lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 09 Nov 2009 16:24:52 +0100 From: Andreas Petlund <apetlund@...ula.no> To: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> CC: Arnd Hannemann <hannemann@...s.rwth-aachen.de>, William Allen Simpson <william.allen.simpson@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "shemminger@...tta.com" <shemminger@...tta.com>, "davem@...emloft.net" <davem@...emloft.net> 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists