[R-C] BoF Scope of work

[Randell Jesup]

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 at jesup.org