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

[Zaheduzzaman Sarker <[e-mail]>]

On 2015-07-14 16:59, Mirja Kühlewind wrote:
> 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!
Ok.
>
>>
>>>>
>>>> 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.
My point of bringing the framework document is to have a place to
discuss what are the correct/appropriate terminologies to use. I believe 
everyone is comfortable with their own terminologies thus discussions 
are required to change some of them to
streamline the docs . Personally, I dont have issues with changing
the terminologies as long as we agree on the definitions.

>
> 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.
>
I agree with this view. Perhaps we can use the wiki to be a place
where we define the terminologies and then if required we can have them 
in a framework document.

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

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