Re: [tsvwg] UDP options and header-data split (zero copy)

Tom Herbert <tom@herbertland.com> Sat, 31 July 2021 18:58 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 9AEED3A156F for <tsvwg@ietfa.amsl.com>; Sat, 31 Jul 2021 11:58:00 -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, 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 EFfSwQ1APWj5 for <tsvwg@ietfa.amsl.com>; Sat, 31 Jul 2021 11:57:55 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 07C4C3A156D for <tsvwg@ietf.org>; Sat, 31 Jul 2021 11:57:49 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id o5so23421976ejy.2 for <tsvwg@ietf.org>; Sat, 31 Jul 2021 11:57:49 -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=jfGEvtpUMa9xspkYjIiMI1F0P1Z2THS69p1q6syQbnY=; b=WKAAf6+qk6lkZ8h8JxDjBpzqc9/r9Mm3/WEAzZ0Dv4aGuZTLV7Z2ge9fsjIE5Zcr/d 03jKtP9RCqe5JCBfWnZMsIrp5Y1qnUg7st4zW8Nktatclki7mjE6Gtqqwk9UZZVMGldN wdka1SQ3jBoSPxo9snBX6UnlU5fcSh5YG6kHC6Mwj0IjqD2huW7rLj/+7yrJsfG29iBy /uHQU08tuZDhStY1j0agZrbC0/7E9o9k+tdKRlltzJpeeslhiCHZkT8BSQNUq0ZqVH7n TxOAVGNVVAAjwh6kTsemInUXjDZhaE3YaDUt954W7GchC5ePrRQqq4xM31JZXfoVbnxi NqFg==
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=jfGEvtpUMa9xspkYjIiMI1F0P1Z2THS69p1q6syQbnY=; b=K53Quey3f9EFYtldSUdBfsStP/R3I5FT8KoszOxvzhJ4mAX1ls8xP2UxnuwrRSjdph l3lttFz/vuuEAAeAtg0/tAXleMDr0fLNDnvWPJBlCSUPCVESf0/x0bLmP/+cU7G3lzZR qfg40BZN7NYi7MrUNWx56KGt+sUmjiBzeyefelRYpRaBFBzeolOCl/SzR1rkejndLO3+ 4somY9jT/hTuD1cKoYp4g6fGRzuEUeieqqQIgMQqWGXAGwWJ5QlRuAeLE4znX3IZPi6z I3PvEXOwqDz7FiaFq3gDhRtQVkv0H7MDhlgMGbSECxcn2LdRegNOrWKC/spv7/E7oSdL q5lQ==
X-Gm-Message-State: AOAM5302OeXIMB28lD9tgTvVmzCKBKvSVTJIDm8JVM3VL6C9OfjRKvtO or9anUuHRdBWKZ30r+B036J7VMAGGbcGj9GOAg9L5g==
X-Google-Smtp-Source: ABdhPJzd725uLppaM4CfObAUg/Ohz2hlQgkxvbyGyrR4rT4ty9hpqj9o4eIx6hGlkFp+VO/DNqz+xfaZFcXpMwVas7U=
X-Received: by 2002:a17:907:2719:: with SMTP id w25mr8479027ejk.239.1627757867571; Sat, 31 Jul 2021 11:57:47 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S37zzaZaWNygGt=YaZSAo1e5fTgqmi0ftK4q+puCfbXWGg@mail.gmail.com> <6073AC0D-C32A-4033-BC92-F828BA50BDF7@strayalpha.com> <CALx6S37Nf4U=6aGf7ov_7+UULzuD-DPP+gJzLyJ0vKxRELtLCQ@mail.gmail.com> <3CCB787D-CD9F-4380-9544-F5FEAFAF3E27@strayalpha.com> <CALx6S36pRhJFHnhh58tUabeoc8ScajfUYV1HOg=tPJvic8bJ9Q@mail.gmail.com> <CF65CA93-768D-4070-818F-8DA2D08F5BC3@strayalpha.com> <CALx6S36o8RR3v29A4fEp94O6qwpwU6PUAAAEgVMZidbQS3RvLw@mail.gmail.com> <7AAB2648-3789-44B6-A07F-DA9031AAC9A2@strayalpha.com> <CALx6S35VyMOdxKLxXzLhPJu6qDK8o8-+SgeV=u89bM3j9BeTSQ@mail.gmail.com> <0BB5684B-C164-4CA4-9208-185FEEECB4D6@strayalpha.com>
In-Reply-To: <0BB5684B-C164-4CA4-9208-185FEEECB4D6@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 31 Jul 2021 11:57:35 -0700
Message-ID: <CALx6S37zVVXnCH+Dv7_QXgwOoqcL4h0SThh+LnmAWn-5enprZQ@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/8ai_vd1v9xqS7HPLR5NvD3izHVs>
Subject: Re: [tsvwg] UDP options and header-data split (zero copy)
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: Sat, 31 Jul 2021 18:58:01 -0000

On Sat, Jul 31, 2021 at 11:34 AM Joseph Touch <touch@strayalpha.com> wrote:
>
> Hi, Tom,
>
> On Jul 31, 2021, at 11:27 AM, Tom Herbert <tom@herbertland.com> wrote:
>
> Joe,
>
> You seem to be missing my point. There are implementations that
> terminate UDP and CANNOT process protocol trailers; this is not just
> an inconvenient performance degradation.
>
>
> If that is the case, then they MUST NOT try to support UDP options. See below.
>
If UDP options cannot be used with UDP tunnel protocols, one of the
biggest use cases for UDP, then I believe the protocol is
fundamentally flawed. At the very least this needs to be documented in
the draft, and if UDP options are only meant to be used for certain
use cases that should be contained in an applicability statement in
the draft.

> Yes, that means that they
> can't use legacy mode, but I don't see the technical argument that UDP
> couldn't be productively supported by these implementations if UDP
> options are all contained in headers.
>
>
> Again, support for legacy receivers has always been a requirement of a solution.
>
> I do not believe this is an
> aberration, we know for instance there are HW routers terminating UDP
> tunnels, and it would be a delusion to believe these implementations
> could be fixed to support protocol trailers in a finite time. So if
> protocol trailers are a forced requirement, even in non-legacy mode
> which is what tunnels would use anyway since they're configured, it
> seems like we're excluding use cases such as UDP tunnels where UDP
> options might be compelling. Given this, what is your answer to
> someone who wants to use UDP options with UDP tunnels?
>
>
> There’s no way that endpoint can ensure it never sees non-fragment UDP options, so it cannot support UDP options.
>
For a tunnel, use of UDP options would just be another configuration
parameter at the end points; we don't need negotiation to send
non-legacy packets. If there's a mismatch in endpoint configuration
then the operator simply detects it and fixes it like any other tunnel
configuration problem.

> Joe
>