Re: Go Back to Single Packet Number Space

Kazuho Oku <> Thu, 26 July 2018 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D679D130F81 for <>; Thu, 26 Jul 2018 01:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oHmshXxrffB5 for <>; Thu, 26 Jul 2018 01:33:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 13F7013104C for <>; Thu, 26 Jul 2018 01:33:34 -0700 (PDT)
Received: by with SMTP id f135-v6so614642lfg.10 for <>; Thu, 26 Jul 2018 01:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2h+j7QGaAn+1jcvziz6j9Vh0Fy/kRHU4hUqodRf0d3g=; b=Ii/ijsR5z47MAU+8dR5AZTMsYuCTnwvsuKVZ0qeRMMd8LWPcEY7DPTbw+nK0Hte+ph Q5Olsoq8l6AMqBuUbzRjWLZG90MV2mKhp07GnFanbFE2jak4jc0afSD1TeVdB/oRxX4d 7w1L5cgK39FkdyiPMRcrmbaB4eLMqXNeXESBohx/j5ygVriCAoVY9UFVjSnC2vXCbCHB 8Hx0uHtB9qsAjMVCJOm0o96toY9JU00TN2MsotFMJrahhLqKIDePKofgxLjDmQBhYn1m UF3xKXVD0Muukmws6MIyL2RO+vxlG8lKfG8ROUUz62T//8GMM/Yw7Y1Nv4GjJkujYC5E AJvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2h+j7QGaAn+1jcvziz6j9Vh0Fy/kRHU4hUqodRf0d3g=; b=geXqVpGxpA3AkJM+31Fqeuw9VAJYiTEQaS9n21TD6tLYaPPLJbLaNDBK2R0IFKiLLC aTgBNvxctNOjxKDV+VJHZj6+VrYGpO+niKU1byddL78E27IncQZtl2yh4zxrMeiVvR2X 01ER79VDwer1/HlGSYdp5nBdrwLXwfyaW+6WSYHtW13OkpaacfBNmMMlOuiZREGByeBG /QEdUcAQZ2SbUSor6RA9TYs3OwrtH5Y0G+59Oa3jYeFV2xuaJ3Lrje1us5puSxP2l9Vp FSqEYWs4tb/DVzyq9ySiAIMwNH3sGLHvlemWTUqu3W5+uwxBx8clScVjSkQJq6OKLUvE rl5A==
X-Gm-Message-State: AOUpUlHYs75iLmxjzeDsjg6rgJD4bgcba+2cZAqO8awtLZupJyNOgpvK W7DI5ocKkzOgwIpdwkRA56j89NlZBin2BFHEiY3YN4th
X-Google-Smtp-Source: AAOMgpf0k5AKNpR/QyM5a+i3moQdnQuokuMCoAHighmqGyonj/aCHEx8XFAWXj1BX9MWt9pvwh9PG3AKgU7mVLwE2ps=
X-Received: by 2002:a19:d484:: with SMTP id l126-v6mr714360lfg.28.1532594013200; Thu, 26 Jul 2018 01:33:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 01:33:32 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Kazuho Oku <>
Date: Thu, 26 Jul 2018 17:33:32 +0900
Message-ID: <>
Subject: Re: Go Back to Single Packet Number Space
To: Martin Thomson <>
Cc: Nick Banks <>, QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jul 2018 08:33:39 -0000

I prefer having split packet number spaces, because in addition to
what Martin says, I feel uneasy about allowing a receiver to
acknowledge a packet "in a greater than or equal encryption level."

My understanding is that this the key of the proposal. Use of a
unified packet number space makes sense only when an endpoint can send
an acknowledgement for all packets that it has received in one
encryption level.

This does sound like a nice hack, but I wonder if it might be too
fragile to changes in TLS that might happen in the future.

At the moment, there is one issue, which might be subtle.

Consider the case where the client is sending it's 2nd flight that
consists of a Handshake packet containing ClientFinished (and
optionally Certificate, CertificateVerify), and a 1-RTT packet
containing application data. At this point, the client knows the 1-RTT
write key, and because the server typically sends NST at the same time
it sends ServerFinished using 0.5 RTT data, the client will be
required to send ACK as part of the 1-RTT packet.

This means that if the Handshake packet gets lost, the server will not
be able to process the ACK even if the packet that contained the ACK
reaches the server, because 1-RTT read key on the server-side is yet
to be activated.

I am not sure how important this issue is.

It might cause excessive retransmits from the server than what we
would see in the separate packet number space approach. The fact that
the server will be sending RTO packets while the user selects his /
her certificate using the client-side UI makes me giggle, but it might
not be a big deal.

However, the existence of such issues make me wonder that the proposal
is relying too much on the details of TLS 1.3. And I am not sure if
the issue explained here is the only problem.

Considering the fact that having split packet number space is just
about having an ACK queue for 3 levels, I would prefer retaining
current design rather than implementing a "hack" that could have
corner cases.

2018-07-26 10:41 GMT+09:00 Martin Thomson <>:
> The feedback I've heard is that the simplification is subjective.
> Others have said that a single space would complicate their
> implementation considerably more.  You might want to say more about
> that.
> The loss of acknowledgements during the Initial phase has the
> unfortunate effect of forcing implementations to rely on implicit
> acknowledgment.  This doesn't seem like a problem now, but we're close
> to the quantum computer cryptographic apocalypse (put that on a
> sandwich board and yell it on street corners folks!) and this sort of
> reduction in capability could serious impair our ability to ship a key
> exchange that doesn't have problems.
> Now, this latter thing is not an unfixable problem if you cared about
> it, but it depends on what your real problem is.
> On Thu, Jul 26, 2018 at 5:29 AM Nick Banks
> <> wrote:
>> Hello Folks,
>> I have opened a GitHub Issue (#1579) and Pull Request (#1591) for this topic, but it seems progressed has stalled, so I figured I should take it to the list.
>> While implementing draft-13, I came across a number of pain points related to using multiple packet number spaces. A lot of the issues result in duplicated state (and associated memory) for all the packet number spaces. But more importantly, the multiple packet number spaces bring in a lot more complexity of logic, compared to the previous single packet number space design. There is a lot more detail in the GitHub issue, and I’d ask that folks take a look at it (and the PR) and provide any feedback they might have. I feel that my Issue adequately describes the problem and my PR provides good (if not better, IMO) solutions to the problems that were fixed previously with multiple packet number spaces. I believe having a single packet number space will drastically simplify implementations in the end.
>> Finally, as QUIC V1 (2?) is coming to a close (hopefully) I feel like we should resolve this issue soon. I don’t want this issue to slip out into the next version.
>> Thanks,
>> - Nick

Kazuho Oku