Draft: draft-ietf-taps-interface

Commentary: This is a ( work in progress ) attempt to clean up Capacity Profile as a selection property along the lines of the state of the discussion in . you had a suggestion to add " High Throughput Data " as a separate profile mapping to AF2n , but I do n't know anything else about what this would actually imply for transport selection ; can you help me out here ? 
 +1 to this 
 - " Please give me the maximum available bandwidth , possibly at the cost of latency " is not how this is defined . See RFC 4594 , section 4.8 : " The High - Throughput Data service class is RECOMMENDED for elastic applications that require timely packet forwarding of variable rate traffic sources and , more specifically , is configured to provide good throughput for TCP longer - lived flows . " I do n't interpret " require timely packet forwarding " as " possibly at the cost of latency " . I 'm also in favor of keeping it - because it has a defined meaning and implementation method as described in at least one RFC , and is hence perhaps even already used by some ISPs to treat traffic in a certain way . 
 Yes , but for a high - throughput flow , " timely packet forwarding " will more likely be achieved on a high - bandwidth path with higher latency than on a low - latency path with lower bandwidth , that 's what I mean . In RFC 4594 , Figure 2 , it says that High - Throughput data has a " Medium - High tolerance to  " , I think that means the same - for this traffic , you do n't optimize for low latency on the path , but for high bandwidth . 
 just committed text for High Throughput , making it clear that the only thing the transport system can do with this is stick a DSCP mark on it . Is this ready to go ? 
 is this good to merge ? 
 Seemed you reached the correct conclusion scavenger = /= bulk . 
 I like the way this is phrased now . I 'm in favor of keeping High Throughput : The Transport System could use this for Path Selection imo , if it has an idea of the available bandwidth over the paths . I think it makes sense that the application is able to say " Please give me the maximum available bandwith , possibly at the cost of latency " here . Please also change Scavenger / Bulk to Scavenger as per  's request . I 'd do it myself but I do n't want to create a conflict
Paragraph (version A):
The application makes no request about its expected capacity
profile.  No special optimizations of the tradeoff between delay,
delay variation, and bandwidth efficiency should be made when
selecting and configuring stacks.
Paragraph (version A):
Response time (latency) should be optimized at the expense of
bandwidth efficiency and delay variation when sending this
message.  This can be used by the system to disable the coalescing
of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; to signal a
preference for lower-latency, higher-loss treatment; and so on.
Paragraph (version B):
Default: : The application makes no representation about its expected
capacity profile.  No special optimizations of the tradeoff between
delay, delay variation, and bandwidth efficiency should be made when
selecting and configuring transport protocol stacks.  Transport
system implementations that map the requested capacity profile onto
per-connection DSCP signaling without multiplexing SHOULD assign the
DSCP Default Forwarding RFC2474 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version B):
Scavenger: : The application is not interactive.  It expects to send
and/or receive data without any urgency.  This can, for example, be
used to select protocol stacks with scavenger transmission control
and/or to assign the traffic to a lower-effort service.  Transport
system implementations that map the requested capacity profile onto
per-connection DSCP signaling without multiplexing SHOULD assign the
DSCP Less than Best Effort LE-PHB PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version B):
Low Latency/Interactive: : The application is interactive, and
prefers loss to latency.  Response time should be optimized at the
expense of bandwidth efficiency and delay variation when sending on
this connection.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer endpoint
when supported by the underlying transport; and so on.  Transport
system implementations that map the requested capacity profile onto
per-connection DSCP signaling without multiplexing SHOULD assign the
DSCP Expedited Forwarding RFC3246 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version B):
Low Latency/Non-Interactive: : The application prefers loss to
latency but is not interactive.  Response time should be optimized at
the expense of bandwidth efficiency and delay variation when sending
on this connection.Transport system implementations that map the
requested capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF21,AF22,AF23,AF24) RFC2597 PHB; when the Connection is
multiplexed, the guidelines in section 6 of RFC7657 apply.
Paragraph (version B):
Constant-Rate Streaming: : The application expects to send/receive
data at a constant rate after Connection establishment.  Delay and
delay variation should be minimized at the expense of bandwidth
efficiency.  This implies that the Connection may fail if the desired
rate cannot be maintained across the Path.  A transport may interpret
this capacity profile as preferring a circuit breaker RFC8084 to a
rate-adaptive congestion controller.  Transport system
implementations that map the requested capacity profile onto per-
connection DSCP signaling without multiplexing SHOULD assign a DSCP
Assured Forwarding (AF31,AF32,AF33,AF34) RFC2597 PHB; when the
Connection is multiplexed, the guidelines in section 6 of RFC7657
apply.
Paragraph (version B):
High Throughput Data: : The application expects to send/receive data
at the maximum rate allowed by its congestion controller over a
relatively long period of time.  Transport system implementations
that map the requested capacity profile onto per-connection DSCP
signaling without multiplexing SHOULD assign a DSCP Assured
Forwarding (AF11,AF12,AF13,AF14) RFC2597 PHB per section 4.8 of
RFC4594.  When the Connection is multiplexed, the guidelines in
section 6 of RFC7657 apply.