[quicwg/base-drafts] Go Back to Single Packet Number Space (#1579)

Nick Banks <notifications@github.com> Tue, 17 July 2018 20:09 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 6E892130E62 for <quic-issues@ietfa.amsl.com>; Tue, 17 Jul 2018 13:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jRyVALknsFgs for <quic-issues@ietfa.amsl.com>; Tue, 17 Jul 2018 13:09:21 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A57713109A for <quic-issues@ietf.org>; Tue, 17 Jul 2018 13:09:09 -0700 (PDT)
Date: Tue, 17 Jul 2018 13:09:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1531858148; bh=MBUiPRXu0MgV0KLSo4XXoPgYYPKrzGN1OdRzltyTTPw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Im35idbQ2tmNuJ7quu48Dazp12Fgl88A3eKFKKJnV6RT73GVTMcm1uXA1bIlulf7j H/3mkMJXK1DXrmyp6NyxsZzPA//rIbeO9gDC0x/OmKHXPLkteXH5s/GUXi8iP2Q2ij leBRdc7Q7RX0UluHWehagTP7mDoevrC1bDV1GyKM=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7c76c31232fe86cd285d09f8a82681c37ea4674192cf0000000117660ee492a169ce14638397@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1579@github.com>
Subject: [quicwg/base-drafts] Go Back to Single Packet Number Space (#1579)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b4e4ce420cdf_6572ad54bbb4f54118042"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/ZZzApLQtsMgXX8hhYY1-5FcgEX0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 17 Jul 2018 20:09:43 -0000

I think we should go back to a single packet number space, and allow for higher encryption levels/epochs to acknowledge packets sent/received in lower levels/epochs.

I have been working on the draft -13 updates for the last week or so, and having completely independent packet number spaces causes a lot of complexity. On the sender side, it requires separate loss detection logic per packet number space, though you still have one congestion control and recovery modules for the entire connection. Resolving the intersection of those two is a headache. On the receiver side, you need a separate tracker for all packets you have received in a given packet number space. At least in my implementation, that comes with a good bit more state than just a list/array of packet numbers. Then when it goes time to frame the acks for all these packet numbers, it's a mess to keep track of which types of packets need to be built, based on the data (both ACKs and CRYPTO) currently queued up.

The argument has been made, at least on the sender side, to use one contiguous set of packet numbers across all encryption levels/epochs. Yes, that does simply the loss detection logic somewhat, but doesn't help the receive and ACK side of things. Additionally, even if we were to mandate that behavior for everyone, the requirement that you ACK a packet in the same encryption level still causes a lot more complexity than the previous logic of always acknowledging in packets in the same (or greater) encryption level. It was a lot easier to implement the previous ACK model design, IMO.

Finally, for debugging purposes, it is really messy to see the same packet numbers, but at different encryption levels. It makes understanding exactly what's going on that much harder. It is a lot more natural to see packet numbers always increase for every packet send/received, independent of what encryption level is used.

Having all this extra complexity for just the handshake really seems like overkill. I understand and am all for the separate encryption levels, but I really think we should go back to a single packet number space and allow for ACK frames in higher encryption levels.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: