This package contains two kernels. 
2.1.129 (patched) to use as a router with RED + ECN  
capability and 2.0.32 to be used for an End system
capable of ECN.

INSTALLING:
----------

A: END SYSTEM
==============

Two ways to get started:
1) Grab the 2.0.32 kernel from 
http://www.kernel.org/pub/linux/kernel/v2.0/
and patch as follows (after untarring the kernel source):
a) go to one directory above the 2.0.32 source
b) cat patch-ecn | patch -p0

or 

2) You can retrieve a patched tar gzipped source included.
File linux-2.0.32-ecn.tgz.

Compiling ECN support in TCP:
----------------------------
The assumption is you know how to compile the kernel.
[You can get help on how to compile the kernel on many
Linux web sites. A good place to start is htttp://www.linuxhq.com]

At kernel configuration time make sure you select Network configuration.
When configuring network Options you will be presented with an option to 
select ECN; make sure you select it. You will also be able to select 
some ECN debugging if you wish to see some out put (intentionaly minimalized).
The debug output goes to /var/log/messages (you can also see view via the
dmesg command or on the console).


B: Router SYSTEM
================
You will need an RED+ECN enabled router in the middle.
You can either use:

1)A BSD box with patches from Kenjiro Cho at:
http://www.csl.sony.co.jp/person/kjc/red/perf.html

2) a) A linux box with at least kernel 2.1.129 with RED+ECN
turned on.
Since 2.1.* is an experimental kernel it is safer to use the
kernel sources i supply. They are other patches other than
ECN which are included.
[Included tarred gzipped file: linux21.ecn-router.tgz]

b) the tc utility to configure the kernel 
It is safer to also use the tc utility supplied in the package
since i dont remember what else i changed.
[A simple setup script is included for RED+CBQ with ECN implied;
File tc.script.sample]

POST-INSTALLATION
===================

Included also are patched sources for tcpdump which will dump
ECN related bits for debugging.
You may also want to edit (2.0.32) the files linux-kernel/net/ipv4/ :
tcp.c, tcp_input.c, tcp_output.c
and define CONFIG_ECN_DEB2 to 1 for more debug outputs.

GENERAL COMMENTS:
----------------

I am planning to port this code to the 2.1.* kernels Real Soon Now
(i have already started looking at it).
[Thats why it is not in even the latest 2.0.* kernel]
*** For any comments, queries, feedback email hadi@nortelnetworks.com


CONFORMANCE TO THE DRAFT/IRFC
=============================

Section 6.1.1: TCP initialization
==================================

1) When a node sends a TCP SYN packet, it may set the ECN-Echo and CWR
   flags in the TCP header.

DONE: 

2) When a node sends a SYN-ACK packet, it may set the ECN-Echo flag, but
   it does not set the CWR flag.

DONE: set the CWR flag as well.

3) If you receive a SYN-ACK packet with both ECN-Echo and CWR flags
set you know that the other side is "lying" that it is capable
of ECN. 

DONE.

Section 6.1.2: TCP sender
==================================

1) If the sender receives an ECN-Echo ACK packet  ...
it halves the congestion window "cwnd" and reduces the slow start
threshold "ssthresh". 

DONE:

-set ssthresh to max( 2, min(cwnd,packets-in-flight/2))
-half cwnd to a minimum of 1

2) The sending TCP does NOT increase the
   congestion window in response to the receipt of an ECN-Echo ACK
   packet.

DONE

3) The TCP sender's congestion window should be reduced only once 
   in response to a series of dropped and/or CE packets from a single 
   window of data.

DONE:

All ECEs are ignored untill all inflight packets are ACKed.

4) The TCP source should not decrease the slow-start
   threshold, ssthresh, if it has been decreased within the last round
   trip time.  

DONE: 
Conformance in the FR only (even when we retransmit a packet even
when we retarnsmit after 3 dupACKs). 
Probably not quiet to the spec in the draft.
The RTO code would still cut the ssthresh.


5) If any retransmitted packets are dropped or have the CE bit set, 
   then this is interpreted by the source TCP as a new
   instance of congestion.

DONE: 
Affects both the case of a FR or a retransmit due to an RTO.
- if a packet is retransmitted as a result of a timeout or FR, set
the marker of "next response to ECE" to be at the receipt of an ACK 
covering  the retransmitted packet(i.e ACK# >= retransmitted-seq-no). 
This way if an ECE is received in that ACK, we are able to react again.

Section 6.1.3: The TCP receiver
==================================

1) When TCP receives a CE data packet at the destination end-system, the
   TCP data receiver sets the ECN-Echo flag in the TCP header of the
   subsequent ACK packet.

DONE:

2) After the receipt of the CWR packet, acknowledgements for subsequent
   non-CE data packets do not have the ECN-Echo flag set.

DONE:

3) If there is any ACK withholding implemented,
   as in current "delayed-ACK" TCP implementations where the TCP
   receiver can send an ACK for two arriving data packets, then the
   ECN-Echo flag in the ACK packet will be set to the OR of the CE bits
   of all of the data packets being acknowledged.

DONE: 

4) When an ECN-Capable TCP reduces its congestion window for any reason
the TCP sets the CWR flag in the TCP header of the first data packet sent 
after the window reduction.

This happens in three locations of the sender code:
i) RTO ii) Fast recovery iii) Receipt of a new ECE


DONE:


5) If that (CWR) data packet is dropped in the network, then the sending TCP 
will have to reduce the congestion window again and retransmit the dropped
packet.  Thus, the Congestion Window Reduced message is reliably
   delivered to the data receiver.


DONE: 

CWR is sent only in packets with data. The retransmission effect of
RTO takes care of reducing the congestion window. 

6) If another CE packet is received by the data receiver, the receiver 
would once again send ACK packets with the ECN-Echo flag set.

DONE: Kind of a redundant statement since it re-iterates 1)
Here just for clarity.

7) When sending pure ACKS turn off the ECT bit.

DONE:
