Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt

Tom Herbert <tom@herbertland.com> Fri, 09 July 2021 22:22 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF33A011B for <tsvwg@ietfa.amsl.com>; Fri, 9 Jul 2021 15:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Utk90GiECWx2 for <tsvwg@ietfa.amsl.com>; Fri, 9 Jul 2021 15:22:08 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 15C3C3A0113 for <tsvwg@ietf.org>; Fri, 9 Jul 2021 15:22:07 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id c17so18802328ejk.13 for <tsvwg@ietf.org>; Fri, 09 Jul 2021 15:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JW5oRcXMZueIZMVIhRBdhagFMW+2k2WyZ9Bf9u0oexw=; b=cuyIZmlcYp0WtXMZxEUwGs1mBkiNQ/VTChuK8tco7u6EDjIRBDM44l3mfD9+kY2OiW s84fPjLCVcXOELPDCForZXVexwoqLQzJOx9DvG+Fxh/5vGZ2c0MmK1PiFHH7rL7wi4Qg pVIXY+gy2KuuuAfWKYl5N+Yxkjw+iTQT6G3M0xDpMAn4xDGlxVli8Mv2nGHDX/Syf7b7 +OYecaakESbLGGlKA23ln41wNebkFVafRJK+orYTNYsDXVGLWylHmZhs6YwNrfxdm2BU 5YJAbZCUI+6XFb3APmB6I2swcmrrCkVWVWtizYkIoxkuWSeiG00CFNYR5mo1GWiWHwh9 L5zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JW5oRcXMZueIZMVIhRBdhagFMW+2k2WyZ9Bf9u0oexw=; b=tTAQHY1GBhNzAkYRoPirWXrtZUw+z9jryDOnEDmplv4ximxauw0jQdPrnkzuCEtl0C mpvXQ12mvKc/AnUvWmoExj80l9ey69w3UBZVjD1At2aLinIrm7QYjSrYORbxR1Bh1tlM 4vCT1oTa9EDzbBejwvzkPARurA2T3eoCoH1qBo46nHzy8cP2M/Zmg06b5tntVHAfUs6S g5DbgnhpSl2fwTS/Viem+6mwJoDzcIJNge2dWY2GUpL0iW/S87DHqP9TKmgBf66O1xuZ hu3C4+X0ZsR7VvhbAd/repdkT+0dU6zlsAncpRGy/MsdB5xOYWSHEyKwd9aLUpks/9LK Uugw==
X-Gm-Message-State: AOAM532V4rQeBd211ogyJRumh6oiqqF2f0dHwrcGNHJoSWJDLpUa0IMd PnfMEWPG3dTEhuxBfYnpvKstpN5qD+LYWwT/kOxB7A==
X-Google-Smtp-Source: ABdhPJz+3yPrfBbrIJE5ii4YDBql1R4p7P+xRU+2nNBd5k2kdhJiKFW+qzMYKyuzd0F7AQ83sDAo+6qHxzKl02vy1Yk=
X-Received: by 2002:a17:906:b204:: with SMTP id p4mr11891708ejz.239.1625869324867; Fri, 09 Jul 2021 15:22:04 -0700 (PDT)
MIME-Version: 1.0
References: <162408795080.21706.5548660195641640175@ietfa.amsl.com> <C2C396E7-B728-496E-841B-D9F64004D3E3@strayalpha.com> <CACL_3VHC55cdu96=5OuNKmaaXrvDY5wkYid9a+j6=VtQrvJhZg@mail.gmail.com> <5086F1C2-55C9-4BD4-BB80-9C247E379204@strayalpha.com> <CALx6S373DmsGAncT8j2rGdpSfQ8q6pZi7iTVw4geZuxQdbA-sA@mail.gmail.com> <6E26E6BD-9AC0-46FF-8BA5-EDA016F840CE@strayalpha.com>
In-Reply-To: <6E26E6BD-9AC0-46FF-8BA5-EDA016F840CE@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 09 Jul 2021 15:21:53 -0700
Message-ID: <CALx6S352p8rboxD9k3bebLvep0rwk37y5avxbqFaFCsuQ_Nt2w@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: TSVWG <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HwPXiWTkWtlzuNmc3YKJfGgMYZw>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2021 22:22:14 -0000

