Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01

[Ingemar Johansson S <[e-mail]>]

Hi

Not sure I get it. 
Do you mean that coupling algo is immune to video coder output rate variation ?

/Ingemar

> -----Original Message-----
> From: Michael Welzl [mailto:[e-mail]]
> Sent: den 22 juli 2015 11:16
> To: Ingemar Johansson S
> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; [e-mail]; Mirja
> Kühlewind
> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> 
> understood; i think these details are beyond the scope of our coupling draft
> which focuses on a different method.
> 
> cheers
> michael
> 
> Sent from my iPhone
> 
> > On 22. juli 2015, at 11:06, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > Hi
> >
> > Still waiting for the summer to show up so I'll try to chime in while this
> subject is at least luke-warm. I may be slow with follow up on this, sorry for
> that in advance.
> >
> > Stream prio in SCReAM is outlined in section A.2 in the draft
> (https://tools.ietf.org/html/draft-ietf-rmcat-scream-cc-01#page-28 ). In its
> function it resembles fq-codel quite a lot in the sense that streams that do
> not get scheduled at a given scheduling instant gets a credit that is used to
> increase the chance of being scheduled at the next scheduling instant. A
> configurable scheduling priority determines how much credit  that is given.
> Looking in the https://tools.ietf.org/pdf/draft-ietf-tsvwg-sctp-ndata-04.pdf
> draft I would say that this resembles the "Weighted Fair Queueing
> Scheduler"  the most. Some additional means are needed to make this work
> well in reality though (see below).
> >
> > The benefit with doing scheduling priority and a common congestion
> control is an increased probability that the path capacity is fully utilized, if a
> stream becomes idle (for instance no or little activity in one video source) ,
> more resources are allocated to the other sources. And this is achieved with
> no or very little additional delay buildup on the sender side.
> > Another benefit with stream prioritization is that it is easier to make one
> congestion control behave well (low delay /packet loss) esp. on a wireless
> link. We have simulation results that supports this statement albeit in the
> different context (QUIC congestion control evolution).
> > The stream prioritization and one congestion control of course require
> > that all the streams share the same bottleneck characteristics
> >
> > With that said, the biggest challenge I have seen this far is the large
> variability of esp. video sources. Sit still in front of the camera and the output
> rate becomes very low regardless the target rate, move yourself closer to
> the camera and bang!!.. you get 2Mbps video rate all of a sudden. This
> variability causes issues with stream prioritization in the sense that less
> variable streams may be pushed back. Additional code is therefore added in
> SCReAM to correct this anomaly and ensure a (weighted) fair distribution
> over a longer time scale. Still as mentioned in the SCReAM draft, this needs
> to be tried out some more. I have sofar only simulated video sources with
> variability to see that the current implementation is reasonably robust.
> > The bottom line here is that, while scheduling of streams with static
> properties may be considered simple, real video may be a taller order.
> >
> > /Ingemar
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Michael Welzl [mailto:[e-mail]]
> >> Sent: den 20 juli 2015 10:03
> >> To: Karen E. E. Nielsen
> >> Cc: Zaheduzzaman Sarker; Ingemar Johansson S; [e-mail]; Mirja
> >> Kühlewind
> >> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> >>
> >>
> >>>> On 20. jul. 2015, at 07.32, Karen Elisabeth Egede Nielsen
> >>> <[e-mail]> wrote:
> >>>
> >>> HI,
> >>>
> >>> Yes - there is the possibility to implement coupled congestion
> >>> control with scheduling priorities, There is no doubt about that
> >>> :-), Indeed SCTP does it and scream does it.
> >>> But it is not so well-described in the scream draft how exactly the
> >>> prioritization works and which means an application has to define
> >>> different priorities.
> >>> (For information then for SCTP a number of different scheduling
> >>> possibilities is described in
> >>> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/.)
> >>>
> >>> Then for RMCAT coupled congestion control  we have the Wezlz,
> >>> Safiqul proposal where the coupled is done in-between per flow-CC
> >>> contexts by prioritization on manipulation of the cwnd.
> >>> And the we also have, a not so detailed proposal/description, on how
> >>> the same can be achieved via scheduling (scream).
> >>> It should be ok to allow for different ways to implement coupling,
> >>> but we should then eventually have one document that describes both
> >>> solutions. Shouldn't we ?
> >>
> >> I think so. There is already (short, because it's so simple) text
> >> about scheduling in coupled-cc and we can extend that and make it
> >> stand out more clearly (now it's in the intro I think).
> >>
> >> Cheers,
> >> Michael
> >