Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud

[Martin Duke <[e-mail]>]

I don’t understand the MIN_PLPMTU language in 6.3.2. This is a constant set
based on the IP version. I don’t understand how it can change on a path?

On Tue, May 12, 2020 at 1:49 AM Magnus Westerlund <
[e-mail]> wrote:

> QUIC WG,
>
>
>
> In response to the IESG evaluation of
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ some
> changes was made to the QUIC chapter.
>
>
>
> The current text is included below. And a Diff for the changes in this
> section -19 to -21 is here:
>
>
>
> QUIC related section is 6.3:
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-datagram-plpmtud-19&url2=draft-ietf-tsvwg-datagram-plpmtud-21
>
>
>
> My plan is to approve this document on Friday after 12:00 (CEST) if not
> anyone yells.
>
>
>
>
>
> 6.3.  DPLPMTUD for QUIC
>
>
>
>    QUIC [I-D.ietf-quic-transport] is a UDP-based transport that provides
>
>    reception feedback.  The UDP payload includes the QUIC packet header,
>
>    protected payload, and any authentication fields.  QUIC depends on a
>
>    PMTU of at least 1280 bytes.
>
>
>
>    Section 14 of [I-D.ietf-quic-transport] describes the path
>
>    considerations when sending QUIC packets.  It recommends the use of
>
>    PADDING frames to build the probe packet.  Pure probe-only packets
>
>    are constructed with PADDING frames and PING frames to create a
>
>    padding only packet that will elicit an acknowledgment.  Such padding
>
>    only packets enable probing without affecting the transfer of other
>
>    QUIC frames.
>
>
>
>    The recommendation for QUIC endpoints implementing DPLPMTUD is that a
>
>    MPS is maintained for each combination of local and remote IP
>
>    addresses [I-D.ietf-quic-transport].  If a QUIC endpoint determines
>
>    that the PMTU between any pair of local and remote IP addresses has
>
>    fallen below the size required for an acceptable MPS, it immediately
>
>    ceases to send QUIC packets on the affected path.  This could result
>
>    in termination of the connection if an alternative path cannot be
>
>    found [I-D.ietf-quic-transport].
>
>
>
> 6.3.1.  Initial Connectivity
>
>
>
>    The base protocol is specified in [I-D.ietf-quic-transport].  This
>
>    provides an acknowledged PL.  A sender can therefore enter the BASE
>
>    state as soon as connectivity has been confirmed.
>
>
>
>    QUIC provides an acknowledged PL, a sender can therefore enter the
>
>    BASE state as soon as the connection handshake has been completed and
>
>    the endpoint has an 1-RTT key established.
>
>
>
> 6.3.2.  Sending QUIC Probe Packets
>
>
>
>    Probe packets consist of a QUIC Header and a payload containing a
>
>    PING Frame and multiple PADDING Frames.  A PADDING Frame is
>
>    represented by a single octet (0x00).  Several PADDING Frames are
>
>    used together to control the length of the probe packet.  The PING
>
>    Frame is used to trigger generation of an acknowledgement.
>
>
>
>    The current specification of QUIC sets the following:
>
>
>
>    *  BASE_PLPMTU: A QUIC sender pads initial packets to confirm the
>
>       path can support packets of the required size, which sets the
>
>       BASE_PLPMTU and MIN_PLPMTU.
>
>
>
>    *  MIN_PLPMTU: A QUIC sender that determines the MIN_PLPMTU has
>
>       fallen MUST immediately stop sending on the affected path.
>
>
>
> 6.3.3.  Validating the Path with QUIC
>
>
>
>    QUIC provides an acknowledged PL, therefore a sender does not
>
>    implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
>
>
>
> 6.3.4.  Handling of PTB Messages by QUIC
>
>
>
>    QUIC validates ICMP PTB messages.  In addition to UDP Port
>
>   validation, QUIC can validate an ICMP message by using other PL
>
>    information (e.g., validation of connection identifiers (CIDs) in the
>
>    quoted packet of any received ICMP message).
>
>
>