Re: [tcpPrague] Experimental dual-queue ECN

[Gorry Fairhurst <[e-mail]>]

Since this is TCP-Prague, I'm speaking here only as an author of the ABE 
spec...

On 24/06/2016 18:01, John Leslie wrote:
> Spencer Dawkins at IETF<[e-mail]>  wrote:
>> ...
>> I would support publication of these algorithms as Experimental, if that's
>> what is proposed.
>>
>> Are you thinking the experiment is, that devices on the public Internet are
>> upgraded to provide this new functionality even if they aren't
>> participating in the experiment, and then this new functionality is then
>> experimented with, and the result of the experiment might be "now we know
>> why that's a bad idea, so we're not going to standardize it", so then the
>> devices revert to previous functionality?
>     I can't answer that part.
>
>> The way I thought this worked was that when you experiment with a
>> standards-track protocol, the Experimental RFC is supported only by
>> devices that are participating in the experiment, and the Experimental
>> RFC doesn't update the standards-track RFC(s) until the experiment
>> succeeds, and then the Experimental RFC is republished as a standards-
>> track RFC that updates the previous standards-track RFCs.
That seems correct to me.
>> If you decide
>> the experiment is a bad idea, only devices that opt in to the experiment
>> need to revert to previous functionality.
>> Are you thinking that wouldn't work here?
>     IMHO, such a path to  update RFC 3168 is impractical.
>
>     At 62 pages, RFC 3168 simply covers too much territory. It covers both
> the behavior of ECN-capable forwarders and the behavior of TCP senders
> and receivers. (Fortunately, it doesn't try to cover the behavior of
> non-TCP transports.)
>
>     At the time it was written, it really wasn't practical to cover less
> territory. But today, we understand that even TCP transport is entirely
> too broad a topic.
>
>     IMHO, we need to break off a limited part of it for Experimental
> protocols:
> 1. that reaction to ECN-CE should be the "same as" drop; and
I disagree of course - the CE-marking proposal has already been 
discussed at the IETF - and I suggest no ECN is likely to be found using 
RED - and ECN-marked RED is now anyway now deprecated. Many modern AQM 
methods CE-mark on a shallow queue - and I think we need to update the 
PS to reflect this.

I also don't see a specific experiment that is needed here  - what would 
be needed to test for safety in deployment? I *think* particular update 
can be taken directly to PS.
> 2. that ECN(1) MAY request marking for a lesser degree of congestion than
>     ECN(0).
That to me requires two changes - a standards action to address the 
current ECN PS requirement that the two codepoints (i.e., ECT(0) and 
ECT(1) are treated the same in the default DS class.

*AND* followed by an experimental proposal to use something different 
and obsolete the ECN-NONCE.

To me though, these are both TSVWG concerns - discussion should be taken 
on that list.
>     This needs justification; and I believe we can give ample justification
> without setting on _just_ dual-queue. Surely you've noticed there's
> already a separate proposal for differing treatment of ECN-CE.
>
>     I'm hoping we can agree that both experiments can co-exist...
If you refer to TCP's recation proposed in ABE (now a draft in TCPM), as 
a co-author I would suggest that these two experiments (and their usage 
if they continue) can co-exist. We have spoken to Bob and Koen on this 
topic.
>     And even if _both_ experiments are declared a failure; the principle
> of allowing differing requests and differing reactions is still 100%
> valid.
Indeed, until a PS is published.
>     Your concern about backing out of an experiment is 100% correct.
>
>     My preference is some kind of registration scheme to state which
> senders and which forwarders are implementing an experiment. Registration
> is conceptually simple; but associating senders with forwarders remains
> challenging. IMHO, we need not solve that: it's sufficient to leave that
> question to those who propose a particular experiment.
>     Unfortunately, we have to deal with human beings to design experiments.
> It is up to those who review the proposals to keep pressure on those
> volunteers to distinguish their eventual aims from how to conduct and
> evaluate experiments.
>
>     IMHO, if we ask each experimental-track writer to solve that in addition
> to designing the intended end-state _and_ how to modify RFC 3168, we're
> inviting failure.
>
>     Obviously, YMMV; but I think I owe it to you to provide whatever advice
> I can.
>
> --
> John Leslie<[e-mail]>
I can see we need to think about how to manage experiments and that 
there could indeed be lots of possibilities about how to manage the 
ECT(1) codepoint usage. I think your proposal should probably be 
analysed (at least discussed) if (hopefully when) TSVWG decides to allow 
experimental use of that codepoint.

Gorry