Re: [quicwg/base-drafts] Integrate QUIC text from DPLPMTUD (#3693)

Magnus Westerlund <notifications@github.com> Tue, 26 May 2020 09:14 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 B022E3A0D56 for <quic-issues@ietfa.amsl.com>; Tue, 26 May 2020 02:14:44 -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 BpiCLgKQ_94g for <quic-issues@ietfa.amsl.com>; Tue, 26 May 2020 02:14:42 -0700 (PDT)
Received: from out-25.smtp.github.com (out-25.smtp.github.com [192.30.252.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF1B3A0D62 for <quic-issues@ietf.org>; Tue, 26 May 2020 02:14:39 -0700 (PDT)
Received: from github-lowworker-ca235ff.ash1-iad.github.net (github-lowworker-ca235ff.ash1-iad.github.net [10.56.110.15]) by smtp.github.com (Postfix) with ESMTP id 2D89528221F for <quic-issues@ietf.org>; Tue, 26 May 2020 02:14:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590484477; bh=5ZjepQqyvjmR4uG0JwVw8TOOwKxoeEXrKdgS4fDZvAI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SrW+DhKPRgmsUNjh9gPNsI4SB8XY1ybkMNwgN63E3MofEIspqTUUl0R4QIaHIqO4h nRxmNh8fF4MLhDIY7hjd6u7d9BXmGkN/n54jWOxcaOyXUIslA3sEeDCHVbIHbz7rAo IA7GN1UWFxm2vBocAUAiy7G0HF+0IwU2ttKhaFdc=
Date: Tue, 26 May 2020 02:14:37 -0700
From: Magnus Westerlund <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6PUUR3ES6AMTLCKDF43C7P3EVBNHHCKNQYNU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3693/review/418084163@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3693@github.com>
References: <quicwg/base-drafts/pull/3693@github.com>
Subject: Re: [quicwg/base-drafts] Integrate QUIC text from DPLPMTUD (#3693)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eccddfd1d588_5df13fd90aecd95c1760fa"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gloinul
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/tje6AbWnW8Vj1c4s0Q8Ffum60Xg>
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: Tue, 26 May 2020 09:14:45 -0000

@gloinul commented on this pull request.

Some feedback on the text. 

> @@ -3797,17 +3797,23 @@ 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 IPv6 minimum size
+{{?RFC8200}} and is also supported by most modern IPv4 networks.
+Assuming the minimum IP header size, this results in a
+QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. 

Should there be an addition to the "QUIC maximum packet size" like initial or base line to indicate that the QUIC maximum packet size is actually a variable that can be changed by the PMTUD/DPLPMTUD? 

>  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.
+larger than the minimum QUIC packet size. 
+
+All QUIC
+packets other than PMTUD/DPLPMTUD probe packets 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, it MUST immediately 

Isn't the "smallest allowed maximum packt size" equal to the "minimum QUIC packet size"? I guess strictly not, as smallest allowed maximum packet size is on IP level which is 1280. While "minimum QUIC packet size" based on the initial requirement is 1200 bytes and results in a IP level value that is slightly less than 1280. I think this needs some alignment. Maybe basing it on the 1200 bytes minimum QUIC packet size and say that smallest supported Maximum Packet Size is then 1200 plus overhead for IP/UDP. 

> +state when the QUIC connection handshake has been completed and
+the endpoint has established a 1-RTT key.

So, this was an attempt from me to correct something that looked even more broken in the earlier text in the TSVWG document. If handshake is complete is a good term lets use it. 

So I think it is relevant to at least go through the implication of sending DPLPMTUD probes prior to handshake complete. So one possible implementation here could be to first send your initial packet with 1280 as MPS. Then you use the rest of your IW=10 to send a broad side of Path MTU probes of various sizes checking a number of common sizes up to the client's local interface's MPS. So in relation to recovery that defines the initial window to 10*max_datagram_size with a limit of max (14720, 2*max_datagram_size). I make an assumption that one will in this case start with max_datagram_size=1200. Thus one can fit some number of probes. So allow DPLPMTUD to use 0-RTT keys to send probes I think is likely to result that the client to server handshake flight will often contain 10-12k of data even if there are no 0-RTT application data. That might be a good investment, but I are we certain of the DoS properties of this? 

So my though was simply to be a bit conservative here and ensure that both endpoints know there are someone there that will report delivery of the probes before sending them. But, this is clearly something the QUIC WG can discuss and change. 

-- 
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/3693#pullrequestreview-418084163