Re: Go Back to Single Packet Number Space

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 26 July 2018 06:56 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0690130DFC for <quic@ietfa.amsl.com>; Wed, 25 Jul 2018 23:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d7j_l8o7AQ-z for <quic@ietfa.amsl.com>; Wed, 25 Jul 2018 23:56:51 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C433130DF2 for <quic@ietf.org>; Wed, 25 Jul 2018 23:56:51 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id l7-v6so531605ioj.1 for <quic@ietf.org>; Wed, 25 Jul 2018 23:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=rl1MvuE2+LFd0Q+BaTpzCwfISPDw3sWfSSsas5VP1x0=; b=ut+3wxUUtXYO3+ePj7PR4dGTTbttEUSTtdhUjHROv14/B6GGJFUuV5uFkxWBX5iGs4 Wp1cUytuU5aLQAmvR00gZDs/ynwFmETupG5idSjyMQ2A0jruoGHZSXsHDxFaNVR/il73 LtM7ytT0/h/kS98kwM43DFSiPCt9oSXuXbyjh/dqVg/gZwNLgfv6KNnlqAW1HEQ77Aun bwmikK3Tyl7rOPydhpfd9KaVHq4hFmiDaOTp8MIIHTzNgslBM93cb22mxLFHwummM5z2 MmqHADSo8LQXJclFvNOvyq8LvuYFl2PQzswoqnI6F8wUhUPPmMsm3Nf8h2IU4LFE5+9m 46Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=rl1MvuE2+LFd0Q+BaTpzCwfISPDw3sWfSSsas5VP1x0=; b=tJi7aXtNqVeIGiSttHTrs75LkvzCOR75kdQUOawVuz9iXVNISNxiVttpBpEypesrnH y8I5mHyHs6gPMwNejH0UTQqTlBNjbXaYb5GuhzYyaBBAFrT4Vuk2Jac23JBrkX2H9Bwd 0x7hdHSszCwDRWu9FFNNbrX4xCbYqv+VcpkTH9YlxUnj6LwMp3+l2uHTfTRrkcbXVJ0j hk4T7dQ1Ail9OSFiX+G4qN7upKW0ZM95RtxZmDt490232dDpv2ucURu69I5J+dpbhQaL VQL+jXze/VXw+Ty6zBWqokiZS607RBTo7BSMgWKu2gISRP5Uei4yT+x+VZcDJfVPd3Dy VT1Q==
X-Gm-Message-State: AOUpUlGAMU80zI4sq6+IT/ySSg9lP/khlUm4rhcn+wC+grHt0OiiZoy3 DB8HW3ZljVlmEh6uzCHorfzIgvebIzJuaIVGL5E=
X-Google-Smtp-Source: AAOMgpfGExUic9mkcOxfm63wl7xUgdBrdL0+0FeXiKpTvV8dJwAKIvKbMJlj1yXdueENwUOcNKLfNhSEhFYhyyjx18c=
X-Received: by 2002:a6b:b685:: with SMTP id g127-v6mr523324iof.209.1532588210938; Wed, 25 Jul 2018 23:56:50 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Jul 2018 23:56:50 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <4C634335-AF46-402B-B155-5BF1B347BB07@netapp.com>
References: <DM5PR2101MB09016D44959E5796570F3CB7B3540@DM5PR2101MB0901.namprd21.prod.outlook.com> <CABkgnnUTPvrVALX0Xr9xGpJnTHq=yWN48NRqtcQSZ4bzGFjAYA@mail.gmail.com> <20180726030135.GA19322@ubuntu-dmitri> <4C634335-AF46-402B-B155-5BF1B347BB07@netapp.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 25 Jul 2018 23:56:50 -0700
Message-ID: <CAN1APdczJpS8a4hgZ=w_PZ_Wxug89yvbMHYeoLh8AbOTY496NQ@mail.gmail.com>
Subject: Re: Go Back to Single Packet Number Space
To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, "Eggert, Lars" <lars@netapp.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e668970571e17f89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/R36xBQHsvHD5RUT9dn_ZVhuzSYk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2018 06:56:54 -0000

I am not currently working on handshake so I don’t have detailed insights
but I see the following concerns:
As Nick writes:


   - Each metadata object has 2 bits for tracking encryption level used to
   send the packet.


This is a problem it you create a highly optimised data structure for the
general receive case. You double or triple the state you need in bitmaps
etc. - yes the counter argument is that you need more state for
retransmission, but these indices use critical cache buffers and
retransmission is rare and can be on disk or main memory.

By having separate packet number spaces you can afford a slower less
optimized logic isolated to the handshake and simplify the logic in the
main case.

So a single number space may be simpler for simpler implementation but more
complex for an advanced implementation.

A counter argument:

The initial handshake requires more state with multiple spaces. This means
that handshake must be done a  specially allocated control block otherwise
the main connections control block will be larger than necessary. This
could be a trade-off between indirection and minimum space required for
long living silent connections.

I believe the extra initial space is not actually a problem because you can
hand-over a read connection to the main connection logic. The additional
memory required during the connection can be a concern, but it isn’t likely
a problem because:  If you are a constrained device you only deal with one
connction at a time and refuse concurrent handshakes. If you are a massive
server, you can easily handle the overhead of 100K concurrent connections
each tracking 4 packet numbers for the duration of a handshake - as long as
the overhead does not spill into the long-term connection.

And finally, keeping the handshake logic out of the main connection makes
it much simpler to experiment with alternative handshakes, for example a
simple pre-shared static key for exchanging traffic keys.

Therefore, I prefer keeping the handshake logic separate from the main
connection as much as possible.



Kind Regards,
Mikkel Fahnøe Jørgensen


On 26 July 2018 at 08.42.52, Eggert, Lars (lars@netapp.com) wrote:


   - Each metadata object has 2 bits for tracking encryption level used to
   send the packet.