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

Tom Herbert <therbert@google.com> Thu, 22 May 2014 21:02 UTC

Return-Path: <therbert@google.com>
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 DD3561A0283 for <tofoo@ietfa.amsl.com>; Thu, 22 May 2014 14:02:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 3NmJREGX4eid for <tofoo@ietfa.amsl.com>; Thu, 22 May 2014 14:02:50 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399BC1A0307 for <tofoo@ietf.org>; Thu, 22 May 2014 14:02:50 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id as1so4204726iec.27 for <tofoo@ietf.org>; Thu, 22 May 2014 14:02:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wJi2QMS5McXPP+/gqP8sqtm1NOLDR0LgXSKQ6uuyAOI=; b=OoaN7XWb/QpzddAezY55s0zNOqFnM0Rw0TRQEo6UGlAgAwjTJxZi26WVMlvWCQtcGE 5DaWg5kdY0JlO7Zu7UglUkS3NuMw+p83WMaiwvmJAHpJKlQP78L8D+xX0/NAxd8j5OO/ 4EvJQpWtY/1DXHU3os4uCWVuftv+nU9Y4y/IMIBTRYM57lg9ADKdbizhMmC2EctTs81r esbsQ/NlLGSNrEgvTaVOW36UefZuKWgB+idhY3Dqb09TXyGwqU6zH9t72z7mvpNHzEMD TnZRWHJhTd+nLGrz/6SmwyK2KnuPWP2O608IVPsqbl8qxlAt1uIf4oa/wXyNGxeDHWJt eKVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wJi2QMS5McXPP+/gqP8sqtm1NOLDR0LgXSKQ6uuyAOI=; b=Cz5dF12IOkAlibsooKXVNOMFWliWP7olOE0EZSrUrnON721pNGBkhv+82wd4i/7Zp2 l8yr0z4YxBAFRgGescZcOqIUBY8YvEZdI9v4EjO3JNwP/ilf516OWRFVJuCAvByEFz9q 0Xp+1B1z7q+Sgww3pXFhvzoCe2C2cf+DtmjAyR18qqszbBbqVsg9t6o6IUoD/zdrYfQ0 Yi+IKEVKDsLn5QK3hUl4wQlJsHpURjzDo1iyRdoDf/z4bvTFJ6MkwnIS9Mv34PRfJYmu Kw/Zlw1pE1N3I+QY6sxi/345nlWq1DTcX/y0Hm4kuuSCUZzEFXUQWOV48i2/vmkbrsYP gZCA==
X-Gm-Message-State: ALoCoQlmaEGpd/g8gB1Ij4hynKzR/PHAU304D5rvixOq1bqrZiMxCHd41cU9lwT0fY1iHAt/oXkv
MIME-Version: 1.0
X-Received: by 10.43.160.69 with SMTP id mb5mr162552icc.49.1400792568534; Thu, 22 May 2014 14:02:48 -0700 (PDT)
Received: by 10.64.148.98 with HTTP; Thu, 22 May 2014 14:02:48 -0700 (PDT)
In-Reply-To: <537E46DC.9000303@isi.edu>
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>
Date: Thu, 22 May 2014 14:02:48 -0700
Message-ID: <CA+mtBx8XnhPqhX_fgyp4O+5NR6kTiJPS-QAaw+K2xV_r5n4LyQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary=001a11c2d62c73b79504fa036fd8
Archived-At: http://mailarchive.ietf.org/arch/msg/tofoo/sPFA4RDJ9F6t09-ZUzUQ88Kr9Qw
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:02:54 -0000

On Thu, May 22, 2014 at 11:50 AM, Joe Touch <touch@isi.edu>; wrote:

>
>
> On 5/22/2014 11:43 AM, Tom Herbert wrote:
>
>>
>>
>>
>> On Tue, May 20, 2014 at 6:14 PM, Joe Touch <touch@isi.edu
>> <mailto:touch@isi.edu>> 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
>