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

From: Kacheong Poon <[email-masked]>
Date: Thu, 12 Dec 2002 22:39:17 -0600 (CST)

Included message from Mark Allman <[email-masked]>:

>----
>I think this document should go forward as a proposed standard
>rather than experimental.
>
>I see the role of experimental as for things that we are just not
>sure about.  The recent byte-counting I-D is a good example.  From
>everything we know about it, consensus seems to be that it should be
>OK.  But, it seems to me that the change is non-trivial enough and
>the direction of the questions are in the behavior of TCP in shared
>networks and what sorts of effects the change will have on traffic
>patterns.  So, going through a period of experimental status seems
>fine and prudent to me.
>
>But, it seems to me that the ECN nonce is pretty straightforward.  I
>have good confidence that it will not fail in ways that are unsafe
>to the global network.  Of course, there is always the possibility
>of unforeseen interactions, but my own opinion is that the nonce is
>ready for proposed standard (which is not a full standard and we can
>still tweak things later).
>----

I guess it is better to be experimental.  ECN nonce being
straightforward does not necessarily mean that IETF should
encourage it to be implemented.  First, it uses up one "precious"
TCP reserved bit.  Is there a consensus that ECN nonce is
very essential in deploying ECN or it has great benefits to
other things that the NS bit is justified?  I'm afraid that
it may be quite complicated to "remove" this use of the bit later
if we find that there are other more important use of it.  I am
not saying that we should actively discourage the use of those
reserved bits.

One justification of ECN nonce is that it has a high probability
to catch misbehaving receivers and middle boxes.  But is this
a high enough risk for ECN deployment if they are not caught?  It
seems to me that a misbehaving ECN sender may be more of a risk (-:
And afterall, RFC 3168 has two sections to discuss this, and
concludes that it is not a big enough threat to deter ECN deployment.

As mentioned in the Interactions of the draft, ECN nonce
does not work well when PMTU discovery is disabled.  And many sites
do disable that to reduce the risk of not being able to communicate
with their clients in case of broken middle boxes or interesting
network policy.  Because of this, when ECN nonce was discussed in
a previous IETF meeting, people agreed that ECN nonce was OK provided
that it was not required to be implemented along with ECN.  That
was a consensus.  It seems to me that making it a Proposed Standard
now contradicts with that consensus.  OTOH, making ECN nonce
experimental now does not prevent it to be changed to PS later.

Finally, my pure speculation is that making ECN nonce PS now may
actually hinder the wider deployment of ECN for fear of even
more compatibility issues...  It is better to be experimental
for now.

							K. Poon.

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