Re: [tcpm] TCP-Rehash draft

[Bruno Mongazon-Cazavet <[e-mail]>]

  Le 24/02/2011 11:21, Scheffenegger, Richard a écrit :
> Bruno,
>
>
>
>>> - the option includes stateful exchanges of options
>>> 	TCP options are stateless w.r.t. the TCP state machine,
>>> 	and must be able to be processed out of order and
>>> 	assume losses (they aren't running inside the TCP
>>> 	data stream); that appears to challenge the design
>>> 	of this mechanism (it seems to be addressed in part,
>>> 	but corner cases aren't considered)
>> There are couples of RFC that use TCP options in a stateful way (i.e.
>> RFC1323 with timestamp echo).
>> Basically MPTCP options also work the same.
>
> Last time I checked, MPTCP negotiates all options that require state changes; and RFC1323 was designed specifically to aid stateless tracking of RTT (instead of what appears to have become endemic, keeping state and tracking each individual sent segment, and matching the ACKs to the proper segment, for "timestamp-less", fine-granularity RTT tracking purposes...

[BM] This is a good point of MPTCP.

> Perhaps using Linux as basis is not the base departure point to argue about IETF compliant behavior (Linux deviates in so many ways from a IETF-adhering stack, that it's hard to delineate all the interactions; this is not intended as a  judgmental statement).

[BM] I use what i have ! I test specifications through implementation as 
IETF requires. I could also have done it on FreeBSD, just lack of time.

Regards,
Bruno.

> Best regards,
>     Richard
>
>
> -----Original Message-----
> From: Bruno Mongazon-Cazavet [mailto:[e-mail]]
> Sent: Mittwoch, 23. Februar 2011 10:34
> To: Joe Touch
> Cc: [e-mail] Extensions
> Subject: Re: [tcpm] TCP-Rehash draft
>
>
>    Le 23/02/2011 03:25, Joe Touch a écrit :
>> Hi, all,
>>
>> FWIW, there was a discussion of whether this proposal was a subset of
>> the features of multipathTCP on the multipathTCP list back in Nov.
> Yes i saw this.
> Having also some knowledge and experience with MPTCP, i would argue that
> features are somewhat different.
> TCP-Rehash and MPTCP looks more complementary than competing.
>
>> Some other points:
>> - rehash is a bad term to use; it implies a security hash, rather than
>> altering the addresses of a TCP connection
> "rehash" term is used in reference to the "hash" mechanism performed by
> TCP/IP Linux stack to find a TCP control block giving a 5-Tuple.
> When choosing this name, no security matter was considered. Just the
> capability to recompute the hash value of a TCP-cb for a given 5-tuple
> (old address) with a new 5-tuple (new address). That's why i called it
> "rehash".
>
> I must agree that the term might not be the best but i wanted to avoid
> terms like "migrate" or alike.
>
>> - the option includes stateful exchanges of options
>> 	TCP options are stateless w.r.t. the TCP state machine,
>> 	and must be able to be processed out of order and
>> 	assume losses (they aren't running inside the TCP
>> 	data stream); that appears to challenge the design
>> 	of this mechanism (it seems to be addressed in part,
>> 	but corner cases aren't considered)
> There are couples of RFC that use TCP options in a stateful way (i.e.
> RFC1323 with timestamp echo).
> Basically MPTCP options also work the same.
> I don't see any restriction in IETF in using TCP options to maintain
> state information.
>
> I agree about "out of order" and "losses" issues and it is true it
> challenged a bit the design.
> I came up with the following invariants:
>
> (a) the first packet out with the new address must carry the REHASH-ADDR
> option if the connection is "rehash" capable
> (b) if REHASH-ADDR has been sent, and some packets are still received
> with the old address, the receiver did not yet "rehash" and the sender
> drops old packets and provides again the REHASH-ADDR option until a
> maximum number of retry is reached.
>
> Could you provide some details on the corner cases that are not covered ?
>
>> - the option seems to be twice as long as necessary
>> 	it seems like you already have the current or old IP
>> 	address in the TCP pseudoheader (IP header); why
>> 	do you need to send both?
> I need both because if there is a NAT in between, the IP header source
> address will differ.
> Although TCP-Rehash is currently described as not-NAT capable, provision
> in the TCP option would allow to do this later.
>
>> 	you clearly need room for flags somewhere, but can
>> 	accomplish that with 1 byte (or 2 if padded), rather
>> 	than 4
> Provision for flags is in bytes 0-1.
>
>> - the option appears to deal only with the address changing
>> 	however, the ports are also specific to the endpoints
>> 	as well; it should not be assumed that a connection
>> 	can be moved with its ports intact
> Right, the ports are currently missing in the option and could be added
> in further revision of the draft.
> Please consider that this is draft-0 and thus claims it might lack of
> some features.
>
>> Finally, I don't see how requiring IPsec to use this mechanism makes it
>> simpler than MPTCP (which doesn't require IPsec).
> Just saying that if your network is insecure and because TCP-Rehash
> security is low, you can use IPsec.
>
>> There are many other issues which are not addressed, notably how
>> applications assume that successive or concurrent connections to the
>> same IP address go to the same endpoint (e.g., for FTP, or web
>> transactions); similar concerns are raised in the Intarea "address
>> sharing" doc, and should be discussed here.
> Fine, can you provide pointer to this document, please.
>
> Best regards,
> Bruno.
>
>> Joe
>>
>> On 2/21/2011 8:05 AM, Bruno Mongazon-Cazavet wrote:
>>> Dear working group members,
>>>
>>> I wonder if you have any chance to look at the TCP-Rehash draft:
>>> http://tools.ietf.org/html/draft-mongazon-tcpm-tcp-rehash-00
>>>
>>> i posted a few months ago.
>>>
>>> Did you read it and would consider any interest and follow-up in the
>>> working group context ?
>>> On my side, i have a pretty serious running implementation of the draft
>>> in Linux 2.6.27 and Linux 2.6.34.
>>> I am ready to discuss and present both the draft and implementation in
>>> next IETF meeting.
>>> Would you be interested in this ?
>>>
>>> Thanks for your time and consideration.
>>> Bruno Mongazon.
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>