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

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

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