Re: [Tofoo] FW: I-D Action: draft-zhou-li-vxlan-soe-01.txt

[Tom Herbert <[e-mail]>]

On Thu, May 22, 2014 at 11:50 AM, Joe Touch <[e-mail]> wrote:

>
>
> On 5/22/2014 11:43 AM, Tom Herbert wrote:
>
>>
>>
>>
>> On Tue, May 20, 2014 at 6:14 PM, Joe Touch <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     Hi, Han,
>>
>>     This helps, but doesn't quite address my concern.
>>
>>     TCP offloading is fine when the OS hands off user data, and the
>>     offload engine creates the entire segment.
>>
>> This would essentially be TOE.
>>
>>     The situation you're describing seems to be a hybrid, where the
>>     guest OS makes a TCP segment, and then something lower (in the VM
>>     system) parses that segment to create one or more segments on the
>> wire.
>>
>> This how Linux and probably about every NIC implements TCP segmentation
>> offload. A large TCP segment is broken up into MSS sized segments (MSS
>> is provided in ancillary data). The process replicates the IP/TCP
>> headers per packet, adjusts the length, sequence numbers, and computes
>> checksum for each segment.  There's no special handling of any options,
>> it is assumed they can be replicated in each segment.
>>
>
> That's an incorrect assumption.
>
>
> If there are options that can't be replicated then the stack won't use the
offload mechanism for those cases. Of course in that situation the
performance benefits would be lost, so we really like new options and
fields in protocols to be able to be replicated across a few segments :-).
New instances of per packet checksums, lengths, sequence numbers, etc. make
segmentation offload harder.


>      If that happens, it will be incompatible with a number of existing
>>     TCP options, and will also cause side-effects with ACK clocking,
>>     timeouts, and more than a few other TCP features.
>>
>>
>>     Although I appreciate the goal of efficiency and speed, there is a
>>     severe compatibility issue that doesn't seem to be addressed.
>>
>> TCP segmentation offload is already widely deployed. Since this draft
>> would be using the same mechanism it's unlikely to create new
>> compatibility issues except for the fact that the segmentation might be
>> deferred to an off host entity which is a new concept that would
>> probably have side effects.
>>
>
> IMO, this draft should not rely on or further promote a mechanism with
> known problems.
>
> The mechanism is not inherently problematic, it is still up to the
implementation to ensure correctness. What is different with SOE is that
the offload functionality becomes visible in the protocol and creates cross
implementation dependencies to implement correctly.

Tom


> Joe
>