Re: [quicwg/base-drafts] Bundle new client connection ID and path challenge in migration probes (#1730)

MikkelFJ <notifications@github.com> Mon, 10 September 2018 05:20 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 9FF93130E3E for <quic-issues@ietfa.amsl.com>; Sun, 9 Sep 2018 22:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 dLrVRQql2P1V for <quic-issues@ietfa.amsl.com>; Sun, 9 Sep 2018 22:20:01 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B50130E3C for <quic-issues@ietf.org>; Sun, 9 Sep 2018 22:20:01 -0700 (PDT)
Date: Sun, 09 Sep 2018 22:20:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536556800; bh=9AfBLwgU5sJeBfTmIwAXDIA3iDKlhrkL6jA4m4h5Cgc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XqL08p1CrdZsul8loLH3yVCmNflNJzudNGzBC7WhhK6P4d0npU4Qxk5I0cfW1U4bs hnLK5SCWSPqApd01ZI/h60v3IvXaDuSW0d+DYWZ+yhMfDgsjAZlk79HTs0IDQImkMi 0rAe3R2lVWw0WtVSrKm1Y0aNDD9MJf91Pud6Ik60=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab548f59f4e65f1198759e92540eebeade053e23a692cf0000000117adc10092a169ce155cc367@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1730/review/153627226@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1730@github.com>
References: <quicwg/base-drafts/pull/1730@github.com>
Subject: Re: [quicwg/base-drafts] Bundle new client connection ID and path challenge in migration probes (#1730)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b95ff00a819e_26dc3ff7304d45c41539d8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/n2P79MDyF32AZYs6d2mFfGN9Tos>
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, 10 Sep 2018 05:20:04 -0000

mikkelfj commented on this pull request.



> @@ -2074,6 +2074,9 @@ path validation with other frames.  For instance, an endpoint may pad a packet
 carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a
 PATH_RESPONSE with its own PATH_CHALLENGE.
 
+When probing a new path, an endpoint may want to ensure that the response, if
+any, is sent to a specific connection ID. The endpoint achieves that by bundling
+NEW_CONNECTION_ID and PATH_CHALLENGE frames, in that order.

OTOH, if this PR is have any effect, it means that an endpoint must be prepared to process later frames in order to proceed. This is still an inter-frame dependency although ordering is relaxed. I think it needs to be made clear that this can happen (perhaps generally, not specifically here), otherwise an implementation may send frames in one order and a receiver fail to make use of that order.

-- 
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/1730#discussion_r216200004