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

[Zaheduzzaman Sarker <[e-mail]>]

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.