On 7/17/2012 12:10 PM, 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.
In fact, harm to RTP occurs long before 100ms - if you're already near the limit or on the "slippery slope", even 20ms latency added will harm RTP (in fact, any extra latency harms it, and once past the knee, the harm is significant).
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.
Agreed, though I could envision downstream prioritization; either signaled or automatic. Whether this would be deployable/deployed is another question.
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.)
Agreed, though the main issue here is to come up with solutions that work now, when CoDel is partly deployed, and when CoDel is largely/fully deployed. Practically, this means a protocol for existing largely-tail-drop routers with (often) oversized buffers, which will also handle CoDel smoothly at the bottleneck node. (Unlike say LEDBAT which likely would revert to taking a full share if AQM is deployed.) -- Randell Jesup randell-ietf@jesup.org