Re: [ns] ecnecho() bit

[Sally Floyd <floyd@aciri.org>]

Well, the story is that options added to TCP are not necessarily
implemented in all of the many TCP modules in NS.

ECN has been validated in NS for the following TCP modules:
(one-way) Tahoe, Reno, Newreno, Sack1.  (These are generally the
only TCP modules that I contribute to myself.)  The ECN validation
test that validates ECN in Tahoe, Reno, Newreno, and Sack1 can be
run in tcl/test with the command "./test-all-ecn".

ECN support is included in some form in the two-way TCP modules
for Tahoe, Reno, Newreno, and Sack1, but it has not been validated
with a validation test, and I therefore can't attest to its current
condition.

I don't know about the state of ECN support for the other TCP
modules in NS (e.g., tcp-abs.cc, tcp-asym-fs.cc, tcp-asym.cc,
tcp-fack.cc, tcp-fs.cc, tcp-int.cc, tcp-rbp.cc, tcp-vegas.cc,
tcp-session.cc, ...).  I don't maintain any of these modules, and
I have not added ECN support to them myself.  But if anyone wanted
to add ECN support to any of these modules, and send it in with an
accompanying validation test the equivalent of the other validation
tests in "test-suite-ecn.tcl", I would be happy to verify the
validation test, and check the changes into the NS distribution...

(My own opinion is that it would be unrealistic to require that
someone would have to update and validate all of the TCP modules
before adding an option to one of the TCP modules in NS.  And the
inevitable consequence is that TCP options and such will not
necessarily be included in all of the TCP modules, and will be
added to each module as someone wants to use it and is willing to
do the work to add it to that module.  This seems ok to me.  The
ultimate authority for what is in NS lies in the validation tests
- anything that is not validated in some validation test should only
be used with the highest degree of skepticism, in my opinion.)

- Sally