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

ianswett <notifications@github.com> Fri, 18 October 2019 23:03 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 AAB3612008B for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 16:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Level:
X-Spam-Status: No, score=-6.595 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_28=1.404, 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 Oxh-BoLVwmHU for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 16:03:42 -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 9C7F312002E for <quic-issues@ietf.org>; Fri, 18 Oct 2019 16:03:42 -0700 (PDT)
Date: Fri, 18 Oct 2019 16:03:41 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571439821; bh=Umzz+yCmsGAx1bt7o8qgNUk83+8Z0flrDDnd771nvVw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ebvyO4CDteK7x/IhbsfaSpeJFrmEs3b/J/tyqKyqG++eRaEKIgXnRdo3FB731Ch5P /pCg0Dw6nC5vnBWKiknG+BAkAbIorNR5VScYFZ854w2snTloMaIXVwT+wpeiU7XTQi qFoXhHbKtsfqCMSwKUkDdh150Qox01Gh5UUGPpss=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4PJPOR3BKTRWWJ6P53W6CV3EVBNHHBXDZPBM@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/543995942@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_5daa44cd989ce_6aec3f865e4cd960310666"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/k_ZrtTx6FL9eHXaSrTWKKYE7KLk>
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:03:45 -0000

When the handshake is confirmed, all the Handshake data is known to be delivered and Handshake recovery state can be discarded.  Previously, this was the moment Handshake keys were discarded, so the recovery doc relied on text about key discard to discard recovery state.

But now that the Handshake keys are staying around longer than the Handshake confirmed point, 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."

To be clear, this suggestion is not a hack.  We should do this if we're going to keep Handshake keys past Handshake Confirmed(which every solution I believe requires?), regardless of how long or why.  I'll note that the server can do this upon receipt of any 1-RTT packet, but waiting for an ACK isn't likely to delay dropping Handshake state significantly and is consistent between client and server.

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