[dccp] a bug in the TFRC code in NS

[Sally Floyd <floyd@icir.org>]

Just in case this is relevant for anyone, I just fixed a major bug
(of mine) in the NS code in NS.  The bug was introduced nearly a
year ago, and resulted in TFRC being way too aggressive under heavy
packet drop rates.  

Such a drag.  My apologies...

- Sally
http://www.icir.org/floyd/


------- Forwarded Message

Date:    Tue, 28 Oct 2003 14:43:49 -0800
From:    Sally Floyd <floyd@icir.org>
To:      John Heidemann <johnh@isi.edu>
cc:      Kun-chan Lan <kclan@isi.edu>,
	 Gwyn Chatranon <gwync@mail.sis.pitt.edu>, Zhijin Wang <sogra@ust.hk>,
	 wklin3@ie.cuhk.edu.hk, Summer <summer80211@hotmail.com>,
	 "ns-users@ISI.EDU" <ns-users@ISI.EDU>
Subject: Re: [ns] [bug] TFRC is * not friendly * to TCP in NS-2.26 

>Sally, did you see this on ns-users?
>Is trfc covered by a test suite?

Thanks for the report.  It is definitely a bug with setting
numPkts_ > 1 in Agent/TFRCSink.

I have some old mail from Wing-kai Lin reporting this problem,
and unfortunately I am just managing to look at it.

I am going to fix it for now by setting numPkts_ back to 1 by
default, in ns-default.tcl.   

The default for numPkts_ was changed to 3 on 12/16/02.

Unfortunately the bug is pretty serious, in that with the bug,
and with numPkts_ set to greater than 1, and with frequent
packet drops, TFRC can completely ignore loss events.

My apologies for this.  I understand that it is a gigantic
drag...

- Sally
http://www.icir.org/floyd/
--------------------------------------------------------------------

I didn't catch the bug with numPkts_ > 1 in part because
I haven't run simulations with TFRC in the last year.
The validation test, test-suite-friendly.tcl, has the following:
 
  Agent/TFRCSink set numPkts_ 1
  # The default for numPkts_ will be changed to 3, at some point.
  
and there are only a few validation tests that test other values
for numPkts_:  
 
./test-all-friendly delayedTFRC
./test-all-friendly delayedTFRC1
./test-all-friendly delayedTFRC2

The validation tests showed that with numPkts_ > 1, TFRC did much
better in the presence of reordering.  Unfortunately, I didn't
run validation tests to investigate how numPkts_ > 1 performed
in the *absence* of reordering.


------- End of Forwarded Message


_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html