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

[Gorry Fairhurst <[e-mail]>]

These NiTs have now been resolved.

Gorry

On 02/07/2023 22:25, Erik Auerswald wrote:
> Hi Gorry,
>
> On Sun, Jul 02, 2023 at 07:59:34PM +0100, Gorry Fairhurst wrote:
>> 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
> The PR looks mostly good, but the "black-hole" reference is mixed up.
>
> Currently, this draft has two references to "black hole" as described by
> RFC 8899.  One references section 4.2 (wrong), one references section 4.3
> (correct).
>
> ```
> $ grep '4\..\.  Black.Hole' rfc8899.txt
>       4.3.  Black Hole Detection and Reducing the PLPMTU
> 4.3.  Black Hole Detection and Reducing the PLPMTU
> ```
>
> The linked pull request changes the correct reference to be incorrect.
>
>>> (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.
> Looks good. :-)
>
>>> (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>
> That looks good, too (but there is a stray period after "</xref>" before
> "to").
>>> (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.
> That looks good in the 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>
> That is fine.
>
>>>    *  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
> Regards,
> Erik