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

Michael Welzl <michawe@ifi.uio.no> Mon, 21 July 2014 12:14 UTC

Return-Path: <michawe@ifi.uio.no>
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 612C91B2D4A; Mon, 21 Jul 2014 05:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6z9yxx9ClsHv; Mon, 21 Jul 2014 05:13:39 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A2A1B2884; Mon, 21 Jul 2014 05:13:38 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1X9CTI-0003KY-9v; Mon, 21 Jul 2014 14:13:36 +0200
Received: from dhcp-8bda.meeting.ietf.org ([31.133.139.218]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1X9CTH-00040B-LZ; Mon, 21 Jul 2014 14:13:36 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <53CCF4B1.6030004@gmail.com>
Date: Mon, 21 Jul 2014 14:13:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D391FD67-FF07-456D-B9D1-155F0A3404CF@ifi.uio.no>
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> <53CCF4B1.6030004@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 12 sum msgs/h 5 total rcpts 18561 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 6024BC657B88BEF5A70F9DE2D49E9E0F5F1A2150
X-UiO-SPAM-Test: remote_host: 31.133.139.218 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 37 max/h 5 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/J2w8JXeW1YsY1kwuljP6W2k77b8
Cc: "Karen E. Egede Nielsen" <karen.nielsen@tieto.com>, rmcat WG <rmcat@ietf.org>, "Black, David" <david.black@emc.com>, "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 12:14:02 -0000

On 21. juli 2014, at 13:08, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

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

Reordering could make this even worse. Could different drop precedences cause reordering?

Cheers,
Michael