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

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

On 18/07/2013 08:46, James Polk wrote:
> At 02:55 PM 7/17/2013, Brian E Carpenter wrote:
>> 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 - while I agree less is more manageable, but less what? Isn't 'the
> less' or "... a small set..." you're referring to actually about
> treatment aggregates, defined by RFC 5127 (where similar PHBs are
> aggregated into 'treatment aggregates' to all be treated the same where
> we have big pipes)? Treatment Aggregates would see all of the above
> video traffic in the same individual treatment aggregate, solving the
> issue you bring up that _not_ any more treatment aggregates are defined.

Yes, I agree entirely.

   Brian

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