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

[James Polk <[e-mail]>]

CJ

These are good suggestions for the next version. I thank you for 
offering them. I agree that s5.1 is underspecified, and will be 
expanded next version along the lines of your 1st paragraph below, as well.

James

At 03:22 PM 7/17/2013, Cheng-Jia Lai (chelai) wrote:
>I think it would be good if Section 5.1 can include some 
>specification or recommendation how a video flow's packets should be 
>classified into CS4 and CS4-Discardable and how they will be dropped 
>preferentially at congestion. Although AF4x has already specified 
>how to do this by different drop probabilities, it might not be 
>suitable since I-frame, IDR, or other important packets (e.g. 
>in-band signals or supplementary metadata) can still be dropped by 
>probability (smaller though) before all discardable P frames in the 
>same video flow are dropped.
>
>In addition, maybe it should cover some fairness requirements, i.e. 
>how the video rate adaptive behaviors can expect to see packet drops 
>w.r.t. contention, which IMHO should encourage video endpoints to 
>generate more discardable P-frame or other lower priority packets, 
>even at congestion. If possible, this should also try to avoid 
>global synchronization, i.e. all video-encoders to generate 
>I-frame/IDR at the same time (even after they reduce rate, they 
>still need to recover the lost video) when CS4 / CS4-Discardable 
>queue is congested and drops packets from all of them.
>
>Regards,
>CJ
>
>
>-----Original Message-----
>From: James Polk (jmpolk)
>Sent: Tuesday, July 16, 2013 2:11 PM
>To: Cheng-Jia Lai (chelai); James Polk (jmpolk); Toerless Eckert 
>(eckert); Michael Ramalho (mramalho); [e-mail]; [e-mail]
>Subject: RE: [tsvwg] FW: [rmcat] 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
> > >