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

Joseph Touch <touch@strayalpha.com> Mon, 19 July 2021 21:32 UTC

Return-Path: <touch@strayalpha.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 E16A23A0B1C for <tsvwg@ietfa.amsl.com>; Mon, 19 Jul 2021 14:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 NJI927U90Nk9 for <tsvwg@ietfa.amsl.com>; Mon, 19 Jul 2021 14:32:45 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AFA3A0B68 for <tsvwg@ietf.org>; Mon, 19 Jul 2021 14:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FUNDwhK4siKO1gHllidazzICHInqy/VOg+w6HOyjxwE=; b=Khhgjcai+pZ2FxxCKFI/434Vq+ kc5+J8gNJn/qPtLomK+3VBJbR9SjeGPK2Y8Yx6avrCb2fCcUa0QcPzd2WRRu1Ir3t4Jaw+ZChghaO FYqGo5AD3xaGl6F1Zg7bZl9yodQuVHTvTMi0es6y5wkWgI+ZJZ3ktrvOyVrMf5IZ77MDr4ajIjW69 p6Um/x/7KhWfPMRhh53zZ6ZbWUDpFITOF+TYQukG3DhQo45mDYbDiFCAXxlX4wCCLbtzNYjgzWXJ4 E7VFnZj1kvMAkxtG+UPHXH28iB5Qm0RZKDiNpseQB0v6E6Ja69VTZQhfDgv0mo/WDdp3KljP6Rm1D UQiShZfQ==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:54937 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1m5asR-0017ZJ-KN; Mon, 19 Jul 2021 17:32:44 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S368+gozryvmkiZVk5jZsOJgtU96Mcpi8pqLBAqJObHh4A@mail.gmail.com>
Date: Mon, 19 Jul 2021 14:32:38 -0700
Cc: tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7ACEA2D-5F1D-4C23-8915-5F072781FB26@strayalpha.com>
References: <CALx6S34WtGABWJEL_CBJAhSFb9JpR97Dr9emX-K0PxUGZ3VvnQ@mail.gmail.com> <927E12B2-D77E-4810-BABC-18D090F0A022@strayalpha.com> <CALx6S37H6wAt4FyGqwm038R=GeiOY0Wt-YY1Hb+XDjGX4Cw_QQ@mail.gmail.com> <6ADBCB38-9C0B-4A43-8877-4177F162D001@strayalpha.com> <CALx6S368+gozryvmkiZVk5jZsOJgtU96Mcpi8pqLBAqJObHh4A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/IZKbXY69DRlibdba1awhHf9INXE>
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, 19 Jul 2021 21:33:03 -0000

Hi, Tom,

First, there’s a good reason to not assume we can put the fragment “whole packet” options in the first fragment: size. We currently have no limit on how much space options can use in general. Per-fragment options clearly need to fit inside the fragment with fragment data. But the options on the reassembled packet might be difficult to assume can be contained in the first fragment alone.

Further, you have proposed several scenarios that claim that users may either want or need to not support legacy mode UDP options, but do want to use fragment-based options. That’s not permitted in the current spec and never has been.

Mode is chosen by the transmitter, not the receiver. Support for legacy mode has always been required.

Further, putting a functionality limit (either in length or support for legacy mode) to enhance the performance of some implementations doesn’t seem prudent.

Joe