Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-09.txt

Erik Auerswald <auerswal@unix-ag.uni-kl.de> Sun, 02 July 2023 18:32 UTC

Return-Path: <auerswal@unix-ag.uni-kl.de>
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 BFC0CC14CE47 for <tsvwg@ietfa.amsl.com>; Sun, 2 Jul 2023 11:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x66zG9ff39on for <tsvwg@ietfa.amsl.com>; Sun, 2 Jul 2023 11:32:17 -0700 (PDT)
Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 4FC62C14F74E for <tsvwg@ietf.org>; Sun, 2 Jul 2023 11:32:16 -0700 (PDT)
Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 362IWIhO174426 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tsvwg@ietf.org>; Sun, 2 Jul 2023 20:32:18 +0200
Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 362IWEDp008799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jul 2023 20:32:14 +0200
Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 362IWEP6008798; Sun, 2 Jul 2023 20:32:14 +0200
Date: Sun, 02 Jul 2023 20:32:14 +0200
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: tsvwg@ietf.org
Message-ID: <20230702183214.GA5392@unix-ag.uni-kl.de>
References: <168805849623.15224.18038199673090941440@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <168805849623.15224.18038199673090941440@ietfa.amsl.com>
Author: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/z-eEJh60Id_2zgl1dHo5ZvY1wwU>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-09.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
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, 02 Jul 2023 18:32:19 -0000

Hi,

thanks for the additional text in section 4.4!

After re-reading the draft, I have noticed four additional issues resp.
potential improvements:


(1)

In section 4.3 on page 8, section 4.2 of RFC 8899 is given as reference for
a DPLPMUTD black-hole.  This should be section 4.3 of RFC 8899 (Black Hole
Detection and Reducing the PLPMTU) instead, I'd say.

OLD:

  (Section 5.2 of [RFC8899], Section 4.2 of [RFC8899]
  defines a DPLPMTUD black-hole).

NEW:

  (Section 5.2 of [RFC8899], Section 4.3 of [RFC8899]
  defines a DPLPMTUD black-hole).


(2)

Then there seems to be an inconsistency in a sentence in section 4.3 on
page 9.  There are three alternatives given for a probe packet, but the
first ("Probing using padding data") and the third (construct a probe
packet that does not carry any application data) seem to be the same.  I'd
suggest to just remove the last alternative:

OLD:

  A probe packet used to validate the path MAY use either
  "Probing using padding data" or "Probing using application data and
  padding data" (Section 4.1 of [RFC8899]) or can construct a probe
  packet that does not carry any application data, as described in a
  previous section.

NEW:

  A probe packet used to validate the path MAY use either
  "Probing using padding data" or "Probing using application data and
  padding data" (Section 4.1 of [RFC8899]).


(3)

IMHO the text would be easier to understand if all UDP Options used were
introduced together, i.e., in section 3, e.g., as follows:

OLD:

  In this specification, this is realised using a pair
  of UDP Options: the Request (REQ) Option and the Response (RES)
  Option [I-D.ietf-tsvwg-udp-options].

NEW:

  In this specification, this is realised using three
  UDP Options: the End of Options List (EOL) Option,
  the Request (REQ) Option, and the Response (RES) Option
  [I-D.ietf-tsvwg-udp-options].


(4)

Similarly, section 3.1 could also include all the UDP Options features used
for DPLPMTUD.  This could be accomplished by extending the first sentence
of section 3.1 and adding another bullet point before the first one:

OLD:

  The UDP Options used in this document are described in Section 9.7 of
  [I-D.ietf-tsvwg-udp-options] and are used in the following way:

  *  The REQ Option is set by a sending PL to solicit a response from a
     remote receiver.  A four-byte token identifies each request.

NEW:

  The UDP Option features used in this document are described in Section
  9.1, Section 9.7, and Section 13 of [I-D.ietf-tsvwg-udp-options] and
  are used in the following way:

  *  A sending PL uses the EOL option together with a minimum datagram
     length to pad probe packets.

  *  The REQ Option is set by a sending PL to solicit a response from a
     remote receiver.  A four-byte token identifies each request.


Regards,
Erik


On Thu, Jun 29, 2023 at 10:08:16AM -0700, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Transport Area Working
> Group (TSVWG) WG of the IETF.
> 
>    Title           : Datagram PLPMTUD for UDP Options
>    Authors         : Godred Fairhurst
>                      Tom Jones
>    Filename        : draft-ietf-tsvwg-udp-options-dplpmtud-09.txt
>    Pages           : 17
>    Date            : 2023-06-29
> 
> Abstract:
>    This document specifies how a UDP Options sender implements Datagram
>    Packetization Layer Path Maximum Transmission Unit Discovery
>    (DPLPMTUD) as a robust method for Path Maximum Transmission Unit
>    discovery.  This method uses the UDP Options packetization layer.  It
>    allows an application to discover the largest size of datagram that
>    can be sent across the network path.  It also provides a way to allow
>    the application to periodically verify the current maximum packet
>    size supported by a path and to update this when required.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-dplpmtud-09
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-udp-options-dplpmtud-09
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
>