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

Harald Alvestrand <> Mon, 25 August 2014 10:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 334A21A8BC1 for <>; Mon, 25 Aug 2014 03:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LupcVJQMzrEe for <>; Mon, 25 Aug 2014 03:17:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ABD841A8BBF for <>; Mon, 25 Aug 2014 03:17:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97B207C3F67 for <>; Mon, 25 Aug 2014 12:17:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NgFFPQmcVc2P for <>; Mon, 25 Aug 2014 12:17:41 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:6dc8:104c:7418:7e33] (unknown [IPv6:2001:470:de0a:27:6dc8:104c:7418:7e33]) by (Postfix) with ESMTPSA id 1025A7C3F65 for <>; Mon, 25 Aug 2014 12:17:41 +0200 (CEST)
Message-ID: <>
Date: Mon, 25 Aug 2014 12:17:40 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Dart] WGLC Comments on draft-ietf-dart-dscp-rtp-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Aug 2014 10:17:47 -0000

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