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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 14 May 2020 19:19 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 BF10D3A0970; Thu, 14 May 2020 12:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 3SymXx00Xv37; Thu, 14 May 2020 12:19:47 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 53FD23A0B73; Thu, 14 May 2020 12:19:46 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6AE011B0015F; Thu, 14 May 2020 20:19:40 +0100 (BST)
Subject: Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud
To: Michael Tuexen <tuexen@fh-muenster.de>, Martin Duke <martin.h.duke@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>
References: <HE1PR0702MB3772606AA3C6D808992C5DF595BE0@HE1PR0702MB3772.eurprd07.prod.outlook.com> <CAM4esxRZBehUOHpEg6E_p7bvY8CpK4oya7rfv4JVTkmAKfQ7jw@mail.gmail.com> <2643A40F-F0DC-45FF-A780-975D5568BE5B@fh-muenster.de>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <03b92d83-b3f9-2fb3-c21c-5bf3fda767cb@erg.abdn.ac.uk>
Date: Thu, 14 May 2020 20:19:39 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <2643A40F-F0DC-45FF-A780-975D5568BE5B@fh-muenster.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4u_RReUYPVIzMiHplX9AmPwUPJI>
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 19:19:52 -0000

To me, this is a PL choice, and likley a constant for a PL.

The PL simply configures as an endpoint what size it needs. If you need 
to work smaller than that size, then the PL has to utilise IP 
fragmentation, etc. The DPLPMTUD alg won't probe for smaller sizes.

I expect most apps will actually use a MIN value that is irrespective of 
IP version, such as 1200B, but the app could choose a smaller number - 
which is permitted for IPv4, but in reality 1200B is likely good. For 
QUIC, I'd expect ~1200B and no IP Frag - but that's QUIC's decision. 
BASE_PLPMTU and MIN_PLPMTU can be set the same.

Gorry

On 14/05/2020 19:50, Michael Tuexen wrote:
>
>> 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).
>>
>>   
>>