Differentiated Services (Diffserv) and Real-Time Communication
RFC 7657

Note: This ballot was opened for revision 08 and is now closed.

(Richard Barnes) Yes

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2014-10-29 for -08)
No email
send info
Thank you for doing this work. It's excellent, and valuable.

I have a small number of editorial questions.

In this text:

1.  Introduction

   The results of using multiple DSCPs to obtain different QoS
   treatments within a single network 5-tuple (e.g., reordering) have
   transport protocol interactions, particularly with congestion control

This is probably perfectly accurate, but I find it confusing. I think my problem is that the sentence sounds like the sender's goal was to cause problems with transport protocol mechanisms. I think it means 

- senders use multiple DSCPs to obtain different QoS treatments within a 5-tuple

- a side effect of using multiple DSCPs is that packets with different DSCPs will often be reordered

- this side effect causes problems with transport protocol mechanisms that expects largely in-order delivery, particularly with congestion control functionality

Am I reading this correctly?

In this text:

2.1.  RTP Background

   The STUN and TURN protocols were originally designed for use of UDP,

I’m not sure what “for use of UDP” means. Is this “to use UDP as a transport”?

   however, TURN has been extended to use TCP as a transport for
   situations in which UDP does not work [RFC6062].  When TURN selects
   use of TCP, the entire real-time communications session is carried
   over a single TCP connection (i.e., 5-tuple).

http://tools.ietf.org/html/rfc7350 has been published recently, defining DTLS as a transport for STUN. Is that in any way relevant to this section?

I feel horribly pedantic for even asking this, but in this text:
3.2.  Traffic Classifiers and DSCP Remarking

   DSCP markings are not end-to-end in general.  Each network can make
   its own decisions about what PHBs to use and which DSCP maps to each
   PHB.  While every PHB specification includes a recommended DSCP, and
   RFC 4594 [RFC4594] recommends their end-to-end usage, there is no
   requirement that every network support any PHBs 

would this be “support any PHBs beyond Default Forwarding”?

In this text:

5.1.  DiffServ, Reordering and Transport Protocols

   Transport protocols provide data communication behaviors beyond those
   possible at the IP layer.  An important example is that TCP [RFC0793]
   provides reliable in-order delivery of data with congestion control.

is there a better reference for TCP than RFC 793? Isn’t that a version of TCP that does NOT have congestion control? Perhaps draft-ietf-tcpm-tcp-rfc4614bis-08 ...

Alternatively, if you dropped “with congestion control”, you might still be making your point … reliable, in-order delivery is beyond what IP does.

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Adrian Farrel) No Objection

Comment (2014-10-29 for -08)
No email
send info
Thanks for making this cross-area piece of work so well.

I had a little bit of a private mutter about whether it is the reliable transport protocols themselves or the implementations that are intolerant to out of order packets. Maybe the text here is a little too kind to the implementations and a little too critical of the protocols. But it is not a big issue in this document.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2014-10-30 for -08)
No email
send info
   So, for two arbitrary network endpoints, there can be no assurance
   that the DSCP set at the source endpoint will be preserved and
   presented at the destination endpoint.  Rather, it is quite likely
   that the DSCP will be set to zero (e.g., at the boundary of a network
   operator that distrusts or does not use the DSCP field) or to a value
   deemed suitable by an ingress classifier for whatever network 5-tuple
   it carries.

In general operational experience is it is unsafe if you are going to employ dscp marking in your your network, to not sanitize other dscp marking on ingress, which leads to a really fun tautology  in that in order to use it you have to break it first.

Barry Leiba No Objection

Comment (2014-10-29 for -08)
No email
send info
Nicely written... and thanks for getting this document out early in the WG's life cycle.

(Kathleen Moriarty) No Objection

Comment (2014-10-30 for -08)
No email
send info
Thanks for addressing the SecDir review comments.

The draft looks good, thanks for your work on it as well.

(Pete Resnick) No Objection