Re: [ns] ecnecho() bit

["Huike (Victor) Li" <huike@ee.mu.oz.au>]

Thanks, Sally,

I'd like to add the ECN support to tcp-vegas, not only because I need it,
but also, my feeling to current Vegas verison in ns is that it can not
react correctly to ECN feedback.

But first, compare the very simple question, in tcp-reno.cc we have the
following
void RenoTcpAgent::recv(Packet *pkt, Handler*)
{
        hdr_tcp *tcph = (hdr_tcp*)pkt->access(off_tcp_);
#ifdef notdef
......
#endif
        ++nackpack_;
        ts_peer_ = tcph->ts();

        if (((hdr_flags*)pkt->access(off_flags_))->ecnecho() && ecn_)
                ecn(tcph->seqno());
if we printf the ecnecho() here we can get 0 or 1.

and in tcg-vegas.cc
void
VegasTcpAgent::recv(Packet *pkt, Handler *)
{
        double currentTime = vegastime();
        hdr_tcp *tcph = (hdr_tcp*)pkt->access(off_tcp_);
        hdr_flags *flagh = (hdr_flags*)pkt->access(off_flags_);

#if 0
.......
#endif /* 0 */
        ++nackpack_;
.....
        if (flagh->ecnecho()){
                ecn(tcph->seqno());
        };
if we printf ecnecho() here, it is always 0, that is, it can never get the
ecn bit.

both recv() derived from the same virtual recv(), and has almost the same
program to get the ecn, I really can not tell, why this vegas can not
work?

Can anyone take some time to shed some lights
Thanks,
Victor    



On Fri, 19 May 2000, Sally Floyd wrote:

> 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
> 
> 
>