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

["Charles Eckel (eckelcu)" <[e-mail]>]

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

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