Re: [tcpm] Extending the TCP option space - yet another approach

[Joe Touch <[e-mail]>]

Hi, Wes,

On 4/12/2011 5:09 PM, Wesley Eddy wrote:
...
>> - extra space is useful only if it exists in the SYN, however; that's
>> where space is at a real premium
>
> I disagree; there's definitely utility beyond just having this
> capability in the SYN, some of this was defined in the LO/SLO draft
> linked to below.

If there is, it's a lot easier to do as a single mod.

...
>> There were several mechanisms, some of which attempted to use data in
>> the SYN (which corrupts the data path if not supported), and even one
>> that suggested just doubling all the TCP header fields (Mark Allman).
>
>
> The ones I recall are:
> - LO/SLO : http://tools.ietf.org/html/draft-eddy-tcp-loo-04
> - DO redefinition : http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00
> - tcpx2 : https://tools.ietf.org/html/draft-allman-tcpx2-hack-00
>
> Andrew's LOIC is interesting, and significantly different than these.

It's a bit of revisiting tcpx2, and just assumes that the endpoint tries 
to start two connections at the same time. That's been suggested before, 
but has problems:

	- how long do you wait to figure out which connection to accept?
	- what happens when either attempt's SYN is lost?

AFAICT, all variants here end up costing either the legacy or the new 
variant excessive delays, and that's not going to fly.

>> Regardless of need or utility, it is simply not possible in the SYN.
>
> The SLO option was an attempt to handle that by sending long options
> that you would have liked to be on the SYN later (i.e. on the ACK
> completing the handshake); in implementation, this meant calling the
> function in the kernel for processing SYN options on a received packet
> even though the packet wasn't a SYN, which was slightly awkward, but
> fairly simple.

This was discussed on this list back in 2004. The key interfering issue 
raised then, AFAICT, was intervening middleboxes that transparently 
rewrite segments.

I'm not sure whether that's still an issue, or whether other issues were 
raised, but let's recall that thread before exploring this as if we 
haven't discussed it before ;-)

>> So basically:
>> - we can trivially add space after a SYN exchange; it that's useful,
>> let's do it
>
> The LO option is one way to handle that:
> http://tools.ietf.org/html/draft-eddy-tcp-loo-04

Sure - but that would need to be factored out as a separate thing if 
deemed useful.

Joe