[ns] ns-2.1b8a Full-TCP ECN fixes

[Tom Kelly <ctk21@cam.ac.uk>]

It would appear that there are some potential problems with the FullTCP
ECN implementation in ns-2.1b8a mostly a lack of compliance with the
IETF proposed standard and RFC 2481 which is now being implemented in real
operating systems.

In particular:
- An ECN SYN packet should have ECE and CWR set.
- An ECN SYN-ACK packet should have ECE set and CWR not set.
- TCP ACKs should not have ECT set.
- On receiving an ACK with ECE set a receiver should not open the
congestion window.

A patch against tcp-full.cc and tcp-full.h which attempt to fix these
issues is available at:
http://www-lce.eng.cam.ac.uk/~ctk21/code/tcp-full.cc.ecn-fix.patch
http://www-lce.eng.cam.ac.uk/~ctk21/code/tcp-full.h.ecn-fix.patch

It should be noted that it breaks the regression tests, but my first pass
look at the errors suggest that the actual behaviour is right.

There is one outstanding issue regarding dupack triggered congestion
responses. In the code it seems carefully constructed that a
duplicate acknowledgement triggers a retransmit and cwnd reduction
even after an ECE caused a cwnd reduction in the same round trip time.
This seems to be at odds with the Proposed Standard:

"[pg19, draft-ietf-tsvwg-ecn-04]
   TCP should not react to congestion indications more than once every
   window of data (or more loosely, more than once every round-trip
   time). That is, 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.  In addition, the TCP source should not
   decrease the slow-start threshold, ssthresh, if it has been decreased
   within the last round trip time.  However, if any retransmitted
   packets are dropped, then this is interpreted by the source TCP as a
   new instance of congestion.
"

Maybe I've missed something, but the code looked deliberate so I haven't
tried to fix it.

Tom