Subject: Re: Internet Draft on Explicit Congestion Notification

From: Sally Floyd <[email-masked]>
Date: Wed, 19 Nov 1997 16:17:22 PST

I am forwarding this email that I sent to [email-masked],
since it reiterates the open question raised by Alessio
about whether bits (one or two) should be added to IPv4 for ECN.

The issue of ECN spans several working groups and research groups,
and the current understanding of what part of the discussion would
take place where is as follows:

ipng: decisions/details of allocating ECN bits in IPv6
int-serv: decisions/details (if any) of allocating ECN bits in IPv4
tcplw or tcp-impl: defining TCP options for ECN (**if** any ECN bits 
  are allocated in IP)
tcpsat: discussions of relevance for TCP over satellite
end2end-interest: general discussions of research issues relating
  to ECN, including the general discussion of the relative merits
  of one bit vs. two bits in the IP header.

- Sally

------- Forwarded Message

To: [email-masked]
cc: [email-masked]
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.

------- End of Forwarded Message