Messages in this thread | | | Date | Mon, 09 Nov 2009 16:24:52 +0100 | From | Andreas Petlund <> | Subject | Re: [PATCH 1/3] net: TCP thin-stream detection |
| |
Ilpo Järvinen wrote: > On Thu, 5 Nov 2009, Andreas Petlund wrote: > >> Arnd Hannemann wrote: >>> One example: Consider standard NewReno non-SACK enabled flow: >>> For some reasons two data packets get reordered. >>> The TCP sender will produce a dupACK and an ACK. >>> The dupACK will trigger (because of your logic) a spurious retransmit. >>> The spurious retransmit will trigger a dupACK. >>> This dupACK will again trigger a spurious retransmit. >>> And this game will continue, unless a packet is dropped by coincidence. >> Such an effect will be extremely rare. It will depend on the application >> producing an extremely even flow of packets with just the right >> interarrival time, and also on reordering of data (which also will >> happen very seldom when the number of packets in flight are so low). >> Even though it can happen, the data flow will progress (with spurious >> retransmissions). The effect will stop as soon as the application sends >> more than 4 segments in an RTT (which will disable the thin-stream >> modifications) or less than 1 (which will cause all segments to be >> successfully ACKed), or if, as you say, a packet is dropped. > > I'd simply workaround this problem by requiring SACK to be enabled for > such a connection. This is reinforced by the fact that small windowed > transfers want it certainly to be on anyway to get the best out of ACK > flow even if there were some ACK losses. >
Thanks. I will revise the patches based on all the feedback I have gotten and get back to the list with a new version when I have done some more testing.
Best regards, Andreas
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |