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

[James Polk <[e-mail]>]

At 03:46 PM 7/16/2013, Charles Eckel (eckelcu) wrote:
>I read the draft and thank you for addressing this need. It does a 
>good job of making the case for the need to differentiate the DSCP 
>assignments of delay-and-loss-based vs. just-loss-based 
>rate-adaptive video applications. While I do not agree with some of 
>the finer points in the draft, including the statement in section 3 
>that AF4x traffic in general is inelastic/fixed bitrate,

Charles

Thank you for the quick review!

If we authors gave the impression that all AF4X marked traffic is 
inelastic and uses the 'same' fixed bitrates, we apologize. However, 
each AF4X flow from a given codec - be it audio or video - in today's 
implementations, pretty much use the same bitrate per flow (not the 
same bitrate for each flow). Do you agree with this clarification, or 
would you like to offer substitute/replacement text in the offending section?

James

>  I completely agree that this traffic is largely loss sensitive and 
> yet often relies on loss based adaption.
>The assignment of a new service class and the proposal for CS4 and 
>CS4-Discardable for rate-adaptive video makes sense to me. At the 
>same time, it is important to re-designate AF4x as you describe in 
>order to match the reality of today's deployments and avoid future confusion.
>I look forward to seeing this work progress as it offer an incentive 
>for applications to embrace congestion control algorithms such as 
>those being developed in RMCAT without fearing they will be overrun 
>by non-delay adaptive traffic.
>
>Cheers,
>Charles
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > James Polk (jmpolk)
> > Sent: Monday, July 15, 2013 11:08 PM
> > To: [e-mail]
> > Subject: [tsvwg] Submitted ID on delay vs. loss-only 
> rate-adaptive for DiffServ
> >
> > (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