Re: [tcpPrague] Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching

[Bob Briscoe <[e-mail]>]

Michael,

Over the coming days / weeks, we will try to expose the vast numbers of 
experiments that have been done. And on real broadband equipment, in 
realistic traffic settings, etc. (the realism being for you to judge, 
not me)

Regarding running code, often at the time when a 'typical' BoF is held, 
there is some example or initial code, but not code for every proposed 
milestone. We are much further ahead than just initial code. But most of 
the "TCP Prague" safety aspects are still only a list of desires, not code.

To ensure I understand your concern,...
I assume even tho your email is as an individual, you are focusing on 
those aspects relevant to tcpm, which are all those safety points - 
mostly not implemented.
Or are you questioning the adequacy of the AQM code, the DCTCP code etc?

The problem here is that, if we were proposing a new WG, it would be 
normal to create a charter with a list of milestones, many of which 
would not have even been thought about in detail, let alone implemented. 
Milestones might be requirements documents, not protocol specs at that 
stage.

Nonetheless, because we are proposing to work across existing WGs, I 
accept we have to adapt to the norms of each WG. Nonetheless, even in 
TCPM, it is possible to start some work with a requirements doc, rather 
than a fully-tested implementation.

Also, part of this discussion is about whether WG norms need to be 
stretched to accommodate L4S work. Or whether a new WG is needed. For 
instance, when we discussed how to take L4S forward with the ADs (and a 
few very relevant WG chairs who happened to be in the Transport AD 
Office hours at the time), there was v strong consensus that we should 
avoid going off into an L4S huddle in a separate WG. And one of the ADs 
said we might have to consider widening the definition of "minor 
extensions" in TCPM's charter as a consequence.


Bob

On 19/05/16 13:54, Scharf, Michael (Nokia - DE) wrote:
>> The biggest question-mark is over tcpm. One of the reasons for showing the full list of possible work (even tho some isn't even started) is to:
>> * expose the potential load on tcpm {Note 1}
>> * enable discussion on whether the phrase "minor" in tcpm's charter would need to be nuanced to encompass minor changes that have major effects
>> {Note 1} Some of the deliverables would be brought to tcpm anyway, because they are important for all TCP-derived congestion controls, not just "TCP Prague".
>> For instance, the following two RTT-related items are particularly important for L4S/"TCP Prague", but they are also important updates to the base TCP cc [RFC5681] too.
>> 3-4) Scaling TCP's Congestion Window for Small Round Trip Times
>> 3-5) Reduce TCP / SCTCP / TCP Prague RTT-dependence
> Before speculating too much about the TCPM charter, I believe that running code and (realistic) experimentation would be an important starting point.
>
> Michael (as individual contributor)
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/