Re: [multipathtcp] Time for Long Options?

[<[e-mail]>]

On 4 Aug 2010, at 20:31, Joe Touch wrote:
On 8/3/2010 2:50 AM, [e-mail] wrote:
>> Joe,
>> 
>>> As I noted, this problem was explored in numerous contexts in TCPM, and
>>> the conclusion was that it was not feasible to extend options in the
>>> SYN. That being the critical case, we didn't explore extending options
>>> in just the payloads after the connection was established.
>> 
>> didn't
>> http://tools.ietf.org/html/draft-eddy-tcp-loo
>> do just that?
> 
> Sec 3 did

right.

And doesn't TCP-CT contains a similar mechanism? That is on its way through
the RFC-Editor...
http://tools.ietf.org/html/draft-simpson-tcpct-03


> , but had numerous issues (required option ordering - which 
> isn't really feasible -- options do not have required ordering, and 
> there's no 'registry' to indicate who comes first if multiple claim to). 
> It also didn't define how it interacted with other options (e.g., MD5 or 
> extended checksums).
> 
> Sec 4 attempted to extend the SYN for subsequent connections to the same 
> host, but that's not feasible since info on one connection might not 
> apply to another (e.g., when connections are distributed inside a 
> back-end system).
> 
> Joe
> 
>> 
>> (yes, should probably be -tcpm- rather than -tcp- in the filename.)
>> 
>> L.
>> 
>> Lloyd Wood
>> http://sat-net.com/L.Wood/
>> ________________________________________
>> From: [e-mail] [[e-mail]] On Behalf Of Joe Touch [[e-mail]]
>> Sent: 03 August 2010 09:44
>> To: Andreas Ripke
>> Cc: multipathtcp TCP
>> Subject: Re: [multipathtcp] Time for Long Options?
>> 
>> On 8/2/2010 2:14 AM, Andreas Ripke wrote:
>>>> FWIW, the MacOSX is implementing TCP properly. The data in the SYN is
>>>> part of the data path (unless, presumably, the option declares
>>>> otherwise). Options not defined are required to be silently ignored.
>>> 
>>> 
>>> The plan was to figure out how to handle a receiver that does not
>>> know about extended option space. If the initial SYN with extended
>>> options space arrives and the receiver is unaware it treats the extra
>>> as payload. Falling back to regular TCP is then only possible with RST
>>> followed by a new connection request (to avoid extended options to be
>>> delivered to the application - as only the SYN is ack'ed in the first
>>> place and not the payload). But then, the other challenge is how to
>>> detect if middleboxes altered and rectified the packets.
>> 
>> RSTs are not reliable, so now you have to deal with the timeouts and
>> retransmissions that result.
>> 
>> As I noted, this problem was explored in numerous contexts in TCPM, and
>> the conclusion was that it was not feasible to extend options in the
>> SYN. That being the critical case, we didn't explore extending options
>> in just the payloads after the connection was established. That may be
>> useful to explore here as a separate issue, but SYN extension does not
>> seem possible.
>> 
>> Joe

Lloyd Wood
[e-mail]
http://sat-net.com/L.Wood