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

On 08/24/2014 12:50 AM, Ben Campbell wrote:
> 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 <david.black@emc.com> wrote:
>
> [...]
>
>>> -- 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?
> 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."
>
> [...]
>>> -- 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.
>>
> 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."

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.
>
>
>>> -- 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?
>>
> No, if that is the intent, I am okay with the existing language.
>
>
> [...]
>
> _______________________________________________
> Dart mailing list
> Dart@ietf.org
> https://www.ietf.org/mailman/listinfo/dart