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

Open Source and information security mailing list archives

Message-ID: <4AEB109A.7090506@gmail.com>
Date:	Fri, 30 Oct 2009 12:13:14 -0400
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	Linux Kernel Network Developers <netdev@...r.kernel.org>
CC:	apetlund@...ula.no,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	Arnd Hannemann <hannemann@...s.rwth-aachen.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"shemminger@...tta.com" <shemminger@...tta.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	Christian Samsel <christian.samsel@...h-aachen.de>
Subject: Re: [PATCH 1/3] net: TCP thin-stream detection

apetlund@...ula.no wrote:
> I share the opinion that the linear timeouts should be limited, and back
> off exponentially after the limit, as Eric suggested. I believe this will
> be a sufficient safety-valve for the black-hole scenario, although I would
> like to run some tests.
> 
> As I wrote to Arnd, there are many similarities with the EFR approach and
> what our patch does. The largest difference is that the thin-stream
> patterns are identified as an indication of time dependent/interactive
> apps. This is the reason why the proposed patch does not try to keep an
> inflated cwnd open, but only focuses on the cases of few packets in
> flight. The target is time-dependent/interactive applications, and as such
> we don't want a generally enabled mechanism, but want to give the option
> of enabling it only in the cases where they are most needed (in contrast
> to a generally enabled "automagically" triggered EFR).
> 
> Below is a link to a table presenting some of the applications that we
> have traced and analysed the packet interarrival times of:
> 
> http://folk.uio.no/apetlund/lktmp/thin_apps_table.pdf
> 
> We were surprised to see how many cases of "thin-stream" traffic patterns
> were indicative of time-dependent/interactive apps.
> 
I'm finding it hard to follow 3 threads, for the 3 parts of the patch.

As I mentioned in one of these threads, I've plenty of experience with
designing and implementing protocols for gaming.  And it seems to me that
you're making changes to the entire TCP stack to make up for shortcomings
in the implementor's design.  Yet, these changes require application
implementors to set a sockopt that's only available in Linux.  Unlikely,
as they probably don't even keep track of such things....

There are other efforts in this area, they've been mentioned.

I'm new to this list, so I'm not entirely sure that protocol design is
regularly discussed here.  But I'd prefer that the discussion moved to
one of the lists that's dedicated to such protocol design and testing.

I've already suggested the end-to-end interest list, where you'll find many
of us with a strong interest in this topic.

List-Subscribe: <http://mailman.postel.org/mailman/listinfo/end2end-interest>,
	<mailto:end2end-interest-request@...tel.org?subject=subscribe>

The IETF has two related working groups:
   tcpm -- tcp modifications
   tsvwg -- general transport, including sctp modifications

Without further ado, just count me as opposed at this time.
--
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

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