[R-C] BoF Scope of work

Harald Alvestrand harald at alvestrand.no
Wed Jul 18 12:07:54 CEST 2012


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

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

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

My opinion.

                            Harald



More information about the Rtp-congestion mailing list