Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ

Michael Welzl <michawe@ifi.uio.no> Wed, 17 July 2013 15:59 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0519921F9D9A; Wed, 17 Jul 2013 08:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8IW1DrYERHl; Wed, 17 Jul 2013 08:59:25 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC721F8E1F; Wed, 17 Jul 2013 08:59:25 -0700 (PDT)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1UzU8R-0006H0-EZ; Wed, 17 Jul 2013 17:59:23 +0200
Received: from 089144206079.atnat0015.highway.bob.at ([89.144.206.79] helo=[192.168.1.6]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1UzU8P-0004mx-JP; Wed, 17 Jul 2013 17:59:23 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com>
Date: Wed, 17 Jul 2013 17:59:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9CCDAE4B-CA8E-4107-80EB-B7DD020CC9D1@ifi.uio.no>
References: <201307160608.r6G680RY026646@rcdn-core-4.cisco.com> <025A278C-55F2-4EB4-A12F-677F8F01A0D0@netapp.com> <D21571530BF9644D9A443D6BD95B910315595CC7@xmb-rcd-x12.cisco.com> <D21571530BF9644D9A443D6BD95B910315595D97@xmb-rcd-x12.cisco.com> <A860EC86B79FA646BF3F89165A88626415339C25@xmb-aln-x11.cisco.com> <201307162111.r6GLBSwF029514@rcdn-core-5.cisco.com> <3879D71E758A7E4AA99A35DD8D41D3D91D494900@xmb-rcd-x14.cisco.com>
To: Mo Zanaty <mzanaty@cisco.com>
X-Mailer: Apple Mail (2.1508)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 22 msgs/h 9 sum rcpts/h 29 sum msgs/h 14 total rcpts 5801 max rcpts/h 40 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: 3394EAB07E4490447B8290DFABDD84BA4E15D334
X-UiO-SPAM-Test: remote_host: 89.144.206.79 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 9 total 42 max/h 10 blacklist 0 greylist 0 ratelimit 0
Cc: "Toerless Eckert (eckert)" <eckert@cisco.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>, "Michael Ramalho (mramalho)" <mramalho@cisco.com>, "James Polk (jmpolk)" <jmpolk@cisco.com>, "Cheng-Jia Lai (chelai)" <chelai@cisco.com>
Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmcat>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2013 15:59:30 -0000

+1

On Jul 17, 2013, at 5:23 AM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

> I support something like what this draft proposes, to segregate RMCAT (and potentially other delay-adaptive traffic) from other traffic which does not adapt to delay trends (and therefore incurs maximum queue delay for all traffic in its queue). Of course, this only helps when such queue segregation is available in the network, but effective active queue management is not available (otherwise there would be no delay signals for delay-adaptive traffic to act on).
> 
> An open question in my mind, that I think this draft needs to address, is whether all delay-adaptive traffic should share the same queue/DSCP, or whether we need different queues/DSCPs for different delay-adaptive protocols/applications (for example, RMCAT vs. LEDBAT).
> 
> Mo
> 
> -----Original Message-----
> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On Behalf Of James Polk (jmpolk)
> Sent: Tuesday, July 16, 2013 5:11 PM
> To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert (eckert); Michael Ramalho (mramalho); tsvwg@ietf.org; rmcat@ietf.org
> Subject: Re: [rmcat] [tsvwg] FW: Fwd: Submitted ID on delay vs. loss-only rate-adaptive for DiffServ
> 
> CJ
> 
> Thank you for the quick review.
> 
> I'll ask you the same question I just asked Michael, the draft isn't 
> very long (under 8 pages currently), and it is a work in progress - 
> but do you have text or just points that this draft needs to cover 
> that it doesn't currently?
> 
> James
> 
> At 01:36 PM 7/16/2013, Cheng-Jia Lai (chelai) wrote:
>> Same here... I feel it makes sense to create a new DSCP / CS4 for 
>> transport of video flows that have rate adaptive behaviors and/or 
>> intra-flow preferential drop priorities as indicated in the I-D. The 
>> service provided by the network may thus be considered new, i.e. 
>> different from what exists in AF4x, so IMHO, using a new or reusing 
>> CS4 service class adds clarity for the user applications.
>> 
>> Regards,
>> CJ
>> 
>> 
>> -----Original Message-----
>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On 
>> Behalf Of Michael Ramalho (mramalho)
>> Sent: Tuesday, July 16, 2013 6:36 AM
>> To: tsvwg@ietf.org
>> Subject: [tsvwg] FW: [rmcat] Fwd: Submitted ID on delay vs. 
>> loss-only rate-adaptive for DiffServ
>> 
>> TSVWG Members,
>> 
>> I should have copied you on my email to the RMCAT mailer below.
>> 
>> I strongly support the creation of a new DSCP for transports in 
>> which their congestion control can adapt based on delay.
>> 
>> The current ID in support of this 
>> (http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt 
>> ) is a work in progress, but a step in the right direction.
>> 
>> It is a given that the ability of the eventual RMCAT adaptation 
>> mechanisms to achieve low delay will be function of the other 
>> dominant traffic it is competing against. If the dominant competing 
>> traffic DEPENDS on loss, the RMCAT packets are held hostage to being 
>> delayed by the bottleneck queue delay maximum.
>> 
>> Thus, whenever possible, it will be preferable for RMCAT flows to 
>> compete with other congestion control transports that adapt on 
>> delay. Even this may not get us to the desired low-delay goals when 
>> a portion of the traffic has long RTTs (i.e., adaptation control 
>> loops that are long in time), or for links that have a highly-time 
>> varying capacity,  but it will help for a lot of common bottleneck 
>> topologies (e.g., slowly time-varying access bufferbloat).
>> 
>> It is my hope that this topic has some discussion time in the Berlin 
>> Transport WG (not the specific codepoint to be chosen, but rather 
>> the need for one).
>> 
>> Off Soapbox,
>> 
>> Michael Ramalho, Ph.D.
>> 
>> -----Original Message-----
>> From: Michael Ramalho (mramalho)
>> Sent: Tuesday, July 16, 2013 9:06 AM
>> To: rmcat@ietf.org
>> Subject: RE: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. 
>> loss-only rate-adaptive for DiffServ
>> 
>> RMCAT Design Team,
>> 
>> The draft Lars references below is a formal request for a DSCP 
>> dedicated to "RMCAT-only (or other nice delay-based cc) traffic".
>> 
>> It will take a while to become socialized ... and we can progress 
>> our RMCAT work in the interim.
>> 
>> Michael Ramalho
>> 
>> -----Original Message-----
>> From: rmcat-bounces@ietf.org [mailto:rmcat-bounces@ietf.org] On 
>> Behalf Of Eggert, Lars
>> Sent: Tuesday, July 16, 2013 5:26 AM
>> To: WG WG
>> Cc: draft-polk-tsvwg-delay-vs-loss-ds-service-classes@tools.ietf.org
>> Subject: [rmcat] Fwd: [tsvwg] Submitted ID on delay vs. loss-only 
>> rate-adaptive for DiffServ
>> 
>> Possibly of interest to RMCAT.
>> 
>> Begin forwarded message:
>> 
>>> From: James Polk <jmpolk@cisco.com>
>>> Subject: [tsvwg] Submitted ID on delay vs. loss-only 
>> rate-adaptive for DiffServ
>>> Date: July 16, 2013 8:07:59 GMT+02:00
>>> To: <tsvwg@ietf.org>
>>> 
>>> (as an author)
>>> 
>>> Toerless and I put together a draft about legacy rate-adaptation 
>> based only on loss vs. what RMCAT is looking to (for RTCWEB), which 
>> is based on delay and loss.  Here's the URL.
>>> 
>>> 
>> http://www.ietf.org/internet-drafts/draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt
>>> 
>>> It's more raw than we had in mind, but we believe this is 
>> necessary, based on implementation experience and what users and 
>> customers have in their networks, or are planning on having in 
>> their networks soon.
>>> 
>>> James & Toerless
>>> 
>