Re: [Spud] SPUD's open/close are unconvincing

[Tom Herbert <[e-mail]>]

On Wed, Apr 8, 2015 at 9:15 PM, Toerless Eckert <[e-mail]> wrote:
> On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote:
>> I think the kernel/user-land argument is a red herring.
>
> Elaborate please. To me its probably the biggest motivator for
> SPUD. Otherwise we could design all we need into IP and TCP.
>
>> The problem is
>> that middleboxes routinely participate in transport layer protocols
>> which was never architected-- transport layer protocols are inherently
>> end-to-end protocols.
>
> Thats 1970'th IETF katechism. I would call middleboxes a big contributor
> to todays success of Internet technologies.
>
Maybe, but the consequences of diverging from the end-to-end model is
reality we still need to deal with. When we deploy transport protocols
at scale on the Internet we are still bound in a large part by the
least common denominator network devices out there. There are deployed
devices that choke on our attempts to extend transports. We need to be
concerned about these, we simply can't completely break connectivity
for 1% of the world in order to give everyone else a 5% performance
improvement.

>> It's relatively easy to change client and
>> server sides to accommodate new transport functionality,
>
> Which is why we have OS-level TCP functions that lag state of the art
> on average by a decade.
>
I can't comment on other OSes, but I will say that the rate of change
to TCP and transport layer protocols in Linux and high and
significantly outpaces IETF standards (e.g. IW=10, lowering initRTO,
CC changes). These arguments seem to have more to do with the time for
deployment. This is not a problem with any reasonably modern OS, but
people are still concerned with getting changes into legacy
deployments (Windows is often cited). But, if you have specific OS
features that you think are missing I'd be happy discuss that
off-thread.

>> but pretty much impossible for us to change all the possible middleboxes
>> in a path in a timely fashion.  Just one middlebox in the path that decides
>> to drop our packet because it doesn't understand our new option, or
>> doesn't like our new flags can spoil everything-- it is really
>> difficult to work around interoperabilities like this.
>
> Everybody and their dog concerned about this problem is already
> automatically falling back to IP over SSL on port 443. We simply need to
> do the best to evolve away from that. Thats why it is important to offer
> benefits to those middleboxes.
>
This a general problem with modifying transport protocols. For
instance, it's potential problems with middleboxes that may wreak
havoc with attempts to increase the TCP option space (EDO).

>> So, yes, the
>> net effect of this is that we have become very conservative with
>> transport layer changes, and when we do make changes at the transport
>> layer we often have to masquerade these in something that is
>> considered generally palatable to middleboxes. This is why we intend
>> to run transport protocols over UDP in the first place, and has even
>> motivated brazen attempts to overload TCP protocol number with other
>> things (e.g. STT). SPUD is a good opportunity to generalize and
>> standardize middlebox/transport protocol interactions, but if the its
>> benefits are dependent on middleboxes being updated that not is going
>> to go anywhere fast either!
>
> Any firewall can start out processing SPUD just as UDP and once
> FW firmware improves it will simply improve from there. Nobody
> says firewalls MUST update, we just say that we want to provide
> at least the same toolset for relevant inspection firewalls as what TCP gives
> them.

It's pretty clear that for the foreseeable future were pretty much
stuck with using either TCP or UDP on the Internet (barring that
something like SCTP would ever get traction). Since we can't do
reasonably stateful firewalls or stateful NAT with UDP that is a
fundamental problem which constrains us to use TCP. There are needs
for new transport protocols, so encapsulating them in UDP seems to be
pragmatic approach, but we really need the ability for middlesboxes to
track state for such things-- this is what I hope SPUD provides.

Tom

>
> Cheers
>     Toerless