On Fri, Jul 9, 2021 at 8:06 AM Joseph Touch <touch@strayalpha.com> wrote:
>
> Hi, Tom,
>
> > On Jul 8, 2021, at 10:13 AM, Tom Herbert <tom@herbertland.com> wrote:
> >
> > On Wed, Jul 7, 2021 at 10:25 PM Joseph Touch <touch@strayalpha.com> wrote:
> >>
> >> Hi, Mike,
> >>
> >> On Jun 26, 2021, at 10:13 PM, C. M. Heard <heard@pobox.com> wrote:
> >> …
> >>   OK on most points, but I strongly object to the following when OCS is mandatory (as is the case when UDP CS <> 0):
> >>
> >>      Note that a receiver can compute the OCS checksum before processing
> >>      any UDP options, but that computation would assume OCS is used and
> >>      would not be verified until the OCS option is interpreted.
> >>
> >>   If I perform the computation before processing any options, and OCS is mandatory, it would be foolish of me to waste any more effort seeking the
> >>   OCS option in the TLV chain. I already know that the option area is invalid,
> >>
> >> How exactly do you know this? If OCS is mandatory, you need to find it (seek it in the TLV chain) in order to know whether the value you compute differs from the value in the option.
> >>
> >> Performing the computation early just allows offloading if desired; the value computed still needs to be checked.
> >>
> >>   and I should not try to parse potentially invalid TLVs. It is both unsafe and a waste of cycles.
> >
> > If the OCS is in a TLV in an arbitrary position in the list, how is
> > wasting cycles avoided?
>
> Everything we’re doing wastes cycles by some metric, e.g., if the checksum fails or if the TLV needs to be parsed and there’s no OCS.
>
> This issue isn’t whether it’s wasted cycles; it’s WHEN. If we force a fixed header in a fixed location, then parsing it is a waste to everyone who isn’t using OCS on every packet - which is bad design, because those are the users whose performance we should be conserving.

I don't know if it's a bad design, but I do know that IPv4 and TCP
have had a fixed checksum field that covers options for over forty
years. Not unsurprisingly, implementators have long since figured out
how to optimize checksum calculation. Checksum offload is ubiquitous
and CPUs have add-with-carry instructions of 32-bit, 64-bit, or vector
instructions to optimize checksum calculation. Also, because of the
way checksum offload works both senders and receivers of UDP options
are likely to compute the checksum over the surplus area regardless of
whether the checksum field is present-- even today, a legacy receiver
will compute the checksum of surplus area in order to offset the
checksum received from the device in checksum offload. AFAICT, no
users are complaining about Internet checksum performance.

In contrast to checksum calculation, walking TLV lists is still
considered a major problem for performance. The algorithm is an
inherently serialized loop that requires a number of conditionals
(i.e. we need to switch on the type and we need to check the length of
each TLV to make sure it is in bounds). For instance, walking over
sixty-four bytes containing with say eight TLVs is more work than it
would take to compute the checksum over those same bytes. If we need
to walk a TLV list twice, the first to find the OCS and second pass to
actually process the TLVs, I believe it is a significant performance
hit.

Tom

