Re: [tsvwg] UDP-Options: UDP has two ???maximums???

Paul Vixie <paul@redbarn.org> Sun, 04 April 2021 04:57 UTC

Return-Path: <vixie@redbarn.org>
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 6702E3A15B5 for <tsvwg@ietfa.amsl.com>; Sat, 3 Apr 2021 21:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 oDyGiweEgXPz for <tsvwg@ietfa.amsl.com>; Sat, 3 Apr 2021 21:57:09 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BA23A15B4 for <tsvwg@ietf.org>; Sat, 3 Apr 2021 21:57:09 -0700 (PDT)
Received: by family.redbarn.org (Postfix, from userid 716) id 794AA7599B; Sun, 4 Apr 2021 04:57:07 +0000 (UTC)
Date: Sun, 4 Apr 2021 04:57:07 +0000
From: Paul Vixie <paul@redbarn.org>
To: Joseph Touch <touch@strayalpha.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-ID: <20210404045707.gilsjcuynsyeolel@family.redbarn.org>
References: <48DA3058-3380-46AC-951E-27B28489AAF6@strayalpha.com> <846f084a-c441-1d2f-a858-e4d34d528c83@erg.abdn.ac.uk> <20210402231200.4q5czwbxswdneinr@family.redbarn.org> <2d36e27c-1470-35f9-3079-6a150e83c713@erg.abdn.ac.uk> <20210403202313.ojof3hcwj35xs67b@family.redbarn.org> <B1E3E640-42B5-452F-BB04-424B0AF10FE7@strayalpha.com> <20210404012903.qirmrspgkjjk6a64@family.redbarn.org> <15883BDF-644B-408B-A575-B73C4127471E@strayalpha.com> <20210404033128.adlr65aktcannjx6@family.redbarn.org> <C0D06E78-F444-46BB-BF4A-94C2D4832FB2@strayalpha.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C0D06E78-F444-46BB-BF4A-94C2D4832FB2@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1yIUKM2kOoQpH0E5HcE3Mym1O5I>
Subject: Re: [tsvwg] UDP-Options: UDP has two ???maximums???
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: Sun, 04 Apr 2021 04:57:11 -0000

On Sat, Apr 03, 2021 at 09:25:00PM -0700, Joseph Touch wrote:
> > i wasn't considering it unsafe. some kind of initiation signal would
> > be required though, or else the initiator would see a small set of
> > apparently empty UDP payloads coming back, and wonder why.
> 
> The same could happen for nearly any new variant of DNS, too.

well, yes, which is why RFC 2671 says:

+---
| 1.2. Existing clients will not know how to interpret the protocol
|      extensions detailed here.  In practice, these clients will be
|      upgraded when they have need of a new feature, and only new
|      features will make use of the extensions.  We must however take
|      account of client behaviour in the face of extra fields, and design
|      a fallback scheme for interoperability with these clients.
+---

> >> Although I appreciate this concern, TCP does the same kind of bursts --
> > 
> > TCP has a congestion window that commonly keeps burst size within range.
> 
> The window isn???t based on the ability to burst an entire window???s worth
> of messages back-to-back.

of course not. but it will be clamped by that limit if the limit is present.

> If you???re speaking of Ethernet, there is link layer flow control, e.g.,
> congestion notification messages or explicit on/off flow control intended
> to push this feedback to routers and endpoints.

that's what the spec says, sure. in practice, congestion is often a silent
killer.

> >> Agreed; that???s aided in UDP with options as per Gorry???s draft.
> > 
> > if we implement PLPMTUD/UDP for DNS, we're going to have a decades-long
> > period during which the far end doesn't understand UDP options,
> 
> s/UDP options/{TCP, QUIC, etc.}/
> 
> Yes, all new mechanisms take time. 

by "Gorry's draft" i took you to mean this one:

draft-fairhurst-tsvwg-udp-options-dplpmtud-04

which talks about "UDP Options" and i was talking about "PLPLTUD/UDP for DNS"
so please interpret my over-specificity (/UDP options/) as well-intentioned.

> PLPMTUD intends to cache MTUs per-endpoint exactly the same way
> that PMTUD did.

that's interesting! so, a DNS protocol speaker (framer of messages operating
at the packetization layer) who uses DNS/UDP messages of various sizes in
order to discover the PMTU, because the kernel routing table had no hint of
the MTU for the endpoint under consideration, will be expected to report its
finding to the kernel, which can store it in the routing table, where TCP,
QUIC, NFS and so on can find it?

i think this is a powerful idea and i'm in favour. but it's the kind of idea
that usually i like and others don't. so i'll be surprised if you don't have
to correct a misimpression here.

-- 
Paul Vixie