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

[Joe Touch <[e-mail]>]

On 5/3/2014 12:51 PM, Olivier Bonaventure wrote:
> 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.

These already affect a few things - splitting replicates timestamps and 
repeats ACKs, and coalescing might need to drop SACK blocks and drops 
some of the timestamp info.

A key question for the group is the extent to which we want to support 
these or even detect them in our core mechanisms, or whether we should 
suggest that they be detected (and replaced) by existing mechanisms 
(e.g., TCP-AO or IPsec).

> 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 are not merely middleboxes that resegment. They ought to be 
integrated with the endsystem sufficient to support TCP.

So we should consider the impact of network rewriting boxes vs. TSO/GRO 
NICs as separate issues, IMO.

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

Again, we're back to the middlebox example:

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

A middlebox that examines the contents of TCP traffic - or worse, 
modifies it - needs to follow all of RFC1122 host requirements. It's 
interpreting content - if it sees a SYN with an unknown option, it ought 
to have removed it or dropped the SYN.

If it doesn't, you have a device that is broken and needs to be replaced.

We should design TCP to be liberal in what it accepts, but no Internet 
protocol should be designed to overcome deliberate implementation errors.

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

Agreed.

However, now you're back to the NIC issue (which ought not be related):

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

This tells me your TCP interface was implemented incorrectly.

The correct interface passes options (including the extended option *and 
its associated contents*) ***SEPARATELY*** from the user data.

If that is done all the way down to the TSO, the TSO will correctly copy 
the option into individual segments correctly.

If, however, you implement this badly - and pass TCP segments as a whole 
to the offload engine, then the offload engine *has no business* 
splitting or coalescing segments.

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

That logic would apply too EVERY option, and now we have a TCP that 
wastes space primarily to locate and debug implementation errors.

I don't agree that TCP should be designed to overcome deliberate 
implementation errors.

Joe