>
> The approach in the doc does potentially waste cycles - but only when OCS is either far into the TLV or required and not in the TLV at all - e.g., because of corruption. Both are intended to be very rare events, so given we’re going to waste cycles one way or the other, IMO this is the better place to potentially waste them.
>
> > It seems like we need to either parse the list
> > fishing for the OCS, or start processing TLVs and throw out any work
> > that was done if an invalid checksum is found.
>
> If OCS is needed, you need to process *it* first - so even if you walk the TLVs, you aren’t doing any work on them except that walk until OCS is checked.
>
> Note that we say OCS *SHOULD* come first, likely only after NOPs, but we don’t need to force this. If someone wants to put the OCS later, then that’s their choice.
>
> >>
> >> You can’t know when OCS is wrong until you find it in the TLV.
> >
> > That presumes that the corruption causing the checksum to be invalid
> > doesn't affect the ability to find the OCS TLV.
>
> No; it’s a statement of fact. If you don’t find it in the TLV at all and it’s not required, it’s not wrong. If it is required (because UDP CS<>0) *AND* it’s not in the TLV, then you have an invalid packet (not an invalid checksum). Both will be detected. Again, the chance that corruption happens that destroys the TLV chain is possible but of low probability.
>
> > However, if a data
> > corruption is in the kind field of the OCS or if a length field of a
> > previous TLV then the OCS TLV might no longer be identifiable in a
> > packet. In these cases, the OCS is wrong
>
> It would be missing. You can’t say something that isn’t there is incorrect except for being missing.
>
> > however, unless the OCS is
> > mandatory for this packet, we don't know the OCS is wrong and we
> > incorrectly accept the packet.
>
> Yes - that’s what happens.
>
> > I have brought up this issue several
> > times that a checksum in a TLV, like OCS, cannot protect itself from
> > corruption; it would be great to see some discussion of this problem
> > in the draft.
>
> An error in the TLVs is likely to cause the chain to have a parse error too, at which point we would drop the options anyway.
>
> Do you really think we need to discuss the case where:
>         - the TLV chain has an error that hides use of OCS when it is optional
>         AND
>         - that TLV chain does not have a parsing inconsistency
>         (e.g., a length that is nonsense either in relation to its kind or jumps past the end of the packet)
>
> We can discuss that, but IMO that’s a reasonable risk given it’s likelihood.
>
> >> Additionally, the following paragraph, while an improvement over the -12 version, is still not good enough when OCS is optional:
> >>
> >>>> When present, the OCS SHOULD occur as early as possible, preceded
> >>   by only NOP options for alignment.
> >>
> >> When UDP CS == 0, either that SHOULD needs to be changed to a MUST, or the receiver needs to be excused from bothering to check OCS.
>
> It’s the sender’s perogative to use OCS even when UDP CS==0.
>
> If the sender adds it, the receiver should process it if found. If the lack of a UDP CS causes undetected errors elsewhere, that’s a choice the sender made.
>
> >> I must once again question the wisdom of ever parsing a list of TLVs that are not covered by a checksum (and I think IPv6 made quite a big mistake to do so with its options).
>
> Doesn’t this viewpoint contradict the request to excuse the receiver you just made above?
>
> >> I don’t see why SHOULD isn’t sufficient. First, it’s obvious that there could be utility in NOPs preceding OCS. Second, we don’t know what other options a user or implementer might want to occur first. You have to parse the TLV one way or the other to find OCS - even if it’s first. If it’s not, you still either find it or you don’t. Yes, earlier is better - but not MUST better. I see nothing that will not work if OCS is not first so no rationale for forcing this.
> >>
> >>   I'd like to bring up another point that came to my attention during an off-list discussion with Tom Herbert, namely that optional checksums save no
> >>   work for an implementation that has generic checksum offload; in fact, they create more work by creating more special cases. He makes the point
> >>
> >>   -- convincingly, as far as I am concerned -- that optional checksums are largely a relic of the past. My preference would be to see support for UDP
> >>   CS == 0 be an option that consenting endpoints may use but that are not required to be implemented.
> >>
> >> I don’t understand what that would mean, but this argument appears to ignore the most important current use case - tunnels. Tunnel systems do not necessarily rely on offloading hardware because the packet processing occurs after the packet has already passed the interface, in many cases.
> >>
> > A very common use case of tunneling is network virtualization where VM
> > guests are sending TCP/UDP packets that are encapsulated by a
> > hypervisor in VXLAN, nvgre, etc. In this case checksum offload of the
> > transport checksum in the guests packets is important for performance.
>
> Encapsulation by a hypervisor that uses checksum offload. Hmm. I’ll need to think about how that works - are you sending packets between processes of a CPU by sending them out to the network card and back?
>
> Yes, hardware integration will require changes to make UDP options work. Some may be able to do this with just reprogramming, some will require new hardware. We can’t design solutions for only the hardware optimizations that exist today.
>
> Joe
>