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

[Michael Welzl <[e-mail]>]

+1

Michael


> On 11 Aug 2015, at 15:43, Ingemar Johansson S <[e-mail]> wrote:
> 
> +1
> Ingemar
> 
> Sent from Moxier Mail
> (http://www.moxier.com)
> 
> 
> ----- Ursprungligt meddelande -----
> Från: Karen Elisabeth Egede Nielsen <[e-mail]>
> Till: Ingemar Johansson S <[e-mail]>, Mirja Kühlewind <[e-mail]>, Michael Welzl <[e-mail]>
> Kopia: Zaheduzzaman Sarker <[e-mail]>, "[e-mail]" <[e-mail]>
> Skickat: 2015-08-11 15:20
> Ämne: RE: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
> 
> 
> 
> Hi,
> 
> In SCTP one uses the term scheduler and scheduling for the entity that
> selects chunks from the various streams and
> bundle them into packets that consumes the common CWND (and the RWND but
> that is a different discussion).
> 
> This effectively is a realization of coupled congestion control in-between
> the multiple streams of the one and the same SCTP association
> even if this is not called coupled congestion control.
> 
> The point indeed is that scheduling among multiple streams sharing the
> same congestion context/CWND calculation is one way of effectively
> realizing coupled congestion control .
> Here no shared bottleneck detection is needed as it is there by default -
> indeed the streams are using same UDP socket (here I assume same DSCP
> markings as well).
> 
> When the shared bottleneck is not evident and/or when multiple congestion
> contexts are maintained, e.g, one CWND for each stream or one CWND for
> each bundle of streams (where
> internally coupling within the bundle is achieved via scheduling
> principles) then SBD and coupled CC as defined in draft-hayes-rmcat-sbd-02
> and draft-welzl-rmcat-coupled-cc-05 is a necessary supplement.
> 
> BR, Karen (as an individual).
> 
> 
>> -----Original Message-----
>> From: Ingemar Johansson S [mailto:[e-mail]]
>> Sent: Friday, July 31, 2015 9:31 AM
>> To: Mirja Kühlewind; Michael Welzl
>> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; [e-mail]; Ingemar
>> Johansson S
>> Subject: SV: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
>> 
>> Errata... Should be "not convinced about the name change", thanks for the
>> heads up Zahed :-)
>> 
>> ...But if it is needed in order to get a common set of terms
>> 
>> Sent from Moxier Mail
>> (http://www.moxier.com)
>> 
>> 
>> ----- Ursprungligt meddelande -----
>> Från: Ingemar Johansson S <[e-mail]>
>> Till: Mirja Kühlewind <[e-mail]>, Michael Welzl
>> <[e-mail]>
>> Kopia: "Karen E. E. Nielsen" <[e-mail]>, Zaheduzzaman
>> Sarker <[e-mail]>, "[e-mail]"
>> <[e-mail]>, Ingemar Johansson S
>> <[e-mail]>
>> Skickat: 2015-07-31 0:30
>> Ämne: RE: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
>> 
>> 
>> 
>> Hi
>> 
>> The term transmission scheduler was taken from a discussion on the TCPM
>> WG (thread starts at http://www.ietf.org/mail-
>> archive/web/tcpm/current/msg08768.html ), the definition was borrowed
>> from TCP laminar. This means that I am currently convinced about the name
>> change.
>> The RTP packets from two or more streams (RTP queues) are in its simplest
>> form picked in a round-robin fashion. This is described in section 4.1.
> If
>> prioritization is desired then a credit based system is used, described
> in
>> appendix A.2. In reality the credit based approach is always enabled even
>> though no prioritization between streams is applied, in this case all
> streams
>> get the same priority.
>> It is imperative however that all streams are able to transmit RTP
> packets
>> frequently. This to avoid extra queueing delay on the sender side. With a
> 2:1
>> prioritization allocation, one stream gets to send 2 RTP packets, then
> the other
>> stream gets to send 1 RTP packet.
>> It is for instance not too practical to allow one stream to send for
> 100ms and
>> then let the other stream transmit for 50ms, this will only increase
> latency and
>> risk making the video choppy. This is the main reason why SCReAMs
> transmit
>> scheduling and prioritization operates is RTP packet transmission clocked
>> instead of timer based.
>> But...of course one can implement timer based prioritization with shorter
>> intervals, in which case the differences would be smaller, but for SCReAM
> it is
>> more practical to be RTP packet transmission based.
>> 
>> PS, deliberately omitted the fact than one (or even all streams) may have
>> nothing to transmit, this is handled in the code however.  For those
>> interested, it is possible to experiment with the C++ code to see how the
>> stream prioritization performs.
>> 
>> 
>> /Ingemar
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Mirja Kühlewind [mailto:[e-mail]]
>>> Sent: den 30 juli 2015 14:21
>>> To: Ingemar Johansson S; Michael Welzl
>>> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; [e-mail]
>>> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
>>> 
>>> Hi Ingemar,
>>> 
>>> okay thanks for the clarification. I discussed this with Zahed and the
>>> scheduler as described in section 4.1.2.2. should probably be renamed
>>> to something like sending rate controller because without the
>>> prioritization it's only handling one flow at a time, right?
>>> 
>>> Mirja
>>> 
>>> 
>>> On 30.07.2015 13:22, Ingemar Johansson S wrote:
>>>> Hi
>>>> 
>>>> Probably needs some clarification. The transmission scheduler that
>>>> decides
>>> when to transmit RTP packets is an integral part of SCReAM and
>>> described in section 4.1.2.2 in the draft.
>>>> Stream prioritization is applied when two or more streams share a
>>> congestion control and is described in section A.2.
>>>> 
>>>> The former has been evaluated earlier , the latter is only
>>>> exemplified in
>>>> https://github.com/EricssonResearch/scream/blob/master/SCReAM-
>>> descript
>>>> ion.pdf
>>>> 
>>>> The evaluation of stream prioritization leads to a set of follow-up
>>> questions. What kind of source behavior do be assume, is it CBR  or
> VBR.
>>> Stream prioritization of CBR sources is quite trivial to solve IMO,
>>> VBR is more complicated.
>>>> 
>>>> /Ingemar
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: Mirja Kühlewind [mailto:[e-mail]]
>>>>> Sent: den 30 juli 2015 12:32
>>>>> To: Ingemar Johansson S; Michael Welzl
>>>>> Cc: Karen E. E. Nielsen; Zaheduzzaman Sarker; [e-mail]
>>>>> Subject: Re: [rmcat] Review of draft-ietf-rmcat-scream-cc-01
>>>>> 
>>>>> 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]
>>>>> ------------------------------------------
>>> 
>>> --
>>> ------------------------------------------
>>> 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]
>>> ------------------------------------------