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

Tom Herbert <tom@herbertland.com> Mon, 02 August 2021 14:38 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 808E93A00D9 for <tsvwg@ietfa.amsl.com>; Mon, 2 Aug 2021 07:38:47 -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 9XlFYlqXr7MI for <tsvwg@ietfa.amsl.com>; Mon, 2 Aug 2021 07:38:42 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 9F9DE3A00DB for <tsvwg@ietf.org>; Mon, 2 Aug 2021 07:38:42 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id p21so24779689edi.9 for <tsvwg@ietf.org>; Mon, 02 Aug 2021 07:38:42 -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=uckzMRBvyOI9nlezue40NBrSdJGLpoS1qrm+zjX91JY=; b=mogWnjCw87L/J00i0vBeRK557Vfjbe15XpBdrKMxCii2critVFseYUpPwgvPRXcSrf yjhxICKOtjKagHkWJJjitC4jeY8a3L7xT1qanpbUjPgzoEA9jmOMnvwx7SAaKf6aMga/ YTW+DAJQ2x7H2dBfUinkLucH6rlpvzOFenKkTuhgW1VXCG3puJ68Kg5Id06gIBvgadvN DLd7DnE2MBRQR0KUNipBUtXP5INQcV+vOgWvaDwKbN1/KBTQbCZlLRmhTSF0WRexXnip HsgUaXKYRQcIgP3HrZxFNMZqlZFnGSlhyl4jl/FfZbDXMJz/S2InbxD4ZinHqfK1nbm9 ZhGw==
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=uckzMRBvyOI9nlezue40NBrSdJGLpoS1qrm+zjX91JY=; b=rYqvSFyBIVbCJnAhTjRFirzObDh1VS4pfLt8Sa2LelaBgsxVycW8RIv00tekoLJYYQ OFc1OVr7zIQxg/e3awDMHGknT1NFzLr0JshFdnBboF+cvhcoaimzEJSZqpZQ5+XvOnuO v/GBMiDVxCV3Lf1d9mMZkEZ7nUIQ+R9a4C/50vN+ELFXEUfO/yjJhEjL1SjLUg8rWbOw h/SDRJGt3KQDjI3KqRA0t8g91AHoAvRI6pTILyU4W/uQ5vV8tqbw/wMXHATuTcSgO4hB zxmx07uayRW8TExDaHS8K6GU7RDP+ut7mhlkMIzgc5MAHp+NmKPBAcNiIQLHOdMiSYXU VHig==
X-Gm-Message-State: AOAM533HZCqghzAQPpjNej9JQoYdrpYcZq8MdEUW5QcZmAb1dZgxqm6o hdmW8Krk5vjvCNWukAAkP8rRlbUdtRJFoXPZBNSZ1A==
X-Google-Smtp-Source: ABdhPJw8bUe0kvf907hWcx/NLet+HDZuMCEpvGbPsnncWFJtJOdNBf1UOA0deLOb7lS7rk9qbU6vKF9eBsMWJMSC2/4=
X-Received: by 2002:a50:bb43:: with SMTP id y61mr19320019ede.22.1627915119802; Mon, 02 Aug 2021 07:38:39 -0700 (PDT)
MIME-Version: 1.0
References: <A0932E7C-183B-41EF-B2AA-838FC45A087E@strayalpha.com> <28339CB5-2C9D-4870-9F25-07D6BBF43BDD@strayalpha.com> <CACL_3VEo75pKTOhizO1AhvqW7vCkOnaerDi6UNRA6e5K5mKYfQ@mail.gmail.com> <F35E0828-1F8F-4D7C-A570-32A2F47F773F@strayalpha.com> <CACL_3VFdzrTXZ8rAGPF=hXJ56zwy9KRxqERO_9doVUB4wFft4g@mail.gmail.com>
In-Reply-To: <CACL_3VFdzrTXZ8rAGPF=hXJ56zwy9KRxqERO_9doVUB4wFft4g@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 02 Aug 2021 07:38:28 -0700
Message-ID: <CALx6S37XLfGBFVMCAhbFjKfsRrevbzOPxP9CT28cpzmzQRBwPw@mail.gmail.com>
To: "C. M. Heard" <heard@pobox.com>
Cc: Joseph Touch <touch@strayalpha.com>, 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/_kLcdQ6oLMRuC-2PDJRJeKmT064>
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: Mon, 02 Aug 2021 14:38:48 -0000

On Sun, Aug 1, 2021 at 4:23 PM C. M. Heard <heard@pobox.com> wrote:
>
> On Sun, Aug 1, 2021 at 3:56 PM Joseph Touch <wrote:
>>
>> The value in the terminal fragment is just the value that would have been in the original IP length before fragmentation, less the IP and UDP headers.
>>
>> That’s very simple.
>
>
> That's highly dependent on the details of the implementation,
>
>>
>> Whether it can be used to split off the trailing options requires a simple comparison - if FRAG_END > FRAG_OFFSET, then the trailing options are entirely in this fragment. If not, then not.
>>
>> The fact that per-reassembled datagram options look exactly like legacy options it similar in its simplicity, as is using TLVs for everything. It’s all about fewer different ways to do the same thing.
>
>
> Based on my own experience, I do not agree that this necessarily makes for a simpler implementation. But let's see what other folks think.
>
Mike,

No, it's not simpler for an implementation. In the current design
options are in trailers for legacy mode and headers in non-legacy mode
so by definition we need divergent code paths code paths for those two
case. In the non-legacy mode case we need to support both options in
headers and options in trailers within the same packet which
contradicts the principle of having fewer ways to do the same thing.
In any case, having divergent code paths isn't a problem for
implemenations, the real complication to implemenations would be the
requirement to process protocol trailers.

Tom

> Mike Heard