netdev - Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 22 Feb 2010 00:31:27 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Pavel Machek <pavel@....cz>
cc:	Andreas Petlund <apetlund@...ula.no>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Arnd Hannemann <hannemann@...s.rwth-aachen.de>,
	LKML <linux-kernel@...r.kernel.org>, shemminger@...tta.com,
	David Miller <davem@...emloft.net>,
	william.allen.simpson@...il.com, damian@....rwth-aachen.de,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [net-next PATCH v4 1/3] net: TCP thin-stream detection

On Sun, 21 Feb 2010, Pavel Machek wrote:

> Hi!
> 
> > +After analysing a large number of time-dependent interactive
> > +applications, we have seen that they often produce thin streams
> > +and also stay with this traffic pattern throughout its entire
> > +lifespan. The combination of time-dependency and the fact that the
> > +streams provoke high latencies when using TCP is unfortunate.
> > +
> > +In order to reduce application-layer latency when packets are lost,
> > +a set of mechanisms has been made, which address these latency issues
> > +for thin streams. In short, if the kernel detects a thin stream,
> > +the retransmission mechanisms are modified in the following manner:
> > +
> > +1) If the stream is thin, fast retransmit on the first dupACK.
> > +2) If the stream is thin, do not apply exponential backoff.
> 
> 2) seems very dangerous/unfair. If network  congestion is caused just
> by thin streams, will the network just fall apart?

...Network will not fall apart. Two possible cases:

a) cwnd > 1 segment, on RTO the window is reduced, thus the sender backs 
off regardless of exponential backoff.
b) All flows have window of 1 already... Well, what do you suggest? I'd 
say that obviously the network is seriously underprovisioned for the 
workload and since the bottleneck can only serve some of them anyway 
dropping the rest, no useless work gets done at the bottleneck. RTT 
estimator then gets a new samples whenever a flow belongs into the lucky 
group. In case any unnecessary retransmission happened (if there was 
very dramatic and sudden increase transient in the workload) they won't 
happen thereafter (unless we increase the workload toward infinity).

...Thus no problem of "falling apart".

-- 
 i.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html