Re: Skipping past TCP lost packet in userspace

[Josh Lehan <linux@krellan.com>]

On 06/24/2011 07:58 AM, Janardhan Iyengar wrote:
> 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 :-)

Thanks, I also appreciate you reviving this thread.  I was surprised at
the hostility here, towards an idea that we both think is necessary and
practical, given the realities of today's Internet.

TCP is at the middle of the hourglass, as you said.  Even UDP isn't
universally allowed (it's not all that uncommon to see UDP blocked,
except for DNS packets to whitelisted DNS servers).  At least one ISP,
"AT&T U-Verse", no longer allows the customer their choice of Internet
router, and the ISP's mandated router will filter all traffic in both
directions, so if the packet isn't recognized by its simple little
stateful firewall, into the bit bucket it goes.  Have fun trying to pass
SCTP or DCCP through that!

> 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.

Agreed, and the freedom of Linux to do this is what makes it great.  API
compatibility with other OS's is not an issue, since as you said the app
can always fall back to classical TCP behavior, and since nothing on the
wire changes, it won't break the other OS on the other side of the wire.

> 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.

Like IPv4, most (all?) IPv6 firewalls are stateful, so the firewall has
to be aware of the transport protocol in order to know which packets to
allow back through as replies.  And, for servers behind the firewall,
the firewall must offer a way to punch a hole through it without opening
too wide of a hole, and keep state for incoming connections, so
transport protocol awareness is important there as well.

So, even though we're vastly outnumbered on this mailing list, I remain
interested in your "Minion" paper and its ideas for providing a richer
API to make TCP more versatile to suit a wide variety of needs.

Josh Lehan