Re: [Dart] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 21 July 2014 11:08 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 71DA01B2B8D; Mon, 21 Jul 2014 04:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 xJyskRcg4oMG; Mon, 21 Jul 2014 04:08:44 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FF61B2D7A; Mon, 21 Jul 2014 04:08:42 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id ho1so3833565wib.4 for <multiple recipients>; Mon, 21 Jul 2014 04:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pLkTQD094eHAhomXeoG/pby02ikZqHfmtvVX0wT4PDs=; b=AGRdiqrb/cpqmyTXbRGdU1oIaU5gs+2+PgT1FrUMaVbzaGBMC30jjivBRfNflrJuXF ji7Dh2v7tgr9uLvyEmHl2TFxFEP0NZJJ0IhM9CnnXxdY9dpGEOVBLid5QyKUZbOvLX0c gXoBd/rqE7dXib67ztdLiB57ibmw6hIyFpshVLKqohqyyj9vAUq8iFDw0zuPLIy+Cu9w MdEfZHW5Vpa7tASERSP4/G3UwxJR+uYd5btNDcGUgLkCqOHhEpXWk3BmFDWQqQVTsWen mQF1M3UmXQoXPCa4x6zQ01VmYsK1KITPgO/GH5EYndVXlUH0iwdSpZRwMuNfJQl69y5r JeDA==
X-Received: by 10.194.48.103 with SMTP id k7mr21719127wjn.68.1405940919969; Mon, 21 Jul 2014 04:08:39 -0700 (PDT)
Received: from [31.133.140.161] (dhcp-8ca1.meeting.ietf.org. [31.133.140.161]) by mx.google.com with ESMTPSA id lk7sm36836510wjb.24.2014.07.21.04.08.37 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 04:08:39 -0700 (PDT)
Message-ID: <53CCF4B1.6030004@gmail.com>
Date: Mon, 21 Jul 2014 23:08:33 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Black, David" <david.black@emc.com>
References: <20140623191132.21904.23978.idtracker@ietfa.amsl.com> <1373b5f3f2f88c06aafc0deb45287f61@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6386@MX15A.corp.emc.com> <cf82224f01a7f8eb7b234c017e80203e@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71207783F6399@MX15A.corp.emc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/J4DYn2foSN0UFL1vKpZG5WN_khs
Cc: "Karen E. Egede Nielsen" <karen.nielsen@tieto.com>, rmcat WG <rmcat@ietf.org>, "dart@ietf.org" <dart@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [Dart] [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.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: Mon, 21 Jul 2014 11:08:47 -0000

On 21/07/2014 14:00, Black, David wrote:
> Karen,
> 
>>> What's the rationale for "certainly isn't viable" regarding different drop
>>> precedences within a single SCTP session?
>> [Karen] Ok - "certainly not viable" is too strong formulation.
>> Having different drop precedences within the same SCTP CC context would,
>> given that SCTP CC presently is drop driven only,
>> results in that the whole data channel is impacted, from a CC perspective,
>> by the highest drop precedence. But I realize that whether this is
>> acceptable is a question indeed.
> 
> I think you're on to something here.  If the drop precedences only came into
> play after the decision to drop a packet had been made, their effect would
> probably be minimal, as they would only affect what to drop in a session, not
> how much to drop.  OTOH, DiffServ AF is not intended to operate in that fashion
> - the rationale for the 3 drop precedences per AF class was based on envisioning
> the output of two-threshold rate shaper:
> 	AFx1 - Within base or committed traffic profile
> 	AFx2 - Beyond base/committed, but within excess or burst traffic profile
> 	AFx3 - Completely out of profile
> 
> Hence the relative mix of those drop precedences can be expected to affect
> the overall drop rate/probability seen in a session where those precedences
> are mixed.

Yes. And it was clearly aimed at layered video, such that there was
a benefit to the end user in dropping the least important layer
during lossy periods. With anything like a TCP-like congestion
control algorithm in sight, the effects may be completely bizarre.

   Brian

> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Karen E. Egede Nielsen [mailto:karen.nielsen@tieto.com]
>> Sent: Sunday, July 20, 2014 9:20 PM
>> To: Black, David; tsvwg@ietf.org
>> Cc: rmcat WG; dart@ietf.org
>> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
>>
>> Hi,
>>
>>> -----Original Message-----
>>> From: Black, David [mailto:david.black@emc.com]
>>> Sent: 21. juli 2014 02:51
>>> To: Karen E. Egede Nielsen; tsvwg@ietf.org
>>> Cc: rmcat WG; dart@ietf.org; Black, David
>>> Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
>>>
>>> Karen,
>>>
>>> <WG chair hat off>, [+dart list]
>>>
>>>> I wonder if the recommendations of this document should not relate to
>>>> the viability (or rather the opposite) of handling different RTCWEB
>>>> data channels individually from a DSCP markings perspective. Or more
>>>> generally relate to the fact that media streams within the same
>>>> congestion control context cannot be handled individually.
>>>> Right now such considerations are not in the document. If the
>>>> intention is for such consideration to come in documents from the dart
>>>> wg, then it would be very important to  have a reference to this
>>>> dependency - or ?
>>> IMHO, such a reference is necessary, although the dart WG draft will be
>>> informational.  The reference should be added once there is an official
>>> dart
>>> WG draft (likely to happen this week).
>>>
>>>> Something else:
>>>>
>>>> Right now the document stipulates that packets within the same media
>>>> stream may be marked with different DSCP codepoints, i.e., it is said:
>>>>
>>>>    One may select difference drop precedences for the
>>>>    different packets in the media flow.  Therefore, all packets in the
>>>>    stream SHOULD be marked with the same priority but can have
>>>>    difference drop precedences.
>>>>
>>>> which indeed is in compliance with the recommendations put forward in
>>>> draft-york-dart-dscp-rtp-00 in that
>>>> it ensures that the DSCP markings  do not result in re-ordering
>>>> within the media flow, but has it been ascertained, from a CC
>>>> perspective that usage of different drop precedence within the same CC
>>>> context is viable ?
>>> Good question - I will include that in my slides for the dart WG meeting.
>>>
>>>> >From the RTCWEB data channel perspective this certainly isn't viable
>>>>> (being
>>>> SCTP based),
>>>> whether it is viable from an RMCAT CC perspective is something that we
>>>> in the RMCAT wg would need to make more clear.
>>> What's the rationale for "certainly isn't viable" regarding different drop
>>> precedences within a single SCTP session?
>> [Karen] Ok - "certainly not viable" is too strong formulation.
>> Having different drop precedences within the same SCTP CC context would,
>> given that SCTP CC presently is drop driven only,
>> results in that the whole data channel is impacted, from a CC perspective,
>> by the highest drop precedence. But I realize that whether this is
>> acceptable is a question indeed.
>>
>>> Thanks,
>>> --David (as an editor of draft-york, *not* as a tsvwg WG chair)
>>>
>>>> -----Original Message-----
>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Karen E.
>>>> Egede Nielsen
>>>> Sent: Sunday, July 20, 2014 4:49 PM
>>>> To: tsvwg@ietf.org
>>>> Cc: rmcat WG
>>>> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
>>>>
>>>> Hi,
>>>>
>>>> Please accept the following comments:
>>>>
>>>> I wonder if the recommendations of this document should not relate to
>>>> the viability (or rather the opposite) of handling different RTCWEB
>>>> data channels individually from a DSCP markings perspective. Or more
>>>> generally relate to the fact that media streams within the same
>>>> congestion control context cannot be handled individually.
>>>> Right now such considerations are not in the document. If the
>>>> intention is for such consideration to come in documents from the dart
>>>> wg, then it would be very important to  have a reference to this
>>>> dependency - or ?
>>>>
>>>> Something else:
>>>>
>>>> Right now the document stipulates that packets within the same media
>>>> stream may be marked with different DSCP codepoints, i.e., it is said:
>>>>
>>>>    One may select difference drop precedences for the
>>>>    different packets in the media flow.  Therefore, all packets in the
>>>>    stream SHOULD be marked with the same priority but can have
>>>>    difference drop precedences.
>>>>
>>>> which indeed is in compliance with the recommendations put forward in
>>>> draft-york-dart-dscp-rtp-00 in that
>>>> it ensures that the DSCP markings  do not result in re-ordering
>>>> within the media flow, but has it been ascertained, from a CC
>>>> perspective that usage of different drop precedence within the same CC
>>>> context is viable ?
>>>>
>>>> >From the RTCWEB data channel perspective this certainly isn't viable
>>>>> (being
>>>> SCTP based),
>>>> whether it is viable from an RMCAT CC perspective is something that we
>>>> in the RMCAT wg would need to make more clear.
>>>>
>>>> BR, Karen
>>>>
>>>>> -----Original Message-----
>>>>> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of internet-
>>>>> drafts@ietf.org
>>>>> Sent: 23. juni 2014 21:12
>>>>> To: i-d-announce@ietf.org
>>>>> Cc: tsvwg@ietf.org
>>>>> Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rtcweb-qos-02.txt
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>>  This draft is a work item of the Transport Area Working Group
>>>>> Working Group of the IETF.
>>>>>
>>>>>         Title           : DSCP and other packet markings for RTCWeb
>>>>> QoS
>>>>>         Authors         : Subha Dhesikan
>>>>>                           Cullen Jennings
>>>>>                           Dan Druta
>>>>>                           Paul Jones
>>>>>                           James Polk
>>>>> 	Filename        : draft-ietf-tsvwg-rtcweb-qos-02.txt
>>>>> 	Pages           : 7
>>>>> 	Date            : 2014-06-23
>>>>>
>>>>> Abstract:
>>>>>    Many networks, such as service provider and enterprise networks,
>>>>> can
>>>>>    provide per packet treatments based on Differentiated Services Code
>>>>>    Points (DSCP) on a per-hop basis.  This document provides the
>>>>>    recommended DSCP values for browsers to use for various classes of
>>>>>    traffic.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-02
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rtcweb-qos-02
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission until the htmlized version and diff are available at
>>>>> tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/