IETF Logo Mail Archive

Re: [quicwg/base-drafts] Bound 0-to-1-RTT Transition (#2466)

Martin Thomson <notifications@github.com> Thu, 14 February 2019 22:27 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 BC9251311FC for <quic-issues@ietfa.amsl.com>; Thu, 14 Feb 2019 14:27:19 -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_IMAGE_ONLY_32=0.001, 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 dhljiQ2yoMnS for <quic-issues@ietfa.amsl.com>; Thu, 14 Feb 2019 14:27:17 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5931311F4 for <quic-issues@ietf.org>; Thu, 14 Feb 2019 14:27:17 -0800 (PST)
Date: Thu, 14 Feb 2019 14:27:16 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1550183236; bh=NB1bt5zSaOMjSJMgTw5ARd+qyytC3z4mhd010La3HPk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lipzcm9lG/faeHD8uPyXbF4dGXa3m5SWCHBqTWnZmJWBKpbPOYYB4b0HR7/CmjQMF KR5PS2uPxvD8MZIrpVHFcHP3zmcFY/0equdmWN9E7Nq2KfzFlS2fTIVpYR4lXn4hUs vLMfxgX1l5W9/NN7LPSitS9eP0clbafJUB8Vr+zU=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abf242c1691cb39b992e98ee7cf2019e72fdd216c492cf00000001187dad4492a169ce1877f890@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2466/review/204003139@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2466@github.com>
References: <quicwg/base-drafts/pull/2466@github.com>
Subject: Re: [quicwg/base-drafts] Bound 0-to-1-RTT Transition (#2466)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c65eb44be54d_5fd53fb18aad45b44258e4"; 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/V-QB8LFHtDfiXplXZvD-xcQpSfw>
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: Thu, 14 Feb 2019 22:27:20 -0000

martinthomson commented on this pull request.

More fundamentally than the objection below (which is minor), this unnecessarily creates lots of special cases.  Maybe that is what we're looking for here, but I would rather say that transport parameters that can apply to 0-RTT need to be remembered, with a requirement to demonstrate that they don't apply before they can be forgotten/changed.

> @@ -2631,7 +2641,10 @@ number 0.  Subsequent packets sent in the same packet number space MUST increase
 the packet number by at least one.
 
 0-RTT and 1-RTT data exist in the same packet number space to make loss recovery
-algorithms easier to implement between the two packet types.
+algorithms easier to implement between the two packet types.  However, a client
+MUST NOT continue sending 0-RTT packets after beginning to use 1-RTT packets.
+Servers MUST drop 0-RTT packets with greater packet numbers than the lowest
+packet number they have received in a 1-RTT packet.

I don't like the drop requirement.  The client is violating the rules, and for no good reason.  The server can punish clients who act in this way.

-- 
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/2466#pullrequestreview-204003139

v2.23.0 | Report a Bug | By Email