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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

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 ?

BR, Karen



>-----Original Message-----
>From: Zaheduzzaman Sarker [mailto:[e-mail]]
>Sent: Sunday, July 19, 2015 11:01 PM
>To: Karen E. E. Nielsen; Ingemar Johansson S
>Cc: Mirja Kühlewind; [e-mail]
>Subject: RE: Review of draft-ietf-rmcat-scream-cc-01
>
>Hi Karen,
>
>Please see inline.
>
>BR
>
>Zahed
>
>>
>> Reading the coupled congestion control draft and the app-interactions
>> draft I have come to wonder a bit about the multi-stream capabilities
>> of scream - or the in-build coupled congestion control of  scream, one
>> can
>say.
>>
>> The coupled congestion control of welzl-rmcat-couple-cc allows for
>> priority to be given to different flows managed by one couple
>> congestion control context (i.e. the flow identified as sharing the
>> same bottle neck) - and the app- interactions draft asks for the same
>> possibility to be provided. The scream coupled cc also allow for such
>> prioritization to be done in that such can be achieved by scheduling
>> priorities in between the multiple RTP streams that one CC context
>> serves (here scream model is the same model as sctp multi-stream cc
>follows).
>> HOWEVER what the  scream model does not directly allow for - as  far
>> as I can see - is prioritized coupling in between multiple RTP flows
>> that do not use the same UDP socket/connection tuple -- And then I
>> start wonder if the stream model is the right one.
>[Zaheduzzaman Sarker] I believe your interpretation of a scream controller
>controlling multiple RTP flows only with same "UDP socket/connection tuple"
>is coming from a previous reply where it was said the controller controls
>flows
>only towards same destination. I think the correct thing to say is, the RTP
>packet passing through the a scream transmission scheduler more of less
>showing same characteristics, like sharing same bottleneck. Hence if there
>is a
>system like SBD already allows multiple RTP flows with different
>destination to
>be identified as sharing the same bottleneck then prioritizations can be
>applied to all those flows by same transmission scheduler.
>In the implementation of scream there is a method to register a RTP flow to
>a
>scream controller which will be congestion controlled by the that
>particular
>scream controller (the transmission scheduler resides in the scream
>control).
>This also means the scream controller has to get the information from the
>RTCP feedbacks for the respective registered flows.
>Hence, your interpretation of " the scream model does not directly allow
>for
>prioritized coupling in between multiple RTP flows that do not use the same
>UDP socket/connection tuple " is not completely true.
>
>> Possibly one can see the scream model as introducing one more level in
>> the coupled cc model - i.e., prioritized coupling in between the flows
>> using the same UDP socket/UDP tuple is done by means of scream
>> transmission scheduling priorities and then coupled congestion control
>> following the welzl model on top of this, when more "advanced"
>> coupling or SBD detection is desired or relevant in between flows
>> sharing the same bottleneck, but not using the same UDP socket/UDP tuple.
>[Zaheduzzaman Sarker] SCReAM model does not simply assumes the
>existence of coupled-cc by default. As SCReAM already uses a transmission
>scheduler it is easy to implement "prioritization coupling" there.
>>
>> I suppose that it should be up to implementations how they want to
>> implement coupled cc and if they want a leveled approach as the one
>> just described or a more "direct" approach where each RTP flows is
>> handled individually from a CC perspective and the coupled via coupled cc
>(wezlz).
>[Zaheduzzaman Sarker] I believe for implementers do have a choice.
>However, if they decided to implement SCReAM they have an easy
>alternative for coupled-cc as Michael W himself says.
>>
>> On the other hand the one should understand what would be the
>> motivation for a leveled approach would be - also because it seems to
>> give a more complex model  - Is it so that such is motivated by - for
>> example:
>?
>>
>> * It is more efficient (overhead or protocol, state, whatever) to
>> manage CC on "one" multi-stream RTP basis when such is possible -  as
>> scream does ? and therefore the leveled approach has advantages from a
>> general perspective or possibly it is advantageous in the particular
>> situations where the default (build-
>> in) shared bottle-neck detection of scream is the only one relevant ?
>>
>[Zaheduzzaman Sarker] I believe I have already answered those questions.