Draft: draft-ietf-taps-interface

Commentary: : a statement about data arriving before Receive is issued ; : removed the confusing sentence ; : carried out replacements suggested by 
 This issue comes from other discussion at the interim of what it means to map to DSCP classes , and proposes to fix two topics . Replace reference OLD : DSCP Less than Best Effort [ LE - PHB ] PHB NEW : DSCP Less than Best Effort [ RFC8622 ] PHB — Low Latency / Interactive : The current advice is wrong . An endpoint never should be assigning EF without understanding the implication of CAC and policing . OLD : Transport system implementations that map the requested capacity profile onto per - connection DSCP signaling without multiplexing SHOULD assign the DSCP Expedited Forwarding [  ] PHB ; NEW : Transport system implementations that map the requested capacity profile onto per - connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding ( AF41,AF42,AF43,AF44 ) [ RFC2597 ] PHB . Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding [  ] or [ RFC5865 ] PHBs . — 
 The new text resolve this issue . 
 I 'm not sure I understand this sentence ( in sec 8 . - Receiving Data ): " As with sending , the type of the Message to be passed is dependent on the implementation , and on the constraints on the Protocol Stacks implied by the Connection 's transport parameters . " Especially , what 's meant by " type of Message " ?
Paragraph (version A):
Once a Connection is established, it can be used for receiving data.
As with sending, data is received in terms of Messages.  Receiving is
an asynchronous operation, in which each call to Receive enqueues a
request to receive new data from the connection.  Once data has been
received, or an error is encountered, an event will be delivered to
complete the Receive request (see receive-events).
Paragraph (version A):
As with sending, the type of the Message to be passed is dependent on
the implementation, and on the constraints on the Protocol Stacks
implied by the Connection's Transport Properties.
Paragraph (version B):
Once a Connection is established, it can be used for receiving data.
As with sending, data is received in terms of Messages.  Receiving is
an asynchronous operation, in which each call to Receive enqueues a
request to receive new data from the connection.  Once data has been
received, or an error is encountered, an event will be delivered to
complete any pending Receive requests (see receive-events).  If
Messages arrive at the transport system before Receive requests are
issued, ensuing Receive requests will first operate on these Messages
before awaiting any further Messages.
Paragraph (version A):
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 SHOULD assign the DSCP Less
than Best Effort LE-PHB PHB.
Paragraph (version B):
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 SHOULD assign the DSCP Less
than Best Effort RFC8622 PHB.
Paragraph (version A):
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.
Paragraph (version B):
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 a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) RFC2597
PHB.  Inelastic traffic that is expected to conform to the
configured network service rate could be mapped to the DSCP
Expedited Forwarding RFC3246 or RFC5865 PHBs.