Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)

Spencer Dawkins at IETF <> Fri, 10 April 2020 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C67A63A0BD0; Fri, 10 Apr 2020 07:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r7lxfqjJ4EYc; Fri, 10 Apr 2020 07:49:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38BB33A0BCD; Fri, 10 Apr 2020 07:49:04 -0700 (PDT)
Received: by with SMTP id h6so1545889lfc.0; Fri, 10 Apr 2020 07:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MpsSiwjQSH4HfYfR0k2bIDOOAjeDVuC7Fqsy6uw3fbU=; b=AbvADfAdFzLK1x3PInVzWa3YmpmEJQIZEHyvhQIPLYo0AKwNTdscfqgE3WWuZCz08R Jb9+5fP31VbDSlpAEJNLaP9XjEy+2fKhKeW5hWU1nfkfb6Y6fN5+ViEDyeiXT/ihCCVM PMHDm44BfvsuoaexS+KnfL2zclrSEpqyQhw2xpt03rIkQz19a/EIpKO8mVkayfL5Jsm6 Tdqnq64PWM24KLfjExR/swNgwwFgixZeShpRClW16Gc3gh2HZNCVSaYHtqsAsCKy1+EM FCrXlE+Y8tPDrppPvpvA3yYbABLD/DIvAxEZbttnB2bSaypBUnPG0YjONbJpZP2pTy9e e+gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MpsSiwjQSH4HfYfR0k2bIDOOAjeDVuC7Fqsy6uw3fbU=; b=c7DHC2cNiaNiYrV2a2AHepccS+bbhQaDjFvvViAXkEFQj++EvbLN7dJKKpbDvPjAxC 89rIgcb7c0N0cFZQKDBZvoQ+POSS7NfF3YfUuYbBXLfiSPFJdpUXbQr8XVYqNo5KlrRo zCRcIO/4szT7JRjxmDQgjqeGUfwPcaBes9A9WMYYkJu9DAgBj28BYXu40+0AlWQZykLt rqVz7BklsZG3SSmsCOAzrrYi+EZAH7oVjzwzooB2g+cHLKDnop5ySsDSM5PHlmlKiOgR uy0XpZx4TReJrfjBYsyLySvEgSAZl1ne+0kN4C026R7P0axK80/B698ZTtiYr3p8tTJL 8Jvw==
X-Gm-Message-State: AGi0PubFgeRwUvbqFEXS6KutjmEu3Uj40IHqNbT9+vVDYCdhlxjhkDOL rBOWqds1vO7eJrq/jSHOFphEA7QLWd59AM+Le6Gjt6Uh
X-Google-Smtp-Source: APiQypI+JQs8wLVq5CzCbVYi/lJNAMwmdM68BfAyR4PPnhBpnEpPQ80VWyPBk7rq0UzMIL1/3FmqVAW++jokU60wX7I=
X-Received: by 2002:a19:7411:: with SMTP id v17mr2873554lfe.27.1586530142446; Fri, 10 Apr 2020 07:49:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Fri, 10 Apr 2020 09:48:36 -0500
Message-ID: <>
To: Jonathan Morton <>
Cc: "Rodney W. Grimes" <>, Gorry Fairhurst <>, "" <>, Robert Wilton <>, "" <>, "" <>, The IESG <>
Content-Type: multipart/alternative; boundary="00000000000090e7d205a2f0d5ab"
Archived-At: <>
Subject: Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Apr 2020 14:49:06 -0000

Hi, Jonathan,

On Fri, Apr 10, 2020 at 9:02 AM Jonathan Morton <>

> > On 10 Apr, 2020, at 4:38 pm, Spencer Dawkins at IETF <
>> wrote:
> >
> > ISTM that asking people to poke at this and report back in MAPRG is an
> excellent idea. Depending on whether there are still "relatively few MTU
> values in use" or not, it might then be useful to consider either updating
> the table of commonly-used values, or saying "binary search will probably
> work fine now".
> In connection with this, it's perhaps worth noting that some applications
> won't need to establish the precise MTU, only the minimum number of
> fragments they need to use for their jumbo datagram.
> For example, a 10,000 byte IPv4 packet can fit through a 1500-byte MTU
> path in seven 1446-byte fragments, but not in six 1684-byte fragments.
> (The calculation is different for IPv6 due to the larger headers.)
> Refining this distinction further only becomes relevant when datagrams of
> different sizes have to be sent over the same path, or when a stream
> transport is involved so that testing specific divisors is not helpful.

Thank you for pointing that out! I've also been ignoring jumbo frames,
which weren't a thing in 1990 because we were still trying to get Ethernet
to work well over coax, and I suppose there'd be some interaction there,

> So a variety of search algorithms may be useful in different circumstances.

Yup. I hope the next stop is in MAPRG, because this does seem useful.



>  - Jonathan Morton