Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[Olivier Bonaventure <[e-mail]>]

Michael,


> Thus, instead of further arguing about process aspects, I am more interested in thoughts on:
>
> * From designers of TCP extensions requiring more option space: Is draft-touch-tcpm-tcp-edo a good solution for your needs and thus the right way to move forward?
>
> * From implementers: Are there deployment issues beyond what is described in the draft already? And, would this mechanism be implemented in the Internet?

My main concern with this draft are the possible interactions with 
segment splitting/coalescing middleboxes.

The draft considers that these middleboxes are rare and should not 
constitute a problem. Unfortunately, I have to disagree with this 
statement. An important concern are the recent NICs that support TSO or 
GRO. These NICs are very widely used today and there are environments 
where it is very difficult for a TCP stack to determine whether it runs 
with such a NIC a not. A typical case is a virtual machine running on a 
host that exposes a driver that does not correspond to the physical NIC 
that is actually used.

The EDO option proposed in this draft does not unfortunately work 
correctly through a middlebox that splits segments. Concerning the 
following example.

A host that has negotiated EDO during the three way handshake sends a 
segment that contains :
- TCP header indicates 4 bytes of option, followed by EDO option 
indicating an option of 100 bytes, 100 bytes of option (e.g. a very long 
SACK), 1000 bytes of data

The middlebox does not understand the EDO option but needs to split the 
segment. Some middleboxes will copy all options in the two segments. 
This results in  :

segment 1 : TCP header indicates 4 bytes of option, followed by EDO 
option indicating an option of 100 bytes, 100 bytes of option (e.g. a 
very long SACK), 500 bytes of data

segment 2 : TCP header indicates 4 bytes of option, followed by EDO 
option indicating an option of 100 bytes, 500 bytes of data

The receiver will try to parse 100 bytes of option in the second segment...

In their IMC paper entitled "Is it Still Possible to Extend TCP?", 
Michio Honda et al. provide the following recommendation
http://conferences.sigcomm.org/imc/2011/docs/p181.pdf

"All the NICs we tested correctly copied the options to all the split 
segments. TSO is now sufficiently commonplace so that designers of 
extensions to TCP should assume it. The implication is that TCP options 
must be designed so that when they are duplicated on consecutive 
segments, this does not adversely affect correctness or performance."

EDO should be modified to take this recommendation into account to be 
deployable in today's Internet.

One possibility could be to include a checksum inside the EDO option.


   +--------+--------+--------+--------+----------+----------+
   |  Kind  | Length |  Header_length  |       Checksum      |
   +--------+--------+--------+--------+----------+----------+

The checksum should be computed over the entire extended option by the 
sender. When a receiver receives a segment with the EDO option, it MUST 
verify the EDO checksum. If the checksum is correct, then the extended 
option can be parsed. Otherwise, the entire segment should be silently 
dropped.

The checksum could solve the problem mentionned above with the NIC that 
segment data, but additional work is required to check whether such 
modification would solve all possible problems with middleboxes.

With Multipath TCP, we managed to extend TCP while preserving 
connectivity. Multipath TCP can cope with various types of middleboxes 
but not all possible behaviours. For some of these behaviours, Multipath 
TCP fallsback to regular TCP to ensure that the application continues to 
operate without any loss of connectivity. The EDO option should also 
have this goal in mind.

Best regards,


Olivier


-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be