TCP window rescale fails to trigger data sending

[waddlesplash]

This only started happening after the TCP changes were merged.

Essentially it manifests itself as just a total stop in data transmission. I can have it happen 100% of the time when doing a large push to GitHub. Packet inspection shows that the transmission stops immediately after a window rescale.

Analysis from mmlr on IRC:

6:24 PM <•mmlr> the window collapses on the github side, which isn't really our fault
6:24 PM <•mmlr> but then there's the window update that resets it back to the full 64k
6:24 PM <•mmlr> but for 600ms nothing happens
6:24 PM <•mmlr> then the server side seems to give up by closing the connection
6:25 PM <•mmlr> so looks like there's an issue with the window update not triggering data sending

mmlr and jessicah have the pcap files from me; I'm OK with giving them to any other developer with commit access who'd like to work on it.

[waddlesplash]

Reverted the offending commit in hrev51419. It should be fixed and reapplied, though.

[a-star]

The problem is exactly what mmlr analyzed. There is no response to a window update message.

The reason for the erratic behavior is that the tcp implementation silently drops window update messages after noting the update but without triggering any data send event. Before the new TCP patches were applied, the implementation relied on a retransmission timeout to trigger a send event after a window update. One of the new patches dealing with the ideal timer changed the semantic of the restransmit function call and caused the behavior witnessed.

But a retransmission timeout is not the correct solution to window update. In fact a retransmission is not a desired effect of window update. So in the patch attached, I have changed the behavior of the implementation to immediately acknowledge the window update (along with data from SendQueue) and thus solving the problem of complete halt in data transmission.

The patch also has the changes re-implemented that were reverted back but had nothing to do with the issue at hand. For the time being, I have also removed the "ideal timer" part from the patch (although it wasn't creating any conflict). I initially decided to implement the ideal timer using the same timer used for retransmission to avoid adding an additional timer. But as I have seen, it can be problematic. So I will be re-implementing the ideal timer and thus it was not included in this patch.

The patch solved the problem for me. If it doesn't workout for anybody, kindly let me know and it would be great if you could provide the pcap file for the same.

[waddlesplash]

Applied in hrev51540. Thanks!