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

Ben Campbell <> Sat, 23 August 2014 22:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E4D31A0B80 for <>; Sat, 23 Aug 2014 15:50:56 -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 tLEjYGuTG6-v for <>; Sat, 23 Aug 2014 15:50:54 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E3691A0B7E for <>; Sat, 23 Aug 2014 15:50:54 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id s7NMojLN074850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Aug 2014 17:50:47 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Sat, 23 Aug 2014 17:50:43 -0500
X-Mao-Original-Outgoing-Id: 430527043.700086-61f462b942e4e5092cd442633bcbcce9
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Black, David" <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>, "" <>
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: Sat, 23 Aug 2014 22:50:57 -0000

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

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