| Hi, I just updated the code at: to fix the bugs when running multiple flows. It was simple as expected: just declare all the state variables in the right place (in the .h file), done. I dealt with a tougher problem that seemed related but was not - I’ll just explain it here so you folks know: for a while, I had an extra rule in there to terminate with an error message when the retransmit round would reach 10 - because that’s just too crazy, it can only be an error. In a scenario with a tiny BDP (below a packet size: 10ms RTT, 1Mbps => 0.83 packets) and 10 packets of buffering, I got an IW of 10 packets, no ACKs, all 10 packets retransmitted, no ACKs, etc etc, often enough to reach my limit. Making this more strange, it appeared when I used one of the “background” nodes as a source but not the other…. it seems that the sequence of creating TCP sockets played a role here, even when only the second was used!!! VERY strange… maybe related to the queue implementation, no idea! Anyway, I think what happened is: normal TCP works fine because it gets a timeout and then only sends 1 packet - but if I start out with IW10 with a small RTT, dropping them might just reduce the gap between them a little, but not enough to avoid dropping them all again… because the initial rate hasn’t been “seeded” with anything useful at all ! We just work from the rate that we have… so we halve a rate that’s way too large. That seems like a strange mistake, a stupid corner case… anyway, a quick fix was to disable my “this is an error, give up” stop. BTW, the new code has a parameter “Verbose” which can be used to disable the heavy output per socket. Maybe useful when dealing with multiple flows, as this quickly gets quite chaotic! Cheers, Michael PS: I had a simple idea to reduce spurious timeouts, even with just the 2*RTT rule: often, we see: 1) packets are sent, timeouts are scheduled 2) RTT grows, a few times 3) timeout happens 4) it is later found to be spurious The timeout in step 3 is based on a too small RTT… it should be simple to update it to get larger when the RTT grows larger too? Would it be hard to change a timer value when a timer is already scheduled? Probably not… PPS: I also still need to implement Giuseppe’s additive increase / slow start increase ideas… |
Archivio con motore MhonArc 2.6.16.