Differentiated Services (Diffserv) and Real-Time Communication
draft-ietf-dart-dscp-rtp-10
Yes
(Alissa Cooper)
(Martin Stiemerling)
(Richard Barnes)
No Objection
(Alia Atlas)
(Brian Haberman)
(Jari Arkko)
(Pete Resnick)
Note: This ballot was opened for revision 08 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -08)
Unknown
Martin Stiemerling Former IESG member
Yes
Yes
(for -08)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(for -08)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2014-10-29 for -08)
Unknown
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 functionality. 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.
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-10-29 for -08)
Unknown
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.
Alia Atlas Former IESG member
No Objection
No Objection
(for -08)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-10-29 for -08)
Unknown
Nicely written... and thanks for getting this document out early in the WG's life cycle.
Brian Haberman Former IESG member
No Objection
No Objection
(for -08)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -08)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2014-10-30 for -08)
Unknown
... 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.
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-10-30 for -08)
Unknown
Thanks for addressing the SecDir review comments. https://www.ietf.org/mail-archive/web/secdir/current/msg05151.html The draft looks good, thanks for your work on it as well.
Pete Resnick Former IESG member
No Objection
No Objection
(for -08)
Unknown