TEB TCP is really robust :)

[Michael Welzl < >]

Hi,

I finally did a test that I should have done long ago; frankly, I’ve been delaying it because I’m beginning to hate scenario generation with ns-3 so much  :-(   (*)

I made an update to my script (and uploaded it to my page, in case you want it) that lets me change the TEB flow’s access link’s delay while the simulation is going on. This is maybe the heaviest kind of “stress test” because of course our timer will get things wrong if we do this.

I’m attaching a cwnd and time-sequence plot for a simulation in the same setup as usual, only one flow, and bumping the delay up to 1 second at t = 10 seconds, lasting for one second:

1. “sack”, which is normal TCP

2. “teb”, which is our timer-based one

3. “teb-noeifel”, which is our timer-based one, but with the Eifel spurious recovery mechanism disabled.

I tried the third thing because I thought it’s a bit unfair otherwise, obviously the normal “sack” TCP in ns-3 doesn’t have Eifel support. 

Obviously, ours with Eifel is best, but that’s thanks to Eifel. But I found it interesting that ours was even better than the normal one - we have the mechanism to detect and react upon a double drop enabled, but the double drop simply doesn’t happen… still, normal Sack doesn’t get enough Sack blocks in time and runs into a timeout, whereas we start expecting packets later as soon as the RTT increases (which is more correct IMO), and hence we don’t run into a major problem after the single false recovery, even in the case without Eifel.

That’s all with simply: timeout =  2 * most recent RTT.

A little hard to see in this picture: we have a spurious timeout at the very beginning, in slow start, because of this 2*RTT calculation, at t=0.63. This is quickly fixed by Eifel, but the green line drops. Still better than overshooting like crazy in bursts and then having a timeout (SACK)!

I’m afraid the competition will be fiercer when I get to compare this against the “real” FreeBSD and Linux implementations… but, still, given the simplicity gain we’re doing pretty well with this   :-)

Cheers,

Michael

(*)

E.g., there’s this “helper” to create a dumbbell topology - but when you want to change the bottleneck link delay, it’s almost impossible to determine which link this is in retrospect. When I googled, I actually found code of someone who creates a dumbbell topology himself because the helper doesn’t give you access to the bottleneck link. This is like we’re building our own app, as adviced by the tutorial, because otherwise we can’t access the cwnd. What, then, is the “BulkSendApplication” good for??  I don’t understand why it makes sense to write all this into the tutorial and act like this is good design, instead of simply fixing what obviously is an architectural problem in this ** piece of software…