Return-Path: 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 ; 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 ; 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 ; 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 Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2020 18:23:57 -0000 ----==_mimepart_5e2c87b945ae2_4c463fc9abacd960128572 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ----==_mimepart_5e2c87b945ae2_4c463fc9abacd960128572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

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, view it on GitHub, or unsubscribe.

----==_mimepart_5e2c87b945ae2_4c463fc9abacd960128572--