To: curtis@ans.net
cc: end2end-interest@ISI.EDU
Subject: Re: Internet Draft on Explicit Congestion Notification 
Date: Wed, 19 Nov 1997 16:06:20 PST
From: Sally Floyd <floyd>

Curtis -

>OK.  I agree that ECN for IPv6 and TCP is a good idea and that we need
>negociation in TCP and 2 bits in IPV6 and/or TCP.  Now what?
>
>How do we format the TCP option and where do we put the 2 bits?  Isn't
>the draft incomplete without this or is this just intended to be
>informational?

You are right, the current internet draft is not a complete detailed
proposal.

Our assumption is that the detailed proposal for formatting the TCP
option will be relatively straightforward, and can wait until after the
ECN bits are actually allocated somewhere.  As far as I know, the Area
Directors and Working Group co-chairs have not yet finally decided
whether the standardization of the TCP option (and accompanying email
discussion) would happen in tcplw (TCP Large Windows) or in tcp-impl
(TCP Implementers).

The question of where the bits would come from in the IP header is more
complicated.  The tentative plan for IPv6 had been that the IPv6 ECN
bits would come from taking two bits away from the 24-bit Flow Label
field.  This discussion (and decision) will have to happen in the ipng
working group.  (I gave a brief presentation about ECN to that working
group at the last IETF.)

The task of defining the TCP option, in our perception, is fairly
simple (and is defined in general form in the draft):  define an option
for ECN that is negotiated at TCP connection setup time, and define an
ECN-Notify bit in the TCP header to carry the ECN-Notification back to
the sender.  The work of translating the received ECN bits back to the
ECN Notify bit is straightforward.  (The main decision to be made
is whether to allocate an ECN-Notify bit in the TCP header (as recommended
in our draft) instead of using an ECN option to carry the ECN notification
from the receiver to the sender.  Not too earth-shattering...)

The new question is whether it would also be good to allocate ECN bits
in IPv4.  We did not originally consider this, because at the time it
did not occur to us that it would be a possibility.  The detailed
discussion of which IPv4 bits (if any) would be allocated for ECN would
have to happen in intserv, as these bits would "compete" with other
intserv proposals to use freed-up bits in the IP TOS and Precedence
fields.  (I am not up-to-date on all of the discussions on int-serv, and
quite honestly don't know whether there are likely to be one or two
bits in IPv4 for ECN or not.)  We are assuming that the general discussion
of whether ECN is or is not sufficiently compelling would happen on
end2end-interest.  Any feedback on this from the folks involved in the
intserv proposals will obviously play a part in whether we suggest that
IPv4 also consider ECN.

(I am writing something today to address the one-bit vs. two-bit
issue.  I personally don't have a preference; the one-bit and the
two-bit implementations would be functionally fairly similar.  There
are some who would argue that the two-bit approach is more robust, and
leaves less room for incorrect implementations.)

- Sally and K.K.