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

[Brian E Carpenter <[e-mail]>]

On 17/07/2013 18:50, [e-mail] wrote:
> I think the question of sharing diffserv is important, and my current
> suggestion is that RMCAT should use one or at most two DSCPs and design a
> CC that works well within the class - however this does not absolve RMCAT
> from also having to work in the Internet without this class. This will
> likely be the main use-case!
> 
> Although the proposal could help these applications - the IETF can not
> somehow mandate this is universally deployed - and even if the DSCP(s)
> were universally recognised, it would still be aggregated within some
> networks and on L2 technologies that support fewer classes than DSCP
> markings.
> 
> It would be interesting to know if others think we should be considering
> more DSCPs for this?

If you mean "more" in the sense of defining new PHBs, I sincerely hope
not. Diffserv works best with a small set of highly differentiated
PHBs. Also, in order to get cross-domain agreements on DSCP assignments,
the fewer there are the better.

    Brian

> 
> Gorry
> 
>> 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: [e-mail] [mailto:[e-mail]] 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); [e-mail]; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Michael Ramalho (mramalho)
>>> Sent: Tuesday, July 16, 2013 6:36 AM
>>> To: [e-mail]
>>> 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: [e-mail]
>>> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Eggert, Lars
>>> Sent: Tuesday, July 16, 2013 5:26 AM
>>> To: WG WG
>>> Cc: [e-mail]
>>> 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 <[e-mail]>
>>>> Subject: [tsvwg] Submitted ID on delay vs. loss-only
>>> rate-adaptive for DiffServ
>>>> Date: July 16, 2013 8:07:59 GMT+02:00
>>>> To: <[e-mail]>
>>>>
>>>> (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
>>>>
> 
> 
>