Implementing ECN in TCP, Sally Floyd, January 1998.
- Sally Floyd

>Is there any agreement on what bit in the TCP header has to be used to
>echo the CE bit back to the sender.

The implementation from UCLA used bit 9 in the Reserved field - the bit
next to the Urgent bit.  That would make sense to me.


NEGOTIATING ECN-CAPABILITY BETWEEN THE SENDER AND RECEIVER:

The current proposal from Kenjiro Cho is as follows:

Node A on sending the TCP SYN packet sets the ECN-Echo bit (previously
called the ECN Notify bit) in the TCP header.  For a SYN packet, the
ECN-Echo bit is defined not as a return indication of congestion, but
instead indicates that the sending TCP is ECN-Capable.  More precisely,
a SYN packet with the ECN-Echo bit set indicates that that TCP
implementation will respond to incoming data packets that have the
ECN/CE (Congestion Experienced) bit set in the IP header by setting the
ECN-Echo bit in outgoing TCP ACK packets.

Similarly, for a SYN-ACK packet, the ECN-Echo bit in the TCP header is
defined as an indication that the TCP sending the SYN-ACK packet is
ECN-Capable.

An alternate proposal would be to define a new TCP option.
Node A would send the SYN packet with a TCP option indicating
that Node A is ECN-Capable, and Node B would do the same for the
SYN-ACK packet.

An earlier, third proposal would be for the end-nodes to use the
ECN-Capable (ECT) bit in the IP header to indicate that the TCP
implementations were ECN-Capable.  This approach would have
disadvantages if a router set the ECN/CE bit in the packet header of
the SYN packet, but the other end was in fact not ECN-Capable, and
ignored the ECN/CE bit.


WHY IS IT NECESSARY FOR TCPS TO NEGOTIATE ECN-CAPABILITY? 

Before a TCP can sent a packet with the ECT bit set in the IP header,
that TCP has to know that the TCP on the other end will send feedback
if it sees an incoming TCP data packet with the ECN/CE bit bit set.  It
would be a problem if one end of the TCP connection is ECN-capable, but
the other end is not.  What if node A sends TCP packets with the ECT
bit set, the router sets the ECN/CE bit, and node B on receiving the
packet does not know what this bit means?  Node B would not set the
ECN-Echo bit in the TCP header, and node A would never find out about
the congestion at the router.


PURE ACK PACKETS:


Current experimental implementations of ECN in TCP do not turn on the
ECN-capable bit for pure ACKs, as the use of ECNs for congestion
control on the "return" path is still a research issue.  One such
proposal is described on a paper on "The Effects of Asymmetry on TCP
Performance" by Balakrishnan, Padmanabhan, and Katz, listed on the ECN
Web Page.


OPEN QUESTION:  SETTING THE ECN-ECHO BIT IN THE TCP HEADER.

One question concerns TCP B's behavior on receiving a TCP data packet
with the ECN/CE bit set.  Should TCP B set the ECN-Echo bit in only
a single returning ACK packet?  Or, to be more robust against the
possibility of a dropped ACK packet, should TCP B set the ECN-Echo
bit in a series of ACK packets?

One possibility, suggested by Kevin Fall, would be as
follows:

1) When TCP B receives a data packet with the ECN/CE bit set,
TCP B sets the ECN-Echo bit in the returning ACK packet, and
continues to set the ECN-Echo bit in subsequent packets until
it hears that TCP A has reduced its congestion window.

(2) When TCP A reduces its congestion window for any reason
(because of a retransmit timeout, a Fast Retransmit, or in response to
an ECN Notification), TCP A sets the (new) Congestion Window
Reduced bit in the TCP header.  The Congestion Window Reduced bit is
only set on the first data packet sent after a window reduction.  If
that data packet is dropped in the network, then TCP A will
have to do another Congestion Window Reduction, and retransmit the
packet.  Assuming that the packet at some point gets through, the
Congestion Window Reduced message will at some point get through also.

It is possible that two messages could pass in the network, an
"ECN-Echo" message from TCP B to TCP A, and a "Congestion Window
Reduction" message from TCP A to TCP B.  This should not be a
problem.

TCP A already reduces its congestion window at most once per
window of data.  This proposal requires some care to make sure that
the sender reduces its congestion window at most once per ECN
indication, and that multiple ECN messages over several successive
windows of data are properly reported to the ECN sender.

One possible scenario would be that TCP B receives a data packet with the
ECN/CE bit set, TCP B sends ACK packets with the ECN-Echo bit set, and
TCP A sends an answering packet with the Congestion Window Reduced bit
set.  But the answering packet again gets the ECN/CE bit set.  So TCP B
continues to send ACK packets with the ECN-Echo bit set.  TCP A knows
that it sent data packet N with the Congestion Window Reduced bit set.
So when TCP A receives an ACK packet from TCP B acking packet N, but
still with the ECN-Echo bit set, then TCP A knows that it has to reduce
its congestion window one more time.