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

[Joe Touch <[e-mail]>]

On 5/22/2014 2:02 PM, Tom Herbert wrote:
...
> 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.

Segmentation should never need to happen in an offload engine unless 
that's where headers are generated. It's never appropriate to merely 
repeat TCP options - consider that this affects timestamps, ACKs, etc.

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

I don't agree about the lack of inherent problems.

Joe