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

Joe Touch <touch@isi.edu> Thu, 22 May 2014 21:11 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tofoo@ietfa.amsl.com
Delivered-To: tofoo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D77F1A0349; Thu, 22 May 2014 14:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31EHjNCcUpMk; Thu, 22 May 2014 14:11:08 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7D61A034D; Thu, 22 May 2014 14:11:08 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4MLAl0c014697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 14:10:47 -0700 (PDT)
Message-ID: <537E67D6.1060405@isi.edu>
Date: Thu, 22 May 2014 14:10:46 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Tom Herbert <therbert@google.com>
References: <20140502120923.9835.17537.idtracker@ietfa.amsl.com> <9F56174078B48B459268EFF1DAB66B1A109C2DD3@DEN-EXDDA-S32.corp.ebay.com> <537B90C9.1090003@isi.edu> <9F56174078B48B459268EFF1DAB66B1A109C36FC@DEN-EXDDA-S32.corp.ebay.com> <537BFDF4.9030300@isi.edu> <CA+mtBx9+7hC5p+3djpLVQ2upx-rs7iE2ms0mET4AoC6uZ1LWnQ@mail.gmail.com> <537E46DC.9000303@isi.edu> <CA+mtBx8XnhPqhX_fgyp4O+5NR6kTiJPS-QAaw+K2xV_r5n4LyQ@mail.gmail.com>
In-Reply-To: <CA+mtBx8XnhPqhX_fgyp4O+5NR6kTiJPS-QAaw+K2xV_r5n4LyQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/obAenCwNgDEahgvXoe6s2Q4dOh4
Cc: "Zhou, Han" <hzhou8@ebay.com>, Erik Nordmark <nordmark@sonic.net>, "tofoo@ietf.org" <tofoo@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "draft-mahalingam-dutt-dcops-vxlan@tools.ietf.org" <draft-mahalingam-dutt-dcops-vxlan@tools.ietf.org>, "draft-zhou-li-vxlan-soe@tools.ietf.org" <draft-zhou-li-vxlan-soe@tools.ietf.org>
Subject: Re: [Tofoo] FW: I-D Action: draft-zhou-li-vxlan-soe-01.txt
X-BeenThere: tofoo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <tofoo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tofoo>, <mailto:tofoo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tofoo/>
List-Post: <mailto:tofoo@ietf.org>
List-Help: <mailto:tofoo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tofoo>, <mailto:tofoo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 21:11:09 -0000


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