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

[ken carlberg <[e-mail]>]

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