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

[James Polk <[e-mail]>]

At 06:32 PM 7/16/2013, Charles Eckel (eckelcu) wrote:
> > -----Original Message-----
> > From: James Polk (jmpolk)
> > Sent: Tuesday, July 16, 2013 2:07 PM
> > To: Charles Eckel (eckelcu); [e-mail]
> > Cc: James Polk (jmpolk)
> > Subject: RE: [tsvwg] Submitted ID on delay vs. loss-only rate-adaptive for
> > DiffServ
> >
> > 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?
>
>I think video codec implementations in the AF4X class today often 
>have variable bit rates; however, those variations are primarily due 
>to the amount of motion and sometimes as an adaptation to loss. The 
>latter is what is important in this discussion. Video codecs will 
>continue to have variable bit rates in accordance with the amount of 
>motion, but if aligned with the output of RMCAT, they will adapt 
>based on delay as well as loss.

Thanks - we'll include those points in the next version.

James


>Cheers,
>Charles
>
>
> > 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