Skip to main content

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