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

Kazuho Oku <notifications@github.com> Fri, 18 October 2019 23:26 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 90FC8120046 for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 16:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
X-Spam-Status: No, score=-7.998 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, URIBL_BLOCKED=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 yRanM5Fepf19 for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 16:26:19 -0700 (PDT)
Received: from out-15.smtp.github.com (out-15.smtp.github.com [192.30.254.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759D512002E for <quic-issues@ietf.org>; Fri, 18 Oct 2019 16:26:19 -0700 (PDT)
Received: from github-lowworker-c53a806.ac4-iad.github.net (github-lowworker-c53a806.ac4-iad.github.net [10.52.23.45]) by smtp.github.com (Postfix) with ESMTP id 09D8C261646 for <quic-issues@ietf.org>; Fri, 18 Oct 2019 16:26:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571441179; bh=XM/ciQeIXt9HKrVMleGv1vUx0CmBXorSqyZdR9VKBtU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oeCXhzb3psxgo9cVMAUtlbyyBWdl65Y/ciicaxKEldly7TAOPK6oDdJ0U1R8lRWVG hHW/f8L5bRaMf9jNBj8OcqUajUw95yH8T0fjOi+/542fN/Rz4YURR0GsjJfs2crclB DHm9NdDD7DCVw/hwxYn//xGaWevaCPtpDz44FR70=
Date: Fri, 18 Oct 2019 16:26:18 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZE2L3YFIBVL7JYGOF3W56JVEVBNHHBXDZPBM@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/544003607@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_5daa4a1ab98f8_2f943f8e4a6cd96011463"; 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/m6bWKb8dVjkjXCq-_ZhNMVtuwyk>
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 23:26:22 -0000

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

The problem here is that even in the case where an endpoint (e.g., server) has received all the handshake transcript and also the ACKs for all the ack-eliciting Handshake packets it has sent, the other side (e.g., client) might have still some data outstanding (due to ACKs being lost).

@ianswett
> I'd suggest we add a paragraph to section 5.5(https://tools.ietf.org/html/draft-ietf-quic-recovery-23#section-5.5) like:
> "When the handshake has been confirmed, all data sent in Handshake packet is known to be delivered and all recovery state should be discarded."

It's not only the the receive-side state of the Handshake packets that you need to retain forever, but also the state related to that path (e.g., socket). I am not sure we'd prefer that.

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