FW: [ns] bugs and fixes in FullTcp & Eifel

["Andei Gurtov" <andrei.gurtov@sonera.com>]

-----Original Message-----
From: Andei Gurtov [mailto:andrei.gurtov@sonera.com]
Sent: 5. syyskuuta 2001 10:20
To: Kevin Fall
Cc: ns-users@ISI.EDU; Reiner Ludwig
Subject: RE: [ns] bugs and fixes in FullTcp & Eifel



Kevin -

> Hi.  I've read over your suggested changes for the first three
> items and I have some concerns.

My intention was to inform the community about possible problems + make
quick fixes so that I continue my work. I din't mean that the fixes should
be
put to the release code as they are.

> 1> there may be some issue here wrt dupacks after RTO [which I am
> 	still thinking about], but to drop any dup ack just because cwnd
> 	is equal to 1 seems like it would be a problem at any other
> 	time you may have a cwnd equal to one (i.e. not only after an
> 	rtx timeout)

Hopefully the picture I have forwarded to you clarifies the problem. I agree
that dropping any dup ack just because cwnd equals to one is a hack, and
should be replaced by better solution. I still think it might be correct:
could we really benefit from DUPACKs unless with have had or going to have a
fast retransmit? But we cannot have fast retransmit if cwnd is one, can we?

> 2> if the peer is ignoring FIN+ACK just because it has the CWR bit
> 	turned on, it seems to me better to fix the peer rather
> 	than only selectively turning on this bit.  [although
> 	perhaps doing both may actually be more correct]

Sure.

> 3> it seems unlikely to me that you should have this problem given
> 	that the if statement above checks for a SYN and if found
> 	goes to dropwithreset.  Thus you should not be getting to the
> 	line you mentioned with SYN being turned on.  Did you
> 	mean FIN or something else perhaps?

Good point. It seems that this code is triggered when a SYN is
retransmitted.
After getting a duplicate SYN should the receiver reply with SYN-ACK or just
with ACK? Also in this trace I don't understand why SYN is retransmitted the
third time at 126007.947107. Maybe after all the original FullTcp code is
correct and such ACKs should be dropped?

126007.647107: FullTcpAgent::recv(_o19) got packet lacking ACK (seq 1)

+ 126000 0 1 tcp 50 ------- 0 0.0 1.0 0 17773 -1 0xa 50 0
+ 126006 0 1 tcp 50 ------- 0 0.0 1.0 0 17774 -1 0xa 50 0
- 126007.32044 0 1 tcp 50 ------- 0 0.0 1.0 0 17773 -1 0xa 50 0
- 126007.333774 0 1 tcp 50 ------- 0 0.0 1.0 0 17774 -1 0xa 50 0
r 126007.633774 0 1 tcp 50 ------- 0 0.0 1.0 0 17773 -1 0xa 50 0
+ 126007.633774 1 0 ack 50 ------- 0 1.0 0.0 0 17775 1 0x1a 50 0
- 126007.633774 1 0 ack 50 ------- 0 1.0 0.0 0 17775 1 0x1a 50 0
r 126007.647107 0 1 tcp 50 ------- 0 0.0 1.0 0 17774 -1 0xa 50 0
+ 126007.647107 1 0 ack 50 ------- 0 1.0 0.0 1 17776 1 0x18 50 0
- 126007.647107 1 0 ack 50 ------- 0 1.0 0.0 1 17776 1 0x18 50 0
r 126007.947107 1 0 ack 50 ------- 0 1.0 0.0 0 17775 1 0x1a 50 0
+ 126007.947107 0 1 tcp 50 ------- 0 0.0 1.0 1 17777 1 0x10 50 0
- 126007.947107 0 1 tcp 50 ------- 0 0.0 1.0 1 17777 1 0x10 50 0
+ 126007.947107 0 1 tcp 586 ------- 0 0.0 1.0 1 17778 1 0x10 50 0
+ 126007.947107 0 1 tcp 586 ------- 0 0.0 1.0 537 17779 1 0x10 50 0
r 126007.96044 1 0 ack 50 ------- 0 1.0 0.0 1 17776 1 0x18 50 0
- 126007.96044 0 1 tcp 586 ------- 0 0.0 1.0 1 17778 1 0x10 50 0
- 126008.116707 0 1 tcp 586 ------- 0 0.0 1.0 537 17779 1 0x10 50 0


Another problem I experienced is that a passive close peer retransmits FIN
forever if the original FIN has been lost. There has been some discussion on
the list about that and I use a suggested hack to fix this.
http://www.isi.edu/nsnam/archive/ns-users/webarch/2000/msg03812.html
Do you have plans to add TIME_WAIT to FullTcp?

> In general, you may notice that the tcp-full model is currently undergoing
> substantial changes.  In particular, the SACK handling is changed
> significantly.  People who are using this code should be aware
> of this.

Sure, I have no complains on this side, it's good that people spent their
time so that FullTcp has appeared at all.

Andrei