IETF Logo Mail Archive

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

ekr <notifications@github.com> Fri, 18 October 2019 22: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 490EE12008B for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 15:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 Vbt7mspXjvvt for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 15:34:32 -0700 (PDT)
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 EB782120046 for <quic-issues@ietf.org>; Fri, 18 Oct 2019 15:34:31 -0700 (PDT)
Date: Fri, 18 Oct 2019 15:34:31 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571438071; bh=D+8o8i6KnfZrN1/I1i3CgqOo8CG+eeZs0idGPZ9fzKg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ITqlDh8xs5cam9j9Fr0pJlTVRrGF6YJhIoql7pp1NfRRVMxHv8Z9ynndjnK8qkrpK jG4hV8TBSOzhSLSv7CYlQA2RTZ58w5JERWDxPB+gDteTeMO0OeS6uJtREAJYApZD1M 1lZo4FGIgEAoju93rFO0xYtb9aNMxjKb8u8c7PP4=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZBUUZ6RDDNTDWKHUF3W57IPEVBNHHBXDZPBM@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/543984852@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_5daa3df712016_72853fc75e6cd96822077"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/3_-gD1nFpz987nSiVCetMoVKiDY>
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 22:34:33 -0000

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

Why not simply prohibit migration until all handshake packets have been ACKed. There is no ambiguity here, as the server is forbidden from initiating migration.


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

v2.23.0 | Report a Bug | By Email