[R-C] BoF Scope of work

[John Leslie]

> 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 at 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 at jlc.net>