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

[Randell Jesup <[e-mail]>]

On 3/5/2013 10:37 AM, ken carlberg wrote:
> 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.

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
[e-mail]