Re: [quicwg/base-drafts] 0-RTT status of new transport parameters (#3433)

Martin Thomson <notifications@github.com> Mon, 23 March 2020 04:24 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 ECCE33A0484 for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 21:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.695
X-Spam-Level:
X-Spam-Status: No, score=-1.695 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 17_wxTKjGKsC for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 21:24:35 -0700 (PDT)
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 6000E3A073D for <quic-issues@ietf.org>; Sun, 22 Mar 2020 21:24:35 -0700 (PDT)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id 4490A8C0F76 for <quic-issues@ietf.org>; Sun, 22 Mar 2020 21:24:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584937474; bh=eIlO3lfaIgwKHQ3CV94laCMeYCE0Mqe+hGbjnGYQB+U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=BdolBrAAxbV2JxG8o/IxrW51YmE92Etu7YR7zdPgvkiYC4hqTGvACGnmSovvYQ4Qh I5B5LVlzRULOtQxNDwtGaMttBa/DtUDfk02CUYQTcwOXWJHt4hB50miIdqw6V8lHBa P055TiMFHzLOTezk6jhy5hA3Okv2ul1W2pUiOQR8=
Date: Sun, 22 Mar 2020 21:24:34 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3FNBRNJR2FKDUVHEF4QQNQFEVBNHHCC3TPKM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3433/602377571@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3433@github.com>
References: <quicwg/base-drafts/issues/3433@github.com>
Subject: Re: [quicwg/base-drafts] 0-RTT status of new transport parameters (#3433)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e783a02324c2_b7e3fe63a8cd95c13029b"; 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/HMAzJD91bZKOktYjtZ8OjPV3S2M>
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: Mon, 23 Mar 2020 04:24:47 -0000

So I'm reviewing this and the only case I'm concerned about is max_ack_delay for 0-RTT.  The server's values might be remembered by the client and applied to its logic.  But I can't see any reason why this might cause actual problems as long as the client adjusts its value when it can.

If the server increases this value, then any increase might accrue to the RTT estimates that are received before the client installs the new value.  But the client won't be generating RTT estimates based on application data, so this is a wash.  And the effect on the PTO duration has no effect because you don't arm PTO because the recovery draft [forbids it](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#section-5.2.1-5).

So, I see three valid choices:

1. Say nothing.  Let people work out that max_ack_delay has no effect prior to the handshake completing on their own.

2. Explain this.  Probably just by saying "Note that max_ack_delay has no effect during the handshake therefore cannot be violated by a client sending 0-RTT data." OR something along those lines.

3. Explicitly forbid remembering this parameter, by adding it to the [MUST NOT use remembered values](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-7.3.1-3) list but don't explain it.

I'm inclined toward number 3 here, if only to save people the effort of working through this one.

-- 
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/3433#issuecomment-602377571