Date:	Fri, 24 Jun 2011 10:58:17 -0400
From:	Janardhan Iyengar <jana.iyengar@...il.com>
To:	rick.jones2@...com
CC:	Josh Lehan <linux@...llan.com>, Yuchung Cheng <ycheng@...gle.com>,
	netdev <netdev@...r.kernel.org>, Bryan Ford <bryan.ford@...e.edu>
Subject: Re: Skipping past TCP lost packet in userspace

[Reviving this thread... apologies for dropping it.]

Rick,

Thanks for your note.  I agree that it does seem like we're simply adding to the metaphorical pile.  And my first knee-jerk response would be that there's not much else one can do in the modern IPv4 Internet :-)

That said, I'd like to point out that when you say that problems at layer 4 need to be fixed, there are two kinds of changes that can be considered -- the layer 4 protocol, and the API it offers to apps.  Changes to the API, which is what we're proposing, is not a modification to the transport layer protocol per se.  In other words, we are changing the service that TCP offers to apps, and not the protocol.

The non-portability that you point out in the second part of your note, while a completely legitimate point, is again an API issue.  While this API is non-portable because it doesn't exist in other OSes yet, that is a matter of time (hopefully), and we're hoping to start the process with Linux.  And, it is easy enough for an app to fail over to using simple TCP behavior where the sockopt is not supported.

You also point out that we could perhaps fix the shortcomings of TCP by actively building and deploying alternative transports -- we've tried that and failed exactly because we've missed the point that the narrow waist of the Internet hourglass is no longer just IP, but includes TCP and UDP as well (and sometimes just TCP.)  For the entire time I've been working with SCTP (since 2001), we've been working on and trying to get SCTP through middleboxes, but as it stands, we still only have pockets of success.  Try using SCTP in the wild; your packets are quite likely to get black-holed within your home/ISP network.  The problem with middleboxes is that the IETF missed the boat on providing standards for these devices, and there are very few (if any) points of pressure that can be applied to change these devices in the network.  As a result, getting any new non-network-compatible transport deployed over the network remains untenable.

Our goal is to be able to provide new network services while remaining compatible with the network.  As we see it, that is the only option that remains if we are to consider any new transport services beyond TCP's straitjacketed one.  As it turns out, our work shows that we _can_ offer more services using the same TCP protocol, which is a win-win, since the new services remain network-compatible.

Note:  I'm talking largely about the v4 Internet.  The v6 Internet will hopefully have fewer devices that interpose on the transport layer, esp. NAPTs;  however, I expect fully that firewalls and PEPs will still use transport layer information, requiring them to be able to read/understand transport header information.

- jana

On 6/1/11 1:35 PM, Rick Jones wrote:
> On Wed, 2011-06-01 at 01:10 -0700, Josh Lehan wrote:
>> On 05/31/2011 10:23 AM, Yuchung Cheng wrote:
>>> This paper may have a solution to your problem
>>> "Minion—an All-Terrain Packet Packhorse to Jump-Start Stalled Internet
>>> Transports"
>>> http://csweb1.fandm.edu/jiyengar/lair/papers/minion-pfldnet2010.pdf
>>
>> Nice, thanks for pointing me to this.  I appreciate the helpful answer,
>> instead of just saying "use UDP" or "use SCTP".  That's not the point.
>>
>> For better or for worse, TCP is realistically the only viable protocol
>> for streaming to the largest possible audience these days, hence my
>> question about adding this feature to the Linux TCP implementation.
>
> Isn't that treating the symptoms of problems at layers 8 and 9 (*) with
> kludges (perhaps hacks if one is feeling charitable) at the user
> interface to layer 4?  Just how many more little bits can we add to the
> great pile before the aroma is overpowering?  Or to abuse another
> metaphor, is there really any camel's back left here?
>
> And while Linux has had some slightly non-trivial, non-portable
> enhancements to its interface to a TCP endpoint (TCP_CORK is something
> that comes to mind) I don't think any of them have been anywhere nearly
> as large a change to a fundamental semantic of a TCP connection as what
> you propose.
>
> rick jones
>
> *
> http://www.isc.org/store/logoware-clothing/isc-9-layer-osi-model-cotton-t-shirt
>
>

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar
--
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

Powered by blists - more mailing lists