Re: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)

Gorry Fairhurst <notifications@github.com> Wed, 27 May 2020 09:24 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4F3A0BF5 for <quic-issues@ietfa.amsl.com>; Wed, 27 May 2020 02:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level:
X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 284GHgJXTJUN for <quic-issues@ietfa.amsl.com>; Wed, 27 May 2020 02:24:17 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1637B3A0BF0 for <quic-issues@ietf.org>; Wed, 27 May 2020 02:24:17 -0700 (PDT)
Received: from github-lowworker-52827f8.ash1-iad.github.net (github-lowworker-52827f8.ash1-iad.github.net [10.56.108.24]) by smtp.github.com (Postfix) with ESMTP id 9DDE31C0D3E for <quic-issues@ietf.org>; Wed, 27 May 2020 02:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590571455; bh=BgPjZNaHWSjDHeSwdyXCOqgXgryC+JkenZ15YkvkStE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bBoCsf6/K0w1cPxxNRdVuTUZ8Hev10cuVbdTJ6H7Iirb9yCQjHmCongjidfGqSTUc Fj+eH1k6GP27m7T4PuAgwm645oKi6+OPcOnOLFnzP2cerB/5s7BfwywWdHD2jYbfY1 PdsrEZNUiNy5XdhImSLm59MgHmiZ1kaqSRpLHlGM=
Date: Wed, 27 May 2020 02:24:15 -0700
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4XFQAVYUWBEYDXQM543IJL7EVBNHHCKRI54E@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3702/review/418950412@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3702@github.com>
References: <quicwg/base-drafts/pull/3702@github.com>
Subject: Re: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ece31bf8d177_75683fa5f5ccd9603476c7"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/w3IK0yrsgXDdlmLBJGknv5dk8Aw>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2020 09:24:19 -0000

@gorryfair commented on this pull request.

This reflow of the text seems clear to me, and seems nearly ready. I have carefully checked the text and I think this covers all issues and responds to all discussion, thanks. There are a small number of NiTs and one or two small questions remain.

>  
-The considerations for processing ICMP messages in the previous section also
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.

I think we agreed to remove the 1-RTT clause (as not needed)?

> -
-One way to construct a probe for the path MTU is to coalesce (see
-{{packet-coalesce}}) a Handshake packet ({{packet-handshake}}) with a short
-header packet in a single UDP datagram.  If the UDP datagram reaches the
-endpoint, the Handshake packet will be ignored, but the short header packet will
-be acknowledged.  If the UDP datagram causes an ICMP message to be sent, the
-first part of the datagram will be quoted in that message.  If the source
-connection ID is within the quoted portion of the UDP datagram, that could be
-used for routing.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a

Re-reading this: Is this only for PMTUD? 

The text seems to describe a probe packet that is ack-eliciting, which may mean it can be used with PLPMTUD?
Should we say PMTUD/DPLPMTUD

>  
-The considerations for processing ICMP messages in the previous section also
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed and the endpoint has
+established a 1-RTT key.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
+PADDING frame therefore implement "Probing using padding data", as defined in
+Section 4.1 of {{!DPLPMTUD}}.  Endpoints could limit the content of probe
+packets to PING and PADDING frames as packets that are larger than the current

Please check: This may leave data in probe packets slightly under-described, and I think more may need to be said:

The transmission of data in probe packets in discussed in
section 4.1 of {{!DPLPMTUD}}. Probe packets that use a PADDING frame or that coalesce packets with no data implement DPLPMTUD with "Probing using padding data".

> @@ -3797,19 +3797,24 @@ later time in the connection.
 The QUIC packet size includes the QUIC header and protected payload, but not the
 UDP or IP header.
 
+QUIC depends upon a minimum packet size of at least 1280 bytes.  This is the

The protocol layer relating to "packet size" needs clarification - is it an IP packet or an IP payload, or QUIC packet?

>  A client MUST expand the payload of all UDP datagrams carrying Initial packets
 to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
 coalescing the Initial packet; see {{packet-coalesce}}.  Sending a UDP datagram
 of this size ensures that the network path from the client to the server
-supports a reasonable Maximum Transmission Unit (MTU).  Padding datagrams also
-helps reduce the amplitude of amplification attacks caused by server responses
-toward an unverified client address; see {{address-validation}}.
+supports a reasonable Path Maximum Transmission Unit (PMTU).  Padding datagrams

/reasonable/minimum size required by QUIC/

>  A client MUST expand the payload of all UDP datagrams carrying Initial packets
 to at least 1200 bytes, by adding PADDING frames to the Initial packet or by
 coalescing the Initial packet; see {{packet-coalesce}}.  Sending a UDP datagram
 of this size ensures that the network path from the client to the server
-supports a reasonable Maximum Transmission Unit (MTU).  Padding datagrams also
-helps reduce the amplitude of amplification attacks caused by server responses
-toward an unverified client address; see {{address-validation}}.
+supports a reasonable Path Maximum Transmission Unit (PMTU).  Padding datagrams

... If coalescing also has this property, should we say:
/Passing datagrams/Using the minimum packet size/


> -used for routing.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a
+packet with a long header, such as a Handshake or 0-RTT packet
+({{long-header}}), with a short header packet in a single UDP datagram.  If the
+UDP datagram reaches the endpoint, the packet with the long header will be
+ignored, but the short header packet will be acknowledged.  If the UDP datagram
+causes an ICMP message to be sent, the first part of the datagram will be quoted
+in that message.  If the source connection ID is within the quoted portion of
+the UDP datagram, that could be used for routing.
+

used for routing ... add: /and for validation of an ICMP message./

> +({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a
+packet with a long header, such as a Handshake or 0-RTT packet
+({{long-header}}), with a short header packet in a single UDP datagram.  If the
+UDP datagram reaches the endpoint, the packet with the long header will be
+ignored, but the short header packet will be acknowledged.  If the UDP datagram
+causes an ICMP message to be sent, the first part of the datagram will be quoted
+in that message.  If the source connection ID is within the quoted portion of
+the UDP datagram, that could be used for routing.
+
+Note:
+: The purpose of using a packet with a long header is only to ensure that the
+  quoted packet contained in the ICMP message contains a Source Connection ID

/SCID/ may already be defined if you prefer.

> +packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a
+packet with a long header, such as a Handshake or 0-RTT packet
+({{long-header}}), with a short header packet in a single UDP datagram.  If the
+UDP datagram reaches the endpoint, the packet with the long header will be
+ignored, but the short header packet will be acknowledged.  If the UDP datagram
+causes an ICMP message to be sent, the first part of the datagram will be quoted
+in that message.  If the source connection ID is within the quoted portion of
+the UDP datagram, that could be used for routing.
+
+Note:
+: The purpose of using a packet with a long header is only to ensure that the
+  quoted packet contained in the ICMP message contains a Source Connection ID
+  field that can be use for routing.  This packet does not need to be a valid

...only for routing? Does this help with validation (the editor will know best).

> -first part of the datagram will be quoted in that message.  If the source
-connection ID is within the quoted portion of the UDP datagram, that could be
-used for routing.
+packets are likely to require that the connection ID be included in
+PMTUD/DPLPMTUD probe packets to route any resulting ICMP messages
+({{icmp-pmtud}}) back to the correct endpoint.  However, only long header
+packets ({{long-header}}) contain source connection IDs, and long header packets
+are not decrypted or acknowledged by the peer once the handshake is complete.
+
+One way to construct a PMTU probe is to coalesce (see {{packet-coalesce}}) a
+packet with a long header, such as a Handshake or 0-RTT packet
+({{long-header}}), with a short header packet in a single UDP datagram.  If the
+UDP datagram reaches the endpoint, the packet with the long header will be
+ignored, but the short header packet will be acknowledged.  If the UDP datagram
+causes an ICMP message to be sent, the first part of the datagram will be quoted
+in that message.  If the source connection ID is within the quoted portion of

I think these may already be defined, you could use them if toy prefer: /CID/ or /SCID/.

> +DPLPMTU probe packets consume congestion window, which could delay subsequent
+transmission by an application.
+
+
+### Validating the QUIC Path with DPLPMTUD
+
+QUIC provides an acknowledged PL, therefore a sender does not implement the
+DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
+
+
+### Handling of ICMP Messages by DPLPMTUD
+
+An endpoint using DPLPMTUD requires the validation of any received PTB message
+before using the PTB information, as defined in Section 4.6 of {{!DPLPMTUD}}.
+In addition to UDP Port validation, QUIC validates an ICMP message by using
+other PL information (e.g., validation of connection identifiers (CIDs) in the

I think /CID/ is already defined at this point in the ID.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702#pullrequestreview-418950412