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

From: Zaheduzzaman Sarker <[email-masked]>
Date: Tue, 5 Mar 2013 14:13:22 +0100

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 +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
[email-masked]
www.ericsson.com

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

---

From: ken carlberg <[email-masked]>
Date: Tue, 5 Mar 2013 10:37:07 -0500

Hi Zahed,

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

bringing up the terms "long-lived" and "short lived" triggered an outside the box thought on the topic.  Do you think its reasonable ro feasable to use numbers associated with average call/flow duration as a point of reference of what is considered a "typical real-time flow"?  Part of the reason that I bring this up is that I understand that one (maybe more) popular VoIP applications starts with a rather aggressive offered load, and then after some period of time (versus actual feedback) the application backs off to some target measure that takes into account accumulated path characteristics (eg, delay, loss).  Perhaps the time delay is to avoid oscilation.

One can argue that the initial stage of such an approach is not fair, or its excessively greedy (for lack of an alternative term), but that perhaps over time, or an average call/flow duration, it is fair.  I've seen numbers that range from 1.8 minutes to 4 minutes in average call duration, and so perhaps this could be a target reference point to gauge how nice various algorithms work with each other.

-ken

---

From: Randell Jesup <[email-masked]>
Date: Sun, 10 Mar 2013 09:08:08 -0400

> One can argue that the initial stage of such an approach is not fair, or its excessively greedy (for lack of an alternative term), but that perhaps over time, or an average call/flow duration, it i…

An initial burst at a higher rate may help in some cases (force existing 
TCP flows into backoff), but can only do so by generating enough delay 
right at the start of a connection to fill the bottleneck and force 
loss.  So it won't do that - but it will allow a call to function "well" 
from the start if there is unused (typically local) bandwidth, whereas a 
classic slow-start may lead to a poor start-of-call experience.

In the past, I used bandwidth availability history (and user settings) 
to select an initial bandwidth I believed was below the likely 
available, since I wanted good startup quality with minimal chance of 
getting behind-the-ball.  A balance; as usual there's no "right" solution.

-- 
Randell Jesup
[email-masked]