Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)

Kazuho Oku <notifications@github.com> Fri, 18 October 2019 06:31 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 C749D120116 for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 23:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, 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 PKKGrLkwQZmF for <quic-issues@ietfa.amsl.com>; Thu, 17 Oct 2019 23:31:26 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B6A1200D8 for <quic-issues@ietf.org>; Thu, 17 Oct 2019 23:31:26 -0700 (PDT)
Received: from github-lowworker-ca5950c.va3-iad.github.net (github-lowworker-ca5950c.va3-iad.github.net [10.48.17.57]) by smtp.github.com (Postfix) with ESMTP id 03AD36A04F5 for <quic-issues@ietf.org>; Thu, 17 Oct 2019 23:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571380285; bh=5QoOUJd0KfHEpwUx5UylKwsrsL1Q4CkLepY3lPkUewg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AfdcUu6Fw/ezDcgHHNX3T9l4KQ0OWv1amTSFF00OaAjZsn/PQDap0/hCX4jACPZ3H Qw15oG858cffMjYyakZ12kMHDvtwdmBbNiM+WEKlD1dWdukrlMNb7fEHdHkzmhsq1B b53L+teniBDtDU5mG9ScJNkzdiCDSnUY0I8GjNjg=
Date: Thu, 17 Oct 2019 23:31:24 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3MNHPBM5XRKDTYQB53W2OMZEVBNHHBXDZPBM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2863/543540677@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2863@github.com>
References: <quicwg/base-drafts/issues/2863@github.com>
Subject: Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da95c3ce8738_4c13fd0910cd964263739"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/Sl33o70yftHVLeckIoo9HxlfOlg>
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: Fri, 18 Oct 2019 06:31:29 -0000

IIUC, we agreed today in Cupertino that forbidding handshake key discarding (#3121) is the solution (at least for the time being), based on the assumption that it works.

I am starting to wonder if it works as expected.

Consider the case where the client migrates to a new path once the handshake is confirmed. That is in fact the recommended behavior when server-preferred address is used.

But IIUC, the existing transport logic is designed based on the assumption that path migration happens only after the exchange of Handshake packets have ceased.

I think I have found at least one issue: when the client intentionally migrates to a new path while still having unacknowledged handshake data, how does it choose the new client CID when sending the Handshake packet? Current design assumes that the *server* to pick the client CID from the pool of the CIDs it has received with the NEW_CONNECTION_ID frames. That works for 1-RTT packets, because 1-RTT packet does not have the Source CID field. But when using the long header packets, the sender choose the Source CID (the source being the client in this particular case). What is the solution here?

-- 
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/2863#issuecomment-543540677