Re: [Softwires] [Int-area] UDP zero-checksum in IPv4

Tom Herbert <tom@herbertland.com> Thu, 10 March 2016 23:45 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2CB12DDF2 for <softwires@ietfa.amsl.com>; Thu, 10 Mar 2016 15:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 JmaghfrE2c9r for <softwires@ietfa.amsl.com>; Thu, 10 Mar 2016 15:45:19 -0800 (PST)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B31812DCA9 for <softwires@ietf.org>; Thu, 10 Mar 2016 15:45:19 -0800 (PST)
Received: by mail-ig0-x22f.google.com with SMTP id av4so5894126igc.1 for <softwires@ietf.org>; Thu, 10 Mar 2016 15:45:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=74J6scK5AWOEdW/7yXQCQyIDe8ZpIIqb6cm9nlagVpQ=; b=qjmELA1KAXPPr/NyciN7vASk5I0QVk5IRoHssMyNN63VXUx62obsocjpRjfIkKTmrb XG1R1xpVKpsGq3Y+mtK/mkOMotzB9bussmfFV4pOZVuOnC0tBUju84xeFQkz3+3xMH4z FQE0UDvf7wX0ZwJ5fheUSpGuFZKPZ/MIOXlk3uZ5dZmWbEn5Az4SSTyxmdsYzu7gOT37 /Lxnq6h4JSHzHmQST4E1xJAWxYoTPPHEgbEOfQwleEPbyjvFn7zpEZbJ5dHNWD5AZlDi GH8Wjw87bqVIOcH2N0DbSDpYWaLt5BEUt1/owCHEKUryLvEfYR8rHqN7bmOHSKNh3gpS fJ1g==
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-transfer-encoding; bh=74J6scK5AWOEdW/7yXQCQyIDe8ZpIIqb6cm9nlagVpQ=; b=eIQToiRnjBnF0DCDQJTDn3Rrhw3Mfp408/0i5oOJEKsipM+619ZUgg1AukJ10JWIPH hDCQ206eTVVMLkFltv4BHyyuQpIjAzEEhL4WBInNlItOWkglAONnX/kjKmOBeCOhnPLg 5/5epeiCJn5nMg96kXU/NkhqG22fBXJgS8oVEElt92W+n8QdPoDnL9jis2NEhAzSht1J d3pD7Nf0yuOO/as4NhEiwst3B6itkQzKblOMf5pW2QoorQfK/getGVh7YBtZOxF3lfHH zXJPKcGT1N3akFxTB6F4wJ/DBybuOmNmAK+HFlkVrNDM6lM8n3COLE9o0PMoKdawCbtQ Nucg==
X-Gm-Message-State: AD7BkJKOM1xTAEzJoXqdcLngchYzv4v+R36lRDJ+SoQjsl87dfvLUqDBq0T/l1QG0ZBRiVLrP9m8Hilnw823Pw==
MIME-Version: 1.0
X-Received: by 10.50.141.164 with SMTP id rp4mr1059527igb.89.1457653518569; Thu, 10 Mar 2016 15:45:18 -0800 (PST)
Received: by 10.107.160.203 with HTTP; Thu, 10 Mar 2016 15:45:18 -0800 (PST)
In-Reply-To: <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com>
References: <7921F977B17D5B49B8DCC955A339D2F0BEA21EC5@US70UWXCHMBA05.zam.alcatel-lucent.com> <64044A42-0775-4ABC-B7BD-3541316B0E81@cisco.com>
Date: Thu, 10 Mar 2016 15:45:18 -0800
Message-ID: <CALx6S34t3KVfEOnh+3vGqZJ1OQUUXg5CwSquaxaWj47khQqFSQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/softwires/YFHv-2dqauqSPOWVvJwLthKLgqw>
X-Mailman-Approved-At: Mon, 14 Mar 2016 08:14:51 -0700
Cc: "softwires@ietf.org" <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "maprg@irtf.org" <maprg@irtf.org>
Subject: Re: [Softwires] [Int-area] UDP zero-checksum in IPv4
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 23:45:21 -0000

On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>
>> On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com> wrote:
>>
>> Hi,
>>
>> Does anyone have any info on the percentage of UDP packets with zero-checksum
>> for IPv4 packets in today’s networks (enterprise, internet, any network).
>> Seems like there is not a whole lot of info about this on the WEB. Anyone has any firsthand/realworld experience with this? Thanks.
>>
>> Kris
>
> A good place to start might be https://tools.ietf.org/html/rfc6936
> 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
>      Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format:
>      TXT=99557 bytes) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6936)
>
> The big consideration there is a middleware device (usually a router, but potentially something else) that is receiving packets at line rate one a set of interfaces and funneling them to another interface on which it is obligated to send them tunneled in UDP packets, or a corollary device at the other end of the tunnel. It would be theoretically possible to add hardware that could parse to the correct point and calculate the checksum while the data being received was stored into memory. However, practically, that is far more likely to be done as a second step, to packets it is applicable to. The configuration of a tunnel that creates or verifies a UDP checksum on a tunneled datagram, in such a case, is essentially a DOS vector.
>
Note that this problem is mostly specific to switches that lack HW to
efficiently perform checksum. On the host side, we have long standing
support in NIC HW to to perform checksum offload (whether UDP sends
zero checksum in IPv6, checksums are always used in TCP so we need a
host solution regardless!). Due to the capabilities of currently
deployed NICs, we get much better performance with the UDP checksum
enabled for tunnels when sourcing or terminating tunnels on the same
host that sends or receive an encapsulated TCP packet-- in fact the
default was recently changed in Linux to enable checksum for UDP
tunnels (it can still be disabled by per tunnel configuration).

Tom

> Any discussion of "percentages of traffic for which X is true in the Internet" are necessarily vague and hand-wavy. The Internet is the proverbial elephant, and those that would statistically describe it are the proverbial philosophers. How one describes it has a lot to do with what part of it one touches.
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>