Re: [quicwg/base-drafts] Fix Recovery Pseudocode (#2907)

Jana Iyengar <notifications@github.com> Fri, 23 August 2019 19:06 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 B97411200EC for <quic-issues@ietfa.amsl.com>; Fri, 23 Aug 2019 12:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Level:
X-Spam-Status: No, score=-8.001 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, RCVD_IN_MSPIKE_H2=-0.001, 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 XaJfhYWkRuAy for <quic-issues@ietfa.amsl.com>; Fri, 23 Aug 2019 12:06:06 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE49B120044 for <quic-issues@ietf.org>; Fri, 23 Aug 2019 12:06:06 -0700 (PDT)
Date: Fri, 23 Aug 2019 12:06:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1566587165; bh=FdrbpIrLQh5cFiY4hQhuwacIIMlG1LE/r1mQu3mIAYA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zjo9m07Pon92k6ZQ7B5FqZyHwtu7T1/1EwhEaVLjEsqxKGlHuf05Lzt+EqIziCBXR O5itOAFNSqAHxNyN+GTrE0QgQ0zutIOP6N9FvdDzcrvb5NdX2Q/peAG361IqCOj0Ss ZEtPFPJYsZgow7BXUNpdSlOPpIDenrBfOBvsg4Gg=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZFQQYP5WXP3EO4MKV3NVVZ3EVBNHHBX66EHQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2907/review/279174450@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2907@github.com>
References: <quicwg/base-drafts/pull/2907@github.com>
Subject: Re: [quicwg/base-drafts] Fix Recovery Pseudocode (#2907)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d60391d9d188_1e53fc069ecd95c1014cf"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/z6iWZ9DTEI6s0gu-ZJuSBIxKFmo>
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, 23 Aug 2019 19:06:09 -0000

janaiyengar commented on this pull request.



> @@ -581,17 +581,17 @@ data.  If no data can be sent, then the PTO alarm MUST NOT be armed until
 data has been received from the client.
 
 Because the server could be blocked until more packets are received, the client
-MUST ensure that the retransmission timer is set if the client does not yet
-have 1-RTT keys.  If the probe timer expires before the client has 1-RTT keys,
-it is possible that the client may not have any crypto data to retransmit.
-However, the client MUST send a new packet to allow the server to continue
-sending data.  At this stage in the connection, when few to none RTT samples
-have been generated, it is possible that the probe timer expiration is due to
-an incorrect RTT estimate at the client. To allow the client to improve its RTT
-estimate, the new packet that it sends MUST be ack-eliciting.  If Handshake
-keys are available to the client, it MUST send a Handshake packet, and
-otherwise it MUST send an Initial packet in a UDP datagram of at least 1200
-bytes.
+MUST ensure that the retransmission timer is set if the client has not received
+an ACK in a Handshake packet and does not yet have 1-RTT keys.  If the probe

This still doesn't work. I think spell it out a bit more might help clarify... how about replacing the sentence with:

"Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send data to unblock the server until it is certain that the server has finished its validation. That is, the client MUST set the retransmission timer if one of the following conditions is true: the client does not yet have 1-RTT keys, or the client has not received an ACK for one of its Handshake packets."

-- 
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/2907#pullrequestreview-279174450