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

ianswett <notifications@github.com> Mon, 01 June 2020 23:51 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 178143A16CD for <quic-issues@ietfa.amsl.com>; Mon, 1 Jun 2020 16:51:58 -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 YIQKmBbNUNVW for <quic-issues@ietfa.amsl.com>; Mon, 1 Jun 2020 16:51:56 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C803A16CC for <quic-issues@ietf.org>; Mon, 1 Jun 2020 16:51:56 -0700 (PDT)
Received: from github-lowworker-b2150d3.ash1-iad.github.net (github-lowworker-b2150d3.ash1-iad.github.net [10.56.113.12]) by smtp.github.com (Postfix) with ESMTP id A19198C0841 for <quic-issues@ietf.org>; Mon, 1 Jun 2020 16:51:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1591055515; bh=RDYQlEzu1USmGisshtLCysPxUb+mrFKxr0iIuVXLwlk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M+ydRQTJ6IOAYzWGlc5cObcTCgNRq+piQSTIO9Y0xwDoSPujv8u3mib7exghFhOM+ nQBz4VwWsb1UlZNAihJq3o+59WU8qfU8VtDz+FloHLLi65s63fjfPJjmzSGQx+UsaE cPhWZa5+zQS2/JrLOd2Tr9b/Z6/mXjc2FMDh8+FQ=
Date: Mon, 01 Jun 2020 16:51:55 -0700
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK455UTPV63CSSN4QAF44F2ZXEVBNHHCKRI54E@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/422237549@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_5ed5949b8fc81_258e3ff6250cd96452885"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/SoVn1eILAPjngqN2j4q7cfeLn-c>
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: Mon, 01 Jun 2020 23:51:58 -0000

@ianswett approved this pull request.



>  
 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}}.
+to at least the smallest allowed maximum packet size (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 Path Maximum
+Transmission Unit (PMTU).  This also helps reduce the amplitude of amplification
+attacks caused by server responses toward an unverified client address; see
+{{address-validation}}.
 
 Enforcement of the max_udp_payload_size transport parameter

I'd move this paragraph above the one above, since they both talk about maximum packet size and in particular this paragraph uses "additional limit" which reads better one paragraph up.

>  
 Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 believes that the network path and peer both support the size that it chooses.
 
 UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4
 {{!IPv4=RFC0791}}, the DF bit MUST be set to prevent fragmentation on the path.
 
-A server MUST discard an Initial packet that is carried in a UDP datagram with
-a payload that is less than 1200 bytes. A server MAY also immediately close the
-connection by sending a CONNECTION_CLOSE frame with an error code of
-PROTOCOL_VIOLATION; see {{immediate-close-hs}}.
+A server MUST discard an Initial packet that is carried in a UDP datagram with a
+payload that is less than the smallest allowed maximum packet size  of 1200

```suggestion
payload that is less than the smallest allowed maximum packet size of 1200
```

> -{{?RFC8085}}.
-
-An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
-({{!DPLPMTUD=I-D.ietf-tsvwg-datagram-plpmtud}}) or implement Path MTU Discovery
-(PMTUD) {{!RFC1191}} {{!RFC8201}} to determine whether the path to a destination
-will support a desired message size without fragmentation.
-
-In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
-larger than 1280 bytes. Assuming the minimum IP header size, this results in a
-QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
-implementation MAY be more conservative in computing the QUIC maximum packet
-size to allow for unknown tunnel overheads or IP header options/extensions.
+An endpoint SHOULD use DPLPMTUD ({{dplpmtud}}) or PMTUD ({{pmtud}}) to determine
+whether the path to a destination will support a desired message size without
+fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT
+send IP packets larger than the minimum QUIC packet size.

```suggestion
send IP packets larger than the smallest allowed maximum packet size.
```

> -implementation MAY be more conservative in computing the QUIC maximum packet
-size to allow for unknown tunnel overheads or IP header options/extensions.
+An endpoint SHOULD use DPLPMTUD ({{dplpmtud}}) or PMTUD ({{pmtud}}) to determine
+whether the path to a destination will support a desired message size without
+fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT
+send IP packets larger than the minimum QUIC packet size.
+
+Both DPLPMTUD and PMTUD send IP packets that are larger than the current maximum
+packet size.  We refer to these as PMTU probes.  All QUIC packets that are not
+sent in a PMTU probe SHOULD be sized to fit within the maximum packet size to
+avoid the packet being fragmented or dropped {{?RFC8085}}.
+
+If a QUIC endpoint determines that the PMTU between any pair of local and remote
+IP addresses has fallen below the smallest allowed maximum packet size of 1200
+bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU
+probes, on the affected path.  An endpoint MAY terminate the connection if an

This isn't new text, but tt seems like these two statements may be contradictory?  Should this be "except for those in PMTU probes or containing connection close frames, on the affected path."?

>  
-Section 6.3 of {{!DPLPMTUD}} provides considerations for implementing Datagram
-Packetization Layer PMTUD (DPLPMTUD) with QUIC.
+If a QUIC endpoint determines that the PLPMTU between any pair of local and
+remote IP addresses has fallen below the size needed to support the minimum QUIC
+packet size (BASE_PLPMTU), it MUST immediately cease sending QUIC packets on the
+affected path. An endpoint MAY terminate the connection if an alternative path

This seems a bit repetitive of 3862-3866.  It's also still confusing or potentially contradictory to me.

-- 
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-422237549