From nobody Sat Jun 1 17:45:21 2019 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 C11D3120090 for ; Sat, 1 Jun 2019 17:45:19 -0700 (PDT) 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 (2048-bit key) header.d=mnot.net header.b=QYbmQpS6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JxoPPOBq 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 p5Le35aIY8ru for ; Sat, 1 Jun 2019 17:45:15 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1870120025 for ; Sat, 1 Jun 2019 17:45:15 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9BACC20CCC for ; Sat, 1 Jun 2019 20:45:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 01 Jun 2019 20:45:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=TD+EMuHBtpyG1qytRu60/5W6jJ+2qrzHhjM7pghfoG8=; b=QYbmQpS6 evj+55JlbsB4OMLT6euFzZhWcEXAhMYYG+sYWJ6F08rvG6Tbq0sxSAzizqPKlr1m l0uQC5PvsF9rU62Lyla0KEClKx4V85hLWQjyDtKP5UOHF4Lpd2iHZ/Y0i1Xpv24/ tZt/Tbz5Ts8LLqlO5VVhTbTO2dKP1RbHY400dNg2s4EaqFlDDDDqDoetN+f4DeHl +dwLDM7lFOSW1Lsh1QTylaHtNPpdaAcrKVVFErrL8YVWY2JnyossBR/uhrK9lFrW quxa6QfLLlkolc4i8Wf3j6RxSEeU/h/bclJqmmX7fS9UrBXd1V3VC+XJPbjuarh4 xAh/gjc3xbHxEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=TD+EMuHBtpyG1qytRu60/5W6jJ+2q rzHhjM7pghfoG8=; b=JxoPPOBqbtgNjA4WSG6oxZfoB7u/xAbch7eEgCpcKgXNQ Vl+jSqg1tpqn50A8MOXv+eAJ1b2xEKgnR4met49+oaHA9k/jnQ98mcWVilETjWHG rIyQhB2gnY9TseaR+uMV9RQygWo7AQDRVh3VFsEl4hUCbykjf0NQQUwQz6POwUQ5 MUoFb3ckDGubd87HKrdSwY7LciiOMk9oqaPlRsAYmwcwxvVWTvsPr5PjoDELUDbA SRE76xv80n6aBGcAC6xdq9fkvnawP7eP8XHzfJlKzFfJjUckPHEQp5mG9qVE9zkv AfQDGUby++em2n26jXavQXgxAgY+T983p6grjCXSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefgedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 34828380083 for ; Sat, 1 Jun 2019 20:45:13 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 15D18C4E33 for ; Sun, 2 Jun 2019 00:45:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7571052429869393018==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190602004510.15D18C4E33@cloud.mnot.net> Date: Sun, 2 Jun 2019 00:45:10 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 02 Jun 2019 00:45:20 -0000 --===============7571052429869393018== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+1/-1/=F0=9F=92=AC19) 1 issues created: - NEW_TOKEN should be symmetric (by marten-seemann) https://github.com/quicwg/base-drafts/issues/2760 = 7 issues received 19 new comments: - #2760 NEW_TOKEN should be symmetric (9 by kazuho, marten-seemann, janai= yengar, mikkelfj, ekr, dtikhonov) https://github.com/quicwg/base-drafts/issues/2760 = - #2753 NUM_PLACEHOLDERS MUST NOT be zero (4 by kazuho, ianswett) https://github.com/quicwg/base-drafts/issues/2753 [-http] = - #2734 Placeholder limits make for awkward clients (2 by kazuho, afrind) https://github.com/quicwg/base-drafts/issues/2734 [-http] = - #2581 Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext (1 by= DavidSchinazi) https://github.com/quicwg/base-drafts/issues/2581 [-tls] [design] [prop= osal-ready] = - #2754 Lessen the divergence from the HTTP/2 prioritization scheme by re= quiring all PRIORITY frames to be sent on the control stream (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2754 [-http] = - #2100 Avoid creating QPACK codec streams when unnecessary (1 by ghedo) https://github.com/quicwg/base-drafts/issues/2100 [-qpack] [design] = - #2741 Re-visit initial keys discard (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2741 [-tls] [-transport] [= design] = 1 issues closed: - RTT measurement using PATH_* frames https://github.com/quicwg/base-draf= ts/issues/2644 [-recovery] [design] = Pull requests ------------- * quicwg/base-drafts (+3/-1/=F0=9F=92=AC11) 3 pull requests submitted: - Mandate allowing peer to create enough unidirectional streams for HTTP = and QPACK (by ghedo) https://github.com/quicwg/base-drafts/pull/2762 = - allow PRIORITY frames referring to placeholders exceeding `SETTING_NUM_= PLACEHOLDERS` (by kazuho) https://github.com/quicwg/base-drafts/pull/2761 = - QPACK editorial revision (by afrind) https://github.com/quicwg/base-drafts/pull/2759 = 6 pull requests received 11 new comments: - #2761 allow PRIORITY frames referring to placeholders exceeding `SETTIN= G_NUM_PLACEHOLDERS` (5 by ghedo, LPardue) https://github.com/quicwg/base-drafts/pull/2761 = - #2529 Allow not creating QPACK codec streams (2 by ghedo) https://github.com/quicwg/base-drafts/pull/2529 [-qpack] = - #2690 Orphan Placeholder (1 by kazuho) https://github.com/quicwg/base-drafts/pull/2690 [-http] [design] = - #2729 Don't store or retransmit PATH_RESPONSE frames, avoid buffering (= 1 by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2729 = - #2749 Allow longer CIDs (1 by martinduke) https://github.com/quicwg/base-drafts/pull/2749 = - #2687 New paths may seed initial_rtt (1 by ianswett) https://github.com/quicwg/base-drafts/pull/2687 [-recovery] = 1 pull requests merged: - New paths may seed initial_rtt https://github.com/quicwg/base-drafts/pull/2687 [-recovery] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7571052429869393018== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 02, 2019

Issues

quicwg/base-drafts (+1/-1/=F0=9F=92=AC19)

1 issues created:

7 issues received 19 new comments:

1 issues closed:

Pull requests

quicwg/base-drafts (+3/-1/=F0=9F=92=AC11)

3 pull requests submitted:

6 pull requests received 11 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============7571052429869393018==-- From nobody Mon Jun 3 17:00:28 2019 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 364591201A2 for ; Mon, 3 Jun 2019 17:00:26 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=gEzo6fJW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aHS9Xqnk 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 mFufXUwRlTx3 for ; Mon, 3 Jun 2019 17:00:24 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02181201FA for ; Mon, 3 Jun 2019 17:00:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 129D0220CF; Mon, 3 Jun 2019 20:00:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 03 Jun 2019 20:00:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=o Kxw3Y7JmFgdZGmpXC/Hoz5g+Q53YhYNHP9M/3YxKjE=; b=gEzo6fJWYo519zQvu XLbrKuWbUfO3m4JuPitPfsf4QvyjzYP5AJ1dJiZeDCHxYSmKdBk01YtwF08nXpCI Hz74n0/KT6j7sZkDU852RYQnfY0bhaDrPppW3dys67LSf/CPnQD4oXegO2AJ3ykw z9VRKrDAfhqb4QMElvYnCUpQGl2AK1Ztm2jPYXzc9aKaUeKfseBe2H/1TYQd0YL3 R1sANlX3nnjc29cAFSX6QiG8EwS/xbdU/17Df94AtlnT6LAdfx2yc20bB5dXHkma iYG+JkXESg3IW5au1liXqbF2zhPNZGz2/OZIDhI+XFRNb/wi8E3CHiFT4NI+1aGQ Oac0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=oKxw3Y7JmFgdZGmpXC/Hoz5g+Q53YhYNHP9M/3YxK jE=; b=aHS9XqnkYKzIfpN3r85oUyt4GGJ4vwxRsupYD3t6bSrIsyza3duMUKNGe AdFN+cnw/NknmUj+gVen1qiVhbrJWpbyEOzubJ9Jq8KVqHnj79bfBKqgS0no2oHn y0QGN6jNEpcQEEqZ57bWe96RiQFOX2dgm3foaqLp/UkH2Ls2h1vcq8engkLLG29J /Nr//LgUZdxeF6/ZLz+hi/uGCQ/8KwRTMtYMaqGZRlVmaoBJpIkM2MwW+k3ySjWG l6n9S6LuXTIhD93Z4BVCMy8TC0gjmWWKbnNXTqCUnSYlE99LCCyw2sJIlu8qCh1y IF/9xwB3Vl7tLGpDyeP/+/JT7fSjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefkedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id CCD41380088; Mon, 3 Jun 2019 20:00:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Calls on Recent Transport/TLS Issues From: Mark Nottingham In-Reply-To: Date: Tue, 4 Jun 2019 10:00:15 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 04 Jun 2019 00:00:26 -0000 Hearing no pushback, consensus declared. Cheers, > On 28 May 2019, at 3:33 pm, Mark Nottingham wrote: >=20 > The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). >=20 > * #2732 - Reusing SRTs ( PR#2733) > * #2580 - Is path validation a SHOULD or a MUST? (PR#2637) > * #2689 - Checking duplicate TPs is onerous (PR#2691) > * #2192 - Optimistic ACK in early handshake (close with no action) > * #2471 - Stateless Reset lacks Normative Text (PR#2574) > * #2581 - Bring back AEAD_AES_128_CCM_8 (PR#2743) > * #2552 - Saving a round-trip time in the initial handshakes with = retry (close with no action; mark issue as quicv2) > * #2394 - Spoofed retry token attack on IP authentication (close with = no action) > * #2308 - Handling of coalesced packets with decryption errors creates = DoS opportunity (PR#2747) > * #2267 - Loss of only two packets can lead to an unrecoverable = situation (PR#2673) > * #2441 - Peers that only terminate a single connection on an IP/port = cannot migrate with 0-byte CIDs (close with no action; mark issue as = quicv2) > * #2214 - Simultaneous key update can lead to deadlock (PR#2673) > * #2458 - Client MUST use 1-RTT packets if it reads 1-RTT packets = (PR#2461) > * #2672 - Transport error codes would be smaller and more consistent = as a varint (PR#2680) > * #2582 - Attacks Against Address Migration (PR#2637) > * #2579 - Path validation should be done even for what looks like NAT = rebinding (PR#2637) > * #2360 - 0-RTT flow control limits can't be increased (PR#2461) >=20 > Absent any pushback, we'll declare consensus at the end of the week. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jun 5 05:03:46 2019 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 F1CA71200B7 for ; Wed, 5 Jun 2019 05:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkUJ_shwN0uW for ; Wed, 5 Jun 2019 05:03:43 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 18D6F120020 for ; Wed, 5 Jun 2019 05:03:43 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id l26so18852299lfh.13 for ; Wed, 05 Jun 2019 05:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ttlZTGy8mNn2nkmIeja+cSogvVMkl387iKJ49bhXk40=; b=fTLav+8HzEK8kHEpjI/15PDa5uJn+OtJB3Rux/wPovB9934Bt0HsyxyfwTrAt/mpgZ gxAxYlMG4bo8wBiX3nflMsdbBzLdD7nzcJ2oNk3ajQt0a2VMr4LjmfsioWIq0hnD7aI3 ydU7rd9DIX+O1L8I4jFIg/wTGSzd/JWjuEVGjsCZDSYsLyAl93IuIuko7ZweSM63fggk UpVfk9MYcPotxdLB0tQzGvh2wtQcFC0xa1cAvQkPLMAwn+LdrXvNAUYeji1cDH9pl6Db liYfmthVNiaaCL0vKyIywTc2BCIiVVN6NhiY+wvVmNncN9iSE2JL/67DFpe7LjJyrcqE bvXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ttlZTGy8mNn2nkmIeja+cSogvVMkl387iKJ49bhXk40=; b=BXD8YX10xOiJXqits8Zw+YUMGd1vxUCo307GryiPsONQRGs2Q95nhKfF4cHvSPBfsv YZmVsDEdKUxwcZxphWE96060K8gr6lQwVsXudIcYUMdQIIEoWORJsG7MD2bdW/4Ysnpz Mbhc+0NVbTgTVertRIGzHw95mZXrMO15RxMKRbYdqS/qJiOZyt70B3/GXFb4yQS/eIWQ 9WiyjJl84w8ClonjX4EjAiTE7+GUr/x1qhrB8hHO9PhnPHolOyapK2sqsVkpD0J/NdhV eZendZIsA7SdndiNI4AICa4hQo5JxAWzqj9oRIFYMpEDG2UAvZrAasT0ENgTY4hVgy3O v5IA== X-Gm-Message-State: APjAAAU2tIHIfpIwNjVha6izsZmcKoFBm5zWSjYyFdr7rKClboaLdXBP KZXeioGTVJzaE5d1ueCwNLHmMkdkmZI4RwWaOY2fKefH X-Google-Smtp-Source: APXvYqxJeWz2C41VRNMyu/v5LRJ0OfTW4Jr4K7FjcxedW7+2P1McItk/AtXi9GmNP3EexEeIEy1sPGGGOfhauIX3yvk= X-Received: by 2002:ac2:424b:: with SMTP id m11mr19381990lfl.163.1559736221263; Wed, 05 Jun 2019 05:03:41 -0700 (PDT) MIME-Version: 1.0 From: Jiuhai Zhang Date: Wed, 5 Jun 2019 20:03:30 +0800 Message-ID: Subject: =?UTF-8?Q?Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000696f21058a9263d8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 12:03:45 -0000 --000000000000696f21058a9263d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 Ack-eliciting Frames: All frames besides ACK or PADDING are considered ack-eliciting. Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE fram= e=EF=BC=9F --000000000000696f21058a9263d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Ack-eliciting Frames:=
  All frames besides ACK or PADDING are
      considered ack-eliciting.
Is CONNECT=
ION_CLOSE frame Ack-eliciting=EF=BC=9F
Should endpoint responds a ACK frame when receiving a =
CONNECTION_CLOSE frame=EF=BC=9F
--000000000000696f21058a9263d8-- From nobody Wed Jun 5 06:48:46 2019 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 4D77B12006E for ; Wed, 5 Jun 2019 06:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.508 X-Spam-Level: X-Spam-Status: No, score=-17.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj5SICBeJw4r for ; Wed, 5 Jun 2019 06:48:43 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 282A1120046 for ; Wed, 5 Jun 2019 06:48:43 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id n4so14295737wrw.13 for ; Wed, 05 Jun 2019 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eyggxK8KlyDBa+E86i/kXokt23SStoBkSgfb3HHEipw=; b=XvKd6uhmEROr8jnvf6NuM4oaF2TCp6gExvbpOGqIfoKivX6nad3hBehbp7I6+qJ6ev /Z1qwwhOUeSGPqbvbcBI3zCFTF4Gr34AfqHaUOOYUmGP1N5AEBGgeMCfbf17adqCzQJv i/vSm9uco2IIE64gvJFspkL14gMM7F0gt96+gZlIMH7XQFctpP+Vb4EGaWEgDkgxyyAs v2D/3GCKgtlY47VlYprUcb7UEFDWyFe7735S5GDhOLa8JnFjXO2Db+8ig+hkZTByRdTa +KmoRVOB6ozFXgNgL3/hXirq43jJLNNDOmOgg+K1PSEsxpbH5QP9WLfHwa0lY3aDxqAn lPKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eyggxK8KlyDBa+E86i/kXokt23SStoBkSgfb3HHEipw=; b=CP7dBDf1J8Ywl1Bn8eIZF5L0I8rs4rm2//K/6McR7vw1UU+YyJe7TsPHcWupIa8GZL fOpzL3JZ3+2DVRwmrL60P1bjmSKvS0LFUjfaMHW6tNo8B2criahEIl6WlnsHtV+/+hSr DJJL3NoOrEYgV8pIFIiURRrQR5e2AqRUk9bqfotneIWTF1sI6isQbuIbjAwfbZ88fSmt NzwBQIrOpqWbXS7QZTtKYCyLrtkMVqlkDQ31t8JVLEREubfs7De28jqUcuXpxmNoulSb t3l+H7HhcGdQZDKuN2iQJnl3ZBjW9ZdxTQ0q1EumusZimUhy9qNF/FlYCOFjULQp2kcW z4+A== X-Gm-Message-State: APjAAAXaSFsG3w10PuFr77cTByqJg9uRf6vWQVeqtLSQ6PsP8BS/bp5d /7sx2D8aFrdrFAWyUZlFsj6CLI0sV8Wlus1Q3g+Tpg== X-Google-Smtp-Source: APXvYqzX/AjKEua3IeXrA6baK1MEGLVlrkgeY3ysnHEUqPXD8OJEjPNBQmOlyh8yAL2rhMT4QDnEP/qa+N3wKs6BHzA= X-Received: by 2002:a5d:4f8b:: with SMTP id d11mr9222293wru.264.1559742521279; Wed, 05 Jun 2019 06:48:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 5 Jun 2019 09:48:28 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: Jiuhai Zhang Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ec66ba058a93dab2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 13:48:45 -0000 --000000000000ec66ba058a93dab2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Technically, yes. But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it. From: https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-10.1 "The draining state is entered once an endpoint receives a signal that its peer is closing or draining. While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets. Retaining packet protection keys is unnecessary once a connection is in the draining state." On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang wrote: > In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 > > Ack-eliciting Frames: All frames besides ACK or PADDING are > considered ack-eliciting. > > > Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F > > Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE fr= ame=EF=BC=9F > > --000000000000ec66ba058a93dab2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Technically, yes.=C2=A0 But connections don't send any= packets after processing a CONNECTION_CLOSE frame, so you would never rece= ive and ACK for it.

"The= draining state is entered once an endpoint receives a signal that
=C2= =A0 =C2=A0its peer is closing or draining.=C2=A0 While otherwise identical = to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUS= T NOT send any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection k= eys is unnecessary once a
=C2=A0 =C2=A0connection is in the draining sta= te."

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhang@gmail.com> wrote:
Ack-eliciting Frames:  All frames besides ACK or PA=
DDING are
      considered ack-eliciting.

Is CONNECTION_CLOSE frame Ack-e=
liciting=EF=BC=9F
Should endpoint responds a ACK frame when receiv=
ing a CONNECTION_CLOSE frame=EF=BC=9F
--000000000000ec66ba058a93dab2-- From nobody Wed Jun 5 06:59:59 2019 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 75683120098 for ; Wed, 5 Jun 2019 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEvX-dHpLZxJ for ; Wed, 5 Jun 2019 06:59:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770095.outbound.protection.outlook.com [40.107.77.95]) (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 B3F33120048 for ; Wed, 5 Jun 2019 06:59:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=fy1pBAnAZ1bh1/kgAhjApMTlBb8i9QoUY5pjTRy+pYVQnb3OmuDflcyM6wmr5bdBeUKHWQvrrsCHZnReW++jsUd7BjAWxon9w0ZIxpKDx2mEHSB4mHb/gkGhEdkyBZhluTsp46BkAGkgHSbdxgqYMt4IulESvajIaE4j7suEptw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kf91w/fdoH8YuXhYlkVRiyEdRihEYoJsh/H2w/Ky/Wc=; b=xlDDtFOKpLkMZhQscqTiA0BHo5PvTetCyFRRxtztKdAeuGQDFlDU3Rjb6p53VKccHpARc+f7E2/PaAdtM1teXhimCKo+NcRQzpouMpnx/5aKqwr0hFKHGST2vuyccgFlZGXGVo3zsueNW58052qAD9wOncIq9m5UkNQDngMjsQQ= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kf91w/fdoH8YuXhYlkVRiyEdRihEYoJsh/H2w/Ky/Wc=; b=U0wsVBrqMH+8DstJQ3GeQjgy6aRcgSegj3dm202GCh/ZkjxEos0LI4M/MyaTzUIy0YdkNRRTDk0e9Ew1J8rnP0hkXwa9xyjtH5xjpEKIEaiOJ9eXwmDpnrq3BPOno0BROu8H8i9Ah5JofyTyDKqDnI0WDUrH4i1w189SL0A9Ki0= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (2603:10b6:207:37::13) by BL0PR2101MB0930.namprd21.prod.outlook.com (2603:10b6:207:30::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.3; Wed, 5 Jun 2019 13:59:48 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::30e9:8bfc:9b18:9fa1]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::30e9:8bfc:9b18:9fa1%3]) with mapi id 15.20.1987.004; Wed, 5 Jun 2019 13:59:48 +0000 From: Nick Banks To: Ian Swett , Jiuhai Zhang CC: IETF QUIC WG Subject: =?utf-8?B?UkU6IElzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUgQWNrLWVsaWNpdGluZw==?= =?utf-8?B?77yf?= Thread-Topic: =?utf-8?B?SXMgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBBY2stZWxpY2l0aW5n77yf?= Thread-Index: AQHVG5bFgUQ+cxLqqU2bDm3dQiViRqaNE4cAgAAAi0A= Date: Wed, 5 Jun 2019 13:59:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-06-05T13:59:43.8384494Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ba8b261d-4193-4f0c-8b40-9953bede4a5a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-originating-ip: [2001:4898:80e8:0:513f:7528:875a:162c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47b8c57c-e8b3-410b-04e0-08d6e9be12d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB0930; x-ms-traffictypediagnostic: BL0PR2101MB0930: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(376002)(396003)(136003)(199004)(189003)(110136005)(8990500004)(71200400001)(6506007)(6436002)(53546011)(68736007)(236005)(66476007)(478600001)(66556008)(52396003)(7696005)(76176011)(790700001)(256004)(14444005)(6116002)(6306002)(99286004)(52536014)(5660300002)(54896002)(9686003)(55016002)(10090500001)(606006)(33656002)(76116006)(46003)(446003)(6246003)(11346002)(71190400001)(2906002)(4326008)(66446008)(64756008)(14454004)(66946007)(186003)(73956011)(10290500003)(966005)(81156014)(81166006)(102836004)(22452003)(486006)(229853002)(74316002)(53936002)(86362001)(7736002)(316002)(25786009)(8936002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB0930; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: j+ZOJryBP/EH4qGjPDq4Q4OsIlpYAggj1q+YVPuIqrUmgYJZfMnKcC23jvPK4RkMeR0HtlZwg8q1JFlxXPEpV/fIp8IssLxGUEtXmvGk42ye4hphOY03FtWk1txe7minily38Vxzd1mozXoXvQ/nlflFZz8yJTWST/yPuaIw7jVib3x8EjWB7RSPmC+my6tqsdn2q79IQqoSXyfBR6naigv/jut37gahUnstS0SqSH/byG0CL+D0FhgInGmTHnVZjkt59NYTiCt0EzDXJRq1hZT3yexk78trEUOzNYyLfDCTDaq+r1ucdGTv0k4RaPs7RKY7Fzy0TzIB5Uiz2quuaeMLtolCQ5ZrajaRoxsUwas8w1iJCo7s71CP3XkjgsFXMQqJltqIoQ9NotTwApN/M2E87r4tNL3dmk3oV3yrn04= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB10437A1A42141B3481712B95B3160BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47b8c57c-e8b3-410b-04e0-08d6e9be12d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 13:59:48.0219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nibanks@microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0930 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 13:59:58 -0000 --_000_BL0PR2101MB10437A1A42141B3481712B95B3160BL0PR2101MB1043_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWFuLA0KDQpJIGhhdmUgZW5jb3VudGVyZWQgaXNzdWVzIGJvdGggaW4gbG9jYWwgYXV0b21hdGVk IHRlc3RzIGFuZCBkdXJpbmcgaW50ZXJvcCwgd2hlcmUgb25lIHNpZGUgZ2V0cyBldmVyeXRoaW5n IGl0IHdhbnRzIGFuZCB0aGVuIGNsZWFubHkgY2xvc2VzIHRoZSBjb25uZWN0aW9uLiBUaGUgaXNz dWVzIGFyaXNlIGJlY2F1c2UgdGhlIHBlZXIgaGFzbuKAmXQgcmVjZWl2ZWQgdGhlIEFDSyBmb3Ig dGhhdCBsYXN0IGV4Y2hhbmdlLiBGb3IgdGhhdCByZWFzb24sIHdpbnF1aWMgYWx3YXlzIGVuY29k ZXMgaXRzIGxhdGVzdCBBQ0sgc3RhdGUgd2l0aCAoYWx3YXlzIGZyYW1lcyBiZWZvcmUpIHRoZSBD T05ORUNUSU9OX0NMT1NFIGZyYW1lLiBUaGlzIGRvZXNu4oCZdCBpbmNyZWFzZSB0aGUgc2l6ZSBv ZiB0aGUgcGFja2V0IG11Y2gsIGFuZCBpdOKAmXMgdXAgdG8gdGhlIHJlY2VpdmVyIGlmIHRoZXkg d2FudCB0byBwcm9jZXNzIHRoZSBBQ0tzIG9yIG5vdDsgYnV0IGl0IGhlbHBzIHRoZXNlIGtpbmQg b2Ygc2NlbmFyaW9zLg0KDQpBIHNpbXBsZSBleGFtcGxlIHRlc3QgY2FzZToNCg0KQ2xpZW50OiBP cGVuIG9uZSBiaWRpcmVjdGlvbmFsIHN0cmVhbSwgc2VuZCBkYXRhIG9uIGl0LCBGSU4gaXQsIGFu ZCB2ZXJpZnkgdGhlIHBlZXIgZG9lcyB0aGUgc2FtZS4gVGhlbiBjbG9zZSB0aGUgY29ubmVjdGlv bi4NClNlcnZlcjogQWNjZXB0IG9uZSBiaWRpcmVjdGlvbmFsIHN0cmVhbSwgcmVjZWl2ZSBhbGwg ZGF0YSBvbiBpdCBhbmQgZWNobyBpdCBiYWNrLiBWZXJpZnkgYWxsIGRhdGEgaXMgc2VudCBzdWNj ZXNzZnVsbHkuDQoNClRoZSDigJxWZXJpZnkgYWxsIGRhdGEgaXMgc2VudCBzdWNjZXNzZnVsbHni gJ0gZmFpbHMgaWYgeW91IGRvbuKAmXQgc2VuZCBBQ0tzIHdpdGggQ09OTkVDVElPTl9DTE9TRS4g U28sIEkgcGVyc29uYWxseSB0aGluayBpdOKAmXMgYSBnb29kIGlkZWEgdG8gcmVjb21tZW5kIGlu Y2x1ZGluZyBBQ0tzLiBJIGtub3cgaXQgZG9lc27igJl0IHByb3ZpZGUgYW55IGd1YXJhbnRlZXMg aW4gdGhlIHByZXNlbmNlIG9mIHBhY2tldCBsb3NzLCBzbyBpZGVhbGx5IHlvdSBkb27igJl0IGRl c2lnbiBhbiBhcHAgcHJvdG9jb2wgb24gdG9wIG9mIHRoaXMsIGJ1dCBpdCBkb2VzIG1ha2UgdGhp bmdzIGEgbGl0dGxlIG5pY2VyLCBJTU8uDQoNClRoYW5rLA0KLSBOaWNrDQoNCkZyb206IFFVSUMg PHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDogV2Vk bmVzZGF5LCBKdW5lIDUsIDIwMTkgNjo0OCBBTQ0KVG86IEppdWhhaSBaaGFuZyA8aml1aGFpLnpo YW5nQGdtYWlsLmNvbT4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogSXMgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBBY2stZWxpY2l0aW5n77yfDQoNClRlY2hu aWNhbGx5LCB5ZXMuICBCdXQgY29ubmVjdGlvbnMgZG9uJ3Qgc2VuZCBhbnkgcGFja2V0cyBhZnRl ciBwcm9jZXNzaW5nIGEgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSwgc28geW91IHdvdWxkIG5ldmVy IHJlY2VpdmUgYW5kIEFDSyBmb3IgaXQuDQoNCkZyb206IGh0dHBzOi8vdG9vbHMuaWV0Zi4ub3Jn L2h0bWwvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMCNzZWN0aW9uLTEwLjE8aHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG dG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMCUyM3Nl Y3Rpb24tMTAuMSZkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2EzZTRi M2JlODgwNjRjMTUzNTA0MDhkNmU5YmM5MTg1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMCU3QzYzNjk1MzM5MzQ1MTM2MzcyNSZzZGF0YT1iaTklMkZEaDNYWnVVZ00l MkIyM3RDNTRjc0FoZEU1UlFFTlJUUXpnajUlMkIlMkJQbE0lM0QmcmVzZXJ2ZWQ9MD4NCiJUaGUg ZHJhaW5pbmcgc3RhdGUgaXMgZW50ZXJlZCBvbmNlIGFuIGVuZHBvaW50IHJlY2VpdmVzIGEgc2ln bmFsIHRoYXQNCiAgIGl0cyBwZWVyIGlzIGNsb3Npbmcgb3IgZHJhaW5pbmcuICBXaGlsZSBvdGhl cndpc2UgaWRlbnRpY2FsIHRvIHRoZQ0KICAgY2xvc2luZyBzdGF0ZSwgYW4gZW5kcG9pbnQgaW4g dGhlIGRyYWluaW5nIHN0YXRlIE1VU1QgTk9UIHNlbmQgYW55DQogICBwYWNrZXRzLiAgUmV0YWlu aW5nIHBhY2tldCBwcm90ZWN0aW9uIGtleXMgaXMgdW5uZWNlc3Nhcnkgb25jZSBhDQogICBjb25u ZWN0aW9uIGlzIGluIHRoZSBkcmFpbmluZyBzdGF0ZS4iDQoNCk9uIFdlZCwgSnVuIDUsIDIwMTkg YXQgODowNCBBTSBKaXVoYWkgWmhhbmcgPGppdWhhaS56aGFuZ0BnbWFpbC5jb208bWFpbHRvOmpp dWhhaS56aGFuZ0BnbWFpbC5jb20+PiB3cm90ZToNCkluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXF1aWMtcmVjb3ZlcnktMjAjc2VjdGlvbi0yPGh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz LmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtcXVpYy1yZWNvdmVyeS0yMCUyM3NlY3Rpb24t MiZkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2EzZTRiM2JlODgwNjRj MTUzNTA0MDhkNmU5YmM5MTg1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjk1MzM5MzQ1MTM2MzcyNSZzZGF0YT00MjByZ1RPNEl1ZDhIYnBGOEt2dkFOakZm UEZQJTJCdHdBbmpWUzdLc3pHYjQlM0QmcmVzZXJ2ZWQ9MD4NCg0KQWNrLWVsaWNpdGluZyBGcmFt ZXM6ICBBbGwgZnJhbWVzIGJlc2lkZXMgQUNLIG9yIFBBRERJTkcgYXJlDQoNCiAgICAgIGNvbnNp ZGVyZWQgYWNrLWVsaWNpdGluZy4NCg0KDQoNCklzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUgQWNr LWVsaWNpdGluZ++8nw0KDQpTaG91bGQgZW5kcG9pbnQgcmVzcG9uZHMgYSBBQ0sgZnJhbWUgd2hl biByZWNlaXZpbmcgYSBDT05ORUNUSU9OX0NMT1NFIGZyYW1l77yfDQo= --_000_BL0PR2101MB10437A1A42141B3481712B95B3160BL0PR2101MB1043_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JYW4sPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgaGF2ZSBlbmNvdW50ZXJlZCBpc3N1ZXMgYm90aCBpbiBsb2NhbCBhdXRvbWF0ZWQgdGVzdHMg YW5kIGR1cmluZyBpbnRlcm9wLCB3aGVyZSBvbmUgc2lkZSBnZXRzIGV2ZXJ5dGhpbmcgaXQgd2Fu dHMgYW5kIHRoZW4gY2xlYW5seSBjbG9zZXMgdGhlIGNvbm5lY3Rpb24uIFRoZSBpc3N1ZXMgYXJp c2UgYmVjYXVzZSB0aGUgcGVlciBoYXNu4oCZdCByZWNlaXZlZCB0aGUgQUNLIGZvciB0aGF0IGxh c3QgZXhjaGFuZ2UuDQogRm9yIHRoYXQgcmVhc29uLCB3aW5xdWljIGFsd2F5cyBlbmNvZGVzIGl0 cyBsYXRlc3QgQUNLIHN0YXRlIHdpdGggKGFsd2F5cyBmcmFtZXMgYmVmb3JlKSB0aGUgQ09OTkVD VElPTl9DTE9TRSBmcmFtZS4gVGhpcyBkb2VzbuKAmXQgaW5jcmVhc2UgdGhlIHNpemUgb2YgdGhl IHBhY2tldCBtdWNoLCBhbmQgaXTigJlzIHVwIHRvIHRoZSByZWNlaXZlciBpZiB0aGV5IHdhbnQg dG8gcHJvY2VzcyB0aGUgQUNLcyBvciBub3Q7IGJ1dCBpdCBoZWxwcyB0aGVzZQ0KIGtpbmQgb2Yg c2NlbmFyaW9zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNpbXBsZSBleGFtcGxlIHRlc3Qg Y2FzZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50OiBPcGVuIG9uZSBiaWRpcmVjdGlv bmFsIHN0cmVhbSwgc2VuZCBkYXRhIG9uIGl0LCBGSU4gaXQsIGFuZCB2ZXJpZnkgdGhlIHBlZXIg ZG9lcyB0aGUgc2FtZS4gVGhlbiBjbG9zZSB0aGUgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlcnZlcjogQWNjZXB0IG9uZSBiaWRpcmVjdGlvbmFsIHN0 cmVhbSwgcmVjZWl2ZSBhbGwgZGF0YSBvbiBpdCBhbmQgZWNobyBpdCBiYWNrLiBWZXJpZnkgYWxs IGRhdGEgaXMgc2VudCBzdWNjZXNzZnVsbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSDi gJxWZXJpZnkgYWxsIGRhdGEgaXMgc2VudCBzdWNjZXNzZnVsbHnigJ0gZmFpbHMgaWYgeW91IGRv buKAmXQgc2VuZCBBQ0tzIHdpdGggQ09OTkVDVElPTl9DTE9TRS4gU28sIEkgcGVyc29uYWxseSB0 aGluayBpdOKAmXMgYSBnb29kIGlkZWEgdG8gcmVjb21tZW5kIGluY2x1ZGluZyBBQ0tzLiBJIGtu b3cgaXQgZG9lc27igJl0IHByb3ZpZGUgYW55IGd1YXJhbnRlZXMgaW4gdGhlIHByZXNlbmNlIG9m IHBhY2tldCBsb3NzLA0KIHNvIGlkZWFsbHkgeW91IGRvbuKAmXQgZGVzaWduIGFuIGFwcCBwcm90 b2NvbCBvbiB0b3Agb2YgdGhpcywgYnV0IGl0IGRvZXMgbWFrZSB0aGluZ3MgYSBsaXR0bGUgbmlj ZXIsIElNTy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmssPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE5pY2sgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpJYW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDUsIDIw MTkgNjo0OCBBTTxicj4NCjxiPlRvOjwvYj4gSml1aGFpIFpoYW5nICZsdDtqaXVoYWkuemhhbmdA Z21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSXMgQ09OTkVDVElPTl9DTE9TRSBmcmFt ZSBBY2stZWxpY2l0aW5nPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+77yfPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVjaG5pY2Fs bHksIHllcy4mbmJzcDsgQnV0IGNvbm5lY3Rpb25zIGRvbid0IHNlbmQgYW55IHBhY2tldHMgYWZ0 ZXIgcHJvY2Vzc2luZyBhIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUsIHNvIHlvdSB3b3VsZCBuZXZl ciByZWNlaXZlIGFuZCBBQ0sgZm9yIGl0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RnJvbTombmJzcDs8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9y ZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTIwJTIzc2VjdGlvbi0xMC4xJmFt cDtkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2EzZTRiM2JlODgwNjRj MTUzNTA0MDhkNmU5YmM5MTg1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjk1MzM5MzQ1MTM2MzcyNSZhbXA7c2RhdGE9Ymk5JTJGRGgzWFp1VWdNJTJCMjN0 QzU0Y3NBaGRFNVJRRU5SVFF6Z2o1JTJCJTJCUGxNJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczov L3Rvb2xzLmlldGYuLm9yZy9odG1sL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMjAjc2VjdGlv bi0xMC4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+JnF1b3Q7VGhlIGRyYWluaW5nIHN0YXRlIGlzIGVudGVyZWQgb25jZSBhbiBlbmRwb2lu dCByZWNlaXZlcyBhIHNpZ25hbCB0aGF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtpdHMgcGVlciBpcyBjbG9zaW5nIG9yIGRyYWluaW5n LiZuYnNwOyBXaGlsZSBvdGhlcndpc2UgaWRlbnRpY2FsIHRvIHRoZTxicj4NCiZuYnNwOyAmbmJz cDtjbG9zaW5nIHN0YXRlLCBhbiBlbmRwb2ludCBpbiB0aGUgZHJhaW5pbmcgc3RhdGUgTVVTVCBO T1Qgc2VuZCBhbnk8YnI+DQombmJzcDsgJm5ic3A7cGFja2V0cy4mbmJzcDsgUmV0YWluaW5nIHBh Y2tldCBwcm90ZWN0aW9uIGtleXMgaXMgdW5uZWNlc3Nhcnkgb25jZSBhPGJyPg0KJm5ic3A7ICZu YnNwO2Nvbm5lY3Rpb24gaXMgaW4gdGhlIGRyYWluaW5nIHN0YXRlLiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4gNSwgMjAxOSBh dCA4OjA0IEFNIEppdWhhaSBaaGFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppdWhhaS56aGFuZ0Bn bWFpbC5jb20iPmppdWhhaS56aGFuZ0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW4mbmJzcDs8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZk cmFmdC1pZXRmLXF1aWMtcmVjb3ZlcnktMjAlMjNzZWN0aW9uLTImYW1wO2RhdGE9MDIlN0MwMSU3 Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDYTNlNGIzYmU4ODA2NGMxNTM1MDQwOGQ2ZTliYzkx ODUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTUzMzkz NDUxMzYzNzI1JmFtcDtzZGF0YT00MjByZ1RPNEl1ZDhIYnBGOEt2dkFOakZmUEZQJTJCdHdBbmpW UzdLc3pHYjQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLXJlY292ZXJ5LTIwI3NlY3Rpb24tMjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpw YWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFjay1lbGljaXRpbmcgRnJhbWVzOiZuYnNw OyBBbGwgZnJhbWVzIGJlc2lkZXMgQUNLIG9yIFBBRERJTkcgYXJlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyZWQgYWNrLWVsaWNpdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWst YmVmb3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SXMgQ09OTkVDVElPTl9DTE9T RSBmcmFtZSBBY2stZWxpY2l0aW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPu+8nzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYnJlYWstYmVm b3JlOnBhZ2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2hvdWxkIGVuZHBvaW50IHJlc3Bv bmRzIGEgQUNLIGZyYW1lIHdoZW4gcmVjZWl2aW5nIGEgQ09OTkVDVElPTl9DTE9TRSBmcmFtZTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9y OmJsYWNrIj7vvJ88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR2101MB10437A1A42141B3481712B95B3160BL0PR2101MB1043_-- From nobody Wed Jun 5 07:07:56 2019 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 4188E1200B6 for ; Wed, 5 Jun 2019 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1GEN9LYNCzM for ; Wed, 5 Jun 2019 07:07:52 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 E7611120048 for ; Wed, 5 Jun 2019 07:07:51 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id h10so5938464edi.13 for ; Wed, 05 Jun 2019 07:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Jgm/NkYFPZzWHgYSf0iVFc/w7p1BDevnrC4krmkSW+M=; b=by1UfJPx6MXRNv8qWJQg0Np6KtXrqRYDvzJAETKdREy4UVCus0bzKXFzmwTeNog6aJ JV8rFJG2Ou96usOaaO1NL1IpUcqACp/29QYJ3vK/7trNK1DbRKBYq3miFqmJLXws5Uy0 UFsOlmLowNpRkoxAg+8qeoSf/GTSgeZkSNxckp0g5jpbjAIH+XW92ie9zZjuKHhmUrY8 LjZQdHytIBS4lIyJr9BgG4OdGwThQtzSV8swkxZWpajbdBbQwiGWrNDhovG1XVbnpBcx yLwngV8J3xE2ZrHxHnVyGRegn6wKM687L9VwDojK5bQuN6/bXpLm8kmY6D+XguK8hwkV 8t8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Jgm/NkYFPZzWHgYSf0iVFc/w7p1BDevnrC4krmkSW+M=; b=PiuJN/d035MEFskCZvZPTzXBEqK7YqMNhG2dQ9YnQ8FLwmqxV+9BZ5cMa9sQnBYekN 0ZrkM2mwmvDZfPFvAWwJDcorFTSjHmHyMzixFpMTtEZzyHvHvDwaFUQLCV5LT5M9xW7s gVKTkIrkRas8jPQi1Z84J4qw8gybz/fuNXS4D7x0viasZozRzYIr0WHVcac/WWIVPZS7 Y24XSL1n7tiaXOKUtX3twJ897h/ppFzQ3msTZpjCy7oue1LqN5Zbd6kM8bA5198zLNhU 9Wi9tUs+P1G14iZLuUX4klX3dnUm/4DFp6Xiu6l11QlZ1/Q9e6LvnJFwGRQD+YkE+xaj 2OzA== X-Gm-Message-State: APjAAAXOeIgvFczYf1U9rLO76WqixLZ1KltnZ3szkrejdJ05vrLTBZWs 36z12gOXX5iVHTdK9IgBEkIZyJ3GFv2mtHp5FAE= X-Google-Smtp-Source: APXvYqxBh1dz4o71sdSCwQ7MyXuefz+quSVaQ095gjlod+/5nhyzMeNAeg0/ljB6WllvscheZrwJL6zbBfRl+/1YYW0= X-Received: by 2002:aa7:d6c8:: with SMTP id x8mr43478387edr.13.1559743670445; Wed, 05 Jun 2019 07:07:50 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 5 Jun 2019 07:07:49 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 5 Jun 2019 07:07:49 -0700 Message-ID: Subject: =?UTF-8?Q?RE=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: Ian Swett , Nick Banks , Jiuhai Zhang Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000006aedd0058a941f16" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 14:07:55 -0000 --0000000000006aedd0058a941f16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can contain other frames. So technically you can ACK a connection close. Doing so might actually make sense if the original closer take that as a signal to drain faster. On 5 June 2019 at 16.00.16, Nick Banks ( nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: Ian, I have encountered issues both in local automated tests and during interop, where one side gets everything it wants and then cleanly closes the connection. The issues arise because the peer hasn=E2=80=99t received the A= CK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always frames before) the CONNECTION_CLOSE frame. This doesn=E2= =80=99t increase the size of the packet much, and it=E2=80=99s up to the receiver i= f they want to process the ACKs or not; but it helps these kind of scenarios. A simple example test case: Client: Open one bidirectional stream, send data on it, FIN it, and verify the peer does the same. Then close the connection. Server: Accept one bidirectional stream, receive all data on it and echo it back. Verify all data is sent successfully. The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you don= =E2=80=99t send ACKs with CONNECTION_CLOSE. So, I personally think it=E2=80=99s a good idea to r= ecommend including ACKs. I know it doesn=E2=80=99t provide any guarantees in the pre= sence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of = this, but it does make things a little nicer, IMO. Thank, - Nick *From:* QUIC *On Behalf Of * Ian Swett *Sent:* Wednesday, June 5, 2019 6:48 AM *To:* Jiuhai Zhang *Cc:* IETF QUIC WG *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F Technically, yes. But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it. From: https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.= 1 "The draining state is entered once an endpoint receives a signal that its peer is closing or draining. While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets. Retaining packet protection keys is unnecessary once a connection is in the draining state." On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang wrote: In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 Ack-eliciting Frames: All frames besides ACK or PADDING are considered ack-eliciting. Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE fram= e=EF=BC=9F --0000000000006aedd0058a941f16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = CONNECTION_CLOSE can= be response to CONNECTION_CLOSE and that response can contain other frames= . So technically you can ACK a connection close.

Doing so might actually make sense if the origi= nal closer take that as a signal to drain faster.


On= 5 June 2019 at 16.00.16, Nick Banks (nibanks=3D40microsoft.com@dmarc.ietf.org) wrote:=

Ian,

=C2=A0

I have encountered issues both in local automated te= sts and during interop, where one side gets everything it wants and then cl= eanly closes the connection. The issues arise because the peer hasn=E2=80= =99t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always = frames before) the CONNECTION_CLOSE frame. This doesn=E2=80=99t increase th= e size of the packet much, and it=E2=80=99s up to the receiver if they want= to process the ACKs or not; but it helps these kind of scenarios.

=C2=A0

A simple example test case:

=C2=A0

Client: Open one bidirectional stream, send data on = it, FIN it, and verify the peer does the same. Then close the connection.

Server: Accept one bidirectional stream, receive all= data on it and echo it back. Verify all data is sent successfully.

=C2=A0

The =E2=80=9CVerify all data is sent successfully=E2= =80=9D fails if you don=E2=80=99t send ACKs with CONNECTION_CLOSE. So, I pe= rsonally think it=E2=80=99s a good idea to recommend including ACKs. I know= it doesn=E2=80=99t provide any guarantees in the presence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of this, but it= does make things a little nicer, IMO.

=C2=A0

Thank,

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuha= i.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org<= /a>>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F

=C2=A0

Technically, yes.=C2=A0 But connections don't se= nd any packets after processing a CONNECTION_CLOSE frame, so you would neve= r receive and ACK for it.

=C2=A0

"The draining state is entered once an endpoint= receives a signal that

=C2=A0 =C2=A0its peer is closing or draining.=C2=A0 = While otherwise identical to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUST NOT send= any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection keys is unnecessary= once a
=C2=A0 =C2=A0connection is in the draining state."

=C2=A0

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhang@gmail.com> wrote:= 

Ack-eliciting =
Frames:=C2=A0 All frames besides ACK or PADDING are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 considered =
ack-eliciting.
=C2=A0<=
/pre>

Is CONNECTION_=
CLOSE frame Ack-eliciting=EF=BC=9F

Should endpoin=
t responds a ACK frame when receiving a CONNECTION_CLOSE frame=EF=BC=9F
--0000000000006aedd0058a941f16-- From nobody Wed Jun 5 08:58:25 2019 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 C71211200EB for ; Wed, 5 Jun 2019 08:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.519 X-Spam-Level: X-Spam-Status: No, score=-15.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1jHdJ5f8rmS for ; Wed, 5 Jun 2019 08:58:20 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 D729A1200B4 for ; Wed, 5 Jun 2019 08:58:19 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id w13so19985318wru.11 for ; Wed, 05 Jun 2019 08:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aV1tWDhCiBRivcXoIlYCuNtrUDpg20jVp7WZY6FG2To=; b=F8TWHiYBEt2/Lwb3bwnYDfPJiel18eFB4l+9vOMTY8B/Oqrzg326qD0bNqnQiQR+A7 fK8PIycHpHWWdwY+VuWhjVbF47L4QxG3f+RSgQgzugGTehcXht5a79jZNSFQZPfF44ey vqZvvr7vxnFwOYgaXNCPY30aJbht4pto5av8OkTj+kBwSVSNd+Hd7ZngYEJEF6JOMQa9 tB/QAbdhd9aJ25zfcLCbxvTt+kNddBp47snGaTkBC4c9pA7d59FoWA+WTy2J6+TsQ5Tx Tfov/PkUaHFP5UUy+GQr6QzSSIqYcTnAiFR2iYu2H1Upig1UXWmsrrCCC0qATQuMmykW rFaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aV1tWDhCiBRivcXoIlYCuNtrUDpg20jVp7WZY6FG2To=; b=IQDoAXwn5bVSX0Z0EibiVkUC19bRAUBKnJYL4q4GjWX2vhabVRXh6QEmMmyZdam7Y6 p2OVueHIZa7coD+7z66i4nRcEU25t04jj1KnQ3yzcZ8UEvgA8vmN7vo12k/3zSUspizm Q62Nw/wu/UmeV6ltY9EpzJIYtPlaZ4vJZCPfhtBPE3RVGguVdFfGX//i29XNgjilQnG8 CB+DktWfjCrD4X+Nf/o//1AXrm04ZGeD/aQC8TY71szn236rBLcskp8MT7krWEgUSv0f ECNRBLgV0yWWFoqG3vm+6O1zeD4lVjNd0bu+MnBp4gVcXwKL68xt0J1DzGH8UI2ZEvYA 3IVQ== X-Gm-Message-State: APjAAAWSsrIKOY8KhtCDBQftBE6Eo7TKVi4hmxzMrJ2iSEjqvW0L6r+z pcVFTvTeARJWCuRM14zG3CeczbdSynCyIeY1AXxsWA== X-Google-Smtp-Source: APXvYqwOc+8/X82hz+mlENI2E2rdOsZPgrEus2WFM/LZuMUQUP3SSaHqpFsutCHEVZ9VZGyjpySZz2SUAhcpOm6GFyo= X-Received: by 2002:a5d:4f8b:: with SMTP id d11mr9641995wru.264.1559750297929; Wed, 05 Jun 2019 08:58:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 5 Jun 2019 11:58:06 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Nick Banks , Jiuhai Zhang , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000072be3f058a95aa46" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 15:58:24 -0000 --00000000000072be3f058a95aa46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well. However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE? Or am I misreading the text about draining? On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response ca= n > contain other frames.. So technically you can ACK a connection close. > > Doing so might actually make sense if the original closer take that as a > signal to drain faster. > > > On 5 June 2019 at 16.00.16, Nick Banks ( > nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: > > Ian, > > > > I have encountered issues both in local automated tests and during > interop, where one side gets everything it wants and then cleanly closes > the connection. The issues arise because the peer hasn=E2=80=99t received= the ACK > for that last exchange. For that reason, winquic always encodes its lates= t > ACK state with (always frames before) the CONNECTION_CLOSE frame. This > doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s up= to the receiver > if they want to process the ACKs or not; but it helps these kind of > scenarios. > > > > A simple example test case: > > > > Client: Open one bidirectional stream, send data on it, FIN it, and verif= y > the peer does the same. Then close the connection. > > Server: Accept one bidirectional stream, receive all data on it and echo > it back. Verify all data is sent successfully. > > > > The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you d= on=E2=80=99t send ACKs > with CONNECTION_CLOSE. So, I personally think it=E2=80=99s a good idea to= recommend > including ACKs. I know it doesn=E2=80=99t provide any guarantees in the p= resence of > packet loss, so ideally you don=E2=80=99t design an app protocol on top o= f this, > but it does make things a little nicer, IMO. > > > > Thank, > > - Nick > > > > *From:* QUIC *On Behalf Of * Ian Swett > *Sent:* Wednesday, June 5, 2019 6:48 AM > *To:* Jiuhai Zhang > *Cc:* IETF QUIC WG > *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F > > > > Technically, yes. But connections don't send any packets after processin= g > a CONNECTION_CLOSE frame, so you would never receive and ACK for it. > > > > From: > https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1 > > > "The draining state is entered once an endpoint receives a signal that > > its peer is closing or draining. While otherwise identical to the > closing state, an endpoint in the draining state MUST NOT send any > packets. Retaining packet protection keys is unnecessary once a > connection is in the draining state." > > > > On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang > wrote: > > In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 > > > Ack-eliciting Frames: All frames besides ACK or PADDING are > > considered ack-eliciting. > > > > Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F > > Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE fr= ame=EF=BC=9F > > --00000000000072be3f058a95aa46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nick, I agree that bundling an ACK with a CONNECTION_CLOSE= is useful, and our implementation does that as well.

Ho= wever, it seems like the existing text indicates you'd never expect to = get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?=C2=A0 Or am I mis= reading the text about draining?

=
On Wed, Jun 5, 2019 at 10:08 AM Mikke= l Fahn=C3=B8e J=C3=B8rgensen <mikk= elfj@gmail.com> wrote:
CONNECTION_CLOSE can be response= to CONNECTION_CLOSE and that response can contain other frames.. So techni= cally you can ACK a connection close.

Doing so might actually make sense if the origin= al closer take that as a signal to drain faster.


On 5 June 2019 at 16.00.16, Nick Banks (nibanks=3D40microsoft.com@dma= rc.ietf.org) wrote:

Ian,

=C2=A0

I have encountered issues both in local automated te= sts and during interop, where one side gets everything it wants and then cl= eanly closes the connection. The issues arise because the peer hasn=E2=80= =99t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always = frames before) the CONNECTION_CLOSE frame. This doesn=E2=80=99t increase th= e size of the packet much, and it=E2=80=99s up to the receiver if they want= to process the ACKs or not; but it helps these kind of scenarios.

=C2=A0

A simple example test case:

=C2=A0

Client: Open one bidirectional stream, send data on = it, FIN it, and verify the peer does the same. Then close the connection.

Server: Accept one bidirectional stream, receive all= data on it and echo it back. Verify all data is sent successfully.

=C2=A0

The =E2=80=9CVerify all data is sent successfully=E2= =80=9D fails if you don=E2=80=99t send ACKs with CONNECTION_CLOSE. So, I pe= rsonally think it=E2=80=99s a good idea to recommend including ACKs. I know= it doesn=E2=80=99t provide any guarantees in the presence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of this, but it= does make things a little nicer, IMO.

=C2=A0

Thank,

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F

=C2=A0

Technically, yes.=C2=A0 But connections don't se= nd any packets after processing a CONNECTION_CLOSE frame, so you would neve= r receive and ACK for it.

=C2=A0

"The draining state is entered once an endpoint= receives a signal that

=C2=A0 =C2=A0its peer is closing or draining.=C2=A0 = While otherwise identical to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUST NOT send= any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection keys is unnecessary= once a
=C2=A0 =C2=A0connection is in the draining state."

=C2=A0

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhang@gmail.= com> wrote:

Ack-eliciting =
Frames:=C2=A0 All frames besides ACK or PADDING are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 considered =
ack-eliciting.
=C2=A0<=
/pre>

Is CONNECTION_=
CLOSE frame Ack-eliciting=EF=BC=9F

Should endpoin=
t responds a ACK frame when receiving a CONNECTION_CLOSE frame=EF=BC=9F
--00000000000072be3f058a95aa46-- From nobody Wed Jun 5 09:03:18 2019 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 074321200B4 for ; Wed, 5 Jun 2019 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.007 X-Spam-Level: X-Spam-Status: No, score=-0.007 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4CoLuW2oiBf for ; Wed, 5 Jun 2019 09:03:14 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 CD6961200C1 for ; Wed, 5 Jun 2019 09:03:13 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id a8so6552527edx.3 for ; Wed, 05 Jun 2019 09:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=KKKRGK7UPB9Xt0Opnf9sS/9h48Rxxe8Xvqfw65iKh+g=; b=gIbamSEQRJtJPHh3pZ97r1fZ2fL983N5q+CLrxZsfGnx/iz8B7brZ4LTq50ZpW/bCq y65BkwClBh2jcjx5mjT6WeBWO0q2nhE8/SPafiAWe8EEWGtfu0ylkIZk1g9bi/WOGiM6 Lrw2blazfbf3r+M82HvTUHInVex2PyRLz8WIz3jMoivSHUWW15T1aXE25yuRltwu4kij 9B5b6eT+XNzFmjfY6xR2hRps/Ad9NLFR8U5Sj1eoHpMMHD/RAtsOyARktEk6TgrjHzbS rizPobLU/8btaCsWbQRM8gRk6TOVo65+/S14F9AW2SzzAXu1XK1rYiS6dgKQqMdJemxN bgkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=KKKRGK7UPB9Xt0Opnf9sS/9h48Rxxe8Xvqfw65iKh+g=; b=U+sXs/tSfiNqMZaiabiaOpWh3DbDKw54KfKFifHUJLfPQfhWfKBlpLlXXU/PxtbVzf 3y2Vfscb3gWQeCTvuUMHlELQQMyIMAmq7l9GNorde+VLYqIqXdK73pcBZzkHJD2gB4Vd youCcJDlMlZl+4FoUFZovh2QJXOkR17lpAz6JQf6XYIZMPuaXpruF+2GPahyRFIqLObf 86AKnaQ2p1X/2Qqru41fvyENEYQsQg+BHzuhL/zmhSWSN+vKzvCfGMnqX0ePKRYbJJKA Sp/pYBl+j/iTMm0E68KmCwySt4UIlT0UEFTsiLfjeg2Rw4+FglsbEOtVw3YYc1+0crxA hEog== X-Gm-Message-State: APjAAAU3GqhPiECTNL6hZUjFc1nTVXudStYjLRfURx5aAx0L616yFtVl e5QzRrLZS/wJQ8F7683pZtow0V1BeP+xOybf+5E= X-Google-Smtp-Source: APXvYqzkrpqcevXwwtdCeZNKzW3c+5Dd1eXwKsFeO582EsHFwWybREFcLjbfkn5kxy4VBZmTtek2DWwFNyBiH8Fvgvg= X-Received: by 2002:a17:906:fcb8:: with SMTP id qw24mr18502462ejb.239.1559750592409; Wed, 05 Jun 2019 09:03:12 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 5 Jun 2019 09:03:11 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 5 Jun 2019 09:03:11 -0700 Message-ID: Subject: =?UTF-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: Ian Swett Cc: Nick Banks , IETF QUIC WG , Jiuhai Zhang Content-Type: multipart/alternative; boundary="000000000000ffb4be058a95bb35" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 16:03:17 -0000 --000000000000ffb4be058a95bb35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 10.3: "After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate." On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com) wrote: Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well. However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE? Or am I misreading the text about draining? On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response ca= n > contain other frames.. So technically you can ACK a connection close. > > Doing so might actually make sense if the original closer take that as a > signal to drain faster. > > > On 5 June 2019 at 16.00.16, Nick Banks ( > nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: > > Ian, > > > > I have encountered issues both in local automated tests and during > interop, where one side gets everything it wants and then cleanly closes > the connection. The issues arise because the peer hasn=E2=80=99t received= the ACK > for that last exchange. For that reason, winquic always encodes its lates= t > ACK state with (always frames before) the CONNECTION_CLOSE frame. This > doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s up= to the receiver > if they want to process the ACKs or not; but it helps these kind of > scenarios. > > > > A simple example test case: > > > > Client: Open one bidirectional stream, send data on it, FIN it, and verif= y > the peer does the same. Then close the connection. > > Server: Accept one bidirectional stream, receive all data on it and echo > it back. Verify all data is sent successfully. > > > > The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you d= on=E2=80=99t send ACKs > with CONNECTION_CLOSE. So, I personally think it=E2=80=99s a good idea to= recommend > including ACKs. I know it doesn=E2=80=99t provide any guarantees in the p= resence of > packet loss, so ideally you don=E2=80=99t design an app protocol on top o= f this, > but it does make things a little nicer, IMO. > > > > Thank, > > - Nick > > > > *From:* QUIC *On Behalf Of* Ian Swett > *Sent:* Wednesday, June 5, 2019 6:48 AM > *To:* Jiuhai Zhang > *Cc:* IETF QUIC WG > *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F > > > > Technically, yes. But connections don't send any packets after processin= g > a CONNECTION_CLOSE frame, so you would never receive and ACK for it. > > > > From: > https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1 > > > "The draining state is entered once an endpoint receives a signal that > > its peer is closing or draining. While otherwise identical to the > closing state, an endpoint in the draining state MUST NOT send any > packets. Retaining packet protection keys is unnecessary once a > connection is in the draining state." > > > > On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang > wrote: > > In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 > > > Ack-eliciting Frames: All frames besides ACK or PADDING are > > considered ack-eliciting. > > Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F > > Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE fr= ame=EF=BC=9F > > --000000000000ffb4be058a95bb35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = 10.3: "After receiving a CONNEC= TION_CLOSE frame, endpoints enter the draining state. An endpoint that rece= ives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECT= ION_CLOSE frame before entering the draining state, using a CONNECTION_CLOS= E frame and a NO_ERROR code if appropriate."

On 5 J= une 2019 at 17.58.19, Ian Swett (ianswett@google.com) wrote:
Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well.

However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?=C2=A0 Or am I misreading the text about draining?

On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can contain other frames.. So technically you can ACK a connection close.

Doing so might actually make sense if the original closer take that as a signal to drain faster.


On 5 June 2019 at 16.00.16, Nick Banks (nibanks=3D40microsoft.com@dmarc.ietf.org) wrot= e:

Ian,

=C2=A0

I have encountered issues both in local automated tests and during interop, where one side gets everything it wants and then cleanly closes the connection. The issues arise because the peer hasn=E2=80=99t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always frames before) the CONNECTION_CLOSE frame. This doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s up to the receiver if they want to process the ACKs or not; but it helps these kind of scenarios.

=C2=A0

A simple example test case:

=C2=A0

Client: Open one bidirectional stream, send data on it, FIN it, and verify the peer does the same. Then close the connection.

Server: Accept one bidirectional stream, receive all data on it and echo it back. Verify all data is sent successfully.

=C2=A0

The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you don=E2=80=99t send ACKs with CONNECTION_= CLOSE. So, I personally think it=E2=80=99s a good idea to recommend including ACKs. I know it doesn=E2=80=99t provide any guarantees in the presence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of this, but it does make things a little nicer, IMO.

=C2=A0

Thank,

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Beha= lf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F

=C2=A0

Technically, yes.=C2=A0 But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it.

=C2=A0

"The draining state is entered once an endpoint receives a signal that

=C2=A0 =C2=A0its peer is closing or draining.=C2=A0 While otherwise identical to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUST NOT send any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection keys is unnecessary once a
=C2=A0 =C2=A0connection is in the draining state."

=C2=A0

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhan= g@gmail.com> wrote:

Ack-eliciting =
Frames:  All frames besides ACK or PADDING are
      considered ack-eliciting.

 


Is CONNECTION_=
CLOSE frame Ack-eliciting=EF=BC=9F


Should endpoin=
t responds a ACK frame when receiving a CONNECTION_CLOSE frame=EF=BC=9F
--000000000000ffb4be058a95bb35-- From nobody Wed Jun 5 09:08:21 2019 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 5E53D120169 for ; Wed, 5 Jun 2019 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.519 X-Spam-Level: X-Spam-Status: No, score=-15.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk2p9BU1uBr0 for ; Wed, 5 Jun 2019 09:08:17 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 812761201C5 for ; Wed, 5 Jun 2019 09:08:17 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id s3so2841122wms.2 for ; Wed, 05 Jun 2019 09:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DuFFzzcnPoKlOZL05rFbF/jmGsZW1Ls4vplhGkJKx1g=; b=iC4PwNOfmoiQVeLkDXUHHPEnHtxRA6uI1hjMCBiAfyb1frG8zRF88TVY2zLrqDBkQ+ Qz6PQ/mdVqf+WhiESkk3rpbBwRzQ4UmsPtJmj1jii9L+/oACbAsYFqzrP3jfbJyU5PSZ 5xluuvyDTM9itwjQWg53bc0MN4LXHW6zQaikGbZX9AGTRmFBjl9h5T3ceKo7o7C5MbMI 9HRXG6571/wP3nV0mOMgNuZbQNRanNs7oM0nkr+tnwfl4l2pyUEdBy7hHQVa/pYIFl66 tw3/VxJYsOUemF+VKA+lPj84489+9XXEo2rmBf/29sTPsqpGcHREzHQF6v1FniJl3E+m 2YXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DuFFzzcnPoKlOZL05rFbF/jmGsZW1Ls4vplhGkJKx1g=; b=tBKt43ZlBfaSWE1V7y5/sF2eZGXX3q3v/Esb5zrX4/XXwi3dGFPDYdWDZ2TMXrhRIK k9AAkhrVVPr4NGTfLqdkonQbb25YAE8PjzTY+SyXoKifLFwwukjRIwIsOD0ZPOYOjUaz sVfU9PEoTK3emJcO/pzpPxufqmiz1tBvetnrMqTd9JfzOl21qcujL8L0yU3Ta874Abex +9OTDsPb+/RsFhFTRYPtuXMfY2AduM8YrnEM+5S4NKDl1j+IDERV+q1xxdNdbYDVPWba ZQCi8jyk5wZm5iszExU8RMU6/u9j7JafPKHKPkINMIgpIICB/+zmqGdX9iRLblYCbGW2 PoBg== X-Gm-Message-State: APjAAAXLZ3cTlzryqQc80IuEvJ0ySKMKada6Mkl3OiJ3jQlDBfgOdHHU lOVYXPZKiyiD8FZY6yajO1Hn24TDAS9nXCy5ZHOX0Q== X-Google-Smtp-Source: APXvYqwrB6FKclw8PGoPBkECMn0hcTJ1re02SwWATJap10Z05YcufeusKG/4N7w8jNj4zhBk+TXQdE3ZXSMOnpZ51RY= X-Received: by 2002:a7b:c775:: with SMTP id x21mr23032878wmk.9.1559750895422; Wed, 05 Jun 2019 09:08:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 5 Jun 2019 12:08:03 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Nick Banks , IETF QUIC WG , Jiuhai Zhang Content-Type: multipart/alternative; boundary="0000000000000fc97b058a95cee0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 16:08:20 -0000 --0000000000000fc97b058a95cee0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I missed that. On Wed, Jun 5, 2019 at 12:03 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > 10.3: "After receiving a CONNECTION_CLOSE frame, endpoints enter the > draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY se= nd > a single packet containing a CONNECTION_CLOSE frame before entering the > draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if > appropriate." > > On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com) wrote: > > Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and > our implementation does that as well. > > However, it seems like the existing text indicates you'd never expect to > get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE? Or am I > misreading the text about draining? > > On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response >> can contain other frames.. So technically you can ACK a connection close= . >> >> Doing so might actually make sense if the original closer take that as a >> signal to drain faster. >> >> >> On 5 June 2019 at 16.00.16, Nick Banks ( >> nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: >> >> Ian, >> >> >> >> I have encountered issues both in local automated tests and during >> interop, where one side gets everything it wants and then cleanly closes >> the connection. The issues arise because the peer hasn=E2=80=99t receive= d the ACK >> for that last exchange. For that reason, winquic always encodes its late= st >> ACK state with (always frames before) the CONNECTION_CLOSE frame. This >> doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s u= p to the receiver >> if they want to process the ACKs or not; but it helps these kind of >> scenarios. >> >> >> >> A simple example test case: >> >> >> >> Client: Open one bidirectional stream, send data on it, FIN it, and >> verify the peer does the same. Then close the connection. >> >> Server: Accept one bidirectional stream, receive all data on it and echo >> it back. Verify all data is sent successfully. >> >> >> >> The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you = don=E2=80=99t send ACKs >> with CONNECTION_CLOSE. So, I personally think it=E2=80=99s a good idea t= o recommend >> including ACKs. I know it doesn=E2=80=99t provide any guarantees in the = presence of >> packet loss, so ideally you don=E2=80=99t design an app protocol on top = of this, >> but it does make things a little nicer, IMO. >> >> >> >> Thank, >> >> - Nick >> >> >> >> *From:* QUIC *On Behalf Of* Ian Swett >> *Sent:* Wednesday, June 5, 2019 6:48 AM >> *To:* Jiuhai Zhang >> *Cc:* IETF QUIC WG >> *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F >> >> >> >> Technically, yes. But connections don't send any packets after >> processing a CONNECTION_CLOSE frame, so you would never receive and ACK = for >> it. >> >> >> >> From: >> https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1 >> >> >> "The draining state is entered once an endpoint receives a signal that >> >> its peer is closing or draining. While otherwise identical to the >> closing state, an endpoint in the draining state MUST NOT send any >> packets. Retaining packet protection keys is unnecessary once a >> connection is in the draining state." >> >> >> >> On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang >> wrote: >> >> In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 >> >> >> Ack-eliciting Frames: All frames besides ACK or PADDING are >> >> considered ack-eliciting. >> >> Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F >> >> Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE f= rame=EF=BC=9F >> >> --0000000000000fc97b058a95cee0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, I missed that.

On Wed, Jun 5, 2019 at 12:03 PM Mikk= el Fahn=C3=B8e J=C3=B8rgensen <mik= kelfj@gmail.com> wrote:
10.3: "After receivi= ng a CONNECTION_CLOSE frame, endpoints enter the draining state. An endpoin= t that receives a CONNECTION_CLOSE frame MAY send a single packet containin= g a CONNECTION_CLOSE frame before entering the draining state, using a CONN= ECTION_CLOSE frame and a NO_ERROR code if appropriate."

On 5 June 2= 019 at 17.58.19, Ian Swett (ianswett@google.com<= /a>) wrote:
=
Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well.

However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?=C2=A0 Or am I misreading the text about draining?

On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can contain other frames.. So technically you can ACK a connection close.

Doing so might actually make sense if the original closer take that as a signal to drain faster.


On 5 June 2019 at 16.00.16, Nick Banks (nibanks=3D40microsoft.com@dmarc.ietf.org) wrot= e:

Ian,

=C2=A0

I have encountered issues both in local automated tests and during interop, where one side gets everything it wants and then cleanly closes the connection. The issues arise because the peer hasn=E2=80=99t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always frames before) the CONNECTION_CLOSE frame. This doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s up to the receiver if they want to process the ACKs or not; but it helps these kind of scenarios.

=C2=A0

A simple example test case:

=C2=A0

Client: Open one bidirectional stream, send data on it, FIN it, and verify the peer does the same. Then close the connection.

Server: Accept one bidirectional stream, receive all data on it and echo it back. Verify all data is sent successfully.

=C2=A0

The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you don=E2=80=99t send ACKs with CONNECTION_= CLOSE. So, I personally think it=E2=80=99s a good idea to recommend including ACKs. I know it doesn=E2=80=99t provide any guarantees in the presence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of this, but it does make things a little nicer, IMO.

=C2=A0

Thank,

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Beha= lf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F

=C2=A0

Technically, yes.=C2=A0 But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it.

=C2=A0

"The draining state is entered once an endpoint receives a signal that

=C2=A0 =C2=A0its peer is closing or draining.=C2=A0 While otherwise identical to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUST NOT send any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection keys is unnecessary once a
=C2=A0 =C2=A0connection is in the draining state."

=C2=A0

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhan= g@gmail.com> wrote:

Ack-eliciting =
Frames:  All frames besides ACK or PADDING are
      considered ack-eliciting.

 


Is CONNECTION_=
CLOSE frame Ack-eliciting=EF=BC=9F


Should endpoin=
t responds a ACK frame when receiving a CONNECTION_CLOSE frame=EF=BC=9F
--0000000000000fc97b058a95cee0-- From nobody Wed Jun 5 09:26:03 2019 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 26BE81200FA for ; Wed, 5 Jun 2019 09:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYu_ieWwwhi9 for ; Wed, 5 Jun 2019 09:25:59 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1402712004E for ; Wed, 5 Jun 2019 09:25:58 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id j24so23744614ljg.1 for ; Wed, 05 Jun 2019 09:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NaoqN1YRPrv0q7oubEi+A0wZc116dwPLi1jorQ6haAs=; b=vMav83vaRZo4q6g5kftybMjZACrA1E4Wnx2e/nikCz1IX9eCxpmcxHEyIEChNvSvib injZreSAyir2kks/JQDKK5NetktxpO7CQuyffABfmzEQI46AnABEP7jMHOszcSbqmH50 DQ4YEQqkFSVVvebiFig4vPsGSIxbiW1CNUuyvRgnAHVs5WqDHnYQSAjem8zIg3yJSo/g R8oZIxoWaXUju14cmfj0+tRQrqcLOq2O0ktGeyV3/wf4N0/BVTITw6Pr7Sx5cOl885cq 6coh0dxtiu54f5ci2hHiLAInK6N3h3oMitEmR2PwSf5XQwd2/6NvFUewes/WqlC4ePHN +oaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NaoqN1YRPrv0q7oubEi+A0wZc116dwPLi1jorQ6haAs=; b=lRSQ3xBE38g9DYY+7EFgw3Q+0Ivxv6XY43L9gC8W+3JbBhqJpdFFxO3/jaK+Kdy1Y2 hfV5d5wgILRk0EozU48WZbtHAj8/1Z0ebR/HDBJ3ZUrxIx1eIg3xDu5vmUeq3loMs5TH d9ESjyrUdM04cgWlLW7fIkvdPNIq2xGzIy20tAHC/V79N1qWnaeTEa2uN3T0t+Fpje8G q16E/tzja9KDLa5ZsMM6n/maJjuxhkjGNF6YjWXU1f1l6v2G+s4cc9YU0B4zVsRQFoZx FPxV0XwRptA0Mde+4RYYY2NBowEh0buH6Q9wK1bzUuhk9CPY81UtngoCrXzHicKVXOeW Lz9w== X-Gm-Message-State: APjAAAXADitxsRzrdIQBFL7WpaOi0BNseo866BE169ZV69NRw96KPRVV +Y+vWRUMQUqxGdQkoPLrlQlzvc4cJB721/DTBFw= X-Google-Smtp-Source: APXvYqzpBj5vAIa7kMjPBueKnbCYuS+Z6jX913dEkDY0ZMQKHAMoJx89FJsaIPzQ/XFUq/VMPwYQE562cV9k7mnr+wA= X-Received: by 2002:a2e:b04c:: with SMTP id d12mr6757069ljl.218.1559751957054; Wed, 05 Jun 2019 09:25:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marten Seemann Date: Thu, 6 Jun 2019 00:25:45 +0800 Message-ID: Subject: =?UTF-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Ian Swett , Nick Banks , IETF QUIC WG , Jiuhai Zhang Content-Type: multipart/alternative; boundary="00000000000056892d058a960dfc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 16:26:02 -0000 --00000000000056892d058a960dfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It doesn't really make sense to send a CONNECTION_CLOSE frame in response to a CONNECTION_CLOSE, since in the closing state an endpoint retains "only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection", i.e. an endpoint won't even open the packet (but it might reply with another CONNECTION_CLOSE). Of course, and endpoint can send as many packets after this as it wants (there's no way it could be penalized for misbehaving), although I'm not sure why we're explicitly allowing sending CONNECTION_CLOSE as a response. I'm not really sure what the benefit is of sending an ACK frame bundled with a CONNECTION_CLOSE. There's nothing the receiving peer can do in reaction to receiving that ACK - the connection is already closed. Furthermore, it would be wrong to conclude that all stream data has been processed by the application. An ACK for a STREAM frame only means that the STREAM frame was processed by the QUIC stack, not by the application. On Thu, Jun 6, 2019 at 12:03 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > 10.3: "After receiving a CONNECTION_CLOSE frame, endpoints enter the > draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY se= nd > a single packet containing a CONNECTION_CLOSE frame before entering the > draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if > appropriate." > > On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com) wrote: > > Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and > our implementation does that as well. > > However, it seems like the existing text indicates you'd never expect to > get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE? Or am I > misreading the text about draining? > > On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response >> can contain other frames.. So technically you can ACK a connection close= . >> >> Doing so might actually make sense if the original closer take that as a >> signal to drain faster. >> >> >> On 5 June 2019 at 16.00.16, Nick Banks ( >> nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: >> >> Ian, >> >> >> >> I have encountered issues both in local automated tests and during >> interop, where one side gets everything it wants and then cleanly closes >> the connection. The issues arise because the peer hasn=E2=80=99t receive= d the ACK >> for that last exchange. For that reason, winquic always encodes its late= st >> ACK state with (always frames before) the CONNECTION_CLOSE frame. This >> doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s u= p to the receiver >> if they want to process the ACKs or not; but it helps these kind of >> scenarios. >> >> >> >> A simple example test case: >> >> >> >> Client: Open one bidirectional stream, send data on it, FIN it, and >> verify the peer does the same. Then close the connection. >> >> Server: Accept one bidirectional stream, receive all data on it and echo >> it back. Verify all data is sent successfully. >> >> >> >> The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you = don=E2=80=99t send ACKs >> with CONNECTION_CLOSE. So, I personally think it=E2=80=99s a good idea t= o recommend >> including ACKs. I know it doesn=E2=80=99t provide any guarantees in the = presence of >> packet loss, so ideally you don=E2=80=99t design an app protocol on top = of this, >> but it does make things a little nicer, IMO. >> >> >> >> Thank, >> >> - Nick >> >> >> >> *From:* QUIC *On Behalf Of* Ian Swett >> *Sent:* Wednesday, June 5, 2019 6:48 AM >> *To:* Jiuhai Zhang >> *Cc:* IETF QUIC WG >> *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F >> >> >> >> Technically, yes. But connections don't send any packets after >> processing a CONNECTION_CLOSE frame, so you would never receive and ACK = for >> it. >> >> >> >> From: >> https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1 >> >> >> "The draining state is entered once an endpoint receives a signal that >> >> its peer is closing or draining. While otherwise identical to the >> closing state, an endpoint in the draining state MUST NOT send any >> packets. Retaining packet protection keys is unnecessary once a >> connection is in the draining state." >> >> >> >> On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang >> wrote: >> >> In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 >> >> >> Ack-eliciting Frames: All frames besides ACK or PADDING are >> >> considered ack-eliciting. >> >> Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F >> >> Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE f= rame=EF=BC=9F >> >> --00000000000056892d058a960dfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It doesn't really make sense to send a CONNECTION_CLOS= E frame in response to a CONNECTION_CLOSE, since in the closing state an en= dpoint retains "only enough information to generate a packet containin= g a CONNECTION_CLOSE frame and to identify packets as belonging to the conn= ection", i.e. an endpoint won't even open the packet (but it might= reply with another CONNECTION_CLOSE).
Of course, and endpoint can send= as many packets after this as it wants (there's no way it could be pen= alized for misbehaving), although I'm not sure why we're explicitly= allowing sending CONNECTION_CLOSE as a response.

I'= m not really sure what the benefit is of sending an ACK frame bundled with = a CONNECTION_CLOSE. There's nothing the receiving peer can do in reacti= on to receiving that ACK - the connection is already closed. Furthermore, i= t would be wrong to conclude that all stream data has been processed by the= application. An ACK for a STREAM frame only means that the STREAM frame wa= s processed by the QUIC stack, not by the application.
On Thu, J= un 6, 2019 at 12:03 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:=
10.3: "After receiving a CONNECTION_CLOSE frame, endpoints = enter the draining state. An endpoint that receives a CONNECTION_CLOSE fram= e MAY send a single packet containing a CONNECTION_CLOSE frame before enter= ing the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code = if appropriate."

On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com) wrote:
Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well.

However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?=C2=A0 Or am I misreading the text about draining?

On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can contain other frames.. So technically you can ACK a connection close.

Doing so might actually make sense if the original closer take that as a signal to drain faster.


On 5 June 2019 at 16.00.16, Nick Banks (nibanks=3D40microsoft.com@dmarc.ietf.org) wrot= e:

Ian,

=C2=A0

I have encountered issues both in local automated tests and during interop, where one side gets everything it wants and then cleanly closes the connection. The issues arise because the peer hasn=E2=80=99t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always frames before) the CONNECTION_CLOSE frame. This doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s up to the receiver if they want to process the ACKs or not; but it helps these kind of scenarios.

=C2=A0

A simple example test case:

=C2=A0

Client: Open one bidirectional stream, send data on it, FIN it, and verify the peer does the same. Then close the connection.

Server: Accept one bidirectional stream, receive all data on it and echo it back. Verify all data is sent successfully.

=C2=A0

The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you don=E2=80=99t send ACKs with CONNECTION_= CLOSE. So, I personally think it=E2=80=99s a good idea to recommend including ACKs. I know it doesn=E2=80=99t provide any guarantees in the presence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of this, but it does make things a little nicer, IMO.

=C2=A0

Thank,

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Beha= lf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F

=C2=A0

Technically, yes.=C2=A0 But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it.

=C2=A0

"The draining state is entered once an endpoint receives a signal that

=C2=A0 =C2=A0its peer is closing or draining.=C2=A0 While otherwise identical to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUST NOT send any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection keys is unnecessary once a
=C2=A0 =C2=A0connection is in the draining state."

=C2=A0

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhan= g@gmail.com> wrote:

Ack-eliciting =
Frames:  All frames besides ACK or PADDING are
      considered ack-eliciting.

 


Is CONNECTION_=
CLOSE frame Ack-eliciting=EF=BC=9F


Should endpoin=
t responds a ACK frame when receiving a CONNECTION_CLOSE frame=EF=BC=9F
--00000000000056892d058a960dfc-- From nobody Wed Jun 5 09:38:23 2019 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 AF78712004E for ; Wed, 5 Jun 2019 09:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxQhk9vNP0Sv for ; Wed, 5 Jun 2019 09:38:19 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740091.outbound.protection.outlook.com [40.107.74.91]) (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 14CE9120041 for ; Wed, 5 Jun 2019 09:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=l4Unp8c/XF05nYSwu1YQB5+jf4vxn2mIwmYU+ilSMSBpBziQST+yFNzWCqwW/5zceD0wNK3/mskwPDvrkS0/83YxiBIKUL1h0UAYZ3+MiByeyjcZmEQFEFph+EKKlT2/4+FlVgALuti56HbN1PG87QjlyKpsnLKkuFGYdKDjb+E= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=osKh7Frh+8Yxw59F4HqWKsWOaNEd2r1Go0RFqQkmBWc=; b=mXpkdbdBPnShOY20CNJT6gBT3NG6VWIpa4vngVQTZtYnGKYWLTlVLy3tIqOO6uVanJTW8navAVKqC+x1jjEt6SRFLAECXBV7kgYwppiBSiK6fVLMK+APj5w5IcjPIbKS/EBeBhqHzHitvHijp92kcpL/zkgK/xfCpC3i8OFISgI= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=osKh7Frh+8Yxw59F4HqWKsWOaNEd2r1Go0RFqQkmBWc=; b=cTynQZhmP99al52WI+JjG5VIaqA7qX2BdZGwNl+sPSe8xclNBlcqQiFCbAsw1SdaasMkmrZpeCJ5Yp6ZqqnEq9JUwsKJPgRLV/MQVdaEjHS1CqogYjTQlfBXED6TPlSDToyAmHP7YbddC0sT4aHxo0gS2NOEOysHKUVQhg9yzAc= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (2603:10b6:207:37::13) by BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.3; Wed, 5 Jun 2019 16:38:15 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::30e9:8bfc:9b18:9fa1]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::30e9:8bfc:9b18:9fa1%3]) with mapi id 15.20.1987.004; Wed, 5 Jun 2019 16:38:15 +0000 From: Nick Banks To: Marten Seemann , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Ian Swett , IETF QUIC WG , Jiuhai Zhang Subject: =?utf-8?B?UkU6IElzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUgQWNrLWVsaWNpdGluZw==?= =?utf-8?B?77yf?= Thread-Topic: =?utf-8?B?SXMgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBBY2stZWxpY2l0aW5n77yf?= Thread-Index: AQHVG5bFgUQ+cxLqqU2bDm3dQiViRqaNE4cAgAAAi0CAAATdgIAAHtAAgAABbICAAAZOgIAAAelQ Date: Wed, 5 Jun 2019 16:38:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-06-05T16:38:13.7448829Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=65cfeb2c-4ade-4d0c-bcc8-e84854c0a570; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-originating-ip: [2001:4898:80e8:0:513f:7528:875a:162c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43f50326-0957-429a-4b3a-08d6e9d4357e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1027; x-ms-traffictypediagnostic: BL0PR2101MB1027: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(376002)(136003)(366004)(189003)(199004)(14454004)(68736007)(8936002)(33656002)(76176011)(7696005)(66574012)(8990500004)(52396003)(81166006)(81156014)(71200400001)(5070765005)(66446008)(64756008)(66556008)(66476007)(73956011)(66946007)(76116006)(10290500003)(478600001)(102836004)(7736002)(46003)(6506007)(53546011)(446003)(11346002)(71190400001)(966005)(486006)(476003)(2906002)(6246003)(6116002)(790700001)(53936002)(9686003)(55016002)(236005)(54896002)(25786009)(6306002)(229853002)(52536014)(74316002)(6436002)(4326008)(86362001)(110136005)(54906003)(256004)(14444005)(186003)(22452003)(5660300002)(99286004)(316002)(517774005)(10090500001)(606006)(440504004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1027; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 25DImVSaNi4zi3DBJJGdivFKgiMsm9ASQb5vvzhv1FS+tLGNNxppjMd15daFnPDy0iWL2h8jK0kI0MzYmiXsgc/g9/o3mQ3FMjbW8udHi9RAiDp56ho6lBDpf1SMVHRYgLJlLhe/T8sCkznKjRO5+7JayzS2N6Rxi5OSYDjepDfcCOjg6lI01r0OMSd5o3NYR9Lj9R+8MEDFWwp4swWyYS8LqojOLL+0hDreQpL1zUgbLg4ig/MuY36UNHySMO2sc8X0k6wFaMvtoQjQovhWXw/tad3aUuO5oy9yxUA76U28r0ImNy21eAGYrGilH+KVywBfkjzPFWYgZ/qwzR1Mo1+EKTe3Vx+7UiSWSyiAHNpcxlIr+h3lfa+d6JVujNemTeVyClQUEcZFOy9zBhcKasAAklfRW3bpxN3df1INWCQ= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43f50326-0957-429a-4b3a-08d6e9d4357e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 16:38:15.6993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nibanks@microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1027 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 16:38:22 -0000 --_000_BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160BL0PR2101MB1043_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgbm8gYWJzb2x1dGUgcmVxdWlyZW1lbnQgdGhhdCB5b3UgbWFpbnRhaW4gdGhlIG1p bmltYWwgc3RhdGUgdG8gZ2VuZXJhdGUgdGhlIENPTk5FQ1RJT05fQ0xPU0UuIFBlcnNvbmFsbHks IEkgZmVlbCBhIE1BWSBpcyBtaXNzaW5nIGluIHRoYXQgc2VudGVuY2UuIEFkZGl0aW9uYWxseSwg SSBmZWVsIHRoYXQgYW4gZW5kcG9pbnQgU0hPVUxEIChub3QgYSBNVVNUIGJlY2F1c2UgaXTigJlz IHVuZW5mb3JjZWFibGUpIHJlc3BvbmQgd2l0aCBhbiBpbW1lZGlhdGUgQ09OTkVDVElPTl9DTE9T RSBvZiBpdHMgb3duLCBzbyB0aGUgcGVlciBjYW4gdXNlIHRoYXQgYXMgYSBzaWduYWwgb2YgYWNr bm93bGVkZ2VtZW50IGFuZCBpbW1lZGlhdGVseSBnbyBhd2F5LCB3aXRob3V0IHdhaXRpbmcgdGhl IGZ1bGwgZHJhaW5pbmcgcGVyaW9kLiBCdXQsIEkga25vdyBJ4oCZbSBub3QgaW4gdGhlIG1ham9y aXR5IHdpdGggdGhhdCBvcGluaW9uLg0KDQpPbiB0aGUgdG9waWMgb2Ygc2VuZGluZyBBQ0tzIHdp dGggQ09OTkVDVElPTl9DTE9TRSwgSSBhbSBtb3JlIHJlZmVycmluZyB0byBidW5kbGluZyBBQ0tz IHdpdGggdGhlIGluaXRpYWwgQ09OTkVDVElPTl9DTE9TRS4gSSBhZ3JlZSwgdGhhdCBzZW5kaW5n IEFDS3Mgd2l0aCB0aGUgcmVzcG9uZGluZyBDT05ORUNUSU9OX0NMT1NFIGRvZXNu4oCZdCBkbyBt dWNoLg0KDQotIE5pY2sNCg0KRnJvbTogTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21h aWwuY29tPg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDUsIDIwMTkgOToyNiBBTQ0KVG86IE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBJYW4gU3dldHQg PGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBOaWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb20+ OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBKaXVoYWkgWmhhbmcgPGppdWhhaS56aGFu Z0BnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogSXMgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBBY2st ZWxpY2l0aW5n77yfDQoNCkl0IGRvZXNuJ3QgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gc2VuZCBhIENP Tk5FQ1RJT05fQ0xPU0UgZnJhbWUgaW4gcmVzcG9uc2UgdG8gYSBDT05ORUNUSU9OX0NMT1NFLCBz aW5jZSBpbiB0aGUgY2xvc2luZyBzdGF0ZSBhbiBlbmRwb2ludCByZXRhaW5zICJvbmx5IGVub3Vn aCBpbmZvcm1hdGlvbiB0byBnZW5lcmF0ZSBhIHBhY2tldCBjb250YWluaW5nIGEgQ09OTkVDVElP Tl9DTE9TRSBmcmFtZSBhbmQgdG8gaWRlbnRpZnkgcGFja2V0cyBhcyBiZWxvbmdpbmcgdG8gdGhl IGNvbm5lY3Rpb24iLCBpLmUuIGFuIGVuZHBvaW50IHdvbid0IGV2ZW4gb3BlbiB0aGUgcGFja2V0 IChidXQgaXQgbWlnaHQgcmVwbHkgd2l0aCBhbm90aGVyIENPTk5FQ1RJT05fQ0xPU0UpLg0KT2Yg Y291cnNlLCBhbmQgZW5kcG9pbnQgY2FuIHNlbmQgYXMgbWFueSBwYWNrZXRzIGFmdGVyIHRoaXMg YXMgaXQgd2FudHMgKHRoZXJlJ3Mgbm8gd2F5IGl0IGNvdWxkIGJlIHBlbmFsaXplZCBmb3IgbWlz YmVoYXZpbmcpLCBhbHRob3VnaCBJJ20gbm90IHN1cmUgd2h5IHdlJ3JlIGV4cGxpY2l0bHkgYWxs b3dpbmcgc2VuZGluZyBDT05ORUNUSU9OX0NMT1NFIGFzIGEgcmVzcG9uc2UuDQoNCkknbSBub3Qg cmVhbGx5IHN1cmUgd2hhdCB0aGUgYmVuZWZpdCBpcyBvZiBzZW5kaW5nIGFuIEFDSyBmcmFtZSBi dW5kbGVkIHdpdGggYSBDT05ORUNUSU9OX0NMT1NFLiBUaGVyZSdzIG5vdGhpbmcgdGhlIHJlY2Vp dmluZyBwZWVyIGNhbiBkbyBpbiByZWFjdGlvbiB0byByZWNlaXZpbmcgdGhhdCBBQ0sgLSB0aGUg Y29ubmVjdGlvbiBpcyBhbHJlYWR5IGNsb3NlZC4gRnVydGhlcm1vcmUsIGl0IHdvdWxkIGJlIHdy b25nIHRvIGNvbmNsdWRlIHRoYXQgYWxsIHN0cmVhbSBkYXRhIGhhcyBiZWVuIHByb2Nlc3NlZCBi eSB0aGUgYXBwbGljYXRpb24uIEFuIEFDSyBmb3IgYSBTVFJFQU0gZnJhbWUgb25seSBtZWFucyB0 aGF0IHRoZSBTVFJFQU0gZnJhbWUgd2FzIHByb2Nlc3NlZCBieSB0aGUgUVVJQyBzdGFjaywgbm90 IGJ5IHRoZSBhcHBsaWNhdGlvbi4NCg0KT24gVGh1LCBKdW4gNiwgMjAxOSBhdCAxMjowMyBBTSBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tl bGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KMTAuMzogIkFmdGVyIHJlY2VpdmluZyBhIENPTk5FQ1RJ T05fQ0xPU0UgZnJhbWUsIGVuZHBvaW50cyBlbnRlciB0aGUgZHJhaW5pbmcgc3RhdGUuIEFuIGVu ZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBDT05ORUNUSU9OX0NMT1NFIGZyYW1lIE1BWSBzZW5kIGEg c2luZ2xlIHBhY2tldCBjb250YWluaW5nIGEgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBiZWZvcmUg ZW50ZXJpbmcgdGhlIGRyYWluaW5nIHN0YXRlLCB1c2luZyBhIENPTk5FQ1RJT05fQ0xPU0UgZnJh bWUgYW5kIGEgTk9fRVJST1IgY29kZSBpZiBhcHByb3ByaWF0ZS4iDQoNCk9uIDUgSnVuZSAyMDE5 IGF0IDE3LjU4LjE5LCBJYW4gU3dldHQgKGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3 ZXR0QGdvb2dsZS5jb20+KSB3cm90ZToNCk5pY2ssIEkgYWdyZWUgdGhhdCBidW5kbGluZyBhbiBB Q0sgd2l0aCBhIENPTk5FQ1RJT05fQ0xPU0UgaXMgdXNlZnVsLCBhbmQgb3VyIGltcGxlbWVudGF0 aW9uIGRvZXMgdGhhdCBhcyB3ZWxsLg0KDQpIb3dldmVyLCBpdCBzZWVtcyBsaWtlIHRoZSBleGlz dGluZyB0ZXh0IGluZGljYXRlcyB5b3UnZCBuZXZlciBleHBlY3QgdG8gZ2V0IGEgQ09OTkVDVElP Tl9DTE9TRSBpbiByZXNwb25zZSB0byBhIENPTk5FQ1RJT05fQ0xPU0U/ICBPciBhbSBJIG1pc3Jl YWRpbmcgdGhlIHRleHQgYWJvdXQgZHJhaW5pbmc/DQoNCk9uIFdlZCwgSnVuIDUsIDIwMTkgYXQg MTA6MDggQU0gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1h aWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNCkNPTk5FQ1RJT05fQ0xPU0UgY2FuIGJl IHJlc3BvbnNlIHRvIENPTk5FQ1RJT05fQ0xPU0UgYW5kIHRoYXQgcmVzcG9uc2UgY2FuIGNvbnRh aW4gb3RoZXIgZnJhbWVzLi4gU28gdGVjaG5pY2FsbHkgeW91IGNhbiBBQ0sgYSBjb25uZWN0aW9u IGNsb3NlLg0KDQpEb2luZyBzbyBtaWdodCBhY3R1YWxseSBtYWtlIHNlbnNlIGlmIHRoZSBvcmln aW5hbCBjbG9zZXIgdGFrZSB0aGF0IGFzIGEgc2lnbmFsIHRvIGRyYWluIGZhc3Rlci4NCg0KDQoN Ck9uIDUgSnVuZSAyMDE5IGF0IDE2LjAwLjE2LCBOaWNrIEJhbmtzIChuaWJhbmtzPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1h cmMuaWV0Zi5vcmc+KSB3cm90ZToNCklhbiwNCg0KSSBoYXZlIGVuY291bnRlcmVkIGlzc3VlcyBi b3RoIGluIGxvY2FsIGF1dG9tYXRlZCB0ZXN0cyBhbmQgZHVyaW5nIGludGVyb3AsIHdoZXJlIG9u ZSBzaWRlIGdldHMgZXZlcnl0aGluZyBpdCB3YW50cyBhbmQgdGhlbiBjbGVhbmx5IGNsb3NlcyB0 aGUgY29ubmVjdGlvbi4gVGhlIGlzc3VlcyBhcmlzZSBiZWNhdXNlIHRoZSBwZWVyIGhhc27igJl0 IHJlY2VpdmVkIHRoZSBBQ0sgZm9yIHRoYXQgbGFzdCBleGNoYW5nZS4gRm9yIHRoYXQgcmVhc29u LCB3aW5xdWljIGFsd2F5cyBlbmNvZGVzIGl0cyBsYXRlc3QgQUNLIHN0YXRlIHdpdGggKGFsd2F5 cyBmcmFtZXMgYmVmb3JlKSB0aGUgQ09OTkVDVElPTl9DTE9TRSBmcmFtZS4gVGhpcyBkb2VzbuKA mXQgaW5jcmVhc2UgdGhlIHNpemUgb2YgdGhlIHBhY2tldCBtdWNoLCBhbmQgaXTigJlzIHVwIHRv IHRoZSByZWNlaXZlciBpZiB0aGV5IHdhbnQgdG8gcHJvY2VzcyB0aGUgQUNLcyBvciBub3Q7IGJ1 dCBpdCBoZWxwcyB0aGVzZSBraW5kIG9mIHNjZW5hcmlvcy4NCg0KQSBzaW1wbGUgZXhhbXBsZSB0 ZXN0IGNhc2U6DQoNCkNsaWVudDogT3BlbiBvbmUgYmlkaXJlY3Rpb25hbCBzdHJlYW0sIHNlbmQg ZGF0YSBvbiBpdCwgRklOIGl0LCBhbmQgdmVyaWZ5IHRoZSBwZWVyIGRvZXMgdGhlIHNhbWUuIFRo ZW4gY2xvc2UgdGhlIGNvbm5lY3Rpb24uDQpTZXJ2ZXI6IEFjY2VwdCBvbmUgYmlkaXJlY3Rpb25h bCBzdHJlYW0sIHJlY2VpdmUgYWxsIGRhdGEgb24gaXQgYW5kIGVjaG8gaXQgYmFjay4gVmVyaWZ5 IGFsbCBkYXRhIGlzIHNlbnQgc3VjY2Vzc2Z1bGx5Lg0KDQpUaGUg4oCcVmVyaWZ5IGFsbCBkYXRh IGlzIHNlbnQgc3VjY2Vzc2Z1bGx54oCdIGZhaWxzIGlmIHlvdSBkb27igJl0IHNlbmQgQUNLcyB3 aXRoIENPTk5FQ1RJT05fQ0xPU0UuIFNvLCBJIHBlcnNvbmFsbHkgdGhpbmsgaXTigJlzIGEgZ29v ZCBpZGVhIHRvIHJlY29tbWVuZCBpbmNsdWRpbmcgQUNLcy4gSSBrbm93IGl0IGRvZXNu4oCZdCBw cm92aWRlIGFueSBndWFyYW50ZWVzIGluIHRoZSBwcmVzZW5jZSBvZiBwYWNrZXQgbG9zcywgc28g aWRlYWxseSB5b3UgZG9u4oCZdCBkZXNpZ24gYW4gYXBwIHByb3RvY29sIG9uIHRvcCBvZiB0aGlz LCBidXQgaXQgZG9lcyBtYWtlIHRoaW5ncyBhIGxpdHRsZSBuaWNlciwgSU1PLg0KDQpUaGFuaywN Ci0gTmljaw0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6IFdlZG5lc2Rh eSwgSnVuZSA1LCAyMDE5IDY6NDggQU0NClRvOiBKaXVoYWkgWmhhbmcgPGppdWhhaS56aGFuZ0Bn bWFpbC5jb208bWFpbHRvOmppdWhhaS56aGFuZ0BnbWFpbC5jb20+Pg0KQ2M6IElFVEYgUVVJQyBX RyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogSXMg Q09OTkVDVElPTl9DTE9TRSBmcmFtZSBBY2stZWxpY2l0aW5n77yfDQoNClRlY2huaWNhbGx5LCB5 ZXMuICBCdXQgY29ubmVjdGlvbnMgZG9uJ3Qgc2VuZCBhbnkgcGFja2V0cyBhZnRlciBwcm9jZXNz aW5nIGEgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSwgc28geW91IHdvdWxkIG5ldmVyIHJlY2VpdmUg YW5kIEFDSyBmb3IgaXQuDQoNCkZyb206IGh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwvZHJh ZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMCNzZWN0aW9uLTEwLjE8aHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0 Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yMCUyM3NlY3Rpb24tMTAu MSZkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3Q2IwYjE1MTE4Yjc2YTRi YzZiMDZlMDhkNmU5ZDI3ZGYzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjk1MzQ4NzYwMjMzMjc2NSZzZGF0YT1JaG12RU9aUkJKZiUyRkQ3eTVlNUZaUzBz TzZ5cWU5WnR1Mm5LNyUyRlVwM3ZvVSUzRCZyZXNlcnZlZD0wPg0KIlRoZSBkcmFpbmluZyBzdGF0 ZSBpcyBlbnRlcmVkIG9uY2UgYW4gZW5kcG9pbnQgcmVjZWl2ZXMgYSBzaWduYWwgdGhhdA0KICAg aXRzIHBlZXIgaXMgY2xvc2luZyBvciBkcmFpbmluZy4gIFdoaWxlIG90aGVyd2lzZSBpZGVudGlj YWwgdG8gdGhlDQogICBjbG9zaW5nIHN0YXRlLCBhbiBlbmRwb2ludCBpbiB0aGUgZHJhaW5pbmcg c3RhdGUgTVVTVCBOT1Qgc2VuZCBhbnkNCiAgIHBhY2tldHMuICBSZXRhaW5pbmcgcGFja2V0IHBy b3RlY3Rpb24ga2V5cyBpcyB1bm5lY2Vzc2FyeSBvbmNlIGENCiAgIGNvbm5lY3Rpb24gaXMgaW4g dGhlIGRyYWluaW5nIHN0YXRlLiINCg0KT24gV2VkLCBKdW4gNSwgMjAxOSBhdCA4OjA0IEFNIEpp dWhhaSBaaGFuZyA8aml1aGFpLnpoYW5nQGdtYWlsLmNvbTxtYWlsdG86aml1aGFpLnpoYW5nQGdt YWlsLmNvbT4+IHdyb3RlOg0KSW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtcXVpYy1yZWNvdmVyeS0yMCNzZWN0aW9uLTI8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZo dG1sJTJGZHJhZnQtaWV0Zi1xdWljLXJlY292ZXJ5LTIwJTIzc2VjdGlvbi0yJmRhdGE9MDIlN0Mw MSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDYjBiMTUxMThiNzZhNGJjNmIwNmUwOGQ2ZTlk MjdkZjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTUz NDg3NjAyMzQyNzYyJnNkYXRhPXRZSUQ4bHFtSDJEVnBPam0wN3BtU0N5S09PQmxCRERpamxUbThG TFEyRzAlM0QmcmVzZXJ2ZWQ9MD4NCg0KQWNrLWVsaWNpdGluZyBGcmFtZXM6ICBBbGwgZnJhbWVz IGJlc2lkZXMgQUNLIG9yIFBBRERJTkcgYXJlDQoNCiAgICAgIGNvbnNpZGVyZWQgYWNrLWVsaWNp dGluZy4NCg0KDQoNCklzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUgQWNrLWVsaWNpdGluZ++8nw0K DQpTaG91bGQgZW5kcG9pbnQgcmVzcG9uZHMgYSBBQ0sgZnJhbWUgd2hlbiByZWNlaXZpbmcgYSBD T05ORUNUSU9OX0NMT1NFIGZyYW1l77yfDQo= --_000_BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160BL0PR2101MB1043_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3 IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbTM0MjM1NTMxMzg1MzA3 MzY5NTNnbWFpbC1tLTMwMjk2NDE5NTgzNjQ0OTI1NzNnbWFpbC1tMjE1MDEzNjI3MTUxOTAwMDE2 NmFpcm1haWxvbiwgbGkuZ21haWwtbTM0MjM1NTMxMzg1MzA3MzY5NTNnbWFpbC1tLTMwMjk2NDE5 NTgzNjQ0OTI1NzNnbWFpbC1tMjE1MDEzNjI3MTUxOTAwMDE2NmFpcm1haWxvbiwgZGl2LmdtYWls LW0zNDIzNTUzMTM4NTMwNzM2OTUzZ21haWwtbS0zMDI5NjQxOTU4MzY0NDkyNTczZ21haWwtbTIx NTAxMzYyNzE1MTkwMDAxNjZhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8zNDIz NTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAyOTY0MTk1ODM2NDQ5MjU3M2dtYWlsLW1fMjE1MDEz NjI3MTUxOTAwMDE2NmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgbm8gYWJzb2x1dGUgcmVxdWlyZW1lbnQgdGhhdCB5 b3UgbWFpbnRhaW4gdGhlIG1pbmltYWwgc3RhdGUgdG8gZ2VuZXJhdGUgdGhlIENPTk5FQ1RJT05f Q0xPU0UuIFBlcnNvbmFsbHksIEkgZmVlbCBhIE1BWSBpcyBtaXNzaW5nIGluIHRoYXQgc2VudGVu Y2UuIEFkZGl0aW9uYWxseSwgSSBmZWVsIHRoYXQgYW4gZW5kcG9pbnQgU0hPVUxEIChub3QgYSBN VVNUIGJlY2F1c2UgaXTigJlzIHVuZW5mb3JjZWFibGUpDQogcmVzcG9uZCB3aXRoIGFuIGltbWVk aWF0ZSBDT05ORUNUSU9OX0NMT1NFIG9mIGl0cyBvd24sIHNvIHRoZSBwZWVyIGNhbiB1c2UgdGhh dCBhcyBhIHNpZ25hbCBvZiBhY2tub3dsZWRnZW1lbnQgYW5kIGltbWVkaWF0ZWx5IGdvIGF3YXks IHdpdGhvdXQgd2FpdGluZyB0aGUgZnVsbCBkcmFpbmluZyBwZXJpb2QuIEJ1dCwgSSBrbm93IEni gJltIG5vdCBpbiB0aGUgbWFqb3JpdHkgd2l0aCB0aGF0IG9waW5pb24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIHRoZSB0b3BpYyBvZiBzZW5kaW5nIEFDS3Mgd2l0aCBDT05ORUNUSU9OX0NM T1NFLCBJIGFtIG1vcmUgcmVmZXJyaW5nIHRvIGJ1bmRsaW5nIEFDS3Mgd2l0aCB0aGUNCjxiPmlu aXRpYWw8L2I+IENPTk5FQ1RJT05fQ0xPU0UuIEkgYWdyZWUsIHRoYXQgc2VuZGluZyBBQ0tzIHdp dGggdGhlIHJlc3BvbmRpbmcgQ09OTkVDVElPTl9DTE9TRSBkb2VzbuKAmXQgZG8gbXVjaC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBOaWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBNYXJ0ZW4gU2VlbWFubiAmbHQ7bWFydGVuc2VlbWFubkBnbWFpbC5jb20mZ3Q7IDxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUgNSwgMjAxOSA5OjI2IEFNPGJyPg0KPGI+ VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7 OyBOaWNrIEJhbmtzICZsdDtuaWJhbmtzQG1pY3Jvc29mdC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBKaXVoYWkgWmhhbmcgJmx0O2ppdWhhaS56aGFuZ0BnbWFp bC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJcyBDT05ORUNUSU9OX0NMT1NFIGZy YW1lIEFjay1lbGljaXRpbmc8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj JnF1b3Q7Ij7vvJ88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBkb2Vz bid0IHJlYWxseSBtYWtlIHNlbnNlIHRvIHNlbmQgYSBDT05ORUNUSU9OX0NMT1NFIGZyYW1lIGlu IHJlc3BvbnNlIHRvIGEgQ09OTkVDVElPTl9DTE9TRSwgc2luY2UgaW4gdGhlIGNsb3Npbmcgc3Rh dGUgYW4gZW5kcG9pbnQgcmV0YWlucyAmcXVvdDtvbmx5IGVub3VnaCBpbmZvcm1hdGlvbiB0byBn ZW5lcmF0ZSBhIHBhY2tldCBjb250YWluaW5nIGEgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBhbmQg dG8gaWRlbnRpZnkNCiBwYWNrZXRzIGFzIGJlbG9uZ2luZyB0byB0aGUgY29ubmVjdGlvbiZxdW90 OywgaS5lLiBhbiBlbmRwb2ludCB3b24ndCBldmVuIG9wZW4gdGhlIHBhY2tldCAoYnV0IGl0IG1p Z2h0IHJlcGx5IHdpdGggYW5vdGhlciBDT05ORUNUSU9OX0NMT1NFKS48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UsIGFuZCBlbmRwb2ludCBjYW4g c2VuZCBhcyBtYW55IHBhY2tldHMgYWZ0ZXIgdGhpcyBhcyBpdCB3YW50cyAodGhlcmUncyBubyB3 YXkgaXQgY291bGQgYmUgcGVuYWxpemVkIGZvciBtaXNiZWhhdmluZyksIGFsdGhvdWdoIEknbSBu b3Qgc3VyZSB3aHkgd2UncmUgZXhwbGljaXRseSBhbGxvd2luZyBzZW5kaW5nIENPTk5FQ1RJT05f Q0xPU0UgYXMgYSByZXNwb25zZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkknbSBub3QgcmVhbGx5IHN1cmUgd2hhdCB0aGUgYmVuZWZpdCBpcyBvZiBzZW5k aW5nIGFuIEFDSyBmcmFtZSBidW5kbGVkIHdpdGggYSBDT05ORUNUSU9OX0NMT1NFLiBUaGVyZSdz IG5vdGhpbmcgdGhlIHJlY2VpdmluZyBwZWVyIGNhbiBkbyBpbiByZWFjdGlvbiB0byByZWNlaXZp bmcgdGhhdCBBQ0sgLSB0aGUgY29ubmVjdGlvbiBpcyBhbHJlYWR5IGNsb3NlZC4gRnVydGhlcm1v cmUsIGl0IHdvdWxkIGJlIHdyb25nDQogdG8gY29uY2x1ZGUgdGhhdCBhbGwgc3RyZWFtIGRhdGEg aGFzIGJlZW4gcHJvY2Vzc2VkIGJ5IHRoZSBhcHBsaWNhdGlvbi4gQW4gQUNLIGZvciBhIFNUUkVB TSBmcmFtZSBvbmx5IG1lYW5zIHRoYXQgdGhlIFNUUkVBTSBmcmFtZSB3YXMgcHJvY2Vzc2VkIGJ5 IHRoZSBRVUlDIHN0YWNrLCBub3QgYnkgdGhlIGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVu IDYsIDIwMTkgYXQgMTI6MDMgQU0gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMzQyMzU1MzEzODUzMDczNjk1M2dtYWlsLW1fLTMw Mjk2NDE5NTgzNjQ0OTI1NzNibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjEwLjM6ICZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkFmdGVyIHJlY2Vp dmluZyBhIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUsIGVuZHBvaW50cyBlbnRlciB0aGUgZHJhaW5p bmcgc3RhdGUuIEFuIGVuZHBvaW50IHRoYXQgcmVjZWl2ZXMgYSBDT05ORUNUSU9OX0NMT1NFIGZy YW1lIE1BWSBzZW5kIGEgc2luZ2xlIHBhY2tldA0KIGNvbnRhaW5pbmcgYSBDT05ORUNUSU9OX0NM T1NFIGZyYW1lIGJlZm9yZSBlbnRlcmluZyB0aGUgZHJhaW5pbmcgc3RhdGUsIHVzaW5nIGEgQ09O TkVDVElPTl9DTE9TRSBmcmFtZSBhbmQgYSBOT19FUlJPUiBjb2RlIGlmIGFwcHJvcHJpYXRlLiZx dW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8zNDIz NTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAyOTY0MTk1ODM2NDQ5MjU3M2Jsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8z NDIzNTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAyOTY0MTk1ODM2NDQ5MjU3M2Jsb29wX3NpZ25f MTU1OTc1MDQzNzQxNDIxMjg2NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPk9uIDUgSnVuZSAyMDE5IGF0IDE3LjU4LjE5LCBJYW4gU3dldHQgKDxhIGhy ZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRA Z29vZ2xlLmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5pY2ssIEkg YWdyZWUgdGhhdCBidW5kbGluZyBhbiBBQ0sgd2l0aCBhIENPTk5FQ1RJT05fQ0xPU0UgaXMgdXNl ZnVsLCBhbmQgb3VyIGltcGxlbWVudGF0aW9uIGRvZXMgdGhhdCBhcyB3ZWxsLg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyLCBpdCBzZWVtcyBs aWtlIHRoZSBleGlzdGluZyB0ZXh0IGluZGljYXRlcyB5b3UnZCBuZXZlciBleHBlY3QgdG8gZ2V0 IGEgQ09OTkVDVElPTl9DTE9TRSBpbiByZXNwb25zZSB0byBhIENPTk5FQ1RJT05fQ0xPU0U/Jm5i c3A7IE9yIGFtIEkgbWlzcmVhZGluZyB0aGUgdGV4dCBhYm91dCBkcmFpbmluZz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdW4g NSwgMjAxOSBhdCAxMDowOCBBTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVm PSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8zNDIzNTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAy OTY0MTk1ODM2NDQ5MjU3M2dtYWlsLW1fMjE1MDEzNjI3MTUxOTAwMDE2NmJsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkNPTk5FQ1RJT05fQ0xPU0UgY2FuIGJlIHJlc3BvbnNlIHRvIENPTk5FQ1RJT05fQ0xPU0UgYW5k IHRoYXQgcmVzcG9uc2UgY2FuIGNvbnRhaW4gb3RoZXIgZnJhbWVzLi4gU28gdGVjaG5pY2FsbHkg eW91IGNhbiBBQ0sgYSBjb25uZWN0aW9uIGNsb3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8zNDIzNTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAyOTY0 MTk1ODM2NDQ5MjU3M2dtYWlsLW1fMjE1MDEzNjI3MTUxOTAwMDE2NmJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8zNDIz NTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAyOTY0MTk1ODM2NDQ5MjU3M2dtYWlsLW1fMjE1MDEz NjI3MTUxOTAwMDE2NmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRvaW5nIHNvIG1pZ2h0IGFjdHVhbGx5IG1ha2Ug c2Vuc2UgaWYgdGhlIG9yaWdpbmFsIGNsb3NlciB0YWtlIHRoYXQgYXMgYSBzaWduYWwgdG8gZHJh aW4gZmFzdGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwt bV8zNDIzNTUzMTM4NTMwNzM2OTUzZ21haWwtbV8tMzAyOTY0MTk1ODM2NDQ5MjU3M2dtYWlsLW1f MjE1MDEzNjI3MTUxOTAwMDE2NmJsb29wX3NpZ25fMTU1OTc0MzUyODQzMjMyNzkzNiI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tMzQyMzU1MzEzODUzMDczNjk1M2dt YWlsLW0tMzAyOTY0MTk1ODM2NDQ5MjU3M2dtYWlsLW0yMTUwMTM2MjcxNTE5MDAwMTY2YWlybWFp bG9uIj4NCk9uIDUgSnVuZSAyMDE5IGF0IDE2LjAwLjE2LCBOaWNrIEJhbmtzICg8YSBocmVmPSJt YWlsdG86bmliYW5rcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5uaWJhbmtzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4pIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPklhbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBlbmNvdW50ZXJlZCBp c3N1ZXMgYm90aCBpbiBsb2NhbCBhdXRvbWF0ZWQgdGVzdHMgYW5kIGR1cmluZyBpbnRlcm9wLCB3 aGVyZSBvbmUgc2lkZSBnZXRzIGV2ZXJ5dGhpbmcgaXQgd2FudHMgYW5kIHRoZW4gY2xlYW5seSBj bG9zZXMgdGhlIGNvbm5lY3Rpb24uIFRoZSBpc3N1ZXMgYXJpc2UgYmVjYXVzZQ0KIHRoZSBwZWVy IGhhc27igJl0IHJlY2VpdmVkIHRoZSBBQ0sgZm9yIHRoYXQgbGFzdCBleGNoYW5nZS4gRm9yIHRo YXQgcmVhc29uLCB3aW5xdWljIGFsd2F5cyBlbmNvZGVzIGl0cyBsYXRlc3QgQUNLIHN0YXRlIHdp dGggKGFsd2F5cyBmcmFtZXMgYmVmb3JlKSB0aGUgQ09OTkVDVElPTl9DTE9TRSBmcmFtZS4gVGhp cyBkb2VzbuKAmXQgaW5jcmVhc2UgdGhlIHNpemUgb2YgdGhlIHBhY2tldCBtdWNoLCBhbmQgaXTi gJlzIHVwIHRvIHRoZSByZWNlaXZlciBpZg0KIHRoZXkgd2FudCB0byBwcm9jZXNzIHRoZSBBQ0tz IG9yIG5vdDsgYnV0IGl0IGhlbHBzIHRoZXNlIGtpbmQgb2Ygc2NlbmFyaW9zLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QSBzaW1wbGUgZXhhbXBsZSB0ZXN0IGNhc2U6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5DbGllbnQ6IE9wZW4gb25lIGJpZGlyZWN0aW9uYWwgc3RyZWFtLCBz ZW5kIGRhdGEgb24gaXQsIEZJTiBpdCwgYW5kIHZlcmlmeSB0aGUgcGVlciBkb2VzIHRoZSBzYW1l LiBUaGVuIGNsb3NlIHRoZSBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5TZXJ2ZXI6IEFjY2VwdCBvbmUgYmlkaXJlY3Rpb25hbCBzdHJlYW0sIHJlY2Vp dmUgYWxsIGRhdGEgb24gaXQgYW5kIGVjaG8gaXQgYmFjay4gVmVyaWZ5IGFsbCBkYXRhIGlzIHNl bnQgc3VjY2Vzc2Z1bGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIOKAnFZlcmlm eSBhbGwgZGF0YSBpcyBzZW50IHN1Y2Nlc3NmdWxseeKAnSBmYWlscyBpZiB5b3UgZG9u4oCZdCBz ZW5kIEFDS3Mgd2l0aCBDT05ORUNUSU9OX0NMT1NFLiBTbywgSSBwZXJzb25hbGx5IHRoaW5rIGl0 4oCZcyBhIGdvb2QgaWRlYSB0byByZWNvbW1lbmQgaW5jbHVkaW5nIEFDS3MuIEkga25vdyBpdCBk b2VzbuKAmXQNCiBwcm92aWRlIGFueSBndWFyYW50ZWVzIGluIHRoZSBwcmVzZW5jZSBvZiBwYWNr ZXQgbG9zcywgc28gaWRlYWxseSB5b3UgZG9u4oCZdCBkZXNpZ24gYW4gYXBwIHByb3RvY29sIG9u IHRvcCBvZiB0aGlzLCBidXQgaXQgZG9lcyBtYWtlIHRoaW5ncyBhIGxpdHRsZSBuaWNlciwgSU1P LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmssPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0gTmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ RnJvbTo8L2I+IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVo YWxmIE9mPC9iPiBJYW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDUs IDIwMTkgNjo0OCBBTTxicj4NCjxiPlRvOjwvYj4gSml1aGFpIFpoYW5nICZsdDs8YSBocmVmPSJt YWlsdG86aml1aGFpLnpoYW5nQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmppdWhhaS56aGFu Z0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSXMgQ09OTkVDVElPTl9DTE9TRSBmcmFt ZSBBY2stZWxpY2l0aW5nPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90OyI+77yfPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRlY2hu aWNhbGx5LCB5ZXMuJm5ic3A7IEJ1dCBjb25uZWN0aW9ucyBkb24ndCBzZW5kIGFueSBwYWNrZXRz IGFmdGVyIHByb2Nlc3NpbmcgYSBDT05ORUNUSU9OX0NMT1NFIGZyYW1lLCBzbyB5b3Ugd291bGQg bmV2ZXIgcmVjZWl2ZSBhbmQgQUNLIGZvciBpdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gcm9tOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xz LmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMjAlMjNzZWN0aW9u LTEwLjEmYW1wO2RhdGE9MDIlN0MwMSU3Q25pYmFua3MlNDBtaWNyb3NvZnQuY29tJTdDYjBiMTUx MThiNzZhNGJjNmIwNmUwOGQ2ZTlkMjdkZjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2OTUzNDg3NjAyMzMyNzY1JmFtcDtzZGF0YT1JaG12RU9aUkJKZiUy RkQ3eTVlNUZaUzBzTzZ5cWU5WnR1Mm5LNyUyRlVwM3ZvVSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi4ub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWlj LXRyYW5zcG9ydC0yMCNzZWN0aW9uLTEwLjE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O1RoZSBkcmFpbmluZyBzdGF0ZSBpcyBl bnRlcmVkIG9uY2UgYW4gZW5kcG9pbnQgcmVjZWl2ZXMgYSBzaWduYWwgdGhhdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtpdHMgcGVl ciBpcyBjbG9zaW5nIG9yIGRyYWluaW5nLiZuYnNwOyBXaGlsZSBvdGhlcndpc2UgaWRlbnRpY2Fs IHRvIHRoZTxicj4NCiZuYnNwOyAmbmJzcDtjbG9zaW5nIHN0YXRlLCBhbiBlbmRwb2ludCBpbiB0 aGUgZHJhaW5pbmcgc3RhdGUgTVVTVCBOT1Qgc2VuZCBhbnk8YnI+DQombmJzcDsgJm5ic3A7cGFj a2V0cy4mbmJzcDsgUmV0YWluaW5nIHBhY2tldCBwcm90ZWN0aW9uIGtleXMgaXMgdW5uZWNlc3Nh cnkgb25jZSBhPGJyPg0KJm5ic3A7ICZuYnNwO2Nvbm5lY3Rpb24gaXMgaW4gdGhlIGRyYWluaW5n IHN0YXRlLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFdlZCwgSnVuIDUsIDIwMTkgYXQgODowNCBBTSBKaXVoYWkgWmhhbmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpqaXVoYWkuemhhbmdAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aml1 aGFpLnpoYW5nQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtcXVpYy1yZWNvdmVy eS0yMCUyM3NlY3Rpb24tMiZhbXA7ZGF0YT0wMiU3QzAxJTdDbmliYW5rcyU0MG1pY3Jvc29mdC5j b20lN0NiMGIxNTExOGI3NmE0YmM2YjA2ZTA4ZDZlOWQyN2RmMyU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5NTM0ODc2MDIzNDI3NjImYW1wO3NkYXRhPXRZ SUQ4bHFtSDJEVnBPam0wN3BtU0N5S09PQmxCRERpamxUbThGTFEyRzAlM0QmYW1wO3Jlc2VydmVk PTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1xdWljLXJlY292ZXJ5LTIwI3NlY3Rpb24tMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkFjay1lbGljaXRpbmcgRnJhbWVzOiZuYnNwOyBBbGwgZnJhbWVzIGJlc2lkZXMgQUNL IG9yIFBBRERJTkcgYXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyZWQg YWNrLWVsaWNpdGluZy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFr LWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPklzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUgQWNrLWVsaWNpdGluZzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNr Ij7vvJ88L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpw YWdlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNob3VsZCBlbmRwb2ludCByZXNwb25kcyBh IEFDSyBmcmFtZSB3aGVuIHJlY2VpdmluZyBhIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWU8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFj ayI+77yfPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BL0PR2101MB1043C760EB1C7C7BB0AE4374B3160BL0PR2101MB1043_-- From nobody Wed Jun 5 09:38:42 2019 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 A042C120234 for ; Wed, 5 Jun 2019 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.519 X-Spam-Level: X-Spam-Status: No, score=-15.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt5galloEvnE for ; Wed, 5 Jun 2019 09:38:36 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 4BF2412012C for ; Wed, 5 Jun 2019 09:38:36 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id u8so1309168wmm.1 for ; Wed, 05 Jun 2019 09:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JUPD9W6JoPD29sCFRmv9mSp98P/BVAuZJ8RSQmjzV8c=; b=ImqYyeKQ+yYCfIFu6o+QU1+XpKI+XqcLAOBy0uh8IMyqgfxpVna1vhNRPSux+2kbed EBHt3DFVcWM1lyhwoADNzuj7tKETvYnFPHz4ziLsAxIAdRC4js8fGMzh7gYY2Jat+YlI q/yynQvo0LKKRDibGX742EujY9sr8SF2W8sAiRGuKW0Ntwh0+W4wdg/89EtbnzpbfRdV +6+1r7UlZ007qOmjx5RC4GW7qjEVjIzPkuv6SOdoi84EhddLIqnlQd2nL1vzp5uyDvSV gJ5V7zt1lPR659iZBDIEgqZgedZw2i6E+VkjP6Ye4E9u6P1oXsoFxur7qOXm41tCtX5c oiJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JUPD9W6JoPD29sCFRmv9mSp98P/BVAuZJ8RSQmjzV8c=; b=k9DuOqqq9eTDb2L9Kogmumgifnr2xH4lHTz+jlXl2C2OyJhPTaZaEL/Hy3TyFjeE8p 7rnlpAOQsQHC1O2JlvFU3CY8kGr5gK9LD6XRPUHSMuHagxDMUnVsrBIszTXJJjNyTmj8 /4eKiW9ctb1RLwfixmwcPzYrzpu8LmSnlNWgjcfXQH9V0CYskCvO1riIW0Z69hHEsKbh ZZfdYeGGCRIogNlvhwI2Ba1Ql7m92153iMZHmMm+l/rU5eq9k/2G0OL+H7jCpLVeu/84 G63swwRItuI4IsTTxx8G9hoctva2ZVsc9+iJ2l425dKUDV66GwUoOs9XgO8dFDoLvaix YIsA== X-Gm-Message-State: APjAAAVPaDpJVXsFFVyjKuphsMQ9fX0RlH0cT2mrvMTEPo0NQzdIAMrt BJaIWktbkzS0z3hk6JMh55wSJPB6yGwiuI9zZGO0Kw== X-Google-Smtp-Source: APXvYqwGNzbCHp7ux9vBk+hqtgz9DXGSGWnmMliUVXhyWr+zi7lPcOYJ/AgDSakwO0nbwVSrc9DNegaOP76CO3Cn6vs= X-Received: by 2002:a1c:b757:: with SMTP id h84mr18608166wmf.127.1559752714356; Wed, 05 Jun 2019 09:38:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 5 Jun 2019 12:38:21 -0400 Message-ID: Subject: =?UTF-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack=2Deliciting=EF=BC=9F?= To: Marten Seemann Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Nick Banks , IETF QUIC WG , Jiuhai Zhang Content-Type: multipart/alternative; boundary="0000000000007ab2db058a963a92" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 16:38:41 -0000 --0000000000007ab2db058a963a92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the past, having an ACK bundled with CONNECTION_CLOSE has been useful to debug what the peer did and did not receive as of the end of the connection= . Agreed on sending CONNECTION_CLOSE in response to CONNECTION_CLOSE being mostly useless. I believe some wanted to allow it because if they received a CONNECTION_CLOSE in response to their CONNECTION_CLOSE, they could remove all state for the connection, including the saved CONNECTION_CLOSE packet? On Wed, Jun 5, 2019 at 12:25 PM Marten Seemann wrote: > It doesn't really make sense to send a CONNECTION_CLOSE frame in response > to a CONNECTION_CLOSE, since in the closing state an endpoint retains "on= ly > enough information to generate a packet containing a CONNECTION_CLOSE fra= me > and to identify packets as belonging to the connection", i.e. an endpoint > won't even open the packet (but it might reply with another > CONNECTION_CLOSE). > Of course, and endpoint can send as many packets after this as it wants > (there's no way it could be penalized for misbehaving), although I'm not > sure why we're explicitly allowing sending CONNECTION_CLOSE as a response= . > > I'm not really sure what the benefit is of sending an ACK frame bundled > with a CONNECTION_CLOSE. There's nothing the receiving peer can do in > reaction to receiving that ACK - the connection is already closed. > Furthermore, it would be wrong to conclude that all stream data has been > processed by the application. An ACK for a STREAM frame only means that t= he > STREAM frame was processed by the QUIC stack, not by the application. > > On Thu, Jun 6, 2019 at 12:03 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> 10.3: "After receiving a CONNECTION_CLOSE frame, endpoints enter the >> draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY s= end >> a single packet containing a CONNECTION_CLOSE frame before entering the >> draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if >> appropriate." >> >> On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com) wrote: >> >> Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, an= d >> our implementation does that as well. >> >> However, it seems like the existing text indicates you'd never expect to >> get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE? Or am I >> misreading the text about draining? >> >> On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < >> mikkelfj@gmail.com> wrote: >> >>> CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response >>> can contain other frames.. So technically you can ACK a connection clos= e. >>> >>> Doing so might actually make sense if the original closer take that as = a >>> signal to drain faster. >>> >>> >>> On 5 June 2019 at 16.00.16, Nick Banks ( >>> nibanks=3D40microsoft.com@dmarc.ietf.org) wrote: >>> >>> Ian, >>> >>> >>> >>> I have encountered issues both in local automated tests and during >>> interop, where one side gets everything it wants and then cleanly close= s >>> the connection. The issues arise because the peer hasn=E2=80=99t receiv= ed the ACK >>> for that last exchange. For that reason, winquic always encodes its lat= est >>> ACK state with (always frames before) the CONNECTION_CLOSE frame. This >>> doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s = up to the receiver >>> if they want to process the ACKs or not; but it helps these kind of >>> scenarios. >>> >>> >>> >>> A simple example test case: >>> >>> >>> >>> Client: Open one bidirectional stream, send data on it, FIN it, and >>> verify the peer does the same. Then close the connection. >>> >>> Server: Accept one bidirectional stream, receive all data on it and ech= o >>> it back. Verify all data is sent successfully. >>> >>> >>> >>> The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you= don=E2=80=99t send ACKs >>> with CONNECTION_CLOSE. So, I personally think it=E2=80=99s a good idea = to recommend >>> including ACKs. I know it doesn=E2=80=99t provide any guarantees in the= presence of >>> packet loss, so ideally you don=E2=80=99t design an app protocol on top= of this, >>> but it does make things a little nicer, IMO. >>> >>> >>> >>> Thank, >>> >>> - Nick >>> >>> >>> >>> *From:* QUIC *On Behalf Of* Ian Swett >>> *Sent:* Wednesday, June 5, 2019 6:48 AM >>> *To:* Jiuhai Zhang >>> *Cc:* IETF QUIC WG >>> *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F >>> >>> >>> >>> Technically, yes. But connections don't send any packets after >>> processing a CONNECTION_CLOSE frame, so you would never receive and ACK= for >>> it. >>> >>> >>> >>> From: >>> https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1 >>> >>> >>> "The draining state is entered once an endpoint receives a signal that >>> >>> its peer is closing or draining. While otherwise identical to the >>> closing state, an endpoint in the draining state MUST NOT send any >>> packets. Retaining packet protection keys is unnecessary once a >>> connection is in the draining state." >>> >>> >>> >>> On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang >>> wrote: >>> >>> In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2 >>> >>> >>> Ack-eliciting Frames: All frames besides ACK or PADDING are >>> >>> considered ack-eliciting. >>> >>> Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F >>> >>> Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE = frame=EF=BC=9F >>> >>> --0000000000007ab2db058a963a92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the past, having an ACK bundled with CONNECTION_CLOSE h= as been useful to debug what the peer did and did not receive as of the end= of the connection.

Agreed on sending CONNECTION_CLOSE i= n response to CONNECTION_CLOSE being mostly useless.=C2=A0 I believe some w= anted to allow it because if they received a CONNECTION_CLOSE in response t= o their CONNECTION_CLOSE, they could remove all state for the connection, i= ncluding the saved CONNECTION_CLOSE packet?

On Wed, Jun 5, 2019 at 12:= 25 PM Marten Seemann <martens= eemann@gmail.com> wrote:
It doesn't really make sense to send a= CONNECTION_CLOSE frame in response to a CONNECTION_CLOSE, since in the clo= sing state an endpoint retains "only enough information to generate a = packet containing a CONNECTION_CLOSE frame and to identify packets as belon= ging to the connection", i.e. an endpoint won't even open the pack= et (but it might reply with another CONNECTION_CLOSE).
Of course, and e= ndpoint can send as many packets after this as it wants (there's no way= it could be penalized for misbehaving), although I'm not sure why we&#= 39;re explicitly allowing sending CONNECTION_CLOSE as a response.

<= /div>
I'm not really sure what the benefit is of sending an ACK fra= me bundled with a CONNECTION_CLOSE. There's nothing the receiving peer = can do in reaction to receiving that ACK - the connection is already closed= . Furthermore, it would be wrong to conclude that all stream data has been = processed by the application. An ACK for a STREAM frame only means that the= STREAM frame was processed by the QUIC stack, not by the application.

On Thu, Jun 6, 2019 at 12:03 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen &l= t;mikkelfj@gmail.co= m> wrote:
10.3: "= ;After re= ceiving a CONNECTION_CLOSE frame, endpoints enter the draining state. An en= dpoint that receives a CONNECTION_CLOSE frame MAY send a single packet cont= aining a CONNECTION_CLOSE frame before entering the draining state, using a= CONNECTION_CLOSE frame and a NO_ERROR code if appropriate."

On 5 June 2019 at 17.58.19, Ian Swett (ianswett@google.com) wro= te:
Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and our implementation does that as well.

However, it seems like the existing text indicates you'd never expect to get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?=C2=A0 Or am I misreading the text about draining?

On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can contain other frames.. So technically you can ACK a connection close.

Doing so might actually make sense if the original closer take that as a signal to drain faster.


On 5 June 2019 a= t 16.00.16, Nick Banks (nibanks=3D40microsoft.com@dmarc.ietf.org) wrot= e:

Ian,

=C2=A0

I have encountered issues both in local automated tests and during interop, where one side gets everything it wants and then cleanly closes the connection. The issues arise because the peer hasn=E2=80=99t received the ACK for that last exchange. For that reason, winquic always encodes its latest ACK state with (always frames before) the CONNECTION_CLOSE frame. This doesn=E2=80=99t increase the size of the packet much, and it=E2=80=99s up to the receiver if they want to process the ACKs or not; but it helps these kind of scenarios.

=C2=A0

A simple example test case:

=C2=A0

Client: Open one bidirectional stream, send data on it, FIN it, and verify the peer does the same. Then close the connection.

Server: Accept one bidirectional stream, receive all data on it and echo it back. Verify all data is sent successfully.

=C2=A0

The =E2=80=9CVerify all data is sent successfully=E2=80=9D fails if you don=E2=80=99t send ACKs with CONNECTION_= CLOSE. So, I personally think it=E2=80=99s a good idea to recommend including ACKs. I know it doesn=E2=80=99t provide any guarantees in the presence of packet loss, so ideally you don=E2=80=99t design an app protocol on top of this, but it does make things a little nicer, IMO.

=C2=A0

Thank,

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Beha= lf Of Ian Swett
Sent: Wednesday, June 5, 2019 6:48 AM
To: Jiuhai Zhang <jiuhai.zhang@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Is CONNECTION_CLOSE frame Ack-eliciting=EF=BC=9F

=C2=A0

Technically, yes.=C2=A0 But connections don't send any packets after processing a CONNECTION_CLOSE frame, so you would never receive and ACK for it.

=C2=A0

"The draining state is entered once an endpoint receives a signal that

=C2=A0 =C2=A0its peer is closing or draining.=C2=A0 While otherwise identical to the
=C2=A0 =C2=A0closing state, an endpoint in the draining state MUST NOT send any
=C2=A0 =C2=A0packets.=C2=A0 Retaining packet protection keys is unnecessary once a
=C2=A0 =C2=A0connection is in the draining state."

=C2=A0

On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <jiuhai.zhan= g@gmail.com> wrote:

Ack-eliciting =
Frames:  All frames besides ACK or PADDING are
      considered ack-eliciting.

 


Is CONNECTION_=
CLOSE frame Ack-eliciting=EF=BC=9F


Should endpoin=
t responds a ACK frame when receiving a CONNECTION_CLOSE frame=EF=BC=9F
--0000000000007ab2db058a963a92-- From nobody Wed Jun 5 13:40:45 2019 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 BF024120159 for ; Wed, 5 Jun 2019 13:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 gUU7Q2zOnaun for ; Wed, 5 Jun 2019 13:40:42 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.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 0477412014B for ; Wed, 5 Jun 2019 13:40:41 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp06.mail2web.com) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hYci7-00058L-1o for quic@ietf.org; Wed, 05 Jun 2019 22:40:40 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hYci3-0001rh-Bh for quic@ietf.org; Wed, 05 Jun 2019 16:40:36 -0400 Received: (qmail 12168 invoked from network); 5 Jun 2019 20:40:34 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Jun 2019 20:40:33 -0000 To: Ian Swett , Marten Seemann Cc: Nick Banks , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , IETF QUIC WG , Jiuhai Zhang References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> Date: Wed, 5 Jun 2019 13:40:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: =?UTF-8?Q?Re=3a_Is_CONNECTION=5fCLOSE_frame_Ack-eliciting=ef=bc=9f?= X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0WF37iHSchYgKnNGmAxHYR+pSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftrR6Fyzsm2NAZtbXmwzXzM/sevPPdLVvjz7b14RFNIS75QzTLy/EjEcXZ5 IgaMYzlfZdf1siwYNJirk4ABKayR03+K7Ju/qxRhvHDAT5LyR61Qv/sjUDXLdm6w1gNv1euKTrwh UfUHUrPvTkTGu7YwVDQ0hbqcLWUbjgHMZS6COdI/uLAeALf3vLWnw0F/4+fmuTv/CYIzmchrGsA6 CN6O7qbWTdT56xh4Rya20+oBtwahqtg42IMQXC/e/thfmehs05Web8nJyEMtLxwhnYinDFrKlNc7 qNKmpnIY9d8cOJUa+B0z/Xg2ESGxDSOWWoTyIUtK8Miz//+1AD61I8sOcFFSGcngeU5u06zO01Ld 6NjlDHh8k6TTdHl8m1/8O//LcKgaYLn9Y2q9E0HrGD+jjSFzFGPNqtT/ZMOz6wxUehT6+eMIjyeL k8Nf0SfiCa+x5xMEOToeUkKHbFkPY7RXd9NKxBWsVxMktDIV0UvDQayp/agYZfrnDk8+IFUpab7m 9Ql4Ld7qe/xoNQPgy7UpxcIWHOi9y3yF+Ot2t6dhJc2bXYMFScrLivfWmWkJo22CHZOREywSBAd6 WuRFS3mxs3T2CPnVGlRvOomQUSscWtvymYfZ8O/Se8jQNEyEo8M8CVsONrMJuGzuoGnKTKcymM5H 5NK8ObCxL+Ab3gHeBGp1PWox/HcVwRsYfOuMC9EDvRTWmuYW5XPvbs91Tlwp9H4DectLaqn7kLkt Zo9lqwZlJF8UKGQcpLF8m4y5fNSIlEy3YgJZkOfaaqfw0pD+E4vXmYOrZ6ynPfzK8qbeqosYcSFD ZkSOre2YUe/WyPr4xM5tUrEfL92iWzfzWX2vJeNfaj+DKN82dVVpaMxSGA== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 20:40:44 -0000 On 6/5/2019 9:38 AM, Ian Swett wrote: > In the past, having an ACK bundled with CONNECTION_CLOSE has been > useful to debug what the peer did and did not receive as of the end of > the connection. > > Agreed on sending CONNECTION_CLOSE in response to CONNECTION_CLOSE > being mostly useless.=C2=A0 I believe some wanted to allow it because i= f > they received a CONNECTION_CLOSE in response to their > CONNECTION_CLOSE, they could remove all state for the connection, > including the saved CONNECTION_CLOSE packet? Most of the arguments I heard one way or the other are based on power management. Sending one more message requires waking up the radio, etc., which consumes significant power on a mobile device. Replying with a connection close allows the peer to immediately exit the waiting state, which might save some power -- but probably not as much as what is saved on the client with not sending an extra message. If the client does send a connection close, the server has to keep the state for 3*RTO, which is not a very big deal. -- Christian Huitema From nobody Wed Jun 5 14:13:34 2019 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 870FF12013B for ; Wed, 5 Jun 2019 14:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 lFQCDj62T-N1 for ; Wed, 5 Jun 2019 14:13:30 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780137.outbound.protection.outlook.com [40.107.78.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93391200B5 for ; Wed, 5 Jun 2019 14:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8t9HRZ+7wTGrtQLfVmm5A0yrNNfdzpHsdRrgVhnzOeA=; b=QSakVh2YQ9Gdsbh+kd79Is1GRO5hyvO6GOTh9GrltqESA0oKvsOeYeNMvyiytfQgZlqPitH5QuNDYJOPpTiFoI4E//R7jaPXW0cpnJZ2X9RevTuJMVrh5Vk/hIzaRcjNcgMA6cdYZSMd2Lce0VMd4Nz6CYImzG/lnDagNV++HN8= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0630.namprd22.prod.outlook.com (10.172.139.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Wed, 5 Jun 2019 21:13:27 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1943.018; Wed, 5 Jun 2019 21:13:26 +0000 From: Mike Bishop To: Christian Huitema , Ian Swett , Marten Seemann CC: Nick Banks , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Jiuhai Zhang Subject: =?utf-8?B?UkU6IElzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUgQWNrLWVsaWNpdGluZw==?= =?utf-8?B?77yf?= Thread-Topic: =?utf-8?B?SXMgQ09OTkVDVElPTl9DTE9TRSBmcmFtZSBBY2stZWxpY2l0aW5n77yf?= Thread-Index: AQHVG5bLhdeFO0b9D0S3XNuHX2zZ7qaNE4cAgAADKYCAAAI/gIAAHtAAgAABbICAAAZOgIAAA4WAgABDqACAAAiaUA== Date: Wed, 5 Jun 2019 21:13:26 +0000 Message-ID: References: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> In-Reply-To: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> 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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c055faa6-123a-489d-fdeb-08d6e9faa6d0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0630; x-ms-traffictypediagnostic: CY4PR22MB0630: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(396003)(39830400003)(376002)(189003)(199004)(13464003)(60444003)(66574012)(256004)(81156014)(14444005)(508600001)(81166006)(52536014)(11346002)(8936002)(7696005)(14454004)(5660300002)(486006)(7736002)(316002)(446003)(476003)(74316002)(305945005)(26005)(54906003)(9686003)(6436002)(3846002)(6506007)(33656002)(4326008)(86362001)(53936002)(229853002)(55016002)(6116002)(99286004)(53546011)(66066001)(76116006)(68736007)(66556008)(73956011)(102836004)(66946007)(6246003)(66476007)(186003)(76176011)(74482002)(71200400001)(25786009)(64756008)(110136005)(71190400001)(66446008)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0630; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: t0rZCGtenIad15bEePPxLyDZwTwtmFkstTQaj3GuUd7+9cTFDr35LqKehThistB7onivsWB8RJhlLhD+qjjDLXJRK6wVwNbIj/iv1mqipnh2IoTkyjOCgsrx6dvmJU1qlrqVw8GOWfa8iNVG8OeML9tjAgiq3TkZTndj7r0RkTy2TL80e8B2vGOQtc80kTN5m+7Oo0PJNYSuJ7wJ5lkGpA0fa7t7Q2JYOfTd3xDDKueI55yWdalxwPOOQUqVnK6avqZgtMSM3DdmRKTJKyec3u2POpEGAzk2JLaL9LSBG6Zm/9JOBNl1C+6c7NlHnAkUDLX0gFaWOXq26bpF5TmEQ+9Mut/fdzZxBw+Ie+aYlJzIO19VMkpPS9iSsxcE03igxzUStFSKrx8WxnaZLnChxB8cMQmRrFR4vVdSHZWfJzQ= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c055faa6-123a-489d-fdeb-08d6e9faa6d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2019 21:13:26.8323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0630 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 21:13:33 -0000 QnV0IElJVUMsIHdha2luZyB0aGUgcmFkaW8gaGFwcGVucyB3aGVuIHJlY2VpdmluZyB0aGUgbWVz c2FnZSBpbiB0aGUgZmlyc3QgcGxhY2UuICBTZW5kaW5nIHZzLiByZWNlaXZpbmcgaXNuJ3QgdGhh dCBkaWZmZXJlbnQuICBTbyB0aGF0J3MgYW4gZXhjZWxsZW50IGFyZ3VtZW50IGZvciBoYXZpbmcg YSBzaWxlbnQgY2xvc2Ugb24gYm90aCBzaWRlcywgYnV0IG5vdCBzbyBjb21wZWxsaW5nIHdpdGgg cmVnYXJkIHRvIHdoZXRoZXIgYSBDT05ORUNUSU9OX0NMT1NFIGNhbiBiZSB1c2VkIGluIHJlc3Bv bnNlIHRvIGEgQ09OTkVDVElPTl9DTE9TRS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlzdGlh biBIdWl0ZW1hDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgNSwgMjAxOSAxOjQxIFBNDQpUbzogSWFu IFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+OyBNYXJ0ZW4gU2Vl bWFubiA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+DQpDYzogTmljayBCYW5rcyA8bmliYW5rc0Bt aWNyb3NvZnQuY29tPjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwu Y29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgSml1aGFpIFpoYW5nIDxqaXVoYWku emhhbmdAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IElzIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUg QWNrLWVsaWNpdGluZ++8nw0KDQpPbiA2LzUvMjAxOSA5OjM4IEFNLCBJYW4gU3dldHQgd3JvdGU6 DQoNCj4gSW4gdGhlIHBhc3QsIGhhdmluZyBhbiBBQ0sgYnVuZGxlZCB3aXRoIENPTk5FQ1RJT05f Q0xPU0UgaGFzIGJlZW4gDQo+IHVzZWZ1bCB0byBkZWJ1ZyB3aGF0IHRoZSBwZWVyIGRpZCBhbmQg ZGlkIG5vdCByZWNlaXZlIGFzIG9mIHRoZSBlbmQgb2YgDQo+IHRoZSBjb25uZWN0aW9uLg0KPg0K PiBBZ3JlZWQgb24gc2VuZGluZyBDT05ORUNUSU9OX0NMT1NFIGluIHJlc3BvbnNlIHRvIENPTk5F Q1RJT05fQ0xPU0UgDQo+IGJlaW5nIG1vc3RseSB1c2VsZXNzLsKgIEkgYmVsaWV2ZSBzb21lIHdh bnRlZCB0byBhbGxvdyBpdCBiZWNhdXNlIGlmIA0KPiB0aGV5IHJlY2VpdmVkIGEgQ09OTkVDVElP Tl9DTE9TRSBpbiByZXNwb25zZSB0byB0aGVpciANCj4gQ09OTkVDVElPTl9DTE9TRSwgdGhleSBj b3VsZCByZW1vdmUgYWxsIHN0YXRlIGZvciB0aGUgY29ubmVjdGlvbiwgDQo+IGluY2x1ZGluZyB0 aGUgc2F2ZWQgQ09OTkVDVElPTl9DTE9TRSBwYWNrZXQ/DQoNCk1vc3Qgb2YgdGhlIGFyZ3VtZW50 cyBJIGhlYXJkIG9uZSB3YXkgb3IgdGhlIG90aGVyIGFyZSBiYXNlZCBvbiBwb3dlciBtYW5hZ2Vt ZW50LiBTZW5kaW5nIG9uZSBtb3JlIG1lc3NhZ2UgcmVxdWlyZXMgd2FraW5nIHVwIHRoZSByYWRp bywgZXRjLiwgd2hpY2ggY29uc3VtZXMgc2lnbmlmaWNhbnQgcG93ZXIgb24gYSBtb2JpbGUgZGV2 aWNlLiBSZXBseWluZyB3aXRoIGEgY29ubmVjdGlvbiBjbG9zZSBhbGxvd3MgdGhlIHBlZXIgdG8g aW1tZWRpYXRlbHkgZXhpdCB0aGUgd2FpdGluZyBzdGF0ZSwgd2hpY2ggbWlnaHQgc2F2ZSBzb21l IHBvd2VyIC0tIGJ1dCBwcm9iYWJseSBub3QgYXMgbXVjaCBhcyB3aGF0IGlzIHNhdmVkIG9uIHRo ZSBjbGllbnQgd2l0aCBub3Qgc2VuZGluZyBhbiBleHRyYSBtZXNzYWdlLiBJZiB0aGUgY2xpZW50 IGRvZXMgc2VuZCBhIGNvbm5lY3Rpb24gY2xvc2UsIHRoZSBzZXJ2ZXIgaGFzIHRvIGtlZXAgdGhl IHN0YXRlIGZvciAzKlJUTywgd2hpY2ggaXMgbm90IGEgdmVyeSBiaWcgZGVhbC4NCg0KLS0gQ2hy aXN0aWFuIEh1aXRlbWENCg0KDQo= From nobody Wed Jun 5 15:20:22 2019 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 2A57B120091; Wed, 5 Jun 2019 15:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: magnus.westerlund@ericsson.com, lars@eggert.org, quic@ietf.org, quic-chairs@ietf.org Subject: quic - Update to a Meeting Session Request for IETF 105 X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155977322109.22423.2620111309939071853.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2019 15:20:21 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 05 Jun 2019 22:20:21 -0000 An update to a 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: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls Second Priority: saag rtcweb People who must be present: Sean Turner Mark Nottingham Magnus Westerlund Jana Iyengar Martin Thomson Brian Trammell Mirja Kuehlewind Lars Eggert Mike Bishop Ian Swett Alan Frindell Resources Requested: Special Requests: Two consecutive days early in the week, if possible. Please avoid colliding with all BOFs and the ANRW. --------------------------------------------------------- From nobody Thu Jun 6 00:55:48 2019 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 D7E5F12004B for ; Thu, 6 Jun 2019 00:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6OmR406dD7W for ; Thu, 6 Jun 2019 00:55:44 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 F1CEA12004F for ; Thu, 6 Jun 2019 00:55:43 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x567tY1B025950 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Jun 2019 09:55:34 +0200 Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hYnDR-000174-Th; Thu, 06 Jun 2019 09:53:41 +0200 From: "Philipp S. Tiesel" Message-Id: <0752F79E-FDC9-4204-B804-EAC60DD61654@tiesel.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_07B2B210-DA50-4F2C-B1F4-4A221557333B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: =?utf-8?Q?Re=3A_Is_CONNECTION=5FCLOSE_frame_Ack-eliciting?= =?utf-8?Q?=EF=BC=9F?= Date: Thu, 6 Jun 2019 09:55:35 +0200 In-Reply-To: Cc: Marten Seemann , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Ian Swett , IETF QUIC WG , Jiuhai Zhang To: Nick Banks References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jun 2019 07:55:46 -0000 --Apple-Mail=_07B2B210-DA50-4F2C-B1F4-4A221557333B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5. Jun 2019, at 18:38, Nick Banks = wrote: >=20 > There is no absolute requirement that you maintain the minimal state = to generate the CONNECTION_CLOSE. Personally, I feel a MAY is missing in = that sentence. Additionally, I feel that an endpoint SHOULD (not a MUST = because it=E2=80=99s unenforceable) respond with an immediate = CONNECTION_CLOSE of its own, so the peer can use that as a signal of = acknowledgement and immediately go away, without waiting the full = draining period. But, I know I=E2=80=99m not in the majority with that = opinion. > =20 > On the topic of sending ACKs with CONNECTION_CLOSE, I am more = referring to bundling ACKs with the initialCONNECTION_CLOSE. I agree, = that sending ACKs with the responding CONNECTION_CLOSE doesn=E2=80=99t = do much. It can still be useful on short lived connections to update the = congestion window cache as well as loss and bandwidth estimates. AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ --Apple-Mail=_07B2B210-DA50-4F2C-B1F4-4A221557333B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5. Jun 2019, at 18:38, Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> = wrote:

There is = no absolute requirement that you maintain the minimal state to generate = the CONNECTION_CLOSE. Personally, I feel a MAY is missing in that = sentence. Additionally, I feel that an endpoint SHOULD (not a MUST = because it=E2=80=99s unenforceable) respond with an immediate = CONNECTION_CLOSE of its own, so the peer can use that as a signal of = acknowledgement and immediately go away, without waiting the full = draining period. But, I know I=E2=80=99m not in the majority with that = opinion.
 
On the topic of sending ACKs with CONNECTION_CLOSE, I am more = referring to bundling ACKs with the initialCONNECTION_CLOSE. I agree, that sending ACKs with = the responding CONNECTION_CLOSE doesn=E2=80=99t do = much.

It can = still be useful on short lived connections to update the congestion = window cache as well as loss and bandwidth estimates.

AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_07B2B210-DA50-4F2C-B1F4-4A221557333B-- From nobody Thu Jun 6 02:33:12 2019 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 D244C1201EC for ; Thu, 6 Jun 2019 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW063FpnBJ65 for ; Thu, 6 Jun 2019 02:33:08 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id CDF61120086 for ; Thu, 6 Jun 2019 02:33:07 -0700 (PDT) Received: from MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A8C891B000DF; Thu, 6 Jun 2019 10:32:58 +0100 (BST) Message-ID: <5CF8DDCA.6050707@erg.abdn.ac.uk> Date: Thu, 06 Jun 2019 10:32:58 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Philipp S. Tiesel" CC: Nick Banks , Marten Seemann , =?UTF-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Ian Swett , Jiuhai Zhang Subject: Re: Is CONNECTION_CLOSE frame =?UTF-8?B?QWNrLWVsaWNpdGluZ++8nw==?= References: <0752F79E-FDC9-4204-B804-EAC60DD61654@tiesel.net> In-Reply-To: <0752F79E-FDC9-4204-B804-EAC60DD61654@tiesel.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jun 2019 09:33:11 -0000 On 06/06/2019, 08:55, Philipp S. Tiesel wrote: > > >> On 5. Jun 2019, at 18:38, Nick Banks >> > > wrote: >> >> There is no absolute requirement that you maintain the minimal state >> to generate the CONNECTION_CLOSE. Personally, I feel a MAY is missing >> in that sentence. Additionally, I feel that an endpoint SHOULD (not a >> MUST because it’s unenforceable) respond with an immediate >> CONNECTION_CLOSE of its own, so the peer can use that as a signal of >> acknowledgement and immediately go away, without waiting the full >> draining period. But, I know I’m not in the majority with that opinion. >> On the topic of sending ACKs with CONNECTION_CLOSE, I am more >> referring to bundling ACKs with the*initial*CONNECTION_CLOSE. I >> agree, that sending ACKs with the responding CONNECTION_CLOSE doesn’t >> do much. > > It can still be useful on short lived connections to update the > congestion window cache as well as loss and bandwidth estimates. > > AVE! > Philipp S. Tiesel > > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ > I'd agree this can be really useful and there may be more transport characteristics that could usefully be cached. Gorry From nobody Thu Jun 6 06:57:52 2019 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 782BC1200F5 for ; Thu, 6 Jun 2019 06:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de 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 nmbXnbsgS4iB for ; Thu, 6 Jun 2019 06:57:47 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDC3120074 for ; Thu, 6 Jun 2019 06:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1559829464; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=82bfCDgcbOZa5idmzBGUzE2PAnSBP3GUIwSwXU7VPh4=; b=GpWDJ5XtUqxgfH1+3xQA7JVRCznHn9OYj7nCzF53j+7Lg65p0iNZ9PorWMUeKTbp4U 8HnpRZUaBhnUN+cqW39wRF50BYnUJVoj43ydZf2pol9fMPc/9AvK4MWfM5WZxwBhC8UF 8psVvrFWerqPRq992Y9IApv7xqvlLHyNpDd6TcSln5GIXgPuecoyHR6/6egikP8BabXr FUOOljecGdQC9So+OsXtZLUlGPnEpxuu/AZUeMEmRXIJCj7sp0XAMZNZDzvBS4xDP0h5 wjZihP9ekRwF52oEYZja2+0/qxThY6KWJ4hAxCHB/noLbElhdWNgleRkK6r61fAI4IbP 1fEA== X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKt0Zib1EwEOzr8+BNkxXWP+OqyFZyRGTJiOMmxcOom4Q2/Hg1L" X-RZG-CLASS-ID: mo00 Received: from [IPv6:2003:f4:73c1:9a00:b409:f58e:e178:266] by smtp.strato.de (RZmta 44.22 AUTH) with ESMTPSA id 608fa8v56DvhG28 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 6 Jun 2019 15:57:43 +0200 (CEST) Subject: =?UTF-8?Q?Re=3a_Is_CONNECTION=5fCLOSE_frame_Ack-eliciting=ef=bc=9f?= To: quic@ietf.org References: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> From: Roland Zink Message-ID: Date: Thu, 6 Jun 2019 15:57:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <3432c428-9c16-93cf-4455-b030c9527beb@huitema.net> Content-Type: multipart/alternative; boundary="------------D0787D1D7B599115AF27DE69" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jun 2019 13:57:51 -0000 This is a multi-part message in MIME format. --------------D0787D1D7B599115AF27DE69 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In LTE networks mobile devices RRC (Radio Resource Control) disconnect after a few seconds from the mobile network. They only connect back from time to time for example when they enter another tracking area. When some data needs to be send to it then those device needs first to be paged within a tracking area and only after they reconnect the data can be send. Often server idle timeouts are longer than the RRC disconnect timeout. This means when the server closes the connection and send something to do so then this requires all the signalling to bring the device online again just for a TCP FIN. For TCP there are middle boxes which optimize those in mobile networks. Some numbers: Devices stay 5-10% shorter in connected (radio active) state Number of paging request because of data to be delivered is reduced by 10-20% There is an Android App available in the PlayStore named Devmon which shows in a graph when such a thing happens. It needs root access and tcpdump to determine if a TCP FIN was received, see https://play.google.com/store/apps/details?id=com.flashnetworks.netmon. For QUIC the silent connection close after an idle timeout avoids that overhead for mobile devices and networks. Regards, Roland Am 05.06.2019 um 22:40 schrieb Christian Huitema: > On 6/5/2019 9:38 AM, Ian Swett wrote: > >> In the past, having an ACK bundled with CONNECTION_CLOSE has been >> useful to debug what the peer did and did not receive as of the end of >> the connection. >> >> Agreed on sending CONNECTION_CLOSE in response to CONNECTION_CLOSE >> being mostly useless.  I believe some wanted to allow it because if >> they received a CONNECTION_CLOSE in response to their >> CONNECTION_CLOSE, they could remove all state for the connection, >> including the saved CONNECTION_CLOSE packet? > Most of the arguments I heard one way or the other are based on power > management. Sending one more message requires waking up the radio, etc., > which consumes significant power on a mobile device. Replying with a > connection close allows the peer to immediately exit the waiting state, > which might save some power -- but probably not as much as what is saved > on the client with not sending an extra message. If the client does send > a connection close, the server has to keep the state for 3*RTO, which is > not a very big deal. > > -- Christian Huitema > > --------------D0787D1D7B599115AF27DE69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

In LTE networks mobile devices RRC (Radio Resource Control) disconnect after a few seconds from the mobile network. They only connect back from time to time for example when they enter another tracking area. When some data needs to be send to it then those device needs first to be paged within a tracking area and only after they reconnect the data can be send. Often server idle timeouts are longer than the RRC disconnect timeout. This means when the server closes the connection and send something to do so then this requires all the signalling to bring the device online again just for a TCP FIN.


For TCP there are middle boxes which optimize those in mobile networks. Some numbers:

Devices stay 5-10% shorter in connected (radio active) state

Number of paging request because of data to be delivered is reduced by 10-20%


There is an Android App available in the PlayStore named Devmon which shows in a graph when such a thing happens. It needs root access and tcpdump to determine if a TCP FIN was received, see https://play.google.com/store/apps/details?id=com.flashnetworks.netmon.


For QUIC the silent connection close after an idle timeout avoids that overhead for mobile devices and networks.


Regards,

Roland



Am 05.06.2019 um 22:40 schrieb Christian Huitema:
On 6/5/2019 9:38 AM, Ian Swett wrote:


In the past, having an ACK bundled with CONNECTION_CLOSE has been
useful to debug what the peer did and did not receive as of the end of
the connection.

Agreed on sending CONNECTION_CLOSE in response to CONNECTION_CLOSE
being mostly useless.  I believe some wanted to allow it because if
they received a CONNECTION_CLOSE in response to their
CONNECTION_CLOSE, they could remove all state for the connection,
including the saved CONNECTION_CLOSE packet?

Most of the arguments I heard one way or the other are based on power
management. Sending one more message requires waking up the radio, etc.,
which consumes significant power on a mobile device. Replying with a
connection close allows the peer to immediately exit the waiting state,
which might save some power -- but probably not as much as what is saved
on the client with not sending an extra message. If the client does send
a connection close, the server has to keep the state for 3*RTO, which is
not a very big deal.

-- Christian Huitema
--------------D0787D1D7B599115AF27DE69-- From nobody Thu Jun 6 16:56:33 2019 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 AF41C1200A3 for ; Thu, 6 Jun 2019 16:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv4X1yeu1FLC for ; Thu, 6 Jun 2019 16:56:29 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 1BE0812006E for ; Thu, 6 Jun 2019 16:56:29 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id f20so37367ual.0 for ; Thu, 06 Jun 2019 16:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6PY9nn6d52z9fQmN3KyBr6iapSd2PSmrt3OxTujd7Uc=; b=bg1O/T+Vsct8ZfGqteFbyZu9LATUMYX9UzpaJQXyyhm0rKxmZepVVitjbGFBvcilEV 92f3v9+1CRO3tlwIxblNee4r2zPNNF5lipDLbeByKjmpL6YmtBtVNYubAVym5tiQrniE YVMocsG+aQ3UI/BRZYsstZK+7nqV/kcG6HncuBMCzjhgcHqkfnc/0g1OvmSHUwaWKm4v WbQlrdRoDpHoeNwDQcUCyd9GCVOc2FzYA2/9ObgnV3tqvvLUnjc2cooNMHcB1Hm/RnTZ 2er7ZvDFNmbwstzXBLQIVV3S/zIcZSF2tu/EJjgIfq48Grq3c6LwbPYtSNExSTN5XPaQ wk3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6PY9nn6d52z9fQmN3KyBr6iapSd2PSmrt3OxTujd7Uc=; b=Nmf8LfT8u9Tna08SlMwYi2sDMak4a70R8XFG44nOY1Ja5beN79RjgP3UAZJnRcn9Sg ZyRUldycRGJJxhe7clUt0Pk4udv8DsmKaN5qRLC+5GtxGlH8Aix2FcfEZbofN7v2M5FB gadrH309sKhcqUXgUAgdF2UGGXI4htawS9kicIK5yqAbbYrsjGIKq6yBcvgDURul92ds MATw8+w35XQwvtz3MsD4OgLpEzXdjSQCH8uywFUNvbcV2pdf6lCa+ohqdHrJaXYM6ITs fI1vI9k7lbLMav9DiFg8GA3gQl3xURIFnk1JDRdASAAQzcasHT8UGBDRuyGh2GP5M/fT F3Wg== X-Gm-Message-State: APjAAAVXFrmNnoMTiDmWoKN4Xd8IPg8i+yHmNY11JlZkpMdGcHO5pCqF sVdAg2+QsRGlS8h/NCBV0ZRV4PMHce/0NTLFRC/sXwfO0l0= X-Google-Smtp-Source: APXvYqzECfQF4qYQqE4dsgI9r1kYjW9H78Gc12+gxVzcdU0+VDBrEBXvcAyJlKXkIFtc2M9aWSiZAyVpwXkPsxcHqFE= X-Received: by 2002:ab0:14cb:: with SMTP id f11mr25919893uae.24.1559865387737; Thu, 06 Jun 2019 16:56:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Bence_B=C3=A9ky?= Date: Thu, 6 Jun 2019 19:56:16 -0400 Message-ID: Subject: Cookie crumbling in QPACK? To: quic@ietf.org Content-Type: multipart/alternative; boundary="00000000000055cbc1058ab076ba" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 06 Jun 2019 23:56:31 -0000 --00000000000055cbc1058ab076ba Content-Type: text/plain; charset="UTF-8" Hi, RFC7540 allows crumbling cookies for compression efficiency with HPACK. However, neither quic-http nor quic-qpack drafts mention cookies or crumbling. Is it considered safe for a QPACK implementation to crumble cookies before compression and concatenate them after decompression? If so, should the draft include clarification on this? Thanks, Bence --00000000000055cbc1058ab076ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

RFC7540=C2=A0allows crumbling=C2=A0cookies for compres= sion efficiency with HPACK.=C2=A0 However, neither quic-http nor quic-qpack drafts mention cookies or crumbling.=C2= =A0 Is it considered safe for a QPACK implementation to crumble cookies bef= ore compression and concatenate them after decompression?=C2=A0 If so, shou= ld the draft include clarification on this?

Thanks= ,

Bence
--00000000000055cbc1058ab076ba-- From nobody Fri Jun 7 09:13:04 2019 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 997231200E6 for ; Fri, 7 Jun 2019 09:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Yg7jBYUX; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=NMIVqt5J 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 HKL5Q9pF2KlX for ; Fri, 7 Jun 2019 09:12:59 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223DE1200DE for ; Fri, 7 Jun 2019 09:12:59 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x57G8hO4021508; Fri, 7 Jun 2019 09:12:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=hs60ET34zGFJH4Cxbud1qlD6q4yOZ5dDSH3sCwpXdnY=; b=Yg7jBYUXlHHOb7F3SewX2S4P5RgwPHmLP+lJ26f4R5aEf+ML48Sm9efROeBAahsHY6NQ ROQPymjTWCwYCSUYwt4IM818AsiZ3ccgFZZQepMbD5uoTmlr8Zo0zzIlpKDNMaBJ1bWL TzH+wll3qzAeksK5+m+6zL9r7n4CsUzaWhc= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2syepu24x9-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 07 Jun 2019 09:12:53 -0700 Received: from ash-exhub203.TheFacebook.com (2620:10d:c0a8:83::5) by ash-exhub204.TheFacebook.com (2620:10d:c0a8:83::4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 7 Jun 2019 09:12:51 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 7 Jun 2019 09:12:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hs60ET34zGFJH4Cxbud1qlD6q4yOZ5dDSH3sCwpXdnY=; b=NMIVqt5JcXO2K542cbBIgKnTvsskM/PEZ1zJkZOimi7qLWsfy9bY3R1xgUovEHonxwi7Gn8rLighsERY5ZLs0gHeCaFcgQG4isKhWMDOLd2S4OUiezfUt3rdM8wuLaj/UYaNNn0On3/oqWFrLj1t7tgkTfF/AWV44sBslJckC+0= Received: from DM5PR15MB1179.namprd15.prod.outlook.com (10.173.215.151) by DM5PR15MB1388.namprd15.prod.outlook.com (10.173.224.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Fri, 7 Jun 2019 16:12:50 +0000 Received: from DM5PR15MB1179.namprd15.prod.outlook.com ([fe80::b075:97af:6ae3:29a5]) by DM5PR15MB1179.namprd15.prod.outlook.com ([fe80::b075:97af:6ae3:29a5%2]) with mapi id 15.20.1965.011; Fri, 7 Jun 2019 16:12:50 +0000 From: Alan Frindell To: =?utf-8?B?QmVuY2UgQsOpa3k=?= , "quic@ietf.org" Subject: Re: Cookie crumbling in QPACK? Thread-Topic: Cookie crumbling in QPACK? Thread-Index: AQHVHMOLjh2xwZnwW02jnHSWTiMOL6aP6NOA Date: Fri, 7 Jun 2019 16:12:50 +0000 Message-ID: <39BCBB46-D35D-44F7-9069-A49BD8CA0C98@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-originating-ip: [2620:10d:c090:200::1:609a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b683e4f1-5428-4d4f-962d-08d6eb62fd25 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR15MB1388; x-ms-traffictypediagnostic: DM5PR15MB1388: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0061C35778 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(376002)(346002)(189003)(199004)(25786009)(606006)(6486002)(478600001)(6116002)(4744005)(5660300002)(33656002)(446003)(6436002)(68736007)(8936002)(46003)(186003)(316002)(86362001)(229853002)(14454004)(476003)(486006)(11346002)(2906002)(2616005)(8676002)(82746002)(110136005)(81166006)(81156014)(58126008)(36756003)(6506007)(71200400001)(71190400001)(76176011)(83716004)(53546011)(102836004)(99286004)(6246003)(66446008)(64756008)(66556008)(66476007)(73956011)(66946007)(76116006)(6306002)(54896002)(6512007)(53936002)(2501003)(236005)(256004)(3480700005)(91956017)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1388; H:DM5PR15MB1179.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8zAGDeolYw6YTd5OHlzxQQrm72RpehLNvT4tmsSAUZJcdoZZsfXRB/6OjrH2PoqnNhvb2dWGT+fvMOo/yj75rsIVx985PZsgO2zdFRRACOajlDUsHFLyxps4DkvGqUvxn1VAGX8uwdkQX2olOOPH1LmRMOnybA3D1G0AH+tLrDagZcbgLDwSjtxIgAUk4ZhtzAOS6L02R0mBz16ykb7KT5p0l9of47hbkJNRTcj8FxwVMgrQ1TJZ1GeR8T4J+Jnw6q5xENMynuLh4Ra2B3HKxFsWrwlL5NxzTMqhXbT0z+w6JhJy25YNrIT0vX2aagjEh/s4KY6SL4XCst30T4aOkZFSt904xHj6unGpFL+c24eTQNaxb3POuO5PvcrBm5Wsm3Jfxf5UaJWDDvCBDBubxnz5cVFQNFuwciC9GjJUyKY= Content-Type: multipart/alternative; boundary="_000_39BCBB46D35D44F79069A49BD8CA0C98fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b683e4f1-5428-4d4f-962d-08d6eb62fd25 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 16:12:50.3773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: afrind@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1388 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=995 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906070109 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 16:13:02 -0000 --_000_39BCBB46D35D44F79069A49BD8CA0C98fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2hvdWxkIGJlIGFzIHNhZmUgZm9yIFFQQUNLIGFzIGl0IGlzIGZvciBIUEFDSy4gIFNpbmNl IEhUVFAvMiB3ZW50IG91dCBvZiB0aGUgd2F5IHRvIG1lbnRpb24gaXQgaW4gdGhlIGRyYWZ0LCBJ IHN1cHBvc2UgSFRUUC8zIHNob3VsZCBhbHNvPw0KDQotQWxhbg0KDQpGcm9tOiBRVUlDIDxxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBCZW5jZSBCw6lreSA8Ym5jPTQwZ29vZ2xl LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCBKdW5lIDYsIDIwMTkgYXQgNDo1 NyBQTQ0KVG86ICJxdWljQGlldGYub3JnIiA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IENvb2tp ZSBjcnVtYmxpbmcgaW4gUVBBQ0s/DQoNCkhpLA0KDQpSRkM3NTQwPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9faHR0cHdnLm9yZ19zcGVjc19yZmM3 NTQwLmh0bWwtMjNDb21wcmVzc0Nvb2tpZSZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNN VXcmcj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3Jm09dXJQTGxvSkFzLUtYbExYOGRmakg4VXdiekst YVBNY1daQzJTV0dzY3BiWSZzPWw1NFEyVThwOG1ReUtBZnJPczV0bVpLNi03MGFxTWtBUW1KZ3J4 TXJKS00mZT0+IGFsbG93cyBjcnVtYmxpbmcgY29va2llcyBmb3IgY29tcHJlc3Npb24gZWZmaWNp ZW5jeSB3aXRoIEhQQUNLLiAgSG93ZXZlciwgbmVpdGhlciBxdWljLWh0dHA8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19xdWljd2cub3JnX2Jhc2Ut MkRkcmFmdHNfZHJhZnQtMkRpZXRmLTJEcXVpYy0yRGh0dHAuaHRtbCZkPUR3TUZhUSZjPTVWRDBS VHRObFRoM3ljZDQxYjNNVXcmcj0xSVRLc1pBZURhdzY1ZXlRY2RWR2N3Jm09dXJQTGxvSkFzLUtY bExYOGRmakg4VXdiekstYVBNY1daQzJTV0dzY3BiWSZzPV9aVWVfZWhhc3NEX1pTQ0EzWjNta05I NlVIUXQ3UHVEWFk1aTR6RFBqN1EmZT0+IG5vciBxdWljLXFwYWNrPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcXVpY3dnLm9yZ19iYXNlLTJEZHJh ZnRzX2RyYWZ0LTJEaWV0Zi0yRHF1aWMtMkRxcGFjay5odG1sJmQ9RHdNRmFRJmM9NVZEMFJUdE5s VGgzeWNkNDFiM01VdyZyPTFJVEtzWkFlRGF3NjVleVFjZFZHY3cmbT11clBMbG9KQXMtS1hsTFg4 ZGZqSDhVd2J6Sy1hUE1jV1pDMlNXR3NjcGJZJnM9R0JndW9iekhEdVRCNXJwX1pzNEJPWjdaaktt dlM4MXJBMWhMXzV0ZU9mQSZlPT4gZHJhZnRzIG1lbnRpb24gY29va2llcyBvciBjcnVtYmxpbmcu ICBJcyBpdCBjb25zaWRlcmVkIHNhZmUgZm9yIGEgUVBBQ0sgaW1wbGVtZW50YXRpb24gdG8gY3J1 bWJsZSBjb29raWVzIGJlZm9yZSBjb21wcmVzc2lvbiBhbmQgY29uY2F0ZW5hdGUgdGhlbSBhZnRl ciBkZWNvbXByZXNzaW9uPyAgSWYgc28sIHNob3VsZCB0aGUgZHJhZnQgaW5jbHVkZSBjbGFyaWZp Y2F0aW9uIG9uIHRoaXM/DQoNClRoYW5rcywNCg0KQmVuY2UNCg== --_000_39BCBB46D35D44F79069A49BD8CA0C98fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkl0IHNob3VsZCBiZSBhcyBzYWZlIGZvciBRUEFDSyBhcyBpdCBpcyBmb3IgSFBB Q0suJm5ic3A7IFNpbmNlIEhUVFAvMiB3ZW50IG91dCBvZiB0aGUgd2F5IHRvIG1lbnRpb24gaXQg aW4gdGhlIGRyYWZ0LCBJIHN1cHBvc2UgSFRUUC8zIHNob3VsZCBhbHNvPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tQWxhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQmVuY2Ug QsOpa3kgJmx0O2JuYz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlRodXJzZGF5LCBKdW5lIDYsIDIwMTkgYXQgNDo1NyBQTTxicj4NCjxiPlRvOiA8L2I+ JnF1b3Q7cXVpY0BpZXRmLm9yZyZxdW90OyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+Q29va2llIGNydW1ibGluZyBpbiBRUEFDSz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGksIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19o dHRwd2cub3JnX3NwZWNzX3JmYzc1NDAuaHRtbC0yM0NvbXByZXNzQ29va2llJmFtcDtkPUR3TUZh USZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPTFJVEtzWkFlRGF3NjVleVFjZFZH Y3cmYW1wO209dXJQTGxvSkFzLUtYbExYOGRmakg4VXdiekstYVBNY1daQzJTV0dzY3BiWSZhbXA7 cz1sNTRRMlU4cDhtUXlLQWZyT3M1dG1aSzYtNzBhcU1rQVFtSmdyeE1ySktNJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPlJGQzc1NDA8L2E+Jm5ic3A7YWxsb3dzDQogY3J1bWJsaW5nJm5ic3A7Y29v a2llcyBmb3IgY29tcHJlc3Npb24gZWZmaWNpZW5jeSB3aXRoIEhQQUNLLiZuYnNwOyBIb3dldmVy LCBuZWl0aGVyIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fcXVpY3dnLm9yZ19iYXNlLTJEZHJhZnRzX2RyYWZ0LTJEaWV0Zi0yRHF1 aWMtMkRodHRwLmh0bWwmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcm YW1wO3I9MUlUS3NaQWVEYXc2NWV5UWNkVkdjdyZhbXA7bT11clBMbG9KQXMtS1hsTFg4ZGZqSDhV d2J6Sy1hUE1jV1pDMlNXR3NjcGJZJmFtcDtzPV9aVWVfZWhhc3NEX1pTQ0EzWjNta05INlVIUXQ3 UHVEWFk1aTR6RFBqN1EmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpxdWljLWh0dHA8L2E+IG5v ciA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3F1aWN3Zy5vcmdfYmFzZS0yRGRyYWZ0c19kcmFmdC0yRGlldGYtMkRxdWljLTJEcXBh Y2suaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj0x SVRLc1pBZURhdzY1ZXlRY2RWR2N3JmFtcDttPXVyUExsb0pBcy1LWGxMWDhkZmpIOFV3YnpLLWFQ TWNXWkMyU1dHc2NwYlkmYW1wO3M9R0JndW9iekhEdVRCNXJwX1pzNEJPWjdaakttdlM4MXJBMWhM XzV0ZU9mQSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCnF1aWMtcXBhY2s8L2E+IGRyYWZ0cyBt ZW50aW9uIGNvb2tpZXMgb3IgY3J1bWJsaW5nLiZuYnNwOyBJcyBpdCBjb25zaWRlcmVkIHNhZmUg Zm9yIGEgUVBBQ0sgaW1wbGVtZW50YXRpb24gdG8gY3J1bWJsZSBjb29raWVzIGJlZm9yZSBjb21w cmVzc2lvbiBhbmQgY29uY2F0ZW5hdGUgdGhlbSBhZnRlciBkZWNvbXByZXNzaW9uPyZuYnNwOyBJ ZiBzbywgc2hvdWxkIHRoZSBkcmFmdCBpbmNsdWRlIGNsYXJpZmljYXRpb24gb24gdGhpcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C ZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39BCBB46D35D44F79069A49BD8CA0C98fbcom_-- From nobody Fri Jun 7 10:10:12 2019 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 989621201D8 for ; Fri, 7 Jun 2019 10:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.508 X-Spam-Level: X-Spam-Status: No, score=-17.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPiyRnOExj5N for ; Fri, 7 Jun 2019 10:09:59 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 974E5120260 for ; Fri, 7 Jun 2019 10:09:58 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id b17so2871458wrq.11 for ; Fri, 07 Jun 2019 10:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yM7wXyy0URebvaxoBw4SIj6jFwqLIOrPNiNzfRSJYhk=; b=NJluh2KgPXLoQY1ICBKF9yi9ccdamqDfqNizF5kcdQvcOhGHtTZmsuBOm8VfVOo4IU O+8lBgRZxw3V/5SxU+qBA5GqGPsCx18+XdcSsePmKsYqVMa63XSrY3n0RxXmECgJMVUy uF9XD0uTX2Gcg98eYR+/LzhTnYkl66Egwr8OuEHk9jUXdjWcj4blXMU0qdNL1uszXlHm UmOQ2Ah+AfBfRMc4FVx6HL6ps4vHgPTl0vERm2iGj/4yYStL071tXJv4xxqb87VeAXpg +/vqSuirRL1GqeIRw6gGYI384MvLPcKVaADdUQoRYfa1nKO2p7n3t/DAr98KKZhopiUk xfAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yM7wXyy0URebvaxoBw4SIj6jFwqLIOrPNiNzfRSJYhk=; b=C/QyjzL6pOrsJ98eyOKQ5xFSlSsPHELY7ea2eBnepmhCHn4UxSn3FxvtdWpPJr75uD ddE/Dg7FAJFxSu9SZBcxca3K1oCnFPoCgSWo1hRgiHnjslKiwzCt+G7QVLDXjjz06mQc XGXxlEBWVBPFbTbEq18jXrDB+ezzJLSG9j3XjGAeY0gJnWPw999KzB82k5BQL1V2Rfcu oSjve8dZ6Iloy7h/M3XsHIAUZ0n15aOy88gYosByirnuoz2haiAICFCWP0Zx4Zm7Zzkw PoIVflmyTTENsedF86xJlJzqTkROjhQLMGNHd7Z0Ccnrdylx9wdxbgCaKELzvmphDo3f CIhA== X-Gm-Message-State: APjAAAVxAjY5ZhVkkeP/8Rx874xsSdKkS6gTwtfKwqxoz0BdkD2WvdsR oUWatsrM38cFaopl3PW1eSRSr9rCcOc5/B6b59jQuQ== X-Google-Smtp-Source: APXvYqzYFFdyRbLfjkFVVT+buBW9qjzlQ5ev3MCxbYXv7hgCCxAWL1dcE1yi0dVVJOoMGr+KffK4HF0gvtG6SdQKXA4= X-Received: by 2002:a5d:4a8d:: with SMTP id o13mr1690947wrq.350.1559927396523; Fri, 07 Jun 2019 10:09:56 -0700 (PDT) MIME-Version: 1.0 References: <39BCBB46-D35D-44F7-9069-A49BD8CA0C98@fb.com> In-Reply-To: <39BCBB46-D35D-44F7-9069-A49BD8CA0C98@fb.com> From: Ryan Hamilton Date: Fri, 7 Jun 2019 10:09:43 -0700 Message-ID: Subject: Re: Cookie crumbling in QPACK? To: Alan Frindell Cc: =?UTF-8?Q?Bence_B=C3=A9ky?= , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000058aabf058abee633" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 17:10:11 -0000 --00000000000058aabf058abee633 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 7, 2019 at 9:13 AM Alan Frindell wrote: > It should be as safe for QPACK as it is for HPACK. Since HTTP/2 went out > of the way to mention it in the draft, I suppose HTTP/3 should also? > Agreed. I think HTTP/3 should either mention it explicitly, or normatively reference 8.1.2.5. --00000000000058aabf058abee633 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 7, 2019 at 9:13 AM = Alan Frindell <afrind@fb.com> wr= ote:

It should be as safe for QPACK as it is for HPACK.= =C2=A0 Since HTTP/2 went out of the way to mention it in the draft, I suppo= se HTTP/3 should also?


Agreed. I think HTTP/3 should either mention it explicitly, or norm= atively reference 8.1.2.5.

--00000000000058aabf058abee633-- From nobody Fri Jun 7 10:13:02 2019 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 02F62120189 for ; Fri, 7 Jun 2019 10:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=S+9s1gSj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=aNybEHuU 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 1tm1OacK-xSB for ; Fri, 7 Jun 2019 10:12:59 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6D8120178 for ; Fri, 7 Jun 2019 10:12:59 -0700 (PDT) Received: from pps.filterd (m0148461.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x57HCr38031321; Fri, 7 Jun 2019 10:12:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=weiXMqUM2TmgGgJJcMEP9UT3M8CSm907ZgNYyWK9lGs=; b=S+9s1gSjckMa76o+fy2wMqNOTq2xVXYSrKUZOR74HXkFM4Ok+CHPMZtXL2DZR4wf6kz6 wCzA24+ZotfLwRYUJIcB6s8/8OnEvTaknJC5hthrTFr1BGKsacOZQd5Rk9mUJNOa+Mx6 SEuRFEb8+8ylq/GGgDQQW+gdmdlN9Sf49CI= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2syrgw0ufk-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 07 Jun 2019 10:12:59 -0700 Received: from ash-exhub101.TheFacebook.com (2620:10d:c0a8:82::e) by ash-exhub203.TheFacebook.com (2620:10d:c0a8:83::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 7 Jun 2019 10:12:35 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 7 Jun 2019 10:12:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=weiXMqUM2TmgGgJJcMEP9UT3M8CSm907ZgNYyWK9lGs=; b=aNybEHuUSduGoBMrHphDhNliMu2sJ7ac7A8LvwE+QQbDVZHqscmjiKLGVjWMo2Apv4/ytrS+Ul5OBkhSshi1ZWhV2pQeGORU1Xw4jfbFfNKWWU/ApW1dDLqucw5fDFrBiMZbPcROEMzRA5cplcpu6khqv49siYNrDezORcEr/Y8= Received: from CY4PR15MB1542.namprd15.prod.outlook.com (10.172.160.9) by CY4PR15MB1416.namprd15.prod.outlook.com (10.172.160.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.22; Fri, 7 Jun 2019 17:12:34 +0000 Received: from CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a]) by CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a%9]) with mapi id 15.20.1943.026; Fri, 7 Jun 2019 17:12:34 +0000 From: Roberto Peon To: Ryan Hamilton , Alan Frindell CC: =?utf-8?B?QmVuY2UgQsOpa3k=?= , "quic@ietf.org" Subject: Re: Cookie crumbling in QPACK? Thread-Topic: Cookie crumbling in QPACK? Thread-Index: AQHVHMOHXaQrvDMq1Uu88/DpXzDJ26aQXi0AgAAP5YD//4tygA== Date: Fri, 7 Jun 2019 17:12:34 +0000 Message-ID: <9CF4862E-400A-4338-939A-8C222B73B483@fb.com> References: <39BCBB46-D35D-44F7-9069-A49BD8CA0C98@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-originating-ip: [2620:10d:c090:200::2:561b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85b90177-60ff-4f87-c696-08d6eb6b557e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR15MB1416; x-ms-traffictypediagnostic: CY4PR15MB1416: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0061C35778 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(39860400002)(396003)(376002)(189003)(199004)(81166006)(6486002)(8676002)(81156014)(82746002)(478600001)(7736002)(6636002)(66946007)(36756003)(86362001)(3480700005)(4744005)(5660300002)(25786009)(229853002)(33656002)(53546011)(54906003)(58126008)(6116002)(6436002)(6512007)(256004)(99286004)(316002)(8936002)(76176011)(71200400001)(2906002)(83716004)(110136005)(2616005)(476003)(66556008)(6506007)(46003)(486006)(4326008)(14454004)(446003)(6246003)(76116006)(11346002)(53936002)(66476007)(73956011)(186003)(66446008)(71190400001)(236005)(6306002)(91956017)(54896002)(102836004)(68736007)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1416; H:CY4PR15MB1542.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BT1x2tvfXOTEAZ/ND6tkdepPBIxkMkjDyjCPl594F2yv3Wk7CbDWKYk0R3+v4X6uAn3Q17hsOdtz+yyPEPzdo4WrB08X24mTh2ZiOS/MqDE/pO75bEIYTdBUFWvUMTXtGQl89rQsGFGnDW9YVCtIkboWrd5HqmfZf8hUWeqCAovvPMtEuuZ+eAqk8DmSp4ZthUmb8taerg7KMyTne+kVJ+WGApCNI29JzkFeWJ9xwam9iQMj0A/WI5T1xNUAcelSQ3wWuwe+jWalMRqIHlW/6CIlGfyflFOT8ZLpfQRAG++wtVwtH6fqCWuM1VPduWELXI8oNK6dDsRDaM8+mM1uXE+SeoGje1mK+eFzar+379SKLFPPa5SFexfTm0wE3TTlQtT2SWGPIQ1bMRGJKbcCbPwU1v188FdZUbSIfSIYKHU= Content-Type: multipart/alternative; boundary="_000_9CF4862E400A4338939A8C222B73B483fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 85b90177-60ff-4f87-c696-08d6eb6b557e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 17:12:34.6522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fenix@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1416 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906070115 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 17:13:01 -0000 --_000_9CF4862E400A4338939A8C222B73B483fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm9ybWF0aXZlIHJlZmVyZW5jZSB3b3VsZCBtYWtlIGEgbG90IG9mIHNlbnNlLCBJIHRoaW5rLg0K LT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJ5 YW4gSGFtaWx0b24gPHJjaD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBGcmlk YXksIEp1bmUgNywgMjAxOSBhdCAxMDoxMSBBTQ0KVG86IEFsYW4gRnJpbmRlbGwgPGFmcmluZEBm Yi5jb20+DQpDYzogQmVuY2UgQsOpa3kgPGJuYz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+ LCAicXVpY0BpZXRmLm9yZyIgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQ29va2llIGNy dW1ibGluZyBpbiBRUEFDSz8NCg0KDQoNCk9uIEZyaSwgSnVuIDcsIDIwMTkgYXQgOToxMyBBTSBB bGFuIEZyaW5kZWxsIDxhZnJpbmRAZmIuY29tPG1haWx0bzphZnJpbmRAZmIuY29tPj4gd3JvdGU6 DQpJdCBzaG91bGQgYmUgYXMgc2FmZSBmb3IgUVBBQ0sgYXMgaXQgaXMgZm9yIEhQQUNLLiAgU2lu Y2UgSFRUUC8yIHdlbnQgb3V0IG9mIHRoZSB3YXkgdG8gbWVudGlvbiBpdCBpbiB0aGUgZHJhZnQs IEkgc3VwcG9zZSBIVFRQLzMgc2hvdWxkIGFsc28/DQoNCkFncmVlZC4gSSB0aGluayBIVFRQLzMg c2hvdWxkIGVpdGhlciBtZW50aW9uIGl0IGV4cGxpY2l0bHksIG9yIG5vcm1hdGl2ZWx5IHJlZmVy ZW5jZSA4LjEuMi41Lg0KDQo= --_000_9CF4862E400A4338939A8C222B73B483fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <40B2C643A1ED4C46B89042C96F5166A4@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNYW5nYWw7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDIgMyAzIDIgMjt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlRyZWJ1Y2hldCBNUyI7DQoJcGFub3NlLTE6MiAxMSA2IDMgMiAyIDIgMiAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3JtYXRpdmUgcmVmZXJl bmNlIHdvdWxkIG1ha2UgYSBsb3Qgb2Ygc2Vuc2UsIEkgdGhpbmsuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m IFJ5YW4gSGFtaWx0b24gJmx0O3JjaD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSnVuZSA3LCAyMDE5IGF0IDEwOjExIEFNPGJyPg0KPGI+ VG86IDwvYj5BbGFuIEZyaW5kZWxsICZsdDthZnJpbmRAZmIuY29tJmd0Ozxicj4NCjxiPkNjOiA8 L2I+QmVuY2UgQsOpa3kgJmx0O2JuYz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7LCAm cXVvdDtxdWljQGlldGYub3JnJnF1b3Q7ICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogQ29va2llIGNydW1ibGluZyBpbiBRUEFDSz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVuIDcsIDIwMTkgYXQgOToxMyBBTSBBbGFuIEZy aW5kZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YWZyaW5kQGZiLmNvbSI+YWZyaW5kQGZiLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IHNob3VsZCBiZSBhcyBzYWZlIGZvciBR UEFDSyBhcyBpdCBpcyBmb3IgSFBBQ0suJm5ic3A7IFNpbmNlIEhUVFAvMiB3ZW50IG91dCBvZiB0 aGUgd2F5IHRvIG1lbnRpb24gaXQgaW4gdGhlIGRyYWZ0LCBJIHN1cHBvc2UgSFRUUC8zIHNob3Vs ZCBhbHNvPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkFncmVlZC4gSSB0aGluayBI VFRQLzMgc2hvdWxkIGVpdGhlciBtZW50aW9uIGl0IGV4cGxpY2l0bHksIG9yIG5vcm1hdGl2ZWx5 IHJlZmVyZW5jZSA4LjEuMi41LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9CF4862E400A4338939A8C222B73B483fbcom_-- From nobody Fri Jun 7 14:11:00 2019 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 22A05120111 for ; Fri, 7 Jun 2019 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 AJ9tWpKcn4S8 for ; Fri, 7 Jun 2019 14:10:53 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680109.outbound.protection.outlook.com [40.107.68.109]) (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 7045C120058 for ; Fri, 7 Jun 2019 14:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h/m5v36ocBk7NpCgo3QncpC0sRfXF5OxzHdayI2x/nc=; b=g9zpEdwAOSANBBVN2V0OvQTFZKvR1Of5wJ33xT0qDwT6AKt9B6QT2dIN9dodLsnTd/IHETwYxl0u6rc51h10oWf+DrXO+AsjPU0pfTO4fIejWhcKn5pWCbOp9qkhcrnnC4LxL7zAIRwH8xefRDiZAQg2/Xx9R4eF8xBH92Fz7dU= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0805.namprd22.prod.outlook.com (10.171.170.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Fri, 7 Jun 2019 21:10:50 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1943.018; Fri, 7 Jun 2019 21:10:50 +0000 From: Mike Bishop To: =?utf-8?B?QmVuY2UgQsOpa3k=?= , "quic@ietf.org" Subject: RE: Cookie crumbling in QPACK? Thread-Topic: Cookie crumbling in QPACK? Thread-Index: AQHVHMOCzJmT1rSD8k2Pw8p631snIaaQsWnw Date: Fri, 7 Jun 2019 21:10:50 +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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b22e66a-ac96-449b-364b-08d6eb8c9e85 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0805; x-ms-traffictypediagnostic: CY4PR22MB0805: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0061C35778 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(376002)(346002)(136003)(366004)(189003)(199004)(6436002)(11346002)(86362001)(186003)(606006)(8676002)(236005)(446003)(7696005)(66446008)(73956011)(3480700005)(55016002)(9686003)(54896002)(68736007)(476003)(76176011)(6306002)(8936002)(21615005)(81156014)(110136005)(81166006)(99286004)(508600001)(53546011)(14454004)(26005)(7736002)(102836004)(33656002)(229853002)(486006)(6506007)(74482002)(316002)(66066001)(6246003)(71200400001)(3846002)(66476007)(66946007)(6116002)(76116006)(5660300002)(4744005)(66556008)(2906002)(2501003)(25786009)(71190400001)(53936002)(64756008)(256004)(74316002)(52536014)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0805; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dVcXRv3qLjXhRgIqkS7QH7gxaBAoNShBscE+0gQTJ8HmLNxBYx29rkX7zFt9KsKUqxmUa+yotaY04GtZXuxLOynWODh2UPeQevNJoECoUGNrTBAuo5hYGmqXGWqYWv9G++sLrsAXrVn81uTYmsJ0a8wCpTjYyIiqv5ZDPbyAFKqUo+b2i7u/XvKheUYBN3FZUChoFriNmn2toErDVJ/Askqol0pyU+8HHzIry2pLDpzwoeTalJjNx/yus0WwGdnt49TTBiPXrIzP0IgGTtKQLWcFy2kabqshiEjpGB5fVLjTYd9Yw4BJuWpcxYHhdtKJNpPOaOR6BQ5xTIbowAcHTUWqH/ncGaI3Pb6vv0pR2+lLdE8mrOWx7Ioea+8PqyeNrr+4MFmKLcdFYVUjLo8aSrtiYdYGAu/rS3lHfs1/gTo= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB09832F11FD842A0290CD7DB0DA100CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 6b22e66a-ac96-449b-364b-08d6eb8c9e85 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 21:10:50.6162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0805 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 21:10:56 -0000 --_000_CY4PR22MB09832F11FD842A0290CD7DB0DA100CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmlsZWQgIzI3NzcuDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEJlbmNlIELDqWt5DQpTZW50OiBUaHVyc2RheSwgSnVuZSA2LCAyMDE5IDQ6NTYgUE0N ClRvOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBDb29raWUgY3J1bWJsaW5nIGluIFFQQUNLPw0K DQpIaSwNCg0KUkZDNzU0MDxodHRwczovL2h0dHB3Zy5vcmcvc3BlY3MvcmZjNzU0MC5odG1sI0Nv bXByZXNzQ29va2llPiBhbGxvd3MgY3J1bWJsaW5nIGNvb2tpZXMgZm9yIGNvbXByZXNzaW9uIGVm ZmljaWVuY3kgd2l0aCBIUEFDSy4gIEhvd2V2ZXIsIG5laXRoZXIgcXVpYy1odHRwPGh0dHBzOi8v cXVpY3dnLm9yZy9iYXNlLWRyYWZ0cy9kcmFmdC1pZXRmLXF1aWMtaHR0cC5odG1sPiBub3IgcXVp Yy1xcGFjazxodHRwczovL3F1aWN3Zy5vcmcvYmFzZS1kcmFmdHMvZHJhZnQtaWV0Zi1xdWljLXFw YWNrLmh0bWw+IGRyYWZ0cyBtZW50aW9uIGNvb2tpZXMgb3IgY3J1bWJsaW5nLiAgSXMgaXQgY29u c2lkZXJlZCBzYWZlIGZvciBhIFFQQUNLIGltcGxlbWVudGF0aW9uIHRvIGNydW1ibGUgY29va2ll cyBiZWZvcmUgY29tcHJlc3Npb24gYW5kIGNvbmNhdGVuYXRlIHRoZW0gYWZ0ZXIgZGVjb21wcmVz c2lvbj8gIElmIHNvLCBzaG91bGQgdGhlIGRyYWZ0IGluY2x1ZGUgY2xhcmlmaWNhdGlvbiBvbiB0 aGlzPw0KDQpUaGFua3MsDQoNCkJlbmNlDQo= --_000_CY4PR22MB09832F11FD842A0290CD7DB0DA100CY4PR22MB0983namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G aWxlZCAjMjc3Ny48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgJmx0 O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkJlbmNlIELD qWt5PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDYsIDIwMTkgNDo1NiBQTTxicj4N CjxiPlRvOjwvYj4gcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBDb29raWUgY3J1 bWJsaW5nIGluIFFQQUNLPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHBzOi8vaHR0cHdnLm9yZy9zcGVjcy9yZmM3NTQwLmh0bWwjQ29tcHJlc3NDb29r aWUiIHRhcmdldD0iX2JsYW5rIj5SRkM3NTQwPC9hPiZuYnNwO2FsbG93cyBjcnVtYmxpbmcmbmJz cDtjb29raWVzIGZvciBjb21wcmVzc2lvbiBlZmZpY2llbmN5IHdpdGggSFBBQ0suJm5ic3A7IEhv d2V2ZXIsIG5laXRoZXINCjxhIGhyZWY9Imh0dHBzOi8vcXVpY3dnLm9yZy9iYXNlLWRyYWZ0cy9k cmFmdC1pZXRmLXF1aWMtaHR0cC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpxdWljLWh0dHA8L2E+ IG5vciA8YSBocmVmPSJodHRwczovL3F1aWN3Zy5vcmcvYmFzZS1kcmFmdHMvZHJhZnQtaWV0Zi1x dWljLXFwYWNrLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCnF1aWMtcXBhY2s8L2E+IGRyYWZ0cyBt ZW50aW9uIGNvb2tpZXMgb3IgY3J1bWJsaW5nLiZuYnNwOyBJcyBpdCBjb25zaWRlcmVkIHNhZmUg Zm9yIGEgUVBBQ0sgaW1wbGVtZW50YXRpb24gdG8gY3J1bWJsZSBjb29raWVzIGJlZm9yZSBjb21w cmVzc2lvbiBhbmQgY29uY2F0ZW5hdGUgdGhlbSBhZnRlciBkZWNvbXByZXNzaW9uPyZuYnNwOyBJ ZiBzbywgc2hvdWxkIHRoZSBkcmFmdCBpbmNsdWRlIGNsYXJpZmljYXRpb24gb24gdGhpcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C ZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR22MB09832F11FD842A0290CD7DB0DA100CY4PR22MB0983namp_-- From nobody Sat Jun 8 13:14:28 2019 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 25DA1120025; Sat, 8 Jun 2019 13:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H7B1wj2uHNg; Sat, 8 Jun 2019 13:14:16 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140047.outbound.protection.outlook.com [40.107.14.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C41120074; Sat, 8 Jun 2019 13:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nUMpcPr18ajIFsddXXQ1SEPGrRalST1j9SZkgqPOVU8=; b=pifMoYW41Z0zoD4Uo35VCrRj7MVqGjGYofa7EEiKSFPyppZYdTUG+Ot5hr/n9lydrusi9O9R+PxG6K0U0Uj057Iw+qr0SwNCBn9whv3+eNrb5Xt1S1Ajlj/0AUWqwXYOHuQYuOnkTKeuwqzQhiDPzVlIuhhHMInPKFdQbuC3fg8= Received: from HE1PR07MB3148.eurprd07.prod.outlook.com (10.170.245.22) by HE1PR07MB3177.eurprd07.prod.outlook.com (10.170.245.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.5; Sat, 8 Jun 2019 20:14:11 +0000 Received: from HE1PR07MB3148.eurprd07.prod.outlook.com ([fe80::d44a:12cc:c916:92ca]) by HE1PR07MB3148.eurprd07.prod.outlook.com ([fe80::d44a:12cc:c916:92ca%7]) with mapi id 15.20.1987.008; Sat, 8 Jun 2019 20:14:11 +0000 From: Mirja Kuehlewind To: "masque@ietf.org" CC: "quic@ietf.org" Subject: FW: New Version Notification for draft-kuehlewind-quic-substrate-00.txt Thread-Topic: New Version Notification for draft-kuehlewind-quic-substrate-00.txt Thread-Index: AQHVHUIiezeDbeUyN0i3J5nDupG4/qaSVHkA Date: Sat, 8 Jun 2019 20:14:11 +0000 Message-ID: References: <155991978677.19940.1367137731581920871.idtracker@ietfa.amsl.com> In-Reply-To: <155991978677.19940.1367137731581920871.idtracker@ietfa.amsl.com> 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=mirja.kuehlewind@ericsson.com; x-originating-ip: [2001:16b8:241b:1f00:8488:afdd:718e:6d11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 601bdcab-0060-48f6-db1a-08d6ec4ddefd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3177; x-ms-traffictypediagnostic: HE1PR07MB3177: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0062BDD52C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(396003)(366004)(346002)(189003)(199004)(53754006)(186003)(5660300002)(2501003)(66574012)(66946007)(66446008)(66556008)(478600001)(5640700003)(71190400001)(446003)(450100002)(83716004)(6916009)(8936002)(44832011)(2616005)(91956017)(73956011)(64756008)(476003)(46003)(6436002)(6506007)(4326008)(486006)(2351001)(11346002)(76176011)(82746002)(14454004)(316002)(305945005)(229853002)(36756003)(2473003)(71200400001)(99286004)(66476007)(6116002)(76116006)(2906002)(6306002)(1730700003)(14444005)(966005)(53936002)(256004)(15650500001)(6512007)(6486002)(25786009)(102836004)(33656002)(81166006)(81156014)(86362001)(7736002)(68736007)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3177; H:HE1PR07MB3148.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: B+sVhO2IstyQJfxGZGzY/RnHeABe/ALJ88zzhLduC3kbCUb8pMFobR/0GAo71QLwu5+aiX/dqChRzjF+hOGVyb1ybTo+EvuMcfTtcYHNNZKCUlj3+5aHmbfzLCCa9bmNQcCPEzLFRYJitAv6x1OUdyN5ZDxB3EWVhPqPNTtRlQH4/hKkNEOrgbp+wFVsL4mk5NJkFJS6tshp1CKLYHJm7MqGXfLfpVad3o6PsIkz7P2DTjqYrt6Fo/RMYStTpw3eDAa8jOBVIQyL/nv+JBCLVznfSk1rrq5CXuN6AinSYXtc5C5r4pqTH5r2B3bTSM7DVwzT9C7+EDLNZQuc6YHuTMeFPoz9yyE/tbJ9l0mvpPNLy5ux4quh6TMha/D3BdkeDt8DHe6B3iXTJRFMMCYgZ4fTSUFY1XqOlzFwqjAO1vo= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 601bdcab-0060-48f6-db1a-08d6ec4ddefd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2019 20:14:11.5240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mirja.kuehlewind@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3177 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 08 Jun 2019 20:14:19 -0000 SGkgZXZlcnlib2R5LA0KDQp3ZSd2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgb24gdXNhZ2Ugc2Nl bmFyaW9zIGZvciBRVUlDIGFzIHN1YnRyYWN0IGFuZCB0dW5uZWxpbmcuIFBsZWFzZSBzZWUgYmVs b3cuIExldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cyBvciBvdGhlciB1c2UgY2Fz ZXMuIEkgYWxzbyBoYXZlIHRoZSBkcmFmdCBvbiBteSBnaXRodWIuIFNvIHlvdSBjYW4gYWxzbyBv cGVuIGlzc3VlcyBvciBzZW5kIFBScyB0aGVyZToNCg0KaHR0cHM6Ly9naXRodWIuY29tL21pcmph ay9kcmFmdC1rdWVobGV3aW5kLXF1aWMtc3Vic3RyYXRlDQoNCkknbSBzZW5kaW5nIHRoaXMgbWFp bCB0byB0aGUgbWFzcXVlIGxpc3QgYXMgd2VsbCBhcyBxdWljIGxpc3QgaW4gb3JkZXIgdG8gaW5m b3JtIHBlb3BsZSB3aG8gbWF5IGJlIGludGVyZXN0ZWQuIEdpdmVuIHRoZSBxdWljIGxpc3QgaXMg dXN1YWxseSBidXN5LCBJIHdvdWxkIHByb3Bvc2UgdG8gZGlyZWN0IGFsbCBkaXNjdXNzaW9uIHRv IHRoZSBtYXNxdWUgbGlzdCAob25seSkuDQoNClRoYW5rcyENCk1pcmphDQoNCg0K77u/T24gMDcu MDYuMTksIDE3OjAzLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPiB3cm90ZToNCg0KICAgIA0KICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1rdWVobGV3aW5kLXF1aWMtc3Vic3RyYXRlLTAwLnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgTWlyamEgS3VlaGxld2luZCBhbmQgcG9zdGVkIHRvIHRoZQ0KICAg IElFVEYgcmVwb3NpdG9yeS4NCiAgICANCiAgICBOYW1lOgkJZHJhZnQta3VlaGxld2luZC1xdWlj LXN1YnN0cmF0ZQ0KICAgIFJldmlzaW9uOgkwMA0KICAgIFRpdGxlOgkJVXNlIENhc2VzIGFuZCBS ZXF1aXJlbWVudHMgZm9yIFFVSUMgYXMgYSBTdWJzdHJhdGUNCiAgICBEb2N1bWVudCBkYXRlOgky MDE5LTA2LTA3DQogICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdlczoJ CTkNCiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWt1ZWhsZXdpbmQtcXVpYy1zdWJzdHJhdGUtMDAudHh0DQogICAgU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1ZWhsZXdpbmQt cXVpYy1zdWJzdHJhdGUvDQogICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1rdWVobGV3aW5kLXF1aWMtc3Vic3RyYXRlLTAwDQogICAgSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQta3VlaGxl d2luZC1xdWljLXN1YnN0cmF0ZQ0KICAgIA0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRD UCBpcyBvZnRlbiB1c2VkIGFzIGEgcHJveHlpbmcgb3IgdHVubmVsaW5nIHByb3RvY29sLiAgUVVJ QyBpcyBhDQogICAgICAgbmV3LCBlbWVyZ2luZyB0cmFuc3BvcnQgcHJvdG9jb2wgYW5kIHRoZXJl IGlzIGEgc2ltaWxhciBleHBlY3RhdGlvbg0KICAgICAgIHRoYXQgaXQgdG9vIHdpbGwgYmUgdXNl ZCBhcyBhIHN1YnN0cmF0ZSBvbmNlIGl0IGlzIHdpZGVseSBkZXBsb3llZC4NCiAgICAgICBVc2lu ZyBRVUlDIGluc3RlYWQgb2YgVENQIGluIGV4aXN0aW5nIHNjZW5hcmlvcyB3aWxsIGFsbG93IHBy b3h5aW5nDQogICAgICAgYW5kIHR1bm5lbGluZyBzZXJ2aWNlcyB0byBtYWludGFpbiB0aGUgYmVu ZWZpdHMgb2YgUVVJQyBuYXRpdmVseSwNCiAgICAgICB3aXRob3V0IGRlZ3JhZGluZyB0aGUgcGVy Zm9ybWFuY2UgYW5kIHNlY3VyaXR5IGNoYXJhY3RlcmlzdGljcy4gIFFVSUMNCiAgICAgICBhbHNv IG9wZW5zIHVwIG5ldyBvcHBvcnR1bml0aWVzIGZvciB0aGVzZSBzZXJ2aWNlcyB0byBoYXZlIGxv d2VyDQogICAgICAgbGF0ZW5jeSBhbmQgYmV0dGVyIG11bHRpc3RyZWFtaW5nIHN1cHBvcnQuICBU aGlzIGRvY3VtZW50IHN1bW1hcml6ZXMNCiAgICAgICBjdXJyZW50IGFuZCBmdXR1cmUgdXNhZ2Ug c2NlbmFyaW9zIHRvIGRlcml2ZSByZXF1aXJlbWVudHMgZm9yIFFVSUMNCiAgICAgICBhbmQgdG8g cHJvdmlkZSBhZGRpdGlvbmFsIHByb3RvY29sIGNvbnNpZGVyYXRpb25zLg0KICAgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAg IA0KICAgIA0KDQo= From nobody Sat Jun 8 17:54:23 2019 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 91B80120120 for ; Sat, 8 Jun 2019 17:54:21 -0700 (PDT) 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 (2048-bit key) header.d=mnot.net header.b=CbiOhTSb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=euh9Jc1h 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 lyCptfeGgU6i for ; Sat, 8 Jun 2019 17:54:16 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF176120072 for ; Sat, 8 Jun 2019 17:54:15 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9D9C521E95 for ; Sat, 8 Jun 2019 20:54:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 08 Jun 2019 20:54:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=76s6vfnMVWWRa3RoJ4XrsDmnHfNtEdTbeaNyenB+k+A=; b=CbiOhTSb ZRAUpTyORAVAgQbc6iQKSzr06NSu6XMR9fLWFnXLYsziyS3xkkoYjoQkVYSm8A0F 4BeKbmDAOGC53J87rvSHFk3VkJmXX3994Za5U1ikFKp9IgWVYxsmFZsLw09NXzBQ JGJbeBk3Edg3FTz7LyN9dDJNTLyodUO1++DY1odEZ2wofi3C441LeACjHFiIFKdL zxxfhDYuvxmfH1pWUmDoXEEZGv33JO+S27E0PqAxrCKIVhHTbSUdcMl5ALWNc7Ok KtAgZEVTVT6+c8fyN4r5/VLTGELIbmCc9FsOKJ9n004ppzVmxRE7V2LfbN+zMDiJ NiPsJRcTFpvOJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=76s6vfnMVWWRa3RoJ4XrsDmnHfNtE dTbeaNyenB+k+A=; b=euh9Jc1h4kiItLrX1GdReRmHiU6t81K8r9HPfV8UBBhD4 LvFs+dUNqKceaPX2ExunzNVmvpqRJah0bxNI++H5dlbL8X7B/A04IuOuAmPjj8Id f7zCZtCiT4lLMAmqd/HBkJqKZ/GqH5Ss7K7mqOY11k9UDc+6kIA/yqv8UnYG1/at hsuGhPEYeXtni4Yh1Oia6kbNFrBNJEL0h/wKl4bawZ1tFmBxYveH4p3Jpnsq7YvE 2FpjDH1bkUZYjco9vownwnYQEpg/8jW2xATWk/wtE3136mmWndEFm64dQqIexb60 H7k6/A+av/TNLkDCIJjYqpSjLNg3lKb2fRCi52mNA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudegledgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 69E88380084 for ; Sat, 8 Jun 2019 20:54:13 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 053D0C2341 for ; Sun, 9 Jun 2019 00:45:15 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7188871959397596174==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190609004516.053D0C2341@cloud.mnot.net> Date: Sun, 9 Jun 2019 00:45:15 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 09 Jun 2019 00:54:22 -0000 --===============7188871959397596174== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+6/-21/=F0=9F=92=AC46) 6 issues created: - HTTP/3 Cookie Crumbling (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2777 [-http] [design] = - Error code to be sent when the size of request headers exceed server's = limit (by kazuho) https://github.com/quicwg/base-drafts/issues/2775 = - HTTP/3 settings frames and prioritization (by tomdedecker) https://github.com/quicwg/base-drafts/issues/2772 = - Stateless Reset becomes a larger risk of amplification with longer CIDs= (by ianswett) https://github.com/quicwg/base-drafts/issues/2770 [-transport] = - Remove QPACK settings maxima as useless (by dtikhonov) https://github.com/quicwg/base-drafts/issues/2766 = - HTTP error codes use inconsistent language (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2765 [-http] [editorial] = 12 issues received 46 new comments: - #2645 Retire My Own CID (11 by DavidSchinazi, mikkelfj, ianswett, erick= innear, nibanks, MikeBishop) https://github.com/quicwg/base-drafts/issues/2645 [-transport] [design] = - #2770 If you want a Stateless Reset you need to send a much larger pack= et than before (7 by martinthomson, ianswett, MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/2770 [-transport] = - #2775 Error code to be sent when the size of request headers exceed ser= ver's limit (6 by kazuho, ianswett, mikkelfj, MikeBishop) https://github.com/quicwg/base-drafts/issues/2775 [-http] = - #2741 Re-visit initial keys discard (5 by DavidSchinazi, kazuho, MikeBi= shop) https://github.com/quicwg/base-drafts/issues/2741 [-tls] [-transport] [= design] = - #2753 NUM_PLACEHOLDERS MUST NOT be zero (3 by kazuho, rmarx, MikeBishop) https://github.com/quicwg/base-drafts/issues/2753 [-http] = - #2754 Lessen the divergence from the HTTP/2 prioritization scheme by re= quiring all PRIORITY frames to be sent on the control stream (3 by rmarx, i= answett, MikeBishop) https://github.com/quicwg/base-drafts/issues/2754 [-http] = - #2772 HTTP/3 settings frames and prioritization (3 by kazuho, tomdedec= ker, MikeBishop) https://github.com/quicwg/base-drafts/issues/2772 [-http] [editorial] = - #2766 Remove QPACK settings maxima as useless (2 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2766 [-qpack] [design] = - #2309 Migration before handshake completed is very messy (2 by martinth= omson, huitema) https://github.com/quicwg/base-drafts/issues/2309 [-transport] [design]= [proposal-ready] = - #2765 HTTP error codes use inconsistent language (2 by dtikhonov, LPard= ue) https://github.com/quicwg/base-drafts/issues/2765 [-http] [editorial] = - #2339 QPACK: instructions and stream description is suboptimal (1 by af= rind) https://github.com/quicwg/base-drafts/issues/2339 [-qpack] [editorial] = - #2734 Placeholder limits make for awkward clients (1 by rmarx) https://github.com/quicwg/base-drafts/issues/2734 [-http] = 21 issues closed: - PRIORITY frame on control stream referencing unopened request stream ht= tps://github.com/quicwg/base-drafts/issues/2502 [-http] = - loss of only two packets can lead to an unrecoverable situation https:/= /github.com/quicwg/base-drafts/issues/2267 [-transport] [design] [has-conse= nsus] = - simultaneous key update can lead to deadlock https://github.com/quicwg/= base-drafts/issues/2214 [-tls] [design] [has-consensus] = - Peers that only terminate a single connection on an IP/port cannot migr= ate with 0-byte CIDs https://github.com/quicwg/base-drafts/issues/2441 [-tr= ansport] [design] [has-consensus] = - Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext https://git= hub.com/quicwg/base-drafts/issues/2581 [-tls] [design] [has-consensus] = - Privacy of spin with multiple connections on same 5 tuple https://githu= b.com/quicwg/base-drafts/issues/2720 [-transport] [editorial] = - Remove QPACK settings maxima as useless https://github.com/quicwg/base-= drafts/issues/2766 [-qpack] [design] = - Avoid creating QPACK codec streams when unnecessary https://github.com/= quicwg/base-drafts/issues/2100 [-qpack] [design] = - Optimistic ACK in early handshake https://github.com/quicwg/base-drafts= /issues/2192 [-transport] [design] [has-consensus] = - Spoofed retry token attack on IP authentication https://github.com/quic= wg/base-drafts/issues/2394 [-transport] [design] [has-consensus] = - 0-RTT flow control limits can't be increased https://github.com/quicwg/= base-drafts/issues/2360 [-transport] [design] [has-consensus] = - Client MUST use 1-RTT packets if it reads 1-RTT packets https://github.= com/quicwg/base-drafts/issues/2458 [-transport] [design] [has-consensus] = - Stateless Reset Lacks Normative Text https://github.com/quicwg/base-dra= fts/issues/2471 [-transport] [design] [has-consensus] = - Saving a round-trip time in the initial handshakes with retry https://g= ithub.com/quicwg/base-drafts/issues/2552 [-transport] [design] [has-consens= us] = - Path validation should be done even for what looks like NAT rebinding h= ttps://github.com/quicwg/base-drafts/issues/2579 [-transport] [design] [has= -consensus] = - Is path validation a SHOULD or a MUST -- pick one! https://github.com/q= uicwg/base-drafts/issues/2580 [-transport] [design] [has-consensus] = - Attacks Against Address Migration https://github.com/quicwg/base-drafts= /issues/2582 [-transport] [design] [has-consensus] = - Transport error codes would be smaller and more consistent as a varint = https://github.com/quicwg/base-drafts/issues/2672 [-transport] [design] [ha= s-consensus] = - Reusing SRTs https://github.com/quicwg/base-drafts/issues/2732 [-transp= ort] [design] [has-consensus] = - Checking duplicate TPs is onerous https://github.com/quicwg/base-drafts= /issues/2689 [-transport] [design] [has-consensus] = - handling of coalesced packets with decryption errors creates DoS opport= unity https://github.com/quicwg/base-drafts/issues/2308 [-transport] [desig= n] [has-consensus] = Pull requests ------------- * quicwg/base-drafts (+7/-17/=F0=9F=92=AC31) 7 pull requests submitted: - Explain initial settings a little more (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2776 [-http] [editorial] = - Discuss max-header-list-size from the other side (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2774 [-http] = - Don't mandate zero server-initiated bidi streams (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2773 [-http] = - Fix typo: s/steam/stream/ (by tomdedecker) https://github.com/quicwg/base-drafts/pull/2771 = - Request to Retire Locally Issues CIDs (by nibanks) https://github.com/quicwg/base-drafts/pull/2769 = - Fix typo: s/overiew/overview/ (by dtikhonov) https://github.com/quicwg/base-drafts/pull/2768 = - Drop maximum value restrictions on QPACK settings (by dtikhonov) https://github.com/quicwg/base-drafts/pull/2767 = 7 pull requests received 31 new comments: - #2769 Request to Retire Locally Issued CIDs (17 by erickinnear, kazuho,= marten-seemann, mikkelfj, nibanks, DavidSchinazi, MikeBishop, ianswett) https://github.com/quicwg/base-drafts/pull/2769 [-transport] = - #2761 allow PRIORITY frames referring to placeholders exceeding `SETTIN= G_NUM_PLACEHOLDERS` (4 by kazuho, rmarx) https://github.com/quicwg/base-drafts/pull/2761 = - #2762 Mandate allowing peer to create enough unidirectional streams for= HTTP and QPACK (3 by ghedo, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/2762 [-http] = - #2370 Stronger migration handshake (3 by DavidSchinazi, huitema) https://github.com/quicwg/base-drafts/pull/2370 [-transport] [design] = - #2749 Allow longer CIDs (2 by mnot, martinduke) https://github.com/quicwg/base-drafts/pull/2749 [-invariants] [-transpo= rt] [design] = - #2557 Simplify kPersistentThreshold (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2557 [-recovery] [editorial] = - #2690 Orphan Placeholder (1 by kazuho) https://github.com/quicwg/base-drafts/pull/2690 [-http] [design] = 17 pull requests merged: - Orphan Placeholder https://github.com/quicwg/base-drafts/pull/2690 [-http] [design] = - Fix typo: s/steam/stream/ https://github.com/quicwg/base-drafts/pull/2771 [-http] [editorial] = - transport: fix broken ref to PTO in recovery https://github.com/quicwg/base-drafts/pull/2758 = - Output of the discard keys design team https://github.com/quicwg/base-drafts/pull/2673 [-tls] [-transport] [de= sign] = - Enable/disable/coordinate spin per path https://github.com/quicwg/base-drafts/pull/2751 [-transport] [editorial= ] = - Drop maximum value restrictions on QPACK settings https://github.com/quicwg/base-drafts/pull/2767 [-qpack] [design] = - Allow not creating QPACK codec streams https://github.com/quicwg/base-drafts/pull/2529 [-qpack] [design] = - Don't use ECN if packets are discarded https://github.com/quicwg/base-drafts/pull/2750 [-transport] [editorial= ] = - fix typo https://github.com/quicwg/base-drafts/pull/2757 [-qpack] [editorial] = - Fix typo: s/overiew/overview/ https://github.com/quicwg/base-drafts/pull/2768 [-http] [editorial] = - 0-RTT can't use transport parameters or 1-RTT frames = https://github.com/quicwg/base-drafts/pull/2461 [-transport] [design] = - Add normative language for stateless reset https://github.com/quicwg/base-drafts/pull/2574 [-transport] = - Stop requiring remote address to match during path validation https://github.com/quicwg/base-drafts/pull/2637 [-transport] [design] = - Change error codes from 16-bit to varints https://github.com/quicwg/base-drafts/pull/2680 [-transport] [design] = - Allow reuse of stateless reset tokens https://github.com/quicwg/base-drafts/pull/2733 [-transport] [design] = - Relax requirement of detecting duplicate TPs on receiver https://github.com/quicwg/base-drafts/pull/2691 [-transport] = - Recommend only one packet per encryption level https://github.com/quicwg/base-drafts/pull/2747 [-transport] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7188871959397596174== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 09, 2019

Issues

quicwg/base-drafts (+6/-21/=F0=9F=92=AC46)

6 issues created:

12 issues received 46 new comments:

21 issues closed:

Pull requests

quicwg/base-drafts (+7/-17/=F0=9F=92=AC31)

7 pull requests submitted:

7 pull requests received 31 new comments:

17 pull requests merged:

Repositories tracked by this digest:

--===============7188871959397596174==-- From nobody Tue Jun 11 00:21:43 2019 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 1C2D8120125 for ; Tue, 11 Jun 2019 00:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=skjWhPXQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KIcqZSm+ 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 FJR9Yxe2iyua for ; Tue, 11 Jun 2019 00:21:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45E212011E for ; Tue, 11 Jun 2019 00:21:37 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DBE0C2223C; Tue, 11 Jun 2019 03:21:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 11 Jun 2019 03:21:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=HOguuSUc1m2bw+Lj2f1pfJtRjD4n9Q IdpkK0By57OBw=; b=skjWhPXQXCFysP0cvkeAVeWqam64NMyhF4elnGlax/GoP8 ZV6Do3aKHm2seHFCszW33cUrGCD9AFpT5u/KohOAtw2vHM6kG44kA/NmPvaOnEX+ 4r1FlTBMriGZfB9fbeGfDey4W0W7VlJgM+BqsSpfR0tYU4o/vhWJSkCzAOWTjxRj s4KYGFXGlWcfi5GMP6uaYX4zt4lJwFpLJz5FVyuqBEWNA26tFdhhbudoROYj4W9V 2HbKgA/w0MraPvNii4js3U9bMdi4jr2EmfuEZQEdLD3lB56xlKgGea6PE47ixibp 6JILykb2fd1on6tzdjqBuUI9TH+pWLsgxSqQV25Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=HOguuS Uc1m2bw+Lj2f1pfJtRjD4n9QIdpkK0By57OBw=; b=KIcqZSm+LlJt6CSkaWwHOE 8fsolPiiHY1q6Df+f/9GOSyXaL3EHjfla45omw5GYmMX5+QgG8Kka2GnY+7Y8wGi l0YNBdHaDW4vA9elgdAomWdeJb16Q6xaRdOkfhoHkx9K6GhVj4c8A9qrizH5yvmb ycH8YlUNLLR0vNnQ3v5tSZkaNv9GIkk/k91xzS8VSf9BdZ0AncqG6luAC1NFgTD9 Ikzfwsg+rRt1XtrqOMXSbVThn5yZEAlDqDLpYABX5Qn+Pd+rkrNwtyizPluuSWYJ 8v4lFUGwRW5DvHnibGJtfe7S/RtEZvbtqakGYbd6/Xk9XsIcOsbQ+z4q50dFQ7Gw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehfedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhtgfgggfukfffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeeh rddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.7.11] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 95B22380083; Tue, 11 Jun 2019 03:21:34 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Reminder: Assigned Issues Message-Id: Date: Tue, 11 Jun 2019 17:21:30 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 07:21:41 -0000 In London, we assigned a number of design issues to owners, who said = they'd produce proposals or otherwise move discussion forward. Please make sure you do so in a timely fashion; we'd like to get the = next set of drafts out with as many such changes in as possible, but to = do so in time (~4 weeks before Montreal), we need to have the PRs, = discuss them, and call consensus. To see the issues assigned to you, replace {user} with your GitHub = username in: https://github.com/quicwg/base-drafts/issues/assigned/{user} Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 11 01:51:34 2019 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 F345C1200DF for ; Tue, 11 Jun 2019 01:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 jMlR4w9Pyrez for ; Tue, 11 Jun 2019 01:51:31 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD141200B1 for ; Tue, 11 Jun 2019 01:51:30 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8773F2006D for ; Tue, 11 Jun 2019 11:51:28 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 68811690720 for ; Tue, 11 Jun 2019 11:51:20 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_4E6BAFDD-9CF1-40A1-8391-F45C22E40AB5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Doodle poll for Second-Quarter 2019 QUIC Virtual Interop Event Date: Tue, 11 Jun 2019 11:51:19 +0300 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> To: QUIC IETF mailing list In-Reply-To: Message-Id: X-MailScanner-ID: 68811690720.AF03F X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 08:51:33 -0000 --Apple-Mail=_4E6BAFDD-9CF1-40A1-8391-F45C22E40AB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please indicate your availability, if you have a stack you wish to test: = https://doodle.com/poll/6r3dyvzb7m6pg6vk (This will be a remote interop. Next physical one will be at the = IETF-105 hackathon in Montreal.) Lars --Apple-Mail=_4E6BAFDD-9CF1-40A1-8391-F45C22E40AB5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAlz/a4cACgkQHbmKvSnu NPjINBAApQPL8onqAct6oS+fS02eLMAyC4b4Z73bPizw4uFk8kFpF9/QZi4SDQld 6xZU1zJ3kLg7jlK1YFnmFc3L+YNObFva8WFW/BWViRNLRP8pzRZAiPR9Qx1WNWB6 L2HangBdPTooFan9x0KUCvesBAZy9jKjXtk0nebwoAkaEWcMRrUQ29ZHbUIe0zQG QyNAnktgrgRyNoSfa4/j79iZtIut74Xf1Y/2spxjQ6O8isbdF+FhJrn4Vd0N2RZj VGL+b8wBBEPqhdWRuCwxLyzXR9n/sq1SgqTokWSag70ODaBZGnXt4wrszNUXMKVU fYPInuAZlnWDL/cu1jWK+gXnwnx3nx5tvWBHbtJhEPdNolQfNqV9H9KXUAEdP+FU rMRY+JWD4eP5YfQhz46jARjNyD+GudWeyH9q+gKfxNu0mebdKn08E4h7l4o0i/p/ 6/h5GJdRGyBc0WrTGjOMUxfaUi+L127AyIoYIfVf3Np8ByUJl/K5CkJhWN6LSDQy 5B4eM9+ygHErXFgjJmxDl9pJPZWJ2/cUruotgU56buZeo5cjEq3Il0UJDFSna55z LD6vVvEP/7wH7h9JCSxEs24Hqe2LKKbDxvpcb1cpDNkANE5Ku4U7sHuAT2i13+nZ /PZKvgxFQjxHg7b9YQtiH7rHxoR1CpFsdPnp3aP79DSEqEpmpdk= =WskV -----END PGP SIGNATURE----- --Apple-Mail=_4E6BAFDD-9CF1-40A1-8391-F45C22E40AB5-- From nobody Tue Jun 11 10:21:48 2019 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 8E7F212003E for ; Tue, 11 Jun 2019 10:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 GARnINTW2b6i for ; Tue, 11 Jun 2019 10:21:45 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 A1FE7120020 for ; Tue, 11 Jun 2019 10:21:45 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id v6so8447184vsq.4 for ; Tue, 11 Jun 2019 10:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dOJItWeXqVTfSAOxQ+3yd3QI/aNhm8yUy1IFlRZ2OeU=; b=N2VnAXjTTh5kpVqg5ECWsZ1pnjIGZPOWKOEyfGHzWUzbOswZXQYbxJxkXX7LspK9B/ zBpn/jYoiiTko2DXCDXFlTm3PhZSfkdh93OzyGUYQr2LGwQnESaizWtHChi/G/hc8nHR CsZRyx/Fr9ds3gf6q2iGEM50BNI20yJQhXtWqBVJ8NrrD3YTPun/IK1mw1POa4Gqn+oO wosuLnfi85fETKILNyLLmeQCeSOGM6H11dqFiAUlDDYdEKgM/kv8WIvz8V7ygsr/ZlOd 17oAgXqQ8lX6+3WY8yOZp7yFLlF6SkBo/nAT36zF3uxqNq1B+DyTf2vL2q4n+BZ2VkOi z7ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dOJItWeXqVTfSAOxQ+3yd3QI/aNhm8yUy1IFlRZ2OeU=; b=p6bWDnFFyRslZOHtWYfQwSZw6akLV1lnlpu62K3lxScKronTQ2CAsW5vtYwylGN0K7 Ld1MYIAcnchVoNBVkwlmCegMFtZRBuKjG8d8sLGAGtXASSZVJm9Ud7LtAq3olv3d65/e NBHonlSa7IVsmBdtmL7zY/j7nYaGhveviYyNUy38rH83pnIZTStf7DiXZsrymy6WnGfZ 4HTU99Q5JHFA4AznK4dTLRx2pJ26By/yThQT1onQeQwfgsivOSVFVUXOBWgwoW4jptiO cVAVsNlFPIsl10kQ2Vf9c7m8namyvUrjhebgByq7mOeyTwU9oPo38GKz+FqDibwSaeQ+ VXJg== X-Gm-Message-State: APjAAAVXWdpBhrg4qk9qZOiMAfJL2UHq9OftUohf1g/W5jhXzQFnj6w6 ZS2S59Nu78rKpZRiiyzvb5p4xDDtpUemZb3wSD3L3ZKY X-Google-Smtp-Source: APXvYqySX+R5PMwG1saX9hvFunblTvjUt+s7BThE2dEQudgNu98G98U1cwWoHr0kW+pCWs8z6NUdgimtShWFFcaT2U8= X-Received: by 2002:a67:d58a:: with SMTP id m10mr22276859vsj.15.1560273704440; Tue, 11 Jun 2019 10:21:44 -0700 (PDT) MIME-Version: 1.0 From: Lucas Pardue Date: Tue, 11 Jun 2019 18:21:33 +0100 Message-ID: Subject: Analysing the HTTP/3 error code space To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 17:21:48 -0000 Hello Working Group, In the London Interim I volunteered to do an analysis of the HTTP/3 error code space. The results shouldn't come as a surprise to many of us but it helps to summarise things in a single place. The most controversial aspect is whether there are too many, too specific error codes. This has come up a few times and now seems as good a time as any to try for consensus. I've offered some suggestions at the end but please do share your opinion. HTTP/3 error codes are based on HTTP/2 error codes. However, because some of HTTP/2s features are subsumed into QUIC, some of the errors are no longer required. Conversely, differences in HTTP/3 mean that new classes of error can arise. For example, HTTP/3 unidirectional stream types add flexibility but invalidate assumptions about mapping between stream ID and usage. This requires extra checks to detect if multiple control streams are created. The carriage of error codes has also changed. In HTTP/2, error codes are carried in RST_STREAM and GOAWAY frames. In HTTP/3, application error codes are carried in QUIC frames: STOP_SENDING, RESET_STREAM and CONNECTION CLOSE (with type 0x1d). Both protocols have errors that relate to streams or the connection as a whole, and stream errors may be upgraded to connection errors. HTTP/2 and HPACK define a total of 13 error codes. 4 of these are not applicable in HTTP/3, yet we presently (draft 20) have a total of 24 error codes across HTTP/3 and QPACK. The list below shoes each error code along with a count that represents number of occurrences of guidance text above or beyond the definition HTTP_NO_ERROR, 1 HTTP_WRONG_SETTING_DIRECTION, 1 HTTP_PUSH_REFUSED, 1 HTTP_INTERNAL_ERROR, 0 HTTP_PUSH_ALREADY_IN_CACHE, 1 HTTP_REQUEST_CANCELLED, 3 HTTP_INCOMPLETE_REQUEST, 4 HTTP_CONNECT_ERROR, 1 HTTP_EXCESSIVE_LOAD, 1 HTTP_VERSION_FALLBACK. 0 HTTP_WRONG_STREAM, 8 HTTP_LIMIT_EXCEEDED, 2 HTTP_DUPLICATE_PUSH, 1 HTTP_UNKNOWN_STREAM_TYPE, 1 HTTP_WRONG_STREAM_COUNT, 2 HTTP_CLOSED_CRITICAL_STREAM, 2 HTTP_WRONG_STREAM_DIRECTION, 1 HTTP_EARLY_RESPONSE, 1 HTTP_MISSING_SETTINGS, 1 HTTP_UNEXPECTED_FRAME, 8 HTTP_REQUEST_REJECTED, 4 HTTP_GENERAL_PROTOCOL_ERROR, 0 HTTP_MALFORMED_FRAME, 9 HTTP_QPACK_DECOMPRESSION_FAILED, 6 HTTP_QPACK_ENCODER_STREAM_ERROR, 4 HTTP_QPACK_DECODER_STREAM_ERROR, 3 Of the total 24 error frames, 14 are only send in the case of a connection error. The remainder are sent as stream errors, which could be upgraded to connection errors. One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been replaced by HTTP_MALFORMED_FRAME, which actually covers a range of values - it dedicates a byte to encode the frame type. This is problematic since the frame type changed to be a 62-bit integer itself. In my personal opinion, this error code is more complicated than needs be and was incorrectly applied. Issue #2551 [1] captures this, and PR #2662 [2] contains a proposed set of replacement codes. That PR adds 4 error codes to bring the total up to 28. Some observations and suggestions: 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3 error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no single equivalent, which I think is incorrect becuase HTTP/3 has HTTP_GENERAL_PROTOCOL_ERROR. 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and very similar. The former is used by a peer that receives a valid frame on a stream that it should never be sent on, the latter is used by a peer that receives a valid frame on a stream that is normally ok but has transitioned to an application-level stream state which prohibits it. Rationalising these seems like a logical option. 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case, a client send NUM_PLACEHOLDER. Declassifying this as an error seems like a sensile option. This frees up error code 0x1, which we can move HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2). 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar but may be useful to understand the different reason that clients reject server push. This is extra fidelity on top of HTTP/2. 4) There are several error codes related to handling requests and responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than HTTP/2 provided. This may extra information may allow endpoints to make smarter decisions about retrying requests. However, it may also be possible to infer things from a stream error that contains simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONSE could benefit from this) 5) The error code guidance is often not symmetric. Client or servers use error codes differently and little guidance is provided on how to process an error code that in theory should never be sent. 6) There is little guidance on how an intermediary that translates between HTTP/2 and HTTP/3 should map these divergent error code spaces. It would pay to align them as close as possible and provide some guidance on how to map higher fidelity codes to lower fidelity codes. 7) There are several error cases related to SETTINGS; a frame that can be sent most once per connection. I made a proposal to address this on issue #2783 [3] 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing the unidirectional stream type header. We might be able to merge these into a error such as HTTP_STREAM_HEADER_ERROR and state the code has different applicability between STOP_SENDING and CONNECTION_CLOSE frames. 9) Critical streams such as control stream and QPACK streams can be created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams can only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures this. We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could even incorporate suggestion 8. 10) There are 3 QPACK errors in contrast to 1 HPACK error. I think this is fair given the new complexity and scope for implementations to make errors. Cheers, Lucas [1] - https://github.com/quicwg/base-drafts/issues/2551 [2] - https://github.com/quicwg/base-drafts/pull/2662 [3] - https://github.com/quicwg/base-drafts/issues/2783 From nobody Tue Jun 11 11:14:07 2019 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 4B7F5120099 for ; Tue, 11 Jun 2019 11:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40IHNx0k6x6L for ; Tue, 11 Jun 2019 11:14:02 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 E452F1200DF for ; Tue, 11 Jun 2019 11:14:01 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id f9so14061485wre.12 for ; Tue, 11 Jun 2019 11:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pBl/W3bqRCGwY4AWlDyxJJskh4P0kWCswxSzgsWFA1Y=; b=t84UE2ftD74Oql5vRJyC4jo/hHisCiel1rwKJwFfAFkC2gVnJALAKfKMLC3IFPNI+J kQSdYEhvV0wkRRAAUDvgc/OyN0TRf43O31BJUCbs57ch2b+5eMslLTXNOwFdJ0dTd6QU bUAWgBXZZtdNfTYZWk6M00JX5ZjV1MFdyEIezo/AOp22Y3Mx7yVsOlznZZ78BjeYJZjk 7UgvMIvRSS0cqdARvgln32+xlwpFlsgG1aZpkmxjieQ1CJyj1CPt0icuCRGMr/cHmGca wcYqonGt2jv3fXvlheGcgbTvPvcrNX8OA/AdCIoY8b3252BkEbNYfiIIIYfPk156Fb/A 7qcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pBl/W3bqRCGwY4AWlDyxJJskh4P0kWCswxSzgsWFA1Y=; b=N3IxRYzkBs0yuz1pyhorsdygeEewehHf+nJzGEuHcV6c3E7NhiTuFUYwS2S7fKZSOx +VNGh794YAlLi1hnv/gH5c4uzaskVv8DHXpjRdHq02QoFio+4rKaittBSZA1fOwjlnGc NRt54gk+m+vqCY/YAmgJkvW0Tde3w91I3I51u0f0WtOlDE+x5Ekh1vXyobRlQKDJXO8n lpg9hByQUN/F6ZSp65CP8pm+Cz80RtstF+AG0YRigNNgrSkeLOj/vYcwEORk+8mK5hwS oefk5HaQNMsT2r/OlPpZrXO3FrQXLUqfZCMV/R7nsQjZ3GSw3gIgkzXxVeEO178KJMcb pL0g== X-Gm-Message-State: APjAAAVW+9FcN12JChpH40P0V5Y3ot62+lG7qSb4R+4coiizga+rK0V3 6zJ3LhKV6lRt8uiJA/iNS+KcQ9mDLHkRz+SU3JKawQ== X-Google-Smtp-Source: APXvYqxyEG+Mqc+zGKTmW3F+gF1Pa/7ch3usgI18zGf0PYu1ez50nLiG1PRIu23ENMv4BFe6HHasCL//YaRsxwePFfs= X-Received: by 2002:adf:f046:: with SMTP id t6mr4419056wro.307.1560276839830; Tue, 11 Jun 2019 11:13:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Tue, 11 Jun 2019 14:13:47 -0400 Message-ID: Subject: Re: Analysing the HTTP/3 error code space To: Lucas Pardue Cc: QUIC WG Content-Type: multipart/alternative; boundary="000000000000ca86ef058b104293" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 18:14:05 -0000 --000000000000ca86ef058b104293 Content-Type: text/plain; charset="UTF-8" Thanks for the awesome work, a few comments below, but I think I'm happy with your suggested changes. On Tue, Jun 11, 2019 at 1:21 PM Lucas Pardue wrote: > Hello Working Group, > > In the London Interim I volunteered to do an analysis of the HTTP/3 > error code space. The results shouldn't come as a surprise to many of > us but it helps to summarise things in a single place. The most > controversial aspect is whether there are too many, too specific error > codes. This has come up a few times and now seems as good a time as > any to try for consensus. I've offered some suggestions at the end but > please do share your opinion. > > HTTP/3 error codes are based on HTTP/2 error codes. However, because > some of HTTP/2s features are subsumed into QUIC, some of the errors > are no longer required. Conversely, differences in HTTP/3 mean that > new classes of error can arise. For example, HTTP/3 unidirectional > stream types add flexibility but invalidate assumptions about mapping > between stream ID and usage. This requires extra checks to detect if > multiple control streams are created. > > The carriage of error codes has also changed. In HTTP/2, error codes > are carried in RST_STREAM and GOAWAY frames. In HTTP/3, application > error codes are carried in QUIC frames: STOP_SENDING, RESET_STREAM and > CONNECTION CLOSE (with type 0x1d). Both protocols have errors that > relate to streams or the connection as a whole, and stream errors may > be upgraded to connection errors. > > HTTP/2 and HPACK define a total of 13 error codes. 4 of these are not > applicable in HTTP/3, yet we presently (draft 20) have a total of 24 > error codes across HTTP/3 and QPACK. The list below shoes each error > code along with a count that represents number of occurrences of > guidance text above or beyond the definition > > HTTP_NO_ERROR, 1 > HTTP_WRONG_SETTING_DIRECTION, 1 > HTTP_PUSH_REFUSED, 1 > HTTP_INTERNAL_ERROR, 0 > HTTP_PUSH_ALREADY_IN_CACHE, 1 > HTTP_REQUEST_CANCELLED, 3 > HTTP_INCOMPLETE_REQUEST, 4 > HTTP_CONNECT_ERROR, 1 > HTTP_EXCESSIVE_LOAD, 1 > HTTP_VERSION_FALLBACK. 0 > HTTP_WRONG_STREAM, 8 > HTTP_LIMIT_EXCEEDED, 2 > HTTP_DUPLICATE_PUSH, 1 > HTTP_UNKNOWN_STREAM_TYPE, 1 > HTTP_WRONG_STREAM_COUNT, 2 > HTTP_CLOSED_CRITICAL_STREAM, 2 > HTTP_WRONG_STREAM_DIRECTION, 1 > HTTP_EARLY_RESPONSE, 1 > HTTP_MISSING_SETTINGS, 1 > HTTP_UNEXPECTED_FRAME, 8 > HTTP_REQUEST_REJECTED, 4 > HTTP_GENERAL_PROTOCOL_ERROR, 0 > HTTP_MALFORMED_FRAME, 9 > HTTP_QPACK_DECOMPRESSION_FAILED, 6 > HTTP_QPACK_ENCODER_STREAM_ERROR, 4 > HTTP_QPACK_DECODER_STREAM_ERROR, 3 > > Of the total 24 error frames, 14 are only send in the case of a > connection error. The remainder are sent as stream errors, which could > be upgraded to connection errors. > > One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been > replaced by HTTP_MALFORMED_FRAME, which actually covers a range of > values - it dedicates a byte to encode the frame type. This is > problematic since the frame type changed to be a 62-bit integer > itself. In my personal opinion, this error code is more complicated > than needs be and was incorrectly applied. Issue #2551 [1] captures > this, and PR #2662 [2] contains a proposed set of replacement codes. > That PR adds 4 error codes to bring the total up to 28. > I like your proposed PR. > > Some observations and suggestions: > > 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3 > error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no > single equivalent, which I think is incorrect becuase HTTP/3 has > HTTP_GENERAL_PROTOCOL_ERROR. > 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and very > similar. The former is used by a peer that receives a valid frame on a > stream that it should never be sent on, the latter is used by a peer > that receives a valid frame on a stream that is normally ok but has > transitioned to an application-level stream state which prohibits it. > Rationalising these seems like a logical option. 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case, > a client send NUM_PLACEHOLDER. Declassifying this as an error seems > like a sensile option. This frees up error code 0x1, which we can move > HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2). 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar > but may be useful to understand the different reason that clients > reject server push. This is extra fidelity on top of HTTP/2. 4) There are several error codes related to handling requests and > responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, > HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity > than HTTP/2 provided. This may extra information may allow endpoints > to make smarter decisions about retrying requests. However, it may > also be possible to infer things from a stream error that contains > simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONSE could benefit from this) > 5) The error code guidance is often not symmetric. Client or servers > use error codes differently and little guidance is provided on how to > process an error code that in theory should never be sent. > 6) There is little guidance on how an intermediary that translates > between HTTP/2 and HTTP/3 should map these divergent error code > spaces. It would pay to align them as close as possible and provide > some guidance on how to map higher fidelity codes to lower fidelity > codes. > 7) There are several error cases related to SETTINGS; a frame that can > be sent most once per connection. I made a proposal to address this on > issue #2783 [3] > 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing > the unidirectional stream type header. We might be able to merge these > into a error such as HTTP_STREAM_HEADER_ERROR and state the code has > different applicability between STOP_SENDING and CONNECTION_CLOSE > frames. > 9) Critical streams such as control stream and QPACK streams can be > created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams > can only be created by a server and HTTP_WRONG_STREAM_DIRECTION > captures this. We could rationalise these into > HTTP_STREAM_CREATION_ERROR, that could even incorporate suggestion 8. > 10) There are 3 QPACK errors in contrast to 1 HPACK error. I think > this is fair given the new complexity and scope for implementations to > make errors. Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which are never used? I'm unclear on what the intended usage is? > > > Cheers, > Lucas > > > [1] - https://github.com/quicwg/base-drafts/issues/2551 > [2] - https://github.com/quicwg/base-drafts/pull/2662 > [3] - https://github.com/quicwg/base-drafts/issues/2783 > > --000000000000ca86ef058b104293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0for the awesome work, a few c= omments below, but I think I'm happy with your suggested changes.
=
On Tue= , Jun 11, 2019 at 1:21 PM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
Hello Working Group,

In the London Interim I volunteered to do an analysis of the HTTP/3
error code space. The results shouldn't come as a surprise to many of us but it helps to summarise things in a single place. The most
controversial aspect is whether there are too many, too specific error
codes. This has come up a few times and now seems as good a time as
any to try for consensus. I've offered some suggestions at the end but<= br> please do share your opinion.

HTTP/3=C2=A0 error codes are based on HTTP/2 error codes. However, because<= br> some of HTTP/2s features are subsumed into QUIC, some of the errors
are no longer required. Conversely, differences in HTTP/3 mean that
new classes of error can arise. For example, HTTP/3 unidirectional
stream types add flexibility but invalidate assumptions about mapping
between stream ID and usage. This requires extra checks to detect if
multiple control streams are created.

The carriage of error codes has also changed. In HTTP/2, error codes
are carried in RST_STREAM and GOAWAY frames. In HTTP/3, application
error codes are carried in QUIC frames: STOP_SENDING, RESET_STREAM and
CONNECTION CLOSE (with type 0x1d). Both protocols have errors that
relate to streams or the connection as a whole, and stream errors may
be upgraded to connection errors.

HTTP/2 and HPACK define a total of 13 error codes. 4 of these are not
applicable in HTTP/3, yet we presently (draft 20) have a total of 24
error codes across HTTP/3 and QPACK. The list below shoes each error
code along with=C2=A0 a count that represents number of occurrences of
guidance text above or beyond the definition

HTTP_NO_ERROR, 1
HTTP_WRONG_SETTING_DIRECTION, 1
HTTP_PUSH_REFUSED, 1
HTTP_INTERNAL_ERROR, 0
HTTP_PUSH_ALREADY_IN_CACHE, 1
HTTP_REQUEST_CANCELLED, 3
HTTP_INCOMPLETE_REQUEST, 4
HTTP_CONNECT_ERROR, 1
HTTP_EXCESSIVE_LOAD, 1
HTTP_VERSION_FALLBACK. 0
HTTP_WRONG_STREAM, 8
HTTP_LIMIT_EXCEEDED, 2
HTTP_DUPLICATE_PUSH, 1
HTTP_UNKNOWN_STREAM_TYPE, 1
HTTP_WRONG_STREAM_COUNT, 2
HTTP_CLOSED_CRITICAL_STREAM, 2
HTTP_WRONG_STREAM_DIRECTION, 1
HTTP_EARLY_RESPONSE, 1
HTTP_MISSING_SETTINGS, 1
HTTP_UNEXPECTED_FRAME, 8
HTTP_REQUEST_REJECTED, 4
HTTP_GENERAL_PROTOCOL_ERROR, 0
HTTP_MALFORMED_FRAME, 9
HTTP_QPACK_DECOMPRESSION_FAILED, 6
HTTP_QPACK_ENCODER_STREAM_ERROR, 4
HTTP_QPACK_DECODER_STREAM_ERROR, 3

Of the total 24 error frames, 14 are only send in the case of a
connection error. The remainder are sent as stream errors, which could
be upgraded to connection errors.

One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been
replaced by HTTP_MALFORMED_FRAME, which actually covers a range of
values - it dedicates a byte to encode the frame type. This is
problematic since the frame type changed to be a 62-bit integer
itself.=C2=A0 In my personal opinion, this error code is more complicated than needs be and was incorrectly applied. Issue #2551 [1] captures
this, and PR #2662 [2] contains a proposed set of replacement codes.
That PR adds 4 error codes to bring the total up to 28.

I like your proposed PR.=C2=A0

Some observations and suggestions:

0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3
error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no
single equivalent, which I think is incorrect becuase HTTP/3 has
HTTP_GENERAL_PROTOCOL_ERROR.
1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and very
similar. The former is used by a peer that receives a valid frame on a
stream that it should never be sent on, the latter is used by a peer
that receives a valid frame on a stream that is normally ok but has
transitioned to an application-level stream state which prohibits it.
Rationalising these seems like a logical option.
2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case,
a client send NUM_PLACEHOLDER. Declassifying this as an error seems
like a sensile option. This frees up error code 0x1, which we can move
HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2).
3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar
but may be useful to understand the different reason that clients
reject server push. This is extra fidelity on top of HTTP/2.
4) There are several error codes related to handling requests and
responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST,
HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity
than HTTP/2 provided. This may extra information may allow endpoints
to make smarter decisions about retrying requests. However, it may
also be possible to infer things from a stream error that contains
simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONSE could benefit from this)
5) The error code guidance is often not symmetric. Client or servers
use error codes differently and little guidance is provided on how to
process an error code that in theory should never be sent.
6) There is little guidance on how an intermediary that translates
between HTTP/2 and HTTP/3 should map these divergent error code
spaces. It would pay to align them as close as possible and provide
some guidance on how to map higher fidelity codes to lower fidelity
codes.
7) There are several error cases related to SETTINGS; a frame that can
be sent most once per connection. I made a proposal to address this on
issue #2783 [3]
8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing
the unidirectional stream type header. We might be able to merge these
into a error such as HTTP_STREAM_HEADER_ERROR and state the code has
different applicability between STOP_SENDING and CONNECTION_CLOSE
frames.
9) Critical streams such as control stream and QPACK streams can be
created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams
can only be created by a server and HTTP_WRONG_STREAM_DIRECTION
captures this. We could rationalise these into
HTTP_STREAM_CREATION_ERROR, that could even incorporate suggestion 8.
10) There are 3 QPACK errors in contrast to 1 HPACK error. I think
this is fair given the new complexity and scope for implementations to
make errors.

Any thoughts on=C2=A0HTTP_VERS= ION_FALLBACK and HTTP_INTERNAL_ERROR, which are never used?=C2=A0 I'm u= nclear on what the intended usage is?=C2=A0


Cheers,
Lucas


[1] - https://github.com/quicwg/base-drafts/issues/= 2551
[2] - https://github.com/quicwg/base-drafts/pull/2662=
[3] - https://github.com/quicwg/base-drafts/issues/= 2783

--000000000000ca86ef058b104293-- From nobody Tue Jun 11 11:53:35 2019 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 E40D2120100 for ; Tue, 11 Jun 2019 11:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 lz4Az-m3d10H for ; Tue, 11 Jun 2019 11:53:31 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 65BC512006A for ; Tue, 11 Jun 2019 11:53:26 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id z13so4690001uaa.4 for ; Tue, 11 Jun 2019 11:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rcDjkjPP7cspNz2WGvShVfeyBGwKArVU3wt8qWTQ2QA=; b=VLKmR/P/h/CTWhSbSL1jWGn4h9Dfe412YkvWp40vMhyJ10SL4oYLg6gMrWZABj2Kd0 NL55pJhOtkZy0HW6ijfuUSrFjDINHdrIkbYPwsIVHyWUduu32PXuM9WKis5Zq6fA0Yi5 vvQtlLhBKZrD5TlC/Gl/YZbiq8R26pzJuiSvrWyYgRgGCrhGzzJ6JeqbJFyf3R5D8tZ7 8x+sBv1piAeXNxywe23a4f3KHF4m+lmkmncalbiN6tacY2Ea8AhXTbRFWcYUOQ4IcEPH NJhYm67b7kUaeo9A6Vzx/Ar9JfxOTsJSWfiKUhV50d/ATvanzh7Rou4ufpD7kBuiIN30 X9bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rcDjkjPP7cspNz2WGvShVfeyBGwKArVU3wt8qWTQ2QA=; b=dXzUudn+/cvoWZVhQEBK+XQ8m9B2AZHvfxxQqJzJ8WynBxTCbdOHXgczLR6ZGPVb2A baVu7LglfVGoefWBVhaOdR1BMgls6cF97huW/GBUHB0zeMPQROR/pOOmG/uwk4on4nYO RAKVUDUpmXX5aGgb74bshwVDfr6S4oIQzcraqxrR9H/3bHpxW1yPakXAuOdl6QvM13JJ rZbXboge931NBrIx2S+9Bpo8wjxU0bRIqVbiejY7yiuO6SRXTVbo5CFXzR6Wng2zQvKg o4pMjQ3dgPMwS4WIOzrUKRzEc92Z2pLIj4ozvPFwjH5sRx6yX1ndRpLLFOHtVWofX4MB NWhQ== X-Gm-Message-State: APjAAAWS5jdXsafsNFBPJTNbNYcb/8YvEsa3BJZQpA0CrBZ9ioQGsLlx FH62Bg16x68d7tqD4Jub0IKkUcE2yB3fZZAcn0c= X-Google-Smtp-Source: APXvYqyrQGTcGr9rUGUbL7fTugwSm/Ls21xRMXxzWyqQdtAkOjjTIV+ojjbRUvk0KX2ZFwD6ruQc6xQ/ZC0/Zey9ZVw= X-Received: by 2002:ab0:3406:: with SMTP id z6mr2668106uap.102.1560279205455; Tue, 11 Jun 2019 11:53:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Tue, 11 Jun 2019 19:53:13 +0100 Message-ID: Subject: Re: Analysing the HTTP/3 error code space To: Ian Swett Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 18:53:33 -0000 Hey Ian, On Tue, Jun 11, 2019 at 7:14 PM Ian Swett wrote: > >> >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been >> replaced by HTTP_MALFORMED_FRAME, which actually covers a range of >> values - it dedicates a byte to encode the frame type. This is >> problematic since the frame type changed to be a 62-bit integer >> itself. In my personal opinion, this error code is more complicated >> than needs be and was incorrectly applied. Issue #2551 [1] captures >> this, and PR #2662 [2] contains a proposed set of replacement codes. >> That PR adds 4 error codes to bring the total up to 28. > > > I like your proposed PR. Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for things that are frame size errors) and adds some new error codes in agreement with our current philosophy. I would refine the PR to agree with the outcome of this thread. > > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which are never used? I'm unclear on what the intended usage is? I realised I didn't qualify one aspect of my analysis - the guidance count metric is only one signal. HTTP_INTERNAL_ERROR is described as "An internal error has occurred in the HTTP stack.", which feels like an implementation-oriented error code. I think it is valid in staying in HTTP/3, especially if it is used in HTTP/2 (I don't have data to hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is only recommended when the server wants to use TLS renegotiation. IMO it is of limited value unless we import the same behaviour into HTTP/3. From nobody Tue Jun 11 12:36:51 2019 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 8DE2C120099 for ; Tue, 11 Jun 2019 12:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 w81WlEJJkTFS for ; Tue, 11 Jun 2019 12:36:47 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 6A0C5120059 for ; Tue, 11 Jun 2019 12:36:47 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id e16so14352389wrn.1 for ; Tue, 11 Jun 2019 12:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6nqFT45PjofiiJxUF+XB9VqJPcBYF/86ce7x0Tu4/A=; b=bwfwfAwlox1g2Ho5NwT418t3xaHfJKF8yYehsAxJZKMKXD3uzeGzUtXMhaxGFmZNik AlVzhJqp8PM9ytsCSpDfarFIX1HaDTHrxaJsp/mfPphKv58JwNeuCbOz03hSi+wv9c/a lfC525ibdoMT+eS/6tFb6fzafbXUz5ZG6RhxkrO88l1hFFq8ryR4RSRCZixrMB3WJjYX c7pxq0cRL06GGWBU5lj7lqR5YkDW4/fDDQTRQSExKsTX5i3u5PAFkLgPVGBF/vtoV7/4 s4hY38qgp5K+03yL1VoATl2eqS5yA3zf4gGiNH9lYUWSB33f0WQ/dVYhyrb1HH7o/pqx wlhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E6nqFT45PjofiiJxUF+XB9VqJPcBYF/86ce7x0Tu4/A=; b=SoLIYCgXKdUFMaJkbddwDb/pl3Aryk5/Dwg5zg6SE1vvJQm+q5mx9mpAP+vEKtbK1A SlDjxSUIB2cLsXUimAiEXHrMEyQ3V0hqrPJorHPtwt8HfTKs5Jdyc3L3JM+oq/q3eX0e 8Hm6ifTwSzD3y+3Jen56mzQEFadRaVOLConuLfXzvJknn9CV9CKPq6Fq9wLGebc6aIZf nJNPIaB8driGsgfBnNYoL1KvRqJnYMAljlzrxRcgLfDkygM7Arb5NLAX+d070+d7thzs xcu9XuYU7QoGyMNZm0SK6DTH9JuX/8vs+CB0Zz4kIGlbVcqIQyCclKMpzrbebfGV83j4 IQyA== X-Gm-Message-State: APjAAAV5TbqGzVsrjr4ytzvqc0eQDZwJIaokSLYZwVfqG6BFFSuftx6z 7aGKq9GJQLz/dmu/DMdVyxeYFkaJVsn+ok1ENbM= X-Google-Smtp-Source: APXvYqyEx58YTvBmXEhKs97bZhF1DIFM1ezaFiSu4Ua3bDmYfAoq0PQBx6VqOoJv54u0bF6JcivM4GxAN6rTKtghrf0= X-Received: by 2002:adf:9d81:: with SMTP id p1mr1467022wre.294.1560281805851; Tue, 11 Jun 2019 12:36:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Tue, 11 Jun 2019 12:36:34 -0700 Message-ID: Subject: Re: Analysing the HTTP/3 error code space To: Lucas Pardue Cc: Ian Swett , QUIC WG Content-Type: multipart/alternative; boundary="000000000000c99287058b116aa9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 19:36:50 -0000 --000000000000c99287058b116aa9 Content-Type: text/plain; charset="UTF-8" I would insist on INTERNAL_ERROR. It is great for various malloc problems, as well as for signalling that something went wrong on the back end in proxy scenarios. It is a catch-all for "I screwed up and can't continue". On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue wrote: > Hey Ian, > > On Tue, Jun 11, 2019 at 7:14 PM Ian Swett wrote: > > > >> > >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been > >> replaced by HTTP_MALFORMED_FRAME, which actually covers a range of > >> values - it dedicates a byte to encode the frame type. This is > >> problematic since the frame type changed to be a 62-bit integer > >> itself. In my personal opinion, this error code is more complicated > >> than needs be and was incorrectly applied. Issue #2551 [1] captures > >> this, and PR #2662 [2] contains a proposed set of replacement codes. > >> That PR adds 4 error codes to bring the total up to 28. > > > > > > I like your proposed PR. > > Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for > things that are frame size errors) and adds some new error codes in > agreement with our current philosophy. I would refine the PR to agree > with the outcome of this thread. > > > > > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which are > never used? I'm unclear on what the intended usage is? > > I realised I didn't qualify one aspect of my analysis - the guidance > count metric is only one signal. HTTP_INTERNAL_ERROR is described as > "An internal error has occurred in the HTTP stack.", which feels like > an implementation-oriented error code. I think it is valid in staying > in HTTP/3, especially if it is used in HTTP/2 (I don't have data to > hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; > it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is > only recommended when the server wants to use TLS renegotiation. IMO > it is of limited value unless we import the same behaviour into > HTTP/3. > > --000000000000c99287058b116aa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would insist on INTERNAL_ERROR. It is great for various = malloc problems, as well as for signalling that something went wrong on the= back end in proxy scenarios. It is a catch-all for "I screwed up and = can't continue".

On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue= <lucaspardue.24.7@gmail.c= om> wrote:
ianswett@google.com> wrote:
>
>>
>> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has b= een
>> replaced by HTTP_MALFORMED_FRAME, which actually covers a range of=
>> values - it dedicates a byte to encode the frame type. This is
>> problematic since the frame type changed to be a 62-bit integer >> itself.=C2=A0 In my personal opinion, this error code is more comp= licated
>> than needs be and was incorrectly applied. Issue #2551 [1] capture= s
>> this, and PR #2662 [2] contains a proposed set of replacement code= s.
>> That PR adds 4 error codes to bring the total up to 28.
>
>
> I like your proposed PR.

Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for
things that are frame size errors) and adds some new error codes in
agreement with our current philosophy. I would refine the PR to agree
with the outcome of this thread.

>
> Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which a= re never used?=C2=A0 I'm unclear on what the intended usage is?

I realised I didn't qualify one aspect of my analysis - the guidance count metric is only one signal. HTTP_INTERNAL_ERROR is described as
"An internal error has occurred in the HTTP stack.", which feels = like
an implementation-oriented error code. I think it is valid in staying
in HTTP/3, especially if it is used in HTTP/2 (I don't have data to
hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird;
it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is
only recommended when the server wants to use TLS renegotiation. IMO
it is of limited value unless we import the same behaviour into
HTTP/3.

--000000000000c99287058b116aa9-- From nobody Tue Jun 11 14:40:53 2019 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 43E6D120098 for ; Tue, 11 Jun 2019 14:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=evequefou.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 aX6LvohT7_TT for ; Tue, 11 Jun 2019 14:40:47 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770111.outbound.protection.outlook.com [40.107.77.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982CE12003F for ; Tue, 11 Jun 2019 14:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fzIZYOLUgTz/Z2Y0/0eWFDCnmySVadODBVA9nbOHpLY=; b=UEzE/sylVxC+Br+3lRwjyc7+PZjtVjp+qiN+MBTaJjEjl3ruiJm+dY2nUqKnmhBN4mc5oaJxd4Chkujc4j+jPG85VN+iTXBJVf1/w2q+Uty6GESlsRkvimFZs0Hai/M5Jp4hUMocaocGarhp/Oon6VGwX/ZL7oWQ07NsyqUjBUQ= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0102.namprd22.prod.outlook.com (10.169.185.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Tue, 11 Jun 2019 21:40:45 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1987.010; Tue, 11 Jun 2019 21:40:45 +0000 From: Mike Bishop To: Martin Duke , Lucas Pardue CC: Ian Swett , QUIC WG Subject: RE: Analysing the HTTP/3 error code space Thread-Topic: Analysing the HTTP/3 error code space Thread-Index: AQHVIHowKD1gaSBv6kuSLW6XelpUtaaWwd6AgAALBYCAAAwcAIAAGiJw Date: Tue, 11 Jun 2019 21:40:45 +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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5721505-913e-4d0e-97db-08d6eeb575f6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0102; x-ms-traffictypediagnostic: CY4PR22MB0102: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(346002)(136003)(39830400003)(189003)(199004)(76116006)(66446008)(25786009)(52536014)(66476007)(66946007)(7696005)(64756008)(73956011)(66066001)(6506007)(4326008)(14454004)(86362001)(81166006)(81156014)(53936002)(54896002)(66556008)(9686003)(236005)(54906003)(508600001)(76176011)(33656002)(99286004)(6246003)(55016002)(53546011)(6306002)(110136005)(102836004)(5660300002)(2906002)(229853002)(186003)(6436002)(316002)(68736007)(3846002)(256004)(14444005)(7736002)(71200400001)(8676002)(561944003)(790700001)(446003)(26005)(6116002)(74482002)(71190400001)(476003)(8936002)(486006)(11346002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0102; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WkRdFSSmZDc3gLks1/TVAJkeeJrtVluk0Olkt1GPi1mrHieavMKfnMsq0xWdZk1ycNXmWEMs7iEBy1fI4sAQq1uUlyJGv/zbssDAu9vfavnHwuTbv6RSfiDcl8iwMcLMzF2MVvSu0IxETyCtIdeClCRAn0qmV0rR23R5/irR03S+otYCDk4VU/sSUlpCHL5B9IMXHVCdFOvv/11yfnVZtBTzEWaVrhVLy77pV4xZbIDu0xVVQxzX5axnsvnU/+LYyBn1bo/MNYw+aU855Mp/gjf72YcBIUYmp8vyzrQZultiMZUnGRMNrst1m8LqdbxQI7/syd1uxQINtsMAJB4NtHAo7AyJUXc8I9NF0OH86WY7dCp7YGrfV/4e+U4aJmOoLcv8qmUz4DIDblmb3E58K2QbCqd86vzmQwPZ5pNlLO0= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB09836F1DC79AE7B1BC49A494DAED0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c5721505-913e-4d0e-97db-08d6eeb575f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 21:40:45.4579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0102 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 11 Jun 2019 21:40:51 -0000 --_000_CY4PR22MB09836F1DC79AE7B1BC49A494DAED0CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgcHJldmlvdXNseSBhZmZpbGlhdGVkIHdpdGggYW4gSFRUUCBzdGFjayB0aGF0IEkgYXNz dW1lIHN0aWxsIG5lZWRzIEhUVFBfVkVSU0lPTl9GQUxMQkFDSyBmb3Igc29tZSBjb3JuZXIgY2Fz ZXMgaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHJlbmVnb3RpYXRpb24uICBUaGlzIFdH IHByZXZpb3VzbHkgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIGl0IHNob3VsZCBmYWxs IGJhY2sgdG8gSFRUUC8yIChsb2dpY2FsLCBidXQgbGlrZWx5IGhhcyBhbGwgdGhlIHNhbWUgaW5j b21wYXRpYmxlIHNjZW5hcmlvcyB0aGF0IEhUVFAvMyBkb2VzKSBvciBIVFRQLzEuMSwgYW5kIGNv bmNsdWRlZCB0aGF0IGl0IHdvdWxkIGJlIHNhZCB0byBtYWtlIHNvbWVvbmUgZmFsbCBmcm9tIDMg LT4gMiAtPiAxLjEgd2hlbiBwcm9iYWJseSBjYW7igJl0IGFuc3dlciBvdmVyIGFueXRoaW5nIGhp Z2hlciB0aGFuIDEuMSBhbnl3YXkuDQoNCg0KPiAwKSBBcHBlbmRpeCBBLjQgY29udGFpbnMgYSBj b252ZW5pZW50IGNvbXBhcmlzb24gb2YgSFRUUC8yIGFuZCBIVFRQLzMgZXJyb3IgY29kZXMuIEhv d2V2ZXIsIGl0IHN0YXRlcyB0aGF0IEhUVFAvMidzIFBST1RPQ09MX0VSUk9SIGhhcyBubyBzaW5n bGUgZXF1aXZhbGVudCwgd2hpY2ggSSB0aGluayBpcyBpbmNvcnJlY3QgYmVjdWFzZSBIVFRQLzMg aGFzIEhUVFBfR0VORVJBTF9QUk9UT0NPTF9FUlJPUi4NCg0KDQoNCk1vc3RseSBiZWNhdXNlIHRo ZSB2YXJpb3VzIE1BTEZPUk1FRF9GUkFNRSBlcnJvcnMgd291bGQgYWxzbyBoYXZlIGJlZW4gUFJP VE9DT0xfRVJST1IgaW4gSFRUUC8yLiAgV2UgY291bGQgbWFrZSB0aGUgdGV4dCBwb2ludCB0byBH UEUsIHdoaWxlIG5vdGluZyB0aGF0IHNwZWNpZmljIGVycm9yIGNvZGVzIGhhdmUgYmVlbiBhZGRl ZCBmb3IgY2VydGFpbiBzaXR1YXRpb25zLg0KDQoNCg0KPiAxKSBIVFRQX1dST05HX1NUUkVBTSBh bmQgSFRUUF9VTkVYUEVDVEVEX0ZSQU1FIGFyZSB1c2VkIGEgbG90IGFuZCB2ZXJ5IHNpbWlsYXIu IFRoZSBmb3JtZXIgaXMgdXNlZCBieSBhIHBlZXIgdGhhdCByZWNlaXZlcyBhIHZhbGlkIGZyYW1l IG9uIGEgc3RyZWFtIHRoYXQgaXQgc2hvdWxkIG5ldmVyIGJlIHNlbnQgb24sIHRoZSBsYXR0ZXIg aXMgdXNlZCBieSBhIHBlZXIgdGhhdCByZWNlaXZlcyBhIHZhbGlkIGZyYW1lIG9uIGEgc3RyZWFt IHRoYXQgaXMgbm9ybWFsbHkgb2sgYnV0IGhhcyB0cmFuc2l0aW9uZWQgdG8gYW4gYXBwbGljYXRp b24tbGV2ZWwgc3RyZWFtIHN0YXRlIHdoaWNoIHByb2hpYml0cyBpdC4NCg0KPiBSYXRpb25hbGlz aW5nIHRoZXNlIHNlZW1zIGxpa2UgYSBsb2dpY2FsIG9wdGlvbi4NCg0KDQoNClNlZW1zIHJlYXNv bmFibGUuICBJIGJlbGlldmUgdGhlcmUgd2FzIHByZXZpb3VzIGRpc2N1c3Npb24gYWJvdXQgcG9z c2libHkgY29tYmluaW5nIHRoZW0sIGJ1dCBJIGNhbuKAmXQgZmluZCBpdCB3aXRoIGEgY3Vyc29y eSBzZWFyY2guDQoNCg0KDQo+IDIpIEhUVFBfV1JPTkdfU0VUVElOR19ESVJFQ1RJT04gcHJlc2Vu dGx5IGFwcGxpZXMgdG8gZXhhY3RseSBvbmUgY2FzZSwgYSBjbGllbnQgc2VuZCBOVU1fUExBQ0VI T0xERVIuIERlY2xhc3NpZnlpbmcgdGhpcyBhcyBhbiBlcnJvciBzZWVtcyBsaWtlIGEgc2Vuc2ls ZSBvcHRpb24uIFRoaXMgZnJlZXMgdXAgZXJyb3IgY29kZSAweDEsIHdoaWNoIHdlIGNhbiBtb3Zl IEhUVFBfR0VORVJBTF9QUk9UT0NPTF9FUlJPUiB0byAobWFraW5nIEhUVFAvMyBtb3JlIHNpbWls YXIgdG8gSFRUUC8yKS4NCg0KPiA3KSBUaGVyZSBhcmUgc2V2ZXJhbCBlcnJvciBjYXNlcyByZWxh dGVkIHRvIFNFVFRJTkdTOyBhIGZyYW1lIHRoYXQgY2FuIGJlIHNlbnQgbW9zdCBvbmNlIHBlciBj b25uZWN0aW9uLiBJIG1hZGUgYSBwcm9wb3NhbCB0byBhZGRyZXNzIHRoaXMgb24gaXNzdWUgIzI3 ODMgWzNdDQoNCg0KDQpJIG5lZWQgdG8gdGhpbmsgbW9yZSBhYm91dCB0aGUgcHJvcG9zYWwgaW4g IzI3ODMsIGJ1dCB0aGF04oCZcyBzZW1pLW9ydGhvZ29uYWwgdG8gdGhlIGVycm9yIGNvbnZlcnNh dGlvbi4gIEkgbGlrZSB0aGUgc3VnZ2VzdGlvbiBmcm9tIHRoZSBpbnRlcmltIHRvIGNvbnNvbGlk YXRlIHRoZXNlIHRvIGEgbW9yZSBnZW5lcmFsIElOVkFMSURfU0VUVElOR1MgZXJyb3IsIHRob3Vn aCBpZiB3ZSBnbyB0aGUgcm91dGUgb2YgIzI3ODMsIHRoYXQgbWlnaHQgYmVjb21lIGEgU1RSRUFN X0hFQURFUl9FUlJPUiDDoCBsYSAoOCkuDQoNCg0KDQo+IDMpIEhUVFBfUFVTSF9SRUZVU0VEIGFu ZCBIVFRQX1BVU0hfQUxSRUFEWV9JTl9DQUNIRSBhcmUgdmVyeSBzaW1pbGFyIGJ1dCBtYXkgYmUg dXNlZnVsIHRvIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCByZWFzb24gdGhhdCBjbGllbnRzIHJl amVjdCBzZXJ2ZXIgcHVzaC4gVGhpcyBpcyBleHRyYSBmaWRlbGl0eSBvbiB0b3Agb2YgSFRUUC8y Lg0KDQo+IDQpIFRoZXJlIGFyZSBzZXZlcmFsIGVycm9yIGNvZGVzIHJlbGF0ZWQgdG8gaGFuZGxp bmcgcmVxdWVzdHMgYW5kDQoNCnJlc3BvbnNlczogSFRUUF9SRVFVRVNUX0NBTkNFTExFRCwgSFRU UF9JTkNPTVBMRVRFX1JFUVVFU1QsIEhUVFBfRUFSTFlfUkVTUE9OU0UsIEhUVFBfUkVRVUVTVF9S RUpFQ1RFRCwgLiBUaGlzIGlzIGV4dHJhIGZpZGVsaXR5IHRoYW4gSFRUUC8yIHByb3ZpZGVkLiBU aGlzIG1heSBleHRyYSBpbmZvcm1hdGlvbiBtYXkgYWxsb3cgZW5kcG9pbnRzIHRvIG1ha2Ugc21h cnRlciBkZWNpc2lvbnMgYWJvdXQgcmV0cnlpbmcgcmVxdWVzdHMuIEhvd2V2ZXIsIGl0IG1heSBh bHNvIGJlIHBvc3NpYmxlIHRvIGluZmVyIHRoaW5ncyBmcm9tIGEgc3RyZWFtIGVycm9yIHRoYXQg Y29udGFpbnMgc2ltcGx5IEhUVFBfTk9fRVJST1IgKCBIVFRQX0VBUkxZX1JFU1BPTlNFIGNvdWxk IGJlbmVmaXQgZnJvbSB0aGlzKQ0KDQoNCg0KV2UgbmVlZCB0aGUgQ0FOQ0VMTEVEL1JFSkVDVEVE IHNwbGl0IHRvIHVuZGVyc3RhbmQgd2hlbiBhIHNlcnZlciBpcyBkZWNsYXJpbmcgdGhhdCBubyBw cm9jZXNzaW5nIG9jY3VycmVkIHZlcnN1cyByZWZsZWN0aW5nIGJhY2sgdGhlIGVycm9yIGNvZGUg ZnJvbSB0aGUgY2xpZW504oCZcyBTVE9QX1NFTkRJTkcgaW4gYSBSRVNFVF9TVFJFQU0uICAoVGhl IHJlc29sdXRpb24gdG8gdGhhdCBpcyB0aGF0IGNsaWVudHMgZG9u4oCZdCBzZW5kIFJFSkVDVEVE LCBhbmQgaXQgaGFzIHRoZSBhZGRpdGlvbmFsIHNlbWFudGljIHdoZW4gY29taW5nIGZyb20gYSBz ZXJ2ZXIuKSAgSWYgd2UgZGlkbuKAmXQgaGF2ZSBJTkNPTVBMRVRFX1JFUVVFU1QsIEnigJltIHVu c3VyZSB3aGF0IHdl4oCZZCBzZW5kIGluIHRoYXQgc2l0dWF0aW9uIGluc3RlYWQ7IGl04oCZcyBj ZXJ0YWlubHkgbm90IGEgTk9fRVJST1Igc2l0dWF0aW9uLg0KDQoNCg0KRm9sZGluZyBFQVJMWV9S RVNQT05TRSBpbnRvIE5PX0VSUk9SIHdvdWxkIGJlIHJlYXNvbmFibGUuDQoNCg0KDQo+IDUpIFRo ZSBlcnJvciBjb2RlIGd1aWRhbmNlIGlzIG9mdGVuIG5vdCBzeW1tZXRyaWMuIENsaWVudCBvciBz ZXJ2ZXJzIHVzZSBlcnJvciBjb2RlcyBkaWZmZXJlbnRseSBhbmQgbGl0dGxlIGd1aWRhbmNlIGlz IHByb3ZpZGVkIG9uIGhvdyB0byBwcm9jZXNzIGFuIGVycm9yIGNvZGUgdGhhdCBpbiB0aGVvcnkg c2hvdWxkIG5ldmVyIGJlIHNlbnQuDQoNCg0KDQpUaGUgb25seSBwb3NzaWJsZSByZXNwb25zZSBp cyBibG93aW5nIHVwIHRoZSBjb25uZWN0aW9uLCBpc27igJl0IGl0PyAgV2hpY2ggaXMgc3VwZXJm bHVvdXMgaWYgeW914oCZdmUgcmVjZWl2ZWQgYSBub25zZW5zaWNhbCBjb25uZWN0aW9uIGVycm9y LCBiZWNhdXNlIHRoZSBjb25uZWN0aW9uIGlzIGFscmVhZHkgYmVpbmcgYmxvd24gdXAgYnkgdGhl IHBlZXIuICBTbyB0aGUgbW9yZSBzY29wZWQgcXVlc3Rpb24gaXMsIGlmIGEgc3RyZWFtIHNlZXMg YSBSRVNFVC9TVE9QX1NFTkRJTkcgd2l0aCBhbiBlcnJvciBjb2RlIHRoYXQgYSkgc2hvdWxkIG9u bHkgaGF2ZSBvcmlnaW5hdGVkIGZyb20geW91ciBzaWRlLCBvciBiKSBjYW4gb25seSBiZSBhIGNv bm5lY3Rpb24gZXJyb3IsIHdoYXQgZG8geW91IGRvPw0KDQoNCg0KPiA2KSBUaGVyZSBpcyBsaXR0 bGUgZ3VpZGFuY2Ugb24gaG93IGFuIGludGVybWVkaWFyeSB0aGF0IHRyYW5zbGF0ZXMgYmV0d2Vl biBIVFRQLzIgYW5kIEhUVFAvMyBzaG91bGQgbWFwIHRoZXNlIGRpdmVyZ2VudCBlcnJvciBjb2Rl IHNwYWNlcy4gSXQgd291bGQgcGF5IHRvIGFsaWduIHRoZW0gYXMgY2xvc2UgYXMgcG9zc2libGUg YW5kIHByb3ZpZGUgc29tZSBndWlkYW5jZSBvbiBob3cgdG8gbWFwIGhpZ2hlciBmaWRlbGl0eSBj b2RlcyB0byBsb3dlciBmaWRlbGl0eSBjb2Rlcy4NCg0KDQoNClRoYXTigJlzIGEgZ29vZCBwb2lu dC4gIEhvd2V2ZXIsIGVycm9yIGNvZGVzIGFyZSBob3AtdG8taG9wIOKAkyBJIHN1c3BlY3QgdGhh dCBhbnkgZXJyb3IgY29kZSBnZXRzIHR1cm5lZCBpbnRvIGEgc3RhdHVzIGNvZGUgNTAyLCB3aXRo IHRoZSBwb3NzaWJsZSBleGNlcHRpb24gb2YgUkVKRUNURUQuICBEbyBleHBlY3QgYW55b25lIHRv IGJ1aWxkIGEgMi8zIGludGVybWVkaWFyeSB3aG8gaXNu4oCZdCBhbHNvIHRlcm1pbmF0aW5nIHRo ZSBIVFRQIHNlbWFudGljIGxheWVyPw0KDQoNCg0KPiA4KSBIVFRQX1VOS05PV05fU1RSRUFNX1RZ UEUgYW5kIERVUExJQ0FURV9QVVNIIGJvdGggcmVsYXRlIHRvIHBhcnNpbmcgdGhlIHVuaWRpcmVj dGlvbmFsIHN0cmVhbSB0eXBlIGhlYWRlci4gV2UgbWlnaHQgYmUgYWJsZSB0byBtZXJnZSB0aGVz ZSBpbnRvIGEgZXJyb3Igc3VjaCBhcyBIVFRQX1NUUkVBTV9IRUFERVJfRVJST1IgYW5kIHN0YXRl IHRoZSBjb2RlIGhhcyBkaWZmZXJlbnQgYXBwbGljYWJpbGl0eSBiZXR3ZWVuIFNUT1BfU0VORElO RyBhbmQgQ09OTkVDVElPTl9DTE9TRSBmcmFtZXMuDQoNCj4gOSkgQ3JpdGljYWwgc3RyZWFtcyBz dWNoIGFzIGNvbnRyb2wgc3RyZWFtIGFuZCBRUEFDSyBzdHJlYW1zIGNhbiBiZSBjcmVhdGVkIG9u bHkgb25jZTsgSFRUUF9XUk9OR19TVFJFQU1fQ09VTlQgY2FwdHVyZXMgdGhpcy4gUHVzaCBzdHJl YW1zIGNhbiBvbmx5IGJlIGNyZWF0ZWQgYnkgYSBzZXJ2ZXIgYW5kIEhUVFBfV1JPTkdfU1RSRUFN X0RJUkVDVElPTiBjYXB0dXJlcyB0aGlzLiBXZSBjb3VsZCByYXRpb25hbGlzZSB0aGVzZSBpbnRv IEhUVFBfU1RSRUFNX0NSRUFUSU9OX0VSUk9SLCB0aGF0IGNvdWxkIGV2ZW4gaW5jb3Jwb3JhdGUg c3VnZ2VzdGlvbiA4Lg0KDQoNCg0KRFVQTElDQVRFX1BVU0ggY2FuIGFsc28gcmVmZXIgdG8gYSBz ZWNvbmQgUFVTSF9QUk9NSVNFIHdpdGggdGhlIHNhbWUgUHVzaCBJRC4gIE90aGVyd2lzZSwgYSBT VFJFQU1fSEVBREVSX0VSUk9SIG9yIFNUUkVBTV9DUkVBVElPTl9FUlJPUiBzZWVtcyBsaWtlIGEg cmVhc29uYWJsZSBjb2xsYXRpb247IEkgYWdyZWUgdGhhdCB0aG9zZSBhcmUgdWx0aW1hdGVseSB0 aGUgc2FtZSBwcm9wb3NhbC4NCg0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBNYXJ0aW4gRHVrZQ0KU2VudDogVHVlc2RheSwgSnVuZSAxMSwgMjAxOSAx MjozNyBQTQ0KVG86IEx1Y2FzIFBhcmR1ZSA8bHVjYXNwYXJkdWUuMjQuN0BnbWFpbC5jb20+DQpD YzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBBbmFseXNpbmcgdGhlIEhUVFAvMyBlcnJvciBjb2RlIHNwYWNlDQoN Ckkgd291bGQgaW5zaXN0IG9uIElOVEVSTkFMX0VSUk9SLiBJdCBpcyBncmVhdCBmb3IgdmFyaW91 cyBtYWxsb2MgcHJvYmxlbXMsIGFzIHdlbGwgYXMgZm9yIHNpZ25hbGxpbmcgdGhhdCBzb21ldGhp bmcgd2VudCB3cm9uZyBvbiB0aGUgYmFjayBlbmQgaW4gcHJveHkgc2NlbmFyaW9zLiBJdCBpcyBh IGNhdGNoLWFsbCBmb3IgIkkgc2NyZXdlZCB1cCBhbmQgY2FuJ3QgY29udGludWUiLg0KDQpPbiBU dWUsIEp1biAxMSwgMjAxOSBhdCAxMTo1MyBBTSBMdWNhcyBQYXJkdWUgPGx1Y2FzcGFyZHVlLjI0 LjdAZ21haWwuY29tPG1haWx0bzpsdWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbT4+IHdyb3RlOg0K IEhleSBJYW4sDQoNCk9uIFR1ZSwgSnVuIDExLCAyMDE5IGF0IDc6MTQgUE0gSWFuIFN3ZXR0IDxp YW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj4gd3JvdGU6DQo+ DQo+Pg0KPj4gT25lIG5vdGFibGUgZGlmZmVyZW5jZSBpcyB0aGF0IEhUVFAvMnMgRlJBTUVfU0la RV9FUlJPUiBjb2RlIGhhcyBiZWVuDQo+PiByZXBsYWNlZCBieSBIVFRQX01BTEZPUk1FRF9GUkFN RSwgd2hpY2ggYWN0dWFsbHkgY292ZXJzIGEgcmFuZ2Ugb2YNCj4+IHZhbHVlcyAtIGl0IGRlZGlj YXRlcyBhIGJ5dGUgdG8gZW5jb2RlIHRoZSBmcmFtZSB0eXBlLiBUaGlzIGlzDQo+PiBwcm9ibGVt YXRpYyBzaW5jZSB0aGUgZnJhbWUgdHlwZSBjaGFuZ2VkIHRvIGJlIGEgNjItYml0IGludGVnZXIN Cj4+IGl0c2VsZi4gIEluIG15IHBlcnNvbmFsIG9waW5pb24sIHRoaXMgZXJyb3IgY29kZSBpcyBt b3JlIGNvbXBsaWNhdGVkDQo+PiB0aGFuIG5lZWRzIGJlIGFuZCB3YXMgaW5jb3JyZWN0bHkgYXBw bGllZC4gSXNzdWUgIzI1NTEgWzFdIGNhcHR1cmVzDQo+PiB0aGlzLCBhbmQgUFIgIzI2NjIgWzJd IGNvbnRhaW5zIGEgcHJvcG9zZWQgc2V0IG9mIHJlcGxhY2VtZW50IGNvZGVzLg0KPj4gVGhhdCBQ UiBhZGRzIDQgZXJyb3IgY29kZXMgdG8gYnJpbmcgdGhlIHRvdGFsIHVwIHRvIDI4Lg0KPg0KPg0K PiBJIGxpa2UgeW91ciBwcm9wb3NlZCBQUi4NCg0KVGhhbmtzLiBUaGUgVEw7RFIgb2YgdGhlIFBS IGlzIHRoYXQgaXQgYWRkIGJhY2sgRlJBTUVfU0laRV9FUlJPUiAoZm9yDQp0aGluZ3MgdGhhdCBh cmUgZnJhbWUgc2l6ZSBlcnJvcnMpIGFuZCBhZGRzIHNvbWUgbmV3IGVycm9yIGNvZGVzIGluDQph Z3JlZW1lbnQgd2l0aCBvdXIgY3VycmVudCBwaGlsb3NvcGh5LiBJIHdvdWxkIHJlZmluZSB0aGUg UFIgdG8gYWdyZWUNCndpdGggdGhlIG91dGNvbWUgb2YgdGhpcyB0aHJlYWQuDQoNCj4NCj4gQW55 IHRob3VnaHRzIG9uIEhUVFBfVkVSU0lPTl9GQUxMQkFDSyBhbmQgSFRUUF9JTlRFUk5BTF9FUlJP Uiwgd2hpY2ggYXJlIG5ldmVyIHVzZWQ/ICBJJ20gdW5jbGVhciBvbiB3aGF0IHRoZSBpbnRlbmRl ZCB1c2FnZSBpcz8NCg0KSSByZWFsaXNlZCBJIGRpZG4ndCBxdWFsaWZ5IG9uZSBhc3BlY3Qgb2Yg bXkgYW5hbHlzaXMgLSB0aGUgZ3VpZGFuY2UNCmNvdW50IG1ldHJpYyBpcyBvbmx5IG9uZSBzaWdu YWwuIEhUVFBfSU5URVJOQUxfRVJST1IgaXMgZGVzY3JpYmVkIGFzDQoiQW4gaW50ZXJuYWwgZXJy b3IgaGFzIG9jY3VycmVkIGluIHRoZSBIVFRQIHN0YWNrLiIsIHdoaWNoIGZlZWxzIGxpa2UNCmFu IGltcGxlbWVudGF0aW9uLW9yaWVudGVkIGVycm9yIGNvZGUuIEkgdGhpbmsgaXQgaXMgdmFsaWQg aW4gc3RheWluZw0KaW4gSFRUUC8zLCBlc3BlY2lhbGx5IGlmIGl0IGlzIHVzZWQgaW4gSFRUUC8y IChJIGRvbid0IGhhdmUgZGF0YSB0bw0KaGFuZCBvbiB0aGF0IHRob3VnaCkuIEhvd2V2ZXIsIEhU VFBfVkVSU0lPTl9GQUxMQkFDSyBpcyBhIGJpdCB3ZWlyZDsNCml0IHN0ZW1zIGZyb20gSFRUUC8y J3MgSFRUUF8xXzFfUkVRVUlSRUQgY29kZSwgd2hpY2ggaW4gUkZDIDc1NDAgaXMNCm9ubHkgcmVj b21tZW5kZWQgd2hlbiB0aGUgc2VydmVyIHdhbnRzIHRvIHVzZSBUTFMgcmVuZWdvdGlhdGlvbi4g SU1PDQppdCBpcyBvZiBsaW1pdGVkIHZhbHVlIHVubGVzcyB3ZSBpbXBvcnQgdGhlIHNhbWUgYmVo YXZpb3VyIGludG8NCkhUVFAvMy4NCg== --_000_CY4PR22MB09836F1DC79AE7B1BC49A494DAED0CY4PR22MB0983namp_ 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 bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHdhcyBwcmV2aW91c2x5IGFmZmlsaWF0ZWQgd2l0aCBhbiBIVFRQIHN0YWNrIHRo YXQgSSBhc3N1bWUgc3RpbGwgbmVlZHMgSFRUUF9WRVJTSU9OX0ZBTExCQUNLIGZvciBzb21lIGNv cm5lciBjYXNlcyBpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgcmVuZWdvdGlhdGlvbi4m bmJzcDsgVGhpcyBXRyBwcmV2aW91c2x5IGhhZCBhIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciBp dCBzaG91bGQgZmFsbCBiYWNrIHRvDQogSFRUUC8yIChsb2dpY2FsLCBidXQgbGlrZWx5IGhhcyBh bGwgdGhlIHNhbWUgaW5jb21wYXRpYmxlIHNjZW5hcmlvcyB0aGF0IEhUVFAvMyBkb2VzKSBvciBI VFRQLzEuMSwgYW5kIGNvbmNsdWRlZCB0aGF0IGl0IHdvdWxkIGJlIHNhZCB0byBtYWtlIHNvbWVv bmUgZmFsbCBmcm9tIDMgLSZndDsgMiAtJmd0OyAxLjEgd2hlbiBwcm9iYWJseSBjYW7igJl0IGFu c3dlciBvdmVyIGFueXRoaW5nIGhpZ2hlciB0aGFuIDEuMSBhbnl3YXkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgMCkgQXBwZW5kaXggQS40IGNvbnRhaW5zIGEgY29udmVuaWVudCBj b21wYXJpc29uIG9mIEhUVFAvMiBhbmQgSFRUUC8zIGVycm9yIGNvZGVzLiBIb3dldmVyLCBpdCBz dGF0ZXMgdGhhdCBIVFRQLzIncyBQUk9UT0NPTF9FUlJPUiBoYXMgbm8gc2luZ2xlIGVxdWl2YWxl bnQsIHdoaWNoIEkgdGhpbmsgaXMgaW5jb3JyZWN0IGJlY3Vhc2UgSFRUUC8zIGhhcyBIVFRQX0dF TkVSQUxfUFJPVE9DT0xfRVJST1IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1vc3Rs eSBiZWNhdXNlIHRoZSB2YXJpb3VzIE1BTEZPUk1FRF9GUkFNRSBlcnJvcnMgd291bGQgYWxzbyBo YXZlIGJlZW4gUFJPVE9DT0xfRVJST1IgaW4gSFRUUC8yLiZuYnNwOyBXZSBjb3VsZCBtYWtlIHRo ZSB0ZXh0IHBvaW50IHRvIEdQRSwgd2hpbGUgbm90aW5nIHRoYXQgc3BlY2lmaWMgZXJyb3IgY29k ZXMgaGF2ZSBiZWVuIGFkZGVkIGZvciBjZXJ0YWluIHNpdHVhdGlvbnMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgMSkgSFRUUF9XUk9OR19TVFJFQU0gYW5kIEhUVFBfVU5FWFBF Q1RFRF9GUkFNRSBhcmUgdXNlZCBhIGxvdCBhbmQgdmVyeSBzaW1pbGFyLiBUaGUgZm9ybWVyIGlz IHVzZWQgYnkgYSBwZWVyIHRoYXQgcmVjZWl2ZXMgYSB2YWxpZCBmcmFtZSBvbiBhIHN0cmVhbSB0 aGF0IGl0IHNob3VsZCBuZXZlciBiZSBzZW50IG9uLCB0aGUgbGF0dGVyIGlzIHVzZWQgYnkgYSBw ZWVyIHRoYXQgcmVjZWl2ZXMgYSB2YWxpZA0KIGZyYW1lIG9uIGEgc3RyZWFtIHRoYXQgaXMgbm9y bWFsbHkgb2sgYnV0IGhhcyB0cmFuc2l0aW9uZWQgdG8gYW4gYXBwbGljYXRpb24tbGV2ZWwgc3Ry ZWFtIHN0YXRlIHdoaWNoIHByb2hpYml0cyBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgUmF0aW9uYWxpc2luZyB0aGVzZSBzZWVtcyBsaWtlIGEgbG9naWNh bCBvcHRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNlZW1zIHJlYXNvbmFibGUu Jm5ic3A7IEkgYmVsaWV2ZSB0aGVyZSB3YXMgcHJldmlvdXMgZGlzY3Vzc2lvbiBhYm91dCBwb3Nz aWJseSBjb21iaW5pbmcgdGhlbSwgYnV0IEkgY2Fu4oCZdCBmaW5kIGl0IHdpdGggYSBjdXJzb3J5 IHNlYXJjaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAyKSBIVFRQX1dST05H X1NFVFRJTkdfRElSRUNUSU9OIHByZXNlbnRseSBhcHBsaWVzIHRvIGV4YWN0bHkgb25lIGNhc2Us IGEgY2xpZW50IHNlbmQgTlVNX1BMQUNFSE9MREVSLiBEZWNsYXNzaWZ5aW5nIHRoaXMgYXMgYW4g ZXJyb3Igc2VlbXMgbGlrZSBhIHNlbnNpbGUgb3B0aW9uLiBUaGlzIGZyZWVzIHVwIGVycm9yIGNv ZGUgMHgxLCB3aGljaCB3ZSBjYW4gbW92ZSBIVFRQX0dFTkVSQUxfUFJPVE9DT0xfRVJST1INCiB0 byAobWFraW5nIEhUVFAvMyBtb3JlIHNpbWlsYXIgdG8gSFRUUC8yKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgNykgVGhlcmUgYXJlIHNldmVyYWwgZXJyb3Ig Y2FzZXMgcmVsYXRlZCB0byBTRVRUSU5HUzsgYSBmcmFtZSB0aGF0IGNhbiBiZSBzZW50IG1vc3Qg b25jZSBwZXIgY29ubmVjdGlvbi4gSSBtYWRlIGEgcHJvcG9zYWwgdG8gYWRkcmVzcyB0aGlzIG9u IGlzc3VlICMyNzgzIFszXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIG5lZWQgdG8g dGhpbmsgbW9yZSBhYm91dCB0aGUgcHJvcG9zYWwgaW4gIzI3ODMsIGJ1dCB0aGF04oCZcyBzZW1p LW9ydGhvZ29uYWwgdG8gdGhlIGVycm9yIGNvbnZlcnNhdGlvbi4mbmJzcDsgSSBsaWtlIHRoZSBz dWdnZXN0aW9uIGZyb20gdGhlIGludGVyaW0gdG8gY29uc29saWRhdGUgdGhlc2UgdG8gYSBtb3Jl IGdlbmVyYWwgSU5WQUxJRF9TRVRUSU5HUyBlcnJvciwgdGhvdWdoIGlmIHdlIGdvIHRoZSByb3V0 ZQ0KIG9mICMyNzgzLCB0aGF0IG1pZ2h0IGJlY29tZSBhIFNUUkVBTV9IRUFERVJfRVJST1Igw6Ag bGEgKDgpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDMpIEhUVFBfUFVTSF9S RUZVU0VEIGFuZCBIVFRQX1BVU0hfQUxSRUFEWV9JTl9DQUNIRSBhcmUgdmVyeSBzaW1pbGFyIGJ1 dCBtYXkgYmUgdXNlZnVsIHRvIHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCByZWFzb24gdGhhdCBj bGllbnRzIHJlamVjdCBzZXJ2ZXIgcHVzaC4gVGhpcyBpcyBleHRyYSBmaWRlbGl0eSBvbiB0b3Ag b2YgSFRUUC8yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA0 KSBUaGVyZSBhcmUgc2V2ZXJhbCBlcnJvciBjb2RlcyByZWxhdGVkIHRvIGhhbmRsaW5nIHJlcXVl c3RzIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+cmVzcG9uc2Vz OiBIVFRQX1JFUVVFU1RfQ0FOQ0VMTEVELCBIVFRQX0lOQ09NUExFVEVfUkVRVUVTVCwgSFRUUF9F QVJMWV9SRVNQT05TRSwgSFRUUF9SRVFVRVNUX1JFSkVDVEVELCAuIFRoaXMgaXMgZXh0cmEgZmlk ZWxpdHkgdGhhbiBIVFRQLzIgcHJvdmlkZWQuIFRoaXMgbWF5IGV4dHJhIGluZm9ybWF0aW9uIG1h eSBhbGxvdyBlbmRwb2ludHMgdG8gbWFrZSBzbWFydGVyIGRlY2lzaW9ucyBhYm91dCByZXRyeWlu Zw0KIHJlcXVlc3RzLiBIb3dldmVyLCBpdCBtYXkgYWxzbyBiZSBwb3NzaWJsZSB0byBpbmZlciB0 aGluZ3MgZnJvbSBhIHN0cmVhbSBlcnJvciB0aGF0IGNvbnRhaW5zIHNpbXBseSBIVFRQX05PX0VS Uk9SICggSFRUUF9FQVJMWV9SRVNQT05TRSBjb3VsZCBiZW5lZml0IGZyb20gdGhpcyk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2UgbmVlZCB0aGUgQ0FOQ0VMTEVEL1JFSkVDVEVEIHNw bGl0IHRvIHVuZGVyc3RhbmQgd2hlbiBhIHNlcnZlciBpcyBkZWNsYXJpbmcgdGhhdCBubyBwcm9j ZXNzaW5nIG9jY3VycmVkIHZlcnN1cyByZWZsZWN0aW5nIGJhY2sgdGhlIGVycm9yIGNvZGUgZnJv bSB0aGUgY2xpZW504oCZcyBTVE9QX1NFTkRJTkcgaW4gYSBSRVNFVF9TVFJFQU0uJm5ic3A7IChU aGUgcmVzb2x1dGlvbiB0byB0aGF0IGlzIHRoYXQgY2xpZW50cw0KIGRvbuKAmXQgc2VuZCBSRUpF Q1RFRCwgYW5kIGl0IGhhcyB0aGUgYWRkaXRpb25hbCBzZW1hbnRpYyB3aGVuIGNvbWluZyBmcm9t IGEgc2VydmVyLikmbmJzcDsgSWYgd2UgZGlkbuKAmXQgaGF2ZSBJTkNPTVBMRVRFX1JFUVVFU1Qs IEnigJltIHVuc3VyZSB3aGF0IHdl4oCZZCBzZW5kIGluIHRoYXQgc2l0dWF0aW9uIGluc3RlYWQ7 IGl04oCZcyBjZXJ0YWlubHkgbm90IGEgTk9fRVJST1Igc2l0dWF0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5Gb2xkaW5nIEVBUkxZX1JFU1BPTlNFIGludG8gTk9fRVJST1Igd291 bGQgYmUgcmVhc29uYWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA1KSBU aGUgZXJyb3IgY29kZSBndWlkYW5jZSBpcyBvZnRlbiBub3Qgc3ltbWV0cmljLiBDbGllbnQgb3Ig c2VydmVycyB1c2UgZXJyb3IgY29kZXMgZGlmZmVyZW50bHkgYW5kIGxpdHRsZSBndWlkYW5jZSBp cyBwcm92aWRlZCBvbiBob3cgdG8gcHJvY2VzcyBhbiBlcnJvciBjb2RlIHRoYXQgaW4gdGhlb3J5 IHNob3VsZCBuZXZlciBiZSBzZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUg b25seSBwb3NzaWJsZSByZXNwb25zZSBpcyBibG93aW5nIHVwIHRoZSBjb25uZWN0aW9uLCBpc27i gJl0IGl0PyZuYnNwOyBXaGljaCBpcyBzdXBlcmZsdW91cyBpZiB5b3XigJl2ZSByZWNlaXZlZCBh IG5vbnNlbnNpY2FsIGNvbm5lY3Rpb24gZXJyb3IsIGJlY2F1c2UgdGhlIGNvbm5lY3Rpb24gaXMg YWxyZWFkeSBiZWluZyBibG93biB1cCBieSB0aGUgcGVlci4mbmJzcDsgU28gdGhlIG1vcmUgc2Nv cGVkIHF1ZXN0aW9uIGlzLA0KIGlmIGEgc3RyZWFtIHNlZXMgYSBSRVNFVC9TVE9QX1NFTkRJTkcg d2l0aCBhbiBlcnJvciBjb2RlIHRoYXQgYSkgc2hvdWxkIG9ubHkgaGF2ZSBvcmlnaW5hdGVkIGZy b20geW91ciBzaWRlLCBvciBiKSBjYW4gb25seSBiZSBhIGNvbm5lY3Rpb24gZXJyb3IsIHdoYXQg ZG8geW91IGRvPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDYpIFRoZXJlIGlz IGxpdHRsZSBndWlkYW5jZSBvbiBob3cgYW4gaW50ZXJtZWRpYXJ5IHRoYXQgdHJhbnNsYXRlcyBi ZXR3ZWVuIEhUVFAvMiBhbmQgSFRUUC8zIHNob3VsZCBtYXAgdGhlc2UgZGl2ZXJnZW50IGVycm9y IGNvZGUgc3BhY2VzLiBJdCB3b3VsZCBwYXkgdG8gYWxpZ24gdGhlbSBhcyBjbG9zZSBhcyBwb3Nz aWJsZSBhbmQgcHJvdmlkZSBzb21lIGd1aWRhbmNlIG9uIGhvdyB0byBtYXAgaGlnaGVyDQogZmlk ZWxpdHkgY29kZXMgdG8gbG93ZXIgZmlkZWxpdHkgY29kZXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlRoYXTigJlzIGEgZ29vZCBwb2ludC4mbmJzcDsgSG93ZXZlciwgZXJyb3IgY29k ZXMgYXJlIGhvcC10by1ob3Ag4oCTIEkgc3VzcGVjdCB0aGF0IGFueSBlcnJvciBjb2RlIGdldHMg dHVybmVkIGludG8gYSBzdGF0dXMgY29kZSA1MDIsIHdpdGggdGhlIHBvc3NpYmxlIGV4Y2VwdGlv biBvZiBSRUpFQ1RFRC4mbmJzcDsgRG8gZXhwZWN0IGFueW9uZSB0byBidWlsZCBhIDIvMyBpbnRl cm1lZGlhcnkgd2hvIGlzbuKAmXQgYWxzbyB0ZXJtaW5hdGluZw0KIHRoZSBIVFRQIHNlbWFudGlj IGxheWVyPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDgpIEhUVFBfVU5LTk9X Tl9TVFJFQU1fVFlQRSBhbmQgRFVQTElDQVRFX1BVU0ggYm90aCByZWxhdGUgdG8gcGFyc2luZyB0 aGUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtIHR5cGUgaGVhZGVyLiBXZSBtaWdodCBiZSBhYmxlIHRv IG1lcmdlIHRoZXNlIGludG8gYSBlcnJvciBzdWNoIGFzIEhUVFBfU1RSRUFNX0hFQURFUl9FUlJP UiBhbmQgc3RhdGUgdGhlIGNvZGUgaGFzIGRpZmZlcmVudCBhcHBsaWNhYmlsaXR5DQogYmV0d2Vl biBTVE9QX1NFTkRJTkcgYW5kIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWVzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA5KSBDcml0aWNhbCBzdHJlYW1zIHN1Y2gg YXMgY29udHJvbCBzdHJlYW0gYW5kIFFQQUNLIHN0cmVhbXMgY2FuIGJlIGNyZWF0ZWQgb25seSBv bmNlOyBIVFRQX1dST05HX1NUUkVBTV9DT1VOVCBjYXB0dXJlcyB0aGlzLiBQdXNoIHN0cmVhbXMg Y2FuIG9ubHkgYmUgY3JlYXRlZCBieSBhIHNlcnZlciBhbmQgSFRUUF9XUk9OR19TVFJFQU1fRElS RUNUSU9OIGNhcHR1cmVzIHRoaXMuIFdlIGNvdWxkIHJhdGlvbmFsaXNlDQogdGhlc2UgaW50byBI VFRQX1NUUkVBTV9DUkVBVElPTl9FUlJPUiwgdGhhdCBjb3VsZCBldmVuIGluY29ycG9yYXRlIHN1 Z2dlc3Rpb24gOC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RFVQTElDQVRFX1BVU0gg Y2FuIGFsc28gcmVmZXIgdG8gYSBzZWNvbmQgUFVTSF9QUk9NSVNFIHdpdGggdGhlIHNhbWUgUHVz aCBJRC4mbmJzcDsgT3RoZXJ3aXNlLCBhIFNUUkVBTV9IRUFERVJfRVJST1Igb3IgU1RSRUFNX0NS RUFUSU9OX0VSUk9SIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIGNvbGxhdGlvbjsgSSBhZ3JlZSB0 aGF0IHRob3NlIGFyZSB1bHRpbWF0ZWx5IHRoZSBzYW1lIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBRVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFs ZiBPZiA8L2I+DQpNYXJ0aW4gRHVrZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEx LCAyMDE5IDEyOjM3IFBNPGJyPg0KPGI+VG86PC9iPiBMdWNhcyBQYXJkdWUgJmx0O2x1Y2FzcGFy ZHVlLjI0LjdAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5z d2V0dEBnb29nbGUuY29tJmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IEFuYWx5c2luZyB0aGUgSFRUUC8zIGVycm9yIGNvZGUgc3BhY2U8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgaW5zaXN0IG9uIElOVEVSTkFM X0VSUk9SLiBJdCBpcyBncmVhdCBmb3IgdmFyaW91cyBtYWxsb2MgcHJvYmxlbXMsIGFzIHdlbGwg YXMgZm9yIHNpZ25hbGxpbmcgdGhhdCBzb21ldGhpbmcgd2VudCB3cm9uZyBvbiB0aGUgYmFjayBl bmQgaW4gcHJveHkgc2NlbmFyaW9zLiBJdCBpcyBhIGNhdGNoLWFsbCBmb3IgJnF1b3Q7SSBzY3Jl d2VkIHVwIGFuZCBjYW4ndCBjb250aW51ZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVuIDExLCAyMDE5IGF0IDExOjUzIEFNIEx1 Y2FzIFBhcmR1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y2FzcGFyZHVlLjI0LjdAZ21haWwuY29t Ij5sdWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij4mbmJzcDtIZXkgSWFuLDxicj4NCjxicj4NCk9uIFR1ZSwgSnVuIDEx LCAyMDE5IGF0IDc6MTQgUE0gSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbmUgbm90YWJsZSBk aWZmZXJlbmNlIGlzIHRoYXQgSFRUUC8ycyBGUkFNRV9TSVpFX0VSUk9SIGNvZGUgaGFzIGJlZW48 YnI+DQomZ3Q7Jmd0OyByZXBsYWNlZCBieSBIVFRQX01BTEZPUk1FRF9GUkFNRSwgd2hpY2ggYWN0 dWFsbHkgY292ZXJzIGEgcmFuZ2Ugb2Y8YnI+DQomZ3Q7Jmd0OyB2YWx1ZXMgLSBpdCBkZWRpY2F0 ZXMgYSBieXRlIHRvIGVuY29kZSB0aGUgZnJhbWUgdHlwZS4gVGhpcyBpczxicj4NCiZndDsmZ3Q7 IHByb2JsZW1hdGljIHNpbmNlIHRoZSBmcmFtZSB0eXBlIGNoYW5nZWQgdG8gYmUgYSA2Mi1iaXQg aW50ZWdlcjxicj4NCiZndDsmZ3Q7IGl0c2VsZi4mbmJzcDsgSW4gbXkgcGVyc29uYWwgb3Bpbmlv biwgdGhpcyBlcnJvciBjb2RlIGlzIG1vcmUgY29tcGxpY2F0ZWQ8YnI+DQomZ3Q7Jmd0OyB0aGFu IG5lZWRzIGJlIGFuZCB3YXMgaW5jb3JyZWN0bHkgYXBwbGllZC4gSXNzdWUgIzI1NTEgWzFdIGNh cHR1cmVzPGJyPg0KJmd0OyZndDsgdGhpcywgYW5kIFBSICMyNjYyIFsyXSBjb250YWlucyBhIHBy b3Bvc2VkIHNldCBvZiByZXBsYWNlbWVudCBjb2Rlcy48YnI+DQomZ3Q7Jmd0OyBUaGF0IFBSIGFk ZHMgNCBlcnJvciBjb2RlcyB0byBicmluZyB0aGUgdG90YWwgdXAgdG8gMjguPGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IEkgbGlrZSB5b3VyIHByb3Bvc2VkIFBSLjxicj4NCjxicj4NClRo YW5rcy4gVGhlIFRMO0RSIG9mIHRoZSBQUiBpcyB0aGF0IGl0IGFkZCBiYWNrIEZSQU1FX1NJWkVf RVJST1IgKGZvcjxicj4NCnRoaW5ncyB0aGF0IGFyZSBmcmFtZSBzaXplIGVycm9ycykgYW5kIGFk ZHMgc29tZSBuZXcgZXJyb3IgY29kZXMgaW48YnI+DQphZ3JlZW1lbnQgd2l0aCBvdXIgY3VycmVu dCBwaGlsb3NvcGh5LiBJIHdvdWxkIHJlZmluZSB0aGUgUFIgdG8gYWdyZWU8YnI+DQp3aXRoIHRo ZSBvdXRjb21lIG9mIHRoaXMgdGhyZWFkLjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IEFueSB0 aG91Z2h0cyBvbiBIVFRQX1ZFUlNJT05fRkFMTEJBQ0sgYW5kIEhUVFBfSU5URVJOQUxfRVJST1Is IHdoaWNoIGFyZSBuZXZlciB1c2VkPyZuYnNwOyBJJ20gdW5jbGVhciBvbiB3aGF0IHRoZSBpbnRl bmRlZCB1c2FnZSBpcz88YnI+DQo8YnI+DQpJIHJlYWxpc2VkIEkgZGlkbid0IHF1YWxpZnkgb25l IGFzcGVjdCBvZiBteSBhbmFseXNpcyAtIHRoZSBndWlkYW5jZTxicj4NCmNvdW50IG1ldHJpYyBp cyBvbmx5IG9uZSBzaWduYWwuIEhUVFBfSU5URVJOQUxfRVJST1IgaXMgZGVzY3JpYmVkIGFzPGJy Pg0KJnF1b3Q7QW4gaW50ZXJuYWwgZXJyb3IgaGFzIG9jY3VycmVkIGluIHRoZSBIVFRQIHN0YWNr LiZxdW90Oywgd2hpY2ggZmVlbHMgbGlrZTxicj4NCmFuIGltcGxlbWVudGF0aW9uLW9yaWVudGVk IGVycm9yIGNvZGUuIEkgdGhpbmsgaXQgaXMgdmFsaWQgaW4gc3RheWluZzxicj4NCmluIEhUVFAv MywgZXNwZWNpYWxseSBpZiBpdCBpcyB1c2VkIGluIEhUVFAvMiAoSSBkb24ndCBoYXZlIGRhdGEg dG88YnI+DQpoYW5kIG9uIHRoYXQgdGhvdWdoKS4gSG93ZXZlciwgSFRUUF9WRVJTSU9OX0ZBTExC QUNLIGlzIGEgYml0IHdlaXJkOzxicj4NCml0IHN0ZW1zIGZyb20gSFRUUC8yJ3MgSFRUUF8xXzFf UkVRVUlSRUQgY29kZSwgd2hpY2ggaW4gUkZDIDc1NDAgaXM8YnI+DQpvbmx5IHJlY29tbWVuZGVk IHdoZW4gdGhlIHNlcnZlciB3YW50cyB0byB1c2UgVExTIHJlbmVnb3RpYXRpb24uIElNTzxicj4N Cml0IGlzIG9mIGxpbWl0ZWQgdmFsdWUgdW5sZXNzIHdlIGltcG9ydCB0aGUgc2FtZSBiZWhhdmlv dXIgaW50bzxicj4NCkhUVFAvMy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR22MB09836F1DC79AE7B1BC49A494DAED0CY4PR22MB0983namp_-- From nobody Tue Jun 11 19:43:57 2019 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 F29AA1200F5 for ; Tue, 11 Jun 2019 19:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 AFuyxM-AqXGk for ; Tue, 11 Jun 2019 19:43:48 -0700 (PDT) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 B4E141200B7 for ; Tue, 11 Jun 2019 19:43:47 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id p24so10821759lfo.6 for ; Tue, 11 Jun 2019 19:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B4dSlzwI3OeBBK28tq+Jb45tnswC3xaWQ5ShfM0m/G8=; b=i4XTEZwEbQsPsdCVCd4kvLIA0USGFQZ0sBwYLZ+G5hMIwJjLcAPEtB1o/NpEAQgmzy TCaAikzfOV0uEEjuegbD8WO4EHQAbaMr+XPIz3LOryDen8jS99zlq6CrHxUoWnhSNs89 9sd5WeLrrWZDlxLrFxuqtbOrLW7HjidwNcY0eWtsjoQT0U3OGZ0K8QhvYHsj5FP4z6pE 0c7X/FOfZSzRSmOnttvOpw+Lz5Fupk/vyvRRPEB4grzddqKJQtTYJd5EZGKlPk20ORhe rL7YJxeANF0GTDUKP8kR4CLB03TZYwwPoBLijFXD7gdOfBtBic5SeXovj3FQuIGzabb0 JYog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B4dSlzwI3OeBBK28tq+Jb45tnswC3xaWQ5ShfM0m/G8=; b=tDJAipNylOXPpA+mfm8UQu9kPSfkNY5ZMb5/CT+SFo5ugsZ3earV3ksL0TIhMiF6UP BGlJ91B48PvuBKqmocGaNvcIyfiotqGyX6hoyNk0fqSNiI8XtVelAd//O1YmHVYf/RQf 0wzbY+vZAHXpWJ6QNT2cPlkPdm1NA+VUYw2LnLo8B+SyBKjNNcYVCvxusuh6PHctAUFU NXYousnKOOYbVTVLYCXGgch4Mg7PsIw78elj6R2GF2A6S3KBgdrhGVnRH+azqZz7FVqm vcoQgD/ZbbxcACleujs/w51/DC1aWhM39uLvHVm7AbHe+oEFUD81ezC7NEhCW/5zVgi+ Q0bA== X-Gm-Message-State: APjAAAUh5ykyE+/1DL3BQg/DqeXdxmzSJhKSsmWXYJACVCrmOkeOl98Z VXD53vyWDOQ6HnPkQp7xPKHtr8coNQqfl60tevg= X-Google-Smtp-Source: APXvYqy5yZx65j7JWvJZr+g3CtprEDPOhLy84V1EWItnpywNWwM9b1Lc2HA3tasaCOV9OGxg7lxPKV7meio2q1pBx/U= X-Received: by 2002:a19:7716:: with SMTP id s22mr22085463lfc.64.1560307425906; Tue, 11 Jun 2019 19:43:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Wed, 12 Jun 2019 11:43:34 +0900 Message-ID: Subject: Re: Analysing the HTTP/3 error code space To: Mike Bishop Cc: Martin Duke , Lucas Pardue , Ian Swett , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 02:43:52 -0000 2019=E5=B9=B46=E6=9C=8812=E6=97=A5(=E6=B0=B4) 6:41 Mike Bishop : > > I was previously affiliated with an HTTP stack that I assume still needs = HTTP_VERSION_FALLBACK for some corner cases including, but not limited to, = renegotiation. This WG previously had a discussion about whether it should= fall back to HTTP/2 (logical, but likely has all the same incompatible sce= narios that HTTP/3 does) or HTTP/1.1, and concluded that it would be sad to= make someone fall from 3 -> 2 -> 1.1 when probably can=E2=80=99t answer ov= er anything higher than 1.1 anyway. > > > > > 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3 e= rror codes. However, it states that HTTP/2's PROTOCOL_ERROR has no single e= quivalent, which I think is incorrect becuase HTTP/3 has HTTP_GENERAL_PROTO= COL_ERROR. > > > > Mostly because the various MALFORMED_FRAME errors would also have been PR= OTOCOL_ERROR in HTTP/2. We could make the text point to GPE, while noting = that specific error codes have been added for certain situations. > > > > > 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and very = similar. The former is used by a peer that receives a valid frame on a stre= am that it should never be sent on, the latter is used by a peer that recei= ves a valid frame on a stream that is normally ok but has transitioned to a= n application-level stream state which prohibits it. > > > Rationalising these seems like a logical option. > > > > Seems reasonable. I believe there was previous discussion about possibly= combining them, but I can=E2=80=99t find it with a cursory search. > > > > > 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case, = a client send NUM_PLACEHOLDER. Declassifying this as an error seems like a = sensile option. This frees up error code 0x1, which we can move HTTP_GENERA= L_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2). > > > 7) There are several error cases related to SETTINGS; a frame that can = be sent most once per connection. I made a proposal to address this on issu= e #2783 [3] > > > > I need to think more about the proposal in #2783, but that=E2=80=99s semi= -orthogonal to the error conversation. I like the suggestion from the inte= rim to consolidate these to a more general INVALID_SETTINGS error, though i= f we go the route of #2783, that might become a STREAM_HEADER_ERROR =C3=A0 = la (8). > > > > > 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar bu= t may be useful to understand the different reason that clients reject serv= er push. This is extra fidelity on top of HTTP/2. > > > 4) There are several error codes related to handling requests and > > responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, HTTP_EARLY_RE= SPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than HTTP/2 provide= d. This may extra information may allow endpoints to make smarter decisions= about retrying requests. However, it may also be possible to infer things = from a stream error that contains simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONS= E could benefit from this) > > > > We need the CANCELLED/REJECTED split to understand when a server is decla= ring that no processing occurred versus reflecting back the error code from= the client=E2=80=99s STOP_SENDING in a RESET_STREAM. (The resolution to t= hat is that clients don=E2=80=99t send REJECTED, and it has the additional = semantic when coming from a server.) If we didn=E2=80=99t have INCOMPLETE_= REQUEST, I=E2=80=99m unsure what we=E2=80=99d send in that situation instea= d; it=E2=80=99s certainly not a NO_ERROR situation. > > > > Folding EARLY_RESPONSE into NO_ERROR would be reasonable. > > > > > 5) The error code guidance is often not symmetric. Client or servers us= e error codes differently and little guidance is provided on how to process= an error code that in theory should never be sent. > > > > The only possible response is blowing up the connection, isn=E2=80=99t it= ? Which is superfluous if you=E2=80=99ve received a nonsensical connection= error, because the connection is already being blown up by the peer. So t= he more scoped question is, if a stream sees a RESET/STOP_SENDING with an e= rror code that a) should only have originated from your side, or b) can onl= y be a connection error, what do you do? > > > > > 6) There is little guidance on how an intermediary that translates betw= een HTTP/2 and HTTP/3 should map these divergent error code spaces. It woul= d pay to align them as close as possible and provide some guidance on how t= o map higher fidelity codes to lower fidelity codes. > > > > That=E2=80=99s a good point. However, error codes are hop-to-hop =E2=80= =93 I suspect that any error code gets turned into a status code 502, with = the possible exception of REJECTED. Do expect anyone to build a 2/3 interm= ediary who isn=E2=80=99t also terminating the HTTP semantic layer? Not that we do now as a proxy implementation, but I think it would be preferable to propagate "temporary" errors (REFUSED_STREAM), and also CONNECT_ERROR to indicate reset of a websocket connection. For all other errors I think that 502 can be used. It might be worth clarifying that such behavior is to be expected (or preferable). > > > > > 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing t= he unidirectional stream type header. We might be able to merge these into = a error such as HTTP_STREAM_HEADER_ERROR and state the code has different a= pplicability between STOP_SENDING and CONNECTION_CLOSE frames. > > > 9) Critical streams such as control stream and QPACK streams can be cre= ated only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams can onl= y be created by a server and HTTP_WRONG_STREAM_DIRECTION captures this. We = could rationalise these into HTTP_STREAM_CREATION_ERROR, that could even in= corporate suggestion 8. > > > > DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same Push= ID. Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR seems like = a reasonable collation; I agree that those are ultimately the same proposal= . > > > > > > From: QUIC On Behalf Of Martin Duke > Sent: Tuesday, June 11, 2019 12:37 PM > To: Lucas Pardue > Cc: Ian Swett ; QUIC WG > Subject: Re: Analysing the HTTP/3 error code space > > > > I would insist on INTERNAL_ERROR. It is great for various malloc problems= , as well as for signalling that something went wrong on the back end in pr= oxy scenarios. It is a catch-all for "I screwed up and can't continue". > > > > On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue wrote: > > Hey Ian, > > On Tue, Jun 11, 2019 at 7:14 PM Ian Swett wrote: > > > >> > >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has been > >> replaced by HTTP_MALFORMED_FRAME, which actually covers a range of > >> values - it dedicates a byte to encode the frame type. This is > >> problematic since the frame type changed to be a 62-bit integer > >> itself. In my personal opinion, this error code is more complicated > >> than needs be and was incorrectly applied. Issue #2551 [1] captures > >> this, and PR #2662 [2] contains a proposed set of replacement codes. > >> That PR adds 4 error codes to bring the total up to 28. > > > > > > I like your proposed PR. > > Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for > things that are frame size errors) and adds some new error codes in > agreement with our current philosophy. I would refine the PR to agree > with the outcome of this thread. > > > > > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which ar= e never used? I'm unclear on what the intended usage is? > > I realised I didn't qualify one aspect of my analysis - the guidance > count metric is only one signal. HTTP_INTERNAL_ERROR is described as > "An internal error has occurred in the HTTP stack.", which feels like > an implementation-oriented error code. I think it is valid in staying > in HTTP/3, especially if it is used in HTTP/2 (I don't have data to > hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; > it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is > only recommended when the server wants to use TLS renegotiation. IMO > it is of limited value unless we import the same behaviour into > HTTP/3. --=20 Kazuho Oku From nobody Tue Jun 11 23:02:01 2019 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 91AC812007A for ; Tue, 11 Jun 2019 23:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=FrmkeGcm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n5vklTUW 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 ZIZulzvbe5lT for ; Tue, 11 Jun 2019 23:01:57 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D48120077 for ; Tue, 11 Jun 2019 23:01:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 3033E4E5; Wed, 12 Jun 2019 02:01:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 12 Jun 2019 02:01:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm2; bh=TkOipKNJvmMgGHNeKvkR3zJMoIiyAp EUpw+/BUKZHR8=; b=FrmkeGcmwvfJOR8/300AsoLFN5iZov1ng6ZpFkGl7lbNNX AhAhkUyAk43Nshi7qjK0ouqP3nEQx1aqPesI3gbOD8b3aY1rjR1Ex9gVctwurydo TQF2NNKC8X5n+dJLZfcRn8quwCZnglKt4jgqBHiHwsD1SacSTj6+FlI9DLDOtHCK lI7JmoLEHMq2TZNL1nna492RRHR+zq9zhpsM0eujXseUeHsiIthh5A58QTFxBo8a Cw91+BPeMWsfQCI9iDiksOZGxohktv+v/Z8GLyVK/4JQt8CsHnAmM3DFbLXVyV0P pNt9uQ3XDswFMs6fzFVQsULsaNuV5UVXQPNTTq1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=TkOipK NJvmMgGHNeKvkR3zJMoIiyApEUpw+/BUKZHR8=; b=n5vklTUWwnKXns63WvQWdx hTGPffqJNp+/AyAkGyL38PNnb5u6+w6XWbaLuT69qbTYdR670GD06BicEC5n7fB4 7JX5px6oaB1Cl1ExVNwYBS4o02FbBTee8OeG8A8L/Ap3XbFBVH1Xze41ykqisJbR vdTDWUxLHjfkdnZuhubyIlxWFCtqjKCOP4BDLsv39EONNKMK115/2QtyEpBV2l37 1PBw7rWqAniaOohZRFc/9+hyustXf0ZCisGRH9MIg8qCmSBXTz05yQsCTPKFN3Q4 8MB7E0I/xKSeyth2nq0SNrhw3hysxtmuzeMO5XEfzEOcwl/DPExofn9zc5hKFpqw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehiedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhtgfgggfukfffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeeh rddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.7.11] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id A3F0880059; Wed, 12 Jun 2019 02:01:53 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Consensus Call: More Connection ID Space #2736 Message-Id: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> Date: Wed, 12 Jun 2019 16:01:48 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 06:02:00 -0000 Regarding: The editors believe that this PR resolved the issue: ....and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 11 23:28:45 2019 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 DC9461200A3 for ; Tue, 11 Jun 2019 23:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=tdgS87AA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hw5kNj02 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 HOAFq3To8ScE for ; Tue, 11 Jun 2019 23:28:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4C3120086 for ; Tue, 11 Jun 2019 23:28:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9B8BB21B62 for ; Wed, 12 Jun 2019 02:28:40 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 12 Jun 2019 02:28:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=9uYhFfmv6NBFAAyDwX+vleylRAFVwrz 6Sqzu87qW6LU=; b=tdgS87AAYnoN+9lwgNjuAJrJ/YcMNlbnZgaHykHUQA4T1Xb Hy/VtEfF1Sh4BWUD5JxqU5vhEiXFm22Jg7osgnKQ38DYYBP8MMP1etABhi06Qi42 +OTi6g8WYQbsLIRCJ0X7W+Y4/8OWA7Z46j7Va6+V18K79L312XLYwYf8YLsTabID lf03mlYopYXW4wRkorpWatp9ziGhbRwWkOkJNgH6j+JGoXP3lmlx/nWrdwGRwosL 3c5oAl/DgMeJoJb0xe/6v63U38MHQCTiYUrRWtCYfQsdRGBK5aduqUZuDDav6Aau Cawd+00AHIGc32qTjEAkfU6+iRO6is+/4470hgQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9uYhFf mv6NBFAAyDwX+vleylRAFVwrz6Sqzu87qW6LU=; b=Hw5kNj02Qb0TmjAhvIcq7A DSEAnaG0cJ7lYI/lx6OYD3+KtY6dWwhQszL9boR1YJZMHXEvZxrl+iepdRt1VdqH YJIY9GmoWT8pQfLCUVqnbhYHVlY6g1EFX9iTpv2u3YcscTQWwxWzRYQ8eybuAMh6 bkkBnEHjLFxi+R87v+1zs2Q6YHw8bYE6JU2WuMHqn7G4FxxCxNSOkMPCO++EnzwV BO7epZw44l1hh5aCptA+sDATGaQgFywgUPF1rG26PtSKZ9p5OiJWoMlWP0NvXLKs VMpxia5K+h0Ullak0Xs/TVXBib4FZlLt2IWv8dQxbqEG0psm9aLKW5X8f8AoSDYQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehiedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpmh hnohhtrdhnvghtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhho phihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 26CCBE00A2; Wed, 12 Jun 2019 02:28:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> In-Reply-To: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> Date: Wed, 12 Jun 2019 16:28:41 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Call: More Connection ID Space #2736 Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 06:28:44 -0000 Unlike other consensus calls, which seem to have passed without comment, I'd like to encourage people who support this to say something. This is a change to a document that we previously agreed would not change. On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote: > Regarding: > > > The editors believe that this PR resolved the issue: > > > .....and discussion so far seems to support consensus to do so. If you > object, please do so on the issue or in response to this message; > absent any pushback, we'll declare consensus at the end of the week. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > From giulio.bosco@cscs.ch Tue Jun 11 23:45:35 2019 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 674621200BA for ; Tue, 11 Jun 2019 23:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 FSewj-BgM_fd for ; Tue, 11 Jun 2019 23:45:33 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AEE1200B8 for ; Tue, 11 Jun 2019 23:45:32 -0700 (PDT) Received: from CAS12.d.ethz.ch (172.31.38.212) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 12 Jun 2019 08:43:56 +0200 Received: from MBX212.d.ethz.ch ([fe80::8519:c2cc:67e7:96cb]) by CAS12.d.ethz.ch ([fe80::7861:4ecb:7c42:cad4%10]) with mapi id 14.03.0439.000; Wed, 12 Jun 2019 08:44:00 +0200 From: "Bosco Giulio" To: "quic@ietf.org" Subject: QUIC command line tool Thread-Topic: QUIC command line tool Thread-Index: AQHVIOo2sjfzCN5BdkeSNZ7rbs4vMQ== Date: Wed, 12 Jun 2019 06:43:58 +0000 Message-ID: <8D88F752-3DBF-4EE4-9C10-98EE339770B4@cscs.ch> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.139.5] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 12 Jun 2019 00:10:30 -0700 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 06:58:49 -0000 SGksDQoNCknigJltIGRvaW5nIHNvbWUgdGVzdHMgb24gUVVJQywgZm9yIGh0dHBzOi8vY3Njcy5j aCBhbmQgSSBuZXZlciBmb3VuZCBhbnkgY29tbWFuZCBsaW5lIFFVSUMgVG9vbCwgdGhlcmUgaXMg b25lPw0KDQpUaGFua3MNCg0KQmVzdCByZWdhcmRzDQoNCkdpdWxpbyBCb3Njbw0KQ1NDUw== From nobody Wed Jun 12 09:13:42 2019 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 72C04120088 for ; Wed, 12 Jun 2019 09:13:40 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=fb.com header.b=hMkAIE/R; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=gT8dq7L4 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 QWRt__hxNkLS for ; Wed, 12 Jun 2019 09:13:38 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732CD12004F for ; Wed, 12 Jun 2019 09:13:38 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5CG8mIT010436; Wed, 12 Jun 2019 09:13:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=Df0/VI+Q/piM3ITie6xTV1iuIqUkDiAaSc/oRvlDccU=; b=hMkAIE/RlSrdHYfamzz/wC3ie3ywozBzaerEYlK5pFYR/1uX6uBE0OkCUGBHC1q5dOGl Z2SqNnyhhiV6RiI9OOFYF6LNDcjYT1Fm/VAqY+aS6i07UFz8+CUKCzCIjl5DfvyxmIHg 9nKdh23sbS1u5Dd86znH1lDClf4Px7PHJ2A= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2t2vwy1jeq-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Jun 2019 09:13:34 -0700 Received: from ash-exhub202.TheFacebook.com (2620:10d:c0a8:83::6) by ash-exhub204.TheFacebook.com (2620:10d:c0a8:83::4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 12 Jun 2019 09:13:31 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 12 Jun 2019 09:13:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Df0/VI+Q/piM3ITie6xTV1iuIqUkDiAaSc/oRvlDccU=; b=gT8dq7L4mRH0Og7o3+Wd8u8ANj4qH7c4OlIoH1q1GMLmwHBkhYuiVZzUbYKGg8JSCa9gzT7U/LTsG0CZPy/fRdkcRqfXKxcxNU/mGoijuwofM97JAgALKSsvAGIMu71PfUl6ja98INi404wQEuX26mhssLrnkrQsIy+cX8SRnoQ= Received: from MWHPR15MB1181.namprd15.prod.outlook.com (10.175.9.8) by MWHPR15MB1312.namprd15.prod.outlook.com (10.175.4.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Wed, 12 Jun 2019 16:13:30 +0000 Received: from MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::e9e3:7a6d:bb46:4e15]) by MWHPR15MB1181.namprd15.prod.outlook.com ([fe80::e9e3:7a6d:bb46:4e15%6]) with mapi id 15.20.1987.012; Wed, 12 Jun 2019 16:13:30 +0000 From: Alan Frindell To: "Bosco Giulio" , "quic@ietf.org" Subject: Re: QUIC command line tool Thread-Topic: QUIC command line tool Thread-Index: AQHVIOo2sjfzCN5BdkeSNZ7rbs4vMaaXvF6A Date: Wed, 12 Jun 2019 16:13:30 +0000 Message-ID: References: <8D88F752-3DBF-4EE4-9C10-98EE339770B4@cscs.ch> In-Reply-To: <8D88F752-3DBF-4EE4-9C10-98EE339770B4@cscs.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-originating-ip: [2620:10d:c090:200::d78b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bdc81dd1-ac7d-4ee1-d83b-08d6ef50e8fa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR15MB1312; x-ms-traffictypediagnostic: MWHPR15MB1312: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2043; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(39860400002)(396003)(376002)(199004)(189003)(7736002)(256004)(46003)(305945005)(2906002)(5660300002)(446003)(2616005)(4744005)(8936002)(8676002)(11346002)(476003)(36756003)(71190400001)(71200400001)(486006)(6116002)(81166006)(81156014)(2501003)(3480700005)(110136005)(6246003)(25786009)(6436002)(6306002)(6512007)(99286004)(53936002)(86362001)(14454004)(102836004)(6506007)(76176011)(6486002)(73956011)(966005)(66446008)(316002)(66946007)(64756008)(66556008)(66476007)(58126008)(76116006)(68736007)(478600001)(33656002)(229853002)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1312; H:MWHPR15MB1181.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zhFHwjMd6kJ0z0+NbhMv9Frk0OiCbuXbE0tcesbq30nOX2hhBzTntfEJqSU63qN40mhNX9R7ARD75zXGQ3Y/OThVrwkJSM+xn0n7ryjPJzEqItGM76+hsJGdgSi2f3V7TihBT2N6HTyeYsEB7ZTNsWfucHtO5B68GVx4ThIGHhb2c7d1d1xmk13oKqMMHudIJMLbnxPkgW7olrjsNSt8H+GzOIEkHEDDsQYvRmvZ0V34al/GH+jZIoz3i3zYflM5yYB15KGiMr1ZimXnbSY6x46Fv93unq4dOFciMSLs0EmK29Me0fchMvgMd+o3Yg9S0N6Q5/HO5MTIebg48qYJVrRd8MCzw66ltbUHxn7ERtPvQSNNG2swH752EHEChFW2u0ivs8TWaj7F2B2+xKhTAXygp0kb3hGjo/SOY58JJbo= Content-Type: text/plain; charset="utf-8" Content-ID: <60FCD72AFCF3EB419EB2CD6E27B24B44@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bdc81dd1-ac7d-4ee1-d83b-08d6ef50e8fa X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 16:13:30.3618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: afrind@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1312 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906120109 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 16:13:41 -0000 V2hhdCBraW5kIG9mIG9wZXJhdGlvbnMgZG8geW91IHdhbnQgdG8gcGVyZm9ybSB3aXRoIGEgUVVJ QyBjb21tYW5kIGxpbmUgdG9vbD8NCg0KVGhlIHByb3h5Z2VuIG9wZW4gc291cmNlIHByb2plY3Qg KGh0dHBzOi8vZ2l0aHViLmNvbS9mYWNlYm9vay9wcm94eWdlbi8pIGhhcyBhIGNvbW1hbmQgbGlu ZSB0b29sIGNhbGxlZCAnaHEnIHdoaWNoIGNhbiBhY3QgYXMgYW4gSFRUUC8zIGNsaWVudCBvciBz ZXJ2ZXIsIHVzaW5nIHRoZSBtdmZzdCBRVUlDIGltcGxlbWVudGF0aW9uLg0KDQotQWxhbg0KDQrv u79PbiA2LzEyLzE5LCAxMjoxMCBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIEJvc2NvICBHaXVsaW8i IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGdpdWxpby5ib3Njb0Bjc2NzLmNo PiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIEnigJltIGRvaW5nIHNvbWUgdGVzdHMgb24g UVVJQywgZm9yIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fY3Njcy5jaCZkPUR3SUdhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj0xSVRLc1pB ZURhdzY1ZXlRY2RWR2N3Jm09bVlqZ2tpUzVRbVFPMUE5WmNoVmlLRHJ2U255TVM5a1ZZQ1hRQnFR RHZ4VSZzPUluTGFyN1ZDQ1Jxa3ZJc0lhT2xzNDEyWEJxRVNDbjRMR280eG9peDA1cTgmZT0gIGFu ZCBJIG5ldmVyIGZvdW5kIGFueSBjb21tYW5kIGxpbmUgUVVJQyBUb29sLCB0aGVyZSBpcyBvbmU/ DQogICAgDQogICAgVGhhbmtzDQogICAgDQogICAgQmVzdCByZWdhcmRzDQogICAgDQogICAgR2l1 bGlvIEJvc2NvDQogICAgQ1NDUw0KDQo= From nobody Wed Jun 12 09:16:37 2019 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 9BEE41200B9 for ; Wed, 12 Jun 2019 09:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 8KXWMzyWsHyg for ; Wed, 12 Jun 2019 09:16:33 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5097412022D for ; Wed, 12 Jun 2019 09:16:33 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id v193so5122309itc.0 for ; Wed, 12 Jun 2019 09:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oxIVkKZwfYCpaGSWyQh3kYEyRAut5mTlpASu8lp2ilU=; b=U5zbq2EHXrXpJS85eJdxl+daUXQ+d0Zqd2jTv7s4PWQsfoqET7tCL28jlDkUwsFrL6 QWuY4WSs1uet6xP5dBnYyJDqeNcJNwTS2ykHtVp++7ruE9j7h4kW+3W74FxPsUX+URGP E+BKGJZnzaQpJUscm9blLbF14dnZotbbZ/PIUl3CHM1ZIcUwFiRnjaa5wpQOrH1PH2cV xZhF9TJIZqym6cEbZ2ACjtEd6leNxC1Cxeonh1GXS2HY/mMsdvnGDSKQCKtuhlYck9Ym Fql9Vq+bDy46jJxY05K7y+hxlSSdEXbFpPRvZFG+GJZdqCIJFeuNuWIsFh+Q/GxK7SMa tzAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oxIVkKZwfYCpaGSWyQh3kYEyRAut5mTlpASu8lp2ilU=; b=HnspOXq3kuLVlnLki4hJsvKNRCv6zRCVTvnN0Ix+aHvy0M+5yETqDTsJCU8aUPKgGU sQwR7xtXPDlJK1aaG7WePmWzHykibtBsMtCqELfJtor13y1D29qz7wT57mLRnu4fIXlJ 9pH8LIAtQ7j5XfLdKYH9Q+v03K0NC3Vzb3+de7jmYQZVch8c7kb1CB5OOzFKZm2RODG9 3hX+VEVfjPXpGhj4lZXmzRmgsABun6Sl9DqprVSdPHCNxTzkIfWWdY7h3thyvcpY4jIB Hbdwct3tV/bLj7MIy+jlJm/T4BByHZFnz1v8S4JJCGnHi7Dpc/3Rx2HlvbSo93dPtGhJ Hp6Q== X-Gm-Message-State: APjAAAXHpKEp/9j9cK3GYoULjIXtB/nDgho4mxTr6bqHCM2fz5DSF/RC ScdLMp+Hohp/4RasYOaylDGnfY8Anl2agmkbA9Y= X-Google-Smtp-Source: APXvYqycF0H/F1lEwG0HryFvmeYX//3L2ltLjElVo4GyceNdHoeDgNzlfuGfNmvAlEc/qLhwvmGO0kjr7TJLaAxAA04= X-Received: by 2002:a05:660c:552:: with SMTP id w18mr21765315itk.26.1560356192453; Wed, 12 Jun 2019 09:16:32 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> In-Reply-To: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> From: Ted Hardie Date: Wed, 12 Jun 2019 09:16:06 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Mark Nottingham Cc: QUIC IETF mailing list , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000930d08058b22bccd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 16:16:35 -0000 --000000000000930d08058b22bccd Content-Type: text/plain; charset="UTF-8" Hi Mark, https://github.com/quicwg/base-drafts/issues/2770 was raised in part because of this change, and it is not resolved. While I do not expect that it will cause a reversion of this design theory, it might be useful to wait on declaring consensus for this until it resolves, in case the resolution suggests a limit change. Could we encourage folks to test with the higher limits and new encoding for now, but not close the issue? regards, Ted On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham wrote: > Regarding: > > > The editors believe that this PR resolved the issue: > > > .....and discussion so far seems to support consensus to do so. If you > object, please do so on the issue or in response to this message; absent > any pushback, we'll declare consensus at the end of the week. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > --000000000000930d08058b22bccd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

https://github.com/quicwg/base-d= rafts/issues/2770 was raised in part because of this change, and it is = not resolved.=C2=A0 While I do not expect that it will cause a reversion of= this design theory, it might be useful to wait on declaring consensus for = this until it resolves, in case the resolution suggests a limit change.

Could we encourage folks to test with the higher limi= ts and new encoding for now, but not close the issue?

<= div>regards,

Ted

On Tue, Jun 11, 2019 at = 11:02 PM Mark Nottingham <mnot@mnot.net= > wrote:
= Regarding:
<https://github.com/quicwg/base-drafts/issues/27= 36>

The editors believe that this PR resolved the issue:
<https://github.com/quicwg/base-drafts/pull/2749>

.....and discussion so far seems to support consensus to do so. If you obje= ct, please do so on the issue or in response to this message; absent any pu= shback, we'll declare consensus at the end of the week.

Regards,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--000000000000930d08058b22bccd-- From nobody Wed Jun 12 09:38:07 2019 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 9F8E4120144 for ; Wed, 12 Jun 2019 09:38:05 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=fb.com header.b=YK+MzZoN; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HJP9o3LR 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 EOvXru2t4B41 for ; Wed, 12 Jun 2019 09:38:04 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201FD120131 for ; Wed, 12 Jun 2019 09:38:03 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5CGbR4I003783; Wed, 12 Jun 2019 09:38:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=y7O9UEjQ1OwjC0VCMuo4HgWd36NuaCAHBiP7K9ToxNs=; b=YK+MzZoNHoNUeV42ootUdidphz/4M1e0GhFpdIwhlsEH7efaHz3gYCXIDh2Zp02C+Hkq 7l4WAW08bm2wphx7VLrgiFQOqJ2uKljnfGWPifObzfcvI6xNMgp7Su0Hi+P6grayMxUt eky1s46Pu0fsyb7QIahFbt5Q+F7rw2aEePg= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2t2vwy1n06-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Jun 2019 09:38:02 -0700 Received: from ash-exhub203.TheFacebook.com (2620:10d:c0a8:83::5) by ash-exhub102.TheFacebook.com (2620:10d:c0a8:82::f) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 12 Jun 2019 09:38:00 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 12 Jun 2019 09:37:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y7O9UEjQ1OwjC0VCMuo4HgWd36NuaCAHBiP7K9ToxNs=; b=HJP9o3LRi8GxqLu2GbzxedpuudDbgCXyt22qK0iKJHxnEape7C3EyR/+dMxh06keCH21pbhIBfPqtbhWyee0cRjBng7BtGDYQC45Pa2Dxy6YBRwK2AOqJeMvGHOO2BsVnYpRppZ9EXw8ZVnz7jQ6S0rwKXifSmXvI0ciOh7UqCg= Received: from CY4PR15MB1542.namprd15.prod.outlook.com (10.172.160.9) by CY4PR15MB1430.namprd15.prod.outlook.com (10.172.160.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Wed, 12 Jun 2019 16:37:59 +0000 Received: from CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a]) by CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a%9]) with mapi id 15.20.1965.017; Wed, 12 Jun 2019 16:37:59 +0000 From: Roberto Peon To: Martin Thomson , "quic@ietf.org" Subject: Re: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORjFtUmRAvDTkuJte7HuW7cSKaXjl6AgAA04gA= Date: Wed, 12 Jun 2019 16:37:58 +0000 Message-ID: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> In-Reply-To: <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-originating-ip: [2620:10d:c090:200::1:ebec] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9dbb0ba4-d691-4b2f-4df2-08d6ef545460 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR15MB1430; x-ms-traffictypediagnostic: CY4PR15MB1430: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(366004)(39860400002)(396003)(376002)(199004)(189003)(229853002)(71190400001)(25786009)(71200400001)(36756003)(5660300002)(4744005)(2501003)(6246003)(305945005)(53936002)(99286004)(110136005)(68736007)(256004)(58126008)(316002)(73956011)(6506007)(966005)(102836004)(86362001)(81166006)(66556008)(64756008)(66446008)(186003)(6512007)(91956017)(8676002)(33656002)(76116006)(8936002)(66476007)(14454004)(76176011)(6116002)(486006)(66946007)(11346002)(446003)(6436002)(6486002)(81156014)(478600001)(2616005)(476003)(2906002)(46003)(6306002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1430; H:CY4PR15MB1542.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BU33oPhGGs07A5UXyXDxIYa+jVGVxuGAkFCsTCO8RRQ/F60/OJxpDJJ4zzev09O546YEz2vYox/k9heJQC7lYbTdXZ/gEgfUuaLonmKSq+cIA2vikx+n+BdTNmAcRPCCOhR4NX2VmGcUu2PZoiWPxa6tGXxzTin1Mi+vLswEqEzokCPMpyTI2vZVAUS+lNoFOPYuquU/IlI457RAs3QVXbSIYl0jgEQ13E4CY4lO5L4sF2w5PdsLg3sMwFFUzVsXY6+0k/yIDyCrk4A0QPY/S4ozsUc4MF85JpJKKAVB4UW2RQI2rUkG0rrE5Kkr+wTdVPbO95cVNQrb8pFdRr6a4jv/Gb2G4igus84QiAxc6XGnSzziWaLWQONkv3/53NJHjTxeDCniIDXJGjYgk59ur9zfWvRaKSvjZgc9+S2Z6Wc= Content-Type: text/plain; charset="utf-8" Content-ID: <1B4609FDC0BA1946B778B1AE0C2D3FC6@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9dbb0ba4-d691-4b2f-4df2-08d6ef545460 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 16:37:59.0091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fenix@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1430 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906120112 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 16:38:06 -0000 SSBiZWxpZXZlIHRoZSBiZW5lZml0cyBvdXR3ZWlnaCB0aGUgZG93bnNpZGVzIGF0IHRoZSBtb21l bnQuDQoNCu+7v09uIDYvMTEvMTksIDExOjI5IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2YgTWFydGlu IFRob21zb24iIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG10QGxvd2VudHJv cHkubmV0PiB3cm90ZToNCg0KICAgIFVubGlrZSBvdGhlciBjb25zZW5zdXMgY2FsbHMsIHdoaWNo IHNlZW0gdG8gaGF2ZSBwYXNzZWQgd2l0aG91dCBjb21tZW50LCBJJ2QgbGlrZSB0byBlbmNvdXJh Z2UgcGVvcGxlIHdobyBzdXBwb3J0IHRoaXMgdG8gc2F5IHNvbWV0aGluZy4gIFRoaXMgaXMgYSBj aGFuZ2UgdG8gYSBkb2N1bWVudCB0aGF0IHdlIHByZXZpb3VzbHkgYWdyZWVkIHdvdWxkIG5vdCBj aGFuZ2UuDQogICAgDQogICAgT24gV2VkLCBKdW4gMTIsIDIwMTksIGF0IDE2OjAyLCBNYXJrIE5v dHRpbmdoYW0gd3JvdGU6DQogICAgPiBSZWdhcmRpbmc6DQogICAgPiA8aHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjczNj4NCiAgICA+IA0KICAgID4gVGhlIGVk aXRvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgUFIgcmVzb2x2ZWQgdGhlIGlzc3VlOg0KICAgID4gPGh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8yNzQ5Pg0KICAgID4gDQog ICAgPiAuLi4uLmFuZCBkaXNjdXNzaW9uIHNvIGZhciBzZWVtcyB0byBzdXBwb3J0IGNvbnNlbnN1 cyB0byBkbyBzby4gSWYgeW91IA0KICAgID4gb2JqZWN0LCBwbGVhc2UgZG8gc28gb24gdGhlIGlz c3VlIG9yIGluIHJlc3BvbnNlIHRvIHRoaXMgbWVzc2FnZTsgDQogICAgPiBhYnNlbnQgYW55IHB1 c2hiYWNrLCB3ZSdsbCBkZWNsYXJlIGNvbnNlbnN1cyBhdCB0aGUgZW5kIG9mIHRoZSB3ZWVrLg0K ICAgID4gDQogICAgPiBSZWdhcmRzLA0KICAgID4gDQogICAgPiAtLQ0KICAgID4gTWFyayBOb3R0 aW5naGFtICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cubW5vdC5uZXRfJmQ9RHdJQkFnJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUMw c1VvLUxGTkJhWWZ5b2FDc2Y2VEEmbT0zanR0WVdjR0hfSDlHYUNDR1REa3g3MWhfSXRCSXVfa29M b2FveklMYnE0JnM9SzNKbjVNU0t0QVV2OVE4SlV5T0xzSDRPY1hBc2pMSTViVjRnOGloSEJaWSZl PSANCiAgICA+IA0KICAgID4NCiAgICANCiAgICANCg0K From nobody Wed Jun 12 10:44:57 2019 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 CB5FD120089 for ; Wed, 12 Jun 2019 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 BHXinuIbRIbw for ; Wed, 12 Jun 2019 10:44:53 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030B012004B for ; Wed, 12 Jun 2019 10:44:53 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id 136so12844267lfa.8 for ; Wed, 12 Jun 2019 10:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9eRUnV1hQFJUIh0bSr6KbjbVBykloquQ2GWqr/yYnI0=; b=FM8oW/Ndlh2gZ0dBCi6NRSjkKPqUoEgT6J9k+ieqOvnBo8gFEh0VxcenZXzPbkOdpk a+IEPOmDrVSuYeSuSjQQSc6vahhKEryUZoJvSZGlVQ/K8GyHuoqyiShcvytNPfKXNmRz lEj1FXi5x8J6C8zTNj4m52N56PmkHEUHs2x2TNj2VrkxX2gKbhbeZnr978VzzVeDtVYq MISTDa81iqJWUSSTsBQ1RQwN2n0UkJjs1bA62vuSqb2MI00KInnpryzh7WyuTkl+Q9S0 WhhSgtX5HCarpxG0mxlQWWX31gr6VGHeNe38mlbu1aFGLaKXmoHvLT47U6aDXVTQVVvE eh5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9eRUnV1hQFJUIh0bSr6KbjbVBykloquQ2GWqr/yYnI0=; b=YCpmLiUyWJORuGFvv/hsQ+uGeGZN38JwGLV1u+g4FZNwMlGreRdzLVPCtc0HRemBBh 32G3fTArdlyv4aNgn+xC55NQNaLi2QB+M/LETxykpod1zS9jsGC6apLPM8wKlsI7JDto 4BE3J5vWGv4DnkY2/Ok2srvQa+NJ4YmepaU4FEJ5iDlXUvGg/x+U1d43Bv1ojQu+LAna 07xPUJBTJ9O666L0HUHUdt82gD1NmYoJbbIfKX9o45eLZnd8NyQLkA9iW61TfwupHiY3 6GXLiuKrpJIc1mS820fak1uIjGxJcvQ2lev9Djwt6zI9AnK3U0RYXnDFP3pWRuffdmyF zkKg== X-Gm-Message-State: APjAAAXWDCg+nQMU0Cu/ZukozUFBi0N7NkwthLfWFfk+PbsjotSE9F3P 3XWblXFy1BJZxoE2Mt9khLl1nLv3ULpDSXhiAm8= X-Google-Smtp-Source: APXvYqyaSX+sW4QKzeUIo+pggFp6DGMBLQZG+51bHmU1fuu/+jl0mMdKbHI1R87YFOjxKoVAY3AUmmbIU5NA2gjt43Q= X-Received: by 2002:ac2:46ce:: with SMTP id p14mr7108729lfo.148.1560361491101; Wed, 12 Jun 2019 10:44:51 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> In-Reply-To: From: David Schinazi Date: Wed, 12 Jun 2019 10:44:39 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Roberto Peon Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="00000000000065fd61058b23f8da" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 12 Jun 2019 17:44:56 -0000 --00000000000065fd61058b23f8da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the proposed change to the invariants and I think PR 2749 is ready. I do not think we should wait for the stateless reset length issue because I am confident that it will be resolved soon. Additionally, if that issue results in a limit change, that will be easier to deploy than the change to the encoding of lengths on the wire (which are in the invariants). Having the invariant changes land ASAP will make it easier to deploy in Google's production environment. David On Wed, Jun 12, 2019 at 9:38 AM Roberto Peon wrote: > I believe the benefits outweigh the downsides at the moment. > > =EF=BB=BFOn 6/11/19, 11:29 PM, "QUIC on behalf of Martin Thomson" < > quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote: > > Unlike other consensus calls, which seem to have passed without > comment, I'd like to encourage people who support this to say something. > This is a change to a document that we previously agreed would not change= . > > On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote: > > Regarding: > > > > > > The editors believe that this PR resolved the issue: > > > > > > .....and discussion so far seems to support consensus to do so. If > you > > object, please do so on the issue or in response to this message; > > absent any pushback, we'll declare consensus at the end of the week= . > > > > Regards, > > > > -- > > Mark Nottingham > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.mnot.net_&d=3D= DwIBAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA&m=3D3jttYWcGH_= H9GaCCGTDkx71h_ItBIu_koLoaozILbq4&s=3DK3Jn5MSKtAUv9Q8JUyOLsH4OcXAsjLI5bV4g8= ihHBZY&e=3D > > > > > > > > --00000000000065fd61058b23f8da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the proposed change to the invariants and I thin= k PR 2749= =C2=A0is ready.

I do not think we should wait for the stateless reset= length issue because I am confident that it will be resolved soon. Add= itionally, if that issue results in a limit change, that will be easier to = deploy than the change to the encoding of lengths on the wire (which are in= the invariants).

Having the invariant changes lan= d ASAP will make it easier to deploy in Google's production environment= .

David

=
On Wed, Jun 12, 2019 at 9:38 AM Rober= to Peon <fenix@fb.com> wrote:
=
I believe the benef= its outweigh the downsides at the moment.

=EF=BB=BFOn 6/11/19, 11:29 PM, "QUIC on behalf of Martin Thomson"= <quic-bounce= s@ietf.org on behalf of mt@lowentropy.net> wrote:

=C2=A0 =C2=A0 Unlike other consensus calls, which seem to have passed witho= ut comment, I'd like to encourage people who support this to say someth= ing.=C2=A0 This is a change to a document that we previously agreed would n= ot change.

=C2=A0 =C2=A0 On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote:
=C2=A0 =C2=A0 > Regarding:
=C2=A0 =C2=A0 > <https://github.com/quicwg/ba= se-drafts/issues/2736>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The editors believe that this PR resolved the issue:
=C2=A0 =C2=A0 > <https://github.com/quicwg/base= -drafts/pull/2749>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > .....and discussion so far seems to support consensus to= do so. If you
=C2=A0 =C2=A0 > object, please do so on the issue or in response to this= message;
=C2=A0 =C2=A0 > absent any pushback, we'll declare consensus at the = end of the week.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > Mark Nottingham=C2=A0 =C2=A0https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A__www.mnot.net_&d=3DDwIBAg&c=3D5VD= 0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA&m=3D3jttYWcGH_H9GaCC= GTDkx71h_ItBIu_koLoaozILbq4&s=3DK3Jn5MSKtAUv9Q8JUyOLsH4OcXAsjLI5bV4g8ih= HBZY&e=3D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >



--00000000000065fd61058b23f8da-- From nobody Wed Jun 12 17:56:23 2019 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 61A6A120164 for ; Wed, 12 Jun 2019 17:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 AYD5i1u8Ta9d for ; Wed, 12 Jun 2019 17:56:20 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9DC12008B for ; Wed, 12 Jun 2019 17:56:19 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id 136so13629831lfa.8 for ; Wed, 12 Jun 2019 17:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ELlS337NJQfInGvzkcZpRgu+goPICvyMtvQYE3YdnLM=; b=AZImRqzlX9iq+vdcHiCt4xkOdB4eBWK25Eec0ykrvQygATedqIjyoTMk0S5OrpcA47 DMOVJsiMd9a3ruap6QprFalQHZlNNsAgBh8SUzwmdzIg6aRoG52wij598PO/xZnrXIy6 08LHRAhXhcf1pf3CiGUaYDeLIpAQb+KMqFu/qgWWU1aVp+t+QYQSW8UiGZIWWUoKlKxM /Gf+stpyRg7MkHMYysNm2JRfUHBoLe7FWkVdTKu1TfyR/N7Ua/sWc2PVdbuf6EugjEtv 5QwP+K1Rnp+d8QJKXoG3kcfnqlTuhKsbfVWgUqb50ydicq3mNtwvmbhw91dj5Rn9pZ99 Kw5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ELlS337NJQfInGvzkcZpRgu+goPICvyMtvQYE3YdnLM=; b=IK7Hr6FYMVehJfePIIZZ7+32eDyela6G+Pp/JRKOBc/ArKqmjwIbU9Ij2QzQSnZUpq DOqeC0vZoUbXAMQfEb3eSkfdPBjHTeGpFwQeyFSyUkM33tytW5fM66mL6OPtrcXOU4Mi S2XmzXpjYBDxQiIusWQDrmL0z3bBQvv993u6H6YaUlGRIFjOShzBquVDm3OgKtrtTw0u auoHpH8m7U6U4e6k0WJtKixYwqQKxeLtEVs+jfDjHNYOrHFKAmwXeMfwo3vUcYmgwMbh ZY5sLwmYPGfLOIDU3M0/f11yzo+FX7O07qysEPymeAIZ/ms7cQPNxGg1L2NzUKa/BM9V zSPQ== X-Gm-Message-State: APjAAAWWq2TFq8EhO/9mBWAzyUw55WJIwqdHATp7sfdWrgtXlE5oZ+DS VaBhrjcURadVpNCyC39nO4X9KQP8uD2jKuCBVS8= X-Google-Smtp-Source: APXvYqzfWGqyKrq+YxDOIDdrnIGN1nCIa8I9E6+BAnAWS2l8iuwqnswD36Lnd1pAhK5QaVwhw2o1ecDPH3gH3kH6FXk= X-Received: by 2002:a19:7716:: with SMTP id s22mr25559344lfc.64.1560387377946; Wed, 12 Jun 2019 17:56:17 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> In-Reply-To: From: Kazuho Oku Date: Thu, 13 Jun 2019 09:56:07 +0900 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: David Schinazi Cc: Roberto Peon , "quic@ietf.org" , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 00:56:23 -0000 2019=E5=B9=B46=E6=9C=8813=E6=97=A5(=E6=9C=A8) 2:45 David Schinazi : > > I support the proposed change to the invariants and I think PR 2749 is re= ady. +1. I am fine with delaying the consensus call until #2770 gets resolved, but I think it would be preferable to merge #2749 to encourage people starting to use the new wire format. > I do not think we should wait for the stateless reset length issue becaus= e I am confident that it will be resolved soon. Additionally, if that issue= results in a limit change, that will be easier to deploy than the change t= o the encoding of lengths on the wire (which are in the invariants). > > Having the invariant changes land ASAP will make it easier to deploy in G= oogle's production environment.. > > David > > On Wed, Jun 12, 2019 at 9:38 AM Roberto Peon wrote: >> >> I believe the benefits outweigh the downsides at the moment. >> >> =EF=BB=BFOn 6/11/19, 11:29 PM, "QUIC on behalf of Martin Thomson" wrote: >> >> Unlike other consensus calls, which seem to have passed without comm= ent, I'd like to encourage people who support this to say something. This = is a change to a document that we previously agreed would not change. >> >> On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote: >> > Regarding: >> > >> > >> > The editors believe that this PR resolved the issue: >> > >> > >> > .....and discussion so far seems to support consensus to do so. If= you >> > object, please do so on the issue or in response to this message; >> > absent any pushback, we'll declare consensus at the end of the wee= k. >> > >> > Regards, >> > >> > -- >> > Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=3Dhtt= ps-3A__www.mnot.net_&d=3DDwIBAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaY= fyoaCsf6TA&m=3D3jttYWcGH_H9GaCCGTDkx71h_ItBIu_koLoaozILbq4&s=3DK3Jn5MSKtAUv= 9Q8JUyOLsH4OcXAsjLI5bV4g8ihHBZY&e=3D >> > >> > >> >> >> --=20 Kazuho Oku From nobody Wed Jun 12 18:59:33 2019 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 DA71E12004A for ; Wed, 12 Jun 2019 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSoVRHdxCh0w for ; Wed, 12 Jun 2019 18:59:30 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 CA37312001E for ; Wed, 12 Jun 2019 18:59:29 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x5D1ufRx006678; Wed, 12 Jun 2019 18:59:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=Hy93PYhsMXgy40nRHdv4/T4VUpRyzaB5XuU/DEvz6II=; b=Tc48bkD5UX3uEdsGSe/A9oeF/RoswEus8jyGFfFBD49FSaKLKebviEiUzHczGGozffwn hhk1GDMgG+j+vPBsZS2a3r5Lan0TQCYX5ahhZqSFcjRrDhb8JP55omH9GMg4LdZYDCo2 b+lFi8RF5GD+bUhS1CTSTyWQ6RvaURHhIAY9MsPHCR+5hlPfBHt/S75+rI0AhHBW7jx9 z5oGjRl8BO3VnHMeBb9RxAq/hmc9kpS1GHFwLmXb/gURbysGxbjPBUX/Os7njmDogY39 dfpVUb+NHZBPb+TrJjHA80S1wuk70GFhKSpovPXU3s4RTHRXrE9FARPwme3x2WHOf49p 4A== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2t09pv7ggv-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Jun 2019 18:59:26 -0700 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PT0000RKLJ25U90@mr2-mtap-s02.rno.apple.com>; Wed, 12 Jun 2019 18:59:26 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PT000300L8AEE00@nwk-mmpp-sz12.apple.com>; Wed, 12 Jun 2019 18:59:26 -0700 (PDT) X-Va-A: X-Va-T-CD: f47a32de39f1cfa35444508222caef20 X-Va-E-CD: c0dd03b56da0c06eed6995d12b46a589 X-Va-R-CD: 2f5d4cfbca99c574feea771ba5d897df X-Va-CD: 0 X-Va-ID: ab0533b2-5bc8-47a0-a49f-b01b9be6e457 X-V-A: X-V-T-CD: f47a32de39f1cfa35444508222caef20 X-V-E-CD: c0dd03b56da0c06eed6995d12b46a589 X-V-R-CD: 2f5d4cfbca99c574feea771ba5d897df X-V-CD: 0 X-V-ID: 5124292d-761a-41ce-bc5a-a2a06efbf963 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-13_01:,, signatures=0 Received: from [17.211.63.8] (unknown [17.211.63.8]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PT000DPLLJ1CQ80@nwk-mmpp-sz12.apple.com>; Wed, 12 Jun 2019 18:59:25 -0700 (PDT) Sender: ekinnear@apple.com Subject: Re: Consensus Call: More Connection ID Space #2736 From: Eric Kinnear X-Mailer: iPhone Mail (16G49) In-reply-to: Date: Wed, 12 Jun 2019 18:59:25 -0700 Cc: David Schinazi , "quic@ietf.org" , Roberto Peon , Martin Thomson Content-transfer-encoding: quoted-printable Message-id: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> To: Kazuho Oku X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-13_01:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 01:59:32 -0000 I also support this change for many of the same reasons already discussed.=20= If we=E2=80=99re already bumping up against the invariants, this is the kind= of experience that we=E2=80=99re asking folks to provide so we can make the= necessary adjustments. And if we=E2=80=99re going to change the invariants, let=E2=80=99s get it me= rged as soon as we can so we can get everything changed over to the new form= at.=20 Thanks, Eric > On Jun 12, 2019, at 5:56 PM, Kazuho Oku wrote: >=20 > 2019=E5=B9=B46=E6=9C=8813=E6=97=A5(=E6=9C=A8) 2:45 David Schinazi : >>=20 >> I support the proposed change to the invariants and I think PR 2749 is re= ady. >=20 > +1. >=20 > I am fine with delaying the consensus call until #2770 gets resolved, > but I think it would be preferable to merge #2749 to encourage people > starting to use the new wire format. >=20 >> I do not think we should wait for the stateless reset length issue becaus= e I am confident that it will be resolved soon. Additionally, if that issue r= esults in a limit change, that will be easier to deploy than the change to t= he encoding of lengths on the wire (which are in the invariants). >>=20 >> Having the invariant changes land ASAP will make it easier to deploy in G= oogle's production environment.. >>=20 >> David >>=20 >>> On Wed, Jun 12, 2019 at 9:38 AM Roberto Peon wrote: >>>=20 >>> I believe the benefits outweigh the downsides at the moment. >>>=20 >>> =EF=BB=BFOn 6/11/19, 11:29 PM, "QUIC on behalf of Martin Thomson" wrote: >>>=20 >>> Unlike other consensus calls, which seem to have passed without comme= nt, I'd like to encourage people who support this to say something. This is= a change to a document that we previously agreed would not change. >>>=20 >>>> On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote: >>>> Regarding: >>>> >>>>=20 >>>> The editors believe that this PR resolved the issue: >>>> >>>>=20 >>>> .....and discussion so far seems to support consensus to do so. If you >>>> object, please do so on the issue or in response to this message; >>>> absent any pushback, we'll declare consensus at the end of the week. >>>>=20 >>>> Regards, >>>>=20 >>>> -- >>>> Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= __www.mnot.net_&d=3DDwIBAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCs= f6TA&m=3D3jttYWcGH_H9GaCCGTDkx71h_ItBIu_koLoaozILbq4&s=3DK3Jn5MSKtAUv9Q8JUyO= LsH4OcXAsjLI5bV4g8ihHBZY&e=3D >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 > --=20 > Kazuho Oku >=20 From nobody Wed Jun 12 22:40:43 2019 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 B5F9B1201F8 for ; Wed, 12 Jun 2019 22:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2vBA3yWmnI5 for ; Wed, 12 Jun 2019 22:40:40 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376E41201D2 for ; Wed, 12 Jun 2019 22:40:40 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id D202B20054; Thu, 13 Jun 2019 08:40:37 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 32BFF61FE08; Thu, 13 Jun 2019 08:40:30 +0300 (EEST) From: Lars Eggert Message-Id: <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3B953EA6-C66E-4615-ACCE-815D34D157C4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Call: More Connection ID Space #2736 Date: Thu, 13 Jun 2019 08:40:29 +0300 In-Reply-To: <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> Cc: quic@ietf.org To: Martin Thomson References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> X-MailScanner-ID: 32BFF61FE08.A7F89 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 05:40:43 -0000 --Apple-Mail=_3B953EA6-C66E-4615-ACCE-815D34D157C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2019-6-12, at 9:28, Martin Thomson wrote: > Unlike other consensus calls, which seem to have passed without = comment, I'd like to encourage people who support this to say something. = This is a change to a document that we previously agreed would not = change. (Chair hat off) Personally, I'm somewhat disappointed about how much we feel we need to = cater to the needs/desires of the current state-of-the-art in = large-scale load balancers. 18 bytes was IMO already quite a lot, and = 256 bytes seems completely over the top. I really wonder if this will = all be pointless with next-gen LB designs. Lars --Apple-Mail=_3B953EA6-C66E-4615-ACCE-815D34D157C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAl0B4c0ACgkQHbmKvSnu NPhaYQ//fMlhhhwE0DtbAV5sOL6Ds0LGgAa/Xmy8xdho2384uoRlvwt7eKqSAdPw yuEfdG3A0US/kAx7z5CdkyoZB8miIbERWo5Ja4X2l2g2MSQsM/vikQi/CGX/gzbK oNm1xOlfLsDgzmORbQDgNMhMLxpYVn1QtvwVIWcav8KDC8ag9m2BavNJXEvInmtt d8DBWFyn3KoUe9/eGmAoNGO1FU5tm9dP+IDz0fQsEtxIuLkbwISwIqHU4+HU0xIL i7nOvAJ2lB8Tg0CsvO33KFJ1YJvb8IPYe8F+OzPdMN5FG7od342J1Hc2uuZb1FCt R1yAZFObth/bOLZPUKl8c9bi2JgeAC+NUCdQRNheqhQlGL/EuVyjA2srS7n0LocT Eh7493XeNKMERSkfrQT6CdQxgsSsTMDscSRD6WEDiZ3WhyFKzQZ3r1ItCtUIIn0h 5LQBdFN4lzB3H1lcYXXMH0ZDfxHKWDOyU/zwIAsr1j6hoJoYDh5xnwAznPCqMS7s pngfT0y2ozJg8DQYHHXHjPlJuNwtj8plV97ABq7+WZm+CyzS3jgKOsktTU8CiNKV WNQxKbyGZuM57kpelgnKwU4crqtd3GAMosWiVvlIxDNmKgoj8B8ngm1UGie9NCef G2sKfKv4MGxqQVRr2PWs/O+0vWhJE7byRKarvWFCINr/vRsckRU= =3BwC -----END PGP SIGNATURE----- --Apple-Mail=_3B953EA6-C66E-4615-ACCE-815D34D157C4-- From nobody Wed Jun 12 23:34:57 2019 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 D2332120088 for ; Wed, 12 Jun 2019 23:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju_pVKO0kny9 for ; Wed, 12 Jun 2019 23:34:54 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.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 5419712007C for ; Wed, 12 Jun 2019 23:34:54 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp05.mail2web.com) by mx120.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hbJK0-000cbZ-Ih for quic@ietf.org; Thu, 13 Jun 2019 08:34:53 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp05.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hbJJb-0008Ba-OO for quic@ietf.org; Thu, 13 Jun 2019 02:34:28 -0400 Received: (qmail 27377 invoked from network); 13 Jun 2019 06:34:23 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Jun 2019 06:34:23 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16F203) In-Reply-To: <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> Date: Wed, 12 Jun 2019 23:34:21 -0700 Cc: Martin Thomson , quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> To: Lars Eggert Subject: Re: Consensus Call: More Connection ID Space #2736 X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Q9DGisTdy29Heef28Cu3sipSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fvL0unCeMrtrwvMdTV4j6ns/sevPPdLVvjz7b14RFNIS87+5mCGQbZOG2a6 XRF1Gc3uVQDNjY9dXg2x7devZyZITpgWJlsU4G2/4kZd/AHuzsdm/7IKyshZDKoLEEdzFciN9bEz YXQ5Bq54+8sOLcJpXof3r8kfRxpez5OlfYJRQkKHj8GhSvnXG6aqAO+QA5zAmfg+QMjm0Wxe7G4F AAR6avERpop5LF7RavHozgbn9YqgREAoh06jutiTfFzl2G4uss8347yATkLSIXqnQVGKSPZLLSx3 /6BTpL6UXmT8yFSCJlnatpQUVkDyz9+HEa34l0QmPyjhxxYY4z85MF0ZIK/1NH5THMtlYvyHAYGO GlmJIjyKo/pbSDRNIEOEwlMcz873cIRxyN1uC++vIKvC6BczixKau3SVCHUjX//Ej2vCd2jEKogU GzDUyvH10yYy9Qh0ig3cSSPZtZ+CipSnueJOzkx7+I4RvvSaKafqbayp/agYZfrnDk8+IFUpab7m 9Ql4Ld7qe/xoNQPgy7UpxcIWHOi9y3yF+Ot2t6dhJc2bXYMFScrLivfWmWkJo22CHZOREywSBAd6 WuRFS3mxS9budSaTUsNjQfp5O0vXFp1Dqv6fSzLAwHtE/2FlqIE8CVsONrMJuGzuoGnKTKcymM5H 5NK8ObCxL+Ab3gHeBGp1PWox/HcVwRsYfOuMC9EDvRTWmuYW5XPvbs91Tlwpf5AUf1kCAsFmubjw BGSJFQZlJF8UKGQcpLF8m4y5fNSIlEy3YgJZkOfaaqfw0pD+E4vXmYOrZ6ynPfzK8qbeqosYcSFD ZkSOre2YUe/WyPr4xM5tUrEfL92iWzfzWX2vJeNfaj+DKN82dVVpaMxSGA== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 06:34:56 -0000 > On Jun 12, 2019, at 10:40 PM, Lars Eggert wrote: >=20 > Personally, I'm somewhat disappointed about how much we feel we need to ca= ter to the needs/desires of the current state-of-the-art in large-scale load= balancers. 18 bytes was IMO already quite a lot, and 256 bytes seems comple= tely over the top. I really wonder if this will all be pointless with next-g= en LB designs. +1 My gut feeling is that if we adopted a 16 bytes limit, load balancers would j= ust deal with it. Maybe pick symmetric encryption algorithms with shorter bl= ocks, or some kind a hierarchical scheme. But I have a hard time reconciling the emotion around shorter encoding of ac= k delays and the willingness to add 32 bytes of overhead in the packet heade= rs. -- Christian Huitema=20= From nobody Wed Jun 12 23:57:21 2019 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 B80A0120235 for ; Wed, 12 Jun 2019 23:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA0YGCpmoo53 for ; Wed, 12 Jun 2019 23:57:18 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 3D4FD12007C for ; Wed, 12 Jun 2019 23:57:18 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id j29so14156578lfk.10 for ; Wed, 12 Jun 2019 23:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jaUnOp91hWaeMZMcier3dqCaBGZWIERxaOYG6MvBZf8=; b=jKfdhNvpVA0ywLjgxPeemGJbE7Lwqeg5iXBEyNUwv/SEugl2tc0mFt/VpoP7tgxa4E RSENGDkzVVkltcEKSMvsLuMoWncRQNVvpdApPG6LUCItXit6CKO/j2OqLaQcB9lf7vUp Agrl/35W8WVDABoQ8AbU0hEu2+Lt5zaGKqZRdSgtPXRDuvFeJvgG03NK7w83ydSnWNNh LQAwVMA5BoR9n57OYDZDyXGsOsO3SRVidld13dWwsHoL/BXr9IYSYnz+U74h0Py6/mBX FSPTQUnYdQkw/EGlwG4KG8u+RQ3/zEGWvXuW8nZeYUU/tHUZO6aJi1F9zAdAq+reB5by r5NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jaUnOp91hWaeMZMcier3dqCaBGZWIERxaOYG6MvBZf8=; b=ImtgkSeEBMOmv539YKhXW6nU+kXlNDLhEuzlQnB0tpVH3GnF04EBzKiKoJI8ZFPuAJ L/ZoHUopUC89HLFoJEZnKUHHzKUCtup4w/JOjuABSpOJYN8aYoXt5ruOC8PG/OawWFwd Thm58kWEcbQQ5ne/PmzWt/gpXO4kCL/aYBKjxUp+losgPRa+Grr0lAse7ukgur7198GW mqLpI/H7jD4l1PFTWtckHiMLtFBltXyalt5zxiKssyEWiEJQJ8xhtY3/qNloCXdx4Yt4 nvsuH6yJ6munOFJ+EPUW4V+02DZ3y22cDTyq80sYfsUsGUv0w/JRZo+rM3VDCjwQGmMn J+Rg== X-Gm-Message-State: APjAAAWAdBHu8yQSZUypFK88dNzKoowjailBjy9DYH+RElsFhh15D28u xwMjS9tSbTY2yJ16boBtJqzrlAIQ1FCr5vDCtZfHUfxf X-Google-Smtp-Source: APXvYqw6V1orCHanNJpUKQaWnSCWum2+8sAyd0q1m86d2mH9lkraKH/8n0FJIqapSpIBLU99bWQPYdcx6Hnshz8mMIk= X-Received: by 2002:ac2:4ac5:: with SMTP id m5mr19994365lfp.95.1560409036250; Wed, 12 Jun 2019 23:57:16 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> In-Reply-To: <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> From: Marten Seemann Date: Thu, 13 Jun 2019 14:57:05 +0800 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Christian Huitema Cc: Lars Eggert , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000004f62ba058b2f0ab0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 06:57:21 -0000 --0000000000004f62ba058b2f0ab0 Content-Type: text/plain; charset="UTF-8" I'm not really happy with the new proposal. 18 bytes is a lot of overhead already, and having a connection ID of 48 bytes will be an even larger overhead for QUIC packets (around 4% assuming a packet size of 1250 bytes). Besides the obvious inefficiency, which is only born by the implementations that actually decide to make use of these long connection IDs (or rather, by their peers), there are two other downsides to this proposal, which affect all QUIC implementations: 1. Since only 48 out of the 256 length values are permitted in QUIC v1, and we don't have any greasing scheme, these bits are likely to ossify pretty quickly. 2. As pointed out in #2770, this change makes stateless resets a lot less useful than they used to be, and the best mitigation seems to be to require large amounts of padding for small QUIC packets. On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema wrote: > > > On Jun 12, 2019, at 10:40 PM, Lars Eggert wrote: > > > > Personally, I'm somewhat disappointed about how much we feel we need to > cater to the needs/desires of the current state-of-the-art in large-scale > load balancers. 18 bytes was IMO already quite a lot, and 256 bytes seems > completely over the top. I really wonder if this will all be pointless with > next-gen LB designs. > > +1 > > My gut feeling is that if we adopted a 16 bytes limit, load balancers > would just deal with it. Maybe pick symmetric encryption algorithms with > shorter blocks, or some kind a hierarchical scheme. > > But I have a hard time reconciling the emotion around shorter encoding of > ack delays and the willingness to add 32 bytes of overhead in the packet > headers. > > -- Christian Huitema > --0000000000004f62ba058b2f0ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not really happy with the new proposal. 18 bytes i= s a lot of overhead already, and having a connection ID of 48 bytes will be= an even larger overhead for QUIC packets (around 4% assuming a packet size= of 1250 bytes).=C2=A0

Besides the obvious inefficiency, which= is only born by the implementations that actually decide to make use of th= ese long connection IDs (or rather, by their peers), there are two other do= wnsides to this proposal, which affect all QUIC implementations:
= 1. Since only 48 out of the 256 length values are permitted in QUIC v1, and= we don't have any greasing scheme, these bits are likely to ossify pre= tty quickly.
2. As pointed out in #2770, this change makes statel= ess resets a lot less useful than they used to be, and the best mitigation = seems to be to require large amounts of padding for small QUIC packets.

On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema <huitema@huitema.net> wro= te:

> On Jun 12, 2019, at 10:40 PM, Lars Eggert <lars@eggert.org> wrote:
>
> Personally, I'm somewhat disappointed about how much we feel we ne= ed to cater to the needs/desires of the current state-of-the-art in large-s= cale load balancers. 18 bytes was IMO already quite a lot, and 256 bytes se= ems completely over the top. I really wonder if this will all be pointless = with next-gen LB designs.

+1

My gut feeling is that if we adopted a 16 bytes limit, load balancers would= just deal with it. Maybe pick symmetric encryption algorithms with shorter= blocks, or some kind a hierarchical scheme.

But I have a hard time reconciling the emotion around shorter encoding of a= ck delays and the willingness to add 32 bytes of overhead in the packet hea= ders.

-- Christian Huitema
--0000000000004f62ba058b2f0ab0-- From nobody Thu Jun 13 05:14:14 2019 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 777E4120324 for ; Thu, 13 Jun 2019 05:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 5C-_aZ_lGnj8 for ; Thu, 13 Jun 2019 05:14:06 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35F8A1202CF for ; Thu, 13 Jun 2019 05:14:05 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:f8d9:4846:b4e:69a8]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4DE781B000FD; Thu, 13 Jun 2019 13:14:01 +0100 (BST) Subject: Re: Consensus Calls on Recent Transport/TLS Issues: Issue 2580 To: Mark Nottingham , QUIC IETF mailing list Cc: Lars Eggert References: From: Gorry Fairhurst Message-ID: <4b79eb5b-3396-1f44-fba0-dae87025f528@erg.abdn.ac.uk> Date: Thu, 13 Jun 2019 13:14:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 12:14:12 -0000 On 28/05/2019 06:33, Mark Nottingham wrote: > The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!). > > > * #2580 - Is path validation a SHOULD or a MUST? (PR#2637) > * Could someone explain why the new change is safe relative to RFC6298? I think the proposed text was: ... 1 second initial handshake timeout as recommended in  {{?RFC6298}}.  A connection MAY use the delay between sending a PATH_CHALLENGE and receiving  a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT  be considered an RTT sample." ... Maybe I am wrong, but I interpret RFC6298 as saying the seed value should be 1.5 x larger than this RTT value? (To account for RTT variance.) Gorry From nobody Thu Jun 13 10:01:25 2019 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 432F912011B for ; Thu, 13 Jun 2019 10:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA9L4yDYAp1F for ; Thu, 13 Jun 2019 10:01:21 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 6091512011C for ; Thu, 13 Jun 2019 10:01:21 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id y13so15641332lfh.9 for ; Thu, 13 Jun 2019 10:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cyvjB9nlX9SbDqAmCGNlkUAGXeBcInX1A32bzidr/lE=; b=fFbpW1ed0pcTJUSAQ2ddVS8awzRvKeQ8CGtDHNDZ+OVzqe/FPMmptaFyADWKtUkSAw kkexJ/wSjWHQYNlWIEF2maoZOif8eLrnIk6k3CwfQHT5YLOFfo2an/Me6TnmFcgabnv9 zz9n86sh5qDVMmiwEdF24yc56PkORe6jACdHkx64S0c84N3A7mVkVPMLPU1fJVv9XcRM 71/CMtVTkX4eAWAvBDE0r62p0QSo9vmzUa1FehIrkl0OGWRJ2brLlIZeERjF95bDQWwS ZvibTSpc0ZKmAyW8fhjnCBzT84xyV8tdjvYX0EELahGl+fqTAGn0HQQJoJML9ztSqS5g 3JEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cyvjB9nlX9SbDqAmCGNlkUAGXeBcInX1A32bzidr/lE=; b=NW0A4W4X1zjXnUXizBZTAhgrXKlXWsdFpzM/TrW4KmbUJCNYzlSVuq0gWLmPjSGHBm jm4N5R54no5llddXhhsn33I/K7dl7GtGN0R4eDNH0PbaWaVwKcb06RfuOXNGXNeQRw3L fX5COiQlLAVsBKRNLxlz8A3AE7bANALzQvtuMiQT3X3JB7vk3uqI7ieuCvFs26xvcZ/s ao+SZDHaTHpsNMLtriKWgohtQb9GgxYOK4YpKnEQHXIrVXGEAW7f6OZdd4mwUZ3XOeB2 oHwn+ytBiKqcvY5F71J1Cw/95Lwv6q5/XUHROoBDrpFmkZcIEnbe7d98QZ1aNzR/DDLW oTWQ== X-Gm-Message-State: APjAAAXuoFTjxWEQKbnRzSAMiekfNM95iguZ44F+PTYDJS4LGrtQUGe1 4I5xIaKiMzlhLAJgCdXk90gl1iyD2EtKtwgHEhU= X-Google-Smtp-Source: APXvYqxe2VY/Z+eaDJ2OvrrB8fOlv6Y1Jh1cVHCYnO7EfWoDJgA0cUUogDaxwqIt2RY8oNeVP/72cYRcYr/RoUSrL8E= X-Received: by 2002:ac2:46ce:: with SMTP id p14mr10631729lfo.148.1560445279501; Thu, 13 Jun 2019 10:01:19 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> In-Reply-To: From: David Schinazi Date: Thu, 13 Jun 2019 10:01:08 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Marten Seemann Cc: Christian Huitema , Lars Eggert , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000938188058b377a92" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 17:01:24 -0000 --000000000000938188058b377a92 Content-Type: text/plain; charset="UTF-8" I'm realizing the PR makes two changes and one might get better consensus than the other. (1) Change the encoding of connection ID lengths in long headers (and invariants) (2) Change the maximum allowed connection ID length in QUICv1 from 18 to 48 I personally believe (1) is important and time-sensitive. The QUIC invariants will be with us for a long time, and it would be unfortunate to be stuck with {0, [3-18]} forever. The only downside is spending one extra byte on long headers and I think that's acceptable. Perhaps we could: - make this PR only change (1) - have the consensus call only discuss (1) - merge (1) if there is consensus - wait for progress on the stateless reset length issue (#2770) - decide together if we want to change the maximum connection ID length in QUICv1 to something higher than 18 How do people feel about this? David On Wed, Jun 12, 2019 at 11:57 PM Marten Seemann wrote: > I'm not really happy with the new proposal. 18 bytes is a lot of overhead > already, and having a connection ID of 48 bytes will be an even larger > overhead for QUIC packets (around 4% assuming a packet size of 1250 bytes). > > Besides the obvious inefficiency, which is only born by the > implementations that actually decide to make use of these long connection > IDs (or rather, by their peers), there are two other downsides to this > proposal, which affect all QUIC implementations: > 1. Since only 48 out of the 256 length values are permitted in QUIC v1, > and we don't have any greasing scheme, these bits are likely to ossify > pretty quickly. > 2. As pointed out in #2770, this change makes stateless resets a lot less > useful than they used to be, and the best mitigation seems to be to require > large amounts of padding for small QUIC packets. > > On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema > wrote: > >> >> > On Jun 12, 2019, at 10:40 PM, Lars Eggert wrote: >> > >> > Personally, I'm somewhat disappointed about how much we feel we need to >> cater to the needs/desires of the current state-of-the-art in large-scale >> load balancers. 18 bytes was IMO already quite a lot, and 256 bytes seems >> completely over the top. I really wonder if this will all be pointless with >> next-gen LB designs. >> >> +1 >> >> My gut feeling is that if we adopted a 16 bytes limit, load balancers >> would just deal with it. Maybe pick symmetric encryption algorithms with >> shorter blocks, or some kind a hierarchical scheme. >> >> But I have a hard time reconciling the emotion around shorter encoding of >> ack delays and the willingness to add 32 bytes of overhead in the packet >> headers. >> >> -- Christian Huitema >> > --000000000000938188058b377a92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm realizing the PR makes two changes and one might g= et better consensus than the other.
(1) Change the encoding of connecti= on ID lengths in long headers (and invariants)
(2) Change the max= imum allowed connection ID length in QUICv1 from 18 to 48

I personally believe (1) is important and time-sensitive. The QUIC = invariants will be with us for a long time, and it would be unfortunate to = be stuck with {0, [3-18]} forever. The only downside is spending one extra = byte on long headers and I think that's acceptable.

Perhaps we could:
- make this PR only change (1)
= - have the consensus call only discuss (1)
- merge (1) if there i= s consensus

How do people feel about this?


On Wed, Jun 12, 2019 at 11:57 PM Marten Seemann <martenseemann@gmail.com> wrote:
I'= ;m not really happy with the new proposal. 18 bytes is a lot of overhead al= ready, and having a connection ID of 48 bytes will be an even larger overhe= ad for QUIC packets (around 4% assuming a packet size of 1250 bytes).=C2=A0=

Besides the obvious inefficiency, which is only born by the i= mplementations that actually decide to make use of these long connection ID= s (or rather, by their peers), there are two other downsides to this propos= al, which affect all QUIC implementations:
1. Since only 48 out o= f the 256 length values are permitted in QUIC v1, and we don't have any= greasing scheme, these bits are likely to ossify pretty quickly.
2. As pointed out in #2770, this change makes stateless resets a lot less = useful than they used to be, and the best mitigation seems to be to require= large amounts of padding for small QUIC packets.

On Thu, Jun 13= , 2019 at 2:35 PM Christian Huitema <huitema@huitema.net> wrote:

> On Jun 12, 2019, at 10:40 PM, Lars Eggert <lars@eggert.org> wrote:
>
> Personally, I'm somewhat disappointed about how much we feel we ne= ed to cater to the needs/desires of the current state-of-the-art in large-s= cale load balancers. 18 bytes was IMO already quite a lot, and 256 bytes se= ems completely over the top. I really wonder if this will all be pointless = with next-gen LB designs.

+1

My gut feeling is that if we adopted a 16 bytes limit, load balancers would= just deal with it. Maybe pick symmetric encryption algorithms with shorter= blocks, or some kind a hierarchical scheme.

But I have a hard time reconciling the emotion around shorter encoding of a= ck delays and the willingness to add 32 bytes of overhead in the packet hea= ders.

-- Christian Huitema
--000000000000938188058b377a92-- From nobody Thu Jun 13 10:11:30 2019 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 4394D12012D for ; Thu, 13 Jun 2019 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 NlpuVOHAeja3 for ; Thu, 13 Jun 2019 10:11:25 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790114.outbound.protection.outlook.com [40.107.79.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D8912011C for ; Thu, 13 Jun 2019 10:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=16RA4Nvi2qsa5arBHy5pxv8LrHGR7g0OwMlLtGokUnc=; b=QT2ShWnPppVi0hUC1H/1ACnO4YWhzHxSGa4pspsPCoazOABl1Vk7rE0HElnCM/i53zxJlgtH1AIn+izBIA0jq1BebvNh2CMgMeY20tsU/EU4PGK4A1SNgPVnq3aBHn+HapjOC5ly3xQwUPsVOkQ4fme5WNWcGMZVHfYNpM/Phdo= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB1685.namprd22.prod.outlook.com (10.165.90.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Thu, 13 Jun 2019 17:11:23 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1987.012; Thu, 13 Jun 2019 17:11:23 +0000 From: Mike Bishop To: David Schinazi , Marten Seemann CC: Lars Eggert , QUIC WG , Christian Huitema , Martin Thomson Subject: RE: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORiEijuWTMk40i6dp3cA94toqaXjl6AgAGE3YCAAA8NgIAABlqAgACoxQCAAAIJQA== Date: Thu, 13 Jun 2019 17:11:23 +0000 Message-ID: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> 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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1065b9e0-2d36-4732-35d4-08d6f0222969 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB1685; x-ms-traffictypediagnostic: CY4PR22MB1685: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(39830400003)(346002)(199004)(189003)(51444003)(486006)(6506007)(53546011)(66066001)(11346002)(102836004)(186003)(26005)(316002)(446003)(71190400001)(71200400001)(76176011)(476003)(86362001)(7736002)(66476007)(64756008)(606006)(110136005)(53936002)(66446008)(561944003)(66556008)(54906003)(2906002)(74482002)(81156014)(81166006)(74316002)(14444005)(256004)(9686003)(68736007)(236005)(54896002)(6306002)(8676002)(4326008)(5660300002)(52536014)(6246003)(33656002)(99286004)(73956011)(66946007)(76116006)(7696005)(229853002)(6436002)(14454004)(55016002)(8936002)(25786009)(6116002)(3846002)(790700001)(508600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB1685; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dN6fDy6TzT1z8CXB9x2KO8Ed4v4AZgPco7TeDBkYtEX48FTUocMeA/W3gxLCIomUXzYpmHKQ8CyJozRYIxVFVFSitCL9YUhBIAua+9ZLlMInKg/dEOfZgMK/qh1Sk2CQwrAL8nLX5B40AreUV18nDZkR5xb1GQKSyovD6VnPvQJ0LkAS/ScM5eTwvouag2rVq3kzo716IOn/fwQYSJwmiOFTev0UIHId7dJYA09tztPax+iFmBHsOd7F8w733d53IlD8WOrVkqwlz4vZnBJU8rWrWLLkkHZo82kB64ULyO+CbXlYOTstg+zHiXrb2Yeh35qNINSVFgHuCJMpsBAymM4rrhLN03dgpRPS1yR2zukjhCcXY1c2R7HZCeo7yYifuMazvUOw65lZH5DrnVWeMzrS+evR01qzL/w5E/KCBVc= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983338EB0337759434B84FCDAEF0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 1065b9e0-2d36-4732-35d4-08d6f0222969 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 17:11:23.3448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB1685 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 17:11:28 -0000 --_000_CY4PR22MB0983338EB0337759434B84FCDAEF0CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZXJl4oCZcyBwcm9iYWJseSBmaXJtZXIgY29uc2Vuc3Vz IGFib3V0IHBlcm1pdHRpbmcgbGFyZ2UgbnVtYmVycyB0aGFuIHRoZXJlIGlzIGFib3V0IHRoZSBz cGVjaWZpYyBudW1iZXIgdG8gY2hvb3NlIGluIHYxLiAgSG93ZXZlciwgdGhlIHBvaW50IG9mIHRo ZSBjaGFuZ2UgaXMgdG8gbWFrZSBpdCBsYXJnZXIgdGhhbiAxOCwgc28gbGVhdmluZyBpdCBhdCAx OCBzZWVtcyBzb21ld2hhdCBjb3VudGVyLWludHVpdGl2ZS4gIEFsc28sIEkgZG9u4oCZdCB0aGlu ayAjMjc3MCBpcyBnb2luZyB0byByZWFsaXN0aWNhbGx5IGNoYW5nZSB0aGUgbWF4IENJRCBsZW5n dGggd2Ugc2VsZWN0IOKAkyBpdOKAmXMgZ29pbmcgdG8gY2hhbmdlIG91ciBndWlkYW5jZSBhYm91 dCB3aGF0IHRvIGRvIGlmIHlvdeKAmXJlIHVzaW5nIGEgbG9uZyBDSUQuDQoNCklmIHRoZXJl4oCZ cyBkaXNhZ3JlZW1lbnQgYWJvdXQgdGhlIG51bWJlciA0OCwgc3BsaXR0aW5nIHRoaXMgaW50byB0 d28gUFJzIGFuZCBjYWxscyBtaWdodCBiZSBhIHdheSB0byBtYWtlIGZvcndhcmQgcHJvZ3Jlc3Mu ICBJZiB3ZSBoYXZlIGNvbnNlbnN1cyBvbiA0OCwgdGhlbiBsZXTigJlzIGRvIGl0IGFsbCBub3cu DQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhdmlk IFNjaGluYXppDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxMywgMjAxOSAxMDowMSBBTQ0KVG86IE1h cnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbT4NCkNjOiBMYXJzIEVnZ2VydCA8 bGFyc0BlZ2dlcnQub3JnPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IENocmlzdGlhbiBIdWl0 ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjsgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHku bmV0Pg0KU3ViamVjdDogUmU6IENvbnNlbnN1cyBDYWxsOiBNb3JlIENvbm5lY3Rpb24gSUQgU3Bh Y2UgIzI3MzYNCg0KSSdtIHJlYWxpemluZyB0aGUgUFIgbWFrZXMgdHdvIGNoYW5nZXMgYW5kIG9u ZSBtaWdodCBnZXQgYmV0dGVyIGNvbnNlbnN1cyB0aGFuIHRoZSBvdGhlci4NCigxKSBDaGFuZ2Ug dGhlIGVuY29kaW5nIG9mIGNvbm5lY3Rpb24gSUQgbGVuZ3RocyBpbiBsb25nIGhlYWRlcnMgKGFu ZCBpbnZhcmlhbnRzKQ0KKDIpIENoYW5nZSB0aGUgbWF4aW11bSBhbGxvd2VkIGNvbm5lY3Rpb24g SUQgbGVuZ3RoIGluIFFVSUN2MSBmcm9tIDE4IHRvIDQ4DQoNCkkgcGVyc29uYWxseSBiZWxpZXZl ICgxKSBpcyBpbXBvcnRhbnQgYW5kIHRpbWUtc2Vuc2l0aXZlLiBUaGUgUVVJQyBpbnZhcmlhbnRz IHdpbGwgYmUgd2l0aCB1cyBmb3IgYSBsb25nIHRpbWUsIGFuZCBpdCB3b3VsZCBiZSB1bmZvcnR1 bmF0ZSB0byBiZSBzdHVjayB3aXRoIHswLCBbMy0xOF19IGZvcmV2ZXIuIFRoZSBvbmx5IGRvd25z aWRlIGlzIHNwZW5kaW5nIG9uZSBleHRyYSBieXRlIG9uIGxvbmcgaGVhZGVycyBhbmQgSSB0aGlu ayB0aGF0J3MgYWNjZXB0YWJsZS4NCg0KUGVyaGFwcyB3ZSBjb3VsZDoNCi0gbWFrZSB0aGlzIFBS IG9ubHkgY2hhbmdlICgxKQ0KLSBoYXZlIHRoZSBjb25zZW5zdXMgY2FsbCBvbmx5IGRpc2N1c3Mg KDEpDQotIG1lcmdlICgxKSBpZiB0aGVyZSBpcyBjb25zZW5zdXMNCi0gd2FpdCBmb3IgcHJvZ3Jl c3Mgb24gdGhlIHN0YXRlbGVzcyByZXNldCBsZW5ndGggaXNzdWUgKCMyNzcwKTxodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8yNzcwPg0KLSBkZWNpZGUgdG9nZXRo ZXIgaWYgd2Ugd2FudCB0byBjaGFuZ2UgdGhlIG1heGltdW0gY29ubmVjdGlvbiBJRCBsZW5ndGgg aW4gUVVJQ3YxIHRvIHNvbWV0aGluZyBoaWdoZXIgdGhhbiAxOA0KDQpIb3cgZG8gcGVvcGxlIGZl ZWwgYWJvdXQgdGhpcz8NCg0KRGF2aWQNCg0KDQpPbiBXZWQsIEp1biAxMiwgMjAxOSBhdCAxMTo1 NyBQTSBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2VlbWFubkBnbWFpbC5jb208bWFpbHRvOm1hcnRl bnNlZW1hbm5AZ21haWwuY29tPj4gd3JvdGU6DQpJJ20gbm90IHJlYWxseSBoYXBweSB3aXRoIHRo ZSBuZXcgcHJvcG9zYWwuIDE4IGJ5dGVzIGlzIGEgbG90IG9mIG92ZXJoZWFkIGFscmVhZHksIGFu ZCBoYXZpbmcgYSBjb25uZWN0aW9uIElEIG9mIDQ4IGJ5dGVzIHdpbGwgYmUgYW4gZXZlbiBsYXJn ZXIgb3ZlcmhlYWQgZm9yIFFVSUMgcGFja2V0cyAoYXJvdW5kIDQlIGFzc3VtaW5nIGEgcGFja2V0 IHNpemUgb2YgMTI1MCBieXRlcykuDQoNCkJlc2lkZXMgdGhlIG9idmlvdXMgaW5lZmZpY2llbmN5 LCB3aGljaCBpcyBvbmx5IGJvcm4gYnkgdGhlIGltcGxlbWVudGF0aW9ucyB0aGF0IGFjdHVhbGx5 IGRlY2lkZSB0byBtYWtlIHVzZSBvZiB0aGVzZSBsb25nIGNvbm5lY3Rpb24gSURzIChvciByYXRo ZXIsIGJ5IHRoZWlyIHBlZXJzKSwgdGhlcmUgYXJlIHR3byBvdGhlciBkb3duc2lkZXMgdG8gdGhp cyBwcm9wb3NhbCwgd2hpY2ggYWZmZWN0IGFsbCBRVUlDIGltcGxlbWVudGF0aW9uczoNCjEuIFNp bmNlIG9ubHkgNDggb3V0IG9mIHRoZSAyNTYgbGVuZ3RoIHZhbHVlcyBhcmUgcGVybWl0dGVkIGlu IFFVSUMgdjEsIGFuZCB3ZSBkb24ndCBoYXZlIGFueSBncmVhc2luZyBzY2hlbWUsIHRoZXNlIGJp dHMgYXJlIGxpa2VseSB0byBvc3NpZnkgcHJldHR5IHF1aWNrbHkuDQoyLiBBcyBwb2ludGVkIG91 dCBpbiAjMjc3MCwgdGhpcyBjaGFuZ2UgbWFrZXMgc3RhdGVsZXNzIHJlc2V0cyBhIGxvdCBsZXNz IHVzZWZ1bCB0aGFuIHRoZXkgdXNlZCB0byBiZSwgYW5kIHRoZSBiZXN0IG1pdGlnYXRpb24gc2Vl bXMgdG8gYmUgdG8gcmVxdWlyZSBsYXJnZSBhbW91bnRzIG9mIHBhZGRpbmcgZm9yIHNtYWxsIFFV SUMgcGFja2V0cy4NCg0KT24gVGh1LCBKdW4gMTMsIDIwMTkgYXQgMjozNSBQTSBDaHJpc3RpYW4g SHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+ IHdyb3RlOg0KDQo+IE9uIEp1biAxMiwgMjAxOSwgYXQgMTA6NDAgUE0sIExhcnMgRWdnZXJ0IDxs YXJzQGVnZ2VydC5vcmc8bWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZz4+IHdyb3RlOg0KPg0KPiBQZXJz b25hbGx5LCBJJ20gc29tZXdoYXQgZGlzYXBwb2ludGVkIGFib3V0IGhvdyBtdWNoIHdlIGZlZWwg d2UgbmVlZCB0byBjYXRlciB0byB0aGUgbmVlZHMvZGVzaXJlcyBvZiB0aGUgY3VycmVudCBzdGF0 ZS1vZi10aGUtYXJ0IGluIGxhcmdlLXNjYWxlIGxvYWQgYmFsYW5jZXJzLiAxOCBieXRlcyB3YXMg SU1PIGFscmVhZHkgcXVpdGUgYSBsb3QsIGFuZCAyNTYgYnl0ZXMgc2VlbXMgY29tcGxldGVseSBv dmVyIHRoZSB0b3AuIEkgcmVhbGx5IHdvbmRlciBpZiB0aGlzIHdpbGwgYWxsIGJlIHBvaW50bGVz cyB3aXRoIG5leHQtZ2VuIExCIGRlc2lnbnMuDQoNCisxDQoNCk15IGd1dCBmZWVsaW5nIGlzIHRo YXQgaWYgd2UgYWRvcHRlZCBhIDE2IGJ5dGVzIGxpbWl0LCBsb2FkIGJhbGFuY2VycyB3b3VsZCBq dXN0IGRlYWwgd2l0aCBpdC4gTWF5YmUgcGljayBzeW1tZXRyaWMgZW5jcnlwdGlvbiBhbGdvcml0 aG1zIHdpdGggc2hvcnRlciBibG9ja3MsIG9yIHNvbWUga2luZCBhIGhpZXJhcmNoaWNhbCBzY2hl bWUuDQoNCkJ1dCBJIGhhdmUgYSBoYXJkIHRpbWUgcmVjb25jaWxpbmcgdGhlIGVtb3Rpb24gYXJv dW5kIHNob3J0ZXIgZW5jb2Rpbmcgb2YgYWNrIGRlbGF5cyBhbmQgdGhlIHdpbGxpbmduZXNzIHRv IGFkZCAzMiBieXRlcyBvZiBvdmVyaGVhZCBpbiB0aGUgcGFja2V0IGhlYWRlcnMuDQoNCi0tIENo cmlzdGlhbiBIdWl0ZW1hDQo= --_000_CY4PR22MB0983338EB0337759434B84FCDAEF0CY4PR22MB0983namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFncmVlIHdpdGggeW91IHRoYXQgdGhlcmXigJlzIHByb2JhYmx5IGZpcm1lciBjb25zZW5zdXMg YWJvdXQgcGVybWl0dGluZyBsYXJnZSBudW1iZXJzIHRoYW4gdGhlcmUgaXMgYWJvdXQgdGhlIHNw ZWNpZmljIG51bWJlciB0byBjaG9vc2UgaW4gdjEuJm5ic3A7IEhvd2V2ZXIsIHRoZSBwb2ludCBv ZiB0aGUgY2hhbmdlIGlzIHRvIG1ha2UgaXQgbGFyZ2VyIHRoYW4gMTgsIHNvIGxlYXZpbmcgaXQg YXQgMTggc2VlbXMgc29tZXdoYXQNCiBjb3VudGVyLWludHVpdGl2ZS4mbmJzcDsgQWxzbywgSSBk b27igJl0IHRoaW5rICMyNzcwIGlzIGdvaW5nIHRvIHJlYWxpc3RpY2FsbHkgY2hhbmdlIHRoZSBt YXggQ0lEIGxlbmd0aCB3ZSBzZWxlY3Qg4oCTIGl04oCZcyBnb2luZyB0byBjaGFuZ2Ugb3VyIGd1 aWRhbmNlIGFib3V0IHdoYXQgdG8gZG8gaWYgeW914oCZcmUgdXNpbmcgYSBsb25nIENJRC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmXigJlzIGRpc2FncmVlbWVudCBhYm91dCB0aGUg bnVtYmVyIDQ4LCBzcGxpdHRpbmcgdGhpcyBpbnRvIHR3byBQUnMgYW5kIGNhbGxzIG1pZ2h0IGJl IGEgd2F5IHRvIG1ha2UgZm9yd2FyZCBwcm9ncmVzcy4mbmJzcDsgSWYgd2UgaGF2ZSBjb25zZW5z dXMgb24gNDgsIHRoZW4gbGV04oCZcyBkbyBpdCBhbGwgbm93LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5P biBCZWhhbGYgT2YgPC9iPg0KRGF2aWQgU2NoaW5hemk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEp1bmUgMTMsIDIwMTkgMTA6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRlbiBTZWVtYW5u ICZsdDttYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IExhcnMgRWdn ZXJ0ICZsdDtsYXJzQGVnZ2VydC5vcmcmZ3Q7OyBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0 OzsgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7OyBNYXJ0aW4g VGhvbXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBDb25zZW5zdXMgQ2FsbDogTW9yZSBDb25uZWN0aW9uIElEIFNwYWNlICMyNzM2PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gcmVhbGl6aW5nIHRoZSBQUiBtYWtlcyB0d28gY2hh bmdlcyBhbmQgb25lIG1pZ2h0IGdldCBiZXR0ZXIgY29uc2Vuc3VzIHRoYW4gdGhlIG90aGVyLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigxKSBDaGFuZ2UgdGhl IGVuY29kaW5nIG9mIGNvbm5lY3Rpb24gSUQgbGVuZ3RocyBpbiBsb25nIGhlYWRlcnMgKGFuZCBp bnZhcmlhbnRzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KDIpIENoYW5nZSB0aGUgbWF4aW11bSBhbGxvd2VkIGNvbm5lY3Rpb24gSUQgbGVuZ3Ro IGluIFFVSUN2MSBmcm9tIDE4IHRvIDQ4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxseSBiZWxpZXZlICgxKSBpcyBpbXBvcnRh bnQgYW5kIHRpbWUtc2Vuc2l0aXZlLiBUaGUgUVVJQyBpbnZhcmlhbnRzIHdpbGwgYmUgd2l0aCB1 cyBmb3IgYSBsb25nIHRpbWUsIGFuZCBpdCB3b3VsZCBiZSB1bmZvcnR1bmF0ZSB0byBiZSBzdHVj ayB3aXRoIHswLCBbMy0xOF19IGZvcmV2ZXIuIFRoZSBvbmx5IGRvd25zaWRlIGlzIHNwZW5kaW5n IG9uZSBleHRyYSBieXRlIG9uIGxvbmcgaGVhZGVycw0KIGFuZCBJIHRoaW5rIHRoYXQncyBhY2Nl cHRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5QZXJoYXBzIHdlIGNvdWxkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LSBtYWtlIHRoaXMgUFIgb25seSBjaGFuZ2UgKDEpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGhhdmUgdGhlIGNv bnNlbnN1cyBjYWxsIG9ubHkgZGlzY3VzcyAoMSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gbWVyZ2UgKDEpIGlmIHRoZXJlIGlzIGNvbnNlbnN1 czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSB3 YWl0IGZvciBwcm9ncmVzcyBvbiB0aGUgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3 Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjc3MCI+DQpzdGF0ZWxlc3MgcmVzZXQgbGVuZ3RoIGlzc3Vl ICgjMjc3MCk8L2E+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tIGRlY2lkZSB0b2dldGhlciBpZiB3ZSB3YW50IHRvIGNoYW5nZSB0aGUg bWF4aW11bSBjb25uZWN0aW9uIElEIGxlbmd0aCBpbiBRVUlDdjEgdG8gc29tZXRoaW5nIGhpZ2hl ciB0aGFuIDE4PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhvdyBkbyBwZW9wbGUgZmVlbCBhYm91dCB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVuIDEyLCAy MDE5IGF0IDExOjU3IFBNIE1hcnRlbiBTZWVtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGVu c2VlbWFubkBnbWFpbC5jb20iPm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSdtIG5vdCByZWFsbHkgaGFwcHkgd2l0aCB0aGUgbmV3IHByb3Bvc2FsLiAxOCBi eXRlcyBpcyBhIGxvdCBvZiBvdmVyaGVhZCBhbHJlYWR5LCBhbmQgaGF2aW5nIGEgY29ubmVjdGlv biBJRCBvZiA0OCBieXRlcyB3aWxsIGJlIGFuIGV2ZW4gbGFyZ2VyIG92ZXJoZWFkIGZvciBRVUlD IHBhY2tldHMgKGFyb3VuZCA0JSBhc3N1bWluZyBhIHBhY2tldCBzaXplIG9mIDEyNTAgYnl0ZXMp LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc2lkZXMgdGhl IG9idmlvdXMgaW5lZmZpY2llbmN5LCB3aGljaCBpcyBvbmx5IGJvcm4gYnkgdGhlIGltcGxlbWVu dGF0aW9ucyB0aGF0IGFjdHVhbGx5IGRlY2lkZSB0byBtYWtlIHVzZSBvZiB0aGVzZSBsb25nIGNv bm5lY3Rpb24gSURzIChvciByYXRoZXIsIGJ5IHRoZWlyIHBlZXJzKSwgdGhlcmUgYXJlIHR3byBv dGhlciBkb3duc2lkZXMgdG8gdGhpcyBwcm9wb3NhbCwgd2hpY2ggYWZmZWN0IGFsbCBRVUlDDQog aW1wbGVtZW50YXRpb25zOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MS4gU2luY2Ugb25seSA0OCBvdXQgb2YgdGhlIDI1NiBsZW5ndGggdmFsdWVz IGFyZSBwZXJtaXR0ZWQgaW4gUVVJQyB2MSwgYW5kIHdlIGRvbid0IGhhdmUgYW55IGdyZWFzaW5n IHNjaGVtZSwgdGhlc2UgYml0cyBhcmUgbGlrZWx5IHRvIG9zc2lmeSBwcmV0dHkgcXVpY2tseS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIEFz IHBvaW50ZWQgb3V0IGluICMyNzcwLCB0aGlzIGNoYW5nZSBtYWtlcyBzdGF0ZWxlc3MgcmVzZXRz IGEgbG90IGxlc3MgdXNlZnVsIHRoYW4gdGhleSB1c2VkIHRvIGJlLCBhbmQgdGhlIGJlc3QgbWl0 aWdhdGlvbiBzZWVtcyB0byBiZSB0byByZXF1aXJlIGxhcmdlIGFtb3VudHMgb2YgcGFkZGluZyBm b3Igc21hbGwgUVVJQyBwYWNrZXRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDEzLCAyMDE5IGF0IDI6MzUg UE0gQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEu bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KJmd0OyBPbiBKdW4gMTIsIDIwMTksIGF0IDEwOjQwIFBNLCBMYXJzIEVnZ2VydCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxhcnNAZWdn ZXJ0Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBQZXJzb25hbGx5LCBJ J20gc29tZXdoYXQgZGlzYXBwb2ludGVkIGFib3V0IGhvdyBtdWNoIHdlIGZlZWwgd2UgbmVlZCB0 byBjYXRlciB0byB0aGUgbmVlZHMvZGVzaXJlcyBvZiB0aGUgY3VycmVudCBzdGF0ZS1vZi10aGUt YXJ0IGluIGxhcmdlLXNjYWxlIGxvYWQgYmFsYW5jZXJzLiAxOCBieXRlcyB3YXMgSU1PIGFscmVh ZHkgcXVpdGUgYSBsb3QsIGFuZCAyNTYgYnl0ZXMgc2VlbXMgY29tcGxldGVseSBvdmVyIHRoZSB0 b3AuIEkgcmVhbGx5IHdvbmRlcg0KIGlmIHRoaXMgd2lsbCBhbGwgYmUgcG9pbnRsZXNzIHdpdGgg bmV4dC1nZW4gTEIgZGVzaWducy48YnI+DQo8YnI+DQomIzQzOzE8YnI+DQo8YnI+DQpNeSBndXQg ZmVlbGluZyBpcyB0aGF0IGlmIHdlIGFkb3B0ZWQgYSAxNiBieXRlcyBsaW1pdCwgbG9hZCBiYWxh bmNlcnMgd291bGQganVzdCBkZWFsIHdpdGggaXQuIE1heWJlIHBpY2sgc3ltbWV0cmljIGVuY3J5 cHRpb24gYWxnb3JpdGhtcyB3aXRoIHNob3J0ZXIgYmxvY2tzLCBvciBzb21lIGtpbmQgYSBoaWVy YXJjaGljYWwgc2NoZW1lLjxicj4NCjxicj4NCkJ1dCBJIGhhdmUgYSBoYXJkIHRpbWUgcmVjb25j aWxpbmcgdGhlIGVtb3Rpb24gYXJvdW5kIHNob3J0ZXIgZW5jb2Rpbmcgb2YgYWNrIGRlbGF5cyBh bmQgdGhlIHdpbGxpbmduZXNzIHRvIGFkZCAzMiBieXRlcyBvZiBvdmVyaGVhZCBpbiB0aGUgcGFj a2V0IGhlYWRlcnMuPGJyPg0KPGJyPg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWEgPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR22MB0983338EB0337759434B84FCDAEF0CY4PR22MB0983namp_-- From nobody Thu Jun 13 10:30:09 2019 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 088CE12012D for ; Thu, 13 Jun 2019 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=evequefou.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 OQgz4YXYDN2n for ; Thu, 13 Jun 2019 10:30:05 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710117.outbound.protection.outlook.com [40.107.71.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05735120058 for ; Thu, 13 Jun 2019 10:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XS1+Sp8feLQQFyNHtoLnLT5fvy0k0UVZ/8ZbpD5SGUg=; b=JWLYQpKosyujh4PTn1ukaT2G2VKPEgyILUd0dEtKQXhG2EzJ59YGyNzAQRa9njnCOonXDfHNH30noqSHqxOwj1KE7mMfOgCPiA2aGRY3s+RjivKRnrIEhLZ/IJzC8cmbXK8TnbUoccw2avyICNUt/x0OPeso99HA3IGJES9pRRA= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0390.namprd22.prod.outlook.com (10.173.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Thu, 13 Jun 2019 17:30:02 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1987.012; Thu, 13 Jun 2019 17:30:02 +0000 From: Mike Bishop To: QUIC WG CC: HTTP Working Group Subject: Consistency in Stream Beginnings in HTTP/3 Thread-Topic: Consistency in Stream Beginnings in HTTP/3 Thread-Index: AdUiCyWUFMBA6tDjRVeSCgLZOnPdlw== Date: Thu, 13 Jun 2019 17:30:02 +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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8d5a9ac-f861-41bb-e216-08d6f024c45a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0390; x-ms-traffictypediagnostic: CY4PR22MB0390: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(376002)(366004)(39830400003)(199004)(189003)(2906002)(256004)(14444005)(6916009)(68736007)(81166006)(8676002)(66946007)(316002)(3846002)(6116002)(790700001)(81156014)(86362001)(476003)(9686003)(486006)(6306002)(25786009)(55016002)(54896002)(66066001)(52536014)(99286004)(102836004)(5660300002)(33656002)(71200400001)(6506007)(7696005)(71190400001)(6436002)(53936002)(73956011)(66476007)(64756008)(4326008)(186003)(26005)(508600001)(76116006)(14454004)(66446008)(8936002)(66556008)(7736002)(74316002)(74482002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0390; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QH8JzkE+ajuwa4E4XXpvSbC/KuyfQ/ZxTSJWzYTV6iBMou5uUaS6bSkwUnVFZ2KNaXN35AK2CEm+mBI8bx0XcedFPZXsY7PHIiRMI4OjWa1mQ9ToYSPhVyF2d8a8pFr+Z9Ub0ZC698LPaQEoLCFtFrTdEb6hkTxcQkuXkdwvLvSbvBdl2trihGOf+UXx0LLb9z2QvaZaenIe2fZtaEJXRh4rlK2OE9MuBeZq4Ji1YwEwfn2mf3RtufnRwpPya/mHaxBUehK0rVbC2nPDpRi8h+g5BSOMiRLH6kwuDTto0PluxbDJtb1IqK16rEolSvpIyQZ4Lz6x/Ju2eEN1VIlfZxECXr+HM9urv2uogWe+sLUMP+XGcnC45oCa7BRtkDXiljg4hJNrvHBjYnCIOc/YfWrCslKSfWmHSDY3gAHbVr0= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098350E9ED73C6B2B282E934DAEF0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: a8d5a9ac-f861-41bb-e216-08d6f024c45a X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 17:30:02.2092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0390 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 17:30:07 -0000 --_000_CY4PR22MB098350E9ED73C6B2B282E934DAEF0CY4PR22MB0983namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This discussion has happened across a collection of GitHub issues with larg= ely the same participants, and I'd like to get a sense of the larger workin= g group's opinion before I work on any of these directions (or close all th= e related issues). To recap the current state: * Unidirectional streams begin with a type byte; interpretation of the = remainder of the stream data depends on the type * Push streams continue with a header - the Push ID as a varint - follo= wed by frames as usual * Control streams don't have a header; frames begin immediately after t= he type byte. However, a SETTINGS frame is required to be the first frame = of the stream. * SETTINGS cannot be sent again thereafter or on any other stream That means there are currently two different models of how you put required= -to-be-first information: As a required-initial frame or as a header befor= e framing begins. There are a couple of paths forward that have been discussed: * Stay as-is. SETTINGS is a frame in HTTP/2, so we're keeping it that = way for consistency. We've previously decided not to permit changes to set= tings to avoid the question of synchronization. The reasons to change are = not urgent. * Make the Push ID a required-initial frame. Proposed in #2526; reject= ed in London. * Make SETTINGS a stream header. Proposed in #2783. * Argument for: Gets rid of the concept of required-initial frames,= in combination with #2781. Consistent with the Push Stream header. * Argument against: Push ID isn't a length-prefixed structure, just= a single varint. We already have facilities for reading length-prefixed s= tructures in frame handling. * Allow multiple SETTINGS. The synchronization requirement on SETTINGS= is hairy when values are reduced, because in-flight activity might now vio= late a peer's restriction. Allowing SETTINGS to be sent at any time, but o= nly increase values, would also mean they need not be the first frame, elim= inating the concept of required-initial frames. * Complication: What does this mean for clients' remembered setting= s and server's remembered settings as stored in NSTs? If a client updates = stored settings but retains a NST from earlier in the connection, the serve= r and client could have divergent views of the server's settings on a futur= e 0-RTT connection. * Allow omitting SETTINGS. If the server doesn't need to change anythi= ng from the client's initial settings, then the server can just not send a = SETTINGS frame. Once you've sent something else on the control stream, tho= ugh, you can't send one later if you change your mind. Thoughts? --_000_CY4PR22MB098350E9ED73C6B2B282E934DAEF0CY4PR22MB0983namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This discussion has happened across a collection of = GitHub issues with largely the same participants, and I’d like to get= a sense of the larger working group’s opinion before I work on any o= f these directions (or close all the related issues).

 

To recap the current state:

  • Unidirectional streams begin with a type byte; interpretation of the = remainder of the stream data depends on the type
  • Pus= h streams continue with a header – the Push ID as a varint – fo= llowed by frames as usual
  • Control streams don’t = have a header; frames begin immediately after the type byte.  However,= a SETTINGS frame is required to be the first frame of the stream.
  • SETTINGS cannot be sent again thereafter or on any other strea= m

 

That means there are currently two different models = of how you put required-to-be-first information:  As a required-initia= l frame or as a header before framing begins.

 

There are a couple of paths forward that have been d= iscussed:

  • Stay as-is.  SETTINGS is a frame in HTTP/2, so we’r= e keeping it that way for consistency.  We’ve previously decided= not to permit changes to settings to avoid the question of synchronization.  The reasons to change are not urgent.
  • Make the Push ID a required-initial frame.  Proposed in #2526; rejected in London.
  • Make SET= TINGS a stream header.  Proposed in #2783.
    • Argument for:  Gets rid of the concept of required-initia= l frames, in combination with #2781.  Consistent with the Push Stream = header.
    • Argument against:  Push ID isnR= 17;t a length-prefixed structure, just a single varint.  We already ha= ve facilities for reading length-prefixed structures in frame handling.
  • Allow multiple SETTINGS.  The synchronization requirement= on SETTINGS is hairy when values are reduced, because in-flight activity m= ight now violate a peer’s restriction.  Allowing SETTINGS to be sent at any time, but only increase values, would also mean= they need not be the first frame, eliminating the concept of required-init= ial frames.
    • Complication:  What does this mean for clients’ remembered= settings and server’s remembered settings as stored in NSTs?  I= f a client updates stored settings but retains a NST from earlier in the connection, the server and client could have divergent view= s of the server’s settings on a future 0-RTT connection.
  • Allow omitting SETTINGS.  If the server doesn’t nee= d to change anything from the client’s initial settings, then the ser= ver can just not send a SETTINGS frame.  Once you’ve sent something else on the control stream, though, you can’t send on= e later if you change your mind.

 

Thoughts?

--_000_CY4PR22MB098350E9ED73C6B2B282E934DAEF0CY4PR22MB0983namp_-- From nobody Thu Jun 13 10:54:56 2019 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 DC33D1201D1 for ; Thu, 13 Jun 2019 10:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6roLD6vWdVfx for ; Thu, 13 Jun 2019 10:54:52 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 1399F120058 for ; Thu, 13 Jun 2019 10:54:52 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id c70so13316314qkg.7 for ; Thu, 13 Jun 2019 10:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=OswXmSGSqvyBaQXlQ4U/kj5IysUb05v4KUSVdXm8NDQ=; b=jlu8XPz8Gc/U8zGOdWjD+/VeQ4l6sXmB8e+VmWEdpPTTFxCz7AdGH7gP0/hYDQOw5a eWOxYY0YWRFas/xqr0iZAQcJJpl2u3upuNruStK4rIARUsST744kedzun7XgS4ILtwYi RXMmv4zNlC5xrQXAezQNwxvnq6hB8vQoycJEvEFKz9VtpsXqDE7+yUP51S9og7dlCIHq 9SjpYTURj251d9EML6bsDAsnX37+ekYuHyhnaepnjVdW5578tInoDAu1gUO1IsULrf8c 7yhPe97qiI0uQBU0YI6uY0Dop6LpQWstElk4uk1qeF7h/Lo3K42wi9YdTRfcsXFnw2jx IVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=OswXmSGSqvyBaQXlQ4U/kj5IysUb05v4KUSVdXm8NDQ=; b=XPjOktH8ThXpODc//8ttUynL26LfbXD8leFjICuWEFlllTimmcESu4Pwh3pxzgkve+ gruxE0Mt/Me8WY3t1lRUQsJcN9DBE0w2yBLM/5/QCQ9a9yIp7aPOrmJRFn9zgdFOOzOr n/U2SxZWJHx5M2OuVwWp1JsmiY6aVQQ0Vj7h5p8oe+nXkCFwVoIYCkm0ZAGIMUi3E/kL Xa8Otp60O8WosqQI4GeUmyQAwfrxIgN/wvUOfY3ACCQPj/D9a5lRxAk21S3wnbK/8b6f vwHijSlZ1skKqrUCgDkNkQnXWtWfltaXF4Z4LUAJOp9FjoNDbo/wr1Vu9qfmo8EzEqkl NjrA== X-Gm-Message-State: APjAAAWZg0r31AbdkcUNUFZV7JQIVEjHW3lj/m9Q3bXij10/N8ANqxzj AcpCaOPduLaxyQgm8WsE5kXoKGc7WKw= X-Google-Smtp-Source: APXvYqy1sRWJIJfYswXnBuLl/f68Gid8hglvM8+OpSFH2a14fIndL1Ied5SjVjT9JF36OYDj4UGOTQ== X-Received: by 2002:a05:620a:12f8:: with SMTP id f24mr16450933qkl.202.1560448491205; Thu, 13 Jun 2019 10:54:51 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id o54sm190925qtb.63.2019.06.13.10.54.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 10:54:50 -0700 (PDT) Date: Thu, 13 Jun 2019 13:54:44 -0400 From: Dmitri Tikhonov To: Marten Seemann Cc: Christian Huitema , Lars Eggert , QUIC WG , Martin Thomson Subject: Re: Consensus Call: More Connection ID Space #2736 Message-ID: <20190613175443.GA23884@ubuntu-dmitri> Mail-Followup-To: Marten Seemann , Christian Huitema , Lars Eggert , QUIC WG , Martin Thomson References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 17:54:54 -0000 On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: > Besides the obvious inefficiency, which is only born by the > implementations that actually decide to make use of these long > connection IDs (or rather, by their peers), The peer can provide CIDs of any size via NEW_CONNECTION_ID, so unless an implementation throws longs CIDs out, it has to support long CIDs. In addition, a server has no choice but to support maximum-size ODCID. There are trade-offs: 1. Make its cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs. This has large memory overhead but it is simple and has good locality of refence. 2. Make cid_t a variable-size object. This saves memory overall, but is more complicated and likely slower (two memory accesses to get CID). 3. Have two types: peer_cid_t that can be any size and my_cid_t that supports CIDs of fixed length picked by the implementation. This is even more complicated. To summarize, the maximum CID length affects all implementations. - Dmitri. From nobody Thu Jun 13 11:47:40 2019 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 CAD0812011E for ; Thu, 13 Jun 2019 11:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqza5iUfEmMR for ; Thu, 13 Jun 2019 11:47:36 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 D0D21120025 for ; Thu, 13 Jun 2019 11:47:35 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id u124so127515vsu.2 for ; Thu, 13 Jun 2019 11:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JQjJVvrQRnUXi4eoF8G/5Rg+2YOSYFAoIbrXp+9Oczs=; b=pshvlPLLEik9CJb3mzzNjlrSbcTcHbiM4t3c3tRPMsL4QvfUv3gzyO10GtPHdzo+82 1xImrpP2pWbYs5JIqgnlINgH9rBJLe88rBDOTgJvtzYly8q9uj60x/2aR1lQ9b0C3LGd 14LejMfHyWA1r7jwby/vVbe6kpixn+7klm1LjnrNOeGbl9Zb0coc4bbCqESu2s3Dlxv9 kbJSkekPPUbEPuQHoBVvEVzrPzxy36Jak6iQL7eDdD3gFTRwhERdcxx7nA65X34qQ2s0 YeqnAVV2oLFtjYsbIP4xw3xJARtVAOzxuGrDPDwaGYBccVP3EmcZ+ri2wDCWyYk/Ru9n H8aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JQjJVvrQRnUXi4eoF8G/5Rg+2YOSYFAoIbrXp+9Oczs=; b=GQBrcGIReWbgaxYbX67f8BquyjmLpu5tJ9Qz1/x/H4eD1yqr9g2KRANkNUnXIVz8mh Xt+b7zsLntuE2KNFs7braQUbNflHAk1qzsi9q92a6Rb8MHdRmRL54xGym3HaghP8y9Rp Im76dP+AZHEuCZxt0mH/rGOR/qiRijNA1vee6L8Z/Rifaef2Dj2DSWojmO9JXaCBcSFx OnBaQSCV5M20zjx6pULFZcTwCvJjG30avI1yYvLaP3mV4O3017bGHXYTMXlRAzfcVHOO k9cJm29dkm/7UUNgIniTdSjiO4helrgc/XMeQlgsiOkxvg+KYiv5yvgVDMQjBhnYZHo7 FM/g== X-Gm-Message-State: APjAAAUk4I7CjygSt2KOCvZQX3+Z/nLkqMT2jlOCxpCoOnQafXMvnIuv dLWrxjbDU+T44I79cDVfxeeGU9aIHa2ZrAxBSUg= X-Google-Smtp-Source: APXvYqyvcL77/kvkieCyAZRIOI2q8J5iYwWTBAhqHZmwJ3dfD4gPwet08qVkUpXJh4HVUTRRo7TR5J4YCqzW+wRpGi4= X-Received: by 2002:a05:6102:8c:: with SMTP id t12mr10167245vsp.143.1560451654786; Thu, 13 Jun 2019 11:47:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Thu, 13 Jun 2019 19:15:05 +0100 Message-ID: Subject: Re: Consistency in Stream Beginnings in HTTP/3 To: Mike Bishop Cc: QUIC WG , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000092a4b1058b38f6af" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 18:47:38 -0000 --00000000000092a4b1058b38f6af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for summarising all of this individual discussions Mike. I have a derivative design on the SETTINGS stream header which would replace length-prefix with count. So rather than Express total length of parameter ID and value, you tell the receiver how many variant pairs to process before processing frames. I dont think that strongly pushes the needle in one direction though. If we reject changing the control stream, I'm presently 50/50 split between revisiting push stream framing and just living with what we have. On Thu, 13 Jun 2019, 18:30 Mike Bishop, wrote: > This discussion has happened across a collection of GitHub issues with > largely the same participants, and I=E2=80=99d like to get a sense of the= larger > working group=E2=80=99s opinion before I work on any of these directions = (or close > all the related issues). > > > > To recap the current state: > > - Unidirectional streams begin with a type byte; interpretation of the > remainder of the stream data depends on the type > - Push streams continue with a header =E2=80=93 the Push ID as a varin= t =E2=80=93 > followed by frames as usual > - Control streams don=E2=80=99t have a header; frames begin immediatel= y after > the type byte. However, a SETTINGS frame is required to be the first = frame > of the stream. > - SETTINGS cannot be sent again thereafter or on any other stream > > > > That means there are currently two different models of how you put > required-to-be-first information: As a required-initial frame or as a > header before framing begins. > > > > There are a couple of paths forward that have been discussed: > > - *Stay as-is.* SETTINGS is a frame in HTTP/2, so we=E2=80=99re keepi= ng it > that way for consistency. We=E2=80=99ve previously decided not to per= mit changes > to settings to avoid the question of synchronization. The reasons to > change are not urgent. > - *Make the Push ID a required-initial frame. *Proposed in #2526; > rejected in London. > - *Make SETTINGS a stream header.* Proposed in #2783. > - *Argument for:* Gets rid of the concept of required-initial > frames, in combination with #2781. Consistent with the Push Stream= header. > - *Argument against:* Push ID isn=E2=80=99t a length-prefixed stru= cture, > just a single varint. We already have facilities for reading > length-prefixed structures in frame handling. > - *Allow multiple SETTINGS.* The synchronization requirement on > SETTINGS is hairy when values are reduced, because in-flight activity = might > now violate a peer=E2=80=99s restriction. Allowing SETTINGS to be sen= t at any > time, but only increase values, would also mean they need not be the f= irst > frame, eliminating the concept of required-initial frames. > - Complication: What does this mean for clients=E2=80=99 remembere= d > settings and server=E2=80=99s remembered settings as stored in NSTs= ? If a client > updates stored settings but retains a NST from earlier in the conne= ction, > the server and client could have divergent views of the server=E2= =80=99s settings > on a future 0-RTT connection. > - *Allow omitting SETTINGS.* If the server doesn=E2=80=99t need to ch= ange > anything from the client=E2=80=99s initial settings, then the server c= an just not > send a SETTINGS frame. Once you=E2=80=99ve sent something else on the= control > stream, though, you can=E2=80=99t send one later if you change your mi= nd. > > > > Thoughts? > --00000000000092a4b1058b38f6af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for summarising all of this individual discus= sions Mike.=C2=A0

I have a der= ivative design on the SETTINGS stream header which would replace length-pre= fix with count. So rather than Express total length of parameter ID and val= ue, you tell the receiver how many variant pairs to process before processi= ng frames.=C2=A0

I dont = think that strongly pushes the needle in one direction though.

If we reject changing the control st= ream, I'm presently 50/50 split between revisiting push stream framing = and just living with what we have.


=
On Thu, 13 Jun 2019, 18:30 Mike Bisho= p, <mbishop@evequefou.be> wrote:

This discussion has happened across a collection of = GitHub issues with largely the same participants, and I=E2=80=99d like to g= et a sense of the larger working group=E2=80=99s opinion before I work on a= ny of these directions (or close all the related issues).

=C2=A0

To recap the current state:

  • Unidirectional streams begin with a type byte; inte= rpretation of the remainder of the stream data depends on the type
  • Push streams continue with a header =E2= =80=93 the Push ID as a varint =E2=80=93 followed by frames as usual=
  • Control streams don=E2=80=99t have a he= ader; frames begin immediately after the type byte.=C2=A0 However, a SETTIN= GS frame is required to be the first frame of the stream.
  • SETTINGS cannot be sent again thereafter or on any= other stream

=C2=A0

That means there are currently two different models = of how you put required-to-be-first information:=C2=A0 As a required-initia= l frame or as a header before framing begins.

=C2=A0

There are a couple of paths forward that have been d= iscussed:

  • Stay as-is.=C2=A0 SETTINGS is a frame in HTT= P/2, so we=E2=80=99re keeping it that way for consistency.=C2=A0 We=E2=80= =99ve previously decided not to permit changes to settings to avoid the que= stion of synchronization.=C2=A0 The reasons to change are not urgent.=
  • Make the Push ID a required-initial frame.= =C2=A0 Proposed in #2526; rejected in London.
  • Make SETTINGS a stream header.=C2=A0 Proposed in #2783.=
    • Argument for:=C2=A0 Gets rid of the concept = of required-initial frames, in combination with #2781.=C2=A0 Consistent wit= h the Push Stream header.
    • Argu= ment against:=C2=A0 Push ID isn=E2=80=99t a length-prefixed structure, = just a single varint.=C2=A0 We already have facilities for reading length-p= refixed structures in frame handling.
  • Allow multiple SETTINGS.=C2=A0 The synchroni= zation requirement on SETTINGS is hairy when values are reduced, because in= -flight activity might now violate a peer=E2=80=99s restriction.=C2=A0 Allo= wing SETTINGS to be sent at any time, but only increase values, would also mean= they need not be the first frame, eliminating the concept of required-init= ial frames.
    • Complication:=C2=A0 What does this mean for clients= =E2=80=99 remembered settings and server=E2=80=99s remembered settings as s= tored in NSTs?=C2=A0 If a client updates stored settings but retains a NST = from earlier in the connection, the server and client could have divergent view= s of the server=E2=80=99s settings on a future 0-RTT connection.<= /u>
  • Allow omitting SETTINGS.=C2=A0 If the server= doesn=E2=80=99t need to change anything from the client=E2=80=99s initial = settings, then the server can just not send a SETTINGS frame.=C2=A0 Once yo= u=E2=80=99ve sent something else on the control stream, though, you can=E2=80=99t send = one later if you change your mind.

=C2=A0

Thoughts?

--00000000000092a4b1058b38f6af-- From nobody Thu Jun 13 12:15:22 2019 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 F1402120617 for ; Thu, 13 Jun 2019 12:15:19 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEmQYS2UNf-c for ; Thu, 13 Jun 2019 12:15:18 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBE312060A for ; Thu, 13 Jun 2019 12:15:17 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id F2A7E2008F for ; Thu, 13 Jun 2019 22:15:15 +0300 (EEST) Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 430DB61FE1B for ; Thu, 13 Jun 2019 22:15:09 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_1CCD065A-4907-44AB-822F-132DD19CDE30"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: July 10! Re: Doodle poll for Second-Quarter 2019 QUIC Virtual Interop Event Date: Thu, 13 Jun 2019 22:15:08 +0300 References: <1C4C1174-F6D0-4EC8-9E80-C4D2889EADD3@eggert.org> To: QUIC IETF mailing list In-Reply-To: Message-Id: <8E623F6D-DA12-4437-A3AB-D3740A94F034@eggert.org> X-MailScanner-ID: 430DB61FE1B.A3DD3 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 19:15:20 -0000 --Apple-Mail=_1CCD065A-4907-44AB-822F-132DD19CDE30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii July 10 is the date for the next virtual interop! > On 2019-6-11, at 11:51, Lars Eggert wrote: >=20 > Please indicate your availability, if you have a stack you wish to = test: https://doodle.com/poll/6r3dyvzb7m6pg6vk >=20 > (This will be a remote interop. Next physical one will be at the = IETF-105 hackathon in Montreal.) >=20 > Lars --Apple-Mail=_1CCD065A-4907-44AB-822F-132DD19CDE30 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAl0CoLwACgkQHbmKvSnu NPis0xAAi/tDhMVQwoB475bJ5IxZOHPrWpJ3DnNwVCu2RynvPQBgG4sibms2f6VE Ws9rlM6Y6b3qnXxSoJz98JnlGCqVnvB/BlkrLHZIWpOLXFJ7eNAUxYkrJtWn7yQI h8LpL8ofdR34Tl90w7B2UNgOSDTqCyDHHK+3SuWORz1LeRlfTr+2BIpIg6F8c024 M7O/SeTJ0XNO0h0C4O4UgREjAL8rYpctPQ9l0E7E+Oz/f00X4bxiBOhz0jFtDrvU +hJ/j4Lvti5pc4xlndJKc3WRoVeziN72ovCHzSHNCMsZEwOp1dLsQtkXlCTRhWng yu8ssbI+3hwfpbXp7rJj+qEhO9athI68UnGYiIof7zZ8W244OLPKbmFoYh11DKs8 imaZuajozIO8zNxBP89DJgXeD1J8bFNKnMRo2pA22Bi27a1gweMjAL6AEosZuKCQ GK2KjrmB1DIOPp//vTmTIATTRpL6hp0cOjE7wyMgIWZ75b/fnD/t+w9nKGEf3W0q fSpVpdW5pN1Njgx52UY0XQyLM9BV3x2PiFgu5JsUZaBciuOOzfAUoUoOWzVotAYJ BY+iov/CX32ygQJmImualxowYfYdaaOXZgLDH80m4lA8wAVMRGhMPMflK7XxyrH7 NXKvLpq8tiGk7eVeQ7aseZJrgcYaI9o9hbRkK2iWKWv6KjqST9M= =usds -----END PGP SIGNATURE----- --Apple-Mail=_1CCD065A-4907-44AB-822F-132DD19CDE30-- From nobody Thu Jun 13 14:19:46 2019 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 3EA461201EB for ; Thu, 13 Jun 2019 14:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.508 X-Spam-Level: X-Spam-Status: No, score=-17.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-L5X76Y7CV0 for ; Thu, 13 Jun 2019 14:19:42 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 EE440120144 for ; Thu, 13 Jun 2019 14:19:41 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id a15so200072wmj.5 for ; Thu, 13 Jun 2019 14:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vHBYoT+q7C2b3sdOQprXKHHx6Ia6SgnFPncLEg+vDws=; b=MH8TGtOZgSHb4M/XPdmZezSGed6rwTD/IJukDc6sjt6cTSnFh23QSH21AuHUQYdh7g QLxxl4PJuowFbvw0KLIq1v3N85GtVpxlwXvX3iVhFAOtPYQjtYNtBay43+Uyf3hxwOY9 0QkQ8poRWzOYI/uy2FeONOua7x1FTkvFTNgh0OYXWuR6PFWN4oRFHkiSSPNzAMozIKHc KFd9Io2uofgHOqM8V/R7jsQRaRoBsYLik+wK4zrVW14Ob54dsjOn/6sDWIF0pOGSN9Sm en4CNLwHb2d9NQs1IBLZF/SKiSjR85QLB6jSAQeBM7qwHemdZtBJB2InH4PhYccxWSS6 hXxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vHBYoT+q7C2b3sdOQprXKHHx6Ia6SgnFPncLEg+vDws=; b=XWza+4r2TjV/t+ppO7sKQeZZZli9Tz/dEpWEYgIQtD++BlPVUYmmXZ5AwOuNp/qN6H vK+izAe9JtQFaeLqobcpujs4xvj5ziIgmePfGTI9MqBIiC2U9KJg9EKCIAXp+VPMCVXU WqeLC1FBKI1lc71kdnl4tC9R92fIKQGEHI87MajoPz3XRxDiVIXLQFLofX7m0upSRuTz YLfY25OtC/l1vwRRcqWOVYsHqYfW2ygzFAsIANEteeBO5lnyphmOQgsSgyKawldy+9hi 4/Cn/cOkQqgWlxTrWvLlwoJYeC2ZWcDso+t8I+0jbWJjFb4rVNYxaCxN+NG5/Lo1/PaL hhSA== X-Gm-Message-State: APjAAAXyMqdAQenBLkaT9FP2iewNv28Hj98W2YR7wuYiUrXBA2zv+5m4 Cki0S9qL0hgwf0/miTd7X9/jd9Bd5KmO25tluuRZ+A== X-Google-Smtp-Source: APXvYqwIWxhEDwO2m9T9Gay5gPHFhrDdQrZGix8nkJExf8i19wyNKwNP2aIkMP7S3LgYs1lP0S5yatEsK+UH8IxHsHA= X-Received: by 2002:a1c:7f93:: with SMTP id a141mr5163909wmd.131.1560460779798; Thu, 13 Jun 2019 14:19:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Hamilton Date: Thu, 13 Jun 2019 14:19:27 -0700 Message-ID: Subject: Re: Consistency in Stream Beginnings in HTTP/3 To: Lucas Pardue Cc: Mike Bishop , QUIC WG , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000077cd27058b3b1689" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 21:19:44 -0000 --00000000000077cd27058b3b1689 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of the options, I'd personally prefer revisiting #2526 and making push ID a required first frame on a push stream. On Thu, Jun 13, 2019 at 11:47 AM Lucas Pardue wrote: > Thanks for summarising all of this individual discussions Mike. > > I have a derivative design on the SETTINGS stream header which would > replace length-prefix with count. So rather than Express total length of > parameter ID and value, you tell the receiver how many variant pairs to > process before processing frames. > > I dont think that strongly pushes the needle in one direction though. > > If we reject changing the control stream, I'm presently 50/50 split > between revisiting push stream framing and just living with what we have. > > > On Thu, 13 Jun 2019, 18:30 Mike Bishop, wrote: > >> This discussion has happened across a collection of GitHub issues with >> largely the same participants, and I=E2=80=99d like to get a sense of th= e larger >> working group=E2=80=99s opinion before I work on any of these directions= (or close >> all the related issues). >> >> >> >> To recap the current state: >> >> - Unidirectional streams begin with a type byte; interpretation of >> the remainder of the stream data depends on the type >> - Push streams continue with a header =E2=80=93 the Push ID as a vari= nt =E2=80=93 >> followed by frames as usual >> - Control streams don=E2=80=99t have a header; frames begin immediate= ly after >> the type byte. However, a SETTINGS frame is required to be the first= frame >> of the stream. >> - SETTINGS cannot be sent again thereafter or on any other stream >> >> >> >> That means there are currently two different models of how you put >> required-to-be-first information: As a required-initial frame or as a >> header before framing begins. >> >> >> >> There are a couple of paths forward that have been discussed: >> >> - *Stay as-is.* SETTINGS is a frame in HTTP/2, so we=E2=80=99re keep= ing it >> that way for consistency. We=E2=80=99ve previously decided not to pe= rmit changes >> to settings to avoid the question of synchronization. The reasons to >> change are not urgent. >> - *Make the Push ID a required-initial frame. *Proposed in #2526; >> rejected in London. >> - *Make SETTINGS a stream header.* Proposed in #2783. >> - *Argument for:* Gets rid of the concept of required-initial >> frames, in combination with #2781. Consistent with the Push Strea= m header. >> - *Argument against:* Push ID isn=E2=80=99t a length-prefixed str= ucture, >> just a single varint. We already have facilities for reading >> length-prefixed structures in frame handling. >> - *Allow multiple SETTINGS.* The synchronization requirement on >> SETTINGS is hairy when values are reduced, because in-flight activity= might >> now violate a peer=E2=80=99s restriction. Allowing SETTINGS to be se= nt at any >> time, but only increase values, would also mean they need not be the = first >> frame, eliminating the concept of required-initial frames. >> - Complication: What does this mean for clients=E2=80=99 remember= ed >> settings and server=E2=80=99s remembered settings as stored in NST= s? If a client >> updates stored settings but retains a NST from earlier in the conn= ection, >> the server and client could have divergent views of the server=E2= =80=99s settings >> on a future 0-RTT connection. >> - *Allow omitting SETTINGS.* If the server doesn=E2=80=99t need to c= hange >> anything from the client=E2=80=99s initial settings, then the server = can just not >> send a SETTINGS frame. Once you=E2=80=99ve sent something else on th= e control >> stream, though, you can=E2=80=99t send one later if you change your m= ind. >> >> >> >> Thoughts? >> > --00000000000077cd27058b3b1689 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of the options, I'd personally prefer= revisiting=C2=A0#2526 and making push ID a required first frame on a push = stream.

On Thu, Jun 13, 2019 at 11:47 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:=
Thanks for summarising all of this individual discussions Mike.=C2= =A0

I have a derivative design= on the SETTINGS stream header which would replace length-prefix with count= . So rather than Express total length of parameter ID and value, you tell t= he receiver how many variant pairs to process before processing frames.=C2= =A0

I dont think that st= rongly pushes the needle in one direction though.
If we reject changing the control stream, I'm= presently 50/50 split between revisiting push stream framing and just livi= ng with what we have.


On Thu, 13 Jun 2019, 18:30 Mike Bishop, <mbishop@evequefou.be> wrote:

This discussion has happened across a collection of = GitHub issues with largely the same participants, and I=E2=80=99d like to g= et a sense of the larger working group=E2=80=99s opinion before I work on a= ny of these directions (or close all the related issues).

=C2=A0

To recap the current state:

  • Unidirectional streams b= egin with a type byte; interpretation of the remainder of the stream data d= epends on the type
  • Push streams continue with a header =E2=80=93 the Push ID as a= varint =E2=80=93 followed by frames as usual
  • Control streams don=E2=80=99t hav= e a header; frames begin immediately after the type byte.=C2=A0 However, a = SETTINGS frame is required to be the first frame of the stream.
  • SETTINGS cannot b= e sent again thereafter or on any other stream

=C2=A0

That means there are currently two different models = of how you put required-to-be-first information:=C2=A0 As a required-initia= l frame or as a header before framing begins.

=C2=A0

There are a couple of paths forward that have been d= iscussed:

  • Stay as-is.=C2=A0= SETTINGS is a frame in HTTP/2, so we=E2=80=99re keeping it that way for co= nsistency.=C2=A0 We=E2=80=99ve previously decided not to permit changes to = settings to avoid the question of synchronization.=C2=A0 The reasons to change are not urgent.=
  • Make the Push ID= a required-initial frame.=C2=A0 Proposed in #2526; rejected in London.
  • Make SETTINGS a stream header.= =C2=A0 Proposed in #2783.
    • Argument for:=C2= =A0 Gets rid of the concept of required-initial frames, in combination with= #2781.=C2=A0 Consistent with the Push Stream header.
      • Argument against:=C2= =A0 Push ID isn=E2=80=99t a length-prefixed structure, just a single varint= .=C2=A0 We already have facilities for reading length-prefixed structures i= n frame handling.
  • Allow multiple SETTIN= GS.=C2=A0 The synchronization requirement on SETTINGS is hairy when val= ues are reduced, because in-flight activity might now violate a peer=E2=80= =99s restriction.=C2=A0 Allowing SETTINGS to be sent at any time, but only increase values, would also mean= they need not be the first frame, eliminating the concept of required-init= ial frames.
    • Complication:=C2=A0 What= does this mean for clients=E2=80=99 remembered settings and server=E2=80= =99s remembered settings as stored in NSTs?=C2=A0 If a client updates store= d settings but retains a NST from earlier in the connection, the server and client could have divergent view= s of the server=E2=80=99s settings on a future 0-RTT connection.<= /u>
  • Allow omitting SETTIN= GS.=C2=A0 If the server doesn=E2=80=99t need to change anything from th= e client=E2=80=99s initial settings, then the server can just not send a SE= TTINGS frame.=C2=A0 Once you=E2=80=99ve sent something else on the control stream, though, you can=E2=80=99t send = one later if you change your mind.

=C2=A0

Thoughts?

--00000000000077cd27058b3b1689-- From nobody Thu Jun 13 14:40:12 2019 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 6008A120148 for ; Thu, 13 Jun 2019 14:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=zfzt8bco; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AhDIjWZR 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 sNh4cH5O3gTj for ; Thu, 13 Jun 2019 14:40:09 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D136D12016D for ; Thu, 13 Jun 2019 14:40:09 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 388A6136C for ; Thu, 13 Jun 2019 17:40:09 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 13 Jun 2019 17:40:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=C0pSI gV9oSnUkbqGrqdqp+mbxR1ozoEpf3eyjgltmFU=; b=zfzt8bcoXAXkVS1IhY8HX NCD7LYtOq4BQl9i4xFThz1Q83jjcEoXFhahMjsKdAN0y9zeENH59KWgLZoVuEx2i LxSeHeg7RZ9qHUl09rpnhCv7aym75yyFo5ltOuefZ3dA2tqfIAQ+RrpwndAw2yvM IbV47MdvySV/ubnn74rMgMsSQzJPzdDGR2+xPuiV+snpvbuGONcfXX8NnJJVBDck jAaENRGDelS2j8mzxwIpfzZpmttutb5MwxIVEkKvjeNwvBbqfXz0DpGIBagGM81L VViZEsF9Dn6IIs0atillqLc7ARw7scRbQEOqwJMfzj0I/YpBtvxInou2PwnZwChh A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=C0pSIgV9oSnUkbqGrqdqp+mbxR1ozoEpf3eyjgltm FU=; b=AhDIjWZRYLUGjuEtCIQzgos50CCyRHuFIq+4aZ8Z50XR2t8msw6M9M9aL kxfvW5rq3Pjhh7XB7F05jE7GYJfXcrpoN6c9dCQPAMT9Yp3+s9PVFhG74N064drD IhkpLE5OkcMzRkxDQYqxKTsjq2lrjVhxhzs2DQducRnkRQ8bpYES1BX7DrMI6ZIY 4JEl+7w8WICYpeDHrmn32ZIzw66zCxDQX8oCUIyyiRTxagYR5qgXmmZO1xYNDg7A oPDoM68pd1VP7Cs6Y0M3I44orsqIJ7SrzenJuhc67r00ElJ6Cbw8FCSqNPP0ppH/ c6ll4eEmFOKoJwZMAZRxYdkRlDDwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehledgudeifecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmthes lhhofigvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne curfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14881E00A1; Thu, 13 Jun 2019 17:40:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: <1ec2d583-52f0-4d25-a013-567fb59e8f88@www.fastmail.com> In-Reply-To: <4b79eb5b-3396-1f44-fba0-dae87025f528@erg.abdn.ac.uk> References: <4b79eb5b-3396-1f44-fba0-dae87025f528@erg.abdn.ac.uk> Date: Fri, 14 Jun 2019 07:40:08 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Calls on Recent Transport/TLS Issues: Issue 2580 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 21:40:11 -0000 On Thu, Jun 13, 2019, at 22:14, Gorry Fairhurst wrote: > On 28/05/2019 06:33, Mark Nottingham wrote: > > The following issues have proposals for resolution, and discussion s= o far seems to support consensus to accept them. If you object, please d= o so on the issue or in response to this message (changing the Subject a= ppropriately!). > > > > > > * #2580 - Is path validation a SHOULD or a MUST? (PR#2637) > > * >=20 > Could someone explain why the new change is safe relative to RFC6298? >=20 >=20 > I think the proposed text was: >=20 > .... 1 second initial handshake timeout as recommended in > =C2=A0{{?RFC6298}}. >=20 > =C2=A0A connection MAY use the delay between sending a PATH_CHALLENGE= and=20 > receiving > =C2=A0a PATH_RESPONSE to seed initial_rtt for a new path, but the del= ay=20 > SHOULD NOT > =C2=A0be considered an RTT sample." >=20 > .... Maybe I am wrong, but I interpret RFC6298 as saying the seed valu= e=20 > should be 1.5 x larger than this RTT value? >=20 > (To account for RTT variance.) This is good feedback. I've opened https://github.com/quicwg/base-drafts/issues/2789 I don't think that this is critical, because the seed will be erased aft= er the first RTT sample arrives. But we should allow for some increase = in the RTT on the path and being slightly more conservative might reduce= the rate that packets hit those new paths. From nobody Thu Jun 13 15:13:04 2019 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 D6CA212016F for ; Thu, 13 Jun 2019 15:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=a4f+tfh7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RMA1XOvN 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 Y2c7ecjbAL9l for ; Thu, 13 Jun 2019 15:13:01 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A5E120148 for ; Thu, 13 Jun 2019 15:13:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EC9CF1320 for ; Thu, 13 Jun 2019 18:13:00 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 13 Jun 2019 18:13:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=3PNvh Bh4VaUnDCsHwZjD/iyjs9kWQ4hU916d3q4YnNU=; b=a4f+tfh7tiTgqzDgD8F4z YCXIy17j6aU/3UXjUydiEnBrnWbz8JxSdvV+aB7bWfLj8lP7O4FoiLS+pB3WYoXv My42aGP4q5+h7LDX4xihTP7ORyVRAOQhj/N35JeI6r6L8OUrocxzR/exS22yQ/eX IaH6QEkYxJcHQPxsMkw5oJGsjsMxrYVC82zQXM8rMkvHTXwBfSEi464UKFXz4q9U Eg0ln8cqH1taYkq2Rnziot+1MAffvFrGAxPotM88YPsnc99TQDVLh70HI/IQfNc4 BGikn6YXjhzg1IlhDJaDSwjYOdaQiSaUxScGLBfo94tCkFBhLVM6JY7HpoBSo3xo w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3PNvhBh4VaUnDCsHwZjD/iyjs9kWQ4hU916d3q4Yn NU=; b=RMA1XOvNOaIzFiMrMGxy+KJq7+MzpPoiKbftTKXvEweo3RU81LSlTUbqj h2eYPCirATivkN0TJ/oB0R0OZf3zAC3pQ5wQINXdBdnmZDVaabRb+dZx65p9UoW8 O/P5vW9MHJvW97hoNFpKMXRlNo/sXcV1Y+KsjL4fjDRFlLogz7X15NwqlxWoKppA yqgXqS/ge8XJ+lmNSi+Hh056BvcqkpRqWExCcnNlPkfpmWk9Ci6Usnpyf8IBfft7 vdTsv0RZ6JpxRsLLM6ZYfVzZerpzc4rn91q/CR/Y6xqdK41djiRh+hIyMWaBExvK 2RwDhdI9MYx/scJTFdj66xZIp+uNA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeitddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslh hofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E08E2E00A1; Thu, 13 Jun 2019 18:12:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: <3a321233-f441-4044-9043-81bae5e5c4eb@www.fastmail.com> In-Reply-To: References: Date: Fri, 14 Jun 2019 08:13:00 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consistency in Stream Beginnings in HTTP/3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 13 Jun 2019 22:13:04 -0000 I tend toward the SETTINGS-as -header option, but not strongly. Bespoke= handling for settings is inevitable and a "fixed" header would eliminat= e any consideration of the frame type from a bunch of places. (I prefer= lengths over counts, to Lucas' suggestion here, either way.) In thinking about multiple SETTINGS frames, I don't think that you can j= ust say "only increase", because that constrains how we might use settin= gs. The rule is probably more that any use of a setting cannot be inval= idated by an updated SETTINGS frame. In other words, if s1 is the old v= alue of a setting and s2 is the updated value, any use of s1 needs to be= valid if s2 is set. For numeric limits, that means that s2 needs to be greater than or equal= to s1. But it also means that there can't be any strong assumption abo= ut the value of s1 or s2 in their usage. Usage has to allow for uncerta= inty about what value is in use. For instance, a setting couldn't be us= ed as the QPACK dynamic table capacity because there can't be uncertaint= y about that value (we don't have this problem, though we flirted with t= he notion for the initial capacity, but I hope that it illustrates the p= oint). We might also say that a new setting is a bitmask. If values that are s= et imply permission to perform certain actions, then s2>=3Ds1 isn't suff= icient. You need s2&s1=3D=3Ds1. That implies s2>=3Ds1, but it isn't qu= ite the same. If certain bits being set were associated with prohibitin= g actions, then a different rule would be needed. And you need to ensure that every setting is assigned a compatible value= when updated, or specify that existing values carry over if not specifi= ed (like 7540). Under those terms, you might say that a client can attempt 0-RTT or resu= mption under an assumption of either s1 or s2, but there are some signif= icant synchronization issues. If the ticket was provided before the set= ting was sent, then we can't assume that the server has a way of recordi= ng s2 in the ticket. That means that there needs to be some rule about = what to do with settings. The simplest rule would be that tickets don't= bind to updated values at all. Working out how to signal that updated = settings apply to a given ticket requires a lot of crossing of lines. In the end, updating settings is just too complicated. If we don't allow updating settings, I realize that we need to be much c= learer about how that first SETTINGS is bound into any session ticket. = Though that session ticket might arrive before the SETTINGS frame, it wo= uld be unfortunate if the client couldn't use those settings when it sta= rts 0-RTT. I'll open an issue. On Fri, Jun 14, 2019, at 03:30, Mike Bishop wrote: > There are a couple of paths forward that have been discussed: >=20 > * *Stay as-is.* SETTINGS is a frame in HTTP/2, so we=E2=80=99re keepi= ng it=20 > that way for consistency. We=E2=80=99ve previously decided not to perm= it=20 > changes to settings to avoid the question of synchronization. The=20 > reasons to change are not urgent. > * *Make the Push ID a required-initial frame. *Proposed in #2526;=20 > rejected in London. > * *Make SETTINGS a stream header.* Proposed in #2783. > * *Argument for:* Gets rid of the concept of required-initial=20 > frames, in combination with #2781. Consistent with the Push Stream=20 > header. > * *Argument against:* Push ID isn=E2=80=99t a length-prefixed struc= ture,=20 > just a single varint. We already have facilities for reading=20 > length-prefixed structures in frame handling. > * *Allow multiple SETTINGS.* The synchronization requirement on=20 > SETTINGS is hairy when values are reduced, because in-flight activity=20= > might now violate a peer=E2=80=99s restriction. Allowing SETTINGS to b= e sent at=20 > any time, but only increase values, would also mean they need not be=20= > the first frame, eliminating the concept of required-initial frames. > * Complication: What does this mean for clients=E2=80=99 remembered= settings=20 > and server=E2=80=99s remembered settings as stored in NSTs? If a clien= t updates=20 > stored settings but retains a NST from earlier in the connection, the=20= > server and client could have divergent views of the server=E2=80=99s s= ettings=20 > on a future 0-RTT connection. > * *Allow omitting SETTINGS.* If the server doesn=E2=80=99t need to ch= ange=20 > anything from the client=E2=80=99s initial settings, then the server c= an just=20 > not send a SETTINGS frame. Once you=E2=80=99ve sent something else on = the=20 > control stream, though, you can=E2=80=99t send one later if you change= your=20 > mind. >=20 > Thoughts? > From nobody Thu Jun 13 17:05:21 2019 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 1005312018C for ; Thu, 13 Jun 2019 17:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 NmaTdajmMi_i for ; Thu, 13 Jun 2019 17:05:16 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::724]) (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 563391201D1 for ; Thu, 13 Jun 2019 17:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qils8URAK/8E+/dHwda7MDqtDf1vBoYOZN3hXL9UoD0=; b=cXlIiXhaUep7Vbri510/eiWa+w57o21GKDFqToPsfhTDDJM8sFpUSEnZ8UWCjYTUtcjXu8JPH2WSbeJK8Cv8K95CW+0OgG7UxLTE9RidX3PTchM8Tp8+C8+2nHtqGYes0fRD4CEz2UtGGkQnqBRSdkFXFaD/FC+rR7MgrCpRy9Y= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0600.namprd22.prod.outlook.com (10.172.135.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.10; Fri, 14 Jun 2019 00:05:13 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1987.012; Fri, 14 Jun 2019 00:05:12 +0000 From: Mike Bishop To: Martin Thomson , "quic@ietf.org" Subject: RE: Consistency in Stream Beginnings in HTTP/3 Thread-Topic: Consistency in Stream Beginnings in HTTP/3 Thread-Index: AdUiCyWUFMBA6tDjRVeSCgLZOnPdlwAKgPIAAAPHuqA= Date: Fri, 14 Jun 2019 00:05:12 +0000 Message-ID: References: <3a321233-f441-4044-9043-81bae5e5c4eb@www.fastmail.com> In-Reply-To: <3a321233-f441-4044-9043-81bae5e5c4eb@www.fastmail.com> 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=mbishop@evequefou.be; x-originating-ip: [2607:fb90:8364:4f47:a406:cb8e:3ed7:4086] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28689234-d3d9-4afb-dcfd-08d6f05bf902 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0600; x-ms-traffictypediagnostic: CY4PR22MB0600: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 0068C7E410 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(376002)(136003)(346002)(366004)(396003)(13464003)(199004)(189003)(86362001)(6436002)(99286004)(74482002)(6246003)(8936002)(7736002)(76116006)(6506007)(2906002)(2501003)(76176011)(305945005)(25786009)(8676002)(53546011)(7696005)(81166006)(6116002)(81156014)(229853002)(53936002)(14444005)(446003)(46003)(186003)(66446008)(508600001)(33656002)(52536014)(486006)(68736007)(55016002)(73956011)(476003)(66946007)(9686003)(66476007)(11346002)(64756008)(71200400001)(110136005)(316002)(71190400001)(102836004)(256004)(5660300002)(66556008)(14454004)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0600; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:3; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8zRfN6NxqHTv2+2Kb2dENnM29oBOFsMozwSa/3Gg55XJYjtkZ54uclqfvRNeesE68yTMrBOJ4xUC5+nZaFulCtRQYMXbFQiiM8+uJszU/BsEaTKcE3eBT6bTU81d0CI1miJuhdgzZfQmk01WGfZUJzZSN66FgKPffSa3ZV/27NbswjmMfroZnx7eF/8P06dRUA7wqii1W+seLLV1NBAfl3Yuukp3b/hca84Guw6BVYIj8daYAyzzViRsOKvrqXh2vBVbAeZIu4KLUmc+BW0j6bvWy4GuPAiSATXP+ymred2uct1FU7L+GXraf3ho7AHDE0rzYgnuwKy9PG96ejVJXyZthLdHcw8CsssnhZqfNJcltnN3iR4gEBHPvPB1r8tX5ln19tCOWZ8F9Qhq2doN9fwVWLABhsyjnAUB+vGwsTc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 28689234-d3d9-4afb-dcfd-08d6f05bf902 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 00:05:12.8667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0600 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 00:05:20 -0000 SSB0aGluayBhIGxvdCBvZiB0aGlzIGNvbXBsZXhpdHkgZ2V0cyBpbnZva2VkIGluIHRoZSB0cmFu c2l0aW9uIGZyb20gdGhlIDAtUlRUIHZhbHVlcyB0byB0aGUgbmV3IFNFVFRJTkdTIGZyYW1lIGFz IHdlbGwuICBXZSBzaG91bGQgcHJvYmFibHkgZXhwYW5kIHRoYXQgdGV4dCwgcmVnYXJkbGVzcyBv ZiB3aGF0IHdlIGRvLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyA8 cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6 IFRodXJzZGF5LCBKdW5lIDEzLCAyMDE5IDM6MTMgUE0NClRvOiBxdWljQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogQ29uc2lzdGVuY3kgaW4gU3RyZWFtIEJlZ2lubmluZ3MgaW4gSFRUUC8zDQoNCkkg dGVuZCB0b3dhcmQgdGhlIFNFVFRJTkdTLWFzIC1oZWFkZXIgb3B0aW9uLCBidXQgbm90IHN0cm9u Z2x5LiAgQmVzcG9rZSBoYW5kbGluZyBmb3Igc2V0dGluZ3MgaXMgaW5ldml0YWJsZSBhbmQgYSAi Zml4ZWQiIGhlYWRlciB3b3VsZCBlbGltaW5hdGUgYW55IGNvbnNpZGVyYXRpb24gb2YgdGhlIGZy YW1lIHR5cGUgZnJvbSBhIGJ1bmNoIG9mIHBsYWNlcy4gIChJIHByZWZlciBsZW5ndGhzIG92ZXIg Y291bnRzLCB0byBMdWNhcycgc3VnZ2VzdGlvbiBoZXJlLCBlaXRoZXIgd2F5LikNCg0KSW4gdGhp bmtpbmcgYWJvdXQgbXVsdGlwbGUgU0VUVElOR1MgZnJhbWVzLCBJIGRvbid0IHRoaW5rIHRoYXQg eW91IGNhbiBqdXN0IHNheSAib25seSBpbmNyZWFzZSIsIGJlY2F1c2UgdGhhdCBjb25zdHJhaW5z IGhvdyB3ZSBtaWdodCB1c2Ugc2V0dGluZ3MuICBUaGUgcnVsZSBpcyBwcm9iYWJseSBtb3JlIHRo YXQgYW55IHVzZSBvZiBhIHNldHRpbmcgY2Fubm90IGJlIGludmFsaWRhdGVkIGJ5IGFuIHVwZGF0 ZWQgU0VUVElOR1MgZnJhbWUuICBJbiBvdGhlciB3b3JkcywgaWYgczEgaXMgdGhlIG9sZCB2YWx1 ZSBvZiBhIHNldHRpbmcgYW5kIHMyIGlzIHRoZSB1cGRhdGVkIHZhbHVlLCBhbnkgdXNlIG9mIHMx IG5lZWRzIHRvIGJlIHZhbGlkIGlmIHMyIGlzIHNldC4NCg0KRm9yIG51bWVyaWMgbGltaXRzLCB0 aGF0IG1lYW5zIHRoYXQgczIgbmVlZHMgdG8gYmUgZ3JlYXRlciB0aGFuIG9yIGVxdWFsIHRvIHMx LiAgQnV0IGl0IGFsc28gbWVhbnMgdGhhdCB0aGVyZSBjYW4ndCBiZSBhbnkgc3Ryb25nIGFzc3Vt cHRpb24gYWJvdXQgdGhlIHZhbHVlIG9mIHMxIG9yIHMyIGluIHRoZWlyIHVzYWdlLiAgVXNhZ2Ug aGFzIHRvIGFsbG93IGZvciB1bmNlcnRhaW50eSBhYm91dCB3aGF0IHZhbHVlIGlzIGluIHVzZS4g IEZvciBpbnN0YW5jZSwgYSBzZXR0aW5nIGNvdWxkbid0IGJlIHVzZWQgYXMgdGhlIFFQQUNLIGR5 bmFtaWMgdGFibGUgY2FwYWNpdHkgYmVjYXVzZSB0aGVyZSBjYW4ndCBiZSB1bmNlcnRhaW50eSBh Ym91dCB0aGF0IHZhbHVlICh3ZSBkb24ndCBoYXZlIHRoaXMgcHJvYmxlbSwgdGhvdWdoIHdlIGZs aXJ0ZWQgd2l0aCB0aGUgbm90aW9uIGZvciB0aGUgaW5pdGlhbCBjYXBhY2l0eSwgYnV0IEkgaG9w ZSB0aGF0IGl0IGlsbHVzdHJhdGVzIHRoZSBwb2ludCkuDQoNCldlIG1pZ2h0IGFsc28gc2F5IHRo YXQgYSBuZXcgc2V0dGluZyBpcyBhIGJpdG1hc2suICBJZiB2YWx1ZXMgdGhhdCBhcmUgc2V0IGlt cGx5IHBlcm1pc3Npb24gdG8gcGVyZm9ybSBjZXJ0YWluIGFjdGlvbnMsIHRoZW4gczI+PXMxIGlz bid0IHN1ZmZpY2llbnQuICBZb3UgbmVlZCBzMiZzMT09czEuICBUaGF0IGltcGxpZXMgczI+PXMx LCBidXQgaXQgaXNuJ3QgcXVpdGUgdGhlIHNhbWUuICBJZiBjZXJ0YWluIGJpdHMgYmVpbmcgc2V0 IHdlcmUgYXNzb2NpYXRlZCB3aXRoIHByb2hpYml0aW5nIGFjdGlvbnMsIHRoZW4gYSBkaWZmZXJl bnQgcnVsZSB3b3VsZCBiZSBuZWVkZWQuDQoNCkFuZCB5b3UgbmVlZCB0byBlbnN1cmUgdGhhdCBl dmVyeSBzZXR0aW5nIGlzIGFzc2lnbmVkIGEgY29tcGF0aWJsZSB2YWx1ZSB3aGVuIHVwZGF0ZWQs IG9yIHNwZWNpZnkgdGhhdCBleGlzdGluZyB2YWx1ZXMgY2Fycnkgb3ZlciBpZiBub3Qgc3BlY2lm aWVkIChsaWtlIDc1NDApLg0KDQpVbmRlciB0aG9zZSB0ZXJtcywgeW91IG1pZ2h0IHNheSB0aGF0 IGEgY2xpZW50IGNhbiBhdHRlbXB0IDAtUlRUIG9yIHJlc3VtcHRpb24gdW5kZXIgYW4gYXNzdW1w dGlvbiBvZiBlaXRoZXIgczEgb3IgczIsIGJ1dCB0aGVyZSBhcmUgc29tZSBzaWduaWZpY2FudCBz eW5jaHJvbml6YXRpb24gaXNzdWVzLiAgSWYgdGhlIHRpY2tldCB3YXMgcHJvdmlkZWQgYmVmb3Jl IHRoZSBzZXR0aW5nIHdhcyBzZW50LCB0aGVuIHdlIGNhbid0IGFzc3VtZSB0aGF0IHRoZSBzZXJ2 ZXIgaGFzIGEgd2F5IG9mIHJlY29yZGluZyBzMiBpbiB0aGUgdGlja2V0LiAgVGhhdCBtZWFucyB0 aGF0IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgcnVsZSBhYm91dCB3aGF0IHRvIGRvIHdpdGggc2V0 dGluZ3MuICBUaGUgc2ltcGxlc3QgcnVsZSB3b3VsZCBiZSB0aGF0IHRpY2tldHMgZG9uJ3QgYmlu ZCB0byB1cGRhdGVkIHZhbHVlcyBhdCBhbGwuICBXb3JraW5nIG91dCBob3cgdG8gc2lnbmFsIHRo YXQgdXBkYXRlZCBzZXR0aW5ncyBhcHBseSB0byBhIGdpdmVuIHRpY2tldCByZXF1aXJlcyBhIGxv dCBvZiBjcm9zc2luZyBvZiBsaW5lcy4NCg0KSW4gdGhlIGVuZCwgdXBkYXRpbmcgc2V0dGluZ3Mg aXMganVzdCB0b28gY29tcGxpY2F0ZWQuDQoNCklmIHdlIGRvbid0IGFsbG93IHVwZGF0aW5nIHNl dHRpbmdzLCBJIHJlYWxpemUgdGhhdCB3ZSBuZWVkIHRvIGJlIG11Y2ggY2xlYXJlciBhYm91dCBo b3cgdGhhdCBmaXJzdCBTRVRUSU5HUyBpcyBib3VuZCBpbnRvIGFueSBzZXNzaW9uIHRpY2tldC4g IFRob3VnaCB0aGF0IHNlc3Npb24gdGlja2V0IG1pZ2h0IGFycml2ZSBiZWZvcmUgdGhlIFNFVFRJ TkdTIGZyYW1lLCBpdCB3b3VsZCBiZSB1bmZvcnR1bmF0ZSBpZiB0aGUgY2xpZW50IGNvdWxkbid0 IHVzZSB0aG9zZSBzZXR0aW5ncyB3aGVuIGl0IHN0YXJ0cyAwLVJUVC4gIEknbGwgb3BlbiBhbiBp c3N1ZS4NCg0KDQpPbiBGcmksIEp1biAxNCwgMjAxOSwgYXQgMDM6MzAsIE1pa2UgQmlzaG9wIHdy b3RlOg0KPiBUaGVyZSBhcmUgYSBjb3VwbGUgb2YgcGF0aHMgZm9yd2FyZCB0aGF0IGhhdmUgYmVl biBkaXNjdXNzZWQ6DQo+IA0KPiAgKiAqU3RheSBhcy1pcy4qIFNFVFRJTkdTIGlzIGEgZnJhbWUg aW4gSFRUUC8yLCBzbyB3ZeKAmXJlIGtlZXBpbmcgaXQgDQo+IHRoYXQgd2F5IGZvciBjb25zaXN0 ZW5jeS4gV2XigJl2ZSBwcmV2aW91c2x5IGRlY2lkZWQgbm90IHRvIHBlcm1pdCANCj4gY2hhbmdl cyB0byBzZXR0aW5ncyB0byBhdm9pZCB0aGUgcXVlc3Rpb24gb2Ygc3luY2hyb25pemF0aW9uLiBU aGUgDQo+IHJlYXNvbnMgdG8gY2hhbmdlIGFyZSBub3QgdXJnZW50Lg0KPiAgKiAqTWFrZSB0aGUg UHVzaCBJRCBhIHJlcXVpcmVkLWluaXRpYWwgZnJhbWUuICpQcm9wb3NlZCBpbiAjMjUyNjsgDQo+ IHJlamVjdGVkIGluIExvbmRvbi4NCj4gICogKk1ha2UgU0VUVElOR1MgYSBzdHJlYW0gaGVhZGVy LiogUHJvcG9zZWQgaW4gIzI3ODMuDQo+ICAgICogKkFyZ3VtZW50IGZvcjoqIEdldHMgcmlkIG9m IHRoZSBjb25jZXB0IG9mIHJlcXVpcmVkLWluaXRpYWwgDQo+IGZyYW1lcywgaW4gY29tYmluYXRp b24gd2l0aCAjMjc4MS4gQ29uc2lzdGVudCB3aXRoIHRoZSBQdXNoIFN0cmVhbSANCj4gaGVhZGVy Lg0KPiAgICAqICpBcmd1bWVudCBhZ2FpbnN0OiogUHVzaCBJRCBpc27igJl0IGEgbGVuZ3RoLXBy ZWZpeGVkIHN0cnVjdHVyZSwgDQo+IGp1c3QgYSBzaW5nbGUgdmFyaW50LiBXZSBhbHJlYWR5IGhh dmUgZmFjaWxpdGllcyBmb3IgcmVhZGluZyANCj4gbGVuZ3RoLXByZWZpeGVkIHN0cnVjdHVyZXMg aW4gZnJhbWUgaGFuZGxpbmcuDQo+ICAqICpBbGxvdyBtdWx0aXBsZSBTRVRUSU5HUy4qIFRoZSBz eW5jaHJvbml6YXRpb24gcmVxdWlyZW1lbnQgb24gDQo+IFNFVFRJTkdTIGlzIGhhaXJ5IHdoZW4g dmFsdWVzIGFyZSByZWR1Y2VkLCBiZWNhdXNlIGluLWZsaWdodCBhY3Rpdml0eSANCj4gbWlnaHQg bm93IHZpb2xhdGUgYSBwZWVy4oCZcyByZXN0cmljdGlvbi4gQWxsb3dpbmcgU0VUVElOR1MgdG8g YmUgc2VudCANCj4gYXQgYW55IHRpbWUsIGJ1dCBvbmx5IGluY3JlYXNlIHZhbHVlcywgd291bGQg YWxzbyBtZWFuIHRoZXkgbmVlZCBub3QgDQo+IGJlIHRoZSBmaXJzdCBmcmFtZSwgZWxpbWluYXRp bmcgdGhlIGNvbmNlcHQgb2YgcmVxdWlyZWQtaW5pdGlhbCBmcmFtZXMuDQo+ICAgICogQ29tcGxp Y2F0aW9uOiBXaGF0IGRvZXMgdGhpcyBtZWFuIGZvciBjbGllbnRz4oCZIHJlbWVtYmVyZWQgDQo+ IHNldHRpbmdzIGFuZCBzZXJ2ZXLigJlzIHJlbWVtYmVyZWQgc2V0dGluZ3MgYXMgc3RvcmVkIGlu IE5TVHM/IElmIGEgDQo+IGNsaWVudCB1cGRhdGVzIHN0b3JlZCBzZXR0aW5ncyBidXQgcmV0YWlu cyBhIE5TVCBmcm9tIGVhcmxpZXIgaW4gdGhlIA0KPiBjb25uZWN0aW9uLCB0aGUgc2VydmVyIGFu ZCBjbGllbnQgY291bGQgaGF2ZSBkaXZlcmdlbnQgdmlld3Mgb2YgdGhlIA0KPiBzZXJ2ZXLigJlz IHNldHRpbmdzIG9uIGEgZnV0dXJlIDAtUlRUIGNvbm5lY3Rpb24uDQo+ICAqICpBbGxvdyBvbWl0 dGluZyBTRVRUSU5HUy4qIElmIHRoZSBzZXJ2ZXIgZG9lc27igJl0IG5lZWQgdG8gY2hhbmdlIA0K PiBhbnl0aGluZyBmcm9tIHRoZSBjbGllbnTigJlzIGluaXRpYWwgc2V0dGluZ3MsIHRoZW4gdGhl IHNlcnZlciBjYW4ganVzdCANCj4gbm90IHNlbmQgYSBTRVRUSU5HUyBmcmFtZS4gT25jZSB5b3Xi gJl2ZSBzZW50IHNvbWV0aGluZyBlbHNlIG9uIHRoZSANCj4gY29udHJvbCBzdHJlYW0sIHRob3Vn aCwgeW91IGNhbuKAmXQgc2VuZCBvbmUgbGF0ZXIgaWYgeW91IGNoYW5nZSB5b3VyIA0KPiBtaW5k Lg0KPiANCj4gVGhvdWdodHM/DQo+DQoNCg== From nobody Thu Jun 13 17:50:37 2019 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 90F041200F6 for ; Thu, 13 Jun 2019 17:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6UuHyyLPv1w for ; Thu, 13 Jun 2019 17:50:32 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7EB12000E for ; Thu, 13 Jun 2019 17:50:32 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id 16so537998ljv.10 for ; Thu, 13 Jun 2019 17:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QklJgLRz/vEScGE+g8dKw2LN8kTn5BzAahlAkHo8D+U=; b=A2ZdEC+GmfOShu5ckozZVgzRdoQi3WOQlqf9o6MZK2ZOzZUPtcu3sh7Ag/I77eOWik Te9b28SL5W70uhE6I2PZeNygOj3RaoGe6sPeMGIZ/nopKCITqXL5DH0wRTd1G5qzItKH 26sMbIwPLzVp6BWO0y9zCCtRQidojdoXn8jkYaI3LgJZjpZPFzYHLw1YR6fqQIa0YoKM p4NHv8MtLXOGaOHf28s2qDd8GR7Ij/ZITFghLpuvNnFRSBcuB90ARXebZEibKhhN/Ag0 DaTbk3BKmLVqSdyL7dSYBIRh3IRkLwQalimmW+KSeFaDwmRAPcwQhdbSi4MkglvPlsRi p7iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QklJgLRz/vEScGE+g8dKw2LN8kTn5BzAahlAkHo8D+U=; b=t+Z7ZZ/uZ+5z+YKw2ihnG7RF1fAt8+EZZyfQ1BTP5E8l9tWbdWh3Kl92DuQbjatXlQ 6CGe9PNZ8VYVdjfzbkV/A0VHCNJz3jZU+sX3p5vDaKuStJxlsqLerwUEEuisvf+hE+0v tIabTMdHsidyfTvqJEM657VJwyUxTYeeEP5oUQAGfSny3hl8eqY1C56ZN64svLxkgcG3 aeMJL0SbxNys9v6G0hBK0QflanS7C+CcpMBg3AOeVsg3UaYTPkvUGYgsms+tRnM/cmBn zjAEfJnXJ2TVCKm8yiTbciQc0hdEFLCazDtdjgNWwT7J889Oki4/PvAfyNvYQSdz9yg/ 7czw== X-Gm-Message-State: APjAAAXETduVyS2kUIsyNPIxNRae8aipBNQwRwywMeJfUBJ5QSg0/RLo rDJTqo5kWbdSRS0BW6xUtNKPwoenMMD1RxCrdo8= X-Google-Smtp-Source: APXvYqxqyPCGg+koK8cYMH42GwyDg7JTgrZBUts3dzUwj5jwel/1vuiGrAllWK+dQWQgiecjn4saP/5LgO5HszURbmk= X-Received: by 2002:a2e:9212:: with SMTP id k18mr2520775ljg.15.1560473430523; Thu, 13 Jun 2019 17:50:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kazuho Oku Date: Fri, 14 Jun 2019 09:50:20 +0900 Message-ID: Subject: Re: Consistency in Stream Beginnings in HTTP/3 To: Ryan Hamilton Cc: Lucas Pardue , QUIC WG , Mike Bishop , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 00:50:36 -0000 2019=E5=B9=B46=E6=9C=8814=E6=97=A5(=E9=87=91) 6:19 Ryan Hamilton : > > Of the options, I'd personally prefer revisiting #2526 and making push ID= a required first frame on a push stream. +1. As I've commented on #2783, I prefer using one TLV structure (called HTTP/3 frame) consistently, rather than inventing different structures for different purposes. We have states that expect particular frame; it's the design pattern we have. The request stream decoder has a state that waits for HEADERS frame. I prefer consistently using one design pattern, unless there is a practical benefit in using something special. > > On Thu, Jun 13, 2019 at 11:47 AM Lucas Pardue wrote: >> >> Thanks for summarising all of this individual discussions Mike. >> >> I have a derivative design on the SETTINGS stream header which would rep= lace length-prefix with count.. So rather than Express total length of para= meter ID and value, you tell the receiver how many variant pairs to process= before processing frames. >> >> I dont think that strongly pushes the needle in one direction though. >> >> If we reject changing the control stream, I'm presently 50/50 split betw= een revisiting push stream framing and just living with what we have. >> >> >> On Thu, 13 Jun 2019, 18:30 Mike Bishop, wrote: >>> >>> This discussion has happened across a collection of GitHub issues with = largely the same participants, and I=E2=80=99d like to get a sense of the l= arger working group=E2=80=99s opinion before I work on any of these directi= ons (or close all the related issues). >>> >>> >>> >>> To recap the current state: >>> >>> Unidirectional streams begin with a type byte; interpretation of the re= mainder of the stream data depends on the type >>> Push streams continue with a header =E2=80=93 the Push ID as a varint = =E2=80=93 followed by frames as usual >>> Control streams don=E2=80=99t have a header; frames begin immediately a= fter the type byte. However, a SETTINGS frame is required to be the first = frame of the stream. >>> SETTINGS cannot be sent again thereafter or on any other stream >>> >>> >>> >>> That means there are currently two different models of how you put requ= ired-to-be-first information: As a required-initial frame or as a header b= efore framing begins. >>> >>> >>> >>> There are a couple of paths forward that have been discussed: >>> >>> Stay as-is. SETTINGS is a frame in HTTP/2, so we=E2=80=99re keeping it= that way for consistency. We=E2=80=99ve previously decided not to permit = changes to settings to avoid the question of synchronization. The reasons = to change are not urgent. >>> Make the Push ID a required-initial frame. Proposed in #2526; rejected= in London. >>> Make SETTINGS a stream header. Proposed in #2783. >>> >>> Argument for: Gets rid of the concept of required-initial frames, in c= ombination with #2781. Consistent with the Push Stream header. >>> Argument against: Push ID isn=E2=80=99t a length-prefixed structure, j= ust a single varint.. We already have facilities for reading length-prefix= ed structures in frame handling. >>> >>> Allow multiple SETTINGS. The synchronization requirement on SETTINGS i= s hairy when values are reduced, because in-flight activity might now viola= te a peer=E2=80=99s restriction. Allowing SETTINGS to be sent at any time,= but only increase values, would also mean they need not be the first frame= , eliminating the concept of required-initial frames. >>> >>> Complication: What does this mean for clients=E2=80=99 remembered sett= ings and server=E2=80=99s remembered settings as stored in NSTs? If a clie= nt updates stored settings but retains a NST from earlier in the connection= , the server and client could have divergent views of the server=E2=80=99s = settings on a future 0-RTT connection. >>> >>> Allow omitting SETTINGS. If the server doesn=E2=80=99t need to change = anything from the client=E2=80=99s initial settings, then the server can ju= st not send a SETTINGS frame. Once you=E2=80=99ve sent something else on t= he control stream, though, you can=E2=80=99t send one later if you change y= our mind. >>> >>> >>> >>> Thoughts? --=20 Kazuho Oku From nobody Fri Jun 14 01:34:30 2019 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 A78CA120198 for ; Fri, 14 Jun 2019 01:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkRA0cgfW4d9 for ; Fri, 14 Jun 2019 01:34:26 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 BAD511200A3 for ; Fri, 14 Jun 2019 01:34:24 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x5E8YCST015675 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Jun 2019 10:34:12 +0200 Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hbhdC-0008EH-3T; Fri, 14 Jun 2019 10:32:18 +0200 From: "Philipp S. Tiesel" Message-Id: <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_8D046079-322B-474B-8483-50D7CD2735D1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Call: More Connection ID Space #2736 Date: Fri, 14 Jun 2019 10:34:12 +0200 In-Reply-To: <20190613175443.GA23884@ubuntu-dmitri> Cc: Marten Seemann , Lars Eggert , QUIC WG , Christian Huitema , Martin Thomson To: Dmitri Tikhonov References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 08:34:29 -0000 --Apple-Mail=_8D046079-322B-474B-8483-50D7CD2735D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13. Jun 2019, at 19:54, Dmitri Tikhonov = wrote: >=20 > On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: >> Besides the obvious inefficiency, which is only born by the >> implementations that actually decide to make use of these long >> connection IDs (or rather, by their peers), >=20 > The peer can provide CIDs of any size via NEW_CONNECTION_ID, so > unless an implementation throws longs CIDs out, it has to support > long CIDs. In addition, a server has no choice but to support > maximum-size ODCID. We could make the maximum SCID LEN a transport parameter and=20 make it an error to extend the connection ID beyond this value. Together with a sane minimal CID a server has to support, this=20 mitigates evil clients that try to exhaust resources at the server without limiting the client. If we have such a mechanism, we can allow the full 255 byte connection IDs for special purpose use cases that presume they need such = long CIDs >=20 > There are trade-offs: >=20 > 1. Make its cid_t a fixed-size object that can fit the > largest CID and eat the overhead for all CIDs. This > has large memory overhead but it is simple and has > good locality of refence. >=20 > 2. Make cid_t a variable-size object. This saves memory > overall, but is more complicated and likely slower > (two memory accesses to get CID). >=20 > 3. Have two types: peer_cid_t that can be any size and > my_cid_t that supports CIDs of fixed length picked by > the implementation. This is even more complicated. >=20 > To summarize, the maximum CID length affects all implementations. >=20 > - Dmitri. >=20 >=20 AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ --Apple-Mail=_8D046079-322B-474B-8483-50D7CD2735D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 13. Jun 2019, at 19:54, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:

On = Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote:
Besides the obvious = inefficiency, which is only born by the
implementations = that actually decide to make use of these long
connection = IDs (or rather, by their peers),

The peer can provide CIDs of any size via NEW_CONNECTION_ID, = so
unless an implementation throws longs CIDs out, it has = to support
long CIDs.  In addition, a server has no = choice but to support
maximum-size ODCID.

We = could make the maximum SCID LEN a transport parameter = and 
make it an error to extend the connection ID beyond = this value.
Together with a sane minimal CID a server has to = support, this 
mitigates evil clients that try to exhaust = resources at the
server without limiting the = client.

If we have such a mechanism, = we can allow the full 255 byte
connection IDs for special = purpose use cases that presume they need such long CIDs



There are = trade-offs:

   1. Make its = cid_t a fixed-size object that can fit the
=       largest CID and eat the overhead for = all CIDs.  This
=       has large memory overhead but it is = simple and has
      good = locality of refence.

   2. = Make cid_t a variable-size object.  This saves memory
=       overall, but is more complicated and = likely slower
      (two = memory accesses to get CID).

=    3. Have two types: peer_cid_t that can be any size = and
      my_cid_t that = supports CIDs of fixed length picked by
=       the implementation.  This is = even more complicated.

To summarize, the = maximum CID length affects all implementations.

 - Dmitri.



AVE!
   Philipp S. = Tiesel

-- 
Philipp S. = Tiesel 
https://philipp.tiesel.net/

= --Apple-Mail=_8D046079-322B-474B-8483-50D7CD2735D1-- From nobody Fri Jun 14 08:21:30 2019 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 B468E120329 for ; Fri, 14 Jun 2019 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 vHaQL_UP51Lg for ; Fri, 14 Jun 2019 08:21:25 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690129.outbound.protection.outlook.com [40.107.69.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 7812612007C for ; Fri, 14 Jun 2019 08:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+x9PL2AMg/4nK1JpZA6R3d7nevP2qGvqE5LPGROzBk8=; b=QmSnPF3nz6MPskC+9hTELMtjpLh8jFXMfRO2gT7UI/o+1faU51ov2TssuFm6pc3KmymLjCNI5kSRJJatKS5pO/p4PIZb+zMzc13pTwJk9pr6ZfZQ9dbCU9rrf2fPbEN2v42XoC5UnacSUsyB9ykiQFoOrDp+BmGjzdI5t+jEQK8= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0343.namprd22.prod.outlook.com (10.173.194.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Fri, 14 Jun 2019 15:21:21 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.1987.013; Fri, 14 Jun 2019 15:21:21 +0000 From: Mike Bishop To: "Philipp S. Tiesel" , Dmitri Tikhonov CC: Marten Seemann , Lars Eggert , QUIC WG , Christian Huitema , Martin Thomson Subject: RE: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORiEijuWTMk40i6dp3cA94toqaXjl6AgAGE3YCAAA8NgIAABlqAgAC3vwCAAPW4AIAAb5mw Date: Fri, 14 Jun 2019 15:21:21 +0000 Message-ID: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> In-Reply-To: <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> 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=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:6552:cd14:5de2:e766] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: befaf6a3-6ebe-47e7-3857-08d6f0dbf509 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0343; x-ms-traffictypediagnostic: CY4PR22MB0343: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1091; x-forefront-prvs: 0068C7E410 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(136003)(366004)(39830400003)(346002)(199004)(189003)(236005)(71200400001)(76176011)(66946007)(6246003)(52536014)(53936002)(6436002)(316002)(81166006)(76116006)(73956011)(71190400001)(8936002)(66476007)(66446008)(64756008)(74482002)(66556008)(8676002)(4326008)(6506007)(7696005)(33656002)(9686003)(54906003)(99286004)(68736007)(7736002)(2906002)(81156014)(110136005)(229853002)(25786009)(55016002)(54896002)(6306002)(46003)(102836004)(86362001)(74316002)(11346002)(6116002)(476003)(486006)(256004)(186003)(790700001)(508600001)(606006)(14454004)(5660300002)(446003)(966005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0343; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: klkEsmPaJ+4KXyYtzG+wdrrozbi8BgUcCMol6Je4PAcU/UtSkXBX8YE62v74brXQi0uIfCh+4hGlitBW34s58E8pZiVOzSvu1JURwvvZifLy0oXK/EzoI93qgxbLZE84p55zbvd9/BMCtLTw89Bb5wuUXTAr+jCRaFgMfd5daJhmPfO34Zxz5xi1VFz9J0Xe4VJoYH/2370a8bpYXMJzTx8a61gY0CtNOUmWIfu12OHxY1wWZd8ToCfftVbU5kGx95fobh3oEQG9FZvFVKwSwg2LJx3DV53kH4tesBzxjUW63tDfD5W1fwmyz0v5slYTcf8HnqYoLAaURPurEwB40t7wLRHH+ml62x5R401EhjTQWSchrJFQ7Ch/LjboyjGwSbKjvy3ccXX89wuaQb5arj4EnRZMif9LyUYtLfEBIks= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB098393D7F57638CC93A6BD5BDAEE0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: befaf6a3-6ebe-47e7-3857-08d6f0dbf509 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 15:21:21.7448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0343 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 14 Jun 2019 15:21:29 -0000 --_000_CY4PR22MB098393D7F57638CC93A6BD5BDAEE0CY4PR22MB0983namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's problematic, because it's the issuer's infrastructure that dictates = the CID size it needs to receive. A real implementation isn't just making = these up for fun. If a peer says they can't tolerate CIDs of the size the = infrastructure uses, the answer will likely be something along the lines of= "too (expletive) bad," and we'll be introducing fragmentation into interop= erability. I don't think that's a good solution. If we feel like we need to constrain this, perhaps a better mitigation woul= d be to advertise the number of bytes you're willing to allocate to trackin= g the CIDs rather than the static count we do now. Then a server with larg= e CIDs will issue fewer to you at a time, while a server with small CIDs co= uld issue many more. However, that only constrains resource exhaustion; it= doesn't address Dmitri's point about code efficiency. From: QUIC On Behalf Of Philipp S. Tiesel Sent: Friday, June 14, 2019 1:34 AM To: Dmitri Tikhonov Cc: Marten Seemann ; Lars Eggert = ; QUIC WG ; Christian Huitema ; Martin = Thomson Subject: Re: Consensus Call: More Connection ID Space #2736 On 13. Jun 2019, at 19:54, Dmitri Tikhonov > wrote: On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: Besides the obvious inefficiency, which is only born by the implementations that actually decide to make use of these long connection IDs (or rather, by their peers), The peer can provide CIDs of any size via NEW_CONNECTION_ID, so unless an implementation throws longs CIDs out, it has to support long CIDs. In addition, a server has no choice but to support maximum-size ODCID. We could make the maximum SCID LEN a transport parameter and make it an error to extend the connection ID beyond this value. Together with a sane minimal CID a server has to support, this mitigates evil clients that try to exhaust resources at the server without limiting the client. If we have such a mechanism, we can allow the full 255 byte connection IDs for special purpose use cases that presume they need such lo= ng CIDs There are trade-offs: 1. Make its cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs. This has large memory overhead but it is simple and has good locality of refence. 2. Make cid_t a variable-size object. This saves memory overall, but is more complicated and likely slower (two memory accesses to get CID). 3. Have two types: peer_cid_t that can be any size and my_cid_t that supports CIDs of fixed length picked by the implementation. This is even more complicated. To summarize, the maximum CID length affects all implementations. - Dmitri. AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ --_000_CY4PR22MB098393D7F57638CC93A6BD5BDAEE0CY4PR22MB0983namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s problematic, because it’s the iss= uer’s infrastructure that dictates the CID size it needs to receive.&= nbsp; A real implementation isn’t just making these up for fun. = If a peer says they can’t tolerate CIDs of the size the infrastructu= re uses, the answer will likely be something along the lines of “too (e= xpletive) bad,” and we’ll be introducing fragmentation into int= eroperability.  I don’t think that’s a good solution.=

 

If we feel like we need to constrain this, perhaps a= better mitigation would be to advertise the number of bytes you’re w= illing to allocate to tracking the CIDs rather than the static count we do = now.  Then a server with large CIDs will issue fewer to you at a time, while a server with small CIDs could issue m= any more.  However, that only constrains resource exhaustion; it doesn= ’t address Dmitri’s point about code efficiency.

 

From: QUIC <quic-bounces@ietf.org> O= n Behalf Of Philipp S. Tiesel
Sent: Friday, June 14, 2019 1:34 AM
To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Lars Eggert <= lars@eggert.org>; QUIC WG <quic@ietf.org>; Christian Huitema <h= uitema@huitema.net>; Martin Thomson <mt@lowentropy.net>
Subject: Re: Consensus Call: More Connection ID Space #2736

 

 



On 13. Jun 2019, at 19:54, Dmitri Tikhonov <dtikhonov@litespeedtech.com&g= t; wrote:

 

On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten= Seemann wrote:

Besides the obvious inefficiency, which is only born= by the
implementations that actually decide to make use of these long
connection IDs (or rather, by their peers),


The peer can provide CIDs of any size via NEW_CONNECTION_ID, so
unless an implementation throws longs CIDs out, it has to support
long CIDs.  In addition, a server has no choice but to support
maximum-size ODCID.

 

We could make the maximum SCID LEN a transport param= eter and 

make it an error to extend the connection ID beyond = this value.

Together with a sane minimal CID a server has to sup= port, this 

mitigates evil clients that try to exhaust resources= at the

server without limiting the client.

 

If we have such a mechanism, we can allow the full 2= 55 byte

connection IDs for special purpose use cases that pr= esume they need such long CIDs

 

 


There are trade-offs:

   1. Make its cid_t a fixed-size object that can fit the       largest CID and eat the overhead for al= l CIDs.  This
      has large memory overhead but it is sim= ple and has
      good locality of refence.

   2. Make cid_t a variable-size object.  This saves me= mory
      overall, but is more complicated and li= kely slower
      (two memory accesses to get CID).

   3. Have two types: peer_cid_t that can be any size and       my_cid_t that supports CIDs of fixed le= ngth picked by
      the implementation.  This is even = more complicated.

To summarize, the maximum CID length affects all implementations.

 - Dmitri.

 

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

 

--_000_CY4PR22MB098393D7F57638CC93A6BD5BDAEE0CY4PR22MB0983namp_-- From nobody Sat Jun 15 06:04:53 2019 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 E6B001200A3 for ; Sat, 15 Jun 2019 06:04:51 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y-VIHpTBLAY for ; Sat, 15 Jun 2019 06:04:50 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 7B7F41200A1 for ; Sat, 15 Jun 2019 06:04:49 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id m23so5019397lje.12 for ; Sat, 15 Jun 2019 06:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wq1bNZ8uosgfqaGsWeyV6UC0wB51MXLF0dF9JtEy4oE=; b=BhTG8L7LVHQ5m0qRLlYUfIsacmfvVU0l65tOAQlnSUb8pdxkVSXHhVbr291KG6UBnF Y6S2nt2vDyNQ/7UTWeK8z/ANTkiujRGAMZgzex8IVpByPTlzO91NRzvfUbdP9av6Dy7l ULLlcq0hv6ffl/nZUz6Y4UQuqYSoi6rDRg7UmHSqz63ret1ZEFaz6+/i/Sceh61Goung 7oAQcBnkNTrrCH7GU9kahc0Hq76UtyFERZkyVpulCj4XxQk8YIqjI8O6vGsGGyC+IhRK nR8mTKSBVzhG2E1quJlif0DqB5d4OajUV2GT5zEfkKqHhVDbyNqGD8DXZtunAdW6vxZh llhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wq1bNZ8uosgfqaGsWeyV6UC0wB51MXLF0dF9JtEy4oE=; b=aULVZ+WWOlnZc/sg74qlPHKjuCatA0yrft+MVdiQolZQpbjri4Emw10aqr/Mz76FWt P4F34FLwoG5tTLFQ3im+m9/KBOuwNoKG+ehke6IIX3fU1LrBcMqwhwGD3Fv3h7aCLgF+ GBf5iNkXxJpgLtelnV4ES+iukJxF5zQcRzC+UnjBjf4qcSDwvxD+27qRpqfRyvgOnMBN t36r72bP6YcLU1FCAUiXdVFFtMerQxdSZnddd002EYOZhiJDOQW1NJ89PSK9+0Jow/Ia aEt76cjZ538CcBBNiQjKEhmdMTVl1vcK6iaD2qct8CLXv8vLoUSsSFr0h74ZBgnmEHpE dXzw== X-Gm-Message-State: APjAAAWiYSSHgR9IBUPqxjs3KllaD/z+Y69gFp00Z6/E9L2AHA+/9ldR TKJ/qHl3EFbkARMp6w1u7gjBPQGLU6HAI3wEASJi1w== X-Google-Smtp-Source: APXvYqwE5DHtcY8A4Uqvyvc0Z7UqktK07UEXUFsaUJUdaXEZKAQfCgYLkVIuqDlktuhOBJrAWW8UI3OfcEDD7jTZ+BY= X-Received: by 2002:a2e:96d0:: with SMTP id d16mr43276049ljj.14.1560603887544; Sat, 15 Jun 2019 06:04:47 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> In-Reply-To: From: Eric Rescorla Date: Sat, 15 Jun 2019 06:04:10 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: David Schinazi Cc: Marten Seemann , Lars Eggert , QUIC WG , Christian Huitema , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000005a3e41058b5c68c3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jun 2019 13:04:52 -0000 --0000000000005a3e41058b5c68c3 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 13, 2019 at 10:01 AM David Schinazi wrote: > I'm realizing the PR makes two changes and one might get better consensus > than the other. > (1) Change the encoding of connection ID lengths in long headers (and > invariants) > (2) Change the maximum allowed connection ID length in QUICv1 from 18 to 48 > For the record, I am in favor of both changes. I personally believe (1) is important and time-sensitive. The QUIC > invariants will be with us for a long time, and it would be unfortunate to > be stuck with {0, [3-18]} forever. The only downside is spending one extra > byte on long headers and I think that's acceptable. > > Perhaps we could: > - make this PR only change (1) > - have the consensus call only discuss (1) > - merge (1) if there is consensus > - wait for progress on the stateless reset length issue (#2770) > > - decide together if we want to change the maximum connection ID length in > QUICv1 to something higher than 18 > > How do people feel about this? > I can live with this, but it would not be my preference. -Ekr > David > > > On Wed, Jun 12, 2019 at 11:57 PM Marten Seemann > wrote: > >> I'm not really happy with the new proposal. 18 bytes is a lot of overhead >> already, and having a connection ID of 48 bytes will be an even larger >> overhead for QUIC packets (around 4% assuming a packet size of 1250 bytes). >> >> Besides the obvious inefficiency, which is only born by the >> implementations that actually decide to make use of these long connection >> IDs (or rather, by their peers), there are two other downsides to this >> proposal, which affect all QUIC implementations: >> 1. Since only 48 out of the 256 length values are permitted in QUIC v1, >> and we don't have any greasing scheme, these bits are likely to ossify >> pretty quickly. >> 2. As pointed out in #2770, this change makes stateless resets a lot less >> useful than they used to be, and the best mitigation seems to be to require >> large amounts of padding for small QUIC packets. >> >> On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema >> wrote: >> >>> >>> > On Jun 12, 2019, at 10:40 PM, Lars Eggert wrote: >>> > >>> > Personally, I'm somewhat disappointed about how much we feel we need >>> to cater to the needs/desires of the current state-of-the-art in >>> large-scale load balancers. 18 bytes was IMO already quite a lot, and 256 >>> bytes seems completely over the top. I really wonder if this will all be >>> pointless with next-gen LB designs. >>> >>> +1 >>> >>> My gut feeling is that if we adopted a 16 bytes limit, load balancers >>> would just deal with it. Maybe pick symmetric encryption algorithms with >>> shorter blocks, or some kind a hierarchical scheme. >>> >>> But I have a hard time reconciling the emotion around shorter encoding >>> of ack delays and the willingness to add 32 bytes of overhead in the packet >>> headers. >>> >>> -- Christian Huitema >>> >> --0000000000005a3e41058b5c68c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 13, 2019 at 10:01 AM Davi= d Schinazi <dschinazi.ietf@g= mail.com> wrote:
I'm realizing the PR makes two changes and one= might get better consensus than the other.
(1) Change the encoding of = connection ID lengths in long headers (and invariants)
(2) Change= the maximum allowed connection ID length in QUICv1 from 18 to 48

For the record, I am in favor of both ch= anges.

I personally believe (1) is important and time-sens= itive. The QUIC invariants will be with us for a long time, and it would be= unfortunate to be stuck with {0, [3-18]} forever. The only downside is spe= nding one extra byte on long headers and I think that's acceptable.

Perhaps we could:
- make this PR only chang= e (1)
- have the consensus call only discuss (1)
- merg= e (1) if there is consensus
- wait for progress on the state= less reset length issue (#2770)=C2=A0
- decide together if we= want to change the maximum connection ID length in QUICv1 to something hig= her than 18

How do people feel about this?

I can live with this, but it would not= be my preference.

-Ekr


David


On Wed, Jun 12, 2019 at 11:57 PM Marten See= mann <marte= nseemann@gmail.com> wrote:
I'm not really happy with the new pr= oposal. 18 bytes is a lot of overhead already, and having a connection ID o= f 48 bytes will be an even larger overhead for QUIC packets (around 4% assu= ming a packet size of 1250 bytes).=C2=A0

Besides the obvious i= nefficiency, which is only born by the implementations that actually decide= to make use of these long connection IDs (or rather, by their peers), ther= e are two other downsides to this proposal, which affect all QUIC implement= ations:
1. Since only 48 out of the 256 length values are permitt= ed in QUIC v1, and we don't have any greasing scheme, these bits are li= kely to ossify pretty quickly.
2. As pointed out in #2770, this c= hange makes stateless resets a lot less useful than they used to be, and th= e best mitigation seems to be to require large amounts of padding for small= QUIC packets.

On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema= <huitema@huite= ma.net> wrote:

> On Jun 12, 2019, at 10:40 PM, Lars Eggert <lars@eggert.org> wrote:
>
> Personally, I'm somewhat disappointed about how much we feel we ne= ed to cater to the needs/desires of the current state-of-the-art in large-s= cale load balancers. 18 bytes was IMO already quite a lot, and 256 bytes se= ems completely over the top. I really wonder if this will all be pointless = with next-gen LB designs.

+1

My gut feeling is that if we adopted a 16 bytes limit, load balancers would= just deal with it. Maybe pick symmetric encryption algorithms with shorter= blocks, or some kind a hierarchical scheme.

But I have a hard time reconciling the emotion around shorter encoding of a= ck delays and the willingness to add 32 bytes of overhead in the packet hea= ders.

-- Christian Huitema
--0000000000005a3e41058b5c68c3-- From nobody Sat Jun 15 06:22:12 2019 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 838D8120073 for ; Sat, 15 Jun 2019 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 L3EG8FXmDrrK for ; Sat, 15 Jun 2019 06:22:09 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 1A7DD120020 for ; Sat, 15 Jun 2019 06:22:09 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id 8so1890086uaz.11 for ; Sat, 15 Jun 2019 06:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XNCXo9isZO03x9Vvr+2zJqxDwWqtiGiBj98EAssCp+Q=; b=B/MroyrteMtF8NqMdPZumgZhJtzAiCmXxcUmOpMjLV1HL9IxxXqG/HyP/fNgdqeged UCBZ/hYgsE6szSHyw3/p+Z/i7b6wG6dM2j3izy3j/XxwLFeUKQARyIL0+5+0m5todgNE t6AI+Je5JxXMPWh88aPuCdNCsTosvIxAAcHeMCHjkYCZgWDmYXfn/e0FWgyI0vr9R4mw oMst4F7LvZhiA67Re9FGUoXLJkLFa6mhFzCzklI13rBDFqgVv7bHOf30ajjGlN5xbY3p kIg5/oyweDDfd7fjEp5O3LpjHjLhfqDsfTKt7UN3Oqmut9V//mSCqsQDJfkT4gv1e94h Yeew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XNCXo9isZO03x9Vvr+2zJqxDwWqtiGiBj98EAssCp+Q=; b=AAwl53ZPWM3B2FFRxUbvnc1+NAN0f7p/HtkoYYEUvqrG2TYfjB04ayflOpOXq/cN9I cY3XNGwuiz9eZvoamdQb/ZbPutbF8BYBRHw3jg7Dzk8Ab9XP22Pxx6T9by9wU44Xjz4O hDXkLnFbeqV/38NbDlBb9FiBvJKK8edm+j9RnQfi0WvHcjJtxreYhIe4oDa93dU/A7MB y7FrKGxPXvdCDkAxxitOkT6av6quAIi1nCM4RaydqDBkOyhUtXS6PPdl9eI1q5p5vpJL DIyPdA2SMMUi19z5GGphRUdeRojuZESwzod3yB867UsmCksDI97aeGS3HF3hB6U2MYfW iM2A== X-Gm-Message-State: APjAAAU0RXBl8ywQqo1YWuEPBwZn7+HdH4PezvmmYQmOScrVtuE+AV6J kcKWA3DOEpHRhQDxsrWf6KU70MSzdsClneA3Jok= X-Google-Smtp-Source: APXvYqxcGhdCqFScRDosjG6pJSAIuJM4awLkYcYomlGqhjeM6WOhz39sbxTPxhosYCJ7/MOkuEzRu/iW6hNPx/4xHE0= X-Received: by 2002:ab0:3406:: with SMTP id z6mr16364611uap.102.1560604928033; Sat, 15 Jun 2019 06:22:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Sat, 15 Jun 2019 13:43:55 +0100 Message-ID: Subject: Re: Analysing the HTTP/3 error code space To: Kazuho Oku Cc: Mike Bishop , Martin Duke , Ian Swett , QUIC WG Content-Type: multipart/alternative; boundary="0000000000005ec973058b5ca637" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jun 2019 13:22:11 -0000 --0000000000005ec973058b5ca637 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you all for the input. Seeing some support, with valuable suggestions, I will start on a series of issues/PRs to let us refine the specifics. On Wed, 12 Jun 2019, 03:43 Kazuho Oku, wrote: > 2019=E5=B9=B46=E6=9C=8812=E6=97=A5(=E6=B0=B4) 6:41 Mike Bishop : > > > > I was previously affiliated with an HTTP stack that I assume still need= s > HTTP_VERSION_FALLBACK for some corner cases including, but not limited to= , > renegotiation. This WG previously had a discussion about whether it shou= ld > fall back to HTTP/2 (logical, but likely has all the same incompatible > scenarios that HTTP/3 does) or HTTP/1.1, and concluded that it would be s= ad > to make someone fall from 3 -> 2 -> 1.1 when probably can=E2=80=99t answe= r over > anything higher than 1.1 anyway. > > > > > > > > > 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3 > error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no singl= e > equivalent, which I think is incorrect becuase HTTP/3 has > HTTP_GENERAL_PROTOCOL_ERROR. > > > > > > > > Mostly because the various MALFORMED_FRAME errors would also have been > PROTOCOL_ERROR in HTTP/2. We could make the text point to GPE, while > noting that specific error codes have been added for certain situations. > > > > > > > > > 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and ver= y > similar. The former is used by a peer that receives a valid frame on a > stream that it should never be sent on, the latter is used by a peer that > receives a valid frame on a stream that is normally ok but has transition= ed > to an application-level stream state which prohibits it. > > > > > Rationalising these seems like a logical option. > > > > > > > > Seems reasonable. I believe there was previous discussion about > possibly combining them, but I can=E2=80=99t find it with a cursory searc= h. > > > > > > > > > 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case= , > a client send NUM_PLACEHOLDER. Declassifying this as an error seems like = a > sensile option. This frees up error code 0x1, which we can move > HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2). > > > > > 7) There are several error cases related to SETTINGS; a frame that ca= n > be sent most once per connection. I made a proposal to address this on > issue #2783 [3] > > > > > > > > I need to think more about the proposal in #2783, but that=E2=80=99s > semi-orthogonal to the error conversation. I like the suggestion from th= e > interim to consolidate these to a more general INVALID_SETTINGS error, > though if we go the route of #2783, that might become a STREAM_HEADER_ERR= OR > =C3=A0 la (8). > > > > > > > > > 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar > but may be useful to understand the different reason that clients reject > server push. This is extra fidelity on top of HTTP/2. > > > > > 4) There are several error codes related to handling requests and > > > > responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, > HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than > HTTP/2 provided. This may extra information may allow endpoints to make > smarter decisions about retrying requests. However, it may also be possib= le > to infer things from a stream error that contains simply HTTP_NO_ERROR ( > HTTP_EARLY_RESPONSE could benefit from this) > > > > > > > > We need the CANCELLED/REJECTED split to understand when a server is > declaring that no processing occurred versus reflecting back the error co= de > from the client=E2=80=99s STOP_SENDING in a RESET_STREAM. (The resolutio= n to that > is that clients don=E2=80=99t send REJECTED, and it has the additional se= mantic > when coming from a server.) If we didn=E2=80=99t have INCOMPLETE_REQUEST= , I=E2=80=99m > unsure what we=E2=80=99d send in that situation instead; it=E2=80=99s cer= tainly not a > NO_ERROR situation. > > > > > > > > Folding EARLY_RESPONSE into NO_ERROR would be reasonable. > > > > > > > > > 5) The error code guidance is often not symmetric. Client or servers > use error codes differently and little guidance is provided on how to > process an error code that in theory should never be sent. > > > > > > > > The only possible response is blowing up the connection, isn=E2=80=99t = it? > Which is superfluous if you=E2=80=99ve received a nonsensical connection = error, > because the connection is already being blown up by the peer. So the mor= e > scoped question is, if a stream sees a RESET/STOP_SENDING with an error > code that a) should only have originated from your side, or b) can only b= e > a connection error, what do you do? > > > > > > > > > 6) There is little guidance on how an intermediary that translates > between HTTP/2 and HTTP/3 should map these divergent error code spaces. I= t > would pay to align them as close as possible and provide some guidance on > how to map higher fidelity codes to lower fidelity codes. > > > > > > > > That=E2=80=99s a good point. However, error codes are hop-to-hop =E2= =80=93 I suspect > that any error code gets turned into a status code 502, with the possible > exception of REJECTED. Do expect anyone to build a 2/3 intermediary who > isn=E2=80=99t also terminating the HTTP semantic layer? > > Not that we do now as a proxy implementation, but I think it would be > preferable to propagate "temporary" errors (REFUSED_STREAM), and also > CONNECT_ERROR to indicate reset of a websocket connection. For all > other errors I think that 502 can be used. > > It might be worth clarifying that such behavior is to be expected (or > preferable). > > > > > > > > > > 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing > the unidirectional stream type header. We might be able to merge these in= to > a error such as HTTP_STREAM_HEADER_ERROR and state the code has different > applicability between STOP_SENDING and CONNECTION_CLOSE frames. > > > > > 9) Critical streams such as control stream and QPACK streams can be > created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams ca= n > only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures this= . > We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could ev= en > incorporate suggestion 8. > > > > > > > > DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same > Push ID. Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR seems > like a reasonable collation; I agree that those are ultimately the same > proposal. > > > > > > > > > > > > From: QUIC On Behalf Of Martin Duke > > Sent: Tuesday, June 11, 2019 12:37 PM > > To: Lucas Pardue > > Cc: Ian Swett ; QUIC WG > > Subject: Re: Analysing the HTTP/3 error code space > > > > > > > > I would insist on INTERNAL_ERROR. It is great for various malloc > problems, as well as for signalling that something went wrong on the back > end in proxy scenarios. It is a catch-all for "I screwed up and can't > continue". > > > > > > > > On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue < > lucaspardue.24.7@gmail.com> wrote: > > > > Hey Ian, > > > > On Tue, Jun 11, 2019 at 7:14 PM Ian Swett wrote: > > > > > >> > > >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has bee= n > > >> replaced by HTTP_MALFORMED_FRAME, which actually covers a range of > > >> values - it dedicates a byte to encode the frame type. This is > > >> problematic since the frame type changed to be a 62-bit integer > > >> itself. In my personal opinion, this error code is more complicated > > >> than needs be and was incorrectly applied. Issue #2551 [1] captures > > >> this, and PR #2662 [2] contains a proposed set of replacement codes. > > >> That PR adds 4 error codes to bring the total up to 28. > > > > > > > > > I like your proposed PR. > > > > Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for > > things that are frame size errors) and adds some new error codes in > > agreement with our current philosophy. I would refine the PR to agree > > with the outcome of this thread. > > > > > > > > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which > are never used? I'm unclear on what the intended usage is? > > > > I realised I didn't qualify one aspect of my analysis - the guidance > > count metric is only one signal. HTTP_INTERNAL_ERROR is described as > > "An internal error has occurred in the HTTP stack.", which feels like > > an implementation-oriented error code. I think it is valid in staying > > in HTTP/3, especially if it is used in HTTP/2 (I don't have data to > > hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; > > it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is > > only recommended when the server wants to use TLS renegotiation. IMO > > it is of limited value unless we import the same behaviour into > > HTTP/3. > > > > -- > Kazuho Oku > --0000000000005ec973058b5ca637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for the input.

<= div dir=3D"auto">Seeing some support, with valuable suggestions, I will sta= rt on a series of issues/PRs to let us refine the specifics.=C2=A0



On Wed, 12 Jun 2019,= 03:43 Kazuho Oku, <kazuhooku@gma= il.com> wrote:
2019=E5=B9=B4= 6=E6=9C=8812=E6=97=A5(=E6=B0=B4) 6:41 Mike Bishop <mbishop@evequefou.b= e>:
>
> I was previously affiliated with an HTTP stack that I assume still nee= ds HTTP_VERSION_FALLBACK for some corner cases including, but not limited t= o, renegotiation.=C2=A0 This WG previously had a discussion about whether i= t should fall back to HTTP/2 (logical, but likely has all the same incompat= ible scenarios that HTTP/3 does) or HTTP/1.1, and concluded that it would b= e sad to make someone fall from 3 -> 2 -> 1.1 when probably can=E2=80= =99t answer over anything higher than 1.1 anyway.
>
>
>
> > 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HT= TP/3 error codes. However, it states that HTTP/2's PROTOCOL_ERROR has n= o single equivalent, which I think is incorrect becuase HTTP/3 has HTTP_GEN= ERAL_PROTOCOL_ERROR.
>
>
>
> Mostly because the various MALFORMED_FRAME errors would also have been= PROTOCOL_ERROR in HTTP/2.=C2=A0 We could make the text point to GPE, while= noting that specific error codes have been added for certain situations. >
>
>
> > 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and= very similar. The former is used by a peer that receives a valid frame on = a stream that it should never be sent on, the latter is used by a peer that= receives a valid frame on a stream that is normally ok but has transitione= d to an application-level stream state which prohibits it.
>
> > Rationalising these seems like a logical option.
>
>
>
> Seems reasonable.=C2=A0 I believe there was previous discussion about = possibly combining them, but I can=E2=80=99t find it with a cursory search.=
>
>
>
> > 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one = case, a client send NUM_PLACEHOLDER. Declassifying this as an error seems l= ike a sensile option. This frees up error code 0x1, which we can move HTTP_= GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2).
>
> > 7) There are several error cases related to SETTINGS; a frame tha= t can be sent most once per connection. I made a proposal to address this o= n issue #2783 [3]
>
>
>
> I need to think more about the proposal in #2783, but that=E2=80=99s s= emi-orthogonal to the error conversation.=C2=A0 I like the suggestion from = the interim to consolidate these to a more general INVALID_SETTINGS error, = though if we go the route of #2783, that might become a STREAM_HEADER_ERROR= =C3=A0 la (8).
>
>
>
> > 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very simi= lar but may be useful to understand the different reason that clients rejec= t server push. This is extra fidelity on top of HTTP/2.
>
> > 4) There are several error codes related to handling requests and=
>
> responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, HTTP_EARLY= _RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than HTTP/2 prov= ided. This may extra information may allow endpoints to make smarter decisi= ons about retrying requests. However, it may also be possible to infer thin= gs from a stream error that contains simply HTTP_NO_ERROR ( HTTP_EARLY_RESP= ONSE could benefit from this)
>
>
>
> We need the CANCELLED/REJECTED split to understand when a server is de= claring that no processing occurred versus reflecting back the error code f= rom the client=E2=80=99s STOP_SENDING in a RESET_STREAM.=C2=A0 (The resolut= ion to that is that clients don=E2=80=99t send REJECTED, and it has the add= itional semantic when coming from a server.)=C2=A0 If we didn=E2=80=99t hav= e INCOMPLETE_REQUEST, I=E2=80=99m unsure what we=E2=80=99d send in that sit= uation instead; it=E2=80=99s certainly not a NO_ERROR situation.
>
>
>
> Folding EARLY_RESPONSE into NO_ERROR would be reasonable.
>
>
>
> > 5) The error code guidance is often not symmetric. Client or serv= ers use error codes differently and little guidance is provided on how to p= rocess an error code that in theory should never be sent.
>
>
>
> The only possible response is blowing up the connection, isn=E2=80=99t= it?=C2=A0 Which is superfluous if you=E2=80=99ve received a nonsensical co= nnection error, because the connection is already being blown up by the pee= r.=C2=A0 So the more scoped question is, if a stream sees a RESET/STOP_SEND= ING with an error code that a) should only have originated from your side, = or b) can only be a connection error, what do you do?
>
>
>
> > 6) There is little guidance on how an intermediary that translate= s between HTTP/2 and HTTP/3 should map these divergent error code spaces. I= t would pay to align them as close as possible and provide some guidance on= how to map higher fidelity codes to lower fidelity codes.
>
>
>
> That=E2=80=99s a good point.=C2=A0 However, error codes are hop-to-hop= =E2=80=93 I suspect that any error code gets turned into a status code 502= , with the possible exception of REJECTED.=C2=A0 Do expect anyone to build = a 2/3 intermediary who isn=E2=80=99t also terminating the HTTP semantic lay= er?

Not that we do now as a proxy implementation, but I think it would be
preferable to propagate "temporary" errors (REFUSED_STREAM), and = also
CONNECT_ERROR to indicate reset of a websocket connection. For all
other errors I think that 502 can be used.

It might be worth clarifying that such behavior is to be expected (or
preferable).

>
>
>
> > 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to par= sing the unidirectional stream type header. We might be able to merge these= into a error such as HTTP_STREAM_HEADER_ERROR and state the code has diffe= rent applicability between STOP_SENDING and CONNECTION_CLOSE frames.
>
> > 9) Critical streams such as control stream and QPACK streams can = be created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams c= an only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures thi= s. We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could e= ven incorporate suggestion 8.
>
>
>
> DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same P= ush ID.=C2=A0 Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR see= ms like a reasonable collation; I agree that those are ultimately the same = proposal.
>
>
>
>
>
> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Du= ke
> Sent: Tuesday, June 11, 2019 12:37 PM
> To: Lucas Pardue <lucaspardue.24.7@gmail.com>
> Cc: Ian Swett <ianswett@google.com>; QUIC WG <quic@ietf.org>
> Subject: Re: Analysing the HTTP/3 error code space
>
>
>
> I would insist on INTERNAL_ERROR. It is great for various malloc probl= ems, as well as for signalling that something went wrong on the back end in= proxy scenarios. It is a catch-all for "I screwed up and can't co= ntinue".
>
>
>
> On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue <lucaspardue.= 24.7@gmail.com> wrote:
>
>=C2=A0 Hey Ian,
>
> On Tue, Jun 11, 2019 at 7:14 PM Ian Swett <ianswett@google.com= > wrote:
> >
> >>
> >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code = has been
> >> replaced by HTTP_MALFORMED_FRAME, which actually covers a ran= ge of
> >> values - it dedicates a byte to encode the frame type. This i= s
> >> problematic since the frame type changed to be a 62-bit integ= er
> >> itself.=C2=A0 In my personal opinion, this error code is more= complicated
> >> than needs be and was incorrectly applied. Issue #2551 [1] ca= ptures
> >> this, and PR #2662 [2] contains a proposed set of replacement= codes.
> >> That PR adds 4 error codes to bring the total up to 28.
> >
> >
> > I like your proposed PR.
>
> Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for<= br> > things that are frame size errors) and adds some new error codes in > agreement with our current philosophy. I would refine the PR to agree<= br> > with the outcome of this thread.
>
> >
> > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, wh= ich are never used?=C2=A0 I'm unclear on what the intended usage is? >
> I realised I didn't qualify one aspect of my analysis - the guidan= ce
> count metric is only one signal. HTTP_INTERNAL_ERROR is described as > "An internal error has occurred in the HTTP stack.", which f= eels like
> an implementation-oriented error code. I think it is valid in staying<= br> > in HTTP/3, especially if it is used in HTTP/2 (I don't have data t= o
> hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; > it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 i= s
> only recommended when the server wants to use TLS renegotiation. IMO > it is of limited value unless we import the same behaviour into
> HTTP/3.



--
Kazuho Oku
--0000000000005ec973058b5ca637-- From nobody Sat Jun 15 07:14:33 2019 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 4C91E120073 for ; Sat, 15 Jun 2019 07:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 iBSb_3QEF-Jt for ; Sat, 15 Jun 2019 07:14:28 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 908FC12001A for ; Sat, 15 Jun 2019 07:14:26 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x5FEE7rl004813 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 15 Jun 2019 16:14:07 +0200 Received: from [2001:bf0:c801:101:3145:f28b:e595:e219] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hc9Pg-0005wZ-DB; Sat, 15 Jun 2019 16:12:12 +0200 From: "Philipp S. Tiesel" Message-Id: <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9BCB4550-439B-409B-90A3-D3A3F23E1695" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Call: More Connection ID Space #2736 Date: Sat, 15 Jun 2019 16:14:05 +0200 In-Reply-To: Cc: Dmitri Tikhonov , Marten Seemann , Lars Eggert , QUIC WG , Christian Huitema , Martin Thomson To: Mike Bishop References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jun 2019 14:14:30 -0000 --Apple-Mail=_9BCB4550-439B-409B-90A3-D3A3F23E1695 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HI > On 14. Jun 2019, at 17:21, Mike Bishop wrote: >=20 > That=E2=80=99s problematic, because it=E2=80=99s the issuer=E2=80=99s = infrastructure that dictates the CID size it needs to receive. A real = implementation isn=E2=80=99t just making these up for fun. If a peer = says they can=E2=80=99t tolerate CIDs of the size the infrastructure = uses, the answer will likely be something along the lines of =E2=80=9Ctoo = (expletive) bad,=E2=80=9D and we=E2=80=99ll be introducing fragmentation = into interoperability. I don=E2=80=99t think that=E2=80=99s a good = solution. I think it depends weather you see this as a symmetric or a asymmetric = problem: - If it is just about server resource exhaustion and code efficiency on = the server side, such a parameter could help. - For the symmetric case, where also the client could constrain the CID = length used by the server, I share your concerns unless we recommend = some very large default CID as minimum. > =20 > If we feel like we need to constrain this, perhaps a better mitigation = would be to advertise the number of bytes you=E2=80=99re willing to = allocate to tracking the CIDs rather than the static count we do now. = Then a server with large CIDs will issue fewer to you at a time, while a = server with small CIDs could issue many more. However, that only = constrains resource exhaustion; it doesn=E2=80=99t address Dmitri=E2=80=99= s point about code efficiency. > =20 > From: QUIC On Behalf Of Philipp S. Tiesel > Sent: Friday, June 14, 2019 1:34 AM > To: Dmitri Tikhonov > Cc: Marten Seemann ; Lars Eggert = ; QUIC WG ; Christian Huitema = ; Martin Thomson > Subject: Re: Consensus Call: More Connection ID Space #2736 > =20 > =20 >=20 >=20 > On 13. Jun 2019, at 19:54, Dmitri Tikhonov = > = wrote: > =20 > On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: >=20 > Besides the obvious inefficiency, which is only born by the > implementations that actually decide to make use of these long > connection IDs (or rather, by their peers), >=20 > The peer can provide CIDs of any size via NEW_CONNECTION_ID, so > unless an implementation throws longs CIDs out, it has to support > long CIDs. In addition, a server has no choice but to support > maximum-size ODCID. > =20 > We could make the maximum SCID LEN a transport parameter and=20 > make it an error to extend the connection ID beyond this value. > Together with a sane minimal CID a server has to support, this=20 > mitigates evil clients that try to exhaust resources at the > server without limiting the client. > =20 > If we have such a mechanism, we can allow the full 255 byte > connection IDs for special purpose use cases that presume they need = such long CIDs > =20 > =20 >=20 > There are trade-offs: >=20 > 1. Make its cid_t a fixed-size object that can fit the > largest CID and eat the overhead for all CIDs. This > has large memory overhead but it is simple and has > good locality of refence. >=20 > 2. Make cid_t a variable-size object. This saves memory > overall, but is more complicated and likely slower > (two memory accesses to get CID). >=20 > 3. Have two types: peer_cid_t that can be any size and > my_cid_t that supports CIDs of fixed length picked by > the implementation. This is even more complicated. >=20 > To summarize, the maximum CID length affects all implementations. >=20 > - Dmitri. >=20 >=20 > =20 > AVE! > Philipp S. Tiesel >=20 > --=20 > Philipp S. Tiesel=20 > https://philipp.tiesel.net/ AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_9BCB4550-439B-409B-90A3-D3A3F23E1695 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HI

On 14. Jun 2019, at 17:21, Mike Bishop <mbishop@evequefou.be> wrote:

That=E2=80=99= s problematic, because it=E2=80=99s the issuer=E2=80=99s infrastructure = that dictates the CID size it needs to receive.  A real = implementation isn=E2=80=99t just making these up for fun.  If a = peer says they can=E2=80=99t tolerate CIDs of the size the = infrastructure uses, the answer will likely be something along the lines = of =E2=80=9Ctoo (expletive) bad,=E2=80=9D and we=E2=80=99ll be = introducing fragmentation into interoperability.  I don=E2=80=99t = think that=E2=80=99s a good = solution.

I = think it depends weather you see this as a symmetric or a asymmetric = problem:
 - If it is just about server resource = exhaustion and code efficiency on the server side, such a parameter = could help.
 - For the symmetric case, where also the = client could constrain the CID length used by the server, I share your = concerns unless we recommend some very large default CID as = minimum.

 
If we feel like we need to constrain = this, perhaps a better mitigation would be to advertise the number of = bytes you=E2=80=99re willing to allocate to tracking the CIDs rather = than the static count we do now.  Then a server with large CIDs = will issue fewer to you at a time, while a server with small CIDs could = issue many more.  However, that only constrains resource = exhaustion; it doesn=E2=80=99t address Dmitri=E2=80=99s point about code = efficiency.
 
From: QUIC <quic-bounces@ietf.org> On Behalf = Of Philipp S. = Tiesel
Sent: Friday, June 14, 2019 1:34 = AM
To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Lars Eggert <lars@eggert.org>; QUIC = WG <quic@ietf.org>; = Christian Huitema <huitema@huitema.net>; Martin Thomson <mt@lowentropy.net>
Subject: Re: Consensus Call: More = Connection ID Space #2736
 
 


On 13. Jun 2019, at 19:54, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
 
On Thu, Jun 13, 2019 at 02:57:05PM = +0800, Marten Seemann wrote:

Besides = the obvious inefficiency, which is only born by the
implementations that actually decide to make use of these = long
connection IDs (or rather, by their peers),

The peer can provide CIDs of any size via = NEW_CONNECTION_ID, so
unless an implementation throws = longs CIDs out, it has to support
long CIDs.  In = addition, a server has no choice but to support
maximum-size= ODCID.
 
We could make the maximum SCID LEN a transport parameter = and 
make it an error to extend the = connection ID beyond this value.
Together with a sane = minimal CID a server has to support, this 
mitigates evil clients that try to exhaust resources at = the
server without limiting the client.
 
If we have such a mechanism, we can = allow the full 255 byte
connection IDs for special = purpose use cases that presume they need such long CIDs
 
 


There are = trade-offs:

   1. Make its = cid_t a fixed-size object that can fit the
      largest CID and eat the = overhead for all CIDs.  This
      has large memory overhead = but it is simple and has
      good locality of = refence.

   2. Make cid_t a = variable-size object.  This saves memory
      overall, but is more = complicated and likely slower
      (two memory accesses to = get CID).

   3. Have two = types: peer_cid_t that can be any size and
      my_cid_t that supports = CIDs of fixed length picked by
      the implementation. =  This is even more complicated.

To = summarize, the maximum CID length affects all implementations.

 - Dmitri.

 
AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/
<= /div>

AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_9BCB4550-439B-409B-90A3-D3A3F23E1695-- From nobody Sat Jun 15 14:14:34 2019 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 C392312012D for ; Sat, 15 Jun 2019 14:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 hUPTugnKjpFR for ; Sat, 15 Jun 2019 14:14:29 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 1FEFB12012A for ; Sat, 15 Jun 2019 14:14:29 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id r16so5931875wrl.11 for ; Sat, 15 Jun 2019 14:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qmPQ9qkGu/QmqF6G8aT4TgtslqT3b1kkUx/YJBe5/U0=; b=UYMx4kujRv5WFxZCVDZaHwidH5ZO3zEOLOCUTzxC+y1s9gWcNT2eZQr49/X6BFZ6UG Ejff7DQsHmts8U6LIxU8d3RiUBcz7+U5u3CHrb5ni/xartS1VARmu/jLDUliuXXeuMWo xd4SBrC4aSWBDSHZurGwRs7jBWxUDR7j+B6AhrBqT4s/lOQU+0XjyKhsuKC43tOp64xD skyaLombzlAdVLXk468pGpc3KuSSXnCtgaX5tQHmkZsMBxl0Ii8HsPJ6Ju0QuK78VOKT k68MRL8Rsoi5ZEmJJ96C8b4/ZncvLf9OZuSjZyZN5bySMiFWKyATKdaGQsd1JqwJgsQR OUqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qmPQ9qkGu/QmqF6G8aT4TgtslqT3b1kkUx/YJBe5/U0=; b=fwNJj5ouw68PosFZjfLf/IKBQS5/BJ2xHbsiFaGlcSqqILhjMVcvqVgPHdKv9lbReN 6Fdln3sTFlXKOOWPMjRWW+cdYwM6HLYx12l1zEeytvS5IXptlXMwwzg9SIaLSmPpitxL 202Aeat+WnrU7YmdSxB7c5byBcCgBA229BtPLLREaPkJcCik7z2YXK7Y3FnUj9G2rKu2 XQp+Pc9enZJ2tZPJR7qPT0chPQPgKkhuoqkpDNAg1B6s0eokxr6YDONF5js1zi5mC0yh It85hqUrSA4H+9zQNPkiKVL1XywzjHKLzBpSoK1JEoLH2/PH7t2Kuxq569zhO4BOK1qy +RNg== X-Gm-Message-State: APjAAAXFUvsl0cSRvzu2+c1NimX5EEBrfuOrBqAdPjcnpKs3R2qkDwz3 UiJZ2HPzpSksONR8G7eaQ8ZiB47nSZK9ecKd028= X-Google-Smtp-Source: APXvYqw/T4+3c3no3TSCKM5Esgkx5trZQeZwNWvISXZ8g1w2p7rihfUlG5uVciMZB2J58z9C08XYPHuJ1JWbjRHkvAQ= X-Received: by 2002:adf:f181:: with SMTP id h1mr469598wro.18.1560633267361; Sat, 15 Jun 2019 14:14:27 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> From: Martin Duke Date: Sat, 15 Jun 2019 14:14:13 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: "Philipp S. Tiesel" Cc: Mike Bishop , Dmitri Tikhonov , Christian Huitema , Marten Seemann , Lars Eggert , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000869b42058b633f6f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 15 Jun 2019 21:14:33 -0000 --000000000000869b42058b633f6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1. I'll chime in to say that a v1 limit of 48 bytes is fairly arbitrary choice, well in excess of any use case we're interested at any time. If there is a number 18 < n < 48 that can gain consensus, I am comfortable with moving to that number. Frankly, we can just barely make 18B work given current use cases, so even sticking to 18 wouldn't derail everything in the short term. I think it was Kazuho that suggested someone might want 2 levels of block encryption, which implies 32B + "a few" more bytes for other stuff, and from there I rounded up to 48. 2. Would a post-quantum world require larger block sizes? If so, the invariants should definitely leave the necessary space. 3. I agree that we are danger of ossifying to block CID lengths > whatever the largest is used in practice, regardless of what the v1 theoretical limit is. However, the answer is not to "pre-ossify" ourselves to ome limit. Allow 255, and if firewalls end up blocking certain use cases, we'll have to deal with that when we come ot it. On Sat, Jun 15, 2019 at 7:14 AM Philipp S. Tiesel wrote: > HI > > On 14. Jun 2019, at 17:21, Mike Bishop wrote: > > That=E2=80=99s problematic, because it=E2=80=99s the issuer=E2=80=99s inf= rastructure that dictates > the CID size it needs to receive. A real implementation isn=E2=80=99t ju= st making > these up for fun. If a peer says they can=E2=80=99t tolerate CIDs of the= size the > infrastructure uses, the answer will likely be something along the lines = of > =E2=80=9Ctoo (expletive) bad,=E2=80=9D and we=E2=80=99ll be introducing f= ragmentation into > interoperability. I don=E2=80=99t think that=E2=80=99s a good solution. > > > I think it depends weather you see this as a symmetric or a asymmetric > problem: > - If it is just about server resource exhaustion and code efficiency on > the server side, such a parameter could help. > - For the symmetric case, where also the client could constrain the CID > length used by the server, I share your concerns unless we recommend some > very large default CID as minimum. > > > If we feel like we need to constrain this, perhaps a better mitigation > would be to advertise the number of bytes you=E2=80=99re willing to alloc= ate to > tracking the CIDs rather than the static count we do now. Then a server > with large CIDs will issue fewer to you at a time, while a server with > small CIDs could issue many more. However, that only constrains resource > exhaustion; it doesn=E2=80=99t address Dmitri=E2=80=99s point about code = efficiency. > > *From:* QUIC *On Behalf Of *Philipp S. Tiesel > *Sent:* Friday, June 14, 2019 1:34 AM > *To:* Dmitri Tikhonov > *Cc:* Marten Seemann ; Lars Eggert < > lars@eggert.org>; QUIC WG ; Christian Huitema < > huitema@huitema.net>; Martin Thomson > *Subject:* Re: Consensus Call: More Connection ID Space #2736 > > > > > On 13. Jun 2019, at 19:54, Dmitri Tikhonov > wrote: > > On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: > > Besides the obvious inefficiency, which is only born by the > implementations that actually decide to make use of these long > connection IDs (or rather, by their peers), > > > The peer can provide CIDs of any size via NEW_CONNECTION_ID, so > unless an implementation throws longs CIDs out, it has to support > long CIDs. In addition, a server has no choice but to support > maximum-size ODCID. > > > We could make the maximum SCID LEN a transport parameter and > make it an error to extend the connection ID beyond this value. > Together with a sane minimal CID a server has to support, this > mitigates evil clients that try to exhaust resources at the > server without limiting the client. > > If we have such a mechanism, we can allow the full 255 byte > connection IDs for special purpose use cases that presume they need such > long CIDs > > > > > There are trade-offs: > > 1. Make its cid_t a fixed-size object that can fit the > largest CID and eat the overhead for all CIDs. This > has large memory overhead but it is simple and has > good locality of refence. > > 2. Make cid_t a variable-size object. This saves memory > overall, but is more complicated and likely slower > (two memory accesses to get CID). > > 3. Have two types: peer_cid_t that can be any size and > my_cid_t that supports CIDs of fixed length picked by > the implementation. This is even more complicated. > > To summarize, the maximum CID length affects all implementations. > > - Dmitri. > > > AVE! > Philipp S. Tiesel > > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----= , > wenn w eine aube ist dn man au dran dre en = | > o Schr an muss hc h (Kurt Schwitters)= | > :wq! <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----= ' > > --000000000000869b42058b633f6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1. I'll chime in to say that a v1 limit of 48 byt= es is fairly arbitrary choice, well in excess of any use case we're int= erested at any time. If there is a number 18 < n < 48 that can gain c= onsensus, I am comfortable with moving to that number. Frankly, we can just= barely make 18B work given current use cases, so even sticking to 18 would= n't derail everything in the short term. I think it was Kazuho that sug= gested someone might want 2 levels of block encryption, which implies 32B= =C2=A0+ "a few" more bytes for other stuff, and from there I roun= ded up to 48.

2. Would a post-quantum world requir= e larger block sizes? If so, the invariants should definitely leave the nec= essary space.

3. I agree that we are danger of oss= ifying to block CID lengths > whatever the largest is used in practice, = regardless of what the v1 theoretical limit is. However, the answer is not = to "pre-ossify" ourselves to ome limit. Allow 255, and if firewal= ls end up blocking certain use cases, we'll have to deal with that when= we come ot it.



On Sat, Jun 15, 2019 at = 7:14 AM Philipp S. Tiesel <philipp= @tiesel.net> wrote:
HI

On 14. Jun 2019= , at 17:21, Mike Bishop <mbishop@evequefou.be> wrote:

That=E2=80=99s problematic, because it=E2=80=99s the issuer=E2= =80=99s infrastructure that dictates the CID size it needs to receive.=C2= =A0 A real implementation isn=E2=80=99t just making these up for fun.=C2=A0= If a peer says they can=E2=80=99t tolerate CIDs of the size the infrastruc= ture uses, the answer will likely be something along the lines of =E2=80=9C= too (expletive) bad,=E2=80=9D and we=E2=80=99ll be introducing fragmentatio= n into interoperability.=C2=A0 I don=E2=80=99t think that=E2=80=99s a good = solution.

I think it depe= nds weather you see this as a symmetric or a asymmetric problem:
= =C2=A0- If it is just about server resource exhaustion and code efficiency = on the server side, such a parameter could help.
=C2=A0- For the = symmetric case, where also the client could constrain the CID length used b= y the server, I share your concerns unless we recommend some very large def= ault CID as minimum.

=C2=A0
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.org= >= =C2=A0On Behalf Of=C2=A0Philipp S. Tiesel
Sent:=C2=A0Fr= iday, June 14, 2019 1:34 AM
To:=C2=A0Dmitri Tikhonov <dtikhonov@litespeedt= ech.com>
Cc:=C2=A0Marten Seemann <martenseemann@gmail.com>; Lars= Eggert <lars@egger= t.org>; QUIC WG <quic@ietf.org>; Christian Huitema <huitema@huitema.net>; Martin Thomson &= lt;mt@lowentropy.net= >
Subject:=C2=A0Re: Consensus Call: More Connection ID Space= #2736
=C2=A0
<= u>=C2=A0


On 13. Jun 2019, at 19= :54, Dmitri Tikhonov <dtikhonov@l= itespeedtech.com> wrote:
=C2=A0=
On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marte= n Seemann wrote:

Besides the obvious inefficiency, which is onl= y born by the
implementations that actually decide to make use of these = long
connection IDs (or rather, by their peers),

The peer can provide CIDs of any size via NEW_CONNECTION_= ID, so
unless an implementation throws longs CIDs out, it has to support=
long CIDs.=C2=A0 In addition, a server has no choice but to support
= maximum-size ODCID.
<= u>=C2=A0
We could make the maximum SCID LEN= a transport parameter and=C2=A0
make = it an error to extend the connection ID beyond this value.
Together with a sane minimal CID a server has to support= , this=C2=A0
mitigates evil clients that= try to exhaust resources at the
serve= r without limiting the client.
= =C2=A0
If we have such a mechanism, we can allo= w the full 255 byte
connection IDs for s= pecial purpose use cases that presume they need such long CIDs
=C2=A0
=C2= =A0


There are trade-offs:

=C2=A0= =C2=A0=C2=A01. Make its cid_t a fixed-size object that can fit the
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0largest CID and eat the overhead for all C= IDs.=C2=A0 This
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0has large memory ove= rhead but it is simple and has
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0good = locality of refence.

=C2=A0=C2=A0=C2=A02. Make cid_t a variable-size= object.=C2=A0 This saves memory
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ove= rall, but is more complicated and likely slower
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0(two memory accesses to get CID).

=C2=A0=C2=A0=C2=A03. H= ave two types: peer_cid_t that can be any size and
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0my_cid_t that supports CIDs of fixed length picked by
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the implementation.=C2=A0 This is even mor= e complicated.

To summarize, the maximum CID length affects all impl= ementations.

=C2=A0- Dmitri.

=C2=A0
AVE!
=C2=A0 =C2=A0Philipp S= . Tiesel

--=C2=A0
Philipp S. Tiesel=C2=A0
https://philipp.tiesel.net/
<= /div>

AVE!=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
--=C2=A0
=C2=A0 =C2=A0{ph= ils}--->---(phils= @in-panik.de)--->---(http://phils.in-panik.de)----,
=C2=A0 =C2=A0 =C2=A0 wenn w e= ine =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran dre en =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 =C2=A0 =C2=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0 =C2=A0 =C2=A0an mus= s =C2=A0 =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0 (Kurt Schwitters) |=
:wq! =C2=A0<----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----&= #39;

--000000000000869b42058b633f6f-- From nobody Sat Jun 15 17:45:51 2019 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 4F45612019C for ; Sat, 15 Jun 2019 17:45:37 -0700 (PDT) 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 (2048-bit key) header.d=mnot.net header.b=n2oZJsAk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K3mhhckw 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 56fdPBaoGEin for ; Sat, 15 Jun 2019 17:45:32 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7527F12019D for ; Sat, 15 Jun 2019 17:45:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D1D34462 for ; Sat, 15 Jun 2019 20:45:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 15 Jun 2019 20:45:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=cArc6ZLar1UDuwDoBSJbKjbiatMPxe+qoHnOCSfDI3c=; b=n2oZJsAk 7MezIA2ZcqXi+P5XiyRWtPJjmMXsMlovpSc6wxZ4I/SUx+ZZScg6KUP9B3gsHPKy 4364m808g5w5Gb3lPS5braZLmkIB1ruLP/cVqhVfPYUZaNcBMkcFNOUe/NwDQ7QE x9BCHqL3xPlmT9gPT69AXxuB/IFr5zUjsEWP1vRM/nGxEsRB7h1nNDVObJa52vnN mb0tbqyYIeY2mNdLjbmoQsdtkSF3LU74S+ndQ+gzlVRjEDzZp3qgAxJUM8uTeYdZ hmvYWurcNfcLbIT/B8Oeq4uDQEAnCQxp/GDLT0TfU2UcIlFBC/MKogpPlurbQgI4 PDsps2A/Emm9iQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=cArc6ZLar1UDuwDoBSJbKjbiatMPx e+qoHnOCSfDI3c=; b=K3mhhckwx9h2BvuKF5lsdqsZ8veUb+Hc1F17V5IY/CboR 9QWYsAzFxNwOjGTXuXPoaGBBNGDNkqrRnCgdqlN44mBQIE9dNQ8WLoe01yFlMbvy FCLDgV5eycxW8gX8PbGpNiA4rFoZeRUdGy4+pjfiHo0mOVS0bLKGFZUVm04F+ven 4hy9GqKRSGvlW0XxjiQ97CfhHmNFAS844WPx+qYFRpRIOEQTCfM4xxmK8hTv1Hwh nI8LAOUl4G7/CveXcCbM9wU2V7K3a0Y4p6GXLkCcKvOx4musu6H57q5WaDEYgqvC xBYVVy6Hc//lJbR5QecoZWAGdqd9gvYQigM/gCULA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeigedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusggppfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeduudelrdelrdegfedrvdegudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 884B580062 for ; Sat, 15 Jun 2019 20:45:20 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id A1F45C01D4 for ; Sun, 16 Jun 2019 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7151495534172043652==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190616004517.A1F45C01D4@cloud.mnot.net> Date: Sun, 16 Jun 2019 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jun 2019 00:45:50 -0000 --===============7151495534172043652== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+7/-6/=F0=9F=92=AC81) 7 issues created: - Junk QUIC High Hardware Usage (by jobs-git) https://github.com/quicwg/base-drafts/issues/2795 = - Junk QUIC High Hardware Usage (by jobs-git) https://github.com/quicwg/base-drafts/issues/2793 = - Timing side-channel on key updates (by marten-seemann) https://github.com/quicwg/base-drafts/issues/2792 = - Binding settings into session tickets (by martinthomson) https://github.com/quicwg/base-drafts/issues/2790 [-http] = - Use a higher seed RTT for new paths (by martinthomson) https://github.com/quicwg/base-drafts/issues/2789 [-recovery] [design] = - HTTP/3 has less concurrency than HTTP/2 (by kazuho) https://github.com/quicwg/base-drafts/issues/2787 = - Disallow reuse of stateless reset tokens (by DavidSchinazi) https://github.com/quicwg/base-drafts/issues/2785 = 19 issues received 81 new comments: - #2645 Retire My Own CID (20 by DavidSchinazi, mikkelfj, nibanks, ianswe= tt, MikeBishop) https://github.com/quicwg/base-drafts/issues/2645 [-transport] [design] = - #2785 Disallow reuse of stateless reset tokens (12 by kazuho, marten-se= emann, mikkelfj, MikeBishop, DavidSchinazi, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/2785 [-transport] = - #2792 Timing side-channel on key updates (10 by kazuho, marten-seemann,= mikkelfj, ianswett, nibanks, MikeBishop) https://github.com/quicwg/base-drafts/issues/2792 = - #2670 Remove ack_delay_exponent TP (8 by kazuho, marten-seemann, mikkel= fj, ianswett, martinthomson, huitema, nibanks) https://github.com/quicwg/base-drafts/issues/2670 [-transport] [design] = - #2783 Consider making SETTINGS part of the control stream header (5 by = kazuho, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2783 [-http] = - #2309 Migration before handshake completed is very messy (4 by huitema,= ianswett) https://github.com/quicwg/base-drafts/issues/2309 [-transport] [design]= [proposal-ready] = - #2143 Be more conservative about migration? (3 by erickinnear, mnot) https://github.com/quicwg/base-drafts/issues/2143 [-transport] [design] = - #2770 If you want a Stateless Reset you need to send a much larger pack= et than before (3 by RyanAtGoogle, DavidSchinazi, martinthomson) https://github.com/quicwg/base-drafts/issues/2770 [-transport] [design] = - #2205 Largest acked in ACK frame MUST NOT decrease (2 by mnot, ianswett) https://github.com/quicwg/base-drafts/issues/2205 [-transport] [design] = - #2389 Be clearer about the purpose of disable_migration (2 by igorlord,= mnot) https://github.com/quicwg/base-drafts/issues/2389 [-transport] [design] = - #2787 HTTP/3 has less concurrency than HTTP/2 (2 by kazuho, mikkelfj) https://github.com/quicwg/base-drafts/issues/2787 = - #2541 Clients cannot abandon Initial packets while server can still sen= d initial close (2 by DavidSchinazi, mnot) https://github.com/quicwg/base-drafts/issues/2541 [-transport] [design] = - #2550 Apply GREASE to transport parameters (2 by loganaden, mnot) https://github.com/quicwg/base-drafts/issues/2550 [-transport] [design] = - #2084 Discuss requirement that connection IDs not be correlatable (1 by= mnot) https://github.com/quicwg/base-drafts/issues/2084 [-transport] [design] = - #2754 Lessen the divergence from the HTTP/2 prioritization scheme by re= quiring all PRIORITY frames to be sent on the control stream (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2754 [-http] = - #2387 Write up our security target against on-path attack (1 by mnot) https://github.com/quicwg/base-drafts/issues/2387 [-transport] [design] = - #2789 Use a higher seed RTT for new paths (1 by rpaulo) https://github.com/quicwg/base-drafts/issues/2789 [-recovery] [design] = - #2793 Junk QUIC High Hardware Usage (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2793 [invalid] = - #2795 Junk QUIC High Hardware Usage (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2795 = 6 issues closed: - Should platform delays be included in ack-delay? https://github.com/qui= cwg/base-drafts/issues/2596 [-recovery] [design] = - Junk QUIC High Hardware Usage https://github.com/quicwg/base-drafts/iss= ues/2793 [invalid] = - Lessen the divergence from the HTTP/2 prioritization scheme by requirin= g all PRIORITY frames to be sent on the control stream https://github.com/q= uicwg/base-drafts/issues/2754 [-http] = - HTTP/3 settings frames and prioritization https://github.com/quicwg/ba= se-drafts/issues/2772 [-http] [editorial] = - Prohibiting server-initiated bidirectional streams for h3 https://githu= b.com/quicwg/base-drafts/issues/2711 [-http] [design] = - H3 guidance on malformed request/response is light https://github.com/q= uicwg/base-drafts/issues/2410 [-http] [design] = Pull requests ------------- * quicwg/base-drafts (+5/-13/=F0=9F=92=AC40) 5 pull requests submitted: - Clarify ACK of ACKs and bundling a PING (by ianswett) https://github.com/quicwg/base-drafts/pull/2794 [-transport] = - Receiver's behavior on key update (by kazuho) https://github.com/quicwg/base-drafts/pull/2791 = - Clarify the side-effect of frequent key updates (by kazuho) https://github.com/quicwg/base-drafts/pull/2788 = - SHOULD NOT include platform delay in ack delay (by ianswett) https://github.com/quicwg/base-drafts/pull/2786 = - Fix inconsistency. (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2784 = 9 pull requests received 40 new comments: - #2729 Don't store or retransmit PATH_RESPONSE frames, avoid buffering (= 12 by yangchi, DavidSchinazi, kazuho, mikkelfj, erickinnear, martinthomson,= ianswett) https://github.com/quicwg/base-drafts/pull/2729 = - #2786 SHOULD NOT include platform delay in ack delay (8 by kazuho, ians= wett, nibanks) https://github.com/quicwg/base-drafts/pull/2786 [-recovery] = - #2761 allow PRIORITY frames referring to placeholders exceeding `SETTIN= G_NUM_PLACEHOLDERS` (6 by kazuho, ianswett, MikeBishop) https://github.com/quicwg/base-drafts/pull/2761 = - #2788 Clarify the side-effect of frequent key updates (5 by kazuho, mar= ten-seemann, mikkelfj) https://github.com/quicwg/base-drafts/pull/2788 = - #2774 Discuss max-header-list-size from the other side (4 by LPardue, M= ikeBishop) https://github.com/quicwg/base-drafts/pull/2774 [-http] = - #2677 Trigger unhappy (2 by ianswett, MikeBishop) https://github.com/quicwg/base-drafts/pull/2677 [-http] [editorial] = - #2769 Request to Retire Locally Issued CIDs (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2769 [-transport] = - #2791 Receiver's behavior on key update (1 by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2791 = - #2794 Clarify ACK of ACKs and bundling a PING (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2794 [-transport] = 13 pull requests merged: - SHOULD NOT include platform delay in ack delay https://github.com/quicwg/base-drafts/pull/2786 [-recovery] = - Bring back the Exclusive Flag https://github.com/quicwg/base-drafts/pull/2781 [-http] [design] = - Explain initial settings a little more https://github.com/quicwg/base-drafts/pull/2776 [-http] [editorial] = - Don't mandate zero server-initiated bidi streams https://github.com/quicwg/base-drafts/pull/2773 [-http] = - Import malformed message text https://github.com/quicwg/base-drafts/pull/2764 [-http] = - Mandate allowing peer to create enough unidirectional streams for HTTP = and QPACK https://github.com/quicwg/base-drafts/pull/2762 [-http] = - Specify error for a DATA frame before any HEADERS frames https://github.com/quicwg/base-drafts/pull/2715 [-http] [design] = - Fix inconsistency. https://github.com/quicwg/base-drafts/pull/2784 [-http] [editorial] = - Break up H2 Frame Considerations https://github.com/quicwg/base-drafts/pull/2698 [-http] [editorial] = - Fix number agreement: a peer *is* able https://github.com/quicwg/base-drafts/pull/2782 [-http] = - use upper-case RECOMMENDED for text incorporated from RFC 7540 https://github.com/quicwg/base-drafts/pull/2780 [-http] = - Specify HEADERS on control stream error. https://github.com/quicwg/base-drafts/pull/2708 [-http] = - Consolidate Bidirectional Streams and Frame Layout truncated frames par= agraphs https://github.com/quicwg/base-drafts/pull/2722 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7151495534172043652== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 16, 2019

Issues

quicwg/base-drafts (+7/-6/=F0=9F=92=AC81)

7 issues created:

19 issues received 81 new comments:

6 issues closed:

Pull requests

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

5 pull requests submitted:

9 pull requests received 40 new comments:

13 pull requests merged:

Repositories tracked by this digest:

--===============7151495534172043652==-- From nobody Sat Jun 15 22:55:58 2019 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 12C5B1201D4 for ; Sat, 15 Jun 2019 22:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7isHnHDq2RP for ; Sat, 15 Jun 2019 22:55:47 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::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 CD6CC1201A2 for ; Sat, 15 Jun 2019 22:55:46 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id k18so6167404ljc.11 for ; Sat, 15 Jun 2019 22:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=splvqepwjZgmiELxBDIe6ULX9GiHPyr3hGwITD04tX4=; b=JX6o6UoMnf907f0tsrYKmLBwXB0+Ajsw7LJ6dMCEOV7Njew+mC4S9fVRzA1vA7PdJj L7+n7P2KdG8JDLmkPUV1wAUpm8yd7SbG+KWETzl8g6ophL1k+hgoN3tKs/N3aniTWv/Z 2OjGFod6muuokCFQbNniLxPUPcWEsKipL4VYCMbMzCoKRV2Kv1O6jCxntCCnMYmRhWNz +zbq/BMnOoe6EEXWo4Nx7USciKUyTc5qu6MMHhpxOuE3l3yPnqOkSx5kESKwHbKkbZlt khjM0D5anfjHnRWVCPsXn9HsF4zgx0a11wy5n8CuZ9rViiiX1exEOA7S9EKS4JYT8ry9 5S1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=splvqepwjZgmiELxBDIe6ULX9GiHPyr3hGwITD04tX4=; b=pNAgoPXy0gfopsA8+5/1acG1Le//LY7E1lnL84rBQxGYAFSlb5PZ7tjTHaQGHPHeSV WYnA9T1Xo67HqXX3OsavUOzDbZ1eABpTOk9quRZwI98oK6ZNVjfj60r5tzmK3lyI+M5m NlSwlMXzTA19U/B4XnaHgN53r24JBZGabfh1IgyVhPBt1a5v3Iad/Hd2mmTudpAIc2Cy IJaLoJd4R/gSn/IZafXPlf2ko3EbmIgaq5HK5ELn/uGpgq+R33sfEKajxDhwrxmlk5Gq yIgK0tCFwX9qbqu8XptUAWsh5Q/VSKKGHCktPIag+dM1YWxcDcAhdQrF1eCC1++eUZ6O GEdA== X-Gm-Message-State: APjAAAVilnYx8s7SdbPqN8tRPn1ZDlWQ/WWVQlnfLyn1AY9ykS3dBRa6 9r2OKfa3jOSvPqDXyhek0CFrL8kyNw2Y9JhJtws= X-Google-Smtp-Source: APXvYqyuOao5UL+0nOTKCv1OvWN8bVJI8RT10GnyvFFpWPMsHeK2EBfNFnueTyc5K4lS9kOb17UWAt6eO7aXU71JH8Q= X-Received: by 2002:a2e:124b:: with SMTP id t72mr47401163lje.143.1560664545023; Sat, 15 Jun 2019 22:55:45 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: From: Kazuho Oku Date: Sun, 16 Jun 2019 14:55:48 +0900 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Martin Duke Cc: "Philipp S. Tiesel" , Mike Bishop , Dmitri Tikhonov , Christian Huitema , Marten Seemann , Lars Eggert , QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jun 2019 05:55:57 -0000 2019=E5=B9=B46=E6=9C=8816=E6=97=A5(=E6=97=A5) 6:14 Martin Duke : > > 1. I'll chime in to say that a v1 limit of 48 bytes is fairly arbitrary c= hoice, well in excess of any use case we're interested at any time. If ther= e is a number 18 < n < 48 that can gain consensus, I am comfortable with mo= ving to that number. Frankly, we can just barely make 18B work given curren= t use cases, so even sticking to 18 wouldn't derail everything in the short= term. I think it was Kazuho that suggested someone might want 2 levels of = block encryption, which implies 32B + "a few" more bytes for other stuff, a= nd from there I rounded up to 48. Yes. My argument for expanding the maximum CID size is that it would be preferable to support 2 + block_size + alpha, with block_size being the block size of a standardized block cipher. FWIW, stated below is how I think. As we have agreed in the past, one way of a "server" implementing a CID scheme is to use a block cipher. Then, the CID could contain the ID of the thread (or the process) that handles the connection. It is preferable also for a load balancer to rely on a block cipher to encrypt the ID of the server instance that the connection is handled by. Note that in either case it is not a good idea to use a steam cipher (or a block cipher in CTR mode), because the CID becomes malleable, allowing an attacker to target a DoS attack against particular server instance behind the load balancer (or a particular thread within a server instance). _If_ we are to allow loose coupling between a load balancer and a server, each of the two should be given the freedom to choose it's own CID encryption scheme. Because all the standardized block ciphers are now 128-bits (=3D 16 bytes), that naturally means that the maximum CID length of QUIC needs to be double amount of that, plus one or two bytes for each of the two for identifying the CID encryption keys. For key identification and other supplemental use, we currently allocate 2 bytes (18-16=3D2). Based on these numbers, the conclusion goes to having (16 + 2) * 2 =3D 36 b= ytes. > > 2. Would a post-quantum world require larger block sizes? If so, the inva= riants should definitely leave the necessary space. > > 3. I agree that we are danger of ossifying to block CID lengths > whateve= r the largest is used in practice, regardless of what the v1 theoretical li= mit is. However, the answer is not to "pre-ossify" ourselves to ome limit. = Allow 255, and if firewalls end up blocking certain use cases, we'll have t= o deal with that when we come ot it. > > > > On Sat, Jun 15, 2019 at 7:14 AM Philipp S. Tiesel wr= ote: >> >> HI >> >> On 14. Jun 2019, at 17:21, Mike Bishop wrote: >> >> That=E2=80=99s problematic, because it=E2=80=99s the issuer=E2=80=99s in= frastructure that dictates the CID size it needs to receive. A real implem= entation isn=E2=80=99t just making these up for fun. If a peer says they c= an=E2=80=99t tolerate CIDs of the size the infrastructure uses, the answer = will likely be something along the lines of =E2=80=9Ctoo (expletive) bad,= =E2=80=9D and we=E2=80=99ll be introducing fragmentation into interoperabil= ity. I don=E2=80=99t think that=E2=80=99s a good solution. >> >> >> I think it depends weather you see this as a symmetric or a asymmetric p= roblem: >> - If it is just about server resource exhaustion and code efficiency on= the server side, such a parameter could help. >> - For the symmetric case, where also the client could constrain the CID= length used by the server, I share your concerns unless we recommend some = very large default CID as minimum. >> >> >> If we feel like we need to constrain this, perhaps a better mitigation w= ould be to advertise the number of bytes you=E2=80=99re willing to allocate= to tracking the CIDs rather than the static count we do now. Then a serve= r with large CIDs will issue fewer to you at a time, while a server with sm= all CIDs could issue many more. However, that only constrains resource exh= austion; it doesn=E2=80=99t address Dmitri=E2=80=99s point about code effic= iency. >> >> From: QUIC On Behalf Of Philipp S. Tiesel >> Sent: Friday, June 14, 2019 1:34 AM >> To: Dmitri Tikhonov >> Cc: Marten Seemann ; Lars Eggert ; QUIC WG ; Christian Huitema ; Mart= in Thomson >> Subject: Re: Consensus Call: More Connection ID Space #2736 >> >> >> >> >> On 13. Jun 2019, at 19:54, Dmitri Tikhonov = wrote: >> >> On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: >> >> Besides the obvious inefficiency, which is only born by the >> implementations that actually decide to make use of these long >> connection IDs (or rather, by their peers), >> >> >> The peer can provide CIDs of any size via NEW_CONNECTION_ID, so >> unless an implementation throws longs CIDs out, it has to support >> long CIDs. In addition, a server has no choice but to support >> maximum-size ODCID. >> >> >> We could make the maximum SCID LEN a transport parameter and >> make it an error to extend the connection ID beyond this value. >> Together with a sane minimal CID a server has to support, this >> mitigates evil clients that try to exhaust resources at the >> server without limiting the client. >> >> If we have such a mechanism, we can allow the full 255 byte >> connection IDs for special purpose use cases that presume they need such= long CIDs >> >> >> >> >> There are trade-offs: >> >> 1. Make its cid_t a fixed-size object that can fit the >> largest CID and eat the overhead for all CIDs. This >> has large memory overhead but it is simple and has >> good locality of refence. >> >> 2. Make cid_t a variable-size object. This saves memory >> overall, but is more complicated and likely slower >> (two memory accesses to get CID). >> >> 3. Have two types: peer_cid_t that can be any size and >> my_cid_t that supports CIDs of fixed length picked by >> the implementation. This is even more complicated. >> >> To summarize, the maximum CID length affects all implementations. >> >> - Dmitri. >> >> >> AVE! >> Philipp S.. Tiesel >> >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> >> >> AVE! >> Philipp S. Tiesel / phils=E2=80=A6 >> -- >> {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)---= -, >> wenn w eine aube ist dn man au dran dre en = | >> o Schr an muss hc h (Kurt Schwitters= ) | >> :wq! <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)---= -' >> --=20 Kazuho Oku From nobody Sun Jun 16 03:01:45 2019 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 107C312015B for ; Sun, 16 Jun 2019 03:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZwelsayF-6A for ; Sun, 16 Jun 2019 03:01:41 -0700 (PDT) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 4382F120134 for ; Sun, 16 Jun 2019 03:01:41 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id e3so11033574edr.10 for ; Sun, 16 Jun 2019 03:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=WQuX2FJS84Domoa3iKFiNgJWuEwh/0tRHhQ7xHvAkyw=; b=XO7CaMnkBnVpJf336IjVr4QuMugUQTfovmhKV5jvtgyKQoaZO2f0H5El/UoSNAhhQ+ aYePVtdDMv5Mqs654I/qX5cc5T0OfbWVcerK3gbLKY1WJIKAvzRb723Dec+zsDjW7+E/ 5rXKihOkM72/13XBfqTcCPr20y/WZmE0E3NgvgLiHzF83Z0caT7hsWOtUYb8SgceWpqB QClCccnhD/XRWfMQU0AWMrlMsrRmsM53q25lzqnNS95TNk34/TDwlNGl7DiIFLaE2M/N 4tclqM6eMJyMhmPVJhaqBFK9G+54OtMdJKsOEUiRuCy1HUGycK6eOthE6gH964GO8M/M 8olA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=WQuX2FJS84Domoa3iKFiNgJWuEwh/0tRHhQ7xHvAkyw=; b=s8NWqwItGOPbZFWtrFJ+AtoGwZYwGsR9Ohzgx0r8AyZUT2g2X29vBTQSOJLh5QNT9a tnK6+bGO9eJAUetIeSM7iHtPpwxUX2+gSGt0Pbxeqi7PEO4/Oi/RMVv2nYP/17DJhW+M 0XDTPi0tK7CdGquycrOBT15GAyvh+vxWfcNkZ2ZRzInLpu8BzI8Vh3V6JPLS/rZyKET2 D8Mincrdc4BNY3S2YMAKIH3K1gj8o9XuaLpWSBqVXcrZS3qzE6CUoVpAxAzT5Xoa+TZj dP9oj3UNfcltJGNzzCV0Rfeo1s2f6oudmYV0lTl77OII8KKwTV8nw1cV+AM8bMuJJFYb AB2g== X-Gm-Message-State: APjAAAWKgcVAu32+hTVhm7lhPj5KqIlivFD1BUNgL9eBduTXLWhJkXKo jgPDwP5e4TYHcRtyCq33Yui3DkuT5Wv4ySe7b70= X-Google-Smtp-Source: APXvYqx+9lOBEtSNkC4bCkA+xXoNV1N0MSsuGr+9E/P6JFuuyKSnEYCRTMYnT6CdBG6r26oV0rGJ0aCxprtxVHzIoKg= X-Received: by 2002:a17:906:6b53:: with SMTP id o19mr15008047ejs.27.1560679299744; Sun, 16 Jun 2019 03:01:39 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 16 Jun 2019 03:01:38 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 16 Jun 2019 03:01:38 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: "Philipp S. Tiesel" , Martin Duke Cc: QUIC WG , Mike Bishop , Martin Thomson , Marten Seemann , Christian Huitema , Dmitri Tikhonov , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000450ea4058b6df75b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 16 Jun 2019 10:01:44 -0000 --000000000000450ea4058b6df75b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m wondering if overly long CID=E2=80=99s are just an attempt to i= mplement stateless NAT server side rather than taking advantage of IPv6? You could use a shorter CID to add authentication to the IP header along with other details for routing purposes. I already find 18 bytes a lot, especially in addition to the IP header. I can see a use case for content hashed addressing, but even here 18 bytes ought to be enough. On 15 June 2019 at 23.14.52, Martin Duke (martin.h.duke@gmail.com) wrote: 1. I'll chime in to say that a v1 limit of 48 bytes is fairly arbitrary choice, well in excess of any use case we're interested at any time. If there is a number 18 < n < 48 that can gain consensus, I am comfortable with moving to that number. Frankly, we can just barely make 18B work given current use cases, so even sticking to 18 wouldn't derail everything in the short term. I think it was Kazuho that suggested someone might want 2 levels of block encryption, which implies 32B + "a few" more bytes for other stuff, and from there I rounded up to 48. 2. Would a post-quantum world require larger block sizes? If so, the invariants should definitely leave the necessary space. 3. I agree that we are danger of ossifying to block CID lengths > whatever the largest is used in practice, regardless of what the v1 theoretical limit is. However, the answer is not to "pre-ossify" ourselves to ome limit. Allow 255, and if firewalls end up blocking certain use cases, we'll have to deal with that when we come ot it. On Sat, Jun 15, 2019 at 7:14 AM Philipp S. Tiesel wrote: > HI > > On 14. Jun 2019, at 17:21, Mike Bishop wrote: > > That=E2=80=99s problematic, because it=E2=80=99s the issuer=E2=80=99s inf= rastructure that dictates > the CID size it needs to receive. A real implementation isn=E2=80=99t ju= st making > these up for fun. If a peer says they can=E2=80=99t tolerate CIDs of the= size the > infrastructure uses, the answer will likely be something along the lines = of > =E2=80=9Ctoo (expletive) bad,=E2=80=9D and we=E2=80=99ll be introducing f= ragmentation into > interoperability. I don=E2=80=99t think that=E2=80=99s a good solution. > > > I think it depends weather you see this as a symmetric or a asymmetric > problem: > - If it is just about server resource exhaustion and code efficiency on > the server side, such a parameter could help. > - For the symmetric case, where also the client could constrain the CID > length used by the server, I share your concerns unless we recommend some > very large default CID as minimum. > > > If we feel like we need to constrain this, perhaps a better mitigation > would be to advertise the number of bytes you=E2=80=99re willing to alloc= ate to > tracking the CIDs rather than the static count we do now. Then a server > with large CIDs will issue fewer to you at a time, while a server with > small CIDs could issue many more. However, that only constrains resource > exhaustion; it doesn=E2=80=99t address Dmitri=E2=80=99s point about code = efficiency. > > *From:* QUIC *On Behalf Of *Philipp S. Tiesel > *Sent:* Friday, June 14, 2019 1:34 AM > *To:* Dmitri Tikhonov > *Cc:* Marten Seemann ; Lars Eggert < > lars@eggert.org>; QUIC WG ; Christian Huitema < > huitema@huitema.net>; Martin Thomson > *Subject:* Re: Consensus Call: More Connection ID Space #2736 > > > > > On 13. Jun 2019, at 19:54, Dmitri Tikhonov > wrote: > > On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote: > > Besides the obvious inefficiency, which is only born by the > implementations that actually decide to make use of these long > connection IDs (or rather, by their peers), > > > The peer can provide CIDs of any size via NEW_CONNECTION_ID, so > unless an implementation throws longs CIDs out, it has to support > long CIDs. In addition, a server has no choice but to support > maximum-size ODCID. > > > We could make the maximum SCID LEN a transport parameter and > make it an error to extend the connection ID beyond this value. > Together with a sane minimal CID a server has to support, this > mitigates evil clients that try to exhaust resources at the > server without limiting the client. > > If we have such a mechanism, we can allow the full 255 byte > connection IDs for special purpose use cases that presume they need such > long CIDs > > > > > There are trade-offs: > > 1. Make its cid_t a fixed-size object that can fit the > largest CID and eat the overhead for all CIDs. This > has large memory overhead but it is simple and has > good locality of refence. > > 2. Make cid_t a variable-size object. This saves memory > overall, but is more complicated and likely slower > (two memory accesses to get CID). > > 3. Have two types: peer_cid_t that can be any size and > my_cid_t that supports CIDs of fixed length picked by > the implementation. This is even more complicated. > > To summarize, the maximum CID length affects all implementations. > > - Dmitri. > > > AVE! > Philipp S.. Tiesel > > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ > > > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > -- > {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----= , > wenn w eine aube ist dn man au dran dre en = | > o Schr an muss hc h (Kurt Schwitters)= | > :wq! <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----= ' > > --000000000000450ea4058b6df75b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m wonderin= g if overly long CID=E2=80=99s are just an attempt to implement stateless N= AT server side rather than taking advantage of IPv6?

You could use a shorter CID to add authenti= cation to the IP header along with other details for routing purposes.

I already find 18 bytes a= lot, especially in addition to the IP header.

I can see a use case for content hashed addressin= g, but even here 18 bytes ought to be enough.

On 15 June 2019 at 23.14.52, Martin Duke (martin.h.duke@gmail.com) wrote:

1. I'll chime in to say that a v1 limit of 48 bytes is fairly arbitrary choice, well in excess of any use case we're interested at any time. If there is a number 18 < n < 48 that can gain consensus, I am comfortable with moving to that number. Frankly, we can just barely make 18B work given current use cases, so even sticking to 18 wouldn't derail everything in the short term. I think it was Kazuho that suggested someone might want 2 levels of block encryption, which implies 32B=C2=A0+ "a few" more bytes for other stuff, and from there I rounded up to 48.

2. Would a post-quantum world require larger block sizes? If so, the invariants should definitely leave the necessary space.

3. I agree that we are danger of ossifying to block CID lengths > whatever the largest is used in practice, regardless of what the v1 theoretical limit is. However, the answer is not to "pre-ossify" ourselves to ome limit. Allow 255, and if firewalls end up blocking certain use cases, we'll have to deal with that when we come ot it.



On Sat, Jun 15, 2019 at 7:14 AM Philipp S. Tiesel <philipp@tiesel.= net> wrote:
HI

On 14. Jun 2019, at 17:21, Mike Bishop <mbishop@evequefou.be> wrote:

That=E2=80=99s problematic, because it=E2=80=99s the issuer=E2=80=99s infra= structure that dictates the CID size it needs to receive.=C2=A0 A real implementation isn=E2=80=99t just making these up for fun.=C2=A0 If a peer says they can=E2=80=99t tolerate CIDs of the size the infrastructure uses, the answer will likely be something along the lines of =E2=80=9Ctoo (expletive) bad,=E2=80=9D and we=E2=80=99ll be introducing fragmentation in= to interoperability.=C2=A0 I don=E2=80=99t think that=E2=80=99s a good solutio= n.

I think it depends weather you see this as a symmetric or a asymmetric problem:
=C2=A0- If it is just about server resource exhaustion and code efficiency on the server side, such a parameter could help.
=C2=A0- For the symmetric case, where also the client could constrain the CID length used by the server, I share your concerns unless we recommend some very large default CID as minimum.

=C2=A0
If we feel like we need to constrain this, perhaps a better mitigation would be to advertise the number of bytes you=E2=80=99re willing to allocate to tracking the CIDs rather than the static count we do now.=C2=A0 Then a server with large CIDs will issue fewer to you at a time, while a server with small CIDs could issue many more.=C2=A0 However, that only constrains resource exhaustion; it doesn=E2=80=99t address Dmitri=E2=80=99s point about code efficiency.
=C2=A0
From:=C2=A0QUIC <quic-bounces= @ietf.org>=C2=A0On Behalf Of= =C2=A0Philipp S. Tiesel
Sent:=C2=A0Friday, June 14, 2019 1:34 AM
To:=C2=A0Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Cc:=C2=A0Marten Seemann <ma= rtenseemann@gmail.com>; Lars Eggert <lars@eggert.org>; QUIC WG <quic@ietf.or= g>; Christian Huitema <huitema@huitema.net>; Martin Thomson <mt@lowentropy.net>
Subject:=C2=A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
=C2=A0


On 13. Jun 2019, at 19:54, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
=C2=A0
On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote:

Besides the obvious inefficiency, which is only born by the
implementations that actually decide to make use of these long
connection IDs (or rather, by their peers),

The peer can provide CIDs of any size via NEW_CONNECTION_ID, so
unless an implementation throws longs CIDs out, it has to support
long CIDs.=C2=A0 In addition, a server has no choice but to support
maximum-size ODCID.
=C2=A0
We could make the maximum SCID LEN a transport parameter and=C2=A0
make it an error to extend the connection ID beyond this value.
Together with a sane minimal CID a server has to support, this=C2=A0
mitigates evil clients that try to exhaust resources at the
server without limiting the client.
=C2=A0
If we have such a mechanism, we can allow the full 255 byte
connection IDs for special purpose use cases that presume they need such long CIDs
=C2=A0
=C2=A0


There are trade-offs:

=C2=A0=C2=A0=C2=A01. Make its cid_t a fixed-size object that can fit the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0largest CID and eat the overhead for all CIDs.=C2=A0 This
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0has large memory overhead but it is simple and has
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0good locality of refence.

=C2=A0=C2=A0=C2=A02. Make cid_t a variable-size object.=C2=A0 This saves memory
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0overall, but is more complicated and likely slower
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(two memory accesses to get CID).

=C2=A0=C2=A0=C2=A03. Have two types: peer_cid_t that can be any size and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0my_cid_t that supports CIDs of fixed length picked by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the implementation.=C2=A0 This is even more complicated.

To summarize, the maximum CID length affects all implementations.

=C2=A0- Dmitri.

=C2=A0
AVE!
=C2=A0 =C2=A0Philipp S.. Tiesel

--=C2=A0
Philipp S. Tiesel=C2=A0
https://philipp.tiesel.net/

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
--=C2=A0
=C2=A0 =C2=A0{phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
=C2=A0 =C2=A0 =C2=A0 wenn w eine =C2=A0 aube ist dn =C2=A0 =C2=A0 =C2=A0man au dran dre en =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 =C2=A0 =C2=A0o =C2=A0 =C2=A0 Schr =C2=A0 =C2=A0 =C2=A0 =C2=A0an muss =C2=A0 =C2=A0 hc =C2=A0 =C2=A0 =C2=A0 =C2=A0 h =C2=A0 (Kurt Schwitters) |
:wq! =C2=A0<----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

--000000000000450ea4058b6df75b-- From nobody Sun Jun 16 19:09:37 2019 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 49C911200FD for ; Sun, 16 Jun 2019 19:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 SzveDov60BOo for ; Sun, 16 Jun 2019 19:09:33 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.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 69AED1200C5 for ; Sun, 16 Jun 2019 19:09:33 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp02.mail2web.com) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hch5O-00075h-Sz for quic@ietf.org; Mon, 17 Jun 2019 04:09:32 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hch5L-00084w-Pv for quic@ietf.org; Sun, 16 Jun 2019 22:09:28 -0400 Received: (qmail 4586 invoked from network); 17 Jun 2019 02:09:23 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Jun 2019 02:09:22 -0000 To: Kazuho Oku , Martin Duke Cc: Mike Bishop , Dmitri Tikhonov , "Philipp S. Tiesel" , Marten Seemann , Lars Eggert , QUIC WG , Martin Thomson References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Sun, 16 Jun 2019 19:09:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Consensus Call: More Connection ID Space #2736 X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Q9DGisTdy29Heef28Cu3sipSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fsahTsTDR0rsLknEZKwN70c/sevPPdLVvjz7b14RFNIS87+5mCGQbZOG2a6 XRF1Gc0bQoXoeQu5aLx9Lt+8rsexTpgWJlsU4G2/4kZd/AHuzsdm/7IKyshZDKoLEEdzFciN9bEz YXQ5Bq54+8sOLcJpXof3r8kfRxpez5OlfYJRQkKHj8GhSvnXG6aqAO+QA5zAmfg+QMjm0Wxe7G4F AAR6avERpop5LF7RavHozgbn9YqgREAoh06jutiTfFzl2G4uss8347yATkLSIXqnQVGKSPZLLSx3 /6BTpL6UXmT8yFSCJlnatpQUVkDyz9+HEa34l0QmPyjhxxYY4z85MF0ZIK/1NH5THMtlYvyHAYGO GlmJIjyKo/pbSDRNIEOEwlMcz873cIRxyN1uC++vIKvC6BczixKau3SVCHUjX//EjwcJ9Z2B17W0 SOVeAqfVLBur38uheYGZEGMgKMCjg1Dz7py5WhTmeYYSnIrN3ccaIayp/agYZfrnDk8+IFUpab7m 9Ql4Ld7qe/xoNQPgy7UpxcIWHOi9y3yF+Ot2t6dhJc2bXYMFScrLivfWmWkJo22CHZOREywSBAd6 WuRFS3mxg1zCW7w3Nrxw6dOwxmvxJ6aIZ4Y1pUAFgRJ0a5xpkoE8CVsONrMJuGzuoGnKTKcymM5H 5NK8ObCxL+Ab3gHeBGp1PWox/HcVwRsYfOuMC9EDvRTWmuYW5XPvbs91Tlwpv0lqRWmYZel4DctY KBjcJAZlJF8UKGQcpLF8m4y5fNSIlEy3YgJZkOfaaqfw0pD+E4vXmYOrZ6ynPfzK8qbeqosYcSFD ZkSOre2YUe/WyPr4xM5tUrEfL92iWzfzWX2vJeNfaj+DKN82dVVpaMxSGA== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 02:09:35 -0000 On 6/15/2019 10:55 PM, Kazuho Oku wrote: > _If_ we are to allow loose coupling between a load balancer and a > server, each of the two should be given the freedom to choose it's own > CID encryption scheme. Because all the standardized block ciphers are > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID > length of QUIC needs to be double amount of that, plus one or two > bytes for each of the two for identifying the CID encryption keys. For > key identification and other supplemental use, we currently allocate 2 > bytes (18-16=3D2). That reasoning is based on the assumption that both the load balancer and the server must use a block cipher with 128 bit block length in order to encrypt the CID. If they were constrained to stay within a short global limit, they could use different sets of algorithms. Assume for example that we split the CID between 32 bits encoding the number of the server in the server farm, and 64 bit encoding the connection number for the server. The server can pick a random value for the connection number, and use a hash table. The load balancer could use a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID as an initial vector. Voila, 96 CID, with demonstrably strong encryption.= Or assume that the server wants to use short CID. We now split the CID between 32 bit for the server number in the farm, and 32 bit for the connection number in the server. The server builds that connection number by using a 32 bit variant of FFX. The load balancer also uses a 32 bit variant, using the lower 32 bit of the CID as initial vector for this FFX encryption. These are just two examples. And yes you may want to add 2 bytes for key identification, etc. In both encryption algorithms, you can feed these two bytes as additional IV for the FFX algorithm. And in both cases, we are well below the 18 byte limit. Yes, that requires some creative engineering. But it is not rocker science. And it seems better than carrying tons of overhead in the header, and becoming less efficient than HTTP2/TLS/TCP. -- Christian Huitema From nobody Sun Jun 16 21:44:47 2019 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 EAA6D12014F for ; Sun, 16 Jun 2019 21:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 GdwUnHb-T9gj for ; Sun, 16 Jun 2019 21:44:43 -0700 (PDT) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 DCC2212011E for ; Sun, 16 Jun 2019 21:44:39 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id y17so5484095lfe.0 for ; Sun, 16 Jun 2019 21:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zeWntx7dhauZ1QIewxCmwKKS5o26AkgU5QRbRweiJXQ=; b=RXweeRIvbZopRFmEwq4LH4RIMIJ4QX46ZoX3mtWL+lBTunbEoTOFIJmh8dFfPW+TRq l4M6FdZnU2ayQnIB0jHff91sZ66DhTkFnwWks3WuL4/ZR97AEth7+oDjwgERnO6i3ZuZ ayjIbwbzdgAYR5I3E73zaPJOGWu3ZtCwukDqSKJXlC+y4bqC4RBQLgP4mKH1O439hcxt QaaWpHleKXbyxCIK1lnJGY0P5QV0avo4DsMs/Aw3nHzTxSzCTvWhhm7ogYFSsu4xr505 gllADBjlVAl7n3rkW0JnDK9PcxhUPzq801jQlUtZL6r+rnbmlWDFBqUjAm/dPDIo+LRJ E9jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zeWntx7dhauZ1QIewxCmwKKS5o26AkgU5QRbRweiJXQ=; b=ZRS+jkx4pmoYQZnxJZBl6Cwa2P72p3nNJgNzrVb879UIVwVAjwRFXQgup//W4zNnFz 91HfaVNvDAR8HLe9s2IUM7TEbzf09zjfgx3lOzSjpHjllDDvdeic5sjEWNouf1YQb7+C SPsinRnisTOoVlQIMl6JRLONa/CdT4T08YtlwL9VDttJG7wMFk7bvSzDk+Fjpy99sbgs 9v+E+jIAcxid82U5NcgM4/nd8ln3zigluPRubROQUmfAFb4GBonam+y5LCC00TaWfEXe 5VQTOXjtCxy1hhZW+NVeBoaxsjlGoJey1a/1cDsI7KHjJA0vBsfP04CMm6p/+aeIxtXJ OoTw== X-Gm-Message-State: APjAAAUHncyEpOUwgWFv+HRp2CP/drlBGf1XhSgRX689wILyqLZLOynv Rlsgbj/b+w0mw4vwPVKbq5ec6hfqUCB7NvUDM8U= X-Google-Smtp-Source: APXvYqyMd+rFWvBBw8RJWtAxtSBdjQk42Lq/uOKdzTnxGaifmB5caLUCo12YOg5u9gxqVEd8DfvTI3al9wuFtvQsOfY= X-Received: by 2002:ac2:4839:: with SMTP id 25mr15669880lft.79.1560746678195; Sun, 16 Jun 2019 21:44:38 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: From: Kazuho Oku Date: Mon, 17 Jun 2019 13:44:28 +0900 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Christian Huitema Cc: Martin Duke , "Philipp S. Tiesel" , Dmitri Tikhonov , Mike Bishop , Marten Seemann , Lars Eggert , QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 04:44:46 -0000 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema : > > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > _If_ we are to allow loose coupling between a load balancer and a > > server, each of the two should be given the freedom to choose it's own > > CID encryption scheme. Because all the standardized block ciphers are > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID > > length of QUIC needs to be double amount of that, plus one or two > > bytes for each of the two for identifying the CID encryption keys. For > > key identification and other supplemental use, we currently allocate 2 > > bytes (18-16=3D2). > > That reasoning is based on the assumption that both the load balancer > and the server must use a block cipher with 128 bit block length in > order to encrypt the CID. If they were constrained to stay within a > short global limit, they could use different sets of algorithms. > > Assume for example that we split the CID between 32 bits encoding the > number of the server in the server farm, and 64 bit encoding the > connection number for the server. The server can pick a random value for > the connection number, and use a hash table. The load balancer could use > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID > as an initial vector. Voila, 96 CID, with demonstrably strong encryption. > > Or assume that the server wants to use short CID. We now split the CID > between 32 bit for the server number in the farm, and 32 bit for the > connection number in the server. The server builds that connection > number by using a 32 bit variant of FFX. The load balancer also uses a > 32 bit variant, using the lower 32 bit of the CID as initial vector for > this FFX encryption. > > These are just two examples. And yes you may want to add 2 bytes for key > identification, etc. In both encryption algorithms, you can feed these > two bytes as additional IV for the FFX algorithm. And in both cases, we > are well below the 18 byte limit. > > Yes, that requires some creative engineering. But it is not rocker > science. And it seems better than carrying tons of overhead in the > header, and becoming less efficient than HTTP2/TLS/TCP. I agree that it would not be the end of the world for the load balancers if we decide to stick on the 18-byte limit. However, as you state, it requires some creativeness. To me it seems that the question is if we have a strong reason to require some people to be creative, for all the versions of QUIC in the future. I personally think that there isn't a strong reason, because people can use shorter CIDs regardless of the decision we make. IIUC, the overhead that everyone needs to accept is: * one byte increase in the long header packets * the minimum size of short header packets becoming slightly greater (otherwise, the peer might not be able to send a stateless reset) I'd say that the first bullet point is negligible. The second point could also be, because I'd assume that the only frequently-sent packets that require additional padding is the ACK-only packets, but there's no reason to pad ACK-only packets in hope that you'd see a stateless reset. Therefore, my (not-so-strong) preference has been to provide extra room, so that some people with necessity can use longer CIDs. > > -- Christian Huitema > > > -- Kazuho Oku From nobody Sun Jun 16 23:50:52 2019 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 C95901200F1 for ; Sun, 16 Jun 2019 23:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7f_thxkJNuj for ; Sun, 16 Jun 2019 23:50:48 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 411A312000E for ; Sun, 16 Jun 2019 23:50:48 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id s49so14584438edb.1 for ; Sun, 16 Jun 2019 23:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=KKMp/VLSUwmsz/sbbYvayxNX2iMnqmsbB3aqyvJwn00=; b=AWB/hPBDSKkw+hLowwZF3HHbX8rCX7sYnappuMS08q1FcZTwMBRunLDF8mD6a78hqd ocqp7ySdGZ68+KACiIkfqYudPGlxKaoX2Zcj+/p905RZSNwXnhX9nyWE/ddpFB06FS8J DkMStMntbwxtGIGVFC4To216cYeJ8gL/uumko4l55+jqaiperr87lVQtQRVjTW1g7B2P aWRJ2mt0SYNtLzjFl3AwnsygCYJHnzsyC3uIo09NTK3LwujjW4z9gEriVz6TWoXaNaY7 7FWv8B0wtn2TJYPKrbGccIaODX17Hat6bxg2yhFN5bJtoS1tIWkee3Kp3xIRRm5EHofr iW8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=KKMp/VLSUwmsz/sbbYvayxNX2iMnqmsbB3aqyvJwn00=; b=t6Av/KDj9Kb6svVQxXT7cJG511ufKoGfDhsbG94MNm0TiNp3rc4Z6W9uTzZSYAChZ1 r6KmPPFvGH1VZQaHHoNHwm/kg1CyGkKu2ZUGiUC60VRphGKVYGKwQho9SpBY6+anIW/I fQLqWKsfFEPC75iZ/kncliaoh/0yNzdz+iE/5hLWyGsboqqPus3K2Qg0Ym1TiR/iVefm 7lCL6gJt1OtrTpnges+IfqJqrq8SOUOP0LjyY0WUpoiogCKUIcPx7/ADrgifTDo44OGr mRVoZ+SIqKy54EmE9aXdJH/gGhYFnmmmcLO0uU+8/X0lXPgc1D6tKOCRSLyz24IEU+x7 rG7g== X-Gm-Message-State: APjAAAVXvtGcMLhuRv94yLYJJ+mwwnC3Twyyq+ZV/yWv1tDSx9UZkVx4 BmzahpuupmYsjPuqGOYsz3QFQy4bL67UrS6kOJI= X-Google-Smtp-Source: APXvYqwP56mSYn2Dqk46o86HfQ+mrez18Ad+C6/b0XvBQ/dx0siqMN6Bql3slWAonFx4FHEvhbwMpeNl2xf82uz1uZ4= X-Received: by 2002:a50:f5c2:: with SMTP id x2mr69267116edm.13.1560754246595; Sun, 16 Jun 2019 23:50:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 17 Jun 2019 02:50:45 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 17 Jun 2019 02:50:45 -0400 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Christian Huitema , Kazuho Oku Cc: QUIC WG , Mike Bishop , Martin Thomson , Marten Seemann , Dmitri Tikhonov , Martin Duke , "Philipp S. Tiesel" , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000733a3e058b7f6ac8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 06:50:51 -0000 --000000000000733a3e058b7f6ac8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited. I do think the invariants should allow for long CID=E2=80=99s as proposed, = and that the long header overhead is not important. But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. I good reference on an algorithm like suggested by Christian would go a long way. If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80= =99s not like we are not looking for excuses to upgrade QUIC versions soon. If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in CID le= ngths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go. Mikkel On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema : > > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > _If_ we are to allow loose coupling between a load balancer and a > > server, each of the two should be given the freedom to choose it's own > > CID encryption scheme. Because all the standardized block ciphers are > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID > > length of QUIC needs to be double amount of that, plus one or two > > bytes for each of the two for identifying the CID encryption keys. For > > key identification and other supplemental use, we currently allocate 2 > > bytes (18-16=3D2). > > That reasoning is based on the assumption that both the load balancer > and the server must use a block cipher with 128 bit block length in > order to encrypt the CID. If they were constrained to stay within a > short global limit, they could use different sets of algorithms. > > Assume for example that we split the CID between 32 bits encoding the > number of the server in the server farm, and 64 bit encoding the > connection number for the server. The server can pick a random value for > the connection number, and use a hash table. The load balancer could use > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID > as an initial vector. Voila, 96 CID, with demonstrably strong encryption. > > Or assume that the server wants to use short CID. We now split the CID > between 32 bit for the server number in the farm, and 32 bit for the > connection number in the server. The server builds that connection > number by using a 32 bit variant of FFX. The load balancer also uses a > 32 bit variant, using the lower 32 bit of the CID as initial vector for > this FFX encryption. > > These are just two examples. And yes you may want to add 2 bytes for key > identification, etc. In both encryption algorithms, you can feed these > two bytes as additional IV for the FFX algorithm. And in both cases, we > are well below the 18 byte limit. > > Yes, that requires some creative engineering. But it is not rocker > science. And it seems better than carrying tons of overhead in the > header, and becoming less efficient than HTTP2/TLS/TCP. I agree that it would not be the end of the world for the load balancers if we decide to stick on the 18-byte limit. However, as you state, it requires some creativeness. To me it seems that the question is if we have a strong reason to require some people to be creative, for all the versions of QUIC in the future. I personally think that there isn't a strong reason, because people can use shorter CIDs regardless of the decision we make. IIUC, the overhead that everyone needs to accept is: * one byte increase in the long header packets * the minimum size of short header packets becoming slightly greater (otherwise, the peer might not be able to send a stateless reset) I'd say that the first bullet point is negligible. The second point could also be, because I'd assume that the only frequently-sent packets that require additional padding is the ACK-only packets, but there's no reason to pad ACK-only packets in hope that you'd see a stateless reset. Therefore, my (not-so-strong) preference has been to provide extra room, so that some people with necessity can use longer CIDs. > > -- Christian Huitema > > > --=20 Kazuho Oku --000000000000733a3e058b7f6ac8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Since it is more lik= ely that you pay for egress traffic than ingress traffic, the motivation to= keep CID=E2=80=99s small is limited.

=

But for QUIC v1, if we al= low for a long CID, a rush to market will set precedence and long CID=E2=80= =99s will ossify in all kinds of stacks.

I good reference on an algorithm like suggested by Chri= stian would go a long way.

If CID length 18 turns out to be not enough, we can add a QUIC v2. It= =E2=80=99s not like we are not looking for excuses to upgrade QUIC versions= soon.

If CID length = negotiation is needed, this could be done via QUIC versions. For example tw= o functionally equivalent versions, but one with longer CID=E2=80=99s. This= would also allow routers to deal with changes in CID lengths. A negotiated= TP would not (easily) allow for that and aside I do not think CID length i= n TP is the way to go.

Mikkel

On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019=E5=B9=B46=E6=9C=881= 7=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema <huitema@huitema.net>:
>
> On 6/15/2019 10:55 PM, Kazuho Oku wrote:
>
> > _If_ we are to allow loose coupling between a load balancer a= nd a
> > server, each of the two should be given the freedom to choose= it's own
> > CID encryption scheme. Because all the standardized block cip= hers are
> > now 128-bits (=3D 16 bytes), that naturally means that the ma= ximum CID
> > length of QUIC needs to be double amount of that, plus one or= two
> > bytes for each of the two for identifying the CID encryption = keys. For
> > key identification and other supplemental use, we currently a= llocate 2
> > bytes (18-16=3D2).
>
> That reasoning is based on the assumption that both the load balan= cer
> and the server must use a block cipher with 128 bit block length i= n
> order to encrypt the CID. If they were constrained to stay within = a
> short global limit, they could use different sets of algorithms.
>
> Assume for example that we split the CID between 32 bits encoding = the
> number of the server in the server farm, and 64 bit encoding the
> connection number for the server. The server can pick a random val= ue for
> the connection number, and use a hash table. The load balancer cou= ld use
> a 32 bit variant of the FFX algorithm, using the lower 64 bit of t= he CID
> as an initial vector. Voila, 96 CID, with demonstrably strong encr= yption.
>
> Or assume that the server wants to use short CID. We now split the= CID
> between 32 bit for the server number in the farm, and 32 bit for t= he
> connection number in the server. The server builds that connection
> number by using a 32 bit variant of FFX. The load balancer also us= es a
> 32 bit variant, using the lower 32 bit of the CID as initial vecto= r for
> this FFX encryption.
>
> These are just two examples. And yes you may want to add 2 bytes f= or key
> identification, etc. In both encryption algorithms, you can feed t= hese
> two bytes as additional IV for the FFX algorithm. And in both case= s, we
> are well below the 18 byte limit.
>
> Yes, that requires some creative engineering. But it is not rocker
> science. And it seems better than carrying tons of overhead in the
> header, and becoming less efficient than HTTP2/TLS/TCP.

I agree that it would not be the end of the world for the load
balancers if we decide to stick on the 18-byte limit. However, as you
state, it requires some creativeness.

To me it seems that the question is if we have a strong reason to
require some people to be creative, for all the versions of QUIC in
the future. I personally think that there isn't a strong reason,
because people can use shorter CIDs regardless of the decision we
make. IIUC, the overhead that everyone needs to accept is:

* one byte increase in the long header packets
* the minimum size of short header packets becoming slightly greater
(otherwise, the peer might not be able to send a stateless reset)

I'd say that the first bullet point is negligible. The second point
could also be, because I'd assume that the only frequently-sent
packets that require additional padding is the ACK-only packets, but
there's no reason to pad ACK-only packets in hope that you'd se= e a
stateless reset.

Therefore, my (not-so-strong) preference has been to provide extra
room, so that some people with necessity can use longer CIDs.

>
> -- Christian Huitema
>
>
>



--
Kazuho Oku

--000000000000733a3e058b7f6ac8-- From nobody Mon Jun 17 08:37:08 2019 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 2F340120143 for ; Mon, 17 Jun 2019 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny6n2waTPjnZ for ; Mon, 17 Jun 2019 08:37:02 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 3AC5912008A for ; Mon, 17 Jun 2019 08:37:02 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id f9so10427795wre.12 for ; Mon, 17 Jun 2019 08:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vVAFPxIEluQ2VlAOE92rnwZHxJYUTAc7NpAhCRjK9K4=; b=Iu66EIMNw0bKoWdNaNeg/MiJw9H2pwAsyxzUitljlb9X5BFhIoQAVQXXqUhA+tmRyu 8/Ff9SPgkBDuNQC1aVfjmEZX/LuS3Bl6Lbi8QMarMnErRpK9XIJd976ie2u6oPV7JbwU /dmiB61dR7lWMtrz0Z1S0IBXY587yVBGx+A+8AZZgS8ukRJjckBzVXPNSx05boqAHYQi DmkKtojpJJs09+zX/fgMyOJxNxb3SXdXz3nMBEcFcw5a7n7ebozc2dPNU4Ut/ZZvnHgY 1Gq0suyJPwht8gH/rPyZN5CNvAYpM5vM7x+Lmf4FEjEqSe5FnfRat2UaX59udkvQeI/j DmOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vVAFPxIEluQ2VlAOE92rnwZHxJYUTAc7NpAhCRjK9K4=; b=j+8+Jq7sDjuoLw4qPeqyRcLnwcEk3MDEsC7vqDty1PFnlAYM2uS0cwJ8FIIA3Q3zui 7trIUAiLbyGadlL/IWlRDJ9ithA8F1gUiIMemdumWMhuU+aZ6ed07NxqQGUF3zaU8c4u KWmzXORwf6qnH8/aYR5PpS2QeHbceMbQ5FNDiC9yehyJxPOLXduG5WgO3e+f8sVlwq0h CZ94YVeijCsY5CYAYtAVKNDCjKkpWvQ027VOkdL4YXiAvsxYA8uvmLetPzvVzgl9YlSC TLBQ6288XShTOrveX7kSkUraM3Z6Y4ymm/pwA9UFDytfLGVkqu1uUlThgKt6tLPQB6Gs O/Sg== X-Gm-Message-State: APjAAAWhXAOW86x/dsvhd7gbC9A1jl4WDK9pIUYFsqp6cDaxMU7lATps OSUPzzdN2NYd0g2vpWUb1RyAAxZg4K2REgX7Rt2u3w== X-Google-Smtp-Source: APXvYqxAEaK+jH8WDLpak10v/FF+avuRcGsVdnE2AZvrnje2TgFPtu1EWNavVPGMLvqVXUy68E8kNkpeZmZMNW2UJPM= X-Received: by 2002:a5d:40ca:: with SMTP id b10mr16735743wrq.171.1560785820086; Mon, 17 Jun 2019 08:37:00 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: From: Ian Swett Date: Mon, 17 Jun 2019 11:36:47 -0400 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Christian Huitema , Kazuho Oku , Dmitri Tikhonov , "Philipp S. Tiesel" , Mike Bishop , Martin Thomson , Marten Seemann , Lars Eggert , QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="00000000000060cd1b058b86c4e6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 15:37:06 -0000 --00000000000060cd1b058b86c4e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly. However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective. Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it. On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Since it is more likely that you pay for egress traffic than ingress > traffic, the motivation to keep CID=E2=80=99s small is limited. > > I do think the invariants should allow for long CID=E2=80=99s as proposed= , and > that the long header overhead is not important. > > But for QUIC v1, if we allow for a long CID, a rush to market will set > precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > > I good reference on an algorithm like suggested by Christian would go a > long way. > > If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2= =80=99s > not like we are not looking for excuses to upgrade QUIC versions soon. > > If CID length negotiation is needed, this could be done via QUIC versions= . > For example two functionally equivalent versions, but one with longer > CID=E2=80=99s. This would also allow routers to deal with changes in CID = lengths. A > negotiated TP would not (easily) allow for that and aside I do not think > CID length in TP is the way to go. > > Mikkel > > On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: > > 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema : > > > > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > > > _If_ we are to allow loose coupling between a load balancer and a > > > server, each of the two should be given the freedom to choose it's ow= n > > > CID encryption scheme. Because all the standardized block ciphers are > > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CI= D > > > length of QUIC needs to be double amount of that, plus one or two > > > bytes for each of the two for identifying the CID encryption keys. Fo= r > > > key identification and other supplemental use, we currently allocate = 2 > > > bytes (18-16=3D2). > > > > That reasoning is based on the assumption that both the load balancer > > and the server must use a block cipher with 128 bit block length in > > order to encrypt the CID. If they were constrained to stay within a > > short global limit, they could use different sets of algorithms. > > > > Assume for example that we split the CID between 32 bits encoding the > > number of the server in the server farm, and 64 bit encoding the > > connection number for the server. The server can pick a random value fo= r > > the connection number, and use a hash table. The load balancer could us= e > > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CI= D > > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > > > > Or assume that the server wants to use short CID. We now split the CID > > between 32 bit for the server number in the farm, and 32 bit for the > > connection number in the server. The server builds that connection > > number by using a 32 bit variant of FFX. The load balancer also uses a > > 32 bit variant, using the lower 32 bit of the CID as initial vector for > > this FFX encryption. > > > > These are just two examples. And yes you may want to add 2 bytes for ke= y > > identification, etc. In both encryption algorithms, you can feed these > > two bytes as additional IV for the FFX algorithm. And in both cases, we > > are well below the 18 byte limit. > > > > Yes, that requires some creative engineering. But it is not rocker > > science. And it seems better than carrying tons of overhead in the > > header, and becoming less efficient than HTTP2/TLS/TCP. > > I agree that it would not be the end of the world for the load > balancers if we decide to stick on the 18-byte limit. However, as you > state, it requires some creativeness. > > To me it seems that the question is if we have a strong reason to > require some people to be creative, for all the versions of QUIC in > the future. I personally think that there isn't a strong reason, > because people can use shorter CIDs regardless of the decision we > make. IIUC, the overhead that everyone needs to accept is: > > * one byte increase in the long header packets > * the minimum size of short header packets becoming slightly greater > (otherwise, the peer might not be able to send a stateless reset) > > I'd say that the first bullet point is negligible. The second point > could also be, because I'd assume that the only frequently-sent > packets that require additional padding is the ACK-only packets, but > there's no reason to pad ACK-only packets in hope that you'd see a > stateless reset. > > Therefore, my (not-so-strong) preference has been to provide extra > room, so that some people with necessity can use longer CIDs. > > > > > -- Christian Huitema > > > > > > > > > > -- > Kazuho Oku > > --00000000000060cd1b058b86c4e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My intuition says making the change to the invariants is t= he right thing to do, but I don't feel that strongly.

However, I'd like the max size to be smaller than 48(but larger than = 18).=C2=A0 If we think 20 or 24 is sufficient, I'd prefer that.=C2=A0 K= azuho suggested 32, which is better, but I don't believe the server nee= ds to use a separate block cipher when giving out connection IDs, because I= believe it's impractical for the load balancer and server to be that d= ecoupled.=C2=A0 The server has to give out a CID that the load balancer wil= l use to route back to the server, so they have to share enough an encrypti= on key/algorithm.=C2=A0 I can imagine nesting load balancers, but that'= s well in the range of QUIC v2 from my perspective.

Whatever we do, I'd really prefer to resolve this sooner rather than = later and be truly done with it.

=
On Mon, Jun 17, 2019 at 2:51 AM Mikke= l Fahn=C3=B8e J=C3=B8rgensen <mikk= elfj@gmail.com> wrote:
Since it is more likely that you= pay for egress traffic than ingress traffic, the motivation to keep CID=E2= =80=99s small is limited.

I do think the invariants should allow for long CID=E2=80=99= s as proposed, and that the long header overhead is not important.

But for QUIC v1, if= we allow for a long CID, a rush to market will set precedence and long CID= =E2=80=99s will ossify in all kinds of stacks.

I good reference on an algorithm like s= uggested by Christian would go a long way.

If CID length 18 turns out to be not enough= , we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuse= s to upgrade QUIC versions soon.

If CID length negotiation is needed, this could be do= ne via QUIC versions. For example two functionally equivalent versions, but= one with longer CID=E2=80=99s. This would also allow routers to deal with = changes in CID lengths. A negotiated TP would not (easily) allow for that a= nd aside I do not think CID length in TP is the way to go.

Mikkel
=

On 17 June 2019 at 0= 6.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019=E5=B9= =B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema <huitema@huitema.net>:
>
> On 6/15/2019 10:55 PM, Kazuho Oku wrote:
>
> > _If_ we are to allow loose coupling between a load balancer a= nd a
> > server, each of the two should be given the freedom to choose= it's own
> > CID encryption scheme. Because all the standardized block cip= hers are
> > now 128-bits (=3D 16 bytes), that naturally means that the ma= ximum CID
> > length of QUIC needs to be double amount of that, plus one or= two
> > bytes for each of the two for identifying the CID encryption = keys. For
> > key identification and other supplemental use, we currently a= llocate 2
> > bytes (18-16=3D2).
>
> That reasoning is based on the assumption that both the load balan= cer
> and the server must use a block cipher with 128 bit block length i= n
> order to encrypt the CID. If they were constrained to stay within = a
> short global limit, they could use different sets of algorithms.
>
> Assume for example that we split the CID between 32 bits encoding = the
> number of the server in the server farm, and 64 bit encoding the
> connection number for the server. The server can pick a random val= ue for
> the connection number, and use a hash table. The load balancer cou= ld use
> a 32 bit variant of the FFX algorithm, using the lower 64 bit of t= he CID
> as an initial vector. Voila, 96 CID, with demonstrably strong encr= yption.
>
> Or assume that the server wants to use short CID. We now split the= CID
> between 32 bit for the server number in the farm, and 32 bit for t= he
> connection number in the server. The server builds that connection
> number by using a 32 bit variant of FFX. The load balancer also us= es a
> 32 bit variant, using the lower 32 bit of the CID as initial vecto= r for
> this FFX encryption.
>
> These are just two examples. And yes you may want to add 2 bytes f= or key
> identification, etc. In both encryption algorithms, you can feed t= hese
> two bytes as additional IV for the FFX algorithm. And in both case= s, we
> are well below the 18 byte limit.
>
> Yes, that requires some creative engineering. But it is not rocker
> science. And it seems better than carrying tons of overhead in the
> header, and becoming less efficient than HTTP2/TLS/TCP.

I agree that it would not be the end of the world for the load
balancers if we decide to stick on the 18-byte limit. However, as you
state, it requires some creativeness.

To me it seems that the question is if we have a strong reason to
require some people to be creative, for all the versions of QUIC in
the future. I personally think that there isn't a strong reason,
because people can use shorter CIDs regardless of the decision we
make. IIUC, the overhead that everyone needs to accept is:

* one byte increase in the long header packets
* the minimum size of short header packets becoming slightly greater
(otherwise, the peer might not be able to send a stateless reset)

I'd say that the first bullet point is negligible. The second point
could also be, because I'd assume that the only frequently-sent
packets that require additional padding is the ACK-only packets, but
there's no reason to pad ACK-only packets in hope that you'd se= e a
stateless reset.

Therefore, my (not-so-strong) preference has been to provide extra
room, so that some people with necessity can use longer CIDs.

>
> -- Christian Huitema
>
>
>



--
Kazuho Oku

--00000000000060cd1b058b86c4e6-- From nobody Mon Jun 17 08:54:50 2019 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 417371201CE for ; Mon, 17 Jun 2019 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnNxX32fsxWR for ; Mon, 17 Jun 2019 08:54:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA5A12018C for ; Mon, 17 Jun 2019 08:54:46 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5HFqL8J029671; Mon, 17 Jun 2019 16:54:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=wGOtYyDioErfwC8zlrOrlqyJJqvHJjaFaVib3bs4qUI=; b=HhEoNRgoLmbvD5UoAW32sJJlnrAoOFjQuSR7eVJbetl8awNK7GHGGyD5Z6IuWGdUWFz2 R2TKXKQaDt2eYKfBToZbMXdiNCFyhhARAoSpYejd5lvj9vmVDmXl9dLSp2Di/DixxbCW sBWc+JtNtus3HSDJyso/78tdHSAUb2ktoTmIsvYsA4SO+IlZuN1HLRBD7SIuo1lKQIxj 5kzuGP8B0CHU15kICMzvX/nTHXQf7hNBg+RMc7XjOBRCXQy3hBCrgOg4d9CAlEc+HDqh LK7uFunA7cY18jp8W9zv5tyaKdGqM5e6MSFPQnVKZVBuw0k0SXOlzYDewbO4+Vz/eu6H HQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2t6awurjaq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Jun 2019 16:54:32 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5HFmHpv013738; Mon, 17 Jun 2019 11:54:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2t4v0vvq42-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Jun 2019 11:54:29 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 10:54:17 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1473.004; Mon, 17 Jun 2019 10:54:17 -0500 From: "Lubashev, Igor" To: Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: "Philipp S. Tiesel" , Dmitri Tikhonov , Mike Bishop , "Martin Duke" , Lars Eggert , Marten Seemann , Christian Huitema , QUIC WG , Martin Thomson , Kazuho Oku Subject: RE: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORfIEAEcQG34kqDfkKYdPIPi6aX4jCAgAGE3YCAAA8NgIAABlqAgAC3vwCAAPW4AIAAk0mAgAFeAoCAAHVigIAAkbsAgAFTDwCAACtYAIAAI0iAgACS+YD//6zYIA== Date: Mon, 17 Jun 2019 15:54:16 +0000 Message-ID: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.49] Content-Type: multipart/alternative; boundary="_000_a8a7c565bfbe438eaaf24c9da01b8e34ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906170140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906170141 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 15:54:49 -0000 --_000_a8a7c565bfbe438eaaf24c9da01b8e34ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgdGFrZSBpcyBzaW1pbGFyIOKAkyA0OCBpcyBwcm9iYWJseSBleGNlc3NpdmUsIHdoaWxlIDMy IGlzIGxpa2VseSB0aGUgdXBwZXIgbGltaXQgb2Yg4oCccmVhc29uYWJsZeKAnSAoaXQgc2hvdWxk IHByb2JhYmx5IGJlIGEgZmFjdG9yIG9mIDgsIHNvIDMyIG9yIDI0PykuDQoNCldlIGFyZSBmaXJt bHkgY29tbWl0dGVkIGZvciB1c2luZyBDSUQgZm9yIGluLWNsdXN0ZXIgbG9hZCBiYWxhbmNpbmcg LyBhbnljYXN0IHBvcCByb3V0aW5nLiAgVGhpcyBkaXNjdXNzaW9uIGlzIHRha2luZyB1cywgaG93 ZXZlciwgdG8gYSBuZXcgdGVycml0b3J5IOKAkyBhIGdlbmVyYWxpemVkIOKAnGRlc3RpbmF0aW9u LWNvbnRyb2xsZWQgcm91dGluZyBpbiBhbiBvdmVybGF5IG5ldHdvcmvigJ0uICBUaGlzIGlzIGEg dmVyeSBpbnRlcmVzdGluZyB0b3BpYywgYnV0IEkgd291bGQgaGVzaXRhdGUgdG8gYXR0ZW1wdCB0 byBzb2x2ZSBpdCBmdWxseSBhbmQg4oCcaW4gZ2VuZXJhbOKAnSBpbiBRVUlDIHYxLg0KDQoNCiAg KiAgIElnb3INCg0KRnJvbTogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMu aWV0Zi5vcmc+DQoNCk15IGludHVpdGlvbiBzYXlzIG1ha2luZyB0aGUgY2hhbmdlIHRvIHRoZSBp bnZhcmlhbnRzIGlzIHRoZSByaWdodCB0aGluZyB0byBkbywgYnV0IEkgZG9uJ3QgZmVlbCB0aGF0 IHN0cm9uZ2x5Lg0KDQpIb3dldmVyLCBJJ2QgbGlrZSB0aGUgbWF4IHNpemUgdG8gYmUgc21hbGxl ciB0aGFuIDQ4KGJ1dCBsYXJnZXIgdGhhbiAxOCkuICBJZiB3ZSB0aGluayAyMCBvciAyNCBpcyBz dWZmaWNpZW50LCBJJ2QgcHJlZmVyIHRoYXQuICBLYXp1aG8gc3VnZ2VzdGVkIDMyLCB3aGljaCBp cyBiZXR0ZXIsIGJ1dCBJIGRvbid0IGJlbGlldmUgdGhlIHNlcnZlciBuZWVkcyB0byB1c2UgYSBz ZXBhcmF0ZSBibG9jayBjaXBoZXIgd2hlbiBnaXZpbmcgb3V0IGNvbm5lY3Rpb24gSURzLCBiZWNh dXNlIEkgYmVsaWV2ZSBpdCdzIGltcHJhY3RpY2FsIGZvciB0aGUgbG9hZCBiYWxhbmNlciBhbmQg c2VydmVyIHRvIGJlIHRoYXQgZGVjb3VwbGVkLiAgVGhlIHNlcnZlciBoYXMgdG8gZ2l2ZSBvdXQg YSBDSUQgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciB3aWxsIHVzZSB0byByb3V0ZSBiYWNrIHRvIHRo ZSBzZXJ2ZXIsIHNvIHRoZXkgaGF2ZSB0byBzaGFyZSBlbm91Z2ggYW4gZW5jcnlwdGlvbiBrZXkv YWxnb3JpdGhtLiAgSSBjYW4gaW1hZ2luZSBuZXN0aW5nIGxvYWQgYmFsYW5jZXJzLCBidXQgdGhh dCdzIHdlbGwgaW4gdGhlIHJhbmdlIG9mIFFVSUMgdjIgZnJvbSBteSBwZXJzcGVjdGl2ZS4NCg0K V2hhdGV2ZXIgd2UgZG8sIEknZCByZWFsbHkgcHJlZmVyIHRvIHJlc29sdmUgdGhpcyBzb29uZXIg cmF0aGVyIHRoYW4gbGF0ZXIgYW5kIGJlIHRydWx5IGRvbmUgd2l0aCBpdC4NCg0KT24gTW9uLCBK dW4gMTcsIDIwMTkgYXQgMjo1MSBBTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxm akBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KU2luY2UgaXQg aXMgbW9yZSBsaWtlbHkgdGhhdCB5b3UgcGF5IGZvciBlZ3Jlc3MgdHJhZmZpYyB0aGFuIGluZ3Jl c3MgdHJhZmZpYywgdGhlIG1vdGl2YXRpb24gdG8ga2VlcCBDSUTigJlzIHNtYWxsIGlzIGxpbWl0 ZWQuDQoNCkkgZG8gdGhpbmsgdGhlIGludmFyaWFudHMgc2hvdWxkIGFsbG93IGZvciBsb25nIENJ ROKAmXMgYXMgcHJvcG9zZWQsIGFuZCB0aGF0IHRoZSBsb25nIGhlYWRlciBvdmVyaGVhZCBpcyBu b3QgaW1wb3J0YW50Lg0KDQpCdXQgZm9yIFFVSUMgdjEsIGlmIHdlIGFsbG93IGZvciBhIGxvbmcg Q0lELCBhIHJ1c2ggdG8gbWFya2V0IHdpbGwgc2V0IHByZWNlZGVuY2UgYW5kIGxvbmcgQ0lE4oCZ cyB3aWxsIG9zc2lmeSBpbiBhbGwga2luZHMgb2Ygc3RhY2tzLg0KDQpJIGdvb2QgcmVmZXJlbmNl IG9uIGFuIGFsZ29yaXRobSBsaWtlIHN1Z2dlc3RlZCBieSBDaHJpc3RpYW4gd291bGQgZ28gYSBs b25nIHdheS4NCg0KSWYgQ0lEIGxlbmd0aCAxOCB0dXJucyBvdXQgdG8gYmUgbm90IGVub3VnaCwg d2UgY2FuIGFkZCBhIFFVSUMgdjIuIEl04oCZcyBub3QgbGlrZSB3ZSBhcmUgbm90IGxvb2tpbmcg Zm9yIGV4Y3VzZXMgdG8gdXBncmFkZSBRVUlDIHZlcnNpb25zIHNvb24uDQoNCklmIENJRCBsZW5n dGggbmVnb3RpYXRpb24gaXMgbmVlZGVkLCB0aGlzIGNvdWxkIGJlIGRvbmUgdmlhIFFVSUMgdmVy c2lvbnMuIEZvciBleGFtcGxlIHR3byBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB2ZXJzaW9ucywg YnV0IG9uZSB3aXRoIGxvbmdlciBDSUTigJlzLiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgcm91dGVy cyB0byBkZWFsIHdpdGggY2hhbmdlcyBpbiBDSUQgbGVuZ3Rocy4gQSBuZWdvdGlhdGVkIFRQIHdv dWxkIG5vdCAoZWFzaWx5KSBhbGxvdyBmb3IgdGhhdCBhbmQgYXNpZGUgSSBkbyBub3QgdGhpbmsg Q0lEIGxlbmd0aCBpbiBUUCBpcyB0aGUgd2F5IHRvIGdvLg0KDQpNaWtrZWwNCg0KDQpPbiAxNyBK dW5lIDIwMTkgYXQgMDYuNDUuMDQsIEthenVobyBPa3UgKGthenVob29rdUBnbWFpbC5jb208bWFp bHRvOmthenVob29rdUBnbWFpbC5jb20+KSB3cm90ZToNCjIwMTnlubQ25pyIMTfml6Uo5pyIKSAx MTowOSBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVt YUBodWl0ZW1hLm5ldD4+Og0KPg0KPiBPbiA2LzE1LzIwMTkgMTA6NTUgUE0sIEthenVobyBPa3Ug d3JvdGU6DQo+DQo+ID4gX0lmXyB3ZSBhcmUgdG8gYWxsb3cgbG9vc2UgY291cGxpbmcgYmV0d2Vl biBhIGxvYWQgYmFsYW5jZXIgYW5kIGENCj4gPiBzZXJ2ZXIsIGVhY2ggb2YgdGhlIHR3byBzaG91 bGQgYmUgZ2l2ZW4gdGhlIGZyZWVkb20gdG8gY2hvb3NlIGl0J3Mgb3duDQo+ID4gQ0lEIGVuY3J5 cHRpb24gc2NoZW1lLiBCZWNhdXNlIGFsbCB0aGUgc3RhbmRhcmRpemVkIGJsb2NrIGNpcGhlcnMg YXJlDQo+ID4gbm93IDEyOC1iaXRzICg9IDE2IGJ5dGVzKSwgdGhhdCBuYXR1cmFsbHkgbWVhbnMg dGhhdCB0aGUgbWF4aW11bSBDSUQNCj4gPiBsZW5ndGggb2YgUVVJQyBuZWVkcyB0byBiZSBkb3Vi bGUgYW1vdW50IG9mIHRoYXQsIHBsdXMgb25lIG9yIHR3bw0KPiA+IGJ5dGVzIGZvciBlYWNoIG9m IHRoZSB0d28gZm9yIGlkZW50aWZ5aW5nIHRoZSBDSUQgZW5jcnlwdGlvbiBrZXlzLiBGb3INCj4g PiBrZXkgaWRlbnRpZmljYXRpb24gYW5kIG90aGVyIHN1cHBsZW1lbnRhbCB1c2UsIHdlIGN1cnJl bnRseSBhbGxvY2F0ZSAyDQo+ID4gYnl0ZXMgKDE4LTE2PTIpLg0KPg0KPiBUaGF0IHJlYXNvbmlu ZyBpcyBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IGJvdGggdGhlIGxvYWQgYmFsYW5jZXIN Cj4gYW5kIHRoZSBzZXJ2ZXIgbXVzdCB1c2UgYSBibG9jayBjaXBoZXIgd2l0aCAxMjggYml0IGJs b2NrIGxlbmd0aCBpbg0KPiBvcmRlciB0byBlbmNyeXB0IHRoZSBDSUQuIElmIHRoZXkgd2VyZSBj b25zdHJhaW5lZCB0byBzdGF5IHdpdGhpbiBhDQo+IHNob3J0IGdsb2JhbCBsaW1pdCwgdGhleSBj b3VsZCB1c2UgZGlmZmVyZW50IHNldHMgb2YgYWxnb3JpdGhtcy4NCj4NCj4gQXNzdW1lIGZvciBl eGFtcGxlIHRoYXQgd2Ugc3BsaXQgdGhlIENJRCBiZXR3ZWVuIDMyIGJpdHMgZW5jb2RpbmcgdGhl DQo+IG51bWJlciBvZiB0aGUgc2VydmVyIGluIHRoZSBzZXJ2ZXIgZmFybSwgYW5kIDY0IGJpdCBl bmNvZGluZyB0aGUNCj4gY29ubmVjdGlvbiBudW1iZXIgZm9yIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2 ZXIgY2FuIHBpY2sgYSByYW5kb20gdmFsdWUgZm9yDQo+IHRoZSBjb25uZWN0aW9uIG51bWJlciwg YW5kIHVzZSBhIGhhc2ggdGFibGUuIFRoZSBsb2FkIGJhbGFuY2VyIGNvdWxkIHVzZQ0KPiBhIDMy IGJpdCB2YXJpYW50IG9mIHRoZSBGRlggYWxnb3JpdGhtLCB1c2luZyB0aGUgbG93ZXIgNjQgYml0 IG9mIHRoZSBDSUQNCj4gYXMgYW4gaW5pdGlhbCB2ZWN0b3IuIFZvaWxhLCA5NiBDSUQsIHdpdGgg ZGVtb25zdHJhYmx5IHN0cm9uZyBlbmNyeXB0aW9uLg0KPg0KPiBPciBhc3N1bWUgdGhhdCB0aGUg c2VydmVyIHdhbnRzIHRvIHVzZSBzaG9ydCBDSUQuIFdlIG5vdyBzcGxpdCB0aGUgQ0lEDQo+IGJl dHdlZW4gMzIgYml0IGZvciB0aGUgc2VydmVyIG51bWJlciBpbiB0aGUgZmFybSwgYW5kIDMyIGJp dCBmb3IgdGhlDQo+IGNvbm5lY3Rpb24gbnVtYmVyIGluIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2ZXIg YnVpbGRzIHRoYXQgY29ubmVjdGlvbg0KPiBudW1iZXIgYnkgdXNpbmcgYSAzMiBiaXQgdmFyaWFu dCBvZiBGRlguIFRoZSBsb2FkIGJhbGFuY2VyIGFsc28gdXNlcyBhDQo+IDMyIGJpdCB2YXJpYW50 LCB1c2luZyB0aGUgbG93ZXIgMzIgYml0IG9mIHRoZSBDSUQgYXMgaW5pdGlhbCB2ZWN0b3IgZm9y DQo+IHRoaXMgRkZYIGVuY3J5cHRpb24uDQo+DQo+IFRoZXNlIGFyZSBqdXN0IHR3byBleGFtcGxl cy4gQW5kIHllcyB5b3UgbWF5IHdhbnQgdG8gYWRkIDIgYnl0ZXMgZm9yIGtleQ0KPiBpZGVudGlm aWNhdGlvbiwgZXRjLiBJbiBib3RoIGVuY3J5cHRpb24gYWxnb3JpdGhtcywgeW91IGNhbiBmZWVk IHRoZXNlDQo+IHR3byBieXRlcyBhcyBhZGRpdGlvbmFsIElWIGZvciB0aGUgRkZYIGFsZ29yaXRo bS4gQW5kIGluIGJvdGggY2FzZXMsIHdlDQo+IGFyZSB3ZWxsIGJlbG93IHRoZSAxOCBieXRlIGxp bWl0Lg0KPg0KPiBZZXMsIHRoYXQgcmVxdWlyZXMgc29tZSBjcmVhdGl2ZSBlbmdpbmVlcmluZy4g QnV0IGl0IGlzIG5vdCByb2NrZXINCj4gc2NpZW5jZS4gQW5kIGl0IHNlZW1zIGJldHRlciB0aGFu IGNhcnJ5aW5nIHRvbnMgb2Ygb3ZlcmhlYWQgaW4gdGhlDQo+IGhlYWRlciwgYW5kIGJlY29taW5n IGxlc3MgZWZmaWNpZW50IHRoYW4gSFRUUDIvVExTL1RDUC4NCg0KSSBhZ3JlZSB0aGF0IGl0IHdv dWxkIG5vdCBiZSB0aGUgZW5kIG9mIHRoZSB3b3JsZCBmb3IgdGhlIGxvYWQNCmJhbGFuY2VycyBp ZiB3ZSBkZWNpZGUgdG8gc3RpY2sgb24gdGhlIDE4LWJ5dGUgbGltaXQuIEhvd2V2ZXIsIGFzIHlv dQ0Kc3RhdGUsIGl0IHJlcXVpcmVzIHNvbWUgY3JlYXRpdmVuZXNzLg0KDQpUbyBtZSBpdCBzZWVt cyB0aGF0IHRoZSBxdWVzdGlvbiBpcyBpZiB3ZSBoYXZlIGEgc3Ryb25nIHJlYXNvbiB0bw0KcmVx dWlyZSBzb21lIHBlb3BsZSB0byBiZSBjcmVhdGl2ZSwgZm9yIGFsbCB0aGUgdmVyc2lvbnMgb2Yg UVVJQyBpbg0KdGhlIGZ1dHVyZS4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgdGhlcmUgaXNuJ3Qg YSBzdHJvbmcgcmVhc29uLA0KYmVjYXVzZSBwZW9wbGUgY2FuIHVzZSBzaG9ydGVyIENJRHMgcmVn YXJkbGVzcyBvZiB0aGUgZGVjaXNpb24gd2UNCm1ha2UuIElJVUMsIHRoZSBvdmVyaGVhZCB0aGF0 IGV2ZXJ5b25lIG5lZWRzIHRvIGFjY2VwdCBpczoNCg0KKiBvbmUgYnl0ZSBpbmNyZWFzZSBpbiB0 aGUgbG9uZyBoZWFkZXIgcGFja2V0cw0KKiB0aGUgbWluaW11bSBzaXplIG9mIHNob3J0IGhlYWRl ciBwYWNrZXRzIGJlY29taW5nIHNsaWdodGx5IGdyZWF0ZXINCihvdGhlcndpc2UsIHRoZSBwZWVy IG1pZ2h0IG5vdCBiZSBhYmxlIHRvIHNlbmQgYSBzdGF0ZWxlc3MgcmVzZXQpDQoNCkknZCBzYXkg dGhhdCB0aGUgZmlyc3QgYnVsbGV0IHBvaW50IGlzIG5lZ2xpZ2libGUuIFRoZSBzZWNvbmQgcG9p bnQNCmNvdWxkIGFsc28gYmUsIGJlY2F1c2UgSSdkIGFzc3VtZSB0aGF0IHRoZSBvbmx5IGZyZXF1 ZW50bHktc2VudA0KcGFja2V0cyB0aGF0IHJlcXVpcmUgYWRkaXRpb25hbCBwYWRkaW5nIGlzIHRo ZSBBQ0stb25seSBwYWNrZXRzLCBidXQNCnRoZXJlJ3Mgbm8gcmVhc29uIHRvIHBhZCBBQ0stb25s eSBwYWNrZXRzIGluIGhvcGUgdGhhdCB5b3UnZCBzZWUgYQ0Kc3RhdGVsZXNzIHJlc2V0Lg0KDQpU aGVyZWZvcmUsIG15IChub3Qtc28tc3Ryb25nKSBwcmVmZXJlbmNlIGhhcyBiZWVuIHRvIHByb3Zp ZGUgZXh0cmENCnJvb20sIHNvIHRoYXQgc29tZSBwZW9wbGUgd2l0aCBuZWNlc3NpdHkgY2FuIHVz ZSBsb25nZXIgQ0lEcy4NCg0KPg0KPiAtLSBDaHJpc3RpYW4gSHVpdGVtYQ0KPg0KPg0KPg0KDQoN Cg0KLS0NCkthenVobyBPa3UNCg== --_000_a8a7c565bfbe438eaaf24c9da01b8e34ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDEx IDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3 IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnAuZ21haWwtbTE4MzQ3ODgwMTAzODUyNDE5MzJhaXJtYWlsb24sIGxpLmdtYWlsLW0x ODM0Nzg4MDEwMzg1MjQxOTMyYWlybWFpbG9uLCBkaXYuZ21haWwtbTE4MzQ3ODgwMTAzODUyNDE5 MzJhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8xODM0Nzg4MDEwMzg1MjQxOTMy YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjE5MDc0NTQzNzQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjYxNTI3Mzg0NCAtMTUwMDYzMjY3MiA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSB0YWtlIGlzIHNpbWlsYXIg4oCTIDQ4IGlz IHByb2JhYmx5IGV4Y2Vzc2l2ZSwgd2hpbGUgMzIgaXMgbGlrZWx5IHRoZSB1cHBlciBsaW1pdCBv ZiDigJxyZWFzb25hYmxl4oCdIChpdCBzaG91bGQgcHJvYmFibHkgYmUgYSBmYWN0b3Igb2YgOCwg c28gMzIgb3IgMjQ/KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXJlIGZpcm1seSBjb21t aXR0ZWQgZm9yIHVzaW5nIENJRCBmb3IgaW4tY2x1c3RlciBsb2FkIGJhbGFuY2luZyAvIGFueWNh c3QgcG9wIHJvdXRpbmcuJm5ic3A7IFRoaXMgZGlzY3Vzc2lvbiBpcyB0YWtpbmcgdXMsIGhvd2V2 ZXIsIHRvIGEgbmV3IHRlcnJpdG9yeSDigJMgYSBnZW5lcmFsaXplZCDigJxkZXN0aW5hdGlvbi1j b250cm9sbGVkIHJvdXRpbmcgaW4gYW4gb3ZlcmxheSBuZXR3b3Jr4oCdLiZuYnNwOyBUaGlzIGlz IGEgdmVyeQ0KIGludGVyZXN0aW5nIHRvcGljLCBidXQgSSB3b3VsZCBoZXNpdGF0ZSB0byBhdHRl bXB0IHRvIHNvbHZlIGl0IGZ1bGx5IGFuZCDigJxpbiBnZW5lcmFs4oCdIGluIFFVSUMgdjEuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj5JZ29yPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dD00MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7DQo8YnI+DQo8YnI+DQo8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TXkgaW50dWl0aW9uIHNheXMgbWFraW5nIHRoZSBjaGFuZ2UgdG8gdGhlIGludmFy aWFudHMgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLCBidXQgSSBkb24ndCBmZWVsIHRoYXQgc3Ry b25nbHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dl dmVyLCBJJ2QgbGlrZSB0aGUgbWF4IHNpemUgdG8gYmUgc21hbGxlciB0aGFuIDQ4KGJ1dCBsYXJn ZXIgdGhhbiAxOCkuJm5ic3A7IElmIHdlIHRoaW5rIDIwIG9yIDI0IGlzIHN1ZmZpY2llbnQsIEkn ZCBwcmVmZXIgdGhhdC4mbmJzcDsgS2F6dWhvIHN1Z2dlc3RlZCAzMiwgd2hpY2ggaXMgYmV0dGVy LCBidXQgSSBkb24ndCBiZWxpZXZlIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gdXNlIGEgc2VwYXJhdGUg YmxvY2sgY2lwaGVyIHdoZW4NCiBnaXZpbmcgb3V0IGNvbm5lY3Rpb24gSURzLCBiZWNhdXNlIEkg YmVsaWV2ZSBpdCdzIGltcHJhY3RpY2FsIGZvciB0aGUgbG9hZCBiYWxhbmNlciBhbmQgc2VydmVy IHRvIGJlIHRoYXQgZGVjb3VwbGVkLiZuYnNwOyBUaGUgc2VydmVyIGhhcyB0byBnaXZlIG91dCBh IENJRCB0aGF0IHRoZSBsb2FkIGJhbGFuY2VyIHdpbGwgdXNlIHRvIHJvdXRlIGJhY2sgdG8gdGhl IHNlcnZlciwgc28gdGhleSBoYXZlIHRvIHNoYXJlIGVub3VnaCBhbiBlbmNyeXB0aW9uIGtleS9h bGdvcml0aG0uJm5ic3A7DQogSSBjYW4gaW1hZ2luZSBuZXN0aW5nIGxvYWQgYmFsYW5jZXJzLCBi dXQgdGhhdCdzIHdlbGwgaW4gdGhlIHJhbmdlIG9mIFFVSUMgdjIgZnJvbSBteSBwZXJzcGVjdGl2 ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hhdGV2ZXIgd2UgZG8sIEknZCByZWFsbHkgcHJlZmVyIHRvIHJlc29sdmUgdGhpcyBzb29uZXIg cmF0aGVyIHRoYW4gbGF0ZXIgYW5kIGJlIHRydWx5IGRvbmUgd2l0aCBpdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMTcs IDIwMTkgYXQgMjo1MSBBTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJt YWlsdG86bWlra2VsZmpAZ21haWwuY29tIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2IGlkPSJn bWFpbC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TaW5jZSBpdCBpcyBtb3Jl IGxpa2VseSB0aGF0IHlvdSBwYXkgZm9yIGVncmVzcyB0cmFmZmljIHRoYW4gaW5ncmVzcyB0cmFm ZmljLCB0aGUgbW90aXZhdGlvbiB0byBrZWVwIENJROKAmXMgc21hbGwgaXMgbGltaXRlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4 NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iZ21haWwtbV8xODM0Nzg4MDEwMzg1MjQxOTMyYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBk byB0aGluayB0aGUgaW52YXJpYW50cyBzaG91bGQgYWxsb3cgZm9yIGxvbmcgQ0lE4oCZcyBhcyBw cm9wb3NlZCwgYW5kIHRoYXQgdGhlIGxvbmcgaGVhZGVyIG92ZXJoZWFkIGlzIG5vdCBpbXBvcnRh bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3 ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4NTI0MTkzMmJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkJ1dCBmb3IgUVVJQyB2MSwgaWYgd2UgYWxsb3cgZm9yIGEgbG9uZyBDSUQsIGEgcnVzaCB0 byBtYXJrZXQgd2lsbCBzZXQgcHJlY2VkZW5jZSBhbmQgbG9uZyBDSUTigJlzIHdpbGwgb3NzaWZ5 IGluIGFsbCBraW5kcyBvZiBzdGFja3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAx MDM4NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgZ29vZCByZWZlcmVuY2Ugb24gYW4gYWxnb3JpdGht IGxpa2Ugc3VnZ2VzdGVkIGJ5IENocmlzdGlhbiB3b3VsZCBnbyBhIGxvbmcgd2F5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8xODM0Nzg4MDEwMzg1MjQx OTMyYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JZiBDSUQg bGVuZ3RoIDE4IHR1cm5zIG91dCB0byBiZSBub3QgZW5vdWdoLCB3ZSBjYW4gYWRkIGEgUVVJQyB2 Mi4gSXTigJlzIG5vdCBsaWtlIHdlIGFyZSBub3QgbG9va2luZyBmb3IgZXhjdXNlcyB0byB1cGdy YWRlIFFVSUMgdmVyc2lvbnMgc29vbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8xODM0Nzg4MDEw Mzg1MjQxOTMyYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgQ0lEIGxlbmd0aCBuZWdvdGlhdGlvbiBpcyBuZWVk ZWQsIHRoaXMgY291bGQgYmUgZG9uZSB2aWEgUVVJQyB2ZXJzaW9ucy4gRm9yIGV4YW1wbGUgdHdv IGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IHZlcnNpb25zLCBidXQgb25lIHdpdGggbG9uZ2VyIENJ ROKAmXMuIFRoaXMgd291bGQNCiBhbHNvIGFsbG93IHJvdXRlcnMgdG8gZGVhbCB3aXRoIGNoYW5n ZXMgaW4gQ0lEIGxlbmd0aHMuIEEgbmVnb3RpYXRlZCBUUCB3b3VsZCBub3QgKGVhc2lseSkgYWxs b3cgZm9yIHRoYXQgYW5kIGFzaWRlIEkgZG8gbm90IHRoaW5rIENJRCBsZW5ndGggaW4gVFAgaXMg dGhlIHdheSB0byBnby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Imdt YWlsLW1fMTgzNDc4ODAxMDM4NTI0MTkzMmJsb29wX3NpZ25fMTU2MDc1MzkzMTgyODE0NTkyMCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NaWtrZWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTE4MzQ3ODgwMTAzODUyNDE5MzJhaXJtYWlsb24iPk9u IDE3IEp1bmUgMjAxOSBhdCAwNi40NS4wNCwgS2F6dWhvIE9rdSAoPGEgaHJlZj0ibWFpbHRvOmth enVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9h Pikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4yMDE5PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjY8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mnIg8L3NwYW4+MTc8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4pIDExOjA5IENo cmlzdGlhbg0KIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0 IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Og0KPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IE9uIDYvMTUvMjAxOSAxMDo1NSBQTSwgS2F6dWhvIE9rdSB3cm90ZTogPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgX0lmXyB3ZSBhcmUgdG8gYWxsb3cgbG9vc2UgY291cGxp bmcgYmV0d2VlbiBhIGxvYWQgYmFsYW5jZXIgYW5kIGEgPGJyPg0KJmd0OyAmZ3Q7IHNlcnZlciwg ZWFjaCBvZiB0aGUgdHdvIHNob3VsZCBiZSBnaXZlbiB0aGUgZnJlZWRvbSB0byBjaG9vc2UgaXQn cyBvd24gPGJyPg0KJmd0OyAmZ3Q7IENJRCBlbmNyeXB0aW9uIHNjaGVtZS4gQmVjYXVzZSBhbGwg dGhlIHN0YW5kYXJkaXplZCBibG9jayBjaXBoZXJzIGFyZSA8YnI+DQomZ3Q7ICZndDsgbm93IDEy OC1iaXRzICg9IDE2IGJ5dGVzKSwgdGhhdCBuYXR1cmFsbHkgbWVhbnMgdGhhdCB0aGUgbWF4aW11 bSBDSUQgPGJyPg0KJmd0OyAmZ3Q7IGxlbmd0aCBvZiBRVUlDIG5lZWRzIHRvIGJlIGRvdWJsZSBh bW91bnQgb2YgdGhhdCwgcGx1cyBvbmUgb3IgdHdvIDxicj4NCiZndDsgJmd0OyBieXRlcyBmb3Ig ZWFjaCBvZiB0aGUgdHdvIGZvciBpZGVudGlmeWluZyB0aGUgQ0lEIGVuY3J5cHRpb24ga2V5cy4g Rm9yIDxicj4NCiZndDsgJmd0OyBrZXkgaWRlbnRpZmljYXRpb24gYW5kIG90aGVyIHN1cHBsZW1l bnRhbCB1c2UsIHdlIGN1cnJlbnRseSBhbGxvY2F0ZSAyIDxicj4NCiZndDsgJmd0OyBieXRlcyAo MTgtMTY9MikuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IHJlYXNvbmluZyBpcyBiYXNlZCBv biB0aGUgYXNzdW1wdGlvbiB0aGF0IGJvdGggdGhlIGxvYWQgYmFsYW5jZXIgPGJyPg0KJmd0OyBh bmQgdGhlIHNlcnZlciBtdXN0IHVzZSBhIGJsb2NrIGNpcGhlciB3aXRoIDEyOCBiaXQgYmxvY2sg bGVuZ3RoIGluIDxicj4NCiZndDsgb3JkZXIgdG8gZW5jcnlwdCB0aGUgQ0lELiBJZiB0aGV5IHdl cmUgY29uc3RyYWluZWQgdG8gc3RheSB3aXRoaW4gYSA8YnI+DQomZ3Q7IHNob3J0IGdsb2JhbCBs aW1pdCwgdGhleSBjb3VsZCB1c2UgZGlmZmVyZW50IHNldHMgb2YgYWxnb3JpdGhtcy4gPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEFzc3VtZSBmb3IgZXhhbXBsZSB0aGF0IHdlIHNwbGl0IHRoZSBDSUQg YmV0d2VlbiAzMiBiaXRzIGVuY29kaW5nIHRoZSA8YnI+DQomZ3Q7IG51bWJlciBvZiB0aGUgc2Vy dmVyIGluIHRoZSBzZXJ2ZXIgZmFybSwgYW5kIDY0IGJpdCBlbmNvZGluZyB0aGUgPGJyPg0KJmd0 OyBjb25uZWN0aW9uIG51bWJlciBmb3IgdGhlIHNlcnZlci4gVGhlIHNlcnZlciBjYW4gcGljayBh IHJhbmRvbSB2YWx1ZSBmb3IgPGJyPg0KJmd0OyB0aGUgY29ubmVjdGlvbiBudW1iZXIsIGFuZCB1 c2UgYSBoYXNoIHRhYmxlLiBUaGUgbG9hZCBiYWxhbmNlciBjb3VsZCB1c2UgPGJyPg0KJmd0OyBh IDMyIGJpdCB2YXJpYW50IG9mIHRoZSBGRlggYWxnb3JpdGhtLCB1c2luZyB0aGUgbG93ZXIgNjQg Yml0IG9mIHRoZSBDSUQgPGJyPg0KJmd0OyBhcyBhbiBpbml0aWFsIHZlY3Rvci4gVm9pbGEsIDk2 IENJRCwgd2l0aCBkZW1vbnN0cmFibHkgc3Ryb25nIGVuY3J5cHRpb24uIDxicj4NCiZndDsgPGJy Pg0KJmd0OyBPciBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdhbnRzIHRvIHVzZSBzaG9ydCBDSUQu IFdlIG5vdyBzcGxpdCB0aGUgQ0lEIDxicj4NCiZndDsgYmV0d2VlbiAzMiBiaXQgZm9yIHRoZSBz ZXJ2ZXIgbnVtYmVyIGluIHRoZSBmYXJtLCBhbmQgMzIgYml0IGZvciB0aGUgPGJyPg0KJmd0OyBj b25uZWN0aW9uIG51bWJlciBpbiB0aGUgc2VydmVyLiBUaGUgc2VydmVyIGJ1aWxkcyB0aGF0IGNv bm5lY3Rpb24gPGJyPg0KJmd0OyBudW1iZXIgYnkgdXNpbmcgYSAzMiBiaXQgdmFyaWFudCBvZiBG RlguIFRoZSBsb2FkIGJhbGFuY2VyIGFsc28gdXNlcyBhIDxicj4NCiZndDsgMzIgYml0IHZhcmlh bnQsIHVzaW5nIHRoZSBsb3dlciAzMiBiaXQgb2YgdGhlIENJRCBhcyBpbml0aWFsIHZlY3RvciBm b3IgPGJyPg0KJmd0OyB0aGlzIEZGWCBlbmNyeXB0aW9uLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhlc2UgYXJlIGp1c3QgdHdvIGV4YW1wbGVzLiBBbmQgeWVzIHlvdSBtYXkgd2FudCB0byBhZGQg MiBieXRlcyBmb3Iga2V5IDxicj4NCiZndDsgaWRlbnRpZmljYXRpb24sIGV0Yy4gSW4gYm90aCBl bmNyeXB0aW9uIGFsZ29yaXRobXMsIHlvdSBjYW4gZmVlZCB0aGVzZSA8YnI+DQomZ3Q7IHR3byBi eXRlcyBhcyBhZGRpdGlvbmFsIElWIGZvciB0aGUgRkZYIGFsZ29yaXRobS4gQW5kIGluIGJvdGgg Y2FzZXMsIHdlIDxicj4NCiZndDsgYXJlIHdlbGwgYmVsb3cgdGhlIDE4IGJ5dGUgbGltaXQuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBZZXMsIHRoYXQgcmVxdWlyZXMgc29tZSBjcmVhdGl2ZSBlbmdp bmVlcmluZy4gQnV0IGl0IGlzIG5vdCByb2NrZXIgPGJyPg0KJmd0OyBzY2llbmNlLiBBbmQgaXQg c2VlbXMgYmV0dGVyIHRoYW4gY2FycnlpbmcgdG9ucyBvZiBvdmVyaGVhZCBpbiB0aGUgPGJyPg0K Jmd0OyBoZWFkZXIsIGFuZCBiZWNvbWluZyBsZXNzIGVmZmljaWVudCB0aGFuIEhUVFAyL1RMUy9U Q1AuIDxicj4NCjxicj4NCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBub3QgYmUgdGhlIGVuZCBvZiB0 aGUgd29ybGQgZm9yIHRoZSBsb2FkIDxicj4NCmJhbGFuY2VycyBpZiB3ZSBkZWNpZGUgdG8gc3Rp Y2sgb24gdGhlIDE4LWJ5dGUgbGltaXQuIEhvd2V2ZXIsIGFzIHlvdSA8YnI+DQpzdGF0ZSwgaXQg cmVxdWlyZXMgc29tZSBjcmVhdGl2ZW5lc3MuIDxicj4NCjxicj4NClRvIG1lIGl0IHNlZW1zIHRo YXQgdGhlIHF1ZXN0aW9uIGlzIGlmIHdlIGhhdmUgYSBzdHJvbmcgcmVhc29uIHRvIDxicj4NCnJl cXVpcmUgc29tZSBwZW9wbGUgdG8gYmUgY3JlYXRpdmUsIGZvciBhbGwgdGhlIHZlcnNpb25zIG9m IFFVSUMgaW4gPGJyPg0KdGhlIGZ1dHVyZS4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgdGhlcmUg aXNuJ3QgYSBzdHJvbmcgcmVhc29uLCA8YnI+DQpiZWNhdXNlIHBlb3BsZSBjYW4gdXNlIHNob3J0 ZXIgQ0lEcyByZWdhcmRsZXNzIG9mIHRoZSBkZWNpc2lvbiB3ZSA8YnI+DQptYWtlLiBJSVVDLCB0 aGUgb3ZlcmhlYWQgdGhhdCBldmVyeW9uZSBuZWVkcyB0byBhY2NlcHQgaXM6IDxicj4NCjxicj4N Ciogb25lIGJ5dGUgaW5jcmVhc2UgaW4gdGhlIGxvbmcgaGVhZGVyIHBhY2tldHMgPGJyPg0KKiB0 aGUgbWluaW11bSBzaXplIG9mIHNob3J0IGhlYWRlciBwYWNrZXRzIGJlY29taW5nIHNsaWdodGx5 IGdyZWF0ZXIgPGJyPg0KKG90aGVyd2lzZSwgdGhlIHBlZXIgbWlnaHQgbm90IGJlIGFibGUgdG8g c2VuZCBhIHN0YXRlbGVzcyByZXNldCkgPGJyPg0KPGJyPg0KSSdkIHNheSB0aGF0IHRoZSBmaXJz dCBidWxsZXQgcG9pbnQgaXMgbmVnbGlnaWJsZS4gVGhlIHNlY29uZCBwb2ludCA8YnI+DQpjb3Vs ZCBhbHNvIGJlLCBiZWNhdXNlIEknZCBhc3N1bWUgdGhhdCB0aGUgb25seSBmcmVxdWVudGx5LXNl bnQgPGJyPg0KcGFja2V0cyB0aGF0IHJlcXVpcmUgYWRkaXRpb25hbCBwYWRkaW5nIGlzIHRoZSBB Q0stb25seSBwYWNrZXRzLCBidXQgPGJyPg0KdGhlcmUncyBubyByZWFzb24gdG8gcGFkIEFDSy1v bmx5IHBhY2tldHMgaW4gaG9wZSB0aGF0IHlvdSdkIHNlZSBhIDxicj4NCnN0YXRlbGVzcyByZXNl dC4gPGJyPg0KPGJyPg0KVGhlcmVmb3JlLCBteSAobm90LXNvLXN0cm9uZykgcHJlZmVyZW5jZSBo YXMgYmVlbiB0byBwcm92aWRlIGV4dHJhIDxicj4NCnJvb20sIHNvIHRoYXQgc29tZSBwZW9wbGUg d2l0aCBuZWNlc3NpdHkgY2FuIHVzZSBsb25nZXIgQ0lEcy4gPGJyPg0KPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IC0tIENocmlzdGlhbiBIdWl0ZW1hIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3UgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a8a7c565bfbe438eaaf24c9da01b8e34ustx2exdag1mb5msgcorpak_-- From nobody Mon Jun 17 09:17:38 2019 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 1AC6912034E for ; Mon, 17 Jun 2019 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=bmWeGoZm; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=pKbPObhf 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 ZvzePeZ4mN6Z for ; Mon, 17 Jun 2019 09:17:31 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57CF120328 for ; Mon, 17 Jun 2019 09:17:12 -0700 (PDT) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5HGBMrr015800; Mon, 17 Jun 2019 09:16:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=TjKtkuStozl61VWLjAoBYoGKDIiYVxjMlBLqqGqvvl4=; b=bmWeGoZm38Tis3TFbzW2rae7EREwWGvaQ3zn3GSf86NyNQ8GMTt27Jkv89HaQZPd1aVI 9Ys2UqnXu+fMBvAVCA1U7lpFdTXZJGI8hgHWvuV7vsEia0vR9TFN/3BmyGb9DtoCVpIc sSGBymJ1NaSb6oOJkkISOhCTYkagLTgZtu8= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2t66mehdxr-18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 17 Jun 2019 09:16:56 -0700 Received: from ash-exhub104.TheFacebook.com (2620:10d:c0a8:82::d) by ash-exhub101.TheFacebook.com (2620:10d:c0a8:82::e) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 17 Jun 2019 09:16:40 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 17 Jun 2019 09:16:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TjKtkuStozl61VWLjAoBYoGKDIiYVxjMlBLqqGqvvl4=; b=pKbPObhfkJxm2LG6xTlU7a40beAysTDML3ppYZBNrp03+YbFDFdW4TNgCBEcrDPwaDMHv95PYfQ+yBqv/oJZ7j7uEqGTN2dHDKZ+fwl0fuOpV/n7HQryTrHkDjWmo9HenS0X6NR00F2TDzCJNYqRhmsyH0g4vTUKNHGK1T0kp0A= Received: from CY4PR15MB1542.namprd15.prod.outlook.com (10.172.160.9) by CY4PR15MB1782.namprd15.prod.outlook.com (10.174.53.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Mon, 17 Jun 2019 16:16:35 +0000 Received: from CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a]) by CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a%9]) with mapi id 15.20.1987.014; Mon, 17 Jun 2019 16:16:35 +0000 From: Roberto Peon To: "Lubashev, Igor" , Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Dmitri Tikhonov , Christian Huitema , "Philipp S. Tiesel" , Mike Bishop , Martin Thomson , Marten Seemann , Lars Eggert , QUIC WG , Martin Duke , Kazuho Oku Subject: Re: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORjFtUmRAvDTkuJte7HuW7cSKaXjl6AgAGE3YCAAA8NgIAABlqAgAC3vwCAAPW4AIAAccKAgAF/iYCAAHVjgIAAkboAgAFTDwCAACtYAIAAI0iAgACS+YCAAATjAP//kOOA Date: Mon, 17 Jun 2019 16:16:35 +0000 Message-ID: <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-originating-ip: [2620:10d:c090:200::1:ade4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f08e4a5a-23be-462b-cbd2-08d6f33f2b8e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR15MB1782; x-ms-traffictypediagnostic: CY4PR15MB1782: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(136003)(376002)(39860400002)(189003)(199004)(71200400001)(66574012)(14454004)(236005)(5660300002)(54896002)(6306002)(99286004)(7736002)(14444005)(68736007)(53936002)(256004)(6512007)(71190400001)(7416002)(76176011)(36756003)(86362001)(76116006)(25786009)(4326008)(486006)(229853002)(81156014)(91956017)(6246003)(66556008)(66946007)(73956011)(66476007)(64756008)(66446008)(316002)(6436002)(6116002)(53546011)(33656002)(6506007)(2906002)(478600001)(81166006)(5070765005)(54906003)(110136005)(440504004)(102836004)(8936002)(58126008)(517774005)(446003)(8676002)(476003)(11346002)(2616005)(6486002)(186003)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1782; H:CY4PR15MB1542.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EaNy0JVyyS4ITRSjoTgBFiR8mN6PK0I+h7L37IX+QjK2I4afl9oIbvdt3ZfJ2SVzCTV9YKMot/faJH18dV3pUYfm7EenimyCsArxhgCNyBgWlu2mXzlD9fuMEr1g0GzhwY+43Wg0yFgEr8sfy9CuDv3x6s17PZJsgOqybIa2SxhItv2IbUujqzJ7jgdeJXWa0JV5pLk4LAw4oj3CmtptxOHu01f0d6rN3KvVlarBduOGa6jV8Vp6OnfK2waXgN3ytVufIcYcoElCh2mkU5fhOScfOLe3nADmixfyiQyUmiLPLqd9TNRZ6l5nUadDIhPbXrlQN+gcgQVqNhl1i4YEC1kGxzzlov8xA+G/K8jl1yED+UOubJAcWXKO5yiP/zMWPI0kwBDVsK95ngKdodXGVq1MgFCoV4rvffS/SaOg9rw= Content-Type: multipart/alternative; boundary="_000_91E94F47B6D24746994A15B84578B174fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f08e4a5a-23be-462b-cbd2-08d6f33f2b8e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 16:16:35.7210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fenix@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1782 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-17_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906170144 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 16:17:37 -0000 --_000_91E94F47B6D24746994A15B84578B174fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBJIHRoaW5rIHBlb3BsZSBhcmUgc2F5aW5nIHNvIGZhcjoNCiAgMSkgUVVJQyB2MSB3b3Vs ZCBsaW1pdCBDSUQgbGVuZ3RoIHRvIHNvbWV0aGluZyBvbmUgb2YgezMyLCAzNiwgb3IgNDh9DQog ICAyKSBSZXByZXNlbnRhdGlvbiBvZiBDSUQgbGVuZ3RoIGFzIGEgYnl0ZSBpcyBzdGlsbCBPSywg dGh1cyBhIFFVSUMgdjIgY291bGQgdXNlIGxvbmdlciBDSURzIGFzIG5lZWRlZCBieSBjaGFuZ2lu ZyB0aGUgc3BlYyB3aGlsZSBrZWVwaW5nIHRoZSBpbnZhcmlhbnRz4oCmIGludmFyaWFudC4NCg0K VGhhdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIC8gSeKAmWQgc3RpbGwgc3VwcG9ydCB0aGF0Lg0K LT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJM dWJhc2hldiwgSWdvciIgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpEYXRlOiBNb25kYXksIEp1bmUg MTcsIDIwMTkgYXQgODo1NSBBTQ0KVG86IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29t QGRtYXJjLmlldGYub3JnPiwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21h aWwuY29tPg0KQ2M6IERtaXRyaSBUaWtob25vdiA8ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29t PiwgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+LCAiUGhpbGlwcCBTLiBU aWVzZWwiIDxwaGlsaXBwQHRpZXNlbC5uZXQ+LCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVm b3UuYmU+LCBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ+LCBNYXJ0ZW4gU2VlbWFu biA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+LCBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3Jn PiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbT4sIEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSRTog Q29uc2Vuc3VzIENhbGw6IE1vcmUgQ29ubmVjdGlvbiBJRCBTcGFjZSAjMjczNg0KDQpNeSB0YWtl IGlzIHNpbWlsYXIg4oCTIDQ4IGlzIHByb2JhYmx5IGV4Y2Vzc2l2ZSwgd2hpbGUgMzIgaXMgbGlr ZWx5IHRoZSB1cHBlciBsaW1pdCBvZiDigJxyZWFzb25hYmxl4oCdIChpdCBzaG91bGQgcHJvYmFi bHkgYmUgYSBmYWN0b3Igb2YgOCwgc28gMzIgb3IgMjQ/KS4NCg0KV2UgYXJlIGZpcm1seSBjb21t aXR0ZWQgZm9yIHVzaW5nIENJRCBmb3IgaW4tY2x1c3RlciBsb2FkIGJhbGFuY2luZyAvIGFueWNh c3QgcG9wIHJvdXRpbmcuICBUaGlzIGRpc2N1c3Npb24gaXMgdGFraW5nIHVzLCBob3dldmVyLCB0 byBhIG5ldyB0ZXJyaXRvcnkg4oCTIGEgZ2VuZXJhbGl6ZWQg4oCcZGVzdGluYXRpb24tY29udHJv bGxlZCByb3V0aW5nIGluIGFuIG92ZXJsYXkgbmV0d29ya+KAnS4gIFRoaXMgaXMgYSB2ZXJ5IGlu dGVyZXN0aW5nIHRvcGljLCBidXQgSSB3b3VsZCBoZXNpdGF0ZSB0byBhdHRlbXB0IHRvIHNvbHZl IGl0IGZ1bGx5IGFuZCDigJxpbiBnZW5lcmFs4oCdIGluIFFVSUMgdjEuDQoNCg0KICAqICAgSWdv cg0KDQpGcm9tOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y Zz4NCk15IGludHVpdGlvbiBzYXlzIG1ha2luZyB0aGUgY2hhbmdlIHRvIHRoZSBpbnZhcmlhbnRz IGlzIHRoZSByaWdodCB0aGluZyB0byBkbywgYnV0IEkgZG9uJ3QgZmVlbCB0aGF0IHN0cm9uZ2x5 Lg0KDQpIb3dldmVyLCBJJ2QgbGlrZSB0aGUgbWF4IHNpemUgdG8gYmUgc21hbGxlciB0aGFuIDQ4 KGJ1dCBsYXJnZXIgdGhhbiAxOCkuICBJZiB3ZSB0aGluayAyMCBvciAyNCBpcyBzdWZmaWNpZW50 LCBJJ2QgcHJlZmVyIHRoYXQuICBLYXp1aG8gc3VnZ2VzdGVkIDMyLCB3aGljaCBpcyBiZXR0ZXIs IGJ1dCBJIGRvbid0IGJlbGlldmUgdGhlIHNlcnZlciBuZWVkcyB0byB1c2UgYSBzZXBhcmF0ZSBi bG9jayBjaXBoZXIgd2hlbiBnaXZpbmcgb3V0IGNvbm5lY3Rpb24gSURzLCBiZWNhdXNlIEkgYmVs aWV2ZSBpdCdzIGltcHJhY3RpY2FsIGZvciB0aGUgbG9hZCBiYWxhbmNlciBhbmQgc2VydmVyIHRv IGJlIHRoYXQgZGVjb3VwbGVkLiAgVGhlIHNlcnZlciBoYXMgdG8gZ2l2ZSBvdXQgYSBDSUQgdGhh dCB0aGUgbG9hZCBiYWxhbmNlciB3aWxsIHVzZSB0byByb3V0ZSBiYWNrIHRvIHRoZSBzZXJ2ZXIs IHNvIHRoZXkgaGF2ZSB0byBzaGFyZSBlbm91Z2ggYW4gZW5jcnlwdGlvbiBrZXkvYWxnb3JpdGht LiAgSSBjYW4gaW1hZ2luZSBuZXN0aW5nIGxvYWQgYmFsYW5jZXJzLCBidXQgdGhhdCdzIHdlbGwg aW4gdGhlIHJhbmdlIG9mIFFVSUMgdjIgZnJvbSBteSBwZXJzcGVjdGl2ZS4NCg0KV2hhdGV2ZXIg d2UgZG8sIEknZCByZWFsbHkgcHJlZmVyIHRvIHJlc29sdmUgdGhpcyBzb29uZXIgcmF0aGVyIHRo YW4gbGF0ZXIgYW5kIGJlIHRydWx5IGRvbmUgd2l0aCBpdC4NCg0KT24gTW9uLCBKdW4gMTcsIDIw MTkgYXQgMjo1MSBBTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5j b208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KU2luY2UgaXQgaXMgbW9yZSBs aWtlbHkgdGhhdCB5b3UgcGF5IGZvciBlZ3Jlc3MgdHJhZmZpYyB0aGFuIGluZ3Jlc3MgdHJhZmZp YywgdGhlIG1vdGl2YXRpb24gdG8ga2VlcCBDSUTigJlzIHNtYWxsIGlzIGxpbWl0ZWQuDQoNCkkg ZG8gdGhpbmsgdGhlIGludmFyaWFudHMgc2hvdWxkIGFsbG93IGZvciBsb25nIENJROKAmXMgYXMg cHJvcG9zZWQsIGFuZCB0aGF0IHRoZSBsb25nIGhlYWRlciBvdmVyaGVhZCBpcyBub3QgaW1wb3J0 YW50Lg0KDQpCdXQgZm9yIFFVSUMgdjEsIGlmIHdlIGFsbG93IGZvciBhIGxvbmcgQ0lELCBhIHJ1 c2ggdG8gbWFya2V0IHdpbGwgc2V0IHByZWNlZGVuY2UgYW5kIGxvbmcgQ0lE4oCZcyB3aWxsIG9z c2lmeSBpbiBhbGwga2luZHMgb2Ygc3RhY2tzLg0KDQpJIGdvb2QgcmVmZXJlbmNlIG9uIGFuIGFs Z29yaXRobSBsaWtlIHN1Z2dlc3RlZCBieSBDaHJpc3RpYW4gd291bGQgZ28gYSBsb25nIHdheS4N Cg0KSWYgQ0lEIGxlbmd0aCAxOCB0dXJucyBvdXQgdG8gYmUgbm90IGVub3VnaCwgd2UgY2FuIGFk ZCBhIFFVSUMgdjIuIEl04oCZcyBub3QgbGlrZSB3ZSBhcmUgbm90IGxvb2tpbmcgZm9yIGV4Y3Vz ZXMgdG8gdXBncmFkZSBRVUlDIHZlcnNpb25zIHNvb24uDQoNCklmIENJRCBsZW5ndGggbmVnb3Rp YXRpb24gaXMgbmVlZGVkLCB0aGlzIGNvdWxkIGJlIGRvbmUgdmlhIFFVSUMgdmVyc2lvbnMuIEZv ciBleGFtcGxlIHR3byBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB2ZXJzaW9ucywgYnV0IG9uZSB3 aXRoIGxvbmdlciBDSUTigJlzLiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgcm91dGVycyB0byBkZWFs IHdpdGggY2hhbmdlcyBpbiBDSUQgbGVuZ3Rocy4gQSBuZWdvdGlhdGVkIFRQIHdvdWxkIG5vdCAo ZWFzaWx5KSBhbGxvdyBmb3IgdGhhdCBhbmQgYXNpZGUgSSBkbyBub3QgdGhpbmsgQ0lEIGxlbmd0 aCBpbiBUUCBpcyB0aGUgd2F5IHRvIGdvLg0KDQpNaWtrZWwNCg0KDQpPbiAxNyBKdW5lIDIwMTkg YXQgMDYuNDUuMDQsIEthenVobyBPa3UgKGthenVob29rdUBnbWFpbC5jb208bWFpbHRvOmthenVo b29rdUBnbWFpbC5jb20+KSB3cm90ZToNCjIwMTnlubQ25pyIMTfml6Uo5pyIKSAxMTowOSBDaHJp c3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1h Lm5ldD4+Og0KPg0KPiBPbiA2LzE1LzIwMTkgMTA6NTUgUE0sIEthenVobyBPa3Ugd3JvdGU6DQo+ DQo+ID4gX0lmXyB3ZSBhcmUgdG8gYWxsb3cgbG9vc2UgY291cGxpbmcgYmV0d2VlbiBhIGxvYWQg YmFsYW5jZXIgYW5kIGENCj4gPiBzZXJ2ZXIsIGVhY2ggb2YgdGhlIHR3byBzaG91bGQgYmUgZ2l2 ZW4gdGhlIGZyZWVkb20gdG8gY2hvb3NlIGl0J3Mgb3duDQo+ID4gQ0lEIGVuY3J5cHRpb24gc2No ZW1lLiBCZWNhdXNlIGFsbCB0aGUgc3RhbmRhcmRpemVkIGJsb2NrIGNpcGhlcnMgYXJlDQo+ID4g bm93IDEyOC1iaXRzICg9IDE2IGJ5dGVzKSwgdGhhdCBuYXR1cmFsbHkgbWVhbnMgdGhhdCB0aGUg bWF4aW11bSBDSUQNCj4gPiBsZW5ndGggb2YgUVVJQyBuZWVkcyB0byBiZSBkb3VibGUgYW1vdW50 IG9mIHRoYXQsIHBsdXMgb25lIG9yIHR3bw0KPiA+IGJ5dGVzIGZvciBlYWNoIG9mIHRoZSB0d28g Zm9yIGlkZW50aWZ5aW5nIHRoZSBDSUQgZW5jcnlwdGlvbiBrZXlzLiBGb3INCj4gPiBrZXkgaWRl bnRpZmljYXRpb24gYW5kIG90aGVyIHN1cHBsZW1lbnRhbCB1c2UsIHdlIGN1cnJlbnRseSBhbGxv Y2F0ZSAyDQo+ID4gYnl0ZXMgKDE4LTE2PTIpLg0KPg0KPiBUaGF0IHJlYXNvbmluZyBpcyBiYXNl ZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IGJvdGggdGhlIGxvYWQgYmFsYW5jZXINCj4gYW5kIHRo ZSBzZXJ2ZXIgbXVzdCB1c2UgYSBibG9jayBjaXBoZXIgd2l0aCAxMjggYml0IGJsb2NrIGxlbmd0 aCBpbg0KPiBvcmRlciB0byBlbmNyeXB0IHRoZSBDSUQuIElmIHRoZXkgd2VyZSBjb25zdHJhaW5l ZCB0byBzdGF5IHdpdGhpbiBhDQo+IHNob3J0IGdsb2JhbCBsaW1pdCwgdGhleSBjb3VsZCB1c2Ug ZGlmZmVyZW50IHNldHMgb2YgYWxnb3JpdGhtcy4NCj4NCj4gQXNzdW1lIGZvciBleGFtcGxlIHRo YXQgd2Ugc3BsaXQgdGhlIENJRCBiZXR3ZWVuIDMyIGJpdHMgZW5jb2RpbmcgdGhlDQo+IG51bWJl ciBvZiB0aGUgc2VydmVyIGluIHRoZSBzZXJ2ZXIgZmFybSwgYW5kIDY0IGJpdCBlbmNvZGluZyB0 aGUNCj4gY29ubmVjdGlvbiBudW1iZXIgZm9yIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2ZXIgY2FuIHBp Y2sgYSByYW5kb20gdmFsdWUgZm9yDQo+IHRoZSBjb25uZWN0aW9uIG51bWJlciwgYW5kIHVzZSBh IGhhc2ggdGFibGUuIFRoZSBsb2FkIGJhbGFuY2VyIGNvdWxkIHVzZQ0KPiBhIDMyIGJpdCB2YXJp YW50IG9mIHRoZSBGRlggYWxnb3JpdGhtLCB1c2luZyB0aGUgbG93ZXIgNjQgYml0IG9mIHRoZSBD SUQNCj4gYXMgYW4gaW5pdGlhbCB2ZWN0b3IuIFZvaWxhLCA5NiBDSUQsIHdpdGggZGVtb25zdHJh Ymx5IHN0cm9uZyBlbmNyeXB0aW9uLg0KPg0KPiBPciBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdh bnRzIHRvIHVzZSBzaG9ydCBDSUQuIFdlIG5vdyBzcGxpdCB0aGUgQ0lEDQo+IGJldHdlZW4gMzIg Yml0IGZvciB0aGUgc2VydmVyIG51bWJlciBpbiB0aGUgZmFybSwgYW5kIDMyIGJpdCBmb3IgdGhl DQo+IGNvbm5lY3Rpb24gbnVtYmVyIGluIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2ZXIgYnVpbGRzIHRo YXQgY29ubmVjdGlvbg0KPiBudW1iZXIgYnkgdXNpbmcgYSAzMiBiaXQgdmFyaWFudCBvZiBGRlgu IFRoZSBsb2FkIGJhbGFuY2VyIGFsc28gdXNlcyBhDQo+IDMyIGJpdCB2YXJpYW50LCB1c2luZyB0 aGUgbG93ZXIgMzIgYml0IG9mIHRoZSBDSUQgYXMgaW5pdGlhbCB2ZWN0b3IgZm9yDQo+IHRoaXMg RkZYIGVuY3J5cHRpb24uDQo+DQo+IFRoZXNlIGFyZSBqdXN0IHR3byBleGFtcGxlcy4gQW5kIHll cyB5b3UgbWF5IHdhbnQgdG8gYWRkIDIgYnl0ZXMgZm9yIGtleQ0KPiBpZGVudGlmaWNhdGlvbiwg ZXRjLiBJbiBib3RoIGVuY3J5cHRpb24gYWxnb3JpdGhtcywgeW91IGNhbiBmZWVkIHRoZXNlDQo+ IHR3byBieXRlcyBhcyBhZGRpdGlvbmFsIElWIGZvciB0aGUgRkZYIGFsZ29yaXRobS4gQW5kIGlu IGJvdGggY2FzZXMsIHdlDQo+IGFyZSB3ZWxsIGJlbG93IHRoZSAxOCBieXRlIGxpbWl0Lg0KPg0K PiBZZXMsIHRoYXQgcmVxdWlyZXMgc29tZSBjcmVhdGl2ZSBlbmdpbmVlcmluZy4gQnV0IGl0IGlz IG5vdCByb2NrZXINCj4gc2NpZW5jZS4gQW5kIGl0IHNlZW1zIGJldHRlciB0aGFuIGNhcnJ5aW5n IHRvbnMgb2Ygb3ZlcmhlYWQgaW4gdGhlDQo+IGhlYWRlciwgYW5kIGJlY29taW5nIGxlc3MgZWZm aWNpZW50IHRoYW4gSFRUUDIvVExTL1RDUC4NCg0KSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIG5vdCBi ZSB0aGUgZW5kIG9mIHRoZSB3b3JsZCBmb3IgdGhlIGxvYWQNCmJhbGFuY2VycyBpZiB3ZSBkZWNp ZGUgdG8gc3RpY2sgb24gdGhlIDE4LWJ5dGUgbGltaXQuIEhvd2V2ZXIsIGFzIHlvdQ0Kc3RhdGUs IGl0IHJlcXVpcmVzIHNvbWUgY3JlYXRpdmVuZXNzLg0KDQpUbyBtZSBpdCBzZWVtcyB0aGF0IHRo ZSBxdWVzdGlvbiBpcyBpZiB3ZSBoYXZlIGEgc3Ryb25nIHJlYXNvbiB0bw0KcmVxdWlyZSBzb21l IHBlb3BsZSB0byBiZSBjcmVhdGl2ZSwgZm9yIGFsbCB0aGUgdmVyc2lvbnMgb2YgUVVJQyBpbg0K dGhlIGZ1dHVyZS4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgdGhlcmUgaXNuJ3QgYSBzdHJvbmcg cmVhc29uLA0KYmVjYXVzZSBwZW9wbGUgY2FuIHVzZSBzaG9ydGVyIENJRHMgcmVnYXJkbGVzcyBv ZiB0aGUgZGVjaXNpb24gd2UNCm1ha2UuIElJVUMsIHRoZSBvdmVyaGVhZCB0aGF0IGV2ZXJ5b25l IG5lZWRzIHRvIGFjY2VwdCBpczoNCg0KKiBvbmUgYnl0ZSBpbmNyZWFzZSBpbiB0aGUgbG9uZyBo ZWFkZXIgcGFja2V0cw0KKiB0aGUgbWluaW11bSBzaXplIG9mIHNob3J0IGhlYWRlciBwYWNrZXRz IGJlY29taW5nIHNsaWdodGx5IGdyZWF0ZXINCihvdGhlcndpc2UsIHRoZSBwZWVyIG1pZ2h0IG5v dCBiZSBhYmxlIHRvIHNlbmQgYSBzdGF0ZWxlc3MgcmVzZXQpDQoNCkknZCBzYXkgdGhhdCB0aGUg Zmlyc3QgYnVsbGV0IHBvaW50IGlzIG5lZ2xpZ2libGUuIFRoZSBzZWNvbmQgcG9pbnQNCmNvdWxk IGFsc28gYmUsIGJlY2F1c2UgSSdkIGFzc3VtZSB0aGF0IHRoZSBvbmx5IGZyZXF1ZW50bHktc2Vu dA0KcGFja2V0cyB0aGF0IHJlcXVpcmUgYWRkaXRpb25hbCBwYWRkaW5nIGlzIHRoZSBBQ0stb25s eSBwYWNrZXRzLCBidXQNCnRoZXJlJ3Mgbm8gcmVhc29uIHRvIHBhZCBBQ0stb25seSBwYWNrZXRz IGluIGhvcGUgdGhhdCB5b3UnZCBzZWUgYQ0Kc3RhdGVsZXNzIHJlc2V0Lg0KDQpUaGVyZWZvcmUs IG15IChub3Qtc28tc3Ryb25nKSBwcmVmZXJlbmNlIGhhcyBiZWVuIHRvIHByb3ZpZGUgZXh0cmEN CnJvb20sIHNvIHRoYXQgc29tZSBwZW9wbGUgd2l0aCBuZWNlc3NpdHkgY2FuIHVzZSBsb25nZXIg Q0lEcy4NCg0KPg0KPiAtLSBDaHJpc3RpYW4gSHVpdGVtYQ0KPg0KPg0KPg0KDQoNCg0KLS0NCkth enVobyBPa3UNCg== --_000_91E94F47B6D24746994A15B84578B174fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFu b3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW0xODM0Nzg4MDEwMzg1MjQxOTMyYWlybWFp bG9uLCBsaS5nbWFpbC1tMTgzNDc4ODAxMDM4NTI0MTkzMmFpcm1haWxvbiwgZGl2LmdtYWlsLW0x ODM0Nzg4MDEwMzg1MjQxOTMyYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fMTgz NDc4ODAxMDM4NTI0MTkzMmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6NzU2NDg2NjM2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxODgyMjEzNzE4O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTkwNzQ1NDM3NDsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjE1MjczODQ0IC0xNTAwNjMyNjcyIDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0 IEkgdGhpbmsgcGVvcGxlIGFyZSBzYXlpbmcgc28gZmFyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7MSkgUVVJQyB2MSB3b3VsZCBsaW1pdCBDSUQgbGVu Z3RoIHRvIHNvbWV0aGluZyBvbmUgb2YgezMyLCAzNiwgb3IgNDh9PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7MikgUmVwcmVzZW50YXRpb24gb2YgQ0lE IGxlbmd0aCBhcyBhIGJ5dGUgaXMgc3RpbGwgT0ssIHRodXMgYSBRVUlDIHYyIGNvdWxkIHVzZSBs b25nZXIgQ0lEcyBhcyBuZWVkZWQgYnkgY2hhbmdpbmcgdGhlIHNwZWMgd2hpbGUga2VlcGluZyB0 aGUgaW52YXJpYW50c+KApiBpbnZhcmlhbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpUaGF0IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUgLyBJ4oCZZCBzdGlsbCBz dXBwb3J0IHRoYXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5RVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAm cXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdW5lIDE3LCAyMDE5IGF0IDg6NTUgQU08YnI+DQo8Yj5U bzogPC9iPklhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn Jmd0OywgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkNjOiA8L2I+RG1pdHJpIFRpa2hvbm92ICZsdDtkdGlraG9ub3ZAbGl0ZXNwZWVk dGVjaC5jb20mZ3Q7LCBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZn dDssICZxdW90O1BoaWxpcHAgUy4gVGllc2VsJnF1b3Q7ICZsdDtwaGlsaXBwQHRpZXNlbC5uZXQm Z3Q7LCBNaWtlIEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7LCBNYXJ0aW4gVGhv bXNvbiAmbHQ7bXRAbG93ZW50cm9weS5uZXQmZ3Q7LCBNYXJ0ZW4gU2VlbWFubiAmbHQ7bWFydGVu c2VlbWFubkBnbWFpbC5jb20mZ3Q7LCBMYXJzDQogRWdnZXJ0ICZsdDtsYXJzQGVnZ2VydC5vcmcm Z3Q7LCBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OywgTWFydGluIER1a2UgJmx0O21hcnRp bi5oLmR1a2VAZ21haWwuY29tJmd0OywgS2F6dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IENvbnNlbnN1cyBDYWxsOiBNb3JlIENvbm5l Y3Rpb24gSUQgU3BhY2UgIzI3MzY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TXkgdGFrZSBpcyBzaW1pbGFyIOKAkyA0OCBpcyBwcm9iYWJseSBl eGNlc3NpdmUsIHdoaWxlIDMyIGlzIGxpa2VseSB0aGUgdXBwZXIgbGltaXQgb2Yg4oCccmVhc29u YWJsZeKAnSAoaXQgc2hvdWxkIHByb2JhYmx5IGJlIGEgZmFjdG9yIG9mIDgsIHNvIDMyIG9yIDI0 PykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBmaXJtbHkgY29tbWl0dGVkIGZvciB1 c2luZyBDSUQgZm9yIGluLWNsdXN0ZXIgbG9hZCBiYWxhbmNpbmcgLyBhbnljYXN0IHBvcCByb3V0 aW5nLiZuYnNwOyBUaGlzIGRpc2N1c3Npb24gaXMgdGFraW5nIHVzLCBob3dldmVyLCB0byBhIG5l dyB0ZXJyaXRvcnkg4oCTIGEgZ2VuZXJhbGl6ZWQg4oCcZGVzdGluYXRpb24tY29udHJvbGxlZCBy b3V0aW5nIGluIGFuIG92ZXJsYXkgbmV0d29ya+KAnS4mbmJzcDsgVGhpcyBpcyBhIHZlcnkNCiBp bnRlcmVzdGluZyB0b3BpYywgYnV0IEkgd291bGQgaGVzaXRhdGUgdG8gYXR0ZW1wdCB0byBzb2x2 ZSBpdCBmdWxseSBhbmQg4oCcaW4gZ2VuZXJhbOKAnSBpbiBRVUlDIHYxLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+SWdvcjxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5z d2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBpbnR1aXRpb24gc2F5cyBtYWtpbmcgdGhlIGNo YW5nZSB0byB0aGUgaW52YXJpYW50cyBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIGJ1dCBJIGRv bid0IGZlZWwgdGhhdCBzdHJvbmdseS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhvd2V2ZXIsIEknZCBsaWtlIHRoZSBtYXggc2l6ZSB0byBiZSBzbWFsbGVy IHRoYW4gNDgoYnV0IGxhcmdlciB0aGFuIDE4KS4mbmJzcDsgSWYgd2UgdGhpbmsgMjAgb3IgMjQg aXMgc3VmZmljaWVudCwgSSdkIHByZWZlciB0aGF0LiZuYnNwOyBLYXp1aG8gc3VnZ2VzdGVkIDMy LCB3aGljaCBpcyBiZXR0ZXIsIGJ1dCBJIGRvbid0IGJlbGlldmUgdGhlIHNlcnZlciBuZWVkcyB0 byB1c2UgYSBzZXBhcmF0ZSBibG9jayBjaXBoZXIgd2hlbg0KIGdpdmluZyBvdXQgY29ubmVjdGlv biBJRHMsIGJlY2F1c2UgSSBiZWxpZXZlIGl0J3MgaW1wcmFjdGljYWwgZm9yIHRoZSBsb2FkIGJh bGFuY2VyIGFuZCBzZXJ2ZXIgdG8gYmUgdGhhdCBkZWNvdXBsZWQuJm5ic3A7IFRoZSBzZXJ2ZXIg aGFzIHRvIGdpdmUgb3V0IGEgQ0lEIHRoYXQgdGhlIGxvYWQgYmFsYW5jZXIgd2lsbCB1c2UgdG8g cm91dGUgYmFjayB0byB0aGUgc2VydmVyLCBzbyB0aGV5IGhhdmUgdG8gc2hhcmUgZW5vdWdoIGFu IGVuY3J5cHRpb24ga2V5L2FsZ29yaXRobS4mbmJzcDsNCiBJIGNhbiBpbWFnaW5lIG5lc3Rpbmcg bG9hZCBiYWxhbmNlcnMsIGJ1dCB0aGF0J3Mgd2VsbCBpbiB0aGUgcmFuZ2Ugb2YgUVVJQyB2MiBm cm9tIG15IHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XaGF0ZXZlciB3ZSBkbywgSSdkIHJlYWxseSBwcmVmZXIgdG8gcmVz b2x2ZSB0aGlzIHNvb25lciByYXRoZXIgdGhhbiBsYXRlciBhbmQgYmUgdHJ1bHkgZG9uZSB3aXRo IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEp1biAxNywgMjAxOSBhdCAyOjUxIEFNIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5z ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IGlkPSJnbWFp bC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YTtjb2xvcjpibGFjayI+U2luY2UgaXQgaXMgbW9yZSBsaWtlbHkgdGhhdCB5b3UgcGF5IGZvciBl Z3Jlc3MgdHJhZmZpYyB0aGFuIGluZ3Jlc3MgdHJhZmZpYywgdGhlIG1vdGl2YXRpb24gdG8ga2Vl cCBDSUTigJlzIHNtYWxsIGlzIGxpbWl0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJibG9vcF9jdXN0 b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+SSBkbyB0aGluayB0aGUgaW52 YXJpYW50cyBzaG91bGQgYWxsb3cgZm9yIGxvbmcgQ0lE4oCZcyBhcyBwcm9wb3NlZCwgYW5kIHRo YXQgdGhlIGxvbmcgaGVhZGVyIG92ZXJoZWFkIGlzIG5vdCBpbXBvcnRhbnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3ODgwMTAzODUyNDE5MzJi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzE4MzQ3ODgwMTAz ODUyNDE5MzJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+ QnV0IGZvciBRVUlDIHYxLCBpZiB3ZSBhbGxvdyBmb3IgYSBsb25nIENJRCwgYSBydXNoIHRvIG1h cmtldCB3aWxsIHNldCBwcmVjZWRlbmNlIGFuZCBsb25nIENJROKAmXMgd2lsbCBvc3NpZnkgaW4g YWxsIGtpbmRzIG9mIHN0YWNrcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5JIGdvb2QgcmVmZXJlbmNlIG9uIGFuIGFs Z29yaXRobSBsaWtlIHN1Z2dlc3RlZCBieSBDaHJpc3RpYW4gd291bGQgZ28gYSBsb25nIHdheS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAx MDM4NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1f MTgzNDc4ODAxMDM4NTI0MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2Nv bG9yOmJsYWNrIj5JZiBDSUQgbGVuZ3RoIDE4IHR1cm5zIG91dCB0byBiZSBub3QgZW5vdWdoLCB3 ZSBjYW4gYWRkIGEgUVVJQyB2Mi4gSXTigJlzIG5vdCBsaWtlIHdlIGFyZSBub3QgbG9va2luZyBm b3IgZXhjdXNlcyB0byB1cGdyYWRlIFFVSUMgdmVyc2lvbnMgc29vbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4NTI0MTkzMmJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fMTgzNDc4ODAxMDM4NTI0 MTkzMmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5JZiBD SUQgbGVuZ3RoIG5lZ290aWF0aW9uIGlzIG5lZWRlZCwgdGhpcyBjb3VsZCBiZSBkb25lIHZpYSBR VUlDIHZlcnNpb25zLiBGb3IgZXhhbXBsZSB0d28gZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgdmVy c2lvbnMsIGJ1dCBvbmUgd2l0aCBsb25nZXIgQ0lE4oCZcy4gVGhpcyB3b3VsZCBhbHNvIGFsbG93 DQogcm91dGVycyB0byBkZWFsIHdpdGggY2hhbmdlcyBpbiBDSUQgbGVuZ3Rocy4gQSBuZWdvdGlh dGVkIFRQIHdvdWxkIG5vdCAoZWFzaWx5KSBhbGxvdyBmb3IgdGhhdCBhbmQgYXNpZGUgSSBkbyBu b3QgdGhpbmsgQ0lEIGxlbmd0aCBpbiBUUCBpcyB0aGUgd2F5IHRvIGdvLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV8xODM0Nzg4MDEwMzg1MjQxOTMyYmxv b3Bfc2lnbl8xNTYwNzUzOTMxODI4MTQ1OTIwIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NaWtrZWw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTE4MzQ3ODgwMTAzODUyNDE5MzJhaXJtYWls b24iPk9uIDE3IEp1bmUgMjAxOSBhdCAwNi40NS4wNCwgS2F6dWhvIE9rdSAoPGEgaHJlZj0ibWFp bHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwu Y29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4yMDE5PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjY8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mnIg8L3NwYW4+MTc8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4pIDEx OjA5IENocmlzdGlhbg0KIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRl bWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Og0KPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDYvMTUvMjAxOSAxMDo1NSBQTSwgS2F6dWhvIE9rdSB3cm90 ZTogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgX0lmXyB3ZSBhcmUgdG8gYWxsb3cgbG9vc2Ug Y291cGxpbmcgYmV0d2VlbiBhIGxvYWQgYmFsYW5jZXIgYW5kIGEgPGJyPg0KJmd0OyAmZ3Q7IHNl cnZlciwgZWFjaCBvZiB0aGUgdHdvIHNob3VsZCBiZSBnaXZlbiB0aGUgZnJlZWRvbSB0byBjaG9v c2UgaXQncyBvd24gPGJyPg0KJmd0OyAmZ3Q7IENJRCBlbmNyeXB0aW9uIHNjaGVtZS4gQmVjYXVz ZSBhbGwgdGhlIHN0YW5kYXJkaXplZCBibG9jayBjaXBoZXJzIGFyZSA8YnI+DQomZ3Q7ICZndDsg bm93IDEyOC1iaXRzICg9IDE2IGJ5dGVzKSwgdGhhdCBuYXR1cmFsbHkgbWVhbnMgdGhhdCB0aGUg bWF4aW11bSBDSUQgPGJyPg0KJmd0OyAmZ3Q7IGxlbmd0aCBvZiBRVUlDIG5lZWRzIHRvIGJlIGRv dWJsZSBhbW91bnQgb2YgdGhhdCwgcGx1cyBvbmUgb3IgdHdvIDxicj4NCiZndDsgJmd0OyBieXRl cyBmb3IgZWFjaCBvZiB0aGUgdHdvIGZvciBpZGVudGlmeWluZyB0aGUgQ0lEIGVuY3J5cHRpb24g a2V5cy4gRm9yIDxicj4NCiZndDsgJmd0OyBrZXkgaWRlbnRpZmljYXRpb24gYW5kIG90aGVyIHN1 cHBsZW1lbnRhbCB1c2UsIHdlIGN1cnJlbnRseSBhbGxvY2F0ZSAyIDxicj4NCiZndDsgJmd0OyBi eXRlcyAoMTgtMTY9MikuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGF0IHJlYXNvbmluZyBpcyBi YXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IGJvdGggdGhlIGxvYWQgYmFsYW5jZXIgPGJyPg0K Jmd0OyBhbmQgdGhlIHNlcnZlciBtdXN0IHVzZSBhIGJsb2NrIGNpcGhlciB3aXRoIDEyOCBiaXQg YmxvY2sgbGVuZ3RoIGluIDxicj4NCiZndDsgb3JkZXIgdG8gZW5jcnlwdCB0aGUgQ0lELiBJZiB0 aGV5IHdlcmUgY29uc3RyYWluZWQgdG8gc3RheSB3aXRoaW4gYSA8YnI+DQomZ3Q7IHNob3J0IGds b2JhbCBsaW1pdCwgdGhleSBjb3VsZCB1c2UgZGlmZmVyZW50IHNldHMgb2YgYWxnb3JpdGhtcy4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzc3VtZSBmb3IgZXhhbXBsZSB0aGF0IHdlIHNwbGl0IHRo ZSBDSUQgYmV0d2VlbiAzMiBiaXRzIGVuY29kaW5nIHRoZSA8YnI+DQomZ3Q7IG51bWJlciBvZiB0 aGUgc2VydmVyIGluIHRoZSBzZXJ2ZXIgZmFybSwgYW5kIDY0IGJpdCBlbmNvZGluZyB0aGUgPGJy Pg0KJmd0OyBjb25uZWN0aW9uIG51bWJlciBmb3IgdGhlIHNlcnZlci4gVGhlIHNlcnZlciBjYW4g cGljayBhIHJhbmRvbSB2YWx1ZSBmb3IgPGJyPg0KJmd0OyB0aGUgY29ubmVjdGlvbiBudW1iZXIs IGFuZCB1c2UgYSBoYXNoIHRhYmxlLiBUaGUgbG9hZCBiYWxhbmNlciBjb3VsZCB1c2UgPGJyPg0K Jmd0OyBhIDMyIGJpdCB2YXJpYW50IG9mIHRoZSBGRlggYWxnb3JpdGhtLCB1c2luZyB0aGUgbG93 ZXIgNjQgYml0IG9mIHRoZSBDSUQgPGJyPg0KJmd0OyBhcyBhbiBpbml0aWFsIHZlY3Rvci4gVm9p bGEsIDk2IENJRCwgd2l0aCBkZW1vbnN0cmFibHkgc3Ryb25nIGVuY3J5cHRpb24uIDxicj4NCiZn dDsgPGJyPg0KJmd0OyBPciBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdhbnRzIHRvIHVzZSBzaG9y dCBDSUQuIFdlIG5vdyBzcGxpdCB0aGUgQ0lEIDxicj4NCiZndDsgYmV0d2VlbiAzMiBiaXQgZm9y IHRoZSBzZXJ2ZXIgbnVtYmVyIGluIHRoZSBmYXJtLCBhbmQgMzIgYml0IGZvciB0aGUgPGJyPg0K Jmd0OyBjb25uZWN0aW9uIG51bWJlciBpbiB0aGUgc2VydmVyLiBUaGUgc2VydmVyIGJ1aWxkcyB0 aGF0IGNvbm5lY3Rpb24gPGJyPg0KJmd0OyBudW1iZXIgYnkgdXNpbmcgYSAzMiBiaXQgdmFyaWFu dCBvZiBGRlguIFRoZSBsb2FkIGJhbGFuY2VyIGFsc28gdXNlcyBhIDxicj4NCiZndDsgMzIgYml0 IHZhcmlhbnQsIHVzaW5nIHRoZSBsb3dlciAzMiBiaXQgb2YgdGhlIENJRCBhcyBpbml0aWFsIHZl Y3RvciBmb3IgPGJyPg0KJmd0OyB0aGlzIEZGWCBlbmNyeXB0aW9uLiA8YnI+DQomZ3Q7IDxicj4N CiZndDsgVGhlc2UgYXJlIGp1c3QgdHdvIGV4YW1wbGVzLiBBbmQgeWVzIHlvdSBtYXkgd2FudCB0 byBhZGQgMiBieXRlcyBmb3Iga2V5IDxicj4NCiZndDsgaWRlbnRpZmljYXRpb24sIGV0Yy4gSW4g Ym90aCBlbmNyeXB0aW9uIGFsZ29yaXRobXMsIHlvdSBjYW4gZmVlZCB0aGVzZSA8YnI+DQomZ3Q7 IHR3byBieXRlcyBhcyBhZGRpdGlvbmFsIElWIGZvciB0aGUgRkZYIGFsZ29yaXRobS4gQW5kIGlu IGJvdGggY2FzZXMsIHdlIDxicj4NCiZndDsgYXJlIHdlbGwgYmVsb3cgdGhlIDE4IGJ5dGUgbGlt aXQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXMsIHRoYXQgcmVxdWlyZXMgc29tZSBjcmVhdGl2 ZSBlbmdpbmVlcmluZy4gQnV0IGl0IGlzIG5vdCByb2NrZXIgPGJyPg0KJmd0OyBzY2llbmNlLiBB bmQgaXQgc2VlbXMgYmV0dGVyIHRoYW4gY2FycnlpbmcgdG9ucyBvZiBvdmVyaGVhZCBpbiB0aGUg PGJyPg0KJmd0OyBoZWFkZXIsIGFuZCBiZWNvbWluZyBsZXNzIGVmZmljaWVudCB0aGFuIEhUVFAy L1RMUy9UQ1AuIDxicj4NCjxicj4NCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBub3QgYmUgdGhlIGVu ZCBvZiB0aGUgd29ybGQgZm9yIHRoZSBsb2FkIDxicj4NCmJhbGFuY2VycyBpZiB3ZSBkZWNpZGUg dG8gc3RpY2sgb24gdGhlIDE4LWJ5dGUgbGltaXQuIEhvd2V2ZXIsIGFzIHlvdSA8YnI+DQpzdGF0 ZSwgaXQgcmVxdWlyZXMgc29tZSBjcmVhdGl2ZW5lc3MuIDxicj4NCjxicj4NClRvIG1lIGl0IHNl ZW1zIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIGlmIHdlIGhhdmUgYSBzdHJvbmcgcmVhc29uIHRvIDxi cj4NCnJlcXVpcmUgc29tZSBwZW9wbGUgdG8gYmUgY3JlYXRpdmUsIGZvciBhbGwgdGhlIHZlcnNp b25zIG9mIFFVSUMgaW4gPGJyPg0KdGhlIGZ1dHVyZS4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQg dGhlcmUgaXNuJ3QgYSBzdHJvbmcgcmVhc29uLCA8YnI+DQpiZWNhdXNlIHBlb3BsZSBjYW4gdXNl IHNob3J0ZXIgQ0lEcyByZWdhcmRsZXNzIG9mIHRoZSBkZWNpc2lvbiB3ZSA8YnI+DQptYWtlLiBJ SVVDLCB0aGUgb3ZlcmhlYWQgdGhhdCBldmVyeW9uZSBuZWVkcyB0byBhY2NlcHQgaXM6IDxicj4N Cjxicj4NCiogb25lIGJ5dGUgaW5jcmVhc2UgaW4gdGhlIGxvbmcgaGVhZGVyIHBhY2tldHMgPGJy Pg0KKiB0aGUgbWluaW11bSBzaXplIG9mIHNob3J0IGhlYWRlciBwYWNrZXRzIGJlY29taW5nIHNs aWdodGx5IGdyZWF0ZXIgPGJyPg0KKG90aGVyd2lzZSwgdGhlIHBlZXIgbWlnaHQgbm90IGJlIGFi bGUgdG8gc2VuZCBhIHN0YXRlbGVzcyByZXNldCkgPGJyPg0KPGJyPg0KSSdkIHNheSB0aGF0IHRo ZSBmaXJzdCBidWxsZXQgcG9pbnQgaXMgbmVnbGlnaWJsZS4gVGhlIHNlY29uZCBwb2ludCA8YnI+ DQpjb3VsZCBhbHNvIGJlLCBiZWNhdXNlIEknZCBhc3N1bWUgdGhhdCB0aGUgb25seSBmcmVxdWVu dGx5LXNlbnQgPGJyPg0KcGFja2V0cyB0aGF0IHJlcXVpcmUgYWRkaXRpb25hbCBwYWRkaW5nIGlz IHRoZSBBQ0stb25seSBwYWNrZXRzLCBidXQgPGJyPg0KdGhlcmUncyBubyByZWFzb24gdG8gcGFk IEFDSy1vbmx5IHBhY2tldHMgaW4gaG9wZSB0aGF0IHlvdSdkIHNlZSBhIDxicj4NCnN0YXRlbGVz cyByZXNldC4gPGJyPg0KPGJyPg0KVGhlcmVmb3JlLCBteSAobm90LXNvLXN0cm9uZykgcHJlZmVy ZW5jZSBoYXMgYmVlbiB0byBwcm92aWRlIGV4dHJhIDxicj4NCnJvb20sIHNvIHRoYXQgc29tZSBw ZW9wbGUgd2l0aCBuZWNlc3NpdHkgY2FuIHVzZSBsb25nZXIgQ0lEcy4gPGJyPg0KPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IC0tIENocmlzdGlhbiBIdWl0ZW1hIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3UgPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_91E94F47B6D24746994A15B84578B174fbcom_-- From nobody Mon Jun 17 12:50:05 2019 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 04C1B120389 for ; Mon, 17 Jun 2019 12:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.014 X-Spam-Level: X-Spam-Status: No, score=-3.014 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=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 dBvMBzU255v3 for ; Mon, 17 Jun 2019 12:50:00 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5660B12006E for ; Mon, 17 Jun 2019 12:49:59 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp11.mail2web.com) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hcxda-000zGE-8z for quic@ietf.org; Mon, 17 Jun 2019 21:49:57 +0200 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hcxdV-0001UN-CR for quic@ietf.org; Mon, 17 Jun 2019 15:49:52 -0400 Received: (qmail 30966 invoked from network); 17 Jun 2019 19:49:48 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Jun 2019 19:49:46 -0000 To: Roberto Peon , "Lubashev, Igor" , Ian Swett , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= Cc: "Philipp S. Tiesel" , Dmitri Tikhonov , Mike Bishop , Martin Duke , Lars Eggert , Marten Seemann , QUIC WG , Martin Thomson , Kazuho Oku References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> Date: Mon, 17 Jun 2019 12:49:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> Content-Type: multipart/alternative; boundary="------------4245F032030B31F286C1097A" Content-Language: en-US Subject: Re: Consensus Call: More Connection ID Space #2736 X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ud2CCyxmm2KHETL0VYw/ASpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ftj+Unh/X/EazkmuBkS86EZ/sevPPdLVvjz7b14RFNIS87+5mCGQbZOG2a6 XRF1Gc13+EGOqzFq62OVVd/IlpApTpgWJlsU4G2/4kZd/AHuzsdm/7IKyshZDKoLEEdzFciN9bEz YXQ5Bq54+8sOLcJpXof3r8kfRxpez5OlfYJRQkKHj8GhSvnXG6aqAO+QA5zAmfg+QMjm0Wxe7G4F AAR6avERpop5LF7RavHozgbn9YqgREAoh06jutiTfFzl2G4uss8347yATkLSIXqnQVGKSPZLLSx3 /6BTpL6UXmT8yFSCJlnatpQUVkDyz9+HEa34l0QmPyjhxxYY4z85MF0ZIK/1NH5THMtlYvyHAYGO GlmJIjyKo/pbSDRNIEOEwlMcz873cIRxyN1uC++vIKvC6BczixKau3SVCHUjX//Ejzlmb7vJotNJ feR0KdPrrD0FVDixAI0yqF62RqWh7gWqv4lgRyT4wpTnWZxrKPLyB6yp/agYZfrnDk8+IFUpab7m 9Ql4Ld7qe/xoNQPgy7UpxcIWHOi9y3yF+Ot2t6dhJc2bXYMFScrLivfWmWkJo22CHZOREywSBAd6 WuRFS3mxt4ZwQHGiE48iclyxSTXyi1TdVxQnUo0GuxU6HUjogks8CVsONrMJuGzuoGnKTKcymM5H 5NK8ObCxL+Ab3gHeBGp1PWox/HcVwRsYfOuMC9EDvRTWmuYW5XPvbs91Tlwplm45eDKY0zTzJ2HG 4elPGQZlJF8UKGQcpLF8m4y5fNSIlEy3YgJZkOfaaqfw0pD+E4vXmYOrZ6ynPfzK8qbeqosYcSFD ZkSOre2YUe/WyPr4xM5tUrEfL92iWzfzWX2vJeNfaj+DKN82dVVpaMxSGA== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 17 Jun 2019 19:50:04 -0000 This is a multi-part message in MIME format. --------------4245F032030B31F286C1097A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution. Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community. I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition. I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance. Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit. -- Christian Huitema On 6/17/2019 9:16 AM, Roberto Peon wrote: > > What I think people are saying so far: > > =C2=A0=C2=A01) QUIC v1 would limit CID length to something one of {32, = 36, or 48} > > =C2=A0 =C2=A02) Representation of CID length as a byte is still OK, thu= s a QUIC > v2 could use longer CIDs as needed by changing the spec while keeping > the invariants=E2=80=A6 invariant. > > > That seems reasonable to me / I=E2=80=99d still support that. > > -=3DR > > *From: *QUIC on behalf of "Lubashev, Igor" > > *Date: *Monday, June 17, 2019 at 8:55 AM > *To: *Ian Swett , Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > *Cc: *Dmitri Tikhonov , Christian Huitema > , "Philipp S. Tiesel" , Mike > Bishop , Martin Thomson , > Marten Seemann , Lars Eggert > , QUIC WG , Martin Duke > , Kazuho Oku > *Subject: *RE: Consensus Call: More Connection ID Space #2736 > > =C2=A0 > > My take is similar =E2=80=93 48 is probably excessive, while 32 is like= ly the > upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a fa= ctor of 8, so > 32 or 24?). > > =C2=A0 > > We are firmly committed for using CID for in-cluster load balancing / > anycast pop routing.=C2=A0 This discussion is taking us, however, to a = new > territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routi= ng in an > overlay network=E2=80=9D.=C2=A0 This is a very interesting topic, but I= would > hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D = in QUIC v1. > > =C2=A0 > > * Igor > > =C2=A0 > > *From:* Ian Swett > > My intuition says making the change to the invariants is the right > thing to do, but I don't feel that strongly. > > =C2=A0 > > However, I'd like the max size to be smaller than 48(but larger than > 18).=C2=A0 If we think 20 or 24 is sufficient, I'd prefer that.=C2=A0 K= azuho > suggested 32, which is better, but I don't believe the server needs to > use a separate block cipher when giving out connection IDs, because I > believe it's impractical for the load balancer and server to be that > decoupled.=C2=A0 The server has to give out a CID that the load balance= r > will use to route back to the server, so they have to share enough an > encryption key/algorithm.=C2=A0 I can imagine nesting load balancers, b= ut > that's well in the range of QUIC v2 from my perspective. > > =C2=A0 > > Whatever we do, I'd really prefer to resolve this sooner rather than > later and be truly done with it. > > =C2=A0 > > On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen > > wrote: > > Since it is more likely that you pay for egress traffic than > ingress traffic, the motivation to keep CID=E2=80=99s small is limi= ted. > > =C2=A0 > > I do think the invariants should allow for long CID=E2=80=99s as pr= oposed, > and that the long header overhead is not important. > > =C2=A0 > > But for QUIC v1, if we allow for a long CID, a rush to market will > set precedence and long CID=E2=80=99s will ossify in all kinds of s= tacks. > > =C2=A0 > > I good reference on an algorithm like suggested by Christian would > go a long way. > > =C2=A0 > > If CID length 18 turns out to be not enough, we can add a QUIC v2. > It=E2=80=99s not like we are not looking for excuses to upgrade QUI= C > versions soon. > > =C2=A0 > > If CID length negotiation is needed, this could be done via QUIC > versions. For example two functionally equivalent versions, but > one with longer CID=E2=80=99s. This would also allow routers to dea= l with > changes in CID lengths. A negotiated TP would not (easily) allow > for that and aside I do not think CID length in TP is the way to go= =2E > > =C2=A0 > > Mikkel > > =C2=A0 > > On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com > ) wrote: > > 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian H= uitema >: > > > > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > > > _If_ we are to allow loose coupling between a load > balancer and a > > > server, each of the two should be given the freedom to > choose it's own > > > CID encryption scheme. Because all the standardized block > ciphers are > > > now 128-bits (=3D 16 bytes), that naturally means that the > maximum CID > > > length of QUIC needs to be double amount of that, plus one > or two > > > bytes for each of the two for identifying the CID > encryption keys. For > > > key identification and other supplemental use, we > currently allocate 2 > > > bytes (18-16=3D2). > > > > That reasoning is based on the assumption that both the load > balancer > > and the server must use a block cipher with 128 bit block > length in > > order to encrypt the CID. If they were constrained to stay > within a > > short global limit, they could use different sets of > algorithms. > > > > Assume for example that we split the CID between 32 bits > encoding the > > number of the server in the server farm, and 64 bit encoding > the > > connection number for the server. The server can pick a > random value for > > the connection number, and use a hash table. The load > balancer could use > > a 32 bit variant of the FFX algorithm, using the lower 64 > bit of the CID > > as an initial vector. Voila, 96 CID, with demonstrably > strong encryption. > > > > Or assume that the server wants to use short CID. We now > split the CID > > between 32 bit for the server number in the farm, and 32 bit > for the > > connection number in the server. The server builds that > connection > > number by using a 32 bit variant of FFX. The load balancer > also uses a > > 32 bit variant, using the lower 32 bit of the CID as initial > vector for > > this FFX encryption. > > > > These are just two examples. And yes you may want to add 2 > bytes for key > > identification, etc. In both encryption algorithms, you can > feed these > > two bytes as additional IV for the FFX algorithm. And in > both cases, we > > are well below the 18 byte limit. > > > > Yes, that requires some creative engineering. But it is not > rocker > > science. And it seems better than carrying tons of overhead > in the > > header, and becoming less efficient than HTTP2/TLS/TCP. > > I agree that it would not be the end of the world for the load > balancers if we decide to stick on the 18-byte limit. However, > as you > state, it requires some creativeness. > > To me it seems that the question is if we have a strong reason = to > require some people to be creative, for all the versions of > QUIC in > the future. I personally think that there isn't a strong reason= , > because people can use shorter CIDs regardless of the decision = we > make. IIUC, the overhead that everyone needs to accept is: > > * one byte increase in the long header packets > * the minimum size of short header packets becoming slightly > greater > (otherwise, the peer might not be able to send a stateless rese= t) > > I'd say that the first bullet point is negligible. The second > point > could also be, because I'd assume that the only frequently-sent= > packets that require additional padding is the ACK-only > packets, but > there's no reason to pad ACK-only packets in hope that you'd > see a > stateless reset. > > Therefore, my (not-so-strong) preference has been to provide > extra > room, so that some people with necessity can use longer CIDs. > > > > > -- Christian Huitema > > > > > > > > > > --=20 > Kazuho Oku > --------------4245F032030B31F286C1097A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.

Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.

I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.

I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.

Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.

-- Christian Huitema

On 6/17/2019 9:16 AM, Roberto Peon wrote:

What I think people are saying so far:

  1) QUIC v1 would limit CID length to something one of {32, 36, or 48}

   2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants… invariant.


That seems reasonable to me / I’d still support that.

-=R

From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
Date: Monday, June 17, 2019 at 8:55 AM
To: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>, Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <martenseemann@gmail.com>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Consensus Call: More Connection ID Space #2736

 

My take is similar – 48 is probably excessive, while 32 is likely the upper limit of “reasonable” (it should probably be a factor of 8, so 32 or 24?).

 

We are firmly committed for using CID for in-cluster load balancing / anycast pop routing.  This discussion is taking us, however, to a new territory – a generalized “destination-controlled routing in an overlay network”.  This is a very interesting topic, but I would hesitate to attempt to solve it fully and “in general” in QUIC v1.

 

  • Igor

 

From: Ian Swett <ianswett=40google.com@dmarc.ietf.org>

My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly.

 

However, I'd like the max size to be smaller than 48(but larger than 18).  If we think 20 or 24 is sufficient, I'd prefer that.  Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled.  The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm.  I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.

 

Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.

 

On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> wrote:

Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID’s small is limited.

 

I do think the invariants should allow for long CID’s as proposed, and that the long header overhead is not important.

 

But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID’s will ossify in all kinds of stacks.

 

I good reference on an algorithm like suggested by Christian would go a long way.

 

If CID length 18 turns out to be not enough, we can add a QUIC v2. It’s not like we are not looking for excuses to upgrade QUIC versions soon.

 

If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID’s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.

 

Mikkel

 

On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:

2019年6月17日(月) 11:09 Christian Huitema <huitema@huitema.net>:
>
> On 6/15/2019 10:55 PM, Kazuho Oku wrote:
>
> > _If_ we are to allow loose coupling between a load balancer and a
> > server, each of the two should be given the freedom to choose it's own
> > CID encryption scheme. Because all the standardized block ciphers are
> > now 128-bits (= 16 bytes), that naturally means that the maximum CID
> > length of QUIC needs to be double amount of that, plus one or two
> > bytes for each of the two for identifying the CID encryption keys. For
> > key identification and other supplemental use, we currently allocate 2
> > bytes (18-16=2).
>
> That reasoning is based on the assumption that both the load balancer
> and the server must use a block cipher with 128 bit block length in
> order to encrypt the CID. If they were constrained to stay within a
> short global limit, they could use different sets of algorithms.
>
> Assume for example that we split the CID between 32 bits encoding the
> number of the server in the server farm, and 64 bit encoding the
> connection number for the server. The server can pick a random value for
> the connection number, and use a hash table. The load balancer could use
> a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID
> as an initial vector. Voila, 96 CID, with demonstrably strong encryption.
>
> Or assume that the server wants to use short CID. We now split the CID
> between 32 bit for the server number in the farm, and 32 bit for the
> connection number in the server. The server builds that connection
> number by using a 32 bit variant of FFX. The load balancer also uses a
> 32 bit variant, using the lower 32 bit of the CID as initial vector for
> this FFX encryption.
>
> These are just two examples. And yes you may want to add 2 bytes for key
> identification, etc. In both encryption algorithms, you can feed these
> two bytes as additional IV for the FFX algorithm. And in both cases, we
> are well below the 18 byte limit.
>
> Yes, that requires some creative engineering. But it is not rocker
> science. And it seems better than carrying tons of overhead in the
> header, and becoming less efficient than HTTP2/TLS/TCP.

I agree that it would not be the end of the world for the load
balancers if we decide to stick on the 18-byte limit. However, as you
state, it requires some creativeness.

To me it seems that the question is if we have a strong reason to
require some people to be creative, for all the versions of QUIC in
the future. I personally think that there isn't a strong reason,
because people can use shorter CIDs regardless of the decision we
make. IIUC, the overhead that everyone needs to accept is:

* one byte increase in the long header packets
* the minimum size of short header packets becoming slightly greater
(otherwise, the peer might not be able to send a stateless reset)

I'd say that the first bullet point is negligible. The second point
could also be, because I'd assume that the only frequently-sent
packets that require additional padding is the ACK-only packets, but
there's no reason to pad ACK-only packets in hope that you'd see a
stateless reset.

Therefore, my (not-so-strong) preference has been to provide extra
room, so that some people with necessity can use longer CIDs.

>
> -- Christian Huitema
>
>
>



--
Kazuho Oku

--------------4245F032030B31F286C1097A-- From nobody Mon Jun 17 20:33:38 2019 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 555941200C7 for ; Mon, 17 Jun 2019 20:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTyUGzaFhmOA for ; Mon, 17 Jun 2019 20:33:33 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 D725D120116 for ; Mon, 17 Jun 2019 20:33:32 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id y13so8084508lfh.9 for ; Mon, 17 Jun 2019 20:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4oTcesVF7X45SKSrgxCMa8N8fqeCx0lmN9ZSf0+LdnA=; b=Dkd1OzgcWwK9Agp5M6nmvA53oSrGnicNsU5sN5hT9JdiS3IvmGG/v9YH1ZkhriHdnr j0TK6Ql++q04KXl7i6NJb2qvkwxjiY1a+WSNfhsiBwBqzYZQlNqw4ipFRsKiklBlXpn9 SSJKulx5j4Y7LO8UJR2qXFfk8L05IDEGTgQ7C3ihqdgxtEKP7doJfmjmgwvujZ3M9PjD IDScOkmAX4D4V0Io7vdjpqrCNNHCRT15HnoPDtxABs/kKXoODfa/jpm9YpEvkQ37T1zK MAwsczSrngxArszonYereg0/HvwacmqQZbDc0W8PaRUURbuSDI1Bp27KUYaTonidIXVR 4x6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4oTcesVF7X45SKSrgxCMa8N8fqeCx0lmN9ZSf0+LdnA=; b=AhtUwJTqtOE+2jxQqg5FQu2bsY0vol7wmWDbfOOzzoFUXTPpICIRYMUOo0vpJkJ0kq I0PCVi8rGJZ9tr1BAxh5oOQ1VX3+2AsxhUhHdkObXajeDlWeoeD6PnIxVkjsJ/6PMhRW SaLe5b0D/6EU8mm4O8GuaWw0y+cgf2NHMtoI31jZET1AFphpufSs+jfIVyr96yBI6+wx HWElbYO02YULEj+r8scpDQjJz3O/81A5CiiTDRJrTVCY1P6aIA9QjscemNo5kcwR/E8O zHgFV3uSFYlHLTWjyizV6b44nEl9UFz11O26ugV/W+GRr9EaINqEnFr+3rmIkhi8DGE/ oI0Q== X-Gm-Message-State: APjAAAVcMeghGaWhlrMOk/jhCQR8HJBxa31/spunkhOTv646Zlkt5lr3 mrPAkfOm+nAMUoxs5apRIFrr1a0Sh+l6RZhvl1Q= X-Google-Smtp-Source: APXvYqyUxY4pHZGB0DaJxxVhE0CHY9i3HZWYnCiGjCRR5evPCmjLLC8V2ZInMMrHGzRGGAwlDEjfu6AGHktgZ8B9DXo= X-Received: by 2002:ac2:5a5e:: with SMTP id r30mr14330058lfn.12.1560828810715; Mon, 17 Jun 2019 20:33:30 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> In-Reply-To: <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> From: Marten Seemann Date: Tue, 18 Jun 2019 11:33:19 +0800 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Christian Huitema Cc: Roberto Peon , "Lubashev, Igor" , Ian Swett , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Philipp S. Tiesel" , Dmitri Tikhonov , Mike Bishop , Martin Duke , Lars Eggert , QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000d16750058b90c6d5" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 03:33:37 -0000 --000000000000d16750058b90c6d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd prefer keeping the "compressed 4 bits" solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary). There are two main reasons to keep the compressed encoding: 1. In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value. 2. The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just t= o be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combin= ed connection ID overhead of 510 bytes. Since VNPs are supposed to be sent = in response to any Long Header packet, you'd have to put some careful thoug= ht into the design of your data types to avoid this becoming a DoS vector. On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema wrote: > I too agree that using one byte in the invariant is preferable to the > current "compressed 4 bits" solution. > > Regarding the "CID length limit", I thing there are two issues: > transmission overhead, and costs to the community. > > I am not too concerned with the transmission overhead, as we have there > the right mix of costs and incentives. Servers who chose to use longer CI= D > will get more transmission overhead, and thus transmission less efficient= ly > than their competitors. They may chose to use longer CID as a trade-off > between transmission efficiency and ease of management. Competition will > sort that out. I note that YouTube is apparently doing fine with smallish > CID, so I trust that there will be competition. > > I am much more concerned with the shared costs, which are a variation of > the "tragedy of the commons". Dmitry explained those costs well in a > previous message. The simpler implementation is to make the "cid_t a > fixed-size object that can fit the largest CID and eat the overhead for a= ll > CIDs." But each connection object carries a large number of instances of > the CID type. Having a very large max CID would imply a large overhead. T= he > alternative is to "Make cid_t a variable-size object", but too affects > performance. > > Hence the push-back. I would personally prefer a max size of 16, and I > think that 32 is the highest practical limit. > > -- Christian Huitema > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > What I think people are saying so far: > > 1) QUIC v1 would limit CID length to something one of {32, 36, or 48} > > 2) Representation of CID length as a byte is still OK, thus a QUIC v2 > could use longer CIDs as needed by changing the spec while keeping the > invariants=E2=80=A6 invariant. > > > That seems reasonable to me / I=E2=80=99d still support that. > > -=3DR > > *From: *QUIC on behalf of > "Lubashev, Igor" > *Date: *Monday, June 17, 2019 at 8:55 AM > *To: *Ian Swett > , Mikkel Fahn=C3=B8e J=C3=B8rgens= en > > *Cc: *Dmitri Tikhonov > , Christian Huitema > , "Philipp S. Tiesel" > , Mike Bishop > , Martin Thomson > , Marten Seemann > , Lars Eggert , > QUIC WG , Martin Duke > , Kazuho Oku > > *Subject: *RE: Consensus Call: More Connection ID Space #2736 > > > > My take is similar =E2=80=93 48 is probably excessive, while 32 is likely= the > upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a fact= or of 8, so 32 or > 24?). > > > > We are firmly committed for using CID for in-cluster load balancing / > anycast pop routing. This discussion is taking us, however, to a new > territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing= in an overlay > network=E2=80=9D. This is a very interesting topic, but I would hesitate= to > attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > > > > - Igor > > > > *From:* Ian Swett > > > My intuition says making the change to the invariants is the right thing > to do, but I don't feel that strongly. > > > > However, I'd like the max size to be smaller than 48(but larger than 18). > If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32= , > which is better, but I don't believe the server needs to use a separate > block cipher when giving out connection IDs, because I believe it's > impractical for the load balancer and server to be that decoupled. The > server has to give out a CID that the load balancer will use to route bac= k > to the server, so they have to share enough an encryption key/algorithm. = I > can imagine nesting load balancers, but that's well in the range of QUIC = v2 > from my perspective. > > > > Whatever we do, I'd really prefer to resolve this sooner rather than late= r > and be truly done with it. > > > > On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > Since it is more likely that you pay for egress traffic than ingress > traffic, the motivation to keep CID=E2=80=99s small is limited. > > > > I do think the invariants should allow for long CID=E2=80=99s as proposed= , and > that the long header overhead is not important. > > > > But for QUIC v1, if we allow for a long CID, a rush to market will set > precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > > > > I good reference on an algorithm like suggested by Christian would go a > long way. > > > > If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2= =80=99s > not like we are not looking for excuses to upgrade QUIC versions soon. > > > > If CID length negotiation is needed, this could be done via QUIC versions= . > For example two functionally equivalent versions, but one with longer > CID=E2=80=99s. This would also allow routers to deal with changes in CID = lengths. A > negotiated TP would not (easily) allow for that and aside I do not think > CID length in TP is the way to go. > > > > Mikkel > > > > On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: > > 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema : > > > > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > > > _If_ we are to allow loose coupling between a load balancer and a > > > server, each of the two should be given the freedom to choose it's ow= n > > > CID encryption scheme. Because all the standardized block ciphers are > > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CI= D > > > length of QUIC needs to be double amount of that, plus one or two > > > bytes for each of the two for identifying the CID encryption keys. Fo= r > > > key identification and other supplemental use, we currently allocate = 2 > > > bytes (18-16=3D2). > > > > That reasoning is based on the assumption that both the load balancer > > and the server must use a block cipher with 128 bit block length in > > order to encrypt the CID. If they were constrained to stay within a > > short global limit, they could use different sets of algorithms. > > > > Assume for example that we split the CID between 32 bits encoding the > > number of the server in the server farm, and 64 bit encoding the > > connection number for the server. The server can pick a random value fo= r > > the connection number, and use a hash table. The load balancer could us= e > > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CI= D > > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > > > > Or assume that the server wants to use short CID. We now split the CID > > between 32 bit for the server number in the farm, and 32 bit for the > > connection number in the server. The server builds that connection > > number by using a 32 bit variant of FFX. The load balancer also uses a > > 32 bit variant, using the lower 32 bit of the CID as initial vector for > > this FFX encryption. > > > > These are just two examples. And yes you may want to add 2 bytes for ke= y > > identification, etc. In both encryption algorithms, you can feed these > > two bytes as additional IV for the FFX algorithm. And in both cases, we > > are well below the 18 byte limit. > > > > Yes, that requires some creative engineering. But it is not rocker > > science. And it seems better than carrying tons of overhead in the > > header, and becoming less efficient than HTTP2/TLS/TCP. > > I agree that it would not be the end of the world for the load > balancers if we decide to stick on the 18-byte limit. However, as you > state, it requires some creativeness. > > To me it seems that the question is if we have a strong reason to > require some people to be creative, for all the versions of QUIC in > the future. I personally think that there isn't a strong reason, > because people can use shorter CIDs regardless of the decision we > make. IIUC, the overhead that everyone needs to accept is: > > * one byte increase in the long header packets > * the minimum size of short header packets becoming slightly greater > (otherwise, the peer might not be able to send a stateless reset) > > I'd say that the first bullet point is negligible. The second point > could also be, because I'd assume that the only frequently-sent > packets that require additional padding is the ACK-only packets, but > there's no reason to pad ACK-only packets in hope that you'd see a > stateless reset. > > Therefore, my (not-so-strong) preference has been to provide extra > room, so that some people with necessity can use longer CIDs. > > > > > -- Christian Huitema > > > > > > > > > > -- > Kazuho Oku > > --000000000000d16750058b90c6d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd prefer keeping the "compressed 4 bits" s= olution, even if we decide to increase the connection ID length to a larger= value (which I'm still not convinced that this is really necessary).
There are two main reasons to keep the compressed encoding:
  1. In the compressed encoding, we can reasonably expect that al= l / most values will be used in practice, so we won't expose any bits o= n the wire that identify a packet as "QUIC traffic" by having a p= redictable value.
  2. The 1-byte encoding has the disadvantage that an = implementation still needs to be able to deal with connection ID lengths of= 255 bytes, just to be able to send Version Negotiation packets. To me, it = seems absurd to write a QUIC implementation that is able to handle packets = with a combined connection ID overhead of 510 bytes. Since VNPs are suppose= d to be sent in response to any Long Header packet, you'd have to put s= ome careful thought into the design of your data types to avoid this becomi= ng a DoS vector.

=
On Tue, Jun 18, 2019 at 3:50 AM Chris= tian Huitema <h= uitema@huitema.net> wrote:
=20 =20 =20

I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.

Regarding the "CID length limit", I thing there are two is= sues: transmission overhead, and costs to the community.

I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.

I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained= those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects perfor= mance.

Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.

-- Christian Huitema

On 6/17/2019 9:16 AM, Roberto Peon wrote:
=20 =20 =20

What I think people are saying so far:

=C2=A0=C2=A01) QUIC v1 would limit CID lengt= h to something one of {32, 36, or 48}

=C2=A0 =C2=A02) Representation of CID length= as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant.


That seems reasonable to me / I=E2=80=99d still support that.<= /u>

-=3DR

From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
Date: Monday, June 17, 2019 at 8:55 AM
To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>, Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <martenseemann@gmail.com>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>, Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Consensus Call: More Connection ID Space #2736

=C2=A0

My take is similar =E2=80=93 48 is probably excessive, while 32 is likely the upper limit of =E2=80=9Creasona= ble=E2=80=9D (it should probably be a factor of 8, so 32 or 24?).

=C2=A0

We are firmly committed for using CID for in-cluster load balancing / anycast pop routing.=C2=A0 This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D.=C2=A0 This is a very interesting topic, but I w= ould hesitate to attempt to solve it fully and =E2=80=9Cin general=E2= =80=9D in QUIC v1.

=C2=A0

  • Igor

=C2=A0

From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.o= rg>

My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly.

=C2=A0

However, I'd like the max size to = be smaller than 48(but larger than 18).=C2=A0 If we think 20 o= r 24 is sufficient, I'd prefer that.=C2=A0 Kazuho suggest= ed 32, which is better, but I don't believe the server needs t= o use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled.=C2=A0 The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm.=C2=A0 I can imagine nesting lo= ad balancers, but that's well in the range of QUIC v2 from my perspective.

=C2=A0

Whatever we do, I'd really prefer = to resolve this sooner rather than later and be truly done with it.

=C2=A0

On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2= =80=99s small is limited.

=C2=A0

I do think the invariants should allow for long CID=E2=80=99s as proposed, and that the long header overhead is not important.

=C2=A0

But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s wil= l ossify in all kinds of stacks.

=C2=A0

I good reference on an algorithm like suggested by Christian would go a long way.

=C2=A0

If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looki= ng for excuses to upgrade QUIC versions soon.<= /u>

=C2=A0

If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers t= o deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.

=C2=A0

M= ikkel

=C2=A0

On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:

2= 019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema <huitema@huitema.net>:
>
> On 6/15/2019 10:55 PM, Kazuho Oku wrote:
>
> > _If_ we are to allow loose coupling between a load balancer and a
> > server, each of the two should be given the freedom to choose it's own
> > CID encryption scheme. Because all the standardized block ciphers are
> > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID
> > length of QUIC needs to be double amount of that, plus one or two
> > bytes for each of the two for identifying the CID encryption keys. For
> > key identification and other supplemental use, we currently allocate 2
> > bytes (18-16=3D2).
>
> That reasoning is based on the assumption that both the load balancer
> and the server must use a block cipher with 128 bit block length in
> order to encrypt the CID. If they were constrained to stay within a
> short global limit, they could use different sets of algorithms.
>
> Assume for example that we split the CID between 32 bits encoding the
> number of the server in the server farm, and 64 bit encoding the
> connection number for the server. The server can pick a random value for
> the connection number, and use a hash table. The load balancer could use
> a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID
> as an initial vector. Voila, 96 CID, with demonstrably strong encryption.
>
> Or assume that the server wants to use short CID. We now split the CID
> between 32 bit for the server number in the farm, and 32 bit for the
> connection number in the server. The server builds that connection
> number by using a 32 bit variant of FFX. The load balancer also uses a
> 32 bit variant, using the lower 32 bit of the CID as initial vector for
> this FFX encryption.
>
> These are just two examples. And yes you may want to add 2 bytes for key
> identification, etc. In both encryption algorithms, you can feed these
> two bytes as additional IV for the FFX algorithm. And in both cases, we
> are well below the 18 byte limit.
>
> Yes, that requires some creative engineering. But it is not rocker
> science. And it seems better than carrying tons of overhead in the
> header, and becoming less efficient than HTTP2/TLS/TCP.

I agree that it would not be the end of the world for the load
balancers if we decide to stick on the 18-byte limit. However, as you
state, it requires some creativeness.

To me it seems that the question is if we have a strong reason to
require some people to be creative, for all the versions of QUIC in
the future. I personally think that there isn't a strong reason,
because people can use shorter CIDs regardless of the decision we
make. IIUC, the overhead that everyone needs to accept is:

* one byte increase in the long header packets
* the minimum size of short header packets becoming slightly greater
(otherwise, the peer might not be able to send a stateless reset)

I'd say that the first bullet point is negligible. The second point
could also be, because I'd assume that the only frequently-sent
packets that require additional padding is the ACK-only packets, but
there's no reason to pad ACK-only packets in hope that you'd see a
stateless reset.

Therefore, my (not-so-strong) preference has been to provide extra
room, so that some people with necessity can use longer CIDs.

>
> -- Christian Huitema
>
>
>



--
Kazuho Oku

--000000000000d16750058b90c6d5-- From nobody Mon Jun 17 22:00:45 2019 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 6A4EB1203F5 for ; Mon, 17 Jun 2019 22:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eW890mVN2t7 for ; Mon, 17 Jun 2019 22:00:40 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::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 BAFB2120234 for ; Mon, 17 Jun 2019 22:00:39 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id s21so11645934lji.8 for ; Mon, 17 Jun 2019 22:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=klZP0WeTa6PDIHau6obghaT4kh7D4MQZ/9kuWPmBeC0=; b=pjMvsYKSAsw3Tfhbd40fbzozGvXDdsqBZdzW8aQsTKDx18Igl2dz6qligFSzW9P4+s rxIiSzuyJTw+Dhz9N1hhbl/3WVKujbZroSCfksJwf4tAdxpwGqz5mgWA3lJuCbpWpd6a QXLbjiux2blOwOVjbk+kLcyGo2LHU02R/XomOu4dbKWRPTMt3e49exWoVRo02r+/fRd6 ZiJuGMAsaG2aiElzTbYXqS/Cp7aFZ0xHr+wM9vKTnEhIJpjfnzM7G/mVA0iNlDuu6EWs CY2/VpkGUZTfbzrkHCU2wuUbSakUVLOjIzAzbARG3Lb0dHjQ4uxQIu4TFMcFMqHtLArZ 2PUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=klZP0WeTa6PDIHau6obghaT4kh7D4MQZ/9kuWPmBeC0=; b=jJNoVpWwjUEXHLRHHhRZW0HhvnJqere/8aPpqLC1aK/9qZd93o3Lvs0paRE6s2vTRc eSOJ3Nwl3Iw6/q1WysmNhBidikdNqLbNTncZctzu7onVLGsl0FbppNRN5l0XYcGFznej EiaEVtvQ7hwGzzyTUQV4+ZXqlswXVn5i6Aws/A8CgFihgIOWVyhSn9OQeHb7rplJTJkC xcI4kRjucWeIDVhm9e6Uoag/L6mcvDpD6O+oviHm6HOCzJfXo8g+vs+FzV55z3yhsls7 bESZPIZxbawFABxW33rhRCF2L/auWDxAGxDF63R8r4kpRg/K8OhFtcgj5agpIcPhWLsc DmKA== X-Gm-Message-State: APjAAAXmunWnVjdfEt+UnByLLhEaA5NDSRUWLsVgB5a65o3zCrhxOyAr qZmuX1Pe/PdaxSykNQNJ74SSZdnkjnn164pTYH8= X-Google-Smtp-Source: APXvYqz4W5kmmAMjZu6UNqWoY9tKjYU0ULB7BW9EO/nqyhYqtqz8Okk1SIQHdA5rADLFdc28AQ0lnCRADq4wCZ3XHHw= X-Received: by 2002:a2e:6c07:: with SMTP id h7mr688395ljc.177.1560834037806; Mon, 17 Jun 2019 22:00:37 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> In-Reply-To: From: Kazuho Oku Date: Tue, 18 Jun 2019 14:00:26 +0900 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Ian Swett Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Christian Huitema , Dmitri Tikhonov , "Philipp S. Tiesel" , Mike Bishop , Martin Thomson , Marten Seemann , Lars Eggert , QUIC WG , Martin Duke Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 05:00:44 -0000 2019=E5=B9=B46=E6=9C=8818=E6=97=A5(=E7=81=AB) 0:37 Ian Swett : > > My intuition says making the change to the invariants is the right thing = to do, but I don't feel that strongly. Though I am a bit concerned about the CID length getting ossified, eventually forcing us going down to a maximum to probably 32 bytes, unless we permit and see actual use of something longer than that in v1. > However, I'd like the max size to be smaller than 48(but larger than 18).= If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32= , which is better, but I don't believe the server needs to use a separate b= lock cipher when giving out connection IDs, because I believe it's impracti= cal for the load balancer and server to be that decoupled. The server has = to give out a CID that the load balancer will use to route back to the serv= er, so they have to share enough an encryption key/algorithm. It's great to see discussions pointing to the design variations we need to support in load balancers. Clarifying the trade-offs is critical to reaching the right answer. IIUC, there are three design variations. Design 1) Load balancer and servers sharing the crypto algorithm and key Maximum length will be one cipher block size + key identifier, meaning that the status-quo of 18 bytes is sufficient. There is no point in selecting a number like 24, because a block cipher cannot compress only half of a block [1]. Design 2) Server uses it's own CID encryption key, server ID in plaintext We *might* want to support deployments that do not share cipher keys between load balancer and the servers. The simplest design of such a deployment is a load balancer prepending (or appending) the server ID in plaintext to the server-generated CID (the server still needs to know it's server ID). This might sound insecure, but we could argue that exposure of the server ID is indifferent from the server IP address being exposed in a deployment that does not use a load balancer. Under such a design, the maximum length of the CID would be 18 bytes (governed by each server) + couple of bytes to identify the server. Design 3) Server uses it's own CID encryption key, server ID also encrypte= d In this design, the maximum length of a CID needs to be 36 bytes (i.e. 2 cipher blocks + key identifier for the server + key identifier for the load balancer). Even though the server can use a it's own cipher for encrypting it's internals in the CID, it still need to aware of the cipher and the key that the load balancer uses for routing the packets. We could use a stream cipher to reduce the size for couple of bytes, but the reduction can never be greater than 7 bytes, and will be much less in practice [2]. Admittedly, design 3 is no-less simpler than design 1, in sense that the load balancer and the server need to still share the cipher and the key. CID of design 1 can have per-server opaque field 64-bit or more (which on the wire is encrypted using the shared key). Per-server opaque field of 64-bits would be to store a sequence number for identifying the connection, and also the server process ID or thread ID that handles the connection. Therefore, I think the question regarding the maximum CID length that we need to support in v1 (and possibly also in invariants) depends on which of the aforementioned designs we are going to support. My preference goes to either supporting design 1 only (in case 4-bit CIDL will be sufficient, and we have the option to bake it into invariants, the benefit being that there would be no ossification), or all the three designs. I do not think if there is practical difference in the maximum being like 24 or like 36. [1] As Christian has pointed out there are solutions like FFX, but I am not sure if we would see wide adoption of such mode in load balancers because it's much slower than block ciphers in ECB mode, and also because IIUC there is a patent. [2] See the discussion on Stream CID Cipher Algorithm in https://github.com/martinduke/draft-duke-quic-load-balancers/blob/master/dr= aft-duke-quic-load-balancers.md > I can imagine nesting load balancers, but that's well in the range of QUI= C v2 from my perspective. > > Whatever we do, I'd really prefer to resolve this sooner rather than late= r and be truly done with it. > > On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> >> Since it is more likely that you pay for egress traffic than ingress tra= ffic, the motivation to keep CID=E2=80=99s small is limited. >> >> I do think the invariants should allow for long CID=E2=80=99s as propose= d, and that the long header overhead is not important. >> >> But for QUIC v1, if we allow for a long CID, a rush to market will set p= recedence and long CID=E2=80=99s will ossify in all kinds of stacks. >> >> I good reference on an algorithm like suggested by Christian would go a = long way. >> >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2= =80=99s not like we are not looking for excuses to upgrade QUIC versions so= on. >> >> If CID length negotiation is needed, this could be done via QUIC version= s. For example two functionally equivalent versions, but one with longer CI= D=E2=80=99s. This would also allow routers to deal with changes in CID leng= ths. A negotiated TP would not (easily) allow for that and aside I do not t= hink CID length in TP is the way to go. >> >> Mikkel >> >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: >> >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema : >> > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >> > >> > > _If_ we are to allow loose coupling between a load balancer and a >> > > server, each of the two should be given the freedom to choose it's o= wn >> > > CID encryption scheme. Because all the standardized block ciphers ar= e >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum C= ID >> > > length of QUIC needs to be double amount of that, plus one or two >> > > bytes for each of the two for identifying the CID encryption keys. F= or >> > > key identification and other supplemental use, we currently allocate= 2 >> > > bytes (18-16=3D2). >> > >> > That reasoning is based on the assumption that both the load balancer >> > and the server must use a block cipher with 128 bit block length in >> > order to encrypt the CID. If they were constrained to stay within a >> > short global limit, they could use different sets of algorithms. >> > >> > Assume for example that we split the CID between 32 bits encoding the >> > number of the server in the server farm, and 64 bit encoding the >> > connection number for the server. The server can pick a random value f= or >> > the connection number, and use a hash table. The load balancer could u= se >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the C= ID >> > as an initial vector. Voila, 96 CID, with demonstrably strong encrypti= on. >> > >> > Or assume that the server wants to use short CID. We now split the CID >> > between 32 bit for the server number in the farm, and 32 bit for the >> > connection number in the server. The server builds that connection >> > number by using a 32 bit variant of FFX. The load balancer also uses a >> > 32 bit variant, using the lower 32 bit of the CID as initial vector fo= r >> > this FFX encryption. >> > >> > These are just two examples. And yes you may want to add 2 bytes for k= ey >> > identification, etc. In both encryption algorithms, you can feed these >> > two bytes as additional IV for the FFX algorithm. And in both cases, w= e >> > are well below the 18 byte limit. >> > >> > Yes, that requires some creative engineering. But it is not rocker >> > science. And it seems better than carrying tons of overhead in the >> > header, and becoming less efficient than HTTP2/TLS/TCP. >> >> I agree that it would not be the end of the world for the load >> balancers if we decide to stick on the 18-byte limit. However, as you >> state, it requires some creativeness. >> >> To me it seems that the question is if we have a strong reason to >> require some people to be creative, for all the versions of QUIC in >> the future. I personally think that there isn't a strong reason, >> because people can use shorter CIDs regardless of the decision we >> make. IIUC, the overhead that everyone needs to accept is: >> >> * one byte increase in the long header packets >> * the minimum size of short header packets becoming slightly greater >> (otherwise, the peer might not be able to send a stateless reset) >> >> I'd say that the first bullet point is negligible. The second point >> could also be, because I'd assume that the only frequently-sent >> packets that require additional padding is the ACK-only packets, but >> there's no reason to pad ACK-only packets in hope that you'd see a >> stateless reset. >> >> Therefore, my (not-so-strong) preference has been to provide extra >> room, so that some people with necessity can use longer CIDs. >> >> > >> > -- Christian Huitema >> > >> > >> > >> >> >> >> -- >> Kazuho Oku >> -- Kazuho Oku From nobody Mon Jun 17 22:48:37 2019 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 603341203F5 for ; Mon, 17 Jun 2019 22:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DUyMdcon6xM for ; Mon, 17 Jun 2019 22:48:33 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 8DE02120405 for ; Mon, 17 Jun 2019 22:48:32 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id k21so19788494edq.3 for ; Mon, 17 Jun 2019 22:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=JLF5kBCWathPn0vvslLdA4599EvPQmuaJeUvt6pH0aU=; b=sLVbeXRFqUKp+h/o0oVtKxqwQZe73mwcHrAPeENuL9mrv+36e7/bU1C/vAU0gqO/nc nncuZmVMk9Q9rEJakzU7aQD8UllD140Ia4m0+s1usRM1KM1zpPumY+FYdxw/nx5WQufh ET0a26n1dbnMZMcq/c8jFTfLmwsYm8et4ppr0V4dIxUWV9z5tKG2+Ybs7PWGxIzlSoxW cWlL8nVTA2C7ufw7weVwL4xHYvWleledKQbmmlzjaJ4TGm8ccKoT6fi8QjBtGW1i+xx3 K7vcxLshxIz+jK0EtP55THzj2nLs/v6WPVYkicVLHqNcPiKT2mAme1UwO8u+G3Ogi/H0 XRVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=JLF5kBCWathPn0vvslLdA4599EvPQmuaJeUvt6pH0aU=; b=X7XHE6ieb1IEMjkNVCU/m0RISqrQqT3s0ivB9yj2VGlakR5lN1MRxWJe6fnFVwZcVN CHSx3zpvAMyqOtZtrFCyiTS22X8HzG/rBxXpnUAmCWVURLbtM9CrRVY5cZJ+Nst/EH90 cuGZ1xU7Xa3Mk1jhXCYkPfdaBb/Bo4NMfescUf0T+ZKpiDXZ/5GC6UMDGj34rXD3E3PK lP2HHUwqlBBk4Hbe08CvCpNQeNZMd3VMj33QjGKEPyFBaksW3DvBcuVqzFMFDt7aw8As 6sso6oXDnbyKDZF42WTho+iWMvTfoVdinzXQ24Us/dkCSW5MisAYpvpT4jdIuFB+pkza tmKQ== X-Gm-Message-State: APjAAAUk2lKoCpC5baMiBbxrRTj1iQ7IGOna596KEeRM6oyMI1xjGpX3 inTaKry6B0VJmOG04KKmZ7nnXIRDmSNF/zppktI= X-Google-Smtp-Source: APXvYqxToumriB0Nr9za4KDPAbTe8Zb26AFJXpOqagS2DL7chspBxhEqt/ZKxP0JzcxprlROanOnEnczr2r4SbqvHn0= X-Received: by 2002:a17:906:6b53:: with SMTP id o19mr23921345ejs.27.1560836911087; Mon, 17 Jun 2019 22:48:31 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 17 Jun 2019 22:48:29 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <9bad0a0f-63e0-4503-81f7-a7f1404cd58d@www.fastmail.com> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 17 Jun 2019 22:48:29 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Ian Swett , Kazuho Oku Cc: QUIC WG , Mike Bishop , Martin Thomson , Marten Seemann , Christian Huitema , Dmitri Tikhonov , Martin Duke , Lars Eggert , "Philipp S. Tiesel" Content-Type: multipart/alternative; boundary="000000000000a344cd058b92a97f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 05:48:37 -0000 --000000000000a344cd058b92a97f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While advocating for a short CID (18-24) in v1, I=E2=80=99ll note that priv= acy of server ID is not exactly correlated to IP because 1) you could NAT the IP at the router and/or do IPv6 mutations on a block that you own. 2) you might have a transport other than IP in some network topology, notably one that uses CID in place of IP (but that would not be v1). The argument that 24 is not useful because block size, I=E2=80=99m not buyi= ng because you do not have to follow a design where that is important but it might be worth more than 18 to some. To Seeman: I think you can separate the concerns on CID size into three parts: vneg, handshake, and post handshake. So you don=E2=80=99t have to ma= ke special handling of CIDs in general you just need to treat the vneg CID as something other than a regular CID. I agree that 254 combined CID sounds excessive, but 640K wasn=E2=80=99t enough either. Ossification / detection based on 8-bit CID length? I think that is a concern, but I also think that 18 x 18 in 4-bit pairs will signal: =E2=80= =9CHi cooporate firewall, I am a chrome browser, or something close to that=E2=80= =9D. Mikkel On 18 June 2019 at 07.00.38, Kazuho Oku (kazuhooku@gmail.com) wrote: 2019=E5=B9=B46=E6=9C=8818=E6=97=A5(=E7=81=AB) 0:37 Ian Swett : > > My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly. Though I am a bit concerned about the CID length getting ossified, eventually forcing us going down to a maximum to probably 32 bytes, unless we permit and see actual use of something longer than that in v1. > However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. It's great to see discussions pointing to the design variations we need to support in load balancers. Clarifying the trade-offs is critical to reaching the right answer. IIUC, there are three design variations. Design 1) Load balancer and servers sharing the crypto algorithm and key Maximum length will be one cipher block size + key identifier, meaning that the status-quo of 18 bytes is sufficient. There is no point in selecting a number like 24, because a block cipher cannot compress only half of a block [1]. Design 2) Server uses it's own CID encryption key, server ID in plaintext We *might* want to support deployments that do not share cipher keys between load balancer and the servers. The simplest design of such a deployment is a load balancer prepending (or appending) the server ID in plaintext to the server-generated CID (the server still needs to know it's server ID). This might sound insecure, but we could argue that exposure of the server ID is indifferent from the server IP address being exposed in a deployment that does not use a load balancer. Under such a design, the maximum length of the CID would be 18 bytes (governed by each server) + couple of bytes to identify the server. Design 3) Server uses it's own CID encryption key, server ID also encrypted In this design, the maximum length of a CID needs to be 36 bytes (i.e. 2 cipher blocks + key identifier for the server + key identifier for the load balancer). Even though the server can use a it's own cipher for encrypting it's internals in the CID, it still need to aware of the cipher and the key that the load balancer uses for routing the packets. We could use a stream cipher to reduce the size for couple of bytes, but the reduction can never be greater than 7 bytes, and will be much less in practice [2]. Admittedly, design 3 is no-less simpler than design 1, in sense that the load balancer and the server need to still share the cipher and the key. CID of design 1 can have per-server opaque field 64-bit or more (which on the wire is encrypted using the shared key). Per-server opaque field of 64-bits would be to store a sequence number for identifying the connection, and also the server process ID or thread ID that handles the connection. Therefore, I think the question regarding the maximum CID length that we need to support in v1 (and possibly also in invariants) depends on which of the aforementioned designs we are going to support. My preference goes to either supporting design 1 only (in case 4-bit CIDL will be sufficient, and we have the option to bake it into invariants, the benefit being that there would be no ossification), or all the three designs. I do not think if there is practical difference in the maximum being like 24 or like 36. [1] As Christian has pointed out there are solutions like FFX, but I am not sure if we would see wide adoption of such mode in load balancers because it's much slower than block ciphers in ECB mode, and also because IIUC there is a patent. [2] See the discussion on Stream CID Cipher Algorithm in https://github.com/martinduke/draft-duke-quic-load-balancers/blob/master/dr= aft-duke-quic-load-balancers.md > I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective. > > Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it. > > On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: >> >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited. >> >> I do think the invariants should allow for long CID=E2=80=99s as propose= d, and that the long header overhead is not important. >> >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. >> >> I good reference on an algorithm like suggested by Christian would go a long way. >> >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2= =80=99s not like we are not looking for excuses to upgrade QUIC versions soon. >> >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in= CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go. >> >> Mikkel >> >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: >> >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema : >> > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >> > >> > > _If_ we are to allow loose coupling between a load balancer and a >> > > server, each of the two should be given the freedom to choose it's own >> > > CID encryption scheme. Because all the standardized block ciphers are >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum C= ID >> > > length of QUIC needs to be double amount of that, plus one or two >> > > bytes for each of the two for identifying the CID encryption keys. For >> > > key identification and other supplemental use, we currently allocate 2 >> > > bytes (18-16=3D2). >> > >> > That reasoning is based on the assumption that both the load balancer >> > and the server must use a block cipher with 128 bit block length in >> > order to encrypt the CID. If they were constrained to stay within a >> > short global limit, they could use different sets of algorithms. >> > >> > Assume for example that we split the CID between 32 bits encoding the >> > number of the server in the server farm, and 64 bit encoding the >> > connection number for the server. The server can pick a random value for >> > the connection number, and use a hash table. The load balancer could use >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption. >> > >> > Or assume that the server wants to use short CID. We now split the CID >> > between 32 bit for the server number in the farm, and 32 bit for the >> > connection number in the server. The server builds that connection >> > number by using a 32 bit variant of FFX. The load balancer also uses a >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for >> > this FFX encryption. >> > >> > These are just two examples. And yes you may want to add 2 bytes for key >> > identification, etc. In both encryption algorithms, you can feed these >> > two bytes as additional IV for the FFX algorithm. And in both cases, we >> > are well below the 18 byte limit. >> > >> > Yes, that requires some creative engineering. But it is not rocker >> > science. And it seems better than carrying tons of overhead in the >> > header, and becoming less efficient than HTTP2/TLS/TCP. >> >> I agree that it would not be the end of the world for the load >> balancers if we decide to stick on the 18-byte limit. However, as you >> state, it requires some creativeness. >> >> To me it seems that the question is if we have a strong reason to >> require some people to be creative, for all the versions of QUIC in >> the future. I personally think that there isn't a strong reason, >> because people can use shorter CIDs regardless of the decision we >> make. IIUC, the overhead that everyone needs to accept is: >> >> * one byte increase in the long header packets >> * the minimum size of short header packets becoming slightly greater >> (otherwise, the peer might not be able to send a stateless reset) >> >> I'd say that the first bullet point is negligible. The second point >> could also be, because I'd assume that the only frequently-sent >> packets that require additional padding is the ACK-only packets, but >> there's no reason to pad ACK-only packets in hope that you'd see a >> stateless reset. >> >> Therefore, my (not-so-strong) preference has been to provide extra >> room, so that some people with necessity can use longer CIDs. >> >> > >> > -- Christian Huitema >> > >> > >> > >> >> >> >> -- >> Kazuho Oku >> --=20 Kazuho Oku --000000000000a344cd058b92a97f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = While advocating for= a short CID (18-24) in v1, I=E2=80=99ll note that privacy of server ID is = not exactly correlated to IP because

1) you could NAT the IP at the router and/or do IPv6 mutati= ons on a block that you own.
2) you might have a transport other than IP in some network= topology, notably one that uses CID in place of IP (but that would not be = v1).

The argument tha= t 24 is not useful because block size, I=E2=80=99m not buying because you d= o not have to follow a design where that is important but it might be worth= more than 18 to some.


Ossification / detection based on 8-bit CID le= ngth? I think that is a concern, but I also think that 18 x 18 in 4-bit pai= rs will signal: =E2=80=9CHi cooporate firewall, I am a chrome browser, or s= omething close to that=E2=80=9D.

Mikkel

=

On 18 June 2019 at 07.00.38, Kazuh= o Oku (kazuhooku@gmail.com) wrot= e:

<= div>2019=E5=B9=B46=E6=9C=8818=E6=97=A5(=E7=81=AB) 0:37 Ian Swett <ianswett@google.com>:
>
> My intuition says making the change to the invariants is the right= thing to do, but I don't feel that strongly.

Though I am a bit concerned about the CID length getting ossified,
eventually forcing us going down to a maximum to probably 32 bytes,
unless we permit and see actual use of something longer than that in
v1.

> However, I'd like the max size to be smaller than 48(but large= r than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazu= ho suggested 32, which is better, but I don't believe the server needs = to use a separate block cipher when giving out connection IDs, because I be= lieve it's impractical for the load balancer and server to be that deco= upled. The server has to give out a CID that the load balancer will use to= route back to the server, so they have to share enough an encryption key/a= lgorithm.

It's great to see discussions pointing to the design variations we
need to support in load balancers. Clarifying the trade-offs is
critical to reaching the right answer.

IIUC, there are three design variations.

Design 1) Load balancer and servers sharing the crypto algorithm and ke= y

Maximum length will be one cipher block size + key identifier, meaning
that the status-quo of 18 bytes is sufficient.
There is no point in selecting a number like 24, because a block
cipher cannot compress only half of a block [1].

Design 2) Server uses it's own CID encryption key, server ID in pla= intext

We *might* want to support deployments that do not share cipher keys
between load balancer and the servers.

The simplest design of such a deployment is a load balancer prepending
(or appending) the server ID in plaintext to the server-generated CID
(the server still needs to know it's server ID). This might sound
insecure, but we could argue that exposure of the server ID is
indifferent from the server IP address being exposed in a deployment
that does not use a load balancer.

Under such a design, the maximum length of the CID would be 18 bytes
(governed by each server) + couple of bytes to identify the server.

Design 3) Server uses it's own CID encryption key, server ID also = encrypted

In this design, the maximum length of a CID needs to be 36 bytes (i.e.
2 cipher blocks + key identifier for the server + key identifier for
the load balancer).
Even though the server can use a it's own cipher for encrypting it&= #39;s
internals in the CID, it still need to aware of the cipher and the key
that the load balancer uses for routing the packets. We could use a
stream cipher to reduce the size for couple of bytes, but the
reduction can never be greater than 7 bytes, and will be much less in
practice [2].

Admittedly, design 3 is no-less simpler than design 1, in sense that
the load balancer and the server need to still share the cipher and
the key. CID of design 1 can have per-server opaque field 64-bit or
more (which on the wire is encrypted using the shared key). Per-server
opaque field of 64-bits would be to store a sequence number for
identifying the connection, and also the server process ID or thread
ID that handles the connection.

Therefore, I think the question regarding the maximum CID length that
we need to support in v1 (and possibly also in invariants) depends on
which of the aforementioned designs we are going to support.

My preference goes to either supporting design 1 only (in case 4-bit
CIDL will be sufficient, and we have the option to bake it into
invariants, the benefit being that there would be no ossification), or
all the three designs. I do not think if there is practical difference
in the maximum being like 24 or like 36.

[1] As Christian has pointed out there are solutions like FFX, but I
am not sure if we would see wide adoption of such mode in load
balancers because it's much slower than block ciphers in ECB mode, = and
also because IIUC there is a patent.
[2] See the discussion on Stream CID Cipher Algorithm in
https://github.com/martindu= ke/draft-duke-quic-load-balancers/blob/master/draft-duke-quic-load-balancer= s.md



> I can imagine nesting load balancers, but that's well in the r= ange of QUIC v2 from my perspective.
>
> Whatever we do, I'd really prefer to resolve this sooner rathe= r than later and be truly done with it.
>
> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen = <mikkelfj@gmail.com> wrote:
>>
>> Since it is more likely that you pay for egress traffic than i= ngress traffic, the motivation to keep CID=E2=80=99s small is limited.
>>
>> I do think the invariants should allow for long CID=E2=80=99s = as proposed, and that the long header overhead is not important.
>>
>> But for QUIC v1, if we allow for a long CID, a rush to market = will set precedence and long CID=E2=80=99s will ossify in all kinds of stac= ks.
>>
>> I good reference on an algorithm like suggested by Christian w= ould go a long way.
>>
>> If CID length 18 turns out to be not enough, we can add a QUIC= v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC v= ersions soon.
>>
>> If CID length negotiation is needed, this could be done via QU= IC versions. For example two functionally equivalent versions, but one with= longer CID=E2=80=99s. This would also allow routers to deal with changes i= n CID lengths. A negotiated TP would not (easily) allow for that and aside = I do not think CID length in TP is the way to go.
>>
>> Mikkel
>>
>> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:
>>
>> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian = Huitema <huitema@huitema.net&= gt;:
>> >
>> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
>> >
>> > > _If_ we are to allow loose coupling between a load b= alancer and a
>> > > server, each of the two should be given the freedom = to choose it's own
>> > > CID encryption scheme. Because all the standardized = block ciphers are
>> > > now 128-bits (=3D 16 bytes), that naturally means th= at the maximum CID
>> > > length of QUIC needs to be double amount of that, pl= us one or two
>> > > bytes for each of the two for identifying the CID en= cryption keys. For
>> > > key identification and other supplemental use, we cu= rrently allocate 2
>> > > bytes (18-16=3D2).
>> >
>> > That reasoning is based on the assumption that both the l= oad balancer
>> > and the server must use a block cipher with 128 bit block= length in
>> > order to encrypt the CID. If they were constrained to sta= y within a
>> > short global limit, they could use different sets of algo= rithms.
>> >
>> > Assume for example that we split the CID between 32 bits = encoding the
>> > number of the server in the server farm, and 64 bit encod= ing the
>> > connection number for the server. The server can pick a r= andom value for
>> > the connection number, and use a hash table. The load bal= ancer could use
>> > a 32 bit variant of the FFX algorithm, using the lower 64= bit of the CID
>> > as an initial vector. Voila, 96 CID, with demonstrably st= rong encryption.
>> >
>> > Or assume that the server wants to use short CID. We now = split the CID
>> > between 32 bit for the server number in the farm, and 32 = bit for the
>> > connection number in the server. The server builds that c= onnection
>> > number by using a 32 bit variant of FFX. The load balance= r also uses a
>> > 32 bit variant, using the lower 32 bit of the CID as init= ial vector for
>> > this FFX encryption.
>> >
>> > These are just two examples. And yes you may want to add = 2 bytes for key
>> > identification, etc. In both encryption algorithms, you c= an feed these
>> > two bytes as additional IV for the FFX algorithm. And in = both cases, we
>> > are well below the 18 byte limit.
>> >
>> > Yes, that requires some creative engineering. But it is n= ot rocker
>> > science. And it seems better than carrying tons of overhe= ad in the
>> > header, and becoming less efficient than HTTP2/TLS/TCP.
>>
>> I agree that it would not be the end of the world for the load
>> balancers if we decide to stick on the 18-byte limit. However,= as you
>> state, it requires some creativeness.
>>
>> To me it seems that the question is if we have a strong reason= to
>> require some people to be creative, for all the versions of QU= IC in
>> the future. I personally think that there isn't a strong r= eason,
>> because people can use shorter CIDs regardless of the decision= we
>> make. IIUC, the overhead that everyone needs to accept is:
>>
>> * one byte increase in the long header packets
>> * the minimum size of short header packets becoming slightly g= reater
>> (otherwise, the peer might not be able to send a stateless res= et)
>>
>> I'd say that the first bullet point is negligible. The sec= ond point
>> could also be, because I'd assume that the only frequently= -sent
>> packets that require additional padding is the ACK-only packet= s, but
>> there's no reason to pad ACK-only packets in hope that you= 'd see a
>> stateless reset.
>>
>> Therefore, my (not-so-strong) preference has been to provide e= xtra
>> room, so that some people with necessity can use longer CIDs.
>>
>> >
>> > -- Christian Huitema
>> >
>> >
>> >
>>
>>
>>
>> --
>> Kazuho Oku
>>


--
Kazuho Oku
--000000000000a344cd058b92a97f-- From nobody Tue Jun 18 01:24:22 2019 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 589081205DC for ; Tue, 18 Jun 2019 01:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIKg8pqOyRPV for ; Tue, 18 Jun 2019 01:24:19 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 0CDAE120475 for ; Tue, 18 Jun 2019 01:24:18 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x5I8No0O032656 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jun 2019 10:23:50 +0200 Received: from philipp-laptop.ods.tu-berlin.de ([130.149.141.20]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1hd9NL-0006rO-9z; Tue, 18 Jun 2019 10:21:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Call: More Connection ID Space #2736 From: "Philipp S. Tiesel" In-Reply-To: Date: Tue, 18 Jun 2019 10:23:51 +0200 Cc: Christian Huitema , Roberto Peon , "Lubashev, Igor" , Ian Swett , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Dmitri Tikhonov , Mike Bishop , Martin Duke , Lars Eggert , QUIC WG , Martin Thomson , Kazuho Oku Content-Transfer-Encoding: quoted-printable Message-Id: <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> To: Marten Seemann X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 18 Jun 2019 08:24:21 -0000 > On 18. Jun 2019, at 05:33, Marten Seemann = wrote: >=20 > I'd prefer keeping the "compressed 4 bits" solution, even if we decide = to increase the connection ID length to a larger value (which I'm still = not convinced that this is really necessary). This would be easy if we change the encoding of the connection ID = length, e.g., to be DCIL*4 allowing up to 60 byte connection IDs. While = we can not encode one or two byte connection IDs in long header packets, = we can still use them in short header packets. This split between long and short header also allows to use much longer = connection IDs after the handshake. I don=E2=80=99t see much use in it, but it may take off some fear that = 24/32/36/48/60 byte connection IDs might not be long enough in the = future. >=20 > There are two main reasons to keep the compressed encoding: > =E2=80=A2 In the compressed encoding, we can reasonably expect = that all / most values will be used in practice, so we won't expose any = bits on the wire that identify a packet as "QUIC traffic" by having a = predictable value. > =E2=80=A2 The 1-byte encoding has the disadvantage that an = implementation still needs to be able to deal with connection ID lengths = of 255 bytes, just to be able to send Version Negotiation packets. To = me, it seems absurd to write a QUIC implementation that is able to = handle packets with a combined connection ID overhead of 510 bytes. = Since VNPs are supposed to be sent in response to any Long Header = packet, you'd have to put some careful thought into the design of your = data types to avoid this becoming a DoS vector. >=20 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema = wrote: > I too agree that using one byte in the invariant is preferable to the = current "compressed 4 bits" solution. >=20 > Regarding the "CID length limit", I thing there are two issues: = transmission overhead, and costs to the community. >=20 > I am not too concerned with the transmission overhead, as we have = there the right mix of costs and incentives. Servers who chose to use = longer CID will get more transmission overhead, and thus transmission = less efficiently than their competitors. They may chose to use longer = CID as a trade-off between transmission efficiency and ease of = management. Competition will sort that out. I note that YouTube is = apparently doing fine with smallish CID, so I trust that there will be = competition. >=20 > I am much more concerned with the shared costs, which are a variation = of the "tragedy of the commons". Dmitry explained those costs well in a = previous message. The simpler implementation is to make the "cid_t a = fixed-size object that can fit the largest CID and eat the overhead for = all CIDs." But each connection object carries a large number of = instances of the CID type. Having a very large max CID would imply a = large overhead. The alternative is to "Make cid_t a variable-size = object", but too affects performance. >=20 > Hence the push-back. I would personally prefer a max size of 16, and I = think that 32 is the highest practical limit. >=20 > -- Christian Huitema >=20 > On 6/17/2019 9:16 AM, Roberto Peon wrote: >> What I think people are saying so far: >>=20 >> 1) QUIC v1 would limit CID length to something one of {32, 36, or = 48} >>=20 >> 2) Representation of CID length as a byte is still OK, thus a QUIC = v2 could use longer CIDs as needed by changing the spec while keeping = the invariants=E2=80=A6 invariant. >>=20 >>=20 >> That seems reasonable to me / I=E2=80=99d still support that. >>=20 >> -=3DR >>=20 >>=20 >> From: QUIC on behalf of "Lubashev, Igor" = >> Date: Monday, June 17, 2019 at 8:55 AM >> To: Ian Swett , Mikkel = Fahn=C3=B8e J=C3=B8rgensen >> Cc: Dmitri Tikhonov , Christian Huitema = , "Philipp S. Tiesel" , Mike = Bishop , Martin Thomson , = Marten Seemann , Lars Eggert , = QUIC WG , Martin Duke , Kazuho = Oku >> Subject: RE: Consensus Call: More Connection ID Space #2736 >>=20 >> =20 >>=20 >> My take is similar =E2=80=93 48 is probably excessive, while 32 is = likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should = probably be a factor of 8, so 32 or 24?). >>=20 >> =20 >>=20 >> We are firmly committed for using CID for in-cluster load balancing / = anycast pop routing. This discussion is taking us, however, to a new = territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled = routing in an overlay network=E2=80=9D. This is a very interesting = topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin = general=E2=80=9D in QUIC v1. >>=20 >> =20 >>=20 >> =E2=80=A2 Igor >> =20 >>=20 >> From: Ian Swett >>=20 >> My intuition says making the change to the invariants is the right = thing to do, but I don't feel that strongly. >>=20 >> =20 >>=20 >> However, I'd like the max size to be smaller than 48(but larger than = 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho = suggested 32, which is better, but I don't believe the server needs to = use a separate block cipher when giving out connection IDs, because I = believe it's impractical for the load balancer and server to be that = decoupled. The server has to give out a CID that the load balancer will = use to route back to the server, so they have to share enough an = encryption key/algorithm. I can imagine nesting load balancers, but = that's well in the range of QUIC v2 from my perspective. >>=20 >> =20 >>=20 >> Whatever we do, I'd really prefer to resolve this sooner rather than = later and be truly done with it. >>=20 >> =20 >>=20 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >>=20 >> Since it is more likely that you pay for egress traffic than ingress = traffic, the motivation to keep CID=E2=80=99s small is limited. >>=20 >> =20 >>=20 >> I do think the invariants should allow for long CID=E2=80=99s as = proposed, and that the long header overhead is not important. >>=20 >> =20 >>=20 >> But for QUIC v1, if we allow for a long CID, a rush to market will = set precedence and long CID=E2=80=99s will ossify in all kinds of = stacks. >>=20 >> =20 >>=20 >> I good reference on an algorithm like suggested by Christian would go = a long way. >>=20 >> =20 >>=20 >> If CID length 18 turns out to be not enough, we can add a QUIC v2. = It=E2=80=99s not like we are not looking for excuses to upgrade QUIC = versions soon. >>=20 >> =20 >>=20 >> If CID length negotiation is needed, this could be done via QUIC = versions. For example two functionally equivalent versions, but one with = longer CID=E2=80=99s. This would also allow = routers to deal with changes in CID lengths. A negotiated TP would not = (easily) allow for that and aside I do not think CID length in TP is the = way to go. >>=20 >> =20 >>=20 >> Mikkel >>=20 >> =20 >>=20 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: >>=20 >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema = :=20 >> >=20 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=20 >> >=20 >> > > _If_ we are to allow loose coupling between a load balancer and a=20= >> > > server, each of the two should be given the freedom to choose = it's own=20 >> > > CID encryption scheme. Because all the standardized block ciphers = are=20 >> > > now 128-bits (=3D 16 bytes), that naturally means that the = maximum CID=20 >> > > length of QUIC needs to be double amount of that, plus one or two=20= >> > > bytes for each of the two for identifying the CID encryption = keys. For=20 >> > > key identification and other supplemental use, we currently = allocate 2=20 >> > > bytes (18-16=3D2).=20 >> >=20 >> > That reasoning is based on the assumption that both the load = balancer=20 >> > and the server must use a block cipher with 128 bit block length in=20= >> > order to encrypt the CID. If they were constrained to stay within a=20= >> > short global limit, they could use different sets of algorithms.=20 >> >=20 >> > Assume for example that we split the CID between 32 bits encoding = the=20 >> > number of the server in the server farm, and 64 bit encoding the=20 >> > connection number for the server. The server can pick a random = value for=20 >> > the connection number, and use a hash table. The load balancer = could use=20 >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of = the CID=20 >> > as an initial vector. Voila, 96 CID, with demonstrably strong = encryption.=20 >> >=20 >> > Or assume that the server wants to use short CID. We now split the = CID=20 >> > between 32 bit for the server number in the farm, and 32 bit for = the=20 >> > connection number in the server. The server builds that connection=20= >> > number by using a 32 bit variant of FFX. The load balancer also = uses a=20 >> > 32 bit variant, using the lower 32 bit of the CID as initial vector = for=20 >> > this FFX encryption.=20 >> >=20 >> > These are just two examples. And yes you may want to add 2 bytes = for key=20 >> > identification, etc. In both encryption algorithms, you can feed = these=20 >> > two bytes as additional IV for the FFX algorithm. And in both = cases, we=20 >> > are well below the 18 byte limit.=20 >> >=20 >> > Yes, that requires some creative engineering. But it is not rocker=20= >> > science. And it seems better than carrying tons of overhead in the=20= >> > header, and becoming less efficient than HTTP2/TLS/TCP.=20 >>=20 >> I agree that it would not be the end of the world for the load=20 >> balancers if we decide to stick on the 18-byte limit. However, as you=20= >> state, it requires some creativeness.=20 >>=20 >> To me it seems that the question is if we have a strong reason to=20 >> require some people to be creative, for all the versions of QUIC in=20= >> the future. I personally think that there isn't a strong reason,=20 >> because people can use shorter CIDs regardless of the decision we=20 >> make. IIUC, the overhead that everyone needs to accept is:=20 >>=20 >> * one byte increase in the long header packets=20 >> * the minimum size of short header packets becoming slightly greater=20= >> (otherwise, the peer might not be able to send a stateless reset)=20 >>=20 >> I'd say that the first bullet point is negligible. The second point=20= >> could also be, because I'd assume that the only frequently-sent=20 >> packets that require additional padding is the ACK-only packets, but=20= >> there's no reason to pad ACK-only packets in hope that you'd see a=20 >> stateless reset.=20 >>=20 >> Therefore, my (not-so-strong) preference has been to provide extra=20 >> room, so that some people with necessity can use longer CIDs.=20 >>=20 >> >=20 >> > -- Christian Huitema=20 >> >=20 >> >=20 >> >=20 >>=20 >>=20 >>=20 >> --=20 >> Kazuho Oku >>=20 AVE! Philipp S. Tiesel --=20 Philipp S. Tiesel=20 https://philipp.tiesel.net/ From nobody Wed Jun 19 21:43:28 2019 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 7EDF1120449 for ; Wed, 19 Jun 2019 21:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 luyyB7ZcRCCh for ; Wed, 19 Jun 2019 21:43:24 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 A5C7212043B for ; Wed, 19 Jun 2019 21:43:23 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id s15so1637862wmj.3 for ; Wed, 19 Jun 2019 21:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F1fA0hMKkHvtQx009JcO7ObbFx5I2WRxwHnIwExrVLE=; b=XW4nM5dvNqdgTPt7JbxHs+aebe2FAQ0VXmsUkdxT585A9b7JKaRnwm3g4twMkgiMDG rbxVUpKjGIT2Js2Ri0C6NGYb/YzJF8AMPOnuFGSTwbEMKOq6Xg2Y3xZExFnkJCWc5kQm k+p2NE9Z03aXY9PXD7fHs2tWbE2IsXunfghKlo53lVXq8OvEuZOUqnUmbFBDFembHNWe R/nTT5wfIP6WWX1596/V65kHm+Hh9Q9mTC9A0ZfoANbsKMQ422ix6T8cDRDk9ZBU/ZjF y3MVKTh5igvNGSx2xDdQqJoGpCv0f4aPrIaZ6XM9wROsxyTHoXdPJceZidjIfkbFtaNk 9fAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F1fA0hMKkHvtQx009JcO7ObbFx5I2WRxwHnIwExrVLE=; b=Zvrj58jDe30unCzkrfk2XChu9JCcxJJN3vF1t4X6MXP/hcCb9eYIKjsN9dpbW9th4Y xESKdj8Co8B1f1hK9zme4PzJT0sJqTev/PRQG8m9stPantJNY1ytxwd2wMESk7w04uLI md94EwuUT/BPvcJNOWqRTz35RbmMD7wdha6/cQc925ZzQcFrw6gIvoupsIGG5/0KKJGD nIZEtQY1om+TkrvVb3/sJxYGXcqRZWUqw+BzPRQMHMo6fBYurZQ4hRISn3Wpoc1gtaPr ZsV4xLaJu1X0aFFuY66PVuGQDg2yY3/ZGeF3m3V66hHOADUrRjxjNvcZTLkFDVx2NWUh LiXg== X-Gm-Message-State: APjAAAV7qp/uMJloM2OmqZdL3vRlU7PcFoT7Crb0KoKFPs6oagnlmLRD u4YhQMo/8tv1hJzbjhNSUOJe7Bf2MdBHaFIULpA= X-Google-Smtp-Source: APXvYqyJdhusWJMLLPBXA+N+cV3A4/GLsxKgcfkGDpCk6Zbd6l6queTsB66dlFn7weRCr4yZ1U+PZO3VIeC3ENmgRTw= X-Received: by 2002:a05:600c:389:: with SMTP id w9mr735915wmd.139.1561005801542; Wed, 19 Jun 2019 21:43:21 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> In-Reply-To: <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> From: Martin Duke Date: Wed, 19 Jun 2019 21:43:10 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: "Philipp S. Tiesel" Cc: Marten Seemann , Christian Huitema , Roberto Peon , "Lubashev, Igor" , Ian Swett , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Dmitri Tikhonov , Mike Bishop , Lars Eggert , QUIC WG , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="0000000000004b172e058bb9fce4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 20 Jun 2019 04:43:27 -0000 --0000000000004b172e058bb9fce4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable so do I hear consensus emerging around 32B in v1, or should I leave the 18B limit in v1 for now and punt out that discussion? On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel wrote: > > > > On 18. Jun 2019, at 05:33, Marten Seemann > wrote: > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we decide > to increase the connection ID length to a larger value (which I'm still n= ot > convinced that this is really necessary). > > This would be easy if we change the encoding of the connection ID length, > e.g., to be DCIL*4 allowing up to 60 byte connection IDs. While we can no= t > encode one or two byte connection IDs in long header packets, we can stil= l > use them in short header packets. > > This split between long and short header also allows to use much longer > connection IDs after the handshake. > I don=E2=80=99t see much use in it, but it may take off some fear that > 24/32/36/48/60 byte connection IDs might not be long enough in the future= . > > > > > There are two main reasons to keep the compressed encoding: > > =E2=80=A2 In the compressed encoding, we can reasonably expect th= at all / > most values will be used in practice, so we won't expose any bits on the > wire that identify a packet as "QUIC traffic" by having a predictable val= ue. > > =E2=80=A2 The 1-byte encoding has the disadvantage that an implem= entation > still needs to be able to deal with connection ID lengths of 255 bytes, > just to be able to send Version Negotiation packets. To me, it seems absu= rd > to write a QUIC implementation that is able to handle packets with a > combined connection ID overhead of 510 bytes. Since VNPs are supposed to = be > sent in response to any Long Header packet, you'd have to put some carefu= l > thought into the design of your data types to avoid this becoming a DoS > vector. > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema > wrote: > > I too agree that using one byte in the invariant is preferable to the > current "compressed 4 bits" solution. > > > > Regarding the "CID length limit", I thing there are two issues: > transmission overhead, and costs to the community. > > > > I am not too concerned with the transmission overhead, as we have there > the right mix of costs and incentives. Servers who chose to use longer CI= D > will get more transmission overhead, and thus transmission less efficient= ly > than their competitors. They may chose to use longer CID as a trade-off > between transmission efficiency and ease of management. Competition will > sort that out. I note that YouTube is apparently doing fine with smallish > CID, so I trust that there will be competition. > > > > I am much more concerned with the shared costs, which are a variation o= f > the "tragedy of the commons". Dmitry explained those costs well in a > previous message. The simpler implementation is to make the "cid_t a > fixed-size object that can fit the largest CID and eat the overhead for a= ll > CIDs." But each connection object carries a large number of instances of > the CID type. Having a very large max CID would imply a large overhead. T= he > alternative is to "Make cid_t a variable-size object", but too affects > performance. > > > > Hence the push-back. I would personally prefer a max size of 16, and I > think that 32 is the highest practical limit. > > > > -- Christian Huitema > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > >> What I think people are saying so far: > >> > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48= } > >> > >> 2) Representation of CID length as a byte is still OK, thus a QUIC > v2 could use longer CIDs as needed by changing the spec while keeping the > invariants=E2=80=A6 invariant. > >> > >> > >> That seems reasonable to me / I=E2=80=99d still support that. > >> > >> -=3DR > >> > >> > >> From: QUIC on behalf of "Lubashev, Igor" < > ilubashe@akamai.com> > >> Date: Monday, June 17, 2019 at 8:55 AM > >> To: Ian Swett , Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > >> Cc: Dmitri Tikhonov , Christian Huitema < > huitema@huitema.net>, "Philipp S. Tiesel" , Mike > Bishop , Martin Thomson , Marten > Seemann , Lars Eggert , QUIC WG > , Martin Duke , Kazuho Oku < > kazuhooku@gmail.com> > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > >> > >> > >> > >> My take is similar =E2=80=93 48 is probably excessive, while 32 is lik= ely the > upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a fact= or of 8, so 32 or > 24?). > >> > >> > >> > >> We are firmly committed for using CID for in-cluster load balancing / > anycast pop routing. This discussion is taking us, however, to a new > territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing= in an overlay > network=E2=80=9D. This is a very interesting topic, but I would hesitate= to > attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > >> > >> > >> > >> =E2=80=A2 Igor > >> > >> > >> From: Ian Swett > >> > >> My intuition says making the change to the invariants is the right > thing to do, but I don't feel that strongly. > >> > >> > >> > >> However, I'd like the max size to be smaller than 48(but larger than > 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho > suggested 32, which is better, but I don't believe the server needs to us= e > a separate block cipher when giving out connection IDs, because I believe > it's impractical for the load balancer and server to be that decoupled. > The server has to give out a CID that the load balancer will use to route > back to the server, so they have to share enough an encryption > key/algorithm. I can imagine nesting load balancers, but that's well in > the range of QUIC v2 from my perspective. > >> > >> > >> > >> Whatever we do, I'd really prefer to resolve this sooner rather than > later and be truly done with it. > >> > >> > >> > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> > >> Since it is more likely that you pay for egress traffic than ingress > traffic, the motivation to keep CID=E2=80=99s small is limited. > >> > >> > >> > >> I do think the invariants should allow for long CID=E2=80=99s as propo= sed, and > that the long header overhead is not important. > >> > >> > >> > >> But for QUIC v1, if we allow for a long CID, a rush to market will set > precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > >> > >> > >> > >> I good reference on an algorithm like suggested by Christian would go = a > long way. > >> > >> > >> > >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It= =E2=80=99s > not like we are not looking for excuses to upgrade QUIC versions soon. > >> > >> > >> > >> If CID length negotiation is needed, this could be done via QUIC > versions. For example two functionally equivalent versions, but one with > longer CID=E2=80=99s. This would also allow routers to= deal with > changes in CID lengths. A negotiated TP would not (easily) allow for that > and aside I do not think CID length in TP is the way to go. > >> > >> > >> > >> Mikkel > >> > >> > >> > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote: > >> > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema = : > >> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > >> > > >> > > _If_ we are to allow loose coupling between a load balancer and a > >> > > server, each of the two should be given the freedom to choose it's > own > >> > > CID encryption scheme. Because all the standardized block ciphers > are > >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum > CID > >> > > length of QUIC needs to be double amount of that, plus one or two > >> > > bytes for each of the two for identifying the CID encryption keys. > For > >> > > key identification and other supplemental use, we currently > allocate 2 > >> > > bytes (18-16=3D2). > >> > > >> > That reasoning is based on the assumption that both the load balance= r > >> > and the server must use a block cipher with 128 bit block length in > >> > order to encrypt the CID. If they were constrained to stay within a > >> > short global limit, they could use different sets of algorithms. > >> > > >> > Assume for example that we split the CID between 32 bits encoding th= e > >> > number of the server in the server farm, and 64 bit encoding the > >> > connection number for the server. The server can pick a random value > for > >> > the connection number, and use a hash table. The load balancer could > use > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the > CID > >> > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > >> > > >> > Or assume that the server wants to use short CID. We now split the > CID > >> > between 32 bit for the server number in the farm, and 32 bit for the > >> > connection number in the server. The server builds that connection > >> > number by using a 32 bit variant of FFX. The load balancer also uses > a > >> > 32 bit variant, using the lower 32 bit of the CID as initial vector > for > >> > this FFX encryption. > >> > > >> > These are just two examples. And yes you may want to add 2 bytes for > key > >> > identification, etc. In both encryption algorithms, you can feed > these > >> > two bytes as additional IV for the FFX algorithm. And in both cases, > we > >> > are well below the 18 byte limit. > >> > > >> > Yes, that requires some creative engineering. But it is not rocker > >> > science. And it seems better than carrying tons of overhead in the > >> > header, and becoming less efficient than HTTP2/TLS/TCP. > >> > >> I agree that it would not be the end of the world for the load > >> balancers if we decide to stick on the 18-byte limit. However, as you > >> state, it requires some creativeness. > >> > >> To me it seems that the question is if we have a strong reason to > >> require some people to be creative, for all the versions of QUIC in > >> the future. I personally think that there isn't a strong reason, > >> because people can use shorter CIDs regardless of the decision we > >> make. IIUC, the overhead that everyone needs to accept is: > >> > >> * one byte increase in the long header packets > >> * the minimum size of short header packets becoming slightly greater > >> (otherwise, the peer might not be able to send a stateless reset) > >> > >> I'd say that the first bullet point is negligible. The second point > >> could also be, because I'd assume that the only frequently-sent > >> packets that require additional padding is the ACK-only packets, but > >> there's no reason to pad ACK-only packets in hope that you'd see a > >> stateless reset. > >> > >> Therefore, my (not-so-strong) preference has been to provide extra > >> room, so that some people with necessity can use longer CIDs. > >> > >> > > >> > -- Christian Huitema > >> > > >> > > >> > > >> > >> > >> > >> -- > >> Kazuho Oku > >> > > AVE! > Philipp S. Tiesel > > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ > > --0000000000004b172e058bb9fce4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
so do I hear consensus emerging around 32B in v1, or shoul= d I leave the 18B limit in v1 for now and punt out that discussion?
On Tue, = Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote:


> On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrote:=
>
> I'd prefer keeping the "compressed 4 bits" solution, eve= n if we decide to increase the connection ID length to a larger value (whic= h I'm still not convinced that this is really necessary).

This would be easy if we change the encoding of the connection ID length, e= .g., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not e= ncode one or two byte connection IDs in long header packets, we can still u= se them in short header packets.

This split between long and short header also allows to use much longer con= nection IDs after the handshake.
I don=E2=80=99t see much use in it, but it may take off some fear that 24/3= 2/36/48/60 byte connection IDs might not be long enough in the future.

>
> There are two main reasons to keep the compressed encoding:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 In the compressed encoding, we can= reasonably expect that all / most values will be used in practice, so we w= on't expose any bits on the wire that identify a packet as "QUIC t= raffic" by having a predictable value.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 The 1-byte encoding has the disadv= antage that an implementation still needs to be able to deal with connectio= n ID lengths of 255 bytes, just to be able to send Version Negotiation pack= ets. To me, it seems absurd to write a QUIC implementation that is able to = handle packets with a combined connection ID overhead of 510 bytes. Since V= NPs are supposed to be sent in response to any Long Header packet, you'= d have to put some careful thought into the design of your data types to av= oid this becoming a DoS vector.
>
> On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net> wrote:=
> I too agree that using one byte in the invariant is preferable to the = current "compressed 4 bits" solution.
>
> Regarding the "CID length limit", I thing there are two issu= es: transmission overhead, and costs to the community.
>
> I am not too concerned with the transmission overhead, as we have ther= e the right mix of costs and incentives. Servers who chose to use longer CI= D will get more transmission overhead, and thus transmission less efficient= ly than their competitors. They may chose to use longer CID as a trade-off = between transmission efficiency and ease of management. Competition will so= rt that out. I note that YouTube is apparently doing fine with smallish CID= , so I trust that there will be competition.
>
> I am much more concerned with the shared costs, which are a variation = of the "tragedy of the commons". Dmitry explained those costs wel= l in a previous message. The simpler implementation is to make the "ci= d_t a fixed-size object that can fit the largest CID and eat the overhead f= or all CIDs." But each connection object carries a large number of ins= tances of the CID type. Having a very large max CID would imply a large ove= rhead. The alternative is to "Make cid_t a variable-size object",= but too affects performance.
>
> Hence the push-back. I would personally prefer a max size of 16, and I= think that 32 is the highest practical limit.
>
> -- Christian Huitema
>
> On 6/17/2019 9:16 AM, Roberto Peon wrote:
>> What I think people are saying so far:
>>
>>=C2=A0 =C2=A01) QUIC v1 would limit CID length to something one of = {32, 36, or 48}
>>
>>=C2=A0 =C2=A0 2) Representation of CID length as a byte is still OK= , thus a QUIC v2 could use longer CIDs as needed by changing the spec while= keeping the invariants=E2=80=A6 invariant.
>>
>>
>> That seems reasonable to me / I=E2=80=99d still support that.
>>
>> -=3DR
>>
>>
>> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor&quo= t; <ilubashe@ak= amai.com>
>> Date: Monday, June 17, 2019 at 8:55 AM
>> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fah= n=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
>> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huite= ma <huitema@hui= tema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>, Mike Bishop &l= t;mbishop@evequef= ou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <martenseemann@gmail.com&g= t;, Lars Eggert <la= rs@eggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>, Kazuh= o Oku <kazuhook= u@gmail.com>
>> Subject: RE: Consensus Call: More Connection ID Space #2736
>>
>>=C2=A0
>>
>> My take is similar =E2=80=93 48 is probably excessive, while 32 is= likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably= be a factor of 8, so 32 or 24?).
>>
>>=C2=A0
>>
>> We are firmly committed for using CID for in-cluster load balancin= g / anycast pop routing.=C2=A0 This discussion is taking us, however, to a = new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routi= ng in an overlay network=E2=80=9D.=C2=A0 This is a very interesting topic, = but I would hesitate to attempt to solve it fully and =E2=80=9Cin general= =E2=80=9D in QUIC v1.
>>
>>=C2=A0
>>
>>=C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Igor
>>=C2=A0
>>
>> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
>>
>> My intuition says making the change to the invariants is the right= thing to do, but I don't feel that strongly.
>>
>>=C2=A0
>>
>> However, I'd like the max size to be smaller than 48(but large= r than 18).=C2=A0 If we think 20 or 24 is sufficient, I'd prefer that.= =C2=A0 Kazuho suggested 32, which is better, but I don't believe the se= rver needs to use a separate block cipher when giving out connection IDs, b= ecause I believe it's impractical for the load balancer and server to b= e that decoupled.=C2=A0 The server has to give out a CID that the load bala= ncer will use to route back to the server, so they have to share enough an = encryption key/algorithm.=C2=A0 I can imagine nesting load balancers, but t= hat's well in the range of QUIC v2 from my perspective.
>>
>>=C2=A0
>>
>> Whatever we do, I'd really prefer to resolve this sooner rathe= r than later and be truly done with it.
>>
>>=C2=A0
>>
>> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen = <mikkelfj@gmail.= com> wrote:
>>
>> Since it is more likely that you pay for egress traffic than ingre= ss traffic, the motivation to keep CID=E2=80=99s small is limited.
>>
>>=C2=A0
>>
>> I do think the invariants should allow for long CID=E2=80=99s as p= roposed, and that the long header overhead is not important.
>>
>>=C2=A0
>>
>> But for QUIC v1, if we allow for a long CID, a rush to market will= set precedence and long CID=E2=80=99s will ossify in all kinds of stacks.<= br> >>
>>=C2=A0
>>
>> I good reference on an algorithm like suggested by Christian would= go a long way.
>>
>>=C2=A0
>>
>> If CID length 18 turns out to be not enough, we can add a QUIC v2.= It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versi= ons soon.
>>
>>=C2=A0
>>
>> If CID length negotiation is needed, this could be done via QUIC v= ersions. For example two functionally equivalent versions, but one with=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0longer CID=E2=80=99s. This would also allow routers to deal with chan= ges in CID lengths. A negotiated TP would not (easily) allow for that and a= side I do not think CID length in TP is the way to go.
>>
>>=C2=A0
>>
>> Mikkel
>>
>>=C2=A0
>>
>> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:
>>
>> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huit= ema <huitema@hu= itema.net>:
>> >
>> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
>> >
>> > > _If_ we are to allow loose coupling between a load balan= cer and a
>> > > server, each of the two should be given the freedom to c= hoose it's own
>> > > CID encryption scheme. Because all the standardized bloc= k ciphers are
>> > > now 128-bits (=3D 16 bytes), that naturally means that t= he maximum CID
>> > > length of QUIC needs to be double amount of that, plus o= ne or two
>> > > bytes for each of the two for identifying the CID encryp= tion keys. For
>> > > key identification and other supplemental use, we curren= tly allocate 2
>> > > bytes (18-16=3D2).
>> >
>> > That reasoning is based on the assumption that both the load = balancer
>> > and the server must use a block cipher with 128 bit block len= gth in
>> > order to encrypt the CID. If they were constrained to stay wi= thin a
>> > short global limit, they could use different sets of algorith= ms.
>> >
>> > Assume for example that we split the CID between 32 bits enco= ding the
>> > number of the server in the server farm, and 64 bit encoding = the
>> > connection number for the server. The server can pick a rando= m value for
>> > the connection number, and use a hash table. The load balance= r could use
>> > a 32 bit variant of the FFX algorithm, using the lower 64 bit= of the CID
>> > as an initial vector. Voila, 96 CID, with demonstrably strong= encryption.
>> >
>> > Or assume that the server wants to use short CID. We now spli= t the CID
>> > between 32 bit for the server number in the farm, and 32 bit = for the
>> > connection number in the server. The server builds that conne= ction
>> > number by using a 32 bit variant of FFX. The load balancer al= so uses a
>> > 32 bit variant, using the lower 32 bit of the CID as initial = vector for
>> > this FFX encryption.
>> >
>> > These are just two examples. And yes you may want to add 2 by= tes for key
>> > identification, etc. In both encryption algorithms, you can f= eed these
>> > two bytes as additional IV for the FFX algorithm. And in both= cases, we
>> > are well below the 18 byte limit.
>> >
>> > Yes, that requires some creative engineering. But it is not r= ocker
>> > science. And it seems better than carrying tons of overhead i= n the
>> > header, and becoming less efficient than HTTP2/TLS/TCP.
>>
>> I agree that it would not be the end of the world for the load >> balancers if we decide to stick on the 18-byte limit. However, as = you
>> state, it requires some creativeness.
>>
>> To me it seems that the question is if we have a strong reason to =
>> require some people to be creative, for all the versions of QUIC i= n
>> the future. I personally think that there isn't a strong reaso= n,
>> because people can use shorter CIDs regardless of the decision we =
>> make. IIUC, the overhead that everyone needs to accept is:
>>
>> * one byte increase in the long header packets
>> * the minimum size of short header packets becoming slightly great= er
>> (otherwise, the peer might not be able to send a stateless reset) =
>>
>> I'd say that the first bullet point is negligible. The second = point
>> could also be, because I'd assume that the only frequently-sen= t
>> packets that require additional padding is the ACK-only packets, b= ut
>> there's no reason to pad ACK-only packets in hope that you'= ;d see a
>> stateless reset.
>>
>> Therefore, my (not-so-strong) preference has been to provide extra=
>> room, so that some people with necessity can use longer CIDs.
>>
>> >
>> > -- Christian Huitema
>> >
>> >
>> >
>>
>>
>>
>> --
>> Kazuho Oku
>>

AVE!
=C2=A0 =C2=A0Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

--0000000000004b172e058bb9fce4-- From nobody Thu Jun 20 11:57:12 2019 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 9FD36120153 for ; Thu, 20 Jun 2019 11:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=hYL+fq6/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q2s9su6+ 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 x5PRvZlakFhA for ; Thu, 20 Jun 2019 11:57:07 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E936B1200F3 for ; Thu, 20 Jun 2019 11:57:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 25E7F4C1 for ; Thu, 20 Jun 2019 14:57:06 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 20 Jun 2019 14:57:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=Z9MFp cP88xgKIOZ8Cym4i9300qs02t+VYg7xWUSMq/4=; b=hYL+fq6//d/zKlBHM1drl HOzcNVn/pNXQfTG1vKVniKn73chKgJU4vCOt4UDRuz+xho/GbM2y7ABjQmtoci/p iTGN/MZoILsVhLV9qqfQJ53I5IU6ovOs+O38vAuZsjNpDHsoa/wXk8Ox05241tH6 WTV9a8ctIe1IPgla468ts26kUZLtLES2heQfQEVNpfB0cDXpivA9D/23SfnBLdvv g06FmVK05ZjKuU4hkKAa+c4SsCezdFZMLnqRJ6OFTFhE2J52Mf87FzMNgwUodhEc sHDxzFpxi1T2neAEscv5hWvC+qsJstEV7oXilR+YkUrDQPf5wru73RATIyQ/PKqz Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Z9MFpcP88xgKIOZ8Cym4i9300qs02t+VYg7xWUSMq /4=; b=q2s9su6+Mm9cOqVKuZaxNVJwZrEuq/ti2KIRCG50TZ7P99ljyZ5zklbim oVspvBkaRYlkAyhC8/b5ECEwr4IopV43mw9H0OHqBBfR01MKdG/y7wzFdl0u09D3 1oLIS7VGQN6EzYjo6jab9qqZh018iUMPWbgCgw+Pznzl6KWa08aD41FJiT6lEhl+ 9EoIpE03xKYSVAWHFEElbQP8hK+U+YRdPb5I7o4QG91ensAlXYGKe45V8aM0V5ml Theel7m+/3J8/ZbXQFzkLe2vRoyesAlDWlr2uR2C73RqogVi7x0VupYpVGHIkuVu fAg4pnofSv+CKZq8llgOFPnpRmx7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdeggddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehtihgvshgvlhdrnhgvthenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4F190E00A1; Thu, 20 Jun 2019 14:57:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-728-g133121a-fmstable-20190620v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> Date: Thu, 20 Jun 2019 11:57:07 -0700 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Call: More Connection ID Space #2736 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 20 Jun 2019 18:57:11 -0000 That seems a little high. I think that Ian's principle here is what sho= uld guide us: what is the minimum you can handle? What I've heard is th= at 18 might have been workable, but it was REALLY close to the edge to t= he point that you weren't confident it was enough, even in the near term= . But that suggests that 20 is workable. On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > so do I hear consensus emerging around 32B in v1, or should I leave th= e=20 > 18B limit in v1 for now and punt out that discussion? >=20 > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel = wrote: > >=20 > >=20 > > > On 18. Jun 2019, at 05:33, Marten Seemann wrote: > > >=20 > > > I'd prefer keeping the "compressed 4 bits" solution, even if we d= ecide to increase the connection ID length to a larger value (which I'm = still not convinced that this is really necessary). > >=20 > > This would be easy if we change the encoding of the connection ID l= ength, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While = we can not encode one or two byte connection IDs in long header packets,= we can still use them in short header packets. > >=20 > > This split between long and short header also allows to use much lo= nger connection IDs after the handshake. > > I don=E2=80=99t see much use in it, but it may take off some fear t= hat 24/32/36/48/60 byte connection IDs might not be long enough in the f= uture. > >=20 > > >=20 > > > There are two main reasons to keep the compressed encoding: > > > =E2=80=A2 In the compressed encoding, we can reasonably expect th= at all / most values will be used in practice, so we won't expose any bi= ts on the wire that identify a packet as "QUIC traffic" by having a pred= ictable value. > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an implem= entation still needs to be able to deal with connection ID lengths of 25= 5 bytes, just to be able to send Version Negotiation packets. To me, it = seems absurd to write a QUIC implementation that is able to handle packe= ts with a combined connection ID overhead of 510 bytes. Since VNPs are s= upposed to be sent in response to any Long Header packet, you'd have to = put some careful thought into the design of your data types to avoid thi= s becoming a DoS vector. > > >=20 > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema wrote: > > > I too agree that using one byte in the invariant is preferable to= the current "compressed 4 bits" solution. > > >=20 > > > Regarding the "CID length limit", I thing there are two issues: t= ransmission overhead, and costs to the community. > > >=20 > > > I am not too concerned with the transmission overhead, as we have= there the right mix of costs and incentives. Servers who chose to use l= onger CID will get more transmission overhead, and thus transmission les= s efficiently than their competitors. They may chose to use longer CID a= s a trade-off between transmission efficiency and ease of management. Co= mpetition will sort that out. I note that YouTube is apparently doing fi= ne with smallish CID, so I trust that there will be competition. > > >=20 > > > I am much more concerned with the shared costs, which are a varia= tion of the "tragedy of the commons". Dmitry explained those costs well = in a previous message. The simpler implementation is to make the "cid_t = a fixed-size object that can fit the largest CID and eat the overhead fo= r all CIDs." But each connection object carries a large number of instan= ces of the CID type. Having a very large max CID would imply a large ove= rhead. The alternative is to "Make cid_t a variable-size object", but to= o affects performance. > > >=20 > > > Hence the push-back. I would personally prefer a max size of 16, = and I think that 32 is the highest practical limit. > > >=20 > > > -- Christian Huitema > > >=20 > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > >> What I think people are saying so far: > > >>=20 > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, o= r 48} > > >>=20 > > >> 2) Representation of CID length as a byte is still OK, thus a QU= IC v2 could use longer CIDs as needed by changing the spec while keeping= the invariants=E2=80=A6 invariant. > > >>=20 > > >>=20 > > >> That seems reasonable to me / I=E2=80=99d still support that. > > >>=20 > > >> -=3DR > > >>=20 > > >>=20 > > >> From: QUIC on behalf of "Lubashev, Igor"= > > >> Date: Monday, June 17, 2019 at 8:55 AM > > >> To: Ian Swett , Mikkel F= ahn=C3=B8e J=C3=B8rgensen > > >> Cc: Dmitri Tikhonov , Christian Hui= tema , "Philipp S. Tiesel" , Mi= ke Bishop , Martin Thomson , Ma= rten Seemann , Lars Eggert , Q= UIC WG , Martin Duke >, Kazuho Oku > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > >>=20 > > >>=20 > > >>=20 > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 = is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should pro= bably be a factor of 8, so 32 or 24?). > > >>=20 > > >>=20 > > >>=20 > > >> We are firmly committed for using CID for in-cluster load balanc= ing / anycast pop routing. This discussion is taking us, however, to a n= ew territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled rou= ting in an overlay network=E2=80=9D. This is a very interesting topic, b= ut I would hesitate to attempt to solve it fully and =E2=80=9Cin general= =E2=80=9D in QUIC v1. > > >>=20 > > >>=20 > > >>=20 > > >> =E2=80=A2 Igor > > >>=20 > > >>=20 > > >> From: Ian Swett > > >>=20 > > >> My intuition says making the change to the invariants is the rig= ht thing to do, but I don't feel that strongly. > > >>=20 > > >>=20 > > >>=20 > > >> However, I'd like the max size to be smaller than 48(but larger = than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho su= ggested 32, which is better, but I don't believe the server needs to use= a separate block cipher when giving out connection IDs, because I belie= ve it's impractical for the load balancer and server to be that decouple= d. The server has to give out a CID that the load balancer will use to r= oute back to the server, so they have to share enough an encryption key/= algorithm. I can imagine nesting load balancers, but that's well in the = range of QUIC v2 from my perspective. > > >>=20 > > >>=20 > > >>=20 > > >> Whatever we do, I'd really prefer to resolve this sooner rather = than later and be truly done with it. > > >>=20 > > >>=20 > > >>=20 > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgense= n wrote: > > >>=20 > > >> Since it is more likely that you pay for egress traffic than ing= ress traffic, the motivation to keep CID=E2=80=99s small is limited. > > >>=20 > > >>=20 > > >>=20 > > >> I do think the invariants should allow for long CID=E2=80=99s as= proposed, and that the long header overhead is not important. > > >>=20 > > >>=20 > > >>=20 > > >> But for QUIC v1, if we allow for a long CID, a rush to market wi= ll set precedence and long CID=E2=80=99s will ossify in all kinds of sta= cks. > > >>=20 > > >>=20 > > >>=20 > > >> I good reference on an algorithm like suggested by Christian wou= ld go a long way. > > >>=20 > > >>=20 > > >>=20 > > >> If CID length 18 turns out to be not enough, we can add a QUIC v= 2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC = versions soon. > > >>=20 > > >>=20 > > >>=20 > > >> If CID length negotiation is needed, this could be done via QUIC= versions. For example two functionally equivalent versions, but one wit= h longer CID=E2=80=99s. This would also allow routers to deal with chang= es in CID lengths. A negotiated TP would not (easily) allow for that and= aside I do not think CID length in TP is the way to go. > > >>=20 > > >>=20 > > >>=20 > > >> Mikkel > > >>=20 > > >>=20 > > >>=20 > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wr= ote: > > >>=20 > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hu= itema :=20 > > >> >=20 > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=20 > > >> >=20 > > >> > > _If_ we are to allow loose coupling between a load balancer = and a=20 > > >> > > server, each of the two should be given the freedom to choos= e it's own=20 > > >> > > CID encryption scheme. Because all the standardized block ci= phers are=20 > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the m= aximum CID=20 > > >> > > length of QUIC needs to be double amount of that, plus one o= r two=20 > > >> > > bytes for each of the two for identifying the CID encryption= keys. For=20 > > >> > > key identification and other supplemental use, we currently = allocate 2=20 > > >> > > bytes (18-16=3D2).=20 > > >> >=20 > > >> > That reasoning is based on the assumption that both the load b= alancer=20 > > >> > and the server must use a block cipher with 128 bit block leng= th in=20 > > >> > order to encrypt the CID. If they were constrained to stay wit= hin a=20 > > >> > short global limit, they could use different sets of algorithm= s.=20 > > >> >=20 > > >> > Assume for example that we split the CID between 32 bits encod= ing the=20 > > >> > number of the server in the server farm, and 64 bit encoding t= he=20 > > >> > connection number for the server. The server can pick a random= value for=20 > > >> > the connection number, and use a hash table. The load balancer= could use=20 > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit = of the CID=20 > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong = encryption.=20 > > >> >=20 > > >> > Or assume that the server wants to use short CID. We now split= the CID=20 > > >> > between 32 bit for the server number in the farm, and 32 bit f= or the=20 > > >> > connection number in the server. The server builds that connec= tion=20 > > >> > number by using a 32 bit variant of FFX. The load balancer als= o uses a=20 > > >> > 32 bit variant, using the lower 32 bit of the CID as initial v= ector for=20 > > >> > this FFX encryption.=20 > > >> >=20 > > >> > These are just two examples. And yes you may want to add 2 byt= es for key=20 > > >> > identification, etc. In both encryption algorithms, you can fe= ed these=20 > > >> > two bytes as additional IV for the FFX algorithm. And in both = cases, we=20 > > >> > are well below the 18 byte limit.=20 > > >> >=20 > > >> > Yes, that requires some creative engineering. But it is not ro= cker=20 > > >> > science. And it seems better than carrying tons of overhead in= the=20 > > >> > header, and becoming less efficient than HTTP2/TLS/TCP.=20 > > >>=20 > > >> I agree that it would not be the end of the world for the load=20= > > >> balancers if we decide to stick on the 18-byte limit. However, a= s you=20 > > >> state, it requires some creativeness.=20 > > >>=20 > > >> To me it seems that the question is if we have a strong reason t= o=20 > > >> require some people to be creative, for all the versions of QUIC= in=20 > > >> the future. I personally think that there isn't a strong reason,= =20 > > >> because people can use shorter CIDs regardless of the decision w= e=20 > > >> make. IIUC, the overhead that everyone needs to accept is:=20 > > >>=20 > > >> * one byte increase in the long header packets=20 > > >> * the minimum size of short header packets becoming slightly gre= ater=20 > > >> (otherwise, the peer might not be able to send a stateless reset= )=20 > > >>=20 > > >> I'd say that the first bullet point is negligible. The second po= int=20 > > >> could also be, because I'd assume that the only frequently-sent=20= > > >> packets that require additional padding is the ACK-only packets,= but=20 > > >> there's no reason to pad ACK-only packets in hope that you'd see= a=20 > > >> stateless reset.=20 > > >>=20 > > >> Therefore, my (not-so-strong) preference has been to provide ext= ra=20 > > >> room, so that some people with necessity can use longer CIDs.=20= > > >>=20 > > >> >=20 > > >> > -- Christian Huitema=20 > > >> >=20 > > >> >=20 > > >> >=20 > > >>=20 > > >>=20 > > >>=20 > > >> --=20 > > >> Kazuho Oku > > >>=20 > >=20 > > AVE! > > Philipp S. Tiesel > >=20 > > --=20 > > Philipp S. Tiesel=20 > > https://philipp.tiesel.net/ > > From nobody Fri Jun 21 13:00:32 2019 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 65C821200F9 for ; Fri, 21 Jun 2019 13:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.508 X-Spam-Level: X-Spam-Status: No, score=-17.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ4SJrORC52z for ; Fri, 21 Jun 2019 13:00:27 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 BFFE112009E for ; Fri, 21 Jun 2019 13:00:26 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id u8so7687272wmm.1 for ; Fri, 21 Jun 2019 13:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QuxM8QQfoJoJMIrXZp41mLOTlneZCcImpf4HjYAjXi8=; b=lfHlvcPod8TJgF69oh/wG7/LobnOQUKPNYTPQXh033FHtwuP4Y7tiDQU9a6Kmzv4IU Wyn3xklaBbXTxM+bGorgDQCVBDNsi159iAGkgDhC+W01DtX40mcNpHms591B+sQsexTl bH7oEkJYX3dZrlKgmthVQAE50+NZrKtymqqi+Akbhuyy9Fhz3ok7hqM1+uGr+yZjx+mI t7POFcpf9L9F1cP9wA4mjFwiBBoUiRhYVTF8/Fa02Iz3jX9Yq0dTMc5FJUlivCySgbD5 Q5o9xpJARxAni6TLfVVnblZAEoiC/UBkj9Dw8vZKFs03GrME8SFFIS971Bw1yX14FuJe CYyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QuxM8QQfoJoJMIrXZp41mLOTlneZCcImpf4HjYAjXi8=; b=IuxtXORdHOg7rKa4pQXA4g6BUi+jXU2YES4iWYni5szV5iGePS9rsNn1uuoh1UK+yG RBFsefTEEq6Y9WkVe2JoGuzZRlABzXclCPa5M5Bs7xwMrw1dyRsScY1j116FzXmbQSOo bxeoMFcC/nXWO5D7CZfBd07vbHDdWsCusMkp3pCW/UlAm5geqV0hevzcNbiWZLR6/JXN xYpLs+7sc8V9SslIq0J61Dg8Tv1bNNewddUVFbsQUiJ7mAXIgIdbzj1q1Uy0zh6JUUsG +aXe4Re+Be6LdD6i/j+9FGPKy+5DYWk+Di3UGWCg1b6EMpC8R8qjgSNY09SrQvQiaU+Y pbuQ== X-Gm-Message-State: APjAAAVt36lpyVWnIEayyEkiTylt+fuy1o+70Xas43/strteqkdWk5k5 piZnFu8Lk1lPFvXByfmLsdg8ki/+QasGmAq3gGe9q8pHBYM= X-Google-Smtp-Source: APXvYqyKnPoWIP4WUN7HasihO96dx0gOCZ3zbpdyfw2/L2PNspATfc9qAT4fQz/XwD8PgOYbdVPnZZ4uFpsWb4Q9nek= X-Received: by 2002:a7b:c775:: with SMTP id x21mr5153253wmk.9.1561147224735; Fri, 21 Jun 2019 13:00:24 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> In-Reply-To: From: Ian Swett Date: Fri, 21 Jun 2019 16:00:12 -0400 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c6233a058bdae973" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 20:00:32 -0000 --000000000000c6233a058bdae973 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the 3 options I see as well reasoned are: 1) Keep the status quo because we think we can put what we really need into 18 bytes if we try. 2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc. 3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID. 2 is my preferred option, though I can live with either of 1 or 3. Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs. On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote: > That seems a little high. I think that Ian's principle here is what > should guide us: what is the minimum you can handle? What I've heard is > that 18 might have been workable, but it was REALLY close to the edge to > the point that you weren't confident it was enough, even in the near > term.. But that suggests that 20 is workable. > > On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > > so do I hear consensus emerging around 32B in v1, or should I leave the > > 18B limit in v1 for now and punt out that discussion? > > > > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel > wrote: > > > > > > > > > > On 18. Jun 2019, at 05:33, Marten Seemann > wrote: > > > > > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we > decide to increase the connection ID length to a larger value (which I'm > still not convinced that this is really necessary). > > > > > > This would be easy if we change the encoding of the connection ID > length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While = we > can not encode one or two byte connection IDs in long header packets, we > can still use them in short header packets. > > > > > > This split between long and short header also allows to use much > longer connection IDs after the handshake. > > > I don=E2=80=99t see much use in it, but it may take off some fear th= at > 24/32/36/48/60 byte connection IDs might not be long enough in the future= . > > > > > > > > > > > There are two main reasons to keep the compressed encoding: > > > > =E2=80=A2 In the compressed encoding, we can reasonably expect tha= t all / > most values will be used in practice, so we won't expose any bits on the > wire that identify a packet as "QUIC traffic" by having a predictable val= ue. > > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an impleme= ntation > still needs to be able to deal with connection ID lengths of 255 bytes, > just to be able to send Version Negotiation packets. To me, it seems absu= rd > to write a QUIC implementation that is able to handle packets with a > combined connection ID overhead of 510 bytes. Since VNPs are supposed to = be > sent in response to any Long Header packet, you'd have to put some carefu= l > thought into the design of your data types to avoid this becoming a DoS > vector. > > > > > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < > huitema@huitema.net> wrote: > > > > I too agree that using one byte in the invariant is preferable to > the current "compressed 4 bits" solution. > > > > > > > > Regarding the "CID length limit", I thing there are two issues: > transmission overhead, and costs to the community. > > > > > > > > I am not too concerned with the transmission overhead, as we have > there the right mix of costs and incentives. Servers who chose to use > longer CID will get more transmission overhead, and thus transmission les= s > efficiently than their competitors. They may chose to use longer CID as a > trade-off between transmission efficiency and ease of management. > Competition will sort that out. I note that YouTube is apparently doing > fine with smallish CID, so I trust that there will be competition. > > > > > > > > I am much more concerned with the shared costs, which are a > variation of the "tragedy of the commons". Dmitry explained those costs > well in a previous message. The simpler implementation is to make the > "cid_t a fixed-size object that can fit the largest CID and eat the > overhead for all CIDs." But each connection object carries a large number > of instances of the CID type. Having a very large max CID would imply a > large overhead. The alternative is to "Make cid_t a variable-size object"= , > but too affects performance. > > > > > > > > Hence the push-back. I would personally prefer a max size of 16, > and I think that 32 is the highest practical limit. > > > > > > > > -- Christian Huitema > > > > > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > > >> What I think people are saying so far: > > > >> > > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or > 48} > > > >> > > > >> 2) Representation of CID length as a byte is still OK, thus a QUI= C > v2 could use longer CIDs as needed by changing the spec while keeping the > invariants=E2=80=A6 invariant. > > > >> > > > >> > > > >> That seems reasonable to me / I=E2=80=99d still support that. > > > >> > > > >> -=3DR > > > >> > > > >> > > > >> From: QUIC on behalf of "Lubashev, Igor" = < > ilubashe@akamai.com> > > > >> Date: Monday, June 17, 2019 at 8:55 AM > > > >> To: Ian Swett , Mikkel > Fahn=C3=B8e J=C3=B8rgensen > > > >> Cc: Dmitri Tikhonov , Christian > Huitema , "Philipp S. Tiesel" , > Mike Bishop , Martin Thomson , > Marten Seemann , Lars Eggert , > QUIC WG , Martin Duke martin..h.duke@gmail.com>>, Kazuho Oku > > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > > >> > > > >> > > > >> > > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 i= s likely > the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a = factor of 8, so 32 > or 24?). > > > >> > > > >> > > > >> > > > >> We are firmly committed for using CID for in-cluster load > balancing / anycast pop routing. This discussion is taking us, however, t= o > a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled r= outing in an > overlay network=E2=80=9D. This is a very interesting topic, but I would h= esitate to > attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > > > >> > > > >> > > > >> > > > >> =E2=80=A2 Igor > > > >> > > > >> > > > >> From: Ian Swett > > > >> > > > >> My intuition says making the change to the invariants is the righ= t > thing to do, but I don't feel that strongly. > > > >> > > > >> > > > >> > > > >> However, I'd like the max size to be smaller than 48(but larger > than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho > suggested 32, which is better, but I don't believe the server needs to us= e > a separate block cipher when giving out connection IDs, because I believe > it's impractical for the load balancer and server to be that decoupled. T= he > server has to give out a CID that the load balancer will use to route bac= k > to the server, so they have to share enough an encryption key/algorithm. = I > can imagine nesting load balancers, but that's well in the range of QUIC = v2 > from my perspective. > > > >> > > > >> > > > >> > > > >> Whatever we do, I'd really prefer to resolve this sooner rather > than later and be truly done with it. > > > >> > > > >> > > > >> > > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen= < > mikkelfj@gmail.com> wrote: > > > >> > > > >> Since it is more likely that you pay for egress traffic than > ingress traffic, the motivation to keep CID=E2=80=99s small is limited. > > > >> > > > >> > > > >> > > > >> I do think the invariants should allow for long CID=E2=80=99s as = proposed, > and that the long header overhead is not important. > > > >> > > > >> > > > >> > > > >> But for QUIC v1, if we allow for a long CID, a rush to market wil= l > set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > > > >> > > > >> > > > >> > > > >> I good reference on an algorithm like suggested by Christian woul= d > go a long way. > > > >> > > > >> > > > >> > > > >> If CID length 18 turns out to be not enough, we can add a QUIC v2= . > It=E2=80=99s not like we are not looking for excuses to upgrade QUIC vers= ions soon. > > > >> > > > >> > > > >> > > > >> If CID length negotiation is needed, this could be done via QUIC > versions. For example two functionally equivalent versions, but one with > longer CID=E2=80=99s. This would also allow routers to deal with changes = in CID > lengths. A negotiated TP would not (easily) allow for that and aside I do > not think CID length in TP is the way to go. > > > >> > > > >> > > > >> > > > >> Mikkel > > > >> > > > >> > > > >> > > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) > wrote: > > > >> > > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hui= tema : > > > >> > > > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > >> > > > > >> > > _If_ we are to allow loose coupling between a load balancer > and a > > > >> > > server, each of the two should be given the freedom to choose > it's own > > > >> > > CID encryption scheme. Because all the standardized block > ciphers are > > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the > maximum CID > > > >> > > length of QUIC needs to be double amount of that, plus one or > two > > > >> > > bytes for each of the two for identifying the CID encryption > keys. For > > > >> > > key identification and other supplemental use, we currently > allocate 2 > > > >> > > bytes (18-16=3D2). > > > >> > > > > >> > That reasoning is based on the assumption that both the load > balancer > > > >> > and the server must use a block cipher with 128 bit block lengt= h > in > > > >> > order to encrypt the CID. If they were constrained to stay > within a > > > >> > short global limit, they could use different sets of algorithms= . > > > >> > > > > >> > Assume for example that we split the CID between 32 bits > encoding the > > > >> > number of the server in the server farm, and 64 bit encoding th= e > > > >> > connection number for the server. The server can pick a random > value for > > > >> > the connection number, and use a hash table. The load balancer > could use > > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit o= f > the CID > > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > > > >> > > > > >> > Or assume that the server wants to use short CID. We now split > the CID > > > >> > between 32 bit for the server number in the farm, and 32 bit fo= r > the > > > >> > connection number in the server. The server builds that > connection > > > >> > number by using a 32 bit variant of FFX. The load balancer also > uses a > > > >> > 32 bit variant, using the lower 32 bit of the CID as initial > vector for > > > >> > this FFX encryption. > > > >> > > > > >> > These are just two examples. And yes you may want to add 2 byte= s > for key > > > >> > identification, etc. In both encryption algorithms, you can fee= d > these > > > >> > two bytes as additional IV for the FFX algorithm. And in both > cases, we > > > >> > are well below the 18 byte limit. > > > >> > > > > >> > Yes, that requires some creative engineering. But it is not > rocker > > > >> > science. And it seems better than carrying tons of overhead in > the > > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. > > > >> > > > >> I agree that it would not be the end of the world for the load > > > >> balancers if we decide to stick on the 18-byte limit. However, as > you > > > >> state, it requires some creativeness. > > > >> > > > >> To me it seems that the question is if we have a strong reason to > > > >> require some people to be creative, for all the versions of QUIC > in > > > >> the future. I personally think that there isn't a strong reason, > > > >> because people can use shorter CIDs regardless of the decision we > > > >> make. IIUC, the overhead that everyone needs to accept is: > > > >> > > > >> * one byte increase in the long header packets > > > >> * the minimum size of short header packets becoming slightly > greater > > > >> (otherwise, the peer might not be able to send a stateless reset) > > > >> > > > >> I'd say that the first bullet point is negligible. The second > point > > > >> could also be, because I'd assume that the only frequently-sent > > > >> packets that require additional padding is the ACK-only packets, > but > > > >> there's no reason to pad ACK-only packets in hope that you'd see = a > > > >> stateless reset. > > > >> > > > >> Therefore, my (not-so-strong) preference has been to provide extr= a > > > >> room, so that some people with necessity can use longer CIDs. > > > >> > > > >> > > > > >> > -- Christian Huitema > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Kazuho Oku > > > >> > > > > > > AVE! > > > Philipp S. Tiesel > > > > > > -- > > > Philipp S. Tiesel > > > https://philipp.tiesel.net/ > > > > > --000000000000c6233a058bdae973 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the 3 options I see as well reasoned are:
1) K= eep the status quo because we think we can put what we really need into 18 = bytes if we try.
2) Change to a 1 byte length per CID and a max o= f 20, which gives us a few extra bytes for cleartext server id and/or key r= otation/etc.
3) Change to a 1 byte length per CID and a max of 36= , because we want be able to put 2 encrypted routing IDs in a single CID.

2 is my preferred option, though I can live with ei= ther of 1 or 3.

Deciding sooner would be strictly = better than later, since this is blocking us(Chrome/Google) actually suppor= ting varlen CIDs.

On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <<= a href=3D"mailto:mt@lowentropy.net">mt@lowentropy.net> wrote:
That seems a little hi= gh.=C2=A0 I think that Ian's principle here is what should guide us: wh= at is the minimum you can handle?=C2=A0 What I've heard is that 18 migh= t have been workable, but it was REALLY close to the edge to the point that= you weren't confident it was enough, even in the near term..=C2=A0 But= that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave th= e
> 18B limit in v1 for now and punt out that discussion?
>
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote: > >
> >
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.c= om> wrote:
> >=C2=A0 >
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a la= rger value (which I'm still not convinced that this is really necessary= ).
> >
> >=C2=A0 This would be easy if we change the encoding of the connect= ion ID length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. W= hile we can not encode one or two byte connection IDs in long header packet= s, we can still use them in short header packets.
> >
> >=C2=A0 This split between long and short header also allows to use= much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off som= e fear that 24/32/36/48/60 byte connection IDs might not be long enough in = the future.
> >
> >=C2=A0 >
> >=C2=A0 > There are two main reasons to keep the compressed enco= ding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonabl= y expect that all / most values will be used in practice, so we won't e= xpose any bits on the wire that identify a packet as "QUIC traffic&quo= t; by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage tha= t an implementation still needs to be able to deal with connection ID lengt= hs of 255 bytes, just to be able to send Version Negotiation packets. To me= , it seems absurd to write a QUIC implementation that is able to handle pac= kets with a combined connection ID overhead of 510 bytes. Since VNPs are su= pposed to be sent in response to any Long Header packet, you'd have to = put some careful thought into the design of your data types to avoid this b= ecoming a DoS vector.
> >=C2=A0 >
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <= huitema@huitema.ne= t> wrote:
> >=C2=A0 > I too agree that using one byte in the invariant is pr= eferable to the current "compressed 4 bits" solution.
> >=C2=A0 >
> >=C2=A0 > Regarding the "CID length limit", I thing th= ere are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >
> >=C2=A0 > I am not too concerned with the transmission overhead,= as we have there the right mix of costs and incentives. Servers who chose = to use longer CID will get more transmission overhead, and thus transmissio= n less efficiently than their competitors. They may chose to use longer CID= as a trade-off between transmission efficiency and ease of management. Com= petition will sort that out. I note that YouTube is apparently doing fine w= ith smallish CID, so I trust that there will be competition.
> >=C2=A0 >
> >=C2=A0 > I am much more concerned with the shared costs, which = are a variation of the "tragedy of the commons". Dmitry explained= those costs well in a previous message. The simpler implementation is to m= ake the "cid_t a fixed-size object that can fit the largest CID and ea= t the overhead for all CIDs." But each connection object carries a lar= ge number of instances of the CID type. Having a very large max CID would i= mply a large overhead. The alternative is to "Make cid_t a variable-si= ze object", but too affects performance.
> >=C2=A0 >
> >=C2=A0 > Hence the push-back. I would personally prefer a max s= ize of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one= of {32, 36, or 48}
> >=C2=A0 >>
> >=C2=A0 >> 2) Representation of CID length as a byte is still= OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec wh= ile keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still su= pport that.
> >=C2=A0 >>
> >=C2=A0 >> -=3DR
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lu= bashev, Igor" <ilubashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org= >, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>,= Christian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>= , Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <= ;martenseemann= @gmail.com>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.c= om <mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Sp= ace #2736
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excess= ive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it= should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> We are firmly committed for using CID for in-clust= er load balancing / anycast pop routing. This discussion is taking us, howe= ver, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-contro= lled routing in an overlay network=E2=80=9D. This is a very interesting top= ic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin gener= al=E2=80=9D in QUIC v1.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>
> >=C2=A0 >> My intuition says making the change to the invaria= nts is the right thing to do, but I don't feel that strongly.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> However, I'd like the max size to be smaller t= han 48(but larger than 18). If we think 20 or 24 is sufficient, I'd pre= fer that. Kazuho suggested 32, which is better, but I don't believe the= server needs to use a separate block cipher when giving out connection IDs= , because I believe it's impractical for the load balancer and server t= o be that decoupled. The server has to give out a CID that the load balance= r will use to route back to the server, so they have to share enough an enc= ryption key/algorithm. I can imagine nesting load balancers, but that's= well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve t= his sooner rather than later and be truly done with it.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e= J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> >=C2=A0 >>
> >=C2=A0 >> Since it is more likely that you pay for egress tr= affic than ingress traffic, the motivation to keep CID=E2=80=99s small is l= imited.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I do think the invariants should allow for long CI= D=E2=80=99s as proposed, and that the long header overhead is not important= .
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rus= h to market will set precedence and long CID=E2=80=99s will ossify in all k= inds of stacks.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I good reference on an algorithm like suggested by= Christian would go a long way.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length 18 turns out to be not enough, we ca= n add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to up= grade QUIC versions soon.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length negotiation is needed, this could be= done via QUIC versions. For example two functionally equivalent versions, = but one with longer CID=E2=80=99s. This would also allow routers to deal wi= th changes in CID lengths. A negotiated TP would not (easily) allow for tha= t and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Mikkel
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) = wrote:
> >=C2=A0 >>
> >=C2=A0 >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:0= 9 Christian Huitema <huitema@huitema.net>:
> >=C2=A0 >> >
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
> >=C2=A0 >> >
> >=C2=A0 >> > > _If_ we are to allow loose coupling betw= een a load balancer and a
> >=C2=A0 >> > > server, each of the two should be given = the freedom to choose it's own
> >=C2=A0 >> > > CID encryption scheme. Because all the s= tandardized block ciphers are
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that natura= lly means that the maximum CID
> >=C2=A0 >> > > length of QUIC needs to be double amount= of that, plus one or two
> >=C2=A0 >> > > bytes for each of the two for identifyin= g the CID encryption keys. For
> >=C2=A0 >> > > key identification and other supplementa= l use, we currently allocate 2
> >=C2=A0 >> > > bytes (18-16=3D2).
> >=C2=A0 >> >
> >=C2=A0 >> > That reasoning is based on the assumption tha= t both the load balancer
> >=C2=A0 >> > and the server must use a block cipher with 1= 28 bit block length in
> >=C2=A0 >> > order to encrypt the CID. If they were constr= ained to stay within a
> >=C2=A0 >> > short global limit, they could use different = sets of algorithms.
> >=C2=A0 >> >
> >=C2=A0 >> > Assume for example that we split the CID betw= een 32 bits encoding the
> >=C2=A0 >> > number of the server in the server farm, and = 64 bit encoding the
> >=C2=A0 >> > connection number for the server. The server = can pick a random value for
> >=C2=A0 >> > the connection number, and use a hash table. = The load balancer could use
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using = the lower 64 bit of the CID
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with dem= onstrably strong encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > Or assume that the server wants to use short = CID. We now split the CID
> >=C2=A0 >> > between 32 bit for the server number in the f= arm, and 32 bit for the
> >=C2=A0 >> > connection number in the server. The server b= uilds that connection
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The = load balancer also uses a
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the= CID as initial vector for
> >=C2=A0 >> > this FFX encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > These are just two examples. And yes you may = want to add 2 bytes for key
> >=C2=A0 >> > identification, etc. In both encryption algor= ithms, you can feed these
> >=C2=A0 >> > two bytes as additional IV for the FFX algori= thm. And in both cases, we
> >=C2=A0 >> > are well below the 18 byte limit.
> >=C2=A0 >> >
> >=C2=A0 >> > Yes, that requires some creative engineering.= But it is not rocker
> >=C2=A0 >> > science. And it seems better than carrying to= ns of overhead in the
> >=C2=A0 >> > header, and becoming less efficient than HTTP= 2/TLS/TCP.
> >=C2=A0 >>
> >=C2=A0 >> I agree that it would not be the end of the world = for the load
> >=C2=A0 >> balancers if we decide to stick on the 18-byte lim= it. However, as you
> >=C2=A0 >> state, it requires some creativeness.
> >=C2=A0 >>
> >=C2=A0 >> To me it seems that the question is if we have a s= trong reason to
> >=C2=A0 >> require some people to be creative, for all the ve= rsions of QUIC in
> >=C2=A0 >> the future. I personally think that there isn'= t a strong reason,
> >=C2=A0 >> because people can use shorter CIDs regardless of = the decision we
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to ac= cept is:
> >=C2=A0 >>
> >=C2=A0 >> * one byte increase in the long header packets > >=C2=A0 >> * the minimum size of short header packets becomin= g slightly greater
> >=C2=A0 >> (otherwise, the peer might not be able to send a s= tateless reset)
> >=C2=A0 >>
> >=C2=A0 >> I'd say that the first bullet point is negligi= ble. The second point
> >=C2=A0 >> could also be, because I'd assume that the onl= y frequently-sent
> >=C2=A0 >> packets that require additional padding is the ACK= -only packets, but
> >=C2=A0 >> there's no reason to pad ACK-only packets in h= ope that you'd see a
> >=C2=A0 >> stateless reset.
> >=C2=A0 >>
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been = to provide extra
> >=C2=A0 >> room, so that some people with necessity can use l= onger CIDs.
> >=C2=A0 >>
> >=C2=A0 >> >
> >=C2=A0 >> > -- Christian Huitema
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> --
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>
> >
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >
> >=C2=A0 --
> >=C2=A0 Philipp S. Tiesel
> > https://philipp.tiesel.net/
> >

--000000000000c6233a058bdae973-- From nobody Fri Jun 21 13:02:33 2019 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 637091200F9 for ; Fri, 21 Jun 2019 13:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Kw8HtPQvOL for ; Fri, 21 Jun 2019 13:02:28 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D070120144 for ; Fri, 21 Jun 2019 13:02:27 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id d11so5909583lfb.4 for ; Fri, 21 Jun 2019 13:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iwt5W0M3OBWEGWoenPE2R4eOyZkDiWhFObzWMobFIII=; b=D6NwrVfkCys0iBwNBV6lBgzZEJEFe3E8bnN0sIbtT3Df4J5BXZnoeJHURsHFlIrQhV 9/tAOd9Iukg1nL8KN/qIy6clmfcipjNgCSP6BLVKF+GGjd6zbh4Pot0jRA+H9/nUyF5n kdG1HInwCRdiPV/J69AyroeMAj7Avqv8YpZkLvEhSo1wgzcWxzvKRaTwlxTi92eA0lcc p60+htYtki50qPeWKy5MZfuWrasqCDFBXOnnhtpTYtZh7/zIvSiMgtE2jcetlBz4Hoqa /vULBExD2n3bhqIX7xTqRG5tZeUKWWlx5nmonv3vj2RX8uvIF0oUwntuI6ttvNZ9Itff ZXFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iwt5W0M3OBWEGWoenPE2R4eOyZkDiWhFObzWMobFIII=; b=NeKyQNBGaJgqoocC6XlO4nZZqlwTwV+UH2SYmm6dMuUuI4fmrvBb2+1yA/vq17diAj M4yTDDDz90KLdvpTjnYc8PmMZ/R7/GXGSeFqHb4Wd9UOICkPTDW5dmcL9lG5+LpL9stH 3pwZljKYL0vanpr5gA7Ap/FGtzBdCbDB8JO7mIq8XCfuEuK0bc3ijcmZa+9ohFX4pLxJ xboytqJJpKPPmsJ19nrul9YCNci7D5vZzEVGydFYHFjMGljRd0zRhavrWWqcWiYN6yK8 Qnytbo46UlWkwKighhwxknHeDYVb89TPk9095oLyR/3zLMU7LrMcBAVEVwSTxbl+MP6w r48A== X-Gm-Message-State: APjAAAUtmkBU0Mlns7KFvf0VgvEWsz5ewPvDKGno2ku4t5GEuBcgbzKd nSgRhePve2d5LvfMjL7CV5csVrYULlrdlNpO433KyA== X-Google-Smtp-Source: APXvYqwaRHXZAruIrFOcmMH0E5ZoCDi98cpl6e7iIVFSz+pd5D9qJaSfPNaGH+pE38Q79NWk7aeHpO/MfzNjx57uV10= X-Received: by 2002:ac2:514b:: with SMTP id q11mr10872243lfd.33.1561147345692; Fri, 21 Jun 2019 13:02:25 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> In-Reply-To: From: David Schinazi Date: Fri, 21 Jun 2019 13:02:14 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Ian Swett Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000fb6cd9058bdaf0d8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 20:02:32 -0000 --000000000000fb6cd9058bdaf0d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to what Ian said. (2) seems like a good path forward On Fri, Jun 21, 2019 at 1:00 PM Ian Swett wrote: > I think the 3 options I see as well reasoned are: > 1) Keep the status quo because we think we can put what we really need > into 18 bytes if we try. > 2) Change to a 1 byte length per CID and a max of 20, which gives us a fe= w > extra bytes for cleartext server id and/or key rotation/etc. > 3) Change to a 1 byte length per CID and a max of 36, because we want be > able to put 2 encrypted routing IDs in a single CID. > > 2 is my preferred option, though I can live with either of 1 or 3. > > Deciding sooner would be strictly better than later, since this is > blocking us(Chrome/Google) actually supporting varlen CIDs. > > On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote: > >> That seems a little high. I think that Ian's principle here is what >> should guide us: what is the minimum you can handle? What I've heard is >> that 18 might have been workable, but it was REALLY close to the edge to >> the point that you weren't confident it was enough, even in the near >> term.. But that suggests that 20 is workable. >> >> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >> > so do I hear consensus emerging around 32B in v1, or should I leave th= e >> > 18B limit in v1 for now and punt out that discussion? >> > >> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel >> wrote: >> > > >> > > >> > > > On 18. Jun 2019, at 05:33, Marten Seemann >> wrote: >> > > > >> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we >> decide to increase the connection ID length to a larger value (which I'm >> still not convinced that this is really necessary). >> > > >> > > This would be easy if we change the encoding of the connection ID >> length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While= we >> can not encode one or two byte connection IDs in long header packets, we >> can still use them in short header packets. >> > > >> > > This split between long and short header also allows to use much >> longer connection IDs after the handshake. >> > > I don=E2=80=99t see much use in it, but it may take off some fear t= hat >> 24/32/36/48/60 byte connection IDs might not be long enough in the futur= e. >> > > >> > > > >> > > > There are two main reasons to keep the compressed encoding: >> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect th= at all / >> most values will be used in practice, so we won't expose any bits on the >> wire that identify a packet as "QUIC traffic" by having a predictable va= lue. >> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an implem= entation >> still needs to be able to deal with connection ID lengths of 255 bytes, >> just to be able to send Version Negotiation packets. To me, it seems abs= urd >> to write a QUIC implementation that is able to handle packets with a >> combined connection ID overhead of 510 bytes. Since VNPs are supposed to= be >> sent in response to any Long Header packet, you'd have to put some caref= ul >> thought into the design of your data types to avoid this becoming a DoS >> vector. >> > > > >> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < >> huitema@huitema.net> wrote: >> > > > I too agree that using one byte in the invariant is preferable to >> the current "compressed 4 bits" solution. >> > > > >> > > > Regarding the "CID length limit", I thing there are two issues: >> transmission overhead, and costs to the community. >> > > > >> > > > I am not too concerned with the transmission overhead, as we have >> there the right mix of costs and incentives. Servers who chose to use >> longer CID will get more transmission overhead, and thus transmission le= ss >> efficiently than their competitors. They may chose to use longer CID as = a >> trade-off between transmission efficiency and ease of management. >> Competition will sort that out. I note that YouTube is apparently doing >> fine with smallish CID, so I trust that there will be competition. >> > > > >> > > > I am much more concerned with the shared costs, which are a >> variation of the "tragedy of the commons". Dmitry explained those costs >> well in a previous message. The simpler implementation is to make the >> "cid_t a fixed-size object that can fit the largest CID and eat the >> overhead for all CIDs." But each connection object carries a large numbe= r >> of instances of the CID type. Having a very large max CID would imply a >> large overhead. The alternative is to "Make cid_t a variable-size object= ", >> but too affects performance. >> > > > >> > > > Hence the push-back. I would personally prefer a max size of 16, >> and I think that 32 is the highest practical limit. >> > > > >> > > > -- Christian Huitema >> > > > >> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >> > > >> What I think people are saying so far: >> > > >> >> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, o= r >> 48} >> > > >> >> > > >> 2) Representation of CID length as a byte is still OK, thus a >> QUIC v2 could use longer CIDs as needed by changing the spec while keepi= ng >> the invariants=E2=80=A6 invariant. >> > > >> >> > > >> >> > > >> That seems reasonable to me / I=E2=80=99d still support that. >> > > >> >> > > >> -=3DR >> > > >> >> > > >> >> > > >> From: QUIC > on >> behalf of "Lubashev, Igor" >> > > >> Date: Monday, June 17, 2019 at 8:55 AM >> > > >> To: Ian Swett , Mikkel >> Fahn=C3=B8e J=C3=B8rgensen >> > > >> Cc: Dmitri Tikhonov , Christian >> Huitema , "Philipp S. Tiesel" , >> Mike Bishop , Martin Thomson , >> Marten Seemann , Lars Eggert , >> QUIC WG , Martin Duke > martin..h.duke@gmail.com>>, Kazuho Oku >> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >> > > >> >> > > >> >> > > >> >> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 = is likely >> the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a= factor of 8, so 32 >> or 24?). >> > > >> >> > > >> >> > > >> >> > > >> We are firmly committed for using CID for in-cluster load >> balancing / anycast pop routing. This discussion is taking us, however, = to >> a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled = routing in an >> overlay network=E2=80=9D. This is a very interesting topic, but I would = hesitate to >> attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. >> > > >> >> > > >> >> > > >> >> > > >> =E2=80=A2 Igor >> > > >> >> > > >> >> > > >> From: Ian Swett >> > > >> >> > > >> My intuition says making the change to the invariants is the >> right thing to do, but I don't feel that strongly. >> > > >> >> > > >> >> > > >> >> > > >> However, I'd like the max size to be smaller than 48(but larger >> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho >> suggested 32, which is better, but I don't believe the server needs to u= se >> a separate block cipher when giving out connection IDs, because I believ= e >> it's impractical for the load balancer and server to be that decoupled. = The >> server has to give out a CID that the load balancer will use to route ba= ck >> to the server, so they have to share enough an encryption key/algorithm.= I >> can imagine nesting load balancers, but that's well in the range of QUIC= v2 >> from my perspective. >> > > >> >> > > >> >> > > >> >> > > >> Whatever we do, I'd really prefer to resolve this sooner rather >> than later and be truly done with it. >> > > >> >> > > >> >> > > >> >> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgense= n < >> mikkelfj@gmail.com> wrote: >> > > >> >> > > >> Since it is more likely that you pay for egress traffic than >> ingress traffic, the motivation to keep CID=E2=80=99s small is limited. >> > > >> >> > > >> >> > > >> >> > > >> I do think the invariants should allow for long CID=E2=80=99s as >> proposed, and that the long header overhead is not important.. >> > > >> >> > > >> >> > > >> >> > > >> But for QUIC v1, if we allow for a long CID, a rush to market >> will set precedence and long CID=E2=80=99s will ossify in all kinds of s= tacks. >> > > >> >> > > >> >> > > >> >> > > >> I good reference on an algorithm like suggested by Christian >> would go a long way. >> > > >> >> > > >> >> > > >> >> > > >> If CID length 18 turns out to be not enough, we can add a QUIC >> v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC= versions >> soon. >> > > >> >> > > >> >> > > >> >> > > >> If CID length negotiation is needed, this could be done via QUIC >> versions. For example two functionally equivalent versions, but one with >> longer CID=E2=80=99s. This would also allow routers to deal with changes= in CID >> lengths. A negotiated TP would not (easily) allow for that and aside I d= o >> not think CID length in TP is the way to go. >> > > >> >> > > >> >> > > >> >> > > >> Mikkel >> > > >> >> > > >> >> > > >> >> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) >> wrote: >> > > >> >> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hu= itema : >> > > >> > >> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >> > > >> > >> > > >> > > _If_ we are to allow loose coupling between a load balancer >> and a >> > > >> > > server, each of the two should be given the freedom to choos= e >> it's own >> > > >> > > CID encryption scheme. Because all the standardized block >> ciphers are >> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the >> maximum CID >> > > >> > > length of QUIC needs to be double amount of that, plus one o= r >> two >> > > >> > > bytes for each of the two for identifying the CID encryption >> keys. For >> > > >> > > key identification and other supplemental use, we currently >> allocate 2 >> > > >> > > bytes (18-16=3D2). >> > > >> > >> > > >> > That reasoning is based on the assumption that both the load >> balancer >> > > >> > and the server must use a block cipher with 128 bit block >> length in >> > > >> > order to encrypt the CID. If they were constrained to stay >> within a >> > > >> > short global limit, they could use different sets of >> algorithms. >> > > >> > >> > > >> > Assume for example that we split the CID between 32 bits >> encoding the >> > > >> > number of the server in the server farm, and 64 bit encoding >> the >> > > >> > connection number for the server. The server can pick a random >> value for >> > > >> > the connection number, and use a hash table. The load balancer >> could use >> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit >> of the CID >> > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong >> encryption. >> > > >> > >> > > >> > Or assume that the server wants to use short CID. We now split >> the CID >> > > >> > between 32 bit for the server number in the farm, and 32 bit >> for the >> > > >> > connection number in the server. The server builds that >> connection >> > > >> > number by using a 32 bit variant of FFX. The load balancer als= o >> uses a >> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial >> vector for >> > > >> > this FFX encryption. >> > > >> > >> > > >> > These are just two examples. And yes you may want to add 2 >> bytes for key >> > > >> > identification, etc. In both encryption algorithms, you can >> feed these >> > > >> > two bytes as additional IV for the FFX algorithm. And in both >> cases, we >> > > >> > are well below the 18 byte limit. >> > > >> > >> > > >> > Yes, that requires some creative engineering. But it is not >> rocker >> > > >> > science. And it seems better than carrying tons of overhead in >> the >> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. >> > > >> >> > > >> I agree that it would not be the end of the world for the load >> > > >> balancers if we decide to stick on the 18-byte limit. However, a= s >> you >> > > >> state, it requires some creativeness. >> > > >> >> > > >> To me it seems that the question is if we have a strong reason t= o >> > > >> require some people to be creative, for all the versions of QUIC >> in >> > > >> the future. I personally think that there isn't a strong reason, >> > > >> because people can use shorter CIDs regardless of the decision w= e >> > > >> make. IIUC, the overhead that everyone needs to accept is: >> > > >> >> > > >> * one byte increase in the long header packets >> > > >> * the minimum size of short header packets becoming slightly >> greater >> > > >> (otherwise, the peer might not be able to send a stateless reset= ) >> > > >> >> > > >> I'd say that the first bullet point is negligible. The second >> point >> > > >> could also be, because I'd assume that the only frequently-sent >> > > >> packets that require additional padding is the ACK-only packets, >> but >> > > >> there's no reason to pad ACK-only packets in hope that you'd see >> a >> > > >> stateless reset. >> > > >> >> > > >> Therefore, my (not-so-strong) preference has been to provide >> extra >> > > >> room, so that some people with necessity can use longer CIDs. >> > > >> >> > > >> > >> > > >> > -- Christian Huitema >> > > >> > >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> Kazuho Oku >> > > >> >> > > >> > > AVE! >> > > Philipp S. Tiesel >> > > >> > > -- >> > > Philipp S. Tiesel >> > > https://philipp.tiesel.net/ >> > > >> >> --000000000000fb6cd9058bdaf0d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to what Ian said. (2) seems like a good path forward

On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:
I= think the 3 options I see as well reasoned are:
1) Keep the status quo= because we think we can put what we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives = us a few extra bytes for cleartext server id and/or key rotation/etc.
=
3) Change to a 1 byte length per CID and a max of 36, because we want = be able to put 2 encrypted routing IDs in a single CID.

2 is my preferred option, though I can live with either of 1 or 3.

Deciding sooner would be strictly better than later,= since this is blocking us(Chrome/Google) actually supporting varlen CIDs.<= /div>

On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:
That seems a little hi= gh.=C2=A0 I think that Ian's principle here is what should guide us: wh= at is the minimum you can handle?=C2=A0 What I've heard is that 18 migh= t have been workable, but it was REALLY close to the edge to the point that= you weren't confident it was enough, even in the near term..=C2=A0 But= that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave th= e
> 18B limit in v1 for now and punt out that discussion?
>
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote: > >
> >
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.c= om> wrote:
> >=C2=A0 >
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a la= rger value (which I'm still not convinced that this is really necessary= ).
> >
> >=C2=A0 This would be easy if we change the encoding of the connect= ion ID length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. W= hile we can not encode one or two byte connection IDs in long header packet= s, we can still use them in short header packets.
> >
> >=C2=A0 This split between long and short header also allows to use= much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off som= e fear that 24/32/36/48/60 byte connection IDs might not be long enough in = the future.
> >
> >=C2=A0 >
> >=C2=A0 > There are two main reasons to keep the compressed enco= ding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonabl= y expect that all / most values will be used in practice, so we won't e= xpose any bits on the wire that identify a packet as "QUIC traffic&quo= t; by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage tha= t an implementation still needs to be able to deal with connection ID lengt= hs of 255 bytes, just to be able to send Version Negotiation packets. To me= , it seems absurd to write a QUIC implementation that is able to handle pac= kets with a combined connection ID overhead of 510 bytes. Since VNPs are su= pposed to be sent in response to any Long Header packet, you'd have to = put some careful thought into the design of your data types to avoid this b= ecoming a DoS vector.
> >=C2=A0 >
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <= huitema@huitema.ne= t> wrote:
> >=C2=A0 > I too agree that using one byte in the invariant is pr= eferable to the current "compressed 4 bits" solution.
> >=C2=A0 >
> >=C2=A0 > Regarding the "CID length limit", I thing th= ere are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >
> >=C2=A0 > I am not too concerned with the transmission overhead,= as we have there the right mix of costs and incentives. Servers who chose = to use longer CID will get more transmission overhead, and thus transmissio= n less efficiently than their competitors. They may chose to use longer CID= as a trade-off between transmission efficiency and ease of management. Com= petition will sort that out. I note that YouTube is apparently doing fine w= ith smallish CID, so I trust that there will be competition.
> >=C2=A0 >
> >=C2=A0 > I am much more concerned with the shared costs, which = are a variation of the "tragedy of the commons". Dmitry explained= those costs well in a previous message. The simpler implementation is to m= ake the "cid_t a fixed-size object that can fit the largest CID and ea= t the overhead for all CIDs." But each connection object carries a lar= ge number of instances of the CID type. Having a very large max CID would i= mply a large overhead. The alternative is to "Make cid_t a variable-si= ze object", but too affects performance.
> >=C2=A0 >
> >=C2=A0 > Hence the push-back. I would personally prefer a max s= ize of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one= of {32, 36, or 48}
> >=C2=A0 >>
> >=C2=A0 >> 2) Representation of CID length as a byte is still= OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec wh= ile keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still su= pport that.
> >=C2=A0 >>
> >=C2=A0 >> -=3DR
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "L= ubashev, Igor" <ilubashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org= >, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>,= Christian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>= , Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <= ;martenseemann= @gmail.com>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.c= om <mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Sp= ace #2736
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excess= ive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it= should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> We are firmly committed for using CID for in-clust= er load balancing / anycast pop routing. This discussion is taking us, howe= ver, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-contro= lled routing in an overlay network=E2=80=9D. This is a very interesting top= ic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin gener= al=E2=80=9D in QUIC v1.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>
> >=C2=A0 >> My intuition says making the change to the invaria= nts is the right thing to do, but I don't feel that strongly.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> However, I'd like the max size to be smaller t= han 48(but larger than 18). If we think 20 or 24 is sufficient, I'd pre= fer that. Kazuho suggested 32, which is better, but I don't believe the= server needs to use a separate block cipher when giving out connection IDs= , because I believe it's impractical for the load balancer and server t= o be that decoupled. The server has to give out a CID that the load balance= r will use to route back to the server, so they have to share enough an enc= ryption key/algorithm. I can imagine nesting load balancers, but that's= well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve t= his sooner rather than later and be truly done with it.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e= J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> >=C2=A0 >>
> >=C2=A0 >> Since it is more likely that you pay for egress tr= affic than ingress traffic, the motivation to keep CID=E2=80=99s small is l= imited.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I do think the invariants should allow for long CI= D=E2=80=99s as proposed, and that the long header overhead is not important= ..
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rus= h to market will set precedence and long CID=E2=80=99s will ossify in all k= inds of stacks.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I good reference on an algorithm like suggested by= Christian would go a long way.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length 18 turns out to be not enough, we ca= n add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to up= grade QUIC versions soon.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length negotiation is needed, this could be= done via QUIC versions. For example two functionally equivalent versions, = but one with longer CID=E2=80=99s. This would also allow routers to deal wi= th changes in CID lengths. A negotiated TP would not (easily) allow for tha= t and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Mikkel
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) = wrote:
> >=C2=A0 >>
> >=C2=A0 >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:0= 9 Christian Huitema <huitema@huitema.net>:
> >=C2=A0 >> >
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
> >=C2=A0 >> >
> >=C2=A0 >> > > _If_ we are to allow loose coupling betw= een a load balancer and a
> >=C2=A0 >> > > server, each of the two should be given = the freedom to choose it's own
> >=C2=A0 >> > > CID encryption scheme. Because all the s= tandardized block ciphers are
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that natura= lly means that the maximum CID
> >=C2=A0 >> > > length of QUIC needs to be double amount= of that, plus one or two
> >=C2=A0 >> > > bytes for each of the two for identifyin= g the CID encryption keys. For
> >=C2=A0 >> > > key identification and other supplementa= l use, we currently allocate 2
> >=C2=A0 >> > > bytes (18-16=3D2).
> >=C2=A0 >> >
> >=C2=A0 >> > That reasoning is based on the assumption tha= t both the load balancer
> >=C2=A0 >> > and the server must use a block cipher with 1= 28 bit block length in
> >=C2=A0 >> > order to encrypt the CID. If they were constr= ained to stay within a
> >=C2=A0 >> > short global limit, they could use different = sets of algorithms.
> >=C2=A0 >> >
> >=C2=A0 >> > Assume for example that we split the CID betw= een 32 bits encoding the
> >=C2=A0 >> > number of the server in the server farm, and = 64 bit encoding the
> >=C2=A0 >> > connection number for the server. The server = can pick a random value for
> >=C2=A0 >> > the connection number, and use a hash table. = The load balancer could use
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using = the lower 64 bit of the CID
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with dem= onstrably strong encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > Or assume that the server wants to use short = CID. We now split the CID
> >=C2=A0 >> > between 32 bit for the server number in the f= arm, and 32 bit for the
> >=C2=A0 >> > connection number in the server. The server b= uilds that connection
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The = load balancer also uses a
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the= CID as initial vector for
> >=C2=A0 >> > this FFX encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > These are just two examples. And yes you may = want to add 2 bytes for key
> >=C2=A0 >> > identification, etc. In both encryption algor= ithms, you can feed these
> >=C2=A0 >> > two bytes as additional IV for the FFX algori= thm. And in both cases, we
> >=C2=A0 >> > are well below the 18 byte limit.
> >=C2=A0 >> >
> >=C2=A0 >> > Yes, that requires some creative engineering.= But it is not rocker
> >=C2=A0 >> > science. And it seems better than carrying to= ns of overhead in the
> >=C2=A0 >> > header, and becoming less efficient than HTTP= 2/TLS/TCP.
> >=C2=A0 >>
> >=C2=A0 >> I agree that it would not be the end of the world = for the load
> >=C2=A0 >> balancers if we decide to stick on the 18-byte lim= it. However, as you
> >=C2=A0 >> state, it requires some creativeness.
> >=C2=A0 >>
> >=C2=A0 >> To me it seems that the question is if we have a s= trong reason to
> >=C2=A0 >> require some people to be creative, for all the ve= rsions of QUIC in
> >=C2=A0 >> the future. I personally think that there isn'= t a strong reason,
> >=C2=A0 >> because people can use shorter CIDs regardless of = the decision we
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to ac= cept is:
> >=C2=A0 >>
> >=C2=A0 >> * one byte increase in the long header packets > >=C2=A0 >> * the minimum size of short header packets becomin= g slightly greater
> >=C2=A0 >> (otherwise, the peer might not be able to send a s= tateless reset)
> >=C2=A0 >>
> >=C2=A0 >> I'd say that the first bullet point is negligi= ble. The second point
> >=C2=A0 >> could also be, because I'd assume that the onl= y frequently-sent
> >=C2=A0 >> packets that require additional padding is the ACK= -only packets, but
> >=C2=A0 >> there's no reason to pad ACK-only packets in h= ope that you'd see a
> >=C2=A0 >> stateless reset.
> >=C2=A0 >>
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been = to provide extra
> >=C2=A0 >> room, so that some people with necessity can use l= onger CIDs.
> >=C2=A0 >>
> >=C2=A0 >> >
> >=C2=A0 >> > -- Christian Huitema
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> --
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>
> >
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >
> >=C2=A0 --
> >=C2=A0 Philipp S. Tiesel
> > https://philipp.tiesel.net/
> >

--000000000000fb6cd9058bdaf0d8-- From nobody Fri Jun 21 13:21:37 2019 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 9F4DF12039A for ; Fri, 21 Jun 2019 13:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=DX8uO0Lc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Orta7nUP 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 gLzSlBdCSemx for ; Fri, 21 Jun 2019 13:21:31 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AC91203AF for ; Fri, 21 Jun 2019 13:21:31 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5LKJqbs009008; Fri, 21 Jun 2019 13:21:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=TnjgldCRyCoO+R6Bo8BJNjlujIvZcxSsX9rBmLJpH2E=; b=DX8uO0LcEpmAXOESDy7f6lMU8jZcweFfozs7+IJ+ea6ruSiDDS3+GzEFtF9oOIg3JBnu wx3JFnEa/r1d2U8fByt6XVGs44B9CXpOIHvM2EKLDbkCrmEfJUycRndovbk7DrazYYcG 8KqcXV5+ATca5ITqyABFlUzp2sOpNsllr2w= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2t8tptjgdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 21 Jun 2019 13:21:27 -0700 Received: from ash-exhub101.TheFacebook.com (2620:10d:c0a8:82::e) by ash-exhub204.TheFacebook.com (2620:10d:c0a8:83::4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 21 Jun 2019 13:21:26 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 21 Jun 2019 13:21:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TnjgldCRyCoO+R6Bo8BJNjlujIvZcxSsX9rBmLJpH2E=; b=Orta7nUPT5VlJQpEuZVzadU6aGgUkWpVrFp1dMZ+OyJ8g6B/aMJI+WWUhaswzqsgcA48Nlkp1zWeWxFuIQZ47XH70dD0D7TzznBzFWmWNYI8RYE6754cGxn5VNMc6OCSj7+9E6hOO/0ks8jQKkSzdy8zts3vT+K66/zagAM4L+E= Received: from CY4PR15MB1542.namprd15.prod.outlook.com (10.172.160.9) by CY4PR15MB1704.namprd15.prod.outlook.com (10.174.53.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Fri, 21 Jun 2019 20:21:24 +0000 Received: from CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a]) by CY4PR15MB1542.namprd15.prod.outlook.com ([fe80::e0d4:26ff:76c:391a%9]) with mapi id 15.20.1987.014; Fri, 21 Jun 2019 20:21:24 +0000 From: Roberto Peon To: David Schinazi , Ian Swett CC: IETF QUIC WG , Martin Thomson Subject: Re: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORjFtUmRAvDTkuJte7HuW7cSKaXjl6AgAGE3YCAAA8NgIAABlqAgAC3vwCAAPW4AIAAccKAgAF/iYCAAHVjgIAAkboAgAFTDwCAACtYAIAAI0iAgACS+YCAAATjAP//kOOAgACw5wCAAIGGgIAAUSyAgALnAQCAAO6YgIABo/QAgAAAkgD//5ABgA== Date: Fri, 21 Jun 2019 20:21:24 +0000 Message-ID: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 x-originating-ip: [2620:10d:c090:200::2:561b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e5bd853-38c7-4e50-3d4d-08d6f686087c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR15MB1704; x-ms-traffictypediagnostic: CY4PR15MB1704: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0075CB064E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(136003)(366004)(199004)(189003)(51444003)(6512007)(73956011)(110136005)(58126008)(11346002)(91956017)(86362001)(236005)(6436002)(6246003)(66946007)(76116006)(6486002)(2906002)(476003)(81156014)(68736007)(4326008)(446003)(14454004)(76176011)(66574012)(229853002)(5660300002)(71190400001)(53936002)(53546011)(2616005)(6506007)(46003)(186003)(486006)(6306002)(6116002)(81166006)(256004)(478600001)(316002)(66476007)(66446008)(66556008)(8936002)(54896002)(71200400001)(966005)(36756003)(14444005)(606006)(99286004)(64756008)(30864003)(8676002)(102836004)(54906003)(7736002)(25786009)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1704; H:CY4PR15MB1542.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aPi9Fdys8kNvZsrYLFeIcA1Og6v33NQ8vTvsxj8cDNc4CmrpbicpTZJGGlZtzoSky7aGf/+PlbLx47mNp+8DZ4lvHsr7OFqD3HiaL3FBztqyeMFFitvofv01MJlL7uwRHtlthfqzgctGPhb71QJ4R28rWWqYKmio2VziH0lhUHLBwi667za6rKsH6dLuaedtGQTqk/x0EUvTdJqlzaO4g6R+mDZUYbvuD12q80t1p8Bt+/PCQvDBQrsb2kuOdqvNN4P1j87qMzoVEHh2ZegiEC9iGyknPLYeKUWwqDWROpZOpRfNFaaaGGym6se3uR+p3oVTQMc12K03omMDP3Ig1ffHlTLUK6Gav5Agee487NMN7bur1kst3TQkhrGHXgZP43n1jnIjnfElAMqMXDrfLDK2eCigc/Zj1B2QwtsvRHU= Content-Type: multipart/alternative; boundary="_000_F127DB352E274709A231558C0E151AE3fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0e5bd853-38c7-4e50-3d4d-08d6f686087c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2019 20:21:24.6092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fenix@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1704 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-21_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906210153 X-FB-Internal: deliver Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 20:21:36 -0000 --_000_F127DB352E274709A231558C0E151AE3fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLg0KLT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+DQpE YXRlOiBGcmlkYXksIEp1bmUgMjEsIDIwMTkgYXQgMTowMiBQTQ0KVG86IElhbiBTd2V0dCA8aWFu c3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZz4sIE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4NClN1YmplY3Q6 IFJlOiBDb25zZW5zdXMgQ2FsbDogTW9yZSBDb25uZWN0aW9uIElEIFNwYWNlICMyNzM2DQoNCisx IHRvIHdoYXQgSWFuIHNhaWQuICgyKSBzZWVtcyBsaWtlIGEgZ29vZCBwYXRoIGZvcndhcmQNCg0K T24gRnJpLCBKdW4gMjEsIDIwMTkgYXQgMTowMCBQTSBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29v Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn Pj4gd3JvdGU6DQpJIHRoaW5rIHRoZSAzIG9wdGlvbnMgSSBzZWUgYXMgd2VsbCByZWFzb25lZCBh cmU6DQoxKSBLZWVwIHRoZSBzdGF0dXMgcXVvIGJlY2F1c2Ugd2UgdGhpbmsgd2UgY2FuIHB1dCB3 aGF0IHdlIHJlYWxseSBuZWVkIGludG8gMTggYnl0ZXMgaWYgd2UgdHJ5Lg0KMikgQ2hhbmdlIHRv IGEgMSBieXRlIGxlbmd0aCBwZXIgQ0lEIGFuZCBhIG1heCBvZiAyMCwgd2hpY2ggZ2l2ZXMgdXMg YSBmZXcgZXh0cmEgYnl0ZXMgZm9yIGNsZWFydGV4dCBzZXJ2ZXIgaWQgYW5kL29yIGtleSByb3Rh dGlvbi9ldGMuDQozKSBDaGFuZ2UgdG8gYSAxIGJ5dGUgbGVuZ3RoIHBlciBDSUQgYW5kIGEgbWF4 IG9mIDM2LCBiZWNhdXNlIHdlIHdhbnQgYmUgYWJsZSB0byBwdXQgMiBlbmNyeXB0ZWQgcm91dGlu ZyBJRHMgaW4gYSBzaW5nbGUgQ0lELg0KDQoyIGlzIG15IHByZWZlcnJlZCBvcHRpb24sIHRob3Vn aCBJIGNhbiBsaXZlIHdpdGggZWl0aGVyIG9mIDEgb3IgMy4NCg0KRGVjaWRpbmcgc29vbmVyIHdv dWxkIGJlIHN0cmljdGx5IGJldHRlciB0aGFuIGxhdGVyLCBzaW5jZSB0aGlzIGlzIGJsb2NraW5n IHVzKENocm9tZS9Hb29nbGUpIGFjdHVhbGx5IHN1cHBvcnRpbmcgdmFybGVuIENJRHMuDQoNCk9u IFRodSwgSnVuIDIwLCAyMDE5IGF0IDI6NTcgUE0gTWFydGluIFRob21zb24gPG10QGxvd2VudHJv cHkubmV0PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KVGhhdCBzZWVtcyBhIGxp dHRsZSBoaWdoLiAgSSB0aGluayB0aGF0IElhbidzIHByaW5jaXBsZSBoZXJlIGlzIHdoYXQgc2hv dWxkIGd1aWRlIHVzOiB3aGF0IGlzIHRoZSBtaW5pbXVtIHlvdSBjYW4gaGFuZGxlPyAgV2hhdCBJ J3ZlIGhlYXJkIGlzIHRoYXQgMTggbWlnaHQgaGF2ZSBiZWVuIHdvcmthYmxlLCBidXQgaXQgd2Fz IFJFQUxMWSBjbG9zZSB0byB0aGUgZWRnZSB0byB0aGUgcG9pbnQgdGhhdCB5b3Ugd2VyZW4ndCBj b25maWRlbnQgaXQgd2FzIGVub3VnaCwgZXZlbiBpbiB0aGUgbmVhciB0ZXJtLi4gIEJ1dCB0aGF0 IHN1Z2dlc3RzIHRoYXQgMjAgaXMgd29ya2FibGUuDQoNCk9uIFdlZCwgSnVuIDE5LCAyMDE5LCBh dCAyMTo0MywgTWFydGluIER1a2Ugd3JvdGU6DQo+IHNvIGRvIEkgaGVhciBjb25zZW5zdXMgZW1l cmdpbmcgYXJvdW5kIDMyQiBpbiB2MSwgb3Igc2hvdWxkIEkgbGVhdmUgdGhlDQo+IDE4QiBsaW1p dCBpbiB2MSBmb3Igbm93IGFuZCBwdW50IG91dCB0aGF0IGRpc2N1c3Npb24/DQo+DQo+IE9uIFR1 ZSwgSnVuIDE4LCAyMDE5IGF0IDE6MjQgQU0gUGhpbGlwcCBTLiBUaWVzZWwgPHBoaWxpcHBAdGll c2VsLm5ldDxtYWlsdG86cGhpbGlwcEB0aWVzZWwubmV0Pj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+ ICA+IE9uIDE4LiBKdW4gMjAxOSwgYXQgMDU6MzMsIE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVt YW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+PiB3cm90ZToNCj4g PiAgPg0KPiA+ICA+IEknZCBwcmVmZXIga2VlcGluZyB0aGUgImNvbXByZXNzZWQgNCBiaXRzIiBz b2x1dGlvbiwgZXZlbiBpZiB3ZSBkZWNpZGUgdG8gaW5jcmVhc2UgdGhlIGNvbm5lY3Rpb24gSUQg bGVuZ3RoIHRvIGEgbGFyZ2VyIHZhbHVlICh3aGljaCBJJ20gc3RpbGwgbm90IGNvbnZpbmNlZCB0 aGF0IHRoaXMgaXMgcmVhbGx5IG5lY2Vzc2FyeSkuDQo+ID4NCj4gPiAgVGhpcyB3b3VsZCBiZSBl YXN5IGlmIHdlIGNoYW5nZSB0aGUgZW5jb2Rpbmcgb2YgdGhlIGNvbm5lY3Rpb24gSUQgbGVuZ3Ro LCBlLi5nLiwgdG8gYmUgRENJTCo0IGFsbG93aW5nIHVwIHRvIDYwIGJ5dGUgY29ubmVjdGlvbiBJ RHMuIFdoaWxlIHdlIGNhbiBub3QgZW5jb2RlIG9uZSBvciB0d28gYnl0ZSBjb25uZWN0aW9uIElE cyBpbiBsb25nIGhlYWRlciBwYWNrZXRzLCB3ZSBjYW4gc3RpbGwgdXNlIHRoZW0gaW4gc2hvcnQg aGVhZGVyIHBhY2tldHMuDQo+ID4NCj4gPiAgVGhpcyBzcGxpdCBiZXR3ZWVuIGxvbmcgYW5kIHNo b3J0IGhlYWRlciBhbHNvIGFsbG93cyB0byB1c2UgbXVjaCBsb25nZXIgY29ubmVjdGlvbiBJRHMg YWZ0ZXIgdGhlIGhhbmRzaGFrZS4NCj4gPiAgSSBkb27igJl0IHNlZSBtdWNoIHVzZSBpbiBpdCwg YnV0IGl0IG1heSB0YWtlIG9mZiBzb21lIGZlYXIgdGhhdCAyNC8zMi8zNi80OC82MCBieXRlIGNv bm5lY3Rpb24gSURzIG1pZ2h0IG5vdCBiZSBsb25nIGVub3VnaCBpbiB0aGUgZnV0dXJlLg0KPiA+ DQo+ID4gID4NCj4gPiAgPiBUaGVyZSBhcmUgdHdvIG1haW4gcmVhc29ucyB0byBrZWVwIHRoZSBj b21wcmVzc2VkIGVuY29kaW5nOg0KPiA+ICA+IOKAoiBJbiB0aGUgY29tcHJlc3NlZCBlbmNvZGlu Zywgd2UgY2FuIHJlYXNvbmFibHkgZXhwZWN0IHRoYXQgYWxsIC8gbW9zdCB2YWx1ZXMgd2lsbCBi ZSB1c2VkIGluIHByYWN0aWNlLCBzbyB3ZSB3b24ndCBleHBvc2UgYW55IGJpdHMgb24gdGhlIHdp cmUgdGhhdCBpZGVudGlmeSBhIHBhY2tldCBhcyAiUVVJQyB0cmFmZmljIiBieSBoYXZpbmcgYSBw cmVkaWN0YWJsZSB2YWx1ZS4NCj4gPiAgPiDigKIgVGhlIDEtYnl0ZSBlbmNvZGluZyBoYXMgdGhl IGRpc2FkdmFudGFnZSB0aGF0IGFuIGltcGxlbWVudGF0aW9uIHN0aWxsIG5lZWRzIHRvIGJlIGFi bGUgdG8gZGVhbCB3aXRoIGNvbm5lY3Rpb24gSUQgbGVuZ3RocyBvZiAyNTUgYnl0ZXMsIGp1c3Qg dG8gYmUgYWJsZSB0byBzZW5kIFZlcnNpb24gTmVnb3RpYXRpb24gcGFja2V0cy4gVG8gbWUsIGl0 IHNlZW1zIGFic3VyZCB0byB3cml0ZSBhIFFVSUMgaW1wbGVtZW50YXRpb24gdGhhdCBpcyBhYmxl IHRvIGhhbmRsZSBwYWNrZXRzIHdpdGggYSBjb21iaW5lZCBjb25uZWN0aW9uIElEIG92ZXJoZWFk IG9mIDUxMCBieXRlcy4gU2luY2UgVk5QcyBhcmUgc3VwcG9zZWQgdG8gYmUgc2VudCBpbiByZXNw b25zZSB0byBhbnkgTG9uZyBIZWFkZXIgcGFja2V0LCB5b3UnZCBoYXZlIHRvIHB1dCBzb21lIGNh cmVmdWwgdGhvdWdodCBpbnRvIHRoZSBkZXNpZ24gb2YgeW91ciBkYXRhIHR5cGVzIHRvIGF2b2lk IHRoaXMgYmVjb21pbmcgYSBEb1MgdmVjdG9yLg0KPiA+ICA+DQo+ID4gID4gT24gVHVlLCBKdW4g MTgsIDIwMTkgYXQgMzo1MCBBTSBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5l dDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KPiA+ICA+IEkgdG9vIGFncmVl IHRoYXQgdXNpbmcgb25lIGJ5dGUgaW4gdGhlIGludmFyaWFudCBpcyBwcmVmZXJhYmxlIHRvIHRo ZSBjdXJyZW50ICJjb21wcmVzc2VkIDQgYml0cyIgc29sdXRpb24uDQo+ID4gID4NCj4gPiAgPiBS ZWdhcmRpbmcgdGhlICJDSUQgbGVuZ3RoIGxpbWl0IiwgSSB0aGluZyB0aGVyZSBhcmUgdHdvIGlz c3VlczogdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBhbmQgY29zdHMgdG8gdGhlIGNvbW11bml0eS4N Cj4gPiAgPg0KPiA+ICA+IEkgYW0gbm90IHRvbyBjb25jZXJuZWQgd2l0aCB0aGUgdHJhbnNtaXNz aW9uIG92ZXJoZWFkLCBhcyB3ZSBoYXZlIHRoZXJlIHRoZSByaWdodCBtaXggb2YgY29zdHMgYW5k IGluY2VudGl2ZXMuIFNlcnZlcnMgd2hvIGNob3NlIHRvIHVzZSBsb25nZXIgQ0lEIHdpbGwgZ2V0 IG1vcmUgdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBhbmQgdGh1cyB0cmFuc21pc3Npb24gbGVzcyBl ZmZpY2llbnRseSB0aGFuIHRoZWlyIGNvbXBldGl0b3JzLiBUaGV5IG1heSBjaG9zZSB0byB1c2Ug bG9uZ2VyIENJRCBhcyBhIHRyYWRlLW9mZiBiZXR3ZWVuIHRyYW5zbWlzc2lvbiBlZmZpY2llbmN5 IGFuZCBlYXNlIG9mIG1hbmFnZW1lbnQuIENvbXBldGl0aW9uIHdpbGwgc29ydCB0aGF0IG91dC4g SSBub3RlIHRoYXQgWW91VHViZSBpcyBhcHBhcmVudGx5IGRvaW5nIGZpbmUgd2l0aCBzbWFsbGlz aCBDSUQsIHNvIEkgdHJ1c3QgdGhhdCB0aGVyZSB3aWxsIGJlIGNvbXBldGl0aW9uLg0KPiA+ICA+ DQo+ID4gID4gSSBhbSBtdWNoIG1vcmUgY29uY2VybmVkIHdpdGggdGhlIHNoYXJlZCBjb3N0cywg d2hpY2ggYXJlIGEgdmFyaWF0aW9uIG9mIHRoZSAidHJhZ2VkeSBvZiB0aGUgY29tbW9ucyIuIERt aXRyeSBleHBsYWluZWQgdGhvc2UgY29zdHMgd2VsbCBpbiBhIHByZXZpb3VzIG1lc3NhZ2UuIFRo ZSBzaW1wbGVyIGltcGxlbWVudGF0aW9uIGlzIHRvIG1ha2UgdGhlICJjaWRfdCBhIGZpeGVkLXNp emUgb2JqZWN0IHRoYXQgY2FuIGZpdCB0aGUgbGFyZ2VzdCBDSUQgYW5kIGVhdCB0aGUgb3Zlcmhl YWQgZm9yIGFsbCBDSURzLiIgQnV0IGVhY2ggY29ubmVjdGlvbiBvYmplY3QgY2FycmllcyBhIGxh cmdlIG51bWJlciBvZiBpbnN0YW5jZXMgb2YgdGhlIENJRCB0eXBlLiBIYXZpbmcgYSB2ZXJ5IGxh cmdlIG1heCBDSUQgd291bGQgaW1wbHkgYSBsYXJnZSBvdmVyaGVhZC4gVGhlIGFsdGVybmF0aXZl IGlzIHRvICJNYWtlIGNpZF90IGEgdmFyaWFibGUtc2l6ZSBvYmplY3QiLCBidXQgdG9vIGFmZmVj dHMgcGVyZm9ybWFuY2UuDQo+ID4gID4NCj4gPiAgPiBIZW5jZSB0aGUgcHVzaC1iYWNrLiBJIHdv dWxkIHBlcnNvbmFsbHkgcHJlZmVyIGEgbWF4IHNpemUgb2YgMTYsIGFuZCBJIHRoaW5rIHRoYXQg MzIgaXMgdGhlIGhpZ2hlc3QgcHJhY3RpY2FsIGxpbWl0Lg0KPiA+ICA+DQo+ID4gID4gLS0gQ2hy aXN0aWFuIEh1aXRlbWENCj4gPiAgPg0KPiA+ICA+IE9uIDYvMTcvMjAxOSA5OjE2IEFNLCBSb2Jl cnRvIFBlb24gd3JvdGU6DQo+ID4gID4+IFdoYXQgSSB0aGluayBwZW9wbGUgYXJlIHNheWluZyBz byBmYXI6DQo+ID4gID4+DQo+ID4gID4+IDEpIFFVSUMgdjEgd291bGQgbGltaXQgQ0lEIGxlbmd0 aCB0byBzb21ldGhpbmcgb25lIG9mIHszMiwgMzYsIG9yIDQ4fQ0KPiA+ICA+Pg0KPiA+ICA+PiAy KSBSZXByZXNlbnRhdGlvbiBvZiBDSUQgbGVuZ3RoIGFzIGEgYnl0ZSBpcyBzdGlsbCBPSywgdGh1 cyBhIFFVSUMgdjIgY291bGQgdXNlIGxvbmdlciBDSURzIGFzIG5lZWRlZCBieSBjaGFuZ2luZyB0 aGUgc3BlYyB3aGlsZSBrZWVwaW5nIHRoZSBpbnZhcmlhbnRz4oCmIGludmFyaWFudC4NCj4gPiAg Pj4NCj4gPiAgPj4NCj4gPiAgPj4gVGhhdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIC8gSeKAmWQg c3RpbGwgc3VwcG9ydCB0aGF0Lg0KPiA+ICA+Pg0KPiA+ICA+PiAtPVINCj4gPiAgPj4NCj4gPiAg Pj4NCj4gPiAgPj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi4uLm9yZz4+IG9uIGJlaGFsZiBvZiAiTHViYXNoZXYsIElnb3IiIDxpbHVi YXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4NCj4gPiAgPj4gRGF0 ZTogTW9uZGF5LCBKdW5lIDE3LCAyMDE5IGF0IDg6NTUgQU0NCj4gPiAgPj4gVG86IElhbiBTd2V0 dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5j b21AZG1hcmMuaWV0Zi5vcmc+PiwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpA Z21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+Pg0KPiA+ICA+PiBDYzogRG1pdHJp IFRpa2hvbm92IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb208bWFpbHRvOmR0aWtob25vdkBs aXRlc3BlZWR0ZWNoLmNvbT4+LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5l dDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+LCAiUGhpbGlwcCBTLiBUaWVzZWwiIDxwaGls aXBwQHRpZXNlbC5uZXQ8bWFpbHRvOnBoaWxpcHBAdGllc2VsLm5ldD4+LCBNaWtlIEJpc2hvcCA8 bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4sIE1hcnRp biBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+Piwg TWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPG1haWx0bzptYXJ0ZW5zZWVt YW5uQGdtYWlsLmNvbT4+LCBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPG1haWx0bzpsYXJz QGVnZ2VydC5vcmc+PiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4+LCBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi5o LmR1a2VAZ21haWwuY29tPiA8bWFpbHRvOm1hcnRpbi4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86 bWFydGluLi5oLmR1a2VAZ21haWwuY29tPj4+LCBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwu Y29tPG1haWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4NCj4gPiAgPj4gU3ViamVjdDogUkU6IENv bnNlbnN1cyBDYWxsOiBNb3JlIENvbm5lY3Rpb24gSUQgU3BhY2UgIzI3MzYNCj4gPiAgPj4NCj4g PiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4gTXkgdGFrZSBpcyBzaW1pbGFyIOKAkyA0OCBpcyBwcm9i YWJseSBleGNlc3NpdmUsIHdoaWxlIDMyIGlzIGxpa2VseSB0aGUgdXBwZXIgbGltaXQgb2Yg4oCc cmVhc29uYWJsZeKAnSAoaXQgc2hvdWxkIHByb2JhYmx5IGJlIGEgZmFjdG9yIG9mIDgsIHNvIDMy IG9yIDI0PykuDQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IFdlIGFyZSBmaXJt bHkgY29tbWl0dGVkIGZvciB1c2luZyBDSUQgZm9yIGluLWNsdXN0ZXIgbG9hZCBiYWxhbmNpbmcg LyBhbnljYXN0IHBvcCByb3V0aW5nLiBUaGlzIGRpc2N1c3Npb24gaXMgdGFraW5nIHVzLCBob3dl dmVyLCB0byBhIG5ldyB0ZXJyaXRvcnkg4oCTIGEgZ2VuZXJhbGl6ZWQg4oCcZGVzdGluYXRpb24t Y29udHJvbGxlZCByb3V0aW5nIGluIGFuIG92ZXJsYXkgbmV0d29ya+KAnS4gVGhpcyBpcyBhIHZl cnkgaW50ZXJlc3RpbmcgdG9waWMsIGJ1dCBJIHdvdWxkIGhlc2l0YXRlIHRvIGF0dGVtcHQgdG8g c29sdmUgaXQgZnVsbHkgYW5kIOKAnGluIGdlbmVyYWzigJ0gaW4gUVVJQyB2MS4NCj4gPiAgPj4N Cj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4g4oCiIElnb3INCj4gPiAgPj4NCj4gPiAgPj4NCj4g PiAgPj4gRnJvbTogSWFuIFN3ZXR0IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQo+ID4gID4+DQo+ID4gID4+ IE15IGludHVpdGlvbiBzYXlzIG1ha2luZyB0aGUgY2hhbmdlIHRvIHRoZSBpbnZhcmlhbnRzIGlz IHRoZSByaWdodCB0aGluZyB0byBkbywgYnV0IEkgZG9uJ3QgZmVlbCB0aGF0IHN0cm9uZ2x5Lg0K PiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+PiBIb3dldmVyLCBJJ2QgbGlrZSB0aGUg bWF4IHNpemUgdG8gYmUgc21hbGxlciB0aGFuIDQ4KGJ1dCBsYXJnZXIgdGhhbiAxOCkuIElmIHdl IHRoaW5rIDIwIG9yIDI0IGlzIHN1ZmZpY2llbnQsIEknZCBwcmVmZXIgdGhhdC4gS2F6dWhvIHN1 Z2dlc3RlZCAzMiwgd2hpY2ggaXMgYmV0dGVyLCBidXQgSSBkb24ndCBiZWxpZXZlIHRoZSBzZXJ2 ZXIgbmVlZHMgdG8gdXNlIGEgc2VwYXJhdGUgYmxvY2sgY2lwaGVyIHdoZW4gZ2l2aW5nIG91dCBj b25uZWN0aW9uIElEcywgYmVjYXVzZSBJIGJlbGlldmUgaXQncyBpbXByYWN0aWNhbCBmb3IgdGhl IGxvYWQgYmFsYW5jZXIgYW5kIHNlcnZlciB0byBiZSB0aGF0IGRlY291cGxlZC4gVGhlIHNlcnZl ciBoYXMgdG8gZ2l2ZSBvdXQgYSBDSUQgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciB3aWxsIHVzZSB0 byByb3V0ZSBiYWNrIHRvIHRoZSBzZXJ2ZXIsIHNvIHRoZXkgaGF2ZSB0byBzaGFyZSBlbm91Z2gg YW4gZW5jcnlwdGlvbiBrZXkvYWxnb3JpdGhtLiBJIGNhbiBpbWFnaW5lIG5lc3RpbmcgbG9hZCBi YWxhbmNlcnMsIGJ1dCB0aGF0J3Mgd2VsbCBpbiB0aGUgcmFuZ2Ugb2YgUVVJQyB2MiBmcm9tIG15 IHBlcnNwZWN0aXZlLg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+PiBXaGF0ZXZl ciB3ZSBkbywgSSdkIHJlYWxseSBwcmVmZXIgdG8gcmVzb2x2ZSB0aGlzIHNvb25lciByYXRoZXIg dGhhbiBsYXRlciBhbmQgYmUgdHJ1bHkgZG9uZSB3aXRoIGl0Lg0KPiA+ICA+Pg0KPiA+ICA+Pg0K PiA+ICA+Pg0KPiA+ICA+PiBPbiBNb24sIEp1biAxNywgMjAxOSBhdCAyOjUxIEFNIE1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21h aWwuY29tPj4gd3JvdGU6DQo+ID4gID4+DQo+ID4gID4+IFNpbmNlIGl0IGlzIG1vcmUgbGlrZWx5 IHRoYXQgeW91IHBheSBmb3IgZWdyZXNzIHRyYWZmaWMgdGhhbiBpbmdyZXNzIHRyYWZmaWMsIHRo ZSBtb3RpdmF0aW9uIHRvIGtlZXAgQ0lE4oCZcyBzbWFsbCBpcyBsaW1pdGVkLg0KPiA+ICA+Pg0K PiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+PiBJIGRvIHRoaW5rIHRoZSBpbnZhcmlhbnRzIHNob3Vs ZCBhbGxvdyBmb3IgbG9uZyBDSUTigJlzIGFzIHByb3Bvc2VkLCBhbmQgdGhhdCB0aGUgbG9uZyBo ZWFkZXIgb3ZlcmhlYWQgaXMgbm90IGltcG9ydGFudC4uLg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ ICA+Pg0KPiA+ICA+PiBCdXQgZm9yIFFVSUMgdjEsIGlmIHdlIGFsbG93IGZvciBhIGxvbmcgQ0lE LCBhIHJ1c2ggdG8gbWFya2V0IHdpbGwgc2V0IHByZWNlZGVuY2UgYW5kIGxvbmcgQ0lE4oCZcyB3 aWxsIG9zc2lmeSBpbiBhbGwga2luZHMgb2Ygc3RhY2tzLg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ ICA+Pg0KPiA+ICA+PiBJIGdvb2QgcmVmZXJlbmNlIG9uIGFuIGFsZ29yaXRobSBsaWtlIHN1Z2dl c3RlZCBieSBDaHJpc3RpYW4gd291bGQgZ28gYSBsb25nIHdheS4NCj4gPiAgPj4NCj4gPiAgPj4N Cj4gPiAgPj4NCj4gPiAgPj4gSWYgQ0lEIGxlbmd0aCAxOCB0dXJucyBvdXQgdG8gYmUgbm90IGVu b3VnaCwgd2UgY2FuIGFkZCBhIFFVSUMgdjIuIEl04oCZcyBub3QgbGlrZSB3ZSBhcmUgbm90IGxv b2tpbmcgZm9yIGV4Y3VzZXMgdG8gdXBncmFkZSBRVUlDIHZlcnNpb25zIHNvb24uDQo+ID4gID4+ DQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IElmIENJRCBsZW5ndGggbmVnb3RpYXRpb24gaXMg bmVlZGVkLCB0aGlzIGNvdWxkIGJlIGRvbmUgdmlhIFFVSUMgdmVyc2lvbnMuIEZvciBleGFtcGxl IHR3byBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB2ZXJzaW9ucywgYnV0IG9uZSB3aXRoIGxvbmdl ciBDSUTigJlzLiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgcm91dGVycyB0byBkZWFsIHdpdGggY2hh bmdlcyBpbiBDSUQgbGVuZ3Rocy4gQSBuZWdvdGlhdGVkIFRQIHdvdWxkIG5vdCAoZWFzaWx5KSBh bGxvdyBmb3IgdGhhdCBhbmQgYXNpZGUgSSBkbyBub3QgdGhpbmsgQ0lEIGxlbmd0aCBpbiBUUCBp cyB0aGUgd2F5IHRvIGdvLg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+PiBNaWtr ZWwNCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4gT24gMTcgSnVuZSAyMDE5IGF0 IDA2LjQ1LjA0LCBLYXp1aG8gT2t1IChrYXp1aG9va3VAZ21haWwuY29tPG1haWx0bzprYXp1aG9v a3VAZ21haWwuY29tPikgd3JvdGU6DQo+ID4gID4+DQo+ID4gID4+IDIwMTnlubQ25pyIMTfml6Uo 5pyIKSAxMTowOSBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86 aHVpdGVtYUBodWl0ZW1hLm5ldD4+Og0KPiA+ICA+PiA+DQo+ID4gID4+ID4gT24gNi8xNS8yMDE5 IDEwOjU1IFBNLCBLYXp1aG8gT2t1IHdyb3RlOg0KPiA+ICA+PiA+DQo+ID4gID4+ID4gPiBfSWZf IHdlIGFyZSB0byBhbGxvdyBsb29zZSBjb3VwbGluZyBiZXR3ZWVuIGEgbG9hZCBiYWxhbmNlciBh bmQgYQ0KPiA+ICA+PiA+ID4gc2VydmVyLCBlYWNoIG9mIHRoZSB0d28gc2hvdWxkIGJlIGdpdmVu IHRoZSBmcmVlZG9tIHRvIGNob29zZSBpdCdzIG93bg0KPiA+ICA+PiA+ID4gQ0lEIGVuY3J5cHRp b24gc2NoZW1lLiBCZWNhdXNlIGFsbCB0aGUgc3RhbmRhcmRpemVkIGJsb2NrIGNpcGhlcnMgYXJl DQo+ID4gID4+ID4gPiBub3cgMTI4LWJpdHMgKD0gMTYgYnl0ZXMpLCB0aGF0IG5hdHVyYWxseSBt ZWFucyB0aGF0IHRoZSBtYXhpbXVtIENJRA0KPiA+ICA+PiA+ID4gbGVuZ3RoIG9mIFFVSUMgbmVl ZHMgdG8gYmUgZG91YmxlIGFtb3VudCBvZiB0aGF0LCBwbHVzIG9uZSBvciB0d28NCj4gPiAgPj4g PiA+IGJ5dGVzIGZvciBlYWNoIG9mIHRoZSB0d28gZm9yIGlkZW50aWZ5aW5nIHRoZSBDSUQgZW5j cnlwdGlvbiBrZXlzLiBGb3INCj4gPiAgPj4gPiA+IGtleSBpZGVudGlmaWNhdGlvbiBhbmQgb3Ro ZXIgc3VwcGxlbWVudGFsIHVzZSwgd2UgY3VycmVudGx5IGFsbG9jYXRlIDINCj4gPiAgPj4gPiA+ IGJ5dGVzICgxOC0xNj0yKS4NCj4gPiAgPj4gPg0KPiA+ICA+PiA+IFRoYXQgcmVhc29uaW5nIGlz IGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYm90aCB0aGUgbG9hZCBiYWxhbmNlcg0KPiA+ ICA+PiA+IGFuZCB0aGUgc2VydmVyIG11c3QgdXNlIGEgYmxvY2sgY2lwaGVyIHdpdGggMTI4IGJp dCBibG9jayBsZW5ndGggaW4NCj4gPiAgPj4gPiBvcmRlciB0byBlbmNyeXB0IHRoZSBDSUQuIElm IHRoZXkgd2VyZSBjb25zdHJhaW5lZCB0byBzdGF5IHdpdGhpbiBhDQo+ID4gID4+ID4gc2hvcnQg Z2xvYmFsIGxpbWl0LCB0aGV5IGNvdWxkIHVzZSBkaWZmZXJlbnQgc2V0cyBvZiBhbGdvcml0aG1z Lg0KPiA+ICA+PiA+DQo+ID4gID4+ID4gQXNzdW1lIGZvciBleGFtcGxlIHRoYXQgd2Ugc3BsaXQg dGhlIENJRCBiZXR3ZWVuIDMyIGJpdHMgZW5jb2RpbmcgdGhlDQo+ID4gID4+ID4gbnVtYmVyIG9m IHRoZSBzZXJ2ZXIgaW4gdGhlIHNlcnZlciBmYXJtLCBhbmQgNjQgYml0IGVuY29kaW5nIHRoZQ0K PiA+ICA+PiA+IGNvbm5lY3Rpb24gbnVtYmVyIGZvciB0aGUgc2VydmVyLiBUaGUgc2VydmVyIGNh biBwaWNrIGEgcmFuZG9tIHZhbHVlIGZvcg0KPiA+ICA+PiA+IHRoZSBjb25uZWN0aW9uIG51bWJl ciwgYW5kIHVzZSBhIGhhc2ggdGFibGUuIFRoZSBsb2FkIGJhbGFuY2VyIGNvdWxkIHVzZQ0KPiA+ ICA+PiA+IGEgMzIgYml0IHZhcmlhbnQgb2YgdGhlIEZGWCBhbGdvcml0aG0sIHVzaW5nIHRoZSBs b3dlciA2NCBiaXQgb2YgdGhlIENJRA0KPiA+ICA+PiA+IGFzIGFuIGluaXRpYWwgdmVjdG9yLiBW b2lsYSwgOTYgQ0lELCB3aXRoIGRlbW9uc3RyYWJseSBzdHJvbmcgZW5jcnlwdGlvbi4NCj4gPiAg Pj4gPg0KPiA+ICA+PiA+IE9yIGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXIgd2FudHMgdG8gdXNlIHNo b3J0IENJRC4gV2Ugbm93IHNwbGl0IHRoZSBDSUQNCj4gPiAgPj4gPiBiZXR3ZWVuIDMyIGJpdCBm b3IgdGhlIHNlcnZlciBudW1iZXIgaW4gdGhlIGZhcm0sIGFuZCAzMiBiaXQgZm9yIHRoZQ0KPiA+ ICA+PiA+IGNvbm5lY3Rpb24gbnVtYmVyIGluIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2ZXIgYnVpbGRz IHRoYXQgY29ubmVjdGlvbg0KPiA+ICA+PiA+IG51bWJlciBieSB1c2luZyBhIDMyIGJpdCB2YXJp YW50IG9mIEZGWC4gVGhlIGxvYWQgYmFsYW5jZXIgYWxzbyB1c2VzIGENCj4gPiAgPj4gPiAzMiBi aXQgdmFyaWFudCwgdXNpbmcgdGhlIGxvd2VyIDMyIGJpdCBvZiB0aGUgQ0lEIGFzIGluaXRpYWwg dmVjdG9yIGZvcg0KPiA+ICA+PiA+IHRoaXMgRkZYIGVuY3J5cHRpb24uDQo+ID4gID4+ID4NCj4g PiAgPj4gPiBUaGVzZSBhcmUganVzdCB0d28gZXhhbXBsZXMuIEFuZCB5ZXMgeW91IG1heSB3YW50 IHRvIGFkZCAyIGJ5dGVzIGZvciBrZXkNCj4gPiAgPj4gPiBpZGVudGlmaWNhdGlvbiwgZXRjLiBJ biBib3RoIGVuY3J5cHRpb24gYWxnb3JpdGhtcywgeW91IGNhbiBmZWVkIHRoZXNlDQo+ID4gID4+ ID4gdHdvIGJ5dGVzIGFzIGFkZGl0aW9uYWwgSVYgZm9yIHRoZSBGRlggYWxnb3JpdGhtLiBBbmQg aW4gYm90aCBjYXNlcywgd2UNCj4gPiAgPj4gPiBhcmUgd2VsbCBiZWxvdyB0aGUgMTggYnl0ZSBs aW1pdC4NCj4gPiAgPj4gPg0KPiA+ICA+PiA+IFllcywgdGhhdCByZXF1aXJlcyBzb21lIGNyZWF0 aXZlIGVuZ2luZWVyaW5nLiBCdXQgaXQgaXMgbm90IHJvY2tlcg0KPiA+ICA+PiA+IHNjaWVuY2Uu IEFuZCBpdCBzZWVtcyBiZXR0ZXIgdGhhbiBjYXJyeWluZyB0b25zIG9mIG92ZXJoZWFkIGluIHRo ZQ0KPiA+ICA+PiA+IGhlYWRlciwgYW5kIGJlY29taW5nIGxlc3MgZWZmaWNpZW50IHRoYW4gSFRU UDIvVExTL1RDUC4NCj4gPiAgPj4NCj4gPiAgPj4gSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIG5vdCBi ZSB0aGUgZW5kIG9mIHRoZSB3b3JsZCBmb3IgdGhlIGxvYWQNCj4gPiAgPj4gYmFsYW5jZXJzIGlm IHdlIGRlY2lkZSB0byBzdGljayBvbiB0aGUgMTgtYnl0ZSBsaW1pdC4gSG93ZXZlciwgYXMgeW91 DQo+ID4gID4+IHN0YXRlLCBpdCByZXF1aXJlcyBzb21lIGNyZWF0aXZlbmVzcy4NCj4gPiAgPj4N Cj4gPiAgPj4gVG8gbWUgaXQgc2VlbXMgdGhhdCB0aGUgcXVlc3Rpb24gaXMgaWYgd2UgaGF2ZSBh IHN0cm9uZyByZWFzb24gdG8NCj4gPiAgPj4gcmVxdWlyZSBzb21lIHBlb3BsZSB0byBiZSBjcmVh dGl2ZSwgZm9yIGFsbCB0aGUgdmVyc2lvbnMgb2YgUVVJQyBpbg0KPiA+ICA+PiB0aGUgZnV0dXJl LiBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCB0aGVyZSBpc24ndCBhIHN0cm9uZyByZWFzb24sDQo+ ID4gID4+IGJlY2F1c2UgcGVvcGxlIGNhbiB1c2Ugc2hvcnRlciBDSURzIHJlZ2FyZGxlc3Mgb2Yg dGhlIGRlY2lzaW9uIHdlDQo+ID4gID4+IG1ha2UuIElJVUMsIHRoZSBvdmVyaGVhZCB0aGF0IGV2 ZXJ5b25lIG5lZWRzIHRvIGFjY2VwdCBpczoNCj4gPiAgPj4NCj4gPiAgPj4gKiBvbmUgYnl0ZSBp bmNyZWFzZSBpbiB0aGUgbG9uZyBoZWFkZXIgcGFja2V0cw0KPiA+ICA+PiAqIHRoZSBtaW5pbXVt IHNpemUgb2Ygc2hvcnQgaGVhZGVyIHBhY2tldHMgYmVjb21pbmcgc2xpZ2h0bHkgZ3JlYXRlcg0K PiA+ICA+PiAob3RoZXJ3aXNlLCB0aGUgcGVlciBtaWdodCBub3QgYmUgYWJsZSB0byBzZW5kIGEg c3RhdGVsZXNzIHJlc2V0KQ0KPiA+ICA+Pg0KPiA+ICA+PiBJJ2Qgc2F5IHRoYXQgdGhlIGZpcnN0 IGJ1bGxldCBwb2ludCBpcyBuZWdsaWdpYmxlLiBUaGUgc2Vjb25kIHBvaW50DQo+ID4gID4+IGNv dWxkIGFsc28gYmUsIGJlY2F1c2UgSSdkIGFzc3VtZSB0aGF0IHRoZSBvbmx5IGZyZXF1ZW50bHkt c2VudA0KPiA+ICA+PiBwYWNrZXRzIHRoYXQgcmVxdWlyZSBhZGRpdGlvbmFsIHBhZGRpbmcgaXMg dGhlIEFDSy1vbmx5IHBhY2tldHMsIGJ1dA0KPiA+ICA+PiB0aGVyZSdzIG5vIHJlYXNvbiB0byBw YWQgQUNLLW9ubHkgcGFja2V0cyBpbiBob3BlIHRoYXQgeW91J2Qgc2VlIGENCj4gPiAgPj4gc3Rh dGVsZXNzIHJlc2V0Lg0KPiA+ICA+Pg0KPiA+ICA+PiBUaGVyZWZvcmUsIG15IChub3Qtc28tc3Ry b25nKSBwcmVmZXJlbmNlIGhhcyBiZWVuIHRvIHByb3ZpZGUgZXh0cmENCj4gPiAgPj4gcm9vbSwg c28gdGhhdCBzb21lIHBlb3BsZSB3aXRoIG5lY2Vzc2l0eSBjYW4gdXNlIGxvbmdlciBDSURzLg0K PiA+ICA+Pg0KPiA+ICA+PiA+DQo+ID4gID4+ID4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4gPiAg Pj4gPg0KPiA+ICA+PiA+DQo+ID4gID4+ID4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4NCj4g PiAgPj4gLS0NCj4gPiAgPj4gS2F6dWhvIE9rdQ0KPiA+ICA+Pg0KPiA+DQo+ID4gIEFWRSENCj4g PiAgUGhpbGlwcCBTLiBUaWVzZWwNCj4gPg0KPiA+ICAtLQ0KPiA+ICBQaGlsaXBwIFMuIFRpZXNl bA0KPiA+IGh0dHBzOi8vcGhpbGlwcC50aWVzZWwubmV0LzxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3BoaWxpcHAudGllc2VsLm5ldF8mZD1Ed01G YVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPTMt LVZmODN5dVVTdUx0STR4MmVuV1QzdXRTV3p1clF2RFpEVGlfN3RKemMmcz0wRXJoNEQ2bUtrS2tE Qy1Fc2NtTTJJWi1qNU96clE4bmotYnVxM3FLYTRvJmU9Pg0KPiA+DQo= --_000_F127DB352E274709A231558C0E151AE3fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1hbmdhbDsNCglwYW5vc2UtMToyIDQg NSAzIDUgMiAzIDMgMiAyO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcg MiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V29ya3MgZm9yIG1lLjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg RGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+RnJpZGF5LCBKdW5lIDIxLCAyMDE5IGF0IDE6MDIgUE08YnI+DQo8Yj5UbzogPC9i PklhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxi cj4NCjxiPkNjOiA8L2I+SUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OywgTWFydGlu IFRob21zb24gJmx0O210QGxvd2VudHJvcHkubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S ZTogQ29uc2Vuc3VzIENhbGw6IE1vcmUgQ29ubmVjdGlvbiBJRCBTcGFjZSAjMjczNjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0 MzsxIHRvIHdoYXQgSWFuIHNhaWQuICgyKSBzZWVtcyBsaWtlIGEgZ29vZCBwYXRoIGZvcndhcmQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVu IDIxLCAyMDE5IGF0IDE6MDAgUE0gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dD08YSBocmVmPSJtYWls dG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSAzIG9wdGlvbnMgSSBzZWUgYXMg d2VsbCByZWFzb25lZCBhcmU6IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjEpIEtlZXAgdGhlIHN0YXR1cyBxdW8gYmVjYXVzZSB3ZSB0aGluayB3ZSBjYW4gcHV0 IHdoYXQgd2UgcmVhbGx5IG5lZWQgaW50byAxOCBieXRlcyBpZiB3ZSB0cnkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBDaGFuZ2UgdG8gYSAx IGJ5dGUgbGVuZ3RoIHBlciBDSUQgYW5kIGEgbWF4IG9mIDIwLCB3aGljaCBnaXZlcyB1cyBhIGZl dyBleHRyYSBieXRlcyBmb3IgY2xlYXJ0ZXh0IHNlcnZlciBpZCBhbmQvb3Iga2V5IHJvdGF0aW9u L2V0Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMpIENoYW5nZSB0byBhIDEgYnl0ZSBsZW5ndGggcGVyIENJRCBhbmQgYSBtYXggb2YgMzYsIGJl Y2F1c2Ugd2Ugd2FudCBiZSBhYmxlIHRvIHB1dCAyIGVuY3J5cHRlZCByb3V0aW5nIElEcyBpbiBh IHNpbmdsZSBDSUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjIgaXMgbXkgcHJlZmVycmVkIG9wdGlvbiwgdGhvdWdoIEkgY2FuIGxpdmUgd2l0 aCBlaXRoZXIgb2YgMSBvciAzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5EZWNpZGluZyBzb29uZXIgd291bGQgYmUgc3RyaWN0bHkgYmV0dGVy IHRoYW4gbGF0ZXIsIHNpbmNlIHRoaXMgaXMgYmxvY2tpbmcgdXMoQ2hyb21lL0dvb2dsZSkgYWN0 dWFsbHkgc3VwcG9ydGluZyB2YXJsZW4gQ0lEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdW4gMjAsIDIwMTkgYXQgMjo1NyBQ TSBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0IiB0 YXJnZXQ9Il9ibGFuayI+bXRAbG93ZW50cm9weS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhdCBzZWVtcyBhIGxpdHRsZSBoaWdoLiZuYnNwOyBJIHRo aW5rIHRoYXQgSWFuJ3MgcHJpbmNpcGxlIGhlcmUgaXMgd2hhdCBzaG91bGQgZ3VpZGUgdXM6IHdo YXQgaXMgdGhlIG1pbmltdW0geW91IGNhbiBoYW5kbGU/Jm5ic3A7IFdoYXQgSSd2ZSBoZWFyZCBp cyB0aGF0IDE4IG1pZ2h0IGhhdmUgYmVlbiB3b3JrYWJsZSwgYnV0IGl0IHdhcyBSRUFMTFkgY2xv c2UgdG8gdGhlDQogZWRnZSB0byB0aGUgcG9pbnQgdGhhdCB5b3Ugd2VyZW4ndCBjb25maWRlbnQg aXQgd2FzIGVub3VnaCwgZXZlbiBpbiB0aGUgbmVhciB0ZXJtLi4mbmJzcDsgQnV0IHRoYXQgc3Vn Z2VzdHMgdGhhdCAyMCBpcyB3b3JrYWJsZS48YnI+DQo8YnI+DQpPbiBXZWQsIEp1biAxOSwgMjAx OSwgYXQgMjE6NDMsIE1hcnRpbiBEdWtlIHdyb3RlOjxicj4NCiZndDsgc28gZG8gSSBoZWFyIGNv bnNlbnN1cyBlbWVyZ2luZyBhcm91bmQgMzJCIGluIHYxLCBvciBzaG91bGQgSSBsZWF2ZSB0aGUg PGJyPg0KJmd0OyAxOEIgbGltaXQgaW4gdjEgZm9yIG5vdyBhbmQgcHVudCBvdXQgdGhhdCBkaXNj dXNzaW9uPzxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUdWUsIEp1biAxOCwgMjAxOSBhdCAxOjI0 IEFNIFBoaWxpcHAgUy4gVGllc2VsICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGlwcEB0aWVzZWwu bmV0IiB0YXJnZXQ9Il9ibGFuayI+cGhpbGlwcEB0aWVzZWwubmV0PC9hPiZndDsgd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBP biAxOC4gSnVuIDIwMTksIGF0IDA1OjMzLCBNYXJ0ZW4gU2VlbWFubiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGVuc2VlbWFu bkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBJJ2QgcHJlZmVyIGtlZXBpbmcgdGhlICZxdW90O2NvbXBy ZXNzZWQgNCBiaXRzJnF1b3Q7IHNvbHV0aW9uLCBldmVuIGlmIHdlIGRlY2lkZSB0byBpbmNyZWFz ZSB0aGUgY29ubmVjdGlvbiBJRCBsZW5ndGggdG8gYSBsYXJnZXIgdmFsdWUgKHdoaWNoIEknbSBz dGlsbCBub3QgY29udmluY2VkIHRoYXQgdGhpcyBpcyByZWFsbHkgbmVjZXNzYXJ5KS48YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IFRoaXMgd291bGQgYmUgZWFzeSBpZiB3ZSBj aGFuZ2UgdGhlIGVuY29kaW5nIG9mIHRoZSBjb25uZWN0aW9uIElEIGxlbmd0aCwgZS4uZy4sIHRv IGJlIERDSUwqNCBhbGxvd2luZyB1cCB0byA2MCBieXRlIGNvbm5lY3Rpb24gSURzLiBXaGlsZSB3 ZSBjYW4gbm90IGVuY29kZSBvbmUgb3IgdHdvIGJ5dGUgY29ubmVjdGlvbiBJRHMgaW4gbG9uZyBo ZWFkZXIgcGFja2V0cywgd2UgY2FuIHN0aWxsIHVzZSB0aGVtIGluIHNob3J0IGhlYWRlciBwYWNr ZXRzLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgVGhpcyBzcGxpdCBiZXR3 ZWVuIGxvbmcgYW5kIHNob3J0IGhlYWRlciBhbHNvIGFsbG93cyB0byB1c2UgbXVjaCBsb25nZXIg Y29ubmVjdGlvbiBJRHMgYWZ0ZXIgdGhlIGhhbmRzaGFrZS48YnI+DQomZ3Q7ICZndDsmbmJzcDsg SSBkb27igJl0IHNlZSBtdWNoIHVzZSBpbiBpdCwgYnV0IGl0IG1heSB0YWtlIG9mZiBzb21lIGZl YXIgdGhhdCAyNC8zMi8zNi80OC82MCBieXRlIGNvbm5lY3Rpb24gSURzIG1pZ2h0IG5vdCBiZSBs b25nIGVub3VnaCBpbiB0aGUgZnV0dXJlLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBUaGVyZSBhcmUgdHdvIG1haW4g cmVhc29ucyB0byBrZWVwIHRoZSBjb21wcmVzc2VkIGVuY29kaW5nOjxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7IOKAoiBJbiB0aGUgY29tcHJlc3NlZCBlbmNvZGluZywgd2UgY2FuIHJlYXNvbmFi bHkgZXhwZWN0IHRoYXQgYWxsIC8gbW9zdCB2YWx1ZXMgd2lsbCBiZSB1c2VkIGluIHByYWN0aWNl LCBzbyB3ZSB3b24ndCBleHBvc2UgYW55IGJpdHMgb24gdGhlIHdpcmUgdGhhdCBpZGVudGlmeSBh IHBhY2tldCBhcyAmcXVvdDtRVUlDIHRyYWZmaWMmcXVvdDsgYnkgaGF2aW5nIGEgcHJlZGljdGFi bGUgdmFsdWUuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg4oCiIFRoZSAxLWJ5dGUgZW5jb2Rp bmcgaGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBzdGlsbCBuZWVk cyB0byBiZSBhYmxlIHRvIGRlYWwgd2l0aCBjb25uZWN0aW9uIElEIGxlbmd0aHMgb2YgMjU1IGJ5 dGVzLCBqdXN0IHRvIGJlIGFibGUgdG8gc2VuZCBWZXJzaW9uIE5lZ290aWF0aW9uIHBhY2tldHMu IFRvIG1lLCBpdCBzZWVtcyBhYnN1cmQgdG8gd3JpdGUgYSBRVUlDIGltcGxlbWVudGF0aW9uIHRo YXQNCiBpcyBhYmxlIHRvIGhhbmRsZSBwYWNrZXRzIHdpdGggYSBjb21iaW5lZCBjb25uZWN0aW9u IElEIG92ZXJoZWFkIG9mIDUxMCBieXRlcy4gU2luY2UgVk5QcyBhcmUgc3VwcG9zZWQgdG8gYmUg c2VudCBpbiByZXNwb25zZSB0byBhbnkgTG9uZyBIZWFkZXIgcGFja2V0LCB5b3UnZCBoYXZlIHRv IHB1dCBzb21lIGNhcmVmdWwgdGhvdWdodCBpbnRvIHRoZSBkZXNpZ24gb2YgeW91ciBkYXRhIHR5 cGVzIHRvIGF2b2lkIHRoaXMgYmVjb21pbmcgYSBEb1MNCiB2ZWN0b3IuPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgT24gVHVlLCBKdW4gMTgsIDIw MTkgYXQgMzo1MCBBTSBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRl bWFAaHVpdGVtYS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSSB0b28gYWdyZWUgdGhhdCB1c2lu ZyBvbmUgYnl0ZSBpbiB0aGUgaW52YXJpYW50IGlzIHByZWZlcmFibGUgdG8gdGhlIGN1cnJlbnQg JnF1b3Q7Y29tcHJlc3NlZCA0IGJpdHMmcXVvdDsgc29sdXRpb24uPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgUmVnYXJkaW5nIHRoZSAmcXVvdDtD SUQgbGVuZ3RoIGxpbWl0JnF1b3Q7LCBJIHRoaW5nIHRoZXJlIGFyZSB0d28gaXNzdWVzOiB0cmFu c21pc3Npb24gb3ZlcmhlYWQsIGFuZCBjb3N0cyB0byB0aGUgY29tbXVuaXR5Ljxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEkgYW0gbm90IHRvbyBj b25jZXJuZWQgd2l0aCB0aGUgdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBhcyB3ZSBoYXZlIHRoZXJl IHRoZSByaWdodCBtaXggb2YgY29zdHMgYW5kIGluY2VudGl2ZXMuIFNlcnZlcnMgd2hvIGNob3Nl IHRvIHVzZSBsb25nZXIgQ0lEIHdpbGwgZ2V0IG1vcmUgdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBh bmQgdGh1cyB0cmFuc21pc3Npb24gbGVzcyBlZmZpY2llbnRseSB0aGFuIHRoZWlyIGNvbXBldGl0 b3JzLiBUaGV5DQogbWF5IGNob3NlIHRvIHVzZSBsb25nZXIgQ0lEIGFzIGEgdHJhZGUtb2ZmIGJl dHdlZW4gdHJhbnNtaXNzaW9uIGVmZmljaWVuY3kgYW5kIGVhc2Ugb2YgbWFuYWdlbWVudC4gQ29t cGV0aXRpb24gd2lsbCBzb3J0IHRoYXQgb3V0LiBJIG5vdGUgdGhhdCBZb3VUdWJlIGlzIGFwcGFy ZW50bHkgZG9pbmcgZmluZSB3aXRoIHNtYWxsaXNoIENJRCwgc28gSSB0cnVzdCB0aGF0IHRoZXJl IHdpbGwgYmUgY29tcGV0aXRpb24uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgSSBhbSBtdWNoIG1vcmUgY29uY2VybmVkIHdpdGggdGhlIHNoYXJl ZCBjb3N0cywgd2hpY2ggYXJlIGEgdmFyaWF0aW9uIG9mIHRoZSAmcXVvdDt0cmFnZWR5IG9mIHRo ZSBjb21tb25zJnF1b3Q7LiBEbWl0cnkgZXhwbGFpbmVkIHRob3NlIGNvc3RzIHdlbGwgaW4gYSBw cmV2aW91cyBtZXNzYWdlLiBUaGUgc2ltcGxlciBpbXBsZW1lbnRhdGlvbiBpcyB0byBtYWtlIHRo ZSAmcXVvdDtjaWRfdCBhIGZpeGVkLXNpemUgb2JqZWN0IHRoYXQgY2FuIGZpdCB0aGUgbGFyZ2Vz dA0KIENJRCBhbmQgZWF0IHRoZSBvdmVyaGVhZCBmb3IgYWxsIENJRHMuJnF1b3Q7IEJ1dCBlYWNo IGNvbm5lY3Rpb24gb2JqZWN0IGNhcnJpZXMgYSBsYXJnZSBudW1iZXIgb2YgaW5zdGFuY2VzIG9m IHRoZSBDSUQgdHlwZS4gSGF2aW5nIGEgdmVyeSBsYXJnZSBtYXggQ0lEIHdvdWxkIGltcGx5IGEg bGFyZ2Ugb3ZlcmhlYWQuIFRoZSBhbHRlcm5hdGl2ZSBpcyB0byAmcXVvdDtNYWtlIGNpZF90IGEg dmFyaWFibGUtc2l6ZSBvYmplY3QmcXVvdDssIGJ1dCB0b28gYWZmZWN0cyBwZXJmb3JtYW5jZS48 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBIZW5j ZSB0aGUgcHVzaC1iYWNrLiBJIHdvdWxkIHBlcnNvbmFsbHkgcHJlZmVyIGEgbWF4IHNpemUgb2Yg MTYsIGFuZCBJIHRoaW5rIHRoYXQgMzIgaXMgdGhlIGhpZ2hlc3QgcHJhY3RpY2FsIGxpbWl0Ljxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IC0tIENo cmlzdGlhbiBIdWl0ZW1hPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgT24gNi8xNy8yMDE5IDk6MTYgQU0sIFJvYmVydG8gUGVvbiB3cm90ZTo8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgV2hhdCBJIHRoaW5rIHBlb3BsZSBhcmUgc2F5aW5n IHNvIGZhcjo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsmZ3Q7IDEpIFFVSUMgdjEgd291bGQgbGltaXQgQ0lEIGxlbmd0aCB0byBzb21ldGhp bmcgb25lIG9mIHszMiwgMzYsIG9yIDQ4fTxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgMikgUmVwcmVzZW50YXRpb24gb2YgQ0lEIGxl bmd0aCBhcyBhIGJ5dGUgaXMgc3RpbGwgT0ssIHRodXMgYSBRVUlDIHYyIGNvdWxkIHVzZSBsb25n ZXIgQ0lEcyBhcyBuZWVkZWQgYnkgY2hhbmdpbmcgdGhlIHNwZWMgd2hpbGUga2VlcGluZyB0aGUg aW52YXJpYW50c+KApiBpbnZhcmlhbnQuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgVGhhdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIC8gSeKAmWQgc3RpbGwgc3VwcG9ydCB0aGF0 Ljxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyZndDsgLT1SPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgRnJvbTogUVVJQyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLi4ub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90O0x1YmFz aGV2LCBJZ29yJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7Jmd0OyBEYXRlOiBNb25kYXksIEp1bmUgMTcsIDIwMTkgYXQgODo1NSBBTTxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBUbzogSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dD08 YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDssIE1pa2tlbCBGYWhuw7hlIErD uHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7Jmd0OyBDYzogRG1pdHJpIFRpa2hvbm92ICZsdDs8YSBocmVmPSJtYWlsdG86ZHRpa2hvbm92 QGxpdGVzcGVlZHRlY2guY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHRpa2hvbm92QGxpdGVzcGVlZHRl Y2guY29tPC9hPiZndDssIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVp dGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+ Jmd0OywgJnF1b3Q7UGhpbGlwcCBTLiBUaWVzZWwmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpw aGlsaXBwQHRpZXNlbC5uZXQiIHRhcmdldD0iX2JsYW5rIj5waGlsaXBwQHRpZXNlbC5uZXQ8L2E+ Jmd0OywNCiBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91 LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OywgTWFydGlu IFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCIgdGFyZ2V0PSJf YmxhbmsiPm10QGxvd2VudHJvcHkubmV0PC9hPiZndDssIE1hcnRlbiBTZWVtYW5uICZsdDs8YSBo cmVmPSJtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0 ZW5zZWVtYW5uQGdtYWlsLmNvbTwvYT4mZ3Q7LA0KIExhcnMgRWdnZXJ0ICZsdDs8YSBocmVmPSJt YWlsdG86bGFyc0BlZ2dlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+bGFyc0BlZ2dlcnQub3JnPC9h PiZndDssIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7LCBNYXJ0aW4gRHVrZSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmgu ZHVrZUBnbWFpbC5jb208L2E+DQogJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFydGluLi5o LmR1a2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLi5oLmR1a2VAZ21haWwuY29t PC9hPiZndDsmZ3Q7LCBLYXp1aG8gT2t1ICZsdDs8YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0Ozxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogQ29uc2Vuc3VzIENhbGw6IE1v cmUgQ29ubmVjdGlvbiBJRCBTcGFjZSAjMjczNjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBNeSB0YWtlIGlzIHNpbWlsYXIg 4oCTIDQ4IGlzIHByb2JhYmx5IGV4Y2Vzc2l2ZSwgd2hpbGUgMzIgaXMgbGlrZWx5IHRoZSB1cHBl ciBsaW1pdCBvZiDigJxyZWFzb25hYmxl4oCdIChpdCBzaG91bGQgcHJvYmFibHkgYmUgYSBmYWN0 b3Igb2YgOCwgc28gMzIgb3IgMjQ/KS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgV2UgYXJlIGZpcm1seSBjb21taXR0ZWQg Zm9yIHVzaW5nIENJRCBmb3IgaW4tY2x1c3RlciBsb2FkIGJhbGFuY2luZyAvIGFueWNhc3QgcG9w IHJvdXRpbmcuIFRoaXMgZGlzY3Vzc2lvbiBpcyB0YWtpbmcgdXMsIGhvd2V2ZXIsIHRvIGEgbmV3 IHRlcnJpdG9yeSDigJMgYSBnZW5lcmFsaXplZCDigJxkZXN0aW5hdGlvbi1jb250cm9sbGVkIHJv dXRpbmcgaW4gYW4gb3ZlcmxheSBuZXR3b3Jr4oCdLiBUaGlzIGlzIGEgdmVyeSBpbnRlcmVzdGlu ZyB0b3BpYywNCiBidXQgSSB3b3VsZCBoZXNpdGF0ZSB0byBhdHRlbXB0IHRvIHNvbHZlIGl0IGZ1 bGx5IGFuZCDigJxpbiBnZW5lcmFs4oCdIGluIFFVSUMgdjEuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IOKAoiBJZ29yPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgRnJvbTogSWFuIFN3ZXR0ICZsdDtpYW5z d2V0dD08YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IE15IGludHVp dGlvbiBzYXlzIG1ha2luZyB0aGUgY2hhbmdlIHRvIHRoZSBpbnZhcmlhbnRzIGlzIHRoZSByaWdo dCB0aGluZyB0byBkbywgYnV0IEkgZG9uJ3QgZmVlbCB0aGF0IHN0cm9uZ2x5Ljxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBI b3dldmVyLCBJJ2QgbGlrZSB0aGUgbWF4IHNpemUgdG8gYmUgc21hbGxlciB0aGFuIDQ4KGJ1dCBs YXJnZXIgdGhhbiAxOCkuIElmIHdlIHRoaW5rIDIwIG9yIDI0IGlzIHN1ZmZpY2llbnQsIEknZCBw cmVmZXIgdGhhdC4gS2F6dWhvIHN1Z2dlc3RlZCAzMiwgd2hpY2ggaXMgYmV0dGVyLCBidXQgSSBk b24ndCBiZWxpZXZlIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gdXNlIGEgc2VwYXJhdGUgYmxvY2sgY2lw aGVyIHdoZW4gZ2l2aW5nIG91dA0KIGNvbm5lY3Rpb24gSURzLCBiZWNhdXNlIEkgYmVsaWV2ZSBp dCdzIGltcHJhY3RpY2FsIGZvciB0aGUgbG9hZCBiYWxhbmNlciBhbmQgc2VydmVyIHRvIGJlIHRo YXQgZGVjb3VwbGVkLiBUaGUgc2VydmVyIGhhcyB0byBnaXZlIG91dCBhIENJRCB0aGF0IHRoZSBs b2FkIGJhbGFuY2VyIHdpbGwgdXNlIHRvIHJvdXRlIGJhY2sgdG8gdGhlIHNlcnZlciwgc28gdGhl eSBoYXZlIHRvIHNoYXJlIGVub3VnaCBhbiBlbmNyeXB0aW9uIGtleS9hbGdvcml0aG0uDQogSSBj YW4gaW1hZ2luZSBuZXN0aW5nIGxvYWQgYmFsYW5jZXJzLCBidXQgdGhhdCdzIHdlbGwgaW4gdGhl IHJhbmdlIG9mIFFVSUMgdjIgZnJvbSBteSBwZXJzcGVjdGl2ZS48YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgV2hhdGV2ZXIg d2UgZG8sIEknZCByZWFsbHkgcHJlZmVyIHRvIHJlc29sdmUgdGhpcyBzb29uZXIgcmF0aGVyIHRo YW4gbGF0ZXIgYW5kIGJlIHRydWx5IGRvbmUgd2l0aCBpdC48YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgT24gTW9uLCBKdW4g MTcsIDIwMTkgYXQgMjo1MSBBTSBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVm PSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBTaW5jZSBpdCBpcyBtb3JlIGxpa2VseSB0aGF0IHlv dSBwYXkgZm9yIGVncmVzcyB0cmFmZmljIHRoYW4gaW5ncmVzcyB0cmFmZmljLCB0aGUgbW90aXZh dGlvbiB0byBrZWVwIENJROKAmXMgc21hbGwgaXMgbGltaXRlZC48YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgSSBkbyB0aGlu ayB0aGUgaW52YXJpYW50cyBzaG91bGQgYWxsb3cgZm9yIGxvbmcgQ0lE4oCZcyBhcyBwcm9wb3Nl ZCwgYW5kIHRoYXQgdGhlIGxvbmcgaGVhZGVyIG92ZXJoZWFkIGlzIG5vdCBpbXBvcnRhbnQuLi48 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyZndDsgQnV0IGZvciBRVUlDIHYxLCBpZiB3ZSBhbGxvdyBmb3IgYSBsb25nIENJRCwgYSBy dXNoIHRvIG1hcmtldCB3aWxsIHNldCBwcmVjZWRlbmNlIGFuZCBsb25nIENJROKAmXMgd2lsbCBv c3NpZnkgaW4gYWxsIGtpbmRzIG9mIHN0YWNrcy48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgSSBnb29kIHJlZmVyZW5jZSBv biBhbiBhbGdvcml0aG0gbGlrZSBzdWdnZXN0ZWQgYnkgQ2hyaXN0aWFuIHdvdWxkIGdvIGEgbG9u ZyB3YXkuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7IElmIENJRCBsZW5ndGggMTggdHVybnMgb3V0IHRvIGJlIG5vdCBlbm91 Z2gsIHdlIGNhbiBhZGQgYSBRVUlDIHYyLiBJdOKAmXMgbm90IGxpa2Ugd2UgYXJlIG5vdCBsb29r aW5nIGZvciBleGN1c2VzIHRvIHVwZ3JhZGUgUVVJQyB2ZXJzaW9ucyBzb29uLjxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBJ ZiBDSUQgbGVuZ3RoIG5lZ290aWF0aW9uIGlzIG5lZWRlZCwgdGhpcyBjb3VsZCBiZSBkb25lIHZp YSBRVUlDIHZlcnNpb25zLiBGb3IgZXhhbXBsZSB0d28gZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQg dmVyc2lvbnMsIGJ1dCBvbmUgd2l0aCBsb25nZXIgQ0lE4oCZcy4gVGhpcyB3b3VsZCBhbHNvIGFs bG93IHJvdXRlcnMgdG8gZGVhbCB3aXRoIGNoYW5nZXMgaW4gQ0lEIGxlbmd0aHMuIEEgbmVnb3Rp YXRlZCBUUCB3b3VsZCBub3QgKGVhc2lseSkNCiBhbGxvdyBmb3IgdGhhdCBhbmQgYXNpZGUgSSBk byBub3QgdGhpbmsgQ0lEIGxlbmd0aCBpbiBUUCBpcyB0aGUgd2F5IHRvIGdvLjxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBN aWtrZWw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgT24gMTcgSnVuZSAyMDE5IGF0IDA2LjQ1LjA0LCBLYXp1aG8gT2t1ICg8 YSBocmVmPSJtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthenVo b29rdUBnbWFpbC5jb208L2E+KSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDIwMTk8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+NjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4xNzxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5pyIPC9zcGFuPikgMTE6MDkgQ2hyaXN0 aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJn ZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Og0KPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsg T24gNi8xNS8yMDE5IDEwOjU1IFBNLCBLYXp1aG8gT2t1IHdyb3RlOiA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyAm Z3Q7IF9JZl8gd2UgYXJlIHRvIGFsbG93IGxvb3NlIGNvdXBsaW5nIGJldHdlZW4gYSBsb2FkIGJh bGFuY2VyIGFuZCBhIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgc2Vy dmVyLCBlYWNoIG9mIHRoZSB0d28gc2hvdWxkIGJlIGdpdmVuIHRoZSBmcmVlZG9tIHRvIGNob29z ZSBpdCdzIG93bg0KPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgJmd0OyBDSUQg ZW5jcnlwdGlvbiBzY2hlbWUuIEJlY2F1c2UgYWxsIHRoZSBzdGFuZGFyZGl6ZWQgYmxvY2sgY2lw aGVycyBhcmUNCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgbm93IDEy OC1iaXRzICg9IDE2IGJ5dGVzKSwgdGhhdCBuYXR1cmFsbHkgbWVhbnMgdGhhdCB0aGUgbWF4aW11 bSBDSUQgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgJmd0OyBsZW5ndGggb2Yg UVVJQyBuZWVkcyB0byBiZSBkb3VibGUgYW1vdW50IG9mIHRoYXQsIHBsdXMgb25lIG9yIHR3byA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyAmZ3Q7IGJ5dGVzIGZvciBlYWNoIG9m IHRoZSB0d28gZm9yIGlkZW50aWZ5aW5nIHRoZSBDSUQgZW5jcnlwdGlvbiBrZXlzLiBGb3INCjxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsga2V5IGlkZW50aWZpY2F0aW9u IGFuZCBvdGhlciBzdXBwbGVtZW50YWwgdXNlLCB3ZSBjdXJyZW50bHkgYWxsb2NhdGUgMg0KPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgJmd0OyBieXRlcyAoMTgtMTY9MikuIDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7Jmd0OyAmZ3Q7IFRoYXQgcmVhc29uaW5nIGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRo YXQgYm90aCB0aGUgbG9hZCBiYWxhbmNlciA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg Jmd0OyBhbmQgdGhlIHNlcnZlciBtdXN0IHVzZSBhIGJsb2NrIGNpcGhlciB3aXRoIDEyOCBiaXQg YmxvY2sgbGVuZ3RoIGluIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IG9yZGVy IHRvIGVuY3J5cHQgdGhlIENJRC4gSWYgdGhleSB3ZXJlIGNvbnN0cmFpbmVkIHRvIHN0YXkgd2l0 aGluIGEgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgc2hvcnQgZ2xvYmFsIGxp bWl0LCB0aGV5IGNvdWxkIHVzZSBkaWZmZXJlbnQgc2V0cyBvZiBhbGdvcml0aG1zLiA8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgJmd0OyBBc3N1bWUgZm9yIGV4YW1wbGUgdGhhdCB3ZSBzcGxpdCB0aGUgQ0lEIGJldHdlZW4g MzIgYml0cyBlbmNvZGluZyB0aGUgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsg bnVtYmVyIG9mIHRoZSBzZXJ2ZXIgaW4gdGhlIHNlcnZlciBmYXJtLCBhbmQgNjQgYml0IGVuY29k aW5nIHRoZSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyBjb25uZWN0aW9uIG51 bWJlciBmb3IgdGhlIHNlcnZlci4gVGhlIHNlcnZlciBjYW4gcGljayBhIHJhbmRvbSB2YWx1ZSBm b3INCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IHRoZSBjb25uZWN0aW9uIG51 bWJlciwgYW5kIHVzZSBhIGhhc2ggdGFibGUuIFRoZSBsb2FkIGJhbGFuY2VyIGNvdWxkIHVzZQ0K PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgYSAzMiBiaXQgdmFyaWFudCBvZiB0 aGUgRkZYIGFsZ29yaXRobSwgdXNpbmcgdGhlIGxvd2VyIDY0IGJpdCBvZiB0aGUgQ0lEDQo8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyBhcyBhbiBpbml0aWFsIHZlY3Rvci4gVm9p bGEsIDk2IENJRCwgd2l0aCBkZW1vbnN0cmFibHkgc3Ryb25nIGVuY3J5cHRpb24uDQo8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgJmd0OyBPciBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdhbnRzIHRvIHVzZSBzaG9ydCBDSUQu IFdlIG5vdyBzcGxpdCB0aGUgQ0lEIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7 IGJldHdlZW4gMzIgYml0IGZvciB0aGUgc2VydmVyIG51bWJlciBpbiB0aGUgZmFybSwgYW5kIDMy IGJpdCBmb3IgdGhlIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IGNvbm5lY3Rp b24gbnVtYmVyIGluIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2ZXIgYnVpbGRzIHRoYXQgY29ubmVjdGlv biA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyBudW1iZXIgYnkgdXNpbmcgYSAz MiBiaXQgdmFyaWFudCBvZiBGRlguIFRoZSBsb2FkIGJhbGFuY2VyIGFsc28gdXNlcyBhIDxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IDMyIGJpdCB2YXJpYW50LCB1c2luZyB0aGUg bG93ZXIgMzIgYml0IG9mIHRoZSBDSUQgYXMgaW5pdGlhbCB2ZWN0b3IgZm9yDQo8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyB0aGlzIEZGWCBlbmNyeXB0aW9uLiA8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg Jmd0OyBUaGVzZSBhcmUganVzdCB0d28gZXhhbXBsZXMuIEFuZCB5ZXMgeW91IG1heSB3YW50IHRv IGFkZCAyIGJ5dGVzIGZvciBrZXkNCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7 IGlkZW50aWZpY2F0aW9uLCBldGMuIEluIGJvdGggZW5jcnlwdGlvbiBhbGdvcml0aG1zLCB5b3Ug Y2FuIGZlZWQgdGhlc2UgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgdHdvIGJ5 dGVzIGFzIGFkZGl0aW9uYWwgSVYgZm9yIHRoZSBGRlggYWxnb3JpdGhtLiBBbmQgaW4gYm90aCBj YXNlcywgd2UNCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IGFyZSB3ZWxsIGJl bG93IHRoZSAxOCBieXRlIGxpbWl0LiA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyBZZXMsIHRoYXQgcmVxdWlyZXMg c29tZSBjcmVhdGl2ZSBlbmdpbmVlcmluZy4gQnV0IGl0IGlzIG5vdCByb2NrZXIgPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgc2NpZW5jZS4gQW5kIGl0IHNlZW1zIGJldHRlciB0 aGFuIGNhcnJ5aW5nIHRvbnMgb2Ygb3ZlcmhlYWQgaW4gdGhlIDxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7Jmd0OyAmZ3Q7IGhlYWRlciwgYW5kIGJlY29taW5nIGxlc3MgZWZmaWNpZW50IHRoYW4g SFRUUDIvVExTL1RDUC4gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyBJIGFncmVlIHRoYXQgaXQgd291bGQgbm90IGJlIHRoZSBlbmQg b2YgdGhlIHdvcmxkIGZvciB0aGUgbG9hZCA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg YmFsYW5jZXJzIGlmIHdlIGRlY2lkZSB0byBzdGljayBvbiB0aGUgMTgtYnl0ZSBsaW1pdC4gSG93 ZXZlciwgYXMgeW91IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBzdGF0ZSwgaXQgcmVx dWlyZXMgc29tZSBjcmVhdGl2ZW5lc3MuIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgVG8gbWUgaXQgc2VlbXMgdGhhdCB0aGUgcXVl c3Rpb24gaXMgaWYgd2UgaGF2ZSBhIHN0cm9uZyByZWFzb24gdG8gPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsmZ3Q7IHJlcXVpcmUgc29tZSBwZW9wbGUgdG8gYmUgY3JlYXRpdmUsIGZvciBhbGwg dGhlIHZlcnNpb25zIG9mIFFVSUMgaW4gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IHRo ZSBmdXR1cmUuIEkgcGVyc29uYWxseSB0aGluayB0aGF0IHRoZXJlIGlzbid0IGEgc3Ryb25nIHJl YXNvbiwgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IGJlY2F1c2UgcGVvcGxlIGNhbiB1 c2Ugc2hvcnRlciBDSURzIHJlZ2FyZGxlc3Mgb2YgdGhlIGRlY2lzaW9uIHdlIDxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyBtYWtlLiBJSVVDLCB0aGUgb3ZlcmhlYWQgdGhhdCBldmVyeW9u ZSBuZWVkcyB0byBhY2NlcHQgaXM6IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgKiBvbmUgYnl0ZSBpbmNyZWFzZSBpbiB0aGUgbG9u ZyBoZWFkZXIgcGFja2V0cyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgKiB0aGUgbWlu aW11bSBzaXplIG9mIHNob3J0IGhlYWRlciBwYWNrZXRzIGJlY29taW5nIHNsaWdodGx5IGdyZWF0 ZXIgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IChvdGhlcndpc2UsIHRoZSBwZWVyIG1p Z2h0IG5vdCBiZSBhYmxlIHRvIHNlbmQgYSBzdGF0ZWxlc3MgcmVzZXQpIDxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgSSdkIHNheSB0 aGF0IHRoZSBmaXJzdCBidWxsZXQgcG9pbnQgaXMgbmVnbGlnaWJsZS4gVGhlIHNlY29uZCBwb2lu dCA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgY291bGQgYWxzbyBiZSwgYmVjYXVzZSBJ J2QgYXNzdW1lIHRoYXQgdGhlIG9ubHkgZnJlcXVlbnRseS1zZW50IDxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7Jmd0OyBwYWNrZXRzIHRoYXQgcmVxdWlyZSBhZGRpdGlvbmFsIHBhZGRpbmcgaXMg dGhlIEFDSy1vbmx5IHBhY2tldHMsIGJ1dCA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg dGhlcmUncyBubyByZWFzb24gdG8gcGFkIEFDSy1vbmx5IHBhY2tldHMgaW4gaG9wZSB0aGF0IHlv dSdkIHNlZSBhIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBzdGF0ZWxlc3MgcmVzZXQu IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyZndDsgVGhlcmVmb3JlLCBteSAobm90LXNvLXN0cm9uZykgcHJlZmVyZW5jZSBoYXMgYmVlbiB0 byBwcm92aWRlIGV4dHJhIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyByb29tLCBzbyB0 aGF0IHNvbWUgcGVvcGxlIHdpdGggbmVjZXNzaXR5IGNhbiB1c2UgbG9uZ2VyIENJRHMuIDxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyAtLSBDaHJpc3RpYW4gSHVp dGVtYSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IEthenVobyBPa3U8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyZuYnNwOyBBVkUhPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IFBoaWxpcHAgUy4gVGllc2VsPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAtLSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsg UGhpbGlwcCBTLiBUaWVzZWwgPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcGhpbGlwcC50aWVzZWwubmV0 XyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1DMHNVby1M Rk5CYVlmeW9hQ3NmNlRBJmFtcDttPTMtLVZmODN5dVVTdUx0STR4MmVuV1QzdXRTV3p1clF2RFpE VGlfN3RKemMmYW1wO3M9MEVyaDRENm1La0trREMtRXNjbU0ySVotajVPenJROG5qLWJ1cTNxS2E0 byZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vcGhpbGlwcC50aWVzZWwubmV0Lzwv YT48YnI+DQomZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F127DB352E274709A231558C0E151AE3fbcom_-- From nobody Fri Jun 21 13:23:23 2019 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 B9B1C1203BD for ; Fri, 21 Jun 2019 13:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyv40wQI2SJl for ; Fri, 21 Jun 2019 13:23:15 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720123.outbound.protection.outlook.com [40.107.72.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC47F1203C6 for ; Fri, 21 Jun 2019 13:23:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lF8taj8DaQO/Ix3KN1meqAkgLB8HKy+HTloh0QymJ3BCuff2ZmjNQ9ZvWf6N5Vmr+yFLi3glBnmvu8VUr84Fw46nqfuLBnEeGW2rSFvIEtI1W5a/Vx7U17d05r2wPPWmuR028yy2aAig/1jo76nX4Mor/SnM30Hs1oZdjY0RpiFuWK2KVFrSyuLOlT8jMwdDxgDltLQrWa3PeN2Na1Du14b+qRM5sS90gF6Keg80NHAKA1+VGzGt4h7hD9ecaHLEpt4E67cJp5TVEoXEaq6XYXB1xadx1+gO6jDNAz3rFsi4EGSRHbx8W/SYGfJNOWyiijY5QuvkW0DVgQUJ2pRKaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RIgj9CkcpAoxVST7Vau/U8ku2sfHDPce+B+gF8yz5J4=; b=IwmDrplsS9K100Yea5n6q58xQCBzOjfbCjepaB4g1ROAqtrHRM+MgpEZS8xI47HS7jSHD1GQ8nMcZB0iqtRfReruS6tvKU8EHRWnsUEdbrtF+18Oj6ROM8luj0W8FQLXeH4B9dJKyhBw0KdEfuMwW29ux6K245u1+dgmb3FNHjtqDJ8PvkYrcWumiaonHSIH+YqsEUq2qYYQNEzjq9QEZ7Kj2HVt6MV31bS5L0lr50qxqL7bQjoC2RDU8+UGktPiqFH6RB0M06bgbVom5bp8xUikblv/7BAX1dqTHHZaTKTmVH6kvDEyyBXI53lxHvnfyd7qHI4xoCWF4Lii30Blsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=microsoft.com;dmarc=pass action=none header.from=microsoft.com;dkim=pass header.d=microsoft.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RIgj9CkcpAoxVST7Vau/U8ku2sfHDPce+B+gF8yz5J4=; b=jX9J8CDNRmn95Yc5TBHSd7aov4RdlsdVnSvnlYkUSiUavmRV0F3ytEWciC3uS6Fh0ewTUVnH1XjS2oGvkenwJmxpT9LmvfpvNfoJMLcGV2CoQK+p6VU6BwdqFgw2VzohrSeBht0coaWmxciAUHqSw+2pv7yz7kcoSnDlZydZmOc= Received: from BL0PR2101MB1332.namprd21.prod.outlook.com (20.177.244.146) by BL0PR2101MB1106.namprd21.prod.outlook.com (52.132.24.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.6; Fri, 21 Jun 2019 20:23:09 +0000 Received: from BL0PR2101MB1332.namprd21.prod.outlook.com ([fe80::f42f:8fa1:bbe4:51ea]) by BL0PR2101MB1332.namprd21.prod.outlook.com ([fe80::f42f:8fa1:bbe4:51ea%4]) with mapi id 15.20.2032.005; Fri, 21 Jun 2019 20:23:09 +0000 From: Nick Banks To: Roberto Peon , David Schinazi , Ian Swett CC: IETF QUIC WG , Martin Thomson Subject: RE: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORg2Y4WsvhffUetueO/guC+RaaXjl6AgAGE3YCAAA8NgIAABlqAgAC3vwCAAPW4AIAAccKAgAF/iYCAAHVjgIAAkboAgAFTDwCAACtYAIAAI0iAgACS+YCAAATjAIAABjyAgAA7jgCAAIGGgIAAUSyAgALnAQCAAO6YgIABo/UAgAAAkQCAAAVbAIAAAFrA Date: Fri, 21 Jun 2019 20:23:09 +0000 Message-ID: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-06-21T20:23:06.4973940Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a4e00aef-9061-4cef-ba07-34912b948d4a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-originating-ip: [2001:4898:80e8:3:513c:7528:875a:162c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 094f2062-4e16-4e09-3009-08d6f68646fc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1106; x-ms-traffictypediagnostic: BL0PR2101MB1106: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0075CB064E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(366004)(51444003)(199004)(189003)(10290500003)(8676002)(316002)(53936002)(54906003)(55016002)(9686003)(22452003)(6436002)(8990500004)(606006)(110136005)(6306002)(6246003)(66476007)(25786009)(33656002)(478600001)(4326008)(10090500001)(236005)(66446008)(64756008)(229853002)(54896002)(476003)(66946007)(966005)(486006)(76116006)(73956011)(66556008)(7736002)(74316002)(46003)(71190400001)(66574012)(2906002)(71200400001)(81156014)(81166006)(6116002)(30864003)(76176011)(5660300002)(68736007)(52536014)(11346002)(8936002)(14444005)(7696005)(6506007)(790700001)(99286004)(86362001)(53546011)(186003)(102836004)(14454004)(256004)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1106; H:BL0PR2101MB1332.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3bGzdXUPLuSJzpd8UkCJ13jGW6e9CHpFSvaTy69BeXRuqt4j/hOgdWrgVX8wSjG0H/NdSMEpaWOKxAGDvlR0Ok0KYIyo3LfMy4jHXsQrCQBCwhDH29oy6yfq7m/doA4gPOCmYjIo+TIKEVLx6/lowInzsgubjF0bsBHCMdAt9+rbWfN9Un5mels9zHXg9ecUed3y7yNLnvr6/Qx+6Petjjkt+Jm6zjC3LAepDKqtlqAaL+YHp555UgJXZF25XDJ0nuswxEgnwrsdweXzR/fotBRO3ybMPtemSCEDDIn1dAMptns79sINhnY8Rcs6PZSLOkUBW/lfputPktPiztMbYF5bxjSRRWN7M6MgO57lJm5iZRAxL4qifOY8OeEF52BHDi4714epNgSH1SkRWzYjmFc40TRMY3XA/pVtANDFGy0= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB13329389538ABEC55AFE80F9B3E70BL0PR2101MB1332_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 094f2062-4e16-4e09-3009-08d6f68646fc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2019 20:23:09.5155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nibanks@microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1106 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 20:23:21 -0000 --_000_BL0PR2101MB13329389538ABEC55AFE80F9B3E70BL0PR2101MB1332_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lIGFzIHdlbGwuDQoNCi0gTmljaw0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb2JlcnRvIFBlb24NClNlbnQ6IEZyaWRheSwgSnVu ZSAyMSwgMjAxOSAxOjIxIFBNDQpUbzogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtdEBs b3dlbnRyb3B5Lm5ldD4NClN1YmplY3Q6IFJlOiBDb25zZW5zdXMgQ2FsbDogTW9yZSBDb25uZWN0 aW9uIElEIFNwYWNlICMyNzM2DQoNCldvcmtzIGZvciBtZS4NCi09Ug0KDQpGcm9tOiBRVUlDIDxx dWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJl aGFsZiBvZiBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpk c2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdW5lIDIxLCAyMDE5IGF0 IDE6MDIgUE0NClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZzxtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PiwgTWFydGlu IFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PG1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldD4+DQpT dWJqZWN0OiBSZTogQ29uc2Vuc3VzIENhbGw6IE1vcmUgQ29ubmVjdGlvbiBJRCBTcGFjZSAjMjcz Ng0KDQorMSB0byB3aGF0IElhbiBzYWlkLiAoMikgc2VlbXMgbGlrZSBhIGdvb2QgcGF0aCBmb3J3 YXJkDQoNCk9uIEZyaSwgSnVuIDIxLCAyMDE5IGF0IDE6MDAgUE0gSWFuIFN3ZXR0IDxpYW5zd2V0 dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZz4+IHdyb3RlOg0KSSB0aGluayB0aGUgMyBvcHRpb25zIEkgc2VlIGFzIHdlbGwgcmVh c29uZWQgYXJlOg0KMSkgS2VlcCB0aGUgc3RhdHVzIHF1byBiZWNhdXNlIHdlIHRoaW5rIHdlIGNh biBwdXQgd2hhdCB3ZSByZWFsbHkgbmVlZCBpbnRvIDE4IGJ5dGVzIGlmIHdlIHRyeS4NCjIpIENo YW5nZSB0byBhIDEgYnl0ZSBsZW5ndGggcGVyIENJRCBhbmQgYSBtYXggb2YgMjAsIHdoaWNoIGdp dmVzIHVzIGEgZmV3IGV4dHJhIGJ5dGVzIGZvciBjbGVhcnRleHQgc2VydmVyIGlkIGFuZC9vciBr ZXkgcm90YXRpb24vZXRjLg0KMykgQ2hhbmdlIHRvIGEgMSBieXRlIGxlbmd0aCBwZXIgQ0lEIGFu ZCBhIG1heCBvZiAzNiwgYmVjYXVzZSB3ZSB3YW50IGJlIGFibGUgdG8gcHV0IDIgZW5jcnlwdGVk IHJvdXRpbmcgSURzIGluIGEgc2luZ2xlIENJRC4NCg0KMiBpcyBteSBwcmVmZXJyZWQgb3B0aW9u LCB0aG91Z2ggSSBjYW4gbGl2ZSB3aXRoIGVpdGhlciBvZiAxIG9yIDMuDQoNCkRlY2lkaW5nIHNv b25lciB3b3VsZCBiZSBzdHJpY3RseSBiZXR0ZXIgdGhhbiBsYXRlciwgc2luY2UgdGhpcyBpcyBi bG9ja2luZyB1cyhDaHJvbWUvR29vZ2xlKSBhY3R1YWxseSBzdXBwb3J0aW5nIHZhcmxlbiBDSURz Lg0KDQpPbiBUaHUsIEp1biAyMCwgMjAxOSBhdCAyOjU3IFBNIE1hcnRpbiBUaG9tc29uIDxtdEBs b3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93ZW50cm9weS5uZXQ+PiB3cm90ZToNClRoYXQgc2Vl bXMgYSBsaXR0bGUgaGlnaC4gIEkgdGhpbmsgdGhhdCBJYW4ncyBwcmluY2lwbGUgaGVyZSBpcyB3 aGF0IHNob3VsZCBndWlkZSB1czogd2hhdCBpcyB0aGUgbWluaW11bSB5b3UgY2FuIGhhbmRsZT8g IFdoYXQgSSd2ZSBoZWFyZCBpcyB0aGF0IDE4IG1pZ2h0IGhhdmUgYmVlbiB3b3JrYWJsZSwgYnV0 IGl0IHdhcyBSRUFMTFkgY2xvc2UgdG8gdGhlIGVkZ2UgdG8gdGhlIHBvaW50IHRoYXQgeW91IHdl cmVuJ3QgY29uZmlkZW50IGl0IHdhcyBlbm91Z2gsIGV2ZW4gaW4gdGhlIG5lYXIgdGVybS4uICBC dXQgdGhhdCBzdWdnZXN0cyB0aGF0IDIwIGlzIHdvcmthYmxlLg0KDQpPbiBXZWQsIEp1biAxOSwg MjAxOSwgYXQgMjE6NDMsIE1hcnRpbiBEdWtlIHdyb3RlOg0KPiBzbyBkbyBJIGhlYXIgY29uc2Vu c3VzIGVtZXJnaW5nIGFyb3VuZCAzMkIgaW4gdjEsIG9yIHNob3VsZCBJIGxlYXZlIHRoZQ0KPiAx OEIgbGltaXQgaW4gdjEgZm9yIG5vdyBhbmQgcHVudCBvdXQgdGhhdCBkaXNjdXNzaW9uPw0KPg0K PiBPbiBUdWUsIEp1biAxOCwgMjAxOSBhdCAxOjI0IEFNIFBoaWxpcHAgUy4gVGllc2VsIDxwaGls aXBwQHRpZXNlbC5uZXQ8bWFpbHRvOnBoaWxpcHBAdGllc2VsLm5ldD4+IHdyb3RlOg0KPiA+DQo+ ID4NCj4gPiAgPiBPbiAxOC4gSnVuIDIwMTksIGF0IDA1OjMzLCBNYXJ0ZW4gU2VlbWFubiA8bWFy dGVuc2VlbWFubkBnbWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPj4gd3Jv dGU6DQo+ID4gID4NCj4gPiAgPiBJJ2QgcHJlZmVyIGtlZXBpbmcgdGhlICJjb21wcmVzc2VkIDQg Yml0cyIgc29sdXRpb24sIGV2ZW4gaWYgd2UgZGVjaWRlIHRvIGluY3JlYXNlIHRoZSBjb25uZWN0 aW9uIElEIGxlbmd0aCB0byBhIGxhcmdlciB2YWx1ZSAod2hpY2ggSSdtIHN0aWxsIG5vdCBjb252 aW5jZWQgdGhhdCB0aGlzIGlzIHJlYWxseSBuZWNlc3NhcnkpLg0KPiA+DQo+ID4gIFRoaXMgd291 bGQgYmUgZWFzeSBpZiB3ZSBjaGFuZ2UgdGhlIGVuY29kaW5nIG9mIHRoZSBjb25uZWN0aW9uIElE IGxlbmd0aCwgZS4uZy4sIHRvIGJlIERDSUwqNCBhbGxvd2luZyB1cCB0byA2MCBieXRlIGNvbm5l Y3Rpb24gSURzLiBXaGlsZSB3ZSBjYW4gbm90IGVuY29kZSBvbmUgb3IgdHdvIGJ5dGUgY29ubmVj dGlvbiBJRHMgaW4gbG9uZyBoZWFkZXIgcGFja2V0cywgd2UgY2FuIHN0aWxsIHVzZSB0aGVtIGlu IHNob3J0IGhlYWRlciBwYWNrZXRzLg0KPiA+DQo+ID4gIFRoaXMgc3BsaXQgYmV0d2VlbiBsb25n IGFuZCBzaG9ydCBoZWFkZXIgYWxzbyBhbGxvd3MgdG8gdXNlIG11Y2ggbG9uZ2VyIGNvbm5lY3Rp b24gSURzIGFmdGVyIHRoZSBoYW5kc2hha2UuDQo+ID4gIEkgZG9u4oCZdCBzZWUgbXVjaCB1c2Ug aW4gaXQsIGJ1dCBpdCBtYXkgdGFrZSBvZmYgc29tZSBmZWFyIHRoYXQgMjQvMzIvMzYvNDgvNjAg Ynl0ZSBjb25uZWN0aW9uIElEcyBtaWdodCBub3QgYmUgbG9uZyBlbm91Z2ggaW4gdGhlIGZ1dHVy ZS4NCj4gPg0KPiA+ICA+DQo+ID4gID4gVGhlcmUgYXJlIHR3byBtYWluIHJlYXNvbnMgdG8ga2Vl cCB0aGUgY29tcHJlc3NlZCBlbmNvZGluZzoNCj4gPiAgPiDigKIgSW4gdGhlIGNvbXByZXNzZWQg ZW5jb2RpbmcsIHdlIGNhbiByZWFzb25hYmx5IGV4cGVjdCB0aGF0IGFsbCAvIG1vc3QgdmFsdWVz IHdpbGwgYmUgdXNlZCBpbiBwcmFjdGljZSwgc28gd2Ugd29uJ3QgZXhwb3NlIGFueSBiaXRzIG9u IHRoZSB3aXJlIHRoYXQgaWRlbnRpZnkgYSBwYWNrZXQgYXMgIlFVSUMgdHJhZmZpYyIgYnkgaGF2 aW5nIGEgcHJlZGljdGFibGUgdmFsdWUuDQo+ID4gID4g4oCiIFRoZSAxLWJ5dGUgZW5jb2Rpbmcg aGFzIHRoZSBkaXNhZHZhbnRhZ2UgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBzdGlsbCBuZWVkcyB0 byBiZSBhYmxlIHRvIGRlYWwgd2l0aCBjb25uZWN0aW9uIElEIGxlbmd0aHMgb2YgMjU1IGJ5dGVz LCBqdXN0IHRvIGJlIGFibGUgdG8gc2VuZCBWZXJzaW9uIE5lZ290aWF0aW9uIHBhY2tldHMuIFRv IG1lLCBpdCBzZWVtcyBhYnN1cmQgdG8gd3JpdGUgYSBRVUlDIGltcGxlbWVudGF0aW9uIHRoYXQg aXMgYWJsZSB0byBoYW5kbGUgcGFja2V0cyB3aXRoIGEgY29tYmluZWQgY29ubmVjdGlvbiBJRCBv dmVyaGVhZCBvZiA1MTAgYnl0ZXMuIFNpbmNlIFZOUHMgYXJlIHN1cHBvc2VkIHRvIGJlIHNlbnQg aW4gcmVzcG9uc2UgdG8gYW55IExvbmcgSGVhZGVyIHBhY2tldCwgeW91J2QgaGF2ZSB0byBwdXQg c29tZSBjYXJlZnVsIHRob3VnaHQgaW50byB0aGUgZGVzaWduIG9mIHlvdXIgZGF0YSB0eXBlcyB0 byBhdm9pZCB0aGlzIGJlY29taW5nIGEgRG9TIHZlY3Rvci4NCj4gPiAgPg0KPiA+ICA+IE9uIFR1 ZSwgSnVuIDE4LCAyMDE5IGF0IDM6NTAgQU0gQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVp dGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PiB3cm90ZToNCj4gPiAgPiBJIHRv byBhZ3JlZSB0aGF0IHVzaW5nIG9uZSBieXRlIGluIHRoZSBpbnZhcmlhbnQgaXMgcHJlZmVyYWJs ZSB0byB0aGUgY3VycmVudCAiY29tcHJlc3NlZCA0IGJpdHMiIHNvbHV0aW9uLg0KPiA+ICA+DQo+ ID4gID4gUmVnYXJkaW5nIHRoZSAiQ0lEIGxlbmd0aCBsaW1pdCIsIEkgdGhpbmcgdGhlcmUgYXJl IHR3byBpc3N1ZXM6IHRyYW5zbWlzc2lvbiBvdmVyaGVhZCwgYW5kIGNvc3RzIHRvIHRoZSBjb21t dW5pdHkuDQo+ID4gID4NCj4gPiAgPiBJIGFtIG5vdCB0b28gY29uY2VybmVkIHdpdGggdGhlIHRy YW5zbWlzc2lvbiBvdmVyaGVhZCwgYXMgd2UgaGF2ZSB0aGVyZSB0aGUgcmlnaHQgbWl4IG9mIGNv c3RzIGFuZCBpbmNlbnRpdmVzLiBTZXJ2ZXJzIHdobyBjaG9zZSB0byB1c2UgbG9uZ2VyIENJRCB3 aWxsIGdldCBtb3JlIHRyYW5zbWlzc2lvbiBvdmVyaGVhZCwgYW5kIHRodXMgdHJhbnNtaXNzaW9u IGxlc3MgZWZmaWNpZW50bHkgdGhhbiB0aGVpciBjb21wZXRpdG9ycy4gVGhleSBtYXkgY2hvc2Ug dG8gdXNlIGxvbmdlciBDSUQgYXMgYSB0cmFkZS1vZmYgYmV0d2VlbiB0cmFuc21pc3Npb24gZWZm aWNpZW5jeSBhbmQgZWFzZSBvZiBtYW5hZ2VtZW50LiBDb21wZXRpdGlvbiB3aWxsIHNvcnQgdGhh dCBvdXQuIEkgbm90ZSB0aGF0IFlvdVR1YmUgaXMgYXBwYXJlbnRseSBkb2luZyBmaW5lIHdpdGgg c21hbGxpc2ggQ0lELCBzbyBJIHRydXN0IHRoYXQgdGhlcmUgd2lsbCBiZSBjb21wZXRpdGlvbi4N Cj4gPiAgPg0KPiA+ICA+IEkgYW0gbXVjaCBtb3JlIGNvbmNlcm5lZCB3aXRoIHRoZSBzaGFyZWQg Y29zdHMsIHdoaWNoIGFyZSBhIHZhcmlhdGlvbiBvZiB0aGUgInRyYWdlZHkgb2YgdGhlIGNvbW1v bnMiLiBEbWl0cnkgZXhwbGFpbmVkIHRob3NlIGNvc3RzIHdlbGwgaW4gYSBwcmV2aW91cyBtZXNz YWdlLiBUaGUgc2ltcGxlciBpbXBsZW1lbnRhdGlvbiBpcyB0byBtYWtlIHRoZSAiY2lkX3QgYSBm aXhlZC1zaXplIG9iamVjdCB0aGF0IGNhbiBmaXQgdGhlIGxhcmdlc3QgQ0lEIGFuZCBlYXQgdGhl IG92ZXJoZWFkIGZvciBhbGwgQ0lEcy4iIEJ1dCBlYWNoIGNvbm5lY3Rpb24gb2JqZWN0IGNhcnJp ZXMgYSBsYXJnZSBudW1iZXIgb2YgaW5zdGFuY2VzIG9mIHRoZSBDSUQgdHlwZS4gSGF2aW5nIGEg dmVyeSBsYXJnZSBtYXggQ0lEIHdvdWxkIGltcGx5IGEgbGFyZ2Ugb3ZlcmhlYWQuIFRoZSBhbHRl cm5hdGl2ZSBpcyB0byAiTWFrZSBjaWRfdCBhIHZhcmlhYmxlLXNpemUgb2JqZWN0IiwgYnV0IHRv byBhZmZlY3RzIHBlcmZvcm1hbmNlLg0KPiA+ICA+DQo+ID4gID4gSGVuY2UgdGhlIHB1c2gtYmFj ay4gSSB3b3VsZCBwZXJzb25hbGx5IHByZWZlciBhIG1heCBzaXplIG9mIDE2LCBhbmQgSSB0aGlu ayB0aGF0IDMyIGlzIHRoZSBoaWdoZXN0IHByYWN0aWNhbCBsaW1pdC4NCj4gPiAgPg0KPiA+ICA+ IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+ID4gID4NCj4gPiAgPiBPbiA2LzE3LzIwMTkgOToxNiBB TSwgUm9iZXJ0byBQZW9uIHdyb3RlOg0KPiA+ICA+PiBXaGF0IEkgdGhpbmsgcGVvcGxlIGFyZSBz YXlpbmcgc28gZmFyOg0KPiA+ICA+Pg0KPiA+ICA+PiAxKSBRVUlDIHYxIHdvdWxkIGxpbWl0IENJ RCBsZW5ndGggdG8gc29tZXRoaW5nIG9uZSBvZiB7MzIsIDM2LCBvciA0OH0NCj4gPiAgPj4NCj4g PiAgPj4gMikgUmVwcmVzZW50YXRpb24gb2YgQ0lEIGxlbmd0aCBhcyBhIGJ5dGUgaXMgc3RpbGwg T0ssIHRodXMgYSBRVUlDIHYyIGNvdWxkIHVzZSBsb25nZXIgQ0lEcyBhcyBuZWVkZWQgYnkgY2hh bmdpbmcgdGhlIHNwZWMgd2hpbGUga2VlcGluZyB0aGUgaW52YXJpYW50c+KApiBpbnZhcmlhbnQu DQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IFRoYXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSAv IEnigJlkIHN0aWxsIHN1cHBvcnQgdGhhdC4NCj4gPiAgPj4NCj4gPiAgPj4gLT1SDQo+ID4gID4+ DQo+ID4gID4+DQo+ID4gID4+IEZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86cXVpYy1ib3VuY2VzQGlldGYuLi5vcmc+PiBvbiBiZWhhbGYgb2YgIkx1YmFzaGV2LCBJZ29y IiA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+DQo+ID4g ID4+IERhdGU6IE1vbmRheSwgSnVuZSAxNywgMjAxOSBhdCA4OjU1IEFNDQo+ID4gID4+IFRvOiBJ YW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1p a2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4NCj4gPiAgPj4gQ2M6 IERtaXRyaSBUaWtob25vdiA8ZHRpa2hvbm92QGxpdGVzcGVlZHRlY2guY29tPG1haWx0bzpkdGlr aG9ub3ZAbGl0ZXNwZWVkdGVjaC5jb20+PiwgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVp dGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PiwgIlBoaWxpcHAgUy4gVGllc2Vs IiA8cGhpbGlwcEB0aWVzZWwubmV0PG1haWx0bzpwaGlsaXBwQHRpZXNlbC5uZXQ+PiwgTWlrZSBC aXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+ LCBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ8bWFpbHRvOm10QGxvd2VudHJvcHku bmV0Pj4sIE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86bWFy dGVuc2VlbWFubkBnbWFpbC5jb20+PiwgTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZzxtYWls dG86bGFyc0BlZ2dlcnQub3JnPj4sIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNA aWV0Zi5vcmc+PiwgTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPG1haWx0bzpt YXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4gPG1haWx0bzptYXJ0aW4uLmguZHVrZUBnbWFpbC5jb208 bWFpbHRvOm1hcnRpbi4uaC5kdWtlQGdtYWlsLmNvbT4+PiwgS2F6dWhvIE9rdSA8a2F6dWhvb2t1 QGdtYWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+DQo+ID4gID4+IFN1YmplY3Q6 IFJFOiBDb25zZW5zdXMgQ2FsbDogTW9yZSBDb25uZWN0aW9uIElEIFNwYWNlICMyNzM2DQo+ID4g ID4+DQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IE15IHRha2UgaXMgc2ltaWxhciDigJMgNDgg aXMgcHJvYmFibHkgZXhjZXNzaXZlLCB3aGlsZSAzMiBpcyBsaWtlbHkgdGhlIHVwcGVyIGxpbWl0 IG9mIOKAnHJlYXNvbmFibGXigJ0gKGl0IHNob3VsZCBwcm9iYWJseSBiZSBhIGZhY3RvciBvZiA4 LCBzbyAzMiBvciAyND8pLg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+PiBXZSBh cmUgZmlybWx5IGNvbW1pdHRlZCBmb3IgdXNpbmcgQ0lEIGZvciBpbi1jbHVzdGVyIGxvYWQgYmFs YW5jaW5nIC8gYW55Y2FzdCBwb3Agcm91dGluZy4gVGhpcyBkaXNjdXNzaW9uIGlzIHRha2luZyB1 cywgaG93ZXZlciwgdG8gYSBuZXcgdGVycml0b3J5IOKAkyBhIGdlbmVyYWxpemVkIOKAnGRlc3Rp bmF0aW9uLWNvbnRyb2xsZWQgcm91dGluZyBpbiBhbiBvdmVybGF5IG5ldHdvcmvigJ0uIFRoaXMg aXMgYSB2ZXJ5IGludGVyZXN0aW5nIHRvcGljLCBidXQgSSB3b3VsZCBoZXNpdGF0ZSB0byBhdHRl bXB0IHRvIHNvbHZlIGl0IGZ1bGx5IGFuZCDigJxpbiBnZW5lcmFs4oCdIGluIFFVSUMgdjEuDQo+ ID4gID4+DQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IOKAoiBJZ29yDQo+ID4gID4+DQo+ID4g ID4+DQo+ID4gID4+IEZyb206IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KPiA+ICA+Pg0K PiA+ICA+PiBNeSBpbnR1aXRpb24gc2F5cyBtYWtpbmcgdGhlIGNoYW5nZSB0byB0aGUgaW52YXJp YW50cyBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIGJ1dCBJIGRvbid0IGZlZWwgdGhhdCBzdHJv bmdseS4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4gSG93ZXZlciwgSSdkIGxp a2UgdGhlIG1heCBzaXplIHRvIGJlIHNtYWxsZXIgdGhhbiA0OChidXQgbGFyZ2VyIHRoYW4gMTgp LiBJZiB3ZSB0aGluayAyMCBvciAyNCBpcyBzdWZmaWNpZW50LCBJJ2QgcHJlZmVyIHRoYXQuIEth enVobyBzdWdnZXN0ZWQgMzIsIHdoaWNoIGlzIGJldHRlciwgYnV0IEkgZG9uJ3QgYmVsaWV2ZSB0 aGUgc2VydmVyIG5lZWRzIHRvIHVzZSBhIHNlcGFyYXRlIGJsb2NrIGNpcGhlciB3aGVuIGdpdmlu ZyBvdXQgY29ubmVjdGlvbiBJRHMsIGJlY2F1c2UgSSBiZWxpZXZlIGl0J3MgaW1wcmFjdGljYWwg Zm9yIHRoZSBsb2FkIGJhbGFuY2VyIGFuZCBzZXJ2ZXIgdG8gYmUgdGhhdCBkZWNvdXBsZWQuIFRo ZSBzZXJ2ZXIgaGFzIHRvIGdpdmUgb3V0IGEgQ0lEIHRoYXQgdGhlIGxvYWQgYmFsYW5jZXIgd2ls bCB1c2UgdG8gcm91dGUgYmFjayB0byB0aGUgc2VydmVyLCBzbyB0aGV5IGhhdmUgdG8gc2hhcmUg ZW5vdWdoIGFuIGVuY3J5cHRpb24ga2V5L2FsZ29yaXRobS4gSSBjYW4gaW1hZ2luZSBuZXN0aW5n IGxvYWQgYmFsYW5jZXJzLCBidXQgdGhhdCdzIHdlbGwgaW4gdGhlIHJhbmdlIG9mIFFVSUMgdjIg ZnJvbSBteSBwZXJzcGVjdGl2ZS4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4g V2hhdGV2ZXIgd2UgZG8sIEknZCByZWFsbHkgcHJlZmVyIHRvIHJlc29sdmUgdGhpcyBzb29uZXIg cmF0aGVyIHRoYW4gbGF0ZXIgYW5kIGJlIHRydWx5IGRvbmUgd2l0aCBpdC4NCj4gPiAgPj4NCj4g PiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4gT24gTW9uLCBKdW4gMTcsIDIwMTkgYXQgMjo1MSBBTSBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tl bGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+ICA+Pg0KPiA+ICA+PiBTaW5jZSBpdCBpcyBtb3Jl IGxpa2VseSB0aGF0IHlvdSBwYXkgZm9yIGVncmVzcyB0cmFmZmljIHRoYW4gaW5ncmVzcyB0cmFm ZmljLCB0aGUgbW90aXZhdGlvbiB0byBrZWVwIENJROKAmXMgc21hbGwgaXMgbGltaXRlZC4NCj4g PiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4gSSBkbyB0aGluayB0aGUgaW52YXJpYW50 cyBzaG91bGQgYWxsb3cgZm9yIGxvbmcgQ0lE4oCZcyBhcyBwcm9wb3NlZCwgYW5kIHRoYXQgdGhl IGxvbmcgaGVhZGVyIG92ZXJoZWFkIGlzIG5vdCBpbXBvcnRhbnQuLi4NCj4gPiAgPj4NCj4gPiAg Pj4NCj4gPiAgPj4NCj4gPiAgPj4gQnV0IGZvciBRVUlDIHYxLCBpZiB3ZSBhbGxvdyBmb3IgYSBs b25nIENJRCwgYSBydXNoIHRvIG1hcmtldCB3aWxsIHNldCBwcmVjZWRlbmNlIGFuZCBsb25nIENJ ROKAmXMgd2lsbCBvc3NpZnkgaW4gYWxsIGtpbmRzIG9mIHN0YWNrcy4NCj4gPiAgPj4NCj4gPiAg Pj4NCj4gPiAgPj4NCj4gPiAgPj4gSSBnb29kIHJlZmVyZW5jZSBvbiBhbiBhbGdvcml0aG0gbGlr ZSBzdWdnZXN0ZWQgYnkgQ2hyaXN0aWFuIHdvdWxkIGdvIGEgbG9uZyB3YXkuDQo+ID4gID4+DQo+ ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IElmIENJRCBsZW5ndGggMTggdHVybnMgb3V0IHRvIGJl IG5vdCBlbm91Z2gsIHdlIGNhbiBhZGQgYSBRVUlDIHYyLiBJdOKAmXMgbm90IGxpa2Ugd2UgYXJl IG5vdCBsb29raW5nIGZvciBleGN1c2VzIHRvIHVwZ3JhZGUgUVVJQyB2ZXJzaW9ucyBzb29uLg0K PiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+Pg0KPiA+ICA+PiBJZiBDSUQgbGVuZ3RoIG5lZ290aWF0 aW9uIGlzIG5lZWRlZCwgdGhpcyBjb3VsZCBiZSBkb25lIHZpYSBRVUlDIHZlcnNpb25zLiBGb3Ig ZXhhbXBsZSB0d28gZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgdmVyc2lvbnMsIGJ1dCBvbmUgd2l0 aCBsb25nZXIgQ0lE4oCZcy4gVGhpcyB3b3VsZCBhbHNvIGFsbG93IHJvdXRlcnMgdG8gZGVhbCB3 aXRoIGNoYW5nZXMgaW4gQ0lEIGxlbmd0aHMuIEEgbmVnb3RpYXRlZCBUUCB3b3VsZCBub3QgKGVh c2lseSkgYWxsb3cgZm9yIHRoYXQgYW5kIGFzaWRlIEkgZG8gbm90IHRoaW5rIENJRCBsZW5ndGgg aW4gVFAgaXMgdGhlIHdheSB0byBnby4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAgPj4NCj4gPiAg Pj4gTWlra2VsDQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+DQo+ID4gID4+IE9uIDE3IEp1bmUg MjAxOSBhdCAwNi40NS4wNCwgS2F6dWhvIE9rdSAoa2F6dWhvb2t1QGdtYWlsLmNvbTxtYWlsdG86 a2F6dWhvb2t1QGdtYWlsLmNvbT4pIHdyb3RlOg0KPiA+ICA+Pg0KPiA+ICA+PiAyMDE55bm0Nuac iDE35pelKOaciCkgMTE6MDkgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8 bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjoNCj4gPiAgPj4gPg0KPiA+ICA+PiA+IE9uIDYv MTUvMjAxOSAxMDo1NSBQTSwgS2F6dWhvIE9rdSB3cm90ZToNCj4gPiAgPj4gPg0KPiA+ICA+PiA+ ID4gX0lmXyB3ZSBhcmUgdG8gYWxsb3cgbG9vc2UgY291cGxpbmcgYmV0d2VlbiBhIGxvYWQgYmFs YW5jZXIgYW5kIGENCj4gPiAgPj4gPiA+IHNlcnZlciwgZWFjaCBvZiB0aGUgdHdvIHNob3VsZCBi ZSBnaXZlbiB0aGUgZnJlZWRvbSB0byBjaG9vc2UgaXQncyBvd24NCj4gPiAgPj4gPiA+IENJRCBl bmNyeXB0aW9uIHNjaGVtZS4gQmVjYXVzZSBhbGwgdGhlIHN0YW5kYXJkaXplZCBibG9jayBjaXBo ZXJzIGFyZQ0KPiA+ICA+PiA+ID4gbm93IDEyOC1iaXRzICg9IDE2IGJ5dGVzKSwgdGhhdCBuYXR1 cmFsbHkgbWVhbnMgdGhhdCB0aGUgbWF4aW11bSBDSUQNCj4gPiAgPj4gPiA+IGxlbmd0aCBvZiBR VUlDIG5lZWRzIHRvIGJlIGRvdWJsZSBhbW91bnQgb2YgdGhhdCwgcGx1cyBvbmUgb3IgdHdvDQo+ ID4gID4+ID4gPiBieXRlcyBmb3IgZWFjaCBvZiB0aGUgdHdvIGZvciBpZGVudGlmeWluZyB0aGUg Q0lEIGVuY3J5cHRpb24ga2V5cy4gRm9yDQo+ID4gID4+ID4gPiBrZXkgaWRlbnRpZmljYXRpb24g YW5kIG90aGVyIHN1cHBsZW1lbnRhbCB1c2UsIHdlIGN1cnJlbnRseSBhbGxvY2F0ZSAyDQo+ID4g ID4+ID4gPiBieXRlcyAoMTgtMTY9MikuDQo+ID4gID4+ID4NCj4gPiAgPj4gPiBUaGF0IHJlYXNv bmluZyBpcyBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IGJvdGggdGhlIGxvYWQgYmFsYW5j ZXINCj4gPiAgPj4gPiBhbmQgdGhlIHNlcnZlciBtdXN0IHVzZSBhIGJsb2NrIGNpcGhlciB3aXRo IDEyOCBiaXQgYmxvY2sgbGVuZ3RoIGluDQo+ID4gID4+ID4gb3JkZXIgdG8gZW5jcnlwdCB0aGUg Q0lELiBJZiB0aGV5IHdlcmUgY29uc3RyYWluZWQgdG8gc3RheSB3aXRoaW4gYQ0KPiA+ICA+PiA+ IHNob3J0IGdsb2JhbCBsaW1pdCwgdGhleSBjb3VsZCB1c2UgZGlmZmVyZW50IHNldHMgb2YgYWxn b3JpdGhtcy4NCj4gPiAgPj4gPg0KPiA+ICA+PiA+IEFzc3VtZSBmb3IgZXhhbXBsZSB0aGF0IHdl IHNwbGl0IHRoZSBDSUQgYmV0d2VlbiAzMiBiaXRzIGVuY29kaW5nIHRoZQ0KPiA+ICA+PiA+IG51 bWJlciBvZiB0aGUgc2VydmVyIGluIHRoZSBzZXJ2ZXIgZmFybSwgYW5kIDY0IGJpdCBlbmNvZGlu ZyB0aGUNCj4gPiAgPj4gPiBjb25uZWN0aW9uIG51bWJlciBmb3IgdGhlIHNlcnZlci4gVGhlIHNl cnZlciBjYW4gcGljayBhIHJhbmRvbSB2YWx1ZSBmb3INCj4gPiAgPj4gPiB0aGUgY29ubmVjdGlv biBudW1iZXIsIGFuZCB1c2UgYSBoYXNoIHRhYmxlLiBUaGUgbG9hZCBiYWxhbmNlciBjb3VsZCB1 c2UNCj4gPiAgPj4gPiBhIDMyIGJpdCB2YXJpYW50IG9mIHRoZSBGRlggYWxnb3JpdGhtLCB1c2lu ZyB0aGUgbG93ZXIgNjQgYml0IG9mIHRoZSBDSUQNCj4gPiAgPj4gPiBhcyBhbiBpbml0aWFsIHZl Y3Rvci4gVm9pbGEsIDk2IENJRCwgd2l0aCBkZW1vbnN0cmFibHkgc3Ryb25nIGVuY3J5cHRpb24u DQo+ID4gID4+ID4NCj4gPiAgPj4gPiBPciBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdhbnRzIHRv IHVzZSBzaG9ydCBDSUQuIFdlIG5vdyBzcGxpdCB0aGUgQ0lEDQo+ID4gID4+ID4gYmV0d2VlbiAz MiBiaXQgZm9yIHRoZSBzZXJ2ZXIgbnVtYmVyIGluIHRoZSBmYXJtLCBhbmQgMzIgYml0IGZvciB0 aGUNCj4gPiAgPj4gPiBjb25uZWN0aW9uIG51bWJlciBpbiB0aGUgc2VydmVyLiBUaGUgc2VydmVy IGJ1aWxkcyB0aGF0IGNvbm5lY3Rpb24NCj4gPiAgPj4gPiBudW1iZXIgYnkgdXNpbmcgYSAzMiBi aXQgdmFyaWFudCBvZiBGRlguIFRoZSBsb2FkIGJhbGFuY2VyIGFsc28gdXNlcyBhDQo+ID4gID4+ ID4gMzIgYml0IHZhcmlhbnQsIHVzaW5nIHRoZSBsb3dlciAzMiBiaXQgb2YgdGhlIENJRCBhcyBp bml0aWFsIHZlY3RvciBmb3INCj4gPiAgPj4gPiB0aGlzIEZGWCBlbmNyeXB0aW9uLg0KPiA+ICA+ PiA+DQo+ID4gID4+ID4gVGhlc2UgYXJlIGp1c3QgdHdvIGV4YW1wbGVzLiBBbmQgeWVzIHlvdSBt YXkgd2FudCB0byBhZGQgMiBieXRlcyBmb3Iga2V5DQo+ID4gID4+ID4gaWRlbnRpZmljYXRpb24s IGV0Yy4gSW4gYm90aCBlbmNyeXB0aW9uIGFsZ29yaXRobXMsIHlvdSBjYW4gZmVlZCB0aGVzZQ0K PiA+ICA+PiA+IHR3byBieXRlcyBhcyBhZGRpdGlvbmFsIElWIGZvciB0aGUgRkZYIGFsZ29yaXRo bS4gQW5kIGluIGJvdGggY2FzZXMsIHdlDQo+ID4gID4+ID4gYXJlIHdlbGwgYmVsb3cgdGhlIDE4 IGJ5dGUgbGltaXQuDQo+ID4gID4+ID4NCj4gPiAgPj4gPiBZZXMsIHRoYXQgcmVxdWlyZXMgc29t ZSBjcmVhdGl2ZSBlbmdpbmVlcmluZy4gQnV0IGl0IGlzIG5vdCByb2NrZXINCj4gPiAgPj4gPiBz Y2llbmNlLiBBbmQgaXQgc2VlbXMgYmV0dGVyIHRoYW4gY2FycnlpbmcgdG9ucyBvZiBvdmVyaGVh ZCBpbiB0aGUNCj4gPiAgPj4gPiBoZWFkZXIsIGFuZCBiZWNvbWluZyBsZXNzIGVmZmljaWVudCB0 aGFuIEhUVFAyL1RMUy9UQ1AuDQo+ID4gID4+DQo+ID4gID4+IEkgYWdyZWUgdGhhdCBpdCB3b3Vs ZCBub3QgYmUgdGhlIGVuZCBvZiB0aGUgd29ybGQgZm9yIHRoZSBsb2FkDQo+ID4gID4+IGJhbGFu Y2VycyBpZiB3ZSBkZWNpZGUgdG8gc3RpY2sgb24gdGhlIDE4LWJ5dGUgbGltaXQuIEhvd2V2ZXIs IGFzIHlvdQ0KPiA+ICA+PiBzdGF0ZSwgaXQgcmVxdWlyZXMgc29tZSBjcmVhdGl2ZW5lc3MuDQo+ ID4gID4+DQo+ID4gID4+IFRvIG1lIGl0IHNlZW1zIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIGlmIHdl IGhhdmUgYSBzdHJvbmcgcmVhc29uIHRvDQo+ID4gID4+IHJlcXVpcmUgc29tZSBwZW9wbGUgdG8g YmUgY3JlYXRpdmUsIGZvciBhbGwgdGhlIHZlcnNpb25zIG9mIFFVSUMgaW4NCj4gPiAgPj4gdGhl IGZ1dHVyZS4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgdGhlcmUgaXNuJ3QgYSBzdHJvbmcgcmVh c29uLA0KPiA+ICA+PiBiZWNhdXNlIHBlb3BsZSBjYW4gdXNlIHNob3J0ZXIgQ0lEcyByZWdhcmRs ZXNzIG9mIHRoZSBkZWNpc2lvbiB3ZQ0KPiA+ICA+PiBtYWtlLiBJSVVDLCB0aGUgb3ZlcmhlYWQg dGhhdCBldmVyeW9uZSBuZWVkcyB0byBhY2NlcHQgaXM6DQo+ID4gID4+DQo+ID4gID4+ICogb25l IGJ5dGUgaW5jcmVhc2UgaW4gdGhlIGxvbmcgaGVhZGVyIHBhY2tldHMNCj4gPiAgPj4gKiB0aGUg bWluaW11bSBzaXplIG9mIHNob3J0IGhlYWRlciBwYWNrZXRzIGJlY29taW5nIHNsaWdodGx5IGdy ZWF0ZXINCj4gPiAgPj4gKG90aGVyd2lzZSwgdGhlIHBlZXIgbWlnaHQgbm90IGJlIGFibGUgdG8g c2VuZCBhIHN0YXRlbGVzcyByZXNldCkNCj4gPiAgPj4NCj4gPiAgPj4gSSdkIHNheSB0aGF0IHRo ZSBmaXJzdCBidWxsZXQgcG9pbnQgaXMgbmVnbGlnaWJsZS4gVGhlIHNlY29uZCBwb2ludA0KPiA+ ICA+PiBjb3VsZCBhbHNvIGJlLCBiZWNhdXNlIEknZCBhc3N1bWUgdGhhdCB0aGUgb25seSBmcmVx dWVudGx5LXNlbnQNCj4gPiAgPj4gcGFja2V0cyB0aGF0IHJlcXVpcmUgYWRkaXRpb25hbCBwYWRk aW5nIGlzIHRoZSBBQ0stb25seSBwYWNrZXRzLCBidXQNCj4gPiAgPj4gdGhlcmUncyBubyByZWFz b24gdG8gcGFkIEFDSy1vbmx5IHBhY2tldHMgaW4gaG9wZSB0aGF0IHlvdSdkIHNlZSBhDQo+ID4g ID4+IHN0YXRlbGVzcyByZXNldC4NCj4gPiAgPj4NCj4gPiAgPj4gVGhlcmVmb3JlLCBteSAobm90 LXNvLXN0cm9uZykgcHJlZmVyZW5jZSBoYXMgYmVlbiB0byBwcm92aWRlIGV4dHJhDQo+ID4gID4+ IHJvb20sIHNvIHRoYXQgc29tZSBwZW9wbGUgd2l0aCBuZWNlc3NpdHkgY2FuIHVzZSBsb25nZXIg Q0lEcy4NCj4gPiAgPj4NCj4gPiAgPj4gPg0KPiA+ICA+PiA+IC0tIENocmlzdGlhbiBIdWl0ZW1h DQo+ID4gID4+ID4NCj4gPiAgPj4gPg0KPiA+ICA+PiA+DQo+ID4gID4+DQo+ID4gID4+DQo+ID4g ID4+DQo+ID4gID4+IC0tDQo+ID4gID4+IEthenVobyBPa3UNCj4gPiAgPj4NCj4gPg0KPiA+ICBB VkUhDQo+ID4gIFBoaWxpcHAgUy4gVGllc2VsDQo+ID4NCj4gPiAgLS0NCj4gPiAgUGhpbGlwcCBT LiBUaWVzZWwNCj4gPiBodHRwczovL3BoaWxpcHAudGllc2VsLm5ldC88aHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19waGlsaXBwLnRp ZXNlbC5uZXRfJTI2ZCUzRER3TUZhUSUyNmMlM0Q1VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JTI2ciUz REMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEElMjZtJTNEMy0tVmY4M3l1VVN1THRJNHgyZW5XVDN1dFNX enVyUXZEWkRUaV83dEp6YyUyNnMlM0QwRXJoNEQ2bUtrS2tEQy1Fc2NtTTJJWi1qNU96clE4bmot YnVxM3FLYTRvJTI2ZSUzRCZkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNvbSU3 QzEzZmFlOTI5ZjQzMjQ3OTYxYWFhMDhkNmY2ODYxNTg4JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk2NzQ1MzEwNTIyOTgyNSZzZGF0YT1CbDFBRHB0eW9T QlN5Uk9NRzZ1MEc5RFE4ME5pdUlXdWV4cDBxdUp0TnR3JTNEJnJlc2VydmVkPTA+DQo+ID4NCg== --_000_BL0PR2101MB13329389538ABEC55AFE80F9B3E70BL0PR2101MB1332_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V29ya3MgZm9yIG1lIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g TmljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+ T24gQmVoYWxmIE9mIDwvYj4NClJvYmVydG8gUGVvbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEp1bmUgMjEsIDIwMTkgMToyMSBQTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0 O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHQ9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0O210QGxvd2VudHJvcHku bmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ29uc2Vuc3VzIENhbGw6IE1vcmUgQ29u bmVjdGlvbiBJRCBTcGFjZSAjMjczNjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V29ya3MgZm9yIG1lLjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERhdmlkIFNj aGluYXppICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIj5kc2No aW5hemkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEp1 bmUgMjEsIDIwMTkgYXQgMTowMiBQTTxicj4NCjxiPlRvOiA8L2I+SWFuIFN3ZXR0ICZsdDs8YSBo cmVmPSJtYWlsdG86aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIj5pYW5zd2V0 dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SUVU RiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9y ZzwvYT4mZ3Q7LCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJv cHkubmV0Ij5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBDb25zZW5zdXMgQ2FsbDogTW9yZSBDb25uZWN0aW9uIElEIFNwYWNlICMyNzM2PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz OzEgdG8gd2hhdCBJYW4gc2FpZC4gKDIpIHNlZW1zIGxpa2UgYSBnb29kIHBhdGggZm9yd2FyZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4g MjEsIDIwMTkgYXQgMTowMCBQTSBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0PTxhIGhyZWY9Im1haWx0 bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRoaW5rIHRoZSAzIG9wdGlvbnMgSSBzZWUgYXMgd2VsbCByZWFzb25lZCBhcmU6IDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIEtlZXAgdGhlIHN0 YXR1cyBxdW8gYmVjYXVzZSB3ZSB0aGluayB3ZSBjYW4gcHV0IHdoYXQgd2UgcmVhbGx5IG5lZWQg aW50byAxOCBieXRlcyBpZiB3ZSB0cnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4yKSBDaGFuZ2UgdG8gYSAxIGJ5dGUgbGVuZ3RoIHBlciBDSUQg YW5kIGEgbWF4IG9mIDIwLCB3aGljaCBnaXZlcyB1cyBhIGZldyBleHRyYSBieXRlcyBmb3IgY2xl YXJ0ZXh0IHNlcnZlciBpZCBhbmQvb3Iga2V5IHJvdGF0aW9uL2V0Yy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIENoYW5nZSB0byBhIDEgYnl0 ZSBsZW5ndGggcGVyIENJRCBhbmQgYSBtYXggb2YgMzYsIGJlY2F1c2Ugd2Ugd2FudCBiZSBhYmxl IHRvIHB1dCAyIGVuY3J5cHRlZCByb3V0aW5nIElEcyBpbiBhIHNpbmdsZSBDSUQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIgaXMgbXkgcHJl ZmVycmVkIG9wdGlvbiwgdGhvdWdoIEkgY2FuIGxpdmUgd2l0aCBlaXRoZXIgb2YgMSBvciAzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWNp ZGluZyBzb29uZXIgd291bGQgYmUgc3RyaWN0bHkgYmV0dGVyIHRoYW4gbGF0ZXIsIHNpbmNlIHRo aXMgaXMgYmxvY2tpbmcgdXMoQ2hyb21lL0dvb2dsZSkgYWN0dWFsbHkgc3VwcG9ydGluZyB2YXJs ZW4gQ0lEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBKdW4gMjAsIDIwMTkgYXQgMjo1NyBQTSBNYXJ0aW4gVGhvbXNvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0IiB0YXJnZXQ9Il9ibGFuayI+bXRAbG93 ZW50cm9weS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYXQgc2VlbXMgYSBsaXR0bGUg aGlnaC4mbmJzcDsgSSB0aGluayB0aGF0IElhbidzIHByaW5jaXBsZSBoZXJlIGlzIHdoYXQgc2hv dWxkIGd1aWRlIHVzOiB3aGF0IGlzIHRoZSBtaW5pbXVtIHlvdSBjYW4gaGFuZGxlPyZuYnNwOyBX aGF0IEkndmUgaGVhcmQgaXMgdGhhdCAxOCBtaWdodCBoYXZlIGJlZW4gd29ya2FibGUsIGJ1dCBp dCB3YXMgUkVBTExZIGNsb3NlIHRvIHRoZQ0KIGVkZ2UgdG8gdGhlIHBvaW50IHRoYXQgeW91IHdl cmVuJ3QgY29uZmlkZW50IGl0IHdhcyBlbm91Z2gsIGV2ZW4gaW4gdGhlIG5lYXIgdGVybS4uJm5i c3A7IEJ1dCB0aGF0IHN1Z2dlc3RzIHRoYXQgMjAgaXMgd29ya2FibGUuPGJyPg0KPGJyPg0KT24g V2VkLCBKdW4gMTksIDIwMTksIGF0IDIxOjQzLCBNYXJ0aW4gRHVrZSB3cm90ZTo8YnI+DQomZ3Q7 IHNvIGRvIEkgaGVhciBjb25zZW5zdXMgZW1lcmdpbmcgYXJvdW5kIDMyQiBpbiB2MSwgb3Igc2hv dWxkIEkgbGVhdmUgdGhlIDxicj4NCiZndDsgMThCIGxpbWl0IGluIHYxIGZvciBub3cgYW5kIHB1 bnQgb3V0IHRoYXQgZGlzY3Vzc2lvbj88YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gVHVlLCBKdW4g MTgsIDIwMTkgYXQgMToyNCBBTSBQaGlsaXBwIFMuIFRpZXNlbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWxpcHBAdGllc2VsLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnBoaWxpcHBAdGllc2VsLm5ldDwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgT24gMTguIEp1biAyMDE5LCBhdCAwNTozMywgTWFydGVuIFNlZW1hbm4g Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSSdkIHByZWZlciBrZWVwaW5n IHRoZSAmcXVvdDtjb21wcmVzc2VkIDQgYml0cyZxdW90OyBzb2x1dGlvbiwgZXZlbiBpZiB3ZSBk ZWNpZGUgdG8gaW5jcmVhc2UgdGhlIGNvbm5lY3Rpb24gSUQgbGVuZ3RoIHRvIGEgbGFyZ2VyIHZh bHVlICh3aGljaCBJJ20gc3RpbGwgbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgaXMgcmVhbGx5IG5l Y2Vzc2FyeSkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyBUaGlzIHdvdWxk IGJlIGVhc3kgaWYgd2UgY2hhbmdlIHRoZSBlbmNvZGluZyBvZiB0aGUgY29ubmVjdGlvbiBJRCBs ZW5ndGgsIGUuLmcuLCB0byBiZSBEQ0lMKjQgYWxsb3dpbmcgdXAgdG8gNjAgYnl0ZSBjb25uZWN0 aW9uIElEcy4gV2hpbGUgd2UgY2FuIG5vdCBlbmNvZGUgb25lIG9yIHR3byBieXRlIGNvbm5lY3Rp b24gSURzIGluIGxvbmcgaGVhZGVyIHBhY2tldHMsIHdlIGNhbiBzdGlsbCB1c2UgdGhlbSBpbiBz aG9ydCBoZWFkZXIgcGFja2V0cy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 IFRoaXMgc3BsaXQgYmV0d2VlbiBsb25nIGFuZCBzaG9ydCBoZWFkZXIgYWxzbyBhbGxvd3MgdG8g dXNlIG11Y2ggbG9uZ2VyIGNvbm5lY3Rpb24gSURzIGFmdGVyIHRoZSBoYW5kc2hha2UuPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7IEkgZG9u4oCZdCBzZWUgbXVjaCB1c2UgaW4gaXQsIGJ1dCBpdCBtYXkg dGFrZSBvZmYgc29tZSBmZWFyIHRoYXQgMjQvMzIvMzYvNDgvNjAgYnl0ZSBjb25uZWN0aW9uIElE cyBtaWdodCBub3QgYmUgbG9uZyBlbm91Z2ggaW4gdGhlIGZ1dHVyZS48YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgVGhl cmUgYXJlIHR3byBtYWluIHJlYXNvbnMgdG8ga2VlcCB0aGUgY29tcHJlc3NlZCBlbmNvZGluZzo8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyDigKIgSW4gdGhlIGNvbXByZXNzZWQgZW5jb2Rpbmcs IHdlIGNhbiByZWFzb25hYmx5IGV4cGVjdCB0aGF0IGFsbCAvIG1vc3QgdmFsdWVzIHdpbGwgYmUg dXNlZCBpbiBwcmFjdGljZSwgc28gd2Ugd29uJ3QgZXhwb3NlIGFueSBiaXRzIG9uIHRoZSB3aXJl IHRoYXQgaWRlbnRpZnkgYSBwYWNrZXQgYXMgJnF1b3Q7UVVJQyB0cmFmZmljJnF1b3Q7IGJ5IGhh dmluZyBhIHByZWRpY3RhYmxlIHZhbHVlLjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IOKAoiBU aGUgMS1ieXRlIGVuY29kaW5nIGhhcyB0aGUgZGlzYWR2YW50YWdlIHRoYXQgYW4gaW1wbGVtZW50 YXRpb24gc3RpbGwgbmVlZHMgdG8gYmUgYWJsZSB0byBkZWFsIHdpdGggY29ubmVjdGlvbiBJRCBs ZW5ndGhzIG9mIDI1NSBieXRlcywganVzdCB0byBiZSBhYmxlIHRvIHNlbmQgVmVyc2lvbiBOZWdv dGlhdGlvbiBwYWNrZXRzLiBUbyBtZSwgaXQgc2VlbXMgYWJzdXJkIHRvIHdyaXRlIGEgUVVJQyBp bXBsZW1lbnRhdGlvbiB0aGF0DQogaXMgYWJsZSB0byBoYW5kbGUgcGFja2V0cyB3aXRoIGEgY29t YmluZWQgY29ubmVjdGlvbiBJRCBvdmVyaGVhZCBvZiA1MTAgYnl0ZXMuIFNpbmNlIFZOUHMgYXJl IHN1cHBvc2VkIHRvIGJlIHNlbnQgaW4gcmVzcG9uc2UgdG8gYW55IExvbmcgSGVhZGVyIHBhY2tl dCwgeW91J2QgaGF2ZSB0byBwdXQgc29tZSBjYXJlZnVsIHRob3VnaHQgaW50byB0aGUgZGVzaWdu IG9mIHlvdXIgZGF0YSB0eXBlcyB0byBhdm9pZCB0aGlzIGJlY29taW5nIGEgRG9TDQogdmVjdG9y Ljxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IE9u IFR1ZSwgSnVuIDE4LCAyMDE5IGF0IDM6NTAgQU0gQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhy ZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBo dWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEkgdG9v IGFncmVlIHRoYXQgdXNpbmcgb25lIGJ5dGUgaW4gdGhlIGludmFyaWFudCBpcyBwcmVmZXJhYmxl IHRvIHRoZSBjdXJyZW50ICZxdW90O2NvbXByZXNzZWQgNCBiaXRzJnF1b3Q7IHNvbHV0aW9uLjxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IFJlZ2Fy ZGluZyB0aGUgJnF1b3Q7Q0lEIGxlbmd0aCBsaW1pdCZxdW90OywgSSB0aGluZyB0aGVyZSBhcmUg dHdvIGlzc3VlczogdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBhbmQgY29zdHMgdG8gdGhlIGNvbW11 bml0eS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyBJIGFtIG5vdCB0b28gY29uY2VybmVkIHdpdGggdGhlIHRyYW5zbWlzc2lvbiBvdmVyaGVhZCwg YXMgd2UgaGF2ZSB0aGVyZSB0aGUgcmlnaHQgbWl4IG9mIGNvc3RzIGFuZCBpbmNlbnRpdmVzLiBT ZXJ2ZXJzIHdobyBjaG9zZSB0byB1c2UgbG9uZ2VyIENJRCB3aWxsIGdldCBtb3JlIHRyYW5zbWlz c2lvbiBvdmVyaGVhZCwgYW5kIHRodXMgdHJhbnNtaXNzaW9uIGxlc3MgZWZmaWNpZW50bHkgdGhh biB0aGVpciBjb21wZXRpdG9ycy4gVGhleQ0KIG1heSBjaG9zZSB0byB1c2UgbG9uZ2VyIENJRCBh cyBhIHRyYWRlLW9mZiBiZXR3ZWVuIHRyYW5zbWlzc2lvbiBlZmZpY2llbmN5IGFuZCBlYXNlIG9m IG1hbmFnZW1lbnQuIENvbXBldGl0aW9uIHdpbGwgc29ydCB0aGF0IG91dC4gSSBub3RlIHRoYXQg WW91VHViZSBpcyBhcHBhcmVudGx5IGRvaW5nIGZpbmUgd2l0aCBzbWFsbGlzaCBDSUQsIHNvIEkg dHJ1c3QgdGhhdCB0aGVyZSB3aWxsIGJlIGNvbXBldGl0aW9uLjxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEkgYW0gbXVjaCBtb3JlIGNvbmNlcm5l ZCB3aXRoIHRoZSBzaGFyZWQgY29zdHMsIHdoaWNoIGFyZSBhIHZhcmlhdGlvbiBvZiB0aGUgJnF1 b3Q7dHJhZ2VkeSBvZiB0aGUgY29tbW9ucyZxdW90Oy4gRG1pdHJ5IGV4cGxhaW5lZCB0aG9zZSBj b3N0cyB3ZWxsIGluIGEgcHJldmlvdXMgbWVzc2FnZS4gVGhlIHNpbXBsZXIgaW1wbGVtZW50YXRp b24gaXMgdG8gbWFrZSB0aGUgJnF1b3Q7Y2lkX3QgYSBmaXhlZC1zaXplIG9iamVjdCB0aGF0IGNh biBmaXQgdGhlIGxhcmdlc3QNCiBDSUQgYW5kIGVhdCB0aGUgb3ZlcmhlYWQgZm9yIGFsbCBDSURz LiZxdW90OyBCdXQgZWFjaCBjb25uZWN0aW9uIG9iamVjdCBjYXJyaWVzIGEgbGFyZ2UgbnVtYmVy IG9mIGluc3RhbmNlcyBvZiB0aGUgQ0lEIHR5cGUuIEhhdmluZyBhIHZlcnkgbGFyZ2UgbWF4IENJ RCB3b3VsZCBpbXBseSBhIGxhcmdlIG92ZXJoZWFkLiBUaGUgYWx0ZXJuYXRpdmUgaXMgdG8gJnF1 b3Q7TWFrZSBjaWRfdCBhIHZhcmlhYmxlLXNpemUgb2JqZWN0JnF1b3Q7LCBidXQgdG9vIGFmZmVj dHMgcGVyZm9ybWFuY2UuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgSGVuY2UgdGhlIHB1c2gtYmFjay4gSSB3b3VsZCBwZXJzb25hbGx5IHByZWZl ciBhIG1heCBzaXplIG9mIDE2LCBhbmQgSSB0aGluayB0aGF0IDMyIGlzIHRoZSBoaWdoZXN0IHBy YWN0aWNhbCBsaW1pdC48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyAtLSBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IE9uIDYvMTcvMjAxOSA5OjE2IEFNLCBSb2JlcnRv IFBlb24gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IFdoYXQgSSB0aGluayBw ZW9wbGUgYXJlIHNheWluZyBzbyBmYXI6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAxKSBRVUlDIHYxIHdvdWxkIGxpbWl0IENJRCBs ZW5ndGggdG8gc29tZXRoaW5nIG9uZSBvZiB7MzIsIDM2LCBvciA0OH08YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDIpIFJlcHJlc2Vu dGF0aW9uIG9mIENJRCBsZW5ndGggYXMgYSBieXRlIGlzIHN0aWxsIE9LLCB0aHVzIGEgUVVJQyB2 MiBjb3VsZCB1c2UgbG9uZ2VyIENJRHMgYXMgbmVlZGVkIGJ5IGNoYW5naW5nIHRoZSBzcGVjIHdo aWxlIGtlZXBpbmcgdGhlIGludmFyaWFudHPigKYgaW52YXJpYW50Ljxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsmZ3Q7IFRoYXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSAvIEnigJlkIHN0 aWxsIHN1cHBvcnQgdGhhdC48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IC09Ujxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsm Z3Q7IEZyb206IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi4uLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiAmcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJh c2hlQGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgRGF0ZTogTW9uZGF5LCBKdW5lIDE3LCAy MDE5IGF0IDg6NTUgQU08YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgVG86IElhbiBTd2V0 dCAmbHQ7aWFuc3dldHQ9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7LCBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgQ2M6IERtaXRyaSBUaWtob25vdiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR0aWto b25vdkBsaXRlc3BlZWR0ZWNoLmNvbTwvYT4mZ3Q7LCBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1h QGh1aXRlbWEubmV0PC9hPiZndDssICZxdW90O1BoaWxpcHAgUy4gVGllc2VsJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbGlwcEB0aWVzZWwubmV0IiB0YXJnZXQ9Il9ibGFuayI+cGhpbGlw cEB0aWVzZWwubmV0PC9hPiZndDssDQogTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpt YmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJl PC9hPiZndDssIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRAbG93ZW50cm9w eS5uZXQiIHRhcmdldD0iX2JsYW5rIj5tdEBsb3dlbnRyb3B5Lm5ldDwvYT4mZ3Q7LCBNYXJ0ZW4g U2VlbWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bWFydGVuc2VlbWFubkBnbWFpbC5jb208L2E+Jmd0OywNCiBMYXJzIEVnZ2Vy dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxh cnNAZWdnZXJ0Lm9yZzwvYT4mZ3Q7LCBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OywgTWFydGluIER1 a2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPg0KICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1hcnRpbi4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi4u aC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OywgS2F6dWhvIE9rdSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwu Y29tPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgU3ViamVjdDogUkU6IENv bnNlbnN1cyBDYWxsOiBNb3JlIENvbm5lY3Rpb24gSUQgU3BhY2UgIzI3MzY8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgTXkg dGFrZSBpcyBzaW1pbGFyIOKAkyA0OCBpcyBwcm9iYWJseSBleGNlc3NpdmUsIHdoaWxlIDMyIGlz IGxpa2VseSB0aGUgdXBwZXIgbGltaXQgb2Yg4oCccmVhc29uYWJsZeKAnSAoaXQgc2hvdWxkIHBy b2JhYmx5IGJlIGEgZmFjdG9yIG9mIDgsIHNvIDMyIG9yIDI0PykuPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IFdlIGFyZSBm aXJtbHkgY29tbWl0dGVkIGZvciB1c2luZyBDSUQgZm9yIGluLWNsdXN0ZXIgbG9hZCBiYWxhbmNp bmcgLyBhbnljYXN0IHBvcCByb3V0aW5nLiBUaGlzIGRpc2N1c3Npb24gaXMgdGFraW5nIHVzLCBo b3dldmVyLCB0byBhIG5ldyB0ZXJyaXRvcnkg4oCTIGEgZ2VuZXJhbGl6ZWQg4oCcZGVzdGluYXRp b24tY29udHJvbGxlZCByb3V0aW5nIGluIGFuIG92ZXJsYXkgbmV0d29ya+KAnS4gVGhpcyBpcyBh IHZlcnkgaW50ZXJlc3RpbmcgdG9waWMsDQogYnV0IEkgd291bGQgaGVzaXRhdGUgdG8gYXR0ZW1w dCB0byBzb2x2ZSBpdCBmdWxseSBhbmQg4oCcaW4gZ2VuZXJhbOKAnSBpbiBRVUlDIHYxLjxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 Jmd0OyDigKIgSWdvcjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IEZyb206IElh biBTd2V0dCAmbHQ7aWFuc3dldHQ9PGEgaHJlZj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7Jmd0OyBNeSBpbnR1aXRpb24gc2F5cyBtYWtpbmcgdGhlIGNoYW5nZSB0byB0aGUgaW52YXJp YW50cyBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIGJ1dCBJIGRvbid0IGZlZWwgdGhhdCBzdHJv bmdseS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgSG93ZXZlciwgSSdkIGxpa2UgdGhlIG1heCBzaXplIHRvIGJlIHNtYWxs ZXIgdGhhbiA0OChidXQgbGFyZ2VyIHRoYW4gMTgpLiBJZiB3ZSB0aGluayAyMCBvciAyNCBpcyBz dWZmaWNpZW50LCBJJ2QgcHJlZmVyIHRoYXQuIEthenVobyBzdWdnZXN0ZWQgMzIsIHdoaWNoIGlz IGJldHRlciwgYnV0IEkgZG9uJ3QgYmVsaWV2ZSB0aGUgc2VydmVyIG5lZWRzIHRvIHVzZSBhIHNl cGFyYXRlIGJsb2NrIGNpcGhlciB3aGVuIGdpdmluZyBvdXQNCiBjb25uZWN0aW9uIElEcywgYmVj YXVzZSBJIGJlbGlldmUgaXQncyBpbXByYWN0aWNhbCBmb3IgdGhlIGxvYWQgYmFsYW5jZXIgYW5k IHNlcnZlciB0byBiZSB0aGF0IGRlY291cGxlZC4gVGhlIHNlcnZlciBoYXMgdG8gZ2l2ZSBvdXQg YSBDSUQgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciB3aWxsIHVzZSB0byByb3V0ZSBiYWNrIHRvIHRo ZSBzZXJ2ZXIsIHNvIHRoZXkgaGF2ZSB0byBzaGFyZSBlbm91Z2ggYW4gZW5jcnlwdGlvbiBrZXkv YWxnb3JpdGhtLg0KIEkgY2FuIGltYWdpbmUgbmVzdGluZyBsb2FkIGJhbGFuY2VycywgYnV0IHRo YXQncyB3ZWxsIGluIHRoZSByYW5nZSBvZiBRVUlDIHYyIGZyb20gbXkgcGVyc3BlY3RpdmUuPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsmZ3Q7IFdoYXRldmVyIHdlIGRvLCBJJ2QgcmVhbGx5IHByZWZlciB0byByZXNvbHZlIHRoaXMg c29vbmVyIHJhdGhlciB0aGFuIGxhdGVyIGFuZCBiZSB0cnVseSBkb25lIHdpdGggaXQuPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsm Z3Q7IE9uIE1vbiwgSnVuIDE3LCAyMDE5IGF0IDI6NTEgQU0gTWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgU2luY2UgaXQgaXMgbW9y ZSBsaWtlbHkgdGhhdCB5b3UgcGF5IGZvciBlZ3Jlc3MgdHJhZmZpYyB0aGFuIGluZ3Jlc3MgdHJh ZmZpYywgdGhlIG1vdGl2YXRpb24gdG8ga2VlcCBDSUTigJlzIHNtYWxsIGlzIGxpbWl0ZWQuPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsmZ3Q7IEkgZG8gdGhpbmsgdGhlIGludmFyaWFudHMgc2hvdWxkIGFsbG93IGZvciBsb25nIENJ ROKAmXMgYXMgcHJvcG9zZWQsIGFuZCB0aGF0IHRoZSBsb25nIGhlYWRlciBvdmVyaGVhZCBpcyBu b3QgaW1wb3J0YW50Li4uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IEJ1dCBmb3IgUVVJQyB2MSwgaWYgd2UgYWxsb3cgZm9y IGEgbG9uZyBDSUQsIGEgcnVzaCB0byBtYXJrZXQgd2lsbCBzZXQgcHJlY2VkZW5jZSBhbmQgbG9u ZyBDSUTigJlzIHdpbGwgb3NzaWZ5IGluIGFsbCBraW5kcyBvZiBzdGFja3MuPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IEkg Z29vZCByZWZlcmVuY2Ugb24gYW4gYWxnb3JpdGhtIGxpa2Ugc3VnZ2VzdGVkIGJ5IENocmlzdGlh biB3b3VsZCBnbyBhIGxvbmcgd2F5Ljxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBJZiBDSUQgbGVuZ3RoIDE4IHR1cm5zIG91 dCB0byBiZSBub3QgZW5vdWdoLCB3ZSBjYW4gYWRkIGEgUVVJQyB2Mi4gSXTigJlzIG5vdCBsaWtl IHdlIGFyZSBub3QgbG9va2luZyBmb3IgZXhjdXNlcyB0byB1cGdyYWRlIFFVSUMgdmVyc2lvbnMg c29vbi48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgSWYgQ0lEIGxlbmd0aCBuZWdvdGlhdGlvbiBpcyBuZWVkZWQsIHRoaXMg Y291bGQgYmUgZG9uZSB2aWEgUVVJQyB2ZXJzaW9ucy4gRm9yIGV4YW1wbGUgdHdvIGZ1bmN0aW9u YWxseSBlcXVpdmFsZW50IHZlcnNpb25zLCBidXQgb25lIHdpdGggbG9uZ2VyIENJROKAmXMuIFRo aXMgd291bGQgYWxzbyBhbGxvdyByb3V0ZXJzIHRvIGRlYWwgd2l0aCBjaGFuZ2VzIGluIENJRCBs ZW5ndGhzLiBBIG5lZ290aWF0ZWQgVFAgd291bGQgbm90IChlYXNpbHkpDQogYWxsb3cgZm9yIHRo YXQgYW5kIGFzaWRlIEkgZG8gbm90IHRoaW5rIENJRCBsZW5ndGggaW4gVFAgaXMgdGhlIHdheSB0 byBnby48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgTWlra2VsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IE9uIDE3IEp1bmUgMjAxOSBhdCAwNi40NS4w NCwgS2F6dWhvIE9rdSAoPGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5rYXp1aG9va3VAZ21haWwuY29tPC9hPikgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAyMDE5PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjY8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mnIg8L3NwYW4+MTc8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+ KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bh bj4pIDExOjA5IENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBo dWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzoN Cjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7Jmd0OyAmZ3Q7IE9uIDYvMTUvMjAxOSAxMDo1NSBQTSwgS2F6dWhvIE9rdSB3cm90ZTog PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7ICZndDsgJmd0OyBfSWZfIHdlIGFyZSB0byBhbGxvdyBsb29zZSBjb3VwbGluZyBi ZXR3ZWVuIGEgbG9hZCBiYWxhbmNlciBhbmQgYSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgJmd0OyAmZ3Q7IHNlcnZlciwgZWFjaCBvZiB0aGUgdHdvIHNob3VsZCBiZSBnaXZlbiB0aGUg ZnJlZWRvbSB0byBjaG9vc2UgaXQncyBvd24NCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyAmZ3Q7ICZndDsgQ0lEIGVuY3J5cHRpb24gc2NoZW1lLiBCZWNhdXNlIGFsbCB0aGUgc3RhbmRh cmRpemVkIGJsb2NrIGNpcGhlcnMgYXJlDQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg Jmd0OyAmZ3Q7IG5vdyAxMjgtYml0cyAoPSAxNiBieXRlcyksIHRoYXQgbmF0dXJhbGx5IG1lYW5z IHRoYXQgdGhlIG1heGltdW0gQ0lEIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7 ICZndDsgbGVuZ3RoIG9mIFFVSUMgbmVlZHMgdG8gYmUgZG91YmxlIGFtb3VudCBvZiB0aGF0LCBw bHVzIG9uZSBvciB0d28gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgJmd0OyBi eXRlcyBmb3IgZWFjaCBvZiB0aGUgdHdvIGZvciBpZGVudGlmeWluZyB0aGUgQ0lEIGVuY3J5cHRp b24ga2V5cy4gRm9yDQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyAmZ3Q7IGtl eSBpZGVudGlmaWNhdGlvbiBhbmQgb3RoZXIgc3VwcGxlbWVudGFsIHVzZSwgd2UgY3VycmVudGx5 IGFsbG9jYXRlIDINCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgYnl0 ZXMgKDE4LTE2PTIpLiA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyBUaGF0IHJlYXNvbmluZyBpcyBiYXNlZCBvbiB0 aGUgYXNzdW1wdGlvbiB0aGF0IGJvdGggdGhlIGxvYWQgYmFsYW5jZXIgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7ICZndDsgYW5kIHRoZSBzZXJ2ZXIgbXVzdCB1c2UgYSBibG9jayBjaXBo ZXIgd2l0aCAxMjggYml0IGJsb2NrIGxlbmd0aCBpbiA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyZndDsgJmd0OyBvcmRlciB0byBlbmNyeXB0IHRoZSBDSUQuIElmIHRoZXkgd2VyZSBjb25zdHJh aW5lZCB0byBzdGF5IHdpdGhpbiBhIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7 IHNob3J0IGdsb2JhbCBsaW1pdCwgdGhleSBjb3VsZCB1c2UgZGlmZmVyZW50IHNldHMgb2YgYWxn b3JpdGhtcy4gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgQXNzdW1lIGZvciBleGFtcGxlIHRoYXQgd2Ugc3BsaXQg dGhlIENJRCBiZXR3ZWVuIDMyIGJpdHMgZW5jb2RpbmcgdGhlIDxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7Jmd0OyAmZ3Q7IG51bWJlciBvZiB0aGUgc2VydmVyIGluIHRoZSBzZXJ2ZXIgZmFybSwg YW5kIDY0IGJpdCBlbmNvZGluZyB0aGUgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZn dDsgY29ubmVjdGlvbiBudW1iZXIgZm9yIHRoZSBzZXJ2ZXIuIFRoZSBzZXJ2ZXIgY2FuIHBpY2sg YSByYW5kb20gdmFsdWUgZm9yDQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyB0 aGUgY29ubmVjdGlvbiBudW1iZXIsIGFuZCB1c2UgYSBoYXNoIHRhYmxlLiBUaGUgbG9hZCBiYWxh bmNlciBjb3VsZCB1c2UNCjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IGEgMzIg Yml0IHZhcmlhbnQgb2YgdGhlIEZGWCBhbGdvcml0aG0sIHVzaW5nIHRoZSBsb3dlciA2NCBiaXQg b2YgdGhlIENJRA0KPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgYXMgYW4gaW5p dGlhbCB2ZWN0b3IuIFZvaWxhLCA5NiBDSUQsIHdpdGggZGVtb25zdHJhYmx5IHN0cm9uZyBlbmNy eXB0aW9uLg0KPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgT3IgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciB3YW50cyB0 byB1c2Ugc2hvcnQgQ0lELiBXZSBub3cgc3BsaXQgdGhlIENJRCA8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyZndDsgJmd0OyBiZXR3ZWVuIDMyIGJpdCBmb3IgdGhlIHNlcnZlciBudW1iZXIgaW4g dGhlIGZhcm0sIGFuZCAzMiBiaXQgZm9yIHRoZSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgJmd0OyBjb25uZWN0aW9uIG51bWJlciBpbiB0aGUgc2VydmVyLiBUaGUgc2VydmVyIGJ1aWxk cyB0aGF0IGNvbm5lY3Rpb24gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgbnVt YmVyIGJ5IHVzaW5nIGEgMzIgYml0IHZhcmlhbnQgb2YgRkZYLiBUaGUgbG9hZCBiYWxhbmNlciBh bHNvIHVzZXMgYSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyAzMiBiaXQgdmFy aWFudCwgdXNpbmcgdGhlIGxvd2VyIDMyIGJpdCBvZiB0aGUgQ0lEIGFzIGluaXRpYWwgdmVjdG9y IGZvcg0KPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgdGhpcyBGRlggZW5jcnlw dGlvbi4gPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7ICZndDsgVGhlc2UgYXJlIGp1c3QgdHdvIGV4YW1wbGVzLiBBbmQgeWVz IHlvdSBtYXkgd2FudCB0byBhZGQgMiBieXRlcyBmb3Iga2V5DQo8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyZndDsgJmd0OyBpZGVudGlmaWNhdGlvbiwgZXRjLiBJbiBib3RoIGVuY3J5cHRpb24g YWxnb3JpdGhtcywgeW91IGNhbiBmZWVkIHRoZXNlIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 Jmd0OyAmZ3Q7IHR3byBieXRlcyBhcyBhZGRpdGlvbmFsIElWIGZvciB0aGUgRkZYIGFsZ29yaXRo bS4gQW5kIGluIGJvdGggY2FzZXMsIHdlDQo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg Jmd0OyBhcmUgd2VsbCBiZWxvdyB0aGUgMTggYnl0ZSBsaW1pdC4gPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgWWVz LCB0aGF0IHJlcXVpcmVzIHNvbWUgY3JlYXRpdmUgZW5naW5lZXJpbmcuIEJ1dCBpdCBpcyBub3Qg cm9ja2VyIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAmZ3Q7IHNjaWVuY2UuIEFuZCBp dCBzZWVtcyBiZXR0ZXIgdGhhbiBjYXJyeWluZyB0b25zIG9mIG92ZXJoZWFkIGluIHRoZSA8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgJmd0OyBoZWFkZXIsIGFuZCBiZWNvbWluZyBsZXNz IGVmZmljaWVudCB0aGFuIEhUVFAyL1RMUy9UQ1AuIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgSSBhZ3JlZSB0aGF0IGl0IHdvdWxk IG5vdCBiZSB0aGUgZW5kIG9mIHRoZSB3b3JsZCBmb3IgdGhlIGxvYWQgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7IGJhbGFuY2VycyBpZiB3ZSBkZWNpZGUgdG8gc3RpY2sgb24gdGhlIDE4 LWJ5dGUgbGltaXQuIEhvd2V2ZXIsIGFzIHlvdSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZn dDsgc3RhdGUsIGl0IHJlcXVpcmVzIHNvbWUgY3JlYXRpdmVuZXNzLiA8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IFRvIG1lIGl0IHNl ZW1zIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIGlmIHdlIGhhdmUgYSBzdHJvbmcgcmVhc29uIHRvIDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyByZXF1aXJlIHNvbWUgcGVvcGxlIHRvIGJlIGNy ZWF0aXZlLCBmb3IgYWxsIHRoZSB2ZXJzaW9ucyBvZiBRVUlDIGluIDxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7Jmd0OyB0aGUgZnV0dXJlLiBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCB0aGVyZSBp c24ndCBhIHN0cm9uZyByZWFzb24sIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyBiZWNh dXNlIHBlb3BsZSBjYW4gdXNlIHNob3J0ZXIgQ0lEcyByZWdhcmRsZXNzIG9mIHRoZSBkZWNpc2lv biB3ZSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgbWFrZS4gSUlVQywgdGhlIG92ZXJo ZWFkIHRoYXQgZXZlcnlvbmUgbmVlZHMgdG8gYWNjZXB0IGlzOiA8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICogb25lIGJ5dGUgaW5j cmVhc2UgaW4gdGhlIGxvbmcgaGVhZGVyIHBhY2tldHMgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsmZ3Q7ICogdGhlIG1pbmltdW0gc2l6ZSBvZiBzaG9ydCBoZWFkZXIgcGFja2V0cyBiZWNvbWlu ZyBzbGlnaHRseSBncmVhdGVyIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0OyAob3RoZXJ3 aXNlLCB0aGUgcGVlciBtaWdodCBub3QgYmUgYWJsZSB0byBzZW5kIGEgc3RhdGVsZXNzIHJlc2V0 KSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsmZ3Q7IEknZCBzYXkgdGhhdCB0aGUgZmlyc3QgYnVsbGV0IHBvaW50IGlzIG5lZ2xpZ2libGUu IFRoZSBzZWNvbmQgcG9pbnQgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IGNvdWxkIGFs c28gYmUsIGJlY2F1c2UgSSdkIGFzc3VtZSB0aGF0IHRoZSBvbmx5IGZyZXF1ZW50bHktc2VudCA8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgcGFja2V0cyB0aGF0IHJlcXVpcmUgYWRkaXRp b25hbCBwYWRkaW5nIGlzIHRoZSBBQ0stb25seSBwYWNrZXRzLCBidXQgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7IHRoZXJlJ3Mgbm8gcmVhc29uIHRvIHBhZCBBQ0stb25seSBwYWNrZXRz IGluIGhvcGUgdGhhdCB5b3UnZCBzZWUgYSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsg c3RhdGVsZXNzIHJlc2V0LiA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IFRoZXJlZm9yZSwgbXkgKG5vdC1zby1zdHJvbmcpIHByZWZl cmVuY2UgaGFzIGJlZW4gdG8gcHJvdmlkZSBleHRyYSA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyZndDsgcm9vbSwgc28gdGhhdCBzb21lIHBlb3BsZSB3aXRoIG5lY2Vzc2l0eSBjYW4gdXNlIGxv bmdlciBDSURzLiA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsg LS0gQ2hyaXN0aWFuIEh1aXRlbWEgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7Jmd0 OyBLYXp1aG8gT2t1PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgQVZFITxicj4NCiZndDsgJmd0OyZuYnNwOyBQaGlsaXBw IFMuIFRpZXNlbDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgLS0gPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7IFBoaWxpcHAgUy4gVGllc2VsIDxicj4NCiZndDsgJmd0OyA8YSBocmVm PSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0 cHMtM0FfX3BoaWxpcHAudGllc2VsLm5ldF8lMjZkJTNERHdNRmFRJTI2YyUzRDVWRDBSVHRObFRo M3ljZDQxYjNNVXclMjZyJTNEQzBzVW8tTEZOQmFZZnlvYUNzZjZUQSUyNm0lM0QzLS1WZjgzeXVV U3VMdEk0eDJlbldUM3V0U1d6dXJRdkRaRFRpXzd0SnpjJTI2cyUzRDBFcmg0RDZtS2tLa0RDLUVz Y21NMklaLWo1T3pyUThuai1idXEzcUthNG8lMjZlJTNEJmFtcDtkYXRhPTAyJTdDMDElN0NuaWJh bmtzJTQwbWljcm9zb2Z0LmNvbSU3QzEzZmFlOTI5ZjQzMjQ3OTYxYWFhMDhkNmY2ODYxNTg4JTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk2NzQ1MzEwNTIy OTgyNSZhbXA7c2RhdGE9QmwxQURwdHlvU0JTeVJPTUc2dTBHOURRODBOaXVJV3VleHAwcXVKdE50 dyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9waGlsaXBwLnRp ZXNlbC5uZXQvPC9hPjxicj4NCiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_BL0PR2101MB13329389538ABEC55AFE80F9B3E70BL0PR2101MB1332_-- From nobody Fri Jun 21 13:24:29 2019 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 7C90A1201E5 for ; Fri, 21 Jun 2019 13:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.02 X-Spam-Level: X-Spam-Status: No, score=-5.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_4mjyLfMLMG for ; Fri, 21 Jun 2019 13:24:24 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 D32071203B2 for ; Fri, 21 Jun 2019 13:24:23 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x5LKH157047940; Fri, 21 Jun 2019 13:24:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=PQegI8J5rDGydaWGtFmHUlYlqIQY6EvQ/ZYPFDWSYxQ=; b=v4w2t/wN/HNO6+t2QolvoUYLkWA7aWGliReaa0r61ScjYymGpokphHiEg1uc93SfV1ob 5tHtHKKSLt6jpdjARiNYJ2TyJcSIkPsMdk1s6w6zAszQog4rPdwvapf3Tgabt7UN8Pcs RYlnOrB1SbIqfMxWbCsHsANrHctnL9O9T1fotAbTGzMrp77oErBWnNZxSfqxQo4WE8/C QVegTjKu/en+HRVAUFycH9Rcz6BWpXHbf9xG2ZRZWC2QJd4ZbJfGQhfstyWdlQT3OZbs OFill88m5Pyqb9v+4ZjqqVSyUANnux5g4dUqh+/nCX1moufRqboUQCcinROrvhESJVPI bg== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2t94wy9m7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 21 Jun 2019 13:24:18 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bki+2vkOG5gn9PS7Lxhs/g)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PTG00J5FU0HIG80@mr2-mtap-s03.rno.apple.com>; Fri, 21 Jun 2019 13:24:17 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PTG00M00TC8DY00@nwk-mmpp-sz10.apple.com>; Fri, 21 Jun 2019 13:24:17 -0700 (PDT) X-Va-A: X-Va-T-CD: f4922fd122d6ae9ff61f672cd6761a55 X-Va-E-CD: c0dd03b56da0c06eed6995d12b46a589 X-Va-R-CD: 2f5d4cfbca99c574feea771ba5d897df X-Va-CD: 0 X-Va-ID: e48beadb-df29-423e-875d-b78a215c568b X-V-A: X-V-T-CD: f4922fd122d6ae9ff61f672cd6761a55 X-V-E-CD: c0dd03b56da0c06eed6995d12b46a589 X-V-R-CD: 2f5d4cfbca99c574feea771ba5d897df X-V-CD: 0 X-V-ID: a3055592-93c9-40c7-af85-422fde24a851 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-21_15:,, signatures=0 Received: from [17.234.66.105] (unknown [17.234.66.105]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PTG00DY4U0G0U70@nwk-mmpp-sz10.apple.com>; Fri, 21 Jun 2019 13:24:16 -0700 (PDT) Sender: ekinnear@apple.com From: Eric Kinnear Message-id: <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> Subject: Re: Consensus Call: More Connection ID Space #2736 Date: Fri, 21 Jun 2019 13:24:16 -0700 In-reply-to: Cc: Roberto Peon , David Schinazi , Ian Swett , IETF QUIC WG , Martin Thomson To: Nick Banks References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-21_15:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 20:24:29 -0000 --Boundary_(ID_bki+2vkOG5gn9PS7Lxhs/g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable (2) would be fine for me! Thanks, Eric > On Jun 21, 2019, at 1:23 PM, Nick Banks = wrote: >=20 > Works for me as well. > =20 > - Nick > =20 > From: QUIC On Behalf Of Roberto Peon > Sent: Friday, June 21, 2019 1:21 PM > To: David Schinazi ; Ian Swett = > Cc: IETF QUIC WG ; Martin Thomson > Subject: Re: Consensus Call: More Connection ID Space #2736 > =20 > Works for me. > -=3DR > =20 > From: QUIC > on = behalf of David Schinazi > > Date: Friday, June 21, 2019 at 1:02 PM > To: Ian Swett > > Cc: IETF QUIC WG >, Martin = Thomson > > Subject: Re: Consensus Call: More Connection ID Space #2736 > =20 > +1 to what Ian said. (2) seems like a good path forward > =20 > On Fri, Jun 21, 2019 at 1:00 PM Ian Swett = > wrote: > I think the 3 options I see as well reasoned are:=20 > 1) Keep the status quo because we think we can put what we really need = into 18 bytes if we try. > 2) Change to a 1 byte length per CID and a max of 20, which gives us a = few extra bytes for cleartext server id and/or key rotation/etc. > 3) Change to a 1 byte length per CID and a max of 36, because we want = be able to put 2 encrypted routing IDs in a single CID. > =20 > 2 is my preferred option, though I can live with either of 1 or 3. > =20 > Deciding sooner would be strictly better than later, since this is = blocking us(Chrome/Google) actually supporting varlen CIDs. > =20 > On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson > wrote: > That seems a little high. I think that Ian's principle here is what = should guide us: what is the minimum you can handle? What I've heard is = that 18 might have been workable, but it was REALLY close to the edge to = the point that you weren't confident it was enough, even in the near = term.. But that suggests that 20 is workable. >=20 > On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > > so do I hear consensus emerging around 32B in v1, or should I leave = the=20 > > 18B limit in v1 for now and punt out that discussion? > >=20 > > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel = > wrote: > > >=20 > > >=20 > > > > On 18. Jun 2019, at 05:33, Marten Seemann = > wrote: > > > >=20 > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we = decide to increase the connection ID length to a larger value (which I'm = still not convinced that this is really necessary). > > >=20 > > > This would be easy if we change the encoding of the connection ID = length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While = we can not encode one or two byte connection IDs in long header packets, = we can still use them in short header packets. > > >=20 > > > This split between long and short header also allows to use much = longer connection IDs after the handshake. > > > I don=E2=80=99t see much use in it, but it may take off some fear = that 24/32/36/48/60 byte connection IDs might not be long enough in the = future. > > >=20 > > > >=20 > > > > There are two main reasons to keep the compressed encoding: > > > > =E2=80=A2 In the compressed encoding, we can reasonably expect = that all / most values will be used in practice, so we won't expose any = bits on the wire that identify a packet as "QUIC traffic" by having a = predictable value. > > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an = implementation still needs to be able to deal with connection ID lengths = of 255 bytes, just to be able to send Version Negotiation packets. To = me, it seems absurd to write a QUIC implementation that is able to = handle packets with a combined connection ID overhead of 510 bytes. = Since VNPs are supposed to be sent in response to any Long Header = packet, you'd have to put some careful thought into the design of your = data types to avoid this becoming a DoS vector. > > > >=20 > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema = > wrote: > > > > I too agree that using one byte in the invariant is preferable = to the current "compressed 4 bits" solution. > > > >=20 > > > > Regarding the "CID length limit", I thing there are two issues: = transmission overhead, and costs to the community. > > > >=20 > > > > I am not too concerned with the transmission overhead, as we = have there the right mix of costs and incentives. Servers who chose to = use longer CID will get more transmission overhead, and thus = transmission less efficiently than their competitors. They may chose to = use longer CID as a trade-off between transmission efficiency and ease = of management. Competition will sort that out. I note that YouTube is = apparently doing fine with smallish CID, so I trust that there will be = competition. > > > >=20 > > > > I am much more concerned with the shared costs, which are a = variation of the "tragedy of the commons". Dmitry explained those costs = well in a previous message. The simpler implementation is to make the = "cid_t a fixed-size object that can fit the largest CID and eat the = overhead for all CIDs." But each connection object carries a large = number of instances of the CID type. Having a very large max CID would = imply a large overhead. The alternative is to "Make cid_t a = variable-size object", but too affects performance. > > > >=20 > > > > Hence the push-back. I would personally prefer a max size of = 16, and I think that 32 is the highest practical limit. > > > >=20 > > > > -- Christian Huitema > > > >=20 > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > > >> What I think people are saying so far: > > > >>=20 > > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, = or 48} > > > >>=20 > > > >> 2) Representation of CID length as a byte is still OK, thus a = QUIC v2 could use longer CIDs as needed by changing the spec while = keeping the invariants=E2=80=A6 invariant. > > > >>=20 > > > >>=20 > > > >> That seems reasonable to me / I=E2=80=99d still support that. > > > >>=20 > > > >> -=3DR > > > >>=20 > > > >>=20 > > > >> From: QUIC > on behalf of "Lubashev, Igor" = > > > > >> Date: Monday, June 17, 2019 at 8:55 AM > > > >> To: Ian Swett >, Mikkel Fahn=C3=B8e J=C3=B8rgensen = > > > > >> Cc: Dmitri Tikhonov >, Christian Huitema = >, "Philipp S. Tiesel" = >, Mike Bishop = >, Martin Thomson = >, Marten Seemann = >, Lars Eggert = >, QUIC WG >, Martin Duke >>, Kazuho Oku > > > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > > >>=20 > > > >>=20 > > > >>=20 > > > >> My take is similar =E2=80=93 48 is probably excessive, while = 32 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should = probably be a factor of 8, so 32 or 24?). > > > >>=20 > > > >>=20 > > > >>=20 > > > >> We are firmly committed for using CID for in-cluster load = balancing / anycast pop routing. This discussion is taking us, however, = to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled= routing in an overlay network=E2=80=9D. This is a very interesting = topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin = general=E2=80=9D in QUIC v1. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> =E2=80=A2 Igor > > > >>=20 > > > >>=20 > > > >> From: Ian Swett > > > > >>=20 > > > >> My intuition says making the change to the invariants is the = right thing to do, but I don't feel that strongly. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> However, I'd like the max size to be smaller than 48(but = larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. = Kazuho suggested 32, which is better, but I don't believe the server = needs to use a separate block cipher when giving out connection IDs, = because I believe it's impractical for the load balancer and server to = be that decoupled. The server has to give out a CID that the load = balancer will use to route back to the server, so they have to share = enough an encryption key/algorithm. I can imagine nesting load = balancers, but that's well in the range of QUIC v2 from my perspective. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> Whatever we do, I'd really prefer to resolve this sooner = rather than later and be truly done with it. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgense= n > wrote: > > > >>=20 > > > >> Since it is more likely that you pay for egress traffic than = ingress traffic, the motivation to keep CID=E2=80=99s small is limited. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> I do think the invariants should allow for long CID=E2=80=99s = as proposed, and that the long header overhead is not important... > > > >>=20 > > > >>=20 > > > >>=20 > > > >> But for QUIC v1, if we allow for a long CID, a rush to market = will set precedence and long CID=E2=80=99s will ossify in all kinds of = stacks. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> I good reference on an algorithm like suggested by Christian = would go a long way. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> If CID length 18 turns out to be not enough, we can add a QUIC = v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC = versions soon. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> If CID length negotiation is needed, this could be done via = QUIC versions. For example two functionally equivalent versions, but one = with longer CID=E2=80=99s. This would also allow routers to deal with = changes in CID lengths. A negotiated TP would not (easily) allow for = that and aside I do not think CID length in TP is the way to go. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> Mikkel > > > >>=20 > > > >>=20 > > > >>=20 > > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com = ) wrote: > > > >>=20 > > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian = Huitema >:=20 > > > >> >=20 > > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=20 > > > >> >=20 > > > >> > > _If_ we are to allow loose coupling between a load = balancer and a=20 > > > >> > > server, each of the two should be given the freedom to = choose it's own=20 > > > >> > > CID encryption scheme. Because all the standardized block = ciphers are=20 > > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the = maximum CID=20 > > > >> > > length of QUIC needs to be double amount of that, plus one = or two=20 > > > >> > > bytes for each of the two for identifying the CID = encryption keys. For=20 > > > >> > > key identification and other supplemental use, we = currently allocate 2=20 > > > >> > > bytes (18-16=3D2).=20 > > > >> >=20 > > > >> > That reasoning is based on the assumption that both the load = balancer=20 > > > >> > and the server must use a block cipher with 128 bit block = length in=20 > > > >> > order to encrypt the CID. If they were constrained to stay = within a=20 > > > >> > short global limit, they could use different sets of = algorithms.=20 > > > >> >=20 > > > >> > Assume for example that we split the CID between 32 bits = encoding the=20 > > > >> > number of the server in the server farm, and 64 bit encoding = the=20 > > > >> > connection number for the server. The server can pick a = random value for=20 > > > >> > the connection number, and use a hash table. The load = balancer could use=20 > > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 = bit of the CID=20 > > > >> > as an initial vector. Voila, 96 CID, with demonstrably = strong encryption.=20 > > > >> >=20 > > > >> > Or assume that the server wants to use short CID. We now = split the CID=20 > > > >> > between 32 bit for the server number in the farm, and 32 bit = for the=20 > > > >> > connection number in the server. The server builds that = connection=20 > > > >> > number by using a 32 bit variant of FFX. The load balancer = also uses a=20 > > > >> > 32 bit variant, using the lower 32 bit of the CID as initial = vector for=20 > > > >> > this FFX encryption.=20 > > > >> >=20 > > > >> > These are just two examples. And yes you may want to add 2 = bytes for key=20 > > > >> > identification, etc. In both encryption algorithms, you can = feed these=20 > > > >> > two bytes as additional IV for the FFX algorithm. And in = both cases, we=20 > > > >> > are well below the 18 byte limit.=20 > > > >> >=20 > > > >> > Yes, that requires some creative engineering. But it is not = rocker=20 > > > >> > science. And it seems better than carrying tons of overhead = in the=20 > > > >> > header, and becoming less efficient than HTTP2/TLS/TCP.=20 > > > >>=20 > > > >> I agree that it would not be the end of the world for the load=20= > > > >> balancers if we decide to stick on the 18-byte limit. However, = as you=20 > > > >> state, it requires some creativeness.=20 > > > >>=20 > > > >> To me it seems that the question is if we have a strong reason = to=20 > > > >> require some people to be creative, for all the versions of = QUIC in=20 > > > >> the future. I personally think that there isn't a strong = reason,=20 > > > >> because people can use shorter CIDs regardless of the decision = we=20 > > > >> make. IIUC, the overhead that everyone needs to accept is:=20 > > > >>=20 > > > >> * one byte increase in the long header packets=20 > > > >> * the minimum size of short header packets becoming slightly = greater=20 > > > >> (otherwise, the peer might not be able to send a stateless = reset)=20 > > > >>=20 > > > >> I'd say that the first bullet point is negligible. The second = point=20 > > > >> could also be, because I'd assume that the only = frequently-sent=20 > > > >> packets that require additional padding is the ACK-only = packets, but=20 > > > >> there's no reason to pad ACK-only packets in hope that you'd = see a=20 > > > >> stateless reset.=20 > > > >>=20 > > > >> Therefore, my (not-so-strong) preference has been to provide = extra=20 > > > >> room, so that some people with necessity can use longer CIDs.=20= > > > >>=20 > > > >> >=20 > > > >> > -- Christian Huitema=20 > > > >> >=20 > > > >> >=20 > > > >> >=20 > > > >>=20 > > > >>=20 > > > >>=20 > > > >> --=20 > > > >> Kazuho Oku > > > >>=20 > > >=20 > > > AVE! > > > Philipp S. Tiesel > > >=20 > > > --=20 > > > Philipp S. Tiesel=20 > > > https://philipp.tiesel.net/ = > > > >=20 --Boundary_(ID_bki+2vkOG5gn9PS7Lxhs/g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable (2) = would be fine for me!

Thanks,
Eric


On Jun 21, 2019, at 1:23 PM, Nick Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> = wrote:

Works for = me as well.
 
- Nick
 
From: QUIC <quic-bounces@ietf.org> On Behalf = Of Roberto Peon
Sent: Friday, June 21, 2019 1:21 = PM
To: David Schinazi <dschinazi.ietf@gmail.com>; Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Cc: IETF= QUIC WG <quic@ietf.org>; Martin Thomson <mt@lowentropy.net>
Subject: Re: Consensus Call: More = Connection ID Space #2736
 
Works for me.
-=3DR
 
From: QUIC <quic-bounces@ietf.org> on = behalf of David Schinazi <dschinazi.ietf@gmail.com>
Date: Friday, June 21, 2019 = at 1:02 PM
To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Cc: IETF= QUIC WG <quic@ietf.org>, Martin = Thomson <mt@lowentropy.net>
Subject: Re: Consensus Call: = More Connection ID Space #2736
 
+1 to what Ian said. (2) seems like a = good path forward
 
On Fri, Jun 21, 2019 at = 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:
I think = the 3 options I see as well reasoned are: 
1) Keep the status quo because we think we can put what we = really need into 18 bytes if we try.
2) Change to a 1 byte = length per CID and a max of 20, which gives us a few extra bytes for = cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because = we want be able to put 2 encrypted routing IDs in a single CID.
 
2 is my preferred option, though I can = live with either of 1 or 3.
 
Deciding sooner would be strictly better than later, since = this is blocking us(Chrome/Google) actually supporting varlen CIDs.
 
On Thu, Jun 20, 2019 at = 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:

That seems a little = high.  I think that Ian's principle here is what should guide us: = what is the minimum you can handle?  What I've heard is that 18 = might have been workable, but it was REALLY close to the edge to the = point that you weren't confident it was enough, even in the near = term..  But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or = should I leave the 
> 18B limit in v1 for now and punt out that discussion?
> 
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net>= wrote:
> > 
> = > 
>= >  > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrote:
> = >  > 
> >  > I'd prefer keeping the "compressed 4 = bits" solution, even if we decide to increase the connection ID length = to a larger value (which I'm still not convinced that this is really = necessary).
> > 
> = >  This would be easy if we change the encoding of the = connection ID length, e..g., to be DCIL*4 allowing up to 60 byte = connection IDs. While we can not encode one or two byte connection IDs = in long header packets, we can still use them in short header = packets.
> > 
> = >  This split between long and short header also allows to use = much longer connection IDs after the handshake.
> = >  I don=E2=80=99t see much use in it, but it may take off some = fear that 24/32/36/48/60 byte connection IDs might not be long enough in = the future.
> > 
> = >  > 
> >  > There are two main reasons to keep the = compressed encoding:
> >  > =E2=80=A2 In the = compressed encoding, we can reasonably expect that all / most values = will be used in practice, so we won't expose any bits on the wire that = identify a packet as "QUIC traffic" by having a predictable value.
> >  > =E2=80=A2 The 1-byte encoding has the = disadvantage that an implementation still needs to be able to deal with = connection ID lengths of 255 bytes, just to be able to send Version = Negotiation packets. To me, it seems absurd to write a QUIC = implementation that is able to handle packets with a combined connection = ID overhead of 510 bytes. Since VNPs are supposed to be sent in response = to any Long Header packet, you'd have to put some careful thought into = the design of your data types to avoid this becoming a DoS vector.
> >  > 
> = >  > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net> wrote:
> = >  > I too agree that using one byte in the invariant is = preferable to the current "compressed 4 bits" solution.
>= >  > 
> >  > Regarding the "CID length limit", I = thing there are two issues: transmission overhead, and costs to the = community.
> >  > 
> = >  > I am not too concerned with the transmission overhead, = as we have there the right mix of costs and incentives. Servers who = chose to use longer CID will get more transmission overhead, and thus = transmission less efficiently than their competitors. They may chose to = use longer CID as a trade-off between transmission efficiency and ease = of management. Competition will sort that out. I note that YouTube is = apparently doing fine with smallish CID, so I trust that there will be = competition.
> >  > 
> = >  > I am much more concerned with the shared costs, which = are a variation of the "tragedy of the commons". Dmitry explained those = costs well in a previous message. The simpler implementation is to make = the "cid_t a fixed-size object that can fit the largest CID and eat the = overhead for all CIDs." But each connection object carries a large = number of instances of the CID type. Having a very large max CID would = imply a large overhead. The alternative is to "Make cid_t a = variable-size object", but too affects performance.
> = >  > 
> >  > Hence the push-back. I would personally = prefer a max size of 16, and I think that 32 is the highest practical = limit.
> >  > 
> = >  > -- Christian Huitema
> >  = > 
>= >  > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >  >> What I think people are saying so = far:
> >  >> 
> = >  >> 1) QUIC v1 would limit CID length to something one = of {32, 36, or 48}
> >  >> 
> = >  >> 2) Representation of CID length as a byte is still = OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec = while keeping the invariants=E2=80=A6 invariant.
> = >  >> 
> >  >> 
> = >  >> That seems reasonable to me / I=E2=80=99d still = support that.
> >  >> 
> = >  >> -=3DR
> >  >> 
> = >  >> 
> >  >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" = <ilubashe@akamai.com>
> >  = >> Date: Monday, June 17, 2019 at 8:55 AM
> = >  >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fahn=C3=B8e = J=C3=B8rgensen <mikkelfj@gmail.com>
> >  = >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>, Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>,= Marten Seemann <martenseemann@gmail.com>, Lars Eggert <lars@eggert.org>, = QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com<mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.com>
> >  = >> Subject: RE: Consensus Call: More Connection ID Space #2736
> >  >> 
> = >  >> 
> >  >> 
> = >  >> My take is similar =E2=80=93 48 is probably = excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80= =9D (it should probably be a factor of 8, so 32 or 24?).
> >  >> 
> = >  >> 
> >  >> 
> = >  >> We are firmly committed for using CID for in-cluster = load balancing / anycast pop routing. This discussion is taking us, = however, to a new territory =E2=80=93 a generalized = =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D. = This is a very interesting topic, but I would hesitate to attempt to = solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >  >> 
> = >  >> 
> >  >> 
> = >  >> =E2=80=A2 Igor
> >  = >> 
> >  >> 
> = >  >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> = >  >> 
> >  >> My intuition says making the change = to the invariants is the right thing to do, but I don't feel that = strongly.
> >  >> 
> = >  >> 
> >  >> 
> = >  >> However, I'd like the max size to be smaller than = 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer = that. Kazuho suggested 32, which is better, but I don't believe the = server needs to use a separate block cipher when giving out connection = IDs, because I believe it's impractical for the load balancer and server = to be that decoupled. The server has to give out a CID that the load = balancer will use to route back to the server, so they have to share = enough an encryption key/algorithm. I can imagine nesting load = balancers, but that's well in the range of QUIC v2 from my = perspective.
> >  >> 
> = >  >> 
> >  >> 
> = >  >> Whatever we do, I'd really prefer to resolve this = sooner rather than later and be truly done with it.
> = >  >> 
> >  >> 
> = >  >> 
> >  >> On Mon, Jun 17, 2019 at 2:51 AM = Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= wrote:
> >  >> 
> = >  >> Since it is more likely that you pay for egress = traffic than ingress traffic, the motivation to keep CID=E2=80=99s small = is limited.
> >  >> 
> = >  >> 
> >  >> 
> = >  >> I do think the invariants should allow for long = CID=E2=80=99s as proposed, and that the long header overhead is not = important...
> >  >> 
> = >  >> 
> >  >> 
> = >  >> But for QUIC v1, if we allow for a long CID, a rush = to market will set precedence and long CID=E2=80=99s will ossify in all = kinds of stacks.
> >  >> 
> = >  >> 
> >  >> 
> = >  >> I good reference on an algorithm like suggested by = Christian would go a long way.
> >  = >> 
> >  >> 
> = >  >> 
> >  >> If CID length 18 turns out to be not = enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking = for excuses to upgrade QUIC versions soon.
> >  = >> 
> >  >> 
> = >  >> 
> >  >> If CID length negotiation is needed, = this could be done via QUIC versions. For example two functionally = equivalent versions, but one with longer CID=E2=80=99s. This would also = allow routers to deal with changes in CID lengths. A negotiated TP would = not (easily) allow for that and aside I do not think CID length in TP is = the way to go.
> >  >> 
> = >  >> 
> >  >> 
> = >  >> Mikkel
> >  >> 
> = >  >> 
> >  >> 
> = >  >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) = wrote:
> >  >> 
> = >  >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(= =E6=9C=88) 11:09 Christian Huitema <huitema@huitema.net>: 
> = >  >> > 
> = >  >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: 
> = >  >> > 
> = >  >> > > _If_ we are to allow loose coupling = between a load balancer and a 
> = >  >> > > server, each of the two should be given = the freedom to choose it's own 
> = >  >> > > CID encryption scheme. Because all the = standardized block ciphers are 
> = >  >> > > now 128-bits (=3D 16 bytes), that = naturally means that the maximum CID 
> = >  >> > > length of QUIC needs to be double amount = of that, plus one or two 
> = >  >> > > bytes for each of the two for identifying = the CID encryption keys. For 
> = >  >> > > key identification and other supplemental = use, we currently allocate 2 
> = >  >> > > bytes (18-16=3D2). 
> = >  >> > 
> = >  >> > That reasoning is based on the assumption that = both the load balancer 
> = >  >> > and the server must use a block cipher with 128 = bit block length in 
> >  >> > order to encrypt the CID. If = they were constrained to stay within a 
> = >  >> > short global limit, they could use different = sets of algorithms. 
> >  >> > 
> = >  >> > Assume for example that we split the CID = between 32 bits encoding the 
> = >  >> > number of the server in the server farm, and 64 = bit encoding the 
> >  >> > connection number for the = server. The server can pick a random value for 
> = >  >> > the connection number, and use a hash table. = The load balancer could use 
> = >  >> > a 32 bit variant of the FFX algorithm, using = the lower 64 bit of the CID 
> = >  >> > as an initial vector. Voila, 96 CID, with = demonstrably strong encryption. 
> = >  >> > 
> = >  >> > Or assume that the server wants to use short = CID. We now split the CID 
> = >  >> > between 32 bit for the server number in the = farm, and 32 bit for the 
> = >  >> > connection number in the server. The server = builds that connection 
> = >  >> > number by using a 32 bit variant of FFX. The = load balancer also uses a 
> = >  >> > 32 bit variant, using the lower 32 bit of the = CID as initial vector for 
> = >  >> > this FFX encryption. 
> = >  >> > 
> = >  >> > These are just two examples. And yes you may = want to add 2 bytes for key 
> = >  >> > identification, etc. In both encryption = algorithms, you can feed these 
> = >  >> > two bytes as additional IV for the FFX = algorithm. And in both cases, we 
> = >  >> > are well below the 18 byte limit. 
> = >  >> > 
> = >  >> > Yes, that requires some creative engineering. = But it is not rocker > >  >> > science. And it seems better = than carrying tons of overhead in the 
> = >  >> > header, and becoming less efficient than = HTTP2/TLS/TCP. 
> >  >> 
> = >  >> I agree that it would not be the end of the world = for the load 
> >  >> balancers if we decide to stick on = the 18-byte limit. However, as you 
> = >  >> state, it requires some creativeness. 
> = >  >> 
> >  >> To me it seems that the question is = if we have a strong reason to 
> = >  >> require some people to be creative, for all the = versions of QUIC in 
> >  >> the future. I personally think that = there isn't a strong reason, 
> = >  >> because people can use shorter CIDs regardless of = the decision we 
> >  >> make. IIUC, the overhead that = everyone needs to accept is: 
> = >  >> 
> >  >> * one byte increase in the long = header packets 
> >  >> * the minimum size of short header = packets becoming slightly greater 
> = >  >> (otherwise, the peer might not be able to send a = stateless reset) 
> >  >> 
> = >  >> I'd say that the first bullet point is negligible. = The second point 
> >  >> could also be, because I'd assume = that the only frequently-sent 
> = >  >> packets that require additional padding is the = ACK-only packets, but 
> = >  >> there's no reason to pad ACK-only packets in hope = that you'd see a 
> >  >> stateless reset. 
> = >  >> 
> >  >> Therefore, my (not-so-strong) = preference has been to provide extra 
> = >  >> room, so that some people with necessity can use = longer CIDs. 
> >  >> 
> = >  >> > 
> = >  >> > -- Christian Huitema 
> = >  >> > 
> = >  >> > 
> = >  >> > 
> = >  >> 
> >  >> 
> = >  >> 
> >  >> -- 
> = >  >> Kazuho Oku
> >  = >> 
> > > >  AVE!
> >  Philipp = S. Tiesel
> > 
> = >  -- 
> >  Philipp S. Tiesel 
> = > https://philipp.tiesel.net/> = >


= --Boundary_(ID_bki+2vkOG5gn9PS7Lxhs/g)-- From nobody Fri Jun 21 14:42:35 2019 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 1B8321201A3 for ; Fri, 21 Jun 2019 14:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QQSc79Um_V1 for ; Fri, 21 Jun 2019 14:42:29 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.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 CB9A9120019 for ; Fri, 21 Jun 2019 14:42:28 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp01.mail2web.com) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1heRIe-0004fA-21 for quic@ietf.org; Fri, 21 Jun 2019 23:42:27 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1heR8y-0000VV-Lq for quic@ietf.org; Fri, 21 Jun 2019 17:32:29 -0400 Received: (qmail 11075 invoked from network); 21 Jun 2019 21:32:22 -0000 Received: from unknown (HELO [192.168.23.106]) (Authenticated-user:_huitema@huitema.net@[96.85.209.249]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Jun 2019 21:32:21 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-3DF5FB12-53D8-4AD4-B0BD-A86336AC227A Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16F203) In-Reply-To: <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> Date: Fri, 21 Jun 2019 14:32:19 -0700 Cc: Nick Banks , David Schinazi , IETF QUIC WG , Roberto Peon , Martin Thomson , Ian Swett Content-Transfer-Encoding: 7bit Message-Id: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b0 78@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> To: Eric Kinnear Subject: Re: Consensus Call: More Connection ID Space #2736 X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ud2CCyxmm2KHETL0VYw/ASpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fuhkr/r9sC5YCtzdvz6DHF5/sevPPdLVvjz7b14RFNIS30ONArWHUY/dwk7 0Vyeflgyb8kPdw8E5fjseDcUSkOj03+K7Ju/qxRhvHDAT5LyR61Qv/sjUDXLdm6w1gNv1euKTrwh UfUHUrPvTkTGu7YwVDQ0hbqcLWUbjgHMZS6COdI/uLAeALf3vLWnw0F/4+fmuTv/CYIzmchrGsA6 CN6O7qbWTdT56xh4Rya20+oBtwahqtg42IMQXC/e/thfmehs05Web8nJyEMtLxwhnYinDFrKlNc7 qNKmpnIY9d8cOJUa+B0z/Xg2ESGxDSOWWoTyIUtK8Miz//+1AD61I8sOcFFSGcngeU5u06zO01Ld 6NjlDHh8k6TTdHl8m1/8O//LcKgaYLn9Y2q9E0HrGD+j4ayKOKT5NRdu2sqbJcxmnwOwLjfhSC97 RhnmkLyZiOt1p7Qbz+TjKzJHqHjtPFwXhGqNQAhHEzpGB9c95R4w6tTfYFaZF6pdz1/j3fjEL16v EiVVR1rPkZgjK0WNyV7pcFe+ssGUoJVGON09uNDgea2JC3P3pjZIYS/5A+25KbfVU/by3/c2iIHM F2bwoHZo7q+KVIeIIWfaNgacxUSy3bWYxefzHJQOVJzgcSxMgyEhu1/rdU1t/SWu+yxj6TsAX9Ie 1jL4T/fqU5aVFbjM9V+ElimW/7I5hKmOBCf3ycaeEs42il/IELhxeiJVldcG5ASVddvwdq0AvyxM Y6A+Z6ElJAUgur44HigTDnZ2pP5lFawbDxpzYifNwA/+CbHAXBYyGbjeBSfLpCY7lXqKxBfGX5E+ 7k0kljwj3V0VROjpTQuMHNi5DO10BOGC1ZJTa6P2ogp9kacJnWQ52TaV/A== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 21:42:34 -0000 --Apple-Mail-3DF5FB12-53D8-4AD4-B0BD-A86336AC227A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Me too. 2. -- Christian Huitema=20 > On Jun 21, 2019, at 1:24 PM, Eric Kinnear wrote: >=20 > (2) would be fine for me! >=20 > Thanks, > Eric >=20 >=20 >> On Jun 21, 2019, at 1:23 PM, Nick Banks wrote: >>=20 >> Works for me as well. >> =20 >> - Nick >> =20 >> From: QUIC On Behalf Of Roberto Peon >> Sent: Friday, June 21, 2019 1:21 PM >> To: David Schinazi ; Ian Swett >> Cc: IETF QUIC WG ; Martin Thomson >> Subject: Re: Consensus Call: More Connection ID Space #2736 >> =20 >> Works for me. >> -=3DR >> =20 >> From: QUIC on behalf of David Schinazi >> Date: Friday, June 21, 2019 at 1:02 PM >> To: Ian Swett >> Cc: IETF QUIC WG , Martin Thomson >> Subject: Re: Consensus Call: More Connection ID Space #2736 >> =20 >> +1 to what Ian said. (2) seems like a good path forward >> =20 >> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett wrote: >> I think the 3 options I see as well reasoned are:=20 >> 1) Keep the status quo because we think we can put what we really need in= to 18 bytes if we try. >> 2) Change to a 1 byte length per CID and a max of 20, which gives us a fe= w extra bytes for cleartext server id and/or key rotation/etc. >> 3) Change to a 1 byte length per CID and a max of 36, because we want be a= ble to put 2 encrypted routing IDs in a single CID. >> =20 >> 2 is my preferred option, though I can live with either of 1 or 3. >> =20 >> Deciding sooner would be strictly better than later, since this is blocki= ng us(Chrome/Google) actually supporting varlen CIDs. >> =20 >> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote:= >> That seems a little high. I think that Ian's principle here is what shou= ld guide us: what is the minimum you can handle? What I've heard is that 18= might have been workable, but it was REALLY close to the edge to the point t= hat you weren't confident it was enough, even in the near term.. But that s= uggests that 20 is workable. >>=20 >> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >> > so do I hear consensus emerging around 32B in v1, or should I leave the= =20 >> > 18B limit in v1 for now and punt out that discussion? >> >=20 >> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel w= rote: >> > >=20 >> > >=20 >> > > > On 18. Jun 2019, at 05:33, Marten Seemann wrote: >> > > >=20 >> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we de= cide to increase the connection ID length to a larger value (which I'm still= not convinced that this is really necessary). >> > >=20 >> > > This would be easy if we change the encoding of the connection ID le= ngth, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While we ca= n not encode one or two byte connection IDs in long header packets, we can s= till use them in short header packets. >> > >=20 >> > > This split between long and short header also allows to use much lon= ger connection IDs after the handshake. >> > > I don=E2=80=99t see much use in it, but it may take off some fear th= at 24/32/36/48/60 byte connection IDs might not be long enough in the future= . >> > >=20 >> > > >=20 >> > > > There are two main reasons to keep the compressed encoding: >> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect tha= t all / most values will be used in practice, so we won't expose any bits on= the wire that identify a packet as "QUIC traffic" by having a predictable v= alue. >> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an impleme= ntation still needs to be able to deal with connection ID lengths of 255 byt= es, just to be able to send Version Negotiation packets. To me, it seems abs= urd to write a QUIC implementation that is able to handle packets with a com= bined connection ID overhead of 510 bytes. Since VNPs are supposed to be sen= t in response to any Long Header packet, you'd have to put some careful thou= ght into the design of your data types to avoid this becoming a DoS vector. >> > > >=20 >> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema wrote: >> > > > I too agree that using one byte in the invariant is preferable to t= he current "compressed 4 bits" solution. >> > > >=20 >> > > > Regarding the "CID length limit", I thing there are two issues: tr= ansmission overhead, and costs to the community. >> > > >=20 >> > > > I am not too concerned with the transmission overhead, as we have t= here the right mix of costs and incentives. Servers who chose to use longer C= ID will get more transmission overhead, and thus transmission less efficient= ly than their competitors. They may chose to use longer CID as a trade-off b= etween transmission efficiency and ease of management. Competition will sort= that out. I note that YouTube is apparently doing fine with smallish CID, s= o I trust that there will be competition. >> > > >=20 >> > > > I am much more concerned with the shared costs, which are a variat= ion of the "tragedy of the commons". Dmitry explained those costs well in a p= revious message. The simpler implementation is to make the "cid_t a fixed-si= ze object that can fit the largest CID and eat the overhead for all CIDs." B= ut each connection object carries a large number of instances of the CID typ= e. Having a very large max CID would imply a large overhead. The alternative= is to "Make cid_t a variable-size object", but too affects performance. >> > > >=20 >> > > > Hence the push-back. I would personally prefer a max size of 16, a= nd I think that 32 is the highest practical limit. >> > > >=20 >> > > > -- Christian Huitema >> > > >=20 >> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >> > > >> What I think people are saying so far: >> > > >>=20 >> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or= 48} >> > > >>=20 >> > > >> 2) Representation of CID length as a byte is still OK, thus a QUI= C v2 could use longer CIDs as needed by changing the spec while keeping the i= nvariants=E2=80=A6 invariant. >> > > >>=20 >> > > >>=20 >> > > >> That seems reasonable to me / I=E2=80=99d still support that. >> > > >>=20 >> > > >> -=3DR >> > > >>=20 >> > > >>=20 >> > > >> From: QUIC on behalf of "Lubashev, Igor" <= ilubashe@akamai.com> >> > > >> Date: Monday, June 17, 2019 at 8:55 AM >> > > >> To: Ian Swett , Mikkel Fa= hn=C3=B8e J=C3=B8rgensen >> > > >> Cc: Dmitri Tikhonov , Christian Huit= ema , "Philipp S. Tiesel" , Mike Bi= shop , Martin Thomson , Marten Seem= ann , Lars Eggert , QUIC WG , Martin Duke >, Kazuho Oku >> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 i= s likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably= be a factor of 8, so 32 or 24?). >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> We are firmly committed for using CID for in-cluster load balanci= ng / anycast pop routing. This discussion is taking us, however, to a new te= rritory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in a= n overlay network=E2=80=9D. This is a very interesting topic, but I would he= sitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC= v1. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> =E2=80=A2 Igor >> > > >>=20 >> > > >>=20 >> > > >> From: Ian Swett >> > > >>=20 >> > > >> My intuition says making the change to the invariants is the righ= t thing to do, but I don't feel that strongly. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> However, I'd like the max size to be smaller than 48(but larger t= han 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggest= ed 32, which is better, but I don't believe the server needs to use a separa= te block cipher when giving out connection IDs, because I believe it's impra= ctical for the load balancer and server to be that decoupled. The server has= to give out a CID that the load balancer will use to route back to the serv= er, so they have to share enough an encryption key/algorithm. I can imagine n= esting load balancers, but that's well in the range of QUIC v2 from my persp= ective. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> Whatever we do, I'd really prefer to resolve this sooner rather t= han later and be truly done with it. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: >> > > >>=20 >> > > >> Since it is more likely that you pay for egress traffic than ingr= ess traffic, the motivation to keep CID=E2=80=99s small is limited. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> I do think the invariants should allow for long CID=E2=80=99s as p= roposed, and that the long header overhead is not important... >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> But for QUIC v1, if we allow for a long CID, a rush to market wil= l set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> I good reference on an algorithm like suggested by Christian woul= d go a long way. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> If CID length 18 turns out to be not enough, we can add a QUIC v2= . It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versi= ons soon. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> If CID length negotiation is needed, this could be done via QUIC v= ersions. For example two functionally equivalent versions, but one with long= er CID=E2=80=99s. This would also allow routers to deal with changes in CID l= engths. A negotiated TP would not (easily) allow for that and aside I do not= think CID length in TP is the way to go. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> Mikkel >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wro= te: >> > > >>=20 >> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hui= tema :=20 >> > > >> >=20 >> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=20 >> > > >> >=20 >> > > >> > > _If_ we are to allow loose coupling between a load balancer a= nd a=20 >> > > >> > > server, each of the two should be given the freedom to choose= it's own=20 >> > > >> > > CID encryption scheme. Because all the standardized block cip= hers are=20 >> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the ma= ximum CID=20 >> > > >> > > length of QUIC needs to be double amount of that, plus one or= two=20 >> > > >> > > bytes for each of the two for identifying the CID encryption k= eys. For=20 >> > > >> > > key identification and other supplemental use, we currently a= llocate 2=20 >> > > >> > > bytes (18-16=3D2).=20 >> > > >> >=20 >> > > >> > That reasoning is based on the assumption that both the load ba= lancer=20 >> > > >> > and the server must use a block cipher with 128 bit block lengt= h in=20 >> > > >> > order to encrypt the CID. If they were constrained to stay with= in a=20 >> > > >> > short global limit, they could use different sets of algorithms= .=20 >> > > >> >=20 >> > > >> > Assume for example that we split the CID between 32 bits encodi= ng the=20 >> > > >> > number of the server in the server farm, and 64 bit encoding th= e=20 >> > > >> > connection number for the server. The server can pick a random v= alue for=20 >> > > >> > the connection number, and use a hash table. The load balancer c= ould use=20 >> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit o= f the CID=20 >> > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong e= ncryption.=20 >> > > >> >=20 >> > > >> > Or assume that the server wants to use short CID. We now split t= he CID=20 >> > > >> > between 32 bit for the server number in the farm, and 32 bit fo= r the=20 >> > > >> > connection number in the server. The server builds that connect= ion=20 >> > > >> > number by using a 32 bit variant of FFX. The load balancer also= uses a=20 >> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial ve= ctor for=20 >> > > >> > this FFX encryption.=20 >> > > >> >=20 >> > > >> > These are just two examples. And yes you may want to add 2 byte= s for key=20 >> > > >> > identification, etc. In both encryption algorithms, you can fee= d these=20 >> > > >> > two bytes as additional IV for the FFX algorithm. And in both c= ases, we=20 >> > > >> > are well below the 18 byte limit.=20 >> > > >> >=20 >> > > >> > Yes, that requires some creative engineering. But it is not roc= ker=20 >> > > >> > science. And it seems better than carrying tons of overhead in t= he=20 >> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP.=20 >> > > >>=20 >> > > >> I agree that it would not be the end of the world for the load=20= >> > > >> balancers if we decide to stick on the 18-byte limit. However, as= you=20 >> > > >> state, it requires some creativeness.=20 >> > > >>=20 >> > > >> To me it seems that the question is if we have a strong reason to= =20 >> > > >> require some people to be creative, for all the versions of QUIC i= n=20 >> > > >> the future. I personally think that there isn't a strong reason,=20= >> > > >> because people can use shorter CIDs regardless of the decision we= =20 >> > > >> make. IIUC, the overhead that everyone needs to accept is:=20 >> > > >>=20 >> > > >> * one byte increase in the long header packets=20 >> > > >> * the minimum size of short header packets becoming slightly grea= ter=20 >> > > >> (otherwise, the peer might not be able to send a stateless reset)= =20 >> > > >>=20 >> > > >> I'd say that the first bullet point is negligible. The second poi= nt=20 >> > > >> could also be, because I'd assume that the only frequently-sent=20= >> > > >> packets that require additional padding is the ACK-only packets, b= ut=20 >> > > >> there's no reason to pad ACK-only packets in hope that you'd see a= =20 >> > > >> stateless reset.=20 >> > > >>=20 >> > > >> Therefore, my (not-so-strong) preference has been to provide extr= a=20 >> > > >> room, so that some people with necessity can use longer CIDs.=20 >> > > >>=20 >> > > >> >=20 >> > > >> > -- Christian Huitema=20 >> > > >> >=20 >> > > >> >=20 >> > > >> >=20 >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> --=20 >> > > >> Kazuho Oku >> > > >>=20 >> > >=20 >> > > AVE! >> > > Philipp S. Tiesel >> > >=20 >> > > --=20 >> > > Philipp S. Tiesel=20 >> > > https://philipp.tiesel.net/ >> > > >>=20 >=20 --Apple-Mail-3DF5FB12-53D8-4AD4-B0BD-A86336AC227A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Me too. 2.

-- Christian Huitema 

On Ju= n 21, 2019, at 1:24 PM, Eric Kinnear <ekinnear=3D40apple.com@dmarc.ietf.org> wrote:
(2) would be fine for me= !

Thanks,
Eric


On Jun 21, 2019, at 1:23 PM, Ni= ck Banks <nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:

Works fo= r me as well.
 
- Nick<= /o:p>
 
=
From: QUIC <quic-bounces@ietf.org> On Behalf Of Roberto Peon
Sent: Friday, June 21, 2019 1:21 PMTo: = ;David Schinazi <dschinazi.ietf@gmail.com>; Ian Swett <ianswett=3D40google.com@dmarc= .ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>; Martin Thomson <mt@lowentropy.net>
Subject: Re: Consen= sus Call: More Connection ID Space #2736
 
Works for me.
-=3DR
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri= , sans-serif;" class=3D""> 
<= b class=3D"">From: QUIC <quic-bounces@ietf.org<= /a>> on behalf of David Schinazi <dsch= inazi.ietf@gmail.com>
Date: Friday, June 21, 2019 at 1:02 PMTo: Ian Swett <ianswett= =3D40google.com@dmarc.ietf.org>
Cc: IETF QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
Subject: Re: Consensus Call: More Connection= ID Space #2736
 
+1 to what Ian said. (2) seems like a good pat= h forward
 
On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:
I think the 3 options I see as well reasoned are: 
1) Keep the status quo because w= e think we can put what we really need into 18 bytes if we try.
2) Change to= a 1 byte length per CID and a max of 20, which gives us a few extra bytes f= or cleartext server id and/or key rotation/etc.
<= /div>
3) Change to a 1 byte length= per CID and a max of 36, because we want be able to put 2 encrypted routing= IDs in a single CID.
 
2 is my preferred option, though I can live with= either of 1 or 3.
 
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri= , sans-serif;" class=3D"">Deciding sooner would be strictly better than late= r, since this is blocking us(Chrome/Google) actually supporting varlen CIDs.=
 
On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:

That seems a little high.  I think that Ian's principle here is what= should guide us: what is the minimum you can handle?  What I've heard i= s that 18 might have been workable, but it was REALLY close to the edge to t= he point that you weren't confident it was enough, even in the near term..&n= bsp; But that suggests that 20 is workable.

On W= ed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I he= ar consensus emerging around 32B in v1, or should I leave the 
> 18B limit in v1 for n= ow and punt out that discussion?
> 
> On Tue, Jun 18, 2019 at 1:24 A= M Philipp S. Tiesel <philipp@= tiesel.net> wrote:
> > 
> > 
> >  > On 18. Jun 2019, a= t 05:33, Marten Seemann <martenseemann@gmail.com> wrote:
> >  > 
> >&nb= sp; > I'd prefer keeping the "compressed 4 bits" solution, even if we dec= ide to increase the connection ID length to a larger value (which I'm still n= ot convinced that this is really necessary).
> > 
> >  Th= is would be easy if we change the encoding of the connection ID length, e..g= ., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not enco= de one or two byte connection IDs in long header packets, we can still use t= hem in short header packets.
> > 
> >  This split between= long and short header also allows to use much longer connection IDs after t= he handshake.
> >  I don=E2=80=99t see much use in i= t, but it may take off some fear that 24/32/36/48/60 byte connection IDs mig= ht not be long enough in the future.
> > 
> >  > 
> >  &= gt; There are two main reasons to keep the compressed encoding:
> >  > =E2=80=A2 In the compressed encoding, we can reasonab= ly expect that all / most values will be used in practice, so we won't expos= e any bits on the wire that identify a packet as "QUIC traffic" by having a p= redictable value.
> >  > =E2=80=A2 The 1-byte en= coding has the disadvantage that an implementation still needs to be able to= deal with connection ID lengths of 255 bytes, just to be able to send Versi= on Negotiation packets. To me, it seems absurd to write a QUIC implementatio= n that is able to handle packets with a combined connection ID overhead of 5= 10 bytes. Since VNPs are supposed to be sent in response to any Long Header p= acket, you'd have to put some careful thought into the design of your data t= ypes to avoid this becoming a DoS vector.
> >  >=  
> >&= nbsp; > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net> wrote:
> >  > I too agree that using one byte in the invariant= is preferable to the current "compressed 4 bits" solution.
&g= t; >  > 
> >  > Regarding the "CID length limit", I thing there= are two issues: transmission overhead, and costs to the community.
> >  > 
> >  > I am not too concerned with the transmi= ssion overhead, as we have there the right mix of costs and incentives. Serv= ers who chose to use longer CID will get more transmission overhead, and thu= s transmission less efficiently than their competitors. They may chose to us= e longer CID as a trade-off between transmission efficiency and ease of mana= gement. Competition will sort that out. I note that YouTube is apparently do= ing fine with smallish CID, so I trust that there will be competition.
> >  > 
> >  > I am much more concerned with the sh= ared costs, which are a variation of the "tragedy of the commons". Dmitry ex= plained those costs well in a previous message. The simpler implementation i= s to make the "cid_t a fixed-size object that can fit the largest CID and ea= t the overhead for all CIDs." But each connection object carries a large num= ber of instances of the CID type. Having a very large max CID would imply a l= arge overhead. The alternative is to "Make cid_t a variable-size object", bu= t too affects performance.
> >  > 
> >  > Henc= e the push-back. I would personally prefer a max size of 16, and I think tha= t 32 is the highest practical limit.
> >  > 
> > = > -- Christian Huitema
> >  > 
> >  > On 6= /17/2019 9:16 AM, Roberto Peon wrote:
> >  >>= What I think people are saying so far:
> >  >&g= t; 
> >= ;  >> 1) QUIC v1 would limit CID length to something one of {32, 3= 6, or 48}
> >  >> 
> >  >> 2) Representa= tion of CID length as a byte is still OK, thus a QUIC v2 could use longer CI= Ds as needed by changing the spec while keeping the invariants=E2=80=A6 inva= riant.
> >  >> 
> >  >> 
> >  >> Th= at seems reasonable to me / I=E2=80=99d still support that.
&g= t; >  >> > >  >> -=3DR
> >  >= ;> 
> &= gt;  >> 
> >  >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, I= gor" <ilubashe@akamai.com>
> >  >> Date: Monday, June 17, 2019 at 8= :55 AM
> >  >> To: Ian Swett <ianswett=3D<= a href=3D"mailto:40google.com@dmarc.ietf.org" target=3D"_blank" style=3D"col= or: purple; text-decoration: underline;" class=3D"">40google.com@dmarc.ietf.= org>, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> >  &= gt;> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Philipp S. T= iesel" <philipp@tiesel.net>, Mike Bishop <mbishop= @evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <martenseemann@gmail.com>, Lars Eggert <= ;lars@eggert.org>, QUIC WG &= lt;quic@ietf.org>, Martin Duke= <martin.h.duke@gmail.co= m<mailto:martin..h.= duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.com>
> >  >&g= t; Subject: RE: Consensus Call: More Connection ID Space #2736
> >  >> =
> >  >> 
> >  >> 
> >  >> My take i= s similar =E2=80=93 48 is probably excessive, while 32 is likely the upper l= imit of =E2=80=9Creasonable=E2=80=9D (it should probably be a factor of 8, s= o 32 or 24?).
> >  >> 
> >  >> 
> >  >= > 
> &= gt;  >> We are firmly committed for using CID for in-cluster load= balancing / anycast pop routing. This discussion is taking us, however, to a= new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routi= ng in an overlay network=E2=80=9D. This is a very interesting topic, but I w= ould hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D i= n QUIC v1.
> >  >> 
> >  >> 
> >  >>=  
> >&= nbsp; >> =E2=80=A2 Igor
> >  >> 
> >  &g= t;> 
>= >  >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >  >> 
> >  >> My intuition says making the chang= e to the invariants is the right thing to do, but I don't feel that strongly= .
> >  >> 
> >  >> 
> >  >> 
> >  &g= t;> However, I'd like the max size to be smaller than 48(but larger than 1= 8). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32= , which is better, but I don't believe the server needs to use a separate bl= ock cipher when giving out connection IDs, because I believe it's impractica= l for the load balancer and server to be that decoupled. The server has to g= ive out a CID that the load balancer will use to route back to the server, s= o they have to share enough an encryption key/algorithm. I can imagine nesti= ng load balancers, but that's well in the range of QUIC v2 from my perspecti= ve.
> >  >> 
> >  >> 
> >  >> 
> >  &= gt;> Whatever we do, I'd really prefer to resolve this sooner rather than= later and be truly done with it.
> >  >> 
> > = ; >> 
= > >  >> <= br class=3D"">> >  >> On Mon, Jun 17, 2019 at 2:51 AM Mikke= l Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> >  >> 
> >&nbs= p; >> Since it is more likely that you pay for egress traffic than ing= ress traffic, the motivation to keep CID=E2=80=99s small is limited.
> >  >> <= /span>
> >  >> 
> >  >> 
> >  >> I d= o think the invariants should allow for long CID=E2=80=99s as proposed, and t= hat the long header overhead is not important...
> >&nbs= p; >> 
> >  >> =
> >  >> 
> >  >> But for QUIC v1, if we= allow for a long CID, a rush to market will set precedence and long CID=E2=80= =99s will ossify in all kinds of stacks.
> >  >&= gt; 
> &g= t;  >> 
> >  >> <= /span>
> >  >> I good reference on an algorit= hm like suggested by Christian would go a long way.
> >&= nbsp; >> 
> >  >> 
> >  >> 
> >  >> If CID length 18 tur= ns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are n= ot looking for excuses to upgrade QUIC versions soon.
> >= ;  >> 
> >  >> 
> >  >> 
> >  >> If CID length neg= otiation is needed, this could be done via QUIC versions. For example two fu= nctionally equivalent versions, but one with longer CID=E2=80=99s. This woul= d also allow routers to deal with changes in CID lengths. A negotiated TP wo= uld not (easily) allow for that and aside I do not think CID length in TP is= the way to go.
> >  >> 
> >  >> 
> >  &g= t;> 
>= >  >> Mikkel
> >  >> 
> >  >= > 
> &= gt;  >> 
> >  >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:> >  >>&= nbsp;
> >  >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11= :09 Christian Huitema <huite= ma@huitema.net>: > >  >> > 
> >  >> > On 6/15/2019 1= 0:55 PM, Kazuho Oku wrote: 
> >  >> > 
> >  >> > > _If_ w= e are to allow loose coupling between a load balancer and a 
> >  >> &g= t; > server, each of the two should be given the freedom to choose it's o= wn 
> >= ;  >> > > CID encryption scheme. Because all the standardiz= ed block ciphers are 
> >  >> > > now 128-bits (=3D 16 bytes), th= at naturally means that the maximum CID 
> >  >> > > length of QU= IC needs to be double amount of that, plus one or two 
> >  >> > >= ; bytes for each of the two for identifying the CID encryption keys. For 
> > = ; >> > > key identification and other supplemental use, we curre= ntly allocate 2 
> >  >> > > bytes (18-16=3D2). 
> >  >> ><= span class=3D"Apple-converted-space"> 
> >&n= bsp; >> > That reasoning is based on the assumption that both the l= oad balancer 
> >  >> > and the server must use a block cipher with 1= 28 bit block length in > >  >> > order to encrypt the CID. If they w= ere constrained to stay within a =
> >  >> > short global limit, they= could use different sets of algorithms. 
> >  >> > 
> >  >> &g= t; Assume for example that we split the CID between 32 bits encoding the 
> > = ; >> > number of the server in the server farm, and 64 bit encoding= the 
> &= gt;  >> > connection number for the server. The server can pic= k a random value for 
> >  >> > the connection number, and use a has= h table. The load balancer could use&n= bsp;
> >  >> > a 32 bit variant of t= he FFX algorithm, using the lower 64 bit of the CID 
> >  >> > as an= initial vector. Voila, 96 CID, with demonstrably strong encryption. 
> >  &g= t;> > 
> >  >> > Or assume that the server wants to use short C= ID. We now split the CID <= br class=3D"">> >  >> > between 32 bit for the server nu= mber in the farm, and 32 bit for the&n= bsp;
> >  >> > connection number in= the server. The server builds that connection 
> >  >> > number by u= sing a 32 bit variant of FFX. The load balancer also uses a 
> >  >> &g= t; 32 bit variant, using the lower 32 bit of the CID as initial vector for 
> >&nb= sp; >> > this FFX encryption.=  
> >  >> > 
> >  >> >= These are just two examples. And yes you may want to add 2 bytes for key 
> >&nbs= p; >> > identification, etc. In both encryption algorithms, you can= feed these 
> >  >> > two bytes as additional IV for the FFX algori= thm. And in both cases, we 
> >  >> > are well below the 18 byte lim= it. 
> &g= t;  >> > > >  >> > Yes, that requires some creative e= ngineering. But it is not rocker =
> >  >> > science. And it seems be= tter than carrying tons of overhead in the 
> >  >> > header, and be= coming less efficient than HTTP2/TLS/TCP. 
> >  >> 
> >  >> I agre= e that it would not be the end of the world for the load 
> >  >> balan= cers if we decide to stick on the 18-byte limit. However, as you 
> >  >>= state, it requires some creativeness.=  
> >  >> 
> >  >> To me it s= eems that the question is if we have a strong reason to 
> >  >> requir= e some people to be creative, for all the versions of QUIC in 
> >  >> t= he future. I personally think that there isn't a strong reason, 
> >  >>= because people can use shorter CIDs regardless of the decision we 
> >  >= > make. IIUC, the overhead that everyone needs to accept is: 
> >  >>=  
> >&= nbsp; >> * one byte increase in the long header packets 
> >  >> *= the minimum size of short header packets becoming slightly greater 
> >  >= ;> (otherwise, the peer might not be able to send a stateless reset) 
> > = >> 
&= gt; >  >> I'd say that the first bullet point is negligible. T= he second point 
> >  >> could also be, because I'd assume that the only f= requently-sent 
> >  >> packets that require additional padding is the A= CK-only packets, but 
> >  >> there's no reason to pad ACK-only packets= in hope that you'd see a =
> >  >> stateless reset. 
> >  >> 
> >  &= gt;> Therefore, my (not-so-strong) preference has been to provide extra 
> >&nb= sp; >> room, so that some people with necessity can use longer CIDs. 
> >&nb= sp; >> 
> >  >> > <= /span>
> >  >> > -- Christian Huitema 
> > = >> > 
> >  >> > =
> >  >> > 
> >  >> 
> >  >&= gt; 
> &g= t;  >> 
> >  >> --&nbs= p;
> >  >> Kazuho Oku
&g= t; >  >> > > 
> >  AVE!
> >  Philipp S. Ties= el
> > 
> >  --&nbs= p;
> >  Philipp S. Tiesel 
> > https://philipp.ties= el.net/
> >


= --Apple-Mail-3DF5FB12-53D8-4AD4-B0BD-A86336AC227A-- From nobody Fri Jun 21 16:17:13 2019 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 63E2E120266 for ; Fri, 21 Jun 2019 16:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 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, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIJF-7Y7-aub for ; Fri, 21 Jun 2019 16:17:09 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 AAD751201CA for ; Fri, 21 Jun 2019 16:17:08 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id m10so12324825edv.6 for ; Fri, 21 Jun 2019 16:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=V5784/FzZsExv1GWJB5D66kQsZS4NrXYx8SKQk/fDQE=; b=jMP1JZ0dZXosPirEveGD7/iUYM4SnFfNd5LkpjIvlKfhD2Mc5Nb1NnbdpDLcIUap7H qTz3vwlVa+Q2BSR7cQhQsbFvZCsQcduNTBriqBq7UAC1sT2M0VJ+gveyPaozKEvICr3D sVAAtFao+WuJY+Vc6XiVyxLRbERGLOjenAcbTgmTOKtnrS0aEvB3LxdxRkyhOSTS9mUW uficjqpdn/L3zsWTNbNTF6gqF7eOh33mhPLDS9cA6WoGZQXn9NLO+NmrqzsEwcbJz4XI VH/iZMCFMf/+Vox6UqSTXgUrTBVbjsDK4oDl3OE2Nse3AFEq8ClI1osduwnDvKaTrg6P +ciQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=V5784/FzZsExv1GWJB5D66kQsZS4NrXYx8SKQk/fDQE=; b=EO7tAIkU9oZ0JCFquqB2a5ld+Eufu1GK85iLC/NHH5tzLFDLCYYKz4jlMFZI+4njiv liCURhOEul1xaVIL2HccYEmGuiAlEbtnaWFtbe0bFzRA184FRmfwGIHscAwIwNq1nZxH 3GdTl6Czmh2g43zFHwDxGispnPqIX2Y7TBoIZ3SVzmBAgXTeXFjDmCnZFDVE6BOfDSQg UAoZ8y53wcLX6JErLOIwQJSjHaQLJ7AQcREZH13s6v0KdUM4h+w6nDt3fyBB3Cxl2tQn 253oscush6qbWl7ldn8FRzwOSAncYxK74UbO0jokXLBu1X4ni5vpt4zdqBLWcuQKNCvq ul3A== X-Gm-Message-State: APjAAAUHV3smq5VENErYDTmz70kYwXA9X4k3fYjOAdF8whHGW6wpxvWu rfpIWhazYqQvPQ/wueePPEv9FNhZVjJhweWq0/M= X-Google-Smtp-Source: APXvYqwZocuLBH7wGXiwIRYoHcGCL2jSbTuWLKcgfysV6nUz3QBfQrEvtijFusML4GJqIx7Ih9vCnPkh5T36r5HHmhQ= X-Received: by 2002:a17:906:5017:: with SMTP id s23mr107308523ejj.17.1561159027069; Fri, 21 Jun 2019 16:17:07 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Jun 2019 16:17:05 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 21 Jun 2019 16:17:05 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Christian Huitema , Eric Kinnear Cc: Nick Banks , David Schinazi , Roberto Peon , IETF QUIC WG , Ian Swett , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000003f1882058bdda903" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 23:17:12 -0000 --0000000000003f1882058bdda903 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Makes sense 2 me 2 On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) wrote: Me too. 2. -- Christian Huitema On Jun 21, 2019, at 1:24 PM, Eric Kinnear < ekinnear=3D40apple.com@dmarc.ietf.org> wrote: (2) would be fine for me! Thanks, Eric On Jun 21, 2019, at 1:23 PM, Nick Banks < nibanks=3D40microsoft.com@dmarc.ietf.org> wrote: Works for me as well. - Nick *From:* QUIC *On Behalf Of *Roberto Peon *Sent:* Friday, June 21, 2019 1:21 PM *To:* David Schinazi ; Ian Swett < ianswett=3D40google.com@dmarc..ietf.org > *Cc:* IETF QUIC WG ; Martin Thomson *Subject:* Re: Consensus Call: More Connection ID Space #2736 Works for me. -=3DR *From: *QUIC on behalf of David Schinazi < dschinazi.ietf@gmail.com> *Date: *Friday, June 21, 2019 at 1:02 PM *To: *Ian Swett *Cc: *IETF QUIC WG , Martin Thomson *Subject: *Re: Consensus Call: More Connection ID Space #2736 +1 to what Ian said. (2) seems like a good path forward On Fri, Jun 21, 2019 at 1:00 PM Ian Swett wrote: I think the 3 options I see as well reasoned are: 1) Keep the status quo because we think we can put what we really need into 18 bytes if we try. 2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc. 3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID. 2 is my preferred option, though I can live with either of 1 or 3. Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs. On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote: That seems a little high. I think that Ian's principle here is what should guide us: what is the minimum you can handle? What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term.. But that suggests that 20 is workable. On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > so do I hear consensus emerging around 32B in v1, or should I leave the > 18B limit in v1 for now and punt out that discussion? > > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel wrote: > > > > > > > On 18. Jun 2019, at 05:33, Marten Seemann wrote: > > > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary). > > > > This would be easy if we change the encoding of the connection ID length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets. > > > > This split between long and short header also allows to use much longer connection IDs after the handshake. > > I don=E2=80=99t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future. > > > > > > > > There are two main reasons to keep the compressed encoding: > > > =E2=80=A2 In the compressed encoding, we can reasonably expect that = all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value= . > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an implement= ation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector. > > > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < huitema@huitema.net> wrote: > > > I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution. > > > > > > Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community. > > > > > > I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition. > > > > > > I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance. > > > > > > Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit. > > > > > > -- Christian Huitema > > > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > >> What I think people are saying so far: > > >> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48} > > >> > > >> 2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant. > > >> > > >> > > >> That seems reasonable to me / I=E2=80=99d still support that. > > >> > > >> -=3DR > > >> > > >> > > >> From: QUIC > on behalf of "Lubashev, Igor" > > >> Date: Monday, June 17, 2019 at 8:55 AM > > >> To: Ian Swett , Mikkel Fahn= =C3=B8e J=C3=B8rgensen > > >> Cc: Dmitri Tikhonov , Christian Huitema , "Philipp S. Tiesel" , Mike Bishop , Martin Thomson , Marten Seemann , Lars Eggert , QUIC WG , Martin Duke >, Kazuho Oku > > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > >> > > >> > > >> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 is = likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a fa= ctor of 8, so 32 or 24?). > > >> > > >> > > >> > > >> We are firmly committed for using CID for in-cluster load balancing / anycast pop routing. This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing i= n an overlay network=E2=80=9D. This is a very interesting topic, but I would hesitate to= attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > > >> > > >> > > >> > > >> =E2=80=A2 Igor > > >> > > >> > > >> From: Ian Swett > > >> > > >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly.. > > >> > > >> > > >> > > >> However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective. > > >> > > >> > > >> > > >> Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it. > > >> > > >> > > >> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: > > >> > > >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited. > > >> > > >> > > >> > > >> I do think the invariants should allow for long CID=E2=80=99s as pr= oposed, and that the long header overhead is not important... > > >> > > >> > > >> > > >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > > >> > > >> > > >> > > >> I good reference on an algorithm like suggested by Christian would go a long way. > > >> > > >> > > >> > > >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versio= ns soon. > > >> > > >> > > >> > > >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in= CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go. > > >> > > >> > > >> > > >> Mikkel > > >> > > >> > > >> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote= : > > >> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huite= ma : > > >> > > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > >> > > > >> > > _If_ we are to allow loose coupling between a load balancer and a > > >> > > server, each of the two should be given the freedom to choose it's own > > >> > > CID encryption scheme. Because all the standardized block ciphers are > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID > > >> > > length of QUIC needs to be double amount of that, plus one or two > > >> > > bytes for each of the two for identifying the CID encryption keys. For > > >> > > key identification and other supplemental use, we currently allocate 2 > > >> > > bytes (18-16=3D2). > > >> > > > >> > That reasoning is based on the assumption that both the load balancer > > >> > and the server must use a block cipher with 128 bit block length in > > >> > order to encrypt the CID. If they were constrained to stay within a > > >> > short global limit, they could use different sets of algorithms. > > >> > > > >> > Assume for example that we split the CID between 32 bits encoding the > > >> > number of the server in the server farm, and 64 bit encoding the > > >> > connection number for the server. The server can pick a random value for > > >> > the connection number, and use a hash table. The load balancer could use > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption. > > >> > > > >> > Or assume that the server wants to use short CID. We now split the CID > > >> > between 32 bit for the server number in the farm, and 32 bit for the > > >> > connection number in the server. The server builds that connectio= n > > >> > number by using a 32 bit variant of FFX. The load balancer also uses a > > >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for > > >> > this FFX encryption. > > >> > > > >> > These are just two examples. And yes you may want to add 2 bytes for key > > >> > identification, etc. In both encryption algorithms, you can feed these > > >> > two bytes as additional IV for the FFX algorithm. And in both cases, we > > >> > are well below the 18 byte limit. > > >> > > > >> > Yes, that requires some creative engineering. But it is not rocke= r > > >> > science. And it seems better than carrying tons of overhead in th= e > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. > > >> > > >> I agree that it would not be the end of the world for the load > > >> balancers if we decide to stick on the 18-byte limit. However, as you > > >> state, it requires some creativeness. > > >> > > >> To me it seems that the question is if we have a strong reason to > > >> require some people to be creative, for all the versions of QUIC in > > >> the future. I personally think that there isn't a strong reason, > > >> because people can use shorter CIDs regardless of the decision we > > >> make. IIUC, the overhead that everyone needs to accept is: > > >> > > >> * one byte increase in the long header packets > > >> * the minimum size of short header packets becoming slightly greate= r > > >> (otherwise, the peer might not be able to send a stateless reset) > > >> > > >> I'd say that the first bullet point is negligible. The second point > > >> could also be, because I'd assume that the only frequently-sent > > >> packets that require additional padding is the ACK-only packets, bu= t > > >> there's no reason to pad ACK-only packets in hope that you'd see a > > >> stateless reset. > > >> > > >> Therefore, my (not-so-strong) preference has been to provide extra > > >> room, so that some people with necessity can use longer CIDs. > > >> > > >> > > > >> > -- Christian Huitema > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> -- > > >> Kazuho Oku > > >> > > > > AVE! > > Philipp S. Tiesel > > > > -- > > Philipp S. Tiesel > > https://philipp.tiesel.net/ > > --0000000000003f1882058bdda903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Makes sense 2 me 2


On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) wrote:

=
Me too. 2.

-- Christian Huitema=C2=A0

On Jun 21, 2019, at 1:24 PM, Eric Kinnear <ekinnear=3D40apple.com@dmarc.ietf.org> wrote:

(2) would be fine for me!

Thanks,
Eric


On Jun 21, 2019, at 1:23 PM, Nick Banks <nibanks=3D40microso= ft.com@dmarc.ietf.org> wrote:

Works for me as well.
=C2=A0
- Nick
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.org>= =C2=A0On Behalf Of=C2=A0Roberto Peon
Sent:=C2=A0F= riday, June 21, 2019 1:21 PM
To:=C2=A0Dav= id Schinazi <dsch= inazi.ietf@gmail.com>; Ian Swett <ianswett=3D40google.com@dmarc..ietf.o= rg>
Cc:=C2=A0IET= F QUIC WG <quic@ietf.org= >; Martin Thomson <mt@lowentropy.n= et>
Subject:=C2=A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
Works for me.
-=3DR
=C2=A0
From:=C2=A0QUIC <quic= -bounces@ietf.org> on behalf of David Schinazi <dschinazi.ietf@gmail.com>
Date:=C2=A0F= riday, June 21, 2019 at 1:02 PM
To:=C2=A0Ian= Swett <ianswett=3D40google.= com@dmarc.ietf.org>
Cc:=C2=A0IET= F QUIC WG <quic@ietf.org>, Martin Thomson <<= a href=3D"mailto:mt@lowentropy.net" style=3D"color:purple;text-decoration:u= nderline" class=3D"">mt@lowentropy.net>
Subject:=C2=A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
+1 to what Ian said. (2) seems like a good path forward
=C2=A0
On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ietf.org<= /a>> wrote:
I think the 3 options I see as well reasoned are:=C2=A0
1) Keep the status quo because we think we can put wha= t we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID.
=C2=A0
2 is my preferred option, though I can live with eithe= r of 1 or 3.
=C2=A0
Deciding sooner would be strictly better than later, s= ince this is blocking us(Chrome/Google) actually supporting varlen CIDs.
=C2=A0
On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote= :

That seems a little high.=C2=A0 I think that Ian's principle here is what should guide us: what is the minimum you can handle?=C2=A0 What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term..=C2=A0 But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the=C2=A0
> 18B limit in v1 for now and punt out that discussion?
>=C2=A0
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote:
> >=C2=A0
> >=C2=A0
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrote:
> >=C2=A0 >=C2=A0
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary).
> >=C2=A0
> >=C2=A0 This would be easy if we change the encoding of the connection ID length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
> >=C2=A0
> >=C2=A0 This split between long and short header also allows to use much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future.
> >=C2=A0
> >=C2=A0 >=C2=A0
> >=C2=A0 > There are two main reasons to keep the compressed encoding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector.
> >=C2=A0 >=C2=A0
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net<= /a>> wrote:
> >=C2=A0 > I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >=C2=A0
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >=C2=A0
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48}
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> 2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still support that.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> -=3DR
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor&= quot; <ilubashe@akamai.com> > >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fa= hn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huit= ema <huitema@huitema.net>, = "Philipp S. Tiesel" <= philipp@tiesel.net>, Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <martenseemann@gmail.com>,= Lars Eggert <lars@eggert.org&= gt;, QUIC WG <quic@ietf.org>= ;, Martin Duke <martin.h.d= uke@gmail.com<mailto:= martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Space #2736
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80= =9D (it should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> We are firmly committed for using CID for in-cluster load balancing / anycast pop routing. This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D. Thi= s is a very interesting topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly..
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mik= kelfj@gmail.com> wrote:
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> I do think the invariants should allow for long CID=E2=80=99s as proposed, and that the long header overhead is not important...
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> I good reference on an algorithm like suggested by Christian would go a long way.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versions soon.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> Mikkel
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:<= br class=3D""> > >=C2=A0 >>=C2=A0=
> >=C2=A0 >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Huitema <huitema@huitema.net>:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > > _If_ we are to allow loose coupling between a load balancer and a=C2=A0
> >=C2=A0 >> > > server, each of the two should be given the freedom to choose it's own=C2=A0
> >=C2=A0 >> > > CID encryption scheme. Because all the standardized block ciphers are=C2=A0
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID= =C2=A0
> >=C2=A0 >> > > length of QUIC needs to be double amount of that, plus one or two=C2=A0
> >=C2=A0 >> > > bytes for each of the two for identifying the CID encryption keys. For=C2=A0
> >=C2=A0 >> > > key identification and other supplemental use, we currently allocate 2=C2=A0
> >=C2=A0 >> > > bytes (18-16=3D2).=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > That reasoning is based on the assumption that both the load balancer=C2=A0
> >=C2=A0 >> > and the server must use a block cipher with 128 bit block length in= =C2=A0
> >=C2=A0 >> > order to encrypt the CID. If they were constrained to stay within a=C2= =A0
> >=C2=A0 >> > short global limit, they could use different sets of algorithms.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Assume for example that we split the CID between 32 bits encoding the=C2= =A0
> >=C2=A0 >> > number of the server in the server farm, and 64 bit encoding the=C2=A0
> >=C2=A0 >> > connection number for the server. The server can pick a random value for=C2= =A0
> >=C2=A0 >> > the connection number, and use a hash table. The load balancer could use=C2= =A0
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID=C2=A0
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption.= =C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Or assume that the server wants to use short CID. We now split the CID= =C2=A0
> >=C2=A0 >> > between 32 bit for the server number in the farm, and 32 bit for the=C2=A0=
> >=C2=A0 >> > connection number in the server. The server builds that connection=C2=A0
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The load balancer also uses a=C2= =A0
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for= =C2=A0
> >=C2=A0 >> > this FFX encryption.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > These are just two examples. And yes you may want to add 2 bytes for key= =C2=A0
> >=C2=A0 >> > identification, etc. In both encryption algorithms, you can feed these=C2=A0
> >=C2=A0 >> > two bytes as additional IV for the FFX algorithm. And in both cases, we= =C2=A0
> >=C2=A0 >> > are well below the 18 byte limit.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Yes, that requires some creative engineering. But it is not rocker=C2= =A0
> >=C2=A0 >> > science. And it seems better than carrying tons of overhead in the=C2= =A0
> >=C2=A0 >> > header, and becoming less efficient than HTTP2/TLS/TCP.=C2=A0
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> I agree that it would not be the end of the world for the load=C2=A0 > >=C2=A0 >> balancers if we decide to stick on the 18-byte limit. However, as you=C2=A0<= /span>
> >=C2=A0 >> state, it requires some creativeness.=C2=A0
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> To me it seems that the question is if we have a strong reason to=C2=A0<= br class=3D""> > >=C2=A0 >> require some people to be creative, for all the versions of QUIC in=C2=A0
> >=C2=A0 >> the future. I personally think that there isn't a strong reason,=C2=A0
> >=C2=A0 >> because people can use shorter CIDs regardless of the decision we=C2=A0
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to accept is:=C2=A0
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> * one byte increase in the long header packets=C2=A0
> >=C2=A0 >> * the minimum size of short header packets becoming slightly greater=C2=A0
> >=C2=A0 >> (otherwise, the peer might not be able to send a stateless reset)=C2=A0<= br class=3D""> > >=C2=A0 >>=C2=A0=
> >=C2=A0 >> I'd say that the first bullet point is negligible. The second point=C2=A0
> >=C2=A0 >> could also be, because I'd assume that the only frequently-sent=C2=A0
> >=C2=A0 >> packets that require additional padding is the ACK-only packets, but=C2=A0
> >=C2=A0 >> there's no reason to pad ACK-only packets in hope that you'd see a=C2=A0
> >=C2=A0 >> stateless reset.=C2=A0
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been to provide extra=C2=A0
> >=C2=A0 >> room, so that some people with necessity can use longer CIDs.=C2=A0
> >=C2=A0 >>=C2=A0=
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > -- Christian Huitema=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=
> >=C2=A0 >> --=C2=A0
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>=C2=A0=
> >=C2=A0
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >=C2=A0
> >=C2=A0 --=C2=A0
> >=C2=A0 Philipp S. Tiesel=C2= =A0
> >=C2=A0https://philipp.tiesel.net/
> >


 --0000000000003f1882058bdda903-- From nobody Fri Jun 21 16:51:20 2019 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 766121201CA for ; Fri, 21 Jun 2019 16:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.252 X-Spam-Level: * X-Spam-Status: No, score=1.252 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, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr7VUNzA6qud for ; Fri, 21 Jun 2019 16:51:14 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 D4E5F12017F for ; Fri, 21 Jun 2019 16:51:13 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id r9so7398740ljg.5 for ; Fri, 21 Jun 2019 16:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AS2tkwcL9NQpVDZqTX2Ed2znYI0FmYd9Tgq+hmU6nlo=; b=rRad7N+mm9IU/XSwq4+mFqvME/eDA7ZIm2JfK59JLNo1j/6pAFXTDHg+mkI1Qno/GX 2XI+l31LweSbxkQXczKxF3Q88UljFEa/iKDTp4nmpiOn6wz/ZuyvoD7njV9hklBbJnS1 y/4n0/OJKL5sSOhAdkDhlWaRGHwQZ5xVZbT+qZIFCV+DfOfIAxbY60CwCOxXayCzaah5 iFbfMpvi6e9ea2SowSXOeYBdYrYhWDzpjW9pzhIYluSMyM7D3kMY1kJkGF1bjZGJ4I/h tdokIo6HVy34Lz1t+mbS7ssgSqoAXcMQP0Ml4BDnzOnr18WXIYx2MV0BbP+CKMsVRqDh 4CZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AS2tkwcL9NQpVDZqTX2Ed2znYI0FmYd9Tgq+hmU6nlo=; b=Cggm5cddErDRRC+OiJpoNQH6eaosdv/4Q4sDBBAeuUnNwnr4cTdVGqb4doP+kJP2nL LXIUV/A+YGO4KCltEJWYvRbLEjYyy8yBSiL/0CK7tfPrvS0VC+FmsCMaa17nON99rNWC wQAhZMQX1cxXIbuPOpEK2iy9iTd/VoaussEZPaEbEYG/UA4HTOwxefIa1mAB2PkoXdU0 d9/kgybArqbWOpWWZeDU9W4V5ERldVBV27fwfgPnKomA4qHLhJLMT7WOgT08HGQvzdIv gMm8J17+YiIV/cKW/wwlpk+ESUFWKpvgjRmh3mGGcln0VTNIrkCTGO2Ja7sDY8YyDVtV K3tw== X-Gm-Message-State: APjAAAXcZjcIO2S10c+B1RYUiGuSPnJgKrmqD6q1eN5rYyYwaFlP0sc4 3gTQWtEImTph5uYXUgSWOzpUXQE/Wu9wKea2bpo= X-Google-Smtp-Source: APXvYqxaQpJNIrZXObgXsk92m0tlYTGtf/xu/abeWWB9S4pOjkidImoBhZS4EKi1PhEJCxf9zTnOfydlxwCj17MDfvc= X-Received: by 2002:a2e:80d6:: with SMTP id r22mr1666659ljg.83.1561161071810; Fri, 21 Jun 2019 16:51:11 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> In-Reply-To: From: Marten Seemann Date: Sat, 22 Jun 2019 07:50:59 +0800 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Christian Huitema , David Schinazi , Eric Kinnear , IETF QUIC WG , Ian Swett , Martin Thomson , Nick Banks , Roberto Peon Content-Type: multipart/alternative; boundary="0000000000001f5de2058bde2341" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 23:51:18 -0000 --0000000000001f5de2058bde2341 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There=E2=80=99s also a 4th option: 4) Keep the 4 bit compressed encoding and increase the maximum length to 20 bytes. This could be done by eliminating code points for 15 and 17 byte connection IDs (or any other 2 code points that seem less useful). I=E2=80=99d prefer that option because of the ossification risks described = earlier. On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Makes sense 2 me 2 > > > On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) > wrote: > > Me too. 2. > > -- Christian Huitema > > On Jun 21, 2019, at 1:24 PM, Eric Kinnear < > ekinnear=3D40apple.com@dmarc.ietf.org> wrote: > > (2) would be fine for me! > > Thanks, > Eric > > > On Jun 21, 2019, at 1:23 PM, Nick Banks < > nibanks=3D40microsoft.com@dmarc.ietf.org> wrote: > > Works for me as well. > > - Nick > > *From:* QUIC *On Behalf Of *Roberto Peon > *Sent:* Friday, June 21, 2019 1:21 PM > *To:* David Schinazi ; Ian Swett < > ianswett=3D40google.com@dmarc..ietf.org > > > *Cc:* IETF QUIC WG ; Martin Thomson > *Subject:* Re: Consensus Call: More Connection ID Space #2736 > > Works for me. > -=3DR > > *From: *QUIC on behalf of David Schinazi < > dschinazi.ietf@gmail.com> > *Date: *Friday, June 21, 2019 at 1:02 PM > *To: *Ian Swett > *Cc: *IETF QUIC WG , Martin Thomson > *Subject: *Re: Consensus Call: More Connection ID Space #2736 > > +1 to what Ian said. (2) seems like a good path forward > > On Fri, Jun 21, 2019 at 1:00 PM Ian Swett 40google.com@dmarc.ietf.org> wrote: > > I think the 3 options I see as well reasoned are: > 1) Keep the status quo because we think we can put what we really need > into 18 bytes if we try. > 2) Change to a 1 byte length per CID and a max of 20, which gives us a fe= w > extra bytes for cleartext server id and/or key rotation/etc. > 3) Change to a 1 byte length per CID and a max of 36, because we want be > able to put 2 encrypted routing IDs in a single CID. > > 2 is my preferred option, though I can live with either of 1 or 3. > > Deciding sooner would be strictly better than later, since this is > blocking us(Chrome/Google) actually supporting varlen CIDs. > > On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote: > > That seems a little high. I think that Ian's principle here is what > should guide us: what is the minimum you can handle? What I've heard is > that 18 might have been workable, but it was REALLY close to the edge to > the point that you weren't confident it was enough, even in the near > term.. But that suggests that 20 is workable. > > On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > > so do I hear consensus emerging around 32B in v1, or should I leave the > > 18B limit in v1 for now and punt out that discussion? > > > > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel > wrote: > > > > > > > > > > On 18. Jun 2019, at 05:33, Marten Seemann > wrote: > > > > > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we > decide to increase the connection ID length to a larger value (which I'm > still not convinced that this is really necessary). > > > > > > This would be easy if we change the encoding of the connection ID > length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While > we can not encode one or two byte connection IDs in long header packets, = we > can still use them in short header packets. > > > > > > This split between long and short header also allows to use much > longer connection IDs after the handshake. > > > I don=E2=80=99t see much use in it, but it may take off some fear th= at > 24/32/36/48/60 byte connection IDs might not be long enough in the future= . > > > > > > > > > > > There are two main reasons to keep the compressed encoding: > > > > =E2=80=A2 In the compressed encoding, we can reasonably expect tha= t all / > most values will be used in practice, so we won't expose any bits on the > wire that identify a packet as "QUIC traffic" by having a predictable val= ue. > > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an impleme= ntation > still needs to be able to deal with connection ID lengths of 255 bytes, > just to be able to send Version Negotiation packets. To me, it seems absu= rd > to write a QUIC implementation that is able to handle packets with a > combined connection ID overhead of 510 bytes. Since VNPs are supposed to = be > sent in response to any Long Header packet, you'd have to put some carefu= l > thought into the design of your data types to avoid this becoming a DoS > vector. > > > > > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < > huitema@huitema.net> wrote: > > > > I too agree that using one byte in the invariant is preferable to > the current "compressed 4 bits" solution. > > > > > > > > Regarding the "CID length limit", I thing there are two issues: > transmission overhead, and costs to the community. > > > > > > > > I am not too concerned with the transmission overhead, as we have > there the right mix of costs and incentives. Servers who chose to use > longer CID will get more transmission overhead, and thus transmission les= s > efficiently than their competitors. They may chose to use longer CID as a > trade-off between transmission efficiency and ease of management. > Competition will sort that out. I note that YouTube is apparently doing > fine with smallish CID, so I trust that there will be competition. > > > > > > > > I am much more concerned with the shared costs, which are a > variation of the "tragedy of the commons". Dmitry explained those costs > well in a previous message. The simpler implementation is to make the > "cid_t a fixed-size object that can fit the largest CID and eat the > overhead for all CIDs." But each connection object carries a large number > of instances of the CID type. Having a very large max CID would imply a > large overhead. The alternative is to "Make cid_t a variable-size object"= , > but too affects performance. > > > > > > > > Hence the push-back. I would personally prefer a max size of 16, > and I think that 32 is the highest practical limit. > > > > > > > > -- Christian Huitema > > > > > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > > >> What I think people are saying so far: > > > >> > > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or > 48} > > > >> > > > >> 2) Representation of CID length as a byte is still OK, thus a QUI= C > v2 could use longer CIDs as needed by changing the spec while keeping the > invariants=E2=80=A6 invariant. > > > >> > > > >> > > > >> That seems reasonable to me / I=E2=80=99d still support that. > > > >> > > > >> -=3DR > > > >> > > > >> > > > >> From: QUIC > on > behalf of "Lubashev, Igor" > > > >> Date: Monday, June 17, 2019 at 8:55 AM > > > >> To: Ian Swett , Mikkel > Fahn=C3=B8e J=C3=B8rgensen > > > >> Cc: Dmitri Tikhonov , Christian > Huitema , "Philipp S. Tiesel" , > Mike Bishop , Martin Thomson , > Marten Seemann , Lars Eggert , > QUIC WG , Martin Duke martin..h.duke@gmail.com>>, Kazuho Oku > > > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > > >> > > > >> > > > >> > > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 i= s likely > the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a = factor of 8, so 32 > or 24?). > > > >> > > > >> > > > >> > > > >> We are firmly committed for using CID for in-cluster load > balancing / anycast pop routing. This discussion is taking us, however, t= o > a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled r= outing in an > overlay network=E2=80=9D. This is a very interesting topic, but I would h= esitate to > attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > > > >> > > > >> > > > >> > > > >> =E2=80=A2 Igor > > > >> > > > >> > > > >> From: Ian Swett > > > >> > > > >> My intuition says making the change to the invariants is the righ= t > thing to do, but I don't feel that strongly.. > > > >> > > > >> > > > >> > > > >> However, I'd like the max size to be smaller than 48(but larger > than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho > suggested 32, which is better, but I don't believe the server needs to us= e > a separate block cipher when giving out connection IDs, because I believe > it's impractical for the load balancer and server to be that decoupled. T= he > server has to give out a CID that the load balancer will use to route bac= k > to the server, so they have to share enough an encryption key/algorithm. = I > can imagine nesting load balancers, but that's well in the range of QUIC = v2 > from my perspective. > > > >> > > > >> > > > >> > > > >> Whatever we do, I'd really prefer to resolve this sooner rather > than later and be truly done with it. > > > >> > > > >> > > > >> > > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen= < > mikkelfj@gmail.com> wrote: > > > >> > > > >> Since it is more likely that you pay for egress traffic than > ingress traffic, the motivation to keep CID=E2=80=99s small is limited. > > > >> > > > >> > > > >> > > > >> I do think the invariants should allow for long CID=E2=80=99s as = proposed, > and that the long header overhead is not important... > > > >> > > > >> > > > >> > > > >> But for QUIC v1, if we allow for a long CID, a rush to market wil= l > set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > > > >> > > > >> > > > >> > > > >> I good reference on an algorithm like suggested by Christian woul= d > go a long way. > > > >> > > > >> > > > >> > > > >> If CID length 18 turns out to be not enough, we can add a QUIC v2= . > It=E2=80=99s not like we are not looking for excuses to upgrade QUIC vers= ions soon. > > > >> > > > >> > > > >> > > > >> If CID length negotiation is needed, this could be done via QUIC > versions. For example two functionally equivalent versions, but one with > longer CID=E2=80=99s. This would also allow routers to deal with changes = in CID > lengths. A negotiated TP would not (easily) allow for that and aside I do > not think CID length in TP is the way to go. > > > >> > > > >> > > > >> > > > >> Mikkel > > > >> > > > >> > > > >> > > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) > wrote: > > > >> > > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hui= tema : > > > >> > > > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > >> > > > > >> > > _If_ we are to allow loose coupling between a load balancer > and a > > > >> > > server, each of the two should be given the freedom to choose > it's own > > > >> > > CID encryption scheme. Because all the standardized block > ciphers are > > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the > maximum CID > > > >> > > length of QUIC needs to be double amount of that, plus one or > two > > > >> > > bytes for each of the two for identifying the CID encryption > keys. For > > > >> > > key identification and other supplemental use, we currently > allocate 2 > > > >> > > bytes (18-16=3D2). > > > >> > > > > >> > That reasoning is based on the assumption that both the load > balancer > > > >> > and the server must use a block cipher with 128 bit block lengt= h > in > > > >> > order to encrypt the CID. If they were constrained to stay > within a > > > >> > short global limit, they could use different sets of algorithms= . > > > > >> > > > > >> > Assume for example that we split the CID between 32 bits > encoding the > > > >> > number of the server in the server farm, and 64 bit encoding th= e > > > > >> > connection number for the server. The server can pick a random > value for > > > >> > the connection number, and use a hash table. The load balancer > could use > > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit o= f > the CID > > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > > > >> > > > > >> > Or assume that the server wants to use short CID. We now split > the CID > > > >> > between 32 bit for the server number in the farm, and 32 bit fo= r > the > > > >> > connection number in the server. The server builds that > connection > > > >> > number by using a 32 bit variant of FFX. The load balancer also > uses a > > > >> > 32 bit variant, using the lower 32 bit of the CID as initial > vector for > > > >> > this FFX encryption. > > > >> > > > > >> > These are just two examples. And yes you may want to add 2 byte= s > for key > > > >> > identification, etc. In both encryption algorithms, you can fee= d > these > > > >> > two bytes as additional IV for the FFX algorithm. And in both > cases, we > > > >> > are well below the 18 byte limit. > > > >> > > > > >> > Yes, that requires some creative engineering. But it is not > rocker > > > >> > science. And it seems better than carrying tons of overhead in > the > > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. > > > >> > > > >> I agree that it would not be the end of the world for the load > > > >> balancers if we decide to stick on the 18-byte limit. However, as > you > > > >> state, it requires some creativeness. > > > >> > > > >> To me it seems that the question is if we have a strong reason to > > > >> require some people to be creative, for all the versions of QUIC = in > > > > >> the future. I personally think that there isn't a strong reason, > > > >> because people can use shorter CIDs regardless of the decision we > > > >> make. IIUC, the overhead that everyone needs to accept is: > > > >> > > > >> * one byte increase in the long header packets > > > >> * the minimum size of short header packets becoming slightly > greater > > > >> (otherwise, the peer might not be able to send a stateless reset) > > > >> > > > >> I'd say that the first bullet point is negligible. The second poi= nt > > > > >> could also be, because I'd assume that the only frequently-sent > > > >> packets that require additional padding is the ACK-only packets, > but > > > >> there's no reason to pad ACK-only packets in hope that you'd see = a > > > > >> stateless reset. > > > >> > > > >> Therefore, my (not-so-strong) preference has been to provide extr= a > > > > >> room, so that some people with necessity can use longer CIDs. > > > >> > > > >> > > > > >> > -- Christian Huitema > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Kazuho Oku > > > >> > > > > > > AVE! > > > Philipp S. Tiesel > > > > > > -- > > > Philipp S. Tiesel > > > https://philipp.tiesel.net/ > > > > > > > --0000000000001f5de2058bde2341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There=E2=80=99s also a 4th option:
4) Keep the 4 bit compressed encoding and increase the maximum = length to 20 bytes.

This= could be done by eliminating code points for 15 and 17 byte connection IDs= (or any other 2 code points that seem less useful).
I=E2=80=99d prefer that option because of the ossification risks described= earlier.

On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rge= nsen <mikkelfj@gmail.com> w= rote:
Makes sense 2 me 2


On 21 = June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) wrote:

Me too. 2.

-- Christi= an Huitema=C2=A0

On Jun 21, 2019, at 1:24 PM, Eric Kinnear <ekinnear=3D40apple.com@dmarc.= ietf.org> wrote:

(2) would be fine for me!

Thanks,
Eric


On Jun 21, 2019, at 1:23 PM, Nick Banks <nibanks=3D40microsoft.= com@dmarc.ietf.org> wrote:

Works for me as well.
=C2=A0
- Nick
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.org>=C2=A0On Behalf Of=C2=A0= Roberto Peon
Sent:=C2= =A0Friday, June 21, 2019 1:21 PM
To:=C2= =A0David Schinazi <dschinazi.ietf@gmail.com>; Ian Swett <ianswett= =3D40google.com@dmarc..ietf.org>
Cc:=C2= =A0IETF QUIC WG <quic@ietf.org>; Martin Thomson <mt@lowen= tropy.net>
Subject:= =C2=A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
Works for me.
-=3DR
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.o= rg> on behalf of David Schinazi <dschinazi.ietf@gmail.com> Date:=C2=A0<= /span>Friday, June 21, 2019 at 1:02 PM
To:=C2=A0Ian Swett <ian= swett=3D40google.com@dmarc.ietf.org>
Cc:=C2=A0IETF QUIC WG <quic@ietf.org>, Ma= rtin Thomson <mt@lowentropy.net>
Subject:=C2= =A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
+1 to what Ian said. (2) seems like a good path forward
=C2=A0
On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ie= tf.org> wrote:
I think the 3 options I see as well reasoned are:=C2=A0
1) Keep the status quo because we think we can put what we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID.
=C2=A0
2 is my preferred option, though I can live with either of 1 or 3.
=C2=A0
Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs.
=C2=A0
On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:

That seems a little high.=C2=A0 I think that Ian's principle here is what should guide us: what is the minimum you can handle?=C2=A0 What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term..=C2=A0 But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the=C2=A0=
> 18B limit in v1 for now and punt out that discussion?
>=C2=A0
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote:
> >=C2=A0=
> >=C2=A0=
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrot= e:
> >=C2=A0 >=C2=A0
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary).
> >=C2=A0=
> >=C2=A0 This would be easy if we change the encoding of the connection ID length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
> >=C2=A0=
> >=C2=A0 This split between long and short header also allows to use much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future.
> >=C2=A0=
> >=C2=A0 >=C2=A0
> >=C2=A0 > There are two main reasons to keep the compressed encoding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector.
> >=C2=A0 >=C2=A0
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net> wrot= e:
> >=C2=A0 > I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >=C2=A0
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >=C2=A0
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48}
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still support that.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> -=3DR
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Phili= pp S. Tiesel" <philipp@tiesel.net= >, Mike Bishop <mbishop@evequefou.be<= /a>>, Martin Thomson <mt@lowentropy.net<= /a>>, Marten Seemann <martenseeman= n@gmail.com>, Lars Eggert <lars@eggert= .org>, QUIC WG <quic@ietf.org>, M= artin Duke <martin.h.duke@gmail.com<mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.= com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Space #2736
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80= =9D (it should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> We are firmly committed for using CID for in-cluster load balancing / anycast pop routing. This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D. Thi= s is a very interesting topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly..
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmai= l.com> wrote:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I do think the invariants should allow for long CID=E2=80=99s as proposed, and that the long header overhead is not important...
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I good reference on an algorithm like suggested by Christian would go a long way.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versions soon.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Mikkel
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 2019=E5=B9=B46=E6= =9C=8817=E6=97=A5<= /span>(=E6=9C=88) = 11:09 Christian Huitema <huitema@huitema.= net>:=C2= =A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > > _If_ we are to allow loose coupling between a load balancer and a=C2=A0
> >=C2=A0 >> > > server, each of the two should be given the freedom to choose it's own=C2=A0
> >=C2=A0 >> > > CID encryption scheme. Because all the standardized block ciphers are=C2=A0
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID=C2=A0
> >=C2=A0 >> > > length of QUIC needs to be double amount of that, plus one or two=C2=A0
> >=C2=A0 >> > > bytes for each of the two for identifying the CID encryption keys. For=C2=A0
> >=C2=A0 >> > > key identification and other supplemental use, we currently allocate 2=C2=A0
> >=C2=A0 >> > > bytes (18-16=3D2).=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > That reasoning is based on the assumption that both the load balancer=C2=A0
> >=C2=A0 >> > and the server must use a block cipher with 128 bit block length in=C2=A0
> >=C2=A0 >> > order to encrypt the CID. If they were constrained to stay within a=C2=A0
> >=C2=A0 >> > short global limit, they could use different sets of algorithms.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Assume for example that we split the CID between 32 bits encoding the=C2=A0
> >=C2=A0 >> > number of the server in the server farm, and 64 bit encoding the=C2=A0
> >=C2=A0 >> > connection number for the server. The server can pick a random value for=C2=A0
> >=C2=A0 >> > the connection number, and use a hash table. The load balancer could use=C2=A0
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID=C2=A0
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Or assume that the server wants to use short CID. We now split the CID=C2=A0
> >=C2=A0 >> > between 32 bit for the server number in the farm, and 32 bit for the=C2=A0
> >=C2=A0 >> > connection number in the server. The server builds that connection=C2=A0
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The load balancer also uses a=C2=A0
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for=C2=A0
> >=C2=A0 >> > this FFX encryption.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > These are just two examples. And yes you may want to add 2 bytes for key=C2=A0
> >=C2=A0 >> > identification, etc. In both encryption algorithms, you can feed these=C2=A0
> >=C2=A0 >> > two bytes as additional IV for the FFX algorithm. And in both cases, we=C2=A0
> >=C2=A0 >> > are well below the 18 byte limit.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Yes, that requires some creative engineering. But it is not rocker=C2=A0
> >=C2=A0 >> > science. And it seems better than carrying tons of overhead in the=C2=A0
> >=C2=A0 >> > header, and becoming less efficient than HTTP2/TLS/TCP.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I agree that it would not be the end of the world for the load=C2=A0
> >=C2=A0 >> balancers if we decide to stick on the 18-byte limit. However, as you=C2=A0
> >=C2=A0 >> state, it requires some creativeness.= =C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> To me it seems that the question is if we have a strong reason to=C2=A0
> >=C2=A0 >> require some people to be creative, for all the versions of QUIC in=C2=A0
> >=C2=A0 >> the future. I personally think that there isn't a strong reason,=C2=A0
> >=C2=A0 >> because people can use shorter CIDs regardless of the decision we=C2=A0
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to accept is:=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> * one byte increase in the long header packets=C2=A0
> >=C2=A0 >> * the minimum size of short header packets becoming slightly greater=C2=A0
> >=C2=A0 >> (otherwise, the peer might not be able to send a stateless reset)=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I'd say that the first bullet point is negligible. The second point=C2=A0
> >=C2=A0 >> could also be, because I'd assume that the only frequently-sent=C2=A0
> >=C2=A0 >> packets that require additional padding is the ACK-only packets, but=C2=A0
> >=C2=A0 >> there's no reason to pad ACK-only packets in hope that you'd see a=C2=A0
> >=C2=A0 >> stateless reset.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been to provide extra=C2=A0
> >=C2=A0 >> room, so that some people with necessity can use longer CIDs.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > -- Christian Huitema=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
> >=C2=A0 >> --=C2=A0
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>=C2=A0
> >=C2=A0=
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >=C2=A0=
> >=C2=A0 --=C2=A0
> >=C2=A0 Philipp S. Tiesel=C2=A0
> >=C2=A0= https://philipp.tiesel.net/
> >


--0000000000001f5de2058bde2341-- From nobody Fri Jun 21 16:53:17 2019 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 E85BD120230 for ; Fri, 21 Jun 2019 16:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.252 X-Spam-Level: * X-Spam-Status: No, score=1.252 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, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eugzbeakprt5 for ; Fri, 21 Jun 2019 16:53:11 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE52B12004C for ; Fri, 21 Jun 2019 16:53:10 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id i21so7418587ljj.3 for ; Fri, 21 Jun 2019 16:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0d7KhlUiIMT+vJ2W4sYEre6J7bN912MZGfGQQU6Mda8=; b=uZi2h28isqTfMccksD7931ovuY9kj4w7Fs/KP0YGESUrv3HMlUG9tEsAqxayQ6da3F OZcYDyNwOi75IpDXfO2L+oASS7i7emhTTE9LCTyJo5Zw/HtBd4jvp0/Dbo0BjfUpm81Q 94hBAghXjOMtd74numDqYu06wQtbfCdlATxN2+jfG/+5zFPMRtnr6wLFLGczU92YcpKQ D7ogFEg1+IILmVAC/6rOUSbZreU+xyzFxhZx1VKe86iwvXZo5NBBk0xb6yD0TSJpY3cm mqg8PgJiBAmnHzSNPkBOK5wO3OIOJUA+aWEINjIldp54xHXy7cUSmEqyayoaTgpXCQiy I1NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0d7KhlUiIMT+vJ2W4sYEre6J7bN912MZGfGQQU6Mda8=; b=Iy9WhpWseRBvkG8QjHVX+LrBoduKp9UycJ9VVqgUt7tg83qcw6EcfiBHKmKI2TIXPr A4zr0Ue8/f/JHa+y7XBoh/CJg5JVIPdtIktvLWP+upXzNT0Dl8XaffCCEnuFKTpb2Jqa fRBkW/g06CZV5z31qgnjDUalNI911cZ2ufJJgdBWU4bRiHsmMOKqDxoScSnrjCVb14Fg iD7zpWoCHuiOjx7x/Vw5MMJUHLPRJa6hbWtdd6hYVQjFNN2mEJ69Jm+/XD47Hajb0rHt E4HLcwsp2EG8p6EucdpDuNxeDhQ4hAA/dHK5unC+PXH+Yegt1WY+bIv9nB2coXOC+Ng5 jAng== X-Gm-Message-State: APjAAAVooUL8lycnmvGADLXyI6JedSEkysTfQdii9Gd/Vt/uof5TTvsa Ys9k3FwMOGUIVamvmeCBWoPWGgb3YQgtPHj2Gu8O8g== X-Google-Smtp-Source: APXvYqx99sIV1SFYIPgpMue1f5/cE8UV2kSckCBFL4KW58oqyMxYdQ5GAxYGH1MlUnMbPhhZ3xtXm6hkNnEmDkDelq4= X-Received: by 2002:a2e:5341:: with SMTP id t1mr64504238ljd.170.1561161189129; Fri, 21 Jun 2019 16:53:09 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> In-Reply-To: From: David Schinazi Date: Fri, 21 Jun 2019 16:52:58 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Marten Seemann Cc: Christian Huitema , Eric Kinnear , IETF QUIC WG , Ian Swett , Martin Thomson , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Nick Banks , Roberto Peon Content-Type: multipart/alternative; boundary="0000000000001d80fc058bde2aab" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 23:53:16 -0000 --0000000000001d80fc058bde2aab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m strongly opposed to option 4. It guarantees ossification by not allowing other lengths from the get go so it=E2=80=99s strictly less future= -proof than option 2. On Fri, Jun 21, 2019 at 16:51 Marten Seemann wrote: > There=E2=80=99s also a 4th option: > 4) Keep the 4 bit compressed encoding and increase the maximum length to > 20 bytes. > > This could be done by eliminating code points for 15 and 17 byte > connection IDs (or any other 2 code points that seem less useful). > I=E2=80=99d prefer that option because of the ossification risks describe= d earlier. > > On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > >> Makes sense 2 me 2 >> >> >> On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) >> wrote: >> >> Me too. 2. >> >> -- Christian Huitema >> >> On Jun 21, 2019, at 1:24 PM, Eric Kinnear < >> ekinnear=3D40apple.com@dmarc.ietf.org> wrote: >> >> (2) would be fine for me! >> >> Thanks, >> Eric >> >> >> On Jun 21, 2019, at 1:23 PM, Nick Banks < >> nibanks=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> Works for me as well. >> >> - Nick >> >> *From:* QUIC *On Behalf Of *Roberto Peon >> *Sent:* Friday, June 21, 2019 1:21 PM >> *To:* David Schinazi ; Ian Swett < >> ianswett=3D40google.com@dmarc..ietf.org >> > >> *Cc:* IETF QUIC WG ; Martin Thomson >> *Subject:* Re: Consensus Call: More Connection ID Space #2736 >> >> Works for me. >> -=3DR >> >> *From: *QUIC on behalf of David Schinazi < >> dschinazi.ietf@gmail.com> >> *Date: *Friday, June 21, 2019 at 1:02 PM >> *To: *Ian Swett >> *Cc: *IETF QUIC WG , Martin Thomson >> *Subject: *Re: Consensus Call: More Connection ID Space #2736 >> >> +1 to what Ian said. (2) seems like a good path forward >> >> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett > 40google.com@dmarc.ietf.org> wrote: >> >> I think the 3 options I see as well reasoned are: >> 1) Keep the status quo because we think we can put what we really need >> into 18 bytes if we try. >> 2) Change to a 1 byte length per CID and a max of 20, which gives us a >> few extra bytes for cleartext server id and/or key rotation/etc. >> 3) Change to a 1 byte length per CID and a max of 36, because we want be >> able to put 2 encrypted routing IDs in a single CID. >> >> 2 is my preferred option, though I can live with either of 1 or 3. >> >> Deciding sooner would be strictly better than later, since this is >> blocking us(Chrome/Google) actually supporting varlen CIDs. >> >> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote= : >> >> That seems a little high. I think that Ian's principle here is what >> should guide us: what is the minimum you can handle? What I've heard is >> that 18 might have been workable, but it was REALLY close to the edge to >> the point that you weren't confident it was enough, even in the near >> term.. But that suggests that 20 is workable. >> >> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >> > so do I hear consensus emerging around 32B in v1, or should I leave th= e >> >> > 18B limit in v1 for now and punt out that discussion? >> > >> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel >> wrote: >> > > >> > > >> > > > On 18. Jun 2019, at 05:33, Marten Seemann >> wrote: >> > > > >> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we >> decide to increase the connection ID length to a larger value (which I'm >> still not convinced that this is really necessary). >> > > >> > > This would be easy if we change the encoding of the connection ID >> length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. Whil= e >> we can not encode one or two byte connection IDs in long header packets,= we >> can still use them in short header packets. >> > > >> > > This split between long and short header also allows to use much >> longer connection IDs after the handshake. >> > > I don=E2=80=99t see much use in it, but it may take off some fear t= hat >> 24/32/36/48/60 byte connection IDs might not be long enough in the futur= e. >> > > >> > > > >> > > > There are two main reasons to keep the compressed encoding: >> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect th= at all / >> most values will be used in practice, so we won't expose any bits on the >> wire that identify a packet as "QUIC traffic" by having a predictable va= lue. >> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an implem= entation >> still needs to be able to deal with connection ID lengths of 255 bytes, >> just to be able to send Version Negotiation packets. To me, it seems abs= urd >> to write a QUIC implementation that is able to handle packets with a >> combined connection ID overhead of 510 bytes. Since VNPs are supposed to= be >> sent in response to any Long Header packet, you'd have to put some caref= ul >> thought into the design of your data types to avoid this becoming a DoS >> vector. >> > > > >> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < >> huitema@huitema.net> wrote: >> > > > I too agree that using one byte in the invariant is preferable to >> the current "compressed 4 bits" solution. >> > > > >> > > > Regarding the "CID length limit", I thing there are two issues: >> transmission overhead, and costs to the community. >> > > > >> > > > I am not too concerned with the transmission overhead, as we have >> there the right mix of costs and incentives. Servers who chose to use >> longer CID will get more transmission overhead, and thus transmission le= ss >> efficiently than their competitors. They may chose to use longer CID as = a >> trade-off between transmission efficiency and ease of management. >> Competition will sort that out. I note that YouTube is apparently doing >> fine with smallish CID, so I trust that there will be competition. >> > > > >> > > > I am much more concerned with the shared costs, which are a >> variation of the "tragedy of the commons". Dmitry explained those costs >> well in a previous message. The simpler implementation is to make the >> "cid_t a fixed-size object that can fit the largest CID and eat the >> overhead for all CIDs." But each connection object carries a large numbe= r >> of instances of the CID type. Having a very large max CID would imply a >> large overhead. The alternative is to "Make cid_t a variable-size object= ", >> but too affects performance. >> > > > >> > > > Hence the push-back. I would personally prefer a max size of 16, >> and I think that 32 is the highest practical limit. >> > > > >> > > > -- Christian Huitema >> > > > >> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >> > > >> What I think people are saying so far: >> > > >> >> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, o= r >> 48} >> > > >> >> > > >> 2) Representation of CID length as a byte is still OK, thus a >> QUIC v2 could use longer CIDs as needed by changing the spec while keepi= ng >> the invariants=E2=80=A6 invariant. >> > > >> >> > > >> >> > > >> That seems reasonable to me / I=E2=80=99d still support that. >> > > >> >> > > >> -=3DR >> > > >> >> > > >> >> > > >> From: QUIC > on >> behalf of "Lubashev, Igor" >> > > >> Date: Monday, June 17, 2019 at 8:55 AM >> > > >> To: Ian Swett , Mikkel >> Fahn=C3=B8e J=C3=B8rgensen >> > > >> Cc: Dmitri Tikhonov , Christian >> Huitema , "Philipp S. Tiesel" , >> Mike Bishop , Martin Thomson , >> Marten Seemann , Lars Eggert , >> QUIC WG , Martin Duke > martin..h.duke@gmail.com>>, Kazuho Oku > > >> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >> > > >> >> > > >> >> > > >> >> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 = is likely >> the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a= factor of 8, so 32 >> or 24?). >> > > >> >> > > >> >> > > >> >> > > >> We are firmly committed for using CID for in-cluster load >> balancing / anycast pop routing. This discussion is taking us, however, = to >> a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled = routing in an >> overlay network=E2=80=9D. This is a very interesting topic, but I would = hesitate to >> attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. >> > > >> >> > > >> >> > > >> >> > > >> =E2=80=A2 Igor >> > > >> >> > > >> >> > > >> From: Ian Swett >> > > >> >> > > >> My intuition says making the change to the invariants is the >> right thing to do, but I don't feel that strongly.. >> > > >> >> > > >> >> > > >> >> > > >> However, I'd like the max size to be smaller than 48(but larger >> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho >> suggested 32, which is better, but I don't believe the server needs to u= se >> a separate block cipher when giving out connection IDs, because I believ= e >> it's impractical for the load balancer and server to be that decoupled. = The >> server has to give out a CID that the load balancer will use to route ba= ck >> to the server, so they have to share enough an encryption key/algorithm.= I >> can imagine nesting load balancers, but that's well in the range of QUIC= v2 >> from my perspective. >> > > >> >> > > >> >> > > >> >> > > >> Whatever we do, I'd really prefer to resolve this sooner rather >> than later and be truly done with it. >> > > >> >> > > >> >> > > >> >> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgense= n < >> mikkelfj@gmail.com> wrote: >> > > >> >> > > >> Since it is more likely that you pay for egress traffic than >> ingress traffic, the motivation to keep CID=E2=80=99s small is limited. >> > > >> >> > > >> >> > > >> >> > > >> I do think the invariants should allow for long CID=E2=80=99s as >> proposed, and that the long header overhead is not important... >> > > >> >> > > >> >> > > >> >> > > >> But for QUIC v1, if we allow for a long CID, a rush to market >> will set precedence and long CID=E2=80=99s will ossify in all kinds of s= tacks. >> > > >> >> > > >> >> > > >> >> > > >> I good reference on an algorithm like suggested by Christian >> would go a long way. >> > > >> >> > > >> >> > > >> >> > > >> If CID length 18 turns out to be not enough, we can add a QUIC >> v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC= versions >> soon. >> > > >> >> > > >> >> > > >> >> > > >> If CID length negotiation is needed, this could be done via QUIC >> versions. For example two functionally equivalent versions, but one with >> longer CID=E2=80=99s. This would also allow routers to deal with changes= in CID >> lengths. A negotiated TP would not (easily) allow for that and aside I d= o >> not think CID length in TP is the way to go. >> > > >> >> > > >> >> > > >> >> > > >> Mikkel >> > > >> >> > > >> >> > > >> >> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) >> wrote: >> > > >> >> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hu= itema : >> > > >> > >> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >> > > >> > >> > > >> > > _If_ we are to allow loose coupling between a load balancer >> and a >> > > >> > > server, each of the two should be given the freedom to choos= e >> it's own >> > > >> > > CID encryption scheme. Because all the standardized block >> ciphers are >> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the >> maximum CID >> > > >> > > length of QUIC needs to be double amount of that, plus one o= r >> two >> > > >> > > bytes for each of the two for identifying the CID encryption >> keys. For >> > > >> > > key identification and other supplemental use, we currently >> allocate 2 >> > > >> > > bytes (18-16=3D2). >> > > >> > >> > > >> > That reasoning is based on the assumption that both the load >> balancer >> > > >> > and the server must use a block cipher with 128 bit block >> length in >> > > >> > order to encrypt the CID. If they were constrained to stay >> within a >> > > >> > short global limit, they could use different sets of algorithm= s. >> >> > > >> > >> > > >> > Assume for example that we split the CID between 32 bits >> encoding the >> > > >> > number of the server in the server farm, and 64 bit encoding t= he >> >> > > >> > connection number for the server. The server can pick a random >> value for >> > > >> > the connection number, and use a hash table. The load balancer >> could use >> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit >> of the CID >> > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong >> encryption. >> > > >> > >> > > >> > Or assume that the server wants to use short CID. We now split >> the CID >> > > >> > between 32 bit for the server number in the farm, and 32 bit >> for the >> > > >> > connection number in the server. The server builds that >> connection >> > > >> > number by using a 32 bit variant of FFX. The load balancer als= o >> uses a >> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial >> vector for >> > > >> > this FFX encryption. >> > > >> > >> > > >> > These are just two examples. And yes you may want to add 2 >> bytes for key >> > > >> > identification, etc. In both encryption algorithms, you can >> feed these >> > > >> > two bytes as additional IV for the FFX algorithm. And in both >> cases, we >> > > >> > are well below the 18 byte limit. >> > > >> > >> > > >> > Yes, that requires some creative engineering. But it is not >> rocker >> > > >> > science. And it seems better than carrying tons of overhead in >> the >> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. >> > > >> >> > > >> I agree that it would not be the end of the world for the load >> > > >> balancers if we decide to stick on the 18-byte limit. However, a= s >> you >> > > >> state, it requires some creativeness. >> > > >> >> > > >> To me it seems that the question is if we have a strong reason t= o >> >> > > >> require some people to be creative, for all the versions of QUIC >> in >> > > >> the future. I personally think that there isn't a strong reason, >> > > >> because people can use shorter CIDs regardless of the decision w= e >> >> > > >> make. IIUC, the overhead that everyone needs to accept is: >> > > >> >> > > >> * one byte increase in the long header packets >> > > >> * the minimum size of short header packets becoming slightly >> greater >> > > >> (otherwise, the peer might not be able to send a stateless reset= ) >> >> > > >> >> > > >> I'd say that the first bullet point is negligible. The second >> point >> > > >> could also be, because I'd assume that the only frequently-sent >> > > >> packets that require additional padding is the ACK-only packets, >> but >> > > >> there's no reason to pad ACK-only packets in hope that you'd see= a >> >> > > >> stateless reset. >> > > >> >> > > >> Therefore, my (not-so-strong) preference has been to provide ext= ra >> >> > > >> room, so that some people with necessity can use longer CIDs. >> > > >> >> > > >> > >> > > >> > -- Christian Huitema >> > > >> > >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> Kazuho Oku >> > > >> >> > > >> > > AVE! >> > > Philipp S. Tiesel >> > > >> > > -- >> > > Philipp S. Tiesel >> > > https://philipp.tiesel.net/ >> >> > > >> >> >> --0000000000001d80fc058bde2aab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99m strongly opposed to option 4. It guarant= ees ossification by not allowing other lengths from the get go so it=E2=80= =99s strictly less future-proof than option 2.

On Fri, Jun 21, 20= 19 at 16:51 Marten Seemann <m= artenseemann@gmail.com> wrote:
There=E2=80=99s also a 4th option:
4) Keep the 4 bit compressed encoding and increase the maxim= um length to 20 bytes.

T= his could be done by eliminating code points for 15 and 17 byte connection = IDs (or any other 2 code points that seem less useful).
I=E2=80=99d prefer that option because of the ossification risks descri= bed earlier.

On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rg= ensen <mikkelfj@= gmail.com> wrote:
Makes sense 2 me 2


On 21 June 2019 at 23.42.48, Christian Huitema = (huitema@huitema.n= et) wrote:

Me too. 2.

-- Christian Huitema=C2=A0

On Jun 21, 2019, at 1:24 PM, Eric Kinnear <ekinnear=3D40apple.com@dmarc.= ietf.org> wrote:

(2) would be fine for me!

Thanks,
Eric


On Jun 21, 2019, at 1:23 PM, Nick Banks <nibanks=3D40microsoft.= com@dmarc.ietf.org> wrote:

Works for me as well.
=C2=A0
- Nick
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.org>=C2= =A0On Behalf Of=C2=A0Roberto Peon
Sent:=C2=A0Friday, June 21, 2019 1:21 PM
To:=C2=A0David Schinazi <dschinazi.ietf@gmail.com>; Ian S= wett <ianswett=3D40google.com@dmarc..ietf.org>
Cc:=C2=A0IETF QUIC WG <quic@ietf.org>; Martin Thomson <mt@lowen= tropy.net>
Subject:=C2=A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
Works for me.
-=3DR
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.org> on behalf of David Schinazi <dschinazi.ietf@gmail.com> Date:=C2=A0Friday, June 21, 2019 at 1:02 PM
To:=C2=A0Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
Cc:=C2=A0IETF QUIC WG <qui= c@ietf.org>, Martin Thomson <mt@lowe= ntropy.net>
Subject:=C2=A0Re: Consensus Call: More Connection ID Space #2736
=C2=A0
+1 to what Ian said. (2) seems like a good path forward
=C2=A0
On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ie= tf.org> wrote:
I think the 3 options I see as well reasoned are:=C2=A0
1) Keep the status quo because we think we can put what we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID.
=C2=A0
2 is my preferred option, though I can live with either of 1 or 3.
=C2=A0
Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs.
=C2=A0
On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:

That seems a little high.=C2=A0 I think that Ian's principle here is what should guide us: what is the minimum you can handle?=C2=A0 What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term..=C2=A0 But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the=C2=A0
> 18B limit in v1 for now and punt out that discussion?
>=C2=A0
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote:
> >=C2=A0
> >=C2=A0
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrot= e:
> >=C2=A0 >=C2=A0
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary).
> >=C2=A0
> >=C2=A0 This would be easy if we change the encoding of the connection ID length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
> >=C2=A0
> >=C2=A0 This split between long and short header also allows to use much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future.
> >=C2=A0
> >=C2=A0 >=C2=A0
> >=C2=A0 > There are two main reasons to keep the compressed encoding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector.
> >=C2=A0 >=C2=A0
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net> wrot= e:
> >=C2=A0 > I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >=C2=A0
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >=C2=A0
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48}
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still support that.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> -=3DR
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Phili= pp S. Tiesel" <philipp@tiesel.net= >, Mike Bishop <mbishop@evequefou.be<= /a>>, Martin Thomson <mt@lowentropy.net<= /a>>, Marten Seemann <martenseeman= n@gmail.com>, Lars Eggert <lars@eggert= .org>, QUIC WG <quic@ietf.org>, M= artin Duke <martin.h.duke@gmail.com<mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.= com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Space #2736
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80= =9D (it should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> We are firmly committed for using CID for in-cluster load balancing / anycast pop routing. This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D. Thi= s is a very interesting topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly..
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmai= l.com> wrote:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I do think the invariants should allow for long CID=E2=80=99s as proposed, and that the long header overhead is not important...
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I good reference on an algorithm like suggested by Christian would go a long way.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versions soon.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Mikkel
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 2019=E5=B9=B46=E6= =9C=8817=E6=97=A5<= /span>(=E6=9C=88) = 11:09 Christian Huitema <huitema@huitema.= net>:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > > _If_ we are to allow loose coupling between a load balancer and a=C2=A0
> >=C2=A0 >> > > server, each of the two should be given the freedom to choose it's own=C2=A0
> >=C2=A0 >> > > CID encryption scheme. Because all the standardized block ciphers are=C2=A0
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID=C2=A0
> >=C2=A0 >> > > length of QUIC needs to be double amount of that, plus one or two=C2=A0
> >=C2=A0 >> > > bytes for each of the two for identifying the CID encryption keys. For=C2=A0
> >=C2=A0 >> > > key identification and other supplemental use, we currently allocate 2=C2=A0
> >=C2=A0 >> > > bytes (18-16=3D2).=C2=A0 > >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > That reasoning is based on the assumption that both the load balancer=C2=A0
> >=C2=A0 >> > and the server must use a block cipher with 128 bit block length in=C2=A0
> >=C2=A0 >> > order to encrypt the CID. If they were constrained to stay within a=C2=A0
> >=C2=A0 >> > short global limit, they could use different sets of algorithms.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Assume for example that we split the CID between 32 bits encoding the=C2=A0
> >=C2=A0 >> > number of the server in the server farm, and 64 bit encoding the=C2=A0
> >=C2=A0 >> > connection number for the server. The server can pick a random value for=C2=A0
> >=C2=A0 >> > the connection number, and use a hash table. The load balancer could use=C2=A0
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID=C2=A0
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Or assume that the server wants to use short CID. We now split the CID=C2=A0
> >=C2=A0 >> > between 32 bit for the server number in the farm, and 32 bit for the=C2=A0
> >=C2=A0 >> > connection number in the server. The server builds that connection=C2=A0
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The load balancer also uses a=C2=A0
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for=C2=A0
> >=C2=A0 >> > this FFX encryption.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > These are just two examples. And yes you may want to add 2 bytes for key=C2=A0
> >=C2=A0 >> > identification, etc. In both encryption algorithms, you can feed these=C2=A0
> >=C2=A0 >> > two bytes as additional IV for the FFX algorithm. And in both cases, we=C2=A0
> >=C2=A0 >> > are well below the 18 byte limit.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Yes, that requires some creative engineering. But it is not rocker=C2=A0
> >=C2=A0 >> > science. And it seems better than carrying tons of overhead in the=C2=A0
> >=C2=A0 >> > header, and becoming less efficient than HTTP2/TLS/TCP.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I agree that it would not be the end of the world for the load=C2=A0
> >=C2=A0 >> balancers if we decide to stick on the 18-byte limit. However, as you=C2=A0
> >=C2=A0 >> state, it requires some creativeness.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> To me it seems that the question is if we have a strong reason to=C2=A0
> >=C2=A0 >> require some people to be creative, for all the versions of QUIC in=C2=A0
> >=C2=A0 >> the future. I personally think that there isn't a strong reason,=C2=A0
> >=C2=A0 >> because people can use shorter CIDs regardless of the decision we=C2=A0
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to accept is:=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> * one byte increase in the long header packets=C2=A0
> >=C2=A0 >> * the minimum size of short header packets becoming slightly greater=C2=A0
> >=C2=A0 >> (otherwise, the peer might not be able to send a stateless reset)=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I'd say that the first bullet point is negligible. The second point=C2=A0
> >=C2=A0 >> could also be, because I'd assume that the only frequently-sent=C2=A0
> >=C2=A0 >> packets that require additional padding is the ACK-only packets, but=C2=A0
> >=C2=A0 >> there's no reason to pad ACK-only packets in hope that you'd see a=C2=A0
> >=C2=A0 >> stateless reset.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been to provide extra=C2=A0
> >=C2=A0 >> room, so that some people with necessity can use longer CIDs.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > -- Christian Huitema=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
> >=C2=A0 >> --=C2=A0
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>=C2=A0
> >=C2=A0
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >=C2=A0
> >=C2=A0 --=C2=A0
> >=C2=A0 Philipp S. Tiesel=C2=A0
> >=C2=A0https://philipp.tiesel.net= /
> >


--0000000000001d80fc058bde2aab-- From nobody Fri Jun 21 17:20:06 2019 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 936D2120416 for ; Fri, 21 Jun 2019 17:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.252 X-Spam-Level: * X-Spam-Status: No, score=1.252 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, HTML_OBFUSCATE_05_10=0.26, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOYkptbbzQD2 for ; Fri, 21 Jun 2019 17:19:53 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 EF6A012035F for ; Fri, 21 Jun 2019 17:19:52 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id k18so7421091ljc.11 for ; Fri, 21 Jun 2019 17:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2CSS5GRfw08wC2nF5VN75rO4MdL0Henlw4mnneIU1o=; b=QCEvqt2U7mVCKSxQEQOfxrzKwCe/G5sZxx6I0lxRLyrb/uQKnlZS2L6r+IErZDEofX tJt56Q6Uj87MhkLinvRiYdlZS4LbA+Y1ZET4RJyJWWkT+QbMeqKhKIShwbaECpulgSdo 2Lbge4qvPxV+UiKEzPxIQMnGv0lUjTyPHVP8SB7WSxt8voQKD9Ihht1FfWLl4uzobNjw 5ALVuhO7YFWgWUPI4ubyMGaMVOkMplQCReBWTbhVJ8H+Axj0inVDLbEn7B43PeZO4uk1 C1VrwPeVJPi/rNmkKnRagW57SAkpiS/EUH4jdwKj1MmFUVvUawT76v0KoqqnnisJrOKX k8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s2CSS5GRfw08wC2nF5VN75rO4MdL0Henlw4mnneIU1o=; b=qSun8d9wu4JXUCblUNB5An+tkw3pfXOhG4MDdm0/OvkWeqdkeDkHd44p/lnZbFHGTC brIxjo9Y1Ukpy9eGEtU5spUJwe6ORa0KRbdje5RhAOrLJt0a46EN7G8BsRSAOo6Zv5r8 HNz3WmEXWLtl7GPZDR3er7VdJ2UiCQcJPqTou2H+5RzTIAL6tqoxwSo9GhHtksjdzjFl vPkUH/cbtJlBgm8O52T5Sai+Hviyb7FWEbeDwf2q33V+csVKVTR78E67Y0onzMkWXdEg EI8ug/CFC1kDC6QHdfv5mbdq40Wq4EYBd/ZMedscw+LxEDolDs833xFjghnS1AVmP1LL eptw== X-Gm-Message-State: APjAAAX8Ic71HYd2u4+7uagp8HWMRruPSSFQgQdyOBV5VKTz4jIxqmxi 4MmWyWhdwO4x01dIQ6KACHGtBNF2r2Zdgi/peKw= X-Google-Smtp-Source: APXvYqzsTHz63GrZkJy0W4figgSGvtggJse4+vCWxnVY+xK+7rUiT2UskC6BQbbs60QidB5IzSscW9J1pKt0SygYQxc= X-Received: by 2002:a2e:1290:: with SMTP id 16mr54497631ljs.88.1561162790867; Fri, 21 Jun 2019 17:19:50 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> In-Reply-To: From: Marten Seemann Date: Sat, 22 Jun 2019 08:19:36 +0800 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: David Schinazi Cc: Christian Huitema , Eric Kinnear , IETF QUIC WG , Ian Swett , Martin Thomson , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Nick Banks , Roberto Peon Content-Type: multipart/alternative; boundary="00000000000096163e058bde89a6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 00:20:05 -0000 --00000000000096163e058bde89a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ossification is prevented by actually using all available code points. With the compressed 4 bit encoding, there's a good chance that actually all connection ID lengths will be used by at least some QUIC implementations, so there's minimal risk of ossification. However, with options 2, we use a whole byte to encode just 20 values, resulting in the first 3 bits always being 0 (in v1) - an easy target for ossification. The biggest downside of the 1 byte connection ID length encoding is how you handle unknown versions. Since an implementation must be able to send Version Negotiation packets, and a future QUIC version could increase the connection ID length limit to 255 bytes, option 2 and 3 will require you to have data types that allow parsing of packets with connection IDs that are a quarter of a kilobyte long. You wouldn't want to use fixed-sized buffers for that, and maybe even end up with different connection ID types for short and long header packets. Option 2 therefore gives us the worst of both worlds: We gain very little in actually available connection ID space, but bear the full cost of implementational complexity for handling packets with 255 byte connection IDs. On Sat, Jun 22, 2019 at 7:53 AM David Schinazi wrote: > I=E2=80=99m strongly opposed to option 4. It guarantees ossification by n= ot > allowing other lengths from the get go so it=E2=80=99s strictly less futu= re-proof > than option 2. > > On Fri, Jun 21, 2019 at 16:51 Marten Seemann > wrote: > >> There=E2=80=99s also a 4th option: >> 4) Keep the 4 bit compressed encoding and increase the maximum length to >> 20 bytes. >> >> This could be done by eliminating code points for 15 and 17 byte >> connection IDs (or any other 2 code points that seem less useful). >> I=E2=80=99d prefer that option because of the ossification risks describ= ed >> earlier. >> >> On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rgensen >> wrote: >> >>> Makes sense 2 me 2 >>> >>> >>> On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) >>> wrote: >>> >>> Me too. 2. >>> >>> -- Christian Huitema >>> >>> On Jun 21, 2019, at 1:24 PM, Eric Kinnear < >>> ekinnear=3D40apple.com@dmarc.ietf.org> wrote: >>> >>> (2) would be fine for me! >>> >>> Thanks, >>> Eric >>> >>> >>> On Jun 21, 2019, at 1:23 PM, Nick Banks < >>> nibanks=3D40microsoft.com@dmarc.ietf.org> wrote: >>> >>> Works for me as well. >>> >>> - Nick >>> >>> *From:* QUIC *On Behalf Of *Roberto Peon >>> *Sent:* Friday, June 21, 2019 1:21 PM >>> *To:* David Schinazi ; Ian Swett < >>> ianswett=3D40google.com@dmarc..ietf.org >>> > >>> *Cc:* IETF QUIC WG ; Martin Thomson >>> *Subject:* Re: Consensus Call: More Connection ID Space #2736 >>> >>> Works for me. >>> -=3DR >>> >>> *From: *QUIC on behalf of David Schinazi < >>> dschinazi.ietf@gmail.com> >>> *Date: *Friday, June 21, 2019 at 1:02 PM >>> *To: *Ian Swett >>> *Cc: *IETF QUIC WG , Martin Thomson >>> *Subject: *Re: Consensus Call: More Connection ID Space #2736 >>> >>> +1 to what Ian said. (2) seems like a good path forward >>> >>> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett >> 40google.com@dmarc.ietf.org> wrote: >>> >>> I think the 3 options I see as well reasoned are: >>> 1) Keep the status quo because we think we can put what we really need >>> into 18 bytes if we try. >>> 2) Change to a 1 byte length per CID and a max of 20, which gives us a >>> few extra bytes for cleartext server id and/or key rotation/etc. >>> 3) Change to a 1 byte length per CID and a max of 36, because we want b= e >>> able to put 2 encrypted routing IDs in a single CID. >>> >>> 2 is my preferred option, though I can live with either of 1 or 3. >>> >>> Deciding sooner would be strictly better than later, since this is >>> blocking us(Chrome/Google) actually supporting varlen CIDs. >>> >>> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson >>> wrote: >>> >>> That seems a little high. I think that Ian's principle here is what >>> should guide us: what is the minimum you can handle? What I've heard i= s >>> that 18 might have been workable, but it was REALLY close to the edge t= o >>> the point that you weren't confident it was enough, even in the near >>> term.. But that suggests that 20 is workable. >>> >>> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >>> > so do I hear consensus emerging around 32B in v1, or should I leave t= he >>> >>> > 18B limit in v1 for now and punt out that discussion? >>> > >>> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel >>> wrote: >>> > > >>> > > >>> > > > On 18. Jun 2019, at 05:33, Marten Seemann < >>> martenseemann@gmail.com> wrote: >>> > > > >>> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we >>> decide to increase the connection ID length to a larger value (which I'= m >>> still not convinced that this is really necessary). >>> > > >>> > > This would be easy if we change the encoding of the connection ID >>> length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. Whi= le >>> we can not encode one or two byte connection IDs in long header packets= , we >>> can still use them in short header packets. >>> > > >>> > > This split between long and short header also allows to use much >>> longer connection IDs after the handshake. >>> > > I don=E2=80=99t see much use in it, but it may take off some fear = that >>> 24/32/36/48/60 byte connection IDs might not be long enough in the futu= re. >>> > > >>> > > > >>> > > > There are two main reasons to keep the compressed encoding: >>> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect t= hat all / >>> most values will be used in practice, so we won't expose any bits on th= e >>> wire that identify a packet as "QUIC traffic" by having a predictable v= alue. >>> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an imple= mentation >>> still needs to be able to deal with connection ID lengths of 255 bytes, >>> just to be able to send Version Negotiation packets. To me, it seems ab= surd >>> to write a QUIC implementation that is able to handle packets with a >>> combined connection ID overhead of 510 bytes. Since VNPs are supposed t= o be >>> sent in response to any Long Header packet, you'd have to put some care= ful >>> thought into the design of your data types to avoid this becoming a DoS >>> vector. >>> > > > >>> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < >>> huitema@huitema.net> wrote: >>> > > > I too agree that using one byte in the invariant is preferable t= o >>> the current "compressed 4 bits" solution. >>> > > > >>> > > > Regarding the "CID length limit", I thing there are two issues: >>> transmission overhead, and costs to the community. >>> > > > >>> > > > I am not too concerned with the transmission overhead, as we hav= e >>> there the right mix of costs and incentives. Servers who chose to use >>> longer CID will get more transmission overhead, and thus transmission l= ess >>> efficiently than their competitors. They may chose to use longer CID as= a >>> trade-off between transmission efficiency and ease of management. >>> Competition will sort that out. I note that YouTube is apparently doing >>> fine with smallish CID, so I trust that there will be competition. >>> > > > >>> > > > I am much more concerned with the shared costs, which are a >>> variation of the "tragedy of the commons". Dmitry explained those costs >>> well in a previous message. The simpler implementation is to make the >>> "cid_t a fixed-size object that can fit the largest CID and eat the >>> overhead for all CIDs." But each connection object carries a large numb= er >>> of instances of the CID type. Having a very large max CID would imply a >>> large overhead. The alternative is to "Make cid_t a variable-size objec= t", >>> but too affects performance. >>> > > > >>> > > > Hence the push-back. I would personally prefer a max size of 16, >>> and I think that 32 is the highest practical limit. >>> > > > >>> > > > -- Christian Huitema >>> > > > >>> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >>> > > >> What I think people are saying so far: >>> > > >> >>> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, >>> or 48} >>> > > >> >>> > > >> 2) Representation of CID length as a byte is still OK, thus a >>> QUIC v2 could use longer CIDs as needed by changing the spec while keep= ing >>> the invariants=E2=80=A6 invariant. >>> > > >> >>> > > >> >>> > > >> That seems reasonable to me / I=E2=80=99d still support that. >>> > > >> >>> > > >> -=3DR >>> > > >> >>> > > >> >>> > > >> From: QUIC > >>> on behalf of "Lubashev, Igor" >>> > > >> Date: Monday, June 17, 2019 at 8:55 AM >>> > > >> To: Ian Swett , Mikkel >>> Fahn=C3=B8e J=C3=B8rgensen >>> > > >> Cc: Dmitri Tikhonov , Christian >>> Huitema , "Philipp S. Tiesel" = , >>> Mike Bishop , Martin Thomson , >>> Marten Seemann , Lars Eggert = , >>> QUIC WG , Martin Duke >> martin..h.duke@gmail.com>>, Kazuho Oku >> > >>> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >>> > > >> >>> > > >> >>> > > >> >>> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32= is >>> likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should proba= bly be a factor of >>> 8, so 32 or 24?). >>> > > >> >>> > > >> >>> > > >> >>> > > >> We are firmly committed for using CID for in-cluster load >>> balancing / anycast pop routing. This discussion is taking us, however,= to >>> a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled= routing in an >>> overlay network=E2=80=9D. This is a very interesting topic, but I would= hesitate to >>> attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. >>> > > >> >>> > > >> >>> > > >> >>> > > >> =E2=80=A2 Igor >>> > > >> >>> > > >> >>> > > >> From: Ian Swett >>> > > >> >>> > > >> My intuition says making the change to the invariants is the >>> right thing to do, but I don't feel that strongly.. >>> > > >> >>> > > >> >>> > > >> >>> > > >> However, I'd like the max size to be smaller than 48(but larger >>> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho >>> suggested 32, which is better, but I don't believe the server needs to = use >>> a separate block cipher when giving out connection IDs, because I belie= ve >>> it's impractical for the load balancer and server to be that decoupled.= The >>> server has to give out a CID that the load balancer will use to route b= ack >>> to the server, so they have to share enough an encryption key/algorithm= . I >>> can imagine nesting load balancers, but that's well in the range of QUI= C v2 >>> from my perspective. >>> > > >> >>> > > >> >>> > > >> >>> > > >> Whatever we do, I'd really prefer to resolve this sooner rather >>> than later and be truly done with it. >>> > > >> >>> > > >> >>> > > >> >>> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgens= en < >>> mikkelfj@gmail.com> wrote: >>> > > >> >>> > > >> Since it is more likely that you pay for egress traffic than >>> ingress traffic, the motivation to keep CID=E2=80=99s small is limited. >>> > > >> >>> > > >> >>> > > >> >>> > > >> I do think the invariants should allow for long CID=E2=80=99s a= s >>> proposed, and that the long header overhead is not important... >>> > > >> >>> > > >> >>> > > >> >>> > > >> But for QUIC v1, if we allow for a long CID, a rush to market >>> will set precedence and long CID=E2=80=99s will ossify in all kinds of = stacks. >>> > > >> >>> > > >> >>> > > >> >>> > > >> I good reference on an algorithm like suggested by Christian >>> would go a long way. >>> > > >> >>> > > >> >>> > > >> >>> > > >> If CID length 18 turns out to be not enough, we can add a QUIC >>> v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUI= C versions >>> soon. >>> > > >> >>> > > >> >>> > > >> >>> > > >> If CID length negotiation is needed, this could be done via QUI= C >>> versions. For example two functionally equivalent versions, but one wit= h >>> longer CID=E2=80=99s. This would also allow routers to deal with change= s in CID >>> lengths. A negotiated TP would not (easily) allow for that and aside I = do >>> not think CID length in TP is the way to go. >>> > > >> >>> > > >> >>> > > >> >>> > > >> Mikkel >>> > > >> >>> > > >> >>> > > >> >>> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) >>> wrote: >>> > > >> >>> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian H= uitema : >>> > > >> > >>> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >>> > > >> > >>> > > >> > > _If_ we are to allow loose coupling between a load balancer >>> and a >>> > > >> > > server, each of the two should be given the freedom to >>> choose it's own >>> > > >> > > CID encryption scheme. Because all the standardized block >>> ciphers are >>> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the >>> maximum CID >>> > > >> > > length of QUIC needs to be double amount of that, plus one >>> or two >>> > > >> > > bytes for each of the two for identifying the CID encryptio= n >>> keys. For >>> > > >> > > key identification and other supplemental use, we currently >>> allocate 2 >>> > > >> > > bytes (18-16=3D2). >>> > > >> > >>> > > >> > That reasoning is based on the assumption that both the load >>> balancer >>> > > >> > and the server must use a block cipher with 128 bit block >>> length in >>> > > >> > order to encrypt the CID. If they were constrained to stay >>> within a >>> > > >> > short global limit, they could use different sets of >>> algorithms. >>> > > >> > >>> > > >> > Assume for example that we split the CID between 32 bits >>> encoding the >>> > > >> > number of the server in the server farm, and 64 bit encoding >>> the >>> > > >> > connection number for the server. The server can pick a rando= m >>> value for >>> > > >> > the connection number, and use a hash table. The load balance= r >>> could use >>> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit >>> of the CID >>> > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong >>> encryption. >>> > > >> > >>> > > >> > Or assume that the server wants to use short CID. We now spli= t >>> the CID >>> > > >> > between 32 bit for the server number in the farm, and 32 bit >>> for the >>> > > >> > connection number in the server. The server builds that >>> connection >>> > > >> > number by using a 32 bit variant of FFX. The load balancer >>> also uses a >>> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial >>> vector for >>> > > >> > this FFX encryption. >>> > > >> > >>> > > >> > These are just two examples. And yes you may want to add 2 >>> bytes for key >>> > > >> > identification, etc. In both encryption algorithms, you can >>> feed these >>> > > >> > two bytes as additional IV for the FFX algorithm. And in both >>> cases, we >>> > > >> > are well below the 18 byte limit. >>> > > >> > >>> > > >> > Yes, that requires some creative engineering. But it is not >>> rocker >>> > > >> > science. And it seems better than carrying tons of overhead i= n >>> the >>> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. >>> > > >> >>> > > >> I agree that it would not be the end of the world for the load >>> > > >> balancers if we decide to stick on the 18-byte limit. However, >>> as you >>> > > >> state, it requires some creativeness. >>> > > >> >>> > > >> To me it seems that the question is if we have a strong reason = to >>> >>> > > >> require some people to be creative, for all the versions of QUI= C >>> in >>> > > >> the future. I personally think that there isn't a strong reason= , >>> >>> > > >> because people can use shorter CIDs regardless of the decision = we >>> >>> > > >> make. IIUC, the overhead that everyone needs to accept is: >>> > > >> >>> > > >> * one byte increase in the long header packets >>> > > >> * the minimum size of short header packets becoming slightly >>> greater >>> > > >> (otherwise, the peer might not be able to send a stateless rese= t) >>> >>> > > >> >>> > > >> I'd say that the first bullet point is negligible. The second >>> point >>> > > >> could also be, because I'd assume that the only frequently-sent >>> > > >> packets that require additional padding is the ACK-only packets= , >>> but >>> > > >> there's no reason to pad ACK-only packets in hope that you'd se= e >>> a >>> > > >> stateless reset. >>> > > >> >>> > > >> Therefore, my (not-so-strong) preference has been to provide >>> extra >>> > > >> room, so that some people with necessity can use longer CIDs. >>> > > >> >>> > > >> > >>> > > >> > -- Christian Huitema >>> > > >> > >>> > > >> > >>> > > >> > >>> > > >> >>> > > >> >>> > > >> >>> > > >> -- >>> > > >> Kazuho Oku >>> > > >> >>> > > >>> > > AVE! >>> > > Philipp S. Tiesel >>> > > >>> > > -- >>> > > Philipp S. Tiesel >>> > > https://philipp.tiesel.net/ >>> >>> > > >>> >>> >>> --00000000000096163e058bde89a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ossification is prevented by actually using all available = code points. With the compressed 4 bit encoding, there's a good chance = that actually all connection ID lengths will be used by at least some QUIC = implementations, so there's minimal risk of ossification. However, with= options 2, we use a whole byte to encode just 20 values, resulting in the = first 3 bits always being 0 (in v1) - an easy target for ossification.
=
The biggest downside of the 1 byte connection ID length enco= ding is how you handle unknown versions. Since an implementation must be ab= le to send Version Negotiation packets, and a future QUIC version could inc= rease the connection ID length limit to 255 bytes, option 2 and 3 will requ= ire you to have data types that allow parsing of packets with connection ID= s that are a quarter of a kilobyte long. You wouldn't want to use fixed= -sized buffers for that, and maybe even end up with different connection ID= types for short and long header packets.

Option 2= therefore gives us the worst of both worlds: We gain very little in actual= ly available connection ID space, but bear the full cost of implementationa= l complexity for handling packets with 255 byte connection IDs.
=
On Sat= , Jun 22, 2019 at 7:53 AM David Schinazi <dschinazi.ietf@gmail.com> wrote:
I=E2=80=99m st= rongly opposed to option 4. It guarantees ossification by not allowing othe= r lengths from the get go so it=E2=80=99s strictly less future-proof than o= ption 2.

On Fri, Jun 21, 2019 at 16:51 Marten Seemann <martenseemann@gmail.c= om> wrote:
There=E2=80=99s also a 4th option:
4) Keep the 4 bit compressed encoding and increase the maximu= m length to 20 bytes.

Th= is could be done by eliminating code points for 15 and 17 byte connection I= Ds (or any other 2 code points that seem less useful).
I=E2=80=99d prefer that option because of the ossification risks describ= ed earlier.

On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rge= nsen <mikkelfj@g= mail.com> wrote:
Makes sense 2 me 2


On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) wrote:

=
Me too. 2.

-- Christian Huitema=C2=A0

On Jun 21, 2019, at 1:24 PM, Eric Kinnear <ekinnear=3D40apple.com@dmarc.= ietf.org> wrote:

(2) would be fine for me!

Thanks,
Eric


On Jun 21, 2019, at 1:23 PM, Nick Banks <nibanks=3D40microsoft.= com@dmarc.ietf.org> wrote:

Works for me as well.
=C2=A0
- Nick
=C2=A0
From:=C2=A0QUIC &= lt;quic-bounces@= ietf.org>=C2=A0On Behalf Of=C2=A0Roberto Peon
Sent:=C2=A0Friday, June 21,= 2019 1:21 PM
To:=C2=A0David Schinazi <= ;dschinazi.ie= tf@gmail.com>; Ian Swett <ianswett=3D40google.com@dmarc..ietf.or= g>
Cc:=C2=A0IETF QUIC WG <<= a href=3D"mailto:quic@ietf.org" target=3D"_blank">quic@ietf.org>; Ma= rtin Thomson <mt@lowen= tropy.net>
Subject:=C2=A0Re: Consensus= Call: More Connection ID Space #2736
=C2=A0
Works for me.
-=3DR
=C2=A0
From:=C2=A0QUIC <quic-bounces@ietf.org> on behalf of Da= vid Schinazi <dschinazi.ietf@gmail.com> Date:=C2=A0Friday, June 21,= 2019 at 1:02 PM
To:=C2=A0Ian Swett <ianswett=3D40google.com@dmarc= .ietf.org>
Cc:=C2=A0IETF QUIC WG <<= a href=3D"mailto:quic@ietf.org" style=3D"color:purple;text-decoration:under= line" target=3D"_blank">quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
Subject:=C2=A0Re: Consensus= Call: More Connection ID Space #2736
=C2=A0
+1 to what Ian said. (2) seems like a good path forward
=C2=A0
On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=3D40google.com@dmarc.ie= tf.org> wrote:
I think the 3 options I see as well reasoned are:=C2=A0
1) Keep the status quo because we think we can put what we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID.
=C2=A0
2 is my preferred option, though I can live with either of 1 or 3.
=C2=A0
Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs.
=C2=A0
On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:

That seems a little high.=C2=A0 I think that Ian's principle here is what should guide us: what is the minimum you can handle?=C2=A0 What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term..=C2=A0 But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the=C2=A0
> 18B limit in v1 for now and punt out that discussion?
>=C2=A0
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote:
> >=C2=A0
> >=C2=A0
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrot= e:
> >=C2=A0 >=C2=A0
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary).
> >=C2=A0
> >=C2=A0 This would be easy if we change the encoding of the connection ID length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
> >=C2=A0
> >=C2=A0 This split between long and short header also allows to use much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future.
> >=C2=A0
> >=C2=A0 >=C2=A0
> >=C2=A0 > There are two main reasons to keep the compressed encoding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector.
> >=C2=A0 >=C2=A0
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitema@huitema.net> wrot= e:
> >=C2=A0 > I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.
> >=C2=A0 >=C2=A0
> >=C2=A0 > I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.
> >=C2=A0 >=C2=A0
> >=C2=A0 > Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >=C2=A0
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >=C2=A0
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48}
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still support that.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> -=3DR
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>, Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Christian Huitema <huitema@huitema.net>, "Phili= pp S. Tiesel" <philipp@tiesel.net= >, Mike Bishop <mbishop@evequefou.be<= /a>>, Martin Thomson <mt@lowentropy.net<= /a>>, Marten Seemann <martenseeman= n@gmail.com>, Lars Eggert <lars@eggert= .org>, QUIC WG <quic@ietf.org>, M= artin Duke <martin.h.duke@gmail.com<mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.= com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Space #2736
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80= =9D (it should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> We are firmly committed for using CID for in-cluster load balancing / anycast pop routing. This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D. Thi= s is a very interesting topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly..
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmai= l.com> wrote:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I do think the invariants should allow for long CID=E2=80=99s as proposed, and that the long header overhead is not important...
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I good reference on an algorithm like suggested by Christian would go a long way.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versions soon.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Mikkel
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrote:
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> 2019=E5=B9=B46=E6= =9C=8817=E6=97=A5<= /span>(=E6=9C=88) = 11:09 Christian Huitema <huitema@huitema.= net>:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > > _If_ we are to allow loose coupling between a load balancer and a=C2= =A0
> >=C2=A0 >> > > server, each of the two should be given the freedom to choose it's own=C2= =A0
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID=C2= =A0
> >=C2=A0 >> > > length of QUIC needs to be double amount of that, plus one or two=C2= =A0
> >=C2=A0 >> > > bytes for each of the two for identifying the CID encryption keys. For= =C2=A0
> >=C2=A0 >> > > key identification and other supplemental use, we currently allocate 2= =C2=A0
> >=C2=A0 >> > > bytes (18-16=3D2).=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > That reasoning is based on the assumption that both the load balancer=C2= =A0
> >=C2=A0 >> > and the server must use a block cipher with 128 bit block length in=C2=A0=
> >=C2=A0 >> > order to encrypt the CID. If they were constrained to stay within a=C2=A0
> >=C2=A0 >> > short global limit, they could use different sets of algorithms.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Assume for example that we split the CID between 32 bits encoding the=C2=A0
> >=C2=A0 >> > number of the server in the server farm, and 64 bit encoding the=C2=A0
> >=C2=A0 >> > connection number for the server. The server can pick a random value for=C2=A0<= /span>
> >=C2=A0 >> > the connection number, and use a hash table. The load balancer could use=C2=A0<= /span>
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID=C2=A0
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption.=C2= =A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Or assume that the server wants to use short CID. We now split the CID=C2=A0=
> >=C2=A0 >> > between 32 bit for the server number in the farm, and 32 bit for the=C2=A0
> >=C2=A0 >> > connection number in the server. The server builds that connection=C2=A0
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The load balancer also uses a=C2=A0<= /span>
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for=C2= =A0
> >=C2=A0 >> > this FFX encryption.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > These are just two examples. And yes you may want to add 2 bytes for key=C2=A0=
> >=C2=A0 >> > identification, etc. In both encryption algorithms, you can feed these= =C2=A0
> >=C2=A0 >> > two bytes as additional IV for the FFX algorithm. And in both cases, we=C2= =A0
> >=C2=A0 >> > are well below the 18 byte limit.=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > Yes, that requires some creative engineering. But it is not rocker=C2=A0
> >=C2=A0 >> > science. And it seems better than carrying tons of overhead in the=C2=A0
> >=C2=A0 >> > header, and becoming less efficient than HTTP2/TLS/TCP.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I agree that it would not be the end of the world for the load=C2=A0
> >=C2=A0 >> balancers if we decide to stick on the 18-byte limit. However, as you=C2=A0
> >=C2=A0 >> state, it requires some creativeness.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> To me it seems that the question is if we have a strong reason to=C2=A0
> >=C2=A0 >> require some people to be creative, for all the versions of QUIC in=C2=A0<= br> > >=C2=A0 >> the future. I personally think that there isn't a strong reason,=C2=A0 > >=C2=A0 >> because people can use shorter CIDs regardless of the decision we=C2=A0
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to accept is:=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> * one byte increase in the long header packets=C2=A0
> >=C2=A0 >> * the minimum size of short header packets becoming slightly greater=C2=A0 > >=C2=A0 >> (otherwise, the peer might not be able to send a stateless reset)=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> I'd say that the first bullet point is negligible. The second point=C2=A0=
> >=C2=A0 >> could also be, because I'd assume that the only frequently-sent=C2=A0
> >=C2=A0 >> packets that require additional padding is the ACK-only packets, but=C2=A0 > >=C2=A0 >> there's no reason to pad ACK-only packets in hope that you'd see a=C2=A0=
> >=C2=A0 >> stateless reset.= =C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been to provide extra=C2=A0 > >=C2=A0 >> room, so that some people with necessity can use longer CIDs.=C2=A0
> >=C2=A0 >>=C2=A0
> >=C2=A0 >> >=C2=A0
> >=C2=A0 >> > -- Christian Huitema=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
> >=C2=A0 >> --=C2=A0<= br> > >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>=C2=A0
> >=C2=A0
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >=C2=A0
> >=C2=A0 --=C2=A0
> >=C2=A0 Philipp S. Tiesel=C2=A0
> >=C2=A0https://philipp.tiesel.net/
> >


--00000000000096163e058bde89a6-- From nobody Fri Jun 21 18:37:50 2019 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 4E200120196 for ; Fri, 21 Jun 2019 18:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 5edVaQU4lfh3 for ; Fri, 21 Jun 2019 18:37:45 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 9310C12017F for ; Fri, 21 Jun 2019 18:37:44 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id a21so7526363ljh.7 for ; Fri, 21 Jun 2019 18:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Rx3NyifD61zoaWdB7R1WP0NHwyHTGaxFyxsw3oWTtzY=; b=Ilu3CBAXmoXrk1ylz0FwaSZ/pW1JDE1jbNFmyrtugMfKEy7TTu1llBQCEcg86BfRkl z8sDK+P5dRGEMgD0k8lOW7mIKqn85eqF/6EvVjp9uAPQsjjt0xPjLaY/IiEgLktoJnGQ tr6t/SSvFcPdQ3L+Sx2lH2E+VKSxPk/DxcxAsmSsY+KL5DdJarXuasY3P3mjiG880DKN lvwotAEcFLlyUdD89HOjK4PVoIFJRM/8u9kBra+Lcj7KQhzK9mB1smduBFuU6aIPveti dgXP035pGyFFufLzQnIufwFb06Qm2v9t7t7iVhdWgFe9mCsSvXcU+R36I9iT7A4v+VOy xdMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Rx3NyifD61zoaWdB7R1WP0NHwyHTGaxFyxsw3oWTtzY=; b=hxs7M34ZssdCHyR0I2E0icnDFCiwlCchamB/Gzn9Qqh9QLM1xpR48FcOKEs4zYMxfF 3NrwitNtCWCal+RDad5ydrA8uAVvCVCem5MGHU9pBJYV19UJ36rguX6SGT//46DtLep/ ykMM5arlbgeGhEOpW/coBipJvodOINCzgRS2iC9JDP9QGsfPwIFzRBzBlu5UYm+aBVg1 vDiwZOqZnEo8b9C/BI70VSDQ7tgBsgySD2DJN+fppE/7HLfjmWSP4BmgdTM2J+NiVhzr 50NaP9d7SvqmL+nzUdqAal+J+gpMmcjDHZiJktpVoeg4Ax9dQ0w9TYtvNi30QwQjnIZq yIgQ== X-Gm-Message-State: APjAAAV7IFAnWz0SX+K5K2hzJ4E5acZnZiEAwR8UpdzqKKz7QMazqNML dSDJnJ4pF/0/FedDT8moOYfzxaXdBtw6cZ9O9OU= X-Google-Smtp-Source: APXvYqwFB4JSECc5dWVxbGls5+lLZC9mDREqPfmT58r7hkYVClf/d305uWLrfEVPbmWyM3zHtdaWOeUME5WYV69moMY= X-Received: by 2002:a2e:9212:: with SMTP id k18mr27975995ljg.15.1561167462544; Fri, 21 Jun 2019 18:37:42 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> In-Reply-To: From: Kazuho Oku Date: Sat, 22 Jun 2019 10:37:31 +0900 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Marten Seemann Cc: David Schinazi , Nick Banks , Roberto Peon , Eric Kinnear , Christian Huitema , Ian Swett , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 01:37:48 -0000 2019=E5=B9=B46=E6=9C=8822=E6=97=A5(=E5=9C=9F) 9:20 Marten Seemann : > > Ossification is prevented by actually using all available code points. Wi= th the compressed 4 bit encoding, there's a good chance that actually all c= onnection ID lengths will be used by at least some QUIC implementations, so= there's minimal risk of ossification. However, with options 2, we use a wh= ole byte to encode just 20 values, resulting in the first 3 bits always bei= ng 0 (in v1) - an easy target for ossification. > > The biggest downside of the 1 byte connection ID length encoding is how y= ou handle unknown versions. Since an implementation must be able to send Ve= rsion Negotiation packets, and a future QUIC version could increase the con= nection ID length limit to 255 bytes, option 2 and 3 will require you to ha= ve data types that allow parsing of packets with connection IDs that are a = quarter of a kilobyte long. You wouldn't want to use fixed-sized buffers fo= r that, and maybe even end up with different connection ID types for short = and long header packets. > > Option 2 therefore gives us the worst of both worlds: We gain very little= in actually available connection ID space, but bear the full cost of imple= mentational complexity for handling packets with 255 byte connection IDs. While I am not generally opposed to option 2 (I do not think it is *that* bad to argue against reaching consensus), I agree that is a concern. And actually, I think there is a beautiful way of encoding CID length in 5 bits: combine the first octet and the CIDL octet that we have now into a uint16_t, and use 5 * 2 bits of that 16-bit field to represent the CID lengths. As a coincidence, we have two unused bits in the long header fields of QUIC v1 (with the exception of Retry [1]). This change would remove those unused bits (and the need for handling them correctly). So it simplifies v1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|T T|X X| DCIDL(5)| SCIDL(5)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Connection ID (0/32..272) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Connection ID (0/32..272) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [1] Retry uses the four bits of the first octet to carry ODCIDL. We would need to use a dedicated octet for carrying ODCIDL if we decide mo make CIDL longer than 4 bits. > > On Sat, Jun 22, 2019 at 7:53 AM David Schinazi = wrote: >> >> I=E2=80=99m strongly opposed to option 4. It guarantees ossification by = not allowing other lengths from the get go so it=E2=80=99s strictly less fu= ture-proof than option 2. >> >> On Fri, Jun 21, 2019 at 16:51 Marten Seemann w= rote: >>> >>> There=E2=80=99s also a 4th option: >>> 4) Keep the 4 bit compressed encoding and increase the maximum length t= o 20 bytes. >>> >>> This could be done by eliminating code points for 15 and 17 byte connec= tion IDs (or any other 2 code points that seem less useful). >>> I=E2=80=99d prefer that option because of the ossification risks descri= bed earlier. >>> >>> On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >>>> >>>> Makes sense 2 me 2 >>>> >>>> >>>> On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.net) w= rote: >>>> >>>> Me too. 2. >>>> >>>> -- Christian Huitema >>>> >>>> On Jun 21, 2019, at 1:24 PM, Eric Kinnear wrote: >>>> >>>> (2) would be fine for me! >>>> >>>> Thanks, >>>> Eric >>>> >>>> >>>> On Jun 21, 2019, at 1:23 PM, Nick Banks wrote: >>>> >>>> Works for me as well. >>>> >>>> - Nick >>>> >>>> From: QUIC On Behalf Of Roberto Peon >>>> Sent: Friday, June 21, 2019 1:21 PM >>>> To: David Schinazi ; Ian Swett >>>> Cc: IETF QUIC WG ; Martin Thomson >>>> Subject: Re: Consensus Call: More Connection ID Space #2736 >>>> >>>> Works for me. >>>> -=3DR >>>> >>>> From: QUIC on behalf of David Schinazi >>>> Date: Friday, June 21, 2019 at 1:02 PM >>>> To: Ian Swett >>>> Cc: IETF QUIC WG , Martin Thomson >>>> Subject: Re: Consensus Call: More Connection ID Space #2736 >>>> >>>> +1 to what Ian said. (2) seems like a good path forward >>>> >>>> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett wrote: >>>> >>>> I think the 3 options I see as well reasoned are: >>>> 1) Keep the status quo because we think we can put what we really need= into 18 bytes if we try. >>>> 2) Change to a 1 byte length per CID and a max of 20, which gives us a= few extra bytes for cleartext server id and/or key rotation/etc. >>>> 3) Change to a 1 byte length per CID and a max of 36, because we want = be able to put 2 encrypted routing IDs in a single CID. >>>> >>>> 2 is my preferred option, though I can live with either of 1 or 3. >>>> >>>> Deciding sooner would be strictly better than later, since this is blo= cking us(Chrome/Google) actually supporting varlen CIDs. >>>> >>>> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wro= te: >>>> >>>> That seems a little high. I think that Ian's principle here is what s= hould guide us: what is the minimum you can handle? What I've heard is tha= t 18 might have been workable, but it was REALLY close to the edge to the p= oint that you weren't confident it was enough, even in the near term.. But= that suggests that 20 is workable. >>>> >>>> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >>>> > so do I hear consensus emerging around 32B in v1, or should I leave = the >>>> > 18B limit in v1 for now and punt out that discussion? >>>> > >>>> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel wrote: >>>> > > >>>> > > >>>> > > > On 18. Jun 2019, at 05:33, Marten Seemann wrote: >>>> > > > >>>> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we= decide to increase the connection ID length to a larger value (which I'm s= till not convinced that this is really necessary). >>>> > > >>>> > > This would be easy if we change the encoding of the connection ID= length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While = we can not encode one or two byte connection IDs in long header packets, we= can still use them in short header packets. >>>> > > >>>> > > This split between long and short header also allows to use much = longer connection IDs after the handshake. >>>> > > I don=E2=80=99t see much use in it, but it may take off some fear= that 24/32/36/48/60 byte connection IDs might not be long enough in the fu= ture. >>>> > > >>>> > > > >>>> > > > There are two main reasons to keep the compressed encoding: >>>> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect = that all / most values will be used in practice, so we won't expose any bit= s on the wire that identify a packet as "QUIC traffic" by having a predicta= ble value. >>>> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an impl= ementation still needs to be able to deal with connection ID lengths of 255= bytes, just to be able to send Version Negotiation packets. To me, it seem= s absurd to write a QUIC implementation that is able to handle packets with= a combined connection ID overhead of 510 bytes. Since VNPs are supposed to= be sent in response to any Long Header packet, you'd have to put some care= ful thought into the design of your data types to avoid this becoming a DoS= vector. >>>> > > > >>>> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema wrote: >>>> > > > I too agree that using one byte in the invariant is preferable = to the current "compressed 4 bits" solution. >>>> > > > >>>> > > > Regarding the "CID length limit", I thing there are two issues:= transmission overhead, and costs to the community. >>>> > > > >>>> > > > I am not too concerned with the transmission overhead, as we ha= ve there the right mix of costs and incentives. Servers who chose to use lo= nger CID will get more transmission overhead, and thus transmission less ef= ficiently than their competitors. They may chose to use longer CID as a tra= de-off between transmission efficiency and ease of management. Competition = will sort that out. I note that YouTube is apparently doing fine with small= ish CID, so I trust that there will be competition. >>>> > > > >>>> > > > I am much more concerned with the shared costs, which are a var= iation of the "tragedy of the commons". Dmitry explained those costs well i= n a previous message. The simpler implementation is to make the "cid_t a fi= xed-size object that can fit the largest CID and eat the overhead for all C= IDs." But each connection object carries a large number of instances of the= CID type. Having a very large max CID would imply a large overhead. The al= ternative is to "Make cid_t a variable-size object", but too affects perfor= mance. >>>> > > > >>>> > > > Hence the push-back. I would personally prefer a max size of 16= , and I think that 32 is the highest practical limit. >>>> > > > >>>> > > > -- Christian Huitema >>>> > > > >>>> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >>>> > > >> What I think people are saying so far: >>>> > > >> >>>> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36,= or 48} >>>> > > >> >>>> > > >> 2) Representation of CID length as a byte is still OK, thus a = QUIC v2 could use longer CIDs as needed by changing the spec while keeping = the invariants=E2=80=A6 invariant. >>>> > > >> >>>> > > >> >>>> > > >> That seems reasonable to me / I=E2=80=99d still support that. >>>> > > >> >>>> > > >> -=3DR >>>> > > >> >>>> > > >> >>>> > > >> From: QUIC on behalf of "Lubashev, Igo= r" >>>> > > >> Date: Monday, June 17, 2019 at 8:55 AM >>>> > > >> To: Ian Swett , Mikkel= Fahn=C3=B8e J=C3=B8rgensen >>>> > > >> Cc: Dmitri Tikhonov , Christian H= uitema , "Philipp S. Tiesel" , Mik= e Bishop , Martin Thomson , Marten= Seemann , Lars Eggert , QUIC WG= , Martin Duke >, Kazuho Oku >>>> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> My take is similar =E2=80=93 48 is probably excessive, while 3= 2 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should prob= ably be a factor of 8, so 32 or 24?). >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> We are firmly committed for using CID for in-cluster load bala= ncing / anycast pop routing. This discussion is taking us, however, to a ne= w territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing= in an overlay network=E2=80=9D. This is a very interesting topic, but I wo= uld hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D = in QUIC v1. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> =E2=80=A2 Igor >>>> > > >> >>>> > > >> >>>> > > >> From: Ian Swett >>>> > > >> >>>> > > >> My intuition says making the change to the invariants is the r= ight thing to do, but I don't feel that strongly.. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> However, I'd like the max size to be smaller than 48(but large= r than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho sug= gested 32, which is better, but I don't believe the server needs to use a s= eparate block cipher when giving out connection IDs, because I believe it's= impractical for the load balancer and server to be that decoupled. The ser= ver has to give out a CID that the load balancer will use to route back to = the server, so they have to share enough an encryption key/algorithm. I can= imagine nesting load balancers, but that's well in the range of QUIC v2 fr= om my perspective. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> Whatever we do, I'd really prefer to resolve this sooner rathe= r than later and be truly done with it. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgen= sen wrote: >>>> > > >> >>>> > > >> Since it is more likely that you pay for egress traffic than i= ngress traffic, the motivation to keep CID=E2=80=99s small is limited. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> I do think the invariants should allow for long CID=E2=80=99s = as proposed, and that the long header overhead is not important... >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> But for QUIC v1, if we allow for a long CID, a rush to market = will set precedence and long CID=E2=80=99s will ossify in all kinds of stac= ks. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> I good reference on an algorithm like suggested by Christian w= ould go a long way. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> If CID length 18 turns out to be not enough, we can add a QUIC= v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC v= ersions soon. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> If CID length negotiation is needed, this could be done via QU= IC versions. For example two functionally equivalent versions, but one with= longer CID=E2=80=99s. This would also allow routers to deal with changes i= n CID lengths. A negotiated TP would not (easily) allow for that and aside = I do not think CID length in TP is the way to go. >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> Mikkel >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) = wrote: >>>> > > >> >>>> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian = Huitema : >>>> > > >> > >>>> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >>>> > > >> > >>>> > > >> > > _If_ we are to allow loose coupling between a load balance= r and a >>>> > > >> > > server, each of the two should be given the freedom to cho= ose it's own >>>> > > >> > > CID encryption scheme. Because all the standardized block = ciphers are >>>> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the= maximum CID >>>> > > >> > > length of QUIC needs to be double amount of that, plus one= or two >>>> > > >> > > bytes for each of the two for identifying the CID encrypti= on keys. For >>>> > > >> > > key identification and other supplemental use, we currentl= y allocate 2 >>>> > > >> > > bytes (18-16=3D2). >>>> > > >> > >>>> > > >> > That reasoning is based on the assumption that both the load= balancer >>>> > > >> > and the server must use a block cipher with 128 bit block le= ngth in >>>> > > >> > order to encrypt the CID. If they were constrained to stay w= ithin a >>>> > > >> > short global limit, they could use different sets of algorit= hms. >>>> > > >> > >>>> > > >> > Assume for example that we split the CID between 32 bits enc= oding the >>>> > > >> > number of the server in the server farm, and 64 bit encoding= the >>>> > > >> > connection number for the server. The server can pick a rand= om value for >>>> > > >> > the connection number, and use a hash table. The load balanc= er could use >>>> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bi= t of the CID >>>> > > >> > as an initial vector. Voila, 96 CID, with demonstrably stron= g encryption. >>>> > > >> > >>>> > > >> > Or assume that the server wants to use short CID. We now spl= it the CID >>>> > > >> > between 32 bit for the server number in the farm, and 32 bit= for the >>>> > > >> > connection number in the server. The server builds that conn= ection >>>> > > >> > number by using a 32 bit variant of FFX. The load balancer a= lso uses a >>>> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial= vector for >>>> > > >> > this FFX encryption. >>>> > > >> > >>>> > > >> > These are just two examples. And yes you may want to add 2 b= ytes for key >>>> > > >> > identification, etc. In both encryption algorithms, you can = feed these >>>> > > >> > two bytes as additional IV for the FFX algorithm. And in bot= h cases, we >>>> > > >> > are well below the 18 byte limit. >>>> > > >> > >>>> > > >> > Yes, that requires some creative engineering. But it is not = rocker >>>> > > >> > science. And it seems better than carrying tons of overhead = in the >>>> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. >>>> > > >> >>>> > > >> I agree that it would not be the end of the world for the load >>>> > > >> balancers if we decide to stick on the 18-byte limit. However,= as you >>>> > > >> state, it requires some creativeness. >>>> > > >> >>>> > > >> To me it seems that the question is if we have a strong reason= to >>>> > > >> require some people to be creative, for all the versions of QU= IC in >>>> > > >> the future. I personally think that there isn't a strong reaso= n, >>>> > > >> because people can use shorter CIDs regardless of the decision= we >>>> > > >> make. IIUC, the overhead that everyone needs to accept is: >>>> > > >> >>>> > > >> * one byte increase in the long header packets >>>> > > >> * the minimum size of short header packets becoming slightly g= reater >>>> > > >> (otherwise, the peer might not be able to send a stateless res= et) >>>> > > >> >>>> > > >> I'd say that the first bullet point is negligible. The second = point >>>> > > >> could also be, because I'd assume that the only frequently-sen= t >>>> > > >> packets that require additional padding is the ACK-only packet= s, but >>>> > > >> there's no reason to pad ACK-only packets in hope that you'd s= ee a >>>> > > >> stateless reset. >>>> > > >> >>>> > > >> Therefore, my (not-so-strong) preference has been to provide e= xtra >>>> > > >> room, so that some people with necessity can use longer CIDs. >>>> > > >> >>>> > > >> > >>>> > > >> > -- Christian Huitema >>>> > > >> > >>>> > > >> > >>>> > > >> > >>>> > > >> >>>> > > >> >>>> > > >> >>>> > > >> -- >>>> > > >> Kazuho Oku >>>> > > >> >>>> > > >>>> > > AVE! >>>> > > Philipp S. Tiesel >>>> > > >>>> > > -- >>>> > > Philipp S. Tiesel >>>> > > https://philipp.tiesel.net/ >>>> > > >>>> >>>> --=20 Kazuho Oku From nobody Fri Jun 21 19:01:18 2019 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 1D42912013A for ; Fri, 21 Jun 2019 19:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-jWXUDjVnq8 for ; Fri, 21 Jun 2019 19:01:14 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD87120073 for ; Fri, 21 Jun 2019 19:01:14 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5M1v4QV029046; Sat, 22 Jun 2019 03:01:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=QjBYFtWgx6OuKvOa1vPU5AfLZC6OhRAxWUkRVKBp6Hw=; b=okulJa2xM/bV3ZnZVMPjr4dqBcyhZWINQey0TiAEIpvzF6nwVJzEqVg9dqOk6dvvAIYq AETKj4j1+N+X4i9soc9ZESF3NMLl/KdqjH9xt52zokhHtOvELrnT+4ICQuvMbY12Y5iq ds5qzZuZMnoj/peZnoxeZS0itKD7amV9PSt1gkxhWdvMS7g5pkVyk/zzmz95Q0k71pZi 6mIldUxF4i81472UVKWcw8zensIN+gfcDM05VgMoBDfrfiRLrUH18xaIGttTBmd8PJg8 tldDJj8hqEmGQVGpqHiujwS88r5jQuSyVh0CockEAwhGX8fpTUvWHzwnxGBb+cEZJHyD 0Q== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2t8x81argt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jun 2019 03:01:05 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5M1kwaG005019; Fri, 21 Jun 2019 22:01:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2t4v0yvx9p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 21 Jun 2019 22:00:59 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 21:00:15 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1473.004; Fri, 21 Jun 2019 21:00:15 -0500 From: "Lubashev, Igor" To: Kazuho Oku , Marten Seemann CC: Nick Banks , Roberto Peon , Eric Kinnear , "Christian Huitema" , Ian Swett , David Schinazi , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , IETF QUIC WG , Martin Thomson Subject: RE: Consensus Call: More Connection ID Space #2736 Thread-Topic: Consensus Call: More Connection ID Space #2736 Thread-Index: AQHVIORfIEAEcQG34kqDfkKYdPIPi6aX4jCAgAGE3YCAAA8NgIAABlqAgAC3vwCAAPW4AIAAk0mAgAFeAoCAAHVigIAAkbsAgAFTDwCAACtYAIAAI0iAgACS+YD//6zYIIAAXkeAgAA7jQCAAIGGgIAAUS2AgALnAQCAAO6XgIABo/UAgAAAkgCAAAVbAIAAAH2AgAAAUACAABMDgIAAHUWAgAAJeYCAAACOAIAAB3EAgAAVxYD//61zkA== Date: Sat, 22 Jun 2019 02:00:15 +0000 Message-ID: <8b3282c37b8f42ee8f4aefb6a853a761@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.184] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-22_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906220014 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-22_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906220016 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 02:01:17 -0000 SSBhbSBmaXJzdCB0byBhcHByZWNpYXRlIGNsZXZlciBiaXQgaGFja3MsIGJ1dCBpbiB0aGlzIGNh c2UsICBJIGRpc2FncmVlIHdpdGggdGhlIHdpc2RvbSBvZiBkb2luZyBzby4NCg0KSW4gZmVhciBv ZiBzb21lIG1pZGRsZWJveCB2ZW5kb3Igb3NzaWZ5aW5nIHRoZSBwcm90b2NvbCwgd2Ugc2hvdWxk IG5vdCBiZSB3b3JraW5nIGhhcmQgdG8gb3NzaWZ5IGl0IG91cnNlbHZlcyBieSByZW1vdmluZyBy ZXNlcnZlZCBiaXRzIGFuZCBtYWtpbmcgaXQgaW1wb3NzaWJsZSB0byBncm93IENJRCBsZW5ndGgg aW4gdGhlIGZ1dHVyZS4NCg0KSSBhbSBhIGJpdCBzdXJwcmlzZWQgYnkgdGhlIGFtb3VudCBvZiBj b25jZXJuIGFib3V0IGhhdmluZyB0byBkZWFsIHdpdGggQ0lEIG9mIHVwIHRvIDI1NSBieXRlcyBm b3IgdmVyc2lvbiBuZWdvdGlhdGlvbi4gIEhvdyBoYXJkIGlzIGl0IHRvOg0KDQoJbWVtY3B5KHZu X3BrdF9wdHIsIGNpX3BrdC0+c2NpZCwgY2lfcGt0LT5zY2lkX2xlbik7DQoJdm5fcGt0X3B0ciAr PSBjaV9wa3QtPnNjaWRfbGVuOw0KCW1lbWNweSh2bl9wa3RfcHRyLCBjaV9wa3QtPmRjaWQsIGNp X3BrdC0+ZGNpZF9sZW4pOw0KCXZuX3BrdF9wdHIgKz0gY2lfcGt0LT5kY2lkX2xlbjsNCg0KTXkg bG90IGlzIHdpdGggT3B0aW9uIDIuICBEbyBub3QgcmVxdWlyZSB2MSB0byBoYW5kbGUgaHVnZSBD SURzIGJ1dCBhbHNvIGRvIG5vdCBwYWludCB5b3Vyc2VsZiBpbnRvIGEgY29ybmVyIGluIEludmFy aWFudHMuDQoNCi0gSWdvcg0KDQo+IEZyb206IEthenVobyBPa3UgPGthenVob29rdUBnbWFpbC5j b20+DQo+IA0KPiAyMDE55bm0NuaciDIy5pelKOWcnykgOToyMCBNYXJ0ZW4gU2VlbWFubiA8bWFy dGVuc2VlbWFubkBnbWFpbC5jb20+Og0KPiA+DQo+ID4gT3NzaWZpY2F0aW9uIGlzIHByZXZlbnRl ZCBieSBhY3R1YWxseSB1c2luZyBhbGwgYXZhaWxhYmxlIGNvZGUgcG9pbnRzLiBXaXRoIHRoZQ0K PiBjb21wcmVzc2VkIDQgYml0IGVuY29kaW5nLCB0aGVyZSdzIGEgZ29vZCBjaGFuY2UgdGhhdCBh Y3R1YWxseSBhbGwgY29ubmVjdGlvbg0KPiBJRCBsZW5ndGhzIHdpbGwgYmUgdXNlZCBieSBhdCBs ZWFzdCBzb21lIFFVSUMgaW1wbGVtZW50YXRpb25zLCBzbyB0aGVyZSdzDQo+IG1pbmltYWwgcmlz ayBvZiBvc3NpZmljYXRpb24uIEhvd2V2ZXIsIHdpdGggb3B0aW9ucyAyLCB3ZSB1c2UgYSB3aG9s ZSBieXRlIHRvDQo+IGVuY29kZSBqdXN0IDIwIHZhbHVlcywgcmVzdWx0aW5nIGluIHRoZSBmaXJz dCAzIGJpdHMgYWx3YXlzIGJlaW5nIDAgKGluIHYxKSAtIGFuDQo+IGVhc3kgdGFyZ2V0IGZvciBv c3NpZmljYXRpb24uDQo+ID4NCj4gPiBUaGUgYmlnZ2VzdCBkb3duc2lkZSBvZiB0aGUgMSBieXRl IGNvbm5lY3Rpb24gSUQgbGVuZ3RoIGVuY29kaW5nIGlzIGhvdw0KPiB5b3UgaGFuZGxlIHVua25v d24gdmVyc2lvbnMuIFNpbmNlIGFuIGltcGxlbWVudGF0aW9uIG11c3QgYmUgYWJsZSB0bw0KPiBz ZW5kIFZlcnNpb24gTmVnb3RpYXRpb24gcGFja2V0cywgYW5kIGEgZnV0dXJlIFFVSUMgdmVyc2lv biBjb3VsZCBpbmNyZWFzZQ0KPiB0aGUgY29ubmVjdGlvbiBJRCBsZW5ndGggbGltaXQgdG8gMjU1 IGJ5dGVzLCBvcHRpb24gMiBhbmQgMyB3aWxsIHJlcXVpcmUgeW91IHRvDQo+IGhhdmUgZGF0YSB0 eXBlcyB0aGF0IGFsbG93IHBhcnNpbmcgb2YgcGFja2V0cyB3aXRoIGNvbm5lY3Rpb24gSURzIHRo YXQgYXJlIGENCj4gcXVhcnRlciBvZiBhIGtpbG9ieXRlIGxvbmcuIFlvdSB3b3VsZG4ndCB3YW50 IHRvIHVzZSBmaXhlZC1zaXplZCBidWZmZXJzIGZvcg0KPiB0aGF0LCBhbmQgbWF5YmUgZXZlbiBl bmQgdXAgd2l0aCBkaWZmZXJlbnQgY29ubmVjdGlvbiBJRCB0eXBlcyBmb3Igc2hvcnQNCj4gYW5k IGxvbmcgaGVhZGVyIHBhY2tldHMuDQo+ID4NCj4gPiBPcHRpb24gMiB0aGVyZWZvcmUgZ2l2ZXMg dXMgdGhlIHdvcnN0IG9mIGJvdGggd29ybGRzOiBXZSBnYWluIHZlcnkgbGl0dGxlIGluDQo+IGFj dHVhbGx5IGF2YWlsYWJsZSBjb25uZWN0aW9uIElEIHNwYWNlLCBidXQgYmVhciB0aGUgZnVsbCBj b3N0IG9mDQo+IGltcGxlbWVudGF0aW9uYWwgY29tcGxleGl0eSBmb3IgaGFuZGxpbmcgcGFja2V0 cyB3aXRoIDI1NSBieXRlIGNvbm5lY3Rpb24NCj4gSURzLg0KPiANCj4gV2hpbGUgSSBhbSBub3Qg Z2VuZXJhbGx5IG9wcG9zZWQgdG8gb3B0aW9uIDIgKEkgZG8gbm90IHRoaW5rIGl0IGlzDQo+ICp0 aGF0KiBiYWQgdG8gYXJndWUgYWdhaW5zdCByZWFjaGluZyBjb25zZW5zdXMpLCBJIGFncmVlIHRo YXQgaXMgYSBjb25jZXJuLg0KPiANCj4gQW5kIGFjdHVhbGx5LCBJIHRoaW5rIHRoZXJlIGlzIGEg YmVhdXRpZnVsIHdheSBvZiBlbmNvZGluZyBDSUQgbGVuZ3RoIGluIDUgYml0czoNCj4gY29tYmlu ZSB0aGUgZmlyc3Qgb2N0ZXQgYW5kIHRoZSBDSURMIG9jdGV0IHRoYXQgd2UgaGF2ZSBub3cgaW50 byBhIHVpbnQxNl90LA0KPiBhbmQgdXNlIDUgKiAyIGJpdHMgb2YgdGhhdCAxNi1iaXQgZmllbGQg dG8gcmVwcmVzZW50IHRoZSBDSUQgbGVuZ3Rocy4gQXMgYQ0KPiBjb2luY2lkZW5jZSwgd2UgaGF2 ZSB0d28gdW51c2VkIGJpdHMgaW4gdGhlIGxvbmcgaGVhZGVyIGZpZWxkcyBvZiBRVUlDIHYxDQo+ ICh3aXRoIHRoZSBleGNlcHRpb24gb2YgUmV0cnkgWzFdKS4gVGhpcyBjaGFuZ2Ugd291bGQgcmVt b3ZlIHRob3NlIHVudXNlZA0KPiBiaXRzIChhbmQgdGhlIG5lZWQgZm9yIGhhbmRsaW5nIHRoZW0g Y29ycmVjdGx5KS4gU28gaXQgc2ltcGxpZmllcyB2MS4NCj4gDQo+ICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN Cj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IHwxfDF8VCBUfFggWHwgRENJ REwoNSl8IFNDSURMKDUpfA0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8ICAgICAgICAgICAgICAgICAgICAgICAg IFZlcnNpb24gKDMyKSAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiB8 ICAgICAgICAgICAgICAgRGVzdGluYXRpb24gQ29ubmVjdGlvbiBJRCAoMC8zMi4uMjcyKSAgICAg ICAgIC4uLg0KPiArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiB8ICAgICAgICAgICAgICAgICBTb3VyY2UgQ29ubmVjdGlv biBJRCAoMC8zMi4uMjcyKSAgICAgICAgICAgIC4uLg0KPiArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiANCj4gWzFdIFJl dHJ5IHVzZXMgdGhlIGZvdXIgYml0cyBvZiB0aGUgZmlyc3Qgb2N0ZXQgdG8gY2FycnkgT0RDSURM LiBXZSB3b3VsZCBuZWVkDQo+IHRvIHVzZSBhIGRlZGljYXRlZCBvY3RldCBmb3IgY2Fycnlpbmcg T0RDSURMIGlmIHdlIGRlY2lkZSBtbyBtYWtlIENJREwNCj4gbG9uZ2VyIHRoYW4gNCBiaXRzLg0K PiANCj4gPg0KPiA+IE9uIFNhdCwgSnVuIDIyLCAyMDE5IGF0IDc6NTMgQU0gRGF2aWQgU2NoaW5h emkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4NCj4gd3JvdGU6DQo+ID4+DQo+ID4+IEnigJlt IHN0cm9uZ2x5IG9wcG9zZWQgdG8gb3B0aW9uIDQuIEl0IGd1YXJhbnRlZXMgb3NzaWZpY2F0aW9u IGJ5IG5vdA0KPiBhbGxvd2luZyBvdGhlciBsZW5ndGhzIGZyb20gdGhlIGdldCBnbyBzbyBpdOKA mXMgc3RyaWN0bHkgbGVzcyBmdXR1cmUtcHJvb2YgdGhhbg0KPiBvcHRpb24gMi4NCj4gPj4NCj4g Pj4gT24gRnJpLCBKdW4gMjEsIDIwMTkgYXQgMTY6NTEgTWFydGVuIFNlZW1hbm4NCj4gPG1hcnRl bnNlZW1hbm5AZ21haWwuY29tPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBUaGVyZeKAmXMgYWxzbyBh IDR0aCBvcHRpb246DQo+ID4+PiA0KSBLZWVwIHRoZSA0IGJpdCBjb21wcmVzc2VkIGVuY29kaW5n IGFuZCBpbmNyZWFzZSB0aGUgbWF4aW11bQ0KPiBsZW5ndGggdG8gMjAgYnl0ZXMuDQo+ID4+Pg0K PiA+Pj4gVGhpcyBjb3VsZCBiZSBkb25lIGJ5IGVsaW1pbmF0aW5nIGNvZGUgcG9pbnRzIGZvciAx NSBhbmQgMTcgYnl0ZQ0KPiBjb25uZWN0aW9uIElEcyAob3IgYW55IG90aGVyIDIgY29kZSBwb2lu dHMgdGhhdCBzZWVtIGxlc3MgdXNlZnVsKS4NCj4gPj4+IEnigJlkIHByZWZlciB0aGF0IG9wdGlv biBiZWNhdXNlIG9mIHRoZSBvc3NpZmljYXRpb24gcmlza3MgZGVzY3JpYmVkIGVhcmxpZXIuDQo+ ID4+Pg0KPiA+Pj4gT24gU2F0LCBKdW4gMjIsIDIwMTkgYXQgMDc6MTcgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbg0KPiA8bWlra2VsZmpAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+ IE1ha2VzIHNlbnNlIDIgbWUgMg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBPbiAyMSBKdW5lIDIw MTkgYXQgMjMuNDIuNDgsIENocmlzdGlhbiBIdWl0ZW1hIChodWl0ZW1hQGh1aXRlbWEubmV0KQ0K PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+IE1lIHRvby4gMi4NCj4gPj4+Pg0KPiA+Pj4+IC0tIENo cmlzdGlhbiBIdWl0ZW1hDQo+ID4+Pj4NCj4gPj4+PiBPbiBKdW4gMjEsIDIwMTksIGF0IDE6MjQg UE0sIEVyaWMgS2lubmVhcg0KPiA8ZWtpbm5lYXI9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc+ IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gKDIpIHdvdWxkIGJlIGZpbmUgZm9yIG1lIQ0KPiA+Pj4+ DQo+ID4+Pj4gVGhhbmtzLA0KPiA+Pj4+IEVyaWMNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24g SnVuIDIxLCAyMDE5LCBhdCAxOjIzIFBNLCBOaWNrIEJhbmtzDQo+IDxuaWJhbmtzPTQwbWljcm9z b2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiBXb3JrcyBmb3Ig bWUgYXMgd2VsbC4NCj4gPj4+Pg0KPiA+Pj4+IC0gTmljaw0KPiA+Pj4+DQo+ID4+Pj4gRnJvbTog UVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUm9iZXJ0byBQZW9uDQo+ ID4+Pj4gU2VudDogRnJpZGF5LCBKdW5lIDIxLCAyMDE5IDE6MjEgUE0NCj4gPj4+PiBUbzogRGF2 aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT47IElhbiBTd2V0dA0KPiA+Pj4+ IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuLmlldGYub3JnPg0KPiA+Pj4+IENjOiBJRVRG IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbg0KPiA+Pj4+IDxtdEBsb3dl bnRyb3B5Lm5ldD4NCj4gPj4+PiBTdWJqZWN0OiBSZTogQ29uc2Vuc3VzIENhbGw6IE1vcmUgQ29u bmVjdGlvbiBJRCBTcGFjZSAjMjczNg0KPiA+Pj4+DQo+ID4+Pj4gV29ya3MgZm9yIG1lLg0KPiA+ Pj4+IC09Ug0KPiA+Pj4+DQo+ID4+Pj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgRGF2aWQgU2NoaW5hemkNCj4gPj4+PiA8ZHNjaGluYXppLmlldGZAZ21h aWwuY29tPg0KPiA+Pj4+IERhdGU6IEZyaWRheSwgSnVuZSAyMSwgMjAxOSBhdCAxOjAyIFBNDQo+ ID4+Pj4gVG86IElhbiBTd2V0dCA8aWFuc3dldHQ9NDBnb29nbGUuY29tQGRtYXJjLi5pZXRmLm9y Zz4NCj4gPj4+PiBDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPiwgTWFydGluIFRob21z b24NCj4gPj4+PiA8bXRAbG93ZW50cm9weS5uZXQ+DQo+ID4+Pj4gU3ViamVjdDogUmU6IENvbnNl bnN1cyBDYWxsOiBNb3JlIENvbm5lY3Rpb24gSUQgU3BhY2UgIzI3MzYNCj4gPj4+Pg0KPiA+Pj4+ ICsxIHRvIHdoYXQgSWFuIHNhaWQuICgyKSBzZWVtcyBsaWtlIGEgZ29vZCBwYXRoIGZvcndhcmQN Cj4gPj4+Pg0KPiA+Pj4+IE9uIEZyaSwgSnVuIDIxLCAyMDE5IGF0IDE6MDAgUE0gSWFuIFN3ZXR0 DQo+IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+Pj4+ DQo+ID4+Pj4gSSB0aGluayB0aGUgMyBvcHRpb25zIEkgc2VlIGFzIHdlbGwgcmVhc29uZWQgYXJl Og0KPiA+Pj4+IDEpIEtlZXAgdGhlIHN0YXR1cyBxdW8gYmVjYXVzZSB3ZSB0aGluayB3ZSBjYW4g cHV0IHdoYXQgd2UgcmVhbGx5DQo+IG5lZWQgaW50byAxOCBieXRlcyBpZiB3ZSB0cnkuDQo+ID4+ Pj4gMikgQ2hhbmdlIHRvIGEgMSBieXRlIGxlbmd0aCBwZXIgQ0lEIGFuZCBhIG1heCBvZiAyMCwg d2hpY2ggZ2l2ZXMgdXMgYQ0KPiBmZXcgZXh0cmEgYnl0ZXMgZm9yIGNsZWFydGV4dCBzZXJ2ZXIg aWQgYW5kL29yIGtleSByb3RhdGlvbi9ldGMuDQo+ID4+Pj4gMykgQ2hhbmdlIHRvIGEgMSBieXRl IGxlbmd0aCBwZXIgQ0lEIGFuZCBhIG1heCBvZiAzNiwgYmVjYXVzZSB3ZSB3YW50DQo+IGJlIGFi bGUgdG8gcHV0IDIgZW5jcnlwdGVkIHJvdXRpbmcgSURzIGluIGEgc2luZ2xlIENJRC4NCj4gPj4+ Pg0KPiA+Pj4+IDIgaXMgbXkgcHJlZmVycmVkIG9wdGlvbiwgdGhvdWdoIEkgY2FuIGxpdmUgd2l0 aCBlaXRoZXIgb2YgMSBvciAzLg0KPiA+Pj4+DQo+ID4+Pj4gRGVjaWRpbmcgc29vbmVyIHdvdWxk IGJlIHN0cmljdGx5IGJldHRlciB0aGFuIGxhdGVyLCBzaW5jZSB0aGlzIGlzIGJsb2NraW5nDQo+ IHVzKENocm9tZS9Hb29nbGUpIGFjdHVhbGx5IHN1cHBvcnRpbmcgdmFybGVuIENJRHMuDQo+ID4+ Pj4NCj4gPj4+PiBPbiBUaHUsIEp1biAyMCwgMjAxOSBhdCAyOjU3IFBNIE1hcnRpbiBUaG9tc29u DQo+IDxtdEBsb3dlbnRyb3B5Lm5ldD4gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+PiBUaGF0IHNlZW1z IGEgbGl0dGxlIGhpZ2guICBJIHRoaW5rIHRoYXQgSWFuJ3MgcHJpbmNpcGxlIGhlcmUgaXMgd2hh dCBzaG91bGQNCj4gZ3VpZGUgdXM6IHdoYXQgaXMgdGhlIG1pbmltdW0geW91IGNhbiBoYW5kbGU/ ICBXaGF0IEkndmUgaGVhcmQgaXMgdGhhdCAxOA0KPiBtaWdodCBoYXZlIGJlZW4gd29ya2FibGUs IGJ1dCBpdCB3YXMgUkVBTExZIGNsb3NlIHRvIHRoZSBlZGdlIHRvIHRoZSBwb2ludA0KPiB0aGF0 IHlvdSB3ZXJlbid0IGNvbmZpZGVudCBpdCB3YXMgZW5vdWdoLCBldmVuIGluIHRoZSBuZWFyIHRl cm0uLiAgQnV0IHRoYXQNCj4gc3VnZ2VzdHMgdGhhdCAyMCBpcyB3b3JrYWJsZS4NCj4gPj4+Pg0K PiA+Pj4+IE9uIFdlZCwgSnVuIDE5LCAyMDE5LCBhdCAyMTo0MywgTWFydGluIER1a2Ugd3JvdGU6 DQo+ID4+Pj4gPiBzbyBkbyBJIGhlYXIgY29uc2Vuc3VzIGVtZXJnaW5nIGFyb3VuZCAzMkIgaW4g djEsIG9yIHNob3VsZCBJDQo+ID4+Pj4gPiBsZWF2ZSB0aGUgMThCIGxpbWl0IGluIHYxIGZvciBu b3cgYW5kIHB1bnQgb3V0IHRoYXQgZGlzY3Vzc2lvbj8NCj4gPj4+PiA+DQo+ID4+Pj4gPiBPbiBU dWUsIEp1biAxOCwgMjAxOSBhdCAxOjI0IEFNIFBoaWxpcHAgUy4gVGllc2VsIDxwaGlsaXBwQHRp ZXNlbC5uZXQ+DQo+IHdyb3RlOg0KPiA+Pj4+ID4gPg0KPiA+Pj4+ID4gPg0KPiA+Pj4+ID4gPiAg PiBPbiAxOC4gSnVuIDIwMTksIGF0IDA1OjMzLCBNYXJ0ZW4gU2VlbWFubg0KPiA8bWFydGVuc2Vl bWFubkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+Pj4+ID4gPiAgPg0KPiA+Pj4+ID4gPiAgPiBJJ2Qg cHJlZmVyIGtlZXBpbmcgdGhlICJjb21wcmVzc2VkIDQgYml0cyIgc29sdXRpb24sIGV2ZW4gaWYg d2UNCj4gZGVjaWRlIHRvIGluY3JlYXNlIHRoZSBjb25uZWN0aW9uIElEIGxlbmd0aCB0byBhIGxh cmdlciB2YWx1ZSAod2hpY2ggSSdtIHN0aWxsDQo+IG5vdCBjb252aW5jZWQgdGhhdCB0aGlzIGlz IHJlYWxseSBuZWNlc3NhcnkpLg0KPiA+Pj4+ID4gPg0KPiA+Pj4+ID4gPiAgVGhpcyB3b3VsZCBi ZSBlYXN5IGlmIHdlIGNoYW5nZSB0aGUgZW5jb2Rpbmcgb2YgdGhlIGNvbm5lY3Rpb24gSUQNCj4g bGVuZ3RoLCBlLi5nLi4sIHRvIGJlIERDSUwqNCBhbGxvd2luZyB1cCB0byA2MCBieXRlIGNvbm5l Y3Rpb24gSURzLiBXaGlsZSB3ZQ0KPiBjYW4gbm90IGVuY29kZSBvbmUgb3IgdHdvIGJ5dGUgY29u bmVjdGlvbiBJRHMgaW4gbG9uZyBoZWFkZXIgcGFja2V0cywgd2UNCj4gY2FuIHN0aWxsIHVzZSB0 aGVtIGluIHNob3J0IGhlYWRlciBwYWNrZXRzLg0KPiA+Pj4+ID4gPg0KPiA+Pj4+ID4gPiAgVGhp cyBzcGxpdCBiZXR3ZWVuIGxvbmcgYW5kIHNob3J0IGhlYWRlciBhbHNvIGFsbG93cyB0byB1c2Ug bXVjaA0KPiBsb25nZXIgY29ubmVjdGlvbiBJRHMgYWZ0ZXIgdGhlIGhhbmRzaGFrZS4NCj4gPj4+ PiA+ID4gIEkgZG9u4oCZdCBzZWUgbXVjaCB1c2UgaW4gaXQsIGJ1dCBpdCBtYXkgdGFrZSBvZmYg c29tZSBmZWFyIHRoYXQNCj4gMjQvMzIvMzYvNDgvNjAgYnl0ZSBjb25uZWN0aW9uIElEcyBtaWdo dCBub3QgYmUgbG9uZyBlbm91Z2ggaW4gdGhlIGZ1dHVyZS4NCj4gPj4+PiA+ID4NCj4gPj4+PiA+ ID4gID4NCj4gPj4+PiA+ID4gID4gVGhlcmUgYXJlIHR3byBtYWluIHJlYXNvbnMgdG8ga2VlcCB0 aGUgY29tcHJlc3NlZCBlbmNvZGluZzoNCj4gPj4+PiA+ID4gID4g4oCiIEluIHRoZSBjb21wcmVz c2VkIGVuY29kaW5nLCB3ZSBjYW4gcmVhc29uYWJseSBleHBlY3QgdGhhdCBhbGwNCj4gLyBtb3N0 IHZhbHVlcyB3aWxsIGJlIHVzZWQgaW4gcHJhY3RpY2UsIHNvIHdlIHdvbid0IGV4cG9zZSBhbnkg Yml0cyBvbiB0aGUNCj4gd2lyZSB0aGF0IGlkZW50aWZ5IGEgcGFja2V0IGFzICJRVUlDIHRyYWZm aWMiIGJ5IGhhdmluZyBhIHByZWRpY3RhYmxlIHZhbHVlLg0KPiA+Pj4+ID4gPiAgPiDigKIgVGhl IDEtYnl0ZSBlbmNvZGluZyBoYXMgdGhlIGRpc2FkdmFudGFnZSB0aGF0IGFuDQo+IGltcGxlbWVu dGF0aW9uIHN0aWxsIG5lZWRzIHRvIGJlIGFibGUgdG8gZGVhbCB3aXRoIGNvbm5lY3Rpb24gSUQg bGVuZ3RocyBvZg0KPiAyNTUgYnl0ZXMsIGp1c3QgdG8gYmUgYWJsZSB0byBzZW5kIFZlcnNpb24g TmVnb3RpYXRpb24gcGFja2V0cy4gVG8gbWUsIGl0DQo+IHNlZW1zIGFic3VyZCB0byB3cml0ZSBh IFFVSUMgaW1wbGVtZW50YXRpb24gdGhhdCBpcyBhYmxlIHRvIGhhbmRsZSBwYWNrZXRzDQo+IHdp dGggYSBjb21iaW5lZCBjb25uZWN0aW9uIElEIG92ZXJoZWFkIG9mIDUxMCBieXRlcy4gU2luY2Ug Vk5QcyBhcmUNCj4gc3VwcG9zZWQgdG8gYmUgc2VudCBpbiByZXNwb25zZSB0byBhbnkgTG9uZyBI ZWFkZXIgcGFja2V0LCB5b3UnZCBoYXZlIHRvDQo+IHB1dCBzb21lIGNhcmVmdWwgdGhvdWdodCBp bnRvIHRoZSBkZXNpZ24gb2YgeW91ciBkYXRhIHR5cGVzIHRvIGF2b2lkIHRoaXMNCj4gYmVjb21p bmcgYSBEb1MgdmVjdG9yLg0KPiA+Pj4+ID4gPiAgPg0KPiA+Pj4+ID4gPiAgPiBPbiBUdWUsIEp1 biAxOCwgMjAxOSBhdCAzOjUwIEFNIENocmlzdGlhbiBIdWl0ZW1hDQo+IDxodWl0ZW1hQGh1aXRl bWEubmV0PiB3cm90ZToNCj4gPj4+PiA+ID4gID4gSSB0b28gYWdyZWUgdGhhdCB1c2luZyBvbmUg Ynl0ZSBpbiB0aGUgaW52YXJpYW50IGlzIHByZWZlcmFibGUgdG8NCj4gdGhlIGN1cnJlbnQgImNv bXByZXNzZWQgNCBiaXRzIiBzb2x1dGlvbi4NCj4gPj4+PiA+ID4gID4NCj4gPj4+PiA+ID4gID4g UmVnYXJkaW5nIHRoZSAiQ0lEIGxlbmd0aCBsaW1pdCIsIEkgdGhpbmcgdGhlcmUgYXJlIHR3byBp c3N1ZXM6DQo+IHRyYW5zbWlzc2lvbiBvdmVyaGVhZCwgYW5kIGNvc3RzIHRvIHRoZSBjb21tdW5p dHkuDQo+ID4+Pj4gPiA+ICA+DQo+ID4+Pj4gPiA+ICA+IEkgYW0gbm90IHRvbyBjb25jZXJuZWQg d2l0aCB0aGUgdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBhcyB3ZQ0KPiBoYXZlIHRoZXJlIHRoZSBy aWdodCBtaXggb2YgY29zdHMgYW5kIGluY2VudGl2ZXMuIFNlcnZlcnMgd2hvIGNob3NlIHRvIHVz ZQ0KPiBsb25nZXIgQ0lEIHdpbGwgZ2V0IG1vcmUgdHJhbnNtaXNzaW9uIG92ZXJoZWFkLCBhbmQg dGh1cyB0cmFuc21pc3Npb24gbGVzcw0KPiBlZmZpY2llbnRseSB0aGFuIHRoZWlyIGNvbXBldGl0 b3JzLiBUaGV5IG1heSBjaG9zZSB0byB1c2UgbG9uZ2VyIENJRCBhcyBhDQo+IHRyYWRlLW9mZiBi ZXR3ZWVuIHRyYW5zbWlzc2lvbiBlZmZpY2llbmN5IGFuZCBlYXNlIG9mIG1hbmFnZW1lbnQuDQo+ IENvbXBldGl0aW9uIHdpbGwgc29ydCB0aGF0IG91dC4gSSBub3RlIHRoYXQgWW91VHViZSBpcyBh cHBhcmVudGx5IGRvaW5nIGZpbmUNCj4gd2l0aCBzbWFsbGlzaCBDSUQsIHNvIEkgdHJ1c3QgdGhh dCB0aGVyZSB3aWxsIGJlIGNvbXBldGl0aW9uLg0KPiA+Pj4+ID4gPiAgPg0KPiA+Pj4+ID4gPiAg PiBJIGFtIG11Y2ggbW9yZSBjb25jZXJuZWQgd2l0aCB0aGUgc2hhcmVkIGNvc3RzLCB3aGljaCBh cmUgYQ0KPiB2YXJpYXRpb24gb2YgdGhlICJ0cmFnZWR5IG9mIHRoZSBjb21tb25zIi4gRG1pdHJ5 IGV4cGxhaW5lZCB0aG9zZSBjb3N0cyB3ZWxsDQo+IGluIGEgcHJldmlvdXMgbWVzc2FnZS4gVGhl IHNpbXBsZXIgaW1wbGVtZW50YXRpb24gaXMgdG8gbWFrZSB0aGUgImNpZF90IGENCj4gZml4ZWQt c2l6ZSBvYmplY3QgdGhhdCBjYW4gZml0IHRoZSBsYXJnZXN0IENJRCBhbmQgZWF0IHRoZSBvdmVy aGVhZCBmb3IgYWxsDQo+IENJRHMuIiBCdXQgZWFjaCBjb25uZWN0aW9uIG9iamVjdCBjYXJyaWVz IGEgbGFyZ2UgbnVtYmVyIG9mIGluc3RhbmNlcyBvZiB0aGUNCj4gQ0lEIHR5cGUuIEhhdmluZyBh IHZlcnkgbGFyZ2UgbWF4IENJRCB3b3VsZCBpbXBseSBhIGxhcmdlIG92ZXJoZWFkLiBUaGUNCj4g YWx0ZXJuYXRpdmUgaXMgdG8gIk1ha2UgY2lkX3QgYSB2YXJpYWJsZS1zaXplIG9iamVjdCIsIGJ1 dCB0b28gYWZmZWN0cw0KPiBwZXJmb3JtYW5jZS4NCj4gPj4+PiA+ID4gID4NCj4gPj4+PiA+ID4g ID4gSGVuY2UgdGhlIHB1c2gtYmFjay4gSSB3b3VsZCBwZXJzb25hbGx5IHByZWZlciBhIG1heCBz aXplIG9mIDE2LA0KPiBhbmQgSSB0aGluayB0aGF0IDMyIGlzIHRoZSBoaWdoZXN0IHByYWN0aWNh bCBsaW1pdC4NCj4gPj4+PiA+ID4gID4NCj4gPj4+PiA+ID4gID4gLS0gQ2hyaXN0aWFuIEh1aXRl bWENCj4gPj4+PiA+ID4gID4NCj4gPj4+PiA+ID4gID4gT24gNi8xNy8yMDE5IDk6MTYgQU0sIFJv YmVydG8gUGVvbiB3cm90ZToNCj4gPj4+PiA+ID4gID4+IFdoYXQgSSB0aGluayBwZW9wbGUgYXJl IHNheWluZyBzbyBmYXI6DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4gMSkgUVVJQyB2 MSB3b3VsZCBsaW1pdCBDSUQgbGVuZ3RoIHRvIHNvbWV0aGluZyBvbmUgb2YgezMyLA0KPiA+Pj4+ ID4gPiAzNiwgb3IgNDh9ICA+PiAgPj4gMikgUmVwcmVzZW50YXRpb24gb2YgQ0lEIGxlbmd0aCBh cyBhIGJ5dGUgaXMNCj4gPj4+PiA+ID4gc3RpbGwgT0ssIHRodXMgYSBRVUlDIHYyIGNvdWxkIHVz ZSBsb25nZXIgQ0lEcyBhcyBuZWVkZWQgYnkgY2hhbmdpbmcNCj4gdGhlIHNwZWMgd2hpbGUga2Vl cGluZyB0aGUgaW52YXJpYW50c+KApiBpbnZhcmlhbnQuDQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+IFRoYXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSAvIEni gJlkIHN0aWxsIHN1cHBvcnQgdGhhdC4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiAt PVINCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4gRnJvbTog UVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIkx1YmFzaGV2LA0KPiA+ Pj4+ID4gPiBJZ29yIiA8aWx1YmFzaGVAYWthbWFpLmNvbT4gID4+IERhdGU6IE1vbmRheSwgSnVu ZSAxNywgMjAxOSBhdA0KPiA+Pj4+ID4gPiA4OjU1IEFNICA+PiBUbzogSWFuIFN3ZXR0DQo+ID4+ Pj4gPiA+IDxpYW5zd2V0dD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+LCBNaWtrZWwgRmFo bsO4ZQ0KPiBKw7hyZ2Vuc2VuDQo+ID4+Pj4gPiA+IDxtaWtrZWxmakBnbWFpbC5jb20+ICA+PiBD YzogRG1pdHJpIFRpa2hvbm92DQo+ID4+Pj4gPiA+IDxkdGlraG9ub3ZAbGl0ZXNwZWVkdGVjaC5j b20+LCBDaHJpc3RpYW4gSHVpdGVtYQ0KPiA+Pj4+ID4gPiA8aHVpdGVtYUBodWl0ZW1hLm5ldD4s ICJQaGlsaXBwIFMuIFRpZXNlbCINCj4gPj4+PiA+ID4gPHBoaWxpcHBAdGllc2VsLm5ldD4sIE1p a2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT4sDQo+ID4+Pj4gPiA+IE1hcnRpbiBUaG9t c29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4sIE1hcnRlbiBTZWVtYW5uDQo+IDxtYXJ0ZW5zZWVtYW5u QGdtYWlsLmNvbT4sIExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC4ub3JnPiwgUVVJQyBXRw0KPiA8 cXVpY0BpZXRmLm9yZz4sIE1hcnRpbiBEdWtlDQo+IDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxt YWlsdG86bWFydGluLi5oLmR1a2VAZ21haWwuY29tPj4sIEthenVobw0KPiBPa3UgPGthenVob29r dUBnbWFpbC5jb20+ICA+PiBTdWJqZWN0OiBSRTogQ29uc2Vuc3VzIENhbGw6IE1vcmUNCj4gQ29u bmVjdGlvbiBJRCBTcGFjZSAjMjczNiAgPj4gID4+ICA+PiAgPj4gTXkgdGFrZSBpcyBzaW1pbGFy IOKAkyA0OCBpcyBwcm9iYWJseQ0KPiBleGNlc3NpdmUsIHdoaWxlIDMyIGlzIGxpa2VseSB0aGUg dXBwZXIgbGltaXQgb2Yg4oCccmVhc29uYWJsZeKAnSAoaXQgc2hvdWxkDQo+IHByb2JhYmx5IGJl IGEgZmFjdG9yIG9mIDgsIHNvIDMyIG9yIDI0PykuDQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4g PiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBXZSBhcmUgZmlybWx5IGNvbW1p dHRlZCBmb3IgdXNpbmcgQ0lEIGZvciBpbi1jbHVzdGVyIGxvYWQNCj4gYmFsYW5jaW5nIC8gYW55 Y2FzdCBwb3Agcm91dGluZy4gVGhpcyBkaXNjdXNzaW9uIGlzIHRha2luZyB1cywgaG93ZXZlciwg dG8gYQ0KPiBuZXcgdGVycml0b3J5IOKAkyBhIGdlbmVyYWxpemVkIOKAnGRlc3RpbmF0aW9uLWNv bnRyb2xsZWQgcm91dGluZyBpbiBhbiBvdmVybGF5DQo+IG5ldHdvcmvigJ0uIFRoaXMgaXMgYSB2 ZXJ5IGludGVyZXN0aW5nIHRvcGljLCBidXQgSSB3b3VsZCBoZXNpdGF0ZSB0byBhdHRlbXB0IHRv DQo+IHNvbHZlIGl0IGZ1bGx5IGFuZCDigJxpbiBnZW5lcmFs4oCdIGluIFFVSUMgdjEuDQo+ID4+ Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+ PiDigKIgSWdvcg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+ PiBGcm9tOiBJYW4gU3dldHQgPGlhbnN3ZXR0PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4N Cj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBNeSBpbnR1aXRpb24gc2F5cyBtYWtpbmcg dGhlIGNoYW5nZSB0byB0aGUgaW52YXJpYW50cyBpcyB0aGUgcmlnaHQNCj4gdGhpbmcgdG8gZG8s IGJ1dCBJIGRvbid0IGZlZWwgdGhhdCBzdHJvbmdseS4uDQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBIb3dldmVyLCBJJ2QgbGlr ZSB0aGUgbWF4IHNpemUgdG8gYmUgc21hbGxlciB0aGFuIDQ4KGJ1dCBsYXJnZXINCj4gdGhhbiAx OCkuIElmIHdlIHRoaW5rIDIwIG9yIDI0IGlzIHN1ZmZpY2llbnQsIEknZCBwcmVmZXIgdGhhdC4g S2F6dWhvIHN1Z2dlc3RlZA0KPiAzMiwgd2hpY2ggaXMgYmV0dGVyLCBidXQgSSBkb24ndCBiZWxp ZXZlIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gdXNlIGEgc2VwYXJhdGUNCj4gYmxvY2sgY2lwaGVyIHdo ZW4gZ2l2aW5nIG91dCBjb25uZWN0aW9uIElEcywgYmVjYXVzZSBJIGJlbGlldmUgaXQncyBpbXBy YWN0aWNhbA0KPiBmb3IgdGhlIGxvYWQgYmFsYW5jZXIgYW5kIHNlcnZlciB0byBiZSB0aGF0IGRl Y291cGxlZC4gVGhlIHNlcnZlciBoYXMgdG8gZ2l2ZQ0KPiBvdXQgYSBDSUQgdGhhdCB0aGUgbG9h ZCBiYWxhbmNlciB3aWxsIHVzZSB0byByb3V0ZSBiYWNrIHRvIHRoZSBzZXJ2ZXIsIHNvIHRoZXkN Cj4gaGF2ZSB0byBzaGFyZSBlbm91Z2ggYW4gZW5jcnlwdGlvbiBrZXkvYWxnb3JpdGhtLiBJIGNh biBpbWFnaW5lIG5lc3RpbmcNCj4gbG9hZCBiYWxhbmNlcnMsIGJ1dCB0aGF0J3Mgd2VsbCBpbiB0 aGUgcmFuZ2Ugb2YgUVVJQyB2MiBmcm9tIG15IHBlcnNwZWN0aXZlLg0KPiA+Pj4+ID4gPiAgPj4N Cj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4gV2hhdGV2ZXIg d2UgZG8sIEknZCByZWFsbHkgcHJlZmVyIHRvIHJlc29sdmUgdGhpcyBzb29uZXIgcmF0aGVyDQo+ IHRoYW4gbGF0ZXIgYW5kIGJlIHRydWx5IGRvbmUgd2l0aCBpdC4NCj4gPj4+PiA+ID4gID4+DQo+ ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+IE9uIE1vbiwgSnVu IDE3LCAyMDE5IGF0IDI6NTEgQU0gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KPiA8bWlra2Vs ZmpAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBTaW5j ZSBpdCBpcyBtb3JlIGxpa2VseSB0aGF0IHlvdSBwYXkgZm9yIGVncmVzcyB0cmFmZmljIHRoYW4g aW5ncmVzcw0KPiB0cmFmZmljLCB0aGUgbW90aXZhdGlvbiB0byBrZWVwIENJROKAmXMgc21hbGwg aXMgbGltaXRlZC4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAg Pj4NCj4gPj4+PiA+ID4gID4+IEkgZG8gdGhpbmsgdGhlIGludmFyaWFudHMgc2hvdWxkIGFsbG93 IGZvciBsb25nIENJROKAmXMgYXMgcHJvcG9zZWQsDQo+IGFuZCB0aGF0IHRoZSBsb25nIGhlYWRl ciBvdmVyaGVhZCBpcyBub3QgaW1wb3J0YW50Li4uDQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4g PiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBCdXQgZm9yIFFVSUMgdjEsIGlm IHdlIGFsbG93IGZvciBhIGxvbmcgQ0lELCBhIHJ1c2ggdG8gbWFya2V0IHdpbGwNCj4gc2V0IHBy ZWNlZGVuY2UgYW5kIGxvbmcgQ0lE4oCZcyB3aWxsIG9zc2lmeSBpbiBhbGwga2luZHMgb2Ygc3Rh Y2tzLg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+ Pj4+ID4gPiAgPj4gSSBnb29kIHJlZmVyZW5jZSBvbiBhbiBhbGdvcml0aG0gbGlrZSBzdWdnZXN0 ZWQgYnkgQ2hyaXN0aWFuDQo+IHdvdWxkIGdvIGEgbG9uZyB3YXkuDQo+ID4+Pj4gPiA+ICA+Pg0K PiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBJZiBDSUQgbGVu Z3RoIDE4IHR1cm5zIG91dCB0byBiZSBub3QgZW5vdWdoLCB3ZSBjYW4gYWRkIGEgUVVJQw0KPiB2 Mi4gSXTigJlzIG5vdCBsaWtlIHdlIGFyZSBub3QgbG9va2luZyBmb3IgZXhjdXNlcyB0byB1cGdy YWRlIFFVSUMgdmVyc2lvbnMNCj4gc29vbi4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+ Pg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+IElmIENJRCBsZW5ndGggbmVnb3RpYXRp b24gaXMgbmVlZGVkLCB0aGlzIGNvdWxkIGJlIGRvbmUgdmlhIFFVSUMNCj4gdmVyc2lvbnMuIEZv ciBleGFtcGxlIHR3byBmdW5jdGlvbmFsbHkgZXF1aXZhbGVudCB2ZXJzaW9ucywgYnV0IG9uZSB3 aXRoDQo+IGxvbmdlciBDSUTigJlzLiBUaGlzIHdvdWxkIGFsc28gYWxsb3cgcm91dGVycyB0byBk ZWFsIHdpdGggY2hhbmdlcyBpbiBDSUQNCj4gbGVuZ3Rocy4gQSBuZWdvdGlhdGVkIFRQIHdvdWxk IG5vdCAoZWFzaWx5KSBhbGxvdyBmb3IgdGhhdCBhbmQgYXNpZGUgSSBkbyBub3QNCj4gdGhpbmsg Q0lEIGxlbmd0aCBpbiBUUCBpcyB0aGUgd2F5IHRvIGdvLg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+ PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4gTWlra2VsDQo+ID4+Pj4g PiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBP biAxNyBKdW5lIDIwMTkgYXQgMDYuNDUuMDQsIEthenVobyBPa3UNCj4gKGthenVob29rdUBnbWFp bC5jb20pIHdyb3RlOg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+IDIwMTnlubQ25pyI MTfml6Uo5pyIKSAxMTowOSBDaHJpc3RpYW4gSHVpdGVtYQ0KPiA8aHVpdGVtYUBodWl0ZW1hLm5l dD46DQo+ID4+Pj4gPiA+ICA+PiA+DQo+ID4+Pj4gPiA+ICA+PiA+IE9uIDYvMTUvMjAxOSAxMDo1 NSBQTSwgS2F6dWhvIE9rdSB3cm90ZToNCj4gPj4+PiA+ID4gID4+ID4NCj4gPj4+PiA+ID4gID4+ ID4gPiBfSWZfIHdlIGFyZSB0byBhbGxvdyBsb29zZSBjb3VwbGluZyBiZXR3ZWVuIGEgbG9hZA0K PiA+Pj4+ID4gPiBiYWxhbmNlciBhbmQgYSAgPj4gPiA+IHNlcnZlciwgZWFjaCBvZiB0aGUgdHdv IHNob3VsZCBiZSBnaXZlbg0KPiA+Pj4+ID4gPiB0aGUgZnJlZWRvbSB0byBjaG9vc2UgaXQncyBv d24gID4+ID4gPiBDSUQgZW5jcnlwdGlvbiBzY2hlbWUuDQo+ID4+Pj4gPiA+IEJlY2F1c2UgYWxs IHRoZSBzdGFuZGFyZGl6ZWQgYmxvY2sgY2lwaGVycyBhcmUgID4+ID4gPiBub3cNCj4gPj4+PiA+ ID4gMTI4LWJpdHMgKD0gMTYgYnl0ZXMpLCB0aGF0IG5hdHVyYWxseSBtZWFucyB0aGF0IHRoZSBt YXhpbXVtDQo+ID4+Pj4gPiA+IENJRCAgPj4gPiA+IGxlbmd0aCBvZiBRVUlDIG5lZWRzIHRvIGJl IGRvdWJsZSBhbW91bnQgb2YgdGhhdCwNCj4gPj4+PiA+ID4gcGx1cyBvbmUgb3IgdHdvICA+PiA+ ID4gYnl0ZXMgZm9yIGVhY2ggb2YgdGhlIHR3byBmb3INCj4gPj4+PiA+ID4gaWRlbnRpZnlpbmcg dGhlIENJRCBlbmNyeXB0aW9uIGtleXMuIEZvciAgPj4gPiA+IGtleSBpZGVudGlmaWNhdGlvbg0K PiBhbmQgb3RoZXIgc3VwcGxlbWVudGFsIHVzZSwgd2UgY3VycmVudGx5IGFsbG9jYXRlIDIgID4+ ID4gPiBieXRlcyAoMTgtMTY9MikuDQo+ID4+Pj4gPiA+ICA+PiA+DQo+ID4+Pj4gPiA+ICA+PiA+ IFRoYXQgcmVhc29uaW5nIGlzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYm90aCB0aGUN Cj4gPj4+PiA+ID4gbG9hZCBiYWxhbmNlciAgPj4gPiBhbmQgdGhlIHNlcnZlciBtdXN0IHVzZSBh IGJsb2NrIGNpcGhlciB3aXRoDQo+ID4+Pj4gPiA+IDEyOCBiaXQgYmxvY2sgbGVuZ3RoIGluICA+ PiA+IG9yZGVyIHRvIGVuY3J5cHQgdGhlIENJRC4gSWYgdGhleQ0KPiA+Pj4+ID4gPiB3ZXJlIGNv bnN0cmFpbmVkIHRvIHN0YXkgd2l0aGluIGEgID4+ID4gc2hvcnQgZ2xvYmFsIGxpbWl0LCB0aGV5 IGNvdWxkDQo+IHVzZSBkaWZmZXJlbnQgc2V0cyBvZiBhbGdvcml0aG1zLg0KPiA+Pj4+ID4gPiAg Pj4gPg0KPiA+Pj4+ID4gPiAgPj4gPiBBc3N1bWUgZm9yIGV4YW1wbGUgdGhhdCB3ZSBzcGxpdCB0 aGUgQ0lEIGJldHdlZW4gMzIgYml0cw0KPiA+Pj4+ID4gPiBlbmNvZGluZyB0aGUgID4+ID4gbnVt YmVyIG9mIHRoZSBzZXJ2ZXIgaW4gdGhlIHNlcnZlciBmYXJtLCBhbmQNCj4gPj4+PiA+ID4gNjQg Yml0IGVuY29kaW5nIHRoZSAgPj4gPiBjb25uZWN0aW9uIG51bWJlciBmb3IgdGhlIHNlcnZlci4g VGhlDQo+ID4+Pj4gPiA+IHNlcnZlciBjYW4gcGljayBhIHJhbmRvbSB2YWx1ZSBmb3IgID4+ID4g dGhlIGNvbm5lY3Rpb24gbnVtYmVyLA0KPiA+Pj4+ID4gPiBhbmQgdXNlIGEgaGFzaCB0YWJsZS4g VGhlIGxvYWQgYmFsYW5jZXIgY291bGQgdXNlICA+PiA+IGEgMzINCj4gPj4+PiA+ID4gYml0IHZh cmlhbnQgb2YgdGhlIEZGWCBhbGdvcml0aG0sIHVzaW5nIHRoZSBsb3dlciA2NCBiaXQgb2YgdGhl IENJRCAgPj4NCj4gPiBhcyBhbiBpbml0aWFsIHZlY3Rvci4gVm9pbGEsIDk2IENJRCwgd2l0aCBk ZW1vbnN0cmFibHkgc3Ryb25nIGVuY3J5cHRpb24uDQo+ID4+Pj4gPiA+ICA+PiA+DQo+ID4+Pj4g PiA+ICA+PiA+IE9yIGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXIgd2FudHMgdG8gdXNlIHNob3J0IENJ RC4gV2Ugbm93DQo+ID4+Pj4gPiA+IHNwbGl0IHRoZSBDSUQgID4+ID4gYmV0d2VlbiAzMiBiaXQg Zm9yIHRoZSBzZXJ2ZXIgbnVtYmVyIGluIHRoZQ0KPiA+Pj4+ID4gPiBmYXJtLCBhbmQgMzIgYml0 IGZvciB0aGUgID4+ID4gY29ubmVjdGlvbiBudW1iZXIgaW4gdGhlIHNlcnZlci4NCj4gPj4+PiA+ ID4gVGhlIHNlcnZlciBidWlsZHMgdGhhdCBjb25uZWN0aW9uICA+PiA+IG51bWJlciBieSB1c2lu ZyBhIDMyDQo+ID4+Pj4gPiA+IGJpdCB2YXJpYW50IG9mIEZGWC4gVGhlIGxvYWQgYmFsYW5jZXIg YWxzbyB1c2VzIGEgID4+ID4gMzIgYml0DQo+ID4+Pj4gPiA+IHZhcmlhbnQsIHVzaW5nIHRoZSBs b3dlciAzMiBiaXQgb2YgdGhlIENJRCBhcyBpbml0aWFsIHZlY3RvciBmb3IgID4+ID4NCj4gdGhp cyBGRlggZW5jcnlwdGlvbi4NCj4gPj4+PiA+ID4gID4+ID4NCj4gPj4+PiA+ID4gID4+ID4gVGhl c2UgYXJlIGp1c3QgdHdvIGV4YW1wbGVzLiBBbmQgeWVzIHlvdSBtYXkgd2FudCB0byBhZGQNCj4g Pj4+PiA+ID4gMiBieXRlcyBmb3Iga2V5ICA+PiA+IGlkZW50aWZpY2F0aW9uLCBldGMuIEluIGJv dGggZW5jcnlwdGlvbg0KPiA+Pj4+ID4gPiBhbGdvcml0aG1zLCB5b3UgY2FuIGZlZWQgdGhlc2Ug ID4+ID4gdHdvIGJ5dGVzIGFzIGFkZGl0aW9uYWwgSVYNCj4gPj4+PiA+ID4gZm9yIHRoZSBGRlgg YWxnb3JpdGhtLiBBbmQgaW4gYm90aCBjYXNlcywgd2UgID4+ID4gYXJlIHdlbGwgYmVsb3cNCj4g dGhlIDE4IGJ5dGUgbGltaXQuDQo+ID4+Pj4gPiA+ICA+PiA+DQo+ID4+Pj4gPiA+ICA+PiA+IFll cywgdGhhdCByZXF1aXJlcyBzb21lIGNyZWF0aXZlIGVuZ2luZWVyaW5nLiBCdXQgaXQgaXMNCj4g Pj4+PiA+ID4gbm90IHJvY2tlciAgPj4gPiBzY2llbmNlLiBBbmQgaXQgc2VlbXMgYmV0dGVyIHRo YW4gY2FycnlpbmcNCj4gPj4+PiA+ID4gdG9ucyBvZiBvdmVyaGVhZCBpbiB0aGUgID4+ID4gaGVh ZGVyLCBhbmQgYmVjb21pbmcgbGVzcyBlZmZpY2llbnQNCj4gdGhhbiBIVFRQMi9UTFMvVENQLg0K PiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+IEkgYWdyZWUgdGhhdCBpdCB3b3VsZCBub3Qg YmUgdGhlIGVuZCBvZiB0aGUgd29ybGQgZm9yIHRoZQ0KPiA+Pj4+ID4gPiBsb2FkICA+PiBiYWxh bmNlcnMgaWYgd2UgZGVjaWRlIHRvIHN0aWNrIG9uIHRoZSAxOC1ieXRlIGxpbWl0Lg0KPiA+Pj4+ ID4gPiBIb3dldmVyLCBhcyB5b3UgID4+IHN0YXRlLCBpdCByZXF1aXJlcyBzb21lIGNyZWF0aXZl bmVzcy4NCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+PiBUbyBtZSBpdCBzZWVtcyB0aGF0 IHRoZSBxdWVzdGlvbiBpcyBpZiB3ZSBoYXZlIGEgc3Ryb25nDQo+ID4+Pj4gPiA+IHJlYXNvbiB0 byAgPj4gcmVxdWlyZSBzb21lIHBlb3BsZSB0byBiZSBjcmVhdGl2ZSwgZm9yIGFsbCB0aGUNCj4g Pj4+PiA+ID4gdmVyc2lvbnMgb2YgUVVJQyBpbiAgPj4gdGhlIGZ1dHVyZS4gSSBwZXJzb25hbGx5 IHRoaW5rIHRoYXQNCj4gPj4+PiA+ID4gdGhlcmUgaXNuJ3QgYSBzdHJvbmcgcmVhc29uLCAgPj4g YmVjYXVzZSBwZW9wbGUgY2FuIHVzZSBzaG9ydGVyDQo+ID4+Pj4gPiA+IENJRHMgcmVnYXJkbGVz cyBvZiB0aGUgZGVjaXNpb24gd2UgID4+IG1ha2UuIElJVUMsIHRoZSBvdmVyaGVhZA0KPiB0aGF0 IGV2ZXJ5b25lIG5lZWRzIHRvIGFjY2VwdCBpczoNCj4gPj4+PiA+ID4gID4+DQo+ID4+Pj4gPiA+ ICA+PiAqIG9uZSBieXRlIGluY3JlYXNlIGluIHRoZSBsb25nIGhlYWRlciBwYWNrZXRzICA+PiAq IHRoZQ0KPiA+Pj4+ID4gPiBtaW5pbXVtIHNpemUgb2Ygc2hvcnQgaGVhZGVyIHBhY2tldHMgYmVj b21pbmcgc2xpZ2h0bHkgZ3JlYXRlcg0KPiA+Pj4+ID4gPiA+PiAob3RoZXJ3aXNlLCB0aGUgcGVl ciBtaWdodCBub3QgYmUgYWJsZSB0byBzZW5kIGEgc3RhdGVsZXNzDQo+ID4+Pj4gPiA+IHJlc2V0 KSAgPj4gID4+IEknZCBzYXkgdGhhdCB0aGUgZmlyc3QgYnVsbGV0IHBvaW50IGlzDQo+ID4+Pj4g PiA+IG5lZ2xpZ2libGUuIFRoZSBzZWNvbmQgcG9pbnQgID4+IGNvdWxkIGFsc28gYmUsIGJlY2F1 c2UgSSdkDQo+ID4+Pj4gPiA+IGFzc3VtZSB0aGF0IHRoZSBvbmx5IGZyZXF1ZW50bHktc2VudCAg Pj4gcGFja2V0cyB0aGF0IHJlcXVpcmUNCj4gPj4+PiA+ID4gYWRkaXRpb25hbCBwYWRkaW5nIGlz IHRoZSBBQ0stb25seSBwYWNrZXRzLCBidXQgID4+IHRoZXJlJ3Mgbm8NCj4gPj4+PiA+ID4gcmVh c29uIHRvIHBhZCBBQ0stb25seSBwYWNrZXRzIGluIGhvcGUgdGhhdCB5b3UnZCBzZWUgYSAgPj4N Cj4gPj4+PiA+ID4gc3RhdGVsZXNzIHJlc2V0Lg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4g ID4+IFRoZXJlZm9yZSwgbXkgKG5vdC1zby1zdHJvbmcpIHByZWZlcmVuY2UgaGFzIGJlZW4gdG8N Cj4gPj4+PiA+ID4gcHJvdmlkZSBleHRyYSAgPj4gcm9vbSwgc28gdGhhdCBzb21lIHBlb3BsZSB3 aXRoIG5lY2Vzc2l0eSBjYW4gdXNlDQo+IGxvbmdlciBDSURzLg0KPiA+Pj4+ID4gPiAgPj4NCj4g Pj4+PiA+ID4gID4+ID4NCj4gPj4+PiA+ID4gID4+ID4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4g Pj4+PiA+ID4gID4+ID4NCj4gPj4+PiA+ID4gID4+ID4NCj4gPj4+PiA+ID4gID4+ID4NCj4gPj4+ PiA+ID4gID4+DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4gPiAgPj4NCj4gPj4+PiA+ID4gID4+ IC0tDQo+ID4+Pj4gPiA+ICA+PiBLYXp1aG8gT2t1DQo+ID4+Pj4gPiA+ICA+Pg0KPiA+Pj4+ID4g Pg0KPiA+Pj4+ID4gPiAgQVZFIQ0KPiA+Pj4+ID4gPiAgUGhpbGlwcCBTLiBUaWVzZWwNCj4gPj4+ PiA+ID4NCj4gPj4+PiA+ID4gIC0tDQo+ID4+Pj4gPiA+ICBQaGlsaXBwIFMuIFRpZXNlbA0KPiA+ Pj4+ID4gPiBodHRwczovL3BoaWxpcHAudGllc2VsLm5ldC8NCj4gPj4+PiA+ID4NCj4gPj4+Pg0K PiA+Pj4+DQo+IA0KPiANCj4gLS0NCj4gS2F6dWhvIE9rdQ0KDQo= From nobody Fri Jun 21 21:40:36 2019 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 615041200FA for ; Fri, 21 Jun 2019 21:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 FCuHInh1-W7S for ; Fri, 21 Jun 2019 21:40:29 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 DD3B112014E for ; Fri, 21 Jun 2019 21:40:28 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id f9so8346816wre.12 for ; Fri, 21 Jun 2019 21:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d4wy8TpEFHYvUHkXPgsMIOlEOBwgyesnY+/C359KLTw=; b=WAlkrXDJ9Yo2hsn+YHT5fjjNsw8MS+e54xznxeCUbyG3dn6N096OwPlOvOtRSwmnxn ja79aFgi9t+rCmPnJiZIsgpPmn/TgwgI0/cxsLAHC60phXKjFl5VKUa2zIOZo+TuRH5y VfTWCXw3Q8L/erOGv/7nDu3EcgTVDjetlqLIxZz7kAMRlngg3TiFSH+t8iiBaaooVa05 p/yxtTDm0J2SR/dy8vTGP3mftZ4ACcZ7GTEEcIGG1SX5aoLL6Ls+CM0gG/C/491EhKXb wdwDN2/9cb3g0Dx5NhHCrBmjoZ71NFfOdmt7nNe+s+ebMJFxxB+sxejSqdB4zSUizMVC h04w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d4wy8TpEFHYvUHkXPgsMIOlEOBwgyesnY+/C359KLTw=; b=qrrQge0wlRLab1CtKp2l0uvnGKZ2lfvQaYJ67StbwG/HJtucBmFC7/wXU1zPBei9Lm YCIjR4TgFYb/Pqno2rwYvOwHznpYAJ8HRCWXx+1yyx7CFw36EvUAFR6fl6TZhtlqPOmC rTlU6cPGYqwRpof1DusAaNmxQIfojR7WISt2plSsW6QgGCiayJJJHxJ5oMuzbJtDzaCP fEuMYcXCrQ1cI8qPEZMR+YKtHjpF9FeymIzCYeGltO1lBw4ntvbwzT0FnGeV/YL7WQKC stBacn0lFh1I/+KfGgR1+VclYGGdhtZ0OUZszzes6bQU4D0Vm4ScuXNJLNt6S3md5btw efrg== X-Gm-Message-State: APjAAAVH/4HXdrq+ou8O1KCkOZKkSRMCaT1as33MmVu4Ds25KzsI3usH DBhrYT08jjPAFH1/oL6oqo/iq19hOJi5pA5F2R03xA== X-Google-Smtp-Source: APXvYqxgpXNLqd0xD61UNKo24PQiWisZEkI9ippc9KwGqrfKvfLcxtNfRmul+860avMFkLYCOFg7Bt5RjDYZJ7PnrW8= X-Received: by 2002:adf:eb89:: with SMTP id t9mr41589753wrn.120.1561178426692; Fri, 21 Jun 2019 21:40:26 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> <8b3282c37b8f42ee8f4aefb6a853a761@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <8b3282c37b8f42ee8f4aefb6a853a761@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Fri, 21 Jun 2019 21:40:13 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: "Lubashev, Igor" Cc: Kazuho Oku , Marten Seemann , Nick Banks , Roberto Peon , Eric Kinnear , Christian Huitema , Ian Swett , David Schinazi , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000008e3d35058be22d59" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 04:40:35 -0000 --0000000000008e3d35058be22d59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I prefer option 2. The wire format is obvious (unlike the current format) and 20 bytes seems like a fine limit. On Fri, Jun 21, 2019 at 7:01 PM Lubashev, Igor wrote: > I am first to appreciate clever bit hacks, but in this case, I disagree > with the wisdom of doing so. > > In fear of some middlebox vendor ossifying the protocol, we should not be > working hard to ossify it ourselves by removing reserved bits and making = it > impossible to grow CID length in the future. > > I am a bit surprised by the amount of concern about having to deal with > CID of up to 255 bytes for version negotiation. How hard is it to: > > memcpy(vn_pkt_ptr, ci_pkt->scid, ci_pkt->scid_len); > vn_pkt_ptr +=3D ci_pkt->scid_len; > memcpy(vn_pkt_ptr, ci_pkt->dcid, ci_pkt->dcid_len); > vn_pkt_ptr +=3D ci_pkt->dcid_len; > > My lot is with Option 2. Do not require v1 to handle huge CIDs but also > do not paint yourself into a corner in Invariants. > > - Igor > > > From: Kazuho Oku > > > > 2019=E5=B9=B46=E6=9C=8822=E6=97=A5(=E5=9C=9F) 9:20 Marten Seemann : > > > > > > Ossification is prevented by actually using all available code points= . > With the > > compressed 4 bit encoding, there's a good chance that actually all > connection > > ID lengths will be used by at least some QUIC implementations, so there= 's > > minimal risk of ossification. However, with options 2, we use a whole > byte to > > encode just 20 values, resulting in the first 3 bits always being 0 (in > v1) - an > > easy target for ossification. > > > > > > The biggest downside of the 1 byte connection ID length encoding is h= ow > > you handle unknown versions. Since an implementation must be able to > > send Version Negotiation packets, and a future QUIC version could > increase > > the connection ID length limit to 255 bytes, option 2 and 3 will requir= e > you to > > have data types that allow parsing of packets with connection IDs that > are a > > quarter of a kilobyte long. You wouldn't want to use fixed-sized buffer= s > for > > that, and maybe even end up with different connection ID types for shor= t > > and long header packets. > > > > > > Option 2 therefore gives us the worst of both worlds: We gain very > little in > > actually available connection ID space, but bear the full cost of > > implementational complexity for handling packets with 255 byte connecti= on > > IDs. > > > > While I am not generally opposed to option 2 (I do not think it is > > *that* bad to argue against reaching consensus), I agree that is a > concern. > > > > And actually, I think there is a beautiful way of encoding CID length i= n > 5 bits: > > combine the first octet and the CIDL octet that we have now into a > uint16_t, > > and use 5 * 2 bits of that 16-bit field to represent the CID lengths. A= s > a > > coincidence, we have two unused bits in the long header fields of QUIC = v1 > > (with the exception of Retry [1]). This change would remove those unuse= d > > bits (and the need for handling them correctly). So it simplifies v1. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1|1|T T|X X| DCIDL(5)| SCIDL(5)| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Version (32) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Destination Connection ID (0/32..272) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Source Connection ID (0/32..272) ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > [1] Retry uses the four bits of the first octet to carry ODCIDL. We > would need > > to use a dedicated octet for carrying ODCIDL if we decide mo make CIDL > > longer than 4 bits. > > > > > > > > On Sat, Jun 22, 2019 at 7:53 AM David Schinazi < > dschinazi.ietf@gmail.com> > > wrote: > > >> > > >> I=E2=80=99m strongly opposed to option 4. It guarantees ossification= by not > > allowing other lengths from the get go so it=E2=80=99s strictly less > future-proof than > > option 2. > > >> > > >> On Fri, Jun 21, 2019 at 16:51 Marten Seemann > > wrote: > > >>> > > >>> There=E2=80=99s also a 4th option: > > >>> 4) Keep the 4 bit compressed encoding and increase the maximum > > length to 20 bytes. > > >>> > > >>> This could be done by eliminating code points for 15 and 17 byte > > connection IDs (or any other 2 code points that seem less useful). > > >>> I=E2=80=99d prefer that option because of the ossification risks de= scribed > earlier. > > >>> > > >>> On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8rgensen > > wrote: > > >>>> > > >>>> Makes sense 2 me 2 > > >>>> > > >>>> > > >>>> On 21 June 2019 at 23.42.48, Christian Huitema (huitema@huitema.ne= t > ) > > wrote: > > >>>> > > >>>> Me too. 2. > > >>>> > > >>>> -- Christian Huitema > > >>>> > > >>>> On Jun 21, 2019, at 1:24 PM, Eric Kinnear > > wrote: > > >>>> > > >>>> (2) would be fine for me! > > >>>> > > >>>> Thanks, > > >>>> Eric > > >>>> > > >>>> > > >>>> On Jun 21, 2019, at 1:23 PM, Nick Banks > > wrote: > > >>>> > > >>>> Works for me as well. > > >>>> > > >>>> - Nick > > >>>> > > >>>> From: QUIC On Behalf Of Roberto Peon > > >>>> Sent: Friday, June 21, 2019 1:21 PM > > >>>> To: David Schinazi ; Ian Swett > > >>>> > > >>>> Cc: IETF QUIC WG ; Martin Thomson > > >>>> > > >>>> Subject: Re: Consensus Call: More Connection ID Space #2736 > > >>>> > > >>>> Works for me. > > >>>> -=3DR > > >>>> > > >>>> From: QUIC on behalf of David Schinazi > > >>>> > > >>>> Date: Friday, June 21, 2019 at 1:02 PM > > >>>> To: Ian Swett > > >>>> Cc: IETF QUIC WG , Martin Thomson > > >>>> > > >>>> Subject: Re: Consensus Call: More Connection ID Space #2736 > > >>>> > > >>>> +1 to what Ian said. (2) seems like a good path forward > > >>>> > > >>>> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett > > wrote: > > >>>> > > >>>> I think the 3 options I see as well reasoned are: > > >>>> 1) Keep the status quo because we think we can put what we really > > need into 18 bytes if we try. > > >>>> 2) Change to a 1 byte length per CID and a max of 20, which gives > us a > > few extra bytes for cleartext server id and/or key rotation/etc. > > >>>> 3) Change to a 1 byte length per CID and a max of 36, because we > want > > be able to put 2 encrypted routing IDs in a single CID. > > >>>> > > >>>> 2 is my preferred option, though I can live with either of 1 or 3. > > >>>> > > >>>> Deciding sooner would be strictly better than later, since this is > blocking > > us(Chrome/Google) actually supporting varlen CIDs. > > >>>> > > >>>> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson > > wrote: > > >>>> > > >>>> That seems a little high. I think that Ian's principle here is > what should > > guide us: what is the minimum you can handle? What I've heard is that = 18 > > might have been workable, but it was REALLY close to the edge to the > point > > that you weren't confident it was enough, even in the near term.. But > that > > suggests that 20 is workable. > > >>>> > > >>>> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > > >>>> > so do I hear consensus emerging around 32B in v1, or should I > > >>>> > leave the 18B limit in v1 for now and punt out that discussion? > > >>>> > > > >>>> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel < > philipp@tiesel.net> > > wrote: > > >>>> > > > > >>>> > > > > >>>> > > > On 18. Jun 2019, at 05:33, Marten Seemann > > wrote: > > >>>> > > > > > >>>> > > > I'd prefer keeping the "compressed 4 bits" solution, even i= f > we > > decide to increase the connection ID length to a larger value (which I'= m > still > > not convinced that this is really necessary). > > >>>> > > > > >>>> > > This would be easy if we change the encoding of the connectio= n > ID > > length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. > While we > > can not encode one or two byte connection IDs in long header packets, w= e > > can still use them in short header packets. > > >>>> > > > > >>>> > > This split between long and short header also allows to use > much > > longer connection IDs after the handshake. > > >>>> > > I don=E2=80=99t see much use in it, but it may take off some = fear that > > 24/32/36/48/60 byte connection IDs might not be long enough in the > future. > > >>>> > > > > >>>> > > > > > >>>> > > > There are two main reasons to keep the compressed encoding: > > >>>> > > > =E2=80=A2 In the compressed encoding, we can reasonably exp= ect that > all > > / most values will be used in practice, so we won't expose any bits on > the > > wire that identify a packet as "QUIC traffic" by having a predictable > value. > > >>>> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an > > implementation still needs to be able to deal with connection ID length= s > of > > 255 bytes, just to be able to send Version Negotiation packets. To me, = it > > seems absurd to write a QUIC implementation that is able to handle > packets > > with a combined connection ID overhead of 510 bytes. Since VNPs are > > supposed to be sent in response to any Long Header packet, you'd have t= o > > put some careful thought into the design of your data types to avoid th= is > > becoming a DoS vector. > > >>>> > > > > > >>>> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema > > wrote: > > >>>> > > > I too agree that using one byte in the invariant is > preferable to > > the current "compressed 4 bits" solution. > > >>>> > > > > > >>>> > > > Regarding the "CID length limit", I thing there are two > issues: > > transmission overhead, and costs to the community. > > >>>> > > > > > >>>> > > > I am not too concerned with the transmission overhead, as w= e > > have there the right mix of costs and incentives. Servers who chose to > use > > longer CID will get more transmission overhead, and thus transmission > less > > efficiently than their competitors. They may chose to use longer CID as= a > > trade-off between transmission efficiency and ease of management. > > Competition will sort that out. I note that YouTube is apparently doing > fine > > with smallish CID, so I trust that there will be competition. > > >>>> > > > > > >>>> > > > I am much more concerned with the shared costs, which are a > > variation of the "tragedy of the commons". Dmitry explained those costs > well > > in a previous message. The simpler implementation is to make the "cid_t= a > > fixed-size object that can fit the largest CID and eat the overhead for > all > > CIDs." But each connection object carries a large number of instances o= f > the > > CID type. Having a very large max CID would imply a large overhead. The > > alternative is to "Make cid_t a variable-size object", but too affects > > performance. > > >>>> > > > > > >>>> > > > Hence the push-back. I would personally prefer a max size o= f > 16, > > and I think that 32 is the highest practical limit. > > >>>> > > > > > >>>> > > > -- Christian Huitema > > >>>> > > > > > >>>> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > >>>> > > >> What I think people are saying so far: > > >>>> > > >> > > >>>> > > >> 1) QUIC v1 would limit CID length to something one of {32, > > >>>> > > 36, or 48} >> >> 2) Representation of CID length as a byte i= s > > >>>> > > still OK, thus a QUIC v2 could use longer CIDs as needed by > changing > > the spec while keeping the invariants=E2=80=A6 invariant. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> That seems reasonable to me / I=E2=80=99d still support th= at. > > >>>> > > >> > > >>>> > > >> -=3DR > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> From: QUIC on behalf of "Lubashev, > > >>>> > > Igor" >> Date: Monday, June 17, 2019 at > > >>>> > > 8:55 AM >> To: Ian Swett > > >>>> > > , Mikkel Fahn=C3=B8e > > J=C3=B8rgensen > > >>>> > > >> Cc: Dmitri Tikhonov > > >>>> > > , Christian Huitema > > >>>> > > , "Philipp S. Tiesel" > > >>>> > > , Mike Bishop , > > >>>> > > Martin Thomson , Marten Seemann > > , Lars Eggert , QUIC WG > > , Martin Duke > > >, Kazuho > > Oku >> Subject: RE: Consensus Call: More > > Connection ID Space #2736 >> >> >> >> My take is similar =E2=80=93 = 48 is > probably > > excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2= =80=9D (it should > > probably be a factor of 8, so 32 or 24?). > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> We are firmly committed for using CID for in-cluster load > > balancing / anycast pop routing. This discussion is taking us, however, > to a > > new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled r= outing in an > overlay > > network=E2=80=9D. This is a very interesting topic, but I would hesitat= e to > attempt to > > solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> =E2=80=A2 Igor > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> From: Ian Swett > > >>>> > > >> > > >>>> > > >> My intuition says making the change to the invariants is > the right > > thing to do, but I don't feel that strongly.. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> However, I'd like the max size to be smaller than 48(but > larger > > than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho > suggested > > 32, which is better, but I don't believe the server needs to use a > separate > > block cipher when giving out connection IDs, because I believe it's > impractical > > for the load balancer and server to be that decoupled. The server has t= o > give > > out a CID that the load balancer will use to route back to the server, > so they > > have to share enough an encryption key/algorithm. I can imagine nesting > > load balancers, but that's well in the range of QUIC v2 from my > perspective. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> Whatever we do, I'd really prefer to resolve this sooner > rather > > than later and be truly done with it. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8= rgensen > > wrote: > > >>>> > > >> > > >>>> > > >> Since it is more likely that you pay for egress traffic > than ingress > > traffic, the motivation to keep CID=E2=80=99s small is limited. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> I do think the invariants should allow for long CID=E2=80= =99s as > proposed, > > and that the long header overhead is not important... > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> But for QUIC v1, if we allow for a long CID, a rush to > market will > > set precedence and long CID=E2=80=99s will ossify in all kinds of stack= s. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> I good reference on an algorithm like suggested by Christi= an > > would go a long way. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> If CID length 18 turns out to be not enough, we can add a > QUIC > > v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUI= C versions > > soon. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> If CID length negotiation is needed, this could be done vi= a > QUIC > > versions. For example two functionally equivalent versions, but one wit= h > > longer CID=E2=80=99s. This would also allow routers to deal with change= s in CID > > lengths. A negotiated TP would not (easily) allow for that and aside I > do not > > think CID length in TP is the way to go. > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> Mikkel > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku > > (kazuhooku@gmail.com) wrote: > > >>>> > > >> > > >>>> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christ= ian Huitema > > : > > >>>> > > >> > > > >>>> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > >>>> > > >> > > > >>>> > > >> > > _If_ we are to allow loose coupling between a load > > >>>> > > balancer and a >> > > server, each of the two should be given > > >>>> > > the freedom to choose it's own >> > > CID encryption scheme. > > >>>> > > Because all the standardized block ciphers are >> > > now > > >>>> > > 128-bits (=3D 16 bytes), that naturally means that the maximum > > >>>> > > CID >> > > length of QUIC needs to be double amount of that, > > >>>> > > plus one or two >> > > bytes for each of the two for > > >>>> > > identifying the CID encryption keys. For >> > > key > identification > > and other supplemental use, we currently allocate 2 >> > > bytes > (18-16=3D2). > > >>>> > > >> > > > >>>> > > >> > That reasoning is based on the assumption that both the > > >>>> > > load balancer >> > and the server must use a block cipher wit= h > > >>>> > > 128 bit block length in >> > order to encrypt the CID. If the= y > > >>>> > > were constrained to stay within a >> > short global limit, > they could > > use different sets of algorithms. > > >>>> > > >> > > > >>>> > > >> > Assume for example that we split the CID between 32 bits > > >>>> > > encoding the >> > number of the server in the server farm, an= d > > >>>> > > 64 bit encoding the >> > connection number for the server. Th= e > > >>>> > > server can pick a random value for >> > the connection number= , > > >>>> > > and use a hash table. The load balancer could use >> > a 32 > > >>>> > > bit variant of the FFX algorithm, using the lower 64 bit of th= e > CID >> > > > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > > >>>> > > >> > > > >>>> > > >> > Or assume that the server wants to use short CID. We now > > >>>> > > split the CID >> > between 32 bit for the server number in th= e > > >>>> > > farm, and 32 bit for the >> > connection number in the server= . > > >>>> > > The server builds that connection >> > number by using a 32 > > >>>> > > bit variant of FFX. The load balancer also uses a >> > 32 bit > > >>>> > > variant, using the lower 32 bit of the CID as initial vector > for >> > > > this FFX encryption. > > >>>> > > >> > > > >>>> > > >> > These are just two examples. And yes you may want to add > > >>>> > > 2 bytes for key >> > identification, etc. In both encryption > > >>>> > > algorithms, you can feed these >> > two bytes as additional I= V > > >>>> > > for the FFX algorithm. And in both cases, we >> > are well > below > > the 18 byte limit. > > >>>> > > >> > > > >>>> > > >> > Yes, that requires some creative engineering. But it is > > >>>> > > not rocker >> > science. And it seems better than carrying > > >>>> > > tons of overhead in the >> > header, and becoming less > efficient > > than HTTP2/TLS/TCP. > > >>>> > > >> > > >>>> > > >> I agree that it would not be the end of the world for the > > >>>> > > load >> balancers if we decide to stick on the 18-byte limit. > > >>>> > > However, as you >> state, it requires some creativeness. > > >>>> > > >> > > >>>> > > >> To me it seems that the question is if we have a strong > > >>>> > > reason to >> require some people to be creative, for all the > > >>>> > > versions of QUIC in >> the future. I personally think that > > >>>> > > there isn't a strong reason, >> because people can use shorte= r > > >>>> > > CIDs regardless of the decision we >> make. IIUC, the overhea= d > > that everyone needs to accept is: > > >>>> > > >> > > >>>> > > >> * one byte increase in the long header packets >> * the > > >>>> > > minimum size of short header packets becoming slightly greater > > >>>> > > >> (otherwise, the peer might not be able to send a stateless > > >>>> > > reset) >> >> I'd say that the first bullet point is > > >>>> > > negligible. The second point >> could also be, because I'd > > >>>> > > assume that the only frequently-sent >> packets that require > > >>>> > > additional padding is the ACK-only packets, but >> there's no > > >>>> > > reason to pad ACK-only packets in hope that you'd see a >> > > >>>> > > stateless reset. > > >>>> > > >> > > >>>> > > >> Therefore, my (not-so-strong) preference has been to > > >>>> > > provide extra >> room, so that some people with necessity can > use > > longer CIDs. > > >>>> > > >> > > >>>> > > >> > > > >>>> > > >> > -- Christian Huitema > > >>>> > > >> > > > >>>> > > >> > > > >>>> > > >> > > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>> > > >> -- > > >>>> > > >> Kazuho Oku > > >>>> > > >> > > >>>> > > > > >>>> > > AVE! > > >>>> > > Philipp S. Tiesel > > >>>> > > > > >>>> > > -- > > >>>> > > Philipp S. Tiesel > > >>>> > > https://philipp.tiesel.net/ > > >>>> > > > > >>>> > > >>>> > > > > > > -- > > Kazuho Oku > > --0000000000008e3d35058be22d59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I prefer option 2. The wire format is obv= ious (unlike the current format) and 20 bytes seems like a fine limit.

On Fri, Jun 21, 2019 at 7:01 PM Lubashev, Igor <ilubashe@akamai.com> wrote:
I am first to appreciate clever bit hack= s, but in this case,=C2=A0 I disagree with the wisdom of doing so.

In fear of some middlebox vendor ossifying the protocol, we should not be w= orking hard to ossify it ourselves by removing reserved bits and making it = impossible to grow CID length in the future.

I am a bit surprised by the amount of concern about having to deal with CID= of up to 255 bytes for version negotiation.=C2=A0 How hard is it to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 memcpy(vn_pkt_ptr, ci_pkt->scid, ci_pkt->= scid_len);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vn_pkt_ptr +=3D ci_pkt->scid_len;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 memcpy(vn_pkt_ptr, ci_pkt->dcid, ci_pkt->= dcid_len);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vn_pkt_ptr +=3D ci_pkt->dcid_len;

My lot is with Option 2.=C2=A0 Do not require v1 to handle huge CIDs but al= so do not paint yourself into a corner in Invariants.

- Igor

> From: Kazuho Oku <kazuhooku@gmail.com>
>
> 2019=E5=B9=B46=E6=9C=8822=E6=97=A5(=E5=9C=9F) 9:20 Marten Seemann <= martenseemann@gmail.com>:
> >
> > Ossification is prevented by actually using all available code po= ints. With the
> compressed 4 bit encoding, there's a good chance that actually all= connection
> ID lengths will be used by at least some QUIC implementations, so ther= e's
> minimal risk of ossification. However, with options 2, we use a whole = byte to
> encode just 20 values, resulting in the first 3 bits always being 0 (i= n v1) - an
> easy target for ossification.
> >
> > The biggest downside of the 1 byte connection ID length encoding = is how
> you handle unknown versions. Since an implementation must be able to > send Version Negotiation packets, and a future QUIC version could incr= ease
> the connection ID length limit to 255 bytes, option 2 and 3 will requi= re you to
> have data types that allow parsing of packets with connection IDs that= are a
> quarter of a kilobyte long. You wouldn't want to use fixed-sized b= uffers for
> that, and maybe even end up with different connection ID types for sho= rt
> and long header packets.
> >
> > Option 2 therefore gives us the worst of both worlds: We gain ver= y little in
> actually available connection ID space, but bear the full cost of
> implementational complexity for handling packets with 255 byte connect= ion
> IDs.
>
> While I am not generally opposed to option 2 (I do not think it is
> *that* bad to argue against reaching consensus), I agree that is a con= cern.
>
> And actually, I think there is a beautiful way of encoding CID length = in 5 bits:
> combine the first octet and the CIDL octet that we have now into a uin= t16_t,
> and use 5 * 2 bits of that 16-bit field to represent the CID lengths. = As a
> coincidence, we have two unused bits in the long header fields of QUIC= v1
> (with the exception of Retry [1]). This change would remove those unus= ed
> bits (and the need for handling them correctly). So it simplifies v1.<= br> >
>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03<= br> >=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= br> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |1|1|T T|X X| DCIDL(5)| SCIDL(5)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |=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=A0Version (32)=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 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination Co= nnection ID (0/32..272)=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 =C2=A0Source = Connection ID (0/32..272)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> [1] Retry uses the four bits of the first octet to carry ODCIDL. We wo= uld need
> to use a dedicated octet for carrying ODCIDL if we decide mo make CIDL=
> longer than 4 bits.
>
> >
> > On Sat, Jun 22, 2019 at 7:53 AM David Schinazi <dschinazi.= ietf@gmail.com>
> wrote:
> >>
> >> I=E2=80=99m strongly opposed to option 4. It guarantees ossif= ication by not
> allowing other lengths from the get go so it=E2=80=99s strictly less f= uture-proof than
> option 2.
> >>
> >> On Fri, Jun 21, 2019 at 16:51 Marten Seemann
> <martenseemann@gmail.com> wrote:
> >>>
> >>> There=E2=80=99s also a 4th option:
> >>> 4) Keep the 4 bit compressed encoding and increase the ma= ximum
> length to 20 bytes.
> >>>
> >>> This could be done by eliminating code points for 15 and = 17 byte
> connection IDs (or any other 2 code points that seem less useful).
> >>> I=E2=80=99d prefer that option because of the ossificatio= n risks described earlier.
> >>>
> >>> On Sat, Jun 22, 2019 at 07:17 Mikkel Fahn=C3=B8e J=C3=B8r= gensen
> <mikkelfj@gmail.com> wrote:
> >>>>
> >>>> Makes sense 2 me 2
> >>>>
> >>>>
> >>>> On 21 June 2019 at 23.42.48, Christian Huitema (huitem= a@huitema.net)
> wrote:
> >>>>
> >>>> Me too. 2.
> >>>>
> >>>> -- Christian Huitema
> >>>>
> >>>> On Jun 21, 2019, at 1:24 PM, Eric Kinnear
> <ekinnear=3D40apple.com@dmarc.ietf.org> wrote:
> >>>>
> >>>> (2) would be fine for me!
> >>>>
> >>>> Thanks,
> >>>> Eric
> >>>>
> >>>>
> >>>> On Jun 21, 2019, at 1:23 PM, Nick Banks
> <nibanks=3D40microsoft.com@dmarc.ietf.org> wrote:<= br> > >>>>
> >>>> Works for me as well.
> >>>>
> >>>> - Nick
> >>>>
> >>>> From: QUIC <quic-bounces@ietf.org> On Beha= lf Of Roberto Peon
> >>>> Sent: Friday, June 21, 2019 1:21 PM
> >>>> To: David Schinazi <dschinazi.ietf@gmail.com>; Ian Swett
> >>>> <ianswett=3D40google.com@dmarc..ietf.org>
> >>>> Cc: IETF QUIC WG <quic@ietf.org>; Martin Thomson > >>>> <mt@lowentropy.net>
> >>>> Subject: Re: Consensus Call: More Connection ID Space= #2736
> >>>>
> >>>> Works for me.
> >>>> -=3DR
> >>>>
> >>>> From: QUIC <quic-bounces@ietf.org> on beha= lf of David Schinazi
> >>>> <dschinazi.ietf@gmail.com>
> >>>> Date: Friday, June 21, 2019 at 1:02 PM
> >>>> To: Ian Swett <ianswett=3D40google.com@dmarc..ietf.org>
> >>>> Cc: IETF QUIC WG <quic@ietf.org>, Martin Thomson > >>>> <mt@lowentropy.net>
> >>>> Subject: Re: Consensus Call: More Connection ID Space= #2736
> >>>>
> >>>> +1 to what Ian said. (2) seems like a good path forwa= rd
> >>>>
> >>>> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett
> <ianswett=3D40google.com@dmarc.ietf.org> wrote:
> >>>>
> >>>> I think the 3 options I see as well reasoned are:
> >>>> 1) Keep the status quo because we think we can put wh= at we really
> need into 18 bytes if we try.
> >>>> 2) Change to a 1 byte length per CID and a max of 20,= which gives us a
> few extra bytes for cleartext server id and/or key rotation/etc.
> >>>> 3) Change to a 1 byte length per CID and a max of 36,= because we want
> be able to put 2 encrypted routing IDs in a single CID.
> >>>>
> >>>> 2 is my preferred option, though I can live with eith= er of 1 or 3.
> >>>>
> >>>> Deciding sooner would be strictly better than later, = since this is blocking
> us(Chrome/Google) actually supporting varlen CIDs.
> >>>>
> >>>> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson
> <mt@lowentropy.net> wrote:
> >>>>
> >>>> That seems a little high.=C2=A0 I think that Ian'= s principle here is what should
> guide us: what is the minimum you can handle?=C2=A0 What I've hear= d is that 18
> might have been workable, but it was REALLY close to the edge to the p= oint
> that you weren't confident it was enough, even in the near term..= =C2=A0 But that
> suggests that 20 is workable.
> >>>>
> >>>> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > >>>> > so do I hear consensus emerging around 32B in v1= , or should I
> >>>> > leave the 18B limit in v1 for now and punt out t= hat discussion?
> >>>> >
> >>>> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiese= l <philipp@tiesel.net>
> wrote:
> >>>> > >
> >>>> > >
> >>>> > >=C2=A0 > On 18. Jun 2019, at 05:33, Marte= n Seemann
> <martenseemann@gmail.com> wrote:
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > I'd prefer keeping the "= ;compressed 4 bits" solution, even if we
> decide to increase the connection ID length to a larger value (which I= 'm still
> not convinced that this is really necessary).
> >>>> > >
> >>>> > >=C2=A0 This would be easy if we change the e= ncoding of the connection ID
> length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. Wh= ile we
> can not encode one or two byte connection IDs in long header packets, = we
> can still use them in short header packets.
> >>>> > >
> >>>> > >=C2=A0 This split between long and short hea= der also allows to use much
> longer connection IDs after the handshake.
> >>>> > >=C2=A0 I don=E2=80=99t see much use in it, b= ut it may take off some fear that
> 24/32/36/48/60 byte connection IDs might not be long enough in the fut= ure.
> >>>> > >
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > There are two main reasons to ke= ep the compressed encoding:
> >>>> > >=C2=A0 > =E2=80=A2 In the compressed enco= ding, we can reasonably expect that all
> / most values will be used in practice, so we won't expose any bit= s on the
> wire that identify a packet as "QUIC traffic" by having a pr= edictable value.
> >>>> > >=C2=A0 > =E2=80=A2 The 1-byte encoding ha= s the disadvantage that an
> implementation still needs to be able to deal with connection ID lengt= hs of
> 255 bytes, just to be able to send Version Negotiation packets. To me,= it
> seems absurd to write a QUIC implementation that is able to handle pac= kets
> with a combined connection ID overhead of 510 bytes. Since VNPs are > supposed to be sent in response to any Long Header packet, you'd h= ave to
> put some careful thought into the design of your data types to avoid t= his
> becoming a DoS vector.
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM = Christian Huitema
> <huitema@huitema.net> wrote:
> >>>> > >=C2=A0 > I too agree that using one byte = in the invariant is preferable to
> the current "compressed 4 bits" solution.
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > Regarding the "CID length l= imit", I thing there are two issues:
> transmission overhead, and costs to the community.
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > I am not too concerned with the = transmission overhead, as we
> have there the right mix of costs and incentives. Servers who chose to= use
> longer CID will get more transmission overhead, and thus transmission = less
> efficiently than their competitors. They may chose to use longer CID a= s a
> trade-off between transmission efficiency and ease of management.
> Competition will sort that out. I note that YouTube is apparently doin= g fine
> with smallish CID, so I trust that there will be competition.
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > I am much more concerned with th= e shared costs, which are a
> variation of the "tragedy of the commons". Dmitry explained = those costs well
> in a previous message. The simpler implementation is to make the "= ;cid_t a
> fixed-size object that can fit the largest CID and eat the overhead fo= r all
> CIDs." But each connection object carries a large number of insta= nces of the
> CID type. Having a very large max CID would imply a large overhead. Th= e
> alternative is to "Make cid_t a variable-size object", but t= oo affects
> performance.
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > Hence the push-back. I would per= sonally prefer a max size of 16,
> and I think that 32 is the highest practical limit.
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > -- Christian Huitema
> >>>> > >=C2=A0 >
> >>>> > >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Pe= on wrote:
> >>>> > >=C2=A0 >> What I think people are sayi= ng so far:
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> 1) QUIC v1 would limit CID l= ength to something one of {32,
> >>>> > > 36, or 48}=C2=A0 >>=C2=A0 >> 2)= Representation of CID length as a byte is
> >>>> > > still OK, thus a QUIC v2 could use longer C= IDs as needed by changing
> the spec while keeping the invariants=E2=80=A6 invariant.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> That seems reasonable to me = / I=E2=80=99d still support that.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> -=3DR
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> From: QUIC <quic-bounces= @ietf.org> on behalf of "Lubashev,
> >>>> > > Igor" <ilubashe@akamai.com>= =C2=A0 >> Date: Monday, June 17, 2019 at
> >>>> > > 8:55 AM=C2=A0 >> To: Ian Swett
> >>>> > > <ianswett=3D40google.com@dmarc.ie= tf.org>, Mikkel Fahn=C3=B8e
> J=C3=B8rgensen
> >>>> > > <mikkelfj@gmail.com>=C2=A0 >>= Cc: Dmitri Tikhonov
> >>>> > > <dtikhonov@litespeedtech.com&= gt;, Christian Huitema
> >>>> > > <huitema@huitema.net>, "Phili= pp S. Tiesel"
> >>>> > > <philipp@tiesel.net>, Mike Bishop &= lt;mbishop@evequefou.be>,
> >>>> > > Martin Thomson <mt@lowentropy.net>, = Marten Seemann
> <martenseemann@gmail.com>, Lars Eggert <lars@eggert..o= rg>, QUIC WG
> <quic@ietf.org>, Martin Duke
> <martin.h.duke@gmail.com<mailto:martin..h.duke@gmail.= com>>, Kazuho
> Oku <kazuhooku@gmail.com>=C2=A0 >> Subject: RE: Consens= us Call: More
> Connection ID Space #2736=C2=A0 >>=C2=A0 >>=C2=A0 >>= =C2=A0 >> My take is similar =E2=80=93 48 is probably
> excessive, while 32 is likely the upper limit of =E2=80=9Creasonable= =E2=80=9D (it should
> probably be a factor of 8, so 32 or 24?).
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> We are firmly committed for = using CID for in-cluster load
> balancing / anycast pop routing. This discussion is taking us, however= , to a
> new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled = routing in an overlay
> network=E2=80=9D. This is a very interesting topic, but I would hesita= te to attempt to
> solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> =E2=80=A2 Igor
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> From: Ian Swett <ianswett= =3D40google.com@dmarc.ietf.org>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> My intuition says making the= change to the invariants is the right
> thing to do, but I don't feel that strongly..
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> However, I'd like the ma= x size to be smaller than 48(but larger
> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kaz= uho suggested
> 32, which is better, but I don't believe the server needs to use a= separate
> block cipher when giving out connection IDs, because I believe it'= s impractical
> for the load balancer and server to be that decoupled. The server has = to give
> out a CID that the load balancer will use to route back to the server,= so they
> have to share enough an encryption key/algorithm. I can imagine nestin= g
> load balancers, but that's well in the range of QUIC v2 from my pe= rspective.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> Whatever we do, I'd real= ly prefer to resolve this sooner rather
> than later and be truly done with it.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51= AM Mikkel Fahn=C3=B8e J=C3=B8rgensen
> <mikkelfj@gmail.com> wrote:
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> Since it is more likely that= you pay for egress traffic than ingress
> traffic, the motivation to keep CID=E2=80=99s small is limited.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> I do think the invariants sh= ould allow for long CID=E2=80=99s as proposed,
> and that the long header overhead is not important...
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> But for QUIC v1, if we allow= for a long CID, a rush to market will
> set precedence and long CID=E2=80=99s will ossify in all kinds of stac= ks.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> I good reference on an algor= ithm like suggested by Christian
> would go a long way.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> If CID length 18 turns out t= o be not enough, we can add a QUIC
> v2. It=E2=80=99s not like we are not looking for excuses to upgrade QU= IC versions
> soon.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> If CID length negotiation is= needed, this could be done via QUIC
> versions. For example two functionally equivalent versions, but one wi= th
> longer CID=E2=80=99s. This would also allow routers to deal with chang= es in CID
> lengths. A negotiated TP would not (easily) allow for that and aside I= do not
> think CID length in TP is the way to go.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> Mikkel
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> On 17 June 2019 at 06.45.04,= Kazuho Oku
> (kazuhooku@gmail.com) wrote:
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> 2019=E5=B9=B46=E6=9C=8817=E6= =97=A5(=E6=9C=88) 11:09 Christian Huitema
> <huitema@huitema.net>:
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > On 6/15/2019 10:55 PM, = Kazuho Oku wrote:
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > > _If_ we are to all= ow loose coupling between a load
> >>>> > > balancer and a=C2=A0 >> > > ser= ver, each of the two should be given
> >>>> > > the freedom to choose it's own=C2=A0 &g= t;> > > CID encryption scheme.
> >>>> > > Because all the standardized block ciphers = are=C2=A0 >> > > now
> >>>> > > 128-bits (=3D 16 bytes), that naturally mea= ns that the maximum
> >>>> > > CID=C2=A0 >> > > length of QUIC= needs to be double amount of that,
> >>>> > > plus one or two=C2=A0 >> > > by= tes for each of the two for
> >>>> > > identifying the CID encryption keys. For=C2= =A0 >> > > key identification
> and other supplemental use, we currently allocate 2=C2=A0 >> >= ; > bytes (18-16=3D2).
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > That reasoning is based= on the assumption that both the
> >>>> > > load balancer=C2=A0 >> > and the s= erver must use a block cipher with
> >>>> > > 128 bit block length in=C2=A0 >> >= order to encrypt the CID. If they
> >>>> > > were constrained to stay within a=C2=A0 >= ;> > short global limit, they could
> use different sets of algorithms.
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > Assume for example that= we split the CID between 32 bits
> >>>> > > encoding the=C2=A0 >> > number of = the server in the server farm, and
> >>>> > > 64 bit encoding the=C2=A0 >> > con= nection number for the server. The
> >>>> > > server can pick a random value for=C2=A0 &g= t;> > the connection number,
> >>>> > > and use a hash table. The load balancer cou= ld use=C2=A0 >> > a 32
> >>>> > > bit variant of the FFX algorithm, using the= lower 64 bit of the CID=C2=A0 >>
> > as an initial vector. Voila, 96 CID, with demonstrably strong enc= ryption.
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > Or assume that the serv= er wants to use short CID. We now
> >>>> > > split the CID=C2=A0 >> > between 3= 2 bit for the server number in the
> >>>> > > farm, and 32 bit for the=C2=A0 >> >= ; connection number in the server.
> >>>> > > The server builds that connection=C2=A0 >= ;> > number by using a 32
> >>>> > > bit variant of FFX. The load balancer also = uses a=C2=A0 >> > 32 bit
> >>>> > > variant, using the lower 32 bit of the CID = as initial vector for=C2=A0 >> >
> this FFX encryption.
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > These are just two exam= ples. And yes you may want to add
> >>>> > > 2 bytes for key=C2=A0 >> > identif= ication, etc. In both encryption
> >>>> > > algorithms, you can feed these=C2=A0 >&g= t; > two bytes as additional IV
> >>>> > > for the FFX algorithm. And in both cases, w= e=C2=A0 >> > are well below
> the 18 byte limit.
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > Yes, that requires some= creative engineering. But it is
> >>>> > > not rocker=C2=A0 >> > science. And= it seems better than carrying
> >>>> > > tons of overhead in the=C2=A0 >> >= header, and becoming less efficient
> than HTTP2/TLS/TCP.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> I agree that it would not be= the end of the world for the
> >>>> > > load=C2=A0 >> balancers if we decide = to stick on the 18-byte limit.
> >>>> > > However, as you=C2=A0 >> state, it re= quires some creativeness.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> To me it seems that the ques= tion is if we have a strong
> >>>> > > reason to=C2=A0 >> require some peopl= e to be creative, for all the
> >>>> > > versions of QUIC in=C2=A0 >> the futu= re. I personally think that
> >>>> > > there isn't a strong reason,=C2=A0 >= > because people can use shorter
> >>>> > > CIDs regardless of the decision we=C2=A0 &g= t;> make. IIUC, the overhead
> that everyone needs to accept is:
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> * one byte increase in the l= ong header packets=C2=A0 >> * the
> >>>> > > minimum size of short header packets becomi= ng slightly greater
> >>>> > > >> (otherwise, the peer might not be = able to send a stateless
> >>>> > > reset)=C2=A0 >>=C2=A0 >> I'= d say that the first bullet point is
> >>>> > > negligible. The second point=C2=A0 >>= could also be, because I'd
> >>>> > > assume that the only frequently-sent=C2=A0 = >> packets that require
> >>>> > > additional padding is the ACK-only packets,= but=C2=A0 >> there's no
> >>>> > > reason to pad ACK-only packets in hope that= you'd see a=C2=A0 >>
> >>>> > > stateless reset.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> Therefore, my (not-so-strong= ) preference has been to
> >>>> > > provide extra=C2=A0 >> room, so that = some people with necessity can use
> longer CIDs.
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> > -- Christian Huitema > >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >> >
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >>
> >>>> > >=C2=A0 >> --
> >>>> > >=C2=A0 >> Kazuho Oku
> >>>> > >=C2=A0 >>
> >>>> > >
> >>>> > >=C2=A0 AVE!
> >>>> > >=C2=A0 Philipp S. Tiesel
> >>>> > >
> >>>> > >=C2=A0 --
> >>>> > >=C2=A0 Philipp S. Tiesel
> >>>> > > https://philipp.tiesel.n= et/
> >>>> > >
> >>>>
> >>>>
>
>
> --
> Kazuho Oku

--0000000000008e3d35058be22d59-- From nobody Fri Jun 21 22:17:47 2019 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 4C2F6120291 for ; Fri, 21 Jun 2019 22:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1EAIF-suXB3 for ; Fri, 21 Jun 2019 22:17:41 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEFD12011F for ; Fri, 21 Jun 2019 22:17:41 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp01.mail2web.com) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1heYPB-0004z3-RE for quic@ietf.org; Sat, 22 Jun 2019 07:17:39 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1heYP8-0008PG-LU for quic@ietf.org; Sat, 22 Jun 2019 01:17:35 -0400 Received: (qmail 17834 invoked from network); 22 Jun 2019 05:17:32 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Jun 2019 05:17:31 -0000 To: Marten Seemann , David Schinazi Cc: Eric Kinnear , IETF QUIC WG , Ian Swett , Martin Thomson , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Nick Banks , Roberto Peon References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <2082A066-CBA1-44A5-90DC-0E41C468EE15@apple.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <84d15ecf-42db-004a-14a8-b8cd186b2978@huitema.net> Date: Fri, 21 Jun 2019 22:17:28 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: Consensus Call: More Connection ID Space #2736 X-Originating-IP: 66.113.192.14 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.14 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.14@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ud2CCyxmm2KHETL0VYw/ASpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fs0VWlHCOSfpzAXnoM3HU2E/sevPPdLVvjz7b14RFNIS30ONArWHUY/dwk7 0VyeflhTPSw+CekCTYoDa8nAx3W503+K7Ju/qxRhvHDAT5LyR61Qv/sjUDXLdm6w1gNv1euKTrwh UfUHUrPvTkTGu7YwVDQ0hbqcLWUbjgHMZS6COdI/uLAeALf3vLWnw0F/4+fmuTv/CYIzmchrGsA6 CN6O7qbWTdT56xh4Rya20+oBtwahqtg42IMQXC/e/thfmehs05Web8nJyEMtLxwhnYinDFrKlNc7 qNKmpnIY9d8cOJUa+B0z/Xg2ESGxDSOWWoTyIUtK8Miz//+1AD61I8sOcFFSGcngeU5u06zO01Ld 6NjlDHh8k6TTdHl8m1/8O//LcKgaYLn9Y2q9E0HrGD+jCxD87nTuKNDHZcdemthLkqDpZM3xHzQl xdue7fUC9q6I7x5eMlDa6HcejzNFj/qM21OrTi18zY+Jvxw0Ht9dWolkqscAyrkBm40BZdkty3fL EDK8hX5Mjj3K6v45KP9rHGWcfOjtTSOQwERm6qbTgncW4cIAGcb2cNTwDakbhAiw/i9M01ZUff8x GCyJrXM9vVXBn6gl9okFYHXguUlWSM1qtGkdnCeOYd2f+c/wzJly2DNwOgV373pfDhBQ21Od3MUB FzOaGm9hK+fonV+pbSyKx2dXkl2oCrRQgdySoHDTVEM4ypmhD+J8YYFIP3hx9a2LHJVD1n7GG0fP 4s+aIrOzr+HlBNv4rXAGTFZjslUYQV5S2tL01oGmO4has73rVGkGolmtL78gKYrUH0FYKQ9Pgug7 9YBnmeXEg9rPBx23byv3CjhKpQiDxiH2EAzSjxi6dtTjIuf/XjLzh/HKpg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 05:17:45 -0000 On 6/21/2019 5:19 PM, Marten Seemann wrote: > Ossification is prevented by actually using all available code points. > With the compressed 4 bit encoding, there's a good chance that > actually all connection ID lengths will be used by at least some QUIC > implementations, so there's minimal risk of ossification. However, > with options 2, we use a whole byte to encode just 20 values, > resulting in the first 3 bits always being 0 (in v1) - an easy target > for ossification. In the proposed solution, the ossification risk is that next versions will not be able to use other CID lengths than those allowed in V1. But in this "4 bit" solution, we are making the CID lengths allowed in V1 part of the invariants. That means we would be trading a potential risk of ossification against a certainty. Kind of like jumping in the water to avoid the rain... -- Christian Huitema From nobody Fri Jun 21 22:57:03 2019 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 14A0412025F for ; Fri, 21 Jun 2019 22:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31, SPF_HELO_NONE=0.001, SPF_NONE=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 01QdIxQrtVHY for ; Fri, 21 Jun 2019 22:56:56 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9564A120148 for ; Fri, 21 Jun 2019 22:56:55 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 3CF6430114; Sat, 22 Jun 2019 08:56:51 +0300 (EEST) Content-Type: multipart/alternative; boundary=Apple-Mail-3BD4D685-00AB-4FF7-8C59-2731E1609F8E Mime-Version: 1.0 (1.0) Subject: Re: Consensus Call: More Connection ID Space #2736 From: Lars Eggert In-Reply-To: Date: Sat, 22 Jun 2019 08:56:38 +0300 Cc: Martin Thomson , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: <60D13F7C-D8DE-4DD5-B7DB-1B560DB6E182@eggert.org> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b0 78@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> To: Ian Swett X-MailScanner-ID: 268D3600447.A7A33 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 05:57:00 -0000 --Apple-Mail-3BD4D685-00AB-4FF7-8C59-2731E1609F8E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I prefer (1), possibly even with the addition of reducing from 18 down to so= mething shorter.=20 LBs will evolve. I remain unconvinced that we need to keep bending the proto= col design for them. And if we ever need to go to longer CIDs in future versions of QUIC, there a= re unused flag bits. --=20 Sent from a mobile device; please excuse typos. > On Jun 21, 2019, at 23:00, Ian Swett wrote: >=20 > I think the 3 options I see as well reasoned are: > 1) Keep the status quo because we think we can put what we really need int= o 18 bytes if we try. > 2) Change to a 1 byte length per CID and a max of 20, which gives us a few= extra bytes for cleartext server id and/or key rotation/etc. > 3) Change to a 1 byte length per CID and a max of 36, because we want be a= ble to put 2 encrypted routing IDs in a single CID. >=20 > 2 is my preferred option, though I can live with either of 1 or 3. >=20 > Deciding sooner would be strictly better than later, since this is blockin= g us(Chrome/Google) actually supporting varlen CIDs. >=20 >> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote:= >> That seems a little high. I think that Ian's principle here is what shou= ld guide us: what is the minimum you can handle? What I've heard is that 18= might have been workable, but it was REALLY close to the edge to the point t= hat you weren't confident it was enough, even in the near term.. But that s= uggests that 20 is workable. >>=20 >> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >> > so do I hear consensus emerging around 32B in v1, or should I leave the= =20 >> > 18B limit in v1 for now and punt out that discussion? >> >=20 >> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel w= rote: >> > >=20 >> > >=20 >> > > > On 18. Jun 2019, at 05:33, Marten Seemann wrote: >> > > >=20 >> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we de= cide to increase the connection ID length to a larger value (which I'm still= not convinced that this is really necessary). >> > >=20 >> > > This would be easy if we change the encoding of the connection ID le= ngth, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While we ca= n not encode one or two byte connection IDs in long header packets, we can s= till use them in short header packets. >> > >=20 >> > > This split between long and short header also allows to use much lon= ger connection IDs after the handshake. >> > > I don=E2=80=99t see much use in it, but it may take off some fear th= at 24/32/36/48/60 byte connection IDs might not be long enough in the future= . >> > >=20 >> > > >=20 >> > > > There are two main reasons to keep the compressed encoding: >> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect tha= t all / most values will be used in practice, so we won't expose any bits on= the wire that identify a packet as "QUIC traffic" by having a predictable v= alue. >> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an impleme= ntation still needs to be able to deal with connection ID lengths of 255 byt= es, just to be able to send Version Negotiation packets. To me, it seems abs= urd to write a QUIC implementation that is able to handle packets with a com= bined connection ID overhead of 510 bytes. Since VNPs are supposed to be sen= t in response to any Long Header packet, you'd have to put some careful thou= ght into the design of your data types to avoid this becoming a DoS vector. >> > > >=20 >> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema wrote: >> > > > I too agree that using one byte in the invariant is preferable to t= he current "compressed 4 bits" solution. >> > > >=20 >> > > > Regarding the "CID length limit", I thing there are two issues: tr= ansmission overhead, and costs to the community. >> > > >=20 >> > > > I am not too concerned with the transmission overhead, as we have t= here the right mix of costs and incentives. Servers who chose to use longer C= ID will get more transmission overhead, and thus transmission less efficient= ly than their competitors. They may chose to use longer CID as a trade-off b= etween transmission efficiency and ease of management. Competition will sort= that out. I note that YouTube is apparently doing fine with smallish CID, s= o I trust that there will be competition. >> > > >=20 >> > > > I am much more concerned with the shared costs, which are a variat= ion of the "tragedy of the commons". Dmitry explained those costs well in a p= revious message. The simpler implementation is to make the "cid_t a fixed-si= ze object that can fit the largest CID and eat the overhead for all CIDs." B= ut each connection object carries a large number of instances of the CID typ= e. Having a very large max CID would imply a large overhead. The alternative= is to "Make cid_t a variable-size object", but too affects performance. >> > > >=20 >> > > > Hence the push-back. I would personally prefer a max size of 16, a= nd I think that 32 is the highest practical limit. >> > > >=20 >> > > > -- Christian Huitema >> > > >=20 >> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >> > > >> What I think people are saying so far: >> > > >>=20 >> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or= 48} >> > > >>=20 >> > > >> 2) Representation of CID length as a byte is still OK, thus a QUI= C v2 could use longer CIDs as needed by changing the spec while keeping the i= nvariants=E2=80=A6 invariant. >> > > >>=20 >> > > >>=20 >> > > >> That seems reasonable to me / I=E2=80=99d still support that. >> > > >>=20 >> > > >> -=3DR >> > > >>=20 >> > > >>=20 >> > > >> From: QUIC on behalf of "Lubashev, Igor" <= ilubashe@akamai.com> >> > > >> Date: Monday, June 17, 2019 at 8:55 AM >> > > >> To: Ian Swett , Mikkel Fa= hn=C3=B8e J=C3=B8rgensen >> > > >> Cc: Dmitri Tikhonov , Christian Huit= ema , "Philipp S. Tiesel" , Mike Bi= shop , Martin Thomson , Marten Seem= ann , Lars Eggert , QUIC WG , Martin Duke >, Kazuho Oku >> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 i= s likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably= be a factor of 8, so 32 or 24?). >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> We are firmly committed for using CID for in-cluster load balanci= ng / anycast pop routing. This discussion is taking us, however, to a new te= rritory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in a= n overlay network=E2=80=9D. This is a very interesting topic, but I would he= sitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC= v1. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> =E2=80=A2 Igor >> > > >>=20 >> > > >>=20 >> > > >> From: Ian Swett >> > > >>=20 >> > > >> My intuition says making the change to the invariants is the righ= t thing to do, but I don't feel that strongly. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> However, I'd like the max size to be smaller than 48(but larger t= han 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggest= ed 32, which is better, but I don't believe the server needs to use a separa= te block cipher when giving out connection IDs, because I believe it's impra= ctical for the load balancer and server to be that decoupled. The server has= to give out a CID that the load balancer will use to route back to the serv= er, so they have to share enough an encryption key/algorithm. I can imagine n= esting load balancers, but that's well in the range of QUIC v2 from my persp= ective. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> Whatever we do, I'd really prefer to resolve this sooner rather t= han later and be truly done with it. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen= wrote: >> > > >>=20 >> > > >> Since it is more likely that you pay for egress traffic than ingr= ess traffic, the motivation to keep CID=E2=80=99s small is limited. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> I do think the invariants should allow for long CID=E2=80=99s as p= roposed, and that the long header overhead is not important.. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> But for QUIC v1, if we allow for a long CID, a rush to market wil= l set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> I good reference on an algorithm like suggested by Christian woul= d go a long way. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> If CID length 18 turns out to be not enough, we can add a QUIC v2= . It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versi= ons soon. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> If CID length negotiation is needed, this could be done via QUIC v= ersions. For example two functionally equivalent versions, but one with long= er CID=E2=80=99s. This would also allow routers to deal with changes in CID l= engths. A negotiated TP would not (easily) allow for that and aside I do not= think CID length in TP is the way to go. >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> Mikkel >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wro= te: >> > > >>=20 >> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hui= tema :=20 >> > > >> >=20 >> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=20 >> > > >> >=20 >> > > >> > > _If_ we are to allow loose coupling between a load balancer a= nd a=20 >> > > >> > > server, each of the two should be given the freedom to choose= it's own=20 >> > > >> > > CID encryption scheme. Because all the standardized block cip= hers are=20 >> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the ma= ximum CID=20 >> > > >> > > length of QUIC needs to be double amount of that, plus one or= two=20 >> > > >> > > bytes for each of the two for identifying the CID encryption k= eys. For=20 >> > > >> > > key identification and other supplemental use, we currently a= llocate 2=20 >> > > >> > > bytes (18-16=3D2).=20 >> > > >> >=20 >> > > >> > That reasoning is based on the assumption that both the load ba= lancer=20 >> > > >> > and the server must use a block cipher with 128 bit block lengt= h in=20 >> > > >> > order to encrypt the CID. If they were constrained to stay with= in a=20 >> > > >> > short global limit, they could use different sets of algorithms= .=20 >> > > >> >=20 >> > > >> > Assume for example that we split the CID between 32 bits encodi= ng the=20 >> > > >> > number of the server in the server farm, and 64 bit encoding th= e=20 >> > > >> > connection number for the server. The server can pick a random v= alue for=20 >> > > >> > the connection number, and use a hash table. The load balancer c= ould use=20 >> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit o= f the CID=20 >> > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong e= ncryption.=20 >> > > >> >=20 >> > > >> > Or assume that the server wants to use short CID. We now split t= he CID=20 >> > > >> > between 32 bit for the server number in the farm, and 32 bit fo= r the=20 >> > > >> > connection number in the server. The server builds that connect= ion=20 >> > > >> > number by using a 32 bit variant of FFX. The load balancer also= uses a=20 >> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial ve= ctor for=20 >> > > >> > this FFX encryption.=20 >> > > >> >=20 >> > > >> > These are just two examples. And yes you may want to add 2 byte= s for key=20 >> > > >> > identification, etc. In both encryption algorithms, you can fee= d these=20 >> > > >> > two bytes as additional IV for the FFX algorithm. And in both c= ases, we=20 >> > > >> > are well below the 18 byte limit.=20 >> > > >> >=20 >> > > >> > Yes, that requires some creative engineering. But it is not roc= ker=20 >> > > >> > science. And it seems better than carrying tons of overhead in t= he=20 >> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP.=20 >> > > >>=20 >> > > >> I agree that it would not be the end of the world for the load=20= >> > > >> balancers if we decide to stick on the 18-byte limit. However, as= you=20 >> > > >> state, it requires some creativeness.=20 >> > > >>=20 >> > > >> To me it seems that the question is if we have a strong reason to= =20 >> > > >> require some people to be creative, for all the versions of QUIC i= n=20 >> > > >> the future. I personally think that there isn't a strong reason,=20= >> > > >> because people can use shorter CIDs regardless of the decision we= =20 >> > > >> make. IIUC, the overhead that everyone needs to accept is:=20 >> > > >>=20 >> > > >> * one byte increase in the long header packets=20 >> > > >> * the minimum size of short header packets becoming slightly grea= ter=20 >> > > >> (otherwise, the peer might not be able to send a stateless reset)= =20 >> > > >>=20 >> > > >> I'd say that the first bullet point is negligible. The second poi= nt=20 >> > > >> could also be, because I'd assume that the only frequently-sent=20= >> > > >> packets that require additional padding is the ACK-only packets, b= ut=20 >> > > >> there's no reason to pad ACK-only packets in hope that you'd see a= =20 >> > > >> stateless reset.=20 >> > > >>=20 >> > > >> Therefore, my (not-so-strong) preference has been to provide extr= a=20 >> > > >> room, so that some people with necessity can use longer CIDs.=20 >> > > >>=20 >> > > >> >=20 >> > > >> > -- Christian Huitema=20 >> > > >> >=20 >> > > >> >=20 >> > > >> >=20 >> > > >>=20 >> > > >>=20 >> > > >>=20 >> > > >> --=20 >> > > >> Kazuho Oku >> > > >>=20 >> > >=20 >> > > AVE! >> > > Philipp S. Tiesel >> > >=20 >> > > --=20 >> > > Philipp S. Tiesel=20 >> > > https://philipp.tiesel.net/ >> > > >>=20 --Apple-Mail-3BD4D685-00AB-4FF7-8C59-2731E1609F8E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I prefer (1), possibly even with the additi= on of reducing from 18 down to something shorter. 

L= Bs will evolve. I remain unconvinced that we need to keep bending the protoc= ol design for them.

And if we ever need to go to lo= nger CIDs in future versions of QUIC, there are unused flag bits.

-- 
Sent from a mobile devi= ce; please excuse typos.

On Jun 21, 2019, at= 23:00, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:

I think the 3 options= I see as well reasoned are:
1) Keep the status quo because we think we c= an put what we really need into 18 bytes if we try.
2) Change to a= 1 byte length per CID and a max of 20, which gives us a few extra bytes for= cleartext server id and/or key rotation/etc.
3) Change to a 1 byt= e length per CID and a max of 36, because we want be able to put 2 encrypted= routing IDs in a single CID.

2 is my preferred opt= ion, though I can live with either of 1 or 3.

Decid= ing sooner would be strictly better than later, since this is blocking us(Ch= rome/Google) actually supporting varlen CIDs.

On Thu, Jun 20, 2019 at 2:= 57 PM Martin Thomson <mt@lowentropy.= net> wrote:
That seems a little high.  I think that Ian's principle here is what s= hould guide us: what is the minimum you can handle?  What I've heard is= that 18 might have been workable, but it was REALLY close to the edge to th= e point that you weren't confident it was enough, even in the near term..&nb= sp; But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the=
> 18B limit in v1 for now and punt out that discussion?
>
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote:
= > >
> >
> >  > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.com> wrote:
> >  >
> >  > I'd prefer keeping the "compressed 4 bits" solution, ev= en if we decide to increase the connection ID length to a larger value (whic= h I'm still not convinced that this is really necessary).
> >
> >  This would be easy if we change the encoding of the connecti= on ID length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. Whi= le we can not encode one or two byte connection IDs in long header packets, w= e can still use them in short header packets.
> >
> >  This split between long and short header also allows to use m= uch longer connection IDs after the handshake.
> >  I don=E2=80=99t see much use in it, but it may take off some= fear that 24/32/36/48/60 byte connection IDs might not be long enough in th= e future.
> >
> >  >
> >  > There are two main reasons to keep the compressed encod= ing:
> >  > =E2=80=A2 In the compressed encoding, we can reasonably= expect that all / most values will be used in practice, so we won't expose a= ny bits on the wire that identify a packet as "QUIC traffic" by having a pre= dictable value.
> >  > =E2=80=A2 The 1-byte encoding has the disadvantage that= an implementation still needs to be able to deal with connection ID lengths= of 255 bytes, just to be able to send Version Negotiation packets. To me, i= t seems absurd to write a QUIC implementation that is able to handle packets= with a combined connection ID overhead of 510 bytes. Since VNPs are suppose= d to be sent in response to any Long Header packet, you'd have to put some c= areful thought into the design of your data types to avoid this becoming a D= oS vector.
> >  >
> >  > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <<= a href=3D"mailto:huitema@huitema.net" target=3D"_blank">huitema@huitema.net<= /a>> wrote:
> >  > I too agree that using one byte in the invariant is pre= ferable to the current "compressed 4 bits" solution.
> >  >
> >  > Regarding the "CID length limit", I thing there are two= issues: transmission overhead, and costs to the community.
> >  >
> >  > I am not too concerned with the transmission overhead, a= s we have there the right mix of costs and incentives. Servers who chose to u= se longer CID will get more transmission overhead, and thus transmission les= s efficiently than their competitors. They may chose to use longer CID as a t= rade-off between transmission efficiency and ease of management. Competition= will sort that out. I note that YouTube is apparently doing fine with small= ish CID, so I trust that there will be competition.
> >  >
> >  > I am much more concerned with the shared costs, which a= re a variation of the "tragedy of the commons". Dmitry explained those costs= well in a previous message. The simpler implementation is to make the "cid_= t a fixed-size object that can fit the largest CID and eat the overhead for a= ll CIDs." But each connection object carries a large number of instances of t= he CID type. Having a very large max CID would imply a large overhead. The a= lternative is to "Make cid_t a variable-size object", but too affects perfor= mance.
> >  >
> >  > Hence the push-back. I would personally prefer a max si= ze of 16, and I think that 32 is the highest practical limit.
> >  >
> >  > -- Christian Huitema
> >  >
> >  > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >  >> What I think people are saying so far:
> >  >>
> >  >> 1) QUIC v1 would limit CID length to something one o= f {32, 36, or 48}
> >  >>
> >  >> 2) Representation of CID length as a byte is still O= K, thus a QUIC v2 could use longer CIDs as needed by changing the spec while= keeping the invariants=E2=80=A6 invariant.
> >  >>
> >  >>
> >  >> That seems reasonable to me / I=E2=80=99d still sup= port that.
> >  >>
> >  >> -=3DR
> >  >>
> >  >>
> >  >> From: QUIC <quic-bounces@ietf.org> on behalf of "Lubashev= , Igor" <ilubash= e@akamai.com>
> >  >> Date: Monday, June 17, 2019 at 8:55 AM
> >  >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org&g= t;, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> >  >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, C= hristian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>, Mike Bishop &= lt;mbishop@evequef= ou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <martenseemann@gmail.com>,= Lars Eggert <lars@e= ggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com <mailto:martin..h.duke@gmail.= com>>, Kazuho Oku <kazuhooku@gmail.com>
> >  >> Subject: RE: Consensus Call: More Connection ID Spa= ce #2736
> >  >>
> >  >>
> >  >>
> >  >> My take is similar =E2=80=93 48 is probably excessi= ve, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it s= hould probably be a factor of 8, so 32 or 24?).
> >  >>
> >  >>
> >  >>
> >  >> We are firmly committed for using CID for in-cluste= r load balancing / anycast pop routing. This discussion is taking us, howeve= r, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlle= d routing in an overlay network=E2=80=9D. This is a very interesting topic, b= ut I would hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80= =9D in QUIC v1.
> >  >>
> >  >>
> >  >>
> >  >> =E2=80=A2 Igor
> >  >>
> >  >>
> >  >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org= >
> >  >>
> >  >> My intuition says making the change to the invarian= ts is the right thing to do, but I don't feel that strongly.
> >  >>
> >  >>
> >  >>
> >  >> However, I'd like the max size to be smaller than 4= 8(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. K= azuho suggested 32, which is better, but I don't believe the server needs to= use a separate block cipher when giving out connection IDs, because I belie= ve it's impractical for the load balancer and server to be that decoupled. T= he server has to give out a CID that the load balancer will use to route bac= k to the server, so they have to share enough an encryption key/algorithm. I= can imagine nesting load balancers, but that's well in the range of QUIC v2= from my perspective.
> >  >>
> >  >>
> >  >>
> >  >> Whatever we do, I'd really prefer to resolve this s= ooner rather than later and be truly done with it.
> >  >>
> >  >>
> >  >>
> >  >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J= =C3=B8rgensen <mi= kkelfj@gmail.com> wrote:
> >  >>
> >  >> Since it is more likely that you pay for egress tra= ffic than ingress traffic, the motivation to keep CID=E2=80=99s small is lim= ited.
> >  >>
> >  >>
> >  >>
> >  >> I do think the invariants should allow for long CID= =E2=80=99s as proposed, and that the long header overhead is not important..=
> >  >>
> >  >>
> >  >>
> >  >> But for QUIC v1, if we allow for a long CID, a rush= to market will set precedence and long CID=E2=80=99s will ossify in all kin= ds of stacks.
> >  >>
> >  >>
> >  >>
> >  >> I good reference on an algorithm like suggested by C= hristian would go a long way.
> >  >>
> >  >>
> >  >>
> >  >> If CID length 18 turns out to be not enough, we can= add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgr= ade QUIC versions soon.
> >  >>
> >  >>
> >  >>
> >  >> If CID length negotiation is needed, this could be d= one via QUIC versions. For example two functionally equivalent versions, but= one with longer CID=E2=80=99s. This would also allow routers to deal with c= hanges in CID lengths. A negotiated TP would not (easily) allow for that and= aside I do not think CID length in TP is the way to go.
> >  >>
> >  >>
> >  >>
> >  >> Mikkel
> >  >>
> >  >>
> >  >>
> >  >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) wrot= e:
> >  >>
> >  >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09= Christian Huitema <huitema@huitema.net>:
> >  >> >
> >  >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
> >  >> >
> >  >> > > _If_ we are to allow loose coupling betwe= en a load balancer and a
> >  >> > > server, each of the two should be given t= he freedom to choose it's own
> >  >> > > CID encryption scheme. Because all the st= andardized block ciphers are
> >  >> > > now 128-bits (=3D 16 bytes), that natural= ly means that the maximum CID
> >  >> > > length of QUIC needs to be double amount o= f that, plus one or two
> >  >> > > bytes for each of the two for identifying= the CID encryption keys. For
> >  >> > > key identification and other supplemental= use, we currently allocate 2
> >  >> > > bytes (18-16=3D2).
> >  >> >
> >  >> > That reasoning is based on the assumption that= both the load balancer
> >  >> > and the server must use a block cipher with 12= 8 bit block length in
> >  >> > order to encrypt the CID. If they were constra= ined to stay within a
> >  >> > short global limit, they could use different s= ets of algorithms.
> >  >> >
> >  >> > Assume for example that we split the CID betwe= en 32 bits encoding the
> >  >> > number of the server in the server farm, and 6= 4 bit encoding the
> >  >> > connection number for the server. The server c= an pick a random value for
> >  >> > the connection number, and use a hash table. T= he load balancer could use
> >  >> > a 32 bit variant of the FFX algorithm, using t= he lower 64 bit of the CID
> >  >> > as an initial vector. Voila, 96 CID, with demo= nstrably strong encryption.
> >  >> >
> >  >> > Or assume that the server wants to use short C= ID. We now split the CID
> >  >> > between 32 bit for the server number in the fa= rm, and 32 bit for the
> >  >> > connection number in the server. The server bu= ilds that connection
> >  >> > number by using a 32 bit variant of FFX. The l= oad balancer also uses a
> >  >> > 32 bit variant, using the lower 32 bit of the C= ID as initial vector for
> >  >> > this FFX encryption.
> >  >> >
> >  >> > These are just two examples. And yes you may w= ant to add 2 bytes for key
> >  >> > identification, etc. In both encryption algori= thms, you can feed these
> >  >> > two bytes as additional IV for the FFX algorit= hm. And in both cases, we
> >  >> > are well below the 18 byte limit.
> >  >> >
> >  >> > Yes, that requires some creative engineering. B= ut it is not rocker
> >  >> > science. And it seems better than carrying ton= s of overhead in the
> >  >> > header, and becoming less efficient than HTTP2= /TLS/TCP.
> >  >>
> >  >> I agree that it would not be the end of the world f= or the load
> >  >> balancers if we decide to stick on the 18-byte limi= t. However, as you
> >  >> state, it requires some creativeness.
> >  >>
> >  >> To me it seems that the question is if we have a st= rong reason to
> >  >> require some people to be creative, for all the ver= sions of QUIC in
> >  >> the future. I personally think that there isn't a s= trong reason,
> >  >> because people can use shorter CIDs regardless of t= he decision we
> >  >> make. IIUC, the overhead that everyone needs to acc= ept is:
> >  >>
> >  >> * one byte increase in the long header packets
= > >  >> * the minimum size of short header packets becoming= slightly greater
> >  >> (otherwise, the peer might not be able to send a st= ateless reset)
> >  >>
> >  >> I'd say that the first bullet point is negligible. T= he second point
> >  >> could also be, because I'd assume that the only fre= quently-sent
> >  >> packets that require additional padding is the ACK-= only packets, but
> >  >> there's no reason to pad ACK-only packets in hope t= hat you'd see a
> >  >> stateless reset.
> >  >>
> >  >> Therefore, my (not-so-strong) preference has been t= o provide extra
> >  >> room, so that some people with necessity can use lo= nger CIDs.
> >  >>
> >  >> >
> >  >> > -- Christian Huitema
> >  >> >
> >  >> >
> >  >> >
> >  >>
> >  >>
> >  >>
> >  >> --
> >  >> Kazuho Oku
> >  >>
> >
> >  AVE!
> >  Philipp S. Tiesel
> >
> >  --
> >  Philipp S. Tiesel
> > https://philipp.tiesel.net/
> >

= --Apple-Mail-3BD4D685-00AB-4FF7-8C59-2731E1609F8E-- From nobody Sat Jun 22 01:24:35 2019 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 2CF79120132 for ; Sat, 22 Jun 2019 01:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfHtC8frvM0V for ; Sat, 22 Jun 2019 01:24:31 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 A41F7120119 for ; Sat, 22 Jun 2019 01:24:30 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id d4so13589804edr.13 for ; Sat, 22 Jun 2019 01:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=85bYPRDMyMpUINbDe8pG2gQWydi5iMAJpNUNovfY4P0=; b=qRV5GmmFQMsZ+fUzXLtSw2jXHoYz1cy573DEhnqx0Sg94MwHzNar/BbidwjT1869hT uGYCfyo+f9wnu1gB7W3nVUZtrt9iOJ5My5nvc10ByRObpvwNCwvt7an1t1XvffEFNPKE K3vPCDD/v9XZaq2k5oX2mpVVXjPBy/XnfV4oEnSlUVxeTiAJbMKE+PyRLe+V5gojrres pHMrunXH7iR4LBjumMCDxL9O331A0mRguFpS+3GuMbL/lEszrZ1K4JB1Vb8NcCtvhW7S uk26WVt+X5syIk/QGKen/2kY3o7aWZFg8tAwpEaBnerldx86CYKlKsG2VygnnKLL7PRu n7Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=85bYPRDMyMpUINbDe8pG2gQWydi5iMAJpNUNovfY4P0=; b=GgWGm272BxpMvuJASFcK10OonDatoqiyAuu9FmlTNmRVSy7YmoPwqLMah99eQjxk3c b6VdwvWveqBo50Sfzg8NMV/ly2E04f0rFqb4Tq+MLvlOko9pz269V0a9BmTiCklb+NfI hqNBKwoOVWVoa4vvSUBfFwZ4O1fklUv5HMmpuiZGIFjKBGcGCxsxJFFTMRlRHSIrqtH2 96PYfBAaJzkz0LU7KT4LbONFVqJ9NOaGcrgklFYuyt9ULcaBcYC/IHJwONfY76LwPhQi ccUCQipukX2b9j+v02wKoV5bZ4ZqpenfyvqJbUxi/DVvyXJ6rqO32Hh/95pyKd+Ehmo8 Qfmw== X-Gm-Message-State: APjAAAW6MERwk9NVOpqx3uoUuQKGQa9wWtE5JEU/qnTHmqjnUqkmvcTB HQE7LlHMzrdBR8MJtsM7aKNvQx461bK8T40GP9OJlPAN X-Google-Smtp-Source: APXvYqymdIKpafZlls1b/i83rphnwsZQL2xNqMHoVsc8TOQ8uXPJvqMTFbNuNngWG4cS6njpV88QiOSvSWTzTd3lu+8= X-Received: by 2002:a50:d0d6:: with SMTP id g22mr80197253edf.250.1561191869142; Sat, 22 Jun 2019 01:24:29 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 22 Jun 2019 01:24:26 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <60D13F7C-D8DE-4DD5-B7DB-1B560DB6E182@eggert.org> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> <60D13F7C-D8DE-4DD5-B7DB-1B560DB6E182@eggert.org> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 22 Jun 2019 01:24:26 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Lars Eggert , Ian Swett Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c96470058be54e70" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 22 Jun 2019 08:24:34 -0000 --000000000000c96470058be54e70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think there as some private use cases for very long CID=E2=80=99s in mesh networking where you replace the IP header entirely. So I would like to see the invariants support long CIDs, but not v1 and I generally share Lars=E2=80=99 concern about trying to please load balancers= too much as they will grab the entire arm. If ossification to short lengths is a concern (I=E2=80=99m not convinced), = we could consider a longer length QUIC version just to scrub the system. Having two versions where not all clients support the long version would prevent load balancers from requiring long version while still keeping the possibility open. A future longer CID version could also be required to have entropy in the leading bits such that a load balancer is not required to deal with the full CID in all cases. They could just hash the first 32 bits like they hash IP/port today using a fast multiplier hash. I do not see as a problem that vneg needs to deal with long CID=E2=80=99s s= ince it is a completely isolated code path. The only possible concern here is the amount of information you might need to cache against a given server, but normally it would suffice to note the preferred version which would be sufficiently short if you support it. On 22 June 2019 at 07.57.14, Lars Eggert (lars@eggert.org) wrote: I prefer (1), possibly even with the addition of reducing from 18 down to something shorter. LBs will evolve. I remain unconvinced that we need to keep bending the protocol design for them. And if we ever need to go to longer CIDs in future versions of QUIC, there are unused flag bits. -- Sent from a mobile device; please excuse typos. On Jun 21, 2019, at 23:00, Ian Swett wrote: I think the 3 options I see as well reasoned are: 1) Keep the status quo because we think we can put what we really need into 18 bytes if we try. 2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc. 3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID. 2 is my preferred option, though I can live with either of 1 or 3. Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs. On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote: > That seems a little high. I think that Ian's principle here is what > should guide us: what is the minimum you can handle? What I've heard is > that 18 might have been workable, but it was REALLY close to the edge to > the point that you weren't confident it was enough, even in the near > term.. But that suggests that 20 is workable. > > On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > > so do I hear consensus emerging around 32B in v1, or should I leave the > > 18B limit in v1 for now and punt out that discussion? > > > > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel > wrote: > > > > > > > > > > On 18. Jun 2019, at 05:33, Marten Seemann > wrote: > > > > > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we > decide to increase the connection ID length to a larger value (which I'm > still not convinced that this is really necessary). > > > > > > This would be easy if we change the encoding of the connection ID > length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While = we > can not encode one or two byte connection IDs in long header packets, we > can still use them in short header packets. > > > > > > This split between long and short header also allows to use much > longer connection IDs after the handshake. > > > I don=E2=80=99t see much use in it, but it may take off some fear th= at > 24/32/36/48/60 byte connection IDs might not be long enough in the future= . > > > > > > > > > > > There are two main reasons to keep the compressed encoding: > > > > =E2=80=A2 In the compressed encoding, we can reasonably expect tha= t all / > most values will be used in practice, so we won't expose any bits on the > wire that identify a packet as "QUIC traffic" by having a predictable val= ue. > > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an impleme= ntation > still needs to be able to deal with connection ID lengths of 255 bytes, > just to be able to send Version Negotiation packets. To me, it seems absu= rd > to write a QUIC implementation that is able to handle packets with a > combined connection ID overhead of 510 bytes. Since VNPs are supposed to = be > sent in response to any Long Header packet, you'd have to put some carefu= l > thought into the design of your data types to avoid this becoming a DoS > vector. > > > > > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < > huitema@huitema.net> wrote: > > > > I too agree that using one byte in the invariant is preferable to > the current "compressed 4 bits" solution. > > > > > > > > Regarding the "CID length limit", I thing there are two issues: > transmission overhead, and costs to the community. > > > > > > > > I am not too concerned with the transmission overhead, as we have > there the right mix of costs and incentives. Servers who chose to use > longer CID will get more transmission overhead, and thus transmission les= s > efficiently than their competitors. They may chose to use longer CID as a > trade-off between transmission efficiency and ease of management. > Competition will sort that out. I note that YouTube is apparently doing > fine with smallish CID, so I trust that there will be competition. > > > > > > > > I am much more concerned with the shared costs, which are a > variation of the "tragedy of the commons". Dmitry explained those costs > well in a previous message. The simpler implementation is to make the > "cid_t a fixed-size object that can fit the largest CID and eat the > overhead for all CIDs." But each connection object carries a large number > of instances of the CID type. Having a very large max CID would imply a > large overhead. The alternative is to "Make cid_t a variable-size object"= , > but too affects performance. > > > > > > > > Hence the push-back. I would personally prefer a max size of 16, > and I think that 32 is the highest practical limit. > > > > > > > > -- Christian Huitema > > > > > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > > >> What I think people are saying so far: > > > >> > > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, or > 48} > > > >> > > > >> 2) Representation of CID length as a byte is still OK, thus a QUI= C > v2 could use longer CIDs as needed by changing the spec while keeping the > invariants=E2=80=A6 invariant. > > > >> > > > >> > > > >> That seems reasonable to me / I=E2=80=99d still support that. > > > >> > > > >> -=3DR > > > >> > > > >> > > > >> From: QUIC > on > behalf of "Lubashev, Igor" > > > >> Date: Monday, June 17, 2019 at 8:55 AM > > > >> To: Ian Swett , Mikkel > Fahn=C3=B8e J=C3=B8rgensen > > > >> Cc: Dmitri Tikhonov , Christian > Huitema , "Philipp S. Tiesel" , > Mike Bishop , Martin Thomson , > Marten Seemann , Lars Eggert , > QUIC WG , Martin Duke martin..h.duke@gmail.com>>, Kazuho Oku > > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > > >> > > > >> > > > >> > > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 i= s likely > the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a = factor of 8, so 32 > or 24?). > > > >> > > > >> > > > >> > > > >> We are firmly committed for using CID for in-cluster load > balancing / anycast pop routing. This discussion is taking us, however, t= o > a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled r= outing in an > overlay network=E2=80=9D. This is a very interesting topic, but I would h= esitate to > attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. > > > >> > > > >> > > > >> > > > >> =E2=80=A2 Igor > > > >> > > > >> > > > >> From: Ian Swett > > > >> > > > >> My intuition says making the change to the invariants is the righ= t > thing to do, but I don't feel that strongly. > > > >> > > > >> > > > >> > > > >> However, I'd like the max size to be smaller than 48(but larger > than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho > suggested 32, which is better, but I don't believe the server needs to us= e > a separate block cipher when giving out connection IDs, because I believe > it's impractical for the load balancer and server to be that decoupled. T= he > server has to give out a CID that the load balancer will use to route bac= k > to the server, so they have to share enough an encryption key/algorithm. = I > can imagine nesting load balancers, but that's well in the range of QUIC = v2 > from my perspective. > > > >> > > > >> > > > >> > > > >> Whatever we do, I'd really prefer to resolve this sooner rather > than later and be truly done with it. > > > >> > > > >> > > > >> > > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen= < > mikkelfj@gmail.com> wrote: > > > >> > > > >> Since it is more likely that you pay for egress traffic than > ingress traffic, the motivation to keep CID=E2=80=99s small is limited. > > > >> > > > >> > > > >> > > > >> I do think the invariants should allow for long CID=E2=80=99s as = proposed, > and that the long header overhead is not important.. > > > >> > > > >> > > > >> > > > >> But for QUIC v1, if we allow for a long CID, a rush to market wil= l > set precedence and long CID=E2=80=99s will ossify in all kinds of stacks. > > > >> > > > >> > > > >> > > > >> I good reference on an algorithm like suggested by Christian woul= d > go a long way. > > > >> > > > >> > > > >> > > > >> If CID length 18 turns out to be not enough, we can add a QUIC v2= . > It=E2=80=99s not like we are not looking for excuses to upgrade QUIC vers= ions soon. > > > >> > > > >> > > > >> > > > >> If CID length negotiation is needed, this could be done via QUIC > versions. For example two functionally equivalent versions, but one with > longer CID=E2=80=99s. This would also allow routers to deal with changes = in CID > lengths. A negotiated TP would not (easily) allow for that and aside I do > not think CID length in TP is the way to go. > > > >> > > > >> > > > >> > > > >> Mikkel > > > >> > > > >> > > > >> > > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) > wrote: > > > >> > > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hui= tema : > > > >> > > > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: > > > >> > > > > >> > > _If_ we are to allow loose coupling between a load balancer > and a > > > >> > > server, each of the two should be given the freedom to choose > it's own > > > >> > > CID encryption scheme. Because all the standardized block > ciphers are > > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the > maximum CID > > > >> > > length of QUIC needs to be double amount of that, plus one or > two > > > >> > > bytes for each of the two for identifying the CID encryption > keys. For > > > >> > > key identification and other supplemental use, we currently > allocate 2 > > > >> > > bytes (18-16=3D2). > > > >> > > > > >> > That reasoning is based on the assumption that both the load > balancer > > > >> > and the server must use a block cipher with 128 bit block lengt= h > in > > > >> > order to encrypt the CID. If they were constrained to stay > within a > > > >> > short global limit, they could use different sets of algorithms= . > > > >> > > > > >> > Assume for example that we split the CID between 32 bits > encoding the > > > >> > number of the server in the server farm, and 64 bit encoding th= e > > > >> > connection number for the server. The server can pick a random > value for > > > >> > the connection number, and use a hash table. The load balancer > could use > > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit o= f > the CID > > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong > encryption. > > > >> > > > > >> > Or assume that the server wants to use short CID. We now split > the CID > > > >> > between 32 bit for the server number in the farm, and 32 bit fo= r > the > > > >> > connection number in the server. The server builds that > connection > > > >> > number by using a 32 bit variant of FFX. The load balancer also > uses a > > > >> > 32 bit variant, using the lower 32 bit of the CID as initial > vector for > > > >> > this FFX encryption. > > > >> > > > > >> > These are just two examples. And yes you may want to add 2 byte= s > for key > > > >> > identification, etc. In both encryption algorithms, you can fee= d > these > > > >> > two bytes as additional IV for the FFX algorithm. And in both > cases, we > > > >> > are well below the 18 byte limit. > > > >> > > > > >> > Yes, that requires some creative engineering. But it is not > rocker > > > >> > science. And it seems better than carrying tons of overhead in > the > > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. > > > >> > > > >> I agree that it would not be the end of the world for the load > > > >> balancers if we decide to stick on the 18-byte limit. However, as > you > > > >> state, it requires some creativeness. > > > >> > > > >> To me it seems that the question is if we have a strong reason to > > > >> require some people to be creative, for all the versions of QUIC = in > > > >> the future. I personally think that there isn't a strong reason, > > > >> because people can use shorter CIDs regardless of the decision we > > > >> make. IIUC, the overhead that everyone needs to accept is: > > > >> > > > >> * one byte increase in the long header packets > > > >> * the minimum size of short header packets becoming slightly > greater > > > >> (otherwise, the peer might not be able to send a stateless reset) > > > >> > > > >> I'd say that the first bullet point is negligible. The second poi= nt > > > >> could also be, because I'd assume that the only frequently-sent > > > >> packets that require additional padding is the ACK-only packets, > but > > > >> there's no reason to pad ACK-only packets in hope that you'd see = a > > > >> stateless reset. > > > >> > > > >> Therefore, my (not-so-strong) preference has been to provide extr= a > > > >> room, so that some people with necessity can use longer CIDs. > > > >> > > > >> > > > > >> > -- Christian Huitema > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Kazuho Oku > > > >> > > > > > > AVE! > > > Philipp S. Tiesel > > > > > > -- > > > Philipp S. Tiesel > > > https://philipp.tiesel.net/ > > > > > --000000000000c96470058be54e70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I think there as som= e private use cases for very long CID=E2=80=99s in mesh networking where yo= u replace the IP header entirely.
So I would like to see the invariants support long C= IDs, but not v1 and I generally share Lars=E2=80=99 concern about trying to= please load balancers too much as they will grab the entire arm.

If ossification to short lengt= hs is a concern (I=E2=80=99m not convinced), we could consider a longer len= gth QUIC version just to scrub the system. Having two versions where not al= l clients support the long version would prevent load balancers from requir= ing long version while still keeping the possibility open.

A future longer CID version could als= o be required to have entropy in the leading bits such that a load balancer= is not required to deal with the full CID in all cases. They could just ha= sh the first 32 bits like they hash IP/port today using a fast multiplier h= ash.

I do not see as = a problem that vneg needs to deal with long CID=E2=80=99s since it is a com= pletely isolated code path. The only possible concern here is the amount of= information you might need to cache against a given server, but normally i= t would suffice to note the preferred version which would be sufficiently s= hort if you support it.



On 22 June 20= 19 at 07.57.14, Lars Eggert (lars@eggert= .org) wrote:

I prefer (1), possibly even with the addition of reducing from 18 down to something shorter.=C2=A0

LBs will evolve. I remain unconvinced that we need to keep bending the protocol design for them.

And if we ever need to go to longer CIDs in future versions of QUIC, there are unused flag bits.

--=C2=A0
Sent from a mobile device; please excuse typos.

On Jun 21, 2019, at 23:00, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:

I think the 3 options I see as well reasoned are:
1) Keep the status quo because we think we can put what we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID.

2 is my preferred option, though I can live with either of 1 or 3.

Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs.

On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <mt@lowentropy.net> wrote:
That seems a little high.=C2=A0 I think that Ian's principle here is what should guide us: what is the minimum you can handle?=C2=A0 What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term..=C2=A0 But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the
> 18B limit in v1 for now and punt out that discussion?
>
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote: > >
> >
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseem= ann@gmail.com> wrote:
> >=C2=A0 >
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary).
> >
> >=C2=A0 This would be easy if we change the encoding of the connection ID length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
> >
> >=C2=A0 This split between long and short header also allows to use much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future.
> >
> >=C2=A0 >
> >=C2=A0 > There are two main reasons to keep the compressed encoding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector.
> >=C2=A0 >
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <huitem= a@huitema.net> wrote:
> >=C2=A0 > I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.
> >=C2=A0 >
> >=C2=A0 > Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >
> >=C2=A0 > I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.
> >=C2=A0 >
> >=C2=A0 > I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.
> >=C2=A0 >
> >=C2=A0 > Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one of {32, 36, or 48}
> >=C2=A0 >>
> >=C2=A0 >> 2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still support that.
> >=C2=A0 >>
> >=C2=A0 >> -=3DR
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "= Lubashev, Igor" <ilu= bashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org= >, Mikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>,= Christian Huitema <huitema@huitem= a.net>, "Philipp S. Tiesel" <philipp@tiesel.= net>, Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten = Seemann <ma= rtenseemann@gmail.com>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.or= g>, Martin Duke <martin.h.duke@gmail.com <mailto:martin..h.duke@gmail.com>>= , Kazuho Oku <kazuhooku@gmai= l.com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Space #2736
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excessive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80= =9D (it should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> We are firmly committed for using CID for in-cluster load balancing / anycast pop routing. This discussion is taking us, however, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled routing in an overlay network=E2=80=9D. Thi= s is a very interesting topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>
> >=C2=A0 >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> However, I'd like the max size to be smaller than 48(but larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled. The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm. I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> >=C2=A0 >>
> >=C2=A0 >> Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID=E2=80=99s small is limited.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I do think the invariants should allow for long CID=E2=80=99s as proposed, and that the long header overhead is not important..
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID=E2=80=99s will ossify in all kinds of stacks.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I good reference on an algorithm like suggested by Christian would go a long way.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length 18 turns out to be not enough, we can add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC versions soon.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID=E2=80=99s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Mikkel
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.c= om) wrote:
> >=C2=A0 >>
> >=C2=A0 >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:0= 9 Christian Huitema <huitema@huitem= a.net>:
> >=C2=A0 >> >
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
> >=C2=A0 >> >
> >=C2=A0 >> > > _If_ we are to allow loose coupling between a load balancer and a
> >=C2=A0 >> > > server, each of the two should be given the freedom to choose it's own
> >=C2=A0 >> > > CID encryption scheme. Because all the standardized block ciphers are
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that naturally means that the maximum CID
> >=C2=A0 >> > > length of QUIC needs to be double amount of that, plus one or two
> >=C2=A0 >> > > bytes for each of the two for identifying the CID encryption keys. For
> >=C2=A0 >> > > key identification and other supplemental use, we currently allocate 2
> >=C2=A0 >> > > bytes (18-16=3D2).
> >=C2=A0 >> >
> >=C2=A0 >> > That reasoning is based on the assumption that both the load balancer
> >=C2=A0 >> > and the server must use a block cipher with 128 bit block length in
> >=C2=A0 >> > order to encrypt the CID. If they were constrained to stay within a
> >=C2=A0 >> > short global limit, they could use different sets of algorithms.
> >=C2=A0 >> >
> >=C2=A0 >> > Assume for example that we split the CID between 32 bits encoding the
> >=C2=A0 >> > number of the server in the server farm, and 64 bit encoding the
> >=C2=A0 >> > connection number for the server. The server can pick a random value for
> >=C2=A0 >> > the connection number, and use a hash table. The load balancer could use
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with demonstrably strong encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > Or assume that the server wants to use short CID. We now split the CID
> >=C2=A0 >> > between 32 bit for the server number in the farm, and 32 bit for the
> >=C2=A0 >> > connection number in the server. The server builds that connection
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The load balancer also uses a
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the CID as initial vector for
> >=C2=A0 >> > this FFX encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > These are just two examples. And yes you may want to add 2 bytes for key
> >=C2=A0 >> > identification, etc. In both encryption algorithms, you can feed these
> >=C2=A0 >> > two bytes as additional IV for the FFX algorithm. And in both cases, we
> >=C2=A0 >> > are well below the 18 byte limit.
> >=C2=A0 >> >
> >=C2=A0 >> > Yes, that requires some creative engineering. But it is not rocker
> >=C2=A0 >> > science. And it seems better than carrying tons of overhead in the
> >=C2=A0 >> > header, and becoming less efficient than HTTP2/TLS/TCP.
> >=C2=A0 >>
> >=C2=A0 >> I agree that it would not be the end of the world for the load
> >=C2=A0 >> balancers if we decide to stick on the 18-byte limit. However, as you
> >=C2=A0 >> state, it requires some creativeness.
> >=C2=A0 >>
> >=C2=A0 >> To me it seems that the question is if we have a strong reason to
> >=C2=A0 >> require some people to be creative, for all the versions of QUIC in
> >=C2=A0 >> the future. I personally think that there isn't a strong reason,
> >=C2=A0 >> because people can use shorter CIDs regardless of the decision we
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to accept is:
> >=C2=A0 >>
> >=C2=A0 >> * one byte increase in the long header packets
> >=C2=A0 >> * the minimum size of short header packets becoming slightly greater
> >=C2=A0 >> (otherwise, the peer might not be able to send a stateless reset)
> >=C2=A0 >>
> >=C2=A0 >> I'd say that the first bullet point is negligible. The second point
> >=C2=A0 >> could also be, because I'd assume that the only frequently-sent
> >=C2=A0 >> packets that require additional padding is the ACK-only packets, but
> >=C2=A0 >> there's no reason to pad ACK-only packets in hope that you'd see a
> >=C2=A0 >> stateless reset.
> >=C2=A0 >>
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been to provide extra
> >=C2=A0 >> room, so that some people with necessity can use longer CIDs.
> >=C2=A0 >>
> >=C2=A0 >> >
> >=C2=A0 >> > -- Christian Huitema
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> --
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>
> >
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >
> >=C2=A0 --
> >=C2=A0 Philipp S. Tiesel
> > https://philipp.tiesel.net/
> >

--000000000000c96470058be54e70-- From nobody Sat Jun 22 17:45:34 2019 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 5A301120033 for ; Sat, 22 Jun 2019 17:45:30 -0700 (PDT) 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 (2048-bit key) header.d=mnot.net header.b=TU7VwVW9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bMOXj39/ 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 GsiKhlTcHg7C for ; Sat, 22 Jun 2019 17:45:25 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F34120019 for ; Sat, 22 Jun 2019 17:45:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5C73A21FE7 for ; Sat, 22 Jun 2019 20:45:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 22 Jun 2019 20:45:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=NAweC6x851UBGmHEvu2UvLKNUC/3Lag1e2pmsNVoCMs=; b=TU7VwVW9 DHhj+rMjzhVZFboJyNKKj3+W0mvR+T4L8tUUeSLXsrf+N04d2O9pWGHgMSx9YR7N WdkcMKS2sGUXkiWmk7+eCTfawgKMzTz9m+cYurqKwZ61PfUW6MjjOlkFVz4Jwdx4 4GS+IVHjMrAjy4YTtgNPDdzwpjLrjRWJeNr4lGfBLu7fb3Qa4HpE49J3NfoQ+jQx puPWObFesvMamzLBoAM8QqYTVoh260boHupDe/4UdByqaeELthNyFEEvp/R/1NK2 MQLFZpRqc1bqGcpAoaOYIFys7qF56wMeQ6K7tKAZGoferKmkDMTB613ea0U4se16 Mqk77rI8t4HhBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=NAweC6x851UBGmHEvu2UvLKNUC/3L ag1e2pmsNVoCMs=; b=bMOXj39/J/k8boUXGT5YYA0xXi3jsrIta0ERjtqP69v0t EIF9Wv2bZnqs+Aj+9Y4IiXwKGXcnz7eozUtunYQPHS8covTMGnRPoufoeZxjIgYR Ol2TWSTu5ugU7AuKSf1u5VzcIxuJiGfEX5f9nNG9DTe4U+zLwIiLMw//K3qOpu/3 S0LYkwdtxxqsPIu7DR7XEayMZee8UiZNDAIb8mjnGPtVaEWeHrN68tk38WwibxAi BQOaWxQrpg5z23WQUj1HyRuy1k5t9I9bRauEnqDwwjBBf4PHuaFJv6pgEdKRhSU2 LC1UOgZMdnUXjS0XZL/B4xg7/LPGQKwpTyAyxnQUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrtdelgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 38A458005A for ; Sat, 22 Jun 2019 20:45:22 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id A93C3C0316 for ; Sun, 23 Jun 2019 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============5328089649018189521==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190623004517.A93C3C0316@cloud.mnot.net> Date: Sun, 23 Jun 2019 00:45:17 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jun 2019 00:45:31 -0000 --===============5328089649018189521== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+16/-6/=F0=9F=92=AC28) 16 issues created: - text about rejecting 0-RTT is unclear (by marten-seemann) https://github.com/quicwg/base-drafts/issues/2829 = - Exceeding Max STREAM ID should be a connection error (by ianswett) https://github.com/quicwg/base-drafts/issues/2825 = - Proposal for Handling Issues with NAT due to QUIC being a UDP protocol = (by john01dav) https://github.com/quicwg/base-drafts/issues/2824 = - Do Initial secrets change after Retry packet? (by nharper) https://github.com/quicwg/base-drafts/issues/2823 = - Rationalize HTTP/3 stream creation errors (by LPardue) https://github.com/quicwg/base-drafts/issues/2821 = - CANCEL_PUSH edge cases (by LPardue) https://github.com/quicwg/base-drafts/issues/2819 = - Iinvalid Push ID error codes (by LPardue) https://github.com/quicwg/base-drafts/issues/2818 = - Guidance for propogation of errors between H2 and H3 (by LPardue) https://github.com/quicwg/base-drafts/issues/2817 = - Handling RESET_STREAM and STOP_SENDING with invalid error codes (by LPa= rdue) https://github.com/quicwg/base-drafts/issues/2816 = - H3 has a stale reference to STREAM_ID_ERROR (by LPardue) https://github.com/quicwg/base-drafts/issues/2815 = - Rationalise Server-Push-specific rejection error codes (by LPardue) https://github.com/quicwg/base-drafts/issues/2812 = - Suggest removal of HTTP_WRONG_SETTING_DIRECTION error (by LPardue) https://github.com/quicwg/base-drafts/issues/2810 = - Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTD_FRAME (by LPardue) https://github.com/quicwg/base-drafts/issues/2809 = - H3 appendix A.4 GENERAL_PROTOCOL_ERROR (by LPardue) https://github.com/quicwg/base-drafts/issues/2807 = - Rationalize terminology around transport/application interactions (by M= ikeBishop) https://github.com/quicwg/base-drafts/issues/2805 [-http] [-transport] = [design] = - describe how a client is supposed to handle multiple tokens (by marten-= seemann) https://github.com/quicwg/base-drafts/issues/2801 = 11 issues received 28 new comments: - #2824 Proposal for Handling Issues with NAT due to QUIC being a UDP pro= tocol (6 by RyanAtGoogle, mikkelfj, ianswett) https://github.com/quicwg/base-drafts/issues/2824 = - #2812 Rationalise Server-Push-specific rejection error codes (5 by kazu= ho, LPardue) https://github.com/quicwg/base-drafts/issues/2812 = - #2818 Invalid Push ID error codes (4 by kazuho, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2818 = - #2801 describe how a client is supposed to handle multiple tokens (3 by= martinthomson, marten-seemann, ianswett) https://github.com/quicwg/base-drafts/issues/2801 [-transport] = - #2810 Rationalise HTTP_WRONG_SETTING_DIRECTION error (3 by kazuho, LPar= due) https://github.com/quicwg/base-drafts/issues/2810 = - #2770 If you want a Stateless Reset you need to send a much larger pack= et than before (2 by DavidSchinazi, marten-seemann) https://github.com/quicwg/base-drafts/issues/2770 [-transport] [design] = - #2816 Handling RESET_STREAM and STOP_SENDING with invalid error codes (= 1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2816 [-http] [design] = - #2339 QPACK: instructions and stream description is suboptimal (1 by LP= ardue) https://github.com/quicwg/base-drafts/issues/2339 [-qpack] [editorial] = - #2823 Do Initial secrets change after Retry packet? (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2823 [-tls] = - #2825 Exceeding Max STREAM ID should be a connection error (1 by ianswe= tt) https://github.com/quicwg/base-drafts/issues/2825 [-transport] = - #2737 TLS draft still contains a section about the old version negotiat= ion (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2737 [-tls] [editorial] = 6 issues closed: - We lost the text recommending replacement of used CIDs https://github.c= om/quicwg/base-drafts/issues/2725 [-transport] [editorial] = - Where can you send CONNECTION_CLOSE https://github.com/quicwg/base-draf= ts/issues/2151 [-transport] [design] = - TLS draft still contains a section about the old version negotiation ht= tps://github.com/quicwg/base-drafts/issues/2737 [-tls] [editorial] = - Is Retry a new connection or what? https://github.com/quicwg/base-draft= s/issues/2180 [-transport] [editorial] [proposal-ready] = - Error code to be sent when the size of request headers exceed server's = limit https://github.com/quicwg/base-drafts/issues/2775 [-http] = - Semantics of SETTINGS_MAX_HEADER_LIST_SIZE https://github.com/quicwg/ba= se-drafts/issues/2516 [-http] = Pull requests ------------- * quicwg/base-drafts (+14/-9/=F0=9F=92=AC26) 14 pull requests submitted: - Fix title capitalization (by amirlivneh) https://github.com/quicwg/base-drafts/pull/2828 = - Fix typos (by amirlivneh) https://github.com/quicwg/base-drafts/pull/2827 = - Make exceeding stream limits a connection error (by ianswett) https://github.com/quicwg/base-drafts/pull/2826 [-transport] = - Rationalize HTTP/3 stream creation errors (by LPardue) https://github.com/quicwg/base-drafts/pull/2822 = - Refactor Push ID related errors (by LPardue) https://github.com/quicwg/base-drafts/pull/2820 = - Rationalize HTTP_WRONG_SETTING_DIRECTION (by LPardue) https://github.com/quicwg/base-drafts/pull/2814 = - Remove HTTP_PUSH_ALREADY_IN_CACHE error (by LPardue) https://github.com/quicwg/base-drafts/pull/2813 = - Remove SETTINGS_NUM_PLACEHOLDERS (by LPardue) https://github.com/quicwg/base-drafts/pull/2811 = - Compare H2 PROTOCOL_ERROR with HTTP_GENERAL_PROTOCOL_ERROR (by LPardue) https://github.com/quicwg/base-drafts/pull/2808 = - Merge Crypto timeout and PTO (by ianswett) https://github.com/quicwg/base-drafts/pull/2806 [-recovery] = - Move Retry and Version Negotiation (by ianswett) https://github.com/quicwg/base-drafts/pull/2804 = - remove outdated text about version negotiation (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2803 = - remove misleading sentence about incompatible QUIC versions and ALPN (b= y marten-seemann) https://github.com/quicwg/base-drafts/pull/2802 = - fix description which token to use for Initial packets (by marten-seema= nn) https://github.com/quicwg/base-drafts/pull/2800 = 9 pull requests received 26 new comments: - #2791 Receiver's behavior on key update (12 by DavidSchinazi, kazuho, m= ikkelfj) https://github.com/quicwg/base-drafts/pull/2791 [-tls] = - #2761 allow PRIORITY frames referring to placeholders exceeding `SETTIN= G_NUM_PLACEHOLDERS` (4 by kazuho, ianswett, MikeBishop) https://github.com/quicwg/base-drafts/pull/2761 [-http] = - #2803 remove outdated text about version negotiation (3 by DavidSchinaz= i, rpaulo, marten-seemann) https://github.com/quicwg/base-drafts/pull/2803 [-tls] = - #2727 Clarify the text recommending replacing CIDs when consumed (2 by = martinthomson, ianswett) https://github.com/quicwg/base-drafts/pull/2727 [-transport] [editorial= ] = - #2688 Clarify server CONNECTION_CLOSE with Handshake (1 by martinthomso= n) https://github.com/quicwg/base-drafts/pull/2688 [-transport] [editorial= ] = - #2820 Refactor Push ID related errors (1 by LPardue) https://github.com/quicwg/base-drafts/pull/2820 [-http] [design] = - #2769 Request to Retire Locally Issued CIDs (1 by erickinnear) https://github.com/quicwg/base-drafts/pull/2769 [-transport] = - #2811 Remove SETTINGS_NUM_PLACEHOLDERS (1 by LPardue) https://github.com/quicwg/base-drafts/pull/2811 = - #2813 Remove HTTP_PUSH_ALREADY_IN_CACHE error (1 by LPardue) https://github.com/quicwg/base-drafts/pull/2813 [-http] = 9 pull requests merged: - Fix verb ownership: a packet does not process packets https://github.com/quicwg/base-drafts/pull/2799 [-tls] [editorial] = - fix description which token to use for Initial packets https://github.com/quicwg/base-drafts/pull/2800 [-transport] = - Clarify the text recommending replacing CIDs when consumed https://github.com/quicwg/base-drafts/pull/2727 [-transport] [editorial= ] = - Clarify server CONNECTION_CLOSE with Handshake https://github.com/quicwg/base-drafts/pull/2688 [-transport] [editorial= ] = - Move Retry and Version Negotiation https://github.com/quicwg/base-drafts/pull/2804 [-recovery] [editorial] = - remove outdated text about version negotiation https://github.com/quicwg/base-drafts/pull/2803 [-tls] = - Clients use the same crypto handshake after Retry https://github.com/quicwg/base-drafts/pull/2746 [-transport] [editorial= ] = - Discuss max-header-list-size from the other side https://github.com/quicwg/base-drafts/pull/2774 [-http] = - Fix grammar https://github.com/quicwg/base-drafts/pull/2796 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============5328089649018189521== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 23, 2019

Issues

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

16 issues created:

11 issues received 28 new comments:

6 issues closed:

Pull requests

quicwg/base-drafts (+14/-9/=F0=9F=92=AC26)

14 pull requests submitted:

9 pull requests received 26 new comments:

9 pull requests merged:

Repositories tracked by this digest:

--===============5328089649018189521==-- From nobody Sun Jun 23 15:02:36 2019 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 DA271120108 for ; Sun, 23 Jun 2019 15:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcC75t9f3E35 for ; Sun, 23 Jun 2019 15:02:31 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCFE12001E for ; Sun, 23 Jun 2019 15:02:30 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v24so10617547ljg.13 for ; Sun, 23 Jun 2019 15:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kg+zMvMLtzpTe8SjbPjBVt11zPrpA0YKJnv7Se39HgQ=; b=Js48a8sDvKEAlnhtH8V7jvcLTb2dt9rQvdsr4u3JgBOHV2LdYRh4hXIEk4x0drb/HO h2wWGUFGXBOsrXPQhvulrguJ6IUhQkji2zp38KHq0QFDy4cvFWRtXG2IBsINWPDuT0K7 7PLXzpfHTHdRs04IXiBhK512U2dzeNxIk3XCeK7aQr+uGZV5UNb+jbOSH4IVZhhKZXK/ t1dHtyarNbKikkWupN2JlvHJod910IHflx1/+roRPoRcuip1tWlEcv/ZG4pMNmGyUCmW OWmnN0PqYkgHGM1P3xPmb6U3QwqAJQ3XJsvMsupzftnY6fF6lb2cXSwfI3/yonHRElfe kweQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kg+zMvMLtzpTe8SjbPjBVt11zPrpA0YKJnv7Se39HgQ=; b=Enzt0ZMXAVNv8tdXm2q3BwXHOnfis+uGvJs3Op3GWDmpWRHuENz/bY0jPlklq9zbER JCiKY//tLdnDUrPq3RKD2BM/f63NI3lGGNEHSgPtr71glLIRB1Vl11iYKPsDLGXZOecU E1t4iGEggHjSzIfs8c3OYmEDcKCe22qUjwhuwLvoh7kDnmuOJJ1bduT6f1m5PPs/a5fN uNij2d86YNGgf+ZetT6urOb9qDDKt0B89s/BYM85reAiu1/A8USLU6QMh5SDlb0jnHWH 4tOAMt9Q6DSSIpk0NZPYI5djFPjvlJlrQG5brMHfyj0T0J29Z6j0IvWBLpnHsODKhnoh OQGg== X-Gm-Message-State: APjAAAWxPmO/tnGuM/zmau+vaJvnkqsOppr9s+4e1R0fPiBR+TJNq0+J 0CuuTEDAe2+9DsES4MPCv1WlSEK6OmSVUKsSOTzrLQmfifQ= X-Google-Smtp-Source: APXvYqznQ8TtEfb2S5/9jvPnP5tZege7xPWxxRMx1WTx5cfq69cmfCqXRF21UWmm2y7Fq7bcpTSvoeLW+3XRfaRt6gE= X-Received: by 2002:a2e:9cd4:: with SMTP id g20mr27027358ljj.205.1561327349034; Sun, 23 Jun 2019 15:02:29 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> In-Reply-To: From: Eric Rescorla Date: Sun, 23 Jun 2019 15:01:52 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Ian Swett Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000004821a058c04dae1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 23 Jun 2019 22:02:36 -0000 --00000000000004821a058c04dae1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2019 at 1:00 PM Ian Swett wrote: > I think the 3 options I see as well reasoned are: > 1) Keep the status quo because we think we can put what we really need > into 18 bytes if we try. > 2) Change to a 1 byte length per CID and a max of 20, which gives us a fe= w > extra bytes for cleartext server id and/or key rotation/etc. > 3) Change to a 1 byte length per CID and a max of 36, because we want be > able to put 2 encrypted routing IDs in a single CID. > I would vote for (2) or (3). (1) seems presently inadvisable. -Ekr > 2 is my preferred option, though I can live with either of 1 or 3. > > Deciding sooner would be strictly better than later, since this is > blocking us(Chrome/Google) actually supporting varlen CIDs. > > On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson wrote: > >> That seems a little high. I think that Ian's principle here is what >> should guide us: what is the minimum you can handle? What I've heard is >> that 18 might have been workable, but it was REALLY close to the edge to >> the point that you weren't confident it was enough, even in the near >> term.. But that suggests that 20 is workable. >> >> On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: >> > so do I hear consensus emerging around 32B in v1, or should I leave th= e >> > 18B limit in v1 for now and punt out that discussion? >> > >> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel >> wrote: >> > > >> > > >> > > > On 18. Jun 2019, at 05:33, Marten Seemann >> wrote: >> > > > >> > > > I'd prefer keeping the "compressed 4 bits" solution, even if we >> decide to increase the connection ID length to a larger value (which I'm >> still not convinced that this is really necessary). >> > > >> > > This would be easy if we change the encoding of the connection ID >> length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While= we >> can not encode one or two byte connection IDs in long header packets, we >> can still use them in short header packets. >> > > >> > > This split between long and short header also allows to use much >> longer connection IDs after the handshake. >> > > I don=E2=80=99t see much use in it, but it may take off some fear t= hat >> 24/32/36/48/60 byte connection IDs might not be long enough in the futur= e. >> > > >> > > > >> > > > There are two main reasons to keep the compressed encoding: >> > > > =E2=80=A2 In the compressed encoding, we can reasonably expect th= at all / >> most values will be used in practice, so we won't expose any bits on the >> wire that identify a packet as "QUIC traffic" by having a predictable va= lue. >> > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an implem= entation >> still needs to be able to deal with connection ID lengths of 255 bytes, >> just to be able to send Version Negotiation packets. To me, it seems abs= urd >> to write a QUIC implementation that is able to handle packets with a >> combined connection ID overhead of 510 bytes. Since VNPs are supposed to= be >> sent in response to any Long Header packet, you'd have to put some caref= ul >> thought into the design of your data types to avoid this becoming a DoS >> vector. >> > > > >> > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema < >> huitema@huitema.net> wrote: >> > > > I too agree that using one byte in the invariant is preferable to >> the current "compressed 4 bits" solution. >> > > > >> > > > Regarding the "CID length limit", I thing there are two issues: >> transmission overhead, and costs to the community. >> > > > >> > > > I am not too concerned with the transmission overhead, as we have >> there the right mix of costs and incentives. Servers who chose to use >> longer CID will get more transmission overhead, and thus transmission le= ss >> efficiently than their competitors. They may chose to use longer CID as = a >> trade-off between transmission efficiency and ease of management. >> Competition will sort that out. I note that YouTube is apparently doing >> fine with smallish CID, so I trust that there will be competition. >> > > > >> > > > I am much more concerned with the shared costs, which are a >> variation of the "tragedy of the commons". Dmitry explained those costs >> well in a previous message. The simpler implementation is to make the >> "cid_t a fixed-size object that can fit the largest CID and eat the >> overhead for all CIDs." But each connection object carries a large numbe= r >> of instances of the CID type. Having a very large max CID would imply a >> large overhead. The alternative is to "Make cid_t a variable-size object= ", >> but too affects performance. >> > > > >> > > > Hence the push-back. I would personally prefer a max size of 16, >> and I think that 32 is the highest practical limit. >> > > > >> > > > -- Christian Huitema >> > > > >> > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: >> > > >> What I think people are saying so far: >> > > >> >> > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, o= r >> 48} >> > > >> >> > > >> 2) Representation of CID length as a byte is still OK, thus a >> QUIC v2 could use longer CIDs as needed by changing the spec while keepi= ng >> the invariants=E2=80=A6 invariant. >> > > >> >> > > >> >> > > >> That seems reasonable to me / I=E2=80=99d still support that. >> > > >> >> > > >> -=3DR >> > > >> >> > > >> >> > > >> From: QUIC > on >> behalf of "Lubashev, Igor" >> > > >> Date: Monday, June 17, 2019 at 8:55 AM >> > > >> To: Ian Swett , Mikkel >> Fahn=C3=B8e J=C3=B8rgensen >> > > >> Cc: Dmitri Tikhonov , Christian >> Huitema , "Philipp S. Tiesel" , >> Mike Bishop , Martin Thomson , >> Marten Seemann , Lars Eggert , >> QUIC WG , Martin Duke > martin..h.duke@gmail.com>>, Kazuho Oku >> > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 >> > > >> >> > > >> >> > > >> >> > > >> My take is similar =E2=80=93 48 is probably excessive, while 32 = is likely >> the upper limit of =E2=80=9Creasonable=E2=80=9D (it should probably be a= factor of 8, so 32 >> or 24?). >> > > >> >> > > >> >> > > >> >> > > >> We are firmly committed for using CID for in-cluster load >> balancing / anycast pop routing. This discussion is taking us, however, = to >> a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled = routing in an >> overlay network=E2=80=9D. This is a very interesting topic, but I would = hesitate to >> attempt to solve it fully and =E2=80=9Cin general=E2=80=9D in QUIC v1. >> > > >> >> > > >> >> > > >> >> > > >> =E2=80=A2 Igor >> > > >> >> > > >> >> > > >> From: Ian Swett >> > > >> >> > > >> My intuition says making the change to the invariants is the >> right thing to do, but I don't feel that strongly. >> > > >> >> > > >> >> > > >> >> > > >> However, I'd like the max size to be smaller than 48(but larger >> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho >> suggested 32, which is better, but I don't believe the server needs to u= se >> a separate block cipher when giving out connection IDs, because I believ= e >> it's impractical for the load balancer and server to be that decoupled. = The >> server has to give out a CID that the load balancer will use to route ba= ck >> to the server, so they have to share enough an encryption key/algorithm.= I >> can imagine nesting load balancers, but that's well in the range of QUIC= v2 >> from my perspective. >> > > >> >> > > >> >> > > >> >> > > >> Whatever we do, I'd really prefer to resolve this sooner rather >> than later and be truly done with it. >> > > >> >> > > >> >> > > >> >> > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgense= n < >> mikkelfj@gmail.com> wrote: >> > > >> >> > > >> Since it is more likely that you pay for egress traffic than >> ingress traffic, the motivation to keep CID=E2=80=99s small is limited. >> > > >> >> > > >> >> > > >> >> > > >> I do think the invariants should allow for long CID=E2=80=99s as >> proposed, and that the long header overhead is not important.. >> > > >> >> > > >> >> > > >> >> > > >> But for QUIC v1, if we allow for a long CID, a rush to market >> will set precedence and long CID=E2=80=99s will ossify in all kinds of s= tacks. >> > > >> >> > > >> >> > > >> >> > > >> I good reference on an algorithm like suggested by Christian >> would go a long way. >> > > >> >> > > >> >> > > >> >> > > >> If CID length 18 turns out to be not enough, we can add a QUIC >> v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC= versions >> soon. >> > > >> >> > > >> >> > > >> >> > > >> If CID length negotiation is needed, this could be done via QUIC >> versions. For example two functionally equivalent versions, but one with >> longer CID=E2=80=99s. This would also allow routers to deal with changes= in CID >> lengths. A negotiated TP would not (easily) allow for that and aside I d= o >> not think CID length in TP is the way to go. >> > > >> >> > > >> >> > > >> >> > > >> Mikkel >> > > >> >> > > >> >> > > >> >> > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) >> wrote: >> > > >> >> > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian Hu= itema : >> > > >> > >> > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote: >> > > >> > >> > > >> > > _If_ we are to allow loose coupling between a load balancer >> and a >> > > >> > > server, each of the two should be given the freedom to choos= e >> it's own >> > > >> > > CID encryption scheme. Because all the standardized block >> ciphers are >> > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the >> maximum CID >> > > >> > > length of QUIC needs to be double amount of that, plus one o= r >> two >> > > >> > > bytes for each of the two for identifying the CID encryption >> keys. For >> > > >> > > key identification and other supplemental use, we currently >> allocate 2 >> > > >> > > bytes (18-16=3D2). >> > > >> > >> > > >> > That reasoning is based on the assumption that both the load >> balancer >> > > >> > and the server must use a block cipher with 128 bit block >> length in >> > > >> > order to encrypt the CID. If they were constrained to stay >> within a >> > > >> > short global limit, they could use different sets of >> algorithms. >> > > >> > >> > > >> > Assume for example that we split the CID between 32 bits >> encoding the >> > > >> > number of the server in the server farm, and 64 bit encoding >> the >> > > >> > connection number for the server. The server can pick a random >> value for >> > > >> > the connection number, and use a hash table. The load balancer >> could use >> > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 bit >> of the CID >> > > >> > as an initial vector. Voila, 96 CID, with demonstrably strong >> encryption. >> > > >> > >> > > >> > Or assume that the server wants to use short CID. We now split >> the CID >> > > >> > between 32 bit for the server number in the farm, and 32 bit >> for the >> > > >> > connection number in the server. The server builds that >> connection >> > > >> > number by using a 32 bit variant of FFX. The load balancer als= o >> uses a >> > > >> > 32 bit variant, using the lower 32 bit of the CID as initial >> vector for >> > > >> > this FFX encryption. >> > > >> > >> > > >> > These are just two examples. And yes you may want to add 2 >> bytes for key >> > > >> > identification, etc. In both encryption algorithms, you can >> feed these >> > > >> > two bytes as additional IV for the FFX algorithm. And in both >> cases, we >> > > >> > are well below the 18 byte limit. >> > > >> > >> > > >> > Yes, that requires some creative engineering. But it is not >> rocker >> > > >> > science. And it seems better than carrying tons of overhead in >> the >> > > >> > header, and becoming less efficient than HTTP2/TLS/TCP. >> > > >> >> > > >> I agree that it would not be the end of the world for the load >> > > >> balancers if we decide to stick on the 18-byte limit. However, a= s >> you >> > > >> state, it requires some creativeness. >> > > >> >> > > >> To me it seems that the question is if we have a strong reason t= o >> > > >> require some people to be creative, for all the versions of QUIC >> in >> > > >> the future. I personally think that there isn't a strong reason, >> > > >> because people can use shorter CIDs regardless of the decision w= e >> > > >> make. IIUC, the overhead that everyone needs to accept is: >> > > >> >> > > >> * one byte increase in the long header packets >> > > >> * the minimum size of short header packets becoming slightly >> greater >> > > >> (otherwise, the peer might not be able to send a stateless reset= ) >> > > >> >> > > >> I'd say that the first bullet point is negligible. The second >> point >> > > >> could also be, because I'd assume that the only frequently-sent >> > > >> packets that require additional padding is the ACK-only packets, >> but >> > > >> there's no reason to pad ACK-only packets in hope that you'd see >> a >> > > >> stateless reset. >> > > >> >> > > >> Therefore, my (not-so-strong) preference has been to provide >> extra >> > > >> room, so that some people with necessity can use longer CIDs. >> > > >> >> > > >> > >> > > >> > -- Christian Huitema >> > > >> > >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> Kazuho Oku >> > > >> >> > > >> > > AVE! >> > > Philipp S. Tiesel >> > > >> > > -- >> > > Philipp S. Tiesel >> > > https://philipp.tiesel.net/ >> > > >> >> --00000000000004821a058c04dae1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jun 21, 2019 at 1:00 PM Ian S= wett <ianswett=3D40google= .com@dmarc.ietf.org> wrote:
I think the 3 options I see as well rea= soned are:
1) Keep the status quo because we think we can put what we r= eally need into 18 bytes if we try.
2) Change to a 1 byte length = per CID and a max of 20, which gives us a few extra bytes for cleartext ser= ver id and/or key rotation/etc.
3) Change to a 1 byte length per = CID and a max of 36, because we want be able to put 2 encrypted routing IDs= in a single CID.

I would vote = for (2) or (3). (1) seems presently inadvisable.

-= Ekr

<= div dir=3D"ltr">

2 is my preferred option, though I can = live with either of 1 or 3.

Deciding sooner would = be strictly better than later, since this is blocking us(Chrome/Google) act= ually supporting varlen CIDs.

On Thu, Jun 20, 2019 at 2:57 PM Martin T= homson <mt@lowent= ropy.net> wrote:
That seems a little high.=C2=A0 I think that Ian's principle he= re is what should guide us: what is the minimum you can handle?=C2=A0 What = I've heard is that 18 might have been workable, but it was REALLY close= to the edge to the point that you weren't confident it was enough, eve= n in the near term..=C2=A0 But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave th= e
> 18B limit in v1 for now and punt out that discussion?
>
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <philipp@tiesel.net> wrote: > >
> >
> >=C2=A0 > On 18. Jun 2019, at 05:33, Marten Seemann <martenseemann@gmail.c= om> wrote:
> >=C2=A0 >
> >=C2=A0 > I'd prefer keeping the "compressed 4 bits&quo= t; solution, even if we decide to increase the connection ID length to a la= rger value (which I'm still not convinced that this is really necessary= ).
> >
> >=C2=A0 This would be easy if we change the encoding of the connect= ion ID length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. W= hile we can not encode one or two byte connection IDs in long header packet= s, we can still use them in short header packets.
> >
> >=C2=A0 This split between long and short header also allows to use= much longer connection IDs after the handshake.
> >=C2=A0 I don=E2=80=99t see much use in it, but it may take off som= e fear that 24/32/36/48/60 byte connection IDs might not be long enough in = the future.
> >
> >=C2=A0 >
> >=C2=A0 > There are two main reasons to keep the compressed enco= ding:
> >=C2=A0 > =E2=80=A2 In the compressed encoding, we can reasonabl= y expect that all / most values will be used in practice, so we won't e= xpose any bits on the wire that identify a packet as "QUIC traffic&quo= t; by having a predictable value.
> >=C2=A0 > =E2=80=A2 The 1-byte encoding has the disadvantage tha= t an implementation still needs to be able to deal with connection ID lengt= hs of 255 bytes, just to be able to send Version Negotiation packets. To me= , it seems absurd to write a QUIC implementation that is able to handle pac= kets with a combined connection ID overhead of 510 bytes. Since VNPs are su= pposed to be sent in response to any Long Header packet, you'd have to = put some careful thought into the design of your data types to avoid this b= ecoming a DoS vector.
> >=C2=A0 >
> >=C2=A0 > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <= huitema@huitema.ne= t> wrote:
> >=C2=A0 > I too agree that using one byte in the invariant is pr= eferable to the current "compressed 4 bits" solution.
> >=C2=A0 >
> >=C2=A0 > Regarding the "CID length limit", I thing th= ere are two issues: transmission overhead, and costs to the community.
> >=C2=A0 >
> >=C2=A0 > I am not too concerned with the transmission overhead,= as we have there the right mix of costs and incentives. Servers who chose = to use longer CID will get more transmission overhead, and thus transmissio= n less efficiently than their competitors. They may chose to use longer CID= as a trade-off between transmission efficiency and ease of management. Com= petition will sort that out. I note that YouTube is apparently doing fine w= ith smallish CID, so I trust that there will be competition.
> >=C2=A0 >
> >=C2=A0 > I am much more concerned with the shared costs, which = are a variation of the "tragedy of the commons". Dmitry explained= those costs well in a previous message. The simpler implementation is to m= ake the "cid_t a fixed-size object that can fit the largest CID and ea= t the overhead for all CIDs." But each connection object carries a lar= ge number of instances of the CID type. Having a very large max CID would i= mply a large overhead. The alternative is to "Make cid_t a variable-si= ze object", but too affects performance.
> >=C2=A0 >
> >=C2=A0 > Hence the push-back. I would personally prefer a max s= ize of 16, and I think that 32 is the highest practical limit.
> >=C2=A0 >
> >=C2=A0 > -- Christian Huitema
> >=C2=A0 >
> >=C2=A0 > On 6/17/2019 9:16 AM, Roberto Peon wrote:
> >=C2=A0 >> What I think people are saying so far:
> >=C2=A0 >>
> >=C2=A0 >> 1) QUIC v1 would limit CID length to something one= of {32, 36, or 48}
> >=C2=A0 >>
> >=C2=A0 >> 2) Representation of CID length as a byte is still= OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec wh= ile keeping the invariants=E2=80=A6 invariant.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> That seems reasonable to me / I=E2=80=99d still su= pport that.
> >=C2=A0 >>
> >=C2=A0 >> -=3DR
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: QUIC <quic-bounces@ietf.org> on behalf of "L= ubashev, Igor" <ilubashe@akamai.com>
> >=C2=A0 >> Date: Monday, June 17, 2019 at 8:55 AM
> >=C2=A0 >> To: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org= >, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> >=C2=A0 >> Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>,= Christian Huitema <huitema@huitema.net>, "Philipp S. Tiesel" <philipp@tiesel.net>= , Mike Bishop <mbishop@evequefou.be>, Martin Thomson <mt@lowentropy.net>, Marten Seemann <= ;martenseemann= @gmail.com>, Lars Eggert <lars@eggert.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.c= om <mailto:martin..h.duke@gmail.com>>, Kazuho Oku <kazuhooku@gmail.com>
> >=C2=A0 >> Subject: RE: Consensus Call: More Connection ID Sp= ace #2736
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> My take is similar =E2=80=93 48 is probably excess= ive, while 32 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it= should probably be a factor of 8, so 32 or 24?).
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> We are firmly committed for using CID for in-clust= er load balancing / anycast pop routing. This discussion is taking us, howe= ver, to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-contro= lled routing in an overlay network=E2=80=9D. This is a very interesting top= ic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin gener= al=E2=80=9D in QUIC v1.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> =E2=80=A2 Igor
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> From: Ian Swett <ianswett=3D40google.com@dmarc.ietf.org>
> >=C2=A0 >>
> >=C2=A0 >> My intuition says making the change to the invaria= nts is the right thing to do, but I don't feel that strongly.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> However, I'd like the max size to be smaller t= han 48(but larger than 18). If we think 20 or 24 is sufficient, I'd pre= fer that. Kazuho suggested 32, which is better, but I don't believe the= server needs to use a separate block cipher when giving out connection IDs= , because I believe it's impractical for the load balancer and server t= o be that decoupled. The server has to give out a CID that the load balance= r will use to route back to the server, so they have to share enough an enc= ryption key/algorithm. I can imagine nesting load balancers, but that's= well in the range of QUIC v2 from my perspective.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Whatever we do, I'd really prefer to resolve t= his sooner rather than later and be truly done with it.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e= J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
> >=C2=A0 >>
> >=C2=A0 >> Since it is more likely that you pay for egress tr= affic than ingress traffic, the motivation to keep CID=E2=80=99s small is l= imited.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I do think the invariants should allow for long CI= D=E2=80=99s as proposed, and that the long header overhead is not important= ..
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> But for QUIC v1, if we allow for a long CID, a rus= h to market will set precedence and long CID=E2=80=99s will ossify in all k= inds of stacks.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> I good reference on an algorithm like suggested by= Christian would go a long way.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length 18 turns out to be not enough, we ca= n add a QUIC v2. It=E2=80=99s not like we are not looking for excuses to up= grade QUIC versions soon.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> If CID length negotiation is needed, this could be= done via QUIC versions. For example two functionally equivalent versions, = but one with longer CID=E2=80=99s. This would also allow routers to deal wi= th changes in CID lengths. A negotiated TP would not (easily) allow for tha= t and aside I do not think CID length in TP is the way to go.
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> Mikkel
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) = wrote:
> >=C2=A0 >>
> >=C2=A0 >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:0= 9 Christian Huitema <huitema@huitema.net>:
> >=C2=A0 >> >
> >=C2=A0 >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:
> >=C2=A0 >> >
> >=C2=A0 >> > > _If_ we are to allow loose coupling betw= een a load balancer and a
> >=C2=A0 >> > > server, each of the two should be given = the freedom to choose it's own
> >=C2=A0 >> > > CID encryption scheme. Because all the s= tandardized block ciphers are
> >=C2=A0 >> > > now 128-bits (=3D 16 bytes), that natura= lly means that the maximum CID
> >=C2=A0 >> > > length of QUIC needs to be double amount= of that, plus one or two
> >=C2=A0 >> > > bytes for each of the two for identifyin= g the CID encryption keys. For
> >=C2=A0 >> > > key identification and other supplementa= l use, we currently allocate 2
> >=C2=A0 >> > > bytes (18-16=3D2).
> >=C2=A0 >> >
> >=C2=A0 >> > That reasoning is based on the assumption tha= t both the load balancer
> >=C2=A0 >> > and the server must use a block cipher with 1= 28 bit block length in
> >=C2=A0 >> > order to encrypt the CID. If they were constr= ained to stay within a
> >=C2=A0 >> > short global limit, they could use different = sets of algorithms.
> >=C2=A0 >> >
> >=C2=A0 >> > Assume for example that we split the CID betw= een 32 bits encoding the
> >=C2=A0 >> > number of the server in the server farm, and = 64 bit encoding the
> >=C2=A0 >> > connection number for the server. The server = can pick a random value for
> >=C2=A0 >> > the connection number, and use a hash table. = The load balancer could use
> >=C2=A0 >> > a 32 bit variant of the FFX algorithm, using = the lower 64 bit of the CID
> >=C2=A0 >> > as an initial vector. Voila, 96 CID, with dem= onstrably strong encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > Or assume that the server wants to use short = CID. We now split the CID
> >=C2=A0 >> > between 32 bit for the server number in the f= arm, and 32 bit for the
> >=C2=A0 >> > connection number in the server. The server b= uilds that connection
> >=C2=A0 >> > number by using a 32 bit variant of FFX. The = load balancer also uses a
> >=C2=A0 >> > 32 bit variant, using the lower 32 bit of the= CID as initial vector for
> >=C2=A0 >> > this FFX encryption.
> >=C2=A0 >> >
> >=C2=A0 >> > These are just two examples. And yes you may = want to add 2 bytes for key
> >=C2=A0 >> > identification, etc. In both encryption algor= ithms, you can feed these
> >=C2=A0 >> > two bytes as additional IV for the FFX algori= thm. And in both cases, we
> >=C2=A0 >> > are well below the 18 byte limit.
> >=C2=A0 >> >
> >=C2=A0 >> > Yes, that requires some creative engineering.= But it is not rocker
> >=C2=A0 >> > science. And it seems better than carrying to= ns of overhead in the
> >=C2=A0 >> > header, and becoming less efficient than HTTP= 2/TLS/TCP.
> >=C2=A0 >>
> >=C2=A0 >> I agree that it would not be the end of the world = for the load
> >=C2=A0 >> balancers if we decide to stick on the 18-byte lim= it. However, as you
> >=C2=A0 >> state, it requires some creativeness.
> >=C2=A0 >>
> >=C2=A0 >> To me it seems that the question is if we have a s= trong reason to
> >=C2=A0 >> require some people to be creative, for all the ve= rsions of QUIC in
> >=C2=A0 >> the future. I personally think that there isn'= t a strong reason,
> >=C2=A0 >> because people can use shorter CIDs regardless of = the decision we
> >=C2=A0 >> make. IIUC, the overhead that everyone needs to ac= cept is:
> >=C2=A0 >>
> >=C2=A0 >> * one byte increase in the long header packets > >=C2=A0 >> * the minimum size of short header packets becomin= g slightly greater
> >=C2=A0 >> (otherwise, the peer might not be able to send a s= tateless reset)
> >=C2=A0 >>
> >=C2=A0 >> I'd say that the first bullet point is negligi= ble. The second point
> >=C2=A0 >> could also be, because I'd assume that the onl= y frequently-sent
> >=C2=A0 >> packets that require additional padding is the ACK= -only packets, but
> >=C2=A0 >> there's no reason to pad ACK-only packets in h= ope that you'd see a
> >=C2=A0 >> stateless reset.
> >=C2=A0 >>
> >=C2=A0 >> Therefore, my (not-so-strong) preference has been = to provide extra
> >=C2=A0 >> room, so that some people with necessity can use l= onger CIDs.
> >=C2=A0 >>
> >=C2=A0 >> >
> >=C2=A0 >> > -- Christian Huitema
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >> >
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >>
> >=C2=A0 >> --
> >=C2=A0 >> Kazuho Oku
> >=C2=A0 >>
> >
> >=C2=A0 AVE!
> >=C2=A0 Philipp S. Tiesel
> >
> >=C2=A0 --
> >=C2=A0 Philipp S. Tiesel
> > https://philipp.tiesel.net/
> >

--00000000000004821a058c04dae1-- From nobody Sun Jun 23 19:44:24 2019 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 60DBC120019 for ; Sun, 23 Jun 2019 19:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=eBCUY0Mn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZMWAiW3O 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 RiRoFUzWysfA for ; Sun, 23 Jun 2019 19:44:19 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73157120282 for ; Sun, 23 Jun 2019 19:44:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7391C22011; Sun, 23 Jun 2019 22:44:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 23 Jun 2019 22:44:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=B DsXhym/8zZBPuWTVs0xjQgq1PRvedtKQApae/vgkuo=; b=eBCUY0MnacYDhQmGe BzOYYW88Q9Aucjo/mTQWugKxaX6lht9wRdJoQ1aZ0PjsZ+RGgN/mkDel23RLbl6g aWVNXU7bRBAqBS82e9zxSlqvOYZI+DiLllwKYzLCmDsaLoHnMsRxOxNuthCG8FYI 3+LWx+BaCguPzW7NQUuRpx03PZPxfHDO9O89hvcVL53pLU5PFCoa66UDHawaNxEL gHnX9o3HIglD/MnmVWtj18nnVrbgrB9oiu7WX4oWG/NPSIkuciVNot7U5agBI4+S 7fODt921gGzJLJPRUYbU3l4/Z67+2o8bWvVq9+yYYpeDAOxlKF09nYRWr/qFcMQv TzZFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=BDsXhym/8zZBPuWTVs0xjQgq1PRvedtKQApae/vgk uo=; b=ZMWAiW3O5QqoJYcebJBGRRblXz6CZxPD1osNL4hrMXYGtXMG6go2bEn7z 9y2WHV23CSv+sZehu7CeLwyK3T89zJP7xPw04gbdq6jZ5f2rF+Q2+2XCRyDqf44n BDJBg8Y2OsEbYTxsHq4o5hC92XV2c99cTOswxq1b+i5yWumCI5RVkGAFQfnSoUL1 dL4T5IwZA+Is41xzdlAKHZu8IWMcmOb4antVxiyoU3VaY+3nvMoK182xh8LohxKd bgle7kyOSXbiXR8WcD1Gd97uDINpd1dvSzHe1V07PMR7uciQ4coeBUiWuTJ8pku6 wrZnL5jJpOLMa6wqRopx5WZ6DfiYA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddugdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeeh rddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 35DFA8005C; Sun, 23 Jun 2019 22:44:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Call: More Connection ID Space #2736 From: Mark Nottingham In-Reply-To: Date: Mon, 24 Jun 2019 12:44:11 +1000 Cc: QUIC IETF mailing list , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <46035944-B522-47D1-A572-509BEC8DFC0B@mnot.net> References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 02:44:22 -0000 Hi Ted, It looks like we're gravitating towards 20 bits (in QUICv1) -- if that's = where we end up, is this still something you'd like to see resolved = first? Cheers, > On 13 Jun 2019, at 2:16 am, Ted Hardie wrote: >=20 > Hi Mark, >=20 > https://github.com/quicwg/base-drafts/issues/2770 was raised in part = because of this change, and it is not resolved. While I do not expect = that it will cause a reversion of this design theory, it might be useful = to wait on declaring consensus for this until it resolves, in case the = resolution suggests a limit change. >=20 > Could we encourage folks to test with the higher limits and new = encoding for now, but not close the issue? >=20 > regards, >=20 > Ted >=20 > On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham = wrote: > Regarding: > >=20 > The editors believe that this PR resolved the issue: > >=20 > .....and discussion so far seems to support consensus to do so. If you = object, please do so on the issue or in response to this message; absent = any pushback, we'll declare consensus at the end of the week. >=20 > Regards, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jun 23 19:44:32 2019 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 5CC5612029D for ; Sun, 23 Jun 2019 19:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZRZFxj0h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J1zo2bs4 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 kYL-tKfvlt8l for ; Sun, 23 Jun 2019 19:44:22 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8953B120286 for ; Sun, 23 Jun 2019 19:44:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B1C01215B2; Sun, 23 Jun 2019 22:44:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 23 Jun 2019 22:44:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=w NsOhbf0VhrWl/PJKWMYxYTqmAkZMLkNblV6tRIiUsw=; b=ZRZFxj0hpRU0qnWrg l+UfqD4ANE0hP0MF1Ko5kbakciPv5rZNfKI8qV7skje01I5VyqoGZ6AkGm4PBGUW dO9bWqvfS7rpMhgNa1TYDxNF4c/mjs5rjGEZ+Soqwv0Wn/AGtSSBDbQpRVN0DHRJ RGVUUqtQrr9za5i95j028sAjRF6/1xEO8IWODd21nE7c3tQjF/YWO6xKuagW5fJC X802wIPsMyiVkzYLLv1ixJWdnxcDk8EHhtmjJUAXbPm1jgYu5jaCMlkSYizUE2J+ SB9PVoe5R2CgU0ybumlwzt2nIkiB/ah4Gk6jZuYlXpWzOM16ruVOSJ/zCzjKT+cw EMkow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=wNsOhbf0VhrWl/PJKWMYxYTqmAkZMLkNblV6tRIiU sw=; b=J1zo2bs4HRGtfDIdcZwogJvaKyyLqA3OX3L1X5i9jb5NNbqffG45Zvh/Z Jqrsnf99Yuj1Iz3uAc5qx6SznZyR+P4/HtHzeRYPszp9CoXwjdVLJdQTSwrvljmc om1GZiG6CE8Fhxcs5eSIDA/13tlqVmFR7NEJeIbmLA1OJ3pef8AJ/nTTJ1Z/fFnB b7oEctJqJ0lpw32XzF0Q86rFE8Z7c9x0TwUPW5uu3oqXUI7CshpTN9HEF2PiIDFB 6XWDmJjcY+vCDRLz+hazm6CMk7PO+ORLZLm3uIIzrKvZ89RFs6r4dCS0XoBFLl7x 8Xa/1PDdhhX8hZjI6QLh+9nSCILuQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddugdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe htihgvshgvlhdrnhgvthdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeeh rddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 2423880062; Sun, 23 Jun 2019 22:44:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Consensus Call: More Connection ID Space #2736 From: Mark Nottingham In-Reply-To: Date: Mon, 24 Jun 2019 12:44:16 +1000 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <506087CE-E1B7-45D3-8E9B-07FC1BC5A53B@eggert.org> <51831915-F209-4C8B-ACEF-AEF768FF0DBB@huitema.net> <20190613175443.GA23884@ubuntu-dmitri> <8FC33E94-A321-4051-93F0-68B9228AAA31@tiesel.net> <71B594CE-E83C-4F62-8FD3-135A297C548D@tiesel.net> <91E94F47-B6D2-4746-994A-15B84578B174@fb.com> <7ddac4e8-3208-69a2-c72c-b12c43d9b078@huitema.net> <629AD231-7AE4-426D-84FE-DC8823AD565F@tiesel.net> To: Martin Duke X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 24 Jun 2019 02:44:26 -0000 It seems like we have a fair number of people who prefer (2), and no one = who strongly objects. MartinD, can you go ahead and revise your PR? Then we can try another = consensus call. Cheers, > On 24 Jun 2019, at 8:01 am, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Jun 21, 2019 at 1:00 PM Ian Swett = wrote: > I think the 3 options I see as well reasoned are: > 1) Keep the status quo because we think we can put what we really need = into 18 bytes if we try. > 2) Change to a 1 byte length per CID and a max of 20, which gives us a = few extra bytes for cleartext server id and/or key rotation/etc. > 3) Change to a 1 byte length per CID and a max of 36, because we want = be able to put 2 encrypted routing IDs in a single CID. >=20 > I would vote for (2) or (3). (1) seems presently inadvisable. >=20 > -Ekr >=20 >=20 > 2 is my preferred option, though I can live with either of 1 or 3. >=20 > Deciding sooner would be strictly better than later, since this is = blocking us(Chrome/Google) actually supporting varlen CIDs. >=20 > On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson = wrote: > That seems a little high. I think that Ian's principle here is what = should guide us: what is the minimum you can handle? What I've heard is = that 18 might have been workable, but it was REALLY close to the edge to = the point that you weren't confident it was enough, even in the near = term.. But that suggests that 20 is workable. >=20 > On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote: > > so do I hear consensus emerging around 32B in v1, or should I leave = the=20 > > 18B limit in v1 for now and punt out that discussion? > >=20 > > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel = wrote: > > >=20 > > >=20 > > > > On 18. Jun 2019, at 05:33, Marten Seemann = wrote: > > > >=20 > > > > I'd prefer keeping the "compressed 4 bits" solution, even if we = decide to increase the connection ID length to a larger value (which I'm = still not convinced that this is really necessary). > > >=20 > > > This would be easy if we change the encoding of the connection ID = length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While = we can not encode one or two byte connection IDs in long header packets, = we can still use them in short header packets. > > >=20 > > > This split between long and short header also allows to use much = longer connection IDs after the handshake. > > > I don=E2=80=99t see much use in it, but it may take off some fear = that 24/32/36/48/60 byte connection IDs might not be long enough in the = future. > > >=20 > > > >=20 > > > > There are two main reasons to keep the compressed encoding: > > > > =E2=80=A2 In the compressed encoding, we can reasonably expect = that all / most values will be used in practice, so we won't expose any = bits on the wire that identify a packet as "QUIC traffic" by having a = predictable value. > > > > =E2=80=A2 The 1-byte encoding has the disadvantage that an = implementation still needs to be able to deal with connection ID lengths = of 255 bytes, just to be able to send Version Negotiation packets. To = me, it seems absurd to write a QUIC implementation that is able to = handle packets with a combined connection ID overhead of 510 bytes. = Since VNPs are supposed to be sent in response to any Long Header = packet, you'd have to put some careful thought into the design of your = data types to avoid this becoming a DoS vector. > > > >=20 > > > > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema = wrote: > > > > I too agree that using one byte in the invariant is preferable = to the current "compressed 4 bits" solution. > > > >=20 > > > > Regarding the "CID length limit", I thing there are two issues: = transmission overhead, and costs to the community. > > > >=20 > > > > I am not too concerned with the transmission overhead, as we = have there the right mix of costs and incentives. Servers who chose to = use longer CID will get more transmission overhead, and thus = transmission less efficiently than their competitors. They may chose to = use longer CID as a trade-off between transmission efficiency and ease = of management. Competition will sort that out. I note that YouTube is = apparently doing fine with smallish CID, so I trust that there will be = competition. > > > >=20 > > > > I am much more concerned with the shared costs, which are a = variation of the "tragedy of the commons". Dmitry explained those costs = well in a previous message. The simpler implementation is to make the = "cid_t a fixed-size object that can fit the largest CID and eat the = overhead for all CIDs." But each connection object carries a large = number of instances of the CID type. Having a very large max CID would = imply a large overhead. The alternative is to "Make cid_t a = variable-size object", but too affects performance. > > > >=20 > > > > Hence the push-back. I would personally prefer a max size of = 16, and I think that 32 is the highest practical limit. > > > >=20 > > > > -- Christian Huitema > > > >=20 > > > > On 6/17/2019 9:16 AM, Roberto Peon wrote: > > > >> What I think people are saying so far: > > > >>=20 > > > >> 1) QUIC v1 would limit CID length to something one of {32, 36, = or 48} > > > >>=20 > > > >> 2) Representation of CID length as a byte is still OK, thus a = QUIC v2 could use longer CIDs as needed by changing the spec while = keeping the invariants=E2=80=A6 invariant. > > > >>=20 > > > >>=20 > > > >> That seems reasonable to me / I=E2=80=99d still support that. > > > >>=20 > > > >> -=3DR > > > >>=20 > > > >>=20 > > > >> From: QUIC on behalf of "Lubashev, = Igor" > > > >> Date: Monday, June 17, 2019 at 8:55 AM > > > >> To: Ian Swett , Mikkel = Fahn=C3=B8e J=C3=B8rgensen > > > >> Cc: Dmitri Tikhonov , Christian = Huitema , "Philipp S. Tiesel" , = Mike Bishop , Martin Thomson , = Marten Seemann , Lars Eggert , = QUIC WG , Martin Duke >, Kazuho Oku > > > >> Subject: RE: Consensus Call: More Connection ID Space #2736 > > > >>=20 > > > >>=20 > > > >>=20 > > > >> My take is similar =E2=80=93 48 is probably excessive, while = 32 is likely the upper limit of =E2=80=9Creasonable=E2=80=9D (it should = probably be a factor of 8, so 32 or 24?). > > > >>=20 > > > >>=20 > > > >>=20 > > > >> We are firmly committed for using CID for in-cluster load = balancing / anycast pop routing. This discussion is taking us, however, = to a new territory =E2=80=93 a generalized =E2=80=9Cdestination-controlled= routing in an overlay network=E2=80=9D. This is a very interesting = topic, but I would hesitate to attempt to solve it fully and =E2=80=9Cin = general=E2=80=9D in QUIC v1. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> =E2=80=A2 Igor > > > >>=20 > > > >>=20 > > > >> From: Ian Swett > > > >>=20 > > > >> My intuition says making the change to the invariants is the = right thing to do, but I don't feel that strongly. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> However, I'd like the max size to be smaller than 48(but = larger than 18). If we think 20 or 24 is sufficient, I'd prefer that. = Kazuho suggested 32, which is better, but I don't believe the server = needs to use a separate block cipher when giving out connection IDs, = because I believe it's impractical for the load balancer and server to = be that decoupled. The server has to give out a CID that the load = balancer will use to route back to the server, so they have to share = enough an encryption key/algorithm. I can imagine nesting load = balancers, but that's well in the range of QUIC v2 from my perspective. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> Whatever we do, I'd really prefer to resolve this sooner = rather than later and be truly done with it. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahn=C3=B8e J=C3=B8rgense= n wrote: > > > >>=20 > > > >> Since it is more likely that you pay for egress traffic than = ingress traffic, the motivation to keep CID=E2=80=99s small is limited. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> I do think the invariants should allow for long CID=E2=80=99s = as proposed, and that the long header overhead is not important... > > > >>=20 > > > >>=20 > > > >>=20 > > > >> But for QUIC v1, if we allow for a long CID, a rush to market = will set precedence and long CID=E2=80=99s will ossify in all kinds of = stacks. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> I good reference on an algorithm like suggested by Christian = would go a long way. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> If CID length 18 turns out to be not enough, we can add a QUIC = v2. It=E2=80=99s not like we are not looking for excuses to upgrade QUIC = versions soon. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> If CID length negotiation is needed, this could be done via = QUIC versions. For example two functionally equivalent versions, but one = with longer CID=E2=80=99s. This would also allow routers to deal with = changes in CID lengths. A negotiated TP would not (easily) allow for = that and aside I do not think CID length in TP is the way to go. > > > >>=20 > > > >>=20 > > > >>=20 > > > >> Mikkel > > > >>=20 > > > >>=20 > > > >>=20 > > > >> On 17 June 2019 at 06.45.04, Kazuho Oku (kazuhooku@gmail.com) = wrote: > > > >>=20 > > > >> 2019=E5=B9=B46=E6=9C=8817=E6=97=A5(=E6=9C=88) 11:09 Christian = Huitema :=20 > > > >> >=20 > > > >> > On 6/15/2019 10:55 PM, Kazuho Oku wrote:=20 > > > >> >=20 > > > >> > > _If_ we are to allow loose coupling between a load = balancer and a=20 > > > >> > > server, each of the two should be given the freedom to = choose it's own=20 > > > >> > > CID encryption scheme. Because all the standardized block = ciphers are=20 > > > >> > > now 128-bits (=3D 16 bytes), that naturally means that the = maximum CID=20 > > > >> > > length of QUIC needs to be double amount of that, plus one = or two=20 > > > >> > > bytes for each of the two for identifying the CID = encryption keys. For=20 > > > >> > > key identification and other supplemental use, we = currently allocate 2=20 > > > >> > > bytes (18-16=3D2).=20 > > > >> >=20 > > > >> > That reasoning is based on the assumption that both the load = balancer=20 > > > >> > and the server must use a block cipher with 128 bit block = length in=20 > > > >> > order to encrypt the CID. If they were constrained to stay = within a=20 > > > >> > short global limit, they could use different sets of = algorithms.=20 > > > >> >=20 > > > >> > Assume for example that we split the CID between 32 bits = encoding the=20 > > > >> > number of the server in the server farm, and 64 bit encoding = the=20 > > > >> > connection number for the server. The server can pick a = random value for=20 > > > >> > the connection number, and use a hash table. The load = balancer could use=20 > > > >> > a 32 bit variant of the FFX algorithm, using the lower 64 = bit of the CID=20 > > > >> > as an initial vector. Voila, 96 CID, with demonstrably = strong encryption.=20 > > > >> >=20 > > > >> > Or assume that the server wants to use short CID. We now = split the CID=20 > > > >> > between 32 bit for the server number in the farm, and 32 bit = for the=20 > > > >> > connection number in the server. The server builds that = connection=20 > > > >> > number by using a 32 bit variant of FFX. The load balancer = also uses a=20 > > > >> > 32 bit variant, using the lower 32 bit of the CID as initial = vector for=20 > > > >> > this FFX encryption.=20 > > > >> >=20 > > > >> > These are just two examples. And yes you may want to add 2 = bytes for key=20 > > > >> > identification, etc. In both encryption algorithms, you can = feed these=20 > > > >> > two bytes as additional IV for the FFX algorithm. And in = both cases, we=20 > > > >> > are well below the 18 byte limit.=20 > > > >> >=20 > > > >> > Yes, that requires some creative engineering. But it is not = rocker=20 > > > >> > science. And it seems better than carrying tons of overhead = in the=20 > > > >> > header, and becoming less efficient than HTTP2/TLS/TCP.=20 > > > >>=20 > > > >> I agree that it would not be the end of the world for the load=20= > > > >> balancers if we decide to stick on the 18-byte limit. However, = as you=20 > > > >> state, it requires some creativeness.=20 > > > >>=20 > > > >> To me it seems that the question is if we have a strong reason = to=20 > > > >> require some people to be creative, for all the versions of = QUIC in=20 > > > >> the future. I personally think that there isn't a strong = reason,=20 > > > >> because people can use shorter CIDs regardless of the decision = we=20 > > > >> make. IIUC, the overhead that everyone needs to accept is:=20 > > > >>=20 > > > >> * one byte increase in the long header packets=20 > > > >> * the minimum size of short header packets becoming slightly = greater=20 > > > >> (otherwise, the peer might not be able to send a stateless = reset)=20 > > > >>=20 > > > >> I'd say that the first bullet point is negligible. The second = point=20 > > > >> could also be, because I'd assume that the only = frequently-sent=20 > > > >> packets that require additional padding is the ACK-only = packets, but=20 > > > >> there's no reason to pad ACK-only packets in hope that you'd = see a=20 > > > >> stateless reset.=20 > > > >>=20 > > > >> Therefore, my (not-so-strong) preference has been to provide = extra=20 > > > >> room, so that some people with necessity can use longer CIDs.=20= > > > >>=20 > > > >> >=20 > > > >> > -- Christian Huitema=20 > > > >> >=20 > > > >> >=20 > > > >> >=20 > > > >>=20 > > > >>=20 > > > >>=20 > > > >> --=20 > > > >> Kazuho Oku > > > >>=20 > > >=20 > > > AVE! > > > Philipp S. Tiesel > > >=20 > > > --=20 > > > Philipp S. Tiesel=20 > > > https://philipp.tiesel.net/ > > > >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 24 17:19:40 2019 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 B254C1201A8 for ; Mon, 24 Jun 2019 17:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fLw__dznLkH for ; Mon, 24 Jun 2019 17:19:37 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 CC44F12001E for ; Mon, 24 Jun 2019 17:19:36 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id p11so15734487wre.7 for ; Mon, 24 Jun 2019 17:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nxwBoyqWbtYopKjdjeM/jwE5sYXbhXXTv5OFWINfFQs=; b=uJPXV+j+a390JaIXARgCMWKEV77kV0BWWjPtpNa7VIbrZ4R66x20mmxqqGvHKeS0i9 /OigZT6nnyEXn0F2UPICmdPSquCh3qwkFHMpRLziTKHM3SVK3gQEhG25eFp+SkSEdBSI 0yMQrzX85ppSOp97Fk7fpeZu8NyAtyOoyqC7Nizpa4zIy3NOZcjVlyBDRqcYcIKiJ5jd OgQ49Y2c2qrSAo23nn3mzIjaFpsfjN7mDT73hUE1bmYeH7hWAIY0sHiP+vGSqJl6w6j7 azTd7xzB+yBGKzY8t4VYg31nFhxKnA4sIBGuXsZ+LDW9+Wx8WiTyPSiZWDCP2ihDhxBT /9Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nxwBoyqWbtYopKjdjeM/jwE5sYXbhXXTv5OFWINfFQs=; b=TfXolv/Vgjn2SjZHYPxj58az1zr3PVxc5SuCcAcSi4hUmO4dtEhTwHEvgsnWikq11U ukqCuWDrH5IJLyOaGXqmmSlqLpLDo1Oa3fAd38XAaF3Z0s1qK+8JhJIRYfUZvmAnDhqI 2UeBEHwz+ep390DDoijYEpUF5tww6pKu0UkQwl+oSR9CHltz8PJl/K1BRtkd0G05WqFq Dle+TLsmxW0tE3/RWKyZPeNRNSljyp7VhuV9J6Lnu52yoaK1F2VWDpXLgdnyA33urhsi qBXws7yB65xKhgX1D3NwfMo+djgh+AMXAQv6TZ+xaM9oBUemEs2XWe3rRk6m+c9xU9Gx ONzg== X-Gm-Message-State: APjAAAUgDR4WQFzgvK01mKtlhuHa8/05/A6CQfkSMEW7dcSmqmY7PaKu TKiUtePYD9wH6mLOf7o8DmEhN36rXsx+9jL0PZE= X-Google-Smtp-Source: APXvYqzgIdeebvpq23+4vVOqh523HwlUQU09ArszCoA7NnBxbvbL1WOxlUsRkSdfxTTIQ3pA8hAWCVIGs4PmzGJOAVA= X-Received: by 2002:adf:f181:: with SMTP id h1mr17210040wro.18.1561421975268; Mon, 24 Jun 2019 17:19:35 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <46035944-B522-47D1-A572-509BEC8DFC0B@mnot.net> In-Reply-To: <46035944-B522-47D1-A572-509BEC8DFC0B@mnot.net> From: Martin Duke Date: Mon, 24 Jun 2019 17:19:22 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Mark Nottingham Cc: Ted Hardie , Lars Eggert , QUIC IETF mailing list Content-Type: multipart/alternative; boundary="0000000000002e312f058c1ae26a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 00:19:39 -0000 --0000000000002e312f058c1ae26a Content-Type: text/plain; charset="UTF-8" OK, expect to see a revised PR Tuesday, Pacific time. On Sun, Jun 23, 2019 at 7:44 PM Mark Nottingham wrote: > Hi Ted, > > It looks like we're gravitating towards 20 bits (in QUICv1) -- if that's > where we end up, is this still something you'd like to see resolved first? > > Cheers, > > > > On 13 Jun 2019, at 2:16 am, Ted Hardie wrote: > > > > Hi Mark, > > > > https://github.com/quicwg/base-drafts/issues/2770 was raised in part > because of this change, and it is not resolved. While I do not expect that > it will cause a reversion of this design theory, it might be useful to wait > on declaring consensus for this until it resolves, in case the resolution > suggests a limit change. > > > > Could we encourage folks to test with the higher limits and new encoding > for now, but not close the issue? > > > > regards, > > > > Ted > > > > On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham wrote: > > Regarding: > > > > > > The editors believe that this PR resolved the issue: > > > > > > .....and discussion so far seems to support consensus to do so. If you > object, please do so on the issue or in response to this message; absent > any pushback, we'll declare consensus at the end of the week. > > > > Regards, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > -- > Mark Nottingham https://www.mnot.net/ > > --0000000000002e312f058c1ae26a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, expect to see a revised PR Tuesday, Pacific time.
<= /div>
O= n Sun, Jun 23, 2019 at 7:44 PM Mark Nottingham <mnot@mnot.net> wrote:
Hi Ted,

It looks like we're gravitating towards 20 bits (in QUICv1) -- if that&= #39;s where we end up, is this still something you'd like to see resolv= ed first?

Cheers,


> On 13 Jun 2019, at 2:16 am, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Hi Mark,
>
> https://github.com/quicwg/base-drafts/issues/2= 770 was raised in part because of this change, and it is not resolved.= =C2=A0 While I do not expect that it will cause a reversion of this design = theory, it might be useful to wait on declaring consensus for this until it= resolves, in case the resolution suggests a limit change.
>
> Could we encourage folks to test with the higher limits and new encodi= ng for now, but not close the issue?
>
> regards,
>
> Ted
>
> On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham <mnot@mnot.net> wrote:
> Regarding:
> <https://github.com/quicwg/base-drafts/iss= ues/2736>
>
> The editors believe that this PR resolved the issue:
> <https://github.com/quicwg/base-drafts/pull/2= 749>
>
> .....and discussion so far seems to support consensus to do so. If you= object, please do so on the issue or in response to this message; absent a= ny pushback, we'll declare consensus at the end of the week.
>
> Regards,
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--0000000000002e312f058c1ae26a-- From nobody Tue Jun 25 09:41:11 2019 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 98099120886 for ; Tue, 25 Jun 2019 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ju3CsFWMlcD for ; Tue, 25 Jun 2019 09:41:07 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 1D382120895 for ; Tue, 25 Jun 2019 09:41:06 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id f9so18615595wre.12 for ; Tue, 25 Jun 2019 09:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A43kGuyTsXlHU/AhMoHuzuSoibSFbB8h+7r9i3eeY2M=; b=no12Cov9Ty667qDoqPVewYXqDE1jqHh958WGY9yKu8EdKWiaZnvxR+OAvdRLaQA+QH KulZSwZCj51hawgJoX/9fdCJDEZyZbU4zXaAz7quwYkXnJ5qMt0gNWIApsBdXPzqtuwq Tj+Sx78UK25dY9vPaO659ZBv0PI96ZdmXxPxltGkM/jX+iqgOKXawMXq+BhFWW2P/Glg /pmZeVvZSTbMNoobMBYRAbgC5YW8Qs93zEfk2wwebrDQOelxMGfwNOemgxC/CsQ7nDTe xDWnJHFEjPoxzI8e83fhyUmUSvSY6o+uWJfFFgWH6gK+h7GW0ns/OONAnm4BZeiz6wgz D14A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A43kGuyTsXlHU/AhMoHuzuSoibSFbB8h+7r9i3eeY2M=; b=Xzqg8hLBfr5r1HJvCqrc3vd5DrnuKWcrY1dL2y6gnUjTDrlZUpsA1zdJ1evT3UDDrV mBN06S2W/KQ7u6ujbhOwHNMI1AerYXTU0A5G+Yiwb6f+q888DN3AI/f5yB9MdSBCAeVG Po3qPFNBVi1fH1pxxjViC8wRmsvFqOsn6ahfdnBE9mlWpxY7HUZAXHr6QQ8+Nb4/EVZA 9Y57KigmQ5nh8KnA61KMnUMvjMcqMczcA915nWmn6x8iiVpn9JvyZm64+F4dukVeVTXg eeq7iXYCGa2G/a2WjyFaeIUb94eaSBhEAaf3SuD/4aiMVeFkrWSJyb+lxD6Nt8MfhpzB 5Srg== X-Gm-Message-State: APjAAAWtVfoUZxpCHdsk1WPcSEjXHl1Pnz5FlGsnOkep40Ol9tzWF84c yBAKk3t6eiwkPUJcHjFoZtmwN5HgIGbcnfxch9Q= X-Google-Smtp-Source: APXvYqy6DOh8G24TwPHq+iz2ptI9wnP1NHxRRTNJwfOC6WqEScYZye0vsNj5dGWuTF2X3oWkwfrXH2BKhRy0MGlgm3M= X-Received: by 2002:adf:9d81:: with SMTP id p1mr38827849wre.294.1561480864587; Tue, 25 Jun 2019 09:41:04 -0700 (PDT) MIME-Version: 1.0 References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <46035944-B522-47D1-A572-509BEC8DFC0B@mnot.net> In-Reply-To: From: Martin Duke Date: Tue, 25 Jun 2019 09:40:52 -0700 Message-ID: Subject: Re: Consensus Call: More Connection ID Space #2736 To: Mark Nottingham Cc: Ted Hardie , Lars Eggert , QUIC IETF mailing list Content-Type: multipart/alternative; boundary="00000000000041e463058c28986b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 16:41:09 -0000 --00000000000041e463058c28986b Content-Type: text/plain; charset="UTF-8" Option (2) is now represented in the PR. On Mon, Jun 24, 2019 at 5:19 PM Martin Duke wrote: > OK, expect to see a revised PR Tuesday, Pacific time. > > On Sun, Jun 23, 2019 at 7:44 PM Mark Nottingham wrote: > >> Hi Ted, >> >> It looks like we're gravitating towards 20 bits (in QUICv1) -- if that's >> where we end up, is this still something you'd like to see resolved first? >> >> Cheers, >> >> >> > On 13 Jun 2019, at 2:16 am, Ted Hardie wrote: >> > >> > Hi Mark, >> > >> > https://github.com/quicwg/base-drafts/issues/2770 was raised in part >> because of this change, and it is not resolved. While I do not expect that >> it will cause a reversion of this design theory, it might be useful to wait >> on declaring consensus for this until it resolves, in case the resolution >> suggests a limit change. >> > >> > Could we encourage folks to test with the higher limits and new >> encoding for now, but not close the issue? >> > >> > regards, >> > >> > Ted >> > >> > On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham wrote: >> > Regarding: >> > >> > >> > The editors believe that this PR resolved the issue: >> > >> > >> > .....and discussion so far seems to support consensus to do so. If you >> object, please do so on the issue or in response to this message; absent >> any pushback, we'll declare consensus at the end of the week. >> > >> > Regards, >> > >> > -- >> > Mark Nottingham https://www.mnot.net/ >> > >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> --00000000000041e463058c28986b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Option (2) is now represented in the PR.

On Mon, Jun 24= , 2019 at 5:19 PM Martin Duke <martin.h.duke@gmail.com> wrote:
OK, expect to see a revised PR Tu= esday, Pacific time.

On Sun, Jun 23, 2019 at 7:44 PM Mark Nottingham <= ;mnot@mnot.net> w= rote:
Hi Ted,
It looks like we're gravitating towards 20 bits (in QUICv1) -- if that&= #39;s where we end up, is this still something you'd like to see resolv= ed first?

Cheers,


> On 13 Jun 2019, at 2:16 am, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Hi Mark,
>
> https://github.com/quicwg/base-drafts/issues/2= 770 was raised in part because of this change, and it is not resolved.= =C2=A0 While I do not expect that it will cause a reversion of this design = theory, it might be useful to wait on declaring consensus for this until it= resolves, in case the resolution suggests a limit change.
>
> Could we encourage folks to test with the higher limits and new encodi= ng for now, but not close the issue?
>
> regards,
>
> Ted
>
> On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham <mnot@mnot.net> wrote:
> Regarding:
> <https://github.com/quicwg/base-drafts/iss= ues/2736>
>
> The editors believe that this PR resolved the issue:
> <https://github.com/quicwg/base-drafts/pull/2= 749>
>
> .....and discussion so far seems to support consensus to do so. If you= object, please do so on the issue or in response to this message; absent a= ny pushback, we'll declare consensus at the end of the week.
>
> Regards,
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--00000000000041e463058c28986b-- From nobody Tue Jun 25 16:29:27 2019 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 12D89120124 for ; Tue, 25 Jun 2019 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 19od1XyQ3phk for ; Tue, 25 Jun 2019 16:29:21 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690100.outbound.protection.outlook.com [40.107.69.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F6812002E for ; Tue, 25 Jun 2019 16:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nA9eRz0fcTp/omEmJ6QHT/IIO8IadZ+dqTRYReGYY6k=; b=IuCym3/sX+FVXy7nI8tH8gZ+X4IGFe88OfcQ5SSkc5wQsEyr1/WAQ/eX80lT2R+gGZIot2hmOoCOa5kjZvUXsRMxNHNBBjreenfxIz1u0wvTyQOhFaMpqtCCRp0wpLz3PKuNNJWOmEBZFTFnEt3333xsgpJ5BKD12bOfcgQAGtk= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0072.namprd22.prod.outlook.com (10.169.183.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.17; Tue, 25 Jun 2019 23:29:19 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::557a:e1d6:905:aab6%6]) with mapi id 15.20.2008.017; Tue, 25 Jun 2019 23:29:19 +0000 From: Mike Bishop To: Lucas Pardue , Kazuho Oku CC: Martin Duke , Ian Swett , QUIC WG Subject: RE: Analysing the HTTP/3 error code space Thread-Topic: Analysing the HTTP/3 error code space Thread-Index: AQHVIHowKD1gaSBv6kuSLW6XelpUtaaWwd6AgAALBYCAAAwcAIAAGiJwgABdLACABV67gIAQZ/0w Date: Tue, 25 Jun 2019 23:29:18 +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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33b03145-1400-425e-1b10-08d6f9c4f21f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR22MB0072; x-ms-traffictypediagnostic: CY4PR22MB0072: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39830400003)(366004)(346002)(396003)(51444003)(199004)(189003)(110136005)(256004)(186003)(66946007)(8936002)(74316002)(54906003)(561944003)(14444005)(316002)(6506007)(81166006)(81156014)(7736002)(14454004)(99286004)(66066001)(606006)(102836004)(53546011)(229853002)(2906002)(7696005)(9686003)(446003)(6306002)(68736007)(54896002)(6246003)(790700001)(3846002)(8676002)(486006)(55016002)(6116002)(236005)(6436002)(74482002)(11346002)(476003)(33656002)(76176011)(71200400001)(86362001)(53936002)(5660300002)(30864003)(508600001)(71190400001)(66476007)(66446008)(66556008)(64756008)(26005)(73956011)(52536014)(25786009)(76116006)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0072; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PpkbfhXHjtPYJWtrXMzEZnArn3li0/HvhM7wxBhHjwk2Usspg2+C0LXCpLuINC1dXw9ubjzYLtR3xD1Hx4hZ6YaxGX7kLRCVKdy0hBIFGqaZsk9B2KBw25urNep5yO74KrSSFpJGfQYsYTJo6IciYUSjEsRzj4ffwk4BicA3fwtr60xftWQnPcPCqhiTOP+xtCL4NJFnCv2nwvYvqMARDYMhlf65wqrirlMt6KwcQX4zWNw1pDI6Yf8Zp/k6/XDVZjUsBWLEPCOeU3MuOxjJpXrCdQgsEHnkeQfOlfRjfXAJn+x3+ml/STvxfrU5NAeZ/E0LF+CkXD/m7ahPFse+sO7qRqMkd2tJDD4ch7V7aWx113M/DhtYMvFpJ2OO3XKgsYTeR16snryF3PRhyfDGdQHOxQUExzQi6aOtnRVjmIw= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983FCF100AFEB9B26603959DAE30CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 33b03145-1400-425e-1b10-08d6f9c4f21f X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 23:29:18.9053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbishop@evequefou.be X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0072 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 23:29:25 -0000 --_000_CY4PR22MB0983FCF100AFEB9B26603959DAE30CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRob3NlIG5vdCBmb2xsb3dpbmcgR2l0SHViIGNsb3NlbHksIEnigJlkIGxpa2UgdG8gcG9p bnQgb3V0IHRoYXQgdGhlc2UgcHJvcG9zYWxzIGhhdmUgc2hvd24gdXAgYXMgUFJzLCBhbmQgdGhh dCB0aGV5IGhhdmUgYmVlbiByZXZpZXdlZCBieSBhIGZldyBvZiB1cyBvdmVyIHRoZXJlLiAgSSBw bGFuIHRvIG1lcmdlIGxhdGVyIHRoaXMgd2VlaywgbW9kdWxvIGFueSBvYmplY3Rpb25zLg0KDQog ICogICAjMjgwODxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjgw OD4gbWFrZXMgdGhlIEgyIGNvbXBhcmlzb24gcG9pbnQgZnJvbSBQUk9UT0NPTF9FUlJPUiB0byBH RU5FUkFMX1BST1RPQ09MX0VSUk9SLCB3aGlsZSBub3RpbmcgdGhhdCBIMyBoYXMgbW9yZSBzcGVj aWZpYyBlcnJvciBjb2RlcyBmb3Igc29tZSB0aGluZ3MgdGhhdCB3ZXJlIFBFIGluIEgyDQogICog ICAjMjgxMzxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjgxMz46 ICBFeHBhbmRzIHRoZSB1c2Ugb2YgUkVRVUVTVF9DQU5DRUxMRUQgdG8gY2FuY2VsbGluZyBwdXNo IHN0cmVhbXMgYW5kIHJlbW92ZXMgdGhlIG1vcmUgc3BlY2lmaWMgZXJyb3IgY29kZXMgZm9yIHdo eSBvbmUgbWlnaHQgbm90IHdhbnQgdGhlIHB1c2hlZCBjb250ZW50DQogICogICAjMjgxNDxodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjgxND46ICBDb2xsZWN0cyBh bnl0aGluZyB0aGF0IGNvdWxkIGJlIHdyb25nIHdpdGggdGhlIHBheWxvYWQgb2YgYSBTRVRUSU5H UyBmcmFtZSAoc2VydmVyIHNldHRpbmdzIHNlbnQgYnkgY2xpZW50cywgZHVwbGljYXRlcykgaW50 byBTRVRUSU5HU19FUlJPUg0KICAqICAgIzI4MjA8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy9wdWxsLzI4MjA+OiAgR3JvdXBzIExJTUlUX0VYQ0VFREVEIGFuZCB2YXJpb3Vz IG1pc3VzZXMgb2YgUHVzaCBJRHMgaW50byBhIHNpbmdsZSBlcnJvciBjb2RlIChJRF9FUlJPUikg Zm9yIGFueSBtaXN1c2Ugb2YgaWRlbnRpZmllcnMgZGVmaW5lZCBieSBIVFRQDQogICogICAjMjgy MjxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjgyMj46ICBHcm91 cHMgVU5LTk9XTl9TVFJFQU1fVFlQRSwgV1JPTkdfU1RSRUFNX0NPVU5ULCBhbmQgV1JPTkdfU1RS RUFNX0RJUkVDVElPTiBpbnRvIGEgc2luZ2xlIGVycm9yIGNvZGUgKFNUUkVBTV9DUkVBVElPTl9F UlJPUikgZm9yIGFueSByZWFzb24gd2h5IGEgbmV3bHkgb3BlbmVkIHVuaWRpcmVjdGlvbmFsIHN0 cmVhbSBpcyB1bmFjY2VwdGFibGUgdG8gdGhlIHJlY2lwaWVudA0KDQpJZiB5b3UgaGF2ZSBmZWVk YmFjayBvbiB0aGVzZSwgcGxlYXNlIHNwZWFrIG5vdywgZWl0aGVyIGhlcmUgb3Igb24gR2l0SHVi Lg0KDQpPbmNlIHRoZXNlIGFyZSBpbiwgIzI2NjI8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy9wdWxsLzI2NjI+IHByb2JhYmx5IG5lZWRzIHRvIGJlIHJld29ya2VkIHNsaWdo dGx5IGFuZCBzaG91bGQgbGFuZCBzb29uIGFzIHdlbGwuICBMdWNhcyBoYXMgYmVlbiBsZWF2aW5n IHRoZSBuby1sb25nZXItdXNlZCBlcnJvciBjb2RlcyBhcyBSZXNlcnZlZCBpbiBlYWNoIG9mIHRo ZXNlIFBSczsgYWZ0ZXIgdGhleSBsYW5kLCBoZSBvciBJIHdpbGwgZG8gYW5vdGhlciBQUiB0byBj b25kZW5zZSB0aGUgZXJyb3IgY29kZSBzcGFjZS4NCg0KRnJvbTogTHVjYXMgUGFyZHVlIDxsdWNh c3BhcmR1ZS4yNC43QGdtYWlsLmNvbT4NClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDE1LCAyMDE5IDU6 NDQgQU0NClRvOiBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KQ2M6IE1pa2UgQmlz aG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQW5hbHlzaW5nIHRoZSBIVFRQLzMgZXJyb3IgY29kZSBz cGFjZQ0KDQpUaGFuayB5b3UgYWxsIGZvciB0aGUgaW5wdXQuDQoNClNlZWluZyBzb21lIHN1cHBv cnQsIHdpdGggdmFsdWFibGUgc3VnZ2VzdGlvbnMsIEkgd2lsbCBzdGFydCBvbiBhIHNlcmllcyBv ZiBpc3N1ZXMvUFJzIHRvIGxldCB1cyByZWZpbmUgdGhlIHNwZWNpZmljcy4NCg0KDQoNCk9uIFdl ZCwgMTIgSnVuIDIwMTksIDAzOjQzIEthenVobyBPa3UsIDxrYXp1aG9va3VAZ21haWwuY29tPG1h aWx0bzprYXp1aG9va3VAZ21haWwuY29tPj4gd3JvdGU6DQoyMDE55bm0NuaciDEy5pelKOawtCkg Njo0MSBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZl cXVlZm91LmJlPj46DQo+DQo+IEkgd2FzIHByZXZpb3VzbHkgYWZmaWxpYXRlZCB3aXRoIGFuIEhU VFAgc3RhY2sgdGhhdCBJIGFzc3VtZSBzdGlsbCBuZWVkcyBIVFRQX1ZFUlNJT05fRkFMTEJBQ0sg Zm9yIHNvbWUgY29ybmVyIGNhc2VzIGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCByZW5l Z290aWF0aW9uLiAgVGhpcyBXRyBwcmV2aW91c2x5IGhhZCBhIGRpc2N1c3Npb24gYWJvdXQgd2hl dGhlciBpdCBzaG91bGQgZmFsbCBiYWNrIHRvIEhUVFAvMiAobG9naWNhbCwgYnV0IGxpa2VseSBo YXMgYWxsIHRoZSBzYW1lIGluY29tcGF0aWJsZSBzY2VuYXJpb3MgdGhhdCBIVFRQLzMgZG9lcykg b3IgSFRUUC8xLjEsIGFuZCBjb25jbHVkZWQgdGhhdCBpdCB3b3VsZCBiZSBzYWQgdG8gbWFrZSBz b21lb25lIGZhbGwgZnJvbSAzIC0+IDIgLT4gMS4xIHdoZW4gcHJvYmFibHkgY2Fu4oCZdCBhbnN3 ZXIgb3ZlciBhbnl0aGluZyBoaWdoZXIgdGhhbiAxLjEgYW55d2F5Lg0KPg0KPg0KPg0KPiA+IDAp IEFwcGVuZGl4IEEuNCBjb250YWlucyBhIGNvbnZlbmllbnQgY29tcGFyaXNvbiBvZiBIVFRQLzIg YW5kIEhUVFAvMyBlcnJvciBjb2Rlcy4gSG93ZXZlciwgaXQgc3RhdGVzIHRoYXQgSFRUUC8yJ3Mg UFJPVE9DT0xfRVJST1IgaGFzIG5vIHNpbmdsZSBlcXVpdmFsZW50LCB3aGljaCBJIHRoaW5rIGlz IGluY29ycmVjdCBiZWN1YXNlIEhUVFAvMyBoYXMgSFRUUF9HRU5FUkFMX1BST1RPQ09MX0VSUk9S Lg0KPg0KPg0KPg0KPiBNb3N0bHkgYmVjYXVzZSB0aGUgdmFyaW91cyBNQUxGT1JNRURfRlJBTUUg ZXJyb3JzIHdvdWxkIGFsc28gaGF2ZSBiZWVuIFBST1RPQ09MX0VSUk9SIGluIEhUVFAvMi4gIFdl IGNvdWxkIG1ha2UgdGhlIHRleHQgcG9pbnQgdG8gR1BFLCB3aGlsZSBub3RpbmcgdGhhdCBzcGVj aWZpYyBlcnJvciBjb2RlcyBoYXZlIGJlZW4gYWRkZWQgZm9yIGNlcnRhaW4gc2l0dWF0aW9ucy4N Cj4NCj4NCj4NCj4gPiAxKSBIVFRQX1dST05HX1NUUkVBTSBhbmQgSFRUUF9VTkVYUEVDVEVEX0ZS QU1FIGFyZSB1c2VkIGEgbG90IGFuZCB2ZXJ5IHNpbWlsYXIuIFRoZSBmb3JtZXIgaXMgdXNlZCBi eSBhIHBlZXIgdGhhdCByZWNlaXZlcyBhIHZhbGlkIGZyYW1lIG9uIGEgc3RyZWFtIHRoYXQgaXQg c2hvdWxkIG5ldmVyIGJlIHNlbnQgb24sIHRoZSBsYXR0ZXIgaXMgdXNlZCBieSBhIHBlZXIgdGhh dCByZWNlaXZlcyBhIHZhbGlkIGZyYW1lIG9uIGEgc3RyZWFtIHRoYXQgaXMgbm9ybWFsbHkgb2sg YnV0IGhhcyB0cmFuc2l0aW9uZWQgdG8gYW4gYXBwbGljYXRpb24tbGV2ZWwgc3RyZWFtIHN0YXRl IHdoaWNoIHByb2hpYml0cyBpdC4NCj4NCj4gPiBSYXRpb25hbGlzaW5nIHRoZXNlIHNlZW1zIGxp a2UgYSBsb2dpY2FsIG9wdGlvbi4NCj4NCj4NCj4NCj4gU2VlbXMgcmVhc29uYWJsZS4gIEkgYmVs aWV2ZSB0aGVyZSB3YXMgcHJldmlvdXMgZGlzY3Vzc2lvbiBhYm91dCBwb3NzaWJseSBjb21iaW5p bmcgdGhlbSwgYnV0IEkgY2Fu4oCZdCBmaW5kIGl0IHdpdGggYSBjdXJzb3J5IHNlYXJjaC4NCj4N Cj4NCj4NCj4gPiAyKSBIVFRQX1dST05HX1NFVFRJTkdfRElSRUNUSU9OIHByZXNlbnRseSBhcHBs aWVzIHRvIGV4YWN0bHkgb25lIGNhc2UsIGEgY2xpZW50IHNlbmQgTlVNX1BMQUNFSE9MREVSLiBE ZWNsYXNzaWZ5aW5nIHRoaXMgYXMgYW4gZXJyb3Igc2VlbXMgbGlrZSBhIHNlbnNpbGUgb3B0aW9u LiBUaGlzIGZyZWVzIHVwIGVycm9yIGNvZGUgMHgxLCB3aGljaCB3ZSBjYW4gbW92ZSBIVFRQX0dF TkVSQUxfUFJPVE9DT0xfRVJST1IgdG8gKG1ha2luZyBIVFRQLzMgbW9yZSBzaW1pbGFyIHRvIEhU VFAvMikuDQo+DQo+ID4gNykgVGhlcmUgYXJlIHNldmVyYWwgZXJyb3IgY2FzZXMgcmVsYXRlZCB0 byBTRVRUSU5HUzsgYSBmcmFtZSB0aGF0IGNhbiBiZSBzZW50IG1vc3Qgb25jZSBwZXIgY29ubmVj dGlvbi4gSSBtYWRlIGEgcHJvcG9zYWwgdG8gYWRkcmVzcyB0aGlzIG9uIGlzc3VlICMyNzgzIFsz XQ0KPg0KPg0KPg0KPiBJIG5lZWQgdG8gdGhpbmsgbW9yZSBhYm91dCB0aGUgcHJvcG9zYWwgaW4g IzI3ODMsIGJ1dCB0aGF04oCZcyBzZW1pLW9ydGhvZ29uYWwgdG8gdGhlIGVycm9yIGNvbnZlcnNh dGlvbi4gIEkgbGlrZSB0aGUgc3VnZ2VzdGlvbiBmcm9tIHRoZSBpbnRlcmltIHRvIGNvbnNvbGlk YXRlIHRoZXNlIHRvIGEgbW9yZSBnZW5lcmFsIElOVkFMSURfU0VUVElOR1MgZXJyb3IsIHRob3Vn aCBpZiB3ZSBnbyB0aGUgcm91dGUgb2YgIzI3ODMsIHRoYXQgbWlnaHQgYmVjb21lIGEgU1RSRUFN X0hFQURFUl9FUlJPUiDDoCBsYSAoOCkuDQo+DQo+DQo+DQo+ID4gMykgSFRUUF9QVVNIX1JFRlVT RUQgYW5kIEhUVFBfUFVTSF9BTFJFQURZX0lOX0NBQ0hFIGFyZSB2ZXJ5IHNpbWlsYXIgYnV0IG1h eSBiZSB1c2VmdWwgdG8gdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW50IHJlYXNvbiB0aGF0IGNsaWVu dHMgcmVqZWN0IHNlcnZlciBwdXNoLiBUaGlzIGlzIGV4dHJhIGZpZGVsaXR5IG9uIHRvcCBvZiBI VFRQLzIuDQo+DQo+ID4gNCkgVGhlcmUgYXJlIHNldmVyYWwgZXJyb3IgY29kZXMgcmVsYXRlZCB0 byBoYW5kbGluZyByZXF1ZXN0cyBhbmQNCj4NCj4gcmVzcG9uc2VzOiBIVFRQX1JFUVVFU1RfQ0FO Q0VMTEVELCBIVFRQX0lOQ09NUExFVEVfUkVRVUVTVCwgSFRUUF9FQVJMWV9SRVNQT05TRSwgSFRU UF9SRVFVRVNUX1JFSkVDVEVELCAuIFRoaXMgaXMgZXh0cmEgZmlkZWxpdHkgdGhhbiBIVFRQLzIg cHJvdmlkZWQuIFRoaXMgbWF5IGV4dHJhIGluZm9ybWF0aW9uIG1heSBhbGxvdyBlbmRwb2ludHMg dG8gbWFrZSBzbWFydGVyIGRlY2lzaW9ucyBhYm91dCByZXRyeWluZyByZXF1ZXN0cy4gSG93ZXZl ciwgaXQgbWF5IGFsc28gYmUgcG9zc2libGUgdG8gaW5mZXIgdGhpbmdzIGZyb20gYSBzdHJlYW0g ZXJyb3IgdGhhdCBjb250YWlucyBzaW1wbHkgSFRUUF9OT19FUlJPUiAoIEhUVFBfRUFSTFlfUkVT UE9OU0UgY291bGQgYmVuZWZpdCBmcm9tIHRoaXMpDQo+DQo+DQo+DQo+IFdlIG5lZWQgdGhlIENB TkNFTExFRC9SRUpFQ1RFRCBzcGxpdCB0byB1bmRlcnN0YW5kIHdoZW4gYSBzZXJ2ZXIgaXMgZGVj bGFyaW5nIHRoYXQgbm8gcHJvY2Vzc2luZyBvY2N1cnJlZCB2ZXJzdXMgcmVmbGVjdGluZyBiYWNr IHRoZSBlcnJvciBjb2RlIGZyb20gdGhlIGNsaWVudOKAmXMgU1RPUF9TRU5ESU5HIGluIGEgUkVT RVRfU1RSRUFNLiAgKFRoZSByZXNvbHV0aW9uIHRvIHRoYXQgaXMgdGhhdCBjbGllbnRzIGRvbuKA mXQgc2VuZCBSRUpFQ1RFRCwgYW5kIGl0IGhhcyB0aGUgYWRkaXRpb25hbCBzZW1hbnRpYyB3aGVu IGNvbWluZyBmcm9tIGEgc2VydmVyLikgIElmIHdlIGRpZG7igJl0IGhhdmUgSU5DT01QTEVURV9S RVFVRVNULCBJ4oCZbSB1bnN1cmUgd2hhdCB3ZeKAmWQgc2VuZCBpbiB0aGF0IHNpdHVhdGlvbiBp bnN0ZWFkOyBpdOKAmXMgY2VydGFpbmx5IG5vdCBhIE5PX0VSUk9SIHNpdHVhdGlvbi4NCj4NCj4N Cj4NCj4gRm9sZGluZyBFQVJMWV9SRVNQT05TRSBpbnRvIE5PX0VSUk9SIHdvdWxkIGJlIHJlYXNv bmFibGUuDQo+DQo+DQo+DQo+ID4gNSkgVGhlIGVycm9yIGNvZGUgZ3VpZGFuY2UgaXMgb2Z0ZW4g bm90IHN5bW1ldHJpYy4gQ2xpZW50IG9yIHNlcnZlcnMgdXNlIGVycm9yIGNvZGVzIGRpZmZlcmVu dGx5IGFuZCBsaXR0bGUgZ3VpZGFuY2UgaXMgcHJvdmlkZWQgb24gaG93IHRvIHByb2Nlc3MgYW4g ZXJyb3IgY29kZSB0aGF0IGluIHRoZW9yeSBzaG91bGQgbmV2ZXIgYmUgc2VudC4NCj4NCj4NCj4N Cj4gVGhlIG9ubHkgcG9zc2libGUgcmVzcG9uc2UgaXMgYmxvd2luZyB1cCB0aGUgY29ubmVjdGlv biwgaXNu4oCZdCBpdD8gIFdoaWNoIGlzIHN1cGVyZmx1b3VzIGlmIHlvdeKAmXZlIHJlY2VpdmVk IGEgbm9uc2Vuc2ljYWwgY29ubmVjdGlvbiBlcnJvciwgYmVjYXVzZSB0aGUgY29ubmVjdGlvbiBp cyBhbHJlYWR5IGJlaW5nIGJsb3duIHVwIGJ5IHRoZSBwZWVyLiAgU28gdGhlIG1vcmUgc2NvcGVk IHF1ZXN0aW9uIGlzLCBpZiBhIHN0cmVhbSBzZWVzIGEgUkVTRVQvU1RPUF9TRU5ESU5HIHdpdGgg YW4gZXJyb3IgY29kZSB0aGF0IGEpIHNob3VsZCBvbmx5IGhhdmUgb3JpZ2luYXRlZCBmcm9tIHlv dXIgc2lkZSwgb3IgYikgY2FuIG9ubHkgYmUgYSBjb25uZWN0aW9uIGVycm9yLCB3aGF0IGRvIHlv dSBkbz8NCj4NCj4NCj4NCj4gPiA2KSBUaGVyZSBpcyBsaXR0bGUgZ3VpZGFuY2Ugb24gaG93IGFu IGludGVybWVkaWFyeSB0aGF0IHRyYW5zbGF0ZXMgYmV0d2VlbiBIVFRQLzIgYW5kIEhUVFAvMyBz aG91bGQgbWFwIHRoZXNlIGRpdmVyZ2VudCBlcnJvciBjb2RlIHNwYWNlcy4gSXQgd291bGQgcGF5 IHRvIGFsaWduIHRoZW0gYXMgY2xvc2UgYXMgcG9zc2libGUgYW5kIHByb3ZpZGUgc29tZSBndWlk YW5jZSBvbiBob3cgdG8gbWFwIGhpZ2hlciBmaWRlbGl0eSBjb2RlcyB0byBsb3dlciBmaWRlbGl0 eSBjb2Rlcy4NCj4NCj4NCj4NCj4gVGhhdOKAmXMgYSBnb29kIHBvaW50LiAgSG93ZXZlciwgZXJy b3IgY29kZXMgYXJlIGhvcC10by1ob3Ag4oCTIEkgc3VzcGVjdCB0aGF0IGFueSBlcnJvciBjb2Rl IGdldHMgdHVybmVkIGludG8gYSBzdGF0dXMgY29kZSA1MDIsIHdpdGggdGhlIHBvc3NpYmxlIGV4 Y2VwdGlvbiBvZiBSRUpFQ1RFRC4gIERvIGV4cGVjdCBhbnlvbmUgdG8gYnVpbGQgYSAyLzMgaW50 ZXJtZWRpYXJ5IHdobyBpc27igJl0IGFsc28gdGVybWluYXRpbmcgdGhlIEhUVFAgc2VtYW50aWMg bGF5ZXI/DQoNCk5vdCB0aGF0IHdlIGRvIG5vdyBhcyBhIHByb3h5IGltcGxlbWVudGF0aW9uLCBi dXQgSSB0aGluayBpdCB3b3VsZCBiZQ0KcHJlZmVyYWJsZSB0byBwcm9wYWdhdGUgInRlbXBvcmFy eSIgZXJyb3JzIChSRUZVU0VEX1NUUkVBTSksIGFuZCBhbHNvDQpDT05ORUNUX0VSUk9SIHRvIGlu ZGljYXRlIHJlc2V0IG9mIGEgd2Vic29ja2V0IGNvbm5lY3Rpb24uIEZvciBhbGwNCm90aGVyIGVy cm9ycyBJIHRoaW5rIHRoYXQgNTAyIGNhbiBiZSB1c2VkLg0KDQpJdCBtaWdodCBiZSB3b3J0aCBj bGFyaWZ5aW5nIHRoYXQgc3VjaCBiZWhhdmlvciBpcyB0byBiZSBleHBlY3RlZCAob3INCnByZWZl cmFibGUpLg0KDQo+DQo+DQo+DQo+ID4gOCkgSFRUUF9VTktOT1dOX1NUUkVBTV9UWVBFIGFuZCBE VVBMSUNBVEVfUFVTSCBib3RoIHJlbGF0ZSB0byBwYXJzaW5nIHRoZSB1bmlkaXJlY3Rpb25hbCBz dHJlYW0gdHlwZSBoZWFkZXIuIFdlIG1pZ2h0IGJlIGFibGUgdG8gbWVyZ2UgdGhlc2UgaW50byBh IGVycm9yIHN1Y2ggYXMgSFRUUF9TVFJFQU1fSEVBREVSX0VSUk9SIGFuZCBzdGF0ZSB0aGUgY29k ZSBoYXMgZGlmZmVyZW50IGFwcGxpY2FiaWxpdHkgYmV0d2VlbiBTVE9QX1NFTkRJTkcgYW5kIENP Tk5FQ1RJT05fQ0xPU0UgZnJhbWVzLg0KPg0KPiA+IDkpIENyaXRpY2FsIHN0cmVhbXMgc3VjaCBh cyBjb250cm9sIHN0cmVhbSBhbmQgUVBBQ0sgc3RyZWFtcyBjYW4gYmUgY3JlYXRlZCBvbmx5IG9u Y2U7IEhUVFBfV1JPTkdfU1RSRUFNX0NPVU5UIGNhcHR1cmVzIHRoaXMuIFB1c2ggc3RyZWFtcyBj YW4gb25seSBiZSBjcmVhdGVkIGJ5IGEgc2VydmVyIGFuZCBIVFRQX1dST05HX1NUUkVBTV9ESVJF Q1RJT04gY2FwdHVyZXMgdGhpcy4gV2UgY291bGQgcmF0aW9uYWxpc2UgdGhlc2UgaW50byBIVFRQ X1NUUkVBTV9DUkVBVElPTl9FUlJPUiwgdGhhdCBjb3VsZCBldmVuIGluY29ycG9yYXRlIHN1Z2dl c3Rpb24gOC4NCj4NCj4NCj4NCj4gRFVQTElDQVRFX1BVU0ggY2FuIGFsc28gcmVmZXIgdG8gYSBz ZWNvbmQgUFVTSF9QUk9NSVNFIHdpdGggdGhlIHNhbWUgUHVzaCBJRC4gIE90aGVyd2lzZSwgYSBT VFJFQU1fSEVBREVSX0VSUk9SIG9yIFNUUkVBTV9DUkVBVElPTl9FUlJPUiBzZWVtcyBsaWtlIGEg cmVhc29uYWJsZSBjb2xsYXRpb247IEkgYWdyZWUgdGhhdCB0aG9zZSBhcmUgdWx0aW1hdGVseSB0 aGUgc2FtZSBwcm9wb3NhbC4NCj4NCj4NCj4NCj4NCj4NCj4gRnJvbTogUVVJQyA8cXVpYy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2Yg TWFydGluIER1a2UNCj4gU2VudDogVHVlc2RheSwgSnVuZSAxMSwgMjAxOSAxMjozNyBQTQ0KPiBU bzogTHVjYXMgUGFyZHVlIDxsdWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbTxtYWlsdG86bHVjYXNw YXJkdWUuMjQuN0BnbWFpbC5jb20+Pg0KPiBDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUu Y29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogQW5hbHlzaW5nIHRoZSBIVFRQ LzMgZXJyb3IgY29kZSBzcGFjZQ0KPg0KPg0KPg0KPiBJIHdvdWxkIGluc2lzdCBvbiBJTlRFUk5B TF9FUlJPUi4gSXQgaXMgZ3JlYXQgZm9yIHZhcmlvdXMgbWFsbG9jIHByb2JsZW1zLCBhcyB3ZWxs IGFzIGZvciBzaWduYWxsaW5nIHRoYXQgc29tZXRoaW5nIHdlbnQgd3Jvbmcgb24gdGhlIGJhY2sg ZW5kIGluIHByb3h5IHNjZW5hcmlvcy4gSXQgaXMgYSBjYXRjaC1hbGwgZm9yICJJIHNjcmV3ZWQg dXAgYW5kIGNhbid0IGNvbnRpbnVlIi4NCj4NCj4NCj4NCj4gT24gVHVlLCBKdW4gMTEsIDIwMTkg YXQgMTE6NTMgQU0gTHVjYXMgUGFyZHVlIDxsdWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbTxtYWls dG86bHVjYXNwYXJkdWUuMjQuN0BnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4gIEhleSBJYW4sDQo+ DQo+IE9uIFR1ZSwgSnVuIDExLCAyMDE5IGF0IDc6MTQgUE0gSWFuIFN3ZXR0IDxpYW5zd2V0dEBn b29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj4gd3JvdGU6DQo+ID4NCj4gPj4N Cj4gPj4gT25lIG5vdGFibGUgZGlmZmVyZW5jZSBpcyB0aGF0IEhUVFAvMnMgRlJBTUVfU0laRV9F UlJPUiBjb2RlIGhhcyBiZWVuDQo+ID4+IHJlcGxhY2VkIGJ5IEhUVFBfTUFMRk9STUVEX0ZSQU1F LCB3aGljaCBhY3R1YWxseSBjb3ZlcnMgYSByYW5nZSBvZg0KPiA+PiB2YWx1ZXMgLSBpdCBkZWRp Y2F0ZXMgYSBieXRlIHRvIGVuY29kZSB0aGUgZnJhbWUgdHlwZS4gVGhpcyBpcw0KPiA+PiBwcm9i bGVtYXRpYyBzaW5jZSB0aGUgZnJhbWUgdHlwZSBjaGFuZ2VkIHRvIGJlIGEgNjItYml0IGludGVn ZXINCj4gPj4gaXRzZWxmLiAgSW4gbXkgcGVyc29uYWwgb3BpbmlvbiwgdGhpcyBlcnJvciBjb2Rl IGlzIG1vcmUgY29tcGxpY2F0ZWQNCj4gPj4gdGhhbiBuZWVkcyBiZSBhbmQgd2FzIGluY29ycmVj dGx5IGFwcGxpZWQuIElzc3VlICMyNTUxIFsxXSBjYXB0dXJlcw0KPiA+PiB0aGlzLCBhbmQgUFIg IzI2NjIgWzJdIGNvbnRhaW5zIGEgcHJvcG9zZWQgc2V0IG9mIHJlcGxhY2VtZW50IGNvZGVzLg0K PiA+PiBUaGF0IFBSIGFkZHMgNCBlcnJvciBjb2RlcyB0byBicmluZyB0aGUgdG90YWwgdXAgdG8g MjguDQo+ID4NCj4gPg0KPiA+IEkgbGlrZSB5b3VyIHByb3Bvc2VkIFBSLg0KPg0KPiBUaGFua3Mu IFRoZSBUTDtEUiBvZiB0aGUgUFIgaXMgdGhhdCBpdCBhZGQgYmFjayBGUkFNRV9TSVpFX0VSUk9S IChmb3INCj4gdGhpbmdzIHRoYXQgYXJlIGZyYW1lIHNpemUgZXJyb3JzKSBhbmQgYWRkcyBzb21l IG5ldyBlcnJvciBjb2RlcyBpbg0KPiBhZ3JlZW1lbnQgd2l0aCBvdXIgY3VycmVudCBwaGlsb3Nv cGh5LiBJIHdvdWxkIHJlZmluZSB0aGUgUFIgdG8gYWdyZWUNCj4gd2l0aCB0aGUgb3V0Y29tZSBv ZiB0aGlzIHRocmVhZC4NCj4NCj4gPg0KPiA+IEFueSB0aG91Z2h0cyBvbiBIVFRQX1ZFUlNJT05f RkFMTEJBQ0sgYW5kIEhUVFBfSU5URVJOQUxfRVJST1IsIHdoaWNoIGFyZSBuZXZlciB1c2VkPyAg SSdtIHVuY2xlYXIgb24gd2hhdCB0aGUgaW50ZW5kZWQgdXNhZ2UgaXM/DQo+DQo+IEkgcmVhbGlz ZWQgSSBkaWRuJ3QgcXVhbGlmeSBvbmUgYXNwZWN0IG9mIG15IGFuYWx5c2lzIC0gdGhlIGd1aWRh bmNlDQo+IGNvdW50IG1ldHJpYyBpcyBvbmx5IG9uZSBzaWduYWwuIEhUVFBfSU5URVJOQUxfRVJS T1IgaXMgZGVzY3JpYmVkIGFzDQo+ICJBbiBpbnRlcm5hbCBlcnJvciBoYXMgb2NjdXJyZWQgaW4g dGhlIEhUVFAgc3RhY2suIiwgd2hpY2ggZmVlbHMgbGlrZQ0KPiBhbiBpbXBsZW1lbnRhdGlvbi1v cmllbnRlZCBlcnJvciBjb2RlLiBJIHRoaW5rIGl0IGlzIHZhbGlkIGluIHN0YXlpbmcNCj4gaW4g SFRUUC8zLCBlc3BlY2lhbGx5IGlmIGl0IGlzIHVzZWQgaW4gSFRUUC8yIChJIGRvbid0IGhhdmUg ZGF0YSB0bw0KPiBoYW5kIG9uIHRoYXQgdGhvdWdoKS4gSG93ZXZlciwgSFRUUF9WRVJTSU9OX0ZB TExCQUNLIGlzIGEgYml0IHdlaXJkOw0KPiBpdCBzdGVtcyBmcm9tIEhUVFAvMidzIEhUVFBfMV8x X1JFUVVJUkVEIGNvZGUsIHdoaWNoIGluIFJGQyA3NTQwIGlzDQo+IG9ubHkgcmVjb21tZW5kZWQg d2hlbiB0aGUgc2VydmVyIHdhbnRzIHRvIHVzZSBUTFMgcmVuZWdvdGlhdGlvbi4gSU1PDQo+IGl0 IGlzIG9mIGxpbWl0ZWQgdmFsdWUgdW5sZXNzIHdlIGltcG9ydCB0aGUgc2FtZSBiZWhhdmlvdXIg aW50bw0KPiBIVFRQLzMuDQoNCg0KDQotLQ0KS2F6dWhvIE9rdQ0K --_000_CY4PR22MB0983FCF100AFEB9B26603959DAE30CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjEwODE5NTAxNDU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjExMjAyODA0OTQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aG9zZSBub3QgZm9sbG93aW5n IEdpdEh1YiBjbG9zZWx5LCBJ4oCZZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IHRoZXNlIHByb3Bv c2FscyBoYXZlIHNob3duIHVwIGFzIFBScywgYW5kIHRoYXQgdGhleSBoYXZlIGJlZW4gcmV2aWV3 ZWQgYnkgYSBmZXcgb2YgdXMgb3ZlciB0aGVyZS4mbmJzcDsgSSBwbGFuIHRvIG1lcmdlIGxhdGVy IHRoaXMgd2VlaywgbW9kdWxvIGFueSBvYmplY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxh IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8yODA4Ij4j MjgwODwvYT4gbWFrZXMgdGhlIEgyIGNvbXBhcmlzb24gcG9pbnQgZnJvbSBQUk9UT0NPTF9FUlJP UiB0byBHRU5FUkFMX1BST1RPQ09MX0VSUk9SLCB3aGlsZSBub3RpbmcgdGhhdCBIMyBoYXMgbW9y ZSBzcGVjaWZpYw0KIGVycm9yIGNvZGVzIGZvciBzb21lIHRoaW5ncyB0aGF0IHdlcmUgUEUgaW4g SDI8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjgxMyI+IzI4MTM8L2E+OiZuYnNwOyBF eHBhbmRzIHRoZSB1c2Ugb2YgUkVRVUVTVF9DQU5DRUxMRUQgdG8gY2FuY2VsbGluZyBwdXNoIHN0 cmVhbXMgYW5kIHJlbW92ZXMgdGhlIG1vcmUgc3BlY2lmaWMgZXJyb3IgY29kZXMgZm9yDQogd2h5 IG9uZSBtaWdodCBub3Qgd2FudCB0aGUgcHVzaGVkIGNvbnRlbnQ8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2Ut ZHJhZnRzL3B1bGwvMjgxNCI+IzI4MTQ8L2E+OiZuYnNwOyBDb2xsZWN0cyBhbnl0aGluZyB0aGF0 IGNvdWxkIGJlIHdyb25nIHdpdGggdGhlIHBheWxvYWQgb2YgYSBTRVRUSU5HUyBmcmFtZSAoc2Vy dmVyIHNldHRpbmdzIHNlbnQgYnkgY2xpZW50cywgZHVwbGljYXRlcykNCiBpbnRvIFNFVFRJTkdT X0VSUk9SPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PGEgaHJlZj0iaHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzI4MjAiPiMyODIwPC9hPjombmJz cDsgR3JvdXBzIExJTUlUX0VYQ0VFREVEIGFuZCB2YXJpb3VzIG1pc3VzZXMgb2YgUHVzaCBJRHMg aW50byBhIHNpbmdsZSBlcnJvciBjb2RlIChJRF9FUlJPUikgZm9yIGFueSBtaXN1c2Ugb2YgaWRl bnRpZmllcnMNCiBkZWZpbmVkIGJ5IEhUVFA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwv MjgyMiI+IzI4MjI8L2E+OiZuYnNwOyBHcm91cHMgVU5LTk9XTl9TVFJFQU1fVFlQRSwgV1JPTkdf U1RSRUFNX0NPVU5ULCBhbmQgV1JPTkdfU1RSRUFNX0RJUkVDVElPTiBpbnRvIGEgc2luZ2xlIGVy cm9yIGNvZGUgKFNUUkVBTV9DUkVBVElPTl9FUlJPUikNCiBmb3IgYW55IHJlYXNvbiB3aHkgYSBu ZXdseSBvcGVuZWQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtIGlzIHVuYWNjZXB0YWJsZSB0byB0aGUg cmVjaXBpZW50PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBoYXZlIGZlZWRi YWNrIG9uIHRoZXNlLCBwbGVhc2Ugc3BlYWsgbm93LCBlaXRoZXIgaGVyZSBvciBvbiBHaXRIdWIu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uY2UgdGhlc2UgYXJlIGluLCA8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjY2MiI+DQojMjY2MjwvYT4g cHJvYmFibHkgbmVlZHMgdG8gYmUgcmV3b3JrZWQgc2xpZ2h0bHkgYW5kIHNob3VsZCBsYW5kIHNv b24gYXMgd2VsbC4mbmJzcDsgTHVjYXMgaGFzIGJlZW4gbGVhdmluZyB0aGUgbm8tbG9uZ2VyLXVz ZWQgZXJyb3IgY29kZXMgYXMgUmVzZXJ2ZWQgaW4gZWFjaCBvZiB0aGVzZSBQUnM7IGFmdGVyIHRo ZXkgbGFuZCwgaGUgb3IgSSB3aWxsIGRvIGFub3RoZXIgUFIgdG8gY29uZGVuc2UgdGhlIGVycm9y IGNvZGUgc3BhY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBMdWNhcyBQ YXJkdWUgJmx0O2x1Y2FzcGFyZHVlLjI0LjdAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50Ojwv Yj4gU2F0dXJkYXksIEp1bmUgMTUsIDIwMTkgNTo0NCBBTTxicj4NCjxiPlRvOjwvYj4gS2F6dWhv IE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlz aG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs7IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4u aC5kdWtlQGdtYWlsLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZn dDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBBbmFseXNpbmcgdGhlIEhUVFAvMyBlcnJvciBjb2RlIHNwYWNlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgYWxsIGZvciB0aGUgaW5wdXQuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWVpbmcgc29tZSBzdXBwb3J0LCB3aXRo IHZhbHVhYmxlIHN1Z2dlc3Rpb25zLCBJIHdpbGwgc3RhcnQgb24gYSBzZXJpZXMgb2YgaXNzdWVz L1BScyB0byBsZXQgdXMgcmVmaW5lIHRoZSBzcGVjaWZpY3MuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIDEyIEp1 biAyMDE5LCAwMzo0MyBLYXp1aG8gT2t1LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthenVob29rdUBn bWFpbC5jb20iPmthenVob29rdUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTk8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lubQ8L3NwYW4+NjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaciDwvc3Bhbj4xMjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaXpTwvc3Bhbj4o PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5rC0PC9zcGFu PikgNjo0MSBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91 LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0Ozo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBJIHdhcyBwcmV2aW91c2x5IGFmZmlsaWF0ZWQgd2l0aCBhbiBIVFRQIHN0 YWNrIHRoYXQgSSBhc3N1bWUgc3RpbGwgbmVlZHMgSFRUUF9WRVJTSU9OX0ZBTExCQUNLIGZvciBz b21lIGNvcm5lciBjYXNlcyBpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgcmVuZWdvdGlh dGlvbi4mbmJzcDsgVGhpcyBXRyBwcmV2aW91c2x5IGhhZCBhIGRpc2N1c3Npb24gYWJvdXQgd2hl dGhlciBpdCBzaG91bGQgZmFsbCBiYWNrIHRvIEhUVFAvMiAobG9naWNhbCwgYnV0DQogbGlrZWx5 IGhhcyBhbGwgdGhlIHNhbWUgaW5jb21wYXRpYmxlIHNjZW5hcmlvcyB0aGF0IEhUVFAvMyBkb2Vz KSBvciBIVFRQLzEuMSwgYW5kIGNvbmNsdWRlZCB0aGF0IGl0IHdvdWxkIGJlIHNhZCB0byBtYWtl IHNvbWVvbmUgZmFsbCBmcm9tIDMgLSZndDsgMiAtJmd0OyAxLjEgd2hlbiBwcm9iYWJseSBjYW7i gJl0IGFuc3dlciBvdmVyIGFueXRoaW5nIGhpZ2hlciB0aGFuIDEuMSBhbnl3YXkuPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDApIEFwcGVuZGl4IEEuNCBjb250 YWlucyBhIGNvbnZlbmllbnQgY29tcGFyaXNvbiBvZiBIVFRQLzIgYW5kIEhUVFAvMyBlcnJvciBj b2Rlcy4gSG93ZXZlciwgaXQgc3RhdGVzIHRoYXQgSFRUUC8yJ3MgUFJPVE9DT0xfRVJST1IgaGFz IG5vIHNpbmdsZSBlcXVpdmFsZW50LCB3aGljaCBJIHRoaW5rIGlzIGluY29ycmVjdCBiZWN1YXNl IEhUVFAvMyBoYXMgSFRUUF9HRU5FUkFMX1BST1RPQ09MX0VSUk9SLjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgTW9zdGx5IGJlY2F1c2UgdGhlIHZhcmlvdXMgTUFMRk9S TUVEX0ZSQU1FIGVycm9ycyB3b3VsZCBhbHNvIGhhdmUgYmVlbiBQUk9UT0NPTF9FUlJPUiBpbiBI VFRQLzIuJm5ic3A7IFdlIGNvdWxkIG1ha2UgdGhlIHRleHQgcG9pbnQgdG8gR1BFLCB3aGlsZSBu b3RpbmcgdGhhdCBzcGVjaWZpYyBlcnJvciBjb2RlcyBoYXZlIGJlZW4gYWRkZWQgZm9yIGNlcnRh aW4gc2l0dWF0aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZn dDsgMSkgSFRUUF9XUk9OR19TVFJFQU0gYW5kIEhUVFBfVU5FWFBFQ1RFRF9GUkFNRSBhcmUgdXNl ZCBhIGxvdCBhbmQgdmVyeSBzaW1pbGFyLiBUaGUgZm9ybWVyIGlzIHVzZWQgYnkgYSBwZWVyIHRo YXQgcmVjZWl2ZXMgYSB2YWxpZCBmcmFtZSBvbiBhIHN0cmVhbSB0aGF0IGl0IHNob3VsZCBuZXZl ciBiZSBzZW50IG9uLCB0aGUgbGF0dGVyIGlzIHVzZWQgYnkgYSBwZWVyIHRoYXQgcmVjZWl2ZXMg YSB2YWxpZCBmcmFtZSBvbiBhIHN0cmVhbSB0aGF0DQogaXMgbm9ybWFsbHkgb2sgYnV0IGhhcyB0 cmFuc2l0aW9uZWQgdG8gYW4gYXBwbGljYXRpb24tbGV2ZWwgc3RyZWFtIHN0YXRlIHdoaWNoIHBy b2hpYml0cyBpdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFJhdGlvbmFsaXNpbmcgdGhlc2Ug c2VlbXMgbGlrZSBhIGxvZ2ljYWwgb3B0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgU2VlbXMgcmVhc29uYWJsZS4mbmJzcDsgSSBiZWxpZXZlIHRoZXJlIHdhcyBw cmV2aW91cyBkaXNjdXNzaW9uIGFib3V0IHBvc3NpYmx5IGNvbWJpbmluZyB0aGVtLCBidXQgSSBj YW7igJl0IGZpbmQgaXQgd2l0aCBhIGN1cnNvcnkgc2VhcmNoLjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAyKSBIVFRQX1dST05HX1NFVFRJTkdfRElSRUNUSU9O IHByZXNlbnRseSBhcHBsaWVzIHRvIGV4YWN0bHkgb25lIGNhc2UsIGEgY2xpZW50IHNlbmQgTlVN X1BMQUNFSE9MREVSLiBEZWNsYXNzaWZ5aW5nIHRoaXMgYXMgYW4gZXJyb3Igc2VlbXMgbGlrZSBh IHNlbnNpbGUgb3B0aW9uLiBUaGlzIGZyZWVzIHVwIGVycm9yIGNvZGUgMHgxLCB3aGljaCB3ZSBj YW4gbW92ZSBIVFRQX0dFTkVSQUxfUFJPVE9DT0xfRVJST1IgdG8gKG1ha2luZyBIVFRQLzMNCiBt b3JlIHNpbWlsYXIgdG8gSFRUUC8yKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDcpIFRoZXJl IGFyZSBzZXZlcmFsIGVycm9yIGNhc2VzIHJlbGF0ZWQgdG8gU0VUVElOR1M7IGEgZnJhbWUgdGhh dCBjYW4gYmUgc2VudCBtb3N0IG9uY2UgcGVyIGNvbm5lY3Rpb24uIEkgbWFkZSBhIHByb3Bvc2Fs IHRvIGFkZHJlc3MgdGhpcyBvbiBpc3N1ZSAjMjc4MyBbM108YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IEkgbmVlZCB0byB0aGluayBtb3JlIGFib3V0IHRoZSBwcm9wb3Nh bCBpbiAjMjc4MywgYnV0IHRoYXTigJlzIHNlbWktb3J0aG9nb25hbCB0byB0aGUgZXJyb3IgY29u dmVyc2F0aW9uLiZuYnNwOyBJIGxpa2UgdGhlIHN1Z2dlc3Rpb24gZnJvbSB0aGUgaW50ZXJpbSB0 byBjb25zb2xpZGF0ZSB0aGVzZSB0byBhIG1vcmUgZ2VuZXJhbCBJTlZBTElEX1NFVFRJTkdTIGVy cm9yLCB0aG91Z2ggaWYgd2UgZ28gdGhlIHJvdXRlIG9mICMyNzgzLCB0aGF0IG1pZ2h0IGJlY29t ZQ0KIGEgU1RSRUFNX0hFQURFUl9FUlJPUiDDoCBsYSAoOCkuPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDMpIEhUVFBfUFVTSF9SRUZVU0VEIGFuZCBIVFRQX1BV U0hfQUxSRUFEWV9JTl9DQUNIRSBhcmUgdmVyeSBzaW1pbGFyIGJ1dCBtYXkgYmUgdXNlZnVsIHRv IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVudCByZWFzb24gdGhhdCBjbGllbnRzIHJlamVjdCBzZXJ2 ZXIgcHVzaC4gVGhpcyBpcyBleHRyYSBmaWRlbGl0eSBvbiB0b3Agb2YgSFRUUC8yLjxicj4NCiZn dDs8YnI+DQomZ3Q7ICZndDsgNCkgVGhlcmUgYXJlIHNldmVyYWwgZXJyb3IgY29kZXMgcmVsYXRl ZCB0byBoYW5kbGluZyByZXF1ZXN0cyBhbmQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyByZXNwb25zZXM6 IEhUVFBfUkVRVUVTVF9DQU5DRUxMRUQsIEhUVFBfSU5DT01QTEVURV9SRVFVRVNULCBIVFRQX0VB UkxZX1JFU1BPTlNFLCBIVFRQX1JFUVVFU1RfUkVKRUNURUQsIC4gVGhpcyBpcyBleHRyYSBmaWRl bGl0eSB0aGFuIEhUVFAvMiBwcm92aWRlZC4gVGhpcyBtYXkgZXh0cmEgaW5mb3JtYXRpb24gbWF5 IGFsbG93IGVuZHBvaW50cyB0byBtYWtlIHNtYXJ0ZXIgZGVjaXNpb25zIGFib3V0IHJldHJ5aW5n IHJlcXVlc3RzLiBIb3dldmVyLA0KIGl0IG1heSBhbHNvIGJlIHBvc3NpYmxlIHRvIGluZmVyIHRo aW5ncyBmcm9tIGEgc3RyZWFtIGVycm9yIHRoYXQgY29udGFpbnMgc2ltcGx5IEhUVFBfTk9fRVJS T1IgKCBIVFRQX0VBUkxZX1JFU1BPTlNFIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGlzKTxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgV2UgbmVlZCB0aGUgQ0FOQ0VMTEVEL1JF SkVDVEVEIHNwbGl0IHRvIHVuZGVyc3RhbmQgd2hlbiBhIHNlcnZlciBpcyBkZWNsYXJpbmcgdGhh dCBubyBwcm9jZXNzaW5nIG9jY3VycmVkIHZlcnN1cyByZWZsZWN0aW5nIGJhY2sgdGhlIGVycm9y IGNvZGUgZnJvbSB0aGUgY2xpZW504oCZcyBTVE9QX1NFTkRJTkcgaW4gYSBSRVNFVF9TVFJFQU0u Jm5ic3A7IChUaGUgcmVzb2x1dGlvbiB0byB0aGF0IGlzIHRoYXQgY2xpZW50cyBkb27igJl0IHNl bmQgUkVKRUNURUQsDQogYW5kIGl0IGhhcyB0aGUgYWRkaXRpb25hbCBzZW1hbnRpYyB3aGVuIGNv bWluZyBmcm9tIGEgc2VydmVyLikmbmJzcDsgSWYgd2UgZGlkbuKAmXQgaGF2ZSBJTkNPTVBMRVRF X1JFUVVFU1QsIEnigJltIHVuc3VyZSB3aGF0IHdl4oCZZCBzZW5kIGluIHRoYXQgc2l0dWF0aW9u IGluc3RlYWQ7IGl04oCZcyBjZXJ0YWlubHkgbm90IGEgTk9fRVJST1Igc2l0dWF0aW9uLjxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRm9sZGluZyBFQVJMWV9SRVNQT05T RSBpbnRvIE5PX0VSUk9SIHdvdWxkIGJlIHJlYXNvbmFibGUuPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDUpIFRoZSBlcnJvciBjb2RlIGd1aWRhbmNlIGlzIG9m dGVuIG5vdCBzeW1tZXRyaWMuIENsaWVudCBvciBzZXJ2ZXJzIHVzZSBlcnJvciBjb2RlcyBkaWZm ZXJlbnRseSBhbmQgbGl0dGxlIGd1aWRhbmNlIGlzIHByb3ZpZGVkIG9uIGhvdyB0byBwcm9jZXNz IGFuIGVycm9yIGNvZGUgdGhhdCBpbiB0aGVvcnkgc2hvdWxkIG5ldmVyIGJlIHNlbnQuPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgb25seSBwb3NzaWJsZSByZXNw b25zZSBpcyBibG93aW5nIHVwIHRoZSBjb25uZWN0aW9uLCBpc27igJl0IGl0PyZuYnNwOyBXaGlj aCBpcyBzdXBlcmZsdW91cyBpZiB5b3XigJl2ZSByZWNlaXZlZCBhIG5vbnNlbnNpY2FsIGNvbm5l Y3Rpb24gZXJyb3IsIGJlY2F1c2UgdGhlIGNvbm5lY3Rpb24gaXMgYWxyZWFkeSBiZWluZyBibG93 biB1cCBieSB0aGUgcGVlci4mbmJzcDsgU28gdGhlIG1vcmUgc2NvcGVkIHF1ZXN0aW9uIGlzLCBp ZiBhIHN0cmVhbSBzZWVzIGEgUkVTRVQvU1RPUF9TRU5ESU5HDQogd2l0aCBhbiBlcnJvciBjb2Rl IHRoYXQgYSkgc2hvdWxkIG9ubHkgaGF2ZSBvcmlnaW5hdGVkIGZyb20geW91ciBzaWRlLCBvciBi KSBjYW4gb25seSBiZSBhIGNvbm5lY3Rpb24gZXJyb3IsIHdoYXQgZG8geW91IGRvPzxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyA2KSBUaGVyZSBpcyBsaXR0bGUg Z3VpZGFuY2Ugb24gaG93IGFuIGludGVybWVkaWFyeSB0aGF0IHRyYW5zbGF0ZXMgYmV0d2VlbiBI VFRQLzIgYW5kIEhUVFAvMyBzaG91bGQgbWFwIHRoZXNlIGRpdmVyZ2VudCBlcnJvciBjb2RlIHNw YWNlcy4gSXQgd291bGQgcGF5IHRvIGFsaWduIHRoZW0gYXMgY2xvc2UgYXMgcG9zc2libGUgYW5k IHByb3ZpZGUgc29tZSBndWlkYW5jZSBvbiBob3cgdG8gbWFwIGhpZ2hlciBmaWRlbGl0eSBjb2Rl cyB0byBsb3dlcg0KIGZpZGVsaXR5IGNvZGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhhdOKAmXMgYSBnb29kIHBvaW50LiZuYnNwOyBIb3dldmVyLCBlcnJvciBj b2RlcyBhcmUgaG9wLXRvLWhvcCDigJMgSSBzdXNwZWN0IHRoYXQgYW55IGVycm9yIGNvZGUgZ2V0 cyB0dXJuZWQgaW50byBhIHN0YXR1cyBjb2RlIDUwMiwgd2l0aCB0aGUgcG9zc2libGUgZXhjZXB0 aW9uIG9mIFJFSkVDVEVELiZuYnNwOyBEbyBleHBlY3QgYW55b25lIHRvIGJ1aWxkIGEgMi8zIGlu dGVybWVkaWFyeSB3aG8gaXNu4oCZdCBhbHNvIHRlcm1pbmF0aW5nIHRoZSBIVFRQIHNlbWFudGlj DQogbGF5ZXI/PGJyPg0KPGJyPg0KTm90IHRoYXQgd2UgZG8gbm93IGFzIGEgcHJveHkgaW1wbGVt ZW50YXRpb24sIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlPGJyPg0KcHJlZmVyYWJsZSB0byBwcm9w YWdhdGUgJnF1b3Q7dGVtcG9yYXJ5JnF1b3Q7IGVycm9ycyAoUkVGVVNFRF9TVFJFQU0pLCBhbmQg YWxzbzxicj4NCkNPTk5FQ1RfRVJST1IgdG8gaW5kaWNhdGUgcmVzZXQgb2YgYSB3ZWJzb2NrZXQg Y29ubmVjdGlvbi4gRm9yIGFsbDxicj4NCm90aGVyIGVycm9ycyBJIHRoaW5rIHRoYXQgNTAyIGNh biBiZSB1c2VkLjxicj4NCjxicj4NCkl0IG1pZ2h0IGJlIHdvcnRoIGNsYXJpZnlpbmcgdGhhdCBz dWNoIGJlaGF2aW9yIGlzIHRvIGJlIGV4cGVjdGVkIChvcjxicj4NCnByZWZlcmFibGUpLjxicj4N Cjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyA4KSBIVFRQX1VO S05PV05fU1RSRUFNX1RZUEUgYW5kIERVUExJQ0FURV9QVVNIIGJvdGggcmVsYXRlIHRvIHBhcnNp bmcgdGhlIHVuaWRpcmVjdGlvbmFsIHN0cmVhbSB0eXBlIGhlYWRlci4gV2UgbWlnaHQgYmUgYWJs ZSB0byBtZXJnZSB0aGVzZSBpbnRvIGEgZXJyb3Igc3VjaCBhcyBIVFRQX1NUUkVBTV9IRUFERVJf RVJST1IgYW5kIHN0YXRlIHRoZSBjb2RlIGhhcyBkaWZmZXJlbnQgYXBwbGljYWJpbGl0eSBiZXR3 ZWVuIFNUT1BfU0VORElORw0KIGFuZCBDT05ORUNUSU9OX0NMT1NFIGZyYW1lcy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IDkpIENyaXRpY2FsIHN0cmVhbXMgc3VjaCBhcyBjb250cm9sIHN0cmVh bSBhbmQgUVBBQ0sgc3RyZWFtcyBjYW4gYmUgY3JlYXRlZCBvbmx5IG9uY2U7IEhUVFBfV1JPTkdf U1RSRUFNX0NPVU5UIGNhcHR1cmVzIHRoaXMuIFB1c2ggc3RyZWFtcyBjYW4gb25seSBiZSBjcmVh dGVkIGJ5IGEgc2VydmVyIGFuZCBIVFRQX1dST05HX1NUUkVBTV9ESVJFQ1RJT04gY2FwdHVyZXMg dGhpcy4gV2UgY291bGQgcmF0aW9uYWxpc2UgdGhlc2UgaW50byBIVFRQX1NUUkVBTV9DUkVBVElP Tl9FUlJPUiwNCiB0aGF0IGNvdWxkIGV2ZW4gaW5jb3Jwb3JhdGUgc3VnZ2VzdGlvbiA4Ljxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgRFVQTElDQVRFX1BVU0ggY2FuIGFs c28gcmVmZXIgdG8gYSBzZWNvbmQgUFVTSF9QUk9NSVNFIHdpdGggdGhlIHNhbWUgUHVzaCBJRC4m bmJzcDsgT3RoZXJ3aXNlLCBhIFNUUkVBTV9IRUFERVJfRVJST1Igb3IgU1RSRUFNX0NSRUFUSU9O X0VSUk9SIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIGNvbGxhdGlvbjsgSSBhZ3JlZSB0aGF0IHRo b3NlIGFyZSB1bHRpbWF0ZWx5IHRoZSBzYW1lIHByb3Bvc2FsLjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9tOiBRVUlDICZsdDs8 YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Yy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIE1hcnRpbiBEdWtlPGJyPg0K Jmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDExLCAyMDE5IDEyOjM3IFBNPGJyPg0KJmd0OyBUbzog THVjYXMgUGFyZHVlICZsdDs8YSBocmVmPSJtYWlsdG86bHVjYXNwYXJkdWUuMjQuN0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5sdWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyBDYzogSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgUVVJQyBX RyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWlj QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBBbmFseXNpbmcgdGhlIEhU VFAvMyBlcnJvciBjb2RlIHNwYWNlPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIHdvdWxkIGluc2lzdCBvbiBJTlRFUk5BTF9FUlJPUi4gSXQgaXMgZ3JlYXQgZm9yIHZh cmlvdXMgbWFsbG9jIHByb2JsZW1zLCBhcyB3ZWxsIGFzIGZvciBzaWduYWxsaW5nIHRoYXQgc29t ZXRoaW5nIHdlbnQgd3Jvbmcgb24gdGhlIGJhY2sgZW5kIGluIHByb3h5IHNjZW5hcmlvcy4gSXQg aXMgYSBjYXRjaC1hbGwgZm9yICZxdW90O0kgc2NyZXdlZCB1cCBhbmQgY2FuJ3QgY29udGludWUm cXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUdWUsIEp1 biAxMSwgMjAxOSBhdCAxMTo1MyBBTSBMdWNhcyBQYXJkdWUgJmx0OzxhIGhyZWY9Im1haWx0bzps dWNhc3BhcmR1ZS4yNC43QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmx1Y2FzcGFyZHVlLjI0 LjdAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgSGV5 IElhbiw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBUdWUsIEp1biAxMSwgMjAxOSBhdCA3OjE0IFBN IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT25lIG5vdGFibGUgZGlm ZmVyZW5jZSBpcyB0aGF0IEhUVFAvMnMgRlJBTUVfU0laRV9FUlJPUiBjb2RlIGhhcyBiZWVuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyByZXBsYWNlZCBieSBIVFRQX01BTEZPUk1FRF9GUkFNRSwgd2hpY2gg YWN0dWFsbHkgY292ZXJzIGEgcmFuZ2Ugb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7IHZhbHVlcyAtIGl0 IGRlZGljYXRlcyBhIGJ5dGUgdG8gZW5jb2RlIHRoZSBmcmFtZSB0eXBlLiBUaGlzIGlzPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBwcm9ibGVtYXRpYyBzaW5jZSB0aGUgZnJhbWUgdHlwZSBjaGFuZ2VkIHRv IGJlIGEgNjItYml0IGludGVnZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0c2VsZi4mbmJzcDsgSW4g bXkgcGVyc29uYWwgb3BpbmlvbiwgdGhpcyBlcnJvciBjb2RlIGlzIG1vcmUgY29tcGxpY2F0ZWQ8 YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoYW4gbmVlZHMgYmUgYW5kIHdhcyBpbmNvcnJlY3RseSBhcHBs aWVkLiBJc3N1ZSAjMjU1MSBbMV0gY2FwdHVyZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoaXMsIGFu ZCBQUiAjMjY2MiBbMl0gY29udGFpbnMgYSBwcm9wb3NlZCBzZXQgb2YgcmVwbGFjZW1lbnQgY29k ZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGF0IFBSIGFkZHMgNCBlcnJvciBjb2RlcyB0byBicmlu ZyB0aGUgdG90YWwgdXAgdG8gMjguPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IEkgbGlrZSB5b3VyIHByb3Bvc2VkIFBSLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRo YW5rcy4gVGhlIFRMO0RSIG9mIHRoZSBQUiBpcyB0aGF0IGl0IGFkZCBiYWNrIEZSQU1FX1NJWkVf RVJST1IgKGZvcjxicj4NCiZndDsgdGhpbmdzIHRoYXQgYXJlIGZyYW1lIHNpemUgZXJyb3JzKSBh bmQgYWRkcyBzb21lIG5ldyBlcnJvciBjb2RlcyBpbjxicj4NCiZndDsgYWdyZWVtZW50IHdpdGgg b3VyIGN1cnJlbnQgcGhpbG9zb3BoeS4gSSB3b3VsZCByZWZpbmUgdGhlIFBSIHRvIGFncmVlPGJy Pg0KJmd0OyB3aXRoIHRoZSBvdXRjb21lIG9mIHRoaXMgdGhyZWFkLjxicj4NCiZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQW55IHRob3VnaHRzIG9uIEhUVFBfVkVSU0lPTl9GQUxM QkFDSyBhbmQgSFRUUF9JTlRFUk5BTF9FUlJPUiwgd2hpY2ggYXJlIG5ldmVyIHVzZWQ/Jm5ic3A7 IEknbSB1bmNsZWFyIG9uIHdoYXQgdGhlIGludGVuZGVkIHVzYWdlIGlzPzxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgcmVhbGlzZWQgSSBkaWRuJ3QgcXVhbGlmeSBvbmUgYXNwZWN0IG9mIG15IGFuYWx5 c2lzIC0gdGhlIGd1aWRhbmNlPGJyPg0KJmd0OyBjb3VudCBtZXRyaWMgaXMgb25seSBvbmUgc2ln bmFsLiBIVFRQX0lOVEVSTkFMX0VSUk9SIGlzIGRlc2NyaWJlZCBhczxicj4NCiZndDsgJnF1b3Q7 QW4gaW50ZXJuYWwgZXJyb3IgaGFzIG9jY3VycmVkIGluIHRoZSBIVFRQIHN0YWNrLiZxdW90Oywg d2hpY2ggZmVlbHMgbGlrZTxicj4NCiZndDsgYW4gaW1wbGVtZW50YXRpb24tb3JpZW50ZWQgZXJy b3IgY29kZS4gSSB0aGluayBpdCBpcyB2YWxpZCBpbiBzdGF5aW5nPGJyPg0KJmd0OyBpbiBIVFRQ LzMsIGVzcGVjaWFsbHkgaWYgaXQgaXMgdXNlZCBpbiBIVFRQLzIgKEkgZG9uJ3QgaGF2ZSBkYXRh IHRvPGJyPg0KJmd0OyBoYW5kIG9uIHRoYXQgdGhvdWdoKS4gSG93ZXZlciwgSFRUUF9WRVJTSU9O X0ZBTExCQUNLIGlzIGEgYml0IHdlaXJkOzxicj4NCiZndDsgaXQgc3RlbXMgZnJvbSBIVFRQLzIn cyBIVFRQXzFfMV9SRVFVSVJFRCBjb2RlLCB3aGljaCBpbiBSRkMgNzU0MCBpczxicj4NCiZndDsg b25seSByZWNvbW1lbmRlZCB3aGVuIHRoZSBzZXJ2ZXIgd2FudHMgdG8gdXNlIFRMUyByZW5lZ290 aWF0aW9uLiBJTU88YnI+DQomZ3Q7IGl0IGlzIG9mIGxpbWl0ZWQgdmFsdWUgdW5sZXNzIHdlIGlt cG9ydCB0aGUgc2FtZSBiZWhhdmlvdXIgaW50bzxicj4NCiZndDsgSFRUUC8zLjxicj4NCjxicj4N Cjxicj4NCjxicj4NCi0tIDxicj4NCkthenVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR22MB0983FCF100AFEB9B26603959DAE30CY4PR22MB0983namp_-- From nobody Tue Jun 25 16:44:59 2019 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 827691200E0 for ; Tue, 25 Jun 2019 16:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgt8vf1YRfde for ; Tue, 25 Jun 2019 16:44:55 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 792F31200CE for ; Tue, 25 Jun 2019 16:44:55 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id v129so345605vsb.11 for ; Tue, 25 Jun 2019 16:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mGYIa5SDcbgGObR3AK+/zgPVnbXntB0tuNqObADqkUg=; b=N2nVc84A1uxCHnLoMpKBx3aPpCDf4He61bP3moa/4+odFiWybaN7UPGBilR8l+LPVT 5ibJcSIY8KGiZxQsACUeeFnSuWDaM/3BhhHedax52EvCB0L4f2Hi5ghQNXwnG6ke1Pri gHYGiGQU2B8vvm20aOE2ey5f5FTWcoTdpbKHXu7Wcb0pCuyh4eDThKJeDKgOBoB8u4yD v/nCU1T4S4lybkAfL+VvMn65q0d0qfNVUKfZaIU1p6mCqu6w+s4turmh0AN1VeikYpug EU6Z6tE1i/7aZw8Ba99+Pl9f//r+wB18rfc4bUSMQo4V4gLp4yJfF5+f20I++vreAIcD RGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mGYIa5SDcbgGObR3AK+/zgPVnbXntB0tuNqObADqkUg=; b=bA5W004G0rlmofsY0iIq7lI0IMgJh5KTx4Z4onuW/Ugj7VVM/6mHTe4ohdNGTEXpyD cK8czdoa88TYlaHXckF1Yr/Vy0REnisGsRN5h2bnl+JvCPHdFElMxjwIoguXRcuTI4vc 1AU70dj5z7+E8/nw5G2G0ZmxKctvz4FcT7TSfqk4GOMzBIkLvP5HGUhLKsAfsVA2Fbf+ nPwOnCRCG1yf97e+1/Cj3Y5ebtz4B2oNdcsLgMpFnzOHAlsXAV7HYmk2p/pgSSy9ytDI Q18amitfTYOM56GPF/EUQHr0tDM33WfMHxfXDxhZrPZlFy6pMMAv3vekJsPdDiOHdUdH mxfg== X-Gm-Message-State: APjAAAXZqlz7vZkCIFA+3ETpkAPX5wkA/kG2PNaKrxJt+tlO8sf1jun1 FklK5GvCNJjuO027iMlKVxln0hsfsjKwPRiL7KM= X-Google-Smtp-Source: APXvYqwqVLc4Wc3Jo8+8ehxGJtXc5kqx6Y6shnZA49fJUUUU2q3+VxD0ql+sdakNKITNCD4bnMJUpiBop5byQuWkKEg= X-Received: by 2002:a67:d00d:: with SMTP id r13mr1012801vsi.100.1561506294336; Tue, 25 Jun 2019 16:44:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Wed, 26 Jun 2019 00:44:42 +0100 Message-ID: Subject: Re: Analysing the HTTP/3 error code space To: Mike Bishop Cc: Kazuho Oku , Martin Duke , Ian Swett , QUIC WG Content-Type: multipart/alternative; boundary="000000000000fd11a9058c2e835e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 23:44:59 -0000 --000000000000fd11a9058c2e835e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Mike, Thanks for putting that list together. I was thinking something like this would be useful to echo back to the thread, you kindly saved me the effort. My approach h was the keep issues as independent as possible, so we can continue to make progress even some turned out contentious. My plan was to do another pass once a few get merged and aim to consolidate everything down - error code rightsizing so to speak. Lucas On Wed, 26 Jun 2019, 00:29 Mike Bishop, wrote: > For those not following GitHub closely, I=E2=80=99d like to point out tha= t these > proposals have shown up as PRs, and that they have been reviewed by a few > of us over there. I plan to merge later this week, modulo any objections= . > > - #2808 makes the H2 > comparison point from PROTOCOL_ERROR to GENERAL_PROTOCOL_ERROR, while > noting that H3 has more specific error codes for some things that were= PE > in H2 > - #2813 : Expands > the use of REQUEST_CANCELLED to cancelling push streams and removes th= e > more specific error codes for why one might not want the pushed conten= t > - #2814 : Collects > anything that could be wrong with the payload of a SETTINGS frame (ser= ver > settings sent by clients, duplicates) into SETTINGS_ERROR > - #2820 : Groups > LIMIT_EXCEEDED and various misuses of Push IDs into a single error cod= e > (ID_ERROR) for any misuse of identifiers defined by HTTP > - #2822 : Groups > UNKNOWN_STREAM_TYPE, WRONG_STREAM_COUNT, and WRONG_STREAM_DIRECTION in= to a > single error code (STREAM_CREATION_ERROR) for any reason why a newly o= pened > unidirectional stream is unacceptable to the recipient > > > > If you have feedback on these, please speak now, either here or on GitHub= . > > > > Once these are in, #2662 > probably needs to be reworked slightly and should land soon as well. Luc= as > has been leaving the no-longer-used error codes as Reserved in each of > these PRs; after they land, he or I will do another PR to condense the > error code space. > > > > *From:* Lucas Pardue > *Sent:* Saturday, June 15, 2019 5:44 AM > *To:* Kazuho Oku > *Cc:* Mike Bishop ; Martin Duke < > martin.h.duke@gmail.com>; Ian Swett ; QUIC WG < > quic@ietf.org> > *Subject:* Re: Analysing the HTTP/3 error code space > > > > Thank you all for the input. > > > > Seeing some support, with valuable suggestions, I will start on a series > of issues/PRs to let us refine the specifics. > > > > > > > > On Wed, 12 Jun 2019, 03:43 Kazuho Oku, wrote: > > 2019=E5=B9=B46=E6=9C=8812=E6=97=A5(=E6=B0=B4) 6:41 Mike Bishop : > > > > I was previously affiliated with an HTTP stack that I assume still need= s > HTTP_VERSION_FALLBACK for some corner cases including, but not limited to= , > renegotiation. This WG previously had a discussion about whether it shou= ld > fall back to HTTP/2 (logical, but likely has all the same incompatible > scenarios that HTTP/3 does) or HTTP/1.1, and concluded that it would be s= ad > to make someone fall from 3 -> 2 -> 1.1 when probably can=E2=80=99t answe= r over > anything higher than 1.1 anyway. > > > > > > > > > 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HTTP/3 > error codes. However, it states that HTTP/2's PROTOCOL_ERROR has no singl= e > equivalent, which I think is incorrect becuase HTTP/3 has > HTTP_GENERAL_PROTOCOL_ERROR. > > > > > > > > Mostly because the various MALFORMED_FRAME errors would also have been > PROTOCOL_ERROR in HTTP/2. We could make the text point to GPE, while > noting that specific error codes have been added for certain situations. > > > > > > > > > 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and ver= y > similar. The former is used by a peer that receives a valid frame on a > stream that it should never be sent on, the latter is used by a peer that > receives a valid frame on a stream that is normally ok but has transition= ed > to an application-level stream state which prohibits it. > > > > > Rationalising these seems like a logical option. > > > > > > > > Seems reasonable. I believe there was previous discussion about > possibly combining them, but I can=E2=80=99t find it with a cursory searc= h. > > > > > > > > > 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one case= , > a client send NUM_PLACEHOLDER. Declassifying this as an error seems like = a > sensile option. This frees up error code 0x1, which we can move > HTTP_GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2). > > > > > 7) There are several error cases related to SETTINGS; a frame that ca= n > be sent most once per connection. I made a proposal to address this on > issue #2783 [3] > > > > > > > > I need to think more about the proposal in #2783, but that=E2=80=99s > semi-orthogonal to the error conversation. I like the suggestion from th= e > interim to consolidate these to a more general INVALID_SETTINGS error, > though if we go the route of #2783, that might become a STREAM_HEADER_ERR= OR > =C3=A0 la (8). > > > > > > > > > 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very similar > but may be useful to understand the different reason that clients reject > server push. This is extra fidelity on top of HTTP/2. > > > > > 4) There are several error codes related to handling requests and > > > > responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, > HTTP_EARLY_RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than > HTTP/2 provided. This may extra information may allow endpoints to make > smarter decisions about retrying requests. However, it may also be possib= le > to infer things from a stream error that contains simply HTTP_NO_ERROR ( > HTTP_EARLY_RESPONSE could benefit from this) > > > > > > > > We need the CANCELLED/REJECTED split to understand when a server is > declaring that no processing occurred versus reflecting back the error co= de > from the client=E2=80=99s STOP_SENDING in a RESET_STREAM. (The resolutio= n to that > is that clients don=E2=80=99t send REJECTED, and it has the additional se= mantic > when coming from a server.) If we didn=E2=80=99t have INCOMPLETE_REQUEST= , I=E2=80=99m > unsure what we=E2=80=99d send in that situation instead; it=E2=80=99s cer= tainly not a > NO_ERROR situation. > > > > > > > > Folding EARLY_RESPONSE into NO_ERROR would be reasonable. > > > > > > > > > 5) The error code guidance is often not symmetric. Client or servers > use error codes differently and little guidance is provided on how to > process an error code that in theory should never be sent. > > > > > > > > The only possible response is blowing up the connection, isn=E2=80=99t = it? > Which is superfluous if you=E2=80=99ve received a nonsensical connection = error, > because the connection is already being blown up by the peer. So the mor= e > scoped question is, if a stream sees a RESET/STOP_SENDING with an error > code that a) should only have originated from your side, or b) can only b= e > a connection error, what do you do? > > > > > > > > > 6) There is little guidance on how an intermediary that translates > between HTTP/2 and HTTP/3 should map these divergent error code spaces. I= t > would pay to align them as close as possible and provide some guidance on > how to map higher fidelity codes to lower fidelity codes. > > > > > > > > That=E2=80=99s a good point. However, error codes are hop-to-hop =E2= =80=93 I suspect > that any error code gets turned into a status code 502, with the possible > exception of REJECTED. Do expect anyone to build a 2/3 intermediary who > isn=E2=80=99t also terminating the HTTP semantic layer? > > Not that we do now as a proxy implementation, but I think it would be > preferable to propagate "temporary" errors (REFUSED_STREAM), and also > CONNECT_ERROR to indicate reset of a websocket connection. For all > other errors I think that 502 can be used. > > It might be worth clarifying that such behavior is to be expected (or > preferable). > > > > > > > > > > 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to parsing > the unidirectional stream type header. We might be able to merge these in= to > a error such as HTTP_STREAM_HEADER_ERROR and state the code has different > applicability between STOP_SENDING and CONNECTION_CLOSE frames. > > > > > 9) Critical streams such as control stream and QPACK streams can be > created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams ca= n > only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures this= . > We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could ev= en > incorporate suggestion 8. > > > > > > > > DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same > Push ID. Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR seems > like a reasonable collation; I agree that those are ultimately the same > proposal. > > > > > > > > > > > > From: QUIC On Behalf Of Martin Duke > > Sent: Tuesday, June 11, 2019 12:37 PM > > To: Lucas Pardue > > Cc: Ian Swett ; QUIC WG > > Subject: Re: Analysing the HTTP/3 error code space > > > > > > > > I would insist on INTERNAL_ERROR. It is great for various malloc > problems, as well as for signalling that something went wrong on the back > end in proxy scenarios. It is a catch-all for "I screwed up and can't > continue". > > > > > > > > On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue < > lucaspardue.24.7@gmail.com> wrote: > > > > Hey Ian, > > > > On Tue, Jun 11, 2019 at 7:14 PM Ian Swett wrote: > > > > > >> > > >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code has bee= n > > >> replaced by HTTP_MALFORMED_FRAME, which actually covers a range of > > >> values - it dedicates a byte to encode the frame type. This is > > >> problematic since the frame type changed to be a 62-bit integer > > >> itself. In my personal opinion, this error code is more complicated > > >> than needs be and was incorrectly applied. Issue #2551 [1] captures > > >> this, and PR #2662 [2] contains a proposed set of replacement codes. > > >> That PR adds 4 error codes to bring the total up to 28. > > > > > > > > > I like your proposed PR. > > > > Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for > > things that are frame size errors) and adds some new error codes in > > agreement with our current philosophy. I would refine the PR to agree > > with the outcome of this thread. > > > > > > > > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, which > are never used? I'm unclear on what the intended usage is? > > > > I realised I didn't qualify one aspect of my analysis - the guidance > > count metric is only one signal. HTTP_INTERNAL_ERROR is described as > > "An internal error has occurred in the HTTP stack.", which feels like > > an implementation-oriented error code. I think it is valid in staying > > in HTTP/3, especially if it is used in HTTP/2 (I don't have data to > > hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; > > it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 is > > only recommended when the server wants to use TLS renegotiation. IMO > > it is of limited value unless we import the same behaviour into > > HTTP/3. > > > > -- > Kazuho Oku > > --000000000000fd11a9058c2e835e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mike,

Thanks for putting that list together. I was thinking something like thi= s would be useful to echo back to the thread, you kindly saved me the effor= t.=C2=A0

My approach h w= as the keep issues as independent as possible, so we can continue to make p= rogress even some turned out contentious. My plan was to do another pass on= ce a few get merged and aim to consolidate everything down - error code rig= htsizing so to speak.=C2=A0

Lucas


On Wed, 26 Jun 2019, 00:29 Mike Bishop, <mbishop@evequefou.be> wrote:

For those not following GitHub closely, I=E2=80=99d = like to point out that these proposals have shown up as PRs, and that they = have been reviewed by a few of us over there.=C2=A0 I plan to merge later t= his week, modulo any objections.

  • #2808 makes the H2 comparison point from PROT= OCOL_ERROR to GENERAL_PROTOCOL_ERROR, while noting that H3 has more specifi= c error codes for some things that were PE in H2
  • #2813:=C2=A0 Expands the use of REQUEST_CANCELLED to c= ancelling push streams and removes the more specific error codes for why one might not want the pushed content
  • #2814:=C2=A0 Collects anything that could be wrong with the= payload of a SETTINGS frame (server settings sent by clients, duplicates) into SETTINGS_ERROR
  • #2820:= =C2=A0 Groups LIMIT_EXCEEDED and various misuses of Push IDs into a single = error code (ID_ERROR) for any misuse of identifiers defined by HTTP
  • #2822:=C2= =A0 Groups UNKNOWN_STREAM_TYPE, WRONG_STREAM_COUNT, and WRONG_STREAM_DIRECT= ION into a single error code (STREAM_CREATION_ERROR) for any reason why a newly opened unidirectional stream is unacceptable to= the recipient

=C2=A0

If you have feedback on these, please speak now, eit= her here or on GitHub.

=C2=A0

Once these are in, #2662 probably needs to be reworked slightly and should land soon as we= ll.=C2=A0 Lucas has been leaving the no-longer-used error codes as Reserved= in each of these PRs; after they land, he or I will do another PR to conde= nse the error code space.

=C2=A0

From: Lucas Pardue <lucaspardue.24= .7@gmail.com>
Sent: Saturday, June 15, 2019 5:44 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Mike Bishop <mbishop@evequefou.be>; Martin Duke &l= t;martin.h.duke@gmail.com>; Ian Swett <ianswett@google.com<= /a>>; QUIC WG <quic@ietf.org>
Subject: Re: Analysing the HTTP/3 error code space

=C2=A0

Thank you all for the input.

=C2=A0

Seeing some support, with valuable suggestions, I wi= ll start on a series of issues/PRs to let us refine the specifics.=C2=A0=

=C2=A0

=C2=A0

=C2=A0

On Wed, 12 Jun 2019, 03:43 Kazuho Oku, <kazuho= oku@gmail.com> wrote:

2019=E6=9C= =8812=E6=97=A5(=E6=B0=B4) 6:4= 1 Mike Bishop <mbishop@evequefou.be>:
>
> I was previously affiliated with an HTTP stack that I assume still nee= ds HTTP_VERSION_FALLBACK for some corner cases including, but not limited t= o, renegotiation.=C2=A0 This WG previously had a discussion about whether i= t should fall back to HTTP/2 (logical, but likely has all the same incompatible scenarios that HTTP/3 does) or HTTP/1= .1, and concluded that it would be sad to make someone fall from 3 -> 2 = -> 1.1 when probably can=E2=80=99t answer over anything higher than 1.1 = anyway.
>
>
>
> > 0) Appendix A.4 contains a convenient comparison of HTTP/2 and HT= TP/3 error codes. However, it states that HTTP/2's PROTOCOL_ERROR has n= o single equivalent, which I think is incorrect becuase HTTP/3 has HTTP_GEN= ERAL_PROTOCOL_ERROR.
>
>
>
> Mostly because the various MALFORMED_FRAME errors would also have been= PROTOCOL_ERROR in HTTP/2.=C2=A0 We could make the text point to GPE, while= noting that specific error codes have been added for certain situations. >
>
>
> > 1) HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME are used a lot and= very similar. The former is used by a peer that receives a valid frame on = a stream that it should never be sent on, the latter is used by a peer that= receives a valid frame on a stream that is normally ok but has transitioned to an application-level stream state w= hich prohibits it.
>
> > Rationalising these seems like a logical option.
>
>
>
> Seems reasonable.=C2=A0 I believe there was previous discussion about = possibly combining them, but I can=E2=80=99t find it with a cursory search.=
>
>
>
> > 2) HTTP_WRONG_SETTING_DIRECTION presently applies to exactly one = case, a client send NUM_PLACEHOLDER. Declassifying this as an error seems l= ike a sensile option. This frees up error code 0x1, which we can move HTTP_= GENERAL_PROTOCOL_ERROR to (making HTTP/3 more similar to HTTP/2).
>
> > 7) There are several error cases related to SETTINGS; a frame tha= t can be sent most once per connection. I made a proposal to address this o= n issue #2783 [3]
>
>
>
> I need to think more about the proposal in #2783, but that=E2=80=99s s= emi-orthogonal to the error conversation.=C2=A0 I like the suggestion from = the interim to consolidate these to a more general INVALID_SETTINGS error, = though if we go the route of #2783, that might become a STREAM_HEADER_ERROR =C3=A0 la (8).
>
>
>
> > 3) HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE are very simi= lar but may be useful to understand the different reason that clients rejec= t server push. This is extra fidelity on top of HTTP/2.
>
> > 4) There are several error codes related to handling requests and=
>
> responses: HTTP_REQUEST_CANCELLED, HTTP_INCOMPLETE_REQUEST, HTTP_EARLY= _RESPONSE, HTTP_REQUEST_REJECTED, . This is extra fidelity than HTTP/2 prov= ided. This may extra information may allow endpoints to make smarter decisi= ons about retrying requests. However, it may also be possible to infer things from a stream error that contains = simply HTTP_NO_ERROR ( HTTP_EARLY_RESPONSE could benefit from this)
>
>
>
> We need the CANCELLED/REJECTED split to understand when a server is de= claring that no processing occurred versus reflecting back the error code f= rom the client=E2=80=99s STOP_SENDING in a RESET_STREAM.=C2=A0 (The resolut= ion to that is that clients don=E2=80=99t send REJECTED, and it has the additional semantic when coming from a server.)=C2=A0 If we= didn=E2=80=99t have INCOMPLETE_REQUEST, I=E2=80=99m unsure what we=E2=80= =99d send in that situation instead; it=E2=80=99s certainly not a NO_ERROR = situation.
>
>
>
> Folding EARLY_RESPONSE into NO_ERROR would be reasonable.
>
>
>
> > 5) The error code guidance is often not symmetric. Client or serv= ers use error codes differently and little guidance is provided on how to p= rocess an error code that in theory should never be sent.
>
>
>
> The only possible response is blowing up the connection, isn=E2=80=99t= it?=C2=A0 Which is superfluous if you=E2=80=99ve received a nonsensical co= nnection error, because the connection is already being blown up by the pee= r.=C2=A0 So the more scoped question is, if a stream sees a RESET/STOP_SEND= ING with an error code that a) should only have originated from your side, or = b) can only be a connection error, what do you do?
>
>
>
> > 6) There is little guidance on how an intermediary that translate= s between HTTP/2 and HTTP/3 should map these divergent error code spaces. I= t would pay to align them as close as possible and provide some guidance on= how to map higher fidelity codes to lower fidelity codes.
>
>
>
> That=E2=80=99s a good point.=C2=A0 However, error codes are hop-to-hop= =E2=80=93 I suspect that any error code gets turned into a status code 502= , with the possible exception of REJECTED.=C2=A0 Do expect anyone to build = a 2/3 intermediary who isn=E2=80=99t also terminating the HTTP semantic layer?

Not that we do now as a proxy implementation, but I think it would be
preferable to propagate "temporary" errors (REFUSED_STREAM), and = also
CONNECT_ERROR to indicate reset of a websocket connection. For all
other errors I think that 502 can be used.

It might be worth clarifying that such behavior is to be expected (or
preferable).

>
>
>
> > 8) HTTP_UNKNOWN_STREAM_TYPE and DUPLICATE_PUSH both relate to par= sing the unidirectional stream type header. We might be able to merge these= into a error such as HTTP_STREAM_HEADER_ERROR and state the code has diffe= rent applicability between STOP_SENDING and CONNECTION_CLOSE frames.
>
> > 9) Critical streams such as control stream and QPACK streams can = be created only once; HTTP_WRONG_STREAM_COUNT captures this. Push streams c= an only be created by a server and HTTP_WRONG_STREAM_DIRECTION captures thi= s. We could rationalise these into HTTP_STREAM_CREATION_ERROR, that could even incorporate suggestion 8.
>
>
>
> DUPLICATE_PUSH can also refer to a second PUSH_PROMISE with the same P= ush ID.=C2=A0 Otherwise, a STREAM_HEADER_ERROR or STREAM_CREATION_ERROR see= ms like a reasonable collation; I agree that those are ultimately the same = proposal.
>
>
>
>
>
> From: QUIC <quic-bounces@ietf.org> On Behalf Of Martin Du= ke
> Sent: Tuesday, June 11, 2019 12:37 PM
> To: Lucas Pardue <lucaspardue.24.7@gmail.com>
> Cc: Ian Swett <ianswett@google.com>; QUIC WG <quic@ietf.org>
> Subject: Re: Analysing the HTTP/3 error code space
>
>
>
> I would insist on INTERNAL_ERROR. It is great for various malloc probl= ems, as well as for signalling that something went wrong on the back end in= proxy scenarios. It is a catch-all for "I screwed up and can't co= ntinue".
>
>
>
> On Tue, Jun 11, 2019 at 11:53 AM Lucas Pardue <lucaspardue.= 24.7@gmail.com> wrote:
>
>=C2=A0 Hey Ian,
>
> On Tue, Jun 11, 2019 at 7:14 PM Ian Swett <ianswett@google.com= > wrote:
> >
> >>
> >> One notable difference is that HTTP/2s FRAME_SIZE_ERROR code = has been
> >> replaced by HTTP_MALFORMED_FRAME, which actually covers a ran= ge of
> >> values - it dedicates a byte to encode the frame type. This i= s
> >> problematic since the frame type changed to be a 62-bit integ= er
> >> itself.=C2=A0 In my personal opinion, this error code is more= complicated
> >> than needs be and was incorrectly applied. Issue #2551 [1] ca= ptures
> >> this, and PR #2662 [2] contains a proposed set of replacement= codes.
> >> That PR adds 4 error codes to bring the total up to 28.
> >
> >
> > I like your proposed PR.
>
> Thanks. The TL;DR of the PR is that it add back FRAME_SIZE_ERROR (for<= br> > things that are frame size errors) and adds some new error codes in > agreement with our current philosophy. I would refine the PR to agree<= br> > with the outcome of this thread.
>
> >
> > Any thoughts on HTTP_VERSION_FALLBACK and HTTP_INTERNAL_ERROR, wh= ich are never used?=C2=A0 I'm unclear on what the intended usage is? >
> I realised I didn't qualify one aspect of my analysis - the guidan= ce
> count metric is only one signal. HTTP_INTERNAL_ERROR is described as > "An internal error has occurred in the HTTP stack.", which f= eels like
> an implementation-oriented error code. I think it is valid in staying<= br> > in HTTP/3, especially if it is used in HTTP/2 (I don't have data t= o
> hand on that though). However, HTTP_VERSION_FALLBACK is a bit weird; > it stems from HTTP/2's HTTP_1_1_REQUIRED code, which in RFC 7540 i= s
> only recommended when the server wants to use TLS renegotiation. IMO > it is of limited value unless we import the same behaviour into
> HTTP/3.



--
Kazuho Oku

--000000000000fd11a9058c2e835e-- From nobody Tue Jun 25 21:15:34 2019 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 37CDB120222 for ; Tue, 25 Jun 2019 21:15:32 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ddaMKJKq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ACouvsEG 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 OPz6p8TQRbTc for ; Tue, 25 Jun 2019 21:15:29 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FDC1201B0 for ; Tue, 25 Jun 2019 21:15:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D170821B84 for ; Wed, 26 Jun 2019 00:15:28 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 26 Jun 2019 00:15:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=CAuwwUfeKv+f887TnzXiYby6orL78ho hWSDTgquO0bI=; b=ddaMKJKq9l/Pn3XCM2F0+T1tLJpb4GcFifVMyCfDcv1g42r jqpQfSimgEHaj1z29frnfrkEYD+18Jsa5ZfGhXa/EYUZbtmiE4M4JlCaWMdSrs7h adohZYD6DUEmNJQ8sUAXa7eiaPE+N+1kDOO1JkJozBAYBGLJx9nRfS3flWCNrrLi AFgzpdU1g2o6sJLoN1o6UG7r8OEWXmNX7zqc/Jq/giymZBqsbPotDDfirsQ3z3AD REbB6N5Od0qz0VDu5THbNFGi2CG9E/ZUAc1O9IbHcDlGrufhgZt0aqdlz0MS893b IiwLXnQisXhHqho5k30QWNUnhDI3yY2fhy2ih2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=CAuwwU feKv+f887TnzXiYby6orL78hohWSDTgquO0bI=; b=ACouvsEGo2PH/AAydaLQEq bsGqd6AljLs9rQ2dWASx9Z+QOLO5ocBhUgzqRwhJW1o2E966mHyJH03IXgqHtnFI mNTAwErgD/To61JC68s6ARwSwCtexk1IzIUw9zG1Qs+Mw3K2bzIQoBVSxFh0kpMV VMVidBhPqDidkfHALIhxuWm5eJnbvxuycHshkgHqJeLgsYLlR0Pg0AiBU/y0J0zB ujMccU5rB9ZieVJohHX9AsIALH0D26gX7EpXvPnLWSSwBVonw7TIqhdsaB6cKtvS UH41JV/eu8MIOgWQMULxgua/MVMPD+6v5nSG119LKF1NGYAro0dpbSV3LVmJt0mg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpmhhnoh htrdhnvghtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3AFAFE00A2; Wed, 26 Jun 2019 00:15:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-730-g63f2c3b-fmstable-20190622v1 Mime-Version: 1.0 Message-Id: <54cb0af3-6c07-4c2d-879f-f085a286380a@www.fastmail.com> In-Reply-To: References: <23A6C02C-174B-4A98-8E10-A2814B427A37@mnot.net> <46035944-B522-47D1-A572-509BEC8DFC0B@mnot.net> Date: Wed, 26 Jun 2019 14:15:30 +1000 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Consensus Call: More Connection ID Space #2736 Content-Type: text/plain Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 26 Jun 2019 04:15:32 -0000 Thanks for all the work Martin! Tracking discussion isn't pleasant. On Wed, Jun 26, 2019, at 02:41, Martin Duke wrote: > Option (2) is now represented in the PR. > > On Mon, Jun 24, 2019 at 5:19 PM Martin Duke wrote: > > OK, expect to see a revised PR Tuesday, Pacific time. > > > > On Sun, Jun 23, 2019 at 7:44 PM Mark Nottingham wrote: > >> Hi Ted, > >> > >> It looks like we're gravitating towards 20 bits (in QUICv1) -- if that's where we end up, is this still something you'd like to see resolved first? > >> > >> Cheers, > >> > >> > >> > On 13 Jun 2019, at 2:16 am, Ted Hardie wrote: > >> > > >> > Hi Mark, > >> > > >> > https://github.com/quicwg/base-drafts/issues/2770 was raised in part because of this change, and it is not resolved. While I do not expect that it will cause a reversion of this design theory, it might be useful to wait on declaring consensus for this until it resolves, in case the resolution suggests a limit change. > >> > > >> > Could we encourage folks to test with the higher limits and new encoding for now, but not close the issue? > >> > > >> > regards, > >> > > >> > Ted > >> > > >> > On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham wrote: > >> > Regarding: > >> > > >> > > >> > The editors believe that this PR resolved the issue: > >> > > >> > > >> > .....and discussion so far seems to support consensus to do so. If you object, please do so on the issue or in response to this message; absent any pushback, we'll declare consensus at the end of the week. > >> > > >> > Regards, > >> > > >> > -- > >> > Mark Nottingham https://www.mnot.net/ > >> > > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> From nobody Thu Jun 27 09:26:48 2019 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 C5F1A120112 for ; Thu, 27 Jun 2019 09:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 t-Q9KtCrSbs2 for ; Thu, 27 Jun 2019 09:26:45 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 0A00B12014B for ; Thu, 27 Jun 2019 09:26:45 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id a15so6339952wmj.5 for ; Thu, 27 Jun 2019 09:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gAW/RamkcRRuBZfOEArgA8oBDuXf/TP4jYGbOLBD3XM=; b=JtwQMyrQ3bm4yjEMXhfiqpGaZpaC2j/CZnUejTl5BjgPcirEMDXJTpeYbudM9mg7FD lEK2r8RK65jkMQWd+GvaX6bZr5oNcTiAQ/SCFejEFkiALVmHJltB1d7VuhfMhXrvuu2F tDX37DoYrkt4leCJzbWlx4qGSCFthJq/zG5YNcSens8fp8Y7dfbe6rGFV2gtgrKyIsIT ax5eXZmOHGsbTSWXxi47nZLipTQXIWIik5rJMSK/RA0A4I2oetEPQpgP/Tov1gXbf/zb N/tpvgnWiC8mqCRChLVNkEwQLLw1hnuiLGWcfQrBAgfqn+jQco0f3B3OD1fUwPJJdtv4 A1nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gAW/RamkcRRuBZfOEArgA8oBDuXf/TP4jYGbOLBD3XM=; b=fjTNWB4An6RNhCTR+9/mo/VXzCsrsntlXq/1ix83yAOaOF82MMlUZV1oq+lFprzmGD O47We1H57sKnheMqAx6pP+J5AkrXHhtTEjLjDRXgy47WmMB+mjS8Yl0bdEJ6OjAle3yg HYA7JAxwxIxZQv8uKCZPMgKN005uSZtEtA+eryez7FHGsvMjizwAkctjmdXF5bJWbk14 aeBpv2ITBvp0Mb1zb5iVqZVg4sd5MjntnC3UvIyLuh0hNyvFOKgm15n7ssyknoUR7ODP wAkGbIraEo/J73mhd+XbtOoYxByvwtjen46KAojDSOCYKPJ7rbqUDos1tkFJJpHq9WzO wBGg== X-Gm-Message-State: APjAAAUKB+mfcgWoSUcTgShKa3eD7fSpHEnGQlq/mwPE3GSeAS34UIf5 Y3RQcK44fzcOOrdLf0STu+XECDcsVhlHbzMOxg0us0sypNU= X-Google-Smtp-Source: APXvYqyfnP1bbigq7jO2aSa4InyMUkciYDLxtODoFRzRvVuxkfYqQLXEcjc6aGcWu3P0TGKsAl+vW7/hii9aDOL3u50= X-Received: by 2002:a05:600c:389:: with SMTP id w9mr3603765wmd.139.1561652803354; Thu, 27 Jun 2019 09:26:43 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Thu, 27 Jun 2019 09:26:32 -0700 Message-ID: Subject: QUIC_ERROR_PMTU_TOO_SMALL? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000009b49b6058c50a01f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jun 2019 16:26:47 -0000 --0000000000009b49b6058c50a01f Content-Type: text/plain; charset="UTF-8" Sec 14.1: If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below the size needed to support the smallest allowed maximum packet size, it MUST immediately cease sending QUIC packets, except for PMTU probe packets, on the affected path. An endpoint MAY terminate the connection if an alternative path cannot be found. If we tear down a connection because we don't have a path that supports 1280 bytes, show should we communicate that to the peer? There should probably be an error code for this. If there are no objections, I'll file an issue. --0000000000009b49b6058c50a01f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

W= hen it wakes up it wants to transmit some data and process inbound messages= .
It does not= want to spend time or power on establishing a new connection and 0-RTT is = not ideal for several reasons: it requires a roundtrip before data are reli= able and most connection state is lost and must be renegotiated.

QUIC has a potentially long idl= e timeout so it could deal with a device that is waking up.
One problem may be how retra= nsmission is handled - will the peer be tolerant to a 1 minute delay before= seeing an ACK?

Anoth= er problem is middleboxes. While not solveable in general, it might be wort= h considering to offer a signal that indicates that the usual timeouts do n= ot apply - the IP might not even be the same if a DHCP server assigns a new= IP on wakeup, but it still has the CID.


Mikkel
--000000000000099e90058c8fc293-- From nobody Sun Jun 30 14:31:56 2019 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 6305F1201CA for ; Sun, 30 Jun 2019 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 hxtakjvE-ag5 for ; Sun, 30 Jun 2019 14:31:53 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 8BB0B1201CC for ; Sun, 30 Jun 2019 14:31:53 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id 5so7787525ybj.10 for ; Sun, 30 Jun 2019 14:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sxz3jpwHLoxUesLJb2W2FUhuNe0lDya6R8r3gODNzfA=; b=fRMxcrBJgpFRuYI1SV8zVO6vfdIHTEXRrsCiz3GMYkZ1eETtTeGGGE27ITzw6fTEps YhLpZV7kEb9+x5Z6db02vIY3ZSbMlVtG1vRx9jLEW2OmFyZsVKN4yWYG7m78g+IUa9DG ntHKjL0Sjwb6Nv3kcCD6oVYty/eAWSQ5d2FI2O++47udw8CJaXdMQ4FHgztTG6zaMSnB ePB6k6bo1Q6Qd7Fb8eu8AEGEdvQwr/q2SB2wniUT6kRxEYuEbiVLMeUCX/cFxW3mVJ4K tj8M4Z3L3S1zQ25IgSnXB6kLNStx1JHWMU6ZuOGxZCgy1rDGvCCaY9/J/CFZpP1JRaGu 1KmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sxz3jpwHLoxUesLJb2W2FUhuNe0lDya6R8r3gODNzfA=; b=OLZRy/3RIPnwDcy6LmsB4cwZbNQHuoXddVUWrw6SJzs974WlSpQUxL2squuO42NxE1 831mmbNgr913808wZMDdKcdyovdJNq/D9iKqjv24bPXgA6aHvjnHjC3ssbiTs/BiIzE8 daIU42npyaMyyPFl/8sa0lVx9jRV0/nfxR2TsMLvQ0AQ4B7w6n23M0oEypPIkL7gSrJI L3/X3H7IGgEimlbrtZrYlH4+APW1EdD+PjJkQlBqTJgggaVLRSe6nUsDomcCdkPKH/PP +W4u0mLe1QotOXXLzFobuxV+hbboWAzb+7nhEAmneHc5I+JJcKRTwr+NKSSBO2tBromq P5yg== X-Gm-Message-State: APjAAAXcQ8uvlEEkdDA+JvtemVIToemdKGcW7+qkGO6Vjzs8YBlQpFLa jI2X9z+TibDRVDDPVZqF8oAIjSGymst2a9V80uk= X-Google-Smtp-Source: APXvYqzARS7wuOC2ci6NttZuNuQAKCoPdsrvgo6fEb8VKeP5KU+GIegfn8zUxwzPKUQpR1MV63Sc9/+yhlOa8TrzrIQ= X-Received: by 2002:a25:33d5:: with SMTP id z204mr13574419ybz.498.1561930312421; Sun, 30 Jun 2019 14:31:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Mon, 1 Jul 2019 00:31:36 +0300 Message-ID: Subject: Re: Low power deep sleep pattern To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 21:31:55 -0000 On Sun, Jun 30, 2019 at 10:46 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Consider a scenario where a small IoT device > is able to store its state in flash and go to deep > sleep for a while. > > When it wakes up it wants to transmit some > data and process inbound messages.. > It does not want to spend time or power on > establishing a new connection and 0-RTT is > not ideal for several reasons: it requires a > roundtrip before data are reliable and most > connection state is lost and must be > renegotiated. This is =E2=80=94 and always was =E2=80=94 a complicated scenario for datag= ram-based protocols. It was even discussed with regards to DTLS a couple of times before. IIRC such a behaviour has always been left up to implementations because advising for any hard-coded decisions here could be seen as advocating for bad designs. E.g. what if your device was intended to sleep for a minute but suffered a power outage and went live a month later instead, and the peer certificate might have expired or been revoked =E2=80=94 how are you going to check this if you're just "un-freezi= ng" a session from flash? Session renegotiation/resumption was always meant to be used for those cases. (I'm personally not going to say though that this will actually *prevent* bad designs in IoT =E2=80=94 in fact, quite the opposite.) > QUIC has a potentially long idle timeout Do you mean "potentially infinite"? Yes, this is how it's probably going to be used in embedded code. https://github.com/quicwg/base-drafts/pull/1765 -- T=C3=B6ma From nobody Sun Jun 30 14:45:17 2019 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 82C5F1201CD for ; Sun, 30 Jun 2019 14:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 RS_nST0EVGse for ; Sun, 30 Jun 2019 14:45:13 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 CE9E81201CE for ; Sun, 30 Jun 2019 14:45:13 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id p2so7793548ybl.13 for ; Sun, 30 Jun 2019 14:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/M+sufJku1BiI+xyUCVqyz3Xw6KCcorRuaA+CHUqETU=; b=TPXcYbas7tYP2AjSEnirTeX3mwGB4Texsoat+ybT5ZhDSSoam0II2atUawfGLjdugk UCj0Z9Du7bvRH8oV3CYNm98q4M3DoCaXtGebKkJx3J3SY10FziaAfajinpGTn5wfifUS IJHJj/z2xindZjpmmai2YTaRCMjeefHGJDFn3KePpyoNzyXz9cfEZ5YIi+/ZZoDDuGCo gL5DEdO7EaoXWJDDGFUVrpYymNmi0zxIo5f3QvC5KMtUT2wlkCvdqyRiDVxZUS8bwt0v ondajBlJLuBXSm4SCUQ4eO2Osxa9NFYHUAP+JMBlLmX3qUWL63EzY2wfhTVw7V9hL/r6 gYSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/M+sufJku1BiI+xyUCVqyz3Xw6KCcorRuaA+CHUqETU=; b=je46iBoCIDYp841VaS3OvbrKp3vgupuAA8/f5XEx9evbDEXmKzCSZ5MC5Opyw8+v3c 8O3UOuQQw2qivdG7DPVu2YlFw/Zd4DB+1MLz1hNnu6K1T98t60acZqfhmBRh7EECgGc1 5B03paMLdgYSYuYyMMBw1of+THh+F5wcMvdrG+5WLaEW/qmRYyFzXliy5ZYqhr5KVVqP k2kutrX7GxzG0xhLPetugIcN/MXq+J1YHqED1NwIqXjrX178x5gqXC8wwEtbcZXp/qIU 5ieqfboXQkOnWlzysbGkeJNFi+IJxcv6rcyXY4VqK2ItDS2mMT9MkgxQBeeOvM6Xbfv6 /HUg== X-Gm-Message-State: APjAAAUmpJFdViP1wCREI0GqFr4uQhO4ATaPnuoAG33WN1dlpxxfJkTW 4mEWgEl7GNFX/f6qw+SjAplkjGEUN4Byt7h/O/w= X-Google-Smtp-Source: APXvYqySjG4QJdobelwjiy9otuSAIEIz2SSVu9BtfhzUDEh7LjFIgN0eb2SQKgajLErsqEkoF2fM9eGhYNU6i+QXdoo= X-Received: by 2002:a25:7782:: with SMTP id s124mr2036980ybc.312.1561931112625; Sun, 30 Jun 2019 14:45:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Mon, 1 Jul 2019 00:44:57 +0300 Message-ID: Subject: Re: Low power deep sleep pattern To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 21:45:16 -0000 On Sun, Jun 30, 2019 at 10:46 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Another problem is middleboxes. While not > solveable in general, it might be worth > considering to offer a signal that indicates > that the usual timeouts do not apply That's a signal to whom? Generic middleboxes are unlikely to ever consider respecting such a signal, b/c of limited RAM if not anything else. For the peer, the infinite idle timeout negotiated (together with application-specific details, known to the application developers, of the protocol running on top of QUIC or HTTP/3) should be a signal in itself I think. Usually, you don't expect IoT devices to land on the same app gateways as browsers do, so that's a distinction to be made infrastructure-wise, not protocol-wise. -- T=C3=B6ma From nobody Sun Jun 30 14:52:05 2019 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 B578F1201D3 for ; Sun, 30 Jun 2019 14:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLeEd5ZJNuUp for ; Sun, 30 Jun 2019 14:52:01 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 5CD511201D1 for ; Sun, 30 Jun 2019 14:52:01 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id z25so19335447edq.9 for ; Sun, 30 Jun 2019 14:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xpRmITBbh0ty7HecC3g6pUR0e4uaSr0CVmc7QrH9P3Q=; b=RX4fywpbcnVYMIulZ0hksYNaJJbxaK6NVsgcHuhFly40BGpiAhNwfc3kx/rxW2vazt rfw960Btb4KzVBbms+JBfztT+hoBtZJYlbNF4VqTESLBUqfYsb4uAMZL8pWgeRsAm9Ym arPSFC+u7SfYCfU9YjhygugVCL9JFH9At4xmlJUM68pBHIG7ddDPjKAWlxo42oGnGIJ2 Gx3Jv/iSDevrFAvB097BU0DZ7nZ2dabx1UXOziWSKzSw8VVI5Qj4NJoTWn5R+Nsves1C 1PyBHAvueNZrPjOdaKWIu3pLelRRjXey+hkwqeP1SPqlGZkUFx2uya6mgJ01xWkfW9ha /MLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xpRmITBbh0ty7HecC3g6pUR0e4uaSr0CVmc7QrH9P3Q=; b=lGGjnp8/UVIIU5g/VAQctaEY6aXab+X8uRqRuyTKgEhFMjF0dsc/wnGdNg3q3LdEWa BEyZicouxhdWz8ToyJaESb8L0K9SrQoX5PtqAilLTAl8PCyqu5vxKQmLKgr+upGEX4x7 0S42xvxr0MfWtR8KYTRIBCUEUJI9zaL7hNMQ5Bkguh7qJal4CxKdkTT1BCU1AOnBwpCT UKl1VGvTpN1/AUOLl3cEKGOMoGPnk9j/y9UVNT0QSgi5u2GQk6+bhIAZlGKJZynOq7H+ Bfg1p6iQrROfidT0gBQWHU7dk2rLhXu4Kk5dxn1Yc/L6kPXkkh1LUPsI/KUBNIMFS6w7 K2mg== X-Gm-Message-State: APjAAAUojTr3XlESwTHMCOWBxzQtqbFhS+mDc9QO8Be27acZEZieoukc Azaw9sFB7j1zH7DMNnGTpz+lONiP2TLbECqGjOh7sXXx X-Google-Smtp-Source: APXvYqxis089E/6yFbdwGYi9nUjcU35NVk8Ok544vVpaLyxaYRbfTYEllphbCO97h/0CXRDsxxBf4iK3/OpE6L45ENg= X-Received: by 2002:a50:f5c2:: with SMTP id x2mr24912771edm.13.1561931519828; Sun, 30 Jun 2019 14:51:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 30 Jun 2019 14:51:59 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 30 Jun 2019 14:51:59 -0700 Message-ID: Subject: Re: Low power deep sleep pattern To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000672783058c918577" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 21:52:03 -0000 --000000000000672783058c918577 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m not so much concerned with the path towards the app gateway, bu= t the last/first mile with a shady wlan router, or whatever. I don=E2=80=99t expect most of these to be useful, but if there is a signal= , there is a market for routers that can deal with this. Today UDP NAT is far too short lived. That is likely to change, but IoT might happen later. A signal would help in that regard. Further inland, the CID might get invalidated over a period of hours or days, no one really knows. But I imagine a device will wake up periodically, like every 1-60 minutes, but not more often, since that might make deep sleep inefficient, and/or require someone to take a hike with a new battery a bit too often. Hence, the CID liveness is not really a concern, again, those in the market of supporting these thing will make allowances. On 30 June 2019 at 23.45.13, T=C3=B6ma Gavrichenkov (ximaera@gmail.com) wro= te: On Sun, Jun 30, 2019 at 10:46 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Another problem is middleboxes. While not > solveable in general, it might be worth > considering to offer a signal that indicates > that the usual timeouts do not apply That's a signal to whom? Generic middleboxes are unlikely to ever consider respecting such a signal, b/c of limited RAM if not anything else. For the peer, the infinite idle timeout negotiated (together with application-specific details, known to the application developers, of the protocol running on top of QUIC or HTTP/3) should be a signal in itself I think. Usually, you don't expect IoT devices to land on the same app gateways as browsers do, so that's a distinction to be made infrastructure-wise, not protocol-wise. --=20 T=C3=B6ma --000000000000672783058c918577 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m not so m= uch concerned with the path towards the app gateway, but the last/first mil= e with a shady wlan router, or whatever.
I don=E2=80=99t expect most of these to be usef= ul, but if there is a signal, there is a market for routers that can deal w= ith this.
Tod= ay UDP NAT is far too short lived. That is likely to change, but IoT might = happen later. A signal would help in that regard.

Further inland, the CID might get invalidated = over a period of hours or days, no one really knows. But I imagine a device= will
wake up= periodically, like every 1-60 minutes, but not more often, since that migh= t make deep sleep inefficient, and/or require someone to take a hike with a= new battery a bit too often.

Hence, the CID liveness is not really a concern, again, those in t= he market of supporting these thing will make allowances.




On 30 June 2019 at 23.45.13, T=C3=B6ma Gavrichenkov (ximaera@gmail.com) wrote:

On Sun, Jun 30, 2019 at 10:= 46 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen
<mikkelfj@gmail.com> wr= ote:
> Another problem is middleboxes. While not
> solveable in general, it might be worth
> considering to offer a signal that indicates
> that the usual timeouts do not apply

That's a signal to whom? Generic middleboxes are unlikely to ever
consider respecting such a signal, b/c of limited RAM if not anything
else.

For the peer, the infinite idle timeout negotiated (together with
application-specific details, known to the application developers, of
the protocol running on top of QUIC or HTTP/3) should be a signal in
itself I think. Usually, you don't expect IoT devices to land on t= he
same app gateways as browsers do, so that's a distinction to be mad= e
infrastructure-wise, not protocol-wise.

--
T=C3=B6ma
--000000000000672783058c918577-- From nobody Sun Jun 30 15:30:04 2019 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 92DED1201D1 for ; Sun, 30 Jun 2019 15:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 TGRRJoCO1o44 for ; Sun, 30 Jun 2019 15:30:01 -0700 (PDT) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 B07661201CD for ; Sun, 30 Jun 2019 15:30:01 -0700 (PDT) Received: by mail-yw1-xc33.google.com with SMTP id u141so4923379ywe.4 for ; Sun, 30 Jun 2019 15:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=B43PIBDkahpPJWnDewwuphWM1PcgzpZoDgi6aeF5ezU=; b=GnzD2CGxihZj153jJWr7jFotMuoXWMh3/GunsWqgOXzyzEG1UEN/iliu3eiWB0mE1H WKsl+jVQISCwEGFzNw955Xm95oQzqnAr0FnGhlbJqdumfuz1iGriEqqwUCwJ9yrM8Xgb R0y4k10rrAOcAykH0DPGtGgMgndvdjO7hZr287UXIsKkvxxIV7UQGocicrqQ/gN8C90e yghEM7RQQ8zplT9CUf35dX0AtWxKT4aPxHOw9STDR7dPflIwJzm59pxQH2doBysoJML8 UljoUAeFs+8U7rvKgrLiCkHEkTfmdAFNBcuvIXFm7RaAs+ZhfhLLvKBPKSEqiXdKuTxB q6Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=B43PIBDkahpPJWnDewwuphWM1PcgzpZoDgi6aeF5ezU=; b=id7aJ42mXFNSBffvxK20zaH529QrjuhgEl+uc9ZT5H5jv/WBH0EYVC5AcbIT6hAHyI a6epOIaiSdszRUWybfpZys5ZD9xGJibfvFHillHAM0rIlBaxTan2l6QlWAK7XT/fiqMe t+Q/xpheqeTDqmnN6DnmkNQNvdnKCDdmFR8lsUN3V0TiKr7ER7jGzyYMswwIztoGT2at 8ccFAxm7S2gpPwtFD5DgBgzALtlgBLEZCmb3YwjgxAC757tKbWF9yBHtxA/M+QZV2a4k BFXtlyAFzyJLo700YSGT1vhRXeMEjCl/0YzPbrDTs5/U/XrrGGCyv6Dm2Z0M8YHWrLzY kONw== X-Gm-Message-State: APjAAAWgpnVbsY8BvefD77RoUkd4BtMn1a3JOvJHo/H5Lp4cm9WhaW3A tQFJA+malw6o2H17Yc+uDsX7wVXhNGPRmmJoYTQ= X-Google-Smtp-Source: APXvYqzqbVBjViBpsJs+ejAZl5u/yv6Zfa2P16Pj0gQoB6H8vjMdnfRXCSZSkZ88qEZ9T9zd+2HJP4O0BMaCruhlU30= X-Received: by 2002:a81:2545:: with SMTP id l66mr12274201ywl.489.1561933800774; Sun, 30 Jun 2019 15:30:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Mon, 1 Jul 2019 01:29:44 +0300 Message-ID: Subject: Re: Low power deep sleep pattern To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 22:30:04 -0000 On Mon, Jul 1, 2019 at 12:52 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I=E2=80=99m not so much concerned with the path > towards the app gateway, but the last/first > mile with a shady wlan router, or whatever. > > I don=E2=80=99t expect most of these to be useful, > but if there is a signal, there is a market > for routers that can deal with this. For all (I'm not even going to beat around the bush with "most of") the stuff in the middle a timeout is never something optional, it's only mandatory. Computational resources are never infinite, so neither must be timeouts for long-dead sessions, initiated by long-dead devices =E2=80=94 which are sometimes just being replaced along w= ith their batteries b/c some of those devices appear obsolete even before they run out of power and it's at times operationally cheaper not to care about the rest of the boxes in the fleet. An exception from the rule might be made for a session peer only, because the latter (hopefully) knows how many clients or devices it's meant to be handling. It's still not a perfect design, but it's sort of acceptable under certain conditions where it's =E2=80=94 again, operationally =E2=80=94 cheaper not to care about corner cases. For a middlebox, things are much less predictable; it only knows (at best, even) how many sessions it *could* handle, thus can never allow for an infinite session data storage while being otherwise reliable. > Today UDP NAT is far too short lived. I can't really say there's no reason for that. -- T=C3=B6ma From nobody Sun Jun 30 19:21:48 2019 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 B08111201EE for ; Sun, 30 Jun 2019 19:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Jt1fdd5+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uQSgopaT 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 UXqRsokSnZrY for ; Sun, 30 Jun 2019 19:21:43 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B498A1201E9 for ; Sun, 30 Jun 2019 19:21:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 959DF21C48; Sun, 30 Jun 2019 22:21:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 30 Jun 2019 22:21:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=fm3; bh=EZD0OEhUKA8BpzWOFzHQ/jACE2EM/U YzsDBD6+9jX2A=; b=Jt1fdd5+5cI81sEo/gwzCcESiG9BFiwKwPvesgYSTV2xBP DWVsqHt5pyLVKQv5xfD2vgxhVah5ViOJmzsb8cxc+zyYjVCT/r7yhq7p/FVzaM3I Rf/oqCdg0twkFM3vLWxawVVAzv26tQJ9N6iWJvrLdVeA68M3E9BeszlQXsI+MV3A ZSvLvJQCyCdHM3oKqWdwgO2K2grYbrOuKL6oTLGXxwG/MamX5jjbL4/Oo/uu6tKc yCJlJFcxj0hDmX+AxopOMqY/7qU94Qklz6ShbpRmxj6zVi6qknZ01Ngd7u9kuXDO Unzjaz1suWSc6zSek1LHx3Z9cGToZ3wtdK3Kc1cQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EZD0OE hUKA8BpzWOFzHQ/jACE2EM/UYzsDBD6+9jX2A=; b=uQSgopaTCa8i/Oy4i9Z3uK GFVrtNTuVCoGHlmnvRG+FZJvlUtWrviabCRtIw6WZiApddsrn7rDxGZUrJ2BwlFt yQ/Z01XOlSzC9t0xt/ScbP7Ub8VBgpOtzhbqUyLQpqfT+BPXMoCapYULfH1bFszZ LlblM6jnoacn2SF0+Wm8SC/pqQm8DtX+u+9Bo/F2iMib+dlWSeiI0CTQlJoFQZ+s vliip+T1zjpEg2St08BhuLc3Ob64OPx6wz0vDmnUjRSAsPG8Mg7ENWcXPR/b8H/2 8XuyQDrc/4jBTz0UO+wmYpWjs15PyPFEbtzmKil0piaUfCv7IKRxCkSttF44pJ6Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdehgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgih hthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddv keenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id C969E80060; Sun, 30 Jun 2019 22:21:38 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Consensus Calls on Recent Transport/TLS Issues Message-Id: Date: Mon, 1 Jul 2019 12:21:35 +1000 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 01 Jul 2019 02:21:47 -0000 The following issues have proposals for resolution, and discussion so = far seems to support consensus to accept them. If you object, please do = so on the issue or in response to this message (changing the Subject = appropriately!). See for the current = state of issues in the Late Stage process. * #2839: Consider adding flags transport parameter for extension, frame, = or feature negotiation The proposal is to close this issue with 'quicv2' -- i.e., no current = action. * #2724: Clarify PATH_RESPONSE lack of retransmission in Path Validation Proposal: * #2645: Retire My Own CID Proposal: * #2638: max_ack_delay is unknown when a new connection is established Proposal: * #2546: ACK of ACK are useful Proposal: * #2309: Migration before handshake completed is very messy Proposal: * #2736: More Connection ID Space Revised proposal: -- Mark Nottingham https://www.mnot.net/
Sec 14.1:
If a QU=
IC endpoint determines that the PMTU between any pair of local
   and remote IP addresses has fallen below the size needed to support
   the smallest allowed maximum packet size, it MUST immediately cease
   sending QUIC packets, except for PMTU probe packets, on the affected
   path.  An endpoint MAY terminate the connection if an alternative
   path cannot be found.


If we tear down a connection because we don't= have a path that supports 1280 bytes, show should we communicate that to t= he peer? There should probably be an error code for this.

If there are no objections, I'll file an issue.
--0000000000009b49b6058c50a01f-- From nobody Thu Jun 27 09:51:38 2019 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 85ED91201D4 for ; Thu, 27 Jun 2019 09:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDP6cEV_IDFx for ; Thu, 27 Jun 2019 09:51:22 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927F4120112 for ; Thu, 27 Jun 2019 09:51:22 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x5RGkb7L021198; Thu, 27 Jun 2019 17:51:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=P+ArC1O1l/ov1IeRt7P/Zwv3MgCQTNTuZ//sXhRalhc=; b=nLMp4K9GGeTAvFLn4WTLXEVlI1FH86O44k7ojRDEqgqw+pkB18X9sAC4lLeY4hlx6X1m GRRxo8pTrBcUCugLut7TaFfoVyV875VwrRVDIPycj+ZQN0VaFo2b9yrIlFKm79lxGo1l Pn2ZhkmQpwZg4GknNIeeZ6DA9vVgLDVTxO7/vQ2qVPrlcz/wvmOZEylnVnznvE0ka/jY 2SRPun0+qewY0fzUtIpwMFzVvPxg28WMjLqIAs1PmjOytr47HQfCaCdnMiZ1eOt0or+g BB7VU8U6+3+YwsHQKnWdKfiB0iRl1cxnTH1OQrmGld2nRD3qAtesRoA8tMOD82gz39XN 6w== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2tcf2dkx9m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 17:51:21 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5RGmIq6025738; Thu, 27 Jun 2019 12:51:20 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2tcdy1mrph-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 12:51:19 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 11:50:50 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1473.004; Thu, 27 Jun 2019 11:50:50 -0500 From: "Lubashev, Igor" To: Martin Duke , IETF QUIC WG Subject: RE: QUIC_ERROR_PMTU_TOO_SMALL? Thread-Topic: QUIC_ERROR_PMTU_TOO_SMALL? Thread-Index: AQHVLQW9iALWP/Yl20KtgH0KqESFwKavsfxA Date: Thu, 27 Jun 2019 16:50:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.104] Content-Type: multipart/alternative; boundary="_000_c7e335ef64804db08d33f1b06ea12f99ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=549 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270193 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=580 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270192 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jun 2019 16:51:28 -0000 --_000_c7e335ef64804db08d33f1b06ea12f99ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBleHBlY3QgbW9zdCBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IGJlIGFibGUgdG8gKG9yIGNh cmUgdG8pIHRlbGwgYSBkaWZmZXJlbmNlIGJldHdlZW4gUE1UVSBzaHJpbmtpbmcgYmVsb3cgMTI4 MCBhbmQgdGhlIHBhdGggdG8gdGhlIHBlZXIgYmVjb21pbmcgYSBibGFjayBob2xlIGVudGlyZWx5 LiAgSS5lLiBtb3N0IGxpa2VseSBJQ01QIHJlcG9ydGluZyBQTVRVIGJlbG93IHRoZSBhY2NlcHRh YmxlIHZhbHVlIHdvdWxkIGJlIGRyb3BwZWQgb24gYSBzdXNwaWNpb24gb2YgZm9yZ2VyeSAobWFu LW9uLWEtc2lkZSBhdHRhY2spLCB3aGlsZSBQTVRVIHByb2JlcyBzbWFsbGVyIHRoYW4gMTI4MCB3 b3VsZCBuZXZlciBiZSBzZW50ICh0aGUgY29ubmVjdGlvbiBjYW5ub3QgY29udGludWUgcmVnYXJk bGVzcyBvZiB3aGV0aGVyIHRoZXkgc3VjY2VlZCBvciBmYWlsKS4NCg0KT2YgY291cnNlLCBhbiBp bXBsZW1lbnRhdGlvbiBjb3VsZCB0cnkgdG8gbWFrZSBhIGd1ZXNzIGFuZCBzZW5kIHRoYXQgQ09O TkVDVElPTl9DTE9TRSBvbiBhIGNoYW5jZSBpdCB3aWxsIGdldCB0aHJvdWdoLCBhbmQgaXQgd291 bGQgbmVlZCBhbiBlcnJvciBjb2RlLiAgQnV0IHNlbmRpbmcgc3VjaCBlcnJvciBjb2RlIHNob3Vs ZCBiZSBlbnRpcmVseSBvcHRpb25hbCAobGlrZSBpbiBNQVkpLg0KDQoNCiAgKiAgIElnb3INCg0K RnJvbTogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPg0KU2VudDogVGh1cnNk YXksIEp1bmUgMjcsIDIwMTkgMTI6MjcgUE0NClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBRVUlDX0VSUk9SX1BNVFVfVE9PX1NNQUxMPw0KDQpTZWMgMTQuMToNCg0K SWYgYSBRVUlDIGVuZHBvaW50IGRldGVybWluZXMgdGhhdCB0aGUgUE1UVSBiZXR3ZWVuIGFueSBw YWlyIG9mIGxvY2FsDQoNCiAgIGFuZCByZW1vdGUgSVAgYWRkcmVzc2VzIGhhcyBmYWxsZW4gYmVs b3cgdGhlIHNpemUgbmVlZGVkIHRvIHN1cHBvcnQNCg0KICAgdGhlIHNtYWxsZXN0IGFsbG93ZWQg bWF4aW11bSBwYWNrZXQgc2l6ZSwgaXQgTVVTVCBpbW1lZGlhdGVseSBjZWFzZQ0KDQogICBzZW5k aW5nIFFVSUMgcGFja2V0cywgZXhjZXB0IGZvciBQTVRVIHByb2JlIHBhY2tldHMsIG9uIHRoZSBh ZmZlY3RlZA0KDQogICBwYXRoLiAgQW4gZW5kcG9pbnQgTUFZIHRlcm1pbmF0ZSB0aGUgY29ubmVj dGlvbiBpZiBhbiBhbHRlcm5hdGl2ZQ0KDQogICBwYXRoIGNhbm5vdCBiZSBmb3VuZC4NCg0KDQpJ ZiB3ZSB0ZWFyIGRvd24gYSBjb25uZWN0aW9uIGJlY2F1c2Ugd2UgZG9uJ3QgaGF2ZSBhIHBhdGgg dGhhdCBzdXBwb3J0cyAxMjgwIGJ5dGVzLCBzaG93IHNob3VsZCB3ZSBjb21tdW5pY2F0ZSB0aGF0 IHRvIHRoZSBwZWVyPyBUaGVyZSBzaG91bGQgcHJvYmFibHkgYmUgYW4gZXJyb3IgY29kZSBmb3Ig dGhpcy4NCg0KSWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMsIEknbGwgZmlsZSBhbiBpc3N1ZS4N Cg== --_000_c7e335ef64804db08d33f1b06ea12f99ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NzE1MTExMzA7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTY1MjE4OTU2IDEzMTI2OTgyMDAgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxNjsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGV4cGVjdCBtb3N0IGltcGxlbWVudGF0aW9ucyB3b3VsZCBub3Qg YmUgYWJsZSB0byAob3IgY2FyZSB0bykgdGVsbCBhIGRpZmZlcmVuY2UgYmV0d2VlbiBQTVRVIHNo cmlua2luZyBiZWxvdyAxMjgwIGFuZCB0aGUgcGF0aCB0byB0aGUgcGVlciBiZWNvbWluZyBhIGJs YWNrIGhvbGUgZW50aXJlbHkuJm5ic3A7IEkuZS4gbW9zdCBsaWtlbHkgSUNNUCByZXBvcnRpbmcg UE1UVSBiZWxvdyB0aGUgYWNjZXB0YWJsZSB2YWx1ZQ0KIHdvdWxkIGJlIGRyb3BwZWQgb24gYSBz dXNwaWNpb24gb2YgZm9yZ2VyeSAobWFuLW9uLWEtc2lkZSBhdHRhY2spLCB3aGlsZSBQTVRVIHBy b2JlcyBzbWFsbGVyIHRoYW4gMTI4MCB3b3VsZCBuZXZlciBiZSBzZW50ICh0aGUgY29ubmVjdGlv biBjYW5ub3QgY29udGludWUgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZXkgc3VjY2VlZCBvciBm YWlsKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2YgY291cnNlLCBhbiBpbXBsZW1lbnRhdGlv biBjb3VsZCB0cnkgdG8gbWFrZSBhIGd1ZXNzIGFuZCBzZW5kIHRoYXQgQ09OTkVDVElPTl9DTE9T RSBvbiBhIGNoYW5jZSBpdCB3aWxsIGdldCB0aHJvdWdoLCBhbmQgaXQgd291bGQgbmVlZCBhbiBl cnJvciBjb2RlLiZuYnNwOyBCdXQgc2VuZGluZyBzdWNoIGVycm9yIGNvZGUgc2hvdWxkIGJlIGVu dGlyZWx5IG9wdGlvbmFsIChsaWtlIGluIE1BWSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JZ29yPG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5k dWtlQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDI3LCAy MDE5IDEyOjI3IFBNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFFVSUNfRVJST1JfUE1UVV9UT09fU01BTEw/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlYyAx NC4xOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVm b3JlOnBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6 bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4 dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JZiBhIFFVSUMgZW5kcG9pbnQgZGV0ZXJtaW5lcyB0aGF0IHRoZSBQTVRV IGJldHdlZW4gYW55IHBhaXIgb2YgbG9jYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYW5kIHJlbW90ZSBJUCBhZGRy ZXNzZXMgaGFzIGZhbGxlbiBiZWxvdyB0aGUgc2l6ZSBuZWVkZWQgdG8gc3VwcG9ydDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyB0aGUgc21hbGxlc3QgYWxsb3dlZCBtYXhpbXVtIHBhY2tldCBzaXplLCBpdCBNVVNUIGlt bWVkaWF0ZWx5IGNlYXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNlbmRpbmcgUVVJQyBwYWNrZXRzLCBleGNlcHQg Zm9yIFBNVFUgcHJvYmUgcGFja2V0cywgb24gdGhlIGFmZmVjdGVkPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHBhdGgu Jm5ic3A7IEFuIGVuZHBvaW50IE1BWSB0ZXJtaW5hdGUgdGhlIGNvbm5lY3Rpb24gaWYgYW4gYWx0 ZXJuYXRpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgcGF0aCBjYW5ub3QgYmUgZm91bmQuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgdGVhciBkb3duIGEgY29u bmVjdGlvbiBiZWNhdXNlIHdlIGRvbid0IGhhdmUgYSBwYXRoIHRoYXQgc3VwcG9ydHMgMTI4MCBi eXRlcywgc2hvdyBzaG91bGQgd2UgY29tbXVuaWNhdGUgdGhhdCB0byB0aGUgcGVlcj8gVGhlcmUg c2hvdWxkIHByb2JhYmx5IGJlIGFuIGVycm9yIGNvZGUgZm9yIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZXJlIGFyZSBubyBv YmplY3Rpb25zLCBJJ2xsIGZpbGUgYW4gaXNzdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c7e335ef64804db08d33f1b06ea12f99ustx2exdag1mb5msgcorpak_-- From nobody Thu Jun 27 12:49:54 2019 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 86F121202E8 for ; Thu, 27 Jun 2019 12:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtbgSLTsBiAk for ; Thu, 27 Jun 2019 12:49:50 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 958C31202B6 for ; Thu, 27 Jun 2019 12:49:50 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id z23so6797700wma.4 for ; Thu, 27 Jun 2019 12:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gmprAttOiX4t5a7iX8L02qEWsJB1K/sytjXF+wuyPLY=; b=RNiBFzwQLkMnPi6o/bEIhYJayBirmFeGlZjvPH3YymdxbWPWcloqnv4NbE7JsRCtHm Ea+klnH2IovE/fJMF57OReUofn45UJtJUCe/6H2GY/v70g4NddlKtfo0W+35Wz5YZyrD X6j8u44qBdgTE1cCawNj8LjH8MIVmwI4MJXHiE4FEKk/Rc1yHfE7Fq82m2RA8B1u8pfL YUdPvbhLQmZuFLf9qA4vmDdStqnLzDnXlyb/4T7jJBGZkQ5LgD8Ym5Iff63eITKiuflR ev7K4r2nqS2EuPZ9l/AUqPIZ5ICIZYNTXzb78Y+WcFerXsVPD/B/K1tw8abupfLDLZZp mkBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gmprAttOiX4t5a7iX8L02qEWsJB1K/sytjXF+wuyPLY=; b=iWztQU7VsELyFsPo6H6PbgFsVKEedv+p168N/S26lOhLnFpVkFnX43H7ubccN0fnc+ GN5qEwNyCCHeUEm/6k+tx5J/54RenZIadU6AbLAQDa3SgLf7guxFlEZYPzwrycUsp9E2 ta0Xz/9TUnjrwqMPudIePum0dCTx8yQIq3JY1FGQDpm+uPoMhX+nEM9KH/B9/KDA6HBS HlHQILVPUTQyno4rtoHq5DLPUJru8vq+iNGygFL8Ky/B4wvYsaq+R41TE0t30ksrKm/o vMt6KjnEeJl2DQATGGN1oMydQlgHy7gFdOVFhIe3uuILTcXKIlPD1gWcrATUoGOc8vy3 wlTQ== X-Gm-Message-State: APjAAAUk0j3sfbjHqU1b7yE3M9nCjMCHFXWEx2e6R5PnXMw+izxesKzf uttVHYjzvNEMjNaAF6J3PWlcPk+GuzJZPFRBfpk= X-Google-Smtp-Source: APXvYqwNaESFl+E/YQBYovIVD4m9a0NThWG74PDo8oGZCKsKJ67xxv3EupN+yTGs0jsVlvAWPUtnqYYs/WDQrT50gxo= X-Received: by 2002:a05:600c:389:: with SMTP id w9mr4089473wmd.139.1561664988973; Thu, 27 Jun 2019 12:49:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Thu, 27 Jun 2019 12:49:37 -0700 Message-ID: Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL? To: "Lubashev, Igor" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ed1536058c53762c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jun 2019 19:49:53 -0000 --000000000000ed1536058c53762c Content-Type: text/plain; charset="UTF-8" The scenario I have in mind is that the handshake completes because the PMTU is between 1228 and 1280, but when the endpoint figures this out it has to send a CONN_CLOSE (which would definitely make it through) On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor wrote: > I expect most implementations would not be able to (or care to) tell a > difference between PMTU shrinking below 1280 and the path to the peer > becoming a black hole entirely. I.e. most likely ICMP reporting PMTU below > the acceptable value would be dropped on a suspicion of forgery > (man-on-a-side attack), while PMTU probes smaller than 1280 would never be > sent (the connection cannot continue regardless of whether they succeed or > fail). > > > > Of course, an implementation could try to make a guess and send that > CONNECTION_CLOSE on a chance it will get through, and it would need an > error code. But sending such error code should be entirely optional (like > in MAY). > > > > - Igor > > > > *From:* Martin Duke > *Sent:* Thursday, June 27, 2019 12:27 PM > *To:* IETF QUIC WG > *Subject:* QUIC_ERROR_PMTU_TOO_SMALL? > > > > Sec 14.1: > > If a QUIC endpoint determines that the PMTU between any pair of local > > and remote IP addresses has fallen below the size needed to support > > the smallest allowed maximum packet size, it MUST immediately cease > > sending QUIC packets, except for PMTU probe packets, on the affected > > path. An endpoint MAY terminate the connection if an alternative > > path cannot be found. > > > > > > If we tear down a connection because we don't have a path that supports > 1280 bytes, show should we communicate that to the peer? There should > probably be an error code for this. > > > > If there are no objections, I'll file an issue. > --000000000000ed1536058c53762c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The scenario I have in mind is that the handshake complete= s because the PMTU is between 1228 and 1280, but when the endpoint figures = this out it has to send a CONN_CLOSE (which would definitely make it throug= h)

On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor <ilubashe@akamai.com> wrote:

I expect most implementations would not be able to (= or care to) tell a difference between PMTU shrinking below 1280 and the pat= h to the peer becoming a black hole entirely.=C2=A0 I.e. most likely ICMP r= eporting PMTU below the acceptable value would be dropped on a suspicion of forgery (man-on-a-side attack), while P= MTU probes smaller than 1280 would never be sent (the connection cannot con= tinue regardless of whether they succeed or fail).

=C2=A0

Of course, an implementation could try to make a gue= ss and send that CONNECTION_CLOSE on a chance it will get through, and it w= ould need an error code.=C2=A0 But sending such error code should be entire= ly optional (like in MAY).

=C2=A0

  • Igor

=C2=A0

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Thursday, June 27, 2019 12:27 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: QUIC_ERROR_PMTU_TOO_SMALL?

=C2=A0

Sec 14.1:

If a QUIC endpo=
int determines that the PMTU between any pair of local=

=C2=A0=C2=A0 and remote IP addresses has f=
allen below the size needed to support
=C2=A0=C2=A0 the smallest allowed maximum =
packet size, it MUST immediately cease
=C2=A0=C2=A0 sending QUIC packets, except =
for PMTU probe packets, on the affected
=C2=A0=C2=A0 path.=C2=A0 An endpoint MAY t=
erminate the connection if an alternative
=C2=A0=C2=A0 path cannot be found.<=
u>

=C2=A0

=C2=A0

If we tear down a connection because we don't ha= ve a path that supports 1280 bytes, show should we communicate that to the = peer? There should probably be an error code for this.

=C2=A0

If there are no objections, I'll file an issue.<= u>

--000000000000ed1536058c53762c-- From nobody Thu Jun 27 13:32:41 2019 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 9E5D1120018 for ; Thu, 27 Jun 2019 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ6kdwXsPRzL for ; Thu, 27 Jun 2019 13:32:36 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6EA12004E for ; Thu, 27 Jun 2019 13:32:36 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x5RKW0kF001129; Thu, 27 Jun 2019 21:32:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=yMB3ZW1H0sl5+N93bF7tXRIG77yiNpJG7sQRw31yOMA=; b=imp1+J33Cj131lmhkAS0mIH8C4JJS+vCLe3AbTacGsHqltiJGjKhmmGoQyBLjsrbZq4x tIqRgU/3h5+5ww5VG5rQ4YT6ixkaSlfBvas1zqzfsjjInY8v9M5f1BUgACSZhPEsGfcQ ZJkgaJb7ldpMVCiE6oNcbnsOj+Vmo4evMrzNUrVcsZJXLZAFriy/bCkRWaOVwAoXaBaw 9luKK42JKsrfGyhg9lf4+HEqrrFKWuT1/I6Tyo2/7WYzIdhsQHVp+rjUHnAH4EkKFL/b Nea3y0RZI7qoObYT5QcxKrB1pEUf0SwcvD/ogQNKoWFtkFWY2z5b0kR9Hn7jt3bsDmh1 LA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2tcethvr6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 21:32:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5RKWS6h024072; Thu, 27 Jun 2019 16:32:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2tccwpfgww-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 16:32:30 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 15:32:26 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1473.004; Thu, 27 Jun 2019 15:32:26 -0500 From: "Lubashev, Igor" To: Martin Duke CC: IETF QUIC WG Subject: RE: QUIC_ERROR_PMTU_TOO_SMALL? Thread-Topic: QUIC_ERROR_PMTU_TOO_SMALL? Thread-Index: AQHVLQW9iALWP/Yl20KtgH0KqESFwKavsfxAgACKsID//7dkUA== Date: Thu, 27 Jun 2019 20:32:26 +0000 Message-ID: <9dd5b8a53bda4799bff551241de67b9d@ustx2ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.104] Content-Type: multipart/alternative; boundary="_000_9dd5b8a53bda4799bff551241de67b9dustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=750 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270236 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=796 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270236 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 27 Jun 2019 20:32:41 -0000 --_000_9dd5b8a53bda4799bff551241de67b9dustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB1bmRlcnN0YW5kLiAgSSB3YXMgc3VnZ2VzdGluZyB0aGF0IG1vc3QgZW5kcG9pbnRzIHdpbGwg bm90IOKAnGZpZ3VyZSB0aGlzIG91dOKAnSwgYXMgdGhleSB3b3VsZCBub3QgYmUgYWJsZSB0byB0 ZWxsIOKAnFBNVFUgaXMgdG9vIGxvd+KAnSBmcm9tIOKAnGEgYmxhY2tob2xlIGRldmVsb3BlZCBv biB0aGUgcGF0aCB0byB0aGUgcGVlcuKAnS4NCg0KRnJvbTogTWFydGluIER1a2UgPG1hcnRpbi5o LmR1a2VAZ21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIEp1bmUgMjcsIDIwMTkgMzo1MCBQTQ0K VG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KQ2M6IElFVEYgUVVJQyBX RyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBRVUlDX0VSUk9SX1BNVFVfVE9PX1NNQUxM Pw0KDQpUaGUgc2NlbmFyaW8gSSBoYXZlIGluIG1pbmQgaXMgdGhhdCB0aGUgaGFuZHNoYWtlIGNv bXBsZXRlcyBiZWNhdXNlIHRoZSBQTVRVIGlzIGJldHdlZW4gMTIyOCBhbmQgMTI4MCwgYnV0IHdo ZW4gdGhlIGVuZHBvaW50IGZpZ3VyZXMgdGhpcyBvdXQgaXQgaGFzIHRvIHNlbmQgYSBDT05OX0NM T1NFICh3aGljaCB3b3VsZCBkZWZpbml0ZWx5IG1ha2UgaXQgdGhyb3VnaCkNCg0KT24gVGh1LCBK dW4gMjcsIDIwMTkgYXQgOTo1MSBBTSBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNv bTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+IHdyb3RlOg0KSSBleHBlY3QgbW9zdCBpbXBs ZW1lbnRhdGlvbnMgd291bGQgbm90IGJlIGFibGUgdG8gKG9yIGNhcmUgdG8pIHRlbGwgYSBkaWZm ZXJlbmNlIGJldHdlZW4gUE1UVSBzaHJpbmtpbmcgYmVsb3cgMTI4MCBhbmQgdGhlIHBhdGggdG8g dGhlIHBlZXIgYmVjb21pbmcgYSBibGFjayBob2xlIGVudGlyZWx5LiAgSS5lLiBtb3N0IGxpa2Vs eSBJQ01QIHJlcG9ydGluZyBQTVRVIGJlbG93IHRoZSBhY2NlcHRhYmxlIHZhbHVlIHdvdWxkIGJl IGRyb3BwZWQgb24gYSBzdXNwaWNpb24gb2YgZm9yZ2VyeSAobWFuLW9uLWEtc2lkZSBhdHRhY2sp LCB3aGlsZSBQTVRVIHByb2JlcyBzbWFsbGVyIHRoYW4gMTI4MCB3b3VsZCBuZXZlciBiZSBzZW50 ICh0aGUgY29ubmVjdGlvbiBjYW5ub3QgY29udGludWUgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRo ZXkgc3VjY2VlZCBvciBmYWlsKS4NCg0KT2YgY291cnNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3Vs ZCB0cnkgdG8gbWFrZSBhIGd1ZXNzIGFuZCBzZW5kIHRoYXQgQ09OTkVDVElPTl9DTE9TRSBvbiBh IGNoYW5jZSBpdCB3aWxsIGdldCB0aHJvdWdoLCBhbmQgaXQgd291bGQgbmVlZCBhbiBlcnJvciBj b2RlLiAgQnV0IHNlbmRpbmcgc3VjaCBlcnJvciBjb2RlIHNob3VsZCBiZSBlbnRpcmVseSBvcHRp b25hbCAobGlrZSBpbiBNQVkpLg0KDQoNCiAgKiAgIElnb3INCg0KRnJvbTogTWFydGluIER1a2Ug PG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4+ DQpTZW50OiBUaHVyc2RheSwgSnVuZSAyNywgMjAxOSAxMjoyNyBQTQ0KVG86IElFVEYgUVVJQyBX RyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBRVUlDX0VS Uk9SX1BNVFVfVE9PX1NNQUxMPw0KDQpTZWMgMTQuMToNCg0KSWYgYSBRVUlDIGVuZHBvaW50IGRl dGVybWluZXMgdGhhdCB0aGUgUE1UVSBiZXR3ZWVuIGFueSBwYWlyIG9mIGxvY2FsDQoNCiAgIGFu ZCByZW1vdGUgSVAgYWRkcmVzc2VzIGhhcyBmYWxsZW4gYmVsb3cgdGhlIHNpemUgbmVlZGVkIHRv IHN1cHBvcnQNCg0KICAgdGhlIHNtYWxsZXN0IGFsbG93ZWQgbWF4aW11bSBwYWNrZXQgc2l6ZSwg aXQgTVVTVCBpbW1lZGlhdGVseSBjZWFzZQ0KDQogICBzZW5kaW5nIFFVSUMgcGFja2V0cywgZXhj ZXB0IGZvciBQTVRVIHByb2JlIHBhY2tldHMsIG9uIHRoZSBhZmZlY3RlZA0KDQogICBwYXRoLiAg QW4gZW5kcG9pbnQgTUFZIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBpZiBhbiBhbHRlcm5hdGl2 ZQ0KDQogICBwYXRoIGNhbm5vdCBiZSBmb3VuZC4NCg0KDQpJZiB3ZSB0ZWFyIGRvd24gYSBjb25u ZWN0aW9uIGJlY2F1c2Ugd2UgZG9uJ3QgaGF2ZSBhIHBhdGggdGhhdCBzdXBwb3J0cyAxMjgwIGJ5 dGVzLCBzaG93IHNob3VsZCB3ZSBjb21tdW5pY2F0ZSB0aGF0IHRvIHRoZSBwZWVyPyBUaGVyZSBz aG91bGQgcHJvYmFibHkgYmUgYW4gZXJyb3IgY29kZSBmb3IgdGhpcy4NCg0KSWYgdGhlcmUgYXJl IG5vIG9iamVjdGlvbnMsIEknbGwgZmlsZSBhbiBpc3N1ZS4NCg== --_000_9dd5b8a53bda4799bff551241de67b9dustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbTE0MzcxNzA2 MTYwODc0Njk5MDltc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tMTQzNzE3MDYxNjA4NzQ2OTkw OW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tMTQzNzE3MDYxNjA4NzQ2OTkwOW1zb2xpc3Rw YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8xNDM3MTcwNjE2MDg3NDY5OTA5bXNv bGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjU0NDYwNDQzNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NDA3OTkwNjt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVu ZGVyc3RhbmQuJm5ic3A7IEkgd2FzIHN1Z2dlc3RpbmcgdGhhdCBtb3N0IGVuZHBvaW50cyB3aWxs IG5vdCDigJxmaWd1cmUgdGhpcyBvdXTigJ0sIGFzIHRoZXkgd291bGQgbm90IGJlIGFibGUgdG8g dGVsbCDigJxQTVRVIGlzIHRvbyBsb3figJ0gZnJvbSDigJxhIGJsYWNraG9sZSBkZXZlbG9wZWQg b24gdGhlIHBhdGggdG8gdGhlIHBlZXLigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSZndDsgPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5IDM6NTAgUE08YnI+DQo8Yj5U bzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogUVVJQ19FUlJPUl9QTVRVX1RPT19TTUFMTD88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2NlbmFyaW8gSSBoYXZlIGluIG1pbmQg aXMgdGhhdCB0aGUgaGFuZHNoYWtlIGNvbXBsZXRlcyBiZWNhdXNlIHRoZSBQTVRVIGlzIGJldHdl ZW4gMTIyOCBhbmQgMTI4MCwgYnV0IHdoZW4gdGhlIGVuZHBvaW50IGZpZ3VyZXMgdGhpcyBvdXQg aXQgaGFzIHRvIHNlbmQgYSBDT05OX0NMT1NFICh3aGljaCB3b3VsZCBkZWZpbml0ZWx5IG1ha2Ug aXQgdGhyb3VnaCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgSnVuIDI3LCAyMDE5IGF0IDk6NTEgQU0gTHViYXNoZXYsIElnb3IgJmx0OzxhIGhy ZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBleHBlY3QgbW9zdCBpbXBsZW1lbnRhdGlvbnMg d291bGQgbm90IGJlIGFibGUgdG8gKG9yIGNhcmUgdG8pIHRlbGwgYSBkaWZmZXJlbmNlIGJldHdl ZW4gUE1UVSBzaHJpbmtpbmcgYmVsb3cgMTI4MCBhbmQgdGhlIHBhdGggdG8gdGhlIHBlZXIgYmVj b21pbmcgYSBibGFjayBob2xlIGVudGlyZWx5LiZuYnNwOyBJLmUuDQogbW9zdCBsaWtlbHkgSUNN UCByZXBvcnRpbmcgUE1UVSBiZWxvdyB0aGUgYWNjZXB0YWJsZSB2YWx1ZSB3b3VsZCBiZSBkcm9w cGVkIG9uIGEgc3VzcGljaW9uIG9mIGZvcmdlcnkgKG1hbi1vbi1hLXNpZGUgYXR0YWNrKSwgd2hp bGUgUE1UVSBwcm9iZXMgc21hbGxlciB0aGFuIDEyODAgd291bGQgbmV2ZXIgYmUgc2VudCAodGhl IGNvbm5lY3Rpb24gY2Fubm90IGNvbnRpbnVlIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGV5IHN1 Y2NlZWQgb3IgZmFpbCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PZiBjb3Vyc2UsIGFu IGltcGxlbWVudGF0aW9uIGNvdWxkIHRyeSB0byBtYWtlIGEgZ3Vlc3MgYW5kIHNlbmQgdGhhdCBD T05ORUNUSU9OX0NMT1NFIG9uIGEgY2hhbmNlIGl0IHdpbGwgZ2V0IHRocm91Z2gsIGFuZCBpdCB3 b3VsZCBuZWVkIGFuIGVycm9yIGNvZGUuJm5ic3A7IEJ1dCBzZW5kaW5nIHN1Y2ggZXJyb3IgY29k ZQ0KIHNob3VsZCBiZSBlbnRpcmVseSBvcHRpb25hbCAobGlrZSBpbiBNQVkpLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbTE0MzcxNzA2MTYwODc0Njk5MDltc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWdvcjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9y IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gTWFydGluIER1a2UgJmx0OzxhIGhyZWY9 Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi5o LmR1a2VAZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVu ZSAyNywgMjAxOSAxMjoyNyBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBRVUlDX0VSUk9SX1BNVFVfVE9PX1NNQUxMPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ U2VjIDE0LjE6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJicmVh ay1iZWZvcmU6cGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQt Y2Fwczpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlh bDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPklmIGEgUVVJQyBlbmRwb2ludCBkZXRlcm1pbmVzIHRoYXQgdGhl IFBNVFUgYmV0d2VlbiBhbnkgcGFpciBvZiBsb2NhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBhbmQgcmVtb3RlIElQ IGFkZHJlc3NlcyBoYXMgZmFsbGVuIGJlbG93IHRoZSBzaXplIG5lZWRlZCB0byBzdXBwb3J0PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IHRoZSBzbWFsbGVzdCBhbGxvd2VkIG1heGltdW0gcGFja2V0IHNpemUsIGl0IE1V U1QgaW1tZWRpYXRlbHkgY2Vhc2U8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2VuZGluZyBRVUlDIHBhY2tldHMsIGV4 Y2VwdCBmb3IgUE1UVSBwcm9iZSBwYWNrZXRzLCBvbiB0aGUgYWZmZWN0ZWQ8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg cGF0aC4mbmJzcDsgQW4gZW5kcG9pbnQgTUFZIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiBpZiBh biBhbHRlcm5hdGl2ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXRoIGNhbm5vdCBiZSBmb3VuZC48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB3ZSB0ZWFy IGRvd24gYSBjb25uZWN0aW9uIGJlY2F1c2Ugd2UgZG9uJ3QgaGF2ZSBhIHBhdGggdGhhdCBzdXBw b3J0cyAxMjgwIGJ5dGVzLCBzaG93IHNob3VsZCB3ZSBjb21tdW5pY2F0ZSB0aGF0IHRvIHRoZSBw ZWVyPyBUaGVyZSBzaG91bGQgcHJvYmFibHkgYmUgYW4gZXJyb3IgY29kZSBmb3IgdGhpcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklm IHRoZXJlIGFyZSBubyBvYmplY3Rpb25zLCBJJ2xsIGZpbGUgYW4gaXNzdWUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9dd5b8a53bda4799bff551241de67b9dustx2exdag1mb5msgcorpak_-- From nobody Fri Jun 28 14:45:31 2019 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 D07BE120945 for ; Fri, 28 Jun 2019 14:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V93_VFXWKMzH for ; Fri, 28 Jun 2019 14:45:23 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 3A10912095B for ; Fri, 28 Jun 2019 14:45:23 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id 207so10397729wma.1 for ; Fri, 28 Jun 2019 14:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SIFvGWg/0Y+dRT4tTqlsoU6TOELSQfMXazfFY080hWs=; b=Sx4+npfv3Mw+k2da+V5MERz7cBZJ5t/OptmIAmwvKEh0GNMGKU2El/s95y2d0nGPFr GgRFRH67gQFcc/IKYmLyrExOIXvF4RiR7KaJri253kOO7j0F/2DsTILoxRiFzGxQxWxL k6Tz10b3oz64uQx76Yr3fNsDBhEFGksA7wezqW1Bsvx9H5SOapRAetNjgM0jqen0ZbKl c+i5UKbYn5VWlwyPvVgftTFUypk8ZkU7r5lE2T3aqiFXOzu7OSImSUcoPLpZGupHtueo eokh7LTssvVoqAfP8lmN17VoSDnLtJ8HcE+Cacfmukd0y5eip6M2eIkhLoDZNwcFytyu 3Ziw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SIFvGWg/0Y+dRT4tTqlsoU6TOELSQfMXazfFY080hWs=; b=KSW3ri3UVzmVOvKKtMzYaWicwoauWTiD4pUpi2q6MABRx2v5W6uGCDK5riXgEohDh9 R22ogSuWoLDltvNEXJZgIu/oENndh+TFUP9SkO2MB8gpOTwZz0IUmBGXibRdCn8giC1K KFIgZBF1qKclDWacvNLAdpN75y/4eNMyC/Ga3BBuOJY1CxQG1pdc00Aa0u0MMFlf6A+a sDfkg2HSre4or5lTAVQf6gm85Bvaqm9xsEAIwxY7xnKhYhHCmGNpNqeKHG97gQg0R7j7 G+zkZR0deHEWJxxSnfpiCH9OaTG/prTwCNVg32Ntt4OGO/leKMGLMZ15nX3UG4A0ix9W 3zBA== X-Gm-Message-State: APjAAAVgsUe4+upyS4Y9HNmkyGdQdJlXiSXgNEgwzw0Zqc2vmLNNO/yk oEAeuv49r/CbuQCB6ufeqg8XSIzb00kfQI40MPE= X-Google-Smtp-Source: APXvYqwRL30ASED0lhoMPMAdPCgnEtpcfgP4mpdH8HRGf5uKiAmmaC27LLxsFgJuGykTJbg9uWPga9wzIOP0LIsqtqg= X-Received: by 2002:a05:600c:389:: with SMTP id w9mr8009535wmd.139.1561758321512; Fri, 28 Jun 2019 14:45:21 -0700 (PDT) MIME-Version: 1.0 References: <9dd5b8a53bda4799bff551241de67b9d@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <9dd5b8a53bda4799bff551241de67b9d@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Martin Duke Date: Fri, 28 Jun 2019 14:45:10 -0700 Message-ID: Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL? To: "Lubashev, Igor" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000fa99bb058c6931ea" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 21:45:29 -0000 --000000000000fa99bb058c6931ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think it's that hard. If most packets below a certain size are acked, and above are not, it's fairly straightforward. As it is, I MUST tear down the connection. so I'm sending CONNECTION_CLOSE with INTERNAL_ERROR, I guess. On Thu, Jun 27, 2019 at 1:32 PM Lubashev, Igor wrote: > I understand. I was suggesting that most endpoints will not =E2=80=9Cfig= ure this > out=E2=80=9D, as they would not be able to tell =E2=80=9CPMTU is too low= =E2=80=9D from =E2=80=9Ca blackhole > developed on the path to the peer=E2=80=9D. > > > > *From:* Martin Duke > *Sent:* Thursday, June 27, 2019 3:50 PM > *To:* Lubashev, Igor > *Cc:* IETF QUIC WG > *Subject:* Re: QUIC_ERROR_PMTU_TOO_SMALL? > > > > The scenario I have in mind is that the handshake completes because the > PMTU is between 1228 and 1280, but when the endpoint figures this out it > has to send a CONN_CLOSE (which would definitely make it through) > > > > On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor > wrote: > > I expect most implementations would not be able to (or care to) tell a > difference between PMTU shrinking below 1280 and the path to the peer > becoming a black hole entirely. I.e. most likely ICMP reporting PMTU bel= ow > the acceptable value would be dropped on a suspicion of forgery > (man-on-a-side attack), while PMTU probes smaller than 1280 would never b= e > sent (the connection cannot continue regardless of whether they succeed o= r > fail). > > > > Of course, an implementation could try to make a guess and send that > CONNECTION_CLOSE on a chance it will get through, and it would need an > error code. But sending such error code should be entirely optional (lik= e > in MAY). > > > > - Igor > > > > *From:* Martin Duke > *Sent:* Thursday, June 27, 2019 12:27 PM > *To:* IETF QUIC WG > *Subject:* QUIC_ERROR_PMTU_TOO_SMALL? > > > > Sec 14.1: > > If a QUIC endpoint determines that the PMTU between any pair of local > > and remote IP addresses has fallen below the size needed to support > > the smallest allowed maximum packet size, it MUST immediately cease > > sending QUIC packets, except for PMTU probe packets, on the affected > > path. An endpoint MAY terminate the connection if an alternative > > path cannot be found. > > > > > > If we tear down a connection because we don't have a path that supports > 1280 bytes, show should we communicate that to the peer? There should > probably be an error code for this. > > > > If there are no objections, I'll file an issue. > > --000000000000fa99bb058c6931ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think it's that hard. If most packets belo= w a certain size are acked, and above are not, it's fairly straightforw= ard. As it is, I MUST tear down the connection. so I'm sending CONNECTI= ON_CLOSE with INTERNAL_ERROR, I guess.

On Thu, Jun 27, 2019 at 1:32 PM L= ubashev, Igor <ilubashe@akamai.co= m> wrote:

I understand.=C2=A0 I was suggesting that most endpo= ints will not =E2=80=9Cfigure this out=E2=80=9D, as they would not be able = to tell =E2=80=9CPMTU is too low=E2=80=9D from =E2=80=9Ca blackhole develop= ed on the path to the peer=E2=80=9D.

=C2=A0

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Thursday, June 27, 2019 3:50 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL?

=C2=A0

The scenario I have in mind is that the handshake co= mpletes because the PMTU is between 1228 and 1280, but when the endpoint fi= gures this out it has to send a CONN_CLOSE (which would definitely make it = through)

=C2=A0

On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:

I expect most implementations would not be able to (= or care to) tell a difference between PMTU shrinking below 1280 and the pat= h to the peer becoming a black hole entirely.=C2=A0 I.e. most likely ICMP reporting PMTU below the acceptable value would be droppe= d on a suspicion of forgery (man-on-a-side attack), while PMTU probes small= er than 1280 would never be sent (the connection cannot continue regardless= of whether they succeed or fail).

=C2=A0

Of course, an implementation could try to make a gue= ss and send that CONNECTION_CLOSE on a chance it will get through, and it w= ould need an error code.=C2=A0 But sending such error code should be entirely optional (like in MAY).

=C2=A0

  • Igor

=C2=A0

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Thursday, June 27, 2019 12:27 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: QUIC_ERROR_PMTU_TOO_SMALL?

=C2=A0

Sec 14.1:

If a QUIC endpo=
int determines that the PMTU between any pair of local=

=C2=A0=C2=A0 and remote IP addresses has f=
allen below the size needed to support
=C2=A0=C2=A0 the smallest allowed maximum =
packet size, it MUST immediately cease
=C2=A0=C2=A0 sending QUIC packets, except =
for PMTU probe packets, on the affected
=C2=A0=C2=A0 path.=C2=A0 An endpoint MAY t=
erminate the connection if an alternative
=C2=A0=C2=A0 path cannot be found.<=
u>

=C2=A0

=C2=A0

If we tear down a connection because we don't ha= ve a path that supports 1280 bytes, show should we communicate that to the = peer? There should probably be an error code for this.

=C2=A0

If there are no objections, I'll file an issue.<= u>

--000000000000fa99bb058c6931ea-- From nobody Fri Jun 28 15:05:46 2019 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 5362F1201DC for ; Fri, 28 Jun 2019 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5MU24yu662F for ; Fri, 28 Jun 2019 15:05:42 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1EA120105 for ; Fri, 28 Jun 2019 15:05:41 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5SM33JH023622; Fri, 28 Jun 2019 23:05:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=qfwPyOqUjPI9uS5RhuoA1lFQlXt/iLDAIsnmXLkWtTE=; b=Cwe/YocxS/PgN2sCdyIBJMxBhE1i8hZGk6+dDmz+wLvEiYrX29ETY+tIJtntGpixUlnr Wu06uSrr2lTTZoFoQm5A3VNgx2E9ycBbV68oKSVNlafmjZu2oAt6LyRudhDRq/fBtjNt PrpFVESNU7jmVhU0tgb+uxQDwWFSs2Xdgk1nm34q6DMiLOAvYvY0L8HwmIe1478nA3j3 75sfSBrVdTYOk/ewfJw4uu1waD/L+eE9eVbozv/kW08XOyvzt3QhvruA7v0xBfDiPJZB Ksvi4+5R9SxUWcPYFXLVea2S8/uCKbWO6F/bFTtoifPDgG4QXwx7ybvgCgxJsD8F7DAB hQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2tcfsm8ubb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 23:05:40 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x5SM3XFQ013360; Fri, 28 Jun 2019 18:05:39 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.21]) by prod-mail-ppoint2.akamai.com with ESMTP id 2tcdrjnxd5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 18:05:37 -0400 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 17:05:29 -0500 Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1473.004; Fri, 28 Jun 2019 17:05:29 -0500 From: "Lubashev, Igor" To: Martin Duke CC: IETF QUIC WG Subject: RE: QUIC_ERROR_PMTU_TOO_SMALL? Thread-Topic: QUIC_ERROR_PMTU_TOO_SMALL? Thread-Index: AQHVLQW9iALWP/Yl20KtgH0KqESFwKavsfxAgACKsID//7dkUIAB+zoA//+uLgA= Date: Fri, 28 Jun 2019 22:05:29 +0000 Message-ID: <8055618054e74d5bbcc10e35f23703a9@ustx2ex-dag1mb5.msg.corp.akamai.com> References: <9dd5b8a53bda4799bff551241de67b9d@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.96] Content-Type: multipart/alternative; boundary="_000_8055618054e74d5bbcc10e35f23703a9ustx2exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-28_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=616 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906280252 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-28_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=662 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906280252 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 22:05:45 -0000 --_000_8055618054e74d5bbcc10e35f23703a9ustx2exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIHlvdSBhcmUgbm90IGFsbG93ZWQgdG8gc2VuZCB5b3VyIENPTk5FQ1RJT05fQ0xP U0Ugd2l0aCBhbnkgZXJyb3IgY29kZSBwZXIgdmVyeSBydWxlIHlvdSBxdW90ZWQuICBJLmUuIGNh bm5vdCBzZW5kIGFueSBRVUlDIHBhY2tldHMsIGV4Y2VwdCBmb3IgUE1UVSBwcm9iZXMsIG9uIHRo ZSBhZmZlY3RlZCBwYXRoLg0KDQoNCkJ1dCB3aGF0IEkgd2FzIHRyeWluZyB0byBwb2ludCBvdXQg aXMgdGhhdCDigJxtb3N0IHBhY2tldHMgYmVsb3cgYSBjZXJ0YWluIHNpemUgYXJlIGFja2VkLCBh bmQgYWJvdmUgYXJlIG5vdOKAnSBpcyBub3QgYSBzaXR1YXRpb24geW91IHdpbGwgbGlrZWx5IGVu Y291bnRlciwgaWYgUE1UVSBzdWRkZW5seSBkcm9wcyBiZWZvcmUgMTI4MC4gIE9uY2UgeW91ciBQ TVRVIGVzdGltYXRlIGRyb3BzIGJlbG93IDEyODAsIHRoZXJlIHdpbGwgYmUgbm8gbW9yZSBBQ0tz IGZvciBzbWFsbCBwYWNrZXRzLCBiZWNhdXNlIG5vIHNtYWxsIHBhY2tldHMgd2lsbCBiZSBzZW50 IChwZXIgdGhlIHJ1bGUgeW91IHF1b3RlZCkuICBUaGUgb25seSBwYWNrZXRzIHRoYXQgY2FuIGJl IHNlbnQgYXJlIFBNVFUgcHJvYmVzLCBhbmQgdGhvc2Ugd2lsbCBuZWVkIHRvIGJlIGF0IGxlYXN0 IDEyODAgaW4gbGVuZ3RoIHRvIGJlIHVzZWZ1bCAoaS5lLiBpZiBhbnkgb2YgdGhlbSBnZXRzIEFD S2VkLCB0aGUgY29ubmVjdGlvbiBjYW4gcmVzdW1lKS4NCg0KDQpGcm9tOiBNYXJ0aW4gRHVrZSA8 bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpTZW50OiBGcmlkYXksIEp1bmUgMjgsIDIwMTkgNTo0 NSBQTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KQ2M6IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBRVUlDX0VSUk9SX1BNVFVfVE9P X1NNQUxMPw0KDQpJIGRvbid0IHRoaW5rIGl0J3MgdGhhdCBoYXJkLiBJZiBtb3N0IHBhY2tldHMg YmVsb3cgYSBjZXJ0YWluIHNpemUgYXJlIGFja2VkLCBhbmQgYWJvdmUgYXJlIG5vdCwgaXQncyBm YWlybHkgc3RyYWlnaHRmb3J3YXJkLiBBcyBpdCBpcywgSSBNVVNUIHRlYXIgZG93biB0aGUgY29u bmVjdGlvbi4gc28gSSdtIHNlbmRpbmcgQ09OTkVDVElPTl9DTE9TRSB3aXRoIElOVEVSTkFMX0VS Uk9SLCBJIGd1ZXNzLg0KDQpPbiBUaHUsIEp1biAyNywgMjAxOSBhdCAxOjMyIFBNIEx1YmFzaGV2 LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4g d3JvdGU6DQpJIHVuZGVyc3RhbmQuICBJIHdhcyBzdWdnZXN0aW5nIHRoYXQgbW9zdCBlbmRwb2lu dHMgd2lsbCBub3Qg4oCcZmlndXJlIHRoaXMgb3V04oCdLCBhcyB0aGV5IHdvdWxkIG5vdCBiZSBh YmxlIHRvIHRlbGwg4oCcUE1UVSBpcyB0b28gbG934oCdIGZyb20g4oCcYSBibGFja2hvbGUgZGV2 ZWxvcGVkIG9uIHRoZSBwYXRoIHRvIHRoZSBwZWVy4oCdLg0KDQpGcm9tOiBNYXJ0aW4gRHVrZSA8 bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPj4N ClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5IDM6NTAgUE0NClRvOiBMdWJhc2hldiwgSWdv ciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+DQpDYzog SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBRVUlDX0VSUk9SX1BNVFVfVE9PX1NNQUxMPw0KDQpUaGUgc2NlbmFyaW8gSSBoYXZl IGluIG1pbmQgaXMgdGhhdCB0aGUgaGFuZHNoYWtlIGNvbXBsZXRlcyBiZWNhdXNlIHRoZSBQTVRV IGlzIGJldHdlZW4gMTIyOCBhbmQgMTI4MCwgYnV0IHdoZW4gdGhlIGVuZHBvaW50IGZpZ3VyZXMg dGhpcyBvdXQgaXQgaGFzIHRvIHNlbmQgYSBDT05OX0NMT1NFICh3aGljaCB3b3VsZCBkZWZpbml0 ZWx5IG1ha2UgaXQgdGhyb3VnaCkNCg0KT24gVGh1LCBKdW4gMjcsIDIwMTkgYXQgOTo1MSBBTSBM dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFp LmNvbT4+IHdyb3RlOg0KSSBleHBlY3QgbW9zdCBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IGJl IGFibGUgdG8gKG9yIGNhcmUgdG8pIHRlbGwgYSBkaWZmZXJlbmNlIGJldHdlZW4gUE1UVSBzaHJp bmtpbmcgYmVsb3cgMTI4MCBhbmQgdGhlIHBhdGggdG8gdGhlIHBlZXIgYmVjb21pbmcgYSBibGFj ayBob2xlIGVudGlyZWx5LiAgSS5lLiBtb3N0IGxpa2VseSBJQ01QIHJlcG9ydGluZyBQTVRVIGJl bG93IHRoZSBhY2NlcHRhYmxlIHZhbHVlIHdvdWxkIGJlIGRyb3BwZWQgb24gYSBzdXNwaWNpb24g b2YgZm9yZ2VyeSAobWFuLW9uLWEtc2lkZSBhdHRhY2spLCB3aGlsZSBQTVRVIHByb2JlcyBzbWFs bGVyIHRoYW4gMTI4MCB3b3VsZCBuZXZlciBiZSBzZW50ICh0aGUgY29ubmVjdGlvbiBjYW5ub3Qg Y29udGludWUgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZXkgc3VjY2VlZCBvciBmYWlsKS4NCg0K T2YgY291cnNlLCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCB0cnkgdG8gbWFrZSBhIGd1ZXNzIGFu ZCBzZW5kIHRoYXQgQ09OTkVDVElPTl9DTE9TRSBvbiBhIGNoYW5jZSBpdCB3aWxsIGdldCB0aHJv dWdoLCBhbmQgaXQgd291bGQgbmVlZCBhbiBlcnJvciBjb2RlLiAgQnV0IHNlbmRpbmcgc3VjaCBl cnJvciBjb2RlIHNob3VsZCBiZSBlbnRpcmVseSBvcHRpb25hbCAobGlrZSBpbiBNQVkpLg0KDQoN CiAgKiAgIElnb3INCg0KRnJvbTogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29t PG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4+DQpTZW50OiBUaHVyc2RheSwgSnVuZSAy NywgMjAxOSAxMjoyNyBQTQ0KVG86IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBRVUlDX0VSUk9SX1BNVFVfVE9PX1NNQUxMPw0KDQpT ZWMgMTQuMToNCg0KSWYgYSBRVUlDIGVuZHBvaW50IGRldGVybWluZXMgdGhhdCB0aGUgUE1UVSBi ZXR3ZWVuIGFueSBwYWlyIG9mIGxvY2FsDQoNCiAgIGFuZCByZW1vdGUgSVAgYWRkcmVzc2VzIGhh cyBmYWxsZW4gYmVsb3cgdGhlIHNpemUgbmVlZGVkIHRvIHN1cHBvcnQNCg0KICAgdGhlIHNtYWxs ZXN0IGFsbG93ZWQgbWF4aW11bSBwYWNrZXQgc2l6ZSwgaXQgTVVTVCBpbW1lZGlhdGVseSBjZWFz ZQ0KDQogICBzZW5kaW5nIFFVSUMgcGFja2V0cywgZXhjZXB0IGZvciBQTVRVIHByb2JlIHBhY2tl dHMsIG9uIHRoZSBhZmZlY3RlZA0KDQogICBwYXRoLiAgQW4gZW5kcG9pbnQgTUFZIHRlcm1pbmF0 ZSB0aGUgY29ubmVjdGlvbiBpZiBhbiBhbHRlcm5hdGl2ZQ0KDQogICBwYXRoIGNhbm5vdCBiZSBm b3VuZC4NCg0KDQpJZiB3ZSB0ZWFyIGRvd24gYSBjb25uZWN0aW9uIGJlY2F1c2Ugd2UgZG9uJ3Qg aGF2ZSBhIHBhdGggdGhhdCBzdXBwb3J0cyAxMjgwIGJ5dGVzLCBzaG93IHNob3VsZCB3ZSBjb21t dW5pY2F0ZSB0aGF0IHRvIHRoZSBwZWVyPyBUaGVyZSBzaG91bGQgcHJvYmFibHkgYmUgYW4gZXJy b3IgY29kZSBmb3IgdGhpcy4NCg0KSWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMsIEknbGwgZmls ZSBhbiBpc3N1ZS4NCg== --_000_8055618054e74d5bbcc10e35f23703a9ustx2exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS01MzE0MjA1 MTcyOTcyMTA2MzkwZ21haWwtbTE0MzcxNzA2MTYwODc0Njk5MDltc29saXN0cGFyYWdyYXBoLCBs aS5nbWFpbC1tLTUzMTQyMDUxNzI5NzIxMDYzOTBnbWFpbC1tMTQzNzE3MDYxNjA4NzQ2OTkwOW1z b2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tLTUzMTQyMDUxNzI5NzIxMDYzOTBnbWFpbC1tMTQz NzE3MDYxNjA4NzQ2OTkwOW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwt bV8tNTMxNDIwNTE3Mjk3MjEwNjM5MGdtYWlsLW0xNDM3MTcwNjE2MDg3NDY5OTA5bXNvbGlzdHBh cmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEy ODM4NzcxOTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjM3MTY2NDM2O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjdHVhbGx5 LCB5b3UgYXJlIG5vdCBhbGxvd2VkIHRvIHNlbmQgeW91ciBDT05ORUNUSU9OX0NMT1NFIHdpdGgg YW55IGVycm9yIGNvZGUgcGVyIHZlcnkgcnVsZSB5b3UgcXVvdGVkLiZuYnNwOyBJLmUuIGNhbm5v dCBzZW5kIGFueSBRVUlDIHBhY2tldHMsIGV4Y2VwdCBmb3IgUE1UVSBwcm9iZXMsIG9uIHRoZSBh ZmZlY3RlZCBwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB3aGF0IEkgd2FzIHRyeWluZyB0byBwb2ludCBv dXQgaXMgdGhhdCDigJxtb3N0IHBhY2tldHMgYmVsb3cgYSBjZXJ0YWluIHNpemUgYXJlIGFja2Vk LCBhbmQgYWJvdmUgYXJlIG5vdOKAnSBpcyBub3QgYSBzaXR1YXRpb24geW91IHdpbGwgbGlrZWx5 IGVuY291bnRlciwgaWYgUE1UVSBzdWRkZW5seSBkcm9wcyBiZWZvcmUgMTI4MC4mbmJzcDsgT25j ZSB5b3VyIFBNVFUgZXN0aW1hdGUgZHJvcHMgYmVsb3cgMTI4MCwgdGhlcmUNCiB3aWxsIGJlIG5v IG1vcmUgQUNLcyBmb3Igc21hbGwgcGFja2V0cywgYmVjYXVzZSBubyBzbWFsbCBwYWNrZXRzIHdp bGwgYmUgc2VudCAocGVyIHRoZSBydWxlIHlvdSBxdW90ZWQpLiZuYnNwOyBUaGUgb25seSBwYWNr ZXRzIHRoYXQgY2FuIGJlIHNlbnQgYXJlIFBNVFUgcHJvYmVzLCBhbmQgdGhvc2Ugd2lsbCBuZWVk IHRvIGJlIGF0IGxlYXN0IDEyODAgaW4gbGVuZ3RoIHRvIGJlIHVzZWZ1bCAoaS5lLiBpZiBhbnkg b2YgdGhlbSBnZXRzIEFDS2VkLCB0aGUNCiBjb25uZWN0aW9uIGNhbiByZXN1bWUpLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdtYWlsLmNv bSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyOCwgMjAxOSA1OjQ1IFBNPGJy Pg0KPGI+VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFFVSUNfRVJST1JfUE1UVV9UT09fU01BTEw/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayBpdCdzIHRo YXQgaGFyZC4gSWYgbW9zdCBwYWNrZXRzIGJlbG93IGEgY2VydGFpbiBzaXplIGFyZSBhY2tlZCwg YW5kIGFib3ZlIGFyZSBub3QsIGl0J3MgZmFpcmx5IHN0cmFpZ2h0Zm9yd2FyZC4gQXMgaXQgaXMs IEkgTVVTVCB0ZWFyIGRvd24gdGhlIGNvbm5lY3Rpb24uIHNvIEknbSBzZW5kaW5nIENPTk5FQ1RJ T05fQ0xPU0Ugd2l0aCBJTlRFUk5BTF9FUlJPUiwgSSBndWVzcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVuIDI3LCAyMDE5IGF0IDE6MzIg UE0gTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Ij5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB1 bmRlcnN0YW5kLiZuYnNwOyBJIHdhcyBzdWdnZXN0aW5nIHRoYXQgbW9zdCBlbmRwb2ludHMgd2ls bCBub3Qg4oCcZmlndXJlIHRoaXMgb3V04oCdLCBhcyB0aGV5IHdvdWxkIG5vdCBiZSBhYmxlIHRv IHRlbGwg4oCcUE1UVSBpcyB0b28gbG934oCdIGZyb20g4oCcYSBibGFja2hvbGUgZGV2ZWxvcGVk IG9uIHRoZSBwYXRoIHRvIHRoZQ0KIHBlZXLigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciBibHVlIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6 Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy b206PC9iPiBNYXJ0aW4gRHVrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+Jmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5IDM6NTAgUE08YnI+DQo8 Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWth bWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozxicj4N CjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogUVVJQ19FUlJPUl9QTVRVX1RPT19TTUFMTD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHNjZW5hcmlvIEkgaGF2ZSBpbiBtaW5k IGlzIHRoYXQgdGhlIGhhbmRzaGFrZSBjb21wbGV0ZXMgYmVjYXVzZSB0aGUgUE1UVSBpcyBiZXR3 ZWVuIDEyMjggYW5kIDEyODAsIGJ1dCB3aGVuIHRoZSBlbmRwb2ludCBmaWd1cmVzIHRoaXMgb3V0 IGl0IGhhcyB0byBzZW5kIGEgQ09OTl9DTE9TRSAod2hpY2gNCiB3b3VsZCBkZWZpbml0ZWx5IG1h a2UgaXQgdGhyb3VnaCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBUaHUsIEp1biAyNywgMjAxOSBhdCA5OjUxIEFNIEx1YmFzaGV2LCBJZ29yICZs dDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmls dWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQs MjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBleHBlY3QgbW9z dCBpbXBsZW1lbnRhdGlvbnMgd291bGQgbm90IGJlIGFibGUgdG8gKG9yIGNhcmUgdG8pIHRlbGwg YSBkaWZmZXJlbmNlIGJldHdlZW4gUE1UVSBzaHJpbmtpbmcgYmVsb3cgMTI4MCBhbmQgdGhlIHBh dGggdG8gdGhlIHBlZXIgYmVjb21pbmcgYSBibGFjayBob2xlIGVudGlyZWx5LiZuYnNwOyBJLmUu DQogbW9zdCBsaWtlbHkgSUNNUCByZXBvcnRpbmcgUE1UVSBiZWxvdyB0aGUgYWNjZXB0YWJsZSB2 YWx1ZSB3b3VsZCBiZSBkcm9wcGVkIG9uIGEgc3VzcGljaW9uIG9mIGZvcmdlcnkgKG1hbi1vbi1h LXNpZGUgYXR0YWNrKSwgd2hpbGUgUE1UVSBwcm9iZXMgc21hbGxlciB0aGFuIDEyODAgd291bGQg bmV2ZXIgYmUgc2VudCAodGhlIGNvbm5lY3Rpb24gY2Fubm90IGNvbnRpbnVlIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlciB0aGV5IHN1Y2NlZWQgb3IgZmFpbCkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PZiBjb3Vyc2UsIGFuIGltcGxlbWVudGF0aW9uIGNvdWxkIHRyeSB0byBtYWtlIGEgZ3Vl c3MgYW5kIHNlbmQgdGhhdCBDT05ORUNUSU9OX0NMT1NFIG9uIGEgY2hhbmNlIGl0IHdpbGwgZ2V0 IHRocm91Z2gsIGFuZCBpdCB3b3VsZCBuZWVkIGFuIGVycm9yIGNvZGUuJm5ic3A7IEJ1dCBzZW5k aW5nIHN1Y2ggZXJyb3IgY29kZQ0KIHNob3VsZCBiZSBlbnRpcmVseSBvcHRpb25hbCAobGlrZSBp biBNQVkpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS01MzE0MjA1 MTcyOTcyMTA2MzkwZ21haWwtbTE0MzcxNzA2MTYwODc0Njk5MDltc29saXN0cGFyYWdyYXBoIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWdvcjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47 Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy b206PC9iPiBNYXJ0aW4gRHVrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+Jmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDI3LCAyMDE5IDEyOjI3IFBNPGJyPg0K PGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFFVSUNfRVJST1JfUE1UVV9UT09fU01BTEw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWMgMTQuMTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlO2ZvbnQtdmFyaWFu dC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0 YXJ0O3RleHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjpp bml0aWFsO3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgYSBR VUlDIGVuZHBvaW50IGRldGVybWluZXMgdGhhdCB0aGUgUE1UVSBiZXR3ZWVuIGFueSBwYWlyIG9m IGxvY2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IGFuZCByZW1vdGUgSVAgYWRkcmVzc2VzIGhhcyBmYWxsZW4gYmVs b3cgdGhlIHNpemUgbmVlZGVkIHRvIHN1cHBvcnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIHNtYWxsZXN0IGFs bG93ZWQgbWF4aW11bSBwYWNrZXQgc2l6ZSwgaXQgTVVTVCBpbW1lZGlhdGVseSBjZWFzZTwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBzZW5kaW5nIFFVSUMgcGFja2V0cywgZXhjZXB0IGZvciBQTVRVIHByb2JlIHBhY2tl dHMsIG9uIHRoZSBhZmZlY3RlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXRoLiZuYnNwOyBBbiBlbmRwb2ludCBN QVkgdGVybWluYXRlIHRoZSBjb25uZWN0aW9uIGlmIGFuIGFsdGVybmF0aXZlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IHBhdGggY2Fubm90IGJlIGZvdW5kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIHRlYXIgZG93biBhIGNvbm5lY3Rpb24gYmVjYXVz ZSB3ZSBkb24ndCBoYXZlIGEgcGF0aCB0aGF0IHN1cHBvcnRzIDEyODAgYnl0ZXMsIHNob3cgc2hv dWxkIHdlIGNvbW11bmljYXRlIHRoYXQgdG8gdGhlIHBlZXI/IFRoZXJlIHNob3VsZCBwcm9iYWJs eSBiZSBhbiBlcnJvciBjb2RlIGZvciB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMs IEknbGwgZmlsZSBhbiBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_8055618054e74d5bbcc10e35f23703a9ustx2exdag1mb5msgcorpak_-- From nobody Fri Jun 28 15:38:31 2019 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 EDE04120105 for ; Fri, 28 Jun 2019 15:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUE9vcbyKnnZ for ; Fri, 28 Jun 2019 15:38:27 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 0FADA120018 for ; Fri, 28 Jun 2019 15:38:27 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id n4so7776566wrs.3 for ; Fri, 28 Jun 2019 15:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=70QTzNUnV3h/mPwmjRBu8H7JdX5NE4FHPIJgXBrgZZc=; b=WAYfzmHUdUzjGJ65aWOI4PoOhIQb3wihmzue52IQapa7NZ2kh3SbzFAHLBMH3EIthl V3x/EUvCzwMhOWvFa7AD3gPcF4F6L+o4aPyoZ6NanVhsBu24SNbyNCzwbZy0WRGDGw8W pU7rGegQ6Wf3m5hQk8VYtfAEbA/t7FILY/+rYg6cRi/lWjvgLW463E0eHqfvfG1VVKc/ XH1OmwBBaK/jthDnUlDBlEx08pAUTY73jeOXqgVwb8tQXbGNn3fAH9lwES7f1XwCeMQh JV9+g9WayxcJkO1NnlYEZk+E+AvmIqMGrTorcP55x8QPvvqC/tpQmOoOXVibW+cwD2hE Jv4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=70QTzNUnV3h/mPwmjRBu8H7JdX5NE4FHPIJgXBrgZZc=; b=YxYytDcef4M0ukZ0MUl6rwzv1cvGRUI3eytmE4BggeGcmC7xdn/ZBhIm5j245629yV p0xm1/3lXIxbBNl4Qye0y3V+DGVzv/BFb4e8OBYUtadA4cX6HpvBAhsylW2INglo4A5T j2V+aElszw6r/jYdkg8G7/lYr/Aw14H9CKNNuhRUhlyye/9zCxFLK+C4xP1h93E7Rclz N5Q1vfA967cY0z07rRtDeci/zazJIrGuurJLet90RQn+jl/UK7Tc7MftV54ilrdkyjOJ BbzeXmZbb5TYIavgVGVIUkEaK7ZSHZ4Nm9wp+tRUB4fL4dAYT4H3RrXcnaoDcrlziQG7 LrzQ== X-Gm-Message-State: APjAAAVQHy0k5O8rArRmPPrukYxAWlgtoIqkjyZD7iYK8eHXXh94HjCf 8JnLdvVGj26V6mk5wt+OXmuPhiLLohE/6N2oTEI= X-Google-Smtp-Source: APXvYqwNhtGXhRCdIHCmz58jDaZwp43UCvsN0Dix9MaUD74GEPUN5z+86u1PwbzzW/5G8Om5tQHx7wbSPoYbkybT+Yw= X-Received: by 2002:adf:f181:: with SMTP id h1mr999114wro.18.1561761505469; Fri, 28 Jun 2019 15:38:25 -0700 (PDT) MIME-Version: 1.0 References: <9dd5b8a53bda4799bff551241de67b9d@ustx2ex-dag1mb5.msg.corp.akamai.com> <8055618054e74d5bbcc10e35f23703a9@ustx2ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <8055618054e74d5bbcc10e35f23703a9@ustx2ex-dag1mb5.msg.corp.akamai.com> From: Martin Duke Date: Fri, 28 Jun 2019 15:38:14 -0700 Message-ID: Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL? To: "Lubashev, Igor" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c1e8b4058c69efa8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 22:38:30 -0000 --000000000000c1e8b4058c69efa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oof. You're right. That's a bad rule, but I guess that's what it says right now. On Fri, Jun 28, 2019 at 3:05 PM Lubashev, Igor wrote: > Actually, you are not allowed to send your CONNECTION_CLOSE with any erro= r > code per very rule you quoted. I.e. cannot send any QUIC packets, except > for PMTU probes, on the affected path. > > > > > > But what I was trying to point out is that =E2=80=9Cmost packets below a = certain > size are acked, and above are not=E2=80=9D is not a situation you will li= kely > encounter, if PMTU suddenly drops before 1280. Once your PMTU estimate > drops below 1280, there will be no more ACKs for small packets, because n= o > small packets will be sent (per the rule you quoted). The only packets > that can be sent are PMTU probes, and those will need to be at least 1280 > in length to be useful (i.e. if any of them gets ACKed, the connection ca= n > resume). > > > > > > *From:* Martin Duke > *Sent:* Friday, June 28, 2019 5:45 PM > *To:* Lubashev, Igor > *Cc:* IETF QUIC WG > *Subject:* Re: QUIC_ERROR_PMTU_TOO_SMALL? > > > > I don't think it's that hard. If most packets below a certain size are > acked, and above are not, it's fairly straightforward. As it is, I MUST > tear down the connection. so I'm sending CONNECTION_CLOSE with > INTERNAL_ERROR, I guess. > > > > On Thu, Jun 27, 2019 at 1:32 PM Lubashev, Igor > wrote: > > I understand. I was suggesting that most endpoints will not =E2=80=9Cfig= ure this > out=E2=80=9D, as they would not be able to tell =E2=80=9CPMTU is too low= =E2=80=9D from =E2=80=9Ca blackhole > developed on the path to the peer=E2=80=9D. > > > > *From:* Martin Duke > *Sent:* Thursday, June 27, 2019 3:50 PM > *To:* Lubashev, Igor > *Cc:* IETF QUIC WG > *Subject:* Re: QUIC_ERROR_PMTU_TOO_SMALL? > > > > The scenario I have in mind is that the handshake completes because the > PMTU is between 1228 and 1280, but when the endpoint figures this out it > has to send a CONN_CLOSE (which would definitely make it through) > > > > On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor > wrote: > > I expect most implementations would not be able to (or care to) tell a > difference between PMTU shrinking below 1280 and the path to the peer > becoming a black hole entirely. I.e. most likely ICMP reporting PMTU bel= ow > the acceptable value would be dropped on a suspicion of forgery > (man-on-a-side attack), while PMTU probes smaller than 1280 would never b= e > sent (the connection cannot continue regardless of whether they succeed o= r > fail). > > > > Of course, an implementation could try to make a guess and send that > CONNECTION_CLOSE on a chance it will get through, and it would need an > error code. But sending such error code should be entirely optional (lik= e > in MAY). > > > > - Igor > > > > *From:* Martin Duke > *Sent:* Thursday, June 27, 2019 12:27 PM > *To:* IETF QUIC WG > *Subject:* QUIC_ERROR_PMTU_TOO_SMALL? > > > > Sec 14.1: > > If a QUIC endpoint determines that the PMTU between any pair of local > > and remote IP addresses has fallen below the size needed to support > > the smallest allowed maximum packet size, it MUST immediately cease > > sending QUIC packets, except for PMTU probe packets, on the affected > > path. An endpoint MAY terminate the connection if an alternative > > path cannot be found. > > > > > > If we tear down a connection because we don't have a path that supports > 1280 bytes, show should we communicate that to the peer? There should > probably be an error code for this. > > > > If there are no objections, I'll file an issue. > > --000000000000c1e8b4058c69efa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oof. You're right. That's a bad rule, but I guess = that's what it says right now.

=
On Fri, Jun 28, 2019 at 3:05 PM Lubas= hev, Igor <ilubashe@akamai.com> wrote:

Actually, you are not allowed to send your CONNECTIO= N_CLOSE with any error code per very rule you quoted.=C2=A0 I.e. cannot sen= d any QUIC packets, except for PMTU probes, on the affected path.=

=C2=A0

=C2=A0

But what I was trying to point out is that =E2=80=9C= most packets below a certain size are acked, and above are not=E2=80=9D is = not a situation you will likely encounter, if PMTU suddenly drops before 12= 80.=C2=A0 Once your PMTU estimate drops below 1280, there will be no more ACKs for small packets, because no small packets will be s= ent (per the rule you quoted).=C2=A0 The only packets that can be sent are = PMTU probes, and those will need to be at least 1280 in length to be useful= (i.e. if any of them gets ACKed, the connection can resume).

=C2=A0

=C2=A0

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Friday, June 28, 2019 5:45 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL?

=C2=A0

I don't think it's that hard. If most packet= s below a certain size are acked, and above are not, it's fairly straig= htforward. As it is, I MUST tear down the connection. so I'm sending CO= NNECTION_CLOSE with INTERNAL_ERROR, I guess.

=C2=A0

On Thu, Jun 27, 2019 at 1:32 PM Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:

I understand.=C2=A0 I was suggesting that most endpo= ints will not =E2=80=9Cfigure this out=E2=80=9D, as they would not be able = to tell =E2=80=9CPMTU is too low=E2=80=9D from =E2=80=9Ca blackhole develop= ed on the path to the peer=E2=80=9D.

=C2=A0

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Thursday, June 27, 2019 3:50 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC_ERROR_PMTU_TOO_SMALL?

=C2=A0

The scenario I have in mind is that the handshake co= mpletes because the PMTU is between 1228 and 1280, but when the endpoint fi= gures this out it has to send a CONN_CLOSE (which would definitely make it through)

=C2=A0

On Thu, Jun 27, 2019 at 9:51 AM Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:

I expect most implementations would not be able to (= or care to) tell a difference between PMTU shrinking below 1280 and the pat= h to the peer becoming a black hole entirely.=C2=A0 I.e. most likely ICMP reporting PMTU below the acceptable value would be droppe= d on a suspicion of forgery (man-on-a-side attack), while PMTU probes small= er than 1280 would never be sent (the connection cannot continue regardless= of whether they succeed or fail).

=C2=A0

Of course, an implementation could try to make a gue= ss and send that CONNECTION_CLOSE on a chance it will get through, and it w= ould need an error code.=C2=A0 But sending such error code should be entirely optional (like in MAY).

=C2=A0

  • Igor

=C2=A0

From: Martin Duke <martin.h.duke@gmail.com>
Sent: Thursday, June 27, 2019 12:27 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: QUIC_ERROR_PMTU_TOO_SMALL?

=C2=A0

Sec 14.1:

If a QUIC endpo=
int determines that the PMTU between any pair of local=

=C2=A0=C2=A0 and remote IP addresses has f=
allen below the size needed to support
=C2=A0=C2=A0 the smallest allowed maximum =
packet size, it MUST immediately cease
=C2=A0=C2=A0 sending QUIC packets, except =
for PMTU probe packets, on the affected
=C2=A0=C2=A0 path.=C2=A0 An endpoint MAY t=
erminate the connection if an alternative
=C2=A0=C2=A0 path cannot be found.<=
u>

=C2=A0

=C2=A0

If we tear down a connection because we don't ha= ve a path that supports 1280 bytes, show should we communicate that to the = peer? There should probably be an error code for this.

=C2=A0

If there are no objections, I'll file an issue.<= u>

--000000000000c1e8b4058c69efa8-- From nobody Fri Jun 28 15:59:51 2019 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 E4E1412096F; Fri, 28 Jun 2019 15:57:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: magnus.westerlund@ericsson.com, quic@ietf.org Subject: quic - Requested sessions have been scheduled for IETF 105 X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267293.11015.1961572744272253154.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:52 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 22:57:59 -0000 Dear Lars Eggert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:00 requested) Tuesday, 23 July 2019, Morning Session I 1000-1200 Room Name: Place du Canada size: 300 --------------------------------------------- quic Session 2 (2:00 requested) Wednesday, 24 July 2019, Morning Session I 1000-1200 Room Name: Place du Canada size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/quic.ics Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls Second Priority: saag rtcweb People who must be present: Sean Turner Mark Nottingham Magnus Westerlund Jana Iyengar Martin Thomson Brian Trammell Mirja Kuehlewind Lars Eggert Mike Bishop Ian Swett Alan Frindell Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days early in the week, if possible. Please avoid colliding with all BOFs and the ANRW. --------------------------------------------------------- From nobody Sat Jun 29 17:45:29 2019 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 78B8A12001E for ; Sat, 29 Jun 2019 17:45:28 -0700 (PDT) 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 (2048-bit key) header.d=mnot.net header.b=WSLcM7DY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A0wuzuce 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 tMUFg479rmsw for ; Sat, 29 Jun 2019 17:45:24 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8A77120074 for ; Sat, 29 Jun 2019 17:45:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id E17EA3EC for ; Sat, 29 Jun 2019 20:45:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 29 Jun 2019 20:45:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=2DaU175KyMfvokkVgyilKwV/YxXPX9XzJWtKw1xRjWA=; b=WSLcM7DY RS75w9tJfCdr2rdCUSETaLDv1ZPRP6Uar5A27ZxyOg+12ByMvzJ3Wx5MzKJBdAqm LMRtI9JQ9wpPGmbNayYGkZuJ2WSBiuGdhWOHMGOWrqYQvBAJ98HZuWiZGT0XpTCV j86maKiRYH4qOvnFtivNYKdQSpc4Acpl1oqXyLLuQMjncm5h2kCdij+Ib3FeVfIF Hz+1WBWcIAwzHzS0+W2Uj5m/9Ue1xAAJM8n4M9QiGAoZhYEsI55dsu6lSnKWc16r M1j4+S7r9qzIHyhKLfYCEQUeQGho8812KUTe6s9O4aMp8yxU86LjNYivbrWyTS+Y zzULKO52akioxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=2DaU175KyMfvokkVgyilKwV/YxXPX 9XzJWtKw1xRjWA=; b=A0wuzucesB5WLKa1n+zsDhJjeOsymG1Ym5P4Y3JjEG/4r 7l2bq23zN7e6V0aIDrDZ84exvWCUkfm+JJGwpVRh1zUl49pqOIPpKyRlGdRD+azQ AvPUefkiSVcKWT/+G2WkkFqmH+tJA2jsiy/ZqMPP2XeftACd+FBlpIG1iQOqsrTA zU7j/2x87xWyMG2HTHXhkGfRJBd/ljl0+h99CrBlxYCl47xqkqWSW1n3zPR1/loc yEXI9RFeCpBqUlcqii68AUsXJFjef6IpEyAE5UrWFWCenyRvW6LJ+XShxohwLp0W 2it8DFu4AKK74m3/U9XKXOSV87cjGF5hTQKaMbbbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdefgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id A2E9780059 for ; Sat, 29 Jun 2019 20:45:20 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 5A222C043B for ; Sun, 30 Jun 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0015826160520830628==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190630004516.5A222C043B@cloud.mnot.net> Date: Sun, 30 Jun 2019 00:45:16 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 00:45:29 -0000 --===============0015826160520830628== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+4/-5/=F0=9F=92=AC31) 4 issues created: - Signal error upon receipt of multiple trailing HEADERS (by bencebeky) https://github.com/quicwg/base-drafts/issues/2858 = - Early Data isn't explained (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2856 [-transport] [editori= al] = - transport: broken refs to -recovery (by reschke) https://github.com/quicwg/base-drafts/issues/2855 = - Resetting stream without knowledge (by LPardue) https://github.com/quicwg/base-drafts/issues/2850 = 13 issues received 31 new comments: - #2844 Client connection IDs are broken (6 by DavidSchinazi, martinthoms= on, huitema) https://github.com/quicwg/base-drafts/issues/2844 [-transport] = - #2850 Resetting stream without knowledge (5 by martinthomson, LPardue, = MikeBishop) https://github.com/quicwg/base-drafts/issues/2850 [-transport] [editori= al] = - #2825 Exceeding Max STREAM ID should be a connection error (4 by martin= thomson, mnot, ianswett) https://github.com/quicwg/base-drafts/issues/2825 [-transport] [design] = - #2821 Rationalize HTTP/3 stream creation errors (3 by kazuho, LPardue) https://github.com/quicwg/base-drafts/issues/2821 [-http] = - #2816 Handling RESET_STREAM and STOP_SENDING with invalid error codes (= 2 by martinthomson, MikeBishop) https://github.com/quicwg/base-drafts/issues/2816 [-http] [design] = - #2534 ECN text disables ECN too aggressively (2 by mnot, ianswett) https://github.com/quicwg/base-drafts/issues/2534 [-recovery] [-transpo= rt] [design] = - #2858 Signal error upon receipt of multiple trailing HEADERS (2 by LPar= due, MikeBishop) https://github.com/quicwg/base-drafts/issues/2858 [-http] [design] = - #2839 Consider adding flags transport parameter for extension, frame, o= r feature negotiation (2 by martinthomson, chris-wood) https://github.com/quicwg/base-drafts/issues/2839 [-transport] [proposa= l-ready] = - #2823 Do Initial secrets change after Retry packet? (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2823 [-tls] = - #2153 Increase the odds of a stateless reset? (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2153 [-transport] [editori= al] = - #2801 describe how a client is supposed to handle multiple tokens (1 by= martinthomson) https://github.com/quicwg/base-drafts/issues/2801 [-transport] [editori= al] = - #2840 Does rejecting 0-RTT data prohibit ACKing 0-RTT data? (1 by marti= nthomson) https://github.com/quicwg/base-drafts/issues/2840 [-transport] = - #2842 Does it make sense to try 0-RTT after Retry? (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2842 [-transport] = 5 issues closed: - Rationalize HTTP/3 stream creation errors https://github.com/quicwg/bas= e-drafts/issues/2821 [-http] = - Rationalise HTTP_WRONG_SETTING_DIRECTION error https://github.com/quicw= g/base-drafts/issues/2810 [-http] = - Rationalise Server-Push-specific rejection error codes https://github.c= om/quicwg/base-drafts/issues/2812 [-http] = - H3 appendix A.4 GENERAL_PROTOCOL_ERROR https://github.com/quicwg/base-d= rafts/issues/2807 [-http] = - Exceeding Max STREAM ID should be a connection error https://github.com= /quicwg/base-drafts/issues/2825 [-transport] = Pull requests ------------- * quicwg/base-drafts (+13/-17/=F0=9F=92=AC11) 13 pull requests submitted: - Remove unnecessary quotes (by amirlivneh) https://github.com/quicwg/base-drafts/pull/2861 = - Fix grammar (by amirlivneh) https://github.com/quicwg/base-drafts/pull/2860 = - Delayed packets can't create state (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2859 [-transport] [editorial= ] = - Define terms for application actions (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2857 [-http] [-transport] [d= esign] = - transport: fix dangling reference to -tls (by reschke) https://github.com/quicwg/base-drafts/pull/2854 = - transport: fix dangling ref to recovery (by reschke) https://github.com/quicwg/base-drafts/pull/2853 = - recommend resending of 0-RTT data after a Retry (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2852 = - Allow connections to share a port by adding restrictions on zero-length= connection IDs (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2851 = - Fix grammar (by amirlivneh) https://github.com/quicwg/base-drafts/pull/2849 = - Fix grammar (by amirlivneh) https://github.com/quicwg/base-drafts/pull/2848 = - Don't terminate connections, close 'em (by martinthomson) https://github.com/quicwg/base-drafts/pull/2847 [-tls] [editorial] = - fix overspecific coalescing requirement for Initials (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2846 = - Remove stale text that forbids the use of TLS records carrying early da= ta (by kazuho) https://github.com/quicwg/base-drafts/pull/2845 = 5 pull requests received 11 new comments: - #2851 Allow connections to share a port by adding restrictions on zero-= length connection IDs (7 by DavidSchinazi, mikkelfj) https://github.com/quicwg/base-drafts/pull/2851 = - #2848 Fix grammar (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2848 [-transport] [editorial= ] = - #2802 remove misleading sentence about incompatible QUIC versions and A= LPN (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2802 [-tls] = - #2826 Make exceeding stream limits a connection error (1 by martinthoms= on) https://github.com/quicwg/base-drafts/pull/2826 [-transport] [editorial= ] = - #2846 fix overspecific coalescing requirement for Initials (1 by marten= -seemann) https://github.com/quicwg/base-drafts/pull/2846 = 17 pull requests merged: - Rationalize HTTP/3 stream creation errors https://github.com/quicwg/base-drafts/pull/2822 [-http] [design] = - Refactor Push ID related errors https://github.com/quicwg/base-drafts/pull/2820 [-http] [design] = - Rationalize HTTP_WRONG_SETTING_DIRECTION https://github.com/quicwg/base-drafts/pull/2814 [-http] = - Remove HTTP_PUSH_ALREADY_IN_CACHE error https://github.com/quicwg/base-drafts/pull/2813 [-http] = - Compare H2 PROTOCOL_ERROR with HTTP_GENERAL_PROTOCOL_ERROR https://github.com/quicwg/base-drafts/pull/2808 [-http] = - transport: fix dangling reference to -tls https://github.com/quicwg/base-drafts/pull/2854 [-transport] [editorial= ] = - Don't terminate connections, close 'em https://github.com/quicwg/base-drafts/pull/2847 [-tls] [editorial] = - QPACK editorial revision https://github.com/quicwg/base-drafts/pull/2759 [-qpack] [editorial] = - Fix grammar https://github.com/quicwg/base-drafts/pull/2849 [-transport] [editorial= ] = - Fix grammar https://github.com/quicwg/base-drafts/pull/2848 = - fix overspecific coalescing requirement for Initials https://github.com/quicwg/base-drafts/pull/2846 [-transport] [editorial= ] = - Remove stale text that forbids the use of TLS records carrying early da= ta https://github.com/quicwg/base-drafts/pull/2845 [-tls] [editorial] = - Fix title capitalization https://github.com/quicwg/base-drafts/pull/2828 [-transport] [editorial= ] = - remove misleading sentence about connection IDs after Retry https://github.com/quicwg/base-drafts/pull/2832 [-transport] = - Make exceeding stream limits a connection error https://github.com/quicwg/base-drafts/pull/2826 [-transport] [editorial= ] = - Editorial suggestions on the Streams section https://github.com/quicwg/base-drafts/pull/2730 [-transport] = - Transport editorial suggestions https://github.com/quicwg/base-drafts/pull/2731 [-transport] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============0015826160520830628== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday June 30, 2019

Issues

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

4 issues created:

13 issues received 31 new comments:

5 issues closed:

Pull requests

quicwg/base-drafts (+13/-17/=F0=9F=92=AC11)

13 pull requests submitted:

5 pull requests received 11 new comments:

17 pull requests merged:

Repositories tracked by this digest:

--===============0015826160520830628==-- From nobody Sun Jun 30 12:45:52 2019 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 6E6861201A1 for ; Sun, 30 Jun 2019 12:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-T7-yp9zOHL for ; Sun, 30 Jun 2019 12:45:49 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 C468512019B for ; Sun, 30 Jun 2019 12:45:48 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id k21so503839edq.3 for ; Sun, 30 Jun 2019 12:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=V3tujcPcjthlLb+5DseXaWWN3qKlQ86hi+dK3j3r7vM=; b=hl/3timV3C3fNmJ4z6xNlODsaSQ3GPJRxn7N9xOQawttx544gwV7UzZIA+N1UESjg0 draT+c3YzUCIjazXzmXWpnKbTX8eSLnsvSc1wh7y067n0G0KxTYvHHxNGDtXv3xxcYwl vZ1hz/EZ+JKHz31zZeOSADn9YXS8tf1BUlIQp5jMWU+szckeRRclb7BL2cWQj0Q+34+W P/3gODJrWEj/QOuOf6gvJOh1nJDS1nhfSerZZ6Eah5rX3lizZgli8xoFQy+0Ent5BTms /xxwCiLHyPKPsvftF37MF95yYPSTOKtNAN2wJ5RxxDwMbqY/1eVrmm0tLk8kerOZFUZC gxmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=V3tujcPcjthlLb+5DseXaWWN3qKlQ86hi+dK3j3r7vM=; b=Gr5SuQhfbAvbLQsrH5a25DCV/c/at6BaXfnaYIGoXQ5mSsbDIGVm6SjkcjweetIuDw nWncV4VsfMq81/ErBxl1lxbf+bo0cmmCsBg2kqMK/IZEAX7aIPZ5TCdWdAXKr0rrPaWU qtIR7fuZ8zehXZDWAK0pHVSUIHv8jxMH1fPRg8KmERhQxsDlOiKBqpg0LABnz226PEWz GqaCqVjZ1zANx7x1AE+2krdS7XbVuQBooAOIsdYua4DLmtxEEka5iVdzpG4fb43ysq/2 0TQwZClzl6jjt/Q7EGA8RdJvqdkzzZb8gH+m14XjeSnz5GSMOE4n1M6iLGrSML1+P7aX FJvw== X-Gm-Message-State: APjAAAUScpaYjTWlnEwap+mRanbFS1PjceFQsHhQ2fbfToDTLAmk24ZY jheOU42Ev07rhnnbEqwr7Hvjapm9BpWPlS8rLqRwvXSD X-Google-Smtp-Source: APXvYqw/yuicDugdf87kjRoHF0ecDutrauLpYC/aVf8NCjAFmjjQ3Ia7GxaJGvpZKHveHgR8gWKWhf9ennTnztEklcs= X-Received: by 2002:aa7:c999:: with SMTP id c25mr24541593edt.134.1561923947174; Sun, 30 Jun 2019 12:45:47 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 30 Jun 2019 12:45:45 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 30 Jun 2019 12:45:45 -0700 Message-ID: Subject: Low power deep sleep pattern To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000099e90058c8fc293" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 19:45:50 -0000 --000000000000099e90058c8fc293 Content-Type: text/plain; charset="UTF-8" Consider a scenario where a small IoT device is able to store its state in flash and go to deep sleep for a while. When it wakes up it wants to transmit some data and process inbound messages. It does not want to spend time or power on establishing a new connection and 0-RTT is not ideal for several reasons: it requires a roundtrip before data are reliable and most connection state is lost and must be renegotiated. QUIC has a potentially long idle timeout so it could deal with a device that is waking up. One problem may be how retransmission is handled - will the peer be tolerant to a 1 minute delay before seeing an ACK? Another problem is middleboxes. While not solveable in general, it might be worth considering to offer a signal that indicates that the usual timeouts do not apply - the IP might not even be the same if a DHCP server assigns a new IP on wakeup, but it still has the CID. Mikkel --000000000000099e90058c8fc293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Consider a scenario = where a small IoT device is able to store its state in flash and go to deep= sleep for a while.