Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02

["Black, David" <[e-mail]>]

Ben,

Many thanks for the extensive review - comments inline ...

Could you suggest some additional text on context (WebRTC, clue and bundle)
for the Introduction and Abstract, plus for a better example in Section 4?

Thanks,
--David


> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Monday, August 18, 2014 5:49 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: WGLC Comments on draft-ietf-dart-dscp-rtp-02
> 
> (As individual)
> 
> Hi,
> 
> Here are some WGLC comments on draft-ietf-dart-dscp-rtp-02.
> 
> Thanks!
> 
> Ben.
> 
> ----------------
> 
> **** Substantive:
> 
> -- General:
> 
> I was going to ask if we can be more precise on what sort of layering (and
> muxing?) we expect to really happen on top of DTLS, especially for WebRTC use
> cases. But I think Colin's comments are on the right track, so I will comment
> in that thread.

Dealt with in other thread, on mux items 3 and 4 in Section 2.1.

> -- Abstract (and intro)
> 
> It's probably worth mentioning that, other than mixing RTP/RTCP,  RTP
> multiplexing is a relatively new thing. It's needed by new work such as WebRTC
> and clue, and it is enabled by bundle. The point being, this wasn't something
> we really needed to worry about until now.

Could you suggest text for the Introduction section, along with any additional references?

> 
> -- Section 2.1, list item 3: "An RTP session could be multiplexed with other
> protocols ... "
> 
> What is likely to really happen here? I don't think we will see an arbitrary
> mixing of other protocols in the immediate future. What are the realistic
> constraints, and likely layerings?  For example, with WebRTC, we are likely to
> see some number of RTP/RTCP streams, stun, turn, and dtls, with dtls carrying
> one or more SCTP associations (i.e. data channels) right? Do we have ways to
> signal more than that in sdp-bundle?
> 
> OTOH, I guess one could argue that people might try to mix in more things in
> the future.

Dealt with in other thread.

> -- 2.1, 2nd to last paragraph, last sentence (starting with "In contrast..."
> 
> Is this specific to SCTP associations carried over DTLS packets a la RFC5764,
> or are we talking about SCTP/UDP in general?

It's SCTP/UDP in general, clarified.

> 
> -- 2.2, third paragraph:
> 
> Are we talking about TCP as the outer transport protocol, and muxing things on
> the TCP 5-tuple? Or are we considering TCP as something that might get
> multiplexed on the UDP 5-tuple? Where do Jonathan Lennox's comments about
> potentially falling back to an ICE TCP candidate fit?

It's TCP as the outer transport protocol, and this is part of the text that
responds to Jonathan Lennox's comments (the rest of it is hidden in 5.3, and
needs some more prominence, as it's missing from the guidelines).  I added:

   When TURN selects use of TCP, the entire real-time communications
   session is carried over a single TCP 5-tuple.

And added mention of this scenario (TURN selects TCP) to the guideline on TCP.
 
> -- section 3, paragraph 5:
> 
> Does the term "network node" include application endpoints that might do
> initial DiffServ marking?

No, changed to "node in the network".

> 
> -- section 3, paragraph 12: "... observable forwarding behavior (e.g., loss,
> delay, jitter) will often depend only on the relative loading of the link"
> 
> Relative to what? Other links? Relative load to the capacity of the link?

Removed "relative" ;-).

> 
> -- section 4:
> 
> It might be nice to have a more WebRTC-ish example. For example an audio
> stream, video stream, and a data channel carrying something like a shared
> white board or game.

Sure, please send text.

> -- section 6, last bullet:
> 
> Is there a such thing as "less than best effort traffic" where "best effort"
> treatments would be unacceptable?

I can come up with possible examples - background bulk transfer of something
large that should not interfere with foreground WebRTC data that is being
carried as best-effort.
> 
> Actually, it's not clear to me from this paragraph if CS1 is ever appropriate,
> at least from the application endpoint perspective, as it seem to give
> completely unpredictable results.

That was intended - would you like to see stronger language?

> -- Normative References:
> 
> Are these first two references both "normative" enough to block on them?

Well, the first one certainly is - if the relevant terminology in the
rtp-grouping-taxonomy draft changes, this DART draft will change also, as
has already been demonstrated.

