Re: [multipathtcp] Time for Long Options?

On 8/3/2010 2:50 AM, L.Wood@surrey.ac.uk 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, 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: multipathtcp-bounces@ietf.org [multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch [touch@isi.edu]
> 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
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp