Change:
12.3.19. <del> Intent [TODO: Discuss] </del> <ins> Selection Property </ins> Enumeration Preconnection, Connection, Message <del> This property specifies the application's expectation of the dominating traffic pattern for this Connection.  This implies that the transport system should optimize for the capacity profile specified.  This can influence path and protocol selection.  The following values are valid for the Capacity Profile: 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. 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. 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. The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can, for example, be used to select protocol stacks with scavenger transmission control, to signal a preference for less-than-best-effort treatment, or to assign the traffic to a lower-effort service. </del> <ins> This property specifies the desired network treatment for traffic sent by the application and the tradeoffs the application is prepared to make in path and protocol selection to receive that desired treatment.  When the capacity profile is set to a value other than Default, the transport system should select paths and profiles to optimize for the capacity profile specified.  The following values are valid for the Capacity Profile: 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. 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. 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. 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. 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. 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. </ins> 12.3.20.

Discussion:
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 . NAME you had a suggestion to add "High Throughput Data" as a separate profile mapping to AF2n, but I don't know anything else about what this would actually imply for transport selection; can you help me out here?
+1 to this
NAME - "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 don'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.
NAME 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 Delay", I think that means the same - for this traffic, you don'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?
NAME 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 Anna's request. I'd do it myself but I don't want to create a conflict