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

[Mirja Kühlewind <[e-mail]>]

Hi Ingemar,

A quick comment here:

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

If the scheduling stays in the appendix, we definitely need to see evaluation 
results for Scream without scheduling. If scheduling is an essential part of 
Scream, you also need a shared bottleneck detection! Actually I guess we need to 
see evaluation results for Scream without scheduling in any case, because there 
might always be the case where the sbd does not detect a shared bottleneck 
correctly.

Mirja



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

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: [phone]
email: [e-mail]
------------------------------------------