Original text:
between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks. <del> The application is interactive.  Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm), to prefer lower-latency paths, signal a preference for lower-latency, higher-loss treatment, and so on. </del>  The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should <del> be optimized at the expense of bandwidth efficiency.  This implies </del>  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 7.1.6. <del> This boolean property specifies, if true, that an application wants this Message to be acknowledged immediately by the receiver.  In case of reliable transmission, this informs the transport protocol on the sender side faster that it can remove the Message from its buffer; therefore this property can be useful for latency-critical applications that maintain tight control over the send buffer (see sending). 7.1.7. </del> This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of the Capacity Profile protocol and path selection property (see prop- cap-profile). <del> The following values are valid for Instantaneous Capacity Profile: </del>  No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when sending 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 <del> algorithm), to signal a preference for lower-latency, higher-loss treatment, and so on. </del>  <del> Delay and delay variation should be optimized at the expense of </del>  bandwidth efficiency. This Message may be sent at the system's leisure.  This can be

Reviewer comments:
Removes Immediate Acknowledgment and makes it an optional implicit feature of Low Latency profile, renames Instantaneous Capacity Profile to Transmission Profile. Addresses ; we should open a new issue to discuss whether we want to split Capacity Profile back out.
About "Transmission profile", I like it; we had Capacity Profile (not "Instantaneous" though) in NEAT because it contains choices about how an application wants to make use of the available capacity. Because "Transmission profile" loses that hint, it conveys less meaning - but frankly, I still prefer it just for the way it sounds.

Revised text:
between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks.  <ins> 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. </ins> The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should  <ins> be minimized at the expense of bandwidth efficiency.  This implies </ins> 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 7.1.6.  This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of the Capacity Profile protocol and path selection property (see prop- cap-profile).  <ins> The following values are valid for Transmission Profile: </ins> No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when sending 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  <ins> 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. </ins>  <ins> Delay and delay variation should be minimized at the expense of </ins> bandwidth efficiency. This Message may be sent at the system's leisure.  This can be