Re: [tsvwg] New revision of DPLPMTU - Asking for WGLG in Sinagpore

G Fairhurst <gorry@erg.abdn.ac.uk> Mon, 25 November 2019 16:03 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 D99AB12098F for <tsvwg@ietfa.amsl.com>; Mon, 25 Nov 2019 08:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 lChAyw6P7X7X for <tsvwg@ietfa.amsl.com>; Mon, 25 Nov 2019 08:03:10 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id E200C1208B0 for <tsvwg@ietf.org>; Mon, 25 Nov 2019 08:03:09 -0800 (PST)
Received: from G-MacBook.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1355C1B00257; Mon, 25 Nov 2019 16:03:06 +0000 (GMT)
Message-ID: <5DDBFB39.5060302@erg.abdn.ac.uk>
Date: Mon, 25 Nov 2019 16:03:05 +0000
From: G Fairhurst <gorry@erg.abdn.ac.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tsvwg@ietf.org, Lars Eggert <lars@netapp.com>
References: <5DC9AE0A.20707@erg.abdn.ac.uk> <B5B741C8-9C79-480F-9498-8E04FFBC2132@eggert.org>
In-Reply-To: <B5B741C8-9C79-480F-9498-8E04FFBC2132@eggert.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rs4J7TmFvvgk8AcwGe8R3f6WwDk>
Subject: Re: [tsvwg] New revision of DPLPMTU - Asking for WGLG in Sinagpore
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: Mon, 25 Nov 2019 16:03:13 -0000

Thanks very much for the review. We have now revised the draft. Please 
see responses inline.

Gorry

On 12/11/2019, 07:35, Lars Eggert wrote:
 > Hi,
 >
 > On 2019-11-11, at 20:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
 >> Could I ask ask you to look at the latest spec for DLPMTUD?
 >> https://tools.ietf.org/pdf/draft-ietf-tsvwg-datagram-plpmtud-09.pdf
 > here is a short review
 >
 > Lars
 >
 >
 >
 > INTRODUCTION, paragraph 15:
 >> Table of Contents
 >   There seem to be some editing labels in the ToC; xml2rfc issue?
XML2RFC v3 format - Now resolved.

 > Section 1.2., paragraph 2:
 >>    In contrast to PMTUD, Packetization Layer Path MTU Discovery
 >>    (PLPMTUD) [RFC4821] does not rely upon reception and validation of
 >>    PTB messages.  It is therefore more robust than Classical PMTUD.
 >>    This has become the recommended approach for implementing PMTU
 >>    discovery with TCP.
 >   Would maybe omit "with TCP" given that the point here is that it can
 >   be a general mechanism.
 >
done.

 > Section 6., paragraph 0:
 >>    6.  Probe loss recovery: It is RECOMMENDED to use probe packets that
 >>        do not carry any user data.  Most datagram transports permit
 >>        this.  If a probe packet contains user data requiring
 >>        retransmission in case of loss, the PL (or layers above) are
 >>        REQUIRED to arrange any retransmission/repair of any resulting
 >>        loss.  DPLPMTUD is REQUIRED to be robust in the case where probe
 >>        packets are lost due to other reasons (including link
 >>        transmission error, congestion).
 >   The recommendation in the first sentence seems a bit too strict, and
 >   is then lessened in the following text anyway. I'd say "It is
 >   RECOMMENDED to use probe packets that do not carry any user data that
 >   would require retransmission if lost." Because this mechanism can
 >   apply to partially-reliable protocols or protocols that can recover
 >   lost data by other means (e.g., FEC), where sticking such data into
 >   probe packets is OK.
Aha, we agreed.
We rewrote that as:
"It is RECOMMENDED to use probe packets that do not carry any user data 
that would require retransmission if lost."

 > Section 8., paragraph 0:
 >>    7.  Probing and congestion control: The DPLPMTUD sender treats
 >>        isolated loss of a probe packet (with or without a corresponding
 >>        PTB message) as a potential indication of a PMTU limit for the
 >>        path.  Loss of a probe packet SHOULD NOT be treated as an
 >>        indication of congestion and the loss SHOULD NOT directly trigger
 >>        a congestion control reaction [RFC4821].
 >   Why "SHOULD NOT" and not "MUST NOT"?
We kept "SHOULD NOT" Because although suboptimal, a use that may 
accidentally view this as a congestion signal is actually safe to treat 
the loss as a congestion indication. We did however
add an explantion at the end of the para
"because this could result in unecessary reduction of the sending rate."

 >>    8.  Shared PLPMTU state: The PLPMTU value could also be stored with
 >>        the corresponding entry in the destination cache and used by
 >>        other PL instances.  The specification of PLPMTUD [RFC4821]
 >>        states: "If PLPMTUD updates the MTU for a particular path, all
 >>        Packetization Layer sessions that share the path representation
 >>        (as described in Section 5.2 of [RFC4821]) SHOULD be notified to
 >>        make use of the new MTU".  Such methods MUST be robust to the
 >>        wide variety of underlying network forwarding behaviors, PLPMTU
 >>        adjustments based on shared PLPMTU values should be incorporated
 >>        in the search algorithms.  Section 5.2 of [RFC8201] provides
 >>        guidance on the caching of PMTU information and also the relation
 >>        to IPv6 flow labels.
 >   Replace "could" with "MAY" in the first sentence, given that the rest
 >   of the paragraph then uses 2119 language?
