[quicwg/base-drafts] Path Migration makes unjustified assumptions about a new path. (#2909)

Gorry Fairhurst <notifications@github.com> Thu, 18 July 2019 13:25 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 06C9C120278 for <quic-issues@ietfa.amsl.com>; Thu, 18 Jul 2019 06:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 zV42EeZmGeob for <quic-issues@ietfa.amsl.com>; Thu, 18 Jul 2019 06:25:14 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB2B120276 for <quic-issues@ietf.org>; Thu, 18 Jul 2019 06:25:14 -0700 (PDT)
Date: Thu, 18 Jul 2019 06:25:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563456313; bh=cwDTb8mg6+ffT9IR/Hl6OxBex32cQt23HbKdx6SKVEA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=v4OHkwz/u9/vSjqwZQljX5ILAQdvP7A4Tdql/zdd4aHm+5lAzMuGGbwO+uYo6PKPy Hn9erS0MLVxTMU8gmXy+6jAz8vB2E3CImKqwYJ3WDdafbqCzgVj5igfknSGxee/FEa 758lcFXQgPcooIBCiraVE1P92WP+/K/BGjXILEN4=
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6TDBZO672WPQS3N2V3HWS3TEVBNHHBYAAYHM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2909@github.com>
Subject: [quicwg/base-drafts] Path Migration makes unjustified assumptions about a new path. (#2909)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d3073395d253_55603fa8f92cd96842261a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
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/Nzr2sWlR9eGIZQpjz4PzLSgJWMc>
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, 18 Jul 2019 13:25:16 -0000

This is awkward, because the issue of assumptions about the path appears spread over multiple places.

Section 9.4 of draft-ietf-quic-transport  :
   The capacity available on the new path might not be the same as the
   old path.  Packets sent on the old path SHOULD NOT contribute to
   congestion control or RTT estimation for the new path.
GF: That would be fine **IF** the new path were a separate CC context, which I am not yet clear whether it is, read on:
—
Section 9.4 of draft-ietf-quic-transport  :
   On confirming a peer's ownership of its new address, an endpoint
   SHOULD immediately reset the congestion controller and round-trip
   time estimator for the new path.
GF: Why not MUST? - because I think this is a new path, I think it can only be should if something can confirm this is the same set of network-devices and classifiers on the path. I don't know how you would know that, and I don't like the guess.
—
draft-ietf-quic-transport :
   For instance, a change in the client's port
   number is likely indicative of a rebinding in a middlebox and not a
   complete change in path. 
GF: So. maybe this is the guess, and I don't believe it! In a world of ECMP and other methods, this needs to be treated as a potential change of path.
—
Section 9.4 of draft-ietf-quic-transport:
   While multiple paths might be used during connection migration, a
   single congestion control context and a single loss recovery context
   (as described in [QUIC-RECOVERY]) may be adequate.  
GF: Well it could if the paths **WERE** known to be identical, but how would an endpoint guarantee that? Section 9.2 of QUIC transport seems to suggest the CC is reset for the new path, which I would agree with, but which part of QUIC recovery says that?
—
draft-ietf-quic-recovery:
   For instance, an
   endpoint might delay switching to a new congestion control context
   until it is confirmed that an old path is no longer needed (such as
   the case in Section 9.3.3).
GF:  This seems underspecified and novel to me. I think it may b quite OK to continue using the old path and the old CC, for a while. Same question: is this implying the two paths share a single CC and is there some real mechanism to detect that they are really the same set of network devices on path?


-- 
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/issues/2909