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

[Ingemar Johansson S <[e-mail]>]

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
>
>==================================================