Re: [quicwg/base-drafts] Merge crypto timeout into PTO (#2655)

MikkelFJ <notifications@github.com> Sat, 27 April 2019 05:50 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 749D31200C4 for <quic-issues@ietfa.amsl.com>; Fri, 26 Apr 2019 22:50:28 -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, 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 T9YxZsr2kxj4 for <quic-issues@ietfa.amsl.com>; Fri, 26 Apr 2019 22:50:25 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86FA12008F for <quic-issues@ietf.org>; Fri, 26 Apr 2019 22:50:25 -0700 (PDT)
Date: Fri, 26 Apr 2019 22:50:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556344224; bh=kgmJdcKOeDllH/c7VfQ3KHpWqaWg/WAFsUPrxlExrPw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BqC6+5BVBrI1M9JdLPQifljYYuMOGOYO1oxrfcGlLhRFu4WHqGr7G/p8W4T496hIO BmzTnIedT5dSe3FAqDFeGzsUE9cjVQ4bol3DKIGN5SiNGk7a6jQZ1yGyqw3qzbF8b8 6ZFTpl6Mdzbmq5zWjD963YeAoL6a3VbV64v6grbw=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZAMLVKXVGSKTEKNCV22EQCBEVBNHHBUGOXBA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2655/review/231410100@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2655@github.com>
References: <quicwg/base-drafts/pull/2655@github.com>
Subject: Re: [quicwg/base-drafts] Merge crypto timeout into PTO (#2655)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc3eda07e8f1_25d53fa3082cd9645541"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/Zju6ZY9AAwefQIJnmPzRVLRhc_4>
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, 27 Apr 2019 05:50:28 -0000

mikkelfj commented on this pull request.

Overall, it's great to reduce the number of overlapping timers, but see comments.

> +The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should 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 crypto retransmission timer is set if there is
+unacknowledged crypto data or if the client does not yet have 1-RTT keys.
+If the crypto retransmission 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, containing only PING or PADDING

```suggestion
However, the client MUST send a new packet, containing only PADDING
```
PING is not valid nor necessary here, no?

> +the count of bytes in flight.
+
+Endpoints stop sending and receiving Initial packets once they start exchanging
+Handshake packets (see Section 17.2.2.1 of {{QUIC-TRANSPORT}}). At this point,
+recovery state for all in-flight Initial packets is discarded.
+
+When 0-RTT is rejected, recovery state for all in-flight 0-RTT packets is
+discarded.
+
+If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive
+before Initial packets, early 0-RTT packets will be declared lost, but that
+is expected to be infrequent.
+
+It is expected that keys are discarded after packets encrypted with them would
+be acknowledged or declared lost.  Initial secrets however might be destroyed
+sooner, as soon as handshake keys are available (see Section 4.10 of

Discarding keys based on being declared lost seems odd to me. Either you abandon the handshake, or you discard keys when you are ready to advance to the next PN space, however that is defined. That readiness might involve overlapped PN spaces, waiting for older packets to ACK or to declare lost, but loss alone cannot be the criteria.

> @@ -689,6 +597,69 @@ is received that newly acknowledges packets, loss detection proceeds as
 dictated by packet and time threshold mechanisms, see {{ack-loss-detection}}.
 
 
+## PTO for Crypto Packets
+
+The initial PTO SHOULD be set to twice the initial RTT or 1 second if no
+initial RTT is available as recommended in {{?RFC6298}}.
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.
+If not all unacknowledged CRYPTO data can be sent, then all unacknowledged
+CRYPTO data sent in Initial packets should be retransmitted.  If no data can be
+sent, then no alarm should be armed until data has been received from the
+client.
+

If no alarm is armed, the connection is at the mercy of the client. I supposed connection timeout is not armed yet, and also the wrong metric, but the server needs to be able to time out the connection attempt somehow.

On a related note, text below on Retry/VNEG says they do not ack an Initial, but I suppose they could be used to time out connection state server side?

-- 
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/2655#pullrequestreview-231410100