Indeed, done.
 >
 > Section 3., paragraph 1:
 >>    In addition, the following principles are stated for design of a
 >>    DPLPMTUD method:
 >   Not sure if the 2119 language in the bullets below is appropriate,
 >   given that no mechanisms are actually defined that it could apply to.
We reviewed the text, but kept the recommendations and requirements 
language, because we think any systen implementing this would need to 
abide by these.

 > Section 4.1., paragraph 0:
 >> 4.1.  PLPMTU Probe Packets
 >   Section 4.1 doesn't use any 2119 language. Is this intentional? If
 >   not, I've identified some suggested replacements below; there are
 >   others that I haven't highlighted.
 >
 > Section 4.1., paragraph 1:
 >>    The DPLPMTUD method relies upon the PL sender being able to generate
 >>    probe packets with a specific size.  TCP is able to generate these
 >>    probe packets by choosing to appropriately segment data being sent
 >>    [RFC4821].  In contrast, a datagram PL that needs to construct a
 >>    probe packet has to either request an application to send a data
 >>    block that is larger than that generated by an application, or to
 >>    utilize padding functions to extend a datagram beyond the size of the
 >>    application data block.  Protocols that permit exchange of control
 >>    messages (without an application data block) could alternatively
 >>    prefer to generate a probe packet by extending a control message with
 >>    padding data.
 >   "MAY" instead of "could alternatively"?
We checked, and updated, including this recommendation.

 > Section 4.1., paragraph 2:
 >>    A receiver needs to be able to distinguish an in-band data block from
 >>    any added padding.  This is needed to ensure that any added padding
 >>    is not passed on to an application at the receiver.
 >   "MUST" instead of "needs to"?
 >
We added "A receiver is REQUIRED to be able to distinguish"...

 > Section 4.1., paragraph 3:
 >>    This results in three possible ways that a sender can create a probe
 >>    packet listed in order of preference:
 >   It is not clear that this preference ordering is correct for
 >   partially-reliable transports. You would want to probe with unreliable
 >   application data instead of padding to increase potential goodput.
 >
That's a continuation of your earlier query regarding partial 
reliability, and we updated the text to align with our response.

 > Section 4.1., paragraph 5:
 >>    Probing using application data and padding
 >>    data:  A probe packet that
 >   Nit: Weird line break
Fixed.

 > Section 5.1.2., paragraph 2:
 >>    MAX_PROBES:  The MAX_PROBES is the maximum value of the PROBE_COUNT
 >>                 counter (see Section 5.1.3).  MAX_PROBES represents the
 >>                 limit for the number of consecutive probe attempts of
 >>                 any size.  The default value of MAX_PROBES is 10.
 >   Why 10?
There should be a default. There was a long story about how to approach 
the design, which missed the final text. The SCTP implementation chose 
3, and that number has been used before in IETF protocols to provide 
robustness against isolated loss - the most important reason for 
being>1. New proposed text:
"The default value of MAX_PROBES is 3.  This
value is greater than 1 to provide robustness to
isolated packet loss."

 > Section 5.1.2., paragraph 5:
 >>    MAX_PMTU:    The MAX_PMTU is the largest size of PLPMTU.  This has to
 >>                 be less than or equal to the minimum of the local MTU of
 >>                 the outgoing interface and the destination PMTU for
 >>                 receiving.  An application, or PL, MAY reduce the
 >>                 MAX_PMTU when there is no need to send packets larger
 >>                 than a specific size.
 >   Given path changes, is this really a constant?
It's not derived from the path, but passed from the API. This has been 
made clearer.

 > Section 5.2., paragraph 2:
 >>    Note: Some state changes are not shown to simplify the diagram.
 >   But I hope they are described in the text - where?
The legend was updated. The (simplified) diagram indeed omits some of 
the cases, which are fully described in the text.

 > Section 6., paragraph 1:
 >>    This section specifies protocol-specific details for datagram PLPMTUD
 >>    for IETF-specified transports.
 >   But it doesn't - it often *refers to* other documents where such
 >   details are specified, e.g., for QUIC. Suggest to make it very clear
 >   which subsections are intending to be normative for other protocols,
 >   and which are informative.
 >
Ah - because for some protocol specs were later moved to other docs, so: 
Quite so. The text has been rewritten.

We also added that probing is limited to once/RTT (itself a result of 
this not being subject to congestion control), rather than hinting at 
RFC80865 in the security considerations section.

And also clarified the case where:
"PTB_SIZE < MIN_MTU "
- which someone asked, and although specified elsewhere, it was not 
clearly called out as a case failing validation.

These edits are now included in draft -11, along with some other review 
comments.

Thanks again,

Gorry