RE: Go Back to Single Packet Number Space

Praveen Balasubramanian <pravb@microsoft.com> Thu, 26 July 2018 05:14 UTC

Return-Path: <pravb@microsoft.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 8658413101C for <quic@ietfa.amsl.com>; Wed, 25 Jul 2018 22:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level:
X-Spam-Status: No, score=-0.02 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 FuecqXjiof4M for <quic@ietfa.amsl.com>; Wed, 25 Jul 2018 22:14:53 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6F7131008 for <quic@ietf.org>; Wed, 25 Jul 2018 22:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XOTeTmLNxfeikq+Grzl/qyqODdZW5cLTi8HNc3vHKnI=; b=Zu+721OOLaPrcJJQg4q2usQWzuUM/zJctrpEfZn7EClyy8bltNLsAQm74lrSXinIhC1iXdyNi1nCVVV8F17BGnB/Q3KO2ZkzjjtXzPhWQjpcliHv4mPeN2EM+a36IxinugD/3wtMVvPnkbVyogFbJkmhmzYxde+4h3aLxwXtJr4=
Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0175.namprd21.prod.outlook.com (10.173.52.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.1; Thu, 26 Jul 2018 05:14:50 +0000
Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::60a2:45d4:b972:fca4]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::60a2:45d4:b972:fca4%6]) with mapi id 15.20.1017.000; Thu, 26 Jul 2018 05:14:50 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>, Tommy Pauly <tpauly@apple.com>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>, "quic@ietf.org" <quic@ietf.org>
CC: Martin Thomson <martin.thomson@gmail.com>
Subject: RE: Go Back to Single Packet Number Space
Thread-Topic: Go Back to Single Packet Number Space
Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0wANbUcAAALJdwAAAvnmgAAAQ0HqAAEfwiA=
Date: Thu, 26 Jul 2018 05:14:50 +0000
Message-ID: <MWHPR21MB0191F6DCED6296FCBC8E72ABB62B0@MWHPR21MB0191.namprd21.prod.outlook.com>
References: <DM5PR2101MB09016D44959E5796570F3CB7B3540@DM5PR2101MB0901.namprd21.prod.outlook.com> <CABkgnnUTPvrVALX0Xr9xGpJnTHq=yWN48NRqtcQSZ4bzGFjAYA@mail.gmail.com> <20180726030135.GA19322@ubuntu-dmitri>, <E2CFE327-4F6B-4217-B248-CE049764187A@apple.com> <DM5PR2101MB09015C909CB3527E73E355A8B32B0@DM5PR2101MB0901.namprd21.prod.outlook.com>
In-Reply-To: <DM5PR2101MB09015C909CB3527E73E355A8B32B0@DM5PR2101MB0901.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:3:16b:4667:1773:1541]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0175; 6:NWXq2nlWn5ct/C9rqFGkWeM5hUVmfIkNFxFEwg9W9/kSgYEYzgSzNCyWWti5WOA45rThIZkNni4eXr1crzNRoBLilm9JIaqdTdwQo8YsD4bGKqVgHjvGIluGRYucsYGf/5MHbwgwKItMWfWQJkajnZZ0Tm9kaiRHTxIs0C1nPhHq+trzhYjviIB28+5o1H972/jtlftbVH8lRD6sonp9hbbTNP38mBKL2e6NemGwUN2D7hDvty2MgytjLo6fZ1CGe5/bYTX/8XC43Xp/H/jwmeYlY65hID0BoTVk7aDMB+B7RbfAqkA4pZUdNiqa9VxDU6jhVgK3tT0LLwwHpa8YdUmIm9N8TYuxkbWO7LYc6PWT/jTWi60lBYaaZi++bL08pTDodVIxIW+rMZN2kyJlKyMmB9ucArZNQXgg4KiGGAMEqpKkL/+x3JYHH5QUygHG2iO/geCW7/Zq07bxVEi/lg==; 5:ZslBIU8ElNqOlw0Hu5/tHy3WZht68l7y0JLQF1zGQJ/917JrFZOaJx94VnKyXoGW0iHCAa6A65sPLd2CBGlkjdmHEFJKlot4XpZT9bJAFxvhWozCwqf0EMJh/++8sMvAN8fYcb0SRY1ouW9uFcn5Qmg793ONyI+YOzeHx3rkhPY=; 7:7Dlri5Ct4TZ4THXsV5Yri6ha4ZQq2ZxM8+gHp/dwmWCQTIT/IuS0RPJG95aTddnpj3hGZiK1ZZk7AEGKfWeCybwS9xW8DAFg1viBecCCI/r51A8bJWhNZ7Jrxp5G7JV7kpeadERKQrNC5tddO0BoHzoisrSAMMxT8TpeFKFsT5tYdk/xcg9ymZtINATePKv65IUGRkCKJS6SmohneCtm4D50lUyhVpNlayfp56PGjYD7aJuP1zEJyTXf1q1OYmjr
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 88484c39-8f11-4285-6f4a-08d5f2b6b6c8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MWHPR21MB0175;
x-ms-traffictypediagnostic: MWHPR21MB0175:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <MWHPR21MB0175207458C912A6B8375A4BB62B0@MWHPR21MB0175.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(80524489315369)(189930954265078)(85827821059158)(219752817060721)(21748063052155)(31960201722614);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(2018427008)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR21MB0175; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0175;
x-forefront-prvs: 07459438AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(396003)(136003)(366004)(199004)(189003)(99286004)(86362001)(102836004)(575784001)(86612001)(6506007)(53546011)(2501003)(74316002)(8990500004)(93886005)(2900100001)(110136005)(790700001)(6116002)(606006)(22452003)(81156014)(256004)(8936002)(81166006)(316002)(8676002)(6306002)(9686003)(54896002)(236005)(55016002)(229853002)(19609705001)(7736002)(33656002)(7696005)(6436002)(76176011)(105586002)(4326008)(5250100002)(39060400002)(46003)(10090500001)(97736004)(25786009)(68736007)(11346002)(2906002)(476003)(478600001)(186003)(10290500003)(53936002)(446003)(486006)(6246003)(106356001)(14454004)(966005)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0175; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: inYB4ULLVKexGbqjeNFeenPjWVeVdkjKXR8zlznQ3u0FXmx07hQStnzirPRViCB2refwuzfBvNEHSJ0YPemY0lodFmHeSZujdGZgtC9+a3C6FfhKPrlC8IK8cwQgYeE2qK2ratAZ0zWC9xyyYXlwecpJL2prektNdB1v/dHBDVYIczR5NvmoDoSN6NX30zRh9avmGREBLs9D3ZqbgNkZmH3xMvsQpQOoxmXT+cHb4yXKAQu6h6e631pN9UFcHDcWLsFTvOgsE44RfvNnYmUCIUo/OPnIHM4xashYT1ID3QGV4PJ3alql3Q4Ki49kN2EAjJrkwwthzjnqR0jSuz4OhEZwayNe4Hm1aSxqC4R+Qgo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0191F6DCED6296FCBC8E72ABB62B0MWHPR21MB0191namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 88484c39-8f11-4285-6f4a-08d5f2b6b6c8
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 05:14:50.5470 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0175
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g91pvdREfI07UEG8bXN2vJWFiY4>
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 05:14:56 -0000

