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

<Ruediger.Geib@telekom.de> Wed, 11 June 2014 08:10 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3071A04C5 for <dart@ietfa.amsl.com>; Wed, 11 Jun 2014 01:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUxGLMiU_UG1 for <dart@ietfa.amsl.com>; Wed, 11 Jun 2014 01:10:01 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249D61A0426 for <dart@ietf.org>; Wed, 11 Jun 2014 01:10:00 -0700 (PDT)
Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jun 2014 10:09:02 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 11 Jun 2014 10:08:56 +0200
From: Ruediger.Geib@telekom.de
To: david.black@emc.com
Date: Wed, 11 Jun 2014 10:08:55 +0200
Thread-Topic: I-D Action: draft-york-dart-dscp-rtp-00.txt
Thread-Index: Ac+B6llHN+tZu0BQRLuCYnrysE8HOgAATlNQAKMdosAAGlz6kAAWWTOQ
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F502D05027E8@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <20140607004925.14786.21299.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076FD342D1@MX15A.corp.emc.com> <CA7A7C64CC4ADB458B74477EA99DF6F502D05022DF@HE111643.EMEA1.CDS.T-INTERNAL.COM> <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076FD346BA@MX15A.corp.emc.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/IAcP7dRLfwkS17J5zkKypymqDDM
Cc: dart@ietf.org
Subject: Re: [Dart] I-D Action: draft-york-dart-dscp-rtp-00.txt
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jun 2014 08:10:06 -0000

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