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

Mike Bishop <notifications@github.com> Thu, 07 February 2019 18:44 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 5575B129A87 for <quic-issues@ietfa.amsl.com>; Thu, 7 Feb 2019 10:44:04 -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 4gQtly25p7sT for <quic-issues@ietfa.amsl.com>; Thu, 7 Feb 2019 10:44:02 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFD0124C04 for <quic-issues@ietf.org>; Thu, 7 Feb 2019 10:44:02 -0800 (PST)
Date: Thu, 07 Feb 2019 10:44:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549565041; bh=FV0GhS/YT2CsLjwQWoac9Rb6LnRUoBHBdWNxyZ40pII=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Y4KEKjlGwvc7wXZpL2MN8Nes5KVNTw78JGiVrzQjSNFlsqw/8g9701uhgwHt/3kWQ XQAcQZO1FtnQYDxbEI+KK1h+5cuA6btTMVw7gM5PQh7mlnWjXJ6t6ZKDcSTUPSROBE S2F2whDndFglRJlyKgXZErBZgS9wBUGh59+/Pi/o=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab083a653302b2919be69f41993671e6bc45cac45992cf0000000118743e7192a169ce1833165d@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/201256996@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_5c5c7c716e8b9_383f3fc0f4ad45b857268"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/t-HznavQvklY1MuI4L_Jyg9H5Ss>
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: Thu, 07 Feb 2019 18:44:04 -0000

MikeBishop approved this pull request.

Looks good.  To @mikkelfj's concern, that's covered by the requirement that you MUST process subsequent packets in the datagram, even if you choose to drop the first one.  An implementation that drops the entire datagram because it starts with a Handshake packet would be violating that requirement (and therefore should expect interop problems).

> @@ -3274,6 +3275,22 @@ The considerations for processing ICMP messages in the previous section also
 apply if these messages are used by DPLPMTUD.
 
 
+### PMTU Probes Containing Source Connection ID {#pmtu-probes-src-cid}
+
+Endpoints that rely on the destination connection ID for routing QUIC packets
+are likely to require that connection ID included in PMTU probe packets in order
+to route resulting ICMP messages ({{icmp-pmtud}}) back to the correct endpoints.
+
+Only long header packets ({{long-header}}) contain source connection IDs, but
+long header packets will not be acknowledged once the connection has been
+established.  One way to construct a PMTU probe 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 short header packet will be acknowledged.  If the UDP datagram
+elicits an ICMP message, that message may contain the source connection ID

The reality seems a little stronger than "may"; perhaps "will likely"?

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

I'm not sure this needs to be called out separately.  If Handshake keys have been dropped, the keys won't be available and you've already covered this.

-- 
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#pullrequestreview-201256996