Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)

Martin Thomson <notifications@github.com> Sun, 09 February 2020 23:01 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 14F6E120071 for <quic-issues@ietfa.amsl.com>; Sun, 9 Feb 2020 15:01:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 KvJFwEbWLjVB for <quic-issues@ietfa.amsl.com>; Sun, 9 Feb 2020 15:01:45 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D4F120052 for <quic-issues@ietf.org>; Sun, 9 Feb 2020 15:01:45 -0800 (PST)
Date: Sun, 09 Feb 2020 15:01:44 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1581289304; bh=74ZzGaXwBT2lqZ4Zn05xqdPONPnRrMgyQJGhdCKLZOQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pqlieW7syPCIzXaf3QRf+peQUFmeDJap+ZF1410F+ey8Hb+sXIAtSnSZMfJlMUvWp m68Xc5vp/L/CUXhccK4cB0GdYMpVF/tbnpb2I2IwuiYftrdZjdbVJ33HJ747LaXEpg s+eS1XDtV6MYNI3RmiA9pRdigyRocZnTHmt1oS3U=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4NIC4SC54NKRH4ZA54JXA5REVBNHHCDAXLQI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3445/review/355641304@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3445@github.com>
References: <quicwg/base-drafts/pull/3445@github.com>
Subject: Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e408f58343e0_644e3f92080cd9686638"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/IeQPCRE062D_x7oetC6gyS5ch2I>
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: Sun, 09 Feb 2020 23:01:47 -0000

martinthomson commented on this pull request.



> @@ -1626,14 +1626,14 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by the amplification restriction.
 
-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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a situation in
+which the server cannot send due to the anti-amplification limit
+and the client has no data to send because client Initial data has been
+acknowledged and it does not yet have Handshake data to send. In order to avoid

This long compound sentence probably needs to be split up.

> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial packets.  The server can reaches its anti-amplification limit (see {{xxx}}), but the client has received and acknowledged Initial packets without having a need to send a Handshake packet.  In this case, where the client would otherwise not send any additional packets, the server will be unable to send because it has not received enough from the client.  To prevent this deadlock, clients MUST send a packet on a probe timeout, or PTO; see Section XX of {{QUIC-RECOVERY}}.  If [...]

-- 
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/pull/3445#pullrequestreview-355641304