OTOH, I'll move both RFC 5764 and the rfc5764-mux-fixes draft to informative.

 
> **** Editorial:
> 
> -- section 1, paragraph 1: "As a result use of different DSCPs..."
> 
> Missing comma after "result".

Fixed.

> -- 3.2, paragraph 1: "... and such nodes remark traffic ..."
> 
> May remark? Always remark?

It's "may remark," but I rephrased for clarity - the sentence now reads:

   When DiffServ is used, the edge or boundary nodes of a network are
   responsible for ensuring that all traffic entering that network
   conforms to that network's policies for DSCP and PHB usage, and
   such nodes may change DSCP markings on traffic to achieve that result.

 
> -- 3.2, paragraph 3, last sentence:
> 
> Is this sentence redundant to the previous paragraph?

Not completely, but I moved the point about ignoring embedded headers
into the previous paragraph and removed this sentence.

> 
> -- 4, paragraph 1: 2nd and 3rd sentence
> 
> These sentences seem to contradict. The first says that receiving audio early
> is not useful, but the second says it may be useful.

Changed second sentence to talk about increased reliability of receiving audio

... because more reliable arrival of audio helps assure smooth audio rendering ...

> 
> -- 4, 2nd paragraph: "... e.g., are in an AF class ..."
> 
> in the _same_ AF class?

Yes, changed to "a single AF class".

> 
> -- 5.1, 7th paragraph
> 
> Is this paragraph redundant with previous discussions of AF classes?

I don't think the paragraph is redundant, but I removed
	"as the three PHBs in an AF class differ solely in drop precedence."
as that is redundant with 3.1.

> 
> -- 5.2, third paragraph:
> 
> Can you elaborate on what it means to be "contained in a buffer"?

Added: "because packets that arrive out of order are retrieved in order
from the jitter buffer for rendering."

> 
> -- 5.2, around paragraph 5:
> 
> There are words about why non-interactive media is likely to have larger
> jitter buffers, but the fact that interactive media may have smaller buffers
> us left to implication.

Elaborated first sentence in previous bullet - it now ends with
	"such as interactive conversations for which small jitter buffers
	are necessary to preserve human perceptions of real-time interaction."
> 
> -- 5.3, 1st and 2nd sentence:
> 
> These seem redundant to previous discussions about AF classes.

Tightened up - the point about same forwarding resources implying no latency
variation needs to be made here.  New text:

   Packets on the same 5-tuple that use PHBs within a single AF class can be
   expected to draw upon the same forwarding resources on network nodes (e.g.,
   use the same router queue) and hence use of multiple drop precedences within
   an AF class is not expected to cause latency variation.

> -- 5.3, 2nd paragraph:
> 
> It's not clear to me what this paragraph means. Is drop likelihood the
> likelihood that anything is dropped in a session, or the chance of any given
> packet being dropped? I assume drop likelihood is relative to that of other
> sessions crossing the same path? And that under non congested conditions none
> of this will matter?

Deleted second sentence, and rephrased first to:

   When PHBs within a single AF class are mixed within a flow, the resulting
   overall likelihood that packets will be dropped from that flow is a mix of
   the drop likelihoods of the PHBs involved.

I also joined it up w/the previous paragraph.

> 
> 
> -- 6, 1st paragraph: " ... the following requirements ..."
> 
> Are these requirements per se, or guidelines?

Guidelines.

> -- 6, bullet list
> 
> Each bullet starts with a verb, but ommits the subject. E.g., in the first
> bullet, what is the actor that should not use different DSCPs within a
> different stream?

The subject was factored out - "applications and other traffic sources".
I moved it to start a new paragraph.

> -- 6, 1st bullet:
> 
> The double negation is confusing  ("should not use", "If this is not
> done..."). Also,

Now reads: " Should limit use of DSCPs within a single RTP stream to those
whose PHBs do not allow packet reordering."

> 2nd bullet:
> 
> Is "use a single PHB and DSCP" different than just saying "use a single DSCP"?

The latter is better for "applications and other traffic sources"  Extensive
editing resulted,.

> 
> 3rd bullet:
> 
> Am I correct in assuming SCTP multihoming is not an issue here? Should we
> mention that explicitly?

It's not an issue, and does not really need to be mentioned here.  Switching
among addresses involved in SCTP multihoming is a transient affect akin to
(and possibly caused by) routing changes, and that's already mentioned in
Section 5.1.