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

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

It was/is not our prime intention to go through different  scheduling can be used. We described a simple way of doing prioritization in the scheduler.

Regarding moving into a common draft with other solutions, I don’t have any strong opinion about it but seems like a reasonable thing to do if RMCAT is going to produce a single document describing alternatives. The stream prioritization is already mentioned as an "additional feature" so separating that from SCReAM draft and just pointing to that the other doc should not be an issue.

BR

Zahed

> -----Original Message-----
> From: Karen Elisabeth Egede Nielsen [mailto:[e-mail]]
> Sent: den 20 juli 2015 07:32
> To: Zaheduzzaman Sarker; Ingemar Johansson S
> Cc: Mirja Kühlewind; [e-mail]
> Subject: RE: Review of draft-ietf-rmcat-scream-cc-01
> 
> 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.