On Jul 8, 2012, at 7:54 PM, John Leslie wrote: [snip]
] - there is a critical mass of participants willing to work on the ] problem (e.g., write drafts, review drafts, etc.). ] ] - the scope of the problem is well defined and understood, that ] is, people generally understand what the WG will work on (and ] what it won't) and what its actual deliverables will be.
This needs work. IMHO it will need work _at_ the BoF.
To be clear, I meant it will need work at the BoF whether or not participants on this list find a consensus before then.
Bob Briscoe wrote:
My personal opinion is that this w-g should be trying to solve the problem. And the problem has three halves: * RTP harming elastic * elastic harming RTP * network arbitrating between the two
John Leslie wrote:
Clearly the first needs to be in-scope for the WG.
IMHO the other two halves need to be discussed at the BoF.
"elastic harming RTP" might not be the right focus, exactly... When there is "TCP-friendly" elastic traffic at the bottleneck, it currently "harms" RTP traffic by driving up the delay. That much _needs_ to be understood to work on our problem at all. The "fault" isn't with the elastic traffic exactly: TCP congestion control depends on filling buffers to the point where packet loss occurs, whether by tail-drop or Active Queue Management or any other algorithm. In the "extreme," we call this buffer-bloat. But we only need about 100 milliseconds of buffer latency to perceptably "harm" RTP traffic. That much (IMHO) needs to be presented to the BoF. IMHO, it's a central part of the "problem" this BoF is convened to discuss. To some degree, QoS can help; the CoDel proposal could help a lot; possibly just a user-visible warning that competing traffic is driving up buffer latency would help. Or perhaps there's some different "mode" of RTP to switch to when latency grows too long... A BoF doesn't start with a charter -- it tries to draft a charter for a WG. The BoF starts with a problem statement and _possibly_ a proposed charter. IMHO proposing a charter is premature until the problem is better understood. "network arbitrating between the two" is quite close to the right focus. QoS arbitration is one appropriate way to do this. The RTP flow could request a particular bandwidth to go to the head of the queue at a point of congestion; but somebody would need to say how to do so, and there'd have to be equipment deployed to accept the request. This is practical if the congestion is only at the uplink from the customer to the ISP; but it may be less practical for congestion at the downlink from ISP to customer; and it's probably impractical for congestion somewhere in the middle. CoDel definitely deserves some discussion at the BoF. It would accomplish most of what QoS could promise without any need for a protocol to request dedicated bandwidth. It still needs deployment to routers where the congestion occurs; but IMHO such deployment is eminently practical for both uplink and downlink to the customer. (Deployment in the middle seems less necessary, but could follow _after_ the benefit is well demonstrated for the relatively few near-backbone routers that ever delay (as opposed to drop) traffic for 100 milliseconds.) "Mode" switching may well deserve some consideration in any case. (Separate arguments could be made for wireless-induced delay: I won't treat that here...) Michael Welzl <michawe@ifi.uio.no> wrote:
Your phrasing was "need to be discussed at the BoF", which I took to mean that we can't agree about these things beforehand.
I've already answered that, but I'm seeing less convergence than (IMHO) is needed. :^(
I think we can, and I think we should try.
I quite agree we should try... -- John Leslie <john@jlc.net>