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

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Aug 2014 16:49:27 -0500

(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.

-- 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.

-- 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.

-- 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?

-- 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?

-- section 3, paragraph 5:

Does the term "network node" include application endpoints that might do initial DiffServ marking?

-- 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?

-- 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.

-- section 6, last bullet:

Is there a such thing as "less than best effort traffic" where "best effort" treatments would be unacceptable?

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.

-- Normative References:

Are these first two references both "normative" enough to block on them?

**** Editorial:

-- section 1, paragraph 1: "As a result use of different DSCPs..."

Missing comma after "result".

-- 3.2, paragraph 1: "... and such nodes remark traffic ..."

May remark? Always remark?

-- 3.2, paragraph 3, last sentence:

Is this sentence redundant to the previous paragraph?

-- 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.

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

in the _same_ AF class?

-- 5.1, 7th paragraph

Is this paragraph redundant with previous discussions of AF classes?

-- 5.2, third paragraph:

Can you elaborate on what it means to be "contained in a buffer"?

-- 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.

-- 5.3, 1st and 2nd sentence:

These seem redundant to previous discussions about AF classes.

-- 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?

-- 6, 1st paragraph: " ... the following requirements ..."

Are these requirements per se, or 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?

-- 6, 1st bullet:

The double negation is confusing  ("should not use", "If this is not done..."). Also,

2nd bullet:

Is "use a single PHB and DSCP" different than just saying "use a single DSCP"?

3rd bullet: 

Am I correct in assuming SCTP multihoming is not an issue here? Should we mention that explicitly?

---

From: "Black, David" <[email-masked]>
Date: Fri, 22 Aug 2014 20:03:30 -0400

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:[email-masked]]
> Sent: Monday, August 18, 2014 5:49 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: WGLC Comments on draft-ietf-dart-dscp-rtp-02
> 
> (As individual)
> 
> Hi,
> 
> 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?

> 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?
> 

Dealt with in other thread.

> 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.
 
> 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"
> 

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.

> 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?

> 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.

> Missing comma after "result".

Fixed.

> 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.

> 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.

> 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 ..."

Yes, changed to "a single AF class".

> 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.

> 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."

> 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."
> 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.

> 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.

> The double negation is confusing  ("should not use", "If this is not

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

> 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,.

> Am I correct in assuming SCTP multihoming is not an issue here? Should we

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.

---

From: Ben Campbell <[email-masked]>
Date: Sat, 23 Aug 2014 17:50:43 -0500

Hi, comments inline. I deleted sections that do not need to seem further comment (or where the comment would have been "okay").

On Aug 22, 2014, at 7:03 PM, Black, David <[email-masked]> wrote:

[...]

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

Okay, how about something like the following (perhaps inserted after "... including communication based on the Real-time Transport Protocol (RTP)")

"Historically, distinct RTP streams have been sent over different transport level flows, sometimes multiplexed with RTCP. But recently WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) [RFC4566] bundle negotiation mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] to send multiple streams, potentially needing different QoS treatments,  using the same IP 5-tuple."

[...]
>> stream, video stream, and a data channel carrying something like a shared

Okay, how about something like the following, added to the end of section 4:

"A WebRTC application may carry one or more RTP streams, as discussed above. In addition, it might carry an SCTP data channel. The treatment of the data channel would depend on the nature of the application. For example, messaging applications, shared white board, or guided browsing applications might be best effort, while a latency-sensitive game application might require a higher priority PHB. "

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

No, if that is the intent, I am okay with the existing language.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Sat, 23 Aug 2014 17:52:31 -0500

> "A WebRTC application may carry one or more RTP streams, as discussed above. In addition, it might carry an SCTP data channel. The treatment of the data channel would depend on the nature of the ap…

Oops, I meant to add draft-ietf-rtcweb-data-channel-11 as a reference for WebRTC data channels.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 25 Aug 2014 12:17:40 +0200

On 08/24/2014 12:50 AM, Ben Campbell wrote:
> "A WebRTC application may carry one or more RTP streams, as discussed above. In addition, it might carry an SCTP data channel. The treatment of the data channel would depend on the nature of the application. For example, messaging applications, shared white board, or guided browsing applications might be best effort, while a latency-sensitive game application might require a higher priority PHB."

I would prefer to say "A WebRTC application may use...." - an 
application is something that lives in a browser at one end of a 
connection, talking to something at the other end of the connection 
(might be an instance of the same application, might be something 
completely different).

I would also prefer "might desire" to "might require" - games are 
unlikely to refuse to operate if they don't get a higher priority PHB, 
they'll just work with degraded performance. That's nits.
> _______________________________________________
> Dart mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dart

---

From: Ben Campbell <[email-masked]>
Date: Mon, 25 Aug 2014 13:07:10 -0500

On Aug 25, 2014, at 5:17 AM, Harald Alvestrand <[email-masked]> wrote:

> I would prefer to say "A WebRTC application may use...." - an application is something that lives in a browser at one end of a connection, talking to something at the other end of the connection (might be an instance of the same application, might be something completely different).
> 
> I would also prefer "might desire" to "might require" - games are unlikely to refuse to operate if they don't get a higher priority PHB, they'll just work with degraded performance. That's nits.
> 

Harald's suggestions improve the text. I agree with both.