On 07/18/2012 06:07 AM, Harald Alvestrand wrote:
My take on the BoF scope of work is fairly straightforward (I believe):
- We're preparing to deploy a new set of RTP applications on the Internet.
- There are Really Stupid Things that could happen if we don't do congestion control: - Internet Congestion Collapse (transmitting lots of packets and getting no useful throughput) - Random self-unfairness, where some channels in an app get good quality and other channels get bad quality, independent of what the app would prefer - Random unfairness to others, where you can't predict the behaviour of the call or of others' traffic even when you know the conditions it's operating under - I'm sure this list could go on for a while....
- Most previous deployments were (in practice) closed systems, and could do proprietary things. This one is intending to be open-standars-based, and depends on interoperability.
Thus, the focus of the WG that comes out of the BOF should be on:
- Getting something documented publicly that, if we all do it, prevents the most abysmally Stupid Things - Getting metrics defined that let us diagnose whether we're in trouble or not - Getting feedback from actual deployment that allows us to figure out whether we need to improve
I think the "diagnosis" topic is very, very important. If people don't know where the problem(s) is(are), they are going to stumble in the dark, as we have for a decade. Without customer pressure to fix problems, they won't get fixed.
Note that the word "optimal" doesn't occur in the above. We should stop being Really Bad before we worry about being Really Good.
(The fact that we're piggybacking deployment on the modern browser product cycle has certain advantages: Essentially, we can replace the entire installed base over a timescale of months. So the stuff that we learn from the first experience (which will certainly arrive ahead of an IETF-process-timescale standard!) can be fed back into the next generation of product fairly quickly.)
Unfortunately, the cycle of deploying broadband gear and routers is much longer. To fix WiFi for real is still going to be a year or two of effort (the Linux driver stack is much more complex, and less amenable to doing AQM of any form than ethernet is). However, at least those in the working group can/should be using routers that are able to do CoDel so we can tell how things will be behaving when they do deploy in numbers.
In my opinion, the BoF scope of work is to nail down the charter for the WG that allows us to accomplish this. The architectural issues, half-baked ideas and orthogonal approaches (like "change the way queueing is done in the Internet") will all have been discussed in Saturday's IAB workshop, and lots of possible ideas for work in other parts of the IETF may be coming from that.
This BoF needs to focus on the WG charter for documenting "interoperable ways of avoiding stupid behaviour".
I'd add "when possible", as you can't engineer yourself around complete brokenness, and we have a lot of complete brokenness right now.
My opinion.
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion