[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ns] TCP Vegas question/minor bug (?)



Hello again,

It seems I'm the only one interested in Vegas, but here's another thing that
seems odd... comparing tcp.cc (v. 117) and tcp-vegas (v 1.34) the output(...)
function has some code that doesn't make sense to me:


tcp.cc line 547:
----------------------------------------
    if (seqno > maxseq_) {
        maxseq_ = seqno;
        if (!rtt_active_) {
            rtt_active_ = 1;
            if (seqno > rtt_seq_) {
                rtt_seq_ = seqno;
                rtt_ts_ = Scheduler::instance().clock();
            }
        }
>   } else {
>       ++nrexmitpack_;
>       nrexmitbytes_ += bytes;
    }
----------------------------------------

As compared to:

tcp-vegas.cc line 459:
----------------------------------------
    if (seqno > maxseq_) {
        maxseq_ = seqno;
        if (!rtt_active_) {
            rtt_active_ = 1;
            if (seqno > rtt_seq_) {
                rtt_seq_ = seqno;
                rtt_ts_ = now;
>           } else {
>               ++nrexmitpack_;
>               nrexmitbytes_ += bytes;
            }
        }
    }
----------------------------------------

I know it's just the insignificant instrumentation code, but they can't *both*
be right. Shouldn't the else clause in the Vegas code be like that of the
Tahoe/reno/etc code, moved to the outer scope? I mean, retransmissions are
occurring when the sequence number transmitted is <= maxseq_, and don't have
anything to do with the round-trip time sampling. Moving the Vegas clause gives
what seem like correct numbers in my simulations.


Thanks!
-Eric

--------------------------------------------
 Eric H. Weigle   CCS-1, RADIANT team
 [email protected]     Los Alamos National Lab
 (505) 665-4937   http://home.lanl.gov/ehw/
--------------------------------------------