[tcpPrague] Experimental dual-queue ECN

[John Leslie <[e-mail]>]

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. 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
2. that ECN(1) MAY request marking for a lesser degree of congestion than
   ECN(0).

   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...

   And even if _both_ experiments are declared a failure; the principle
of allowing differing requests and differing reactions is still 100%
valid.

   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]>