Re: [quicwg/base-drafts] Discarding Initial context too soon leads to deadlock (#3395)

ianswett <notifications@github.com> Sat, 25 January 2020 18:23 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 707D0120074 for <quic-issues@ietfa.amsl.com>; Sat, 25 Jan 2020 10:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.3
X-Spam-Level:
X-Spam-Status: No, score=-5.3 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_MED=-2.3, 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 56gbtPFSTe3o for <quic-issues@ietfa.amsl.com>; Sat, 25 Jan 2020 10:23:54 -0800 (PST)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E3A120048 for <quic-issues@ietf.org>; Sat, 25 Jan 2020 10:23:54 -0800 (PST)
Date: Sat, 25 Jan 2020 10:23:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579976633; bh=KR901IcQaqrT1RTjQ5VNL+4WscFpHt0tbwmJ/I9DGaI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AoI0RjlefGTB3rN5ADqmnRcqv7PEqXl3aFb9qfsbi3TBEYQdQvpl3UoS1N6DHG9W1 4bw54zOnvAhN8tBA2OBtdtdBIaI+bXp5Ce4i0Gfdwg+isMfo59yjuPv8amoPSJJhy0 zHznueoLFXsvz5QeaG038OAey/kNT+h0NYNwVWTQ=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7ZVQEI2Z6RGWGEWLV4HG5DTEVBNHHCCE326I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3395/578429987@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3395@github.com>
References: <quicwg/base-drafts/issues/3395@github.com>
Subject: Re: [quicwg/base-drafts] Discarding Initial context too soon leads to deadlock (#3395)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e2c87b945ae2_4c463fc9abacd960128572"; 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/ilcBuCSs7GpwW_qZWZBHALorQYo>
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: Sat, 25 Jan 2020 18:23:57 -0000

Section 8.1 of transport contains text that agrees with recovery:
"Packet loss, in particular loss of a Handshake packet from the
   server, can cause a situation in which the server cannot send when
   the client has no data to send and the anti-amplification limit is
   reached.  In order to avoid this causing a handshake deadlock,
   clients SHOULD send a packet upon a probe timeout, as described in
   [QUIC-RECOVERY].  If the client has no data to retransmit and does
   not have Handshake keys, it SHOULD send an Initial packet in a UDP
   datagram of at least 1200 bytes.  If the client has Handshake keys,
   it SHOULD send a Handshake packet."

Possibly the SHOULDs in transport should be MUSTs?

The original issue was #1764.

At the NY interim, the conclusion to #1764 was that the only way to prevent a deadlock in the presence of a server that would stop sending due to an anti-amplification factor was to force the client to continue sending.  The existing recovery text proscribes that and this is one of the relatively few portions of the recovery text that uses a MUST instead of a SHOULD because otherwise you do get a deadlock.

I don't believe the ack-eliciting suggestion is always going to work unless it's also reliable, so I'd rather stick with the existing solution.  I think the cause of this problem is the amplification limits, and doesn't have to do with abandoning Initial packets, so a reference to recovery would be most appropriate in section 

-- 
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/3395#issuecomment-578429987