[rmcat] Initial comments on draft-jesup-rmcat-reqs-01

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

Thanks to the author for updating the doc. This version has clarified 
couple of issues but still I think there is lot left to do for the whole 
group. My thoughts/comments below-

General :

# I think  it will be very good if the document includes some 
explanation text on why one particular requirement is listed. Those who 
are involved in the discussion from the very beginning perhaps 
understands the reasons but still I think it will be nice thing to add 
(to reduce latecomer effect :-)).

# Now, we will have to decide on the "fairness" (everybody's favorite, 
right?). Yes, it is difficult and yes, we can spend huge amount of time 
discussing on it. However, IMHO the discussion should short and we 
should just pick one that is available or define something ( for 
example, something that Harald had mentioned in one of IAB CC workshop 
paper).

# This draft should somewhere mentioned the circuit breaker draft. I 
would even say that it should be a requirement on the RMCAT Congestion 
Control (CC) algorithm that it works "within the envelope" of circuit 
breaker.

# The applications that will use RMCAT solution for congestion control 
may need to have a way to configure certain behavior related to the 
service it provides. For example, the application may like to set the 
MIN and MAX bitrate rate, certain behavior if the MIN bitrate is not 
sustainable even if after adapting rate etc. How would we like to 
realize this? One way is to , set the MAX and MIN rate as configuration 
to the adaptation algorithm so that if it suggest , for example , 
bitrate to the application then it never goes above MAX and below MIN. 
Another way is to not set any limit to the CC algorithm and let it send 
feedback to the application on what will be the sustainable bitrate at a 
certain time and the application decides what to do with that feedback. 
The first one is perhaps the most commonly implemented approach while 
the second options gives lot of power to the application. Depending what 
we think is the right way to realize this, puts some requirements on the 
RMCAT CC algorithm. Requirement 1 touches upon it but it also created 
confusion in my mind and I think we can we a better job there.

Requirement Specific:

   * Req 4: it says "Extra information could be added to the packets to 
provide more detailed information on actual send times (as opposed to 
sampling times), but should not be required." I think it can say 
something like this "Extra information could be added to the packets to 
provide more detailed information to improve the performance of the 
algorithm but the algorithm should justify the additional information 
added". Then an algorithm can use, for example, actual send times 
instead of sampling times or something else to improve its performance 
or use something else.
   * Req 7: this is an important requirements. Very ofter I find papers 
where they kind of forget about the congestion in feedback channel.
   * Req 8: This requirement focuses on long-lived TCP flows but I think 
it should focus on flows with known congestion control algorithm. in the 
fast phase, RMCAT will publish (hopefully) more than one experimental CC 
algorithms and I think it is important to look how one of the candidate 
is behaving when competing with other candidate.  But if we want to 
focus on the behavior against competing TCP flows then the requirement 
should say "It should attempt to avoid bandwidth 'collapse' when facing 
a saturating TCP flow or flows but it should not starve TCP flow (should 
not grab more than necessary)" or something along this theme. And I 
would also like to get rid of the prefix terms "short-lived" and 
"Long-lived" TCP flow as I think from a congestion controller point of 
view it is hardly possible to distinguish between them unless we have 
some explicit information from the shared bottleneck.

So far, this is what i think.

BR

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER


Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone [phone]
Fax [phone]
SMS/MMS [phone]
[e-mail]
www.ericsson.com

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