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

[Zaheduzzaman Sarker <[e-mail]>]

On 2015-07-14 09:24, Ingemar Johansson S wrote:
> Hi Mirja and thanks for your comments, answers inline marked with [IJ]
>

>> And two more high-level/general comments on (the structure of) the
>> document:
>>
>> 1) I think the algorithm is now well understandable with the code and
>> respective explanation (expect the end of section 4.1.3 needs more
>> explanation as just mentioned above). I would still like to propose some
>> restructuring. I think the readability can be much improved by some rather
>> simple restructuring using a model similar as in the LEDBAT draft: First give a
>> high level summarize of all steps that have to be performed ("For each
>> ACK/report the state on the delay and delay trend will be updated. If a loss is
>> detected the congestion window cwnd will be decreased strongly, otherwise
>> there are two operation mode: fast increase and regular operation. In fast
>> increase the goal is to reach a previous target value quickly applying an
>> multiplicative increase scheme, while otherwise a delay traget should be
>> maintained..."). Then give all the pseudo code structured into functions and
>> finally explain each function block in detail in an own paragraph. I already
>> have a good idea how this would look like and if you want to we can sit down
>> at the meeting and do this together.
> [IJ] I'd like to have some kind of sit together, unfortunately I cannot attend the IETF this time, perhaps some remote appear.in session or the like can be arranged in August.
As I will be attending Prague we can sit together and if remote 
participant can join perhaps Ingemar can also join. We can at least 
start the process. And thanks for the this.

>>
>> 2) Having reviewed NADA and Scream now basically in one go, I think the
>> used framework is very similar. If you look at your Figure 1 and the Figure 1 in
>> the NADA draft, I think I'm now basically able to do a 1:1 mapping. However, I
>> think in your picture it is wrong to have multiple video coder/rate
>> controller/queues shown because that indicates that there is only one
>> transmission scheduler and congestion controller for all transmissions, which
>> is not the case. If you remove that part, there is only one difference left
>> between the two images and that is that there is an input from the
>> congestion control to the video rate controller in NADA which you don't have
>> (also see comment 2 above).
> [IJ] We can probably remove the example with multiple videos if it makes things more simple, but fact of the matter is that SCReAM can handle multiple sources.
>
>
> 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?

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

==================================================