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

[Mirja Kühlewind <[e-mail]>]

Hi Zahed,

see below.

On 14.07.2015 10:51, Zaheduzzaman Sarker wrote:
>
>
> 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.

Okay, I think I'll have some time on Tuesday. Let's discuss Sunday, when we are 
going to work on 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?


For me personally it would be more important to have the same terminology and 
also the same variable names if things are really exactly the same thing in the 
drafts, than having a framework document. Also, if the drafts 'speak the same 
language', it should be easy to write a framework document.

As a chair I'd actually like to publish the current proposal as experimental 
RFCs as stand-alone documents. While if we end up to actually publish more than 
one scheme as standard track, I think it would be useful to have one framework 
document where we describe all similarities and potentially also discuss when to 
use which scheme... but that's for the working group to decide later on.

Mirja


>