Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt

"Black, David" <> Thu, 12 June 2014 02:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 61F2F1B298A for <>; Wed, 11 Jun 2014 19:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.952
X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cCnuxS36k4A7 for <>; Wed, 11 Jun 2014 19:34:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 388941B2986 for <>; Wed, 11 Jun 2014 19:34:55 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C2Ysw6013833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 22:34:54 -0400
X-DKIM: OpenDKIM Filter v2.4.3 s5C2Ysw6013833
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1402540494; bh=i6V2tF0yeoWeUsq6ST7MufpZmlw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Lzl7wXwVDY43YnkviP+HNQm4NGrdweBzbLHbY8p217Xtt9qMzwDee3uhlOjyRyYmk 5FmMVDprJBQc74sWR2mvsmSHh0Jo5X0I5NXRIkO/yHsa7bm6UJjsELpJraxb9I/VHY y5bxDpMS55vHG3pLYUMBD+Y202hBd8F6UaRC29qI=
X-DKIM: OpenDKIM Filter v2.4.3 s5C2Ysw6013833
Received: from ( []) by (RSA Interceptor); Wed, 11 Jun 2014 22:34:35 -0400
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s5C2Xhth016939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 22:34:34 -0400
Received: from ([]) by ([]) with mapi; Wed, 11 Jun 2014 22:34:23 -0400
From: "Black, David" <>
To: "" <>
Date: Wed, 11 Jun 2014 22:34:22 -0400
Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt
Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAKMdosAAGlz6kAAWWTOQACqOmHA=
Message-ID: <>
References: <> <> <CA7A7C64CC4ADB458B74477EA99DF6F502D05022DF@HE111643.EMEA1.CDS.T-INTERNAL.COM> <> <CA7A7C64CC4ADB458B74477EA99DF6F502D05027E8@HE111643.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F502D05027E8@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Classifications: DLM_1, public
Cc: "" <>
Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt
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: Thu, 12 Jun 2014 02:34:58 -0000

Hi Ruediger,

Extracting text on a couple of points:

>     I'd appreciate another
>     draft line explaining how MediaStream corresponds to RTP stream or
>     RTP session.

Sure.  The parenthetical text on MediaStream and MediaStreamTrack can
be pulled out of item 1, moved a bit later in the section and expanded.

> RG> Your draft is offering good QoS related guidance, and it's not only
> 	provided by the above section. I would appreciate a good explanation
>	of what to expect within a single 5 tuple flow (a single application
>	flow or multiple ones).

That expectation may not be what you're looking for - it's likely to be
a longer version of "everything depends on the network(s)", i.e., nothing
can be assured in general, depending on how the networks involved are
configured for DiffServ.  See Brian Carpenter's recent emails to the list
and my comment on strengthening the text in Section 2.4 about how
differentiation can be lost (e.g., all traffic in a 5-tuple could be
remarked to DF [best effort] at some intermediate network boundary node).


> -----Original Message-----
> From: []
> Sent: Wednesday, June 11, 2014 4:09 AM
> To: Black, David
> Cc:
> Subject: AW: I-D Action: draft-york-dart-dscp-rtp-00.txt
> Hi David,
> my responses start by "RG".
> Regards, Ruediger
>  > If a MediaStream is carried in a RTP session, the text may also
>  > explicitely say that (it says MediaStreamTrack == media flow, which is
>  > carried in an individual RTP packet stream)
> DB: As I read Section 11 of draft-ietf-rtcweb-rtp-usage-15, for RTCWEB,
> DB: that would happen only when the MediaStream contains exactly one
> DB: MediaStreamTrack.  The use of these terms in bullet item 1 in
> DB: section 2 is intended to be specific to RTCWEB, but we could add
> DB: text elsewhere to point out that non-RTCWEB usage of MediaStreams
> DB: could use an RTP packet stream for each Media Stream, independent
> DB: of how many MediaStreamTracks each MediaStream contains.
> DB: Could you suggest a reference that could be cited for usage of an
> DB: RTP packet stream for each MediaStream independent of how many
> DB: MediaStreamTracks each MediaStream contains?
> RG> Sorry, I can't, that above was an assumption. I'd appreciate another
>     draft line explaining how MediaStream corresponds to RTP stream or
>     RTP session.
> > Is the following correct:
> >
> > UDP_5-tuple-+--transport protocol 1-----
> >             |
> >             +--RTP session 1-----
> >             |
> >             +--RTP session 2-----+---RTP_stream_2.1
> >                                  |
> >                                  +---RTP_stream_2.2
> >                                  |...
> [snip]
> DB: See draft-ietf-tsvwg-rtcweb-qos-00, which proposes to make all four AF
> DB: classes available, so we can expect that someone will try to use all
> DB: of them (and everything else in that draft).
> DB: OTOH, we did put this warning text in at the end of Section 2.4 of draft-
> york:
>      Backbone and other carrier networks may employ a small number of
>      DSCPs (e.g., less than half a dozen) in order to manage a small
>      number of traffic aggregates; hosts that use a larger number of DSCPs
>      may find that much of the intended differentiation is removed by such
>      networks.
> DB: What additional text would you suggest that we add?
> RG> tsvwg-rtcweb-qos offers 4 priorities which, following the definition given
>     there, are relevant to the browser (not to forwarding, as the draft doesn't
>     change existing standards on that).
>     I'd expect priorities "very low" and "low" to be produced in one queue. I'd
>     expect each AF class to be produced in one queue. So packet reordering may
>     occur between different priorities. Type "data" requires 3 queues, if
>     produced as I'd assume.
> RG> Your draft is offering good QoS related guidance, and it's not only provided by the
>     above section. I would appreciate a good explanation of what to expect within
>     a single 5 tuple flow (a single application flow or multiple ones). I'd
>     further appreciate, if all rtcweb related drafts in the transport area clarify
>     the concepts they support related to rtcweb transport flow types. MF based
>     classification is one mode of DiffServ operation and it's important to note
>     whether this is applicable in future or not. For the time being, application
>     servers aren't always marking flows and the above suggests, that they will
>     have to mark packets within flows individually.
> RG> Finally, if the QoE suffers because code points interpreted as application
>     priorities by browsers, which at the same time are interpreted as transport
>     QoS marks by routers which may be changed at network boundaries, then
>     DiffServ as a whole may have to be re-thought. To better understand that
>     point, I've posted a mail on the tsvwg list.
> Regards,
> Ruediger