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

Michael Tuexen <tuexen@fh-muenster.de> Thu, 14 May 2020 18:51 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BACC3A0405; Thu, 14 May 2020 11:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 oVPpU_tk6NjD; Thu, 14 May 2020 11:51:01 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C859E3A0B25; Thu, 14 May 2020 11:51:00 -0700 (PDT)
Received: from [IPv6:2a02:8109:1140:c3d:4136:86f2:7b59:6ff0] (unknown [IPv6:2a02:8109:1140:c3d:4136:86f2:7b59:6ff0]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 37F237220CCE5; Thu, 14 May 2020 20:50:53 +0200 (CEST)
From: Michael Tuexen <tuexen@fh-muenster.de>
Message-Id: <2643A40F-F0DC-45FF-A780-975D5568BE5B@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_5A1E9ECA-70AD-47C9-AD17-F28E3C3FE165"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud
Date: Thu, 14 May 2020 20:50:51 +0200
In-Reply-To: <CAM4esxRZBehUOHpEg6E_p7bvY8CpK4oya7rfv4JVTkmAKfQ7jw@mail.gmail.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" <draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org>, "quic@ietf.org" <quic@ietf.org>
To: Martin Duke <martin.h.duke@gmail.com>
References: <HE1PR0702MB3772606AA3C6D808992C5DF595BE0@HE1PR0702MB3772.eurprd07.prod.outlook.com> <CAM4esxRZBehUOHpEg6E_p7bvY8CpK4oya7rfv4JVTkmAKfQ7jw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/D-tiQyILa2nFrVnswvl6QmpthM4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2020 18:51:04 -0000


> On 14. May 2020, at 19:20, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> 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?
I guess it should state that if the PLPMTU falls below MIN_PLPMTU, you stop sending packets.

Best regards
Michael
> 
> On Tue, May 12, 2020 at 1:49 AM Magnus Westerlund <magnus.westerlund@ericsson.com> 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).
> 
>  
>