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