Subject: Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental

From: Sally Floyd <[email-masked]>
Date: Thu, 12 Dec 2002 15:25:06 -0800

>The only reason to go to draft standard is if things CURRENTLY break 
>worse without this mod than with. Otherwise, the track should be via 
>Experimental first.

I would disagree with this.  

For things that are completely up to the implementor (e.g., larger
initial windows, byte counting), and for things that might be
implemented with one of several algorithms, with rather complex
tradeoffs (e.g., mechanisms for dealing with spurious timeouts),
it makes a lot of sense to me to go Experimental first.

But I think the ECN Nonce draft is in a different category.  We
already made the decision, in the standardization process for RFC
3168, to use the extra ECN codepoint in the IP header for a second
ECT Codepoint, specifically for use with the ECN Nonce,
and that is now Proposed Standard.

The ECN Nonce draft in question describes the mechanism for getting
the nonce info from the TCP receiver to the TCP sender, and for the
TCP sender to check the nonce info.  This is reasonably straightforward
and uncontroversial, I would say.  The ECN Nonce draft leaves the
question of the sender's response to an incorrect nonce as a matter
of policy.

One way that the ECN Nonce is different from larger initial windows
or byte counting or mechanisms for dealing with spurious timeouts
is that I believe that we (the IETF) would like to *actively encourage*
implementors to implement the ECN Nonce for TCP, if they are going
to use ECN (without using any "MUST" language, however).

This is not really the case for larger initial windows
or byte counting or mechanisms for dealing with spurious timeouts;
implementors are free to implement these things if they find them
useful, but if they don't, that is ok too.

The only reason that I could think of for the ECN Nonce draft to spend a
period first as Experimental would be that we don't have much
operational experience with TCP's use of the nonce, and there could
always be surprises down the line (as we have learned, there is no
telling what middleboxes and firewalls and normalizers do with
things like ECN fields in TCP and IP headers).

But my preference would probably be for this one to go straight to
Proposed.  In particular, it would be nice for implementors to use
the ECN Nonce when/if they add ECN capability to their TCP stack,
in my view.  To my mind, this fits Proposed Standard better than
it fits Experimental.  (Proposed Standard does *not* mean
end-of-the line...)

- Sally

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Dec 2002 21:57:47 -0800

> I would disagree with this.  
...
> question of the sender's response to an incorrect nonce as a matter

I read this as "things will break".

Anything that creates breakage, IMO, should be tested first. Especially 
in the absence of - as state above - evidence that things are currently 
MORE broken without it.

That still sounds like an experiment. Calling it anything other than 
experimental requires some operational experience first, not merely:
	- thought experiment
	- consensus
	- lack of controversy

Joe