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

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

HI Ingemar, 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.

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.

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).

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 ?

I hope that this was somewhat understandable...

Thanks
BR, Karen


>-----Original Message-----
>From: Ingemar Johansson S [mailto:[e-mail]]
>Sent: Tuesday, July 14, 2015 10:16 PM
>To: Karen E. E. Nielsen
>Cc: Mirja Kühlewind; Zaheduzzaman Sarker; [e-mail]
>Subject: SV: Review of draft-ietf-rmcat-scream-cc-01
>
>Hi Karen
>Your interpretation of the SCReAM multistream handling and transmission
>scheduling is correct. And as such it resembles SCTP (with NDATA) or QUIC
>(with the addition of support for unreliable delivery) very much
>
>Ingemar
>
>Sent from Moxier Mail
>(http://www.moxier.com)
>
>
>----- Ursprungligt meddelande -----
>Från: Karen Elisabeth Egede Nielsen <[e-mail]>
>Till: Zaheduzzaman Sarker <[e-mail]>, Ingemar
>Johansson S <[e-mail]>, Mirja Kühlewind
><[e-mail]>
>Kopia: "[e-mail]" <[e-mail]>
>Skickat: 2015-07-14 14:08
>Ämne: RE: Review of draft-ietf-rmcat-scream-cc-01
>
>
>
>HI,
>
>>> Other than that the mapping would be the
>>>> following way:
>>>>
>>>> NADA
>>>> ---
>>>> Reference Rate Calculator    -> Network congestion control
>>>> Video Target Rate Calculator -> Rate Control
>>>> Sending Rate Calculator      -> Transmission scheduler
>>>> Encoder                      -> Video Encoder
>>>> Rate Shaping Buffer          -> Queue RTP packets
>>>>
>>>> I think it would be super helpful to use a common terminology here
>>>> for everybody to better understand similarities and differences.
>>> [IJ] Agree, if we can come up with some common terms, so much the
>>> better
>>>
>>This (and the previous comment from Mirja and Ingemar on similarity
>>between NADA and SCReAM) tell that common terminologies should be
>used
>>in the different candidate drafts for ease of understanding if the
>>terms are meaning the same things. We had a plan to have a framework
>>document in RMCAT. Will that help?
>>
>[Karen ] Yes I think that can be a good idea, but I am not sure that the
above
>mapping of terms is right  - or is it  ?.
>I very likely can be mistaken, but with screams multiple stream view then
I
>have thought that the following was the case:
>
>Scream Transmission scheduler is in fact a true transmission scheduler as
it
>takes packets from the multiple RTP queues and schedule the packets
>(following whatever multiple-stream scheduling policy/stream priority
>relevant)
>for consummation of the global sending rate/the congestion window
>calculated and thus transmit the packets on the UDP socket (after which
they
>eventually will go to the NIC for transmission). I further had assumed
that
>pacing (vis-à-vis cwnv) in this design is implemented as part of the
>transmission scheduler and not as part of the RTP queue logic.
>This model at least corresponds to SCTP's model for scheduling of the
multiple
>streams for consummation of CWND and transmission.
>
>BR, Karen
>
>>--
>>Zahed
>>
>>==================================================
>>ANM ZAHEDUZZAMAN SARKER
>>
>>
>>Ericsson AB
>>Services, Media and Network Features
>>Laboratoriegränd 11
>>97128 Luleå, Sweden
>>Phone [phone]
>>Fax [phone]
>>SMS/MMS [phone]
>>[e-mail]
>>www.ericsson.com
>>
>>==================================================