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

[Wesley Eddy <[e-mail]>]

On 4/12/2011 6:48 PM, Joe Touch wrote:
> Hi, all,
>
> On 4/12/2011 3:18 PM, Anantha Ramaiah (ananth) wrote:
>>
>> To add more...
>>
>> History : TCP option space issue, when I raised it 5 years back, was
>> deemed as a "solution in search of a problem".
>
> I would describe it as a "unsolvable problem" with many proposed
> solutions, none of which was viable.
>
> Here's the nutshell, as I recall it:
>
> - extra space after the 3WHS is easy; create an option, and once it's
> ACK'd you can use it (in each direction)


I agree.


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


> - extra space in the SYN is not possible
> there's no way to provide the space before you negotiate support in a
> backward compatible way


I agree.


> 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. 
If there's evidence that it can survive some significant fraction of 
middleboxes, that would be good; this was a concern with all 3 of the 
proposals listed above.

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


> 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

-- 
Wes Eddy
MTI Systems