I agree that multiple PN spaces are confusing and seem unnecessary. Loss recovery would be much simplified by having a single PN space. Its also easier to reason about the state of loss recovery and for debugging and diagnostics. The lower memory overhead is also a factor. We should aim for a simple design unless there is a strong reason not to. Single PN space was how the design was before draft 13 so I don't understand why there would be complications for implementation. Please note that you can trivially change the sender to have a single PN space by just using consecutive PN for the 3 spaces! And the receiver ACK tracking logic would be simplified as well.

From: QUIC <quic-bounces@ietf.org> On Behalf Of Nick Banks
Sent: Wednesday, July 25, 2018 9:37 PM
To: Tommy Pauly <tpauly@apple.com>; Dmitri Tikhonov <dtikhonov@litespeedtech.com>; quic@ietf.org
Cc: Martin Thomson <martin.thomson@gmail.com>
Subject: RE: Go Back to Single Packet Number Space


Since there are four encryption levels, the fact that there are only three packet spaces only makes things more confusing IMO.. If your argument is that matching them together makes things easier, then I'd think there should be four packet spaces. I think having all this duplication and separation just adds unnecessary complexity.



Sent from my Windows 10 device

[HxS - 15254 - 16.0.10325.20083]



________________________________
From: tpauly@apple.com<mailto:tpauly@apple.com> <tpauly@apple.com<mailto:tpauly@apple.com>> on behalf of Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>>
Sent: Wednesday, July 25, 2018 9:26:49 PM
To: Dmitri Tikhonov
Cc: Martin Thomson; Nick Banks; QUIC WG
Subject: Re: Go Back to Single Packet Number Space

As another implementer, I also prefer having the split packet spaces. The point isn't necessarily that it's good to have the triple spaces, but rather that it's nice to have the packet number spaces correspond tightly with the packet types and protection. The logic for handling a space can be treated more uniformly in that way, although it does involve potentially more memory to store the state.

Thanks,
Tommy

> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov <dtikhonov@litespeedtech.com<mailto:dtikhonov@litespeedtech.com>> wrote:
>
> On Thu, Jul 26, 2018 at 11:41:48AM +1000, Martin Thomson wrote:
>> The feedback I've heard is that the simplification is subjective.
>> Others have said that a single space would complicate their
>> implementation considerably more.
>
> EKR is one of the "others" [1] -- are there other implementers who
> prefer the triple packet space?
>
>  - Dmitri.
>
> 1. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&amp;data=02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&amp;sdata=fstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&data=02%7C01%7Cpravb%40microsoft.com%7C7a6598c7f2734f21a24508d5f2b1798b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636681766425990424&sdata=FKfn6LZV%2Fn9fbyja6Ug6hUQZdzvdVpnvqZdgmu3hChk%3D&reserved=0>
>