[R-C] BoF Scope of work

[Jim Gettys]

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 at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion