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

From: Andreas Petlund
Date: Thu Nov 05 2009 - 08:36:30 EST

William Allen Simpson wrote:
> 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....

The target is not only games, but for instance SSH sessions, RDP or VNC,
stock trading services, sensor networks and so forth. There are a lot of
time-dependent applications that shows thin stream properties. Many of
these use TCP, and will continue to use it. Some of these applications
use UDP as default, but fall back to TCP if there is a problem with the
UDP connection (for instance Skype). By providing better latency for thin
streams, we can increase the service level for all these applications.

Our experience is that at least some designers of interactive/time-dependent
applications are skilled enough and concerned enough to investigate whether
options exist that may improve the applications they are designing. Of
course there are exceptions, but for open-sourced software, there will be
people who can provide this input. If the argument is that there is no need
for customised options because developers are stupid, we could strip away a
lot of the existing network code.

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

I've been reading end-to-end for several years, and I think I will take this
discussion to that list eventually. We have discussed whether we should take
this to end-to-end first, and netdev after, but decided to go here for the
following reasons: 1) We have working patches that we wanted to contribute.
2) The modifications are implemented as optional. 3) When active, the
modifications handle a special case of TCP streams that we have shown to
have minimal impact on general TCP behaviour.

Also, in my experience, the end-to-end list discussions tend to digress,
making it difficult to keep the discussion to the special case that we
address. Since we wanted technical and practical feedback that would help us
to refine the modifications in the patches in addition to the discussion on
transport protocols, we chose to go to netdev first.

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

There are plenty of examples of TCP mechanisms present in the Linux
kernel that has not been standardised, for instance TCP CUBIC, the
default congestion control for many Linux distributions at this time.

We have a set of patches, and a large body of experiments that shows them to
be effective for the thin-stream scenario without any significant disadvantages.
Please consider this before discarding the proposition based on a general
principle of standardisation. We believe that the thin-stream modifications
will provide extra value to Linux networking.

Best regards,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at