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

Joseph Touch <touch@strayalpha.com> Sat, 31 July 2021 17:33 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 6EDE83A10D4 for <tsvwg@ietfa.amsl.com>; Sat, 31 Jul 2021 10:33:07 -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 rcdW3BEPW75V for <tsvwg@ietfa.amsl.com>; Sat, 31 Jul 2021 10:33:02 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 CDAAF3A10D0 for <tsvwg@ietf.org>; Sat, 31 Jul 2021 10:33:02 -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=xC8LHZ5pxq/pP5q9hjg8+LGWHpUPHbO2ntHXFNj9HEs=; b=dfM7uEAor+rlewbxceYRKPThNg I8A0gvcdOC3m1SLa0CCDSgqmuog3Mlr851RVLLuowAT9/v73miaIwmLpDZRqJOzON+wcjD05XyvfM gkuCaerzv+lJvTltADwMscbEOqbLFZncNuqvnzXmclyB4tMg94CnfefXEaagKLw1hOqUt+cIEocPF 0RekPdYKUZhAppbT8Te5cwrcLUWib6tb9cQeArPuakkC6WgZzTGSM59DDuZG7qMC2kM8H3BkbLuEx UncbMsVQr9Tsq7A0oAnKLK674T99UdXGq310EQlNJ8u4No2k5RCs+odM5SpR+kWd///4gAA3btynR UFaZH3wA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:60531 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 1m9sr2-000gd7-Gh; Sat, 31 Jul 2021 13:33:01 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CALx6S36o8RR3v29A4fEp94O6qwpwU6PUAAAEgVMZidbQS3RvLw@mail.gmail.com>
Date: Sat, 31 Jul 2021 10:32:53 -0700
Cc: tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AAB2648-3789-44B6-A07F-DA9031AAC9A2@strayalpha.com>
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>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
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/3Fq8yPU6sryFSpCetQK0lNVvkjw>
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 17:33:08 -0000


> On Jul 31, 2021, at 10:17 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Sat, Jul 31, 2021 at 9:18 AM Joseph Touch <touch@strayalpha.com> wrote:
>> 
>> Hi, Tom,
>> 
>> On Jul 31, 2021, at 7:53 AM, Tom Herbert <tom@herbertland.com> wrote:
>> 
>> On Fri, Jul 30, 2021 at 8:35 PM Joseph Touch <touch@strayalpha.com> wrote:
>> 
>> 
>> Hi, Tom,
>> 
>> On Jul 20, 2021, at 7:49 AM, Tom Herbert <tom@herbertland.com> wrote:
>> ...
>> Limiting use to fragment mode is not what I am suggesting.
>> 
>> ...If trailers are required in all use
>> cases, then devices that don't support them can't use UDP options even
>> if they're only interested in non-legacy mode uses
>> 
>> ….
>> 
>> 
>> I don’t follow this line of logic.
>> 
>> You claim that you’re not limiting use to frag-only, but then talk about “if trailers are required”.
>> 
>> There’s no IF. They are.
>> 
>> 
>> Joe,
>> 
>> That is an opinion, not an established fact.
>> 
>> 
>> Trailers have been shown to be the only way to support legacy mode use of UDP options. Nobody else has ever suggested or accepted that legacy mode is an optional part of this spec.
>> 
>> If you want to convince
>> us that trailers are a requirement in all use cases, specifically
>> non-legacy mode, then please provide at least one example of options
>> that could not be correctly conveyed in protocol headers.
>> 
>> 
>> Legacy mode.
>> 
>> Given that
>> we have many examples of successful protocols that have protocol
>> options in headers, IP options, TCP options, and IPv6 which provides
>> the example of how per fragment options and options for the
>> reassembled packet, I am dubious the need for trailers can be proven.
>> 
>> 
>> We’ve already done so for legacy mode.
>> 
> But not for non-legacy mode.

They’re not separable. If you can’t support non-legacy, you don’t support UDP options.

This has never been a “pick and choose” spec.

>> If you’re looking for a successful version of trailers, perhaps Ethernet will convince you? How about HTTP since 1.1? HLDC and PPP?
>> 
> No, it's not convincing. HTTP is an application layer protocol.
> Ethernet, HDLC, and PPP are layer 2 protocols that have headers and
> use trailers for only FCS and CRC for the benefit of hardware
> implementation.

It doesn’t benefit or hinder hardware implementation. It affects queuing delay in either case, but that’s not an issue for an endpoint protocol like UDP.

> You could also add ESP to this list which again
> primarily uses a header and puts authentication data. These are not
> comparable to UDP options which is an open ended list of TLVs which is
> more likely to be processed in software. For network layer and
> transport layer protocols, protocol headers are the longstanding
> convention.

And if we were designing one from scratch, I would agree.

> Implementations have assumed this convention, and
> introducing a protocol that goes against this convention will have
> adverse effects.

We don’t have a choice for legacy mode.

> The effects could be loss of performance or
> functionality, or outright complete inability to support the protocol.

Performance, yes. But by your own admission, the TLV is likely to be processed in software (wherever that is) anyway. 

>> If an implementation can’t deal with trailers, it can’t support UDP options - the core set is “all or none”, not “pick what you want”.
>> 
>> 
>> If an implementation can't deal with trailers, then that means that
>> users of those implementations can't use UDP options.
>> 
>> 
>> Again, that IS the point.
> 
> I don't see how that isn't arbitrarily and knowingly eliminating the
> number of users and use cases for the protocol.

The result of a “pick and choose” protocol is the same, if not worse.

Again, like most of the IETF, we’re focusing on ubiquity over performance.

>> If users can[’t] use
>> the protocol we're defining then what is the point of bringing it to
>> IETF?
>> 
>> 
>> (I’m presuming you meant “can’t” above)
>> 
>> We have two types of legacy users:
>> - legacy UDP endpoints in general
>> - updatable endpoints with legacy UDP acceleration hardware
>> 
> What does "updatable" mean.

I was giving your approach the benefit of the doubt that the software could be updated to support legacy acceleration hardware.

If that can’t happen, then UDP options can’t be supported because they aren’t right now.

> If there is some piece of hardware that
> doesn't support protocol trailers, it's not like we can just call up
> the vendor and they'll fix it in a month.

Right. But you CAN just have it push the whole reassembled packet with trailers to the OS and let the OS software handle the rest - just like it would need to for legacy mode anyway.

> Fixing hardware takes years,
> and that assumes the vendors see any business value to invest in the
> fix which only exists if UDP options use becomes prevalent and support
> is being demanded by customers.

Agreed - which is even LESS reason to try to optimize for today’s hardware.

>> Your claim is that we can’t support both groups, especially if they interact.Even if we were to accept your claim, we would always choose to support legacy endpoints in general. If we have to sacrifice, we should sacrifice performance to maintain interoperability.
>> 
> To the contrary, my claim is that we need to support as many users as
> possible. Avoiding a requirement for protocol trailers aligns with
> that goal, requiring protocol trailers opposes that goal and limits
> the number of users that can use the protocol.

How does leaving legacy endpoints out “support as many users as possible” vs. merely using software to complement hardware acceleration, the latter which would support all users?

Joe