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

[Gorry Fairhurst <[e-mail]>]

On 02/07/2023 19:32, Erik Auerswald wrote:
> 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).

Thanks, done in this PR for the editor's version.

See:

https://github.com/uoaerg/draft-udp-options-dplpmtud/pull/28/files#diff-768474f5b48a4bc0b418862bf044141c340e502c6f99947161841e6137601c85

>
> (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]).
>
I agree this was unclear, I suggest the revised text in the PR.

> (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].
>
Kind of, but I think the focus is on REQ/RES. Maybe though to be 
complete I could suggest:

The method also uses the the End of Options List (EOL) Option <xref 
target="I-D.ietf-tsvwg-udp-options"></xref>. to
introduce padding to set the size of a probe packet.</t>

> (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:

I'm inclined to remove the cross reference. References to sections are 
rather fragile

if specs are updated, and the sections can be found from the ToC, so 
perhaps it

might be better without, see PR.

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

I see, I propose;

                      <t>A sending PL can use the EOL option together 
with a minimum
                        datagram length to pad probe packets.</t>

>
>    *  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, [e-mail] 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
>>
>>
Best wishes,

Gorry