From nobody Sun Jul 1 09:27:45 2018 Return-Path: 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 2D0E4130DC8 for ; Sun, 1 Jul 2018 09:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 OJsTGAjChWg7 for ; Sun, 1 Jul 2018 09:27:42 -0700 (PDT) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 710EE12F1A5 for ; Sun, 1 Jul 2018 09:27:42 -0700 (PDT) Received: by mail-pl0-x230.google.com with SMTP id s24-v6so6769252plq.6 for ; Sun, 01 Jul 2018 09:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=os+OhHKUZubWC6gnApdUQmcYYvGirSAwoIGybUTo0s8=; b=oJPLUMhKtrvbNZ1i9qFhX4SoDMA2XLp4J/QKkTcLi4nJAhbWUdG4jTQYHJbJbko4uq MF1z5KTe6R1PGm38uZeiEsC5NdKLoqB8b892EVqK9pXnrdfpaAiUeFGGrk7IlJUuHGSK fO4s1IAkv9wg3EAcvxOL9U8n52QXJCAm/2SGV0mX/RT4Oy2pnAnyIckmeFdefkiVl1Ed aebA7NKMANjNNWcUIkRrnzfnb8kR4YiIhJz3hmR58tGKf5fIDW1hUGnUnExP3kC+4NRw Fad1gJh7baDa0fM8q/IknRzdLY8pXYTD4M7dMwHqm6oR7t7CdxC/SnOXc7lvlzEhFfr0 6qKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=os+OhHKUZubWC6gnApdUQmcYYvGirSAwoIGybUTo0s8=; b=TSgBsFqPxVX1Vgxdg+osmNwnOK/+ZTccRQMXOcuREJNBE3qxYtHX9XGeURw5h1MrCs 8IVUklwa2k+rQ2/E8pg8zwQqZ5UM4ZTmUYA4fTnTtWn/l4RUNVTLILb9bi57jlm9dwbt dlpFndnbSdjEzjK00QptkC7kRtK/zR8jhzH15ZxG38duvzdVJbzEW0o820kKVejlMmmz +vdLxCJplOYF/AFtyj56m30B2jn0rOEqSSv90hws3ZpJPXeNJ2JoGC8NjlmASgyNE4wm r7i7YZnyLDxaX4oRfrn2Q5awX9UlZcEYWiUhiFDZlv6vr4SiQ1mTKGj82R8DvMGWAPB0 PtYg== X-Gm-Message-State: APt69E0DFdOcNU58b9KzHHtPSVA04dmOAN/S2GEu0hFH9y75qrKk/rj0 o/Bx+Rsxtcw114B7MdC5YlfX2iock+Z3tRIzY54= X-Google-Smtp-Source: ADUXVKLOJnowwuOeIPjHM2fPzlJkCQ7LrVt4PN8cnLiAmh4mYNeQbUrAs9i8otzfbrZgjgHgitUu6qvEvArOvPtOcSc= X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr22722936plb.208.1530462462001; Sun, 01 Jul 2018 09:27:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:1181:0:0:0:0 with HTTP; Sun, 1 Jul 2018 09:27:41 -0700 (PDT) In-Reply-To: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Kazuho Oku Date: Mon, 2 Jul 2018 01:27:41 +0900 Message-ID: Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions) To: "Lubashev, Igor" , Praveen Balasubramanian Cc: "huitema@huitema.net" , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 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: Sun, 01 Jul 2018 16:27:44 -0000 2018-06-30 12:43 GMT+09:00 Lubashev, Igor : > It would make sense to define PING to require an ACK as soon as possible. > The need for an immediate ACK is not just in tail loss probes. It is also > PMTU probes. Come to think of this, PATH_CHALLENGE should require an > expedited ACK as well. That approach would work well. In my view, there are two ways; i) define a frame that requests immediate ACK, and bundle that frame with other frames if immediate ACK is required, ii) define which frames trigger immediate ACK. I think either of the two are workable. Re Praveen's comment, my understanding is that there are cases that a sender wants to trigger immediate ACK even if gap is not observed on the receiver side. In case of TLP, such behavior is desirable because it gives the peers to recover earlier from the loss of a previous packet that contained an ACK. > > - Igor > > > -----Original Message----- > From: Kazuho Oku [kazuhooku@gmail.com] > Received: Friday, 29 Jun 2018, 11:14PM > To: Christian Huitema [huitema@huitema.net] > CC: IETF QUIC WG [quic@ietf.org] > Subject: Speeding up tail loss detection (Re: Congestion control algorithm > questions) > > I know that the recovery draft defines TLP, but it does not provide a > way for a sender to request client to send an ACK immediately. I think > that there should be a way to request that, because it would help the > sender detect the loss at the earliest moment. > > One way is to specify a TLP frame, which is identical to a PING frame > with only one difference: it suggests the peer to send ACK > immediately. A sender sending a TLP will include the frame in the > packet to evoke the peer to send ACK without waiting for the delay. > > Searching the mailing list archive told me that Christian raised the > issue about a year ago (in the mail cited below), but it seems to me > that the issue has not been resolved yet. > > 2017-08-25 14:52 GMT+09:00 Christian Huitema : > >> 3) Can the senders do something to speed up retransmission? >> In the absence of continuous traffic flow, the previous decision tree >> degenerates to timer based retransmission. To speed things up, >> implementations can generate extra traffic. For example, if no >> acknowledgement is received after a short timer, they can send a >> gratuitous packet that may trigger a further acknowledgement. That's the >> essence of the "tail loss probe" algorithm of TCP, but things are really >> simpler with monotonously increasing packet sequence numbers. There are >> various plausible ways to send a gratuitous packet -- a Ping, a Max Data >> Update, or repeating the oldest packet will all work. >> >> Of course, implementations should avoid sending too many gratuitous >> packets, because it can cause congestion. The typical implementation >> will wait one min-RTT before sending the first tail loss probe, then >> just wait for the regular timer based retransmission. But we may start >> being creative. For example, if packets are waiting and the >> implementation is sending a naked ACK for whatever reason, it does not >> cost much to add a Ping to that. >> >> This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is >> very easy to implement. >> >> -- >> Christian Huitema >> >> > > > > -- > Kazuho Oku > -- Kazuho Oku From nobody Sun Jul 1 09:32:43 2018 Return-Path: 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 377E4130DC8 for ; Sun, 1 Jul 2018 09:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 fKSlOBBhZHaf for ; Sun, 1 Jul 2018 09:32:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0134.outbound.protection.outlook.com [104.47.38.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1938C12F1A5 for ; Sun, 1 Jul 2018 09:32:38 -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=QcBvBdTFiz9Cx7+TKUB5dgBmcRG/Cj+viu0FWMkcTvw=; b=Cd5X/KaCmfaGE936tqBoK8yzICeVl36AsvktYC9GKUqaqEZ68DKaBpuhzDt1vW9zZ4rZqAXgc9U2PwskGv+m4P897bsjZGUHjkQJNFGAs/ZA03ZH3ni06sWpy4nUEpVo+PZkDvq9Qqfa7S7kfG9xfBrZcWDYSjuJt00KjC06sp4= Received: from MW2PR2101MB1098.namprd21.prod.outlook.com (52.132.149.27) by MW2PR2101MB1097.namprd21.prod.outlook.com (52.132.149.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.4; Sun, 1 Jul 2018 16:32:34 +0000 Received: from MW2PR2101MB1098.namprd21.prod.outlook.com ([fe80::ca9:e464:9c1b:dd55]) by MW2PR2101MB1098.namprd21.prod.outlook.com ([fe80::ca9:e464:9c1b:dd55%5]) with mapi id 15.20.0952.003; Sun, 1 Jul 2018 16:32:34 +0000 From: Praveen Balasubramanian To: Kazuho Oku , "Lubashev, Igor" CC: huitema , "quic@ietf.org" Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions) Thread-Topic: Speeding up tail loss detection (Re: Congestion control algorithm questions) Thread-Index: AQHUECByHqG/zftGOUq9fkJj1zXpE6R4KKgAgAJn9ICAAAA6YA== Date: Sun, 1 Jul 2018 16:32:34 +0000 Message-ID: References: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2:a1c6:60df:b76a:58b5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB1097; 7:sdsYL5s9HaOMUcnSIXEmzV5spBw3fvYVoiPb8sPklNmgvy3KR/2toynCXtZDx4w737doUSJRHoS9JTxByR6O4KvypLMMrs5nTukV0uQktAEFEtktKTIcoYBIOez0epWDPYGFWQ325mGwnAA0R/nwaGbJELWJc29Bai0PvSqJuSz32RgBEw66XyBMmCVK4gR+0IIawoHJ07vsyv4OYRhS8dQwW7OMLVV4+N7T6h+W0R7+kxojZH0247+vQyPczd+1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b7fa16b2-be4f-46c3-061c-08d5df70401a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:MW2PR2101MB1097; x-ms-traffictypediagnostic: MW2PR2101MB1097: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231270)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MW2PR2101MB1097; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB1097; x-forefront-prvs: 07200C0526 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(39860400002)(136003)(199004)(189003)(13464003)(229853002)(2900100001)(46003)(105586002)(486006)(55016002)(33656002)(6116002)(68736007)(97736004)(446003)(11346002)(5660300001)(256004)(14444005)(2906002)(476003)(316002)(102836004)(186003)(25786009)(6346003)(14454004)(86612001)(22452003)(6506007)(10290500003)(54906003)(305945005)(4326008)(74316002)(7736002)(110136005)(8676002)(10090500001)(81156014)(86362001)(53936002)(8936002)(106356001)(81166006)(478600001)(6436002)(8990500004)(7696005)(9686003)(39060400002)(53546011)(99286004)(6246003)(76176011)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1097; H:MW2PR2101MB1098.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: K3qqQe89/1hUWgVhATRoKC9VMzASeUoHKsLSky/0Nfgvtl725EWnKD8KcKpVeHBt7L2UKkEOpu/kfopZUAptf8RHgQOYIo/ekuv+dTqChBZdhW9DvUhenshHbCcT+4yNBSPNXatr5QsnDByEfDXt2UCUD99+amncqtr1OGdZsxUT4ETD3LJhhrUO8RK8182S4zGtIt0g6bNwFMkh8xrmBM6jV9KCNkdg58us/aDD/ZTNYj69gyMTyqtvFgxONfb0CXbdOU0BgRLuOFtY8g10axsvWJ2eENDo8xTWGAjFuLD0lzd6Y/O7yxSkhzSUZQJ9/naOcqAy87Sjr1wE+dsb/kicjJ/e6D0ZWXKaiPOyCw8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7fa16b2-be4f-46c3-061c-08d5df70401a X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2018 16:32:34.5670 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1097 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 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: Sun, 01 Jul 2018 16:32:41 -0000 RG9lc27igJl0IHRoZSBQSU5HIGZyYW1lIHNlcnZlcyB0aGlzIHB1cnBvc2U/IFRoZSBsYW5ndWFn ZSBpbiB0aGUgdHJhbnNwb3J0IGRyYWZ0IGlzbuKAmXQgdmVyeSBjbGVhcjoNCglUaGUgcmVjZWl2 ZXIgb2YgYSBQSU5HIGZyYW1lIHNpbXBseSBuZWVkcyB0byBhY2tub3dsZWRnZSB0aGUgcGFja2V0 IGNvbnRhaW5pbmcgdGhpcyBmcmFtZS4NCg0KSWRlYWxseSB0aGlzIHNob3VsZCBzYXk6DQoJVGhl IHJlY2VpdmVyIG9mIGEgUElORyBmcmFtZSBTSE9VTEQgc2VuZCBhbiBpbW1lZGlhdGUgQUNLIGFj a25vd2xlZGdpbmcgdGhlIHBhY2tldCBjb250YWluaW5nIHRoaXMgZnJhbWUuDQoNCj4gdGhhdCB0 aGVyZSBhcmUgY2FzZXMgdGhhdCBhIHNlbmRlciB3YW50cyB0byB0cmlnZ2VyIGltbWVkaWF0ZSBB Q0sgZXZlbiBpZiBnYXAgaXMgbm90IG9ic2VydmVkIG9uIHRoZSByZWNlaXZlciBzaWRlDQpJZiB0 aGlzIGlzIGZvciB0aW1pbmcgbWVhc3VyZW1lbnRzIG9yIGxpdmVuZXNzIHRoZW4gUElORyBzaG91 bGQgd29yay4gSWYgeW91IGhhdmUgZXhhbXBsZXMgd2hlcmUgbG9zcyByZWNvdmVyeSBjYW4gYmUg ZnVydGhlciBpbXByb3ZlZCB1c2luZyBzdWNoIGEgbWVjaGFuaXNtIHRoZW4gd2Ugc2hvdWxkIGNl cnRhaW5seSBhZGRyZXNzIGl0LiBJIGRvbuKAmXQgdGhpbmsgd2UgY2FuIG1ha2UgYW55IGFzc3Vt cHRpb25zIG9uIHRoZSBzZW5kZXIgdGhhdCByZWNlaXZlciB3aWxsIEFDSyBiZWNhdXNlIHB1cmUg QUNLIGNhbiBhbHNvIGJlIGRyb3BwZWQgYW5kIG5vdCByZXRyYW5zbWl0dGVkLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F6dWhvIE9rdSBbbWFpbHRvOmthenVob29rdUBn bWFpbC5jb21dIA0KU2VudDogU3VuZGF5LCBKdWx5IDEsIDIwMTggOToyOCBBTQ0KVG86IEx1YmFz aGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4g PHByYXZiQG1pY3Jvc29mdC5jb20+DQpDYzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47 IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTcGVlZGluZyB1cCB0YWlsIGxvc3MgZGV0ZWN0 aW9uIChSZTogQ29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobSBxdWVzdGlvbnMpDQoNCjIwMTgt MDYtMzAgMTI6NDMgR01UKzA5OjAwIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29t PjoNCj4gSXQgd291bGQgbWFrZSBzZW5zZSB0byBkZWZpbmUgUElORyB0byByZXF1aXJlIGFuIEFD SyBhcyBzb29uIGFzIHBvc3NpYmxlLg0KPiBUaGUgbmVlZCBmb3IgYW4gaW1tZWRpYXRlIEFDSyBp cyBub3QganVzdCBpbiB0YWlsIGxvc3MgcHJvYmVzLiBJdCBpcyANCj4gYWxzbyBQTVRVIHByb2Jl cy4gQ29tZSB0byB0aGluayBvZiB0aGlzLCBQQVRIX0NIQUxMRU5HRSBzaG91bGQgcmVxdWlyZSAN Cj4gYW4gZXhwZWRpdGVkIEFDSyBhcyB3ZWxsLg0KDQpUaGF0IGFwcHJvYWNoIHdvdWxkIHdvcmsg d2VsbC4NCg0KSW4gbXkgdmlldywgdGhlcmUgYXJlIHR3byB3YXlzOyBpKSBkZWZpbmUgYSBmcmFt ZSB0aGF0IHJlcXVlc3RzIGltbWVkaWF0ZSBBQ0ssIGFuZCBidW5kbGUgdGhhdCBmcmFtZSB3aXRo IG90aGVyIGZyYW1lcyBpZiBpbW1lZGlhdGUgQUNLIGlzIHJlcXVpcmVkLCBpaSkgZGVmaW5lIHdo aWNoIGZyYW1lcyB0cmlnZ2VyIGltbWVkaWF0ZSBBQ0suIEkgdGhpbmsgZWl0aGVyIG9mIHRoZSB0 d28gYXJlIHdvcmthYmxlLg0KDQpSZSBQcmF2ZWVuJ3MgY29tbWVudCwgbXkgdW5kZXJzdGFuZGlu ZyBpcyB0aGF0IHRoZXJlIGFyZSBjYXNlcyB0aGF0IGEgc2VuZGVyIHdhbnRzIHRvIHRyaWdnZXIg aW1tZWRpYXRlIEFDSyBldmVuIGlmIGdhcCBpcyBub3Qgb2JzZXJ2ZWQgb24gdGhlIHJlY2VpdmVy IHNpZGUuIEluIGNhc2Ugb2YgVExQLCBzdWNoIGJlaGF2aW9yIGlzIGRlc2lyYWJsZSBiZWNhdXNl IGl0IGdpdmVzIHRoZSBwZWVycyB0byByZWNvdmVyIGVhcmxpZXIgZnJvbSB0aGUgbG9zcyBvZiBh IHByZXZpb3VzIHBhY2tldCB0aGF0IGNvbnRhaW5lZCBhbiBBQ0suDQoNCj4NCj4gLSBJZ29yDQo+ DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEthenVobyBPa3UgW2th enVob29rdUBnbWFpbC5jb21dDQo+IFJlY2VpdmVkOiBGcmlkYXksIDI5IEp1biAyMDE4LCAxMTox NFBNDQo+IFRvOiBDaHJpc3RpYW4gSHVpdGVtYSBbaHVpdGVtYUBodWl0ZW1hLm5ldF0NCj4gQ0M6 IElFVEYgUVVJQyBXRyBbcXVpY0BpZXRmLm9yZ10NCj4gU3ViamVjdDogU3BlZWRpbmcgdXAgdGFp bCBsb3NzIGRldGVjdGlvbiAoUmU6IENvbmdlc3Rpb24gY29udHJvbCANCj4gYWxnb3JpdGhtDQo+ IHF1ZXN0aW9ucykNCj4NCj4gSSBrbm93IHRoYXQgdGhlIHJlY292ZXJ5IGRyYWZ0IGRlZmluZXMg VExQLCBidXQgaXQgZG9lcyBub3QgcHJvdmlkZSBhIA0KPiB3YXkgZm9yIGEgc2VuZGVyIHRvIHJl cXVlc3QgY2xpZW50IHRvIHNlbmQgYW4gQUNLIGltbWVkaWF0ZWx5LiBJIHRoaW5rIA0KPiB0aGF0 IHRoZXJlIHNob3VsZCBiZSBhIHdheSB0byByZXF1ZXN0IHRoYXQsIGJlY2F1c2UgaXQgd291bGQg aGVscCB0aGUgDQo+IHNlbmRlciBkZXRlY3QgdGhlIGxvc3MgYXQgdGhlIGVhcmxpZXN0IG1vbWVu dC4NCj4NCj4gT25lIHdheSBpcyB0byBzcGVjaWZ5IGEgVExQIGZyYW1lLCB3aGljaCBpcyBpZGVu dGljYWwgdG8gYSBQSU5HIGZyYW1lIA0KPiB3aXRoIG9ubHkgb25lIGRpZmZlcmVuY2U6IGl0IHN1 Z2dlc3RzIHRoZSBwZWVyIHRvIHNlbmQgQUNLIA0KPiBpbW1lZGlhdGVseS4gQSBzZW5kZXIgc2Vu ZGluZyBhIFRMUCB3aWxsIGluY2x1ZGUgdGhlIGZyYW1lIGluIHRoZSANCj4gcGFja2V0IHRvIGV2 b2tlIHRoZSBwZWVyIHRvIHNlbmQgQUNLIHdpdGhvdXQgd2FpdGluZyBmb3IgdGhlIGRlbGF5Lg0K Pg0KPiBTZWFyY2hpbmcgdGhlIG1haWxpbmcgbGlzdCBhcmNoaXZlIHRvbGQgbWUgdGhhdCBDaHJp c3RpYW4gcmFpc2VkIHRoZSANCj4gaXNzdWUgYWJvdXQgYSB5ZWFyIGFnbyAoaW4gdGhlIG1haWwg Y2l0ZWQgYmVsb3cpLCBidXQgaXQgc2VlbXMgdG8gbWUgDQo+IHRoYXQgdGhlIGlzc3VlIGhhcyBu b3QgYmVlbiByZXNvbHZlZCB5ZXQuDQo+DQo+IDIwMTctMDgtMjUgMTQ6NTIgR01UKzA5OjAwIENo cmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjoNCj4NCj4+IDMpIENhbiB0aGUg c2VuZGVycyBkbyBzb21ldGhpbmcgdG8gc3BlZWQgdXAgcmV0cmFuc21pc3Npb24/DQo+PiBJbiB0 aGUgYWJzZW5jZSBvZiBjb250aW51b3VzIHRyYWZmaWMgZmxvdywgdGhlIHByZXZpb3VzIGRlY2lz aW9uIHRyZWUgDQo+PiBkZWdlbmVyYXRlcyB0byB0aW1lciBiYXNlZCByZXRyYW5zbWlzc2lvbi4g VG8gc3BlZWQgdGhpbmdzIHVwLCANCj4+IGltcGxlbWVudGF0aW9ucyBjYW4gZ2VuZXJhdGUgZXh0 cmEgdHJhZmZpYy4gRm9yIGV4YW1wbGUsIGlmIG5vIA0KPj4gYWNrbm93bGVkZ2VtZW50IGlzIHJl Y2VpdmVkIGFmdGVyIGEgc2hvcnQgdGltZXIsIHRoZXkgY2FuIHNlbmQgYSANCj4+IGdyYXR1aXRv dXMgcGFja2V0IHRoYXQgbWF5IHRyaWdnZXIgYSBmdXJ0aGVyIGFja25vd2xlZGdlbWVudC4gVGhh dCdzIA0KPj4gdGhlIGVzc2VuY2Ugb2YgdGhlICJ0YWlsIGxvc3MgcHJvYmUiIGFsZ29yaXRobSBv ZiBUQ1AsIGJ1dCB0aGluZ3MgYXJlIA0KPj4gcmVhbGx5IHNpbXBsZXIgd2l0aCBtb25vdG9ub3Vz bHkgaW5jcmVhc2luZyBwYWNrZXQgc2VxdWVuY2UgbnVtYmVycy4gDQo+PiBUaGVyZSBhcmUgdmFy aW91cyBwbGF1c2libGUgd2F5cyB0byBzZW5kIGEgZ3JhdHVpdG91cyBwYWNrZXQgLS0gYSANCj4+ IFBpbmcsIGEgTWF4IERhdGEgVXBkYXRlLCBvciByZXBlYXRpbmcgdGhlIG9sZGVzdCBwYWNrZXQg d2lsbCBhbGwgd29yay4NCj4+DQo+PiBPZiBjb3Vyc2UsIGltcGxlbWVudGF0aW9ucyBzaG91bGQg YXZvaWQgc2VuZGluZyB0b28gbWFueSBncmF0dWl0b3VzIA0KPj4gcGFja2V0cywgYmVjYXVzZSBp dCBjYW4gY2F1c2UgY29uZ2VzdGlvbi4gVGhlIHR5cGljYWwgaW1wbGVtZW50YXRpb24gDQo+PiB3 aWxsIHdhaXQgb25lIG1pbi1SVFQgYmVmb3JlIHNlbmRpbmcgdGhlIGZpcnN0IHRhaWwgbG9zcyBw cm9iZSwgdGhlbiANCj4+IGp1c3Qgd2FpdCBmb3IgdGhlIHJlZ3VsYXIgdGltZXIgYmFzZWQgcmV0 cmFuc21pc3Npb24uIEJ1dCB3ZSBtYXkgDQo+PiBzdGFydCBiZWluZyBjcmVhdGl2ZS4gRm9yIGV4 YW1wbGUsIGlmIHBhY2tldHMgYXJlIHdhaXRpbmcgYW5kIHRoZSANCj4+IGltcGxlbWVudGF0aW9u IGlzIHNlbmRpbmcgYSBuYWtlZCBBQ0sgZm9yIHdoYXRldmVyIHJlYXNvbiwgaXQgZG9lcyANCj4+ IG5vdCBjb3N0IG11Y2ggdG8gYWRkIGEgUGluZyB0byB0aGF0Lg0KPj4NCj4+IFRoaXMgc2ltcGxl IHRleHQgZW5jb21wYXNzZXMgU0FDSywgUkFDSywgYW5kIFRhaWwtTG9zcyBQcm9iZS4gQW5kIGl0 IA0KPj4gaXMgdmVyeSBlYXN5IHRvIGltcGxlbWVudC4NCj4+DQo+PiAtLQ0KPj4gQ2hyaXN0aWFu IEh1aXRlbWENCj4+DQo+Pg0KPg0KPg0KPg0KPiAtLQ0KPiBLYXp1aG8gT2t1DQo+DQoNCg0KDQot LQ0KS2F6dWhvIE9rdQ0K From nobody Sun Jul 1 10:20:46 2018 Return-Path: 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 7E48112F1A2 for ; Sun, 1 Jul 2018 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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] 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 wPqAkz-pOEm2 for ; Sun, 1 Jul 2018 10:20:44 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 0BD09126CC7 for ; Sun, 1 Jul 2018 10:20:43 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id p7-v6so371816ioh.13 for ; Sun, 01 Jul 2018 10:20:43 -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=Lh8JCuIUO4yR6PInwpCb3wwOKSaRKQscqLRoYN2AlRU=; b=G9sq1fppx5GmZvZEo1pzRQWOvwUJycVD6tUtQDcTtz+1Pz07NoBnscbEovlgI1EPq5 09Ac4M1nqaVb2ZTHZrCr1x2WWsdOqcOyFUpaqOsmBmcUO/EP+HNXSmeotaVVHj3qD1gb gCmHFqAveCHau2LTi6iqaHbOwwG5c5dHpTSvLAf8tgxbHRYvXuuzpzFqnpbD866UW39l cH+VjNX3cbM9BfRP3CXus4u+0Ne5+eEHzE+i1Ag17zITEoSX86GzJybb9HCmQgs5n6P8 l94gTUsiKUEu1PYADu8rYQz2awnkfLEK8mYbbox9QBSgLYnUz+ne2DP71TkyPhgclf29 8M+Q== 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=Lh8JCuIUO4yR6PInwpCb3wwOKSaRKQscqLRoYN2AlRU=; b=HnWo4j7fnkAR3RiKQNQ50va64R5ogtdf3DkryJ+S9V2NrpUR7AsGQE5cKZjebH1LwY +fTevcU6E58buwfJjf/vTonNWiUd4lzBxlj/uOjE3p0ZIjeols8RqOid4xu154qm2WPi TN4g8VKeeFqIhzUA7gb+wFEXPZ+QdeZYwrYStxDaeKwLP0aeG0HNDhF4n9qLDqGObpDB X8QNUjdPSJk/R83E2ObzNh+uo7Nze4B/r402oowYaOUPDUNdgAtVwsAGZyNt4ssBMu/6 KGf7yk56/JkamUOMdde5HLvgT2K00g5ByJQQfynno3xyf9ZTDIIVCFcG/pFYCpIQxaFM kH3Q== X-Gm-Message-State: APt69E0IkZ47AnV8LmIx6DUrv4WrF3nYE8cIpDUieXW9vSvijK5QqFl3 V2IcN4Oxd92ZQ1ZFwoxHnS0Zt2hNJI0gbTPHUf0= X-Google-Smtp-Source: AAOMgpdXzJoghSdBbnU7FaMkuYoPPql1yKydQhRD1LdxmdP3rEFUjBE1I0SPeyQRe3ZvYtiD/Wg4bO74X9/riebPJus= X-Received: by 2002:a6b:b685:: with SMTP id g127-v6mr18193091iof.209.1530465643336; Sun, 01 Jul 2018 10:20:43 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 1 Jul 2018 10:20:42 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 1 Jul 2018 10:20:42 -0700 Message-ID: Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions) To: Praveen Balasubramanian , "Lubashev, Igor" , Kazuho Oku Cc: huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000031d2e056ff34d85" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 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: Sun, 01 Jul 2018 17:20:46 -0000 --000000000000031d2e056ff34d85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 1 July 2018 at 18.32.56, Praveen Balasubramanian ( pravb=3D40microsoft.com@dmarc.ietf.org) wrote: Doesn=E2=80=99t the PING frame serves this purpose? The language in the tra= nsport draft isn=E2=80=99t very clear: The receiver of a PING frame simply needs to acknowledge the packet containing this frame. No, I asked for this several times, but there was no traction. It is ACK=E2= =80=99ed as any packet which the consensus considers soon enough. But I dont=E2=80= =99 think this takes into account use cases with delayed ACK and congestion algorithms that can tolerate longer delays. It=E2=80=99s simply useful to ping in order to get a roundtrip time on the connection, aside from what has already been mentioned. --000000000000031d2e056ff34d85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 1 July 2018 at 18= .32.56, Praveen Balasubramanian (pravb=3D40microsoft.com@dmarc.ietf.org) wrote:
Doesn=E2= =80=99t the PING frame serves this purpose? The language in the transport d= raft isn=E2=80=99t very clear:=C2=A0<= /span>
The receiver= of a PING frame simply needs to acknowledge the packet containing this fra= me.=C2=A0
<= /blockquote>


No, I asked for t= his several times, but there was no traction. It is ACK=E2=80=99ed as any p= acket which the consensus considers soon enough. But I dont=E2=80=99 think = this takes into account use cases with delayed ACK and congestion algorithm= s that can tolerate longer delays.

It=E2=80=99s si= mply useful to ping in order to get a roundtrip time on the connection, asi= de from what has already been mentioned.
--000000000000031d2e056ff34d85-- From nobody Mon Jul 2 01:45:55 2018 Return-Path: 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 860C6130E36 for ; Mon, 2 Jul 2018 01:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 bziMPRnFOsoy for ; Mon, 2 Jul 2018 01:45:51 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4069F129C6A for ; Mon, 2 Jul 2018 01:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530521149; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KTYAiJKu7dZHGh4e6usGanjwY3TOoVOyVFSlQIhbyWQ=; b=dmNhvU+PxBTqy/t3ajOmMCf6K8iUTF6Jsbbv1tmpjn28jryAjmHCOU4UeFx8WK7x bZzVR8yft6S7qCl1RXtFLxcW2TgXjv+kWwyDMiDFzci59YvZgiX8JeY/TzPI9c2H SEYUzJ6WkvSGBIJQXPH6jAnEhtwnv09mpSW8atzuINc=; X-AuditID: c1b4fb3a-dcb6e9c0000079c1-e0-5b39e63d8d64 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.BD.31169.D36E93B5; Mon, 2 Jul 2018 10:45:49 +0200 (CEST) Received: from [147.214.20.27] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 2 Jul 2018 10:45:47 +0200 Subject: Re: Treatment of ICMP for PMTU To: "Lubashev, Igor" , "Eggert, Lars" CC: IETF QUIC WG , Martin Duke References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Magnus Westerlund Message-ID: <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com> Date: Mon, 2 Jul 2018 10:45:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------DD5D1EAE514950E2644135BF" Content-Language: en-GB X-Originating-IP: [153.88.183.153] X-ClientProxiedBy: ESESSMB503.ericsson.se (153.88.183.164) To ESESSMB502.ericsson.se (153.88.183.163) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2J7ha7tM8tog62PxSyOzTrBZPHidQ+L xfTHL9gsehZwO7B4nFh2hdVj56y77B5Llvxk8pjx6QtbAEsUl01Kak5mWWqRvl0CV8bK5a8Z Cx6ZVhybn9TAeFWri5GTQ0LAROLu5/PsXYxcHEICRxkl9k5uYIZw3jFKLDv6jBGkSlhAXeL3 pQnsILaIQLzE7FPXwWxmAXeJUz2trBAN5xklzty5zgaSYBOwkLj5oxHM5hWwl/jVcgGsgUVA ReLBjHdgQ0UFYiRWb7zMDlEjKHFy5hMWEJtTIFii+fU6JogFYRIbt8IsE5do+rKSFcQWEtCW aGjqYIV4QUni+rzrLBB2usS0p2uYJjAKzUIydhaSUbOQjIKwLSRmzj/PCGHLSzRvnc0MYWtI tM6Zy44svoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYDwd3PLbagfjweeOhxgFOBiV eHgPnbeMFmJNLCuuzD3EKMHBrCTCK/rRPFqINyWxsiq1KD++qDQntfgQozQHi5I4r1OaRZSQ QHpiSWp2ampBahFMlomDU6qBkZuPRa53aafl3aJ5Tq+mPzM2ydk7z0vVYuHxtc0PBY4/cVZe E+HdMPfC5mfvzWcnmkmUiIQf26pWcaknqdhgu1C8pb288r6rL86EvJzbZ+qQmCeftc2TYVdJ wWbhpLBYsYk3HLz0CgwKWq6tC1MV3pK/Mlk7SCsaGP/aL44cXqM6KcLWslGJpTgj0VCLuag4 EQAfPeXgowIAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 02 Jul 2018 08:45:54 -0000 --------------DD5D1EAE514950E2644135BF Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor: >>> • What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)? >> Isn't this sufficiently covered in 4821? > Not really. Or, at least I could not find anything more useful there then: "If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message." So 4821 seems silent on what to do if ICMP is received for a non-probe packet, and it seems silent on how one could decide whether to set search_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help here). These questions are what I am trying to address for QUIC. > > 4821 uses MAY in the sentence above, since it does not really give any better indication. This PR draws a distinction between ICMP w/ and w/o on-path proof and in some specific cases, it recommends a SHOULD. > > If you look at the updated PLPMTUD: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ 3.3. Reducing the PLPMTU: Confirming Path Characteristics If the DPLPMTUD method detects that a packet with the PLPMTU size is no supported by the network path, then the DLPMTUD method needs to validate the PLPMTU. This can happen when a validated PTB message is received, or another event that indicates the network path no longer sustains this packet size, such as a loss report from the PL All implementations of DPLPMTUD are REQUIRED to provide support that reduces the PLPMTU when the actual PMTU supported by a network path is less than the PLPMTU. Section 4.9 says: PROBE_DONE: The PROBE_DONE state indicates a successful end to a probing phase. DPLPMTUD remains in this state until either the PMTU_RAISE_TIMER expires or a received PTB message is verified. However, I have to say that the draft is a bit unclear on what to do at this point. I guess the options are two. Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU. I will start a thread on TSVWG WG mailing list regarding the lack of specific text in their draft for this case. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------DD5D1EAE514950E2644135BF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi,


Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor:

      

        

          
 • What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)?


        

        
Isn't this sufficiently covered in 4821?


      

      
Not really.  Or, at least I could not find anything more useful there then: "If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message."  So 4821 seems silent on what to do if ICMP is received for a non-probe packet, and it seems silent on how one could decide whether to set search_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help here).  These questions are what I am trying to address for QUIC.

4821 uses MAY in the sentence above, since it does not really give any better indication.  This PR draws a distinction between ICMP w/ and w/o on-path proof and in some specific cases, it recommends a SHOULD.




    

    If you look at the updated PLPMTUD:

    

    https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/

    

    
3.3.  Reducing the PLPMTU: Confirming Path Characteristics

   If the DPLPMTUD method detects that a packet with the PLPMTU size is
   no supported by the network path, then the DLPMTUD method needs to
   validate the PLPMTU. This can happen when a validated PTB message is
   received, or another event that indicates the network path no longer
   sustains this packet size, such as a loss report from the PL

   All implementations of DPLPMTUD are REQUIRED to provide support that
   reduces the PLPMTU when the actual PMTU supported by a network path
   is less than the PLPMTU.

    

    Section 4.9 says:

    
   PROBE_DONE: The PROBE_DONE state indicates a successful end to a
      probing phase.  DPLPMTUD remains in this state until either the
      PMTU_RAISE_TIMER expires or a received PTB message is verified.

    

    However, I have to say that the draft is a bit unclear on what to do
    at this point. 

    

    I guess the options are two.

    

    Probe starting at PTB_SIZE or verify Base_MTU and then probe up.
    From my perspective, the important is that one uses this a signal
    for checking the PMTU. 

    

    I will start a thread on TSVWG WG mailing list regarding the lack of
    specific text in their draft for this case.

    

    Cheers

    
Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

  


--------------DD5D1EAE514950E2644135BF--


From nobody Mon Jul  2 07:49:56 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 035B11311B0; Mon,  2 Jul 2018 07:49:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: quic@ietf.org
Subject: I-D Action: draft-ietf-quic-applicability-02.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153054298196.16428.4469540506910232383@ietfa.amsl.com>
Date: Mon, 02 Jul 2018 07:49:42 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 14:49:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : Applicability of the QUIC Transport Protocol
        Authors         : Mirja Kuehlewind
                          Brian Trammell
	Filename        : draft-ietf-quic-applicability-02.txt
	Pages           : 10
	Date            : 2018-07-02

Abstract:
   This document discusses the applicability of the QUIC transport
   protocol, focusing on caveats impacting application protocol
   development and deployment over QUIC.  Its intended audience is
   designers of application protocol mappings to QUIC, and implementors
   of these application protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-applicability-02
https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-applicability-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jul  2 07:50:19 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0BF1311EE; Mon,  2 Jul 2018 07:49:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: quic@ietf.org
Subject: I-D Action: draft-ietf-quic-manageability-02.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153054299880.16179.237405143300036641@ietfa.amsl.com>
Date: Mon, 02 Jul 2018 07:49:58 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 14:50:05 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : Manageability of the QUIC Transport Protocol
        Authors         : Mirja Kuehlewind
                          Brian Trammell
	Filename        : draft-ietf-quic-manageability-02.txt
	Pages           : 15
	Date            : 2018-07-02

Abstract:
   This document discusses manageability of the QUIC transport protocol,
   focusing on caveats impacting network operations involving QUIC
   traffic.  Its intended audience is network operators, as well as
   content providers that rely on the use of QUIC-aware middleboxes,
   e.g. for load balancing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-quic-manageability-02
https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-manageability-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Jul  2 07:55:33 2018
Return-Path: 
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 B110A131106 for ; Mon,  2 Jul 2018 07:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 yrDaVmkwiki7 for ; Mon,  2 Jul 2018 07:55:09 -0700 (PDT)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDE4130DFC for ; Mon,  2 Jul 2018 07:54:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41K9Jc17HnzMp6b for ; Mon,  2 Jul 2018 16:54:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_MRYZY1lX3U for ; Mon,  2 Jul 2018 16:54:39 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (mue-88-130-61-042.dsl.tropolys.de [88.130.61.42]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA for ; Mon,  2 Jul 2018 16:54:38 +0200 (CEST)
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Subject: Re: I-D Action: draft-ietf-quic-applicability-02.txt
Date: Mon, 2 Jul 2018 16:54:35 +0200
References: <153054298196.16428.4469540506910232383@ietfa.amsl.com>
To: IETF QUIC WG 
In-Reply-To: <153054298196.16428.4469540506910232383@ietfa.amsl.com>
Message-Id: <4989F0E6-6B29-4908-9413-BF4351AB19CB@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 14:55:21 -0000

Hi all,

this is a resubmission without changes to keep the document alive/raise =
it from the dead. There are a few issue in GitHub regarding use/creation =
of CIDs and   (re-)use/selection of ports, that we would like further =
input on from the group in order to address them in the next version.

Mirja



> Am 02.07.2018 um 16:49 schrieb internet-drafts@ietf.org:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the QUIC WG of the IETF.
>=20
>        Title           : Applicability of the QUIC Transport Protocol
>        Authors         : Mirja Kuehlewind
>                          Brian Trammell
> 	Filename        : draft-ietf-quic-applicability-02.txt
> 	Pages           : 10
> 	Date            : 2018-07-02
>=20
> Abstract:
>   This document discusses the applicability of the QUIC transport
>   protocol, focusing on caveats impacting application protocol
>   development and deployment over QUIC.  Its intended audience is
>   designers of application protocol mappings to QUIC, and implementors
>   of these application protocols.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-quic-applicability-02
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-02
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-applicability-02
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20


From nobody Mon Jul  2 07:56:24 2018
Return-Path: 
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 31FE21274D0 for ; Mon,  2 Jul 2018 07:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cfwRu0KIrHkO for ; Mon,  2 Jul 2018 07:56:21 -0700 (PDT)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BE1130DFC for ; Mon,  2 Jul 2018 07:56:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41K9LW4zWxzMp5r for ; Mon,  2 Jul 2018 16:56:19 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa3SSZ0y4-87 for ; Mon,  2 Jul 2018 16:56:17 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (mue-88-130-61-042.dsl.tropolys.de [88.130.61.42]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA for ; Mon,  2 Jul 2018 16:56:17 +0200 (CEST)
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Subject: Re: I-D Action: draft-ietf-quic-manageability-02.txt
Date: Mon, 2 Jul 2018 16:56:16 +0200
References: <153054299880.16179.237405143300036641@ietfa.amsl.com>
To: IETF QUIC WG 
In-Reply-To: <153054299880.16179.237405143300036641@ietfa.amsl.com>
Message-Id: <06EF9348-4C68-4F2C-BAAA-5DBD95AF3C83@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 14:56:24 -0000

Hi all,

this update is to align the text with the latest version of the =
transport draft; in many cases mostly removing text. There is one big =
issue on the use of the CID that we would like further input on, or even =
better text contributions.

Mirja



> Am 02.07.2018 um 16:49 schrieb internet-drafts@ietf.org:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the QUIC WG of the IETF.
>=20
>        Title           : Manageability of the QUIC Transport Protocol
>        Authors         : Mirja Kuehlewind
>                          Brian Trammell
> 	Filename        : draft-ietf-quic-manageability-02.txt
> 	Pages           : 15
> 	Date            : 2018-07-02
>=20
> Abstract:
>   This document discusses manageability of the QUIC transport =
protocol,
>   focusing on caveats impacting network operations involving QUIC
>   traffic.  Its intended audience is network operators, as well as
>   content providers that rely on the use of QUIC-aware middleboxes,
>   e.g. for load balancing.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-quic-manageability-02
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-02
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-manageability-02
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20


From nobody Mon Jul  2 16:20:06 2018
Return-Path: 
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 976E21311F1 for ; Mon,  2 Jul 2018 16:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level: 
X-Spam-Status: No, score=-0.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 1yhn7O9WsCur for ; Mon,  2 Jul 2018 16:19:59 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EF2130E8E for ; Mon,  2 Jul 2018 16:19:59 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w62NIBFT022800; Tue, 3 Jul 2018 00:19:55 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ZFKmSskF2YOPxxNxKz8wGiAm5VqrD1dyHYec/JRzL+0=; b=TRhrLECsb9sZGtfagN6ur+cG3bocLEX/48AP7bo6zd0HBF/WcnjZswaGCVCo+4VAqbkn 6toztfM2DlhzYulYooOFnN40RUqiTWX3RLhkKnFDtGzXw7U8rtzc/33UEb0dW2yYmmf5 E2xW0UjZMj6FgdKnfHL5qbcWLlyYkMBAkQMT+UE4yHYxbgVXY8uPP6QaC5/JVDBbRcG1 SxkJ1eI47jDM16eo02DKby9CIqfheF0v5q5K9gmPoYsHj4iDZSSfcK0iDNhRAjuAgxwQ ewdWXnDNwQhi9Ksu5r8PUcc4sikUW3NnNCsG5G5nhTSS5tXrt3sc6z5dhu9w/56TLyCl Ow== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2jx1grppav-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 00:19:54 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w62NBPva008329; Mon, 2 Jul 2018 19:19:54 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jx56uw0g5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Jul 2018 19:19:53 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 2 Jul 2018 18:19:52 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Mon, 2 Jul 2018 18:19:52 -0500
From: "Lubashev, Igor" 
To: Magnus Westerlund , "Eggert, Lars" 
CC: IETF QUIC WG , Martin Duke 
Subject: RE: Treatment of ICMP for PMTU
Thread-Topic: Treatment of ICMP for PMTU
Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wAV77aAAAI9IOAA1Pw3gAASjHLQ
Date: Mon, 2 Jul 2018 23:19:51 +0000
Message-ID: <643f80954e6a45ba881c7d4a90a066d0@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com>
In-Reply-To: <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.38.207]
Content-Type: multipart/alternative; boundary="_000_643f80954e6a45ba881c7d4a90a066d0ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807020258
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807020259
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 23:20:05 -0000

--_000_643f80954e6a45ba881c7d4a90a066d0ustx2exdag1mb5msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

ICAqICAgUHJvYmUgc3RhcnRpbmcgYXQgUFRCX1NJWkUgb3IgdmVyaWZ5IEJhc2VfTVRVIGFuZCB0
aGVuIHByb2JlIHVwLiBGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgaW1wb3J0YW50IGlzIHRoYXQg
b25lIHVzZXMgdGhpcyBhIHNpZ25hbCBmb3IgY2hlY2tpbmcgdGhlIFBNVFUuDQoNCkZyb20gbXkg
cGVyc3BlY3RpdmUsIHRoZXJlIGFyZSB0d28gdGhpbmdzIHRoYXQgYXJlIGltcG9ydGFudCBoZXJl
Og0KDQogIDEuICBVc2UgUFRCIHNpZ25hbCB0byBzdGFydCBwcm9iaW5nIChhcyB5b3Ugc2FpZCku
ICBUaGlzIGlzIHNlY3Rpb24gMy4zLg0KICAyLiAgSWRlbnRpZnkgY2FzZXMsIHdoZW4geW91IGNh
biBzZXQgUE1UVSB0byBQVEJfU0laRSBpbW1lZGlhdGVseSB1cG9uIHJlY2VpcHQgb2YgUFRCLCB3
aGlsZSB0aGUgcHJvYmluZyBpcyBoYXBwZW5pbmcuDQoNClBsdXMgb25lIG1vcmUgdGhpbmcgdGhh
dCBpcyBub3QgaW4gdGhhdCBkcmFmdCBhdCBhbGwg4oCTIEkgdGhpbmsgaXQgaXMgcHJ1ZGVudCB0
byByZXNwZWN0IFBUQiwgZXZlbiBpZiB0aGF0IFBUQiBpcyBub3QgdmFsaWRhdGVkIChpLmUuIHcv
byBvbi1wYXRoIHByb29mLCB1c2luZyBteSBsaW5nbyksIGlmIFBUQl9TSVpFIGlzIGxhcmdlIGVu
b3VnaCAodG8gYmUgZGVmaW5lZCBob3cgbGFyZ2UpLiAgSXQgcHJvYmFibHkgZGVzZXJ2ZXMgaXRz
IG93biB0aHJlYWQgaW4gdHN2d2cuDQoNCg0KICAqICAgSWdvcg0KDQoNCkZyb206IE1hZ251cyBX
ZXN0ZXJsdW5kIFttYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tXQ0KU2VudDog
TW9uZGF5LCBKdWx5IDAyLCAyMDE4IDQ6NDYgQU0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFz
aGVAYWthbWFpLmNvbT47IEVnZ2VydCwgTGFycyA8bGFyc0BuZXRhcHAuY29tPg0KQ2M6IElFVEYg
UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWls
LmNvbT4NClN1YmplY3Q6IFJlOiBUcmVhdG1lbnQgb2YgSUNNUCBmb3IgUE1UVQ0KDQoNCkhpLA0K
DQpEZW4gMjAxOC0wNi0yOSBrbC4gMDI6MzAsIHNrcmV2IEx1YmFzaGV2LCBJZ29yOg0KDQoNCg0K
IOKAoiBXaGF0IHRvIGRvLCB3aGVuIGFuIElQdjQgSUNNUCAody9vIG9uLXBhdGggcHJvb2YpIHJl
cXVlc3QgYSBQTVRVIHJlZHVjdGlvbiAoYWZ0ZXIgaGFuZHNoYWtlKT8NCg0KDQoNCklzbid0IHRo
aXMgc3VmZmljaWVudGx5IGNvdmVyZWQgaW4gNDgyMT8NCg0KDQoNCk5vdCByZWFsbHkuICBPciwg
YXQgbGVhc3QgSSBjb3VsZCBub3QgZmluZCBhbnl0aGluZyBtb3JlIHVzZWZ1bCB0aGVyZSB0aGVu
OiAiSWYgYW4gSUNNUCBQVEIgbWVzc2FnZSBpcyByZWNlaXZlZCBtYXRjaGluZyB0aGUgcHJvYmUg
cGFja2V0LCB0aGVuIHNlYXJjaF9oaWdoIGFuZCBlZmZfcG10dSBNQVkgYmUgc2V0IGZyb20gdGhl
IE1UVSB2YWx1ZSBpbmRpY2F0ZWQgaW4gdGhlIG1lc3NhZ2UuIiAgU28gNDgyMSBzZWVtcyBzaWxl
bnQgb24gd2hhdCB0byBkbyBpZiBJQ01QIGlzIHJlY2VpdmVkIGZvciBhIG5vbi1wcm9iZSBwYWNr
ZXQsIGFuZCBpdCBzZWVtcyBzaWxlbnQgb24gaG93IG9uZSBjb3VsZCBkZWNpZGUgd2hldGhlciB0
byBzZXQgc2VhcmNoX2hpZ2ggYW5kIGVmZl9wbXR1IGZyb20gdGhlIE1UVSBpbiBJQ01QIG9yIG5v
dCAoc2F5aW5nICJNQVkiIGRvZXMgbm90IHJlYWxseSBoZWxwIGhlcmUpLiAgVGhlc2UgcXVlc3Rp
b25zIGFyZSB3aGF0IEkgYW0gdHJ5aW5nIHRvIGFkZHJlc3MgZm9yIFFVSUMuDQoNCg0KDQo0ODIx
IHVzZXMgTUFZIGluIHRoZSBzZW50ZW5jZSBhYm92ZSwgc2luY2UgaXQgZG9lcyBub3QgcmVhbGx5
IGdpdmUgYW55IGJldHRlciBpbmRpY2F0aW9uLiAgVGhpcyBQUiBkcmF3cyBhIGRpc3RpbmN0aW9u
IGJldHdlZW4gSUNNUCB3LyBhbmQgdy9vIG9uLXBhdGggcHJvb2YgYW5kIGluIHNvbWUgc3BlY2lm
aWMgY2FzZXMsIGl0IHJlY29tbWVuZHMgYSBTSE9VTEQuDQoNCg0KDQoNCklmIHlvdSBsb29rIGF0
IHRoZSB1cGRhdGVkIFBMUE1UVUQ6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LWlldGYtdHN2d2ctZGF0YWdyYW0tcGxwbXR1ZC88aHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2Nf
ZHJhZnQtMkRpZXRmLTJEdHN2d2ctMkRkYXRhZ3JhbS0yRHBscG10dWRfJmQ9RHdNRGFRJmM9OTZa
YlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5f
bTU1S1BtbG8mbT11REdJOWppUzdHZWczZGJ2Ny02WDEzaVdmVUlDS3kzZk9pZWtKWWFPX0hBJnM9
TVFSaFduc0xUZ08zc1JYTS1Fbk12WVRSb1g5SHViVHlzU2ZUX0ZQaWNKayZlPT4NCg0KMy4zLiAg
UmVkdWNpbmcgdGhlIFBMUE1UVTogQ29uZmlybWluZyBQYXRoIENoYXJhY3RlcmlzdGljcw0KDQoN
Cg0KICAgSWYgdGhlIERQTFBNVFVEIG1ldGhvZCBkZXRlY3RzIHRoYXQgYSBwYWNrZXQgd2l0aCB0
aGUgUExQTVRVIHNpemUgaXMNCg0KICAgbm8gc3VwcG9ydGVkIGJ5IHRoZSBuZXR3b3JrIHBhdGgs
IHRoZW4gdGhlIERMUE1UVUQgbWV0aG9kIG5lZWRzIHRvDQoNCiAgIHZhbGlkYXRlIHRoZSBQTFBN
VFUuIFRoaXMgY2FuIGhhcHBlbiB3aGVuIGEgdmFsaWRhdGVkIFBUQiBtZXNzYWdlIGlzDQoNCiAg
IHJlY2VpdmVkLCBvciBhbm90aGVyIGV2ZW50IHRoYXQgaW5kaWNhdGVzIHRoZSBuZXR3b3JrIHBh
dGggbm8gbG9uZ2VyDQoNCiAgIHN1c3RhaW5zIHRoaXMgcGFja2V0IHNpemUsIHN1Y2ggYXMgYSBs
b3NzIHJlcG9ydCBmcm9tIHRoZSBQTA0KDQoNCg0KICAgQWxsIGltcGxlbWVudGF0aW9ucyBvZiBE
UExQTVRVRCBhcmUgUkVRVUlSRUQgdG8gcHJvdmlkZSBzdXBwb3J0IHRoYXQNCg0KICAgcmVkdWNl
cyB0aGUgUExQTVRVIHdoZW4gdGhlIGFjdHVhbCBQTVRVIHN1cHBvcnRlZCBieSBhIG5ldHdvcmsg
cGF0aA0KDQogICBpcyBsZXNzIHRoYW4gdGhlIFBMUE1UVS4NCg0KU2VjdGlvbiA0Ljkgc2F5czoN
Cg0KICAgUFJPQkVfRE9ORTogVGhlIFBST0JFX0RPTkUgc3RhdGUgaW5kaWNhdGVzIGEgc3VjY2Vz
c2Z1bCBlbmQgdG8gYQ0KDQogICAgICBwcm9iaW5nIHBoYXNlLiAgRFBMUE1UVUQgcmVtYWlucyBp
biB0aGlzIHN0YXRlIHVudGlsIGVpdGhlciB0aGUNCg0KICAgICAgUE1UVV9SQUlTRV9USU1FUiBl
eHBpcmVzIG9yIGEgcmVjZWl2ZWQgUFRCIG1lc3NhZ2UgaXMgdmVyaWZpZWQuDQoNCkhvd2V2ZXIs
IEkgaGF2ZSB0byBzYXkgdGhhdCB0aGUgZHJhZnQgaXMgYSBiaXQgdW5jbGVhciBvbiB3aGF0IHRv
IGRvIGF0IHRoaXMgcG9pbnQuDQoNCkkgZ3Vlc3MgdGhlIG9wdGlvbnMgYXJlIHR3by4NCg0KUHJv
YmUgc3RhcnRpbmcgYXQgUFRCX1NJWkUgb3IgdmVyaWZ5IEJhc2VfTVRVIGFuZCB0aGVuIHByb2Jl
IHVwLiBGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgaW1wb3J0YW50IGlzIHRoYXQgb25lIHVzZXMg
dGhpcyBhIHNpZ25hbCBmb3IgY2hlY2tpbmcgdGhlIFBNVFUuDQoNCkkgd2lsbCBzdGFydCBhIHRo
cmVhZCBvbiBUU1ZXRyBXRyBtYWlsaW5nIGxpc3QgcmVnYXJkaW5nIHRoZSBsYWNrIG9mIHNwZWNp
ZmljIHRleHQgaW4gdGhlaXIgZHJhZnQgZm9yIHRoaXMgY2FzZS4NCg0KQ2hlZXJzDQoNCg0KDQoN
Ck1hZ251cyBXZXN0ZXJsdW5kDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5ldHdvcmsgQXJjaGl0
ZWN0dXJlICYgUHJvdG9jb2xzLCBFcmljc3NvbiBSZXNlYXJjaA0KDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN
CkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KDQpU
b3JzaGFtbnNnYXRhbiAyMyAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCg0KU0Ut
MTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmlj
c3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0K

--_000_643f80954e6a45ba881c7d4a90a066d0ustx2exdag1mb5msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov
DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz
dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0
Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow
aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi
bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z
by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn
aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0
OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0
eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv
bnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4ubWgNCgl7bXNvLXN0eWxlLW5hbWU6bV9oO30N
CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQyMDg4
MTYxMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEz
NDIyOTU3MjAgMTE2NTc2MDIzNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2
NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7
bXNvLWxldmVsLXN0YXJ0LWF0OjE2Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t
YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg
bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt
ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0NzE5NDMxMzk7DQoJ
bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4ODk1NTMzMzYg
Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2
OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwz
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl
bnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N
CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA
bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl
bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNv
LWxpc3QtaWQ6Nzg2OTcxNzg2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl
bXBsYXRlLWlkczotMTc2OTgyNjM1NiAxNjQyODU2NTQyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4
Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0
IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp
ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs
MjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy
OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyI7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu
LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp
Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0
Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv
eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO
LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i
TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bWFyZ2luLWxlZnQ6MGlu
O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UHJv
YmUgc3RhcnRpbmcgYXQgUFRCX1NJWkUgb3IgdmVyaWZ5IEJhc2VfTVRVIGFuZCB0aGVuIHByb2Jl
IHVwLiBGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgaW1wb3J0YW50IGlzIHRoYXQgb25lIHVzZXMg
dGhpcyBhIHNpZ25hbCBmb3IgY2hlY2tpbmcgdGhlIFBNVFUuDQo8YnI+DQo8YnI+DQo8L3NwYW4+
PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+RnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlcmUgYXJlIHR3byB0aGlu
Z3MgdGhhdCBhcmUgaW1wb3J0YW50IGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0
eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29M
aXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNv
LWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KVXNlIFBUQiBzaWduYWwgdG8gc3RhcnQgcHJvYmluZyAo
YXMgeW91IHNhaWQpLiZuYnNwOyBUaGlzIGlzIHNlY3Rpb24gMy4zLjxvOnA+PC9vOnA+PC9saT48
bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21hcmdp
bi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpJZGVudGlmeSBjYXNlcywgd2hl
biB5b3UgY2FuIHNldCBQTVRVIHRvIFBUQl9TSVpFIGltbWVkaWF0ZWx5IHVwb24gcmVjZWlwdCBv
ZiBQVEIsIHdoaWxlIHRoZSBwcm9iaW5nIGlzIGhhcHBlbmluZy48bzpwPjwvbzpwPjwvbGk+PC9v
bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6d2luZG93dGV4dCI+UGx1cyBvbmUgbW9yZSB0aGluZyB0aGF0IGlzIG5vdCBp
biB0aGF0IGRyYWZ0IGF0IGFsbCDigJMgSSB0aGluayBpdCBpcyBwcnVkZW50IHRvIHJlc3BlY3Qg
UFRCLCBldmVuIGlmIHRoYXQgUFRCIGlzIG5vdCB2YWxpZGF0ZWQgKGkuZS4gdy9vIG9uLXBhdGgg
cHJvb2YsIHVzaW5nIG15IGxpbmdvKSwgaWYgUFRCX1NJWkUgaXMgbGFyZ2UgZW5vdWdoICh0byBi
ZSBkZWZpbmVkDQogaG93IGxhcmdlKS4mbmJzcDsgSXQgcHJvYmFibHkgZGVzZXJ2ZXMgaXRzIG93
biB0aHJlYWQgaW4gdHN2d2cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs
YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVm
dDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KSWdvcjxvOnA+PC9vOnA+PC9saT48L3Vs
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dCI+IE1hZ251cyBXZXN0ZXJsdW5kIFttYWlsdG86bWFnbnVzLndlc3Rl
cmx1bmRAZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAwMiwg
MjAxOCA0OjQ2IEFNPGJyPg0KPGI+VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVA
YWthbWFpLmNvbSZndDs7IEVnZ2VydCwgTGFycyAmbHQ7bGFyc0BuZXRhcHAuY29tJmd0Ozxicj4N
CjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluIER1
a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTogVHJlYXRtZW50IG9mIElDTVAgZm9yIFBNVFU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cD5IaSwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZW4gMjAxOC0wNi0yOSBrbC4g
MDI6MzAsIHNrcmV2IEx1YmFzaGV2LCBJZ29yOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiDigKIgV2hhdCB0byBkbywgd2hl
biBhbiBJUHY0IElDTVAgKHcvbyBvbi1wYXRoIHByb29mKSByZXF1ZXN0IGEgUE1UVSByZWR1Y3Rp
b24gKGFmdGVyIGhhbmRzaGFrZSk/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SXNuJ3QgdGhpcyBzdWZmaWNpZW50bHkg
Y292ZXJlZCBpbiA0ODIxPzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5vdCByZWFsbHkuJm5ic3A7IE9yLCBhdCBsZWFz
dCBJIGNvdWxkIG5vdCBmaW5kIGFueXRoaW5nIG1vcmUgdXNlZnVsIHRoZXJlIHRoZW46ICZxdW90
O0lmIGFuIElDTVAgUFRCIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgbWF0Y2hpbmcgdGhlIHByb2JlIHBh
Y2tldCwgdGhlbiBzZWFyY2hfaGlnaCBhbmQgZWZmX3BtdHUgTUFZIGJlIHNldCBmcm9tIHRoZSBN
VFUgdmFsdWUgaW5kaWNhdGVkIGluIHRoZSBtZXNzYWdlLiZxdW90OyZuYnNwOyBTbyA0ODIxIHNl
ZW1zIHNpbGVudCBvbiB3aGF0IHRvIGRvIGlmIElDTVAgaXMgcmVjZWl2ZWQgZm9yIGEgbm9uLXBy
b2JlIHBhY2tldCwgYW5kIGl0IHNlZW1zIHNpbGVudCBvbiBob3cgb25lIGNvdWxkIGRlY2lkZSB3
aGV0aGVyIHRvIHNldCBzZWFyY2hfaGlnaCBhbmQgZWZmX3BtdHUgZnJvbSB0aGUgTVRVIGluIElD
TVAgb3Igbm90IChzYXlpbmcgJnF1b3Q7TUFZJnF1b3Q7IGRvZXMgbm90IHJlYWxseSBoZWxwIGhl
cmUpLiZuYnNwOyBUaGVzZSBxdWVzdGlvbnMgYXJlIHdoYXQgSSBhbSB0cnlpbmcgdG8gYWRkcmVz
cyBmb3IgUVVJQy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT40ODIxIHVzZXMgTUFZIGluIHRoZSBzZW50ZW5jZSBhYm92ZSwgc2luY2UgaXQgZG9l
cyBub3QgcmVhbGx5IGdpdmUgYW55IGJldHRlciBpbmRpY2F0aW9uLiZuYnNwOyBUaGlzIFBSIGRy
YXdzIGEgZGlzdGluY3Rpb24gYmV0d2VlbiBJQ01QIHcvIGFuZCB3L28gb24tcGF0aCBwcm9vZiBh
bmQgaW4gc29tZSBzcGVjaWZpYyBjYXNlcywgaXQgcmVjb21tZW5kcyBhIFNIT1VMRC48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JZiB5b3UgbG9vayBhdCB0aGUgdXBkYXRlZCBQTFBNVFVE
Ojxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0y
RHRzdndnLTJEZGF0YWdyYW0tMkRwbHBtdHVkXyZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FN
RjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201
NUtQbWxvJmFtcDttPXVER0k5amlTN0dlZzNkYnY3LTZYMTNpV2ZVSUNLeTNmT2lla0pZYU9fSEEm
YW1wO3M9TVFSaFduc0xUZ08zc1JYTS1Fbk12WVRSb1g5SHViVHlzU2ZUX0ZQaWNKayZhbXA7ZT0i
Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctZGF0YWdy
YW0tcGxwbXR1ZC88L2E+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIGNsYXNzPSJtaCI+My4z
LiZuYnNwOyBSZWR1Y2luZyB0aGUgUExQTVRVOiBDb25maXJtaW5nIFBhdGggQ2hhcmFjdGVyaXN0
aWNzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyBJZiB0aGUgRFBMUE1UVUQgbWV0aG9kIGRldGVjdHMgdGhhdCBh
IHBhY2tldCB3aXRoIHRoZSBQTFBNVFUgc2l6ZSBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyBubyBzdXBwb3J0ZWQgYnkgdGhlIG5ldHdvcmsgcGF0aCwgdGhlbiB0aGUgRExQ
TVRVRCBtZXRob2QgbmVlZHMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
dmFsaWRhdGUgdGhlIFBMUE1UVS4gVGhpcyBjYW4gaGFwcGVuIHdoZW4gYSB2YWxpZGF0ZWQgUFRC
IG1lc3NhZ2UgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcmVjZWl2ZWQs
IG9yIGFub3RoZXIgZXZlbnQgdGhhdCBpbmRpY2F0ZXMgdGhlIG5ldHdvcmsgcGF0aCBubyBsb25n
ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3VzdGFpbnMgdGhpcyBwYWNr
ZXQgc2l6ZSwgc3VjaCBhcyBhIGxvc3MgcmVwb3J0IGZyb20gdGhlIFBMPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFsbCBp
bXBsZW1lbnRhdGlvbnMgb2YgRFBMUE1UVUQgYXJlIFJFUVVJUkVEIHRvIHByb3ZpZGUgc3VwcG9y
dCB0aGF0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHJlZHVjZXMgdGhlIFBM
UE1UVSB3aGVuIHRoZSBhY3R1YWwgUE1UVSBzdXBwb3J0ZWQgYnkgYSBuZXR3b3JrIHBhdGg8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXMgbGVzcyB0aGFuIHRoZSBQTFBNVFUu
PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClNlY3Rpb24gNC45
IHNheXM6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBQUk9CRV9ET05FOiBUaGUg
UFJPQkVfRE9ORSBzdGF0ZSBpbmRpY2F0ZXMgYSBzdWNjZXNzZnVsIGVuZCB0byBhPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb2JpbmcgcGhh
c2UuJm5ic3A7IERQTFBNVFVEIHJlbWFpbnMgaW4gdGhpcyBzdGF0ZSB1bnRpbCBlaXRoZXIgdGhl
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBN
VFVfUkFJU0VfVElNRVIgZXhwaXJlcyBvciBhIHJlY2VpdmVkIFBUQiBtZXNzYWdlIGlzIHZlcmlm
aWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpIb3dldmVy
LCBJIGhhdmUgdG8gc2F5IHRoYXQgdGhlIGRyYWZ0IGlzIGEgYml0IHVuY2xlYXIgb24gd2hhdCB0
byBkbyBhdCB0aGlzIHBvaW50Lg0KPGJyPg0KPGJyPg0KSSBndWVzcyB0aGUgb3B0aW9ucyBhcmUg
dHdvLjxicj4NCjxicj4NClByb2JlIHN0YXJ0aW5nIGF0IFBUQl9TSVpFIG9yIHZlcmlmeSBCYXNl
X01UVSBhbmQgdGhlbiBwcm9iZSB1cC4gRnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlIGltcG9ydGFu
dCBpcyB0aGF0IG9uZSB1c2VzIHRoaXMgYSBzaWduYWwgZm9yIGNoZWNraW5nIHRoZSBQTVRVLg0K
PGJyPg0KPGJyPg0KSSB3aWxsIHN0YXJ0IGEgdGhyZWFkIG9uIFRTVldHIFdHIG1haWxpbmcgbGlz
dCByZWdhcmRpbmcgdGhlIGxhY2sgb2Ygc3BlY2lmaWMgdGV4dCBpbiB0aGVpciBkcmFmdCBmb3Ig
dGhpcyBjYXNlLjxicj4NCjxicj4NCkNoZWVyczxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5NYWdudXMgV2VzdGVybHVuZCA8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+TmV0d29yayBBcmNoaXRlY3R1cmUgJmFtcDsg
UHJvdG9jb2xzLCBFcmljc3NvbiBSZXNlYXJjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Fcmljc3NvbiBBQiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFBob25lJm5ic3A7ICYjNDM7NDYgMTAgNzE0ODI4
NzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvcnNoYW1uc2dhdGFuIDIzJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTW9iaWxlICYj
NDM7NDYgNzMgMDk0OTA3OTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNFLTE2NCA4MCBTdG9ja2hv
bG0sIFN3ZWRlbiB8IG1haWx0bzogPGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVy
aWNzc29uLmNvbSI+bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9hPjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_643f80954e6a45ba881c7d4a90a066d0ustx2exdag1mb5msgcorpak_--


From nobody Tue Jul  3 02:08:52 2018
Return-Path: 
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 9E361130FBA for ; Tue,  3 Jul 2018 02:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 k3Iw0yNj71g6 for ; Tue,  3 Jul 2018 02:08:47 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C448C130E40 for ; Tue,  3 Jul 2018 02:08:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1530608925; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rtOoSkg5mpe9X/qAoU8+13F4Y8+OBvimKv3zFU+pRMI=; b=TL3OxbiEmmQjqfjnuicbMOYUBkHw+GJ7fSj4mW4wHo8nBkmXF3v4iQ3jeiNE3gqX uNV1pHNd94j55SCoYMx2VXemeAsRtZvntl2tJTr9r+L0jx8bDNqpaKg4zRzpd5UL n0sJjyir4NoBAzWZSBBmCoo/4KZORkX3N8L4Ah+mYhA=;
X-AuditID: c1b4fb2d-223ff700000055ff-8e-5b3b3d1dbb14
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C9.A9.22015.D1D3B3B5; Tue,  3 Jul 2018 11:08:45 +0200 (CEST)
Received: from [147.214.163.236] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 3 Jul 2018 11:08:44 +0200
Subject: Re: Treatment of ICMP for PMTU
To: "Lubashev, Igor" , "Eggert, Lars" 
CC: IETF QUIC WG , Martin Duke 
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com> <643f80954e6a45ba881c7d4a90a066d0@ustx2ex-dag1mb5.msg.corp.akamai.com>
From: Magnus Westerlund 
Message-ID: <3c9a5b82-4c95-10b2-1ce2-9b2a9fe72876@ericsson.com>
Date: Tue, 3 Jul 2018 11:08:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <643f80954e6a45ba881c7d4a90a066d0@ustx2ex-dag1mb5.msg.corp.akamai.com>
Content-Type: multipart/alternative; boundary="------------811F199CCB1F864E9211E04B"
Content-Language: en-GB
X-Originating-IP: [153.88.183.153]
X-ClientProxiedBy: ESESBMB505.ericsson.se (153.88.183.172) To ESESSMB502.ericsson.se (153.88.183.163)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2J7ha6srXW0wek+doumhhXMFi9e97BY TH/8gs2iZwG3A4vH5CMLmD12zrrL7rFkyU8mjxmfvrAFsERx2aSk5mSWpRbp2yVwZey7vJi1 oDe/4sRnhQbGy9FdjJwcEgImEvPbVzN2MXJxCAkcZZR4+fouG4TzgVHize8D7CBVwgLqEr8v TQCzRQR8JO49XMsCYjMLuEuc6mllhWg4xyTRN72ZESTBJmAhcfNHIxuIzStgL7Fq0UtmEJtF QEVi8ZOjYLaoQIzE6o2X2SFqBCVOznwCNpRTIFhi7+5nUAvCJNa+fMIMYYtLNH1ZyQpiCwlo SzQ0dbBCvKAkcX3edRYIO13i7pFu1gmMQrOQjJ2FZNQsJKMgbAuJmfPPM0LY8hLNW2dD1WhI tM6Zy44svoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYDwd3PJbdwfj6teOhxgFOBiV eHj/2FhHC7EmlhVX5h5ilOBgVhLh3aZqFS3Em5JYWZValB9fVJqTWnyIUZqDRUmcV2/Vnigh gfTEktTs1NSC1CKYLBMHp1QDY62sxt4N+tUZTy8Uv3jql23ZL3DyIFfN0RfcEqsi05yK1xTr ze5t4lsVasR6MOm7gt/kX782VEo3lLVLvD4590WvCnf/g5L1K11a+0MZT2po/Vv5woV9WkwZ m4TkOUbPepcTlyb4ntjeWKQws77yx582BQmBlXz7lfTELpw7+OrtC9nAC4deKrEUZyQaajEX FScCAJ6PsMWjAgAA
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 09:08:50 -0000

--------------811F199CCB1F864E9211E04B
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit



Den 2018-07-03 kl. 01:19, skrev Lubashev, Igor:
>
>   * Probe starting at PTB_SIZE or verify Base_MTU and then probe up.
>     From my perspective, the important is that one uses this a signal
>     for checking the PMTU.
>
> From my perspective, there are two things that are important here:
>
>  1. Use PTB signal to start probing (as you said).  This is section 3.3.
>  2. Identify cases, when you can set PMTU to PTB_SIZE immediately upon
>     receipt of PTB, while the probing is happening.
>
Yes, that should definitely be detailed. For a validated message, I 
think there are good reasons to adjust PLPMTU to PTB_SIZE when it is 
less than PLPMTU and >= BASE_MTU. As this can prevent driving at least 
one additional RTT of data likely into a MTU blackhole. However, there 
are clearly corner cases, for example with inconsistent MTUs. But the 
goal there is to find the lower of the multiple thresholds.

> Plus one more thing that is not in that draft at all – I think it is 
> prudent to respect PTB, even if that PTB is not validated (i.e. w/o 
> on-path proof, using my lingo), if PTB_SIZE is large enough (to be 
> defined how large).  It probably deserves its own thread in tsvwg.
>

Definitely a TSVWG thread I think, please start a thread. I see 
significant issue with using unvalidated PTBs. First of all one need to 
be able to be certain that it is actually related to ones flow at all. 
Secondly, if it doesn't contain any information that one can identify it 
as an actually sent packet then one are open to off-path attackers. That 
is a real issue. I think at most one can initiate a probe based on flow 
related but not fully validated PTB messages.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------811F199CCB1F864E9211E04B
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
Den 2018-07-03 kl. 01:19, skrev
      Lubashev, Igor:

    

    

      
      
      
      

        
    
          
  • 
            Probe starting at PTB_SIZE or
              verify Base_MTU and then probe up. From my perspective,
              the important is that one uses this a signal for checking
              the PMTU.
              
    
              
    
            
    • 
        

        
From my
            perspective, there are two things that are important here:

        
    
          
  1. 
            Use PTB signal to start probing (as you said).  This is
            section 3.3.
    2. 
          
  2. 
            Identify cases, when you can set PMTU to PTB_SIZE
            immediately upon receipt of PTB, while the probing is
            happening.
    3. 
        

        
 

      

    

    Yes, that should definitely be detailed. For a validated message, I
    think there are good reasons to adjust PLPMTU to PTB_SIZE when it is
    less than PLPMTU and >= BASE_MTU. As this can prevent driving at
    least one additional RTT of data likely into a MTU blackhole.
    However, there are clearly corner cases, for example with
    inconsistent MTUs. But the goal there is to find the lower of the
    multiple thresholds. 

    

    

      

        
Plus one
            more thing that is not in that draft at all – I think it is
            prudent to respect PTB, even if that PTB is not validated
            (i.e. w/o on-path proof, using my lingo), if PTB_SIZE is
            large enough (to be defined how large).  It probably
            deserves its own thread in tsvwg.

      

    

    

    Definitely a TSVWG thread I think, please start a thread. I see
    significant issue with using unvalidated PTBs. First of all one need
    to be able to be certain that it is actually related to ones flow at
    all. Secondly, if it doesn't contain any information that one can
    identify it as an actually sent packet then one are open to off-path
    attackers. That is a real issue. I think at most one can initiate a
    probe based on flow related but not fully validated PTB messages.

    

    Cheers

    

    Magnus Westerlund
    
----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

  


--------------811F199CCB1F864E9211E04B--


From nobody Tue Jul  3 05:45:20 2018
Return-Path: 
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 99320130EB5 for ; Tue,  3 Jul 2018 05:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 F8IprRTrdJ1U for ; Tue,  3 Jul 2018 05:45:16 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 7AAE4130EAB for ; Tue,  3 Jul 2018 05:45:16 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id q4-v6so1585317iob.2 for ; Tue, 03 Jul 2018 05:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=zqRR0qqF3BakBHybFfZoVj4DpdCSFclsfrxkaRlOoPk=; b=nsqCDLBI6PgHSCq+XZ9tBmKBRDA0Brpj95JFWTAdSjEasIrapF/I10/46MQKAIrznH 5we8SUPRPUhUGF/ZbjPwkowbgpXNPKn6/kZkODJB1PcKGwK6ByPuiZn70MvKcL13SmKA CetAdF/LldKzTP2Mc4hgMgZzA9bNJyBL4u9r8tPkMLPiUO9BUscUdzYlw1eFsP5YcG2g 9ejC1nXatCn3dAonCFGpvyR1Xewh7AVLEPwndhwAx5zzM8UHF+YlK99WOO5wusb7J0Fx FHHMUU2dXfR5juRKF+mexmxiz/7PJrWS3BDNmUVwMLabL/ORI0hsnA9jH82kp7hV3NqH vnnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zqRR0qqF3BakBHybFfZoVj4DpdCSFclsfrxkaRlOoPk=; b=JSCtABjTgSWFPm0uxe8KDt8tbBpDkoIuDskqZF8af3pET/MVVtn7HDBWPVLt0Cundh Eq4xv4echb2YzNb96Jp/4/qG3RzrBrk3HUuUwjTpaGf0kfHmqloFBn8zqVVa17vzzmbv J0yqeqrwrd8iBh7B4gQJHqUP/BuUC12PGTOz1is2G4olGFlBI8z+wOXAlWGiAi+6m+8N B9IYRy3K/FUFSlPL0yJL9Iu45v47TDSVT8KGAeGTjES0+hoIHAP/s2lK+nmlIxchIkrP ToJrHcZHVEHIdYdQgwqmiclw+CHPHDja0RP9uoffbjuOvcTRmQGEaBUPWSSJEfnjOvKb K3Cg==
X-Gm-Message-State: APt69E0Ji3dCbi1bAMCdmwFOUfvq7YaGOmnVI2eFoPIl5VSU5tejGShl W5ArhHylk1SxmCEWw/A/efYdCNHmCzD7Y2uBbqwyaw==
X-Google-Smtp-Source: AAOMgpfD+LfGVd28yTwc81xqNxBlN2rwBcZd8XumWMoWLDBMS+Vn66ZvNrlQAfzNlBKrFdVWtaiakFlry1rIFFvibjI=
X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr23080810ioh.235.1530621915136;  Tue, 03 Jul 2018 05:45:15 -0700 (PDT)
MIME-Version: 1.0
From: Marten Seemann 
Date: Tue, 3 Jul 2018 19:45:03 +0700
Message-ID: 
Subject: Connection ID lengths 1, 2 and 3
To: QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000898682057017af8b"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 12:45:19 -0000

--000000000000898682057017af8b
Content-Type: text/plain; charset="UTF-8"

First of all, I realise that I'm bringing this up late in the process, and
maybe too late, since this would require a change to the invariants.

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes
(inclusive). Lengths of 1, 2 and 3 bytes are not possible.
For p2p applications, and for server deployments that are not doing
connection ID based load balancing, it would be interesting to use shorter
connection IDs. One might imagine that a peer encodes the length of the
connection ID into the first few bits, and then starts using 1 byte
connection IDs first, and successively moves to longer lengths only when
handling more connections. A p2p host handling several thousand
simultaneous connections (which will be enough for many p2p protocols)
would never have to use anything longer than 2 byte connection IDs.

In the connection ID length field in the Long Header, we only have to 4 bit
to encode a range of 19 values (we want 0 byte connection IDs, and we want
to support 18 byte connection IDs), so *some* values have to be left out.
However, leaving out 1, 2 and 3 seems a bit unfortunate, as there will be
more use cases for these values than e.g. for 13, 14 and 15 bytes.

--000000000000898682057017af8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


First of all, I realise that I'm bringing this up=
 late in the process, and maybe too late, since this would require a change=
 to the invariants.

The connection IDs can be eith=
er 0 bytes or anything between 4 and 18 bytes (inclusive). Lengths of 1, 2 =
and 3 bytes are not possible.
For p2p applications, and for serve=
r deployments that are not doing connection ID based load balancing, it wou=
ld be interesting to use shorter connection IDs. One might imagine that a p=
eer encodes the length of the connection ID into the first few bits, and th=
en starts using 1 byte connection IDs first, and successively moves to long=
er lengths only when handling more connections. A p2p host handling several=
 thousand simultaneous connections (which will be enough for many p2p proto=
cols) would never have to use anything longer than 2 byte connection IDs.

In the connection ID length field in the Long Heade=
r, we only have to 4 bit to encode a range of 19 values (we want 0 byte con=
nection IDs, and we want to support 18 byte connection IDs), so *some* valu=
es have to be left out. However, leaving out 1, 2 and 3 seems a bit unfortu=
nate, as there will be more use cases for these values than e.g. for 13, 14=
 and 15 bytes.


--000000000000898682057017af8b--


From nobody Tue Jul  3 06:06:27 2018
Return-Path: 
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 78669130E0A for ; Tue,  3 Jul 2018 06:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 GXvroOVvnkTC for ; Tue,  3 Jul 2018 06:06:24 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 80BFF130DF7 for ; Tue,  3 Jul 2018 06:06:24 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id v26-v6so1638516iog.5 for ; Tue, 03 Jul 2018 06:06:24 -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;  bh=aPe1JXgKrIFq7DhafJ9bBYa4fK7N6EMpf9Odzr/r4gM=; b=lLANlRYACr4eU+TU8LMY99MZIG0t83yK3iiuK907rfzMcifkGIQkh+MhdAtc4kUMnb rTWm0DGVwp4ZfxWU9doIWPsM3W3EigVgNUw07/b4UV88Ct+G94xYGnCavNd+gqmSbKt7 t/45dgiXGUc4KP9Rf8J37NZiWmTnMqjU3NYk/zB/8ogWSGRsksieSqLJfJ0fMoeHF6Cj BUqxEO01befFlsJQl5zUO3+H4mPEPDSQv/HVM34ep1khAapXDRwYiJm13oddfWp1S0Qe 6C/qW85Q0XyjMyLyWqGv/YEeDgkWJRgcPDuo8n35PrPSetys30Z3lUkcJFes0QPP7qPJ 2FCw==
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; bh=aPe1JXgKrIFq7DhafJ9bBYa4fK7N6EMpf9Odzr/r4gM=; b=DCnsPt6tfNiWw/HuRVDBRHGoaqbUmYViS7iy5HxLMUWytkbIMPnZMlKTAE8Xy61u4s ljJarLqvi5rAV0aTDjJMJvQMtaoyhgFr0LJStdr+KLsmACJxSmDLsbSfc7OmRh0TF/W5 uIZwC9LzvszOcRUSoTQ43q5CuqLbwM5qVXK1bMidVJsEhfEPDzJFIK3SQ/UC6AcHI07w 8VOmbU0LgvsLxw5wR9AcJh5TY/Ki2uk5S2VzxqRtf+r7b6D3a1NxU65XM7Qjo3iu5Sz3 uBuTRuh2tWTj6ITEUGeAIWb9efbx+0BawGwCaPLjsarKMEp5leW0kox0jOIjP/RX1pK7 H3Xw==
X-Gm-Message-State: APt69E06fAiyzgvPMp4Fv5wHssr+UJwZaxpPMEW3qW9dLCRQ4Vm1H8XV wGpDNAaPd46Ys/cr4HgZZx2MFTmpTWwIrKx2z1GnTw==
X-Google-Smtp-Source: AAOMgpfygx5CSWnHb9I3CRoYFkODl31lLm8pkD6CAlba3FnS4bvKHp3giOz1Ol8gKs9G9L1QZHph5m1rWG5tAe9apCQ=
X-Received: by 2002:a6b:1e91:: with SMTP id e139-v6mr25365700ioe.36.1530623183756;  Tue, 03 Jul 2018 06:06:23 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 3 Jul 2018 09:06:22 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References: 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 3 Jul 2018 09:06:22 -0400
Message-ID: 
Subject: Re: Connection ID lengths 1, 2 and 3
To: QUIC WG , Marten Seemann 
Content-Type: multipart/alternative; boundary="000000000000272afc057017fb22"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 13:06:26 -0000

--000000000000272afc057017fb22
Content-Type: text/plain; charset="UTF-8"

That is correct. Especially in low-power sensor mesh networks.


On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) wrote:

First of all, I realise that I'm bringing this up late in the process, and
maybe too late, since this would require a change to the invariants.

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes
(inclusive). Lengths of 1, 2 and 3 bytes are not possible.
For p2p applications, and for server deployments that are not doing
connection ID based load balancing, it would be interesting to use shorter
connection IDs. One might imagine that a peer encodes the length of the
connection ID into the first few bits, and then starts using 1 byte
connection IDs first, and successively moves to longer lengths only when
handling more connections. A p2p host handling several thousand
simultaneous connections (which will be enough for many p2p protocols)
would never have to use anything longer than 2 byte connection IDs.

In the connection ID length field in the Long Header, we only have to 4 bit
to encode a range of 19 values (we want 0 byte connection IDs, and we want
to support 18 byte connection IDs), so *some* values have to be left out.
However, leaving out 1, 2 and 3 seems a bit unfortunate, as there will be
more use cases for these values than e.g. for 13, 14 and 15 bytes.

--000000000000272afc057017fb22
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
That is correct. Esp=
ecially in low-power sensor mesh networks.
 

 
On 3 July=
 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) wrote:
 









First of all, I realise that I'm bringing this up late in the
process, and maybe too late, since this would require a change to
the invariants.





The connection IDs can be either 0 bytes or anything between 4
and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not
possible.


For p2p applications, and for server deployments that are not
doing connection ID based load balancing, it would be interesting
to use shorter connection IDs. One might imagine that a peer
encodes the length of the connection ID into the first few bits,
and then starts using 1 byte connection IDs first, and successively
moves to longer lengths only when handling more connections. A p2p
host handling several thousand simultaneous connections (which will
be enough for many p2p protocols) would never have to use anything
longer than 2 byte connection IDs.





In the connection ID length field in the Long Header, we only
have to 4 bit to encode a range of 19 values (we want 0 byte
connection IDs, and we want to support 18 byte connection IDs), so
*some* values have to be left out. However, leaving out 1, 2 and 3
seems a bit unfortunate, as there will be more use cases for these
values than e.g. for 13, 14 and 15 bytes.








--000000000000272afc057017fb22--


From nobody Tue Jul  3 09:02:04 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C239B130F59; Tue,  3 Jul 2018 09:00:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com
Subject: quic - Requested session has been scheduled for IETF 102
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153063361379.4893.2098075254703479268.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jul 2018 09:00:13 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 16:00:21 -0000

Dear Lars Eggert,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    quic Session 1 (2:30 requested)
    Wednesday, 18 July 2018, Morning Session I 0930-1200
    Room Name: Place du Canada size: 300
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/102/sessions/quic.ics

Request Information:


---------------------------------------------------------
Working Group Name: QUIC
Area Name: Transport Area
Session Requester: Lars Eggert

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 200
Conflicts to Avoid: 
 First Priority: tsvarea tsvwg tcpm iccrg httpbis tls dispatch
 Second Priority: mptcp saag
 Third Priority: irtfopen maprg


People who must be present:
  Sean Turner
  Mark Nottingham
  Patrick R. McManus
  Jana Iyengar
  Martin Thomson
  Spencer Dawkins
  Brian Trammell
  Lars Eggert
  Mike Bishop
  Ian Swett
  Alan Frindell

Resources Requested:
  Experimental Room Setup (U-Shape and classroom, subject to availability)

Special Requests:
  Two consecutive days early in the week, if possible; 2 hour slot(s) fine too, if that makes it easier.
---------------------------------------------------------


From nobody Tue Jul  3 12:18:01 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B952A130DDE; Tue,  3 Jul 2018 12:17:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: quic@ietf.org
Subject: QUIC (quic) WG Interim Meeting: 2018-09-19
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153064547960.4965.17530030582624965326@ietfa.amsl.com>
Date: Tue, 03 Jul 2018 12:17:59 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 03 Jul 2018 19:18:00 -0000

The QUIC (quic) Working Group will hold
a multi-day interim meeting.

Session 1:
2018-09-19     09:30 to 02:30  US/Eastern
Session 2:
2018-09-20     09:30 to 02:30  US/Eastern

Meeting Location:
New York City, NY, US

Agenda:
https://github.com/quicwg/wg-materials/blob/master/interim-18-09/agenda.md

Information about remote participation:
Webex information will be emailed to registered remote participants

https://github.com/quicwg/wg-materials/blob/master/interim-18-09/arrangements.md


From nobody Fri Jul  6 00:03:35 2018
Return-Path: 
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 F06C6130E1A for ; Fri,  6 Jul 2018 00:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=netapp.onmicrosoft.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 6XQHuxxVNc-t for ; Fri,  6 Jul 2018 00:03:30 -0700 (PDT)
Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2396E130DE2 for ; Fri,  6 Jul 2018 00:03:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.51,315,1526367600";  d="asc'?scan'208,217";a="284801646"
Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx141-out.netapp.com with ESMTP; 06 Jul 2018 00:03:29 -0700
Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Jul 2018 00:03:29 -0700
Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 6 Jul 2018 00:03:29 -0700
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 6 Jul 2018 00:03:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=okbhnbJwdYxe/8Rag/MNktILmfvPjdQQpZ3tWFA0R9o=; b=jKXWKULFkKVGC3lXjHhHnoOkemNImzdnPMX91knf0/WysBNK1/pxqCePxUFMQ3psJT0SfE1QlPUNFae5GgExbm2nSJdYR4eklEoWSiqWU9CowNrzf/KAzmP+p66w20M4Ws47FwIQaxYLDUF2iWvJ/yHMhhEcBOenWDfDRcXqvd0=
Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB658.namprd06.prod.outlook.com (10.141.208.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Fri, 6 Jul 2018 07:03:25 +0000
Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::f983:bf6c:8b8f:c82c]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::f983:bf6c:8b8f:c82c%6]) with mapi id 15.20.0930.016; Fri, 6 Jul 2018 07:03:25 +0000
From: "Eggert, Lars" 
To: IETF QUIC WG 
Subject: Fwd: [irsg] IRTF Announcement: Starting up PEARG, to work on Privacy-Enhancing Technologies in IRTF
Thread-Topic: [irsg] IRTF Announcement: Starting up PEARG, to work on Privacy-Enhancing Technologies in IRTF
Thread-Index: AQHUFJNAvDEP5WisqkW1LxOnajlqTQ==
Date: Fri, 6 Jul 2018 07:03:25 +0000
Message-ID: <730E056B-7A30-4940-9EA5-E0B4AB718A66@netapp.com>
References: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.8.2)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; 
x-originating-ip: [217.70.211.15]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR06MB658; 7:ZuTrh6A68Kl8ysbdlSZY9mKg6UKN/IpEtbZchcirfmJWR6ILtKHY0V2/TWKY3PrJisDDSHBN8JF8wxAr1bs7RcRhXvMsLFD2E1LVKYsVAs0uqKzpogm5Bu8bcFboKFOs4E/TcZus1jMZ6bURUp4fF6N2gPq+d5OC3yciGdrlfgzZaj+Z8irnTVSWegrDjPxk1Qr0ol9Z28uC6EN8Yp63w+G7HS2fcZ6MyL3dVdVegCM7ogHKAtKWUisMfOfvs1Y7
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c1647782-b2da-4966-da97-08d5e30e91d7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(2017052603328)(49563074)(7193020); SRVR:BLUPR06MB658; 
x-ms-traffictypediagnostic: BLUPR06MB658:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(192374486261705)(131327999870524)(85827821059158)(206333022235701)(211171220733660)(231250463719595);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BLUPR06MB658; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB658; 
x-forefront-prvs: 0725D9E8D0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(136003)(396003)(376002)(22974007)(189003)(199004)(5250100002)(99286004)(446003)(966005)(478600001)(316002)(486006)(476003)(14454004)(2616005)(105586002)(106356001)(86362001)(14444005)(36756003)(256004)(33656002)(82746002)(97736004)(6486002)(99936001)(6916009)(50226002)(53936002)(2906002)(68736007)(25786009)(57306001)(7736002)(83716003)(81156014)(8676002)(81166006)(8936002)(186003)(26005)(5660300001)(606006)(66066001)(6506007)(53546011)(102836004)(76176011)(229853002)(6436002)(6116002)(3846002)(6512007)(2473003)(54896002)(6306002)(236005)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB658; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 56Zei9XntJdaKiAIoe9Okwo0YvlgyG04+XHmQndyRLdACJUk0rvaYDNjf9tD2vaSu9GIN7e2sMhZPW/bktklgW+eSxshscP7RvkVyASbbp4QQ6R0piEHDbBEdhKqCWPQXr9V3clq9e+aLqi84DNXJA3YODrj/BQTXgJaj0RiYUJ5tZ4OqnFgOqta1/v4D3iqen6YUj0BHmC34kVDztWUPLhV3BYZhUYU2NEVbu6NVfoDCuoeT/1uKPGNMQ6dJ7CtAh5OWEpxgl16HUlZ947FnmnGDWBtnfyjvacn0rCc7lyzjeLMG2Nrs/+4givNORTPdNpDHeBrnlhcwWR0o7CaNRvtcg0/t14n69JfEkJ8Bks=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_9D059701-271C-461E-8F1F-ACA8A8BA10CD"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c1647782-b2da-4966-da97-08d5e30e91d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2018 07:03:25.7862 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB658
X-OriginatorOrg: netapp.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 07:03:33 -0000

--Apple-Mail=_9D059701-271C-461E-8F1F-ACA8A8BA10CD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8643BB6B-F86D-4DA6-8FA4-26E1E9E36932"


--Apple-Mail=_8643BB6B-F86D-4DA6-8FA4-26E1E9E36932
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Note the inclusion of some QUIC-related items on the list below.

Lars

> Begin forwarded message:
>=20
> From: Allison Mankin 
> Subject: [irsg] IRTF Announcement: Starting up PEARG, to work on =
Privacy-Enhancing Technologies in IRTF
> Date: July 5, 2018 at 21:05:52 GMT+2
> To: irtf-announce@irtf.org, "Internet Research Steering Group =
(irsg@irtf.org)" , IRTF Discussion =

>=20
> Dear IRTF folks,
>=20
> Please see the note below.  A side meeting will take place to get =
feedback and move towards organizing PEARG (Privacy Enhancements and =
Assessment (Proposed) RG.  Please join the pearg mailing list if you are =
interested in participating.  Meeting info will also be sent on lists =
addressed here.  You may receive this multiple times,  so thanks for =
your patience!
>=20
> To subscribe:  https://www.irtf.org/mailman/listinfo/pearg =

>=20
> See you in Montreal!
>=20
> Allison
> IRTF Chair
>=20
>=20
> ---------- Forwarded message ----------
> From: Sara Dickinson >
> Date: 5 July 2018 at 12:51
> Subject: [Pearg] Welcome to the Privacy Enhancements and Assessment =
Proposed RG mailing list!
> To: pearg@irtf.org 
>=20
>=20
> Dear All,
>=20
> We would like to announce the first meeting (a side meeting) of the =
Privacy Enhancements and Assessment (PEA) Proposed RG to be held at IETF =
102 in Montreal. We are waiting confirmation of our time slot, we have =
requested 18:40 on Tuesday 17th July and will post to this list as soon =
as we have more details.
>=20
> The chairs for this Proposed RG are:
> Sara Dickinson (sara@sinodun.com ) and
> Shivan Sahib (ssahib@salesforce.com )
>=20
> This side meeting is planned as an informal discussion for parties =
interested in participating in the Proposed RG. There will be an =
overview of the proposed charter (see below) and we would like to =
solicit feedback on the charter and also possible future work in the =
group.
>=20
> As food for thought we believe that there are several ongoing =
privacy-relevant efforts and discussions in various IETF and IRTF groups =
that would benefit from a dedicated group for analysis, including:
>=20
> - [QUIC] Privacy leaks via passive network management via the proposed =
QUIC spin bit.
> - [QUIC] Connection migration and multipath privacy properties of =
exposed packet header information.
> - [DoH] Privacy implications for various use cases and for server =
operators.
> - [DRUI (BoF)] Privacy implications of DNS resolver discovery =
mechanisms.
> - [DNSSD] Private service discovery threat model formulation and =
solution analysis.
> - [DPRIVE] BCP for operators of DNS privacy services. Padding profile =
analysis.
> - [ICNRG] Privacy implications of unencrypted content requests =
(interests).
> - [TRANS] Privacy implications of certificate transparency gossiping.
> - [RTCWEB] Privacy issues around exposing private IP addresses in =
WebRTC
>=20
> Equally important, there is active research being conducted in the =
academic and open source communities around privacy preserving =
techniques that the IETF and IRTF could benefit from adopting.
>=20
> We=E2=80=99ll also discuss scheduling future meetings, including =
possible co-location with events other than the IETF.
>=20
> Best regards
>=20
> Sara & Shivan
>=20
>=20
>=20
>=20
> # Draft Charter
>=20
> ## Background
>=20
> Privacy is an increasingly desirable and often necessary property for =
Internet technologies. Evidence suggests that attacks on societal, =
community, and individual privacy occur with non-negligible frequency, =
as discussed in detail in RFC 7258 and in protocol-specific documents =
such as RFC 7626. Pervasive monitoring [RFC 7258], is a well known =
attack on privacy at incredible scale.  The IETF and IAB responses to =
such attacks is to push for widespread end-to-end encryption. =
Understanding attacks on privacy and the costs of addressing them is =
critical for ensuring the longevity, usability, and viability of =
Internet technologies.
>=20
> Alongside such work the emergence of global and region-specific =
legislation in this area e.g. GDPR provides further motivation for =
enhancing available privacy techniques (beyond end-to-end encryption), =
advancing the state-of-the-art for privacy in protocols, and for =
assessing privacy of existing protocols.
>=20
> ## Objectives
>=20
> The Privacy Enhancements and Assessments Research Group (PEARG) is a =
general forum for discussing and reviewing privacy enhancing =
technologies for network protocols and distributed systems in general, =
and for the IETF in particular. The PEARG serves as a bridge between =
theory and practice, bringing new privacy-enhancing technologies to the =
Internet community and promoting an understanding of the use and =
applicability of these mechanisms via Informational RFCs (in the =
tradition of HMAC [RFC 2104]).  Our goal is to provide a forum for =
discussion and analyzing the cryptographic and practical aspects of =
privacy protocols, and to offer guidance on the use of emerging =
techniques and new uses of existing ones.  IETF working groups =
developing protocols that include privacy technology elements are =
welcome to bring questions concerning the protocols to the PEARG for =
advice.
>=20
> The Assessments objective of PEARG will include partaking in the =
following tasks:
>=20
> 1) Reviewing privacy properties (informed by but not limited to the =
analysis in RFC6973) of existing and emerging IETF protocols,
>=20
> 2) Developing specifications in the tradition of RFC 6973 that offer =
guidance for protocol design and development and advice on =
privacy-enhancement.
>=20
> This work will involve outreach to ensure close cooperation with =
similar and related efforts in IETF.
>=20
> ## Meetings
>=20
> The PEARG will meet two to three times per year, as deemed necessary =
by the chairs and according to demand. At least one PEARG meeting will =
be co-located with an IETF meeting per year. The PEARG will also meet =
collocated with relevant academic conferences, such as the Privacy =
Enhancing Technologies Symposium (PETS), yearly if possible. =
Participation is open to all.
>=20
> Meetings are by default open with open attendance and published =
proceedings, with remote participation and recording as provided by the =
meeting venue, according to the IRTF=E2=80=99s IPR policy.
>=20
> The chairs may at times appoint at their pleasure =E2=80=9Cclosed=E2=80=9D=
 design teams with lesser reporting requirements (though results will be =
open).  This will allow for some limited discussions in which =
participants require extra privacy.  This does not relax the Note Well:  =
for all activities of the RG, as for all other activities of IRTF, the =
Note Well applies [https://www.ietf.org/about/note-well/ =
].
>=20
> ## Collaborations
>=20
> PEARG will actively engage with academic and open source (e.g. Tor =
project, EFF, OTF) communities and encourage specification of key =
privacy-enhancing technologies in Informational or Experimental RFCs.  =
Example current emerging technologies where interest is solicited =
include:
>=20
> 1. Differential privacy techniques applied to networked and =
distributed systems
> 2. Anti-fingerprinting techniques
> 3. Potential uses of MPC for privacy
>=20
> PEARG is related to security and cryptographic protocols in the IETF =
and IRTF. Among the IETF working groups, PEARG will collaborate to =
ensure and encourage collaboration so that desirable privacy properties =
are upheld for the Internet community. PEARG will also collaborate with =
the CFRG to ensure cryptographic techniques and algorithms are used =
appropriately for their intended purpose.
>=20
>=20
>=20
> --
> Pearg mailing list
> Pearg@irtf.org 
> https://www.irtf.org/mailman/listinfo/pearg =

>=20
>=20


--Apple-Mail=_8643BB6B-F86D-4DA6-8FA4-26E1E9E36932
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Note =
the inclusion of some QUIC-related items on the list below.

Lars

Begin forwarded message:

From: =
Allison Mankin <allison.mankin@gmail.com>
Subject: =
[irsg] IRTF =
Announcement: Starting up PEARG, to work on Privacy-Enhancing =
Technologies in IRTF
Date: =
July 5, 2018 at 21:05:52 =
GMT+2
To: =
irtf-announce@irtf.org,  "Internet Research Steering =
Group (irsg@irtf.org)" =
<irsg@irtf.org>, =
IRTF Discussion <irtf-discuss@irtf.org>

Dear IRTF folks,

Please see the note =
below.  A side meeting will take place to get feedback and move =
towards organizing PEARG (Privacy Enhancements and Assessment (Proposed) =
RG.  Please join the pearg mailing list if you are interested in =
participating.  Meeting info will also be sent on lists addressed =
here.  You may receive this multiple times,  so thanks for =
your patience!

To subscribe:  https://www.irtf.org/mailman/listinfo/pearg

See you in =
Montreal!

Allison
IRTF Chair


---------- Forwarded message ----------
From: Sara Dickinson <sara@sinodun.com>
Date: 5 July =
2018 at 12:51
Subject: [Pearg] Welcome to the Privacy =
Enhancements and Assessment Proposed RG mailing list!
To: =
pearg@irtf.org


Dear All, 

We would like to announce the first =
meeting (a side meeting) of the Privacy Enhancements and Assessment =
(PEA) Proposed RG to be held at IETF 102 in Montreal. We are waiting =
confirmation of our time slot, we have requested 18:40 on Tuesday 17th =
July and will post to this list as soon as we have more =
details.

The =
chairs for this Proposed RG are:
Sara Dickinson (sara@sinodun.com) and 
Shivan =
Sahib (ssahib@salesforce.com)

This side meeting is planned as an =
informal discussion for parties interested in participating in the =
Proposed RG. There will be an overview of the proposed charter (see =
below) and we would like to solicit feedback on the charter and also =
possible future work in the group. 

As food for thought we believe that =
there are several ongoing privacy-relevant efforts and discussions in =
various IETF and IRTF groups that would benefit from a dedicated group =
for analysis, including:

- [QUIC] Privacy leaks via =
passive network management via the proposed QUIC spin bit.
-=
 [QUIC] Connection migration and multipath privacy properties of exposed =
packet header information.
- [DoH] Privacy implications =
for various use cases and for server operators.
- [DRUI =
(BoF)] Privacy implications of DNS resolver discovery mechanisms.
- [DNSSD] Private service discovery threat model formulation =
and solution analysis.
- [DPRIVE] BCP for operators of DNS =
privacy services. Padding profile analysis.
- [ICNRG] =
Privacy implications of unencrypted content requests (interests).
- [TRANS] Privacy implications of certificate transparency =
gossiping.
- [RTCWEB] Privacy issues around exposing =
private IP addresses in WebRTC

Equally important, there is active research being conducted =
in the academic and open source communities around privacy preserving =
techniques that the IETF and IRTF could benefit from adopting.

We=E2=80=99=
ll also discuss scheduling future meetings, including possible =
co-location with events other than the IETF. 

Best regards

Sara & Shivan




# Draft Charter

## =
Background

Privacy is an increasingly =
desirable and often necessary property for Internet technologies. =
Evidence suggests that attacks on societal, community, =
and individual privacy occur with non-negligible frequency, as =
discussed in detail in RFC 7258 and in protocol-specific documents such =
as RFC 7626. Pervasive monitoring [RFC 7258], is a well known =
attack on privacy at incredible scale.  The IETF and IAB responses =
to such attacks is to push for widespread end-to-end encryption. =
Understanding attacks on privacy and the costs of addressing them is =
critical for ensuring the longevity, usability, and viability of =
Internet technologies. 

Alongside such =
work the emergence of global and region-specific legislation in this =
area e.g. GDPR provides further motivation for enhancing =
available privacy techniques (beyond end-to-end encryption), =
advancing the state-of-the-art for privacy in protocols, and for =
assessing privacy of existing protocols. 

## Objectives

The Privacy =
Enhancements and Assessments Research Group (PEARG) is a general forum =
for discussing and reviewing privacy enhancing technologies for =
network protocols and distributed systems in general, and for the IETF =
in particular. The PEARG serves as a bridge between theory and =
practice, bringing new privacy-enhancing technologies to the =
Internet community and promoting an understanding of the use and =
applicability of these mechanisms via Informational RFCs (in the =
tradition of HMAC [RFC 2104]).  Our goal is to provide a forum for =
discussion and analyzing the cryptographic and practical aspects of =
privacy protocols, and to offer guidance on the use of emerging =
techniques and new uses of existing ones.  IETF working groups =
developing protocols that include privacy technology elements are =
welcome to bring questions concerning the protocols to the PEARG for =
advice.

The Assessments objective of PEARG =
will include partaking in the following tasks:

1) Reviewing privacy properties (informed by but not limited =
to the analysis in RFC6973) of existing and emerging IETF protocols,

2) Developing specifications in the tradition =
of RFC 6973 that offer guidance for protocol design and development =
and advice on privacy-enhancement.  

This work will involve outreach to =
ensure close cooperation with similar and related efforts in =
IETF. 

## =
Meetings

The PEARG =
will meet two to three times per year, as deemed necessary by the chairs =
and according to demand. At least one PEARG meeting will be co-located =
with an IETF meeting per year. The PEARG will also meet collocated with =
relevant academic conferences, such as the Privacy =
Enhancing Technologies Symposium (PETS), yearly if possible. =
Participation is open to all. 

Meetings =
are by default open with open attendance and published proceedings, with =
remote participation and recording as provided by the meeting =
venue, according to the IRTF=E2=80=99s IPR policy. 

The chairs may at times appoint at their =
pleasure =E2=80=9Cclosed=E2=80=9D design teams with lesser reporting =
requirements (though results will be open).  This will allow =
for some limited discussions in which participants require extra =
privacy.  This does not relax the Note Well:  for all =
activities of the RG, as for all other activities of IRTF, the Note =
Well applies [https://www.ietf.org/about/note-well/].

## =
Collaborations

PEARG =
will actively engage with academic and open source (e.g. Tor project, =
EFF, OTF) communities and encourage specification of key =
privacy-enhancing technologies in Informational or Experimental =
RFCs.  Example current emerging technologies where interest is =
solicited include:

1. Differential privacy =
techniques applied to networked and distributed systems
2. =
Anti-fingerprinting techniques
3. Potential uses of MPC =
for privacy 

PEARG is related to =
security and cryptographic protocols in the IETF and IRTF. Among the =
IETF working groups, PEARG will collaborate to ensure and encourage =
collaboration so that desirable privacy properties are upheld for the =
Internet community. PEARG will also collaborate with the CFRG to =
ensure cryptographic techniques and algorithms are used =
appropriately for their intended purpose.



-- 

Pearg mailing list

Pearg@irtf.org

https://www.irtf.org/mailman/listinfo/pearg






=

--Apple-Mail=_8643BB6B-F86D-4DA6-8FA4-26E1E9E36932--

--Apple-Mail=_9D059701-271C-461E-8F1F-ACA8A8BA10CD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAls/FD0ACgkQVLXDCb9w
wVcWmw//bsRMySA1bCR3X0gutB+R3lZYD9w1fjv1DbC8A9SqFlqy1gr+12SAmBwc
RqlIRC6NGtnCTa31z+zJI51QskBAXx8jxm0JhW6kxY8uijA6dk1M1Vj/eLP+l8Ce
/ulqZpM2/E4ihzY1hzqtwlYeACz+rVv4Fxrh3v//pDttGo4GsjOMtPgPtCr3vMeT
jsivgZlUwHm+9nQFNyjgkgFy5OejK6pu9ZCm/sml8W7gN1HLBK2m48gphtXPzu3Q
WAR+HPSfDup4WNomd37yYTk9j0w3QDRu+H8WJNWsb7viLLoOca5JxY8gWWo6h6JX
r/rVVcgSsI4iYd91YBRHzrIOONrsQqr4kG3D32tQxGEYUeZ3xUleoNqxkmUTUsxL
U3o18yEZAqUaVfDbAycLNYILJvS9qFQdC6e5+CTPyTObg2ZTAQMWvsJLhHMS0IZv
GWRkTPzGuDR0T4/M0v0LqdWfI9rFF5O9Y5wt8EN9fAKIR2997v6XiALVkPnTG7UN
WVpy3buYth3E/JbcCD/e1jDYy8KRjfXwLuH78xBhQ+toKsS3+bwYVW4u6DUt+knZ
m8vmVcLZRE9IPdGtaNQha81+dGYv0UDfXZOJxFsp4Db8Wn3zissBY7yqaJpxsv2w
mNVsSviFp3/KM+etCkSbSCr3rh48S+cIsnJxYy9nbE64IO4GEi4=
=wVtn
-----END PGP SIGNATURE-----

--Apple-Mail=_9D059701-271C-461E-8F1F-ACA8A8BA10CD--


From nobody Fri Jul  6 02:59:29 2018
Return-Path: 
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 81497130E7E for ; Fri,  6 Jul 2018 02:59:27 -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 fA24F94giEez for ; Fri,  6 Jul 2018 02:59:24 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 49DC6130E2D for ; Fri,  6 Jul 2018 02:59:24 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id j185-v6so16045620ite.1 for ; Fri, 06 Jul 2018 02:59:24 -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;  bh=mghkWWA7WpAGLESpfoby2BoaP7SKJREe88wSXuSQu5s=; b=nwhamSi4js7ntLI4Z4K4JTxJkNb1mbfxRA6dHqSD2LEQ/18+APKE8IYfsJ48ttVBoO lzdJ+PY6Ruh1dm8rshEtZb8wFV71dUcQ+bm465gTlKei77pVe+52N15Hclj2gcHJmjMR 1XhB9s2lzFRoT2os97BT7F0aLgP9faCm/d1Mhbiucm3OHzU7mUocNjEEeL8/RpQPMOPN ANQCsc6EWWo2/NanetwiNq9vDVgCHfYNkUvn+vDdzp60zWxQSUdqMFY89Grr3GV5PLOm qbFB4MQpQvdw2XpCaJsQX80WnLD0x2Bwh5Vhq7h9F67HDZpUQqnvGJ6DzZsBaEuWHtbN ofpg==
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; bh=mghkWWA7WpAGLESpfoby2BoaP7SKJREe88wSXuSQu5s=; b=hQmznObGBhIYrDXtBgxq4GpYrwFtaTZUqW5Ov66r6BUbbCUv93ryk8NKy5SCabzoft Ap98LBrGrE6uk+08dftYWad35qRKzBkqsmM5JiU0nvtQmsSuztSu7sNWAV63sFtVda5D 9+ZoeogvQuF5yaNDqpLyXEYBfLgE+Gx9xVoBysQXmDxeKSlhdOPUjF2UWKwJj433tdnV 4GMgKdh3CH+8JLzG8hvSu8y6Ir4DjOT3LLYrcr18YyHEn6tGIXp/HZDLdksdX8kwPCGH oqbwIffpNGsqWR9IW4ep4AJaRVw8+/hVyHrHgwAWJJ0FaZPduXgpDhTMB/aTXy++JWmo hNew==
X-Gm-Message-State: APt69E1hMuEGf0DmpUImDZfFHGPmdv9bxddHxFJDEabRJ80MMVe4EKlU iJDy3yqXwfKKAmi/PQmsn/SUoO/QVcZbKXjlDUZ/bA==
X-Google-Smtp-Source: AAOMgpc6UH9VC5zPnDJ0mFmXFefLskrWJdee/2RDHXuXBI13ujfMEVrFsDBTPe0Ydk28n+uq/4vCjATp1/A9sdm5KZU=
X-Received: by 2002:a02:9833:: with SMTP id t48-v6mr7793617jaj.111.1530871163333;  Fri, 06 Jul 2018 02:59:23 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Jul 2018 05:59:22 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <730E056B-7A30-4940-9EA5-E0B4AB718A66@netapp.com>
References:  <730E056B-7A30-4940-9EA5-E0B4AB718A66@netapp.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 6 Jul 2018 05:59:22 -0400
Message-ID: 
Subject: Re: Fwd: [irsg] IRTF Announcement: Starting up PEARG, to work on Privacy-Enhancing Technologies in IRTF
To: IETF QUIC WG , "Eggert, Lars" 
Content-Type: multipart/alternative; boundary="000000000000e331af057051b750"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 09:59:28 -0000

--000000000000e331af057051b750
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I probably won=E2=80=99t join, but you could add 0-RTT tokens to that since=
 the
server can use it as a cookie.


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

Note the inclusion of some QUIC-related items on the list below.

Lars

Begin forwarded message:

*From:* Allison Mankin 
*Subject:* *[irsg] IRTF Announcement: Starting up PEARG, to work on
Privacy-Enhancing Technologies in IRTF*
*Date:* July 5, 2018 at 21:05:52 GMT+2
*To:* irtf-announce@irtf.org, "Internet Research Steering Group (
irsg@irtf.org)" , IRTF Discussion 

Dear IRTF folks,

Please see the note below.  A side meeting will take place to get feedback
and move towards organizing PEARG (Privacy Enhancements and Assessment
(Proposed) RG.  Please join the pearg mailing list if you are interested in
participating.  Meeting info will also be sent on lists addressed here.
You may receive this multiple times,  so thanks for your patience!

To subscribe:  https://www.irtf.org/mailman/listinfo/pearg

See you in Montreal!

Allison
IRTF Chair


---------- Forwarded message ----------
From: Sara Dickinson 
Date: 5 July 2018 at 12:51
Subject: [Pearg] Welcome to the Privacy Enhancements and Assessment
Proposed RG mailing list!
To: pearg@irtf.org


Dear All,

We would like to announce the first meeting (a side meeting) of the Privacy
Enhancements and Assessment (PEA) Proposed RG to be held at IETF 102 in
Montreal. We are waiting confirmation of our time slot, we have requested
18:40 on Tuesday 17th July and will post to this list as soon as we have
more details.

The chairs for this Proposed RG are:
Sara Dickinson (sara@sinodun.com) and
Shivan Sahib (ssahib@salesforce.com)

This side meeting is planned as an informal discussion for parties
interested in participating in the Proposed RG. There will be an overview
of the proposed charter (see below) and we would like to solicit feedback
on the charter and also possible future work in the group.

As food for thought we believe that there are several ongoing
privacy-relevant efforts and discussions in various IETF and IRTF groups
that would benefit from a dedicated group for analysis, including:

- [QUIC] Privacy leaks via passive network management via the proposed QUIC
spin bit.
- [QUIC] Connection migration and multipath privacy properties of exposed
packet header information.
- [DoH] Privacy implications for various use cases and for server operators=
.
- [DRUI (BoF)] Privacy implications of DNS resolver discovery mechanisms.
- [DNSSD] Private service discovery threat model formulation and solution
analysis.
- [DPRIVE] BCP for operators of DNS privacy services. Padding profile
analysis.
- [ICNRG] Privacy implications of unencrypted content requests (interests).
- [TRANS] Privacy implications of certificate transparency gossiping.
- [RTCWEB] Privacy issues around exposing private IP addresses in WebRTC

Equally important, there is active research being conducted in the academic
and open source communities around privacy preserving techniques that the
IETF and IRTF could benefit from adopting.

We=E2=80=99ll also discuss scheduling future meetings, including possible
co-location with events other than the IETF.

Best regards

Sara & Shivan




# Draft Charter

## Background

Privacy is an increasingly desirable and often necessary property for
Internet technologies. Evidence suggests that attacks on societal,
community, and individual privacy occur with non-negligible frequency, as
discussed in detail in RFC 7258 and in protocol-specific documents such as
RFC 7626. Pervasive monitoring [RFC 7258], is a well known attack on
privacy at incredible scale.  The IETF and IAB responses to such attacks is
to push for widespread end-to-end encryption. Understanding attacks on
privacy and the costs of addressing them is critical for ensuring the
longevity, usability, and viability of Internet technologies.

Alongside such work the emergence of global and region-specific legislation
in this area e.g. GDPR provides further motivation for enhancing
available privacy techniques (beyond end-to-end encryption), advancing the
state-of-the-art for privacy in protocols, and for assessing privacy of
existing protocols.

## Objectives

The Privacy Enhancements and Assessments Research Group (PEARG) is a
general forum for discussing and reviewing privacy enhancing
technologies for network protocols and distributed systems in general, and
for the IETF in particular. The PEARG serves as a bridge between theory and
practice, bringing new privacy-enhancing technologies to the Internet
community and promoting an understanding of the use and applicability of
these mechanisms via Informational RFCs (in the tradition of HMAC [RFC
2104]).  Our goal is to provide a forum for discussion and analyzing the
cryptographic and practical aspects of privacy protocols, and to offer
guidance on the use of emerging techniques and new uses of existing ones.
IETF working groups developing protocols that include privacy technology
elements are welcome to bring questions concerning the protocols to the
PEARG for advice.

The Assessments objective of PEARG will include partaking in the following
tasks:

1) Reviewing privacy properties (informed by but not limited to the
analysis in RFC6973) of existing and emerging IETF protocols,

2) Developing specifications in the tradition of RFC 6973 that offer
guidance for protocol design and development and advice on
privacy-enhancement.

This work will involve outreach to ensure close cooperation with similar
and related efforts in IETF.

## Meetings

The PEARG will meet two to three times per year, as deemed necessary by the
chairs and according to demand. At least one PEARG meeting will be
co-located with an IETF meeting per year. The PEARG will also meet
collocated with relevant academic conferences, such as the Privacy
Enhancing Technologies Symposium (PETS), yearly if possible. Participation
is open to all.

Meetings are by default open with open attendance and published
proceedings, with remote participation and recording as provided by the
meeting venue, according to the IRTF=E2=80=99s IPR policy.

The chairs may at times appoint at their pleasure =E2=80=9Cclosed=E2=80=9D =
design teams
with lesser reporting requirements (though results will be open).  This
will allow for some limited discussions in which participants require extra
privacy.  This does not relax the Note Well:  for all activities of the RG,
as for all other activities of IRTF, the Note Well applies [
https://www.ietf.org/about/note-well/].

## Collaborations

PEARG will actively engage with academic and open source (e.g. Tor project,
EFF, OTF) communities and encourage specification of key privacy-enhancing
technologies in Informational or Experimental RFCs.  Example current
emerging technologies where interest is solicited include:

1. Differential privacy techniques applied to networked and distributed
systems
2. Anti-fingerprinting techniques
3. Potential uses of MPC for privacy

PEARG is related to security and cryptographic protocols in the IETF and
IRTF. Among the IETF working groups, PEARG will collaborate to ensure
and encourage collaboration so that desirable privacy properties are upheld
for the Internet community. PEARG will also collaborate with the CFRG to
ensure cryptographic techniques and algorithms are used appropriately for
their intended purpose.



--
Pearg mailing list
Pearg@irtf.org
https://www.irtf.org/mailman/listinfo/pearg

--000000000000e331af057051b750
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I probably won=E2=80=
=99t join, but you could add 0-RTT tokens to that since the server can use =
it as a cookie.

 
On 6 July 2018 at 09.03.54, Egger=
t, Lars (lars@netapp.com) wrote:
=
 







Note the inclusion of some QUIC-related items on the list below.




Lars







Begin forwarded message:




Fr=
om: Allison Mankin <allison.mankin@gmail.com>


Su=
bject: [irsg] IRTF Announcemen=
t: Starting up PEARG,
to work on Privacy-Enhancing Technologies in IRTF
=



Da=
te: July 5, 2018 at 21:05:52 GMT+2


To=
: irtf-announce@irtf.org, "Internet Research Steering Gro=
up
(irsg@irtf.org)"
<irsg@irtf.org>,
IRTF Discussion <irt=
f-discuss@irtf.org>









Dear IRTF folks,





Please see the note
below.=C2=A0 A side meeting will take place to get feedback and
move towards organizing PEARG (Privacy Enhancements and Assessment
(Proposed) RG.=C2=A0 Please join the pearg mailing list if you are
interested in participating.=C2=A0 Meeting info will also be sent
on lists addressed here.=C2=A0 You may receive this multiple
times,=C2=A0 so thanks for your patience!





To subscribe:=C2=A0
https://www.irtf.org/mailman/l=
istinfo/pearg





See you in Montreal!





Allison


IRTF Chair








---------- Forwarded message
----------

From: Sara Dickinson <sara@sinodun.co=
m>

Date: 5 July 2018 at 12:51

Subject: [Pearg] Welcome to the Privacy Enhancements and Assessment
Proposed RG mailing list!

To: pearg@irtf.org








Dear All,=C2=A0





We would like to announce the first meeting (a side
meeting) of the Privacy Enhancements and Assessment (PEA) Proposed
RG to be held at IETF 102 in Montreal. We are waiting confirmation
of our time slot, we have requested 18:40 on Tuesday 17th July and
will post to this list as soon as we have more details.





The chairs for this Proposed RG are:


Sara Dickinson (sara@sinodun.com) and=C2=A0


Shivan Sahib (ssahib@salesforce.com)





This side meeting is planned as an informal
discussion for parties interested in participating in the Proposed
RG. There will be an overview of the proposed charter (see below)
and we would like to solicit feedback on the charter and also
possible future work in the group.=C2=A0





As food for thought we believe that there are several
ongoing privacy-relevant efforts and discussions in various IETF
and IRTF groups that would benefit from a dedicated group for
analysis, including:



- [QUIC] Privacy leaks via passive network management via the
proposed QUIC spin bit.

- [QUIC] Connection migration and multipath privacy properties of
exposed packet header information.

- [DoH] Privacy implications for various use cases and for server
operators.

- [DRUI (BoF)] Privacy implications of DNS resolver discovery
mechanisms.

- [DNSSD] Private service discovery threat model formulation and
solution analysis.

- [DPRIVE] BCP for operators of DNS privacy services. Padding
profile analysis.

- [ICNRG] Privacy implications of unencrypted content requests
(interests).

- [TRANS] Privacy implications of certificate transparency
gossiping.

- [RTCWEB] Privacy issues around exposing private IP addresses in
WebRTC




Equally important, there is active research being
conducted in the academic and open source communities around
privacy preserving techniques that the IETF and IRTF could benefit
from adopting.





We=E2=80=99ll also discuss scheduling future meetings,
including possible co-location with events other than the
IETF.=C2=A0





Best regards





Sara & Shivan
















# Draft Charter





## Background



Privacy is an increasingly desirable and often necessary property
for Internet technologies. Evidence suggests that attacks on
societal, community, and=C2=A0individual privacy occur with
non-negligible frequency, as discussed in detail in RFC 7258 and in
protocol-specific documents such as RFC 7626.=C2=A0Pervasive
monitoring [RFC 7258], is a well known attack on privacy at
incredible scale.=C2=A0 The IETF and IAB responses to such attacks
is to push for=C2=A0widespread end-to-end encryption. Understanding
attacks on privacy and the costs of addressing them is critical for
ensuring the longevity, usability, and=C2=A0viability of Internet
technologies.=C2=A0



Alongside such work the emergence of global and region-specific
legislation in this area e.g. GDPR provides further motivation for
enhancing available=C2=A0privacy techniques (beyond end-to-end
encryption), advancing the state-of-the-art for privacy in
protocols, and for assessing privacy of existing
protocols.=C2=A0



## Objectives



The Privacy Enhancements and Assessments Research Group (PEARG) is
a general forum for discussing and reviewing privacy enhancing
technologies=C2=A0for network protocols and distributed systems in
general, and for the IETF in particular. The PEARG serves as a
bridge between theory and practice,=C2=A0bringing new
privacy-enhancing technologies to the Internet community and
promoting an understanding of the use and applicability of these
mechanisms=C2=A0via Informational RFCs (in the tradition of HMAC
[RFC 2104]).=C2=A0 Our goal is to provide a forum for discussion
and analyzing the cryptographic and practical=C2=A0aspects of
privacy protocols, and to offer guidance on the use of emerging
techniques and new uses of existing ones.=C2=A0 IETF working groups
developing=C2=A0protocols that include privacy technology elements
are welcome to bring questions concerning the protocols to the
PEARG for advice.



The Assessments objective of PEARG will include partaking in the
following tasks:



1) Reviewing privacy properties (informed by but not limited to the
analysis in RFC6973) of existing and emerging IETF
protocols,



2) Developing specifications in the tradition of RFC 6973 that
offer guidance for protocol=C2=A0design and development and advice
on privacy-enhancement. =C2=A0





This work will involve outreach to ensure close
cooperation with similar and related efforts=C2=A0in
IETF.=C2=A0





## Meetings




The PEARG will meet two to three times per year, as
deemed necessary by the chairs and according to demand. At least
one PEARG meeting will be co-located with an IETF meeting per year.
The PEARG will also meet collocated with relevant academic
conferences, such as the Privacy Enhancing=C2=A0Technologies
Symposium (PETS), yearly if possible. Participation is open to
all.=C2=A0



Meetings are by default open with open attendance and published
proceedings, with remote participation and recording as provided by
the meeting venue,=C2=A0according to the IRTF=E2=80=99s IPR
policy.=C2=A0



The chairs may at times appoint at their pleasure =E2=80=9Cclosed=E2=80=9D =
design
teams with lesser reporting requirements (though results will be
open).=C2=A0 This will allow for=C2=A0some limited discussions in
which participants require extra privacy.=C2=A0 This does not relax
the Note Well: =C2=A0for all activities of the RG, as for all other
activities=C2=A0of IRTF, the Note Well applies [https://www.ietf.org/ab=
out/note-well/].




## Collaborations




PEARG will actively engage with academic and open
source (e.g. Tor project, EFF, OTF) communities and encourage
specification of key privacy-enhancing technologies in
Informational or Experimental RFCs.=C2=A0 Example current emerging
technologies where interest is solicited include:



1. Differential privacy techniques applied to networked and
distributed systems

2. Anti-fingerprinting techniques

3. Potential uses of MPC for privacy=C2=A0



PEARG is related to security and cryptographic protocols in the
IETF and IRTF. Among the IETF working groups, PEARG will
collaborate to ensure and=C2=A0encourage collaboration so that
desirable privacy properties are upheld for the Internet community.
PEARG will also collaborate with the CFRG to
ensure=C2=A0cryptographic techniques and algorithms are used
appropriately for their intended purpose.










--

Pearg mailing list

Pearg@irtf.org

https://www.irtf.org/mailman/l=
istinfo/pearg


















--000000000000e331af057051b750--


From nobody Fri Jul  6 08:00:50 2018
Return-Path: 
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 6F0D5130FE6 for ; Fri,  6 Jul 2018 08:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3wCXoOz0d6Ua for ; Fri,  6 Jul 2018 08:00:46 -0700 (PDT)
Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AF5130EBA for ; Fri,  6 Jul 2018 08:00:46 -0700 (PDT)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w66F0fRI027765; Fri, 6 Jul 2018 16:00:41 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0389.001; Fri, 6 Jul 2018 16:00:40 +0100
From: Lucas Pardue 
To: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "IETF QUIC WG" , Martin Duke , "Lubashev, Igor" 
Subject: RE: Treatment of ICMP for PMTU
Thread-Topic: Treatment of ICMP for PMTU
Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsgAJFrAwAAfLncD///9AgIAM8sy8
Date: Fri, 6 Jul 2018 15:00:40 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB6B21B@bgb01xud1012>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012>, 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23950.006
x-tm-as-result: No-10.415000-8.000000-10
x-tmase-matchedrid: z5DqD3Ob671xGyfbWjfsSxuurbgYp+HQgqd6JzaZubNJ/oIGXyyX8lTN qf3EQ8oxtzDrWJxEioOtnzrv0kNb2rjxJMcFZasFe5NWR5iixe2ZEoWHC6Rh/WO8D0RGuSzoSMw 7yiQ5hNxDwvRMVQLpjp/+EYQomaZlE6V/2dtg4KaN2XH+kPpjjJl/lu28zzkBcqpbvFV4XbTEZK HidzhUXKGwVXCCwVeTPGiD7E7pfUe2L7ZGrRpjDYa7OiQBC9buq6/EYzBxkJhtgXN8SPjcGMlMl 7WSd81b1CCGjlHZzRvp2/WQkTTCMi+JsPJdMSAFuIwLnB3Aqp1zBvBK5TfUrXLQ6+4hpEnp152a 4j27Jxh8iaF9fJvREBSG2FrT70yKntqpoQEvC7WimtMQe97AAJv8tNLRPUrWXwDLkmwDcf16+4Y 3holm5UBs56dzQBBaK7D2LgnL7xIZgd/Sc3gU4wz4VsCc1YW+Xeyujb7aXgRJTQZkUumNMcprMg +WQ2Ii1bxH3i2X13jiFNektabfg200sCPwNg7wFVfH7j3N9bcS12tj9Zvd831Dn+DKecbWV/w6z 6RQQ8Bm0OGqVvbkV6um06i1BvtxwLBOSQNcHqxc/msUC5wFQTPsdZKCLP2mum5eVh8PBT+jxYyR Ba/qJcaUO+wtQNbap0Bff6m2gascRx2FqmzvFUry688VPywtdbd7xtU5YSNNX5RhnD7Y3uO998a qqyTO
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--10.415000-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23950.006
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB6B21Bbgb01xud1012_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 15:00:49 -0000

--_000_7CF7F94CB496BF4FAB1676F375F9666A3BB6B21Bbgb01xud1012_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mikkel, Igor,

In case you don't follow HTTPbis: I have published an I-D [1] [2] that surv=
eys options for tunneling of UDP and IP. It presents some options for frami=
ng but it is not exhaustive. There's a slot on the agenda to discuss things=
 there.

I added a HoL section in response to your earlier comments. I'm looking for=
 input on whether such tunneling should depend on partial reliability in QU=
IC (bearing in mind that there may be some desire to support TCP-based HTTP=
).

Kind regards
Lucas

[1] https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnellin=
g-00
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0025.html

________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Mikkel Fahn=F8e J=F8rgensen=
 [mikkelfj@gmail.com]
Sent: 28 June 2018 11:07
To: Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev, Igor
Subject: RE: Treatment of ICMP for PMTU

I think QUIC needs a tunnel extension frame.


On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Igor Lubashev wrote:

>I think I see what you are talking about.
>
>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forwar=
d
>data streams, not packets. Hence, MTU concept on a tunnel-stream is
>meaningless. The text says it explicitly: "Note that the size and number o=
f TCP
>segments is not guaranteed to map predictably to the size and number of
>HTTP DATA or QUIC STREAM frames." From the client's perspective there is
>only one PMTU that is relevant -- the one to the proxy. The proxy will kee=
p
>tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC connection
>over a single QUIC stream would create HOLB for QUIC packets to and from
>the proxy. Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more though=
t. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL is en=
ough to make QUIC not QUIC". I've taken the view that it may be desirable t=
o tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so I view HOL=
 avoidance as an optimisation rather than a requirement. Partial reliabilit=
y (of streams, or of some new frame type) could help solve that puzzle. Now=
 I think about it, a complimentary mitigation could be to reserve a set of =
tunnel-streams to provide some basic multiplexing. However, the complexity =
of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open a
>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mandat=
e
>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it
>would be a very good idea for such a proxy to add a new frame for providin=
g
>ICMP-like explicit PMTU feedback to the sender (why leave the sender
>guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas


--_000_7CF7F94CB496BF4FAB1676F375F9666A3BB6B21Bbgb01xud1012_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Mikkel, Igor,







In case you don't follow HTTPbis: I have published an I-D [1] [2] that=
 surveys options for tunneling of UDP and IP. It presents some options for =
framing but it is not exhaustive. There's a slot on the agenda to discuss t=
hings there.







I added a HoL section in response to your earlier comments. I'm lookin=
g for input on whether such tunneling should depend on partial reliability =
in QUIC (bearing in mind that there may be some desire to support TCP-based=
 HTTP).







Kind regards


Lucas








[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0025.=
html











From: QUIC [quic-bounces@ietf.org] on beh=
alf of Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]

Sent: 28 June 2018 11:07

To: Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev, Igor

Subject: RE: Treatment of ICMP for PMTU











I think QUIC needs a tunnel extension frame.









On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:








Igor Lubashev wrote: 



>I think I see what you are talking about. 

> 

>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies for=
ward 

>data streams, not packets. Hence, MTU concept on a tunnel-stream is 
>meaningless. The text says it explicitly: "Note that the size and =
number of TCP 

>segments is not guaranteed to map predictably to the size and number of=
 

>HTTP DATA or QUIC STREAM frames." From the client's perspective th=
ere is 

>only one PMTU that is relevant -- the one to the proxy. The proxy will =
keep 

>tracks of the PMTUs to the CONNECT endpoints itself and will generate T=
CP 

>segments accordingly. 



Right, that's how I was seeing it. 



>Trying to design a CONNECT-like method to proxy an entire QUIC connecti=
on 

>over a single QUIC stream would create HOLB for QUIC packets to and fro=
m 

>the proxy. Some sort of a partially reliable QUIC stream could help her=
e. 



Both you and Mikkel have identified HOL as something that needs more though=
t. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL =
is enough to make QUIC not QUIC". I've taken the view that it may be d=
esirable to tunnel QUIC over TLS/TCP too (perhaps
 using HTTP/2 frames), so I view HOL avoidance as an optimisation rather th=
an a requirement. Partial reliability (of streams, or of some new frame typ=
e) could help solve that puzzle. Now I think about it, a complimentary miti=
gation could be to reserve a set
 of tunnel-streams to provide some basic multiplexing. However, the complex=
ity of that might not be worth it.




>This proxying scheme would require an extension to CONNECT to open a 
>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also man=
date 

>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it=
 

>would be a very good idea for such a proxy to add a new frame for provi=
ding 

>ICMP-like explicit PMTU feedback to the sender (why leave the sender 
>guessing and probing, if the PMTU is already known to the proxy?). 



This is good feedback. Thanks! 



Kind regards 

Lucas 




















--_000_7CF7F94CB496BF4FAB1676F375F9666A3BB6B21Bbgb01xud1012_--


From nobody Fri Jul  6 12:43:56 2018
Return-Path: 
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 17013130EF3 for ; Fri,  6 Jul 2018 12:43:55 -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 JS-0S5VPQBvF for ; Fri,  6 Jul 2018 12:43:52 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 48301130E6D for ; Fri,  6 Jul 2018 12:43:52 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id v71-v6so8124832itb.3 for ; Fri, 06 Jul 2018 12:43:52 -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;  bh=VZDG18AEP2OunVRyoshF3uLP/B3Go5ORjcji97l9yvM=; b=FjeTHpkqUjmuIo5aGdynkQ3NnBsFLdJUb0cy+rJobLchiZ4uZS0H8zCmkSU1xADbyf rKiHe4h6EyvehcsCmiWdXKFx0XY+2efDyVZWDjj/WGZzXdtzrgFkyoYKlSVMCa8GrtmM ufKdNIwSvsgO7DgEHHKhTluxnJPd0XwXn79m3uMLkawpFXTXBfc9t81svTOk95k5+vOg PPFIhpYwVahpDDk/60G6ScmAu7BXqqah1e2v69ZLQ8eDF+nVFFQxnuV8Gz/+NttbXp/F l5GLj6wS0FFcvBSb5yVKcu9dv7bz1G2vRbO2QnixK8pBIzYEUCzD9bO7w/5cXc1Ihug3 kpBw==
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; bh=VZDG18AEP2OunVRyoshF3uLP/B3Go5ORjcji97l9yvM=; b=Aq9vGmECMJsbGUcv4PDCUdL7ErXf4gA62orTmFBn7ckrCIPJt2aurIqWD5F5xNn1SK kJA06qjQ8eMsqZRz+LkC6kT6EZC96l9t5I4MQ/y84llk1cnASsFAEq0AX8jFcPIByHjp A9paiCP9DvSawqUE7cGXZ/CKt2R14pQ+inRLS1n55RQEVjIMADMd5jhK8PL6VykThpmT Uk/87ZhESJOgDilnY47ON0Dr9USDZy8BWx969+4zp+ZhDx0aEEIBWu3szdlyF3oU2LX+ DO0ULX8JKFdh/DGB1hOSEijbrDc4bOpCJfA3xoHq2SSaKjZOn+3VxEmgPpWQS1Txzj1g ynlg==
X-Gm-Message-State: APt69E2lZdyd4usU2l88ZzHhrUUIKBI4ffU7A5mVQk/VVFByqNVS+J2X pYExseIYs5QGXIcz2JlVOhmh0TuCXFbus4sqkYbLCg==
X-Google-Smtp-Source: AAOMgpdo0UTKH1+vB+qkNeuQ107mtMpHJQ1ZlmdY6p03MbuIhn79dgXU3+yHSbwHaFUE2vmNA2pC3DRj27ajkURw9rk=
X-Received: by 2002:a24:534c:: with SMTP id n73-v6mr9288342itb.25.1530906231519;  Fri, 06 Jul 2018 12:43:51 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Jul 2018 15:43:50 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB6B21B@bgb01xud1012>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012> <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012> <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA9B@bgb01xud1012>  <7CF7F94CB496BF4FAB1676F375F9666A3BB6B21B@bgb01xud1012>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 6 Jul 2018 15:43:50 -0400
Message-ID: 
Subject: RE: Treatment of ICMP for PMTU
To: Lucas Pardue , IETF QUIC WG ,  Martin Duke , "Lubashev, Igor" 
Content-Type: multipart/alternative; boundary="0000000000001d471f057059e291"
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 19:43:56 -0000

--0000000000001d471f057059e291
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Lukas, thanks for working on this.

It=E2=80=99s a bit much for me swallow in detail so I can only provide some=
 general
thoughts.

QUIC recently added extension frames that require IANA registry, but there
is an endless supply.
This could be used to define semantics suitable for lossless packets in a
very straightforward manner that may be simpler than Partial Reliability
once that lands because you just add a tunnel header and ship the frame as
if it were a UDP packet without ACK=E2=80=99ing it. There needs to focus on=
 flow
control all the same. That could be tricky.

Now, adding extension random frames for something that aims to be standard
outside of QUIC is probably not optimal, especially considering that
QUIC/v2 is sort of expected to deliver something similar. In fact, this
could be great input for a v2 use case. I imagine there won=E2=80=99t be a =
one size
suits all partial reliability feature. In part because tunneling doesn=E2=
=80=99t
even want partial reliability, just unreliability - i.e. not attempt at
ordering what is received, if it is received.

Additionally, the constraint that tunneling should happen not just over
QUIC but QUIC/HTTP adds additional constraints because QUIC/HTTP would not
automatically add an extension frame. It might even not really support
partial reliability in v2 in a way that is well suited for the problem. On
the other hand, QUIC/HTTP seems to be infinitely hackable, so you could
abuse unistreams to create packets - but likely that would sink
unsuspecting end-points not optimized for that.

Now, I don=E2=80=99t know that much about HTTP tunnelling - but - it might =
be
possible to use QUIC/HTTP as a signalling path and create a separate QUIC
connection for payload with either an extension frame, or a future v2
unreliability feature, or even an official tunnelling frame.

Given that QUIC is encrypted, it becomes harder for middleware to block
non-HTTP, so the question is: why does it need to be over HTTP? If the
answer is that middelware still knows too much - perhaps QUIC should fix
that.

So, I think the best option would probably be to wait for v2 and do some
studies with extension frames meanwhile and possibly play with signalling
via QUIC/HTTP if it must be HTTP.


But all of this just based on intuition and no deep knowledge of tunneling
protocols.

Mikkel


On 6 July 2018 at 17.00.44, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Mikkel, Igor,

In case you don't follow HTTPbis: I have published an I-D [1] [2] that
surveys options for tunneling of UDP and IP. It presents some options for
framing but it is not exhaustive. There's a slot on the agenda to discuss
things there.

I added a HoL section in response to your earlier comments. I'm looking for
input on whether such tunneling should depend on partial reliability in
QUIC (bearing in mind that there may be some desire to support TCP-based
HTTP).

Kind regards
Lucas

[1]
https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-00
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0025.html

------------------------------
*From:* QUIC [quic-bounces@ietf.org] on behalf of Mikkel Fahn=C3=B8e J=C3=
=B8rgensen [
mikkelfj@gmail.com]
*Sent:* 28 June 2018 11:07
*To:* Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev, Igor
*Subject:* RE: Treatment of ICMP for PMTU

I think QUIC needs a tunnel extension frame.

On 28 June 2018 at 11.25.20, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Igor Lubashev wrote:

>I think I see what you are talking about.
>
>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forwar=
d
>data streams, not packets. Hence, MTU concept on a tunnel-stream is
>meaningless. The text says it explicitly: "Note that the size and number
of TCP
>segments is not guaranteed to map predictably to the size and number of
>HTTP DATA or QUIC STREAM frames." From the client's perspective there is
>only one PMTU that is relevant -- the one to the proxy. The proxy will kee=
p
>tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC connection
>over a single QUIC stream would create HOLB for QUIC packets to and from
>the proxy. Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more
thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL
is enough to make QUIC not QUIC". I've taken the view that it may be
desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so
I view HOL avoidance as an optimisation rather than a requirement. Partial
reliability (of streams, or of some new frame type) could help solve that
puzzle. Now I think about it, a complimentary mitigation could be to
reserve a set of tunnel-streams to provide some basic multiplexing.
However, the complexity of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open a
>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mandat=
e
>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it
>would be a very good idea for such a proxy to add a new frame for providin=
g
>ICMP-like explicit PMTU feedback to the sender (why leave the sender
>guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas

--0000000000001d471f057059e291
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Hi Lukas, thanks for=
 working on this.

It=
=E2=80=99s a bit much for me swallow in detail so I can only provide some g=
eneral thoughts.

QUIC=
 recently added extension frames that require IANA registry, but there is a=
n endless supply.
This could be used to define semantics suitable for lossless packets i=
n a very straightforward manner that may be simpler than Partial Reliabilit=
y once that lands because you just add a tunnel header and ship the frame a=
s if it were a UDP packet without ACK=E2=80=99ing it. There needs to focus =
on flow control all the same. That could be tricky.

Now, adding extension random frames for some=
thing that aims to be standard outside of QUIC is probably not optimal, esp=
ecially considering that QUIC/v2 is sort of expected to deliver something s=
imilar. In fact, this could be great input for a v2 use case. I imagine the=
re won=E2=80=99t be a one size suits all partial reliability feature. In pa=
rt because tunneling doesn=E2=80=99t even want partial reliability, just un=
reliability - i.e. not attempt at ordering what is received, if it is recei=
ved.

Additionally, th=
e constraint that tunneling should happen not just over QUIC but QUIC/HTTP =
adds additional constraints because QUIC/HTTP would not automatically add a=
n extension frame. It might even not really support partial reliability in =
v2 in a way that is well suited for the problem. On the other hand, QUIC/HT=
TP seems to be infinitely hackable, so you could abuse unistreams to create=
 packets - but likely that would sink unsuspecting end-points not optimized=
 for that.
Now, I don=
=E2=80=99t know that much about HTTP tunnelling - but - it might be possibl=
e to use QUIC/HTTP as a signalling path and create a separate QUIC connecti=
on for payload with either an extension frame, or a future v2 unreliability=
 feature, or even an official tunnelling frame.

Given that QUIC is encrypted, it becomes harder =
for middleware to block non-HTTP, so the question is: why does it need to b=
e over HTTP? If the answer is that middelware still knows too much - perhap=
s QUIC should fix that.

So, I think the best option would probably be to wait for v2 and do some=
 studies with extension frames meanwhile and possibly play with signalling =
via QUIC/HTTP if it must be HTTP.
 


But a=
ll of this just based on intuition and no deep knowledge of tunneling proto=
cols.

Mikkel

 
=
On 6 July 2018 at 17.00.44, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:
 













Mikkel, Igor,





In case you don't follow HTTPbis: I have published an I-D [1]
[2] that surveys options for tunneling of UDP and IP. It presents
some options for framing but it is not exhaustive. There's a slot
on the agenda to discuss things there.





I added a HoL section in response to your earlier comments.
I'm looking for input on whether such tunneling should depend on
partial reliability in QUIC (bearing in mind that there may be some
desire to support TCP-based HTTP).





Kind regards


Lucas














From: QUIC [quic-bounces@ietf.org]
on behalf of Mikkel Fahn=C3=B8e J=C3=B8rgensen [mikkelfj@gmail.com]

Sent: 28 June 2018 11:07

To: Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev,
Igor

Subject: RE: Treatment of ICMP for
PMTU






I think QUIC needs a tunnel extension frame.







On 28 June 2018 at 11.25.20, Lucas Pardue
(lucas.pardue@bbc.co.uk) wrote:






Igor Lubashev wrote:



>I think I see what you are talking about.

>

>At least the way it is specced in H2 and HTTP/QUIC, CONNECT
proxies forward

>data streams, not packets. Hence, MTU concept on a
tunnel-stream is

>meaningless. The text says it explicitly: "Note that the size
and number of TCP

>segments is not guaranteed to map predictably to the size and
number of

>HTTP DATA or QUIC STREAM frames." From the client's perspectiv=
e
there is

>only one PMTU that is relevant -- the one to the proxy. The
proxy will keep

>tracks of the PMTUs to the CONNECT endpoints itself and will
generate TCP

>segments accordingly.



Right, that's how I was seeing it.



>Trying to design a CONNECT-like method to proxy an entire QUIC
connection

>over a single QUIC stream would create HOLB for QUIC packets to
and from

>the proxy. Some sort of a partially reliable QUIC stream could
help here.



Both you and Mikkel have identified HOL as something that needs
more thought. Thanks. Mikkel's view is a little more extreme, to
paraphrase "HOL is enough to make QUIC not QUIC". I've taken =
the
view that it may be desirable to tunnel QUIC over TLS/TCP too
(perhaps using HTTP/2 frames), so I view HOL avoidance as an
optimisation rather than a requirement. Partial reliability (of
streams, or of some new frame type) could help solve that puzzle.
Now I think about it, a complimentary mitigation could be to
reserve a set of tunnel-streams to provide some basic multiplexing.
However, the complexity of that might not be worth it.



>This proxying scheme would require an extension to CONNECT to
open a

>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would
also mandate

>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect
that it

>would be a very good idea for such a proxy to add a new frame
for providing

>ICMP-like explicit PMTU feedback to the sender (why leave the
sender

>guessing and probing, if the PMTU is already known to the
proxy?).



This is good feedback. Thanks!



Kind regards

Lucas




















--0000000000001d471f057059e291--


From nobody Sat Jul  7 17:45:26 2018
Return-Path: 
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 E91B7130F01 for ; Sat,  7 Jul 2018 17:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=mnot.net header.b=vY7lXTnm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VofmruKF
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 ijTVecGeFf-O for ; Sat,  7 Jul 2018 17:45:21 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4448130DFE for ; Sat,  7 Jul 2018 17:45:21 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B9AD9653 for ; Sat,  7 Jul 2018 20:45:20 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 07 Jul 2018 20:45:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=fxxPyi5kBfP1y2mKJ aKbTvcM8BpEZjFbLa1Yn5mQtXM=; b=vY7lXTnmeEpmHWJYo+mKKuFgdN3G5Ud6j 14e7I7PA0e0AFOCtQPNAb/RhoF16EDFNeOV8PujWJ3K2fadgMVUt63OY4lY4bW2Z CBUBW+f6dd1HL3C3Fllmboz8JiBrdfD8CK8oKzhF/t1lyRTRJ4e0d384qwFDrXE2 Z/k4cFK4GNJWPHkv9g9FGr4FQa8hrTkNK8DnM4azmAUM+oVPLFD/gbUU7cjtYQjn wOtbqkZOP/h5OOe5eOYMqNT8ZBYs/wYkb4k22X/N/9fdBmc3TacfvBumiI2ZhabS 6AhlTBu0eeeAHNz/ABbeC/TaF53EZB6bnQvYcZpYFRx00K/siI8dA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=fxxPyi5kBfP1y2mKJaKbTvcM8BpEZjFbLa1Yn5mQtXM=; b=VofmruKF 25gXnVyMk1fIyh7IKw5sVXcE/TUvkNwjBjHDgWbBkWscLoc24AC02MW4MAC3CpmA jmT0Ykx8vWPi7vTn8t7Oi8Vnuj938qLipDvLCagolc7T1NxqMoSm0hekt/ghWwPm 15YFhq7fKb9LTlSi/WNr7D+rlIfb1onh/GsyjHkSQ8REeT2EeWUP0vrD/h3e0Gjt OUbj8Rjd6KT28S18aQnSkPb4lNk+V53KbBp9/M0Ol/v5snTUDZXFEp2TWJreLbtu k+N8sGAhb8mNerGtJZCrNxWstE8Ful3gZhxM65oTK7mU5TzluZMrozi0GCCZMWx9 WlSraNlR7Jd2Lg==
X-ME-Proxy:      
X-ME-Sender: 
Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 54ADAE4072 for ; Sat,  7 Jul 2018 20:45:19 -0400 (EDT)
Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id D1EFAC2370 for ; Sun,  8 Jul 2018 00:45:16 +0000 (UTC)
Content-Type: multipart/alternative; boundary="===============8729749588331130967=="
MIME-Version: 1.0
From: =?utf-8?q?Github_Notifications?= 
To: quic@ietf.org
Subject: Weekly github digest (QUIC Working Group Specifications)
Message-Id: <20180708004516.D1EFAC2370@cloud.mnot.net>
Date: Sun,  8 Jul 2018 00:45:16 +0000 (UTC)
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Sun, 08 Jul 2018 00:45:25 -0000

--===============8729749588331130967==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Events without label "editorial"

Issues
------
* quicwg/base-drafts (+5/-5/=F0=9F=92=AC34)
  5 issues created:
  - Only Update max_ack_delay for Retransmittable Packets (by nibanks)
    https://github.com/quicwg/base-drafts/issues/1531 =

  - Initial size of dynamic table (by martinthomson)
    https://github.com/quicwg/base-drafts/issues/1530 [-qpack] [design] =

  - HTTP should use APPLICATION_CLOSE, not CONNECTION_CLOSE (by marten-seem=
ann)
    https://github.com/quicwg/base-drafts/issues/1521 =

  - Make EOED transmission optional in QUIC, please (by huitema)
    https://github.com/quicwg/base-drafts/issues/1518 =

  - 0-RTT DCID Routing (by mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1513 =


  11 issues received 34 new comments:
  - #1486 Client's initial destination CID is unauthenticated (8 by kazuho,=
 janaiyengar, martinthomson, mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1486 [-transport] [design] =

  - #1505 Stateless Reset from clients, bis (6 by igorlord, martinthomson, =
mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1505 [-transport] [design] =

  - #1518 Make EOED transmission optional in QUIC, please (5 by martinthoms=
on, ekr, huitema)
    https://github.com/quicwg/base-drafts/issues/1518 [-tls] [design] =

  - #1513 0-RTT DCID Routing (5 by martinthomson, mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1513 [-transport] [design] =

  - #1511 Short header: reserved bits (2 by martinthomson, larseggert)
    https://github.com/quicwg/base-drafts/issues/1511 =

  - #1481 Fragility in ECN counters with lost acks (2 by gloinul, martintho=
mson)
    https://github.com/quicwg/base-drafts/issues/1481 [-recovery] [-transpo=
rt] [design] =

  - #1530 Initial size of dynamic table (2 by martinthomson, MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1530 [-qpack] [design] =

  - #1351 Reorder HTTP frame fields to put Type first (1 by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1351 [-http] =

  - #1016 Split stream initial flow control (1 by martinthomson)
    https://github.com/quicwg/base-drafts/issues/1016 [-transport] [design] =

  - #1458 Coalesced packets and handshake packet limiting (1 by martinthoms=
on)
    https://github.com/quicwg/base-drafts/issues/1458 [-transport] [design] =

  - #446 HOL blocking on Finished (1 by martinthomson)
    https://github.com/quicwg/base-drafts/issues/446 [-tls] [design] [parke=
d] =


  5 issues closed:
  - Greasing for Unidirectional Stream Types https://github.com/quicwg/base=
-drafts/issues/1490 [-http] [design] =

  - Coalesced packets and handshake packet limiting https://github.com/quic=
wg/base-drafts/issues/1458 [-transport] [design] =

  - Short header: reserved bits https://github.com/quicwg/base-drafts/issue=
s/1511 [-transport] [design] =

  - HOL blocking on Finished https://github.com/quicwg/base-drafts/issues/4=
46 [-tls] [design] [parked] =

  - Reorder HTTP frame fields to put Type first https://github.com/quicwg/b=
ase-drafts/issues/1351 [-http] =




Pull requests
-------------
* quicwg/base-drafts (+11/-8/=F0=9F=92=AC10)
  11 pull requests submitted:
  - Describe variable-length integer fields explicitly as variable-length e=
ncoded (by igorlord)
    https://github.com/quicwg/base-drafts/pull/1534 =

  - Optimize definition IP addr in TP PreferredAddress (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1533 =

  - Move HTTP_*PACK_COMPRESSION_FAILED to QPACK (by MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1532 =

  - Application close  (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1528 [-transport] =

  - Tolerate unknown stream types, add greasing (by MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1525 [-http] [design] =

  - Use APPLICATION_CLOSE for hq errors (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1522 =

  - ACK_ECN type value is not incremented (by ami-GS)
    https://github.com/quicwg/base-drafts/pull/1520 =

  - Add cautionary text about PADDING and congestion control (by janaiyenga=
r)
    https://github.com/quicwg/base-drafts/pull/1517 =

  - Fix number agreement: a number _is_ reduced (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1515 =

  - Permit 0-RTT after Retry and VN (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1514 =

  - Tweak TLS API (by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1512 =


  7 pull requests received 10 new comments:
  - #1533 Optimize definition IP addr in TP PreferredAddress (3 by MikeBish=
op, dtikhonov, mikkelfj)
    https://github.com/quicwg/base-drafts/pull/1533 [-transport] [design] =

  - #1359 Unidirectional Stream Headers in HTTP (2 by janaiyengar, LPardue)
    https://github.com/quicwg/base-drafts/pull/1359 [-http] [-qpack] [desig=
n] =

  - #1514 Permit 0-RTT after Retry and VN (1 by mikkelfj)
    https://github.com/quicwg/base-drafts/pull/1514 [-transport] =

  - #1515 Fix number agreement: a number _is_ reduced (1 by martinthomson)
    https://github.com/quicwg/base-drafts/pull/1515 =

  - #1517 Add cautionary text about PADDING and congestion control (1 by ma=
rtinthomson)
    https://github.com/quicwg/base-drafts/pull/1517 =

  - #1520 ACK_ECN type value is not incremented (1 by janaiyengar)
    https://github.com/quicwg/base-drafts/pull/1520 =

  - #1525 Tolerate unknown stream types, add greasing (1 by LPardue)
    https://github.com/quicwg/base-drafts/pull/1525 [-http] [design] =


  8 pull requests merged:
  - Describe variable-length integer fields explicitly as variable-length e=
ncoded
    https://github.com/quicwg/base-drafts/pull/1534 =

  - Tolerate unknown stream types, add greasing
    https://github.com/quicwg/base-drafts/pull/1525 [-http] [design] =

  - ACK_ECN type value is not incremented
    https://github.com/quicwg/base-drafts/pull/1520 =

  - Application close =

    https://github.com/quicwg/base-drafts/pull/1528 [-transport] =

  - Add cautionary text about PADDING and congestion control
    https://github.com/quicwg/base-drafts/pull/1517 =

  - Fix number agreement: a number _is_ reduced
    https://github.com/quicwg/base-drafts/pull/1515 =

  - Add TP disable_migration to the registry
    https://github.com/quicwg/base-drafts/pull/1510 =

  - Fix: octets do not have arbitrary length
    https://github.com/quicwg/base-drafts/pull/1509 =



Repositories tracked by this digest:
-----------------------------------
* https://github.com/quicwg/base-drafts

--===============8729749588331130967==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (QUIC Working Group Specifications)





Sunday July 08, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+5/-5/=F0=9F=92=AC34)

  
5 issues created:

  

  
11 issues received 34 new comments:

  

  
5 issues closed:

  




Pull requests


quicwg/base-drafts (+11/-8/=F0=9F=92=AC10)

  
11 pull requests submitted:

  

  
7 pull requests received 10 new comments:

  

  
8 pull requests merged:

  



Repositories tracked by this digest:





--===============8729749588331130967==--


From nobody Sun Jul  8 04:38:34 2018
Return-Path: 
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 7123B130DEF for ; Sun,  8 Jul 2018 04:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.102
X-Spam-Level: 
X-Spam-Status: No, score=0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 R8bWe835rHSP for ; Sun,  8 Jul 2018 04:38:29 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6612872C for ; Sun,  8 Jul 2018 04:38:28 -0700 (PDT)
Received: from [172.16.58.13] (unknown [207.115.102.243]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 777EB1B001C2; Tue,  3 Jul 2018 12:57:21 +0100 (BST)
Content-Type: multipart/alternative; boundary=Apple-Mail-C5B464CF-8226-4186-BDC8-6FC848F14E44
Mime-Version: 1.0 (1.0)
Subject: Re: Treatment of ICMP for PMTU
From: "Gorry (erg)" 
X-Mailer: iPhone Mail (15E216)
In-Reply-To: <643f80954e6a45ba881c7d4a90a066d0@ustx2ex-dag1mb5.msg.corp.akamai.com>
Date: Tue, 3 Jul 2018 07:57:13 -0400
Cc: Magnus Westerlund , "Eggert, Lars" , IETF QUIC WG , Martin Duke 
Content-Transfer-Encoding: 7bit
Message-Id: <654381A2-8E10-4010-B119-7A1F25137AFF@erg.abdn.ac.uk>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <802647B5-94B5-4C24-BEFA-4B44F5B5E832@netapp.com> <43152ecf9538418ab26c23747c4d1d74@ustx2ex-dag1mb5.msg.corp.akamai.com> <4aef7f4c-327e-9651-80f8-990cc855d627@ericsson.com> <643f80954e6a45ba881c7d4a90a066d0@ustx2ex-dag1mb5.msg.corp.akamai.com>
To: "Lubashev, Igor" 
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Sun, 08 Jul 2018 11:38:32 -0000

--Apple-Mail-C5B464CF-8226-4186-BDC8-6FC848F14E44
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

See below :=20

> On 2 Jul 2018, at 19:19, Lubashev, Igor  wrote:
>=20
> Probe starting at PTB_SIZE or verify Base_MTU and then probe up. =46rom my=
 perspective, the important is that one uses this a signal for checking the P=
MTU.=20

Fine (for me) to say to use as PROBED_SIZE, to trigger an immediate check th=
at this size works.=20

>=20
> =46rom my perspective, there are two things that are important here:
> Use PTB signal to start probing (as you said).  This is section 3.3.
> Identify cases, when you can set PMTU to PTB_SIZE immediately upon receipt=
 of PTB, while the probing is happening.
> =20
> Plus one more thing that is not in that draft at all =E2=80=93 I think it i=
s prudent to respect PTB, even if that PTB is not validated (i.e. w/o on-pat=
h proof, using my lingo), if PTB_SIZE is large enough (to be defined how lar=
ge).  It probably deserves its own thread in tsvwg.

That last part, I  less clear about - and I think we see there are cases whe=
re that may not do what would be best. Please  do feel discuss in tsvwg...

Gorry=20
> =20
> Igor
> =20
> =20
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
> Sent: Monday, July 02, 2018 4:46 AM
> To: Lubashev, Igor ; Eggert, Lars 
> Cc: IETF QUIC WG ; Martin Duke 
> Subject: Re: Treatment of ICMP for PMTU
> =20
> Hi,
>=20
> =20
> Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor:
> =20
>  =E2=80=A2 What to do, when an IPv4 ICMP (w/o on-path proof) request a PMT=
U reduction (after handshake)?
> =20
> Isn't this sufficiently covered in 4821?
> =20
> Not really.  Or, at least I could not find anything more useful there then=
: "If an ICMP PTB message is received matching the probe packet, then search=
_high and eff_pmtu MAY be set from the MTU value indicated in the message." =
 So 4821 seems silent on what to do if ICMP is received for a non-probe pack=
et, and it seems silent on how one could decide whether to set search_high a=
nd eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help h=
ere).  These questions are what I am trying to address for QUIC.
> =20
> 4821 uses MAY in the sentence above, since it does not really give any bet=
ter indication.  This PR draws a distinction between ICMP w/ and w/o on-path=
 proof and in some specific cases, it recommends a SHOULD.
> =20
> =20
> If you look at the updated PLPMTUD:
>=20
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/
>=20
> 3.3.  Reducing the PLPMTU: Confirming Path Characteristics
> =20
>    If the DPLPMTUD method detects that a packet with the PLPMTU size is
>    no supported by the network path, then the DLPMTUD method needs to
>    validate the PLPMTU. This can happen when a validated PTB message is
>    received, or another event that indicates the network path no longer
>    sustains this packet size, such as a loss report from the PL
> =20
>    All implementations of DPLPMTUD are REQUIRED to provide support that
>    reduces the PLPMTU when the actual PMTU supported by a network path
>    is less than the PLPMTU.
>=20
> Section 4.9 says:
>    PROBE_DONE: The PROBE_DONE state indicates a successful end to a
>       probing phase.  DPLPMTUD remains in this state until either the
>       PMTU_RAISE_TIMER expires or a received PTB message is verified.
>=20
> However, I have to say that the draft is a bit unclear on what to do at th=
is point.=20
>=20
> I guess the options are two.
>=20
> Probe starting at PTB_SIZE or verify Base_MTU and then probe up. =46rom my=
 perspective, the important is that one uses this a signal for checking the P=
MTU.=20
>=20
> I will start a thread on TSVWG WG mailing list regarding the lack of speci=
fic text in their draft for this case.
>=20
> Cheers
>=20
> =20
> Magnus Westerlund=20
> =20
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------

--Apple-Mail-C5B464CF-8226-4186-BDC8-6FC848F14E44
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


See below : 

On 2 Jul 2018, at 19:19, Lubashev, Igor <ilubashe=3D40akamai.com@dmarc.ietf.org> w=
rote:











    

  • 
Probe starting at PTB_SIZE or verify Base_MTU an=
d then probe up. =46rom my perspective, the important is that one uses this a=
 signal for checking the PMTU.


Fine (for me) to say to us=
e as PROBED_SIZE, to trigger an immediate check that this size works. <=
div>
  • 

    



=46rom my perspectiv=
e, there are two things that are important here:


    

  1. 
Use PTB signal to start probing (as you said).  This is section 3.3.
  2. 
Identify cases, when you can set PMTU to PTB_SIZE immediately upon receipt o=
f PTB, while the probing is happening.


 


Plus one more thing t=
hat is not in that draft at all =E2=80=93 I think it is prudent to respect P=
TB, even if that PTB is not validated (i.e. w/o on-path proof, using my ling=
o), if PTB_SIZE is large enough (to be defined
 how large).  It probably deserves its own thread in tsvwg.
<=
/div>

That last part, I  less clear about - and I=
 think we see there are cases where that may not do what would be best. Plea=
se  do feel discuss in tsvwg...

Gorry 


 


    

  • 
Igor


 


 






From:<=
span style=3D"color:windowtext"> Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]


Sent: Monday, July 02, 2018 4:46 AM

To: Lubashev, Igor <ilubash=
e@akamai.com>; Eggert, Lars <la=
rs@netapp.com>

Cc: IETF QUIC WG <quic@ietf.org>; Martin Duke <martin.h.=
duke@gmail.com>

Subject: Re: Treatment of ICMP for PMTU






 


Hi, 


 




Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor:<=
/o:p>






 






 =E2=80=A2 What to do, when an IPv4 ICMP (w/o on-path proof) request a P=
MTU reduction (after handshake)?




 


Isn't this sufficiently covered in 4821?




 


Not really.  Or, at least I could not find anything more useful th=
ere then: "If an ICMP PTB message is received matching the probe packet, the=
n search_high and eff_pmtu MAY be set from the MTU value indicated in the me=
ssage."  So 4821 seems silent on what to do if ICMP is received for a n=
on-probe packet, and it seems silent on how one could decide whether to set s=
earch_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not r=
eally help here).  These questions are what I am trying to address for Q=
UIC.


 


4821 uses MAY in the sentence above, since it does not really give any b=
etter indication.  This PR draws a distinction between ICMP w/ and w/o o=
n-path proof and in some specific cases, it recommends a SHOULD.<=
/pre>

 


 




If you look at the upd=
ated PLPMTUD:



https://datatracker.ietf.org/doc/d=
raft-ietf-tsvwg-datagram-plpmtud/


3.3.  Reducing the PLPMTU: Confirming Path Char=
acteristics


 


   If the DPLPMTUD method detects that a packet with the PLPM=
TU size is


   no supported by the network path, then the DLPMTUD method n=
eeds to


   validate the PLPMTU. This can happen when a validated PTB m=
essage is


   received, or another event that indicates the network path=
 no longer


   sustains this packet size, such as a loss report from the P=
L


 


   All implementations of DPLPMTUD are REQUIRED to provide su=
pport that


   reduces the PLPMTU when the actual PMTU supported by a net=
work path


   is less than the PLPMTU.




Section 4.9 says:


   PROBE_DONE: The PROBE_DONE state indicates a successful en=
d to a


      probing phase.  DPLPMTUD remains in=
 this state until either the


      PMTU_RAISE_TIMER expires or a received P=
TB message is verified.




However, I have to say that the draft is a bit unclear on what to do at this=
 point.




I guess the options are two.



Probe starting at PTB_SIZE or verify Base_MTU and then probe up. =46rom my p=
erspective, the important is that one uses this a signal for checking the PM=
TU.




I will start a thread on TSVWG WG mailing list regarding the lack of specifi=
c text in their draft for this case.



Cheers






 


Magnus Westerlund 


 


----------------------------------------------------------------------<=
o:p>


Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------<=
o:p>


Ericsson AB          =
       | Phone  +46 10 7148287=



Torshamnsgatan 23         =
  | Mobile +46 73 0949079


SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


----------------------------------------------------------------------<=
o:p>






=

--Apple-Mail-C5B464CF-8226-4186-BDC8-6FC848F14E44--


From nobody Mon Jul  9 01:03:27 2018
Return-Path: 
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 79F50130E16 for ; Mon,  9 Jul 2018 01:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.091
X-Spam-Level: 
X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=netapp.onmicrosoft.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 WmN1t2hTL07Q for ; Mon,  9 Jul 2018 01:03:07 -0700 (PDT)
Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36271277CC for ; Mon,  9 Jul 2018 01:03:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.51,329,1526367600";  d="asc'?scan'208";a="264540907"
Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx142-out.netapp.com with ESMTP; 09 Jul 2018 01:03:07 -0700
Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 9 Jul 2018 01:03:07 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 9 Jul 2018 01:03:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tcL9LcRUmy97TRmT7sVmZcMCpaF0i4Zp243MzikclaQ=; b=MGgH4Y4kJRKukItglfr8Gp7rEuO6uEjUyx87L4/fPJL/7qQqu4MbR1ZZwct/TxEvJO42xwqXL7IpsTo3Z8Xa1nxZ+1eYS4DGQu+hgepjrcHRsEpN1V7ccAxWRlX7Kc2eeu7ZKVmD5qpKmeXXBkONKgqUlV38iMByXFDn3ZWkFYg=
Received: from BL0PR06MB4676.namprd06.prod.outlook.com (52.132.15.150) by BL0PR06MB4676.namprd06.prod.outlook.com (52.132.15.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Mon, 9 Jul 2018 08:03:05 +0000
Received: from BL0PR06MB4676.namprd06.prod.outlook.com ([fe80::cbc:c3e9:ace4:e56c]) by BL0PR06MB4676.namprd06.prod.outlook.com ([fe80::cbc:c3e9:ace4:e56c%2]) with mapi id 15.20.0930.016; Mon, 9 Jul 2018 08:03:05 +0000
From: "Eggert, Lars" 
To: IETF QUIC WG 
Subject: Academic workshop on QUIC
Thread-Topic: Academic workshop on QUIC
Thread-Index: AQHUF1tEAW8Q+1KXjku08tLSrMqg4A==
Date: Mon, 9 Jul 2018 08:03:05 +0000
Message-ID: <4EFE5C97-5BBB-44C8-A872-C5BE9479ED68@netapp.com>
Reply-To: "Eggert, Lars" , =?iso-8859-1?Q?J=F6rg_Ott?= 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.8.2)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; 
x-originating-ip: [217.70.211.15]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR06MB4676; 7:BBIphF669vg7+QG4E3gmzQ6Flf7oI2NoS73Xd/w5u0aKmwRc4F6CBmMw+z+OkH3rlTqcQoUH3arv6OmnroHdvd/vr/oJXftiBKCAgVoeoT7s0PxgsVHQ4bpOCIOV0OwrD6ZD/XevydHC6Y8k/PDeXv3gLLEAuLlH/TP6AaYf0SxE9ul0HWpqclWxBAIDb0BaDlc1xaNoEvEseqV98oaIStNcmkvKneGA+gkIbpzOg+Mbx4YfPqixbxiRvrSzLV2m
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 8b98d141-668d-4d46-2b2d-08d5e57266e4
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(2017052603328)(49563074)(7193020); SRVR:BL0PR06MB4676; 
x-ms-traffictypediagnostic: BL0PR06MB4676:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BL0PR06MB4676; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4676; 
x-forefront-prvs: 07283408BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(396003)(366004)(39860400002)(189003)(199004)(3846002)(6512007)(6116002)(316002)(102836004)(26005)(3480700004)(86362001)(25786009)(50226002)(6306002)(2906002)(5250100002)(66066001)(82746002)(2900100001)(68736007)(6506007)(99286004)(6486002)(43066004)(6436002)(7736002)(8936002)(33656002)(97736004)(2616005)(186003)(256004)(966005)(476003)(14454004)(53936002)(106356001)(105586002)(486006)(305945005)(6916009)(36756003)(8676002)(57306001)(99936001)(81166006)(81156014)(5660300001)(478600001)(83716003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4676; H:BL0PR06MB4676.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 5lgS1FhqzMtAJbVTpWBI3sb3nQ48oYCsGFuo6NUVUQXoipdjQagvdbtytZghpjupd33CeTQBo4nbyOxKP46xIDMRppL5bA84QkpDJ9D1nOZTpeVjH6GQg88dQeO1a35cQYPrI8KGoC3aHhdUMGmNKc2BYg/Vroev+zRrbbvkBiuBgPHfvd9ibbgozxFEZ+yUfCsmOGRwuN7qDPaSRvwK+fnYtlJMk/ktB1zmI9lAhza+BxVckk57jdeRU/hQ5F15Khywk9wLejfg+Ej2ZoQjYqOZM3aQGoLfbccNWMfG7lbyh18BjejHiTaLGryfUd9rPOVt6MNpqeVM+Crhp71v6rf1QVtVdJ8dFZ3aPZpBKBE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_9FAD8664-7A52-472D-9569-E7A346FF40F5"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b98d141-668d-4d46-2b2d-08d5e57266e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 08:03:05.6223 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4676
X-OriginatorOrg: netapp.com
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 09 Jul 2018 08:03:12 -0000

--Apple-Mail=_9FAD8664-7A52-472D-9569-E7A346FF40F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

if you are doing R&D related to the QUIC protocol, please consider =
submitting your work to the ACM CoNEXT 2018 workshop on the Evolution, =
Performance, and Interoperability of QUIC (EPIQ).

EPIQ solicits two types of submissions for presentation and discussion =
at the workshop: academic papers and posters&demos. See =
https://conferences2.sigcomm.org/co-next/2018/#!/workshop-epiq for =
details.

Lars

--Apple-Mail=_9FAD8664-7A52-472D-9569-E7A346FF40F5
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAltDFrkACgkQVLXDCb9w
wVeV6hAA0oFITxxO4Gk2skPsDFhJK8eCYM62QrtAJFLzv5sQA5mgm//NiiVoxVot
S6sdvcCjpzZunRbBhGcZYGMQCwYWkC+0HljUNScctB8j9109wDT0TJf+s1lbiVQj
VKF6iqJqEXw7Oz3BqBK+jAr6cHgkdodCHawsyi4NqsaRNwABy2cnxvHAXhFWRYZm
lMOd5xksczM+c778uUlyfHWjG+9024qPHhVKA9mOMnJju938BbA61cE29qjmhbEL
Uk5B06LVShlF3Hn3brS9WaDa+rtBZ2sTRK9Y91ZLSLErDV5WQYo7MsyVRET/wMrJ
mGLDBQ2YYFgIXKt5G57pLcg9MnMbRKYShQ28+ODVJZPcoHgposUsoj2c2fTuzabI
wTvynVXJY3yqdOgkUI1W+PBUowQ6Q+DtENNBT+C7b9ld1cdPIbM8t/8Rxh5px27v
AOMasaMFa7LpGqm3K7f3QFTA67QKM6zXdcFb9E4nHBNGi9AeiP7ngKYxUJKkgAU3
Z3JtsqAYuVkjzLXOqRk12jDkyj/kzq88wIdq8Izore1LzduOvxp3fR4s7+btUeil
eKxQvQPMuotO/0YBEsQ13vgnKLP3+gNyZZF1q8RL23zFiT6zjOJBdLsa0sVilFv0
bfNqo9xtjhmrZy2+v9CG6ZXSD2+c98oU7a/WBjHz9Le+EbXz2B0=
=DbL7
-----END PGP SIGNATURE-----

--Apple-Mail=_9FAD8664-7A52-472D-9569-E7A346FF40F5--


From nobody Mon Jul  9 01:04:24 2018
Return-Path: 
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 ECFAE130E12 for ; Mon,  9 Jul 2018 01:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 ksaZ-JQNQTUy for ; Mon,  9 Jul 2018 01:04:19 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66FB1277CC for ; Mon,  9 Jul 2018 01:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531123456; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RMkg9FB8ELLDwK4iB4C6ESq83YLZ9jrDWDciXzuJqG8=; b=QDuhoQhvbYkzVmcdxdlDrS0Ru9FYgJ4rZo4RkIpWOq1xIR8vM3IhKIzP+/o9DlfP TZ3Lmfm+SL1TX9oMz5FKtpEqGnTIkCQvVremdtY2jsc7pksT9wSmlygS0Ki9TbFl yeb/0FZL5gHiA54Z5t7VUMjXcENm0BZYGP3g8YlgT3U=;
X-AuditID: c1b4fb3a-dcb6e9c0000079c1-44-5b4317002b44
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.92.31169.007134B5; Mon,  9 Jul 2018 10:04:16 +0200 (CEST)
Received: from [147.214.163.97] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 9 Jul 2018 10:04:16 +0200
To: IETF QUIC WG 
From: Magnus Westerlund 
Subject: ECN summary to TSVWG
Message-ID: <5d6aaca2-84b7-1325-b77e-ebc828da0568@ericsson.com>
Date: Mon, 9 Jul 2018 10:04:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-Originating-IP: [153.88.183.153]
X-ClientProxiedBy: ESESSMB503.ericsson.se (153.88.183.164) To ESESSMB502.ericsson.se (153.88.183.163)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM2J7hS6DuHO0wbuL1hY9C7gdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJVx9nk/Y0Eze8Xr+V2MDYzPWLsYOTkkBEwkfu2exNjFyMUhJHCU UWLbhy4mCOc9o8TfNdvZuxg5OEQEFCTWNHCCNLAJWEjc/NHIBhIWFpCV2PpXGSTMK2Av8ez3 JHYQm0VARWJl4x8WEFtUIEZi5ebXbBA1ghInZz5hAWllBqp/sLUMJMwsIC+x/e0cZghbXKLp y0qw04QEtCUamjqgzlSSuD7vOguEnS4x7ekapgmMArOQTJ2FMHUWkqmzkExdwMiyilG0OLW4 ODfdyEgvtSgzubg4P08vL7VkEyMwJA9u+W21g/Hgc8dDjAIcjEo8vFt4nKOFWBPLiitzDzFK cDArifAmWjlFC/GmJFZWpRblxxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5NLUgtgskycXBK NTBOWJPbFLKzLURIV/Qap2/9gicP3qY8jG35+TU3icNwGZ+npnhmepbHVkNTvvze2ZyfxQ7u 4gpbf2x9rdvBUMc13K6+HYEhpyemhoRJ3o6smMvho9UvIHsrSdnj3OsVV9LKZxlFlbz2f3e8 Vn/exEIe/9NvpvD9PDpJrkBf7syc7999w5pPmSuxFGckGmoxFxUnAgCO+M4ARQIAAA==
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 09 Jul 2018 08:04:22 -0000

QUIC WG,

I did a personal summary of what I think are some open questions and 
experience learnt in the ECN in QUIC work so far and posted that to the 
TSVWG mailing list.

https://mailarchive.ietf.org/arch/msg/tsvwg/80Y2qVPn4M2_bp9U2mYEMvf9-UA

David Black has provided the first feedback on this.

I also requested some agenda time to inform and solicit feedback to
these questions in TSVWG on Thursday.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Mon Jul  9 17:47:44 2018
Return-Path: 
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 6236B127148 for ; Mon,  9 Jul 2018 17:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level: 
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UVAEplGWnEWb for ; Mon,  9 Jul 2018 17:47:40 -0700 (PDT)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 59B32130DD6 for ; Mon,  9 Jul 2018 17:47:40 -0700 (PDT)
Received: by mail-yb0-x230.google.com with SMTP id s1-v6so7955101ybk.3 for ; Mon, 09 Jul 2018 17:47:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AoZqM5+P8AGlqZ/MRvYS8rjDmv2p9lItDw1dKkuJotc=; b=bNbsjsvxKXPN7v47b/CnIk1JOS7s1u3cgkV4UM8nL8ZUEfLS+afsTDSa4Zx3RRvVMF sz7LgCXegXJYgdw8WdWcR+GUXbvZ7lWk0PpQhIhfpQBxeoR4H9BAYUS7hsX9CwzVB/Br yrHk4Us8Wrjp4V4uKBYiD7mgw4SH0QGUM4pdDKZdYpbIgXfnr06zC7gWT8aIUasBLhWg 3XHBdx35EMXsX5jBBZNTuAA1GfHrSdoSCGsu5ghLIki0BvgVJBLeUHz/uL0hrMr+1fll K8RO599OLH2Nh5WBPYldIOWndeYLrRzo2sL2dRC6icKNdzh33iCRa8zODRRLtFJdjzfL WYVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AoZqM5+P8AGlqZ/MRvYS8rjDmv2p9lItDw1dKkuJotc=; b=GxlG8SlsAoNUGGU+L5ESDxJQQ129s9O5EQIcpr1JIK0l0Zjfp2Na8YZdCLiRtZ5ukb eAnHkZAJpIdZKUF5ex7ZXBA53m8FLvKggUy6ZL/kMf+GcQliNDaZxuvLS36DHmeIU7CJ 2ZSpeZyKseix74cQO5rMR2i6dqjSGG7zYP3oaGuKccOfnRdon3Mhnst9JDwSzCfIX4NQ r954TPPL8cUc4W/c1tRXkmfuagnlY56jTd8R/3ghPICvFVUneYNHtrq+mxBtL/LY1QD1 lQ7ERMOEckGjFihH1nVV0K9Sabg1+OdGlsZ8YzW+SmH5yEQXEWqgXXhmYbAoV7Neyf0Y RJKQ==
X-Gm-Message-State: APt69E3W2JyIwSjnCRoGLesEc6M1XcJa8UeAVpow9Xwb3jR9ztaBWz0D NVSFtUvgAbrf8TkGTF0rDDNJhtvApQTigOIbIsVYGKVn
X-Google-Smtp-Source: AAOMgpfYvcNSnEYIgReW4lHl+VSQLdxqyLHGRumiwaLiJqcLcWZhkteqoT8gU+Fz62lw29PbHDoab+HwSSnl+rEt05A=
X-Received: by 2002:a25:b3c1:: with SMTP id x1-v6mr11864488ybf.241.1531183659321;  Mon, 09 Jul 2018 17:47:39 -0700 (PDT)
MIME-Version: 1.0
References:  <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>   
In-Reply-To: 
From: Ian Swett 
Date: Mon, 9 Jul 2018 20:47:28 -0400
Message-ID: 
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: pravb=40microsoft.com@dmarc.ietf.org,  "Lubashev, Igor" , Kazuho Oku , IETF QUIC WG , Christian Huitema 
Content-Type: multipart/alternative; boundary="0000000000001a5f2e05709a7a55"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 10 Jul 2018 00:47:43 -0000

--0000000000001a5f2e05709a7a55
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This has been discussed on and off for a few years now, even prior to the
IETF process.  It's never been clear that adding a frame for this purpose,
or altering the behavior of an existing frame(ie: PING or STREAM) is
valuable.

I'm about to start an experiment to send an ACK more quickly(ie: 1ms delay)
if it's been over an RTT since an ACK has been sent, which may help, but is
largely aimed at the TLP and RTO use cases.  One use case that's been
discussed is sending a fast ack frame/signal when entering an app-limited
phase.  This seems fairly promising to me, but I have no experimental
evidence it actually helps.

One option would be to recommend sending an ACK quickly in response to a
PING, unless a PING has been acked within the last RTT.  This would provide
a natural rate-limit to immediate ACKs.


On Sun, Jul 1, 2018 at 1:20 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen 
wrote:

> On 1 July 2018 at 18..32.56, Praveen Balasubramanian (
> pravb=3D40microsoft.com@dmarc.ietf.org) wrote:
>
> Doesn=E2=80=99t the PING frame serves this purpose? The language in the t=
ransport
> draft isn=E2=80=99t very clear:
> The receiver of a PING frame simply needs to acknowledge the packet
> containing this frame.
>
>
>
> No, I asked for this several times, but there was no traction. It is
> ACK=E2=80=99ed as any packet which the consensus considers soon enough. B=
ut I dont=E2=80=99
> think this takes into account use cases with delayed ACK and congestion
> algorithms that can tolerate longer delays.
>
> It=E2=80=99s simply useful to ping in order to get a roundtrip time on th=
e
> connection, aside from what has already been mentioned.
>

--0000000000001a5f2e05709a7a55
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This has been discussed on and off for a few years no=
w, even prior to the IETF process.=C2=A0 It's never been clear that add=
ing a frame for this purpose, or altering the behavior of an existing frame=
(ie: PING or STREAM) is valuable.

I'm about to=
 start an experiment to send an ACK more quickly(ie: 1ms delay) if it's=
 been over an RTT since an ACK has been sent, which may help, but is largel=
y aimed at the TLP and RTO use cases.=C2=A0 One use case that's been di=
scussed is sending a fast ack frame/signal when entering an app-limited pha=
se.=C2=A0 This seems fairly promising to me, but I have no experimental evi=
dence it actually helps.

One option would be to re=
commend sending an ACK quickly in response to a PING, unless a PING has bee=
n acked within the last RTT.=C2=A0 This would provide a natural rate-limit =
to immediate ACKs.


On Sun, Jul 1, 2018 at 1:20 PM Mikkel Fahn=C3=B8e J=C3=B8=
rgensen <mikkelfj@gmail.com>=
; wrote:
On 1 July 2018 at 18..32.56, Pra=
veen Balasubramanian (pravb=3D40microsoft.com@dmarc.ietf.org) wrote: 
Doesn=E2=80=99t the PING frame serves this purpose? Th=
e language in the transport draft isn=E2=80=99t very clear:=C2=A0
The receiver of a PING frame simpl=
y needs to acknowledge the packet containing this frame.=C2=A0
<=
/blockquote>


No, I asked for this several times, but there was no traction. It is ACK=
=E2=80=99ed as any packet which the consensus considers soon enough. But I =
dont=E2=80=99 think this takes into account use cases with delayed ACK and =
congestion algorithms that can tolerate longer delays.

=

It=E2=80=99s simply useful to ping in order to get a roundtrip time on=
 the connection, aside from what has already been mentioned.




--0000000000001a5f2e05709a7a55--


From nobody Mon Jul  9 21:56:23 2018
Return-Path: 
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 3370B130DDB for ; Mon,  9 Jul 2018 21:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ddr9W6iHYfGG for ; Mon,  9 Jul 2018 21:56:20 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2605E130EF8 for ; Mon,  9 Jul 2018 21:56:19 -0700 (PDT)
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2E2522786CF for ; Tue, 10 Jul 2018 13:56:18 +0900 (JST)
Received: by mail-it0-f54.google.com with SMTP id y124-v6so13749336itc.0 for ; Mon, 09 Jul 2018 21:56:18 -0700 (PDT)
X-Gm-Message-State: APt69E1s3obYtpkFBEZZpJwuJV+iOPj+K9hRv8veANP2z5rpNra57VPB yEhSxIw9nyl1Cvzwkvb63mDfttHbGjij02f5c/k=
X-Google-Smtp-Source: AAOMgpeTp1aPuZgifSn9iq30pVt9uC+g3D2ynp4zTRQYONA72XKr6qubwm8qe6TZDqxvVfsi9uSbVFHyAyCcpjRhpeY=
X-Received: by 2002:a24:7893:: with SMTP id p141-v6mr9839304itc.20.1531198574069;  Mon, 09 Jul 2018 21:56:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 21:56:13 -0700 (PDT)
In-Reply-To: 
References:  <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>    
From: Yoshifumi Nishida 
Date: Mon, 9 Jul 2018 21:56:13 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: Ian Swett 
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  pravb=40microsoft.com@dmarc.ietf.org, "Lubashev, Igor" ,  Christian Huitema , IETF QUIC WG , Kazuho Oku 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 10 Jul 2018 04:56:23 -0000

On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett
 wrote:
> This has been discussed on and off for a few years now, even prior to the
> IETF process.  It's never been clear that adding a frame for this purpose,
> or altering the behavior of an existing frame(ie: PING or STREAM) is
> valuable.
>
> I'm about to start an experiment to send an ACK more quickly(ie: 1ms delay)
> if it's been over an RTT since an ACK has been sent, which may help, but is
> largely aimed at the TLP and RTO use cases.  One use case that's been
> discussed is sending a fast ack frame/signal when entering an app-limited
> phase.  This seems fairly promising to me, but I have no experimental
> evidence it actually helps.

If it's mainly aimed at the TLP and RTO, I'm not very sure if this is
really effective.
For TLP and RTO cases, I guess the speed will depend on how fast
sender sends a probe packet (while avoiding redundancy) rather than
how fast receiver sends an ack.
--
Yoshi


From nobody Tue Jul 10 06:54:23 2018
Return-Path: 
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 1CF72130EE3 for ; Tue, 10 Jul 2018 06:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level: 
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ukB0kBYL7fS6 for ; Tue, 10 Jul 2018 06:54:20 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 1241E130ED8 for ; Tue, 10 Jul 2018 06:54:20 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id j68-v6so7851494ywg.1 for ; Tue, 10 Jul 2018 06:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uqqaOIb1EefjdhSMsj4Z+ts8NWLF6kN5vXqrAT+2dr0=; b=kF4aon83lNejsGCOLL1FKfZ21NGQO/GQJsrljtLlBl+v3B1ik/rMa5Rk5Nnvjgzdu3 yAM32SvUssdfAhbPtGqKwanIHvHaDq0+372reXY853/SPXAilLiF+HBkmpnZeQPBz7gc ET2CZFQ8+tkAGuSuf1ZgjCVJRE7pFLQ2ACW1SvKdJb7r0/4SoHvuhhOt0CgHKol6yWVv 1iGID6MRoL+nlNcNa59u1LBW25Aw58N53yWhleWlOKpL52rIOFex3XlOb3E3MyF/TE2J W9Fu02aA7M0Gg2TyM18A16e1XPlQt3Zj89/jbyVsEsRin0+WbQpAa4K08++cCGyKhQit 8Nlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uqqaOIb1EefjdhSMsj4Z+ts8NWLF6kN5vXqrAT+2dr0=; b=bz99MZX8T9T5ZoQqcYRAs3XiNujHxy8H3eu+njK2e4HDrTUlsNHkU8em5/XliHEmbd WYA5B7+Rv8sn93X0TCJyilGIz7/TU06/C/zwRmh06HeVj5ZioxL7P4WnszMpxg3QQ989 KiC54xn492t1fq0FcL8yMJ0Uj0iNgGFTQiTyskAPa0da7BsEHtx2MKgR/+Ch7abTiXQ4 xGNoux87vYTH+XOuHYgOzBLqx8Nd9fYm9V3604eZioTdjoRK54VoY+xWWYt5X463jIFN HzYMFHXGIHgD3TPpxKIwTm83x+xMu1WAYu5o2GFZY7p7DYj5kzy0rAi8tYGM4bU09tG4 cZog==
X-Gm-Message-State: APt69E0KqkK8CubVrxiSE0La4vyPxKgwq2GnhgrtkECZMnL9hbeVSLPG 5GdSDrkuRRBGCj19dgUPTOm9lBPoukc3MrpbwnW92Q==
X-Google-Smtp-Source: AAOMgpeZEQrSgB183e5YEa5q1JgARh9kqfa/2NneDzyYHq98Uj1KGINQGnoj7GKDThSAFv5+K8oG27vmFKntGuvCN6g=
X-Received: by 2002:a81:b3c1:: with SMTP id r184-v6mr12121403ywh.173.1531230858991;  Tue, 10 Jul 2018 06:54:18 -0700 (PDT)
MIME-Version: 1.0
References:  <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>     
In-Reply-To: 
From: Ian Swett 
Date: Tue, 10 Jul 2018 09:54:07 -0400
Message-ID: 
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: nishida@sfc.wide.ad.jp
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  Praveen Balasubramanian , "Lubashev, Igor" ,  Christian Huitema , IETF QUIC WG , Kazuho Oku 
Content-Type: multipart/alternative; boundary="0000000000006bdc5c0570a57773"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 10 Jul 2018 13:54:22 -0000

--0000000000006bdc5c0570a57773
Content-Type: text/plain; charset="UTF-8"

To summarize my current thinking: I'd like to add/change something in QUIC
that allows experimentation in this space.  Ideally this would be in the
near future(before v1), so we can understand if it's valuable and provide a
well-reasoned recommendation in the recovery doc.

The fast ACK after PING approach seems simple enough to me, but I'm open to
other suggestions as well.

On Tue, Jul 10, 2018 at 12:56 AM Yoshifumi Nishida 
wrote:

> On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett
>  wrote:
> > This has been discussed on and off for a few years now, even prior to the
> > IETF process.  It's never been clear that adding a frame for this
> purpose,
> > or altering the behavior of an existing frame(ie: PING or STREAM) is
> > valuable.
> >
> > I'm about to start an experiment to send an ACK more quickly(ie: 1ms
> delay)
> > if it's been over an RTT since an ACK has been sent, which may help, but
> is
> > largely aimed at the TLP and RTO use cases.  One use case that's been
> > discussed is sending a fast ack frame/signal when entering an app-limited
> > phase.  This seems fairly promising to me, but I have no experimental
> > evidence it actually helps.
>
> If it's mainly aimed at the TLP and RTO, I'm not very sure if this is
> really effective.
> For TLP and RTO cases, I guess the speed will depend on how fast
> sender sends a probe packet (while avoiding redundancy) rather than
> how fast receiver sends an ack.
> --
> Yoshi
>

--0000000000006bdc5c0570a57773
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


To summarize my current thinking: I'd like to add/chan=
ge something in QUIC that allows experimentation in this space.=C2=A0 Ideal=
ly this would be in the near future(before v1), so we can understand if it&=
#39;s valuable and provide a well-reasoned recommendation in the recovery d=
oc.

The fast ACK after PING approach seems simple enough=
 to me, but I'm open to other suggestions as well.

On Tue, Jul 10, 2018 at 12:56 AM Yos=
hifumi Nishida <nishida@sfc.wi=
de.ad.jp> wrote:
On Mon, Jul=
 9, 2018 at 5:47 PM, Ian Swett

<ianswett=3D40google.com@dmarc.ietf.org> wrote:

> This has been discussed on and off for a few years now, even prior to =
the

> IETF process.=C2=A0 It's never been clear that adding a frame for =
this purpose,

> or altering the behavior of an existing frame(ie: PING or STREAM) is
> valuable.

>

> I'm about to start an experiment to send an ACK more quickly(ie: 1=
ms delay)

> if it's been over an RTT since an ACK has been sent, which may hel=
p, but is

> largely aimed at the TLP and RTO use cases.=C2=A0 One use case that=
9;s been

> discussed is sending a fast ack frame/signal when entering an app-limi=
ted

> phase.=C2=A0 This seems fairly promising to me, but I have no experime=
ntal

> evidence it actually helps.



If it's mainly aimed at the TLP and RTO, I'm not very sure if this =
is

really effective.

For TLP and RTO cases, I guess the speed will depend on how fast

sender sends a probe packet (while avoiding redundancy) rather than

how fast receiver sends an ack.

--

Yoshi




--0000000000006bdc5c0570a57773--


From nobody Tue Jul 10 09:15:44 2018
Return-Path: 
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 85162131008 for ; Tue, 10 Jul 2018 09:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 Jjf6vUTPj6oU for ; Tue, 10 Jul 2018 09:15:35 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0101.outbound.protection.outlook.com [104.47.36.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C46B131012 for ; Tue, 10 Jul 2018 09:15:34 -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=VQiBW/TzpJb+zUhkF0zTz+F2BFpOxlsL661ZjtUIJII=; b=k/yGNR9Ba+GOQbLVbxWidxDXMO5qbtqKrFGu44oIXIxb4TL6lLK8BR1acAhynUdIH1RYrYP0yGYekar5P7bMCpn4cAZmgLamFiaQUf7iirrdmXAyBG0ZK+8K3yPyF+DOiI0l2hmWA/SiGcfw63K1efL+DWvtcaMfnadBQey1Mlk=
Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0639.namprd21.prod.outlook.com (10.175.141.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.6; Tue, 10 Jul 2018 16:15:32 +0000
Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::9433:e5c:b9af:1b72]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::9433:e5c:b9af:1b72%9]) with mapi id 15.20.0952.017; Tue, 10 Jul 2018 16:15:32 +0000
From: Praveen Balasubramanian 
To: Ian Swett , "nishida@sfc.wide.ad.jp" 
CC: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Lubashev, Igor" , huitema , IETF QUIC WG , Kazuho Oku 
Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)
Thread-Topic: Speeding up tail loss detection (Re: Congestion control algorithm questions)
Thread-Index: AQHUECByHqG/zftGOUq9fkJj1zXpE6R4KKgAgAJn9ICAAAA6YIAADpYAgA0PegCAAEWAgIAAlkmAgAAm+6A=
Date: Tue, 10 Jul 2018 16:15:31 +0000
Message-ID: 
References:  <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:2:f034:4043:b2ae:fd53]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0639; 7:jbk3QVyZ7SadpC4V6/Qqf382kaK8MOx1Mm+eSF5xMO9YQOYMciPPUvVagAVRIXqJqE2MwF6SK9lVWUvNZSe8TJxEzQm9s3PbiJ/+HIF4pwwBNumIicjLrxBiCB7nwYW1N93coDrILqeqdD9uXQmwOnyPZlxzm2vL4IC6S6Kh09KUjQEOxzLxUh95mtwUgq+przJIuQvfn4ytM/08uy5V5EmpvB83Vo1A0mkKqrvGyUzdPgEK/Exhuq+6bkibNnS9
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: dd7596a7-ac0e-4ca3-dfaa-08d5e6805c40
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:MWHPR21MB0639; 
x-ms-traffictypediagnostic: MWHPR21MB0639:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; 
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(211936372134217)(21748063052155);
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)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR21MB0639; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0639; 
x-forefront-prvs: 0729050452
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(136003)(366004)(376002)(39860400002)(346002)(189003)(199004)(51854002)(7696005)(86362001)(2501003)(53546011)(4326008)(6506007)(6246003)(76176011)(46003)(102836004)(25786009)(53936002)(256004)(105586002)(93886005)(22452003)(316002)(97736004)(10090500001)(54906003)(14444005)(110136005)(86612001)(186003)(99286004)(2900100001)(106356001)(5250100002)(39060400002)(8936002)(10290500003)(2906002)(476003)(790700001)(229853002)(68736007)(6116002)(478600001)(33656002)(446003)(9686003)(81156014)(8676002)(81166006)(236005)(19609705001)(7736002)(14454004)(6436002)(55016002)(6306002)(54896002)(8990500004)(11346002)(5660300001)(74316002)(486006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0639; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 9YT0Sjd3DllX1PurkoOBICDadlDHoXZku7/jriZ/SW80MpROsiLpOmKicKgG+rHHjqTMtJT8ZYMXSQtk9xGYCz6a9GBc+NzJCK4JvwRn5/lhFZWRCCydoqD8csCwPgs87untQ/pW7KwuBM7PQ3pP/x8kAhS3U5y0qjwuGpAfpYiCapCl284Ilp+aEZNYpWEE/fRq3O7yFGMryWXifMHsFb/6pwRtnU4fkxBbMoJP/+tCjwe+3K+/JVjGLFzA58HWoVIRCftc75ZW6Y7hl6AdS1Gz/17wJIeQCM/hsGxcB5iUNHGqR9F7R+aaN8HtMH8fnMRH+radWo6byPSKveN990rZP3DM7gDLd+URVusutFw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0191444EDC54BDB409AF728AB65B0MWHPR21MB0191namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd7596a7-ac0e-4ca3-dfaa-08d5e6805c40
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 16:15:31.9860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0639
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 10 Jul 2018 16:15:39 -0000

--_000_MWHPR21MB0191444EDC54BDB409AF728AB65B0MWHPR21MB0191namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmVxdWlyaW5nIGltbWVkaWF0ZSAobm90IGV4cGxpY2l0bHkgZGVsYXllZCkgQUNLIGZvciBQSU5H
IGZyYW1lIGF0IGxlYXN0IG9uY2UgcGVyIFJUVCAob3IgZXZlbiBhbHdheXMpIHNlZW1zIGZpbmUg
dG8gbWUuIEluIHRoZSBjcnVjaWFsIHJlY292ZXJ5IGNhc2VzIFRMUCB3aWxsIGJlIG91dCBvZiBv
cmRlciBhbmQgd2lsbCBlbGljaXQgYW4gaW1tZWRpYXRlIEFDSyBhbnl3YXlzLiBJZiB0aGVyZSBh
cmUgd2F5cyB0byBzcGVlZCB1cCByZWNvdmVyeSBsZXTigJlzIGV4cGVyaW1lbnQgYW5kIGJyaW5n
IHRoZW0gdG8gdGhlIGRyYWZ0LCB0aGV5IG1pZ2h0IGhlbHAgVENQIGFzIHdlbGwuDQoNCkZyb206
IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dDQpTZW50OiBUdWVzZGF5LCBK
dWx5IDEwLCAyMDE4IDY6NTQgQU0NClRvOiBuaXNoaWRhQHNmYy53aWRlLmFkLmpwDQpDYzogTWlr
a2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPjsgUHJhdmVlbiBCYWxh
c3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBMdWJhc2hldiwgSWdvciA8aWx1YmFz
aGVAYWthbWFpLmNvbT47IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBJRVRGIFFVSUMg
V0cgPHF1aWNAaWV0Zi5vcmc+OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KU3Vi
amVjdDogUmU6IFNwZWVkaW5nIHVwIHRhaWwgbG9zcyBkZXRlY3Rpb24gKFJlOiBDb25nZXN0aW9u
IGNvbnRyb2wgYWxnb3JpdGhtIHF1ZXN0aW9ucykNCg0KVG8gc3VtbWFyaXplIG15IGN1cnJlbnQg
dGhpbmtpbmc6IEknZCBsaWtlIHRvIGFkZC9jaGFuZ2Ugc29tZXRoaW5nIGluIFFVSUMgdGhhdCBh
bGxvd3MgZXhwZXJpbWVudGF0aW9uIGluIHRoaXMgc3BhY2UuICBJZGVhbGx5IHRoaXMgd291bGQg
YmUgaW4gdGhlIG5lYXIgZnV0dXJlKGJlZm9yZSB2MSksIHNvIHdlIGNhbiB1bmRlcnN0YW5kIGlm
IGl0J3MgdmFsdWFibGUgYW5kIHByb3ZpZGUgYSB3ZWxsLXJlYXNvbmVkIHJlY29tbWVuZGF0aW9u
IGluIHRoZSByZWNvdmVyeSBkb2MuDQoNClRoZSBmYXN0IEFDSyBhZnRlciBQSU5HIGFwcHJvYWNo
IHNlZW1zIHNpbXBsZSBlbm91Z2ggdG8gbWUsIGJ1dCBJJ20gb3BlbiB0byBvdGhlciBzdWdnZXN0
aW9ucyBhcyB3ZWxsLg0KDQpPbiBUdWUsIEp1bCAxMCwgMjAxOCBhdCAxMjo1NiBBTSBZb3NoaWZ1
bWkgTmlzaGlkYSA8bmlzaGlkYUBzZmMud2lkZS5hZC5qcDxtYWlsdG86bmlzaGlkYUBzZmMud2lk
ZS5hZC5qcD4+IHdyb3RlOg0KT24gTW9uLCBKdWwgOSwgMjAxOCBhdCA1OjQ3IFBNLCBJYW4gU3dl
dHQNCjxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29vZ2xl
LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KPiBUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBv
biBhbmQgb2ZmIGZvciBhIGZldyB5ZWFycyBub3csIGV2ZW4gcHJpb3IgdG8gdGhlDQo+IElFVEYg
cHJvY2Vzcy4gIEl0J3MgbmV2ZXIgYmVlbiBjbGVhciB0aGF0IGFkZGluZyBhIGZyYW1lIGZvciB0
aGlzIHB1cnBvc2UsDQo+IG9yIGFsdGVyaW5nIHRoZSBiZWhhdmlvciBvZiBhbiBleGlzdGluZyBm
cmFtZShpZTogUElORyBvciBTVFJFQU0pIGlzDQo+IHZhbHVhYmxlLg0KPg0KPiBJJ20gYWJvdXQg
dG8gc3RhcnQgYW4gZXhwZXJpbWVudCB0byBzZW5kIGFuIEFDSyBtb3JlIHF1aWNrbHkoaWU6IDFt
cyBkZWxheSkNCj4gaWYgaXQncyBiZWVuIG92ZXIgYW4gUlRUIHNpbmNlIGFuIEFDSyBoYXMgYmVl
biBzZW50LCB3aGljaCBtYXkgaGVscCwgYnV0IGlzDQo+IGxhcmdlbHkgYWltZWQgYXQgdGhlIFRM
UCBhbmQgUlRPIHVzZSBjYXNlcy4gIE9uZSB1c2UgY2FzZSB0aGF0J3MgYmVlbg0KPiBkaXNjdXNz
ZWQgaXMgc2VuZGluZyBhIGZhc3QgYWNrIGZyYW1lL3NpZ25hbCB3aGVuIGVudGVyaW5nIGFuIGFw
cC1saW1pdGVkDQo+IHBoYXNlLiAgVGhpcyBzZWVtcyBmYWlybHkgcHJvbWlzaW5nIHRvIG1lLCBi
dXQgSSBoYXZlIG5vIGV4cGVyaW1lbnRhbA0KPiBldmlkZW5jZSBpdCBhY3R1YWxseSBoZWxwcy4N
Cg0KSWYgaXQncyBtYWlubHkgYWltZWQgYXQgdGhlIFRMUCBhbmQgUlRPLCBJJ20gbm90IHZlcnkg
c3VyZSBpZiB0aGlzIGlzDQpyZWFsbHkgZWZmZWN0aXZlLg0KRm9yIFRMUCBhbmQgUlRPIGNhc2Vz
LCBJIGd1ZXNzIHRoZSBzcGVlZCB3aWxsIGRlcGVuZCBvbiBob3cgZmFzdA0Kc2VuZGVyIHNlbmRz
IGEgcHJvYmUgcGFja2V0ICh3aGlsZSBhdm9pZGluZyByZWR1bmRhbmN5KSByYXRoZXIgdGhhbg0K
aG93IGZhc3QgcmVjZWl2ZXIgc2VuZHMgYW4gYWNrLg0KLS0NCllvc2hpDQo=

--_000_MWHPR21MB0191444EDC54BDB409AF728AB65B0MWHPR21MB0191namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S
ZXF1aXJpbmcgaW1tZWRpYXRlIChub3QgZXhwbGljaXRseSBkZWxheWVkKSBBQ0sgZm9yIFBJTkcg
ZnJhbWUgYXQgbGVhc3Qgb25jZSBwZXIgUlRUIChvciBldmVuIGFsd2F5cykgc2VlbXMgZmluZSB0
byBtZS4gSW4gdGhlIGNydWNpYWwgcmVjb3ZlcnkgY2FzZXMgVExQIHdpbGwgYmUgb3V0IG9mIG9y
ZGVyIGFuZCB3aWxsIGVsaWNpdCBhbiBpbW1lZGlhdGUgQUNLIGFueXdheXMuIElmIHRoZXJlIGFy
ZSB3YXlzDQogdG8gc3BlZWQgdXAgcmVjb3ZlcnkgbGV04oCZcyBleHBlcmltZW50IGFuZCBicmlu
ZyB0aGVtIHRvIHRoZSBkcmFmdCwgdGhleSBtaWdodCBoZWxwIFRDUCBhcyB3ZWxsLjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRA
Z29vZ2xlLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bHkgMTAsIDIwMTggNjo1
NCBBTTxicj4NCjxiPlRvOjwvYj4gbmlzaGlkYUBzZmMud2lkZS5hZC5qcDxicj4NCjxiPkNjOjwv
Yj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozsg
UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBMdWJh
c2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IGh1aXRlbWEgJmx0O2h1aXRl
bWFAaHVpdGVtYS5uZXQmZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBL
YXp1aG8gT2t1ICZsdDtrYXp1aG9va3VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogU3BlZWRpbmcgdXAgdGFpbCBsb3NzIGRldGVjdGlvbiAoUmU6IENvbmdlc3Rpb24gY29u
dHJvbCBhbGdvcml0aG0gcXVlc3Rpb25zKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VG8gc3VtbWFyaXplIG15IGN1cnJlbnQgdGhpbmtpbmc6IEknZCBsaWtlIHRvIGFkZC9jaGFuZ2Ug
c29tZXRoaW5nIGluIFFVSUMgdGhhdCBhbGxvd3MgZXhwZXJpbWVudGF0aW9uIGluIHRoaXMgc3Bh
Y2UuJm5ic3A7IElkZWFsbHkgdGhpcyB3b3VsZCBiZSBpbiB0aGUgbmVhciBmdXR1cmUoYmVmb3Jl
IHYxKSwgc28gd2UgY2FuIHVuZGVyc3RhbmQgaWYgaXQncyB2YWx1YWJsZSBhbmQgcHJvdmlkZSBh
IHdlbGwtcmVhc29uZWQNCiByZWNvbW1lbmRhdGlvbiBpbiB0aGUgcmVjb3ZlcnkgZG9jLjxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZhc3QgQUNLIGFm
dGVyIFBJTkcgYXBwcm9hY2ggc2VlbXMgc2ltcGxlIGVub3VnaCB0byBtZSwgYnV0IEknbSBvcGVu
IHRvIG90aGVyIHN1Z2dlc3Rpb25zIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDEwLCAyMDE4IGF0IDEyOjU2
IEFNIFlvc2hpZnVtaSBOaXNoaWRhICZsdDs8YSBocmVmPSJtYWlsdG86bmlzaGlkYUBzZmMud2lk
ZS5hZC5qcCI+bmlzaGlkYUBzZmMud2lkZS5hZC5qcDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBK
dWwgOSwgMjAxOCBhdCA1OjQ3IFBNLCBJYW4gU3dldHQ8YnI+DQombHQ7aWFuc3dldHQ9PGEgaHJl
Zj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQw
Z29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgVGhpcyBo
YXMgYmVlbiBkaXNjdXNzZWQgb24gYW5kIG9mZiBmb3IgYSBmZXcgeWVhcnMgbm93LCBldmVuIHBy
aW9yIHRvIHRoZTxicj4NCiZndDsgSUVURiBwcm9jZXNzLiZuYnNwOyBJdCdzIG5ldmVyIGJlZW4g
Y2xlYXIgdGhhdCBhZGRpbmcgYSBmcmFtZSBmb3IgdGhpcyBwdXJwb3NlLDxicj4NCiZndDsgb3Ig
YWx0ZXJpbmcgdGhlIGJlaGF2aW9yIG9mIGFuIGV4aXN0aW5nIGZyYW1lKGllOiBQSU5HIG9yIFNU
UkVBTSkgaXM8YnI+DQomZ3Q7IHZhbHVhYmxlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEknbSBhYm91
dCB0byBzdGFydCBhbiBleHBlcmltZW50IHRvIHNlbmQgYW4gQUNLIG1vcmUgcXVpY2tseShpZTog
MW1zIGRlbGF5KTxicj4NCiZndDsgaWYgaXQncyBiZWVuIG92ZXIgYW4gUlRUIHNpbmNlIGFuIEFD
SyBoYXMgYmVlbiBzZW50LCB3aGljaCBtYXkgaGVscCwgYnV0IGlzPGJyPg0KJmd0OyBsYXJnZWx5
IGFpbWVkIGF0IHRoZSBUTFAgYW5kIFJUTyB1c2UgY2FzZXMuJm5ic3A7IE9uZSB1c2UgY2FzZSB0
aGF0J3MgYmVlbjxicj4NCiZndDsgZGlzY3Vzc2VkIGlzIHNlbmRpbmcgYSBmYXN0IGFjayBmcmFt
ZS9zaWduYWwgd2hlbiBlbnRlcmluZyBhbiBhcHAtbGltaXRlZDxicj4NCiZndDsgcGhhc2UuJm5i
c3A7IFRoaXMgc2VlbXMgZmFpcmx5IHByb21pc2luZyB0byBtZSwgYnV0IEkgaGF2ZSBubyBleHBl
cmltZW50YWw8YnI+DQomZ3Q7IGV2aWRlbmNlIGl0IGFjdHVhbGx5IGhlbHBzLjxicj4NCjxicj4N
CklmIGl0J3MgbWFpbmx5IGFpbWVkIGF0IHRoZSBUTFAgYW5kIFJUTywgSSdtIG5vdCB2ZXJ5IHN1
cmUgaWYgdGhpcyBpczxicj4NCnJlYWxseSBlZmZlY3RpdmUuPGJyPg0KRm9yIFRMUCBhbmQgUlRP
IGNhc2VzLCBJIGd1ZXNzIHRoZSBzcGVlZCB3aWxsIGRlcGVuZCBvbiBob3cgZmFzdDxicj4NCnNl
bmRlciBzZW5kcyBhIHByb2JlIHBhY2tldCAod2hpbGUgYXZvaWRpbmcgcmVkdW5kYW5jeSkgcmF0
aGVyIHRoYW48YnI+DQpob3cgZmFzdCByZWNlaXZlciBzZW5kcyBhbiBhY2suPGJyPg0KLS08YnI+
DQpZb3NoaTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_MWHPR21MB0191444EDC54BDB409AF728AB65B0MWHPR21MB0191namp_--


From nobody Tue Jul 10 14:14:35 2018
Return-Path: 
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 1F174131064 for ; Tue, 10 Jul 2018 14:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Lkt1Nh6PoBvf for ; Tue, 10 Jul 2018 14:14:31 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E11130DE1 for ; Tue, 10 Jul 2018 14:14:30 -0700 (PDT)
Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BFF68278511 for ; Wed, 11 Jul 2018 06:14:28 +0900 (JST)
Received: by mail-it0-f53.google.com with SMTP id a195-v6so726783itd.3 for ; Tue, 10 Jul 2018 14:14:28 -0700 (PDT)
X-Gm-Message-State: APt69E2o0XifVj6bOmz9wbwccKvEw4nlZth5cCKJR+yGri80rU+LteWi Sj7/NV0ysCG+FoA03urdpRC3q0bD82SSwT2fnjw=
X-Google-Smtp-Source: AAOMgpdkvsTdUT29M3j51jsvXDivRqbZOyUSYdgrobGo06cfEpJbtJW6ghKn6sde9mi0UvDxCjKw0WjF4smc+KAAfsk=
X-Received: by 2002:a24:78c9:: with SMTP id p192-v6mr22361228itc.143.1531257265245;  Tue, 10 Jul 2018 14:14:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 14:14:24 -0700 (PDT)
In-Reply-To: 
References:  <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>      
From: Yoshifumi Nishida 
Date: Tue, 10 Jul 2018 14:14:24 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)
To: Ian Swett 
Cc: Yoshifumi Nishida ,  =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  Praveen Balasubramanian , "Lubashev, Igor" ,  Christian Huitema , IETF QUIC WG , Kazuho Oku 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 10 Jul 2018 21:14:33 -0000

Hi,
Just to be clear..  I am a bit skeptical about the effectiveness of it
for (current) TLP, but I am not against having this kind of feature
for future experiments.
People may come up with an interesting idea based on the results of
some experiments.
--
Yoshi

On Tue, Jul 10, 2018 at 6:54 AM, Ian Swett  wrote:
> To summarize my current thinking: I'd like to add/change something in QUIC
> that allows experimentation in this space.  Ideally this would be in the
> near future(before v1), so we can understand if it's valuable and provide a
> well-reasoned recommendation in the recovery doc.
>
> The fast ACK after PING approach seems simple enough to me, but I'm open to
> other suggestions as well.
>
> On Tue, Jul 10, 2018 at 12:56 AM Yoshifumi Nishida 
> wrote:
>>
>> On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett
>>  wrote:
>> > This has been discussed on and off for a few years now, even prior to
>> > the
>> > IETF process.  It's never been clear that adding a frame for this
>> > purpose,
>> > or altering the behavior of an existing frame(ie: PING or STREAM) is
>> > valuable.
>> >
>> > I'm about to start an experiment to send an ACK more quickly(ie: 1ms
>> > delay)
>> > if it's been over an RTT since an ACK has been sent, which may help, but
>> > is
>> > largely aimed at the TLP and RTO use cases.  One use case that's been
>> > discussed is sending a fast ack frame/signal when entering an
>> > app-limited
>> > phase.  This seems fairly promising to me, but I have no experimental
>> > evidence it actually helps.
>>
>> If it's mainly aimed at the TLP and RTO, I'm not very sure if this is
>> really effective.
>> For TLP and RTO cases, I guess the speed will depend on how fast
>> sender sends a probe packet (while avoiding redundancy) rather than
>> how fast receiver sends an ack.
>> --
>> Yoshi


From nobody Wed Jul 11 07:35:40 2018
Return-Path: 
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 015F11277CC; Wed, 11 Jul 2018 07:35:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: "IETF-Announce" 
Cc: quic@ietf.org
Subject: QUIC (quic) WG Interim Meeting: 2018-09-19 CHANGED
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153131973793.21671.16522111171587131775@ietfa.amsl.com>
Date: Wed, 11 Jul 2018 07:35:37 -0700
Archived-At: 
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 11 Jul 2018 14:35:38 -0000

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The QUIC (quic) Working Group will hold
a multi-day interim meeting.

Session 1:
2018-09-19     09:30 to 17:00  US/Eastern
Session 2:
2018-09-20     09:30 to 17:00  US/Eastern

Meeting Location:
New York City, NY, US

Agenda:
https://github.com/quicwg/wg-materials/blob/master/interim-18-09/agenda.md

Information about remote participation:
Webex information will be emailed to registered remote participants

https://github.com/quicwg/wg-materials/blob/master/interim-18-09/arrangements.md


From nobody Wed Jul 11 23:44:55 2018
Return-Path: 
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 3E6F9130EBC for ; Wed, 11 Jul 2018 23:44:54 -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 TEN88Wpvqmun for ; Wed, 11 Jul 2018 23:44:52 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 1E332130E13 for ; Wed, 11 Jul 2018 23:44:52 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id l14-v6so17119956iob.7 for ; Wed, 11 Jul 2018 23:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:date:message-id:subject:to; bh=KHSBRQ/RPdAJ7qR2rhi/BoQKh5eDYXggeFNEHTmggsA=; b=ErW5n1eYIXUyAuX+TuvUoF+y69pL/mIzst57CdG/Qf6wOjJ1RL0NnFu7JFUwuAAC/P SnaF+9DzFG2i4W5eunS+RirzMVahtzeVFY3+9za8T1wucqtDIySLdiO8b7HmTVnGI+ng yDOm+Qu5ph0mmjQuxHJoU7ktUtYYNGLjh43aPuA01wumT8nTP7dZ9NReNJnWUikYoyUE o/QvcgwaaoGmCsHUtjH7O29YZlUSjGdydKzG/mB2Aq668HkgjfViydp47YlIvXFm3R9O zZcacK83owtlJxUBccn/KoX0TJHRLFg511zKZ+Vyvob00gU+ggi1aasLV5tjPJ/rR0eK Auug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=KHSBRQ/RPdAJ7qR2rhi/BoQKh5eDYXggeFNEHTmggsA=; b=BhmYFGhI5GvIrp52GiBEOxGSJlvhYkOxbDFgF/LLZsVS+Yu0iaWw4YPxDiGP2T2wdW wzJdJKh9nWoh09kXC7au3TF7wd+Kw0KVEnmUaEHwIKnM4G108yek4cCgOSaSpHl9zVEk hEqViep5c3ODuIjzzxTNshOiJakJTSja6/s+YbcCg+hLM7T65O5emdAjh2V/zOwMpv9m UavJluCyjSKmN1waEcNGnx9xPBB3TmCemgYKiZpMt4+4VZ3a0ZGnq+S1FDWJXTcY8QaD 9K51RPlocuP/PuE9JmqTrxVRKlrur/5VyDA/qScokP375H6VSFbpdf0gvZE2a+MVBkVs MuvQ==
X-Gm-Message-State: AOUpUlEOBsGUsSPJOqk+tHybbYlFP2jUhd2hqmPWamyViwqk81gckfIc ke3L9OQ2Aelf11nG1QeWluyOrZzCqYI9ZInB7GrhIg==
X-Google-Smtp-Source: AAOMgpcehAD5d/l7E265KU3jRjK0uxC0jfiyBosN0ugtrRjenKZ1F7QmS1pDuPS+87eaJ5ZryLjjdf/9SusHqgYPAtQ=
X-Received: by 2002:a6b:b3d7:: with SMTP id c206-v6mr1406579iof.606.1531377891318;  Wed, 11 Jul 2018 23:44:51 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 11 Jul 2018 23:44:50 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 11 Jul 2018 23:44:50 -0700
Message-ID: 
Subject: Security of coalesced packets
To: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000003a9f9b0570c7b39c"
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 06:44:54 -0000

--0000000000003a9f9b0570c7b39c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

An issues was recently closed regarding what to do when UDP datagrams
contain coalesced QUIC packets where some are not understood. The
requirement is that the connection ID must match in all QUIC packets but
otherwise packets that do not verify should be buffered or ignored
independently of other packets.

https://github.com/quicwg/base-drafts/issues/1319#issuecomment-404403569

There are good reasons to coalesce because it makes the early handshake
much more efficient and there are good reasons to allow packets that do not
verify because they may relate to key material not yet available.

However, considering the effort spend in trying to avoid linkability, it
appears to me that third-parties can easily inject tracking information in
ordinary QUIC packets using the coalescing mechanism.

Even if the connection ID must match, it is easy to just copy the
connection ID from the primary packet and insert a global tracking cookie
near the source of the packet, such as in a compromised home NAT router.

Tracking can also be done with ordinary tunnelling but that is sometimes
desirable inside infrastructure, and far more difficult to manipulate
outside such boundaries - e.g. a compromised NAT router would not be able
to do it.

These issues could be avoided by only permitting certain early packets to
coalesce.

I do not have the overview of other possible valid uses of coalescing such
as during migration or rekeying.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

--0000000000003a9f9b0570c7b39c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
An issues was recent=
ly closed regarding what to do when UDP datagrams contain coalesced QUIC pa=
ckets where some are not understood. The requirement is that the connection=
 ID must match in all QUIC packets but otherwise packets that do not verify=
 should be buffered or ignored independently of other packets.


There are good reasons to coalesce because=
 it makes the early handshake much more efficient and there are good reason=
s to allow packets that do not verify because they may relate to key materi=
al not yet available.

However, considering the effort spend in trying to avoid linkability, it a=
ppears to me that third-parties can easily inject tracking information in o=
rdinary QUIC packets using the coalescing mechanism.

Even if the connection ID must match, it is=
 easy to just copy the connection ID from the primary packet and insert a g=
lobal tracking cookie near the source of the packet, such as in a compromis=
ed home NAT router.

T=
racking can also be done with ordinary tunnelling but that is sometimes des=
irable inside infrastructure, and far more difficult to manipulate outside =
such boundaries - e.g. a compromised NAT router would not be able to do it.=


These issues could b=
e avoided by only permitting certain early packets to coalesce.

I do not have the overview of ot=
her possible valid uses of coalescing such as during migration or rekeying.=



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


--0000000000003a9f9b0570c7b39c--


From nobody Wed Jul 11 23:53:49 2018
Return-Path: 
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 849CE130FD7 for ; Wed, 11 Jul 2018 23:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 QTMVYb5I8Jtj for ; Wed, 11 Jul 2018 23:53:45 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 D1D86130E13 for ; Wed, 11 Jul 2018 23:53:44 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id w126-v6so53866346oie.7 for ; Wed, 11 Jul 2018 23:53:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QEAR3R0aF1vgjyWdJXvtgt+Fox+UWnE90i8hrc0+7cY=; b=PfXUfbe5fOkS0hdeoWjuNIl1SrkcWAghwvQygGQURmputCdkCxRbD/7Dd9eutXhERi LvH62KGGVNezNKjYYe+fSPTAB3yRz8f1fVB2B3mmgzDR8Jp5rPOdzruHojAyJU7aphWz RPWXKJSJ9OcAQB5b2/6Hk3UhNNZRU/P6SceU8q2K03QvxPUSb/F/nH4t4oPGOruK5yho FW0XXQNEowEM9CuTLINDex9rHtWMLBWWSw8MoTeQ6eHExb5rLq9Hexb5jw2fo2iRYw/i MMVcNMzCJODI4LRL5fiNSdcn0Q7Vncdh7vfZIHbJ2PhICeo0imiUcQEJLaWjZLrMiOR0 Ae6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QEAR3R0aF1vgjyWdJXvtgt+Fox+UWnE90i8hrc0+7cY=; b=e6AAze+Fghcyzk+r3PyszDJKPrbHmhQklGX3mLS2ihMNRN30RAk1osB7OKjL66zqj6 i6zTNnX1U9fS3H+jv21MTDl1VxnfesX4NWHwinudbtcKa9iVqCjIpPthUs1/lrDWnd6T T9nsUTVgGutpI19MzgVb+4T4AdKLgSwx98TfwugVyP55IMtPJnWqAKXkvg0ioRRaUa/4 U117fLg2gDe3KQjlveUKMJ/l47HGM5Ph624mKrKVC7fv/elbg4j6t39cB2uIQjrJMX06 Bj0lcfwhQi8nafwDFTcDwKQUO9jBpOph82MquVVJWzT26vmYDhDhObbdCoyytmqHfB+0 gCUg==
X-Gm-Message-State: AOUpUlHBcbKgJDZiSim3rQtH/TQogaF1O1HNTIX8uoO0gC5q99V4FW9t vPXsptzMmLtkMdQTVr/SYXEg/SBrcYsd15n9jrs=
X-Google-Smtp-Source: AAOMgpcPhL8Qomp8h5ujcAsfEmVoJ9ltjd0kiV2fm69UAuGLBDdhR8Rd/t6PXcObaTJ9yp6ulzuSW6kt0EEj5MPfPtw=
X-Received: by 2002:aca:df42:: with SMTP id w63-v6mr959905oig.295.1531378424058;  Wed, 11 Jul 2018 23:53:44 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Martin Thomson 
Date: Thu, 12 Jul 2018 16:53:33 +1000
Message-ID: 
Subject: Re: Security of coalesced packets
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 06:53:47 -0000

On Thu, Jul 12, 2018 at 4:45 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen
 wrote:
> However, considering the effort spend in trying to avoid linkability, it =
appears to me that third-parties can easily inject tracking information in =
ordinary QUIC packets using the coalescing mechanism.

Yes, this is possible.  It is also possible at the IP layer through
the use of IPv6 header extensions.  A MitM attacker can also embed
signals in flows by altering the rate at which packets are
transmitted.

> These issues could be avoided by only permitting certain early packets to=
 coalesce.

In the current design, you need to use the long header to coalesce
(the trailing packet can use the short header).  And packets with the
long header only appear during connection setup.  It is possible that
we could prevent this sort of covert channel from being created using
long header packets by saying that coalescing isn't allowed after the
connection is established.   Not sure that it gains us much though.


From nobody Thu Jul 12 00:02:29 2018
Return-Path: 
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 0C5BF130EBC for ; Thu, 12 Jul 2018 00:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level: 
X-Spam-Status: No, score=-1.738 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 i-uWnJSKdkbQ for ; Thu, 12 Jul 2018 00:02:23 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 61521130E13 for ; Thu, 12 Jul 2018 00:02:23 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id y10-v6so12295384ioa.10 for ; Thu, 12 Jul 2018 00:02:23 -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=SK2htsOfNhWy56ux4DJPlAdqFT1nHUWxihgrEXVNLvI=; b=U84VyCY7/z+kwKHOdAZrCHIMSNcebSmH+NNkYyt1P+0rJmIvZYQldoY/fQWCFkhqio mX8ADHruI3JdJBdT28Wig0grX/oWuBZ+HWLYyZKBzHiKAImy/BZ6Zh6VJ0fU+embhGsX E9SOc3yMRTXmyrE+dHUbInKPAGM7xnj0L26lglu1g7B/wXDAfMd5sIJwDVTkKFHINrQu kaVXKclPlYTvjlFBqhGeYY2JHLyC0b2aibxcqd1bZJPn4sTdt1Ks4yJzgrolkG0/fRRe joZtcFjgDITK7o1/HTd45S9ZyUWKEdPwMZXq7TDtcDIdO0UagZYEpHh+2K4benhKon3s EYOQ==
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=SK2htsOfNhWy56ux4DJPlAdqFT1nHUWxihgrEXVNLvI=; b=IxuR79WHfE7s8gKI3vMdHVfXVb2zJa20muv/LV3fOTPIVrsvaUpuvo3nSshecBi0ZB GeIQ+CYbDrcPB5oed2yLddlSYXn+RQqnrDwEYgS31+dAoqx8d+XMcepkbRJg+mjZsI3Q iLyHnrAtnodRvoUGhuUzGHRKRkIFZRwOjSLdWQMwsMq4hZSqhr1kadRmMUy/vofGrX9+ VcbpWj6ViSYMW1Dx3s+ItppvxFGJPs3lgtnyH13HHPA5Cz3eiHuem/rlJtTTFTgvDinv BZ9KbPOeaecgCojbtSkSADswjmcIspJ8kZlBghGJiBqXZx3i7CiQm0Kqo50srpfsKvH4 SYcQ==
X-Gm-Message-State: AOUpUlHOzpdObAa1A/6GNwoZkRXqB5MxOWNyOuUvTEQCRuaiiWJrgIUd T+aO7NqQ39l8LkfisYyDQPKUotnbMtfAD9eRAGE=
X-Google-Smtp-Source: AAOMgpcGOipETlGl6EwNvb9clikncoNSnMzcJ8eGTu62HJP0ut2f2J/hogDKiP4vJWEbDs/zMMhBiklUc9MAETwsEe8=
X-Received: by 2002:a6b:b3d7:: with SMTP id c206-v6mr1434156iof.606.1531378942760;  Thu, 12 Jul 2018 00:02:22 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Jul 2018 00:02:22 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:  
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 12 Jul 2018 00:02:22 -0700
Message-ID: 
Subject: Re: Security of coalesced packets
To: Martin Thomson 
Cc: QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000e662df0570c7f1db"
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 07:02:29 -0000

--000000000000e662df0570c7f1db
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In the current design, you need to use the long header to coalesce
(the trailing packet can use the short header). And packets with the
long header only appear during connection setup.

The thing is that any MitM can add a long header at any point in time. So
long headers can appear throughout the connection alhough not a meaningful.
For the same reason it is also easy to disallow later in the connection,
but it isn=E2=80=99t.

I get you point about other signals in rate and IP headers. The IP headers
could be monitored and are less likely to be abused - but my knowledge is
limited here. Of course unexpected long headers could also raise a flag,
but disallowing would be simpler.

Traffic rate signalling is hard to avoid, it is known that THOR traffic is
identified this way, albeit based on the inherent traffic pattern of the
original user. (Which is also why I=E2=80=99m dubious about trying so hard =
to avoid
linkability).

--000000000000e662df0570c7f1db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

In the current design, you need to use the long header to coales=
ce=C2=A0
(the trailing pack=
et can use the short header). And packets with the=C2=A0
long header only appear during connection set=
up.
The thing is that any MitM can =
add a long header at any point in time. So long headers can appear througho=
ut the connection alhough not a meaningful. For the same reason it is also =
easy to disallow later in the connection, but it isn=E2=80=99t.
I get=
 you point about other signals in rate and IP headers. The IP headers could=
 be monitored and are less likely to be abused - but my knowledge is limite=
d here. Of course unexpected long headers could also raise a flag, but disa=
llowing would be simpler.
Traffic rate signalling is hard to avoid, i=
t is known that THOR traffic is identified this way, albeit based on the in=
herent traffic pattern of the original user. (Which is also why I=E2=80=99m=
 dubious about trying so hard to avoid linkability).

<=
/html>

--000000000000e662df0570c7f1db--


From nobody Thu Jul 12 00:30:07 2018
Return-Path: 
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 EA211131084 for ; Thu, 12 Jul 2018 00:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 6LpF-HUGPAzb for ; Thu, 12 Jul 2018 00:30:02 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 8161C130E0E for ; Thu, 12 Jul 2018 00:30:02 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id b22-v6so10971711lfa.3 for ; Thu, 12 Jul 2018 00:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qXdfSuVRWa8NebhDSsrrWVvpMzMp770DplHbMZgR6QM=; b=Ts23EwxprpNywAXiqgbcmx4LBzeVHFlxiBgwyXgzDTK9v91CFHVYiEWNwXI7nU4MAM t5Ov3mYUZdhL7DjPeo2+QuT7iCCJ2ack77Nkqa1x1phk6VvI1ypvIUsSsZVXqGsRL/3j pLGsppaQ1itRPEy9fn5eHm1G5XmvdVDlHEuv+GWvzwqC47nBuHsRDZWkZV9zivIdxnat CJtWM9SbG3Zglz6ivNGl9dm317tjQnLE8qbCanBUjmsz1XRwDhXkgGcwlhRm3TtIDOkL CMjwuQCLWYGAH0getiMvVhTX5AxHXNmFEBNp5++LP++MFEBbzNsXayvLkyuEfzQ+I0df NCjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qXdfSuVRWa8NebhDSsrrWVvpMzMp770DplHbMZgR6QM=; b=L+DF3GfTLVxtZMHC/AQyOSdbQL2/uOHqLvcuRoZvxnOu7N/iDhSQ+C4mKL2mQBBZ4L P7KlA1aIOmCGsr8XaXMZsZ511aepGI8vkr4ZhiPUvBJEPDL5N+qR3cn/xXNEu5xZh/f/ Oeh/7d+zBS9BB4aqqpoHk3Qg+OgyqgyEXOQjEO12m6apM9hMC3xHcefSeiJsAy7nqvy1 a4kvisMt+2nE8gOfoSiut0XZ4QbK0sQMKoGG3U9ckbegurlRoTfB5GC9X/eUz/uQiMPc 39rUd649Prdi2FCSKHBfBGU/o5BcwGwF8y7q64JiXkdL2GE5gPg8BAth0BsBAxV1b0vZ 1URw==
X-Gm-Message-State: AOUpUlHlnzFYtsRGxA42gRNIQ21vbSzYSxJTlO++R1q6n3WvexqDwCit 544VBZYVXn95gm7yNxrBBVFFNhe83QZdfCiMC0U=
X-Google-Smtp-Source: AAOMgpcsEJGtl3DsQOb3a6Rriof9fWldIqALcQsE0HizaC584RvWjPsBBYZq7tzQOYZit2dNsCiY/Dd9NYAlqDugnGc=
X-Received: by 2002:a19:6b03:: with SMTP id d3-v6mr838043lfa.81.1531380600598;  Thu, 12 Jul 2018 00:30:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 00:30:00 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Thu, 12 Jul 2018 16:30:00 +0900
Message-ID: 
Subject: Re: Security of coalesced packets
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 07:30:05 -0000

2018-07-12 15:44 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> An issues was recently closed regarding what to do when UDP datagrams
> contain coalesced QUIC packets where some are not understood. The
> requirement is that the connection ID must match in all QUIC packets but
> otherwise packets that do not verify should be buffered or ignored
> independently of other packets.
>
> https://github.com/quicwg/base-drafts/issues/1319#issuecomment-404403569
>
> There are good reasons to coalesce because it makes the early handshake m=
uch
> more efficient and there are good reasons to allow packets that do not
> verify because they may relate to key material not yet available.
>
> However, considering the effort spend in trying to avoid linkability, it
> appears to me that third-parties can easily inject tracking information i=
n
> ordinary QUIC packets using the coalescing mechanism.

Would you mind elaborating what the additional attack vector by
allowing on-path devices to embed octets introduces?

Current design just throws away the junk. It does not affect the state
of the connection. So while it is possible for an on-path device to
alter the packet, the device cannot see if it reached the peer.

To me the situation seems indifferent to on-path devices sending
additional packet using the 5-tuple when it sees a packet belonging to
the QUIC connection.

>
> Even if the connection ID must match, it is easy to just copy the connect=
ion
> ID from the primary packet and insert a global tracking cookie near the
> source of the packet, such as in a compromised home NAT router.
>
> Tracking can also be done with ordinary tunnelling but that is sometimes
> desirable inside infrastructure, and far more difficult to manipulate
> outside such boundaries - e.g. a compromised NAT router would not be able=
 to
> do it.
>
> These issues could be avoided by only permitting certain early packets to
> coalesce.
>
> I do not have the overview of other possible valid uses of coalescing suc=
h
> as during migration or rekeying.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>



--=20
Kazuho Oku


From nobody Thu Jul 12 00:50:57 2018
Return-Path: 
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 F1351130E01 for ; Thu, 12 Jul 2018 00:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 eZ3cQG5wCYV5 for ; Thu, 12 Jul 2018 00:50:54 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 C706012F1A2 for ; Thu, 12 Jul 2018 00:50:53 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id w16-v6so5653221ita.0 for ; Thu, 12 Jul 2018 00:50:53 -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=AAAlWmsi9UKqOsRBpa71X3RZmuy7YaFqfUzwgdyW1L8=; b=lcUy62LQRTleiN1JCGLmMIJk0+Qd5K0Hnl6D2m1uUshLD3OwAhyq1sxPU8mKlIAxpd SeWj8bcgX6mJ7N0CFMPSaYBq20JpS46tcY4VlO4+wThzAK/JdX8XpbkV1aaDNHK1hk93 fZdovWrKq0Xl1AkFx8o2jRAbGgg+MqZ5h0yFiZ6uLh1AvcgZCKK/bTQCMjrnjQvcEcAH l385STS7xpmWg7uRS0tv/0Urk0W3ii7UktEUvD+lzXjiZrV1A+Dehfcugvc7jPxXUVDG 4a7F9UxescDrGxEA53MkjihjgX1gks2pos4wlaD6jX+Fwg/D+xMM+h36uYBTcVWwrXlB 21JQ==
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=AAAlWmsi9UKqOsRBpa71X3RZmuy7YaFqfUzwgdyW1L8=; b=pZcA+2MQCuKYEZO0yJvv8wfM0N7HuKodKO7LaU10s6AdIb2h4P5t7sZQXMatu7TafU Sr2Oml4lxzYbINYjzxkex7x0/+cTrl8kv6fjMwFNFQnc1Yya+NQK2QLRNf7CaIx/0TRe OKU3rMfmwXeo2HaxYLuZv+/OJa6TDG7BxzopUWPk6LdEVNJJySSkj2pVKtQ6KkhygR4t SNR4Mi6ckvpq1MNXMVGQqVEWLInMONpYqo8dhmHYVOmBy6rdghE9mlA5wIY63AODRx6o pyiAJ2Xum/ePA6eZhlEHtK7FvnPYeXGEk8ZXa2MK6mzElaeFELzhOglqHSlN7l0bPzAh u/sA==
X-Gm-Message-State: AOUpUlEvTFfYPh0Ua7JLxdc/7oMCj9jBrJV/t7uL0mM0lYvnrcosZv4d 8WJFg/E0Xuvon0OWwO5fwcuI5ylM6BD2XdeYkQs=
X-Google-Smtp-Source: AAOMgpccV8G45+W2NH7rarCZ1L9OjS1d7bwen+VZtSHDQLLbctD2nzKmm+6CA3MYdSZb9T33rHQIOIMHNNiJLDiWWBY=
X-Received: by 2002:a02:9833:: with SMTP id t48-v6mr617451jaj.111.1531381853046;  Thu, 12 Jul 2018 00:50:53 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Jul 2018 00:50:51 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:  
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 12 Jul 2018 00:50:51 -0700
Message-ID: 
Subject: Re: Security of coalesced packets
To: Kazuho Oku 
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000005dd3310570c89f00"
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 07:50:56 -0000

--0000000000005dd3310570c89f00
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Would you mind elaborating what the additional attack vector by
allowing on-path devices to embed octets introduces?

It is widely known that there are is broad logging of traffic at major
distribution points, typically controlled by various state actors or
related agencies. Hence, if you can inject a signal early on the path, you
can collect it later for correlation.

Additionally script kiddies might be able to inject traffic monitoring at
corporate traffic gateways so work at home employees could ferry payload
via their NAT router to somewhere inside the firewall, and vice versa. Thus
you could download massive amounts of sensitive data undetected such as
stealing operating system source code or the latest release of Shawn the
Sheep extended DVD edition.



On 12 July 2018 at 09.30.01, Kazuho Oku (kazuhooku@gmail.com) wrote:

2018-07-12 15:44 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> An issues was recently closed regarding what to do when UDP datagrams
> contain coalesced QUIC packets where some are not understood. The
> requirement is that the connection ID must match in all QUIC packets but
> otherwise packets that do not verify should be buffered or ignored
> independently of other packets.
>
> https://github.com/quicwg/base-drafts/issues/1319#issuecomment-404403569
>
> There are good reasons to coalesce because it makes the early handshake
much
> more efficient and there are good reasons to allow packets that do not
> verify because they may relate to key material not yet available.
>
> However, considering the effort spend in trying to avoid linkability, it
> appears to me that third-parties can easily inject tracking information
in
> ordinary QUIC packets using the coalescing mechanism.

Would you mind elaborating what the additional attack vector by
allowing on-path devices to embed octets introduces?

Current design just throws away the junk. It does not affect the state
of the connection. So while it is possible for an on-path device to
alter the packet, the device cannot see if it reached the peer.

To me the situation seems indifferent to on-path devices sending
additional packet using the 5-tuple when it sees a packet belonging to
the QUIC connection.

>
> Even if the connection ID must match, it is easy to just copy the
connection
> ID from the primary packet and insert a global tracking cookie near the
> source of the packet, such as in a compromised home NAT router.
>
> Tracking can also be done with ordinary tunnelling but that is sometimes
> desirable inside infrastructure, and far more difficult to manipulate
> outside such boundaries - e.g. a compromised NAT router would not be able
to
> do it.
>
> These issues could be avoided by only permitting certain early packets to
> coalesce.
>
> I do not have the overview of other possible valid uses of coalescing
such
> as during migration or rekeying.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>



--=20
Kazuho Oku

--0000000000005dd3310570c89f00
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

Would you mind elaborat=
ing what the additional attack vector by=C2=A0
allowing on-path devices =
to embed octets introduces?=C2=A0
It is widely known t=
hat there are is broad logging of traffic at major distribution points, typ=
ically controlled by various state actors or related agencies. Hence, if yo=
u can inject a signal early on the path, you can collect it later for corre=
lation.
Additionally script kiddies might be able to inject traffic m=
onitoring at corporate traffic gateways so work at home employees could fer=
ry payload via their NAT router to somewhere inside the firewall, and vice =
versa. Thus you could download massive amounts of sensitive data undetected=
 such as stealing operating system source code or the latest release of Sha=
wn the Sheep extended DVD edition.

 
On 12 July 2018 at 09.30.01, Kazuho Oku (kazuhooku@gmail.com) wrote:
 
2018-07-12 15:44 GMT+09:00 M=
ikkel Fahn=C3=B8e J=C3=B8rgensen <=
mikkelfj@gmail.com>:

> An issues was recently closed regarding what to do when UDP datagr=
ams

> contain coalesced QUIC packets where some are not understood. The

> requirement is that the connection ID must match in all QUIC packe=
ts but

> otherwise packets that do not verify should be buffered or ignored

> independently of other packets.

>

> https://github.com/quicwg/base-drafts/issues/1319#issuec=
omment-404403569

>

> There are good reasons to coalesce because it makes the early hand=
shake much

> more efficient and there are good reasons to allow packets that do=
 not

> verify because they may relate to key material not yet available.

>

> However, considering the effort spend in trying to avoid linkabili=
ty, it

> appears to me that third-parties can easily inject tracking inform=
ation in

> ordinary QUIC packets using the coalescing mechanism.



Would you mind elaborating what the additional attack vector by

allowing on-path devices to embed octets introduces?



Current design just throws away the junk. It does not affect the state

of the connection. So while it is possible for an on-path device to

alter the packet, the device cannot see if it reached the peer.



To me the situation seems indifferent to on-path devices sending

additional packet using the 5-tuple when it sees a packet belonging to

the QUIC connection.



>

> Even if the connection ID must match, it is easy to just copy the =
connection

> ID from the primary packet and insert a global tracking cookie nea=
r the

> source of the packet, such as in a compromised home NAT router.

>

> Tracking can also be done with ordinary tunnelling but that is som=
etimes

> desirable inside infrastructure, and far more difficult to manipul=
ate

> outside such boundaries - e.g. a compromised NAT router would not =
be able to

> do it.

>

> These issues could be avoided by only permitting certain early pac=
kets to

> coalesce.

>

> I do not have the overview of other possible valid uses of coalesc=
ing such

> as during migration or rekeying.

>

>

> Kind Regards,

> Mikkel Fahn=C3=B8e J=C3=B8rgensen

>







-- =20

Kazuho Oku



--0000000000005dd3310570c89f00--


From nobody Thu Jul 12 00:52:36 2018
Return-Path: 
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 4F155130E01 for ; Thu, 12 Jul 2018 00:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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] 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 AMNZjU3vQ5GI for ; Thu, 12 Jul 2018 00:52:33 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 B6EE512F1A2 for ; Thu, 12 Jul 2018 00:52:33 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id v26-v6so27285225iog.5 for ; Thu, 12 Jul 2018 00:52:33 -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=YhBRh+Wo+ceP8PCW68+jCmxkAaUpQFShX08fYFhfbLw=; b=kioIe1mpb9cW8dJpb2GkK7PMPwY61B/D5hY/ltTDnHJKnlzagA9VVSPtkePfE4tEvk dRoQuIuV59gYS83SNfdzu1idYMLK+4wDus5kPRzbm2iukUoGbO5VjaKsmvYbFzS+aYuv LdcYxz2BREACafrscd5mgcxz4Lf9fxqNZtoPRzhnfps/VapBUU6Om7xJY8/F+2g2dAtw UcPG0agBp/UxYdECcGaKrerjPSVOJiazLA2jbRsuwhrt+KLgcFwKlIK6Jz0q6+k2Fp0U lVP6A7zYC1FG7Hcnt3w0Z/1piiFHJnSi+CstLm3X/pS+mrCwM1iAxaAHETwE1w49/5ry gpDg==
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=YhBRh+Wo+ceP8PCW68+jCmxkAaUpQFShX08fYFhfbLw=; b=RSbIzIX1Byx9rXDFbf5YJJmhMgnj4+pROgzp5DmQKgS7ld9CQXC9N3+YVLxoDGI+IY Mqbr1Hy9OPhAUCfN66Tq+dF+17MzVoxV7/vU0+vqIfWoqj7R8Lr4O8ua5KOlR4Tan0Gs LEffkwcHot9f/Kqkndw5OlzQmGeEF5PfS3i3w1AsWMnjiC7/TtexgDRyZ96gNg47HtOa 5T1d++7Chu/zJMXuEK/4vAkRUQYLRWvChAgNKTiapeiRQKHC4HILU4UHkamA88DSt9lb ycEcIr5711S+Dbxw8GIfwX1Q3cpuZyUF+8f1PlfUx6isH4v1FVs/ABctHJoihyKrdbgQ cTKg==
X-Gm-Message-State: AOUpUlF1gN67fVo9Rz8e8RQNCiWYqArM2XJGVNPFoRLo8QC3saOzwCQY KVjKn8IoK0ouLJGF2CquPhmc7LegZpdT2gu0dcM=
X-Google-Smtp-Source: AAOMgpcnl6JA/y3Q6Bbgl+mD+wQNYT0tA1UQn3e1zBgo53ZBwGDxUdP4FOluOTfBDO0yMtK4nwDKFUnkXLhl2WxUBiA=
X-Received: by 2002:a6b:b3d7:: with SMTP id c206-v6mr1506518iof.606.1531381953084;  Thu, 12 Jul 2018 00:52:33 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Jul 2018 00:52:32 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:   
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 12 Jul 2018 00:52:32 -0700
Message-ID: 
Subject: Re: Security of coalesced packets
To: Kazuho Oku 
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="00000000000054430e0570c8a5da"
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 07:52:35 -0000

--00000000000054430e0570c8a5da
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 12 July 2018 at 09.50.51, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gm=
ail.com)
wrote:

To me the situation seems indifferent to on-path devices sending
additional packet using the 5-tuple when it sees a packet belonging to
the QUIC connection.


It is different because if the source is a NAT home router, or a
compromised mobile phone, it does not matter how you migrate, or change
connection ID, you would still end the same cookie.

--00000000000054430e0570c8a5da
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

On 12 July 2018 at 09.50.51, Mikkel Fahn=C3=B8e J=C3=B8rgen=
sen (mikkelfj@gmail.com) wrote: 
=

To =
me the situation seems indifferent to on-path devices sending=C2=A0
additional packet using the 5-tuple when it sees a packe=
t belonging to=C2=A0the QUIC connection.=C2=A0

It is different because if the source is a NAT home ro=
uter, or a compromised mobile phone, it does not matter how you migrate, or=
 change connection ID, you would still end the same cookie.=C2=A0
<=
/div>

--00000000000054430e0570c8a5da--


From nobody Thu Jul 12 01:32:22 2018
Return-Path: 
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 380A812F1A2 for ; Thu, 12 Jul 2018 01:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 EgO11ra4Jfcu for ; Thu, 12 Jul 2018 01:32:19 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 6F5EC130ED0 for ; Thu, 12 Jul 2018 01:32:19 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id l7-v6so27452434ioj.1 for ; Thu, 12 Jul 2018 01:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KDxGf6HxZ5GIxNQDd0gSp9o9bwiU3UC67L1dZyX3Q8c=; b=Pv6Vyas3E7kEtqkKPhVeSIFmRl0QdRTnFXENyluq6qw8QqT5Ocx3ptTcK6UkaJHqNo YeaL+oz4XIzTAz+dxn6uLXQ7pNH7c3A0RqaXBfQ/CytTy3UJ1ukWtfA8DtnpYhmly0gd XRer6XqJwlDopunBxm1slfXbpDaCmHAx9TR6JQnIum3mAXhwJkSCMc5GxgVwhVn+/Vi/ OEmtsftJZdPl4VHx7i/zJM5vIffMbXCT0h+GQ0JY5066S57TNGqajXd8wsR5FB6LwDnG 87vRfspalGi+6BeVzjh2Rvk8ZQHkhcqITVVrp+8E1t5s6wzsBCNJtgy4lQGsgGhztglZ DBjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KDxGf6HxZ5GIxNQDd0gSp9o9bwiU3UC67L1dZyX3Q8c=; b=f5ugY8z3+Jrui/RwbkQN1Q+T3h6VF9nbBT5MIbDLw9jiOfWCBf2z7c1RkGMXRv1euH nEvfBOghULXnxGvXZ8XjOF31HYmG895nFVI7ohBmVWsuSBWPzUXAK2scb2D+/bn6LRSY I79Vo/yH/xFsrWPcNOOLorM5gWhFAsZSAtHJXJBd3u4Sw5R/LdXSdO+H0JVtzeYHNn5H 4C9I+mVdda4hjiOKdUztq0EFNtdVBZetrAtRVCP7J8lwjVWxRSpOq9pOyGenCgevZIyp Mw5rAwRGrY/q9lCmbULhunPADlGQggAK8U90dljrvl/k8ltnR8Y/ATGpXVtFVTDcbPHt WBhA==
X-Gm-Message-State: APt69E0gZYN//801i+c+a1qRthFx8uT0Re7AyJzTcyXHNPFCzR09jO+d HJItOT5AEHny6zEtMXGaPvVxJbDo
X-Google-Smtp-Source: AAOMgpdyAMqEpB5zEnkw6infnugZKorwPhs4NeAwAsKcJMuVrp/pIEcuWdLksJ8Fx8bshk6wLOhmsQ==
X-Received: by 2002:a6b:84c6:: with SMTP id o67-v6mr26434794ioi.119.1531384338396;  Thu, 12 Jul 2018 01:32:18 -0700 (PDT)
Received: from ?IPv6:2400:4050:2c40:1700:c9ed:d102:b5ef:b579? ([2400:4050:2c40:1700:c9ed:d102:b5ef:b579]) by smtp.gmail.com with ESMTPSA id g10-v6sm6608240ioq.87.2018.07.12.01.32.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 01:32:17 -0700 (PDT)
From: Kazuho Oku 
X-Google-Original-From: Kazuho Oku 
Content-Type: multipart/alternative; boundary=Apple-Mail-929ED041-D567-4E5E-965C-B369847E5C26
Mime-Version: 1.0 (1.0)
Subject: Re: Security of coalesced packets
X-Mailer: iPhone Mail (15F79)
In-Reply-To: 
Date: Thu, 12 Jul 2018 17:32:14 +0900
Cc: IETF QUIC WG 
Content-Transfer-Encoding: 7bit
Message-Id: <5E1464AF-9AA8-48D0-9007-2B1CC764AEA2@gmail.com>
References:    
To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Archived-At: 
X-BeenThere: quic@ietf.org
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, 12 Jul 2018 08:32:22 -0000

--Apple-Mail-929ED041-D567-4E5E-965C-B369847E5C26
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

2018/07/12 16:52=E3=80=81Mikkel Fahn=C3=B8e J=C3=B8rgensen =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

>=20
>> On 12 July 2018 at 09.50.51, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@=
gmail.com) wrote:
>>=20
>> To me the situation seems indifferent to on-path devices sending=20
>> additional packet using the 5-tuple when it sees a packet belonging to=20=

>> the QUIC connection.=20
>=20
>=20
> It is different because if the source is a NAT home router, or a compromis=
ed mobile phone, it does not matter how you migrate, or change connection ID=
, you would still end the same cookie.=20
>=20

Thank you for elaborating.

I think that the attacks you describe can be mounted *without* using coalesc=
ed packets.

A malicious device (could be a router or a compromised mobile phone) can obs=
erve the TCP/UDP packets being transmitted, craft a new packet that has the s=
ame 5-tuple (and possibly also the first few octets that contain the packet h=
eader) and emit them. An observer will observe those crafted packets to trac=
k the connection.=

--Apple-Mail-929ED041-D567-4E5E-965C-B369847E5C26
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

2018/07/12 16:52=E3=80=81Mikkel Fahn=C3=B8e=
 J=C3=B8rgensen <mikkelfj@gmail.com=
>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:






Sunday July 15, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+6/-8/=F0=9F=92=AC33)

  
6 issues created:

  

  
15 issues received 33 new comments:

  

  
8 issues closed:

  




Pull requests


quicwg/base-drafts (+16/-9/=F0=9F=92=AC7)

  
16 pull requests submitted:

  

  
6 pull requests received 7 new comments:

  

  
9 pull requests merged:

  



Repositories tracked by this digest:





--===============0998956451747972282==--


From nobody Sat Jul 14 20:35:31 2018
Return-Path: 
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 7CA89130F0F for ; Sat, 14 Jul 2018 20:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MEiYGS65vbYf for ; Sat, 14 Jul 2018 20:35:24 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9853130EB9 for ; Sat, 14 Jul 2018 20:35:24 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2018 20:35:24 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.51,355,1526367600"; d="scan'208,217"; a="56604266"
Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga007.jf.intel.com with ESMTP; 14 Jul 2018 20:35:15 -0700
Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 14 Jul 2018 20:35:15 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX115.amr.corp.intel.com ([169.254.4.162]) with mapi id 14.03.0319.002; Sat, 14 Jul 2018 20:35:14 -0700
From: "Deval, Manasi" 
To: =?utf-8?B?J01pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4n?= , Eric Rescorla , Kazuho Oku 
CC: Jana Iyengar , IETF QUIC WG , "Marten Seemann" , Martin Thomson , Ian Swett , "Praveen Balasubramanian" 
Subject: RE: Proposal to replace ACK block count with ACK length
Thread-Topic: Proposal to replace ACK block count with ACK length
Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFywAA7X+IAADpdCoAAAtMWAABL8DbAAVdcngAATwqWAAAPVigAAApb0gAK6iKdQ
Date: Sun, 15 Jul 2018 03:35:14 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri>  <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com>            <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTczNzY1NWEtZDJiZi00YzYyLWIxMTgtNGM0ZTMwNTZmZTA2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYWUxcDVocHUyYlwvS1RtZWhBVTRcL1lzdHVHSzNaTjRJcmdGUDB1Q3pZSkZxTUpXYm84VzNDTlFSc2VYblwvMWdMWCJ9
x-ctpclassification: CTP_NT
x-originating-ip: [10.22.254.139]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B86D457ORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 03:35:31 -0000

--_000_1F436ED13A22A246A59CA374CBC543998B86D457ORSMSX111amrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmV2aXNpdCB0aGlzIGRpc2N1c3Npb24gaW4gdGhl
IGNvbnRleHQgb2YgZGlzdHJpYnV0ZWQgcHJvY2Vzc2luZy4gVGhlIGRpc3RyaWJ1dGVkIHByb2Nl
c3NpbmcgZG9lc27igJl0IG9ubHkgYXBwbHkgdG8gbXVsdGktdGhyZWFkaW5nIGJ1dCBhbHNvIHRv
IGxheWVyZWQgcHJvY2Vzc2luZy4NCg0KT25lIGV4YW1wbGUgb2YgbGF5ZXJlZCBwcm9jZXNzaW5n
IGlzIHNlZ21lbnRhdGlvbi4gVGhlIGN1cnJlbnQgQ2hyb21pdW0gaW1wbGVtZW50YXRpb24gY3Vy
cmVudGx5IGNyZWF0ZXMgdGhlIHNlZ21lbnRzIGFuZCBwYXNzZXMgdGhlbSBhcyBhIGJ1bmNoIGlu
dG8gdGhlIExpbnV4IGtlcm5lbC4gVGhlcmUgaXMgYSBHU08gcGF0Y2ggdGhhdCB3b3VsZCBjaG9w
IGF0IHRoZSBzZWdtZW50IGJvdW5kYXJ5IGFuZCBlbmNhcHN1bGF0ZSBpbiBVRFAgaGVhZGVycy4g
V2UgY2FuIGZ1cnRoZXIgaW1wcm92ZSBwZXJmb3JtYW5jZSBieSBwbHVnZ2luZyBpbiBhIHNtYXJ0
ZXIgc2VnbWVudGF0aW9uIGFsZ29yaXRobSBzdWNoIHRoYXQgdGhlIHNlZ21lbnQgcHJvY2Vzc2lu
ZyBjYW4gYWNjb3VudCBmb3IgdHlwZSBvZiBmcmFtZSwgaXRzIHNpemUgYW5kIG1ha2UgaW50ZWxs
aWdlbnQgYm91bmRhcnkgYW5kIHBhZGRpbmcgZGVjaXNpb25zIGF0IGEgbG93ZXIgbGF5ZXIgb3Ig
aW4gYW4gb2ZmbG9hZC4gVG8gdGhpcyBlbmQsIHRoZSBhbGdvcml0aG0gbmVlZHMgdG8gaWRlbnRp
ZnkgdGhlIHNpemUgb2YgZWFjaCBvZiB0aGUgZnJhbWVzLiBIYXZpbmcgYW4gQUNLIGxlbmd0aCB0
aGF0IGNhbiBiZSBkZXRlcm1pbmVkIGluIGEgc2luZ2xlIHJlYWQgaXMgbXVjaCBtb3JlIGVmZmlj
aWVudCB0aGFuIGhhdmluZyB0byBkbyBhIHNlcmllcyBvZiByZWFkcy4NCg0KVGhhbmtzLA0KTWFu
YXNpDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBn
bWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEp1bmUgMjIsIDIwMTggOToxNSBBTQ0KVG86IEVyaWMg
UmVzY29ybGEgPGVrckBydGZtLmNvbT47IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+
DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1
aWNAaWV0Zi5vcmc+OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPjsgTWFy
dGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPjsgTWFydGluIFRob21zb24gPG1h
cnRpbi50aG9tc29uQGdtYWlsLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47
IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDog
UmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0K
DQpBbm90aGVyIG9wdGlvbiBpcyB0byB3cml0ZSBvdXQgZnJhbWVzIGFzIGlzIHdpdGhvdXQgbGVu
Z3RoIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHZhcmludHMuIFdoZW4gYSBwYWNrZXQgaXMgbmVhcmx5
IGRvbmUsIGEgcnVuLWxlbmd0aCBlbmNvZGVkIGZyYW1lIGluZGV4IGlzIHBsYWNlZCBpbiB0aGUg
cGFja2V0IHRhaWwuIEl0IGNvdWxkIGFsc28gaW5jbHVkZSB0aGUgZnJhbWUgdHlwZXMuIEEgcmVh
ZGVyIGNhbiBub3cgZGlyZWN0bHkgZmluZCBvciBza2lwIEFDSyBmcmFtZXMgYW5kIHRoZSB3cml0
ZXIgZG9lcyBub3QgaGF2ZSB0byBjb21wdXRlIGxlbmd0aHMgYmVmb3JlIHdyaXRpbmcuIE9mIGNv
dXJzZSwgdGhlIHJlYWRlciBuZWVkcyB0byBiZSBhYmxlIHRvIGxvY2F0ZSB0aGUgaW5kZXggYXQg
dGhlIHRhaWwgd2hpY2ggY2FuIGJlIHRyaWNreSB3aXRoIGNvYWxlc2NlZCBwYWNrZXRzLCBidXQg
bm90IGltcG9zc2libGUuIElzbuKAmXQgdGhpcyBsYXJnZWx5IGhvdyB6aXAtZmlsZXMgd29yaz8N
Cg0KTWlra2VsDQoNCg0KT24gMjIgSnVuZSAyMDE4IGF0IDE3LjAwLjUyLCBNaWtrZWwgRmFobsO4
ZSBKw7hyZ2Vuc2VuIChtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNv
bT4pIHdyb3RlOg0KQXMgSSBzYWlkIGVhcmxpZXIsIEkgYWxzbyBmYXZvdXIgYSBsZW5ndGggcHJl
Zml4LiBCdXQsIElhbiBkb2VzIGhhdmUgYSBwb2ludDoNCg0KV3JpdGluZyBkYXRhIGlzIGdlbmVy
YWxseSBtb3JlIGV4cGVuc2l2ZSB0aGFuIHJlYWRpbmcgZGF0YS4gRXNwZWNpYWxseSBpZiB5b3Ug
aGF2ZSB0byB0cmF2ZXJzZSBsb25nIGRhdGEgc3RydWN0dXJlcyB0byBmaW5kIHRoZSBsZW5ndGgg
YmVmb3JlIHlvdSBjYW4gc3RhcnQgd3JpdGluZyBhbmQvb3IgeW91IG1heSBoYXZlIHRvIGNvbnNl
cnZhdGl2ZWx5IHJlc2VydmUgZXh0cmEgc3BhY2UgZm9yIGEgbGVuZ3RoIGZpZWxkLg0KDQpTbyBi
ZWZvcmUgZGVjaWRpbmcgb25lIHdheSBvciB0aGUgb3RoZXIsIHRoZSBjb3N0IG9mIHdyaXRpbmcg
bmVlZHMgdG8gYmUgd2VsbCB1bmRlcnN0b29kLCBhbHNvIGluIHNjZW5hcmlvcyB3aXRoIGxhcmdl
IE1UVeKAmXMuDQoNCkluIHRoZSBmbGF0YnVmZmVycyBzcGFjZSB0aGF0IEnigJltIGludm9sdmVk
IHdpdGgsIHN0cmVhbWluZyBoYXMgdHVybmVkIHRvIGJlIGFuIGlzc3VlIGJlY2F1c2UgZGF0YSBj
YW5ub3QgYmUgdHJhbnNtaXR0ZWQgaW4gcGFydHMgd2l0aG91dCBpbmRleCBkYXRhIG9uIGEgc2Vw
YXJhdGUgY2hhbm5lbCB0byByZWNvbWJpbmVkIGZyYWdtZW50cy4gQSBzaW1wbGUsIGJ1dCBub24t
c3RhbmRhcmQsIGNoYW5nZSBpbiB0aGUgZm9ybWF0IHdvdWxkIGZpeCB0aGlzLiBKU09OIGFuZCBD
b0FQIGFsbG93cyBzdHJlYW1pbmcsIGJ1dCBtYW55IG90aGVyIGZvcm1hdHMgZG8gbm90LCBpbmNs
dWRpbmcgbGF0ZXIgdmVyc2lvbnMgb2YgcHJvdG9jb2wgYnVmZmVycywgYXMgSSB1bmRlcnN0YW5k
Lg0KDQpBbiBvZGQgY29uc2VxdWVuY2Ugb2YgbWFraW5nIGJvdGggcmVhZCBhbmQgd3JpdGUgZWZm
aWNpZW50IGlzIHRoYXQgbGVuZ3RoIGJldHRlciB3b3JrIGJldHRlciBpZiBzdG9yZWQgYXQgdGhl
IGVuZCBhbmQgcGFja2V0cyByZWFkIGJhY2t3YXJkcy4gVGhpcyByZXF1aXJlcyBhIHNpbmdsZSB0
b3RhbCBsZW5ndGggcHJlZml4IGJ1dCB0aGlzIGlzIHN0b3JlZCBpbiB0aGUgZGF0YWdyYW0gaGVh
ZGVyLiBUaGlzIGlzIHByb2JhYmx5IHRvbyBvZGQtYmFsbCwgYnV0IHN0aWxsIGEgY29uc2lkZXJh
dGlvbiB3b3J0aCBub3RpbmcuDQoNClRoZSBzZWNvbmQgYmVzdCBhbHRlcm5hdGl2ZSBtYXkgdGhl
cmVmb3JlIGJlIHRvIGFsbG93IHdyaXRlcyB0byBiZSBmYXN0IGFuZCByZWFkcyB0byBiZSBkZWNl
bnQuDQoNCllldCwgSSBzdGlsbCBsaWtlIGxlbmd0aCBwcmVmaXhlcyBpZiB0aGV5IGNvdWxkIGJl
IG1hZGUgd3JpdGUgZWZmaWNpZW50IGJlY2F1c2UgaGlnaCBwZXJmb3JtYW5jZSBsb3ctbGF0ZW5j
eSBwcm9jZXNzZXMgY2FyZSB6ZXJvIGFib3V0IEFDSyBhbmQgY2FuIGNvbnN1bWUgYSBwYWNrZXQg
ZGlyZWN0bHkgd2hpbGUgYSBiYWNrZ3JvdW5kIHByb2Nlc3MgaGFuZGxlcyBhbGwgdGhlIGxhdGVu
Y3kgaW5zZW5zaXRpdmUgQUNLIGFuZCByZXRyYW5zbWlzc2lvbiBsb2dpYy4NCg0KVGhlIHF1ZXN0
aW9uIGlzIGFsc28sIHdoZXJlIGlzIHRoZSBwcmVzc3VyZTogYW4gSW9UIGFnZ3JlZ2F0b3IgbWln
aHQgYmUgbWFzc2l2ZWx5IHJlYWQgaW50ZW5zaXZlIHdoaWxlIGEgd2ViIGNhY2hlIHdvdWxkIGJl
IHZlcnkgd3JpdGUgaW50ZW5zaXZlLg0KDQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hl
IErDuHJnZW5zZW4NCg0KDQpPbiAyMiBKdW5lIDIwMTggYXQgMTUuMTIuMDksIEVyaWMgUmVzY29y
bGEgKGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPikgd3JvdGU6DQpJdCBzZWVtcyBs
aWtlIHRoZXJlIGFyZSB0d28gcXVlc3Rpb25zIGF0IGhhbmQgaGVyZToNCg0KMS4gV291bGQgaXQg
YmUgYXJjaGl0ZWN0dXJhbGx5IGJldHRlciB0byBoYXZlIGZyYW1lcyBoYXZlIGEgY29uc2lzdGVu
dCBzZWxmLWNvbnRhaW5lZA0KcmVwcmVzZW50YXRpb24/DQoyLiBJcyBpdCBlbm91Z2ggYmV0dGVy
IHRoYXQgd2Ugc2hvdWxkIGRvIHNvIG5vdy4NCg0KSSBhZ3JlZSB3aXRoIEthenVobyB0aGF0IChh
KSB3ZSBkb24ndCBoYXZlIHRoYXQgcmVwcmVzZW50YXRpb24gbm93IGFuZCAoYikgaXQgd291bGQN
CmJlIGEgYmV0dGVyIGRlc2lnbiB0byBkbyBzby4gSSdtIHBlcmhhcHMgc29tZXdoYXQgbW9yZSBw
b3NpdGl2ZSBvbiAoMikgdGhhbiBoZQ0KaXMuIEkgZG9uJ3QgdGhpbmsgaXQncyBjcml0aWNhbGx5
IGltcG9ydGFudCB0aGF0IHdlIG1ha2UgdGhlIGNoYW5nZSwgYnV0IGlmIHdlIHdlcmUNCnRvIGhv
bGQgYSBjb25zZW5zdXMgY2FsbCwgSSB0aGluayBJIHdvdWxkIGJlIGluIGZhdm9yLiBJJ2QgY2Vy
dGFpbmx5IGJlIGludGVyZXN0ZWQNCmluIGxvb2tpbmcgYXQgYSBwcm9wb3NhbCBpZiBzb21lb25l
IGVsc2Ugd2VyZSB0byBtYWtlIG9uZS4NCg0KLUVrcg0KDQoNCg0KT24gVGh1LCBKdW4gMjEsIDIw
MTggYXQgODo0NSBQTSwgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86a2F6
dWhvb2t1QGdtYWlsLmNvbT4+IHdyb3RlOg0KMjAxOC0wNi0yMiA4OjA4IEdNVCswOTowMCBEZXZh
bCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50
ZWwuY29tPj46DQo+IEkgZmVlbCB0aGF0IHRoZSByZXF1aXJlbWVudCB0byBoYXZlIGV2ZXJ5IHZh
bHVlIHZhbGlkIGlzIHNvbWV3aGF0IGFjYWRlbWljLg0KDQpJIHRoaW5rIHRoYXQgTWFydGVuIGlz
IGNvcnJlY3QgaW4gcG9pbnRpbmcgb3V0IHRoYXQgbWFraW5nIHRoZSBBQ0sNCmZyYW1lIHNlbGYt
Y29udGFpbmluZyAoYnkgaGF2aW5nIGEgZmllbGQgdGhhdCByZXByZXNlbnRzIHRoZSBudW1iZXIg
b2YNCm9jdGV0cyBiZWluZyBjb25zdW1lZCBieSB0aGUgZnJhbWUpIHdvdWxkIGJlIGFuIGV4Y2Vw
dGlvbiBmcm9tIHRoZQ0KZGVzaWduIHBhdHRlcm4gd2UgaGF2ZS4NCg0KTG9vayBhdCBTVFJFQU0g
ZnJhbWUuIFRoZSBmaWVsZCBpcyBub3Qgc2VsZi1jb250YWluZWQuIEluc3RlYWQsIGl0IGhhcw0K
YSBMZW5ndGggZmllbGQgZm9yIHRoZSBTdHJlYW0gRGF0YSwgd2hpY2ggaXMgYSBsZWFmLiBUaGUg
c2FtZSBnb2VzIGZvcg0KTkVXX0NPTk5FQ1RJT05fSUQgZnJhbWUgKHRoYXQgaGFzIHRoZSBsZW5n
dGggZmllbGQgZm9yIENvbm5lY3Rpb24gSUQNCmZpZWxkICh3aGljaCBpcyBhbHNvIGEgbGVhZikp
LCBDT05ORUNUSU9OX0NMT1NFIChsZW5ndGggZmllbGQgZm9yDQpSZWFzb24gUGhhc2UpLg0KDQpJ
IGFncmVlIHdpdGggTWFydGVuLCBNaWtrZWwgKGFuZCBwb3NzaWJseSBvdGhlcnMgYXMgd2VsbCkg
dGhhdCBoYXZpbmcNCmNvbnNpc3RlbmN5IGlzIGltcG9ydGFudC4NCg0KVGhlcmVmb3JlLCBJIGFn
cmVlIHdpdGggTWlra2VsIHRoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIG1ha2luZyBldmVyeQ0KZnJh
bWUgc2VsZi1jb250YWluZWQgb3Iga2VlcGluZyBldmVyeSBmcmFtZSBhcy1pcyAoaS5lLiBub3QN
CnNlbGYtY29udGFpbmVkKS4NCg0KRldJVywgYXMgZGVzY3JpYmVkIGluIHRoZSBsYXR0ZXIgaGFs
ZiBvZg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9xdWljL2N1cnJlbnQv
bXNnMDQyODcuaHRtbCwgaXQNCmlzIHBvc3NpYmxlIHRvIG1ha2UgZXZlcnkgZnJhbWUgc2VsZi1j
b250YWluZWQgKmFuZCogYWxzbyBtYWtlIEFDSw0KZnJhbWVzIHNtYWxsZXIgdGhhbiB0aGUgY3Vy
cmVudCBkcmFmdC4gTWFraW5nIGV2ZXJ5IGZyYW1lDQpzZWxmLWNvbnRhaW5lZCBnaXZlcyB1cyB0
aGUgcG9zc2liaWxpdHkgdG8gc2VuZCBuZXcgZXh0ZW5zaW9uIGZyYW1lcw0Kd2l0aG91dCBuZWdv
dGlhdGlvbi4NCg0KSSBkbyBub3QgdGhpbmsgdGhhdCBJIHdvdWxkIHB1c2ggZm9yIG1ha2luZyBl
dmVyeSBmcmFtZSBzZWxmLWNvbnRhaW5lZA0KYnkgbXlzZWxmIChiZWNhdXNlIEkgZG8gbm90IHRo
aW5rIGl0IG1lZXRzIHRoZSBoaWdoIGJhciB0byBoYXZlIGENCmNoYW5nZSBhdCBzdWNoIGEgbGF0
ZSBtb21lbnQgb2Ygc3RhbmRhcmRpemF0aW9uKSwgYnV0IGFzIHN0YXRlZCwgbXkNCnByZWZlcmVu
Y2UgZ29lcyB0byBzZWVpbmcgZXZlcnkgZnJhbWUgbWFkZSBzZWxmLWNvbnRhaW5lZCBvciBub25l
IG9mDQp0aGVtIG1hZGUgYXMgc3VjaC4NCg0KPiBUaGUgbGVuZ3RoIHZhbHVlIHByb3ZpZGVzIG11
Y2ggbW9yZSB2YWx1ZSB0aGFuIHRoZSBibG9jayBjb3VudCBhbmQgdGhlIGZhY3QNCj4gdGhhdCBj
ZXJ0YWluIHZhbHVlcyBjYW4gbmV2ZXIgYmUgYWNoaWV2ZWQgaXMgYW4gaW5oZXJlbnQgcHJvcGVy
dHkgb2YgdGhlDQo+IGxlbmd0aC4NCj4NCj4NCj4NCj4gT25lIGludGVyZXN0aW5nIG9ic2VydmF0
aW9uIGlzIHRoYXQgdGhpcyBwcm9wZXJ0eSBpcyBub3QgbGltaXRlZCB0byBsZW5ndGguDQo+IE9u
ZSBjYW4gZXZlbiBtYWtlIGEgc2ltaWxhciBhcmd1bWVudCBhYm91dCBBQ0sgYmxvY2sgY291bnQu
IFRoZSBtYXhpbXVtDQo+IG51bWJlciBvZiBBQ0sgYmxvY2tzIHRoYXQgY2FuIGJlIGRlZmluZWQg
d2lsbCBub3QgYWx3YXlzIGhhdmUgYSBtZWFuaW5nZnVsDQo+IHZhbHVlLiBJbiBvdXQgZXhhbXBs
ZXMsIDAsMSwyLDMgYXJlIGFsbCB2YWxpZC4gSWYgSSBzZXQgdGhlIHZhbHVlIG9mIEFDSw0KPiBi
bG9jayBjb3VudCB0byBoYXZlIGxvd2VyIHR3byBiaXRzIHRvIGJlIDExLCB0aGUgbWF4aW11bSB2
YWx1ZSBpcyBvZiBBQ0sNCj4gYmxvY2tzIGlzIOKAkyA0NjExNjg2MDE4NDI3Mzg3OTAzLiBUaGlz
IGlzIHRoZSBzYW1lIHZhbHVlIG9mIGxhcmdlc3QNCj4gYWNrbm93bGVkZ2VkIHNvIGlmIHRoZSBB
Q0sgYmxvY2sgY291bnQgd2FzIHNldCB0byB0aGlzIHZhbHVlLCBpdCB3b3VsZCBzdGlsbA0KPiBi
ZSBtZWFuaW5nbGVzcy4NCj4NCj4NCj4NCj4gVGhhbmtzLA0KPg0KPiBNYW5hc2kNCj4NCj4NCj4N
Cj4NCj4NCj4NCj4NCj4gRnJvbTogTWFydGVuIFNlZW1hbm4gW21haWx0bzptYXJ0ZW5zZWVtYW5u
QGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+XQ0KPiBTZW50OiBUdWVz
ZGF5LCBKdW5lIDE5LCAyMDE4IDY6NDQgUE0NCj4gVG86IERldmFsLCBNYW5hc2kgPG1hbmFzaS4u
ZGV2YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4gQ2M6IElh
biBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+
OyBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwu
Y29tPj47IEVyaWMNCj4gUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29t
Pj47IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFp
bC5jb20+PjsgUHJhdmVlbg0KPiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208
bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn
PG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hcnRpbg0KPiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv
bkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQo+DQo+DQo+IFN1
YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBs
ZW5ndGgNCj4NCj4NCj4NCj4gSGkgTWFuYXNpLA0KPg0KPg0KPg0KPj4gVGhlIHJpc2sgb2YgZGlz
YWdyZWVtZW50IGJldHdlZW4gYWNrIGJsb2NrcyBhbmQgYWNrIGJsb2NrIGNvdW50IGlzIHNhbWUg
YXMNCj4+IHRoZSByaXNrIG9mIGRpc2FncmVlbWVudCBiZXR3ZWVuIGFjayBibG9ja3MgYW5kIGFj
ayBsZW5ndGguIEVpdGhlciB3YXkgdGhpcw0KPj4gbmVlZHMgdG8gYmUgY291bnRlZCB1cCB3aGls
ZSBjcmVhdGluZyB0aGUgQUNLIGFuZCBjb3VudGVkIGRvd24gd2hpbGUgcGFyc2luZw0KPj4gaXQu
IFRoZSBwb3NzaWJpbGl0eSBvZiBlcnJvciBpcyB0aGUgc2FtZS4gR2V0dGluZyB0aGUgYWNrIGJs
b2NrIGNvdW50IHdyb25nDQo+PiBpcyBhcyBwcm9ibGVtYXRpYyBhcyBnZXR0aW5nIHRoZSBhY2sg
bGVuZ3RoIHdyb25nLiBEbyB5b3UgYWdyZWU/DQo+DQo+DQo+DQo+IEkgZGlzYWdyZWUuIExldCdz
IHRha2UgYW4gZXhhbXBsZSBvZiBhbiBBQ0sgZnJhbWUgd2l0aCBvbmUgQUNLIHJhbmdlLCB0aGF0
DQo+IG5lZWRzIGEgMiBieXRlIHZhcmludCB0byByZXByZXNlbnQgdGhlIEZpcnN0IEFDSyBCbG9j
ayBhbmQgYW5vdGhlciAyIGJ5dGUNCj4gdmFyaW50IHRvIHJlcHJlc2VudCB0aGUgR2FwLg0KPg0K
PiBXaXRoIHlvdXIgcHJvcG9zYWw6DQo+DQo+IFRoZSB2YWx1ZXMgMCBhbmQgMSBhcmUgaW52YWxp
ZCwgc2luY2UgdGhlIGxlbmd0aCBmaWVsZHMgaXRzZWxmIGlzIGluY2x1ZGVkDQo+IGluIHRoZSBs
ZW5ndGguDQo+IFRoZSB2YWx1ZXMgMiwgMywgLi4uLCAoMiArIGxlbihMYXJnZXN0QWNrbm93bGVk
Z2VkKSArIGxlbihBY2tEZWxheSkpIC0gMSBhcmUNCj4gaW52YWxpZCwgc2luY2UgdGhlIGxlbmd0
aCBuZWVkcyB0byBpbmNsdWRlIHRoZSBMYXJnZXN0IEFja25vd2xlZGdlZCBhbmQgdGhlDQo+IEFj
ayBEZWxheS4NCj4gVGhlIHZhbHVlIDIgKyBsZW4oTGFyZ2VzdEFja25vd2xlZGdlZCkgKyBsZW4o
QWNrRGVsYXkpIHdvdWxkIGJlIHRoZSBmaXJzdA0KPiB2YWxpZCB2YWx1ZSwgYW5kIGNvcnJlc3Bv
bmQgdG8gYW4gQUNLIGZyYW1lIHdpdGggbm8gYmxvY2tzLg0KPiBUaGUgdmFsdWUgMiArIGxlbihM
YXJnZXN0QWNrbm93bGVkZ2VkKSArIGxlbihBY2tEZWxheSkgKyAxIGlzIGludmFsaWQsIHNpbmNl
DQo+IGl0IHdvdWxkIGN1dCB0aGUgdmFyaW50IGZvciB0aGUgRmlyc3QgQUNLIEJsb2NrDQo+IFRo
ZSB2YWx1ZSAyICsgbGVuKExhcmdlc3RBY2tub3dsZWRnZWQpICsgbGVuKEFja0RlbGF5KSArIDIg
aXMgaW52YWxpZCwgc2luY2UNCj4gaXQgd291bGQgY3V0IHRoZSBmcmFtZSBhZnRlciB0aGUgRmly
c3QgQUNLIEJsb2NrIChidXQgZXZlcnkgYmxvY2sgbXVzdCBiZQ0KPiBmb2xsb3dlZCBieSBhIGdh
cCBsZW5ndGgpDQo+IFRoZSB2YWx1ZSAyICsgbGVuKExhcmdlc3RBY2tub3dsZWRnZWQpICsgbGVu
KEFja0RlbGF5KSArIDMgaXMgaW52YWxpZCwgc2luY2UNCj4gaXQgd291bGQgY3V0IHRoZSB2YXJp
bnQgZm9yIHRoZSBHYXANCj4gRmluYWxseSwgdGhlIHZhbHVlIDIgKyBsZW4oTGFyZ2VzdEFja25v
d2xlZGdlZCkgKyBsZW4oQWNrRGVsYXkpICsgNCBpcyB2YWxpZA0KPg0KPiBUaGVyZSBhcmUgKmEg
bG90KiBvZiBpbnZhbGlkIHZhbHVlcyB0aGF0IHlvdSBjYW4gZW5jb2RlIGludG8gdGhlIEFDSyBs
ZW5ndGgNCj4gZmllbGQuIE1vcmUgaW1wb3J0YW50bHksICpub25lKiBvZiB0aGVzZSBlcnJvciBj
YXNlcyBleGlzdHMgd2l0aCB0aGUgY3VycmVudA0KPiBmcmFtZSBmb3JtYXQuDQo+DQo+IFRoZSAq
b25seSogZXJyb3IgY2FzZSB0aGF0IGNhbiBvY2N1ciB3aXRoIG91ciBjdXJyZW50IGZvcm1hdCBp
cyB0aGF0IHRoZQ0KPiBwYWNrZXQgaXMgdG9vIHNob3J0IGZvciB0aGUgbnVtYmVyIG9mIEFDSyBi
bG9ja3MgdGhhdCBhcmUgc3VwcG9zZWQgdG8NCj4gY29udGFpbmVkIGluIHRoZSBmcmFtZS4gVGhp
cyBjYW4gb2NjdXIgd2l0aCB5b3VyIHByb3Bvc2FsIGFzIHdlbGwgKGluDQo+IGFkZGl0aW9uIHRv
IHRoZSBlcnJvciBjYXNlcyBsaXN0ZWQgYWJvdmUpLg0KPg0KPg0KPg0KPiBNeSBjb25jZXJuIGlz
IG5vdCB0aGF0IGl0J3MgaW1wb3NzaWJsZSBvciBldmVuIHBhcnRpY3VsYXJseSBoYXJkIHRvIGNh
dGNoDQo+IHRoZXNlIGVycm9ycywgYnV0IEkgZGlzbGlrZSB0aGUgcHJvcGVydHkgdGhhdCBzb21l
IChpbiBmYWN0LCBtb3N0KSBlbmNvZGFibGUNCj4gdmFsdWVzIGFyZSBpbnZhbGlkLg0KPg0KPg0K
Pg0KPiBCZXN0LA0KPg0KPiBNYXJ0ZW4NCj4NCj4NCj4NCj4NCj4NCj4gT24gV2VkLCBKdW4gMjAs
IDIwMTggYXQgMzoyMSBBTSBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29tPG1h
aWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4gd3JvdGU6DQo+DQo+IEhpIElhbiwNCj4N
Cj4NCj4NCj4gSGVyZSBpcyBhbm90aGVyIGF0dGVtcHQgdG8gc29sdmUgdGhlIG9iamVjdGlvbnMg
eW91IHJhaXNlZDoNCj4NCj4NCj4NCj4+SSdtIG5vdCBhIGZhbiBvZiB0aGlzIHByb3Bvc2FsLCBi
ZWNhdXNlIEkgdGhpbmsgaXQgaXMgaW1wcmFjdGljYWwgdG8gZHJvcA0KPj4gdGhlIG51bWJlciBv
ZiBhY2sgYmxvY2tzLCBiZWNhdXNlIHdpdGggdGhlIEVDTiBwcm9wb3NhbCBpdCBiZWNvbWVzDQo+
PiBpbXByYWN0aWNhbGx5IGNvbXBsZXggdG8gcGFyc2UuDQo+DQo+IElzIHRoZXJlIGEgcmVhc29u
IHRoZSBwcm9wb3NhbCBmcm9tIENocmlzdGlhbiBkb2VzIG5vdCBzb2x2ZSB0aGlzIHByb2JsZW0/
DQo+DQo+DQo+DQo+PklmIHdlIGRvbid0IHJlbW92ZSB0aGUgbnVtYmVyIG9mIGFjayBibG9ja3Ms
IHRoZW4gdGhlIGFjayBmcmFtZSBpcyBsYXJnZXIsDQo+PiBidXQgSSBkb24ndCB0aGluayB0aGUg
ZXh0cmEgc2l6ZSBmaWVsZCBpcyB1c2VmdWwgZm9yIG1vc3QgaW1wbGVtZW50YXRpb25zLg0KPj4g
QWxzbywgaXQgbWVhbnMgdGhlIGxlbmd0aCBjYW4gZGlzYWdyZWUgd2l0aCB0aGUgYWN0dWFsIGxl
bmd0aCwgd2hpY2ggYWRkDQo+PiBjb21wbGV4aXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgb2Ygd3Jp
dGluZyBlcnJvci1wcm9uZSBjb2RlLiAgVGhlIGlkZWEgb2YNCj4+IHNvbWVvbmUgb2ZmbG9hZGlu
ZyBhY2sgcHJvY2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRydXN0IHRoZSBsZW5ndGgN
Cj4+IHNlZW1zIGxpa2Ugc29tZW9uZSBjb3VsZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29u
Y2VybmluZyBpc3N1ZXMuDQo+DQo+IFRoZSByaXNrIG9mIGRpc2FncmVlbWVudCBiZXR3ZWVuIGFj
ayBibG9ja3MgYW5kIGFjayBibG9jayBjb3VudCBpcyBzYW1lIGFzDQo+IHRoZSByaXNrIG9mIGRp
c2FncmVlbWVudCBiZXR3ZWVuIGFjayBibG9ja3MgYW5kIGFjayBsZW5ndGguIEVpdGhlciB3YXkg
dGhpcw0KPiBuZWVkcyB0byBiZSBjb3VudGVkIHVwIHdoaWxlIGNyZWF0aW5nIHRoZSBBQ0sgYW5k
IGNvdW50ZWQgZG93biB3aGlsZSBwYXJzaW5nDQo+IGl0LiBUaGUgcG9zc2liaWxpdHkgb2YgZXJy
b3IgaXMgdGhlIHNhbWUuIEdldHRpbmcgdGhlIGFjayBibG9jayBjb3VudCB3cm9uZw0KPiBpcyBh
cyBwcm9ibGVtYXRpYyBhcyBnZXR0aW5nIHRoZSBhY2sgbGVuZ3RoIHdyb25nLiBEbyB5b3UgYWdy
ZWU/DQo+DQo+DQo+DQo+Pk15IGV4cGVyaWVuY2UgaXMgbXVsdGl0aHJlYWRlZCBwYWNrZXQgcHJv
Y2Vzc2luZyBpcyBtb3JlIGNvc3QgYW5kIHdvcmsgdGhhbg0KPj4gaXQncyB3b3J0aC4gIFN1cmUg
eW91IGNhbid0IGZpbGwgYSAxMDBHIE5JQyB3aXRoIG9uZSBjb25uZWN0aW9uLCBidXQgdGhhdA0K
Pj4gc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3JrbG9hZHMg
SSd2ZSBzZWVuLiAgVHlwaWNhbGx5DQo+PiB0aGUgZXh0cmEgY29zdCBvZiBtdWx0aXRocmVhZGlu
ZyBvdXR3ZWlnaHMgaXRzIHZhbHVlLg0KPg0KPiBUaGUgdmFsdWUgaXMgdHdvIGZvbGQg4oCTIHBy
ZS1wcm9jZXNzaW5nIGFuZCBtdWx0aS10aHJlYWRpbmcuIElmIHdlDQo+IHByZS1wcm9jZXNzIHRo
ZSByZWNlaXZlZCBwYWNrZXRzIHN1Y2ggdGhhdCBBQ0tzIGFuZCBzdHJlYW1zIGNhbiBiZQ0KPiBj
b2FsZXNjZWQsIHRoZSByZWNlaXZlIHNpZGUgY2FuIGluZGljYXRlIGEgbGFyZ2UgY2h1bmsgb2Yg
aW5mb3JtYXRpb24gdGhvdWdoDQo+IHRoZSBrZXJuZWwsIHJlZHVjaW5nIHRoZSBjb3N0IG9mIHN5
c3RlbSBjYWxsIGFuZCBwcm90b2NvbCBvdmVyaGVhZC4gVGhpcyBpcw0KPiB0aGUgc2FtZSBjb25j
ZXB0IGFzIFVEUCBzZWdtZW50YXRpb24gdGFrZW4gYSBzdGVwIGZ1cnRoZXIgb24gcmVjZWl2ZSBz
aWRlLg0KPiBBZnRlciB0aGlzIGNodW5rIGlzIGluZGljYXRlZCBpbnRvIHRoZSBRVUlDIHByb3Rv
Y29sLCB0aGUgcHJvdG9jb2wgbWF5DQo+IHByb2Nlc3Mgc3RyZWFtIGFuZCBBQ0sgaW4gcGFyYWxs
ZWwuIFdoaWxlIGZvbGtzIG1heSBvciBtYXkgbm90IHV0aWxpemUgdGhpcywNCj4gdGhlcmUgaXMg
YW4gYWR2YW50YWdlIGhlcmUuDQo+DQo+DQo+DQo+IFRoYW5rcywNCj4NCj4gTWFuYXNpDQo+DQo+
DQo+DQo+DQo+DQo+IEZyb206IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb208
bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+XQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAy
MDE4IDExOjI2IEFNDQo+IFRvOiBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuLmRldmFsQGludGVsLmNv
bTxtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbT4+DQo+IENjOiBNYXJ0ZW4gU2VlbWFubiA8
bWFydGVuc2VlbWFubkBnbWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPj47
IEthenVobyBPa3UNCj4gPGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFp
bC5jb20+PjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+
PjsgSmFuYSBJeWVuZ2FyDQo+IDxqcmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpyaS5pZXRmQGdt
YWlsLmNvbT4+OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxt
YWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+OyBJRVRGDQo+IFFVSUMgV0cgPHF1aWNAaWV0Zi5v
cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u
QGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4NCj4NCj4NCj4gU3Vi
amVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxl
bmd0aA0KPg0KPg0KPg0KPiBJJ20gc3RpbGwgbm90IGludGVyZXN0ZWQgaW4gdGhpcyBjaGFuZ2Us
IGZvciB0aGUgcmVhc29ucyBJIHN0YXRlZCBhYm92ZS4NCj4NCj4NCj4NCj4gT24gVHVlLCBKdW4g
MTksIDIwMTggYXQgMjoyMSBQTSBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2YWxAaW50ZWwuY29t
PG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4gd3JvdGU6DQo+DQo+IEhpIEFsbCwN
Cj4NCj4NCj4NCj4gRG8gd2UgaGF2ZSBhZ3JlZW1lbnQgaGVyZSB0byBjcmVhdGUgYSBuZXcgUFI/
DQo+DQo+DQo+DQo+IFRoYW5rcywNCj4NCj4gTWFuYXNpDQo+DQo+DQo+DQo+IEZyb206IERldmFs
LCBNYW5hc2kNCj4gU2VudDogU3VuZGF5LCBKdW5lIDE3LCAyMDE4IDI6MjUgUE0NCj4gVG86IE1h
cnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFu
bkBnbWFpbC5jb20+PjsgS2F6dWhvIE9rdQ0KPiA8a2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86
a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQo+IENjOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xl
LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9yZz4+
OyBFcmljIFJlc2NvcmxhDQo+IDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBK
YW5hIEl5ZW5nYXIgPGpyaS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86anJpLmlldGZAZ21haWwuY29t
Pj47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQo+IDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0
bzpwcmF2YkBtaWNyb3NvZnQuY29tPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWls
dG86cXVpY0BpZXRmLm9yZz4+OyBNYXJ0aW4gVGhvbXNvbg0KPiA8bWFydGluLnRob21zb25AZ21h
aWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KPiBTdWJqZWN0OiBSRTog
UHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0aCBBQ0sgbGVuZ3RoDQo+DQo+
DQo+DQo+IEhpIEFsbCwNCj4NCj4NCj4NCj4gSSBoYXZlIG1hZGUgYSBsaXN0IG9mIG9iamVjdGlv
bnMgdG8gdGhlIHByb3Bvc2FsIGFuZCB0aGUgc29sdXRpb25zIHRvIHRob3NlDQo+IG9iamVjdGlv
bnMgZGlzY3Vzc2VkIG9uIHRoaXMgdGhyZWFkLg0KPg0KPg0KPg0KPiBhLiAgICAgIENvLWV4aXN0
ZW5jZSBvZiBsZW5ndGggZmllbGQgd2l0aCBFQ04gZmllbGQgYW5kIEFDSyBibG9ja3MuDQo+DQo+
DQo+DQo+IENocmlzdGlhbiBzdWdnZXN0ZWQgdG8gbW92ZSB0aGUgRUNOIGZpZWxkcyB0byBwcmVj
ZWRlIHRoZSBBQ0sgYmxvY2tzLiBUaGlzDQo+IGlzIGFuIGVsZWdhbnQgc29sdXRpb24uIFBhcnNp
bmcgZW50aXJlIGxpc3Qgb2YgQUNLIGJsb2NrcyB0byByZXZpZXcgRUNOIGJpdHMNCj4gd291bGQg
aGF2ZSBiZWVuIGFubm95aW5nLCBldmVuIHRob3VnaCBpdCBjYW4gd29yay4NCj4NCj4NCj4NCj4g
Yi4gICAgICBUaGVyZSBhcmUgdHdvIGNhc2VzIHRvIGJlIHBhcnNlZCDigJMgZW50aXJlIEFDSyBh
bmQgcGFyc2UgQUNLIHRvDQo+IGlkZW50aWZ5IGxlbmd0aC4gVGhlcmUgYXJlIHNvbWUgcmVzZXJ2
YXRpb25zIHdoZW4gQUNLIHBhcnNpbmcgZ2V0cyBoYXJkZXINCj4gZm9yIHRoZSBjYXNlIHdoZXJl
IHRoZSBlbnRpcmUgaGVhZGVyIG5lZWRzIHRvIGJlIHBhcnNlZC4NCj4NCj4NCj4NCj4gQWdyZWVt
ZW50IGZyb20gc2V2ZXJhbCBmb2xrcyBoZXJlLiBJbiB0aGUgb3JpZ2luYWwgQUNLIGRlZmluZWQg
aW4gZHJhZnQgMTINCj4gb2YgdGhlIHNsaWRlLCBvbmUgd291bGQgY291bnQgZG93biBudW1iZXIg
b2YgQUNLIGJsb2NrcyB0byBnZXQgdG8gdGhlIGVuZCBvZg0KPiB0aGUgcGFja2V0LiBJbiB0aGUg
cHJvcG9zYWwgSSBtYWRlLCBvbmUgd291bGQgY291bnQgZG93biB0aGUgbGVuZ3RoIHRvDQo+IGlk
ZW50aWZ5IHRoZSBlbmQgb2YgdGhlIHBhY2tldC4gVGhlIGxvZ2ljIGlzIHZlcnkgc2ltaWxhciBp
biBjeWNsZSBjb3VudCBhbmQNCj4gY29tcGxleGl0eS4gU2V2ZXJhbCBmb2xrcyBhbHNvIGNvbW1l
bnRlZCB0byB0aGlzIGVmZmVjdC4NCj4NCj4NCj4NCj4gYy4gICAgICBNdWx0aS10aHJlYWRlZCBw
YWNrZXQgcHJvY2Vzc2luZw0KPg0KPg0KPg0KPiBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZXJlIGFy
ZSAxMHMgb2YgMTAwMHMgb2YgY29ubmVjdGlvbnMgaW4gdXNlIGF0IGFueSB0aW1lDQo+IGZvciBh
IHNlcnZlciB3aXRoIGEgaGlnaCBzcGVlZCBsaW5rLiBNdWx0aS10aHJlYWRpbmcgdG8gaGFuZGxl
IGVhY2ggb2YgdGhlc2UNCj4gZmxvd3MgLyBjb25uZWN0aW9ucyBpbiBwYXJhbGxlbCBpcyBuZWNl
c3NpdHkgdG8gYmUgYWJsZSB0byBzdXBwb3J0IGxhcmdlDQo+IG51bWJlciBvZiBjb25uZWN0aW9u
cyBvbiBhIGhpZ2ggc3BlZWQgbGluay4gVHggc2VnbWVudGF0aW9uLCBSeCBjb2FsZXNjaW5nDQo+
IGFyZSB3ZWxsIGtub3duIHN0cmF0ZWdpZXMgdG8gcmVkdWNlIHRoZSBwcm9jZXNzaW5nIGNvc3Qu
IEluIGluaXRpYWwgc3RhZ2VzLA0KPiBjb2RlIGlzIG9mdGVuIHdyaXR0ZW4gYXMgYSBzaW5nbGUt
dGhyZWFkZWQgYW5kIHRoZW4gcmUtZmFjdG9yZWQgdG8NCj4gcGFyYWxsZWxpemUgY3ljbGUgaW50
ZW5zaXZlIG9wZXJhdGlvbnMuIEluIG9yZGVyIHRvIGFsbG93IHRoaXMgcHJvdG9jb2wgdG8NCj4g
c2NhbGUgaW4gZnV0dXJlLCBJIHdvdWxkIHN1Z2dlc3Qgd2UgZG8gbm90IHByZWNsdWRlIHRoaXMg
Y2FzZS4NCj4NCj4NCj4NCj4gZC4gICAgICBJbmNyZWFzZSBpbiBBQ0sgc2l6ZSBieSAxIGJ5dGUu
DQo+DQo+DQo+DQo+IEkgZG8gbm90IHNlZSB0aGlzIGFzIGEgc2VyaW91cyBpc3N1ZSBidXQgaWYg
Zm9sa3MgYnV0IHdlIGNhbiBjb25zaWRlciBtYWtpbmcNCj4gdGhpcyBhIHZhcmludCwgaWYgb3Ro
ZXJzIGhhdmUgc3Ryb25nIGZlZWxpbmdzIGFib3V0IGl0LiBJdOKAmXMgYSB0cmFkZS1vZmYgOiAy
DQo+IHJlYWRzIHRvIHNhdmUgMSBieXRlLg0KPg0KPg0KPg0KPiBlLiAgICAgIEV2ZXJ5IGVuY29k
YWJsZSB2YWx1ZSBzaG91bGQgYmUgdmFsaWQNCj4NCj4gTm90IGV2ZXJ5IGxlbmd0aCB3aWxsIGJl
IHZhbGlkLiBUaGlzIGlzIGluaGVyZW50IHRvIGxlbmd0aHMuIFRoaXMgc2FtZSBpc3N1ZQ0KPiBh
aWxzIHRoZSDigJhwYXlsb2FkIGxlbmd0aOKAmSBpbiBRVUlDIGhlYWRlci4gTm90IG9ubHkgZG9l
cyB0aGUgaXNzdWUgZXhpc3QgZm9yDQo+IHNtYWxsIHZhbHVlcywgaXQgYWxzbyBhcHBsaWVzIHRv
IGxhcmdlIHZhbHVlcyBzaW5jZSBkYXRhIHN0cmVhbSB3aWxsIGJlIHNlbnQNCj4gYWZ0ZXIgY3J5
cHRvIG5lZ290aWF0aW9uLiAgRS5nLiAgLSBob3cgZG9lcyBvbmUgY3JhZnQgYSBwYXlsb2FkIHdp
dGggNjIgYml0DQo+IHBheWxvYWQgbGVuZ3RoIGluIGEgbGFyZ2UgaGVhZGVyPw0KPg0KPg0KPg0K
Pg0KPg0KPiBUaGFua3MsDQo+DQo+IE1hbmFzaQ0KPg0KPg0KPg0KPg0KPg0KPiBGcm9tOiBNYXJ0
ZW4gU2VlbWFubiBbbWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPG1haWx0bzptYXJ0ZW5z
ZWVtYW5uQGdtYWlsLmNvbT5dDQo+IFNlbnQ6IFN1bmRheSwgSnVuZSAxNywgMjAxOCA2OjU5IEFN
DQo+IFRvOiBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VA
Z21haWwuY29tPj4NCj4gQ2M6IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJj
LmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi4ub3JnPj47IEVyaWMgUmVz
Y29ybGENCj4gPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj47IEphbmEgSXllbmdh
ciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+PjsgUHJhdmVl
biBCYWxhc3VicmFtYW5pYW4NCj4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1p
Y3Jvc29mdC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGll
dGYub3JnPj47IE1hcnRpbiBUaG9tc29uDQo+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFp
bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+OyBEZXZhbCwgTWFuYXNpIDxtYW5hc2kuZGV2
YWxAaW50ZWwuY29tPG1haWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tPj4NCj4gU3ViamVjdDog
UmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0K
Pg0KPg0KPg0KPiBNYXliZSBpdCdzIHNwZWNpZmljIHRvIEdvLCBidXQgSSdtIHVzaW5nIGEgc2lu
Z2xlIGlvLlJlYWRlciBmb3IgdGhlIHdob2xlDQo+IHBhY2tldCwgc28gYXMgbG9uZyBhcyB0aGUg
cGFja2V0IHBheWxvYWQgaXMgbG9uZyBlbm91Z2gsIHRoZSB2YXJpbnQgcGFyc2luZw0KPiB3aWxs
IG5vdCBmYWlsLg0KPg0KPiBJIGRvbid0IHRoaW5rIHRoYXQgc3BlY2lmaWNzIG9mIHByb2dyYW1t
aW5nIGxhbmd1YWdlcyBtYXR0ZXIgaGVyZSB0aG91Z2gsDQo+IGFuZCBJJ20gc3VyZSBib3RoIGZy
YW1lIGZvcm1hdHMgY2FuIGJlIHJlYXNvbmFibHkgaW1wbGVtZW50ZWQgaW4gQyBhcyB3ZWxsDQo+
IGFzIGluIEdvLiBUaGUgcmVhc29ucyBJJ20gb3Bwb3NlZCB0byBNYW5hc2kncyBwcm9wb3NhbCBh
cmUgdGhhdCBpdCBtb3ZlcyB1cw0KPiBhd2F5IGZyb20gdGhlIHByaW5jaXBsZSB0aGF0IG9ubHkg
cmVhc29uYWJsZSB2YWx1ZXMgc2hvdWxkIGJlIGVuY29kYWJsZSwgYW5kDQo+IHRoYXQgaXQgaW5j
cmVhc2VzIHRoZSBzaXplIG9mIHRoZSBBQ0sgZnJhbWUsIGZvciB0aGUgcXVlc3Rpb25hYmxlIGJl
bmVmaXQgb2YNCj4gYmVpbmcgYWJsZSB0byBwYXJhbGxlbGlzZSB0aGUgZnJhbWUgcGFyc2VyLg0K
Pg0KPg0KPg0KPiBPbiBTdW4sIEp1biAxNywgMjAxOCBhdCA4OjQ4IFBNIEthenVobyBPa3UgPGth
enVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVob29rdUBnbWFpbC5jb20+PiB3cm90ZToNCj4N
Cj4gMjAxOC0wNi0xNyAyMjozNiBHTVQrMDk6MDAgTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1h
bm5AZ21haWwuY29tPG1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbT4+Og0KPj4gQXQgbGVh
c3QgZm9yIG15IGltcGxlbWVudGF0aW9uLCBwYXJzaW5nIGRvZXNuJ3QgYmVjb21lIGVhc2llciwg
aXQgYmVjb21lcw0KPj4gbW9yZSBjb21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4gTXkgdmFyaW50
LXBhcnNlciBhbHdheXMgY29uc3VtZXMgYXMgbWFueQ0KPj4gYnl0ZXMgYXMgdGhlIHZhcmludCBy
ZXF1aXJlcywgc28gYWZ0ZXIgcGFyc2luZyBhIHZhcmludCwgSSdkIGhhdmUgdG8NCj4+IGludHJv
ZHVjZSBhbiBhZGRpdGlvbmFsIGNoZWNrIHRoYXQgdGhpcyBkaWRuJ3Qgb3ZlcmZsb3cgdGhlIEFD
SyBsZW5ndGgNCj4+IChlLmcuDQo+PiBjb25zaWRlciB0aGF0IEkgcGFyc2VkIHRoZSBBQ0sgZnJh
bWUgc28gZmFyIHRoYXQgb25seSAyIGJ5dGVzIGFyZQ0KPj4gcmVtYWluaW5nDQo+PiBhY2NvcmRp
bmcgdG8gQUNLIGxlbmd0aCBmaWVsZCwgYnV0IHRoZSBuZXh0IHZhcmludCBpcyA0IGJ5dGVzIGxv
bmcpLg0KPg0KPiBJc24ndCB5b3VyIHZhcmludCBwYXJzZXIgY2hlY2tpbmcgdGhhdCBpdCBoYXMg
bm90IChvciB3aWxsIG5vdCkgcnVuDQo+IGFjcm9zcyB0aGUgZW5kIG9mIHRoZSBwYWNrZXQgcGF5
bG9hZCBmb3IgZXZlcnkgQUNLIGJsb2NrIGl0IHBhcnNlcz8NCj4gSSdkIGFzc3VtZSB0aGF0IHlv
dSB3b3VsZCBiZSBkb2luZyB0aGF0LCBiZWNhdXNlIEkgdGhpbmsgdGhhdCBpcw0KPiBuZWNlc3Nh
cnkgdG8gYXZvaWQgYnVmZmVyIG92ZXJydW4uDQo+DQo+IFdoYXQgSSBhbSBzYXlpbmcgdGhhdCB0
aGF0IGNoZWNrIGNvdWxkIGJlIGNvbnZlcnRlZCB0byBhIG92ZXJydW4gY2hlY2sNCj4gYWdhaW5z
dCB0aGUgZW5kIG9mIHRoZSAiZnJhbWUgcGF5bG9hZCIsIGFuZCB0aGF0IGNoZWNraW5nIHRoZQ0K
PiByZW1haW5pbmcgYmxvY2sgY291bnQgYmVjb21lcyB1bm5lY2Vzc2FyeSwgaW4gY2FzZSB3ZSBy
ZXBsYWNlIEFDSw0KPiBCbG9jayBDb3VudCB3aXRoIEFDSyBGcmFtZSBMZW5ndGguDQo+DQo+Pg0K
Pj4gSW4gZ2VuZXJhbCwgd2UndmUgYmVlbiBtb3ZpbmcgdGhlIHdpcmUgaW1hZ2UgdG93YXJkcyBt
YWtpbmcgZXZlcnkNCj4+IGVuY29kYWJsZQ0KPj4gdmFsdWUgdmFsaWQuIFRoaXMgcHJvcG9zYWwg
bW92ZXMgdXMgYXdheSBmcm9tIHRoYXQgcHJpbmNpcGxlOg0KPj4gKiBzb21lIHNtYWxsIHZhbHVl
cyBhcmUgYWx3YXlzIGludmFsaWQgKHRoZSBsZW5ndGggY2FuIG5ldmVyIGJlIGJldHdlZW4gMA0K
Pj4gYW5kIDMpDQo+PiAqIGEgbG90IG9mIGludGVybWVkaWF0ZSB2YWx1ZXMgYXJlIGludmFsaWQg
KGlmIHRoZSBib3VuZGFyeSBmYWxscyBpbnNpZGUgYQ0KPj4gdmFyaW50LCBhcyBkZXNjcmliZWQg
YWJvdmUpDQo+PiBCb3RoIHRoZXNlIGNhc2VzIGNhbid0IG9jY3VyIHdpdGggdGhlIGN1cnJlbnQg
QUNLIGZyYW1lIGZvcm1hdC4uDQo+Pg0KPj4gT24gU3VuLCBKdW4gMTcsIDIwMTggYXQgNzo1NCBQ
TSBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwu
Y29tPj4gd3JvdGU6DQo+Pj4NCj4+PiAyMDE4LTA2LTE3IDg6MzQgR01UKzA5OjAwIElhbiBTd2V0
dA0KPj4+IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29v
Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+Og0KPj4+ID4gSSdtIG5vdCBhIGZhbiBvZiB0aGlzIHBy
b3Bvc2FsLCBiZWNhdXNlIEkgdGhpbmsgaXQgaXMgaW1wcmFjdGljYWwgdG8NCj4+PiA+IGRyb3AN
Cj4+PiA+IHRoZSBudW1iZXIgb2YgYWNrIGJsb2NrcywgYmVjYXVzZSB3aXRoIHRoZSBFQ04gcHJv
cG9zYWwgaXQgYmVjb21lcw0KPj4+ID4gaW1wcmFjdGljYWxseSBjb21wbGV4IHRvIHBhcnNlLg0K
Pj4+DQo+Pj4gRm9yIHRoZSBFQ04gcHJvcG9zYWwsIGFzIENocmlzdGlhbiBoYXMgc3VnZ2VzdGVk
LCB3ZSBjYW4gbW92ZSB0aGUgRUNODQo+Pj4gY291bnRlcnMgYmVmb3JlIHRoZSBBQ0sgYmxvY2tz
LiBUaGVuLCBpdCB3b3VsZCBub3QgYmUgY29tcGxleCB0bw0KPj4+IHBhcnNlLg0KPj4+DQo+Pj4g
QW5kIG15IHZpZXcgaXMgdGhhdCBwYXJzaW5nIGJlY29tZXMgZWFzaWVyIGlmIHdlIHJlcGxhY2Ug
QUNLIEJsb2NrDQo+Pj4gQ291bnQgd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLg0KPj4+DQo+Pj4gTm93
LCB3aXRoIEFDSyBCbG9jayBDb3VudCwgd2UgbmVlZCB0byBjaGVjayB0aGUgcmVtYWluaW5nIG51
bWJlciBvZg0KPj4+IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBzcGFjZSBpbiB0aGUgcGFja2V0
IHBheWxvYWQgZm9yIGV2ZXJ5IGJsb2NrDQo+Pj4gdGhhdCB3ZSBwYXJzZS4gRmFpbGluZyB0byBj
aGVjayBlaXRoZXIgbGVhZHMgdG8gYSBidWcgb3IgYSBzZWN1cml0eQ0KPj4+IGlzc3VlLg0KPj4+
DQo+Pj4gSWYgd2Ugc3dpdGNoIHRvIEFDSyBGcmFtZSBMZW5ndGgsIHdlIG5lZWQgdG8gb25seSBj
aGVjayB0aGUgcmVtYWluaW5nDQo+Pj4gc3BhY2UgaW4gdGhlIGZyYW1lLg0KPj4+DQo+Pj4gSSB0
aGluayB0aGF0IHRoaXMgaXMgdGhlIGJpZ2dlc3QgYmVuZWZpdCBvZiByZXBsYWNpbmcgQUNLIEJs
b2NrIENvdW50DQo+Pj4gd2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLiBPVE9IIHRoZSBkb3duc2lkZSBp
cyB0aGF0IHlvdSBuZWVkIGV4dHJhIG9uZSB0bw0KPj4+IHR3byBiaXRzIChvbmUgaWYgdGhlIHNp
emUgb2YgYmxvY2sgLyBnYXAgaXMgZXhwZWN0ZWQgdG8gYmUgYmVsb3cgNjUsDQo+Pj4gdHdvIGlm
IHRoZXkgYXJlIGV4cGVjdGVkIHRvIGJlIGFib3ZlIHRoYXQpIGZvciBlbmNvZGluZyBBQ0sgRnJh
bWUNCj4+PiBMZW5ndGggY29tcGFyZWQgdG8gQUNLIEJsb2NrIENvdW50Lg0KPj4+DQo+Pj4NCj4+
Pg0KPj4+IEhhdmluZyBzYWlkIHRoYXQsIEkgaG9uZXN0bHkgd29uZGVyIGlmIGFsbCB0aGUgZnJh
bWVzIGNvdWxkIGhhdmUgaXQncw0KPj4+IGxlbmd0aCBiZWluZyBlbmNvZGVkIChlaXRoZXIgZXhw
bGljaXRseSBvciBlaXRoZXIgYXMgYSBzaWduYWwgdGhhdA0KPj4+IHNheXMgInRvIHRoZSBlbmQg
b2YgdGhlIHBhY2tldCIpLiBDb25zaWRlciBzb21ldGhpbmcgbGlrZSBiZWxvdzoNCj4+Pg0KPj4+
IHwwfCBmcmFtZS10eXBlICg3KSB8IGZyYW1lLXBheWxvYWQtbGVuZ3RoIChpKSB8IGZyYW1lLXBh
eWxvYWQgKCopIHwNCj4+PiAgb3INCj4+PiB8MXwgZnJhbWUtdHlwZSAoNykgfCBmcmFtZS1wYXls
b2FkICgqKSB8DQo+Pj4NCj4+PiBXaGVuIE1TQiBvZiB0aGUgZmlyc3Qgb2N0ZXQgc2V0IHRvIHpl
cm8sIHRoZSBsZW5ndGggb2YgdGhlIGZyYW1lDQo+Pj4gcGF5bG9hZCBpcyBkZXNpZ25hdGVkIGJ5
IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBmcmFtZQ0KPj4+IHR5cGUu
DQo+Pj4gV2hlbiBNU0Igb2YgdGhlIGZpcnN0IG9jdGV0IHNldCB0byBvbmUsIHRoZSBsZW5ndGgg
b2YgdGhlIGZyYW1lDQo+Pj4gcGF5bG9hZCBzcGFucyB0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQu
DQo+Pj4NCj4+PiBJbiB0aGlzIGVuY29kaW5nLCB3ZSBjYW4gYWx3YXlzIG9taXQgdGhlIExlbmd0
aCBmaWVsZCBvZiBhIFNUUkVBTQ0KPj4+IGZyYW1lLiBTbyB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5
aW5nIHN0cmVhbSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJlbnQgaW4NCj4+PiBwcmFjdGljZS4NCj4+
Pg0KPj4+IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0aGUgQUNLIEJsb2NrIENvdW50
IGZpZWxkLiBBbmQgdGhlDQo+Pj4gb3ZlcmhlYWQgd2lsbCBiZSBvbmUgdG8gdHdvIGJpdHMgaWYg
dGhlIEFDSyBmcmFtZSBpcyBzZW50IGluIHRoZQ0KPj4+IG1pZGRsZSBvZiB0aGUgcGFja2V0ICh0
aGVyZWJ5IHVzaW5nIHRoZSBlbmNvZGluZyB3aXRoIGV4cGxpY2l0IGZyYW1lDQo+Pj4gcGF5bG9h
ZCBsZW5ndGgpLCBvciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBpcyB0aGUgbGFz
dCBmcmFtZQ0KPj4+IG9mIHRoZSBwYWNrZXQuDQo+Pj4NCj4+PiBXZSBhcmUgbGlrZWx5IHRvIHNl
ZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9zdCBvZiB0aGUgb3RoZXIgdHlwZXMNCj4+PiBv
ZiBmcmFtZXMsIGJ1dCBJIGRvIG5vdCB0aGluayB0aGF0IHdvdWxkIGJlIGFuIGlzc3VlIGNvbnNp
ZGVyaW5nIHRoYXQNCj4+PiB0aGV5IHdpbGwgYmUgZmFyIHNlbGRvbSBzZWVuIGNvbXBhcmVkIHRv
IFNUUkVBTXMgYW5kIEFDS3MuDQo+Pj4NCj4+PiBUbyBzdW1tYXJpemUsIG15IGFudGljaXBhdGlv
biBpcyB0aGF0IHdlIGNhbiBtYWtlIGFsbCB0aGUgZnJhbWVzDQo+Pj4gc2VsZi1jb250YWluZWQg
KGkuZS4gdGhlIGxlbmd0aCBjYW4gYmUgZGV0ZXJtaW5lZCB3aXRob3V0IHRoZQ0KPj4+IGtub3ds
ZWRnZSBvZiBob3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVyaGVhZCwg
aWYgd2UNCj4+PiBhZ3JlZSBvbiBtYWtpbmcgdGhlIGZyYW1lIHR5cGUgc3BhY2UgMSBiaXQgc21h
bGxlci4NCj4+Pg0KPj4+IEZpbmFsbHksIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBz
ZWxmLWNvbnRhaW5lZCBlbmNvZGluZyBvZg0KPj4+IGZyYW1lcyBpcyB0aGF0IHdlIHdvdWxkIGhh
dmUgdGhlIGFiaWxpdHkgdG8gaW50cm9kdWNlIG5ldyBvcHRpb25hbA0KPj4+IGZyYW1lcyB3aXRo
b3V0IG5lZ290aWF0aW9uLiBCeSBtYWtpbmcgdGhlIGZyYW1lcyBzZWxmLWNvbnRhaW5lZCwgUVVJ
Qw0KPj4+IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdub3JpbmcgdGhlIGZy
YW1lcyB0aGF0IHRoZXkgZG8NCj4+PiBub3QgdW5kZXJzdGFuZC4NCj4+Pg0KPj4+IEJlaW5nIGFi
bGUgdG8gc2VuZCBRVUlDIGZyYW1lcyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dA0KPj4+
IG5lZ290aWF0aW5nIHVzaW5nIFRyYW5zcG9ydCBQYXJhbWV0ZXJzIHdpbGwgYmUgYSB3aW4gaW4g
Ym90aCB0ZXJtcyBvZg0KPj4+IHNlY3VyaXR5IChiZWNhdXNlIGNsaWVudHMnIFRQIGlzIHNlbnQg
aW4gY2xlYXIpIGFuZCBmbGV4aWJpbGl0eQ0KPj4+IChiZWNhdXNlIHdlIHdpbGwgYmUgcG9zc2li
bGUgdG8gc2VuZCB0aGUgZXh0ZW5zaW9ucyBiZWZvcmUgd2UgZmlndXJlDQo+Pj4gb3V0IHdoZXRo
ZXIgdGhlIHBlZXIgc3VwcG9ydHMgdGhhdCBleHRlbnNpb24pLg0KPj4+DQo+Pj4gPiBJZiB3ZSBk
b24ndCByZW1vdmUgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCB0aGVuIHRoZSBhY2sgZnJhbWUg
aXMNCj4+PiA+IGxhcmdlciwNCj4+PiA+IGJ1dCBJIGRvbid0IHRoaW5rIHRoZSBleHRyYSBzaXpl
IGZpZWxkIGlzIHVzZWZ1bCBmb3IgbW9zdA0KPj4+ID4gaW1wbGVtZW50YXRpb25zLg0KPj4+ID4g
QWxzbywgaXQgbWVhbnMgdGhlIGxlbmd0aCBjYW4gZGlzYWdyZWUgd2l0aCB0aGUgYWN0dWFsIGxl
bmd0aCwgd2hpY2gNCj4+PiA+IGFkZA0KPj4+ID4gY29tcGxleGl0eSBhbmQgdGhlIHBvc3NpYmls
aXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUgY29kZS4gIFRoZSBpZGVhDQo+Pj4gPiBvZg0KPj4+
ID4gc29tZW9uZSBvZmZsb2FkaW5nIGFjayBwcm9jZXNzaW5nIGFuZCB0aGVuIHByb2NlZWRpbmcg
dG8gdHJ1c3QgdGhlDQo+Pj4gPiBsZW5ndGgNCj4+PiA+IHNlZW1zIGxpa2Ugc29tZW9uZSBjb3Vs
ZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMuDQo+Pj4gPg0KPj4+
ID4gTXkgZXhwZXJpZW5jZSBpcyBtdWx0aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1v
cmUgY29zdCBhbmQgd29yaw0KPj4+ID4gdGhhbg0KPj4+ID4gaXQncyB3b3J0aC4gIFN1cmUgeW91
IGNhbid0IGZpbGwgYSAxMDBHIE5JQyB3aXRoIG9uZSBjb25uZWN0aW9uLCBidXQNCj4+PiA+IHRo
YXQNCj4+PiA+IHNlZW1zIGxpa2UgYW4gYWNhZGVtaWMgcHJvYmxlbSwgbm90IG9uZSBmb3Igd29y
a2xvYWRzIEkndmUgc2Vlbi4NCj4+PiA+IFR5cGljYWxseQ0KPj4+ID4gdGhlIGV4dHJhIGNvc3Qg
b2YgbXVsdGl0aHJlYWRpbmcgb3V0d2VpZ2hzIGl0cyB2YWx1ZS4NCj4+PiA+DQo+Pj4gPiBUbyBi
ZSBjbGVhciwgSSBkb24ndCB0aGluayB0aGlzIGlzIGFuIGF3ZnVsIGlkZWEsIGJ1dCBJIGFsc28g
ZG9uJ3Qgc2VlDQo+Pj4gPiB0aGUNCj4+PiA+IHZhbHVlIGFuZCBpdCBhZGRzIGNvbXBsZXhpdHku
ICBJIHJlYWQgTWFuYXNpJ3MgZW1haWwsIGJ1dCBJIGRvbid0IHRoaW5rDQo+Pj4gPiBJDQo+Pj4g
PiB1bmRlcnN0YW5kIHdoeSBhbnkgb2YgdGhvc2UgbWF0dGVyIGluIHByYWN0aWNlLg0KPj4+ID4N
Cj4+PiA+IE9uIFNhdCwgSnVuIDE2LCAyMDE4IGF0IDQ6MTMgUE0gRXJpYyBSZXNjb3JsYSA8ZWty
QHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCj4+PiA+Pg0KPj4+ID4+IE9u
IEZyaSwgSnVuIDE1LCAyMDE4IGF0IDY6NDYgUE0sIE1hcnRlbiBTZWVtYW5uDQo+Pj4gPj4gPG1h
cnRlbnNlZW1hbm5AZ21haWwuY29tPG1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbT4+DQo+
Pj4gPj4gd3JvdGU6DQo+Pj4gPj4+DQo+Pj4gPj4+IFRoaXMgcHJvcG9zYWwgaW5jcmVhc2VzIHRo
ZSBzaXplIG9mIHRoZSBBQ0sgZnJhbWUgYnkgMSBieXRlIGluIHRoZQ0KPj4+ID4+PiBjb21tb24N
Cj4+PiA+Pj4gY2FzZSAobGVzcyB0aGFuIDYzIEFDSyByYW5nZXMpLCBzaW5jZSB0aGUgQUNLIGxl
bmd0aCBmaWVsZCBoZXJlDQo+Pj4gPj4+IGFsd2F5cw0KPj4+ID4+PiBjb25zdW1lcyAyIGJ5dGVz
LCB3aGVyZWFzIHRoZSBBQ0sgQmxvY2sgQ291bnQgaXMgYSB2YXJpYWJsZS1sZW5ndGgNCj4+PiA+
Pj4gaW50ZWdlci4NCj4+PiA+Pj4gQ29uc2lkZXJpbmcgaG93IG11Y2ggd29yayB3ZSBwdXQgaW50
byBtaW5pbWlzaW5nIHRoZSBzaXplIG9mIHRoZQ0KPj4+ID4+PiBmcmFtZXMsDQo+Pj4gPj4+IHRo
aXMgZmVlbHMgbGlrZSBhIHN0ZXAgaW4gdGhlIHdyb25nIGRpcmVjdGlvbi4uDQo+Pj4gPj4+DQo+
Pj4gPj4+IFJlZ2FyZGluZyB0aGUgcHJvY2Vzc2luZyBjb3N0LCBJIGFncmVlIHdpdGggRG1pdHJp
LiBIYW5kbGluZyBhbiBBQ0sNCj4+PiA+Pj4gZnJhbWUNCj4+PiA+Pj4gcmVxdWlyZXMgbG9vcGlu
ZyBvdmVyIGFuZCBtYWtpbmcgY2hhbmdlcyB0byBhIGRhdGEgc3RydWN0dXJlIHRoYXQNCj4+PiA+
Pj4ga2VlcHMNCj4+PiA+Pj4gdHJhY2sgb2Ygc2VudCBwYWNrZXRzLiBUaGlzIGlzIG11Y2ggbW9y
ZSBleHBlbnNpdmUgdGhhbiBzaW1wbHkNCj4+PiA+Pj4gcGFyc2luZw0KPj4+ID4+PiBhDQo+Pj4g
Pj4+IGJ1bmNoIG9mIHZhcmludHMgaW4gdGhlIEFDSyBmcmFtZS4gSXQgc2VlbXMgdW5saWtlbHkg
dGhhdCBhDQo+Pj4gPj4+IG11bHRpLXRocmVhZGVkDQo+Pj4gPj4+IHBhY2tldCBwYXJzZXIgd291
bGQgb2ZmZXIgYW55IHJlYWwtd29ybGQgcGVyZm9ybWFuY2UgYmVuZWZpdHMuDQo+Pj4gPj4NCj4+
PiA+Pg0KPj4+ID4+IEkgZG9uJ3Qgd2FudCB0byBvdmVyc3RhdGUgdGhlIGJlbmVmaXQgaGVyZSwg
YnV0IG15IHBvaW50IGlzbid0IHRoYXQNCj4+PiA+PiBwYXJzaW5nIGlzIGV4cGVuc2l2ZSBidXQg
dGhhdCBpZiB5b3Ugd2FudCB0byBoYXZlIGEgbXVsdGl0aHJlYWRlZA0KPj4+ID4+IHBhY2tldA0K
Pj4+ID4+IHByb2Nlc3Npbmcgc3lzdGVtLCB0aGVuIGl0J3MgbmljZSB0byBoYXZlIGEgc2ltcGxl
ciBkYXRhIHN0cnVjdHVyZQ0KPj4+ID4+ICh0aGUNCj4+PiA+PiB1bnBhcnNlZCBBQ0sgYmxvY2sp
IHRvIGhhbmQgdG8gdGhlIEFDSyBwcm9jZXNzaW5nIHRocmVhZC4NCj4+PiA+Pg0KPj4+ID4+IC1F
a3INCj4+PiA+Pg0KPj4+ID4+DQo+Pj4gPj4+DQo+Pj4gPj4+IE9uIFNhdCwgSnVuIDE2LCAyMDE4
IGF0IDY6MTkgQU0gTWFydGluIFRob21zb24NCj4+PiA+Pj4gPG1hcnRpbi50aG9tc29uQGdtYWls
LmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4NCj4+PiA+Pj4gd3JvdGU6DQo+
Pj4gPj4+Pg0KPj4+ID4+Pj4gV2hlbiB3ZSBkaXNjdXNzZWQgdGhpcyBiZWZvcmUsIHNvbWUgcGVv
cGxlIG9ic2VydmVkIHRoYXQgdGhpcw0KPj4+ID4+Pj4gY3JlYXRlcw0KPj4+ID4+Pj4gYSBuZWVk
IHRvIGVuY29kZSBpbiB0d28gcGFzc2VzLiAgVGhhdCdzIHRoZSB0cmFkZS1vZmYgaGVyZS4gIChO
b3QNCj4+PiA+Pj4+IGV4cHJlc3NpbmcgYW4gb3Bpbmlvbi4pDQo+Pj4gPj4+PiBPbiBGcmksIEp1
biAxNSwgMjAxOCBhdCAzOjUxIFBNIEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1h
aWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+Pg0KPj4+ID4+Pj4gd3JvdGU6DQo+Pj4gPj4+PiA+DQo+
Pj4gPj4+PiA+IEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIG9uIHRoaXMuIEknbSBjZXJ0
YWlubHkgbm90IG9wcG9zZWQNCj4+PiA+Pj4+ID4gdG8NCj4+PiA+Pj4+ID4gaXQuDQo+Pj4gPj4+
PiA+IERvZXMgYW55b25lIGhhdmUgYSBzdHJvbmcgb3Bwb3NpdGlvbj8NCj4+PiA+Pj4+ID4NCj4+
PiA+Pj4+ID4gT24gRnJpLCBKdW4gMTUsIDIwMTggYXQgMzoxMCBQTSBQcmF2ZWVuIEJhbGFzdWJy
YW1hbmlhbg0KPj4+ID4+Pj4gPiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWlj
cm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+IEkgYWdyZWUgYXMg
d2VsbCBzaW5jZSB0aGlzIGNhbiBoZWxwIHJlZHVjZSBwZXIgcGFja2V0IHByb2Nlc3NpbmcNCj4+
PiA+Pj4+ID4+IG92ZXJoZWFkLiBBQ0tzIGFyZSBnb2luZyB0byBiZSB0aGUgc2Vjb25kIG1vc3Qg
Y29tbW9uIGZyYW1lIHR5cGUNCj4+PiA+Pj4+ID4+IHNvIG5vDQo+Pj4gPj4+PiA+PiBvYmplY3Rp
b25zIHRvIHNwZWNpYWwgY2FzaW5nLg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+Pj4gPj4+
PiA+Pg0KPj4+ID4+Pj4gPj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y
ZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVyaWMNCj4+PiA+
Pj4+ID4+IFJlc2NvcmxhDQo+Pj4gPj4+PiA+PiBTZW50OiBGcmlkYXksIEp1bmUgMTUsIDIwMTgg
OToxMSBBTQ0KPj4+ID4+Pj4gPj4gVG86IERldmFsLCBNYW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRl
bC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20+Pg0KPj4+ID4+Pj4gPj4gQ2M6IEph
bmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20+
PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQo+Pj4gPj4+
PiA+PiBTdWJqZWN0OiBSZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sgY291bnQgd2l0
aCBBQ0sgbGVuZ3RoDQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+Pj4g
Pj4+PiA+PiBJIGFncmVlIHdpdGggTWFuYXNpIGhlcmUuIFRoaXMgY2hhbmdlIHdvdWxkIGFsbG93
IGFjayBmcmFtZQ0KPj4+ID4+Pj4gPj4gcGFyc2luZw0KPj4+ID4+Pj4gPj4gdG8gYmUgbW9yZSBz
ZWxmLWNvbnRhaW5lZCwgd2hpY2ggaXMgYW4gYWR2YW50YWdlIGZvciB0aGUgcGFyc2VyDQo+Pj4g
Pj4+PiA+PiBhbmQgYWxzbw0KPj4+ID4+Pj4gPj4gcG90ZW50aWFsbHkgZm9yIHBhcmFsbGVsaXNt
IChiZWNhdXNlIHlvdSBjYW4gcXVpY2tseSBmaW5kIHRoZQ0KPj4+ID4+Pj4gPj4gZnJhbWUgYW5k
IHRoZW4NCj4+PiA+Pj4+ID4+IHByb2Nlc3MgaXQgaW4gcGFyYWxsZWwpLg0KPj4+ID4+Pj4gPj4N
Cj4+PiA+Pj4+ID4+DQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4gLUVrcg0KPj4+ID4+Pj4gPj4N
Cj4+PiA+Pj4+ID4+DQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+Pj4g
Pj4+PiA+PiBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA1OjIyIFBNLCBEZXZhbCwgTWFuYXNpDQo+
Pj4gPj4+PiA+PiA8bWFuYXNpLmRldmFsQGludGVsLmNvbTxtYWlsdG86bWFuYXNpLmRldmFsQGlu
dGVsLmNvbT4+IHdyb3RlOg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+IEluIGdlbmVyYWwsIHZh
cmludHMgcmVxdWlyZSBzb21lIHNwZWNpZmljIGxvZ2ljIGZvciBwYXJzaW5nLiBUbw0KPj4+ID4+
Pj4gPj4gc2tpcA0KPj4+ID4+Pj4gPj4gb3ZlciBhbnkgaGVhZGVyLCBJIGhhdmUgdG8gcmVhZCBl
dmVyeSBzaW5nbGUgdmFyaW50LiBBcyB0aGUgY29kZQ0KPj4+ID4+Pj4gPj4gc2VlcyBTdHJlYW0N
Cj4+PiA+Pj4+ID4+IGFuZCBBQ0sgaGVhZGVycyBtb3N0IGZyZXF1ZW50bHksIHRoYXQgaXMgbXkg
Zm9jdXMuICBUaGUgU3RyZWFtDQo+Pj4gPj4+PiA+PiBmcmFtZSBoYXMgYQ0KPj4+ID4+Pj4gPj4g
bGVuZ3RoIGluIGl0cyB0aGlyZCBmaWVsZC4NCj4+PiA+Pj4+ID4+DQo+Pj4gPj4+PiA+Pg0KPj4+
ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+IEFDSyBwYXJzaW5nLCBob3dldmVyLCBuZWVkcyA2ICsgMipu
dW1fYmxvY2tzIHJlYWRzIHRvIGlkZW50aWZ5DQo+Pj4gPj4+PiA+PiBsZW5ndGguIFRoZXJlIGFy
ZSB0d28gcmVhZHMgZWFjaCBmb3Ig4oCYbGFyZ2VzdCBhY2tub3dsZWRnZWTigJksIOKAmEFDSw0K
Pj4+ID4+Pj4gPj4gZGVsYXnigJkgYW5kDQo+Pj4gPj4+PiA+PiDigJhBQ0sgYmxvY2sgY291bnTi
gJkuIFRoZSBwYWluIHBvaW50IGlzIHRoZSB0b3RhbCBudW1iZXIgb2YgY3ljbGVzDQo+Pj4gPj4+
PiA+PiBwYXJzZSBhbg0KPj4+ID4+Pj4gPj4gQUNLLiBJZiBJIGFtIHByb2Nlc3NpbmcgMTBNIHBw
cywgd2hlcmUgMTAlIC0gMzAlIG9mIHRoZSBwYWNrZXRzDQo+Pj4gPj4+PiA+PiBoYXZlIGENCj4+
PiA+Pj4+ID4+IHBpZ2d5YmFja2VkIEFDSywgdGhlc2UgY3ljbGVzIGJlY29tZXMgYSBzaWduaWZp
Y2FudCBib3R0bGVuZWNrLg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+Pj4gPj4+PiA+Pg0K
Pj4+ID4+Pj4gPj4gVGhhbmtzLA0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+IE1hbmFzaQ0KPj4+
ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+
ID4+DQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+IEZyb206IFFVSUMgW21h
aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5d
IE9uIEJlaGFsZiBPZiBKYW5hDQo+Pj4gPj4+PiA+PiBJeWVuZ2FyDQo+Pj4gPj4+PiA+PiBTZW50
OiBNb25kYXksIEp1bmUgMTEsIDIwMTggMzoxMSBQTQ0KPj4+ID4+Pj4gPj4gVG86IERldmFsLCBN
YW5hc2kgPG1hbmFzaS5kZXZhbEBpbnRlbC5jb208bWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5j
b20+PjsgUVVJQyBXRw0KPj4+ID4+Pj4gPj4gPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0
Zi5vcmc+Pg0KPj4+ID4+Pj4gPj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNL
IGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aA0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+
Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4gWW91J3JlIHJpZ2h0IHRoYXQgd2Ugbm8gbG9uZ2VyIGhh
dmUgdGhlIGFiaWxpdHkgdG8gc2tpcCBhbiBBQ0sNCj4+PiA+Pj4+ID4+IGZyYW1lLA0KPj4+ID4+
Pj4gPj4gYW5kIHRoaXMgY3JlcHQgaW4gd2hlbiB3ZSBtb3ZlZCB0byB2YXJpbnRzLg0KPj4+ID4+
Pj4gPj4NCj4+PiA+Pj4+ID4+IEkgYmVsaWV2ZSB5b3VyIHByb2JsZW0gdGhvdWdoIGlzIGdlbmVy
YWxseSB0cnVlIG9mIG1vc3QgZnJhbWVzDQo+Pj4gPj4+PiA+PiBub3QNCj4+PiA+Pj4+ID4+IGp1
c3QgQUNLcywgc2luY2UgaWRzLCBwYWNrZXQgbnVtYmVycywgYW5kIG51bWJlcnMgaW4gYWxsIGZy
YW1lcw0KPj4+ID4+Pj4gPj4gYXJlIG5vdyBhbGwNCj4+PiA+Pj4+ID4+IHZhcmludHMuIFRvIHNr
aXAgYW55IGZyYW1lLCB5b3UnbGwgbmVlZCB0byBwYXJzZSB0aGUgdmFyaW50DQo+Pj4gPj4+PiA+
PiBmaWVsZHMNCj4+PiA+Pj4+ID4+IGluIHRob3NlDQo+Pj4gPj4+PiA+PiBmcmFtZXMuIElmIHlv
dSBoYXZlIGxvZ2ljIHRvIHByb2Nlc3MgYW5kIHNraXAgdmFyaW50cywgdGhlbg0KPj4+ID4+Pj4g
Pj4gc2tpcHBpbmcgdGhlIGFjaw0KPj4+ID4+Pj4gPj4gYmxvY2sgc2VjdGlvbiBpcyBtZXJlbHkg
cmVwZWF0aW5nIHRoaXMgb3BlcmF0aW9uICgyKm51bV9ibG9jaysxKQ0KPj4+ID4+Pj4gPj4gdGlt
ZXMuIERvDQo+Pj4gPj4+PiA+PiB5b3Ugc2VlIHNwZWNpZmljIHZhbHVlIGluIHNraXBwaW5nIEFD
SyBmcmFtZXMgb3ZlciB0aGUgb3RoZXINCj4+PiA+Pj4+ID4+IGNvbnRyb2wgZnJhbWVzPw0KPj4+
ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+DQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+
ID4+DQo+Pj4gPj4+PiA+PiBPbiBNb24sIEp1biAxMSwgMjAxOCBhdCA4OjQzIEFNIERtaXRyaSBU
aWtob25vdg0KPj4+ID4+Pj4gPj4gPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5jb20+IHdyb3Rl
Og0KPj4+ID4+Pj4gPj4NCj4+PiA+Pj4+ID4+IE9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDAzOjMz
OjM1UE0gKzAwMDAsIERldmFsLCBNYW5hc2kgd3JvdGU6DQo+Pj4gPj4+PiA+PiA+IC0gICAgICAg
IE1vdmluZyB0aGUgQUNLIGxlbmd0aCB0byB0aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3MNCj4+
PiA+Pj4+ID4+ID4gdGhlDQo+Pj4gPj4+PiA+PiA+ICAgICAgICAgIGZsZXhpYmlsaXR5IG9mIGVp
dGhlciByZWFkaW5nIHRoZSBlbnRpcmUgQUNLIG9yDQo+Pj4gPj4+PiA+PiA+IHJlYWRpbmcNCj4+
PiA+Pj4+ID4+ID4gdGhlDQo+Pj4gPj4+PiA+PiA+ICAgICAgICAgIGZpcnN0IDE2IGJpdHMgYW5k
IHNraXBwaW5nIG92ZXIgdGhlIGxlbmd0aC4gVGhpcyBpcyBhDQo+Pj4gPj4+PiA+PiA+IHVzZWZ1
bA0KPj4+ID4+Pj4gPj4gPiAgICAgICAgICBmZWF0dXJlIGZvciB0aGUgY2FzZSB3aGVyZSBBQ0sg
cHJvY2Vzc2luZyBpcyBzcGxpdA0KPj4+ID4+Pj4gPj4gPiBpbnRvDQo+Pj4gPj4+PiA+PiA+ICAg
ICAgICAgIG11bHRpcGxlIGxheWVycy4gRGVwZW5kaW5nIG9uIHRoZSBwcm9jZXNzb3IgdGhpcyBp
cw0KPj4+ID4+Pj4gPj4gPiBydW4NCj4+PiA+Pj4+ID4+ID4gb24sDQo+Pj4gPj4+PiA+PiA+ICAg
ICAgICAgIHRoZXJlIGFyZSBkaWZmZXJlbnQgYWR2YW50YWdlcyAtDQo+Pj4gPj4+PiA+Pg0KPj4+
ID4+Pj4gPj4gSnVzdCBhIG5vdGUuICBJbiBteSBleHBlcmllbmNlLCB0aGUgY29zdCBvZiBwYXJz
aW5nIGFuIEFDSyBmcmFtZQ0KPj4+ID4+Pj4gPj4gaXMNCj4+PiA+Pj4+ID4+IG5lZ2xpZ2libGUg
Y29tcGFyZWQgdG8gdGhlIGNvc3Qgb2YgcHJvY2Vzc2luZyBhbiBBQ0sgZnJhbWU6IHRoYXQNCj4+
PiA+Pj4+ID4+IGlzLA0KPj4+ID4+Pj4gPj4gcG9raW5nIGF0IHZhcmlvdXMgbWVtb3J5IGxvY2F0
aW9ucyB0byBkaXNjYXJkIG5ld2x5IEFDS2VkDQo+Pj4gPj4+PiA+PiBwYWNrZXRzLg0KPj4+ID4+
Pj4gPj4NCj4+PiA+Pj4+ID4+ICAgLSBEbWl0cmkuDQo+Pj4gPj4+PiA+Pg0KPj4+ID4+Pj4gPj4N
Cj4+PiA+Pj4+DQo+Pj4gPj4NCj4+PiA+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiBLYXp1
aG8gT2t1DQo+DQo+DQo+DQo+IC0tDQo+IEthenVobyBPa3UNCg0KDQotLQ0KS2F6dWhvIE9rdQ0K
DQo=

--_000_1F436ED13A22A246A59CA374CBC543998B86D457ORSMSX111amrcor_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNv
LXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn
aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0
OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
LHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVt
YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh
Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp
biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUzNzQyNjEx
Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjA0ODcy
NzU0IC0xIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4
Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh
cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N
CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJp
Zjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxl
dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N
Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBz
dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7bGluZS1icmVhazphZnRlci13aGl0ZS1zcGFjZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZiI+SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd291bGQgbGlrZSB0byByZXZpc2l0IHRoaXMg
ZGlzY3Vzc2lvbiBpbiB0aGUgY29udGV4dCBvZiBkaXN0cmlidXRlZCBwcm9jZXNzaW5nLiBUaGUg
ZGlzdHJpYnV0ZWQgcHJvY2Vzc2luZyBkb2VzbuKAmXQgb25seSBhcHBseSB0byBtdWx0aS10aHJl
YWRpbmcgYnV0IGFsc28gdG8gbGF5ZXJlZCBwcm9jZXNzaW5nLg0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T25lIGV4
YW1wbGUgb2YgbGF5ZXJlZCBwcm9jZXNzaW5nIGlzIHNlZ21lbnRhdGlvbi4gVGhlIGN1cnJlbnQg
Q2hyb21pdW0gaW1wbGVtZW50YXRpb24gY3VycmVudGx5IGNyZWF0ZXMgdGhlIHNlZ21lbnRzIGFu
ZCBwYXNzZXMgdGhlbSBhcyBhIGJ1bmNoIGludG8gdGhlIExpbnV4IGtlcm5lbC4gVGhlcmUNCiBp
cyBhIEdTTyBwYXRjaCB0aGF0IHdvdWxkIGNob3AgYXQgdGhlIHNlZ21lbnQgYm91bmRhcnkgYW5k
IGVuY2Fwc3VsYXRlIGluIFVEUCBoZWFkZXJzLiBXZSBjYW4gZnVydGhlciBpbXByb3ZlIHBlcmZv
cm1hbmNlIGJ5IHBsdWdnaW5nIGluIGEgc21hcnRlciBzZWdtZW50YXRpb24gYWxnb3JpdGhtIHN1
Y2ggdGhhdCB0aGUgc2VnbWVudCBwcm9jZXNzaW5nIGNhbiBhY2NvdW50IGZvciB0eXBlIG9mIGZy
YW1lLCBpdHMgc2l6ZSBhbmQgbWFrZSBpbnRlbGxpZ2VudA0KIGJvdW5kYXJ5IGFuZCBwYWRkaW5n
IGRlY2lzaW9ucyBhdCBhIGxvd2VyIGxheWVyIG9yIGluIGFuIG9mZmxvYWQuIFRvIHRoaXMgZW5k
LCB0aGUgYWxnb3JpdGhtIG5lZWRzIHRvIGlkZW50aWZ5IHRoZSBzaXplIG9mIGVhY2ggb2YgdGhl
IGZyYW1lcy4gSGF2aW5nIGFuIEFDSyBsZW5ndGggdGhhdCBjYW4gYmUgZGV0ZXJtaW5lZCBpbiBh
IHNpbmdsZSByZWFkIGlzIG11Y2ggbW9yZSBlZmZpY2llbnQgdGhhbiBoYXZpbmcgdG8gZG8gYSBz
ZXJpZXMgb2YNCiByZWFkcy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hbmFzaTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1pa2tlbCBGYWhuw7hlIErD
uHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g
RnJpZGF5LCBKdW5lIDIyLCAyMDE4IDk6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29y
bGEgJmx0O2VrckBydGZtLmNvbSZndDs7IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5j
b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKYW5hIEl5ZW5nYXIgJmx0O2pyaS5pZXRmQGdtYWlsLmNv
bSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IERldmFsLCBNYW5hc2kg
Jmx0O21hbmFzaS5kZXZhbEBpbnRlbC5jb20mZ3Q7OyBNYXJ0ZW4gU2VlbWFubiAmbHQ7bWFydGVu
c2VlbWFubkBnbWFpbC5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25A
Z21haWwuY29tJmd0OzsgSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0OzsgUHJh
dmVlbiBCYWxhc3VicmFtYW5pYW4NCiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdp
dGggQUNLIGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1
c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFub3Ro
ZXIgb3B0aW9uIGlzIHRvIHdyaXRlIG91dCBmcmFtZXMgYXMgaXMgd2l0aG91dCBsZW5ndGggZXhj
ZXB0IGFzIG5lZWRlZCBmb3IgdmFyaW50cy4gV2hlbiBhIHBhY2tldCBpcyBuZWFybHkgZG9uZSwg
YSBydW4tbGVuZ3RoIGVuY29kZWQgZnJhbWUgaW5kZXggaXMgcGxhY2VkIGluIHRoZSBwYWNrZXQN
CiB0YWlsLiBJdCBjb3VsZCBhbHNvIGluY2x1ZGUgdGhlIGZyYW1lIHR5cGVzLiBBIHJlYWRlciBj
YW4gbm93IGRpcmVjdGx5IGZpbmQgb3Igc2tpcCBBQ0sgZnJhbWVzIGFuZCB0aGUgd3JpdGVyIGRv
ZXMgbm90IGhhdmUgdG8gY29tcHV0ZSBsZW5ndGhzIGJlZm9yZSB3cml0aW5nLiBPZiBjb3Vyc2Us
IHRoZSByZWFkZXIgbmVlZHMgdG8gYmUgYWJsZSB0byBsb2NhdGUgdGhlIGluZGV4IGF0IHRoZSB0
YWlsIHdoaWNoIGNhbiBiZSB0cmlja3kgd2l0aCBjb2FsZXNjZWQNCiBwYWNrZXRzLCBidXQgbm90
IGltcG9zc2libGUuIElzbuKAmXQgdGhpcyBsYXJnZWx5IGhvdyB6aXAtZmlsZXMgd29yaz88bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUyOTY4Mzc3
ODM3MTc2MDg5NiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5PbiAyMiBKdW5lIDIwMTggYXQgMTcuMDAuNTIsIE1pa2tlbCBGYWhu
w7hlIErDuHJnZW5zZW4gKDwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29t
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+bWlra2VsZmpAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+KQ0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5BcyBJIHNhaWQgZWFybGllciwgSSBhbHNvIGZhdm91ciBhIGxlbmd0
aCBwcmVmaXguIEJ1dCwgSWFuIGRvZXMgaGF2ZSBhIHBvaW50OjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5Xcml0aW5nIGRhdGEgaXMgZ2VuZXJhbGx5IG1vcmUgZXhwZW5zaXZl
IHRoYW4gcmVhZGluZyBkYXRhLiBFc3BlY2lhbGx5IGlmIHlvdSBoYXZlIHRvIHRyYXZlcnNlIGxv
bmcgZGF0YSBzdHJ1Y3R1cmVzIHRvIGZpbmQgdGhlIGxlbmd0aCBiZWZvcmUgeW91IGNhbiBzdGFy
dCB3cml0aW5nIGFuZC9vcg0KIHlvdSBtYXkgaGF2ZSB0byBjb25zZXJ2YXRpdmVseSByZXNlcnZl
IGV4dHJhIHNwYWNlIGZvciBhIGxlbmd0aCBmaWVsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+U28gYmVmb3JlIGRlY2lkaW5nIG9uZSB3YXkgb3IgdGhlIG90aGVyLCB0aGUg
Y29zdCBvZiB3cml0aW5nIG5lZWRzIHRvIGJlIHdlbGwgdW5kZXJzdG9vZCwgYWxzbyBpbiBzY2Vu
YXJpb3Mgd2l0aCBsYXJnZSBNVFXigJlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk
PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5JbiB0aGUgZmxhdGJ1ZmZlcnMgc3BhY2UgdGhhdCBJ4oCZbSBpbnZvbHZlZCB3aXRoLCBz
dHJlYW1pbmcgaGFzIHR1cm5lZCB0byBiZSBhbiBpc3N1ZSBiZWNhdXNlIGRhdGEgY2Fubm90IGJl
IHRyYW5zbWl0dGVkIGluIHBhcnRzIHdpdGhvdXQgaW5kZXggZGF0YSBvbiBhIHNlcGFyYXRlIGNo
YW5uZWwNCiB0byByZWNvbWJpbmVkIGZyYWdtZW50cy4gQSBzaW1wbGUsIGJ1dCBub24tc3RhbmRh
cmQsIGNoYW5nZSBpbiB0aGUgZm9ybWF0IHdvdWxkIGZpeCB0aGlzLiBKU09OIGFuZCBDb0FQIGFs
bG93cyBzdHJlYW1pbmcsIGJ1dCBtYW55IG90aGVyIGZvcm1hdHMgZG8gbm90LCBpbmNsdWRpbmcg
bGF0ZXIgdmVyc2lvbnMgb2YgcHJvdG9jb2wgYnVmZmVycywgYXMgSSB1bmRlcnN0YW5kLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BbiBvZGQgY29uc2VxdWVuY2Ugb2YgbWFr
aW5nIGJvdGggcmVhZCBhbmQgd3JpdGUgZWZmaWNpZW50IGlzIHRoYXQgbGVuZ3RoIGJldHRlciB3
b3JrIGJldHRlciBpZiBzdG9yZWQgYXQgdGhlIGVuZCBhbmQgcGFja2V0cyByZWFkIGJhY2t3YXJk
cy4gVGhpcyByZXF1aXJlcyBhIHNpbmdsZSB0b3RhbA0KIGxlbmd0aCBwcmVmaXggYnV0IHRoaXMg
aXMgc3RvcmVkIGluIHRoZSBkYXRhZ3JhbSBoZWFkZXIuIFRoaXMgaXMgcHJvYmFibHkgdG9vIG9k
ZC1iYWxsLCBidXQgc3RpbGwgYSBjb25zaWRlcmF0aW9uIHdvcnRoIG5vdGluZy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHNlY29uZCBiZXN0IGFsdGVybmF0aXZlIG1h
eSB0aGVyZWZvcmUgYmUgdG8gYWxsb3cgd3JpdGVzIHRvIGJlIGZhc3QgYW5kIHJlYWRzIHRvIGJl
IGRlY2VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1
c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WWV0LCBJIHN0aWxs
IGxpa2UgbGVuZ3RoIHByZWZpeGVzIGlmIHRoZXkgY291bGQgYmUgbWFkZSB3cml0ZSBlZmZpY2ll
bnQgYmVjYXVzZSBoaWdoIHBlcmZvcm1hbmNlIGxvdy1sYXRlbmN5IHByb2Nlc3NlcyBjYXJlIHpl
cm8gYWJvdXQgQUNLIGFuZCBjYW4gY29uc3VtZSBhIHBhY2tldCBkaXJlY3RseQ0KIHdoaWxlIGEg
YmFja2dyb3VuZCBwcm9jZXNzIGhhbmRsZXMgYWxsIHRoZSBsYXRlbmN5IGluc2Vuc2l0aXZlIEFD
SyBhbmQgcmV0cmFuc21pc3Npb24gbG9naWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPlRoZSBxdWVzdGlvbiBpcyBhbHNvLCB3aGVyZSBpcyB0aGUgcHJlc3N1cmU6IGFuIElv
VCBhZ2dyZWdhdG9yIG1pZ2h0IGJlIG1hc3NpdmVseSByZWFkIGludGVuc2l2ZSB3aGlsZSBhIHdl
YiBjYWNoZSB3b3VsZCBiZSB2ZXJ5IHdyaXRlIGludGVuc2l2ZS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUyOTY3ODk3NzY3NTQ2NTk4
NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQg
UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+T24gMjIgSnVuZSAyMDE4IGF0IDE1LjEyLjA5LCBFcmljIFJlc2NvcmxhICg8L3NwYW4+
PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmVrckBydGZt
LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPikNCiB3cm90ZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgc2VlbXMgbGlrZSB0aGVyZSBhcmUgdHdvIHF1ZXN0
aW9ucyBhdCBoYW5kIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj4xLiBXb3VsZCBpdCBiZSBhcmNoaXRlY3R1cmFsbHkgYmV0dGVyIHRvIGhhdmUg
ZnJhbWVzIGhhdmUgYSBjb25zaXN0ZW50IHNlbGYtY29udGFpbmVkPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPnJlcHJlc2VudGF0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4yLiBJcyBpdCBlbm91Z2gg
YmV0dGVyIHRoYXQgd2Ugc2hvdWxkIGRvIHNvIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgd2l0aCBLYXp1aG8gdGhhdCAoYSkgd2Ug
ZG9uJ3QgaGF2ZSB0aGF0IHJlcHJlc2VudGF0aW9uIG5vdyBhbmQgKGIpIGl0IHdvdWxkPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPmJlIGEgYmV0dGVyIGRlc2lnbiB0byBkbyBzby4gSSdtIHBlcmhhcHMg
c29tZXdoYXQgbW9yZSBwb3NpdGl2ZSBvbiAoMikgdGhhbiBoZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5pcy4gSSBkb24ndCB0aGluayBpdCdzIGNyaXRpY2FsbHkgaW1wb3J0YW50IHRoYXQgd2UgbWFr
ZSB0aGUgY2hhbmdlLCBidXQgaWYgd2Ugd2VyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj50byBob2xk
IGEgY29uc2Vuc3VzIGNhbGwsIEkgdGhpbmsgSSB3b3VsZCBiZSBpbiBmYXZvci4gSSdkIGNlcnRh
aW5seSBiZSBpbnRlcmVzdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmluIGxvb2tpbmcgYXQgYSBw
cm9wb3NhbCBpZiBzb21lb25lIGVsc2Ugd2VyZSB0byBtYWtlIG9uZS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi1Fa3I8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gVGh1LCBKdW4gMjEsIDIwMTggYXQgODo0
NSBQTSwgS2F6dWhvIE9rdSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VAZ21h
aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmthenVob29rdUBnbWFp
bC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQogd3JvdGU6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+MjAxOC0wNi0y
MiA4OjA4IEdNVCYjNDM7MDk6MDAgRGV2YWwsIE1hbmFzaSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFuYXNpLmRl
dmFsQGludGVsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs6PGJyPg0KJmd0
OyBJIGZlZWwgdGhhdCB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBldmVyeSB2YWx1ZSB2YWxpZCBp
cyBzb21ld2hhdCBhY2FkZW1pYy48YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgTWFydGVuIGlzIGNv
cnJlY3QgaW4gcG9pbnRpbmcgb3V0IHRoYXQgbWFraW5nIHRoZSBBQ0s8YnI+DQpmcmFtZSBzZWxm
LWNvbnRhaW5pbmcgKGJ5IGhhdmluZyBhIGZpZWxkIHRoYXQgcmVwcmVzZW50cyB0aGUgbnVtYmVy
IG9mPGJyPg0Kb2N0ZXRzIGJlaW5nIGNvbnN1bWVkIGJ5IHRoZSBmcmFtZSkgd291bGQgYmUgYW4g
ZXhjZXB0aW9uIGZyb20gdGhlPGJyPg0KZGVzaWduIHBhdHRlcm4gd2UgaGF2ZS48YnI+DQo8YnI+
DQpMb29rIGF0IFNUUkVBTSBmcmFtZS4gVGhlIGZpZWxkIGlzIG5vdCBzZWxmLWNvbnRhaW5lZC4g
SW5zdGVhZCwgaXQgaGFzPGJyPg0KYSBMZW5ndGggZmllbGQgZm9yIHRoZSBTdHJlYW0gRGF0YSwg
d2hpY2ggaXMgYSBsZWFmLiBUaGUgc2FtZSBnb2VzIGZvcjxicj4NCk5FV19DT05ORUNUSU9OX0lE
IGZyYW1lICh0aGF0IGhhcyB0aGUgbGVuZ3RoIGZpZWxkIGZvciBDb25uZWN0aW9uIElEPGJyPg0K
ZmllbGQgKHdoaWNoIGlzIGFsc28gYSBsZWFmKSksIENPTk5FQ1RJT05fQ0xPU0UgKGxlbmd0aCBm
aWVsZCBmb3I8YnI+DQpSZWFzb24gUGhhc2UpLjxicj4NCjxicj4NCkkgYWdyZWUgd2l0aCBNYXJ0
ZW4sIE1pa2tlbCAoYW5kIHBvc3NpYmx5IG90aGVycyBhcyB3ZWxsKSB0aGF0IGhhdmluZzxicj4N
CmNvbnNpc3RlbmN5IGlzIGltcG9ydGFudC48YnI+DQo8YnI+DQpUaGVyZWZvcmUsIEkgYWdyZWUg
d2l0aCBNaWtrZWwgdGhhdCB3ZSBzaG91bGQgY29uc2lkZXIgbWFraW5nIGV2ZXJ5PGJyPg0KZnJh
bWUgc2VsZi1jb250YWluZWQgb3Iga2VlcGluZyBldmVyeSBmcmFtZSBhcy1pcyAoaS5lLiBub3Q8
YnI+DQpzZWxmLWNvbnRhaW5lZCkuPGJyPg0KPGJyPg0KRldJVywgYXMgZGVzY3JpYmVkIGluIHRo
ZSBsYXR0ZXIgaGFsZiBvZjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsLWFyY2hpdmUvd2ViL3F1aWMvY3VycmVudC9tc2cwNDI4Ny5odG1sIiB0YXJnZXQ9Il9i
bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2
ZS93ZWIvcXVpYy9jdXJyZW50L21zZzA0Mjg3Lmh0bWw8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj4sDQogaXQ8YnI+DQppcyBwb3NzaWJsZSB0byBtYWtlIGV2ZXJ5IGZyYW1lIHNlbGYtY29u
dGFpbmVkICphbmQqIGFsc28gbWFrZSBBQ0s8YnI+DQpmcmFtZXMgc21hbGxlciB0aGFuIHRoZSBj
dXJyZW50IGRyYWZ0LiBNYWtpbmcgZXZlcnkgZnJhbWU8YnI+DQpzZWxmLWNvbnRhaW5lZCBnaXZl
cyB1cyB0aGUgcG9zc2liaWxpdHkgdG8gc2VuZCBuZXcgZXh0ZW5zaW9uIGZyYW1lczxicj4NCndp
dGhvdXQgbmVnb3RpYXRpb24uPGJyPg0KPGJyPg0KSSBkbyBub3QgdGhpbmsgdGhhdCBJIHdvdWxk
IHB1c2ggZm9yIG1ha2luZyBldmVyeSBmcmFtZSBzZWxmLWNvbnRhaW5lZDxicj4NCmJ5IG15c2Vs
ZiAoYmVjYXVzZSBJIGRvIG5vdCB0aGluayBpdCBtZWV0cyB0aGUgaGlnaCBiYXIgdG8gaGF2ZSBh
PGJyPg0KY2hhbmdlIGF0IHN1Y2ggYSBsYXRlIG1vbWVudCBvZiBzdGFuZGFyZGl6YXRpb24pLCBi
dXQgYXMgc3RhdGVkLCBteTxicj4NCnByZWZlcmVuY2UgZ29lcyB0byBzZWVpbmcgZXZlcnkgZnJh
bWUgbWFkZSBzZWxmLWNvbnRhaW5lZCBvciBub25lIG9mPGJyPg0KdGhlbSBtYWRlIGFzIHN1Y2gu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQom
Z3Q7IFRoZSBsZW5ndGggdmFsdWUgcHJvdmlkZXMgbXVjaCBtb3JlIHZhbHVlIHRoYW4gdGhlIGJs
b2NrIGNvdW50IGFuZCB0aGUgZmFjdDxicj4NCiZndDsgdGhhdCBjZXJ0YWluIHZhbHVlcyBjYW4g
bmV2ZXIgYmUgYWNoaWV2ZWQgaXMgYW4gaW5oZXJlbnQgcHJvcGVydHkgb2YgdGhlPGJyPg0KJmd0
OyBsZW5ndGguPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbmUgaW50
ZXJlc3Rpbmcgb2JzZXJ2YXRpb24gaXMgdGhhdCB0aGlzIHByb3BlcnR5IGlzIG5vdCBsaW1pdGVk
IHRvIGxlbmd0aC48YnI+DQomZ3Q7IE9uZSBjYW4gZXZlbiBtYWtlIGEgc2ltaWxhciBhcmd1bWVu
dCBhYm91dCBBQ0sgYmxvY2sgY291bnQuIFRoZSBtYXhpbXVtPGJyPg0KJmd0OyBudW1iZXIgb2Yg
QUNLIGJsb2NrcyB0aGF0IGNhbiBiZSBkZWZpbmVkIHdpbGwgbm90IGFsd2F5cyBoYXZlIGEgbWVh
bmluZ2Z1bDxicj4NCiZndDsgdmFsdWUuIEluIG91dCBleGFtcGxlcywgMCwxLDIsMyBhcmUgYWxs
IHZhbGlkLiBJZiBJIHNldCB0aGUgdmFsdWUgb2YgQUNLPGJyPg0KJmd0OyBibG9jayBjb3VudCB0
byBoYXZlIGxvd2VyIHR3byBiaXRzIHRvIGJlIDExLCB0aGUgbWF4aW11bSB2YWx1ZSBpcyBvZiBB
Q0s8YnI+DQomZ3Q7IGJsb2NrcyBpcyDigJMgNDYxMTY4NjAxODQyNzM4NzkwMy4gVGhpcyBpcyB0
aGUgc2FtZSB2YWx1ZSBvZiBsYXJnZXN0PGJyPg0KJmd0OyBhY2tub3dsZWRnZWQgc28gaWYgdGhl
IEFDSyBibG9jayBjb3VudCB3YXMgc2V0IHRvIHRoaXMgdmFsdWUsIGl0IHdvdWxkIHN0aWxsPGJy
Pg0KJmd0OyBiZSBtZWFuaW5nbGVzcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+
DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNYW5hc2k8YnI+DQomZ3Q7PGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy
Pg0KJmd0OyBGcm9tOiBNYXJ0ZW4gU2VlbWFubiBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWls
dG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5tYXJ0ZW5zZWVt
YW5uQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl08YnI+DQomZ3Q7IFNl
bnQ6IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggNjo0NCBQTTxicj4NCiZndDsgVG86IERldmFsLCBN
YW5hc2kgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFuYXNpLmRldmFsQGludGVsLmNvbSI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPm1hbmFzaS4uZGV2YWxAaW50ZWwuY29tPC9zcGFuPjwvYT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCiZndDsgQ2M6IElhbiBTd2V0dCAmbHQ7PC9zcGFuPjxh
IGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aWFu
c3dldHRAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IEthenVo
byBPa3UgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPmthenVob29rdUBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mZ3Q7Ow0KIEVyaWM8YnI+DQomZ3Q7IFJlc2NvcmxhICZsdDs8L3NwYW4+PGEgaHJl
Zj0ibWFpbHRvOmVrckBydGZtLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmVrckBydGZtLmNvbTwv
c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IEphbmEgSXllbmdhciAmbHQ7PC9zcGFu
PjxhIGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5q
cmkuaWV0ZkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KIFBy
YXZlZW48YnI+DQomZ3Q7IEJhbGFzdWJyYW1hbmlhbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0
bzpwcmF2YkBtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cHJhdmJAbWljcm9zb2Z0
LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7
PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
cXVpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQogTWFydGlu
PGJyPg0KJmd0OyBUaG9tc29uICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t
c29uQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNv
bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDsgU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50
IHdpdGggQUNLIGxlbmd0aDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg
SGkgTWFuYXNpLDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFRo
ZSByaXNrIG9mIGRpc2FncmVlbWVudCBiZXR3ZWVuIGFjayBibG9ja3MgYW5kIGFjayBibG9jayBj
b3VudCBpcyBzYW1lIGFzPGJyPg0KJmd0OyZndDsgdGhlIHJpc2sgb2YgZGlzYWdyZWVtZW50IGJl
dHdlZW4gYWNrIGJsb2NrcyBhbmQgYWNrIGxlbmd0aC4gRWl0aGVyIHdheSB0aGlzPGJyPg0KJmd0
OyZndDsgbmVlZHMgdG8gYmUgY291bnRlZCB1cCB3aGlsZSBjcmVhdGluZyB0aGUgQUNLIGFuZCBj
b3VudGVkIGRvd24gd2hpbGUgcGFyc2luZzxicj4NCiZndDsmZ3Q7IGl0LiBUaGUgcG9zc2liaWxp
dHkgb2YgZXJyb3IgaXMgdGhlIHNhbWUuIEdldHRpbmcgdGhlIGFjayBibG9jayBjb3VudCB3cm9u
Zzxicj4NCiZndDsmZ3Q7IGlzIGFzIHByb2JsZW1hdGljIGFzIGdldHRpbmcgdGhlIGFjayBsZW5n
dGggd3JvbmcuIERvIHlvdSBhZ3JlZT88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+
DQomZ3Q7IEkgZGlzYWdyZWUuIExldCdzIHRha2UgYW4gZXhhbXBsZSBvZiBhbiBBQ0sgZnJhbWUg
d2l0aCBvbmUgQUNLIHJhbmdlLCB0aGF0PGJyPg0KJmd0OyBuZWVkcyBhIDIgYnl0ZSB2YXJpbnQg
dG8gcmVwcmVzZW50IHRoZSBGaXJzdCBBQ0sgQmxvY2sgYW5kIGFub3RoZXIgMiBieXRlPGJyPg0K
Jmd0OyB2YXJpbnQgdG8gcmVwcmVzZW50IHRoZSBHYXAuPGJyPg0KJmd0Ozxicj4NCiZndDsgV2l0
aCB5b3VyIHByb3Bvc2FsOjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSB2YWx1ZXMgMCBhbmQgMSBh
cmUgaW52YWxpZCwgc2luY2UgdGhlIGxlbmd0aCBmaWVsZHMgaXRzZWxmIGlzIGluY2x1ZGVkPGJy
Pg0KJmd0OyBpbiB0aGUgbGVuZ3RoLjxicj4NCiZndDsgVGhlIHZhbHVlcyAyLCAzLCAuLi4sICgy
ICYjNDM7IGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSAmIzQzOyBsZW4oQWNrRGVsYXkpKSAtIDEg
YXJlPGJyPg0KJmd0OyBpbnZhbGlkLCBzaW5jZSB0aGUgbGVuZ3RoIG5lZWRzIHRvIGluY2x1ZGUg
dGhlIExhcmdlc3QgQWNrbm93bGVkZ2VkIGFuZCB0aGU8YnI+DQomZ3Q7IEFjayBEZWxheS48YnI+
DQomZ3Q7IFRoZSB2YWx1ZSAyICYjNDM7IGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSAmIzQzOyBs
ZW4oQWNrRGVsYXkpIHdvdWxkIGJlIHRoZSBmaXJzdDxicj4NCiZndDsgdmFsaWQgdmFsdWUsIGFu
ZCBjb3JyZXNwb25kIHRvIGFuIEFDSyBmcmFtZSB3aXRoIG5vIGJsb2Nrcy48YnI+DQomZ3Q7IFRo
ZSB2YWx1ZSAyICYjNDM7IGxlbihMYXJnZXN0QWNrbm93bGVkZ2VkKSAmIzQzOyBsZW4oQWNrRGVs
YXkpICYjNDM7IDEgaXMgaW52YWxpZCwgc2luY2U8YnI+DQomZ3Q7IGl0IHdvdWxkIGN1dCB0aGUg
dmFyaW50IGZvciB0aGUgRmlyc3QgQUNLIEJsb2NrPGJyPg0KJmd0OyBUaGUgdmFsdWUgMiAmIzQz
OyBsZW4oTGFyZ2VzdEFja25vd2xlZGdlZCkgJiM0MzsgbGVuKEFja0RlbGF5KSAmIzQzOyAyIGlz
IGludmFsaWQsIHNpbmNlPGJyPg0KJmd0OyBpdCB3b3VsZCBjdXQgdGhlIGZyYW1lIGFmdGVyIHRo
ZSBGaXJzdCBBQ0sgQmxvY2sgKGJ1dCBldmVyeSBibG9jayBtdXN0IGJlPGJyPg0KJmd0OyBmb2xs
b3dlZCBieSBhIGdhcCBsZW5ndGgpPGJyPg0KJmd0OyBUaGUgdmFsdWUgMiAmIzQzOyBsZW4oTGFy
Z2VzdEFja25vd2xlZGdlZCkgJiM0MzsgbGVuKEFja0RlbGF5KSAmIzQzOyAzIGlzIGludmFsaWQs
IHNpbmNlPGJyPg0KJmd0OyBpdCB3b3VsZCBjdXQgdGhlIHZhcmludCBmb3IgdGhlIEdhcDxicj4N
CiZndDsgRmluYWxseSwgdGhlIHZhbHVlIDIgJiM0MzsgbGVuKExhcmdlc3RBY2tub3dsZWRnZWQp
ICYjNDM7IGxlbihBY2tEZWxheSkgJiM0MzsgNCBpcyB2YWxpZDxicj4NCiZndDs8YnI+DQomZ3Q7
IFRoZXJlIGFyZSAqYSBsb3QqIG9mIGludmFsaWQgdmFsdWVzIHRoYXQgeW91IGNhbiBlbmNvZGUg
aW50byB0aGUgQUNLIGxlbmd0aDxicj4NCiZndDsgZmllbGQuIE1vcmUgaW1wb3J0YW50bHksICpu
b25lKiBvZiB0aGVzZSBlcnJvciBjYXNlcyBleGlzdHMgd2l0aCB0aGUgY3VycmVudDxicj4NCiZn
dDsgZnJhbWUgZm9ybWF0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSAqb25seSogZXJyb3IgY2Fz
ZSB0aGF0IGNhbiBvY2N1ciB3aXRoIG91ciBjdXJyZW50IGZvcm1hdCBpcyB0aGF0IHRoZTxicj4N
CiZndDsgcGFja2V0IGlzIHRvbyBzaG9ydCBmb3IgdGhlIG51bWJlciBvZiBBQ0sgYmxvY2tzIHRo
YXQgYXJlIHN1cHBvc2VkIHRvPGJyPg0KJmd0OyBjb250YWluZWQgaW4gdGhlIGZyYW1lLiBUaGlz
IGNhbiBvY2N1ciB3aXRoIHlvdXIgcHJvcG9zYWwgYXMgd2VsbCAoaW48YnI+DQomZ3Q7IGFkZGl0
aW9uIHRvIHRoZSBlcnJvciBjYXNlcyBsaXN0ZWQgYWJvdmUpLjxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgTXkgY29uY2VybiBpcyBub3QgdGhhdCBpdCdzIGltcG9zc2li
bGUgb3IgZXZlbiBwYXJ0aWN1bGFybHkgaGFyZCB0byBjYXRjaDxicj4NCiZndDsgdGhlc2UgZXJy
b3JzLCBidXQgSSBkaXNsaWtlIHRoZSBwcm9wZXJ0eSB0aGF0IHNvbWUgKGluIGZhY3QsIG1vc3Qp
IGVuY29kYWJsZTxicj4NCiZndDsgdmFsdWVzIGFyZSBpbnZhbGlkLjxicj4NCiZndDs8YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQmVzdCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNYXJ0ZW48
YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn
dDsgT24gV2VkLCBKdW4gMjAsIDIwMTggYXQgMzoyMSBBTSBEZXZhbCwgTWFuYXNpICZsdDs8L3Nw
YW4+PGEgaHJlZj0ibWFpbHRvOm1hbmFzaS5kZXZhbEBpbnRlbC5jb20iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5tYW5hc2kuZGV2YWxAaW50ZWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jmd0Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgSWFuLDxicj4NCiZn
dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGVyZSBpcyBhbm90aGVyIGF0dGVtcHQg
dG8gc29sdmUgdGhlIG9iamVjdGlvbnMgeW91IHJhaXNlZDo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDs8YnI+DQomZ3Q7Jmd0O0knbSBub3QgYSBmYW4gb2YgdGhpcyBwcm9wb3NhbCwgYmVj
YXVzZSBJIHRoaW5rIGl0IGlzIGltcHJhY3RpY2FsIHRvIGRyb3A8YnI+DQomZ3Q7Jmd0OyB0aGUg
bnVtYmVyIG9mIGFjayBibG9ja3MsIGJlY2F1c2Ugd2l0aCB0aGUgRUNOIHByb3Bvc2FsIGl0IGJl
Y29tZXM8YnI+DQomZ3Q7Jmd0OyBpbXByYWN0aWNhbGx5IGNvbXBsZXggdG8gcGFyc2UuPGJyPg0K
Jmd0Ozxicj4NCiZndDsgSXMgdGhlcmUgYSByZWFzb24gdGhlIHByb3Bvc2FsIGZyb20gQ2hyaXN0
aWFuIGRvZXMgbm90IHNvbHZlIHRoaXMgcHJvYmxlbT88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N
CiZndDs8YnI+DQomZ3Q7Jmd0O0lmIHdlIGRvbid0IHJlbW92ZSB0aGUgbnVtYmVyIG9mIGFjayBi
bG9ja3MsIHRoZW4gdGhlIGFjayBmcmFtZSBpcyBsYXJnZXIsPGJyPg0KJmd0OyZndDsgYnV0IEkg
ZG9uJ3QgdGhpbmsgdGhlIGV4dHJhIHNpemUgZmllbGQgaXMgdXNlZnVsIGZvciBtb3N0IGltcGxl
bWVudGF0aW9ucy48YnI+DQomZ3Q7Jmd0OyBBbHNvLCBpdCBtZWFucyB0aGUgbGVuZ3RoIGNhbiBk
aXNhZ3JlZSB3aXRoIHRoZSBhY3R1YWwgbGVuZ3RoLCB3aGljaCBhZGQ8YnI+DQomZ3Q7Jmd0OyBj
b21wbGV4aXR5IGFuZCB0aGUgcG9zc2liaWxpdHkgb2Ygd3JpdGluZyBlcnJvci1wcm9uZSBjb2Rl
LiZuYnNwOyBUaGUgaWRlYSBvZjxicj4NCiZndDsmZ3Q7IHNvbWVvbmUgb2ZmbG9hZGluZyBhY2sg
cHJvY2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRydXN0IHRoZSBsZW5ndGg8YnI+DQom
Z3Q7Jmd0OyBzZWVtcyBsaWtlIHNvbWVvbmUgY291bGQgZ2V0IHdyb25nIGFuZCBjYXVzZSBzb21l
IGNvbmNlcm5pbmcgaXNzdWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSByaXNrIG9mIGRpc2Fn
cmVlbWVudCBiZXR3ZWVuIGFjayBibG9ja3MgYW5kIGFjayBibG9jayBjb3VudCBpcyBzYW1lIGFz
PGJyPg0KJmd0OyB0aGUgcmlzayBvZiBkaXNhZ3JlZW1lbnQgYmV0d2VlbiBhY2sgYmxvY2tzIGFu
ZCBhY2sgbGVuZ3RoLiBFaXRoZXIgd2F5IHRoaXM8YnI+DQomZ3Q7IG5lZWRzIHRvIGJlIGNvdW50
ZWQgdXAgd2hpbGUgY3JlYXRpbmcgdGhlIEFDSyBhbmQgY291bnRlZCBkb3duIHdoaWxlIHBhcnNp
bmc8YnI+DQomZ3Q7IGl0LiBUaGUgcG9zc2liaWxpdHkgb2YgZXJyb3IgaXMgdGhlIHNhbWUuIEdl
dHRpbmcgdGhlIGFjayBibG9jayBjb3VudCB3cm9uZzxicj4NCiZndDsgaXMgYXMgcHJvYmxlbWF0
aWMgYXMgZ2V0dGluZyB0aGUgYWNrIGxlbmd0aCB3cm9uZy4gRG8geW91IGFncmVlPzxicj4NCiZn
dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7TXkgZXhwZXJpZW5jZSBpcyBtdWx0
aXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nIGlzIG1vcmUgY29zdCBhbmQgd29yayB0aGFuPGJy
Pg0KJmd0OyZndDsgaXQncyB3b3J0aC4mbmJzcDsgU3VyZSB5b3UgY2FuJ3QgZmlsbCBhIDEwMEcg
TklDIHdpdGggb25lIGNvbm5lY3Rpb24sIGJ1dCB0aGF0PGJyPg0KJmd0OyZndDsgc2VlbXMgbGlr
ZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3JrbG9hZHMgSSd2ZSBzZWVuLiZu
YnNwOyBUeXBpY2FsbHk8YnI+DQomZ3Q7Jmd0OyB0aGUgZXh0cmEgY29zdCBvZiBtdWx0aXRocmVh
ZGluZyBvdXR3ZWlnaHMgaXRzIHZhbHVlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSB2YWx1ZSBp
cyB0d28gZm9sZCDigJMgcHJlLXByb2Nlc3NpbmcgYW5kIG11bHRpLXRocmVhZGluZy4gSWYgd2U8
YnI+DQomZ3Q7IHByZS1wcm9jZXNzIHRoZSByZWNlaXZlZCBwYWNrZXRzIHN1Y2ggdGhhdCBBQ0tz
IGFuZCBzdHJlYW1zIGNhbiBiZTxicj4NCiZndDsgY29hbGVzY2VkLCB0aGUgcmVjZWl2ZSBzaWRl
IGNhbiBpbmRpY2F0ZSBhIGxhcmdlIGNodW5rIG9mIGluZm9ybWF0aW9uIHRob3VnaDxicj4NCiZn
dDsgdGhlIGtlcm5lbCwgcmVkdWNpbmcgdGhlIGNvc3Qgb2Ygc3lzdGVtIGNhbGwgYW5kIHByb3Rv
Y29sIG92ZXJoZWFkLiBUaGlzIGlzPGJyPg0KJmd0OyB0aGUgc2FtZSBjb25jZXB0IGFzIFVEUCBz
ZWdtZW50YXRpb24gdGFrZW4gYSBzdGVwIGZ1cnRoZXIgb24gcmVjZWl2ZSBzaWRlLjxicj4NCiZn
dDsgQWZ0ZXIgdGhpcyBjaHVuayBpcyBpbmRpY2F0ZWQgaW50byB0aGUgUVVJQyBwcm90b2NvbCwg
dGhlIHByb3RvY29sIG1heTxicj4NCiZndDsgcHJvY2VzcyBzdHJlYW0gYW5kIEFDSyBpbiBwYXJh
bGxlbC4gV2hpbGUgZm9sa3MgbWF5IG9yIG1heSBub3QgdXRpbGl6ZSB0aGlzLDxicj4NCiZndDsg
dGhlcmUgaXMgYW4gYWR2YW50YWdlIGhlcmUuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgTWFuYXNpPGJyPg0KJmd0Ozxi
cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEZyb206IElh
biBTd2V0dCBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNv
bSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmlhbnN3ZXR0QGdvb2dsZS5jb208L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5dPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDE5LCAyMDE4IDEx
OjI2IEFNPGJyPg0KJmd0OyBUbzogRGV2YWwsIE1hbmFzaSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFuYXNpLi5k
ZXZhbEBpbnRlbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KJmd0
OyBDYzogTWFydGVuIFNlZW1hbm4gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFydGVuc2Vl
bWFubkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5tYXJ0ZW5zZWVtYW5uQGdtYWlsLmNv
bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IEthenVobyBPa3U8YnI+DQomZ3Q7
ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5rYXp1aG9va3VAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jmd0OzsgRXJpYyBSZXNjb3JsYSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpla3JAcnRm
bS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5la3JAcnRmbS5jb208L3NwYW4+PC9hPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj4mZ3Q7Ow0KIEphbmEgSXllbmdhcjxicj4NCiZndDsgJmx0Ozwvc3Bhbj48YSBo
cmVmPSJtYWlsdG86anJpLmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+anJpLmll
dGZAZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsgUHJhdmVlbiBC
YWxhc3VicmFtYW5pYW4gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0
LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnByYXZiQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KIElFVEY8YnI+DQomZ3Q7IFFVSUMgV0cgJmx0Ozwvc3Bh
bj48YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnF1aWNA
aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBNYXJ0aW4gVGhvbXNv
biAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6
IFJlOiBQcm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8
YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEknbSBzdGlsbCBub3QgaW50
ZXJlc3RlZCBpbiB0aGlzIGNoYW5nZSwgZm9yIHRoZSByZWFzb25zIEkgc3RhdGVkIGFib3ZlLjxi
cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gVHVlLCBKdW4gMTksIDIw
MTggYXQgMjoyMSBQTSBEZXZhbCwgTWFuYXNpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1h
bmFzaS5kZXZhbEBpbnRlbC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5tYW5hc2kuZGV2YWxAaW50
ZWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCiZndDsgd3JvdGU6
PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgQWxsLDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0
Ozxicj4NCiZndDsgRG8gd2UgaGF2ZSBhZ3JlZW1lbnQgaGVyZSB0byBjcmVhdGUgYSBuZXcgUFI/
PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0
Ozxicj4NCiZndDsgTWFuYXNpPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0
OyBGcm9tOiBEZXZhbCwgTWFuYXNpPGJyPg0KJmd0OyBTZW50OiBTdW5kYXksIEp1bmUgMTcsIDIw
MTggMjoyNSBQTTxicj4NCiZndDsgVG86IE1hcnRlbiBTZWVtYW5uICZsdDs8L3NwYW4+PGEgaHJl
Zj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFy
dGVuc2VlbWFubkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBL
YXp1aG8gT2t1PGJyPg0KJmd0OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzprYXp1aG9va3VA
Z21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQomZ3Q7IENjOiBJYW4gU3dldHQgJmx0O2lh
bnN3ZXR0PTwvc3Bhbj48YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYuLm9y
ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IEVyaWMNCiBSZXNjb3JsYTxicj4NCiZndDsgJmx0
Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
ZWtyQHJ0Zm0uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsgSmFuYSBJeWVu
Z2FyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPmpyaS5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZndDs7DQogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQomZ3Q7ICZsdDs8L3NwYW4+
PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5w
cmF2YkBtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsgSUVU
RiBRVUlDIFdHICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5xdWljQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jmd0OzsNCiBNYXJ0aW4gVGhvbXNvbjxicj4NCiZndDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls
dG86bWFydGluLnRob21zb25AZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFydGluLnRo
b21zb25AZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCiZn
dDsgU3ViamVjdDogUkU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGgg
QUNLIGxlbmd0aDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgQWxs
LDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBoYXZlIG1hZGUgYSBs
aXN0IG9mIG9iamVjdGlvbnMgdG8gdGhlIHByb3Bvc2FsIGFuZCB0aGUgc29sdXRpb25zIHRvIHRo
b3NlPGJyPg0KJmd0OyBvYmplY3Rpb25zIGRpc2N1c3NlZCBvbiB0aGlzIHRocmVhZC48YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IGEuJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Q28tZXhpc3RlbmNlIG9mIGxlbmd0aCBmaWVsZCB3aXRoIEVDTiBmaWVsZCBhbmQgQUNLIGJsb2Nr
cy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IENocmlzdGlhbiBzdWdn
ZXN0ZWQgdG8gbW92ZSB0aGUgRUNOIGZpZWxkcyB0byBwcmVjZWRlIHRoZSBBQ0sgYmxvY2tzLiBU
aGlzPGJyPg0KJmd0OyBpcyBhbiBlbGVnYW50IHNvbHV0aW9uLiBQYXJzaW5nIGVudGlyZSBsaXN0
IG9mIEFDSyBibG9ja3MgdG8gcmV2aWV3IEVDTiBiaXRzPGJyPg0KJmd0OyB3b3VsZCBoYXZlIGJl
ZW4gYW5ub3lpbmcsIGV2ZW4gdGhvdWdoIGl0IGNhbiB3b3JrLjxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgYi4mbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSBhcmUgdHdv
IGNhc2VzIHRvIGJlIHBhcnNlZCDigJMgZW50aXJlIEFDSyBhbmQgcGFyc2UgQUNLIHRvPGJyPg0K
Jmd0OyBpZGVudGlmeSBsZW5ndGguIFRoZXJlIGFyZSBzb21lIHJlc2VydmF0aW9ucyB3aGVuIEFD
SyBwYXJzaW5nIGdldHMgaGFyZGVyPGJyPg0KJmd0OyBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIGVu
dGlyZSBoZWFkZXIgbmVlZHMgdG8gYmUgcGFyc2VkLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K
Jmd0Ozxicj4NCiZndDsgQWdyZWVtZW50IGZyb20gc2V2ZXJhbCBmb2xrcyBoZXJlLiBJbiB0aGUg
b3JpZ2luYWwgQUNLIGRlZmluZWQgaW4gZHJhZnQgMTI8YnI+DQomZ3Q7IG9mIHRoZSBzbGlkZSwg
b25lIHdvdWxkIGNvdW50IGRvd24gbnVtYmVyIG9mIEFDSyBibG9ja3MgdG8gZ2V0IHRvIHRoZSBl
bmQgb2Y8YnI+DQomZ3Q7IHRoZSBwYWNrZXQuIEluIHRoZSBwcm9wb3NhbCBJIG1hZGUsIG9uZSB3
b3VsZCBjb3VudCBkb3duIHRoZSBsZW5ndGggdG88YnI+DQomZ3Q7IGlkZW50aWZ5IHRoZSBlbmQg
b2YgdGhlIHBhY2tldC4gVGhlIGxvZ2ljIGlzIHZlcnkgc2ltaWxhciBpbiBjeWNsZSBjb3VudCBh
bmQ8YnI+DQomZ3Q7IGNvbXBsZXhpdHkuIFNldmVyYWwgZm9sa3MgYWxzbyBjb21tZW50ZWQgdG8g
dGhpcyBlZmZlY3QuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBjLiZu
YnNwOyAmbmJzcDsgJm5ic3A7IE11bHRpLXRocmVhZGVkIHBhY2tldCBwcm9jZXNzaW5nPGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIHdvdWxkIGV4cGVjdCB0aGF0IHRo
ZXJlIGFyZSAxMHMgb2YgMTAwMHMgb2YgY29ubmVjdGlvbnMgaW4gdXNlIGF0IGFueSB0aW1lPGJy
Pg0KJmd0OyBmb3IgYSBzZXJ2ZXIgd2l0aCBhIGhpZ2ggc3BlZWQgbGluay4gTXVsdGktdGhyZWFk
aW5nIHRvIGhhbmRsZSBlYWNoIG9mIHRoZXNlPGJyPg0KJmd0OyBmbG93cyAvIGNvbm5lY3Rpb25z
IGluIHBhcmFsbGVsIGlzIG5lY2Vzc2l0eSB0byBiZSBhYmxlIHRvIHN1cHBvcnQgbGFyZ2U8YnI+
DQomZ3Q7IG51bWJlciBvZiBjb25uZWN0aW9ucyBvbiBhIGhpZ2ggc3BlZWQgbGluay4gVHggc2Vn
bWVudGF0aW9uLCBSeCBjb2FsZXNjaW5nPGJyPg0KJmd0OyBhcmUgd2VsbCBrbm93biBzdHJhdGVn
aWVzIHRvIHJlZHVjZSB0aGUgcHJvY2Vzc2luZyBjb3N0LiBJbiBpbml0aWFsIHN0YWdlcyw8YnI+
DQomZ3Q7IGNvZGUgaXMgb2Z0ZW4gd3JpdHRlbiBhcyBhIHNpbmdsZS10aHJlYWRlZCBhbmQgdGhl
biByZS1mYWN0b3JlZCB0bzxicj4NCiZndDsgcGFyYWxsZWxpemUgY3ljbGUgaW50ZW5zaXZlIG9w
ZXJhdGlvbnMuIEluIG9yZGVyIHRvIGFsbG93IHRoaXMgcHJvdG9jb2wgdG88YnI+DQomZ3Q7IHNj
YWxlIGluIGZ1dHVyZSwgSSB3b3VsZCBzdWdnZXN0IHdlIGRvIG5vdCBwcmVjbHVkZSB0aGlzIGNh
c2UuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBkLiZuYnNwOyAmbmJz
cDsgJm5ic3A7IEluY3JlYXNlIGluIEFDSyBzaXplIGJ5IDEgYnl0ZS48YnI+DQomZ3Q7PGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZG8gbm90IHNlZSB0aGlzIGFzIGEgc2VyaW91cyBp
c3N1ZSBidXQgaWYgZm9sa3MgYnV0IHdlIGNhbiBjb25zaWRlciBtYWtpbmc8YnI+DQomZ3Q7IHRo
aXMgYSB2YXJpbnQsIGlmIG90aGVycyBoYXZlIHN0cm9uZyBmZWVsaW5ncyBhYm91dCBpdC4gSXTi
gJlzIGEgdHJhZGUtb2ZmIDogMjxicj4NCiZndDsgcmVhZHMgdG8gc2F2ZSAxIGJ5dGUuPGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBlLiZuYnNwOyAmbmJzcDsgJm5ic3A7
IEV2ZXJ5IGVuY29kYWJsZSB2YWx1ZSBzaG91bGQgYmUgdmFsaWQ8YnI+DQomZ3Q7PGJyPg0KJmd0
OyBOb3QgZXZlcnkgbGVuZ3RoIHdpbGwgYmUgdmFsaWQuIFRoaXMgaXMgaW5oZXJlbnQgdG8gbGVu
Z3Rocy4gVGhpcyBzYW1lIGlzc3VlPGJyPg0KJmd0OyBhaWxzIHRoZSDigJhwYXlsb2FkIGxlbmd0
aOKAmSBpbiBRVUlDIGhlYWRlci4gTm90IG9ubHkgZG9lcyB0aGUgaXNzdWUgZXhpc3QgZm9yPGJy
Pg0KJmd0OyBzbWFsbCB2YWx1ZXMsIGl0IGFsc28gYXBwbGllcyB0byBsYXJnZSB2YWx1ZXMgc2lu
Y2UgZGF0YSBzdHJlYW0gd2lsbCBiZSBzZW50PGJyPg0KJmd0OyBhZnRlciBjcnlwdG8gbmVnb3Rp
YXRpb24uJm5ic3A7IEUuZy4mbmJzcDsgLSBob3cgZG9lcyBvbmUgY3JhZnQgYSBwYXlsb2FkIHdp
dGggNjIgYml0PGJyPg0KJmd0OyBwYXlsb2FkIGxlbmd0aCBpbiBhIGxhcmdlIGhlYWRlcj88YnI+
DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg
VGhhbmtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IE1hbmFzaTxicj4NCiZndDs8YnI+DQomZ3Q7PGJy
Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9tOiBNYXJ0ZW4gU2VlbWFu
biBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5tYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPl08YnI+DQomZ3Q7IFNlbnQ6IFN1bmRheSwgSnVuZSAxNywgMjAxOCA2
OjU5IEFNPGJyPg0KJmd0OyBUbzogS2F6dWhvIE9rdSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0
bzprYXp1aG9va3VAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+a2F6dWhvb2t1QGdtYWls
LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQomZ3Q7IENjOiBJYW4g
U3dldHQgJmx0O2lhbnN3ZXR0PTwvc3Bhbj48YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRt
YXJjLmlldGYuLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm
Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IEVyaWMNCiBSZXNjb3JsYTxi
cj4NCiZndDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+ZWtyQHJ0Zm0uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0
OzsgSmFuYSBJeWVuZ2FyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWls
LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmpyaS5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQomZ3Q7
ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+Jmd0OzsgSUVURiBRVUlDIFdHICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0
Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5xdWljQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+Jmd0OzsNCiBNYXJ0aW4gVGhvbXNvbjxicj4NCiZndDsgJmx0Ozwvc3Bhbj48
YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Jmd0OzsgRGV2YWwsIE1hbmFzaSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYW5hc2kuZGV2
YWxAaW50ZWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFuYXNpLmRldmFsQGludGVsLmNvbTwv
c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBQ
cm9wb3NhbCB0byByZXBsYWNlIEFDSyBibG9jayBjb3VudCB3aXRoIEFDSyBsZW5ndGg8YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE1heWJlIGl0J3Mgc3BlY2lmaWMgdG8g
R28sIGJ1dCBJJ20gdXNpbmcgYSBzaW5nbGUgaW8uUmVhZGVyIGZvciB0aGUgd2hvbGU8YnI+DQom
Z3Q7IHBhY2tldCwgc28gYXMgbG9uZyBhcyB0aGUgcGFja2V0IHBheWxvYWQgaXMgbG9uZyBlbm91
Z2gsIHRoZSB2YXJpbnQgcGFyc2luZzxicj4NCiZndDsgd2lsbCBub3QgZmFpbC48YnI+DQomZ3Q7
PGJyPg0KJmd0OyBJIGRvbid0IHRoaW5rIHRoYXQgc3BlY2lmaWNzIG9mIHByb2dyYW1taW5nIGxh
bmd1YWdlcyBtYXR0ZXIgaGVyZSB0aG91Z2gsPGJyPg0KJmd0OyBhbmQgSSdtIHN1cmUgYm90aCBm
cmFtZSBmb3JtYXRzIGNhbiBiZSByZWFzb25hYmx5IGltcGxlbWVudGVkIGluIEMgYXMgd2VsbDxi
cj4NCiZndDsgYXMgaW4gR28uIFRoZSByZWFzb25zIEknbSBvcHBvc2VkIHRvIE1hbmFzaSdzIHBy
b3Bvc2FsIGFyZSB0aGF0IGl0IG1vdmVzIHVzPGJyPg0KJmd0OyBhd2F5IGZyb20gdGhlIHByaW5j
aXBsZSB0aGF0IG9ubHkgcmVhc29uYWJsZSB2YWx1ZXMgc2hvdWxkIGJlIGVuY29kYWJsZSwgYW5k
PGJyPg0KJmd0OyB0aGF0IGl0IGluY3JlYXNlcyB0aGUgc2l6ZSBvZiB0aGUgQUNLIGZyYW1lLCBm
b3IgdGhlIHF1ZXN0aW9uYWJsZSBiZW5lZml0IG9mPGJyPg0KJmd0OyBiZWluZyBhYmxlIHRvIHBh
cmFsbGVsaXNlIHRoZSBmcmFtZSBwYXJzZXIuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7
PGJyPg0KJmd0OyBPbiBTdW4sIEp1biAxNywgMjAxOCBhdCA4OjQ4IFBNIEthenVobyBPa3UgJmx0
Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPmthenVob29rdUBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
Z3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IDIwMTgtMDYtMTcgMjI6MzYgR01UJiM0Mzsw
OTowMCBNYXJ0ZW4gU2VlbWFubiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVt
YW5uQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm1hcnRlbnNlZW1hbm5AZ21haWwuY29t
PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyBBdCBsZWFz
dCBmb3IgbXkgaW1wbGVtZW50YXRpb24sIHBhcnNpbmcgZG9lc24ndCBiZWNvbWUgZWFzaWVyLCBp
dCBiZWNvbWVzPGJyPg0KJmd0OyZndDsgbW9yZSBjb21wbGV4IHdpdGggdGhpcyBwcm9wb3NhbC4g
TXkgdmFyaW50LXBhcnNlciBhbHdheXMgY29uc3VtZXMgYXMgbWFueTxicj4NCiZndDsmZ3Q7IGJ5
dGVzIGFzIHRoZSB2YXJpbnQgcmVxdWlyZXMsIHNvIGFmdGVyIHBhcnNpbmcgYSB2YXJpbnQsIEkn
ZCBoYXZlIHRvPGJyPg0KJmd0OyZndDsgaW50cm9kdWNlIGFuIGFkZGl0aW9uYWwgY2hlY2sgdGhh
dCB0aGlzIGRpZG4ndCBvdmVyZmxvdyB0aGUgQUNLIGxlbmd0aDxicj4NCiZndDsmZ3Q7IChlLmcu
PGJyPg0KJmd0OyZndDsgY29uc2lkZXIgdGhhdCBJIHBhcnNlZCB0aGUgQUNLIGZyYW1lIHNvIGZh
ciB0aGF0IG9ubHkgMiBieXRlcyBhcmU8YnI+DQomZ3Q7Jmd0OyByZW1haW5pbmc8YnI+DQomZ3Q7
Jmd0OyBhY2NvcmRpbmcgdG8gQUNLIGxlbmd0aCBmaWVsZCwgYnV0IHRoZSBuZXh0IHZhcmludCBp
cyA0IGJ5dGVzIGxvbmcpLjxicj4NCiZndDs8YnI+DQomZ3Q7IElzbid0IHlvdXIgdmFyaW50IHBh
cnNlciBjaGVja2luZyB0aGF0IGl0IGhhcyBub3QgKG9yIHdpbGwgbm90KSBydW48YnI+DQomZ3Q7
IGFjcm9zcyB0aGUgZW5kIG9mIHRoZSBwYWNrZXQgcGF5bG9hZCBmb3IgZXZlcnkgQUNLIGJsb2Nr
IGl0IHBhcnNlcz88YnI+DQomZ3Q7IEknZCBhc3N1bWUgdGhhdCB5b3Ugd291bGQgYmUgZG9pbmcg
dGhhdCwgYmVjYXVzZSBJIHRoaW5rIHRoYXQgaXM8YnI+DQomZ3Q7IG5lY2Vzc2FyeSB0byBhdm9p
ZCBidWZmZXIgb3ZlcnJ1bi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGF0IEkgYW0gc2F5aW5nIHRo
YXQgdGhhdCBjaGVjayBjb3VsZCBiZSBjb252ZXJ0ZWQgdG8gYSBvdmVycnVuIGNoZWNrPGJyPg0K
Jmd0OyBhZ2FpbnN0IHRoZSBlbmQgb2YgdGhlICZxdW90O2ZyYW1lIHBheWxvYWQmcXVvdDssIGFu
ZCB0aGF0IGNoZWNraW5nIHRoZTxicj4NCiZndDsgcmVtYWluaW5nIGJsb2NrIGNvdW50IGJlY29t
ZXMgdW5uZWNlc3NhcnksIGluIGNhc2Ugd2UgcmVwbGFjZSBBQ0s8YnI+DQomZ3Q7IEJsb2NrIENv
dW50IHdpdGggQUNLIEZyYW1lIExlbmd0aC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyBJbiBnZW5lcmFsLCB3ZSd2ZSBiZWVuIG1vdmluZyB0aGUgd2lyZSBpbWFnZSB0b3dh
cmRzIG1ha2luZyBldmVyeTxicj4NCiZndDsmZ3Q7IGVuY29kYWJsZTxicj4NCiZndDsmZ3Q7IHZh
bHVlIHZhbGlkLiBUaGlzIHByb3Bvc2FsIG1vdmVzIHVzIGF3YXkgZnJvbSB0aGF0IHByaW5jaXBs
ZTo8YnI+DQomZ3Q7Jmd0OyAqIHNvbWUgc21hbGwgdmFsdWVzIGFyZSBhbHdheXMgaW52YWxpZCAo
dGhlIGxlbmd0aCBjYW4gbmV2ZXIgYmUgYmV0d2VlbiAwPGJyPg0KJmd0OyZndDsgYW5kIDMpPGJy
Pg0KJmd0OyZndDsgKiBhIGxvdCBvZiBpbnRlcm1lZGlhdGUgdmFsdWVzIGFyZSBpbnZhbGlkIChp
ZiB0aGUgYm91bmRhcnkgZmFsbHMgaW5zaWRlIGE8YnI+DQomZ3Q7Jmd0OyB2YXJpbnQsIGFzIGRl
c2NyaWJlZCBhYm92ZSk8YnI+DQomZ3Q7Jmd0OyBCb3RoIHRoZXNlIGNhc2VzIGNhbid0IG9jY3Vy
IHdpdGggdGhlIGN1cnJlbnQgQUNLIGZyYW1lIGZvcm1hdC4uPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyBPbiBTdW4sIEp1biAxNywgMjAxOCBhdCA3OjU0IFBNIEthenVobyBPa3UgJmx0Ozwv
c3Bhbj48YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPmthenVob29rdUBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7
IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAyMDE4LTA2LTE3IDg6
MzQgR01UJiM0MzswOTowMCBJYW4gU3dldHQ8YnI+DQomZ3Q7Jmd0OyZndDsgJmx0O2lhbnN3ZXR0
PTwvc3Bhbj48YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+Jmd0Ozo8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBJJ20gbm90IGEgZmFu
IG9mIHRoaXMgcHJvcG9zYWwsIGJlY2F1c2UgSSB0aGluayBpdCBpcyBpbXByYWN0aWNhbCB0bzxi
cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IGRyb3A8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyB0aGUgbnVt
YmVyIG9mIGFjayBibG9ja3MsIGJlY2F1c2Ugd2l0aCB0aGUgRUNOIHByb3Bvc2FsIGl0IGJlY29t
ZXM8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBpbXByYWN0aWNhbGx5IGNvbXBsZXggdG8gcGFyc2Uu
PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEZvciB0aGUgRUNOIHByb3Bvc2Fs
LCBhcyBDaHJpc3RpYW4gaGFzIHN1Z2dlc3RlZCwgd2UgY2FuIG1vdmUgdGhlIEVDTjxicj4NCiZn
dDsmZ3Q7Jmd0OyBjb3VudGVycyBiZWZvcmUgdGhlIEFDSyBibG9ja3MuIFRoZW4sIGl0IHdvdWxk
IG5vdCBiZSBjb21wbGV4IHRvPGJyPg0KJmd0OyZndDsmZ3Q7IHBhcnNlLjxicj4NCiZndDsmZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBbmQgbXkgdmlldyBpcyB0aGF0IHBhcnNpbmcgYmVjb21l
cyBlYXNpZXIgaWYgd2UgcmVwbGFjZSBBQ0sgQmxvY2s8YnI+DQomZ3Q7Jmd0OyZndDsgQ291bnQg
d2l0aCBBQ0sgRnJhbWUgTGVuZ3RoLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyBOb3csIHdpdGggQUNLIEJsb2NrIENvdW50LCB3ZSBuZWVkIHRvIGNoZWNrIHRoZSByZW1haW5p
bmcgbnVtYmVyIG9mPGJyPg0KJmd0OyZndDsmZ3Q7IGJsb2NrcyBhbmQgdGhlIHJlbWFpbmluZyBz
cGFjZSBpbiB0aGUgcGFja2V0IHBheWxvYWQgZm9yIGV2ZXJ5IGJsb2NrPGJyPg0KJmd0OyZndDsm
Z3Q7IHRoYXQgd2UgcGFyc2UuIEZhaWxpbmcgdG8gY2hlY2sgZWl0aGVyIGxlYWRzIHRvIGEgYnVn
IG9yIGEgc2VjdXJpdHk8YnI+DQomZ3Q7Jmd0OyZndDsgaXNzdWUuPGJyPg0KJmd0OyZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsmZ3Q7IElmIHdlIHN3aXRjaCB0byBBQ0sgRnJhbWUgTGVuZ3RoLCB3ZSBu
ZWVkIHRvIG9ubHkgY2hlY2sgdGhlIHJlbWFpbmluZzxicj4NCiZndDsmZ3Q7Jmd0OyBzcGFjZSBp
biB0aGUgZnJhbWUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgdGhpbmsg
dGhhdCB0aGlzIGlzIHRoZSBiaWdnZXN0IGJlbmVmaXQgb2YgcmVwbGFjaW5nIEFDSyBCbG9jayBD
b3VudDxicj4NCiZndDsmZ3Q7Jmd0OyB3aXRoIEFDSyBGcmFtZSBMZW5ndGguIE9UT0ggdGhlIGRv
d25zaWRlIGlzIHRoYXQgeW91IG5lZWQgZXh0cmEgb25lIHRvPGJyPg0KJmd0OyZndDsmZ3Q7IHR3
byBiaXRzIChvbmUgaWYgdGhlIHNpemUgb2YgYmxvY2sgLyBnYXAgaXMgZXhwZWN0ZWQgdG8gYmUg
YmVsb3cgNjUsPGJyPg0KJmd0OyZndDsmZ3Q7IHR3byBpZiB0aGV5IGFyZSBleHBlY3RlZCB0byBi
ZSBhYm92ZSB0aGF0KSBmb3IgZW5jb2RpbmcgQUNLIEZyYW1lPGJyPg0KJmd0OyZndDsmZ3Q7IExl
bmd0aCBjb21wYXJlZCB0byBBQ0sgQmxvY2sgQ291bnQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhhdmluZyBz
YWlkIHRoYXQsIEkgaG9uZXN0bHkgd29uZGVyIGlmIGFsbCB0aGUgZnJhbWVzIGNvdWxkIGhhdmUg
aXQnczxicj4NCiZndDsmZ3Q7Jmd0OyBsZW5ndGggYmVpbmcgZW5jb2RlZCAoZWl0aGVyIGV4cGxp
Y2l0bHkgb3IgZWl0aGVyIGFzIGEgc2lnbmFsIHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsgc2F5cyAm
cXVvdDt0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQmcXVvdDspLiBDb25zaWRlciBzb21ldGhpbmcg
bGlrZSBiZWxvdzo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgfDB8IGZyYW1l
LXR5cGUgKDcpIHwgZnJhbWUtcGF5bG9hZC1sZW5ndGggKGkpIHwgZnJhbWUtcGF5bG9hZCAoKikg
fDxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyBvcjxicj4NCiZndDsmZ3Q7Jmd0OyB8MXwgZnJhbWUt
dHlwZSAoNykgfCBmcmFtZS1wYXlsb2FkICgqKSB8PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7IFdoZW4gTVNCIG9mIHRoZSBmaXJzdCBvY3RldCBzZXQgdG8gemVybywgdGhlIGxl
bmd0aCBvZiB0aGUgZnJhbWU8YnI+DQomZ3Q7Jmd0OyZndDsgcGF5bG9hZCBpcyBkZXNpZ25hdGVk
IGJ5IHRoZSB2YXJpbnQgdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBmcmFtZTxicj4NCiZn
dDsmZ3Q7Jmd0OyB0eXBlLjxicj4NCiZndDsmZ3Q7Jmd0OyBXaGVuIE1TQiBvZiB0aGUgZmlyc3Qg
b2N0ZXQgc2V0IHRvIG9uZSwgdGhlIGxlbmd0aCBvZiB0aGUgZnJhbWU8YnI+DQomZ3Q7Jmd0OyZn
dDsgcGF5bG9hZCBzcGFucyB0byB0aGUgZW5kIG9mIHRoZSBwYWNrZXQuPGJyPg0KJmd0OyZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEluIHRoaXMgZW5jb2RpbmcsIHdlIGNhbiBhbHdheXMgb21p
dCB0aGUgTGVuZ3RoIGZpZWxkIG9mIGEgU1RSRUFNPGJyPg0KJmd0OyZndDsmZ3Q7IGZyYW1lLiBT
byB0aGUgb3ZlcmhlYWQgZm9yIGNhcnJ5aW5nIHN0cmVhbSBkYXRhIHdpbGwgYmUgaW5kaWZmZXJl
bnQgaW48YnI+DQomZ3Q7Jmd0OyZndDsgcHJhY3RpY2UuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7IEZvciB0aGUgQUNLIGZyYW1lLCB3ZSBjYW4gb21pdCB0aGUgQUNLIEJsb2Nr
IENvdW50IGZpZWxkLiBBbmQgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IG92ZXJoZWFkIHdpbGwgYmUg
b25lIHRvIHR3byBiaXRzIGlmIHRoZSBBQ0sgZnJhbWUgaXMgc2VudCBpbiB0aGU8YnI+DQomZ3Q7
Jmd0OyZndDsgbWlkZGxlIG9mIHRoZSBwYWNrZXQgKHRoZXJlYnkgdXNpbmcgdGhlIGVuY29kaW5n
IHdpdGggZXhwbGljaXQgZnJhbWU8YnI+DQomZ3Q7Jmd0OyZndDsgcGF5bG9hZCBsZW5ndGgpLCBv
ciBvbmUgb2N0ZXQgb3IgbW9yZSBzaG9ydGVyIGlmIEFDSyBpcyB0aGUgbGFzdCBmcmFtZTxicj4N
CiZndDsmZ3Q7Jmd0OyBvZiB0aGUgcGFja2V0Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0OyBXZSBhcmUgbGlrZWx5IHRvIHNlZSBpbmNyZWFzZSBvZiBvdmVyaGVhZCBmb3IgbW9z
dCBvZiB0aGUgb3RoZXIgdHlwZXM8YnI+DQomZ3Q7Jmd0OyZndDsgb2YgZnJhbWVzLCBidXQgSSBk
byBub3QgdGhpbmsgdGhhdCB3b3VsZCBiZSBhbiBpc3N1ZSBjb25zaWRlcmluZyB0aGF0PGJyPg0K
Jmd0OyZndDsmZ3Q7IHRoZXkgd2lsbCBiZSBmYXIgc2VsZG9tIHNlZW4gY29tcGFyZWQgdG8gU1RS
RUFNcyBhbmQgQUNLcy48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVG8gc3Vt
bWFyaXplLCBteSBhbnRpY2lwYXRpb24gaXMgdGhhdCB3ZSBjYW4gbWFrZSBhbGwgdGhlIGZyYW1l
czxicj4NCiZndDsmZ3Q7Jmd0OyBzZWxmLWNvbnRhaW5lZCAoaS5lLiB0aGUgbGVuZ3RoIGNhbiBi
ZSBkZXRlcm1pbmVkIHdpdGhvdXQgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7IGtub3dsZWRnZSBvZiBo
b3cgZWFjaCBmcmFtZSBpcyBlbmNvZGVkKSB3aXRob3V0IGFueSBvdmVyaGVhZCwgaWYgd2U8YnI+
DQomZ3Q7Jmd0OyZndDsgYWdyZWUgb24gbWFraW5nIHRoZSBmcmFtZSB0eXBlIHNwYWNlIDEgYml0
IHNtYWxsZXIuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEZpbmFsbHksIHRo
ZSBiaWdnZXN0IGJlbmVmaXQgb2YgdXNpbmcgYSBzZWxmLWNvbnRhaW5lZCBlbmNvZGluZyBvZjxi
cj4NCiZndDsmZ3Q7Jmd0OyBmcmFtZXMgaXMgdGhhdCB3ZSB3b3VsZCBoYXZlIHRoZSBhYmlsaXR5
IHRvIGludHJvZHVjZSBuZXcgb3B0aW9uYWw8YnI+DQomZ3Q7Jmd0OyZndDsgZnJhbWVzIHdpdGhv
dXQgbmVnb3RpYXRpb24uIEJ5IG1ha2luZyB0aGUgZnJhbWVzIHNlbGYtY29udGFpbmVkLCBRVUlD
PGJyPg0KJmd0OyZndDsmZ3Q7IGVuZHBvaW50cyB3aWxsIGhhdmUgdGhlIGZyZWVkb20gb2YgaWdu
b3JpbmcgdGhlIGZyYW1lcyB0aGF0IHRoZXkgZG88YnI+DQomZ3Q7Jmd0OyZndDsgbm90IHVuZGVy
c3RhbmQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEJlaW5nIGFibGUgdG8g
c2VuZCBRVUlDIGZyYW1lcyBkZWZpbmVkIGluIGV4dGVuc2lvbnMgd2l0aG91dDxicj4NCiZndDsm
Z3Q7Jmd0OyBuZWdvdGlhdGluZyB1c2luZyBUcmFuc3BvcnQgUGFyYW1ldGVycyB3aWxsIGJlIGEg
d2luIGluIGJvdGggdGVybXMgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsgc2VjdXJpdHkgKGJlY2F1c2Ug
Y2xpZW50cycgVFAgaXMgc2VudCBpbiBjbGVhcikgYW5kIGZsZXhpYmlsaXR5PGJyPg0KJmd0OyZn
dDsmZ3Q7IChiZWNhdXNlIHdlIHdpbGwgYmUgcG9zc2libGUgdG8gc2VuZCB0aGUgZXh0ZW5zaW9u
cyBiZWZvcmUgd2UgZmlndXJlPGJyPg0KJmd0OyZndDsmZ3Q7IG91dCB3aGV0aGVyIHRoZSBwZWVy
IHN1cHBvcnRzIHRoYXQgZXh0ZW5zaW9uKS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsgJmd0OyBJZiB3ZSBkb24ndCByZW1vdmUgdGhlIG51bWJlciBvZiBhY2sgYmxvY2tzLCB0
aGVuIHRoZSBhY2sgZnJhbWUgaXM8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBsYXJnZXIsPGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsgYnV0IEkgZG9uJ3QgdGhpbmsgdGhlIGV4dHJhIHNpemUgZmllbGQg
aXMgdXNlZnVsIGZvciBtb3N0PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgaW1wbGVtZW50YXRpb25z
Ljxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IEFsc28sIGl0IG1lYW5zIHRoZSBsZW5ndGggY2FuIGRp
c2FncmVlIHdpdGggdGhlIGFjdHVhbCBsZW5ndGgsIHdoaWNoPGJyPg0KJmd0OyZndDsmZ3Q7ICZn
dDsgYWRkPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgY29tcGxleGl0eSBhbmQgdGhlIHBvc3NpYmls
aXR5IG9mIHdyaXRpbmcgZXJyb3ItcHJvbmUgY29kZS4mbmJzcDsgVGhlIGlkZWE8YnI+DQomZ3Q7
Jmd0OyZndDsgJmd0OyBvZjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IHNvbWVvbmUgb2ZmbG9hZGlu
ZyBhY2sgcHJvY2Vzc2luZyBhbmQgdGhlbiBwcm9jZWVkaW5nIHRvIHRydXN0IHRoZTxicj4NCiZn
dDsmZ3Q7Jmd0OyAmZ3Q7IGxlbmd0aDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IHNlZW1zIGxpa2Ug
c29tZW9uZSBjb3VsZCBnZXQgd3JvbmcgYW5kIGNhdXNlIHNvbWUgY29uY2VybmluZyBpc3N1ZXMu
PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBNeSBleHBlcmll
bmNlIGlzIG11bHRpdGhyZWFkZWQgcGFja2V0IHByb2Nlc3NpbmcgaXMgbW9yZSBjb3N0IGFuZCB3
b3JrPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgdGhhbjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IGl0
J3Mgd29ydGguJm5ic3A7IFN1cmUgeW91IGNhbid0IGZpbGwgYSAxMDBHIE5JQyB3aXRoIG9uZSBj
b25uZWN0aW9uLCBidXQ8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyB0aGF0PGJyPg0KJmd0OyZndDsm
Z3Q7ICZndDsgc2VlbXMgbGlrZSBhbiBhY2FkZW1pYyBwcm9ibGVtLCBub3Qgb25lIGZvciB3b3Jr
bG9hZHMgSSd2ZSBzZWVuLjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IFR5cGljYWxseTxicj4NCiZn
dDsmZ3Q7Jmd0OyAmZ3Q7IHRoZSBleHRyYSBjb3N0IG9mIG11bHRpdGhyZWFkaW5nIG91dHdlaWdo
cyBpdHMgdmFsdWUuPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0
OyBUbyBiZSBjbGVhciwgSSBkb24ndCB0aGluayB0aGlzIGlzIGFuIGF3ZnVsIGlkZWEsIGJ1dCBJ
IGFsc28gZG9uJ3Qgc2VlPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyZndDsm
Z3Q7ICZndDsgdmFsdWUgYW5kIGl0IGFkZHMgY29tcGxleGl0eS4mbmJzcDsgSSByZWFkIE1hbmFz
aSdzIGVtYWlsLCBidXQgSSBkb24ndCB0aGluazxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IEk8YnI+
DQomZ3Q7Jmd0OyZndDsgJmd0OyB1bmRlcnN0YW5kIHdoeSBhbnkgb2YgdGhvc2UgbWF0dGVyIGlu
IHByYWN0aWNlLjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsg
T24gU2F0LCBKdW4gMTYsIDIwMTggYXQgNDoxMyBQTSBFcmljIFJlc2NvcmxhICZsdDs8L3NwYW4+
PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmVrckBydGZt
LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZn
dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIEZyaSwgSnVuIDE1
LCAyMDE4IGF0IDY6NDYgUE0sIE1hcnRlbiBTZWVtYW5uPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+bWFydGVuc2VlbWFubkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHdyb3RlOjxicj4N
CiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7
IFRoaXMgcHJvcG9zYWwgaW5jcmVhc2VzIHRoZSBzaXplIG9mIHRoZSBBQ0sgZnJhbWUgYnkgMSBi
eXRlIGluIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29tbW9uPGJyPg0KJmd0
OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBjYXNlIChsZXNzIHRoYW4gNjMgQUNLIHJhbmdlcyksIHNp
bmNlIHRoZSBBQ0sgbGVuZ3RoIGZpZWxkIGhlcmU8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsm
Z3Q7IGFsd2F5czxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgY29uc3VtZXMgMiBieXRl
cywgd2hlcmVhcyB0aGUgQUNLIEJsb2NrIENvdW50IGlzIGEgdmFyaWFibGUtbGVuZ3RoPGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBpbnRlZ2VyLjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0OyZndDsgQ29uc2lkZXJpbmcgaG93IG11Y2ggd29yayB3ZSBwdXQgaW50byBtaW5pbWlzaW5n
IHRoZSBzaXplIG9mIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgZnJhbWVzLDxi
cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgdGhpcyBmZWVscyBsaWtlIGEgc3RlcCBpbiB0
aGUgd3JvbmcgZGlyZWN0aW9uLi48YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBSZWdhcmRpbmcgdGhlIHByb2Nlc3NpbmcgY29zdCwg
SSBhZ3JlZSB3aXRoIERtaXRyaS4gSGFuZGxpbmcgYW4gQUNLPGJyPg0KJmd0OyZndDsmZ3Q7ICZn
dDsmZ3Q7Jmd0OyBmcmFtZTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcmVxdWlyZXMg
bG9vcGluZyBvdmVyIGFuZCBtYWtpbmcgY2hhbmdlcyB0byBhIGRhdGEgc3RydWN0dXJlIHRoYXQ8
YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IGtlZXBzPGJyPg0KJmd0OyZndDsmZ3Q7ICZn
dDsmZ3Q7Jmd0OyB0cmFjayBvZiBzZW50IHBhY2tldHMuIFRoaXMgaXMgbXVjaCBtb3JlIGV4cGVu
c2l2ZSB0aGFuIHNpbXBseTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgcGFyc2luZzxi
cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsgYTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0
OyZndDsgYnVuY2ggb2YgdmFyaW50cyBpbiB0aGUgQUNLIGZyYW1lLiBJdCBzZWVtcyB1bmxpa2Vs
eSB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IG11bHRpLXRocmVhZGVkPGJy
Pg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyBwYWNrZXQgcGFyc2VyIHdvdWxkIG9mZmVyIGFu
eSByZWFsLXdvcmxkIHBlcmZvcm1hbmNlIGJlbmVmaXRzLjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0
OyBJIGRvbid0IHdhbnQgdG8gb3ZlcnN0YXRlIHRoZSBiZW5lZml0IGhlcmUsIGJ1dCBteSBwb2lu
dCBpc24ndCB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHBhcnNpbmcgaXMgZXhwZW5z
aXZlIGJ1dCB0aGF0IGlmIHlvdSB3YW50IHRvIGhhdmUgYSBtdWx0aXRocmVhZGVkPGJyPg0KJmd0
OyZndDsmZ3Q7ICZndDsmZ3Q7IHBhY2tldDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBwcm9j
ZXNzaW5nIHN5c3RlbSwgdGhlbiBpdCdzIG5pY2UgdG8gaGF2ZSBhIHNpbXBsZXIgZGF0YSBzdHJ1
Y3R1cmU8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsgKHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0OyB1bnBhcnNlZCBBQ0sgYmxvY2spIHRvIGhhbmQgdG8gdGhlIEFDSyBwcm9jZXNzaW5n
IHRocmVhZC48YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0
OyZndDsgLUVrcjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg
Jmd0OyZndDsmZ3Q7IE9uIFNhdCwgSnVuIDE2LCAyMDE4IGF0IDY6MTkgQU0gTWFydGluIFRob21z
b248YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFp
bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm1hcnRpbi50
aG9tc29uQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgV2hlbiB3ZSBkaXNj
dXNzZWQgdGhpcyBiZWZvcmUsIHNvbWUgcGVvcGxlIG9ic2VydmVkIHRoYXQgdGhpczxicj4NCiZn
dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNyZWF0ZXM8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyBhIG5lZWQgdG8gZW5jb2RlIGluIHR3byBwYXNzZXMuJm5ic3A7IFRoYXQn
cyB0aGUgdHJhZGUtb2ZmIGhlcmUuJm5ic3A7IChOb3Q8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZn
dDsmZ3Q7Jmd0OyBleHByZXNzaW5nIGFuIG9waW5pb24uKTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0IDM6NTEgUE0gSmFuYSBJeWVuZ2Fy
ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPmpyaS5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7
Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsgJmd0OyBJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLiBJJ20g
Y2VydGFpbmx5IG5vdCBvcHBvc2VkPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
Jmd0OyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsgaXQuPGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBEb2VzIGFueW9uZSBoYXZlIGEgc3Ry
b25nIG9wcG9zaXRpb24/PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsgT24gRnJpLCBKdW4gMTUsIDIw
MTggYXQgMzoxMCBQTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cHJhdmJAbWlj
cm9zb2Z0LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnByYXZiQG1pY3Jvc29mdC5jb208L3NwYW4+
PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
Jmd0OyZndDsgSSBhZ3JlZSBhcyB3ZWxsIHNpbmNlIHRoaXMgY2FuIGhlbHAgcmVkdWNlIHBlciBw
YWNrZXQgcHJvY2Vzc2luZzxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7IG92ZXJoZWFkLiBBQ0tzIGFyZSBnb2luZyB0byBiZSB0aGUgc2Vjb25kIG1vc3QgY29tbW9u
IGZyYW1lIHR5cGU8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBz
byBubzxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG9iamVjdGlv
bnMgdG8gc3BlY2lhbCBjYXNpbmcuPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7
ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgRnJvbTogUVVJQyBbbWFpbHRvOjwvc3Bhbj48YSBo
cmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cXVp
Yy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+XSBPbiBCZWhh
bGYgT2YgRXJpYzxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IFJl
c2NvcmxhPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgU2VudDog
RnJpZGF5LCBKdW5lIDE1LCAyMDE4IDk6MTEgQU08YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyAmZ3Q7Jmd0OyBUbzogRGV2YWwsIE1hbmFzaSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h
aWx0bzptYW5hc2kuZGV2YWxAaW50ZWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFuYXNpLmRl
dmFsQGludGVsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQomZ3Q7
Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBDYzogSmFuYSBJeWVuZ2FyICZsdDs8
L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPmpyaS5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7
IFFVSUMgV0cgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPnF1aWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgU3ViamVjdDog
UmU6IFByb3Bvc2FsIHRvIHJlcGxhY2UgQUNLIGJsb2NrIGNvdW50IHdpdGggQUNLIGxlbmd0aDxi
cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7IEkgYWdyZWUgd2l0aCBNYW5hc2kgaGVyZS4gVGhpcyBjaGFuZ2Ugd291bGQgYWxsb3cgYWNr
IGZyYW1lPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcGFyc2lu
Zzxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHRvIGJlIG1vcmUg
c2VsZi1jb250YWluZWQsIHdoaWNoIGlzIGFuIGFkdmFudGFnZSBmb3IgdGhlIHBhcnNlcjxicj4N
CiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCBhbHNvPGJyPg0KJmd0
OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcG90ZW50aWFsbHkgZm9yIHBhcmFs
bGVsaXNtIChiZWNhdXNlIHlvdSBjYW4gcXVpY2tseSBmaW5kIHRoZTxicj4NCiZndDsmZ3Q7Jmd0
OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGZyYW1lIGFuZCB0aGVuPGJyPg0KJmd0OyZndDsm
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgcHJvY2VzcyBpdCBpbiBwYXJhbGxlbCkuPGJy
Pg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn
dDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZn
dDsgLUVrcjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg
Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsm
Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBPbiBNb24sIEp1biAx
MSwgMjAxOCBhdCA1OjIyIFBNLCBEZXZhbCwgTWFuYXNpPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7Jmd0OyZndDsgJmd0OyZndDsgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFuYXNpLmRl
dmFsQGludGVsLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm1hbmFzaS5kZXZhbEBpbnRlbC5jb208
L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0
OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0
OyZndDsgJmd0OyZndDsgSW4gZ2VuZXJhbCwgdmFyaW50cyByZXF1aXJlIHNvbWUgc3BlY2lmaWMg
bG9naWMgZm9yIHBhcnNpbmcuIFRvPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
Jmd0OyZndDsgc2tpcDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7
IG92ZXIgYW55IGhlYWRlciwgSSBoYXZlIHRvIHJlYWQgZXZlcnkgc2luZ2xlIHZhcmludC4gQXMg
dGhlIGNvZGU8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBzZWVz
IFN0cmVhbTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGFuZCBB
Q0sgaGVhZGVycyBtb3N0IGZyZXF1ZW50bHksIHRoYXQgaXMgbXkgZm9jdXMuJm5ic3A7IFRoZSBT
dHJlYW08YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSBo
YXMgYTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGxlbmd0aCBp
biBpdHMgdGhpcmQgZmllbGQuPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZn
dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgQUNLIHBhcnNpbmcsIGhvd2V2ZXIsIG5lZWRzIDYgJiM0
MzsgMipudW1fYmxvY2tzIHJlYWRzIHRvIGlkZW50aWZ5PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7Jmd0OyZndDsgJmd0OyZndDsgbGVuZ3RoLiBUaGVyZSBhcmUgdHdvIHJlYWRzIGVhY2ggZm9y
IOKAmGxhcmdlc3QgYWNrbm93bGVkZ2Vk4oCZLCDigJhBQ0s8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBkZWxheeKAmSBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyDigJhBQ0sgYmxvY2sgY291bnTigJkuIFRoZSBwYWluIHBv
aW50IGlzIHRoZSB0b3RhbCBudW1iZXIgb2YgY3ljbGVzPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7Jmd0OyZndDsgJmd0OyZndDsgcGFyc2UgYW48YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyAmZ3Q7Jmd0OyBBQ0suIElmIEkgYW0gcHJvY2Vzc2luZyAxME0gcHBzLCB3aGVyZSAx
MCUgLSAzMCUgb2YgdGhlIHBhY2tldHM8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0
OyAmZ3Q7Jmd0OyBoYXZlIGE8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0OyBwaWdneWJhY2tlZCBBQ0ssIHRoZXNlIGN5Y2xlcyBiZWNvbWVzIGEgc2lnbmlmaWNhbnQg
Ym90dGxlbmVjay48YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyAmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn
dDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBN
YW5hc2k8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZn
dDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0
OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn
dDsmZ3Q7ICZndDsmZ3Q7IEZyb206IFFVSUMgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv
OnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnF1aWMtYm91bmNlc0Bp
ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl0gT24gQmVoYWxmIE9mIEphbmE8
YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJeWVuZ2FyPGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgU2VudDogTW9uZGF5LCBKdW5l
IDExLCAyMDE4IDM6MTEgUE08YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0OyBUbzogRGV2YWwsIE1hbmFzaSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYW5hc2ku
ZGV2YWxAaW50ZWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFuYXNpLmRldmFsQGludGVsLmNv
bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IFFVSUMgV0c8YnI+DQomZ3Q7Jmd0
OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0
bzpxdWljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cXVpY0BpZXRmLm9yZzwvc3Bhbj48
L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogUHJvcG9zYWwgdG8gcmVwbGFjZSBBQ0sgYmxvY2sg
Y291bnQgd2l0aCBBQ0sgbGVuZ3RoPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7
ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgWW91J3JlIHJpZ2h0IHRoYXQgd2Ugbm8gbG9uZ2Vy
IGhhdmUgdGhlIGFiaWxpdHkgdG8gc2tpcCBhbiBBQ0s8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZn
dDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBmcmFtZSw8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7
Jmd0OyAmZ3Q7Jmd0OyBhbmQgdGhpcyBjcmVwdCBpbiB3aGVuIHdlIG1vdmVkIHRvIHZhcmludHMu
PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGJlbGlldmUgeW91ciBwcm9ibGVtIHRo
b3VnaCBpcyBnZW5lcmFsbHkgdHJ1ZSBvZiBtb3N0IGZyYW1lczxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IG5vdDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZn
dDsmZ3Q7ICZndDsmZ3Q7IGp1c3QgQUNLcywgc2luY2UgaWRzLCBwYWNrZXQgbnVtYmVycywgYW5k
IG51bWJlcnMgaW4gYWxsIGZyYW1lczxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
ICZndDsmZ3Q7IGFyZSBub3cgYWxsPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg
Jmd0OyZndDsgdmFyaW50cy4gVG8gc2tpcCBhbnkgZnJhbWUsIHlvdSdsbCBuZWVkIHRvIHBhcnNl
IHRoZSB2YXJpbnQ8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBm
aWVsZHM8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBpbiB0aG9z
ZTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGZyYW1lcy4gSWYg
eW91IGhhdmUgbG9naWMgdG8gcHJvY2VzcyBhbmQgc2tpcCB2YXJpbnRzLCB0aGVuPGJyPg0KJmd0
OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgc2tpcHBpbmcgdGhlIGFjazxicj4N
CiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGJsb2NrIHNlY3Rpb24gaXMg
bWVyZWx5IHJlcGVhdGluZyB0aGlzIG9wZXJhdGlvbiAoMipudW1fYmxvY2smIzQzOzEpPGJyPg0K
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgdGltZXMuIERvPGJyPg0KJmd0
OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgeW91IHNlZSBzcGVjaWZpYyB2YWx1
ZSBpbiBza2lwcGluZyBBQ0sgZnJhbWVzIG92ZXIgdGhlIG90aGVyPGJyPg0KJmd0OyZndDsmZ3Q7
ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgY29udHJvbCBmcmFtZXM/PGJyPg0KJmd0OyZndDsm
Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsm
Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7
Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IE9uIE1vbiwgSnVuIDExLCAyMDE4IGF0IDg6NDMgQU0gRG1p
dHJpIFRpa2hvbm92PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsg
Jmx0O2R0aWtob25vdkBsaXRlc3BlZWR0ZWNoLi5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7
Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7
Jmd0OyZndDsgJmd0OyZndDsgT24gTW9uLCBKdW4gMTEsIDIwMTggYXQgMDM6MzM6MzVQTSAmIzQz
OzAwMDAsIERldmFsLCBNYW5hc2kgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0
OyZndDsgJmd0OyZndDsgJmd0OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1vdmluZyB0
aGUgQUNLIGxlbmd0aCB0byB0aGUgZnJvbnQgb2YgdGhlIEFDSyBhbGxvd3M8YnI+DQomZ3Q7Jmd0
OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7Jmd0
OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IGZsZXhpYmlsaXR5IG9mIGVpdGhlciByZWFkaW5nIHRoZSBlbnRpcmUgQUNLIG9y
PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyByZWFkaW5n
PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyB0aGU8YnI+
DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmaXJzdCAxNiBiaXRzIGFuZCBza2lwcGluZyBvdmVyIHRo
ZSBsZW5ndGguIFRoaXMgaXMgYTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZn
dDsmZ3Q7ICZndDsgdXNlZnVsPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0
OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZmVhdHVyZSBmb3Ig
dGhlIGNhc2Ugd2hlcmUgQUNLIHByb2Nlc3NpbmcgaXMgc3BsaXQ8YnI+DQomZ3Q7Jmd0OyZndDsg
Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGludG88YnI+DQomZ3Q7Jmd0OyZndDsgJmd0
OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyBtdWx0aXBsZSBsYXllcnMuIERlcGVuZGluZyBvbiB0aGUgcHJvY2Vzc29yIHRoaXMgaXM8
YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHJ1bjxicj4N
CiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7ICZndDsgb24sPGJyPg0KJmd0
OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgdGhlcmUgYXJlIGRpZmZlcmVudCBhZHZhbnRhZ2VzIC08YnI+DQom
Z3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IEp1c3QgYSBub3RlLiZuYnNwOyBJbiBteSBleHBlcmll
bmNlLCB0aGUgY29zdCBvZiBwYXJzaW5nIGFuIEFDSyBmcmFtZTxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IGlzPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0
OyZndDsgJmd0OyZndDsgbmVnbGlnaWJsZSBjb21wYXJlZCB0byB0aGUgY29zdCBvZiBwcm9jZXNz
aW5nIGFuIEFDSyBmcmFtZTogdGhhdDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7
ICZndDsmZ3Q7IGlzLDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7
IHBva2luZyBhdCB2YXJpb3VzIG1lbW9yeSBsb2NhdGlvbnMgdG8gZGlzY2FyZCBuZXdseSBBQ0tl
ZDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7IHBhY2tldHMuPGJy
Pg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDstIERtaXRyaS48YnI+DQom
Z3Q7Jmd0OyZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAm
Z3Q7Jmd0OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsmZ3Q7Jmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7Jmd0OyBLYXp1aG8gT2t1PGJyPg0KJmd0Ozxicj4N
CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgS2F6dWhvIE9rdTxicj4NCjxi
cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojODg4ODg4Ij4tLTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4
OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+S2F6dWhvIE9rdTwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_1F436ED13A22A246A59CA374CBC543998B86D457ORSMSX111amrcor_--


From nobody Sun Jul 15 07:34:13 2018
Return-Path: 
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 8E97E130F65 for ; Sun, 15 Jul 2018 07:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 d9HtV_Ke1UQS for ; Sun, 15 Jul 2018 07:33:55 -0700 (PDT)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CA6130EDD for ; Sun, 15 Jul 2018 07:33:55 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 07:33:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.51,357,1526367600"; d="scan'208,217"; a="54511577"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga007.fm.intel.com with ESMTP; 15 Jul 2018 07:33:13 -0700
Received: from orsmsx113.amr.corp.intel.com (10.22.240.9) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 15 Jul 2018 07:33:13 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX113.amr.corp.intel.com ([169.254.9.96]) with mapi id 14.03.0319.002; Sun, 15 Jul 2018 07:33:13 -0700
From: "Deval, Manasi" 
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , QUIC WG , Marten Seemann 
Subject: RE: Connection ID lengths 1, 2 and 3
Thread-Topic: Connection ID lengths 1, 2 and 3
Thread-Index: AQHUEsvAi91oX8DVaUqbcldKc5Rk06R97QgAgBGLlvCAAOSi4A==
Date: Sun, 15 Jul 2018 14:33:12 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWQzZGY3YjEtZjRlNC00OWI1LTkxMjktNDBmYzRhOWUxNjgxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiU05XUWJFWFMzVEY2NjVhRFNQa1BaTnpXaUdpbDlrczZJUUVXdFp2RkFCYzB2V1l1cFdvVWljdTNmXC9CbE03SG4ifQ==
x-ctpclassification: CTP_NT
x-originating-ip: [10.22.254.139]
Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B86DF5EORSMSX111amrcor_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 14:34:12 -0000

--_000_1F436ED13A22A246A59CA374CBC543998B86DF5EORSMSX111amrcor_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QW5vdGhlciBpc3N1ZSBJIG5vdGljZWQgd2l0aCB0aGUgc2l6ZSBvZiBjb25uZWN0aW9uIGlkIHdh
cyB3aXRoIHJlZ2FyZHMgdG8gcGFyc2luZyB0aGUgaGVhZGVyIGZpZWxkLiBUaGUgY3VycmVudCBz
dGVwcyBhcmU6DQoNCsK3ICAgICAgICBQYXJzZSBEQ2lkIGxlbmd0aCwNCg0KwrcgICAgICAgIEFk
ZCAzLA0KDQrCtyAgICAgICAgUGFyc2UgRENpZCBsZW5ndGgNCg0KwrcgICAgICAgIEFkZCAzLA0K
DQrCtyAgICAgICAgUmVhZCBEQ0lEDQoNCsK3ICAgICAgICBSZWFkIFNDSUQuDQoNCkkgcmVhbGx5
IGFwcHJlY2lhdGUgdGhlIGZpeGVkIHNpemUgbGVuZ3RoIGZpZWxkcyBzbyB3ZSBjYW4ga25vdyBi
b3RoIGRlc3RpbmF0aW9uIGFuZCBzb3VyY2UgQ2lkIGxlbmd0aHMgaW4gcGFyYWxsZWwuIEltcGxl
bWVudGluZyB0aGlzIGluIGhhcmR3YXJlIGhhcyB0aGUgZm9sbG93aW5nIGNoYWxsZW5nZXMgdGhv
dWdoOg0KDQphLiAgICAgIFRoZXJlIGFyZSAxMiB1bmlxdWUgbGVuZ3RoIHR5cGVzIGZvciBlYWNo
IG9mIHRoZSBDaURzLiBUaGlzIG1lYW5zIGVpdGhlciBtb3JlIHN0YWdlcyBvZiBzZXJpYWwgcHJv
Y2Vzc2luZywgd2hpY2ggd291bGQgYmUgc2xvd2VyLiBPciBpdCBtZWFucyBtb3JlIGxvZ2ljIGZv
ciBwYXJhbGxlbCBwcm9jZXNzaW5nLg0KDQpiLiAgICAgIEluIGFkZGl0aW9uIHRvIHRoaXMsIHRo
ZSBhcml0aG1ldGljIGxvZ2ljIHRvIGFkZCAzIGlzIGEgbGl0dGxlIG1vcmUgc3BlY2lhbGl6ZWQg
dGhhbiBhIGxvZ2ljYWwgb3BlcmF0aW9uLCBlLmcuc2hpZnQgbGVmdC4NCg0KVGhlcmVmb3JlLCBJ
IHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUgYmFzaXMgZm9yIGhhdmluZyAxMiBkaWZmZXJl
bnQgbGVuZ3RocyBhbmQgaWYgdGhlcmUgaXMgYSBjaGFuY2UgdG8gc2ltcGxpZnkgdGhpcyBsb2dp
Yywgd2UgY2FuIGhhdmUgYSAzIGJpdCBsZW5ndGggYW5kIHNoaWZ0IGxlZnQgMSwgc28gd2UgaGF2
ZSBsZW5ndGhzIG9mIDAsMiw04oCmIDE0LiBXb3VsZCB0aGUgbG9zcyBvZiBsb25nZXIgQ2lEIHZh
bHVlcyBmcm9tIDE1IHRvIDE4IGJlIGFuIGlzc3VlPw0KDQpUaGFua3MsDQpNYW5hc2kNCg0KRnJv
bTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2tl
bCBGYWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMDMsIDIwMTggNjowNiBB
TQ0KVG86IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2Vl
bWFubkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogQ29ubmVjdGlvbiBJRCBsZW5ndGhzIDEsIDIg
YW5kIDMNCg0KVGhhdCBpcyBjb3JyZWN0LiBFc3BlY2lhbGx5IGluIGxvdy1wb3dlciBzZW5zb3Ig
bWVzaCBuZXR3b3Jrcy4NCg0KDQoNCk9uIDMgSnVseSAyMDE4IGF0IDE0LjQ1LjMwLCBNYXJ0ZW4g
U2VlbWFubiAobWFydGVuc2VlbWFubkBnbWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21h
aWwuY29tPikgd3JvdGU6DQpGaXJzdCBvZiBhbGwsIEkgcmVhbGlzZSB0aGF0IEknbSBicmluZ2lu
ZyB0aGlzIHVwIGxhdGUgaW4gdGhlIHByb2Nlc3MsIGFuZCBtYXliZSB0b28gbGF0ZSwgc2luY2Ug
dGhpcyB3b3VsZCByZXF1aXJlIGEgY2hhbmdlIHRvIHRoZSBpbnZhcmlhbnRzLg0KDQpUaGUgY29u
bmVjdGlvbiBJRHMgY2FuIGJlIGVpdGhlciAwIGJ5dGVzIG9yIGFueXRoaW5nIGJldHdlZW4gNCBh
bmQgMTggYnl0ZXMgKGluY2x1c2l2ZSkuIExlbmd0aHMgb2YgMSwgMiBhbmQgMyBieXRlcyBhcmUg
bm90IHBvc3NpYmxlLg0KRm9yIHAycCBhcHBsaWNhdGlvbnMsIGFuZCBmb3Igc2VydmVyIGRlcGxv
eW1lbnRzIHRoYXQgYXJlIG5vdCBkb2luZyBjb25uZWN0aW9uIElEIGJhc2VkIGxvYWQgYmFsYW5j
aW5nLCBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byB1c2Ugc2hvcnRlciBjb25uZWN0aW9uIElE
cy4gT25lIG1pZ2h0IGltYWdpbmUgdGhhdCBhIHBlZXIgZW5jb2RlcyB0aGUgbGVuZ3RoIG9mIHRo
ZSBjb25uZWN0aW9uIElEIGludG8gdGhlIGZpcnN0IGZldyBiaXRzLCBhbmQgdGhlbiBzdGFydHMg
dXNpbmcgMSBieXRlIGNvbm5lY3Rpb24gSURzIGZpcnN0LCBhbmQgc3VjY2Vzc2l2ZWx5IG1vdmVz
IHRvIGxvbmdlciBsZW5ndGhzIG9ubHkgd2hlbiBoYW5kbGluZyBtb3JlIGNvbm5lY3Rpb25zLiBB
IHAycCBob3N0IGhhbmRsaW5nIHNldmVyYWwgdGhvdXNhbmQgc2ltdWx0YW5lb3VzIGNvbm5lY3Rp
b25zICh3aGljaCB3aWxsIGJlIGVub3VnaCBmb3IgbWFueSBwMnAgcHJvdG9jb2xzKSB3b3VsZCBu
ZXZlciBoYXZlIHRvIHVzZSBhbnl0aGluZyBsb25nZXIgdGhhbiAyIGJ5dGUgY29ubmVjdGlvbiBJ
RHMuDQoNCkluIHRoZSBjb25uZWN0aW9uIElEIGxlbmd0aCBmaWVsZCBpbiB0aGUgTG9uZyBIZWFk
ZXIsIHdlIG9ubHkgaGF2ZSB0byA0IGJpdCB0byBlbmNvZGUgYSByYW5nZSBvZiAxOSB2YWx1ZXMg
KHdlIHdhbnQgMCBieXRlIGNvbm5lY3Rpb24gSURzLCBhbmQgd2Ugd2FudCB0byBzdXBwb3J0IDE4
IGJ5dGUgY29ubmVjdGlvbiBJRHMpLCBzbyAqc29tZSogdmFsdWVzIGhhdmUgdG8gYmUgbGVmdCBv
dXQuIEhvd2V2ZXIsIGxlYXZpbmcgb3V0IDEsIDIgYW5kIDMgc2VlbXMgYSBiaXQgdW5mb3J0dW5h
dGUsIGFzIHRoZXJlIHdpbGwgYmUgbW9yZSB1c2UgY2FzZXMgZm9yIHRoZXNlIHZhbHVlcyB0aGFu
IGUuZy4gZm9yIDEzLCAxNCBhbmQgMTUgYnl0ZXMuDQo=

--_000_1F436ED13A22A246A59CA374CBC543998B86DF5EORSMSX111amrcor_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2
ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw
Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz
dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ
bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24s
IGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u
cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzE0Mzc4NDAxOw0KCW1zby1saXN0LXR5cGU6
aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODcxODkxNzYwIDY3Njk4Njg5IDY3Njk4
NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx
IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwz
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp
c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i
b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
LHNlcmlmO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1MDkyNDc2NTU7
DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0NDUyMTAx
ODYgNjc2OTg3MTMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUg
Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K
QGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs
aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs
NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy
b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcN
Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA
bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo
dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTk0MTkw
ODYwNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAw
MDA4NTkwMiA2NzY5ODcxMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5
ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93
ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7
fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6
bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxl
dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl
cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9
DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N
CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv
dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286
c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V
UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFu
b3RoZXIgaXNzdWUgSSBub3RpY2VkIHdpdGggdGhlIHNpemUgb2YgY29ubmVjdGlvbiBpZCB3YXMg
d2l0aCByZWdhcmRzIHRvIHBhcnNpbmcgdGhlIGhlYWRlciBmaWVsZC4gVGhlIGN1cnJlbnQgc3Rl
cHMgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo
IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtp
ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8
c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXJzZSBEQ2lkIGxl
bmd0aCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo
IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtp
ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8
c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZGQgMywNCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4
dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExp
c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29s
b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i
Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QYXJzZSBEQ2lkIGxlbmd0aDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p
bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3Rz
XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6
IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u
dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZGQgMyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt
c28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFu
IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+UmVhZCBEQ0lEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv
LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8
L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPlJlYWQgU0NJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PkkgcmVhbGx5IGFwcHJlY2lhdGUgdGhlIGZpeGVkIHNpemUgbGVuZ3RoIGZpZWxkcyBzbyB3ZSBj
YW4ga25vdyBib3RoIGRlc3RpbmF0aW9uIGFuZCBzb3VyY2UgQ2lkIGxlbmd0aHMgaW4gcGFyYWxs
ZWwuIEltcGxlbWVudGluZyB0aGlzIGluIGhhcmR3YXJlIGhhcyB0aGUgZm9sbG93aW5nDQogY2hh
bGxlbmdlcyB0aG91Z2g6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ
YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm
bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48
c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPlRoZXJlIGFyZSAxMiB1bmlxdWUgbGVuZ3RoIHR5cGVzIGZvciBlYWNoIG9mIHRoZSBD
aURzLiBUaGlzIG1lYW5zIGVpdGhlciBtb3JlIHN0YWdlcyBvZiBzZXJpYWwgcHJvY2Vzc2luZywg
d2hpY2ggd291bGQgYmUgc2xvd2VyLiBPciBpdCBtZWFucyBtb3JlIGxvZ2ljDQogZm9yIHBhcmFs
bGVsIHByb2Nlc3NpbmcuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0
UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBs
Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5JbiBhZGRpdGlvbiB0byB0aGlzLCB0aGUgYXJpdGhtZXRpYyBsb2dpYyB0byBhZGQg
MyBpcyBhIGxpdHRsZSBtb3JlIHNwZWNpYWxpemVkIHRoYW4gYSBsb2dpY2FsIG9wZXJhdGlvbiwg
ZS5nLnNoaWZ0IGxlZnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPlRoZXJlZm9yZSwgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIGJhc2lzIGZvciBo
YXZpbmcgMTIgZGlmZmVyZW50IGxlbmd0aHMgYW5kIGlmIHRoZXJlIGlzIGEgY2hhbmNlIHRvIHNp
bXBsaWZ5IHRoaXMgbG9naWMsIHdlIGNhbiBoYXZlIGEgMyBiaXQgbGVuZ3RoIGFuZA0KIHNoaWZ0
IGxlZnQgMSwgc28gd2UgaGF2ZSBsZW5ndGhzIG9mIDAsMiw04oCmIDE0LiBXb3VsZCB0aGUgbG9z
cyBvZiBsb25nZXIgQ2lEIHZhbHVlcyBmcm9tIDE1IHRvIDE4IGJlIGFuIGlzc3VlPw0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPk1hbmFzaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu
IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFy
YXRvciI+PC9hPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg
T2YgPC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh
eSwgSnVseSAwMywgMjAxOCA2OjA2IEFNPGJyPg0KPGI+VG86PC9iPiBRVUlDIFdHICZsdDtxdWlj
QGlldGYub3JnJmd0OzsgTWFydGVuIFNlZW1hbm4gJmx0O21hcnRlbnNlZW1hbm5AZ21haWwuY29t
Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ29ubmVjdGlvbiBJRCBsZW5ndGhzIDEsIDIg
YW5kIDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0IGlzIGNvcnJl
Y3QuIEVzcGVjaWFsbHkgaW4gbG93LXBvd2VyIHNlbnNvciBtZXNoIG5ldHdvcmtzLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bfc2lnbl8xNTMwNjIzMDY3MjMx
ODgzMDA4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMyBKdWx5IDIwMTgg
YXQgMTQuNDUuMzAsIE1hcnRlbiBTZWVtYW5uICg8YSBocmVmPSJtYWlsdG86bWFydGVuc2VlbWFu
bkBnbWFpbC5jb20iPm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPikgd3JvdGU6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZpcnN0IG9mIGFsbCwgSSByZWFsaXNlIHRoYXQg
SSdtIGJyaW5naW5nIHRoaXMgdXAgbGF0ZSBpbiB0aGUgcHJvY2VzcywgYW5kIG1heWJlIHRvbyBs
YXRlLCBzaW5jZSB0aGlzIHdvdWxkIHJlcXVpcmUgYSBjaGFuZ2UgdG8gdGhlIGludmFyaWFudHMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY29u
bmVjdGlvbiBJRHMgY2FuIGJlIGVpdGhlciAwIGJ5dGVzIG9yIGFueXRoaW5nIGJldHdlZW4gNCBh
bmQgMTggYnl0ZXMgKGluY2x1c2l2ZSkuIExlbmd0aHMgb2YgMSwgMiBhbmQgMyBieXRlcyBhcmUg
bm90IHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gb3IgcDJwIGFwcGxpY2F0aW9ucywg
YW5kIGZvciBzZXJ2ZXIgZGVwbG95bWVudHMgdGhhdCBhcmUgbm90IGRvaW5nIGNvbm5lY3Rpb24g
SUQgYmFzZWQgbG9hZCBiYWxhbmNpbmcsIGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHVzZSBz
aG9ydGVyIGNvbm5lY3Rpb24gSURzLiBPbmUgbWlnaHQgaW1hZ2luZQ0KIHRoYXQgYSBwZWVyIGVu
Y29kZXMgdGhlIGxlbmd0aCBvZiB0aGUgY29ubmVjdGlvbiBJRCBpbnRvIHRoZSBmaXJzdCBmZXcg
Yml0cywgYW5kIHRoZW4gc3RhcnRzIHVzaW5nIDEgYnl0ZSBjb25uZWN0aW9uIElEcyBmaXJzdCwg
YW5kIHN1Y2Nlc3NpdmVseSBtb3ZlcyB0byBsb25nZXIgbGVuZ3RocyBvbmx5IHdoZW4gaGFuZGxp
bmcgbW9yZSBjb25uZWN0aW9ucy4gQSBwMnAgaG9zdCBoYW5kbGluZyBzZXZlcmFsIHRob3VzYW5k
IHNpbXVsdGFuZW91cw0KIGNvbm5lY3Rpb25zICh3aGljaCB3aWxsIGJlIGVub3VnaCBmb3IgbWFu
eSBwMnAgcHJvdG9jb2xzKSB3b3VsZCBuZXZlciBoYXZlIHRvIHVzZSBhbnl0aGluZyBsb25nZXIg
dGhhbiAyIGJ5dGUgY29ubmVjdGlvbiBJRHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGUgY29ubmVjdGlvbiBJRCBsZW5ndGggZmllbGQgaW4g
dGhlIExvbmcgSGVhZGVyLCB3ZSBvbmx5IGhhdmUgdG8gNCBiaXQgdG8gZW5jb2RlIGEgcmFuZ2Ug
b2YgMTkgdmFsdWVzICh3ZSB3YW50IDAgYnl0ZSBjb25uZWN0aW9uIElEcywgYW5kIHdlIHdhbnQg
dG8gc3VwcG9ydCAxOCBieXRlDQogY29ubmVjdGlvbiBJRHMpLCBzbyAqc29tZSogdmFsdWVzIGhh
dmUgdG8gYmUgbGVmdCBvdXQuIEhvd2V2ZXIsIGxlYXZpbmcgb3V0IDEsIDIgYW5kIDMgc2VlbXMg
YSBiaXQgdW5mb3J0dW5hdGUsIGFzIHRoZXJlIHdpbGwgYmUgbW9yZSB1c2UgY2FzZXMgZm9yIHRo
ZXNlIHZhbHVlcyB0aGFuIGUuZy4gZm9yIDEzLCAxNCBhbmQgMTUgYnl0ZXMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_1F436ED13A22A246A59CA374CBC543998B86DF5EORSMSX111amrcor_--


From nobody Sun Jul 15 07:45:04 2018
Return-Path: 
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 28C85130E09 for ; Sun, 15 Jul 2018 07:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level: 
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5uKDstKEzorC for ; Sun, 15 Jul 2018 07:44:59 -0700 (PDT)
Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 9AF18130DE4 for ; Sun, 15 Jul 2018 07:44:59 -0700 (PDT)
Received: by mail-yb0-x22f.google.com with SMTP id h127-v6so14509448ybg.12 for ; Sun, 15 Jul 2018 07:44:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2HE4UM4FgRzLemanDkYRy8O9CB4zPz0ASN/ifXJ2+as=; b=UmVwrFbMNKQHxwA7S4cdhB4E/iY0YuxqWpB061jrgOu1dKZw/VA7CE84+k2d8P7SmX kbomHkgeplssTNW4dFtZt0XEge+EovEAKD5S3Qv/IPZzEMIEtXMEmQ45rC4TeJEJpYtC Ef+0X/pTdxBNC0Xs7Gg/6F1mesbu/mN23UOI6Lb6oA0zB70gnd5kW6ObvWHfjOv7oerH 7y6nKf6o1ZRJ4sPweuERzjwMXq09WWJZ8WAdD9zJlUYSMZxYNXPECneM868Jf9nvynHG B2kvV55KKJYuY4YP3k3OEaXlqHgKuf8irvv6w9ABg/wl3S4PWB5dQjXtD4Ds26mZgnfa AtAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2HE4UM4FgRzLemanDkYRy8O9CB4zPz0ASN/ifXJ2+as=; b=j/W+sQ7TvUW98pNJsY0LYuM11zyIdNEf97X/ms8h5AggMr0Bshk2M7Y6Nxpgc+DtTa 8I35+RVDFOJ6NO+HJL461llfrkx3qa0BhOmkDH2PfBwxo4GSuSobnr88O3lAZ18j5Zbb Nj/I6bQRffPzeySBTIm+D7kSQ1NNvw4TiFeQOcUVsHXuM39Bjg0MGfHoBG9GJmUi+WCQ IxuujAx5wNP3X9GzeaSYXeQjfLVJFLgem6Gm/6dWJYfJzvW4DPV/j/Xrq2aRC/GiSzdJ ddXlvwFpt+gZbzbIcyoh7Xb5NY3AHwO0om70U7HZ0fEAfSPvycoWfS9dAz++LYwZK2Tt j4ew==
X-Gm-Message-State: AOUpUlEh5YhT2Lhluy2KU3Vyr9yAfN4nBwV1mWeOLjNbXR5NSnjW7zZ2 oUXI5erukigjKeIuKw8pHZttFRnwI+U5SEfenCK+vA6l
X-Google-Smtp-Source: AAOMgpd2CGrfiYUXlZz5g8ZnsImoic7tZ3k1eB7o9f+l+Zp+Pz2pCohm25/WEqTY8rsxAgmVl6PvS5sEvmPrflxDjlk=
X-Received: by 2002:a25:57d7:: with SMTP id l206-v6mr7084632ybb.206.1531665898612;  Sun, 15 Jul 2018 07:44:58 -0700 (PDT)
MIME-Version: 1.0
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>
From: Ian Swett 
Date: Sun, 15 Jul 2018 10:44:46 -0400
Message-ID: 
Subject: Re: Connection ID lengths 1, 2 and 3
To: "Deval, Manasi" 
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  IETF QUIC WG , Marten Seemann 
Content-Type: multipart/alternative; boundary="000000000000cdea7d05710ac1ae"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 14:45:02 -0000

--000000000000cdea7d05710ac1ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If one uses existing fast crypto primitives to encode connection ID, then
16 bytes is a natural size, and there was interest in having an extra byte
for metadata(key rotation/length signaling/etc).

Unfortunately, that leaves us with a gap somewhere, and a gap at the
beginning seemed the most natural at the time.

On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi 
wrote:

> Another issue I noticed with the size of connection id was with regards t=
o
> parsing the header field. The current steps are:
>
> =C2=B7        Parse DCid length,
>
> =C2=B7        Add 3,
>
> =C2=B7        Parse DCid length
>
> =C2=B7        Add 3,
>
> =C2=B7        Read DCID
>
> =C2=B7        Read SCID.
>
>
>
> I really appreciate the fixed size length fields so we can know both
> destination and source Cid lengths in parallel. Implementing this in
> hardware has the following challenges though:
>
> a.      There are 12 unique length types for each of the CiDs. This means
> either more stages of serial processing, which would be slower. Or it mea=
ns
> more logic for parallel processing.
>
> b.      In addition to this, the arithmetic logic to add 3 is a little
> more specialized than a logical operation, e.g.shift left.
>
>
>
> Therefore, I would like to understand the basis for having 12 different
> lengths and if there is a chance to simplify this logic, we can have a 3
> bit length and shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. Wou=
ld the
> loss of longer CiD values from 15 to 18 be an issue?
>
>
>
> Thanks,
>
> Manasi
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3=
=B8e
> J=C3=B8rgensen
> *Sent:* Tuesday, July 03, 2018 6:06 AM
> *To:* QUIC WG ; Marten Seemann 
> *Subject:* Re: Connection ID lengths 1, 2 and 3
>
>
>
> That is correct. Especially in low-power sensor mesh networks.
>
>
>
>
>
> On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com)
> wrote:
>
> First of all, I realise that I'm bringing this up late in the process, an=
d
> maybe too late, since this would require a change to the invariants.
>
>
>
> The connection IDs can be either 0 bytes or anything between 4 and 18
> bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
>
> For p2p applications, and for server deployments that are not doing
> connection ID based load balancing, it would be interesting to use shorte=
r
> connection IDs. One might imagine that a peer encodes the length of the
> connection ID into the first few bits, and then starts using 1 byte
> connection IDs first, and successively moves to longer lengths only when
> handling more connections. A p2p host handling several thousand
> simultaneous connections (which will be enough for many p2p protocols)
> would never have to use anything longer than 2 byte connection IDs.
>
>
>
> In the connection ID length field in the Long Header, we only have to 4
> bit to encode a range of 19 values (we want 0 byte connection IDs, and we
> want to support 18 byte connection IDs), so *some* values have to be left
> out. However, leaving out 1, 2 and 3 seems a bit unfortunate, as there wi=
ll
> be more use cases for these values than e.g. for 13, 14 and 15 bytes.
>
>

--000000000000cdea7d05710ac1ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


If one uses existing fast crypto primitives to encode conn=
ection ID, then 16 bytes is a natural size, and there was interest in havin=
g an extra byte for metadata(key rotation/length signaling/etc).

Unfortunately, that leaves us with a gap somewhere, and a gap at t=
he beginning seemed the most natural at the time.

On Sun, Jul 15, 2018 at 10:35 AM Deval, M=
anasi <manasi.deval@intel.com<=
/a>> wrote:











Another issue I noticed with the size=
 of connection id was with regards to parsing the header field. The current=
 steps are:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Parse DCid length,



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Add 3,



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Parse DCid length<=
/span>


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Add 3,


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Read DCID

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Read SCID.<=
/p>

=C2=A0


I really appreciate the fixed size le=
ngth fields so we can know both destination and source Cid lengths in paral=
lel. Implementing this in hardware has the following
 challenges though:


<=
span>a.=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
There are 12 unique length types=
 for each of the CiDs. This means either more stages of serial processing, =
which would be slower. Or it means more logic
 for parallel processing. 


<=
span>b.=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
In addition to this, the arithme=
tic logic to add 3 is a little more specialized than a logical operation, e=
.g.shift left.



=C2=A0


Therefore, I would like to understand=
 the basis for having 12 different lengths and if there is a chance to simp=
lify this logic, we can have a 3 bit length and
 shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. Would the loss of l=
onger CiD values from 15 to 18 be an issue?



=C2=A0


Thanks,


Manasi


<=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1f497d">=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Tuesday, July 03, 2018 6:06 AM

To: QUIC WG <q=
uic@ietf.org>; Marten Seemann <martenseemann@gmail.com>

Subject: Re: Connection ID lengths 1, 2 and 3





=C2=A0




That is correct. Especially in low-power sensor m=
esh networks.








=C2=A0






=C2=A0


On 3 July 2018 at 14.45.30,=
 Marten Seemann (martenseemann@gmail.com) wrote:












First of all, I realise that I'm bringing thi=
s up late in the process, and maybe too late, since this would require a ch=
ange to the invariants.






=C2=A0






The connection IDs can be either 0 bytes or anyth=
ing between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not=
 possible.






For p2p applications, and for server deployments =
that are not doing connection ID based load balancing, it would be interest=
ing to use shorter connection IDs. One might imagine
 that a peer encodes the length of the connection ID into the first few bit=
s, and then starts using 1 byte connection IDs first, and successively move=
s to longer lengths only when handling more connections. A p2p host handlin=
g several thousand simultaneous
 connections (which will be enough for many p2p protocols) would never have=
 to use anything longer than 2 byte connection IDs.





=C2=A0






In the connection ID length field in the Long Hea=
der, we only have to 4 bit to encode a range of 19 values (we want 0 byte c=
onnection IDs, and we want to support 18 byte
 connection IDs), so *some* values have to be left out. However, leaving ou=
t 1, 2 and 3 seems a bit unfortunate, as there will be more use cases for t=
hese values than e.g. for 13, 14 and 15 bytes.



















--000000000000cdea7d05710ac1ae--


From nobody Sun Jul 15 09:41:56 2018
Return-Path: 
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 CC719130E3E for ; Sun, 15 Jul 2018 09:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XiOjshdI6sGH for ; Sun, 15 Jul 2018 09:41:51 -0700 (PDT)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FFD130E12 for ; Sun, 15 Jul 2018 09:41:51 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 09:41:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.51,357,1526367600"; d="scan'208,217"; a="57853279"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga006.jf.intel.com with ESMTP; 15 Jul 2018 09:41:46 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX106.amr.corp.intel.com ([169.254.1.85]) with mapi id 14.03.0319.002; Sun, 15 Jul 2018 09:41:46 -0700
From: "Deval, Manasi" 
To: Ian Swett 
CC: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "IETF QUIC WG" , Marten Seemann 
Subject: Re: Connection ID lengths 1, 2 and 3
Thread-Topic: Connection ID lengths 1, 2 and 3
Thread-Index: AQHUEsvAi91oX8DVaUqbcldKc5Rk06R97QgAgBGLlvCAAOSi4IAAh0AA//+rWH8=
Date: Sun, 15 Jul 2018 16:41:45 +0000
Message-ID: <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_0EA7393DB7EC4755B13E5177E24AA57Aintelcom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 16:41:54 -0000

--_000_0EA7393DB7EC4755B13E5177E24AA57Aintelcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I would still prefer if we can reduce the number of sizes supported.

Could a scheme where we support only 5 cids be used? Use a 3 bit size , shi=
ft left by 2 and not use the last 2 sizes of 24 and 28.


Thanks,
Manasi


On Jul 15, 2018, at 10:45 AM, Ian Swett > wrote:

If one uses existing fast crypto primitives to encode connection ID, then 1=
6 bytes is a natural size, and there was interest in having an extra byte f=
or metadata(key rotation/length signaling/etc).

Unfortunately, that leaves us with a gap somewhere, and a gap at the beginn=
ing seemed the most natural at the time.

On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi > wrote:
Another issue I noticed with the size of connection id was with regards to =
parsing the header field. The current steps are:

=95        Parse DCid length,

=95        Add 3,

=95        Parse DCid length

=95        Add 3,

=95        Read DCID

=95        Read SCID.

I really appreciate the fixed size length fields so we can know both destin=
ation and source Cid lengths in parallel. Implementing this in hardware has=
 the following challenges though:

a.      There are 12 unique length types for each of the CiDs. This means e=
ither more stages of serial processing, which would be slower. Or it means =
more logic for parallel processing.

b.      In addition to this, the arithmetic logic to add 3 is a little more=
 specialized than a logical operation, e.g.shift left.

Therefore, I would like to understand the basis for having 12 different len=
gths and if there is a chance to simplify this logic, we can have a 3 bit l=
ength and shift left 1, so we have lengths of 0,2,4=85 14. Would the loss o=
f longer CiD values from 15 to 18 be an issue?

Thanks,
Manasi

From: QUIC [mailto:quic-bounces@ietf.org] On =
Behalf Of Mikkel Fahn=F8e J=F8rgensen
Sent: Tuesday, July 03, 2018 6:06 AM
To: QUIC WG >; Marten Seemann >
Subject: Re: Connection ID lengths 1, 2 and 3

That is correct. Especially in low-power sensor mesh networks.



On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) wrote:
First of all, I realise that I'm bringing this up late in the process, and =
maybe too late, since this would require a change to the invariants.

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes=
 (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
For p2p applications, and for server deployments that are not doing connect=
ion ID based load balancing, it would be interesting to use shorter connect=
ion IDs. One might imagine that a peer encodes the length of the connection=
 ID into the first few bits, and then starts using 1 byte connection IDs fi=
rst, and successively moves to longer lengths only when handling more conne=
ctions. A p2p host handling several thousand simultaneous connections (whic=
h will be enough for many p2p protocols) would never have to use anything l=
onger than 2 byte connection IDs.

In the connection ID length field in the Long Header, we only have to 4 bit=
 to encode a range of 19 values (we want 0 byte connection IDs, and we want=
 to support 18 byte connection IDs), so *some* values have to be left out. =
However, leaving out 1, 2 and 3 seems a bit unfortunate, as there will be m=
ore use cases for these values than e.g. for 13, 14 and 15 bytes.

--_000_0EA7393DB7EC4755B13E5177E24AA57Aintelcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable






I would still prefer if we can reduce the number of sizes supported. 






Could a scheme where we support only 5 cids be used? Use a 3 bit size =
, shift left by 2 and not use the last 2 sizes of 24 and 28.














Thanks,


Manasi






On Jul 15, 2018, at 10:45 AM, Ian Swett <ianswett@google.com> wrote:










If one uses existing fast crypto primitives to encode conn=
ection ID, then 16 bytes is a natural size, and there was interest in havin=
g an extra byte for metadata(key rotation/length signaling/etc).






Unfortunately, that leaves us with a gap somewhere, and a gap at the b=
eginning seemed the most natural at the time.








On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi <manasi.deval@intel.com> wrote:









Another issue I noticed with the size=
 of connection id was with regards to parsing the header field. The current=
 steps are:


=B7      =
 
Parse DCid length,



=B7      =
 
Add 3,



=B7      =
 
Parse DCid length<=
/span>


=B7      =
 
Add 3,


=B7      =
 
Read DCID

=B7      =
 
Read SCID.<=
/p>

 


I really appreciate the fixed size le=
ngth fields so we can know both destination and source Cid lengths in paral=
lel. Implementing this in hardware has the following
 challenges though:


<=
span>a.  &=
nbsp;  
There are 12 unique length types=
 for each of the CiDs. This means either more stages of serial processing, =
which would be slower. Or it means more logic
 for parallel processing. 


<=
span>b.  &=
nbsp;  
In addition to this, the arithme=
tic logic to add 3 is a little more specialized than a logical operation, e=
.g.shift left.



 


Therefore, I would like to understand=
 the basis for having 12 different lengths and if there is a chance to simp=
lify this logic, we can have a 3 bit length and
 shift left 1, so we have lengths of 0,2,4=85 14. Would the loss of longer =
CiD values from 15 to 18 be an issue?



 


Thanks,


Manasi


<=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1f497d"> 






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=F8e J=F8rgensen

Sent: Tuesday, July 03, 2018 6:06 AM

To: QUIC WG <q=
uic@ietf.org>; Marten Seemann <martenseemann@gmail.com>

Subject: Re: Connection ID lengths 1, 2 and 3





 




That is correct. Especially in low-power sensor m=
esh networks.








 






 


On 3 July 2018 at 14.45.30,=
 Marten Seemann (martenseemann@gmail.com) wrote:












First of all, I realise that I'm bringing this up=
 late in the process, and maybe too late, since this would require a change=
 to the invariants.






 






The connection IDs can be either 0 bytes or anyth=
ing between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not=
 possible.






For p2p applications, and for server deployments =
that are not doing connection ID based load balancing, it would be interest=
ing to use shorter connection IDs. One might imagine
 that a peer encodes the length of the connection ID into the first few bit=
s, and then starts using 1 byte connection IDs first, and successively move=
s to longer lengths only when handling more connections. A p2p host handlin=
g several thousand simultaneous
 connections (which will be enough for many p2p protocols) would never have=
 to use anything longer than 2 byte connection IDs.





 






In the connection ID length field in the Long Hea=
der, we only have to 4 bit to encode a range of 19 values (we want 0 byte c=
onnection IDs, and we want to support 18 byte
 connection IDs), so *some* values have to be left out. However, leaving ou=
t 1, 2 and 3 seems a bit unfortunate, as there will be more use cases for t=
hese values than e.g. for 13, 14 and 15 bytes.






























--_000_0EA7393DB7EC4755B13E5177E24AA57Aintelcom_--


From nobody Sun Jul 15 09:52:16 2018
Return-Path: 
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 66375130DF9 for ; Sun, 15 Jul 2018 09:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 lnF0liKOPQCr for ; Sun, 15 Jul 2018 09:52:11 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 A344A1294D0 for ; Sun, 15 Jul 2018 09:52:11 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id v26-v6so35548420iog.5 for ; Sun, 15 Jul 2018 09:52:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aFbNQSutZCBLx2kgxkB1+XlSY7qZ0MkJ+c87qluDwp4=; b=j+PcWXSBTihxb5WFR/Q4KoQMdzio95PeWGgSId8Ba7d644sv9AY25YMKY5B7RAbA3I v2WhRUrjY7aM9SSzrzTNlUclTd6KOYQuFmE3gNf3dzQyqWbBRxcCbiF3wB4foNBuMkGm v/5+DsE3Ahtnc43r8GQ2jXsDPk6wu1kaKnGHsg4L5LQxq8u+9SqeyOdEqAL2gorTuZ/y LqrU4quMowDbIF1U+qRgvvq4TnnLy0jmc3gU37YBEC8l3sIkbjvMPo+hwLSg/EELaXK/ 4nlPd9EvpLhvNSrFgpgD/3XrPUPJe9n3EwkNwljJIzs4T1s7SwZJ10WDJv4H8swHVP/R F0gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aFbNQSutZCBLx2kgxkB1+XlSY7qZ0MkJ+c87qluDwp4=; b=Y5UvxtoL2urIK43ygvKZKwPoYPmzy6noYG8ob3EikFQC8oj+VT8KoziMsX3lcOCydb pVmUG8dQ1l4rqdM0n05MxrYeO7qbdWxFVi7tiBVwgkWUiZL3IePcSLH59lJTytDZSoMn pVFLyZGltFhYet4qHSJORGHee9F88+GhFbwQNfAF/0rT7ST5BN8Ej9cE9Ro2k1opc3ga fVKE/5EV5V8rnAouAjbaVzUEvED4PCw+XZQfAKgtPMf6QqprU75ev8ZcyyPwFPkF8hFC ljDCM7xvTf9gvnmkdvJ6oBca99oT3hspA2W63cBbW7rKQWhXLmo13EiGq1DdtRwrYAg5 sI9Q==
X-Gm-Message-State: AOUpUlFv8yD0sHlwxdiqwTgVFYiy8kaYWssVE8Be3JydQshsgDnha+Ia nOrYwt+M5BwESw9zXjY8Z2aCEv6sv3RzBl191g0=
X-Google-Smtp-Source: AAOMgpdqigk+iVqFyKOhv+oJD7BAK+++4b02PcsbmwKbmSCdJ9NgdDFG+CNcJAR8W2ORGT75UGL8S100kBsfr4ZmTKE=
X-Received: by 2002:a5e:de42:: with SMTP id e2-v6mr13438533ioq.235.1531673530803;  Sun, 15 Jul 2018 09:52:10 -0700 (PDT)
MIME-Version: 1.0
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>  <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>
In-Reply-To: <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>
From: Marten Seemann 
Date: Sun, 15 Jul 2018 17:51:59 +0100
Message-ID: 
Subject: Re: Connection ID lengths 1, 2 and 3
To: "Deval, Manasi" 
Cc: Ian Swett , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000b72ab905710c8881"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 16:52:15 -0000

--000000000000b72ab905710c8881
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't think we should reduce the number of sizes available. Sending bytes
on the wire is orders of magnitude more expensive than performing a simple
transformation to a parsed value. I'd prefer if we could discuss this
separately, since this is quite the opposite of what I was originally
proposing.

To reiterate my argument, changing the invariants such that the values 1, 2
and 3 can be used would be a big benefit for p2p applications, since they
would be able to use super-short connection IDs. Since this is a change
that requires a change to the invariants, we need to make this decision
very soon, if we want to enable this use case of QUIC.

On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi 
wrote:

> I would still prefer if we can reduce the number of sizes supported.
>
> Could a scheme where we support only 5 cids be used? Use a 3 bit size ,
> shift left by 2 and not use the last 2 sizes of 24 and 28.
>
>
> Thanks,
> Manasi
>
>
>
> On Jul 15, 2018, at 10:45 AM, Ian Swett  wrote:
>
> If one uses existing fast crypto primitives to encode connection ID, then
> 16 bytes is a natural size, and there was interest in having an extra byt=
e
> for metadata(key rotation/length signaling/etc).
>
> Unfortunately, that leaves us with a gap somewhere, and a gap at the
> beginning seemed the most natural at the time.
>
> On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi 
> wrote:
>
>> Another issue I noticed with the size of connection id was with regards
>> to parsing the header field. The current steps are:
>>
>> =C2=B7        Parse DCid length,
>>
>> =C2=B7        Add 3,
>>
>> =C2=B7        Parse DCid length
>>
>> =C2=B7        Add 3,
>>
>> =C2=B7        Read DCID
>>
>> =C2=B7        Read SCID.
>>
>>
>>
>> I really appreciate the fixed size length fields so we can know both
>> destination and source Cid lengths in parallel. Implementing this in
>> hardware has the following challenges though:
>>
>> a.      There are 12 unique length types for each of the CiDs. This
>> means either more stages of serial processing, which would be slower. Or=
 it
>> means more logic for parallel processing.
>>
>> b.      In addition to this, the arithmetic logic to add 3 is a little
>> more specialized than a logical operation, e.g.shift left.
>>
>>
>>
>> Therefore, I would like to understand the basis for having 12 different
>> lengths and if there is a chance to simplify this logic, we can have a 3
>> bit length and shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. Wo=
uld the
>> loss of longer CiD values from 15 to 18 be an issue?
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=
=C3=B8e
>> J=C3=B8rgensen
>> *Sent:* Tuesday, July 03, 2018 6:06 AM
>> *To:* QUIC WG ; Marten Seemann 
>> *Subject:* Re: Connection ID lengths 1, 2 and 3
>>
>>
>>
>> That is correct. Especially in low-power sensor mesh networks.
>>
>>
>>
>>
>>
>> On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com)
>> wrote:
>>
>> First of all, I realise that I'm bringing this up late in the process,
>> and maybe too late, since this would require a change to the invariants.
>>
>>
>>
>> The connection IDs can be either 0 bytes or anything between 4 and 18
>> bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
>>
>> For p2p applications, and for server deployments that are not doing
>> connection ID based load balancing, it would be interesting to use short=
er
>> connection IDs. One might imagine that a peer encodes the length of the
>> connection ID into the first few bits, and then starts using 1 byte
>> connection IDs first, and successively moves to longer lengths only when
>> handling more connections. A p2p host handling several thousand
>> simultaneous connections (which will be enough for many p2p protocols)
>> would never have to use anything longer than 2 byte connection IDs.
>>
>>
>>
>> In the connection ID length field in the Long Header, we only have to 4
>> bit to encode a range of 19 values (we want 0 byte connection IDs, and w=
e
>> want to support 18 byte connection IDs), so *some* values have to be lef=
t
>> out. However, leaving out 1, 2 and 3 seems a bit unfortunate, as there w=
ill
>> be more use cases for these values than e.g. for 13, 14 and 15 bytes.
>>
>>

--000000000000b72ab905710c8881
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't think we should reduce the number of sizes ava=
ilable. Sending bytes on the wire is orders of magnitude more expensive tha=
n performing a simple transformation to a parsed value. I'd prefer if w=
e could discuss this separately, since this is quite the opposite of what I=
 was originally proposing.

To reiterate my argument, cha=
nging the invariants such that the values 1, 2 and 3 can be used would be a=
 big benefit for p2p applications, since they would be able to use super-sh=
ort connection IDs. Since this is a change that requires a change to the in=
variants, we need to make this decision very soon, if we want to enable thi=
s use case of QUIC.

On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi <manasi.deval@intel.com> wrote:






I would still prefer if we can reduce the number of sizes supported.=C2=A0






Could a scheme where we support only 5 cids be used? Use a 3 bit size =
, shift left by 2 and not use the last 2 sizes of 24 and 28.














Thanks,


Manasi







On Jul 15, 2018, at 10:45 AM, Ian Swett <ianswett@google.com> wrote:










If one uses existing fast crypto primitives to encode conn=
ection ID, then 16 bytes is a natural size, and there was interest in havin=
g an extra byte for metadata(key rotation/length signaling/etc).






Unfortunately, that leaves us with a gap somewhere, and a gap at the b=
eginning seemed the most natural at the time.








On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi <manasi.deval@intel.com=
> wrote:










Another issue I noticed with the size=
 of connection id was with regards to parsing the header field. The current=
 steps are:


<=
u>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Parse DCid length,



<=
u>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Add 3,



<=
u>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Parse DCid length<=
/span>


<=
u>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Add 3,


<=
u>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Read DCID

<=
u>=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Read SCID.<=
/p>

=C2=A0


I really appreciate the fixed size le=
ngth fields so we can know both destination and source Cid lengths in paral=
lel. Implementing this in hardware has the following
 challenges though:


<=
u>a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
There are 12 unique length types=
 for each of the CiDs. This means either more stages of serial processing, =
which would be slower. Or it means more logic
 for parallel processing. 


<=
u>b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
In addition to this, the arithme=
tic logic to add 3 is a little more specialized than a logical operation, e=
.g.shift left.



=C2=A0


Therefore, I would like to understand=
 the basis for having 12 different lengths and if there is a chance to simp=
lify this logic, we can have a 3 bit length and
 shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. Would the loss of l=
onger CiD values from 15 to 18 be an issue?



=C2=A0


Thanks,


Manasi


=C2=A0






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Tuesday, July 03, 2018 6:06 AM

To: QUIC WG <q=
uic@ietf.org>; Marten Seemann <martenseemann@gmail.com>

Subject: Re: Connection ID lengths 1, 2 and 3





=C2=A0




That is correct. Especially in low-power sensor m=
esh networks.








=C2=A0






=C2=A0


On 3 =
July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) wrote:<=
/span>












First of all, I realise that I'm bringing thi=
s up late in the process, and maybe too late, since this would require a ch=
ange to the invariants.






=C2=A0






The connection IDs can be either 0 bytes or anyth=
ing between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not=
 possible.






For p2p applications, and for server deployments =
that are not doing connection ID based load balancing, it would be interest=
ing to use shorter connection IDs. One might imagine
 that a peer encodes the length of the connection ID into the first few bit=
s, and then starts using 1 byte connection IDs first, and successively move=
s to longer lengths only when handling more connections. A p2p host handlin=
g several thousand simultaneous
 connections (which will be enough for many p2p protocols) would never have=
 to use anything longer than 2 byte connection IDs.





=C2=A0






In the connection ID length field in the Long Hea=
der, we only have to 4 bit to encode a range of 19 values (we want 0 byte c=
onnection IDs, and we want to support 18 byte
 connection IDs), so *some* values have to be left out. However, leaving ou=
t 1, 2 and 3 seems a bit unfortunate, as there will be more use cases for t=
hese values than e.g. for 13, 14 and 15 bytes.


























--000000000000b72ab905710c8881--


From nobody Sun Jul 15 10:04:55 2018
Return-Path: 
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 9CC1A1294D0 for ; Sun, 15 Jul 2018 10:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 K6w0TRhzDhXC for ; Sun, 15 Jul 2018 10:04:50 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1064B130DFA for ; Sun, 15 Jul 2018 10:04:50 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 10:04:49 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.51,357,1526367600"; d="scan'208,217"; a="74967269"
Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga002.jf.intel.com with ESMTP; 15 Jul 2018 10:04:26 -0700
Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 15 Jul 2018 10:04:26 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX152.amr.corp.intel.com ([169.254.8.83]) with mapi id 14.03.0319.002; Sun, 15 Jul 2018 10:04:26 -0700
From: "Deval, Manasi" 
To: Marten Seemann 
CC: Ian Swett , IETF QUIC WG , =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= 
Subject: Re: Connection ID lengths 1, 2 and 3
Thread-Topic: Connection ID lengths 1, 2 and 3
Thread-Index: AQHUEsvAi91oX8DVaUqbcldKc5Rk06R97QgAgBGLlvCAAOSi4IAAh0AA//+rWH+AAHgzgP//jiJF
Date: Sun, 15 Jul 2018 17:04:25 +0000
Message-ID: <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>  <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4F5BCC2E4DD0403F954AFB79847E218Bintelcom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 17:04:53 -0000

--_000_4F5BCC2E4DD0403F954AFB79847E218Bintelcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

There is a 32bit version number that precedes the length field. Until we ha=
ve a thousand versions, we are always sending 3 extra bytes on the wire.

Thanks,
Manasi

On Jul 15, 2018, at 12:52 PM, Marten  > wrote:

I don't think we should reduce the number of sizes available. Sending bytes=
 on the wire is orders of magnitude more expensive than performing a simple=
 transformation to a parsed value. I'd prefer if we could discuss this sepa=
rately, since this is quite the opposite of what I was originally proposing=
.

To reiterate my argument, changing the invariants such that the values 1, 2=
 and 3 can be used would be a big benefit for p2p applications, since they =
would be able to use super-short connection IDs. Since this is a change tha=
t requires a change to the invariants, we need to make this decision very s=
oon, if we want to enable this use case of QUIC.

On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi > wrote:
I would still prefer if we can reduce the number of sizes supported.

Could a scheme where we support only 5 cids be used? Use a 3 bit size , shi=
ft left by 2 and not use the last 2 sizes of 24 and 28.


Thanks,
Manasi



On Jul 15, 2018, at 10:45 AM, Ian Swett > wrote:

If one uses existing fast crypto primitives to encode connection ID, then 1=
6 bytes is a natural size, and there was interest in having an extra byte f=
or metadata(key rotation/length signaling/etc).

Unfortunately, that leaves us with a gap somewhere, and a gap at the beginn=
ing seemed the most natural at the time.

On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi > wrote:
Another issue I noticed with the size of connection id was with regards to =
parsing the header field. The current steps are:

=95        Parse DCid length,

=95        Add 3,

=95        Parse DCid length

=95        Add 3,

=95        Read DCID

=95        Read SCID.

I really appreciate the fixed size length fields so we can know both destin=
ation and source Cid lengths in parallel. Implementing this in hardware has=
 the following challenges though:

a.      There are 12 unique length types for each of the CiDs. This means e=
ither more stages of serial processing, which would be slower. Or it means =
more logic for parallel processing.

b.      In addition to this, the arithmetic logic to add 3 is a little more=
 specialized than a logical operation, e..g.shift left.

Therefore, I would like to understand the basis for having 12 different len=
gths and if there is a chance to simplify this logic, we can have a 3 bit l=
ength and shift left 1, so we have lengths of 0,2,4=85 14. Would the loss o=
f longer CiD values from 15 to 18 be an issue?

Thanks,
Manasi

From: QUIC [mailto:quic-bounces@ietf.org] On =
Behalf Of Mikkel Fahn=F8e J=F8rgensen
Sent: Tuesday, July 03, 2018 6:06 AM
To: QUIC WG >; Marten Seemann >
Subject: Re: Connection ID lengths 1, 2 and 3

That is correct. Especially in low-power sensor mesh networks.



On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) wrote:
First of all, I realise that I'm bringing this up late in the process, and =
maybe too late, since this would require a change to the invariants.

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes=
 (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
For p2p applications, and for server deployments that are not doing connect=
ion ID based load balancing, it would be interesting to use shorter connect=
ion IDs. One might imagine that a peer encodes the length of the connection=
 ID into the first few bits, and then starts using 1 byte connection IDs fi=
rst, and successively moves to longer lengths only when handling more conne=
ctions. A p2p host handling several thousand simultaneous connections (whic=
h will be enough for many p2p protocols) would never have to use anything l=
onger than 2 byte connection IDs.

In the connection ID length field in the Long Header, we only have to 4 bit=
 to encode a range of 19 values (we want 0 byte connection IDs, and we want=
 to support 18 byte connection IDs), so *some* values have to be left out. =
However, leaving out 1, 2 and 3 seems a bit unfortunate, as there will be m=
ore use cases for these values than e.g. for 13, 14 and 15 bytes.

--_000_4F5BCC2E4DD0403F954AFB79847E218Bintelcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable






There is a 32bit version number that precedes the length field. Until we ha=
ve a thousand versions, we are always sending 3 extra bytes on the wire.&nb=
sp;




Thanks,


Manasi




On Jul 15, 2018, at 12:52 PM, Marten  <martenseemann@gmail.com> wrote:










I don't think we should reduce the number of sizes availab=
le. Sending bytes on the wire is orders of magnitude more expensive than pe=
rforming a simple transformation to a parsed value. I'd prefer if we could =
discuss this separately, since this
 is quite the opposite of what I was originally proposing.






To reiterate my argument, changing the invariants such that the values=
 1, 2 and 3 can be used would be a big benefit for p2p applications, since =
they would be able to use super-short connection IDs. Since this is a chang=
e that requires a change to the
 invariants, we need to make this decision very soon, if we want to enable =
this use case of QUIC.








On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi <manasi.deval@intel.com> wrote:





I would still prefer if we can reduce the number of sizes=
 supported. 






Could a scheme where we support only 5 cids be used? Use a 3 bit size =
, shift left by 2 and not use the last 2 sizes of 24 and 28.














Thanks,


Manasi

















On Jul 15, 2018, at 10:45 AM, Ian Swett <ianswett@google.com> wrote:










If one uses existing fast crypto primitives to encode conn=
ection ID, then 16 bytes is a natural size, and there was interest in havin=
g an extra byte for metadata(key rotation/length signaling/etc).






Unfortunately, that leaves us with a gap somewhere, and a gap at the b=
eginning seemed the most natural at the time.








On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi <manasi.deval@intel.com=
> wrote:










Another issue I noticed with the size=
 of connection id was with regards to parsing the header field. The current=
 steps are:


<=
u>=B7  &n=
bsp;    
Parse DCid length,



<=
u>=B7  &n=
bsp;    
Add 3,



<=
u>=B7  &n=
bsp;    
Parse DCid length<=
/span>


<=
u>=B7  &n=
bsp;    
Add 3,


<=
u>=B7  &n=
bsp;    
Read DCID

<=
u>=B7  &n=
bsp;    
Read SCID.<=
/p>

 


I really appreciate the fixed size le=
ngth fields so we can know both destination and source Cid lengths in paral=
lel. Implementing this in hardware has the following
 challenges though:


<=
u>a.     
There are 12 unique length types=
 for each of the CiDs. This means either more stages of serial processing, =
which would be slower. Or it means more logic
 for parallel processing. 


<=
u>b.     
In addition to this, the arithme=
tic logic to add 3 is a little more specialized than a logical operation, e=
..g.shift left.



 


Therefore, I would like to understand=
 the basis for having 12 different lengths and if there is a chance to simp=
lify this logic, we can have a 3 bit length and
 shift left 1, so we have lengths of 0,2,4=85 14. Would the loss of longer =
CiD values from 15 to 18 be an issue?



 


Thanks,


Manasi


 






From: QUIC [mailto:quic-bounces@ietf.org]
On Behalf Of Mikkel Fahn=F8e J=F8rgensen

Sent: Tuesday, July 03, 2018 6:06 AM

To: QUIC WG <q=
uic@ietf.org>; Marten Seemann <martenseemann@gmail.com>

Subject: Re: Connection ID lengths 1, 2 and 3





 




That is correct. Especially in low-power sensor m=
esh networks.








 






 


On 3 =
July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com)
 wrote:












First of all, I realise that I'm bringing this up=
 late in the process, and maybe too late, since this would require a change=
 to the invariants.






 






The connection IDs can be either 0 bytes or anyth=
ing between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not=
 possible.






For p2p applications, and for server deployments =
that are not doing connection ID based load balancing, it would be interest=
ing to use shorter connection IDs. One might imagine
 that a peer encodes the length of the connection ID into the first few bit=
s, and then starts using 1 byte connection IDs first, and successively move=
s to longer lengths only when handling more connections. A p2p host handlin=
g several thousand simultaneous
 connections (which will be enough for many p2p protocols) would never have=
 to use anything longer than 2 byte connection IDs.





 






In the connection ID length field in the Long Hea=
der, we only have to 4 bit to encode a range of 19 values (we want 0 byte c=
onnection IDs, and we want to support 18 byte
 connection IDs), so *some* values have to be left out. However, leaving ou=
t 1, 2 and 3 seems a bit unfortunate, as there will be more use cases for t=
hese values than e.g. for 13, 14 and 15 bytes.










































--_000_4F5BCC2E4DD0403F954AFB79847E218Bintelcom_--


From nobody Sun Jul 15 10:08:19 2018
Return-Path: 
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 1A6A51277D2 for ; Sun, 15 Jul 2018 10:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 0r1Uas8uxLfW for ; Sun, 15 Jul 2018 10:08:15 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 21FF4130DFA for ; Sun, 15 Jul 2018 10:08:15 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id h2-v6so15849586itj.1 for ; Sun, 15 Jul 2018 10:08:15 -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=aU1VFcoifcJCMkJr0743IATkDt94ilpbxM4NDDThhDI=; b=BWj/La/n9zYFMH+9dvNvRrZdunpo8vV/FmsJn/ydDmVl0drK+2IGCmrC9Pqa6y52bD KeAVmA0JFoIioS/b3lnmQvw6iQUEGYZcd2KRcgs8zcrBeHH6TPe9YUl3O87DM1TR7ky4 kPcOCrCT1gJwnkVooaFcn0caqbB3AkP5wXnHv6i+M37eGQ8yNALGIhUx5jnwxLfM8cf8 XtypdsTLoZqqPezX7EuEpf8BeNgP1NP3If1S5DXahsG2Lid+bzPuGJ0hIz6vrcr14X29 8K+SR8u7cVs/oIjQ+yP5pibu/wjiU1pGIezRL+3cTGIvC5Xxc42y6BVpC6AI3LyOSFSu AjhQ==
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=aU1VFcoifcJCMkJr0743IATkDt94ilpbxM4NDDThhDI=; b=dSdpivdyBWuTDwh5dvtj3/TpNcMC274h8d+dF1hUufUyHLA9iGedK8hNa5+NFrhK6a ipIfKrCHBsVVTloRUc+W0IgMBppTpKzZSX2XeKtKreZL5QEDCvEzCufsFzAP3przDsiM GsNzEHTPtJngb5OAbD58DNdNAoiUJ+2kN438kXIKV4ImRYhJKgyTFvGCJPCYodPJM5Qo ol/4ui9X+0UeAzH+UJrCE6K4WcWiOJDb+BPjp3LpzD1Bu+BHFmLNetGlm0iqWckd8g+X co61McDZ8JJNJ2Mp+GnXTgiS52a98hejs4M6e3YD6iMfAsdXKlFsvtp42mHI04VZdqxI MWtA==
X-Gm-Message-State: AOUpUlFMC6ZNJA3vG2VymgbZeqQx9z7tbkZVCpa5Alp4KA5nFS2YrGyG ac8xxvV46AUo1/Mdz+a61hEjVGiR1VdCBOWpI6M=
X-Google-Smtp-Source: AAOMgpfAIpJu3CBMSgxbVO6VjpuNMEN21xEHVcy1nA6uiHbufviv7UY3LDK2lNwdYvsgpsOQ7RgcNv4tH1ueCGDRkAk=
X-Received: by 2002:a24:534c:: with SMTP id n73-v6mr10641008itb.25.1531674494553;  Sun, 15 Jul 2018 10:08:14 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 15 Jul 2018 13:08:13 -0400
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>  <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>  <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sun, 15 Jul 2018 13:08:13 -0400
Message-ID: 
Subject: Re: Connection ID lengths 1, 2 and 3
To: "Deval, Manasi" , Marten Seemann 
Cc: Ian Swett , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="00000000000028d1d505710cc2e2"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 17:08:17 -0000

--00000000000028d1d505710cc2e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

version is only during handshake, CID is on all packets



On 15 July 2018 at 19.04.49, Deval, Manasi (manasi.deval@intel.com) wrote:

There is a 32bit version number that precedes the length field. Until we
have a thousand versions, we are always sending 3 extra bytes on the wire.

Thanks,
Manasi

On Jul 15, 2018, at 12:52 PM, Marten   wrote:

I don't think we should reduce the number of sizes available. Sending bytes
on the wire is orders of magnitude more expensive than performing a simple
transformation to a parsed value. I'd prefer if we could discuss this
separately, since this is quite the opposite of what I was originally
proposing.

To reiterate my argument, changing the invariants such that the values 1, 2
and 3 can be used would be a big benefit for p2p applications, since they
would be able to use super-short connection IDs. Since this is a change
that requires a change to the invariants, we need to make this decision
very soon, if we want to enable this use case of QUIC.

On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi 
wrote:

> I would still prefer if we can reduce the number of sizes supported.
>
> Could a scheme where we support only 5 cids be used? Use a 3 bit size ,
> shift left by 2 and not use the last 2 sizes of 24 and 28.
>
>
> Thanks,
> Manasi
>
>
>
> On Jul 15, 2018, at 10:45 AM, Ian Swett  wrote:
>
> If one uses existing fast crypto primitives to encode connection ID, then
> 16 bytes is a natural size, and there was interest in having an extra byt=
e
> for metadata(key rotation/length signaling/etc).
>
> Unfortunately, that leaves us with a gap somewhere, and a gap at the
> beginning seemed the most natural at the time.
>
> On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi 
> wrote:
>
>> Another issue I noticed with the size of connection id was with regards
>> to parsing the header field. The current steps are:
>>
>> =C2=B7        Parse DCid length,
>>
>> =C2=B7        Add 3,
>>
>> =C2=B7        Parse DCid length
>>
>> =C2=B7        Add 3,
>>
>> =C2=B7        Read DCID
>>
>> =C2=B7        Read SCID.
>>
>>
>>
>> I really appreciate the fixed size length fields so we can know both
>> destination and source Cid lengths in parallel. Implementing this in
>> hardware has the following challenges though:
>>
>> a.      There are 12 unique length types for each of the CiDs. This
>> means either more stages of serial processing, which would be slower. Or=
 it
>> means more logic for parallel processing.
>>
>> b.      In addition to this, the arithmetic logic to add 3 is a little
>> more specialized than a logical operation, e..g.shift left.
>>
>>
>>
>> Therefore, I would like to understand the basis for having 12 different
>> lengths and if there is a chance to simplify this logic, we can have a 3
>> bit length and shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. Wo=
uld the
>> loss of longer CiD values from 15 to 18 be an issue?
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of* Mikkel Fahn=
=C3=B8e
>> J=C3=B8rgensen
>> *Sent:* Tuesday, July 03, 2018 6:06 AM
>> *To:* QUIC WG ; Marten Seemann 
>> *Subject:* Re: Connection ID lengths 1, 2 and 3
>>
>>
>>
>> That is correct. Especially in low-power sensor mesh networks.
>>
>>
>>
>>
>>
>> On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com)
>> wrote:
>>
>> First of all, I realise that I'm bringing this up late in the process,
>> and maybe too late, since this would require a change to the invariants.
>>
>>
>>
>> The connection IDs can be either 0 bytes or anything between 4 and 18
>> bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
>>
>> For p2p applications, and for server deployments that are not doing
>> connection ID based load balancing, it would be interesting to use short=
er
>> connection IDs. One might imagine that a peer encodes the length of the
>> connection ID into the first few bits, and then starts using 1 byte
>> connection IDs first, and successively moves to longer lengths only when
>> handling more connections. A p2p host handling several thousand
>> simultaneous connections (which will be enough for many p2p protocols)
>> would never have to use anything longer than 2 byte connection IDs.
>>
>>
>>
>> In the connection ID length field in the Long Header, we only have to 4
>> bit to encode a range of 19 values (we want 0 byte connection IDs, and w=
e
>> want to support 18 byte connection IDs), so *some* values have to be lef=
t
>> out. However, leaving out 1, 2 and 3 seems a bit unfortunate, as there w=
ill
>> be more use cases for these values than e.g. for 13, 14 and 15 bytes.
>>
>>

--00000000000028d1d505710cc2e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
version is only duri=
ng handshake, CID is on all packets 


 
On 15 July 2=
018 at 19.04.49, Deval, Manasi (m=
anasi.deval@intel.com) wrote:
 







There is a 32bit version number that precedes the length field.
Until we have a thousand versions, we are always sending 3 extra
bytes on the wire.=C2=A0




Thanks,


Manasi




On Jul 15, 2018, at 12:52 PM, Marten =C2=A0<martenseemann@gmail.com>
wrote:








I don't think we should reduce the number of sizes
available. Sending bytes on the wire is orders of magnitude more
expensive than performing a simple transformation to a parsed
value. I'd prefer if we could discuss this separately, since this
is quite the opposite of what I was originally proposing.




To reiterate my argument, changing the invariants such that
the values 1, 2 and 3 can be used would be a big benefit for p2p
applications, since they would be able to use super-short
connection IDs. Since this is a change that requires a change to
the invariants, we need to make this decision very soon, if we want
to enable this use case of QUIC.








On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi
<manasi.deval@intel.com>=
;
wrote:




I would still prefer if we can reduce the number of
sizes supported.=C2=A0




Could a scheme where we support only 5 cids be used? Use a 3
bit size , shift left by 2 and not use the last 2 sizes of 24 and
28.










Thanks,


Manasi

















On Jul 15, 2018, at 10:45 AM, Ian Swett <ianswett@google.com> wrote:








If one uses existing fast crypto primitives to
encode connection ID, then 16 bytes is a natural size, and there
was interest in having an extra byte for metadata(key
rotation/length signaling/etc).




Unfortunately, that leaves us with a gap somewhere, and a gap
at the beginning seemed the most natural at the time.








On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi
<manasi.deva=
l@intel.com> wrote:









Another issue I noticed with the size of connection id was with
regards to parsing the header field. The current steps
are:



=C2=
=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0

Parse DCid length, 



=C2=
=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0

Add 3, 



=C2=
=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0

Parse DCid length



=C2=
=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0

Add 3,



=C2=
=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0

Read DCID



=C2=
=B7=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0

Read SCID.



=C2=A0



I really appreciate the fixed size length fields so we can know
both destination and source Cid lengths in parallel. Implementing
this in hardware has the following challenges though:




a.=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0

There are 12 unique length types for each of the CiDs. This means
either more stages of serial processing, which would be slower. Or
it means more logic for parallel processing. 




b.=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0

In addition to this, the arithmetic logic to add 3 is a little more
specialized than a logical operation, e..g.shift left. 



=C2=A0



Therefore, I would like to understand the basis for having 12
different lengths and if there is a chance to simplify this logic,
we can have a 3 bit length and shift left 1, so we have lengths of
0,2,4=E2=80=A6 14. Would the loss of longer CiD values from 15 to 18 be an
issue? 



=C2=A0



Thanks,



Manasi



=C2=A0







From:
QUIC
[mailto:quic-bou=
nces@ietf.org] On Behalf Of Mikkel
Fahn=C3=B8e J=C3=B8rgensen

Sent: Tuesday, July 03, 2018 6:06 AM

To: QUIC WG <q=
uic@ietf.org>; Marten Seemann <martenseemann@gmail.com>

Subject: Re: Connection ID lengths 1, 2 and 3






=C2=A0




That
is correct. Especially in low-power sensor mesh
networks.








=C2=A0






=C2=A0



On
3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com) wrote:












First
of all, I realise that I'm bringing this up late in the process,
and maybe too late, since this would require a change to the
invariants.






=C2=A0






The
connection IDs can be either 0 bytes or anything between 4 and 18
bytes (inclusive). Lengths of 1, 2 and 3 bytes are not
possible.






For
p2p applications, and for server deployments that are not doing
connection ID based load balancing, it would be interesting to use
shorter connection IDs. One might imagine that a peer encodes the
length of the connection ID into the first few bits, and then
starts using 1 byte connection IDs first, and successively moves to
longer lengths only when handling more connections. A p2p host
handling several thousand simultaneous connections (which will be
enough for many p2p protocols) would never have to use anything
longer than 2 byte connection IDs.






=C2=A0






In
the connection ID length field in the Long Header, we only have to
4 bit to encode a range of 19 values (we want 0 byte connection
IDs, and we want to support 18 byte connection IDs), so *some*
values have to be left out. However, leaving out 1, 2 and 3 seems a
bit unfortunate, as there will be more use cases for these values
than e.g. for 13, 14 and 15 bytes.












































--00000000000028d1d505710cc2e2--


From nobody Sun Jul 15 10:15:21 2018
Return-Path: 
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 8B37B130FAE for ; Sun, 15 Jul 2018 10:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.751
X-Spam-Level: 
X-Spam-Status: No, score=-0.751 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=oV9br0Pv; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=AUsjG4g2
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 xxG9pHSVJWS9 for ; Sun, 15 Jul 2018 10:15:01 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1313130E14 for ; Sun, 15 Jul 2018 10:15:01 -0700 (PDT)
Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6FHEPbi028379; Sun, 15 Jul 2018 10:14:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=uBGsIHJtGfB4K0KJZsuKAuco7leR9kXgFF+X3Fmm6n0=; b=oV9br0Pvf4VHebVXfNrNSWtW1PzumLMcRxLk+mXSK+9O42p0qKH2yXWGzPvghbYblxII 4whjoN3zWa4JxhR0TVOkGWxshFkgoonSH5N0P86e0jws9W9E3XS8mbcH/IdQ8KB9q7Ip E1ILn393cJPvn+cKcExsH+6YqHl8rF3Bf2s= 
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2k89q401xs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Jul 2018 10:14:58 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 15 Jul 2018 13:14:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uBGsIHJtGfB4K0KJZsuKAuco7leR9kXgFF+X3Fmm6n0=; b=AUsjG4g2T0/nkN8Dbis0vhFyuyS6xvxvlrShS1+qED9EdS/rGdGk35CfawFvPtmk4QXwHK4rDO+PvITtjDwSQGoySJqCnQKi2ZU4Vs9e1DHLWefFo9t/n5pNN5mBBu29uc2iOC7w3+dhrpnoDRPR4PAUy76QhkxsVVohuApJ3ME=
Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1888.namprd15.prod.outlook.com (10.174.100.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.21; Sun, 15 Jul 2018 17:14:51 +0000
Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::80:141b:7fe8:2596]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::80:141b:7fe8:2596%9]) with mapi id 15.20.0952.021; Sun, 15 Jul 2018 17:14:51 +0000
From: Subodh Iyengar 
To: "Deval, Manasi" , =?Windows-1252?Q?=27Mikkel_Fahn=F8e_J=F8rgensen=27?= , Eric Rescorla , Kazuho Oku 
CC: Jana Iyengar , Praveen Balasubramanian , Ian Swett , Marten Seemann , IETF QUIC WG , Martin Thomson 
Subject: Re: Proposal to replace ACK block count with ACK length
Thread-Topic: Proposal to replace ACK block count with ACK length
Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFON0uAAA2Oe4AABJAbAAC4BBWAAAAXlWAADdw6gAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAD4/6gABeMHaAAAAl2oAABAimgAALQ2CAAF8rsoAACaeCgAATwqWAAAPViwAAApbzgARqKuIAABx3OIs=
Date: Sun, 15 Jul 2018 17:14:51 +0000
Message-ID: 
References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri>  <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com>            <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com>    , <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com>
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [199.201.64.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1888; 7:mXUqJVh/6Pb9HYajj5eCH9XKiytnV1+6r+ouUx0FhQU1vC+6pu1Bq7IL4ZXm7bfyY+jGZfmN5Cf1zaOsU2C41j+81j/Ch2MD0USnnBAna7GaASh4838nN2zusmtxXLcnjSyBN3NSfMPVRw06VgZilXAT3lbMURrlENI6GA1U5ZgQmjyzHxVWjkWVOM1vfn49u0euTP93qiYvEfx1DW6nKUSsJ+ru3p3Qko8qTXqRriMzqyB5wjShjAE5toZ6Yph8; 20:wXV+4mb4orcvA7hPCYh3LR4+KfItbHxSnJ0rGgSWui5pB22DRgx4dE7ohF4ju2AaTv1N9793iuZw0oKeWdqe/CKmZbg8i8ObKArWU/C+rALsk8cfHRZIqbW+8Z7xoxTpDwcRT6h9bxeqDbNiTw1pF6PrNRI1fFthpP0eqlMeDIc=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 52a7a058-7597-4fdb-1dc0-08d5ea767a10
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1888; 
x-ms-traffictypediagnostic: MWHPR15MB1888:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(10436049006162)(89211679590171)(192374486261705)(85827821059158)(788757137089)(211936372134217)(100405760836317)(153496737603132);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1888; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1888; 
x-forefront-prvs: 07349BFAD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(136003)(376002)(51444003)(53754006)(78114003)(189003)(199004)(26005)(54906003)(110136005)(561944003)(39060400002)(106356001)(5250100002)(33656002)(4326008)(6116002)(606006)(3846002)(25786009)(478600001)(45080400002)(74316002)(7736002)(6506007)(99286004)(256004)(97736004)(966005)(102836004)(53546011)(19627235002)(2906002)(186003)(14444005)(316002)(81166006)(53936002)(66066001)(236005)(105586002)(76176011)(6436002)(7696005)(2900100001)(68736007)(93886005)(6246003)(6606003)(229853002)(476003)(11346002)(5660300001)(486006)(446003)(54896002)(16200700003)(9686003)(55016002)(6306002)(8936002)(14454004)(7416002)(86362001)(19627405001)(53946003)(81156014)(8676002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1888; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: /YOIOUH2hhScoQUS7Vjwii6NdANumirL+4Aow+D7pvftGPv1HEf/CpEHf5lcORdeRePqLhavpGW9PMTByevBKCeFZIJdZqxriQ3f8ETR3yW8Z9SnlJNV9O4lIOACOG4tQzq49KmkEstH8pJUk48HCr3MOP9C1oPO+H4DmjstUvNcGLp5JwA63hFOoYErxqS8b7FtUtFxMWO4gC/0QdMlPobL7uqT+GhQFqVCwcTgedU2bAt4J/dvS7VtbWU+96F6BV3fA9MDXlMJ53y0vPiwjx4U/LthYgp2spShWpBFdX5dhz2REz8dv7O9fKlGkrArh32H7GQs797RW0N82ROy/fqTrBx68Srk88Ap4Ymi9Pg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB182169F94173C287298636AAB65E0MWHPR15MB1821namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 52a7a058-7597-4fdb-1dc0-08d5ea767a10
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2018 17:14:51.5991 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1888
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-15_06:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 17:15:19 -0000

--_000_MWHPR15MB182169F94173C287298636AAB65E0MWHPR15MB1821namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Manasi,

Doesn't the segmentation make more sense for stream frames than ACK frames?=
 ACK frames are not sent very often and at least in production what we've s=
een is that most of the time ACKs naturally end up getting sent in their ow=
n pure ACK packets.

Not arguing for or against the length prefix design, but trying to understa=
nd why having a length prefix in the ACK frame helps segmentation for strea=
m frames even on the recv side.


Subodh

________________________________
From: QUIC  on behalf of Deval, Manasi 
Sent: Saturday, July 14, 2018 8:35:14 PM
To: 'Mikkel Fahn=F8e J=F8rgensen'; Eric Rescorla; Kazuho Oku
Cc: Jana Iyengar; Praveen Balasubramanian; Ian Swett; Marten Seemann; IETF =
QUIC WG; Martin Thomson
Subject: RE: Proposal to replace ACK block count with ACK length


Hi All,



I would like to revisit this discussion in the context of distributed proce=
ssing. The distributed processing doesn=92t only apply to multi-threading b=
ut also to layered processing.



One example of layered processing is segmentation. The current Chromium imp=
lementation currently creates the segments and passes them as a bunch into =
the Linux kernel. There is a GSO patch that would chop at the segment bound=
ary and encapsulate in UDP headers. We can further improve performance by p=
lugging in a smarter segmentation algorithm such that the segment processin=
g can account for type of frame, its size and make intelligent boundary and=
 padding decisions at a lower layer or in an offload. To this end, the algo=
rithm needs to identify the size of each of the frames. Having an ACK lengt=
h that can be determined in a single read is much more efficient than havin=
g to do a series of reads.



Thanks,

Manasi



From: Mikkel Fahn=F8e J=F8rgensen [mailto:mikkelfj@gmail.com]
Sent: Friday, June 22, 2018 9:15 AM
To: Eric Rescorla ; Kazuho Oku 
Cc: Jana Iyengar ; IETF QUIC WG ; Deval,=
 Manasi ; Marten Seemann ;=
 Martin Thomson ; Ian Swett =
; Praveen Balasubramanian 
Subject: Re: Proposal to replace ACK block count with ACK length



Another option is to write out frames as is without length except as needed=
 for varints. When a packet is nearly done, a run-length encoded frame inde=
x is placed in the packet tail. It could also include the frame types. A re=
ader can now directly find or skip ACK frames and the writer does not have =
to compute lengths before writing. Of course, the reader needs to be able t=
o locate the index at the tail which can be tricky with coalesced packets, =
but not impossible. Isn=92t this largely how zip-files work?



Mikkel



On 22 June 2018 at 17.00.52, Mikkel Fahn=F8e J=F8rgensen (mikkelfj@gmail.co=
m) wrote:

As I said earlier, I also favour a length prefix. But, Ian does have a poin=
t:



Writing data is generally more expensive than reading data. Especially if y=
ou have to traverse long data structures to find the length before you can =
start writing and/or you may have to conservatively reserve extra space for=
 a length field.



So before deciding one way or the other, the cost of writing needs to be we=
ll understood, also in scenarios with large MTU=92s.



In the flatbuffers space that I=92m involved with, streaming has turned to =
be an issue because data cannot be transmitted in parts without index data =
on a separate channel to recombined fragments. A simple, but non-standard, =
change in the format would fix this. JSON and CoAP allows streaming, but ma=
ny other formats do not, including later versions of protocol buffers, as I=
 understand.



An odd consequence of making both read and write efficient is that length b=
etter work better if stored at the end and packets read backwards. This req=
uires a single total length prefix but this is stored in the datagram heade=
r. This is probably too odd-ball, but still a consideration worth noting.



The second best alternative may therefore be to allow writes to be fast and=
 reads to be decent.



Yet, I still like length prefixes if they could be made write efficient bec=
ause high performance low-latency processes care zero about ACK and can con=
sume a packet directly while a background process handles all the latency i=
nsensitive ACK and retransmission logic.



The question is also, where is the pressure: an IoT aggregator might be mas=
sively read intensive while a web cache would be very write intensive.





Kind Regards,

Mikkel Fahn=F8e J=F8rgensen



On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote:

It seems like there are two questions at hand here:



1. Would it be architecturally better to have frames have a consistent self=
-contained

representation?

2. Is it enough better that we should do so now.



I agree with Kazuho that (a) we don't have that representation now and (b) =
it would

be a better design to do so. I'm perhaps somewhat more positive on (2) than=
 he

is. I don't think it's critically important that we make the change, but if=
 we were

to hold a consensus call, I think I would be in favor. I'd certainly be int=
erested

in looking at a proposal if someone else were to make one.



-Ekr







On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku > wrote:

2018-06-22 8:08 GMT+09:00 Deval, Manasi >:
> I feel that the requirement to have every value valid is somewhat academi=
c.

I think that Marten is correct in pointing out that making the ACK
frame self-containing (by having a field that represents the number of
octets being consumed by the frame) would be an exception from the
design pattern we have.

Look at STREAM frame. The field is not self-contained. Instead, it has
a Length field for the Stream Data, which is a leaf. The same goes for
NEW_CONNECTION_ID frame (that has the length field for Connection ID
field (which is also a leaf)), CONNECTION_CLOSE (length field for
Reason Phase).

I agree with Marten, Mikkel (and possibly others as well) that having
consistency is important.

Therefore, I agree with Mikkel that we should consider making every
frame self-contained or keeping every frame as-is (i.e. not
self-contained).

FWIW, as described in the latter half of
https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it
is possible to make every frame self-contained *and* also make ACK
frames smaller than the current draft. Making every frame
self-contained gives us the possibility to send new extension frames
without negotiation.

I do not think that I would push for making every frame self-contained
by myself (because I do not think it meets the high bar to have a
change at such a late moment of standardization), but as stated, my
preference goes to seeing every frame made self-contained or none of
them made as such.

> The length value provides much more value than the block count and the fa=
ct
> that certain values can never be achieved is an inherent property of the
> length.
>
>
>
> One interesting observation is that this property is not limited to lengt=
h.
> One can even make a similar argument about ACK block count. The maximum
> number of ACK blocks that can be defined will not always have a meaningfu=
l
> value. In out examples, 0,1,2,3 are all valid. If I set the value of ACK
> block count to have lower two bits to be 11, the maximum value is of ACK
> blocks is =96 4611686018427387903. This is the same value of largest
> acknowledged so if the ACK block count was set to this value, it would st=
ill
> be meaningless.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Tuesday, June 19, 2018 6:44 PM
> To: Deval, Manasi =
>
> Cc: Ian Swett >; Kazuho O=
ku >; Eric
> Rescorla >; Jana Iyengar >; Praveen
> Balasubramanian >; IETF Q=
UIC WG >; Martin
> Thomson >
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Hi Manasi,
>
>
>
>> The risk of disagreement between ack blocks and ack block count is same =
as
>> the risk of disagreement between ack blocks and ack length. Either way t=
his
>> needs to be counted up while creating the ACK and counted down while par=
sing
>> it. The possibility of error is the same. Getting the ack block count wr=
ong
>> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
> I disagree. Let's take an example of an ACK frame with one ACK range, tha=
t
> needs a 2 byte varint to represent the First ACK Block and another 2 byte
> varint to represent the Gap.
>
> With your proposal:
>
> The values 0 and 1 are invalid, since the length fields itself is include=
d
> in the length.
> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - 1 =
are
> invalid, since the length needs to include the Largest Acknowledged and t=
he
> Ack Delay.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the first
> valid value, and correspond to an ACK frame with no blocks.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, si=
nce
> it would cut the varint for the First ACK Block
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, si=
nce
> it would cut the frame after the First ACK Block (but every block must be
> followed by a gap length)
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, si=
nce
> it would cut the varint for the Gap
> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is va=
lid
>
> There are *a lot* of invalid values that you can encode into the ACK leng=
th
> field. More importantly, *none* of these error cases exists with the curr=
ent
> frame format.
>
> The *only* error case that can occur with our current format is that the
> packet is too short for the number of ACK blocks that are supposed to
> contained in the frame. This can occur with your proposal as well (in
> addition to the error cases listed above).
>
>
>
> My concern is not that it's impossible or even particularly hard to catch
> these errors, but I dislike the property that some (in fact, most) encoda=
ble
> values are invalid.
>
>
>
> Best,
>
> Marten
>
>
>
>
>
> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi >
> wrote:
>
> Hi Ian,
>
>
>
> Here is another attempt to solve the objections you raised:
>
>
>
>>I'm not a fan of this proposal, because I think it is impractical to drop
>> the number of ack blocks, because with the ECN proposal it becomes
>> impractically complex to parse.
>
> Is there a reason the proposal from Christian does not solve this problem=
?
>
>
>
>>If we don't remove the number of ack blocks, then the ack frame is larger=
,
>> but I don't think the extra size field is useful for most implementation=
s.
>> Also, it means the length can disagree with the actual length, which add
>> complexity and the possibility of writing error-prone code.  The idea of
>> someone offloading ack processing and then proceeding to trust the lengt=
h
>> seems like someone could get wrong and cause some concerning issues.
>
> The risk of disagreement between ack blocks and ack block count is same a=
s
> the risk of disagreement between ack blocks and ack length. Either way th=
is
> needs to be counted up while creating the ACK and counted down while pars=
ing
> it. The possibility of error is the same. Getting the ack block count wro=
ng
> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
>>My experience is multithreaded packet processing is more cost and work th=
an
>> it's worth.  Sure you can't fill a 100G NIC with one connection, but tha=
t
>> seems like an academic problem, not one for workloads I've seen.  Typica=
lly
>> the extra cost of multithreading outweighs its value.
>
> The value is two fold =96 pre-processing and multi-threading. If we
> pre-process the received packets such that ACKs and streams can be
> coalesced, the receive side can indicate a large chunk of information tho=
ugh
> the kernel, reducing the cost of system call and protocol overhead. This =
is
> the same concept as UDP segmentation taken a step further on receive side=
.
> After this chunk is indicated into the QUIC protocol, the protocol may
> process stream and ACK in parallel. While folks may or may not utilize th=
is,
> there is an advantage here.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Ian Swett [mailto:ianswett@google.com]
> Sent: Tuesday, June 19, 2018 11:26 AM
> To: Deval, Manasi =
>
> Cc: Marten Seemann >; Kazuho Oku
> >; Eric Rescorla >; Jana Iyengar
> >; Praveen Balasubramanian =
>; IETF
> QUIC WG >; Martin Thomson >
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> I'm still not interested in this change, for the reasons I stated above.
>
>
>
> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi >
> wrote:
>
> Hi All,
>
>
>
> Do we have agreement here to create a new PR?
>
>
>
> Thanks,
>
> Manasi
>
>
>
> From: Deval, Manasi
> Sent: Sunday, June 17, 2018 2:25 PM
> To: Marten Seemann >; Kazuho Oku
> >
> Cc: Ian Swett >; Eric Rescorla
> >; Jana Iyengar >; Praveen Balasubramanian
> >; IETF QUIC WG >; Martin Thomson
> >
> Subject: RE: Proposal to replace ACK block count with ACK length
>
>
>
> Hi All,
>
>
>
> I have made a list of objections to the proposal and the solutions to tho=
se
> objections discussed on this thread.
>
>
>
> a.      Co-existence of length field with ECN field and ACK blocks.
>
>
>
> Christian suggested to move the ECN fields to precede the ACK blocks. Thi=
s
> is an elegant solution. Parsing entire list of ACK blocks to review ECN b=
its
> would have been annoying, even though it can work.
>
>
>
> b.      There are two cases to be parsed =96 entire ACK and parse ACK to
> identify length. There are some reservations when ACK parsing gets harder
> for the case where the entire header needs to be parsed.
>
>
>
> Agreement from several folks here. In the original ACK defined in draft 1=
2
> of the slide, one would count down number of ACK blocks to get to the end=
 of
> the packet. In the proposal I made, one would count down the length to
> identify the end of the packet. The logic is very similar in cycle count =
and
> complexity. Several folks also commented to this effect.
>
>
>
> c.      Multi-threaded packet processing
>
>
>
> I would expect that there are 10s of 1000s of connections in use at any t=
ime
> for a server with a high speed link. Multi-threading to handle each of th=
ese
> flows / connections in parallel is necessity to be able to support large
> number of connections on a high speed link. Tx segmentation, Rx coalescin=
g
> are well known strategies to reduce the processing cost. In initial stage=
s,
> code is often written as a single-threaded and then re-factored to
> parallelize cycle intensive operations. In order to allow this protocol t=
o
> scale in future, I would suggest we do not preclude this case.
>
>
>
> d.      Increase in ACK size by 1 byte.
>
>
>
> I do not see this as a serious issue but if folks but we can consider mak=
ing
> this a varint, if others have strong feelings about it. It=92s a trade-of=
f : 2
> reads to save 1 byte.
>
>
>
> e.      Every encodable value should be valid
>
> Not every length will be valid. This is inherent to lengths. This same is=
sue
> ails the =91payload length=92 in QUIC header. Not only does the issue exi=
st for
> small values, it also applies to large values since data stream will be s=
ent
> after crypto negotiation.  E.g.  - how does one craft a payload with 62 b=
it
> payload length in a large header?
>
>
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Sunday, June 17, 2018 6:59 AM
> To: Kazuho Oku >
> Cc: Ian Swett >; Eric Rescorla
> >; Jana Iyengar >; Praveen Balasubramanian
> >; IETF QUIC WG >; Martin Thomson
> >; Deval, Manas=
i >
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Maybe it's specific to Go, but I'm using a single io.Reader for the whole
> packet, so as long as the packet payload is long enough, the varint parsi=
ng
> will not fail.
>
> I don't think that specifics of programming languages matter here though,
> and I'm sure both frame formats can be reasonably implemented in C as wel=
l
> as in Go. The reasons I'm opposed to Manasi's proposal are that it moves =
us
> away from the principle that only reasonable values should be encodable, =
and
> that it increases the size of the ACK frame, for the questionable benefit=
 of
> being able to parallelise the frame parser.
>
>
>
> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku > wrote:
>
> 2018-06-17 22:36 GMT+09:00 Marten Seemann >:
>> At least for my implementation, parsing doesn't become easier, it become=
s
>> more complex with this proposal. My varint-parser always consumes as man=
y
>> bytes as the varint requires, so after parsing a varint, I'd have to
>> introduce an additional check that this didn't overflow the ACK length
>> (e.g.
>> consider that I parsed the ACK frame so far that only 2 bytes are
>> remaining
>> according to ACK length field, but the next varint is 4 bytes long).
>
> Isn't your varint parser checking that it has not (or will not) run
> across the end of the packet payload for every ACK block it parses?
> I'd assume that you would be doing that, because I think that is
> necessary to avoid buffer overrun.
>
> What I am saying that that check could be converted to a overrun check
> against the end of the "frame payload", and that checking the
> remaining block count becomes unnecessary, in case we replace ACK
> Block Count with ACK Frame Length.
>
>>
>> In general, we've been moving the wire image towards making every
>> encodable
>> value valid. This proposal moves us away from that principle:
>> * some small values are always invalid (the length can never be between =
0
>> and 3)
>> * a lot of intermediate values are invalid (if the boundary falls inside=
 a
>> varint, as described above)
>> Both these cases can't occur with the current ACK frame format..
>>
>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku > wrote:
>>>
>>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>>> >:
>>> > I'm not a fan of this proposal, because I think it is impractical to
>>> > drop
>>> > the number of ack blocks, because with the ECN proposal it becomes
>>> > impractically complex to parse.
>>>
>>> For the ECN proposal, as Christian has suggested, we can move the ECN
>>> counters before the ACK blocks. Then, it would not be complex to
>>> parse.
>>>
>>> And my view is that parsing becomes easier if we replace ACK Block
>>> Count with ACK Frame Length.
>>>
>>> Now, with ACK Block Count, we need to check the remaining number of
>>> blocks and the remaining space in the packet payload for every block
>>> that we parse. Failing to check either leads to a bug or a security
>>> issue.
>>>
>>> If we switch to ACK Frame Length, we need to only check the remaining
>>> space in the frame.
>>>
>>> I think that this is the biggest benefit of replacing ACK Block Count
>>> with ACK Frame Length. OTOH the downside is that you need extra one to
>>> two bits (one if the size of block / gap is expected to be below 65,
>>> two if they are expected to be above that) for encoding ACK Frame
>>> Length compared to ACK Block Count.
>>>
>>>
>>>
>>> Having said that, I honestly wonder if all the frames could have it's
>>> length being encoded (either explicitly or either as a signal that
>>> says "to the end of the packet"). Consider something like below:
>>>
>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) |
>>>  or
>>> |1| frame-type (7) | frame-payload (*) |
>>>
>>> When MSB of the first octet set to zero, the length of the frame
>>> payload is designated by the varint that immediately follows the frame
>>> type.
>>> When MSB of the first octet set to one, the length of the frame
>>> payload spans to the end of the packet.
>>>
>>> In this encoding, we can always omit the Length field of a STREAM
>>> frame. So the overhead for carrying stream data will be indifferent in
>>> practice.
>>>
>>> For the ACK frame, we can omit the ACK Block Count field. And the
>>> overhead will be one to two bits if the ACK frame is sent in the
>>> middle of the packet (thereby using the encoding with explicit frame
>>> payload length), or one octet or more shorter if ACK is the last frame
>>> of the packet.
>>>
>>> We are likely to see increase of overhead for most of the other types
>>> of frames, but I do not think that would be an issue considering that
>>> they will be far seldom seen compared to STREAMs and ACKs.
>>>
>>> To summarize, my anticipation is that we can make all the frames
>>> self-contained (i.e. the length can be determined without the
>>> knowledge of how each frame is encoded) without any overhead, if we
>>> agree on making the frame type space 1 bit smaller.
>>>
>>> Finally, the biggest benefit of using a self-contained encoding of
>>> frames is that we would have the ability to introduce new optional
>>> frames without negotiation. By making the frames self-contained, QUIC
>>> endpoints will have the freedom of ignoring the frames that they do
>>> not understand.
>>>
>>> Being able to send QUIC frames defined in extensions without
>>> negotiating using Transport Parameters will be a win in both terms of
>>> security (because clients' TP is sent in clear) and flexibility
>>> (because we will be possible to send the extensions before we figure
>>> out whether the peer supports that extension).
>>>
>>> > If we don't remove the number of ack blocks, then the ack frame is
>>> > larger,
>>> > but I don't think the extra size field is useful for most
>>> > implementations.
>>> > Also, it means the length can disagree with the actual length, which
>>> > add
>>> > complexity and the possibility of writing error-prone code.  The idea
>>> > of
>>> > someone offloading ack processing and then proceeding to trust the
>>> > length
>>> > seems like someone could get wrong and cause some concerning issues.
>>> >
>>> > My experience is multithreaded packet processing is more cost and wor=
k
>>> > than
>>> > it's worth.  Sure you can't fill a 100G NIC with one connection, but
>>> > that
>>> > seems like an academic problem, not one for workloads I've seen.
>>> > Typically
>>> > the extra cost of multithreading outweighs its value.
>>> >
>>> > To be clear, I don't think this is an awful idea, but I also don't se=
e
>>> > the
>>> > value and it adds complexity.  I read Manasi's email, but I don't thi=
nk
>>> > I
>>> > understand why any of those matter in practice.
>>> >
>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla > wrote:
>>> >>
>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>>> >> >
>>> >> wrote:
>>> >>>
>>> >>> This proposal increases the size of the ACK frame by 1 byte in the
>>> >>> common
>>> >>> case (less than 63 ACK ranges), since the ACK length field here
>>> >>> always
>>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length
>>> >>> integer.
>>> >>> Considering how much work we put into minimising the size of the
>>> >>> frames,
>>> >>> this feels like a step in the wrong direction..
>>> >>>
>>> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK
>>> >>> frame
>>> >>> requires looping over and making changes to a data structure that
>>> >>> keeps
>>> >>> track of sent packets. This is much more expensive than simply
>>> >>> parsing
>>> >>> a
>>> >>> bunch of varints in the ACK frame. It seems unlikely that a
>>> >>> multi-threaded
>>> >>> packet parser would offer any real-world performance benefits.
>>> >>
>>> >>
>>> >> I don't want to overstate the benefit here, but my point isn't that
>>> >> parsing is expensive but that if you want to have a multithreaded
>>> >> packet
>>> >> processing system, then it's nice to have a simpler data structure
>>> >> (the
>>> >> unparsed ACK block) to hand to the ACK processing thread.
>>> >>
>>> >> -Ekr
>>> >>
>>> >>
>>> >>>
>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>>> >>> >
>>> >>> wrote:
>>> >>>>
>>> >>>> When we discussed this before, some people observed that this
>>> >>>> creates
>>> >>>> a need to encode in two passes.  That's the trade-off here.  (Not
>>> >>>> expressing an opinion.)
>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar >
>>> >>>> wrote:
>>> >>>> >
>>> >>>> > I don't have a strong opinion on this. I'm certainly not opposed
>>> >>>> > to
>>> >>>> > it.
>>> >>>> > Does anyone have a strong opposition?
>>> >>>> >
>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian
>>> >>>> > > wrote:
>>> >>>> >>
>>> >>>> >> I agree as well since this can help reduce per packet processin=
g
>>> >>>> >> overhead. ACKs are going to be the second most common frame typ=
e
>>> >>>> >> so no
>>> >>>> >> objections to special casing.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric
>>> >>>> >> Rescorla
>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>>> >>>> >> To: Deval, Manasi >
>>> >>>> >> Cc: Jana Iyengar =
>; QUIC WG >
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK lengt=
h
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> I agree with Manasi here. This change would allow ack frame
>>> >>>> >> parsing
>>> >>>> >> to be more self-contained, which is an advantage for the parser
>>> >>>> >> and also
>>> >>>> >> potentially for parallelism (because you can quickly find the
>>> >>>> >> frame and then
>>> >>>> >> process it in parallel).
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> -Ekr
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi
>>> >>>> >> > wrote:
>>> >>>> >>
>>> >>>> >> In general, varints require some specific logic for parsing. To
>>> >>>> >> skip
>>> >>>> >> over any header, I have to read every single varint. As the cod=
e
>>> >>>> >> sees Stream
>>> >>>> >> and ACK headers most frequently, that is my focus.  The Stream
>>> >>>> >> frame has a
>>> >>>> >> length in its third field.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify
>>> >>>> >> length. There are two reads each for =91largest acknowledged=92=
, =91ACK
>>> >>>> >> delay=92 and
>>> >>>> >> =91ACK block count=92. The pain point is the total number of cy=
cles
>>> >>>> >> parse an
>>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets
>>> >>>> >> have a
>>> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> Thanks,
>>> >>>> >>
>>> >>>> >> Manasi
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana
>>> >>>> >> Iyengar
>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>>> >>>> >> To: Deval, Manasi >; QUIC WG
>>> >>>> >> >
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK lengt=
h
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> You're right that we no longer have the ability to skip an ACK
>>> >>>> >> frame,
>>> >>>> >> and this crept in when we moved to varints.
>>> >>>> >>
>>> >>>> >> I believe your problem though is generally true of most frames
>>> >>>> >> not
>>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames
>>> >>>> >> are now all
>>> >>>> >> varints. To skip any frame, you'll need to parse the varint
>>> >>>> >> fields
>>> >>>> >> in those
>>> >>>> >> frames. If you have logic to process and skip varints, then
>>> >>>> >> skipping the ack
>>> >>>> >> block section is merely repeating this operation (2*num_block+1=
)
>>> >>>> >> times. Do
>>> >>>> >> you see specific value in skipping ACK frames over the other
>>> >>>> >> control frames?
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov
>>> >>>> >>  wrote:
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>>> >>>> >> > -        Moving the ACK length to the front of the ACK allows
>>> >>>> >> > the
>>> >>>> >> >          flexibility of either reading the entire ACK or
>>> >>>> >> > reading
>>> >>>> >> > the
>>> >>>> >> >          first 16 bits and skipping over the length. This is =
a
>>> >>>> >> > useful
>>> >>>> >> >          feature for the case where ACK processing is split
>>> >>>> >> > into
>>> >>>> >> >          multiple layers. Depending on the processor this is
>>> >>>> >> > run
>>> >>>> >> > on,
>>> >>>> >> >          there are different advantages -
>>> >>>> >>
>>> >>>> >> Just a note.  In my experience, the cost of parsing an ACK fram=
e
>>> >>>> >> is
>>> >>>> >> negligible compared to the cost of processing an ACK frame: tha=
t
>>> >>>> >> is,
>>> >>>> >> poking at various memory locations to discard newly ACKed
>>> >>>> >> packets.
>>> >>>> >>
>>> >>>> >>   - Dmitri.
>>> >>>> >>
>>> >>>> >>
>>> >>>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>
>
>
> --
> Kazuho Oku



--
Kazuho Oku



--_000_MWHPR15MB182169F94173C287298636AAB65E0MWHPR15MB1821namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable










Hi Manasi,


Doesn't the segmentation make mor=
e sense for stream frames than ACK frames? ACK frames are not sent very oft=
en and at least in production what we've seen is that most of the time ACKs=
 naturally end up getting sent in
 their own pure ACK packets. 



Not arguing for or against the length prefix design, but trying to understa=
nd why having a length prefix in the ACK frame helps segmentation for strea=
m frames even on the recv side.







Subodh








From: QUIC <quic-bounces=
@ietf.org> on behalf of Deval, Manasi <manasi.deval@intel.com>

Sent: Saturday, July 14, 2018 8:35:14 PM

To: 'Mikkel Fahn=F8e J=F8rgensen'; Eric Rescorla; Kazuho Oku

Cc: Jana Iyengar; Praveen Balasubramanian; Ian Swett; Marten Seemann=
; IETF QUIC WG; Martin Thomson

Subject: RE: Proposal to replace ACK block count with ACK length

 











Hi All,


 


I would like to revisit this discussion in the con=
text of distributed processing. The distributed processing doesn=92t only a=
pply to multi-threading but also to layered processing.



 


One example of layered processing is segmentation.=
 The current Chromium implementation currently creates the segments and pas=
ses them as a bunch into the Linux kernel. There
 is a GSO patch that would chop at the segment boundary and encapsulate in =
UDP headers. We can further improve performance by plugging in a smarter se=
gmentation algorithm such that the segment processing can account for type =
of frame, its size and make intelligent
 boundary and padding decisions at a lower layer or in an offload. To this =
end, the algorithm needs to identify the size of each of the frames. Having=
 an ACK length that can be determined in a single read is much more efficie=
nt than having to do a series of
 reads. 


 


Thanks,


Manasi


&nb=
sp;






From: Mikkel Fahn=F8e J=F8rgensen [mailto:mikkelfj@gmail.com]


Sent: Friday, June 22, 2018 9:15 AM

To: Eric Rescorla <ekr@rtfm.com>; Kazuho Oku <kazuhooku@gma=
il.com>

Cc: Jana Iyengar <jri.ietf@gmail.com>; IETF QUIC WG <quic@i=
etf.org>; Deval, Manasi <manasi.deval@intel.com>; Marten Seemann &=
lt;martenseemann@gmail.com>; Martin Thomson <martin.thomson@gmail.com=
>; Ian Swett <ianswett@google.com>; Praveen Balasubramanian
 <pravb@microsoft.com>

Subject: Re: Proposal to replace ACK block count with ACK length






 




Another option is to write out frames as is wi=
thout length except as needed for varints. When a packet is nearly done, a =
run-length encoded frame index is placed in the
 packet tail. It could also include the frame types. A reader can now direc=
tly find or skip ACK frames and the writer does not have to compute lengths=
 before writing. Of course, the reader needs to be able to locate the index=
 at the tail which can be tricky
 with coalesced packets, but not impossible. Isn=92t this largely how zip-f=
iles work?








 






Mikkel






 


On 22 June 2018 at 17.00.52, Mikkel Fahn=F8e J=
=F8rgensen (mikkelfj@gmail=
.com)
 wrote:










As I said earlier, I also favour a length pref=
ix. But, Ian does have a point:






 






Writing data is generally more expensive than =
reading data. Especially if you have to traverse long data structures to fi=
nd the length before you can start writing and/or
 you may have to conservatively reserve extra space for a length field.






 






So before deciding one way or the other, the c=
ost of writing needs to be well understood, also in scenarios with large MT=
U=92s.






 






In the flatbuffers space that I=92m involved w=
ith, streaming has turned to be an issue because data cannot be transmitted=
 in parts without index data on a separate channel
 to recombined fragments. A simple, but non-standard, change in the format =
would fix this. JSON and CoAP allows streaming, but many other formats do n=
ot, including later versions of protocol buffers, as I understand.





 






An odd consequence of making both read and wri=
te efficient is that length better work better if stored at the end and pac=
kets read backwards. This requires a single total
 length prefix but this is stored in the datagram header. This is probably =
too odd-ball, but still a consideration worth noting.






 






The second best alternative may therefore be t=
o allow writes to be fast and reads to be decent.






 






Yet, I still like length prefixes if they coul=
d be made write efficient because high performance low-latency processes ca=
re zero about ACK and can consume a packet directly
 while a background process handles all the latency insensitive ACK and ret=
ransmission logic.






 






The question is also, where is the pressure: a=
n IoT aggregator might be massively read intensive while a web cache would =
be very write intensive.






 




 






Kind Regards,






Mikkel Fahn=F8e=
 J=F8rgensen






 


On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com)
 wrote:












It seems like there are two questions at hand =
here:






 






1. Would it be architecturally better to have =
frames have a consistent self-contained






representation?






2. Is it enough better that we should do so no=
w.






 






I agree with Kazuho that (a) we don't have tha=
t representation now and (b) it would






be a better design to do so. I'm perhaps somew=
hat more positive on (2) than he






is. I don't think it's critically important th=
at we make the change, but if we were






to hold a consensus call, I think I would be i=
n favor. I'd certainly be interested






in looking at a proposal if someone else were =
to make one.






 






-Ekr






 






 








 




On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku &l=
t;kazuh=
ooku@gmail.com>
 wrote:




2018-06-22 8:08 GMT+09:00 Deval, Manasi &l=
t;manasi.deval@intel.c=
om>:

> I feel that the requirement to have every value valid is somewhat acad=
emic.



I think that Marten is correct in pointing out that making the ACK

frame self-containing (by having a field that represents the number of

octets being consumed by the frame) would be an exception from the

design pattern we have.



Look at STREAM frame. The field is not self-contained. Instead, it has

a Length field for the Stream Data, which is a leaf. The same goes for

NEW_CONNECTION_ID frame (that has the length field for Connection ID

field (which is also a leaf)), CONNECTION_CLOSE (length field for

Reason Phase).



I agree with Marten, Mikkel (and possibly others as well) that having

consistency is important.



Therefore, I agree with Mikkel that we should consider making every

frame self-contained or keeping every frame as-is (i.e. not

self-contained).



FWIW, as described in the latter half of

https://www.ietf.org/mail-arch=
ive/web/quic/current/msg04287.html,
 it

is possible to make every frame self-contained *and* also make ACK

frames smaller than the current draft. Making every frame

self-contained gives us the possibility to send new extension frames

without negotiation.



I do not think that I would push for making every frame self-contained

by myself (because I do not think it meets the high bar to have a

change at such a late moment of standardization), but as stated, my

preference goes to seeing every frame made self-contained or none of

them made as such.








> The length value provides much more value than the block count and the=
 fact

> that certain values can never be achieved is an inherent property of t=
he

> length.

>

>

>

> One interesting observation is that this property is not limited to le=
ngth.

> One can even make a similar argument about ACK block count. The maximu=
m

> number of ACK blocks that can be defined will not always have a meanin=
gful

> value. In out examples, 0,1,2,3 are all valid. If I set the value of A=
CK

> block count to have lower two bits to be 11, the maximum value is of A=
CK

> blocks is =96 4611686018427387903. This is the same value of largest
> acknowledged so if the ACK block count was set to this value, it would=
 still

> be meaningless.

>

>

>

> Thanks,

>

> Manasi

>

>

>

>

>

>

>

> From: Marten Seemann [mailto:martenseemann@gmail.com]

> Sent: Tuesday, June 19, 2018 6:44 PM

> To: Deval, Manasi <manasi..deval@intel.com>

> Cc: Ian Swett <ia=
nswett@google.com>; Kazuho Oku <kazuhooku@gmail.com>;
 Eric

> Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>;
 Praveen

> Balasubramanian <=
pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>;
 Martin

> Thomson <mar=
tin.thomson@gmail.com>

>

>

> Subject: Re: Proposal to replace ACK block count with ACK length

>

>

>

> Hi Manasi,

>

>

>

>> The risk of disagreement between ack blocks and ack block count is=
 same as

>> the risk of disagreement between ack blocks and ack length. Either=
 way this

>> needs to be counted up while creating the ACK and counted down whi=
le parsing

>> it. The possibility of error is the same. Getting the ack block co=
unt wrong

>> is as problematic as getting the ack length wrong. Do you agree?
>

>

>

> I disagree. Let's take an example of an ACK frame with one ACK range, =
that

> needs a 2 byte varint to represent the First ACK Block and another 2 b=
yte

> varint to represent the Gap.

>

> With your proposal:

>

> The values 0 and 1 are invalid, since the length fields itself is incl=
uded

> in the length.

> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckD=
elay)) - 1 are

> invalid, since the length needs to include the Largest Acknowledged an=
d the

> Ack Delay.

> The value 2 + len(LargestAcknowledged) + len(AckDelay) would b=
e the first

> valid value, and correspond to an ACK frame with no blocks.

> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1=
 is invalid, since

> it would cut the varint for the First ACK Block

> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2=
 is invalid, since

> it would cut the frame after the First ACK Block (but every block must=
 be

> followed by a gap length)

> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3=
 is invalid, since

> it would cut the varint for the Gap

> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay=
) + 4 is valid

>

> There are *a lot* of invalid values that you can encode into the ACK l=
ength

> field. More importantly, *none* of these error cases exists with the c=
urrent

> frame format.

>

> The *only* error case that can occur with our current format is that t=
he

> packet is too short for the number of ACK blocks that are supposed to<=
br>
> contained in the frame. This can occur with your proposal as well (in<=
br>
> addition to the error cases listed above).

>

>

>

> My concern is not that it's impossible or even particularly hard to ca=
tch

> these errors, but I dislike the property that some (in fact, most) enc=
odable

> values are invalid.

>

>

>

> Best,

>

> Marten

>

>

>

>

>

> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@intel.com><=
br>
> wrote:

>

> Hi Ian,

>

>

>

> Here is another attempt to solve the objections you raised:

>

>

>

>>I'm not a fan of this proposal, because I think it is impractical t=
o drop

>> the number of ack blocks, because with the ECN proposal it becomes=


>> impractically complex to parse.

>

> Is there a reason the proposal from Christian does not solve this prob=
lem?

>

>

>

>>If we don't remove the number of ack blocks, then the ack frame is =
larger,

>> but I don't think the extra size field is useful for most implemen=
tations.

>> Also, it means the length can disagree with the actual length, whi=
ch add

>> complexity and the possibility of writing error-prone code.  =
The idea of

>> someone offloading ack processing and then proceeding to trust the=
 length

>> seems like someone could get wrong and cause some concerning issue=
s.

>

> The risk of disagreement between ack blocks and ack block count is sam=
e as

> the risk of disagreement between ack blocks and ack length. Either way=
 this

> needs to be counted up while creating the ACK and counted down while p=
arsing

> it. The possibility of error is the same. Getting the ack block count =
wrong

> is as problematic as getting the ack length wrong. Do you agree?

>

>

>

>>My experience is multithreaded packet processing is more cost and w=
ork than

>> it's worth.  Sure you can't fill a 100G NIC with one connecti=
on, but that

>> seems like an academic problem, not one for workloads I've seen.&n=
bsp; Typically

>> the extra cost of multithreading outweighs its value.

>

> The value is two fold =96 pre-processing and multi-threading. If we
> pre-process the received packets such that ACKs and streams can be

> coalesced, the receive side can indicate a large chunk of information =
though

> the kernel, reducing the cost of system call and protocol overhead. Th=
is is

> the same concept as UDP segmentation taken a step further on receive s=
ide.

> After this chunk is indicated into the QUIC protocol, the protocol may=


> process stream and ACK in parallel. While folks may or may not utilize=
 this,

> there is an advantage here.

>

>

>

> Thanks,

>

> Manasi

>

>

>

>

>

> From: Ian Swett [mailto:=
ianswett@google.com]

> Sent: Tuesday, June 19, 2018 11:26 AM

> To: Deval, Manasi <manasi..deval@intel.com>

> Cc: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku

> <kazuhooku@gmail.=
com>; Eric Rescorla <ekr@rtfm.com>;
 Jana Iyengar

> <jri.ietf@gmail.co=
m>; Praveen Balasubramanian <pravb@microsoft.com>;
 IETF

> QUIC WG <quic@ietf.org<=
/span>>; Martin Thomson <martin.thomson@gmail.com>

>

>

> Subject: Re: Proposal to replace ACK block count with ACK length

>

>

>

> I'm still not interested in this change, for the reasons I stated abov=
e.

>

>

>

> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@intel.com><=
br>
> wrote:

>

> Hi All,

>

>

>

> Do we have agreement here to create a new PR?

>

>

>

> Thanks,

>

> Manasi

>

>

>

> From: Deval, Manasi

> Sent: Sunday, June 17, 2018 2:25 PM

> To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku

> <kazuhooku@gmail.=
com>

> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric
 Rescorla

> <ekr@rtfm.com=
>; Jana Iyengar <jri.ietf@gmail.com>;
 Praveen Balasubramanian

> <pravb@microsoft.=
com>; IETF QUIC WG <quic@ietf.org>;
 Martin Thomson

> <martin.thom=
son@gmail.com>

> Subject: RE: Proposal to replace ACK block count with ACK length

>

>

>

> Hi All,

>

>

>

> I have made a list of objections to the proposal and the solutions to =
those

> objections discussed on this thread.

>

>

>

> a.      Co-existence of length field with ECN field and=
 ACK blocks.

>

>

>

> Christian suggested to move the ECN fields to precede the ACK blocks. =
This

> is an elegant solution. Parsing entire list of ACK blocks to review EC=
N bits

> would have been annoying, even though it can work.

>

>

>

> b.      There are two cases to be parsed =96 entire ACK=
 and parse ACK to

> identify length. There are some reservations when ACK parsing gets har=
der

> for the case where the entire header needs to be parsed.

>

>

>

> Agreement from several folks here. In the original ACK defined in draf=
t 12

> of the slide, one would count down number of ACK blocks to get to the =
end of

> the packet. In the proposal I made, one would count down the length to=


> identify the end of the packet. The logic is very similar in cycle cou=
nt and

> complexity. Several folks also commented to this effect.

>

>

>

> c.      Multi-threaded packet processing

>

>

>

> I would expect that there are 10s of 1000s of connections in use at an=
y time

> for a server with a high speed link. Multi-threading to handle each of=
 these

> flows / connections in parallel is necessity to be able to support lar=
ge

> number of connections on a high speed link. Tx segmentation, Rx coales=
cing

> are well known strategies to reduce the processing cost. In initial st=
ages,

> code is often written as a single-threaded and then re-factored to

> parallelize cycle intensive operations. In order to allow this protoco=
l to

> scale in future, I would suggest we do not preclude this case.

>

>

>

> d.      Increase in ACK size by 1 byte.

>

>

>

> I do not see this as a serious issue but if folks but we can consider =
making

> this a varint, if others have strong feelings about it. It=92s a trade=
-off : 2

> reads to save 1 byte.

>

>

>

> e.      Every encodable value should be valid

>

> Not every length will be valid. This is inherent to lengths. This same=
 issue

> ails the =91payload length=92 in QUIC header. Not only does the issue =
exist for

> small values, it also applies to large values since data stream will b=
e sent

> after crypto negotiation.  E.g.  - how does one craft a payl=
oad with 62 bit

> payload length in a large header?

>

>

>

>

>

> Thanks,

>

> Manasi

>

>

>

>

>

> From: Marten Seemann [mailto:martenseemann@gmail.com]

> Sent: Sunday, June 17, 2018 6:59 AM

> To: Kazuho Oku <k=
azuhooku@gmail.com>

> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric
 Rescorla

> <ekr@rtfm.com=
>; Jana Iyengar <jri.ietf@gmail.com>;
 Praveen Balasubramanian

> <pravb@microsoft.=
com>; IETF QUIC WG <quic@ietf.org>;
 Martin Thomson

> <martin.thom=
son@gmail.com>; Deval, Manasi <manasi.deval@intel.com>
> Subject: Re: Proposal to replace ACK block count with ACK length

>

>

>

> Maybe it's specific to Go, but I'm using a single io.Reader for the wh=
ole

> packet, so as long as the packet payload is long enough, the varint pa=
rsing

> will not fail.

>

> I don't think that specifics of programming languages matter here thou=
gh,

> and I'm sure both frame formats can be reasonably implemented in C as =
well

> as in Go. The reasons I'm opposed to Manasi's proposal are that it mov=
es us

> away from the principle that only reasonable values should be encodabl=
e, and

> that it increases the size of the ACK frame, for the questionable bene=
fit of

> being able to parallelise the frame parser.

>

>

>

> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>

> 2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.com>=
;:

>> At least for my implementation, parsing doesn't become easier, it =
becomes

>> more complex with this proposal. My varint-parser always consumes =
as many

>> bytes as the varint requires, so after parsing a varint, I'd have =
to

>> introduce an additional check that this didn't overflow the ACK le=
ngth

>> (e.g.

>> consider that I parsed the ACK frame so far that only 2 bytes are<=
br>
>> remaining

>> according to ACK length field, but the next varint is 4 bytes long=
).

>

> Isn't your varint parser checking that it has not (or will not) run
> across the end of the packet payload for every ACK block it parses?
> I'd assume that you would be doing that, because I think that is

> necessary to avoid buffer overrun.

>

> What I am saying that that check could be converted to a overrun check=


> against the end of the "frame payload", and that checking th=
e

> remaining block count becomes unnecessary, in case we replace ACK

> Block Count with ACK Frame Length.

>

>>

>> In general, we've been moving the wire image towards making every<=
br>
>> encodable

>> value valid. This proposal moves us away from that principle:

>> * some small values are always invalid (the length can never be be=
tween 0

>> and 3)

>> * a lot of intermediate values are invalid (if the boundary falls =
inside a

>> varint, as described above)

>> Both these cases can't occur with the current ACK frame format..
>>

>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com>
 wrote:

>>>

>>> 2018-06-17 8:34 GMT+09:00 Ian Swett

>>> <ianswett=3D40google.com@dmarc.ietf.org>:

>>> > I'm not a fan of this proposal, because I think it is imp=
ractical to

>>> > drop

>>> > the number of ack blocks, because with the ECN proposal i=
t becomes

>>> > impractically complex to parse.

>>>

>>> For the ECN proposal, as Christian has suggested, we can move =
the ECN

>>> counters before the ACK blocks. Then, it would not be complex =
to

>>> parse.

>>>

>>> And my view is that parsing becomes easier if we replace ACK B=
lock

>>> Count with ACK Frame Length.

>>>

>>> Now, with ACK Block Count, we need to check the remaining numb=
er of

>>> blocks and the remaining space in the packet payload for every=
 block

>>> that we parse. Failing to check either leads to a bug or a sec=
urity

>>> issue.

>>>

>>> If we switch to ACK Frame Length, we need to only check the re=
maining

>>> space in the frame.

>>>

>>> I think that this is the biggest benefit of replacing ACK Bloc=
k Count

>>> with ACK Frame Length. OTOH the downside is that you need extr=
a one to

>>> two bits (one if the size of block / gap is expected to be bel=
ow 65,

>>> two if they are expected to be above that) for encoding ACK Fr=
ame

>>> Length compared to ACK Block Count.

>>>

>>>

>>>

>>> Having said that, I honestly wonder if all the frames could ha=
ve it's

>>> length being encoded (either explicitly or either as a signal =
that

>>> says "to the end of the packet"). Consider something=
 like below:

>>>

>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload =
(*) |

>>>  or

>>> |1| frame-type (7) | frame-payload (*) |

>>>

>>> When MSB of the first octet set to zero, the length of the fra=
me

>>> payload is designated by the varint that immediately follows t=
he frame

>>> type.

>>> When MSB of the first octet set to one, the length of the fram=
e

>>> payload spans to the end of the packet.

>>>

>>> In this encoding, we can always omit the Length field of a STR=
EAM

>>> frame. So the overhead for carrying stream data will be indiff=
erent in

>>> practice.

>>>

>>> For the ACK frame, we can omit the ACK Block Count field. And =
the

>>> overhead will be one to two bits if the ACK frame is sent in t=
he

>>> middle of the packet (thereby using the encoding with explicit=
 frame

>>> payload length), or one octet or more shorter if ACK is the la=
st frame

>>> of the packet.

>>>

>>> We are likely to see increase of overhead for most of the othe=
r types

>>> of frames, but I do not think that would be an issue consideri=
ng that

>>> they will be far seldom seen compared to STREAMs and ACKs.

>>>

>>> To summarize, my anticipation is that we can make all the fram=
es

>>> self-contained (i.e. the length can be determined without the<=
br>
>>> knowledge of how each frame is encoded) without any overhead, =
if we

>>> agree on making the frame type space 1 bit smaller.

>>>

>>> Finally, the biggest benefit of using a self-contained encodin=
g of

>>> frames is that we would have the ability to introduce new opti=
onal

>>> frames without negotiation. By making the frames self-containe=
d, QUIC

>>> endpoints will have the freedom of ignoring the frames that th=
ey do

>>> not understand.

>>>

>>> Being able to send QUIC frames defined in extensions without
>>> negotiating using Transport Parameters will be a win in both t=
erms of

>>> security (because clients' TP is sent in clear) and flexibilit=
y

>>> (because we will be possible to send the extensions before we =
figure

>>> out whether the peer supports that extension).

>>>

>>> > If we don't remove the number of ack blocks, then the ack=
 frame is

>>> > larger,

>>> > but I don't think the extra size field is useful for most=


>>> > implementations.

>>> > Also, it means the length can disagree with the actual le=
ngth, which

>>> > add

>>> > complexity and the possibility of writing error-prone cod=
e.  The idea

>>> > of

>>> > someone offloading ack processing and then proceeding to =
trust the

>>> > length

>>> > seems like someone could get wrong and cause some concern=
ing issues.

>>> >

>>> > My experience is multithreaded packet processing is more =
cost and work

>>> > than

>>> > it's worth.  Sure you can't fill a 100G NIC with one=
 connection, but

>>> > that

>>> > seems like an academic problem, not one for workloads I'v=
e seen.

>>> > Typically

>>> > the extra cost of multithreading outweighs its value.

>>> >

>>> > To be clear, I don't think this is an awful idea, but I a=
lso don't see

>>> > the

>>> > value and it adds complexity.  I read Manasi's email=
, but I don't think

>>> > I

>>> > understand why any of those matter in practice.

>>> >

>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <=
ekr@rtfm.com> wrote:<=
br>
>>> >>

>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann

>>> >> <martenseemann@gmail.com>

>>> >> wrote:

>>> >>>

>>> >>> This proposal increases the size of the ACK frame=
 by 1 byte in the

>>> >>> common

>>> >>> case (less than 63 ACK ranges), since the ACK len=
gth field here

>>> >>> always

>>> >>> consumes 2 bytes, whereas the ACK Block Count is =
a variable-length

>>> >>> integer.

>>> >>> Considering how much work we put into minimising =
the size of the

>>> >>> frames,

>>> >>> this feels like a step in the wrong direction..
>>> >>>

>>> >>> Regarding the processing cost, I agree with Dmitr=
i. Handling an ACK

>>> >>> frame

>>> >>> requires looping over and making changes to a dat=
a structure that

>>> >>> keeps

>>> >>> track of sent packets. This is much more expensiv=
e than simply

>>> >>> parsing

>>> >>> a

>>> >>> bunch of varints in the ACK frame. It seems unlik=
ely that a

>>> >>> multi-threaded

>>> >>> packet parser would offer any real-world performa=
nce benefits.

>>> >>

>>> >>

>>> >> I don't want to overstate the benefit here, but my po=
int isn't that

>>> >> parsing is expensive but that if you want to have a m=
ultithreaded

>>> >> packet

>>> >> processing system, then it's nice to have a simpler d=
ata structure

>>> >> (the

>>> >> unparsed ACK block) to hand to the ACK processing thr=
ead.

>>> >>

>>> >> -Ekr

>>> >>

>>> >>

>>> >>>

>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>>> >>> <martin.thomson@gmail.com>

>>> >>> wrote:

>>> >>>>

>>> >>>> When we discussed this before, some people ob=
served that this

>>> >>>> creates

>>> >>>> a need to encode in two passes.  That's =
the trade-off here.  (Not

>>> >>>> expressing an opinion.)

>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar =
<jri.ietf@gmail.com>

>>> >>>> wrote:

>>> >>>> >

>>> >>>> > I don't have a strong opinion on this. I=
'm certainly not opposed

>>> >>>> > to

>>> >>>> > it.

>>> >>>> > Does anyone have a strong opposition?
>>> >>>> >

>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen =
Balasubramanian

>>> >>>> > <pravb@microsoft.com> wrote:

>>> >>>> >>

>>> >>>> >> I agree as well since this can help =
reduce per packet processing

>>> >>>> >> overhead. ACKs are going to be the s=
econd most common frame type

>>> >>>> >> so no

>>> >>>> >> objections to special casing.

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On=
 Behalf Of
 Eric

>>> >>>> >> Rescorla

>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM<=
br>
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>

>>> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; Q=
UIC WG <quic@ietf.org=
>

>>> >>>> >> Subject: Re: Proposal to replace ACK=
 block count with ACK length

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> I agree with Manasi here. This chang=
e would allow ack frame

>>> >>>> >> parsing

>>> >>>> >> to be more self-contained, which is =
an advantage for the parser

>>> >>>> >> and also

>>> >>>> >> potentially for parallelism (because=
 you can quickly find the

>>> >>>> >> frame and then

>>> >>>> >> process it in parallel).

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> -Ekr

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Dev=
al, Manasi

>>> >>>> >> <manasi.deval@intel.com> wrote:

>>> >>>> >>

>>> >>>> >> In general, varints require some spe=
cific logic for parsing. To

>>> >>>> >> skip

>>> >>>> >> over any header, I have to read ever=
y single varint. As the code

>>> >>>> >> sees Stream

>>> >>>> >> and ACK headers most frequently, tha=
t is my focus.  The Stream

>>> >>>> >> frame has a

>>> >>>> >> length in its third field.

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> ACK parsing, however, needs 6 + =
2*num_blocks reads to identify

>>> >>>> >> length. There are two reads each for=
 =91largest acknowledged=92, =91ACK

>>> >>>> >> delay=92 and

>>> >>>> >> =91ACK block count=92. The pain poin=
t is the total number of cycles

>>> >>>> >> parse an

>>> >>>> >> ACK. If I am processing 10M pps, whe=
re 10% - 30% of the packets

>>> >>>> >> have a

>>> >>>> >> piggybacked ACK, these cycles become=
s a significant bottleneck.

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> Thanks,

>>> >>>> >>

>>> >>>> >> Manasi

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On=
 Behalf Of
 Jana

>>> >>>> >> Iyengar

>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM<=
br>
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG

>>> >>>> >> <quic@ietf.org>

>>> >>>> >> Subject: Re: Proposal to replace ACK=
 block count with ACK length

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> You're right that we no longer have =
the ability to skip an ACK

>>> >>>> >> frame,

>>> >>>> >> and this crept in when we moved to v=
arints.

>>> >>>> >>

>>> >>>> >> I believe your problem though is gen=
erally true of most frames

>>> >>>> >> not

>>> >>>> >> just ACKs, since ids, packet numbers=
, and numbers in all frames

>>> >>>> >> are now all

>>> >>>> >> varints. To skip any frame, you'll n=
eed to parse the varint

>>> >>>> >> fields

>>> >>>> >> in those

>>> >>>> >> frames. If you have logic to process=
 and skip varints, then

>>> >>>> >> skipping the ack

>>> >>>> >> block section is merely repeating th=
is operation (2*num_block+1)

>>> >>>> >> times. Do

>>> >>>> >> you see specific value in skipping A=
CK frames over the other

>>> >>>> >> control frames?

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmit=
ri Tikhonov

>>> >>>> >> <dtikhonov@litespeedtech..com>=
 wrote:

>>> >>>> >>

>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM &=
#43;0000, Deval, Manasi wrote:

>>> >>>> >> > -        Mo=
ving the ACK length to the front of the ACK allows

>>> >>>> >> > the

>>> >>>> >> >        &nbs=
p; flexibility of either reading the entire ACK or

>>> >>>> >> > reading

>>> >>>> >> > the

>>> >>>> >> >        &nbs=
p; first 16 bits and skipping over the length. This is a

>>> >>>> >> > useful

>>> >>>> >> >        &nbs=
p; feature for the case where ACK processing is split

>>> >>>> >> > into

>>> >>>> >> >        &nbs=
p; multiple layers. Depending on the processor this is

>>> >>>> >> > run

>>> >>>> >> > on,

>>> >>>> >> >        &nbs=
p; there are different advantages -

>>> >>>> >>

>>> >>>> >> Just a note.  In my experience,=
 the cost of parsing an ACK frame

>>> >>>> >> is

>>> >>>> >> negligible compared to the cost of p=
rocessing an ACK frame: that

>>> >>>> >> is,

>>> >>>> >> poking at various memory locations t=
o discard newly ACKed

>>> >>>> >> packets.

>>> >>>> >>

>>> >>>> >>   - Dmitri.

>>> >>>> >>

>>> >>>> >>

>>> >>>>

>>> >>

>>> >

>>>

>>>

>>>

>>> --

>>> Kazuho Oku

>

>

>

> --

> Kazuho Oku












--

Kazuho Oku






 






















--_000_MWHPR15MB182169F94173C287298636AAB65E0MWHPR15MB1821namp_--


From nobody Sun Jul 15 10:56:15 2018
Return-Path: 
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 5DAEC128CF3 for ; Sun, 15 Jul 2018 10:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 rqUFTVOWKFlc for ; Sun, 15 Jul 2018 10:56:08 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 559F4130E42 for ; Sun, 15 Jul 2018 10:56:08 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l189-v6so13440999ywb.10 for ; Sun, 15 Jul 2018 10:56:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pG4ZAzskfHRA2wyuH65UwiVYDOhKyCjmdpHZgcKuU9s=; b=jmmTrcQIp1uWFcf1HDPm4+Aw0O1Loircph1R95Wj3doFq7YrJhYnVLfWT3VJeNpr8o JxC7IwY289C4KYjSm8dwfzmy/OgYw7PXaedAm7y1Z17SaFpLVJkIQiB0QzO4zYd2LpXl o6oY4/WcrMKaStZ1vCaWI47gH73hw2xUQjFLM2u38TSW/sp5sRtKiVzC2/9AY5sEwEzl qxYXoe7qAFuUCj5AtFVp++o531hlBQXIQ8I4u3gT/UqEWM+c4IaDtGKWswzFS44MBrqs r1POnJoN9YfrWn+zXgC3vjr5bZ+WbF5gN7RV76Yysvea3c6+7TmhYkRMKzI+9PQw/VSA A5+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pG4ZAzskfHRA2wyuH65UwiVYDOhKyCjmdpHZgcKuU9s=; b=Aap2kx+f06aJ2+4eHSvX4TOYB9AJXHgselZYZcvmKrQgB0nrKsPcg2B/kybnVfZSf/ PNrZ7sU7eQ3NZIUqZPTowro5cEu0+fa0cxMc5kcvPd4JTZrql1zwk5OydaF+cVYEUfmj Vn0Wn5cwl+sezA/wUI2sn8fa8GiNrILzZmeucbwXpdw2msZuqdK7/rg8ibyPk9YWT1zL lDFxOl6xQP5oJB/yV9e9DAuWVBp5jOlu1mU4PYeQHxj3knr7O0Vgcbq4njUZ2lxQNm1R LEKPvhwAf1GYh25EGsvZkdf+Fa29J8rIwbUtJj8qJ3mMEmKQHhKJYzvRMYvk6RZU5r51 LCRw==
X-Gm-Message-State: AOUpUlGGi6SleLsicoNbHGAtcVODphxTfZC11FXhsPIpVRW/umSAU6l/ jvv4VINp3+qzAUiCoyi3jBMxjqZJBd/b650EM0D31Q==
X-Google-Smtp-Source: AAOMgpcLlH7Vt5mANFYk0kOO25JK2yf2o9wg36lh8t9msxNMRYnkO9wBKNOFYzdLqld1N5kimPo/T5lvBjDNw9J5jY8=
X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr7184931ywa.381.1531677367299;  Sun, 15 Jul 2018 10:56:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 10:55:26 -0700 (PDT)
In-Reply-To: <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>  <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>  <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>
From: Eric Rescorla 
Date: Sun, 15 Jul 2018 10:55:26 -0700
Message-ID: 
Subject: Re: Connection ID lengths 1, 2 and 3
To: "Deval, Manasi" 
Cc: Marten Seemann , Ian Swett ,  IETF QUIC WG , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Content-Type: multipart/alternative; boundary="00000000000063bbaa05710d6d1b"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 17:56:15 -0000

--00000000000063bbaa05710d6d1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 15, 2018 at 10:04 AM, Deval, Manasi 
wrote:

> There is a 32bit version number that precedes the length field. Until we
> have a thousand versions, we are always sending 3 extra bytes on the wire=
.
>

Well, the current version actually has the high bit set.

>
> Thanks,
> Manasi
>
> On Jul 15, 2018, at 12:52 PM, Marten   wrote:
>
> I don't think we should reduce the number of sizes available. Sending
> bytes on the wire is orders of magnitude more expensive than performing a
> simple transformation to a parsed value. I'd prefer if we could discuss
> this separately, since this is quite the opposite of what I was originall=
y
> proposing.
>
> To reiterate my argument, changing the invariants such that the values 1,
> 2 and 3 can be used would be a big benefit for p2p applications, since th=
ey
> would be able to use super-short connection IDs. Since this is a change
> that requires a change to the invariants, we need to make this decision
> very soon, if we want to enable this use case of QUIC.
>
> On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi 
> wrote:
>
>> I would still prefer if we can reduce the number of sizes supported.
>>
>> Could a scheme where we support only 5 cids be used? Use a 3 bit size ,
>> shift left by 2 and not use the last 2 sizes of 24 and 28.
>>
>>
>> Thanks,
>> Manasi
>>
>>
>>
>> On Jul 15, 2018, at 10:45 AM, Ian Swett  wrote:
>>
>> If one uses existing fast crypto primitives to encode connection ID, the=
n
>> 16 bytes is a natural size, and there was interest in having an extra by=
te
>> for metadata(key rotation/length signaling/etc).
>>
>> Unfortunately, that leaves us with a gap somewhere, and a gap at the
>> beginning seemed the most natural at the time.
>>
>> On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi 
>> wrote:
>>
>>> Another issue I noticed with the size of connection id was with regards
>>> to parsing the header field. The current steps are:
>>>
>>> =C2=B7        Parse DCid length,
>>>
>>> =C2=B7        Add 3,
>>>
>>> =C2=B7        Parse DCid length
>>>
>>> =C2=B7        Add 3,
>>>
>>> =C2=B7        Read DCID
>>>
>>> =C2=B7        Read SCID.
>>>
>>>
>>>
>>> I really appreciate the fixed size length fields so we can know both
>>> destination and source Cid lengths in parallel. Implementing this in
>>> hardware has the following challenges though:
>>>
>>> a.      There are 12 unique length types for each of the CiDs. This
>>> means either more stages of serial processing, which would be slower. O=
r it
>>> means more logic for parallel processing.
>>>
>>> b.      In addition to this, the arithmetic logic to add 3 is a little
>>> more specialized than a logical operation, e...g.shift left.
>>>
>>>
>>>
>>> Therefore, I would like to understand the basis for having 12 different
>>> lengths and if there is a chance to simplify this logic, we can have a =
3
>>> bit length and shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. W=
ould the
>>> loss of longer CiD values from 15 to 18 be an issue?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Manasi
>>>
>>>
>>>
>>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel
>>> Fahn=C3=B8e J=C3=B8rgensen
>>> *Sent:* Tuesday, July 03, 2018 6:06 AM
>>> *To:* QUIC WG ; Marten Seemann 
>>> *Subject:* Re: Connection ID lengths 1, 2 and 3
>>>
>>>
>>>
>>> That is correct. Especially in low-power sensor mesh networks.
>>>
>>>
>>>
>>>
>>>
>>> On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com)
>>> wrote:
>>>
>>> First of all, I realise that I'm bringing this up late in the process,
>>> and maybe too late, since this would require a change to the invariants=
.
>>>
>>>
>>>
>>> The connection IDs can be either 0 bytes or anything between 4 and 18
>>> bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.
>>>
>>> For p2p applications, and for server deployments that are not doing
>>> connection ID based load balancing, it would be interesting to use shor=
ter
>>> connection IDs. One might imagine that a peer encodes the length of the
>>> connection ID into the first few bits, and then starts using 1 byte
>>> connection IDs first, and successively moves to longer lengths only whe=
n
>>> handling more connections. A p2p host handling several thousand
>>> simultaneous connections (which will be enough for many p2p protocols)
>>> would never have to use anything longer than 2 byte connection IDs.
>>>
>>>
>>>
>>> In the connection ID length field in the Long Header, we only have to 4
>>> bit to encode a range of 19 values (we want 0 byte connection IDs, and =
we
>>> want to support 18 byte connection IDs), so *some* values have to be le=
ft
>>> out. However, leaving out 1, 2 and 3 seems a bit unfortunate, as there =
will
>>> be more use cases for these values than e.g. for 13, 14 and 15 bytes.
>>>
>>>

--00000000000063bbaa05710d6d1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Sun, Jul 15, 2018 at 10:04 AM, Deval, Manasi <ma=
nasi.deval@intel.com> wrote:






There is a 32bit version number that precedes the length field. Until we ha=
ve a thousand versions, we are always sending 3 extra bytes on the wire.=C2=
=A0


Well, the current version actually h=
as the high bit set.



Thanks,


Manasi




On Jul 15, 2018, at 12:52 PM, Marten =C2=A0<martenseemann@gmail.com> wrote:










I don't think we should reduce the number of sizes ava=
ilable. Sending bytes on the wire is orders of magnitude more expensive tha=
n performing a simple transformation to a parsed value. I'd prefer if w=
e could discuss this separately, since this
 is quite the opposite of what I was originally proposing.






To reiterate my argument, changing the invariants such that the values=
 1, 2 and 3 can be used would be a big benefit for p2p applications, since =
they would be able to use super-short connection IDs. Since this is a chang=
e that requires a change to the
 invariants, we need to make this decision very soon, if we want to enable =
this use case of QUIC.








On Sun, Jul 15, 2018 at 12:41 PM Deval, Manasi <manasi.deval@intel.com=
> wrote:






I would still prefer if we can reduce the number of sizes=
 supported.=C2=A0






Could a scheme where we support only 5 cids be used? Use a 3 bit size =
, shift left by 2 and not use the last 2 sizes of 24 and 28.














Thanks,


Manasi

















On Jul 15, 2018, at 10:45 AM, Ian Swett <ianswett@google.com> wrote:










If one uses existing fast crypto primitives to encode conn=
ection ID, then 16 bytes is a natural size, and there was interest in havin=
g an extra byte for metadata(key rotation/length signaling/etc).






Unfortunately, that leaves us with a gap somewhere, and a gap at the b=
eginning seemed the most natural at the time.








On Sun, Jul 15, 2018 at 10:35 AM Deval, Manasi <manasi.deval@intel.com=
> wrote:










Another issue I noticed with the size=
 of connection id was with regards to parsing the header field. The current=
 steps are:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Parse DCid length,



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Add 3,



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Parse DCid length<=
/span>


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Add 3,


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Read DCID

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Read SCID.<=
/p>

=C2=A0


I really appreciate the fixed size le=
ngth fields so we can know both destination and source Cid lengths in paral=
lel. Implementing this in hardware has the following
 challenges though:


a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
There are 12 unique length types=
 for each of the CiDs. This means either more stages of serial processing, =
which would be slower. Or it means more logic
 for parallel processing. 


b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
In addition to this, the arithme=
tic logic to add 3 is a little more specialized than a logical operation, e=
...g.shift left.



=C2=A0


Therefore, I would like to understand=
 the basis for having 12 different lengths and if there is a chance to simp=
lify this logic, we can have a 3 bit length and
 shift left 1, so we have lengths of 0,2,4=E2=80=A6 14. Would the loss of l=
onger CiD values from 15 to 18 be an issue?



=C2=A0


Thanks,


Manasi


=C2=A0=







From: Q=
UIC [mailto:quic=
-bounces@ietf.org]
On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen

Sent: Tuesday, July 03, 2018 6:06 AM

To: QUIC WG <q=
uic@ietf.org>; Marten Seemann <martenseemann@gmail.com>

Subject: Re: Connection ID lengths 1, 2 and 3





=C2=A0




That is correct. Especially in low-power sensor m=
esh networks.








=C2=A0






=C2=A0


On 3 July 2018 at 14.45.30, Marten Seemann (martenseemann@gmail.com)
 wrote:












First of all, I realise that I'm bringing thi=
s up late in the process, and maybe too late, since this would require a ch=
ange to the invariants.






=C2=A0






The connection IDs can be either 0 bytes or anyth=
ing between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not=
 possible.






For p2p applications, and for server deployments =
that are not doing connection ID based load balancing, it would be interest=
ing to use shorter connection IDs. One might imagine
 that a peer encodes the length of the connection ID into the first few bit=
s, and then starts using 1 byte connection IDs first, and successively move=
s to longer lengths only when handling more connections. A p2p host handlin=
g several thousand simultaneous
 connections (which will be enough for many p2p protocols) would never have=
 to use anything longer than 2 byte connection IDs.





=C2=A0






In the connection ID length field in the Long Hea=
der, we only have to 4 bit to encode a range of 19 values (we want 0 byte c=
onnection IDs, and we want to support 18 byte
 connection IDs), so *some* values have to be left out. However, leaving ou=
t 1, 2 and 3 seems a bit unfortunate, as there will be more use cases for t=
hese values than e.g. for 13, 14 and 15 bytes.














































--00000000000063bbaa05710d6d1b--


From nobody Sun Jul 15 12:15:11 2018
Return-Path: 
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 1989D130EB4 for ; Sun, 15 Jul 2018 12:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Level: 
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KuOa-EkXVDSN for ; Sun, 15 Jul 2018 12:14:55 -0700 (PDT)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24928130EDF for ; Sun, 15 Jul 2018 12:14:55 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 12:14:54 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos; i="5.51,358,1526367600"; d="scan'208,217"; a="54543203"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by fmsmga007.fm.intel.com with ESMTP; 15 Jul 2018 12:14:54 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX110.amr.corp.intel.com ([169.254.10.244]) with mapi id 14.03.0319.002; Sun, 15 Jul 2018 12:14:53 -0700
From: "Deval, Manasi" 
To: Subodh Iyengar 
CC: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "Eric Rescorla" , Kazuho Oku , Jana Iyengar , Praveen Balasubramanian , "Ian Swett" , Marten Seemann , "IETF QUIC WG" , Martin Thomson 
Subject: Re: Proposal to replace ACK block count with ACK length
Thread-Topic: Proposal to replace ACK block count with ACK length
Thread-Index: AdP8YgwJ2vNnJzEFTfGDVpW0S5D9xAFc4mOAAA2Oe4AAC1gQUACxPCCAAAyM/YAAAWbSgAABAJmAAAUhF4AAJqV6gAAHDGIAABvs+wAAAXoxAAAAa3CAAABfXoAAAUH10ABdzFywAA7X+IAADpdCoAAAtMWAABL8DbAAVdcngAATwqWAAAPVigAAApb0gAK6iKdQAcxCLYD//6wwow==
Date: Sun, 15 Jul 2018 19:14:52 +0000
Message-ID: 
References: <1F436ED13A22A246A59CA374CBC543998B832414@ORSMSX111.amr.corp.intel.com> <20180611154244.GA27622@ubuntu-dmitri>  <1F436ED13A22A246A59CA374CBC543998B833B91@ORSMSX111.amr.corp.intel.com>            <1F436ED13A22A246A59CA374CBC543998B83AB21@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B83EC27@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B83EF15@ORSMSX111.amr.corp.intel.com>  <1F436ED13A22A246A59CA374CBC543998B843873@ORSMSX111.amr.corp.intel.com>    , <1F436ED13A22A246A59CA374CBC543998B86D457@ORSMSX111.amr.corp.intel.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_ABCEEAFC0EE548F9939BE0F819507BE1intelcom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 19:15:08 -0000

--_000_ABCEEAFC0EE548F9939BE0F819507BE1intelcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I think if ACKs are sent every 20 to 40 packets, they require the segmentat=
ion code to care about them.

Also from talking to various folks I heard different things. Some implement=
ations like to piggyback the ack with data while others keep ACK separate. =
In my understanding, the piggybacked ask is used for bandwidth restricted c=
ases where they avoid padding.

This is also an excellent question for the implementers and deployers on th=
is list.

Thanks,
Manasi


On Jul 15, 2018, at 1:15 PM, Subodh Iyengar > wrote:


Hi Manasi,

Doesn't the segmentation make more sense for stream frames than ACK frames?=
 ACK frames are not sent very often and at least in production what we've s=
een is that most of the time ACKs naturally end up getting sent in their ow=
n pure ACK packets.

Not arguing for or against the length prefix design, but trying to understa=
nd why having a length prefix in the ACK frame helps segmentation for strea=
m frames even on the recv side.


Subodh

________________________________
From: QUIC > on behalf =
of Deval, Manasi >
Sent: Saturday, July 14, 2018 8:35:14 PM
To: 'Mikkel Fahn=F8e J=F8rgensen'; Eric Rescorla; Kazuho Oku
Cc: Jana Iyengar; Praveen Balasubramanian; Ian Swett; Marten Seemann; IETF =
QUIC WG; Martin Thomson
Subject: RE: Proposal to replace ACK block count with ACK length


Hi All,



I would like to revisit this discussion in the context of distributed proce=
ssing. The distributed processing doesn=92t only apply to multi-threading b=
ut also to layered processing.



One example of layered processing is segmentation. The current Chromium imp=
lementation currently creates the segments and passes them as a bunch into =
the Linux kernel. There is a GSO patch that would chop at the segment bound=
ary and encapsulate in UDP headers. We can further improve performance by p=
lugging in a smarter segmentation algorithm such that the segment processin=
g can account for type of frame, its size and make intelligent boundary and=
 padding decisions at a lower layer or in an offload. To this end, the algo=
rithm needs to identify the size of each of the frames. Having an ACK lengt=
h that can be determined in a single read is much more efficient than havin=
g to do a series of reads.



Thanks,

Manasi



From: Mikkel Fahn=F8e J=F8rgensen [mailto:mikkelfj@gmail.com]
Sent: Friday, June 22, 2018 9:15 AM
To: Eric Rescorla >; Kazuho Oku >
Cc: Jana Iyengar >; IETF QUIC=
 WG >; Deval, Manasi >; Marten Seemann >; Martin Thomson >; Ian Swett >; Praveen Balasubramanian >
Subject: Re: Proposal to replace ACK block count with ACK length



Another option is to write out frames as is without length except as needed=
 for varints. When a packet is nearly done, a run-length encoded frame inde=
x is placed in the packet tail. It could also include the frame types. A re=
ader can now directly find or skip ACK frames and the writer does not have =
to compute lengths before writing. Of course, the reader needs to be able t=
o locate the index at the tail which can be tricky with coalesced packets, =
but not impossible. Isn=92t this largely how zip-files work?



Mikkel



On 22 June 2018 at 17.00.52, Mikkel Fahn=F8e J=F8rgensen (mikkelfj@gmail.co=
m) wrote:

As I said earlier, I also favour a length prefix. But, Ian does have a poin=
t:



Writing data is generally more expensive than reading data. Especially if y=
ou have to traverse long data structures to find the length before you can =
start writing and/or you may have to conservatively reserve extra space for=
 a length field.



So before deciding one way or the other, the cost of writing needs to be we=
ll understood, also in scenarios with large MTU=92s.



In the flatbuffers space that I=92m involved with, streaming has turned to =
be an issue because data cannot be transmitted in parts without index data =
on a separate channel to recombined fragments. A simple, but non-standard, =
change in the format would fix this. JSON and CoAP allows streaming, but ma=
ny other formats do not, including later versions of protocol buffers, as I=
 understand.



An odd consequence of making both read and write efficient is that length b=
etter work better if stored at the end and packets read backwards. This req=
uires a single total length prefix but this is stored in the datagram heade=
r. This is probably too odd-ball, but still a consideration worth noting.



The second best alternative may therefore be to allow writes to be fast and=
 reads to be decent.



Yet, I still like length prefixes if they could be made write efficient bec=
ause high performance low-latency processes care zero about ACK and can con=
sume a packet directly while a background process handles all the latency i=
nsensitive ACK and retransmission logic.



The question is also, where is the pressure: an IoT aggregator might be mas=
sively read intensive while a web cache would be very write intensive.





Kind Regards,

Mikkel Fahn=F8e J=F8rgensen



On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com) wrote:

It seems like there are two questions at hand here:



1. Would it be architecturally better to have frames have a consistent self=
-contained

representation?

2. Is it enough better that we should do so now.



I agree with Kazuho that (a) we don't have that representation now and (b) =
it would

be a better design to do so. I'm perhaps somewhat more positive on (2) than=
 he

is. I don't think it's critically important that we make the change, but if=
 we were

to hold a consensus call, I think I would be in favor. I'd certainly be int=
erested

in looking at a proposal if someone else were to make one.



-Ekr







On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku > wrote:

2018-06-22 8:08 GMT+09:00 Deval, Manasi >:
> I feel that the requirement to have every value valid is somewhat academi=
c.

I think that Marten is correct in pointing out that making the ACK
frame self-containing (by having a field that represents the number of
octets being consumed by the frame) would be an exception from the
design pattern we have.

Look at STREAM frame. The field is not self-contained. Instead, it has
a Length field for the Stream Data, which is a leaf. The same goes for
NEW_CONNECTION_ID frame (that has the length field for Connection ID
field (which is also a leaf)), CONNECTION_CLOSE (length field for
Reason Phase).

I agree with Marten, Mikkel (and possibly others as well) that having
consistency is important.

Therefore, I agree with Mikkel that we should consider making every
frame self-contained or keeping every frame as-is (i.e. not
self-contained).

FWIW, as described in the latter half of
https://www.ietf.org/mail-archive/web/quic/current/msg04287.html, it
is possible to make every frame self-contained *and* also make ACK
frames smaller than the current draft. Making every frame
self-contained gives us the possibility to send new extension frames
without negotiation.

I do not think that I would push for making every frame self-contained
by myself (because I do not think it meets the high bar to have a
change at such a late moment of standardization), but as stated, my
preference goes to seeing every frame made self-contained or none of
them made as such.

> The length value provides much more value than the block count and the fa=
ct
> that certain values can never be achieved is an inherent property of the
> length.
>
>
>
> One interesting observation is that this property is not limited to lengt=
h.
> One can even make a similar argument about ACK block count. The maximum
> number of ACK blocks that can be defined will not always have a meaningfu=
l
> value. In out examples, 0,1,2,3 are all valid. If I set the value of ACK
> block count to have lower two bits to be 11, the maximum value is of ACK
> blocks is =96 4611686018427387903. This is the same value of largest
> acknowledged so if the ACK block count was set to this value, it would st=
ill
> be meaningless.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Tuesday, June 19, 2018 6:44 PM
> To: Deval, Manasi =
>
> Cc: Ian Swett >; Kazuho O=
ku >; Eric
> Rescorla >; Jana Iyengar >; Praveen
> Balasubramanian >; IETF Q=
UIC WG >; Martin
> Thomson >
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Hi Manasi,
>
>
>
>> The risk of disagreement between ack blocks and ack block count is same =
as
>> the risk of disagreement between ack blocks and ack length. Either way t=
his
>> needs to be counted up while creating the ACK and counted down while par=
sing
>> it. The possibility of error is the same. Getting the ack block count wr=
ong
>> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
> I disagree. Let's take an example of an ACK frame with one ACK range, tha=
t
> needs a 2 byte varint to represent the First ACK Block and another 2 byte
> varint to represent the Gap.
>
> With your proposal:
>
> The values 0 and 1 are invalid, since the length fields itself is include=
d
> in the length.
> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckDelay)) - 1 =
are
> invalid, since the length needs to include the Largest Acknowledged and t=
he
> Ack Delay.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) would be the first
> valid value, and correspond to an ACK frame with no blocks.
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1 is invalid, si=
nce
> it would cut the varint for the First ACK Block
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2 is invalid, si=
nce
> it would cut the frame after the First ACK Block (but every block must be
> followed by a gap length)
> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3 is invalid, si=
nce
> it would cut the varint for the Gap
> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay) + 4 is va=
lid
>
> There are *a lot* of invalid values that you can encode into the ACK leng=
th
> field. More importantly, *none* of these error cases exists with the curr=
ent
> frame format.
>
> The *only* error case that can occur with our current format is that the
> packet is too short for the number of ACK blocks that are supposed to
> contained in the frame. This can occur with your proposal as well (in
> addition to the error cases listed above).
>
>
>
> My concern is not that it's impossible or even particularly hard to catch
> these errors, but I dislike the property that some (in fact, most) encoda=
ble
> values are invalid.
>
>
>
> Best,
>
> Marten
>
>
>
>
>
> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi >
> wrote:
>
> Hi Ian,
>
>
>
> Here is another attempt to solve the objections you raised:
>
>
>
>>I'm not a fan of this proposal, because I think it is impractical to drop
>> the number of ack blocks, because with the ECN proposal it becomes
>> impractically complex to parse.
>
> Is there a reason the proposal from Christian does not solve this problem=
?
>
>
>
>>If we don't remove the number of ack blocks, then the ack frame is larger=
,
>> but I don't think the extra size field is useful for most implementation=
s.
>> Also, it means the length can disagree with the actual length, which add
>> complexity and the possibility of writing error-prone code.  The idea of
>> someone offloading ack processing and then proceeding to trust the lengt=
h
>> seems like someone could get wrong and cause some concerning issues.
>
> The risk of disagreement between ack blocks and ack block count is same a=
s
> the risk of disagreement between ack blocks and ack length. Either way th=
is
> needs to be counted up while creating the ACK and counted down while pars=
ing
> it. The possibility of error is the same. Getting the ack block count wro=
ng
> is as problematic as getting the ack length wrong. Do you agree?
>
>
>
>>My experience is multithreaded packet processing is more cost and work th=
an
>> it's worth.  Sure you can't fill a 100G NIC with one connection, but tha=
t
>> seems like an academic problem, not one for workloads I've seen.  Typica=
lly
>> the extra cost of multithreading outweighs its value.
>
> The value is two fold =96 pre-processing and multi-threading. If we
> pre-process the received packets such that ACKs and streams can be
> coalesced, the receive side can indicate a large chunk of information tho=
ugh
> the kernel, reducing the cost of system call and protocol overhead. This =
is
> the same concept as UDP segmentation taken a step further on receive side=
.
> After this chunk is indicated into the QUIC protocol, the protocol may
> process stream and ACK in parallel. While folks may or may not utilize th=
is,
> there is an advantage here.
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Ian Swett [mailto:ianswett@google.com]
> Sent: Tuesday, June 19, 2018 11:26 AM
> To: Deval, Manasi =
>
> Cc: Marten Seemann >; Kazuho Oku
> >; Eric Rescorla >; Jana Iyengar
> >; Praveen Balasubramanian =
>; IETF
> QUIC WG >; Martin Thomson >
>
>
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> I'm still not interested in this change, for the reasons I stated above.
>
>
>
> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi >
> wrote:
>
> Hi All,
>
>
>
> Do we have agreement here to create a new PR?
>
>
>
> Thanks,
>
> Manasi
>
>
>
> From: Deval, Manasi
> Sent: Sunday, June 17, 2018 2:25 PM
> To: Marten Seemann >; Kazuho Oku
> >
> Cc: Ian Swett >; Eric Rescorla
> >; Jana Iyengar >; Praveen Balasubramanian
> >; IETF QUIC WG >; Martin Thomson
> >
> Subject: RE: Proposal to replace ACK block count with ACK length
>
>
>
> Hi All,
>
>
>
> I have made a list of objections to the proposal and the solutions to tho=
se
> objections discussed on this thread.
>
>
>
> a.      Co-existence of length field with ECN field and ACK blocks.
>
>
>
> Christian suggested to move the ECN fields to precede the ACK blocks. Thi=
s
> is an elegant solution. Parsing entire list of ACK blocks to review ECN b=
its
> would have been annoying, even though it can work.
>
>
>
> b.      There are two cases to be parsed =96 entire ACK and parse ACK to
> identify length. There are some reservations when ACK parsing gets harder
> for the case where the entire header needs to be parsed.
>
>
>
> Agreement from several folks here. In the original ACK defined in draft 1=
2
> of the slide, one would count down number of ACK blocks to get to the end=
 of
> the packet. In the proposal I made, one would count down the length to
> identify the end of the packet. The logic is very similar in cycle count =
and
> complexity. Several folks also commented to this effect.
>
>
>
> c.      Multi-threaded packet processing
>
>
>
> I would expect that there are 10s of 1000s of connections in use at any t=
ime
> for a server with a high speed link. Multi-threading to handle each of th=
ese
> flows / connections in parallel is necessity to be able to support large
> number of connections on a high speed link. Tx segmentation, Rx coalescin=
g
> are well known strategies to reduce the processing cost. In initial stage=
s,
> code is often written as a single-threaded and then re-factored to
> parallelize cycle intensive operations. In order to allow this protocol t=
o
> scale in future, I would suggest we do not preclude this case.
>
>
>
> d.      Increase in ACK size by 1 byte.
>
>
>
> I do not see this as a serious issue but if folks but we can consider mak=
ing
> this a varint, if others have strong feelings about it. It=92s a trade-of=
f : 2
> reads to save 1 byte.
>
>
>
> e.      Every encodable value should be valid
>
> Not every length will be valid. This is inherent to lengths. This same is=
sue
> ails the =91payload length=92 in QUIC header. Not only does the issue exi=
st for
> small values, it also applies to large values since data stream will be s=
ent
> after crypto negotiation.  E.g.  - how does one craft a payload with 62 b=
it
> payload length in a large header?
>
>
>
>
>
> Thanks,
>
> Manasi
>
>
>
>
>
> From: Marten Seemann [mailto:martenseemann@gmail.com]
> Sent: Sunday, June 17, 2018 6:59 AM
> To: Kazuho Oku >
> Cc: Ian Swett >; Eric Rescorla
> >; Jana Iyengar >; Praveen Balasubramanian
> >; IETF QUIC WG >; Martin Thomson
> >; Deval, Manas=
i >
> Subject: Re: Proposal to replace ACK block count with ACK length
>
>
>
> Maybe it's specific to Go, but I'm using a single io.Reader for the whole
> packet, so as long as the packet payload is long enough, the varint parsi=
ng
> will not fail.
>
> I don't think that specifics of programming languages matter here though,
> and I'm sure both frame formats can be reasonably implemented in C as wel=
l
> as in Go. The reasons I'm opposed to Manasi's proposal are that it moves =
us
> away from the principle that only reasonable values should be encodable, =
and
> that it increases the size of the ACK frame, for the questionable benefit=
 of
> being able to parallelise the frame parser.
>
>
>
> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku > wrote:
>
> 2018-06-17 22:36 GMT+09:00 Marten Seemann >:
>> At least for my implementation, parsing doesn't become easier, it become=
s
>> more complex with this proposal. My varint-parser always consumes as man=
y
>> bytes as the varint requires, so after parsing a varint, I'd have to
>> introduce an additional check that this didn't overflow the ACK length
>> (e.g.
>> consider that I parsed the ACK frame so far that only 2 bytes are
>> remaining
>> according to ACK length field, but the next varint is 4 bytes long).
>
> Isn't your varint parser checking that it has not (or will not) run
> across the end of the packet payload for every ACK block it parses?
> I'd assume that you would be doing that, because I think that is
> necessary to avoid buffer overrun.
>
> What I am saying that that check could be converted to a overrun check
> against the end of the "frame payload", and that checking the
> remaining block count becomes unnecessary, in case we replace ACK
> Block Count with ACK Frame Length.
>
>>
>> In general, we've been moving the wire image towards making every
>> encodable
>> value valid. This proposal moves us away from that principle:
>> * some small values are always invalid (the length can never be between =
0
>> and 3)
>> * a lot of intermediate values are invalid (if the boundary falls inside=
 a
>> varint, as described above)
>> Both these cases can't occur with the current ACK frame format..
>>
>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku > wrote:
>>>
>>> 2018-06-17 8:34 GMT+09:00 Ian Swett
>>> >:
>>> > I'm not a fan of this proposal, because I think it is impractical to
>>> > drop
>>> > the number of ack blocks, because with the ECN proposal it becomes
>>> > impractically complex to parse.
>>>
>>> For the ECN proposal, as Christian has suggested, we can move the ECN
>>> counters before the ACK blocks. Then, it would not be complex to
>>> parse.
>>>
>>> And my view is that parsing becomes easier if we replace ACK Block
>>> Count with ACK Frame Length.
>>>
>>> Now, with ACK Block Count, we need to check the remaining number of
>>> blocks and the remaining space in the packet payload for every block
>>> that we parse. Failing to check either leads to a bug or a security
>>> issue.
>>>
>>> If we switch to ACK Frame Length, we need to only check the remaining
>>> space in the frame.
>>>
>>> I think that this is the biggest benefit of replacing ACK Block Count
>>> with ACK Frame Length. OTOH the downside is that you need extra one to
>>> two bits (one if the size of block / gap is expected to be below 65,
>>> two if they are expected to be above that) for encoding ACK Frame
>>> Length compared to ACK Block Count.
>>>
>>>
>>>
>>> Having said that, I honestly wonder if all the frames could have it's
>>> length being encoded (either explicitly or either as a signal that
>>> says "to the end of the packet"). Consider something like below:
>>>
>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload (*) |
>>>  or
>>> |1| frame-type (7) | frame-payload (*) |
>>>
>>> When MSB of the first octet set to zero, the length of the frame
>>> payload is designated by the varint that immediately follows the frame
>>> type.
>>> When MSB of the first octet set to one, the length of the frame
>>> payload spans to the end of the packet.
>>>
>>> In this encoding, we can always omit the Length field of a STREAM
>>> frame. So the overhead for carrying stream data will be indifferent in
>>> practice.
>>>
>>> For the ACK frame, we can omit the ACK Block Count field. And the
>>> overhead will be one to two bits if the ACK frame is sent in the
>>> middle of the packet (thereby using the encoding with explicit frame
>>> payload length), or one octet or more shorter if ACK is the last frame
>>> of the packet.
>>>
>>> We are likely to see increase of overhead for most of the other types
>>> of frames, but I do not think that would be an issue considering that
>>> they will be far seldom seen compared to STREAMs and ACKs.
>>>
>>> To summarize, my anticipation is that we can make all the frames
>>> self-contained (i.e. the length can be determined without the
>>> knowledge of how each frame is encoded) without any overhead, if we
>>> agree on making the frame type space 1 bit smaller.
>>>
>>> Finally, the biggest benefit of using a self-contained encoding of
>>> frames is that we would have the ability to introduce new optional
>>> frames without negotiation. By making the frames self-contained, QUIC
>>> endpoints will have the freedom of ignoring the frames that they do
>>> not understand.
>>>
>>> Being able to send QUIC frames defined in extensions without
>>> negotiating using Transport Parameters will be a win in both terms of
>>> security (because clients' TP is sent in clear) and flexibility
>>> (because we will be possible to send the extensions before we figure
>>> out whether the peer supports that extension).
>>>
>>> > If we don't remove the number of ack blocks, then the ack frame is
>>> > larger,
>>> > but I don't think the extra size field is useful for most
>>> > implementations.
>>> > Also, it means the length can disagree with the actual length, which
>>> > add
>>> > complexity and the possibility of writing error-prone code.  The idea
>>> > of
>>> > someone offloading ack processing and then proceeding to trust the
>>> > length
>>> > seems like someone could get wrong and cause some concerning issues.
>>> >
>>> > My experience is multithreaded packet processing is more cost and wor=
k
>>> > than
>>> > it's worth.  Sure you can't fill a 100G NIC with one connection, but
>>> > that
>>> > seems like an academic problem, not one for workloads I've seen.
>>> > Typically
>>> > the extra cost of multithreading outweighs its value.
>>> >
>>> > To be clear, I don't think this is an awful idea, but I also don't se=
e
>>> > the
>>> > value and it adds complexity.  I read Manasi's email, but I don't thi=
nk
>>> > I
>>> > understand why any of those matter in practice.
>>> >
>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla > wrote:
>>> >>
>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann
>>> >> >
>>> >> wrote:
>>> >>>
>>> >>> This proposal increases the size of the ACK frame by 1 byte in the
>>> >>> common
>>> >>> case (less than 63 ACK ranges), since the ACK length field here
>>> >>> always
>>> >>> consumes 2 bytes, whereas the ACK Block Count is a variable-length
>>> >>> integer.
>>> >>> Considering how much work we put into minimising the size of the
>>> >>> frames,
>>> >>> this feels like a step in the wrong direction..
>>> >>>
>>> >>> Regarding the processing cost, I agree with Dmitri. Handling an ACK
>>> >>> frame
>>> >>> requires looping over and making changes to a data structure that
>>> >>> keeps
>>> >>> track of sent packets. This is much more expensive than simply
>>> >>> parsing
>>> >>> a
>>> >>> bunch of varints in the ACK frame. It seems unlikely that a
>>> >>> multi-threaded
>>> >>> packet parser would offer any real-world performance benefits.
>>> >>
>>> >>
>>> >> I don't want to overstate the benefit here, but my point isn't that
>>> >> parsing is expensive but that if you want to have a multithreaded
>>> >> packet
>>> >> processing system, then it's nice to have a simpler data structure
>>> >> (the
>>> >> unparsed ACK block) to hand to the ACK processing thread.
>>> >>
>>> >> -Ekr
>>> >>
>>> >>
>>> >>>
>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>>> >>> >
>>> >>> wrote:
>>> >>>>
>>> >>>> When we discussed this before, some people observed that this
>>> >>>> creates
>>> >>>> a need to encode in two passes.  That's the trade-off here.  (Not
>>> >>>> expressing an opinion.)
>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar >
>>> >>>> wrote:
>>> >>>> >
>>> >>>> > I don't have a strong opinion on this. I'm certainly not opposed
>>> >>>> > to
>>> >>>> > it.
>>> >>>> > Does anyone have a strong opposition?
>>> >>>> >
>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen Balasubramanian
>>> >>>> > > wrote:
>>> >>>> >>
>>> >>>> >> I agree as well since this can help reduce per packet processin=
g
>>> >>>> >> overhead. ACKs are going to be the second most common frame typ=
e
>>> >>>> >> so no
>>> >>>> >> objections to special casing.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric
>>> >>>> >> Rescorla
>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM
>>> >>>> >> To: Deval, Manasi >
>>> >>>> >> Cc: Jana Iyengar =
>; QUIC WG >
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK lengt=
h
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> I agree with Manasi here. This change would allow ack frame
>>> >>>> >> parsing
>>> >>>> >> to be more self-contained, which is an advantage for the parser
>>> >>>> >> and also
>>> >>>> >> potentially for parallelism (because you can quickly find the
>>> >>>> >> frame and then
>>> >>>> >> process it in parallel).
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> -Ekr
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Deval, Manasi
>>> >>>> >> > wrote:
>>> >>>> >>
>>> >>>> >> In general, varints require some specific logic for parsing. To
>>> >>>> >> skip
>>> >>>> >> over any header, I have to read every single varint. As the cod=
e
>>> >>>> >> sees Stream
>>> >>>> >> and ACK headers most frequently, that is my focus.  The Stream
>>> >>>> >> frame has a
>>> >>>> >> length in its third field.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> ACK parsing, however, needs 6 + 2*num_blocks reads to identify
>>> >>>> >> length. There are two reads each for =91largest acknowledged=92=
, =91ACK
>>> >>>> >> delay=92 and
>>> >>>> >> =91ACK block count=92. The pain point is the total number of cy=
cles
>>> >>>> >> parse an
>>> >>>> >> ACK. If I am processing 10M pps, where 10% - 30% of the packets
>>> >>>> >> have a
>>> >>>> >> piggybacked ACK, these cycles becomes a significant bottleneck.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> Thanks,
>>> >>>> >>
>>> >>>> >> Manasi
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana
>>> >>>> >> Iyengar
>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM
>>> >>>> >> To: Deval, Manasi >; QUIC WG
>>> >>>> >> >
>>> >>>> >> Subject: Re: Proposal to replace ACK block count with ACK lengt=
h
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> You're right that we no longer have the ability to skip an ACK
>>> >>>> >> frame,
>>> >>>> >> and this crept in when we moved to varints.
>>> >>>> >>
>>> >>>> >> I believe your problem though is generally true of most frames
>>> >>>> >> not
>>> >>>> >> just ACKs, since ids, packet numbers, and numbers in all frames
>>> >>>> >> are now all
>>> >>>> >> varints. To skip any frame, you'll need to parse the varint
>>> >>>> >> fields
>>> >>>> >> in those
>>> >>>> >> frames. If you have logic to process and skip varints, then
>>> >>>> >> skipping the ack
>>> >>>> >> block section is merely repeating this operation (2*num_block+1=
)
>>> >>>> >> times. Do
>>> >>>> >> you see specific value in skipping ACK frames over the other
>>> >>>> >> control frames?
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmitri Tikhonov
>>> >>>> >>  wrote:
>>> >>>> >>
>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM +0000, Deval, Manasi wrote:
>>> >>>> >> > -        Moving the ACK length to the front of the ACK allows
>>> >>>> >> > the
>>> >>>> >> >          flexibility of either reading the entire ACK or
>>> >>>> >> > reading
>>> >>>> >> > the
>>> >>>> >> >          first 16 bits and skipping over the length. This is =
a
>>> >>>> >> > useful
>>> >>>> >> >          feature for the case where ACK processing is split
>>> >>>> >> > into
>>> >>>> >> >          multiple layers. Depending on the processor this is
>>> >>>> >> > run
>>> >>>> >> > on,
>>> >>>> >> >          there are different advantages -
>>> >>>> >>
>>> >>>> >> Just a note.  In my experience, the cost of parsing an ACK fram=
e
>>> >>>> >> is
>>> >>>> >> negligible compared to the cost of processing an ACK frame: tha=
t
>>> >>>> >> is,
>>> >>>> >> poking at various memory locations to discard newly ACKed
>>> >>>> >> packets.
>>> >>>> >>
>>> >>>> >>   - Dmitri.
>>> >>>> >>
>>> >>>> >>
>>> >>>>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Kazuho Oku
>
>
>
> --
> Kazuho Oku



--
Kazuho Oku



--_000_ABCEEAFC0EE548F9939BE0F819507BE1intelcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable






I think if ACKs are sent every 20 to 40 packets, they require the segmentat=
ion code to care about them. 






Also from talking to various folks I heard different things. Some impl=
ementations like to piggyback the ack with data while others keep ACK separ=
ate. In my understanding, the piggybacked ask is used for bandwidth restric=
ted cases where they avoid padding. 







This is also an excellent question for the implementers and deployers =
on this list.







Thanks,


Manasi











On Jul 15, 2018, at 1:15 PM, Subodh Iyengar <subodh@fb.com> wrote:












Hi Manasi,


Doesn't the segmentation make mor=
e sense for stream frames than ACK frames? ACK frames are not sent very oft=
en and at least in production what we've seen is that most of the time ACKs=
 naturally end up getting sent in
 their own pure ACK packets. 



Not arguing for or against the length prefix design, but trying to understa=
nd why having a length prefix in the ACK frame helps segmentation for strea=
m frames even on the recv side.







Subodh








From: QUIC <quic-bounces@ietf.org> on behalf of Dev=
al, Manasi <manasi.deval@intel=
.com>

Sent: Saturday, July 14, 2018 8:35:14 PM

To: 'Mikkel Fahn=F8e J=F8rgensen'; Eric Rescorla; Kazuho Oku

Cc: Jana Iyengar; Praveen Balasubramanian; Ian Swett; Marten Seemann=
; IETF QUIC WG; Martin Thomson

Subject: RE: Proposal to replace ACK block count with ACK length

 











Hi All,


 


I would like to revisit this discussion in the con=
text of distributed processing. The distributed processing doesn=92t only a=
pply to multi-threading but also to layered processing.



 


One example of layered processing is segmentation.=
 The current Chromium implementation currently creates the segments and pas=
ses them as a bunch into the Linux kernel. There
 is a GSO patch that would chop at the segment boundary and encapsulate in =
UDP headers. We can further improve performance by plugging in a smarter se=
gmentation algorithm such that the segment processing can account for type =
of frame, its size and make intelligent
 boundary and padding decisions at a lower layer or in an offload. To this =
end, the algorithm needs to identify the size of each of the frames. Having=
 an ACK length that can be determined in a single read is much more efficie=
nt than having to do a series of
 reads. 


 


Thanks,


Manasi


&nb=
sp;






From: Mikkel Fahn=F8e J=F8rgensen [mailto:mikkelfj@gmail.com]


Sent: Friday, June 22, 2018 9:15 AM

To: Eric Rescorla <ekr@rtfm.com>; Kazuho Oku <kazuhooku@gma=
il.com>

Cc: Jana Iyengar <jri.ietf@=
gmail.com>; IETF QUIC WG <quic@i=
etf.org>; Deval, Manasi <manasi.deval@intel.com>; Marten Seemann <martenseemann@gmail.com>;
 Martin Thomson <martin.thom=
son@gmail.com>; Ian Swett <ianswett@google.com>; Praveen Balasubramanian <pravb@microsoft.com>

Subject: Re: Proposal to replace ACK block count with ACK length






 




Another option is to write out frames as is wi=
thout length except as needed for varints. When a packet is nearly done, a =
run-length encoded frame index is placed in the
 packet tail. It could also include the frame types. A reader can now direc=
tly find or skip ACK frames and the writer does not have to compute lengths=
 before writing. Of course, the reader needs to be able to locate the index=
 at the tail which can be tricky
 with coalesced packets, but not impossible. Isn=92t this largely how zip-f=
iles work?








 






Mikkel






 


On 22 June 2018 at 17.00.52, Mikkel Fahn=F8e J=
=F8rgensen (mikkelfj@gmail=
.com)
 wrote:










As I said earlier, I also favour a length pref=
ix. But, Ian does have a point:






 






Writing data is generally more expensive than =
reading data. Especially if you have to traverse long data structures to fi=
nd the length before you can start writing and/or
 you may have to conservatively reserve extra space for a length field.






 






So before deciding one way or the other, the c=
ost of writing needs to be well understood, also in scenarios with large MT=
U=92s.






 






In the flatbuffers space that I=92m involved w=
ith, streaming has turned to be an issue because data cannot be transmitted=
 in parts without index data on a separate channel
 to recombined fragments. A simple, but non-standard, change in the format =
would fix this. JSON and CoAP allows streaming, but many other formats do n=
ot, including later versions of protocol buffers, as I understand.





 






An odd consequence of making both read and wri=
te efficient is that length better work better if stored at the end and pac=
kets read backwards. This requires a single total
 length prefix but this is stored in the datagram header. This is probably =
too odd-ball, but still a consideration worth noting.






 






The second best alternative may therefore be t=
o allow writes to be fast and reads to be decent.






 






Yet, I still like length prefixes if they coul=
d be made write efficient because high performance low-latency processes ca=
re zero about ACK and can consume a packet directly
 while a background process handles all the latency insensitive ACK and ret=
ransmission logic.






 






The question is also, where is the pressure: a=
n IoT aggregator might be massively read intensive while a web cache would =
be very write intensive.






 




 






Kind Regards,






Mikkel Fahn=F8e=
 J=F8rgensen






 


On 22 June 2018 at 15.12.09, Eric Rescorla (ekr@rtfm.com)
 wrote:












It seems like there are two questions at hand =
here:






 






1. Would it be architecturally better to have =
frames have a consistent self-contained






representation?






2. Is it enough better that we should do so no=
w.






 






I agree with Kazuho that (a) we don't have tha=
t representation now and (b) it would






be a better design to do so. I'm perhaps somew=
hat more positive on (2) than he






is. I don't think it's critically important th=
at we make the change, but if we were






to hold a consensus call, I think I would be i=
n favor. I'd certainly be interested






in looking at a proposal if someone else were =
to make one.






 






-Ekr






 






 








 




On Thu, Jun 21, 2018 at 8:45 PM, Kazuho Oku &l=
t;kazuh=
ooku@gmail.com>
 wrote:




2018-06-22 8:08 GMT+09:00 Deval, Manasi &l=
t;manasi.deval@intel.c=
om>:

> I feel that the requirement to have every value valid is somewhat acad=
emic.



I think that Marten is correct in pointing out that making the ACK

frame self-containing (by having a field that represents the number of

octets being consumed by the frame) would be an exception from the

design pattern we have.



Look at STREAM frame. The field is not self-contained. Instead, it has

a Length field for the Stream Data, which is a leaf. The same goes for

NEW_CONNECTION_ID frame (that has the length field for Connection ID

field (which is also a leaf)), CONNECTION_CLOSE (length field for

Reason Phase).



I agree with Marten, Mikkel (and possibly others as well) that having

consistency is important.



Therefore, I agree with Mikkel that we should consider making every

frame self-contained or keeping every frame as-is (i.e. not

self-contained).



FWIW, as described in the latter half of

https://www.ietf.org/mail-arch=
ive/web/quic/current/msg04287.html,
 it

is possible to make every frame self-contained *and* also make ACK

frames smaller than the current draft. Making every frame

self-contained gives us the possibility to send new extension frames

without negotiation.



I do not think that I would push for making every frame self-contained

by myself (because I do not think it meets the high bar to have a

change at such a late moment of standardization), but as stated, my

preference goes to seeing every frame made self-contained or none of

them made as such.








> The length value provides much more value than the block count and the=
 fact

> that certain values can never be achieved is an inherent property of t=
he

> length.

>

>

>

> One interesting observation is that this property is not limited to le=
ngth.

> One can even make a similar argument about ACK block count. The maximu=
m

> number of ACK blocks that can be defined will not always have a meanin=
gful

> value. In out examples, 0,1,2,3 are all valid. If I set the value of A=
CK

> block count to have lower two bits to be 11, the maximum value is of A=
CK

> blocks is =96 4611686018427387903. This is the same value of largest
> acknowledged so if the ACK block count was set to this value, it would=
 still

> be meaningless.

>

>

>

> Thanks,

>

> Manasi

>

>

>

>

>

>

>

> From: Marten Seemann [mailto:martenseemann@gmail.com]

> Sent: Tuesday, June 19, 2018 6:44 PM

> To: Deval, Manasi <manasi..deval@intel.com>

> Cc: Ian Swett <ia=
nswett@google.com>; Kazuho Oku <kazuhooku@gmail.com>;
 Eric

> Rescorla <ekr@rtfm.com>; Jana Iyengar <jri.ietf@gmail.com>;
 Praveen

> Balasubramanian <=
pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>;
 Martin

> Thomson <mar=
tin.thomson@gmail.com>

>

>

> Subject: Re: Proposal to replace ACK block count with ACK length

>

>

>

> Hi Manasi,

>

>

>

>> The risk of disagreement between ack blocks and ack block count is=
 same as

>> the risk of disagreement between ack blocks and ack length. Either=
 way this

>> needs to be counted up while creating the ACK and counted down whi=
le parsing

>> it. The possibility of error is the same. Getting the ack block co=
unt wrong

>> is as problematic as getting the ack length wrong. Do you agree?
>

>

>

> I disagree. Let's take an example of an ACK frame with one ACK range, =
that

> needs a 2 byte varint to represent the First ACK Block and another 2 b=
yte

> varint to represent the Gap.

>

> With your proposal:

>

> The values 0 and 1 are invalid, since the length fields itself is incl=
uded

> in the length.

> The values 2, 3, ..., (2 + len(LargestAcknowledged) + len(AckD=
elay)) - 1 are

> invalid, since the length needs to include the Largest Acknowledged an=
d the

> Ack Delay.

> The value 2 + len(LargestAcknowledged) + len(AckDelay) would b=
e the first

> valid value, and correspond to an ACK frame with no blocks.

> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 1=
 is invalid, since

> it would cut the varint for the First ACK Block

> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 2=
 is invalid, since

> it would cut the frame after the First ACK Block (but every block must=
 be

> followed by a gap length)

> The value 2 + len(LargestAcknowledged) + len(AckDelay) + 3=
 is invalid, since

> it would cut the varint for the Gap

> Finally, the value 2 + len(LargestAcknowledged) + len(AckDelay=
) + 4 is valid

>

> There are *a lot* of invalid values that you can encode into the ACK l=
ength

> field. More importantly, *none* of these error cases exists with the c=
urrent

> frame format.

>

> The *only* error case that can occur with our current format is that t=
he

> packet is too short for the number of ACK blocks that are supposed to<=
br>
> contained in the frame. This can occur with your proposal as well (in<=
br>
> addition to the error cases listed above).

>

>

>

> My concern is not that it's impossible or even particularly hard to ca=
tch

> these errors, but I dislike the property that some (in fact, most) enc=
odable

> values are invalid.

>

>

>

> Best,

>

> Marten

>

>

>

>

>

> On Wed, Jun 20, 2018 at 3:21 AM Deval, Manasi <manasi.deval@intel.com><=
br>
> wrote:

>

> Hi Ian,

>

>

>

> Here is another attempt to solve the objections you raised:

>

>

>

>>I'm not a fan of this proposal, because I think it is impractical t=
o drop

>> the number of ack blocks, because with the ECN proposal it becomes=


>> impractically complex to parse.

>

> Is there a reason the proposal from Christian does not solve this prob=
lem?

>

>

>

>>If we don't remove the number of ack blocks, then the ack frame is =
larger,

>> but I don't think the extra size field is useful for most implemen=
tations.

>> Also, it means the length can disagree with the actual length, whi=
ch add

>> complexity and the possibility of writing error-prone code.  =
The idea of

>> someone offloading ack processing and then proceeding to trust the=
 length

>> seems like someone could get wrong and cause some concerning issue=
s.

>

> The risk of disagreement between ack blocks and ack block count is sam=
e as

> the risk of disagreement between ack blocks and ack length. Either way=
 this

> needs to be counted up while creating the ACK and counted down while p=
arsing

> it. The possibility of error is the same. Getting the ack block count =
wrong

> is as problematic as getting the ack length wrong. Do you agree?

>

>

>

>>My experience is multithreaded packet processing is more cost and w=
ork than

>> it's worth.  Sure you can't fill a 100G NIC with one connecti=
on, but that

>> seems like an academic problem, not one for workloads I've seen.&n=
bsp; Typically

>> the extra cost of multithreading outweighs its value.

>

> The value is two fold =96 pre-processing and multi-threading. If we
> pre-process the received packets such that ACKs and streams can be

> coalesced, the receive side can indicate a large chunk of information =
though

> the kernel, reducing the cost of system call and protocol overhead. Th=
is is

> the same concept as UDP segmentation taken a step further on receive s=
ide.

> After this chunk is indicated into the QUIC protocol, the protocol may=


> process stream and ACK in parallel. While folks may or may not utilize=
 this,

> there is an advantage here.

>

>

>

> Thanks,

>

> Manasi

>

>

>

>

>

> From: Ian Swett [mailto:=
ianswett@google.com]

> Sent: Tuesday, June 19, 2018 11:26 AM

> To: Deval, Manasi <manasi..deval@intel.com>

> Cc: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku

> <kazuhooku@gmail.=
com>; Eric Rescorla <ekr@rtfm.com>;
 Jana Iyengar

> <jri.ietf@gmail.co=
m>; Praveen Balasubramanian <pravb@microsoft.com>;
 IETF

> QUIC WG <quic@ietf.org<=
/span>>; Martin Thomson <martin.thomson@gmail.com>

>

>

> Subject: Re: Proposal to replace ACK block count with ACK length

>

>

>

> I'm still not interested in this change, for the reasons I stated abov=
e.

>

>

>

> On Tue, Jun 19, 2018 at 2:21 PM Deval, Manasi <manasi.deval@intel.com><=
br>
> wrote:

>

> Hi All,

>

>

>

> Do we have agreement here to create a new PR?

>

>

>

> Thanks,

>

> Manasi

>

>

>

> From: Deval, Manasi

> Sent: Sunday, June 17, 2018 2:25 PM

> To: Marten Seemann <martenseemann@gmail.com>; Kazuho Oku

> <kazuhooku@gmail.=
com>

> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric
 Rescorla

> <ekr@rtfm.com=
>; Jana Iyengar <jri.ietf@gmail.com>;
 Praveen Balasubramanian

> <pravb@microsoft.=
com>; IETF QUIC WG <quic@ietf.org>;
 Martin Thomson

> <martin.thom=
son@gmail.com>

> Subject: RE: Proposal to replace ACK block count with ACK length

>

>

>

> Hi All,

>

>

>

> I have made a list of objections to the proposal and the solutions to =
those

> objections discussed on this thread.

>

>

>

> a.      Co-existence of length field with ECN field and=
 ACK blocks.

>

>

>

> Christian suggested to move the ECN fields to precede the ACK blocks. =
This

> is an elegant solution. Parsing entire list of ACK blocks to review EC=
N bits

> would have been annoying, even though it can work.

>

>

>

> b.      There are two cases to be parsed =96 entire ACK=
 and parse ACK to

> identify length. There are some reservations when ACK parsing gets har=
der

> for the case where the entire header needs to be parsed.

>

>

>

> Agreement from several folks here. In the original ACK defined in draf=
t 12

> of the slide, one would count down number of ACK blocks to get to the =
end of

> the packet. In the proposal I made, one would count down the length to=


> identify the end of the packet. The logic is very similar in cycle cou=
nt and

> complexity. Several folks also commented to this effect.

>

>

>

> c.      Multi-threaded packet processing

>

>

>

> I would expect that there are 10s of 1000s of connections in use at an=
y time

> for a server with a high speed link. Multi-threading to handle each of=
 these

> flows / connections in parallel is necessity to be able to support lar=
ge

> number of connections on a high speed link. Tx segmentation, Rx coales=
cing

> are well known strategies to reduce the processing cost. In initial st=
ages,

> code is often written as a single-threaded and then re-factored to

> parallelize cycle intensive operations. In order to allow this protoco=
l to

> scale in future, I would suggest we do not preclude this case.

>

>

>

> d.      Increase in ACK size by 1 byte.

>

>

>

> I do not see this as a serious issue but if folks but we can consider =
making

> this a varint, if others have strong feelings about it. It=92s a trade=
-off : 2

> reads to save 1 byte.

>

>

>

> e.      Every encodable value should be valid

>

> Not every length will be valid. This is inherent to lengths. This same=
 issue

> ails the =91payload length=92 in QUIC header. Not only does the issue =
exist for

> small values, it also applies to large values since data stream will b=
e sent

> after crypto negotiation.  E.g.  - how does one craft a payl=
oad with 62 bit

> payload length in a large header?

>

>

>

>

>

> Thanks,

>

> Manasi

>

>

>

>

>

> From: Marten Seemann [mailto:martenseemann@gmail.com]

> Sent: Sunday, June 17, 2018 6:59 AM

> To: Kazuho Oku <k=
azuhooku@gmail.com>

> Cc: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>; Eric
 Rescorla

> <ekr@rtfm.com=
>; Jana Iyengar <jri.ietf@gmail.com>;
 Praveen Balasubramanian

> <pravb@microsoft.=
com>; IETF QUIC WG <quic@ietf.org>;
 Martin Thomson

> <martin.thom=
son@gmail.com>; Deval, Manasi <manasi.deval@intel.com>
> Subject: Re: Proposal to replace ACK block count with ACK length

>

>

>

> Maybe it's specific to Go, but I'm using a single io.Reader for the wh=
ole

> packet, so as long as the packet payload is long enough, the varint pa=
rsing

> will not fail.

>

> I don't think that specifics of programming languages matter here thou=
gh,

> and I'm sure both frame formats can be reasonably implemented in C as =
well

> as in Go. The reasons I'm opposed to Manasi's proposal are that it mov=
es us

> away from the principle that only reasonable values should be encodabl=
e, and

> that it increases the size of the ACK frame, for the questionable bene=
fit of

> being able to parallelise the frame parser.

>

>

>

> On Sun, Jun 17, 2018 at 8:48 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>

> 2018-06-17 22:36 GMT+09:00 Marten Seemann <martenseemann@gmail.com>=
;:

>> At least for my implementation, parsing doesn't become easier, it =
becomes

>> more complex with this proposal. My varint-parser always consumes =
as many

>> bytes as the varint requires, so after parsing a varint, I'd have =
to

>> introduce an additional check that this didn't overflow the ACK le=
ngth

>> (e.g.

>> consider that I parsed the ACK frame so far that only 2 bytes are<=
br>
>> remaining

>> according to ACK length field, but the next varint is 4 bytes long=
).

>

> Isn't your varint parser checking that it has not (or will not) run
> across the end of the packet payload for every ACK block it parses?
> I'd assume that you would be doing that, because I think that is

> necessary to avoid buffer overrun.

>

> What I am saying that that check could be converted to a overrun check=


> against the end of the "frame payload", and that checking th=
e

> remaining block count becomes unnecessary, in case we replace ACK

> Block Count with ACK Frame Length.

>

>>

>> In general, we've been moving the wire image towards making every<=
br>
>> encodable

>> value valid. This proposal moves us away from that principle:

>> * some small values are always invalid (the length can never be be=
tween 0

>> and 3)

>> * a lot of intermediate values are invalid (if the boundary falls =
inside a

>> varint, as described above)

>> Both these cases can't occur with the current ACK frame format..
>>

>> On Sun, Jun 17, 2018 at 7:54 PM Kazuho Oku <kazuhooku@gmail.com>
 wrote:

>>>

>>> 2018-06-17 8:34 GMT+09:00 Ian Swett

>>> <ianswett=3D40google.com@dmarc.ietf.org>:

>>> > I'm not a fan of this proposal, because I think it is imp=
ractical to

>>> > drop

>>> > the number of ack blocks, because with the ECN proposal i=
t becomes

>>> > impractically complex to parse.

>>>

>>> For the ECN proposal, as Christian has suggested, we can move =
the ECN

>>> counters before the ACK blocks. Then, it would not be complex =
to

>>> parse.

>>>

>>> And my view is that parsing becomes easier if we replace ACK B=
lock

>>> Count with ACK Frame Length.

>>>

>>> Now, with ACK Block Count, we need to check the remaining numb=
er of

>>> blocks and the remaining space in the packet payload for every=
 block

>>> that we parse. Failing to check either leads to a bug or a sec=
urity

>>> issue.

>>>

>>> If we switch to ACK Frame Length, we need to only check the re=
maining

>>> space in the frame.

>>>

>>> I think that this is the biggest benefit of replacing ACK Bloc=
k Count

>>> with ACK Frame Length. OTOH the downside is that you need extr=
a one to

>>> two bits (one if the size of block / gap is expected to be bel=
ow 65,

>>> two if they are expected to be above that) for encoding ACK Fr=
ame

>>> Length compared to ACK Block Count.

>>>

>>>

>>>

>>> Having said that, I honestly wonder if all the frames could ha=
ve it's

>>> length being encoded (either explicitly or either as a signal =
that

>>> says "to the end of the packet"). Consider something=
 like below:

>>>

>>> |0| frame-type (7) | frame-payload-length (i) | frame-payload =
(*) |

>>>  or

>>> |1| frame-type (7) | frame-payload (*) |

>>>

>>> When MSB of the first octet set to zero, the length of the fra=
me

>>> payload is designated by the varint that immediately follows t=
he frame

>>> type.

>>> When MSB of the first octet set to one, the length of the fram=
e

>>> payload spans to the end of the packet.

>>>

>>> In this encoding, we can always omit the Length field of a STR=
EAM

>>> frame. So the overhead for carrying stream data will be indiff=
erent in

>>> practice.

>>>

>>> For the ACK frame, we can omit the ACK Block Count field. And =
the

>>> overhead will be one to two bits if the ACK frame is sent in t=
he

>>> middle of the packet (thereby using the encoding with explicit=
 frame

>>> payload length), or one octet or more shorter if ACK is the la=
st frame

>>> of the packet.

>>>

>>> We are likely to see increase of overhead for most of the othe=
r types

>>> of frames, but I do not think that would be an issue consideri=
ng that

>>> they will be far seldom seen compared to STREAMs and ACKs.

>>>

>>> To summarize, my anticipation is that we can make all the fram=
es

>>> self-contained (i.e. the length can be determined without the<=
br>
>>> knowledge of how each frame is encoded) without any overhead, =
if we

>>> agree on making the frame type space 1 bit smaller.

>>>

>>> Finally, the biggest benefit of using a self-contained encodin=
g of

>>> frames is that we would have the ability to introduce new opti=
onal

>>> frames without negotiation. By making the frames self-containe=
d, QUIC

>>> endpoints will have the freedom of ignoring the frames that th=
ey do

>>> not understand.

>>>

>>> Being able to send QUIC frames defined in extensions without
>>> negotiating using Transport Parameters will be a win in both t=
erms of

>>> security (because clients' TP is sent in clear) and flexibilit=
y

>>> (because we will be possible to send the extensions before we =
figure

>>> out whether the peer supports that extension).

>>>

>>> > If we don't remove the number of ack blocks, then the ack=
 frame is

>>> > larger,

>>> > but I don't think the extra size field is useful for most=


>>> > implementations.

>>> > Also, it means the length can disagree with the actual le=
ngth, which

>>> > add

>>> > complexity and the possibility of writing error-prone cod=
e.  The idea

>>> > of

>>> > someone offloading ack processing and then proceeding to =
trust the

>>> > length

>>> > seems like someone could get wrong and cause some concern=
ing issues.

>>> >

>>> > My experience is multithreaded packet processing is more =
cost and work

>>> > than

>>> > it's worth.  Sure you can't fill a 100G NIC with one=
 connection, but

>>> > that

>>> > seems like an academic problem, not one for workloads I'v=
e seen.

>>> > Typically

>>> > the extra cost of multithreading outweighs its value.

>>> >

>>> > To be clear, I don't think this is an awful idea, but I a=
lso don't see

>>> > the

>>> > value and it adds complexity.  I read Manasi's email=
, but I don't think

>>> > I

>>> > understand why any of those matter in practice.

>>> >

>>> > On Sat, Jun 16, 2018 at 4:13 PM Eric Rescorla <=
ekr@rtfm.com> wrote:<=
br>
>>> >>

>>> >> On Fri, Jun 15, 2018 at 6:46 PM, Marten Seemann

>>> >> <martenseemann@gmail.com>

>>> >> wrote:

>>> >>>

>>> >>> This proposal increases the size of the ACK frame=
 by 1 byte in the

>>> >>> common

>>> >>> case (less than 63 ACK ranges), since the ACK len=
gth field here

>>> >>> always

>>> >>> consumes 2 bytes, whereas the ACK Block Count is =
a variable-length

>>> >>> integer.

>>> >>> Considering how much work we put into minimising =
the size of the

>>> >>> frames,

>>> >>> this feels like a step in the wrong direction..
>>> >>>

>>> >>> Regarding the processing cost, I agree with Dmitr=
i. Handling an ACK

>>> >>> frame

>>> >>> requires looping over and making changes to a dat=
a structure that

>>> >>> keeps

>>> >>> track of sent packets. This is much more expensiv=
e than simply

>>> >>> parsing

>>> >>> a

>>> >>> bunch of varints in the ACK frame. It seems unlik=
ely that a

>>> >>> multi-threaded

>>> >>> packet parser would offer any real-world performa=
nce benefits.

>>> >>

>>> >>

>>> >> I don't want to overstate the benefit here, but my po=
int isn't that

>>> >> parsing is expensive but that if you want to have a m=
ultithreaded

>>> >> packet

>>> >> processing system, then it's nice to have a simpler d=
ata structure

>>> >> (the

>>> >> unparsed ACK block) to hand to the ACK processing thr=
ead.

>>> >>

>>> >> -Ekr

>>> >>

>>> >>

>>> >>>

>>> >>> On Sat, Jun 16, 2018 at 6:19 AM Martin Thomson
>>> >>> <martin.thomson@gmail.com>

>>> >>> wrote:

>>> >>>>

>>> >>>> When we discussed this before, some people ob=
served that this

>>> >>>> creates

>>> >>>> a need to encode in two passes.  That's =
the trade-off here.  (Not

>>> >>>> expressing an opinion.)

>>> >>>> On Fri, Jun 15, 2018 at 3:51 PM Jana Iyengar =
<jri.ietf@gmail.com>

>>> >>>> wrote:

>>> >>>> >

>>> >>>> > I don't have a strong opinion on this. I=
'm certainly not opposed

>>> >>>> > to

>>> >>>> > it.

>>> >>>> > Does anyone have a strong opposition?
>>> >>>> >

>>> >>>> > On Fri, Jun 15, 2018 at 3:10 PM Praveen =
Balasubramanian

>>> >>>> > <pravb@microsoft.com> wrote:

>>> >>>> >>

>>> >>>> >> I agree as well since this can help =
reduce per packet processing

>>> >>>> >> overhead. ACKs are going to be the s=
econd most common frame type

>>> >>>> >> so no

>>> >>>> >> objections to special casing.

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On=
 Behalf Of
 Eric

>>> >>>> >> Rescorla

>>> >>>> >> Sent: Friday, June 15, 2018 9:11 AM<=
br>
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>

>>> >>>> >> Cc: Jana Iyengar <jri.ietf@gmail.com>; Q=
UIC WG <quic@ietf.org=
>

>>> >>>> >> Subject: Re: Proposal to replace ACK=
 block count with ACK length

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> I agree with Manasi here. This chang=
e would allow ack frame

>>> >>>> >> parsing

>>> >>>> >> to be more self-contained, which is =
an advantage for the parser

>>> >>>> >> and also

>>> >>>> >> potentially for parallelism (because=
 you can quickly find the

>>> >>>> >> frame and then

>>> >>>> >> process it in parallel).

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> -Ekr

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> On Mon, Jun 11, 2018 at 5:22 PM, Dev=
al, Manasi

>>> >>>> >> <manasi.deval@intel.com> wrote:

>>> >>>> >>

>>> >>>> >> In general, varints require some spe=
cific logic for parsing. To

>>> >>>> >> skip

>>> >>>> >> over any header, I have to read ever=
y single varint. As the code

>>> >>>> >> sees Stream

>>> >>>> >> and ACK headers most frequently, tha=
t is my focus.  The Stream

>>> >>>> >> frame has a

>>> >>>> >> length in its third field.

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> ACK parsing, however, needs 6 + =
2*num_blocks reads to identify

>>> >>>> >> length. There are two reads each for=
 =91largest acknowledged=92, =91ACK

>>> >>>> >> delay=92 and

>>> >>>> >> =91ACK block count=92. The pain poin=
t is the total number of cycles

>>> >>>> >> parse an

>>> >>>> >> ACK. If I am processing 10M pps, whe=
re 10% - 30% of the packets

>>> >>>> >> have a

>>> >>>> >> piggybacked ACK, these cycles become=
s a significant bottleneck.

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> Thanks,

>>> >>>> >>

>>> >>>> >> Manasi

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> From: QUIC [mailto:quic-bounces@ietf.org] On=
 Behalf Of
 Jana

>>> >>>> >> Iyengar

>>> >>>> >> Sent: Monday, June 11, 2018 3:11 PM<=
br>
>>> >>>> >> To: Deval, Manasi <manasi.deval@intel.com>; QUIC WG

>>> >>>> >> <quic@ietf.org>

>>> >>>> >> Subject: Re: Proposal to replace ACK=
 block count with ACK length

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> You're right that we no longer have =
the ability to skip an ACK

>>> >>>> >> frame,

>>> >>>> >> and this crept in when we moved to v=
arints.

>>> >>>> >>

>>> >>>> >> I believe your problem though is gen=
erally true of most frames

>>> >>>> >> not

>>> >>>> >> just ACKs, since ids, packet numbers=
, and numbers in all frames

>>> >>>> >> are now all

>>> >>>> >> varints. To skip any frame, you'll n=
eed to parse the varint

>>> >>>> >> fields

>>> >>>> >> in those

>>> >>>> >> frames. If you have logic to process=
 and skip varints, then

>>> >>>> >> skipping the ack

>>> >>>> >> block section is merely repeating th=
is operation (2*num_block+1)

>>> >>>> >> times. Do

>>> >>>> >> you see specific value in skipping A=
CK frames over the other

>>> >>>> >> control frames?

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >>

>>> >>>> >> On Mon, Jun 11, 2018 at 8:43 AM Dmit=
ri Tikhonov

>>> >>>> >> <dtikhonov@litespeedtech..com>=
 wrote:

>>> >>>> >>

>>> >>>> >> On Mon, Jun 11, 2018 at 03:33:35PM &=
#43;0000, Deval, Manasi wrote:

>>> >>>> >> > -        Mo=
ving the ACK length to the front of the ACK allows

>>> >>>> >> > the

>>> >>>> >> >        &nbs=
p; flexibility of either reading the entire ACK or

>>> >>>> >> > reading

>>> >>>> >> > the

>>> >>>> >> >        &nbs=
p; first 16 bits and skipping over the length. This is a

>>> >>>> >> > useful

>>> >>>> >> >        &nbs=
p; feature for the case where ACK processing is split

>>> >>>> >> > into

>>> >>>> >> >        &nbs=
p; multiple layers. Depending on the processor this is

>>> >>>> >> > run

>>> >>>> >> > on,

>>> >>>> >> >        &nbs=
p; there are different advantages -

>>> >>>> >>

>>> >>>> >> Just a note.  In my experience,=
 the cost of parsing an ACK frame

>>> >>>> >> is

>>> >>>> >> negligible compared to the cost of p=
rocessing an ACK frame: that

>>> >>>> >> is,

>>> >>>> >> poking at various memory locations t=
o discard newly ACKed

>>> >>>> >> packets.

>>> >>>> >>

>>> >>>> >>   - Dmitri.

>>> >>>> >>

>>> >>>> >>

>>> >>>>

>>> >>

>>> >

>>>

>>>

>>>

>>> --

>>> Kazuho Oku

>

>

>

> --

> Kazuho Oku












--

Kazuho Oku






 




























--_000_ABCEEAFC0EE548F9939BE0F819507BE1intelcom_--


From nobody Sun Jul 15 13:37:16 2018
Return-Path: 
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 8AF2D130E63 for ; Sun, 15 Jul 2018 13:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ZvbLENu23ZEe for ; Sun, 15 Jul 2018 13:37:13 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC05130DDC for ; Sun, 15 Jul 2018 13:37:12 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jul 2018 13:37:12 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.51,358,1526367600"; d="scan'208";a="71598477"
Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by fmsmga004.fm.intel.com with ESMTP; 15 Jul 2018 13:37:00 -0700
Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 15 Jul 2018 13:37:00 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX115.amr.corp.intel.com ([169.254.4.162]) with mapi id 14.03.0319.002; Sun, 15 Jul 2018 13:37:00 -0700
From: "Deval, Manasi" 
To: Eric Rescorla 
CC: Marten Seemann , Ian Swett ,  IETF QUIC WG , =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= 
Subject: Re: Connection ID lengths 1, 2 and 3
Thread-Topic: Connection ID lengths 1, 2 and 3
Thread-Index: AQHUEsvAi91oX8DVaUqbcldKc5Rk06R97QgAgBGLlvCAAOSi4IAAh0AA//+rWH+AAHgzgP//jiJFgACDmQD//7fKzw==
Date: Sun, 15 Jul 2018 20:36:59 +0000
Message-ID: <08C6157C-A349-4CDB-B2AD-87215252DC25@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>  <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>  <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 20:37:15 -0000

For now,  we have heard of a good use case for 16-18 byte long connection I=
d and a 1-4 byte long connection id. I am very skeptical of the requirement=
 to support every size from 0 to 18.=20

We can possibly agree to support 8 or 10 different sizes that span this ran=
ge and code it in a 3 or 4 bit connection length. If we must use 4 bit, som=
e of the values can be encoded to 0. What do you think?

Manasi




Sent from my iPhone

> On Jul 15, 2018, at 1:56 PM, Eric Rescorla  wrote:
>=20
> existing fast crypto primitives to encode connection ID


From nobody Sun Jul 15 15:15:15 2018
Return-Path: 
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 25D66130E8C for ; Sun, 15 Jul 2018 15:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 iiGbPGcmCGH3 for ; Sun, 15 Jul 2018 15:15:11 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 6A1B6130E89 for ; Sun, 15 Jul 2018 15:15:11 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id l189-v6so13563368ywb.10 for ; Sun, 15 Jul 2018 15:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SmXC2KStpG4ciXbvFCiNdT4PAL8/H+/w6CN7l1mFjKI=; b=U7LqtH2fU+Es4lWUDSH6QHyYlBA/HKEiGFhMOajWK2slVBjTQOBr9XwTWAi0SHysxs xyvaJIqzODpARzb9usd9PAVB5slxpyRZhWZ7c9GcjiSsn+IQanbZKZgHyLHwSOxyAqnF NUJVMXHESlbZLyH9e1/YgQrH3s9nJ9Sx/qfPjCNWTWGdsDoPp1Chm56qOQIQxWpXgbpb L68fny2tQWD6O/Ol6xiYQdXPGau/oa9qVakX0mgiUseCOcZYuyAbKhkNCw1mS1rVYkbM buZEcqyRsrm9DCu+k9Oh5pdd7pwl+a9S1+Q761cRq+DL/E1aAYTZ2k+BfgnouaGhEa7b 1RIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SmXC2KStpG4ciXbvFCiNdT4PAL8/H+/w6CN7l1mFjKI=; b=Lf9GgTmqxH0OrmE2T0BCBU6Osqt9wt1EicKuieyH13Tjm0eVzNOWJTIznjYXcn6Lew GlDAarnfDqWIKHu6K9F1URNqUtgaO84zEwKA/9lDfI5152SIg/KSV+zraqDO+z3oCJ79 RiMZ5tw0put7o14SRYWD+/pDDW2gIbkm8n6Hl7DRlbGH5Ta8Cd7l5xSecCvrNHIV+k+8 ZAoX9AUuxulwzw0eRrPJpGQspooPe2kpjkwKe+4JtMge3eWWFR0HV6Ssc1qp28a0VDPN Eq547Vvt3e8xepOYI0yZVJ0BqgbtFYbxnTKlsxmz2kg4wAJPkXRPhmMyvTJjHnkX1zZd gRKw==
X-Gm-Message-State: AOUpUlFekmmm20LrKZiAIktT6ofd3hWpH66YOED09xPHi8925CK30DpX OzX1/ILcoBsIS39LimzOzuVlswDt+MaokOL/VBQgNg==
X-Google-Smtp-Source: AAOMgpfTHoNvl1Rz79AiRKyuzqerMpRTujC1J+6wSVRMHMbw+Ra20EcVRlOSs0Mz+OTIsweQjO8C8va4H1QdsjLYstw=
X-Received: by 2002:a81:2202:: with SMTP id i2-v6mr6963796ywi.167.1531692910497;  Sun, 15 Jul 2018 15:15:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Sun, 15 Jul 2018 15:14:30 -0700 (PDT)
In-Reply-To: <08C6157C-A349-4CDB-B2AD-87215252DC25@intel.com>
References: <1F436ED13A22A246A59CA374CBC543998B86DF5E@ORSMSX111.amr.corp.intel.com>  <0EA7393D-B7EC-4755-B13E-5177E24AA57A@intel.com>  <4F5BCC2E-4DD0-403F-954A-FB79847E218B@intel.com>  <08C6157C-A349-4CDB-B2AD-87215252DC25@intel.com>
From: Eric Rescorla 
Date: Sun, 15 Jul 2018 15:14:30 -0700
Message-ID: 
Subject: Re: Connection ID lengths 1, 2 and 3
To: "Deval, Manasi" 
Cc: Marten Seemann , Ian Swett ,  IETF QUIC WG , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Content-Type: multipart/alternative; boundary="000000000000d5e8f70571110b31"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 15 Jul 2018 22:15:14 -0000

--000000000000d5e8f70571110b31
Content-Type: text/plain; charset="UTF-8"

Not sure what went wrong with your quoting. You are responding to Ian
Swett, not to me.

On Sun, Jul 15, 2018 at 1:36 PM, Deval, Manasi 
wrote:

>
> For now,  we have heard of a good use case for 16-18 byte long connection
> Id and a 1-4 byte long connection id. I am very skeptical of the
> requirement to support every size from 0 to 18.
>
> We can possibly agree to support 8 or 10 different sizes that span this
> range and code it in a 3 or 4 bit connection length. If we must use 4 bit,
> some of the values can be encoded to 0. What do you think?
>
> Manasi
>
>
>
>
> Sent from my iPhone
>
> > On Jul 15, 2018, at 1:56 PM, Eric Rescorla  wrote:
> >
> > existing fast crypto primitives to encode connection ID
>

--000000000000d5e8f70571110b31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Not sure what went wrong with your quoting. You are respon=
ding to Ian Swett, not to me.

On Sun, Jul 15, 2018 at 1:36 PM, Deval, Manasi <manasi.deval@intel.com> wrote:


For now,=C2=A0 we have heard of a good use case for 16-18 byte long connect=
ion Id and a 1-4 byte long connection id. I am very skeptical of the requir=
ement to support every size from 0 to 18. 



We can possibly agree to support 8 or 10 different sizes that span this ran=
ge and code it in a 3 or 4 bit connection length. If we must use 4 bit, som=
e of the values can be encoded to 0. What do you think?



Manasi









Sent from my iPhone




> On Jul 15, 2018, at 1:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 

> existing fast crypto primitives to encode connection ID





--000000000000d5e8f70571110b31--


From nobody Wed Jul 18 03:50:19 2018
Return-Path: 
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 8C85313116B for ; Wed, 18 Jul 2018 03:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 DWnvdjyBPsFQ for ; Wed, 18 Jul 2018 03:50:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E2E131177 for ; Wed, 18 Jul 2018 03:50:09 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D7E82306158F4 for ; Wed, 18 Jul 2018 11:50:04 +0100 (IST)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 18 Jul 2018 11:50:06 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0382.000; Wed, 18 Jul 2018 16:19:54 +0530
From: Sridhar Bhaskaran 
To: IETF QUIC WG 
Subject: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQ==
Date: Wed, 18 Jul 2018 10:49:53 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.148.59]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 18 Jul 2018 10:50:18 -0000

Dear Quic experts,

I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC transp=
ort and HTTP over QUIC, I have the following queries

1. If a HTTP URI uses http:// scheme and the origin server advertises alter=
nate service via QUIC, can a HTTP client use QUIC to connect to the origin =
server and still use the http:// scheme URI?
2. If a HTTP URI uses https:// scheme and the HTTP client is configured to =
connect to a HTTP proxy and if the HTTP proxy supports QUIC, my understandi=
ng is the following sequence of events
	a. HTTP client to HTTP proxy QUIC connection is setup
	b. HTTP client issues a HTTP CONNECT request to the proxy with the ":autho=
rity" HTTP/2 pseudo header pointing to the origin server
	c. HTTP proxy upon getting the CONNECT request sets up a TCP connection wi=
th the origin server
	d. HTTP proxy sends HTTP CONNECT response to the client
	e. HTTP client then initiates a TLS connection towards the origin server v=
ia the proxy and the proxy simply tunnels it.
	f. Actual HTTP traffic happens between client and origin server

Is this correct?

Where I am not clear is whether step /e/ actually happens. If it does, then=
 for step /f/ is the client required to do ciphering 2 times - one for the =
TLS and other for the QUIC connection to proxy itself.

Could you please clarify?

Thanks
Sridhar


From nobody Wed Jul 18 06:38:26 2018
Return-Path: 
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 1E6211311C7 for ; Wed, 18 Jul 2018 06:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level: 
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 DGHGPbfHCeTl for ; Wed, 18 Jul 2018 06:38:13 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5079F1311B0 for ; Wed, 18 Jul 2018 06:38:13 -0700 (PDT)
Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id CAEC73A028 for ; Wed, 18 Jul 2018 09:38:12 -0400 (EDT)
Received: by mail-oi0-f51.google.com with SMTP id w126-v6so8801175oie.7 for ; Wed, 18 Jul 2018 06:38:12 -0700 (PDT)
X-Gm-Message-State: AOUpUlHUoX9oB3dUkqXYfKVc6Vxwc7Lg74FplfZLnzFrJCJrYhHyTVhe DzavbUiYmzTXXXV4QxTgrZQP7QzTdP6NBkX5/wU=
X-Google-Smtp-Source: AAOMgpdPgOHeRUhre+9EJEQ23UFxg4QxV+5sZAXg+ab9XyIk5KymatFEWndyjQ0uCz0p/3uG1J2kCzm+MDj3qwfq3GY=
X-Received: by 2002:aca:a806:: with SMTP id r6-v6mr6772681oie.213.1531921092545;  Wed, 18 Jul 2018 06:38:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 06:38:11 -0700 (PDT)
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
From: Patrick McManus 
Date: Wed, 18 Jul 2018 09:38:11 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Questions on HTTP URI schemes and QUIC
To: Sridhar Bhaskaran 
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000008ba1130571462c73"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 18 Jul 2018 13:38:25 -0000

--0000000000008ba1130571462c73
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 18, 2018 at 6:49 AM, Sridhar Bhaskaran <
sridhar.bhaskaran@huawei.com> wrote:

> Dear Quic experts,
>
> I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC
> transport and HTTP over QUIC, I have the following queries
>
> 1. If a HTTP URI uses http:// scheme and the origin server advertises
> alternate service via QUIC, can a HTTP client use QUIC to connect to the
> origin server and still use the http:// scheme URI?
>

There is an experimental RFC, 8164, that would probably apply here for
consenting endpoints. 8164 requires the same crypto and authentication as
https - so you should probably just go with https unless you're already
using that strategy with h2 for legacy mixed content.



> 2. If a HTTP URI uses https:// scheme and the HTTP client is configured
> to connect to a HTTP proxy and if the HTTP proxy supports QUIC, my
> understanding is the following sequence of events
>         a. HTTP client to HTTP proxy QUIC connection is setup
>         b. HTTP client issues a HTTP CONNECT request to the proxy with the
> ":authority" HTTP/2 pseudo header pointing to the origin server
>         c. HTTP proxy upon getting the CONNECT request sets up a TCP
> connection with the origin server
>         d. HTTP proxy sends HTTP CONNECT response to the client
>         e. HTTP client then initiates a TLS connection towards the origin
> server via the proxy and the proxy simply tunnels it.
>         f. Actual HTTP traffic happens between client and origin server
>
> Is this correct?
>
>
i believe so


> Where I am not clear is whether step /e/ actually happens. If it does,
> then for step /f/ is the client required to do ciphering 2 times - one for
> the TLS and other for the QUIC connection to proxy itself.
>
>
yes, connect tunnels are end to end encryption for their content so the
data that flows between the client and proxy is encrypted twice. That's the
same in all versions of http.

Could you please clarify?
>
> Thanks
> Sridhar
>
>

--0000000000008ba1130571462c73
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Wed, Jul 18, 2018 at 6:49 AM, Sridhar Bhaskaran <sridhar.bha=
skaran@huawei.com> wrote:
D=
ear Quic experts,



I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC transp=
ort and HTTP over QUIC, I have the following queries



1. If a HTTP URI uses http:// scheme and the origin server advertises alter=
nate service via QUIC, can a HTTP client use QUIC to connect to the origin =
server and still use the http:// scheme URI?



There is an experimental RFC, 8164, that w=
ould probably apply here for consenting endpoints. 8164 requires the same c=
rypto and authentication as https - so you should probably just go with htt=
ps unless you're already using that strategy with h2 for legacy mixed c=
ontent.

=C2=A0
2. If a HTTP URI uses https:// scheme and the HTTP client is configure=
d to connect to a HTTP proxy and if the HTTP proxy supports QUIC, my unders=
tanding is the following sequence of events

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. HTTP client to HTTP proxy QUIC connection is=
 setup

=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. HTTP client issues a HTTP CONNECT request to=
 the proxy with the ":authority" HTTP/2 pseudo header pointing to=
 the origin server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. HTTP proxy upon getting the CONNECT request =
sets up a TCP connection with the origin server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 d. HTTP proxy sends HTTP CONNECT response to th=
e client

=C2=A0 =C2=A0 =C2=A0 =C2=A0 e. HTTP client then initiates a TLS connection =
towards the origin server via the proxy and the proxy simply tunnels it.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 f. Actual HTTP traffic happens between client a=
nd origin server



Is this correct?



i believe so
=C2=A0

Where I am not clear is whether step /e/ actually happens. If it does, then=
 for step /f/ is the client required to do ciphering 2 times - one for the =
TLS and other for the QUIC connection to proxy itself.



yes, connect tunnels are end to end en=
cryption for their content so the data that flows between the client and pr=
oxy is encrypted twice. That's the same in all versions of http.
<=
div>

Could you please clarify?



Thanks

Sridhar







--0000000000008ba1130571462c73--


From nobody Wed Jul 18 06:52:27 2018
Return-Path: 
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 BA5E4130DD7 for ; Wed, 18 Jul 2018 06:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sIJQToybGHt7 for ; Wed, 18 Jul 2018 06:52:23 -0700 (PDT)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C16126DBF for ; Wed, 18 Jul 2018 06:52:23 -0700 (PDT)
Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w6IDqIwN001682; Wed, 18 Jul 2018 14:52:18 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0389.001; Wed, 18 Jul 2018 14:52:18 +0100
From: Lucas Pardue 
To: Sridhar Bhaskaran , IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMg
Date: Wed, 18 Jul 2018 13:52:17 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23976.006
x-tm-as-result: No-1.001300-8.000000-10
x-tmase-matchedrid: byfwvk+IcRm7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p3b6Y+fnTZUL3V8 6ck2cnUP7UIY7FTQEq2Xo+LdDt/YJs4MEMpuYr2lpvwZ9GmdwDP4qCLIu0mtIIzZ6FNX6KaLozk GjKWy0ilNYvDaO9t+nCgYXq4u0oay+dVjQNaxOresDodw9yUkxpnZ3QZNYH8lFlEHrMSBTX++8x ACKN6zGIfhK4s3hzbmECTq1hdYNfFNTwBwYO28L/p1plqEbuqxeFyzQYzPQ+TIvQIyugvKdZUgS Lx++MHyn/3mwgykHMD1kO5kGLTAx9b7UmjtI1CSX39j8VcpJxEHdYH++bm0GEmVes1pwna567zK QiK/wKzDzL4vreNXHbBMgJuhfWMiQgUInkqQBs9kiLB9qoJwH30tCKdnhB581B0Hk1Q1KyJXaDn 6DhA2Ao2j49Ftap9ExlblqLlYqXLjuiF7ro3IQ7hNCgyyTm7VvyRdTjpwY9ovtWLkGpUIs5tFFh Ww9ee1ELkzJvIsnr5fjlAWuVH+tCF9eE/0RdtqjECEHl6HMMPIKX8H5ZJqUCmvpvEsYCZa+dHcz GoifKaUJgj59gJblQ5uHRe1kWVm
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--1.001300-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23976.006
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 18 Jul 2018 13:52:26 -0000

Hi Sridhar,

I presented some slides [1] about HTTP proxying (including HTTP over QUIC) =
at the IETF 102 HTTPbis session this week. I'm not sure if your questions a=
re motivated by that session, or if it is coincidence. There are some visua=
lisations of the various tunnelling options (as I understand them) across t=
he main slides and backup slides.

Regards
Lucas

[1] - https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-hel=
ium.pdf

>-----Original Message-----
>From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Sridhar Bhaskaran
>Sent: 18 July 2018 11:50
>To: IETF QUIC WG 
>Subject: Questions on HTTP URI schemes and QUIC
>
>Dear Quic experts,
>
>I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC
>transport and HTTP over QUIC, I have the following queries
>
>1. If a HTTP URI uses http:// scheme and the origin server advertises alte=
rnate
>service via QUIC, can a HTTP client use QUIC to connect to the origin serv=
er
>and still use the http:// scheme URI?
>2. If a HTTP URI uses https:// scheme and the HTTP client is configured to
>connect to a HTTP proxy and if the HTTP proxy supports QUIC, my
>understanding is the following sequence of events
>	a. HTTP client to HTTP proxy QUIC connection is setup
>	b. HTTP client issues a HTTP CONNECT request to the proxy with the
>":authority" HTTP/2 pseudo header pointing to the origin server
>	c. HTTP proxy upon getting the CONNECT request sets up a TCP
>connection with the origin server
>	d. HTTP proxy sends HTTP CONNECT response to the client
>	e. HTTP client then initiates a TLS connection towards the origin server
>via the proxy and the proxy simply tunnels it.
>	f. Actual HTTP traffic happens between client and origin server
>
>Is this correct?
>
>Where I am not clear is whether step /e/ actually happens. If it does, the=
n for
>step /f/ is the client required to do ciphering 2 times - one for the TLS =
and
>other for the QUIC connection to proxy itself.
>
>Could you please clarify?
>
>Thanks
>Sridhar


From nobody Wed Jul 18 07:12:36 2018
Return-Path: 
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 7458C126F72 for ; Wed, 18 Jul 2018 07:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 DlIiodxWGzpD for ; Wed, 18 Jul 2018 07:12:32 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 0957E130E1B for ; Wed, 18 Jul 2018 07:12:32 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id l15-v6so4243981lji.6 for ; Wed, 18 Jul 2018 07:12:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ybhpqzggTdePGmMOQagwnORdifRZjPfEmYnheOLj1Vg=; b=0wlzO7ZwJ3TJt/HkU/0Qn/U3Ymo3bUU/QB+5KImoZQkyWBRmi2Ks9Zvfzahf/7yjrI VC3b8tBFfmKNtaB9MMLDyROfyn2Bj+eg6zjndPYq+UYhsgBI85YQQQQGLW+6fMpElpIA qmliyz7MVpOCsVlWjvpTARcm7KgdSm8YVHqZSp6gP3WKa7oLxcyU/1fbpscx+nc2lEKM /pl2+mgD/ShwtmjggAmeIvDLRgSNR0n5jYflAxRmy5M5Pr4B71yuUVrZzozDE9WHxDgn tgfiwlxFhquaUsBGW+EZmzsO5UdYYHQqs6MqL/vtzB8v0Lb0t4S4AWMA6/ew2eM3pATe gUEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ybhpqzggTdePGmMOQagwnORdifRZjPfEmYnheOLj1Vg=; b=mwyWU5eT6Js1/A9AyaCKbngtVCLiou15BwgcOkU3xRHtixHJ/0Vq0RhPQbmwTPSwbQ U3n2nc+ZCLxjCctmhb8g3/Y6kqzbI4gCzoRYtIUF5vgVhoU9zfVteVjD7QkUfQ6bl61N COK3Guovt4pGJqKDzej8AQ5wUN8mVe41Jfp9cSEcuhuXtuZ+0iCiwaqtU/gWi2Fuj6PX 4FSU/GD9SEviv+v6aFhfLCMf0q2Dx9/QSQCFPHUJoNtOsqgRuw3r4CKRihU5vvx3UtP/ g+KfEkC8ObAjJs1TVLtBHLPP0gnggOW5b6Y/UmY5OmQ8CqW+6NYelGz1rf9guXKYtwco QSOw==
X-Gm-Message-State: AOUpUlH1vrAY/QWzjjmKQXjlbmFJR/mpy1KpSk98sKTRkhK3DkZw7kSC zmSv+yNV/pZXZ98ovGYVxd6IM+GBSQH46ow9BLdKyy1fW8A=
X-Google-Smtp-Source: AAOMgpfhRuio/Nkx5IiMabG+HYqfUYmSXAimBL+gIMIrgLN+9KaLHTn2ejd+FckMSwt37VJNB/t4DKyB1tLOsuQZjaE=
X-Received: by 2002:a2e:9c4d:: with SMTP id t13-v6mr4619625ljj.153.1531923150052;  Wed, 18 Jul 2018 07:12:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 07:11:49 -0700 (PDT)
From: Eric Rescorla 
Date: Wed, 18 Jul 2018 07:11:49 -0700
Message-ID: 
Subject: PNE Test Vector
To: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000002eb472057146a759"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 18 Jul 2018 14:12:35 -0000

--0000000000002eb472057146a759
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As discussed in the meeting, here is a test vector for PNE. It's an Initial
packet generated by Kazuho but processed by Minq, with the output being an
edited and annotated version of Minq's logging. Happy to help with more
logging if that helps.


INPUT PACKET
ffff00000d5006b858ec6f80452b0044efa5d8d307c2973fa0d63fd9b03a4e163b990dd7788=
94a9edc8eacfbe4aa6fbf4a22ec7f906b5e8b8ae12e5fcc7924dfeee813842bb2149b805e55=
895084e8393200bb3fc618af7d08281485d914ce42303f5d772b200508a0c00253e332e36a8=
4f657321ac4c8e2cc8a117e95871f12b1f36be8c4b76fa433dc4d3142e6547f4598bf4b1921=
30aea6fc20da5158b2162b5a899957da05ded5c70907298fd885847f22a1ecb0a814fe0170e=
23cad20af64f05cc13c74e91824101afdcf5f1532fc2fde936a3a159f76283a26c738f778c7=
6e6ca41fa7f134401d39027fd81de17a8021a9c0aaa9b4478fe5c0647941618f3bee410caf9=
4c248d2a64b5e45845cd77de13a5ed94034d2bc5f457887351993c1ecfa34fd0c658fea3f80=
86d26808eef976262ecf0ad646b627945511dde83e26609cd5cfd7ed9f6207d76618b44c48b=
f623bf420dc7c127e5d5f529f083b71a17b17da329bfc38a74bf8cfcf315c7c070b71ebfae3=
ab351341a767adfdd9e57c738f5de9da53711e886d1472310b917a1c9798e3e9b13c7c74beb=
8d1b82345bea1349415679a9c64b0433b68c871ae08092a1f6106bc06337cd343866ee8185c=
03fcf3bb0666453f847905547199414c1e57535747be61cdf6778378f121d68df0181ee9e8d=
9932c1c593c0f8c0a1af0f5262b86205002dced9ecdaee2d0aa07dd4c14f98571e4bea72f84=
74f63697043e936ebb2bf9716ed0efbdc13005a75cee3a49babc61b9677764510eb19828df4=
e10fb38b79a1efbf04cc2d571949d5403f797361743dcc5e3bf3b4396f7ae1a3affbc9f72e5=
40d920363970307e0725fa838d611803251a4a08ccca1983d5b29a583758be63343e88f5591=
d885b8af695f33adbdd0d941d260287e32ef5a98fd55ac137211021fdc23b5d7a5469f578bf=
7aff6529117996f9ebab5e6dc7b047b356332fea82fdd620eb86f3c1d3855c8b8075da59a76=
62f4a11b977d996b8b3c7657ad4a82a20a7f76ce376c0320086ed029dd615399307983113cc=
0aa973ecba691e7e4cdc80aefa7e8c8347baba050eaca7dc35a21aa854e531dc7758d7d10b8=
c8e42c1be3bbf266d055ac25c37279ebefa28bbe89a34ad1ab3d23d7a66d1c216a57650e6ec=
9fc8ba7adfb38e57f20c467166c8fe7944e67f82138160002004812c78ba4b5f0da917da4cc=
14cf8fc10dba3f533facb11ef06d8b8f178ea9c5e8acbbca7b7f0e1f6b7a70ec2d5108cc411=
78056295793bed357accbb03c0582dc69bc77a34030f38cce256c5a9cec6e862146e3f0463f=
10dd5833257d0a0359166a7e2027d98eaf26cf0d5a4a05f6ef8b742f5d314a31deeeabe4ebc=
3106547e79c6cb933105d907b4c8c60443e97a154694bab5edfc781a438675b9de6ed03c77f=
51458eab61ca2e80ac02cc8c037d8fb3cf129d7107f618d66032cc02238a211f78bfa44e7c1=
bbcfcc627771c188d1b3713ce5e75cd2325a0a2ba08268cad13b27d97696ef678b592d0ac80=
ad1bacb4a1ba75bea8c477f39fc32c2aa20f352bb0da1c49b7d3927bcd9dfaf229237081d5f=
a08924fefd923ff0ac6baad6864b7c10dc73379a5ebd9e4678a0c26517656e8e51fca2a51a3=
3fb2cdd5d76d12674c240ba9a4893c1af69b8f2c4adf37c4a47551eb2006a732f6b3b2f338c=
078ede33946dfe4a55bf644d3b98848693ada1fcb6fc16cac339ee65c24dc64b0ae92005354=
af00ade71e6c5e2efd85c46131d948ff14096b0f06a41d83c8522f30beb4eaaf4a6f908fe2a=
6ee754c896


GENERATE THE KEYS
Cleartext keys: cid=3D06b858ec6f80452b
initial_salt=3D9c108f98520a5c5c32968e950e8a2c5fe06d6c38

initial_secret (server in) =3D
7e0aba2c4b9742d0d130bc7318622ad3b44aca1f09abb19b3f394cd7e20f4be0
key=3D26080e60d288db7df816a1cb0bc6c7f4 iv=3Db9fdc5b448af3e023422443b
pn=3D00babbe1be0f0c6618188b4fcca57a96

Cleartext keys: cid=3D06b858ec6f80452b
initial_salt=3D9c108f98520a5c5c32968e950e8a2c5fe06d6c38
initial_secret (client in) =3D
82a73572e7cb89523b68c39eaa8325404f86498c8e2437dfdce10f9c34281a3d
key=3Da79943566c41342f2bc3de6b7c1539df iv=3D84eb954ffe161c3875919f5f
pn=3D5c0f6472a15658047a3cc1f15478dcf4

PNE DECRYPTION
PNE sample_offset=3D21 sample=3Dc2973fa0d63fd9b03a4e163b990dd778
Decoded PN block (unknown length): c0000000
Packet number: 0 length=3D4

--0000000000002eb472057146a759
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


As discussed in the meeting, here is a test vector fo=
r PNE. It's an Initial packet generated by Kazuho but processed by Minq=
, with the output being an edited and annotated version of Minq's loggi=
ng. Happy to help with more logging if that helps.

=


INPUT PACKET
ffff00000d5006b858ec6f80452b0044efa5d8d=
307c2973fa0d63fd9b03a4e163b990dd778894a9edc8eacfbe4aa6fbf4a22ec7f906b5e8b8a=
e12e5fcc7924dfeee813842bb2149b805e55895084e8393200bb3fc618af7d08281485d914c=
e42303f5d772b200508a0c00253e332e36a84f657321ac4c8e2cc8a117e95871f12b1f36be8=
c4b76fa433dc4d3142e6547f4598bf4b192130aea6fc20da5158b2162b5a899957da05ded5c=
70907298fd885847f22a1ecb0a814fe0170e23cad20af64f05cc13c74e91824101afdcf5f15=
32fc2fde936a3a159f76283a26c738f778c76e6ca41fa7f134401d39027fd81de17a8021a9c=
0aaa9b4478fe5c0647941618f3bee410caf94c248d2a64b5e45845cd77de13a5ed94034d2bc=
5f457887351993c1ecfa34fd0c658fea3f8086d26808eef976262ecf0ad646b627945511dde=
83e26609cd5cfd7ed9f6207d76618b44c48bf623bf420dc7c127e5d5f529f083b71a17b17da=
329bfc38a74bf8cfcf315c7c070b71ebfae3ab351341a767adfdd9e57c738f5de9da53711e8=
86d1472310b917a1c9798e3e9b13c7c74beb8d1b82345bea1349415679a9c64b0433b68c871=
ae08092a1f6106bc06337cd343866ee8185c03fcf3bb0666453f847905547199414c1e57535=
747be61cdf6778378f121d68df0181ee9e8d9932c1c593c0f8c0a1af0f5262b86205002dced=
9ecdaee2d0aa07dd4c14f98571e4bea72f8474f63697043e936ebb2bf9716ed0efbdc13005a=
75cee3a49babc61b9677764510eb19828df4e10fb38b79a1efbf04cc2d571949d5403f79736=
1743dcc5e3bf3b4396f7ae1a3affbc9f72e540d920363970307e0725fa838d611803251a4a0=
8ccca1983d5b29a583758be63343e88f5591d885b8af695f33adbdd0d941d260287e32ef5a9=
8fd55ac137211021fdc23b5d7a5469f578bf7aff6529117996f9ebab5e6dc7b047b356332fe=
a82fdd620eb86f3c1d3855c8b8075da59a7662f4a11b977d996b8b3c7657ad4a82a20a7f76c=
e376c0320086ed029dd615399307983113cc0aa973ecba691e7e4cdc80aefa7e8c8347baba0=
50eaca7dc35a21aa854e531dc7758d7d10b8c8e42c1be3bbf266d055ac25c37279ebefa28bb=
e89a34ad1ab3d23d7a66d1c216a57650e6ec9fc8ba7adfb38e57f20c467166c8fe7944e67f8=
2138160002004812c78ba4b5f0da917da4cc14cf8fc10dba3f533facb11ef06d8b8f178ea9c=
5e8acbbca7b7f0e1f6b7a70ec2d5108cc41178056295793bed357accbb03c0582dc69bc77a3=
4030f38cce256c5a9cec6e862146e3f0463f10dd5833257d0a0359166a7e2027d98eaf26cf0=
d5a4a05f6ef8b742f5d314a31deeeabe4ebc3106547e79c6cb933105d907b4c8c60443e97a1=
54694bab5edfc781a438675b9de6ed03c77f51458eab61ca2e80ac02cc8c037d8fb3cf129d7=
107f618d66032cc02238a211f78bfa44e7c1bbcfcc627771c188d1b3713ce5e75cd2325a0a2=
ba08268cad13b27d97696ef678b592d0ac80ad1bacb4a1ba75bea8c477f39fc32c2aa20f352=
bb0da1c49b7d3927bcd9dfaf229237081d5fa08924fefd923ff0ac6baad6864b7c10dc73379=
a5ebd9e4678a0c26517656e8e51fca2a51a33fb2cdd5d76d12674c240ba9a4893c1af69b8f2=
c4adf37c4a47551eb2006a732f6b3b2f338c078ede33946dfe4a55bf644d3b98848693ada1f=
cb6fc16cac339ee65c24dc64b0ae92005354af00ade71e6c5e2efd85c46131d948ff14096b0=
f06a41d83c8522f30beb4eaaf4a6f908fe2a6ee754c896


GENERATE THE KEYS=

Cleartext keys: cid=3D06b858ec6f80452b initial_salt=3D9c108f98520a5c5c3=
2968e950e8a2c5fe06d6c38

initial_secret (server in) =3D 7e0aba2c4b974=
2d0d130bc7318622ad3b44aca1f09abb19b3f394cd7e20f4be0
key=3D26080e60d288db=
7df816a1cb0bc6c7f4 iv=3Db9fdc5b448af3e023422443b pn=3D00babbe1be0f0c6618188=
b4fcca57a96

Cleartext keys: cid=3D06b858ec6f80452b initial_salt=3D9c=
108f98520a5c5c32968e950e8a2c5fe06d6c38
initial_secret (client in) =3D 82=
a73572e7cb89523b68c39eaa8325404f86498c8e2437dfdce10f9c34281a3d
key=3Da79=
943566c41342f2bc3de6b7c1539df iv=3D84eb954ffe161c3875919f5f pn=3D5c0f6472a1=
5658047a3cc1f15478dcf4

PNE DECRYPTION
PNE sample_offset=3D21 samp=
le=3Dc2973fa0d63fd9b03a4e163b990dd778
Decoded PN block (unknown length):=
 c0000000
Packet number: 0 length=3D4



--0000000000002eb472057146a759--


From nobody Wed Jul 18 12:09:57 2018
Return-Path: 
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 7289B130F89 for ; Wed, 18 Jul 2018 12:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=aXGm57FK; dkim=pass (1024-bit key) header.d=ericsson.com header.b=fWgajpgX
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 g8Qt-ISwHt7y for ; Wed, 18 Jul 2018 12:09:47 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EE6130FFB for ; Wed, 18 Jul 2018 12:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531940985; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fDCvHSzXtMJkMctfPh/vyGDs31WzBBaLg2kB9YRmrSM=; b=aXGm57FKRc9yRQR5r2Zbo2hjVFIufb0qGREdayCwsvD+uzaSxAhQR2ntgB28f8Vb WVaC9XtY6eby5+e7F9Bv/6an0WprfvI73MP3pXV5niC/yeOW40EoW1GbT9TOArnA xyR+qp9kgggPcjCuy/s30v70ungayekhs6hff8mhXEM=;
X-AuditID: c1b4fb30-5cb039c0000059c2-67-5b4f90798e0d
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.CC.22978.9709F4B5; Wed, 18 Jul 2018 21:09:45 +0200 (CEST)
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 18 Jul 2018 21:09:43 +0200
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 18 Jul 2018 21:09:43 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fDCvHSzXtMJkMctfPh/vyGDs31WzBBaLg2kB9YRmrSM=; b=fWgajpgXOCt9fxhBxhdtlh5O+Uv9TgUcy3hG8JnlT0Sk2v9NgVAm09qE99HPU6Tb076wdu5+2hV/jvbwvfKEzR/phkKyR3GlfGPoWvObXKpV6Ks+uInp1nT218EHxh1/UDuM8z7UJGlgdTFSO7PxY9nBvZ3+UlkcBVQ7yE/149k=
Received: from HE1PR0701MB2393.eurprd07.prod.outlook.com (10.168.128.12) by HE1PR0701MB2476.eurprd07.prod.outlook.com (10.168.128.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Wed, 18 Jul 2018 19:09:39 +0000
Received: from HE1PR0701MB2393.eurprd07.prod.outlook.com ([fe80::b19f:1cc2:4698:a10e]) by HE1PR0701MB2393.eurprd07.prod.outlook.com ([fe80::b19f:1cc2:4698:a10e%9]) with mapi id 15.20.0973.016; Wed, 18 Jul 2018 19:09:39 +0000
From: Marcus Ihlar 
To: "quic@ietf.org" 
Subject: 1-bit spin bit; some results
Thread-Topic: 1-bit spin bit; some results
Thread-Index: AQHUHsphxa9pByBhmUGxIxW8KQGBBw==
Date: Wed, 18 Jul 2018 19:09:39 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: sv-SE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:67c:370:128:a940:3a65:6837:468f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2476; 6:m0wGqGzMHidKoKTrHY7HxvQC2jbfPtVyolOjF4sLpbyxvJQPtrBtCbT479pzg0cK7kpUfqux8O3SyJeMDblllUQMZCaa2TTGjfP/JdU+erTRiJCikHactWyv0ZWvlZZZ5CgmgJX7h6XQtNWm63HKzWXVNpz1kE2WRDr44SKjbuQ3vNMWKOTi/UiMXVY/u4OrqM6IyLJU1MZr3dv3SbKbHNBrI+A08TSPeheXco9UhjTbR2Fks9EuVXpo8VMg1aE8sU7MK0/6x85AVxn/70Y6N3AeRhxvPKtKDqnUIKwOyV2C2DLYnoSlt/iLmo7zSKB/EKD7qxaQpy6BMgVJFSv5MjIYArYyl4uaUXfSmPdD2sBKRNxf43D4W2lsNkyCKCUAtdRb849D1d0P8xLeWPuDXsQgwEYKqppjh4MevlAGFcU+CMEmZFTPmYAgBzczyoobvByptIUahPF2dsGTmq1jDg==; 5:yDkmgXN8yGfaDryMd560y/8umlT+xtmp1brXj3rc3708QY5YJUpGO6+omSyxhHQ0sT9hlJfu1Q/+zZh2umUaHESsOn+8P43T2tydfiJCPukzuHpq+bjcmWFKdiTX4RD+D+10Qr80gYNZ0bm4rW6rninowIweSsvUh4fBLCKzrE8=; 7:q5EqUp4lVLWKf5gGVdsmDH0szGKXBdFfSBJbgQIB/IWnW+kQ7P8hCkJ1Bh+dNE2LDATj2F5TtfO+wG2OXeyyKaWs5R4EEL3CtZX9n4ed8qCte5TW46Zy+h1XGIMXi9Avi07ItY/Ll1cwWJp74bQ+nmJ8sT6u/sviBo8siYPUmHOtQ540QRIsJHE+g6/EPjAGhgzG/AaM+IZRQckawnRz2ZjfegeBCUYHGW/hcoHCo55IHaqgJj+Pu5nIYzd7vbK8
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 90da25d4-3c32-4ce9-122d-08d5ece202e1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600064)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2476; 
x-ms-traffictypediagnostic: HE1PR0701MB2476:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcus.ihlar@ericsson.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB2476; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2476; 
x-forefront-prvs: 0737B96801
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(396003)(366004)(199004)(189003)(86362001)(46003)(97736004)(6116002)(316002)(186003)(5250100002)(256004)(478600001)(102836004)(44832011)(476003)(606006)(2501003)(486006)(25786009)(6916009)(7736002)(68736007)(966005)(1730700003)(7696005)(53336002)(74316002)(5640700003)(9686003)(6506007)(53936002)(19627405001)(8936002)(99286004)(733005)(33656002)(14454004)(6606003)(105586002)(54896002)(6436002)(2351001)(2900100001)(106356001)(236005)(81156014)(8676002)(5660300001)(81166006)(55016002)(2906002)(861006)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2476; H:HE1PR0701MB2393.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: aI9ry7Vw+faVgm777cywiC2lT6n/1mbp+OV0SXf//FIIneApSfbEWHZaaFYAsaHX0v6UZ9gl4boI2g3WHPi3Gm716+dzw3IZbRfIwbFM5ztzMe3qGuTCsUci3InCbMUIrMs6//fK/0WJK1gw23Putmx47niILB2b75yzEOppQC6KuIwLOrk/YPAbsg9yESkkFwMcLUZ1u3NY6wbwSDM0vUhuKsP9kt5NuxUreqLMlcGuB1xF6xbWZXy4uv+brNUiEv6gAwSEtJLQZZxqZoJYexwu2La0E4s8wR0H/llBB4czom+UKpfcH3yB+03YaU/v0BK0zwBp1i67L5NxUTnfy0w/A0jdvrjw+VET2FdRR+k=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB23937E0A9F0866D7491B2358E2530HE1PR0701MB2393_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 90da25d4-3c32-4ce9-122d-08d5ece202e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2018 19:09:39.6931 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2476
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfOtuNqcFqKD94+LOpDunnBwiijGyVkGtGH0CBnnqblLpxj NqsPIwzEG942c92mzchLGWlqWaIDM3EUC43UzJU2tYyESnOitu1d4Lff8///n+d9n5eXIiRm fhCVpc5hWLUiWyoQkTWnOi7J8sqSU6OavoXHFZs37EMJFssS7zhKEe3JYLKzchk2cm+aKLPu TTtPO31QN9wxL9Cjyt2FyI8COha+OpuFhUhESeg+BPlFJh4uFhCUfzHyPSkJbeGB3cV6DJIu I+DxYAGBU9U8GG7oR7hwIlguqCU8LQJaDrbxIoGH/ektcKv+ntDDm+mt0Fz1l8T6dihx1CPM cuhbmffqpDtjm27wHi2m08C+sOxlRIfCxOInb4agA+HXbQcPL0GD5cVbAnMAzE6u8jHHQf+K 2ceh8O5ukfeiQPcIYWDB5GuQwbzB4ONjMHJtiMChAQT61mIhNiLAVjrjPo1y3+I0uMa0WNbA 3CMHiTkRpoxG35wwaCz5TOI5VgLyF34jbITAjNPoMyb50H2zSliGZKZ1G2HWgOtVl9DkfYFN MFAzRWJdDh8MVQLM4XC/9juBWQY3Vq3ket2MhI0ogGO4dJUyJkbOsFlnOU6jlquZnCfI/W96 25ajOtHs9H4roikk3Siu0yWnSviKXC5PZUVAEVJ/ce/PpFSJOEORd5lhNWfYi9kMZ0XBFCkN FMcltaZIaKUih7nAMFqG/e/yKL8gPWoKGXW1O4JH0Y/4hMbceKU51nlCFXj1fcuzwF3Gc0O6 nMiw0UX9Wm3GgwNHRpraKyXRqqGWbSnPJ8YtY3eu218f3TnHOp4e6upZc2qvrNop9fmPw84K fuKf6odtFUERuarw9vrydJ3SZhh8SVq7S239xqVO2DF3eNUv+6S5fEBKcpmK6O0Eyyn+Ab4f JXMzAwAA
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 18 Jul 2018 19:09:54 -0000

--_000_HE1PR0701MB23937E0A9F0866D7491B2358E2530HE1PR0701MB2393_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

We have done measurements to test the impact of different kinds of network =
impairments has on the spin bit signal. The results we have so far are very=
 promising in terms of how useful the mechanism is.

Short summary:
The spin bit works well and provides good RTT estimates. Use of simple heur=
istics in the measurement node makes the RTT measurements robust to severe =
levels of reordering.


Observations:

Downstream impairments have little or no impact on the spin bit signal. Thi=
s is fairly obvious as the flow is well ordered at the observation point.


Severe reordering has the most negative impact on the spin bit signal quali=
ty since there is scrambling along the edges. Simple heuristics can be appl=
ied to minimize the reordering impact.


Random packet loss has a very small impact on the spin bit signal, a slight=
 bias towards larger RTT samples (compared to ideal measurements) is observ=
ed.


We also looked at the sample frequency of the spin bit signal (1 sample per=
 RTT) and compared it with the higher frequency sampling at the server (1 s=
ample per ACK). The server has a slight bias towards smaller samples, but t=
he difference is negligible.


We find these results very encouraging so far and will continue to scale up=
 and do further measurements.


There wasn't time enough at the QUIC session in Montreal to present the res=
ults, but you can find the slides here:

https://github.com/quicwg/wg-materials/blob/master/ietf102/SPIN-QUICWG.pdf


/Marcus Ihlar




[https://avatars0.githubusercontent.com/u/22631371?s=3D400&v=3D4]

quicwg/wg-materials
github.com
wg-materials - Agenda, Minutes, Presentations



--_000_HE1PR0701MB23937E0A9F0866D7491B2358E2530HE1PR0701MB2393_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi,


We have done measurements to test=
 the impact of different kinds of network impairments has on the spin bit s=
ignal. The results we have so far are very promising in terms of how useful=
 the mechanism is.










Short summary: 




The spin bit works well and provides good RTT estimates. Use of simple=
 heuristics in the measurement node makes the RTT measurements robust to se=
vere levels of reordering.










Observations:




Downstream impairments have littl=
e or no impact on the spin bit signal. This is fairly obvious as the flow i=
s well ordered at the observation point.










Severe reordering has the most ne=
gative impact on the spin bit signal quality since there is scrambling alon=
g the edges. Simple heuristics can be applied to minimize the reordering im=
pact.










Random packet loss has a very sma=
ll impact on the spin bit signal, a slight bias towards larger RTT samples =
(compared to ideal measurements) is observed.









We also looked at the sample freq=
uency of the spin bit signal (1 sample per RTT) and compared it with the hi=
gher frequency sampling at the server (1 sample per ACK). The server has a =
slight bias towards smaller samples,
 but the difference is negligible. 









We find these results very encour=
aging so far and will continue to scale up and do further measurements.&nbs=
p;










There wasn't time enough at the Q=
UIC session in Montreal to present the results, but you can find the slides=
 here:


https://github.com/quicwg/wg-ma=
terials/blob/master/ietf102/SPIN-QUICWG.pdf







/Marcus Ihlar



























github.com



wg-materials - Agenda, Minutes, Presentations


















--_000_HE1PR0701MB23937E0A9F0866D7491B2358E2530HE1PR0701MB2393_--


From nobody Wed Jul 18 12:42:42 2018
Return-Path: 
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 1F61E130FE1 for ; Wed, 18 Jul 2018 12:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 Ll5jCP9x9dj3 for ; Wed, 18 Jul 2018 12:42:38 -0700 (PDT)
Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EB3130FC5 for ; Wed, 18 Jul 2018 12:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple;  q=dns/txt; i=@apple.com; t=1531942957; x=2395856557; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nTXlSm2SznVGkKegD0hzN85MYv1LusMKtgyWS50D80w=; b=e53jZbr0iFNLX6kPWZsPyRs1dOwlZ8IcfhRml/kp6OUZuIfiBIvWJNh0PBRw31CF vqNtmxYlqXLNU8GAuP6Irmd9s4YQcZBQp+b7FnPJqGFRsv29sPV8B7zU8JIWk/L7 GO5NZmoN0f5WgwET1D2I8l1fcH7YG/nadox5Vd7hYH7l+SzYLlfcW2XO0hW5RLVX 5fjhu8r1FYd42FLd38+MiqW16NqVWHaV8gJq6P2CiII98mtROwMsrgnZdfi5nENz F7Gy2cspS4NS6HS40nfzHPXJLlnj6z9vZOuc2HqW99yCqAm2kCd6tcw7JamFf+Qf aiMONdQSh74rW5y3GUOHDg==;
X-AuditID: 11ab0219-557ff70000004c1b-e1-5b4f982cc82b
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id F1.3D.19483.C289F4B5; Wed, 18 Jul 2018 12:42:37 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC200JRXUR0R7A0@mr2-mtap-s02.rno.apple.com>; Wed, 18 Jul 2018 12:42:36 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200100U4Z5W00@nwk-mmpp-sz12.apple.com>; Wed, 18 Jul 2018 12:42:36 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: 6ca8ca8f63305df212074b411a74f5fb
X-Va-E-CD: 26edf7ff94935584dffa79cd798c470b
X-Va-R-CD: 00d6728f8db2d698c6ce62702a7e48e4
X-Va-CD: 0
X-Va-ID: 9b2e6cdd-d742-401d-95be-8d3a3fcfb499
X-V-A: 
X-V-T-CD: 6ca8ca8f63305df212074b411a74f5fb
X-V-E-CD: 26edf7ff94935584dffa79cd798c470b
X-V-R-CD: 00d6728f8db2d698c6ce62702a7e48e4
X-V-CD: 0
X-V-ID: 4cee4a63-f04b-4233-91b3-d51a08c1b0cd
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200A00UP0LA00@nwk-mmpp-sz12.apple.com>; Wed, 18 Jul 2018 12:42:35 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-18_05:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1
Received: from rui-imac.scv.apple.com ([17.192.155.24]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC200737UQZVN10@nwk-mmpp-sz12.apple.com>; Wed, 18 Jul 2018 12:42:35 -0700 (PDT)
Sender: rpaulo@apple.com
Subject: Re: PNE Test Vector
From: Rui Paulo 
In-reply-to: 
Date: Wed, 18 Jul 2018 12:42:35 -0700
Cc: IETF QUIC WG 
Content-transfer-encoding: quoted-printable
Message-id: <99CA16C1-EC22-4DF5-B508-1E3EDCFEF8AC@apple.com>
References: 
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3445.100.20)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUiuPlRm67uDP9og1XfOS1WvD7HbtGzgNuB yWPJkp9MHpMftzEHMEVx2aSk5mSWpRbp2yVwZZy8tpyl4K58xdfuhAbGY7JdjJwcEgImEpf/ /WTuYuTiEBI4yCTR13icCSTBKyAo8WPyPZYuRg4OZgF1iSlTciFq1jNJNF04wg7hdDFJXJ98 ixliErvEn187WCBsbYm1K86xwdif+x8zggwCsScuyYYIc0ks2HqaFcLWlZi1+DkjhM0msf7E EiYIW0ui/9gtFhh744E3cPanF4+g1nJKnP8ykR3C1pHYs2U9K8RtnUwSz88egFqQLfH70mMW iBuCJfa/VYaomcAkcfLwQ7BBwgISEvtPPmSHsGUkTizqALPZBJQknvWdALM5gXqPvdwEdiiL gKrExklbwQ5iFlCQ2L3xASOErS3x5N0FVkgg2kgc/TEVbL6QQIBE84tHYPUiQPW//pxgmcCo OAsprGchwnoWkkkLGJlXMQrnJmbm6GbmGZnqJRYU5KTqJefnbmIEpYPVTJI7GL++NjzEKMDB qMTDe+C/b7QQa2JZcWXuIUZpDhYlcd6Pu8SihQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDq q6+Xf+HadbBCQNCl2OTC+v42l3vMoZnlec+vqAh/2jkj2c9XUXVa6fP4r4+EFxQu+Z1d2zHF Z5kDY9S5ladl458c4599JuFm2YquKNfic8Fe5c2q5a/dHzO+5fMOcbyflrzi2xGhJwsdIqd9 4/g2zVjN69rOJA1xp9X1vdPlPnyZY5or/k+JpTgj0VCLuag4EQCJPM586AIAAA==
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 18 Jul 2018 19:42:40 -0000

My idea was to use the key/CID in PR #1573 to generate test vectors for =
the PNE so that there=E2=80=99s a logical progression in the appendixes.

> On Jul 18, 2018, at 07:11, Eric Rescorla  wrote:
>=20
> As discussed in the meeting, here is a test vector for PNE. It's an =
Initial packet generated by Kazuho but processed by Minq, with the =
output being an edited and annotated version of Minq's logging. Happy to =
help with more logging if that helps.
>=20
>=20
> INPUT PACKET
> =
ffff00000d5006b858ec6f80452b0044efa5d8d307c2973fa0d63fd9b03a4e163b990dd778=
894a9edc8eacfbe4aa6fbf4a22ec7f906b5e8b8ae12e5fcc7924dfeee813842bb2149b805e=
55895084e8393200bb3fc618af7d08281485d914ce42303f5d772b200508a0c00253e332e3=
6a84f657321ac4c8e2cc8a117e95871f12b1f36be8c4b76fa433dc4d3142e6547f4598bf4b=
192130aea6fc20da5158b2162b5a899957da05ded5c70907298fd885847f22a1ecb0a814fe=
0170e23cad20af64f05cc13c74e91824101afdcf5f1532fc2fde936a3a159f76283a26c738=
f778c76e6ca41fa7f134401d39027fd81de17a8021a9c0aaa9b4478fe5c0647941618f3bee=
410caf94c248d2a64b5e45845cd77de13a5ed94034d2bc5f457887351993c1ecfa34fd0c65=
8fea3f8086d26808eef976262ecf0ad646b627945511dde83e26609cd5cfd7ed9f6207d766=
18b44c48bf623bf420dc7c127e5d5f529f083b71a17b17da329bfc38a74bf8cfcf315c7c07=
0b71ebfae3ab351341a767adfdd9e57c738f5de9da53711e886d1472310b917a1c9798e3e9=
b13c7c74beb8d1b82345bea1349415679a9c64b0433b68c871ae08092a1f6106bc06337cd3=
43866ee8185c03fcf3bb0666453f847905547199414c1e57535747be61cdf6778378f121d6=
8df0181ee9e8d9932c1c593c0f8c0a1af0f5262b86205002dced9ecdaee2d0aa07dd4c14f9=
8571e4bea72f8474f63697043e936ebb2bf9716ed0efbdc13005a75cee3a49babc61b96777=
64510eb19828df4e10fb38b79a1efbf04cc2d571949d5403f797361743dcc5e3bf3b4396f7=
ae1a3affbc9f72e540d920363970307e0725fa838d611803251a4a08ccca1983d5b29a5837=
58be63343e88f5591d885b8af695f33adbdd0d941d260287e32ef5a98fd55ac137211021fd=
c23b5d7a5469f578bf7aff6529117996f9ebab5e6dc7b047b356332fea82fdd620eb86f3c1=
d3855c8b8075da59a7662f4a11b977d996b8b3c7657ad4a82a20a7f76ce376c0320086ed02=
9dd615399307983113cc0aa973ecba691e7e4cdc80aefa7e8c8347baba050eaca7dc35a21a=
a854e531dc7758d7d10b8c8e42c1be3bbf266d055ac25c37279ebefa28bbe89a34ad1ab3d2=
3d7a66d1c216a57650e6ec9fc8ba7adfb38e57f20c467166c8fe7944e67f82138160002004=
812c78ba4b5f0da917da4cc14cf8fc10dba3f533facb11ef06d8b8f178ea9c5e8acbbca7b7=
f0e1f6b7a70ec2d5108cc41178056295793bed357accbb03c0582dc69bc77a34030f38cce2=
56c5a9cec6e862146e3f0463f10dd5833257d0a0359166a7e2027d98eaf26cf0d5a4a05f6e=
f8b742f5d314a31deeeabe4ebc3106547e79c6cb933105d907b4c8c60443e97a154694bab5=
edfc781a438675b9de6ed03c77f51458eab61ca2e80ac02cc8c037d8fb3cf129d7107f618d=
66032cc02238a211f78bfa44e7c1bbcfcc627771c188d1b3713ce5e75cd2325a0a2ba08268=
cad13b27d97696ef678b592d0ac80ad1bacb4a1ba75bea8c477f39fc32c2aa20f352bb0da1=
c49b7d3927bcd9dfaf229237081d5fa08924fefd923ff0ac6baad6864b7c10dc73379a5ebd=
9e4678a0c26517656e8e51fca2a51a33fb2cdd5d76d12674c240ba9a4893c1af69b8f2c4ad=
f37c4a47551eb2006a732f6b3b2f338c078ede33946dfe4a55bf644d3b98848693ada1fcb6=
fc16cac339ee65c24dc64b0ae92005354af00ade71e6c5e2efd85c46131d948ff14096b0f0=
6a41d83c8522f30beb4eaaf4a6f908fe2a6ee754c896
>=20
>=20
> GENERATE THE KEYS
> Cleartext keys: cid=3D06b858ec6f80452b =
initial_salt=3D9c108f98520a5c5c32968e950e8a2c5fe06d6c38
>=20
> initial_secret (server in) =3D =
7e0aba2c4b9742d0d130bc7318622ad3b44aca1f09abb19b3f394cd7e20f4be0
> key=3D26080e60d288db7df816a1cb0bc6c7f4 iv=3Db9fdc5b448af3e023422443b =
pn=3D00babbe1be0f0c6618188b4fcca57a96
>=20
> Cleartext keys: cid=3D06b858ec6f80452b =
initial_salt=3D9c108f98520a5c5c32968e950e8a2c5fe06d6c38
> initial_secret (client in) =3D =
82a73572e7cb89523b68c39eaa8325404f86498c8e2437dfdce10f9c34281a3d
> key=3Da79943566c41342f2bc3de6b7c1539df iv=3D84eb954ffe161c3875919f5f =
pn=3D5c0f6472a15658047a3cc1f15478dcf4
>=20
> PNE DECRYPTION
> PNE sample_offset=3D21 sample=3Dc2973fa0d63fd9b03a4e163b990dd778
> Decoded PN block (unknown length): c0000000
> Packet number: 0 length=3D4
>=20

=E2=80=94
Rui Paulo




From nobody Wed Jul 18 20:40:22 2018
Return-Path: 
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 8D9AB130ED3 for ; Wed, 18 Jul 2018 20:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mg5x9Ir-krbv for ; Wed, 18 Jul 2018 20:40:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE27112D949 for ; Wed, 18 Jul 2018 20:40:17 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CEF024537DB4B for ; Thu, 19 Jul 2018 04:40:14 +0100 (IST)
Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 19 Jul 2018 04:40:15 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0382.000; Thu, 19 Jul 2018 09:10:02 +0530
From: Sridhar Bhaskaran 
To: IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kA=
Date: Thu, 19 Jul 2018 03:40:02 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.148.62]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
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, 19 Jul 2018 03:40:21 -0000

Thank you Lucas and Patrick for the clarification. The hint-helium presenta=
tion was very useful. It was just pure co-incidence of me asking this quest=
ion. I did not attend the session in IETF 102.

For the background, 3GPP CT4 is doing a study on the use of QUIC as transpo=
rt protocol for the 5G control plane interfaces. The 5G control plane inter=
faces use HTTP APIs (HTTP/2 over TCP) in 3GPP Release 15. The objective of =
this new study is to look into the benefits of replacing TCP with QUIC from=
 Release 16 onwards.

I am the rapporteur for that study. The study objectives can be found at=20

http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_80_La_Jolla/Docs/CP-181194.zip

In 5G control plane architecture there is a network function called "Securi=
ty Protection and Edge Proxy - SEPP" which sits at the edge of each PLMN (a=
n operator's network) connecting the network functions of one PLMN with the=
 other PLMN. I was wondering how http:// and https:// scheme APIs would wor=
k when SEPP, as a proxy, supports QUIC and the network functions in the two=
 PLMNs support QUIC and they communicate via SEPP which is a HTTP/QUIC prox=
y. Looks like this latter scenario is bit challenging as there is no standa=
rd means as highlighted in slide 6.

Note that this SEPP is not a blind forwarding proxy. It does message transf=
ormations based on operator policies. So as highlighted in slide 8 SEPP's r=
ole is "in the loop".=20

Thanks
Sridhar

-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]=20
Sent: Wednesday, July 18, 2018 7:22 PM
To: Sridhar Bhaskaran ; IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

I presented some slides [1] about HTTP proxying (including HTTP over QUIC) =
at the IETF 102 HTTPbis session this week. I'm not sure if your questions a=
re motivated by that session, or if it is coincidence. There are some visua=
lisations of the various tunnelling options (as I understand them) across t=
he main slides and backup slides.

Regards
Lucas

[1] - https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/hint-hel=
ium.pdf

>-----Original Message-----
>From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Sridhar=20
>Bhaskaran
>Sent: 18 July 2018 11:50
>To: IETF QUIC WG 
>Subject: Questions on HTTP URI schemes and QUIC
>
>Dear Quic experts,
>
>I am Sridhar Bhaskaran from Huawei. Going through the drafts on QUIC=20
>transport and HTTP over QUIC, I have the following queries
>
>1. If a HTTP URI uses http:// scheme and the origin server advertises=20
>alternate service via QUIC, can a HTTP client use QUIC to connect to=20
>the origin server and still use the http:// scheme URI?
>2. If a HTTP URI uses https:// scheme and the HTTP client is configured=20
>to connect to a HTTP proxy and if the HTTP proxy supports QUIC, my=20
>understanding is the following sequence of events
>	a. HTTP client to HTTP proxy QUIC connection is setup
>	b. HTTP client issues a HTTP CONNECT request to the proxy with the=20
>":authority" HTTP/2 pseudo header pointing to the origin server
>	c. HTTP proxy upon getting the CONNECT request sets up a TCP=20
>connection with the origin server
>	d. HTTP proxy sends HTTP CONNECT response to the client
>	e. HTTP client then initiates a TLS connection towards the origin=20
>server via the proxy and the proxy simply tunnels it.
>	f. Actual HTTP traffic happens between client and origin server
>
>Is this correct?
>
>Where I am not clear is whether step /e/ actually happens. If it does,=20
>then for step /f/ is the client required to do ciphering 2 times - one=20
>for the TLS and other for the QUIC connection to proxy itself.
>
>Could you please clarify?
>
>Thanks
>Sridhar


From nobody Thu Jul 19 07:04:39 2018
Return-Path: 
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 674EE130F52 for ; Thu, 19 Jul 2018 07:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=YKCf4d8h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Df26jRYl
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 LHD7YCWTjMvT for ; Thu, 19 Jul 2018 07:04:30 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7033F130EC4 for ; Thu, 19 Jul 2018 07:04:30 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A0EE921F43; Thu, 19 Jul 2018 10:04:29 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 19 Jul 2018 10:04:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=KaLk9A/WHkfZQSqLNcuzM8nw0e4wdJmjqXOLumUH9ss=; b=YKCf4d8h 2//Ypmz14fv7ZA2j1NPui+AW6RF6mXKWPGQSTBo55HNLVkmzSBwZz+1ryQCYRiRx 0BAlL3DrFAjbNlM8ziMbcgHEn7wdWbebpEPc9eNVlBNbqG2n+P4aceBhDTNZKj/H vyOkBFEcrO3Q43UQ+S3l9YdY+z8JhVbieMa0JU8hNknldb1diFsG6poJqsBDoh/J 3ek5GxEPq5D9TPpDN77LBWm3P+bqevJmuI+3sHunjE2b4Ssr1fPO0c77GBp7p80s sLt7Kf4CCzxEJDzcox2DczwwaEgE3BtDoMP3RxwohZjLXRt+iqQSWZS8fbswdHD2 ENu1C6ODtM/zeA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=KaLk9A/WHkfZQSqLNcuzM8nw0e4wd JmjqXOLumUH9ss=; b=Df26jRYlrKbiL9fcUGa+gaGFIJIXiCjT8Yv29fIQMq03F +2JP1rhPv9MTWtQjzHaBvRH3mrtO1n03PoQdUr8xizPd8OglbPIZKEmUesJYqTVE rDCLFC0tW6mufTnZ5y9qFZuLgMDyYT9x4KP0xqr8ddJBVlmwXnYyc1s1MfZVC78l FP8NH/J9bwetkqlyJkBHdDaaTkXZlIkFgyOIdeZ1pYCb3GBSTqrsRKCpP5B8ZqL/ 9XFhYlp1YJLE8hasd83PDIrX9U1TSReCTONhNmjaNy722Muei5GqT29/qLH9lf5B NMAq4RlPBsOVHYtG++rL3I6Kc4s0BMFX9kspHDxDA==
X-ME-Proxy:      
X-ME-Sender: 
Received: from dhcp-873a.meeting.ietf.org (dhcp-873a.meeting.ietf.org [31.133.135.58]) by mail.messagingengine.com (Postfix) with ESMTPA id B4FBA10269; Thu, 19 Jul 2018 10:04:28 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: DRAFT minutes from IETF102 Montreal
Message-Id: 
Date: Thu, 19 Jul 2018 10:04:27 -0400
Cc: Lars Eggert 
To: IETF QUIC WG 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
X-BeenThere: quic@ietf.org
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, 19 Jul 2018 14:04:38 -0000

... are at:
  https://github.com/quicwg/wg-materials/blob/master/ietf102/minutes.md

Thanks to Joe Lorenzo Hall for scribing.

Please submit corrections / improvements as Pull Requests or in response =
to this e-mail.

Cheers,


--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 19 07:26:02 2018
Return-Path: 
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 60A6F1310DB for ; Thu, 19 Jul 2018 07:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Xl+DTjrt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T7hivYks
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 VpzF24U1lcth for ; Thu, 19 Jul 2018 07:25:49 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EDC131056 for ; Thu, 19 Jul 2018 07:25:45 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 87F6F2118B; Thu, 19 Jul 2018 10:25:44 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 19 Jul 2018 10:25:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=Z2FmRC01SEDwzNpi1U32bTx5QGfhcOJV+QT1FY8zyeU=; b=Xl+DTjrt sHB6jBpksiyZr75vwS/3mXxDH5mkKunxrFWRPPv7MHrrPG4C0HH1Akatk2yHmsmn VA6DGMQJJq6XWkWSlVI/KvT012vuPDMN3aSDCFXPEoibtND1iRvV92NVpJNLofpJ tSMhFHMG2Jn8Xp0Td3TdmwgAaUALEFmPyb49iW6ZWfdcTd+ggNOvLs6XUS2yRqdY mzQbF4nPFjfL5WWIr3lHLJkd3AeBKqUy+clhuVX9TkfJBqTPvfzDzRWDaZK4S2qI azg20m+i/jbg3Jm99z7EeS+Rr3/a97jUIYHhl/4cstx94vitWXtOMhMnNE30dWL2 QUV6eWqf6NcGWQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=Z2FmRC01SEDwzNpi1U32bTx5QGfhc OJV+QT1FY8zyeU=; b=T7hivYks+h6hUxYDUaBwlNa07Hzk5GSn914H+iCKIVT5W MF5y6M+fkdyqrfih5FvKDHxHK6kxBFjMakNGXK9TaGONOkZPDXvAeHprWXqtGX6p j1Iz/5sFApOv3Epc8kVdh57LbazCqbDT9dNOEINAd9WgpIrtdnWJ6Pz/Yi9JWox8 jZ99liSejErygeuKRZTwtiUxpwuF02SlA2r2tIq0+Wa1sU7qReYrAxuXmuHtWZ96 BWxNA/9Zxxxf1B3XSgesDPXCJgfCmqaJuQI/PZh0vZFFnJwIo93F85S5zwF9shh6 sHmcdudoaSGzPzpif46OughLJt78GKr+En+Mfmquw==
X-ME-Proxy:      
X-ME-Sender: 
Received: from dhcp-873a.meeting.ietf.org (dhcp-873a.meeting.ietf.org [31.133.135.58]) by mail.messagingengine.com (Postfix) with ESMTPA id B5AFC10273; Thu, 19 Jul 2018 10:25:43 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Spin Bit Experimental Design Reviews at the New York Interim
Message-Id: <50AB6C0B-C9BC-4B96-84B9-578F0FBC2B37@mnot.net>
Date: Thu, 19 Jul 2018 10:25:42 -0400
Cc: Lars Eggert 
To: IETF QUIC WG 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
X-BeenThere: quic@ietf.org
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, 19 Jul 2018 14:26:00 -0000

As you may remember, we decided to adopt the Spin Bit draft =
, but =
defer deciding whether it'll actually be published as part of QUIC until =
we get some validation that it helps to operate networks.=20

We've encouraged folks to gather data to guide that decision by running =
experiments, with the aim of being able to make a decision in our =
Bangkok meeting.

To help those experiments succeed in guiding our decision, we'll reserve =
some time to review experiments that request it in our New York interim =
meeting =
.=20

The goal of these presentations will be to guide the experimental design =
with feedback from the working group; not to report or judge the results =
of the experiments (which will happen in Bangkok).

Please note:

* Reviews (both individually and collectively) will be time-bounded; =
plan on approximately 15 minutes (each) to present, with another 15 to =
discuss (extended if there's WG interest).
* This is ONLY an experimental design review; expect feedback on the =
utility of the design and its results.
* No other discussion or decisions about the Spin Bit will take place in =
the NYC interim.

If you'd like to request a review, please contact the chairs.=20

--
Mark Nottingham   https://www.mnot.net/


From nobody Thu Jul 19 12:36:41 2018
Return-Path: 
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 2A5AB13111B for ; Thu, 19 Jul 2018 12:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MTxklcdns1YG for ; Thu, 19 Jul 2018 12:36:31 -0700 (PDT)
Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECC713107A for ; Thu, 19 Jul 2018 12:36:30 -0700 (PDT)
Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w6JJaNh5008114; Thu, 19 Jul 2018 20:36:23 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0389.001; Thu, 19 Jul 2018 20:36:23 +0100
From: Lucas Pardue 
To: Sridhar Bhaskaran , IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMA==
Date: Thu, 19 Jul 2018 19:36:23 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-23980.000
x-tm-as-result: No-6.773700-8.000000-10
x-tmase-matchedrid: cgbqQT5W8he7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p2o+b+yOP0oGCGZ 6VVOVYeW1Fc61VCGvh1ksMOLRwwsVw9DNWzI2FEPQJOfGClqJxm0xIzVr7UlbzaULO2AzDKgBK6 s6YP1Blq61M5/Y3W4NE/SoXfxRM/UK2D6pmarVf/XIwmz2YEJxYrogmbAtARIOdl/GMFVBFtnHb mOz4dRQ+fOVcxjDhcwPcCXjNqUmkUgBwKKRHe+r/NQIWjWJOcZRjHPAocdpPudfkZxob/od5Gct dgmmRomL4wskVNIozg=
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--6.773700-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-23980.000
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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, 19 Jul 2018 19:36:40 -0000

Hi Sridhar,

Thanks for sharing the 3GPP work.

Sridhar wrote:

>Note that this SEPP is not a blind forwarding proxy. It does message
>transformations based on operator policies. So as highlighted in slide 8 S=
EPP's
>role is "in the loop".

Are the required transformations shareable (or captured in some 3GPP docume=
nt). We are aware of a congestion control use case but additional ones are =
welcome.

However, considering the model I have for tunnelling QUIC, the amount of in=
-the-loop processing possible is likely to be minimal due to the end-to-end=
 QUIC security context. The proxy will have access to IP, UDP and QUIC head=
ers but not QUIC protected payload.

Kind regards
Lucas



From nobody Fri Jul 20 11:33:29 2018
Return-Path: 
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 2E31B131120 for ; Fri, 20 Jul 2018 11:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 UIZcirNhJk5V for ; Fri, 20 Jul 2018 11:33:25 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 40360130DF1 for ; Fri, 20 Jul 2018 11:33:25 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id h4-v6so11119821qtj.7 for ; Fri, 20 Jul 2018 11:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=czAeaw4kHwEAL8TidalSzrqLZYjKpRazHZKtn0E7r2A=; b=lMfAW+rsip0Hzf0QeltlA7BOGNBM6CcD+TfVz4v/j3egtHIlkEjbWW7pG9ukNd8f0B D1EQjXFv6MiSxUESizbqDBRiVcfR5xR/SIXyY0QyaYU7NOtvlGP0tRF5/mOwmJpXPrgA 9JUFoDNP8I86LilNpmJtzY8PKATSWzsOQHV1Wjof49T0yoVymb1dPJkBneuNWUmH8MK2 r2n4pPSyfmune7YtAK5PiJvSbA+hS49nZYCSEUfHcCI6x4gLediL6rcV8c0EvI7SvM4k C6Q1HCi0ZYyaoxCHW0AtdK0mD2Xy/yOW59lkC7Ubbz2GQ/kuLJ0lSs3ziH8jSK3F+T34 wB0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=czAeaw4kHwEAL8TidalSzrqLZYjKpRazHZKtn0E7r2A=; b=eLIBVc5U7S1zG6WbYsu2qCiy9vVKrRZEcX1ksOMqHSHhyzXkJugtvd1sReLPsEmjKl kJdYtQAyNfaXmotHyfA0pgx+f7yMfhRlDDzBSbH5zDF4EkZ2NOqPQFoTA9hghrDFlA62 Rx5jfzqXtXRUU3VSho1WE+vcZvRgSZUWAolTLHmWEU6HpdPCaK4Qll3ZXc2YrEA5SiL+ 3hQli12o5UM0ZfFavmnx5J8f1hR4YhmLJy0Hu/P4ZwDHnJ/WhiiTD8YlgeUjErOGKEsI EH9dU8oOLg/92Ntlr0u3c5n5hWWbC7iEhP5E128E/hU9dPi+DhOWFiJ7CSejaqW5CjSo ccgA==
X-Gm-Message-State: AOUpUlGclL+CgqaZI9NUHcxpOL/Azim4t+VoJIwZH8PcMoizD1AEsrMP 9ADZPM7IDLxiKptNX81rz4p/HbtMm8g=
X-Google-Smtp-Source: AAOMgpdbmH28iyy3bUh1ZJSCaCsJ9PlV8qSDlVZPR7BaTfpyNbOza2xI0mzVkDpfo96GuJ3hAja5hQ==
X-Received: by 2002:ac8:2f7c:: with SMTP id k57-v6mr3072782qta.424.1532111604232;  Fri, 20 Jul 2018 11:33:24 -0700 (PDT)
Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id s31-v6sm2209832qtc.68.2018.07.20.11.33.23 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jul 2018 11:33:24 -0700 (PDT)
Date: Fri, 20 Jul 2018 14:33:19 -0400
From: Dmitri Tikhonov 
To: IETF QUIC WG 
Subject: qpack: no need to ack refless header blocks
Message-ID: <20180720183319.GA23032@ubuntu-dmitri>
Mail-Followup-To: IETF QUIC WG 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 20 Jul 2018 18:33:27 -0000

There is no need to acknowledge header blocks that do not reference
the dynamic table.  These acknowledgements do not contain any
information useful to the encoder.  I propose that the draft be
modified to state that

    A Header Acknowledgement is emitted only if the header block
    references the dynamic table (only when Largest Reference in
    the Header Data Prefix is zero).

This a) saves bytes and b) allows the encoder to drop state for
such header blocks as soon as they are encoded.

  - Dmitri.


From aep@exys.org  Sat Jul 21 07:20:35 2018
Return-Path: 
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 14E7C124D68 for ; Sat, 21 Jul 2018 07:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=exys-org.20150623.gappssmtp.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 bEU6XTMwJN2C for ; Sat, 21 Jul 2018 07:20:32 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 A9B99130DBE for ; Sat, 21 Jul 2018 07:20:32 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id i12-v6so26236645oik.2 for ; Sat, 21 Jul 2018 07:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exys-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+cBUUVEZaKLNqhFvVXBUHs7Yf2dKFzlg0xPJtwRvhwg=; b=XoYKiGfC1muDa+IrWo8sSqJ1FjoQt2auMPKJPbikwCVOQjZLSRy02WR8i0i+kWaNDv 3J5jTWELH05YzF98st8zkDrVe2mFo6LefW2qKaBpnWptIsOcbG3uWbHY25U2nbzDtfl9 c64/LD6bkyaym0fb0Y0/Z57KzqXDC34gPUJLWNRrKybvH8T1Jr5dkMdXK2956cUzW5YY ujbw9QUoQu0HfxWqxGDAGTSS5rOiXgujIvh428OK4E/CrNzqI6u3md7UL/L97gI/iNz7 0WYS7S5uah/ma1vzCV5m7K9fWY5ThDpfmjG/MQEpjbOfGbTfuQvX5HqLRqvx08omW0qA NLbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+cBUUVEZaKLNqhFvVXBUHs7Yf2dKFzlg0xPJtwRvhwg=; b=pL+LAdYkweaDYVjOy6RyzTSxv9t+fZrvTH1uG3OWUa9GApdpHna9efLzLfBzTaBI01 ccLcoZTL324kZm4pPRg2C7nVPNKw6VuXbtz5ekhvy1I+6VcP9j3148HhJR5c+riyfZd3 neJGxTD/zm7YUhb1VTOktWE9WxgiVVjx6GdZaJArAP1mEUE35GPdOpchMlnCEpW7b+DH WQgHP6wT9/4e5PgXYzK4074OoylU7Vn/jfOQLsIP02KSi1AF5mAURTiHIA69eHV0Ib5c qCOyJCEnzKutCgXWOxqaf0m/ozAVP/gd4NDSde+Vn1MSS9V+ethol0NjcpHhJLjaspVf rUPQ==
X-Gm-Message-State: AOUpUlEz71YQQmFGT6kc47IjlYHxDq59BcL3WkNj3NGRrLELkBmH9buR IVExCC5eIiPZ/SICEYywTF3F9MIKZ25vsCwkxW+M7PJs8po=
X-Google-Smtp-Source: AAOMgpfg0CaC57xLFgJY4/vZAFoMGb2qLnudJsxIfyO1rOgYvpiK/J/SOL6hwSMZ60wcCfDnd+3/Mv87zxgqvxFq5iU=
X-Received: by 2002:aca:5354:: with SMTP id h81-v6mr1792687oib.299.1532182831196;  Sat, 21 Jul 2018 07:20:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:5dd0:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 07:20:30 -0700 (PDT)
X-Originating-IP: [77.180.150.202]
From: Arvid Picciani 
Date: Sat, 21 Jul 2018 16:20:30 +0200
Message-ID: 
Subject: RTT sampling on retransmissions
To: quic@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 21 Jul 2018 14:23:20 -0000

Hi,

UpdateRtt in https://tools.ietf.org/html/draft-ietf-quic-recovery-13#section-3.5.5
does seem to calculate the RTT from an ack on any packet, even if the
packet was resent.

1. In a TLP event The oldest packet is resent and the sent_time reset
to the current time.
2. Eventually that packet is acked, because the network was just slow.
3. RTT is calculated from the last sent_time (which was the time it was resent).
4. RTT is way too small now, leading to lots of timeouts.


what am i missing here?

https://tools.ietf.org/html/rfc6298 section 2 specifically says that
RTT must NOT be calculated from retransmissions. Is a "retransmitted"
bit in the quic-recovery left as exercise to the reader or should
retransmissions actually never be passed to OnPacketSent?

/b/


From nobody Sat Jul 21 09:45:14 2018
Return-Path: 
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 212AB130DFF for ; Sat, 21 Jul 2018 09:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level: 
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 eCTH1238wy_4 for ; Sat, 21 Jul 2018 09:45:10 -0700 (PDT)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 CC88A130DC4 for ; Sat, 21 Jul 2018 09:45:09 -0700 (PDT)
Received: by mail-yb0-x231.google.com with SMTP id s1-v6so5791124ybk.3 for ; Sat, 21 Jul 2018 09:45:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Hs4pgO7NsInNe7RbsmpqLJqsTdJfgKGbtHeS+Qj2EUM=; b=sOKQyGwwBnznNFWcNjh559S7De1GqOJ9lZWSFUcIG8JZ/62ugqa9ZcQudQ5Y15Jje/ QPT/tUWdzZWl3y/PWkEtkWua058TKZQfMkwrFhLZh82n6c0L5yFp4Aoxv75xTmnFBphX rxrycOB+bstPPGPElw1R5jIAY/jmGHqK4aq8R4xz9wHI5HdOrZPxCnugeH+LsM0TwZUE SKautyRjdK8xdg1Vo2nEElwVPuwWnB/yRnTfO/6r+U01i5SqjkuJYfuhaIn9aJd57CTY a70q5kxxvoca12pclPuf+SIDrZ+vjnpro6E/sjCpfjvJk7AKJrMrakmgM+KCHMsl/Jmj G6tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hs4pgO7NsInNe7RbsmpqLJqsTdJfgKGbtHeS+Qj2EUM=; b=ItzlrexPG3kXeC8epC4shZ3ZW/XyLV8/1q1pIDXdKuXpbkhlNrybFIcgYF0NMtZF1F 6A2nK3eHOD8LQODMzTmbJyRXy/wcsv9Ru7x0u6Y2Z/KhH3YPwnodqT2A+wwTkSj5gXjy PIJB+IqX3FDFLbq+mXRRYha14WbMFY3cJWQ0nDMZTQdPYSJ4id+DuUVppurf6ds56Wnx WKLzIQ1jYEW+C9FvtZB2T/n8sL1RjBbxq86D2z6blU0Xp1Hwg7I4uIYe8pfsyEix+uCp +L3UhztrfdUeVpjUf/1/kwHhKz4qFN9LdV8/oDDgveEMxtXmXyDPNLiIwVKbZjtGjH2t r8bA==
X-Gm-Message-State: AOUpUlEuUXLxkpBhqrwIVJUZREl5P1veUOakR69iLhXl/FXyvG7Qmpq5 M5KKMV3Pxs6mgkN5VTcSUK50LcvTfB87iyBurp2zTnBZyrE=
X-Google-Smtp-Source: AAOMgpdBJPoO7VhgkiZVv1Bo3KmKO7tY5yjRpPnkmp8BB7H+On/f1FBgyPjxr/v1fFJEoUXuXRTXZeOL7ULYnZuDZ0Q=
X-Received: by 2002:a5b:3cd:: with SMTP id t13-v6mr3444424ybp.206.1532191508687;  Sat, 21 Jul 2018 09:45:08 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Ian Swett 
Date: Sat, 21 Jul 2018 12:44:56 -0400
Message-ID: 
Subject: Re: RTT sampling on retransmissions
To: aep@exys.org
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000009b440105718522cb"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 21 Jul 2018 16:45:12 -0000

--0000000000009b440105718522cb
Content-Type: text/plain; charset="UTF-8"

QUIC doesn't retransmits packets.  If data needs to be retransmitted
because it's lost, it's sent in a new packet with a new packet number.  The
new packet number prevents issues with ambiguity.

See recovery section 2(particularly 2.1.2) for more details:
https://tools.ietf.org/html/draft-ietf-quic-recovery-13#section-2



On Sat, Jul 21, 2018 at 10:23 AM Arvid Picciani  wrote:

> Hi,
>
> UpdateRtt in
> https://tools.ietf.org/html/draft-ietf-quic-recovery-13#section-3.5.5
> does seem to calculate the RTT from an ack on any packet, even if the
> packet was resent.
>
> 1. In a TLP event The oldest packet is resent and the sent_time reset
> to the current time.
> 2. Eventually that packet is acked, because the network was just slow.
> 3. RTT is calculated from the last sent_time (which was the time it was
> resent).
> 4. RTT is way too small now, leading to lots of timeouts.
>
>
> what am i missing here?
>
> https://tools.ietf.org/html/rfc6298 section 2 specifically says that
> RTT must NOT be calculated from retransmissions. Is a "retransmitted"
> bit in the quic-recovery left as exercise to the reader or should
> retransmissions actually never be passed to OnPacketSent?
>
> /b/
>
>

--0000000000009b440105718522cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


QUIC doesn't retransmits packets.=C2=A0 If data needs =
to be retransmitted because it's lost, it's sent in a new packet wi=
th a new packet number.=C2=A0 The new packet number prevents issues with am=
biguity.

See recovery section 2(particularly 2.1.2) for =
more details:=C2=A0https://tools.ietf.org/html/draft-ietf-quic-recovery-=
13#section-2



On Sat, Jul 21, 2018 at 10:23 AM Arvid Picci=
ani <aep@exys.org> wrote:
Hi,



UpdateRtt in https://tools.ietf=
.org/html/draft-ietf-quic-recovery-13#section-3.5.5

does seem to calculate the RTT from an ack on any packet, even if the

packet was resent.



1. In a TLP event The oldest packet is resent and the sent_time reset

to the current time.

2. Eventually that packet is acked, because the network was just slow.

3. RTT is calculated from the last sent_time (which was the time it was res=
ent).

4. RTT is way too small now, leading to lots of timeouts.





what am i missing here?



https://tools.ietf.org/html/rfc6298 section 2 specifically =
says that

RTT must NOT be calculated from retransmissions. Is a "retransmitted&q=
uot;

bit in the quic-recovery left as exercise to the reader or should

retransmissions actually never be passed to OnPacketSent?



/b/






--0000000000009b440105718522cb--


From nobody Sat Jul 21 17:45:39 2018
Return-Path: 
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 BD17C130EA0 for ; Sat, 21 Jul 2018 17:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=mnot.net header.b=Ly7Mt/wy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V2AinZh4
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 p0Na9vd5UwUY for ; Sat, 21 Jul 2018 17:45:23 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31D41271FF for ; Sat, 21 Jul 2018 17:45:22 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4CE672B9 for ; Sat, 21 Jul 2018 20:45:22 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 21 Jul 2018 20:45:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=5YZJt3ugh0jGgV52O eZAK8faaWn71kVwpxbnf2VRIJQ=; b=Ly7Mt/wydUd4zTGc3RGYDg9b3hV4f+UxW L93l4Z6/p718lH11/yZCJnN/7Lhi1Z0jRxjy4IP8Yh0/xwefKJvAMmxkK2XFNKc3 u3djmNhQu6sL+B3ww0W81SjGKQXWOS4smpULEWVsvKi0ic2kj9zYllp+fKK325As djPjBdxKhZBbsgdOVfFJ+uaRL0g+QiNIQPdjdrov047+WZ0EtaA7nECCHO0aLSNa +47hneNGxjq224xrpk8nJxNgi7p4bX2HIKFMH2SLX3gmv1bdSgeUklswdjyvHgga yP0FD6nxa5DIQQvkZ7GxD+GeLn7mSFjnUHOF+SrrUMo3y7QZBASRg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=5YZJt3ugh0jGgV52OeZAK8faaWn71kVwpxbnf2VRIJQ=; b=V2AinZh4 PhDkei6lK3gMHzjlva3jV8BwbHdEx8kcNf18fkrCOvV5kq5pZLgWQrnn1IS0imiO 7Paw0bG+WTRw5VBxF/9S8m0vdFmW4QdFJ27BAuKqsKDuY18tpKk4iylnXO3AStoy ae5n8sqqVURifS/J6di+zaliNlBJoMoeIA9/jP+Now/Nk2SLN2u+kUDlP/I91xS0 xoMJG7t+4Bd4i1/mr8hYVTZjkStt7U1vNgpj/t9xJiaZLj6D6kaFkEimcTUyj2/2 c51aMu7eAW2jcgZssnO521PLq3xyUagw4Zxkogn5G2vDywIY0tNlBzXoGmLBU5MS nFUcaWJ6NxPQ6g==
X-ME-Proxy:      
X-ME-Sender: 
Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 7417A10273 for ; Sat, 21 Jul 2018 20:45:20 -0400 (EDT)
Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id DB9A8C50D5 for ; Sun, 22 Jul 2018 00:45:17 +0000 (UTC)
Content-Type: multipart/alternative; boundary="===============3410778860500670307=="
MIME-Version: 1.0
From: =?utf-8?q?Github_Notifications?= 
To: quic@ietf.org
Subject: Weekly github digest (QUIC Working Group Specifications)
Message-Id: <20180722004517.DB9A8C50D5@cloud.mnot.net>
Date: Sun, 22 Jul 2018 00:45:17 +0000 (UTC)
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 22 Jul 2018 00:45:38 -0000

--===============3410778860500670307==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Events without label "editorial"

Issues
------
* quicwg/base-drafts (+13/-7/=F0=9F=92=AC118)
  13 issues created:
  - draft-ietf-quic-recovery: kMarkReductionFactor is not defined (by aep)
    https://github.com/quicwg/base-drafts/issues/1594 =

  - transport: danging reference to Section 11 of QUIC-TLS (by reschke)
    https://github.com/quicwg/base-drafts/issues/1593 =

  - Single Stream of Bytes for CRYPTO Frames (by nibanks)
    https://github.com/quicwg/base-drafts/issues/1592 =

  - Use of "supports ECN" is confusing (by mirjak)
    https://github.com/quicwg/base-drafts/issues/1587 =

  - qpack: successful header block processing as opposed to what? (by dtikh=
onov)
    https://github.com/quicwg/base-drafts/issues/1586 =

  - qpack: control stream is not defined (by dtikhonov)
    https://github.com/quicwg/base-drafts/issues/1583 =

  - hq: Does ignored data/frames cause flow control updates? (by LPardue)
    https://github.com/quicwg/base-drafts/issues/1580 =

  - Go Back to Single Packet Number Space (by nibanks)
    https://github.com/quicwg/base-drafts/issues/1579 =

  - Keep PN out of AEAD (by mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1578 =

  - Consider making long header payload length 16bits (by DavidSchinazi)
    https://github.com/quicwg/base-drafts/issues/1577 =

  - Consider encrypting the long header payload length as part of packet nu=
mber encryption (by DavidSchinazi)
    https://github.com/quicwg/base-drafts/issues/1576 =

  - Consider simplifying Packet Number Encryption (by DavidSchinazi)
    https://github.com/quicwg/base-drafts/issues/1575 =

  - Connection ID lengths 1, 2 and 3 bytes can't be encoded (by marten-seem=
ann)
    https://github.com/quicwg/base-drafts/issues/1570 =


  21 issues received 118 new comments:
  - #1443 Stateless Reset Eternal Ping Pong (19 by kazuho, marten-seemann, =
mikkelfj, martinthomson, ianswett, igorlord, dtikhonov)
    https://github.com/quicwg/base-drafts/issues/1443 [-transport] [design] =

  - #1577 Consider making long header payload length 16bits (16 by kazuho, =
marten-seemann, janaiyengar, mikkelfj, ianswett, larseggert, DavidSchinazi,=
 martinthomson, mcmanus, nibanks, dtikhonov)
    https://github.com/quicwg/base-drafts/issues/1577 [-transport] [design] =

  - #1592 Single Stream of Bytes for CRYPTO Frames (15 by dtikhonov, marten=
-seemann, ekr, ianswett, nibanks)
    https://github.com/quicwg/base-drafts/issues/1592 =

  - #1579 Go Back to Single Packet Number Space (12 by kazuho, ianswett, ek=
r, nibanks)
    https://github.com/quicwg/base-drafts/issues/1579 [-tls] [-transport] [=
design] =

  - #1580 hq: Does ignored data/frames cause flow control updates? (10 by m=
artinthomson, mikkelfj, LPardue, MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1580 =

  - #1556 HTTP SETTINGS: define setting content encoding (8 by lnicco, afri=
nd, LPardue)
    https://github.com/quicwg/base-drafts/issues/1556 [-http] =

  - #1575 Consider simplifying Packet Number Encryption (7 by DavidSchinazi=
, martinthomson, mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1575 [-tls] =

  - #1428 When the sender is using standard Reno congestion control, ack ev=
ery ~2 packets (5 by gloinul, nibanks, pravb, ianswett)
    https://github.com/quicwg/base-drafts/issues/1428 [-recovery] [design] =

  - #1570 Connection ID lengths 1, 2 and 3 bytes can't be encoded (5 by mar=
tinthomson, janaiyengar, ekr, mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1570 [-invariants] [design=
] =

  - #1576 Consider encrypting the long header payload length as part of pac=
ket number encryption (4 by DavidSchinazi, rpaulo, mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1576 [-transport] [design] =

  - #1507 Can a client send 0-RTT data when receiving Retry? (3 by kazuho, =
martinthomson)
    https://github.com/quicwg/base-drafts/issues/1507 [-transport] [design] =

  - #814 Add a MESSAGE frame optimized for sub-MTU payloads (2 by LPardue, =
ianswett)
    https://github.com/quicwg/base-drafts/issues/814 [-transport] [design] =
[quicv2] =

  - #981 Explicitly communicate and include ACK delay in RTO computations (=
2 by pravb, ianswett)
    https://github.com/quicwg/base-drafts/issues/981 [-recovery] [design] =

  - #941 Resume HTTP/2 TLS from QUIC ? (2 by kazuho)
    https://github.com/quicwg/base-drafts/issues/941 [-tls] [design] [has-p=
roposal] [quicv2] =

  - #1017 Eliminating the fixed minimum RTO (2 by pravb, ianswett)
    https://github.com/quicwg/base-drafts/issues/1017 [-recovery] [design] =
[parked] =

  - #1430 Interleaved Stream IDs are awkward (1 by ianswett)
    https://github.com/quicwg/base-drafts/issues/1430 [-transport] [design] =

  - #1438 Resending ACKs increases max_ack_delay unnecessarily (1 by ianswe=
tt)
    https://github.com/quicwg/base-drafts/issues/1438 [-recovery] [design] =

  - #1578 Keep PN out of AEAD (1 by mikkelfj)
    https://github.com/quicwg/base-drafts/issues/1578 =

  - #1594 draft-ietf-quic-recovery: kMarkReductionFactor is not defined (1 =
by ianswett)
    https://github.com/quicwg/base-drafts/issues/1594 =

  - #1102 wrong MSS value in congestion avoidance phase (1 by ianswett)
    https://github.com/quicwg/base-drafts/issues/1102 [-recovery] [design] =

  - #1535 Long header + token and PNE (1 by kazuho)
    https://github.com/quicwg/base-drafts/issues/1535 [-transport] [design] =


  7 issues closed:
  - draft-ietf-quic-recovery: kMarkReductionFactor is not defined https://g=
ithub.com/quicwg/base-drafts/issues/1594 =

  - Single Stream of Bytes for CRYPTO Frames https://github.com/quicwg/base=
-drafts/issues/1592 =

  - hq: Does ignored data/frames cause flow control updates? https://github=
.com/quicwg/base-drafts/issues/1580 =

  - Fragility in ECN counters with lost acks https://github.com/quicwg/base=
-drafts/issues/1481 [-recovery] [-transport] [design] =

  - Consider encrypting the long header payload length as part of packet nu=
mber encryption https://github.com/quicwg/base-drafts/issues/1576 [-transpo=
rt] [design] =

  - wrong MSS value in congestion avoidance phase https://github.com/quicwg=
/base-drafts/issues/1102 [-recovery] [design] =

  - Interleaved Stream IDs are awkward https://github.com/quicwg/base-draft=
s/issues/1430 [-transport] [design] =




Pull requests
-------------
* quicwg/base-drafts (+13/-8/=F0=9F=92=AC17)
  13 pull requests submitted:
  - Single Packet Number Space (by nibanks)
    https://github.com/quicwg/base-drafts/pull/1591 =

  - Remove alarm references from the transport doc. (by rpaulo)
    https://github.com/quicwg/base-drafts/pull/1590 =

  - Do not use undefined term "successful processing" (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1589 =

  - Fix: replace "control stream" with "Encoder Stream" (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1588 =

  - Fix: ACKs permit encoder to evict, not to avoid eviction (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1585 =

  - Add forward reference to decoder stream; fix another ref to it (by dtik=
honov)
    https://github.com/quicwg/base-drafts/pull/1584 =

  - Remove packets from flight when RTO is verified (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1582 =

  - Change early retransmit timer to 1/8th (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1581 =

  - Add MaxAckDelay sub-section (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1574 =

  - Add an appendix containing test vectors for "Initial". (by rpaulo)
    https://github.com/quicwg/base-drafts/pull/1573 =

  - Fix: reference the newer ChaCha20 spec: RFC 8439 (by dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1572 =

  - Recovery slides (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1571 =

  - Remove MSS (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1569 =


  10 pull requests received 17 new comments:
  - #1559 Replace alarm with timer (4 by rpaulo, janaiyengar, ianswett)
    https://github.com/quicwg/base-drafts/pull/1559 =

  - #1582 Remove packets from flight when RTO is verified (2 by siyengar)
    https://github.com/quicwg/base-drafts/pull/1582 =

  - #1573 Add an appendix containing test vectors for "Initial". (2 by rpau=
lo, masaori335)
    https://github.com/quicwg/base-drafts/pull/1573 =

  - #1588 Fix: replace "control stream" with "Encoder Stream" (2 by martint=
homson, dtikhonov)
    https://github.com/quicwg/base-drafts/pull/1588 =

  - #1496 CID Lifetime Management (2 by kazuho, ianswett)
    https://github.com/quicwg/base-drafts/pull/1496 [-transport] [design] =

  - #1551 Editorial recovery fixes (1 by ianswett)
    https://github.com/quicwg/base-drafts/pull/1551 =

  - #1562 Security considerations (1 by janaiyengar)
    https://github.com/quicwg/base-drafts/pull/1562 =

  - #1565 Simplify receiver verification of ECN counters (1 by janaiyengar)
    https://github.com/quicwg/base-drafts/pull/1565 =

  - #1572 Fix: reference the newer ChaCha20 spec: RFC 8439 (1 by martinthom=
son)
    https://github.com/quicwg/base-drafts/pull/1572 =

  - #1581 Change early retransmit timer to 1/8th (1 by siyengar)
    https://github.com/quicwg/base-drafts/pull/1581 =


  8 pull requests merged:
  - Remove alarm references from the transport doc.
    https://github.com/quicwg/base-drafts/pull/1590 =

  - Remove packets from flight when RTO is verified
    https://github.com/quicwg/base-drafts/pull/1582 =

  - Security considerations
    https://github.com/quicwg/base-drafts/pull/1562 =

  - Simplify receiver verification of ECN counters
    https://github.com/quicwg/base-drafts/pull/1565 =

  - Fix: reference the newer ChaCha20 spec: RFC 8439
    https://github.com/quicwg/base-drafts/pull/1572 =

  - Remove MSS
    https://github.com/quicwg/base-drafts/pull/1569 =

  - Editorial recovery fixes
    https://github.com/quicwg/base-drafts/pull/1551 =

  - Replace alarm with timer
    https://github.com/quicwg/base-drafts/pull/1559 =



Repositories tracked by this digest:
-----------------------------------
* https://github.com/quicwg/base-drafts

--===============3410778860500670307==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (QUIC Working Group Specifications)





Sunday July 22, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+13/-7/=F0=9F=92=AC118)

  
13 issues created:

  

  
21 issues received 118 new comments:

  

  
7 issues closed:

  




Pull requests


quicwg/base-drafts (+13/-8/=F0=9F=92=AC17)

  
13 pull requests submitted:

  

  
10 pull requests received 17 new comments:

  

  
8 pull requests merged:

  



Repositories tracked by this digest:





--===============3410778860500670307==--


From nobody Mon Jul 23 20:37:06 2018
Return-Path: 
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 0567E130FCE for ; Mon, 23 Jul 2018 20:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZBkmHvda_fdq for ; Mon, 23 Jul 2018 20:37:02 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D4C130DFE for ; Mon, 23 Jul 2018 20:37:01 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 53754BFD5272C for ; Tue, 24 Jul 2018 04:36:58 +0100 (IST)
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 24 Jul 2018 04:36:59 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0382.000; Tue, 24 Jul 2018 09:06:50 +0530
From: Sridhar Bhaskaran 
To: Lucas Pardue , IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3Q
Date: Tue, 24 Jul 2018 03:36:50 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.148.205]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 24 Jul 2018 03:37:04 -0000

Hi Lucas,

>> Are the required transformations shareable (or captured in some 3GPP doc=
ument). We are aware of a congestion control use case but additional ones a=
re welcome.

The draft change requests are currently being discussed between 3GPP SA3 an=
d CT4. You will see the updated specs once this is agreed - after September=
. The latest draft CR is available @ http://www.3gpp.org/ftp/tsg_sa/WG3_Sec=
urity/TSGS3_91Bis_LaJolla/Docs/S3-181937.zip. Note that this draft CR is fo=
r 3GPP release 15 where the transport is TCP/TLS. My questions below are fo=
r the study item in 3GPP release 16 where we are exploring if QUIC can be u=
sed as an alternate transport.

>> However, considering the model I have for tunnelling QUIC, the amount of=
 in-the-loop processing possible is likely to be minimal due to the end-to-=
end QUIC security context. The proxy will have access to IP, UDP and QUIC h=
eaders but not QUIC protected payload.

Yes this is understood. One follow up question is - can a bump in TLS (TLS =
interception) where a proxy provides certificates on behalf of origin host =
signed by its own CA (provided the client is configured to trust this CA) w=
ork with QUIC? Can this be made to work to intercept the protected payload =
at a proxy?

Thanks
Sridhar
-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]=20
Sent: Friday, July 20, 2018 1:06 AM
To: Sridhar Bhaskaran ; IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

Thanks for sharing the 3GPP work.

Sridhar wrote:

>Note that this SEPP is not a blind forwarding proxy. It does message=20
>transformations based on operator policies. So as highlighted in slide=20
>8 SEPP's role is "in the loop".

Are the required transformations shareable (or captured in some 3GPP docume=
nt). We are aware of a congestion control use case but additional ones are =
welcome.

However, considering the model I have for tunnelling QUIC, the amount of in=
-the-loop processing possible is likely to be minimal due to the end-to-end=
 QUIC security context. The proxy will have access to IP, UDP and QUIC head=
ers but not QUIC protected payload.

Kind regards
Lucas



From nobody Tue Jul 24 09:08:28 2018
Return-Path: 
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 4DFA5130F3B for ; Tue, 24 Jul 2018 09:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, 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 FBrhuUtwbBy8 for ; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 26B05131156 for ; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id k12-v6so8447699oiw.8 for ; Tue, 24 Jul 2018 09:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M9pBVUPsSjXpo31w58FtVDjFxll6ybZhF0YzAHEV340=; b=H0HsJ0zrTdqnaAybokqnB4hFV8EPHKLntRfK0bx9DzQad8bwj44WQmVV1P40lXoJBe MTDulgXxPCxwCOhjlyoIM/1ev/ougP3ooJz8P+Mo0lay0zJ4TCJpTBV23gF5twftYca4 yd9z88pXSLFVbL51MYqfYdwgYR+VBa8B+94FkmbCW7wwN+QQCV+4ccQQqZn5oNvfRCBn ENIvAoUlTFJHXKNwT1BAklbFReWMP1WmdJWX6ECMzvo1JOYKQOAAdDLTwXVAfTK5egBS 5WLCMQjQboqTXnkKjhrXutYA3Am5p1DhifutAzt6IttbzoIUbPqhUpdb2AwnwP/RYbgf ZC2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M9pBVUPsSjXpo31w58FtVDjFxll6ybZhF0YzAHEV340=; b=rs6iR6YDYjUrrFNc6ERHxcx6TXYyHAdCkdSin8KIIuMoE8UuYmCa1MhtMbZHFlfaE1 jZi5whZ5H3OTrWBnHCtcWjikG1BzZLrg8L+gZOyv0KCcS26357ZhunGB+UVKUyJoi7VZ KTTyEyLFSf16Q42q06VzYFUzsDqMoQ/KKtKEWnVyxjJoKUTzLs3wVxo24evCkVEDRtca WygX9TrhA/mHeGQOYdGQR39nnZM7Lp64MQozIQ3GO8P6kBQlY6gt7TZluJJ5ihJ37II1 3x78PBVUgP+t4SIt9eS9MnxSVArG497sokPDaCW3/wRl9eNUEK+U8n4k7FB6Ei6zhDzY iEjw==
X-Gm-Message-State: AOUpUlEdsN1eZzkCzE4bOQbvqtSSU7xJpIFGxWKg1oFLxNWArfn8k3ia LzKUt7tYo2J2wbOatCMEosRp4KoWNFF9nXCwiC4=
X-Google-Smtp-Source: AAOMgpcY/a1AkLSUfp52EUvJSYVH3aZ9734/N33yeL7mDsmCE/+LAzneWYJeHtQE6RpqQ8a9IBBb4Q+ae5MtZJRWy+Y=
X-Received: by 2002:aca:d015:: with SMTP id h21-v6mr4084831oig.142.1532448504173;  Tue, 24 Jul 2018 09:08:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:07:53 -0700 (PDT)
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>
From: Ted Hardie 
Date: Tue, 24 Jul 2018 09:07:53 -0700
Message-ID: 
Subject: Re: Questions on HTTP URI schemes and QUIC
To: Sridhar Bhaskaran 
Cc: Lucas Pardue , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000ba58420571c0f81c"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Tue, 24 Jul 2018 16:08:27 -0000

--000000000000ba58420571c0f81c
Content-Type: text/plain; charset="UTF-8"

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <
sridhar.bhaskaran@huawei.com> wrote:


> Yes this is understood. One follow up question is - can a bump in TLS (TLS
> interception) where a proxy provides certificates on behalf of origin host
> signed by its own CA (provided the client is configured to trust this CA)
> work with QUIC? Can this be made to work to intercept the protected payload
> at a proxy?
>
> Thanks
> Sridhar


Before going down that road, may I ask why 3gpp prefers the
bump-in-the-wire style proxy, rather than a configured proxy?  A configured
proxy can act as a back-to-back user agent, which allows the kind of
inspection you describe.  The  mechanism can also be set to work either on
a per-network basis or globally (depending on the configuration and the
topology).  Is that not a better fit for your deployment model?

regards,

Ted

--000000000000ba58420571c0f81c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaska=
ran <sridhar.bhaskaran@huawei.com> wrote:
=C2=A0

Yes this is understood. One follow up question is - can a bump in TL=
S (TLS interception) where a proxy provides certificates on behalf of origi=
n host signed by its own CA (provided the client is configured to trust thi=
s CA) work with QUIC? Can this be made to work to intercept the protected p=
ayload at a proxy?



Thanks

Sridhar

Before going down that road,=
 may I ask why 3gpp prefers the bump-in-the-wire style proxy, rather than a=
 configured proxy?=C2=A0 A configured proxy can act as a back-to-back user =
agent, which allows the kind of inspection you describe.=C2=A0 The=C2=A0 me=
chanism can also be set to work either on a per-network basis or globally (=
depending on the configuration and the topology).=C2=A0 Is that not a bette=
r fit for your deployment model?

regards,

Ted


--000000000000ba58420571c0f81c--


From nobody Tue Jul 24 20:33:48 2018
Return-Path: 
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 81F38130F47 for ; Tue, 24 Jul 2018 20:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PWXot1QGlh-L for ; Tue, 24 Jul 2018 20:33:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EC2130E00 for ; Tue, 24 Jul 2018 20:33:44 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E697B5FDEE602 for ; Wed, 25 Jul 2018 04:33:38 +0100 (IST)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 25 Jul 2018 04:33:22 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0382.000; Wed, 25 Jul 2018 09:03:10 +0530
From: Sridhar Bhaskaran 
To: Ted Hardie , IETF QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QAA8EpoAAIxU/UA==
Date: Wed, 25 Jul 2018 03:33:09 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.148.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 03:33:47 -0000

SGkgVGVkLA0KDQo+PiBCZWZvcmUgZ29pbmcgZG93biB0aGF0IHJvYWQsIG1heSBJIGFzayB3aHkg
M2dwcCBwcmVmZXJzIHRoZSBidW1wLWluLXRoZS13aXJlIHN0eWxlIHByb3h5LCByYXRoZXIgdGhh
biBhIGNvbmZpZ3VyZWQgcHJveHk/ICBBIGNvbmZpZ3VyZWQgcHJveHkgY2FuIGFjdCBhcyBhIGJh
Y2stdG8tYmFjayB1c2VyIGFnZW50LCB3aGljaCBhbGxvd3MgdGhlIGtpbmQgb2YgaW5zcGVjdGlv
biB5b3UgZGVzY3JpYmUuICBUaGUgIG1lY2hhbmlzbSBjYW4gYWxzbyBiZSBzZXQgdG8gd29yayBl
aXRoZXIgb24gYSBwZXItbmV0d29yayBiYXNpcyBvciBnbG9iYWxseSAoZGVwZW5kaW5nIG9uIHRo
ZSBjb25maWd1cmF0aW9uIGFuZCB0aGUgdG9wb2xvZ3kpLiAgSXMgdGhhdCBub3QgYSBiZXR0ZXIg
Zml0IGZvciB5b3VyIGRlcGxveW1lbnQgbW9kZWw/DQoNCltTcmlkaGFyXSBJbiAzR1BQIGFyY2hp
dGVjdHVyZSwgZnJvbSBhIEhUVFAgY2xpZW50IHBlcnNwZWN0aXZlIGl0IGJlbGlldmVzIGl0IGlz
IGludm9raW5nIHRoZSBBUEkgZXhwb3NlZCBieSBhIEhUVFAgc2VydmVyLiBJZiB0aGUgY2xpZW50
IGlzIGNvbmZpZ3VyZWQgdG8gcm91dGUgdGhlIHJlcXVlc3QgdmlhIGEgcHJveHkgKGNvbmZpZ3Vy
YXRpb24gaXMgYXQgSFRUUCBsZXZlbCBhbmQgYXBwbGljYXRpb24gaXMgdW5hd2FyZSBvZiBpdCks
IHRoZW4gd2hhdCBzaG91bGQgYmUgdGhlICI6YXV0aG9yaXR5IiBwc2V1ZG8gaGVhZGVyIGluIGEg
SFRUUC8yIHJlcXVlc3QgKGkuZSB0aGUgYXV0aG9yaXR5IHBhcnQgb2YgdGhlIFVSSSk/IElmIHRo
ZSBhdXRob3JpdHkgcGFydCBvZiB0aGUgVVJJIHN0aWxsIHJlZmVycyB0byBhbiBGUUROIC8gSVAg
YWRkcmVzcyBvZiB0aGUgSFRUUCBzZXJ2ZXIsIHRoZW4gaXNu4oCZdCB0aGUgVExTIGNlcnRpZmlj
YXRlIGV4Y2hhbmdlIHN1cHBvc2VkIHRvIGhhcHBlbiBhZ2FpbnN0IHRoaXM/IE9uIHRoZSBvdGhl
ciBoYW5kLCBpZiB0aGUgYXV0aG9yaXR5IHBhcnQgb2YgdGhlIFVSSSByZWZlcnMgdG8gdGhlIHBy
b3h5J3MgZW5kcG9pbnQgaXRzZWxmLCB0aGVuIGhvdyBkb2VzIHRoZSBwcm94eSBrbm93IHdoZXJl
IHRvIHJvdXRlIHRoZSByZXF1ZXN0IGZ1cnRoZXI/IA0KDQpCeSB0aGUgd2F5IGFyZSB0aGVyZSBh
bnkgSUVURiBkcmFmdHMgLyBSRkNzIHRoYXQgZXhwbGFpbiBob3cgdGhpcyB3b3VsZCB3b3JrPw0K
DQpJIG1heSBiZSBtaXNzaW5nIGZldyBkZXRhaWxzIGhlcmUuIENvdWxkIHlvdSBwbGVhc2UgY2xh
cmlmeSBob3cgYSBjb25maWd1cmVkIHByb3h5IGFjdGluZyBhcyBCMkIgdXNlciBhZ2VudCB3b3Vs
ZCANCg0KYSkgdGVybWluYXRlIFRMUyBieSBwcm92aWRpbmcgYSB2YWxpZCBjZXJ0aWZpY2F0ZSBm
b3IgdGhlIGRvbWFpbiAvIGF1dGhvcml0eSB3aXRoIHdoaWNoIHRoZSBjbGllbnQgaXMgaW50ZW5k
aW5nIHRvIGNvbW11bmljYXRlIA0KYikgaG93IHRoZSBwcm94eSB3aWxsIHJvdXRlIHRoZSBIVFRQ
LzIgcmVxdWVzdCB0byB0aGUgcmlnaHQgc2VydmVyIChhbmQgYmFzZWQgb24gd2hpY2ggaW5mb3Jt
YXRpb24gaW4gdGhlIEhUVFAvMiByZXF1ZXN0KT8NCmMpIEFueSBJRVRGIGRyYWZ0IC8gUkZDIHRo
YXQgZXhwbGFpbnMgdGhpcy4NCg0KVGhhbmtzDQpTcmlkaGFyDQoNCkZyb206IFRlZCBIYXJkaWUg
W21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgSnVseSAyNCwgMjAx
OCA5OjM4IFBNDQpUbzogU3JpZGhhciBCaGFza2FyYW4gPHNyaWRoYXIuYmhhc2thcmFuQGh1YXdl
aS5jb20+DQpDYzogTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJkdWVAYmJjLmNvLnVrPjsgSUVURiBR
VUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFF1ZXN0aW9ucyBvbiBIVFRQIFVS
SSBzY2hlbWVzIGFuZCBRVUlDDQoNCkhpIFNyaWRoYXIsDQoNCk9uIE1vbiwgSnVsIDIzLCAyMDE4
IGF0IDg6MzYgUE0sIFNyaWRoYXIgQmhhc2thcmFuIDxzcmlkaGFyLmJoYXNrYXJhbkBodWF3ZWku
Y29tPiB3cm90ZToNCsKgDQpZZXMgdGhpcyBpcyB1bmRlcnN0b29kLiBPbmUgZm9sbG93IHVwIHF1
ZXN0aW9uIGlzIC0gY2FuIGEgYnVtcCBpbiBUTFMgKFRMUyBpbnRlcmNlcHRpb24pIHdoZXJlIGEg
cHJveHkgcHJvdmlkZXMgY2VydGlmaWNhdGVzIG9uIGJlaGFsZiBvZiBvcmlnaW4gaG9zdCBzaWdu
ZWQgYnkgaXRzIG93biBDQSAocHJvdmlkZWQgdGhlIGNsaWVudCBpcyBjb25maWd1cmVkIHRvIHRy
dXN0IHRoaXMgQ0EpIHdvcmsgd2l0aCBRVUlDPyBDYW4gdGhpcyBiZSBtYWRlIHRvIHdvcmsgdG8g
aW50ZXJjZXB0IHRoZSBwcm90ZWN0ZWQgcGF5bG9hZCBhdCBhIHByb3h5Pw0KDQpUaGFua3MNClNy
aWRoYXINCg0KQmVmb3JlIGdvaW5nIGRvd24gdGhhdCByb2FkLCBtYXkgSSBhc2sgd2h5IDNncHAg
cHJlZmVycyB0aGUgYnVtcC1pbi10aGUtd2lyZSBzdHlsZSBwcm94eSwgcmF0aGVyIHRoYW4gYSBj
b25maWd1cmVkIHByb3h5P8KgIEEgY29uZmlndXJlZCBwcm94eSBjYW4gYWN0IGFzIGEgYmFjay10
by1iYWNrIHVzZXIgYWdlbnQsIHdoaWNoIGFsbG93cyB0aGUga2luZCBvZiBpbnNwZWN0aW9uIHlv
dSBkZXNjcmliZS7CoCBUaGXCoCBtZWNoYW5pc20gY2FuIGFsc28gYmUgc2V0IHRvIHdvcmsgZWl0
aGVyIG9uIGEgcGVyLW5ldHdvcmsgYmFzaXMgb3IgZ2xvYmFsbHkgKGRlcGVuZGluZyBvbiB0aGUg
Y29uZmlndXJhdGlvbiBhbmQgdGhlIHRvcG9sb2d5KS7CoCBJcyB0aGF0IG5vdCBhIGJldHRlciBm
aXQgZm9yIHlvdXIgZGVwbG95bWVudCBtb2RlbD8NCg0KcmVnYXJkcywNCg0KVGVkDQo=


From nobody Tue Jul 24 22:48:27 2018
Return-Path: 
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 5D1C0130DF4 for ; Tue, 24 Jul 2018 22:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 uS1KxvMyA_HN for ; Tue, 24 Jul 2018 22:48:23 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 B3A2E130E2A for ; Tue, 24 Jul 2018 22:48:22 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id e19-v6so6533779qtp.8 for ; Tue, 24 Jul 2018 22:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=2x45d0nxvJEqQPGkMDxh54lyJCcmbaF91rS3pRq4Gv4=; b=HXLVDUUaYbwCVzfQNfipWktT3ipQPtMgmn0zOXOJEJ+hxwL1C/b8rPlQIdaMR18ENe Gw9phsiSA7S5+Q2uT/bKv7JBkEKOyxzLFosRzmQcDk+gr6tQtjR3qWRC8soVcURly2Rh xQ3EPYTls8Jk2EjzMyvPG16ot2B4rvL7psurlRTGEe59ZpNS8d88wIYPXbFUB+HROTBB abXbXxplOL4xhaBGkNwzjI+tS5YfOKX7GVXmPw1Oq57dHhgUj+UFxhm0ZL3Mau5jA6By p+7HPRlm07AoVFVGjLXBuxZm1QDo/AR9ZlvSC0UbFOPzBkVOgTiqhoZQpktHmHamcxPb Gmiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=2x45d0nxvJEqQPGkMDxh54lyJCcmbaF91rS3pRq4Gv4=; b=f+Hr58A457UTMkhPiU2T2RyjAhC9lIpT/TAx9G5FpOAiC1IbX8rpSLQJVgkOkGkvtz LDWSitFXLSKpoSjiPDdyzinYgmWyhChoSLzSWcdme2gyu44kkUm4JIi13DDmxRNkSywF Ffcf3fe3M1JcvVnbwbUa8/aGwnK+9AuoPbHmq+Lx7uLDe8SBjc3nQ/NKigqrFQ4FB+3y qIE7OAexmciwIBa4V00lBmyXZi3uBYsN37F3Ldu+72m0Gd1YybiOa6wxRMxWiciDElGl n8nnble4swra+JEoY2hqLyY7zPip69vTgUv9PV3rrlFHyp/x6EAktXSxmDOt0QfncITm Vvig==
X-Gm-Message-State: AOUpUlH6Qa8lSYi2GTUk4A1tKtr0kWVosn2hoL2p09HRsWVKNb4T0Ncz CwDk7i/8r+5GdstEUZeKBhU=
X-Google-Smtp-Source: AAOMgpdsrf47k4693SN/eqTzUVRUeVyzOr31TxL8CfhY0EalxgL+WlIzNYH2XIdGYRSXyOv/WIq/WQ==
X-Received: by 2002:a0c:ca94:: with SMTP id a20-v6mr17831146qvk.37.1532497701888;  Tue, 24 Jul 2018 22:48:21 -0700 (PDT)
Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id o2-v6sm1671658qte.16.2018.07.24.22.48.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 22:48:20 -0700 (PDT)
From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= 
To: Sridhar Bhaskaran , Ted Hardie , IETF QUIC WG 
Subject: Re: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AUFFRjg2ghJw9e6hhjKznfXxRVMqEkFBM0ZDQkVGODY1QTNGQzlFRjg2QW5YWVExRUY4NpqXJS6d
X-MS-Exchange-MessageSentRepresentingType: 2
Date: Wed, 25 Jul 2018 05:48:17 +0000
Message-ID: 
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com> , <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: 
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766AEAB4F1B0C7F40DDEEACAC540DB6PR10MB1766EURP_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 05:48:25 -0000

--_000_DB6PR10MB1766AEAB4F1B0C7F40DDEEACAC540DB6PR10MB1766EURP_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Another option is to connect to the backend directly, then forward traffic =
keys to the proxy.

________________________________
From: QUIC  on behalf of Sridhar Bhaskaran 
Sent: Wednesday, July 25, 2018 5:33:09 AM
To: Ted Hardie; IETF QUIC WG
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Ted,

>> Before going down that road, may I ask why 3gpp prefers the bump-in-the-=
wire style proxy, rather than a configured proxy?  A configured proxy can a=
ct as a back-to-back user agent, which allows the kind of inspection you de=
scribe.  The  mechanism can also be set to work either on a per-network bas=
is or globally (depending on the configuration and the topology).  Is that =
not a better fit for your deployment model?

[Sridhar] In 3GPP architecture, from a HTTP client perspective it believes =
it is invoking the API exposed by a HTTP server. If the client is configure=
d to route the request via a proxy (configuration is at HTTP level and appl=
ication is unaware of it), then what should be the ":authority" pseudo head=
er in a HTTP/2 request (i.e the authority part of the URI)? If the authorit=
y part of the URI still refers to an FQDN / IP address of the HTTP server, =
then isn=92t the TLS certificate exchange supposed to happen against this? =
On the other hand, if the authority part of the URI refers to the proxy's e=
ndpoint itself, then how does the proxy know where to route the request fur=
ther?

By the way are there any IETF drafts / RFCs that explain how this would wor=
k?

I may be missing few details here. Could you please clarify how a configure=
d proxy acting as B2B user agent would

a) terminate TLS by providing a valid certificate for the domain / authorit=
y with which the client is intending to communicate
b) how the proxy will route the HTTP/2 request to the right server (and bas=
ed on which information in the HTTP/2 request)?
c) Any IETF draft / RFC that explains this.

Thanks
Sridhar

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, July 24, 2018 9:38 PM
To: Sridhar Bhaskaran 
Cc: Lucas Pardue ; IETF QUIC WG 
Subject: Re: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran  wrote:

Yes this is understood. One follow up question is - can a bump in TLS (TLS =
interception) where a proxy provides certificates on behalf of origin host =
signed by its own CA (provided the client is configured to trust this CA) w=
ork with QUIC? Can this be made to work to intercept the protected payload =
at a proxy?

Thanks
Sridhar

Before going down that road, may I ask why 3gpp prefers the bump-in-the-wir=
e style proxy, rather than a configured proxy?  A configured proxy can act =
as a back-to-back user agent, which allows the kind of inspection you descr=
ibe.  The  mechanism can also be set to work either on a per-network basis =
or globally (depending on the configuration and the topology).  Is that not=
 a better fit for your deployment model?

regards,

Ted

--_000_DB6PR10MB1766AEAB4F1B0C7F40DDEEACAC540DB6PR10MB1766EURP_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


















Another option is to connect to the backend di=
rectly, then forward traffic keys to the proxy.

















From: QUIC <quic-bounc=
es@ietf.org> on behalf of Sridhar Bhaskaran <sridhar.bhaskaran@huawei=
.com>

Sent: Wednesday, July 25, 2018 5:33:09 AM

To: Ted Hardie; IETF QUIC WG

Subject: RE: Questions on HTTP URI schemes and QUIC

 







Hi Ted,



>> Before going down that road, may I ask why 3gpp prefers the bump-i=
n-the-wire style proxy, rather than a configured proxy?  A configured =
proxy can act as a back-to-back user agent, which allows the kind of inspec=
tion you describe.  The  mechanism can also
 be set to work either on a per-network basis or globally (depending on the=
 configuration and the topology).  Is that not a better fit for your d=
eployment model?



[Sridhar] In 3GPP architecture, from a HTTP client perspective it believes =
it is invoking the API exposed by a HTTP server. If the client is configure=
d to route the request via a proxy (configuration is at HTTP level and appl=
ication is unaware of it), then
 what should be the ":authority" pseudo header in a HTTP/2 reques=
t (i.e the authority part of the URI)? If the authority part of the URI sti=
ll refers to an FQDN / IP address of the HTTP server, then isn=92t the TLS =
certificate exchange supposed to happen against
 this? On the other hand, if the authority part of the URI refers to the pr=
oxy's endpoint itself, then how does the proxy know where to route the requ=
est further?




By the way are there any IETF drafts / RFCs that explain how this would wor=
k?



I may be missing few details here. Could you please clarify how a configure=
d proxy acting as B2B user agent would




a) terminate TLS by providing a valid certificate for the domain / authorit=
y with which the client is intending to communicate


b) how the proxy will route the HTTP/2 request to the right server (and bas=
ed on which information in the HTTP/2 request)?

c) Any IETF draft / RFC that explains this.



Thanks

Sridhar



From: Ted Hardie [mailto:ted.ietf@gma=
il.com]


Sent: Tuesday, July 24, 2018 9:38 PM

To: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>

Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf=
.org>

Subject: Re: Questions on HTTP URI schemes and QUIC



Hi Sridhar,



On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <sridhar.bhaskaran@hu=
awei.com> wrote:

 

Yes this is understood. One follow up question is - can a bump in TLS (TLS =
interception) where a proxy provides certificates on behalf of origin host =
signed by its own CA (provided the client is configured to trust this CA) w=
ork with QUIC? Can this be made
 to work to intercept the protected payload at a proxy?



Thanks

Sridhar



Before going down that road, may I ask why 3gpp prefers the bump-in-the-wir=
e style proxy, rather than a configured proxy?  A configured proxy can=
 act as a back-to-back user agent, which allows the kind of inspection you =
describe.  The  mechanism can also be
 set to work either on a per-network basis or globally (depending on the co=
nfiguration and the topology).  Is that not a better fit for your depl=
oyment model?



regards,



Ted







--_000_DB6PR10MB1766AEAB4F1B0C7F40DDEEACAC540DB6PR10MB1766EURP_--


From nobody Tue Jul 24 23:59:58 2018
Return-Path: 
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 CCB64130E48 for ; Tue, 24 Jul 2018 23:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 WhSS8Z4eD_CY for ; Tue, 24 Jul 2018 23:59:55 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 3FCE7130E2C for ; Tue, 24 Jul 2018 23:59:55 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id n84-v6so12019674oib.9 for ; Tue, 24 Jul 2018 23:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5ov0kZmwOFnxR/33//Sek+BJ3mIXswJIUv/aYo0Xk1E=; b=Z6b92+9OCS6I0y5VD3ECM6UMCJtYUH62cpeg5h2o8gYyX1+q3OtcvVMrOWASJk2NDQ dS4HvP51w2IHI8BIQL7J3GWoKAlDnJCPoPPih21NV8k+WC2lcJrucK29OJR/B4FNXnEE 05tBVtaeo0bb/8fqM8O7fgOkhW7DO94cSFVBTuDXCkcySF4qmSUaARkXboIqWS93mtNV /gCad/VbrzFrm62EuDwSeJaWNWPa2kewBTWu85E4K6M10paXZklPvkBTISXKZvzR4y1K FjxIyr49Uyc1GfShVYzhbD66gCCW8/wZ5bv0Ngz3VFyz7by7KTdL/uzA+9i49JZkA34r xIfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5ov0kZmwOFnxR/33//Sek+BJ3mIXswJIUv/aYo0Xk1E=; b=IMxWJJNlOZwMmEkUH8ft/iFhGEAVP2EYMhxiyFIN/GJhIS0wsUVwNV3wiX5+N6Ie3T SNw/ziPKXtF1KgZdBe9UUQjD0nQII5NJ0j4TGDFSlHhdroM7lrOc5yVwIaTV/YycT1xZ u2FrkYJWNIY1Lo+BHSjHbIxFWyX0/qErNBWZ845Y86nexg9KO9gJjyCkfYezwr6DAWUk iVma6jEwabUhblFWS8uuerH2CrNceGi07LxCnxvzMpNcVeVvU6yrOhl8utn8TlGM8C6O pyoxrmEg/VWL6BJ3mlQZ/DHZXvbJJ3P0W2Y/MHeWczRAWueqS8pEGYOFw/vGmzv5VB/d OoCw==
X-Gm-Message-State: AOUpUlGXYjO4PxPEh3aT5jrGqWfKBiQXfZZJS9xaNsWH87fOHdJ+rbBU LsqcU+DH8XEBSanYLgEUdOEEFgNWazsnoI4Dvr0=
X-Google-Smtp-Source: AAOMgpeHgVEMoqwW1hakKAdynhsWFAsvPwwDCWw3QT/hOlSYXlqgnHlniNYYwFwRQTP4mcjkidElal//nMbcEirZKWM=
X-Received: by 2002:aca:b208:: with SMTP id b8-v6mr2084316oif.144.1532501994384;  Tue, 24 Jul 2018 23:59:54 -0700 (PDT)
MIME-Version: 1.0
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>  <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com>
From: Martin Thomson 
Date: Wed, 25 Jul 2018 16:59:43 +1000
Message-ID: 
Subject: Re: Questions on HTTP URI schemes and QUIC
To: sridhar.bhaskaran@huawei.com
Cc: Ted Hardie , QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 06:59:57 -0000

On Wed, Jul 25, 2018 at 1:34 PM Sridhar Bhaskaran
 wrote:
> If the client is configured to route the request via a proxy (configurati=
on is at HTTP level and application is unaware of it), then what should be =
the ":authority" pseudo header in a HTTP/2 request (i.e the authority part =
of the URI)?

Yes, this is as defined in RFC 7540.  The identity of the proxy
doesn't matter.  Of course, that places a lot of trust in the proxy,
and clients rarely do that.  In most cases, a (forward) proxy will
instead see a CONNECT request instead.  (I'm assuming HTTPS here, as
deployment of unsecured HTTP/2 is both effectively non-existent and
prohibited by 3GPP.)

> If the authority part of the URI still refers to an FQDN / IP address of =
the HTTP server, then isn=E2=80=99t the TLS certificate exchange supposed t=
o happen against this? On the other hand, if the authority part of the URI =
refers to the proxy's endpoint itself, then how does the proxy know where t=
o route the request further?

The latter is what we call a reverse proxy or gateway.  For that to
work, the "proxy" needs to hold a certificate and keys that are valid
for the identified authority.  The proxy can usually only operate for
a single authority for each connection (RFC 7540 covers the exceptions
to this).  It can use the TLS server_name extension and HTTP Host
header field to demultiplex requests for multiple names if it is
authoritative for more than one.  Each name typically needs a separate
connection.

> By the way are there any IETF drafts / RFCs that explain how this would w=
ork?

RFC 7540 should describe most of this, either directly or by
reference.  TLS server_name is described in RFC 6066.


From nobody Wed Jul 25 00:20:34 2018
Return-Path: 
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 D2E20130EC1 for ; Wed, 25 Jul 2018 00:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 a5WW-g32ouhf for ; Wed, 25 Jul 2018 00:20:31 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A06130E76 for ; Wed, 25 Jul 2018 00:20:30 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E64AD4D527231 for ; Wed, 25 Jul 2018 08:20:27 +0100 (IST)
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 25 Jul 2018 08:20:28 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0382.000; Wed, 25 Jul 2018 12:50:16 +0530
From: Sridhar Bhaskaran 
To: Martin Thomson , QUIC WG 
CC: Ted Hardie 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QAA8EpoAAIxU/UP//4IKA//+hFRA=
Date: Wed, 25 Jul 2018 07:20:16 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129F263@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>  <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.148.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 07:20:33 -0000

SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLg0KDQo+PiBUaGUgbGF0
dGVyIGlzIHdoYXQgd2UgY2FsbCBhIHJldmVyc2UgcHJveHkgb3IgZ2F0ZXdheS4gIEZvciB0aGF0
IHRvIHdvcmssIHRoZSAicHJveHkiIG5lZWRzIHRvIGhvbGQgYSBjZXJ0aWZpY2F0ZSBhbmQga2V5
cyB0aGF0IGFyZSB2YWxpZCBmb3IgdGhlIGlkZW50aWZpZWQgYXV0aG9yaXR5LiAgVGhlIHByb3h5
IGNhbiB1c3VhbGx5IG9ubHkgb3BlcmF0ZSBmb3IgYSBzaW5nbGUgYXV0aG9yaXR5IGZvciBlYWNo
IGNvbm5lY3Rpb24gKFJGQyA3NTQwIGNvdmVycyB0aGUgZXhjZXB0aW9ucyB0byB0aGlzKS4gIEl0
IGNhbiB1c2UgdGhlIFRMUyBzZXJ2ZXJfbmFtZSBleHRlbnNpb24gYW5kIEhUVFAgSG9zdCBoZWFk
ZXIgZmllbGQgdG8gZGVtdWx0aXBsZXggcmVxdWVzdHMgZm9yIG11bHRpcGxlIG5hbWVzIGlmIGl0
IGlzIGF1dGhvcml0YXRpdmUgZm9yIG1vcmUgdGhhbiBvbmUuICBFYWNoIG5hbWUgdHlwaWNhbGx5
IG5lZWRzIGEgc2VwYXJhdGUgY29ubmVjdGlvbi4NCg0KW1NyaWRoYXJdIFJldmVyc2UgcHJveGll
cyB0byB0ZXJtaW5hdGUgVExTIGNhbiBiZSBkZXBsb3llZCB3aGVuIHRoZSBwcm94eSBpcyBpbiB0
aGUgc2FtZSB0cnVzdCBkb21haW4gYXMgdGhlIG9yaWdpbiBzZXJ2ZXIgc2luY2UgdGhlIHJldmVy
c2UgcHJveHkgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gZXhwb3NlIHRoZSBBUEkgZW5kcG9pbnQgdG93
YXJkcyB0aGUgY2xpZW50cyBhbmQgbWFza3MgdGhlIHByZXNlbmNlIG9mIGJhY2tlbmQgc2VydmVy
cy4gLiBCdXQgaW4gM0dQUCB0aGUgSFRUUCBBUEkgY2FsbCBpcyBsaWtlIGJlbG93DQoNCkhUVFAg
Q2xpZW50IGluIE5ldHdvcmsgQSAoUExNTiBBKSAtLT4gU0VQUCBvZiBQTE1OIEEgWyBUcnVzdCBC
b3VuZGFyeSBjcm9zc2VkIGhlcmVdIC0tPiBTRVBQIG9mIFBMTU4gQiAtLT4gSFRUUCBzZXJ2ZXIg
aW4gTmV0d29yayBCIChQTE1OIEIpDQoNClNvIGhlcmUgdGhlIGNsaWVudCdzIHRyYW5zcG9ydCBj
b25uZWN0aW9uIChUTFMgb3IgUVVJQykgdGVybWluYXRlcyBhdCBTRVBQIG9mIFBMTU4gQSB3aGlj
aCBhY3RzIGFzIGZvcndhcmQgcHJveHkuIFNvIGZvciBhIGh0dHBzOi8vIHNjaGVtZSBVUkksIHRo
ZSBjbGllbnQgaGFzIHRvIHRydXN0IHRoZSBTRVBQIEEgYXMgYSBjZXJ0aWZpY2F0ZSBhdXRob3Jp
dHkgaWYgaXQgYWN0cyBhcyBhIGJ1bXAgaW4gVExTIGFuZCBwcm92aWRlcyBhIGNlcnRpZmljYXRl
IG9uIGJlaGFsZiBvZiB0aGUgSFRUUCBvcmlnaW4gc2VydmVyLg0KDQpJIHRoaW5rIHRoZSBiYWNr
IHRvIGJhY2sgdXNlciBhZ2VudCB0eXBlIHByb3h5IG1heSBub3QgZXhhY3RseSBmaXQgaGVyZSBk
dWUgdG8gaW52b2x2ZW1lbnQgb2YgbXVsdGlwbGUgcHJveGllcyAoU0VQUCBBLCBTRVBQIEIpLg0K
DQpUaGFua3MNClNyaWRoYXINCg==


From nobody Wed Jul 25 01:24:27 2018
Return-Path: 
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 BA492130E4A for ; Wed, 25 Jul 2018 01:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PZ9C2jXn-W3K for ; Wed, 25 Jul 2018 01:24:23 -0700 (PDT)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB32A130DC6 for ; Wed, 25 Jul 2018 01:24:23 -0700 (PDT)
Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w6P8Nvl2026546; Wed, 25 Jul 2018 09:23:57 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0389.001; Wed, 25 Jul 2018 09:23:57 +0100
From: Lucas Pardue 
To: Sridhar Bhaskaran , Martin Thomson , QUIC WG 
CC: Ted Hardie 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QABhyo4AAF+7DgAAHNtmAAAC3vAAAA/ntzA==
Date: Wed, 25 Jul 2018 08:23:56 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB799EE@bgb01xud1012>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>  <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com> , <0E42DD26875E1748992B1E3F732A36AE0129F263@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129F263@BLREML503-MBX.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 08:24:26 -0000

Hi Sridhar,

What is the relationship between PLMN A and PLMN B? Is this "the public Int=
ernet" or more a collection of operator networks? If there is a coordinated=
 handoff then, although operating in different trust domains, it seems feas=
ible for the SEPPS to trust each other. Is that not the case?

Trust of course requires some provisioning/orchestration of services at a s=
ystem level but from the client perspective,  HTTP clients at any point in =
the chain could believe they are in communication with the final target ser=
ver.

Lucas
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Sridhar Bhaskaran [sridhar.=
bhaskaran@huawei.com]
Sent: 25 July 2018 08:20
To: Martin Thomson; QUIC WG
Cc: Ted Hardie
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Martin,

Thanks for the clarification.

>> The latter is what we call a reverse proxy or gateway.  For that to work=
, the "proxy" needs to hold a certificate and keys that are valid for the i=
dentified authority.  The proxy can usually only operate for a single autho=
rity for each connection (RFC 7540 covers the exceptions to this).  It can =
use the TLS server_name extension and HTTP Host header field to demultiplex=
 requests for multiple names if it is authoritative for more than one.  Eac=
h name typically needs a separate connection.

[Sridhar] Reverse proxies to terminate TLS can be deployed when the proxy i=
s in the same trust domain as the origin server since the reverse proxy can=
 be configured to expose the API endpoint towards the clients and masks the=
 presence of backend servers. . But in 3GPP the HTTP API call is like below

HTTP Client in Network A (PLMN A) --> SEPP of PLMN A [ Trust Boundary cross=
ed here] --> SEPP of PLMN B --> HTTP server in Network B (PLMN B)

So here the client's transport connection (TLS or QUIC) terminates at SEPP =
of PLMN A which acts as forward proxy. So for a https:// scheme URI, the cl=
ient has to trust the SEPP A as a certificate authority if it acts as a bum=
p in TLS and provides a certificate on behalf of the HTTP origin server.

I think the back to back user agent type proxy may not exactly fit here due=
 to involvement of multiple proxies (SEPP A, SEPP B).

Thanks
Sridhar


From nobody Wed Jul 25 01:44:21 2018
Return-Path: 
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 C818C130E51 for ; Wed, 25 Jul 2018 01:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 CPTuuNzFkE_I for ; Wed, 25 Jul 2018 01:44:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8589130DC6 for ; Wed, 25 Jul 2018 01:44:17 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E811DBA222ED1 for ; Wed, 25 Jul 2018 09:44:13 +0100 (IST)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 25 Jul 2018 09:44:15 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0382.000; Wed, 25 Jul 2018 14:14:05 +0530
From: Sridhar Bhaskaran 
To: QUIC WG 
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QAA8EpoAAIxU/UP//4IKA//+hFRCAAHZzAP//npFg
Date: Wed, 25 Jul 2018 08:44:04 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129F313@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>  <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com> , <0E42DD26875E1748992B1E3F732A36AE0129F263@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB799EE@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB799EE@bgb01xud1012>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.148.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 08:44:20 -0000

Hi Luca / all,

I will take this offlist as this getting more into URI design, 3GPP API des=
ign discussion which is not of interest to quic transport group.

Thanks all for the valuable feedback so far.

With this I am concluding the thread on this mailer list.

Sridhar

-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]=20
Sent: Wednesday, July 25, 2018 1:54 PM
To: Sridhar Bhaskaran ; Martin Thomson ; QUIC WG 
Cc: Ted Hardie 
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

What is the relationship between PLMN A and PLMN B? Is this "the public Int=
ernet" or more a collection of operator networks? If there is a coordinated=
 handoff then, although operating in different trust domains, it seems feas=
ible for the SEPPS to trust each other. Is that not the case?

Trust of course requires some provisioning/orchestration of services at a s=
ystem level but from the client perspective,  HTTP clients at any point in =
the chain could believe they are in communication with the final target ser=
ver.

Lucas
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Sridhar Bhaskaran [sridhar.=
bhaskaran@huawei.com]
Sent: 25 July 2018 08:20
To: Martin Thomson; QUIC WG
Cc: Ted Hardie
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Martin,

Thanks for the clarification.

>> The latter is what we call a reverse proxy or gateway.  For that to work=
, the "proxy" needs to hold a certificate and keys that are valid for the i=
dentified authority.  The proxy can usually only operate for a single autho=
rity for each connection (RFC 7540 covers the exceptions to this).  It can =
use the TLS server_name extension and HTTP Host header field to demultiplex=
 requests for multiple names if it is authoritative for more than one.  Eac=
h name typically needs a separate connection.

[Sridhar] Reverse proxies to terminate TLS can be deployed when the proxy i=
s in the same trust domain as the origin server since the reverse proxy can=
 be configured to expose the API endpoint towards the clients and masks the=
 presence of backend servers. . But in 3GPP the HTTP API call is like below

HTTP Client in Network A (PLMN A) --> SEPP of PLMN A [ Trust Boundary cross=
ed here] --> SEPP of PLMN B --> HTTP server in Network B (PLMN B)

So here the client's transport connection (TLS or QUIC) terminates at SEPP =
of PLMN A which acts as forward proxy. So for a https:// scheme URI, the cl=
ient has to trust the SEPP A as a certificate authority if it acts as a bum=
p in TLS and provides a certificate on behalf of the HTTP origin server.

I think the back to back user agent type proxy may not exactly fit here due=
 to involvement of multiple proxies (SEPP A, SEPP B).

Thanks
Sridhar


From nobody Wed Jul 25 12:29:47 2018
Return-Path: 
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 80158130DD8 for ; Wed, 25 Jul 2018 12:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 Emii7xKCYDer for ; Wed, 25 Jul 2018 12:29:43 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB668129385 for ; Wed, 25 Jul 2018 12:29:42 -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=JZLQ3wyP+OHTUVJz5XKHYaLCQrdS6nAn7oJv56xlI5M=; b=cDmucW4+2Nq6uk/FRvZ3j5emISalazaIS24PNs1ST2GDaCZ2rUFGrcdD1jGNiLup84UFvCq7PxdKqH5Xgthx1XTw8aehM2is//X6rNAY/3+FP8mZXLGy8UBrrYPERNUCeKtxisB2Pxokjzkz6rix/lz7apLj30v4HN4ha81ocLw=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0967.namprd21.prod.outlook.com (52.132.133.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.2; Wed, 25 Jul 2018 19:29:41 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545%2]) with mapi id 15.20.1017.000; Wed, 25 Jul 2018 19:29:41 +0000
From: Nick Banks 
To: IETF QUIC WG 
Subject: Go Back to Single Packet Number Space
Thread-Topic: Go Back to Single Packet Number Space
Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0w==
Date: Wed, 25 Jul 2018 19:29:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-07-25T19:29:38.7932667Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:1:1d83:4be1:90a4:2f3c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0967; 6:QZLbTB4pE4tezSWVB7Exr36XbqdlnsIgFT/y/oJ+4YsGlRxApqaN5duyJ9vvowzRMHqair6HGH7KQYiEQak8PoQgDpVsN0izuPcaHSBrL/qN2cJR2xbV0rFWMbqaVrLW/VmixyVwH12EtaFtjV+HFhq+zUNgV9FNq5PyWWgZ7eAdnYJvlXwmM4UmFKIPdkm+/pKB0fylK4OuRSlkgq5KjksvauVkUyRRjNS9LMyvNOJwZqgtmgCvO5OMHxD9FMSHXYtfpXtsFjNg6Tl4KYTYGPAw67lACnL3WbplLmgeJmVzkiKIlCk7rjzUdZLBFhNwyGxPFbamuaqGMfr1ThKaIl837UGhLP2whEbSIqMbuawGKbmDzrnKRpTHCEvJcJeHTDKU7Vj6m9rAVzP2i8yUSNiCHJMtJuKirnp93L10CXnebzhGIRX0bTd0hhhir+3R/Un5tzmbtUo03bBhhvypDw==; 5:Zay3N4a4u72KF9zS2Ijup6cbWM8lGZBqnsYqA9S1E0w0TDynDeritP0R3db1BHuRgRR119D1xy0YKesLwAmgTOl55oJsDObp/gyRpy2fgXfAiEyHAR39+RCFnkdKaohux/v4QEODVrwH5P1iufHn3BKRI5U8fLiXek2IFohUuok=; 7:Y7AqnZJ/0e7w2OxeSu8+0WlAmJulGcye+rOae1D7qfnJEqqr4r+dQ4GqchF0WRiXcD6JUcmNkyoZ9Bv3laJr3JylfN03XAzlzfFg/HNDjNBiLoWnzNXnfs1VvuXLMzHxsQP8kb0nbD2QYWL0fufApPObj5DkstJ9Z2zvvuTixNxnEqQ2xnHoap1a/cCxVRjRy1PlxJ+xKu5fwPGXJIcrxFtN63k/m2+Bi33IlAy8ZRHwiNYAcjX06pkIbXTqhDFu
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b601cf0e-e64c-4ad7-e0ae-08d5f264f7fe
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR2101MB0967; 
x-ms-traffictypediagnostic: DM5PR2101MB0967:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231311)(944501410)(52105095)(2018427008)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0967; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0967; 
x-forefront-prvs: 0744CFB5E8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(346002)(39860400002)(396003)(199004)(189003)(606006)(25786009)(22452003)(256004)(236005)(6436002)(10090500001)(14444005)(6916009)(46003)(86612001)(7696005)(7736002)(74316002)(2906002)(86362001)(68736007)(99286004)(97736004)(8990500004)(106356001)(6506007)(8936002)(33656002)(2900100001)(478600001)(186003)(5250100002)(790700001)(102836004)(9686003)(486006)(6116002)(14454004)(81166006)(53936002)(6306002)(81156014)(54896002)(316002)(55016002)(8676002)(105586002)(10290500003)(476003)(5660300001)(9326002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0967; H:DM5PR2101MB0901.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: wEOyD534T8KLDNdQ9iKV7A2CfVhBiIojjarYg66HxlT+76w24RlPE9GfrhgsGbt746IOxIHfx44322c7OIXGktR5uU0Q7Mto+TibHCL5+r6kE33jZtKD0XbhSmm2bDWyx3maV1sog6DnG0Lm5+AZq8QGdivPhMaqsOQv9F+d3akUX8p6PIoDsosyxGI0QIKitxYd7iNBmx5Gj6wHoOeIIJqYSbMO30u7slwAFJADx+WLf2FjT3PcWx8IJVNEiB4GHO9yikMiJK/dP01DwmVZZQD6CD9+5KQXuPfaEW0nlzdn0pJErqXAvlzTGhu05ReakXArq2SRluWTKUwYz6NkXqkKCJVS8UtYxKLVnBq+6ag=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB09016D44959E5796570F3CB7B3540DM5PR2101MB0901_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b601cf0e-e64c-4ad7-e0ae-08d5f264f7fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2018 19:29:41.2719 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0967
Archived-At: 
X-BeenThere: quic@ietf.org
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: Wed, 25 Jul 2018 19:29:46 -0000

--_000_DM5PR2101MB09016D44959E5796570F3CB7B3540DM5PR2101MB0901_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Folks,

I have opened a GitHub Issue (#1579) and Pull Request (#1591) for this topic, but it seems progressed has stalled, so I figur=
ed 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 dupli=
cated state (and associated memory) for all the packet number spaces. But m=
ore importantly, the multiple packet number spaces bring in a lot more comp=
lexity 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 ta=
ke a look at it (and the PR) and provide any feedback they might have. I fe=
el that my Issue adequately describes the problem and my PR provides good (=
if not better, IMO) solutions to the problems that were fixed previously wi=
th multiple packet number spaces. I believe having a single packet number s=
pace will drastically simplify implementations in the end.

Finally, as QUIC V1 (2?) is coming to a close (hopefully) I feel like we sh=
ould resolve this issue soon. I don't want this issue to slip out into the =
next version.

Thanks,
- Nick

--_000_DM5PR2101MB09016D44959E5796570F3CB7B3540DM5PR2101MB0901_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello Folks,


 


I have opened a GitHub Issue (#1579) and Pull Request (#1591) for this t=
opic, 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 pack=
et 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 we=
re 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 (hopef=
ully) I feel like we should resolve this issue soon. I don’t want thi=
s issue to slip out into the next version.


 


Thanks,


- Nick






--_000_DM5PR2101MB09016D44959E5796570F3CB7B3540DM5PR2101MB0901_--


From nobody Wed Jul 25 18:42:02 2018
Return-Path: 
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 1923B130F29 for ; Wed, 25 Jul 2018 18:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 yJOycbNcYoxz for ; Wed, 25 Jul 2018 18:41:59 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 16D7612F18C for ; Wed, 25 Jul 2018 18:41:59 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id b15-v6so146434oib.10 for ; Wed, 25 Jul 2018 18:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hchkBIVoYCo1P4XY3aj+AvBiVc5+liOIV4sOh23Djm8=; b=npbnWaX2evTxaLCrxLKCzqL2x37i4uiU0s3yvPwjL3gRZtj8JYSTYTaMyg7Bl2cVo5 RG3yMBRthD9SMLBGOJTE/nKxfrE/jjoFFbWe8LucDkc+BBUn8aDttFhZhCZpn0tvdsIU dzXXYF6BjubJ/FwaNkc3ZwQkXv2DxVuXauQ43tu4LDtieM2cQNQbFh+WDe5bZqh63PD1 HysAQ0aQbGsNoq9VzZnXWU+ngMDmktsNAERclLDAiwbcl8ojKWAzFemZtBkSLplc+0tH W9T5Q1fKtmYCXm+usvMOnppGQ7vGa7c4ZM43NtvQp6ojdePg4q334BBnB1x86rBowHtO id9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hchkBIVoYCo1P4XY3aj+AvBiVc5+liOIV4sOh23Djm8=; b=E8D0yjBjj0+Je+M7MHrokQpLHXkoVA4ptgdRbsBXt/0/RVvoLmmYcpsOIS13q19b5Y upZbFlgJ/GaS9wdFieHqdX3X/i/ovz70KQwcg6SCC1xIhn9wuGhEXPtbioqaZdRzG2tZ MWtOsYwtkh3Y0zPvrX7m3hymeC2a/ix0e8iLUYk9xf9abIHPKScb5+ayts+JT7b0K7Fw uinbKmMsKj4ZLVodF+hwLvxRM+dIlF7YMPcDJ3P68+06S5VFgYWeqLcmnWoTOFTIFgnA qG1DERGFns0KBtKs4GPcY8q2ozEcXA9eHor1Bh5WXJhlMapbI+vZofh/SZUQJMT8FQzP gl2g==
X-Gm-Message-State: AOUpUlG3HVxRaGp5NYL8Ihq4xqDYl0V2YNsjfVXhO+Nq8AfJ1fUjHfH6 d9/Pqp3OXkcTQ+kTXbU+WFnRLwrPp3hlSDBkYG1ymLPD
X-Google-Smtp-Source: AAOMgpdvJ1fWVi4UFLmAEGrIfsyyMEIA5faueUiWlsediWEgx4wMwcvLjv9gml+SGKBZxaiaWh6E0mG4MCLLvjjfmGk=
X-Received: by 2002:aca:3954:: with SMTP id g81-v6mr6189212oia.215.1532569318045;  Wed, 25 Jul 2018 18:41:58 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Martin Thomson 
Date: Thu, 26 Jul 2018 11:41:48 +1000
Message-ID: 
Subject: Re: Go Back to Single Packet Number Space
To: Nick Banks 
Cc: QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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 01:42:01 -0000

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 to=
pic, 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 relate=
d to using multiple packet number spaces. A lot of the issues result in dup=
licated state (and associated memory) for all the packet number spaces. But=
 more importantly, the multiple packet number spaces bring in a lot more co=
mplexity of logic, compared to the previous single packet number space desi=
gn. There is a lot more detail in the GitHub issue, and I=E2=80=99d ask tha=
t 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 provi=
des good (if not better, IMO) solutions to the problems that were fixed pre=
viously with multiple packet number spaces. I believe having a single packe=
t 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=E2=80=99t want this issue to slip out=
 into the next version.
>
>
>
> Thanks,
>
> - Nick


From nobody Wed Jul 25 19:36:11 2018
Return-Path: 
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 29BC4130EAA for ; Wed, 25 Jul 2018 19:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 UYyGDc2FJx9h for ; Wed, 25 Jul 2018 19:36:05 -0700 (PDT)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680099.outbound.protection.outlook.com [40.107.68.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB7A130E3C for ; Wed, 25 Jul 2018 19:36:05 -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=qJuawzBA/3al1RqVQBaD1H3OsWNVrp/3pmYiKLO60kc=; b=S8Jmxo2+O0v9F24MoIGzzroO8FDJ23UvK/MiKgtNwxSC+LOhbO8EgFeer79WXpVWvEqYde1+jQAFo6h6gKodKGP3spORMT+cL4NNUw7qFzhvbNLf3IDOnMfS5L2Z7ODNT99O6ocTqbh9+7sQoyNKoX2dtGB5Uz8avium3iCeiag=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0965.namprd21.prod.outlook.com (52.132.133.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.2; Thu, 26 Jul 2018 02:36:03 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545%2]) with mapi id 15.20.1017.000; Thu, 26 Jul 2018 02:36:03 +0000
From: Nick Banks 
To: Martin Thomson , QUIC WG 
Subject: RE: Go Back to Single Packet Number Space
Thread-Topic: Go Back to Single Packet Number Space
Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0wANbUcAAAFHrbA=
Date: Thu, 26 Jul 2018 02:36:03 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-07-26T02:36:01.6551027Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:1:1d83:4be1:90a4:2f3c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0965; 6:jVBaV90Ik2W6AxBWMThsVVl+ocUSnsq8R0vsQ6fQbOIoS5TTAYstPWtPrBr5nuukZUUGJoFLG7IQuF6/HmckQmtA3lXGQrVg1lgD/Wa8vhkT4PZE3M3Cqm8VcKdFvQICCAzcCSgblsUwyS1SRoxmHdOomZGIBf/kHMZc+pB+P0SJRQd6sEXYIfDfwXP3kxjC6m44ceyPR9NW9l1dlqW1dqAO6vsCTmzd7SWprD19v5rWvrqKw7PqELZ2FZ67gv6kkY6B5Jo3nJfLS7+tCr5iRUf4KQEzgFDJDcNcAmsqwgFsxoZz1zAz/jZ500BxmFnn/rg1RaPt0IsQbn3KKmSBR75J0suentTcIBMrW2mW4y0LJ4Buh1yMIUnc9XpaAxSQ9qPYBKW7iyBHoQMMO5VsbqsRo0zmIPn3Z9m/tQovSb4HRtMu03VQaigot+MpTkeD4biCHd27KZ8t6+GOo4BpWQ==; 5:tBFHZSoqp4mwHkNH0ShRJh2paFuMzKhFJromMFkZxN91kaJ+g/ynzkIFsD3Yis8xmMt+kzOnyQoIv8tM5QdnyOAvyt/m93TKwWTYDFYJyJ87u+o75KcpwN82Nx5T6GyayQjT+CLzeACcJKrZDAMokHlBPGmaA06ylytD0tjpgfI=; 7:gx2M9JYTuf/UdD8ZOIuh8wY38wC9RKMmRCV/TrsXXC7nrnNcfMyQ4+njcrS2PtFqyS/nAAgCTqscYRWMiKhNRBqUt5y25+g9DyXLqs5APnJcDImeddmkYPyFwAOZcs9CwO/ZZmnHi1MUgYXj1VoorvkmB4t/a2pGlqoTFbEDiI7yJRvs8xxvLktmaqYnN9ET8byC4i1vdhjRaH3lzHprIJgQi99Qa5suMTLkqKk+A4A5Hcu0OhixOsV1oRZsO7PA
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: aec2af75-3f05-4692-453c-08d5f2a087f8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR2101MB0965; 
x-ms-traffictypediagnostic: DM5PR2101MB0965:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231311)(944501410)(52105095)(2018427008)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0965; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0965; 
x-forefront-prvs: 07459438AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(136003)(39860400002)(346002)(396003)(189003)(199004)(13464003)(53936002)(6436002)(105586002)(39060400002)(22452003)(446003)(74316002)(11346002)(486006)(2906002)(10090500001)(106356001)(5250100002)(25786009)(316002)(14454004)(5660300001)(46003)(110136005)(97736004)(33656002)(8990500004)(6306002)(76176011)(256004)(86362001)(9686003)(54896002)(8936002)(81156014)(236005)(81166006)(99286004)(7696005)(10290500003)(68736007)(476003)(6246003)(790700001)(55016002)(8676002)(6506007)(53546011)(102836004)(229853002)(2900100001)(186003)(6116002)(7736002)(478600001)(14444005)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0965; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: PAILi7HIh4B8CkB/LXh2Y4GNcOizafXOvDQ3IRFD9dOvo/n7BnR46nwOcVIFD8+dpMqHhOeiALrrv6a27VL75ME4mCSn6Z6J/5kwhEuhKMiRQvUi5UjvpoX0E4RB2GsC8cbHs2RBDKAa1Q9HaIx5c6Vo6f5HCEWfzQA2XlN0s6TyY1XRFdKDWDqCzPmhZpxU3Mp4rzdFtLxU/D+lRgBoRtrTTf67kx5MJSb+7xUxkmp72sAIJze4tgx5PHAryw9GfdA7UOomSmbS86eVqc/VwIfNLf5axlcRmWcN1aC7uj6eYoGn/kQFaOD6/OyCsHCNmPCrLrkqL6eCDLeqeYmTMC1TwIZz3Jgq2i2bbKwlQe8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901E7A2FB4F8F8C79FEAEA4B32B0DM5PR2101MB0901_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aec2af75-3f05-4692-453c-08d5f2a087f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 02:36:03.1466 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0965
Archived-At: 
X-BeenThere: quic@ietf.org
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 02:36:09 -0000

--_000_DM5PR2101MB0901E7A2FB4F8F8C79FEAEA4B32B0DM5PR2101MB0901_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QSBsb3QgbW9yZSBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCByZWxhdGVkIHRvIHRoaXMgb24g
dGhlIGlzc3VlLCBidXQgSSBjYW4gZXhwYW5kIG9uIHNvbWUgb2YgaXQgaGVyZS4NCg0KDQoNClRo
ZSBkZXNpZ24gZm9yIG1hbmFnaW5nIHNlbnQgcGFja2V0cyBhbmQgaGFuZGxpbmcgQUNLIGZyYW1l
cyBmb3IgdGhlbSBmb3IgdGhlIHR3byBkZXNpZ25zIGxvb2tzIGFzIGZvbGxvd3M6DQoNCg0KDQpT
aW5nbGUgUGFja2V0IFNwYWNlDQoNCiAgKiAgIEEgc2luZ2xlIGxpc3Qgb2Ygc2VudCBwYWNrZXQg
bWV0YWRhdGEgb2JqZWN0cywgYW5kIG90aGVyIGxvc3MgZGV0ZWN0aW9uL3JlY292ZXJ5IHN0YXRl
IChsYXJnZXN0IHBhY2tldCBudW1iZXIsIGxhc3Qgc2VudCB0aW1lLCBSVE8gdGltZXLigKYpLg0K
ICAqICAgRWFjaCBtZXRhZGF0YSBvYmplY3QgaGFzIDIgYml0cyBmb3IgdHJhY2tpbmcgZW5jcnlw
dGlvbiBsZXZlbCB1c2VkIHRvIHNlbmQgdGhlIHBhY2tldC4NCiAgKiAgIE9uIHJlY2VpcHQgb2Yg
YW4gQUNLIGZyYW1lLCBlbmNyeXB0aW9uIGxldmVsIGFuZCBmcmFtZSBhcmUgcGFzc2VkIHRvIHRo
ZSBBQ0sgcHJvY2Vzc2luZyBsb2dpYy4gVGhpcyBsb2dpYyB0cmF2ZXJzZXMgdGhlIGxpc3Qgb2Yg
c2VudCBwYWNrZXRzIGFuZCBqdXN0IHZlcmlmaWVzIHRoYXQgdGhlIHJlY2VpdmVkIGVuY3J5cHRp
b24gbGV2ZWwgPj0gdG8gdGhlIG9yaWdpbmFsIGxldmVsLg0KDQoNCg0KTXVsdGlwbGUgUGFja2V0
IFNwYWNlcw0KDQogICogICBUaHJlZSBsaXN0cyBvZiBzZW50IHBhY2tldCBtZXRhZGF0YSBvYmpl
Y3RzIGFuZCB0aGVpciBhc3NvY2lhdGVkIGxvc3MgZGV0ZWN0aW9uL3JlY292ZXJ5IHN0YXRlLg0K
ICAqICAgT24gcmVjZWlwdCBvZiBhbiBBQ0sgZnJhbWUsIGVuY3J5cHRpb24gbGV2ZWwgYW5kIGZy
YW1lIGFyZSBwYXNzZWQgdG8gdGhlIEFDSyBwcm9jZXNzaW5nIGxvZ2ljLiBUaGUgZW5jcnlwdGlv
biBsZXZlbCBpbmRpY2F0ZXMgd2hlbiBzZW50IHBhY2tldCBsaXN0IHRvIHNlYXJjaC4NCg0KDQoN
ClRoZSBsb2dpYyBjb21wbGV4aXR5IG9mIHByb2Nlc3NpbmcgdGhlIEFDSyBpcyBwcmV0dHkgbXVj
aCB0aGUgc2FtZSwgYnV0IHRoZSBtdWx0aXBsZSBwYWNrZXQgc3BhY2VzIGhhcyBhIGxvdCBtb3Jl
IHN0YXRlIHRyYWNraW5nLiBBZGRpdGlvbmFsbHksIGhvdyBwYWNrZXQgbG9zcyB3b3JrcyBhY3Jv
c3MgcGFja2V0IGxldmVscyBpcyBub3Qgd2VsbCBleHBsYWluZWQuIFdpdGggc2luZ2xlIHBhY2tl
dCBzcGFjZSwgdGhlcmUgaXMgbm8gZXh0cmEgY29tcGxleGl0eSBmb3IgY3Jvc3MtcGFja2V0IHNw
YWNlIGxvc3MgcmVjb3ZlcnkuDQoNCg0KDQpPbiB0aGUgc2lkZSBvZiB0aGUgYWNrbm93bGVkZ2Vy
LCB0aGVyZSBpcyBhIGxvdCBtb3JlIGNvbXBsZXhpdHkuIEFnYWluLCBrZWVwaW5nIHRocmVlIHRp
bWVzIHRoZSBzdGF0ZSB0byB0cmFjayB3aGljaCBwYWNrZXRzIG51bWJlcnMgYXJlIG91dHN0YW5k
aW5nIGluIHdoaWNoIGVuY3J5cHRpb24gbGV2ZWwgaXMgYSBidXJkZW4uIFRoZSBtb3N0IHBhaW5m
dWwgcGFydCAoYXQgbGVhc3QgZm9yIG15IGNvZGUpIGlzIHdoZW4gaXQgdGltZXMgdG8gZ2VuZXJh
dGUgYWxsIHRoZSBuZWNlc3NhcnkgcGFja2V0cyBnaXZlbiB0aGUgY3VycmVudCBzdGF0ZS4gVGFr
aW5nIHRob3NlIHRocmVlIHNldHMgb2YgcGFja2V0IG51bWJlciB0byBhY2tub3dsZWRnZSBhbmQg
Z2VuZXJhdGUgYWxsIHRoZSBjb3JyZWN0bHkgZm9ybWF0dGVkIHBhY2tldHMgaW4gdGhlIGFwcHJv
cHJpYXRlIGVuY3J5cHRpb24gbGV2ZWxzIGluIHF1aXRlIGludm9sdmVkLiBNeSBsb2dpYyBmb3Ig
ZGVjaWRpbmcgd2hhdCB0eXBlIG9mIHBhY2tldCB0byBmcmFtZSBuZXh0IGFuZCB3aGF0IGNhbi9z
aG91bGQgYmUgcHV0IGluIGl0IHN0aWxsIGhhcyBidWdzIGFmdGVyIHdvcmtpbmcgb24gaXQgZm9y
IGEgZmV3IHdlZWtzLiBXaXRoIGEgc2luZ2xlIHBhY2tldCBudW1iZXIgc3BhY2UsIHlvdSBvbmx5
IGtlZXAgMSBzZXQgb2YgcGFja2V0IG51bWJlcnMgdG8gYWNrbm93bGVkZ2UsIGFuZCB0aGUgaGln
aGVzdCBlbmNyeXB0aW9uIGxldmVsIGZvciBhIHBhY2tldCBudW1iZXIgdGhhdCBuZWVkcyB0byBi
ZSBhY2tub3dsZWRnZWQuIFRoZW4sIHlvdSBzZW5kIGEgc2luZ2xlIHBhY2tldCwgd2l0aCBhIHNp
bmdsZSBBQ0sgZnJhbWUgYXQgdGhhdCBoaWdoZXN0IGVuY3J5cHRpb24gbGV2ZWwgKG9yIGhpZ2hl
ciksIGFuZCB5b3UgYXJlIGRvbmUuDQoNCg0KDQpCb3R0b20gbGluZSwgbXVsdGlwbGUgcGFja2V0
IG51bWJlcnMgcmVxdWlyZSAzIHRpbWVzIHRoZSBzdGF0ZSBhbmQgcmVxdWlyZSBhIGxvdCBvZiBh
ZGRpdGlvbmFsIGxvZ2ljIHRvIG1hbmFnZSwgYm90aCBvbiB0aGUgc2VuZCBhbmQgcmVjZWl2ZSBz
aWRlLiBJTU8sIHRoaXMgaXMgYSBsb3Qgb2YgY29tcGxleGl0eSB0aGF0IGlzIG5vdCBuZWVkZWQs
IGFuZCBpcyBvdmVya2lsbCBmb3Igd2hhdCB1c3VhbGx5IGlzIGp1c3QgMSBvciAyIFJUVCBvZiB0
aGUgZW50aXJlIGNvbm5lY3Rpb24uDQoNCg0KDQotIE5pY2sNCg0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwu
Y29tPg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDI1LCAyMDE4IDY6NDIgUE0NClRvOiBOaWNrIEJh
bmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4N
ClN1YmplY3Q6IFJlOiBHbyBCYWNrIHRvIFNpbmdsZSBQYWNrZXQgTnVtYmVyIFNwYWNlDQoNCg0K
DQpUaGUgZmVlZGJhY2sgSSd2ZSBoZWFyZCBpcyB0aGF0IHRoZSBzaW1wbGlmaWNhdGlvbiBpcyBz
dWJqZWN0aXZlLg0KDQpPdGhlcnMgaGF2ZSBzYWlkIHRoYXQgYSBzaW5nbGUgc3BhY2Ugd291bGQg
Y29tcGxpY2F0ZSB0aGVpciBpbXBsZW1lbnRhdGlvbiBjb25zaWRlcmFibHkgbW9yZS4gIFlvdSBt
aWdodCB3YW50IHRvIHNheSBtb3JlIGFib3V0IHRoYXQuDQoNCg0KDQpUaGUgbG9zcyBvZiBhY2tu
b3dsZWRnZW1lbnRzIGR1cmluZyB0aGUgSW5pdGlhbCBwaGFzZSBoYXMgdGhlIHVuZm9ydHVuYXRl
IGVmZmVjdCBvZiBmb3JjaW5nIGltcGxlbWVudGF0aW9ucyB0byByZWx5IG9uIGltcGxpY2l0IGFj
a25vd2xlZGdtZW50LiAgVGhpcyBkb2Vzbid0IHNlZW0gbGlrZSBhIHByb2JsZW0gbm93LCBidXQg
d2UncmUgY2xvc2UgdG8gdGhlIHF1YW50dW0gY29tcHV0ZXIgY3J5cHRvZ3JhcGhpYyBhcG9jYWx5
cHNlIChwdXQgdGhhdCBvbiBhIHNhbmR3aWNoIGJvYXJkIGFuZCB5ZWxsIGl0IG9uIHN0cmVldCBj
b3JuZXJzIGZvbGtzISkgYW5kIHRoaXMgc29ydCBvZiByZWR1Y3Rpb24gaW4gY2FwYWJpbGl0eSBj
b3VsZCBzZXJpb3VzIGltcGFpciBvdXIgYWJpbGl0eSB0byBzaGlwIGEga2V5IGV4Y2hhbmdlIHRo
YXQgZG9lc24ndCBoYXZlIHByb2JsZW1zLg0KDQoNCg0KTm93LCB0aGlzIGxhdHRlciB0aGluZyBp
cyBub3QgYW4gdW5maXhhYmxlIHByb2JsZW0gaWYgeW91IGNhcmVkIGFib3V0IGl0LCBidXQgaXQg
ZGVwZW5kcyBvbiB3aGF0IHlvdXIgcmVhbCBwcm9ibGVtIGlzLg0KDQpPbiBUaHUsIEp1bCAyNiwg
MjAxOCBhdCA1OjI5IEFNIE5pY2sgQmFua3MgPG5pYmFua3M9NDBtaWNyb3NvZnQuY29tQGRtYXJj
LmlldGYub3JnPG1haWx0bzpuaWJhbmtzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+
IHdyb3RlOg0KDQo+DQoNCj4gSGVsbG8gRm9sa3MsDQoNCj4NCg0KPg0KDQo+DQoNCj4gSSBoYXZl
IG9wZW5lZCBhIEdpdEh1YiBJc3N1ZSAoIzE1NzkpIGFuZCBQdWxsIFJlcXVlc3QgKCMxNTkxKSBm
b3IgdGhpcyB0b3BpYywgYnV0IGl0IHNlZW1zIHByb2dyZXNzZWQgaGFzIHN0YWxsZWQsIHNvIEkg
ZmlndXJlZCBJIHNob3VsZCB0YWtlIGl0IHRvIHRoZSBsaXN0Lg0KDQo+DQoNCj4NCg0KPg0KDQo+
IFdoaWxlIGltcGxlbWVudGluZyBkcmFmdC0xMywgSSBjYW1lIGFjcm9zcyBhIG51bWJlciBvZiBw
YWluIHBvaW50cyByZWxhdGVkIHRvIHVzaW5nIG11bHRpcGxlIHBhY2tldCBudW1iZXIgc3BhY2Vz
LiBBIGxvdCBvZiB0aGUgaXNzdWVzIHJlc3VsdCBpbiBkdXBsaWNhdGVkIHN0YXRlIChhbmQgYXNz
b2NpYXRlZCBtZW1vcnkpIGZvciBhbGwgdGhlIHBhY2tldCBudW1iZXIgc3BhY2VzLiBCdXQgbW9y
ZSBpbXBvcnRhbnRseSwgdGhlIG11bHRpcGxlIHBhY2tldCBudW1iZXIgc3BhY2VzIGJyaW5nIGlu
IGEgbG90IG1vcmUgY29tcGxleGl0eSBvZiBsb2dpYywgY29tcGFyZWQgdG8gdGhlIHByZXZpb3Vz
IHNpbmdsZSBwYWNrZXQgbnVtYmVyIHNwYWNlIGRlc2lnbi4gVGhlcmUgaXMgYSBsb3QgbW9yZSBk
ZXRhaWwgaW4gdGhlIEdpdEh1YiBpc3N1ZSwgYW5kIEnigJlkIGFzayB0aGF0IGZvbGtzIHRha2Ug
YSBsb29rIGF0IGl0IChhbmQgdGhlIFBSKSBhbmQgcHJvdmlkZSBhbnkgZmVlZGJhY2sgdGhleSBt
aWdodCBoYXZlLiBJIGZlZWwgdGhhdCBteSBJc3N1ZSBhZGVxdWF0ZWx5IGRlc2NyaWJlcyB0aGUg
cHJvYmxlbSBhbmQgbXkgUFIgcHJvdmlkZXMgZ29vZCAoaWYgbm90IGJldHRlciwgSU1PKSBzb2x1
dGlvbnMgdG8gdGhlIHByb2JsZW1zIHRoYXQgd2VyZSBmaXhlZCBwcmV2aW91c2x5IHdpdGggbXVs
dGlwbGUgcGFja2V0IG51bWJlciBzcGFjZXMuIEkgYmVsaWV2ZSBoYXZpbmcgYSBzaW5nbGUgcGFj
a2V0IG51bWJlciBzcGFjZSB3aWxsIGRyYXN0aWNhbGx5IHNpbXBsaWZ5IGltcGxlbWVudGF0aW9u
cyBpbiB0aGUgZW5kLg0KDQo+DQoNCj4NCg0KPg0KDQo+IEZpbmFsbHksIGFzIFFVSUMgVjEgKDI/
KSBpcyBjb21pbmcgdG8gYSBjbG9zZSAoaG9wZWZ1bGx5KSBJIGZlZWwgbGlrZSB3ZSBzaG91bGQg
cmVzb2x2ZSB0aGlzIGlzc3VlIHNvb24uIEkgZG9u4oCZdCB3YW50IHRoaXMgaXNzdWUgdG8gc2xp
cCBvdXQgaW50byB0aGUgbmV4dCB2ZXJzaW9uLg0KDQo+DQoNCj4NCg0KPg0KDQo+IFRoYW5rcywN
Cg0KPg0KDQo+IC0gTmljaw0K

--_000_DM5PR2101MB0901E7A2FB4F8F8C79FEAEA4B32B0DM5PR2101MB0901_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu
aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozODUzNzU3NDg7DQoJbXNvLWxpc3Qt
dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yOTgwNDYzMTIgNjc2OTg2ODkg
Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2
OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM4LjI1
cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h
cmdpbi1sZWZ0Ojc0LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1s
ZWZ0OjExMC4yNXB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCW1hcmdpbi1sZWZ0OjE0Ni4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h
cmdpbi1sZWZ0OjE4Mi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl
bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4t
bGVmdDoyMTguMjVwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ
e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgltYXJnaW4tbGVmdDoyNTQuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg
bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt
YXJnaW4tbGVmdDoyOTAuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2
ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2lu
LWxlZnQ6MzI2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1s
aXN0LWlkOjU1Mjc0MTEwOTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w
bGF0ZS1pZHM6MzEzOTM5MzYwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3
Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxl
dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzguMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K
QGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgltYXJnaW4tbGVmdDo3NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs
MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCglt
YXJnaW4tbGVmdDoxMTAuMjVwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2
ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgltYXJnaW4tbGVmdDoxNDYuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K
QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgltYXJnaW4tbGVmdDoxODIuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg
bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ
bWFyZ2luLWxlZnQ6MjE4LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxl
dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjU0LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N
CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJbWFyZ2luLWxlZnQ6MjkwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0
IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K
CW1hcmdpbi1sZWZ0OjMyNi4yNXB0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0K
CXttc28tbGlzdC1pZDoxMjYxMTEwNTUwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s
aXN0LXRlbXBsYXRlLWlkczotMTM5NjI2NDk2MiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2
NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA
bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh
bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs
NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K
QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm
b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu
b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1
aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn
aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgbG90IG1vcmUg
aGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgcmVsYXRlZCB0byB0aGlzIG9uIHRoZSBpc3N1ZSwg
YnV0IEkgY2FuIGV4cGFuZCBvbiBzb21lIG9mIGl0IGhlcmUuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPlRoZSBkZXNpZ24gZm9yIG1hbmFnaW5nIHNlbnQgcGFja2V0cyBhbmQgaGFuZGxp
bmcgQUNLIGZyYW1lcyBmb3IgdGhlbSBmb3IgdGhlIHR3byBkZXNpZ25zIGxvb2tzIGFzIGZvbGxv
d3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48dT48bzpwPjxzcGFu
IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+Jm5ic3A7PC9zcGFuPjwvbzpwPjwvdT48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48dT5TaW5nbGUgUGFja2V0IFNwYWNlPG86cD48L286
cD48L3U+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg
Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm8xIj5BIHNp
bmdsZSBsaXN0IG9mIHNlbnQgcGFja2V0IG1ldGFkYXRhIG9iamVjdHMsIGFuZCBvdGhlciBsb3Nz
IGRldGVjdGlvbi9yZWNvdmVyeSBzdGF0ZSAobGFyZ2VzdCBwYWNrZXQgbnVtYmVyLCBsYXN0IHNl
bnQgdGltZSwgUlRPIHRpbWVy4oCmKS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29QbGFp
blRleHQiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+RWFjaCBtZXRhZGF0YSBvYmpl
Y3QgaGFzIDIgYml0cyBmb3IgdHJhY2tpbmcgZW5jcnlwdGlvbiBsZXZlbCB1c2VkIHRvIHNlbmQg
dGhlIHBhY2tldC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl
PSJtc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+T24gcmVjZWlwdCBvZiBhbiBBQ0sgZnJhbWUsIGVu
Y3J5cHRpb24gbGV2ZWwgYW5kIGZyYW1lIGFyZSBwYXNzZWQgdG8gdGhlIEFDSyBwcm9jZXNzaW5n
IGxvZ2ljLiBUaGlzIGxvZ2ljIHRyYXZlcnNlcyB0aGUgbGlzdCBvZiBzZW50IHBhY2tldHMgYW5k
IGp1c3QgdmVyaWZpZXMgdGhhdCB0aGUgcmVjZWl2ZWQgZW5jcnlwdGlvbiBsZXZlbCAmZ3Q7PSB0
bw0KIHRoZSBvcmlnaW5hbCBsZXZlbC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHU+TXVsdGlwbGUgUGFja2V0IFNwYWNlczwvdT48bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHls
ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQi
IHN0eWxlPSJtYXJnaW4tbGVmdDoyLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRocmVl
IGxpc3RzIG9mIHNlbnQgcGFja2V0IG1ldGFkYXRhIG9iamVjdHMgYW5kIHRoZWlyIGFzc29jaWF0
ZWQgbG9zcyBkZXRlY3Rpb24vcmVjb3Zlcnkgc3RhdGUuPG86cD48L286cD48L2xpPjxsaSBjbGFz
cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4yNXB0O21zby1saXN0OmwwIGxl
dmVsMSBsZm8zIj5PbiByZWNlaXB0IG9mIGFuIEFDSyBmcmFtZSwgZW5jcnlwdGlvbiBsZXZlbCBh
bmQgZnJhbWUgYXJlIHBhc3NlZCB0byB0aGUgQUNLIHByb2Nlc3NpbmcgbG9naWMuIFRoZSBlbmNy
eXB0aW9uIGxldmVsIGluZGljYXRlcyB3aGVuIHNlbnQgcGFja2V0IGxpc3QgdG8gc2VhcmNoLjxv
OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbG9naWMgY29tcGxleGl0eSBv
ZiBwcm9jZXNzaW5nIHRoZSBBQ0sgaXMgcHJldHR5IG11Y2ggdGhlIHNhbWUsIGJ1dCB0aGUgbXVs
dGlwbGUgcGFja2V0IHNwYWNlcyBoYXMgYSBsb3QgbW9yZSBzdGF0ZSB0cmFja2luZy4gQWRkaXRp
b25hbGx5LCBob3cgcGFja2V0IGxvc3Mgd29ya3MgYWNyb3NzIHBhY2tldCBsZXZlbHMgaXMgbm90
IHdlbGwgZXhwbGFpbmVkLiBXaXRoIHNpbmdsZSBwYWNrZXQgc3BhY2UsDQogdGhlcmUgaXMgbm8g
ZXh0cmEgY29tcGxleGl0eSBmb3IgY3Jvc3MtcGFja2V0IHNwYWNlIGxvc3MgcmVjb3ZlcnkuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9uIHRoZSBzaWRlIG9mIHRoZSBhY2tub3dsZWRn
ZXIsIHRoZXJlIGlzIGEgbG90IG1vcmUgY29tcGxleGl0eS4gQWdhaW4sIGtlZXBpbmcgdGhyZWUg
dGltZXMgdGhlIHN0YXRlIHRvIHRyYWNrIHdoaWNoIHBhY2tldHMgbnVtYmVycyBhcmUgb3V0c3Rh
bmRpbmcgaW4gd2hpY2ggZW5jcnlwdGlvbiBsZXZlbCBpcyBhIGJ1cmRlbi4gVGhlIG1vc3QgcGFp
bmZ1bCBwYXJ0IChhdCBsZWFzdCBmb3IgbXkgY29kZSkNCiBpcyB3aGVuIGl0IHRpbWVzIHRvIGdl
bmVyYXRlIGFsbCB0aGUgbmVjZXNzYXJ5IHBhY2tldHMgZ2l2ZW4gdGhlIGN1cnJlbnQgc3RhdGUu
IFRha2luZyB0aG9zZSB0aHJlZSBzZXRzIG9mIHBhY2tldCBudW1iZXIgdG8gYWNrbm93bGVkZ2Ug
YW5kIGdlbmVyYXRlIGFsbCB0aGUgY29ycmVjdGx5IGZvcm1hdHRlZCBwYWNrZXRzIGluIHRoZSBh
cHByb3ByaWF0ZSBlbmNyeXB0aW9uIGxldmVscyBpbiBxdWl0ZSBpbnZvbHZlZC4gTXkgbG9naWMg
Zm9yIGRlY2lkaW5nDQogd2hhdCB0eXBlIG9mIHBhY2tldCB0byBmcmFtZSBuZXh0IGFuZCB3aGF0
IGNhbi9zaG91bGQgYmUgcHV0IGluIGl0IHN0aWxsIGhhcyBidWdzIGFmdGVyIHdvcmtpbmcgb24g
aXQgZm9yIGEgZmV3IHdlZWtzLiBXaXRoIGEgc2luZ2xlIHBhY2tldCBudW1iZXIgc3BhY2UsIHlv
dSBvbmx5IGtlZXAgMSBzZXQgb2YgcGFja2V0IG51bWJlcnMgdG8gYWNrbm93bGVkZ2UsIGFuZCB0
aGUgaGlnaGVzdCBlbmNyeXB0aW9uIGxldmVsIGZvciBhIHBhY2tldCBudW1iZXINCiB0aGF0IG5l
ZWRzIHRvIGJlIGFja25vd2xlZGdlZC4gVGhlbiwgeW91IHNlbmQgYSBzaW5nbGUgcGFja2V0LCB3
aXRoIGEgc2luZ2xlIEFDSyBmcmFtZSBhdCB0aGF0IGhpZ2hlc3QgZW5jcnlwdGlvbiBsZXZlbCAo
b3IgaGlnaGVyKSwgYW5kIHlvdSBhcmUgZG9uZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Qm90dG9tIGxpbmUsIG11bHRpcGxlIHBhY2tldCBudW1iZXJzIHJlcXVpcmUgMyB0aW1lcyB0
aGUgc3RhdGUgYW5kIHJlcXVpcmUgYSBsb3Qgb2YgYWRkaXRpb25hbCBsb2dpYyB0byBtYW5hZ2Us
IGJvdGggb24gdGhlIHNlbmQgYW5kIHJlY2VpdmUgc2lkZS4gSU1PLCB0aGlzIGlzIGEgbG90IG9m
IGNvbXBsZXhpdHkgdGhhdCBpcyBub3QgbmVlZGVkLCBhbmQgaXMgb3ZlcmtpbGwgZm9yIHdoYXQg
dXN1YWxseQ0KIGlzIGp1c3QgMSBvciAyIFJUVCBvZiB0aGUgZW50aXJlIGNvbm5lY3Rpb24uPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gTmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IE1hcnRpbiBUaG9t
c29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7IDxicj4NClNlbnQ6IFdlZG5lc2Rh
eSwgSnVseSAyNSwgMjAxOCA2OjQyIFBNPGJyPg0KVG86IE5pY2sgQmFua3MgJmx0O25pYmFua3NA
bWljcm9zb2Z0LmNvbSZndDs8YnI+DQpDYzogUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8
YnI+DQpTdWJqZWN0OiBSZTogR28gQmFjayB0byBTaW5nbGUgUGFja2V0IE51bWJlciBTcGFjZTwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+VGhlIGZlZWRiYWNrIEkndmUgaGVhcmQgaXMgdGhhdCB0aGUgc2lt
cGxpZmljYXRpb24gaXMgc3ViamVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPk90aGVycyBoYXZlIHNhaWQgdGhhdCBhIHNpbmdsZSBzcGFjZSB3b3VsZCBjb21w
bGljYXRlIHRoZWlyIGltcGxlbWVudGF0aW9uIGNvbnNpZGVyYWJseSBtb3JlLiZuYnNwOyBZb3Ug
bWlnaHQgd2FudCB0byBzYXkgbW9yZSBhYm91dCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij5UaGUgbG9zcyBvZiBhY2tub3dsZWRnZW1lbnRzIGR1cmluZyB0aGUgSW5pdGlhbCBw
aGFzZSBoYXMgdGhlIHVuZm9ydHVuYXRlIGVmZmVjdCBvZiBmb3JjaW5nIGltcGxlbWVudGF0aW9u
cyB0byByZWx5IG9uIGltcGxpY2l0IGFja25vd2xlZGdtZW50LiZuYnNwOyBUaGlzIGRvZXNuJ3Qg
c2VlbSBsaWtlIGEgcHJvYmxlbSBub3csIGJ1dCB3ZSdyZSBjbG9zZSB0byB0aGUgcXVhbnR1bSBj
b21wdXRlciBjcnlwdG9ncmFwaGljDQogYXBvY2FseXBzZSAocHV0IHRoYXQgb24gYSBzYW5kd2lj
aCBib2FyZCBhbmQgeWVsbCBpdCBvbiBzdHJlZXQgY29ybmVycyBmb2xrcyEpIGFuZCB0aGlzIHNv
cnQgb2YgcmVkdWN0aW9uIGluIGNhcGFiaWxpdHkgY291bGQgc2VyaW91cyBpbXBhaXIgb3VyIGFi
aWxpdHkgdG8gc2hpcCBhIGtleSBleGNoYW5nZSB0aGF0IGRvZXNuJ3QgaGF2ZSBwcm9ibGVtcy48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tm93LCB0aGlzIGxhdHRlciB0aGluZyBpcyBu
b3QgYW4gdW5maXhhYmxlIHByb2JsZW0gaWYgeW91IGNhcmVkIGFib3V0IGl0LCBidXQgaXQgZGVw
ZW5kcyBvbiB3aGF0IHlvdXIgcmVhbCBwcm9ibGVtIGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+T24gVGh1LCBKdWwgMjYsIDIwMTggYXQgNToyOSBBTSBOaWNrIEJh
bmtzICZsdDs8YSBocmVmPSJtYWlsdG86bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0
Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l
Ij5uaWJhbmtzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSGVsbG8gRm9sa3Ms
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgaGF2ZSBvcGVuZWQgYSBHaXRIdWIgSXNzdWUg
KCMxNTc5KSBhbmQgUHVsbCBSZXF1ZXN0ICgjMTU5MSkgZm9yIHRoaXMgdG9waWMsIGJ1dCBpdCBz
ZWVtcyBwcm9ncmVzc2VkIGhhcyBzdGFsbGVkLCBzbyBJIGZpZ3VyZWQgSSBzaG91bGQgdGFrZSBp
dCB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgV2hpbGUgaW1wbGVtZW50
aW5nIGRyYWZ0LTEzLCBJIGNhbWUgYWNyb3NzIGEgbnVtYmVyIG9mIHBhaW4gcG9pbnRzIHJlbGF0
ZWQgdG8gdXNpbmcgbXVsdGlwbGUgcGFja2V0IG51bWJlciBzcGFjZXMuIEEgbG90IG9mIHRoZSBp
c3N1ZXMgcmVzdWx0IGluIGR1cGxpY2F0ZWQgc3RhdGUgKGFuZCBhc3NvY2lhdGVkIG1lbW9yeSkg
Zm9yIGFsbCB0aGUgcGFja2V0IG51bWJlciBzcGFjZXMuIEJ1dCBtb3JlIGltcG9ydGFudGx5LA0K
IHRoZSBtdWx0aXBsZSBwYWNrZXQgbnVtYmVyIHNwYWNlcyBicmluZyBpbiBhIGxvdCBtb3JlIGNv
bXBsZXhpdHkgb2YgbG9naWMsIGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyBzaW5nbGUgcGFja2V0
IG51bWJlciBzcGFjZSBkZXNpZ24uIFRoZXJlIGlzIGEgbG90IG1vcmUgZGV0YWlsIGluIHRoZSBH
aXRIdWIgaXNzdWUsIGFuZCBJ4oCZZCBhc2sgdGhhdCBmb2xrcyB0YWtlIGEgbG9vayBhdCBpdCAo
YW5kIHRoZSBQUikgYW5kIHByb3ZpZGUgYW55IGZlZWRiYWNrDQogdGhleSBtaWdodCBoYXZlLiBJ
IGZlZWwgdGhhdCBteSBJc3N1ZSBhZGVxdWF0ZWx5IGRlc2NyaWJlcyB0aGUgcHJvYmxlbSBhbmQg
bXkgUFIgcHJvdmlkZXMgZ29vZCAoaWYgbm90IGJldHRlciwgSU1PKSBzb2x1dGlvbnMgdG8gdGhl
IHByb2JsZW1zIHRoYXQgd2VyZSBmaXhlZCBwcmV2aW91c2x5IHdpdGggbXVsdGlwbGUgcGFja2V0
IG51bWJlciBzcGFjZXMuIEkgYmVsaWV2ZSBoYXZpbmcgYSBzaW5nbGUgcGFja2V0IG51bWJlciBz
cGFjZSB3aWxsDQogZHJhc3RpY2FsbHkgc2ltcGxpZnkgaW1wbGVtZW50YXRpb25zIGluIHRoZSBl
bmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEZpbmFsbHksIGFzIFFVSUMgVjEgKDI/KSBp
cyBjb21pbmcgdG8gYSBjbG9zZSAoaG9wZWZ1bGx5KSBJIGZlZWwgbGlrZSB3ZSBzaG91bGQgcmVz
b2x2ZSB0aGlzIGlzc3VlIHNvb24uIEkgZG9u4oCZdCB3YW50IHRoaXMgaXNzdWUgdG8gc2xpcCBv
dXQgaW50byB0aGUgbmV4dCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0
OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGFu
a3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IC0gTmljazxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DM5PR2101MB0901E7A2FB4F8F8C79FEAEA4B32B0DM5PR2101MB0901_--


From nobody Wed Jul 25 20:01:47 2018
Return-Path: 
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 31F97130EB2 for ; Wed, 25 Jul 2018 20:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 UGuX43SUwGM4 for ; Wed, 25 Jul 2018 20:01:42 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 F0913130ED3 for ; Wed, 25 Jul 2018 20:01:41 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id z8-v6so218927qto.9 for ; Wed, 25 Jul 2018 20:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ueqvjnqBezFh92Ef2mgEqTLe4ZJRJoVxMua6vVzm2hM=; b=Mela/ddSs75s+Vl/UoslrsXY0CYSdrwbCWZqk0dgKnH28yPMZNwKtSMjywgj/zuF/P jwF1cj+R9+JRd35uwJPtEjP3BW+O//CQ3ceOH2JjvSJ7nBptXzadIqA7Ywv89/4DTW04 30W85D3RA0/692p79h9MfivsAHiizu9t4TIL5fYTcTuzectQzF9CIov019fGFwpliowD zLhAhIIGbW5l0r8N3CHniGnjdjOi24G5WMRuwlou0YDRVvht8QXB5mrNoVgOD73toQEY EDboKTqCSaMB0OL0vYWVv2qSNdoq1qJUT1nZtTAf4rl5z0wvLrBsOnnl+ueG0CP6VkJv W7vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=ueqvjnqBezFh92Ef2mgEqTLe4ZJRJoVxMua6vVzm2hM=; b=qke9b0g+89ZpTF/lgIZD9mo9oxKGDLmR4TMx3DUIi6ECzg3qcua5oIqUz3gRjMmIk0 9BVKTaMw3O0uZc98I4Yuu7TVVKM+Q0+wMHSaLTEFFEDb2xytCabPP1OWjmxWJ1MIkDuw 2FBAsbujSKcSbjEK2TrVvv7mGSjw+cMAfHIbNyYUxDdguHtnfR2ny4qrW/qzNxa55mgi JMmTZht3chasGahCAJfpq5nHHQ5H0Y9DKRlXLC4k9AxnLo3Kydrwb52sk63qUqSiMYma oSXIzkZWoW2beeeUc5dIK2oLHenkbbnx+Cm+RCCLHoUDM+FgLgAdszszMUwHNTE+nRiC 6EyQ==
X-Gm-Message-State: AOUpUlFsZcqvwPRkpldL/4m7eq1Pvx1CCKlimye5A4UlSiufg+5FFFiq +TtH7OASZ4T9V4hmTo3h1Mwvag==
X-Google-Smtp-Source: AAOMgpdLcahLDkv87nVZbq/Y1YyYFKb6/3TRGNKtAmIqaht9W5fxz23iobqIeVq1KTbZfUIHt2zPiA==
X-Received: by 2002:ac8:725a:: with SMTP id l26-v6mr124365qtp.181.1532574101099;  Wed, 25 Jul 2018 20:01:41 -0700 (PDT)
Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id s6-v6sm90197qkb.26.2018.07.25.20.01.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jul 2018 20:01:40 -0700 (PDT)
Date: Wed, 25 Jul 2018 23:01:36 -0400
From: Dmitri Tikhonov 
To: Martin Thomson 
Cc: Nick Banks , QUIC WG 
Subject: Re: Go Back to Single Packet Number Space
Message-ID: <20180726030135.GA19322@ubuntu-dmitri>
Mail-Followup-To: Martin Thomson , Nick Banks , QUIC WG 
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
X-BeenThere: quic@ietf.org
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 03:01:46 -0000

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://github.com/quicwg/base-drafts/issues/1579#issuecomment-405720217


From nobody Wed Jul 25 21:26:57 2018
Return-Path: 
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 B1CA2130F5F for ; Wed, 25 Jul 2018 21:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 EeiIPKLe-geQ for ; Wed, 25 Jul 2018 21:26:53 -0700 (PDT)
Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC20130EDE for ; Wed, 25 Jul 2018 21:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple;  q=dns/txt; i=@apple.com; t=1532579212; x=2396492812; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/q3NYcnmxh278lJsrPJQNq2jA513ZHsFJNFmWdl78KE=; b=XUHL/VndufQPYPyVGle0fqdZ7jqzOB0xsyKvHnHBUfDbVgGhK9hTQKhmanThiFau lyA5DFXYY/cnM9ZaqTH1YUJru6JEhy+7YxnCdppdNmdtb2VMvGc2T1/zLtuFG+cY 8fII9lJDf64Rsp686lt2p3Zjhq+n7GOJ0lmjL8bWGjuJB0CqeEi6Vu1dX9htdb3X JXSDbnBpOq0RbVqrybzjv3sKcXAOwsRFQXNcgs7OYS7C+1Sl9/eNbL5C8HwurUx8 oXAi96yiI60K80Pr81JEy3CzlI142eldwAHCdueO8evx5nNnjT2yqTMPss2rv2xc 5AiuCJSGarCajXRH4QFDLQ==;
X-AuditID: 11ab0215-22fff70000002a18-bf-5b594d8c6571
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id 21.6C.10776.C8D495B5; Wed, 25 Jul 2018 21:26:52 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCG0045CHOR7B80@ma1-mtap-s01.corp.apple.com>; Wed, 25 Jul 2018 21:26:52 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCG00A00GYAXK00@nwk-mmpp-sz11.apple.com>; Wed, 25 Jul 2018 21:26:52 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: b0cb8fad22368bc753cfd02e8d50493f
X-Va-E-CD: 9972b49a85f1a3efa290995569b54582
X-Va-R-CD: 5fd1ac8411fc0aff2be93db04dc55585
X-Va-CD: 0
X-Va-ID: ea4268c5-21e5-4281-b6c0-a5d1e326a74a
X-V-A: 
X-V-T-CD: b0cb8fad22368bc753cfd02e8d50493f
X-V-E-CD: 9972b49a85f1a3efa290995569b54582
X-V-R-CD: 5fd1ac8411fc0aff2be93db04dc55585
X-V-CD: 0
X-V-ID: d57a0a32-6c28-4b25-8ab0-c464f04f16f5
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCG00G00H6XFA00@nwk-mmpp-sz11.apple.com>; Wed, 25 Jul 2018 21:26:52 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-26_01:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1
Received: from [17.234.78.29] (unknown [17.234.78.29]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCG00BJWHOR3160@nwk-mmpp-sz11.apple.com>; Wed, 25 Jul 2018 21:26:52 -0700 (PDT)
Sender: tpauly@apple.com
Subject: Re: Go Back to Single Packet Number Space
From: Tommy Pauly 
In-reply-to: <20180726030135.GA19322@ubuntu-dmitri>
Date: Wed, 25 Jul 2018 21:26:49 -0700
Cc: Martin Thomson , Nick Banks , QUIC WG 
Message-id: 
References:   <20180726030135.GA19322@ubuntu-dmitri>
To: Dmitri Tikhonov 
X-Mailer: Apple Mail (2.3445.100.13.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUiqOHDqtvjGxltMGO1ocWXCWwW1878Y7SY t2cTu0XPAm4HFo8Ty66weuycdZfdY8mSn0weT7YdZw5gieKySUnNySxLLdK3S+DK2HTtBXvB EfaKj49vMjcwTmTrYuTkkBAwkVjU/J+pi5GLQ0hgP5PEtvcnWUESvAKCEj8m32PpYuTgYBaQ lzh4XhYkzCygJfH9USsLRP1GJomZi56zQzhdTBJHDq2Emsou8efXDhYIW1vi6sl77DD2+8e7 4ewpE69B2VwSC7aeZoWwdSVmvnwLZbNJrD+xhAnC1pJYemI5K4zduGc9M4x94MhTqL2cEue/ TISaqSPR/2A/G8RxnUwSL66vhSrKlrjx+y+UHSxxfUsb1Af9TBJXJ8xhB3lZWEBCYvOeRJAa YQEjiYM/Z4MtYxNQkTj+bQOYzSlgLLHo7QEwm0VAVeLqt2UskCCqlWh+38EGCUUbif611xkh 5l9ilLi4ERTuHBwiAoYS+/YmT2BUnIUU2LMQgT0LKbAXMDKvYhTOTczM0c3MMzLUSywoyEnV S87P3cQIShyrmUR3MM5/ZXiIUYCDUYmH9+LMiGgh1sSy4srcQ4zSHCxK4rwfd4lFCwmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamAMyKjJedy33XjGG/mHcoITV/BFxF9UvTFrjlbg+jJ/Dm3R 1cWfHf+/U3G4+e7QvL2fb7w2DmsMZT1ty5x6OmRHRubT60VJPlUvy5eZb5nH3LHTJXp9RYHi i3k7vj7qPZPv1tcnsq+i5EnoW/ZOHY9fP5/NEHzFsnepMIvyiVX//B+v8A7estxPiaU4I9FQ i7moOBEAeUXivf0CAAA=
Archived-At: 
X-BeenThere: quic@ietf.org
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 04:26:56 -0000

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  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://github.com/quicwg/base-drafts/issues/1579#issuecomment-405720217
> 


From nobody Wed Jul 25 21:37:12 2018
Return-Path: 
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 48A71130EEC for ; Wed, 25 Jul 2018 21:37:10 -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=ham 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 h-qxS9LjJOhS for ; Wed, 25 Jul 2018 21:37:07 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6EA130E05 for ; Wed, 25 Jul 2018 21:37:06 -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=mkkuec8E930tIzUrmV4uBuFIhPlbfgpiWY80housZFg=; b=E6UVzdu5Dhkp0h7xHFGs8/I0DpfVRit/An9EJ7LL5oS+uJebVxKo9VbRGuWvKlPXZVcNCm/b4crEaoFc55/LfsVIBKcgNqVph7SzEhoMe4NgLQNVWJlC6wstX3Dajky/U06oGqwA7QSFD07lag04zJUpO5U1Np9IhHE941w9tCA=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB1109.namprd21.prod.outlook.com (52.132.130.19) 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 04:37:05 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545%2]) with mapi id 15.20.1017.000; Thu, 26 Jul 2018 04:37:05 +0000
From: Nick Banks 
To: Tommy Pauly , Dmitri Tikhonov , "quic@ietf.org" 
CC: Martin Thomson 
Subject: RE: Go Back to Single Packet Number Space
Thread-Topic: Go Back to Single Packet Number Space
Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0wANbUcAAALJdwAAAvnmgAAAQ0Hq
Date: Thu, 26 Jul 2018 04:37:05 +0000
Message-ID: 
References:   <20180726030135.GA19322@ubuntu-dmitri>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.235.10.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1109; 6:jdBBEZj7i/61ns7Nq0N5pvMaIsxxn9XETISPhmu9tTQ/xuvmn+MHxlnWQDyev61Wxgd4ExoW9UwQl5e1F/9LdaPkIbAslRBllhaKMKJhFtntETYkx5ng4YjXI4oWzFpkWLHgHz8LxNyZYITIqIl8xyrfRFtMrWn5JM+RXoShfoF+h/tZFKap8/36fni205l7FcVwAWNHHqhmA0l5euZ+lP0VQ9NWKDxZKbf9wszTrglDMdYurtwMIonhsqVrVC33LMVXsrv48Q6TAMaD97Kr7Feaw7KOJRt67/LXM0YfqCFoBOarntLxKfLl5BFpMpzqzFmYPW6iUcXSb5U2ANpogpzvdRFWV2PIWVexwM/NNkv/B4riN2OLpT2EhBroW8pLQW6vIIp7T+tjRCHEZIPcKXWNHgcYt5GLvW66lo1S1ZltVCFw3II3SE0KSVAQ4OnwxBmSws2/x1WbbUrppEH4sg==; 5:pj3w+nSjnf1lDs3JBTVWm+jhjILA0zbepke8j8ffY0+td6xiGBKmvQRbQHZMrqjFBHChd3N1PNMAvRkHK9HaeVfWgZizIddivfmrhnYNqF1MmC1ALgu43UG1vcEfbDucZzjpGCmTwnqgjJHmdj5Pa7Bm5WPX4dlT9faYml/3fbM=; 7:unI8TKq1QcZcWY3QLWcUBgJmvO+huSPINzscmIcGeGBJtB+opF4WfKsRLeEnr1Yc8lHowokg9paVHHVyuXVFUIUymxso3fgQCzsjezg9zujRxlaP1D9INun4BjJ87vi6xWlqCzhB740jbrkgCzSreAiXrcYWtoTuLSN1RnYVAo+EDlo+dpb8Te6492lnNIxdpLS5NXpD6YWd6fB/VU99j9UCBd4R3xFKN5+YpdwRM1hyKeMHBELOJYCQRWezLkuB
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 3e22c1d2-a405-4681-9c18-08d5f2b17086
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR2101MB1109; 
x-ms-traffictypediagnostic: DM5PR2101MB1109:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(80524489315369)(158342451672863)(189930954265078)(219752817060721)(31960201722614);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231311)(944501410)(52105095)(2018427008)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1109; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1109; 
x-forefront-prvs: 07459438AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39860400002)(136003)(199004)(189003)(99286004)(2906002)(6506007)(5660300001)(8990500004)(22452003)(8936002)(26005)(25786009)(105586002)(476003)(316002)(106356001)(446003)(7696005)(86612001)(11346002)(966005)(55016002)(93886005)(6246003)(68736007)(66066001)(19627235002)(39060400002)(6436002)(10090500001)(4326008)(486006)(478600001)(14454004)(575784001)(10290500003)(7736002)(86362001)(8676002)(236005)(2900100001)(256004)(9686003)(81156014)(81166006)(33656002)(6116002)(3846002)(54896002)(74316002)(229853002)(76176011)(53546011)(110136005)(186003)(97736004)(606006)(6306002)(53936002)(5250100002)(102836004)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1109; H:DM5PR2101MB0901.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: ielvzq3QXrwv6DG6tf8+6Lrac74RgUtRwjVsSpMZ6n96NbKk/GsMzyxqZAItqwF2C8Cxck89PPQvm0NtdrlaRcWb9ToMeHYf+nUMGVILI4pYLnjiHT1trirS6QiOQAh27nEbQIjZmg/Ifi6SWlujs3ErjmW9tqnhwHljVvO4J9xnbKjYwk007886EAUXH9Gyf9D1fwC/HnF5pCAUNQkfpXoPqMqofmViobO8RcfYATWdRfQ/XigSyExSAhgrt9RsP1R/j228OfsyAmbXtg7x6e69uIe7hPFuz5gjtZ8iRO/X9CEFK2QLlWb4yIXXabLe+IvOrDCcrCEWYucjIpPTk+5ls3zdQPY8J/caupdM2tQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB09015C909CB3527E73E355A8B32B0DM5PR2101MB0901_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e22c1d2-a405-4681-9c18-08d5f2b17086
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 04:37:05.2365 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1109
Archived-At: 
X-BeenThere: quic@ietf.org
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 04:37:11 -0000

--_000_DM5PR2101MB09015C909CB3527E73E355A8B32B0DM5PR2101MB0901_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

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 tha=
t matching them together makes things easier, then I=92d 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  on behalf of Tommy Pauly 
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 p=
oint 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 th=
e packet types and protection. The logic for handling a space can be treate=
d more uniformly in that way, although it does involve potentially more mem=
ory to store the state.

Thanks,
Tommy

> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov  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=3Dhttps%3A%2F%2Fgit=
hub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&=
;data=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b0068=
4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&sdata=
=3DfstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&reserved=3D0
>


--_000_DM5PR2101MB09015C909CB3527E73E355A8B32B0DM5PR2101MB0901_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
















Since there are four encryption levels, the fact t=
hat 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=92d think there should be four packet
 spaces. I think having all this duplication and separation just adds unnec=
essary complexity.


 


Sent from my Windows 10 device


[HxS - 15254 - 16.0.10325.20083]


 






From: tpauly@apple.com &l=
t;tpauly@apple.com> on behalf of Tommy Pauly <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 s=
plit 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 c=
orrespond tightly with the packet
 types and protection. The logic for handling a space can be treated more u=
niformly in that way, although it does involve potentially more memory to s=
tore the state.



Thanks,

Tommy



> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov <dtikhonov@litespeedte=
ch.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.<=
br>
>> Others have said that a single space would complicate their

>> implementation considerably more.

> 

> EKR is one of the "others" [1] -- are there other implemente=
rs who

> prefer the triple packet space?

> 

>  - Dmitri.

> 

> 1. 
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.c=
om%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&amp;=
data=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684=
%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&amp;sd=
ata=3DfstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&amp;reserved=3D0

> 









--_000_DM5PR2101MB09015C909CB3527E73E355A8B32B0DM5PR2101MB0901_--


From nobody Wed Jul 25 22:14:56 2018
Return-Path: 
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 ; 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 ; 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 ; 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 
To: Nick Banks , Tommy Pauly , Dmitri Tikhonov , "quic@ietf.org" 
CC: Martin Thomson 
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: 
References:   <20180726030135.GA19322@ubuntu-dmitri>,  
In-Reply-To: 
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: 
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: 
X-BeenThere: quic@ietf.org
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 05:14:56 -0000

--_000_MWHPR21MB0191F6DCED6296FCBC8E72ABB62B0MWHPR21MB0191namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree that multiple PN spaces are confusing and seem unnecessary. Loss re=
covery would be much simplified by having a single PN space. Its also easie=
r to reason about the state of loss recovery and for debugging and diagnost=
ics. 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 compli=
cations for implementation. Please note that you can trivially change the s=
ender to have a single PN space by just using consecutive PN for the 3 spac=
es! And the receiver ACK tracking logic would be simplified as well.

From: QUIC  On Behalf Of Nick Banks
Sent: Wednesday, July 25, 2018 9:37 PM
To: Tommy Pauly ; Dmitri Tikhonov ; quic@ietf.org
Cc: Martin Thomson 
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 th=
at matching them together makes things easier, then I'd think there should =
be four packet spaces. I think having all this duplication and separation j=
ust adds unnecessary complexity.



Sent from my Windows 10 device

[HxS - 15254 - 16.0.10325.20083]



________________________________
From: tpauly@apple.com > on behalf of Tommy Pauly >
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 p=
oint 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 th=
e packet types and protection. The logic for handling a space can be treate=
d more uniformly in that way, although it does involve potentially more mem=
ory to store the state.

Thanks,
Tommy

> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov > 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=3Dhttps%3A%2F%2Fgit=
hub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&=
;data=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b0068=
4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&sdata=
=3DfstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&reserved=3D0
>

--_000_MWHPR21MB0191F6DCED6296FCBC8E72ABB62B0MWHPR21MB0191namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I agree that multiple PN spaces are confusing and se=
em unnecessary. Loss recovery would be much simplified by having a single P=
N 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 be=
fore 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 co=
nsecutive PN for the 3 spaces! And the receiver ACK tracking logic would be=
 simplified as well.



 






From: QUIC <quic-bounces@ietf.org> O=
n Behalf Of 
Nick Banks

Sent: Wednesday, July 25, 2018 9:37 PM

To: Tommy Pauly <tpauly@apple.com>; Dmitri Tikhonov <dtikho=
nov@litespeedtech.com>; quic@ietf.org

Cc: Martin Thomson <martin.thomson@gmail.com>

Subject: RE: Go Back to Single Packet Number Space






 





As another implemente=
r, I also prefer having the split packet spaces. The point isn't necessaril=
y that it's good to have the triple spaces, but rather that it's nice to ha=
ve the packet number spaces correspond
 tightly with the packet types and protection. The logic for handling a spa=
ce can be treated more uniformly in that way, although it does involve pote=
ntially more memory to store the state.



Thanks,

Tommy



> On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov <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.<=
br>
>> Others have said that a single space would complicate their

>> implementation considerably more.

> 

> EKR is one of the "others" [1] -- are there other implemente=
rs who

> prefer the triple packet space?

> 

>  - Dmitri.

> 

> 1. 
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.c=
om%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&amp;=
data=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684=
%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&amp;sd=
ata=3DfstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&amp;reserved=3D0

> 








--_000_MWHPR21MB0191F6DCED6296FCBC8E72ABB62B0MWHPR21MB0191namp_--


From nobody Wed Jul 25 22:38:19 2018
Return-Path: 
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 AEE63130DD2 for ; Wed, 25 Jul 2018 22:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EsAh7ICFDCpp for ; Wed, 25 Jul 2018 22:38:14 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A18130DC2 for ; Wed, 25 Jul 2018 22:38:14 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fiYyV-000BSA-Hn for quic@ietf.org; Thu, 26 Jul 2018 07:38:12 +0200
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fiYyP-0007zj-E8 for quic@ietf.org; Thu, 26 Jul 2018 01:38:05 -0400
Received: (qmail 11676 invoked from network); 26 Jul 2018 05:37:58 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.39.156]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jul 2018 05:37:58 -0000
To: quic@ietf.org
References:  <99CA16C1-EC22-4DF5-B508-1E3EDCFEF8AC@apple.com>
From: Christian Huitema 
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <9b611378-8aa1-2d2c-a06d-24eccd3a6dd8@huitema.net>
Date: Wed, 25 Jul 2018 22:37:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <99CA16C1-EC22-4DF5-B508-1E3EDCFEF8AC@apple.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: PNE Test Vector
X-Originating-IP: 168.144.250.231
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.47)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5hIYPF4DIpudR54U8A6wmgZ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViUaqCbx5eZGjA8QMy4iuV4c7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB4lampmfDNuiABFovtjnMdR/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpX6N+2DyDXes8vYD17nJ00FIh8e57XaprhzZuSNqthqM3/LeqWQyg6N Iyz2bUxqm/Nz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqz6Jnv65JqzoprPQQCAlAFYE7tCqypI5WX0qWh4YQLA8LIDSPvB01Ekd aSQ4JjN6br8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLUKQCrMv/Srp/VLqDjjh0L1QKHY 6H+wSCoVvwvquzDDiPkKIKnisj+1ZHYjRAh7nr2Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
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 05:38:18 -0000

On 7/18/2018 12:42 PM, Rui Paulo wrote:
> My idea was to use the key/CID in PR #1573 to generate test vectors for=
 the PNE so that there=E2=80=99s a logical progression in the appendixes.=


The test vectors provided by EKR are a super-set of the test vectors in
the Wiki. I think we will be better off just using them.

>> On Jul 18, 2018, at 07:11, Eric Rescorla  wrote:
>>
>> As discussed in the meeting, here is a test vector for PNE. It's an In=
itial packet generated by Kazuho but processed by Minq, with the output b=
eing an edited and annotated version of Minq's logging. Happy to help wit=
h more logging if that helps.
>>
>>
>> INPUT PACKET
>> ffff00000d5006b858ec6f80452b0044efa5d8d307c2973fa0d63fd9b03a4e163b990d=
d778894a9edc8eacfbe4aa6fbf4a22ec7f906b5e8b8ae12e5fcc7924dfeee813842bb2149=
b805e55895084e8393200bb3fc618af7d08281485d914ce42303f5d772b200508a0c00253=
e332e36a84f657321ac4c8e2cc8a117e95871f12b1f36be8c4b76fa433dc4d3142e6547f4=
598bf4b192130aea6fc20da5158b2162b5a899957da05ded5c70907298fd885847f22a1ec=
b0a814fe0170e23cad20af64f05cc13c74e91824101afdcf5f1532fc2fde936a3a159f762=
83a26c738f778c76e6ca41fa7f134401d39027fd81de17a8021a9c0aaa9b4478fe5c06479=
41618f3bee410caf94c248d2a64b5e45845cd77de13a5ed94034d2bc5f457887351993c1e=
cfa34fd0c658fea3f8086d26808eef976262ecf0ad646b627945511dde83e26609cd5cfd7=
ed9f6207d76618b44c48bf623bf420dc7c127e5d5f529f083b71a17b17da329bfc38a74bf=
8cfcf315c7c070b71ebfae3ab351341a767adfdd9e57c738f5de9da53711e886d1472310b=
917a1c9798e3e9b13c7c74beb8d1b82345bea1349415679a9c64b0433b68c871ae08092a1=
f6106bc06337cd343866ee8185c03fcf3bb0666453f847905547199414c1e57535747be61=
cdf6778378f121d68df0181ee9e8d9932c1c593c0f8c0a1af0f5262b86205002dced9ecda=
ee2d0aa07dd4c14f98571e4bea72f8474f63697043e936ebb2bf9716ed0efbdc13005a75c=
ee3a49babc61b9677764510eb19828df4e10fb38b79a1efbf04cc2d571949d5403f797361=
743dcc5e3bf3b4396f7ae1a3affbc9f72e540d920363970307e0725fa838d611803251a4a=
08ccca1983d5b29a583758be63343e88f5591d885b8af695f33adbdd0d941d260287e32ef=
5a98fd55ac137211021fdc23b5d7a5469f578bf7aff6529117996f9ebab5e6dc7b047b356=
332fea82fdd620eb86f3c1d3855c8b8075da59a7662f4a11b977d996b8b3c7657ad4a82a2=
0a7f76ce376c0320086ed029dd615399307983113cc0aa973ecba691e7e4cdc80aefa7e8c=
8347baba050eaca7dc35a21aa854e531dc7758d7d10b8c8e42c1be3bbf266d055ac25c372=
79ebefa28bbe89a34ad1ab3d23d7a66d1c216a57650e6ec9fc8ba7adfb38e57f20c467166=
c8fe7944e67f82138160002004812c78ba4b5f0da917da4cc14cf8fc10dba3f533facb11e=
f06d8b8f178ea9c5e8acbbca7b7f0e1f6b7a70ec2d5108cc41178056295793bed357accbb=
03c0582dc69bc77a34030f38cce256c5a9cec6e862146e3f0463f10dd5833257d0a035916=
6a7e2027d98eaf26cf0d5a4a05f6ef8b742f5d314a31deeeabe4ebc3106547e79c6cb9331=
05d907b4c8c60443e97a154694bab5edfc781a438675b9de6ed03c77f51458eab61ca2e80=
ac02cc8c037d8fb3cf129d7107f618d66032cc02238a211f78bfa44e7c1bbcfcc627771c1=
88d1b3713ce5e75cd2325a0a2ba08268cad13b27d97696ef678b592d0ac80ad1bacb4a1ba=
75bea8c477f39fc32c2aa20f352bb0da1c49b7d3927bcd9dfaf229237081d5fa08924fefd=
923ff0ac6baad6864b7c10dc73379a5ebd9e4678a0c26517656e8e51fca2a51a33fb2cdd5=
d76d12674c240ba9a4893c1af69b8f2c4adf37c4a47551eb2006a732f6b3b2f338c078ede=
33946dfe4a55bf644d3b98848693ada1fcb6fc16cac339ee65c24dc64b0ae92005354af00=
ade71e6c5e2efd85c46131d948ff14096b0f06a41d83c8522f30beb4eaaf4a6f908fe2a6e=
e754c896
>>
>>
>> GENERATE THE KEYS
>> Cleartext keys: cid=3D06b858ec6f80452b initial_salt=3D9c108f98520a5c5c=
32968e950e8a2c5fe06d6c38

@EKR: could you also provide the value of the "initial_secret", as
defined in section 5.1.1 of the QUIC TLS draft? It is an interesting
intermediate value.


>>
>> initial_secret (server in) =3D 7e0aba2c4b9742d0d130bc7318622ad3b44aca1=
f09abb19b3f394cd7e20f4be0
>> key=3D26080e60d288db7df816a1cb0bc6c7f4 iv=3Db9fdc5b448af3e023422443b p=
n=3D00babbe1be0f0c6618188b4fcca57a96
>>
>> Cleartext keys: cid=3D06b858ec6f80452b initial_salt=3D9c108f98520a5c5c=
32968e950e8a2c5fe06d6c38
>> initial_secret (client in) =3D 82a73572e7cb89523b68c39eaa8325404f86498=
c8e2437dfdce10f9c34281a3d
>> key=3Da79943566c41342f2bc3de6b7c1539df iv=3D84eb954ffe161c3875919f5f p=
n=3D5c0f6472a15658047a3cc1f15478dcf4
>>
>> PNE DECRYPTION
>> PNE sample_offset=3D21 sample=3Dc2973fa0d63fd9b03a4e163b990dd778
>> Decoded PN block (unknown length): c0000000
>> Packet number: 0 length=3D4
>>

-- Christian Huitema


From nobody Wed Jul 25 23:21:51 2018
Return-Path: 
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 EE89A130DF2 for ; Wed, 25 Jul 2018 23:21:49 -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 tliiLvI_pvc3 for ; Wed, 25 Jul 2018 23:21:48 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 EE9F5130DC2 for ; Wed, 25 Jul 2018 23:21:47 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id 72-v6so1266672itw.3 for ; Wed, 25 Jul 2018 23:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:date:message-id:subject:to; bh=a5T/VlWp8XpoCviFG9y55uKCaXfH79+1hZDHFVAaoRY=; b=Nym+M3HSB1tDUPMQRLK7pb4P4HFSbPQRazX4vfJSPE3zD05yOasmV2ipoCb9FJYxBl IkDz2RSZoOKxvDMWrMLUpnGccOgVVM1DQD3+OJpB8bCBcu3rVz51nDNv6KuLzLRrrKAz myZjm6crKrRE3ih5qhrPGS5cz3O5kfvEju3vPZCNnJ96ZmyAJNOX+4H+S7MiwuUV3jxi ms4g9+2tkuK4FcFKBvXijQDpQflZfGtDpPd13ELM/2YeOaojqd9+kqxY8YdlL2lbngVA wdKUiNc2nXBuwkVBNeFGsZVNKBwsIyigowSF2u0+iL8j8r1BSy20MnCpbLOonHuyH1MF tDlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=a5T/VlWp8XpoCviFG9y55uKCaXfH79+1hZDHFVAaoRY=; b=UXMTOihFIvaxhWw1FCiQeRVjKi6NWrSdgfe+KHXTxTtK5/FUcsrDBmk+fpT+if9ndh biXFxHfxbOA9XOfZ6Ygn0nn23DTKBS1md1kLhdZUIC/R8QQ/XLOSgFFvAvCjTu515160 KtxGGH0EFsyqH1ndzKPwQcKAx32Gyi8VFFidDPFOt+tYRJLmJ9Yae2iYL3Nqr14JAX4W TJKOsipdQgB0KvE52gvLinkpT6R9gPlopxIip0XIu3GiPkiClI3+TW4FOrzKTR5PE/GX kffKF+hcl8z65FdU6/2/VmtJ7pV/KjFNxsgQrYPDTQvG2zq2/UuqSCE4CMJoPXOKIVq5 4Pcg==
X-Gm-Message-State: AOUpUlEFpjUfkf4QI0CKI2k52IuNnpsbQiAaaWimOVq49TK92/wM7+4F qjhvLQmqZsgGFae+DyZnK+8Z+CL/A4SGlH9D8sWm0w==
X-Google-Smtp-Source: AAOMgpfhKA315M9vP8ZbLjo+qJYIWmdC9hqyUm9QIcO1tcJ5SScudarN7SGutlCXg+vdjFzcoPJSo2nbWy1q5vQ3lWY=
X-Received: by 2002:a24:4ecb:: with SMTP id r194-v6mr829233ita.39.1532586107042;  Wed, 25 Jul 2018 23:21:47 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Jul 2018 23:21:46 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 25 Jul 2018 23:21:46 -0700
Message-ID: 
Subject: Packet Number Encryption outside of AEAD
To: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000007f82420571e1020e"
Archived-At: 
X-BeenThere: quic@ietf.org
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 06:21:50 -0000

--0000000000007f82420571e1020e
Content-Type: text/plain; charset="UTF-8"

I created the following issue a while ago but go no response, so perhaps it
should have been discussed on this list:

https://github.com/quicwg/base-drafts/issues/1578

The issues covers the point, but in summary:

If the packet format is kept as it is today, but the packet number is not
included in the authenticated data when computing the AEAD tag, then the
decoder need not modify the received packet buffer when decoding the packet
number. This can lead to more efficient hardware implementations and make
multi-processor buffer sharing more effective.

Mikkel

--0000000000007f82420571e1020e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I created the follow=
ing issue a while ago but go no response, so perhaps it should have been di=
scussed on this list:


The issues covers the point, but in summary:

If the packet format is kept=
 as it is today, but the packet number is not included in the authenticated=
 data when computing the AEAD tag, then the decoder need not modify the rec=
eived packet buffer when decoding the packet number. This can lead to more =
efficient hardware implementations and make multi-processor buffer sharing =
more effective.

Mikkel


--0000000000007f82420571e1020e--


From nobody Wed Jul 25 23:32:04 2018
Return-Path: 
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 94B19130DFC for ; Wed, 25 Jul 2018 23:32:01 -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 C7Y3ceG7YBan for ; Wed, 25 Jul 2018 23:31:59 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 54D26130DDA for ; Wed, 25 Jul 2018 23:31:59 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id l14-v6so477611iob.7 for ; Wed, 25 Jul 2018 23:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:date:message-id:subject:to; bh=Uz8Rv6iAlvQ+tZIOv6mzmCuHhCF62hWj9cGhwF8gpG4=; b=ZMo/Wu5mesyYfpUAf/KRBO26cthykFPLsdqd3gdhiAWBHxVFW7I5DR9c8MjeGNloxV hKgoiJbhoJ9kvx9pB1hl09JZ/dpV/uvsZyVoUSwmO7kSvuE9W4c+WM8vj/PIrvNA6c1L U2+V4clAGXc5JuLE9WRW1LWI9Yh+uf4WqslBfalBfxRwi2oubIlAcFKnGEEJ6IWFK4Yf a+tyOcY2uJG8dU2wEqBxazIl4ABLG8AXpJnys8kcsGTYYqX522MA8K2sp71cMSRy+q9O 9uFuJQFWOxUXTPQEZYOC4ZWuwU71jfyqDxgyt0n7ZUKFVMvINMm+UjVp5Ar/9bQAsVX3 IAzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=Uz8Rv6iAlvQ+tZIOv6mzmCuHhCF62hWj9cGhwF8gpG4=; b=MEc/KLKB8bwHJFkyF5hRq8umDO0TiXht5keiI8V9dAKXmoct4nuc42GyVhiC3O6ore 63ne957tl4uF7PLWaZu/V1vpepXZznH1k57fPLddYo5firTV0BLQgsu3zouJYrts/jAd IoUE0PVk1UOtUyAq9oVj0reJ9/FJqtGfsXwt2p5FnAIA2AUUOkdS0+sviczpnzufCjvQ 61FpA0JUrlzpC2sQ06527TCmg5UYTX4RhRLMkNs4smmeEl52L9zMzMqxictJoJq5DhJv FkpfnYlbiFX4ENdbisDTWgO9GFGjvFXrHKA88rHuaF/1Fvx/CHOIlETEy+1KcxPjdYfe Xnyg==
X-Gm-Message-State: AOUpUlGWljTo6G218FKtRgNggtBXiAl1bELUBJTNvHFRtg3+gHZMNo6x Uu14eUCUrv1i/5jsPX1vlSkx27Nh/VtOAtBqP0lBdQ==
X-Google-Smtp-Source: AAOMgpezLVMEnqM2SvGk4ZYIg6t22lp7j9Y1z/JfuYwv8xPM/PZt+yPBoVWlaStxGHorSGGN2G6ljV2hzuhw3PWaxrE=
X-Received: by 2002:a6b:b685:: with SMTP id g127-v6mr472491iof.209.1532586718515;  Wed, 25 Jul 2018 23:31:58 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 25 Jul 2018 23:31:58 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 25 Jul 2018 23:31:58 -0700
Message-ID: 
Subject: Hidden connection spawning
To: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000f1e8740571e126da"
Archived-At: 
X-BeenThere: quic@ietf.org
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 06:32:02 -0000

--000000000000f1e8740571e126da
Content-Type: text/plain; charset="UTF-8"

I came to think about a use case where you want to spawn a new connection
from an existing connection because the new connection runs a different
protocol. For example a http connection where you  want to run a separate
live conference call, or to control tunnels from http control connection.

You have roughly three options:

1. extend the current protocol with the new feature set in extension frames
or similar
2. develop or use a purposes specific QUIC protol using 0-RTT for spawning
the connection
3. negotiate the new connection handshake within the current handshake.

The first solution is not complex, limited, and not modular.
The second solution can be used to get information about the connection,
and for example block connections that appear to be doing that.
The third solution allows for an invisible connection spawn, but requires
addition handshake logic which is already complex as it is.

I suggesting solution 3 as possible option, although I am not convinced
that this is worthwhile, at least in V1.


This was in part inspired by recent discussion on tunneling, and in part by
the following issue where partial reliability is being discussed and
possibly shoe-horned into an extension. I am not following that issue
closely though - it is just an example.
https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495


Mikkel

--000000000000f1e8740571e126da
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I came to think abou=
t a use case where you want to spawn a new connection from an existing conn=
ection because the new connection runs a different protocol. For example a =
http connection where you =C2=A0want to run a separate live conference call=
, or to control tunnels from http control connection.

You have roughly three options:

1. extend the current protocol =
with the new feature set in extension frames or similar
2. develop or use a purposes spe=
cific QUIC protol using 0-RTT for spawning the connection
3. negotiate the new connectio=
n handshake within the current handshake.

The first solution is not complex, limited, and not =
modular.
The =
second solution can be used to get information about the connection, and fo=
r example block connections that appear to be doing that.
The third solution allows for =
an invisible connection spawn, but requires addition handshake logic which =
is already complex as it is.

I suggesting solution 3 as possible option, although I am not convi=
nced that this is worthwhile, at least in V1.


This was in part inspired by recent discussion on tunnelin=
g, and in part by the following issue where partial reliability is being di=
scussed and possibly shoe-horned into an extension. I am not following that=
 issue closely though - it is just an example.


Mikkel


--000000000000f1e8740571e126da--


From nobody Wed Jul 25 23:42:34 2018
Return-Path: 
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 B6406130E13 for ; Wed, 25 Jul 2018 23:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=netapp.onmicrosoft.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 oYDC5pT1lePO for ; Wed, 25 Jul 2018 23:42:30 -0700 (PDT)
Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13ECC130DF2 for ; Wed, 25 Jul 2018 23:42:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.51,404,1526367600"; d="scan'208";a="289518437"
Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx141-out.netapp.com with ESMTP; 25 Jul 2018 23:42:29 -0700
Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 25 Jul 2018 23:42:29 -0700
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 25 Jul 2018 23:42:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qzb5/0i/jFVVILtDDQVtsLfujbL3l4jW8o3yIbs98s8=; b=CuFdrBSt8zS/P6BQjxpDUP1eHWwNmTIiW4QHKy1WuLbPsBaS5Y7CNV4Z0cCNEeeNfFBBwCNL10msMcFThbYEdy7EABr5ZPF1nrerB+guBptrli3alJrvR4sOb79P4NUexGJhsYwdxZ5yK0Ub+/tL0PHCGpR1yXXts415w/trqn0=
Received: from MWHPR06MB2830.namprd06.prod.outlook.com (10.175.138.7) by MWHPR06MB3503.namprd06.prod.outlook.com (10.175.136.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.16; Thu, 26 Jul 2018 06:42:27 +0000
Received: from MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::191f:29ab:29f4:65a3]) by MWHPR06MB2830.namprd06.prod.outlook.com ([fe80::191f:29ab:29f4:65a3%6]) with mapi id 15.20.0973.022; Thu, 26 Jul 2018 06:42:27 +0000
From: "Eggert, Lars" 
To: Dmitri Tikhonov 
CC: Martin Thomson , Nick Banks , QUIC WG 
Subject: Re: Go Back to Single Packet Number Space
Thread-Topic: Go Back to Single Packet Number Space
Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0wANbUcAAALJdwAAB7acXA==
Date: Thu, 26 Jul 2018 06:42:27 +0000
Message-ID: <4C634335-AF46-402B-B155-5BF1B347BB07@netapp.com>
References:  , <20180726030135.GA19322@ubuntu-dmitri>
In-Reply-To: <20180726030135.GA19322@ubuntu-dmitri>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; 
x-originating-ip: [109.41.194.40]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR06MB3503; 6:mIDGno+g8+BbPulrQ3xbPZdwl5Lcot0G4P9uQABAxVbA9uzFkJdyXHTcoEwZGZIcXDTkDKiP1owbhytz7jndPSYaxqPdwpUHy/U/ly0qEkf399aJaSZK7hmVI4oxZeOTPX09hYV+7oiW5Tz5L9WTeuSXp1cLGrg+o4bHUXZFeBeuVIHRhJRWdXDfTKcq10FPhXmDvpLXZvN2UY0+pN+0tyhHcuzp2MVib5usVJ7Wc+kM9ousvxlgNRfZGY2tGA0PWJMkn6+k+x0cpFPctCYb/DxM+zShsyKNowvQoG/mtj8vrgYf8v8cOHq8LkqI5W14pead68IDrhFRJVV0baPdLv3M7LhEZs0mqzgd8R2AAA4uAvmjJ07dJX4fEhnMOnBkcfKsrEodRY+NJ6MTtQkqg8cnCox+jfb4U9fzoXLtLdVdz8SWXRpxvwIw13LKrJJ9mCZXgfBKZyjOULfOPEMs+g==; 5:L+LOQbjzE3f2ym6SNYmRK4w203h0/yS7jrBnx+1okqIpi2kaV27mnAU4UW8p06XTFCgz4lhllUdFEeocSVOsTRjKMOWn0HAIr/UjWMOe13+nm0AjwkDenSNltoCTABO8gf/FDmNQMb5JbzAIqZyWwBlrx0BNkdmStDu3WwOGv9g=; 7:mihSMtRDoJY8tvrbXxlinyHOGkdxcxGzAV57i5VjcacXNfcBwmNZf7DlBPFeugIFqoBKihuTSQw6tZAfAauhpXVkggPOtYJ13IMLRhJLbT7Xsde+l34ep84ZNI9ClPEwLUAcP5X27KAq1IFrl1Cakb03xC233DHUb7Ck9WAY4+WOMpGHtn8KQze+htKuMG/UW3nRvIFDiaVDGRYiNlUcLQeqUczxo1nT7TqvVtANU3Iw6Ks6U1sbfH9r4Muq1AmS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 3128e369-cfe2-4518-7e9c-08d5f2c2f417
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7193020); SRVR:MWHPR06MB3503; 
x-ms-traffictypediagnostic: MWHPR06MB3503:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR06MB3503; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB3503; 
x-forefront-prvs: 07459438AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(396003)(136003)(189003)(199004)(2900100001)(54906003)(486006)(2616005)(476003)(76176011)(316002)(3846002)(6116002)(26005)(446003)(186003)(99286004)(97736004)(53936002)(105586002)(106356001)(11346002)(36756003)(102836004)(5250100002)(8936002)(83716003)(14454004)(86362001)(68736007)(966005)(6306002)(6436002)(7736002)(6916009)(478600001)(6486002)(305945005)(25786009)(82746002)(229853002)(2906002)(256004)(53546011)(6246003)(4326008)(33656002)(66066001)(8676002)(6506007)(39060400002)(5660300001)(6512007)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB3503; H:MWHPR06MB2830.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pCt3TWrSbEYmWmrS3zZaFdOFlcD3Ui6nqBF4xLXLoZ0lHbsHkrcDtQsjZsEivtNwoBeB+CABQ9uH8OGJkZE4H+S1zF3KyGfjXxWWopZ7U5YX04Ykqi+Ps/d0jGdxZN53E15kgl6wnNVINmQdxFgTWfS2PbvzeNzlC+vIBjrauc9aTfriqhSGgJifbop+3VZPlcZbJzjHp/0+Q0ldhh4IHMCMsUKc/f6S09DqfPez1LJmkoh+cxw4Dtt8O3BjG9B7mpxlF20WFj0lHSVbfZwHZkR/BuKqmtUaBx6bO/CxGi+RWJQWJBEkz18uaunYysqXx9OWjA1L2O+629Y1IzC59gNprTqYIKHmZc5lFtarU3c=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3128e369-cfe2-4518-7e9c-08d5f2c2f417
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 06:42:27.5082 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB3503
X-OriginatorOrg: netapp.com
Archived-At: 
X-BeenThere: quic@ietf.org
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 06:42:33 -0000

For my implementation, I prefer the single space. My data structures are ve=
ry similar to what Nick described.

--=20
Sent from a mobile device; please excuse typos.
+49 151 120 55791

> On Jul 26, 2018, at 05:02, Dmitri Tikhonov  =
wrote:
>=20
>> 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.
>=20
> EKR is one of the "others" [1] -- are there other implementers who
> prefer the triple packet space?
>=20
>  - Dmitri.
>=20
> 1. https://github.com/quicwg/base-drafts/issues/1579#issuecomment-4057202=
17
>=20


From nobody Wed Jul 25 23:56:56 2018
Return-Path: 
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 ; 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 ; 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 ; Wed, 25 Jul 2018 23:56:51 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id l7-v6so531605ioj.1 for ; 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: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <4C634335-AF46-402B-B155-5BF1B347BB07@netapp.com>
References:   <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: 
Subject: Re: Go Back to Single Packet Number Space
To: Dmitri Tikhonov , "Eggert, Lars" 
Cc: Martin Thomson ,  Nick Banks , QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000e668970571e17f89"
Archived-At: 
X-BeenThere: quic@ietf.org
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 06:56:54 -0000

--000000000000e668970571e17f89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I am not currently working on handshake so I don=E2=80=99t have detailed in=
sights
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=E2=80=99=
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=C3=B8e J=C3=B8rgensen


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.

--000000000000e668970571e17f89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
I am not currently w=
orking on handshake so I don=E2=80=99t have detailed insights but I see the=
 following concerns:
As Nick writes:

  • Each metadata object has 2 bits for tracking encryption level use=
d to send the packet.
 

This is a problem it y=
ou create a highly optimised data structure for the general receive case. Y=
ou double or triple the state you need in bitmaps etc. - yes the counter ar=
gument is that you need more state for retransmission, but these indices us=
e critical cache buffers and retransmission is rare and can be on disk or m=
ain memory.

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

So a single numbe=
r space may be simpler for simpler implementation but more complex for an a=
dvanced implementation.

A counter argument:
<=
div>
The initial handshake requires more state with multiple =
spaces. This means that handshake must be done a =C2=A0specially allocated =
control block otherwise the main connections control block will be larger t=
han necessary. This could be a trade-off between indirection and minimum sp=
ace 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 me=
mory required during the connection can be a concern, but it isn=E2=80=99t =
likely a problem because: =C2=A0If you are a constrained device you only de=
al with one connction at a time and refuse concurrent handshakes. If you ar=
e a massive server, you can easily handle the overhead of 100K concurrent c=
onnections 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 ma=
in connection makes it much simpler to experiment with alternative handshak=
es, for example a simple pre-shared static key for exchanging traffic keys.=


Therefore, I prefer keeping the handshake logic s=
eparate from the main connection as much as possible.

<=
div>

 
Kind Regar=
ds,
Mikkel F=
ahn=C3=B8e J=C3=B8rgensen

 
O=
n 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.
<=
/html>

--000000000000e668970571e17f89--


From nobody Thu Jul 26 01:33:40 2018
Return-Path: 
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 D679D130F81 for ; Thu, 26 Jul 2018 01:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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: 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 oHmshXxrffB5 for ; Thu, 26 Jul 2018 01:33:36 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 13F7013104C for ; Thu, 26 Jul 2018 01:33:34 -0700 (PDT)
Received: by mail-lf1-x12f.google.com 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; d=gmail.com; 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; d=1e100.net; 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-BeenThere: quic@ietf.org
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 t=
opic, 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 relat=
ed to using multiple packet number spaces. A lot of the issues result in du=
plicated state (and associated memory) for all the packet number spaces. Bu=
t more importantly, the multiple packet number spaces bring in a lot more c=
omplexity of logic, compared to the previous single packet number space des=
ign. There is a lot more detail in the GitHub issue, and I=E2=80=99d ask th=
at 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 prov=
ides good (if not better, IMO) solutions to the problems that were fixed pr=
eviously with multiple packet number spaces. I believe having a single pack=
et 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=E2=80=99t want this issue to slip ou=
t into the next version.
>>
>>
>>
>> Thanks,
>>
>> - Nick
>



--=20
Kazuho Oku


From nobody Thu Jul 26 02:35:21 2018
Return-Path: 
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 603E41310A6 for ; Thu, 26 Jul 2018 02:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 54mjjdRK09Ne for ; Thu, 26 Jul 2018 02:35:17 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 AAB9C130E37 for ; Thu, 26 Jul 2018 02:35:17 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id k12-v6so1794637oiw.8 for ; Thu, 26 Jul 2018 02:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=igBkSrzOJraKyz6ldighabE212F4NvamXaysa5g32RY=; b=N0gumd2aDNwtoUKPigLrOOnCAWdCel0AYNcxDi+GDeSnjpOnMCkj12xLhfsME9Qf6a YmjXjwva1sPayEaoiXerFd+uQatdl2/Yq/CzXuwZDtpE+JBJXUIFZoCF4m2GlsOprSf+ tLXuyofONSroBrK9yVbogYN351B2qAeXJlUQToq67IiX2lgtJ1LQDsKKxWkOao+e626R hVdmFj7KZ/CIsqjjpTn8Noa7dW53sjan8QiuILRDdEzDmRe2DNC01jY8sfbyqVpjXG+5 6lhD8mNsGz12m3XniX+UqtktwnSaUE1LrIRMhRbZn/rgKU66+0xONh3txIyKlTF/MUDR mJog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=igBkSrzOJraKyz6ldighabE212F4NvamXaysa5g32RY=; b=exBYaZMuFhnCQTnLZBN2wj9Y5Ium42DIzlSkjYGXdPMIAAYh+ukSKztRfSuu7Z20Kp RbNj9CXhcBT+Q/idD20L+tR1JbE5bhNKgGWbsz6dTCeNtO0J5vjSi517p0xbz2PyBV1s ZNq8ngRBYd3WitANj15mzE5m36Zos8DnXDEUK2wQjXQ4pItuJF3uuDOggedHHAH8CrTR dK9PvghXPw0zj7K4azc2snRj5a9Qa1RgOcRLhlvwPr6EHop3H5CiGgJ3b6KBSbH3XMhm wQ0rM5umUX/g/mdKVO4MU6LeS5fkrFa56AJ0rS+2FYxfW76/LdHPiMcQYezr0DL9k1Rx XBJg==
X-Gm-Message-State: AOUpUlFJvWT4bvDFwWg1iK6m3UCh5mI3HrT10rEF4s2VvUrVSrt3cu4s sne3Yt5fn+mIYkWKTZzZENDtlyxnKqYA3+20EcE=
X-Google-Smtp-Source: AAOMgpexkCiHi/WunqxFrS04UD3yPYF55CBYG8vIHyQY3sJKPemZFLvMVJ94Y81xw9515zVpYqucVRC8yk/ZJvRp3h8=
X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr1246042oiq.110.1532597716877;  Thu, 26 Jul 2018 02:35:16 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Martin Thomson 
Date: Thu, 26 Jul 2018 19:35:05 +1000
Message-ID: 
Subject: Re: Hidden connection spawning
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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 09:35:20 -0000

Sounds like work for an extension to me.
On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen
 wrote:
>
> I came to think about a use case where you want to spawn a new connection=
 from an existing connection because the new connection runs a different pr=
otocol. For example a http connection where you  want to run a separate liv=
e conference call, or to control tunnels from http control connection.
>
> You have roughly three options:
>
> 1. extend the current protocol with the new feature set in extension fram=
es or similar
> 2. develop or use a purposes specific QUIC protol using 0-RTT for spawnin=
g the connection
> 3. negotiate the new connection handshake within the current handshake.
>
> The first solution is not complex, limited, and not modular.
> The second solution can be used to get information about the connection, =
and for example block connections that appear to be doing that.
> The third solution allows for an invisible connection spawn, but requires=
 addition handshake logic which is already complex as it is.
>
> I suggesting solution 3 as possible option, although I am not convinced t=
hat this is worthwhile, at least in V1.
>
>
> This was in part inspired by recent discussion on tunneling, and in part =
by the following issue where partial reliability is being discussed and pos=
sibly shoe-horned into an extension. I am not following that issue closely =
though - it is just an example.
> https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495
>
>
> Mikkel


From nobody Thu Jul 26 05:15:33 2018
Return-Path: 
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 D17F9130DD7 for ; Thu, 26 Jul 2018 05:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 FyTtlxqMj-B7 for ; Thu, 26 Jul 2018 05:15:30 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 50FA7130E5A for ; Thu, 26 Jul 2018 05:15:30 -0700 (PDT)
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5455C3A042 for ; Thu, 26 Jul 2018 08:15:28 -0400 (EDT)
Received: by mail-oi0-f41.google.com with SMTP id k81-v6so2523121oib.4 for ; Thu, 26 Jul 2018 05:15:28 -0700 (PDT)
X-Gm-Message-State: AOUpUlHShJfnzvVNgjK7QsLMaD9MwbWwj5r6L68pG7dtvB0ENt1vUyCm bf8IpEAKoljsGFoq6HbabgiYwfu8kZ/VpnFHkQo=
X-Google-Smtp-Source: AAOMgpdMDE0mIYTeudXL3PKaUN1eOjiq6+vTCMN9pqLzmq4Z5xeymmzEg8hyZe/syp9IpF1fo0t0YyWYrMAQ7m7wgy0=
X-Received: by 2002:aca:31c6:: with SMTP id x189-v6mr1779980oix.213.1532607327972;  Thu, 26 Jul 2018 05:15:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 05:15:27 -0700 (PDT)
In-Reply-To: 
References:   
From: Patrick McManus 
Date: Thu, 26 Jul 2018 08:15:27 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Go Back to Single Packet Number Space
To: Kazuho Oku 
Cc: Martin Thomson ,  Nick Banks , QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000005d320c0571e5f38f"
Archived-At: 
X-BeenThere: quic@ietf.org
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 12:15:32 -0000

--0000000000005d320c0571e5f38f
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 26, 2018 at 4:33 AM, Kazuho Oku  wrote:

> 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 sums up my feelings as well - I really like the explicitness of the
separate spaces.

--0000000000005d320c0571e5f38f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 26, 2018 at 4:33 AM, Kazuho Oku <kazuhooku@gmail.com=
> wrote:
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.&quo=
t;



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 sums up my feelings as well - I really lik=
e the explicitness of the separate spaces.


--0000000000005d320c0571e5f38f--


From nobody Thu Jul 26 07:05:09 2018
Return-Path: 
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 DC392130E70 for ; Thu, 26 Jul 2018 07:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 um3r3l3oav4T for ; Thu, 26 Jul 2018 07:04:59 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0123.outbound.protection.outlook.com [104.47.41.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16282131158 for ; Thu, 26 Jul 2018 07:04: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=bkra2vfAEITDOlNnmMCps/ab9jnkjisdJySdgh74iT4=; b=OUilGR+k7H2aecL4aJdAgXJ91hTL1DgogNLqznziVa2Vu9shPa08m6m3ICaS8MCq6una55pMm0bz5lJSttM+5WPhRat7wtqz7M7Uk3Jr+Cw3bDMvxRcsDaArAHqwzfbzdJAWyMEJ+Qo4Ge7bkb2FOPMuxG/bS57pA2MyZx1prsE=
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0917.namprd21.prod.outlook.com (52.132.132.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.2; Thu, 26 Jul 2018 14:04:50 +0000
Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::b1ef:f0bd:d9eb:2545%2]) with mapi id 15.20.1017.000; Thu, 26 Jul 2018 14:04:50 +0000
From: Nick Banks 
To: Patrick McManus , Kazuho Oku ,  QUIC WG 
CC: Martin Thomson 
Subject: RE: Go Back to Single Packet Number Space
Thread-Topic: Go Back to Single Packet Number Space
Thread-Index: AdQkTBwat6Uz522HTCmlcfdQS0RX0wANbUcAAA5hLwAAB8AWgAADcZzg
Date: Thu, 26 Jul 2018 14:04:50 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-07-26T14:04:48.6805047Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: [2001:4898:80e8:1:1d83:4be1:90a4:2f3c]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0917; 6:db612/Bt6xuUXIvSDTyQolz26fvNxMKP+KuqyCZ6kocwe7+h3cpFeFjKaBxkcbqh5doGA6aQqCVd2ATjkkGOOyYoEu4u1VbkT79YrnhuNEvdl3ena8JlWG47xroCu0/OUWV1vPcjpPkSoz5h0mlyAuTqEBpBorVz7ofkyZyez5D7Z+sgwAw2HqjWN4z9cC/TSxY3BjLH0IbabtMISFZtwFYAYPVIs12CFCRGM9LF00KNdv+khfBaNvooVmLjijaIbSSlhaWnjSShQVshz80mzueqMjvWydfwyvGiGvGDEQ2Iz5PCtxDWGcpTwWLVT2LRC2yTJd08TFbTXi019DCJQoKlNaP73J+L3C1zBcnMycJq0pS2qIkSAcuIpMgnajvyHvaoVMJurUSJXlGs7XCwyFCF5SH91Jymb5XOnKQ9C8Zir6Yj5sEikU1C4QxUIdb9qgEuaEz1ygVLXFrfdZcHMg==; 5:hYKE5R0dPFfg1lQ41enKZJMsAE+x3VUssjwgMmd1bYIo10E5W4UfpeeBeCLYrnu0Npwlnxm2l2R6avKmdNkx3POdAXMms3r5BSQ0JVIK4SCCCFw1jAH6BdZeRXPocgGDZWPX50lu2AJuO6h8rsh5ZNVHOWkwKRvbmdJyAQ7XsOE=; 7:uphZiNakbYKbwcbEAjKoE8AKq5vwMrXp/VeyXL9jY691cXa5PLhSZdvtOnZ/YLwRGl26K5CL6DQVeclEeaO3Elcn4RmsPBx72z3wy9gMcxVdwo5NpjSxcLf5ZyI5KnLMwu0BHMsF38vvqedzF+r7FrppgIWyi/vcm4ktnjWRj/bhlVdtpI5YoomQt5PwRj5PkM+vylaQH7kJPdIIk11aziBV7MnQF6+GmqaGPI1+zGgn7d+EaFdPZJRYN8HjYmTj
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 484a4d6c-3480-4e5a-5578-08d5f300c0e5
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:DM5PR2101MB0917; 
x-ms-traffictypediagnostic: DM5PR2101MB0917:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231311)(944501410)(52105095)(2018427008)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB0917; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0917; 
x-forefront-prvs: 07459438AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(346002)(366004)(396003)(39860400002)(189003)(199004)(6116002)(19609705001)(9686003)(236005)(54896002)(6306002)(55016002)(5660300001)(229853002)(102836004)(76176011)(46003)(6506007)(53546011)(105586002)(106356001)(110136005)(316002)(86612001)(2900100001)(81166006)(8936002)(8676002)(186003)(22452003)(53936002)(86362001)(790700001)(6436002)(97736004)(81156014)(10090500001)(8990500004)(476003)(33656002)(561944003)(5250100002)(2906002)(68736007)(256004)(14444005)(10290500003)(7736002)(99286004)(446003)(11346002)(486006)(93886005)(4326008)(14454004)(478600001)(7696005)(6246003)(39060400002)(25786009)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0917; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Dedj+d3SEpyq6PF6wHlWlAYTKrWTcvYAvhD1tasp9saPeN88f4oaq1SzDZ7T5Ty5IVWu7RhnhCU0Plpg5m6y61DcfTXwN2vGrNimi+3FrBMJu23c/Sh73S/sJ0xhjwW3FCA7Sl+gdk/JQXtr4lgSTDsnmT9roIXLpgWXXTUHulLx9LA4SDcAZfCA2iipPPhh8kr/WwJmwpFeSvvXcObYuO4H/ZUV8gM5PkHEPjhF0ZdAu99Jl3j3YDICB5ppd/9+HESVh+pZ5UYtUHV3nCvWNFiDYPvzfzrodQQQ+tJXoZtWMDbHIcL5WmWn84IfTUtkRcdmywc5at1fC5w4w5WmdeTExZ2ESwjJ4K9hcTD4OLc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0901581E982F410F31E42E2AB32B0DM5PR2101MB0901_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 484a4d6c-3480-4e5a-5578-08d5f300c0e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 14:04:50.2906 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0917
Archived-At: 
X-BeenThere: quic@ietf.org
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 14:05:08 -0000

--_000_DM5PR2101MB0901581E982F410F31E42E2AB32B0DM5PR2101MB0901_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Rmlyc3QsIEkgdGhpbmsgd2Ugc2hvdWxkIGxpbWl0IHRoZSBkaXNjdXNzaW9uIHRvIHdoYXQgYWN0
dWFsbHkgaXMgaW4gVjEuIFRoaW5ncyBsaWtlIHBvc3QgcXVhbnR1bSBjcnlwdG8gYW5kIHBvc3Np
YmxlIGZ1dHVyZSBUTFMgY2hhbmdlcyBhcmUgaW50ZXJlc3RpbmcgdG8gcmVhc29uIGFib3V0LCBi
dXQgc2hvdWxkIGhhdmUgbm8gaW1tZWRpYXRlIGJlYXJpbmcgb24gdGhlIGRlc2lnbiByaWdodCBu
b3cuIElmIHRoaW5ncyBjaGFuZ2UgaW4gdGhlIGZ1dHVyZSB0aGF0IG1pZ2h0IGNhdXNlIGFkZGl0
aW9uYWwgaXNzdWVzLCB3ZSBzaG91bGQgaGFuZGxlIHRoZW0gaW4gYSBmdXR1cmUgdmVyc2lvbi4N
Cg0KU2Vjb25kLCBvbiB0aGUgdG9waWMgb2Ygb25seSBhY2tub3dsZWRnaW5nIHBhY2tldHMgYXQg
YSBncmVhdGVyIHRoYW4gb3IgZXF1YWwgZW5jcnlwdGlvbiBsZXZlbCBiZWluZyBldmVuIGhhcmRl
ciBvciBsZXNzIGVmZmljaWVudCB0byBpbXBsZW1lbnQsIHdoaWxlIEkgd2hvbGUtaGVhcnRlZGx5
IGRpc2FncmVlLCBJIHdhcyB0aGlua2luZyBhYm91dCB0aGlzLCBhbmQgZmVlbCB3ZSBjb3VsZCBh
Y3R1YWxseSBnbyBvbmUgc3RlcCBmdXJ0aGVyLiBBbHJlYWR5IEkgaGF2ZSBwcm9wb3NlZCBkaXNh
bGxvd2luZyBBQ0tzIGluIEluaXRpYWwgcGFja2V0cyBhbmQgYWxsb3dpbmcgMC1SVFQgcGFja2V0
cyB0byBiZSBhY2tub3dsZWRnZWQgaW4gSGFuZHNoYWtlIHBhY2tldHMuIFdlIGNvdWxkIGluc3Rl
YWQganVzdCBzYXkgbm8gQUNLcyBpbiBJbml0aWFsIHBhY2tldHMsIGJ1dCBhbGwgb3RoZXIgcGFj
a2V0cyBjYW4gYWNrbm93bGVkZ2UgYW55IG90aGVyIHBhY2tldC4gTm8gZW5jcnlwdGlvbiBsZXZl
bCByZXF1aXJlbWVudHMgYXQgYWxsLiBUaGUgb2J2aW91cyBwb3NzaWJsZSBwb2ludCBvZiBjb250
ZW50aW9uIHdpdGggdGhpcywgaXMgdGhhdCBpdCB3b3VsZCBhbGxvdyBIYW5kc2hha2UgcGFja2V0
cyB0byBhY2tub3dsZWRnZSAxLVJUVCBwYWNrZXRzLiBXaGlsZSBpdCBpcyBhIOKAmGxvd2Vy4oCZ
IGVuY3J5cHRpb24gbGV2ZWwgKEkgZG9u4oCZdCByZWFsbHkga25vdyB3aGF0IHRoYXQgbWVhbnMp
IGJvdGggSGFuZHNoYWtlIGFuZCAxLVJUVCBrZXlzIGFyZSBrZXlzIG9ubHkgdGhlIGVuZHBvaW50
cyBrbm93LiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGluIHRlbXBvcmFyaWx5IChhcyBsb25nIGFz
IHlvdSBhY2NlcHQgSGFuZHNoYWtlIHBhY2tldHMpIGFsbG93aW5nIEhhbmRzaGFrZSBwYWNrZXRz
IHRvIGFja25vd2xlZGdlIDEtUlRUIHBhY2tldHMuIFdpdGggdGhpcyBkZXNpZ24sIGFuIGltcGxl
bWVudGF0aW9uIHRoYXQgbmVlZHMgdG8gYWNrbm93bGVkZ2Ugc29tZXRoaW5nIGNhbiB0aGVuIGRv
IHdoYXRldmVyIGl0IGxpa2VzLCBzbyBsb25nIGFzIGl0IGRvZXNu4oCZdCB1c2UgYW4gSW5pdGlh
bCBwYWNrZXRzLg0KDQpOZXh0LCBmb3Igbm90IGV4cGxpY2l0bHkgc2VuZGluZyBBQ0sgZnJhbWVz
IGluIEluaXRpYWwgcGFja2V0cywgSSBwZXJzb25hbGx5IGRvbuKAmXQgc2VlIHRoZSBleHBsaWNp
dCBldmVudCBvZiBUTFMgY2hhbmdpbmcgcmVhZCBlbmNyeXB0aW9uIGtleXMgZnJvbSBpbml0aWFs
IHRvIGhhbmRzaGFrZSBhcyBhbiBpbXBsaWNpdCBzaWduYWwuIFRvIG1lLCBpdCBzZWVtcyB2ZXJ5
IHJlYXNvbmFibGUgdG8gY2FsbCB0aGF0IG91dCBhcyB0aGUgZXhwbGljaXQgc2lnbmFsIHRvIHRy
ZWF0IHlvdXIgaW5pdGlhbCBwYWNrZXQocz8pIGFzIGFja25vd2xlZGdlZC4NCg0KLSBOaWNrDQoN
CkZyb206IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTZW50OiBUaHVy
c2RheSwgSnVseSAyNiwgMjAxOCA1OjE1IEFNDQpUbzogS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdt
YWlsLmNvbT4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsg
TmljayBCYW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9y
Zz4NClN1YmplY3Q6IFJlOiBHbyBCYWNrIHRvIFNpbmdsZSBQYWNrZXQgTnVtYmVyIFNwYWNlDQoN
Cg0KDQpPbiBUaHUsIEp1bCAyNiwgMjAxOCBhdCA0OjMzIEFNLCBLYXp1aG8gT2t1IDxrYXp1aG9v
a3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4gd3JvdGU6DQpJIHByZWZl
ciBoYXZpbmcgc3BsaXQgcGFja2V0IG51bWJlciBzcGFjZXMsIGJlY2F1c2UgaW4gYWRkaXRpb24g
dG8NCndoYXQgTWFydGluIHNheXMsIEkgZmVlbCB1bmVhc3kgYWJvdXQgYWxsb3dpbmcgYSByZWNl
aXZlciB0bw0KYWNrbm93bGVkZ2UgYSBwYWNrZXQgImluIGEgZ3JlYXRlciB0aGFuIG9yIGVxdWFs
IGVuY3J5cHRpb24gbGV2ZWwuIg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyB0aGUg
a2V5IG9mIHRoZSBwcm9wb3NhbC4gVXNlIG9mIGENCnVuaWZpZWQgcGFja2V0IG51bWJlciBzcGFj
ZSBtYWtlcyBzZW5zZSBvbmx5IHdoZW4gYW4gZW5kcG9pbnQgY2FuIHNlbmQNCmFuIGFja25vd2xl
ZGdlbWVudCBmb3IgYWxsIHBhY2tldHMgdGhhdCBpdCBoYXMgcmVjZWl2ZWQgaW4gb25lDQplbmNy
eXB0aW9uIGxldmVsLg0KDQpUaGlzIHN1bXMgdXAgbXkgZmVlbGluZ3MgYXMgd2VsbCAtIEkgcmVh
bGx5IGxpa2UgdGhlIGV4cGxpY2l0bmVzcyBvZiB0aGUgc2VwYXJhdGUgc3BhY2VzLg0K

--_000_DM5PR2101MB0901581E982F410F31E42E2AB32B0DM5PR2101MB0901_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls
ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv
c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4
dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X
b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw
MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo
YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv
Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu
Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0LCBJIHRoaW5rIHdlIHNob3VsZCBs
aW1pdCB0aGUgZGlzY3Vzc2lvbiB0byB3aGF0IGFjdHVhbGx5IGlzIGluIFYxLiBUaGluZ3MgbGlr
ZSBwb3N0IHF1YW50dW0gY3J5cHRvIGFuZCBwb3NzaWJsZSBmdXR1cmUgVExTIGNoYW5nZXMgYXJl
IGludGVyZXN0aW5nIHRvIHJlYXNvbiBhYm91dCwgYnV0IHNob3VsZCBoYXZlIG5vIGltbWVkaWF0
ZSBiZWFyaW5nIG9uIHRoZSBkZXNpZ24gcmlnaHQgbm93LiBJZiB0aGluZ3MNCiBjaGFuZ2UgaW4g
dGhlIGZ1dHVyZSB0aGF0IG1pZ2h0IGNhdXNlIGFkZGl0aW9uYWwgaXNzdWVzLCB3ZSBzaG91bGQg
aGFuZGxlIHRoZW0gaW4gYSBmdXR1cmUgdmVyc2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
U2Vjb25kLCBvbiB0aGUgdG9waWMgb2Ygb25seSBhY2tub3dsZWRnaW5nIHBhY2tldHMgYXQgYSBn
cmVhdGVyIHRoYW4gb3IgZXF1YWwgZW5jcnlwdGlvbiBsZXZlbCBiZWluZyBldmVuIGhhcmRlciBv
ciBsZXNzIGVmZmljaWVudCB0byBpbXBsZW1lbnQsIHdoaWxlIEkgd2hvbGUtaGVhcnRlZGx5IGRp
c2FncmVlLCBJIHdhcyB0aGlua2luZyBhYm91dCB0aGlzLCBhbmQgZmVlbCB3ZSBjb3VsZCBhY3R1
YWxseSBnbw0KIG9uZSBzdGVwIGZ1cnRoZXIuIEFscmVhZHkgSSBoYXZlIHByb3Bvc2VkIGRpc2Fs
bG93aW5nIEFDS3MgaW4gSW5pdGlhbCBwYWNrZXRzIGFuZCBhbGxvd2luZyAwLVJUVCBwYWNrZXRz
IHRvIGJlIGFja25vd2xlZGdlZCBpbiBIYW5kc2hha2UgcGFja2V0cy4gV2UgY291bGQgaW5zdGVh
ZCBqdXN0IHNheSBubyBBQ0tzIGluIEluaXRpYWwgcGFja2V0cywgYnV0IGFsbCBvdGhlciBwYWNr
ZXRzIGNhbiBhY2tub3dsZWRnZSBhbnkgb3RoZXIgcGFja2V0Lg0KIE5vIGVuY3J5cHRpb24gbGV2
ZWwgcmVxdWlyZW1lbnRzIGF0IGFsbC4gVGhlIG9idmlvdXMgcG9zc2libGUgcG9pbnQgb2YgY29u
dGVudGlvbiB3aXRoIHRoaXMsIGlzIHRoYXQgaXQgd291bGQgYWxsb3cgSGFuZHNoYWtlIHBhY2tl
dHMgdG8gYWNrbm93bGVkZ2UgMS1SVFQgcGFja2V0cy4gV2hpbGUgaXQgaXMgYSDigJhsb3dlcuKA
mSBlbmNyeXB0aW9uIGxldmVsIChJIGRvbuKAmXQgcmVhbGx5IGtub3cgd2hhdCB0aGF0IG1lYW5z
KSBib3RoIEhhbmRzaGFrZQ0KIGFuZCAxLVJUVCBrZXlzIGFyZSBrZXlzIG9ubHkgdGhlIGVuZHBv
aW50cyBrbm93LiBJIGRvbuKAmXQgc2VlIGFueSBoYXJtIGluIHRlbXBvcmFyaWx5IChhcyBsb25n
IGFzIHlvdSBhY2NlcHQgSGFuZHNoYWtlIHBhY2tldHMpIGFsbG93aW5nIEhhbmRzaGFrZSBwYWNr
ZXRzIHRvIGFja25vd2xlZGdlIDEtUlRUIHBhY2tldHMuIFdpdGggdGhpcyBkZXNpZ24sIGFuIGlt
cGxlbWVudGF0aW9uIHRoYXQgbmVlZHMgdG8gYWNrbm93bGVkZ2Ugc29tZXRoaW5nDQogY2FuIHRo
ZW4gZG8gd2hhdGV2ZXIgaXQgbGlrZXMsIHNvIGxvbmcgYXMgaXQgZG9lc27igJl0IHVzZSBhbiBJ
bml0aWFsIHBhY2tldHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5leHQsIGZvciBub3QgZXhw
bGljaXRseSBzZW5kaW5nIEFDSyBmcmFtZXMgaW4gSW5pdGlhbCBwYWNrZXRzLCBJIHBlcnNvbmFs
bHkgZG9u4oCZdCBzZWUgdGhlIGV4cGxpY2l0IGV2ZW50IG9mIFRMUyBjaGFuZ2luZyByZWFkIGVu
Y3J5cHRpb24ga2V5cyBmcm9tIGluaXRpYWwgdG8gaGFuZHNoYWtlIGFzIGFuIGltcGxpY2l0IHNp
Z25hbC4gVG8gbWUsIGl0IHNlZW1zIHZlcnkgcmVhc29uYWJsZSB0byBjYWxsIHRoYXQNCiBvdXQg
YXMgdGhlIGV4cGxpY2l0IHNpZ25hbCB0byB0cmVhdCB5b3VyIGluaXRpYWwgcGFja2V0KHM/KSBh
cyBhY2tub3dsZWRnZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gTmljazxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUGF0cmljayBNY01hbnVzICZsdDtwbWNtYW51c0Bt
b3ppbGxhLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI2LCAyMDE4
IDU6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5j
b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25A
Z21haWwuY29tJmd0OzsgTmljayBCYW5rcyAmbHQ7bmliYW5rc0BtaWNyb3NvZnQuY29tJmd0Ozsg
UVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEdv
IEJhY2sgdG8gU2luZ2xlIFBhY2tldCBOdW1iZXIgU3BhY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IFRodSwgSnVsIDI2LCAyMDE4IGF0IDQ6MzMgQU0sIEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1h
aWx0bzprYXp1aG9va3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWls
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBwcmVmZXIgaGF2aW5n
IHNwbGl0IHBhY2tldCBudW1iZXIgc3BhY2VzLCBiZWNhdXNlIGluIGFkZGl0aW9uIHRvPGJyPg0K
d2hhdCBNYXJ0aW4gc2F5cywgSSBmZWVsIHVuZWFzeSBhYm91dCBhbGxvd2luZyBhIHJlY2VpdmVy
IHRvPGJyPg0KYWNrbm93bGVkZ2UgYSBwYWNrZXQgJnF1b3Q7aW4gYSBncmVhdGVyIHRoYW4gb3Ig
ZXF1YWwgZW5jcnlwdGlvbiBsZXZlbC4mcXVvdDs8YnI+DQo8YnI+DQpNeSB1bmRlcnN0YW5kaW5n
IGlzIHRoYXQgdGhpcyB0aGUga2V5IG9mIHRoZSBwcm9wb3NhbC4gVXNlIG9mIGE8YnI+DQp1bmlm
aWVkIHBhY2tldCBudW1iZXIgc3BhY2UgbWFrZXMgc2Vuc2Ugb25seSB3aGVuIGFuIGVuZHBvaW50
IGNhbiBzZW5kPGJyPg0KYW4gYWNrbm93bGVkZ2VtZW50IGZvciBhbGwgcGFja2V0cyB0aGF0IGl0
IGhhcyByZWNlaXZlZCBpbiBvbmU8YnI+DQplbmNyeXB0aW9uIGxldmVsLjxvOnA+PC9vOnA+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoaXMgc3VtcyB1cCBteSBmZWVsaW5ncyBhcyB3ZWxsIC0gSSByZWFsbHkgbGlrZSB0
aGUgZXhwbGljaXRuZXNzIG9mIHRoZSBzZXBhcmF0ZSBzcGFjZXMuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DM5PR2101MB0901581E982F410F31E42E2AB32B0DM5PR2101MB0901_--


From nobody Thu Jul 26 08:44:56 2018
Return-Path: 
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 842E113119C for ; Thu, 26 Jul 2018 08:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level: 
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 5gk2SkOtC2zz for ; Thu, 26 Jul 2018 08:44:50 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 01587131157 for ; Thu, 26 Jul 2018 08:44:50 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id g6-v6so1513370lfb.11 for ; Thu, 26 Jul 2018 08:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iVwK5MejFnZougPZYJiJJMzCgmprkkqYrCp//lpEL8M=; b=x3oXImOV1z0Zwna+0gXW5GrLTIOxxWX9nv0Vu36D+uImBkM8B3GoKZdscG17d31Jv+ 9qBvWLkzTwSgh9byKlD8/liex7t4XTGNDeIGDrlt8WdUOYFY2cWgjEUdbeG0nPSoGHbz e3dRfC5wPGS0N6HsxVrG7T8xR/zgmo86opxVzL3tbYDLMawui3q+PM88ILcHOm/Vwk61 1ZT1qiScvSEDwt6DjaHtKqCwOpcimGtefihwt1bYEIDh6qrClogBaefvsz5SxUlJf1SV mlm/EanZ8lFt4IZ35MmGeV2yrP2QZPSwNNIX74l0IbRP0xJN3WBwdD+H5nI4qN/rA5Av gIUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iVwK5MejFnZougPZYJiJJMzCgmprkkqYrCp//lpEL8M=; b=qjXO7cNQL69CnQoupq8NKFJDXTSMU/K1Ev+OcWGQxQ8r6DjHalm4PFNHUTL6BwxVsk FzIwxteosq6wYaGUI30cgFGO3n21qzhWD13Thl+Acq4YUFD+06eeQQ/kYGRyur5URKLl oMFqQGEvIlLq6OpZ/gnrCW4P175l3KZfGMV+NEWf8JvwSGr1Pei2CnTGvpbmxRg+/i6H SZmPCbv9zYrBid2pFzSJKd0DtbjnIi7mmfuWUWd/Yv1xOf4GssXntcDPPu3TpztymbtZ zYr4/mPiAgerCrSWwPCLRDXBpshsLkhk0CA1/VK1AUjhXL/tqndilTaquJwhcbo7NH1U L+KA==
X-Gm-Message-State: AOUpUlHO2bLRqS2n4r+Y/mP4SophORXi6HOZC4o/VlEzK99qJjcSNnT+ m9hsYCZCcyn9H9dYsU2prcBE/tHz/KjXwUsZzV3E2w==
X-Google-Smtp-Source: AAOMgpd9dtduJM7eGdYyJuPrQY+SX5OcrerfnJflfpsgLzywKL85h8BdTTk9LRRE3YfVDBq+Y9efW6bwAe1D8wa4KMg=
X-Received: by 2002:a19:a417:: with SMTP id q23-v6mr1698187lfc.59.1532619888136;  Thu, 26 Jul 2018 08:44:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 08:44:07 -0700 (PDT)
In-Reply-To: 
References:     
From: Eric Rescorla 
Date: Thu, 26 Jul 2018 08:44:07 -0700
Message-ID: 
Subject: Re: Go Back to Single Packet Number Space
To: Nick Banks 
Cc: Patrick McManus , Kazuho Oku ,  QUIC WG , Martin Thomson 
Content-Type: multipart/alternative; boundary="00000000000002310e0571e8e0b8"
Archived-At: 
X-BeenThere: quic@ietf.org
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 15:44:54 -0000

--00000000000002310e0571e8e0b8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 26, 2018 at 7:04 AM, Nick Banks <
nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:

> First, I think we should limit the discussion to what actually is in V1.
> Things like post quantum crypto and possible future TLS changes are
> interesting to reason about, but should have no immediate bearing on the
> design right now. If things change in the future that might cause
> additional issues, we should handle them in a future version.
>
>
>
> Second, on the topic of only acknowledging packets at a greater than or
> equal encryption level being even harder or less efficient to implement,
> while I whole-heartedly disagree, I was thinking about this, and feel we
> could actually go one step further. Already I have proposed disallowing
> ACKs in Initial packets and allowing 0-RTT packets to be acknowledged in
> Handshake packets. We could instead just say no ACKs in Initial packets,
> but all other packets can acknowledge any other packet.
>

This seems like a lot of special casing.


No encryption level requirements at all. The obvious possible point of
> contention with this, is that it would allow Handshake packets to
> acknowledge 1-RTT packets. While it is a =E2=80=98lower=E2=80=99 encrypti=
on level (I don=E2=80=99t
> really know what that means) both Handshake and 1-RTT keys are keys only
> the endpoints know. I don=E2=80=99t see any harm in temporarily (as long =
as you
> accept Handshake packets) allowing Handshake packets to acknowledge 1-RTT
> packets. With this design, an implementation that needs to acknowledge
> something can then do whatever it likes, so long as it doesn=E2=80=99t us=
e an
> Initial packets.
>

This does not match the analytic framework established for TLS 1.3, which
explicitly includes key separation between handshake and traffic keys. This
was very important when we did the protocol analysis, so I would not be in
favor of this change.

-Ekr




> Next, for not explicitly sending ACK frames in Initial packets, I
> personally don=E2=80=99t see the explicit event of TLS changing read encr=
yption
> keys from initial to handshake as an implicit signal. To me, it seems ver=
y
> reasonable to call that out as the explicit signal to treat your initial
> packet(s?) as acknowledged.
>



>
> - Nick
>
>
>
> *From:* Patrick McManus 
> *Sent:* Thursday, July 26, 2018 5:15 AM
> *To:* Kazuho Oku 
> *Cc:* Martin Thomson ; Nick Banks <
> nibanks@microsoft.com>; QUIC WG 
> *Subject:* Re: Go Back to Single Packet Number Space
>
>
>
>
>
>
>
> On Thu, Jul 26, 2018 at 4:33 AM, Kazuho Oku  wrote:
>
> 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 sums up my feelings as well - I really like the explicitness of the
> separate spaces.
>

--00000000000002310e0571e8e0b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Jul 26, 2018 at 7:04 AM, Nick Banks <ni=
banks=3D40microsoft.com@dmarc.ietf.org> wrote:











First, I think we should limit the discussion to wha=
t actually is in V1. Things like post quantum crypto and possible future TL=
S changes are interesting to reason about, but should have no immediate bea=
ring on the design right now. If things
 change in the future that might cause additional issues, we should handle =
them in a future version.


=C2=A0


Second, on the topic of only acknowledging packets a=
t a greater than or equal encryption level being even harder or less effici=
ent to implement, while I whole-heartedly disagree, I was thinking about th=
is, and feel we could actually go
 one step further. Already I have proposed disallowing ACKs in Initial pack=
ets and allowing 0-RTT packets to be acknowledged in Handshake packets. We =
could instead just say no ACKs in Initial packets, but all other packets ca=
n acknowledge any other packet.

=

This seems like a lot of special casing.

 

 No encryption level requirements at all. The obvious possible point of con=
tention with this, is that it would allow Handshake packets to acknowledge =
1-RTT packets. While it is a =E2=80=98lower=E2=80=99 encryption level (I do=
n=E2=80=99t really know what that means) both Handshake
 and 1-RTT keys are keys only the endpoints know. I don=E2=80=99t see any h=
arm in temporarily (as long as you accept Handshake packets) allowing Hands=
hake packets to acknowledge 1-RTT packets. With this design, an implementat=
ion that needs to acknowledge something
 can then do whatever it likes, so long as it doesn=E2=80=99t use an Initia=
l packets.

This does not ma=
tch the analytic framework established for TLS 1.3, which explicitly includ=
es key separation between handshake and traffic keys. This was very importa=
nt when we did the protocol analysis, so I would not be in favor of this ch=
ange.

-Ekr


=

=C2=A0

Next, for not explicitly sending ACK frames in Initial packets, =
I personally don=E2=80=99t see the explicit event of TLS changing read encr=
yption keys from initial to handshake as an implicit signal. To me, it seem=
s very reasonable to call that
 out as the explicit signal to treat your initial packet(s?) as acknowledge=
d.


=



=C2=A0


- Nick


=C2=A0


From: Patrick McManus <pmcmanus@mozilla.com> 

Sent: Thursday, July 26, 2018 5:15 AM

To: Kazuho Oku <kazuhooku@gmail.com>

Cc: Martin Thomson <martin.thomson@gmail.com>; Nick Banks <nibanks@microsoft.com>; QUIC WG <quic=
@ietf.org>

Subject: Re: Go Back to Single Packet Number Space


=C2=A0











--00000000000002310e0571e8e0b8--


From nobody Thu Jul 26 09:09:38 2018
Return-Path: 
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 0AA0A130DE0 for ; Thu, 26 Jul 2018 09:09:36 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 a5Ni76mh4Vih for ; Thu, 26 Jul 2018 09:09:33 -0700 (PDT)
Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B223B130DD0 for ; Thu, 26 Jul 2018 09:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple;  q=dns/txt; i=@apple.com; t=1532621372; x=2396534972; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RUkKlfv+7e0/fHlo2uwnzpLO9ADE1qIGRoo/naS8txM=; b=nsmxTaxxVFkGPltDuFZqp9b7p8+QsIijaUxsJlsPZDvvipqmZ/4uKW1U3YTtb0RA jgnR8tDAEGLTU/vxP12q2BCJLJMPalZrgF789k/HI8St1BZ6yaW8kBh9ajVF2acv nPozd/JssOhnJHK0PpDYFkHhIy6Hzz9+mrYt5xO0ddls1/NU0DcKcnFHveymAzRy MOQ71EmfnGVPkoH5F8v+FO0ojUXcv8bRf0YqmfzkDSDuM38NLLdTgpoH5DzbsOtM 8vm9eApjb6HImIVRJH/io5L1allrIVyxNysx0Ao3av8s+RFqWFAX8WzRCB3rQxez dNwfQOCmKGlpw72cTUkpfQ==;
X-AuditID: 11ab0219-56fff70000004c1b-d5-5b59f23c8b48
Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 12.FF.19483.C32F95B5; Thu, 26 Jul 2018 09:09:32 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_a6a0L5zxa95GL4r1soLqgg)"
Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCH003Z4E7WU3A0@ma1-mtap-s02.corp.apple.com>; Thu, 26 Jul 2018 09:09:32 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCH00K00DW95Y00@nwk-mmpp-sz12.apple.com>; Thu, 26 Jul 2018 09:09:32 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: ac297ad8b265304ff727e66f1dc3418f
X-Va-E-CD: 9972b49a85f1a3efa290995569b54582
X-Va-R-CD: 5fd1ac8411fc0aff2be93db04dc55585
X-Va-CD: 0
X-Va-ID: a13329e3-044d-4f11-ab29-53a39bc3134f
X-V-A: 
X-V-T-CD: ac297ad8b265304ff727e66f1dc3418f
X-V-E-CD: 9972b49a85f1a3efa290995569b54582
X-V-R-CD: 5fd1ac8411fc0aff2be93db04dc55585
X-V-CD: 0
X-V-ID: c7b00404-0858-4f07-a5fc-669731c13574
Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCH00K00DVH0R00@nwk-mmpp-sz12.apple.com>; Thu, 26 Jul 2018 09:09:31 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-26_04:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1
Received: from [17.234.9.47] (unknown [17.234.9.47]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCH0066CE7T8070@nwk-mmpp-sz12.apple.com>; Thu, 26 Jul 2018 09:09:31 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly 
Message-id: 
Subject: Re: Go Back to Single Packet Number Space
Date: Thu, 26 Jul 2018 09:09:24 -0700
In-reply-to: 
Cc: Dmitri Tikhonov , "quic@ietf.org" , Martin Thomson 
To: Nick Banks 
References:   <20180726030135.GA19322@ubuntu-dmitri>  
X-Mailer: Apple Mail (2.3445.100.13.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR1PBh07X5FBltMP2SlcWXCWwW1878Y7SY t2cTu0XPAm4HFo8Ty66weuycdZfdY8mSn0weT7YdZw5gieKySUnNySxLLdK3S+DKmPHnBXNB a25Fx5EFLA2MrXFdjJwcEgImEs+vX2LrYuTiEBLYzyTxfPlnVpAEr4CgxI/J91hAbGaBMIn9 DZuYIIo2MkmsWvmEHcLpYpJYf2sVE8Qodok/v3awQNjaEsvOTGGHsd8/3g1nT5l4Dcrmkliw 9TTQNg4gW1fibm8RRJhNYv2JJVAjtSSW71zIAmM37lnPDGMfOPKUDcLmlDj/ZSLUSB2JtZ+W Q93WySSx7NB5qEHZEi8Xb4KygyWub2mDKupmkti3YTM7yBHCAhISm/ckgtSwCahIHP+2gRkS EjYSdyb+BVsmLGAkcfDnbLA4i4CqxPIz18GhxSmQLLHj6jFWSGjVS1x8dQzsaBEBc4kZ919C 7brDJHH32AmoS9Uk5t9+wTqBUWEWUmjPQgrtWUAnMQuoS0yZkgsR1pZ48u4CK4StJrHw9yIm ZPEFjGyrGIVzEzNzdDPzjEz1EgsKclL1kvNzNzGCUtBqJskdjF9fGx5iFOBgVOLh/fEiMlqI NbGsuDL3EKM0B4uSOO/HXWLRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgbf+YIXpI4ebHg b/4Rzj9uN3609bv9ftf0d9+JXvmfmSVyNUpm5+0ny92fqnR50b7FfktLnqxNlppy/W/qvZ0q KnX+4jfiwpgUdUVZvnRMN8ywzmmRkeezmt9vq2NuYxb/TWBvZsj2lU/u9WafrHfPiiriCuQQ b3yYJKPxuGH9vYJUiwssJUosxRmJhlrMRcWJABRy6z8iAwAA
Archived-At: 
X-BeenThere: quic@ietf.org
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 16:09:36 -0000

--Boundary_(ID_a6a0L5zxa95GL4r1soLqgg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

First off, I'd like to +1 to the points Kazuho made, as I think he did a =
very good job of expressing the concern I have.

To elaborate on the point about separation of spaces making things =
easier to reason about:

While the table below does indicate that there are 4 different =
encryption levels/sets of keys, there can and should be a connection =
between the 0-RTT and 1-RTT spaces.=20

| Packet Type     | Encryption Level | PN Space  |
|:----------------|:-----------------|:----------|
| Initial         | Initial secrets  | Initial   |
| 0-RTT Protected | 0-RTT            | 0/1-RTT   |
| Handshake       | Handshake        | Handshake |
| Retry           | N/A              | N/A       |
| Short Header    | 1-RTT            | 0/1-RTT   |

Effectively, there are three different levels of trust at play, which =
determine the type of frame content that may be sent:
- For Initial packets, there is no established trust at all
- For Handshake packets, there is only the established trust that the =
peers are the same ones that performed the Initial exchange; at this =
point it is safe to perform authentication
- For both 0-RTT and 1-RTT packets, there is the trust that the peers =
have completed an authenticated handshake; only here is it safe to send =
application data

These three levels of trust are not specific to TLS, but a common =
feature of security handshakes.

Separated packet number spaces allows an implementation to very =
discretely separate its handling of frames and retransmissions between =
the three levels of trust. The architecture that this promotes is one =
that (I hope) is less likely to have bugs in which frames that must only =
be sent in higher levels of trust are sent in lower levels.

Thanks,
Tommy

> On Jul 25, 2018, at 9:37 PM, Nick Banks =
 wrote:
>=20
> 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=E2=80=99=
d think there should be four packet spaces. I think having all this =
duplication and separation just adds unnecessary complexity.
> =20
> Sent from my Windows 10 device
> [HxS - 15254 - 16.0.10325.20083]
> =20
> From: tpauly@apple.com  > on behalf of Tommy Pauly >
> 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
> =20
> 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.
>=20
> Thanks,
> Tommy
>=20
> > On Jul 25, 2018, at 8:01 PM, Dmitri Tikhonov =
> =
wrote:
> >=20
> > 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.
> >=20
> > EKR is one of the "others" [1] -- are there other implementers who
> > prefer the triple packet space?
> >=20
> >  - Dmitri.
> >=20
> > 1. =
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.=
com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-405720217&da=
ta=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc7808d5f2b00684%=
7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636681760204180396&sdata=3D=
fstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&reserved=3D0 =

> >=20
>=20


--Boundary_(ID_a6a0L5zxa95GL4r1soLqgg)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

First=
 off, I'd like to +1 to the points Kazuho made, as I think he did a very =
good job of expressing the concern I have.

To elaborate on the point about =
separation of spaces making things easier to reason about:

While the table below =
does indicate that there are 4 different encryption levels/sets of keys, =
there can and should be a connection between the 0-RTT and 1-RTT =
spaces. 

| Packet Type     | Encryption Level | PN =
Space  |
|:----------------|:-----------------|:----------|
| Initial         | Initial secrets =
 | Initial   |
| 0-RTT Protected | 0-RTT =
           | 0/1-RTT   |
| Handshake       | Handshake     =
   | Handshake |
| Retry     =
      | N/A             =
 | N/A       |
| Short Header =
   | 1-RTT           =
 | 0/1-RTT   |

Effectively, there are three different =
levels of trust at play, which determine the type of frame content that =
may be sent:
- For Initial packets, there is no =
established trust at all
- For Handshake packets, =
there is only the established trust that the peers are the same ones =
that performed the Initial exchange; at this point it is safe to perform =
authentication
- For both 0-RTT and 1-RTT packets, =
there is the trust that the peers have completed an authenticated =
handshake; only here is it safe to send application data

These three levels of =
trust are not specific to TLS, but a common feature of security =
handshakes.

Separated packet number spaces allows an implementation to =
very discretely separate its handling of frames and retransmissions =
between the three levels of trust. The architecture that this promotes =
is one that (I hope) is less likely to have bugs in which frames that =
must only be sent in higher levels of trust are sent in lower =
levels.

Thanks,
Tommy

On Jul =
25, 2018, at 9:37 PM, Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> =
wrote:

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=E2=80=99d 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 <tpauly@apple.com> on =
behalf of Tommy Pauly <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> 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=3Dhttps%3A%2=
F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F1579%23issuecomment-40572=
0217&amp;data=3D02%7C01%7Cnibanks%40microsoft.com%7C86b0eb2ea03c48a3fc=
7808d5f2b00684%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63668176020418=
0396&amp;sdata=3DfstGdvwnKKfApVKVQZFuJYdWAZkXCafUsEH0t1YtH8U%3D&am=
p;reserved=3D0
> 


=

--Boundary_(ID_a6a0L5zxa95GL4r1soLqgg)--


From nobody Thu Jul 26 09:52:49 2018
Return-Path: 
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 23DB6130E0E for ; Thu, 26 Jul 2018 09:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level: 
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 elyVn74Tb0Dh for ; Thu, 26 Jul 2018 09:52:44 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 B74EF12F1AC for ; Thu, 26 Jul 2018 09:52:44 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id z143-v6so815611ywa.7 for ; Thu, 26 Jul 2018 09:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8wiAuN0JMMl7/WJRMmkhJqebBGXr/CNI71ohFbCnXs8=; b=Y/vqxaU55X2OecFjrt6xZqxj3r3qg4Fou6pCSdfmF4PuwMz424qAPlazDfhtKgwvBW UEwTM5kJQFJPh5qnO8zB8KeF+dAeXlJmAA2dSYYXVqLJSjMfJD2gpsAZP5vIafQdCc98 P0aXwuY6/9m5MV9sT/Cw6atNmKqn77it7cKYcSpfVHfdrycx5Ndy60cYv4xk/S9AK/5p kiRQfLQxONM3bcM3r82GYumgqb/5J7sNeNTL41LbG7c7/W3zpcRhwSNXPOetLRRGPKlY srXDQl6jbq0yLMHeSequlYckfYdHjBDtQC2qp57QSlSJZJdMOskJCBpV2ryLvPqGk8fw HeQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8wiAuN0JMMl7/WJRMmkhJqebBGXr/CNI71ohFbCnXs8=; b=m7CO3/HbyVNZBfYNtUJ1GT3wYKqT7NrDm8eMWmcmMbyht4Xjbt9Uztt8ReWjlH6avm 50JLGOlbATo2HmUVpEiFuYnu9u1TQt+vIVJrk5DCuaIUr90KupUfWC3KcaJBN/0hxuaz E5v7bCJV7csQoqvoS84ypcUSBAk1GIEKyUkc9x9WrBRtO54npbQQWxXN3QVsKViArlpA aNDye57zywtDutV6POOrKVN+0tCySKLN4V2FG5iUcBWk2PoNx3gG4espjTx7Q6czUwKS IzM3941M/K9a9jsIfNsSza8SerPutxxriy476eMQwhPXWjP1WKAKyH0yzgBPF6/vvSu7 RtFg==
X-Gm-Message-State: AOUpUlHNWUTgk8UF7g3ddAm2yrTUg5FBrt+iXGdZ0Z/mvwOyZ2MNCc0r /PfzA364r/xXJmw01C7X7N0qBhfeI1/wfLhSsFr5pw==
X-Google-Smtp-Source: AAOMgpfEIm4U3kdBKyJMkSL0ds/edwPuHbw0n30qLyJ0335E9PEWUxJEj3dbX/5yd+8NpXNWDdWGrvAjbv9FfCxj0KY=
X-Received: by 2002:a81:2c0a:: with SMTP id s10-v6mr1405664yws.335.1532623963567;  Thu, 26 Jul 2018 09:52:43 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Ian Swett 
Date: Thu, 26 Jul 2018 12:52:32 -0400
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: IETF QUIC WG , "Deval, Manasi" , borisp@mellanox.com
Content-Type: multipart/alternative; boundary="000000000000ecf4af0571e9d23e"
Archived-At: 
X-BeenThere: quic@ietf.org
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 16:52:47 -0000

--000000000000ecf4af0571e9d23e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

That seems like a reasonable suggestion to me.

Adding Boris and Manasi to see if they also think it'll make hardware
offload easier?

On Thu, Jul 26, 2018 at 2:22 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen 
wrote:

> I created the following issue a while ago but go no response, so perhaps
> it should have been discussed on this list:
>
> https://github.com/quicwg/base-drafts/issues/1578
>
> The issues covers the point, but in summary:
>
> If the packet format is kept as it is today, but the packet number is not
> included in the authenticated data when computing the AEAD tag, then the
> decoder need not modify the received packet buffer when decoding the pack=
et
> number. This can lead to more efficient hardware implementations and make
> multi-processor buffer sharing more effective.
>
> Mikkel
>

--000000000000ecf4af0571e9d23e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


That seems like a reasonable suggestion to me.=C2=A0
<=
br>
Adding Boris and Manasi to see if they also think it'll m=
ake hardware offload easier?

On Thu, Jul 26, 2018 at 2:22 AM Mikkel Fahn=C3=B8e J=C3=B8rgen=
sen <mikkelfj@gmail.com> wr=
ote:
I created the following issue a whil=
e ago but go no response, so perhaps it should have been discussed on this =
list:

https://github.com/quicwg/base-drafts/iss=
ues/1578

The issues covers the point, but in su=
mmary:

If the packet format is kept as it is today, =
but the packet number is not included in the authenticated data when comput=
ing the AEAD tag, then the decoder need not modify the received packet buff=
er when decoding the packet number. This can lead to more efficient hardwar=
e implementations and make multi-processor buffer sharing more effective.

Mikkel




--000000000000ecf4af0571e9d23e--


From nobody Thu Jul 26 09:53:48 2018
Return-Path: 
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 930BC130E0E for ; Thu, 26 Jul 2018 09:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EaXu7Uan0Y2d for ; Thu, 26 Jul 2018 09:53:44 -0700 (PDT)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2196E12F1AC for ; Thu, 26 Jul 2018 09:53:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41bypt4wj6zMl1H; Thu, 26 Jul 2018 18:53:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sowSyRgakwnj; Thu, 26 Jul 2018 18:53:41 +0200 (CEST)
X-MtScore: NO score=0
Received: from [10.0.100.91] (50-204-41-11-static.hfc.comcastbusiness.net [50.204.41.11]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 26 Jul 2018 18:53:40 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Subject: Re: Hidden connection spawning
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= 
In-Reply-To: 
Date: Thu, 26 Jul 2018 11:53:38 -0500
Cc: QUIC WG , Martin Thomson 
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F11F9C1-FD7D-48D6-9D59-838852DD58B8@tik.ee.ethz.ch>
References:  
To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: 
X-BeenThere: quic@ietf.org
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 16:53:47 -0000

Hi Mikkel,

a little amount of discussion on this also happened in taps. At least I =
have a draft on separating the handshake from the actual data encryption =
(draft-kuehlewind-taps-crypto-sep) which was not yet largely discussed =
but probably will come up again.=20

In case of quic I'm mainly wondering how hard it would be to resume a =
TLS1.3 session with keys that have been negotiated with a different =
underlying transport protocol (use 0-RTT quic based on keys from a =
TCP/TLS1.3 connection or the other way around)=E2=80=A6?=20

But maybe the taps list is a better place to have this discussion=E2=80=A6=


Mirja



> Am 26.07.2018 um 04:35 schrieb Martin Thomson =
:
>=20
> Sounds like work for an extension to me.
> On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen
>  wrote:
>>=20
>> I came to think about a use case where you want to spawn a new =
connection from an existing connection because the new connection runs a =
different protocol. For example a http connection where you  want to run =
a separate live conference call, or to control tunnels from http control =
connection.
>>=20
>> You have roughly three options:
>>=20
>> 1. extend the current protocol with the new feature set in extension =
frames or similar
>> 2. develop or use a purposes specific QUIC protol using 0-RTT for =
spawning the connection
>> 3. negotiate the new connection handshake within the current =
handshake.
>>=20
>> The first solution is not complex, limited, and not modular.
>> The second solution can be used to get information about the =
connection, and for example block connections that appear to be doing =
that.
>> The third solution allows for an invisible connection spawn, but =
requires addition handshake logic which is already complex as it is.
>>=20
>> I suggesting solution 3 as possible option, although I am not =
convinced that this is worthwhile, at least in V1.
>>=20
>>=20
>> This was in part inspired by recent discussion on tunneling, and in =
part by the following issue where partial reliability is being discussed =
and possibly shoe-horned into an extension. I am not following that =
issue closely though - it is just an example.
>> =
https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495
>>=20
>>=20
>> Mikkel
>=20


From nobody Thu Jul 26 10:28:10 2018
Return-Path: 
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 DF7F3130E53 for ; Thu, 26 Jul 2018 10:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.003
X-Spam-Level: ***
X-Spam-Status: No, score=3.003 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, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 f3rrKF5vkWm4 for ; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 AD049130E0C for ; Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id w16-v6so3873076ita.0 for ; Thu, 26 Jul 2018 10:28:06 -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=yeW8NMB1mSf9bis/1cohTYduuvzZdK/VwQ8/GOSnd6w=; b=Z73Tns15DKsgkbbLbR1IwE97Ddjtqb37fTmEiiE8zVt9Bp92dRgXcAiKsSTFei/5vB NWUD1LEvMOqcpOjqviCnUgvDRvn9cDuVgaJJnuOKnP/QbVLsFjAIEm8L/sXmT2QP6W0i my1M7xEZGYsqqb9/jgDclakA0tsTsa0AilBU2lC2FeoEwQi+nF+K+BA30hDaulW36QUv HStJpG5q86uClKyCBfLU9G4pmiR7/+uT9eXFSHGHUocX/RoB67oLmcB1iSmhl+mk/x+M f7EeWbH3kOc+FAEv4mO5hWQDg4pjkGXlfENBz1Qo1C1/nsjUcpdvzkMTr7f2l/CRhM0D zvIA==
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=yeW8NMB1mSf9bis/1cohTYduuvzZdK/VwQ8/GOSnd6w=; b=LXiTwIdnGcTA6fuqON4PvC+nCE5gL7zpbJcwaE06WeXp/ow8gcU9vr8YtA1wsNkujR uZBDsCHXfj2Yv3N4Qbwj7DlJXvYjptA1pnyjz4x54ATq97ZuafY0leho3YN8dLmJD33Q dppn2S0JR1bGNBuFUOUQoPao9OKGUq5zfD/pFOUp05GZgkzuFIr3/7AsyO53441PW0DL PyTaoBRF1ZLINTO0nBeory31RcKH8wOO5UWDxNxpUq2FdPvCURmqV2CGrXOzqY2Waz/4 TGSimsMStc9vFFmQsW5cHzG3FBwGcFLlzhM7GLR/rNH4QDltW+iE6OuYQXXxBbOMsQoa VrNg==
X-Gm-Message-State: AOUpUlEuyITgE8tj2cAEyMkoHtBjOgDEtEQoRdcL1Nc7ZXgQ1I9RTEAt kViiawDIjFFRXGfO/jR3ivBpJbBj9ZmTMvyrN5E=
X-Google-Smtp-Source: AAOMgpeem2VQN/VXeYgp1G1+yVcC1dJ1yM9zEhaAxQvjVEop3HF57sIz+N9xhQfb1/S4uHL7AXKTIOV7nwZ0uf6qLPc=
X-Received: by 2002:a02:8c75:: with SMTP id j50-v6mr2871917jal.76.1532626086055;  Thu, 26 Jul 2018 10:28:06 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 26 Jul 2018 10:28:05 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <3F11F9C1-FD7D-48D6-9D59-838852DD58B8@tik.ee.ethz.ch>
References:   <3F11F9C1-FD7D-48D6-9D59-838852DD58B8@tik.ee.ethz.ch>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Thu, 26 Jul 2018 10:28:05 -0700
Message-ID: 
Subject: Re: Hidden connection spawning
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= 
Cc: Martin Thomson , QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000006ed3e40571ea519c"
Archived-At: 
X-BeenThere: quic@ietf.org
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 17:28:09 -0000

--0000000000006ed3e40571ea519c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mirja,

I believe at least the following issues must be addressed in a handshake:

- traffic keys
- PMTU
- TP (transport params, incl. reset token etc.)
- CID
- TLS CERT auth (some clients are authenticated this way too)
- QUIC version

Traffic keys are easy. PMTU could be inherited and later retested if
needed. Transport params probably cannot be inherited trivially, especially
not if there is some sort of negotiation happening, but I don=E2=80=99t the=
re is
anything beyond "this is what I have - deal with it". CID would require
some thought because it needs to be different and possible route to same or
different location. TLS Certs could be implied valid via handover.

For things like traffic keys, it would be trivial to provide these via any
secure out-of-band channel. But the sum of concerns probably would make it
fragile to attempt to use a non-QUIC protocol to negotiate a QUIC
handshake, except for the special case where everything other than traffic
keys and CID can be statically configured.

Of course you can be have special QUIC protocols that can have handshake
negotiated via either QUIC or WebRTC etc, but in the general case I think
it needs to be via QUIC and likely even the same QUIC version.

The above can be side-stepped by actually carrying a full QUIC handshake
over another secure channel, but that could lead to more roundtrips and
overhead than ideal. 0-RTC might not work here because keys might not be
present. Various rejections might happen like retry or vneg.


On 26 July 2018 at 18.53.43, Mirja K=C3=BChlewind (
mirja.kuehlewind@tik.ee.ethz.ch) wrote:

Hi Mikkel,

a little amount of discussion on this also happened in taps. At least I
have a draft on separating the handshake from the actual data encryption
(draft-kuehlewind-taps-crypto-sep) which was not yet largely discussed but
probably will come up again.

In case of quic I'm mainly wondering how hard it would be to resume a
TLS1.3 session with keys that have been negotiated with a different
underlying transport protocol (use 0-RTT quic based on keys from a
TCP/TLS1.3 connection or the other way around)=E2=80=A6?

But maybe the taps list is a better place to have this discussion=E2=80=A6

Mirja



> Am 26.07.2018 um 04:35 schrieb Martin Thomson :
>
> Sounds like work for an extension to me.
> On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen
>  wrote:
>>
>> I came to think about a use case where you want to spawn a new
connection from an existing connection because the new connection runs a
different protocol. For example a http connection where you want to run a
separate live conference call, or to control tunnels from http control
connection.
>>
>> You have roughly three options:
>>
>> 1. extend the current protocol with the new feature set in extension
frames or similar
>> 2. develop or use a purposes specific QUIC protol using 0-RTT for
spawning the connection
>> 3. negotiate the new connection handshake within the current handshake.
>>
>> The first solution is not complex, limited, and not modular.
>> The second solution can be used to get information about the connection,
and for example block connections that appear to be doing that.
>> The third solution allows for an invisible connection spawn, but
requires addition handshake logic which is already complex as it is.
>>
>> I suggesting solution 3 as possible option, although I am not convinced
that this is worthwhile, at least in V1.
>>
>>
>> This was in part inspired by recent discussion on tunneling, and in part
by the following issue where partial reliability is being discussed and
possibly shoe-horned into an extension. I am not following that issue
closely though - it is just an example.
>> https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495
>>
>>
>> Mikkel
>

--0000000000006ed3e40571ea519c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Hi Mirja,

I believe at least the followin=
g issues must be addressed in a handshake:

- traffic keys
- PMTU
- TP (transport params, incl. reset token etc.)
- CID
- TLS CERT auth (some client=
s are authenticated this way too)
- QUIC version
=C2=A0
Traffic keys are easy. PMTU could be inherited and later=
 retested if needed. Transport params probably cannot be inherited triviall=
y, especially not if there is some sort of negotiation happening, but I don=
=E2=80=99t there is anything beyond "this is what I have - deal with i=
t". CID would require some thought because it needs to be different an=
d possible route to same or different location. TLS Certs could be implied =
valid via handover.

F=
or things like traffic keys, it would be trivial to provide these via any s=
ecure out-of-band channel. But the sum of concerns probably would make it f=
ragile to attempt to use a non-QUIC protocol to negotiate a QUIC handshake,=
 except for the special case where everything other than traffic keys and C=
ID can be statically configured.

Of course you can be have special QUIC protocols that can have =
handshake negotiated via either QUIC or WebRTC etc, but in the general case=
 I think it needs to be via QUIC and likely even the same QUIC version.

The above can be side-st=
epped by actually carrying a full QUIC handshake over another secure channe=
l, but that could lead to more roundtrips and overhead than ideal. 0-RTC mi=
ght not work here because keys might not be present. Various rejections mig=
ht happen like retry or vneg.

 
On 26 July 2018 at 18.5=
3.43, Mirja K=C3=BChlewind (mirja.kuehlewind@tik.ee.ethz.ch) wrote:
 
Hi Mikkel,



a little amount of discussion on this also happened in taps. At least I=
 have a draft on separating the handshake from the actual data encryption (=
draft-kuehlewind-taps-crypto-sep) which was not yet largely discussed but p=
robably will come up again. =20



In case of quic I'm mainly wondering how hard it would be to resume=
 a TLS1.3 session with keys that have been negotiated with a different unde=
rlying transport protocol (use 0-RTT quic based on keys from a TCP/TLS1.3 c=
onnection or the other way around)=E2=80=A6? =20



But maybe the taps list is a better place to have this discussion=E2=80=
=A6



Mirja







> Am 26.07.2018 um 04:35 schrieb Martin Thomson <martin.thomson@gmail.com>:

> =20

> Sounds like work for an extension to me.

> On Thu, Jul 26, 2018 at 4:32 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen

> <mikkelfj@gmail.com&g=
t; wrote:

>> =20

>> I came to think about a use case where you want to spawn a new=
 connection from an existing connection because the new connection runs a d=
ifferent protocol. For example a http connection where you  want to run a s=
eparate live conference call, or to control tunnels from http control conne=
ction.

>> =20

>> You have roughly three options:

>> =20

>> 1. extend the current protocol with the new feature set in ext=
ension frames or similar

>> 2. develop or use a purposes specific QUIC protol using 0-RTT =
for spawning the connection

>> 3. negotiate the new connection handshake within the current h=
andshake.

>> =20

>> The first solution is not complex, limited, and not modular.

>> The second solution can be used to get information about the c=
onnection, and for example block connections that appear to be doing that.

>> The third solution allows for an invisible connection spawn, b=
ut requires addition handshake logic which is already complex as it is.

>> =20

>> I suggesting solution 3 as possible option, although I am not =
convinced that this is worthwhile, at least in V1.

>> =20

>> =20

>> This was in part inspired by recent discussion on tunneling, a=
nd in part by the following issue where partial reliability is being discus=
sed and possibly shoe-horned into an extension. I am not following that iss=
ue closely though - it is just an example.

>> https://github.com/quicwg/base-drafts/issues/1606#is=
suecomment-407951495

>> =20

>> =20

>> Mikkel

> =20





--0000000000006ed3e40571ea519c--


From nobody Thu Jul 26 14:33:44 2018
Return-Path: 
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 AD8B5130EAE for ; Thu, 26 Jul 2018 14:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5_ZYaPBUIA5g for ; Thu, 26 Jul 2018 14:33:39 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E368130E0A for ; Thu, 26 Jul 2018 14:33:39 -0700 (PDT)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1finsn-0008UE-5m for quic@ietf.org; Thu, 26 Jul 2018 23:33:35 +0200
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1finsh-0002KU-QP for quic@ietf.org; Thu, 26 Jul 2018 17:33:08 -0400
Received: (qmail 27244 invoked from network); 26 Jul 2018 21:33:04 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.39.156]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jul 2018 21:33:04 -0000
To: quic@ietf.org
References:  
From: Christian Huitema 
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: 
Date: Thu, 26 Jul 2018 14:33:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D33131323AE59AD6BA874D48"
Content-Language: en-US
Subject: Re: Packet Number Encryption outside of AEAD
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5s9raB6a21Vnhwn0u3DKObp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVijmIHL2DPjh4T9n8cu4hFTM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBpxvnk7PJGygctl3LC86inx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWYO2/mqpOb7Q80SeXyngcEQspW6PWtFljIeoG6OsM9IQiLnFf4krIH /ZTjmCmLErVgiNplmw3yp4FFFCuS+k6jh5d4Swn5E67RV+LaU4GmVjH8gYlRWMzXMtJksqe+xLeX oHkzkRzbKyRDRP8j7fY6rka7glK07Vs7rsUOKUDQF2h+wlfAS2SbL4bvnSO/22XcRFubexolRo+C LCjUkAONcKuSF0M++CcmCgpc7O13z5Rins15oKFWvUk5C9olBXDhjX6bHzu+acs8UcTQf4enw6nI oDr0sXUZ7YZoZ/GZ+jr47k1ZYM+XPLUTB3aEhddz5NQBt6vrTjaii/MA7FoCAhy1/eljfSN5aXns qLZLef9qwM7RXpJS8RjTdyh2j5AWyDZ7BRCxIW6XiPgk5wgNeRXbC69qDBnTAPdQSCnD1TRj9D8H LKHAKpPGP8EPnuDHTXhIrVzYteKGVryF5qVZ
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
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 21:33:42 -0000

This is a multi-part message in MIME format.
--------------D33131323AE59AD6BA874D48
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit



On 7/26/2018 9:52 AM, Ian Swett wrote:
> That seems like a reasonable suggestion to me. 
>
> Adding Boris and Manasi to see if they also think it'll make hardware
> offload easier?
>
> On Thu, Jul 26, 2018 at 2:22 AM Mikkel Fahnøe Jørgensen
> > wrote:
>
>     I created the following issue a while ago but go no response, so
>     perhaps it should have been discussed on this list:
>
>     https://github.com/quicwg/base-drafts/issues/1578
>
>     The issues covers the point, but in summary:
>
>     If the packet format is kept as it is today, but the packet number
>     is not included in the authenticated data when computing the AEAD
>     tag, then the decoder need not modify the received packet buffer
>     when decoding the packet number. This can lead to more efficient
>     hardware implementations and make multi-processor buffer sharing
>     more effective.
>
>     Mikkel
>

It is not just a harware issue. It would make software easier to.
Currently, if we want to decrypt a packet, we need to somehow replace
the PN bytes with a decrypted version and pass that as "authenticated
data" to the AEAD decryption. This is really not necessary, since the
decrypted sequence number is included in the IV.

-- Christian Huitema

--------------D33131323AE59AD6BA874D48
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 7/26/2018 9:52 AM, Ian Swett wrote:

    

    

      
      
That seems like a reasonable suggestion to me. 
        


        

        
Adding Boris and Manasi to see if they also think it'll
          make hardware offload easier?

      

      

      

        
On Thu, Jul 26, 2018 at 2:22 AM Mikkel Fahnøe
          Jørgensen <mikkelfj@gmail.com> wrote:

        

        

          

            
I
              created the following issue a while ago but go no
              response, so perhaps it should have been discussed on this
              list:

            


            

            
https://github.com/quicwg/base-drafts/issues/1578

            


            

            
The
              issues covers the point, but in summary:

            


            

            
If
              the packet format is kept as it is today, but the packet
              number is not included in the authenticated data when
              computing the AEAD tag, then the decoder need not modify
              the received packet buffer when decoding the packet
              number. This can lead to more efficient hardware
              implementations and make multi-processor buffer sharing
              more effective.

            


            

            

              
Mikkel

            

          

        

      

    

    

    It is not just a harware issue. It would make software easier to.
    Currently, if we want to decrypt a packet, we need to somehow
    replace the PN bytes with a decrypted version and pass that as
    "authenticated data" to the AEAD decryption. This is really not
    necessary, since the decrypted sequence number is included in the
    IV.

    

    -- Christian Huitema

  


--------------D33131323AE59AD6BA874D48--


From nobody Thu Jul 26 14:42:00 2018
Return-Path: 
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 79B0A130F13 for ; Thu, 26 Jul 2018 14:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 usj3pTOKB21x for ; Thu, 26 Jul 2018 14:41:56 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A68131125 for ; Thu, 26 Jul 2018 14:41:56 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fio1A-0004LP-3I for quic@ietf.org; Thu, 26 Jul 2018 23:41:53 +0200
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fio10-0007jn-Qo for quic@ietf.org; Thu, 26 Jul 2018 17:41:46 -0400
Received: (qmail 3640 invoked from network); 26 Jul 2018 21:41:39 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.39.156]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jul 2018 21:41:39 -0000
To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= 
References: 
From: Christian Huitema 
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Cc: IETF QUIC WG 
Message-ID: 
Date: Thu, 26 Jul 2018 14:41:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------BF5E22844E2E89B6E4F42D60"
Content-Language: en-US
Subject: Re: Hidden connection spawning
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.51)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5m8VH28tPAwsw/XhlSi3isN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVis3nhlkVllM1zNttPzEF9FM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVY5gBCHz+Uo/N0tFtwsRimPxkFlstLtLUT 12JuL2XjD3Nz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVqutd2F/yaZGqnwJYwSpQ91YE7tCqypI5WX0qWh4YQLAhFxALg5ISJWbb Cid3wKxdbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXekflWG4A3HDBzBq/sLmCzQKHY 6H+wSCoVvwvquzDDiP1kW3XKN6SjV/ce7POAEs6Ydub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
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 21:41:59 -0000

This is a multi-part message in MIME format.
--------------BF5E22844E2E89B6E4F42D60
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 7/25/2018 11:31 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
> I came to think about a use case where you want to spawn a new
> connection from an existing connection because the new connection runs
> a different protocol. For example a http connection where you =C2=A0wan=
t to
> run a separate live conference call, or to control tunnels from http
> control connection.
=2E..
>
> This was in part inspired by recent discussion on tunneling, and in
> part by the following issue where partial reliability is being
> discussed and possibly shoe-horned into an extension. I am not
> following that issue closely though - it is just an example.
> https://github.com/quicwg/base-drafts/issues/1606#issuecomment-40795149=
5
>

I have a related scenario in mind, something like "server-assisted
peer-to-peer". Two peers first synchronize through a server -- each peer
has a QUIC connection with the server. They exchange some messages to
establish a peer-to-peer connection through the server, then use
connection migration to establish a direct peer-to-peer connection. I
think it will require the same type of extension frames that you are
considering, plus something like ICE.

-- Christian Huitema

--------------BF5E22844E2E89B6E4F42D60
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 7/25/2018 11:31 PM, Mikkel Fahnøe
      Jørgensen wrote:

    

    

      
      
      
I
        came to think about a use case where you want to spawn a new
        connection from an existing connection because the new
        connection runs a different protocol. For example a http
        connection where you  want to run a separate live conference
        call, or to control tunnels from http control connection.

    

    ...

    

      


      

      
This
        was in part inspired by recent discussion on tunneling, and in
        part by the following issue where partial reliability is being
        discussed and possibly shoe-horned into an extension. I am not
        following that issue closely though - it is just an example.

      
      

    

    

    I have a related scenario in mind, something like "server-assisted
    peer-to-peer". Two peers first synchronize through a server -- each
    peer has a QUIC connection with the server. They exchange some
    messages to establish a peer-to-peer connection through the server,
    then use connection migration to establish a direct peer-to-peer
    connection. I think it will require the same type of extension
    frames that you are considering, plus something like ICE.

    

    -- Christian Huitema

  


--------------BF5E22844E2E89B6E4F42D60--


From nobody Thu Jul 26 15:08:37 2018
Return-Path: 
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 285B0131240 for ; Thu, 26 Jul 2018 15:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, 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 Rw8BcAnUUOJf for ; Thu, 26 Jul 2018 15:08:30 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 53055131242 for ; Thu, 26 Jul 2018 15:08:30 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id n84-v6so5724419oib.9 for ; Thu, 26 Jul 2018 15:08:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DP/4JThFUQQ6QOLJ4htDvf65pOYtG5WmSvMJZRk27u4=; b=vdvdVMG48Y1BOcyPvqXod/nf1JRDPcSUjI4hiGd3Td2K4GnYFdNhFmGXVRySfzLGqI o8wIsNCYcBJZdBrKq4ZPufEjju3NCnvQhRZ2b23AwjB/4ysbTeb2nRv+XZrRpdf3N9vW rhhZQDQbKEpF4hNAXjIFcE666vc3hVtQweMT3EtIzXsvqtagkgScb1nKmJZszcclxCuc oTSeugFfF/eCCmsqnVY7i7BcUaJoDBoZr3qvXFN9VtM9XpVi99cVb1FQAjuj4rrgRQhF R4iE5cMs/BxpaYI5AfYbRVzd6YxWfv2H4cGHxXO520FEE8G6Q4Pt0kKdPdifd7s6jRKu BtEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DP/4JThFUQQ6QOLJ4htDvf65pOYtG5WmSvMJZRk27u4=; b=hz2wjLpJ+bVGIqf0szl9ouKSuX8tzdljgVdubwGmE/jmLBcNScm9IUb8jLtaz+jtJH RQ5pkz6cJlYJb2eTE8CyoFvEsDmF6kd9lzDmb51sLcIykikYIBWKgoB7e7YSeWfzcysx lSYTmCHDWesZYhtaFzCZFmXVtfuM1wF4oZI3G2nDAanjnS5Ot7y6QkB4fg4nSqFuy9oB +ZHc2wT6m012c8UH6U62J4k4bg7s2zYdy6VYsL9zRMt2YOitW4hnRIFpVfa14pPQ4Tip 5myDdwmAoNo53pZga5HnY9aWT1ymRFAjm5jJGzh3loSXEEqXNvAPxKu7Ac7WT11PZOIj 0qYA==
X-Gm-Message-State: AOUpUlEhWtf78zK2DbmTUyxkoKWHqx6zcMiDjOnQheYwT8vudypALPkW f2uSR4cPdAOT81ijqPKRv2hDr7zS09DbBJ49QZA=
X-Google-Smtp-Source: AAOMgpfo3Ae7Ob+CmyoJ4K/aSJLSnoJ/iayfRtHlbevIbuy9ihasrU7/9+TUEZE4HES4t77QDCJlxQTCuca1cLtWC10=
X-Received: by 2002:aca:c692:: with SMTP id w140-v6mr3792818oif.284.1532642909279;  Thu, 26 Jul 2018 15:08:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 15:07:58 -0700 (PDT)
In-Reply-To: 
References:  
From: Ted Hardie 
Date: Thu, 26 Jul 2018 15:07:58 -0700
Message-ID: 
Subject: Re: Hidden connection spawning
To: Christian Huitema 
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  IETF QUIC WG 
Content-Type: multipart/alternative; boundary="0000000000002cdb480571ee3c05"
Archived-At: 
X-BeenThere: quic@ietf.org
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 22:08:35 -0000

--0000000000002cdb480571ee3c05
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 26, 2018 at 2:41 PM, Christian Huitema 
wrote:

>
> I have a related scenario in mind, something like "server-assisted
> peer-to-peer". Two peers first synchronize through a server -- each peer
> has a QUIC connection with the server. They exchange some messages to
> establish a peer-to-peer connection through the server, then use connection
> migration to establish a direct peer-to-peer connection. I think it will
> require the same type of extension frames that you are considering, plus
> something like ICE.
>

This seems like a generalization of the "QUIC as an RTCWEB datachannel"
use case.  In that, the web server providing the JavaScript is the initial
server, ICE messages provide rendezvous/consent, and you can have
peer-to-peer connections.

Other than the generalization from "web server" to "server" is there a
distinction here I'm missing?

Ted

--0000000000002cdb480571ee3c05
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, Jul 26, 2018 at 2:41 PM, Christian Huitema <hui=
tema@huitema.net> wrote:

 =20
   =20
 =20
  


    I have a related scenario in mind, something like "server-assisted
    peer-to-peer". Two peers first synchronize through a server -- eac=
h
    peer has a QUIC connection with the server. They exchange some
    messages to establish a peer-to-peer connection through the server,
    then use connection migration to establish a direct peer-to-peer
    connection. I think it will require the same type of extension
    frames that you are considering, plus something like ICE.

=

This seems like a generalization of the "QUIC as an RTCWEB =
datachannel"=C2=A0=C2=A0 use case.=C2=A0 In that, the web server provi=
ding the JavaScript is the initial server, ICE messages provide rendezvous/=
consent, and you can have peer-to-peer connections. =C2=A0 
<=
br>
Other than the generalization from "web server" to =
"server" is there a distinction here I'm missing?
<=
br>
Ted


--0000000000002cdb480571ee3c05--


From nobody Thu Jul 26 15:40:47 2018
Return-Path: 
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 653EA13124A for ; Thu, 26 Jul 2018 15:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rx90b615c0ke for ; Thu, 26 Jul 2018 15:40:43 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C26B1277C8 for ; Thu, 26 Jul 2018 15:40:43 -0700 (PDT)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fiow4-000181-Pg for quic@ietf.org; Fri, 27 Jul 2018 00:40:41 +0200
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fiovw-0006R7-FJ for quic@ietf.org; Thu, 26 Jul 2018 18:40:36 -0400
Received: (qmail 23615 invoked from network); 26 Jul 2018 22:40:29 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.39.156]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jul 2018 22:40:28 -0000
To: Ted Hardie 
Cc: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , IETF QUIC WG 
References:   
From: Christian Huitema 
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <2739c6b0-f521-659c-408c-a48f66f74b79@huitema.net>
Date: Thu, 26 Jul 2018 15:40:28 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D15D009485AAA27FE77D1610"
Content-Language: en-US
Subject: Re: Hidden connection spawning
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.31)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5ozh1cEvKQ38LGQeQeGpD89602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVinKUq8w9dxJTCLGcpWXENPc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1XpqFDyTB1Bz0n/bLAAUYB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpWbjljpzcldG5bc9h0NLkX5F8FcHzzV3acxBudgYcInb04ky+xnadzl +pZpY0S08wCZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZGPG0gBeFe8dTkoKHsNX/zVwBl1z1+w2zS/h3e6UiVRc6iB2jhOVnJatc toUjTNoWTZuYoWs6Yn9ZbKba9s0cGGeqA47D/juB1cx4exzYk7xDEprJBvGyAnl2eE95UiNN647l NwN4qOsSZg+fYhVZG/KhGwfpQ4IVt47AMmp/QOvVwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
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 22:40:46 -0000

This is a multi-part message in MIME format.
--------------D15D009485AAA27FE77D1610
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 7/26/2018 3:07 PM, Ted Hardie wrote:
> On Thu, Jul 26, 2018 at 2:41 PM, Christian Huitema
> > wrote:
>
>
>     I have a related scenario in mind, something like "server-assisted
>     peer-to-peer". Two peers first synchronize through a server --
>     each peer has a QUIC connection with the server. They exchange
>     some messages to establish a peer-to-peer connection through the
>     server, then use connection migration to establish a direct
>     peer-to-peer connection. I think it will require the same type of
>     extension frames that you are considering, plus something like ICE.=

>
>
> This seems like a generalization of the "QUIC as an RTCWEB
> datachannel"=C2=A0=C2=A0 use case.=C2=A0 In that, the web server provid=
ing the
> JavaScript is the initial server, ICE messages provide
> rendezvous/consent, and you can have peer-to-peer connections. =C2=A0
>
> Other than the generalization from "web server" to "server" is there a
> distinction here I'm missing?

It is definitely related. As it is related to SIP/RTP, and many other
apps. That's a very generic P2P pattern. I like the idea of pushing the
function down to a secure transport layer. It allows embedding this P2P
functionality in any application, independent of the browsers and web
servers. Think of "nodes and supernodes", as in the original versions of
Skype. Or Kazaa if you really want to go down memory lane.

-- Christian Huitema

--------------D15D009485AAA27FE77D1610
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 7/26/2018 3:07 PM, Ted Hardie wrote:

    

    

      
      
On Thu, Jul 26, 2018 at 2:41 PM, Christian Huitema
        <huitema@huitema.net>
        wrote:

        

          

            

              


                 I have a related scenario in mind, something
                like "server-assisted peer-to-peer". Two peers first
                synchronize through a server -- each peer has a QUIC
                connection with the server. They exchange some messages
                to establish a peer-to-peer connection through the
                server, then use connection migration to establish a
                direct peer-to-peer connection. I think it will require
                the same type of extension frames that you are
                considering, plus something like ICE.

            

            


            

            
This seems like a generalization of the "QUIC as an
              RTCWEB datachannel"   use case.  In that, the web server
              providing the JavaScript is the initial server, ICE
              messages provide rendezvous/consent, and you can have
              peer-to-peer connections.   

            

            


            

            
Other than the generalization from "web server" to
              "server" is there a distinction here I'm missing?

            

          

        

      

    

    

    It is definitely related. As it is related to SIP/RTP, and many
    other apps. That's a very generic P2P pattern. I like the idea of
    pushing the function down to a secure transport layer. It allows
    embedding this P2P functionality in any application, independent of
    the browsers and web servers. Think of "nodes and supernodes", as in
    the original versions of Skype. Or Kazaa if you really want to go
    down memory lane.

    

    -- Christian Huitema

  


--------------D15D009485AAA27FE77D1610--


From nobody Thu Jul 26 17:31:10 2018
Return-Path: 
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 861A7130DC0 for ; Thu, 26 Jul 2018 17:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 kA2Z0vKuVYG2 for ; Thu, 26 Jul 2018 17:31:05 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 0324B1292F1 for ; Thu, 26 Jul 2018 17:31:04 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id f8-v6so3012764ljk.1 for ; Thu, 26 Jul 2018 17:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SZ7zXxEDRsxnVviNGKXjTsRzb6Bp+46am+rjrKb9KBg=; b=vU9V7k0faVzr7ktsiNKLqa6/bhTYn0+YHfzSxpqAxmJBSjZBCOc2TO9A+6QR25NFtG EfR5etime/CscUuDTUuBdY8Hc2PgF852WamaIDVf7oIJF9uaD/9mRCJilEgpFea95hHP i0Q2+3UfzNqoRobQse8+dPAgqDdZXfTR1c7CuivWqgB3myk3aiuxdZt4aUriCKIbM5HQ z4m17Mgb2uDh18LzQFgTYFcgCQumsZRNAS5uAXtZhYQNMU5ED4m+H7cz3EoofY5nFe2H 0mFeJXMF4uiIb5Sm5UfmwxEDSJSfcRgr5VgfILGkA9Ql3mo38E5eVrC/vVUxHjT3Oa/9 97AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SZ7zXxEDRsxnVviNGKXjTsRzb6Bp+46am+rjrKb9KBg=; b=R/TpplAOCut0tsp9BuUTzJoOWzNI7v9fqz5rOAw+ZmHfZ3BgcTgMBIlC+wPTlYhDhO YGEql77vCZwYCLCuF9flJ5gEJa4OjIMAM0oHj7P6+VR3pKnKZKkxDBGxN/NgV1nQ2/Xa 5b0f4p9rdzVI2FoNEeKX41QiSMGdd9+MgYH87Swqw8PA0cYZ46SJwtUr6rwKO7ohs78N JGyDSFOsh2yhlKx1RZqF3O2wz/UOMezhmpaY2yGEpVvqD3W3u3RUkexfhTq3eeV7tegH 5owJ2QqW3dYLe0FvZaiSQZ3bNM6VVfThzQEWDI8hmuuEF8lrtnhOfhkMisSVRtjBMa+9 7vKQ==
X-Gm-Message-State: AOUpUlHoFz6jLwYQmEOpfO3F40OXOm8apThnZTf+bTt3eAT6QimSxslB 3URcRygKMDvVwACAA7pZCDezEms7EZzNDASKVHMCByNx
X-Google-Smtp-Source: AAOMgpfEPjWzyOz25Igmpjx2q144gOChW7suE3sVoWKRM38KTtkDiCv1JnzHf/pXrtxRg+HLmOffY4aatJlpqsNe+18=
X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr3280995lju.77.1532651463222;  Thu, 26 Jul 2018 17:31:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 17:31:02 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Fri, 27 Jul 2018 09:31:02 +0900
Message-ID: 
Subject: Re: Hidden connection spawning
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: IETF QUIC WG , Chris Wood , tpauly@apple.com, dschinazi@apple.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 27 Jul 2018 00:31:08 -0000

2018-07-26 15:31 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> I came to think about a use case where you want to spawn a new connection
> from an existing connection because the new connection runs a different
> protocol. For example a http connection where you  want to run a separate
> live conference call, or to control tunnels from http control connection.
>
> You have roughly three options:
>
> 1. extend the current protocol with the new feature set in extension fram=
es
> or similar
> 2. develop or use a purposes specific QUIC protol using 0-RTT for spawnin=
g
> the connection
> 3. negotiate the new connection handshake within the current handshake.
>
> The first solution is not complex, limited, and not modular.
> The second solution can be used to get information about the connection, =
and
> for example block connections that appear to be doing that.
> The third solution allows for an invisible connection spawn, but requires
> addition handshake logic which is already complex as it is.

I prefer the second approach, since it allows spawning connections in
0-RTT across different transports.

For example, I think that it would be nice to have a way to spawn a
0-RTT HQ connection from a HTTP/2 connection (via alt-svc).

Note also that there is an individual draft submitted to TLSWG that
discusses of adding a way for a TLS server to issue session tickets
that could be context-specific: see
https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/.

>
> I suggesting solution 3 as possible option, although I am not convinced t=
hat
> this is worthwhile, at least in V1.
>
>
> This was in part inspired by recent discussion on tunneling, and in part =
by
> the following issue where partial reliability is being discussed and
> possibly shoe-horned into an extension. I am not following that issue
> closely though - it is just an example.
> https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495
>
>
> Mikkel



--=20
Kazuho Oku


From nobody Thu Jul 26 21:14:30 2018
Return-Path: 
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 85177130EA6 for ; Thu, 26 Jul 2018 21:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 btOF5y0NrSMw for ; Thu, 26 Jul 2018 21:14:17 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 2BEE1130EF4 for ; Thu, 26 Jul 2018 21:14:17 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id n96-v6so2636475lfi.1 for ; Thu, 26 Jul 2018 21:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0Tz9p9oDrAR9prjM7I5yrENUV0rsbpVWeUGLWjQikJI=; b=Prz1Rnrbc8gOOXbuVegC5A808nDoW74xYy6MYiutoCqrKD+EV+udXpy+RCO+x2D+vE 273Dsa6jv+NgdkYSa8pGsDI1BkOUbgODOsBFnGO70zPquqg48LbQLRsrG4BgHxPWt2i0 a2BYCZ59ilU+iIZTPT20GY32kkS97T9u2TXCvPuI+/y9YTUe2YmTVPcBffk/Pj0j3BYb 09YWPYLV7GOxBKpwMm67ctiGTjsDV4ZIQrVKrKC6oTYU65hMbvrqubKQbutQDfyiPwQ5 WS3Au14RLpFtsqxsXVRGQqSESUi6wSOX/KalCcBg2ub+6RG2L/Xv49WmQTTuuWaXvuG8 ooaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0Tz9p9oDrAR9prjM7I5yrENUV0rsbpVWeUGLWjQikJI=; b=Ol2X24C5fevmjeptwMHk6z7KXO1PeF19nc/SCkZhZG39aWG8hoa6IXtAMbQBbg4AXu QQOn8FKq3Z6xijyqkUDEuWB5kkJT916zeg2WjLrKZiF5TmyXYInfBlj/7MuRwTc2ukPR Jo7F+nV5MTOlzFkEhfB77CJHVy6Te/gLkE7nBKmQ6R2Kbq0De1fqBYgyo+tLDg5W/k29 QRP55HcfitOtimB+lVgChlQnGKPtqXHNjE+EEWFrDg4fLeBlRRRyRz6kRDf3Nthzw/Hx I1lzeK6bic7go04r66zHv++sq28k7NfmEimbZcY5AeJgn4xJImknrUZu8DfkwIhCx2/N tEQg==
X-Gm-Message-State: AOUpUlF/D2iR9m7fKnsgxqrVfxtbS4k/2Yi8ifk/gyLVsHRxswvQhV+L DJH5Id07VUbyjv/NGfE9t6k1wIAQV/ZLBYSqzYU=
X-Google-Smtp-Source: AAOMgpc91DkZHczr1TqEMq4LxdaSx//1NOnvCcPd+gQIBrw3gNWWVlKoaLU3vlBKzVM0c3vY/8T29XYrDHOlKili4Kc=
X-Received: by 2002:a19:6b03:: with SMTP id d3-v6mr2741093lfa.81.1532664855402;  Thu, 26 Jul 2018 21:14:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 21:14:14 -0700 (PDT)
In-Reply-To: 
References: 
From: Kazuho Oku 
Date: Fri, 27 Jul 2018 13:14:14 +0900
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 27 Jul 2018 04:14:29 -0000

2018-07-26 15:21 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> I created the following issue a while ago but go no response, so perhaps =
it
> should have been discussed on this list:
>
> https://github.com/quicwg/base-drafts/issues/1578
>
> The issues covers the point, but in summary:
>
> If the packet format is kept as it is today, but the packet number is not
> included in the authenticated data when computing the AEAD tag, then the
> decoder need not modify the received packet buffer when decoding the pack=
et
> number. This can lead to more efficient hardware implementations and make
> multi-processor buffer sharing more effective.

I am not sure if this is a safe change.

What makes me worried is the fact that we will now have at most three
ways of representing a packet. My understanding is that having
indeterministic encoding is considered dangerous in crypto.

Consider the case where a sender encodes a packet number using 4
octets even when just using 1 octet is enough.

An on-path attacker rewrites the packet by applying XOR 0x80 to the
first octet of the encrypted PN, and trimming the latter three octets
of the encrypted PN.

Then, the attacker can observe if the packet is successfully consumed
by the receiver, and use the fact to infer if the upper 6 bits of the
30-bit PN was equal to the least 6 bits.

I am not sure if this attack is interesting, but allowing multiple
representation does create these kind of attack vectors.

>
> Mikkel



--=20
Kazuho Oku


From nobody Fri Jul 27 00:02:51 2018
Return-Path: 
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 977D5130E21 for ; Fri, 27 Jul 2018 00:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 6e6Z70Mqn7dF for ; Fri, 27 Jul 2018 00:02:48 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 5B037130DEC for ; Fri, 27 Jul 2018 00:02:48 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id s7-v6so6249030itb.4 for ; Fri, 27 Jul 2018 00:02:48 -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=p60NrcnjN9R3PE0JOM6Zo6lbGOyPOtdbkPJwBf3m3fs=; b=gYilaMEJIrekeXVR1z7IW4emyaP2vDeCTTW++1Bcs2dkDzCsxMyQhNy0lHMXiFCjxe mr/Fadhi6yJ1X5R3fXvsyCxP6ZyPf0yZHX5l4rtvzkvyejZLvfQ2v0N67Mx7WasLyRO+ M4oe7WD/R2rFUoUTKVxRt0w1spdUIUmUM6MrZPP2ceHj/CAWxxjtkyTab5BVTOH6WPUh hKjeeZHNUiHvobcHquOg/aGlqa5eZ7rayNY+y9ErlnniHg5mK/nQuZcJvvd5pqzJRPM1 nxd76V+ZzPNHEtslmJTN2aR9zseu6Nu/hHFvglld2o97mGG6/p+fdSYQeX9+3xPoH6bk j8Fw==
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=p60NrcnjN9R3PE0JOM6Zo6lbGOyPOtdbkPJwBf3m3fs=; b=eSgYSam5uLsvz/4HCu5FLMbBhxF+/xsU60YPg1y/mIjWrxksTso14SI9JNgbmWSQRe pa9ne5XrT382r0Xh3SimgMpLbl8uDNWNGGGB3OPVFx95L1fj5511vz9KocQcW8xsfxgt dLWS/Z6IKDuiKp0DuSbS9g2ssJ6eHsiIQXtFXL00VDq9fTyZFxBlVkzrcy0+g6jwB11g R6dQ0KTfR7qwf0D1i+uXpUCqf+iZsDOjI2fC/EY0xhoN9QWKBih7BmYCbq/ntqaGzXfR EPXC/ayiuYy1I5CGlSsI083N3oUYshJI99ugUxAM5tQls51jZ7lFPw7d0Maw81fEK5sX Ebyg==
X-Gm-Message-State: AOUpUlE/dhppBxGnWpl3G4u7Q+VA5B76bwa6XZW0OkS4ibY+S7Z+bM+4 JbxgM4xngX+7OyYlByvjzc3e6Rs+WJ2xSohxAfARFw==
X-Google-Smtp-Source: AAOMgpenr2s3BMzM+pfuCQ79MvnzhIC6nihiutWkAc81dd/oWTjCj7fq3ugWMPeC6jBi4+t3J0jviz3vulPP6f744x0=
X-Received: by 2002:a24:5e0b:: with SMTP id h11-v6mr4509498itb.80.1532674967789;  Fri, 27 Jul 2018 00:02:47 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 27 Jul 2018 00:02:46 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:  
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 27 Jul 2018 00:02:46 -0700
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: Kazuho Oku 
Cc: IETF QUIC WG 
Content-Type: multipart/alternative; boundary="00000000000002e3c30571f5b327"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 27 Jul 2018 07:02:51 -0000

--00000000000002e3c30571f5b327
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes ideally you should include the packet length in AEAD, which of course
is the case already for long packet headers.

But on the other hand, it is widely accepted in cryptography that is is
safe to send the IV in clear text, and if isn=E2=80=99t, something else is =
wrong,
so from that point of view there shouldn=E2=80=99t be any dangers. Still it=
 is
mildly disturbing that a verified tag does not correspond to single packet
size.

AES-GCM already includes a length in it=E2=80=99s tag, but it does of cours=
e not
cover content it does not include.

I=E2=80=99m not sure if it is reasonable to require a PN always being sent =
with the
shortest length possible, but it sure would save space on the wire.

Mikkel

On 27 July 2018 at 06.14.16, Kazuho Oku (kazuhooku@gmail.com) wrote:

2018-07-26 15:21 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> I created the following issue a while ago but go no response, so perhaps
it
> should have been discussed on this list:
>
> https://github.com/quicwg/base-drafts/issues/1578
>
> The issues covers the point, but in summary:
>
> If the packet format is kept as it is today, but the packet number is not
> included in the authenticated data when computing the AEAD tag, then the
> decoder need not modify the received packet buffer when decoding the
packet
> number. This can lead to more efficient hardware implementations and make
> multi-processor buffer sharing more effective.

I am not sure if this is a safe change.

What makes me worried is the fact that we will now have at most three
ways of representing a packet. My understanding is that having
indeterministic encoding is considered dangerous in crypto.

Consider the case where a sender encodes a packet number using 4
octets even when just using 1 octet is enough.

An on-path attacker rewrites the packet by applying XOR 0x80 to the
first octet of the encrypted PN, and trimming the latter three octets
of the encrypted PN.

Then, the attacker can observe if the packet is successfully consumed
by the receiver, and use the fact to infer if the upper 6 bits of the
30-bit PN was equal to the least 6 bits.

I am not sure if this attack is interesting, but allowing multiple
representation does create these kind of attack vectors.

>
> Mikkel



--=20
Kazuho Oku

--00000000000002e3c30571f5b327
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Yes ideally you shou=
ld include the packet length in AEAD, which of course is the case already f=
or long packet headers.

But on the other hand, it is widely accepted in cryptography that is is =
safe to send the IV in clear text, and if isn=E2=80=99t, something else is =
wrong, so from that point of view there shouldn=E2=80=99t be any dangers. S=
till it is mildly disturbing that a verified tag does not correspond to sin=
gle packet size.

AES-=
GCM already includes a length in it=E2=80=99s tag, but it does of course no=
t cover content it does not include.

I=E2=80=99m not sure if it is reasonable to require a PN al=
ways being sent with the shortest length possible, but it sure would save s=
pace on the wire.

Mik=
kel
 
On 27 July 2018 at 06.14.16, Kazuho O=
ku (kazuhooku@gmail.com) wrote:<=
/p> 
2018-07-26 15:21 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>:

> I created the following issue a while ago but go no response, so p=
erhaps it

> should have been discussed on this list:

>

> http=
s://github.com/quicwg/base-drafts/issues/1578

>

> The issues covers the point, but in summary:

>

> If the packet format is kept as it is today, but the packet number=
 is not

> included in the authenticated data when computing the AEAD tag, th=
en the

> decoder need not modify the received packet buffer when decoding t=
he packet

> number. This can lead to more efficient hardware implementations a=
nd make

> multi-processor buffer sharing more effective.



I am not sure if this is a safe change.



What makes me worried is the fact that we will now have at most three

ways of representing a packet. My understanding is that having

indeterministic encoding is considered dangerous in crypto.



Consider the case where a sender encodes a packet number using 4

octets even when just using 1 octet is enough.



An on-path attacker rewrites the packet by applying XOR 0x80 to the

first octet of the encrypted PN, and trimming the latter three octets

of the encrypted PN.



Then, the attacker can observe if the packet is successfully consumed

by the receiver, and use the fact to infer if the upper 6 bits of the

30-bit PN was equal to the least 6 bits.



I am not sure if this attack is interesting, but allowing multiple

representation does create these kind of attack vectors.



>

> Mikkel







-- =20

Kazuho Oku



--00000000000002e3c30571f5b327--


From nobody Fri Jul 27 00:07:55 2018
Return-Path: 
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 13FD6130E21 for ; Fri, 27 Jul 2018 00:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level: 
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 mPdO6GyKsD7m for ; Fri, 27 Jul 2018 00:07:52 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 CC503130E3B for ; Fri, 27 Jul 2018 00:07:51 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id w16-v6so6302672ita.0 for ; Fri, 27 Jul 2018 00:07: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=MEwfKybPItA/JCSR7BsImS9J5jZoyT6eK4iWCuTOwnY=; b=hsP10AcE67uR6c5xe13thPqMTCHrSUB5kBNhaQ8Mj09G2C7DEvSWB8GflaOvg1nQuy U1pC1wPglG6s5LI+LNirkbvd+skka+2nrsQkPLOO5Lg4nlyxe4py8IngFMCoVSUNbWwH zHULQQAVZZj5GOqXCOA+coVHUkp7pBfGku/1OM1KqPFSFfx9i2D5SHHGXxI3BGWI39e0 HDfByl6JuIBy1hf6G6kH9wRqNyPZm01cWkz1SbTsFanx6YeOaKD5IZUWMCE8omq3HsXo 63tj1y8E61iefR+H9pt2XCrB2klStKKHtppBe+UmTfrRwgba/aD7xiOwBiMNWLiRxPfQ 1vTw==
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=MEwfKybPItA/JCSR7BsImS9J5jZoyT6eK4iWCuTOwnY=; b=WEhrbjSF2M4JIlgXv9rGopdmIifluO77kpaO3ZVy/ocRsU5GwhzfEQl3giXqxRKhqN HC0cqYY6UoR0iKPPkTUNYVhB7S59k60GcNJA/WrX2P5BYNmNKp5TM61idfIGn+0vZsk7 9P32h/0cf35ujtxgZXciKaAUC98PHGaVKpcKtB1SxYW3JEK4nqkQ1IJvL2iGDIqDxfnL cZH4qTh+xTCLV2/b1WSkdgY+D0A6mnkqJ366ORsi0hTi4quRyHgGWgJTt8jv7emUp4DJ g/AYeCLVZfvJ7aNeQMf5t/jBc85Dh7/OvR0Ng9UU0Rw0gWSeDRgFGMJ0itN6FKOK4rW+ HMCw==
X-Gm-Message-State: AOUpUlEaCe/wXRYcB9zLH+FlCbOgtLHO8XXCDjSvd7dRe1ZQw63JseAa eqeF7rzj5YV0j1Wo40/UZQvC4ruyzfB3PeY9gfc=
X-Google-Smtp-Source: AAOMgpdFmYV/X6Kc9m+ucuG6rBv11HeThUmraHX5nVMd2bDkpoUxBTdrAuBYOBBs0n2l81JvDJOl4UO+LergofklhOQ=
X-Received: by 2002:a02:8c75:: with SMTP id j50-v6mr5032517jal.76.1532675271280;  Fri, 27 Jul 2018 00:07:51 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 27 Jul 2018 00:07:50 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:  
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Fri, 27 Jul 2018 00:07:50 -0700
Message-ID: 
Subject: Re: Hidden connection spawning
To: Kazuho Oku 
Cc: Chris Wood , tpauly@apple.com, IETF QUIC WG , dschinazi@apple.com
Content-Type: multipart/alternative; boundary="00000000000019ccfb0571f5c5ee"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 27 Jul 2018 07:07:54 -0000

--00000000000019ccfb0571f5c5ee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

When you say you prefer option 2 (0-RTT), do you mean to not hide the
handshake, or do you mean the until now unlisted option 4:

4. carry out a full 0-RTT handshake over a separate secure channel (QUIC or
otherwise)

Option 4 may skip the QUIC encryption layer if the outer layer is equally
strong (this is a can of worms).


Correction: in my earlier mail I wrote =E2=80=9Cnot complex=E2=80=9D in rel=
ation to option
1, the =E2=80=9Cnot=E2=80=9D should not have been there.

On 27 July 2018 at 02.31.03, Kazuho Oku (kazuhooku@gmail.com) wrote:

2018-07-26 15:31 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> I came to think about a use case where you want to spawn a new connection
> from an existing connection because the new connection runs a different
> protocol. For example a http connection where you want to run a separate
> live conference call, or to control tunnels from http control connection.
>
> You have roughly three options:
>
> 1. extend the current protocol with the new feature set in extension
frames
> or similar
> 2. develop or use a purposes specific QUIC protol using 0-RTT for
spawning
> the connection
> 3. negotiate the new connection handshake within the current handshake.
>
> The first solution is not complex, limited, and not modular.
> The second solution can be used to get information about the connection,
and
> for example block connections that appear to be doing that.
> The third solution allows for an invisible connection spawn, but requires
> addition handshake logic which is already complex as it is.

I prefer the second approach, since it allows spawning connections in
0-RTT across different transports.

For example, I think that it would be nice to have a way to spawn a
0-RTT HQ connection from a HTTP/2 connection (via alt-svc).

Note also that there is an individual draft submitted to TLSWG that
discusses of adding a way for a TLS server to issue session tickets
that could be context-specific: see
https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/.

>
> I suggesting solution 3 as possible option, although I am not convinced
that
> this is worthwhile, at least in V1.
>
>
> This was in part inspired by recent discussion on tunneling, and in part
by
> the following issue where partial reliability is being discussed and
> possibly shoe-horned into an extension. I am not following that issue
> closely though - it is just an example.
> https://github.com/quicwg/base-drafts/issues/1606#issuecomment-407951495
>
>
> Mikkel



--=20
Kazuho Oku

--00000000000019ccfb0571f5c5ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
When you say you pre=
fer option 2 (0-RTT), do you mean to not hide the handshake, or do you mean=
 the until now unlisted option 4:

4. carry out a full 0-RTT handshake over a separate secure c=
hannel (QUIC or otherwise)

Option 4 may skip the QUIC encryption layer if the outer layer is equ=
ally strong (this is a can of worms).
 


Correction: in my earlier mail I wrote =E2=80=9Cnot complex=E2=80=9D in r=
elation to option 1, the =E2=80=9Cnot=E2=80=9D should not have been there.<=
/div>
 
On 27 July 2018 at 02.31.03, Kazuho=
 Oku (kazuhooku@gmail.com) wrote=
:
 
2018-07-26 15:31 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>:

> I came to think about a use case where you want to spawn a new con=
nection

> from an existing connection because the new connection runs a diff=
erent

> protocol. For example a http connection where you  want to run a s=
eparate

> live conference call, or to control tunnels from http control conn=
ection.

>

> You have roughly three options:

>

> 1. extend the current protocol with the new feature set in extensi=
on frames

> or similar

> 2. develop or use a purposes specific QUIC protol using 0-RTT for =
spawning

> the connection

> 3. negotiate the new connection handshake within the current hands=
hake.

>

> The first solution is not complex, limited, and not modular.

> The second solution can be used to get information about the conne=
ction, and

> for example block connections that appear to be doing that.

> The third solution allows for an invisible connection spawn, but r=
equires

> addition handshake logic which is already complex as it is.



I prefer the second approach, since it allows spawning connections in

0-RTT across different transports.



For example, I think that it would be nice to have a way to spawn a

0-RTT HQ connection from a HTTP/2 connection (via alt-svc).



Note also that there is an individual draft submitted to TLSWG that

discusses of adding a way for a TLS server to issue session tickets

that could be context-specific: see

https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/.



>

> I suggesting solution 3 as possible option, although I am not conv=
inced that

> this is worthwhile, at least in V1.

>

>

> This was in part inspired by recent discussion on tunneling, and i=
n part by

> the following issue where partial reliability is being discussed a=
nd

> possibly shoe-horned into an extension. I am not following that is=
sue

> closely though - it is just an example.

> https://github.com/quicwg/base-drafts/issues/1606#issuec=
omment-407951495

>

>

> Mikkel







-- =20

Kazuho Oku



--00000000000019ccfb0571f5c5ee--


From nobody Fri Jul 27 06:43:49 2018
Return-Path: 
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 A3956130F88 for ; Fri, 27 Jul 2018 06:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 joRZw0LWNeSn for ; Fri, 27 Jul 2018 06:43:35 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62411130FC2 for ; Fri, 27 Jul 2018 06:43:33 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fj31l-0000jk-9u for quic@ietf.org; Fri, 27 Jul 2018 15:43:30 +0200
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fj31g-0004Ka-Vw for quic@ietf.org; Fri, 27 Jul 2018 09:43:25 -0400
Received: (qmail 19053 invoked from network); 27 Jul 2018 13:43:21 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.39.156]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Jul 2018 13:43:21 -0000
To: Kazuho Oku , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= 
Cc: IETF QUIC WG 
References:  
From: Christian Huitema 
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
Date: Fri, 27 Jul 2018 06:43:22 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: Packet Number Encryption outside of AEAD
X-Originating-IP: 168.144.250.231
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5sAWxx+raDIKj4lxLTm7F3N602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViSSeRRXp+kIstRaiReIekXs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1VzUjpi3KNxdQZ39cmOPHk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaKFx/oZIYfnv6X4HqmwQedqF8FcHzzV3acxBudgYcInb9GkghycT1df ko8m/t56ZgyZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZN1zg8T9ahw4hquQDupK1jlwBl1z1+w2zS/h3e6UiVRcINLwG6Bo+JaQM +C8JASYyS//k0VHDkAzPFlaOxUvkWmeqA47D/juB1cx4exzYk7wfjirBnMSvLt+oZCsKZvqt647l NwN4qOsSZg+fYhVZG9EQ9b9YI+9ZsqMLtlmzzH7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 27 Jul 2018 13:43:48 -0000

On 7/26/2018 9:14 PM, Kazuho Oku wrote:
> Consider the case where a sender encodes a packet number using 4
> octets even when just using 1 octet is enough.
>
> An on-path attacker rewrites the packet by applying XOR 0x80 to the
> first octet of the encrypted PN, and trimming the latter three octets
> of the encrypted PN.
That attack does not work, because the encoding of the PN is big-endian.
The actual packet number is in the fourth octet. Or rather, it only
works in the special case where the PN is 0.

-- Christian Huitema


From nobody Fri Jul 27 15:11:45 2018
Return-Path: 
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 B667712E039 for ; Fri, 27 Jul 2018 15:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 dWUcNC_Ddzvs for ; Fri, 27 Jul 2018 15:11:43 -0700 (PDT)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FFA12DD85 for ; Fri, 27 Jul 2018 15:11:43 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2018 15:11:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.51,411,1526367600"; d="scan'208";a="219726300"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga004.jf.intel.com with ESMTP; 27 Jul 2018 15:11:32 -0700
Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 27 Jul 2018 15:11:32 -0700
Received: from orsmsx111.amr.corp.intel.com ([169.254.12.141]) by ORSMSX153.amr.corp.intel.com ([169.254.12.164]) with mapi id 14.03.0319.002; Fri, 27 Jul 2018 15:11:32 -0700
From: "Deval, Manasi" 
To: Christian Huitema , Kazuho Oku ,  =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= 
CC: IETF QUIC WG 
Subject: RE: Packet Number Encryption outside of AEAD
Thread-Topic: Packet Number Encryption outside of AEAD
Thread-Index: AQHUJKkAtask1KfWg0ikoziD8HV0hqSi7JQAgACfBAD//7ZHcA==
Date: Fri, 27 Jul 2018 22:11:31 +0000
Message-ID: <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
In-Reply-To: <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZGZjY2MzYTgtYTcyYi00OTQ2LTgyNGYtZTU4NDNkZDFhYjkxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRFg1V1wvVjE1SXhjUDQxb2diUE5FOW4xVWJJdm90TE9ZNDlGM0FKNzY2eTQ5dXJTZ2pBWklPbmNRR3VBd0FpVnEifQ==
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [10.22.254.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: quic@ietf.org
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: Fri, 27 Jul 2018 22:11:45 -0000

QWJvdXQgdGhlIGlzc3VlIG9mIFBhY2tldCBOdW1iZXIgRW5jcnlwdGlvbiBvdXRzaWRlIG9mIEFF
QUQgLSBXZSBhZ3JlZSBpdCBzaW1wbGlmaWVzIGJvdGggaGFyZHdhcmUgYW5kIHNvZnR3YXJlIGxv
Z2ljLiBJdCBhbHNvIGFsbG93cyB0aGUyIGVuY3J5cHRpb24gb3BlcmF0aW9ucyB0byBydW4gbW9z
dGx5IGluIHBhcmFsbGVsLCBzbyBpdCBpcyBhIHdlbGNvbWUgbW9kaWZpY2F0aW9uLg0KDQpUaGFu
a3MsDQpNYW5hc2kNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBb
bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0
ZW1hDQpTZW50OiBGcmlkYXksIEp1bHkgMjcsIDIwMTggNjo0MyBBTQ0KVG86IEthenVobyBPa3Ug
PGthenVob29rdUBnbWFpbC5jb20+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxm
akBnbWFpbC5jb20+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDog
UmU6IFBhY2tldCBOdW1iZXIgRW5jcnlwdGlvbiBvdXRzaWRlIG9mIEFFQUQNCg0KDQoNCk9uIDcv
MjYvMjAxOCA5OjE0IFBNLCBLYXp1aG8gT2t1IHdyb3RlOg0KPiBDb25zaWRlciB0aGUgY2FzZSB3
aGVyZSBhIHNlbmRlciBlbmNvZGVzIGEgcGFja2V0IG51bWJlciB1c2luZyA0DQo+IG9jdGV0cyBl
dmVuIHdoZW4ganVzdCB1c2luZyAxIG9jdGV0IGlzIGVub3VnaC4NCj4NCj4gQW4gb24tcGF0aCBh
dHRhY2tlciByZXdyaXRlcyB0aGUgcGFja2V0IGJ5IGFwcGx5aW5nIFhPUiAweDgwIHRvIHRoZQ0K
PiBmaXJzdCBvY3RldCBvZiB0aGUgZW5jcnlwdGVkIFBOLCBhbmQgdHJpbW1pbmcgdGhlIGxhdHRl
ciB0aHJlZSBvY3RldHMNCj4gb2YgdGhlIGVuY3J5cHRlZCBQTi4NClRoYXQgYXR0YWNrIGRvZXMg
bm90IHdvcmssIGJlY2F1c2UgdGhlIGVuY29kaW5nIG9mIHRoZSBQTiBpcyBiaWctZW5kaWFuLg0K
VGhlIGFjdHVhbCBwYWNrZXQgbnVtYmVyIGlzIGluIHRoZSBmb3VydGggb2N0ZXQuIE9yIHJhdGhl
ciwgaXQgb25seQ0Kd29ya3MgaW4gdGhlIHNwZWNpYWwgY2FzZSB3aGVyZSB0aGUgUE4gaXMgMC4N
Cg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0K


From nobody Sat Jul 28 05:35:13 2018
Return-Path: 
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 DCB8D130F36 for ; Sat, 28 Jul 2018 05:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 tejOVzKDQ-0O for ; Sat, 28 Jul 2018 05:35:09 -0700 (PDT)
Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 3E952130EDB for ; Sat, 28 Jul 2018 05:35:09 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id j19-v6so6661584ljc.7 for ; Sat, 28 Jul 2018 05:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a19U3jSemwzpgCupG/UnP8G1PEvi0LfhxTbPA3Uqu3A=; b=Z7pFEoXhANgl+yYhTmMlyJyFr/gVA4t7MVBq+25SMp6N6ct0RxoECrWTbFPCIaGqKq istvxhFahmq9YtNqfWVa0aSJ07ETr3yIoi9WiBjrP8p3e3CzrL9sC5xE0IJi4d38EcNs hcRbONKz49cj0LRfCu4WRjuVfFnvB3LP6YVX7IOryVoCvhUHZvCoGRZ9NzIRIV0vymmH ndDYzeS20rIZceaFLjjbPJx1tvsb6gKKEvObaHuRKc7CqJOzJcBnGfVz5C24zEMWzX94 4yu9hh1HVxU3WL99gutf9Bb7bhcThEo1nB8QtIKf/YAeegFDKj07eKXvS7HuG/p2NtOM or+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a19U3jSemwzpgCupG/UnP8G1PEvi0LfhxTbPA3Uqu3A=; b=qaHD03i/7xXImGZVohvSuqi8bO/Y9SzBrToTtFARZJU2Yz5gPh/bt0mvFshNHFD56h SnV1QtcgJ9NEUsFJb3nhQ9VHk5a3YKvtqihr4xF7GEySvFrEeB8ctdeb9IoMS0F3F3r1 093d8dtFfYr71PeXDaGulYl0fwN1O/SNlRkht2UHYrIFFJVR5rby11kvIP05n7D6qtno d82/04XGDSzd6ucDCRtToGk3kOGqJv/sGtfOpqlvDOcQfsl43hm7V0wKHQ/F1egVow91 f70VOE2pl0WVtaeHlwwH/Yx9INRSGpXMLRLrojSxFJtXE0CgAjxgsYh96R1rSxziotQF +c3A==
X-Gm-Message-State: AOUpUlGkEKTsHqFiqTnTnbUQww4vXNdkCWuk6HBYxugnwabexkueWZyj 9mAUzYmcqg/JmQFN5Q6fkSbLvSBMGgNibuDjsJ4=
X-Google-Smtp-Source: AAOMgpcyLGCA3KXq5Uf882ZvjPn1QUvbT/c1WmcH3nSTVhHV2XMofFHgFC+rNiPGWfRTZ1o5Qy3ND3eKEfi8OIhdh9I=
X-Received: by 2002:a2e:4e02:: with SMTP id c2-v6mr7471931ljb.108.1532781307469;  Sat, 28 Jul 2018 05:35:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 05:35:06 -0700 (PDT)
In-Reply-To: <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net>
From: Kazuho Oku 
Date: Sat, 28 Jul 2018 21:35:06 +0900
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: Christian Huitema 
Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 12:35:11 -0000

2018-07-27 22:43 GMT+09:00 Christian Huitema :
>
>
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>>
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.

I do not see how the issue relates to the endianness.

Consider the following case.

encrypted PN + payload: 46 5f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f 10 11
AES-CTR mask for PN: c5 5c

The PN field after decryption is 83 03. IV used for PNE is 02 03 .. 11.

Attacker applies XOR 0x80 (to change the PN field length from 2 to 1)
and removes the second octet.

The modified encrypted PN + payload becomes: c6 00 01 02 03 04 05 06
07 08 09 0a 0b 0c 0d 0e 0f 10 11.

The PN field after decryption is 03, and IV used for PNE is 02 03 .. 11.

In such case, the receiver will successfully process the modified
input if the PN was expressible using one octet, thereby leaking the
fact that the first 6 bits of the 16-bit PN was equal to the least
significant 6 bits of the PN and that the 7th and 8th bits were zero.

Admittedly, this attack relies on the fact that the frames contained
in the packet are 2 octets. But I am not sure if this is the _only_
attack that is possible.

Am I missing something?


Besides, note also that the proposed change will prevent us from using
the PNE key to encrypt other information. For example, in #1322, we
have been discussing about how to protect the key-phase bit. It seemed
to me that we were leaning towards encrypting the key-phase bit using
the PNE key. That would no longer be possible (or lead to other
security concerns) if we adopt this proposal.

>
> -- Christian Huitema



-- 
Kazuho Oku


From nobody Sat Jul 28 06:16:09 2018
Return-Path: 
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 091D6130EA3 for ; Sat, 28 Jul 2018 06:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 firorite0JWe for ; Sat, 28 Jul 2018 06:16:05 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 F38B1130E8C for ; Sat, 28 Jul 2018 06:16:04 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id r13-v6so6723915ljg.10 for ; Sat, 28 Jul 2018 06:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2ZTLiP1tGVL6iD72wpZ5OYMQ6I7R7BSmrhsD6/Yuo44=; b=OO+wzydVQUU5KDm0Uubh6eDJIaVs/dFtEgUexYnZBkrFRpQgcKgOZZgmqJj+Y0S/7h kC3/PAiOHZn/MJiEBsEZbN+VNtDyKGmukecOeuqp8bH76ri6K3/uk8c8+qB1NVDLTjuM 5Ty3jJoXVkWLUZWQOYuHmiKO5m+SMmHjhPONmrOpsFYyCZqCZjLXBmOWdG2XeDpOuGSw 6CeRabBYYIVLu6U7zxWeRcxy/1E2KrDTTIcNEQMjNCqojFx9rxNM837l3zrZXC8ah1F3 wEeDFUHY8AQzaOx4Id55tecGc3PFUd7GEzKRMgui3P5QC/BXqNBtzsmY7V8TEHMOdBna 8osw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2ZTLiP1tGVL6iD72wpZ5OYMQ6I7R7BSmrhsD6/Yuo44=; b=FQ78oisrirqbinX09IqRP9g5SlEyOhMQ0zXVbUKkYqTrg34ogsGB7GEnO2DyrXxiK2 qZCAjSxsoS4sxyiFSsfB/t+MHQ306EFtiDiXu2no3h23vUJ+Ub0ZjukHD8CvCXCsOHBg c4tznTQLLhFFiTgLLbkjZlfO5YCU9FtEPe/iM28PqZV+AsgIdM4SkgLggX7oZZ6i/z9N +sMt7WnnGKm5TqsOcmRZMhsAhiY2swHRiFSOqsVmaS3Xgb+1yZAM5cgYnsbo/fDQ1a6l xIJHw7srV4dQLERMqe0s04ju+7gHq5iAQxqtRwCp75Cr9hY04tjv/8sh5ccGl6Anww33 P7UA==
X-Gm-Message-State: AOUpUlGf+igsAPlY5OiomCjUR5JHn3bdCgPbdSl9M+YTIkYDHYHfgFge 0Az4MEdKWzpnpcpDCW10mVCkfpRW3lCWmQHOD48=
X-Google-Smtp-Source: AAOMgpftZzG3vQ9hOEn2bnSQXH1BpTfCtnvEre5DxzN6eAbZKVk05KfSaY6/XA+PtbAl32aM8yLWiFOFlbRzW6eWU60=
X-Received: by 2002:a2e:8147:: with SMTP id t7-v6mr8314909ljg.32.1532783763277;  Sat, 28 Jul 2018 06:16:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 06:16:02 -0700 (PDT)
In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>
From: Kazuho Oku 
Date: Sat, 28 Jul 2018 22:16:02 +0900
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: "Deval, Manasi" 
Cc: Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= ,  IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 13:16:07 -0000

2018-07-28 7:11 GMT+09:00 Deval, Manasi :
> About the issue of Packet Number Encryption outside of AEAD - We agree it=
 simplifies both hardware and software logic. It also allows the2 encryptio=
n operations to run mostly in parallel, so it is a welcome modification.

Would you mind elaborating a bit on how the proposed change would help
parallelization?

My understanding is that it does not help parallelizing "encryption",
because the only change is if you have the cleartext PN (which is
something you can prepare beforehand) as part of the AAD.

I also do not understand how it helps parallelizing decryption in practice.

The proposed change removes cleartext PN from AAD. It sounds like that
you would then have a chance to start processing AAD for GCM. But I am
not sure if that is correct.

In the current approach, input to GCM is: GCM(first-octet || CID ||
plaintext-PN || payload).

With the proposed change, it becomes: GCM(fist-octet || CID || payload).

Because where the payload begins depends on the value of the PN being
decrypted, in both cases you have the same degree of parallelism. You
can process GCM to the end of CID, but no more.

To conclude, I do not see how the proposed change helps parallelize
the encoder or the decoder.

> Thanks,
> Manasi
>
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Friday, July 27, 2018 6:43 AM
> To: Kazuho Oku ; Mikkel Fahn=C3=B8e J=C3=B8rgensen <=
mikkelfj@gmail.com>
> Cc: IETF QUIC WG 
> Subject: Re: Packet Number Encryption outside of AEAD
>
>
>
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>>
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.
>
> -- Christian Huitema
>



--=20
Kazuho Oku


From nobody Sat Jul 28 06:44:41 2018
Return-Path: 
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 0A784130EB7 for ; Sat, 28 Jul 2018 06:44:40 -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 H-C4zfts62_s for ; Sat, 28 Jul 2018 06:44:37 -0700 (PDT)
Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 1CFFF130DD4 for ; Sat, 28 Jul 2018 06:44:37 -0700 (PDT)
Received: by mail-it0-x243.google.com with SMTP id g191-v6so414324ita.0 for ; Sat, 28 Jul 2018 06:44:37 -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=oOZmS30BwzRb4/sie7tkGMBFEB/s+T2V83tveyOn70s=; b=avcNo9RQEnZ3akg3NJHlZp/iJUzY6qZYtZVl0e5/HQhDoD85eljxFU6jnFplzAINGC IrSEVjZcqXgHiD5zjL3FLm9IS9IQAFI9wNI6B2AnB41ZqPaK62Lk/jTHUz/2m23LE29E YFgjBgNtmgXIDTRb5fRd1t7YTMkAYr5rJ4VnexF6z4B4pxnkG+vcf0T2HwYqi5pr5w17 A60rxpcR5MqPedaUT8+FGfVM6SrF6IApa0Ru6ll2Jk2+Io7VS/XTo3rZb5lzps+x6e2j 9+4sUqv5aPgxJqBUnC/5fsnH7hipk7r7yb/A+xr60v7oZimL/OjzYuZ1h7N0fKHPUDRI VtwQ==
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=oOZmS30BwzRb4/sie7tkGMBFEB/s+T2V83tveyOn70s=; b=bGzFyjQTD9RoipR76lblSQYCtfXB0Z+9LT5n+MncNy50JXdwQNtFJoaiXY4R48gj6/ oqreQyFcrXD+7MTZ++492vX/VTuSlhmZW01uORO5shXtg+gPRk8oCUh/mk0xNgwKklZi 2NB22hrk23krUkXaHhkIWPx8rZgE+TGDGhtDDJtg0abLFPSQhNStPkxVtiD8+w4jkNh5 SGHR6dRc8KqqGNjUegxPHRQ7XwTqW1n7mV665IcUl8JnVyyzqv77cSJK5+E2d7wCS84q ZQw2DpZoZ2qoKvomyNE7rVzY2Fk43uKxJyNiaEueP+tR3LYp0hbCOtqulqEX8/wrGye+ Nk9A==
X-Gm-Message-State: AOUpUlGWIYOQuJL163kFlu/4zQX1g4DdJZ+BboKVNggb5pv0C4JwZibW 3FeJ4327B9O5VfT4W6/GaidJqM9tng2XUWHLnQO/ZA==
X-Google-Smtp-Source: AAOMgpfAwd4H6vfqng02c8C8hI7ga56pzOhu7vFET0KTq/h6dB19SFFTFmPAqJzJCWbu6VTN6i69DBt1n89N7pVq8QA=
X-Received: by 2002:a02:8c3c:: with SMTP id l57-v6mr10050203jak.57.1532785476367;  Sat, 28 Jul 2018 06:44:36 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 28 Jul 2018 06:44:35 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: 
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com> 
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sat, 28 Jul 2018 06:44:35 -0700
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: "Deval, Manasi" , Kazuho Oku 
Cc: Christian Huitema , IETF QUIC WG 
Content-Type: multipart/alternative; boundary="000000000000d60a3805720f6dbb"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 13:44:40 -0000

--000000000000d60a3805720f6dbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You can have one core with access to an input queue that does nothing but
decrypting packet numbers.
The decrypted PN=E2=80=99s are placed on a queue.
Meanwhile one or several other cores verify the AEAD tag and places
validation on a queue.
A third set of cores processes decryption and places decrypted packets on a
queue. High priority frames are read from the decrypted packet queue and
processed, pending tag confirmation.
A fourth set of cores deal with ACK processing and other packet number
sensitive content.

If the original receive buffer needs to be modified, you first incur the
PNE decryption delay, then you force a possibly shared cache line into
exclusive mode by writing to the buffer. The separate concurrent stages now
not only have to wait for PNE, but also for the inter-processor cache
coherency synchronisation to take effect.

For encoding there are fewer benefits, but one is that you can encrypt
buffers without deciding the packet number immediately. This might be
helpful if sending via multiple cores feeding to a final transmit process
that synchronises packet numbers and applies PNE before sending data on the
wire.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:

2018-07-28 7:11 GMT+09:00 Deval, Manasi :
> About the issue of Packet Number Encryption outside of AEAD - We agree it
simplifies both hardware and software logic. It also allows the2 encryption
operations to run mostly in parallel, so it is a welcome modification.

Would you mind elaborating a bit on how the proposed change would help
parallelization?

My understanding is that it does not help parallelizing "encryption",
because the only change is if you have the cleartext PN (which is
something you can prepare beforehand) as part of the AAD.

I also do not understand how it helps parallelizing decryption in practice.

The proposed change removes cleartext PN from AAD. It sounds like that
you would then have a chance to start processing AAD for GCM. But I am
not sure if that is correct.

In the current approach, input to GCM is: GCM(first-octet || CID ||
plaintext-PN || payload).

With the proposed change, it becomes: GCM(fist-octet || CID || payload).

Because where the payload begins depends on the value of the PN being
decrypted, in both cases you have the same degree of parallelism. You
can process GCM to the end of CID, but no more.

To conclude, I do not see how the proposed change helps parallelize
the encoder or the decoder.

> Thanks,
> Manasi
>
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Friday, July 27, 2018 6:43 AM
> To: Kazuho Oku ; Mikkel Fahn=C3=B8e J=C3=B8rgensen <
mikkelfj@gmail.com>
> Cc: IETF QUIC WG 
> Subject: Re: Packet Number Encryption outside of AEAD
>
>
>
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>>
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.
>
> -- Christian Huitema
>



--=20
Kazuho Oku

--000000000000d60a3805720f6dbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
You can have one cor=
e with access to an input queue that does nothing but decrypting packet num=
bers.
The dec=
rypted PN=E2=80=99s are placed on a queue.
Meanwhile one or several other cores verify t=
he AEAD tag and places validation on a queue.
A third set of cores processes decryption =
and places decrypted packets on a queue. High priority frames are read from=
 the decrypted packet queue and processed, pending tag confirmation.
<=
div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:=
13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">A fourth set of cor=
es deal with ACK processing and other packet number sensitive content.

If the original receive b=
uffer needs to be modified, you first incur the PNE decryption delay, then =
you force a possibly shared cache line into exclusive mode by writing to th=
e buffer. The separate concurrent stages now not only have to wait for PNE,=
 but also for the inter-processor cache coherency synchronisation to take e=
ffect.

For encoding t=
here are fewer benefits, but one is that you can encrypt buffers without de=
ciding the packet number immediately. This might be helpful if sending via =
multiple cores feeding to a final transmit process that synchronises packet=
 numbers and applies PNE before sending data on the wire.

 
 
Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen
 
On 28 July 2018 at 15.16.03, Kazu=
ho Oku (kazuhooku@gmail.com) wro=
te:
 
=

2018-07-28 7:11 GMT+09:00 Deval, Manasi <manasi.deval@intel.com>:

> About the issue of Packet Number Encryption outside of AEAD - We a=
gree it simplifies both hardware and software logic. It also allows the2 en=
cryption operations to run mostly in parallel, so it is a welcome modificat=
ion.



Would you mind elaborating a bit on how the proposed change would help

parallelization?



My understanding is that it does not help parallelizing "encryptio=
n",

because the only change is if you have the cleartext PN (which is

something you can prepare beforehand) as part of the AAD.



I also do not understand how it helps parallelizing decryption in pract=
ice.



The proposed change removes cleartext PN from AAD. It sounds like that

you would then have a chance to start processing AAD for GCM. But I am

not sure if that is correct.



In the current approach, input to GCM is: GCM(first-octet || CID ||

plaintext-PN || payload).



With the proposed change, it becomes: GCM(fist-octet || CID || payload)=
.



Because where the payload begins depends on the value of the PN being

decrypted, in both cases you have the same degree of parallelism. You

can process GCM to the end of CID, but no more.



To conclude, I do not see how the proposed change helps parallelize

the encoder or the decoder.



> Thanks,

> Manasi

>

>

> -----Original Message-----

> From: QUIC [mailto:quic-b=
ounces@ietf.org] On Behalf Of Christian Huitema

> Sent: Friday, July 27, 2018 6:43 AM

> To: Kazuho Oku <kazuhook=
u@gmail.com>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>

> Cc: IETF QUIC WG <quic@ietf.or=
g>

> Subject: Re: Packet Number Encryption outside of AEAD

>

>

>

> On 7/26/2018 9:14 PM, Kazuho Oku wrote:

>> Consider the case where a sender encodes a packet number using=
 4

>> octets even when just using 1 octet is enough.

>>

>> An on-path attacker rewrites the packet by applying XOR 0x80 t=
o the

>> first octet of the encrypted PN, and trimming the latter three=
 octets

>> of the encrypted PN.

> That attack does not work, because the encoding of the PN is big-e=
ndian.

> The actual packet number is in the fourth octet. Or rather, it onl=
y

> works in the special case where the PN is 0.

>

> -- Christian Huitema

>







-- =20

Kazuho Oku



--000000000000d60a3805720f6dbb--


From nobody Sat Jul 28 07:24:16 2018
Return-Path: 
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 6F43C130E1E for ; Sat, 28 Jul 2018 07:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 xdrkR5N2KgC2 for ; Sat, 28 Jul 2018 07:24:13 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 C7655130DE1 for ; Sat, 28 Jul 2018 07:24:12 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id w16-v6so3222829ljh.12 for ; Sat, 28 Jul 2018 07:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YJZpOMXyn0jYdau78layerTBt+evLMijT2JKUtTTZsE=; b=gYkMvCcImVlkHzgLYpcaoNL9LumKtKk9m3wh3Oex7Okvht30rJ1SLVy/0ID1EY9rz9 a7RwZcpCSnbsgdeNsVWtYNy59c3ytJnj7tE9kISlMtePGtjd6m49rR6h9j2q7Uu8pMzp 126G9weU+TFn/Hf9wj+NIQlDaHhZnM/P5pfKy0kjs4uqcc7Tib2uVSkQFHNZI3zcyf0f wK+MqzI6CYiadU2sUXQmV5+mgCw/6kdu8lzKY4mxHMSS0hGubpyAUsu573NdnkFu1dNc XUhwMJMiYwKDfbEQnBePS+iOV3hODyKc6iiqLzuPA9oqbesQwdrqFK4eFY/2wcXUYcRx L1Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YJZpOMXyn0jYdau78layerTBt+evLMijT2JKUtTTZsE=; b=hflaH2cUcmmGUAmabwLenPEDcWloF8kOz6LNpocRWNmPTB3UlwGsVQkVwFQRsRb+DV HjtTYvf0HSCWWpGSctqgNEAQgivLobS+vBvPgLhazqFBRCGSu3dX+CaJBSurvAvHYnXs PazwsO4+lFC6Xzv/BQWlDXZzQS5pdoiQ/lv5nk4osSHuwl2drgg/0CcVPVXQBkVeE/HC nvhhLrLZ6nUf6uw1qlSKmpK2z8YXh1l4+gMFTEQ6lN4Ku9K39z3phuqK7BNB29OVJOW5 j+DlgnHtwsGWYeKYIbhXHWi4v5lwznlBlxERIFlZfHU5Qifsj13UUcoTgNEpC3mKUAfg COXQ==
X-Gm-Message-State: AOUpUlE8yxOCq5mz10UJgHcAIA5iuXIz1qBRrrriAJ5VPMEeM1nPOebm 2s61/bV8yQjwCNs8crL48hxpJ39gv9ySK9VPP0ywgA==
X-Google-Smtp-Source: AAOMgpcKgyyn7KV3oSiDHAx2KBrT8ZgBAKIVOlJuxd6y7P0PKLDhSzxEUEv8hb0OCHNzv08tE1YMKwmYxd/nfH3UU5U=
X-Received: by 2002:a2e:2e02:: with SMTP id u2-v6mr8260545lju.77.1532787851141;  Sat, 28 Jul 2018 07:24:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 07:24:10 -0700 (PDT)
In-Reply-To: 
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>  
From: Kazuho Oku 
Date: Sat, 28 Jul 2018 23:24:10 +0900
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: "Deval, Manasi" , Christian Huitema , IETF QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 14:24:16 -0000

2018-07-28 22:44 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> You can have one core with access to an input queue that does nothing but
> decrypting packet numbers.
> The decrypted PN=E2=80=99s are placed on a queue.
> Meanwhile one or several other cores verify the AEAD tag and places
> validation on a queue.

My point is that you cannot run PN decryption and AEAD tag
verification in parallel, because the input to GCM, specifically the
beginning offset of the ciphertext, depends on the length of the PN
field, a value that becomes available only after decrypting the PN
field.

The input that can be given to GCM is the first octet and CID,
regardless of the proposed change.

In the current approach, GCM calculation needs to wait for the result
of PN decryption, because it is the value that is fed to GCM following
the CID.

With the proposed change, GCM calculation still needs to wait for the
result of the PN decryption to determine where the ciphertext begins,
because the ciphertext is fed the thing that is fed to GCM following
the CID.

> A third set of cores processes decryption and places decrypted packets on=
 a
> queue. High priority frames are read from the decrypted packet queue and
> processed, pending tag confirmation.
> A fourth set of cores deal with ACK processing and other packet number
> sensitive content.
>
> If the original receive buffer needs to be modified, you first incur the =
PNE
> decryption delay, then you force a possibly shared cache line into exclus=
ive
> mode by writing to the buffer. The separate concurrent stages now not onl=
y
> have to wait for PNE, but also for the inter-processor cache coherency
> synchronisation to take effect.
>
> For encoding there are fewer benefits, but one is that you can encrypt
> buffers without deciding the packet number immediately. This might be
> helpful if sending via multiple cores feeding to a final transmit process
> that synchronises packet numbers and applies PNE before sending data on t=
he
> wire.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
> On 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:
>
> 2018-07-28 7:11 GMT+09:00 Deval, Manasi :
>> About the issue of Packet Number Encryption outside of AEAD - We agree i=
t
>> simplifies both hardware and software logic. It also allows the2 encrypt=
ion
>> operations to run mostly in parallel, so it is a welcome modification.
>
> Would you mind elaborating a bit on how the proposed change would help
> parallelization?
>
> My understanding is that it does not help parallelizing "encryption",
> because the only change is if you have the cleartext PN (which is
> something you can prepare beforehand) as part of the AAD.
>
> I also do not understand how it helps parallelizing decryption in practic=
e.
>
> The proposed change removes cleartext PN from AAD. It sounds like that
> you would then have a chance to start processing AAD for GCM. But I am
> not sure if that is correct.
>
> In the current approach, input to GCM is: GCM(first-octet || CID ||
> plaintext-PN || payload).
>
> With the proposed change, it becomes: GCM(fist-octet || CID || payload).
>
> Because where the payload begins depends on the value of the PN being
> decrypted, in both cases you have the same degree of parallelism. You
> can process GCM to the end of CID, but no more.
>
> To conclude, I do not see how the proposed change helps parallelize
> the encoder or the decoder.
>
>> Thanks,
>> Manasi
>>
>>
>> -----Original Message-----
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
>> Sent: Friday, July 27, 2018 6:43 AM
>> To: Kazuho Oku ; Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> 
>> Cc: IETF QUIC WG 
>> Subject: Re: Packet Number Encryption outside of AEAD
>>
>>
>>
>> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>>> Consider the case where a sender encodes a packet number using 4
>>> octets even when just using 1 octet is enough.
>>>
>>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>>> first octet of the encrypted PN, and trimming the latter three octets
>>> of the encrypted PN.
>> That attack does not work, because the encoding of the PN is big-endian.
>> The actual packet number is in the fourth octet. Or rather, it only
>> works in the special case where the PN is 0.
>>
>> -- Christian Huitema
>>
>
>
>
> --
> Kazuho Oku



--=20
Kazuho Oku


From nobody Sat Jul 28 07:41:29 2018
Return-Path: 
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 2D9E4130F52 for ; Sat, 28 Jul 2018 07:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2TdfjLxDoiz4 for ; Sat, 28 Jul 2018 07:41:23 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FD7130ECF for ; Sat, 28 Jul 2018 07:41:22 -0700 (PDT)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fjQOh-0005Bg-8d for quic@ietf.org; Sat, 28 Jul 2018 16:41:19 +0200
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fjQOc-0003Mz-CM for quic@ietf.org; Sat, 28 Jul 2018 10:40:42 -0400
Received: (qmail 1084 invoked from network); 28 Jul 2018 14:40:31 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.107]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Jul 2018 14:40:30 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-AA0DC0A4-40A8-481D-82F8-8B2A397E48AD
Mime-Version: 1.0 (1.0)
From: Christian Huitema 
X-Mailer: iPhone Mail (15G77)
In-Reply-To: 
Date: Sat, 28 Jul 2018 07:40:28 -0700
Cc: "Deval, Manasi" , Kazuho Oku , IETF QUIC WG 
Content-Transfer-Encoding: 7bit
Message-Id: <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net>
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>  
To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Subject: Re: Packet Number Encryption outside of AEAD
X-Originating-IP: 168.144.250.232
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.18)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5vrOkxCz7CUqfc4pVysanN5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVita7dq4C5XeXlPLezMaOVjs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1c1FPznmLv13i1NL5aXaHx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpU1moK5+umQAfdUHagyvOVYV02484zECfle5vrwArTB04jUSEF1DKGQ k5uEolWDqGJz1HQkoj+jjvmw3UQ3Zextr+7/jg66NXUoieIpLIJirIV7hPvBDpgDmC+XXO9ws5qS dbWrmlMqpoC2dVXCySAVi5bZXEudL3ieMOBM2bJNcVYE7tCqypI5WX0qWh4YQLCDiFcTNEuokWVE +92LapjBbr8Ks0SqCpRWIiXMtOo8/pI8jnU4taLGlA8rnD8bXLXYENHEHdfH4WKtOnkQjvURQKHY 6H+wSCoVvwvquzDDiAFgqbLsMBS3CSu0TYW/KPOYdub/YU/cH64QiTAnRDmAKMFEHS3+vt/Njsed NDmPw/Ld14/y82ebPziYNS9mrGcHWFhVQvKDd9aHm1tzPaYBnxycJOQKmrvtOUL1jquCMfd5HnMi k4ibTRVHi8subW0=
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 14:41:26 -0000

--Apple-Mail-AA0DC0A4-40A8-481D-82F8-8B2A397E48AD
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think that Kazuho is making a strong point. The PNE is somewhat malleable,=
 so there is indeed a risk in not using AEAD to protect the encoding.=20

There are potential gains in not including the encoding in AEAD, but they ar=
e pretty small. There is no actual need to decrypt the PN in place and modif=
y the input buffer. You can always decrypt it in a secondary buffer and use a=
 scatter-gather API for AEAD input. Or you can copy the entire decrypted hea=
der in a secondary buffer if you don't have access to scatter-gather API.

-- Christian Huitema=20

> On Jul 28, 2018, at 6:44 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen  wrote:
>=20
> You can have one core with access to an input queue that does nothing but d=
ecrypting packet numbers.
> The decrypted PN=E2=80=99s are placed on a queue.
> Meanwhile one or several other cores verify the AEAD tag and places valida=
tion on a queue.
> A third set of cores processes decryption and places decrypted packets on a=
 queue. High priority frames are read from the decrypted packet queue and pr=
ocessed, pending tag confirmation.
> A fourth set of cores deal with ACK processing and other packet number sen=
sitive content.
>=20
> If the original receive buffer needs to be modified, you first incur the P=
NE decryption delay, then you force a possibly shared cache line into exclus=
ive mode by writing to the buffer. The separate concurrent stages now not on=
ly have to wait for PNE, but also for the inter-processor cache coherency sy=
nchronisation to take effect.
>=20
> For encoding there are fewer benefits, but one is that you can encrypt buf=
fers without deciding the packet number immediately. This might be helpful i=
f sending via multiple cores feeding to a final transmit process that synchr=
onises packet numbers and applies PNE before sending data on the wire.
>=20
>=20
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>=20
>=20
>> On 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:
>>=20
>> 2018-07-28 7:11 GMT+09:00 Deval, Manasi :=20
>> > About the issue of Packet Number Encryption outside of AEAD - We agree i=
t simplifies both hardware and software logic. It also allows the2 encryptio=
n operations to run mostly in parallel, so it is a welcome modification.=20
>>=20
>> Would you mind elaborating a bit on how the proposed change would help=20=

>> parallelization?=20
>>=20
>> My understanding is that it does not help parallelizing "encryption",=20
>> because the only change is if you have the cleartext PN (which is=20
>> something you can prepare beforehand) as part of the AAD.=20
>>=20
>> I also do not understand how it helps parallelizing decryption in practic=
e.=20
>>=20
>> The proposed change removes cleartext PN from AAD. It sounds like that=20=

>> you would then have a chance to start processing AAD for GCM. But I am=20=

>> not sure if that is correct.=20
>>=20
>> In the current approach, input to GCM is: GCM(first-octet || CID ||=20
>> plaintext-PN || payload).=20
>>=20
>> With the proposed change, it becomes: GCM(fist-octet || CID || payload).=20=

>>=20
>> Because where the payload begins depends on the value of the PN being=20
>> decrypted, in both cases you have the same degree of parallelism. You=20
>> can process GCM to the end of CID, but no more.=20
>>=20
>> To conclude, I do not see how the proposed change helps parallelize=20
>> the encoder or the decoder.=20
>>=20
>> > Thanks,=20
>> > Manasi=20
>> >=20
>> >=20
>> > -----Original Message-----=20
>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitem=
a=20
>> > Sent: Friday, July 27, 2018 6:43 AM=20
>> > To: Kazuho Oku ; Mikkel Fahn=C3=B8e J=C3=B8rgensen=
 =20
>> > Cc: IETF QUIC WG =20
>> > Subject: Re: Packet Number Encryption outside of AEAD=20
>> >=20
>> >=20
>> >=20
>> > On 7/26/2018 9:14 PM, Kazuho Oku wrote:=20
>> >> Consider the case where a sender encodes a packet number using 4=20
>> >> octets even when just using 1 octet is enough.=20
>> >>=20
>> >> An on-path attacker rewrites the packet by applying XOR 0x80 to the=20=

>> >> first octet of the encrypted PN, and trimming the latter three octets=20=

>> >> of the encrypted PN.=20
>> > That attack does not work, because the encoding of the PN is big-endian=
.=20
>> > The actual packet number is in the fourth octet. Or rather, it only=20
>> > works in the special case where the PN is 0.=20
>> >=20
>> > -- Christian Huitema=20
>> >=20
>>=20
>>=20
>>=20
>> --=20
>> Kazuho Oku=20

--Apple-Mail-AA0DC0A4-40A8-481D-82F8-8B2A397E48AD
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think that Kazuho is making a strong poin=
t. The PNE is somewhat malleable, so there is indeed a risk in not using AEA=
D to protect the encoding. 

There are potential gain=
s in not including the encoding in AEAD, but they are pretty small. There is=
 no actual need to decrypt the PN in place and modify the input buffer. You c=
an always decrypt it in a secondary buffer and use a scatter-gather API for A=
EAD input. Or you can copy the entire decrypted header in a secondary buffer=
 if you don't have access to scatter-gather API.

-- Christian Huitema 

On Jul 28, 2018, at 6:44=
 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

You can have one core with=
 access to an input queue that does nothing but decrypting packet numbers.
The decrypted PN=
=E2=80=99s are placed on a queue.
Meanwhile one or several other cores verify the AEAD tag a=
nd places validation on a queue.
A third set of cores processes decryption and places decry=
pted packets on a queue. High priority frames are read from the decrypted pa=
cket queue and processed, pending tag confirmation.
A fourth set of cores deal with ACK pro=
cessing and other packet number sensitive content.

If the original receive buffer needs to be modifie=
d, you first incur the PNE decryption delay, then you force a possibly share=
d cache line into exclusive mode by writing to the buffer. The separate conc=
urrent stages now not only have to wait for PNE, but also for the inter-proc=
essor cache coherency synchronisation to take effect.

For encoding there are fewer benefits, but one i=
s that you can encrypt buffers without deciding the packet number immediatel=
y. This might be helpful if sending via multiple cores feeding to a final tr=
ansmit process that synchronises packet numbers and applies PNE before sendi=
ng data on the wire.

 
 
Kind Reg=
ards,
Mikkel =
Fahn=C3=B8e J=C3=B8rgensen

 
O=
n 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:
 
2018-07-28 7:11 GMT+09:00 Deval, Manasi &=
lt;manasi.deval@intel.com>:=


> About the issue of Packet Number Encryption outside of AEAD - We ag=
ree it simplifies both hardware and software logic. It also allows the2 encr=
yption operations to run mostly in parallel, so it is a welcome modification=
.



Would you mind elaborating a bit on how the proposed change would help

parallelization?



My understanding is that it does not help parallelizing "encryption",

because the only change is if you have the cleartext PN (which is

something you can prepare beforehand) as part of the AAD.



I also do not understand how it helps parallelizing decryption in practi=
ce.



The proposed change removes cleartext PN from AAD. It sounds like that

you would then have a chance to start processing AAD for GCM. But I am

not sure if that is correct.



In the current approach, input to GCM is: GCM(first-octet || CID ||

plaintext-PN || payload).



With the proposed change, it becomes: GCM(fist-octet || CID || payload).=




Because where the payload begins depends on the value of the PN being

decrypted, in both cases you have the same degree of parallelism. You

can process GCM to the end of CID, but no more.



To conclude, I do not see how the proposed change helps parallelize

the encoder or the decoder.



> Thanks,

> Manasi

>

>

> -----Original Message-----

> From: QUIC [mailto:quic-bo=
unces@ietf.org] On Behalf Of Christian Huitema

> Sent: Friday, July 27, 2018 6:43 AM

> To: Kazuho Oku <kazuhooku=
@gmail.com>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>

> Cc: IETF QUIC WG <quic@ietf.org=
>

> Subject: Re: Packet Number Encryption outside of AEAD

>

>

>

> On 7/26/2018 9:14 PM, Kazuho Oku wrote:

>> Consider the case where a sender encodes a packet number using 4=


>> octets even when just using 1 octet is enough.

>>

>> An on-path attacker rewrites the packet by applying XOR 0x80 to=
 the

>> first octet of the encrypted PN, and trimming the latter three o=
ctets

>> of the encrypted PN.

> That attack does not work, because the encoding of the PN is big-en=
dian.

> The actual packet number is in the fourth octet. Or rather, it only=


> works in the special case where the PN is 0.

>

> -- Christian Huitema

>







-- =20

Kazuho Oku



=

--Apple-Mail-AA0DC0A4-40A8-481D-82F8-8B2A397E48AD--


From nobody Sat Jul 28 08:13:20 2018
Return-Path: 
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 9CDFE130F88 for ; Sat, 28 Jul 2018 08:13:18 -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 goSBdKqGDnMS for ; Sat, 28 Jul 2018 08:13:16 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 17AAB130E76 for ; Sat, 28 Jul 2018 08:13:16 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id q19-v6so6493113ioh.11 for ; Sat, 28 Jul 2018 08:13:16 -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=I/j+rilTokxewbiFz3fHApk/s6xctJSOlAahP9JBv/M=; b=unCd39Ghg5mtignn1SL6Q1RDKcZ/0sYt6REct3ZmzPmL3bQhWiufJDRf3PyLgpuPD5 G0O5O/5WyZC5ZeHe4qzWrj0y8QCI69yPYsVW3rMLl65MLD0ag1bQXnj2WKexDtk8rMtJ /JDZi+TkdcxV9LIaqw73Fj90ASlwZaEz318ISJHjSv8rPTMHkjrADuifxSsfgXMkKe6O wjD9osttMy6y1+Pa09IjOrG6vy+PmlZzYIo4rG+2Sg65Vkh6pCMgB4BIPpaRRkkjIIEK PNVQK4MlAZ8pYsFTgOff2Y0hb/oXsaHzWedW70gm11nfL3vMcwAYnOiuAyHI33jUEEbe p7WA==
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=I/j+rilTokxewbiFz3fHApk/s6xctJSOlAahP9JBv/M=; b=kKhLAkot8jE6sfX+T4k/N0S8fLel9f/QNhRDyp0P33HQ7VzlJnLqqg8RWaCbQpfRub 0fBIpEkLvr2i/fGlIU6ummYQoql7Mx50R5MCKL3BmIld/1wRrVF4FnLDnHWA4t+lL0Sf 2iELK+Tn28V/AZRcz/JvGHZiHnUJbfrKxtSBNlwrLQfuOFgijWMwwgbVX5Pi5NayRTcn q5b6/UErYUBINAsMa3i3vy5qNtKso+UtriDxrY7aph5ZaG0KxE7je+DRUDvWb0R/ZAcn HsluKK7cq97Sn60+DUa7Hdqs9HH8ntGDgGEQnakKSZv1XSzGpSAAnaqBbzHHW6yEC/Al ChMQ==
X-Gm-Message-State: AOUpUlFga7mC0thT23WL4RdKiSz0TXtC7HDsChSi7//J9GVZlNuM65L8 mt36U7utgxaJdIygG3jpsxELrSj5sT8R6PYJ0lk=
X-Google-Smtp-Source: AAOMgpeeE15RFRQYdr5fWK47663NPFeqSKRdnsw8fHs9U+iYiermLYOmgNIVC9OBmcbHA9cTH+x4uHP1b3xzS/TLzCQ=
X-Received: by 2002:a6b:7b03:: with SMTP id l3-v6mr8962975iop.36.1532790795457;  Sat, 28 Jul 2018 08:13:15 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 28 Jul 2018 08:13:14 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
In-Reply-To: <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net>
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>   <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sat, 28 Jul 2018 08:13:14 -0700
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: Christian Huitema 
Cc: IETF QUIC WG , "Deval, Manasi" ,  Kazuho Oku 
Content-Type: multipart/alternative; boundary="000000000000e0dacf057210aad5"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 15:13:19 -0000

--000000000000e0dacf057210aad5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, the fact that you don=E2=80=99t know the PN length is a problem.
The PN length could be sent in clear text. Would that be a problem?

Copying is not very useful if you want to pipeline packets.
A gather API can work but it complicates things, especially in hardware.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 28 July 2018 at 16.40.43, Christian Huitema (huitema@huitema.net) wrote:

I think that Kazuho is making a strong point. The PNE is somewhat
malleable, so there is indeed a risk in not using AEAD to protect the
encoding.

There are potential gains in not including the encoding in AEAD, but they
are pretty small. There is no actual need to decrypt the PN in place and
modify the input buffer. You can always decrypt it in a secondary buffer
and use a scatter-gather API for AEAD input. Or you can copy the entire
decrypted header in a secondary buffer if you don't have access to
scatter-gather API.

-- Christian Huitema

On Jul 28, 2018, at 6:44 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen 
wrote:

You can have one core with access to an input queue that does nothing but
decrypting packet numbers.
The decrypted PN=E2=80=99s are placed on a queue.
Meanwhile one or several other cores verify the AEAD tag and places
validation on a queue.
A third set of cores processes decryption and places decrypted packets on a
queue. High priority frames are read from the decrypted packet queue and
processed, pending tag confirmation.
A fourth set of cores deal with ACK processing and other packet number
sensitive content.

If the original receive buffer needs to be modified, you first incur the
PNE decryption delay, then you force a possibly shared cache line into
exclusive mode by writing to the buffer. The separate concurrent stages now
not only have to wait for PNE, but also for the inter-processor cache
coherency synchronisation to take effect.

For encoding there are fewer benefits, but one is that you can encrypt
buffers without deciding the packet number immediately. This might be
helpful if sending via multiple cores feeding to a final transmit process
that synchronises packet numbers and applies PNE before sending data on the
wire.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:

2018-07-28 7:11 GMT+09:00 Deval, Manasi :
> About the issue of Packet Number Encryption outside of AEAD - We agree it
simplifies both hardware and software logic. It also allows the2 encryption
operations to run mostly in parallel, so it is a welcome modification.

Would you mind elaborating a bit on how the proposed change would help
parallelization?

My understanding is that it does not help parallelizing "encryption",
because the only change is if you have the cleartext PN (which is
something you can prepare beforehand) as part of the AAD.

I also do not understand how it helps parallelizing decryption in practice.

The proposed change removes cleartext PN from AAD. It sounds like that
you would then have a chance to start processing AAD for GCM. But I am
not sure if that is correct.

In the current approach, input to GCM is: GCM(first-octet || CID ||
plaintext-PN || payload).

With the proposed change, it becomes: GCM(fist-octet || CID || payload).

Because where the payload begins depends on the value of the PN being
decrypted, in both cases you have the same degree of parallelism. You
can process GCM to the end of CID, but no more.

To conclude, I do not see how the proposed change helps parallelize
the encoder or the decoder.

> Thanks,
> Manasi
>
>
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
> Sent: Friday, July 27, 2018 6:43 AM
> To: Kazuho Oku ; Mikkel Fahn=C3=B8e J=C3=B8rgensen <
mikkelfj@gmail.com>
> Cc: IETF QUIC WG 
> Subject: Re: Packet Number Encryption outside of AEAD
>
>
>
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>>
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.
>
> -- Christian Huitema
>



--
Kazuho Oku

--000000000000e0dacf057210aad5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=
Yes, the fact that y=
ou don=E2=80=99t know the PN length is a problem.
The PN length could be sent in clear t=
ext. Would that be a problem?

Copying is not very useful if you want to pipeline packets.
<=
div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:=
13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">A gather API can wo=
rk but it complicates things, especially in hardware. 
 
Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen
 
On 28 July 2018 at 16.40.43, =
Christian Huitema (huitema@huitema.n=
et) wrote:
 







I think that Kazuho is making a strong point. The PNE is somewhat
malleable, so there is indeed a risk in not using AEAD to protect
the encoding.=C2=A0




There are potential gains in not including the encoding in
AEAD, but they are pretty small. There is no actual need to decrypt
the PN in place and modify the input buffer. You can always decrypt
it in a secondary buffer and use a scatter-gather API for AEAD
input. Or you can copy the entire decrypted header in a secondary
buffer if you don't have access to scatter-gather API.




-- Christian Huitema=C2=A0




On Jul 28, 2018, at 6:44 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:










You can have one core with access to an input queue that does
nothing but decrypting packet numbers.



The decrypted PN=E2=80=99s are placed on a queue.



Meanwhile one or several other cores verify the AEAD tag and places
validation on a queue.



A third set of cores processes decryption and places decrypted
packets on a queue. High priority frames are read from the
decrypted packet queue and processed, pending tag
confirmation.



A fourth set of cores deal with ACK processing and other packet
number sensitive content.







If the original receive buffer needs to be modified, you first
incur the PNE decryption delay, then you force a possibly shared
cache line into exclusive mode by writing to the buffer. The
separate concurrent stages now not only have to wait for PNE, but
also for the inter-processor cache coherency synchronisation to
take effect.







For encoding there are fewer benefits, but one is that you can
encrypt buffers without deciding the packet number immediately.
This might be helpful if sending via multiple cores feeding to a
final transmit process that synchronises packet numbers and applies
PNE before sending data on the wire.










Kind
Regards,


Mikkel
Fahn=C3=B8e J=C3=B8rgensen








On 28 July 2018 at 15.16.03, Kazuho Oku
(kazuhooku@gmail.com)
wrote:






2018-07-28 7:11 GMT+09:00 Deval, Manasi <manasi.deval@intel.com>:


> About the issue of Packet Number Encryption outside of AEAD -
We agree it simplifies both hardware and software logic. It also
allows the2 encryption operations to run mostly in parallel, so it
is a welcome modification.



Would you mind elaborating a bit on how the proposed change would
help

parallelization?



My understanding is that it does not help parallelizing
"encryption",

because the only change is if you have the cleartext PN (which
is

something you can prepare beforehand) as part of the AAD.



I also do not understand how it helps parallelizing decryption in
practice.



The proposed change removes cleartext PN from AAD. It sounds like
that

you would then have a chance to start processing AAD for GCM. But I
am

not sure if that is correct.



In the current approach, input to GCM is: GCM(first-octet || CID
||

plaintext-PN || payload).



With the proposed change, it becomes: GCM(fist-octet || CID ||
payload).



Because where the payload begins depends on the value of the PN
being

decrypted, in both cases you have the same degree of parallelism.
You

can process GCM to the end of CID, but no more.



To conclude, I do not see how the proposed change helps
parallelize

the encoder or the decoder.



> Thanks,

> Manasi

>

>

> -----Original Message-----

> From: QUIC [mailto:quic-bounc=
es@ietf.org] On Behalf
Of Christian Huitema

> Sent: Friday, July 27, 2018 6:43 AM

> To: Kazuho Oku <kazuhooku@gm=
ail.com>; Mikkel
Fahn=C3=B8e J=C3=B8rgensen <mikkel=
fj@gmail.com>

> Cc: IETF QUIC WG <quic@ietf.org>

> Subject: Re: Packet Number Encryption outside of AEAD

>

>

>

> On 7/26/2018 9:14 PM, Kazuho Oku wrote:

>> Consider the case where a sender encodes a packet number
using 4

>> octets even when just using 1 octet is enough.

>>

>> An on-path attacker rewrites the packet by applying XOR
0x80 to the

>> first octet of the encrypted PN, and trimming the latter
three octets

>> of the encrypted PN.

> That attack does not work, because the encoding of the PN is
big-endian.

> The actual packet number is in the fourth octet. Or rather, it
only

> works in the special case where the PN is 0.

>

> -- Christian Huitema

>







--

Kazuho Oku
















--000000000000e0dacf057210aad5--


From nobody Sat Jul 28 11:14:02 2018
Return-Path: 
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 BA972130E5D for ; Sat, 28 Jul 2018 11:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 ZDW8xjfXiYU6 for ; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 8B7DA130DD3 for ; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id u14-v6so5583174lfu.0 for ; Sat, 28 Jul 2018 11:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GaP/iXwWh0+ZpftxIIX4wsmYogxKVGqvocbdXiaPxs8=; b=U4uA2spmCylbYBVxBxhl9cWqR+p9EWR7IRp7EtIaOvNaW/hsUap6oVf+2qb1O19D1U yDDRQrmPRQwy5buAHdmPKPd1IJGzeMcz87Me2KiAsG5Sw6x8SFzIto7UfsQkQ59fYCO+ nP/4kth+8Bggm/0D/MIc6CMLQh1zoIhKLWcUggEj2iS+Tnm5vywNlu9dxvNfUQ/pyJsF bEz4cxuCr/xtXiw5bV5Obnc9iAFAdtg7sHh4eDv0XygADek/INOh78DFnCIIFwlCUgOx RoBm7hcvYWi0EhwyqD8zc6Fz1dpvLfUskqFf/pZd71MdIbq4I1vkWViEmIykKpAiCnHp BJRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GaP/iXwWh0+ZpftxIIX4wsmYogxKVGqvocbdXiaPxs8=; b=UdTuWwajt+5rXMFtoLDCYfwC7zPlUJ0XjASig3zAUEbwCHFDz1mfrcabkd9aNW0CXI kffHH3n4El0FrM/Xk0vjclWPQKgGDhxPE0GJZAQSChig/egzNWe3MdKFnC5ObqFq7n1R MTsU8c4voWudZTFqF7PAHtNHbIgppOznwQMVLL8AYj3HLT1lACCpdjlYlZ/4s6NH/NwI zNlwy5OUOJsk92vgxNPQ5zsHOVPmqgFSolNjrD3q+xp51U8q1l99GtR4Sf+vzAiWT4hj 1hRxc9yKgLz83pvzOoIlfDnf3mh1S5PwJHvodkIn5gTGmjBYzCkFkLCxWyKEPmFgNMuI zyDg==
X-Gm-Message-State: AOUpUlEgQfKXQB6mF6pXoXyRKqLQxoOp6+QRIE6cw2YQCwsYCh6OBMkC w5TDWyXhlKt+5Ceng6/GEOPjESTb4fuOYxhx94M=
X-Google-Smtp-Source: AAOMgpfeNOvMYpNqhSWdNipeh6SusAq3aTUnE7pqKxnsrJRlJqkcX2mV51nAMkX8WQupHRe0r7ULCCVrsXx4IsUa0+8=
X-Received: by 2002:a19:de4e:: with SMTP id v75-v6mr6448773lfg.14.1532801637850;  Sat, 28 Jul 2018 11:13:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 11:13:57 -0700 (PDT)
In-Reply-To: 
References:   <97ef2887-7e02-7a57-efe9-f6e54dcbf0dc@huitema.net> <1F436ED13A22A246A59CA374CBC543998B87F778@ORSMSX111.amr.corp.intel.com>   <2D08CAE5-D780-402A-9272-48EE52425F67@huitema.net> 
From: Kazuho Oku 
Date: Sun, 29 Jul 2018 03:13:57 +0900
Message-ID: 
Subject: Re: Packet Number Encryption outside of AEAD
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= 
Cc: Christian Huitema , IETF QUIC WG ,  "Deval, Manasi" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sat, 28 Jul 2018 18:14:02 -0000

2018-07-29 0:13 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen :
> Yes, the fact that you don=E2=80=99t know the PN length is a problem.
> The PN length could be sent in clear text. Would that be a problem?

That would be a problem.

An endpoint can select the size of the PN field based on the number of
packets inflight. For such an implementation, sending the size of the
field effectively means leaking RTT.

>
> Copying is not very useful if you want to pipeline packets.
> A gather API can work but it complicates things, especially in hardware.
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
> On 28 July 2018 at 16.40.43, Christian Huitema (huitema@huitema.net) wrot=
e:
>
> I think that Kazuho is making a strong point. The PNE is somewhat malleab=
le,
> so there is indeed a risk in not using AEAD to protect the encoding.
>
> There are potential gains in not including the encoding in AEAD, but they
> are pretty small. There is no actual need to decrypt the PN in place and
> modify the input buffer. You can always decrypt it in a secondary buffer =
and
> use a scatter-gather API for AEAD input. Or you can copy the entire
> decrypted header in a secondary buffer if you don't have access to
> scatter-gather API.
>
> -- Christian Huitema
>
> On Jul 28, 2018, at 6:44 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen 
> wrote:
>
> You can have one core with access to an input queue that does nothing but
> decrypting packet numbers.
> The decrypted PN=E2=80=99s are placed on a queue.
> Meanwhile one or several other cores verify the AEAD tag and places
> validation on a queue.
> A third set of cores processes decryption and places decrypted packets on=
 a
> queue. High priority frames are read from the decrypted packet queue and
> processed, pending tag confirmation.
> A fourth set of cores deal with ACK processing and other packet number
> sensitive content.
>
> If the original receive buffer needs to be modified, you first incur the =
PNE
> decryption delay, then you force a possibly shared cache line into exclus=
ive
> mode by writing to the buffer. The separate concurrent stages now not onl=
y
> have to wait for PNE, but also for the inter-processor cache coherency
> synchronisation to take effect.
>
> For encoding there are fewer benefits, but one is that you can encrypt
> buffers without deciding the packet number immediately. This might be
> helpful if sending via multiple cores feeding to a final transmit process
> that synchronises packet numbers and applies PNE before sending data on t=
he
> wire.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
>
> On 28 July 2018 at 15.16.03, Kazuho Oku (kazuhooku@gmail.com) wrote:
>
> 2018-07-28 7:11 GMT+09:00 Deval, Manasi :
>> About the issue of Packet Number Encryption outside of AEAD - We agree i=
t
>> simplifies both hardware and software logic. It also allows the2 encrypt=
ion
>> operations to run mostly in parallel, so it is a welcome modification.
>
> Would you mind elaborating a bit on how the proposed change would help
> parallelization?
>
> My understanding is that it does not help parallelizing "encryption",
> because the only change is if you have the cleartext PN (which is
> something you can prepare beforehand) as part of the AAD.
>
> I also do not understand how it helps parallelizing decryption in practic=
e.
>
> The proposed change removes cleartext PN from AAD. It sounds like that
> you would then have a chance to start processing AAD for GCM. But I am
> not sure if that is correct.
>
> In the current approach, input to GCM is: GCM(first-octet || CID ||
> plaintext-PN || payload).
>
> With the proposed change, it becomes: GCM(fist-octet || CID || payload).
>
> Because where the payload begins depends on the value of the PN being
> decrypted, in both cases you have the same degree of parallelism. You
> can process GCM to the end of CID, but no more.
>
> To conclude, I do not see how the proposed change helps parallelize
> the encoder or the decoder.
>
>> Thanks,
>> Manasi
>>
>>
>> -----Original Message-----
>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
>> Sent: Friday, July 27, 2018 6:43 AM
>> To: Kazuho Oku ; Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> 
>> Cc: IETF QUIC WG 
>> Subject: Re: Packet Number Encryption outside of AEAD
>>
>>
>>
>> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>>> Consider the case where a sender encodes a packet number using 4
>>> octets even when just using 1 octet is enough.
>>>
>>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>>> first octet of the encrypted PN, and trimming the latter three octets
>>> of the encrypted PN.
>> That attack does not work, because the encoding of the PN is big-endian.
>> The actual packet number is in the fourth octet. Or rather, it only
>> works in the special case where the PN is 0.
>>
>> -- Christian Huitema
>>
>
>
>
> --
> Kazuho Oku



--=20
Kazuho Oku


From nobody Sat Jul 28 17:45:20 2018
Return-Path: 
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 1C6A2124D68 for ; Sat, 28 Jul 2018 17:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=I/pQ+Mo1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VdfEAjsY
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 mbjcH0jtnKGs for ; Sat, 28 Jul 2018 17:45:15 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC51130DE4 for ; Sat, 28 Jul 2018 17:45:15 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 75A0D21221 for ; Sat, 28 Jul 2018 20:45:14 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 28 Jul 2018 20:45:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=aohWaqUP955DI3u5z brXh2B0zZBpX9Bqeoddcvt6uk8=; b=I/pQ+Mo16TDBuHCAQse2qmbpXSlmVhWwa p1XN7I55XNxzUi42GDxiDOTwiDbXl9P5gL2ZEaNOyNx52+F0mWWyt7tvQdZXETLh l5AdTSLtfTWnQK1g0I+0gyLr/mjGZQbd9aRm/bDiqTGpvVcAYjGezijx+RhL9BC8 yJjl7+Ym8ldqf22x41cjEgkj5g2Fa5ClY2JNDeNxfOGcb1zyYUnYcIH4McEJ5iFi 1ZJOQkqoke5Fw7uPjCNIGl75KMwV7b9DPvaoEWh1Vv5Wxdq0hu+dk4rzQZXWI384 VUnH2j4GuhO+ViVujsLbUdwR+/xGb4Oee1Gna7gMR/pWUPbYkvo5g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=aohWaqUP955DI3u5zbrXh2B0zZBpX9Bqeoddcvt6uk8=; b=VdfEAjsY PnXj62S/JcsjYEQBl6ieXnnQYVwZ7g3yb8qTyw6z/j/Lmvr453Scn7pSZK614Ror qEZGlELRCRAOceSL+eJIXo1WLS0jmGmlBXUkFlH8ovoPtjvYFPgWx0RdxDMuxmIC crvom3g9N8P8PVo5fuoZJG78SxdRpr6klInDB4gfA/IBh8SoWLoMV7jBr9Wt8Him m/O75YcIRHbgf6XsnefFrfee2HPJayS741UdKL9QRvUR4mJtxF16IpPxHbjEsdg5 GQqUozaFbqyaOZqcd0SWTKK/hzU+T9zzr+wc4sDpHGkBDB3ecISaC6bJOkF8OKDt XrN2AnVtErGDzQ==
X-ME-Proxy:      
X-ME-Sender: 
Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id BC62910268 for ; Sat, 28 Jul 2018 20:45:13 -0400 (EDT)
Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id EA023CC678 for ; Sun, 29 Jul 2018 00:45:10 +0000 (UTC)
Content-Type: multipart/alternative; boundary="===============4312774257548697369=="
MIME-Version: 1.0
From: =?utf-8?q?Github_Notifications?= 
To: quic@ietf.org
Subject: Weekly github digest (QUIC Working Group Specifications)
Message-Id: <20180729004510.EA023CC678@cloud.mnot.net>
Date: Sun, 29 Jul 2018 00:45:10 +0000 (UTC)
Archived-At: 
X-BeenThere: quic@ietf.org
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: Sun, 29 Jul 2018 00:45:19 -0000

--===============4312774257548697369==
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; format="flowed"




Events without label "editorial"

Issues
------
* quicwg/base-drafts (+5/-1/=F0=9F=92=AC31)
  5 issues created:
  - Possible HoL blocking due to co-mingling payload and metadata (header) =
address space. (by grmocg)
    https://github.com/quicwg/base-drafts/issues/1606 =

  - qpack: acking headers that do not reference the dynamic table is wastef=
ul (by dtikhonov)
    https://github.com/quicwg/base-drafts/issues/1603 =

  - Indicate support for optional protocol chunks. (by MikeBishop)
    https://github.com/quicwg/base-drafts/issues/1600 [-http] [design] =

  - draft-ietf-quic-recovery-13  ssthresh never set (by aep)
    https://github.com/quicwg/base-drafts/issues/1598 =

  - How should an HQ server respond to RST_STREAM? (by afrind)
    https://github.com/quicwg/base-drafts/issues/1596 =


  7 issues received 31 new comments:
  - #1606 Possible HoL blocking due to co-mingling payload and metadata (he=
ader) address space. (14 by grmocg, MikeBishop, krasic, martinthomson, ians=
wett, LPardue)
    https://github.com/quicwg/base-drafts/issues/1606 [-http] [design] [qui=
cv2] =

  - #1443 Stateless Reset Eternal Ping Pong (8 by martinthomson, ianswett)
    https://github.com/quicwg/base-drafts/issues/1443 [-transport] [design] =

  - #1596 How should an HQ server respond to RST_STREAM? (4 by LPardue, afr=
ind)
    https://github.com/quicwg/base-drafts/issues/1596 =

  - #1556 HTTP SETTINGS: define setting content encoding (2 by afrind, Mike=
Bishop)
    https://github.com/quicwg/base-drafts/issues/1556 [-http] =

  - #1600 Indicate support for PRIORITY (1 by ianswett)
    https://github.com/quicwg/base-drafts/issues/1600 [-http] [design] =

  - #1579 Go Back to Single Packet Number Space (1 by nibanks)
    https://github.com/quicwg/base-drafts/issues/1579 [-tls] [-transport] [=
design] =

  - #1598 draft-ietf-quic-recovery-13  ssthresh never set (1 by ianswett)
    https://github.com/quicwg/base-drafts/issues/1598 =


  1 issues closed:
  - draft-ietf-quic-recovery-13  ssthresh never set https://github.com/quic=
wg/base-drafts/issues/1598 =




Pull requests
-------------
* quicwg/base-drafts (+5/-5/=F0=9F=92=AC8)
  5 pull requests submitted:
  - STREAM -> CRYPTO (by ekr)
    https://github.com/quicwg/base-drafts/pull/1607 =

  - Only ack headers that have non-zero declared Largest Reference (by dtik=
honov)
    https://github.com/quicwg/base-drafts/pull/1605 =

  - Release note (by ianswett)
    https://github.com/quicwg/base-drafts/pull/1604 =

  - adds missing ssthresh =3D congestion_window (by aep)
    https://github.com/quicwg/base-drafts/pull/1602 =

  - draft-ietf-quic-recovery: fix typo (by aep)
    https://github.com/quicwg/base-drafts/pull/1597 =


  4 pull requests received 8 new comments:
  - #1589 Do not use undefined term "successful processing" (3 by martintho=
mson, dtikhonov, afrind)
    https://github.com/quicwg/base-drafts/pull/1589 =

  - #1591 Single Packet Number Space (3 by nibanks, huitema, MikeBishop)
    https://github.com/quicwg/base-drafts/pull/1591 =

  - #1574 Add MaxAckDelay sub-section (1 by ianswett)
    https://github.com/quicwg/base-drafts/pull/1574 =

  - #1607 STREAM -> CRYPTO (1 by ekr)
    https://github.com/quicwg/base-drafts/pull/1607 =


  5 pull requests merged:
  - Add MaxAckDelay sub-section
    https://github.com/quicwg/base-drafts/pull/1574 =

  - Release note
    https://github.com/quicwg/base-drafts/pull/1604 =

  - Change early retransmit timer to 1/8th
    https://github.com/quicwg/base-drafts/pull/1581 =

  - adds missing ssthresh =3D congestion_window
    https://github.com/quicwg/base-drafts/pull/1602 =

  - draft-ietf-quic-recovery: fix typo
    https://github.com/quicwg/base-drafts/pull/1597 =



Repositories tracked by this digest:
-----------------------------------
* https://github.com/quicwg/base-drafts

--===============4312774257548697369==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable





Weekly github digest (QUIC Working Group Specifications)





Sunday July 29, 2018



Events without label "editorial"



Issues



quicwg/base-drafts (+5/-1/=F0=9F=92=AC31)

  
5 issues created:

  

  
7 issues received 31 new comments:

  

  
1 issues closed:

  




Pull requests


quicwg/base-drafts (+5/-5/=F0=9F=92=AC8)

  
5 pull requests submitted:

  

  
4 pull requests received 8 new comments:

  

  
5 pull requests merged:

  



Repositories tracked by this digest:





--===============4312774257548697369==--


From nobody Sun Jul 29 18:15:42 2018
Return-Path: 
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 B1DFD130F11 for ; Sun, 29 Jul 2018 18:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 6zZjqvUFq6T3 for ; Sun, 29 Jul 2018 18:15:38 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 AF334130EE1 for ; Sun, 29 Jul 2018 18:15:38 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id l10-v6so18327382oii.0 for ; Sun, 29 Jul 2018 18:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=jCrxsxY1NisfTMhcJeuUb1rbPlJlxXcu8hnHwz/iOLs=; b=BLazy/qeU5G+KPw0dS4fJ2dSSPIkeKscsJsplhLeDbr+ilnOUD1+lTt7qvWzY2b8CB Kx2UfA+/6TANq1mZ92xaew3ez2e5moNr46xALKMvzbkwAH/j8CVW0dmr12kbYf9qfkPx YpcSzFYl8pXMciHT5YTvHqgpCkWDU+YgA7eddHchMDRgXuxVKjq4mboD1j6ychZBJvNS YdGHx9roLxB07tajRil2WqYYXZ37Sq4KVFHBfUXCkBiVSaPLShKJrvCScEIJcULMYul3 w0wJMqvN4SyAvoEJalXsoCPz+kl7oGDM9P7W7bVLkWigQFNDRl4OlcU5lZkWybUiAQoT yRhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jCrxsxY1NisfTMhcJeuUb1rbPlJlxXcu8hnHwz/iOLs=; b=gZYrkcWHbGQ6MNxxTFigZDxfcpqTuaydSN9DJWKvhFF/nINm8bL2Y/R38qCQwr0FNt wriKX6lDfSGsrtKRmns5d5JzA7gekr4H2WpGgt84cb8coyijYyTpu7U6O01i0DQelRnw 5JHEkxBJ0LUxgTSiFBDtA9MbH5gyeC1yhYnIAdjoMD5pxuellZCtjGeb9MGoELIjH3f2 h43hQsfqcQ5498HERRzmHwRbObXdBVQXfK9opzZiAwC4yCLFnNxYmP6kH/NjkTfo+jK6 +MuGLmEcLdeNX3X0xotllzueSZhhlA9ytfbmhtgGkS64H4W+kOD+8d+hTvNbi7aUCRI9 /Nqg==
X-Gm-Message-State: AOUpUlH5Q38p4uqL2PPAl5MlJLGiM2bDJX3PTmlzwHXnD6vHmYOJYZ9h /Qk55EgDNCMqPvO/Y60Nesy6T0Xx9U8QX0z3+UdMLkjH
X-Google-Smtp-Source: AAOMgpd+7JLrPVDmGOask2q2CfZOT1S1D7JHBihaZCGcJ/yvVDFMHacirNBNQdrhSFzzHzkoBcIYPnl126rw62u5VnQ=
X-Received: by 2002:aca:a8c1:: with SMTP id r184-v6mr11832554oie.215.1532913337768;  Sun, 29 Jul 2018 18:15:37 -0700 (PDT)
MIME-Version: 1.0
From: Martin Thomson 
Date: Mon, 30 Jul 2018 11:15:27 +1000
Message-ID: 
Subject: Flow control transport parameters are optional
To: QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: quic@ietf.org
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: Mon, 30 Jul 2018 01:15:41 -0000

Just checking that people are OK with this change.

Marten opened https://github.com/quicwg/base-drafts/pull/1610 which
proposes making the initial_max_data transport parameter optional.
Given that this can be set to 0 anyway, it isn't any more of a footgun
that we already have.  Absent objections, I plan to merge this.


From nobody Sun Jul 29 20:22:32 2018
Return-Path: 
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 7EECA130F80 for ; Sun, 29 Jul 2018 20:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 yvRO_hC-xw4M for ; Sun, 29 Jul 2018 20:22:29 -0700 (PDT)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F4E130DF0 for ; Sun, 29 Jul 2018 20:22:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple;  q=dns/txt; i=@apple.com; t=1532920948; x=2396834548; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0SXYtkGrK4HCcs/D9WgsFzSeW1PZFPOzRHftE4FFtZw=; b=S+82+N7tpsV//aeoSPzbnW0ElyiDfj3eGjjfbSV52ldxz9NRzt5QrM/GVndQSRlo 7DgKRz9SgrCfDwTCC1z1xHXVPnNxN+hLP++Hb7yfduNjPkpl10/tE8S44lqx2HD+ 9Hv/U9C5a4R6fc6+Qs3KEfyv1w+l9UMp87SPe7dGQ0JNkoFDlB+a1a/+2hk2tmBU T45i7OyYjYbEIy52O5WYbeQlL5vNvB1solr9W098RWmda5Lw3fdHKL6UVXkTeUEV TsgpP/PXevCHG4p68rNVMiPaL59DUMBaFKhv82CwgZF0yFrDUGDeC4zK2Y70kaz/ iPh9oPhhBfqat05qen/RBg==;
X-AuditID: 11973e11-4fbff70000005b22-55-5b5e847445af
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 45.94.23330.4748E5B5; Sun, 29 Jul 2018 20:22:28 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCN00HNKTDF6S50@ma1-mtap-s03.corp.apple.com>; Sun, 29 Jul 2018 20:22:28 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCN00300TB8CE00@nwk-mmpp-sz10.apple.com>; Sun, 29 Jul 2018 20:22:27 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: bf8f304014303abde5d6a8a39396dd88
X-Va-E-CD: 24d131a76c6d1a4e0eee0eba61b4bc7b
X-Va-R-CD: e087e47261ec22b0fd268f8033e7ffd1
X-Va-CD: 0
X-Va-ID: 33638bb5-8fa0-4d99-b37d-d9373372a134
X-V-A: 
X-V-T-CD: bf8f304014303abde5d6a8a39396dd88
X-V-E-CD: 24d131a76c6d1a4e0eee0eba61b4bc7b
X-V-R-CD: e087e47261ec22b0fd268f8033e7ffd1
X-V-CD: 0
X-V-ID: 47e7e58c-7470-4409-9c46-f8a3fe9de1a8
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCN00300TB8CD00@nwk-mmpp-sz10.apple.com>; Sun, 29 Jul 2018 20:22:27 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-30_01:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1
Received: from [17.234.103.173] (unknown [17.234.103.173]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCN0032YTDE9E00@nwk-mmpp-sz10.apple.com>; Sun, 29 Jul 2018 20:22:27 -0700 (PDT)
Sender: tpauly@apple.com
Subject: Re: Flow control transport parameters are optional
From: Tommy Pauly 
X-Mailer: iPhone Mail (16A5327f)
In-reply-to: 
Date: Sun, 29 Jul 2018 20:22:26 -0700
Cc: QUIC WG 
Content-transfer-encoding: quoted-printable
Message-id: 
References: 
To: Martin Thomson 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUiqOHDrlvSEhdtsHKJtsW1M/8YLXoWcDsw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGSvubWAv6GOtePRnA1sD42SWLkZODgkBE4lv G9ewdzFycQgJ7GOS+N8xmxEkwSsgKPFj8j2gIg4OZgF1iSlTciFqNjJJLGtYxwrhdDFJHLx/ jQ1iErvEn187oKZqS/QfbmeFsRvXPWYEGQRi77+nAhHmkliw9TRUia7E2hk/GSFsNon1J5Yw QdhaEt1/Wphh7Dttt9lg7P3t19khbE6J818mQtk6EtOfTmeCuK2TSeLw4QaoBdkSr149hFoQ LPHnUA/YUCGByUwSW99pg9wmLCAhsXlPIoRpLfHzcxBIBZuAisTxbxugTlCQ2HSlGWwKJ9CU zU9Pg53DIqAqcX95I1icWUBa4uyktSwQtrbEk3cXWCHBaSMx+8dVdoitARJdD74zT2BUnIUU 0rMQIT0LSfcCRuZVjEK5iZk5upl5RnqJBQU5qXrJ+bmbGEGpYLqd4A7G46usDjEKcDAq8fBm SMVFC7EmlhVX5h5ilOZgURLn3b0xOlpIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4ysrn+a9 67n3x96O6euSEK99kFttbRLouXbFkRknQnRiVttP6LD7zybeMNtOtjV1zfLPu7YoJT/d1/N3 J/vPGMnbc1eVKqcWnFY3MmcMmaJ+qf1blIzqsqXhrWu3b11lEaQvemrjRft93bsX9dzZHjy7 hE9y++8/xw59yvspdnN/3FveGnfrGiWW4oxEQy3mouJEALSthXLmAgAA
Archived-At: 
X-BeenThere: quic@ietf.org
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: Mon, 30 Jul 2018 03:22:31 -0000

Seems reasonable, given that it has a well-defined default of 0. I imagine m=
ost implementations will want to always send this, but there doesn=E2=80=99t=
 seem to be any harm in making it optimal.=20

Tommy

> On Jul 29, 2018, at 6:15 PM, Martin Thomson  wro=
te:
>=20
> Just checking that people are OK with this change.
>=20
> Marten opened https://github.com/quicwg/base-drafts/pull/1610 which
> proposes making the initial_max_data transport parameter optional.
> Given that this can be set to 0 anyway, it isn't any more of a footgun
> that we already have.  Absent objections, I plan to merge this.
>=20


From nobody Mon Jul 30 02:36:32 2018
Return-Path: 
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 63249130FA0 for ; Mon, 30 Jul 2018 02:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
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=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 JcPA11zlLl22 for ; Mon, 30 Jul 2018 02:36:29 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 772B2130E05 for ; Mon, 30 Jul 2018 02:36:29 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id d189-v6so20005545oib.6 for ; Mon, 30 Jul 2018 02:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rwTFsk1uEUTyOeoVaWDX+pjeYnqPij7bE8pVJMJw1tg=; b=D7X+cVusGil0ufzFQU2P+FXXXcMorI+wqfFB0x7QvnUaooqVbcHbC4OIYpPZwTkrQu twD2YLhyHTGHIFHKSQ69UqVUsitN+ykT3xE82QJT+RzfjmuBbRD1eWBW0fe3chHwJ2bG Lri/YFrT/ByaSPUoZ1jUyRch9pm/vtiP1pINrgUmmUcogRn9pmPPGr8n++DYJgGJlKml exQEPz5DF8VJGIkjnvyYoqLenQIMDpSvSGXaGRwfKddt4pd5Ff4YxAJvWwP0QCYfoB9v X3xf/QxBhk4nnCWg206U95kc2pKvrbKBXguUulP32dNsPzlitYEJcPyC/D379Jk/vNoY cu+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rwTFsk1uEUTyOeoVaWDX+pjeYnqPij7bE8pVJMJw1tg=; b=LUxCuAlw95sD+hqj7vB7AZi4jle+UUQ0GMOUt0FFMkr49KnTe8depuLPxYw/GSrfaX AY/b5Y3MOn1MkGXS/hOqx8MzF61F2VI1khrT++mxdHaguiQ1xwx/VMnbwtM65hI8NgSR QLlSSj3tf+YALW57JWPT0VvldKJAJG5gWde0qZxeNB7B0ypoNvo40U3OyW+lU8RTMIeF RAPf1Qo2c+YHorJKQDaXmZFOG8ftMuWraFDCUssnIeoGtwkhZxSXIjtW1ZCMZoKod82h WHvUB1DvMOGyzIwph5PvJshbrFRAEdOSFsyITwVEHgN0UZ9dvt4SwJOT73sc7WVIHHNj WoxQ==
X-Gm-Message-State: AOUpUlESTjTv8Qeo7lqpmQfRY1Vqla/g60diVrnKFBQ6p2Z6fB3SCuKl +B4EWYaexdJRJbN0F2HHvFtJDsCtpFRfC0orsMQ=
X-Google-Smtp-Source: AAOMgpcRixDVcu/eyAcmHxNlDbiCLgDFa6xDmKveMwmtJbUTZjXfGqFdjiXzPHdG1Z4hzJcL2lMmABrFgqTt9qEdDi0=
X-Received: by 2002:aca:a8c1:: with SMTP id r184-v6mr13116897oie.215.1532943388704;  Mon, 30 Jul 2018 02:36:28 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Martin Thomson 
Date: Mon, 30 Jul 2018 19:36:16 +1000
Message-ID: 
Subject: Re: PNE Test Vector
To: Eric Rescorla 
Cc: QUIC WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: quic@ietf.org
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: Mon, 30 Jul 2018 09:36:31 -0000

I just implemented a hacky encrypt/decrypt routine for initial packets
and verified this message (not that that was necessary).

https://gist.github.com/martinthomson/7f4b615070254644f4c5335014980cbc

That implementation shows more intermediate values and might be easier
to tweak in order to produce sample values; for instance, it produces
a server Initial packet with an ACK and ServerHello.

I also verified the PNE mask here (65d8d307) using both AES-ECB and
AES-CTR (the API to which in nodejs is fantastically obtuse).
On Thu, Jul 19, 2018 at 12:12 AM Eric Rescorla  wrote:
>
> As discussed in the meeting, here is a test vector for PNE. It's an Initi=
al packet generated by Kazuho but processed by Minq, with the output being =
an edited and annotated version of Minq's logging. Happy to help with more =
logging if that helps.
>
>
> INPUT PACKET
> ffff00000d5006b858ec6f80452b0044efa5d8d307c2973fa0d63fd9b03a4e163b990dd77=
8894a9edc8eacfbe4aa6fbf4a22ec7f906b5e8b8ae12e5fcc7924dfeee813842bb2149b805e=
55895084e8393200bb3fc618af7d08281485d914ce42303f5d772b200508a0c00253e332e36=
a84f657321ac4c8e2cc8a117e95871f12b1f36be8c4b76fa433dc4d3142e6547f4598bf4b19=
2130aea6fc20da5158b2162b5a899957da05ded5c70907298fd885847f22a1ecb0a814fe017=
0e23cad20af64f05cc13c74e91824101afdcf5f1532fc2fde936a3a159f76283a26c738f778=
c76e6ca41fa7f134401d39027fd81de17a8021a9c0aaa9b4478fe5c0647941618f3bee410ca=
f94c248d2a64b5e45845cd77de13a5ed94034d2bc5f457887351993c1ecfa34fd0c658fea3f=
8086d26808eef976262ecf0ad646b627945511dde83e26609cd5cfd7ed9f6207d76618b44c4=
8bf623bf420dc7c127e5d5f529f083b71a17b17da329bfc38a74bf8cfcf315c7c070b71ebfa=
e3ab351341a767adfdd9e57c738f5de9da53711e886d1472310b917a1c9798e3e9b13c7c74b=
eb8d1b82345bea1349415679a9c64b0433b68c871ae08092a1f6106bc06337cd343866ee818=
5c03fcf3bb0666453f847905547199414c1e57535747be61cdf6778378f121d68df0181ee9e=
8d9932c1c593c0f8c0a1af0f5262b86205002dced9ecdaee2d0aa07dd4c14f98571e4bea72f=
8474f63697043e936ebb2bf9716ed0efbdc13005a75cee3a49babc61b9677764510eb19828d=
f4e10fb38b79a1efbf04cc2d571949d5403f797361743dcc5e3bf3b4396f7ae1a3affbc9f72=
e540d920363970307e0725fa838d611803251a4a08ccca1983d5b29a583758be63343e88f55=
91d885b8af695f33adbdd0d941d260287e32ef5a98fd55ac137211021fdc23b5d7a5469f578=
bf7aff6529117996f9ebab5e6dc7b047b356332fea82fdd620eb86f3c1d3855c8b8075da59a=
7662f4a11b977d996b8b3c7657ad4a82a20a7f76ce376c0320086ed029dd615399307983113=
cc0aa973ecba691e7e4cdc80aefa7e8c8347baba050eaca7dc35a21aa854e531dc7758d7d10=
b8c8e42c1be3bbf266d055ac25c37279ebefa28bbe89a34ad1ab3d23d7a66d1c216a57650e6=
ec9fc8ba7adfb38e57f20c467166c8fe7944e67f82138160002004812c78ba4b5f0da917da4=
cc14cf8fc10dba3f533facb11ef06d8b8f178ea9c5e8acbbca7b7f0e1f6b7a70ec2d5108cc4=
1178056295793bed357accbb03c0582dc69bc77a34030f38cce256c5a9cec6e862146e3f046=
3f10dd5833257d0a0359166a7e2027d98eaf26cf0d5a4a05f6ef8b742f5d314a31deeeabe4e=
bc3106547e79c6cb933105d907b4c8c60443e97a154694bab5edfc781a438675b9de6ed03c7=
7f51458eab61ca2e80ac02cc8c037d8fb3cf129d7107f618d66032cc02238a211f78bfa44e7=
c1bbcfcc627771c188d1b3713ce5e75cd2325a0a2ba08268cad13b27d97696ef678b592d0ac=
80ad1bacb4a1ba75bea8c477f39fc32c2aa20f352bb0da1c49b7d3927bcd9dfaf229237081d=
5fa08924fefd923ff0ac6baad6864b7c10dc73379a5ebd9e4678a0c26517656e8e51fca2a51=
a33fb2cdd5d76d12674c240ba9a4893c1af69b8f2c4adf37c4a47551eb2006a732f6b3b2f33=
8c078ede33946dfe4a55bf644d3b98848693ada1fcb6fc16cac339ee65c24dc64b0ae920053=
54af00ade71e6c5e2efd85c46131d948ff14096b0f06a41d83c8522f30beb4eaaf4a6f908fe=
2a6ee754c896
>
>
> GENERATE THE KEYS
> Cleartext keys: cid=3D06b858ec6f80452b initial_salt=3D9c108f98520a5c5c329=
68e950e8a2c5fe06d6c38
>
> initial_secret (server in) =3D 7e0aba2c4b9742d0d130bc7318622ad3b44aca1f09=
abb19b3f394cd7e20f4be0
> key=3D26080e60d288db7df816a1cb0bc6c7f4 iv=3Db9fdc5b448af3e023422443b pn=
=3D00babbe1be0f0c6618188b4fcca57a96
>
> Cleartext keys: cid=3D06b858ec6f80452b initial_salt=3D9c108f98520a5c5c329=
68e950e8a2c5fe06d6c38
> initial_secret (client in) =3D 82a73572e7cb89523b68c39eaa8325404f86498c8e=
2437dfdce10f9c34281a3d
> key=3Da79943566c41342f2bc3de6b7c1539df iv=3D84eb954ffe161c3875919f5f pn=
=3D5c0f6472a15658047a3cc1f15478dcf4
>
> PNE DECRYPTION
> PNE sample_offset=3D21 sample=3Dc2973fa0d63fd9b03a4e163b990dd778
> Decoded PN block (unknown length): c0000000
> Packet number: 0 length=3D4
>