Re: [quicwg/base-drafts] Describe PMTU probing that includes source connection ID for routing … (#2402)

Igor Lubashev <notifications@github.com> Mon, 11 February 2019 02:34 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 F319E130EEA for <quic-issues@ietfa.amsl.com>; Sun, 10 Feb 2019 18:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ng1CxhOTUxSw for <quic-issues@ietfa.amsl.com>; Sun, 10 Feb 2019 18:33:59 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB162130ECD for <quic-issues@ietf.org>; Sun, 10 Feb 2019 18:33:58 -0800 (PST)
Date: Sun, 10 Feb 2019 18:33:57 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549852437; bh=2fvlKqzScBkb4TBdoo5ee2TBCG/XoRKr8cbKiA+FQcE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qliKwHWyEk9uDRBgEBE2rhYd8PK8LPdFrQ/H4tcxWRTYPsUn6zoAgyAe+Jaj8d8F2 X6nVMr99hE4BZ9JCv993p8hqdzX6YgQs6jOgaF72F72PMkaD2SLcmcEiy2P+gIsfz2 oMJ7m5lBYNGEvs0qsvy6S6HeN9Nqvz1WmC8Ab6Cs=
From: Igor Lubashev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab10ac85a1a384e16f9dfa387046c98001f5c2681b92cf000000011878a11592a169ce1833165d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2402/review/201939603@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2402@github.com>
References: <quicwg/base-drafts/pull/2402@github.com>
Subject: =?UTF-8?Q?Re:_[quicwg/base-drafts]_Describe_PMTU_probing_that?= =?UTF-8?Q?_includes_source_connection_ID_for_routing_=E2=80=A6_=28#2402=29?=
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c60df15b915c_46d73fc7482d45c0143872d"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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/BvXSQqF9meokhaCDZU6FgI3Xl6A>
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, 11 Feb 2019 02:34:01 -0000

igorlord commented on this pull request.



> @@ -2670,9 +2670,10 @@ complete.  Though the values of some fields in the packet header might be
 redundant, no fields are omitted.  The receiver of coalesced QUIC packets MUST
 individually process each QUIC packet and separately acknowledge them, as if
 they were received as the payload of different UDP datagrams.  For example, if
-decryption fails (because the keys are not available or any other reason), the
-the receiver MAY either discard or buffer the packet for later processing and
-MUST attempt to process the remaining packets.
+decryption fails (because the keys are not available, the UDP datagram is a PMTU
+probe (see {{pmtu-probes-src-cid}}), or any other reason), the the receiver MAY

It looks technically redundant, but it works to point out this use case in the _Coalescing Packets_ section. The other alternative would be to mention PMTU probes earlier (in the in the second paragraph, for example):

```suggestion
Using the Length field, a sender can coalesce multiple QUIC packets into one UDP datagram.
This can reduce the number of UDP datagrams needed to complete the cryptographic
handshake and start sending data.  This can also be used to construct PMTU probes (see
{{pmtu-probes-src-cid}}).  Receivers MUST be able to probe (see {{pmtu-probes-src-cid}}),
or any other reason), the the receiver MAY process coalesced packets.
```

I do wonder if mentioning this too early would distract from the main purpose of coalesced packets -- reducing the number of UDP datagrams during handshake.

-- 
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/2402#discussion_r255371509