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

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

OK, understand. 

No hard feelings from my side if the scheduling details are removed from the SCReAM draft (and possibly put elsewhere), it is currently only an appendix section anyway. 

I think however the scheduling it will remain in the running code (C++ code and OWR) at least until a good alternative is available.

/Ingemar


> -----Original Message-----
> From: Michael Welzl [mailto:[e-mail]]
> Sent: den 24 juli 2015 10:57
> 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
> 
> No.
> 
> Our algo lets you assign priorities, and they are valid at the time you set
> them, they just give you a portion of the overall rate and it applies as soon as
> you set it.
> If  you want to adjust priorities based on the coder output rate variation, you
> can implement this using our algo or with a scheduler. A scheduler operates
> per packet, we operate per time, so implementation-wise it's a bit different.
> 
> My point is only: whether you do it with our algorithm or without a
> scheduler, I think this should not be in our draft  (and I'm neutral about:
> should it be in the SCReAM draft or separate from it).
> 
> Cheers,
> Michael
> 
> 
> > On 24. jul. 2015, at 10.42, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > 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
> >>>