From nobody Thu Dec 1 15:11:46 2016 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 BCCAB129439 for ; Thu, 1 Dec 2016 15:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 U38QwAC1PEfM for ; Thu, 1 Dec 2016 15:11:40 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 210BD12952B for ; Thu, 1 Dec 2016 15:11:40 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id w33so236069797qtc.3 for ; Thu, 01 Dec 2016 15:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mZjkMePJxyvF9wEDK6+WQQfU72CY0qT0hCwxTPfj2js=; b=ynGzeAQiuC6v23UGyNBtgutWJUkMujGe7ZbJo5FVlawX9uhNCAbDzn08lGxXPcj5gm VJNWPUWNZlP8ZGCb7MMXm3byp9Gf9lTIk2j8rj98oX4hzA6d5qIlEqZ6TpcBSELtftGW Q8jbbIbMNlZRHtDyhnuMlS5PFOGyaQXBQTrrXdQy90yz9rcBBHI/7KsYaZR1hX0Pwc6C heJ9TuRwBUid+OqlRWVutz7Wr+8VlFEzNP6I+C/45rmU/JbBn1tJMRMdCA/zYWVYVNYo XVwskU0psFGv9azKzdWLoBrNBJhsh/Jrb7WIsLY6dQLFy40PBOoye7DOxMo/DfpVz24A o5sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mZjkMePJxyvF9wEDK6+WQQfU72CY0qT0hCwxTPfj2js=; b=UL18pY4bR4rtizN3ZFRYuPEAimyPabYG9OClGxVzeYrLlbFNQ9vn0e+XiaKEpRqvLv Ds5H4gXWbRZ8dzyGesVryfuhShiZVRGl91y9Ceg81uYRB1PpiIBbCCYeH9o4Grp2ZW5O J1IvadvfDJGXk7wELkYFZvpZmQua9jAchYqsTLuIgpnie1MWFpLvHgayhBPkzbS2J7O6 ciV2iTX298nyhQyEmPYEHGTWoJNHsXQzurU6/u124MQnAvuIAp+0vFzX/gOYwjdAZRa/ Zm+xLClwkAbzVtPYYN3oTmyENZCsaRQerdUdJaeyibSLbtvZCffFvBb2LDgqWa/XVmJI x2JA== X-Gm-Message-State: AKaTC008hRpT8KuqHYikRvyRiPrrKxJos0CDQ9xWoxXDMTar57E/JTTTrtdELdnMX+y25fLbLHIptBshccZI/A== X-Received: by 10.200.41.248 with SMTP id 53mr39862044qtt.3.1480633899277; Thu, 01 Dec 2016 15:11:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Thu, 1 Dec 2016 15:11:38 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 2 Dec 2016 10:11:38 +1100 Message-ID: Subject: Re: QUIC-TLS pull requests To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 01 Dec 2016 23:11:44 -0000 On 1 December 2016 at 16:50, Martin Duke wrote: > The interface document is a huge improvement. What I think is missing is the > various transport parameters that I believe the quic-transport document says > QUIC will deliver to TLS to include in handshake messages, and similarly > pull from TLS for processin when decrypted. It's on the list: https://github.com/quicwg/base-drafts/issues/49 From nobody Thu Dec 1 15:35:29 2016 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 9E4D51295ED for ; Thu, 1 Dec 2016 15:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 cZhYqW2vXq2t for ; Thu, 1 Dec 2016 15:35:24 -0800 (PST) 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 7D496129465 for ; Thu, 1 Dec 2016 15:35:24 -0800 (PST) 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; bh=kOEvmM3ri7RP0nWAIRjVOUS9B5gFm+7aZWK/rp7ymr8=; b=Q2qVcJx6S1uxbaI4rKM2iN4xYs0l240By4CZMoqqpKpjeQCUGrbG0K0fO0TKehPY0ps2XqsvZpHVrXT1cShEfPshWFEIW7oYfbDmXx5t+b9ZtmXqEFAFFBgDEntrvtEhZRXONzVJ9/1G6PfJnf8+wmjCvj5sYIG+rXR2V/wSMrg= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Thu, 1 Dec 2016 23:35:23 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.018; Thu, 1 Dec 2016 23:35:23 +0000 From: Mike Bishop To: IETF QUIC WG Subject: HTTP Mapping: Fixing streams-in-streams Thread-Topic: HTTP Mapping: Fixing streams-in-streams Thread-Index: AdJMK4UPnpRSHPYRT8al2LR5lm7ZTw== Date: Thu, 1 Dec 2016 23:35:22 +0000 Message-ID: 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=Michael.Bishop@microsoft.com; x-originating-ip: [167.220.61.243] x-ms-office365-filtering-correlation-id: a7671ea0-d1ab-400b-f222-08d41a42b876 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:dnAMZhlNGnQ3qWKHHr6EUiND7AhI8PuPak2gBZYTo2IKLteQ6DgMRBeQJJPg+7TylCx/VNgvAiwxskOf0i+xTqHs/omN1MJ3TRguaZcupvJjA2iqiJ9T4HsbAGdha6XdCb6Lntu8MxAcpeaLNWQ/kcw/2whFF5L54owRAzAxXk4boA5SE1SNg9caYhfBXKegW9K42vXB7qJ+KijlbMJjWqa/lMR6HKQCWr+CKhFZ6Ii6OerTIXoRWb3AB6E2SQrzacAHborM0CBPZCKa3FalT0PICCPgHlphfcRyFM0rYmADdLg5oTthx4K9+74A08y0hw7sqnCqk0Z0fc+8M6yxon2qz3gDacgU5ftGYvGByg9Mx+Z+Q4LDoM4xs73bZ+ulC/50cWPlcdZPz2Pq0QojsPNpq4LOBUI7UR8BCpN5NA9ifPTKSNu25nE09w0NkXMl7Uh+tjvzgSzu2jgAo06HzN1WwAV5pgRtU/wkA6Se6Gs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558021)(20161123564025)(20161123555025)(20161123562025)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(8936002)(102836003)(2906002)(7906003)(7736002)(3846002)(6116002)(81166006)(86612001)(8990500004)(122556002)(7846002)(39450400002)(77096006)(81156014)(561944003)(606004)(33656002)(790700001)(10090500001)(86362001)(97736004)(92566002)(74316002)(3660700001)(3280700002)(230783001)(39410400001)(54356999)(76576001)(450100001)(68736007)(106356001)(6506004)(50986999)(66066001)(10290500002)(2900100001)(5660300001)(7696004)(99286002)(8676002)(189998001)(107886002)(5005710100001)(9686002)(110136003)(6916009)(101416001)(105586002)(38730400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27084E4209327BD54256A5CA878F0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2016 23:35:22.8667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 01 Dec 2016 23:35:28 -0000 --_000_BN6PR03MB27084E4209327BD54256A5CA878F0BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have the existing document which puts everything on a single stream and = retains HTTP/2 framing. At the WG meeting, I heard substantial desire to m= ove as much as possible off to separate streams per request. There was als= o discussion about how to modify HPACK (Buck has a proposal via e-mail; I h= ave a draft) to enable this, but from side conversations, I think there's a= lso a desire to reuse HPACK code where possible and minimize changes. What I'd like to propose as the path forward is this: * Change the mapping document to use the two-streams-per-request model = described in draft-bishop-quic-http-and-qpack section 3.1 with some of the frame redefin= itions from section 3.2. * Augment header-bearing frames with a sequence number * Continue to use unmodified HPACK with a requirement that frames be fe= d to the decoder in order for now This should produce no worse head-of-line blocking than currently exists, r= euses existing HPACK code, and lets us make progress on the current draft. = In parallel and as we have people to work on it, we can decide to what ext= ent we want to modify HPACK to reduce HOL-blocking issues. (I'd encourage = Buck to generate a short draft on his idea as well, so we have two ideas to= compare.) I'd specifically like opinions from the WG on whether that's the path we wa= nt to move forward with, or if there's an alternative I haven't heard. If = that's acceptable to the WG, I'll start a pull request for review. --_000_BN6PR03MB27084E4209327BD54256A5CA878F0BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have the existing document which puts everything = on a single stream and retains HTTP/2 framing.  At the WG meeting, I h= eard substantial desire to move as much as possible off to separate streams= per request.  There was also discussion about how to modify HPACK (Buck has a proposal via e-mail; I have a draft)= to enable this, but from side conversations, I think there’s also a = desire to reuse HPACK code where possible and minimize changes.<= /p>

 

What I’d like to propose as the path forward i= s this:

  • Change the mapping document to use the two-streams-per-request model = described in dr= aft-bishop-quic-http-and-qpack section 3.1 with some of the frame redef= initions from section 3.2.
  • Augment header-bearing fram= es with a sequence number
  • Continue to use unmodified H= PACK with a requirement that frames be fed to the decoder in order for now<= o:p>

 

This should produce no worse head-of-line blocking t= han currently exists, reuses existing HPACK code, and lets us make progress= on the current draft.  In parallel and as we have people to work on i= t, we can decide to what extent we want to modify HPACK to reduce HOL-blocking issues.  (I’d encourage = Buck to generate a short draft on his idea as well, so we have two ideas to= compare.)

 

I’d specifically like opinions from the WG on = whether that’s the path we want to move forward with, or if thereR= 17;s an alternative I haven’t heard.  If that’s acceptable= to the WG, I’ll start a pull request for review.

--_000_BN6PR03MB27084E4209327BD54256A5CA878F0BN6PR03MB2708namp_-- From nobody Thu Dec 1 16:00:25 2016 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 066D9129A31 for ; Thu, 1 Dec 2016 16:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 LeHeOW9WQvi1 for ; Thu, 1 Dec 2016 16:00:20 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 DB620129A2D for ; Thu, 1 Dec 2016 15:59:42 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n21so263007036qka.3 for ; Thu, 01 Dec 2016 15:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3rmRKCXrke4j2b5f243Nw5SF2gX29dwWsT869oWtuks=; b=ZWQMK7P3oifFnipjzNHFNRZK7iaK9tB1+CBtf0TDlWFFUk7OQEabvXevBudQyDgiLl S5E0UNaCoLgVxLqMbw0H6R2bl94b211x+PZPLZlzTd1EEpU6CrIThXkQ2A+1OZmtlUF4 B630w8qQxOj3A+4gW8X3cjz3WY0OguDFppOawm+MoPph4IMCxVnwarFQUmRU+DT2+4km 1FfjtKrJBEOAppwPPjh/yClESy36fwiuf7hTjQUk2uVAM1KIxBihmeVTSnlJoOhLsn0B dpCADIYaFbOI1enMxMHTL1dgq/mlMHhRFIy9ANpd4d3NCfhQA7BCJYhRuoQReN5E3VZO STSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3rmRKCXrke4j2b5f243Nw5SF2gX29dwWsT869oWtuks=; b=I4d9/BgV8PI0Xwvnio1q8+J49rABBbY6Llo9PRplRfsqGgNiVRNcWcSNPCbm4wXAaB nK2HcdCy7Wg/byirVQ2gWsOFLENIwaXvbnzdNdGlBI8WqsdlawWaKqJ3nK1ju0ERvceY 6tnJrQmnJG1L+6hUNuj4VJZbVGTWbvTFvN4DkTFx5UkQyoIxGX/9vbCIAC7okH6dqWLI TnFdFYA9FQICLVAVO0HxQ+LKNs7QT5w2lAGzlMAWxl5wuuZKOeVnbwJzugwPh7yIdn/Q PKHqkXkQUMbb6lKXoZnM9xC8T++8QyjB/SfYpFIWPsjJ4UiHUwY2hbYMFsMcNiMjSrRr 4Z5A== X-Gm-Message-State: AKaTC03TJo4WvPlHqt2jn8vF3soHj03GYdF/4pOqpOD87f0Bt+R1gNlZWjb6qZ4DkXgBFUqwOrtTMBrPpaaNIA== X-Received: by 10.55.158.199 with SMTP id h190mr40077228qke.202.1480636781917; Thu, 01 Dec 2016 15:59:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Thu, 1 Dec 2016 15:59:41 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 2 Dec 2016 10:59:41 +1100 Message-ID: Subject: Re: Comments on draft-ietf-quic-transport-00 To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Dec 2016 00:00:23 -0000 Hi Martin, I've opened issues for your versioning and flags questions. See inline. On 1 December 2016 at 16:41, Martin Duke wrote: > Section 4.1. Common Header. https://github.com/quicwg/base-drafts/issues/55 https://github.com/quicwg/base-drafts/issues/56 > Section 4.2. Regular Packets. The version field should immediately follow > the public flags Note that Google might have a hard time deploying your suggestion for changing the packet layout; but I won't argue that point because I have no deployed code :) But see the above issues. > Section 4.2.1. Should receivers enforce that packet numbers are long enough? https://github.com/quicwg/base-drafts/issues/57 > Section 4.2.2 Frame types. I think we need an "experimental" frame type, It's so refreshing to have this conversation early in the design process. https://github.com/quicwg/base-drafts/issues/58 > Section 4.4. Public Reset. Yep, let's continue that discussion separately. > Separately, what is the Connection ID we MUST use if the client never > generated one? I don't understand. The client is obligated to generate one, right? "This must be set in all packets until negotiated to a different value for a given direction." > Section 5.1. Version Negotiation. This mechanism is completely vulnerable to > DoS by eavesdropper at connection startup. An attacker can sniff the client > hello and spoof a server version negotiation message that only advertises > nonexistent versions, preventing connection. Yes. An attacker can also tweak the TLS ServerHello or ClientHello in any way they choose to prevent that from completing too. I don't believe that there is any defense against this style of DoS prior to having a shared secret. > As with Public Resets, a short waiting period before abandoning the > connection would solve the problem. This is harder than you think. TLS implementations generally don't defend against this over TCP either, though the attack is perfectly feasible there as well (though the attack arguably requires more resources to break into TCP). The problem is that there are lots of perfectly valid TLS messages and processing any of them creates a bunch of state. Reverting that state is non-trivial. Yeah, we could do it, but I'm not sure that anyone will implement it. > Section 5.2.1. ICSL is missing here, even though it is listed as mandatory > in 5.4. https://github.com/quicwg/base-drafts/issues/59 > Section 5.2.2. You mention "stateless rejects" here, but the draft could > really use a full section on it. https://github.com/quicwg/base-drafts/issues/60 > Section 5.3. Do we need an ADD_ADDR message to advertise additional > addresses, in the event that address is unreachable from the peer's > currently known addresses? Given how big the pile of work is already, I would prefer to defer working on this sort of thing. Feel free to open an issue though. > What is a "silent close option?" Is this negotiated or just a > sysctl/sockopt? If negotiated, we need more details. https://github.com/quicwg/base-drafts/issues/61 > Instead, I recommend that all fields necessary for frame length computation > are first in the frame. https://github.com/quicwg/base-drafts/issues/62 > section 6.2 Ack frames: I am unclear about the procedure for including ACK > blocks in a particular frame. https://github.com/quicwg/base-drafts/issues/63 > Section 7. PMTU discovery: https://github.com/quicwg/base-drafts/issues/64 > Section 9. Why are BLOCKED frames a MUST? They are sort of like TCP persist > probes, but WINDOW_UPDATE messages are delivered reliably in QUIC, so > BLOCKED has no input on operation. If the purpose is debugging only this > ought to be no more than a SHOULD, and probably a MAY. Ahh, the BLOCKED issue was a sore point in HTTP/2. I look forward to another lively discussion. AIUI, it's not a deadlock issue, because you can always recover from flow control issues, but it is useful in providing feedback for performance tuning. https://github.com/quicwg/base-drafts/issues/65 > Nits: I got most of these, thanks. > Section 7. Withholding packets to wait for more frames: I suggest some sort > of bound on how long the sender can wait. That's a design issue, I think, but I don't know what to write in it. From nobody Fri Dec 2 04:10:10 2016 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 315A8129E9A for ; Fri, 2 Dec 2016 04:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 iGYYp_nlAvfg for ; Fri, 2 Dec 2016 04:10:05 -0800 (PST) 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 9841A129DE6 for ; Fri, 2 Dec 2016 04:10:02 -0800 (PST) X-AuditID: c1b4fb3a-97bff70000007918-b4-58416497e28a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 8A.0E.31000.79461485; Fri, 2 Dec 2016 13:10:00 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 2 Dec 2016 13:09:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hG1JD2NNWJEyw7CZFu3Eg5VRJ4Ebj8DhBfuJQKGgJdY=; b=SPLy337TjDB1GmIfTGx323XQ7jxJ4pgVmuhhdKrQtmayxALkgbNehXwMJY2+Dg3joW95QAf6JQMnHj8hjgGm7tG9TzA3BBV2dxzDMtPsrlyeObVKJYOL0binMDSuLIhz5SkvTsUGr6Sxt9Smkc7WYPo/Ia+ZHNVnMb6uToJoIRY= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB350.eurprd07.prod.outlook.com (10.141.12.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Fri, 2 Dec 2016 12:09:58 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) by DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) with mapi id 15.01.0761.012; Fri, 2 Dec 2016 12:09:58 +0000 From: Ingemar Johansson S To: "quic@ietf.org" Subject: ECN support in QUIC Thread-Topic: ECN support in QUIC Thread-Index: AdJMlPQfSxtqvt4NTzup1wwKcj82KA== Date: Fri, 2 Dec 2016 12:09:58 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-office365-filtering-correlation-id: 933e7592-7766-4f1d-bf7e-08d41aac228e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DBXPR07MB350; x-microsoft-exchange-diagnostics: 1; DBXPR07MB350; 7:+V/TiYl32nMyPvltzRuPm8nezjObEcP8BNdLNKpd12eumfLkUkkfZ38lzzZ/7iYQIOfTfrWalllTvms3iccqQZCtnRe1+Ujbc8vBK/pmkXQi+j06bpLUHJnPmlnRQSf7ubNR4LIaMYJzOWlY88334xBbIy3pNfy3Kw8oeweidN1ZtbRDsC5/eUPPhBlydEIylrABhVBoPNP6I9trm1zVrXE2tUjFLnRyAeQireH6zXTP7AHmS3amTqAGjV6WJJycNncU76QYIOg1qT5iV9RFDGM5LTFRXI4fdC8j0lwFhOgI8C9PA+UlwpvgdTtc68W+QV6QmRE4DGN66Xc3bp+zTQRtr8M5mHouRx7uRzIT8muf/dvRC/NOLWEt3vt1dMAkFtCLGT0CMZgFu1FUO7VrwJKMlFSdcGSTjxQAvq8JQyD4dVKBcQeZ0r83Rm8g8Zd6J6YXoMLUWxYlSYKVoQYbfg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(6042181)(6072148); SRVR:DBXPR07MB350; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB350; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(74316002)(86362001)(2351001)(189998001)(50986999)(450100001)(106356001)(105586002)(54356999)(66066001)(790700001)(102836003)(6116002)(3846002)(101416001)(107886002)(97736004)(3660700001)(6506004)(5660300001)(606004)(38730400001)(8936002)(77096006)(3280700002)(19609705001)(7906003)(122556002)(5630700001)(92566002)(5640700001)(33656002)(3480700004)(2906002)(1730700003)(7846002)(7736002)(68736007)(9326002)(110136003)(2501003)(81156014)(81166006)(7696004)(9686002)(2900100001)(6916009)(8676002)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB350; H:DBXPR07MB351.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB351F5EEC751B5967C07CDCDC28E0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 12:09:58.1979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB350 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGOffezet0etsU/6hFzehD4TQTTVkx+xBGSVqRSz/U0JsbzU12 l2QvsMQMZ/bqSM18qWkZzGJZahjiFM2BmmH4gjVK0VTEMEJlMHI7Bvv2O8/z45z7wKVJUR0v nFZrDaxeq9RI+AKqWtEeG12Vm6KI/ToXf/BOQ4AcpVosG0Q6yhLIclmNupDVxxy+IFC9MZcS BQ75laY2I2FEn5JNyJ8GJh5sq32UCQloEdOKYMK96IcPAwiGy+ZIj0UxFSTU/+Rw8ZAA2/xj hA+9CIxdw4TH4jMyaLGvIQ+HMFFQ2/R88yqaFjOR8KizCMe7wDa1QGKWQnd5CcIP7IYfbb1e FjJZMDPQ53UQsx2ca98pD5NMGEzN1hP4sxmwdI2QmENhYcbNw34OrE5W8HC+EwZeLvMxp4Gj tGorPwFDVpd3MjDlFJSsrPvhQg0mS/OWlA2V/SY+lhoJeFr3h8JFJJjrjSQuHDyY6G7wFiKG hRfWW94JYiYcvo2VbXEk/Jr+yMMTdFC50EThmdtgsHqWuo/21Pisq/HRanw0nEthwlzJx7wP mhuXSMzRUOW2U755A/J7hUI5luPy8+LipKxencNxOq1UyxpsaPOv6WlzJXegnvkUO2JoJAkU /k6WK0Q8ZSFXlG9HQJOSEGFwTopCJMxVFl1l9brz+ssalrOjCJqShAkTWpyZIiZPaWAvsWwB q//fErR/uBEZr6WPCoPlc9bOgM/Lk7dlQe6Me0sy5w6YvnugI+liyIfM8fdjQ7Wj8vLiJ+2L GT39Xaqk1+OakQjzekL1qbf5mqiCOOZG0KF3N4/OOhJBdV2HTopTp1sDjxxXrNTGuJpd2WLi bygYLM/OJjpPD1YcQ8Vp59LPRJs3Gq1fHpRIKE6l3L+X1HPKf0x6eMwxAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Dec 2016 12:10:09 -0000 --_000_DBXPR07MB351F5EEC751B5967C07CDCDC28E0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I commented a little on draft-iyengar-quic-loss-recovery-01 https://mailarchive.ietf.org/arch/msg/quic/qhYslAmlbPPCaF57Qm70_Trg4XQ Realize that he draft was renamed to draft-ietf-quic-recovery shortly afte= r. I will read it and see if my comments are still valid. I have one question though as regards to ECN support in QUIC, where will th= is be described. I can imagine that parts of it will go in quic-recovery bu= t I assume that quic-transport needs an update for the protocol specifics, = does the handshake and negotiation as well as possible fallback upon failur= e go there as well. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com No, you can=B4t tell people anything You've got to show 'em Bruce Springsteen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DBXPR07MB351F5EEC751B5967C07CDCDC28E0DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I commented a little on  draft-iyengar-quic-los= s-recovery-01

https://mailarchive.ietf.org/arch/msg/quic/q= hYslAmlbPPCaF57Qm70_Trg4XQ

Realize that he draft was renamed to draft-ietf-quic= -recovery shortly  after. I will read it and see if my comments are st= ill valid.

 

I have one question though as regards to ECN support= in QUIC, where will this be described. I can imagine that parts of it will= go in quic-recovery but I assume that quic-transport needs an update for t= he protocol specifics, does the handshake and negotiation as well as possible fallback upon failure go there as well= .

 

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

 =     No, you can=B4t tell people anything

 =         You’ve got to show ‘= em

 =              Br= uce Springsteen
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_DBXPR07MB351F5EEC751B5967C07CDCDC28E0DBXPR07MB351eurprd_-- From nobody Sat Dec 3 07:40:32 2016 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 C7BB91298B2 for ; Sat, 3 Dec 2016 07:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 nYqVCo-xKU2T for ; Sat, 3 Dec 2016 07:40:28 -0800 (PST) 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 6D0881298AD for ; Sat, 3 Dec 2016 07:40:28 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id v78so47137586ybe.3 for ; Sat, 03 Dec 2016 07:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fHvA+rJDu7elWh4adarDAgyutc4C2/pEGc+umZPy1wk=; b=F9v6ueDhk6U08fUG4Zx0pML4geZUk8RPz/jwMquavTYyvkc71e24SXQSB4WWTw4Jl5 AmyrTUBfZAguOSgwBh0/3tSUSBsTdpdpFUWg+Un0y6smwlsnoFVfpnQqSiQOI6fe1QiU /6jccg2Cj5dbDox2hqWv8OKJ08UeRHmwfiGV7iADnNDEE9USdXcfcjCXqmpFhqb8Q79C LWGePXLAFnpvAT7rdAi2VRGbaX0VUBC3IHbAJfjU+zCIFLiRnxkdtkrvgkEwQbf+XHx5 +AI3E2Ip9NbMRqtTLglHRkBwtOLUiCdiuKSZC2MEZ6Nz8aIEjRNeNAuC/X2tA9QcUv5/ yInQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fHvA+rJDu7elWh4adarDAgyutc4C2/pEGc+umZPy1wk=; b=KVNZ9EuJ1tSE+NFUqkzKviPcIR9GQAHHvHYBUi9AXYODC9rLbxZlZhKVLjzEZAC1gs ZQU1DRl+5x8dV/hnuQgUkVPt3Qc4MSA4IOGlo4aVdvQLVSK4MZsRxZ4SQNzxwUfOfvw8 yXxP/qTmo7blM2QxpIGJjdvEkUyBsci5HEWjSaiUoL0Yb7DFLfD1LnbDK8hcNYVXuD2t cCKQjwepCPHZPwq5BTd7jkxVMFrUk6iEB0T+wbyEhI6JDlxOMlP2AmqXynb1oqARQoF3 iGFHa//sobKs2kvyNGlw7CG6E8gIhsQXcjIz7aK18GYcKXO5SlLxvtHm++NHO7D30oPS cwmA== X-Gm-Message-State: AKaTC02A0uu9GiG+hgIlXLcrbc/3AwRZylK5zrPUrXSCBNGKTgeThNFi0+8tdmBgKwjZlZKdAiWwHWAAVjQa4IRX X-Received: by 10.37.173.232 with SMTP id d40mr22540852ybe.73.1480779627540; Sat, 03 Dec 2016 07:40:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Sat, 3 Dec 2016 07:40:06 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sat, 3 Dec 2016 10:40:06 -0500 Message-ID: Subject: Re: ECN support in QUIC To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=f403045ecd54b136b90542c2dfa2 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Dec 2016 15:40:31 -0000 --f403045ecd54b136b90542c2dfa2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good point, I added an open issue for ECN. Feel free to add any comments there. https://github.com/quicwg/base-drafts/issues/68 On Fri, Dec 2, 2016 at 7:09 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > I commented a little on draft-iyengar-quic-loss-recovery-01 > > https://mailarchive.ietf.org/arch/msg/quic/qhYslAmlbPPCaF57Qm70_Trg4XQ > > Realize that he draft was renamed to draft-ietf-quic-recovery shortly > after. I will read it and see if my comments are still valid. > > > > I have one question though as regards to ECN support in QUIC, where will > this be described. I can imagine that parts of it will go in quic-recover= y > but I assume that quic-transport needs an update for the protocol > specifics, does the handshake and negotiation as well as possible fallbac= k > upon failure go there as well. > > > > /Ingemar > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 <+46%2073%20078%2032%2089> > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > No, you can=C2=B4t tell people anything > > You=E2=80=99ve got to show =E2=80=98em > > Bruce Springsteen > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --f403045ecd54b136b90542c2dfa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point, I added an open issue for ECN.=C2=A0 Feel free= to add any comments there.


On Fri, Dec 2, 2016 at 7:09 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi

=C2=A0

I commented a little on =C2=A0draft-iyengar-quic-los= s-recovery-01

https://mailarchive.ietf.o= rg/arch/msg/quic/qhYslAmlbPPCaF57Qm70_Trg4XQ

Realize that he draft was renamed to draft-ietf-quic= -recovery shortly =C2=A0after. I will read it and see if my comments are st= ill valid.

=C2=A0

I have one question though as regards to ECN support= in QUIC, where will this be described. I can imagine that parts of it will= go in quic-recovery but I assume that quic-transport needs an update for t= he protocol specifics, does the handshake and negotiation as well as possible fallback upon failure go there as well= .

=C2=A0

/Ingemar

=C2=A0

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Ingemar Johansson=C2=A0= M.Sc.

Master Researcher

=C2=A0

Ericsson AB

Wireless Access Network= s

Labratoriegr=C3=A4nd 11=

971 28, Lule=C3=A5, Swe= den

Phone +46-1071 43042=

SMS/MMS +46-73 0= 78 3289

ingemar.s.johanss= on@ericsson.com

www.ericsson.com=

<= /u>=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0 No, you can=C2=B4t tell people anything

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 You=E2=80=99ve got to show =E2= =80=98em

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Br= uce Springsteen
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0


--f403045ecd54b136b90542c2dfa2-- From nobody Mon Dec 5 01:17:33 2016 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 C110A1295B8 for ; Mon, 5 Dec 2016 01:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 2623b-5YlrtB for ; Mon, 5 Dec 2016 01:17:30 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4AFF9129849 for ; Mon, 5 Dec 2016 01:17:28 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-a6-584530a728f0 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 37.05.32482.7A035485; Mon, 5 Dec 2016 10:17:27 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 5 Dec 2016 10:16:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XKQiDl16kX6jTi5oUBiqqavU4J4OayTnlXrSTEfYSt0=; b=LleyDtRWtlotH/NKDBRebbOQLVmmJ+R0o5NE+zGA8kgz8V0qsrevFocoyh/B/5uo4RXacNN1ZE0jqeROYn0784K9hXZEoPfiE/cFdOFH+2RZmdEp/cT/wwTOsXCWqwwH4+FcaNpRqK0IYVNS5YVVaj7TRjVZCzHm5sCV2EqORmg= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Mon, 5 Dec 2016 09:16:44 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0771.006; Mon, 5 Dec 2016 09:16:44 +0000 From: Ingemar Johansson S To: Ian Swett Subject: RE: ECN support in QUIC Thread-Topic: ECN support in QUIC Thread-Index: AdJMlPQfSxtqvt4NTzup1wwKcj82KAA5pEsAAFcgRqA= Date: Mon, 5 Dec 2016 09:16:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [77.95.104.36] x-ms-office365-filtering-correlation-id: 6d276fc0-c207-4dc9-7099-08d41cef6ed5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB345; x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:ae43eBo2jSp2j5wCiZZ/2Avx/rxBtgAZ5fG7DlSekF8Fd3dhdyNtqeMjif/6c/sRTgO8Lu/UlUcU+oAlwKRo0DpxUIa8xFS3pqs4dB/VlKjB1yWVHQvFZeFaH7WdzDSoOpSVsMlUJr/KYseHLvwWd09Yl5dhBCpmjMHfyVMLWBdbB5wzDmcB9i75olUO0NIuLkz2VOX/ASWRbm5Jts7enGj1Gkr4x3SBqZ4xGBs2Qxe+qUxoX05aI6g+Dr+JojcR/4CSud0fe5ZDW9OnY8WN0hFRY1AXz2n9+FSAvMeKn2NVvK5mlpIOHtrjiqYzUVyxmDjRMzjE1cw7V2IzaRaViYaHrKahPlKYlcFvaXKuZS4SyWn+bcku+f/AsFtarQCLsxEu8YVCDlUWsPfbvpcKxTE0Vyt/ofOOMsdJQ3c1K/XuJ2Ie9SfoBjSOuUA3AhzRUHUheYgdVZoEzRlvyQwb5w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(211936372134217)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(199003)(189002)(377454003)(6916009)(19609705001)(81156014)(66066001)(7846002)(2900100001)(7736002)(3660700001)(77096006)(39450400002)(8676002)(7906003)(92566002)(3280700002)(97736004)(81166006)(39410400001)(74316002)(39850400001)(2906002)(229853002)(33656002)(54356999)(76176999)(16601075003)(6116002)(790700001)(3480700004)(3846002)(68736007)(6506006)(102836003)(106356001)(7696004)(105586002)(38730400001)(5660300001)(8936002)(122556002)(39840400001)(50986999)(76576001)(606004)(189998001)(9686002)(2950100002)(110136003)(4326007)(101416001)(86362001)(39860400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348C71A80C83DFF55E50DF4C2830DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 09:16:44.6464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85m2fa6m1pPliSWwkppWZlVlIZCvugeClo+cVOerzUvLAz Na3ABLs4J5ZiKEnGhqZU2shLZhdXJjEoKD/kyvuSBoImmkxR2vYa+O33PP8/z/N/H16WlrWI /NjsXC2vyeXUCrEnU6/qPrm/JSxWFbawuivSMfpSFFnZ5HWKUjaZCpRGo4NKpFI8o9J5dXYh rwk9ccEz68dctyi/qhNdeV1jRaXocQeqQBIW8CEwDI842ZOV4WcI/n4Yp0gxiGCxatatMFhP g+5JDUOUWgom/1SvFwMIevsaRK5hYhwFreYl92BvvBsGft5zM+3kWkup27MNB0CHyUQRjxxM VjtdgVgnH4OP09iFDN4DN5cyXA4pToGBNYeYrHqEoLmrX+wSJDgJDJXP3SMR9oexpVGGrPIF q+0hRd6Gwdj3hSbsA/aptXV/GswP60WkHwCVs90i117A8bB2N5q040D/3SImrGNg3IwJZ8P0 8vL66a6DvcJGu7IBvk3BW/sUQ4Sd0GjpQkQoE8ONr83uEDLMQ8vTckTu4AcjQ3dQNQpq2JCb cB6MGhfcLMVb4VO9jWlw5qNxELT3hhKLHGp1Ex6E90L5g0aPjf0m5NGGfAReuJiTGX4whNdk pwlCXm5ILq81Ief36X+xEtiDvs1EmxFmkWKTND80RiUTcYVCcY4ZAUsrvKUzwbEqmTSdKy7h NXmpmgI1L5jRDpZR+EojWsfOyXAmp+Uv83w+r/mvUqzErxRlcI4Cc1TRYiAV5/eKaWMkXInE kbrq4R+zUigNl/Rcu08dtcbPrR2fDvyVgONOXwqw2I4wZRHC2PYhrdKQXCR/J7aeF8ZWDHnT W2zJQZHyNxASf3aw1Nqm41Ttvw8HShPf7/PR36pznBmeuprUp1ZOwHxnnWrzZMJn/1QvBSNk cQeCaY3A/QNLKl4lOgMAAA== Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 09:17:32 -0000 --_000_DB4PR07MB348C71A80C83DFF55E50DF4C2830DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLiBBZGRlZCBzb21lIHRoZSBzcGVjaWZpY3MgYmVsb3cgb24gR2l0aHViDQovSW5nZW1h cg0KLS0tLS0tLS0tLS0tLQ0KVGhlIHNwZWNpZmljIGl0ZW1zIHRoYXQgYXJlIG5lZWRlZCBhcmUg KHBlcmhhcHMgbW9yZSA/KQ0KDQogICogICBFQ04gZWNobyBpbiBwcm90b2NvbCwgcHJlZmVycmFi bHkgYXMgYSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IHBhcnQsIFJGQzc1NjAgY2FuIHByb3ZpZGUg d2l0aCB2YWx1YWJsZSBpbnB1dCBpbiB0aGUgZGVzaWduDQogICogICBFQ04gbmVnb3RpYXRpb24s IHRoZSB3b3JrIG9uIHVwZGF0ZWQgRUNOIHNlbWFudGljcyBpbiBUU1ZXRyBzaG91bGQgYmUgYWRk cmVzc2VkIChMNFMgc3VwcG9ydCkNCiAgKiAgIEZhbGxiYWNrIGZvciBpbiB2YXJpb3VzIGZhaWx1 cmUgY2FzZXMsIGFuZCBSRkM2Njc5IGFuZCBkcmFmdC1rdWVobGV3aW5kLXRjcG0tZWNuLWZhbGxi YWNrLTAxIG1heSBwcm92aWRlIGlucHV0DQogICogICBBZGRyZXNzIHVzZXIgc3BhY2UgbGltaXRh dGlvbiwgY29sbGVjdCBiZXN0IGN1cnJlbnQgcHJhY3RpY2UgdG8gcmVhZC93cml0ZSBFQ04gYml0 cyBmb3IgZGlmZmVyZW50IE9TLg0KICAqICAgQWxpZ24gbWVhbmluZyBvZiBFQ04tQ0UgbWFya2lu ZyBvZiBFQ1QoMCkgYW5kIEVDVCgxKSB0cmFmZmljIHdpdGggVFNWV0cNCg0KDQpGcm9tOiBJYW4g U3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDogZGVuIDMgZGVjZW1iZXIg MjAxNiAxNjo0MA0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25A ZXJpY3Nzb24uY29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBFQ04gc3VwcG9y dCBpbiBRVUlDDQoNCkdvb2QgcG9pbnQsIEkgYWRkZWQgYW4gb3BlbiBpc3N1ZSBmb3IgRUNOLiAg RmVlbCBmcmVlIHRvIGFkZCBhbnkgY29tbWVudHMgdGhlcmUuDQoNCmh0dHBzOi8vZ2l0aHViLmNv bS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzY4DQoNCk9uIEZyaSwgRGVjIDIsIDIwMTYgYXQg NzowOSBBTSwgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aQ0KDQpJIGNvbW1lbnRlZCBhIGxpdHRsZSBvbiAgZHJhZnQtaXllbmdhci1xdWljLWxvc3MtcmVj b3ZlcnktMDENCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcXVpYy9xaFlz bEFtbGJQUENhRjU3UW03MF9Ucmc0WFENClJlYWxpemUgdGhhdCBoZSBkcmFmdCB3YXMgcmVuYW1l ZCB0byBkcmFmdC1pZXRmLXF1aWMtcmVjb3Zlcnkgc2hvcnRseSAgYWZ0ZXIuIEkgd2lsbCByZWFk IGl0IGFuZCBzZWUgaWYgbXkgY29tbWVudHMgYXJlIHN0aWxsIHZhbGlkLg0KDQpJIGhhdmUgb25l IHF1ZXN0aW9uIHRob3VnaCBhcyByZWdhcmRzIHRvIEVDTiBzdXBwb3J0IGluIFFVSUMsIHdoZXJl IHdpbGwgdGhpcyBiZSBkZXNjcmliZWQuIEkgY2FuIGltYWdpbmUgdGhhdCBwYXJ0cyBvZiBpdCB3 aWxsIGdvIGluIHF1aWMtcmVjb3ZlcnkgYnV0IEkgYXNzdW1lIHRoYXQgcXVpYy10cmFuc3BvcnQg bmVlZHMgYW4gdXBkYXRlIGZvciB0aGUgcHJvdG9jb2wgc3BlY2lmaWNzLCBkb2VzIHRoZSBoYW5k c2hha2UgYW5kIG5lZ290aWF0aW9uIGFzIHdlbGwgYXMgcG9zc2libGUgZmFsbGJhY2sgdXBvbiBm YWlsdXJlIGdvIHRoZXJlIGFzIHdlbGwuDQoNCi9JbmdlbWFyDQoNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCkluZ2VtYXIgSm9oYW5zc29uICBNLlNjLg0KTWFzdGVyIFJlc2Vh cmNoZXINCg0KRXJpY3Nzb24gQUINCldpcmVsZXNzIEFjY2VzcyBOZXR3b3Jrcw0KTGFicmF0b3Jp ZWdyw6RuZCAxMQ0KOTcxIDI4LCBMdWxlw6UsIFN3ZWRlbg0KUGhvbmUgKzQ2LTEwNzEgNDMwNDIN ClNNUy9NTVMgKzQ2LTczIDA3OCAzMjg5PHRlbDorNDYlMjA3MyUyMDA3OCUyMDMyJTIwODk+DQpp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb20+DQp3d3cuZXJpY3Nzb24uY29tPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29t Pg0KDQogICAgIE5vLCB5b3UgY2FuwrR0IHRlbGwgcGVvcGxlIGFueXRoaW5nDQogICAgICAgICBZ b3XigJl2ZSBnb3QgdG8gc2hvdyDigJhlbQ0KICAgICAgICAgICAgICBCcnVjZSBTcHJpbmdzdGVl bg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg== --_000_DB4PR07MB348C71A80C83DFF55E50DF4C2830DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2 Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoxNDI4NTA1NjY5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MjA0MTAzMjQ0NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGFua3MuIEFkZGVkIHNvbWUgdGhlIHNwZWNpZmljcyBiZWxvdyBvbiBHaXRo dWI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPi9JbmdlbWFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMzMzMzMzIj5UaGUgc3BlY2lmaWMgaXRlbXMgdGhhdCBhcmUgbmVlZGVkIGFyZSAocGVyaGFw cyBtb3JlID8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+RUNOIGVjaG8gaW4gcHJvdG9jb2ws IHByZWZlcnJhYmx5IGFzIGEgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBwYXJ0LCBSRkM3NTYwIGNh biBwcm92aWRlIHdpdGggdmFsdWFibGUgaW5wdXQgaW4gdGhlIGRlc2lnbjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdp bi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5FQ04gbmVnb3RpYXRp b24sIHRoZSB3b3JrIG9uIHVwZGF0ZWQgRUNOIHNlbWFudGljcyBpbiBUU1ZXRyBzaG91bGQgYmUg YWRkcmVzc2VkIChMNFMgc3VwcG9ydCk8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+RmFsbGJhY2sgZm9yIGluIHZhcmlvdXMgZmFpbHVyZSBj YXNlcywgYW5kIFJGQzY2NzkgYW5kIGRyYWZ0LWt1ZWhsZXdpbmQtdGNwbS1lY24tZmFsbGJhY2st MDEgbWF5IHByb3ZpZGUgaW5wdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZiI+QWRkcmVzcyB1c2VyIHNwYWNlIGxpbWl0YXRpb24sIGNvbGxl Y3QgYmVzdCBjdXJyZW50IHByYWN0aWNlIHRvIHJlYWQvd3JpdGUgRUNOIGJpdHMgZm9yIGRpZmZl cmVudCBPUy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZiI+QWxpZ24gbWVhbmluZyBvZiBFQ04tQ0UgbWFya2luZyBvZiBFQ1QoMCkgYW5kIEVD VCgxKSB0cmFmZmljIHdpdGggVFNWV0c8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAzIGRlY2VtYmVyIDIw MTYgMTY6NDA8YnI+DQo8Yj5Ubzo8L2I+IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIu cy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gcXVpY0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRUNOIHN1cHBvcnQgaW4gUVVJQzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIHBvaW50LCBJ IGFkZGVkIGFuIG9wZW4gaXNzdWUgZm9yIEVDTi4mbmJzcDsgRmVlbCBmcmVlIHRvIGFkZCBhbnkg Y29tbWVudHMgdGhlcmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vl cy82OCI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNjg8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgRGVjIDIsIDIwMTYgYXQgNzowOSBBTSwgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i bGFuayI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgY29tbWVudGVkIGEgbGl0dGxl IG9uICZuYnNwO2RyYWZ0LWl5ZW5nYXItcXVpYy1sb3NzLXJlY292ZXJ5LTAxPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvcXVpYy9xaFlzbEFtbGJQUENhRjU3UW03MF9Ucmc0WFEiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3F1aWMvcWhZ c2xBbWxiUFBDYUY1N1FtNzBfVHJnNFhRPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5SZWFsaXplIHRoYXQgaGUgZHJhZnQgd2FzIHJlbmFtZWQgdG8gZHJhZnQtaWV0 Zi1xdWljLXJlY292ZXJ5IHNob3J0bHkgJm5ic3A7YWZ0ZXIuIEkgd2lsbCByZWFkIGl0IGFuZCBz ZWUgaWYgbXkgY29tbWVudHMgYXJlIHN0aWxsIHZhbGlkLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGhhdmUgb25lIHF1ZXN0aW9uIHRob3VnaCBhcyByZWdhcmRzIHRvIEVDTiBzdXBw b3J0IGluIFFVSUMsIHdoZXJlIHdpbGwgdGhpcyBiZSBkZXNjcmliZWQuIEkgY2FuIGltYWdpbmUg dGhhdCBwYXJ0cyBvZiBpdCB3aWxsIGdvIGluIHF1aWMtcmVjb3ZlcnkgYnV0IEkgYXNzdW1lIHRo YXQgcXVpYy10cmFuc3BvcnQNCiBuZWVkcyBhbiB1cGRhdGUgZm9yIHRoZSBwcm90b2NvbCBzcGVj aWZpY3MsIGRvZXMgdGhlIGhhbmRzaGFrZSBhbmQgbmVnb3RpYXRpb24gYXMgd2VsbCBhcyBwb3Nz aWJsZSBmYWxsYmFjayB1cG9uIGZhaWx1cmUgZ28gdGhlcmUgYXMgd2VsbC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5JbmdlbWFyIEpvaGFuc3NvbiZuYnNwOyBNLlNjLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+TWFzdGVyIFJlc2VhcmNoZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6 bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Fcmljc3NvbiBBQjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPldpcmVsZXNzIEFjY2VzcyBOZXR3b3Jrczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkxh YnJhdG9yaWVncsOkbmQgMTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj45NzEgMjgsIEx1bGXD pSwgU3dlZGVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UGhvbmUgJiM0Mzs0Ni0xMDcxIDQz MDQyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0 b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U01TL01NUyA8YSBocmVmPSJ0ZWw6JiM0Mzs0 NiUyMDczJTIwMDc4JTIwMzIlMjA4OSIgdGFyZ2V0PSJfYmxhbmsiPg0KJiM0Mzs0Ni03MyAwNzgg MzI4OTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hdXRvc3BhY2U6bm9uZSI+DQo8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5pbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmVy aWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnd3dy5lcmljc3Nvbi5j b208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt YXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNDQ0NDREQiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9z cGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE5vLCB5b3UgY2FuwrR0IHRlbGwgcGVvcGxlIGFueXRoaW5nPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWW914oCZdmUgZ290IHRvIHNob3cg4oCYZW08L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6 bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBCcnVjZSBTcHJpbmdzdGVlbjxzcGFuIHN0eWxlPSJjb2xvcjojMzMzMzMzIj48YnI+DQo8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB348C71A80C83DFF55E50DF4C2830DB4PR07MB348eurprd_-- From nobody Mon Dec 5 09:05:57 2016 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 27F4E129554 for ; Mon, 5 Dec 2016 09:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] 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 ZpFYNRiiH8Ho for ; Mon, 5 Dec 2016 09:05:54 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF11129C40 for ; Mon, 5 Dec 2016 09:02:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AF2D1D9309 for ; Mon, 5 Dec 2016 18:02:53 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bQK4XcRjtW4T for ; Mon, 5 Dec 2016 18:02:53 +0100 (MET) Received: from [192.168.178.33] (p5DEC2FCB.dip0.t-ipconnect.de [93.236.47.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7C007D9305 for ; Mon, 5 Dec 2016 18:02:53 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Review of draft-ietf-quic-transport-00 Message-Id: <938D954F-A61D-4779-90D6-CC2800CF75DE@tik.ee.ethz.ch> Date: Mon, 5 Dec 2016 18:02:52 +0100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 17:05:56 -0000 Hi all, I reviewed draft-ietf-quic-transport-00 as an individual. I have quite a = few comments but I would like to raise three high-level design questions = which I will send separate mails for next with more explanation to keep = the discussion separated. I do have more comments but I might bring them = up later or just send a PR for some of them. Excuse me if parts of these = issues have been discussed earlier; it=E2=80=99s not unlikely that = I=E2=80=99ve missed parts of previous discussions given the amount of = mail we currently have on this list.=20 The three high level points, which are more on the transporty side of = life, are (see further explanation in following mails): 1. Per-stream vs. per-connection information: They way per-stream and = per-connection information are mixed up in frames (or not) is really = confusing to me. I have some concrete examples and proposal in the next = mail, and this is a little related to my next point. 2. Encryption: The split between the crypto and the transport handshake = is confusing and, as I believe was discussed to some extend already, = it=E2=80=99s not clear which information will be encrypted and which = will be visible. 3. Do we really need to close streams? Why not just leave them open and = have them inactive, e.g. with a time-out and/or advertising a window of = zero=E2=80=A6? Especially reading section 8, I think that would simplify = things enormously. I think some of these questions are connected to the split of documents, = especially regarding the tls-doc but also the cc/recovery-doc. I only = reviewed in detail this doc, the quic-transport draft, and only skimmed = the other docs, however, to my understanding as it should be possible to = replace the crypto-negotiation as well as recovery mechanism with other = mechanisms, and as such this draft must be stand-alone to a certain = extend and therefore a few things are missing. Please see next mails! Mirja P.S.: One nit I would like to mention here: Section 4.2 (Regular Packets) page 10 says: "The first packet send by an = endpoint MUST have a packet number of 1." And section 7 (Packetization and Reliability) page 28 says: "That is, = the first packet in both directions of the connection MUST have a packet = number of 0." From nobody Mon Dec 5 09:06:18 2016 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 7934D129BD3 for ; Mon, 5 Dec 2016 09:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] 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 9rJWNBgmr7sQ for ; Mon, 5 Dec 2016 09:06:10 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2045D129B6B for ; Mon, 5 Dec 2016 09:03:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DEA38D9305 for ; Mon, 5 Dec 2016 18:03:07 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SjgJbcozLsyp for ; Mon, 5 Dec 2016 18:03:07 +0100 (MET) Received: from [192.168.178.33] (p5DEC2FCB.dip0.t-ipconnect.de [93.236.47.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9365ED9304 for ; Mon, 5 Dec 2016 18:03:07 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Stream vs. connection Message-Id: Date: Mon, 5 Dec 2016 18:03:07 +0100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 17:06:16 -0000 Hi again, here comes further information on point one regarding the questions how = to treat stream-based information vs. connection-based information. This = is currently my main point about the transport design of quic. To be = more concrete, quic has the concept of packets and frames. While one = regular packet can carry multiple frames there are also other packets = that do not carry any frames/stream-based information but are related to = the state management of the whole connection (version negotiation and = public reset in this case). I think this is all fine. My confusion comes = when I look at the different kinds of frames. While most of the frames = carry information that is clearly assigned to one stream, there are some = frames that again carry connection-wide information, namely the ACK = frame, the STOP_WAITING Frame, the CONNECTION_CLOSE frame, the GOWAY = frame and probably also the PING frame (not talking about the PADDING = frame here because its use is fully unclear to me=E2=80=A6). I think = these information should be part of an encrypted QUIC per-packet header = instead. Some more concrete comments on each frame: - ACK frame: Here the decision was made that data is ack=E2=80=99ed on a = per-packet basis (instead on per frame-basis). I believe this decision = is fine (didn=E2=80=99t actually further think about it so far). = However, as these information are clearly aligned to packets, I think = they should be part of the QUIC packet header. Here I assume that it = does not make sense to send multiple ACK frames in one packet because = they could always be combined to one (to save space). In this case it = would be sufficient to have one flag in the general QUIC packet header = that indicates if these information are present or not. - STOP_WAITING frame: At the first reading I didn=E2=80=99t really = understand what this is needed for because I didn=E2=80=99t fully = internalize that packets are not retransmitted (btw. that could be = stated more clearly in the intro!). I understand that this is inevitable = connection to how ack'ing is done and therefore I really don=E2=80=99t = understand why this is a separate frame at all. For me that could simply = be one field in the ACK frame basically always indicating the last ACK = information received.=20 One more general comment here: I=E2=80=99m also not convince that the = ACK scheme chosen (and basically aligned to the TCP ACK scheme is the = right choice here). Given that you don=E2=80=99t retransmit, wouldn't a = NACK scheme make more sense=E2=80=A6? Meaning that you indicate the = highest (un-ordered) packet number seen as well as all packet numbers = not seen since the packet number announced by the last STOP_WAITING = value. Did you consider that previously? - PING frame: Having a whole frame for this really, really seems like = overhead, while you only need on bit in the packet header and no = frames/steam payload data are send at all=E2=80=A6 Btw. the reaction to = this signal is not specified: is the receiver supposed to send a ping = back or a different packet or nothing at all? - CONNECTION_CLOSE and GO_AWAY: These two information bits are clearly = per-connection. I also don=E2=80=99t really see a need for a = CONNECTION_CLOSE and a PUBLIC_RESET. I think there can be a way to = combine these signals given we have a mechanism for integrity checking. Mirja From nobody Mon Dec 5 09:11:44 2016 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 A76BA129C0E for ; Mon, 5 Dec 2016 09:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] 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 Cw_7WO4tbV2m for ; Mon, 5 Dec 2016 09:11:40 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB15A129BFD for ; Mon, 5 Dec 2016 09:10:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D938DD9305 for ; Mon, 5 Dec 2016 18:03:22 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FopqAU86Fe0c for ; Mon, 5 Dec 2016 18:03:22 +0100 (MET) Received: from [192.168.178.33] (p5DEC2FCB.dip0.t-ipconnect.de [93.236.47.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A91D2D9304 for ; Mon, 5 Dec 2016 18:03:22 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Encryption boundary and transport handshake Message-Id: Date: Mon, 5 Dec 2016 18:03:22 +0100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 17:11:42 -0000 Hi once again, for this point I believe there is first of all some specification = missing, mainly in section 5.2.1 (transport parameters and options) = because it=E2=80=99s really not clear what to do with the specified = parameters. However (without having read the tls-draft in detail), I = think the boundary between transport and crypto is very blurry here. I = understand that the goal is to more tightly integrate them, mostly to = avoid additional RTTs, however, I still think this can be clearly = separated in the spec. I=E2=80=99m thinking here a little bit about the = approach we finally took in tcpinc where you have tcp-eno that specifies = the TCP option to negotiate crypto and potentially related information = and then you can use this to either negotiate the use of tcpcrypt or = TLS. Again, I know the goal is to not spend extra RTTs on negotiation = but I think we should really ask which information is crypto-specific = and which information is needed for all crypto schemes and can be = provided by the transport part such as the STK potentially. Also I said = this in my previous mail, the transport spec needs to have all = information and mechanism that makes it possible to replace the crypto = scheme at a later point of time. This seems not fully be the case yet. The other rated point here, which also was made previously, is that is = not clear which information is (always) sent in clear and with = information should always be encrypted. Note that there are the two = cases: having a first connection or session resumption. These cases = should also be discussed in the transport draft. Mirja= From nobody Mon Dec 5 09:11:48 2016 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 A78C8129C12 for ; Mon, 5 Dec 2016 09:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] 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 oBnbuTMAHDoU for ; Mon, 5 Dec 2016 09:11:40 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B83D129BFF for ; Mon, 5 Dec 2016 09:10:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DB1FDD9309 for ; Mon, 5 Dec 2016 18:03:31 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xJxuN1NGRymK for ; Mon, 5 Dec 2016 18:03:31 +0100 (MET) Received: from [192.168.178.33] (p5DEC2FCB.dip0.t-ipconnect.de [93.236.47.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 91D58D9304 for ; Mon, 5 Dec 2016 18:03:31 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Closing streams Message-Id: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> Date: Mon, 5 Dec 2016 18:03:31 +0100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 17:11:44 -0000 And finally (one more hi!), while reading the draft, saying that the stream handling is really = light-way, I was asking myself if we really need to close streams at all = (given that we also just implicitly open them). When you look at section = 8.1 (Life of a stream) the overhead of closing streams is actually quite = large (couple of additional states only needed for this). (Btw. I also = don=E2=80=99t really understand what the difference between a reserved = and idle stream is=E2=80=A6 i guess that=E2=80=99s rather an interface = question than state management, anyway=E2=80=A6). To my understanding, = you close connection for state management at the receiver side. However, = as you announce the maximum number of streams to the other endpoint and = you can use the WINDOW_UPDATE to send a zero window to make sure no = additional data are send (and use BLOCK to reset-up state on the = receiver if needed), I think it is a local decision at the receiver = which streams to remove state for if the max number of streams is = reached. I don=E2=80=99t really see the additional benefit the FIN bits = are giving. Or has this proven to be really helpful in some real-life = situation? Mirja= From nobody Mon Dec 5 10:52:57 2016 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 052C6129C86 for ; Mon, 5 Dec 2016 10:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 vKsUxc03GKtH for ; Mon, 5 Dec 2016 10:52:54 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0091.outbound.protection.outlook.com [104.47.37.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B772129C85 for ; Mon, 5 Dec 2016 10:52:53 -0800 (PST) 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; bh=4v5GcQ030gMJl8BQuir5j52JssvpthmwdByya0Iw0dI=; b=VSUwQir1XoJ5VVI7/2xH0W/jd2N/MnowK+v9DgxlZY+lIQOKx/AyJAKQOAqmHaKHIaoWOydcuBnl5kqFxHvWU6UcGqYZhNWzcNA/5+hMNHHEnmRSI2Cgw6FIiFrh3r/pJB54ZLX7pHZXZdOh+1TxCQXX2rzjItjdfWBH6HCHrPo= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 5 Dec 2016 18:52:52 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.020; Mon, 5 Dec 2016 18:52:52 +0000 From: Mike Bishop To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "quic@ietf.org" Subject: RE: Closing streams Thread-Topic: Closing streams Thread-Index: AQHSTxrILgKjlazdGkOpQOy52b3ruqD5ssyQ Date: Mon, 5 Dec 2016 18:52:52 +0000 Message-ID: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> In-Reply-To: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:9::390] x-ms-office365-filtering-correlation-id: 927464e5-fdd2-4995-39cf-08d41d3feab2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:CaSNRjTgFn4pBfCQZD8x0ZukbvG0WIEGcTOb0D6dM5ywYVo5eWfMiCbKRmRamEhncJ3hFkZOTDvUAzZz9ffrdAiSlXZHVGJOhmH3+VHsAu1KNxiJoh3zF/fFayJL1amu5MWTIIVLr/VillBxw3GcLzwsgJ5bGls8Z5TFHLiSDYGP8BSIpyIHlZpZ/9ydjrxSe1lD2H+Y64cZgq/SJRoQbLRsbHIw/mmKRcbGXCnLqd0De8R0rT3DayfMSd8tbOHpPK7Y+V43uShXDWxYwBVwpBYXJoreo6fefnaf/7E8BHG8qDJtPSz3t+gfdV9vVvsBWLC/rqod6e8Ptb/ICQLUp+DmPqtOBZkNMMDGW7loS2bN3NCKAfsQcBaJ2OLAVe1/BhqffM5podnqk3ECauH2NYQtOMDG5YCsw6RAqO3E1vjOIqg91iiUOaRGbNe3yuQK5pGfTNXO2G1R0wvVP+OPjMxHOj7QaKiOJEMkye5YkO0= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(6047074)(6042181)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(377454003)(199003)(3660700001)(106116001)(33656002)(101416001)(68736007)(50986999)(81156014)(105586002)(106356001)(7696004)(76176999)(99286002)(8936002)(9686002)(76576001)(2950100002)(3480700004)(7846002)(7736002)(74316002)(7116003)(81166006)(2906002)(54356999)(8676002)(122556002)(5660300001)(3280700002)(189998001)(6116002)(102836003)(229853002)(38730400001)(305945005)(86612001)(2900100001)(8990500004)(107886002)(97736004)(5001770100001)(86362001)(92566002)(10290500002)(5005710100001)(221733001)(10090500001)(77096006)(2501003)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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-originalarrivaltime: 05 Dec 2016 18:52:52.2965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 18:52:56 -0000 IlJlc2VydmVkIiBpcyBhIGNvbmNlcHQgZHJhd24gZnJvbSBIVFRQLzIgdGhhdCBoYXMgdHJpY2ts ZWQgaW50byBRVUlDLiAgV2hldGhlciBpdCBuZWVkcyB0byBleGlzdCBhdCB0aGUgdHJhbnNwb3J0 IGxheWVyIGlzIGEgcmVhc29uYWJsZSBxdWVzdGlvbi4gIEluIGdlbmVyYWwgdGVybXMsICJyZXNl cnZlZCIgbWVhbnMgdGhhdCB5b3Uga25vdyB3aGF0IHRoZSBwZWVyIGlzIGdvaW5nIHRvIHNlbmQg eW91IG9uIHRoYXQgc3RyZWFtIChmcm9tIHRoZSBhcHBsaWNhdGlvbiBsYXllciksIGJ1dCB0aGV5 IGhhdmVuJ3QgYWN0dWFsbHkgZG9uZSBzbyB5ZXQuICBOb3cgdGhhdCB5b3UgcmFpc2UgdGhlIHF1 ZXN0aW9uLCBJIGRvbid0IHNlZSBhIHJlYXNvbiB0aGF0IGNvdWxkbid0IGJlIGFuIGFwcGxpY2F0 aW9uLWxheWVyIGNvbmNlcHQgYW5kIGxldCB0aGUgdHJhbnNwb3J0IGNvbnRpbnVlIHRvIHNlZSB0 aG9zZSBzdHJlYW1zIGFzICJpZGxlIiAtLSBkb2VzIGFueW9uZSBlbHNlPw0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIE1pcmphIEvDvGhsZXdpbmQNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg NSwgMjAxNiA5OjA0IEFNDQpUbzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogQ2xvc2luZyBzdHJl YW1zDQoNCkFuZCBmaW5hbGx5IChvbmUgbW9yZSBoaSEpLA0KDQp3aGlsZSByZWFkaW5nIHRoZSBk cmFmdCwgc2F5aW5nIHRoYXQgdGhlIHN0cmVhbSBoYW5kbGluZyBpcyByZWFsbHkgbGlnaHQtd2F5 LCBJIHdhcyBhc2tpbmcgbXlzZWxmIGlmIHdlIHJlYWxseSBuZWVkIHRvIGNsb3NlIHN0cmVhbXMg YXQgYWxsIChnaXZlbiB0aGF0IHdlIGFsc28ganVzdCBpbXBsaWNpdGx5IG9wZW4gdGhlbSkuIFdo ZW4geW91IGxvb2sgYXQgc2VjdGlvbiA4LjEgKExpZmUgb2YgYSBzdHJlYW0pIHRoZSBvdmVyaGVh ZCBvZiBjbG9zaW5nIHN0cmVhbXMgaXMgYWN0dWFsbHkgcXVpdGUgbGFyZ2UgKGNvdXBsZSBvZiBh ZGRpdGlvbmFsIHN0YXRlcyBvbmx5IG5lZWRlZCBmb3IgdGhpcykuIChCdHcuIEkgYWxzbyBkb27i gJl0IHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHJlc2Vy dmVkIGFuZCBpZGxlIHN0cmVhbSBpc+KApiBpIGd1ZXNzIHRoYXTigJlzIHJhdGhlciBhbiBpbnRl cmZhY2UgcXVlc3Rpb24gdGhhbiBzdGF0ZSBtYW5hZ2VtZW50LCBhbnl3YXnigKYpLiBUbyBteSB1 bmRlcnN0YW5kaW5nLCB5b3UgY2xvc2UgY29ubmVjdGlvbiBmb3Igc3RhdGUgbWFuYWdlbWVudCBh dCB0aGUgcmVjZWl2ZXIgc2lkZS4gSG93ZXZlciwgYXMgeW91IGFubm91bmNlIHRoZSBtYXhpbXVt IG51bWJlciBvZiBzdHJlYW1zIHRvIHRoZSBvdGhlciBlbmRwb2ludCBhbmQgeW91IGNhbiB1c2Ug dGhlIFdJTkRPV19VUERBVEUgdG8gc2VuZCBhIHplcm8gd2luZG93IHRvIG1ha2Ugc3VyZSBubyBh ZGRpdGlvbmFsIGRhdGEgYXJlIHNlbmQgKGFuZCB1c2UgQkxPQ0sgdG8gcmVzZXQtdXAgc3RhdGUg b24gdGhlIHJlY2VpdmVyIGlmIG5lZWRlZCksIEkgdGhpbmsgaXQgaXMgYSBsb2NhbCBkZWNpc2lv biBhdCB0aGUgcmVjZWl2ZXIgd2hpY2ggc3RyZWFtcyB0byByZW1vdmUgc3RhdGUgZm9yIGlmIHRo ZSBtYXggbnVtYmVyIG9mIHN0cmVhbXMgaXMgcmVhY2hlZC4gSSBkb27igJl0IHJlYWxseSBzZWUg dGhlIGFkZGl0aW9uYWwgYmVuZWZpdCB0aGUgRklOIGJpdHMgYXJlIGdpdmluZy4gT3IgaGFzIHRo aXMgcHJvdmVuIHRvIGJlIHJlYWxseSBoZWxwZnVsIGluIHNvbWUgcmVhbC1saWZlIHNpdHVhdGlv bj8NCg0KTWlyamENCg== From nobody Mon Dec 5 10:57:30 2016 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 46D0812958F for ; Mon, 5 Dec 2016 10:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 PBx_9dnjzp7e for ; Mon, 5 Dec 2016 10:57:26 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0119.outbound.protection.outlook.com [104.47.40.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C5B129C5B for ; Mon, 5 Dec 2016 10:57:26 -0800 (PST) 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; bh=ypbpTgFfgB6wGYV+piR4+rI885E/8LzldtLQbPwZcKI=; b=QZ5ReHTt71wavjoRYjz6wi6vHVP0URTg7XelHfem+C7sawKq6EVR6Bu0peiEnroVDe0gcP1HDwitA1B3o2Hj7HQ2oqG5jd7JdSsYcLHo0f+lhFcVyl0fBuES8oGZZc8AZRXwWMxo0QMbJxCZAfmHBxrsySMqsbISMfvSUnaly9A= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 5 Dec 2016 18:57:24 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.020; Mon, 5 Dec 2016 18:57:24 +0000 From: Mike Bishop To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "quic@ietf.org" Subject: RE: Review of draft-ietf-quic-transport-00 Thread-Topic: Review of draft-ietf-quic-transport-00 Thread-Index: AQHSTxnbhl9/imI8xU2Xm+4NAoLXtaD5s/Iw Date: Mon, 5 Dec 2016 18:57:24 +0000 Message-ID: References: <938D954F-A61D-4779-90D6-CC2800CF75DE@tik.ee.ethz.ch> In-Reply-To: <938D954F-A61D-4779-90D6-CC2800CF75DE@tik.ee.ethz.ch> 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:9::390] x-ms-office365-filtering-correlation-id: b13f3197-155a-49af-6f59-08d41d408d1f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:WLkQUybWWUFFEQ/DvkOGZz9mX8+Czfm1zP5N3wXY86e16MGfhPcMrcHMYDBcvHDGiPRdEm7cfB4H5iGKWmpYnVPB4DlZJ++CJYOKkgcwiXV+7BM1kcgq4T/tnje7DamzWln9K+ywSEyGvf3tXnEZ6A0xDaDe7WR6Me467YiLBflk6gUmG8pKPaEqkPN2V/nyEcadSHWJu6j7SRHQk+3am/U+ZsVVhnXnr1eeq5VsWBHgrvIfMT7OpyOmFRrHUzHlNIIiA13WVlTyHyTA0WbfY/uynBFCFeXUGjemtzuNqN75irxUHRH8S2mgZNFWOsTYA2VNjnVRg1vkAg0oaXKljX7kXVTGLAMSjvMP//4KUFJt4sb+VKxq0w4F14UvUwfGi1f8iPn2LcHH9D3ptuVp7UOflMFDcH5tFs1rRUX/dTuNDlpWvs05XJ7tl4sjD5bxvbk6XDYG85Ela1tots2/fl2p8V9vYyGMd4pME0FIVD8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(53754006)(13464003)(377454003)(189002)(51444003)(7736002)(7696004)(6506006)(5005710100001)(10290500002)(10090500001)(2906002)(86612001)(8990500004)(561944003)(105586002)(33656002)(106356001)(106116001)(99286002)(230783001)(76176999)(81156014)(8676002)(101416001)(81166006)(50986999)(54356999)(3280700002)(39850400001)(9686002)(5660300001)(189998001)(8936002)(107886002)(122556002)(92566002)(3660700001)(76576001)(2900100001)(68736007)(2501003)(5001770100001)(97736004)(6116002)(102836003)(86362001)(7846002)(305945005)(74316002)(229853002)(39840400001)(39410400001)(2950100002)(38730400001)(39450400002)(77096006)(39860400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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-originalarrivaltime: 05 Dec 2016 18:57:24.6420 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 18:57:28 -0000 SGF2aW5nIGFuIGluZmluaXRlIG51bWJlciBvZiBzdHJlYW1zIG9wZW4gYW5kIGlkbGUgc2VlbXMg bGlrZSBhIGdvb2Qgd2F5IHRvIHdhc3RlIGFwcGxpY2F0aW9uIHJlc291cmNlcyB0cmFja2luZyBz dGF0ZS4gIFNwZWFraW5nIGZyb20gYW4gYXBwbGljYXRpb24gcGVyc3BlY3RpdmUsIEknbSByZWFk aW5nIGZyb20gYSBzdHJlYW0gYW5kIHdvdWxkIGxpa2UgYSB3YXkgdG8ga25vdyB3aGVuIEkndmUg cmVhY2hlZCB0aGUgZW5kIChyYXRoZXIgdGhhbiBqdXN0IGhhdmluZyBub3QgcmVjZWl2ZWQgaXQg eWV0KS4gIE9mIGNvdXJzZSwgSSBjb3VsZCBkZWZpbmUgdGhhdCBteXNlbGYgd2l0aCBhbiBFT0Yt aW5kaWNhdG9yIG9uIHRoZSBzdHJlYW0gZGF0YSBpZiB0aGVyZSdzIGEgZ29vZCByZWFzb24gZm9y IHRoZSB0cmFuc3BvcnQgKm5vdCogdG8gcHJvdmlkZSB0aGF0IGZ1bmN0aW9uYWxpdHkuICBPdGhl ciB0aGFuIHNpbXBsaWZ5aW5nIHRoZSBzdHJlYW0gc3RhdGUgbWFjaGluZSwgd2h5IHdvdWxkbid0 IHlvdSBzdXBwb3J0IGl0Pw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphIEvDvGhs ZXdpbmQNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiA5OjAzIEFNDQpUbzogcXVpY0Bp ZXRmLm9yZw0KU3ViamVjdDogUmV2aWV3IG9mIGRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMDAN Cg0KSGkgYWxsLA0KDQpJIHJldmlld2VkIGRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMDAgYXMg YW4gaW5kaXZpZHVhbC4gSSBoYXZlIHF1aXRlIGEgZmV3IGNvbW1lbnRzIGJ1dCBJIHdvdWxkIGxp a2UgdG8gcmFpc2UgdGhyZWUgaGlnaC1sZXZlbCBkZXNpZ24gcXVlc3Rpb25zIHdoaWNoIEkgd2ls bCBzZW5kIHNlcGFyYXRlIG1haWxzIGZvciBuZXh0IHdpdGggbW9yZSBleHBsYW5hdGlvbiB0byBr ZWVwIHRoZSBkaXNjdXNzaW9uIHNlcGFyYXRlZC4gSSBkbyBoYXZlIG1vcmUgY29tbWVudHMgYnV0 IEkgbWlnaHQgYnJpbmcgdGhlbSB1cCBsYXRlciBvciBqdXN0IHNlbmQgYSBQUiBmb3Igc29tZSBv ZiB0aGVtLiBFeGN1c2UgbWUgaWYgcGFydHMgb2YgdGhlc2UgaXNzdWVzIGhhdmUgYmVlbiBkaXNj dXNzZWQgZWFybGllcjsgaXTigJlzIG5vdCB1bmxpa2VseSB0aGF0IEnigJl2ZSBtaXNzZWQgcGFy dHMgb2YgcHJldmlvdXMgZGlzY3Vzc2lvbnMgZ2l2ZW4gdGhlIGFtb3VudCBvZiBtYWlsIHdlIGN1 cnJlbnRseSBoYXZlIG9uIHRoaXMgbGlzdC4gDQoNClRoZSB0aHJlZSBoaWdoIGxldmVsIHBvaW50 cywgd2hpY2ggYXJlIG1vcmUgb24gdGhlIHRyYW5zcG9ydHkgc2lkZSBvZiBsaWZlLCBhcmUgKHNl ZSBmdXJ0aGVyIGV4cGxhbmF0aW9uIGluIGZvbGxvd2luZyBtYWlscyk6DQoNCjEuIFBlci1zdHJl YW0gdnMuIHBlci1jb25uZWN0aW9uIGluZm9ybWF0aW9uOiBUaGV5IHdheSBwZXItc3RyZWFtIGFu ZCBwZXItY29ubmVjdGlvbiBpbmZvcm1hdGlvbiBhcmUgbWl4ZWQgdXAgaW4gZnJhbWVzIChvciBu b3QpIGlzIHJlYWxseSBjb25mdXNpbmcgdG8gbWUuIEkgaGF2ZSBzb21lIGNvbmNyZXRlIGV4YW1w bGVzIGFuZCBwcm9wb3NhbCBpbiB0aGUgbmV4dCBtYWlsLCBhbmQgdGhpcyBpcyBhIGxpdHRsZSBy ZWxhdGVkIHRvIG15IG5leHQgcG9pbnQuDQoNCjIuIEVuY3J5cHRpb246IFRoZSBzcGxpdCBiZXR3 ZWVuIHRoZSBjcnlwdG8gYW5kIHRoZSB0cmFuc3BvcnQgaGFuZHNoYWtlIGlzIGNvbmZ1c2luZyBh bmQsIGFzIEkgYmVsaWV2ZSB3YXMgZGlzY3Vzc2VkIHRvIHNvbWUgZXh0ZW5kIGFscmVhZHksIGl0 4oCZcyBub3QgY2xlYXIgd2hpY2ggaW5mb3JtYXRpb24gd2lsbCBiZSBlbmNyeXB0ZWQgYW5kIHdo aWNoIHdpbGwgYmUgdmlzaWJsZS4NCg0KMy4gRG8gd2UgcmVhbGx5IG5lZWQgdG8gY2xvc2Ugc3Ry ZWFtcz8gV2h5IG5vdCBqdXN0IGxlYXZlIHRoZW0gb3BlbiBhbmQgaGF2ZSB0aGVtIGluYWN0aXZl LCBlLmcuIHdpdGggYSB0aW1lLW91dCBhbmQvb3IgYWR2ZXJ0aXNpbmcgYSB3aW5kb3cgb2YgemVy b+KApj8gRXNwZWNpYWxseSByZWFkaW5nIHNlY3Rpb24gOCwgSSB0aGluayB0aGF0IHdvdWxkIHNp bXBsaWZ5IHRoaW5ncyBlbm9ybW91c2x5Lg0KDQpJIHRoaW5rIHNvbWUgb2YgdGhlc2UgcXVlc3Rp b25zIGFyZSBjb25uZWN0ZWQgdG8gdGhlIHNwbGl0IG9mIGRvY3VtZW50cywgZXNwZWNpYWxseSBy ZWdhcmRpbmcgdGhlIHRscy1kb2MgYnV0IGFsc28gdGhlIGNjL3JlY292ZXJ5LWRvYy4gSSBvbmx5 IHJldmlld2VkIGluIGRldGFpbCB0aGlzIGRvYywgdGhlIHF1aWMtdHJhbnNwb3J0IGRyYWZ0LCBh bmQgb25seSBza2ltbWVkIHRoZSBvdGhlciBkb2NzLCBob3dldmVyLCB0byBteSB1bmRlcnN0YW5k aW5nIGFzIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byByZXBsYWNlIHRoZSBjcnlwdG8tbmVnb3Rp YXRpb24gYXMgd2VsbCBhcyByZWNvdmVyeSBtZWNoYW5pc20gd2l0aCBvdGhlciBtZWNoYW5pc21z LCAgYW5kIGFzIHN1Y2ggdGhpcyBkcmFmdCBtdXN0IGJlIHN0YW5kLWFsb25lIHRvIGEgY2VydGFp biBleHRlbmQgYW5kIHRoZXJlZm9yZSBhIGZldyB0aGluZ3MgYXJlIG1pc3NpbmcuDQoNClBsZWFz ZSBzZWUgbmV4dCBtYWlscyENCk1pcmphDQoNCg0KUC5TLjogT25lIG5pdCBJIHdvdWxkIGxpa2Ug dG8gbWVudGlvbiBoZXJlOg0KU2VjdGlvbiA0LjIgKFJlZ3VsYXIgUGFja2V0cykgcGFnZSAxMCBz YXlzOiAiVGhlIGZpcnN0IHBhY2tldCBzZW5kIGJ5IGFuIGVuZHBvaW50IE1VU1QgaGF2ZSBhIHBh Y2tldCBudW1iZXIgb2YgMS4iDQpBbmQgc2VjdGlvbiA3IChQYWNrZXRpemF0aW9uIGFuZCBSZWxp YWJpbGl0eSkgcGFnZSAyOCBzYXlzOiAiVGhhdCBpcywgdGhlIGZpcnN0IHBhY2tldCBpbiBib3Ro IGRpcmVjdGlvbnMgb2YgdGhlIGNvbm5lY3Rpb24gTVVTVCBoYXZlIGEgcGFja2V0IG51bWJlciBv ZiAwLiINCg0KDQo= From nobody Mon Dec 5 11:01:34 2016 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 B3972129C9C for ; Mon, 5 Dec 2016 11:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 aWHzd_ZXgYRB for ; Mon, 5 Dec 2016 11:01:32 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 EB85B129C9A for ; Mon, 5 Dec 2016 11:01:31 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id r204so259196464ywb.0 for ; Mon, 05 Dec 2016 11:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EpRyOiQr0Zh2Ei5GBdDsqzj4A6bgQ4rMpW+ydTwTnLE=; b=QAkptwKyjBNaVN1fk9KWNiEeqjoqd3hIsTUxEUmVYeuwIs5Jj1EoAqznOfhITnDok1 qfKVEKShJ83YkC6VKfhkgYoEJVlZJ0+R3xVZcPYJWD17T7X4fQh27u7k5Rv9Y8S4uL9B S+/o+xP4p6cIAo983P82UDkQnpje7exZj9rN8GqaOV6ZcSdnXs/WQdG/hWKp8UDt7+jk +Hs/jbEXtCsuRVsJGVOwf50E+BapkmDZAAvFMIENDBkZ4dAkKc2+xvX4crMAAfHwUsP4 QrTtWHV3imHvkuQPPkWbVfPY/Gwg+RdHf/q7IYjLUV/3jz6xB3aWGxpX72UMuaduKa+O v+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EpRyOiQr0Zh2Ei5GBdDsqzj4A6bgQ4rMpW+ydTwTnLE=; b=lPZk5jnMwHAEq9llIu9z6bZGt3fdfC4JNNsYUoIUAYHx/TNQWKwfqkdybT5YJBEmwo WOEccvkRIVuprDyEJMcpyslD+8ijMNqZoLPt7qa0grMgjSGE2ksaQiKTaAm2WOwcyV8s U+Hh/3J93z7q1EictVmcZgRIWYwt0SslQ1eKHxcutZXZ8bWYIP+9xwq+esdv1lfnRgpY RD/Bca6s20cgvlQtokn4EQS39CivizVGMIoVVmK2E+Rke60Jma2IuYdBoPTqWmbCFTrp VaY3z9KYtfJd5OL1WWSiZJAteo7Y2gIjebKB46vIoxVVKLnnocF9qmlmktHLdK3rgS6h 0vWA== X-Gm-Message-State: AKaTC03ujVZpn/OxoHSqhZWw6Zdsa/pSV8Gn3jXsKizMRZpZ6Wuax2XTFTavE5ceRYRdHPZQFYrtPvU/u0Qivb9A X-Received: by 10.129.117.215 with SMTP id q206mr60790913ywc.143.1480964491028; Mon, 05 Dec 2016 11:01:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Mon, 5 Dec 2016 11:01:10 -0800 (PST) In-Reply-To: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> From: Ian Swett Date: Mon, 5 Dec 2016 14:01:10 -0500 Message-ID: Subject: Re: Closing streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1147f9ce6a12d20542edeaeb Archived-At: Cc: "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 19:01:33 -0000 --001a1147f9ce6a12d20542edeaeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A key to making streams lightweight is to ensure they're used in order. Otherwise tracking which streams have been previously used and closed can consume a large amount of memory. So I believe the streams have to be reserved or have another way to ensure they're used in order(at least approximately). Of course, it'd be easy enough to immediately reset the stream to indicate you're just skipping it. On Mon, Dec 5, 2016 at 1:52 PM, Mike Bishop wrote: > "Reserved" is a concept drawn from HTTP/2 that has trickled into QUIC. > Whether it needs to exist at the transport layer is a reasonable question= . > In general terms, "reserved" means that you know what the peer is going t= o > send you on that stream (from the application layer), but they haven't > actually done so yet. Now that you raise the question, I don't see a > reason that couldn't be an application-layer concept and let the transpor= t > continue to see those streams as "idle" -- does anyone else? > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewi= nd > Sent: Monday, December 5, 2016 9:04 AM > To: quic@ietf.org > Subject: Closing streams > > And finally (one more hi!), > > while reading the draft, saying that the stream handling is really > light-way, I was asking myself if we really need to close streams at all > (given that we also just implicitly open them). When you look at section > 8.1 (Life of a stream) the overhead of closing streams is actually quite > large (couple of additional states only needed for this). (Btw. I also > don=E2=80=99t really understand what the difference between a reserved an= d idle > stream is=E2=80=A6 i guess that=E2=80=99s rather an interface question th= an state > management, anyway=E2=80=A6). To my understanding, you close connection f= or state > management at the receiver side. However, as you announce the maximum > number of streams to the other endpoint and you can use the WINDOW_UPDATE > to send a zero window to make sure no additional data are send (and use > BLOCK to reset-up state on the receiver if needed), I think it is a local > decision at the receiver which streams to remove state for if the max > number of streams is reached. I don=E2=80=99t really see the additional b= enefit the > FIN bits are giving. Or has this proven to be really helpful in some > real-life situation? > > Mirja > --001a1147f9ce6a12d20542edeaeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A key to making streams lightweight is to ensure they'= re used in order.=C2=A0 Otherwise tracking which streams have been previous= ly used and closed can consume a large amount of memory.=C2=A0 So I believe= the streams have to be reserved or have another way to ensure they're = used in order(at least approximately).=C2=A0 Of course, it'd be easy en= ough to immediately reset the stream to indicate you're just skipping i= t. =C2=A0

On= Mon, Dec 5, 2016 at 1:52 PM, Mike Bishop <Michael.Bishop@micro= soft.com> wrote:
"Re= served" is a concept drawn from HTTP/2 that has trickled into QUIC.=C2= =A0 Whether it needs to exist at the transport layer is a reasonable questi= on.=C2=A0 In general terms, "reserved" means that you know what t= he peer is going to send you on that stream (from the application layer), b= ut they haven't actually done so yet.=C2=A0 Now that you raise the ques= tion, I don't see a reason that couldn't be an application-layer co= ncept and let the transport continue to see those streams as "idle&quo= t; -- does anyone else?

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mirja K=C3=BChlewind
Sent: Monday, December 5, 2016 9:04 AM
To: quic@ietf.org
Subject: Closing streams

And finally (one more hi!),

while reading the draft, saying that the stream handling is really light-wa= y, I was asking myself if we really need to close streams at all (given tha= t we also just implicitly open them). When you look at section 8.1 (Life of= a stream) the overhead of closing streams is actually quite large (couple = of additional states only needed for this). (Btw. I also don=E2=80=99t real= ly understand what the difference between a reserved and idle stream is=E2= =80=A6 i guess that=E2=80=99s rather an interface question than state manag= ement, anyway=E2=80=A6). To my understanding, you close connection for stat= e management at the receiver side. However, as you announce the maximum num= ber of streams to the other endpoint and you can use the WINDOW_UPDATE to s= end a zero window to make sure no additional data are send (and use BLOCK t= o reset-up state on the receiver if needed), I think it is a local decision= at the receiver which streams to remove state for if the max number of str= eams is reached. I don=E2=80=99t really see the additional benefit the FIN = bits are giving. Or has this proven to be really helpful in some real-life = situation?

Mirja

--001a1147f9ce6a12d20542edeaeb-- From nobody Mon Dec 5 11:13:18 2016 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 EE8F9129CAF for ; Mon, 5 Dec 2016 11:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 mPLNg9accWj3 for ; Mon, 5 Dec 2016 11:13:15 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0115.outbound.protection.outlook.com [104.47.41.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E0C129CA3 for ; Mon, 5 Dec 2016 11:13:15 -0800 (PST) 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; bh=nSX77CAXzcXkd6xytgf2Mn9Pywpbi26DSPDqNhp2xIE=; b=CycOCnkx6MYlrpiay0228L3OaFu94Y4X3zoJbzCATddTSnAqG3OdfBxH5kWoZjLbgD7vY5ECc/xZlNe8oVKf/n+cQadbc+Kx4zBhN2WCPWNuD6lNXm2nA9qFQFy1FSVzt2R/FOqpmEP2DgT7Fe7+KpBL8O0z9HVxMtxQNu5XFa8= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 5 Dec 2016 19:13:13 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.020; Mon, 5 Dec 2016 19:13:13 +0000 From: Mike Bishop To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "quic@ietf.org" Subject: RE: Stream vs. connection Thread-Topic: Stream vs. connection Thread-Index: AQHSTxnrJofcTRdZDE2sksJ4g94J/KD5tLlA Date: Mon, 5 Dec 2016 19:13:13 +0000 Message-ID: References: In-Reply-To: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:9::390] x-ms-office365-filtering-correlation-id: 8e1c1944-42f0-4d70-b8fe-08d41d42c29f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:7FmLnsBvvVXra38jWfrd6tefabBcDamHD2P0WThDlv5cj9dWkph4NN238qu4klNVyuGg9A0+KFj4NYR2dHUjhG9ofvS37rR20Hj5Il+NogOYr0ukRpnpR22XExANlZz6lvHEtoTeiOF1w9AKy2IPnSCufBPte8p0i8tJt59POuG/XLAUUadE6uPuodotnd8Ju7Ci7IHNXEejuAG3FRlDsBvM0FRSL44+mdc30b6zeJHNERsbt3wIE56U3bvEwEJo1yr4kuCNEjKRT8WgjzwURMWuffRkTgc5WZcr5QgvNhs8qdYOcnLs7WoDsKao14EO+CArrPgCk0YtiVHGkNwigb923FZJlXgmBrQVciIa4b+HAawzvyua5uFXREmvUkKGGE4nsqCVUTqZ6hQsQMaP3bLyzzjOeR+GU5b7dPIfHDLUqv4qYmBEfCtuccpWLI8BtPnytW9p/14K3/QV3hE0hTkh9RgdbwrFYtdwq4ZTGEk= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(6047074)(6042181)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(377454003)(199003)(3660700001)(106116001)(33656002)(101416001)(68736007)(50986999)(81156014)(105586002)(106356001)(7696004)(76176999)(99286002)(8936002)(9686002)(76576001)(2950100002)(4326007)(7846002)(7736002)(74316002)(81166006)(2906002)(54356999)(8676002)(122556002)(5660300001)(3280700002)(189998001)(6116002)(102836003)(229853002)(38730400001)(305945005)(86612001)(2900100001)(8990500004)(97736004)(5001770100001)(86362001)(92566002)(10290500002)(5005710100001)(10090500001)(77096006)(2501003)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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-originalarrivaltime: 05 Dec 2016 19:13:13.5536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Ian Swett X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 19:13:18 -0000 SSBvcGVuZWQgaXNzdWUgIzcwIGZvciB0aGUgc3VnZ2VzdGlvbiB0byBtb3ZlIEFDSyBpbnRvIGEg Zml4ZWQgcGVyLXBhY2tldCBsb2NhdGlvbi4gIElhbiBoYXMgYWxyZWFkeSByZXBsaWVkIHRoZXJl IG5vdGluZyB0aGF0IHRoZXJlIGlzbid0IGFuIChlbmNyeXB0ZWQpIHBhY2tldCBoZWFkZXIsIHNv IHdlJ2QgbmVlZCB0byBjcmVhdGUgb25lIHRvIGhvbGQgdGhlIEFDSyBkYXRhIGFuZCBhbnl0aGlu ZyBlbHNlIHdlIHdhbnRlZCB0byBjb25zb2xpZGF0ZSB0aGVyZS4gIFNUT1BfV0FJVElORyBpcyBh bHJlYWR5IG9uIHRoZSBjaG9wcGluZyBibG9jayBpbiBhbm90aGVyIGlzc3VlICgjNjYpLg0KDQpU aGUgUElORyBmcmFtZSBoYW5kbGluZyBhY3R1YWxseSBpcyBzcGVjaWZpZWQ6ICAiVGhlIHJlY2Vp dmVyIG9mIGEgUElORyBmcmFtZSBzaW1wbHkgbmVlZHMgdG8gQUNLIHRoZSBwYWNrZXQgY29udGFp bmluZyB0aGlzIGZyYW1lLiIgIEkgY2FuIHNlZSB3aGVyZSBpdCBzZWVtcyBsaWtlIGl0IHNlcnZl cyBsaXR0bGUgcHVycG9zZSAtLSB0aGVyZSdzIGJhc2ljYWxseSBubyBkaWZmZXJlbmNlIGJldHdl ZW4gUElORyBhbmQgUEFERElORywgZXhjZXB0IHRoYXQgUElORyBpcyByZXRyYW5zbWl0dGFibGUg YW5kIFBBRERJTkcgaXMgbm90Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphIEvD vGhsZXdpbmQNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiA5OjAzIEFNDQpUbzogcXVp Y0BpZXRmLm9yZw0KU3ViamVjdDogU3RyZWFtIHZzLiBjb25uZWN0aW9uDQoNCkhpIGFnYWluLA0K DQpoZXJlIGNvbWVzIGZ1cnRoZXIgaW5mb3JtYXRpb24gb24gcG9pbnQgb25lIHJlZ2FyZGluZyB0 aGUgcXVlc3Rpb25zIGhvdyB0byB0cmVhdCBzdHJlYW0tYmFzZWQgaW5mb3JtYXRpb24gdnMuIGNv bm5lY3Rpb24tYmFzZWQgaW5mb3JtYXRpb24uIFRoaXMgaXMgY3VycmVudGx5IG15IG1haW4gcG9p bnQgYWJvdXQgdGhlIHRyYW5zcG9ydCBkZXNpZ24gb2YgcXVpYy4gVG8gYmUgbW9yZSBjb25jcmV0 ZSwgcXVpYyBoYXMgdGhlIGNvbmNlcHQgb2YgcGFja2V0cyBhbmQgZnJhbWVzLiBXaGlsZSBvbmUg cmVndWxhciBwYWNrZXQgY2FuIGNhcnJ5IG11bHRpcGxlIGZyYW1lcyB0aGVyZSBhcmUgYWxzbyBv dGhlciBwYWNrZXRzIHRoYXQgZG8gbm90IGNhcnJ5IGFueSBmcmFtZXMvc3RyZWFtLWJhc2VkIGlu Zm9ybWF0aW9uIGJ1dCBhcmUgcmVsYXRlZCB0byB0aGUgc3RhdGUgbWFuYWdlbWVudCBvZiB0aGUg d2hvbGUgY29ubmVjdGlvbiAodmVyc2lvbiBuZWdvdGlhdGlvbiBhbmQgcHVibGljIHJlc2V0IGlu IHRoaXMgY2FzZSkuIEkgdGhpbmsgdGhpcyBpcyBhbGwgZmluZS4gTXkgY29uZnVzaW9uIGNvbWVz IHdoZW4gSSBsb29rIGF0IHRoZSBkaWZmZXJlbnQga2luZHMgb2YgZnJhbWVzLiBXaGlsZSBtb3N0 IG9mIHRoZSBmcmFtZXMgY2FycnkgaW5mb3JtYXRpb24gdGhhdCBpcyBjbGVhcmx5IGFzc2lnbmVk IHRvIG9uZSBzdHJlYW0sIHRoZXJlIGFyZSBzb21lIGZyYW1lcyB0aGF0IGFnYWluIGNhcnJ5IGNv bm5lY3Rpb24td2lkZSBpbmZvcm1hdGlvbiwgbmFtZWx5IHRoZSBBQ0sgZnJhbWUsIHRoZSBTVE9Q X1dBSVRJTkcgRnJhbWUsIHRoZSBDT05ORUNUSU9OX0NMT1NFIGZyYW1lLCB0aGUgR09XQVkgZnJh bWUgYW5kIHByb2JhYmx5IGFsc28gdGhlIFBJTkcgZnJhbWUgKG5vdCB0YWxraW5nIGFib3V0IHRo ZSBQQURESU5HIGZyYW1lIGhlcmUgYmVjYXVzZSBpdHMgdXNlIGlzIGZ1bGx5IHVuY2xlYXIgdG8g bWXigKYpLiBJIHRoaW5rIHRoZXNlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBwYXJ0IG9mIGFuIGVu Y3J5cHRlZCBRVUlDIHBlci1wYWNrZXQgaGVhZGVyIGluc3RlYWQuIFNvbWUgbW9yZSBjb25jcmV0 ZSBjb21tZW50cyBvbiBlYWNoIGZyYW1lOg0KDQotIEFDSyBmcmFtZTogSGVyZSB0aGUgZGVjaXNp b24gd2FzIG1hZGUgdGhhdCBkYXRhIGlzIGFja+KAmWVkIG9uIGEgcGVyLXBhY2tldCBiYXNpcyAo aW5zdGVhZCBvbiBwZXIgZnJhbWUtYmFzaXMpLiBJIGJlbGlldmUgdGhpcyBkZWNpc2lvbiBpcyBm aW5lIChkaWRu4oCZdCBhY3R1YWxseSBmdXJ0aGVyIHRoaW5rIGFib3V0IGl0IHNvIGZhcikuIEhv d2V2ZXIsIGFzIHRoZXNlIGluZm9ybWF0aW9uIGFyZSBjbGVhcmx5IGFsaWduZWQgdG8gcGFja2V0 cywgSSB0aGluayB0aGV5IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBRVUlDIHBhY2tldCBoZWFkZXIu IEhlcmUgSSBhc3N1bWUgdGhhdCBpdCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIHNlbmQgbXVsdGlw bGUgQUNLIGZyYW1lcyBpbiBvbmUgcGFja2V0IGJlY2F1c2UgdGhleSBjb3VsZCBhbHdheXMgYmUg Y29tYmluZWQgdG8gb25lICh0byBzYXZlIHNwYWNlKS4gSW4gdGhpcyBjYXNlIGl0IHdvdWxkIGJl IHN1ZmZpY2llbnQgdG8gaGF2ZSBvbmUgZmxhZyBpbiB0aGUgZ2VuZXJhbCBRVUlDIHBhY2tldCBo ZWFkZXIgdGhhdCBpbmRpY2F0ZXMgaWYgdGhlc2UgaW5mb3JtYXRpb24gYXJlIHByZXNlbnQgb3Ig bm90Lg0KDQotIFNUT1BfV0FJVElORyBmcmFtZTogQXQgdGhlIGZpcnN0IHJlYWRpbmcgSSBkaWRu 4oCZdCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IHRoaXMgaXMgbmVlZGVkIGZvciBiZWNhdXNlIEkg ZGlkbuKAmXQgZnVsbHkgaW50ZXJuYWxpemUgdGhhdCBwYWNrZXRzIGFyZSBub3QgcmV0cmFuc21p dHRlZCAoYnR3LiB0aGF0IGNvdWxkIGJlIHN0YXRlZCBtb3JlIGNsZWFybHkgaW4gdGhlIGludHJv ISkuIEkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgaW5ldml0YWJsZSBjb25uZWN0aW9uIHRvIGhv dyBhY2snaW5nIGlzIGRvbmUgYW5kIHRoZXJlZm9yZSBJIHJlYWxseSBkb27igJl0IHVuZGVyc3Rh bmQgd2h5IHRoaXMgaXMgYSBzZXBhcmF0ZSBmcmFtZSBhdCBhbGwuIEZvciBtZSB0aGF0IGNvdWxk IHNpbXBseSBiZSBvbmUgZmllbGQgaW4gdGhlIEFDSyBmcmFtZSBiYXNpY2FsbHkgYWx3YXlzIGlu ZGljYXRpbmcgdGhlIGxhc3QgQUNLIGluZm9ybWF0aW9uIHJlY2VpdmVkLiANCg0KT25lIG1vcmUg Z2VuZXJhbCBjb21tZW50IGhlcmU6IEnigJltIGFsc28gbm90IGNvbnZpbmNlIHRoYXQgdGhlIEFD SyBzY2hlbWUgY2hvc2VuIChhbmQgYmFzaWNhbGx5IGFsaWduZWQgdG8gdGhlIFRDUCBBQ0sgc2No ZW1lIGlzIHRoZSByaWdodCBjaG9pY2UgaGVyZSkuIEdpdmVuIHRoYXQgeW91IGRvbuKAmXQgcmV0 cmFuc21pdCwgd291bGRuJ3QgYSBOQUNLIHNjaGVtZSBtYWtlIG1vcmUgc2Vuc2XigKY/IE1lYW5p bmcgdGhhdCB5b3UgaW5kaWNhdGUgdGhlIGhpZ2hlc3QgKHVuLW9yZGVyZWQpIHBhY2tldCBudW1i ZXIgc2VlbiBhcyB3ZWxsIGFzIGFsbCBwYWNrZXQgbnVtYmVycyBub3Qgc2VlbiBzaW5jZSB0aGUg cGFja2V0IG51bWJlciBhbm5vdW5jZWQgYnkgdGhlIGxhc3QgU1RPUF9XQUlUSU5HIHZhbHVlLiBE aWQgeW91IGNvbnNpZGVyIHRoYXQgcHJldmlvdXNseT8NCg0KLSBQSU5HIGZyYW1lOiBIYXZpbmcg YSB3aG9sZSBmcmFtZSBmb3IgdGhpcyByZWFsbHksIHJlYWxseSBzZWVtcyBsaWtlIG92ZXJoZWFk LCB3aGlsZSB5b3Ugb25seSBuZWVkIG9uIGJpdCBpbiB0aGUgcGFja2V0IGhlYWRlciBhbmQgbm8g ZnJhbWVzL3N0ZWFtIHBheWxvYWQgZGF0YSBhcmUgc2VuZCBhdCBhbGzigKYgQnR3LiB0aGUgcmVh Y3Rpb24gdG8gdGhpcyBzaWduYWwgaXMgbm90IHNwZWNpZmllZDogaXMgdGhlIHJlY2VpdmVyIHN1 cHBvc2VkIHRvIHNlbmQgYSBwaW5nIGJhY2sgb3IgYSBkaWZmZXJlbnQgcGFja2V0IG9yIG5vdGhp bmcgYXQgYWxsPw0KDQotIENPTk5FQ1RJT05fQ0xPU0UgYW5kIEdPX0FXQVk6IFRoZXNlIHR3byBp bmZvcm1hdGlvbiBiaXRzIGFyZSBjbGVhcmx5IHBlci1jb25uZWN0aW9uLiBJIGFsc28gZG9u4oCZ dCByZWFsbHkgc2VlIGEgbmVlZCBmb3IgYSBDT05ORUNUSU9OX0NMT1NFIGFuZCBhIFBVQkxJQ19S RVNFVC4gSSB0aGluayB0aGVyZSBjYW4gYmUgYSB3YXkgdG8gY29tYmluZSB0aGVzZSBzaWduYWxz IGdpdmVuIHdlIGhhdmUgYSBtZWNoYW5pc20gZm9yIGludGVncml0eSBjaGVja2luZy4NCg0KTWly amENCg0KDQo= From nobody Mon Dec 5 12:26:12 2016 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 5C199129CE5 for ; Mon, 5 Dec 2016 12:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 R84Qq-XEMsCn for ; Mon, 5 Dec 2016 12:26:09 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 38E35129CCD for ; Mon, 5 Dec 2016 12:26:09 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id w194so185201207vkw.2 for ; Mon, 05 Dec 2016 12:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IbeTpGjaQKAw1UPpFSEg29TO908HCu9GWUfgCUznpiM=; b=pfhIuwznou8lolldmw4kA/bmqMTaScx34F8Nf4aLc0JQPO7w+55C01PY9wH0irffK2 lxryfc1zLdDxgOJRKr9nUFt7g3H2mCsxO7ioxG2Kp6UJnCZjOUxOPP1ewpUCe+PID+UW pSmH0B7l8gIJ3XqxGq/FKcWnHdmM1NpC48wZwPT2tW0yKgfh0YAX3Lxen6gk3usenE9U Yzd2OFBI2g1UgPdfszLrnUeHxcpXQN5xFNGMo4/lprd2KE1ewNjYDqM0P+lWzj9KfLcf ykWRtT/xeQCI2zuMjipG1T9gToJziF6P8QYtEmohTXZjb+34aX3fJyRW1MOy9o4askx4 sZKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IbeTpGjaQKAw1UPpFSEg29TO908HCu9GWUfgCUznpiM=; b=i31Sf9tpK/lJg0UpvtvsWKiEnbQNebmvBEYq6ko3WrSY4PZpTRefD4IDwDnC7uAukq 4Rws8uJ15YimqD9839X87uKx4/4Q+BNk1Kjwp5LrCdYOT6fhJ2+U21+moFYvBfjBKV8O wR4r4RsTtsUyBpEEti3tKOsYmXemDwHOvtI4yKEBjj1W3Rj+TNflau9SlvBIwu2mTo/M tjWSfOcRx4w8cKgKMunWjU5SuxPOcUllJKb5oxwknyjhGvU082tAbkOwa/BMNjXcIrQ6 tXErFrG+AKJCcMEkSwaCdVPQT1RMr1MtjeY4oU18Zpt59ouRcFerMh3pf7E7NMlK0gfo SN3w== X-Gm-Message-State: AKaTC02yY0kHFedmR3dPHXuyr6t27tNDQIKwqrBVP5zF9Qit9IO1dp/wMyy/2sw01a65UfGeyDbqEexzXaI+hHai X-Received: by 10.31.164.204 with SMTP id n195mr18053849vke.58.1480969568167; Mon, 05 Dec 2016 12:26:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Mon, 5 Dec 2016 12:26:07 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 5 Dec 2016 12:26:07 -0800 Message-ID: Subject: Re: HTTP Mapping: Fixing streams-in-streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1142e10a093c4f0542ef1998 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 20:26:11 -0000 --001a1142e10a093c4f0542ef1998 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the work, Mike. I like this approach -- it's a great way to separate the header compression issue from the issue of a clean mapping of HTTP headers/data to QUIC streams. I think we should discuss the HTTP to QUIC stream mapping proposal you've outlined, but should we do that on an issue? Or a separate thread? FWIW, I like this mapping approach, where HTTP headers and body are mapped to a stream-pair. As I've noted earlier, QUIC's streams are ephemeral and should be lightweight, which means that they can be used instead of building a new framing format for HTTP headers vs body. On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop wrote: > We have the existing document which puts everything on a single stream an= d > retains HTTP/2 framing. At the WG meeting, I heard substantial desire to > move as much as possible off to separate streams per request. There was > also discussion about how to modify HPACK (Buck has a proposal via e-mail= ; > I have a draft) to enable this, but from side conversations, I think > there=E2=80=99s also a desire to reuse HPACK code where possible and mini= mize > changes. > > > > What I=E2=80=99d like to propose as the path forward is this: > > - Change the mapping document to use the two-streams-per-request model > described in draft-bishop-quic-http-and-qpack > section > 3.1 with some of the frame redefinitions from section 3.2. > - Augment header-bearing frames with a sequence number > - Continue to use unmodified HPACK with a requirement that frames be > fed to the decoder in order for now > > > > This should produce no worse head-of-line blocking than currently exists, > reuses existing HPACK code, and lets us make progress on the current > draft. In parallel and as we have people to work on it, we can decide to > what extent we want to modify HPACK to reduce HOL-blocking issues. (I=E2= =80=99d > encourage Buck to generate a short draft on his idea as well, so we have > two ideas to compare.) > > > > I=E2=80=99d specifically like opinions from the WG on whether that=E2=80= =99s the path we > want to move forward with, or if there=E2=80=99s an alternative I haven= =E2=80=99t heard. > If that=E2=80=99s acceptable to the WG, I=E2=80=99ll start a pull request= for review. > --001a1142e10a093c4f0542ef1998 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the work, Mike. I like this approach -- it'= s a great way to separate the header compression issue from the issue of a = clean mapping of HTTP headers/data to QUIC streams. I think we should discu= ss the HTTP to QUIC stream mapping proposal you've outlined, but should= we do that on an issue? Or a separate thread?

FWIW, I l= ike this mapping approach, where HTTP headers and body are mapped to a stre= am-pair. As I've noted earlier, QUIC's streams are ephemeral and sh= ould be lightweight, which means that they can be used instead of building = a new framing format for HTTP headers vs body.


On Thu, Dec 1, 2016= at 3:35 PM, Mike Bishop <Michael.Bishop@microsoft.com><= /span> wrote:

We have the existing document which puts everything = on a single stream and retains HTTP/2 framing.=C2=A0 At the WG meeting, I h= eard substantial desire to move as much as possible off to separate streams= per request.=C2=A0 There was also discussion about how to modify HPACK (Buck has a proposal via e-mail; I have a draft)= to enable this, but from side conversations, I think there=E2=80=99s also = a desire to reuse HPACK code where possible and minimize changes.=

=C2=A0

What I=E2=80=99d like to propose as the path forward= is this:

  • Change the mapping document to use the two-streams-per-request model de= scribed in draft-bishop-quic-http-and-qpack section 3.1 with = some of the frame redefinitions from section 3.2.
  • Aug= ment header-bearing frames with a sequence number
  • Con= tinue to use unmodified HPACK with a requirement that frames be fed to the = decoder in order for now

=C2=A0

This should produce no worse head-of-line blocking t= han currently exists, reuses existing HPACK code, and lets us make progress= on the current draft.=C2=A0 In parallel and as we have people to work on i= t, we can decide to what extent we want to modify HPACK to reduce HOL-blocking issues.=C2=A0 (I=E2=80=99d encourag= e Buck to generate a short draft on his idea as well, so we have two ideas = to compare.)

=C2=A0

I=E2=80=99d specifically like opinions from the WG o= n whether that=E2=80=99s the path we want to move forward with, or if there= =E2=80=99s an alternative I haven=E2=80=99t heard.=C2=A0 If that=E2=80=99s = acceptable to the WG, I=E2=80=99ll start a pull request for review.<= u>


--001a1142e10a093c4f0542ef1998-- From nobody Mon Dec 5 12:36:32 2016 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 BE063129409 for ; Mon, 5 Dec 2016 12:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 OFgnFGqIJ4qi for ; Mon, 5 Dec 2016 12:36:28 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 5AB8312956B for ; Mon, 5 Dec 2016 12:36:26 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id a10so260101525ywa.3 for ; Mon, 05 Dec 2016 12:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8Ur7F5vwa5Ve/nBjndSErK1Yuca7OjmFVQ8Pd+qFOCk=; b=gs58j8pDL7OKMbBfPNEeXpo2yRXCsny3A3OGhlYHs4reN5IZ3K06vKO+eu+gog2mGY cLZJFPfVdI2WOJtw4zjitMrQEOO4F1z8VndCWT+D+Q/UwR1ysbpTu9uBSHaBG0m9PNl7 CtIxL78DnxIcRuItY4cmABaqs3KSuqDVirIZI1Q0vUHlDGSFB1HCBUk7HkiRGRPmEQAb Bt1TUeq69tLFsGO9Ugfc2uzmcE800ThD6iOSpOFstHN/ylB4NVBIBut6IBFZMp/Q+CYf n1pbFmbPZtHnKHlk0h7fPeN1HjMvSiJvtH+lxE3UZ/TGO/5q9dXCXvqmpoxPW9dEQiWg bupw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8Ur7F5vwa5Ve/nBjndSErK1Yuca7OjmFVQ8Pd+qFOCk=; b=G4adZTv0UkbDfqHuJ+WM08UpttF7yvD2Kn6t5NFfzrAMwscrvNG8u7YR5xmOX9fkK5 EdfayzlvxctN8M8P4gov4dd/ObAzksNUqErDdUP+Cf+zGSvPzqSppPSwWu7qdEvfPVQm OtryeJYfTcWf8mq8gDZg0UU/oXZ7RjXBNiWbBS+LG+pS2sGdCNKRoqr15qjgUgDU+kfL 2arWyeSszpYYQOPZiSDCu8HRDSCb/vqdXL+bJIz7Kjq+uzP2lLyzIVQ7xFrGPTpPxnBN 31kARLUYmrKxeFTPWGtol7mzXJt7HkgVYt9j2jZFhqrcurSiQCU+7JnOzC9jviZHogfH 6uKQ== X-Gm-Message-State: AKaTC02hi2Icnb124F5kTHvBYyCHXw1k2uld8CgdoVWOEBnszQ4MwIxiAx3ufdqWixiG3etnKGpct+zXYPZMO3k+ X-Received: by 10.129.78.205 with SMTP id c196mr61813889ywb.63.1480970185510; Mon, 05 Dec 2016 12:36:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Mon, 5 Dec 2016 12:36:05 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Mon, 5 Dec 2016 15:36:05 -0500 Message-ID: Subject: Re: HTTP Mapping: Fixing streams-in-streams To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114db8ead4e4780542ef3d56 Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 20:36:31 -0000 --001a114db8ead4e4780542ef3d56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, moving forward with the existing level of HOL blocking and improving upon it seems practical, since it seems very likely we'll move to the two-streams-per-request model no matter what. On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar wrote: > Thanks for the work, Mike. I like this approach -- it's a great way to > separate the header compression issue from the issue of a clean mapping o= f > HTTP headers/data to QUIC streams. I think we should discuss the HTTP to > QUIC stream mapping proposal you've outlined, but should we do that on an > issue? Or a separate thread? > > FWIW, I like this mapping approach, where HTTP headers and body are mappe= d > to a stream-pair. As I've noted earlier, QUIC's streams are ephemeral and > should be lightweight, which means that they can be used instead of > building a new framing format for HTTP headers vs body. > > > On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop > wrote: > >> We have the existing document which puts everything on a single stream >> and retains HTTP/2 framing. At the WG meeting, I heard substantial desi= re >> to move as much as possible off to separate streams per request. There = was >> also discussion about how to modify HPACK (Buck has a proposal via e-mai= l; >> I have a draft) to enable this, but from side conversations, I think >> there=E2=80=99s also a desire to reuse HPACK code where possible and min= imize >> changes. >> >> >> >> What I=E2=80=99d like to propose as the path forward is this: >> >> - Change the mapping document to use the two-streams-per-request >> model described in draft-bishop-quic-http-and-qpack >> >> section 3.1 with some of the frame redefinitions from section 3.2. >> - Augment header-bearing frames with a sequence number >> - Continue to use unmodified HPACK with a requirement that frames be >> fed to the decoder in order for now >> >> >> >> This should produce no worse head-of-line blocking than currently exists= , >> reuses existing HPACK code, and lets us make progress on the current >> draft. In parallel and as we have people to work on it, we can decide t= o >> what extent we want to modify HPACK to reduce HOL-blocking issues. (I= =E2=80=99d >> encourage Buck to generate a short draft on his idea as well, so we have >> two ideas to compare.) >> >> >> >> I=E2=80=99d specifically like opinions from the WG on whether that=E2=80= =99s the path we >> want to move forward with, or if there=E2=80=99s an alternative I haven= =E2=80=99t heard. >> If that=E2=80=99s acceptable to the WG, I=E2=80=99ll start a pull reques= t for review. >> > > --001a114db8ead4e4780542ef3d56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, moving forward with the existing level of HOL bloc= king and improving upon it seems practical, since it seems very likely we&#= 39;ll move to the two-streams-per-request model no matter what.

On Mon, Dec 5, 2016 at = 3:26 PM, Jana Iyengar <jri@google.com> wrote:
Thanks for the work, Mike. I like this ap= proach -- it's a great way to separate the header compression issue fro= m the issue of a clean mapping of HTTP headers/data to QUIC streams. I thin= k we should discuss the HTTP to QUIC stream mapping proposal you've out= lined, but should we do that on an issue? Or a separate thread?

FWIW, I like this mapping approach, where HTTP headers and body are= mapped to a stream-pair. As I've noted earlier, QUIC's streams are= ephemeral and should be lightweight, which means that they can be used ins= tead of building a new framing format for HTTP headers vs body.
<= br>

On Thu, Dec 1, 2016 at 3:35 PM, Mike = Bishop <Michael.Bishop@microsoft.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

We have the existing document which puts everything = on a single stream and retains HTTP/2 framing.=C2=A0 At the WG meeting, I h= eard substantial desire to move as much as possible off to separate streams= per request.=C2=A0 There was also discussion about how to modify HPACK (Buck has a proposal via e-mail; I have a draft)= to enable this, but from side conversations, I think there=E2=80=99s also = a desire to reuse HPACK code where possible and minimize changes.=

=C2=A0

What I=E2=80=99d like to propose as the path forward= is this:

  • Change the mapping document to use the two-streams= -per-request model described in draft-bishop-quic-http-and-qpack section 3.1 with = some of the frame redefinitions from section 3.2.
  • Augment header-bearing frames with a sequence number
  • Continue to use unmodified HPACK wit= h a requirement that frames be fed to the decoder in order for now

=C2=A0

This should produce no worse head-of-line blocking t= han currently exists, reuses existing HPACK code, and lets us make progress= on the current draft.=C2=A0 In parallel and as we have people to work on i= t, we can decide to what extent we want to modify HPACK to reduce HOL-blocking issues.=C2=A0 (I=E2=80=99d encourag= e Buck to generate a short draft on his idea as well, so we have two ideas = to compare.)

=C2=A0

I=E2=80=99d specifically like opinions from the WG o= n whether that=E2=80=99s the path we want to move forward with, or if there= =E2=80=99s an alternative I haven=E2=80=99t heard.=C2=A0 If that=E2=80=99s = acceptable to the WG, I=E2=80=99ll start a pull request for review.<= u>



--001a114db8ead4e4780542ef3d56-- From nobody Mon Dec 5 12:44:09 2016 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 C30F4129D0C for ; Mon, 5 Dec 2016 12:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 c9bbAtBDQG1E for ; Mon, 5 Dec 2016 12:44:06 -0800 (PST) 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 5DACB129CF5 for ; Mon, 5 Dec 2016 12:44:06 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id r204so260794609ywb.0 for ; Mon, 05 Dec 2016 12:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bk+H4bEznWJyEvNf97xCd4rUYPmetfcIlB+lLxKekyw=; b=ShCpmIYTw1eRNJYBTUf8720X8f5MYKBUYAZQqZpcKFJHAE4HsFeFeB34EWXJ9D2j3a fy9rNN27LTAnEn60D6DE1AveoIdOztvALECQihUFUOFeniN1SQFQg2SJQmVj0ZLkXzrt 9Fh62/3Zx5c+wdqW5oGKsvM6Xq55TOPtewyZ3Jsq9S6570WmEmCBwoRdu1mfDNHnPZ4W kpmg4LeLSHbt42z3hkCU6gzXJTM6WUiKbq2BfW0F4X2ymdQcYIR8FaM1jY1+PKWz8ggO 5P7bVzfKdH4rxxi1QLwALfM/K7A/OW0JXoeR92pPpU6zoqJnRKyMtPMcEdi8Cg9H9D5x yTbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bk+H4bEznWJyEvNf97xCd4rUYPmetfcIlB+lLxKekyw=; b=Fs2qhPZl+n/xoxsP/PmryobyOiwphkcAFpYq9VwgoBlvZrysAgzLWCpsiIjvMfG3xj GVUCx9dTYOQSP0ot7OcdXUeUrl5eDZmyPy4Lon9IyYu6z3b3acs/l2FMTlm1i3j+IZBL yh54EB3WIto2pE9sD3XYKiXRVurJ3c9n3qOXhZv/AFqBLBkyJ43NrG719I5NXuMytgMv E0BwtJvVojSaglogWB0+37LEz7i88PACtNIMwxp25nJ3KmnCdjRiGXmWPvCAg0xb88py CoxhmZ/rt0AF+IFK8OuePPN1swbeiX/KwAoDqA8zGDgB+RrLDed9oBv1z51js9+j8T/s Q3fw== X-Gm-Message-State: AKaTC03xOTixJhZPypEL+ktadGkwxKhGvjUn0/CHcxXiN2aqTT4b8zkgFiGhavAGSKdizxBGN73MouBFUg08MjPv X-Received: by 10.13.245.199 with SMTP id e190mr54444443ywf.317.1480970645334; Mon, 05 Dec 2016 12:44:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Mon, 5 Dec 2016 12:43:44 -0800 (PST) In-Reply-To: References: <938D954F-A61D-4779-90D6-CC2800CF75DE@tik.ee.ethz.ch> From: Ian Swett Date: Mon, 5 Dec 2016 15:43:44 -0500 Message-ID: Subject: Re: Review of draft-ietf-quic-transport-00 To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c032e703d59ad0542ef59ac Archived-At: Cc: "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 20:44:09 -0000 --94eb2c032e703d59ad0542ef59ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In regards to your PS, I added a note to fix this as part Issue #35( https://github.com/quicwg/base-drafts/issues/35) On Mon, Dec 5, 2016 at 1:57 PM, Mike Bishop wrote: > Having an infinite number of streams open and idle seems like a good way > to waste application resources tracking state. Speaking from an > application perspective, I'm reading from a stream and would like a way t= o > know when I've reached the end (rather than just having not received it > yet). Of course, I could define that myself with an EOF-indicator on the > stream data if there's a good reason for the transport *not* to provide > that functionality. Other than simplifying the stream state machine, why > wouldn't you support it? > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewi= nd > Sent: Monday, December 5, 2016 9:03 AM > To: quic@ietf.org > Subject: Review of draft-ietf-quic-transport-00 > > Hi all, > > I reviewed draft-ietf-quic-transport-00 as an individual. I have quite a > few comments but I would like to raise three high-level design questions > which I will send separate mails for next with more explanation to keep t= he > discussion separated. I do have more comments but I might bring them up > later or just send a PR for some of them. Excuse me if parts of these > issues have been discussed earlier; it=E2=80=99s not unlikely that I=E2= =80=99ve missed > parts of previous discussions given the amount of mail we currently have = on > this list. > > The three high level points, which are more on the transporty side of > life, are (see further explanation in following mails): > > 1. Per-stream vs. per-connection information: They way per-stream and > per-connection information are mixed up in frames (or not) is really > confusing to me. I have some concrete examples and proposal in the next > mail, and this is a little related to my next point. > > 2. Encryption: The split between the crypto and the transport handshake i= s > confusing and, as I believe was discussed to some extend already, it=E2= =80=99s not > clear which information will be encrypted and which will be visible. > > 3. Do we really need to close streams? Why not just leave them open and > have them inactive, e.g. with a time-out and/or advertising a window of > zero=E2=80=A6? Especially reading section 8, I think that would simplify = things > enormously. > > I think some of these questions are connected to the split of documents, > especially regarding the tls-doc but also the cc/recovery-doc. I only > reviewed in detail this doc, the quic-transport draft, and only skimmed t= he > other docs, however, to my understanding as it should be possible to > replace the crypto-negotiation as well as recovery mechanism with other > mechanisms, and as such this draft must be stand-alone to a certain exte= nd > and therefore a few things are missing. > > Please see next mails! > Mirja > > > P.S.: One nit I would like to mention here: > Section 4.2 (Regular Packets) page 10 says: "The first packet send by an > endpoint MUST have a packet number of 1." > And section 7 (Packetization and Reliability) page 28 says: "That is, the > first packet in both directions of the connection MUST have a packet numb= er > of 0." > > > --94eb2c032e703d59ad0542ef59ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In regards to your PS, I added a note to fix this as = part Issue #35(= https://github.com/quicwg/base-drafts/issues/35)

On Mon, Dec 5, 2016 at 1= :57 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
Having an infinite number of str= eams open and idle seems like a good way to waste application resources tra= cking state.=C2=A0 Speaking from an application perspective, I'm readin= g from a stream and would like a way to know when I've reached the end = (rather than just having not received it yet).=C2=A0 Of course, I could def= ine that myself with an EOF-indicator on the stream data if there's a g= ood reason for the transport *not* to provide that functionality.=C2=A0 Oth= er than simplifying the stream state machine, why wouldn't you support = it?

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mirja K=C3=BChlewind
Sent: Monday, December 5, 2016 9:03 AM
To: quic@ietf.org
Subject: Review of draft-ietf-quic-transport-00

Hi all,

I reviewed draft-ietf-quic-transport-00 as an individual. I have quite a fe= w comments but I would like to raise three high-level design questions whic= h I will send separate mails for next with more explanation to keep the dis= cussion separated. I do have more comments but I might bring them up later = or just send a PR for some of them. Excuse me if parts of these issues have= been discussed earlier; it=E2=80=99s not unlikely that I=E2=80=99ve missed= parts of previous discussions given the amount of mail we currently have o= n this list.

The three high level points, which are more on the transporty side of life,= are (see further explanation in following mails):

1. Per-stream vs. per-connection information: They way per-stream and per-c= onnection information are mixed up in frames (or not) is really confusing t= o me. I have some concrete examples and proposal in the next mail, and this= is a little related to my next point.

2. Encryption: The split between the crypto and the transport handshake is = confusing and, as I believe was discussed to some extend already, it=E2=80= =99s not clear which information will be encrypted and which will be visibl= e.

3. Do we really need to close streams? Why not just leave them open and hav= e them inactive, e.g. with a time-out and/or advertising a window of zero= =E2=80=A6? Especially reading section 8, I think that would simplify things= enormously.

I think some of these questions are connected to the split of documents, es= pecially regarding the tls-doc but also the cc/recovery-doc. I only reviewe= d in detail this doc, the quic-transport draft, and only skimmed the other = docs, however, to my understanding as it should be possible to replace the = crypto-negotiation as well as recovery mechanism with other mechanisms,=C2= =A0 and as such this draft must be stand-alone to a certain extend and ther= efore a few things are missing.

Please see next mails!
Mirja


P.S.: One nit I would like to mention here:
Section 4.2 (Regular Packets) page 10 says: "The first packet send by = an endpoint MUST have a packet number of 1."
And section 7 (Packetization and Reliability) page 28 says: "That is, = the first packet in both directions of the connection MUST have a packet nu= mber of 0."



--94eb2c032e703d59ad0542ef59ac-- From nobody Mon Dec 5 13:52:47 2016 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 A5B7E129E0B for ; Mon, 5 Dec 2016 13:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 rbrCr2kKGw4C for ; Mon, 5 Dec 2016 13:52:42 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0127.outbound.protection.outlook.com [104.47.34.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEC6129E2C for ; Mon, 5 Dec 2016 13:52:21 -0800 (PST) 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; bh=/VhBwsNkKJ0semEW7WDlBdRvR4JX5pcESshR4DEuUcA=; b=YL7YwERXwaHHurRKb9+I9WqJabEZT9gptXpewm2Qje2VoaT49rYcOy8kJ401V6maSSXpOEvt2yj2warXd4mxWInUfFeNoUTlqgxk8YIAwZO49AM0Wcl6dl9jitkDzF+FjbgFrGF5VBiSIBznWO7dOZt1bq3WuvjqiCQhVpqD+kc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 5 Dec 2016 21:52:20 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.020; Mon, 5 Dec 2016 21:52:20 +0000 From: Mike Bishop To: Ian Swett , Jana Iyengar Subject: RE: HTTP Mapping: Fixing streams-in-streams Thread-Topic: HTTP Mapping: Fixing streams-in-streams Thread-Index: AdJMK4UPnpRSHPYRT8al2LR5lm7ZTwDCknSAAABZHIAAASvckA== Date: Mon, 5 Dec 2016 21:52:19 +0000 Message-ID: References: In-Reply-To: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:9::390] x-ms-office365-filtering-correlation-id: 67a1fa6f-22da-47c4-f69d-08d41d58fcd4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:00m1YWwuDbamye4De6zY65920O/bDK1gkqyIxYtDNhwfjWzfPTJ4u/OFe9WCihuOVZpnu2kDAZ5dB8BuN1Vzr85T4Q7LiVNVlefbvFCd8J6I4CAfVldPowUdAyvzIpEGDjnrv0/7ILRUJd1yGwV6JJemipu9DemmJEqEOBQiFzgXt8YTW721btoYmCaT+Umd5YtAJJZQwrFcgQWH9V5YZFuU0bKxmvq2vRV+xtLb9hK1ChVIOw+0Ivt9tECUEF55/134in9j0WZ5Rcn1kMol0EqKFEsxovLHdiUU6JSh2iYminjcQcoJDWvlwBC3XREXwv4XjT+aVLQpwVww847ow+hrVcwA9yGLW/u/ZTp8Aw/Y6ycJkltQ6dJiDFjJFFWX1QbUeMj1HeqXn57lOvCrF9Gn9XYF8ExPt/xRlTSDCVa1xsXmPwj6Fp+qE5kYVYbIAlbhQAikGEgXQHdu0ipGy9ehJvZRsFSXayW2VcJA6lU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148)(6047074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(51914003)(377454003)(199003)(24454002)(189002)(81156014)(4326007)(6506006)(76176999)(68736007)(77096006)(7696004)(38730400001)(606004)(5005710100001)(8990500004)(10290500002)(561944003)(2906002)(7846002)(39410400001)(102836003)(790700001)(6116002)(19609705001)(39450400002)(39860400001)(2900100001)(105586002)(39840400001)(106356001)(10090500001)(122556002)(7736002)(33656002)(5001770100001)(76576001)(86612001)(101416001)(9686002)(189998001)(229853002)(2950100002)(99286002)(7906003)(8936002)(8676002)(97736004)(230783001)(5660300001)(39850400001)(81166006)(54356999)(3280700002)(3660700001)(74316002)(92566002)(86362001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708037FDDBA5E50D653FEE287830BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 21:52:20.0103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 21:52:45 -0000 --_000_BN6PR03MB2708037FDDBA5E50D653FEE287830BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3Qgd2l0aCB0aGUgZm9sbG93aW5nIHByb3Bvc2Fs IGhlcmU6ICBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzENCg0K RmVlZGJhY2sgd2VsY29tZSwgYXMgYWx3YXlzLg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBEZWNlbWJlciA1LCAyMDE2IDEyOjM2 IFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4NCkNjOiBNaWtlIEJpc2hvcCA8 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBIVFRQIE1hcHBpbmc6IEZpeGluZyBzdHJlYW1zLWluLXN0cmVhbXMN Cg0KQWdyZWVkLCBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBleGlzdGluZyBsZXZlbCBvZiBIT0wg YmxvY2tpbmcgYW5kIGltcHJvdmluZyB1cG9uIGl0IHNlZW1zIHByYWN0aWNhbCwgc2luY2UgaXQg c2VlbXMgdmVyeSBsaWtlbHkgd2UnbGwgbW92ZSB0byB0aGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVl c3QgbW9kZWwgbm8gbWF0dGVyIHdoYXQuDQoNCk9uIE1vbiwgRGVjIDUsIDIwMTYgYXQgMzoyNiBQ TSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3 cm90ZToNClRoYW5rcyBmb3IgdGhlIHdvcmssIE1pa2UuIEkgbGlrZSB0aGlzIGFwcHJvYWNoIC0t IGl0J3MgYSBncmVhdCB3YXkgdG8gc2VwYXJhdGUgdGhlIGhlYWRlciBjb21wcmVzc2lvbiBpc3N1 ZSBmcm9tIHRoZSBpc3N1ZSBvZiBhIGNsZWFuIG1hcHBpbmcgb2YgSFRUUCBoZWFkZXJzL2RhdGEg dG8gUVVJQyBzdHJlYW1zLiBJIHRoaW5rIHdlIHNob3VsZCBkaXNjdXNzIHRoZSBIVFRQIHRvIFFV SUMgc3RyZWFtIG1hcHBpbmcgcHJvcG9zYWwgeW91J3ZlIG91dGxpbmVkLCBidXQgc2hvdWxkIHdl IGRvIHRoYXQgb24gYW4gaXNzdWU/IE9yIGEgc2VwYXJhdGUgdGhyZWFkPw0KDQpGV0lXLCBJIGxp a2UgdGhpcyBtYXBwaW5nIGFwcHJvYWNoLCB3aGVyZSBIVFRQIGhlYWRlcnMgYW5kIGJvZHkgYXJl IG1hcHBlZCB0byBhIHN0cmVhbS1wYWlyLiBBcyBJJ3ZlIG5vdGVkIGVhcmxpZXIsIFFVSUMncyBz dHJlYW1zIGFyZSBlcGhlbWVyYWwgYW5kIHNob3VsZCBiZSBsaWdodHdlaWdodCwgd2hpY2ggbWVh bnMgdGhhdCB0aGV5IGNhbiBiZSB1c2VkIGluc3RlYWQgb2YgYnVpbGRpbmcgYSBuZXcgZnJhbWlu ZyBmb3JtYXQgZm9yIEhUVFAgaGVhZGVycyB2cyBib2R5Lg0KDQoNCk9uIFRodSwgRGVjIDEsIDIw MTYgYXQgMzozNSBQTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCldlIGhhdmUgdGhl IGV4aXN0aW5nIGRvY3VtZW50IHdoaWNoIHB1dHMgZXZlcnl0aGluZyBvbiBhIHNpbmdsZSBzdHJl YW0gYW5kIHJldGFpbnMgSFRUUC8yIGZyYW1pbmcuICBBdCB0aGUgV0cgbWVldGluZywgSSBoZWFy ZCBzdWJzdGFudGlhbCBkZXNpcmUgdG8gbW92ZSBhcyBtdWNoIGFzIHBvc3NpYmxlIG9mZiB0byBz ZXBhcmF0ZSBzdHJlYW1zIHBlciByZXF1ZXN0LiAgVGhlcmUgd2FzIGFsc28gZGlzY3Vzc2lvbiBh Ym91dCBob3cgdG8gbW9kaWZ5IEhQQUNLIChCdWNrIGhhcyBhIHByb3Bvc2FsIHZpYSBlLW1haWw7 IEkgaGF2ZSBhIGRyYWZ0KSB0byBlbmFibGUgdGhpcywgYnV0IGZyb20gc2lkZSBjb252ZXJzYXRp b25zLCBJIHRoaW5rIHRoZXJl4oCZcyBhbHNvIGEgZGVzaXJlIHRvIHJldXNlIEhQQUNLIGNvZGUg d2hlcmUgcG9zc2libGUgYW5kIG1pbmltaXplIGNoYW5nZXMuDQoNCldoYXQgSeKAmWQgbGlrZSB0 byBwcm9wb3NlIGFzIHRoZSBwYXRoIGZvcndhcmQgaXMgdGhpczoNCg0KICAqICAgQ2hhbmdlIHRo ZSBtYXBwaW5nIGRvY3VtZW50IHRvIHVzZSB0aGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVlc3QgbW9k ZWwgZGVzY3JpYmVkIGluIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjaz4gc2Vj dGlvbiAzLjEgd2l0aCBzb21lIG9mIHRoZSBmcmFtZSByZWRlZmluaXRpb25zIGZyb20gc2VjdGlv biAzLjIuDQogICogICBBdWdtZW50IGhlYWRlci1iZWFyaW5nIGZyYW1lcyB3aXRoIGEgc2VxdWVu Y2UgbnVtYmVyDQogICogICBDb250aW51ZSB0byB1c2UgdW5tb2RpZmllZCBIUEFDSyB3aXRoIGEg cmVxdWlyZW1lbnQgdGhhdCBmcmFtZXMgYmUgZmVkIHRvIHRoZSBkZWNvZGVyIGluIG9yZGVyIGZv ciBub3cNCg0KVGhpcyBzaG91bGQgcHJvZHVjZSBubyB3b3JzZSBoZWFkLW9mLWxpbmUgYmxvY2tp bmcgdGhhbiBjdXJyZW50bHkgZXhpc3RzLCByZXVzZXMgZXhpc3RpbmcgSFBBQ0sgY29kZSwgYW5k IGxldHMgdXMgbWFrZSBwcm9ncmVzcyBvbiB0aGUgY3VycmVudCBkcmFmdC4gIEluIHBhcmFsbGVs IGFuZCBhcyB3ZSBoYXZlIHBlb3BsZSB0byB3b3JrIG9uIGl0LCB3ZSBjYW4gZGVjaWRlIHRvIHdo YXQgZXh0ZW50IHdlIHdhbnQgdG8gbW9kaWZ5IEhQQUNLIHRvIHJlZHVjZSBIT0wtYmxvY2tpbmcg aXNzdWVzLiAgKEnigJlkIGVuY291cmFnZSBCdWNrIHRvIGdlbmVyYXRlIGEgc2hvcnQgZHJhZnQg b24gaGlzIGlkZWEgYXMgd2VsbCwgc28gd2UgaGF2ZSB0d28gaWRlYXMgdG8gY29tcGFyZS4pDQoN CknigJlkIHNwZWNpZmljYWxseSBsaWtlIG9waW5pb25zIGZyb20gdGhlIFdHIG9uIHdoZXRoZXIg dGhhdOKAmXMgdGhlIHBhdGggd2Ugd2FudCB0byBtb3ZlIGZvcndhcmQgd2l0aCwgb3IgaWYgdGhl cmXigJlzIGFuIGFsdGVybmF0aXZlIEkgaGF2ZW7igJl0IGhlYXJkLiAgSWYgdGhhdOKAmXMgYWNj ZXB0YWJsZSB0byB0aGUgV0csIEnigJlsbCBzdGFydCBhIHB1bGwgcmVxdWVzdCBmb3IgcmV2aWV3 Lg0KDQoNCg== --_000_BN6PR03MB2708037FDDBA5E50D653FEE287830BN6PR03MB2708namp_ 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 O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ3ODQ5 NzcwMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjUyMjY3OTgyO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBjcmVhdGVk IGEgcHVsbCByZXF1ZXN0IHdpdGggdGhlIGZvbGxvd2luZyBwcm9wb3NhbCBoZXJlOiZuYnNwOw0K PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzcxIj5o dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzE8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZlZWRiYWNrIHdlbGNvbWUsIGFzIGFsd2F5cy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2ds ZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERlY2VtYmVyIDUsIDIwMTYgMTI6MzYg UE08YnI+DQo8Yj5Ubzo8L2I+IEphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IEhUVFAgTWFwcGluZzogRml4aW5nIHN0cmVhbXMtaW4tc3RyZWFtczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLCBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBl eGlzdGluZyBsZXZlbCBvZiBIT0wgYmxvY2tpbmcgYW5kIGltcHJvdmluZyB1cG9uIGl0IHNlZW1z IHByYWN0aWNhbCwgc2luY2UgaXQgc2VlbXMgdmVyeSBsaWtlbHkgd2UnbGwgbW92ZSB0byB0aGUg dHdvLXN0cmVhbXMtcGVyLXJlcXVlc3QgbW9kZWwgbm8gbWF0dGVyIHdoYXQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyA1LCAyMDE2IGF0 IDM6MjYgUE0sIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZv ciB0aGUgd29yaywgTWlrZS4gSSBsaWtlIHRoaXMgYXBwcm9hY2ggLS0gaXQncyBhIGdyZWF0IHdh eSB0byBzZXBhcmF0ZSB0aGUgaGVhZGVyIGNvbXByZXNzaW9uIGlzc3VlIGZyb20gdGhlIGlzc3Vl IG9mIGEgY2xlYW4gbWFwcGluZyBvZiBIVFRQIGhlYWRlcnMvZGF0YSB0byBRVUlDIHN0cmVhbXMu IEkgdGhpbmsgd2Ugc2hvdWxkIGRpc2N1c3MgdGhlIEhUVFAgdG8gUVVJQyBzdHJlYW0gbWFwcGlu Zw0KIHByb3Bvc2FsIHlvdSd2ZSBvdXRsaW5lZCwgYnV0IHNob3VsZCB3ZSBkbyB0aGF0IG9uIGFu IGlzc3VlPyBPciBhIHNlcGFyYXRlIHRocmVhZD88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZXSVcsIEkgbGlrZSB0aGlzIG1hcHBpbmcgYXBwcm9hY2gsIHdo ZXJlIEhUVFAgaGVhZGVycyBhbmQgYm9keSBhcmUgbWFwcGVkIHRvIGEgc3RyZWFtLXBhaXIuIEFz IEkndmUgbm90ZWQgZWFybGllciwgUVVJQydzIHN0cmVhbXMgYXJlIGVwaGVtZXJhbCBhbmQgc2hv dWxkIGJlIGxpZ2h0d2VpZ2h0LCB3aGljaCBtZWFucyB0aGF0IHRoZXkgY2FuIGJlIHVzZWQgaW5z dGVhZCBvZiBidWlsZGluZyBhIG5ldyBmcmFtaW5nDQogZm9ybWF0IGZvciBIVFRQIGhlYWRlcnMg dnMgYm9keS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRGVjIDEsIDIwMTYgYXQgMzozNSBQTSwgTWlr ZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5XZSBoYXZlIHRoZSBleGlzdGluZyBkb2N1bWVudCB3aGljaCBwdXRzIGV2 ZXJ5dGhpbmcgb24gYSBzaW5nbGUgc3RyZWFtIGFuZCByZXRhaW5zIEhUVFAvMiBmcmFtaW5nLiZu YnNwOyBBdCB0aGUgV0cgbWVldGluZywgSSBoZWFyZCBzdWJzdGFudGlhbCBkZXNpcmUgdG8gbW92 ZSBhcyBtdWNoIGFzIHBvc3NpYmxlIG9mZg0KIHRvIHNlcGFyYXRlIHN0cmVhbXMgcGVyIHJlcXVl c3QuJm5ic3A7IFRoZXJlIHdhcyBhbHNvIGRpc2N1c3Npb24gYWJvdXQgaG93IHRvIG1vZGlmeSBI UEFDSyAoQnVjayBoYXMgYSBwcm9wb3NhbCB2aWEgZS1tYWlsOyBJIGhhdmUgYSBkcmFmdCkgdG8g ZW5hYmxlIHRoaXMsIGJ1dCBmcm9tIHNpZGUgY29udmVyc2F0aW9ucywgSSB0aGluayB0aGVyZeKA mXMgYWxzbyBhIGRlc2lyZSB0byByZXVzZSBIUEFDSyBjb2RlIHdoZXJlIHBvc3NpYmxlIGFuZCBt aW5pbWl6ZQ0KIGNoYW5nZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IEnigJlk IGxpa2UgdG8gcHJvcG9zZSBhcyB0aGUgcGF0aCBmb3J3YXJkIGlzIHRoaXM6PG86cD48L286cD48 L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpDaGFuZ2UgdGhlIG1hcHBpbmcgZG9jdW1l bnQgdG8gdXNlIHRoZSB0d28tc3RyZWFtcy1wZXItcmVxdWVzdCBtb2RlbCBkZXNjcmliZWQgaW4N CjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3AtcXVpYy1o dHRwLWFuZC1xcGFjayIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1h bmQtcXBhY2s8L2E+IHNlY3Rpb24gMy4xIHdpdGggc29tZSBvZiB0aGUgZnJhbWUgcmVkZWZpbml0 aW9ucyBmcm9tIHNlY3Rpb24gMy4yLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpBdWdtZW50IGhl YWRlci1iZWFyaW5nIGZyYW1lcyB3aXRoIGEgc2VxdWVuY2UgbnVtYmVyPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCkNvbnRpbnVlIHRvIHVzZSB1bm1vZGlmaWVkIEhQQUNLIHdpdGggYSByZXF1aXJl bWVudCB0aGF0IGZyYW1lcyBiZSBmZWQgdG8gdGhlIGRlY29kZXIgaW4gb3JkZXIgZm9yIG5vdzxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBzaG91bGQgcHJvZHVjZSBubyB3 b3JzZSBoZWFkLW9mLWxpbmUgYmxvY2tpbmcgdGhhbiBjdXJyZW50bHkgZXhpc3RzLCByZXVzZXMg ZXhpc3RpbmcgSFBBQ0sgY29kZSwgYW5kIGxldHMgdXMgbWFrZSBwcm9ncmVzcyBvbiB0aGUgY3Vy cmVudCBkcmFmdC4mbmJzcDsgSW4gcGFyYWxsZWwgYW5kIGFzIHdlIGhhdmUNCiBwZW9wbGUgdG8g d29yayBvbiBpdCwgd2UgY2FuIGRlY2lkZSB0byB3aGF0IGV4dGVudCB3ZSB3YW50IHRvIG1vZGlm eSBIUEFDSyB0byByZWR1Y2UgSE9MLWJsb2NraW5nIGlzc3Vlcy4mbmJzcDsgKEnigJlkIGVuY291 cmFnZSBCdWNrIHRvIGdlbmVyYXRlIGEgc2hvcnQgZHJhZnQgb24gaGlzIGlkZWEgYXMgd2VsbCwg c28gd2UgaGF2ZSB0d28gaWRlYXMgdG8gY29tcGFyZS4pPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5J4oCZZCBzcGVjaWZpY2FsbHkgbGlrZSBvcGluaW9ucyBmcm9tIHRoZSBXRyBvbiB3aGV0 aGVyIHRoYXTigJlzIHRoZSBwYXRoIHdlIHdhbnQgdG8gbW92ZSBmb3J3YXJkIHdpdGgsIG9yIGlm IHRoZXJl4oCZcyBhbiBhbHRlcm5hdGl2ZSBJIGhhdmVu4oCZdCBoZWFyZC4mbmJzcDsgSWYgdGhh dOKAmXMgYWNjZXB0YWJsZSB0byB0aGUgV0csDQogSeKAmWxsIHN0YXJ0IGEgcHVsbCByZXF1ZXN0 IGZvciByZXZpZXcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR03MB2708037FDDBA5E50D653FEE287830BN6PR03MB2708namp_-- From nobody Mon Dec 5 14:02:54 2016 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 372641295F1 for ; Mon, 5 Dec 2016 14:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 q00E-DKvDrXu for ; Mon, 5 Dec 2016 14:02:50 -0800 (PST) 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 869DE1295D7 for ; Mon, 5 Dec 2016 14:02:50 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id a10so261333179ywa.3 for ; Mon, 05 Dec 2016 14:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GH9I3HMMrucYMpt18XB+TYysD40Do5jUG3ACM/QPf0Q=; b=kz305/T5AwnkokUmALYs4VxfSR6HpwttLm5wrhjqXobMTXQXmXYzPRKwCw0JRuTj6i Z8FHp9PA8O/G0VMBs46zOIlOSYICPXY6X9/3lN9MIgfL9kKkPJRl4YSNJsYVZdJnjRXF Im7j5g1ExfwXGt9X7T1lawJTd4aVYR9UUIJUPXJZ8EByPSLq8V0+jyTFpEZ6ZpqJ7Hsx Fi6PJMoHeTjijK+0wWw4/dfHxWMzbw+8SqgAX08VLQlj+BDH7tPVjAZAVExVSgfcJN8V s7jxlGjE7r8zg8vxIxFJYSIOAsPoZH4nQ67tP6TLXAPeGPTOJVVeh2xvhtlZDXTtCO+U Xfdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GH9I3HMMrucYMpt18XB+TYysD40Do5jUG3ACM/QPf0Q=; b=dVb3GXG1jBQz+skqR0HoMJKwbNXVFR9wZSj0b9ZEtkB2rMEkz8HshrudMbKsEgQn+n gsVgJ3NS+A4FrQRnpwChKHc2QZFmJ82HRY26hkTdTV8MeWpxKjJmAvIj2PHhOYYLOVwN NoQU2fVX1yF3iQHirHDwJZaPDzHg0UkKkO7wS59VmQdrYKVHQnc4wReFdDHNw7sAgTql WXK4VzaqzwE55aOn2EPHKNpHKPYqotzY7WcaesMRthaXkQNzz8dXU3O4CDQpy7e/6hxk o5rB4/daJyyQ7RvhPGMpAPOYEc5EyOOVnaJkg6M+DV8FG7r7QDqn7e+RLT0jRjZOzBdc OCNw== X-Gm-Message-State: AKaTC009k4ItlW3AJcdM8T4D+SrkthhVmSQSnb+ZbcrN+vC2vwUUykJvbIaoqtEsIViQYQtotPKclvZgd6v49xq0 X-Received: by 10.129.116.195 with SMTP id p186mr54819791ywc.153.1480975369533; Mon, 05 Dec 2016 14:02:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Mon, 5 Dec 2016 14:02:29 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Mon, 5 Dec 2016 17:02:29 -0500 Message-ID: Subject: Re: Stream vs. connection To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1147fc58d2b9d20542f072aa Archived-At: Cc: "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 22:02:53 -0000 --001a1147fc58d2b9d20542f072aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 5, 2016 at 2:13 PM, Mike Bishop wrote: > I opened issue #70 for the suggestion to move ACK into a fixed per-packet > location. Ian has already replied there noting that there isn't an > (encrypted) packet header, so we'd need to create one to hold the ACK dat= a > and anything else we wanted to consolidate there. STOP_WAITING is alread= y > on the chopping block in another issue (#66). > > The PING frame handling actually is specified: "The receiver of a PING > frame simply needs to ACK the packet containing this frame." I can see > where it seems like it serves little purpose -- there's basically no > difference between PING and PADDING, except that PING is retransmittable > and PADDING is not. > > Because it must be acked, it serves as a liveness/connectivity check, which can be very useful on longer lived connections. > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewi= nd > Sent: Monday, December 5, 2016 9:03 AM > To: quic@ietf.org > Subject: Stream vs. connection > > Hi again, > > here comes further information on point one regarding the questions how t= o > treat stream-based information vs. connection-based information. This is > currently my main point about the transport design of quic. To be more > concrete, quic has the concept of packets and frames. While one regular > packet can carry multiple frames there are also other packets that do not > carry any frames/stream-based information but are related to the state > management of the whole connection (version negotiation and public reset = in > this case). I think this is all fine. My confusion comes when I look at t= he > different kinds of frames. While most of the frames carry information tha= t > is clearly assigned to one stream, there are some frames that again carry > connection-wide information, namely the ACK frame, the STOP_WAITING Frame= , > the CONNECTION_CLOSE frame, the GOWAY frame and probably also the PING > frame (not talking about the PADDING frame here because its use is fully > unclear to me=E2=80=A6). I think these information should be part of an e= ncrypted > QUIC per-packet header instead. Some more concrete comments on each frame= : > > > - ACK frame: Here the decision was made that data is ack=E2=80=99ed on a > per-packet basis (instead on per frame-basis). I believe this decision is > fine (didn=E2=80=99t actually further think about it so far). However, as= these > information are clearly aligned to packets, I think they should be part o= f > the QUIC packet header. Here I assume that it does not make sense to send > multiple ACK frames in one packet because they could always be combined t= o > one (to save space). In this case it would be sufficient to have one flag > in the general QUIC packet header that indicates if these information are > present or not. > As noted in the Issue Mike opened, there is currently no encrypted QUIC packet header, but it could be added. > > - STOP_WAITING frame: At the first reading I didn=E2=80=99t really unders= tand what > this is needed for because I didn=E2=80=99t fully internalize that packet= s are not > retransmitted (btw. that could be stated more clearly in the intro!). I > understand that this is inevitable connection to how ack'ing is done and > therefore I really don=E2=80=99t understand why this is a separate frame = at all. > For me that could simply be one field in the ACK frame basically always > indicating the last ACK information received. > As noted in Issue #66(https://github.com/quicwg/base-drafts/issues/66), it is not really necessary anymore. If not, merging into the ack frame as you mentioned is a nice simplification, but I'd rather try removing it first if possible. > One more general comment here: I=E2=80=99m also not convince that the ACK= scheme > chosen (and basically aligned to the TCP ACK scheme is the right choice > here). Given that you don=E2=80=99t retransmit, wouldn't a NACK scheme ma= ke more > sense=E2=80=A6? Meaning that you indicate the highest (un-ordered) packet= number > seen as well as all packet numbers not seen since the packet number > announced by the last STOP_WAITING value. Did you consider that previousl= y? > QUIC@Google originally implemented that. In many ways they're mostly equivalent, but it's critical to have the ack contain the smallest packet being acked, otherwise the receiver can't unilaterally stop acking old packets without receiving a stop waiting that raises the least unacked. Once you have a largest acked and a set of nack ranges and a smallest acked, you have something that looks more like ack ranges than nack ranges, but one could word it as nack ranges. The new ack block approach is much simpler to implement, and removed quite a few edge cases. I wrote a longer doc on why this change was made, but I'm unable to find it at the moment. I'll try to find it as background information. > > - PING frame: Having a whole frame for this really, really seems like > overhead, while you only need on bit in the packet header and no > frames/steam payload data are send at all=E2=80=A6 Btw. the reaction to t= his signal > is not specified: is the receiver supposed to send a ping back or a > different packet or nothing at all? > The overhead is pretty small, since it's just a byte. The reaction specified in 6.8 is: "The receiver of a PING frame simply needs to ACK the packet containing this frame." Would it be clearer as "only" instead of simply? > - CONNECTION_CLOSE and GO_AWAY: These two information bits are clearly > per-connection. I also don=E2=80=99t really see a need for a CONNECTION_C= LOSE and a > PUBLIC_RESET. I think there can be a way to combine these signals given w= e > have a mechanism for integrity checking. > A connection close is encrypted and a public reset is not. If we have non-spoofable public resets and we end up wanting to notify the path of the close, I can imagine merging them into one packet, though I would want to continue to encrypt connection close reason and details. In which case, we'd still need both. Mirja > > > --001a1147fc58d2b9d20542f072aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 5, 2016 at 2:13 PM, Mike Bishop <Michael.Bishop@microso= ft.com> wrote:
I opened issue #70 for the suggestion to move ACK into a fixed per-p= acket location.=C2=A0 Ian has already replied there noting that there isn&#= 39;t an (encrypted) packet header, so we'd need to create one to hold t= he ACK data and anything else we wanted to consolidate there.=C2=A0 STOP_WA= ITING is already on the chopping block in another issue (#66).

The PING frame handling actually is specified:=C2=A0 "The receiver of = a PING frame simply needs to ACK the packet containing this frame."=C2= =A0 I can see where it seems like it serves little purpose -- there's b= asically no difference between PING and PADDING, except that PING is retran= smittable and PADDING is not.

Because it must be acked, it serves as a liveness/connectivity c= heck, which can be very useful on longer lived connections.
=C2= =A0
-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Mirja K=C3=BChlewind
Sent: Monday, December 5, 2016 9:03 AM
To: quic@ietf.org
Subject: Stream vs. connection

Hi again,

here comes further information on point one regarding the questions how to = treat stream-based information vs. connection-based information. This is cu= rrently my main point about the transport design of quic. To be more concre= te, quic has the concept of packets and frames. While one regular packet ca= n carry multiple frames there are also other packets that do not carry any = frames/stream-based information but are related to the state management of = the whole connection (version negotiation and public reset in this case). I= think this is all fine. My confusion comes when I look at the different ki= nds of frames. While most of the frames carry information that is clearly a= ssigned to one stream, there are some frames that again carry connection-wi= de information, namely the ACK frame, the STOP_WAITING Frame, the CONNECTIO= N_CLOSE frame, the GOWAY frame and probably also the PING frame (not talkin= g about the PADDING frame here because its use is fully unclear to me=E2=80= =A6). I think these information should be part of an encrypted QUIC per-pac= ket header instead. Some more concrete comments on each frame:=C2=A0

- ACK frame: Here the decision was made that data is ack=E2=80=99ed on a pe= r-packet basis (instead on per frame-basis). I believe this decision is fin= e (didn=E2=80=99t actually further think about it so far). However, as thes= e information are clearly aligned to packets, I think they should be part o= f the QUIC packet header. Here I assume that it does not make sense to send= multiple ACK frames in one packet because they could always be combined to= one (to save space). In this case it would be sufficient to have one flag = in the general QUIC packet header that indicates if these information are p= resent or not.

As noted in = the Issue Mike opened, there is currently no encrypted QUIC packet header, = but it could be added.=C2=A0

- STOP_WAITING frame: At the first reading I didn=E2=80=99t really understa= nd what this is needed for because I didn=E2=80=99t fully internalize that = packets are not retransmitted (btw. that could be stated more clearly in th= e intro!). I understand that this is inevitable connection to how ack'i= ng is done and therefore I really don=E2=80=99t understand why this is a se= parate frame at all. For me that could simply be one field in the ACK frame= basically always indicating the last ACK information received.

As noted in Issue #66(https://github.com/quicwg/base-= drafts/issues/66), it is not really necessary anymore.=C2=A0 If not, me= rging into the ack frame as you mentioned is a nice simplification, but I&#= 39;d rather try removing it first if possible.


One more general comment here: I=E2=80=99m also not convince that the ACK s= cheme chosen (and basically aligned to the TCP ACK scheme is the right choi= ce here). Given that you don=E2=80=99t retransmit, wouldn't a NACK sche= me make more sense=E2=80=A6? Meaning that you indicate the highest (un-orde= red) packet number seen as well as all packet numbers not seen since the pa= cket number announced by the last STOP_WAITING value. Did you consider that= previously?

QUIC@Google or= iginally implemented that.=C2=A0 In many ways they're mostly equivalent= , but it's critical to have the ack contain the smallest packet being a= cked, otherwise the receiver can't unilaterally stop acking old packets= without receiving a stop waiting that raises the least unacked.=C2=A0 Once= you have a largest acked and a set of nack ranges and a smallest acked, yo= u have something that looks more like ack ranges than nack ranges, but one = could word it as nack ranges.

The new ack block ap= proach is much simpler to implement, and removed quite a few edge cases.=C2= =A0 I wrote a longer doc on why this change was made, but I'm unable to= find it at the moment.=C2=A0 I'll try to find it as background informa= tion.
=C2=A0

- PING frame: Having a whole frame for this really, really seems like overh= ead, while you only need on bit in the packet header and no frames/steam pa= yload data are send at all=E2=80=A6 Btw. the reaction to this signal is not= specified: is the receiver supposed to send a ping back or a different pac= ket or nothing at all?

The = overhead is pretty small, since it's just a byte.=C2=A0 The reaction sp= ecified in 6.8 is: "The receiver of a PING frame simply needs to ACK t= he
=C2=A0 =C2=A0packet containing this frame." =C2=A0Would i= t be clearer as "only" instead of simply?

=

- CONNECTION_CLOSE and GO_AWAY: These two information bits are clearly per-= connection. I also don=E2=80=99t really see a need for a CONNECTION_CLOSE a= nd a PUBLIC_RESET. I think there can be a way to combine these signals give= n we have a mechanism for integrity checking.
<= div>
A connection close is encrypted and a public reset is no= t.=C2=A0 If we have non-spoofable public resets and we end up wanting to no= tify the path of the close, I can imagine merging them into one packet, tho= ugh I would want to continue to encrypt connection close reason and details= .=C2=A0 In which case, we'd still need both.

Mirja



--001a1147fc58d2b9d20542f072aa-- From nobody Mon Dec 5 14:21:34 2016 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 1D555129B08 for ; Mon, 5 Dec 2016 14:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 fKfqM8yssbOd for ; Mon, 5 Dec 2016 14:21:31 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 D0152126579 for ; Mon, 5 Dec 2016 14:21:25 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id d128so61875052ybh.2 for ; Mon, 05 Dec 2016 14:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTHCrg5n/5i+2mG41uPOIOPLJbH3oEhzKkLrVUy5UtQ=; b=TDovz6oYoxZ0wINRriGBoWFSn03oFDwgPwgb9KUKeOsU9z/846MfsZyrJUWoVu6AVH D5ZdzULaftUD/Ve1C13oPtg2WfFB1dxMR0cdtXF7oe1AqqMLwdh+3hIhpeSuzInfMJ7f Lr2fYf13q+WIq6sfNBS95Y6/3SMVWJOGQRH7w5fEDKegVcdZrZIQPTZn2gte7K8bhqKf /X+ttsqiCk1rRjOVVu70IY1ZZub0eWX8ekrk/kpL7LeVIrvm5F/nNQzgVZFty0KQW9uG 97fUsAN9CHT4Qbt2LcGqEYW9/Ol9r5SooOqF6yKAyr+LmNNg50GNlwFg88GqPlWBuGad tccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nTHCrg5n/5i+2mG41uPOIOPLJbH3oEhzKkLrVUy5UtQ=; b=lAaCWV8sCWButJ8u0HV8e7Ns9VvrAUcyXvfLd9bR0Zrr14guIrfVvFh/SovQj+gWib PpKTUwo+USraYaKkEPkXwepITeskfXLit/zL79Q86/iUISmdPfm+lqiUDGxAlKt3wXce dKbSFHf0QplWku1CBTwEQojINv/IYQ+2nr1lTJuQMNpbF2dwL4BPR/lHt2zap2GORIn7 vpwv7ZoplL7YYOwL6kiIIPdD+JZ1Zif3ig5X66PvVsI8+hWXL+g/avs0t+ckJafzuue6 45OEBkOuri9RYo/YwnS1AA2FpFNVQ0G88dquGsP8/ROWCgENzbrH577lAQR1OsZBTnC3 ciJg== X-Gm-Message-State: AKaTC03OGw7MD2sQfeuMAPmP9xf5cnE4pUZj1tOFjbwDYdyc39gdoVmoj0hYFRI70HIAhMh6Y+6Y+Cgmvf4d9Gnl X-Received: by 10.37.111.214 with SMTP id k205mr28077242ybc.175.1480976484866; Mon, 05 Dec 2016 14:21:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Mon, 5 Dec 2016 14:21:04 -0800 (PST) In-Reply-To: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> From: Ian Swett Date: Mon, 5 Dec 2016 17:21:04 -0500 Message-ID: Subject: Re: Closing streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1148a5944dbc6a0542f0b5cd Archived-At: Cc: "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 22:21:34 -0000 --001a1148a5944dbc6a0542f0b5cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As a high level comment, I think the current QUIC stream state machine is quite complex, and it'd be great to simplify it. I expect it's possible, but don't have any concrete suggestions at the moment. On Mon, Dec 5, 2016 at 2:01 PM, Ian Swett wrote: > A key to making streams lightweight is to ensure they're used in order. > Otherwise tracking which streams have been previously used and closed can > consume a large amount of memory. So I believe the streams have to be > reserved or have another way to ensure they're used in order(at least > approximately). Of course, it'd be easy enough to immediately reset the > stream to indicate you're just skipping it. > > On Mon, Dec 5, 2016 at 1:52 PM, Mike Bishop > wrote: > >> "Reserved" is a concept drawn from HTTP/2 that has trickled into QUIC. >> Whether it needs to exist at the transport layer is a reasonable questio= n. >> In general terms, "reserved" means that you know what the peer is going = to >> send you on that stream (from the application layer), but they haven't >> actually done so yet. Now that you raise the question, I don't see a >> reason that couldn't be an application-layer concept and let the transpo= rt >> continue to see those streams as "idle" -- does anyone else? >> >> -----Original Message----- >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlew= ind >> Sent: Monday, December 5, 2016 9:04 AM >> To: quic@ietf.org >> Subject: Closing streams >> >> And finally (one more hi!), >> >> while reading the draft, saying that the stream handling is really >> light-way, I was asking myself if we really need to close streams at all >> (given that we also just implicitly open them). When you look at section >> 8.1 (Life of a stream) the overhead of closing streams is actually quite >> large (couple of additional states only needed for this). (Btw. I also >> don=E2=80=99t really understand what the difference between a reserved a= nd idle >> stream is=E2=80=A6 i guess that=E2=80=99s rather an interface question t= han state >> management, anyway=E2=80=A6). To my understanding, you close connection = for state >> management at the receiver side. However, as you announce the maximum >> number of streams to the other endpoint and you can use the WINDOW_UPDAT= E >> to send a zero window to make sure no additional data are send (and use >> BLOCK to reset-up state on the receiver if needed), I think it is a loca= l >> decision at the receiver which streams to remove state for if the max >> number of streams is reached. I don=E2=80=99t really see the additional = benefit the >> FIN bits are giving. Or has this proven to be really helpful in some >> real-life situation? >> >> Mirja >> > > --001a1148a5944dbc6a0542f0b5cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a high level comment, I think the current QUIC stream s= tate machine is quite complex, and it'd be great to simplify it.=C2=A0 = I expect it's possible, but don't have any concrete suggestions at = the moment.


<= br>
On Mon, Dec 5, 2016 at 2:01 PM, Ian Swett <ianswett@google.com> wrote:
A key to making streams lightweight is to ensure they= 9;re used in order.=C2=A0 Otherwise tracking which streams have been previo= usly used and closed can consume a large amount of memory.=C2=A0 So I belie= ve the streams have to be reserved or have another way to ensure they'r= e used in order(at least approximately).=C2=A0 Of course, it'd be easy = enough to immediately reset the stream to indicate you're just skipping= it. =C2=A0

On Mon, Dec 5, 2016 at 1:52 PM, Mik= e Bishop <Michael.Bishop@microsoft.com> wrote:
"Reserved" is a concept drawn fro= m HTTP/2 that has trickled into QUIC.=C2=A0 Whether it needs to exist at th= e transport layer is a reasonable question.=C2=A0 In general terms, "r= eserved" means that you know what the peer is going to send you on tha= t stream (from the application layer), but they haven't actually done s= o yet.=C2=A0 Now that you raise the question, I don't see a reason that= couldn't be an application-layer concept and let the transport continu= e to see those streams as "idle" -- does anyone else?

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewind
Sent: Monday, December 5, 2016 9:04 AM
To: quic@ietf.org Subject: Closing streams

And finally (one more hi!),

while reading the draft, saying that the stream handling is really light-wa= y, I was asking myself if we really need to close streams at all (given tha= t we also just implicitly open them). When you look at section 8.1 (Life of= a stream) the overhead of closing streams is actually quite large (couple = of additional states only needed for this). (Btw. I also don=E2=80=99t real= ly understand what the difference between a reserved and idle stream is=E2= =80=A6 i guess that=E2=80=99s rather an interface question than state manag= ement, anyway=E2=80=A6). To my understanding, you close connection for stat= e management at the receiver side. However, as you announce the maximum num= ber of streams to the other endpoint and you can use the WINDOW_UPDATE to s= end a zero window to make sure no additional data are send (and use BLOCK t= o reset-up state on the receiver if needed), I think it is a local decision= at the receiver which streams to remove state for if the max number of str= eams is reached. I don=E2=80=99t really see the additional benefit the FIN = bits are giving. Or has this proven to be really helpful in some real-life = situation?

Mirja


--001a1148a5944dbc6a0542f0b5cd-- From nobody Mon Dec 5 14:42:49 2016 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 E1D54129B58 for ; Mon, 5 Dec 2016 14:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 9ioO_s3sRB1Q for ; Mon, 5 Dec 2016 14:42:44 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0109.outbound.protection.outlook.com [104.47.34.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC411129E4C for ; Mon, 5 Dec 2016 14:42:44 -0800 (PST) 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; bh=m5gakHZ5wcZFOVJ5ptr6qWiHPLYiEI3W6UYlHWJ+93s=; b=APRZ/4O2OsrIyDwWfSdTTr7BJGdPqpSg1ivXcP4hKiKYzEMtL9dNiB93f2sReolVuhEbT9BqRBqtUvQPM0VLYMctQk6o/1BDGw75r79f7WxqIqxwiDqM1C7wWyb/kfjIQ7JbhoLVPYYHikcnGuLEp2FsjVETh9g5OBQ9ijdzr7k= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 5 Dec 2016 22:42:43 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.020; Mon, 5 Dec 2016 22:42:43 +0000 From: Mike Bishop To: Ian Swett Subject: RE: Closing streams Thread-Topic: Closing streams Thread-Index: AQHSTxrILgKjlazdGkOpQOy52b3ruqD5ssyQgAAC4ACAADfaAIAAATkw Date: Mon, 5 Dec 2016 22:42:43 +0000 Message-ID: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> In-Reply-To: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:9::390] x-ms-office365-filtering-correlation-id: 2d7fe62b-ec3b-417d-4b02-08d41d6006c9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:OchvRwbirH4lrbRDUu6NJBl1Fm8Olit1YcvPlgdpHKpAcCMk2tXYbXzhp575QvUU9rtYnYjPKEiUL5C5kREWwvNIbBVD/vkDzwI3mniLmXAyr/ATIVnkXXQLm7gi8IAVxOnsFR83vNaPdVW0TPCY5YrVrn95T+W3zVH4+m0iIgu0TFiDJlx2p9ZURHFQi2/3P4B4lrWj4tO8OdiyhBNIFCsWAuGtklHDG8ATadp+GQEITPl3WK4qAMl+LIA4ORCqvmXwvn/3U1P5oEHvuW7sUUJWP79m6FW9DVBH9tVOJyWSXQOgb7iuZ1u9bG6fDRNK/GDUEWTEo1GLV5esHemBBF6p9/ZPr5dIhT/UVURKcQJ5htBlBCx+jgOa6ZOQaHhsCUiivQnuH1k5VB8Zsg5mkIS/kJB+nfXfhyboSPe2k8Pcn/Pifp4HeqLFDC2ieORN1qiijxwdhcqHTaoKGmTcnIupHY/fzqxVHxTI6QPhaTg= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558021)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(13464003)(377454003)(199003)(3660700001)(33656002)(106356001)(101416001)(110136003)(68736007)(50986999)(81156014)(105586002)(7696004)(106116001)(6916009)(8936002)(76176999)(99286002)(76576001)(9686002)(2950100002)(3480700004)(4326007)(7846002)(7736002)(74316002)(7116003)(122556002)(54356999)(93886004)(8676002)(2906002)(5660300001)(39850400001)(81166006)(3280700002)(189998001)(6116002)(39410400001)(102836003)(790700001)(229853002)(38730400001)(2900100001)(8990500004)(86612001)(97736004)(606004)(86362001)(92566002)(5005710100001)(10290500002)(221733001)(10090500001)(39860400001)(39840400001)(39450400002)(6506006)(77096006)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270865D294AE1AF40533E53E87830BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 22:42:43.3243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: "quic@ietf.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 22:42:48 -0000 --_000_BN6PR03MB270865D294AE1AF40533E53E87830BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hldGhlciB0aGV54oCZcmUgdXNlZCBpbiBvcmRlciBvciBub3QsIHRoZXJlIGFyZSBzb21lIHZl cnkgbG9uZy1saXZlZCBzdHJlYW1zIGFuZCBzb21lIHZlcnkgc2hvcnQtbGl2ZWQgb25lcywgYXMg SeKAmW0gc3VyZSB5b3XigJl2ZSBzZWVuLiAgT25lIG9mIHRoZSBkcmF3YmFja3MgdG8gdGhlIHR3 by1zdHJlYW0tcGVyLXJlcXVlc3QgbWFwcGluZyBpbiBIVFRQLCBpbiBmYWN0LCBpcyBob3cgdGhh dCBtYXBzIHRvIHByaW9yaXRpemF0aW9uIHNjaGVtZXMgdGhhdCB1c2Ug4oCcem9tYmll4oCdIHN0 cmVhbXMgYXMgcGxhY2Vob2xkZXJzIGZvciBjZXJ0YWluIGNhdGVnb3JpZXMgb2YgcmVzb3VyY2Uu ICBJbiB0aGUgY3VycmVudCBwdWxsIHJlcXVlc3QsIGlmIHlvdSBjbG9zZSB0aGUgUVVJQyBzdHJl YW0sIHlvdSBsb3NlIHRoZSBhYmlsaXR5IHRvIHJlcHJpb3JpdGl6ZSBpdCBsYXRlci4gIChPbmUg c29sdXRpb24gaW4gdGhlIEhUVFAgbWFwcGluZyBpcyB0byBtb3ZlIFBSSU9SSVRZIHRvIGJlIGEg c2Vzc2lvbi1sZXZlbCBmcmFtZSBiYWNrIG9uIHN0cmVhbSAzLCBhbmQgaW5jbHVkZXMgYm90aCB0 aGUgcHJpb3JpdGl6ZWQgYW5kIGRlcGVuZGVudCBzdHJlYW0gSURzLikgIEV2ZW4gc28sIHlvdeKA mWxsIGhhdmUgc3RyZWFtcyAxIGFuZCAzIGxpdmluZyBmb3JldmVyLiAgSXQgc2VlbXMgbGlrZSBm b3Igc3RhdGUgbWFuYWdlbWVudCwgeW91IG5lZWQgdG8gYmUgYWJsZSB0byB0cmFjayBjb250aWd1 b3VzIHJlZ2lvbnMgaW4gdGhlIHNhbWUgc3RhdGUsIGFuZCB5b3Ugd2FudCB0aG9zZSByZWdpb25z IHRvIGJlIGxhcmdlIHNvIHlvdSBoYXZlIGFzIGZldyBkaXN0aW5jdCByZWNvcmRzIGFzIHBvc3Np YmxlLg0KDQpJbiB0ZXJtcyBvZiDigJxyZXNlcnZlZCzigJ0gdGhhdCBzZWVtcyBsaWtlIGl0IGNv dWxkIGVhc2lseSBiZSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuICBBcyBJIGVudmlzaW9uIHRo ZSBBUEksIGF0IGxlYXN0LCAoaGF2ZW7igJl0IGxvb2tlZCBhdCB5b3VycyksIHRoZSBhcHAgcHJv YmFibHkgYXNrcyB0aGUgUVVJQyBzdGFjayBmb3IgYSBoYW5kbGUgdG8gYSBuZXcgc3RyZWFtICh0 aGVuIHF1ZXJpZXMgdG8gZGlzY292ZXIgdGhlIHN0cmVhbSBJRCksIG9yIGFza3MgdGhlIFFVSUMg c3RhY2sgZm9yIGEgaGFuZGxlIHRvIGEgcGFydGljdWxhciBzdHJlYW0gSUQuICDigJxSZXNlcnZl ZOKAnSBzZWVtcyBsaWtlIGl04oCZcyBiYXNpY2FsbHkgdGhlIHN0YWNr4oCZcyBjb3VudGVyIGZv ciB0aGUgZmlyc3QgaW5zdGFuY2Ug4oCTIGV2ZW4gaWYgY2FsbGVyICMxIGhhc27igJl0IGFjdHVh bGx5IHNlbnQgZGF0YSB5ZXQsIHlvdSBzaG91bGRu4oCZdCBoYW5kIHRoZSBzYW1lIHN0cmVhbSB0 byBjYWxsZXIgIzIgd2hlbiB0aGV5IGFzayBmb3IgYSBuZXcgc3RyZWFtLiAgSWYgdGhhdOKAmXMg cmVhbGx5IHdoYXQgaXQgd2luZHMgdXAgYmVpbmcsIHRoZW4gaXQgZG9lc27igJl0IGJlbG9uZyBp biB0aGUgZHJhZnQuICBBbm90aGVyIGFyZ3VtZW50IGluIHRoYXQgZGlyZWN0aW9uIGlzIHRoYXQg bm90aGluZyBpcyBzZW50IG9uIHRoZSB3aXJlLCBzbyB0aGUgb3RoZXIgc2lkZSBkb2VzbuKAmXQg a25vdyBpdOKAmXMgcmVzZXJ2ZWQgKGV4Y2VwdCBpZiB0aGUgYXBwIGxheWVyIGNob29zZXMgdG8g dGVsbCB0aGVtKS4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNv bV0NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiAyOjIxIFBNDQpUbzogTWlrZSBCaXNo b3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzogTWlyamEgS8O8aGxld2luZCA8 bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBDbG9zaW5nIHN0cmVhbXMNCg0KQXMgYSBoaWdoIGxldmVsIGNvbW1lbnQsIEkgdGhpbmsg dGhlIGN1cnJlbnQgUVVJQyBzdHJlYW0gc3RhdGUgbWFjaGluZSBpcyBxdWl0ZSBjb21wbGV4LCBh bmQgaXQnZCBiZSBncmVhdCB0byBzaW1wbGlmeSBpdC4gIEkgZXhwZWN0IGl0J3MgcG9zc2libGUs IGJ1dCBkb24ndCBoYXZlIGFueSBjb25jcmV0ZSBzdWdnZXN0aW9ucyBhdCB0aGUgbW9tZW50Lg0K DQoNCg0KT24gTW9uLCBEZWMgNSwgMjAxNiBhdCAyOjAxIFBNLCBJYW4gU3dldHQgPGlhbnN3ZXR0 QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3cm90ZToNCkEga2V5IHRv IG1ha2luZyBzdHJlYW1zIGxpZ2h0d2VpZ2h0IGlzIHRvIGVuc3VyZSB0aGV5J3JlIHVzZWQgaW4g b3JkZXIuICBPdGhlcndpc2UgdHJhY2tpbmcgd2hpY2ggc3RyZWFtcyBoYXZlIGJlZW4gcHJldmlv dXNseSB1c2VkIGFuZCBjbG9zZWQgY2FuIGNvbnN1bWUgYSBsYXJnZSBhbW91bnQgb2YgbWVtb3J5 LiAgU28gSSBiZWxpZXZlIHRoZSBzdHJlYW1zIGhhdmUgdG8gYmUgcmVzZXJ2ZWQgb3IgaGF2ZSBh bm90aGVyIHdheSB0byBlbnN1cmUgdGhleSdyZSB1c2VkIGluIG9yZGVyKGF0IGxlYXN0IGFwcHJv eGltYXRlbHkpLiAgT2YgY291cnNlLCBpdCdkIGJlIGVhc3kgZW5vdWdoIHRvIGltbWVkaWF0ZWx5 IHJlc2V0IHRoZSBzdHJlYW0gdG8gaW5kaWNhdGUgeW91J3JlIGp1c3Qgc2tpcHBpbmcgaXQuDQoN Ck9uIE1vbiwgRGVjIDUsIDIwMTYgYXQgMTo1MiBQTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3 cm90ZToNCiJSZXNlcnZlZCIgaXMgYSBjb25jZXB0IGRyYXduIGZyb20gSFRUUC8yIHRoYXQgaGFz IHRyaWNrbGVkIGludG8gUVVJQy4gIFdoZXRoZXIgaXQgbmVlZHMgdG8gZXhpc3QgYXQgdGhlIHRy YW5zcG9ydCBsYXllciBpcyBhIHJlYXNvbmFibGUgcXVlc3Rpb24uICBJbiBnZW5lcmFsIHRlcm1z LCAicmVzZXJ2ZWQiIG1lYW5zIHRoYXQgeW91IGtub3cgd2hhdCB0aGUgcGVlciBpcyBnb2luZyB0 byBzZW5kIHlvdSBvbiB0aGF0IHN0cmVhbSAoZnJvbSB0aGUgYXBwbGljYXRpb24gbGF5ZXIpLCBi dXQgdGhleSBoYXZlbid0IGFjdHVhbGx5IGRvbmUgc28geWV0LiAgTm93IHRoYXQgeW91IHJhaXNl IHRoZSBxdWVzdGlvbiwgSSBkb24ndCBzZWUgYSByZWFzb24gdGhhdCBjb3VsZG4ndCBiZSBhbiBh cHBsaWNhdGlvbi1sYXllciBjb25jZXB0IGFuZCBsZXQgdGhlIHRyYW5zcG9ydCBjb250aW51ZSB0 byBzZWUgdGhvc2Ugc3RyZWFtcyBhcyAiaWRsZSIgLS0gZG9lcyBhbnlvbmUgZWxzZT8NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNaXJq YSBLw7xobGV3aW5kDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDUsIDIwMTYgOTowNCBBTQ0KVG86 IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBDbG9zaW5nIHN0 cmVhbXMNCg0KQW5kIGZpbmFsbHkgKG9uZSBtb3JlIGhpISksDQoNCndoaWxlIHJlYWRpbmcgdGhl IGRyYWZ0LCBzYXlpbmcgdGhhdCB0aGUgc3RyZWFtIGhhbmRsaW5nIGlzIHJlYWxseSBsaWdodC13 YXksIEkgd2FzIGFza2luZyBteXNlbGYgaWYgd2UgcmVhbGx5IG5lZWQgdG8gY2xvc2Ugc3RyZWFt cyBhdCBhbGwgKGdpdmVuIHRoYXQgd2UgYWxzbyBqdXN0IGltcGxpY2l0bHkgb3BlbiB0aGVtKS4g V2hlbiB5b3UgbG9vayBhdCBzZWN0aW9uIDguMSAoTGlmZSBvZiBhIHN0cmVhbSkgdGhlIG92ZXJo ZWFkIG9mIGNsb3Npbmcgc3RyZWFtcyBpcyBhY3R1YWxseSBxdWl0ZSBsYXJnZSAoY291cGxlIG9m IGFkZGl0aW9uYWwgc3RhdGVzIG9ubHkgbmVlZGVkIGZvciB0aGlzKS4gKEJ0dy4gSSBhbHNvIGRv buKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgcmVz ZXJ2ZWQgYW5kIGlkbGUgc3RyZWFtIGlz4oCmIGkgZ3Vlc3MgdGhhdOKAmXMgcmF0aGVyIGFuIGlu dGVyZmFjZSBxdWVzdGlvbiB0aGFuIHN0YXRlIG1hbmFnZW1lbnQsIGFueXdheeKApikuIFRvIG15 IHVuZGVyc3RhbmRpbmcsIHlvdSBjbG9zZSBjb25uZWN0aW9uIGZvciBzdGF0ZSBtYW5hZ2VtZW50 IGF0IHRoZSByZWNlaXZlciBzaWRlLiBIb3dldmVyLCBhcyB5b3UgYW5ub3VuY2UgdGhlIG1heGlt dW0gbnVtYmVyIG9mIHN0cmVhbXMgdG8gdGhlIG90aGVyIGVuZHBvaW50IGFuZCB5b3UgY2FuIHVz ZSB0aGUgV0lORE9XX1VQREFURSB0byBzZW5kIGEgemVybyB3aW5kb3cgdG8gbWFrZSBzdXJlIG5v IGFkZGl0aW9uYWwgZGF0YSBhcmUgc2VuZCAoYW5kIHVzZSBCTE9DSyB0byByZXNldC11cCBzdGF0 ZSBvbiB0aGUgcmVjZWl2ZXIgaWYgbmVlZGVkKSwgSSB0aGluayBpdCBpcyBhIGxvY2FsIGRlY2lz aW9uIGF0IHRoZSByZWNlaXZlciB3aGljaCBzdHJlYW1zIHRvIHJlbW92ZSBzdGF0ZSBmb3IgaWYg dGhlIG1heCBudW1iZXIgb2Ygc3RyZWFtcyBpcyByZWFjaGVkLiBJIGRvbuKAmXQgcmVhbGx5IHNl ZSB0aGUgYWRkaXRpb25hbCBiZW5lZml0IHRoZSBGSU4gYml0cyBhcmUgZ2l2aW5nLiBPciBoYXMg dGhpcyBwcm92ZW4gdG8gYmUgcmVhbGx5IGhlbHBmdWwgaW4gc29tZSByZWFsLWxpZmUgc2l0dWF0 aW9uPw0KDQpNaXJqYQ0KDQoNCg== --_000_BN6PR03MB270865D294AE1AF40533E53E87830BN6PR03MB2708namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGV0aGVyIHRoZXnigJlyZSB1c2VkIGluIG9yZGVyIG9yIG5vdCwgdGhlcmUgYXJlIHNvbWUgdmVy eSBsb25nLWxpdmVkIHN0cmVhbXMgYW5kIHNvbWUgdmVyeSBzaG9ydC1saXZlZCBvbmVzLCBhcyBJ 4oCZbSBzdXJlIHlvdeKAmXZlIHNlZW4uJm5ic3A7IE9uZSBvZiB0aGUgZHJhd2JhY2tzIHRvIHRo ZSB0d28tc3RyZWFtLXBlci1yZXF1ZXN0IG1hcHBpbmcgaW4gSFRUUCwgaW4gZmFjdCwgaXMgaG93 IHRoYXQgbWFwcyB0byBwcmlvcml0aXphdGlvbg0KIHNjaGVtZXMgdGhhdCB1c2Ug4oCcem9tYmll 4oCdIHN0cmVhbXMgYXMgcGxhY2Vob2xkZXJzIGZvciBjZXJ0YWluIGNhdGVnb3JpZXMgb2YgcmVz b3VyY2UuJm5ic3A7IEluIHRoZSBjdXJyZW50IHB1bGwgcmVxdWVzdCwgaWYgeW91IGNsb3NlIHRo ZSBRVUlDIHN0cmVhbSwgeW91IGxvc2UgdGhlIGFiaWxpdHkgdG8gcmVwcmlvcml0aXplIGl0IGxh dGVyLiZuYnNwOyAoT25lIHNvbHV0aW9uIGluIHRoZSBIVFRQIG1hcHBpbmcgaXMgdG8gbW92ZSBQ UklPUklUWSB0byBiZSBhDQogc2Vzc2lvbi1sZXZlbCBmcmFtZSBiYWNrIG9uIHN0cmVhbSAzLCBh bmQgaW5jbHVkZXMgYm90aCB0aGUgcHJpb3JpdGl6ZWQgYW5kIGRlcGVuZGVudCBzdHJlYW0gSURz LikmbmJzcDsgRXZlbiBzbywgeW914oCZbGwgaGF2ZSBzdHJlYW1zIDEgYW5kIDMgbGl2aW5nIGZv cmV2ZXIuJm5ic3A7IEl0IHNlZW1zIGxpa2UgZm9yIHN0YXRlIG1hbmFnZW1lbnQsIHlvdSBuZWVk IHRvIGJlIGFibGUgdG8gdHJhY2sgY29udGlndW91cyByZWdpb25zIGluIHRoZSBzYW1lIHN0YXRl LA0KIGFuZCB5b3Ugd2FudCB0aG9zZSByZWdpb25zIHRvIGJlIGxhcmdlIHNvIHlvdSBoYXZlIGFz IGZldyBkaXN0aW5jdCByZWNvcmRzIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiB0ZXJtcyBvZiDigJxyZXNlcnZlZCzigJ0gdGhhdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGVh c2lseSBiZSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuJm5ic3A7IEFzIEkgZW52aXNpb24gdGhl IEFQSSwgYXQgbGVhc3QsIChoYXZlbuKAmXQgbG9va2VkIGF0IHlvdXJzKSwgdGhlIGFwcCBwcm9i YWJseSBhc2tzIHRoZSBRVUlDIHN0YWNrIGZvciBhIGhhbmRsZSB0byBhIG5ldyBzdHJlYW0gKHRo ZW4gcXVlcmllcyB0byBkaXNjb3Zlcg0KIHRoZSBzdHJlYW0gSUQpLCBvciBhc2tzIHRoZSBRVUlD IHN0YWNrIGZvciBhIGhhbmRsZSB0byBhIHBhcnRpY3VsYXIgc3RyZWFtIElELiZuYnNwOyDigJxS ZXNlcnZlZOKAnSBzZWVtcyBsaWtlIGl04oCZcyBiYXNpY2FsbHkgdGhlIHN0YWNr4oCZcyBjb3Vu dGVyIGZvciB0aGUgZmlyc3QgaW5zdGFuY2Ug4oCTIGV2ZW4gaWYgY2FsbGVyICMxIGhhc27igJl0 IGFjdHVhbGx5IHNlbnQgZGF0YSB5ZXQsIHlvdSBzaG91bGRu4oCZdCBoYW5kIHRoZSBzYW1lIHN0 cmVhbSB0byBjYWxsZXINCiAjMiB3aGVuIHRoZXkgYXNrIGZvciBhIG5ldyBzdHJlYW0uJm5ic3A7 IElmIHRoYXTigJlzIHJlYWxseSB3aGF0IGl0IHdpbmRzIHVwIGJlaW5nLCB0aGVuIGl0IGRvZXNu 4oCZdCBiZWxvbmcgaW4gdGhlIGRyYWZ0LiZuYnNwOyBBbm90aGVyIGFyZ3VtZW50IGluIHRoYXQg ZGlyZWN0aW9uIGlzIHRoYXQgbm90aGluZyBpcyBzZW50IG9uIHRoZSB3aXJlLCBzbyB0aGUgb3Ro ZXIgc2lkZSBkb2VzbuKAmXQga25vdyBpdOKAmXMgcmVzZXJ2ZWQgKGV4Y2VwdCBpZiB0aGUgYXBw IGxheWVyDQogY2hvb3NlcyB0byB0ZWxsIHRoZW0pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0gPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiAyOjIxIFBNPGJyPg0KPGI+VG86 PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IE1pcmphIEvDvGhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2gmZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBDbG9z aW5nIHN0cmVhbXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGEgaGlnaCBsZXZl bCBjb21tZW50LCBJIHRoaW5rIHRoZSBjdXJyZW50IFFVSUMgc3RyZWFtIHN0YXRlIG1hY2hpbmUg aXMgcXVpdGUgY29tcGxleCwgYW5kIGl0J2QgYmUgZ3JlYXQgdG8gc2ltcGxpZnkgaXQuJm5ic3A7 IEkgZXhwZWN0IGl0J3MgcG9zc2libGUsIGJ1dCBkb24ndCBoYXZlIGFueSBjb25jcmV0ZSBzdWdn ZXN0aW9ucyBhdCB0aGUgbW9tZW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDUsIDIwMTYgYXQgMjowMSBQTSwgSWFuIFN3ZXR0 ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBrZXkgdG8gbWFraW5nIHN0cmVh bXMgbGlnaHR3ZWlnaHQgaXMgdG8gZW5zdXJlIHRoZXkncmUgdXNlZCBpbiBvcmRlci4mbmJzcDsg T3RoZXJ3aXNlIHRyYWNraW5nIHdoaWNoIHN0cmVhbXMgaGF2ZSBiZWVuIHByZXZpb3VzbHkgdXNl ZCBhbmQgY2xvc2VkIGNhbiBjb25zdW1lIGEgbGFyZ2UgYW1vdW50IG9mIG1lbW9yeS4mbmJzcDsg U28gSSBiZWxpZXZlIHRoZSBzdHJlYW1zIGhhdmUgdG8gYmUgcmVzZXJ2ZWQgb3IgaGF2ZSBhbm90 aGVyDQogd2F5IHRvIGVuc3VyZSB0aGV5J3JlIHVzZWQgaW4gb3JkZXIoYXQgbGVhc3QgYXBwcm94 aW1hdGVseSkuJm5ic3A7IE9mIGNvdXJzZSwgaXQnZCBiZSBlYXN5IGVub3VnaCB0byBpbW1lZGlh dGVseSByZXNldCB0aGUgc3RyZWFtIHRvIGluZGljYXRlIHlvdSdyZSBqdXN0IHNraXBwaW5nIGl0 LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgNSwgMjAxNiBhdCAxOjUyIFBNLCBNaWtlIEJpc2hvcCAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7UmVzZXJ2 ZWQmcXVvdDsgaXMgYSBjb25jZXB0IGRyYXduIGZyb20gSFRUUC8yIHRoYXQgaGFzIHRyaWNrbGVk IGludG8gUVVJQy4mbmJzcDsgV2hldGhlciBpdCBuZWVkcyB0byBleGlzdCBhdCB0aGUgdHJhbnNw b3J0IGxheWVyIGlzIGEgcmVhc29uYWJsZSBxdWVzdGlvbi4mbmJzcDsgSW4gZ2VuZXJhbCB0ZXJt cywgJnF1b3Q7cmVzZXJ2ZWQmcXVvdDsgbWVhbnMgdGhhdCB5b3Uga25vdyB3aGF0IHRoZSBwZWVy IGlzIGdvaW5nIHRvIHNlbmQgeW91IG9uIHRoYXQNCiBzdHJlYW0gKGZyb20gdGhlIGFwcGxpY2F0 aW9uIGxheWVyKSwgYnV0IHRoZXkgaGF2ZW4ndCBhY3R1YWxseSBkb25lIHNvIHlldC4mbmJzcDsg Tm93IHRoYXQgeW91IHJhaXNlIHRoZSBxdWVzdGlvbiwgSSBkb24ndCBzZWUgYSByZWFzb24gdGhh dCBjb3VsZG4ndCBiZSBhbiBhcHBsaWNhdGlvbi1sYXllciBjb25jZXB0IGFuZCBsZXQgdGhlIHRy YW5zcG9ydCBjb250aW51ZSB0byBzZWUgdGhvc2Ugc3RyZWFtcyBhcyAmcXVvdDtpZGxlJnF1b3Q7 IC0tIGRvZXMgYW55b25lIGVsc2U/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWly amEgS8O8aGxld2luZDxicj4NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiA5OjA0IEFN PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cXVpY0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBDbG9zaW5nIHN0cmVhbXM8YnI+DQo8YnI+ DQpBbmQgZmluYWxseSAob25lIG1vcmUgaGkhKSw8YnI+DQo8YnI+DQp3aGlsZSByZWFkaW5nIHRo ZSBkcmFmdCwgc2F5aW5nIHRoYXQgdGhlIHN0cmVhbSBoYW5kbGluZyBpcyByZWFsbHkgbGlnaHQt d2F5LCBJIHdhcyBhc2tpbmcgbXlzZWxmIGlmIHdlIHJlYWxseSBuZWVkIHRvIGNsb3NlIHN0cmVh bXMgYXQgYWxsIChnaXZlbiB0aGF0IHdlIGFsc28ganVzdCBpbXBsaWNpdGx5IG9wZW4gdGhlbSku IFdoZW4geW91IGxvb2sgYXQgc2VjdGlvbiA4LjEgKExpZmUgb2YgYSBzdHJlYW0pIHRoZSBvdmVy aGVhZCBvZiBjbG9zaW5nDQogc3RyZWFtcyBpcyBhY3R1YWxseSBxdWl0ZSBsYXJnZSAoY291cGxl IG9mIGFkZGl0aW9uYWwgc3RhdGVzIG9ubHkgbmVlZGVkIGZvciB0aGlzKS4gKEJ0dy4gSSBhbHNv IGRvbuKAmXQgcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGEg cmVzZXJ2ZWQgYW5kIGlkbGUgc3RyZWFtIGlz4oCmIGkgZ3Vlc3MgdGhhdOKAmXMgcmF0aGVyIGFu IGludGVyZmFjZSBxdWVzdGlvbiB0aGFuIHN0YXRlIG1hbmFnZW1lbnQsIGFueXdheeKApikuDQog VG8gbXkgdW5kZXJzdGFuZGluZywgeW91IGNsb3NlIGNvbm5lY3Rpb24gZm9yIHN0YXRlIG1hbmFn ZW1lbnQgYXQgdGhlIHJlY2VpdmVyIHNpZGUuIEhvd2V2ZXIsIGFzIHlvdSBhbm5vdW5jZSB0aGUg bWF4aW11bSBudW1iZXIgb2Ygc3RyZWFtcyB0byB0aGUgb3RoZXIgZW5kcG9pbnQgYW5kIHlvdSBj YW4gdXNlIHRoZSBXSU5ET1dfVVBEQVRFIHRvIHNlbmQgYSB6ZXJvIHdpbmRvdyB0byBtYWtlIHN1 cmUgbm8gYWRkaXRpb25hbCBkYXRhIGFyZSBzZW5kDQogKGFuZCB1c2UgQkxPQ0sgdG8gcmVzZXQt dXAgc3RhdGUgb24gdGhlIHJlY2VpdmVyIGlmIG5lZWRlZCksIEkgdGhpbmsgaXQgaXMgYSBsb2Nh bCBkZWNpc2lvbiBhdCB0aGUgcmVjZWl2ZXIgd2hpY2ggc3RyZWFtcyB0byByZW1vdmUgc3RhdGUg Zm9yIGlmIHRoZSBtYXggbnVtYmVyIG9mIHN0cmVhbXMgaXMgcmVhY2hlZC4gSSBkb27igJl0IHJl YWxseSBzZWUgdGhlIGFkZGl0aW9uYWwgYmVuZWZpdCB0aGUgRklOIGJpdHMgYXJlIGdpdmluZy4g T3IgaGFzDQogdGhpcyBwcm92ZW4gdG8gYmUgcmVhbGx5IGhlbHBmdWwgaW4gc29tZSByZWFsLWxp ZmUgc2l0dWF0aW9uPzxicj4NCjxicj4NCk1pcmphPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB270865D294AE1AF40533E53E87830BN6PR03MB2708namp_-- From nobody Mon Dec 5 15:27:46 2016 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 BAE3912960A for ; Mon, 5 Dec 2016 15:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 rAN6Q33B9Oy1 for ; Mon, 5 Dec 2016 15:27:42 -0800 (PST) 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 0656112961A for ; Mon, 5 Dec 2016 15:27:42 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id r204so262953554ywb.0 for ; Mon, 05 Dec 2016 15:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3fKwT6YdajSUujejp6fw6ytLS8Do35SeczHUqwobWsA=; b=pRlf8vKKSoJF6jwtJ7kFuFqcGTjmaKw2Tcsa8ov/DS5gK+VAaOynf1CK4aRP2MVgM9 O23Z6BDnGoFIDgVR7Z9cBhQRuULPDAxe4aENgThY84nlnZhOQ8ddLI1cDdfikAv2CWHR EYDwbVUbzjovWb2TiEdcWyLMKkEgBfKHKdTcovudYTUGDLs3LdbYwoCTI2cqX2ANVtwU SUOO1OPUTYWkLe2R9INswyVebhKR0+XE86qDB/vtbLUHSByvhDCZWyU1ZKvUlWfBa2LM 8qzIaKSwQyWJ9Ps/1EUkDAl5VSozhj4JAKH8/hmFVMrWDvIGlCcQB3aL40Xvmeu9pU3h 185w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3fKwT6YdajSUujejp6fw6ytLS8Do35SeczHUqwobWsA=; b=S0SgAxaK+I8ckgQIH6+id70yoBk+cExEfOSAs0E2Zlyn6HhJYAb56rEKql9VdKPhp/ jaQsq2aoiDfGyLwUt8lfQmecSywBBuDTjpO4V7RmWyyJbBgjZijyhd7fWnKmCd+1SfTV SmdU/mn87hilUDCxv7Z0VUF40v/ArrLTAjl+rwcUs0PLZlLMD60dzIcKTqis/42hGxap /I5KBFJ0HrXzTTXRhBMFACjVszzh3gZV0I4ui+TGx8P6cxoE9GNGLxzbUJyFPVgHp7or vnUDJ7F6rkgKKAywwRKVISMKSWjK/ncgCLej20aJumzQ27KtqfCjqJLnksZj+0vIq8NF zCgA== X-Gm-Message-State: AKaTC01I/8ipiQ6JThMAxU8x8/2BBsMSIBcbH/n5P//UUBxP8NbUNkEytVc9EQQdaygEglSDfURdHqXiEiAWc2YX X-Received: by 10.13.199.135 with SMTP id j129mr55838120ywd.12.1480980461141; Mon, 05 Dec 2016 15:27:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Mon, 5 Dec 2016 15:27:20 -0800 (PST) In-Reply-To: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> From: Ian Swett Date: Mon, 5 Dec 2016 18:27:20 -0500 Message-ID: Subject: Re: Closing streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a114e5ea04e859f0542f1a21d Archived-At: Cc: "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Dec 2016 23:27:45 -0000 --001a114e5ea04e859f0542f1a21d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A few long lived streams are fine, even if they're completely discontiguous. It's very simple to track open and closed stream with an "everything under this max stream value is closed, unless it's contained in this map" approach. If streams aren't used or reserved in order, then one would have to store every stream ever used, open or closed, which could consume a large amount of memory and is not friendly to long-running connections. The current QUIC draft does not allow streams to be re-opened once their closed. I suppose an alternative is to allow streams to be closed and re-opened later, but that brings in new challenges like the creator of the stream having to ensure all data and the fin, or the reset, are acked before re-using a stream. A buggy implementation could easily cause data corruption. It On Mon, Dec 5, 2016 at 5:42 PM, Mike Bishop wrote: > Whether they=E2=80=99re used in order or not, there are some very long-li= ved > streams and some very short-lived ones, as I=E2=80=99m sure you=E2=80=99v= e seen. One of > the drawbacks to the two-stream-per-request mapping in HTTP, in fact, is > how that maps to prioritization schemes that use =E2=80=9Czombie=E2=80=9D= streams as > placeholders for certain categories of resource. In the current pull > request, if you close the QUIC stream, you lose the ability to reprioriti= ze > it later. (One solution in the HTTP mapping is to move PRIORITY to be a > session-level frame back on stream 3, and includes both the prioritized a= nd > dependent stream IDs.) Even so, you=E2=80=99ll have streams 1 and 3 livi= ng > forever. It seems like for state management, you need to be able to trac= k > contiguous regions in the same state, and you want those regions to be > large so you have as few distinct records as possible. > > > > In terms of =E2=80=9Creserved,=E2=80=9D that seems like it could easily b= e an > implementation detail. As I envision the API, at least, (haven=E2=80=99t= looked at > yours), the app probably asks the QUIC stack for a handle to a new stream > (then queries to discover the stream ID), or asks the QUIC stack for a > handle to a particular stream ID. =E2=80=9CReserved=E2=80=9D seems like = it=E2=80=99s basically the > stack=E2=80=99s counter for the first instance =E2=80=93 even if caller #= 1 hasn=E2=80=99t actually > sent data yet, you shouldn=E2=80=99t hand the same stream to caller #2 wh= en they > ask for a new stream. If that=E2=80=99s really what it winds up being, t= hen it > doesn=E2=80=99t belong in the draft. Another argument in that direction = is that > nothing is sent on the wire, so the other side doesn=E2=80=99t know it=E2= =80=99s reserved > (except if the app layer chooses to tell them). > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Monday, December 5, 2016 2:21 PM > *To:* Mike Bishop > *Cc:* Mirja K=C3=BChlewind ; quic@ietf.o= rg > *Subject:* Re: Closing streams > > > > As a high level comment, I think the current QUIC stream state machine is > quite complex, and it'd be great to simplify it. I expect it's possible, > but don't have any concrete suggestions at the moment. > > > > > > > > On Mon, Dec 5, 2016 at 2:01 PM, Ian Swett wrote: > > A key to making streams lightweight is to ensure they're used in order. > Otherwise tracking which streams have been previously used and closed can > consume a large amount of memory. So I believe the streams have to be > reserved or have another way to ensure they're used in order(at least > approximately). Of course, it'd be easy enough to immediately reset the > stream to indicate you're just skipping it. > > > > On Mon, Dec 5, 2016 at 1:52 PM, Mike Bishop > wrote: > > "Reserved" is a concept drawn from HTTP/2 that has trickled into QUIC. > Whether it needs to exist at the transport layer is a reasonable question= . > In general terms, "reserved" means that you know what the peer is going t= o > send you on that stream (from the application layer), but they haven't > actually done so yet. Now that you raise the question, I don't see a > reason that couldn't be an application-layer concept and let the transpor= t > continue to see those streams as "idle" -- does anyone else? > > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewi= nd > Sent: Monday, December 5, 2016 9:04 AM > To: quic@ietf.org > Subject: Closing streams > > And finally (one more hi!), > > while reading the draft, saying that the stream handling is really > light-way, I was asking myself if we really need to close streams at all > (given that we also just implicitly open them). When you look at section > 8.1 (Life of a stream) the overhead of closing streams is actually quite > large (couple of additional states only needed for this). (Btw. I also > don=E2=80=99t really understand what the difference between a reserved an= d idle > stream is=E2=80=A6 i guess that=E2=80=99s rather an interface question th= an state > management, anyway=E2=80=A6). To my understanding, you close connection f= or state > management at the receiver side. However, as you announce the maximum > number of streams to the other endpoint and you can use the WINDOW_UPDATE > to send a zero window to make sure no additional data are send (and use > BLOCK to reset-up state on the receiver if needed), I think it is a local > decision at the receiver which streams to remove state for if the max > number of streams is reached. I don=E2=80=99t really see the additional b= enefit the > FIN bits are giving. Or has this proven to be really helpful in some > real-life situation? > > Mirja > > > > > --001a114e5ea04e859f0542f1a21d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few long lived streams are fine, even if they're com= pletely discontiguous.=C2=A0 It's very simple to track open and closed = stream with an "everything under this max stream value is closed, unle= ss it's contained in this map" approach.=C2=A0 If streams aren'= ;t used or reserved in order, then one would have to store every stream eve= r used, open or closed, which could consume a large amount of memory and is= not friendly to long-running connections.

The current Q= UIC draft does not allow streams to be re-opened once their closed.=C2=A0 I= suppose an alternative is to allow streams to be closed and re-opened late= r, but that brings in new challenges like the creator of the stream having = to ensure all data and the fin, or the reset, are acked before re-using a s= tream.=C2=A0 A buggy implementation could easily cause data corruption.

It=C2=A0

On Mon, Dec 5, 2016 at 5:42 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Whether they=E2=80=99re used in order or not, there = are some very long-lived streams and some very short-lived ones, as I=E2=80= =99m sure you=E2=80=99ve seen.=C2=A0 One of the drawbacks to the two-stream= -per-request mapping in HTTP, in fact, is how that maps to prioritization schemes that use =E2=80=9Czombie=E2=80=9D streams as placeholders for cert= ain categories of resource.=C2=A0 In the current pull request, if you close= the QUIC stream, you lose the ability to reprioritize it later.=C2=A0 (One= solution in the HTTP mapping is to move PRIORITY to be a session-level frame back on stream 3, and includes both the prioritized an= d dependent stream IDs.)=C2=A0 Even so, you=E2=80=99ll have streams 1 and 3= living forever.=C2=A0 It seems like for state management, you need to be a= ble to track contiguous regions in the same state, and you want those regions to be large so you have as few distinct records= as possible.

=C2=A0

In terms of =E2=80=9Creserved,=E2=80=9D that seems l= ike it could easily be an implementation detail.=C2=A0 As I envision the AP= I, at least, (haven=E2=80=99t looked at yours), the app probably asks the Q= UIC stack for a handle to a new stream (then queries to discover the stream ID), or asks the QUIC stack for a handle to a particular stream= ID.=C2=A0 =E2=80=9CReserved=E2=80=9D seems like it=E2=80=99s basically the= stack=E2=80=99s counter for the first instance =E2=80=93 even if caller #1= hasn=E2=80=99t actually sent data yet, you shouldn=E2=80=99t hand the same= stream to caller #2 when they ask for a new stream.=C2=A0 If that=E2=80=99s really what it = winds up being, then it doesn=E2=80=99t belong in the draft.=C2=A0 Another = argument in that direction is that nothing is sent on the wire, so the othe= r side doesn=E2=80=99t know it=E2=80=99s reserved (except if the app layer chooses to tell them).

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Monday, December 5, 2016 2:21 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>;= quic@ietf.org
Subject: Re: Closing streams

=C2=A0

As a high level comment, I think the current QUIC st= ream state machine is quite complex, and it'd be great to simplify it.= =C2=A0 I expect it's possible, but don't have any concrete suggesti= ons at the moment.

=C2=A0

=C2=A0

=C2=A0

On Mon, Dec 5, 2016 at 2:01 PM, Ian Swett <ianswett@google.com&= gt; wrote:

A key to making streams lightweight is to ensure the= y're used in order.=C2=A0 Otherwise tracking which streams have been pr= eviously used and closed can consume a large amount of memory.=C2=A0 So I b= elieve the streams have to be reserved or have another way to ensure they're used in order(at least approximately).=C2=A0 Of = course, it'd be easy enough to immediately reset the stream to indicate= you're just skipping it. =C2=A0

=C2=A0

On Mon, Dec 5, 2016 at 1:52 PM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

"Reserved" is a concept drawn from HTTP/2 = that has trickled into QUIC.=C2=A0 Whether it needs to exist at the transpo= rt layer is a reasonable question.=C2=A0 In general terms, "reserved&q= uot; means that you know what the peer is going to send you on that stream (from the application layer), but they haven't actually done so= yet.=C2=A0 Now that you raise the question, I don't see a reason that = couldn't be an application-layer concept and let the transport continue= to see those streams as "idle" -- does anyone else?


-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewind
Sent: Monday, December 5, 2016 9:04 AM
To: quic@ietf.org Subject: Closing streams

And finally (one more hi!),

while reading the draft, saying that the stream handling is really light-wa= y, I was asking myself if we really need to close streams at all (given tha= t we also just implicitly open them). When you look at section 8.1 (Life of= a stream) the overhead of closing streams is actually quite large (couple of additional states only needed f= or this). (Btw. I also don=E2=80=99t really understand what the difference = between a reserved and idle stream is=E2=80=A6 i guess that=E2=80=99s rathe= r an interface question than state management, anyway=E2=80=A6). To my understanding, you close connection for state management at the rece= iver side. However, as you announce the maximum number of streams to the ot= her endpoint and you can use the WINDOW_UPDATE to send a zero window to mak= e sure no additional data are send (and use BLOCK to reset-up state on the receiver if needed), I think it is= a local decision at the receiver which streams to remove state for if the = max number of streams is reached. I don=E2=80=99t really see the additional= benefit the FIN bits are giving. Or has this proven to be really helpful in some real-life situation?

Mirja

=C2=A0

=C2=A0


--001a114e5ea04e859f0542f1a21d-- From nobody Tue Dec 6 13:43:27 2016 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 2499E129CA6 for ; Tue, 6 Dec 2016 13:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 hg01-B4JL381 for ; Tue, 6 Dec 2016 13:43:23 -0800 (PST) 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 6AAEF1294F7 for ; Tue, 6 Dec 2016 13:43:23 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id p16so359170506qta.0 for ; Tue, 06 Dec 2016 13:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I0O2iHCEYgHhGp1DvXnVB1ed+L7i6/Ez0Ddu3+bywKc=; b=Qe1b/k4CEQPuSXeU/5uIWECpIBYkVIQEngcUjuMlnqp4SMoBS5D7K2mDCYRa1jjFOA tvMGRsvCj7+QfWoDsW3jGA2riRp+MwwIQv1zGQxkJU31KMX37C7CIE05Inr/xJCSz/1d 1Cg+hlek5gYTACcAsmbfx799YWltuN8x4Q4X+sBf8Z0gvmV7IVbxfJXik8v3onmEP4Xy 1MZCDkHgbczmGxVB7bJEykGz6inDPwvRVVaPHpcdHl9a/IkemIjc5aZCFXsCpOq4Lxxi E0JZPSJIEa/n3oPnReSpse4REumAMgaKOB4fppsHizvbdevVsXb6riFBBT8zMXcc4+oS hcbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I0O2iHCEYgHhGp1DvXnVB1ed+L7i6/Ez0Ddu3+bywKc=; b=QoO/HDY1542ZVweQry8FwXUW7zidhnwjB43lmqE3P8aOKjO4mBJbx0Wz7SA8QY1hil mDZytgIXYoLSq6tX5qP3PVbS4JTA7csBwNnva0O95ml8rvL1DNR2BIAkWbO7T8AlURgG 1std4wJhIzBJusHphfMMh7o9hfhtsH9es0zqvhC+pSGVptjQB66bm4T0+aeHZ8VMkg6D S8co68dhZTVeqXOIrTbIk1TpU3EEe/CSs5OdrczTssch/fQZb4vmVIJqXRYVRxOjsp9N g57ghueSGgm6I3gEeoHUTpJ61tXHMmJH4yFf7dx9YEE4HudZ69RXjU16+oeQPBi/MZC9 ZQmw== X-Gm-Message-State: AKaTC00yW6ZCrUOi9S8PQPwrts0yzfMDLWM7jXjSO5y8wKx15yhHY08iLvM5mFk4ab/OrVtbPn2tBhF4A93xPw== X-Received: by 10.200.46.249 with SMTP id i54mr57213340qta.13.1481060602532; Tue, 06 Dec 2016 13:43:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 6 Dec 2016 13:43:21 -0800 (PST) In-Reply-To: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> From: Martin Thomson Date: Wed, 7 Dec 2016 06:43:21 +0900 Message-ID: Subject: Re: Closing streams To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Dec 2016 21:43:25 -0000 On 6 December 2016 at 07:21, Ian Swett wrote: > As a high level comment, I think the current QUIC stream state machine is > quite complex, and it'd be great to simplify it. I expect it's possible, > but don't have any concrete suggestions at the moment. One way to do this is to completely detach streams in both directions. Then have response streams explicitly identify the request that they are responding to. Possibly at the usage layer. I think that avoids much of the complexity associated with reservations, but it likely adds new and interesting twists to consider. One twist that I'm particularly concerned about is congruence with h2. But then Mike's proposals have already taken us away from that; maybe that can be repaired in time, but we should be aware of the cost of divergence. To be explicit, we've opened several new fronts just by taking this work on; reworking the request-response stream mapping opens another. From nobody Tue Dec 6 15:04:26 2016 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 3810B1295A3 for ; Tue, 6 Dec 2016 15:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 YZ1heDJ5qlIf for ; Tue, 6 Dec 2016 15:04:22 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 35EA71295D8 for ; Tue, 6 Dec 2016 15:04:22 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 20so398001723uak.0 for ; Tue, 06 Dec 2016 15:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SaNrUZmwzqKP9Y02tfMf/TB1Puwy8qFSfpezkTKo7/Y=; b=mQZerGzfljv0HdMZsIvfJI5Cy7bGr2FvVSVM6Tfeg5x43Tjbofb16wncmrHtSsa2xC EvttM/b0ADNWxRS6+LKq7zoiqCou1PY1WEv+fAp7xnEpLCSouL/zwWSrauyhpEUvk5JR iku9nt8vTGdrRfp0qnHtgi1cOjW7M0U0HtjI2WRFTHEX1QhAXyn2R2ZApTEQesfrD66B xqcomj9OGwwGkfj3kuiDeuTr25M0r749pB5cQI4Kb0smfQmGUtqdP6+7FoKwCTWDkLEa NkWff7tDIVOL6ktRThvrvTKyikphMeJyZfc/Yf9/L7UVYu25FjIisXn5lEmqixKySs2N vktw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SaNrUZmwzqKP9Y02tfMf/TB1Puwy8qFSfpezkTKo7/Y=; b=EbrvKISJIMulM4mgdixphCcqQKYfL00XBTe3jFp6BoqcEg8+nvvbfLu1ONlVGUDp10 B9ULGMD2aQCf2PYcMM2p01HmH4abG6Ysetjw5nzgC2t4Nl4xTFCE2lewLlYIZeQt2gKn AsUk6WOMb6nDshwoBvbLFcWYaOaw8COKwvvnMJNHQcHU+/1fdi+HkeLX4iCJNrELDZYy HQhFED276j9fvFoX+FU6sssEa/LYf6o8V8e7LhKUerKV49Q2mF28zWRJvP6tcUUzJLOg fbuUKPpVVWkd1sp5fEYWhMgZAO5Ak2905ok2Q3Lj6rJAmGqQeUjiYnyavdkmfhC5rQ0H CyIQ== X-Gm-Message-State: AKaTC03c8Kp5MeC7/ok1DN/6izYBL6kCb2ievoGxFtJ2hihb6FpXCstdVP+DrdTPOik714AwlcifyGBiIzBym2JM X-Received: by 10.159.48.222 with SMTP id k30mr51670129uab.2.1481065461181; Tue, 06 Dec 2016 15:04:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 6 Dec 2016 15:04:20 -0800 (PST) In-Reply-To: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> From: Jana Iyengar Date: Tue, 6 Dec 2016 15:04:20 -0800 Message-ID: Subject: Re: Closing streams To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045dd8f0b432c70543056c32 Archived-At: Cc: Mike Bishop , Ian Swett , "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Dec 2016 23:04:24 -0000 --f403045dd8f0b432c70543056c32 Content-Type: text/plain; charset=UTF-8 Catching up -- just a couple of thoughts. Reserving streams did come from RFC 7540 and is meant for PUSH streams primarily. As Ian notes, one of the ways of keeping stream-handling light-weight is by using in-order stream creation. We didn't need to distinguish between local and remote "reserved" states, as is done in RFC 7540, because there's no notion of PUSH in QUIC. This means PUSH messages are sent at the HTTP level, which then turns into the HTTP layer reserving streams at the QUIC layer through the reserve_stream primitive. The Reserved state is only useful at the side that creates a stream, for enforcement of "Streams MUST be created or reserved in sequential order" (Sec 8.2). Incoming streams are allowed to be created in arbitrary order, to allow for network reordering of incoming stream frames, and so, a PUSHed stream does not need to be reserved at the receiver. The state machine is basically about as complex as the HTTP/2 stream state machine... I'm not too concerned about it. Mike's proposal does not take us away from the congruence by much... the 2-stream mapping approach basically means that every HTTP/2 stream becomes 2 QUIC streams. If you were to PUSH an HTTP/2 stream, this would move the HTTP/2 stream into the "reserve (local)" state, and the HTTP layer would then cause the 2 corresponding QUIC streams to go into the "reserved" state (I would expect this mapping to be static -- something like HTTP/2 stream ID x 2 and HTTP/2 stream ID x 2 + 1.) On Tue, Dec 6, 2016 at 1:43 PM, Martin Thomson wrote: > On 6 December 2016 at 07:21, Ian Swett wrote: > > As a high level comment, I think the current QUIC stream state machine is > > quite complex, and it'd be great to simplify it. I expect it's possible, > > but don't have any concrete suggestions at the moment. > > > One way to do this is to completely detach streams in both directions. > Then have response streams explicitly identify the request that they > are responding to. Possibly at the usage layer. I think that avoids > much of the complexity associated with reservations, but it likely > adds new and interesting twists to consider. > > One twist that I'm particularly concerned about is congruence with h2. > But then Mike's proposals have already taken us away from that; maybe > that can be repaired in time, but we should be aware of the cost of > divergence. To be explicit, we've opened several new fronts just by > taking this work on; reworking the request-response stream mapping > opens another. > > --f403045dd8f0b432c70543056c32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Catching up -- just a couple of thoughts.=C2=A0

Reserving streams did come from RFC 7540 and is meant for PUSH str= eams primarily. As Ian notes, one of the ways of keeping stream-handling li= ght-weight is by using in-order stream creation. We didn't need to dist= inguish between local and remote "reserved" states, as is done in= RFC 7540, because there's no notion of PUSH in QUIC. This means PUSH m= essages are sent at the HTTP level, which then turns into the HTTP layer re= serving streams at the QUIC layer through the reserve_stream primitive. The= Reserved state is only useful at the side that creates a stream, for enfor= cement of "Streams MUST be created or reserved in sequential order&quo= t; (Sec 8.2). Incoming streams are allowed to be created in arbitrary order= , to allow for network reordering of incoming stream frames, and so, a PUSH= ed stream does not need to be reserved at the receiver.=C2=A0
The state machine is basically about as complex as the HTTP/2 s= tream state machine... I'm not too concerned about it. Mike's propo= sal does not take us away from the congruence by much... the 2-stream mappi= ng approach basically means that every HTTP/2 stream becomes 2 QUIC streams= . If you were to PUSH an HTTP/2 stream, this would move the HTTP/2 stream i= nto the "reserve (local)" state, and the HTTP layer would then ca= use the 2 corresponding QUIC streams to go into the "reserved" st= ate (I would expect this mapping to be static -- something like HTTP/2 stre= am ID x 2 and HTTP/2 stream ID =C2=A0x 2 + 1.)


On Tue, = Dec 6, 2016 at 1:43 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 6= December 2016 at 07:21, Ian Swett <ianswett@google.com> wrote:
> As a high level comment, I think the current QUIC stream state machine= is
> quite complex, and it'd be great to simplify it.=C2=A0 I expect it= 's possible,
> but don't have any concrete suggestions at the moment.


One way to do this is to completely detach streams in both direction= s.
Then have response streams explicitly identify the request that they
are responding to.=C2=A0 Possibly at the usage layer.=C2=A0 I think that av= oids
much of the complexity associated with reservations, but it likely
adds new and interesting twists to consider.

One twist that I'm particularly concerned about is congruence with h2.<= br> But then Mike's proposals have already taken us away from that; maybe that can be repaired in time, but we should be aware of the cost of
divergence.=C2=A0 To be explicit, we've opened several new fronts just = by
taking this work on; reworking the request-response stream mapping
opens another.


--f403045dd8f0b432c70543056c32-- From nobody Tue Dec 6 15:07:03 2016 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 6A0CF1295C9 for ; Tue, 6 Dec 2016 15:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 hwUWKTzfY6A1 for ; Tue, 6 Dec 2016 15:07:00 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 740921295BD for ; Tue, 6 Dec 2016 15:07:00 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cEOp8-0004P2-Il for quic@ietf.org; Wed, 07 Dec 2016 00:06:59 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cEOp6-0005Bq-WB for quic@ietf.org; Tue, 06 Dec 2016 18:06:57 -0500 Received: (qmail 22836 invoked from network); 6 Dec 2016 23:06:55 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.108]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Dec 2016 23:06:55 -0000 From: "Christian Huitema" To: "'Ian Swett'" , "'Mike Bishop'" References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> In-Reply-To: Date: Tue, 6 Dec 2016 15:06:53 -0800 Message-ID: <040a01d25015$700c3830$5024a890$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEwxArnUhGs6Bh9N7fd44FypWF5NAHrbzktAiH9Fs4CW2DwHKILWiqA Content-Language: en-us Subject: RE: Closing streams X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD68C TZtuqlOnjCG4AjFvaYjUxKSNi2BPIptTfoC3gyVXdcmtTcWSOKD5RASVzg27iqvOPVJ3SnRg7eM0 KERedRd5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRkRsUGQMRvuH9VwFTc0JdsoMQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCj/wETjrysRdTQFgEXAljBCLeNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxMwo0ageKMXcNstrfyg5gXa7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRZKVzLoodJpOhZOhElZeeZ68HN1XtUyhw3DgxLaLBwUGYIHhtpcaYbh91FuaKgJHE3L es7Q3TWr9wD5RALyObfQMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.38) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: quic@ietf.org, =?UTF-8?Q?'Mirja_K=C3=BChlewind'?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Dec 2016 23:07:02 -0000 >=20 > As a high level comment, I think the current QUIC stream state machine = is quite=20 > complex, and it'd be great to simplify it. I expect it's possible, = but don't have any=20 > concrete suggestions at the moment. I did not find it particularly complex when implementing it. Basically, = the spec says open, send, receive, abort and close. The only complex = part is that frames can be received out of order, and that the error = correction mechanism supposes an interaction between the frame level and = the packet level. But even that can be managed rather easily. There is however another issue, related to multihoming. Can we split a = given stream over several packet level connections? The reasons for = doing that are largely the same as splitting an application stream over = several connections in MP-TCP. Each independent packet level connection = can be parametrized based on its underlying path. Different paths might = get for example different congestion controls. An application that sends = one big stream of data could send part of the stream over each = connection. If the stream level itself handles that, we get nice = properties like being able to send the error corrections on a different = connection than the original packet. -- Christian Huitema From nobody Tue Dec 6 15:24:21 2016 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 2A4941295EF for ; Tue, 6 Dec 2016 15:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 eAE5taSlgGKS for ; Tue, 6 Dec 2016 15:24:17 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0124.outbound.protection.outlook.com [104.47.33.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DEE1295E8 for ; Tue, 6 Dec 2016 15:24:17 -0800 (PST) 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; bh=sU95zEe10dFDkC0crHv2AVpQHtbUKFH//8kdXfeitdA=; b=MhCe6dA4FEEPDu+exkvmK8Cu3+gynFSOQK+Xg7hkjV26FzK5wO9JL3QVBbjc/So2PouuBNF+14Jr1312YspXbbrb9v7zwPJgkhP0Gn1SpgBdcsJYCAC38KHm1NPCbvw2XXQI0X0PuLY0c1WiVxl6l+7v0yBWz9uhPLg/+sToTpU= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Tue, 6 Dec 2016 23:24:14 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.020; Tue, 6 Dec 2016 23:24:14 +0000 From: Mike Bishop To: Jana Iyengar , Martin Thomson Subject: RE: Closing streams Thread-Topic: Closing streams Thread-Index: AQHSTxrILgKjlazdGkOpQOy52b3ruqD5ssyQgAAC4ACAADfaAIABh8uAgAAWoACAAATWcA== Date: Tue, 6 Dec 2016 23:24:14 +0000 Message-ID: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> In-Reply-To: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:a::196] x-ms-office365-filtering-correlation-id: 76c92b4b-ac28-469c-32ad-08d41e2efe22 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:FBqh4/sj9+3i7ylqtc/9kb2r6iDMrzIQl064PH5nP0r3R6wwefalGNTToDup9Knt8o7u5xtOo2MFmUQFUsEqm3Qb7LmJ6dFZbmICb2I4M0ZfkS+SnIfgptb6cMMfLLmU+0CmZ6HY0Umggr4auD0KZurqnCULDanTO6Nl7sNTX/5EELJ2m0wFX+YleDFcixxH8Rsf6wkQg6ONXUMSAAgEKNnEV6DQZalcF/LXVpJDYnU6n4/ydRhwF1zbzyXgw38YBI9nYf/FUfBMybu7Sk8RXRMdzeOkuubPWqUhC9MBVl6Wa1hDY4gXHu+aUMZShiVvuQVeklpnepKTYaz6p+yCT93G/DD0HHb455tHsOPh4kuuOSgSUfJnv4vUWdmcLZTGvFNHZ1VBt5x5lhV3x78KU70shx7vXvUd6jNjpZGvMmcKfhtsOKigIyNTcQbsm1BE9nnnBUX8Dv3G/IcFqJl4Inv1Q20j7csTvBczdDvtleM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558021)(20161123564025)(20161123560025)(20161123562025)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 01480965DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(51444003)(377454003)(199003)(3660700001)(105586002)(81156014)(50986999)(7696004)(106116001)(76576001)(76176999)(8936002)(99286002)(2950100002)(7736002)(9686002)(3480700004)(4326007)(561944003)(68736007)(101416001)(7846002)(74316002)(106356001)(5660300001)(7116003)(93886004)(122556002)(33656002)(54356999)(8676002)(2906002)(39850400001)(3280700002)(81166006)(38730400001)(102836003)(39060400001)(790700001)(39410400001)(6116002)(189998001)(229853002)(8990500004)(10290500002)(39840400001)(86612001)(5005710100001)(2900100001)(97736004)(5001770100001)(86362001)(92566002)(606004)(221733001)(10090500001)(19609705001)(77096006)(6506006)(39450400002)(39860400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27084F339860CCF85824FB1187820BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2016 23:24:14.3152 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Ian Swett , "quic@ietf.org" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Dec 2016 23:24:20 -0000 --_000_BN6PR03MB27084F339860CCF85824FB1187820BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIGluIG15IHByb3Bvc2FsLCB0aGVyZSBhcmUgbm8gSFRUUC1sYXllciBzdHJlYW0g SURzLiAgSXQgZGlyZWN0bHkgcmVmZXJlbmNlcyB0aGUgUVVJQyBzdHJlYW0gSUQgaW4gcXVlc3Rp b24gKHdlbGwsIHJlZmVyZW5jZXMgdGhlIGZpcnN0IHN0cmVhbSBvZiB0aGUgcGFpciBhbnl3aGVy ZSBzb21ldGhpbmcgZWxzZSBuZWVkcyB0byBwb2ludCB0byBpdCkuICBJ4oCZZCByZWFsbHkgbGlr ZSB0byBrZWVwIGF3YXkgZnJvbSBoYXZpbmcgZGlzdGluY3Qgc3RyZWFtIElEcyBhdCB0d28gbGF5 ZXJzLCBldmVuIGlmIHRoZXJlIGlzIGEgc3RhdGljIG1hcHBpbmcgZnJvbSBvbmUgdG8gdGhlIG90 aGVyLiAgKE9mIGNvdXJzZSwgYW4gaW1wbGVtZW50YXRpb24gY291bGQgc3RpbGwgZG8gc28gaW50 ZXJuYWxseSwgaWYgZGVzaXJlZC4pDQoNCkZyb206IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBn b29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgNiwgMjAxNiAzOjA0IFBNDQpUbzog TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkNjOiBJYW4gU3dldHQg PGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9z b2Z0LmNvbT47IHF1aWNAaWV0Zi5vcmc7IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdp bmRAdGlrLmVlLmV0aHouY2g+DQpTdWJqZWN0OiBSZTogQ2xvc2luZyBzdHJlYW1zDQoNCkNhdGNo aW5nIHVwIC0tIGp1c3QgYSBjb3VwbGUgb2YgdGhvdWdodHMuDQoNClJlc2VydmluZyBzdHJlYW1z IGRpZCBjb21lIGZyb20gUkZDIDc1NDAgYW5kIGlzIG1lYW50IGZvciBQVVNIIHN0cmVhbXMgcHJp bWFyaWx5LiBBcyBJYW4gbm90ZXMsIG9uZSBvZiB0aGUgd2F5cyBvZiBrZWVwaW5nIHN0cmVhbS1o YW5kbGluZyBsaWdodC13ZWlnaHQgaXMgYnkgdXNpbmcgaW4tb3JkZXIgc3RyZWFtIGNyZWF0aW9u LiBXZSBkaWRuJ3QgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGxvY2FsIGFuZCByZW1vdGUg InJlc2VydmVkIiBzdGF0ZXMsIGFzIGlzIGRvbmUgaW4gUkZDIDc1NDAsIGJlY2F1c2UgdGhlcmUn cyBubyBub3Rpb24gb2YgUFVTSCBpbiBRVUlDLiBUaGlzIG1lYW5zIFBVU0ggbWVzc2FnZXMgYXJl IHNlbnQgYXQgdGhlIEhUVFAgbGV2ZWwsIHdoaWNoIHRoZW4gdHVybnMgaW50byB0aGUgSFRUUCBs YXllciByZXNlcnZpbmcgc3RyZWFtcyBhdCB0aGUgUVVJQyBsYXllciB0aHJvdWdoIHRoZSByZXNl cnZlX3N0cmVhbSBwcmltaXRpdmUuIFRoZSBSZXNlcnZlZCBzdGF0ZSBpcyBvbmx5IHVzZWZ1bCBh dCB0aGUgc2lkZSB0aGF0IGNyZWF0ZXMgYSBzdHJlYW0sIGZvciBlbmZvcmNlbWVudCBvZiAiU3Ry ZWFtcyBNVVNUIGJlIGNyZWF0ZWQgb3IgcmVzZXJ2ZWQgaW4gc2VxdWVudGlhbCBvcmRlciIgKFNl YyA4LjIpLiBJbmNvbWluZyBzdHJlYW1zIGFyZSBhbGxvd2VkIHRvIGJlIGNyZWF0ZWQgaW4gYXJi aXRyYXJ5IG9yZGVyLCB0byBhbGxvdyBmb3IgbmV0d29yayByZW9yZGVyaW5nIG9mIGluY29taW5n IHN0cmVhbSBmcmFtZXMsIGFuZCBzbywgYSBQVVNIZWQgc3RyZWFtIGRvZXMgbm90IG5lZWQgdG8g YmUgcmVzZXJ2ZWQgYXQgdGhlIHJlY2VpdmVyLg0KDQpUaGUgc3RhdGUgbWFjaGluZSBpcyBiYXNp Y2FsbHkgYWJvdXQgYXMgY29tcGxleCBhcyB0aGUgSFRUUC8yIHN0cmVhbSBzdGF0ZSBtYWNoaW5l Li4uIEknbSBub3QgdG9vIGNvbmNlcm5lZCBhYm91dCBpdC4gTWlrZSdzIHByb3Bvc2FsIGRvZXMg bm90IHRha2UgdXMgYXdheSBmcm9tIHRoZSBjb25ncnVlbmNlIGJ5IG11Y2guLi4gdGhlIDItc3Ry ZWFtIG1hcHBpbmcgYXBwcm9hY2ggYmFzaWNhbGx5IG1lYW5zIHRoYXQgZXZlcnkgSFRUUC8yIHN0 cmVhbSBiZWNvbWVzIDIgUVVJQyBzdHJlYW1zLiBJZiB5b3Ugd2VyZSB0byBQVVNIIGFuIEhUVFAv MiBzdHJlYW0sIHRoaXMgd291bGQgbW92ZSB0aGUgSFRUUC8yIHN0cmVhbSBpbnRvIHRoZSAicmVz ZXJ2ZSAobG9jYWwpIiBzdGF0ZSwgYW5kIHRoZSBIVFRQIGxheWVyIHdvdWxkIHRoZW4gY2F1c2Ug dGhlIDIgY29ycmVzcG9uZGluZyBRVUlDIHN0cmVhbXMgdG8gZ28gaW50byB0aGUgInJlc2VydmVk IiBzdGF0ZSAoSSB3b3VsZCBleHBlY3QgdGhpcyBtYXBwaW5nIHRvIGJlIHN0YXRpYyAtLSBzb21l dGhpbmcgbGlrZSBIVFRQLzIgc3RyZWFtIElEIHggMiBhbmQgSFRUUC8yIHN0cmVhbSBJRCAgeCAy ICsgMS4pDQoNCg0KT24gVHVlLCBEZWMgNiwgMjAxNiBhdCAxOjQzIFBNLCBNYXJ0aW4gVGhvbXNv biA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20+PiB3cm90ZToNCk9uIDYgRGVjZW1iZXIgMjAxNiBhdCAwNzoyMSwgSWFuIFN3ZXR0IDxpYW5z d2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj4gd3JvdGU6DQo+IEFz IGEgaGlnaCBsZXZlbCBjb21tZW50LCBJIHRoaW5rIHRoZSBjdXJyZW50IFFVSUMgc3RyZWFtIHN0 YXRlIG1hY2hpbmUgaXMNCj4gcXVpdGUgY29tcGxleCwgYW5kIGl0J2QgYmUgZ3JlYXQgdG8gc2lt cGxpZnkgaXQuICBJIGV4cGVjdCBpdCdzIHBvc3NpYmxlLA0KPiBidXQgZG9uJ3QgaGF2ZSBhbnkg Y29uY3JldGUgc3VnZ2VzdGlvbnMgYXQgdGhlIG1vbWVudC4NCg0KDQpPbmUgd2F5IHRvIGRvIHRo aXMgaXMgdG8gY29tcGxldGVseSBkZXRhY2ggc3RyZWFtcyBpbiBib3RoIGRpcmVjdGlvbnMuDQpU aGVuIGhhdmUgcmVzcG9uc2Ugc3RyZWFtcyBleHBsaWNpdGx5IGlkZW50aWZ5IHRoZSByZXF1ZXN0 IHRoYXQgdGhleQ0KYXJlIHJlc3BvbmRpbmcgdG8uICBQb3NzaWJseSBhdCB0aGUgdXNhZ2UgbGF5 ZXIuICBJIHRoaW5rIHRoYXQgYXZvaWRzDQptdWNoIG9mIHRoZSBjb21wbGV4aXR5IGFzc29jaWF0 ZWQgd2l0aCByZXNlcnZhdGlvbnMsIGJ1dCBpdCBsaWtlbHkNCmFkZHMgbmV3IGFuZCBpbnRlcmVz dGluZyB0d2lzdHMgdG8gY29uc2lkZXIuDQoNCk9uZSB0d2lzdCB0aGF0IEknbSBwYXJ0aWN1bGFy bHkgY29uY2VybmVkIGFib3V0IGlzIGNvbmdydWVuY2Ugd2l0aCBoMi4NCkJ1dCB0aGVuIE1pa2Un cyBwcm9wb3NhbHMgaGF2ZSBhbHJlYWR5IHRha2VuIHVzIGF3YXkgZnJvbSB0aGF0OyBtYXliZQ0K dGhhdCBjYW4gYmUgcmVwYWlyZWQgaW4gdGltZSwgYnV0IHdlIHNob3VsZCBiZSBhd2FyZSBvZiB0 aGUgY29zdCBvZg0KZGl2ZXJnZW5jZS4gIFRvIGJlIGV4cGxpY2l0LCB3ZSd2ZSBvcGVuZWQgc2V2 ZXJhbCBuZXcgZnJvbnRzIGp1c3QgYnkNCnRha2luZyB0aGlzIHdvcmsgb247IHJld29ya2luZyB0 aGUgcmVxdWVzdC1yZXNwb25zZSBzdHJlYW0gbWFwcGluZw0Kb3BlbnMgYW5vdGhlci4NCg0K --_000_BN6PR03MB27084F339860CCF85824FB1187820BN6PR03MB2708namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B Y3R1YWxseSwgaW4gbXkgcHJvcG9zYWwsIHRoZXJlIGFyZSBubyBIVFRQLWxheWVyIHN0cmVhbSBJ RHMuJm5ic3A7IEl0IGRpcmVjdGx5IHJlZmVyZW5jZXMgdGhlIFFVSUMgc3RyZWFtIElEIGluIHF1 ZXN0aW9uICh3ZWxsLCByZWZlcmVuY2VzIHRoZSBmaXJzdCBzdHJlYW0gb2YgdGhlIHBhaXIgYW55 d2hlcmUgc29tZXRoaW5nIGVsc2UgbmVlZHMgdG8gcG9pbnQgdG8gaXQpLiZuYnNwOyBJ4oCZZCBy ZWFsbHkgbGlrZSB0byBrZWVwDQogYXdheSBmcm9tIGhhdmluZyBkaXN0aW5jdCBzdHJlYW0gSURz IGF0IHR3byBsYXllcnMsIGV2ZW4gaWYgdGhlcmUgaXMgYSBzdGF0aWMgbWFwcGluZyBmcm9tIG9u ZSB0byB0aGUgb3RoZXIuJm5ic3A7IChPZiBjb3Vyc2UsIGFuIGltcGxlbWVudGF0aW9uIGNvdWxk IHN0aWxsIGRvIHNvIGludGVybmFsbHksIGlmIGRlc2lyZWQuKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dIDxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciA2LCAyMDE2IDM6MDQgUE08YnI+DQo8 Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBN aWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IHF1aWNAaWV0 Zi5vcmc7IE1pcmphIEvDvGhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHou Y2gmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBDbG9zaW5nIHN0cmVhbXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhdGNoaW5nIHVwIC0tIGp1c3QgYSBjb3VwbGUgb2YgdGhv dWdodHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZXNlcnZpbmcgc3RyZWFtcyBkaWQgY29tZSBmcm9tIFJGQyA3NTQwIGFuZCBpcyBtZWFudCBm b3IgUFVTSCBzdHJlYW1zIHByaW1hcmlseS4gQXMgSWFuIG5vdGVzLCBvbmUgb2YgdGhlIHdheXMg b2Yga2VlcGluZyBzdHJlYW0taGFuZGxpbmcgbGlnaHQtd2VpZ2h0IGlzIGJ5IHVzaW5nIGluLW9y ZGVyIHN0cmVhbSBjcmVhdGlvbi4gV2UgZGlkbid0IG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2Vl biBsb2NhbCBhbmQNCiByZW1vdGUgJnF1b3Q7cmVzZXJ2ZWQmcXVvdDsgc3RhdGVzLCBhcyBpcyBk b25lIGluIFJGQyA3NTQwLCBiZWNhdXNlIHRoZXJlJ3Mgbm8gbm90aW9uIG9mIFBVU0ggaW4gUVVJ Qy4gVGhpcyBtZWFucyBQVVNIIG1lc3NhZ2VzIGFyZSBzZW50IGF0IHRoZSBIVFRQIGxldmVsLCB3 aGljaCB0aGVuIHR1cm5zIGludG8gdGhlIEhUVFAgbGF5ZXIgcmVzZXJ2aW5nIHN0cmVhbXMgYXQg dGhlIFFVSUMgbGF5ZXIgdGhyb3VnaCB0aGUgcmVzZXJ2ZV9zdHJlYW0gcHJpbWl0aXZlLg0KIFRo ZSBSZXNlcnZlZCBzdGF0ZSBpcyBvbmx5IHVzZWZ1bCBhdCB0aGUgc2lkZSB0aGF0IGNyZWF0ZXMg YSBzdHJlYW0sIGZvciBlbmZvcmNlbWVudCBvZiAmcXVvdDtTdHJlYW1zIE1VU1QgYmUgY3JlYXRl ZCBvciByZXNlcnZlZCBpbiBzZXF1ZW50aWFsIG9yZGVyJnF1b3Q7IChTZWMgOC4yKS4gSW5jb21p bmcgc3RyZWFtcyBhcmUgYWxsb3dlZCB0byBiZSBjcmVhdGVkIGluIGFyYml0cmFyeSBvcmRlciwg dG8gYWxsb3cgZm9yIG5ldHdvcmsgcmVvcmRlcmluZyBvZiBpbmNvbWluZw0KIHN0cmVhbSBmcmFt ZXMsIGFuZCBzbywgYSBQVVNIZWQgc3RyZWFtIGRvZXMgbm90IG5lZWQgdG8gYmUgcmVzZXJ2ZWQg YXQgdGhlIHJlY2VpdmVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3RhdGUgbWFjaGluZSBpcyBiYXNpY2FsbHkgYWJvdXQg YXMgY29tcGxleCBhcyB0aGUgSFRUUC8yIHN0cmVhbSBzdGF0ZSBtYWNoaW5lLi4uIEknbSBub3Qg dG9vIGNvbmNlcm5lZCBhYm91dCBpdC4gTWlrZSdzIHByb3Bvc2FsIGRvZXMgbm90IHRha2UgdXMg YXdheSBmcm9tIHRoZSBjb25ncnVlbmNlIGJ5IG11Y2guLi4gdGhlIDItc3RyZWFtIG1hcHBpbmcg YXBwcm9hY2ggYmFzaWNhbGx5IG1lYW5zIHRoYXQNCiBldmVyeSBIVFRQLzIgc3RyZWFtIGJlY29t ZXMgMiBRVUlDIHN0cmVhbXMuIElmIHlvdSB3ZXJlIHRvIFBVU0ggYW4gSFRUUC8yIHN0cmVhbSwg dGhpcyB3b3VsZCBtb3ZlIHRoZSBIVFRQLzIgc3RyZWFtIGludG8gdGhlICZxdW90O3Jlc2VydmUg KGxvY2FsKSZxdW90OyBzdGF0ZSwgYW5kIHRoZSBIVFRQIGxheWVyIHdvdWxkIHRoZW4gY2F1c2Ug dGhlIDIgY29ycmVzcG9uZGluZyBRVUlDIHN0cmVhbXMgdG8gZ28gaW50byB0aGUgJnF1b3Q7cmVz ZXJ2ZWQmcXVvdDsgc3RhdGUgKEkgd291bGQNCiBleHBlY3QgdGhpcyBtYXBwaW5nIHRvIGJlIHN0 YXRpYyAtLSBzb21ldGhpbmcgbGlrZSBIVFRQLzIgc3RyZWFtIElEIHggMiBhbmQgSFRUUC8yIHN0 cmVhbSBJRCAmbmJzcDt4IDIgJiM0MzsgMS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgNiwg MjAxNiBhdCAxOjQzIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gNiBEZWNlbWJlciAy MDE2IGF0IDA3OjIxLCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29n bGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBBcyBh IGhpZ2ggbGV2ZWwgY29tbWVudCwgSSB0aGluayB0aGUgY3VycmVudCBRVUlDIHN0cmVhbSBzdGF0 ZSBtYWNoaW5lIGlzPGJyPg0KJmd0OyBxdWl0ZSBjb21wbGV4LCBhbmQgaXQnZCBiZSBncmVhdCB0 byBzaW1wbGlmeSBpdC4mbmJzcDsgSSBleHBlY3QgaXQncyBwb3NzaWJsZSw8YnI+DQomZ3Q7IGJ1 dCBkb24ndCBoYXZlIGFueSBjb25jcmV0ZSBzdWdnZXN0aW9ucyBhdCB0aGUgbW9tZW50Ljxicj4N Cjxicj4NCjxicj4NCk9uZSB3YXkgdG8gZG8gdGhpcyBpcyB0byBjb21wbGV0ZWx5IGRldGFjaCBz dHJlYW1zIGluIGJvdGggZGlyZWN0aW9ucy48YnI+DQpUaGVuIGhhdmUgcmVzcG9uc2Ugc3RyZWFt cyBleHBsaWNpdGx5IGlkZW50aWZ5IHRoZSByZXF1ZXN0IHRoYXQgdGhleTxicj4NCmFyZSByZXNw b25kaW5nIHRvLiZuYnNwOyBQb3NzaWJseSBhdCB0aGUgdXNhZ2UgbGF5ZXIuJm5ic3A7IEkgdGhp bmsgdGhhdCBhdm9pZHM8YnI+DQptdWNoIG9mIHRoZSBjb21wbGV4aXR5IGFzc29jaWF0ZWQgd2l0 aCByZXNlcnZhdGlvbnMsIGJ1dCBpdCBsaWtlbHk8YnI+DQphZGRzIG5ldyBhbmQgaW50ZXJlc3Rp bmcgdHdpc3RzIHRvIGNvbnNpZGVyLjxicj4NCjxicj4NCk9uZSB0d2lzdCB0aGF0IEknbSBwYXJ0 aWN1bGFybHkgY29uY2VybmVkIGFib3V0IGlzIGNvbmdydWVuY2Ugd2l0aCBoMi48YnI+DQpCdXQg dGhlbiBNaWtlJ3MgcHJvcG9zYWxzIGhhdmUgYWxyZWFkeSB0YWtlbiB1cyBhd2F5IGZyb20gdGhh dDsgbWF5YmU8YnI+DQp0aGF0IGNhbiBiZSByZXBhaXJlZCBpbiB0aW1lLCBidXQgd2Ugc2hvdWxk IGJlIGF3YXJlIG9mIHRoZSBjb3N0IG9mPGJyPg0KZGl2ZXJnZW5jZS4mbmJzcDsgVG8gYmUgZXhw bGljaXQsIHdlJ3ZlIG9wZW5lZCBzZXZlcmFsIG5ldyBmcm9udHMganVzdCBieTxicj4NCnRha2lu ZyB0aGlzIHdvcmsgb247IHJld29ya2luZyB0aGUgcmVxdWVzdC1yZXNwb25zZSBzdHJlYW0gbWFw cGluZzxicj4NCm9wZW5zIGFub3RoZXIuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB27084F339860CCF85824FB1187820BN6PR03MB2708namp_-- From nobody Tue Dec 6 15:44:00 2016 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 54C7B1295FF for ; Tue, 6 Dec 2016 15:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 PMq7v16A-0EU for ; Tue, 6 Dec 2016 15:43:55 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 8C7E41295FB for ; Tue, 6 Dec 2016 15:43:54 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id x186so203979524vkd.1 for ; Tue, 06 Dec 2016 15:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l25HOr1S8aYOMjoZCWcoK/vHxxEOooxAXjrvc7LIr8s=; b=fWVZl9cksvYc7hvNmi8DdeR7T9Cigy+zn++tTfCBgYdgUcyShe1V/9sx+cjMIZnLA/ zGQ+cWBDXmm1oYU/VaYD6aWM37t8Ro8JQu38hqv1+uIoX/T5mf4Uj32eKhAG7zVb4dmr 4H8xge5wg6gW4zc2WPWGup5693ylHvOGfqLCHvspx+wKQPfqrPpByryDIruAXnNSUxsL xcZ5cjtu+aLqsCI7YZI2VdAu/spEmdvm31gC8VSyENxwvX6yD3rfOPDXAhiTjT57gjnw VkSCeXGH3lePkHTOI35VhXEWP3Gwn6kkrYCmd0QnhQI25+jnfmJ1RWDpcbEowiF1/EJ+ HM6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l25HOr1S8aYOMjoZCWcoK/vHxxEOooxAXjrvc7LIr8s=; b=mbvXCi9WqSLjha9qhQvj3TEL7dxX9J8n36hkmnvOUKcDoHoEr75NVJvy0rJrNY+fxm c1ZJ6UYhaP0RlzbHVzia4aH2B8q2ZvMP5vaeDA+q31LaFWfUB0vKP4S5WrGCj5sHKUQb SxUrqwm2YKbrTApVciA0Vbm4yULsaetlOY7Uz7NjPAL+mHzMvv7UTNMHrRR6FfeNvonI HwMSRpBsvS3BmHAJaTrJ5Ef0hW1DJKQRO2pSnh7XETODUF4bVuZo8A6DoGH/jZo0Vq1T pfBbatQkgxPTClsnw2L/6K/ql737Ns5LxKSmY12WYU+vfHoSE02Buwzn8eAL2H+y245s PyoQ== X-Gm-Message-State: AKaTC01bJZsFvuHQaluAhhNfFWJj1bwRL2c2cODJDzUsEtpHR2xypae/BIvRPXp6hb7GzKwF/QlXMzQVTT29i5Q0 X-Received: by 10.31.164.204 with SMTP id n195mr20129788vke.58.1481067833534; Tue, 06 Dec 2016 15:43:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 6 Dec 2016 15:43:53 -0800 (PST) In-Reply-To: References: <8E60AD8E-3757-45AA-8F94-AC6BF01DB7A3@tik.ee.ethz.ch> From: Jana Iyengar Date: Tue, 6 Dec 2016 15:43:53 -0800 Message-ID: Subject: Re: Closing streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1142e10a1b7678054305fa16 Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ian Swett , "quic@ietf.org" , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Dec 2016 23:43:58 -0000 --001a1142e10a1b7678054305fa16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 6, 2016 at 3:24 PM, Mike Bishop wrote: > Actually, in my proposal, there are no HTTP-layer stream IDs. It directl= y > references the QUIC stream ID in question (well, references the first > stream of the pair anywhere something else needs to point to it). I=E2= =80=99d > really like to keep away from having distinct stream IDs at two layers, > even if there is a static mapping from one to the other. (Of course, an > implementation could still do so internally, if desired.) > Right, good point. In the abstract though, the idea remains the same -- where you would have seen HTTP/2 stream ID Y in the HTTP/2 world, you now see QUIC stream ID Yx2 and Yx2+1. > > > *From:* Jana Iyengar [mailto:jri@google.com] > *Sent:* Tuesday, December 6, 2016 3:04 PM > *To:* Martin Thomson > *Cc:* Ian Swett ; Mike Bishop < > Michael.Bishop@microsoft.com>; quic@ietf.org; Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> > *Subject:* Re: Closing streams > > > > Catching up -- just a couple of thoughts. > > > > Reserving streams did come from RFC 7540 and is meant for PUSH streams > primarily. As Ian notes, one of the ways of keeping stream-handling > light-weight is by using in-order stream creation. We didn't need to > distinguish between local and remote "reserved" states, as is done in RFC > 7540, because there's no notion of PUSH in QUIC. This means PUSH messages > are sent at the HTTP level, which then turns into the HTTP layer reservin= g > streams at the QUIC layer through the reserve_stream primitive. The > Reserved state is only useful at the side that creates a stream, for > enforcement of "Streams MUST be created or reserved in sequential order" > (Sec 8.2). Incoming streams are allowed to be created in arbitrary order, > to allow for network reordering of incoming stream frames, and so, a PUSH= ed > stream does not need to be reserved at the receiver. > > > > The state machine is basically about as complex as the HTTP/2 stream stat= e > machine... I'm not too concerned about it. Mike's proposal does not take = us > away from the congruence by much... the 2-stream mapping approach basical= ly > means that every HTTP/2 stream becomes 2 QUIC streams. If you were to PUS= H > an HTTP/2 stream, this would move the HTTP/2 stream into the "reserve > (local)" state, and the HTTP layer would then cause the 2 corresponding > QUIC streams to go into the "reserved" state (I would expect this mapping > to be static -- something like HTTP/2 stream ID x 2 and HTTP/2 stream ID = x > 2 + 1.) > > > > > > On Tue, Dec 6, 2016 at 1:43 PM, Martin Thomson > wrote: > > On 6 December 2016 at 07:21, Ian Swett wrote: > > As a high level comment, I think the current QUIC stream state machine = is > > quite complex, and it'd be great to simplify it. I expect it's possibl= e, > > but don't have any concrete suggestions at the moment. > > > One way to do this is to completely detach streams in both directions. > Then have response streams explicitly identify the request that they > are responding to. Possibly at the usage layer. I think that avoids > much of the complexity associated with reservations, but it likely > adds new and interesting twists to consider. > > One twist that I'm particularly concerned about is congruence with h2. > But then Mike's proposals have already taken us away from that; maybe > that can be repaired in time, but we should be aware of the cost of > divergence. To be explicit, we've opened several new fronts just by > taking this work on; reworking the request-response stream mapping > opens another. > > > --001a1142e10a1b7678054305fa16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 6, 2016 at 3:24 PM, Mike Bishop <Michael.Bishop@microso= ft.com> wrote:

Actually, in my proposal, there are no HTTP-layer st= ream IDs.=C2=A0 It directly references the QUIC stream ID in question (well= , references the first stream of the pair anywhere something else needs to = point to it).=C2=A0 I=E2=80=99d really like to keep away from having distinct stream IDs at two layers, even if there is a sta= tic mapping from one to the other.=C2=A0 (Of course, an implementation coul= d still do so internally, if desired.)

Right, good point. In the abstract though, the idea remains the= same -- where you would have seen HTTP/2 stream ID Y in the HTTP/2 world, = you now see QUIC stream ID Yx2 and Yx2+1.

=C2=A0

=C2=A0

From: Jana Iyengar [mailto:jri@google.com]
Sent: Tuesday, December 6, 2016 3:04 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Ian Swett <ianswett@google.com>; Mike Bishop <Michael.Bishop@microsoft.com= >; quic@ietf.org= ; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Subject: Re: Closing streams

=C2=A0

Catching up -- just a couple of thoughts.=C2=A0

=C2=A0

Reserving streams did come from RFC 7540 and is mean= t for PUSH streams primarily. As Ian notes, one of the ways of keeping stre= am-handling light-weight is by using in-order stream creation. We didn'= t need to distinguish between local and remote "reserved" states, as is done in RFC 7540, because there&= #39;s no notion of PUSH in QUIC. This means PUSH messages are sent at the H= TTP level, which then turns into the HTTP layer reserving streams at the QU= IC layer through the reserve_stream primitive. The Reserved state is only useful at the side that creates a stream, for e= nforcement of "Streams MUST be created or reserved in sequential order= " (Sec 8.2). Incoming streams are allowed to be created in arbitrary o= rder, to allow for network reordering of incoming stream frames, and so, a PUSHed stream does not need to be reserved at the= receiver.=C2=A0

=C2=A0

The state machine is basically about as complex as t= he HTTP/2 stream state machine... I'm not too concerned about it. Mike&= #39;s proposal does not take us away from the congruence by much... the 2-s= tream mapping approach basically means that every HTTP/2 stream becomes 2 QUIC streams. If you were to PUSH an HTTP/2 = stream, this would move the HTTP/2 stream into the "reserve (local)&qu= ot; state, and the HTTP layer would then cause the 2 corresponding QUIC str= eams to go into the "reserved" state (I would expect this mapping to be static -- something like HTTP/2 stream ID x 2 an= d HTTP/2 stream ID =C2=A0x 2 + 1.)

=C2=A0

=C2=A0

On Tue, Dec 6, 2016 at 1:43 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On 6 December 2016 at= 07:21, Ian Swett <ianswett@google.com> wrote:
> As a high level comment, I think the current QUIC stream state machine= is
> quite complex, and it'd be great to simplify it.=C2=A0 I expect it= 's possible,
> but don't have any concrete suggestions at the moment.


One way to do this is to completely detach streams in both directions.
Then have response streams explicitly identify the request that they
are responding to.=C2=A0 Possibly at the usage layer.=C2=A0 I think that av= oids
much of the complexity associated with reservations, but it likely
adds new and interesting twists to consider.

One twist that I'm particularly concerned about is congruence with h2.<= br> But then Mike's proposals have already taken us away from that; maybe that can be repaired in time, but we should be aware of the cost of
divergence.=C2=A0 To be explicit, we've opened several new fronts just = by
taking this work on; reworking the request-response stream mapping
opens another.

=C2=A0


--001a1142e10a1b7678054305fa16-- From nobody Wed Dec 7 01:47:01 2016 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 98C75129642 for ; Wed, 7 Dec 2016 01:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 VcCnDn018J1r for ; Wed, 7 Dec 2016 01:46:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2D8129655 for ; Wed, 7 Dec 2016 01:46:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 075E2D9546; Wed, 7 Dec 2016 10:46:55 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OuRCq1z1GBTY; Wed, 7 Dec 2016 10:46:54 +0100 (MET) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B9924D94B7; Wed, 7 Dec 2016 10:46:54 +0100 (MET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Review of draft-ietf-quic-transport-00 From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 7 Dec 2016 10:46:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71F548B4-7E61-406E-AC25-0FFBFD4DEAE5@tik.ee.ethz.ch> References: <938D954F-A61D-4779-90D6-CC2800CF75DE@tik.ee.ethz.ch> To: Mike Bishop X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 07 Dec 2016 09:46:59 -0000 Hi Mike, hi all, see below. > Am 05.12.2016 um 19:57 schrieb Mike Bishop = : >=20 > Having an infinite number of streams open and idle seems like a good = way to waste application resources tracking state. Speaking from an = application perspective, I'm reading from a stream and would like a way = to know when I've reached the end (rather than just having not received = it yet). Of course, I could define that myself with an EOF-indicator on = the stream data if there's a good reason for the transport *not* to = provide that functionality. Other than simplifying the stream state = machine, why wouldn't you support it? The idea is really not to have an infinite number of streams open. You = still have an maximum number of open stream and as Ian pointed out if = you open them in order, you probably just keep the last X open. My point = is that closing a stream can be a local decision. That doesn=E2=80=99t = mean that quic couldn=E2=80=99t tell the higher layers about it. It=E2=80=99= s again just a local interface question.=20 And yes if you send one object over a stream and you want to let the = other end know that you are not planning to send any additional data, = there should probably be a EOF signal at the layer that knows about the = objects. Again, in this case there could be a local interface to the = lower layer telling quic that you do expect any data anymore on that = stream or that you are not will to accept any data any more on that = stream, so quic could send the right error message if it anyway receives = data on that stream. Mirja >=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja = K=C3=BChlewind > Sent: Monday, December 5, 2016 9:03 AM > To: quic@ietf.org > Subject: Review of draft-ietf-quic-transport-00 >=20 > Hi all, >=20 > I reviewed draft-ietf-quic-transport-00 as an individual. I have quite = a few comments but I would like to raise three high-level design = questions which I will send separate mails for next with more = explanation to keep the discussion separated. I do have more comments = but I might bring them up later or just send a PR for some of them. = Excuse me if parts of these issues have been discussed earlier; it=E2=80=99= s not unlikely that I=E2=80=99ve missed parts of previous discussions = given the amount of mail we currently have on this list.=20 >=20 > The three high level points, which are more on the transporty side of = life, are (see further explanation in following mails): >=20 > 1. Per-stream vs. per-connection information: They way per-stream and = per-connection information are mixed up in frames (or not) is really = confusing to me. I have some concrete examples and proposal in the next = mail, and this is a little related to my next point. >=20 > 2. Encryption: The split between the crypto and the transport = handshake is confusing and, as I believe was discussed to some extend = already, it=E2=80=99s not clear which information will be encrypted and = which will be visible. >=20 > 3. Do we really need to close streams? Why not just leave them open = and have them inactive, e.g. with a time-out and/or advertising a window = of zero=E2=80=A6? Especially reading section 8, I think that would = simplify things enormously. >=20 > I think some of these questions are connected to the split of = documents, especially regarding the tls-doc but also the = cc/recovery-doc. I only reviewed in detail this doc, the quic-transport = draft, and only skimmed the other docs, however, to my understanding as = it should be possible to replace the crypto-negotiation as well as = recovery mechanism with other mechanisms, and as such this draft must = be stand-alone to a certain extend and therefore a few things are = missing. >=20 > Please see next mails! > Mirja >=20 >=20 > P.S.: One nit I would like to mention here: > Section 4.2 (Regular Packets) page 10 says: "The first packet send by = an endpoint MUST have a packet number of 1." > And section 7 (Packetization and Reliability) page 28 says: "That is, = the first packet in both directions of the connection MUST have a packet = number of 0." >=20 >=20 From nobody Thu Dec 8 09:52:53 2016 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 7CB96129FA1 for ; Thu, 8 Dec 2016 09:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 tMqgJ8kd8PCy for ; Thu, 8 Dec 2016 09:52:49 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1871294DD for ; Thu, 8 Dec 2016 09:52:48 -0800 (PST) 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; bh=K2Yx5kLnv/eOo8vYUPTZniu4v4qin6hR+92pJAsrFdA=; b=JyTaBzCJ/wlZIkI0YhClRKCj3bXUy9KJICMNlIfAmEx1MJ3GPJdtN6oe6Q3r/OQHZSL5/qYbhpWnDuCee4MtIYFZw1s5Sc2OdEE15w22Lv9/CBLZjNUoRcv19qfA74UxW2QN2Kfw1QP4LAgPFGzRFrGCtEVuNo2sWm+n082jjG0= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Thu, 8 Dec 2016 17:52:46 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.021; Thu, 8 Dec 2016 17:52:46 +0000 From: Mike Bishop To: Mike Bishop , Ian Swett , Jana Iyengar Subject: RE: HTTP Mapping: Fixing streams-in-streams Thread-Topic: HTTP Mapping: Fixing streams-in-streams Thread-Index: AdJMK4UPnpRSHPYRT8al2LR5lm7ZTwDCknSAAABZHIAAASvckACPyzDQ Date: Thu, 8 Dec 2016 17:52:46 +0000 Message-ID: References: In-Reply-To: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:1::16a] x-ms-office365-filtering-correlation-id: 67409b2c-d8a8-4f96-ca17-08d41f9304c2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:3D/+KZu2y0yUrXoFmjBvP7XoxmpdNX6r77bLHBOV4gA5BQFxqyc6iDW6qZIFmD8fX/seYWESYkxUSbLaDtpU8bT3OarKf3oI6UeFS/nXWzgDg9MnhJspx55cwFZ4LP/KxoBraZ8YGeTrXq1meFIVvB26urwswDsNNgSUK5RhvM3EY/oU36L9upKdGtv3+A5ElRPZ8dxgEbrA0fFyGRoBat8LeM8ZBPBBIBlMpQznt6v5CbztipEFyYooys4RJjYepi8B2euSZEt0hqRMN/lqbBM9mTQXs0g07UOriT3B2FE+NUuL8WGx/r6h+jNpVHsxpdo7DnAyXa1nEPOzDU6dFpsPJmKIhdKAt9a5Tc5c94EDAt+wE4zxkOieaBnnZHyRM3Q4yJWlRks4OCcy4Y7iviIP22lu5pipZNGS3rLE8uYwK8cwerIkQu77zqMCbIMExVzy8hQuR0Zh0DNxwfreQRdlWJAr5Dua80w32A2Qg2g= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6042181)(6072148)(6047074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(51914003)(199003)(189002)(24454002)(7696004)(229853002)(9686002)(68736007)(2906002)(77096006)(86612001)(86362001)(5001770100001)(97736004)(81156014)(606004)(561944003)(2421001)(189998001)(4326007)(122556002)(2950100002)(5660300001)(38730400001)(81166006)(8936002)(19609705001)(8676002)(8990500004)(50986999)(2900100001)(76176999)(33656002)(54356999)(101416001)(76576001)(92566002)(3280700002)(3660700001)(230783001)(7906003)(7846002)(790700001)(6116002)(99286002)(106356001)(102836003)(93886004)(1511001)(105586002)(10090500001)(74316002)(6506006)(2561002)(5005710100001)(10290500002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708FAF57F9276296D71A06987840BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 17:52:46.5479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 08 Dec 2016 17:52:51 -0000 --_000_BN6PR03MB2708FAF57F9276296D71A06987840BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2l2ZW4gc29tZSBwb3NpdGl2ZSBmZWVkYmFjayBhbmQgbm8gbmVnYXRpdmUgc28gZmFyLCBJ4oCZ bSBnb2luZyB0byBnbyBhaGVhZCBhbmQgbWVyZ2UgdGhpcy4gIEZlZWRiYWNrIGNvbnRpbnVlcyB0 byBiZSB3ZWxjb21lLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTWlrZSBCaXNob3ANClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAx NiAxOjUyIFBNDQpUbzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgSmFuYSBJeWVu Z2FyIDxqcmlAZ29vZ2xlLmNvbT4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogSFRUUCBNYXBwaW5nOiBGaXhpbmcgc3RyZWFtcy1pbi1zdHJlYW1zDQoNCkni gJl2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0IHdpdGggdGhlIGZvbGxvd2luZyBwcm9wb3NhbCBo ZXJlOiAgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzcxDQoNCkZl ZWRiYWNrIHdlbGNvbWUsIGFzIGFsd2F5cy4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiAxMjozNiBQ TQ0KVG86IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29t Pj4NCkNjOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IEhUVFAgTWFwcGluZzogRml4 aW5nIHN0cmVhbXMtaW4tc3RyZWFtcw0KDQpBZ3JlZWQsIG1vdmluZyBmb3J3YXJkIHdpdGggdGhl IGV4aXN0aW5nIGxldmVsIG9mIEhPTCBibG9ja2luZyBhbmQgaW1wcm92aW5nIHVwb24gaXQgc2Vl bXMgcHJhY3RpY2FsLCBzaW5jZSBpdCBzZWVtcyB2ZXJ5IGxpa2VseSB3ZSdsbCBtb3ZlIHRvIHRo ZSB0d28tc3RyZWFtcy1wZXItcmVxdWVzdCBtb2RlbCBubyBtYXR0ZXIgd2hhdC4NCg0KT24gTW9u LCBEZWMgNSwgMjAxNiBhdCAzOjI2IFBNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1h aWx0bzpqcmlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB0aGUgd29yaywgTWlrZS4g SSBsaWtlIHRoaXMgYXBwcm9hY2ggLS0gaXQncyBhIGdyZWF0IHdheSB0byBzZXBhcmF0ZSB0aGUg aGVhZGVyIGNvbXByZXNzaW9uIGlzc3VlIGZyb20gdGhlIGlzc3VlIG9mIGEgY2xlYW4gbWFwcGlu ZyBvZiBIVFRQIGhlYWRlcnMvZGF0YSB0byBRVUlDIHN0cmVhbXMuIEkgdGhpbmsgd2Ugc2hvdWxk IGRpc2N1c3MgdGhlIEhUVFAgdG8gUVVJQyBzdHJlYW0gbWFwcGluZyBwcm9wb3NhbCB5b3UndmUg b3V0bGluZWQsIGJ1dCBzaG91bGQgd2UgZG8gdGhhdCBvbiBhbiBpc3N1ZT8gT3IgYSBzZXBhcmF0 ZSB0aHJlYWQ/DQoNCkZXSVcsIEkgbGlrZSB0aGlzIG1hcHBpbmcgYXBwcm9hY2gsIHdoZXJlIEhU VFAgaGVhZGVycyBhbmQgYm9keSBhcmUgbWFwcGVkIHRvIGEgc3RyZWFtLXBhaXIuIEFzIEkndmUg bm90ZWQgZWFybGllciwgUVVJQydzIHN0cmVhbXMgYXJlIGVwaGVtZXJhbCBhbmQgc2hvdWxkIGJl IGxpZ2h0d2VpZ2h0LCB3aGljaCBtZWFucyB0aGF0IHRoZXkgY2FuIGJlIHVzZWQgaW5zdGVhZCBv ZiBidWlsZGluZyBhIG5ldyBmcmFtaW5nIGZvcm1hdCBmb3IgSFRUUCBoZWFkZXJzIHZzIGJvZHku DQoNCg0KT24gVGh1LCBEZWMgMSwgMjAxNiBhdCAzOjM1IFBNLCBNaWtlIEJpc2hvcCA8TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KV2UgaGF2ZSB0aGUgZXhpc3RpbmcgZG9jdW1lbnQgd2hpY2ggcHV0cyBldmVy eXRoaW5nIG9uIGEgc2luZ2xlIHN0cmVhbSBhbmQgcmV0YWlucyBIVFRQLzIgZnJhbWluZy4gIEF0 IHRoZSBXRyBtZWV0aW5nLCBJIGhlYXJkIHN1YnN0YW50aWFsIGRlc2lyZSB0byBtb3ZlIGFzIG11 Y2ggYXMgcG9zc2libGUgb2ZmIHRvIHNlcGFyYXRlIHN0cmVhbXMgcGVyIHJlcXVlc3QuICBUaGVy ZSB3YXMgYWxzbyBkaXNjdXNzaW9uIGFib3V0IGhvdyB0byBtb2RpZnkgSFBBQ0sgKEJ1Y2sgaGFz IGEgcHJvcG9zYWwgdmlhIGUtbWFpbDsgSSBoYXZlIGEgZHJhZnQpIHRvIGVuYWJsZSB0aGlzLCBi dXQgZnJvbSBzaWRlIGNvbnZlcnNhdGlvbnMsIEkgdGhpbmsgdGhlcmXigJlzIGFsc28gYSBkZXNp cmUgdG8gcmV1c2UgSFBBQ0sgY29kZSB3aGVyZSBwb3NzaWJsZSBhbmQgbWluaW1pemUgY2hhbmdl cy4NCg0KV2hhdCBJ4oCZZCBsaWtlIHRvIHByb3Bvc2UgYXMgdGhlIHBhdGggZm9yd2FyZCBpcyB0 aGlzOg0KDQogICogICBDaGFuZ2UgdGhlIG1hcHBpbmcgZG9jdW1lbnQgdG8gdXNlIHRoZSB0d28t c3RyZWFtcy1wZXItcmVxdWVzdCBtb2RlbCBkZXNjcmliZWQgaW4gZHJhZnQtYmlzaG9wLXF1aWMt aHR0cC1hbmQtcXBhY2s8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpc2hvcC1x dWljLWh0dHAtYW5kLXFwYWNrPiBzZWN0aW9uIDMuMSB3aXRoIHNvbWUgb2YgdGhlIGZyYW1lIHJl ZGVmaW5pdGlvbnMgZnJvbSBzZWN0aW9uIDMuMi4NCiAgKiAgIEF1Z21lbnQgaGVhZGVyLWJlYXJp bmcgZnJhbWVzIHdpdGggYSBzZXF1ZW5jZSBudW1iZXINCiAgKiAgIENvbnRpbnVlIHRvIHVzZSB1 bm1vZGlmaWVkIEhQQUNLIHdpdGggYSByZXF1aXJlbWVudCB0aGF0IGZyYW1lcyBiZSBmZWQgdG8g dGhlIGRlY29kZXIgaW4gb3JkZXIgZm9yIG5vdw0KDQpUaGlzIHNob3VsZCBwcm9kdWNlIG5vIHdv cnNlIGhlYWQtb2YtbGluZSBibG9ja2luZyB0aGFuIGN1cnJlbnRseSBleGlzdHMsIHJldXNlcyBl eGlzdGluZyBIUEFDSyBjb2RlLCBhbmQgbGV0cyB1cyBtYWtlIHByb2dyZXNzIG9uIHRoZSBjdXJy ZW50IGRyYWZ0LiAgSW4gcGFyYWxsZWwgYW5kIGFzIHdlIGhhdmUgcGVvcGxlIHRvIHdvcmsgb24g aXQsIHdlIGNhbiBkZWNpZGUgdG8gd2hhdCBleHRlbnQgd2Ugd2FudCB0byBtb2RpZnkgSFBBQ0sg dG8gcmVkdWNlIEhPTC1ibG9ja2luZyBpc3N1ZXMuICAoSeKAmWQgZW5jb3VyYWdlIEJ1Y2sgdG8g Z2VuZXJhdGUgYSBzaG9ydCBkcmFmdCBvbiBoaXMgaWRlYSBhcyB3ZWxsLCBzbyB3ZSBoYXZlIHR3 byBpZGVhcyB0byBjb21wYXJlLikNCg0KSeKAmWQgc3BlY2lmaWNhbGx5IGxpa2Ugb3BpbmlvbnMg ZnJvbSB0aGUgV0cgb24gd2hldGhlciB0aGF04oCZcyB0aGUgcGF0aCB3ZSB3YW50IHRvIG1vdmUg Zm9yd2FyZCB3aXRoLCBvciBpZiB0aGVyZeKAmXMgYW4gYWx0ZXJuYXRpdmUgSSBoYXZlbuKAmXQg aGVhcmQuICBJZiB0aGF04oCZcyBhY2NlcHRhYmxlIHRvIHRoZSBXRywgSeKAmWxsIHN0YXJ0IGEg cHVsbCByZXF1ZXN0IGZvciByZXZpZXcuDQoNCg0K --_000_BN6PR03MB2708FAF57F9276296D71A06987840BN6PR03MB2708namp_ 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 by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0MTU3OTAwMjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjEzNDAxMjIwMDg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0Nzg0OTc3 MDA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjY1MjI2Nzk4Mjt9DQpAbGlzdCBsMTpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiBzb21lIHBvc2l0 aXZlIGZlZWRiYWNrIGFuZCBubyBuZWdhdGl2ZSBzbyBmYXIsIEnigJltIGdvaW5nIHRvIGdvIGFo ZWFkIGFuZCBtZXJnZSB0aGlzLiZuYnNwOyBGZWVkYmFjayBjb250aW51ZXMgdG8gYmUgd2VsY29t ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YNCjwvYj5NaWtlIEJpc2hvcDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERl Y2VtYmVyIDUsIDIwMTYgMTo1MiBQTTxicj4NCjxiPlRvOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5z d2V0dEBnb29nbGUuY29tJmd0OzsgSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IEhUVFAgTWFwcGluZzogRml4aW5nIHN0cmVhbXMtaW4tc3RyZWFt czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZlIGNyZWF0ZWQg YSBwdWxsIHJlcXVlc3Qgd2l0aCB0aGUgZm9sbG93aW5nIHByb3Bvc2FsIGhlcmU6Jm5ic3A7DQo8 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzEiPmh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC83MTwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RmVlZGJhY2sgd2VsY29tZSwgYXMgYWx3YXlzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0IFs8YSBocmVmPSJtYWlsdG86aWFuc3dl dHRAZ29vZ2xlLmNvbSI+bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgNSwgMjAxNiAxMjozNiBQTTxicj4NCjxiPlRvOjwv Yj4gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBn b29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVm PSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWlj QGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IEhUVFAgTWFwcGluZzogRml4aW5nIHN0cmVhbXMtaW4tc3RyZWFtczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWdyZWVkLCBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBleGlzdGluZyBs ZXZlbCBvZiBIT0wgYmxvY2tpbmcgYW5kIGltcHJvdmluZyB1cG9uIGl0IHNlZW1zIHByYWN0aWNh bCwgc2luY2UgaXQgc2VlbXMgdmVyeSBsaWtlbHkgd2UnbGwgbW92ZSB0byB0aGUgdHdvLXN0cmVh bXMtcGVyLXJlcXVlc3QgbW9kZWwgbm8gbWF0dGVyIHdoYXQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIERlYyA1LCAyMDE2IGF0IDM6MjYgUE0s IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHdvcmssIE1pa2UuIEkgbGlrZSB0aGlz IGFwcHJvYWNoIC0tIGl0J3MgYSBncmVhdCB3YXkgdG8gc2VwYXJhdGUgdGhlIGhlYWRlciBjb21w cmVzc2lvbiBpc3N1ZSBmcm9tIHRoZSBpc3N1ZSBvZiBhIGNsZWFuIG1hcHBpbmcgb2YgSFRUUCBo ZWFkZXJzL2RhdGEgdG8gUVVJQyBzdHJlYW1zLiBJIHRoaW5rIHdlIHNob3VsZCBkaXNjdXNzIHRo ZSBIVFRQIHRvIFFVSUMgc3RyZWFtIG1hcHBpbmcNCiBwcm9wb3NhbCB5b3UndmUgb3V0bGluZWQs IGJ1dCBzaG91bGQgd2UgZG8gdGhhdCBvbiBhbiBpc3N1ZT8gT3IgYSBzZXBhcmF0ZSB0aHJlYWQ/ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GV0lXLCBJIGxp a2UgdGhpcyBtYXBwaW5nIGFwcHJvYWNoLCB3aGVyZSBIVFRQIGhlYWRlcnMgYW5kIGJvZHkgYXJl IG1hcHBlZCB0byBhIHN0cmVhbS1wYWlyLiBBcyBJJ3ZlIG5vdGVkIGVhcmxpZXIsIFFVSUMncyBz dHJlYW1zIGFyZSBlcGhlbWVyYWwgYW5kIHNob3VsZCBiZSBsaWdodHdlaWdodCwgd2hpY2ggbWVh bnMgdGhhdCB0aGV5IGNhbiBiZSB1c2VkIGluc3RlYWQgb2YgYnVpbGRpbmcgYSBuZXcgZnJhbWlu Zw0KIGZvcm1hdCBmb3IgSFRUUCBoZWFkZXJzIHZzIGJvZHkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IERlYyAxLCAyMDE2IGF0IDM6MzUgUE0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGhhdmUgdGhlIGV4aXN0aW5nIGRvY3VtZW50IHdoaWNo IHB1dHMgZXZlcnl0aGluZyBvbiBhIHNpbmdsZSBzdHJlYW0gYW5kIHJldGFpbnMgSFRUUC8yIGZy YW1pbmcuJm5ic3A7IEF0IHRoZSBXRyBtZWV0aW5nLCBJIGhlYXJkIHN1YnN0YW50aWFsIGRlc2ly ZSB0byBtb3ZlIGFzIG11Y2ggYXMgcG9zc2libGUgb2ZmDQogdG8gc2VwYXJhdGUgc3RyZWFtcyBw ZXIgcmVxdWVzdC4mbmJzcDsgVGhlcmUgd2FzIGFsc28gZGlzY3Vzc2lvbiBhYm91dCBob3cgdG8g bW9kaWZ5IEhQQUNLIChCdWNrIGhhcyBhIHByb3Bvc2FsIHZpYSBlLW1haWw7IEkgaGF2ZSBhIGRy YWZ0KSB0byBlbmFibGUgdGhpcywgYnV0IGZyb20gc2lkZSBjb252ZXJzYXRpb25zLCBJIHRoaW5r IHRoZXJl4oCZcyBhbHNvIGEgZGVzaXJlIHRvIHJldXNlIEhQQUNLIGNvZGUgd2hlcmUgcG9zc2li bGUgYW5kIG1pbmltaXplDQogY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldo YXQgSeKAmWQgbGlrZSB0byBwcm9wb3NlIGFzIHRoZSBwYXRoIGZvcndhcmQgaXMgdGhpczo8bzpw PjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KQ2hhbmdlIHRoZSBtYXBwaW5nIGRvY3VtZW50IHRvIHVz ZSB0aGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVlc3QgbW9kZWwgZGVzY3JpYmVkIGluDQo8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQt cXBhY2siIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNr PC9hPiBzZWN0aW9uIDMuMSB3aXRoIHNvbWUgb2YgdGhlIGZyYW1lIHJlZGVmaW5pdGlvbnMgZnJv bSBzZWN0aW9uIDMuMi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpBdWdtZW50IGhlYWRlci1iZWFyaW5nIGZyYW1lcyB3aXRo IGEgc2VxdWVuY2UgbnVtYmVyPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KQ29udGludWUgdG8gdXNlIHVubW9kaWZpZWQgSFBB Q0sgd2l0aCBhIHJlcXVpcmVtZW50IHRoYXQgZnJhbWVzIGJlIGZlZCB0byB0aGUgZGVjb2RlciBp biBvcmRlciBmb3Igbm93PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHNo b3VsZCBwcm9kdWNlIG5vIHdvcnNlIGhlYWQtb2YtbGluZSBibG9ja2luZyB0aGFuIGN1cnJlbnRs eSBleGlzdHMsIHJldXNlcyBleGlzdGluZyBIUEFDSyBjb2RlLCBhbmQgbGV0cyB1cyBtYWtlIHBy b2dyZXNzIG9uIHRoZSBjdXJyZW50IGRyYWZ0LiZuYnNwOyBJbiBwYXJhbGxlbCBhbmQgYXMgd2Ug aGF2ZQ0KIHBlb3BsZSB0byB3b3JrIG9uIGl0LCB3ZSBjYW4gZGVjaWRlIHRvIHdoYXQgZXh0ZW50 IHdlIHdhbnQgdG8gbW9kaWZ5IEhQQUNLIHRvIHJlZHVjZSBIT0wtYmxvY2tpbmcgaXNzdWVzLiZu YnNwOyAoSeKAmWQgZW5jb3VyYWdlIEJ1Y2sgdG8gZ2VuZXJhdGUgYSBzaG9ydCBkcmFmdCBvbiBo aXMgaWRlYSBhcyB3ZWxsLCBzbyB3ZSBoYXZlIHR3byBpZGVhcyB0byBjb21wYXJlLik8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJlkIHNwZWNpZmljYWxseSBsaWtlIG9waW5pb25zIGZy b20gdGhlIFdHIG9uIHdoZXRoZXIgdGhhdOKAmXMgdGhlIHBhdGggd2Ugd2FudCB0byBtb3ZlIGZv cndhcmQgd2l0aCwgb3IgaWYgdGhlcmXigJlzIGFuIGFsdGVybmF0aXZlIEkgaGF2ZW7igJl0IGhl YXJkLiZuYnNwOyBJZiB0aGF04oCZcyBhY2NlcHRhYmxlIHRvIHRoZSBXRywNCiBJ4oCZbGwgc3Rh cnQgYSBwdWxsIHJlcXVlc3QgZm9yIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708FAF57F9276296D71A06987840BN6PR03MB2708namp_-- From nobody Thu Dec 8 09:58:36 2016 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 4815A1295F0 for ; Thu, 8 Dec 2016 09:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 alLS5VSTG7vD for ; Thu, 8 Dec 2016 09:58:31 -0800 (PST) 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 7F4EA127058 for ; Thu, 8 Dec 2016 09:58:31 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id h30so13391505iod.2 for ; Thu, 08 Dec 2016 09:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bJ6HfrbflM9MJ5VOGRBYj+qYaHETshZMBRdS17iWKCo=; b=RbScQsGiazapMkpiDTmy0/Y+Vcq70ts8TyrdhxZGX5L/1PlfXEfUkDLuYxvSzcZ4Cf fMvM9pxSJaCEOL2svSY38nFNlGyhNySYpjVcIKlgaGTWlxmCO8HcLUIT9wf7gV3EPCiv PrKfw9n2ehlVrF+rpRzaWzKhVXH4R/lZvhqTk/TS9/oSuuNuFsKs9w9m7ifFYuhsYPzZ rb3TzAhorHtkKv/oh6k6B8GjCCCp2mCcVLZz9w7GbPoM5UPg1qrRRTr5yLLHiUgevr6s 5DfN0xvZO2wpD9kZUjaENjdGD52dFAhTRbbkaTSID9/bIKBwFuAYcH8+4V/RTYlNMaaS rIzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bJ6HfrbflM9MJ5VOGRBYj+qYaHETshZMBRdS17iWKCo=; b=XpSoeR5MlE6Bm033TylC2fDf15N7F5lxLuDKP7f58pl3bCpqv5jXxG1xn7jf2+b/bh AIVe+hD2lK1QQpx2USFiscYMdFftje5ChsQW1KM4JQrPI3/DzBS/Nb4l48AWypm3urEV HISC1nCL3h8Z4bjAk/ZC1RoA7PDotDdN9YD2qXSfF2qg7zN3rzSuLBd9QjTZcf/AhSSW 8IcBDchPcj7QN/omOqKpyO4tcPEUvWb5bEPuJM61J04nohJLnki1BaH0XnRwAXSAPo0A xsqTjJgkSKSRwTQVaX4LNqymA0RlQlPXoOooyj3+qvjLGfoJdtQ5Twy/qw3ox2l+aNHO 1xWA== X-Gm-Message-State: AKaTC03hVg1Fen1kJ8ghZg9oL+F+SIKapYJXsgkF8V6HTe5f0EqCAfNXN66wbeP5F0edhA9QmjX+WVGfiH3JcH/O X-Received: by 10.107.35.147 with SMTP id j141mr14134951ioj.41.1481219909621; Thu, 08 Dec 2016 09:58:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.67 with HTTP; Thu, 8 Dec 2016 09:58:08 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Thu, 8 Dec 2016 09:58:08 -0800 Message-ID: Subject: Re: HTTP Mapping: Fixing streams-in-streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a114041f48c68a4054329622a Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 08 Dec 2016 17:58:34 -0000 --001a114041f48c68a4054329622a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One question I have. The text refers to the control data streams being exempt from flow control. In our deployment, headers are exempt from the connection level flow control, but stream level flow control still applies. Is the full exemption intentional? Beyond that, I'm interested to know more of the rationale behind flow control. Tidbits I've heard are not very satisfactory to me, it seems like priorities (which are not fully baked for QUIC yet) would be the more appropriate mechanism. On Thu, Dec 8, 2016 at 9:52 AM, Mike Bishop wrote: > Given some positive feedback and no negative so far, I=E2=80=99m going to= go ahead > and merge this. Feedback continues to be welcome. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mike Bishop > *Sent:* Monday, December 5, 2016 1:52 PM > *To:* Ian Swett ; Jana Iyengar > *Cc:* IETF QUIC WG > *Subject:* RE: HTTP Mapping: Fixing streams-in-streams > > > > I=E2=80=99ve created a pull request with the following proposal here: > https://github.com/quicwg/base-drafts/pull/71 > > > > Feedback welcome, as always. > > > > *From:* Ian Swett [mailto:ianswett@google.com ] > *Sent:* Monday, December 5, 2016 12:36 PM > *To:* Jana Iyengar > *Cc:* Mike Bishop ; IETF QUIC WG < > quic@ietf.org> > *Subject:* Re: HTTP Mapping: Fixing streams-in-streams > > > > Agreed, moving forward with the existing level of HOL blocking and > improving upon it seems practical, since it seems very likely we'll move = to > the two-streams-per-request model no matter what. > > > > On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar wrote: > > Thanks for the work, Mike. I like this approach -- it's a great way to > separate the header compression issue from the issue of a clean mapping o= f > HTTP headers/data to QUIC streams. I think we should discuss the HTTP to > QUIC stream mapping proposal you've outlined, but should we do that on an > issue? Or a separate thread? > > > > FWIW, I like this mapping approach, where HTTP headers and body are mappe= d > to a stream-pair. As I've noted earlier, QUIC's streams are ephemeral and > should be lightweight, which means that they can be used instead of > building a new framing format for HTTP headers vs body. > > > > > > On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop > wrote: > > We have the existing document which puts everything on a single stream an= d > retains HTTP/2 framing. At the WG meeting, I heard substantial desire to > move as much as possible off to separate streams per request. There was > also discussion about how to modify HPACK (Buck has a proposal via e-mail= ; > I have a draft) to enable this, but from side conversations, I think > there=E2=80=99s also a desire to reuse HPACK code where possible and mini= mize > changes. > > > > What I=E2=80=99d like to propose as the path forward is this: > > - Change the mapping document to use the two-streams-per-request model > described in draft-bishop-quic-http-and-qpack > section > 3.1 with some of the frame redefinitions from section 3.2. > - Augment header-bearing frames with a sequence number > - Continue to use unmodified HPACK with a requirement that frames be > fed to the decoder in order for now > > > > This should produce no worse head-of-line blocking than currently exists, > reuses existing HPACK code, and lets us make progress on the current > draft. In parallel and as we have people to work on it, we can decide to > what extent we want to modify HPACK to reduce HOL-blocking issues. (I=E2= =80=99d > encourage Buck to generate a short draft on his idea as well, so we have > two ideas to compare.) > > > > I=E2=80=99d specifically like opinions from the WG on whether that=E2=80= =99s the path we > want to move forward with, or if there=E2=80=99s an alternative I haven= =E2=80=99t heard. > If that=E2=80=99s acceptable to the WG, I=E2=80=99ll start a pull request= for review. > > > > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a114041f48c68a4054329622a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One question I have.=C2=A0 The text refers to the control = data streams being exempt from flow control.=C2=A0 In our deployment, heade= rs are exempt from the connection level flow control, but stream level flow= control still applies. =C2=A0 Is the full exemption intentional?

<= /div>
Beyond that, I'm interested to know more of the rationale beh= ind flow control.=C2=A0 Tidbits I've heard are not very satisfactory to= me, it seems like priorities (which are not fully baked for QUIC yet) woul= d be the more appropriate mechanism.
=
On Thu, Dec 8, 2016 at 9:52 AM, Mike Bishop = <Michael.Bishop@microsoft.com> wrote:

Given some positive feedback and no negative so far,= I=E2=80=99m going to go ahead and merge this.=C2=A0 Feedback continues to = be welcome.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop
Sent: Monday, December 5, 2016 1:52 PM
To: Ian Swett <ianswett@google.com>; Jana Iyengar <jri@google.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: RE: HTTP Mapping: Fixing streams-in-streams

=C2=A0

I=E2=80=99ve created a pull request with the followi= ng proposal here:=C2=A0 https://github.com/quicwg/base-drafts/pull/71

=C2=A0

Feedback welcome, as always.

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Monday, December 5, 2016 12:36 PM
To: Jana Iyengar <jri@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG &= lt;quic@ietf.org>=
Subject: Re: HTTP Mapping: Fixing streams-in-streams

=C2=A0

Agreed, moving forward with the existing level of HO= L blocking and improving upon it seems practical, since it seems very likel= y we'll move to the two-streams-per-request model no matter what.

=C2=A0

On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar <jri@google.com> wro= te:

Thanks for the work, Mike. I like this approach -- i= t's a great way to separate the header compression issue from the issue= of a clean mapping of HTTP headers/data to QUIC streams. I think we should= discuss the HTTP to QUIC stream mapping proposal you've outlined, but should we do that on an issue? Or a sepa= rate thread?

=C2=A0

FWIW, I like this mapping approach, where HTTP heade= rs and body are mapped to a stream-pair. As I've noted earlier, QUIC= 9;s streams are ephemeral and should be lightweight, which means that they = can be used instead of building a new framing format for HTTP headers vs body.

=C2=A0

=C2=A0

On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

We have the existing document which puts everything = on a single stream and retains HTTP/2 framing.=C2=A0 At the WG meeting, I h= eard substantial desire to move as much as possible off to separate streams per request.=C2=A0 There was also discussion about how= to modify HPACK (Buck has a proposal via e-mail; I have a draft) to enable= this, but from side conversations, I think there=E2=80=99s also a desire t= o reuse HPACK code where possible and minimize changes.

=C2=A0

What I=E2=80=99d like to propose as the path forward= is this:

  • Change the mapping document to use the two-streams-per-request model descri= bed in draft-bishop-quic-http-and-qpack section 3.1 with some of the fram= e redefinitions from section 3.2.
  • Augment header-bearing frames with a sequence number
  • Continue to use unmodified HPACK with a requirement that frames be fed to t= he decoder in order for now

=C2=A0

This should produce no worse head-of-line blocking t= han currently exists, reuses existing HPACK code, and lets us make progress= on the current draft.=C2=A0 In parallel and as we have people to work on it, we can decide to what extent we want to modify HPACK= to reduce HOL-blocking issues.=C2=A0 (I=E2=80=99d encourage Buck to genera= te a short draft on his idea as well, so we have two ideas to compare.)<= /u>

=C2=A0

I=E2=80=99d specifically like opinions from the WG o= n whether that=E2=80=99s the path we want to move forward with, or if there= =E2=80=99s an alternative I haven=E2=80=99t heard.=C2=A0 If that=E2=80=99s = acceptable to the WG, I=E2=80=99ll start a pull request for review.

=C2=A0

=C2=A0




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--001a114041f48c68a4054329622a-- From nobody Thu Dec 8 11:30:24 2016 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 5AA29129556 for ; Thu, 8 Dec 2016 11:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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_LOW=-0.7, 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 SsBrrEVJxbgF for ; Thu, 8 Dec 2016 11:30:21 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 E2CC51295FC for ; Thu, 8 Dec 2016 11:30:20 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id i88so84562857pfk.2 for ; Thu, 08 Dec 2016 11:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=NpFOwXeFyhsTds6h8BRSV1UaYyMus7xJN6NvjSoJ2GY=; b=CFF1s4EKlcbO6ojty+1BfAft3lCLH9eucjlzo9u6r7kaPNI3K59KM9wWva7qyX4s+J GDRySg8qOGoFfIdhgyQHNDWAs+PRYR5JZ/o3Ks+wXfE20G2wmt5/vyMbHrAlY4Z+ZxOG o6XH/Um5G1QQsY/pJqZ3j0x3+Z741rWXV/YfRH8mWdmcQdtmzVCISKusSLK8dr43r8u4 vNVSG9Y29V9Od7uFGWL2z6U/xFrQHZSWZvVvBOPDW3KvYuzYX5kc2XuGlp/U+rOy71lR TeW7ZzFKemRkv9DV0UsER26Q8J5H5bpLFjgY570aIYKckOJK+VomrnAOBMmr+IGWtZpj bfZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NpFOwXeFyhsTds6h8BRSV1UaYyMus7xJN6NvjSoJ2GY=; b=BaDZ8e5EzWKxB1awmHNqqctdsV5Jdo5VHrPbiAcJkMwkQusQP3wFFnNoqW/dEiKzGn SJGamW4Rmhb50hnQs9DB6ssPrpH/Nfmzs1ZW6/FOWs84TTISZDWVyfNG0HIqAgaRZodO 2YZ4bs7acLWDLrz6uty/tMuZNyokBUvW0s0p7Fn1YIeLPUsw1g7cbqXIz1dAdqE9/WyH 8Ut5v6bp4dFX9pyyAfSDQQ9ftDfTHgjfTmzboMZYHV8WGL8Tk8Cw2zXWoa/8Pc9AHat7 UHOvFh2t6sdjVonDRUuMKSeSOmM9XU3BKQ6ogmgVB4bnG7nH6XJBJXfdbHLds7DLpEun J3LA== X-Gm-Message-State: AKaTC038FpWiH0X1D1EZAXdOpxEHeoKKUOBrhbnI4exsd/d9+ovozkkoRMVp428HifvzZg== X-Received: by 10.99.227.81 with SMTP id o17mr134926102pgj.69.1481225420515; Thu, 08 Dec 2016 11:30:20 -0800 (PST) Received: from [10.192.173.48] (stargate.chelsio.com. [12.32.117.8]) by smtp.gmail.com with ESMTPSA id x4sm52256730pgc.14.2016.12.08.11.30.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 11:30:20 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A8C3B3FB-570F-453E-8FC0-75B6A146E83D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Comments on draft-ietf-quic-transport-00 From: Asgeir Eiriksson In-Reply-To: Date: Thu, 8 Dec 2016 11:30:19 -0800 Message-Id: References: To: "Aron ." X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 08 Dec 2016 19:30:22 -0000 --Apple-Mail=_A8C3B3FB-570F-453E-8FC0-75B6A146E83D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 30, 2016, at 10:00 PM, Aron . wrote: >=20 > On Thu, Dec 1, 2016 at 12:41 AM, Martin Duke > wrote:=20 > Section 6. Frame Formats. Another broad comment: one common task will = be take a piece of a packet corresponding to a frame and passing it into = some handling function. Similarly, we would want some basic sanity = checks on frame length (i.e. <=3D remaining packet length) before = starting processing. It would be helpful if it were easy to parse the = first few bytes of the frame to find its length. Length computation = requires reading the flags, and sometimes checking additional fields = that are variable lengths from the start of the frame. This is very = cumbersome to implement. If you're trying in plain old C, as I am, the = macros are horrendous. >=20 > Have the frame handling function return the number of bytes it = consumed or -1 on error. >=20 > Aron. >=20 The length field is optional see Section 6.1 The =E2=80=99D=E2=80=99 bit = indicates whether a Data Length field is present in the STREAM header It might be helpful to contrast the above sw implementation discussion = and a hw implementation=20 If the packet parsing is happening in hw e.g. NIC then there are = 8B/16B/32B to be processed/parsed per clock cycle, and if the processing = is proceeding in cut-through mode (which is typical), the Ethernet CRC, = the UDP checksum check, and QUIC parsing, etc. are all happening at the = same time, and then the various error flags are gathered up after the = end of the packet, and the packet either dropped, or processed further, = or handed off to sw I=E2=80=99m new to QUIC and it is not clear to me if the QUIC use = case(s) extend to 10Gbps and 100Gbps implied by the 16B and 32B above = (which are used in 10Gbps and 100Gbps TCP processing designs) =E2=80=98Asgeir --Apple-Mail=_A8C3B3FB-570F-453E-8FC0-75B6A146E83D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 30, 2016, at 10:00 PM, Aron . <aron.schats@gmail.com> wrote:

On Thu, Dec 1, = 2016 at 12:41 AM, Martin Duke <martin.h.duke@gmail.com> wrote: 
Section 6. Frame Formats. Another broad = comment: one common task will be take a piece of a packet corresponding = to a frame and passing it into some handling function. Similarly, we = would want some basic sanity checks on frame length (i.e. <=3D = remaining packet length) before starting processing. It would be helpful = if it were easy to parse the first few bytes of the frame to find its = length. Length computation requires reading the flags, and sometimes = checking additional fields that are variable lengths from the start of = the frame. This is very cumbersome to implement. If you're trying in = plain old C, as I am, the macros are horrendous.

Have the frame handling function return the = number of bytes it consumed or -1 on error.

  Aron.


The length field is optional see Section = 6.1 The =E2=80=99D=E2=80=99 bit indicates whether a Data = Length field is present in the STREAM = header

It might be = helpful to contrast the above sw implementation discussion and a = hw implementation 

If the packet = parsing is happening in hw e.g. NIC then there are 8B/16B/32B to be = processed/parsed per clock cycle, and if the processing is proceeding in = cut-through mode (which is typical), the Ethernet CRC, the UDP checksum = check, and QUIC parsing, etc. are all happening at the same time, and = then the various error flags are gathered up after the end of the = packet, and the packet either dropped, or processed further, or = handed off to sw

I=E2=80=99m new to QUIC and it is = not clear to me if the QUIC use case(s) extend to 10Gbps and 100Gbps = implied by the 16B and 32B above (which are used in 10Gbps and 100Gbps = TCP processing designs)

=E2=80=98Asgeir


= --Apple-Mail=_A8C3B3FB-570F-453E-8FC0-75B6A146E83D-- From nobody Thu Dec 8 12:13:05 2016 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 EDF0B12896F for ; Thu, 8 Dec 2016 12:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 KFnVjDpNuP3B for ; Thu, 8 Dec 2016 12:13:00 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0095.outbound.protection.outlook.com [104.47.41.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B82129456 for ; Thu, 8 Dec 2016 12:12:59 -0800 (PST) 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; bh=ZiLcxQArnpzO8hpqojuJ664LxuSG6heqagt1GJ71BdQ=; b=bu+8aSF1IS6NbI1b2FVf+mjwWAG+tSEMtiqgMffnHLctCR4dGtexg3xqhVugL5KP089rfK49tXWDJk7w076icLVwQ3BMELCX8b1X4olK2Z6bMbRrLDFA+6LyZNoIYTG3opnVFhb5BpaxdI9vvpQTY6E+/wwk8ZcZnMQUHfyjeyw= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 8 Dec 2016 20:12:56 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.021; Thu, 8 Dec 2016 20:12:56 +0000 From: Mike Bishop To: Charles 'Buck' Krasic Subject: RE: HTTP Mapping: Fixing streams-in-streams Thread-Topic: HTTP Mapping: Fixing streams-in-streams Thread-Index: AdJMK4UPnpRSHPYRT8al2LR5lm7ZTwDCknSAAABZHIAAASvckACPyzDQAABklQAABDe1kA== Date: Thu, 8 Dec 2016 20:12:55 +0000 Message-ID: References: In-Reply-To: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:b::51f] x-ms-office365-filtering-correlation-id: 5680b689-1d13-4f8c-aa81-08d41fa69936 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:Cgf+g0BqSz2SRogsTdJ6SQ4qPxUgpEqmBG4Xhng3plsp6EiJsHQRovO3Sy3jUQabJYFd5wTgAGkD3naygvbDrDMEMSmyRmpH+BkoUGmTnDTv6P00FGsEh/TWrdE8y3zC6pOTysg7/cM7dS3/4UYeja4vsGxqaP+dGUQ9RJM77dzworQvkncXR3fpek9QfYHL/5MQAJSoGI2pXlIcYgPgKXUDVXyHs5HLakXrtbA3mujEDgzVH8X7Yd/af0CVzKfwaChTyyEHinYJ3JDng9VUCcxAK/YOO9ILrXODmamNvN7QlZKGf47igrUY9s6yaKs6LIcrCVsEKO6fsKXebtwTNNXxBirnC3IU5hmmgRyNUeZSbYn5fIv67uxEW2VijsLVAmT7nzt+yKPluBqEFqmeYD/lPn05VRN0yEbIZA5B7r69mAi7w7yfx5WEtMb3u8xY741CzkCDMoaU/qrl+UTGe7XKx2lO7x/KSMeFyh5JUN4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(189002)(24454002)(51914003)(377454003)(199003)(105586002)(76176999)(54356999)(50986999)(110136003)(5660300001)(7696004)(99286002)(6916009)(2950100002)(6436002)(68736007)(122556002)(790700001)(6116002)(102836003)(4326007)(230783001)(106356001)(2906002)(76576001)(93886004)(189998001)(81166006)(86612001)(8676002)(7736002)(8936002)(74316002)(7906003)(33656002)(561944003)(3660700001)(3280700002)(81156014)(2900100001)(101416001)(9686002)(97736004)(92566002)(19609705001)(38730400001)(8990500004)(86362001)(10290500002)(77096006)(606004)(229853002)(10090500001)(6506006)(5005710100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708BB50674E470BDBE0108487840BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 20:12:55.7578 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 08 Dec 2016 20:13:04 -0000 --_000_BN6PR03MB2708BB50674E470BDBE0108487840BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhY3R1YWxseSBkaWQgdXBkYXRlIHRoZSB0ZXh0IHRvIHNwZWNpZnkg4oCcY29ubmVjdGlvbi1s ZXZlbCzigJ0gc2luY2UgdGhhdOKAmXMgd2hhdCB0aGUgdHJhbnNwb3J0IGRyYWZ0IGFsbG93cyB0 aGUgYXBwbGljYXRpb24gdG8gZG8uICBJbiBIVFRQLzIsIG9ubHkgREFUQSBmcmFtZXMgYXJlIGZs b3ctY29udHJvbGxlZCBhdCBhbGwsIGEgc3ViamVjdCBvZiBzb21lIGRlYmF0ZSBpbiB0aGUgSFRU UCBXRyBhdCB0aGUgdGltZS4NCg0KVGhlIHJhdGlvbmFsZSBlaXRoZXIgd2F5IGlzIHRoYXQgcGF5 bG9hZCBvbiB0aGUgY29udHJvbCBzdHJlYW1zIGlzIGJlaW5nIGNvbnN1bWVkIGJ5IHRoZSBwcm90 b2NvbCBpbXBsZW1lbnRhdGlvbiBpdHNlbGYsIG5vdCBieSBzb21ldGhpbmcgYWJvdmUgaXQsIHNv IHRob3NlIHNob3VsZCBmbG93IHVuaW1wZWRlZCBhbmQgY2FuIGJlIHRydXN0ZWQgdG8gcmVhZCBh bmQgcHJvY2VzcyBwcm9tcHRseSwgYnVncyBub3R3aXRoc3RhbmRpbmcuICBUaGVyZSBhcmUgb3Ro ZXIgZ3VhcmRzIGFnYWluc3QgYW4gYWJ1c2l2ZSBwZWVyOiAgSWYgdGhlIHBlZXIgb3BlbnMgdG9v IG1hbnkgc3RyZWFtcyB0aGV54oCZbGwgcHJvZHVjZSBhIHZpb2xhdGlvbiBhdCB0aGUgUVVJQyBs YXllciwgYW5kIHlvdSBoYXZlIHRoZSBvcHRpb24gb2YgcHV0dGluZyBhIHNtYWxsZXIgcGVyLXN0 cmVhbSBmbG93IGNvbnRyb2wgd2luZG93IHRvIGJlZ2luIHdpdGguDQoNCkZsb3cgY29udHJvbCBh bmQgcHJpb3JpdHkgYXJlIHJlbGF0ZWQsIGJ1dCBzZXJ2ZSBkaWZmZXJlbnQgcHVycG9zZXMuICBG bG93IGNvbnRyb2wgbGltaXRzIGhvdyBtdWNoIHVucHJvY2Vzc2VkIGRhdGEgSSBoYXZlIHNpdHRp bmcgYXJvdW5kLCB3aGlsZSBwcmlvcml0eSBkaWN0YXRlcyBob3cgSSBzaG91bGQgYWxsb2NhdGUg YSBzY2FyY2UgcmVzb3VyY2UgKHdoZXRoZXIgdGhhdOKAmXMgcHJvY2Vzc2luZyB0aW1lIG9yIGJh bmR3aWR0aCBvbiB0aGUgcmV0dXJuIGRpcmVjdGlvbikuICBBIHRoaWNrIGNsaWVudCB3aWxsIHZl cnkgcmFyZWx5IHdhbnQgdG8gZmxvdy1jb250cm9sIHRoZSBzZXJ2ZXIg4oCTIGluIHByYWN0aWNl LCB0aGV5IG9wZW4gdGhlIHdpbmRvd3MgYXMgd2lkZSBhcyBwb3NzaWJsZSBhbmQgdXNlIHByaW9y aXR5LCBhcyB5b3Ugc3VnZ2VzdC4gIFRoZSBzZXJ2ZXIsIG9uIHRoZSBvdGhlciBoYW5kLCB3YW50 cyB0byBjYXJlZnVsbHkgYm91bmQgbWVtb3J5IGFsbG9jYXRpb25zIHBlciBjb25uZWN0aW9uIOKA kyBlc3BlY2lhbGx5IHdoZXJlIHRoZSBhcHBsaWNhdGlvbiBhY3R1YWxseSBjb25zdW1pbmcgdGhl IGRhdGEgaXNu4oCZdCBmdWxseSByZWxpYWJsZSBmcm9tIHRoZSBwcm90b2NvbCBpbXBsZW1lbnRh dGlvbuKAmXMgcG9pbnQgb2Ygdmlldy4gIEZsb3cgY29udHJvbCBhbGxvd3MgdW5yZWFkIGRhdGEg Zmxvd2luZyB1cHN0cmVhbSB0byBiZSBoZWxkIGF0IHRoZSBjbGllbnQsIHJhdGhlciB0aGFuIGlu IHRoZSBzZXJ2ZXLigJlzIGxpbWl0ZWQgbWVtb3J5LCB3aGVuIHRoZSBhcHBsaWNhdGlvbiBpcyBz bG93IHRvIGNvbnN1bWUgdGhlIGRhdGEuICBOb24tYnJvd3NlciBjbGllbnRzIG9mdGVuIGZpbmQg dGhlbXNlbHZlcyBpbiB0aGUgc2FtZSBwb3NpdGlvbiBvZiBuZWVkaW5nIHRvIGJvdW5kIG1lbW9y eSB1c2VkIGZvciB0aGUgY29ubmVjdGlvbi4NCg0KRnJvbTogQ2hhcmxlcyAnQnVjaycgS3Jhc2lj IFttYWlsdG86Y2tyYXNpY0Bnb29nbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDgs IDIwMTYgOTo1OCBBTQ0KVG86IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tPg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IEphbmEgSXllbmdhciA8 anJpQGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogSFRUUCBNYXBwaW5nOiBGaXhpbmcgc3RyZWFtcy1pbi1zdHJlYW1zDQoNCk9uZSBxdWVzdGlv biBJIGhhdmUuICBUaGUgdGV4dCByZWZlcnMgdG8gdGhlIGNvbnRyb2wgZGF0YSBzdHJlYW1zIGJl aW5nIGV4ZW1wdCBmcm9tIGZsb3cgY29udHJvbC4gIEluIG91ciBkZXBsb3ltZW50LCBoZWFkZXJz IGFyZSBleGVtcHQgZnJvbSB0aGUgY29ubmVjdGlvbiBsZXZlbCBmbG93IGNvbnRyb2wsIGJ1dCBz dHJlYW0gbGV2ZWwgZmxvdyBjb250cm9sIHN0aWxsIGFwcGxpZXMuICAgSXMgdGhlIGZ1bGwgZXhl bXB0aW9uIGludGVudGlvbmFsPw0KDQpCZXlvbmQgdGhhdCwgSSdtIGludGVyZXN0ZWQgdG8ga25v dyBtb3JlIG9mIHRoZSByYXRpb25hbGUgYmVoaW5kIGZsb3cgY29udHJvbC4gIFRpZGJpdHMgSSd2 ZSBoZWFyZCBhcmUgbm90IHZlcnkgc2F0aXNmYWN0b3J5IHRvIG1lLCBpdCBzZWVtcyBsaWtlIHBy aW9yaXRpZXMgKHdoaWNoIGFyZSBub3QgZnVsbHkgYmFrZWQgZm9yIFFVSUMgeWV0KSB3b3VsZCBi ZSB0aGUgbW9yZSBhcHByb3ByaWF0ZSBtZWNoYW5pc20uDQoNCk9uIFRodSwgRGVjIDgsIDIwMTYg YXQgOTo1MiBBTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFp bHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkdpdmVuIHNvbWUgcG9z aXRpdmUgZmVlZGJhY2sgYW5kIG5vIG5lZ2F0aXZlIHNvIGZhciwgSeKAmW0gZ29pbmcgdG8gZ28g YWhlYWQgYW5kIG1lcmdlIHRoaXMuICBGZWVkYmFjayBjb250aW51ZXMgdG8gYmUgd2VsY29tZS4N Cg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE1pa2UgQmlzaG9wDQpTZW50OiBNb25kYXks IERlY2VtYmVyIDUsIDIwMTYgMTo1MiBQTQ0KVG86IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xl LmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29n bGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBIVFRQIE1hcHBpbmc6 IEZpeGluZyBzdHJlYW1zLWluLXN0cmVhbXMNCg0KSeKAmXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVl c3Qgd2l0aCB0aGUgZm9sbG93aW5nIHByb3Bvc2FsIGhlcmU6ICBodHRwczovL2dpdGh1Yi5jb20v cXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzENCg0KRmVlZGJhY2sgd2VsY29tZSwgYXMgYWx3YXlz Lg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDog TW9uZGF5LCBEZWNlbWJlciA1LCAyMDE2IDEyOjM2IFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlA Z29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+Pg0KQ2M6IE1pa2UgQmlzaG9wIDxNaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogSFRUUCBNYXBwaW5nOiBGaXhpbmcgc3RyZWFtcy1pbi1zdHJlYW1zDQoN CkFncmVlZCwgbW92aW5nIGZvcndhcmQgd2l0aCB0aGUgZXhpc3RpbmcgbGV2ZWwgb2YgSE9MIGJs b2NraW5nIGFuZCBpbXByb3ZpbmcgdXBvbiBpdCBzZWVtcyBwcmFjdGljYWwsIHNpbmNlIGl0IHNl ZW1zIHZlcnkgbGlrZWx5IHdlJ2xsIG1vdmUgdG8gdGhlIHR3by1zdHJlYW1zLXBlci1yZXF1ZXN0 IG1vZGVsIG5vIG1hdHRlciB3aGF0Lg0KDQpPbiBNb24sIERlYyA1LCAyMDE2IGF0IDM6MjYgUE0s IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4gd3Jv dGU6DQpUaGFua3MgZm9yIHRoZSB3b3JrLCBNaWtlLiBJIGxpa2UgdGhpcyBhcHByb2FjaCAtLSBp dCdzIGEgZ3JlYXQgd2F5IHRvIHNlcGFyYXRlIHRoZSBoZWFkZXIgY29tcHJlc3Npb24gaXNzdWUg ZnJvbSB0aGUgaXNzdWUgb2YgYSBjbGVhbiBtYXBwaW5nIG9mIEhUVFAgaGVhZGVycy9kYXRhIHRv IFFVSUMgc3RyZWFtcy4gSSB0aGluayB3ZSBzaG91bGQgZGlzY3VzcyB0aGUgSFRUUCB0byBRVUlD IHN0cmVhbSBtYXBwaW5nIHByb3Bvc2FsIHlvdSd2ZSBvdXRsaW5lZCwgYnV0IHNob3VsZCB3ZSBk byB0aGF0IG9uIGFuIGlzc3VlPyBPciBhIHNlcGFyYXRlIHRocmVhZD8NCg0KRldJVywgSSBsaWtl IHRoaXMgbWFwcGluZyBhcHByb2FjaCwgd2hlcmUgSFRUUCBoZWFkZXJzIGFuZCBib2R5IGFyZSBt YXBwZWQgdG8gYSBzdHJlYW0tcGFpci4gQXMgSSd2ZSBub3RlZCBlYXJsaWVyLCBRVUlDJ3Mgc3Ry ZWFtcyBhcmUgZXBoZW1lcmFsIGFuZCBzaG91bGQgYmUgbGlnaHR3ZWlnaHQsIHdoaWNoIG1lYW5z IHRoYXQgdGhleSBjYW4gYmUgdXNlZCBpbnN0ZWFkIG9mIGJ1aWxkaW5nIGEgbmV3IGZyYW1pbmcg Zm9ybWF0IGZvciBIVFRQIGhlYWRlcnMgdnMgYm9keS4NCg0KDQpPbiBUaHUsIERlYyAxLCAyMDE2 IGF0IDM6MzUgUE0sIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpXZSBoYXZlIHRoZSBl eGlzdGluZyBkb2N1bWVudCB3aGljaCBwdXRzIGV2ZXJ5dGhpbmcgb24gYSBzaW5nbGUgc3RyZWFt IGFuZCByZXRhaW5zIEhUVFAvMiBmcmFtaW5nLiAgQXQgdGhlIFdHIG1lZXRpbmcsIEkgaGVhcmQg c3Vic3RhbnRpYWwgZGVzaXJlIHRvIG1vdmUgYXMgbXVjaCBhcyBwb3NzaWJsZSBvZmYgdG8gc2Vw YXJhdGUgc3RyZWFtcyBwZXIgcmVxdWVzdC4gIFRoZXJlIHdhcyBhbHNvIGRpc2N1c3Npb24gYWJv dXQgaG93IHRvIG1vZGlmeSBIUEFDSyAoQnVjayBoYXMgYSBwcm9wb3NhbCB2aWEgZS1tYWlsOyBJ IGhhdmUgYSBkcmFmdCkgdG8gZW5hYmxlIHRoaXMsIGJ1dCBmcm9tIHNpZGUgY29udmVyc2F0aW9u cywgSSB0aGluayB0aGVyZeKAmXMgYWxzbyBhIGRlc2lyZSB0byByZXVzZSBIUEFDSyBjb2RlIHdo ZXJlIHBvc3NpYmxlIGFuZCBtaW5pbWl6ZSBjaGFuZ2VzLg0KDQpXaGF0IEnigJlkIGxpa2UgdG8g cHJvcG9zZSBhcyB0aGUgcGF0aCBmb3J3YXJkIGlzIHRoaXM6DQoNCiAgKiAgIENoYW5nZSB0aGUg bWFwcGluZyBkb2N1bWVudCB0byB1c2UgdGhlIHR3by1zdHJlYW1zLXBlci1yZXF1ZXN0IG1vZGVs IGRlc2NyaWJlZCBpbiBkcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjazxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2s+IHNlY3Rp b24gMy4xIHdpdGggc29tZSBvZiB0aGUgZnJhbWUgcmVkZWZpbml0aW9ucyBmcm9tIHNlY3Rpb24g My4yLg0KICAqICAgQXVnbWVudCBoZWFkZXItYmVhcmluZyBmcmFtZXMgd2l0aCBhIHNlcXVlbmNl IG51bWJlcg0KICAqICAgQ29udGludWUgdG8gdXNlIHVubW9kaWZpZWQgSFBBQ0sgd2l0aCBhIHJl cXVpcmVtZW50IHRoYXQgZnJhbWVzIGJlIGZlZCB0byB0aGUgZGVjb2RlciBpbiBvcmRlciBmb3Ig bm93DQoNClRoaXMgc2hvdWxkIHByb2R1Y2Ugbm8gd29yc2UgaGVhZC1vZi1saW5lIGJsb2NraW5n IHRoYW4gY3VycmVudGx5IGV4aXN0cywgcmV1c2VzIGV4aXN0aW5nIEhQQUNLIGNvZGUsIGFuZCBs ZXRzIHVzIG1ha2UgcHJvZ3Jlc3Mgb24gdGhlIGN1cnJlbnQgZHJhZnQuICBJbiBwYXJhbGxlbCBh bmQgYXMgd2UgaGF2ZSBwZW9wbGUgdG8gd29yayBvbiBpdCwgd2UgY2FuIGRlY2lkZSB0byB3aGF0 IGV4dGVudCB3ZSB3YW50IHRvIG1vZGlmeSBIUEFDSyB0byByZWR1Y2UgSE9MLWJsb2NraW5nIGlz c3Vlcy4gIChJ4oCZZCBlbmNvdXJhZ2UgQnVjayB0byBnZW5lcmF0ZSBhIHNob3J0IGRyYWZ0IG9u IGhpcyBpZGVhIGFzIHdlbGwsIHNvIHdlIGhhdmUgdHdvIGlkZWFzIHRvIGNvbXBhcmUuKQ0KDQpJ 4oCZZCBzcGVjaWZpY2FsbHkgbGlrZSBvcGluaW9ucyBmcm9tIHRoZSBXRyBvbiB3aGV0aGVyIHRo YXTigJlzIHRoZSBwYXRoIHdlIHdhbnQgdG8gbW92ZSBmb3J3YXJkIHdpdGgsIG9yIGlmIHRoZXJl 4oCZcyBhbiBhbHRlcm5hdGl2ZSBJIGhhdmVu4oCZdCBoZWFyZC4gIElmIHRoYXTigJlzIGFjY2Vw dGFibGUgdG8gdGhlIFdHLCBJ4oCZbGwgc3RhcnQgYSBwdWxsIHJlcXVlc3QgZm9yIHJldmlldy4N Cg0KDQoNCg0KDQotLQ0KQ2hhcmxlcyAnQnVjaycgS3Jhc2ljIHwgU29mdHdhcmUgRW5naW5lZXIg fCBja3Jhc2ljQGdvb2dsZS5jb208bWFpbHRvOmNrcmFzaWNAZ29vZ2xlLmNvbT4gfCArMSAoNDA4 KSA0MTItMTE0MQ0K --_000_BN6PR03MB2708BB50674E470BDBE0108487840BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjE3NDkxODI0Nzk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05NjQ2MzgxNzI7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JIGFjdHVhbGx5IGRpZCB1cGRhdGUgdGhlIHRleHQgdG8gc3BlY2lmeSDigJxj b25uZWN0aW9uLWxldmVsLOKAnSBzaW5jZSB0aGF04oCZcyB3aGF0IHRoZSB0cmFuc3BvcnQgZHJh ZnQgYWxsb3dzIHRoZSBhcHBsaWNhdGlvbiB0byBkby4mbmJzcDsgSW4gSFRUUC8yLCBvbmx5IERB VEEgZnJhbWVzIGFyZSBmbG93LWNvbnRyb2xsZWQNCiBhdCBhbGwsIGEgc3ViamVjdCBvZiBzb21l IGRlYmF0ZSBpbiB0aGUgSFRUUCBXRyBhdCB0aGUgdGltZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHJh dGlvbmFsZSBlaXRoZXIgd2F5IGlzIHRoYXQgcGF5bG9hZCBvbiB0aGUgY29udHJvbCBzdHJlYW1z IGlzIGJlaW5nIGNvbnN1bWVkIGJ5IHRoZSBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiBpdHNlbGYs IG5vdCBieSBzb21ldGhpbmcgYWJvdmUgaXQsIHNvIHRob3NlIHNob3VsZCBmbG93IHVuaW1wZWRl ZA0KIGFuZCBjYW4gYmUgdHJ1c3RlZCB0byByZWFkIGFuZCBwcm9jZXNzIHByb21wdGx5LCBidWdz IG5vdHdpdGhzdGFuZGluZy4mbmJzcDsgVGhlcmUgYXJlIG90aGVyIGd1YXJkcyBhZ2FpbnN0IGFu IGFidXNpdmUgcGVlcjombmJzcDsgSWYgdGhlIHBlZXIgb3BlbnMgdG9vIG1hbnkgc3RyZWFtcyB0 aGV54oCZbGwgcHJvZHVjZSBhIHZpb2xhdGlvbiBhdCB0aGUgUVVJQyBsYXllciwgYW5kIHlvdSBo YXZlIHRoZSBvcHRpb24gb2YgcHV0dGluZyBhIHNtYWxsZXIgcGVyLXN0cmVhbQ0KIGZsb3cgY29u dHJvbCB3aW5kb3cgdG8gYmVnaW4gd2l0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RmxvdyBjb250cm9sIGFu ZCBwcmlvcml0eSBhcmUgcmVsYXRlZCwgYnV0IHNlcnZlIGRpZmZlcmVudCBwdXJwb3Nlcy4mbmJz cDsgRmxvdyBjb250cm9sIGxpbWl0cyBob3cgbXVjaCB1bnByb2Nlc3NlZCBkYXRhIEkgaGF2ZSBz aXR0aW5nIGFyb3VuZCwgd2hpbGUgcHJpb3JpdHkgZGljdGF0ZXMgaG93IEkgc2hvdWxkDQogYWxs b2NhdGUgYSBzY2FyY2UgcmVzb3VyY2UgKHdoZXRoZXIgdGhhdOKAmXMgcHJvY2Vzc2luZyB0aW1l IG9yIGJhbmR3aWR0aCBvbiB0aGUgcmV0dXJuIGRpcmVjdGlvbikuJm5ic3A7IEEgdGhpY2sgY2xp ZW50IHdpbGwgdmVyeSByYXJlbHkgd2FudCB0byBmbG93LWNvbnRyb2wgdGhlIHNlcnZlciDigJMg aW4gcHJhY3RpY2UsIHRoZXkgb3BlbiB0aGUgd2luZG93cyBhcyB3aWRlIGFzIHBvc3NpYmxlIGFu ZCB1c2UgcHJpb3JpdHksIGFzIHlvdSBzdWdnZXN0LiZuYnNwOyBUaGUNCiBzZXJ2ZXIsIG9uIHRo ZSBvdGhlciBoYW5kLCB3YW50cyB0byBjYXJlZnVsbHkgYm91bmQgbWVtb3J5IGFsbG9jYXRpb25z IHBlciBjb25uZWN0aW9uIOKAkyBlc3BlY2lhbGx5IHdoZXJlIHRoZSBhcHBsaWNhdGlvbiBhY3R1 YWxseSBjb25zdW1pbmcgdGhlIGRhdGEgaXNu4oCZdCBmdWxseSByZWxpYWJsZSBmcm9tIHRoZSBw cm90b2NvbCBpbXBsZW1lbnRhdGlvbuKAmXMgcG9pbnQgb2Ygdmlldy4mbmJzcDsgRmxvdyBjb250 cm9sIGFsbG93cyB1bnJlYWQgZGF0YSBmbG93aW5nDQogdXBzdHJlYW0gdG8gYmUgaGVsZCBhdCB0 aGUgY2xpZW50LCByYXRoZXIgdGhhbiBpbiB0aGUgc2VydmVy4oCZcyBsaW1pdGVkIG1lbW9yeSwg d2hlbiB0aGUgYXBwbGljYXRpb24gaXMgc2xvdyB0byBjb25zdW1lIHRoZSBkYXRhLiZuYnNwOyBO b24tYnJvd3NlciBjbGllbnRzIG9mdGVuIGZpbmQgdGhlbXNlbHZlcyBpbiB0aGUgc2FtZSBwb3Np dGlvbiBvZiBuZWVkaW5nIHRvIGJvdW5kIG1lbW9yeSB1c2VkIGZvciB0aGUgY29ubmVjdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENoYXJs ZXMgJ0J1Y2snIEtyYXNpYyBbbWFpbHRvOmNrcmFzaWNAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgOCwgMjAxNiA5OjU4IEFNPGJyPg0KPGI+VG86PC9i PiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8 Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IEphbmEgSXll bmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBIVFRQIE1hcHBpbmc6IEZpeGluZyBzdHJl YW1zLWluLXN0cmVhbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUg cXVlc3Rpb24gSSBoYXZlLiZuYnNwOyBUaGUgdGV4dCByZWZlcnMgdG8gdGhlIGNvbnRyb2wgZGF0 YSBzdHJlYW1zIGJlaW5nIGV4ZW1wdCBmcm9tIGZsb3cgY29udHJvbC4mbmJzcDsgSW4gb3VyIGRl cGxveW1lbnQsIGhlYWRlcnMgYXJlIGV4ZW1wdCBmcm9tIHRoZSBjb25uZWN0aW9uIGxldmVsIGZs b3cgY29udHJvbCwgYnV0IHN0cmVhbSBsZXZlbCBmbG93IGNvbnRyb2wgc3RpbGwgYXBwbGllcy4g Jm5ic3A7IElzIHRoZSBmdWxsDQogZXhlbXB0aW9uIGludGVudGlvbmFsPzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmV5b25kIHRoYXQsIEknbSBpbnRlcmVz dGVkIHRvIGtub3cgbW9yZSBvZiB0aGUgcmF0aW9uYWxlIGJlaGluZCBmbG93IGNvbnRyb2wuJm5i c3A7IFRpZGJpdHMgSSd2ZSBoZWFyZCBhcmUgbm90IHZlcnkgc2F0aXNmYWN0b3J5IHRvIG1lLCBp dCBzZWVtcyBsaWtlIHByaW9yaXRpZXMgKHdoaWNoIGFyZSBub3QgZnVsbHkgYmFrZWQgZm9yIFFV SUMgeWV0KSB3b3VsZCBiZSB0aGUgbW9yZSBhcHByb3ByaWF0ZSBtZWNoYW5pc20uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRGVj IDgsIDIwMTYgYXQgOTo1MiBBTSwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HaXZlbiBzb21lIHBvc2l0aXZl IGZlZWRiYWNrIGFuZCBubyBuZWdhdGl2ZSBzbyBmYXIsIEnigJltIGdvaW5nIHRvIGdvIGFoZWFk IGFuZCBtZXJnZSB0aGlzLiZuYnNwOyBGZWVkYmFjayBjb250aW51ZXMgdG8gYmUgd2VsY29tZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5NaWtlIEJpc2hvcDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IERlY2VtYmVyIDUsIDIwMTYgMTo1MiBQTTxicj4NCjxiPlRvOjwvYj4gSWFuIFN3ZXR0ICZsdDs8 YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3 ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86 anJpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBIVFRQIE1hcHBpbmc6IEZpeGluZyBzdHJlYW1zLWluLXN0cmVhbXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJl2 ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0IHdpdGggdGhlIGZvbGxvd2luZyBwcm9wb3NhbCBoZXJl OiZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9w dWxsLzcxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRy YWZ0cy9wdWxsLzcxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RmVlZGJhY2sgd2Vs Y29tZSwgYXMgYWx3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+ IElhbiBTd2V0dCBbPGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBEZWNlbWJlciA1LCAyMDE2IDEyOjM2IFBNPGJyPg0KPGI+VG86PC9iPiBKYW5h IEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmpyaUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgSUVURiBRVUlDIFdH ICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSFRUUCBNYXBwaW5nOiBG aXhpbmcgc3RyZWFtcy1pbi1zdHJlYW1zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QWdyZWVkLCBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRoZSBleGlzdGluZyBsZXZlbCBvZiBIT0wg YmxvY2tpbmcgYW5kIGltcHJvdmluZyB1cG9uIGl0IHNlZW1zIHByYWN0aWNhbCwgc2luY2UgaXQg c2VlbXMgdmVyeSBsaWtlbHkgd2UnbGwgbW92ZSB0byB0aGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVl c3QgbW9kZWwNCiBubyBtYXR0ZXIgd2hhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIERlYyA1LCAyMDE2IGF0IDM6MjYgUE0sIEphbmEg SXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB0aGUgd29yaywgTWlrZS4gSSBsaWtlIHRoaXMgYXBw cm9hY2ggLS0gaXQncyBhIGdyZWF0IHdheSB0byBzZXBhcmF0ZSB0aGUgaGVhZGVyIGNvbXByZXNz aW9uIGlzc3VlIGZyb20gdGhlIGlzc3VlIG9mIGEgY2xlYW4gbWFwcGluZyBvZiBIVFRQIGhlYWRl cnMvZGF0YSB0byBRVUlDIHN0cmVhbXMuDQogSSB0aGluayB3ZSBzaG91bGQgZGlzY3VzcyB0aGUg SFRUUCB0byBRVUlDIHN0cmVhbSBtYXBwaW5nIHByb3Bvc2FsIHlvdSd2ZSBvdXRsaW5lZCwgYnV0 IHNob3VsZCB3ZSBkbyB0aGF0IG9uIGFuIGlzc3VlPyBPciBhIHNlcGFyYXRlIHRocmVhZD88bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GV0lXLCBJIGxp a2UgdGhpcyBtYXBwaW5nIGFwcHJvYWNoLCB3aGVyZSBIVFRQIGhlYWRlcnMgYW5kIGJvZHkgYXJl IG1hcHBlZCB0byBhIHN0cmVhbS1wYWlyLiBBcyBJJ3ZlIG5vdGVkIGVhcmxpZXIsIFFVSUMncyBz dHJlYW1zIGFyZSBlcGhlbWVyYWwgYW5kIHNob3VsZCBiZSBsaWdodHdlaWdodCwgd2hpY2gNCiBt ZWFucyB0aGF0IHRoZXkgY2FuIGJlIHVzZWQgaW5zdGVhZCBvZiBidWlsZGluZyBhIG5ldyBmcmFt aW5nIGZvcm1hdCBmb3IgSFRUUCBoZWFkZXJzIHZzIGJvZHkuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUaHUsIERlYyAxLCAyMDE2IGF0IDM6MzUgUE0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGhhdmUgdGhlIGV4aXN0aW5nIGRvY3VtZW50 IHdoaWNoIHB1dHMgZXZlcnl0aGluZyBvbiBhIHNpbmdsZSBzdHJlYW0gYW5kIHJldGFpbnMgSFRU UC8yIGZyYW1pbmcuJm5ic3A7IEF0IHRoZSBXRyBtZWV0aW5nLCBJIGhlYXJkIHN1YnN0YW50aWFs IGRlc2lyZSB0byBtb3ZlIGFzIG11Y2ggYXMgcG9zc2libGUgb2ZmDQogdG8gc2VwYXJhdGUgc3Ry ZWFtcyBwZXIgcmVxdWVzdC4mbmJzcDsgVGhlcmUgd2FzIGFsc28gZGlzY3Vzc2lvbiBhYm91dCBo b3cgdG8gbW9kaWZ5IEhQQUNLIChCdWNrIGhhcyBhIHByb3Bvc2FsIHZpYSBlLW1haWw7IEkgaGF2 ZSBhIGRyYWZ0KSB0byBlbmFibGUgdGhpcywgYnV0IGZyb20gc2lkZSBjb252ZXJzYXRpb25zLCBJ IHRoaW5rIHRoZXJl4oCZcyBhbHNvIGEgZGVzaXJlIHRvIHJldXNlIEhQQUNLIGNvZGUgd2hlcmUg cG9zc2libGUgYW5kIG1pbmltaXplDQogY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPldoYXQgSeKAmWQgbGlrZSB0byBwcm9wb3NlIGFzIHRoZSBwYXRoIGZvcndhcmQgaXMgdGhp czo8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQ2hhbmdlIHRoZSBtYXBwaW5nIGRvY3VtZW50 IHRvIHVzZSB0aGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVlc3QgbW9kZWwgZGVzY3JpYmVkIGluDQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLXF1aWMtaHR0 cC1hbmQtcXBhY2siIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5k LXFwYWNrPC9hPiBzZWN0aW9uIDMuMSB3aXRoIHNvbWUgb2YgdGhlIGZyYW1lIHJlZGVmaW5pdGlv bnMgZnJvbSBzZWN0aW9uIDMuMi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpBdWdtZW50IGhlYWRlci1iZWFyaW5nIGZyYW1l cyB3aXRoIGEgc2VxdWVuY2UgbnVtYmVyPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQ29udGludWUgdG8gdXNlIHVubW9kaWZp ZWQgSFBBQ0sgd2l0aCBhIHJlcXVpcmVtZW50IHRoYXQgZnJhbWVzIGJlIGZlZCB0byB0aGUgZGVj b2RlciBpbiBvcmRlciBmb3Igbm93PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGlzIHNob3VsZCBwcm9kdWNlIG5vIHdvcnNlIGhlYWQtb2YtbGluZSBibG9ja2luZyB0aGFuIGN1 cnJlbnRseSBleGlzdHMsIHJldXNlcyBleGlzdGluZyBIUEFDSyBjb2RlLCBhbmQgbGV0cyB1cyBt YWtlIHByb2dyZXNzIG9uIHRoZSBjdXJyZW50IGRyYWZ0LiZuYnNwOyBJbiBwYXJhbGxlbCBhbmQg YXMgd2UgaGF2ZQ0KIHBlb3BsZSB0byB3b3JrIG9uIGl0LCB3ZSBjYW4gZGVjaWRlIHRvIHdoYXQg ZXh0ZW50IHdlIHdhbnQgdG8gbW9kaWZ5IEhQQUNLIHRvIHJlZHVjZSBIT0wtYmxvY2tpbmcgaXNz dWVzLiZuYnNwOyAoSeKAmWQgZW5jb3VyYWdlIEJ1Y2sgdG8gZ2VuZXJhdGUgYSBzaG9ydCBkcmFm dCBvbiBoaXMgaWRlYSBhcyB3ZWxsLCBzbyB3ZSBoYXZlIHR3byBpZGVhcyB0byBjb21wYXJlLik8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJlkIHNwZWNpZmljYWxseSBsaWtlIG9waW5p b25zIGZyb20gdGhlIFdHIG9uIHdoZXRoZXIgdGhhdOKAmXMgdGhlIHBhdGggd2Ugd2FudCB0byBt b3ZlIGZvcndhcmQgd2l0aCwgb3IgaWYgdGhlcmXigJlzIGFuIGFsdGVybmF0aXZlIEkgaGF2ZW7i gJl0IGhlYXJkLiZuYnNwOyBJZiB0aGF04oCZcyBhY2NlcHRhYmxlIHRvIHRoZSBXRywNCiBJ4oCZ bGwgc3RhcnQgYSBwdWxsIHJlcXVlc3QgZm9yIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjRDUwRjI1IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPkNoYXJs ZXMgJ0J1Y2snIEtyYXNpYyZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzMz NjlFOCAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDtTb2Z0d2FyZQ0KIEVuZ2luZWVyJm5ic3A7 fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjMDA5OTM5IDEuNXB0O3BhZGRpbmc6Mi4w cHQiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5ja3Jhc2ljQGdvb2dsZS5jb208L2E+Jm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRl cjpzb2xpZCAjRUVCMjExIDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwOyYjNDM7MQ0KICg0MDgp IDQxMi0xMTQxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708BB50674E470BDBE0108487840BN6PR03MB2708namp_-- From nobody Thu Dec 8 12:25:29 2016 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 3970F12956F for ; Thu, 8 Dec 2016 12:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 4wLQjjnd1wSK for ; Thu, 8 Dec 2016 12:25:25 -0800 (PST) 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 02B2A129567 for ; Thu, 8 Dec 2016 12:25:24 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id p42so23952413ioo.1 for ; Thu, 08 Dec 2016 12:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YCAafbNY3DxbANWh0UCHOr6H8WIpdm8D0Mnz0duiLl8=; b=UMI7T66LsZmBYX2ZEkpB3XGvpnedvSPjClv/fINqhtot1mdcUGCYdTUo4Lrk1t4bX7 A/Le2ER+l7GxSLmNmC9oqe5V5CfwDyvu5O7CztCZWRzsKom6dtNcBOrE8+HtPmsYDn6O /9ccPuVYYcLWxAZ6KxQKXj5dSOvTOr14BltUG3HIphJ54fSOJNVDjDnEU8w2HoMk5RU6 BzciyJSwW7ZK5YQR930PgTqfS3D5O4cywAvHE62h/j0mBJU+T/5gj3hUbfXHeunNI17v LxTNw0B4zBeO/Cj4JX0KuIQocXmNMgrzNc69YIdZmQNmCZY0H1wDZc0heIPwE9AQ03hK yZyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YCAafbNY3DxbANWh0UCHOr6H8WIpdm8D0Mnz0duiLl8=; b=G+NIEqOVGypc9u2jRvfaZ2PgFYUIegvH0nU0rltsZ6frZQbmg/hAYri/c1G2IMr922 E8McjaIjiSKHMwcHHeMHrRr1vklKrD3gwZrSLMEMlg9qHDzSYbpn+Jf1dQ+CRSDzCovw VTpsdiFc5LlBHVi5Fhv2JPioKoLCAcOVHkyBCw2Ovo/6euCgRO2NgUIDdm1pBDDau/9E C8ZOzPBXOgHWhuOm1A5Y8fKoh9ZlGuI6Qk+PHpYMggo0JufS2NMBXevRGve7TZ/0qLRy sXFCYSVX3dAT28u4R2srnKEaDL7a5wG7yGJDil7HgAniKRrfTvaA7rKtLDXqQY2rErwL fhRw== X-Gm-Message-State: AKaTC01JnSV7/YHKNjYQUbbJC0FQwUa+vx3ReSBxsHdJixJihg2vPaXP9vXBpOofc+4FQ9hSpNKJEyhqv8XAWkDB X-Received: by 10.36.15.137 with SMTP id 131mr3569772ito.115.1481228724131; Thu, 08 Dec 2016 12:25:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.67 with HTTP; Thu, 8 Dec 2016 12:25:03 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Thu, 8 Dec 2016 12:25:03 -0800 Message-ID: Subject: Re: HTTP Mapping: Fixing streams-in-streams To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1144a40cef29a805432b6f45 Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 08 Dec 2016 20:25:28 -0000 --001a1144a40cef29a805432b6f45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gah. My question had a terrible typo. I didn't mean "rationale behind flow control" but rather "rationale behind the flow control exemption". Either way, you answered thanks. :) On Thu, Dec 8, 2016 at 12:12 PM, Mike Bishop wrote: > I actually did update the text to specify =E2=80=9Cconnection-level,=E2= =80=9D since that=E2=80=99s > what the transport draft allows the application to do. In HTTP/2, only > DATA frames are flow-controlled at all, a subject of some debate in the > HTTP WG at the time. > > > > The rationale either way is that payload on the control streams is being > consumed by the protocol implementation itself, not by something above it= , > so those should flow unimpeded and can be trusted to read and process > promptly, bugs notwithstanding. There are other guards against an abusiv= e > peer: If the peer opens too many streams they=E2=80=99ll produce a viola= tion at > the QUIC layer, and you have the option of putting a smaller per-stream > flow control window to begin with. > > > > Flow control and priority are related, but serve different purposes. Flo= w > control limits how much unprocessed data I have sitting around, while > priority dictates how I should allocate a scarce resource (whether that= =E2=80=99s > processing time or bandwidth on the return direction). A thick client wi= ll > very rarely want to flow-control the server =E2=80=93 in practice, they o= pen the > windows as wide as possible and use priority, as you suggest. The server= , > on the other hand, wants to carefully bound memory allocations per > connection =E2=80=93 especially where the application actually consuming = the data > isn=E2=80=99t fully reliable from the protocol implementation=E2=80=99s p= oint of view. > Flow control allows unread data flowing upstream to be held at the client= , > rather than in the server=E2=80=99s limited memory, when the application = is slow to > consume the data. Non-browser clients often find themselves in the same > position of needing to bound memory used for the connection. > > > > *From:* Charles 'Buck' Krasic [mailto:ckrasic@google.com] > *Sent:* Thursday, December 8, 2016 9:58 AM > *To:* Mike Bishop > *Cc:* Ian Swett ; Jana Iyengar ; > IETF QUIC WG > > *Subject:* Re: HTTP Mapping: Fixing streams-in-streams > > > > One question I have. The text refers to the control data streams being > exempt from flow control. In our deployment, headers are exempt from the > connection level flow control, but stream level flow control still applie= s. > Is the full exemption intentional? > > > > Beyond that, I'm interested to know more of the rationale behind flow > control. Tidbits I've heard are not very satisfactory to me, it seems li= ke > priorities (which are not fully baked for QUIC yet) would be the more > appropriate mechanism. > > > > On Thu, Dec 8, 2016 at 9:52 AM, Mike Bishop > wrote: > > Given some positive feedback and no negative so far, I=E2=80=99m going to= go ahead > and merge this. Feedback continues to be welcome. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mike Bishop > *Sent:* Monday, December 5, 2016 1:52 PM > *To:* Ian Swett ; Jana Iyengar > *Cc:* IETF QUIC WG > *Subject:* RE: HTTP Mapping: Fixing streams-in-streams > > > > I=E2=80=99ve created a pull request with the following proposal here: > https://github.com/quicwg/base-drafts/pull/71 > > > > Feedback welcome, as always. > > > > *From:* Ian Swett [mailto:ianswett@google.com ] > *Sent:* Monday, December 5, 2016 12:36 PM > *To:* Jana Iyengar > *Cc:* Mike Bishop ; IETF QUIC WG < > quic@ietf.org> > *Subject:* Re: HTTP Mapping: Fixing streams-in-streams > > > > Agreed, moving forward with the existing level of HOL blocking and > improving upon it seems practical, since it seems very likely we'll move = to > the two-streams-per-request model no matter what. > > > > On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar wrote: > > Thanks for the work, Mike. I like this approach -- it's a great way to > separate the header compression issue from the issue of a clean mapping o= f > HTTP headers/data to QUIC streams. I think we should discuss the HTTP to > QUIC stream mapping proposal you've outlined, but should we do that on an > issue? Or a separate thread? > > > > FWIW, I like this mapping approach, where HTTP headers and body are mappe= d > to a stream-pair. As I've noted earlier, QUIC's streams are ephemeral and > should be lightweight, which means that they can be used instead of > building a new framing format for HTTP headers vs body. > > > > > > On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop > wrote: > > We have the existing document which puts everything on a single stream an= d > retains HTTP/2 framing. At the WG meeting, I heard substantial desire to > move as much as possible off to separate streams per request. There was > also discussion about how to modify HPACK (Buck has a proposal via e-mail= ; > I have a draft) to enable this, but from side conversations, I think > there=E2=80=99s also a desire to reuse HPACK code where possible and mini= mize > changes. > > > > What I=E2=80=99d like to propose as the path forward is this: > > - Change the mapping document to use the two-streams-per-request model > described in draft-bishop-quic-http-and-qpack > section > 3.1 with some of the frame redefinitions from section 3.2. > - Augment header-bearing frames with a sequence number > - Continue to use unmodified HPACK with a requirement that frames be > fed to the decoder in order for now > > > > This should produce no worse head-of-line blocking than currently exists, > reuses existing HPACK code, and lets us make progress on the current > draft. In parallel and as we have people to work on it, we can decide to > what extent we want to modify HPACK to reduce HOL-blocking issues. (I=E2= =80=99d > encourage Buck to generate a short draft on his idea as well, so we have > two ideas to compare.) > > > > I=E2=80=99d specifically like opinions from the WG on whether that=E2=80= =99s the path we > want to move forward with, or if there=E2=80=99s an alternative I haven= =E2=80=99t heard. > If that=E2=80=99s acceptable to the WG, I=E2=80=99ll start a pull request= for review. > > > > > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1144a40cef29a805432b6f45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gah.=C2=A0 My question had a terrible typo. I didn't m= ean "rationale behind flow control" but rather "rationale be= hind the flow control exemption". =C2=A0 Either way, you answered than= ks. =C2=A0:) =C2=A0=C2=A0



On Thu, Dec 8, 2016 at 12:12 PM= , Mike Bishop <Michael.Bishop@microsoft.com> wrot= e:

I actually did update the text to specify =E2=80=9C= connection-level,=E2=80=9D since that=E2=80=99s what the transport draft al= lows the application to do.=C2=A0 In HTTP/2, only DATA frames are flow-cont= rolled at all, a subject of some debate in the HTTP WG at the time.=

=C2=A0

The rationale either way is that payload on the con= trol streams is being consumed by the protocol implementation itself, not b= y something above it, so those should flow unimpeded and can be trusted to read and process promptly, bugs notwithstanding.=C2= =A0 There are other guards against an abusive peer:=C2=A0 If the peer opens= too many streams they=E2=80=99ll produce a violation at the QUIC layer, an= d you have the option of putting a smaller per-stream flow control window to begin with.

=C2=A0

Flow control and priority are related, but serve di= fferent purposes.=C2=A0 Flow control limits how much unprocessed data I hav= e sitting around, while priority dictates how I should allocate a scarce resource (whether that=E2=80=99s processing time or band= width on the return direction).=C2=A0 A thick client will very rarely want = to flow-control the server =E2=80=93 in practice, they open the windows as = wide as possible and use priority, as you suggest.=C2=A0 The server, on the other hand, wants to carefully bound memory allocations per= connection =E2=80=93 especially where the application actually consuming t= he data isn=E2=80=99t fully reliable from the protocol implementation=E2=80= =99s point of view.=C2=A0 Flow control allows unread data flowing upstream to be held at the client, rather than in the server=E2=80=99s lim= ited memory, when the application is slow to consume the data.=C2=A0 Non-br= owser clients often find themselves in the same position of needing to boun= d memory used for the connection.

=C2=A0

From: Charles 'Buck' Krasic = [mailto:ckrasic@goo= gle.com]
Sent: Thursday, December 8, 2016 9:58 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Ian Swett <ianswett@google.com>; Jana Iyengar <jri@google.com>; IETF QUIC WG <quic@ietf.org>=


Subject: Re: HTTP Mapping: Fixing streams-in-streams

=C2=A0

One question I have.=C2=A0 The text refers to the co= ntrol data streams being exempt from flow control.=C2=A0 In our deployment,= headers are exempt from the connection level flow control, but stream leve= l flow control still applies. =C2=A0 Is the full exemption intentional?

=C2=A0

Beyond that, I'm interested to know more of the = rationale behind flow control.=C2=A0 Tidbits I've heard are not very sa= tisfactory to me, it seems like priorities (which are not fully baked for Q= UIC yet) would be the more appropriate mechanism.

=C2=A0

On Thu, Dec 8, 2016 at 9:52 AM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

Given some positive feedback and no negative so far,= I=E2=80=99m going to go ahead and merge this.=C2=A0 Feedback continues to = be welcome.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop
Sent: Monday, December 5, 2016 1:52 PM
To: Ian Swett <ianswett@google.com>; Jana Iyengar <jri@google.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: RE: HTTP Mapping: Fixing streams-in-streams

=C2=A0

I=E2=80=99ve created a pull request with the followi= ng proposal here:=C2=A0 https://github.com/quicwg/base-drafts/pull/71

=C2=A0

Feedback welcome, as always.

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Monday, December 5, 2016 12:36 PM
To: Jana Iyengar <jri@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; IETF QUIC WG &= lt;quic@ietf.org>=
Subject: Re: HTTP Mapping: Fixing streams-in-streams

=C2=A0

Agreed, moving forward with the existing level of HO= L blocking and improving upon it seems practical, since it seems very likel= y we'll move to the two-streams-per-request model no matter what.

=C2=A0

On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar <jri@google.com> wro= te:

Thanks for the work, Mike. I like this approach -- i= t's a great way to separate the header compression issue from the issue= of a clean mapping of HTTP headers/data to QUIC streams. I think we should discuss the HTTP to QUIC stream mapping proposal you'= ;ve outlined, but should we do that on an issue? Or a separate thread?

=C2=A0

FWIW, I like this mapping approach, where HTTP heade= rs and body are mapped to a stream-pair. As I've noted earlier, QUIC= 9;s streams are ephemeral and should be lightweight, which means that they can be used instead of building a new framing format for H= TTP headers vs body.

=C2=A0

=C2=A0

On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

We have the existing document which puts everything = on a single stream and retains HTTP/2 framing.=C2=A0 At the WG meeting, I h= eard substantial desire to move as much as possible off to separate streams per request.=C2=A0 There was also discussion about how= to modify HPACK (Buck has a proposal via e-mail; I have a draft) to enable= this, but from side conversations, I think there=E2=80=99s also a desire t= o reuse HPACK code where possible and minimize changes.

=C2=A0

What I=E2=80=99d like to propose as the path forward= is this:

  • Change the mapping document to use the two-streams-per-request model descri= bed in draft-bishop-quic-http-and-qpack section 3.1 with some of the fram= e redefinitions from section 3.2.
  • Augment header-bearing frames with a sequence number
  • Continue to use unmodified HPACK with a requirement that frames be fed to t= he decoder in order for now

=C2=A0

This should produce no worse head-of-line blocking t= han currently exists, reuses existing HPACK code, and lets us make progress= on the current draft.=C2=A0 In parallel and as we have people to work on it, we can decide to what extent we want to modify HPACK= to reduce HOL-blocking issues.=C2=A0 (I=E2=80=99d encourage Buck to genera= te a short draft on his idea as well, so we have two ideas to compare.)<= /u>

=C2=A0

I=E2=80=99d specifically like opinions from the WG o= n whether that=E2=80=99s the path we want to move forward with, or if there= =E2=80=99s an alternative I haven=E2=80=99t heard.=C2=A0 If that=E2=80=99s = acceptable to the WG, I=E2=80=99ll start a pull request for review.

=C2=A0

=C2=A0



=C2=A0

--

Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2= =A0|=C2=A0+1 = (408) 412-1141




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--001a1144a40cef29a805432b6f45-- From nobody Sat Dec 10 14:31:45 2016 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 C626A129535 for ; Sat, 10 Dec 2016 14:31:43 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 I2AU-FqFXqfn for ; Sat, 10 Dec 2016 14:31:41 -0800 (PST) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 980EB129531 for ; Sat, 10 Dec 2016 14:31:41 -0800 (PST) Received: by mail-yw0-x241.google.com with SMTP id a10so4798878ywa.1 for ; Sat, 10 Dec 2016 14:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=r7M2luoaOSzP0cii8nOb1yfUS4vov8DCPphuMpp/Yg8=; b=xJIX4Dgig6YbJ1I9my3E/lMFlsecknYfsrK6wvmmPZ4Sw8wqIapjBWS7KiUxveq3Ef jrf1aD5oKazJCifUZ0RybQpTOdqnvTAlBEcFBShp39b+v1TSk71piTDSGHN3UOt2BZPA kE+H9Dign7jrcN5zwFsCSNfOueO8ryTI9IkvAgXCEdWhIn+y3/gdHJpIO7eJRaCvUn4r Ilix+FW4nGq/048vEXwivJibvWe7dG11j6ZCgkldGxpOHYd06/6NcR1BAVOGWkqgQlS3 2JNXWNn8mWCXgpherF4OGWppaziTvuQPSEJfKQw7lzXa9nLoOV/pDe7f7xKu32fi26kP /4OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=r7M2luoaOSzP0cii8nOb1yfUS4vov8DCPphuMpp/Yg8=; b=FR2/ze9fBD+x5vSvojfT64ZRNs7vBiHO7/dsbBitNbsIwG7j2G8AlQIcD+KvrytzRs 7GSoivZXBvzRyonmwAIrSmru99tCV5x7S4SnWR9cWWy43nezSKM2amMa4iDcjo2qLlyF f4mibdspp454QguIMprxJsBNgJ0HiQqOU671fJHMcglFIYrtUm9YimDpPcMMRWCRgoFu iyzNvqXEESxcvt6YtvAwUn3Oz2vO6KgDwcYEoyk1j8C3ZA2tT4X5cot/BsJOsuvlHLN9 2kKr4tutoqIZ7tpMKTZRIA4TCRFlCaHtiszYRvlOwWs0p2Xq8Wy4/5kykQaCXZwFqbYl 0+Zg== X-Gm-Message-State: AKaTC01xN5IZs4gWCqSkhoDX/V2IDkrTyYGUn3nU/UV+upO73n1wqXh2gLgXGElutGyG3r3l3WNc1sECl76DbQ== X-Received: by 10.129.94.196 with SMTP id s187mr23064602ywb.240.1481409100515; Sat, 10 Dec 2016 14:31:40 -0800 (PST) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.129.53.4 with HTTP; Sat, 10 Dec 2016 14:31:40 -0800 (PST) In-Reply-To: References: From: Jim Roskind Date: Sat, 10 Dec 2016 14:31:40 -0800 X-Google-Sender-Auth: IBqwkB4PIZ0Fn8IZp7ceTYsKFzk Message-ID: Subject: Re: Stream vs. connection To: Ian Swett Content-Type: multipart/alternative; boundary=001a1141c1f43410ed0543556f3b Archived-At: Cc: Mike Bishop , "quic@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Dec 2016 22:31:44 -0000 --001a1141c1f43410ed0543556f3b Content-Type: text/plain; charset=UTF-8 Adding to Ian's comment: On Mon, Dec 5, 2016 at 2:02 PM, Ian Swett wrote: > On Mon, Dec 5, 2016 at 2:13 PM, Mike Bishop > wrote: > >> ... >> The PING frame handling actually is specified: "The receiver of a PING >> frame simply needs to ACK the packet containing this frame." I can see >> where it seems like it serves little purpose -- there's basically no >> difference between PING and PADDING, except that PING is retransmittable >> and PADDING is not. >> >> Because it must be acked, it serves as a liveness/connectivity check, > which can be very useful on longer lived connections. > > Even more important/common that a "liveness check," a PING frame in a packet often serves to revitalize a connection. It is often the case that a NATing router can drop the NAT association, either due to an expiration timer firing, or plausibly due to the NAT table exhaustion and eviction. As a result, it is routinely the case that a client sends a PING frame (in a packet) when the client is still waiting for a response, and it is fearful that a router has dropped the NAT association (which would make it impossible for a server response to reach the client!). The PING then either assures the NAT router that "traffic is still using the route" (and hence the NAT association should not be dropped anytime soon), or else it causes the NAT router to establish a new association (potentially new egress port for the externally visible router IP address). On the receiving side, the server is therefore effectively supplied with an explanation for why a packet was sent, containing a PING frame. For some servers, there is a fear that a DOS attack (intentional or accidental) could be mounted by a series of PING-containing packets (which consume bandwidth, but provide no significant data-payload transmission). As a result, servers may wish to restrict the rate, or conditions, for which clients may reasonably send PING frames, and at the same time, be "more willing' to accept a change in the connection's client-side egress port when a PING frame is observed. PADDING frames serve different functions, and should not interact with limitations/meanings on PING frames. The cost of distinguishing these similar frames seems small, and the value of handling PINGs differently seems significant. Hope that helps, Jim Opinions expressed are mine, and not that of my employer. --001a1141c1f43410ed0543556f3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding to Ian's comment:

On Mon, Dec 5, 2016 at 2:02 PM, Ian Swett <= span dir=3D"ltr"><ianswett@google.com> wrote:
= On Mon, Dec 5, 2016 at 2:13 PM, Mike Bishop <M= ichael.Bishop@microsoft.com> wrote:
...
The PING frame handling actually is specified:=C2=A0 "The receiver of = a PING frame simply needs to ACK the packet containing this frame."=C2= =A0 I can see where it seems like it serves little purpose -- there's b= asically no difference between PING and PADDING, except that PING is retran= smittable and PADDING is not.

Because it must= be acked, it serves as a liveness/connectivity check, which can be very us= eful on longer lived connections.


Even more important/c= ommon that a "liveness check," a PING frame in a packet often ser= ves to revitalize a connection.=C2=A0 It is often the case that a NATing ro= uter can drop the NAT association, either due to an expiration timer firing= , or plausibly due to the NAT table exhaustion and eviction.=C2=A0 As a res= ult, it is routinely the case that a client sends a PING frame (in a packet= ) when the client is still waiting for a response, and it is fearful that a= router has dropped the NAT association (which would make it impossible for= a server response to reach the client!).=C2=A0 The PING then either assure= s the NAT router that "traffic is still using the route" (and hen= ce the NAT association should not be dropped anytime soon), or else it caus= es the NAT router to establish a new association (potentially new egress po= rt for the externally visible router IP address).=C2=A0

On the receiving side, the server is therefore effectively supplied w= ith an explanation for why a packet was sent, containing a PING frame.=C2= =A0 For some servers, there is a fear that a DOS attack (intentional or acc= idental) could be mounted by a series of PING-containing packets (which con= sume bandwidth, but provide no significant data-payload transmission). As a= result, servers may wish to restrict the rate, or conditions, for which cl= ients may reasonably send PING frames, and at the same time, be "more = willing' to accept a change in the connection's client-side egress = port when a PING frame is observed.

PADDING frames= serve different functions, and should not interact with limitations/meanin= gs on PING frames.=C2=A0 The cost of distinguishing these similar frames se= ems small, and the value of handling PINGs differently seems significant.

Hope that helps,

Jim

Opinions expressed are mine, and not that of my employer.


--001a1141c1f43410ed0543556f3b-- From nobody Sun Dec 11 17:09:43 2016 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 72A8A129509 for ; Sun, 11 Dec 2016 17:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 lkuHwc1-9_2p for ; Sun, 11 Dec 2016 17:09:40 -0800 (PST) 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 9F59B1294FB for ; Sun, 11 Dec 2016 17:09:40 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cGF7Z-0003il-LA for quic@ietf.org; Mon, 12 Dec 2016 02:09:38 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cGF7B-0004J7-H3 for quic@ietf.org; Sun, 11 Dec 2016 20:09:35 -0500 Received: (qmail 25668 invoked from network); 12 Dec 2016 01:09:13 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.108]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Dec 2016 01:09:12 -0000 From: "Christian Huitema" To: "'Eric Rescorla'" References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> In-Reply-To: Date: Sun, 11 Dec 2016 17:09:06 -0800 Message-ID: <011301d25414$580de370$0829aa50$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wFxK6dxAjaMj8gCk11JPgK0p11kAM33deQCcSx/dgH5uKaZAbbvkdsC6gRqegKLJr2gAba8JmWfHpCuoA== Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD80X 6To05MuWZvnX6A5YlIp+LHmS9K05s5hs6dK7bfMudcmtTcWSOKD5RASVzg27iipWm9T+NduR4dWL Z2bCpe95kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRr9EcJ34BT4NI2tYPYpe0B0MQOp+UtDOd2Xrp4Ao XsNbYI86krgx3/MiyhynFjvn4vwETjrysRdTQFgEXAljBCLeNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxNnmFCUctm6OHeH6tWPSXJE7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRYE83tH9htpyVATiooT/rJiGHIfgXXvuhI9vwJN89WVO9R0tarUwIt7i7NiVJNL9jNC r2VPLfZa8ts/I6OTYjIAMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: 'Jim Roskind' , 'Kyle Rose' , 'IETF QUIC WG' , 'Brian Trammell' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Dec 2016 01:09:42 -0000 On Sunday, November 27, 2016 4:43 PM, Eric Rescorla wrote: >On Sun, Nov 27, 2016 at 4:35 PM, Christian Huitema = wrote: >> On Sunday, November 27, 2016 12:13 PM, Eric Rescorla wrote: >>> On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema = wrote: >>>> ... >>>> Responding to Eric: I am not sure that I understand how the second = option works >>>> for the "rebooted server" scenario. Sure, the rebooted server can = use a persistent >>>> secret to compose the magic prefix of the encrypted payload. But = what about the >>>> sequence number? If it is not within the range that the client = expect, the packet >>>> will be dropped before processing the encrypted payload. >>> >>> Christian, can you elaborate on this? You are referring to the range = of the server's >>> sequence numbers, right? >> >> Yes. If the rebooted server makes up a sequence number for the PR, = the packet could=20 >> be rejected by sequence number testing prior to the decryption = attempt. Also, if a=20 >> middlebox keeps track of sequence numbers it will discover that the = PR is out of sequence,=20 >> which somehow breaks the design goal that "The middlebox cannot = distinguish the public=20 >> reset from other packets." >> >>> If so, it seems like that's fixed by modifying my algorithm to check = the prefix as the >>> first thing on an incoming packet. But maybe I've missed something. >> >> That will work for the client, but an overactive middlebox could = decide that "this packet=20 >> does not look to have the right sequence number" and drop it. I = suppose that we could work=20 >> around that with a creative use of sequence number compression. = Mostly. > > Good point. So it's not totally indistinguishable. Ugh. We now have this proposal in PLUS to augment the public header in QUIC = and carry not just the packet sequence number, but also the "last seen = number" from the other side. If we have that, then it becomes easy for = the rebooted server to set their own sequence number to the packet's = received last seen + 1, and the last seen value to the sequence number = of the received packet. And then, yes, your proposal would just work. = And it would be undistinguishable by middle boxes. -- Christian Huitema From nobody Mon Dec 12 16:09:28 2016 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 DB8BE129ED9 for ; Mon, 12 Dec 2016 16:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 NQ6-Nu8Wv6RZ for ; Mon, 12 Dec 2016 16:09:25 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 A3E90129EEF for ; Mon, 12 Dec 2016 16:08:58 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n204so100689197qke.2 for ; Mon, 12 Dec 2016 16:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uOEbOgcNjK+5p2O95SKkF9gYKObgf2QISqdwQLI3AVI=; b=0qMN63AnJZZdCjxiQeRxgq53La+4TdoqkLy5ZOcXMroHAoQasp8huujlkT9qZ255hT LIVeq3O5oqEiI8CjLWURivxk42xX3o9geWdPNKbqDwxeslEIvsr3wCkvZ/eyHuScKwcT lX4zriV8MGgrmUwqyhFc6KSK90j3wlthAqoCFIutNMMkZG5R75u3ikv3aUTMqsPYb9V0 j/OQkAwKExRqwX5ctvGPZnfQ8nW2Wyp/jJGSq3+P2Y1Wb+4+jrAR22BOMqeq03f7AmRQ 714kuVz0+PzqgSiABR3U/xQLtzL4kBiyZjLhihvv5xdgSNnu1w8tdosmeE2jxzAMm++b 8LnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uOEbOgcNjK+5p2O95SKkF9gYKObgf2QISqdwQLI3AVI=; b=eddDj7Ph0tFc2CwLi69aZiqoFFARRHnLDoG/nckXZ7IrgOUy57gIdBW4j8APGm588N cDErNYsvfs+D+Ux0CrAL0lSMiE1+Z0eBah929kcpIsZsYx8okd7e0DuKodEGCi2SUFET kOZGBiAxpwgoeBtPtdBfMvxYlmRHbyL+vpwt0UiQP4TJJWVM6WnO57k5VxEJwRuYBsn1 0DVjjWcXUkdHQmhM0BiLLD6K6EN2Ig8AkRm8UsXFQcd45iYcqhlgdZA8nksCGwqgwIc1 bQ8frQ9rTxblZW5MbrwQP2Hit/uzun3CDcCaRLnGrwv1Yd+cb/FBc5eju7I1OAeilrPH d9vg== X-Gm-Message-State: AKaTC01YqnNPm6ok3LLkxSGsMmh5uZCHM773d3cWVoJMgGpV7yaYf+ESxFrwV5kgkweOH68/qwC2co3xDTWNpA== X-Received: by 10.55.12.2 with SMTP id 2mr81139644qkm.68.1481587737758; Mon, 12 Dec 2016 16:08:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Mon, 12 Dec 2016 16:08:57 -0800 (PST) In-Reply-To: <011301d25414$580de370$0829aa50$@huitema.net> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> <011301d25414$580de370$0829aa50$@huitema.net> From: Martin Thomson Date: Tue, 13 Dec 2016 11:08:57 +1100 Message-ID: Subject: Re: Public reset PR To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 00:09:27 -0000 On 12 December 2016 at 12:09, Christian Huitema wrote: > We now have this proposal in PLUS to augment the public header in QUIC and carry not just the packet sequence number, but also the "last seen number" from the other side. That only works if you include the entire packet number. That's a lot of bits to be sending on every packet. This discussion makes me wonder if it is possible to encrypt the packet number. I think that it's possible. From nobody Mon Dec 12 16:25:31 2016 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 AC5C0129F80 for ; Mon, 12 Dec 2016 16:25:29 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 CxwmeCG5i9cH for ; Mon, 12 Dec 2016 16:25:28 -0800 (PST) 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 F3F52129EC6 for ; Mon, 12 Dec 2016 16:25:27 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id v84so106553350oie.3 for ; Mon, 12 Dec 2016 16:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=syBaQh0KsRO3Mf5SBUGt8f4D99eRomTciQWg1e6826Q=; b=ffoMK/r6lvXw3wggyMTw3f7w29QH3G0GcMJ5KGMuOC7Q464Ix3OhPLFl7efF9ETYjX LbLxhPKmVaXZvVA7GcXY1d8wOZ3IJE3svcuKNNpn8M8bo8uArRbxXe5k9vRVxtUYYprU lwCraMKLgP1GJeeP5+EmE+u/5KeK6w7KJSQwrfhKgs7o2fpwnQtaBNPDKGVDEK2Hsd9b orwSMdiM5cUtM2c4sJYiFGJg8ibBfHYJPRtHe3uS/8GrUOjTVwhlu/dxshOG2Dey4L9A FEA2shY7oJ4aWm252J3R9+sKr6vicOZLVvXh0iNpdISqrF6IY3afMsoumSX+yYg1h7HQ OK5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=syBaQh0KsRO3Mf5SBUGt8f4D99eRomTciQWg1e6826Q=; b=nK69azQ+dQo61ufHtoiB3Ft+JyA0ZXsWwJtD2CXpYzHjUbI1pKmrqr8sni4gd4O6j0 3qMRP8Ygj+xqyAWqzFRZyW4W0ZsHuhIhLuD345AJrqDhJxUG7isQFOrmCIjS4m8SbWqW c5kkb8r+2/j2SjvTIBfrd3d+VgoUHcDYaNBQe+o+oIn9DPpFp2MR9rFenFAcoZViptGb 3r2N27Sb5VFq3/yIewMFNz9g0D+/9nCr44RdaEI4hfhYdmrIbIs62j7SnuB+5aPA8D8O n1j1P9GA/dNnycffdChZr/rBrqdrgv1mXW0K6r3L8HM6DahNjS48G2lDJw9/h0gX5cPI WvPQ== X-Gm-Message-State: AKaTC00UTJX/KAKDrFzCIldxOfrutDSID8Z5NtmCbrSYkuUFOuBrhPhDDk1sOtg5C+1EfuTiVxGKcT+3w6iAcA== X-Received: by 10.157.20.176 with SMTP id d45mr50484156ote.2.1481588727333; Mon, 12 Dec 2016 16:25:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.56 with HTTP; Mon, 12 Dec 2016 16:25:26 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> <011301d25414$580de370$0829aa50$@huitema.net> From: Martin Duke Date: Mon, 12 Dec 2016 16:25:26 -0800 Message-ID: Subject: Re: Public reset PR To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11440332cbca3d05437f4125 Archived-At: Cc: Christian Huitema , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 00:25:30 -0000 --001a11440332cbca3d05437f4125 Content-Type: text/plain; charset=UTF-8 If I recall correctly from the way Chromium QUIC crypto works, the packet number is an input to properly set the IV for decryption. I am far from a TLS expert, but I believe it introduces diversity into the encryption between datagrams and is necessary for the sender to explicitly provide. I think there's a way to do this securely if we accept the expense of PKI sign/authenticate operations. Any client that thinks it is in mid-connection with a server, by definition, has its certificate and public key; therefore, the server could sign a public reset in its private key with reasonable expectation that it the client can authenticate it. Sadly, in the other direction only authenticated clients could do the same. On Mon, Dec 12, 2016 at 4:08 PM, Martin Thomson wrote: > On 12 December 2016 at 12:09, Christian Huitema > wrote: > > We now have this proposal in PLUS to augment the public header in QUIC > and carry not just the packet sequence number, but also the "last seen > number" from the other side. > > That only works if you include the entire packet number. That's a lot > of bits to be sending on every packet. > > This discussion makes me wonder if it is possible to encrypt the > packet number. I think that it's possible. > > --001a11440332cbca3d05437f4125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I recall correctly from the way Chromium QUIC crypto wo= rks, the packet number is an input to properly set the IV for decryption. I= am far from a TLS expert, but I believe it introduces diversity into the e= ncryption between datagrams and is necessary for the sender to explicitly p= rovide.

I think there's a way to do this securely if= we accept the expense of PKI sign/authenticate operations. Any client that= thinks it is in mid-connection with a server, by definition, has its certi= ficate and public key; therefore, the server could sign a public reset in i= ts private key with reasonable expectation that it the client can authentic= ate it.

Sadly, in the other direction only authent= icated clients could do the same.
On Mon, Dec 12, 2016 at 4:08 PM, Martin Thomson= <martin.thomson@gmail.com> wrote:
On 12 December 2016 at 12:09, Christian = Huitema <huitema@huitema.net&= gt; wrote:
> We now have this proposal in PLUS to augment the public header in QUIC= and carry not just the packet sequence number, but also the "last see= n number" from the other side.

That only works if you include the entire packet number.=C2=A0 That&= #39;s a lot
of bits to be sending on every packet.

This discussion makes me wonder if it is possible to encrypt the
packet number.=C2=A0 I think that it's possible.


--001a11440332cbca3d05437f4125-- From nobody Mon Dec 12 16:46:09 2016 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 DFEC0129EB7 for ; Mon, 12 Dec 2016 16:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 C0WIcW6w8Aau for ; Mon, 12 Dec 2016 16:46:06 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 5C794129858 for ; Mon, 12 Dec 2016 16:46:06 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id q130so101403569qke.1 for ; Mon, 12 Dec 2016 16:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MyBJCPK6GMPT3EyryvuiVwa/Sq40Fyal4pA2whIEM4o=; b=NF1SCLHVBtaVDI1zJg19j8lECVneUs8vXAFsHZXTR0+6ZGHR7RR1X2poT4XHDTugl3 jjlup9ZzjR1Z46DfzpXZyWkh93SxyrsIss78Vi4rCVLkmfQZSGCsBsxoL2Sz++UcgAXm BieG17H/O214UjltglZ1BzfeGo2G4L8mOnO46aq2KomPxmmERSZBQaWExWNyH5aBa97o UXIC5MfrHclni/t+tj3kcMSzbbFlkSlHYQotd8fic05TBbK4ifXhGQdPpU3im2lxgpB1 XUy8vuwRCajTSov3kcTYSl8xVdxMd458cNOoxedMnREpZbnUEVXIOM8EsJPD8WsrIuZ8 bgGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MyBJCPK6GMPT3EyryvuiVwa/Sq40Fyal4pA2whIEM4o=; b=F129lxsKenqKzenb0Hrukq+Vd2EYBQsm4fc1t7iA+JMpzievjUhReGcdWEHhDP52YN Y+rctmSjDwsPtN7Sn/2aIq7qkLvwwCi9nnBdkhj8IQ/B/bKMFDjRcvojLrJ+1yYCeWlR b1z+P1ld0dMnnSx8/bQnMRzaJY+41tYpR2LnKAUMdf1Ssbj3IWR4irehArx/RmSh/3uk GhF6Q0NhdQiw0lx/ceFzgbwJB3qZRkZdH+UovTlhQFUex+p0tNMbKcQFyo3/oSh0q6o5 uTVz0neM3HrS2e26EAnAXcBxxr6wUgFUowNqYZL4DMgiW/z6Yvky4KkemEnp9sF/FYLZ PbDA== X-Gm-Message-State: AKaTC01AxliZsH6fjcozSIj4L2HhufO1Dx8kdQvtfNkKr5lAvVyl8//MT7MraA8pTn7UmL7DhMF80LubGo0tKA== X-Received: by 10.233.235.72 with SMTP id b69mr90533621qkg.144.1481589965543; Mon, 12 Dec 2016 16:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Mon, 12 Dec 2016 16:46:04 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> <011301d25414$580de370$0829aa50$@huitema.net> From: Martin Thomson Date: Tue, 13 Dec 2016 11:46:04 +1100 Message-ID: Subject: Re: Public reset PR To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christian Huitema , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 00:46:08 -0000 On 13 December 2016 at 11:25, Martin Duke wrote: > If I recall correctly from the way Chromium QUIC crypto works, the packet > number is an input to properly set the IV for decryption. I am far from a > TLS expert, but I believe it introduces diversity into the encryption > between datagrams and is necessary for the sender to explicitly provide. Yes, but the (nascent) idea is that each peer could run the value through a PRP to recover the actual packet number. The observation is that the packet number is only (legitimately) used by an endpoint that also has a decryption key. So you could do a lot as long as you were willing to accept a few trade-offs. It wouldn't require fancy crypto. It wouldn't be very effective against a motivated attacker, and it wouldn't prevent spoofing, so it's not clear how much help it would be. And you would also have to burn at least one bit of the (truncated) packet number to even have a half-plausible story. But then, the benefits to reducing mucking around on-path might be worth spending the time. From nobody Mon Dec 12 18:26:29 2016 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 B5484129554 for ; Mon, 12 Dec 2016 18:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 dORXk5yjLXe8 for ; Mon, 12 Dec 2016 18:26:25 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 6D546129553 for ; Mon, 12 Dec 2016 18:26:24 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id p16so94680986qta.0 for ; Mon, 12 Dec 2016 18:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t9IFMWR6p90EGUJjld+WT6LO4lnnrox0jM9gnp+wKqM=; b=U6ufsQVNfnW8Sau+/P59toYd269RJlpP2PUhf/XCfbxCJ74fugEx6yBw+FReOhurrc SxSSftARkf/9ikMnIQRrVY21weQF4Z0SSdinVdizqmNMcE8ShSzoMafRX43D9DpGFOou w/bNUrEzEj6JPi9JU17MA1vorq5ddJwy/zIxo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t9IFMWR6p90EGUJjld+WT6LO4lnnrox0jM9gnp+wKqM=; b=WkwlwkzMJrJs5xCOsUToWtcv+tVuN4SWmO8oBFNCCFGCvJ4DZKbZ8/fKxppPcHWXpv dJs7v+OhycmFEIOjl70dhzk9wvl3a+4W0UVoDfqslILCeEcGOP8BAku1TRlDYcUivm9I gtqeYiAjVYNMIPt5IcHSHeN/8tSzDA0PufGz3Jl6kxHAgPJ04orv/LJr3U2NA+oM7TWh fEfSPybw/J17aNSkhsNTLbKlxG+dI4QZpGpk8SYqQF302ndte0y7ugdvmXQwyDrG5+ZQ e3xzKXQ3Ph3EuDkA1QGJedvKTWIzC6SB+VZ5Cg0rh/4ILZSP8iOaVIpYX3FVhtQJkjoD 9w+Q== X-Gm-Message-State: AKaTC00vGKTJRKEvZARI8Mj+xiXKdg4nviu9K2LHPckrp1g5/1oUdnbtu0JFWA2DuSp6m38+j3b4M23D/1FgqA== X-Received: by 10.237.36.154 with SMTP id t26mr80091004qtc.188.1481595983660; Mon, 12 Dec 2016 18:26:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.180.2 with HTTP; Mon, 12 Dec 2016 18:26:22 -0800 (PST) X-Originating-IP: [2001:470:1f07:121:88d4:dbff:fed8:cd83] In-Reply-To: <71F548B4-7E61-406E-AC25-0FFBFD4DEAE5@tik.ee.ethz.ch> References: <938D954F-A61D-4779-90D6-CC2800CF75DE@tik.ee.ethz.ch> <71F548B4-7E61-406E-AC25-0FFBFD4DEAE5@tik.ee.ethz.ch> From: Kyle Rose Date: Mon, 12 Dec 2016 21:26:22 -0500 Message-ID: Subject: Re: Review of draft-ietf-quic-transport-00 To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a1141058e4ea47d054380f223 Archived-At: Cc: Mike Bishop , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 02:26:28 -0000 --001a1141058e4ea47d054380f223 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 7, 2016 at 4:46 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > The idea is really not to have an infinite number of streams open. You > still have an maximum number of open stream and as Ian pointed out if you > open them in order, you probably just keep the last X open. My point is > that closing a stream can be a local decision. That doesn=E2=80=99t mean = that quic > couldn=E2=80=99t tell the higher layers about it. It=E2=80=99s again just= a local interface > question. > The question here seems to reduce to a design choice regarding the degree to which we want to bake application-level semantics into the transport. If QUIC is going to be used primarily for protocols like HTTP in which stream data begins in a way and at a time that the receiver understands (e.g., on a specific application-defined stream ID right after the headers come in on an associated stream), is often of a predetermined length, and is logically dead for the remainder of the connection after that number of bytes has been transferred, then baking the EOF into the transport probably makes sense. If OTOH some application uses the stream ID as a generic mechanism for serialization of data, but without any way for the receiver to predict stream IDs, nor any way for it to know when the last possible data has been sent on that stream, then EOF in the transport is vestigal. I'm struggling to think of a not-crazy example here. Even in this case, its presence doesn't do any damage, as an application could simply not employ it. And yes if you send one object over a stream and you want to let the other > end know that you are not planning to send any additional data, there > should probably be a EOF signal at the layer that knows about the objects= . > Again, in this case there could be a local interface to the lower layer > telling quic that you do expect any data anymore on that stream or that y= ou > are not will to accept any data any more on that stream, so quic could se= nd > the right error message if it anyway receives data on that stream. > Is this really that different from the existing EOF? The receiver can already choose when to close the stream by telling the stack to send a FIN. Under this proposal, the application would have to send an app-level EOF (other than cases in which it is implicit, e.g., via Content-Length) and also tell the stack to reject future data. Baking the EOF signal into the transport seems entirely appropriate if we decide the stack has to know when not to accept any more data on that stream, anyway. I don't think this particular signal has the potential to be like URG, which turned out to be mostly useless at the transport level (I imagine largely because of the strict ordering of TCP and the not-really-OOB-data semantics) and is a good illustration of the #allthefeatures approach of over-designing an API. FIN, by contrast, seems integral to the lifecycle of a stream. It also seems like the stack's state maintenance is similar in both cases: as long as the stack needs to know when not to accept any more data, it needs to retain information about which streams have been closed or put into a "reject" state. The application, of course, is going to need to decide independently which streams it's going to retain state for, regardless of which lever the stack supports (close or reject). Kyle --001a1141058e4ea47d054380f223 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 7, 2016 at 4:46 AM, Mirja K=C3=BChlewind <mirja.kueh= lewind@tik.ee.ethz.ch> wrote:

The idea is really not to have an infinite number of streams open. Y= ou still have an maximum number of open stream and as Ian pointed out if yo= u open them in order, you probably just keep the last X open. My point is t= hat closing a stream can be a local decision. That doesn=E2=80=99t mean tha= t quic couldn=E2=80=99t tell the higher layers about it. It=E2=80=99s again= just a local interface question.

The questio= n here seems to reduce to a design choice regarding the degree=20 to which we want to bake application-level semantics into the transport. If QUIC is going to be used primarily for protocols like HTTP in which=20 stream data begins in a way and at a time that the receiver understands=20 (e.g., on a specific application-defined stream ID right after the headers = come in on an associated stream), is often of a=20 predetermined length, and is logically dead for the remainder of the=20 connection after that number of bytes has been transferred, then baking=20 the EOF into the transport probably makes sense.

If OTOH some = application uses the stream ID as a generic mechanism for serialization of = data, but without any way for the receiver to predict stream IDs, nor any w= ay for it to know when the last possible data has been sent on that stream,= then EOF in the transport is vestigal. I'm struggling to think of a no= t-crazy example here. Even in this case, its presence doesn't do any da= mage, as an application could simply not employ it.

And yes if you send one object over a stream and you want to let the other = end know that you are not planning to send any additional data, there shoul= d probably be a EOF signal at the layer that knows about the objects. Again= , in this case there could be a local interface to the lower layer telling = quic that you do expect any data anymore on that stream or that you are not= will to accept any data any more on that stream, so quic could send the ri= ght error message if it anyway receives data on that stream.

Is this rea= lly that different from the existing EOF? The receiver can already choose w= hen to close the stream by telling the stack to send a FIN. Under this prop= osal, the application would have to send an app-level EOF (other than cases= in which it is implicit, e.g., via Content-Length) and also tell the stack= to reject future data.

Baking the = EOF signal into the transport seems entirely appropriate if we decide the s= tack has to know when not to accept any more data on that stream, anyway.
I don't think this particular si= gnal has the potential to be like URG, which turned out to be mostly useles= s at the transport level (I imagine largely because of the strict ordering = of TCP and the not-really-OOB-data semantics) and is a good illustration of= the #allthefeatures approach of over-designing an API. FIN, by contrast, s= eems integral to the lifecycle of a stream.

It also seems like the stack'= s state maintenance is similar in both cases: as long as the stack needs to= know when not to accept any more data, it needs to retain information abou= t which streams have been closed or put into a "reject" state. Th= e application, of course, is going to need to decide independently which st= reams it's going to retain state for, regardless of which lever the sta= ck supports (close or reject).

Kyle
--001a1141058e4ea47d054380f223-- From nobody Tue Dec 13 02:13:16 2016 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 C2214129A52 for ; Tue, 13 Dec 2016 02:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=3.595, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-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 IFKubO5j6VIu for ; Tue, 13 Dec 2016 02:13:13 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CEF0E129A42 for ; Tue, 13 Dec 2016 02:13:12 -0800 (PST) Received: from [172.17.140.41] (unknown [147.67.241.226]) by trammell.ch (Postfix) with ESMTPSA id 869431A0213; Tue, 13 Dec 2016 11:12:41 +0100 (CET) Subject: Re: Public reset PR Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_656D3EF2-B566-44B3-8205-B32E75421EA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Tue, 13 Dec 2016 11:12:40 +0100 Message-Id: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> <011301d25414$580de370$0829aa50$@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christian Huitema , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 10:13:15 -0000 --Apple-Mail=_656D3EF2-B566-44B3-8205-B32E75421EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all, > On 13 Dec 2016, at 01:08, Martin Thomson = wrote: >=20 > On 12 December 2016 at 12:09, Christian Huitema = wrote: >> We now have this proposal in PLUS to augment the public header in = QUIC and carry not just the packet sequence number, but also the "last = seen number" from the other side. >=20 > That only works if you include the entire packet number. That's a lot > of bits to be sending on every packet. That depends on how many bits of the packet and the echo are necessary = to (1) support RTT and loss measurement on path and (2) support = plausibility checks to re-establish state at middleboxes (the = association/confirmation cycle in draft-trammell-plus-statefulness). The answer to (1) is "not very many"; basically you need to limit the = probability of a packet number wraparound through a burst of lost = packets. Ian's mentioned 16 bits as a reasonable assumption here. The answer to (2) may be "not very many" as well, if one is prepared to = accept resetting the window of in-flight packets during NAT rebinding or = firewall state re-establishment, which seems reasonable to me. The = tradeoff here then becomes number of bits per packet versus strength of = assurance of the association and confirmation signal. I'll note that we = have lots of experience with 32 bit packet number equivalents in TCP, = here, though with Connection ID as an additional source of bits to = resist off-path attacks, we might be able to get by with fewer. > This discussion makes me wonder if it is possible to encrypt the > packet number. I think that it's possible. Why not, though this is primarily a question of requirements: an = encrypted packet number/echo would be difficult to use for measurement, = and practically impossible to use for state re-establishment. A = mechanism allowing endpoint verification of packet and echo number = integrity, though, would maintain this utility while reducing reward to = the meddlers. Cheers, Brian --Apple-Mail=_656D3EF2-B566-44B3-8205-B32E75421EA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYT8mYAAoJEIoSt78L6kajJDYQALQxotI29CIvKRQXeo0kxrpu pOuhCxs6R6gjoQvsqv+b6eyUoXi+XbuzaJEZcJuJ9Rf0jRoo6uq5an4MJt5OZp3z rcVq5LC1l3VHMP16bGCuF5rfFnhfS1uVeSELA8liYF/BpQs/VzsY6I61bn6x+eQI af31BzkCEyCJCsLgmBE9UgwGfiJf4zoGoXDAommr4Q9wAPwsVIMesu2euDf1oO6D YWca9QbppNpjB09sLJyf7W+PySmdhELmpHBXBA1Ab2WuOCa47PzbaKJ9BxScofXR 89lPTOHDH40Hns4Q0gzyNO6hTSFvkBHyg7D8GIjJ9yqlfN7NgaQN5dF7XVsoC3um 69utyPVTmp2EBDReuSnlreBllDXGkw6BsSCiX7Uznuo6wNs5e07NHODCIB/IJDUZ yoFkovs0k8gFkSvQh5L/Ak9tRa2KTfDdVU/7SW9TAPtkV2yY5tYM2y76pCo8YAay ZQfvPSe1smCuS48njHWckweOnElrHSVX4iW95u11jFwwpvJZ5AKMUlIyI6xlNPw9 Ci7TVLOiQ/6gaEyNzxsy8JXKiICOPdpgPJw9Xg9tbsbK1UK3tTw/PiEwZqVlzLwz o5VENCtoAjSmDk4HU3Us3ORBCxgPpb+MnX6TOJrXnJvH41ZPF3FJLN0PlqPoN+kZ avcNzqXcku01U+oJ59qd =ABRv -----END PGP SIGNATURE----- --Apple-Mail=_656D3EF2-B566-44B3-8205-B32E75421EA3-- From nobody Tue Dec 13 14:29:09 2016 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 2EBCF129BFE for ; Tue, 13 Dec 2016 14:29:08 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 uzaDxjVcLMgX for ; Tue, 13 Dec 2016 14:29:06 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003: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 92120129B62 for ; Tue, 13 Dec 2016 14:29:06 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id v84so1358349oie.3 for ; Tue, 13 Dec 2016 14:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=KQEM10dow+LVRRIjD2wm5rzuy95q24uKY3G9pQjgK7s=; b=cYGhmbtaXDmod7V8ctZk2NN2sLAbam9aUV7m8EN2mnk7hDftxgXNCY3a0PbJjsbjAz 71wJOkJSTokDcVUi+eqqx7UP9HdBqsoUkNkCUultPhT+uHaFLe67SUR288c0OM3782rT p4XYvcJUOpVS8oMHIlPV3yNI2zoCF3WKYTq5n7QCtVtfCjCrtk7ROMwCyBWK7eOuGg/A 0srNj3RcPHBOZAIOFMxIWMf82R957uF9pAGhi2Tc27uPsXdFR3QJ+WlWHy55tC+YL2ha +neLUCP5rZGdAHbN8cKViPpH6ytqQO/9tI4vNKxz3gK/AXCYDHf97e8bHUlUcjqIjB42 2AjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KQEM10dow+LVRRIjD2wm5rzuy95q24uKY3G9pQjgK7s=; b=c/3eqyNqtqwLhUqeyMp4mbG6Nl67Qn1+HyE39S8QQqfXBApBmiLfMCj67JevgHE+8r tXfZZEjGsuKoRZNL/EAOw7OgYakUo4pxrnCYhpmp/THILAeBBSyIQcHr7D12mXjRwmqs rs06oZ1JWf68rKbZRqsr/f337ZWUfs7LY0zOKCo9r+pSvEzuKc0DrwLAVFEAdu7VnD8N 520ySzMI14DqD3DgqRVQRUdrDSzfIWombuJlh8No+yvslCatAd7RvmTWJ6lP7HTxA0Vv cDof39dazBehWqWR4C8n4QTFUjtWL9vJiQgwAO43pM5zQRXvSNp0dfx5KIC+vvRtOwvl 51uw== X-Gm-Message-State: AKaTC03uxn+dzb7p3BwGu1zMtjA5myzEn8x1U0pf8Yt9KDyKhlKOtSRxtS9JIneIgiw00BRu7vDq1kzESEv1YA== X-Received: by 10.157.38.151 with SMTP id l23mr52002869otb.97.1481668145907; Tue, 13 Dec 2016 14:29:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.56 with HTTP; Tue, 13 Dec 2016 14:29:05 -0800 (PST) From: Martin Duke Date: Tue, 13 Dec 2016 14:29:05 -0800 Message-ID: Subject: TCP Fallback? To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1143042e830e82054391bf03 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 22:29:08 -0000 --001a1143042e830e82054391bf03 Content-Type: text/plain; charset=UTF-8 At the moment, a lost CHLO can mean any of the following: - Host not reachable - Path congestion - RF loss - MTU too large* - A middlebox will not carry UDP/QUIC many of which have very different responses. The spec needs some guidelines on client (and server!, the same applies to SHLO without necessarily being symmetric) behavior for many of these scenarios. * I owe the group a PR on this subject, see here: https://github.com/quicwg/base-drafts/issues/64#issuecomment-265016665 Martin --001a1143042e830e82054391bf03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the moment, a lost CHLO can mean any of the follow= ing:
- Host not reachable
- Path congestion
- RF loss
- MTU too large*
- A middlebox will not ca= rry UDP/QUIC

many of which have very different res= ponses. The spec needs some guidelines on client (and server!, the same app= lies to SHLO without necessarily being symmetric) behavior for many of thes= e scenarios.

* I owe the group a PR on this subjec= t, see here:=C2=A0https://github.com/quicwg/base-drafts/issues/64#i= ssuecomment-265016665

Martin

--001a1143042e830e82054391bf03-- From nobody Tue Dec 13 15:25:09 2016 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 31B79129C56 for ; Tue, 13 Dec 2016 15:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] 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 3KHvLYaO5Yl4 for ; Tue, 13 Dec 2016 15:25:05 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::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 7A459129C50 for ; Tue, 13 Dec 2016 15:25:05 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id 137so3813767vkl.0 for ; Tue, 13 Dec 2016 15:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+nZQReHtMwP5hl0wkyNfQo9LF9Ahf6RZvL6N/xgMLmo=; b=Jg+k4gvzx4YSKTvL+4YS2URE2DsMHM1NEi1i74F1pjngejl4TKzX05vbVFCIkqfNS+ 5HYrS2pbKhgxkz8b89J6561OMkUNTvzLTUVGVFY0phdxU9oTiPTQ4DvPF8VuYXm0It5r YFOlYzPLI5uXhuu8kD+oepbM43a55Y+xS2eVUHxPt+jeVnINguV+b58Tl/FSb58VC1oM Fe3T1JHiyT8xG0jSt+o9gWEByF7HN+tD3991hqbFAYyveJhd9hdjPTOR844KP81nvXlH 6qlY0nktqbS2wlutz/c81TBPQzw9z7pwu1olYKAHVSSSABOI9/NKgoBPcFVs5Sozi1Bb d/lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+nZQReHtMwP5hl0wkyNfQo9LF9Ahf6RZvL6N/xgMLmo=; b=O4nGANzqqLxsdstLR/khAtCPlsesjDr1NC27M7niMBnLgkPFQ/+cDTrqPB3brJ623f sCmbZVeVBumFtjSDmxtbc+o+zvHwsFejw5OdcKvlou++LVeWHHqI2/pBC0oJ1AbuKHkS FhoCb0fhZU5AHmJsjcri8GQMhubUf1uvT0YcYIVzFR2dvpDtYPbD+uWz4ubjXbbJbbnn d0AJVSk2jqxrCuIJHxFZeuSMEAAQnHIw4GGQzWvb5eUrWn1SVlJ6qObqbTbU0eN/udAc as5uSdsFAMtJe3tZIKRC7ymQnx0UyhbQ21z6me1TYsofSOj5Nn2LbIK4J3INydIuYYCR /R+g== X-Gm-Message-State: AKaTC01Cg4Jc9zARXsgMV06KFV5YOieyHlwXso4ckx5lcOad5/rasGghNJdLZfvwS9iMrsM61tibKRZOoRqxW/y+ X-Received: by 10.176.80.154 with SMTP id c26mr83483390uaa.136.1481671504552; Tue, 13 Dec 2016 15:25:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 13 Dec 2016 15:25:04 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 13 Dec 2016 15:25:04 -0800 Message-ID: Subject: Re: TCP Fallback? To: Martin Duke Content-Type: multipart/alternative; boundary=94eb2c190cf0b42bda05439287fa Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Dec 2016 23:25:07 -0000 --94eb2c190cf0b42bda05439287fa Content-Type: text/plain; charset=UTF-8 On Tue, Dec 13, 2016 at 2:29 PM, Martin Duke wrote: > At the moment, a lost CHLO can mean any of the following: > - Host not reachable > - Path congestion > - RF loss > - MTU too large* > - A middlebox will not carry UDP/QUIC > There are two classes of responses -- ones that can be fixed by retransmissions, and ones that cannot. To your email subject, TCP fallback should exist to catch the ones that cannot be fixed by retransmissions. QUIC stream 1 (crypto stream) is reliably transmitted, which means that QUIC will retransmit the CHLO (and SHLO) n times before it gives up on the connection. That said, at least one on this list is separable. An implementation could try different MTU sizes if the CHLO fails a few times before giving up. This may be worth pointing out explicitly, though, as you suggest. - jana > many of which have very different responses. The spec needs some > guidelines on client (and server!, the same applies to SHLO without > necessarily being symmetric) behavior for many of these scenarios. > > * I owe the group a PR on this subject, see here: https://github.com/ > quicwg/base-drafts/issues/64#issuecomment-265016665 > > Martin > > --94eb2c190cf0b42bda05439287fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 13, 2016 at 2:29 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
At the moment, a lost CHLO can mean any of the following:
- = Host not reachable
- Path congestion
- RF loss
- MTU too large*




* I owe the group a PR on this subject, see here:=C2=A0https://github.com/quicwg/base-drafts/issues/64#issuecomm= ent-265016665
=
Martin


--94eb2c190cf0b42bda05439287fa-- From nobody Wed Dec 14 12:20:48 2016 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 EDA78129472 for ; Wed, 14 Dec 2016 12:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 VFXIt2hoHGQU for ; Wed, 14 Dec 2016 12:20:38 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0095.outbound.protection.outlook.com [104.47.38.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96962129473 for ; Wed, 14 Dec 2016 12:20:38 -0800 (PST) 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; bh=nIsheQFUY5MYq0M4VpAGh+FBGSpZNMDML/KHqILK0T4=; b=Skv4WQ2kZrU2vxoM8njDMbRLi8hbg5VJI40sReWRFSrcIN8BgMyrIkJLNqd0i39cZCKzMzQKrHn/vZpOWUPcgu7Y24fhVfb0mjDxpiMBx76xwhpRg67BT3lv/dkAs3DGFeg++Woz90ALgYAFJMwwVczARyGQ7ero1e+EOBsqrZY= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 14 Dec 2016 20:20:36 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 20:20:36 +0000 From: Mike Bishop To: IETF QUIC WG Subject: HTTP/QUIC: Two SETTINGS PRs Thread-Topic: HTTP/QUIC: Two SETTINGS PRs Thread-Index: AdJWRF0vJ9lL46HQTi67VgHC6GjC2w== Date: Wed, 14 Dec 2016 20:20:36 +0000 Message-ID: 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=Michael.Bishop@microsoft.com; x-originating-ip: [170.173.8.12] x-ms-office365-filtering-correlation-id: 7c371e68-d937-44e5-2a4f-08d4245eaa4b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:fyvB2cVamTVIlng6dlcmknrDdFSzuFdT2B1MzNUxgNUxlU/USVU1v6y9Lb3hnhPS6/wjdiQZeMb6Zi/8TV+XJbpjm4Zav7SATOa9yZZSSDXI9qoLzDGCirdOrL4QtSLTgH4nSwx1X/u4Uhyic7UZ9Q2yMDO6wu58maLcTEHUhfHX9wvsDQrdw4o7Ailic7DtiGQFCl4ucnD/2K8h6nT+sw7tn0Rocj0P7KDjP8THkwGKG/MXiOZBgZOxUTAP68+fyGIYXemMr7ZUxSe/uSmC3mQ89xggN2bc6rtNjIFvtZCpbyH2SDXRaSSmeePAbJdtZmmXuqdHzICdC4SeFxfSPvkKo5BaTJtyDbSZnfotxU/XXKomUaIVwwf2zOHHpuaQU1gX3br/whJtQM7OzsVo0g9+LFqTJNM5+DQ1Z7ijxJWO1yemho3zH+CVAwl5523iRtt0nZdJLY2333+9ALMvVJ4RTclRONO1rNVC1UbZr30= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(189002)(199003)(5660300001)(8990500004)(450100001)(101416001)(105586002)(6506006)(81166006)(8676002)(38730400001)(68736007)(81156014)(77096006)(97736004)(2906002)(106356001)(99286002)(6916009)(76576001)(86362001)(5005710100001)(9686002)(10290500002)(86612001)(8936002)(6436002)(10090500001)(6116002)(3660700001)(7736002)(790700001)(7906003)(2900100001)(3846002)(102836003)(50986999)(606005)(122556002)(74316002)(33656002)(7696004)(110136003)(107886002)(66066001)(54356999)(3280700002)(92566002)(189998001)(25786008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270870B6518544A9A1189A46879A0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 20:20:36.7159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Dec 2016 20:20:43 -0000 --_000_BN6PR03MB270870B6518544A9A1189A46879A0BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have two open pull requests I'd like to draw folks' attention to, in hope= s of getting more review than just Martin - thoughtful though his comments = always are. https://github.com/quicwg/base-drafts/pull/80 merges the HTTP WG draft (ful= l disclosure: by me) creating a SETTINGS-frame alternative called EXTENDED= _SETTINGS. In this pull request, the SETTINGS frame is fully replaced by t= he proposed EXTENDED_SETTINGS functionality and existing settings values ar= e redefined into the new space. The notable differences are: * Rather than being a fixed 32-bit length, settings are TLV records w= ith interpretation defined custom to the setting. Includes option to decla= re the value as zero-length and use an embedded flag as a Boolean value, si= nce many settings are strictly yes/no. Reduces length of a setting in most= cases, and permits greater flexibility if a setting needs to communicate s= omething more complex (e.g. a list of values). * Ack is requested or not on a per-SETTINGS-frame basis, since many s= ettings don't actually need acknowledgement. If an ACK is requested, the A= CK tells the sender which settings in the frame were recognized and which w= ere unknown/ignored. That can potentially do away with bidirectional setti= ngs that merely acknowledge mutual support for an extension - client can se= t the value to "true" and requests ACK, server indicates comprehension, don= e. (Note that while this is useful information, it's also a fingerprinting= vector we should note in Security Considerations.) This pull request explicitly doesn't solve the synchronization problem that= SETTINGS has with regard to QUIC, which is that you can't tell when in eac= h stream the new settings take effect, since there's no intra-stream orderi= ng in QUIC. (Tracked by https://github.com/quicwg/base-drafts/issues/75.) https://github.com/quicwg/base-drafts/pull/84 builds on the previous reques= t and attempts to address that problem, though the same technique could be = applied to an HTTP/2-style SETTINGS frame. It requires, not a single SETTI= NGS_ACK, but a collection of them: * One on stream 3 which indicates the highest non-idle locally-initia= ted and peer-initiated stream IDs * One on every message control stream that was open when the SETTINGS= frame was received. With the first, the sender of the SETTINGS knows all streams that have the = new settings from the start; every other stream must either close (still un= der the old settings) or carry a SETTINGS_ACK frame (accepting the new sett= ings) within the timeout. There's a race condition where a stream's openin= g frame is still in flight when the SETTINGS is received, and I attempt to = address that as well, but Martin's comments suggest it might not be fully c= overed yet. Anyone see things here to panic about, or should I merge them? --_000_BN6PR03MB270870B6518544A9A1189A46879A0BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have two open pull requests I’d like to draw= folks’ attention to, in hopes of getting more review than just Marti= n – thoughtful though his comments always are.

 

https://github.com/quicwg/base-drafts/pull/80 merges the HTTP WG = draft (full disclosure:  by me) creating a SETTINGS-frame alternative = called EXTENDED_SETTINGS.  In this pull request, the SETTINGS frame is fully replaced by the proposed EXTENDED_SETTINGS fun= ctionality and existing settings values are redefined into the new space.&n= bsp; The notable differences are:

·       Rather than being a fixed 32-bit length, set= tings are TLV records with interpretation defined custom to the setting.&nb= sp; Includes option to declare the value as zero-length and use an embedded= flag as a Boolean value, since many settings are strictly yes/no.  Reduces length of a setting in most ca= ses, and permits greater flexibility if a setting needs to communicate some= thing more complex (e.g. a list of values).

·       Ack is requested or not on a per-SETTINGS-fr= ame basis, since many settings don’t actually need acknowledgement.&n= bsp; If an ACK is requested, the ACK tells the sender which settings in the frame w= ere recognized and which were unknown/ignored.  That can potentially d= o away with bidirectional settings that merely acknowledge mutual support f= or an extension – client can set the value to “true” and requests ACK, server indicates comprehensi= on, done.  (Note that while this is useful information, it’s als= o a fingerprinting vector we should note in Security Considerations.)<= /o:p>

This pull request explicitly doesn’t solve the= synchronization problem that SETTINGS has with regard to QUIC, which is th= at you can’t tell when in each stream the new settings take effect, since there’s no = intra-stream ordering in QUIC.  (Tracked by https://github.= com/quicwg/base-drafts/issues/75.)

 

https://github.com/quicwg/base-drafts/pull/84 builds on the previ= ous request and attempts to address that problem, though the same technique= could be applied to an HTTP/2-style SETTINGS frame.  It requires, not a single SETTINGS_ACK, but a collec= tion of them:

·       One on stream 3 which indicates the highest = non-idle locally-initiated and peer-initiated stream IDs

·       One on every message control stream t= hat was open when the SETTINGS frame was received.

With the first, the sender of the SETTINGS knows all= streams that have the new settings from the start; every other stream must= either close (still under the old settings) or carry a SETTINGS_ACK frame = (accepting the new settings) within the timeout.  There’s a race condition where a stream’s o= pening frame is still in flight when the SETTINGS is received, and I attemp= t to address that as well, but Martin’s comments suggest it might not= be fully covered yet.

 

Anyone see things here to panic about, or should I m= erge them?

--_000_BN6PR03MB270870B6518544A9A1189A46879A0BN6PR03MB2708namp_-- From nobody Thu Dec 15 09:55:46 2016 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 99566129B1F for ; Thu, 15 Dec 2016 09:55:44 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 dJusPGoXYEY9 for ; Thu, 15 Dec 2016 09:55:42 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 C09DB129B56 for ; Thu, 15 Dec 2016 09:55:38 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id a10so18027511ywa.3 for ; Thu, 15 Dec 2016 09:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=diXIujQ9pbuQDzBZcIIMi7b35SKDtadRUqnLo7bURSQ=; b=M/WobqRkyCDpSWtAeeyFYjt9rQwKk77rKP+YX2aehPApA97TYRQ0ICTQom32vgvKeS 5w7AUJfoq2TUoLzRTKVrxOK+Sm53JJWnrAIsY6M+IXuvEHOx5CGZvafTVP1wAbNz3lY7 jiGtkMH7S/9zvGO7D3a+BHanqmFTaw53a85/z7jMhjPKRQWeuqR8rTrqLMh5CGIjEC8O EZWs5qksREVpO0BBvkr7HEoeoN4C5Jeu4/Qywdeyi3fnC4AoFPuVRxwo/dKMk3qnGMDs KL4FL/dshgZJmx1I0XdQD23Ijatzd1cTgF1FtRet6bVOvrYKXyJ5MRK62qU2G2fQ8lqu 0A8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=diXIujQ9pbuQDzBZcIIMi7b35SKDtadRUqnLo7bURSQ=; b=WTyAjBojxncOrUceGZQNfK7TrCEZirHNUBPshPd918rxw03Y09xw/Glpxr4nf9n9Hh dcDxK6e1yP3aEjSWOzKkwOoyrj3NYS3yv1BQdGpA3eignv7X/DhIwjB6Bu56yQzlXorX PWz4MbuMFVVDXkH+VjRgm3FP0+Xu2sX+7Xn27Y0nNcDocGTGL7vDF4VG5SoG60CVLcxw SwvmaMT3hXrU9UeH/AXtF1yHFhGUro999xbczVCwaDVYjDGIddtO+ScMqbNLeEmsd0iL 5btZfbCdc/1hThToYO/rhQvBBKO9xlg1HbUEf8Ck/EJcRbpZ4NsaLotXdBogqwTpCCo8 Ck5g== X-Gm-Message-State: AKaTC01cX3Yzzuyo9qzYJGdJUzAxikIMdI+iwYHd71AHq0u6iQcy5bBtdPwNwFRw4om+UkZNEdB+LCH2la9qhg== X-Received: by 10.129.53.194 with SMTP id c185mr2031135ywa.205.1481824537938; Thu, 15 Dec 2016 09:55:37 -0800 (PST) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.129.53.4 with HTTP; Thu, 15 Dec 2016 09:55:37 -0800 (PST) In-Reply-To: References: From: Jim Roskind Date: Thu, 15 Dec 2016 09:55:37 -0800 X-Google-Sender-Auth: tpZiNuqs5ke2KfgFD4GTv93W3tU Message-ID: Subject: Re: TCP Fallback? To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114214783411760543b6291a Archived-At: Cc: IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 15 Dec 2016 17:55:44 -0000 --001a114214783411760543b6291a Content-Type: text/plain; charset=UTF-8 Great care should be taken before suggesting an MTU based experiment during the CHLO phase. The full packet size of a CHLO is integral to the defense against Amplification Attacks, and a server should currently be required to obtain a (relatively?) "full-size" packet containing CHLO information. There is certainly a lot of "Amplification Attack" safety margin when replying to a CHLO. A rapid (0-RTT) response to a validated CHLO can provide a factor of 10 amplification using a 10 packet initial congestion window (while competitive vulnerabilities in DNS appear to provide closer to a 50x amplification factor). Still, it is good to continue to be be well under that of such competitive vulnerabilities. It is plausible that a server could use care when it receives a significantly smaller packet containing a CHLO (effectively require a 1-RTT connection establishment? further limit response MTU? limit initial congestion window for the response?), but there has not (to date) been a need for this added complexity. Although there are some tunneling induced restrictions, I don't think the world (Internet?) is moving in the direction of smaller MTUs. Jim p.s., I've always been in favor of MTU based experiments *during* transmission (after connection establishment), but such have always been targeted at dynamically increasing the MTU, rather than searching for a workable lower MTU. On Tue, Dec 13, 2016 at 3:25 PM, Jana Iyengar wrote: > On Tue, Dec 13, 2016 at 2:29 PM, Martin Duke > wrote: > >> At the moment, a lost CHLO can mean any of the following: >> - Host not reachable >> - Path congestion >> - RF loss >> - MTU too large* >> - A middlebox will not carry UDP/QUIC >> > > There are two classes of responses -- ones that can be fixed by > retransmissions, and ones that cannot. To your email subject, TCP fallback > should exist to catch the ones that cannot be fixed by retransmissions. > QUIC stream 1 (crypto stream) is reliably transmitted, which means that > QUIC will retransmit the CHLO (and SHLO) n times before it gives up on the > connection. > > That said, at least one on this list is separable. An implementation could > try different MTU sizes if the CHLO fails a few times before giving up. > This may be worth pointing out explicitly, though, as you suggest. > > - jana > > >> many of which have very different responses. The spec needs some >> guidelines on client (and server!, the same applies to SHLO without >> necessarily being symmetric) behavior for many of these scenarios. >> >> * I owe the group a PR on this subject, see here: >> https://github.com/quicwg/base-drafts/issues/64#issuecomment-265016665 >> >> Martin >> >> > --001a114214783411760543b6291a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great care should be taken before suggesting an MTU based = experiment during the CHLO phase.=C2=A0 The full packet size of a CHLO is i= ntegral to the defense against Amplification Attacks, and a server should c= urrently be required to obtain a (relatively?) "full-size" packet= containing CHLO information.=C2=A0

There is certainly a= lot of "Amplification Attack" safety margin when replying to a C= HLO.=C2=A0 A rapid (0-RTT) response to a validated CHLO can provide a facto= r of 10 amplification using a 10 packet initial congestion window (while co= mpetitive vulnerabilities in DNS appear to provide closer to a 50x amplific= ation factor).=C2=A0 Still, it is good to continue to be be well under that= of such competitive vulnerabilities.

It is plausible th= at a server could use care when it receives a significantly smaller packet = containing a CHLO (effectively require a 1-RTT connection establishment? fu= rther limit response MTU? limit initial congestion window for the response?= ), but there has not (to date) been a need for this added complexity.=C2=A0= Although there are some tunneling induced restrictions, I don't think = the world (Internet?) is moving in the direction of smaller MTUs.

Jim

p.s., I've always been in = favor of MTU based experiments *during* transmission (after connection esta= blishment), but such have always been targeted at dynamically increasing th= e MTU, rather than searching for a workable lower MTU.

On Tue, Dec 13, 2016= at 3:25 PM, Jana Iyengar <jri@google.com> wrote:
On Tue, Dec 13, 2016 at 2:29 PM, Martin D= uke <martin.h.duke@gmail.com> wrote:
At the moment, a lost CHLO can mean = any of the following:
- Host not reachable
- Path c= ongestion
- RF loss
- MTU too large*
- A midd= lebox will not carry UDP/QUIC

There are two classes of responses -- ones that can be fixed by retra= nsmissions, and ones that cannot. To your email subject, TCP fallback shoul= d exist to catch the ones that cannot be fixed by retransmissions. QUIC str= eam 1 (crypto stream) is reliably transmitted, which means that QUIC will r= etransmit the CHLO (and SHLO) n times before it gives up on the connection.=

That said, at least one on this list is separable= . An implementation could try different MTU sizes if the CHLO fails a few t= imes before giving up. This may be worth pointing out explicitly, though, a= s you suggest.
- jana
=C2=A0
many of which have very d= ifferent responses. The spec needs some guidelines on client (and server!, = the same applies to SHLO without necessarily being symmetric) behavior for = many of these scenarios.

* I owe the group a PR on= this subject, see here:=C2=A0https://github.com/= quicwg/base-drafts/issues/64#issuecomment-265016665

<= /div>
Martin



--001a114214783411760543b6291a-- From nobody Thu Dec 15 13:49:57 2016 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 282271294A7 for ; Thu, 15 Dec 2016 13:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-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 35TMH-TIaa4y for ; Thu, 15 Dec 2016 13:49:53 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 279A31293EC for ; Thu, 15 Dec 2016 13:49:53 -0800 (PST) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id 9E5D83A021 for ; Thu, 15 Dec 2016 16:49:51 -0500 (EST) Received: by mail-it0-f49.google.com with SMTP id j191so3537570ita.1 for ; Thu, 15 Dec 2016 13:49:51 -0800 (PST) X-Gm-Message-State: AKaTC03CFhGuwGc8TqXICVgCjIHiKjfQoJMqztk5SRATX+853XrdUIH8L1C3USW4cGTmyxzl6KqNGShQ4r+6Kw== X-Received: by 10.36.43.147 with SMTP id h141mr517016ita.47.1481838591220; Thu, 15 Dec 2016 13:49:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.19.16 with HTTP; Thu, 15 Dec 2016 13:49:50 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Thu, 15 Dec 2016 16:49:50 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HTTP/QUIC: Two SETTINGS PRs To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1146ec54d825f10543b96e62 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 15 Dec 2016 21:49:55 -0000 --001a1146ec54d825f10543b96e62 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 14, 2016 at 3:20 PM, Mike Bishop wrote: > Anyone see things here to panic about, or should I merge them? > ship it! as you said, this is basically a "hold for update of 7540" item.. --001a1146ec54d825f10543b96e62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Dec 14, 2016 at 3:20 PM, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

Anyone see things here to panic about, or should I merge t= hem?



ship it! as you said, this is basic= ally a "hold for update of 7540" item..
--001a1146ec54d825f10543b96e62-- From nobody Fri Dec 16 00:51:25 2016 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 20E9E129B1B for ; Fri, 16 Dec 2016 00:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=mMuSAzC/; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=mMuSAzC/ 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 9lmM4LF6hOxS for ; Fri, 16 Dec 2016 00:50:59 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66B6129AFD for ; Fri, 16 Dec 2016 00:50:58 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id 89C1115A04D4; Fri, 16 Dec 2016 09:50:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1481878256; bh=ssAV0h5rWHZigcHxsz0XsOT23SiN1DoIaAqp9QsgtQ8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mMuSAzC/F2etWF7E1levg3L0zr4yfvWxJg3JeNqNzX/sGqxULqhfeF5LxTPLJpb6Z jsrjSZ4fNjN0RwyHfF1/fQWeOFTNz0ev3xW1QMRouwR/Vq0ke+8Mp+PM6ukCAbKpa/ nG2+wCAXGsRbF/MICIZjw0QJFPAmdS+tKQTPsXOg= Received: from [192.168.1.48] (unknown [87.78.175.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id C82A115A04D4; Fri, 16 Dec 2016 09:50:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1481878256; bh=ssAV0h5rWHZigcHxsz0XsOT23SiN1DoIaAqp9QsgtQ8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mMuSAzC/F2etWF7E1levg3L0zr4yfvWxJg3JeNqNzX/sGqxULqhfeF5LxTPLJpb6Z jsrjSZ4fNjN0RwyHfF1/fQWeOFTNz0ev3xW1QMRouwR/Vq0ke+8Mp+PM6ukCAbKpa/ nG2+wCAXGsRbF/MICIZjw0QJFPAmdS+tKQTPsXOg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: HTTP/QUIC: Two SETTINGS PRs From: Stefan Eissing In-Reply-To: Date: Fri, 16 Dec 2016 09:50:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BD3E70B-CBD9-4028-9090-565AF9CE9A08@greenbytes.de> References: To: Mike Bishop X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Dec 2016 08:51:16 -0000 > Am 14.12.2016 um 21:20 schrieb Mike Bishop = : >=20 > I have two open pull requests I=E2=80=99d like to draw folks=E2=80=99 = attention to, in hopes of getting more review than just Martin =E2=80=93 = thoughtful though his comments always are. > =20 > https://github.com/quicwg/base-drafts/pull/80 merges the HTTP WG draft = (full disclosure: by me) creating a SETTINGS-frame alternative called = EXTENDED_SETTINGS. In this pull request, the SETTINGS frame is fully = replaced by the proposed EXTENDED_SETTINGS functionality and existing = settings values are redefined into the new space. The notable = differences are: > =C2=B7 Rather than being a fixed 32-bit length, settings are TLV = records with interpretation defined custom to the setting. Includes = option to declare the value as zero-length and use an embedded flag as a = Boolean value, since many settings are strictly yes/no. Reduces length = of a setting in most cases, and permits greater flexibility if a setting = needs to communicate something more complex (e.g. a list of values). > =C2=B7 Ack is requested or not on a per-SETTINGS-frame basis, = since many settings don=E2=80=99t actually need acknowledgement. If an = ACK is requested, the ACK tells the sender which settings in the frame = were recognized and which were unknown/ignored. That can potentially do = away with bidirectional settings that merely acknowledge mutual support = for an extension =E2=80=93 client can set the value to =E2=80=9Ctrue=E2=80= =9D and requests ACK, server indicates comprehension, done. (Note that = while this is useful information, it=E2=80=99s also a fingerprinting = vector we should note in Security Considerations.) > This pull request explicitly doesn=E2=80=99t solve the synchronization = problem that SETTINGS has with regard to QUIC, which is that you can=E2=80= =99t tell when in each stream the new settings take effect, since = there=E2=80=99s no intra-stream ordering in QUIC. (Tracked by = https://github.com/quicwg/base-drafts/issues/75.) > https://github.com/quicwg/base-drafts/pull/84 builds on the previous = request and attempts to address that problem, though the same technique = could be applied to an HTTP/2-style SETTINGS frame. It requires, not a = single SETTINGS_ACK, but a collection of them: > =C2=B7 One on stream 3 which indicates the highest non-idle = locally-initiated and peer-initiated stream IDs > =C2=B7 One on every message control stream that was open when = the SETTINGS frame was received. > With the first, the sender of the SETTINGS knows all streams that have = the new settings from the start; every other stream must either close = (still under the old settings) or carry a SETTINGS_ACK frame (accepting = the new settings) within the timeout. There=E2=80=99s a race condition = where a stream=E2=80=99s opening frame is still in flight when the = SETTINGS is received, and I attempt to address that as well, but = Martin=E2=80=99s comments suggest it might not be fully covered yet. > =20 > Anyone see things here to panic about, or should I merge them? +1, on both from me. From nobody Tue Dec 20 02:28:25 2016 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 0CC5912955C; Tue, 20 Dec 2016 02:28:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: quic - New Meeting Session Request for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148222970402.23845.10332227089915044247.idtracker@ietfa.amsl.com> Date: Tue, 20 Dec 2016 02:28:24 -0800 Archived-At: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Dec 2016 10:28:24 -0000 A new meeting session request has just been submitted by Lars Eggert, a Chair of the quic working group. --------------------------------------------------------- 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: 250 Conflicts to Avoid: First Priority: irtfopen artarea taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch httpbis tls saag tsvarea Second Priority: rtcweb webpush acme t2trg Special Requests: --------------------------------------------------------- From nobody Tue Dec 20 10:05:41 2016 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 684C5129BF4 for ; Tue, 20 Dec 2016 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 r4FfP48ss8Cy for ; Tue, 20 Dec 2016 10:05:38 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0109.outbound.protection.outlook.com [104.47.37.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E76C129519 for ; Tue, 20 Dec 2016 10:05:38 -0800 (PST) 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; bh=HHBzOnTIxxdQl1IDCNx8Fl2GVe9zGiAURFV+n+dLThA=; b=Ppt+dbt+wB9nDt9xY1FSV/WnEUc0pUdL2vijS/YQ8SiPDyTVJT+dnhlhYZzV5gZNP7jKJOB/MKTZC06w7lqTRF6NVHeO9H0lT/3/xqNFyzbe+pIkNPdo2zyb6ZTf1IU2YnHYNVuUu8zEQYfoW0Hl5yaWm8USKZKIsvgCQZWGG5k= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 20 Dec 2016 18:05:37 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0803.010; Tue, 20 Dec 2016 18:05:37 +0000 From: Mike Bishop To: IETF QUIC WG Subject: Version Negotiation, Crypto Protocols, and ALPN Thread-Topic: Version Negotiation, Crypto Protocols, and ALPN Thread-Index: AdJa6Epvcy4nCI3yQ2GlNrRDAGQw6A== Date: Tue, 20 Dec 2016 18:05:36 +0000 Message-ID: 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=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:88ac:c8f8:62b1:2221] x-ms-office365-filtering-correlation-id: ebcf0b14-3781-422f-bb08-08d42902ccf7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:XJDCESBbIiqFtFkU05E86bdisRw9eewH6naBugpb0iPYGHOK0xgum1JlIdonORb+vrnUAu1hkuWsezaNVbz9/On4bsesm4Z5JXvwRqJhcWFkS2TZ8JAyYcdsbXCodVsqCmBaTDohpQH0XMHmHhLAvNZNunOKPABISmZRHsBDq1gXttwfppWcZ5PWIINUuBTcx05t5RUMTOhWVR/3CxiYXoMiCe1XTrvTJFMoaVpNO7QofMPpO4Lm3U/NKSeZBmS71r5kRiePPmyWllXenvDGGK3nYCiF2zo+S5ltK/yN+LunYn4/YV4NW6SN3xFyEUNW6pXPEOeMipqEQl41t6QoLSEHYxgl+Dcr7nAcjX0oUN1zqehUsQ133me1DDAAgZRIfmIFo/uPqarF8XADRkcc1C7IMwYPTuHUH7moa2YwkQMQUtsIX1fnyt/7dYHQP8vvgk/I+d9ZYMfKPe0pbORu1abEl6KFX4Usd15qODCMhKc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0162ACCC24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39450400003)(39410400002)(189002)(199003)(450100001)(6506006)(92566002)(6436002)(33656002)(606005)(68736007)(101416001)(122556002)(10090500001)(76576001)(38730400001)(9686002)(107886002)(97736004)(77096006)(50986999)(54356999)(189998001)(106356001)(25786008)(74316002)(8936002)(3280700002)(105586002)(99286002)(2900100001)(3660700001)(86362001)(86612001)(5660300001)(7736002)(6916009)(790700001)(6116002)(110136003)(7696004)(5005710100001)(81166006)(81156014)(8676002)(7906003)(2906002)(8990500004)(102836003)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708D955F539A11005CA645087900BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2016 18:05:36.9711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Dec 2016 18:05:40 -0000 --_000_BN6PR03MB2708D955F539A11005CA645087900BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've got a couple GitHub issues around version negotiation and how all the= pieces play together. I'd like to keep the layers as modular as possible,= so I'm trying to flex the joins a little bit conceptually. * draft-ietf-quic-transport says: If not explicitly specified in the application mapping, TLS is assumed to b= e the default crypto handshake protocol, as described in [QUIC-TLS]. An app= lication that maps to QUIC MAY however specify an alternative crypto handsh= ake protocol to be used. * draft-ietf-quic-tls says: The ALPN identifier for the protocol MUST be specific to the QUIC version t= hat it operates over. * draft-ietf-quic-http (in PR#90) would say: HTTP/QUIC support is indicated by selecting the ALPN token "hq" in the cryp= to handshake. * Ian's comment in Issue #45: I would suggest [the crypto protocol] be baked into the QUIC version. There's also some related discussion in Issue #87 / Issue #89 which diverged from it. So the application mapping is supposed to specify the QUIC versions and, im= plicitly or explicitly, the crypto protocol that's acceptable. Except the = crypto protocol is already known by the time the ALPN tokens are being inte= rpreted, because you have to parse the QUIC frame and the crypto protocol t= o find the ALPN tokens. Besides which, I'm inclined *not* to require new Q= UIC versions to imply revs to the application protocol anyway; if we had to= , either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. plac= eholder where the QUIC version is embedded), but I'd prefer that HTTP allow= s *any* version of QUIC that provides the necessary properties (which is li= kely to be all future versions, but not necessarily). Those versions might= or might not use TLS as their crypto protocol - HTTP simply requires QUIC,= and QUIC simply requires that the crypto handshake be able to negotiate an= application-layer protocol. I'm thinking of it this way: * QUIC specifies that a particular QUIC version uses a particular cr= ypto handshake and/or allocates the crypto protocol a few bits of the versi= on field. * The QUIC TLS extension carries: o Client->server: The initially-offered version o Client->server: The finally-selected version o Server->client: The set of versions the server did / would have sent i= n a Version Negotiation packet * The application specifies requirements of the QUIC version to be u= sed, but doesn't bind that version in its ALPN token However, this is a more expansive design issue, so I'd like to make sure it= 's visible on-list. --_000_BN6PR03MB2708D955F539A11005CA645087900BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve got a couple GitHub issues around versio= n negotiation and how all the pieces play together.  I’d like to= keep the layers as modular as possible, so I’m trying to flex the jo= ins a little bit conceptually.

 

·        draft-ietf-quic-trans= port says:

If not explicitly specified in the appli= cation mapping, TLS is assumed to be the default crypto handshake protocol,= as described in [QUIC-TLS]. An application that maps to QUIC MAY however specify an alternative crypto handshake protocol = to be used.

·        draft-ietf-quic-tls says:=

The ALPN identifier for the protocol MUS= T be specific to the QUIC version that it operates over.<= /p>

·        draft-ietf-quic-h= ttp (in PR#90) would say:

HTTP/QUIC support is indicated by select= ing the ALPN token “hq” in the crypto handshake.

·        Ian’s comment in Issue #45:

I would suggest [the crypto protocol] be baked into the QUI= C version.<= /o:p>

=  

There’s also some related discussion in Issue #87 / Issue #89 which diverged from it.

=  

So the application mapping is supposed to specify th= e QUIC versions and, implicitly or explicitly, the crypto protocol that's a= cceptable.  Except the crypto protocol is already known by the time th= e ALPN tokens are being interpreted, because you have to parse the QUIC frame and the crypto protocol to find= the ALPN tokens.  Besides which, I'm inclined *not* to require ne= w QUIC versions to imply revs to the application protocol anyway; if we had= to, either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. placeholder where the QUIC version is e= mbedded), but I’d prefer that HTTP allows *any* version of QUIC that = provides the necessary properties (which is likely to be all future version= s, but not necessarily).  Those versions might or might not use TLS as their crypto protocol – HTTP simply re= quires QUIC, and QUIC simply requires that the crypto handshake be able to = negotiate an application-layer protocol.

 

I’m thinking of it this way:

·        QUIC specifies that a particular QUIC versio= n uses a particular crypto handshake and/or allocates the crypto protocol a= few bits of the version field.

·        The QUIC TLS extension carries:

o   Client->server:  The initially-offer= ed version

o   Client->server:  The finally-selecte= d version

o   Server->client:  The set of versions= the server did / would have sent in a Version Negotiation packet

·        The application specifies requirements of th= e QUIC version to be used, but doesn’t bind that version in its ALPN = token

 

However, this is a more expansive design issue, so I= ’d like to make sure it’s visible on-list.

--_000_BN6PR03MB2708D955F539A11005CA645087900BN6PR03MB2708namp_-- From nobody Wed Dec 21 04:56:02 2016 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 0BEA7129CC8 for ; Wed, 21 Dec 2016 04:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 vF_Q6rEWb4C7 for ; Wed, 21 Dec 2016 04:56:01 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC444129641 for ; Wed, 21 Dec 2016 04:55:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,383,1477983600"; d="scan'208";a="166323742" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx144-out.netapp.com with ESMTP; 21 Dec 2016 04:52:07 -0800 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Dec 2016 04:55:39 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 21 Dec 2016 04:55:39 -0800 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; bh=1cSk0NuCJgyyJo9dTeJKC3IZtQm/KiebryyHsd6vsHQ=; b=anB4ZpCXMdVF5mznPbRhJcSjvc1wYCj2xK98wpZhvRH4vf8Feax6Mpz1hjL4hHI9ujCFWwzplX8HN2OWyj5NGiInY1AwPu0zwQs0H8WgNsVNHy/efGhH8tYvA0RSoIGP5RjMlhJRWIRGuSd18cBn92npWCwn7cN2Wlzrb9UpXCY= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1156.namprd06.prod.outlook.com (10.160.157.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 12:55:36 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 12:55:36 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Confirming consensus on using big-endian Thread-Topic: Confirming consensus on using big-endian Thread-Index: AQHSW4mG9NOMWLbswkGsmqdXhDKU2w== Date: Wed, 21 Dec 2016 12:55:36 +0000 Message-ID: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 4f730c30-a4c0-4ae7-99b8-08d429a0a8ca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1156; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1156; 7:hP1p1ypI+sl0fa+W3b9xD/KoM/U8GgaXU5Ha+MnYUZjzgjsSkiQo6sILCtqQECWqOp3TQCNb5Siu4l0aU25jRZMDfv/a6dW/kR5bIO7/7vWaoXpfWKoyX3R5Tf+Lqw75MC7wrZd2oezFypDVv85g5uOeFpHQxvn0ueJFzzAD4pOFqVEIOX96kxtJKguYr2CkJValVU0rZquoaMMy18eivJuz6PSGcRe87LuIQxs/FScrZ8q9HWaDrMI7SSY10Tj4u9qBwtYYzALylUy+Ln0Ul43m8rBu2qsIT/JOIXx1SBaEykJsZbPfaq9OQ0+azrcgqnVwo7/WpMD0itGxR/iJvimZ+DHfeyt2rN7mDeglPK50K4mvSUZqPCcxpFLu0vEE9Xi4TpPli+hJhvBHGveMXQAnAbne7tFkBxFp4XbeI/o9utqRhx29m7HFyF43PvozaZ8nRUcZ7hzVqiufGTPIYA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(6042181); SRVR:BN3PR0601MB1156; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1156; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(99286002)(107886002)(36756003)(189998001)(82746002)(97736004)(38730400001)(83716003)(68736007)(8936002)(6436002)(6916009)(81166006)(81156014)(50986999)(3660700001)(8676002)(3280700002)(110136003)(77096006)(101416001)(2900100001)(50226002)(305945005)(6506006)(2906002)(7736002)(25786008)(450100001)(6512006)(57306001)(92566002)(6116002)(102836003)(3846002)(106356001)(558084003)(106116001)(122556002)(6486002)(5660300001)(33656002)(86362001)(66066001)(105586002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1156; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4DE877F5EB833B44B8B8F709A0A465D7@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 12:55:36.7557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1156 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Dec 2016 12:56:02 -0000 Hi, we had very strong consensus during the Seoul meeting to use big-endian enc= oding for QUIC. We'd like to confirm this consensus on the list.=20 If you *disagree*, please reply to the list by Jan 6, 2017. Lars= From nobody Wed Dec 21 06:10:14 2016 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 A0CF81293E9 for ; Wed, 21 Dec 2016 06:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 pWBgzE8OPAEB for ; Wed, 21 Dec 2016 06:10:12 -0800 (PST) Received: from mail-wj0-x235.google.com (mail-wj0-x235.google.com [IPv6:2a00:1450:400c:c01::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 E5E63129453 for ; Wed, 21 Dec 2016 06:10:11 -0800 (PST) Received: by mail-wj0-x235.google.com with SMTP id sd9so17904631wjb.1 for ; Wed, 21 Dec 2016 06:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=WpxM5P/0w5hTSi19f5uSHXVywK8xq5fVzi4xBGEN1Xk=; b=GJbjm5g2jVBK7wGsACs4ZvQkQjhC6wZAV2M1KsJsZ5OYgJ46XEKBkrfpP+VP9gZi3W G7dGs1YFAu8bhW4DdeqkQ2j5D9ZeiiFH1Ets0pPZHNZvWll/OqAmYPjg8RBv9ZlE3O0a 9Xkq0i8cp/gGQ8y1FaI4RkeGeLJnBpVIVlEJDpTNNVO8cLn9v9nqevIaXAdTnuMoZ3iN 7iQwta29PO/3Kj7kFMbDorYfCZqymAZVNWMid8h3Mo+vJp3iB1CgL0ui79Ao2idA48HF Zav9uLer8TzBwkXeFmC0wE4/MIn5qXXglf6mRM3GpizbcOywYkcFhIkod5H74vGVxgRQ Z5tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=WpxM5P/0w5hTSi19f5uSHXVywK8xq5fVzi4xBGEN1Xk=; b=RSHnlfLXelRw69Mq4XnL/y5HdYWrjDlfnggEw8qCQ5nb7w7Ee5GgFPTeaVR7Zxr3Cz WgUW6QNqOIJqZ+UF5W/Y0SIiiprz5d7mUvRr2Hbaojxr4nKAuQCONiIJtqD05W5PSHgv 62PkdEttmxBTDtt9oqt6NXDm+ERFmpL5PD7ic4xWm/VQZbT+H/4UbMQs/DBrzQ0yA9Td EgBkdwwXsHH2Gx/+JrhbZSKppJsOiEWFjOxr3Ucfepol9Hh5x6Svf8pgiksiDfhkiPNE nCA8GkOBGd2Yd9rrIzNUuXxnIIlfcaFOUnUmkXnoCZqIw2Po9XevADWP6nxf6m53ZwFs S4UQ== X-Gm-Message-State: AIkVDXJOjp4/IfOcqqZtW9Z0/S6K9gg1TBy2e0K34+LV+gNUd/jDz8dvFbuppGwpdcoXeHj+FUmgxydrMAXHRA== X-Received: by 10.194.102.162 with SMTP id fp2mr2471535wjb.6.1482329410330; Wed, 21 Dec 2016 06:10:10 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Wed, 21 Dec 2016 06:10:09 -0800 (PST) From: Phillip Hallam-Baker Date: Wed, 21 Dec 2016 09:10:09 -0500 X-Google-Sender-Auth: NX1NyI5PJxi4iv83lZBhvgc_uYI Message-ID: Subject: Nested length: Re: Confirming consensus on using big-endian To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=e89a8f23557ff166a805442bb593 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Dec 2016 14:10:13 -0000 --e89a8f23557ff166a805442bb593 Content-Type: text/plain; charset=UTF-8 I agree on big endian. But one area I would point out as a serious fire hazard is nested length specifiers. These are a real minefield from a security point of view. In 1980, it was considered OK to use tools that let the less skilled develop code that would create security holes. Today we are all living with the consequences of billions of holes created by millions of incompetents. Specifically, the problem that comes up is encoding structures of the form x { { Test1 }, { Test2 } } Encoding in XML, JSON or any modified S-notation like scheme is safe because a decoder has to allocate memory as it goes. This is inefficient of course. Encoding in ASN.1 BER indefinite length encoding is also safe. Here we identify the extent of terminal nodes by means of a length specifier but close the list/set explicitly: x { 4: "Test" , 5 "Test2" } Encoding in the ASN.1 DER encoding is not only a pig to write unless you know the trick, it is also unsafe. 11: 4: "Test" , 5 "Test2" Specifically the problem comes when an attacker produces something of the form: 11: 4: "Test" , 66666666: "Test2" This is one of the main ways to create a buffer overrun and smash the stack. Nested length encodings are really bad news and require serious coding effort if a vulnerability isn't going to be created. While early implementations of QUIC are likely to be at the application layer, we can expect this sort of code to head to the kernel fairly fast. The O/S people do not understand the seriousness of this problem. When someone tried to put some protection macros into the Linux IPv6 code, Linus himself called out the coder as guilty of 'compiler masturbation' and publicly vilified him. So much for the many eyes theory of security. It doesn't work so well if an ignoramus then ignores the result. I strongly suggest a bar on nested length encodings in the spec and perform an audit when you are done. It was a style that was acceptable in the 1980s but we have learned is unsafe and must be avoided. On Wed, Dec 21, 2016 at 7:55 AM, Eggert, Lars wrote: > Hi, > > we had very strong consensus during the Seoul meeting to use big-endian > encoding for QUIC. We'd like to confirm this consensus on the list. > > If you *disagree*, please reply to the list by Jan 6, 2017. > > Lars > --e89a8f23557ff166a805442bb593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I a= gree on big endian.

But o= ne area I would point out as a serious fire hazard is nested length specifi= ers. These are a real minefield from a security point of view. In 1980, it = was considered OK to use tools that let the less skilled develop code that = would create security holes. Today we are all living with the consequences = of billions of holes created by millions of incompetents.


Specifically, the problem that comes up is encodin= g structures of the form

= x { =C2=A0{ Test1 }, { Test2 } }

Encoding in XML, JSON or any modified S-notation like scheme is saf= e because a decoder has to allocate memory as it goes. This is inefficient = of course.

=
Encoding in AS= N.1 BER indefinite length encoding is also safe. Here we identify the exten= t of terminal nodes by means of a length specifier but close the list/set e= xplicitly:

=
x { 4: "T= est" , 5 "Test2" }=C2=A0

Encoding in the ASN.1 DER encoding is not only a pig to writ= e unless you know the trick, it is also unsafe.

11: =C2=A04: "Test" , 5 "Test2"= =C2=A0

=
Specifically t= he problem comes when an attacker produces something of the form:

11: =C2=A04: "Test" , 66= 666666: "Test2"=C2=A0

This is one of the main ways to create a buffer overrun and smas= h the stack.

Nested length encoding= s are really bad news and require serious coding effort if a vulnerability = isn't going to be created. While early implementations of QUIC are like= ly to be at the application layer, we can expect this sort of code to head = to the kernel fairly fast.

The O/S people do not understand the seriousness of this problem. When so= meone tried to put some protection macros into the Linux IPv6 code, Linus h= imself called out the coder as guilty of 'compiler masturbation' an= d publicly vilified him. So much for the many eyes theory of security. It d= oesn't work so well if an ignoramus then ignores the result.


I strongly suggest a bar on nested length enc= odings in the spec and perform an audit when you are done. It was a style t= hat was acceptable in the 1980s but we have learned is unsafe and must be a= voided.


On Wed, Dec 21= , 2016 at 7:55 AM, Eggert, Lars <lars@netapp.com> wrote:
Hi,

we had very strong consensus during the Seoul meeting to use big-endian enc= oding for QUIC. We'd like to confirm this consensus on the list.

If you *disagree*, please reply to the list by Jan 6, 2017.

Lars

--e89a8f23557ff166a805442bb593-- From nobody Wed Dec 21 06:12:07 2016 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 72A99129494 for ; Wed, 21 Dec 2016 06:12:06 -0800 (PST) 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 A6Ec5F-vhHGe for ; Wed, 21 Dec 2016 06:12:05 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 61597129453 for ; Wed, 21 Dec 2016 06:12:05 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 2so78925172uax.2 for ; Wed, 21 Dec 2016 06:12:05 -0800 (PST) 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=jAE9L3V2Mw4oPD2QgQG8tKzI0IZvYw5uqYlzsmuFnE0=; b=GHyGKtHCxdi9AMRiOBlbqR8se56Knfi6p7eltgPSXRIjoACSH8Rte7gBL4OlKLynNR pkVrrjHEpDRWRSwo+Uz1y6PPE5TwXRn9z7fBbrbATVWL+cXJN+JfmU2ynMcmMwY//w3I eipdq8wdMR2qIoZQp8LyXmqi36aHZnNblGDKqPbr3qpaDg52RuLRTN2+fB2sUgZH1PE1 olhyGtCiUbqXVGcNTg+ETy128IvS/TvlNgDCqX4dE9hb7bPw1hRql/cHZKdhJua2MuZ+ rhFx3zc3n1h4JTuVfy2dhOHv2DdJX3ILV6GBtNUaeHt5YDnvZW97pNrXzCWI5NKSCM6g CsgQ== 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=jAE9L3V2Mw4oPD2QgQG8tKzI0IZvYw5uqYlzsmuFnE0=; b=A02hOCEQp3araOItJTDa4Y+q6Cq9U4prT/aP5WbbBdd+JXYaK32U56PXMF29jlT6et sCeFD5PkQpGVDns/IILShRBerSCFnHWYy1SxtO+klm38SHeBX30edkrNks2amisYb58q 7yPrPyKl2Ip9Wu2JMjwMGrjJM1ohnhS/P265EPvethOgUjuLK4c1O6tvLTb4baSiXfZQ 0FPc+xgUTRLtZtLNgxevO9Nsp6l0IxzEsS5lMaBDdvxo+ia41CECVxAGFmN5K0x7e+50 wFrBmlE6jwm2AiFafUDujLsVa+tDhd+sKWXmau6WMG07nOhBwJpyTqD/tf/44uQJpIiM SBVg== X-Gm-Message-State: AIkVDXLPpRqiwz9/EYapD/xsHa3KB8v2RIyTtjFxFE/KS9sZe9v+kXAK5TucTOaCztMDamv0NeL4fao3wq+TZw== X-Received: by 10.159.40.101 with SMTP id c92mr3903737uac.111.1482329524437; Wed, 21 Dec 2016 06:12:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.50.153 with HTTP; Wed, 21 Dec 2016 06:12:03 -0800 (PST) In-Reply-To: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> References: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> From: Watson Ladd Date: Wed, 21 Dec 2016 06:12:03 -0800 Message-ID: Subject: Re: Confirming consensus on using big-endian To: "Eggert, Lars" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Dec 2016 14:12:06 -0000 On Wed, Dec 21, 2016 at 4:55 AM, Eggert, Lars wrote: > Hi, > > we had very strong consensus during the Seoul meeting to use big-endian encoding for QUIC. We'd like to confirm this consensus on the list. > > If you *disagree*, please reply to the list by Jan 6, 2017. Big endian *for what*? I'm sure I agree, I just don't know with what I am agreeing! > > Lars -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Dec 21 06:23:03 2016 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 E4E431296AA for ; Wed, 21 Dec 2016 06:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham 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 vJqdjSlUneCZ for ; Wed, 21 Dec 2016 06:23:01 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E6612969A for ; Wed, 21 Dec 2016 06:23:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,383,1477983600"; d="scan'208";a="171722999" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx141-out.netapp.com with ESMTP; 21 Dec 2016 06:14:57 -0800 Received: from VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Dec 2016 06:17:57 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 21 Dec 2016 06:17:57 -0800 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; bh=6PjLAq6OwOSNHiEfNOJgbZVhC5gIogaFw0ZVygEh19c=; b=QZnJOdfgyE7O5tMduVABt7jT11SQaRXxKBhYV6EjqjzlDRPoKe7edrOQLS/q4DSEcWNyo1ay5XLkef0GvYWe4j1Sqzz2wHi2ZrayJipbOUslJBsm+r+JbIC6xlQ26ZdZOOXUKJq7qozYCMQAZ4aSNg5IR4oVx64+Q9ZHO+J8fW0= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 14:17:55 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 14:17:55 +0000 From: "Eggert, Lars" To: Watson Ladd Subject: Re: Confirming consensus on using big-endian Thread-Topic: Confirming consensus on using big-endian Thread-Index: AQHSW4mGzCwkS862HUmqjPU9smsw9aEScVSAgAABowA= Date: Wed, 21 Dec 2016 14:17:55 +0000 Message-ID: <5D797F6B-6567-4A14-A05C-0BA3B9BE42E9@netapp.com> References: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 32de10f3-b06f-4c9f-b916-08d429ac2892 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1155; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:FulrD16/612pzTqQn1PV2DujGCYVDIX5NLol+3XqaRljVPHZsWwNZ+kXMYMac0wDGvMTTdr5Nht+jQogS40bB/7wSiO0j2+AydPPuAdQRb04z2ebqeEf5DXhIqz7tv9vqpzVLKgGMHdDE3FNEKbo09bobJkNIw8lDGwBmhvqWAk/aqLkF0UqOoqPDciog0yFkGd/uCo7alHFN3fHPd44rMvqq94Tt0H0Tc/u3YF/M2HT6AI1zI392g9OJSjjQa/QOhXmgvMsXXRI/frbwZ4jCq5/FVial8UNvFghQYBVs+q5KNmdSK21k31I4oaO8llkBlck5WUWovD8I+Iobltojc3VyyXp/YXUwfw0m9ICKCu9DOHFdzGktY4GERkiLOGSP5KBmvY/k9rzuwSi7mPNgEx3av95DzWB3ZbKuaVZdkOsPeHGxozrR/egWv+PBoc0Ha1yqH57FBpyxoMLNKPmYw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(199003)(189002)(377424004)(24454002)(36756003)(7736002)(2900100001)(68736007)(97736004)(86362001)(99286002)(3660700001)(106116001)(105586002)(106356001)(102836003)(6116002)(122556002)(305945005)(25786008)(6506006)(77096006)(6512006)(3846002)(6486002)(3280700002)(6436002)(82746002)(39060400001)(50986999)(1411001)(76176999)(38730400001)(2906002)(110136003)(8676002)(229853002)(2950100002)(101416001)(57306001)(5660300001)(50226002)(4326007)(6916009)(189998001)(8936002)(81156014)(66066001)(81166006)(4001150100001)(83716003)(33656002)(92566002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <71162F6301A36749931BE85DEF95DF22@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 14:17:55.6099 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Dec 2016 14:23:03 -0000 On 2016-12-21, at 15:12, Watson Ladd wrote: > On Wed, Dec 21, 2016 at 4:55 AM, Eggert, Lars wrote: >> we had very strong consensus during the Seoul meeting to use big-endian = encoding for QUIC. We'd like to confirm this consensus on the list. >>=20 >> If you *disagree*, please reply to the list by Jan 6, 2017. >=20 > Big endian *for what*? I'm sure I agree, I just don't know with what I > am agreeing! For the header fields in the QUIC specification that this WG is standardizi= ng. Lars= From nobody Wed Dec 21 08:29:03 2016 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 B2394129876 for ; Wed, 21 Dec 2016 08:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 oN9EjRLQhbRx for ; Wed, 21 Dec 2016 08:29:01 -0800 (PST) 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 5952C129762 for ; Wed, 21 Dec 2016 08:29:01 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cJjks-0002fH-Qc for quic@ietf.org; Wed, 21 Dec 2016 17:28:41 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cJjg3-0007dA-Qi for quic@ietf.org; Wed, 21 Dec 2016 11:23:40 -0500 Received: (qmail 26180 invoked from network); 21 Dec 2016 16:23:39 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[208.54.5.167]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Dec 2016 16:23:38 -0000 From: "Christian Huitema" To: "'Eggert, Lars'" , "'Watson Ladd'" References: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> <5D797F6B-6567-4A14-A05C-0BA3B9BE42E9@netapp.com> In-Reply-To: <5D797F6B-6567-4A14-A05C-0BA3B9BE42E9@netapp.com> Date: Wed, 21 Dec 2016 08:23:29 -0800 Message-ID: <08de01d25ba6$921600e0$b64202a0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHBMOQ7cExyTxKWKiek3qZTsoAW0wH4VevJAc2x73ChFro/0A== Content-Language: en-us Subject: RE: Confirming consensus on using big-endian X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD8L8 JYG9zJjNZQ28kxRUiYPWu4/Yum4Sg7X+31yuALfZdcmtTcWSOKD5RASVzg27isHQQQX4d8d1Wjzb XaO9Az55kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRnMGRzUJOm9oQmOStscXq/4MQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCj2kVHDBf7iCrNMGYaUFmFq/eNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxNnmFCUctm6OHeH6tWPSXJE7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRYE83tH9htpyVATiooT/rJiGHIfgXXvuhI9vwJN89WVO9R0tarUwIt7i7NiVJNL9jNC r2VPLfZa8ts/I6OTYjIAMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.09) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Cc: 'IETF QUIC WG' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Dec 2016 16:29:03 -0000 On Wednesday, December 21, 2016 6:18 AM, Lars Eggert wrote: > On 2016-12-21, at 15:12, Watson Ladd wrote: >> ... >> Big endian *for what*? I'm sure I agree, I just don't know with what I >> am agreeing! > > For the header fields in the QUIC specification that this WG is standardizing. I agree. Most QUIC numbers are encoded with variable length, so the impact of endian conversion is really low. Uniformity with the other layers (TLS) is an advantage. -- Christian Huitema From nobody Thu Dec 22 02:18:53 2016 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 9CEE0129489 for ; Thu, 22 Dec 2016 02:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.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 B4oQOzWJZHNE for ; Thu, 22 Dec 2016 02:18:48 -0800 (PST) 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 B2F7E129469 for ; Thu, 22 Dec 2016 02:18:47 -0800 (PST) X-AuditID: c1b4fb2d-e97ff7000000561e-71-585ba885b564 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id DA.D9.22046.588AB585; Thu, 22 Dec 2016 11:18:45 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Dec 2016 11:18:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lmH4qiWYrIkXp0h/AtIpqlha8cRV78FD6JRym7ACUR0=; b=dMfGel5+uAmR34/L6s+tIyODX5zwz9e0GIPfh09gtnMJZn3CzJ12yz8W5dIvghePCmQ+bRxWP56Wb/TIFfgibPfnFkEEr5zgt40KUbtoLVdV4y/ln3kxMpb0IOx/6s6wzIklznwiEg+zHOh0XTTD6P3THAYBRXnQuLWAP+Ai2lE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.5; Thu, 22 Dec 2016 10:18:43 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0803.013; Thu, 22 Dec 2016 10:18:43 +0000 From: Ingemar Johansson S To: Ian Swett Subject: RE: ECN support in QUIC Thread-Topic: ECN support in QUIC Thread-Index: AdJMlPQfSxtqvt4NTzup1wwKcj82KAA5pEsAA69xd9A= Date: Thu, 22 Dec 2016 10:18:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-office365-filtering-correlation-id: 0c94a88a-2c19-41ad-71a2-08d42a53e892 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB345; x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:aMNjA9G/dwt2sgMjj9iU1BDxVcS3hiNd2eBljwxDe6CO5RjWG9JKDaibfnRnCSDu9vCH8A/q3NFU2N7n4igrWJuOwkGjb5amHNfHiwj71icmYCTaAwzWCc7dgIYLqOpnsgvHEgWiMVRyFPmXsEiPix8gCS151SbFGlEhCU+Uw0Ghx8rGI2zKBSNnYqfDTlhWjryiobqN9NkkTf1rkqdnV0kbCsKWhuuqWyefdXtF8JDciuqC1JVKNmmxojUbrl9BA+A9v/WEqWCsWhZmxT8CrVcnALfWZ+qc6L4pgIpc9gC0McFbqUTQ5HEAB7bpauJ9r3pTswxgfD7nI8TAKPGLsGLlE2Fyb9ZPwOfqxkdsia4Wxv0hIDQ6AkvXWCKrqdxN9+Y01wUjeuySftk5LQi4lj4wlS22qe+jU1QyPzIFFT6BMsZxZhc3GB1bU+iVa5EYqkE7WzyrBe89KJS0FOlJsQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(211936372134217)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(24454002)(199003)(377454003)(189002)(4326007)(74316002)(229853002)(77096006)(2900100001)(9326002)(7696004)(38730400001)(9686002)(2906002)(76576001)(3660700001)(3846002)(102836003)(6116002)(790700001)(122556002)(3280700002)(66066001)(97736004)(110136003)(101416001)(2950100002)(54356999)(92566002)(76176999)(6916009)(68736007)(50986999)(7906003)(189998001)(106356001)(7736002)(19609705001)(105586002)(6436002)(8936002)(606005)(25786008)(3480700004)(6506006)(86362001)(5660300001)(8676002)(33656002)(81166006)(16601075003)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3488DAC5AFB3A816541B06EC2920DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 10:18:43.6094 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbv3b2uBk8r87CKdCW9oVmLEJMoP03SyihcG1FDLynOKbsW FRSVGbY5iNKykbhyaW2ka2WWGNhqUvRmIGlqrqFWFqUWZuJLbXsW+O13zvk/53/O4eEoWRsj 53INRbzRoNMrxBL6irpJGVdyU6tOqLGuSZzoe8gkev02JvHPqwC5nOV0YpltzhZG9dXXzqhs 7kMqu31CpHI6/ZSqbWRMvJPRSJKzeX3uYd64dvMBSY7lZSdTeM+LjlRZNSdRZSsyoQgO8Aao G37LmpCEk+F6BJahaUSCZwgGpxqpYEBjCwWTTwbCsgoRjN3oF5GgDUHD6690sJkYJ8Mtz3io 8QK8DLy9F0JM4U8Ing3qgzwfR4PL7RYRTQy4u4cowklQfPdNSE/jWGju6QhppFgDHSNNYedr CGrvPxYHCxE4A2rK7jBBRngJ+Mb7aGIWBd0D1SKyHQZ7yxuKcCQM9c+E9Vnw870lwFwgHw3+ xu1Ekg6tXWaGcBpYul6Ig76AzTR4vKMsKeSCwz8mJnwchkwD4f6lImj4vJPwYvhxupoij/0M TJ86E9pMhnmou12CyCXk8KHjHDqPVllnzU24AMpu/qasoQPMg+dXBmhrYFYKr4KG5rVEEgPl Zj9LeCWUXK1iZ+dtiHWgSIEXhPyD65XxvDE3SxAKDPEGvsiNAr/r8b3JuAfI+W2rB2EOKeZK Ryo1ahmjOywczfcg4CjFAmmKXauWSbN1R4/xxoL9xkN6XvCgRRytiJJuvOXLlOGDuiI+j+cL eeP/qoiLkJ9Ei9JbtUxL8132XWXWWYWk1Lt31PkoL2FDufh+RtqKlumnw6OXvjS1f9ys9Fyu tRdfWKo9sa1xZnV0j978d3fS91idnO10piyJwY4jCzPZ5Sk7ZhyprjhBXTEVhTy+Um3FnixT 5q6cZb+w0ja8rT4teW6NPz71omtTfu+W6/vu8ApayNGtW00ZBd0/DyNKK1kDAAA= Archived-At: Cc: "Bob Briscoe \(ietf@bobbriscoe.net\)" , "quic@ietf.org" , "'mirja.kuehlewind@tik.ee.ethz.ch'" , "Michael Welzl \(michawe@ifi.uio.no\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Dec 2016 10:18:50 -0000 --_000_DB4PR07MB3488DAC5AFB3A816541B06EC2920DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBkZWNpZGVkIHRoYXQgaXQgaXMgaGlnaCB0aW1lIHRvIGdldCBzdGFydGVkIHdpdGgg dGhpcyBhZnRlciB0aGUgaG9saWRheXMuDQpUaGUgcHJvc2VkIEVDTiBUT0RPIGl0ZW1zIGFyZSBk ZXNjcmliZWQgaW4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMv NjggLg0KDQogICogICBFQ04gZWNobyBpbiBwcm90b2NvbCwgcHJlZmVycmFibHkgYXMgYSBtYW5k YXRvcnkgdG8gaW1wbGVtZW50IHBhcnQsIFJGQzc1NjAgY2FuIHByb3ZpZGUgd2l0aCB2YWx1YWJs ZSBpbnB1dCBpbiB0aGUgZGVzaWduDQogICogICBFQ04gbmVnb3RpYXRpb24sIHRoZSB3b3JrIG9u IHVwZGF0ZWQgRUNOIHNlbWFudGljdHMgaW4gVFNWV0cgc2hvdWxkIGJlIGFkZHJlc3NlZCAoTDRT IHN1cHBvcnQpDQogICogICBGYWxsYmFjayBmb3IgaW4gdmFyaW91cyBmYWlsdXJlIGNhc2VzLCBS RkM2Njc5IGFuZCBkcmFmdC1rdWVobGV3aW5kLXRjcG0tZWNuLWZhbGxiYWNrLTAxIG1heSBwcm92 aWRlIGlucHV0DQogICogICBBZGRyZXNzIHVzZXIgc3BhY2UgbGltaXRhdGlvbiwgY29sbGVjdCBi ZXN0IGN1cnJlbnQgcHJhY3RpY2UgdG8gcmVhZC93cml0ZSBFQ04gYml0cyBmb3IgZGlmZmVyZW50 IE9TLg0KICAqICAgQWxpZ24gbWVhbmluZyBvZiBFQ04tQ0UgbWFya2luZyBvZiBFQ1QoMCkgYW5k IEVDVCgxKSB0cmFmZmljIHdpdGggVFNWV0cNCg0KTXkgdGhpbmtpbmcgaXMgdGhhdCBpdCBpcyBw ZXJoYXBzIGJlc3QgdG8gc3RhcnQgd2l0aCBhIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIGhvdyB0aGVz ZSBUT0RPcyBhcmUgc29sdmVkID8uIEFzIGl0IGV2b2x2ZXMsIHNlbGVjdCBwYXJ0cyBvZiBpdCBj YW4gYmUgbW92ZWQgIHRvIHRoZSBhcHBsaWNhYmxlIFdHIGRyYWZ0cywgbW9zdCBsaWtlbHkgdGhp cyBFQ04gaW4gUVVJQyBjYW4gc2lsZW50bHkgZXhwaXJlIHVubGVzcyB0aGVyZSBhcmUgcGFydHMg dGhhdCBkb27igJl0IGZpdCBpbiBhbiBleGlzdGluZyBXRyBkcmFmdC4NCkRvZXMgdGhpcyBzb3Vu ZCByZWFzb25hYmxlID8NCg0KL0luZ2VtYXINCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IGRlbiAzIGRlY2VtYmVyIDIwMTYgMTY6NDANClRvOiBJ bmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCkNj OiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogRUNOIHN1cHBvcnQgaW4gUVVJQw0KDQpHb29k IHBvaW50LCBJIGFkZGVkIGFuIG9wZW4gaXNzdWUgZm9yIEVDTi4gIEZlZWwgZnJlZSB0byBhZGQg YW55IGNvbW1lbnRzIHRoZXJlLg0KDQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJh ZnRzL2lzc3Vlcy82OA0KDQpPbiBGcmksIERlYyAyLCAyMDE2IGF0IDc6MDkgQU0sIEluZ2VtYXIg Sm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzppbmdl bWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkNCg0KSSBjb21tZW50ZWQg YSBsaXR0bGUgb24gIGRyYWZ0LWl5ZW5nYXItcXVpYy1sb3NzLXJlY292ZXJ5LTAxDQpodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3F1aWMvcWhZc2xBbWxiUFBDYUY1N1FtNzBf VHJnNFhRDQpSZWFsaXplIHRoYXQgaGUgZHJhZnQgd2FzIHJlbmFtZWQgdG8gZHJhZnQtaWV0Zi1x dWljLXJlY292ZXJ5IHNob3J0bHkgIGFmdGVyLiBJIHdpbGwgcmVhZCBpdCBhbmQgc2VlIGlmIG15 IGNvbW1lbnRzIGFyZSBzdGlsbCB2YWxpZC4NCg0KSSBoYXZlIG9uZSBxdWVzdGlvbiB0aG91Z2gg YXMgcmVnYXJkcyB0byBFQ04gc3VwcG9ydCBpbiBRVUlDLCB3aGVyZSB3aWxsIHRoaXMgYmUgZGVz Y3JpYmVkLiBJIGNhbiBpbWFnaW5lIHRoYXQgcGFydHMgb2YgaXQgd2lsbCBnbyBpbiBxdWljLXJl Y292ZXJ5IGJ1dCBJIGFzc3VtZSB0aGF0IHF1aWMtdHJhbnNwb3J0IG5lZWRzIGFuIHVwZGF0ZSBm b3IgdGhlIHByb3RvY29sIHNwZWNpZmljcywgZG9lcyB0aGUgaGFuZHNoYWtlIGFuZCBuZWdvdGlh dGlvbiBhcyB3ZWxsIGFzIHBvc3NpYmxlIGZhbGxiYWNrIHVwb24gZmFpbHVyZSBnbyB0aGVyZSBh cyB3ZWxsLg0KDQovSW5nZW1hcg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpJbmdlbWFyIEpvaGFuc3NvbiAgTS5TYy4NCk1hc3RlciBSZXNlYXJjaGVyDQoNCkVyaWNzc29u IEFCDQpXaXJlbGVzcyBBY2Nlc3MgTmV0d29ya3MNCkxhYnJhdG9yaWVncsOkbmQgMTENCjk3MSAy OCwgTHVsZcOlLCBTd2VkZW4NClBob25lICs0Ni0xMDcxIDQzMDQyDQpTTVMvTU1TICs0Ni03MyAw NzggMzI4OTx0ZWw6KzQ2JTIwNzMlMjAwNzglMjAzMiUyMDg5Pg0KaW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0K d3d3LmVyaWNzc29uLmNvbTxodHRwOi8vd3d3LmVyaWNzc29uLmNvbT4NCg0KICAgICBObywgeW91 IGNhbsK0dCB0ZWxsIHBlb3BsZSBhbnl0aGluZw0KICAgICAgICAgWW914oCZdmUgZ290IHRvIHNo b3cg4oCYZW0NCiAgICAgICAgICAgICAgQnJ1Y2UgU3ByaW5nc3RlZW4NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCg0KDQo= --_000_DB4PR07MB3488DAC5AFB3A816541B06EC2920DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1 cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTk5 MjgzMzc2NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjI1NzUxNzA0O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNt O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkkgZGVjaWRlZCB0aGF0IGl0IGlzIGhpZ2ggdGltZSB0byBnZXQgc3RhcnRlZCB3aXRoIHRo aXMgYWZ0ZXIgdGhlIGhvbGlkYXlzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgcHJvc2VkIEVDTiBUT0RPIGl0ZW1zIGFy ZSBkZXNjcmliZWQgaW4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dn L2Jhc2UtZHJhZnRzL2lzc3Vlcy82OCI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRy YWZ0cy9pc3N1ZXMvNjg8L2E+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZiI+RUNOIGVjaG8gaW4gcHJvdG9jb2wsIHByZWZlcnJhYmx5IGFzIGEgbWFuZGF0b3J5 IHRvIGltcGxlbWVudCBwYXJ0LCBSRkM3NTYwIGNhbiBwcm92aWRlIHdpdGggdmFsdWFibGUgaW5w dXQgaW4gdGhlIGRlc2lnbjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OyxzYW5zLXNlcmlmIj5FQ04gbmVnb3RpYXRpb24sIHRoZSB3b3JrIG9uIHVwZGF0ZWQgRUNO IHNlbWFudGljdHMgaW4gVFNWV0cgc2hvdWxkIGJlIGFkZHJlc3NlZCAoTDRTIHN1cHBvcnQpPG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMz MzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPkZh bGxiYWNrIGZvciBpbiB2YXJpb3VzIGZhaWx1cmUgY2FzZXMsIFJGQzY2NzkgYW5kIGRyYWZ0LWt1 ZWhsZXdpbmQtdGNwbS1lY24tZmFsbGJhY2stMDEgbWF5IHByb3ZpZGUgaW5wdXQ8bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMztt YXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+QWRkcmVzcyB1 c2VyIHNwYWNlIGxpbWl0YXRpb24sIGNvbGxlY3QgYmVzdCBjdXJyZW50IHByYWN0aWNlIHRvIHJl YWQvd3JpdGUgRUNOIGJpdHMgZm9yIGRpZmZlcmVudCBPUy48bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMu MHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xO2Jh Y2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+QWxpZ24gbWVhbmluZyBvZiBFQ04t Q0UgbWFya2luZyBvZiBFQ1QoMCkgYW5kIEVDVCgxKSB0cmFmZmljIHdpdGggVFNWV0c8bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+TXkgdGhpbmtpbmcgaXMgdGhhdCBpdCBpcyBwZXJoYXBzIGJlc3QgdG8g c3RhcnQgd2l0aCBhIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIGhvdyB0aGVzZSBUT0RPcyBhcmUgc29s dmVkID8uIEFzIGl0IGV2b2x2ZXMsIHNlbGVjdCBwYXJ0cyBvZiBpdCBjYW4gYmUgbW92ZWQgJm5i c3A7dG8gdGhlIGFwcGxpY2FibGUNCiBXRyBkcmFmdHMsIG1vc3QgbGlrZWx5IHRoaXMgRUNOIGlu IFFVSUMgY2FuIHNpbGVudGx5IGV4cGlyZSB1bmxlc3MgdGhlcmUgYXJlIHBhcnRzIHRoYXQgZG9u 4oCZdCBmaXQgaW4gYW4gZXhpc3RpbmcgV0cgZHJhZnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRvZXMgdGhpcyBzb3VuZCBy ZWFzb25hYmxlID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+L0luZ2VtYXI8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dl dHRAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMyBkZWNlbWJlciAyMDE2IDE2 OjQwPGJyPg0KPGI+VG86PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEVDTiBzdXBwb3J0IGluIFFVSUM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBwb2ludCwgSSBhZGRl ZCBhbiBvcGVuIGlzc3VlIGZvciBFQ04uJm5ic3A7IEZlZWwgZnJlZSB0byBhZGQgYW55IGNvbW1l bnRzIHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNjgi Pmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzY4PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IERlYyAyLCAyMDE2IGF0IDc6MDkgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9 Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SSBjb21tZW50ZWQgYSBsaXR0bGUgb24gJm5ic3A7ZHJhZnQtaXllbmdhci1x dWljLWxvc3MtcmVjb3ZlcnktMDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9xdWljL3Fo WXNsQW1sYlBQQ2FGNTdRbTcwX1RyZzRYUSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcXVpYy9xaFlzbEFtbGJQUENhRjU3UW03MF9Ucmc0WFE8 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlYWxpemUgdGhhdCBo ZSBkcmFmdCB3YXMgcmVuYW1lZCB0byBkcmFmdC1pZXRmLXF1aWMtcmVjb3Zlcnkgc2hvcnRseSAm bmJzcDthZnRlci4gSSB3aWxsIHJlYWQgaXQgYW5kIHNlZSBpZiBteSBjb21tZW50cyBhcmUgc3Rp bGwgdmFsaWQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBvbmUgcXVlc3Rp b24gdGhvdWdoIGFzIHJlZ2FyZHMgdG8gRUNOIHN1cHBvcnQgaW4gUVVJQywgd2hlcmUgd2lsbCB0 aGlzIGJlIGRlc2NyaWJlZC4gSSBjYW4gaW1hZ2luZSB0aGF0IHBhcnRzIG9mIGl0IHdpbGwgZ28g aW4gcXVpYy1yZWNvdmVyeSBidXQgSSBhc3N1bWUgdGhhdCBxdWljLXRyYW5zcG9ydA0KIG5lZWRz IGFuIHVwZGF0ZSBmb3IgdGhlIHByb3RvY29sIHNwZWNpZmljcywgZG9lcyB0aGUgaGFuZHNoYWtl IGFuZCBuZWdvdGlhdGlvbiBhcyB3ZWxsIGFzIHBvc3NpYmxlIGZhbGxiYWNrIHVwb24gZmFpbHVy ZSBnbyB0aGVyZSBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iU1YiPi9JbmdlbWFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNW Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRv c3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPkluZ2VtYXIgSm9oYW5zc29uJm5ic3A7IE0uU2MuDQo8L3NwYW4+ PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hc3RlciBSZXNlYXJj aGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0 b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+RXJpY3Nzb24gQUI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaXJlbGVzcyBBY2Nl c3MgTmV0d29ya3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5MYWJyYXRvcmllZ3LDpG5kIDEx PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OTcxIDI4LCBMdWxlw6UsIFN3ZWRlbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25l Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlBob25lICYjNDM7NDYtMTA3MSA0MzA0Mjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlNNUy9NTVMgPC9zcGFuPjxhIGhyZWY9InRlbDomIzQzOzQ2JTIwNzMlMjAw NzglMjAzMiUyMDg5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+JiM0Mzs0Ni03MyAw NzggMzI4OTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5pbmdlbWFyLnMu am9oYW5zc29uQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnd3dy5lcmljc3Nv bi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNDQ0NDREQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWF1 dG9zcGFjZTpub25lIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE5vLCB5b3UgY2FuwrR0IHRlbGwgcGVvcGxlIGFueXRoaW5nPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYXV0b3NwYWNlOm5v bmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWW914oCZdmUgZ290IHRvIHNob3cg4oCYZW08 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hdXRvc3Bh Y2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBCcnVjZSBTcHJpbmdzdGVlbjxzcGFuIHN0eWxlPSJjb2xvcjojMzMzMzMzIj48YnI+ DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB3488DAC5AFB3A816541B06EC2920DB4PR07MB348eurprd_-- From nobody Thu Dec 22 07:40:10 2016 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 B3C1512967E for ; Thu, 22 Dec 2016 07:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, 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 9hLo0Go6ToPd for ; Thu, 22 Dec 2016 07:40:08 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CC92A127A91 for ; Thu, 22 Dec 2016 07:40:07 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 7C3001A0213; Thu, 22 Dec 2016 16:40:06 +0100 (CET) Subject: Re: Nested length Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B55A3EF5-54E0-4B96-89E2-B1F4DFD91BAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Thu, 22 Dec 2016 16:40:05 +0100 Message-Id: <43394F35-D445-475B-ABE7-F09AF245AE10@trammell.ch> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Dec 2016 15:40:09 -0000 --Apple-Mail=_B55A3EF5-54E0-4B96-89E2-B1F4DFD91BAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Phill, Thanks for raising this point. The current arrangement of the packet = header doesn't have nested length encoding issues (unless you count IP = length and UDP length), however it does look a bit fiddlier than it = needs to be. Simplifying the layout and reducing the permutations of = field offset and length will reduce the number of ways packet processing = can go wrong. I haven't dug into nested-length issues in the frame = format or in TLS 1.3 yet, though. (and in case there's any question on the pre-hijacked topic of this = thread, I'm also in favor of big-endian, for the usual reasons.) Cheers, Brian > On 21 Dec 2016, at 15:10, Phillip Hallam-Baker = wrote: >=20 > I agree on big endian. >=20 > But one area I would point out as a serious fire hazard is nested = length specifiers. These are a real minefield from a security point of = view. In 1980, it was considered OK to use tools that let the less = skilled develop code that would create security holes. Today we are all = living with the consequences of billions of holes created by millions of = incompetents. >=20 >=20 > Specifically, the problem that comes up is encoding structures of the = form >=20 > x { { Test1 }, { Test2 } } >=20 > Encoding in XML, JSON or any modified S-notation like scheme is safe = because a decoder has to allocate memory as it goes. This is inefficient = of course. >=20 > Encoding in ASN.1 BER indefinite length encoding is also safe. Here we = identify the extent of terminal nodes by means of a length specifier but = close the list/set explicitly: >=20 > x { 4: "Test" , 5 "Test2" } >=20 > Encoding in the ASN.1 DER encoding is not only a pig to write unless = you know the trick, it is also unsafe. >=20 > 11: 4: "Test" , 5 "Test2" >=20 > Specifically the problem comes when an attacker produces something of = the form: >=20 > 11: 4: "Test" , 66666666: "Test2" >=20 > This is one of the main ways to create a buffer overrun and smash the = stack. >=20 >=20 > Nested length encodings are really bad news and require serious coding = effort if a vulnerability isn't going to be created. While early = implementations of QUIC are likely to be at the application layer, we = can expect this sort of code to head to the kernel fairly fast. >=20 > The O/S people do not understand the seriousness of this problem. When = someone tried to put some protection macros into the Linux IPv6 code, = Linus himself called out the coder as guilty of 'compiler masturbation' = and publicly vilified him. So much for the many eyes theory of security. = It doesn't work so well if an ignoramus then ignores the result. >=20 >=20 > I strongly suggest a bar on nested length encodings in the spec and = perform an audit when you are done. It was a style that was acceptable = in the 1980s but we have learned is unsafe and must be avoided. >=20 >=20 > On Wed, Dec 21, 2016 at 7:55 AM, Eggert, Lars wrote: > Hi, >=20 > we had very strong consensus during the Seoul meeting to use = big-endian encoding for QUIC. We'd like to confirm this consensus on the = list. >=20 > If you *disagree*, please reply to the list by Jan 6, 2017. >=20 > Lars >=20 --Apple-Mail=_B55A3EF5-54E0-4B96-89E2-B1F4DFD91BAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYW/PWAAoJEIoSt78L6kajXO8P/ilJdagW6u29GD4l2VEpzzhE AV1riNRJDt3X66dPcbvQdgXBaIfSkx1o5HcgZd1+HI63MwtGahGrR2vuDSDjd0P7 /sF+L4OihQPlWVp6aKOfz+T4z6aquNSLhlmkLwwBDGVhnDbeFTuzK7V3XL6jVL7H QKuHy3s78WS0jOy3sCFsSzf55OTO3WvtUyri+tmoixlCp7YJYoMcLVEBJzjHvRgg yIW1hkkQ/O74jhbdLSqHoM0+o15FNQma8SWEPjhWOQ7GQzHEgfBFZq6fgyuju8zV OPPzIXwKytiB2Kh1h/d3uqAEoJm3dTjrbBUolr+eoR9MpX2/zpNanc61a+bCIrub 5m2WuT/hj7nlLNvWxTv7Sw8Pz16YtjokcQtLWSN4nLCfExR88rh8aLlLcsX2S9mJ DMGUPCAr3TXK+m9dFumHrS63lJ3i9V5nHMvwZG51mtkTwGMTj907m/+P7SvwqRbJ hyXqHyewfQzJlAuTSTIWlFWKQTU+tM2wJ63bAg/7xBhCH8adxBNnfMIbe1QVZmGw JF6LetOFI7A4bNY8D57oGrgSQGvt3eCmziQIdJHj/evrRuR9fvgr8fmqDtf0pYxi tKqh+glpjPtHCWHLo/CyL4PafYvWqhv9X1zZ2I+xYjC7VAR5wC1PTSgVbE3UQ6Vb yA6wfF69097szfZ+Oszu =c/5R -----END PGP SIGNATURE----- --Apple-Mail=_B55A3EF5-54E0-4B96-89E2-B1F4DFD91BAE-- From nobody Thu Dec 22 09:46:47 2016 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 CFB341294E1 for ; Thu, 22 Dec 2016 09:46:45 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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=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 xgAMgDxg1cOF for ; Thu, 22 Dec 2016 09:46:42 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A457B12971E for ; Thu, 22 Dec 2016 09:46:42 -0800 (PST) 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; bh=WVYTkeziAGXDxr9svXFX+pNKobd5sDEgZoRfeiRv05Q=; b=WjBbbySClxCtpRJrRC2ZmYTX1OXCDc5i/35E4hEM+e1voMsbNtVOBH+r6EN86/aHILQZiYMXEptPSHKPP4Bsfj8PLkHSvFCphp2/Pbb5clz8Ak1qTEjP5iBvwv2Rgo/ZNzasDwHQnhqgqY1XCQn6sNI5mbpd35EKIWqzx/UrVpw= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 22 Dec 2016 17:46:40 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0803.013; Thu, 22 Dec 2016 17:46:40 +0000 From: Mike Bishop To: Brian Trammell , Phillip Hallam-Baker Subject: RE: Nested length Thread-Topic: Nested length Thread-Index: AQHSXGmxIgd+v0ZVq0CMwDcRWJgxD6EUNn2Q Date: Thu, 22 Dec 2016 17:46:40 +0000 Message-ID: References: <43394F35-D445-475B-ABE7-F09AF245AE10@trammell.ch> In-Reply-To: <43394F35-D445-475B-ABE7-F09AF245AE10@trammell.ch> 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=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:7404:4073:b8ce:562d] x-ms-office365-filtering-correlation-id: 1adae577-563a-4095-bb23-08d42a927c54 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:wnYIBLv5yy9Z2BFr5MjUxU5RCecINl/0WUGRQKfjD1rV40wmb279RT9fDcMmQmPnqRoaqOf+E/W3oqxiVSrjULuOggJchjY+lEeWoONbjJLNiVHdTsSAVDJ9mf26DB8eQkvl8TU0ZiDl+LgHLCLpR9FY2sumQirylUUZLIin/AnyWnQPgtN1NKuWXs5HEkxeOHpsQB6zpGxeOOc/XX7DlGfbsSXg8urB3/CWgsiUo8p/j5fXyeJXit4sWJKnwPMDwws7G2f8KSNP2ZHTkk8EhgiAw5FwFixVznrpLhX97tgK9H8uztqFdPgCWbewPHPoS24xHlqMN00LZuGUF3MY9jExRWCwYknXIYYgn1KDkxy14YY7PjpJEbSUVXTQqSvaP1MHzXLA73aXE1YTavuVdUcVNl0LXDiNiVhCNVVyLD2Ma8ni6DxOIKb/2fvCnskc3JAvayTAiGTBi833bQlJ5H6BpQOiiIfJUzh03zfY1BA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6047074)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(189002)(199003)(377454003)(13464003)(24454002)(189998001)(99286002)(6506006)(106116001)(105586002)(92566002)(106356001)(229853002)(50986999)(38730400001)(3660700001)(2900100001)(9686002)(76176999)(3480700004)(68736007)(54356999)(5005710100001)(101416001)(6116002)(102836003)(790700001)(10290500002)(8990500004)(97736004)(5001770100001)(33656002)(77096006)(10090500001)(4326007)(2906002)(6436002)(7696004)(7736002)(5660300001)(7116003)(2950100002)(76576001)(122556002)(86362001)(221733001)(86612001)(81166006)(8676002)(8936002)(25786008)(81156014)(3280700002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270816B0FCB7009779C9DF6987920BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 17:46:40.2429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 22 Dec 2016 17:46:46 -0000 --_000_BN6PR03MB270816B0FCB7009779C9DF6987920BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem I have with such a fundamental ban is that UDP already has a le= ngth field in the outside of the packet. To prohibit nested length fields = would be to prohibit length fields entirely in QUIC, which doesn't appear t= o be practical. However, looking at places where they occur and asking whe= ther there are better ways to accomplish the same thing is certainly a usef= ul exercise. The transport protocol has an obvious nested-length combination, of course:= the collection of frames inside a packet. The UDP packet has a length, by= which the length of the AEAD data can be derived. That data, decrypted, c= ontains a series of frames. Some frames are fixed-length, some specify the= ir length, and some extend to the end of the packet. The spec requires tha= t a frame not cross a packet boundary, which could be read as a requirement= that implementations check for excessive lengths, but that's not currently= called out as explicitly as it could be. If you have suggestions on how t= o eliminate this, they would be welcome, I'm sure. Otherwise, I'd suggest = we strengthen that language and move on. In the HTTP layer, we also have some of this. We're insulated from QUIC's = framing by the bytestream abstraction - if one of our frames extends past t= he end of a QUIC frame... oh well. And it often will, I expect. HTTP/2 ty= pically solves this in one of two ways: Either the frame is a fixed-length= (and any other length MUST be a fatal error), or the frame consists of a p= otentially-optional fixed-length segment followed by a variable-length segm= ent that runs to the end of the frame. The same is true for the HTTP/QUIC = mapping as it currently stands. The exception, in both cases, is SETTINGS. In HTTP/2, each setting takes u= p six octets, so the SETTINGS frame payload must be a multiple of six octet= s. In the current HTTP/QUIC, we've introduced variable-length setting valu= es -- and you have a good point that, since each setting value specifies it= s own length, that length could run beyond the end of the SETTINGS frame. = If you have any suggestions on how to adapt the safer structures to that sc= enario, I'd welcome them; I'll give this some thought as well as adding lan= guage that the length MUST be compared to the remaining length of the frame= . -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Thursday, December 22, 2016 7:40 AM To: Phillip Hallam-Baker Cc: IETF QUIC WG Subject: Re: Nested length hi Phill, Thanks for raising this point. The current arrangement of the packet header= doesn't have nested length encoding issues (unless you count IP length and= UDP length), however it does look a bit fiddlier than it needs to be. Simp= lifying the layout and reducing the permutations of field offset and length= will reduce the number of ways packet processing can go wrong. I haven't d= ug into nested-length issues in the frame format or in TLS 1.3 yet, though. (and in case there's any question on the pre-hijacked topic of this thread,= I'm also in favor of big-endian, for the usual reasons.) Cheers, Brian > On 21 Dec 2016, at 15:10, Phillip Hallam-Baker > wrote: > > I agree on big endian. > > But one area I would point out as a serious fire hazard is nested length = specifiers. These are a real minefield from a security point of view. In 19= 80, it was considered OK to use tools that let the less skilled develop cod= e that would create security holes. Today we are all living with the conseq= uences of billions of holes created by millions of incompetents. > > > Specifically, the problem that comes up is encoding structures of the for= m > > x { { Test1 }, { Test2 } } > > Encoding in XML, JSON or any modified S-notation like scheme is safe beca= use a decoder has to allocate memory as it goes. This is inefficient of cou= rse. > > Encoding in ASN.1 BER indefinite length encoding is also safe. Here we id= entify the extent of terminal nodes by means of a length specifier but clos= e the list/set explicitly: > > x { 4: "Test" , 5 "Test2" } > > Encoding in the ASN.1 DER encoding is not only a pig to write unless you = know the trick, it is also unsafe. > > 11: 4: "Test" , 5 "Test2" > > Specifically the problem comes when an attacker produces something of the= form: > > 11: 4: "Test" , 66666666: "Test2" > > This is one of the main ways to create a buffer overrun and smash the sta= ck. > > > Nested length encodings are really bad news and require serious coding ef= fort if a vulnerability isn't going to be created. While early implementati= ons of QUIC are likely to be at the application layer, we can expect this s= ort of code to head to the kernel fairly fast. > > The O/S people do not understand the seriousness of this problem. When so= meone tried to put some protection macros into the Linux IPv6 code, Linus h= imself called out the coder as guilty of 'compiler masturbation' and public= ly vilified him. So much for the many eyes theory of security. It doesn't w= ork so well if an ignoramus then ignores the result. > > > I strongly suggest a bar on nested length encodings in the spec and perfo= rm an audit when you are done. It was a style that was acceptable in the 19= 80s but we have learned is unsafe and must be avoided. > > > On Wed, Dec 21, 2016 at 7:55 AM, Eggert, Lars > wrote: > Hi, > > we had very strong consensus during the Seoul meeting to use big-endian e= ncoding for QUIC. We'd like to confirm this consensus on the list. > > If you *disagree*, please reply to the list by Jan 6, 2017. > > Lars > --_000_BN6PR03MB270816B0FCB7009779C9DF6987920BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The problem I have with such a fundamental ban is= that UDP already has a length field in the outside of the packet.  To= prohibit nested length fields would be to prohibit length fields entirely = in QUIC, which doesn’t appear to be practical.  However, looking at places where they occur and asking whether there are b= etter ways to accomplish the same thing is certainly a useful exercise.

 

The transport protocol has an obvious nested-leng= th combination, of course: the collection of frames inside a packet.  = The UDP packet has a length, by which the length of the AEAD data can be de= rived.  That data, decrypted, contains a series of frames.  Some frames are fixed-length, some specify their= length, and some extend to the end of the packet.  The spec requires = that a frame not cross a packet boundary, which could be read as a requirem= ent that implementations check for excessive lengths, but that’s not currently called out as explicitly as it cou= ld be.  If you have suggestions on how to eliminate this, they would b= e welcome, I’m sure.  Otherwise, I’d suggest we strengthen= that language and move on.

 

In the HTTP layer, we also have some of this.&nbs= p; We’re insulated from QUIC’s framing by the bytestream abstra= ction – if one of our frames extends past the end of a QUIC frameR= 30; oh well.  And it often will, I expect.  HTTP/2 typically solv= es this in one of two ways:  Either the frame is a fixed-length (and any= other length MUST be a fatal error), or the frame consists of a potentiall= y-optional fixed-length segment followed by a variable-length segment that = runs to the end of the frame.  The same is true for the HTTP/QUIC mapping as it currently stands.

 

The exception, in both cases, is SETTINGS.  = In HTTP/2, each setting takes up six octets, so the SETTINGS frame payload = must be a multiple of six octets.  In the current HTTP/QUIC, we've int= roduced variable-length setting values -- and you have a good point that, since each setting value specifies its own len= gth, that length could run beyond the end of the SETTINGS frame.  If y= ou have any suggestions on how to adapt the safer structures to that scenar= io, I'd welcome them; I'll give this some thought as well as adding language that the length MUST be compared t= o the remaining length of the frame.

 

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
Sent: Thursday, December 22, 2016 7:40 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Nested length

 

hi Phill,

 

Thanks for raising this point. The current arrang= ement of the packet header doesn't have nested length encoding issues (unle= ss you count IP length and UDP length), however it does look a bit fiddlier= than it needs to be. Simplifying the layout and reducing the permutations of field offset and length will r= educe the number of ways packet processing can go wrong. I haven't dug into= nested-length issues in the frame format or in TLS 1.3 yet, though.

 

(and in case there's any question on the pre-hija= cked topic of this thread, I'm also in favor of big-endian, for the usual r= easons.)

 

Cheers,

 

Brian

 

> On 21 Dec 2016, at 15:10, Phillip Hallam-Bak= er <phill@hallambaker.com> wrote:=

>

> I agree on big endian.

>

> But one area I would point out as a serious = fire hazard is nested length specifiers. These are a real minefield from a = security point of view. In 1980, it was considered OK to use tools that let= the less skilled develop code that would create security holes. Today we are all living with the consequences of bi= llions of holes created by millions of incompetents.

>

>

> Specifically, the problem that comes up is e= ncoding structures of the form

>

> x {  { Test1 }, { Test2 } }<= /p>

>

> Encoding in XML, JSON or any modified S-nota= tion like scheme is safe because a decoder has to allocate memory as it goe= s. This is inefficient of course.

>

> Encoding in ASN.1 BER indefinite length enco= ding is also safe. Here we identify the extent of terminal nodes by means o= f a length specifier but close the list/set explicitly:

>

> x { 4: "Test" , 5 "Test2"= ; }

>

> Encoding in the ASN.1 DER encoding is not on= ly a pig to write unless you know the trick, it is also unsafe.<= /p>

>

> 11:  4: "Test" , 5 "Test= 2"

>

> Specifically the problem comes when an attac= ker produces something of the form:

>

> 11:  4: "Test" , 66666666: &q= uot;Test2"

>

> This is one of the main ways to create a buf= fer overrun and smash the stack.

>

>

> Nested length encodings are really bad news = and require serious coding effort if a vulnerability isn't going to be crea= ted. While early implementations of QUIC are likely to be at the applicatio= n layer, we can expect this sort of code to head to the kernel fairly fast.

>

> The O/S people do not understand the serious= ness of this problem. When someone tried to put some protection macros into= the Linux IPv6 code, Linus himself called out the coder as guilty of 'comp= iler masturbation' and publicly vilified him. So much for the many eyes theory of security. It doesn't work so well= if an ignoramus then ignores the result.

>

>

> I strongly suggest a bar on nested length en= codings in the spec and perform an audit when you are done. It was a style = that was acceptable in the 1980s but we have learned is unsafe and must be = avoided.

>

>

> On Wed, Dec 21, 2016 at 7:55 AM, Eggert, Lar= s <lars@netapp.com> wrote:

> Hi,

>

> we had very strong consensus during the Seou= l meeting to use big-endian encoding for QUIC. We'd like to confirm this co= nsensus on the list.

>

> If you *disagree*, please reply to the list = by Jan 6, 2017.

>

> Lars

>

 

--_000_BN6PR03MB270816B0FCB7009779C9DF6987920BN6PR03MB2708namp_-- From nobody Fri Dec 23 07:34:35 2016 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 8A3AC129678 for ; Fri, 23 Dec 2016 07:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Lbo9elAKC0-r for ; Fri, 23 Dec 2016 07:34:33 -0800 (PST) Received: from mail-wj0-x230.google.com (mail-wj0-x230.google.com [IPv6:2a00:1450:400c: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 2159D1295CB for ; Fri, 23 Dec 2016 07:34:33 -0800 (PST) Received: by mail-wj0-x230.google.com with SMTP id v7so255551726wjy.2 for ; Fri, 23 Dec 2016 07:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/qTRsvVX3qkoB3SUiDuQpP2P4o07XUp7tPKPlOTK7bU=; b=M9ukRtivMv8+hjN1x4lqIR+If+vSiOWsahy4oiVIHl54cumFwpE+RGEYav/CQWjIlF M/QGXuyYzUvtQSKS59UKi9/cB8CGY0euUwMuYy0w8H+LbYbnePxHYTnYOkxwae/nXfnq a8LGY1eAi/A/vcyFxoqdqpnxOhFPHQHPTwveqVYmG5ssT+dCKuQ2aM9HemRAw5lNKLpc Ri8JUDAaJzwm1FVmXr+mZKmt+WYwkMS2ycrgjsu/vhIA6mxLvYJ2scyrt0jjloNi/SLt 2JvU4WfHCQy3qC3acUIS2smg+ObbV2yhNkN5Ca9J+JWM0aEC52+Tdf+iX+AyX6fWqw7j aRzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/qTRsvVX3qkoB3SUiDuQpP2P4o07XUp7tPKPlOTK7bU=; b=tKgvT91KsKn1qfDjklKFb1mtGYjU8UmbPT/w7lvTvGGm4BRnboD7Mw/BBtEtnwGLui KLxDHr4liNZmIfzerph3B7oLpbz5ZkuxYWXM77OXxYK9B++NqYEaVU5U6V4PhRb08Ncw iwGKFhpFtRXEh3ik8GXG8VAR+WX5FclR1ndYI9FHZIvhzS3tPxH0zMviTNv7m7dsaP7E JTa88mc9o07VZ0M1Z8w2d0i08A14ye+tB0SpNX+6s8RazR41JIerbIroEqGtT7+KlTxB lu0mpSkEco8LsTexNYRv1xo9fIHt5TEsgZvc4GfHa601OWNqDEJRTX5YFHIZfdd/OFXL WJZg== X-Gm-Message-State: AIkVDXJZHDZZzp0EzhG1Mj406bk1d+E+cdIjZ1yEU2a3vfDMW1XWpsuif9yqoUTIehGSFUbMg5TqJCiMw7vPlA== X-Received: by 10.194.187.103 with SMTP id fr7mr13496751wjc.99.1482507271608; Fri, 23 Dec 2016 07:34:31 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.194.83.101 with HTTP; Fri, 23 Dec 2016 07:34:30 -0800 (PST) In-Reply-To: <08de01d25ba6$921600e0$b64202a0$@huitema.net> References: <6E67B1C8-0D14-4478-A165-5227061B4973@netapp.com> <5D797F6B-6567-4A14-A05C-0BA3B9BE42E9@netapp.com> <08de01d25ba6$921600e0$b64202a0$@huitema.net> From: Phillip Hallam-Baker Date: Fri, 23 Dec 2016 10:34:30 -0500 X-Google-Sender-Auth: QXG1QZf3EqccF9C9lrGNTFEEaO0 Message-ID: Subject: Re: Confirming consensus on using big-endian To: Christian Huitema Content-Type: multipart/alternative; boundary=047d7bd6bc9c4d21270544551f2d Archived-At: Cc: Watson Ladd , IETF QUIC WG , "Eggert, Lars" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 23 Dec 2016 15:34:34 -0000 --047d7bd6bc9c4d21270544551f2d Content-Type: text/plain; charset=UTF-8 The only case where this is likely to be an issue is with crypto data some of which is bigendian and some of which is little. I can't ever remember which is which. Where cryptodata is concerned, just specify the fields as opaque blobs, that is byte[] or OCTET STRING. Most of the CMS and PKIX stuff does this for the same reason. --047d7bd6bc9c4d21270544551f2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The= only case where this is likely to be an issue is with crypto data some of = which is bigendian and some of which is little. I can't ever remember w= hich is which.
=
Where cryp= todata is concerned, just specify the fields as opaque blobs, that is byte[= ] or OCTET STRING. Most of the CMS and PKIX stuff does this for the same re= ason.
--047d7bd6bc9c4d21270544551f2d-- From nobody Sun Dec 25 02:05:09 2016 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 4DA6A12711D for ; Sun, 25 Dec 2016 02:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=3.399, RP_MATCHES_RCVD=-3.1] 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 6ZBUtveLL6Wo for ; Sun, 25 Dec 2016 02:05:06 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 2ABE61295FE for ; Sun, 25 Dec 2016 02:05:05 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cL5fr-000GKM-5F for quic@ietf.org; Sun, 25 Dec 2016 11:05:03 +0100 Received: from 212095007006.public.telering.at ([212.95.7.6] helo=[192.168.1.113]) by mail-mx2.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1cL5fp-0007fO-SE; Sun, 25 Dec 2016 11:05:02 +0100 From: Michael Welzl Message-Id: <0D4ACC71-C350-44CD-B26F-99469D3F9F94@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_EF707ED6-701A-422C-A5C7-6597983DE876" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: ECN support in QUIC Date: Sun, 25 Dec 2016 11:05:03 +0100 In-Reply-To: To: Ingemar Johansson S References: X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 8 sum msgs/h 1 total rcpts 50285 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 17EDDEFDD8C268C710D6646623FA5035993B15A6 X-UiO-SPAM-Test: remote_host: 212.95.7.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "Bob Briscoe \(ietf@bobbriscoe.net\)" , Ian Swett , "quic@ietf.org" , "mirja.kuehlewind@tik.ee.ethz.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Dec 2016 10:05:08 -0000 --Apple-Mail=_EF707ED6-701A-422C-A5C7-6597983DE876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 22, 2016, at 11:18 AM, Ingemar Johansson S = wrote: >=20 > Hi > =20 > I decided that it is high time to get started with this after the = holidays. > The prosed ECN TODO items are described in = https://github.com/quicwg/base-drafts/issues/68 = .=20 > ECN echo in protocol, preferrably as a mandatory to implement part, = RFC7560 can provide with valuable input in the design > ECN negotiation, the work on updated ECN semanticts in TSVWG should be = addressed (L4S support) > Fallback for in various failure cases, RFC6679 and = draft-kuehlewind-tcpm-ecn-fallback-01 may provide input > Address user space limitation, collect best current practice to = read/write ECN bits for different OS. > Align meaning of ECN-CE marking of ECT(0) and ECT(1) traffic with = TSVWG > =20 > My thinking is that it is perhaps best to start with a draft that = describes how these TODOs are solved ?. As it evolves, select parts of = it can be moved to the applicable WG drafts, most likely this ECN in = QUIC can silently expire unless there are parts that don=E2=80=99t fit = in an existing WG draft. > Does this sound reasonable ? It does, to me=E2=80=A6 cheers, Michael > =20 > /Ingemar > =20 > From: Ian Swett [mailto:ianswett@google.com = ]=20 > Sent: den 3 december 2016 16:40 > To: Ingemar Johansson S > > Cc: quic@ietf.org > Subject: Re: ECN support in QUIC > =20 > Good point, I added an open issue for ECN. Feel free to add any = comments there. > =20 > https://github.com/quicwg/base-drafts/issues/68 = > =20 > On Fri, Dec 2, 2016 at 7:09 AM, Ingemar Johansson S = > wrote: > Hi > =20 > I commented a little on draft-iyengar-quic-loss-recovery-01 > https://mailarchive.ietf.org/arch/msg/quic/qhYslAmlbPPCaF57Qm70_Trg4XQ = > Realize that he draft was renamed to draft-ietf-quic-recovery shortly = after. I will read it and see if my comments are still valid. > =20 > I have one question though as regards to ECN support in QUIC, where = will this be described. I can imagine that parts of it will go in = quic-recovery but I assume that quic-transport needs an update for the = protocol specifics, does the handshake and negotiation as well as = possible fallback upon failure go there as well. > =20 > /Ingemar > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Master Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com = > www.ericsson.com > =20 > No, you can=C2=B4t tell people anything > You=E2=80=99ve got to show =E2=80=98em > Bruce Springsteen > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail=_EF707ED6-701A-422C-A5C7-6597983DE876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 22, 2016, at 11:18 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi
 
I decided that it is high = time to get started with this after the holidays.
The prosed ECN TODO items are described in https://github.com/quicwg/base-drafts/issues/68 . 
  • ECN echo in = protocol, preferrably as a mandatory to implement part, RFC7560 can = provide with valuable input in the design
  • ECN negotiation, the work on updated ECN = semanticts in TSVWG should be addressed (L4S support)
  • Fallback for in various failure cases, RFC6679 = and draft-kuehlewind-tcpm-ecn-fallback-01 may provide input
  • Address user space limitation, collect best = current practice to read/write ECN bits for different OS.
  • Align meaning of ECN-CE marking of ECT(0) and = ECT(1) traffic with TSVWG
 
My thinking is that it is perhaps best to start = with a draft that describes how these TODOs are solved ?. As it evolves, = select parts of it can be moved  to the applicable WG drafts, most = likely this ECN in QUIC can silently expire unless there are parts that = don=E2=80=99t fit in an existing WG draft.
Does this sound reasonable = ?

It = does, to me=E2=80=A6

cheers,
Michael


 
/Ingemar
 
From: Ian Swett = [mailto:ianswett@google.com] 
Sent: den= 3 december 2016 16:40
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: quic@ietf.org
Subject: Re: ECN support in QUIC
 
Good point, I added an open issue for = ECN.  Feel free to add any comments there.
 
https://github.com/quicwg/base-drafts/issues/68
 
On Fri, Dec 2, 2016 at 7:09 AM, Ingemar = Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi
 
I commented a little on =  draft-iyengar-quic-loss-recovery-01
https://mailarchive.ietf.org/arch/msg/quic/qhYslAmlbPPCaF57Qm70= _Trg4XQ
Realize that he draft was renamed to draft-ietf-quic-recovery = shortly  after. I will read it and see if my comments are still = valid.
 
I have one question though as regards to ECN support in QUIC, = where will this be described. I can imagine that parts of it will go in = quic-recovery but I assume that quic-transport needs an update for the = protocol specifics, does the handshake and negotiation as well as = possible fallback upon failure go there as well.
 
/Ingemar
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ingemar Johansson  M.Sc.
Master Researcher
 
Ericsson AB
Wireless Access = Networks
Labratoriegr=C3=A4nd 11
971 = 28, Lule=C3=A5, Sweden
Phone +46-1071 = 43042
www.ericsson.com
 
     No, you can=C2=B4t tell = people anything
         You=E2=80=99ve= got to show =E2=80=98em
          &nb= sp;   Bruce Springsteen
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= --Apple-Mail=_EF707ED6-701A-422C-A5C7-6597983DE876-- From nobody Fri Dec 30 22:10:34 2016 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 45B771294DF for ; Fri, 30 Dec 2016 22:10:33 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 LmswDWR7i591 for ; Fri, 30 Dec 2016 22:10:31 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 2745912944B for ; Fri, 30 Dec 2016 22:10:31 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id 128so245232000oig.0 for ; Fri, 30 Dec 2016 22:10:31 -0800 (PST) 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=8CbrnWECHp2yRHQeAUvle38xV7Lpa/NnT2UUplkjZHE=; b=kLc5C7KUs0nLXpMfz5crpj51exNXr9FgU9alnGuXmduBHj/dKVqDtui3aiUTwfOwET RGJ8HVwlqBxE1ULAizMkITaW3aUA4aVTImUa7OH2UjzMkPZdIBxQNM1DCtIT1BC3yZ4e CId9fWhyq/veCOJuanlfZ5npxj09oQqTvtbzutXFZ8bIpqtBIz+Iv8zcbuslNP65uFH6 hqGmu4h6uacXrnwwenIuGSRInMCST6F8/nuIq6bai9gjJICoA/ORXNcD9yzscRKmL2iR BiGrmmMXwmXUHyO8qZj2Hd5zW77skbfCtJAzo/QUDInr/1ZxTvgMG/gUofpiYdjSeO7E wuAQ== 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=8CbrnWECHp2yRHQeAUvle38xV7Lpa/NnT2UUplkjZHE=; b=kFRK+70FrBG+oq9lF9K401aOFCyCblmgWcQ+NAYX/t/4U+dHXoSwBAdMBUloavtjT5 Mqyi6YGSlcj73ct9sXSWf2ncOqlKX5LZHUrRSl3xKtegO5QRcL206zPxg362dbaSQ63U SAgZpBVX6ZFcDlHndDV6v/XwL0i3ETKnXJACn3BWI3tahuc1U51bG3sm1wmT4QwORzOs BCXH146iZBzAQiHQNzXJP5Tebi5KMS4hLc+KT5xcVvB8fwzSk8xXvjzjsgeyWXtLhhFC lvMl7MA7UwmiwDwjc9tuLE8pYLuSxyfop+pckc+oCq1Orzr+RlmVt4bxWifMD+kZGlAF 9tSQ== X-Gm-Message-State: AIkVDXLCwiPdS9QzyU3AZO1Thrtqn9za9zsnCL4duvb9f3kCNLAuCnxdgpvC/ReZPJaUYjHUneQrJ9RIcIab9w== X-Received: by 10.157.0.73 with SMTP id 67mr22843885ota.141.1483164630547; Fri, 30 Dec 2016 22:10:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.34.105 with HTTP; Fri, 30 Dec 2016 22:10:30 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Fri, 30 Dec 2016 22:10:30 -0800 Message-ID: Subject: Re: Version Negotiation, Crypto Protocols, and ALPN To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c11f30ef283a10544ee2c72 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Dec 2016 06:10:33 -0000 --94eb2c11f30ef283a10544ee2c72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that binding QUIC versions to the ALPN seems unnecessary. If by the second point you mean that TLS would handle QUIC version negotiation, I'm not sure how that work. In principle new QUIC versions might change the headers, so I'm not sure how we'd get to the TLS message in the general case. Or perhaps I misunderstood what you wrote. On Tue, Dec 20, 2016 at 10:05 AM, Mike Bishop wrote: > We=E2=80=99ve got a couple GitHub issues around version negotiation and h= ow all > the pieces play together. I=E2=80=99d like to keep the layers as modular= as > possible, so I=E2=80=99m trying to flex the joins a little bit conceptual= ly. > > > > =C2=B7 draft-ietf-quic-transport > > says: > > If not explicitly specified in the application mapping, TLS is assumed to > be the default crypto handshake protocol, as described in [QUIC-TLS]. An > application that maps to QUIC MAY however specify an alternative crypto > handshake protocol to be used. > > =C2=B7 draft-ietf-quic-tls > > says: > > The ALPN identifier for the protocol MUST be specific to the QUIC version > that it operates over. > > =C2=B7 draft-ietf-quic-http > > (in PR#90) would say: > > HTTP/QUIC support is indicated by selecting the ALPN token =E2=80=9Chq=E2= =80=9D in the > crypto handshake. > > =C2=B7 Ian=E2=80=99s comment in Issue #45 > : > > I would suggest [the crypto protocol] be baked into the QUIC version. > > > > There=E2=80=99s also some related discussion in Issue #87 > / Issue #89 > which diverged from it. > > > > So the application mapping is supposed to specify the QUIC versions and, > implicitly or explicitly, the crypto protocol that's acceptable. Except > the crypto protocol is already known by the time the ALPN tokens are bein= g > interpreted, because you have to *parse* the QUIC frame and the crypto > protocol to *find* the ALPN tokens. Besides which, I'm inclined *not* to > require new QUIC versions to imply revs to the application protocol anywa= y; > if we had to, either HTTP would define that the ALPN token is e.g. > `hq-QQQQ` (i.e. placeholder where the QUIC version is embedded), but I=E2= =80=99d > prefer that HTTP allows *any* version of QUIC that provides the necessary > properties (which is likely to be all future versions, but not > necessarily). Those versions might or might not use TLS as their crypto > protocol =E2=80=93 HTTP simply requires QUIC, and QUIC simply requires th= at the > crypto handshake be able to negotiate an application-layer protocol. > > > > I=E2=80=99m thinking of it this way: > > =C2=B7 QUIC specifies that a particular QUIC version uses a partic= ular > crypto handshake and/or allocates the crypto protocol a few bits of the > version field. > > =C2=B7 The QUIC TLS extension carries: > > o Client->server: The initially-offered version > > o Client->server: The finally-selected version > > o Server->client: The set of versions the server did / would have sent > in a Version Negotiation packet > > =C2=B7 The application specifies requirements of the QUIC version = to be > used, but doesn=E2=80=99t bind that version in its ALPN token > > > > However, this is a more expansive design issue, so I=E2=80=99d like to ma= ke sure > it=E2=80=99s visible on-list. > --94eb2c11f30ef283a10544ee2c72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that binding QUIC versions to the ALPN seems = unnecessary.

If by the second point you mean that = TLS would handle QUIC version negotiation, I'm not sure how that work. = In principle new QUIC versions might change the headers, so I'm not sur= e how we'd get to the TLS message in the general case.

Or perhaps I misunderstood what you wrote.

On Tue, Dec 20, 2016 at 10:= 05 AM, Mike Bishop <Michael.Bishop@microsoft.com>= wrote:

We=E2=80=99ve got a couple GitHub issues around vers= ion negotiation and how all the pieces play together.=C2=A0 I=E2=80=99d lik= e to keep the layers as modular as possible, so I=E2=80=99m trying to flex = the joins a little bit conceptually.

=C2=A0

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-= ietf-quic-transport says:

If not explicitly sp= ecified in the application mapping, TLS is assumed to be the default crypto= handshake protocol, as described in [QUIC-TLS]. An application that maps to QUIC MAY however specify an alternative crypto handshake protocol = to be used.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-ietf-qui= c-tls says:

The ALPN identifier = for the protocol MUST be specific to the QUIC version that it operates over= .

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dr= aft-ietf-quic-http (in PR#90) would say:

HTTP/QUIC support is= indicated by selecting the ALPN token =E2=80=9Chq=E2=80=9D in the crypto h= andshake.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ian=E2=80=99s comment in Issue #45:

I would suggest [the crypto protocol] b= e baked into the QUIC version.

= =C2=A0

There=E2=80=99s also some related discussion in Issue #87 / Issue #89 which diverged from it.

= =C2=A0

So the application mapping is supposed to specify th= e QUIC versions and, implicitly or explicitly, the crypto protocol that'= ;s acceptable.=C2=A0 Except the crypto protocol is already known by the tim= e the ALPN tokens are being interpreted, because you have to parse the QUIC frame and the crypto protocol to find= the ALPN tokens.=C2=A0 Besides which, I'm inclined *not* to requir= e new QUIC versions to imply revs to the application protocol anyway; if we= had to, either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. placeholder where the QUIC version is e= mbedded), but I=E2=80=99d prefer that HTTP allows *any* version of QUIC tha= t provides the necessary properties (which is likely to be all future versi= ons, but not necessarily).=C2=A0 Those versions might or might not use TLS as their crypto protocol =E2=80=93 HTTP simply = requires QUIC, and QUIC simply requires that the crypto handshake be able t= o negotiate an application-layer protocol.

=C2=A0

I=E2=80=99m thinking of it this way:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 QUIC specifies that a particular QUIC version u= ses a particular crypto handshake and/or allocates the crypto protocol a fe= w bits of the version field.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The QUIC TLS extension carries:

o=C2=A0=C2=A0 Client->server:=C2=A0 The initially-offered = version

o=C2=A0=C2=A0 Client->server:=C2=A0 The finally-selected v= ersion

o=C2=A0=C2=A0 Server->client:=C2=A0 The set of versions th= e server did / would have sent in a Version Negotiation packet

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The application specifies requirements of the Q= UIC version to be used, but doesn=E2=80=99t bind that version in its ALPN t= oken

=C2=A0

However, this is a more expansive design issue, so I= =E2=80=99d like to make sure it=E2=80=99s visible on-list.


--94eb2c11f30ef283a10544ee2c72-- From nobody Sat Dec 31 08:15:21 2016 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 5A79D129490 for ; Sat, 31 Dec 2016 08:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-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 qrsVE0CSxLk3 for ; Sat, 31 Dec 2016 08:15:15 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0099.outbound.protection.outlook.com [104.47.34.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 BABDE129467 for ; Sat, 31 Dec 2016 08:15:15 -0800 (PST) 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; bh=Jmqn5JhCJANyM960Gl4T0My7K/6igGcJZcGfjjMxZ38=; b=hqU5b8z7yBoluPo4aIfBMkHYXUOV/6siT7a0Q5f0rOvsuSiUlXpeHpn2n1nxpZrdr1jl5Ec7sxL8SCRlr2HQ0Nw+u27eTUXiN4niCpYgccHilQ+d+N+Mi9rS6J2qUSN8V5FS++mrbI+6LJBw8dCxpKuYTQQ6+Vtga+TmyyYpcHQ= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sat, 31 Dec 2016 16:15:12 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0803.021; Sat, 31 Dec 2016 16:15:12 +0000 From: Mike Bishop To: Martin Duke Subject: RE: Version Negotiation, Crypto Protocols, and ALPN Thread-Topic: Version Negotiation, Crypto Protocols, and ALPN Thread-Index: AdJa6Epvcy4nCI3yQ2GlNrRDAGQw6AIREv0AABUea48= Date: Sat, 31 Dec 2016 16:15:11 +0000 Message-ID: References: , In-Reply-To: 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=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:600:8300:3b9a:7c60:f5de:4d98:35eb] x-ms-office365-filtering-correlation-id: d4448aae-9a33-4a42-fffb-08d4319832ca x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:wyUx0BQD+2r0HOAqOnrPY+QIeMY/pb7tmpVZAy6THRWOGTXjUKDIjxaGQn+GwWbihHOYtl2PIGQ/x6ZRYiAXmGbE/oYvR6lLkwkCvkAOaofThB8nZLqReRHqy1AvdE9gj3sYvWZ3RkhJSlQUNiOzoRvGYxYgpsgfHJ+ZKQRMBj+TvbrVMIWHuLki1ZyKdPsbMH5s6iiAkMn+UAWJSYpi9H6kaa9uGGxhMR4/upDEzIj32ZnADVKnOdEPlYUpxuUn8snsKQobmcbSHjYfgW8chs4yNipsCjx3qfuYqlg9kXBUVl54kJXAh/P7l6RLt9M2Pm6m7KOAb/tKN0MZtnbAC67HqmT0TzZD8k9yzixfndAaUhjV7hTJcvDku5O6Mr/GgvM4vkaH+IG9vHKzxEkygMs1+kL07MvT8e2jW6DjPftwbn5Eh2d4VNUCEDC8BEsX6VVH5uot+Go/PzUnS6Vny0e+wYoATReIuYKIVguRvrQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(377454003)(24454002)(199003)(189002)(106356001)(3900700001)(122556002)(10090500001)(50986999)(54356999)(3660700001)(229853002)(77096006)(105586002)(2906002)(74316002)(6116002)(38730400001)(7906003)(92566002)(7736002)(99286003)(7696004)(39060400001)(101416001)(102836003)(110136003)(606005)(25786008)(6916009)(6506006)(76176999)(6436002)(2950100002)(4326007)(68736007)(3280700002)(5660300001)(81166006)(86362001)(8936002)(81156014)(8676002)(8990500004)(10290500002)(9686002)(86612001)(97736004)(2900100001)(189998001)(55016002)(5005710100001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708FEBA07FA1F309A5290C5876D0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2016 16:15:11.9934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Dec 2016 16:15:18 -0000 --_000_BN6PR03MB2708FEBA07FA1F309A5290C5876D0BN6PR03MB2708namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, the spec already requires that TLS echo it, because when QUIC sends it = it=92s not protected and could be tampered with. My primary addition there= is that the server=92s list be sent by TLS even if not by QUIC, so the cli= ent can cache it. Sent from my Windows 10 phone From: Martin Duke Sent: Friday, December 30, 2016 10:10 PM To: Mike Bishop Cc: IETF QUIC WG Subject: Re: Version Negotiation, Crypto Protocols, and ALPN I agree that binding QUIC versions to the ALPN seems unnecessary. If by the second point you mean that TLS would handle QUIC version negotiat= ion, I'm not sure how that work. In principle new QUIC versions might chang= e the headers, so I'm not sure how we'd get to the TLS message in the gener= al case. Or perhaps I misunderstood what you wrote. On Tue, Dec 20, 2016 at 10:05 AM, Mike Bishop > wrote: We=92ve got a couple GitHub issues around version negotiation and how all t= he pieces play together. I=92d like to keep the layers as modular as possi= ble, so I=92m trying to flex the joins a little bit conceptually. =95 draft-ietf-quic-transport says: If not explicitly specified in the application mapping, TLS is assumed to b= e the default crypto handshake protocol, as described in [QUIC-TLS]. An app= lication that maps to QUIC MAY however specify an alternative crypto handsh= ake protocol to be used. =95 draft-ietf-quic-tls says: The ALPN identifier for the protocol MUST be specific to the QUIC version t= hat it operates over. =95 draft-ietf-quic-http (in PR#90) would say: HTTP/QUIC support is indicated by selecting the ALPN token =93hq=94 in the = crypto handshake. =95 Ian=92s comment in Issue #45: I would suggest [the crypto protocol] be baked into the QUIC version. There=92s also some related discussion in Issue #87 / Issue #89 which diverged from it. So the application mapping is supposed to specify the QUIC versions and, im= plicitly or explicitly, the crypto protocol that's acceptable. Except the = crypto protocol is already known by the time the ALPN tokens are being inte= rpreted, because you have to parse the QUIC frame and the crypto protocol t= o find the ALPN tokens. Besides which, I'm inclined *not* to require new Q= UIC versions to imply revs to the application protocol anyway; if we had to= , either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. plac= eholder where the QUIC version is embedded), but I=92d prefer that HTTP all= ows *any* version of QUIC that provides the necessary properties (which is = likely to be all future versions, but not necessarily). Those versions mig= ht or might not use TLS as their crypto protocol =96 HTTP simply requires Q= UIC, and QUIC simply requires that the crypto handshake be able to negotiat= e an application-layer protocol. I=92m thinking of it this way: =95 QUIC specifies that a particular QUIC version uses a particular = crypto handshake and/or allocates the crypto protocol a few bits of the ver= sion field. =95 The QUIC TLS extension carries: o Client->server: The initially-offered version o Client->server: The finally-selected version o Server->client: The set of versions the server did / would have sent i= n a Version Negotiation packet =95 The application specifies requirements of the QUIC version to be= used, but doesn=92t bind that version in its ALPN token However, this is a more expansive design issue, so I=92d like to make sure = it=92s visible on-list. --_000_BN6PR03MB2708FEBA07FA1F309A5290C5876D0BN6PR03MB2708namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

No, the spec already requires that TLS echo it, beca= use when QUIC sends it it=92s not protected and could be tampered with.&nbs= p; My primary addition there is that the server=92s list be sent by TLS eve= n if not by QUIC, so the client can cache it.

 

Sent from my Windows 10 phone

 

From: Martin Duke
Sent: Friday, December 30, 2016 10:10 PM
To: Mike Bishop<= br> Cc: IETF QUIC WG
Subject: Re: Version Negotiation, Crypto Protocols, and ALPN

 

I agree that binding QUIC versions to the ALPN seems unnecessary.

If by the second point you mean that TLS would handle QUIC version neg= otiation, I'm not sure how that work. In principle new QUIC versions might = change the headers, so I'm not sure how we'd get to the TLS message in the = general case.

Or perhaps I misunderstood what you wrote.

On Tue, Dec 20, 2016 at 10:05 AM, Mike Bishop <Micha= el.Bishop@microsoft.com> wrote:

We=92ve got a couple GitHub issues around version ne= gotiation and how all the pieces play together.  I=92d like to keep th= e layers as modular as possible, so I=92m trying to flex the joins a little= bit conceptually.

 

=B7        draft-= ietf-quic-transport says:

If not explicitly sp= ecified in the application mapping, TLS is assumed to be the default crypto= handshake protocol, as described in [QUIC-TLS]. An application that maps to QUIC MAY however specify an alternative crypto= handshake protocol to be used.

=B7        draft-ietf-qui= c-tls says:

The ALPN identifier = for the protocol MUST be specific to the QUIC version that it operates over= .

=B7        dr= aft-ietf-quic-http (in PR#90) would say:

HTTP/QUIC support is= indicated by selecting the ALPN token =93hq=94 in the crypto handshake.=

=B7        Ian=92s comment in Issue #45:

I would suggest [the crypto protocol] b= e baked into the QUIC version.

=  

There=92s also some related discussion in Issue #87 / Issue #89 which diverged from it.

=  

So the application mapping is supposed to specify th= e QUIC versions and, implicitly or explicitly, the crypto protocol that's a= cceptable.  Except the crypto protocol is already known by the time th= e ALPN tokens are being interpreted, because you have to parse the QUIC frame and the crypto protocol to find= the ALPN tokens.  Besides which, I'm inclined *not* to require ne= w QUIC versions to imply revs to the application protocol anyway; if we had= to, either HTTP would define that the ALPN token is e.g. `hq-QQQQ` (i.e. placeholder where the QUIC version is e= mbedded), but I=92d prefer that HTTP allows *any* version of QUIC that prov= ides the necessary properties (which is likely to be all future versions, b= ut not necessarily).  Those versions might or might not use TLS as their crypto protocol =96 HTTP simply requir= es QUIC, and QUIC simply requires that the crypto handshake be able to nego= tiate an application-layer protocol.

 

I=92m thinking of it this way:

=B7        QUIC specifies that a particular QUIC version u= ses a particular crypto handshake and/or allocates the crypto protocol a fe= w bits of the version field.

=B7        The QUIC TLS extension carries:

o   Client->server:  The initially-offered = version

o   Client->server:  The finally-selected v= ersion

o   Server->client:  The set of versions th= e server did / would have sent in a Version Negotiation packet

=B7        The application specifies requirements of the Q= UIC version to be used, but doesn=92t bind that version in its ALPN token

 

However, this is a more expansive design issue, so I= =92d like to make sure it=92s visible on-list.


--_000_BN6PR03MB2708FEBA07FA1F309A5290C5876D0BN6PR03MB2708namp_--