From nobody Wed May 1 05:33: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 3C0681200CD for ; Wed, 1 May 2019 05:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5z52Owu3m_nW for ; Wed, 1 May 2019 05:33:14 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 7130F120020 for ; Wed, 1 May 2019 05:33:14 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id f125so10077388qke.6 for ; Wed, 01 May 2019 05:33:14 -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=m05pXaUCrBYv9PhtfTPnVOdZappYOQ/ilsKFfWxurWo=; b=YAl+R7a4b5ZuTWAuyozH5jGcNL0XPWBuKh0B8An2tibBmvm3gKBu6Js16c/6IhXh2Z AG4O3tY4GX1qiTD881fPar9n6DlOgzYEAy4rz0bgX5bOkjwYMDO27M0NBcgz0kl4AxQa FmNtlMYQG7JPZBdzYBn2AJ7q0gRilOE71Ix+JqSYW1uPaWJNYKF1NWsK74y1olarM8Y7 Kycaoiln7hk9zpvTUaYvWIpEs9HMgsVQlmrEco6D80dAgpDYXI/CyZ5NXAo5MmIUWkHe 5WcrEpMhRFPgaS4DRVlR1bjL160wAioxnLJYQuhL5jJNACGF4cvfyfo2rexLTiu01/07 twZw== 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=m05pXaUCrBYv9PhtfTPnVOdZappYOQ/ilsKFfWxurWo=; b=s8/TpQeYoPZ5uo2Zy1iGgPVSKpke0QjvJLKDYzceAlYuFny9vIQjjF3UYbmJ4EOAiX qs1LfUVsPthWe5sPt9FOfMauUDyoDEozVptHEfIqMjNQkwNszj5IkrhoBJuAF1lJthIX iDj4FEevB5KuYWoKJuQwVMX/YuQjBDaLhKvcx4ds9+RJnx0KrkAQ/mJCFzUII38ASQer QVxcmn19A6LhBZ/R1T/D3Vw3dDSVP+vKQdMK4lO5SrBrGeRGi3teYISP3NBgDDt8c4Jh mipGrh8WFAm5svwzX4POdbi9EmEq9DmMFo/j54WbCZtHDt0pge7KOb0NyYKBtCHv70QD +fIQ== X-Gm-Message-State: APjAAAXjAmWJMt4KIdU/II0mRlmYkbrfKbEADm2pK6eWQsmMpCCzfG8O pSmJ/7KG0x2a28XkCPlmyCMjgrzbfxk= X-Google-Smtp-Source: APXvYqxMVsL7gUn71vjz47V9yrfj2lhEQYz9m+Tx4yEwoKKyXV6uJ/9r0l/xxnrqCbCmJ4yVtAsLSw== X-Received: by 2002:a05:620a:1315:: with SMTP id o21mr37764707qkj.318.1556713993523; Wed, 01 May 2019 05:33:13 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id q11sm9465590qkn.19.2019.05.01.05.33.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 05:33:12 -0700 (PDT) Date: Wed, 1 May 2019 08:33:06 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: quic@ietf.org Subject: Re: Connection ID Space Message-ID: <20190501123305.GA5964@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , quic@ietf.org References: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> 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: Wed, 01 May 2019 12:33:16 -0000 On Tue, Apr 30, 2019 at 08:31:47PM -0400, Martin Thomson wrote: > That's on the TODO list anyway, as we agreed to remove the > 0/4-18 restriction for the short packet header a while back. I do not recall -- when was that decided? - Dmitri. From nobody Wed May 1 07:31: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 9FF37120186 for ; Wed, 1 May 2019 07:31:39 -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=m0fLJluu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WH6N1Vcb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muQyBL6kHjjw for ; Wed, 1 May 2019 07:31:38 -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 7982E12018F for ; Wed, 1 May 2019 07:31:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8245C21F83 for ; Wed, 1 May 2019 10:31:37 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 01 May 2019 10:31:37 -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=C+0+LxZtCnqZtXj2DLnCYiSMI6zKP+y 2HEwoWrzhJWI=; b=m0fLJluux1C32MGOJCxKRPI/qv7AUHsicCPIa5o0vp5ZO9t Uj1G6I3dWkTeDTtulhMCRKU8ZI9NsEoLq90VIaMxW1HTT5hDZBcaP/oH3E+iwDC7 MZFanjFXCRNRk3SOzelXmHYrojpaWp7qe6Zf8Z18q5gMQJtQ2tLAK1AHo6UGq/Cy jdmphyxudaVSxQ20SHL0EFR40VFlFYiS/7yj5aeMNJtDQ5OvH2+udGqIlQFMrxDT XePBIilqTuatJbwRh7VNE4wSsOumR1ayh3YomOEOPqF64c10Rlp+OwB3+Pxq+BhR YzAqGnEX4hNG62xCN6cX7yJT/aOAHouOwVDtwzQ== 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=fm2; bh=C+0+Lx ZtCnqZtXj2DLnCYiSMI6zKP+y2HEwoWrzhJWI=; b=WH6N1Vcbj82Dr1UYlfBcvB C1WQAtD93oBdKnbWB2MyOARB2yHzkE3MIOgXdJVUtoLUi1sXgRFCst8vDbPiGzQD NHJjff2TrIW/FbhIcvg3pyAye4DpJml/CX6/NVXyxZ9cXBHqfciFPuxQRaYlNK/J URLGcXrR3KRzrGyL0cAPyxvBb1+giD/tgs8Qt4hui8bG3XC5yIvrkEU5qwn0MOCI hPP/ny0VlVa9W86dKBXoY+zV2HH8+G/3aTMzyd2Ka+hBncQCKhwFX5JPoO6/ic+O DeZpW6xZNYQnGsUaI9JRkrHriMhnMCBBghu5dNP+8zw/6yfAnMsBOjmRNmT26fHA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieejgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BF7497C199; Wed, 1 May 2019 10:31:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <20190501123305.GA5964@ubuntu-dmitri> References: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> <20190501123305.GA5964@ubuntu-dmitri> Date: Wed, 01 May 2019 10:31:47 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Connection ID Space 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, 01 May 2019 14:31:40 -0000 On Wed, May 1, 2019, at 14:33, Dmitri Tikhonov wrote: > On Tue, Apr 30, 2019 at 08:31:47PM -0400, Martin Thomson wrote: > > That's on the TODO list anyway, as we agreed to remove the > > 0/4-18 restriction for the short packet header a while back. > > I do not recall -- when was that decided? It was in relation to a request for a *smaller* connection ID. Marten might remember better than I. From nobody Wed May 1 07:34: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 51CDC120196 for ; Wed, 1 May 2019 07:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 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, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 68Bes3X10vSl for ; Wed, 1 May 2019 07:34:52 -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 0C4F112017D for ; Wed, 1 May 2019 07:34:52 -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 x41ERRYR002815; Wed, 1 May 2019 15:34:51 +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=n0f3mMo4tYFhNOEO+Ytnosvu9IqOE3jVODyreI9pt6M=; b=aWI25+nAPPRPcatEHHfUsvJYwg2p1jO6j2ZTnwFzEaE5gvxDYFVpFWzeqx/s+3vg3tOw YVsbAxopCMYy1O/jbLVpFyLA2boYMhkytUgUEcU4fre1Ht7w8be9xEseVWMZDJ//Hq1H kJIrERNTHmnWg470uYiPez5uH+kvNbAGl5x2y1ivbJtztazqbhVJ8jDupIfCVW9kohxm JVqKmcdWqVlpy9nV5/6c8VVS6Ynre6qR+E4w3jb7y7SPr4Ms0ZqNgVs9l46XdWpKsiL1 PalVsLKlf1B/987VU0YUkkosbpvNz6nqjzt8PizW9QbcoynhvClYegywxEcsqelsu+a6 Zw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2s670vye4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 May 2019 15:34:50 +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 x41EWMt2011982; Wed, 1 May 2019 10:34:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2s4jdvhkm5-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 May 2019 10:34:41 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 10:33:54 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1473.003; Wed, 1 May 2019 10:33:54 -0400 From: "Lubashev, Igor" To: John Wason , Ted Hardie CC: IETF QUIC WG Subject: RE: QUIC for robotics and other time-sensitive applications Thread-Topic: QUIC for robotics and other time-sensitive applications Thread-Index: AQHU/4kFmHgV+zSU3UK4cEKX71ffXaZVfeQAgAAD3YCAAM7+UA== Date: Wed, 1 May 2019 14:33:53 +0000 Message-ID: References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.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.42] Content-Type: multipart/alternative; boundary="_000_df610cdb89614e459f64292ca02c2041usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-01_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-1905010093 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-01_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-1905010093 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, 01 May 2019 14:34:54 -0000 --_000_df610cdb89614e459f64292ca02c2041usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9obiwNCg0KSSBhbSBoYXBweSB0byByZXN1cnJlY3QgdGhhdCBkcmFmdC1sdWJhc2hldi1xdWlj LXBhcnRpYWwtcmVsaWFiaWxpdHkgZm9yIFFVSUMgdjIgKHNvbWUgcGVvcGxlIHByZWZlcnJlZCB2 ZXJzaW9uIDAyLCB3aGljaCBhY3R1YWxseSBnZXRzIHlvdSBhIGJpdCBtb3JlIGZlYXR1cmVzIGF0 IHRoZSBjb3N0IG9mIGEgYml0IG1vcmUgY29tcGxleGl0eSkuDQoNCkkgd291bGQgbGlrZSB0byBm aXJzdCB1bmRlcnN0YW5kIHdoYXQgcGFydGlhbGx5IHJlbGlhYmxlIHN0cmVhbXMgZ2l2ZSB5b3Ug dGhhdCBpcyBub3QgYXZhaWxhYmxlIHdpdGggcmVndWxhciBzdHJlYW1zLiAgSS5lLiB3aGF0IGFy ZSB5b3UgbWlzc2luZyBpZiB5b3UgdXNlIFNUUkVBTSAod2l0aCBhIHBvc3NpYmxlIHN1YnNlcXVl bnQgUkVTRVQpIGZvciBtZXNzYWdlcz8gIChZb3UgY2Fubm90IHVzZSBEQVRBR1JBTSBmb3IgbWVz c2FnZXMsIHNpbmNlIHlvdSB3b3VsZCBsaWtlIHRoZSB0cmFuc3BvcnQgdG8gZmFjaWxpdGF0ZSBy ZXRyYW5zbWlzc2lvbiB1bnRpbCBleHBpcmF0aW9uLikNCg0KTXkgZHJhZnQtbHViYXNoZXYtcXVp Yy1wYXJ0aWFsLXJlbGlhYmlsaXR5IGxpc3RzIGEgZmV3IHRoaW5ncyB0aGF0IHN0cmVhbS1wZXIt bWVzc2FnZSBkb2VzIG5vdCBnZXQgeW91Og0KDQoNCiAgMS4gIElmIHlvdSBoYXZlIG11bHRpcGxl IGFwcGxpY2F0aW9uIG1lc3NhZ2Ugc3RyZWFtcywgeW91IHdvdWxkIG5lZWQgYSBoZWFkZXIgZm9y IGVhY2ggUVVJQyBzdHJlYW0gdG8gaWRlbnRpZnkgdGhlIGFwcGxpY2F0aW9uIHN0cmVhbS4gIFRo aXMgc2VlbXMgbGlrZSBhIHNtYWxsIGJ1cmRlbiwgZXhjZXB0IGZvciB2ZXJ5IHNob3J0IG1lc3Nh Z2VzLg0KICAgICAqICAgSWYgdGhlIG9yZGVyIG9mIG1lc3NhZ2VzIGluIGFuIGFwcGxpY2F0aW9u IHN0cmVhbSBtYXR0ZXJzLCB5b3Ugd291bGQgbmVlZCB0byByZW9yZGVyIHRoZW0geW91cnNlbGYu ICBUaGlzIGNhbm5vdCBiZSB2ZXJ5IGNvbXBsaWNhdGVkIGZvciB0aGUgYXBwbGljYXRpb24uDQoN Cg0KICAxLiAgUVVJQyBwZXItYXBwbGljYXRpb24tc3RyZWFtIGZsb3cgY29udHJvbCBpcyByZW5k ZXJlZCBpbmVmZmVjdGl2ZS4gIEkgYW0gYWN0dWFsbHkgbm90IGEgaHVnZSBmYW4gb2YgUVVJQyBw ZXItc3RyZWFtIGZsb3cgY29udHJvbCwgYXMgSSBzdHJvbmdseSBwcmVmZXIgc3RyZWFtIHByaW9y aXRpZXMgYXMgYSBzaWduYWwuICBCdXQgSSBub3cga25vdyBvZiBhIGNhc2Ugd2hlbiBwZXItc3Ry ZWFtIGZsb3cgY29udHJvbCBpcywgaW5kZWVkIHVzZWZ1bCAod2hlbiB0aGVyZSBpcyBvbmx5IG9u ZSBzbG93IGRyYWluaW5nIHN0cmVhbSB0aGF0IHVzZXMgdXAgdGhlIGVudGlyZSBjb25uZWN0aW9u IGJ1ZmZlciBiZWZvcmUgYSBoaWdoZXItcHJpb3JpdHkgc3RyZWFtIHNob3dzIHVwKS4NCg0KQXJl IHRoZXJlIGFueSBvdGhlciBiZW5lZml0cyB5b3Ugc2VlIGluIHBhcnRpYWxseSByZWxpYWJsZSBz dHJlYW1zPw0KDQoNCiAgKiAgIElnb3INCg0KRnJvbTogSm9obiBXYXNvbiA8am9obndhc29uMUBn bWFpbC5jb20+DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAzMCwgMjAxOSA1OjUyIFBNDQpUbzogVGVk IEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBRVUlDIGZvciByb2JvdGljcyBhbmQgb3RoZXIgdGltZS1zZW5z aXRpdmUgYXBwbGljYXRpb25zDQoNCg0KVGhhbmtzIFRlZCwgdGhpcyBsb29rcyB2ZXJ5IGludGVy ZXN0aW5nLiBCYXNlZCBvbiB0aGVzZSBkb2N1bWVudHMgdGhlIERFVE5FVCBzaXRzIGJlbG93IHRo ZSBsZXZlbCBvZiBRVUlDIHRoYXQgd2UgYXJlIGN1cnJlbnRseSBkaXNjdXNzaW5nIGFuZCB3b3Vs ZCBtYWlubHkgYWZmZWN0IHRoZSBJUCBoZWFkZXIgZm9ybWF0IG9mIHRoZSByZXN1bHRpbmcgVURQ IHBhY2tldHMuIFRoZSBRVUlDIHByb3RvY29sIHdpbGwgc3RpbGwgcmVxdWlyZSBzb21lIGZvcm0g b2YgcGFydGlhbCByZWxpYWJpbGl0eSB0byBmdW5jdGlvbiBvbiBhIERFVE5FVCBuZXR3b3JrLg0K DQogICAgLUpvaG4gV2Fzb24NCk9uIDQvMzAvMjAxOSA1OjM3IFBNLCBUZWQgSGFyZGllIHdyb3Rl Og0KSGkgSm9obiwNCg0KVGhhbmtzIGZvciB0aGUgbWVzc2FnZS4gIElmIHlvdSBoYXZlIG5vdCBh bHJlYWR5IHJldmlld2VkIHRoZSB3b3JrIG9mIERFVE5FVCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy93Zy9kZXRuZXQvYWJvdXQvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfd2dfZGV0bmV0X2Fib3V0 XyZkPUR3TURhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZM M3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09dWVxM1ltRjdVYWp3Z0NidExTcGxiaG43SXAwNXdG Qk0yMEtidWp6amloMCZzPXhMWEN6Unlrd1h6WDdiUV9FZkFoNFJlYTJzRXplbDl3Z25wclFBdXdQ d2MmZT0+KSBoZXJlIGluIHRoZSBJRVRGLCBpdCBtaWdodCBiZSB1c2VmdWwgdG8gZG8gc28sIGFz IHRoZXJlIGFyZSBhIG51bWJlciBvZiBlbGVtZW50cyBvZiB5b3VyIHVzZSBjYXNlIHdoaWNoIGFw cGVhcmVkIHRvIGJlIHNoYXJlZCB3aXRoIHRoZWlyIHdvcmsuICBJbiBwYXJ0aWN1bGFyLCBpdCBt aWdodCBiZSB1c2VmdWwgdG8gY29uc2lkZXIgd2hldGhlciB0aGUgaW50ZWdyYXRpb24gb2YgdGhl aXIgcHJvcG9zZWQgSVAgZGF0YSBwbGFuZSAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1kZXRuZXQtZHAtc29sLWlwLz9pbmNsdWRlX3RleHQ9MTxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmll dGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRkZXRuZXQtMkRkcC0yRHNvbC0yRGlwXy0zRmluY2x1 ZGUtNUZ0ZXh0LTNEMSZkPUR3TURhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1 dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09dWVxM1ltRjdVYWp3Z0NidExT cGxiaG43SXAwNXdGQk0yMEtidWp6amloMCZzPVRJektyLUlPNDR5akJmUGhoUHA1bWxkejhRRU5S UUdFLTRXRDdiYmRuNWsmZT0+KSB3aXRoIFFVSUMgd291bGQgYmUgdmFsdWFibGUgaW4gYWNoaWV2 aW5nIHlvdXIgdGltaW5nIGdvYWxzLg0KDQoNCmJlc3QgcmVnYXJkLA0KDQpUZWQgSGFyZGllDQoN Ck9uIFR1ZSwgQXByIDMwLCAyMDE5IGF0IDEyOjE1IFBNIEpvaG4gV2Fzb24gPGpvaG53YXNvbjFA Z21haWwuY29tPG1haWx0bzpqb2hud2Fzb24xQGdtYWlsLmNvbT4+IHdyb3RlOg0KR3JlZXRpbmdz IFFVSUMgV0csDQoNClRoZSBkaXNjdXNzaW9uIG9uIElzc3VlICM5MiBvZiB3ZWJydGMtcXVpYyBz dWdnZXN0ZWQgdGhhdCBJIHBvc3QgbXkNCnJlcXVpcmVtZW50cyB0byB0aGlzIGxpc3QuDQoNCkkg YW0gYSByb2JvdGljcyBlbmdpbmVlciBhbmQgdGhlIGRldmVsb3BlciBvZiBSb2JvdCBSYWNvbnRl dXIsIGENCmNvbW11bmljYXRpb24gZnJhbWV3b3JrIGZvciByb2JvdGljcyBhbmQgYXV0b21hdGlv biBzeXN0ZW1zDQooaHR0cHM6Ly9naXRodWIuY29tL3JvYm90cmFjb250ZXVyL3JvYm90cmFjb250 ZXVyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f Z2l0aHViLmNvbV9yb2JvdHJhY29udGV1cl9yb2JvdHJhY29udGV1ciZkPUR3TURhUSZjPTk2WmJa WmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201 NUtQbWxvJm09dWVxM1ltRjdVYWp3Z0NidExTcGxiaG43SXAwNXdGQk0yMEtidWp6amloMCZzPVZJ ekRWWGpyNjNVd0hiVDBydllDelM5MVZBWmFyeVNlV2Z0Rk5Dc0MyaEUmZT0+KS4gUm9ib3RpY3MN CmFwcGxpY2F0aW9ucyByZXF1aXJlIGRpZmZlcmVudCBkYXRhIHR5cGVzIGFuZCBRb1Mgd2hlbiBj b21wYXJlZCB0bw0KYnVzaW5lc3Mgb3Igd2ViIGFwcGxpY2F0aW9ucy4gUm9ib3RpY3MgYXBwbGlj YXRpb25zIG5lZWQgcmVhbC10aW1lDQpjb21tdW5pY2F0aW9uIG9mIGlzb2Nocm9ub3VzIGRhdGEs IGZvciBpbnN0YW5jZSBjb25zdGFudCB1cGRhdGVzIG9uIHRoZQ0KcG9zaXRpb24gb2YgdGhlIGpv aW50cyBvZiB0aGUgcm9ib3QsIGFsb25nc2lkZSBnZW5lcmljDQpub24tdGltZS1zZW5zaXRpdmUg ZGF0YS4gQ3VycmVudGx5IG1vc3Qgcm9ib3RpY3MgYXBwbGljYXRpb25zIGFyZSB1c2luZw0KVENQ IChSb2JvdCBSYWNvbnRldXIsIFJPUyosIE9QQy9VQSksIFVEUCAoRERTLCBST1MyLCBST1MqKSwg b3Igc29tZSBmb3JtDQpvZiBjdXN0b20gRXRoZXJuZXQgcHJvdG9jb2wgKEV0aGVybmV0L0lQLCBF dGhlckNBVCwgUG93ZXJMaW5rKS4gVG8gYWRkDQptb3JlIGNvbmZ1c2lvbiB0byB0aGUgc2l0dWF0 aW9uLCB0aGVyZSBpcyB0aGUgcmVjZW50IGludHJvZHVjdGlvbiBvZg0KSUVFRSA4MDIuMVEgVGlt ZSBTZW5zaXRpdmUgTmV0d29ya2luZyAoVFNOKSB3aGljaCBjbGFpbXMgdG8gYWxsb3cgVENQDQph bmQgVURQIHRvIGFjaGlldmUgaGFyZCByZWFsLXRpbWUgcGVyZm9ybWFuY2UuDQoNCldoaWxlIHRo ZXJlIGFyZSBtYW55IHJvYm90aWNzIHByb3RvY29scyBvdXQgdGhlcmUsIG9ubHkgUm9ib3QgUmFj b250ZXVyDQphbmQgT1BDL1VBIGFyZSBjb21wYXRpYmxlIHdpdGggZXhpc3Rpbmcgd2ViIGFuZCBj bG91ZCBpbmZyYXN0cnVjdHVyZS4NCihTb21lIGxpbWl0ZWQgc3VwcG9ydCBmb3IgUk9TL1JPUzIg aGFzIGJlY29tZSBhdmFpbGFibGUgb24gQVdTLCBidXQgdGhlDQpkZXNpZ24gb2YgUk9TIGRvZXMg bm90IHBsYXkgdmVyeSB3ZWxsIG91dHNpZGUgb2YgbG9jYWwgbmV0d29ya3MuKikgUm9ib3QNClJh Y29udGV1ciBpbXBsZW1lbnRzIHdlYiBicm93c2VyIGFuZCB3ZWIgc2VydmVyIHN1cHBvcnQgYnkg YWxsb3dpbmcgdGhlDQp3ZWJzb2NrZXQgcHJvdG9jb2wgdG8gYmUgdXNlZC4gQ2xpZW50cyBjYW4g dXNlIGEgVVJMIHRoYXQgc3BlY2lmaWVzIHRoYXQNCnRoZSBjb25uZWN0aW9uIGlzIGEgd2Vic29j a2V0LCBhbmQgaW5jb21pbmcgVENQIGNvbm5lY3Rpb25zIGNhbiBkZXRlY3QNCmlmIHRoZSBjb25u ZWN0aW9uIGlzIHRoZSBSb2JvdCBSYWNvbnRldXIgcHJvdG9jb2wgb3IgYW4gaW5jb21pbmcNCndl YnNvY2tldCBjb25uZWN0aW9uLiBSb2JvdCBSYWNvbnRldXIgcnVubmluZyBpbnNpZGUgYW4gQVNQ Lk5FVDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f QVNQLk5FVCZkPUR3TURhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBN XzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09dWVxM1ltRjdVYWp3Z0NidExTcGxiaG43 SXAwNXdGQk0yMEtidWp6amloMCZzPTl1Y2hCZFJ6Y3VxdElCNmxadVQwd2xHb2VsRldnSXpNVlQ0 aFRCR0VWeGMmZT0+IHdlYg0Kc2VydmVyIGhhcyBiZWVuIGRlbW9uc3RyYXRlZCwgYW5kIHRoZXJl IGlzIG5vIHRlY2huaWNhbCByZWFzb24gdGhhdA0Kb3RoZXIgc2VydmVyIHRlY2hub2xvZ2llcyBj YW5ub3QgYWNjZXB0IFJvYm90IFJhY29udGV1ciBjb25uZWN0aW9ucw0KdGhyb3VnaCB3ZWJzb2Nr ZXRzLiAoT1BDL1VBIHVzZXMgU09BUCBmb3IgaXRzIHdlYiBiYXNlZCB0cmFuc3BvcnQsIGJ1dA0K c3VwcG9ydCBpcyB2ZXJ5IHBvb3IgYW5kIG9ubHkgYXZhaWxhYmxlIGluIGEgZmV3IGltcGxlbWVu dGF0aW9ucy4pDQoNClRoZSBtYWluIGlzc3VlIGxpbWl0aW5nIFJvYm90IFJhY29udGV1ciBmb3Ig bW9yZSBkZW1hbmRpbmcgYXBwbGljYXRpb25zDQppcyB0aGUgdXNlIG9mIFRDUCBmb3IgZGF0YSB0 cmFuc3BvcnQuIFRDUCBzdWZmZXJzIGZyb20gImhlYWQtb2YtbGluZSINCmJsb2NraW5nLCB3aGlj aCBtZWFucyB0aGF0IGlmIHN0YWxlIGRhdGEgZW5jb3VudGVycyBhbiBlcnJvciBpdCBjYW4gc3Rv cA0KZnJlc2ggZGF0YSBmcm9tIHJlYWNoaW5nIHRoZSBvdGhlciBwZWVyLiBUaGVyZSBpcyBhbHNv IHRoZSBwcm9ibGVtIG9mDQpsYXJnZSBtZXNzYWdlcyBibG9ja2luZyB0aGUgdHJhbnNtaXNzaW9u IG9mIHNtYWxsZXIsIG1vcmUgdGltZSBzZW5zaXRpdmUNCm1lc3NhZ2VzIG9uIHRoZSBjb25uZWN0 aW9uLiBRVUlDIGFwcGVhcnMgdG8gc29sdmUgbW9zdCBvZiB0aGVzZQ0KcHJvYmxlbXMsIGFuZCB0 aGUgd2VicnRjLXF1aWMgc3VwcG9ydCB1bmRlciBkZXZlbG9wbWVudCBwcm92aWRlcyBhIGxvdA0K b2YgbmV3IGFuZCBpbnRlcmVzdGluZyBvcHBvcnR1bml0aWVzIGZvciBpbnRlZ3JhdGluZyByb2Jv dGljcw0KYXBwbGljYXRpb25zIHdpdGggd2ViIHRlY2hub2xvZ3kuIEJ5IGFkb3B0aW5nIFFVSUMs IHRoZSByZXN1bHRpbmcNCnNvZnR3YXJlIHdpbGwgcmVtYWluIGNvbXBsZXRlbHkgY29tcGF0aWJs ZSB3aXRoIHdlYiBpbmZyYXN0cnVjdHVyZS4NCg0KVHJhbnNtaXR0aW5nIHRpbWUtc2Vuc2l0aXZl IGRhdGEgcmVxdWlyZXMgdGhlIGFiaWxpdHkgdG8gbXVsdGlwbGV4IChhbmQNCnByaW9yaXRpemUp IG1lc3NhZ2VzIGFuZCBkcm9wIG1lc3NhZ2VzIGlmIHRoZSBkYXRhIGNvbnRhaW5lZCBiZWNvbWVz DQpzdGFsZS4gVGhlIG11bHRpcGxleGluZyBpc3N1ZSBpcyBzb2x2ZWQgdXNpbmcgdGhlICJzdHJl YW1zIGFzIG1lc3NhZ2VzIg0KY29uY2VwdCBpbiBRVUlDLCB3aXRoIGJ1aWx0IGluIHByaW9yaXR5 IGhhbmRsaW5nLiBUaGlzIGRlc2lnbiBsb29rcyB2ZXJ5DQpwcm9taXNpbmcsIGFuZCBjb25zaWRl cmFibHkgc2ltcGxlciB0byB1c2UgY29tcGFyZWQgdG8gU0NUUCBzdHJlYW1zLiBUaGUNCmN1cnJl bnQgaXNzdWUgdGhhdCBpcyBzb21ld2hhdCBxdWVzdGlvbmFibGUgaXMgdGhlIGltcGxlbWVudGF0 aW9uIG9mDQpwYXJ0aWFsIHJlbGlhYmlsaXR5LiBUaGUgZGlzY3Vzc2lvbiByaWdodCBub3cgaXMg Zm9jdXNlZCBvbiBEQVRBR1JBTQ0KZXh0ZW5zaW9ucyAoZHJhZnQtcGF1bHktcXVpYy1kYXRhZ3Jh bS0wMiksIHdoaWNoIGFsbG93IGZvciAicmF3IiBhY2Nlc3MNCnRvIHRoZSBzb2NrZXQgc28gcHJv dG9jb2xzIHN1Y2ggYXMgUlRQIGNhbiB0dW5uZWwgdGhyb3VnaCBRVUlDLiBUaGlzDQpyZXF1aXJl bWVudCBpcyBxdWl0ZSBhIGJpdCBkaWZmZXJlbnQgdGhhbiB3aGF0IGlzIHJlcXVpcmVkIGZvciBh bg0KYXBwbGljYXRpb24gbGlrZSBSb2JvdCBSYWNvbnRldXIuIFJvYm90IFJhY29udGV1ciBpcyBi YXNlZCBvbiBtZXNzYWdlDQpwYXNzaW5nLCB3aGVyZSBlaXRoZXIgdGhlIGVudGlyZSBtZXNzYWdl IGlzIHJlY2VpdmVkIG9yIHRoZSBlbnRpcmUNCm1lc3NhZ2UgaXMgY2FuY2VsbGVkIGJlY2F1c2Ug dGhlIGRhdGEgY29udGFpbmVkIGlzIHN0YWxlLiBUaGUgbWVzc2FnZQ0KbWF5IGJlIGNvbnNpZGVy YWJseSBsYXJnZXIgdGhhbiBNVFUsIGFuZCB0aGUgUW9TIG1heSBiZSAicGFydGlhbCwiDQptZWFu aW5nIHRoYXQgYSBzZXQgbnVtYmVyIG9mIGF0dGVtcHRzIG1heSBiZSBtYWRlIHRvIHJlc2VuZCwg YW5kL29yDQp0aGVyZSBpcyBhbiBleHBpcmF0aW9uIHRpbWUgb24gdGhlIG1lc3NhZ2UuIFRoaXMg Y2FwYWJpbGl0eSBpcyBkaXNjdXNzZWQNCmluIGRyYWZ0LWx1YmFzaGV2LXF1aWMtcGFydGlhbC1y ZWxpYWJpbGl0eS0wMywgYW5kIGlzIHNpbWlsYXIgdG8gaG93DQpTQ1RQIGhhbmRsZXMgcGFydGlh bCByZWxpYWJpbGl0eS4gSWYgb25seSBhIHJhdyBEQVRBR1JBTSBjYXBhYmlsaXR5IGlzDQpwcm92 aWRlZCwgdGhlbiBwYXJ0aWFsIHJlbGlhYmlsaXR5IHdpbGwgbmVlZCB0byBiZSBidWlsdCBvbiB0 b3Agb2YgUVVJQywNCmRlZmVhdGluZyB0aGUgcHVycG9zZSBvZiB1c2luZyBRVUlDIGZvciB0aGlz IGFwcGxpY2F0aW9uLiBPdGhlcg0KYXBwbGljYXRpb25zIHN1Y2ggYXMgb25saW5lIGdhbWluZyBo YXZlIHZlcnkgc2ltaWxhciBwZXJmb3JtYW5jZQ0KcmVxdWlyZW1lbnRzLCBzbyBJIHRoaW5rIHRo YXQgdGhlIHBhcnRpYWwgcmVsaWFiaWxpdHkgY2FwYWJpbGl0eSB3aWxsIGJlDQppbXBvcnRhbnQg dG8gbWFueSBmdXR1cmUgdXNlcnMuDQoNClRoZSBjb21wbGV4aXR5IGFuZCByZXF1aXJlZCBlZmZv cnQgdG8gYWRkIHRoZSBwYXJ0aWFsIHJlbGlhYmlsaXR5DQpjYXBhYmlsaXR5IHRvIFFVSUMgaXMg bG93LCBzbyBJIGhvcGUgdGhhdCB0aGlzIGNhcGFiaWxpdHkgaXMgbm90IGFiYW5kb25lZC4NCg0K Um9ib3QgUmFjb250ZXVyIGhhcyByZWNlaXZlZCBhIGdyYW50IGZyb20gdGhlIFVuaXRlZCBTdGF0 ZXMgQVJNDQpJbnN0aXR1dGUgYW5kIE5ldyBZb3JrIFN0YXRlIHRvIGJlZ2luIGNvbW1lcmNpYWxp emluZyB0aGUgdGVjaG5vbG9neS4NClRoaXMgcHJvamVjdCB3aWxsIGJlIGRvbmUgaW4gcGFydG5l cnNoaXAgd2l0aCBXYXNvbiBUZWNobm9sb2d5LCBMTEMsDQpSZW5zc2VsYWVyIFBvbHl0ZWNobmlj IEluc3RpdHV0ZSwgU291dGh3ZXN0IFJlc2VhcmNoIEluc3RpdHV0ZSwgYW5kDQpVbml0ZWQgVGVj aG5vbG9naWVzIFJlc2VhcmNoIENlbnRlci4gVGhlIHByb2plY3Qgc3RhcnRzIHNvb24sIGFuZA0K Y29uc2lkZXJhYmxlIGRldmVsb3BtZW50IGVmZm9ydCB3aWxsIGJlIGludmVzdGVkIGluIHRoZSBS b2JvdCBSYWNvbnRldXINCnRlY2hub2xvZ3kgc3RhcnRpbmcgZWFybHkgc3VtbWVyLiBJbnRlZ3Jh dGluZyBRVUlDIGlzIG9uZSBvZiB0aGUgdGFza3MNCnRoYXQgSSBob3BlIHRvIHVuZGVydGFrZSBk dXJpbmcgdGhpcyBwcm9qZWN0Lg0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55 IHF1ZXN0aW9ucyBhYm91dCBSb2JvdCBSYWNvbnRldXIgb3INCnRoZSByZXF1aXJlbWVudHMgZm9y IFFVSUMgaW4gcm9ib3RpY3MgYXBwbGljYXRpb25zLg0KDQogICAgIC1Kb2huIFdhc29uDQoNCigq IEkgYW0gYXdhcmUgdGhhdCB0aGVyZSBhcmUgc29tZSBjYXZlYXRzIHRvIGhvdyBST1MvUk9TMiBp bnRlcmFjdCB3aXRoDQp0aGUgd2lkZXIgd29ybGQsIGJ1dCB0aGUgdGVjaG5vbG9naWVzIGFyZSBu b3QgYnVpbHQgb24gb3IgY29tcGF0aWJsZQ0Kd2l0aCB3ZWIgc3RhbmRhcmRzIHNvIGFuIGluIGRl cHRoIGRpc2N1c3Npb24gaXMgbm90IHJlbGV2YW50IGZvciB0aGUNCmN1cnJlbnQgdG9waWMuIFJP UyBkb2VzIGhhdmUgYSBVRFAgdHJhbnNwb3J0LCBidXQgaXQgaXMgbm90IGNvbW1vbmx5IHVzZWQu KQ0KDQotLQ0KSm9obiBXYXNvbiwgUGguRC4NCldhc29uIFRlY2hub2xvZ3ksIExMQw0KMTYgU3Rl cmxpbmcgTGFrZSBSZA0KVHV4ZWRvLCBOWSAxMDk4Nw0KKDUxOCkgMjc5LTYyMzQNCndhc29uQHdh c29udGVjaC5jb208bWFpbHRvOndhc29uQHdhc29udGVjaC5jb20+DQoNCi0tDQoNCkpvaG4gV2Fz b24sIFBoLkQuDQoNCldhc29uIFRlY2hub2xvZ3ksIExMQw0KDQoxNiBTdGVybGluZyBMYWtlIFJk DQoNClR1eGVkbywgTlkgMTA5ODcNCg0KKDUxOCkgMjc5LTYyMzQNCg0Kd2Fzb25Ad2Fzb250ZWNo LmNvbTxtYWlsdG86d2Fzb25Ad2Fzb250ZWNoLmNvbT4NCg== --_000_df610cdb89614e459f64292ca02c2041usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc5ODgzNTc0MzsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4MDUzNjcwNDggNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTgyNTEy NTkwMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk0 MzEyMzE2IC03ODQxNzM0NzggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5K b2huLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SSBhbSBoYXBw eSB0byByZXN1cnJlY3QgdGhhdCA8L3NwYW4+DQpkcmFmdC1sdWJhc2hldi1xdWljLXBhcnRpYWwt cmVsaWFiaWxpdHkgZm9yIFFVSUMgdjIgKHNvbWUgcGVvcGxlIHByZWZlcnJlZCB2ZXJzaW9uIDAy LCB3aGljaCBhY3R1YWxseSBnZXRzIHlvdSBhIGJpdCBtb3JlIGZlYXR1cmVzIGF0IHRoZSBjb3N0 IG9mIGEgYml0IG1vcmUgY29tcGxleGl0eSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPkkgd291bGQgbGlrZSB0byBmaXJzdCB1bmRlcnN0YW5kIHdoYXQgcGFydGlhbGx5IHJl bGlhYmxlIHN0cmVhbXMgZ2l2ZSB5b3UgdGhhdCBpcyBub3QgYXZhaWxhYmxlIHdpdGggcmVndWxh ciBzdHJlYW1zLiZuYnNwOyBJLmUuIHdoYXQgYXJlIHlvdSBtaXNzaW5nIGlmIHlvdSB1c2UgU1RS RUFNICh3aXRoIGEgcG9zc2libGUgc3Vic2VxdWVudCBSRVNFVCkgZm9yIG1lc3NhZ2VzPyZuYnNw Ow0KIChZb3UgY2Fubm90IHVzZSBEQVRBR1JBTSBmb3IgbWVzc2FnZXMsIHNpbmNlIHlvdSB3b3Vs ZCBsaWtlIHRoZSB0cmFuc3BvcnQgdG8gZmFjaWxpdGF0ZSByZXRyYW5zbWlzc2lvbiB1bnRpbCBl eHBpcmF0aW9uLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPk15 IDwvc3Bhbj5kcmFmdC1sdWJhc2hldi1xdWljLXBhcnRpYWwtcmVsaWFiaWxpdHkgbGlzdHMgYSBm ZXcgdGhpbmdzIHRoYXQgc3RyZWFtLXBlci1tZXNzYWdlIGRvZXMgbm90IGdldCB5b3U6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KSWYgeW91IGhhdmUgbXVsdGlwbGUgYXBwbGljYXRpb24gbWVzc2FnZSBzdHJlYW1z LCB5b3Ugd291bGQgbmVlZCBhIGhlYWRlciBmb3IgZWFjaCBRVUlDIHN0cmVhbSB0byBpZGVudGlm eSB0aGUgYXBwbGljYXRpb24gc3RyZWFtLiZuYnNwOyBUaGlzIHNlZW1zIGxpa2UgYSBzbWFsbCBi dXJkZW4sIGV4Y2VwdCBmb3IgdmVyeSBzaG9ydCBtZXNzYWdlcy48bzpwPjwvbzpwPg0KPG9sIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KSWYgdGhlIG9yZGVyIG9mIG1lc3NhZ2VzIGluIGFuIGFw cGxpY2F0aW9uIHN0cmVhbSBtYXR0ZXJzLCB5b3Ugd291bGQgbmVlZCB0byByZW9yZGVyIHRoZW0g eW91cnNlbGYuJm5ic3A7IFRoaXMgY2Fubm90IGJlIHZlcnkgY29tcGxpY2F0ZWQgZm9yIHRoZSBh cHBsaWNhdGlvbi48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMiIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpRVUlDIHBlci1hcHBs aWNhdGlvbi1zdHJlYW0gZmxvdyBjb250cm9sIGlzIHJlbmRlcmVkIGluZWZmZWN0aXZlLiZuYnNw OyBJIGFtIGFjdHVhbGx5IG5vdCBhIGh1Z2UgZmFuIG9mIFFVSUMgcGVyLXN0cmVhbSBmbG93IGNv bnRyb2wsIGFzIEkgc3Ryb25nbHkgcHJlZmVyIHN0cmVhbSBwcmlvcml0aWVzIGFzIGEgc2lnbmFs LiZuYnNwOyBCdXQgSSBub3cga25vdyBvZiBhIGNhc2Ugd2hlbiBwZXItc3RyZWFtIGZsb3cgY29u dHJvbCBpcywgaW5kZWVkIHVzZWZ1bCAod2hlbg0KIHRoZXJlIGlzIG9ubHkgb25lIHNsb3cgZHJh aW5pbmcgc3RyZWFtIHRoYXQgdXNlcyB1cCB0aGUgZW50aXJlIGNvbm5lY3Rpb24gYnVmZmVyIGJl Zm9yZSBhIGhpZ2hlci1wcmlvcml0eSBzdHJlYW0gc2hvd3MgdXApLjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5BcmUgdGhlcmUgYW55IG90aGVyIGJlbmVmaXRzIHlv dSBzZWUgaW4gcGFydGlhbGx5IHJlbGlhYmxlIHN0cmVhbXM/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KSWdvcjxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEpvaG4gV2Fzb24gJmx0O2pvaG53 YXNvbjFAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDMw LCAyMDE5IDU6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFFVSUMgZm9yIHJvYm90aWNzIGFuZCBvdGhl ciB0aW1lLXNlbnNpdGl2ZSBhcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cD5UaGFua3MgVGVkLCB0aGlzIGxvb2tzIHZlcnkgaW50ZXJlc3RpbmcuIEJhc2VkIG9uIHRoZXNl IGRvY3VtZW50cyB0aGUgREVUTkVUIHNpdHMgYmVsb3cgdGhlIGxldmVsIG9mIFFVSUMgdGhhdCB3 ZSBhcmUgY3VycmVudGx5IGRpc2N1c3NpbmcgYW5kIHdvdWxkIG1haW5seSBhZmZlY3QgdGhlIElQ IGhlYWRlciBmb3JtYXQgb2YgdGhlIHJlc3VsdGluZyBVRFAgcGFja2V0cy4gVGhlIFFVSUMgcHJv dG9jb2wgd2lsbCBzdGlsbCByZXF1aXJlIHNvbWUNCiBmb3JtIG9mIHBhcnRpYWwgcmVsaWFiaWxp dHkgdG8gZnVuY3Rpb24gb24gYSBERVRORVQgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOyZuYnNwOyZuYnNwOyAtSm9obiBXYXNvbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDQvMzAvMjAxOSA1OjM3IFBNLCBUZWQgSGFyZGllIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBKb2huLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBtZXNzYWdlLiZuYnNwOyBJZiB5 b3UgaGF2ZSBub3QgYWxyZWFkeSByZXZpZXdlZCB0aGUgd29yayBvZiBERVRORVQgKDxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0 YXRyYWNrZXIuaWV0Zi5vcmdfd2dfZGV0bmV0X2Fib3V0XyZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZa YlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpV WmRuX201NUtQbWxvJmFtcDttPXVlcTNZbUY3VWFqd2dDYnRMU3BsYmhuN0lwMDV3RkJNMjBLYnVq emppaDAmYW1wO3M9eExYQ3pSeWt3WHpYN2JRX0VmQWg0UmVhMnNFemVsOXdnbnByUUF1d1B3YyZh bXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZGV0bmV0L2Fib3V0LzwvYT4p DQogaGVyZSBpbiB0aGUgSUVURiwgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIGRvIHNvLCBhcyB0aGVy ZSBhcmUgYSBudW1iZXIgb2YgZWxlbWVudHMgb2YgeW91ciB1c2UgY2FzZSB3aGljaCBhcHBlYXJl ZCB0byBiZSBzaGFyZWQgd2l0aCB0aGVpciB3b3JrLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBpdCBt aWdodCBiZSB1c2VmdWwgdG8gY29uc2lkZXIgd2hldGhlciB0aGUgaW50ZWdyYXRpb24gb2YgdGhl aXIgcHJvcG9zZWQgSVAgZGF0YSBwbGFuZSAoPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2Nf ZHJhZnQtMkRpZXRmLTJEZGV0bmV0LTJEZHAtMkRzb2wtMkRpcF8tM0ZpbmNsdWRlLTVGdGV4dC0z RDEmYW1wO2Q9RHdNRGFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JR NXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT11ZXEzWW1GN1Vhandn Q2J0TFNwbGJobjdJcDA1d0ZCTTIwS2J1anpqaWgwJmFtcDtzPVRJektyLUlPNDR5akJmUGhoUHA1 bWxkejhRRU5SUUdFLTRXRDdiYmRuNWsmYW1wO2U9Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWRldG5ldC1kcC1zb2wtaXAvP2luY2x1ZGVfdGV4dD0xPC9hPikN CiB3aXRoIFFVSUMgd291bGQgYmUgdmFsdWFibGUgaW4gYWNoaWV2aW5nIHlvdXIgdGltaW5nIGdv YWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmJlc3QgcmVnYXJkLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UZWQgSGFyZGllPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEFwciAzMCwgMjAx OSBhdCAxMjoxNSBQTSBKb2huIFdhc29uICZsdDs8YSBocmVmPSJtYWlsdG86am9obndhc29uMUBn bWFpbC5jb20iPmpvaG53YXNvbjFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkdyZWV0aW5ncyBRVUlDIFdHLDxicj4NCjxicj4NClRoZSBkaXNj dXNzaW9uIG9uIElzc3VlICM5MiBvZiB3ZWJydGMtcXVpYyBzdWdnZXN0ZWQgdGhhdCBJIHBvc3Qg bXkgPGJyPg0KcmVxdWlyZW1lbnRzIHRvIHRoaXMgbGlzdC48YnI+DQo8YnI+DQpJIGFtIGEgcm9i b3RpY3MgZW5naW5lZXIgYW5kIHRoZSBkZXZlbG9wZXIgb2YgUm9ib3QgUmFjb250ZXVyLCBhIDxi cj4NCmNvbW11bmljYXRpb24gZnJhbWV3b3JrIGZvciByb2JvdGljcyBhbmQgYXV0b21hdGlvbiBz eXN0ZW1zIDxicj4NCig8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fcm9ib3RyYWNvbnRldXJfcm9ib3RyYWNvbnRl dXImYW1wO2Q9RHdNRGFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JR NXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT11ZXEzWW1GN1Vhandn Q2J0TFNwbGJobjdJcDA1d0ZCTTIwS2J1anpqaWgwJmFtcDtzPVZJekRWWGpyNjNVd0hiVDBydllD elM5MVZBWmFyeVNlV2Z0Rk5Dc0MyaEUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9n aXRodWIuY29tL3JvYm90cmFjb250ZXVyL3JvYm90cmFjb250ZXVyPC9hPikuDQogUm9ib3RpY3Mg PGJyPg0KYXBwbGljYXRpb25zIHJlcXVpcmUgZGlmZmVyZW50IGRhdGEgdHlwZXMgYW5kIFFvUyB3 aGVuIGNvbXBhcmVkIHRvIDxicj4NCmJ1c2luZXNzIG9yIHdlYiBhcHBsaWNhdGlvbnMuIFJvYm90 aWNzIGFwcGxpY2F0aW9ucyBuZWVkIHJlYWwtdGltZSA8YnI+DQpjb21tdW5pY2F0aW9uIG9mIGlz b2Nocm9ub3VzIGRhdGEsIGZvciBpbnN0YW5jZSBjb25zdGFudCB1cGRhdGVzIG9uIHRoZSA8YnI+ DQpwb3NpdGlvbiBvZiB0aGUgam9pbnRzIG9mIHRoZSByb2JvdCwgYWxvbmdzaWRlIGdlbmVyaWMg PGJyPg0Kbm9uLXRpbWUtc2Vuc2l0aXZlIGRhdGEuIEN1cnJlbnRseSBtb3N0IHJvYm90aWNzIGFw cGxpY2F0aW9ucyBhcmUgdXNpbmcgPGJyPg0KVENQIChSb2JvdCBSYWNvbnRldXIsIFJPUyosIE9Q Qy9VQSksIFVEUCAoRERTLCBST1MyLCBST1MqKSwgb3Igc29tZSBmb3JtIDxicj4NCm9mIGN1c3Rv bSBFdGhlcm5ldCBwcm90b2NvbCAoRXRoZXJuZXQvSVAsIEV0aGVyQ0FULCBQb3dlckxpbmspLiBU byBhZGQgPGJyPg0KbW9yZSBjb25mdXNpb24gdG8gdGhlIHNpdHVhdGlvbiwgdGhlcmUgaXMgdGhl IHJlY2VudCBpbnRyb2R1Y3Rpb24gb2YgPGJyPg0KSUVFRSA4MDIuMVEgVGltZSBTZW5zaXRpdmUg TmV0d29ya2luZyAoVFNOKSB3aGljaCBjbGFpbXMgdG8gYWxsb3cgVENQIDxicj4NCmFuZCBVRFAg dG8gYWNoaWV2ZSBoYXJkIHJlYWwtdGltZSBwZXJmb3JtYW5jZS48YnI+DQo8YnI+DQpXaGlsZSB0 aGVyZSBhcmUgbWFueSByb2JvdGljcyBwcm90b2NvbHMgb3V0IHRoZXJlLCBvbmx5IFJvYm90IFJh Y29udGV1ciA8YnI+DQphbmQgT1BDL1VBIGFyZSBjb21wYXRpYmxlIHdpdGggZXhpc3Rpbmcgd2Vi IGFuZCBjbG91ZCBpbmZyYXN0cnVjdHVyZS4gPGJyPg0KKFNvbWUgbGltaXRlZCBzdXBwb3J0IGZv ciBST1MvUk9TMiBoYXMgYmVjb21lIGF2YWlsYWJsZSBvbiBBV1MsIGJ1dCB0aGUgPGJyPg0KZGVz aWduIG9mIFJPUyBkb2VzIG5vdCBwbGF5IHZlcnkgd2VsbCBvdXRzaWRlIG9mIGxvY2FsIG5ldHdv cmtzLiopIFJvYm90IDxicj4NClJhY29udGV1ciBpbXBsZW1lbnRzIHdlYiBicm93c2VyIGFuZCB3 ZWIgc2VydmVyIHN1cHBvcnQgYnkgYWxsb3dpbmcgdGhlIDxicj4NCndlYnNvY2tldCBwcm90b2Nv bCB0byBiZSB1c2VkLiBDbGllbnRzIGNhbiB1c2UgYSBVUkwgdGhhdCBzcGVjaWZpZXMgdGhhdCA8 YnI+DQp0aGUgY29ubmVjdGlvbiBpcyBhIHdlYnNvY2tldCwgYW5kIGluY29taW5nIFRDUCBjb25u ZWN0aW9ucyBjYW4gZGV0ZWN0IDxicj4NCmlmIHRoZSBjb25uZWN0aW9uIGlzIHRoZSBSb2JvdCBS YWNvbnRldXIgcHJvdG9jb2wgb3IgYW4gaW5jb21pbmcgPGJyPg0Kd2Vic29ja2V0IGNvbm5lY3Rp b24uIFJvYm90IFJhY29udGV1ciBydW5uaW5nIGluc2lkZSBhbiA8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fQVNQLk5FVCZhbXA7ZD1E d01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJz a2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPXVlcTNZbUY3VWFqd2dDYnRMU3BsYmhu N0lwMDV3RkJNMjBLYnVqemppaDAmYW1wO3M9OXVjaEJkUnpjdXF0SUI2bFp1VDB3bEdvZWxGV2dJ ek1WVDRoVEJHRVZ4YyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCkFTUC5ORVQ8L2E+IHdlYiA8 YnI+DQpzZXJ2ZXIgaGFzIGJlZW4gZGVtb25zdHJhdGVkLCBhbmQgdGhlcmUgaXMgbm8gdGVjaG5p Y2FsIHJlYXNvbiB0aGF0IDxicj4NCm90aGVyIHNlcnZlciB0ZWNobm9sb2dpZXMgY2Fubm90IGFj Y2VwdCBSb2JvdCBSYWNvbnRldXIgY29ubmVjdGlvbnMgPGJyPg0KdGhyb3VnaCB3ZWJzb2NrZXRz LiAoT1BDL1VBIHVzZXMgU09BUCBmb3IgaXRzIHdlYiBiYXNlZCB0cmFuc3BvcnQsIGJ1dCA8YnI+ DQpzdXBwb3J0IGlzIHZlcnkgcG9vciBhbmQgb25seSBhdmFpbGFibGUgaW4gYSBmZXcgaW1wbGVt ZW50YXRpb25zLik8YnI+DQo8YnI+DQpUaGUgbWFpbiBpc3N1ZSBsaW1pdGluZyBSb2JvdCBSYWNv bnRldXIgZm9yIG1vcmUgZGVtYW5kaW5nIGFwcGxpY2F0aW9ucyA8YnI+DQppcyB0aGUgdXNlIG9m IFRDUCBmb3IgZGF0YSB0cmFuc3BvcnQuIFRDUCBzdWZmZXJzIGZyb20gJnF1b3Q7aGVhZC1vZi1s aW5lJnF1b3Q7IDxicj4NCmJsb2NraW5nLCB3aGljaCBtZWFucyB0aGF0IGlmIHN0YWxlIGRhdGEg ZW5jb3VudGVycyBhbiBlcnJvciBpdCBjYW4gc3RvcCA8YnI+DQpmcmVzaCBkYXRhIGZyb20gcmVh Y2hpbmcgdGhlIG90aGVyIHBlZXIuIFRoZXJlIGlzIGFsc28gdGhlIHByb2JsZW0gb2YgPGJyPg0K bGFyZ2UgbWVzc2FnZXMgYmxvY2tpbmcgdGhlIHRyYW5zbWlzc2lvbiBvZiBzbWFsbGVyLCBtb3Jl IHRpbWUgc2Vuc2l0aXZlIDxicj4NCm1lc3NhZ2VzIG9uIHRoZSBjb25uZWN0aW9uLiBRVUlDIGFw cGVhcnMgdG8gc29sdmUgbW9zdCBvZiB0aGVzZSA8YnI+DQpwcm9ibGVtcywgYW5kIHRoZSB3ZWJy dGMtcXVpYyBzdXBwb3J0IHVuZGVyIGRldmVsb3BtZW50IHByb3ZpZGVzIGEgbG90IDxicj4NCm9m IG5ldyBhbmQgaW50ZXJlc3Rpbmcgb3Bwb3J0dW5pdGllcyBmb3IgaW50ZWdyYXRpbmcgcm9ib3Rp Y3MgPGJyPg0KYXBwbGljYXRpb25zIHdpdGggd2ViIHRlY2hub2xvZ3kuIEJ5IGFkb3B0aW5nIFFV SUMsIHRoZSByZXN1bHRpbmcgPGJyPg0Kc29mdHdhcmUgd2lsbCByZW1haW4gY29tcGxldGVseSBj b21wYXRpYmxlIHdpdGggd2ViIGluZnJhc3RydWN0dXJlLjxicj4NCjxicj4NClRyYW5zbWl0dGlu ZyB0aW1lLXNlbnNpdGl2ZSBkYXRhIHJlcXVpcmVzIHRoZSBhYmlsaXR5IHRvIG11bHRpcGxleCAo YW5kIDxicj4NCnByaW9yaXRpemUpIG1lc3NhZ2VzIGFuZCBkcm9wIG1lc3NhZ2VzIGlmIHRoZSBk YXRhIGNvbnRhaW5lZCBiZWNvbWVzIDxicj4NCnN0YWxlLiBUaGUgbXVsdGlwbGV4aW5nIGlzc3Vl IGlzIHNvbHZlZCB1c2luZyB0aGUgJnF1b3Q7c3RyZWFtcyBhcyBtZXNzYWdlcyZxdW90OyA8YnI+ DQpjb25jZXB0IGluIFFVSUMsIHdpdGggYnVpbHQgaW4gcHJpb3JpdHkgaGFuZGxpbmcuIFRoaXMg ZGVzaWduIGxvb2tzIHZlcnkgPGJyPg0KcHJvbWlzaW5nLCBhbmQgY29uc2lkZXJhYmx5IHNpbXBs ZXIgdG8gdXNlIGNvbXBhcmVkIHRvIFNDVFAgc3RyZWFtcy4gVGhlIDxicj4NCmN1cnJlbnQgaXNz dWUgdGhhdCBpcyBzb21ld2hhdCBxdWVzdGlvbmFibGUgaXMgdGhlIGltcGxlbWVudGF0aW9uIG9m IDxicj4NCnBhcnRpYWwgcmVsaWFiaWxpdHkuIFRoZSBkaXNjdXNzaW9uIHJpZ2h0IG5vdyBpcyBm b2N1c2VkIG9uIERBVEFHUkFNIDxicj4NCmV4dGVuc2lvbnMgKGRyYWZ0LXBhdWx5LXF1aWMtZGF0 YWdyYW0tMDIpLCB3aGljaCBhbGxvdyBmb3IgJnF1b3Q7cmF3JnF1b3Q7IGFjY2VzcyA8YnI+DQp0 byB0aGUgc29ja2V0IHNvIHByb3RvY29scyBzdWNoIGFzIFJUUCBjYW4gdHVubmVsIHRocm91Z2gg UVVJQy4gVGhpcyA8YnI+DQpyZXF1aXJlbWVudCBpcyBxdWl0ZSBhIGJpdCBkaWZmZXJlbnQgdGhh biB3aGF0IGlzIHJlcXVpcmVkIGZvciBhbiA8YnI+DQphcHBsaWNhdGlvbiBsaWtlIFJvYm90IFJh Y29udGV1ci4gUm9ib3QgUmFjb250ZXVyIGlzIGJhc2VkIG9uIG1lc3NhZ2UgPGJyPg0KcGFzc2lu Zywgd2hlcmUgZWl0aGVyIHRoZSBlbnRpcmUgbWVzc2FnZSBpcyByZWNlaXZlZCBvciB0aGUgZW50 aXJlIDxicj4NCm1lc3NhZ2UgaXMgY2FuY2VsbGVkIGJlY2F1c2UgdGhlIGRhdGEgY29udGFpbmVk IGlzIHN0YWxlLiBUaGUgbWVzc2FnZSA8YnI+DQptYXkgYmUgY29uc2lkZXJhYmx5IGxhcmdlciB0 aGFuIE1UVSwgYW5kIHRoZSBRb1MgbWF5IGJlICZxdW90O3BhcnRpYWwsJnF1b3Q7IDxicj4NCm1l YW5pbmcgdGhhdCBhIHNldCBudW1iZXIgb2YgYXR0ZW1wdHMgbWF5IGJlIG1hZGUgdG8gcmVzZW5k LCBhbmQvb3IgPGJyPg0KdGhlcmUgaXMgYW4gZXhwaXJhdGlvbiB0aW1lIG9uIHRoZSBtZXNzYWdl LiBUaGlzIGNhcGFiaWxpdHkgaXMgZGlzY3Vzc2VkIDxicj4NCmluIGRyYWZ0LWx1YmFzaGV2LXF1 aWMtcGFydGlhbC1yZWxpYWJpbGl0eS0wMywgYW5kIGlzIHNpbWlsYXIgdG8gaG93IDxicj4NClND VFAgaGFuZGxlcyBwYXJ0aWFsIHJlbGlhYmlsaXR5LiBJZiBvbmx5IGEgcmF3IERBVEFHUkFNIGNh cGFiaWxpdHkgaXMgPGJyPg0KcHJvdmlkZWQsIHRoZW4gcGFydGlhbCByZWxpYWJpbGl0eSB3aWxs IG5lZWQgdG8gYmUgYnVpbHQgb24gdG9wIG9mIFFVSUMsIDxicj4NCmRlZmVhdGluZyB0aGUgcHVy cG9zZSBvZiB1c2luZyBRVUlDIGZvciB0aGlzIGFwcGxpY2F0aW9uLiBPdGhlciA8YnI+DQphcHBs aWNhdGlvbnMgc3VjaCBhcyBvbmxpbmUgZ2FtaW5nIGhhdmUgdmVyeSBzaW1pbGFyIHBlcmZvcm1h bmNlIDxicj4NCnJlcXVpcmVtZW50cywgc28gSSB0aGluayB0aGF0IHRoZSBwYXJ0aWFsIHJlbGlh YmlsaXR5IGNhcGFiaWxpdHkgd2lsbCBiZSA8YnI+DQppbXBvcnRhbnQgdG8gbWFueSBmdXR1cmUg dXNlcnMuPGJyPg0KPGJyPg0KVGhlIGNvbXBsZXhpdHkgYW5kIHJlcXVpcmVkIGVmZm9ydCB0byBh ZGQgdGhlIHBhcnRpYWwgcmVsaWFiaWxpdHkgPGJyPg0KY2FwYWJpbGl0eSB0byBRVUlDIGlzIGxv dywgc28gSSBob3BlIHRoYXQgdGhpcyBjYXBhYmlsaXR5IGlzIG5vdCBhYmFuZG9uZWQuPGJyPg0K PGJyPg0KUm9ib3QgUmFjb250ZXVyIGhhcyByZWNlaXZlZCBhIGdyYW50IGZyb20gdGhlIFVuaXRl ZCBTdGF0ZXMgQVJNIDxicj4NCkluc3RpdHV0ZSBhbmQgTmV3IFlvcmsgU3RhdGUgdG8gYmVnaW4g Y29tbWVyY2lhbGl6aW5nIHRoZSB0ZWNobm9sb2d5LiA8YnI+DQpUaGlzIHByb2plY3Qgd2lsbCBi ZSBkb25lIGluIHBhcnRuZXJzaGlwIHdpdGggV2Fzb24gVGVjaG5vbG9neSwgTExDLCA8YnI+DQpS ZW5zc2VsYWVyIFBvbHl0ZWNobmljIEluc3RpdHV0ZSwgU291dGh3ZXN0IFJlc2VhcmNoIEluc3Rp dHV0ZSwgYW5kIDxicj4NClVuaXRlZCBUZWNobm9sb2dpZXMgUmVzZWFyY2ggQ2VudGVyLiBUaGUg cHJvamVjdCBzdGFydHMgc29vbiwgYW5kIDxicj4NCmNvbnNpZGVyYWJsZSBkZXZlbG9wbWVudCBl ZmZvcnQgd2lsbCBiZSBpbnZlc3RlZCBpbiB0aGUgUm9ib3QgUmFjb250ZXVyIDxicj4NCnRlY2hu b2xvZ3kgc3RhcnRpbmcgZWFybHkgc3VtbWVyLiBJbnRlZ3JhdGluZyBRVUlDIGlzIG9uZSBvZiB0 aGUgdGFza3MgPGJyPg0KdGhhdCBJIGhvcGUgdG8gdW5kZXJ0YWtlIGR1cmluZyB0aGlzIHByb2pl Y3QuPGJyPg0KPGJyPg0KUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBxdWVzdGlv bnMgYWJvdXQgUm9ib3QgUmFjb250ZXVyIG9yIDxicj4NCnRoZSByZXF1aXJlbWVudHMgZm9yIFFV SUMgaW4gcm9ib3RpY3MgYXBwbGljYXRpb25zLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtSm9obiBXYXNvbjxicj4NCjxicj4NCigqIEkgYW0gYXdhcmUgdGhhdCB0aGVyZSBh cmUgc29tZSBjYXZlYXRzIHRvIGhvdyBST1MvUk9TMiBpbnRlcmFjdCB3aXRoIDxicj4NCnRoZSB3 aWRlciB3b3JsZCwgYnV0IHRoZSB0ZWNobm9sb2dpZXMgYXJlIG5vdCBidWlsdCBvbiBvciBjb21w YXRpYmxlIDxicj4NCndpdGggd2ViIHN0YW5kYXJkcyBzbyBhbiBpbiBkZXB0aCBkaXNjdXNzaW9u IGlzIG5vdCByZWxldmFudCBmb3IgdGhlIDxicj4NCmN1cnJlbnQgdG9waWMuIFJPUyBkb2VzIGhh dmUgYSBVRFAgdHJhbnNwb3J0LCBidXQgaXQgaXMgbm90IGNvbW1vbmx5IHVzZWQuKTxicj4NCjxi cj4NCi0tIDxicj4NCkpvaG4gV2Fzb24sIFBoLkQuPGJyPg0KV2Fzb24gVGVjaG5vbG9neSwgTExD PGJyPg0KMTYgU3RlcmxpbmcgTGFrZSBSZDxicj4NClR1eGVkbywgTlkgMTA5ODc8YnI+DQooNTE4 KSAyNzktNjIzNDxicj4NCjxhIGhyZWY9Im1haWx0bzp3YXNvbkB3YXNvbnRlY2guY29tIiB0YXJn ZXQ9Il9ibGFuayI+d2Fzb25Ad2Fzb250ZWNoLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5Kb2huIFdhc29uLCBQaC5ELjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldhc29uIFRl Y2hub2xvZ3ksIExMQzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjE2IFN0ZXJsaW5nIExha2UgUmQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UdXhlZG8sIE5ZIDEwOTg3PG86cD48L286cD48L3ByZT4N CjxwcmU+KDUxOCkgMjc5LTYyMzQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWls dG86d2Fzb25Ad2Fzb250ZWNoLmNvbSI+d2Fzb25Ad2Fzb250ZWNoLmNvbTwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_df610cdb89614e459f64292ca02c2041usma1exdag1mb5msgcorpak_-- From nobody Wed May 1 07:46: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 4EC591200F9 for ; Wed, 1 May 2019 07:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEWD9dTGVuRN for ; Wed, 1 May 2019 07:46:19 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 8B3BA120108 for ; Wed, 1 May 2019 07:46:19 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id v141so3175307vsc.5 for ; Wed, 01 May 2019 07:46: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; bh=ybtc/B2rHzNVSM9+05aSJ3yGDGqFBnxEpvJok365ydw=; b=eM/h3GXhQ9IhhkHghQfhWV2tvE67S3fU5oFp078EVosLtzPEjaFIEFnNoDhJf0Za2Y 6pzfaYDrqIto9NcYw3imC5XcuKNFU2Yu6MiwNqJOW9RTmbWIdG7UVq2L4ayai+TPZVrr V/0xQPIjZ32Scl52vtyiC9EEhnBlkjktIs9/vr2CQ2xOHaYBzdhZU8FLsnatVlU5dEmP 1AVYxoJM2104SKzhy9JM8uRmhSOWnTIuXcZuxy5M26v3D20OnQxhP2QCQ2bfPaFfJdrI ZLLFyOe0G3EfHFPv/yzItZydxDpXP5eiRcPPX0V+AxttG3SscoXIaL5BDifMHd/vtqsJ g5bw== 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=ybtc/B2rHzNVSM9+05aSJ3yGDGqFBnxEpvJok365ydw=; b=sO1R4z+b8QkSpRiek+mS7vqFW09hVOtVpDvRCBEOrocz8Fizj+jrBzebx86GA00fRF sqrHZ3m5Jy6Fzg7FMyPYVW1a9BiPpE1YT12BC4cmyhA5F8d0O3SKz9UgniWfWNhFzDdQ ia5sDiwSUCl4RzDwXodnI4fYoNrY42aD1aN8hpyPkPf89mqQAgP6tPEgDlDjvXlIlWzG zfzwNKp4/GFasEO/F5qx6nQto3IIEbCRKRmJ7mlFeobhR4Rf+7Dq/I3lM5qVOe+O10YX 4voX6MkIDIUkxMzc8GY3SaO97svB0e3hF0ryZ7wO+vnLXEUuB0Sm4cp9neKGo5qleVB0 IlCw== X-Gm-Message-State: APjAAAUNgM2pUI8ARXfEiUP7MYGAoB3I0wM9S5uHXlX4uvYu+WC2BQIG rmHVKsPsrX3nhcy3uFWBQLbHnx0Hy98bmHiS+u3vt6zVfi4= X-Google-Smtp-Source: APXvYqz1YsyczEJfsajt9lJuIikIa1RQ9vpNJKw49DKWJSAl73R4NxjtjLpkcQ76JktbvqGiOQQDGg8hIJurpGtZp14= X-Received: by 2002:a67:80c8:: with SMTP id b191mr38593099vsd.184.1556721978417; Wed, 01 May 2019 07:46:18 -0700 (PDT) MIME-Version: 1.0 References: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> <20190501123305.GA5964@ubuntu-dmitri> In-Reply-To: From: Marten Seemann Date: Wed, 1 May 2019 23:46:07 +0900 Message-ID: Subject: Re: Connection ID Space To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="00000000000089a6e80587d494b7" 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, 01 May 2019 14:46:21 -0000 --00000000000089a6e80587d494b7 Content-Type: text/plain; charset="UTF-8" If I remember correctly, we made all the required changes for that to the invariants. The connection ID lengths are only invariant for Long Header packets. The connection ID for Short Header packets can have any length, so a new QUIC version (or a QUIC extension) could define connection IDs in the Short Header to have lengths that are not encodable in the 0/4-18 scheme. On Wed, May 1, 2019 at 11:31 PM Martin Thomson wrote: > On Wed, May 1, 2019, at 14:33, Dmitri Tikhonov wrote: > > On Tue, Apr 30, 2019 at 08:31:47PM -0400, Martin Thomson wrote: > > > That's on the TODO list anyway, as we agreed to remove the > > > 0/4-18 restriction for the short packet header a while back. > > > > I do not recall -- when was that decided? > > It was in relation to a request for a *smaller* connection ID. Marten > might remember better than I. > > --00000000000089a6e80587d494b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I remember correctly, we made all the required changes = for that to the invariants. The connection ID lengths are only invariant fo= r Long Header packets. The connection ID for Short Header packets can have = any length, so a new QUIC version (or a QUIC extension) could define connec= tion IDs in the Short Header to have lengths that are not encodable in the = 0/4-18 scheme.

On Wed, May 1, 2019 at 11:31 PM Martin Thomson <mt@lowentropy.net> wrote:
On Wed, May 1, 2019, at 14:3= 3, Dmitri Tikhonov wrote:
> On Tue, Apr 30, 2019 at 08:31:47PM -0400, Martin Thomson wrote:
> > That's on the TODO list anyway, as we agreed to remove the > > 0/4-18 restriction for the short packet header a while back.
>
> I do not recall -- when was that decided?

It was in relation to a request for a *smaller* connection ID.=C2=A0 Marten= might remember better than I.

--00000000000089a6e80587d494b7-- From nobody Wed May 1 09:22:10 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 E08E31200D5 for ; Wed, 1 May 2019 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 3lrG5RJ61DjZ for ; Wed, 1 May 2019 09:22:06 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 111F212011A for ; Wed, 1 May 2019 09:22:06 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id b3so20483117qtc.12 for ; Wed, 01 May 2019 09:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=90f8YcfhkYOJME9fEKqizFO/dww8Xx3OfSxy/Wgq3K0=; b=D7+rECI9WqJeh7snmrMoBEZJ8EYVpS+G/T+knQ9osAsxwxM+WVQaaEcm6DRY+M0Wrc XPPEWKbZpTCYXIvULXWIEYaXqIwSik7SDYh4CG3MN0S55uAg081LrxdlnrTPe3SvJpWV hSDlvsvJSwt5+LaGJN7QeWathGx1sXfcoyK93DEeAjc/i+ZF5gTsUixaM9+jpJdImjJ8 mp5mO+fSxWHx2uIYMKjVmFZZPvn5NXD/W0aBOr0tfIcVhX3e3s94yftDCAu12IlMYdMP T3Zokygd0XwzbsqdhoCdCq33b23vHJv4so0vf3svuStMNzPz8aiVzIiWJvBOlGLwoFcE CpHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=90f8YcfhkYOJME9fEKqizFO/dww8Xx3OfSxy/Wgq3K0=; b=lrn9Nd/gSPNYshiEdJpF4yu4urq5smfDPaQbXs5FlJnhXbAjSE65A8EmAgjJ31H+S5 k7+VaOoYyLuG7iIYKNrx6kRVgaURMmJNiy2jZrRrE92L0ltG0nroSedhdnkuc63OkrGC rSzUWmqx222mAlWU5CWWE8PunFCFKOw35lu7l2PjXFsfXLy7Il8EDnRhHGqV2VFlZeYW 5rvFbre3eFcqo5YGH8NQI8bEf7SWoZjFO8XPwzrc7AiOmod6stp608vwWbkpEvkzXxsb 3fpAJGIQRmNhx4FVix/Cvo6JP6aS1TAli/YVTQ0Jun3NnGBHJnrEeechb3AWewo7HRUx v4TQ== X-Gm-Message-State: APjAAAWn0cMY6TuXJwrInGzWoAuNYxNZul7BPSRV1RFvzpWyD08DwAtl EZMhdd6XFNOHfaj3ObT45QDE10Br X-Google-Smtp-Source: APXvYqyDwUN/aogTVOHWHvGcSGXYWacdlQJlyVO+5/FC0N4NCWLEFtR4fEHEIb7dYbKDOPUR9FrV3g== X-Received: by 2002:a0c:948e:: with SMTP id j14mr29441719qvj.245.1556727724716; Wed, 01 May 2019 09:22:04 -0700 (PDT) Received: from [192.168.1.94] (ool-44c6b4b5.dyn.optonline.net. [68.198.180.181]) by smtp.googlemail.com with ESMTPSA id k4sm18935799qki.15.2019.05.01.09.22.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 09:22:03 -0700 (PDT) Subject: Re: QUIC for robotics and other time-sensitive applications To: "Lubashev, Igor" , Ted Hardie Cc: IETF QUIC WG References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> From: John Wason Message-ID: <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> Date: Wed, 1 May 2019 12:22:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------52D9ED9977456621A973D822" 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: Wed, 01 May 2019 16:22:09 -0000 This is a multi-part message in MIME format. --------------52D9ED9977456621A973D822 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Igor, It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering. If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs.     -John On 5/1/2019 10:33 AM, Lubashev, Igor wrote: > > John, > > I am happy to resurrect that draft-lubashev-quic-partial-reliability > for QUIC v2 (some people preferred version 02, which actually gets you > a bit more features at the cost of a bit more complexity). > > I would like to first understand what partially reliable streams give > you that is not available with regular streams.  I.e. what are you > missing if you use STREAM (with a possible subsequent RESET) for > messages?  (You cannot use DATAGRAM for messages, since you would like > the transport to facilitate retransmission until expiration.) > > My draft-lubashev-quic-partial-reliability lists a few things that > stream-per-message does not get you: > > 1. If you have multiple application message streams, you would need a > header for each QUIC stream to identify the application stream.  > This seems like a small burden, except for very short messages. > 1. If the order of messages in an application stream matters, you > would need to reorder them yourself.  This cannot be very > complicated for the application. > > 2. QUIC per-application-stream flow control is rendered ineffective.  > I am actually not a huge fan of QUIC per-stream flow control, as I > strongly prefer stream priorities as a signal.  But I now know of > a case when per-stream flow control is, indeed useful (when there > is only one slow draining stream that uses up the entire > connection buffer before a higher-priority stream shows up). > > Are there any other benefits you see in partially reliable streams? > > * Igor > > *From:*John Wason > *Sent:* Tuesday, April 30, 2019 5:52 PM > *To:* Ted Hardie > *Cc:* IETF QUIC WG > *Subject:* Re: QUIC for robotics and other time-sensitive applications > > Thanks Ted, this looks very interesting. Based on these documents the > DETNET sits below the level of QUIC that we are currently discussing > and would mainly affect the IP header format of the resulting UDP > packets. The QUIC protocol will still require some form of partial > reliability to function on a DETNET network. > >     -John Wason > > On 4/30/2019 5:37 PM, Ted Hardie wrote: > > Hi John, > > Thanks for the message.  If you have not already reviewed the work > of DETNET (https://datatracker.ietf.org/wg/detnet/about/ > ) > here in the IETF, it might be useful to do so, as there are a > number of elements of your use case which appeared to be shared > with their work.  In particular, it might be useful to consider > whether the integration of their proposed IP data plane > (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1 > ) > with QUIC would be valuable in achieving your timing goals. > > best regard, > > Ted Hardie > > On Tue, Apr 30, 2019 at 12:15 PM John Wason > wrote: > > Greetings QUIC WG, > > The discussion on Issue #92 of webrtc-quic suggested that I > post my > requirements to this list. > > I am a robotics engineer and the developer of Robot Raconteur, a > communication framework for robotics and automation systems > (https://github.com/robotraconteur/robotraconteur > ). > Robotics > applications require different data types and QoS when > compared to > business or web applications. Robotics applications need > real-time > communication of isochronous data, for instance constant > updates on the > position of the joints of the robot, alongside generic > non-time-sensitive data. Currently most robotics applications > are using > TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or > some form > of custom Ethernet protocol (Ethernet/IP, EtherCAT, > PowerLink). To add > more confusion to the situation, there is the recent > introduction of > IEEE 802.1Q Time Sensitive Networking (TSN) which claims to > allow TCP > and UDP to achieve hard real-time performance. > > While there are many robotics protocols out there, only Robot > Raconteur > and OPC/UA are compatible with existing web and cloud > infrastructure. > (Some limited support for ROS/ROS2 has become available on > AWS, but the > design of ROS does not play very well outside of local > networks.*) Robot > Raconteur implements web browser and web server support by > allowing the > websocket protocol to be used. Clients can use a URL that > specifies that > the connection is a websocket, and incoming TCP connections > can detect > if the connection is the Robot Raconteur protocol or an incoming > websocket connection. Robot Raconteur running inside an > ASP.NET > > web > server has been demonstrated, and there is no technical reason > that > other server technologies cannot accept Robot Raconteur > connections > through websockets. (OPC/UA uses SOAP for its web based > transport, but > support is very poor and only available in a few implementations.) > > The main issue limiting Robot Raconteur for more demanding > applications > is the use of TCP for data transport. TCP suffers from > "head-of-line" > blocking, which means that if stale data encounters an error > it can stop > fresh data from reaching the other peer. There is also the > problem of > large messages blocking the transmission of smaller, more time > sensitive > messages on the connection. QUIC appears to solve most of these > problems, and the webrtc-quic support under development > provides a lot > of new and interesting opportunities for integrating robotics > applications with web technology. By adopting QUIC, the resulting > software will remain completely compatible with web > infrastructure. > > Transmitting time-sensitive data requires the ability to > multiplex (and > prioritize) messages and drop messages if the data contained > becomes > stale. The multiplexing issue is solved using the "streams as > messages" > concept in QUIC, with built in priority handling. This design > looks very > promising, and considerably simpler to use compared to SCTP > streams. The > current issue that is somewhat questionable is the > implementation of > partial reliability. The discussion right now is focused on > DATAGRAM > extensions (draft-pauly-quic-datagram-02), which allow for > "raw" access > to the socket so protocols such as RTP can tunnel through > QUIC. This > requirement is quite a bit different than what is required for an > application like Robot Raconteur. Robot Raconteur is based on > message > passing, where either the entire message is received or the > entire > message is cancelled because the data contained is stale. The > message > may be considerably larger than MTU, and the QoS may be > "partial," > meaning that a set number of attempts may be made to resend, > and/or > there is an expiration time on the message. This capability is > discussed > in draft-lubashev-quic-partial-reliability-03, and is similar > to how > SCTP handles partial reliability. If only a raw DATAGRAM > capability is > provided, then partial reliability will need to be built on > top of QUIC, > defeating the purpose of using QUIC for this application. Other > applications such as online gaming have very similar performance > requirements, so I think that the partial reliability > capability will be > important to many future users. > > The complexity and required effort to add the partial reliability > capability to QUIC is low, so I hope that this capability is > not abandoned. > > Robot Raconteur has received a grant from the United States ARM > Institute and New York State to begin commercializing the > technology. > This project will be done in partnership with Wason > Technology, LLC, > Rensselaer Polytechnic Institute, Southwest Research > Institute, and > United Technologies Research Center. The project starts soon, and > considerable development effort will be invested in the Robot > Raconteur > technology starting early summer. Integrating QUIC is one of > the tasks > that I hope to undertake during this project. > > Please let me know if you have any questions about Robot > Raconteur or > the requirements for QUIC in robotics applications. > >      -John Wason > > (* I am aware that there are some caveats to how ROS/ROS2 > interact with > the wider world, but the technologies are not built on or > compatible > with web standards so an in depth discussion is not relevant > for the > current topic. ROS does have a UDP transport, but it is not > commonly used.) > > -- > John Wason, Ph.D. > Wason Technology, LLC > 16 Sterling Lake Rd > Tuxedo, NY 10987 > (518) 279-6234 > wason@wasontech.com > > -- > John Wason, Ph.D. > Wason Technology, LLC > 16 Sterling Lake Rd > Tuxedo, NY 10987 > (518) 279-6234 > wason@wasontech.com -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com --------------52D9ED9977456621A973D822 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Igor,

It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering.

If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs.

    -John

On 5/1/2019 10:33 AM, Lubashev, Igor wrote:

John,

 

I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity).

 

I would like to first understand what partially reliable streams give you that is not available with regular streams.  I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages?  (You cannot use DATAGRAM for messages, since you would like the transport to facilitate retransmission until expiration.)

 

My draft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you:

 

  1. If you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream.  This seems like a small burden, except for very short messages.
    1. If the order of messages in an application stream matters, you would need to reorder them yourself.  This cannot be very complicated for the application.

 

  1. QUIC per-application-stream flow control is rendered ineffective.  I am actually not a huge fan of QUIC per-stream flow control, as I strongly prefer stream priorities as a signal.  But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up).

 

Are there any other benefits you see in partially reliable streams?

 

  • Igor

 

From: John Wason <johnwason1@gmail.com>
Sent: Tuesday, April 30, 2019 5:52 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC for robotics and other time-sensitive applications

 

Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.

    -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:

Hi John,

 

Thanks for the message.  If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work.  In particular, it might be useful to consider whether the integration of their proposed IP data plane (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) with QUIC would be valuable in achieving your timing goals.

 

 

best regard,

 

Ted Hardie

 

On Tue, Apr 30, 2019 at 12:15 PM John Wason <johnwason1@gmail.com> wrote:

Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/robotraconteur/robotraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the
position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur
and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the
design of ROS does not play very well outside of local networks.*) Robot
Raconteur implements web browser and web server support by allowing the
websocket protocol to be used. Clients can use a URL that specifies that
the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications
is the use of TCP for data transport. TCP suffers from "head-of-line"
blocking, which means that if stale data encounters an error it can stop
fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive
messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and
prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages"
concept in QUIC, with built in priority handling. This design looks very
promising, and considerably simpler to use compared to SCTP streams. The
current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed
in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC,
defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be
important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur
technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

     -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with
the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--------------52D9ED9977456621A973D822-- From nobody Wed May 1 09:38: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 6FCBA12014F for ; Wed, 1 May 2019 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 S3wf0ctU8JRM for ; Wed, 1 May 2019 09:38:19 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 6B934120143 for ; Wed, 1 May 2019 09:38:19 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id r85so10673425itc.2 for ; Wed, 01 May 2019 09:38:19 -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=IRXdFJTCVgu65RWjcknzN7Smfp0fvhd0D4onF5HIxR4=; b=n1TW8Zz0tE+niPfcu9tDfmeTNWXIBKKeZjevPeo6zQlcl8ceB1dWiwt4733wnHxOz+ rUdeWL7fQ0qP3XoNyAi6nZW2/Z91lBZfF99rewTqd4fcmTyGZSpp8ASTrcaBcQXwYgz+ 5UzH4jtSNvpHhOiI/MfO06Z6wFWrvDL76ARxvzGNcw0/pDigAUY9+lU/XLIsbq26wicX CVwjssfjU73aK3AkD21073MXjjnn4MntmWYpJ37GmT71/MtHTjlJg/DFWsclHCLDB+Xf j5D53Ev5UO66TG+eb8hTwNxbn3IJi+xN8lG5Ts96HOOajXkeTJEfyB+rM60sER750D+v oUjg== 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=IRXdFJTCVgu65RWjcknzN7Smfp0fvhd0D4onF5HIxR4=; b=IQ8Mi3A4j3F9qoII5vA90wJZUDc8hTyO7KYIMGV70MoyYpCW8kGHFOZrF9aHCoNnB1 mEterQLL8y/dHjIocE2ji3GexPEZ3CHUEq+49ZiasQKRhO8o93mfg8eIjw3CfLl4zcmn rdT/bE4aodAX/FRvsB4oNqS9FxR3lU+JphUIM2FpKKIuAl9xpdrylcQjMQfsqyt0PTgP rxm5GDf3gd5LmQBuBQ9jBPbYbcWVsm410uMv62BX/5M84ffdmChqMMYDeNXYj/7h0u7f DOVBtUV1Uy4B1wSmm5uUJ6milvZ1Q7YKL+bs/cFhQyYp97rD5Z/zMFjGxEkOmT4qpl/H dv2Q== X-Gm-Message-State: APjAAAUVVTsmfzzMknb8SYPGmxMmbxItVtlZsi8PIQ1kyL+SIFQ1cN8N IITtNPeQzkbrzvHEk77HefCVSOShJIfqUoqIQWE= X-Google-Smtp-Source: APXvYqyiLuf9QW+ATmxhh6Fu2s/Ti2hMEzdtkoW3SydnC5ucE3uaNyOO64N6ayb7mPdPyEP+oRPxFg1zZwWGKNhGwj0= X-Received: by 2002:a24:9d96:: with SMTP id f144mr8170180itd.167.1556728698694; Wed, 01 May 2019 09:38:18 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 1 May 2019 09:38:17 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 1 May 2019 09:38:17 -0700 Message-ID: Subject: Re: QUIC for robotics and other time-sensitive applications To: "Lubashev, Igor" , Ted Hardie , John Wason Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000018f24d0587d6250d" 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, 01 May 2019 16:38:22 -0000 --00000000000018f24d0587d6250d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable QUIC does not prioritise streams at the transport layer, that is an implementation detail although pacing is recommended. If you bring you own application layer protocol you can decide how to schedule data across streams within the flow control constraints. You could add priorities to your application level custom API. If you layer a protocol on top of H3 you are more constrained since you must assume other implementations that won= =E2=80=99t necessarily do what you want them to do. On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com) wrote: Igor, It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering. If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs. -John On 5/1/2019 10:33 AM, Lubashev, Igor wrote: John, I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity). I would like to first understand what partially reliable streams give you that is not available with regular streams. I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages? (You cannot use DATAGRAM for messages, since you would like the transport to facilitate retransmission until expiration.) My draft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you: 1. If you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream. This se= ems like a small burden, except for very short messages. 1. If the order of messages in an application stream matters, you would need to reorder them yourself. This cannot be very complicated= for the application. 1. QUIC per-application-stream flow control is rendered ineffective. I am actually not a huge fan of QUIC per-stream flow control, as I strongl= y prefer stream priorities as a signal. But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up). Are there any other benefits you see in partially reliable streams? - Igor *From:* John Wason *Sent:* Tuesday, April 30, 2019 5:52 PM *To:* Ted Hardie *Cc:* IETF QUIC WG *Subject:* Re: QUIC for robotics and other time-sensitive applications Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network. -John Wason On 4/30/2019 5:37 PM, Ted Hardie wrote: Hi John, Thanks for the message. If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/ ) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work. In particular, it might be useful to consider whether the integration of their proposed IP data plane ( https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text= =3D1 ) with QUIC would be valuable in achieving your timing goals. best regard, Ted Hardie On Tue, Apr 30, 2019 at 12:15 PM John Wason wrote: Greetings QUIC WG, The discussion on Issue #92 of webrtc-quic suggested that I post my requirements to this list. I am a robotics engineer and the developer of Robot Raconteur, a communication framework for robotics and automation systems (https://github.com/robotraconteur/robotraconteur ). Robotics applications require different data types and QoS when compared to business or web applications. Robotics applications need real-time communication of isochronous data, for instance constant updates on the position of the joints of the robot, alongside generic non-time-sensitive data. Currently most robotics applications are using TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add more confusion to the situation, there is the recent introduction of IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP and UDP to achieve hard real-time performance. While there are many robotics protocols out there, only Robot Raconteur and OPC/UA are compatible with existing web and cloud infrastructure. (Some limited support for ROS/ROS2 has become available on AWS, but the design of ROS does not play very well outside of local networks.*) Robot Raconteur implements web browser and web server support by allowing the websocket protocol to be used. Clients can use a URL that specifies that the connection is a websocket, and incoming TCP connections can detect if the connection is the Robot Raconteur protocol or an incoming websocket connection. Robot Raconteur running inside an ASP.NET web server has been demonstrated, and there is no technical reason that other server technologies cannot accept Robot Raconteur connections through websockets. (OPC/UA uses SOAP for its web based transport, but support is very poor and only available in a few implementations.) The main issue limiting Robot Raconteur for more demanding applications is the use of TCP for data transport. TCP suffers from "head-of-line" blocking, which means that if stale data encounters an error it can stop fresh data from reaching the other peer. There is also the problem of large messages blocking the transmission of smaller, more time sensitive messages on the connection. QUIC appears to solve most of these problems, and the webrtc-quic support under development provides a lot of new and interesting opportunities for integrating robotics applications with web technology. By adopting QUIC, the resulting software will remain completely compatible with web infrastructure. Transmitting time-sensitive data requires the ability to multiplex (and prioritize) messages and drop messages if the data contained becomes stale. The multiplexing issue is solved using the "streams as messages" concept in QUIC, with built in priority handling. This design looks very promising, and considerably simpler to use compared to SCTP streams. The current issue that is somewhat questionable is the implementation of partial reliability. The discussion right now is focused on DATAGRAM extensions (draft-pauly-quic-datagram-02), which allow for "raw" access to the socket so protocols such as RTP can tunnel through QUIC. This requirement is quite a bit different than what is required for an application like Robot Raconteur. Robot Raconteur is based on message passing, where either the entire message is received or the entire message is cancelled because the data contained is stale. The message may be considerably larger than MTU, and the QoS may be "partial," meaning that a set number of attempts may be made to resend, and/or there is an expiration time on the message. This capability is discussed in draft-lubashev-quic-partial-reliability-03, and is similar to how SCTP handles partial reliability. If only a raw DATAGRAM capability is provided, then partial reliability will need to be built on top of QUIC, defeating the purpose of using QUIC for this application. Other applications such as online gaming have very similar performance requirements, so I think that the partial reliability capability will be important to many future users. The complexity and required effort to add the partial reliability capability to QUIC is low, so I hope that this capability is not abandoned. Robot Raconteur has received a grant from the United States ARM Institute and New York State to begin commercializing the technology. This project will be done in partnership with Wason Technology, LLC, Rensselaer Polytechnic Institute, Southwest Research Institute, and United Technologies Research Center. The project starts soon, and considerable development effort will be invested in the Robot Raconteur technology starting early summer. Integrating QUIC is one of the tasks that I hope to undertake during this project. Please let me know if you have any questions about Robot Raconteur or the requirements for QUIC in robotics applications. -John Wason (* I am aware that there are some caveats to how ROS/ROS2 interact with the wider world, but the technologies are not built on or compatible with web standards so an in depth discussion is not relevant for the current topic. ROS does have a UDP transport, but it is not commonly used.) --=20 John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com --=20 John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234wason@wasontech.com --00000000000018f24d0587d6250d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = QUIC does not priori= tise streams at the transport layer, that is an implementation detail altho= ugh pacing is recommended. If you bring you own application layer protocol = you can decide how to schedule data across streams within the flow control = constraints. You could add priorities to your application level custom API.= If you layer a protocol on top of H3 you are more constrained since you mu= st assume other implementations that won=E2=80=99t necessarily do what you = want them to do.


On 1 May 2019 at 18.22.22, John = Wason (johnwason1@gmail.com) wr= ote:

=20 =20 =20 =20

Igor,

It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering.

If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs.

=C2=A0=C2=A0=C2=A0 -John

On 5/1/2019 10:33 AM, Lubashev, Igor wrote:
=20 =20 =20

John,

=C2=A0

I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity).

=C2=A0

I would lik= e to first understand what partially reliable streams give you that is not available with regular streams.=C2=A0 I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages?=C2=A0 (You cannot use DATAGRAM for message= s, since you would like the transport to facilitate retransmission until expiration.)

=C2=A0

My d= raft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you:

=C2=A0

  1. If you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream.=C2=A0 This seems like a small burden, excep= t for very short messages.
    1. If the order of messages in an application stream matters, you would need to reorder them yourself.=C2=A0 Thi= s cannot be very complicated for the application.

=C2=A0

  1. QUIC per-application-stream flow control is rendered ineffective.=C2=A0 I am actually not a huge fan of QUIC per-stream flow control, as I strongly prefer stream priorities as a signal.=C2=A0 But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up).

=C2=A0

Are there any other benefits you see in partially reliable streams?

=C2=A0

  • Igor

=C2=A0

Fr= om: John Wason <johnwason1@gmail.com>
Sent: Tuesday, April 30, 2019 5:52 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC for robotics and other time-sensitive applications

=C2=A0

Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.

=C2=A0=C2=A0=C2=A0 -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:<= /p>

Hi John,

=C2=A0

Thanks for the message.=C2=A0 If= you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work.=C2=A0 In particular, it might be useful to consider whether the integration of their proposed IP data plane (https://datatrac= ker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=3D1) with QUIC would be valuable in achieving your timing goals.

=C2=A0

=C2=A0

best regard,

=C2=A0

Ted Hardie

=C2=A0

On Tue, Apr 30, 2019 at 12:15 PM John Wason <jo= hnwason1@gmail.com> wrote:

Greet= ings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/= robotraconteur/robotraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the
position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur
and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the
design of ROS does not play very well outside of local networks.*) Robot
Raconteur implements web browser and web server support by allowing the
websocket protocol to be used. Clients can use a URL that specifies that
the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications
is the use of TCP for data transport. TCP suffers from "head-of-line"
blocking, which means that if stale data encounters an error it can stop
fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive
messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and
prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages"
concept in QUIC, with built in priority handling. This design looks very
promising, and considerably simpler to use compared to SCTP streams. The
current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed
in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC,
defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be
important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur
technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

=C2=A0=C2=A0=C2=A0=C2=A0 -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with
the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
= wason@wasontech.com

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
-- =20
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
w=
ason@wasontech.com
=20
--00000000000018f24d0587d6250d-- From nobody Wed May 1 10:33: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 C11E61200A2 for ; Wed, 1 May 2019 10:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 lPcPLJScJ4IY for ; Wed, 1 May 2019 10:33:29 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 D4D311200B6 for ; Wed, 1 May 2019 10:33:28 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id a62so8828424ywa.4 for ; Wed, 01 May 2019 10:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=QTV0/M1eGqNO7iHkw1J/1MdOSv2uJi57RNi0OUngzLE=; b=sUs2F+XVVlDeY9SxpgrM74XYmJUYPM03ATN4tzYiH29tTEu9f1ouJvi1AwnP5w+0OU xHofLTl6WfOH2Kid8cHwCzMcAQXQ43ly+6f4ZXUYkzmjlPQ0Xb/WmSZrQTFQlNyR/sDb sEAhHl/ueKiH9CW+yK6sGY1YZuTkxZcJqR9Gm7FVkYMrzuFDXAl5gKSyTz3ryL0D6uSm HfTM9zjbTKjOxdGDFYWClrDflBV53qHFimhKXmeBG3CEfASZML9HNLqvwsGC2VPrtXPH M7xZuqQjIEQ4S8edKQnyHzS5h9Ofevcf9RJQm+OvBf9fqEdpV7o4SbjMegbk7+8dIIgQ 8zOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=QTV0/M1eGqNO7iHkw1J/1MdOSv2uJi57RNi0OUngzLE=; b=Y303hxq6CZK1jnBhe4L2G736yWYVycEKTBaAXIJSFYxGM3crdw5q/LzshYXeOAGL5h qp/L7NCeHgd7llVVXxJqdlSyJjGe9HuYeHr7unOLN0JZ6a6cFFwn8Ioh8P42NehPn9cw OYWaT82bjw89fD+Qltwjgt5VXYz1wm1aWOnfCZ61HsuKhhRiMz0R4naplL3u15esdvwX /MeP2gYzCu73dDdEo5ncerX1mZhDz+eK8gwy+7UZS+HEhi++JmW/P8Ny+LFuShIGFY6A ws80gnp6kJBMnO5HErcStvbvuPIKz3XfZB5K+KiNvfbwqpyuKFskNBqLlK2rmaru+UZv ap+Q== X-Gm-Message-State: APjAAAVw1v4Fp5p3vz9NYiMvpKIUzfm64Y5eV4DyN2s6kANOVRr/rJez /Q8ragBGXtnnzparhGMgc2HH4xJC X-Google-Smtp-Source: APXvYqxhhdUJ2nQemc2gz2uZZL/uZZrwq7bjMoexlKtVDWdrqdYbdKcsx5+y+30ObU37Zyyu6rOXrA== X-Received: by 2002:a81:65d6:: with SMTP id z205mr47956445ywb.313.1556732007617; Wed, 01 May 2019 10:33:27 -0700 (PDT) Received: from [192.168.11.58] (D8FF7f43.cst.lightpath.net. [216.255.127.67]) by smtp.gmail.com with ESMTPSA id h204sm38639098ywh.110.2019.05.01.10.33.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 10:33:26 -0700 (PDT) Subject: Re: QUIC for robotics and other time-sensitive applications To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "Lubashev, Igor" , Ted Hardie Cc: IETF QUIC WG References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> From: John Wason Message-ID: <1bb52999-d020-422e-db87-733fbc7b0cae@gmail.com> Date: Wed, 1 May 2019 13:33:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AFF208F7D84D084CE1D8D71B" 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: Wed, 01 May 2019 17:33:32 -0000 This is a multi-part message in MIME format. --------------AFF208F7D84D084CE1D8D71B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mikkel, That makes sense, the order of streams sent shouldn't affect the wire protocol. For the flow control, does the protocol provide information about how much headroom is left? For instance, it may be very important that small, time sensitive streams reach their destination quickly, while there may be larger, slower streams that can wait. If the flow control is not handled correctly, the slower stream could block the fast streams by filling the available bandwidth and buffers. I am not sure what you mean by "layer on top of H3".     -John On 5/1/2019 12:38 PM, Mikkel Fahnøe Jørgensen wrote: > QUIC does not prioritise streams at the transport layer, that is an > implementation detail although pacing is recommended. If you bring you > own application layer protocol you can decide how to schedule data > across streams within the flow control constraints. You could add > priorities to your application level custom API. If you layer a > protocol on top of H3 you are more constrained since you must assume > other implementations that won’t necessarily do what you want them to do. > > > On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com > ) wrote: > >> Igor, >> >> It appears I misunderstood the distinction between per-stream partial >> reliability and intra-stream partial reliability. If I send one >> partial-reliability message per stream, using RESET frames should be >> sufficient. How this is exposed as an API is important, since I am >> not sure the webrtc-quic team has considered this yet. In response to >> your questions 1) Each message contains a header that should be >> sufficient for the receiver to understand the incoming stream 2) Does >> QUIC provide the type of priority that you suggest? My understanding >> is that QUIC multiplexes streams using a priority based ordering. >> >> If I can emulate partial-reliability using RESET frames to cancel >> entire streams, that should be sufficient for my needs. >> >>     -John >> >> On 5/1/2019 10:33 AM, Lubashev, Igor wrote: >>> >>> John, >>> >>> I am happy to resurrect that draft-lubashev-quic-partial-reliability >>> for QUIC v2 (some people preferred version 02, which actually gets >>> you a bit more features at the cost of a bit more complexity). >>> >>> I would like to first understand what partially reliable streams >>> give you that is not available with regular streams.  I.e. what are >>> you missing if you use STREAM (with a possible subsequent RESET) for >>> messages?  (You cannot use DATAGRAM for messages, since you would >>> like the transport to facilitate retransmission until expiration.) >>> >>> My draft-lubashev-quic-partial-reliability lists a few things that >>> stream-per-message does not get you: >>> >>> 1. If you have multiple application message streams, you would need >>> a header for each QUIC stream to identify the application >>> stream.  This seems like a small burden, except for very short >>> messages. >>> 1. If the order of messages in an application stream matters, >>> you would need to reorder them yourself.  This cannot be >>> very complicated for the application. >>> >>> 2. QUIC per-application-stream flow control is rendered >>> ineffective.  I am actually not a huge fan of QUIC per-stream >>> flow control, as I strongly prefer stream priorities as a >>> signal.  But I now know of a case when per-stream flow control >>> is, indeed useful (when there is only one slow draining stream >>> that uses up the entire connection buffer before a >>> higher-priority stream shows up). >>> >>> Are there any other benefits you see in partially reliable streams? >>> >>> * Igor >>> >>> *From:*John Wason >>> *Sent:* Tuesday, April 30, 2019 5:52 PM >>> *To:* Ted Hardie >>> *Cc:* IETF QUIC WG >>> *Subject:* Re: QUIC for robotics and other time-sensitive applications >>> >>> Thanks Ted, this looks very interesting. Based on these documents >>> the DETNET sits below the level of QUIC that we are currently >>> discussing and would mainly affect the IP header format of the >>> resulting UDP packets. The QUIC protocol will still require some >>> form of partial reliability to function on a DETNET network. >>> >>>     -John Wason >>> >>> On 4/30/2019 5:37 PM, Ted Hardie wrote: >>> >>> Hi John, >>> >>> Thanks for the message.  If you have not already reviewed the >>> work of DETNET (https://datatracker.ietf.org/wg/detnet/about/ >>> ) >>> here in the IETF, it might be useful to do so, as there are a >>> number of elements of your use case which appeared to be shared >>> with their work.  In particular, it might be useful to consider >>> whether the integration of their proposed IP data plane >>> (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1 >>> ) >>> with QUIC would be valuable in achieving your timing goals. >>> >>> best regard, >>> >>> Ted Hardie >>> >>> On Tue, Apr 30, 2019 at 12:15 PM John Wason >>> > wrote: >>> >>> Greetings QUIC WG, >>> >>> The discussion on Issue #92 of webrtc-quic suggested that I >>> post my >>> requirements to this list. >>> >>> I am a robotics engineer and the developer of Robot >>> Raconteur, a >>> communication framework for robotics and automation systems >>> (https://github.com/robotraconteur/robotraconteur >>> ). >>> Robotics >>> applications require different data types and QoS when >>> compared to >>> business or web applications. Robotics applications need >>> real-time >>> communication of isochronous data, for instance constant >>> updates on the >>> position of the joints of the robot, alongside generic >>> non-time-sensitive data. Currently most robotics >>> applications are using >>> TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), >>> or some form >>> of custom Ethernet protocol (Ethernet/IP, EtherCAT, >>> PowerLink). To add >>> more confusion to the situation, there is the recent >>> introduction of >>> IEEE 802.1Q Time Sensitive Networking (TSN) which claims to >>> allow TCP >>> and UDP to achieve hard real-time performance. >>> >>> While there are many robotics protocols out there, only >>> Robot Raconteur >>> and OPC/UA are compatible with existing web and cloud >>> infrastructure. >>> (Some limited support for ROS/ROS2 has become available on >>> AWS, but the >>> design of ROS does not play very well outside of local >>> networks.*) Robot >>> Raconteur implements web browser and web server support by >>> allowing the >>> websocket protocol to be used. Clients can use a URL that >>> specifies that >>> the connection is a websocket, and incoming TCP connections >>> can detect >>> if the connection is the Robot Raconteur protocol or an >>> incoming >>> websocket connection. Robot Raconteur running inside an >>> ASP.NET >>> >>> web >>> server has been demonstrated, and there is no technical >>> reason that >>> other server technologies cannot accept Robot Raconteur >>> connections >>> through websockets. (OPC/UA uses SOAP for its web based >>> transport, but >>> support is very poor and only available in a few >>> implementations.) >>> >>> The main issue limiting Robot Raconteur for more demanding >>> applications >>> is the use of TCP for data transport. TCP suffers from >>> "head-of-line" >>> blocking, which means that if stale data encounters an error >>> it can stop >>> fresh data from reaching the other peer. There is also the >>> problem of >>> large messages blocking the transmission of smaller, more >>> time sensitive >>> messages on the connection. QUIC appears to solve most of these >>> problems, and the webrtc-quic support under development >>> provides a lot >>> of new and interesting opportunities for integrating robotics >>> applications with web technology. By adopting QUIC, the >>> resulting >>> software will remain completely compatible with web >>> infrastructure. >>> >>> Transmitting time-sensitive data requires the ability to >>> multiplex (and >>> prioritize) messages and drop messages if the data contained >>> becomes >>> stale. The multiplexing issue is solved using the "streams >>> as messages" >>> concept in QUIC, with built in priority handling. This >>> design looks very >>> promising, and considerably simpler to use compared to SCTP >>> streams. The >>> current issue that is somewhat questionable is the >>> implementation of >>> partial reliability. The discussion right now is focused on >>> DATAGRAM >>> extensions (draft-pauly-quic-datagram-02), which allow for >>> "raw" access >>> to the socket so protocols such as RTP can tunnel through >>> QUIC. This >>> requirement is quite a bit different than what is required >>> for an >>> application like Robot Raconteur. Robot Raconteur is based >>> on message >>> passing, where either the entire message is received or the >>> entire >>> message is cancelled because the data contained is stale. >>> The message >>> may be considerably larger than MTU, and the QoS may be >>> "partial," >>> meaning that a set number of attempts may be made to resend, >>> and/or >>> there is an expiration time on the message. This capability >>> is discussed >>> in draft-lubashev-quic-partial-reliability-03, and is >>> similar to how >>> SCTP handles partial reliability. If only a raw DATAGRAM >>> capability is >>> provided, then partial reliability will need to be built on >>> top of QUIC, >>> defeating the purpose of using QUIC for this application. Other >>> applications such as online gaming have very similar >>> performance >>> requirements, so I think that the partial reliability >>> capability will be >>> important to many future users. >>> >>> The complexity and required effort to add the partial >>> reliability >>> capability to QUIC is low, so I hope that this capability is >>> not abandoned. >>> >>> Robot Raconteur has received a grant from the United States ARM >>> Institute and New York State to begin commercializing the >>> technology. >>> This project will be done in partnership with Wason >>> Technology, LLC, >>> Rensselaer Polytechnic Institute, Southwest Research >>> Institute, and >>> United Technologies Research Center. The project starts >>> soon, and >>> considerable development effort will be invested in the >>> Robot Raconteur >>> technology starting early summer. Integrating QUIC is one of >>> the tasks >>> that I hope to undertake during this project. >>> >>> Please let me know if you have any questions about Robot >>> Raconteur or >>> the requirements for QUIC in robotics applications. >>> >>>      -John Wason >>> >>> (* I am aware that there are some caveats to how ROS/ROS2 >>> interact with >>> the wider world, but the technologies are not built on or >>> compatible >>> with web standards so an in depth discussion is not relevant >>> for the >>> current topic. ROS does have a UDP transport, but it is not >>> commonly used.) >>> >>> -- >>> John Wason, Ph.D. >>> Wason Technology, LLC >>> 16 Sterling Lake Rd >>> Tuxedo, NY 10987 >>> (518) 279-6234 >>> wason@wasontech.com >>> >>> -- >>> John Wason, Ph.D. >>> Wason Technology, LLC >>> 16 Sterling Lake Rd >>> Tuxedo, NY 10987 >>> (518) 279-6234 >>> wason@wasontech.com >> -- >> John Wason, Ph.D. >> Wason Technology, LLC >> 16 Sterling Lake Rd >> Tuxedo, NY 10987 >> (518) 279-6234 >> wason@wasontech.com -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com --------------AFF208F7D84D084CE1D8D71B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Mikkel,

That makes sense, the order of streams sent shouldn't affect the wire protocol. For the flow control, does the protocol provide information about how much headroom is left? For instance, it may be very important that small, time sensitive streams reach their destination quickly, while there may be larger, slower streams that can wait. If the flow control is not handled correctly, the slower stream could block the fast streams by filling the available bandwidth and buffers.

I am not sure what you mean by "layer on top of H3".

    -John

On 5/1/2019 12:38 PM, Mikkel Fahnøe Jørgensen wrote:
QUIC does not prioritise streams at the transport layer, that is an implementation detail although pacing is recommended. If you bring you own application layer protocol you can decide how to schedule data across streams within the flow control constraints. You could add priorities to your application level custom API. If you layer a protocol on top of H3 you are more constrained since you must assume other implementations that won’t necessarily do what you want them to do.


On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com) wrote:

Igor,

It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering.

If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs.

    -John

On 5/1/2019 10:33 AM, Lubashev, Igor wrote:

John,

 

I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity).

 

I would like to first understand what partially reliable streams give you that is not available with regular streams.  I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages?  (You cannot use DATAGRAM for messages, since you would like the transport to facilitate retransmission until expiration.)

 

My draft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you:

 

  1. If you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream.  This seems like a small burden, except for very short messages.
    1. If the order of messages in an application stream matters, you would need to reorder them yourself.  This cannot be very complicated for the application.

 

  1. QUIC per-application-stream flow control is rendered ineffective.  I am actually not a huge fan of QUIC per-stream flow control, as I strongly prefer stream priorities as a signal.  But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up).

 

Are there any other benefits you see in partially reliable streams?

 

  • Igor

 

From: John Wason <johnwason1@gmail.com>
Sent: Tuesday, April 30, 2019 5:52 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC for robotics and other time-sensitive applications

 

Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.

    -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:

Hi John,

 

Thanks for the message.  If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work.  In particular, it might be useful to consider whether the integration of their proposed IP data plane (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) with QUIC would be valuable in achieving your timing goals.

 

 

best regard,

 

Ted Hardie

 

On Tue, Apr 30, 2019 at 12:15 PM John Wason <johnwason1@gmail.com> wrote:

Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/robotraconteur/robotraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the
position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur
and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the
design of ROS does not play very well outside of local networks.*) Robot
Raconteur implements web browser and web server support by allowing the
websocket protocol to be used. Clients can use a URL that specifies that
the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications
is the use of TCP for data transport. TCP suffers from "head-of-line"
blocking, which means that if stale data encounters an error it can stop
fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive
messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and
prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages"
concept in QUIC, with built in priority handling. This design looks very
promising, and considerably simpler to use compared to SCTP streams. The
current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed
in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC,
defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be
important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur
technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

     -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with
the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--  
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--------------AFF208F7D84D084CE1D8D71B-- From nobody Wed May 1 10:39: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 8F3F21200A2 for ; Wed, 1 May 2019 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 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, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 px6MGEVbu0ye for ; Wed, 1 May 2019 10:39:08 -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 B55EB1200B6 for ; Wed, 1 May 2019 10:39:07 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x41HWBPg023509; Wed, 1 May 2019 18:39:06 +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=3ZWmgKEAaJWykyXQxfFgE5Vg04jAcT3502uMUVwSn5U=; b=ixk+GxZz28fkGtjVS+Dc7izNou5sjrr3sVZT1AcYiAAVsV+ThzD5/8ipDcAYC4isYbpG wR0IHAgvq3hQuY3g2bpnmBRRGKrQhwysuAUiXW7JMLBgoPXCsNfsEMVLICNMnbDCpAq2 4Eo5wCx9a8TRQaGjsx5lS/5e111R822hd+sL11YBXskjotULJrR0Isnfrwcgobwn8zi2 EsMv7EeZ55IaLYFI3zqLNlPyEuUEKavFcy2XWtaVP1SV7uV9ZxpE1dh52BVw7jUVbh+t ldcBgAv/Ho+VQUSuDCeHlyfdttetEInItgV0CL8JUMOk4SnC2zCC8ZEUtwnGsrExILLj mg== 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 2s6gsbxkru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 May 2019 18:39:06 +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 x41HWCxw010000; Wed, 1 May 2019 13:39:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 2s4jdvhgtk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 May 2019 13:39:00 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 13:33:09 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 1 May 2019 13:33:08 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1473.003; Wed, 1 May 2019 13:33:08 -0400 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Ted Hardie , John Wason CC: IETF QUIC WG Subject: RE: QUIC for robotics and other time-sensitive applications Thread-Topic: QUIC for robotics and other time-sensitive applications Thread-Index: AQHU/4kFmHgV+zSU3UK4cEKX71ffXaZVfeQAgAAD3YCAAM7+UIAAZ0EAgAAEioD//8f0EA== Date: Wed, 1 May 2019 17:33:08 +0000 Message-ID: References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.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.42] Content-Type: multipart/alternative; boundary="_000_fc0a9e35393a435a9b6f5662aef866e2usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-01_08:, , 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-1905010109 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-01_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905010109 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, 01 May 2019 17:39:10 -0000 --_000_fc0a9e35393a435a9b6f5662aef866e2usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFFVSUMgbGlicmFyeSBBUEkgbWF5IGluY2x1ZGUgYSBmYWNpbGl0eSB0byBzZXQvdXBkYXRl IHN0cmVhbSBwcmlvcml0aWVzIGZvciB0aGUgc2VuZGVyIG9mIGRhdGEuICBXZWJydGMtcXVpYyBt YXkgaW5jbHVkZSB0aGUgc2FtZSB3L28gYW55IGNoYW5nZSB0byB0aGUgdW5kZXJseWluZyBRVUlD IHByb3RvY29sLg0KDQpIb3dldmVyLCBpZiBhIHJlcXVlc3QgZm9yIGEgcHJpb3JpdHkgY2hhbmdl IG9mIGEgc3RyZWFtIGlzIG9yaWdpbmF0aW5nIGZyb20gdGhlIHJlY2VpdmVyIG9mIHRoZSBkYXRh LCBRVUlDIHRyYW5zcG9ydCBoYXMgbm8gZmFjaWxpdHkgdG8gcmVsYXkgdGhpcyBpbmZvcm1hdGlv biB0byB0aGUgc2VuZGVyLiAgQW4gYXBwbGljYXRpb24gcHJvdG9jb2wgd291bGQgbmVlZCB0byBo YW5kbGUgdGhpcy4gIEkgdGhpbmsgaXQgaXMgYSB1c2VmdWwgZXh0ZW5zaW9uIGZvciBRVUlDIHYy IHRvIHB1c2ggc3RyZWFtIHByaW9yaXR5IHRvIHRoZSB0cmFuc3BvcnQsIHNpbmNlIHRoZSB0cmFu c3BvcnQgY2FuIG1hbmFnZSB0aGlzIGNvbnRyb2wgc2lnbmFsIG1vcmUgZWZmaWNpZW50bHkuDQoN CkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NClNl bnQ6IFdlZG5lc2RheSwgTWF5IDAxLCAyMDE5IDEyOjM4IFBNDQpUbzogTHViYXNoZXYsIElnb3Ig PGlsdWJhc2hlQGFrYW1haS5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBK b2huIFdhc29uIDxqb2hud2Fzb24xQGdtYWlsLmNvbT4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUVVJQyBmb3Igcm9ib3RpY3MgYW5kIG90aGVyIHRpbWUt c2Vuc2l0aXZlIGFwcGxpY2F0aW9ucw0KDQpRVUlDIGRvZXMgbm90IHByaW9yaXRpc2Ugc3RyZWFt cyBhdCB0aGUgdHJhbnNwb3J0IGxheWVyLCB0aGF0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFp bCBhbHRob3VnaCBwYWNpbmcgaXMgcmVjb21tZW5kZWQuIElmIHlvdSBicmluZyB5b3Ugb3duIGFw cGxpY2F0aW9uIGxheWVyIHByb3RvY29sIHlvdSBjYW4gZGVjaWRlIGhvdyB0byBzY2hlZHVsZSBk YXRhIGFjcm9zcyBzdHJlYW1zIHdpdGhpbiB0aGUgZmxvdyBjb250cm9sIGNvbnN0cmFpbnRzLiBZ b3UgY291bGQgYWRkIHByaW9yaXRpZXMgdG8geW91ciBhcHBsaWNhdGlvbiBsZXZlbCBjdXN0b20g QVBJLiBJZiB5b3UgbGF5ZXIgYSBwcm90b2NvbCBvbiB0b3Agb2YgSDMgeW91IGFyZSBtb3JlIGNv bnN0cmFpbmVkIHNpbmNlIHlvdSBtdXN0IGFzc3VtZSBvdGhlciBpbXBsZW1lbnRhdGlvbnMgdGhh dCB3b27igJl0IG5lY2Vzc2FyaWx5IGRvIHdoYXQgeW91IHdhbnQgdGhlbSB0byBkby4NCg0KDQoN Ck9uIDEgTWF5IDIwMTkgYXQgMTguMjIuMjIsIEpvaG4gV2Fzb24gKGpvaG53YXNvbjFAZ21haWwu Y29tPG1haWx0bzpqb2hud2Fzb24xQGdtYWlsLmNvbT4pIHdyb3RlOg0KDQpJZ29yLA0KDQpJdCBh cHBlYXJzIEkgbWlzdW5kZXJzdG9vZCB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwZXItc3RyZWFt IHBhcnRpYWwgcmVsaWFiaWxpdHkgYW5kIGludHJhLXN0cmVhbSBwYXJ0aWFsIHJlbGlhYmlsaXR5 LiBJZiBJIHNlbmQgb25lIHBhcnRpYWwtcmVsaWFiaWxpdHkgbWVzc2FnZSBwZXIgc3RyZWFtLCB1 c2luZyBSRVNFVCBmcmFtZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQuIEhvdyB0aGlzIGlzIGV4cG9z ZWQgYXMgYW4gQVBJIGlzIGltcG9ydGFudCwgc2luY2UgSSBhbSBub3Qgc3VyZSB0aGUgd2VicnRj LXF1aWMgdGVhbSBoYXMgY29uc2lkZXJlZCB0aGlzIHlldC4gSW4gcmVzcG9uc2UgdG8geW91ciBx dWVzdGlvbnMgMSkgRWFjaCBtZXNzYWdlIGNvbnRhaW5zIGEgaGVhZGVyIHRoYXQgc2hvdWxkIGJl IHN1ZmZpY2llbnQgZm9yIHRoZSByZWNlaXZlciB0byB1bmRlcnN0YW5kIHRoZSBpbmNvbWluZyBz dHJlYW0gMikgRG9lcyBRVUlDIHByb3ZpZGUgdGhlIHR5cGUgb2YgcHJpb3JpdHkgdGhhdCB5b3Ug c3VnZ2VzdD8gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IFFVSUMgbXVsdGlwbGV4ZXMgc3RyZWFt cyB1c2luZyBhIHByaW9yaXR5IGJhc2VkIG9yZGVyaW5nLg0KDQpJZiBJIGNhbiBlbXVsYXRlIHBh cnRpYWwtcmVsaWFiaWxpdHkgdXNpbmcgUkVTRVQgZnJhbWVzIHRvIGNhbmNlbCBlbnRpcmUgc3Ry ZWFtcywgdGhhdCBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgbXkgbmVlZHMuDQoNCiAgICAtSm9o bg0KT24gNS8xLzIwMTkgMTA6MzMgQU0sIEx1YmFzaGV2LCBJZ29yIHdyb3RlOg0KSm9obiwNCg0K SSBhbSBoYXBweSB0byByZXN1cnJlY3QgdGhhdCBkcmFmdC1sdWJhc2hldi1xdWljLXBhcnRpYWwt cmVsaWFiaWxpdHkgZm9yIFFVSUMgdjIgKHNvbWUgcGVvcGxlIHByZWZlcnJlZCB2ZXJzaW9uIDAy LCB3aGljaCBhY3R1YWxseSBnZXRzIHlvdSBhIGJpdCBtb3JlIGZlYXR1cmVzIGF0IHRoZSBjb3N0 IG9mIGEgYml0IG1vcmUgY29tcGxleGl0eSkuDQoNCkkgd291bGQgbGlrZSB0byBmaXJzdCB1bmRl cnN0YW5kIHdoYXQgcGFydGlhbGx5IHJlbGlhYmxlIHN0cmVhbXMgZ2l2ZSB5b3UgdGhhdCBpcyBu b3QgYXZhaWxhYmxlIHdpdGggcmVndWxhciBzdHJlYW1zLiAgSS5lLiB3aGF0IGFyZSB5b3UgbWlz c2luZyBpZiB5b3UgdXNlIFNUUkVBTSAod2l0aCBhIHBvc3NpYmxlIHN1YnNlcXVlbnQgUkVTRVQp IGZvciBtZXNzYWdlcz8gIChZb3UgY2Fubm90IHVzZSBEQVRBR1JBTSBmb3IgbWVzc2FnZXMsIHNp bmNlIHlvdSB3b3VsZCBsaWtlIHRoZSB0cmFuc3BvcnQgdG8gZmFjaWxpdGF0ZSByZXRyYW5zbWlz c2lvbiB1bnRpbCBleHBpcmF0aW9uLikNCg0KTXkgZHJhZnQtbHViYXNoZXYtcXVpYy1wYXJ0aWFs LXJlbGlhYmlsaXR5IGxpc3RzIGEgZmV3IHRoaW5ncyB0aGF0IHN0cmVhbS1wZXItbWVzc2FnZSBk b2VzIG5vdCBnZXQgeW91Og0KDQoNCiAgMS4gIElmIHlvdSBoYXZlIG11bHRpcGxlIGFwcGxpY2F0 aW9uIG1lc3NhZ2Ugc3RyZWFtcywgeW91IHdvdWxkIG5lZWQgYSBoZWFkZXIgZm9yIGVhY2ggUVVJ QyBzdHJlYW0gdG8gaWRlbnRpZnkgdGhlIGFwcGxpY2F0aW9uIHN0cmVhbS4gIFRoaXMgc2VlbXMg bGlrZSBhIHNtYWxsIGJ1cmRlbiwgZXhjZXB0IGZvciB2ZXJ5IHNob3J0IG1lc3NhZ2VzLg0KDQog ICAgICogICBJZiB0aGUgb3JkZXIgb2YgbWVzc2FnZXMgaW4gYW4gYXBwbGljYXRpb24gc3RyZWFt IG1hdHRlcnMsIHlvdSB3b3VsZCBuZWVkIHRvIHJlb3JkZXIgdGhlbSB5b3Vyc2VsZi4gIFRoaXMg Y2Fubm90IGJlIHZlcnkgY29tcGxpY2F0ZWQgZm9yIHRoZSBhcHBsaWNhdGlvbi4NCg0KDQogIDEu ICBRVUlDIHBlci1hcHBsaWNhdGlvbi1zdHJlYW0gZmxvdyBjb250cm9sIGlzIHJlbmRlcmVkIGlu ZWZmZWN0aXZlLiAgSSBhbSBhY3R1YWxseSBub3QgYSBodWdlIGZhbiBvZiBRVUlDIHBlci1zdHJl YW0gZmxvdyBjb250cm9sLCBhcyBJIHN0cm9uZ2x5IHByZWZlciBzdHJlYW0gcHJpb3JpdGllcyBh cyBhIHNpZ25hbC4gIEJ1dCBJIG5vdyBrbm93IG9mIGEgY2FzZSB3aGVuIHBlci1zdHJlYW0gZmxv dyBjb250cm9sIGlzLCBpbmRlZWQgdXNlZnVsICh3aGVuIHRoZXJlIGlzIG9ubHkgb25lIHNsb3cg ZHJhaW5pbmcgc3RyZWFtIHRoYXQgdXNlcyB1cCB0aGUgZW50aXJlIGNvbm5lY3Rpb24gYnVmZmVy IGJlZm9yZSBhIGhpZ2hlci1wcmlvcml0eSBzdHJlYW0gc2hvd3MgdXApLg0KDQpBcmUgdGhlcmUg YW55IG90aGVyIGJlbmVmaXRzIHlvdSBzZWUgaW4gcGFydGlhbGx5IHJlbGlhYmxlIHN0cmVhbXM/ DQoNCg0KICAqICAgSWdvcg0KDQpGcm9tOiBKb2huIFdhc29uIDxqb2hud2Fzb24xQGdtYWlsLmNv bT48bWFpbHRvOmpvaG53YXNvbjFAZ21haWwuY29tPg0KU2VudDogVHVlc2RheSwgQXByaWwgMzAs IDIwMTkgNTo1MiBQTQ0KVG86IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT48bWFpbHRv OnRlZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+PG1h aWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFFVSUMgZm9yIHJvYm90aWNzIGFuZCBv dGhlciB0aW1lLXNlbnNpdGl2ZSBhcHBsaWNhdGlvbnMNCg0KDQpUaGFua3MgVGVkLCB0aGlzIGxv b2tzIHZlcnkgaW50ZXJlc3RpbmcuIEJhc2VkIG9uIHRoZXNlIGRvY3VtZW50cyB0aGUgREVUTkVU IHNpdHMgYmVsb3cgdGhlIGxldmVsIG9mIFFVSUMgdGhhdCB3ZSBhcmUgY3VycmVudGx5IGRpc2N1 c3NpbmcgYW5kIHdvdWxkIG1haW5seSBhZmZlY3QgdGhlIElQIGhlYWRlciBmb3JtYXQgb2YgdGhl IHJlc3VsdGluZyBVRFAgcGFja2V0cy4gVGhlIFFVSUMgcHJvdG9jb2wgd2lsbCBzdGlsbCByZXF1 aXJlIHNvbWUgZm9ybSBvZiBwYXJ0aWFsIHJlbGlhYmlsaXR5IHRvIGZ1bmN0aW9uIG9uIGEgREVU TkVUIG5ldHdvcmsuDQoNCiAgICAtSm9obiBXYXNvbg0KT24gNC8zMC8yMDE5IDU6MzcgUE0sIFRl ZCBIYXJkaWUgd3JvdGU6DQpIaSBKb2huLA0KDQpUaGFua3MgZm9yIHRoZSBtZXNzYWdlLiAgSWYg eW91IGhhdmUgbm90IGFscmVhZHkgcmV2aWV3ZWQgdGhlIHdvcmsgb2YgREVUTkVUIChodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RldG5ldC9hYm91dC88aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ193 Z19kZXRuZXRfYWJvdXRfJmQ9RHdNRGFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNi UTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT11ZXEzWW1GN1VhandnQ2J0 TFNwbGJobjdJcDA1d0ZCTTIwS2J1anpqaWgwJnM9eExYQ3pSeWt3WHpYN2JRX0VmQWg0UmVhMnNF emVsOXdnbnByUUF1d1B3YyZlPT4pIGhlcmUgaW4gdGhlIElFVEYsIGl0IG1pZ2h0IGJlIHVzZWZ1 bCB0byBkbyBzbywgYXMgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIGVsZW1lbnRzIG9mIHlvdXIgdXNl IGNhc2Ugd2hpY2ggYXBwZWFyZWQgdG8gYmUgc2hhcmVkIHdpdGggdGhlaXIgd29yay4gIEluIHBh cnRpY3VsYXIsIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBjb25zaWRlciB3aGV0aGVyIHRoZSBpbnRl Z3JhdGlvbiBvZiB0aGVpciBwcm9wb3NlZCBJUCBkYXRhIHBsYW5lIChodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRldG5ldC1kcC1zb2wtaXAvP2luY2x1ZGVfdGV4 dD0xPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGRldG5ldC0yRGRwLTJEc29s LTJEaXBfLTNGaW5jbHVkZS01RnRleHQtM0QxJmQ9RHdNRGFRJmM9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT11ZXEz WW1GN1VhandnQ2J0TFNwbGJobjdJcDA1d0ZCTTIwS2J1anpqaWgwJnM9VEl6S3ItSU80NHlqQmZQ aGhQcDVtbGR6OFFFTlJRR0UtNFdEN2JiZG41ayZlPT4pIHdpdGggUVVJQyB3b3VsZCBiZSB2YWx1 YWJsZSBpbiBhY2hpZXZpbmcgeW91ciB0aW1pbmcgZ29hbHMuDQoNCg0KYmVzdCByZWdhcmQsDQoN ClRlZCBIYXJkaWUNCg0KT24gVHVlLCBBcHIgMzAsIDIwMTkgYXQgMTI6MTUgUE0gSm9obiBXYXNv biA8am9obndhc29uMUBnbWFpbC5jb208bWFpbHRvOmpvaG53YXNvbjFAZ21haWwuY29tPj4gd3Jv dGU6DQpHcmVldGluZ3MgUVVJQyBXRywNCg0KVGhlIGRpc2N1c3Npb24gb24gSXNzdWUgIzkyIG9m IHdlYnJ0Yy1xdWljIHN1Z2dlc3RlZCB0aGF0IEkgcG9zdCBteQ0KcmVxdWlyZW1lbnRzIHRvIHRo aXMgbGlzdC4NCg0KSSBhbSBhIHJvYm90aWNzIGVuZ2luZWVyIGFuZCB0aGUgZGV2ZWxvcGVyIG9m IFJvYm90IFJhY29udGV1ciwgYQ0KY29tbXVuaWNhdGlvbiBmcmFtZXdvcmsgZm9yIHJvYm90aWNz IGFuZCBhdXRvbWF0aW9uIHN5c3RlbXMNCihodHRwczovL2dpdGh1Yi5jb20vcm9ib3RyYWNvbnRl dXIvcm9ib3RyYWNvbnRldXI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19naXRodWIuY29tX3JvYm90cmFjb250ZXVyX3JvYm90cmFjb250ZXVyJmQ9 RHdNRGFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8mbT11ZXEzWW1GN1VhandnQ2J0TFNwbGJobjdJcDA1d0ZCTTIw S2J1anpqaWgwJnM9Vkl6RFZYanI2M1V3SGJUMHJ2WUN6UzkxVkFaYXJ5U2VXZnRGTkNzQzJoRSZl PT4pLiBSb2JvdGljcw0KYXBwbGljYXRpb25zIHJlcXVpcmUgZGlmZmVyZW50IGRhdGEgdHlwZXMg YW5kIFFvUyB3aGVuIGNvbXBhcmVkIHRvDQpidXNpbmVzcyBvciB3ZWIgYXBwbGljYXRpb25zLiBS b2JvdGljcyBhcHBsaWNhdGlvbnMgbmVlZCByZWFsLXRpbWUNCmNvbW11bmljYXRpb24gb2YgaXNv Y2hyb25vdXMgZGF0YSwgZm9yIGluc3RhbmNlIGNvbnN0YW50IHVwZGF0ZXMgb24gdGhlDQpwb3Np dGlvbiBvZiB0aGUgam9pbnRzIG9mIHRoZSByb2JvdCwgYWxvbmdzaWRlIGdlbmVyaWMNCm5vbi10 aW1lLXNlbnNpdGl2ZSBkYXRhLiBDdXJyZW50bHkgbW9zdCByb2JvdGljcyBhcHBsaWNhdGlvbnMg YXJlIHVzaW5nDQpUQ1AgKFJvYm90IFJhY29udGV1ciwgUk9TKiwgT1BDL1VBKSwgVURQIChERFMs IFJPUzIsIFJPUyopLCBvciBzb21lIGZvcm0NCm9mIGN1c3RvbSBFdGhlcm5ldCBwcm90b2NvbCAo RXRoZXJuZXQvSVAsIEV0aGVyQ0FULCBQb3dlckxpbmspLiBUbyBhZGQNCm1vcmUgY29uZnVzaW9u IHRvIHRoZSBzaXR1YXRpb24sIHRoZXJlIGlzIHRoZSByZWNlbnQgaW50cm9kdWN0aW9uIG9mDQpJ RUVFIDgwMi4xUSBUaW1lIFNlbnNpdGl2ZSBOZXR3b3JraW5nIChUU04pIHdoaWNoIGNsYWltcyB0 byBhbGxvdyBUQ1ANCmFuZCBVRFAgdG8gYWNoaWV2ZSBoYXJkIHJlYWwtdGltZSBwZXJmb3JtYW5j ZS4NCg0KV2hpbGUgdGhlcmUgYXJlIG1hbnkgcm9ib3RpY3MgcHJvdG9jb2xzIG91dCB0aGVyZSwg b25seSBSb2JvdCBSYWNvbnRldXINCmFuZCBPUEMvVUEgYXJlIGNvbXBhdGlibGUgd2l0aCBleGlz dGluZyB3ZWIgYW5kIGNsb3VkIGluZnJhc3RydWN0dXJlLg0KKFNvbWUgbGltaXRlZCBzdXBwb3J0 IGZvciBST1MvUk9TMiBoYXMgYmVjb21lIGF2YWlsYWJsZSBvbiBBV1MsIGJ1dCB0aGUNCmRlc2ln biBvZiBST1MgZG9lcyBub3QgcGxheSB2ZXJ5IHdlbGwgb3V0c2lkZSBvZiBsb2NhbCBuZXR3b3Jr cy4qKSBSb2JvdA0KUmFjb250ZXVyIGltcGxlbWVudHMgd2ViIGJyb3dzZXIgYW5kIHdlYiBzZXJ2 ZXIgc3VwcG9ydCBieSBhbGxvd2luZyB0aGUNCndlYnNvY2tldCBwcm90b2NvbCB0byBiZSB1c2Vk LiBDbGllbnRzIGNhbiB1c2UgYSBVUkwgdGhhdCBzcGVjaWZpZXMgdGhhdA0KdGhlIGNvbm5lY3Rp b24gaXMgYSB3ZWJzb2NrZXQsIGFuZCBpbmNvbWluZyBUQ1AgY29ubmVjdGlvbnMgY2FuIGRldGVj dA0KaWYgdGhlIGNvbm5lY3Rpb24gaXMgdGhlIFJvYm90IFJhY29udGV1ciBwcm90b2NvbCBvciBh biBpbmNvbWluZw0Kd2Vic29ja2V0IGNvbm5lY3Rpb24uIFJvYm90IFJhY29udGV1ciBydW5uaW5n IGluc2lkZSBhbiBBU1AuTkVUPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX19BU1AuTkVUJmQ9RHdNRGFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZy PURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT11ZXEzWW1GN1Vh andnQ2J0TFNwbGJobjdJcDA1d0ZCTTIwS2J1anpqaWgwJnM9OXVjaEJkUnpjdXF0SUI2bFp1VDB3 bEdvZWxGV2dJek1WVDRoVEJHRVZ4YyZlPT4gd2ViDQpzZXJ2ZXIgaGFzIGJlZW4gZGVtb25zdHJh dGVkLCBhbmQgdGhlcmUgaXMgbm8gdGVjaG5pY2FsIHJlYXNvbiB0aGF0DQpvdGhlciBzZXJ2ZXIg dGVjaG5vbG9naWVzIGNhbm5vdCBhY2NlcHQgUm9ib3QgUmFjb250ZXVyIGNvbm5lY3Rpb25zDQp0 aHJvdWdoIHdlYnNvY2tldHMuIChPUEMvVUEgdXNlcyBTT0FQIGZvciBpdHMgd2ViIGJhc2VkIHRy YW5zcG9ydCwgYnV0DQpzdXBwb3J0IGlzIHZlcnkgcG9vciBhbmQgb25seSBhdmFpbGFibGUgaW4g YSBmZXcgaW1wbGVtZW50YXRpb25zLikNCg0KVGhlIG1haW4gaXNzdWUgbGltaXRpbmcgUm9ib3Qg UmFjb250ZXVyIGZvciBtb3JlIGRlbWFuZGluZyBhcHBsaWNhdGlvbnMNCmlzIHRoZSB1c2Ugb2Yg VENQIGZvciBkYXRhIHRyYW5zcG9ydC4gVENQIHN1ZmZlcnMgZnJvbSAiaGVhZC1vZi1saW5lIg0K YmxvY2tpbmcsIHdoaWNoIG1lYW5zIHRoYXQgaWYgc3RhbGUgZGF0YSBlbmNvdW50ZXJzIGFuIGVy cm9yIGl0IGNhbiBzdG9wDQpmcmVzaCBkYXRhIGZyb20gcmVhY2hpbmcgdGhlIG90aGVyIHBlZXIu IFRoZXJlIGlzIGFsc28gdGhlIHByb2JsZW0gb2YNCmxhcmdlIG1lc3NhZ2VzIGJsb2NraW5nIHRo ZSB0cmFuc21pc3Npb24gb2Ygc21hbGxlciwgbW9yZSB0aW1lIHNlbnNpdGl2ZQ0KbWVzc2FnZXMg b24gdGhlIGNvbm5lY3Rpb24uIFFVSUMgYXBwZWFycyB0byBzb2x2ZSBtb3N0IG9mIHRoZXNlDQpw cm9ibGVtcywgYW5kIHRoZSB3ZWJydGMtcXVpYyBzdXBwb3J0IHVuZGVyIGRldmVsb3BtZW50IHBy b3ZpZGVzIGEgbG90DQpvZiBuZXcgYW5kIGludGVyZXN0aW5nIG9wcG9ydHVuaXRpZXMgZm9yIGlu dGVncmF0aW5nIHJvYm90aWNzDQphcHBsaWNhdGlvbnMgd2l0aCB3ZWIgdGVjaG5vbG9neS4gQnkg YWRvcHRpbmcgUVVJQywgdGhlIHJlc3VsdGluZw0Kc29mdHdhcmUgd2lsbCByZW1haW4gY29tcGxl dGVseSBjb21wYXRpYmxlIHdpdGggd2ViIGluZnJhc3RydWN0dXJlLg0KDQpUcmFuc21pdHRpbmcg dGltZS1zZW5zaXRpdmUgZGF0YSByZXF1aXJlcyB0aGUgYWJpbGl0eSB0byBtdWx0aXBsZXggKGFu ZA0KcHJpb3JpdGl6ZSkgbWVzc2FnZXMgYW5kIGRyb3AgbWVzc2FnZXMgaWYgdGhlIGRhdGEgY29u dGFpbmVkIGJlY29tZXMNCnN0YWxlLiBUaGUgbXVsdGlwbGV4aW5nIGlzc3VlIGlzIHNvbHZlZCB1 c2luZyB0aGUgInN0cmVhbXMgYXMgbWVzc2FnZXMiDQpjb25jZXB0IGluIFFVSUMsIHdpdGggYnVp bHQgaW4gcHJpb3JpdHkgaGFuZGxpbmcuIFRoaXMgZGVzaWduIGxvb2tzIHZlcnkNCnByb21pc2lu ZywgYW5kIGNvbnNpZGVyYWJseSBzaW1wbGVyIHRvIHVzZSBjb21wYXJlZCB0byBTQ1RQIHN0cmVh bXMuIFRoZQ0KY3VycmVudCBpc3N1ZSB0aGF0IGlzIHNvbWV3aGF0IHF1ZXN0aW9uYWJsZSBpcyB0 aGUgaW1wbGVtZW50YXRpb24gb2YNCnBhcnRpYWwgcmVsaWFiaWxpdHkuIFRoZSBkaXNjdXNzaW9u IHJpZ2h0IG5vdyBpcyBmb2N1c2VkIG9uIERBVEFHUkFNDQpleHRlbnNpb25zIChkcmFmdC1wYXVs eS1xdWljLWRhdGFncmFtLTAyKSwgd2hpY2ggYWxsb3cgZm9yICJyYXciIGFjY2Vzcw0KdG8gdGhl IHNvY2tldCBzbyBwcm90b2NvbHMgc3VjaCBhcyBSVFAgY2FuIHR1bm5lbCB0aHJvdWdoIFFVSUMu IFRoaXMNCnJlcXVpcmVtZW50IGlzIHF1aXRlIGEgYml0IGRpZmZlcmVudCB0aGFuIHdoYXQgaXMg cmVxdWlyZWQgZm9yIGFuDQphcHBsaWNhdGlvbiBsaWtlIFJvYm90IFJhY29udGV1ci4gUm9ib3Qg UmFjb250ZXVyIGlzIGJhc2VkIG9uIG1lc3NhZ2UNCnBhc3NpbmcsIHdoZXJlIGVpdGhlciB0aGUg ZW50aXJlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgb3IgdGhlIGVudGlyZQ0KbWVzc2FnZSBpcyBjYW5j ZWxsZWQgYmVjYXVzZSB0aGUgZGF0YSBjb250YWluZWQgaXMgc3RhbGUuIFRoZSBtZXNzYWdlDQpt YXkgYmUgY29uc2lkZXJhYmx5IGxhcmdlciB0aGFuIE1UVSwgYW5kIHRoZSBRb1MgbWF5IGJlICJw YXJ0aWFsLCINCm1lYW5pbmcgdGhhdCBhIHNldCBudW1iZXIgb2YgYXR0ZW1wdHMgbWF5IGJlIG1h ZGUgdG8gcmVzZW5kLCBhbmQvb3INCnRoZXJlIGlzIGFuIGV4cGlyYXRpb24gdGltZSBvbiB0aGUg bWVzc2FnZS4gVGhpcyBjYXBhYmlsaXR5IGlzIGRpc2N1c3NlZA0KaW4gZHJhZnQtbHViYXNoZXYt cXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5LTAzLCBhbmQgaXMgc2ltaWxhciB0byBob3cNClNDVFAg aGFuZGxlcyBwYXJ0aWFsIHJlbGlhYmlsaXR5LiBJZiBvbmx5IGEgcmF3IERBVEFHUkFNIGNhcGFi aWxpdHkgaXMNCnByb3ZpZGVkLCB0aGVuIHBhcnRpYWwgcmVsaWFiaWxpdHkgd2lsbCBuZWVkIHRv IGJlIGJ1aWx0IG9uIHRvcCBvZiBRVUlDLA0KZGVmZWF0aW5nIHRoZSBwdXJwb3NlIG9mIHVzaW5n IFFVSUMgZm9yIHRoaXMgYXBwbGljYXRpb24uIE90aGVyDQphcHBsaWNhdGlvbnMgc3VjaCBhcyBv bmxpbmUgZ2FtaW5nIGhhdmUgdmVyeSBzaW1pbGFyIHBlcmZvcm1hbmNlDQpyZXF1aXJlbWVudHMs IHNvIEkgdGhpbmsgdGhhdCB0aGUgcGFydGlhbCByZWxpYWJpbGl0eSBjYXBhYmlsaXR5IHdpbGwg YmUNCmltcG9ydGFudCB0byBtYW55IGZ1dHVyZSB1c2Vycy4NCg0KVGhlIGNvbXBsZXhpdHkgYW5k IHJlcXVpcmVkIGVmZm9ydCB0byBhZGQgdGhlIHBhcnRpYWwgcmVsaWFiaWxpdHkNCmNhcGFiaWxp dHkgdG8gUVVJQyBpcyBsb3csIHNvIEkgaG9wZSB0aGF0IHRoaXMgY2FwYWJpbGl0eSBpcyBub3Qg YWJhbmRvbmVkLg0KDQpSb2JvdCBSYWNvbnRldXIgaGFzIHJlY2VpdmVkIGEgZ3JhbnQgZnJvbSB0 aGUgVW5pdGVkIFN0YXRlcyBBUk0NCkluc3RpdHV0ZSBhbmQgTmV3IFlvcmsgU3RhdGUgdG8gYmVn aW4gY29tbWVyY2lhbGl6aW5nIHRoZSB0ZWNobm9sb2d5Lg0KVGhpcyBwcm9qZWN0IHdpbGwgYmUg ZG9uZSBpbiBwYXJ0bmVyc2hpcCB3aXRoIFdhc29uIFRlY2hub2xvZ3ksIExMQywNClJlbnNzZWxh ZXIgUG9seXRlY2huaWMgSW5zdGl0dXRlLCBTb3V0aHdlc3QgUmVzZWFyY2ggSW5zdGl0dXRlLCBh bmQNClVuaXRlZCBUZWNobm9sb2dpZXMgUmVzZWFyY2ggQ2VudGVyLiBUaGUgcHJvamVjdCBzdGFy dHMgc29vbiwgYW5kDQpjb25zaWRlcmFibGUgZGV2ZWxvcG1lbnQgZWZmb3J0IHdpbGwgYmUgaW52 ZXN0ZWQgaW4gdGhlIFJvYm90IFJhY29udGV1cg0KdGVjaG5vbG9neSBzdGFydGluZyBlYXJseSBz dW1tZXIuIEludGVncmF0aW5nIFFVSUMgaXMgb25lIG9mIHRoZSB0YXNrcw0KdGhhdCBJIGhvcGUg dG8gdW5kZXJ0YWtlIGR1cmluZyB0aGlzIHByb2plY3QuDQoNClBsZWFzZSBsZXQgbWUga25vdyBp ZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIGFib3V0IFJvYm90IFJhY29udGV1ciBvcg0KdGhlIHJl cXVpcmVtZW50cyBmb3IgUVVJQyBpbiByb2JvdGljcyBhcHBsaWNhdGlvbnMuDQoNCiAgICAgLUpv aG4gV2Fzb24NCg0KKCogSSBhbSBhd2FyZSB0aGF0IHRoZXJlIGFyZSBzb21lIGNhdmVhdHMgdG8g aG93IFJPUy9ST1MyIGludGVyYWN0IHdpdGgNCnRoZSB3aWRlciB3b3JsZCwgYnV0IHRoZSB0ZWNo bm9sb2dpZXMgYXJlIG5vdCBidWlsdCBvbiBvciBjb21wYXRpYmxlDQp3aXRoIHdlYiBzdGFuZGFy ZHMgc28gYW4gaW4gZGVwdGggZGlzY3Vzc2lvbiBpcyBub3QgcmVsZXZhbnQgZm9yIHRoZQ0KY3Vy cmVudCB0b3BpYy4gUk9TIGRvZXMgaGF2ZSBhIFVEUCB0cmFuc3BvcnQsIGJ1dCBpdCBpcyBub3Qg Y29tbW9ubHkgdXNlZC4pDQoNCi0tDQpKb2huIFdhc29uLCBQaC5ELg0KV2Fzb24gVGVjaG5vbG9n eSwgTExDDQoxNiBTdGVybGluZyBMYWtlIFJkDQpUdXhlZG8sIE5ZIDEwOTg3DQooNTE4KSAyNzkt NjIzNA0Kd2Fzb25Ad2Fzb250ZWNoLmNvbTxtYWlsdG86d2Fzb25Ad2Fzb250ZWNoLmNvbT4NCg0K LS0NCg0KSm9obiBXYXNvbiwgUGguRC4NCg0KV2Fzb24gVGVjaG5vbG9neSwgTExDDQoNCjE2IFN0 ZXJsaW5nIExha2UgUmQNCg0KVHV4ZWRvLCBOWSAxMDk4Nw0KDQooNTE4KSAyNzktNjIzNA0KDQp3 YXNvbkB3YXNvbnRlY2guY29tPG1haWx0bzp3YXNvbkB3YXNvbnRlY2guY29tPg0KDQotLQ0KDQpK b2huIFdhc29uLCBQaC5ELg0KDQpXYXNvbiBUZWNobm9sb2d5LCBMTEMNCg0KMTYgU3Rlcmxpbmcg TGFrZSBSZA0KDQpUdXhlZG8sIE5ZIDEwOTg3DQoNCig1MTgpIDI3OS02MjM0DQoNCndhc29uQHdh c29udGVjaC5jb208bWFpbHRvOndhc29uQHdhc29udGVjaC5jb20+DQo= --_000_fc0a9e35393a435a9b6f5662aef866e2usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYu YWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjQxODc5ODExOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NTcyNjAx NjI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTEzMDA1MTkyNzsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMjk2NzY1MDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTMxMDQwMDIzNTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU5NDM3OTA2NCAtMjA2NjE2NjczMCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwzDQoJe21zby1saXN0LWlkOjE5NDcwNzg1NDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi05MDU2Njg2NDQ7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIFFVSUMgbGlicmFyeSBBUEkgbWF5IGluY2x1ZGUgYSBmYWNpbGl0 eSB0byBzZXQvdXBkYXRlIHN0cmVhbSBwcmlvcml0aWVzIGZvciB0aGUgc2VuZGVyIG9mIGRhdGEu Jm5ic3A7IFdlYnJ0Yy1xdWljIG1heSBpbmNsdWRlIHRoZSBzYW1lIHcvbyBhbnkgY2hhbmdlIHRv IHRoZSB1bmRlcmx5aW5nIFFVSUMgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhv d2V2ZXIsIGlmIGEgcmVxdWVzdCBmb3IgYSBwcmlvcml0eSBjaGFuZ2Ugb2YgYSBzdHJlYW0gaXMg b3JpZ2luYXRpbmcgZnJvbSB0aGUgcmVjZWl2ZXIgb2YgdGhlIGRhdGEsIFFVSUMgdHJhbnNwb3J0 IGhhcyBubyBmYWNpbGl0eSB0byByZWxheSB0aGlzIGluZm9ybWF0aW9uIHRvIHRoZSBzZW5kZXIu Jm5ic3A7IEFuIGFwcGxpY2F0aW9uIHByb3RvY29sIHdvdWxkIG5lZWQgdG8gaGFuZGxlIHRoaXMu Jm5ic3A7IEkgdGhpbmsgaXQNCiBpcyBhIHVzZWZ1bCBleHRlbnNpb24gZm9yIFFVSUMgdjIgdG8g cHVzaCBzdHJlYW0gcHJpb3JpdHkgdG8gdGhlIHRyYW5zcG9ydCwgc2luY2UgdGhlIHRyYW5zcG9y dCBjYW4gbWFuYWdlIHRoaXMgY29udHJvbCBzaWduYWwgbW9yZSBlZmZpY2llbnRseS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl biAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBNYXkgMDEsIDIwMTkgMTI6MzggUE08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZs dDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwu Y29tJmd0OzsgSm9obiBXYXNvbiAmbHQ7am9obndhc29uMUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBRVUlDIGZvciByb2JvdGljcyBhbmQgb3RoZXIgdGltZS1zZW5zaXRpdmUgYXBw bGljYXRpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5RVUlDIGRvZXMgbm90IHBy aW9yaXRpc2Ugc3RyZWFtcyBhdCB0aGUgdHJhbnNwb3J0IGxheWVyLCB0aGF0IGlzIGFuIGltcGxl bWVudGF0aW9uIGRldGFpbCBhbHRob3VnaCBwYWNpbmcgaXMgcmVjb21tZW5kZWQuIElmIHlvdSBi cmluZyB5b3Ugb3duIGFwcGxpY2F0aW9uIGxheWVyIHByb3RvY29sDQogeW91IGNhbiBkZWNpZGUg aG93IHRvIHNjaGVkdWxlIGRhdGEgYWNyb3NzIHN0cmVhbXMgd2l0aGluIHRoZSBmbG93IGNvbnRy b2wgY29uc3RyYWludHMuIFlvdSBjb3VsZCBhZGQgcHJpb3JpdGllcyB0byB5b3VyIGFwcGxpY2F0 aW9uIGxldmVsIGN1c3RvbSBBUEkuIElmIHlvdSBsYXllciBhIHByb3RvY29sIG9uIHRvcCBvZiBI MyB5b3UgYXJlIG1vcmUgY29uc3RyYWluZWQgc2luY2UgeW91IG11c3QgYXNzdW1lIG90aGVyIGlt cGxlbWVudGF0aW9ucw0KIHRoYXQgd29u4oCZdCBuZWNlc3NhcmlseSBkbyB3aGF0IHlvdSB3YW50 IHRoZW0gdG8gZG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMSBNYXkgMjAxOSBhdCAxOC4yMi4y MiwgSm9obiBXYXNvbiAoPGEgaHJlZj0ibWFpbHRvOmpvaG53YXNvbjFAZ21haWwuY29tIj5qb2hu d2Fzb24xQGdtYWlsLmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWdvciw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgYXBwZWFycyBJIG1pc3VuZGVyc3Rvb2QgdGhl IGRpc3RpbmN0aW9uIGJldHdlZW4gcGVyLXN0cmVhbSBwYXJ0aWFsIHJlbGlhYmlsaXR5IGFuZCBp bnRyYS1zdHJlYW0gcGFydGlhbCByZWxpYWJpbGl0eS4gSWYgSSBzZW5kIG9uZSBwYXJ0aWFsLXJl bGlhYmlsaXR5IG1lc3NhZ2UgcGVyIHN0cmVhbSwgdXNpbmcgUkVTRVQgZnJhbWVzDQogc2hvdWxk IGJlIHN1ZmZpY2llbnQuIEhvdyB0aGlzIGlzIGV4cG9zZWQgYXMgYW4gQVBJIGlzIGltcG9ydGFu dCwgc2luY2UgSSBhbSBub3Qgc3VyZSB0aGUgd2VicnRjLXF1aWMgdGVhbSBoYXMgY29uc2lkZXJl ZCB0aGlzIHlldC4gSW4gcmVzcG9uc2UgdG8geW91ciBxdWVzdGlvbnMgMSkgRWFjaCBtZXNzYWdl IGNvbnRhaW5zIGEgaGVhZGVyIHRoYXQgc2hvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIHRoZSByZWNl aXZlciB0byB1bmRlcnN0YW5kIHRoZQ0KIGluY29taW5nIHN0cmVhbSAyKSBEb2VzIFFVSUMgcHJv dmlkZSB0aGUgdHlwZSBvZiBwcmlvcml0eSB0aGF0IHlvdSBzdWdnZXN0PyBNeSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQgUVVJQyBtdWx0aXBsZXhlcyBzdHJlYW1zIHVzaW5nIGEgcHJpb3JpdHkgYmFz ZWQgb3JkZXJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PklmIEkgY2FuIGVtdWxhdGUgcGFydGlhbC1yZWxpYWJpbGl0eSB1c2luZyBSRVNFVCBmcmFtZXMg dG8gY2FuY2VsIGVudGlyZSBzdHJlYW1zLCB0aGF0IHNob3VsZCBiZSBzdWZmaWNpZW50IGZvciBt eSBuZWVkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IC1Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA1LzEvMjAxOSAxMDozMyBBTSwg THViYXNoZXYsIElnb3Igd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Kb2huLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkkgYW0gaGFwcHkgdG8gcmVzdXJyZWN0IHRoYXQgZHJhZnQtbHVi YXNoZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5IGZvciBRVUlDIHYyIChzb21lIHBlb3BsZSBw cmVmZXJyZWQgdmVyc2lvbg0KIDAyLCB3aGljaCBhY3R1YWxseSBnZXRzIHlvdSBhIGJpdCBtb3Jl IGZlYXR1cmVzIGF0IHRoZSBjb3N0IG9mIGEgYml0IG1vcmUgY29tcGxleGl0eSkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SSB3b3VsZCBsaWtlIHRvIGZpcnN0IHVuZGVyc3RhbmQgd2hhdCBwYXJ0 aWFsbHkgcmVsaWFibGUgc3RyZWFtcyBnaXZlIHlvdSB0aGF0IGlzIG5vdCBhdmFpbGFibGUgd2l0 aCByZWd1bGFyIHN0cmVhbXMuJm5ic3A7DQogSS5lLiB3aGF0IGFyZSB5b3UgbWlzc2luZyBpZiB5 b3UgdXNlIFNUUkVBTSAod2l0aCBhIHBvc3NpYmxlIHN1YnNlcXVlbnQgUkVTRVQpIGZvciBtZXNz YWdlcz8mbmJzcDsgKFlvdSBjYW5ub3QgdXNlIERBVEFHUkFNIGZvciBtZXNzYWdlcywgc2luY2Ug eW91IHdvdWxkIGxpa2UgdGhlIHRyYW5zcG9ydCB0byBmYWNpbGl0YXRlIHJldHJhbnNtaXNzaW9u IHVudGlsIGV4cGlyYXRpb24uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15IGRyYWZ0LWx1YmFz aGV2LXF1aWMtcGFydGlhbC1yZWxpYWJpbGl0eSBsaXN0cyBhIGZldyB0aGluZ3MgdGhhdCBzdHJl YW0tcGVyLW1lc3NhZ2UgZG9lcyBub3QgZ2V0IHlvdTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JZiB5b3UgaGF2ZSBtdWx0aXBsZSBhcHBsaWNhdGlvbiBtZXNzYWdlIHN0cmVhbXMsIHlv dSB3b3VsZCBuZWVkIGEgaGVhZGVyIGZvciBlYWNoIFFVSUMgc3RyZWFtIHRvIGlkZW50aWZ5IHRo ZSBhcHBsaWNhdGlvbiBzdHJlYW0uJm5ic3A7DQogVGhpcyBzZWVtcyBsaWtlIGEgc21hbGwgYnVy ZGVuLCBleGNlcHQgZm9yIHZlcnkgc2hvcnQgbWVzc2FnZXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC9vbD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9ImEi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwy IGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZiB0aGUgb3JkZXIgb2YgbWVzc2FnZXMgaW4gYW4g YXBwbGljYXRpb24gc3RyZWFtIG1hdHRlcnMsIHlvdSB3b3VsZCBuZWVkIHRvIHJlb3JkZXIgdGhl bSB5b3Vyc2VsZi4mbmJzcDsgVGhpcyBjYW5ub3QgYmUgdmVyeSBjb21wbGljYXRlZA0KIGZvciB0 aGUgYXBwbGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlFVSUMgcGVyLWFwcGxpY2F0aW9uLXN0cmVhbSBmbG93IGNvbnRyb2wgaXMgcmVuZGVyZWQgaW5l ZmZlY3RpdmUuJm5ic3A7IEkgYW0gYWN0dWFsbHkgbm90IGEgaHVnZSBmYW4gb2YgUVVJQyBwZXIt c3RyZWFtIGZsb3cgY29udHJvbCwgYXMNCiBJIHN0cm9uZ2x5IHByZWZlciBzdHJlYW0gcHJpb3Jp dGllcyBhcyBhIHNpZ25hbC4mbmJzcDsgQnV0IEkgbm93IGtub3cgb2YgYSBjYXNlIHdoZW4gcGVy LXN0cmVhbSBmbG93IGNvbnRyb2wgaXMsIGluZGVlZCB1c2VmdWwgKHdoZW4gdGhlcmUgaXMgb25s eSBvbmUgc2xvdyBkcmFpbmluZyBzdHJlYW0gdGhhdCB1c2VzIHVwIHRoZSBlbnRpcmUgY29ubmVj dGlvbiBidWZmZXIgYmVmb3JlIGEgaGlnaGVyLXByaW9yaXR5IHN0cmVhbSBzaG93cyB1cCkuPG86 cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXJlIHRoZXJlIGFueSBvdGhlciBiZW5lZml0cyB5 b3Ugc2VlIGluIHBhcnRpYWxseSByZWxpYWJsZSBzdHJlYW1zPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwzIGxldmVsMSBsZm8zIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+SWdvcjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4gSm9obiBXYXNvbg0KPGEgaHJlZj0ibWFpbHRvOmpvaG53YXNv bjFAZ21haWwuY29tIj4mbHQ7am9obndhc29uMUBnbWFpbC5jb20mZ3Q7PC9hPiA8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgQXByaWwgMzAsIDIwMTkgNTo1MiBQTTxicj4NCjxiPlRvOjwvYj4g VGVkIEhhcmRpZSA8YSBocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29tIj4mbHQ7dGVkLmll dGZAZ21haWwuY29tJmd0OzwvYT48YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyA8YSBocmVm PSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PC9hPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogUVVJQyBmb3Igcm9ib3RpY3MgYW5kIG90aGVyIHRpbWUtc2Vuc2l0 aXZlIGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIFRlZCwgdGhpcyBsb29r cyB2ZXJ5IGludGVyZXN0aW5nLiBCYXNlZCBvbiB0aGVzZSBkb2N1bWVudHMgdGhlIERFVE5FVCBz aXRzIGJlbG93IHRoZSBsZXZlbCBvZiBRVUlDIHRoYXQgd2UgYXJlIGN1cnJlbnRseSBkaXNjdXNz aW5nIGFuZCB3b3VsZCBtYWlubHkgYWZmZWN0IHRoZSBJUCBoZWFkZXIgZm9ybWF0IG9mIHRoZQ0K IHJlc3VsdGluZyBVRFAgcGFja2V0cy4gVGhlIFFVSUMgcHJvdG9jb2wgd2lsbCBzdGlsbCByZXF1 aXJlIHNvbWUgZm9ybSBvZiBwYXJ0aWFsIHJlbGlhYmlsaXR5IHRvIGZ1bmN0aW9uIG9uIGEgREVU TkVUIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyAtSm9obiBXYXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA0LzMwLzIw MTkgNTozNyBQTSwgVGVkIEhhcmRpZSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEpvaG4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzIGZvciB0aGUgbWVzc2FnZS4mbmJzcDsgSWYg eW91IGhhdmUgbm90IGFscmVhZHkgcmV2aWV3ZWQgdGhlIHdvcmsgb2YgREVUTkVUICg8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2Rh dGF0cmFja2VyLmlldGYub3JnX3dnX2RldG5ldF9hYm91dF8mYW1wO2Q9RHdNRGFRJmFtcDtjPTk2 WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlq VVpkbl9tNTVLUG1sbyZhbXA7bT11ZXEzWW1GN1VhandnQ2J0TFNwbGJobjdJcDA1d0ZCTTIwS2J1 anpqaWgwJmFtcDtzPXhMWEN6Unlrd1h6WDdiUV9FZkFoNFJlYTJzRXplbDl3Z25wclFBdXdQd2Mm YW1wO2U9Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RldG5ldC9hYm91dC88L2E+ KQ0KIGhlcmUgaW4gdGhlIElFVEYsIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBkbyBzbywgYXMgdGhl cmUgYXJlIGEgbnVtYmVyIG9mIGVsZW1lbnRzIG9mIHlvdXIgdXNlIGNhc2Ugd2hpY2ggYXBwZWFy ZWQgdG8gYmUgc2hhcmVkIHdpdGggdGhlaXIgd29yay4mbmJzcDsgSW4gcGFydGljdWxhciwgaXQg bWlnaHQgYmUgdXNlZnVsIHRvIGNvbnNpZGVyIHdoZXRoZXIgdGhlIGludGVncmF0aW9uIG9mIHRo ZWlyIHByb3Bvc2VkIElQIGRhdGEgcGxhbmUgKDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9j X2RyYWZ0LTJEaWV0Zi0yRGRldG5ldC0yRGRwLTJEc29sLTJEaXBfLTNGaW5jbHVkZS01RnRleHQt M0QxJmFtcDtkPUR3TURhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNi UTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209dWVxM1ltRjdVYWp3 Z0NidExTcGxiaG43SXAwNXdGQk0yMEtidWp6amloMCZhbXA7cz1USXpLci1JTzQ0eWpCZlBoaFBw NW1sZHo4UUVOUlFHRS00V0Q3YmJkbjVrJmFtcDtlPSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1kZXRuZXQtZHAtc29sLWlwLz9pbmNsdWRlX3RleHQ9MTwvYT4p DQogd2l0aCBRVUlDIHdvdWxkIGJlIHZhbHVhYmxlIGluIGFjaGlldmluZyB5b3VyIHRpbWluZyBn b2Fscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5iZXN0IHJlZ2FyZCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UZWQgSGFyZGllPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIFR1ZSwgQXByIDMwLCAyMDE5IGF0IDEyOjE1IFBNIEpvaG4gV2Fzb24gJmx0Ozxh IGhyZWY9Im1haWx0bzpqb2hud2Fzb24xQGdtYWlsLmNvbSI+am9obndhc29uMUBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+R3JlZXRpbmdzIFFVSUMgV0csPGJyPg0KPGJyPg0KVGhlIGRpc2N1 c3Npb24gb24gSXNzdWUgIzkyIG9mIHdlYnJ0Yy1xdWljIHN1Z2dlc3RlZCB0aGF0IEkgcG9zdCBt eSA8YnI+DQpyZXF1aXJlbWVudHMgdG8gdGhpcyBsaXN0Ljxicj4NCjxicj4NCkkgYW0gYSByb2Jv dGljcyBlbmdpbmVlciBhbmQgdGhlIGRldmVsb3BlciBvZiBSb2JvdCBSYWNvbnRldXIsIGEgPGJy Pg0KY29tbXVuaWNhdGlvbiBmcmFtZXdvcmsgZm9yIHJvYm90aWNzIGFuZCBhdXRvbWF0aW9uIHN5 c3RlbXMgPGJyPg0KKDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9yb2JvdHJhY29udGV1cl9yb2JvdHJhY29udGV1 ciZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1 dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPXVlcTNZbUY3VWFqd2dD YnRMU3BsYmhuN0lwMDV3RkJNMjBLYnVqemppaDAmYW1wO3M9Vkl6RFZYanI2M1V3SGJUMHJ2WUN6 UzkxVkFaYXJ5U2VXZnRGTkNzQzJoRSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dp dGh1Yi5jb20vcm9ib3RyYWNvbnRldXIvcm9ib3RyYWNvbnRldXI8L2E+KS4NCiBSb2JvdGljcyA8 YnI+DQphcHBsaWNhdGlvbnMgcmVxdWlyZSBkaWZmZXJlbnQgZGF0YSB0eXBlcyBhbmQgUW9TIHdo ZW4gY29tcGFyZWQgdG8gPGJyPg0KYnVzaW5lc3Mgb3Igd2ViIGFwcGxpY2F0aW9ucy4gUm9ib3Rp Y3MgYXBwbGljYXRpb25zIG5lZWQgcmVhbC10aW1lIDxicj4NCmNvbW11bmljYXRpb24gb2YgaXNv Y2hyb25vdXMgZGF0YSwgZm9yIGluc3RhbmNlIGNvbnN0YW50IHVwZGF0ZXMgb24gdGhlIDxicj4N CnBvc2l0aW9uIG9mIHRoZSBqb2ludHMgb2YgdGhlIHJvYm90LCBhbG9uZ3NpZGUgZ2VuZXJpYyA8 YnI+DQpub24tdGltZS1zZW5zaXRpdmUgZGF0YS4gQ3VycmVudGx5IG1vc3Qgcm9ib3RpY3MgYXBw bGljYXRpb25zIGFyZSB1c2luZyA8YnI+DQpUQ1AgKFJvYm90IFJhY29udGV1ciwgUk9TKiwgT1BD L1VBKSwgVURQIChERFMsIFJPUzIsIFJPUyopLCBvciBzb21lIGZvcm0gPGJyPg0Kb2YgY3VzdG9t IEV0aGVybmV0IHByb3RvY29sIChFdGhlcm5ldC9JUCwgRXRoZXJDQVQsIFBvd2VyTGluaykuIFRv IGFkZCA8YnI+DQptb3JlIGNvbmZ1c2lvbiB0byB0aGUgc2l0dWF0aW9uLCB0aGVyZSBpcyB0aGUg cmVjZW50IGludHJvZHVjdGlvbiBvZiA8YnI+DQpJRUVFIDgwMi4xUSBUaW1lIFNlbnNpdGl2ZSBO ZXR3b3JraW5nIChUU04pIHdoaWNoIGNsYWltcyB0byBhbGxvdyBUQ1AgPGJyPg0KYW5kIFVEUCB0 byBhY2hpZXZlIGhhcmQgcmVhbC10aW1lIHBlcmZvcm1hbmNlLjxicj4NCjxicj4NCldoaWxlIHRo ZXJlIGFyZSBtYW55IHJvYm90aWNzIHByb3RvY29scyBvdXQgdGhlcmUsIG9ubHkgUm9ib3QgUmFj b250ZXVyIDxicj4NCmFuZCBPUEMvVUEgYXJlIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyB3ZWIg YW5kIGNsb3VkIGluZnJhc3RydWN0dXJlLiA8YnI+DQooU29tZSBsaW1pdGVkIHN1cHBvcnQgZm9y IFJPUy9ST1MyIGhhcyBiZWNvbWUgYXZhaWxhYmxlIG9uIEFXUywgYnV0IHRoZSA8YnI+DQpkZXNp Z24gb2YgUk9TIGRvZXMgbm90IHBsYXkgdmVyeSB3ZWxsIG91dHNpZGUgb2YgbG9jYWwgbmV0d29y a3MuKikgUm9ib3QgPGJyPg0KUmFjb250ZXVyIGltcGxlbWVudHMgd2ViIGJyb3dzZXIgYW5kIHdl YiBzZXJ2ZXIgc3VwcG9ydCBieSBhbGxvd2luZyB0aGUgPGJyPg0Kd2Vic29ja2V0IHByb3RvY29s IHRvIGJlIHVzZWQuIENsaWVudHMgY2FuIHVzZSBhIFVSTCB0aGF0IHNwZWNpZmllcyB0aGF0IDxi cj4NCnRoZSBjb25uZWN0aW9uIGlzIGEgd2Vic29ja2V0LCBhbmQgaW5jb21pbmcgVENQIGNvbm5l Y3Rpb25zIGNhbiBkZXRlY3QgPGJyPg0KaWYgdGhlIGNvbm5lY3Rpb24gaXMgdGhlIFJvYm90IFJh Y29udGV1ciBwcm90b2NvbCBvciBhbiBpbmNvbWluZyA8YnI+DQp3ZWJzb2NrZXQgY29ubmVjdGlv bi4gUm9ib3QgUmFjb250ZXVyIHJ1bm5pbmcgaW5zaWRlIGFuIDxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19BU1AuTkVUJmFtcDtkPUR3 TURhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNr ZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209dWVxM1ltRjdVYWp3Z0NidExTcGxiaG43 SXAwNXdGQk0yMEtidWp6amloMCZhbXA7cz05dWNoQmRSemN1cXRJQjZsWnVUMHdsR29lbEZXZ0l6 TVZUNGhUQkdFVnhjJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KQVNQLk5FVDwvYT4gd2ViIDxi cj4NCnNlcnZlciBoYXMgYmVlbiBkZW1vbnN0cmF0ZWQsIGFuZCB0aGVyZSBpcyBubyB0ZWNobmlj YWwgcmVhc29uIHRoYXQgPGJyPg0Kb3RoZXIgc2VydmVyIHRlY2hub2xvZ2llcyBjYW5ub3QgYWNj ZXB0IFJvYm90IFJhY29udGV1ciBjb25uZWN0aW9ucyA8YnI+DQp0aHJvdWdoIHdlYnNvY2tldHMu IChPUEMvVUEgdXNlcyBTT0FQIGZvciBpdHMgd2ViIGJhc2VkIHRyYW5zcG9ydCwgYnV0IDxicj4N CnN1cHBvcnQgaXMgdmVyeSBwb29yIGFuZCBvbmx5IGF2YWlsYWJsZSBpbiBhIGZldyBpbXBsZW1l bnRhdGlvbnMuKTxicj4NCjxicj4NClRoZSBtYWluIGlzc3VlIGxpbWl0aW5nIFJvYm90IFJhY29u dGV1ciBmb3IgbW9yZSBkZW1hbmRpbmcgYXBwbGljYXRpb25zIDxicj4NCmlzIHRoZSB1c2Ugb2Yg VENQIGZvciBkYXRhIHRyYW5zcG9ydC4gVENQIHN1ZmZlcnMgZnJvbSAmcXVvdDtoZWFkLW9mLWxp bmUmcXVvdDsgPGJyPg0KYmxvY2tpbmcsIHdoaWNoIG1lYW5zIHRoYXQgaWYgc3RhbGUgZGF0YSBl bmNvdW50ZXJzIGFuIGVycm9yIGl0IGNhbiBzdG9wIDxicj4NCmZyZXNoIGRhdGEgZnJvbSByZWFj aGluZyB0aGUgb3RoZXIgcGVlci4gVGhlcmUgaXMgYWxzbyB0aGUgcHJvYmxlbSBvZiA8YnI+DQps YXJnZSBtZXNzYWdlcyBibG9ja2luZyB0aGUgdHJhbnNtaXNzaW9uIG9mIHNtYWxsZXIsIG1vcmUg dGltZSBzZW5zaXRpdmUgPGJyPg0KbWVzc2FnZXMgb24gdGhlIGNvbm5lY3Rpb24uIFFVSUMgYXBw ZWFycyB0byBzb2x2ZSBtb3N0IG9mIHRoZXNlIDxicj4NCnByb2JsZW1zLCBhbmQgdGhlIHdlYnJ0 Yy1xdWljIHN1cHBvcnQgdW5kZXIgZGV2ZWxvcG1lbnQgcHJvdmlkZXMgYSBsb3QgPGJyPg0Kb2Yg bmV3IGFuZCBpbnRlcmVzdGluZyBvcHBvcnR1bml0aWVzIGZvciBpbnRlZ3JhdGluZyByb2JvdGlj cyA8YnI+DQphcHBsaWNhdGlvbnMgd2l0aCB3ZWIgdGVjaG5vbG9neS4gQnkgYWRvcHRpbmcgUVVJ QywgdGhlIHJlc3VsdGluZyA8YnI+DQpzb2Z0d2FyZSB3aWxsIHJlbWFpbiBjb21wbGV0ZWx5IGNv bXBhdGlibGUgd2l0aCB3ZWIgaW5mcmFzdHJ1Y3R1cmUuPGJyPg0KPGJyPg0KVHJhbnNtaXR0aW5n IHRpbWUtc2Vuc2l0aXZlIGRhdGEgcmVxdWlyZXMgdGhlIGFiaWxpdHkgdG8gbXVsdGlwbGV4IChh bmQgPGJyPg0KcHJpb3JpdGl6ZSkgbWVzc2FnZXMgYW5kIGRyb3AgbWVzc2FnZXMgaWYgdGhlIGRh dGEgY29udGFpbmVkIGJlY29tZXMgPGJyPg0Kc3RhbGUuIFRoZSBtdWx0aXBsZXhpbmcgaXNzdWUg aXMgc29sdmVkIHVzaW5nIHRoZSAmcXVvdDtzdHJlYW1zIGFzIG1lc3NhZ2VzJnF1b3Q7IDxicj4N CmNvbmNlcHQgaW4gUVVJQywgd2l0aCBidWlsdCBpbiBwcmlvcml0eSBoYW5kbGluZy4gVGhpcyBk ZXNpZ24gbG9va3MgdmVyeSA8YnI+DQpwcm9taXNpbmcsIGFuZCBjb25zaWRlcmFibHkgc2ltcGxl ciB0byB1c2UgY29tcGFyZWQgdG8gU0NUUCBzdHJlYW1zLiBUaGUgPGJyPg0KY3VycmVudCBpc3N1 ZSB0aGF0IGlzIHNvbWV3aGF0IHF1ZXN0aW9uYWJsZSBpcyB0aGUgaW1wbGVtZW50YXRpb24gb2Yg PGJyPg0KcGFydGlhbCByZWxpYWJpbGl0eS4gVGhlIGRpc2N1c3Npb24gcmlnaHQgbm93IGlzIGZv Y3VzZWQgb24gREFUQUdSQU0gPGJyPg0KZXh0ZW5zaW9ucyAoZHJhZnQtcGF1bHktcXVpYy1kYXRh Z3JhbS0wMiksIHdoaWNoIGFsbG93IGZvciAmcXVvdDtyYXcmcXVvdDsgYWNjZXNzIDxicj4NCnRv IHRoZSBzb2NrZXQgc28gcHJvdG9jb2xzIHN1Y2ggYXMgUlRQIGNhbiB0dW5uZWwgdGhyb3VnaCBR VUlDLiBUaGlzIDxicj4NCnJlcXVpcmVtZW50IGlzIHF1aXRlIGEgYml0IGRpZmZlcmVudCB0aGFu IHdoYXQgaXMgcmVxdWlyZWQgZm9yIGFuIDxicj4NCmFwcGxpY2F0aW9uIGxpa2UgUm9ib3QgUmFj b250ZXVyLiBSb2JvdCBSYWNvbnRldXIgaXMgYmFzZWQgb24gbWVzc2FnZSA8YnI+DQpwYXNzaW5n LCB3aGVyZSBlaXRoZXIgdGhlIGVudGlyZSBtZXNzYWdlIGlzIHJlY2VpdmVkIG9yIHRoZSBlbnRp cmUgPGJyPg0KbWVzc2FnZSBpcyBjYW5jZWxsZWQgYmVjYXVzZSB0aGUgZGF0YSBjb250YWluZWQg aXMgc3RhbGUuIFRoZSBtZXNzYWdlIDxicj4NCm1heSBiZSBjb25zaWRlcmFibHkgbGFyZ2VyIHRo YW4gTVRVLCBhbmQgdGhlIFFvUyBtYXkgYmUgJnF1b3Q7cGFydGlhbCwmcXVvdDsgPGJyPg0KbWVh bmluZyB0aGF0IGEgc2V0IG51bWJlciBvZiBhdHRlbXB0cyBtYXkgYmUgbWFkZSB0byByZXNlbmQs IGFuZC9vciA8YnI+DQp0aGVyZSBpcyBhbiBleHBpcmF0aW9uIHRpbWUgb24gdGhlIG1lc3NhZ2Uu IFRoaXMgY2FwYWJpbGl0eSBpcyBkaXNjdXNzZWQgPGJyPg0KaW4gZHJhZnQtbHViYXNoZXYtcXVp Yy1wYXJ0aWFsLXJlbGlhYmlsaXR5LTAzLCBhbmQgaXMgc2ltaWxhciB0byBob3cgPGJyPg0KU0NU UCBoYW5kbGVzIHBhcnRpYWwgcmVsaWFiaWxpdHkuIElmIG9ubHkgYSByYXcgREFUQUdSQU0gY2Fw YWJpbGl0eSBpcyA8YnI+DQpwcm92aWRlZCwgdGhlbiBwYXJ0aWFsIHJlbGlhYmlsaXR5IHdpbGwg bmVlZCB0byBiZSBidWlsdCBvbiB0b3Agb2YgUVVJQywgPGJyPg0KZGVmZWF0aW5nIHRoZSBwdXJw b3NlIG9mIHVzaW5nIFFVSUMgZm9yIHRoaXMgYXBwbGljYXRpb24uIE90aGVyIDxicj4NCmFwcGxp Y2F0aW9ucyBzdWNoIGFzIG9ubGluZSBnYW1pbmcgaGF2ZSB2ZXJ5IHNpbWlsYXIgcGVyZm9ybWFu Y2UgPGJyPg0KcmVxdWlyZW1lbnRzLCBzbyBJIHRoaW5rIHRoYXQgdGhlIHBhcnRpYWwgcmVsaWFi aWxpdHkgY2FwYWJpbGl0eSB3aWxsIGJlIDxicj4NCmltcG9ydGFudCB0byBtYW55IGZ1dHVyZSB1 c2Vycy48YnI+DQo8YnI+DQpUaGUgY29tcGxleGl0eSBhbmQgcmVxdWlyZWQgZWZmb3J0IHRvIGFk ZCB0aGUgcGFydGlhbCByZWxpYWJpbGl0eSA8YnI+DQpjYXBhYmlsaXR5IHRvIFFVSUMgaXMgbG93 LCBzbyBJIGhvcGUgdGhhdCB0aGlzIGNhcGFiaWxpdHkgaXMgbm90IGFiYW5kb25lZC48YnI+DQo8 YnI+DQpSb2JvdCBSYWNvbnRldXIgaGFzIHJlY2VpdmVkIGEgZ3JhbnQgZnJvbSB0aGUgVW5pdGVk IFN0YXRlcyBBUk0gPGJyPg0KSW5zdGl0dXRlIGFuZCBOZXcgWW9yayBTdGF0ZSB0byBiZWdpbiBj b21tZXJjaWFsaXppbmcgdGhlIHRlY2hub2xvZ3kuIDxicj4NClRoaXMgcHJvamVjdCB3aWxsIGJl IGRvbmUgaW4gcGFydG5lcnNoaXAgd2l0aCBXYXNvbiBUZWNobm9sb2d5LCBMTEMsIDxicj4NClJl bnNzZWxhZXIgUG9seXRlY2huaWMgSW5zdGl0dXRlLCBTb3V0aHdlc3QgUmVzZWFyY2ggSW5zdGl0 dXRlLCBhbmQgPGJyPg0KVW5pdGVkIFRlY2hub2xvZ2llcyBSZXNlYXJjaCBDZW50ZXIuIFRoZSBw cm9qZWN0IHN0YXJ0cyBzb29uLCBhbmQgPGJyPg0KY29uc2lkZXJhYmxlIGRldmVsb3BtZW50IGVm Zm9ydCB3aWxsIGJlIGludmVzdGVkIGluIHRoZSBSb2JvdCBSYWNvbnRldXIgPGJyPg0KdGVjaG5v bG9neSBzdGFydGluZyBlYXJseSBzdW1tZXIuIEludGVncmF0aW5nIFFVSUMgaXMgb25lIG9mIHRo ZSB0YXNrcyA8YnI+DQp0aGF0IEkgaG9wZSB0byB1bmRlcnRha2UgZHVyaW5nIHRoaXMgcHJvamVj dC48YnI+DQo8YnI+DQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IHF1ZXN0aW9u cyBhYm91dCBSb2JvdCBSYWNvbnRldXIgb3IgPGJyPg0KdGhlIHJlcXVpcmVtZW50cyBmb3IgUVVJ QyBpbiByb2JvdGljcyBhcHBsaWNhdGlvbnMuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC1Kb2huIFdhc29uPGJyPg0KPGJyPg0KKCogSSBhbSBhd2FyZSB0aGF0IHRoZXJlIGFy ZSBzb21lIGNhdmVhdHMgdG8gaG93IFJPUy9ST1MyIGludGVyYWN0IHdpdGggPGJyPg0KdGhlIHdp ZGVyIHdvcmxkLCBidXQgdGhlIHRlY2hub2xvZ2llcyBhcmUgbm90IGJ1aWx0IG9uIG9yIGNvbXBh dGlibGUgPGJyPg0Kd2l0aCB3ZWIgc3RhbmRhcmRzIHNvIGFuIGluIGRlcHRoIGRpc2N1c3Npb24g aXMgbm90IHJlbGV2YW50IGZvciB0aGUgPGJyPg0KY3VycmVudCB0b3BpYy4gUk9TIGRvZXMgaGF2 ZSBhIFVEUCB0cmFuc3BvcnQsIGJ1dCBpdCBpcyBub3QgY29tbW9ubHkgdXNlZC4pPGJyPg0KPGJy Pg0KLS0gPGJyPg0KSm9obiBXYXNvbiwgUGguRC48YnI+DQpXYXNvbiBUZWNobm9sb2d5LCBMTEM8 YnI+DQoxNiBTdGVybGluZyBMYWtlIFJkPGJyPg0KVHV4ZWRvLCBOWSAxMDk4Nzxicj4NCig1MTgp IDI3OS02MjM0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOndhc29uQHdhc29udGVjaC5jb20iIHRhcmdl dD0iX2JsYW5rIj53YXNvbkB3YXNvbnRlY2guY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT4tLSA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5Kb2huIFdhc29uLCBQaC5ELjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPldh c29uIFRlY2hub2xvZ3ksIExMQzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjE2IFN0ZXJsaW5nIExh a2UgUmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UdXhlZG8sIE5ZIDEwOTg3PG86cD48L286cD48 L3ByZT4NCjxwcmU+KDUxOCkgMjc5LTYyMzQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm PSJtYWlsdG86d2Fzb25Ad2Fzb250ZWNoLmNvbSI+d2Fzb25Ad2Fzb250ZWNoLmNvbTwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwcmU+LS0mbmJz cDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Sm9obiBXYXNvbiwgUGguRC48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5XYXNvbiBUZWNobm9sb2d5LCBMTEM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4x NiBTdGVybGluZyBMYWtlIFJkPG86cD48L286cD48L3ByZT4NCjxwcmU+VHV4ZWRvLCBOWSAxMDk4 NzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPig1MTgpIDI3OS02MjM0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOndhc29uQHdhc29udGVjaC5jb20iPndhc29uQHdhc29udGVj aC5jb208L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_fc0a9e35393a435a9b6f5662aef866e2usma1exdag1mb5msgcorpak_-- From nobody Wed May 1 10:53: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 A7B6E12012C for ; Wed, 1 May 2019 10:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl4uB6Db_jwn for ; Wed, 1 May 2019 10:53:36 -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 9B7AD120136 for ; Wed, 1 May 2019 10:53:35 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id a12so25388944wrq.10 for ; Wed, 01 May 2019 10:53: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=U5FHEZSvp4JSKRuyNnTzwrU8kjduivefMLUMxFqcvcg=; b=r2fT/efNv3Lykw+ABVzG1EGAKkN5x3sQMM4t/GJ1jnnwOG8mHuJ7WId2LkqZaXwm3s 6Y66/cfhJBhw5S6APrAtGtxiHKrWg0dmmW3ESM2/nl1U5KquCY/JkkNYGHVqT/olTxxG szjfr5VYjaaTsYBNnDk/CB91DfBd0kMudGHE5LqE+df466d0cYd02rDmoadzEFx6Auzk 8QbZAFX3QOCGqI8ANQFg2emQveV92vtcHwinxl8fSMnEkfrp2M6rknbjh35F2AJ0xxpt wg7OKOhAscvgWBVDArDg5rqfFRgxkP6VX+Z9ovCGDzMUz7FmUIXeVXpoL8XqSQtYsmo5 aFhw== 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=U5FHEZSvp4JSKRuyNnTzwrU8kjduivefMLUMxFqcvcg=; b=oddT3VSyoRvgzez38/N3e904kwW+nWQ6sT8WCm+7hQ7lFm+989C5Cnad4N17MpFxIR cN+8XXqbgiXXN3R4HwfPiEzXv5uczun1k2cijI6tccPW4lg2lEfrayie/h6xi868frOJ CElLYrup0HiWFA9siSMF+RjVo3V/k3PzwRoiqI6u8eqxWLDIma9UAVB79rvqFKyr3Y77 EV22hlRa5vVkI+dAEgXq7Sw4jQdvn9MDASJFmWfwzUk8VazU1YQBnNuJ9exPTuxS1/Dy CqTOxLnx00/2agY+PYi0wwrdEWflX3ihDxhee70tmVPkApXtRHJecqOuKf9gsvS+uQmC EDfQ== X-Gm-Message-State: APjAAAVIBh/JqQ0IyNIrGsZqnozx+1ykQrx/MgW7Ztd1a5zcyhjjCLQl fDrE7ZKw28W8kRnNrCKxXuw9pByi+5lNDL/dLDM= X-Google-Smtp-Source: APXvYqysXuMZ+rKYOaFaNzd4BK0bD5ZUMkiWBJzmi3oV/ghdP3KezgXX6CTxHvz5BNPTehmy6pzMVJpv/aPgih1apis= X-Received: by 2002:a5d:5542:: with SMTP id g2mr27630367wrw.58.1556733214097; Wed, 01 May 2019 10:53:34 -0700 (PDT) MIME-Version: 1.0 References: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> <20190501123305.GA5964@ubuntu-dmitri> In-Reply-To: From: Martin Duke Date: Wed, 1 May 2019 10:53:22 -0700 Message-ID: Subject: Re: Connection ID Space To: Marten Seemann Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="0000000000003c88250587d73261" 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, 01 May 2019 17:53:38 -0000 --0000000000003c88250587d73261 Content-Type: text/plain; charset="UTF-8" Allowing longer CIDs in short headers at least partially mitigates this. Is the theory that future versions would negotiate this in the handshake, so every short header would have the longer CID? On Wed, May 1, 2019 at 7:46 AM Marten Seemann wrote: > If I remember correctly, we made all the required changes for that to the > invariants. The connection ID lengths are only invariant for Long Header > packets. The connection ID for Short Header packets can have any length, so > a new QUIC version (or a QUIC extension) could define connection IDs in the > Short Header to have lengths that are not encodable in the 0/4-18 scheme. > > On Wed, May 1, 2019 at 11:31 PM Martin Thomson wrote: > >> On Wed, May 1, 2019, at 14:33, Dmitri Tikhonov wrote: >> > On Tue, Apr 30, 2019 at 08:31:47PM -0400, Martin Thomson wrote: >> > > That's on the TODO list anyway, as we agreed to remove the >> > > 0/4-18 restriction for the short packet header a while back. >> > >> > I do not recall -- when was that decided? >> >> It was in relation to a request for a *smaller* connection ID. Marten >> might remember better than I. >> >> --0000000000003c88250587d73261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Allowing longer CIDs in short headers at least partially m= itigates this. Is the theory that future versions would negotiate this in t= he handshake, so every short header would have the longer CID?

On Wed, May 1= , 2019 at 7:46 AM Marten Seemann <martenseemann@gmail.com> wrote:
If I remember correctly, we ma= de all the required changes for that to the invariants. The connection ID l= engths are only invariant for Long Header packets. The connection ID for Sh= ort Header packets can have any length, so a new QUIC version (or a QUIC ex= tension) could define connection IDs in the Short Header to have lengths th= at are not encodable in the 0/4-18 scheme.

On Wed, May 1, 2019 at 11:31 PM M= artin Thomson <mt= @lowentropy.net> wrote:
On Wed, May 1, 2019, at 14:33, Dmitri Tikhonov wrote:
> On Tue, Apr 30, 2019 at 08:31:47PM -0400, Martin Thomson wrote:
> > That's on the TODO list anyway, as we agreed to remove the > > 0/4-18 restriction for the short packet header a while back.
>
> I do not recall -- when was that decided?

It was in relation to a request for a *smaller* connection ID.=C2=A0 Marten= might remember better than I.

--0000000000003c88250587d73261-- From nobody Wed May 1 11:28: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 102BC120143 for ; Wed, 1 May 2019 11:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.24 X-Spam-Level: X-Spam-Status: No, score=0.24 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-LCuFp_i6YG for ; Wed, 1 May 2019 11:28:15 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 E653B120136 for ; Wed, 1 May 2019 11:28:14 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id b7so1349817qkl.2 for ; Wed, 01 May 2019 11:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=DhzSbUqBDrdPOKML1awNvLC6PJcGcNyd80Ki7FiTEig=; b=MjOoeSxG/j3Iiza8ggJv9SsHRUX6NH4WlMtmfJ3xevfXfkj7EFxzD1MhBXcSedjDwe nBAaS1FjP5X4av0mwZLl+iBTw0jDna1GbRmEC+BYJ9OGK2B/vgadA4K3Dk6GK3q2UIUW M6ETsm4IfwuYcoPdyco0Fbd29NOFKUSxrdmomeaByiHm9+T8cbfQvcIOtC/tKnk8DlgH oa9WkYIyDD2jiMO7w9a2AxQGCWSULvXqKy+lnmshESMJ+YYGx4Jrm7F2YjZQ8kgvQvii ZzhuqOHUX8V9tsJ+FnDJcIFs4MDq4mF5TgG6I68jqCxKxC/KJeyCSqzTz8Tz1FNcO/KL Dhyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=DhzSbUqBDrdPOKML1awNvLC6PJcGcNyd80Ki7FiTEig=; b=GFjIuApXDu4OvLtSWPGC9+SFPC9pjTnOmAZCJtLyty5pMWL7ExsNP5+0htxM/0JpRE yP9xdrsh+Oqj0DL/SE04f/6D3cKEqqohi5WKgGV9Xr4VHYip7OVvqt0m9bQehODXoCWx dHGCTY9GAIqiWcBg0+BuXBxNHbMM2wPhfXQ2uDgEVi1D9NcdQ6eM7oLdCvs9LmCPwTxW Hh7ld+Uo/VwZYlURU5ZhHum94MYXkl42uVItCbR4mFpUTAH2SKI4q0OAK1jqMgbsyGYa +hQ2HzSEqcBwvgd9VIWGiJQqXVi4gTBnHCq9Q9rJegHrnHecGgxbORjhoNTNHZUpsBBx S0QQ== X-Gm-Message-State: APjAAAUDTw+xhFYpoV9PDjf1EBqrLz8B1epD6YmBEE1CWYIF0kpNeEDr rc0yCxGJ2I9g1kaE5RRGeHv91ADg X-Google-Smtp-Source: APXvYqysFd/txr6yI+F3nJrdOJFwx35rC5YXXdS3Kzo94xS9k7sR8zFO0VUlu1+LN76fcea/+bpbIg== X-Received: by 2002:a37:b683:: with SMTP id g125mr6165597qkf.249.1556735293588; Wed, 01 May 2019 11:28:13 -0700 (PDT) Received: from [192.168.1.94] (ool-44c6b4b5.dyn.optonline.net. [68.198.180.181]) by smtp.googlemail.com with ESMTPSA id 4sm1067662qtt.90.2019.05.01.11.28.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 11:28:12 -0700 (PDT) Subject: Re: QUIC for robotics and other time-sensitive applications To: "Lubashev, Igor" , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Ted Hardie Cc: IETF QUIC WG References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> From: John Wason Message-ID: Date: Wed, 1 May 2019 14:28:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6C42F9741C3DBC5079F09753" 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: Wed, 01 May 2019 18:28:18 -0000 This is a multi-part message in MIME format. --------------6C42F9741C3DBC5079F09753 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Would it make sense to add support for isochronous data directly to the QUIC protocol? DDS has the ability to set the requested update rate and QoS of different topics. My plan has been to emulate this functionality using streams at the application layer, but I am thinking now that there may be some benefit to having specialized flow control and QoS capabilities for this type of data. Besides robotics, this type of data is used extensively for applications like online gaming and high frequency trading so I think there is a large user base that would benefit from the extra capabilities. On 5/1/2019 1:33 PM, Lubashev, Igor wrote: > > The QUIC library API may include a facility to set/update stream > priorities for the sender of data. Webrtc-quic may include the same > w/o any change to the underlying QUIC protocol. > > However, if a request for a priority change of a stream is originating > from the receiver of the data, QUIC transport has no facility to relay > this information to the sender.  An application protocol would need to > handle this.  I think it is a useful extension for QUIC v2 to push > stream priority to the transport, since the transport can manage this > control signal more efficiently. > > *From:* Mikkel Fahnøe Jørgensen > *Sent:* Wednesday, May 01, 2019 12:38 PM > *To:* Lubashev, Igor ; Ted Hardie > ; John Wason > *Cc:* IETF QUIC WG > *Subject:* Re: QUIC for robotics and other time-sensitive applications > > QUIC does not prioritise streams at the transport layer, that is an > implementation detail although pacing is recommended. If you bring you > own application layer protocol you can decide how to schedule data > across streams within the flow control constraints. You could add > priorities to your application level custom API. If you layer a > protocol on top of H3 you are more constrained since you must assume > other implementations that won’t necessarily do what you want them to do. > > On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com > ) wrote: > > Igor, > > It appears I misunderstood the distinction between per-stream > partial reliability and intra-stream partial reliability. If I > send one partial-reliability message per stream, using RESET > frames should be sufficient. How this is exposed as an API is > important, since I am not sure the webrtc-quic team has considered > this yet. In response to your questions 1) Each message contains a > header that should be sufficient for the receiver to understand > the incoming stream 2) Does QUIC provide the type of priority that > you suggest? My understanding is that QUIC multiplexes streams > using a priority based ordering. > > If I can emulate partial-reliability using RESET frames to cancel > entire streams, that should be sufficient for my needs. > > -John > > On 5/1/2019 10:33 AM, Lubashev, Igor wrote: > > John, > > I am happy to resurrect that > draft-lubashev-quic-partial-reliability for QUIC v2 (some > people preferred version 02, which actually gets you a bit > more features at the cost of a bit more complexity). > > I would like to first understand what partially reliable > streams give you that is not available with regular streams.  > I.e. what are you missing if you use STREAM (with a possible > subsequent RESET) for messages?  (You cannot use DATAGRAM for > messages, since you would like the transport to facilitate > retransmission until expiration.) > > My draft-lubashev-quic-partial-reliability lists a few things > that stream-per-message does not get you: > > 1. If you have multiple application message streams, you > would need a header for each QUIC stream to identify the > application stream.  This seems like a small burden, > except for very short messages. > > 1. If the order of messages in an application stream > matters, you would need to reorder them yourself.  > This cannot be very complicated for the application. > > 2. QUIC per-application-stream flow control is rendered > ineffective.  I am actually not a huge fan of QUIC > per-stream flow control, as I strongly prefer stream > priorities as a signal.  But I now know of a case when > per-stream flow control is, indeed useful (when there is > only one slow draining stream that uses up the entire > connection buffer before a higher-priority stream shows up). > > Are there any other benefits you see in partially reliable > streams? > > * Igor > > *From:*John Wason > > *Sent:* Tuesday, April 30, 2019 5:52 PM > *To:* Ted Hardie > *Cc:* IETF QUIC WG > *Subject:* Re: QUIC for robotics and other time-sensitive > applications > > Thanks Ted, this looks very interesting. Based on these > documents the DETNET sits below the level of QUIC that we are > currently discussing and would mainly affect the IP header > format of the resulting UDP packets. The QUIC protocol will > still require some form of partial reliability to function on > a DETNET network. > > -John Wason > > On 4/30/2019 5:37 PM, Ted Hardie wrote: > > Hi John, > > Thanks for the message.  If you have not already reviewed > the work of DETNET > (https://datatracker.ietf.org/wg/detnet/about/ > ) > here in the IETF, it might be useful to do so, as there > are a number of elements of your use case which appeared > to be shared with their work.  In particular, it might be > useful to consider whether the integration of their > proposed IP data plane > (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1 > ) > with QUIC would be valuable in achieving your timing goals. > > best regard, > > Ted Hardie > > On Tue, Apr 30, 2019 at 12:15 PM John Wason > > wrote: > > Greetings QUIC WG, > > The discussion on Issue #92 of webrtc-quic suggested > that I post my > requirements to this list. > > I am a robotics engineer and the developer of Robot > Raconteur, a > communication framework for robotics and automation > systems > (https://github.com/robotraconteur/robotraconteur > ). > Robotics > applications require different data types and QoS when > compared to > business or web applications. Robotics applications > need real-time > communication of isochronous data, for instance > constant updates on the > position of the joints of the robot, alongside generic > non-time-sensitive data. Currently most robotics > applications are using > TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, > ROS*), or some form > of custom Ethernet protocol (Ethernet/IP, EtherCAT, > PowerLink). To add > more confusion to the situation, there is the recent > introduction of > IEEE 802.1Q Time Sensitive Networking (TSN) which > claims to allow TCP > and UDP to achieve hard real-time performance. > > While there are many robotics protocols out there, > only Robot Raconteur > and OPC/UA are compatible with existing web and cloud > infrastructure. > (Some limited support for ROS/ROS2 has become > available on AWS, but the > design of ROS does not play very well outside of local > networks.*) Robot > Raconteur implements web browser and web server > support by allowing the > websocket protocol to be used. Clients can use a URL > that specifies that > the connection is a websocket, and incoming TCP > connections can detect > if the connection is the Robot Raconteur protocol or > an incoming > websocket connection. Robot Raconteur running inside > an ASP.NET > > web > server has been demonstrated, and there is no > technical reason that > other server technologies cannot accept Robot > Raconteur connections > through websockets. (OPC/UA uses SOAP for its web > based transport, but > support is very poor and only available in a few > implementations.) > > The main issue limiting Robot Raconteur for more > demanding applications > is the use of TCP for data transport. TCP suffers from > "head-of-line" > blocking, which means that if stale data encounters an > error it can stop > fresh data from reaching the other peer. There is also > the problem of > large messages blocking the transmission of smaller, > more time sensitive > messages on the connection. QUIC appears to solve most > of these > problems, and the webrtc-quic support under > development provides a lot > of new and interesting opportunities for integrating > robotics > applications with web technology. By adopting QUIC, > the resulting > software will remain completely compatible with web > infrastructure. > > Transmitting time-sensitive data requires the ability > to multiplex (and > prioritize) messages and drop messages if the data > contained becomes > stale. The multiplexing issue is solved using the > "streams as messages" > concept in QUIC, with built in priority handling. This > design looks very > promising, and considerably simpler to use compared to > SCTP streams. The > current issue that is somewhat questionable is the > implementation of > partial reliability. The discussion right now is > focused on DATAGRAM > extensions (draft-pauly-quic-datagram-02), which allow > for "raw" access > to the socket so protocols such as RTP can tunnel > through QUIC. This > requirement is quite a bit different than what is > required for an > application like Robot Raconteur. Robot Raconteur is > based on message > passing, where either the entire message is received > or the entire > message is cancelled because the data contained is > stale. The message > may be considerably larger than MTU, and the QoS may > be "partial," > meaning that a set number of attempts may be made to > resend, and/or > there is an expiration time on the message. This > capability is discussed > in draft-lubashev-quic-partial-reliability-03, and is > similar to how > SCTP handles partial reliability. If only a raw > DATAGRAM capability is > provided, then partial reliability will need to be > built on top of QUIC, > defeating the purpose of using QUIC for this > application. Other > applications such as online gaming have very similar > performance > requirements, so I think that the partial reliability > capability will be > important to many future users. > > The complexity and required effort to add the partial > reliability > capability to QUIC is low, so I hope that this > capability is not abandoned. > > Robot Raconteur has received a grant from the United > States ARM > Institute and New York State to begin commercializing > the technology. > This project will be done in partnership with Wason > Technology, LLC, > Rensselaer Polytechnic Institute, Southwest Research > Institute, and > United Technologies Research Center. The project > starts soon, and > considerable development effort will be invested in > the Robot Raconteur > technology starting early summer. Integrating QUIC is > one of the tasks > that I hope to undertake during this project. > > Please let me know if you have any questions about > Robot Raconteur or > the requirements for QUIC in robotics applications. > >      -John Wason > > (* I am aware that there are some caveats to how > ROS/ROS2 interact with > the wider world, but the technologies are not built on > or compatible > with web standards so an in depth discussion is not > relevant for the > current topic. ROS does have a UDP transport, but it > is not commonly used.) > > -- > John Wason, Ph.D. > Wason Technology, LLC > 16 Sterling Lake Rd > Tuxedo, NY 10987 > (518) 279-6234 > wason@wasontech.com > > -- > > John Wason, Ph.D. > > Wason Technology, LLC > > 16 Sterling Lake Rd > > Tuxedo, NY 10987 > > (518) 279-6234 > > wason@wasontech.com > > -- > > John Wason, Ph.D. > > Wason Technology, LLC > > 16 Sterling Lake Rd > > Tuxedo, NY 10987 > > (518) 279-6234 > > wason@wasontech.com > -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com --------------6C42F9741C3DBC5079F09753 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Would it make sense to add support for isochronous data directly to the QUIC protocol? DDS has the ability to set the requested update rate and QoS of different topics. My plan has been to emulate this functionality using streams at the application layer, but I am thinking now that there may be some benefit to having specialized flow control and QoS capabilities for this type of data. Besides robotics, this type of data is used extensively for applications like online gaming and high frequency trading so I think there is a large user base that would benefit from the extra capabilities.

On 5/1/2019 1:33 PM, Lubashev, Igor wrote:

The QUIC library API may include a facility to set/update stream priorities for the sender of data.  Webrtc-quic may include the same w/o any change to the underlying QUIC protocol.

 

However, if a request for a priority change of a stream is originating from the receiver of the data, QUIC transport has no facility to relay this information to the sender.  An application protocol would need to handle this.  I think it is a useful extension for QUIC v2 to push stream priority to the transport, since the transport can manage this control signal more efficiently.

 

From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Sent: Wednesday, May 01, 2019 12:38 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Ted Hardie <ted.ietf@gmail.com>; John Wason <johnwason1@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC for robotics and other time-sensitive applications

 

QUIC does not prioritise streams at the transport layer, that is an implementation detail although pacing is recommended. If you bring you own application layer protocol you can decide how to schedule data across streams within the flow control constraints. You could add priorities to your application level custom API. If you layer a protocol on top of H3 you are more constrained since you must assume other implementations that won’t necessarily do what you want them to do.

 

 

On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com) wrote:

Igor,

It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering.

If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs.

    -John

On 5/1/2019 10:33 AM, Lubashev, Igor wrote:

John,

 

I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity).

 

I would like to first understand what partially reliable streams give you that is not available with regular streams.  I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages?  (You cannot use DATAGRAM for messages, since you would like the transport to facilitate retransmission until expiration.)

 

My draft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you:

 

  1. If you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream.  This seems like a small burden, except for very short messages.
    1. If the order of messages in an application stream matters, you would need to reorder them yourself.  This cannot be very complicated for the application.

 

  1. QUIC per-application-stream flow control is rendered ineffective.  I am actually not a huge fan of QUIC per-stream flow control, as I strongly prefer stream priorities as a signal.  But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up).

 

Are there any other benefits you see in partially reliable streams?

 

  • Igor

 

From: John Wason <johnwason1@gmail.com>
Sent: Tuesday, April 30, 2019 5:52 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC for robotics and other time-sensitive applications

 

Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.

    -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:

Hi John,

 

Thanks for the message.  If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work.  In particular, it might be useful to consider whether the integration of their proposed IP data plane (https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text=1) with QUIC would be valuable in achieving your timing goals.

 

 

best regard,

 

Ted Hardie

 

On Tue, Apr 30, 2019 at 12:15 PM John Wason <johnwason1@gmail.com> wrote:

Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/robotraconteur/robotraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the
position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur
and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the
design of ROS does not play very well outside of local networks.*) Robot
Raconteur implements web browser and web server support by allowing the
websocket protocol to be used. Clients can use a URL that specifies that
the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications
is the use of TCP for data transport. TCP suffers from "head-of-line"
blocking, which means that if stale data encounters an error it can stop
fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive
messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and
prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages"
concept in QUIC, with built in priority handling. This design looks very
promising, and considerably simpler to use compared to SCTP streams. The
current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed
in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC,
defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be
important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur
technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

     -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with
the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--  
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--------------6C42F9741C3DBC5079F09753-- From nobody Wed May 1 11:45: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 C05D0120021 for ; Wed, 1 May 2019 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 VIeD3krgfjUJ for ; Wed, 1 May 2019 11:45:04 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0: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 B837E120143 for ; Wed, 1 May 2019 11:45:04 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id q14so153351itk.0 for ; Wed, 01 May 2019 11:45:04 -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=TjTfRW5iwy3LARbKmpX9rl9t28tjd33MY15Qe72AiVE=; b=OjwvBBfAm+H27XVCtGnn/SvkEFrrvp5vY0lX758uMsbv35M988hBNW3zhoVw40NUjw oN31D6ezZ0UtkOSIJKo+Gif8pYVUZh39wqvNnT9Z2sEZd447iuQGZaIgyfxGfgjdGDss gNzipSxQUBL7egvlYC/KAh+VOhvMuoZ9aQqtQulMyB4HiqdjjG+kfnh24nCWpjKePDYs ISIUxZQcFkhEqmWjqgAs6mx8e4+6AZq9ZPhdgRBdtt9suo5MpCmnj5SBBXjUdl1AzoFk GfhgmAcwhhrZNHe5kLsFIveL8T+zUTcNGaZ8d943bgeayHjS63R/ZiNL7prYzhtJsQ3F oyHg== 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=TjTfRW5iwy3LARbKmpX9rl9t28tjd33MY15Qe72AiVE=; b=tqzAKySg6/J6MLqTEqhHfoRbkqaqlbIKoBB+1IHsqj4zuXy3h5c8moGsaH8iVMDl3g r1RG0dVM46jqwWAPgPzN3apenBQ1nKmZ3cedDNUNycyDXtJRh0tfpoCGlz2mQ5HKtMeB qPmkQIrK9X3VhYnKYBfW1kUf01XXAX5la16gLmp86NyVc3yBdNsLnbb5PBFkS+6Mb9yO oEKtCUd505VIcuHqDMk9xhRlqBr5Ce1qvlNeYSVtVcQwDrhrVRpSk+zoiJt7RypMpqOA lkoaW2Ff1uUNrAGjtnG/GcHgV2qkiq84sxrzg0f5mCXct8JrmlYnQWPvpZiBbWZhytuu KH7A== X-Gm-Message-State: APjAAAW76cfKlQmjqSeCahbrSkAYdo/oBJi+Fytdk8LbkHDtzLQ7YOep m8eazwaXlmsF85N5OsS3ots8ZDVpo9t0bWwnxic= X-Google-Smtp-Source: APXvYqydbmfqMS4kLrzjFzO/Szxma1BLm3ff2o8HTUWuvXOHAnA58+Y/5jGO+GF6PLIY8p1Bmi2UkTr2zABKY7AQlC0= X-Received: by 2002:a24:9d96:: with SMTP id f144mr8573350itd.167.1556736303899; Wed, 01 May 2019 11:45:03 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 1 May 2019 14:45:02 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1bb52999-d020-422e-db87-733fbc7b0cae@gmail.com> References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> <1bb52999-d020-422e-db87-733fbc7b0cae@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 1 May 2019 14:45:02 -0400 Message-ID: Subject: Re: QUIC for robotics and other time-sensitive applications To: "Lubashev, Igor" , Ted Hardie , John Wason Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000672a330587d7ea26" 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, 01 May 2019 18:45:08 -0000 --000000000000672a330587d7ea26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To your latest question first > Would it make sense to add support for isochronous data directly to the QUIC protocol? No I don=E2=80=99t think so. Things go into transport if transport can do m= agic difficult to do elsewhere. Sending repeated events is not that. It would just complicate the core logic. Please note that QUIC v2 has focus on partial reliability but it is out of scope for v1. You can construct an overlay stream by sending an identifier in stream payload and send each event in a new stream. This avoids head-of-line-blocking (HOL), but it is clumsy and not always a good solution. On controlling transmission rate: There are algorithms that are sensitive to prioritizing small payload over large payload such that all overall fairness is achieved (FQ scheduler) such as weighed round robin (WRR) https://en.wikipedia.org/wiki/Network_scheduler An applicaition interface can receive hints that can guide such a scheduler. The scheduler would be implement in the belly of the QUIC transport, but it isn=E2=80=99t part of the transport layer protocol per se= . On visiblity of flow control. See the various packets the stream controllers send to allow more data. Stream based limits are generally for applications that cannot buffr more for the time being while connection level is for overall bandwidth. A receiver can try to manage priorities via flow credits, but it probably gets messy. > I am not sure what you mean by "layer on top of H3=E2=80=9D. This is the equivalent of a HTTP 1.1. REST protocol vs a custom/dedicated TCP protocol like FTP. If you choose H3 your protocol design would be expected to be useful for the majority of QUIC H3 implementations. If you choose a lower level protocol directly on the QUIC transport layer, you are still limited by whatever API=E2=80=99s make available such as sche= duling, but if you can the better choose implementations that are suitable. Mikkel On 1 May 2019 at 19.33.28, John Wason (johnwason1@gmail.com) wrote: Mikkel, That makes sense, the order of streams sent shouldn't affect the wire protocol. For the flow control, does the protocol provide information about how much headroom is left? For instance, it may be very important that small, time sensitive streams reach their destination quickly, while there may be larger, slower streams that can wait. If the flow control is not handled correctly, the slower stream could block the fast streams by filling the available bandwidth and buffers. I am not sure what you mean by "layer on top of H3". -John On 5/1/2019 12:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: QUIC does not prioritise streams at the transport layer, that is an implementation detail although pacing is recommended. If you bring you own application layer protocol you can decide how to schedule data across streams within the flow control constraints. You could add priorities to your application level custom API. If you layer a protocol on top of H3 you are more constrained since you must assume other implementations that won= =E2=80=99t necessarily do what you want them to do. On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com) wrote: Igor, It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering. If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs. -John On 5/1/2019 10:33 AM, Lubashev, Igor wrote: John, I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity). I would like to first understand what partially reliable streams give you that is not available with regular streams. I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages? (You cannot use DATAGRAM for messages, since you would like the transport to facilitate retransmission until expiration.) My draft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you: 1. If you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream. This se= ems like a small burden, except for very short messages. 1. If the order of messages in an application stream matters, you would need to reorder them yourself. This cannot be very complicated= for the application. 1. QUIC per-application-stream flow control is rendered ineffective. I am actually not a huge fan of QUIC per-stream flow control, as I strongl= y prefer stream priorities as a signal. But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up). Are there any other benefits you see in partially reliable streams? - Igor *From:* John Wason *Sent:* Tuesday, April 30, 2019 5:52 PM *To:* Ted Hardie *Cc:* IETF QUIC WG *Subject:* Re: QUIC for robotics and other time-sensitive applications Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network. -John Wason On 4/30/2019 5:37 PM, Ted Hardie wrote: Hi John, Thanks for the message. If you have not already reviewed the work of DETNET (https://datatracker.ietf.org/wg/detnet/about/ ) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work. In particular, it might be useful to consider whether the integration of their proposed IP data plane ( https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol-ip/?include_text= =3D1 ) with QUIC would be valuable in achieving your timing goals. best regard, Ted Hardie On Tue, Apr 30, 2019 at 12:15 PM John Wason wrote: Greetings QUIC WG, The discussion on Issue #92 of webrtc-quic suggested that I post my requirements to this list. I am a robotics engineer and the developer of Robot Raconteur, a communication framework for robotics and automation systems (https://github.com/robotraconteur/robotraconteur ). Robotics applications require different data types and QoS when compared to business or web applications. Robotics applications need real-time communication of isochronous data, for instance constant updates on the position of the joints of the robot, alongside generic non-time-sensitive data. Currently most robotics applications are using TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add more confusion to the situation, there is the recent introduction of IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP and UDP to achieve hard real-time performance. While there are many robotics protocols out there, only Robot Raconteur and OPC/UA are compatible with existing web and cloud infrastructure. (Some limited support for ROS/ROS2 has become available on AWS, but the design of ROS does not play very well outside of local networks.*) Robot Raconteur implements web browser and web server support by allowing the websocket protocol to be used. Clients can use a URL that specifies that the connection is a websocket, and incoming TCP connections can detect if the connection is the Robot Raconteur protocol or an incoming websocket connection. Robot Raconteur running inside an ASP.NET web server has been demonstrated, and there is no technical reason that other server technologies cannot accept Robot Raconteur connections through websockets. (OPC/UA uses SOAP for its web based transport, but support is very poor and only available in a few implementations.) The main issue limiting Robot Raconteur for more demanding applications is the use of TCP for data transport. TCP suffers from "head-of-line" blocking, which means that if stale data encounters an error it can stop fresh data from reaching the other peer. There is also the problem of large messages blocking the transmission of smaller, more time sensitive messages on the connection. QUIC appears to solve most of these problems, and the webrtc-quic support under development provides a lot of new and interesting opportunities for integrating robotics applications with web technology. By adopting QUIC, the resulting software will remain completely compatible with web infrastructure. Transmitting time-sensitive data requires the ability to multiplex (and prioritize) messages and drop messages if the data contained becomes stale. The multiplexing issue is solved using the "streams as messages" concept in QUIC, with built in priority handling. This design looks very promising, and considerably simpler to use compared to SCTP streams. The current issue that is somewhat questionable is the implementation of partial reliability. The discussion right now is focused on DATAGRAM extensions (draft-pauly-quic-datagram-02), which allow for "raw" access to the socket so protocols such as RTP can tunnel through QUIC. This requirement is quite a bit different than what is required for an application like Robot Raconteur. Robot Raconteur is based on message passing, where either the entire message is received or the entire message is cancelled because the data contained is stale. The message may be considerably larger than MTU, and the QoS may be "partial," meaning that a set number of attempts may be made to resend, and/or there is an expiration time on the message. This capability is discussed in draft-lubashev-quic-partial-reliability-03, and is similar to how SCTP handles partial reliability. If only a raw DATAGRAM capability is provided, then partial reliability will need to be built on top of QUIC, defeating the purpose of using QUIC for this application. Other applications such as online gaming have very similar performance requirements, so I think that the partial reliability capability will be important to many future users. The complexity and required effort to add the partial reliability capability to QUIC is low, so I hope that this capability is not abandoned. Robot Raconteur has received a grant from the United States ARM Institute and New York State to begin commercializing the technology. This project will be done in partnership with Wason Technology, LLC, Rensselaer Polytechnic Institute, Southwest Research Institute, and United Technologies Research Center. The project starts soon, and considerable development effort will be invested in the Robot Raconteur technology starting early summer. Integrating QUIC is one of the tasks that I hope to undertake during this project. Please let me know if you have any questions about Robot Raconteur or the requirements for QUIC in robotics applications. -John Wason (* I am aware that there are some caveats to how ROS/ROS2 interact with the wider world, but the technologies are not built on or compatible with web standards so an in depth discussion is not relevant for the current topic. ROS does have a UDP transport, but it is not commonly used.) -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com --=20 John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234 wason@wasontech.com -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234wason@wasontech.com -- John Wason, Ph.D. Wason Technology, LLC 16 Sterling Lake Rd Tuxedo, NY 10987 (518) 279-6234wason@wasontech.com --000000000000672a330587d7ea26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = To your latest quest= ion first
>= ;=C2=A0Would it make sense to add support for isochronous data directl= y to the QUIC protocol?=C2=A0

No I don=E2=80=99t think so. Things go into transp= ort if transport can do magic difficult to do elsewhere. Sending repeated e= vents is not that. It would just complicate the core logic.

=
Please note that QUIC v2 has= focus on partial reliability but it is out of scope for v1. You can constr= uct an overlay stream by sending an identifier in stream payload and send e= ach event in a new stream. This avoids head-of-line-blocking (HOL), but it = is clumsy and not always a good solution.

On controlling transmission rate: There are al= gorithms that are sensitive to prioritizing small payload over large payloa= d such that all overall fairness is achieved (FQ scheduler) such as weighed= round robin (WRR)=C2=A0https://en.wikipedia.org/wiki/Network_scheduler<= /div>
An applicaition interfa= ce can receive hints that can guide such a scheduler. The scheduler would b= e implement in the belly of the QUIC transport, but it isn=E2=80=99t part o= f the transport layer protocol per se.
<= span style=3D"font-size:14px">
On visiblity of flow control. See the various pac= kets the stream controllers send to allow more data. Stream based limits ar= e generally for applications that cannot buffr more for the time being whil= e connection level is for overall bandwidth. A receiver can try to manage p= riorities via flow credits, but it probably gets messy.
=

>=C2=A0= I am not sure what you mean by "layer on top of H3=E2=80=9D.

This is the equivalent of a HT= TP 1.1. REST protocol vs a custom/dedicated TCP protocol like FTP.
If you choose H3= your protocol design would be expected to be useful for the majority of QU= IC H3 implementations.
If you choose a lower level protocol directly on the QUIC transport = layer, you are still limited by whatever API=E2=80=99s make available such = as scheduling, but if you can the better choose implementations that are su= itable.
<= br>
Mikkel

On 1 May= 2019 at 19.33.28, John Wason (john= wason1@gmail.com) wrote:

Mikkel,

That makes sense, the order of streams sent shouldn't affect the wire protocol. For the flow control, does the protocol provide information about how much headroom is left? For instance, it may be very important that small, time sensitive streams reach their destination quickly, while there may be larger, slower streams that can wait. If the flow control is not handled correctly, the slower stream could block the fast streams by filling the available bandwidth and buffers.

I am not sure what you mean by "layer on top of H3".

=C2=A0=C2=A0=C2=A0 -John

On 5/1/2019 12:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
QUIC does not prioritise streams at the transport layer, that is an implementation detail although pacing is recommended. If you bring you own application layer protocol you can decide how to schedule data across streams within the flow control constraints. You could add priorities to your application level custom API. If you layer a protocol on top of H3 you are more constrained since you must assume other implementations that won=E2=80=99t necessarily do what you want them to do.


On 1 May 2019 at 18.22.22, John Wason (johnwason1@gmail.com) wrote:

Igor,

It appears I misunderstood the distinction between per-stream partial reliability and intra-stream partial reliability. If I send one partial-reliability message per stream, using RESET frames should be sufficient. How this is exposed as an API is important, since I am not sure the webrtc-quic team has considered this yet. In response to your questions 1) Each message contains a header that should be sufficient for the receiver to understand the incoming stream 2) Does QUIC provide the type of priority that you suggest? My understanding is that QUIC multiplexes streams using a priority based ordering.

If I can emulate partial-reliability using RESET frames to cancel entire streams, that should be sufficient for my needs.

=C2=A0=C2=A0=C2=A0 -John

On 5/1/2019 10:33 AM, Lubashev, Igor wrote:

John,<= /span>

=C2=A0

I am happy to resurrect that draft-lubashev-quic-partial-reliability for QUIC v2 (some people preferred version 02, which actually gets you a bit more features at the cost of a bit more complexity).

=C2=A0

I would like to first understand what partially reliable streams give you that is not available with regular streams.=C2=A0 I.e. what are you missing if you use STREAM (with a possible subsequent RESET) for messages?=C2=A0 (You cannot use DATAGRAM for messages, since you would like the transport to facilitate retransmission until expiration.)

=C2=A0

My draft-lubashev-quic-partial-reliability lists a few things that stream-per-message does not get you:

=C2=A0

  1. I= f you have multiple application message streams, you would need a header for each QUIC stream to identify the application stream.=C2=A0 This seems like a small burden, except for very short messages.
    1. I= f the order of messages in an application stream matters, you would need to reorder them yourself.=C2=A0 This cannot be very complicated for the application.

=C2=A0

  1. Q= UIC per-application-stream flow control is rendered ineffective.=C2=A0 I am actually not a huge fan of QUIC per-stream flow control, as I strongly prefer stream priorities as a signal.=C2=A0 But I now know of a case when per-stream flow control is, indeed useful (when there is only one slow draining stream that uses up the entire connection buffer before a higher-priority stream shows up).

=C2=A0

Are there any other benefits you see in partially reliable streams?

=C2=A0

  • I= gor

=C2=A0

From:= John Wason <johnwason1@gmail.com><= br> Sent: Tuesday, April 30, 2019 5:52 PM
To: Ted Hardie <ted.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC for robotics and other time-sensitive applications

=C2=A0

Thanks Ted, this looks very interesting. Based on these documents the DETNET sits below the level of QUIC that we are currently discussing and would mainly affect the IP header format of the resulting UDP packets. The QUIC protocol will still require some form of partial reliability to function on a DETNET network.

=C2=A0=C2=A0=C2=A0 -John Wason

On 4/30/2019 5:37 PM, Ted Hardie wrote:

Hi John,

=C2=A0

Thanks for the message.=C2=A0 If you have not already reviewed the work of DETNET (https://datatracker.ie= tf.org/wg/detnet/about/) here in the IETF, it might be useful to do so, as there are a number of elements of your use case which appeared to be shared with their work.=C2=A0 In particular, it might be useful to consider whether the integration of their proposed IP data plane (https://datatracker.ietf.org/doc/draft= -ietf-detnet-dp-sol-ip/?include_text=3D1) with QUIC would be valuable in achieving your timing goals.

=C2=A0

=C2=A0

best regard,

=C2=A0

Ted Hardie

=C2=A0

On Tue, Apr 30, 2019 at 12:15 PM John Wason <johnwason1@gmail.com> wr= ote:

Greetings QUIC WG,

The discussion on Issue #92 of webrtc-quic suggested that I post my
requirements to this list.

I am a robotics engineer and the developer of Robot Raconteur, a
communication framework for robotics and automation systems
(https://github.com/robotraconteur/rob= otraconteur). Robotics
applications require different data types and QoS when compared to
business or web applications. Robotics applications need real-time
communication of isochronous data, for instance constant updates on the
position of the joints of the robot, alongside generic
non-time-sensitive data. Currently most robotics applications are using
TCP (Robot Raconteur, ROS*, OPC/UA), UDP (DDS, ROS2, ROS*), or some form
of custom Ethernet protocol (Ethernet/IP, EtherCAT, PowerLink). To add
more confusion to the situation, there is the recent introduction of
IEEE 802.1Q Time Sensitive Networking (TSN) which claims to allow TCP
and UDP to achieve hard real-time performance.

While there are many robotics protocols out there, only Robot Raconteur
and OPC/UA are compatible with existing web and cloud infrastructure.
(Some limited support for ROS/ROS2 has become available on AWS, but the
design of ROS does not play very well outside of local networks.*) Robot
Raconteur implements web browser and web server support by allowing the
websocket protocol to be used. Clients can use a URL that specifies that
the connection is a websocket, and incoming TCP connections can detect
if the connection is the Robot Raconteur protocol or an incoming
websocket connection. Robot Raconteur running inside an ASP.NET web=
server has been demonstrated, and there is no technical reason that
other server technologies cannot accept Robot Raconteur connections
through websockets. (OPC/UA uses SOAP for its web based transport, but
support is very poor and only available in a few implementations.)

The main issue limiting Robot Raconteur for more demanding applications
is the use of TCP for data transport. TCP suffers from "head-of-line"
blocking, which means that if stale data encounters an error it can stop
fresh data from reaching the other peer. There is also the problem of
large messages blocking the transmission of smaller, more time sensitive
messages on the connection. QUIC appears to solve most of these
problems, and the webrtc-quic support under development provides a lot
of new and interesting opportunities for integrating robotics
applications with web technology. By adopting QUIC, the resulting
software will remain completely compatible with web infrastructure.

Transmitting time-sensitive data requires the ability to multiplex (and
prioritize) messages and drop messages if the data contained becomes
stale. The multiplexing issue is solved using the "streams as messages"
concept in QUIC, with built in priority handling. This design looks very
promising, and considerably simpler to use compared to SCTP streams. The
current issue that is somewhat questionable is the implementation of
partial reliability. The discussion right now is focused on DATAGRAM
extensions (draft-pauly-quic-datagram-02), which allow for "raw" access
to the socket so protocols such as RTP can tunnel through QUIC. This
requirement is quite a bit different than what is required for an
application like Robot Raconteur. Robot Raconteur is based on message
passing, where either the entire message is received or the entire
message is cancelled because the data contained is stale. The message
may be considerably larger than MTU, and the QoS may be "partial,"
meaning that a set number of attempts may be made to resend, and/or
there is an expiration time on the message. This capability is discussed
in draft-lubashev-quic-partial-reliability-03, and is similar to how
SCTP handles partial reliability. If only a raw DATAGRAM capability is
provided, then partial reliability will need to be built on top of QUIC,
defeating the purpose of using QUIC for this application. Other
applications such as online gaming have very similar performance
requirements, so I think that the partial reliability capability will be
important to many future users.

The complexity and required effort to add the partial reliability
capability to QUIC is low, so I hope that this capability is not abandoned.

Robot Raconteur has received a grant from the United States ARM
Institute and New York State to begin commercializing the technology.
This project will be done in partnership with Wason Technology, LLC,
Rensselaer Polytechnic Institute, Southwest Research Institute, and
United Technologies Research Center. The project starts soon, and
considerable development effort will be invested in the Robot Raconteur
technology starting early summer. Integrating QUIC is one of the tasks
that I hope to undertake during this project.

Please let me know if you have any questions about Robot Raconteur or
the requirements for QUIC in robotics applications.

=C2=A0=C2=A0=C2=A0=C2=A0 -John Wason

(* I am aware that there are some caveats to how ROS/ROS2 interact with
the wider world, but the technologies are not built on or compatible
with web standards so an in depth discussion is not relevant for the
current topic. ROS does have a UDP transport, but it is not commonly used.)

--
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.co= m

-- 
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
wason@wasontech.com
--  =20
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
w=
ason@wasontech.com
-- =20
John Wason, Ph.D.
Wason Technology, LLC
16 Sterling Lake Rd
Tuxedo, NY 10987
(518) 279-6234
w=
ason@wasontech.com
--000000000000672a330587d7ea26-- From nobody Wed May 1 12:40:44 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 BE7621201B8 for ; Wed, 1 May 2019 12:40:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3ALDmK1LGfV for ; Wed, 1 May 2019 12:40:41 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 41143120149 for ; Wed, 1 May 2019 12:40:41 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id v141so52648vsc.5 for ; Wed, 01 May 2019 12:40:41 -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=0XUMDZn2GdY/ikdlKrMIikDec04IvFtVEVO6ljDrhhM=; b=BSxd7RYc5afk6AXI6GerM2FJKfgU6Se2Scejkcu8Ry7vY4Z/zehfDGNxnPM6/pIPYi jYFFR6aVDMVlmBXba/Zamu3AgL2jQpUDXd99nm09T2J2/6QBcaRNE6kfW9ugT2FEyJuT YG0OuHRP8V/8peohiFAS2YVuciADfQ9ZDBXoHMITWyIhB6VxhsIGxENjVlwVgXtb6Jed LpT/QrcOSKVZfNFXISG14BMT795lZCdOwOCzM2hffYlZhO/Sh4OKuiMDl0nebzrvMEo0 m3S/u4C7+cBfvpjFSCrBSd66QU8ca1jiRlAc7vTuNTWIRiAkkilSA0ss3FXVKTfuUUU5 MvcQ== 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=0XUMDZn2GdY/ikdlKrMIikDec04IvFtVEVO6ljDrhhM=; b=P35kjtP2Z733iBiZJ+lRm+lHFCK1pEc2o15CqTOmLWkQlV68axKJAiZbeDew0+kIJa K0a1N+W3D/Pg/B4DqYVlsMvaJPdJ5GTfzKYXQCNhPsOBtLQZCF/qj5fYzeWrOC/LTVnx XCM1QugtPGWlwXckeWvwRJURzQO1+RVmkbDmxlT6u97uPGdCI/Rbl6Q3732VTcLoE3nE c5hEqhitCRMnhI9U4OaVchj+pc+TOR1vo0iTO+MGgwcnXbsIVq4jPCi2OzEpk3IglAnr 6yvgyMezyXSi1EUTXqe1EyXGPCNCaG1JqQUWM59VxrUc8hwTzZbslzyugF3F1Mb32TzM 2afA== X-Gm-Message-State: APjAAAXdKBrs4cXXcqsC4WU2CWtTkSNVByIw/nIYp2IsDz2qHmob/UsG Jb4+YWdes67qxcQvVfSD2dWhjAdPPEkBrhJctoM= X-Google-Smtp-Source: APXvYqxIjsK/HReQrB97Y/8EsknA5KfvKUC33ZWSeALlEDKyQQmlYXNI+Y88/UEfx5UsHzM69XkGKbTLmmXuQZ2IAlU= X-Received: by 2002:a67:af0a:: with SMTP id v10mr1228633vsl.27.1556739640303; Wed, 01 May 2019 12:40:40 -0700 (PDT) MIME-Version: 1.0 References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> <3c34ef0d-40ae-3ec0-6a60-2da4dab1b339@gmail.com> In-Reply-To: From: Lucas Pardue Date: Wed, 1 May 2019 20:40:27 +0100 Message-ID: Subject: Re: QUIC for robotics and other time-sensitive applications To: John Wason Cc: "Lubashev, Igor" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Ted Hardie , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000044a5170587d8b16f" 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, 01 May 2019 19:40:43 -0000 --00000000000044a5170587d8b16f Content-Type: text/plain; charset="UTF-8" Hi John, On Wed, 1 May 2019, 19:28 John Wason, wrote: > Would it make sense to add support for isochronous data directly to the > QUIC protocol? DDS has the ability to set the requested update rate and QoS > of different topics. My plan has been to emulate this functionality using > streams at the application layer, but I am thinking now that there may be > some benefit to having specialized flow control and QoS capabilities for > this type of data. > I used to use DDS (assuming you mean Data Distribution Service). The abilities you mention came up recently is a side discussion abouit the DATAGRAM frame and transport-service API (aks IETF TAPS). I shared a link to a mammothe slide pack with some people at the time which explains some DDS things, for convenience, here it is: https://www.omg.org/news/meetings/workshops/RT-2007/00-T5_Hunt-revised.pdf The DATAGRAM frame alone won't satisfy all requirements (or at least not without some duplication in higher levels). I too am interested in partial reliability of streams, in some form, in future versions of QUIC. A DDS over QUIC application mapping document seems like the correct place to express how transport capabilities map to DDS features. I wonder if such a thing will ever emerge.. Tangent: The particular flavour of DDS I used, based on top of UDP, had some clever approaches for choosing when to deliver samples over via unicast or multicast IP. I have a multicast HTTP/3 over QUIC independent draft, I would assume some of the concepts could transfer to DDS. Lucas --00000000000044a5170587d8b16f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

On Wed, 1 May 2019, 19:28 Joh= n Wason, <john= wason1@gmail.com> wrote:
=20 =20 =20

Would it make sense to add support for isochronous data directly to the QUIC protocol? DDS has the ability to set the requested update rate and QoS of different topics. My plan has been to emulate this functionality using streams at the application layer, but I am thinking now that there may be some benefit to having specialized flow control and QoS capabilities for this type of data.

I used to = use DDS (assuming you mean Data Distribution Service). The abilities you me= ntion came up recently is a side discussion abouit the DATAGRAM frame and t= ransport-service API (aks IETF TAPS). I shared a link to a mammothe slide p= ack with some people at the time which explains some DDS things, for conven= ience, here it is:=C2=A0


The DATAGRAM frame alone won't satisfy all requirements = (or at least not without some duplication in higher levels). I too am inter= ested in partial reliability of streams, in some form, in future versions o= f QUIC.=C2=A0

A DDS over= QUIC application mapping document seems like the correct place to express = how transport capabilities map to DDS features. I wonder if such a thing wi= ll ever emerge..

Tangent= :
The particular flavour of DDS I used, based on top= of UDP, had some clever approaches for choosing when to deliver samples ov= er via unicast or multicast IP. I have a multicast HTTP/3 over QUIC indepen= dent draft, I would assume some of the concepts could transfer to DDS.

Lucas
--00000000000044a5170587d8b16f-- From nobody Wed May 1 12:44: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 C3CFE12020A for ; Wed, 1 May 2019 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 pGTanFLdNiad for ; Wed, 1 May 2019 12:44:09 -0700 (PDT) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (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 214F71201B8 for ; Wed, 1 May 2019 12:44:09 -0700 (PDT) Received: by mail-oi1-f176.google.com with SMTP id n187so14615864oih.6 for ; Wed, 01 May 2019 12:44:09 -0700 (PDT) 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=bTW9L+gSVsKSvIAh1OgqiT7fJGCgkjdi91i0AA8hj08=; b=CPmEYS/coypUWiRrOXCNMnoIDL/C+Az2MG5GSCeSgz4yZ2YTGfEOhM7o1hSMS4fdig S7779rRLjXB//iYXz0qWEk5+Qy79GgFpbr87neHgH5qO55Lfo8vGqmeOVt2lR8SLtrkb 65/zTuDlqcyzHI/Tfan9ujW/iJJmO7YJN5dNvZyZ8Vo6tFm9WwDPuvAAwrv8ARI++ril Fa/YpiWMoD6dXm8OO+jyyU8xPP5RAqCOd0kXmxwR0c7rtLe5GgBOberOKs4xtnzNZKae jLNman01XzFFx7VxVC0Ofb5c/C5UEHxViPl9lv5IIwJppt4khk4134WQivpwXYrgKFe4 jISw== X-Gm-Message-State: APjAAAWwfAYcjV2X17sIjfBE3S5BKm63D7Pr53ahY1Q0PiqxEhT9Py4B aO8PkwlkUt1RMYftT+fPI70RpU3LG4ov6SI+/cQ= X-Google-Smtp-Source: APXvYqxYzrbEEZznw1X/2DBloiLBBEzwxVQQ4FClqrhwHr+ea5He5SocJ9P9oyKIe7h5J/O/gdBrHuGlpUJIas42B34= X-Received: by 2002:aca:4a10:: with SMTP id x16mr14388oia.58.1556739848367; Wed, 01 May 2019 12:44:08 -0700 (PDT) MIME-Version: 1.0 References: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> In-Reply-To: <542b6445-de16-8b13-4ffc-f1ca46c535da@gmail.com> From: Phillip Hallam-Baker Date: Wed, 1 May 2019 15:43:59 -0400 Message-ID: Subject: Re: QUIC for robotics and other time-sensitive applications To: John Wason Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000ab71a30587d8bd27" 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, 01 May 2019 19:44:11 -0000 --000000000000ab71a30587d8bd27 Content-Type: text/plain; charset="UTF-8" I am a big fan of QUIC. I think it meets an important set of requirements. But are those requirements so general that it amounts to a replacement for TCP/IP in every context? I don't think so and I think it would be a very bad idea to attempt to address every problem with the same toolkit. Looking at the specifics of your problem, I have two major questions: 1) How big do the control messages need to be? 2) How big do the data stream messages need to be? I am looking at a robotics control application but it is hardly a critical one. I have this dalek in my office that I would like to be able to control from various devices and autonomously to a limited degree. It has a camera in its eyestalk and various telemetry data is developed. So QUIC does look kinda sorta relevant. But is the effort required to try and fit my application into the QUIC paradigm really worth making? Could I do just as well by simply splitting the control and data streams? I know that every control message is less than 64KB (much less infact). Looking at the Web Services space, I find QUIC doesn't fit too well there either. In particular, I note that for all my latency critical Mesh applications, the request message is less than 8K and usually less than 1K. So I can use UDP without any need to support request reassembly. Which means I can support most of my information retrieval applications currently implemented over HTTPS over a lighter weight UDP protocol that is stateless on the server side. Message reassembly is expensive on the server side but not an issue on the client side. So one UDP request can result in multiple UDP responses. So I think we should be skeptical before deciding QUIC is the new hammer to be used to beat every nail. HTTPS is a poor match for Web Services because: * The HTTP layer basically provides no value except for allowing multiple services to be multiplexed on a single port. * TCP/IP startup time introduces latency * Vulnerable to DDoS (TCP/IP SYN flooding, TLS key exchange) * QUIC is very complex. The concerns that motivate QUIC are similar but really not the same as for Web Services. And that is OK. We don't have to use the same hammer for every problem. There are some Web Services that will layer really nicely on QUIC (but maybe not this iteration or the next). There are other Web Services that don't and won't. --000000000000ab71a30587d8bd27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m a big fan of QUIC. I think it meets an important set of requirements.

But are those requirements s= o general that it amounts to a replacement for TCP/IP in every context? I d= on't think so and I think it would be a very bad idea to attempt to add= ress every problem with the same toolkit.

Looking at the specifics of your problem, I have two major= questions:
1) How big do= the control messages need to be?
2) How big do the data stream messages need to be?

I am looking at a robotics c= ontrol application but it is hardly a critical one. I have this dalek in my= office that I would like to be able to control from various devices and au= tonomously to a limited degree. It has a camera in its eyestalk and various= telemetry data is developed.

So QUIC does look kinda sorta relevant. But is the effort required to = try and fit my application into the QUIC paradigm really worth making? Coul= d I do just as well by simply splitting the control and data streams? I kno= w that every control message is less than 64KB (much less infact).

Looking at the Web Services space= , I find QUIC doesn't fit too well there either. In particular, I note = that for all my latency critical Mesh applications, the request message is = less than 8K and usually less than 1K. So I can use UDP without any need to= support request reassembly. Which means I can support most of my informati= on retrieval applications currently implemented over HTTPS over a lighter w= eight UDP protocol that is stateless on the server side. Message reassembly= is expensive on the server side but not an issue on the client side. So on= e UDP request can result in multiple UDP responses.

So I think we should be skeptical before decidin= g QUIC is the new hammer to be used to beat every nail. HTTPS is a poor mat= ch for Web Services because:

* The HTTP layer basically provides no value except for allowing multip= le services to be multiplexed on a single port.=C2=A0

* TCP/IP startup time introduces latency
=

* Vulnerable to DDoS (TCP/IP S= YN flooding, TLS key exchange)

* QUIC is very complex.

The concerns that motivate QUIC are similar but really not the same as= for Web Services. And that is OK. We don't have to use the same hammer= for every problem. There are some Web Services that will layer really nice= ly on QUIC (but maybe not this iteration or the next). There are other Web = Services that don't and won't.
--000000000000ab71a30587d8bd27-- From nobody Wed May 1 13:42: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 5DF49120094 for ; Wed, 1 May 2019 13:42:09 -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 t8avfhw5gsws for ; Wed, 1 May 2019 13:42:06 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710127.outbound.protection.outlook.com [40.107.71.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA4B120021 for ; Wed, 1 May 2019 13:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pI7yaWKo3azwBa5rXR6vBoWmQW7C0qCh/cF8+juPXRU=; b=CpdSbjTwaJFvJwRu7j03Ep45AsBkj4ruJdzL0qxueAiit9TQVXW+2EVmrTSw/MDWUojvN56g8NwPteLVf1nXaozbBMf6lhgW7Lb0KRAtzAx+Ych0vT7CvHWLzxuoDG+5PTrlPY0pvRsZUDH0faMK/HvhaLq4YSHWsHPZwNICht8= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0341.namprd22.prod.outlook.com (10.173.190.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Wed, 1 May 2019 20:42:04 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::5e:10a3:8225:425]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::5e:10a3:8225:425%5]) with mapi id 15.20.1856.008; Wed, 1 May 2019 20:42:03 +0000 From: Mike Bishop To: Martin Duke , Marten Seemann CC: QUIC WG , Martin Thomson Subject: RE: Connection ID Space Thread-Topic: Connection ID Space Thread-Index: AQHU/Hke5LQf5oR0tESJhMqZbEzX16ZPCC6AgABbDoCABZxCoIAAchSAgADJiQCAACEpgIAABAGAgAA0UQCAAC5nAA== Date: Wed, 1 May 2019 20:42:03 +0000 Message-ID: References: <2d1ff788-399f-4a20-9dda-82b159398b60@www.fastmail.com> <20190501123305.GA5964@ubuntu-dmitri> 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: 36774872-4c2d-40a2-bdfe-08d6ce7577fc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR22MB0341; x-ms-traffictypediagnostic: CY4PR22MB0341: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39830400003)(136003)(366004)(346002)(199004)(189003)(52314003)(52536014)(66946007)(66556008)(66476007)(73956011)(8936002)(66446008)(64756008)(14444005)(186003)(256004)(76116006)(86362001)(4326008)(25786009)(7116003)(99286004)(68736007)(53936002)(66066001)(508600001)(6436002)(6116002)(14454004)(476003)(3846002)(54896002)(316002)(74316002)(446003)(33656002)(81156014)(486006)(7696005)(8676002)(81166006)(55016002)(9686003)(6306002)(6246003)(26005)(11346002)(110136005)(229853002)(54906003)(3480700005)(102836004)(53546011)(6506007)(5660300002)(7736002)(790700001)(236005)(76176011)(71190400001)(71200400001)(74482002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0341; 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: y5tvdRT54QHbD8tqpumXZRgCDV2MR2zhonu2qmsy91ZvelSFBuNyrgQNAftY5gTTZcy5BRYhMXDM/o4/3QSP+Nw3DoMVn1Bzcs5xBrUPqqkn0WOofmMspEMw6mGTlL3v5bQKw+ljaj7fUx6WR5ZHqMPuNkg6arOsIklygEx+pbfceybm24VnqnMXrL1rJBkemj3n0hnrsTnBES4CGVslaYBcbjrkZ9e0tBCS1cMHmjT3Pch1i6pqOll33CWd4ODNKCOdwv/e6bVJfMpMjG/lh0Wd8AIHPfRzC+CEMxO85KPeosg7VP6K5/GTEfRZST90zac9/PWS6w+MskoyJSAA85If7AagLZHpU+c8FP6FalsyZ+ZlDkTDAYmYgID5Y/aqn0YrZhfkQLw5MDu3UwjkmkHWElS/Hk3J2lgqRXNPtcU= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983E15F761FA29DA09A1388DA3B0CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 36774872-4c2d-40a2-bdfe-08d6ce7577fc X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2019 20:42:03.7490 (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-Transport-CrossTenantHeadersStamped: CY4PR22MB0341 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, 01 May 2019 20:42:10 -0000 --_000_CY4PR22MB0983E15F761FA29DA09A1388DA3B0CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW9yZSBsaWtlIGZ1dHVyZSBRVUlDIHZlcnNpb25zIGNhbiBkZWZpbmUgYW55dGhpbmcgdGhleSBs aWtlIGluIHRoZSBkZWZpbml0aW9uIG9mIHRoZSB2ZXJzaW9uLiAgVGhhdCBtaWdodCBpbmNsdWRl IGEgbmVnb3RpYXRpb24sIG9yIGl0IG1pZ2h0IHNpbXBseSBiZSB0aGF0IHRoZSB2ZXJzaW9uIHdv dWxkIGRlY2xhcmUgdGhhdCBtdWNoIGxhcmdlciBDSURzIGFyZSBmaW5lIHdpdGggYXBwcm9wcmlh dGUgd2F5cyBvZiBleHByZXNzaW5nIHRoZW0uICBUaGVyZSBqdXN0IG5lZWRzIHRvIGJlIGEgdHJh bnNpdGlvbiBwYXRoIGZyb20gdGhlIENJRHMgZXN0YWJsaXNoZWQgaW4gdGhlIGhhbmRzaGFrZS4g IEFuZCB5ZXMsIGV2ZXJ5dGhpbmcgbmVlZGVkIGZvciB0aGlzIGlzIGFscmVhZHkgaW4gLWludmFy aWFudHMuDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IE1hcnRpbiBEdWtlDQpTZW50OiBXZWRuZXNkYXksIE1heSAxLCAyMDE5IDEwOjUzIEFNDQpUbzog TWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPg0KQ2M6IFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8bXRAbG93ZW50cm9weS5uZXQ+DQpTdWJqZWN0 OiBSZTogQ29ubmVjdGlvbiBJRCBTcGFjZQ0KDQpBbGxvd2luZyBsb25nZXIgQ0lEcyBpbiBzaG9y dCBoZWFkZXJzIGF0IGxlYXN0IHBhcnRpYWxseSBtaXRpZ2F0ZXMgdGhpcy4gSXMgdGhlIHRoZW9y eSB0aGF0IGZ1dHVyZSB2ZXJzaW9ucyB3b3VsZCBuZWdvdGlhdGUgdGhpcyBpbiB0aGUgaGFuZHNo YWtlLCBzbyBldmVyeSBzaG9ydCBoZWFkZXIgd291bGQgaGF2ZSB0aGUgbG9uZ2VyIENJRD8NCg0K T24gV2VkLCBNYXkgMSwgMjAxOSBhdCA3OjQ2IEFNIE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVt YW5uQGdtYWlsLmNvbTxtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20+PiB3cm90ZToNCklm IEkgcmVtZW1iZXIgY29ycmVjdGx5LCB3ZSBtYWRlIGFsbCB0aGUgcmVxdWlyZWQgY2hhbmdlcyBm b3IgdGhhdCB0byB0aGUgaW52YXJpYW50cy4gVGhlIGNvbm5lY3Rpb24gSUQgbGVuZ3RocyBhcmUg b25seSBpbnZhcmlhbnQgZm9yIExvbmcgSGVhZGVyIHBhY2tldHMuIFRoZSBjb25uZWN0aW9uIElE IGZvciBTaG9ydCBIZWFkZXIgcGFja2V0cyBjYW4gaGF2ZSBhbnkgbGVuZ3RoLCBzbyBhIG5ldyBR VUlDIHZlcnNpb24gKG9yIGEgUVVJQyBleHRlbnNpb24pIGNvdWxkIGRlZmluZSBjb25uZWN0aW9u IElEcyBpbiB0aGUgU2hvcnQgSGVhZGVyIHRvIGhhdmUgbGVuZ3RocyB0aGF0IGFyZSBub3QgZW5j b2RhYmxlIGluIHRoZSAwLzQtMTggc2NoZW1lLg0KDQpPbiBXZWQsIE1heSAxLCAyMDE5IGF0IDEx OjMxIFBNIE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldDxtYWlsdG86bXRAbG93ZW50 cm9weS5uZXQ+PiB3cm90ZToNCk9uIFdlZCwgTWF5IDEsIDIwMTksIGF0IDE0OjMzLCBEbWl0cmkg VGlraG9ub3Ygd3JvdGU6DQo+IE9uIFR1ZSwgQXByIDMwLCAyMDE5IGF0IDA4OjMxOjQ3UE0gLTA0 MDAsIE1hcnRpbiBUaG9tc29uIHdyb3RlOg0KPiA+IFRoYXQncyBvbiB0aGUgVE9ETyBsaXN0IGFu eXdheSwgYXMgd2UgYWdyZWVkIHRvIHJlbW92ZSB0aGUNCj4gPiAwLzQtMTggcmVzdHJpY3Rpb24g Zm9yIHRoZSBzaG9ydCBwYWNrZXQgaGVhZGVyIGEgd2hpbGUgYmFjay4NCj4NCj4gSSBkbyBub3Qg cmVjYWxsIC0tIHdoZW4gd2FzIHRoYXQgZGVjaWRlZD8NCg0KSXQgd2FzIGluIHJlbGF0aW9uIHRv IGEgcmVxdWVzdCBmb3IgYSAqc21hbGxlciogY29ubmVjdGlvbiBJRC4gIE1hcnRlbiBtaWdodCBy ZW1lbWJlciBiZXR0ZXIgdGhhbiBJLg0K --_000_CY4PR22MB0983E15F761FA29DA09A1388DA3B0CY4PR22MB0983namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N b3JlIGxpa2UgZnV0dXJlIFFVSUMgdmVyc2lvbnMgY2FuIGRlZmluZSBhbnl0aGluZyB0aGV5IGxp a2UgaW4gdGhlIGRlZmluaXRpb24gb2YgdGhlIHZlcnNpb24uJm5ic3A7IFRoYXQgbWlnaHQgaW5j bHVkZSBhIG5lZ290aWF0aW9uLCBvciBpdCBtaWdodCBzaW1wbHkgYmUgdGhhdCB0aGUgdmVyc2lv biB3b3VsZCBkZWNsYXJlIHRoYXQgbXVjaCBsYXJnZXIgQ0lEcyBhcmUgZmluZSB3aXRoIGFwcHJv cHJpYXRlIHdheXMNCiBvZiBleHByZXNzaW5nIHRoZW0uJm5ic3A7IFRoZXJlIGp1c3QgbmVlZHMg dG8gYmUgYSB0cmFuc2l0aW9uIHBhdGggZnJvbSB0aGUgQ0lEcyBlc3RhYmxpc2hlZCBpbiB0aGUg aGFuZHNoYWtlLiZuYnNwOyBBbmQgeWVzLCBldmVyeXRoaW5nIG5lZWRlZCBmb3IgdGhpcyBpcyBh bHJlYWR5IGluIC1pbnZhcmlhbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9i Pg0KTWFydGluIER1a2U8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMSwgMjAxOSAx MDo1MyBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGVuIFNlZW1hbm4gJmx0O21hcnRlbnNlZW1hbm5A Z21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs7IE1hcnRpbiBUaG9tc29uICZsdDttdEBsb3dlbnRyb3B5Lm5ldCZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IENvbm5lY3Rpb24gSUQgU3BhY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsbG93aW5nIGxvbmdlciBDSURzIGluIHNob3J0IGhlYWRlcnMgYXQgbGVhc3QgcGFy dGlhbGx5IG1pdGlnYXRlcyB0aGlzLiBJcyB0aGUgdGhlb3J5IHRoYXQgZnV0dXJlIHZlcnNpb25z IHdvdWxkIG5lZ290aWF0ZSB0aGlzIGluIHRoZSBoYW5kc2hha2UsIHNvIGV2ZXJ5IHNob3J0IGhl YWRlciB3b3VsZCBoYXZlIHRoZSBsb25nZXIgQ0lEPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgMSwgMjAxOSBhdCA3OjQ2IEFNIE1hcnRl biBTZWVtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb20iPm1h cnRlbnNlZW1hbm5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgSSByZW1lbWJl ciBjb3JyZWN0bHksIHdlIG1hZGUgYWxsIHRoZSByZXF1aXJlZCBjaGFuZ2VzIGZvciB0aGF0IHRv IHRoZSBpbnZhcmlhbnRzLiBUaGUgY29ubmVjdGlvbiBJRCBsZW5ndGhzIGFyZSBvbmx5IGludmFy aWFudCBmb3IgTG9uZyBIZWFkZXIgcGFja2V0cy4gVGhlIGNvbm5lY3Rpb24gSUQgZm9yIFNob3J0 IEhlYWRlciBwYWNrZXRzIGNhbiBoYXZlIGFueSBsZW5ndGgsIHNvIGEgbmV3IFFVSUMgdmVyc2lv bg0KIChvciBhIFFVSUMgZXh0ZW5zaW9uKSBjb3VsZCBkZWZpbmUgY29ubmVjdGlvbiBJRHMgaW4g dGhlIFNob3J0IEhlYWRlciB0byBoYXZlIGxlbmd0aHMgdGhhdCBhcmUgbm90IGVuY29kYWJsZSBp biB0aGUgMC80LTE4IHNjaGVtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFdlZCwgTWF5IDEsIDIwMTkgYXQgMTE6MzEgUE0gTWFydGluIFRob21zb24g Jmx0OzxhIGhyZWY9Im1haWx0bzptdEBsb3dlbnRyb3B5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm10 QGxvd2VudHJvcHkubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPk9uIFdlZCwgTWF5IDEsIDIwMTksIGF0IDE0OjMzLCBEbWl0cmkgVGlraG9ub3Ygd3JvdGU6 PGJyPg0KJmd0OyBPbiBUdWUsIEFwciAzMCwgMjAxOSBhdCAwODozMTo0N1BNIC0wNDAwLCBNYXJ0 aW4gVGhvbXNvbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgVGhhdCdzIG9uIHRoZSBUT0RPIGxpc3Qg YW55d2F5LCBhcyB3ZSBhZ3JlZWQgdG8gcmVtb3ZlIHRoZTxicj4NCiZndDsgJmd0OyAwLzQtMTgg cmVzdHJpY3Rpb24gZm9yIHRoZSBzaG9ydCBwYWNrZXQgaGVhZGVyIGEgd2hpbGUgYmFjay48YnI+ DQomZ3Q7IDxicj4NCiZndDsgSSBkbyBub3QgcmVjYWxsIC0tIHdoZW4gd2FzIHRoYXQgZGVjaWRl ZD88YnI+DQo8YnI+DQpJdCB3YXMgaW4gcmVsYXRpb24gdG8gYSByZXF1ZXN0IGZvciBhICpzbWFs bGVyKiBjb25uZWN0aW9uIElELiZuYnNwOyBNYXJ0ZW4gbWlnaHQgcmVtZW1iZXIgYmV0dGVyIHRo YW4gSS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR22MB0983E15F761FA29DA09A1388DA3B0CY4PR22MB0983namp_-- From nobody Thu May 2 00:16:15 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 7C0531202FB for ; Thu, 2 May 2019 00:16:13 -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=VXLxn5Zp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wqoaprar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcWNrJN2Oqge for ; Thu, 2 May 2019 00:16:11 -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 0E9441202F9 for ; Thu, 2 May 2019 00:16:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 18A4F23281; Thu, 2 May 2019 03:16:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 02 May 2019 03:16:10 -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=t pbyz3GMDpD2XsrqgsKZeE9AfvAYI2ri9tSAjIzRbnA=; b=VXLxn5Zphum9ksjDu ZmfUgID3eiWZG17xy8mysgw0MvZWPS01wb5liezqEQurQKSBljbZSRgG6FWPDtnH Q4a7UDZP3SkdE+18JQOq4xGVBG32So712I3tqUcZyXSeiM7SM+jGfo6Szxcs722o hv5HmAlMLrx68vlPv5e0IP/ZRrvson+IZjI9nsdLKitzpNxzX9CqgRe9HB45e7TO W9NjThsGJLk4zISaW1RP3EfVuukQo/psqaocDzhVVW3MndUib+Zf/dLAA5JHFFl9 orbG6ZHfaGX2v/xmIJI6UiJtxK24TxZsGDLD/TeOLnbG2ulSPSngyNNwBrrSiRBJ mvo6Q== 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=tpbyz3GMDpD2XsrqgsKZeE9AfvAYI2ri9tSAjIzRb nA=; b=WqoaprarMOXoPLm/8tTZEdiUJqLXqkdFIvRRe82PtDzzDy7h9GMEttz2b FwyVozxsBjthpFcrHpjFt+Hq84zmxm031AyninkbQFUqxMEfOnlvBMeUgcmp1rQh 560oJqwjY81g/13KRA3lSFXLFBvclECcUyxZ/HEQt0gHdddO8PsBBUPwAKKXSsWl AN7/CVgWRpkHpl3qo11DYBswx091d/465CKS8yfugLeP0NCQ0I2GETOd6nLsaFax uWBQS5z1Oz8iqi+GqfvE019FTpTZSNQOs7fILrGRdXiG7frAjnsO1borchxx1znB hkotOdedJkxTk2nD6ARc2wfH3xqtg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 4151F10369; Thu, 2 May 2019 03:16:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Consensus Call: endpoints don't know how many connection IDs the peer is willing to store #1994 From: Mark Nottingham In-Reply-To: <6660ECD9-CBFD-4980-8454-B595633CA30E@mnot.net> Date: Thu, 2 May 2019 17:16:04 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <4BAA5B73-ACCF-4AFB-84E8-AD6A6A80CA36@mnot.net> References: <6660ECD9-CBFD-4980-8454-B595633CA30E@mnot.net> To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.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: Thu, 02 May 2019 07:16:13 -0000 Hearing no pushback, consensus declared. > On 24 Apr 2019, at 5:02 pm, Mark Nottingham wrote: >=20 > 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 Thu May 2 00:17: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 AD0C31202FF for ; Thu, 2 May 2019 00:16:42 -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=hpazrgeh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=euEoKYe5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZqY6fyMiOeO for ; Thu, 2 May 2019 00:16:40 -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 47D841202FC for ; Thu, 2 May 2019 00:16:40 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4074923382; Thu, 2 May 2019 03:16:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 02 May 2019 03:16:39 -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=R Q3PlnyKIeyRKZ9YO5fW7Ad0zptERpFQU/96GCPEF2Q=; b=hpazrgehHfP/9UHli GlGB42sizM6YdWI0Ecm7/rb3JGpVR7XLlynUUd/hYHoE6It4/2RK8a5R3xZE/oep YBmuwi3bbYMsnMmhnPoKn5wBFnkleqbYUbNjH1M4u3YtV/Xc7RnK7ICflq/qHUyS wK4oUHlOEQRLMrtEwhxAcnv/K9StWMPnyRBacxDOs+hV9TeNUUHjqolIjy1dAwO/ VQ0wADC6rBsee8J0wQvV4qW2b9MLp5/q6Z2m7+CfxWI9jyv3l2x4Md4PhVvJmHYN tB06b4x4EHjih2JyTU8X6gPlhCyJAnAOi7ZUxlTplHfB9hoyclhH9RUx6nh5Rht4 rjaNg== 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=RQ3PlnyKIeyRKZ9YO5fW7Ad0zptERpFQU/96GCPEF 2Q=; b=euEoKYe5gqfys63QoTcuRqjHg9dOeRwUzZ+RO2ayyIYzXVDbnhUrKhpHz Be+Kcp7mOXyCoBa3cEHk5jW6jnXeZr94+kBg0D5hJfBKrESPoGpFFiIeUg5r2jFM Mjf73OkBBUKG3m8a3z7kqRIy4RdJfjOEtkO9i6kVD6y+O9lU50t+O69Z0Y0LeMH7 AVACeBTqD7ReTvJJS+Q8wH4oOKJZeUars2hOjufIsKdFsADICO4Hbliy4TRhNXF+ BXC9KlHaaOSHc/D4/ZEWjpjRUrhc+r7bAc9enEyOuj3W+8oAH9JFoRw2SL2Wi4sI uqaN9M874Nfw4PeWRnmB9GvS9gj1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id C73821037C; Thu, 2 May 2019 03:16:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Consensus Call: MAX_PACKET_SIZE frame #2545 From: Mark Nottingham In-Reply-To: <5C3EEB14-9461-4CBB-967B-6EBC7D3F3E07@mnot.net> Date: Thu, 2 May 2019 17:16:37 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <9FE0703E-12ED-4316-9935-383A2468AA25@mnot.net> References: <5C3EEB14-9461-4CBB-967B-6EBC7D3F3E07@mnot.net> To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.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: Thu, 02 May 2019 07:16:43 -0000 Hearing no pushback, consensus declared. > On 23 Apr 2019, at 5:44 pm, Mark Nottingham wrote: >=20 > And again, now with Title. >=20 >> On 23 Apr 2019, at 5:28 pm, Mark Nottingham wrote: >>=20 >> Regarding: >> >>=20 >> There seems to be consensus on the issue to close it as out-of-scope = for QUICv1; while it's labeled QUICv2, that is not a commitment to work = on it in the future, just an indication of interest. >>=20 >> 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 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu May 2 00:18: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 8EBB8120313 for ; Thu, 2 May 2019 00:17:58 -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=iFzdXciO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lZe5nm3D Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdz7pv33wHRt for ; Thu, 2 May 2019 00:17:56 -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 A1C32120300 for ; Thu, 2 May 2019 00:17:55 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9053623648; Thu, 2 May 2019 03:17:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 02 May 2019 03:17:54 -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=B O7q5H5U+Hribvk8l3Q1wwoDFy7KAldopJY4mzD+DiA=; b=iFzdXciOj5IdEgkVU H7MyNs8DwA6fmdYYAoGgFlSBRR6DWGBVU2eq0rTwSrJtYZuTexdcZh/cuGKbd/D3 QuYF3oIdDYnYGhnqzwgGSRgaeM2vO7AHBNouVGZ1uo1XPypkz/83XIlCNjW623E5 cOO6hxatmc4RYbtx+9GH+r4mc1t0NDzYirchAL5R5SZtIESD/vpI2uQcFp3DFgyJ yR4RMlyNqvm90fm1wkv14SJRg1X6F27VrtaEYV/A+SI/H3g5fU2v6dXcoBIbOsJW wYbqrprjWGphlgzHMRpuNzsrv7gNWrZT5b38+V+Kiy6Py8mT243QCIaDoCbF6TpK glEqg== 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=BO7q5H5U+Hribvk8l3Q1wwoDFy7KAldopJY4mzD+D iA=; b=lZe5nm3DgEiFU6E81gQj3q2i7orSJ5tPcF2nOW1DUGVXxXRrC9LOAasND HWQWH9UB0QhKNw2xV5w/Zu2XCUq07/ZGy+/ZEFTeT6ZYAsxZ5k7kdm/tLVR7LP3d lm2jJADT7ZhPIht0xW638pcBDjPMRksyjJGz3AdHaJ86L95JkbwlaOzLcXhICRvV yliWIJZ7WaxFp6c+2ZMI3+NUOs0mVuqmb9bWMv8+REzoPo9G97d7GyUsK5bN0vfK xkAx12dfmPAdOt+IhL2ooP7ec9Mp0WdPDwtQVIBlXQaQBU76wHUHDWaRYHBjdql2 SXZaQGlvra1apleuLO+ftfJfJ82pA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgepfe X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C1CF103CB; Thu, 2 May 2019 03:17:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Consensus Call: Flow control for post-handshake CRYPTO messages #1834 From: Mark Nottingham In-Reply-To: <71AC126A-FA71-4356-9B11-C0963AC5437A@mnot.net> Date: Thu, 2 May 2019 17:17:52 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <36E73329-5D29-44DF-B19E-6583F3014E64@mnot.net> References: <71AC126A-FA71-4356-9B11-C0963AC5437A@mnot.net> To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.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: Thu, 02 May 2019 07:18:02 -0000 Hearing no pushback, consensus declared. > On 23 Apr 2019, at 5:29 pm, Mark Nottingham wrote: >=20 > Bah, sorry; forgot the title. >=20 >> On 23 Apr 2019, at 5:28 pm, Mark Nottingham wrote: >>=20 >> 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 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu May 2 00:26: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 5AFB01202FD for ; Thu, 2 May 2019 00:26:12 -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=Cf+UJhTJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gPjVjOGl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7Jf_J2WktW5 for ; Thu, 2 May 2019 00:26:10 -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 558A21202F9 for ; Thu, 2 May 2019 00:26:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 22B1023378; Thu, 2 May 2019 03:17:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 02 May 2019 03:17:05 -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=u r4rlt0Epcz8rcPCn1nLZfXVv3vcCc4di+A8312jYP8=; b=Cf+UJhTJEKVg/xaMK u2ZsDRjDKzJ9EQinTJtv3sHuxHyA75A/Fr83FXXdJ6FAxkuT1p8wnJvmw6mmnw0F whgibZB4tURbnpuGI46fou8S4Ibh1fQilSRrsk4kBjSlyUQ+2pmSwQhL/w+QgLts 8IbuDkkUnvOhbVKiEP2o1xuQS592fYsJSJv3AP5b9bRCrL++02t2UKt48smRuY+Z Ndrm2DKR0KrKtQU/4Wb1lSsD2uIONoN+t+JPp2m/11lf76DaWhlvsRA0MkN1JJvj yeiGzwqwkuUf1vE3pdNj8vH8251AXYlSpuWUqk7zZhAH6Fq6Jf37bvt5S+bN/ZxU b9OjA== 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=ur4rlt0Epcz8rcPCn1nLZfXVv3vcCc4di+A8312jY P8=; b=gPjVjOGlfE/VO08dpYiwI7+6hAU1ZA3lN4dqgOSHCo4uF7X2ynIwegv8j q8jtIYvCSu3pqEP2zzKL9nJ5MWpoZIWyP8HLcp7wl1yD5JxNl1hVwJv5WHwjJCAv bfxbsCKe/uSIyq5awwpvxCSrs/YaAWxNRk4M9bF9jkyEGttK04sXQZPDo2kmAyew wZFz7CdFLVuSShYq0jz+ktoCWZ//YmBvI2OZbjgOcmmRut2UZqkJQCvt7jG3rWRH iGgDYZRnQsx0QJzwTdix6BIWXVjJ6ZlQXkDmDSI7ELoM6qIgc6v+4eWA5avUs9DW P7N257IGJisib+h3n8ToGd2qeTRpA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudeggedrudefiedrudej hedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgepvd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id C05F81037C; Thu, 2 May 2019 03:17:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Consensus Call: Use short headers for stateless reset #2599 From: Mark Nottingham In-Reply-To: <876F0C09-4A34-4489-B1DB-5FF365E4B6C3@mnot.net> Date: Thu, 2 May 2019 17:17:03 +1000 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <432F5703-9C52-4153-ACED-11578D503F5E@mnot.net> <876F0C09-4A34-4489-B1DB-5FF365E4B6C3@mnot.net> To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.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: Thu, 02 May 2019 07:26:12 -0000 Hearing no pushback, consensus declared. > On 23 Apr 2019, at 5:30 pm, Mark Nottingham wrote: >=20 > .... and now with a title. >=20 >> On 23 Apr 2019, at 5:28 pm, Mark Nottingham wrote: >>=20 >> 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 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu May 2 16:36:10 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 1E8B012065D for ; Thu, 2 May 2019 16:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=0.958] 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 KDfLjvnPXiSt for ; Thu, 2 May 2019 16:36:07 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0: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 86AF8120658 for ; Thu, 2 May 2019 16:36:07 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id v23so3129042oif.8 for ; Thu, 02 May 2019 16:36:07 -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=zBZfZOq6owH3fGc4mMVmnnpWROLwQz1xvsS4mFcIwno=; b=B/0Be46R6hkpxhOAVViGEbDd+z5TbLjLbvDMRcCgIeo1UbMeE3WyB1SJiiSnoNgCiC YJJ3KEL6enfZXOcksg43UtBXKDPIHwadOreLj/bhoUy+1CeYhLn5q4enk1jLO3h/gI0l HGL2bLeB4KkGxEnLmXAUs8ztruLsFRFU1DrCfP2LE44f6+cQ15jNGxMuyoWyB5ZMAzuu 5s9s/5FlntEoDUdBmQ0Enk6dE8XE7mogjAndqlVeh/kZ9UVAQuY27mzBfLAbkK/zPNGx nVqkJviTLDTL0u8ncsGE+MUn1/LzfCkbCwAAt+Ij/sTxYhw1smiBwd07K7UmWRrq9LBH 2m2A== 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=zBZfZOq6owH3fGc4mMVmnnpWROLwQz1xvsS4mFcIwno=; b=YUe2SJ5xIimh0DU47KeUlOvJjqpQgxsxoBg7OcZYv/s5Zqax9IO2ti9hzEVMKXgJzD aGr85hJQ18zSu046Zmak6fNXnII/YaEjDFCBqqi/xcl73+2NxMN6D0m5tWWDeor97tPT N6q0efi1WcBaTBKaKlJSZWbQ504qPDyp3b5+t1FJO9WU7yKCW5SLCgN5qwJxkFIeDHJD Z4PnDKWl4pjyNUiP1yJZLI2N6rTFh8ZZSpRUdhBSzN8O4wJYzP37Dvb2ugDbMDsIt2iE fFhOR7XTPnwdGWgUM1MXEjJdwCrHRE1L8gcq2h5USgN7XehCi8IROnYrYAuSZEaC/t1j c5Lw== X-Gm-Message-State: APjAAAVFo7b3aQHQooywX6d3AsFY0EkPUxBs9Soso7gNWBrTzcD6o5Kp VXFBH2QaMpOYFl33oA2hJwEplgsNaxum06v7aAPG4vjhuLQ= X-Google-Smtp-Source: APXvYqzAh7KFvzMPmVu5nM453vAxMJ7pBn/bV18fpgiDAC6uuBTmZblVn4wco+v8urMlGbMZGqdm+1vY+tA7YJxtJsU= X-Received: by 2002:aca:52d1:: with SMTP id g200mr4043779oib.152.1556840166595; Thu, 02 May 2019 16:36:06 -0700 (PDT) MIME-Version: 1.0 From: Udip Pant Date: Thu, 2 May 2019 16:35:55 -0700 Message-ID: Subject: Open sourced mvfst - implementation of QUIC by Facebook To: quic@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a223a0587f0194d" 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, 02 May 2019 23:36:09 -0000 --0000000000001a223a0587f0194d Content-Type: text/plain; charset="UTF-8" Hello everyone, We open sourced mvfst, an implementation of IETF-QUIC by Facebook: https://github.com/facebookincubator/mvfst. It has both the client and server implementations and includes features such as multi-threaded sever, connection-id based routing, GSO support, APIs for statistics and transport events, and happy eyeballs support. I hope you can try it out and give us feedback. For discussions, join our slack channel: mvfst . Thanks, Udip --0000000000001a223a0587f0194d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

We open sourced mvfst,=C2=A0an implementation of IETF-Q= UIC by Facebook:=C2=A0https://github.com/facebookincubator/mvfst.=C2=A0
It has bo= th the client and server implementations and includes features such as mult= i-threaded sever, connection-id based routing, GSO support, APIs for statis= tics and transport events, and happy eyeballs support.

=
I hope you can try it out and give us feedback. For discussions, join = our slack channel:=C2=A0mvfst.

= Thanks,
Udip
--0000000000001a223a0587f0194d-- From nobody Fri May 3 05:21:55 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 D124A1200F5 for ; Fri, 3 May 2019 05:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IHnBJLOYiQte for ; Fri, 3 May 2019 05:21:51 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 AEB1B1200EF for ; Fri, 3 May 2019 05:21:51 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id g141so3468388qke.5 for ; Fri, 03 May 2019 05:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=A6nhbGeiscD5u4KGoZcffjhyfJMpZ8M4drZ7UJQa/r8=; b=dP2huCAeJ2HC/UkfDxOu8/hcwGcmsJH9juU194hqv6nKrABBle2bZcsnvrkQ7kzI0x tNQqsjPXbBvMbUzmq0WadVxojaomR7zzbTrFP/tzPaYkr8xfAYa2/shBSVIRkso7KEwQ 9XlEnov66g3DJTXTLdtrAduzbOu8gDn42BpYZAc54shqkW3RLz7MpuctS5Vt5qmj6qbS PdfcaXIjVeyC9SbsMv3wm7l96T6Hf5YyTAcDdB72feRBl/molU4JydcKqNI9z7n3H0pH iBEbhQR5/FDDTcGW/8lqkTh+tDzv3HJKzvr5keBvoBsvKtnFh/jby+OidrzBlSFpwdBM r7rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=A6nhbGeiscD5u4KGoZcffjhyfJMpZ8M4drZ7UJQa/r8=; b=fPkA3BtQJHPEXQ9UeczZ0mwpzMi2eHyiVbPofpzzYC+qN+KDwAuLzaj8SrshQnOz0J geP7y3YKAEvfqpvpc1Zf91Hsvzqby4g3m/l/1j3P1GzBwyDCnPlbGK960UFeaY6Dk69a VfuH+iNWBDt4j4jRKz5TNWF9BPLDmvqHYoZcyNCVEiRIn0knradGGbqL1acO/BBE55WI C8tx7iDQg/OPkkBX048SR7zDkEZz818y13ICXGjdqSbIevdboeK22iZU1+DX+StesNzi 96iZuPtQXXBqCmWn0mILobjpICJaK1m0xLR++LMbYxJHDGlgG+s1ZMTpN7lCOanavTmL GMzA== X-Gm-Message-State: APjAAAXE7Vw1eHjNudGpeNk+Mx4Jfh2RHmUMqZDk8dmwjCCDAk9TKYmZ IL8ZHS+AkCgvWN8KMTTdVjjZU+0VrJg= X-Google-Smtp-Source: APXvYqwnoHDT+0yLBPKF28/ycJ7dy13Zsy6EhJcHTNaC45B8h6CVqjYBEkYYM6CN+nKgmg1595ICOw== X-Received: by 2002:a05:620a:118f:: with SMTP id b15mr7181239qkk.162.1556886110622; Fri, 03 May 2019 05:21:50 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id b187sm1171350qkd.73.2019.05.03.05.21.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 05:21:49 -0700 (PDT) Date: Fri, 3 May 2019 08:21:44 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Duplicated TPs vs duped HTTP/3 settings Message-ID: <20190503122143.GA26519@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 03 May 2019 12:21:54 -0000 Hello, A recent GitHub discussion [1] reminded me that duplicated transport parameters MUST be treated as error [2]. This is in contrast to duplicated HTTP/3 settings, which MAY be treated as an error. Why the inconsistency? The checks for duplicated transport (or settings) parameters are expensive, because one has to maintain an arbitrarily-sized set of possibly large numbers. I propose we switch the duplicate TP parameters enforcement to "MAY treat as error." - Dmitri. 1. https://github.com/quicwg/base-drafts/issues/2663 2. https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-7.3 From nobody Sat May 4 17:45: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 804FE1202E2 for ; Sat, 4 May 2019 17:45:22 -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=H2+U5/8/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CmkMf/Y4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbgaoemSYmKp for ; Sat, 4 May 2019 17:45:19 -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 36B5312029F for ; Sat, 4 May 2019 17:45:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 6EAE52DF for ; Sat, 4 May 2019 20:45:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 04 May 2019 20:45:18 -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=EKbihx8hk7I13fehsZ2iFOjBTUKLTEzC5k9vGO+/PDY=; b=H2+U5/8/ IFHGc+2B7VjfRHOk8ss6/reoabWJSP1fY8i+CePX4J9t75hTmQSme2RNGu1sh5Yp 2lNScthG4GRdBSNyFkjVxah80bZNqKSx1UOwSd/hpoxMYTp8Ly5vQPc/gY/dsxaS 0YyAJxQnjr9wYAGUshBVX/F39+I5y9jBEabUDucrlB+Q1qgSgsDDEbwPak8f/dH/ JfoMFLBiZRvklCTDrl33N1Q5etCLrdeTxVgftfmjOSwF1vUah1oBsELPPT6Do2zb P86JFDDMLiNYiyl3koQ4ykp2FUUSB8Av8KBSPyySwgW8Kb5mJ1xIpmAN9uHWmzCO JxnkyM4gAxuSJw== 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=EKbihx8hk7I13fehsZ2iFOjBTUKLT EzC5k9vGO+/PDY=; b=CmkMf/Y466s3KpMAVD4wI3CsyZSnX8rientiEvOcedP91 iMtFu51dmfY2wFSWmNVWL6RxxqdqfuzCMyfVX0uQrWHUFd0uxFvG5BK/iFSdV1Td FHIIddudPsPJdY5QFUGval1KWyKDMAR+S5ueDXVmAQkJhxFrKJsIXodpuqDe2Qd7 vkQOmaRtdcgavGAv4O+nGyXXrZGRf6dJCQKAKRzg++rT6Z+mgm0p7DhQ3DLYE58u xvQQSd7anUzoztn3s/4eVb/VDaFUzoSA1Yy1SNLYLQ2kcuBFQTSH9dF2uLAJi0Z/ BCioo8P2Pklf342xgXiKurLn0771drhMpXwZbePfQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeggdeflecutefuodetggdotefrodftvf 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 535EAE4122 for ; Sat, 4 May 2019 20:45:16 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id CA1EAC033D for ; Sun, 5 May 2019 00:45:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7324647560692005027==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190505004512.CA1EAC033D@cloud.mnot.net> Date: Sun, 5 May 2019 00:45:12 +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, 05 May 2019 00:45:23 -0000 --===============7324647560692005027== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+5/-10/=F0=9F=92=AC37) 5 issues created: - [feature] Push messaging from server to client (by wzr1337) https://github.com/quicwg/base-drafts/issues/2664 = - Why is SETTINGS parameter duplication a connection error? (by LPardue) https://github.com/quicwg/base-drafts/issues/2663 = - STREAM_LIMIT_ERROR vs MAX_STREAMS (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2661 = - Is HTTP/3 message exchange 100% accurate? (by LPardue) https://github.com/quicwg/base-drafts/issues/2657 = - Discarding connection state at server on unvalidated client (by janaiye= ngar) https://github.com/quicwg/base-drafts/issues/2656 [-recovery] [design] = 9 issues received 37 new comments: - #2664 [feature] Push messaging from server to client (10 by wzr1337, mi= kkelfj, martinthomson, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2664 [invalid] = - #2656 Discarding connection state at server on unvalidated client (8 by= martinthomson, mikkelfj, janaiyengar, marten-seemann, ianswett) https://github.com/quicwg/base-drafts/issues/2656 [-transport] = - #2663 Why is SETTINGS parameter duplication a connection error? (8 by m= artinthomson, ianswett, dtikhonov, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2663 = - #2661 STREAM_LIMIT_ERROR vs MAX_STREAMS (5 by martinthomson, marten-see= mann, LPardue, mikkelfj) https://github.com/quicwg/base-drafts/issues/2661 [-transport] [editori= al] = - #2638 max_ack_delay is unknown when a new connection is established (2 = by marten-seemann, mikkelfj) https://github.com/quicwg/base-drafts/issues/2638 [-recovery] [design] = - #2533 Handling of PRIORITY Frame Empty bits (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2533 [-http] = - #2509 STOP_SENDING on Critical Stream (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2509 [-http] [design] = - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (1 b= y afrind) https://github.com/quicwg/base-drafts/issues/2632 [-http] [design] = - #2551 Replace HTTP_MALFORMED_FRAME for something simpler (1 by dtikhono= v) https://github.com/quicwg/base-drafts/issues/2551 [-http] [design] = 10 issues closed: - Handling of PRIORITY Frame Empty bits https://github.com/quicwg/base-dr= afts/issues/2533 [-http] = - STREAM_LIMIT_ERROR vs MAX_STREAMS https://github.com/quicwg/base-drafts= /issues/2661 [-transport] [editorial] = - is persistent congestion per pn_space? https://github.com/quicwg/base-d= rafts/issues/2649 [-recovery] = - endpoints don't know how many connection IDs the peer is willing to sto= re https://github.com/quicwg/base-drafts/issues/1994 [-transport] [design] = [has-consensus] = - MAX_PACKET_SIZE frame https://github.com/quicwg/base-drafts/issues/2545= [-transport] [has-consensus] [quicv2] = - [feature] Push messaging from server to client https://github.com/quicw= g/base-drafts/issues/2664 = - Why is SETTINGS parameter duplication a connection error? https://githu= b.com/quicwg/base-drafts/issues/2663 = - rate-limiting of CID issuance needs to be allowed https://github.com/qu= icwg/base-drafts/issues/2436 [-transport] [design] [has-consensus] = - Are transport parameters mandatory? https://github.com/quicwg/base-draf= ts/issues/2528 [-transport] [design] [has-consensus] = - lost_pn can go negative https://github.com/quicwg/base-drafts/issues/26= 11 [-recovery] = Pull requests ------------- * quicwg/base-drafts (+6/-9/=F0=9F=92=AC11) 6 pull requests submitted: - Recovery Editorial Nits (by ianswett) https://github.com/quicwg/base-drafts/pull/2667 = - Don't request control streams be closed (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2666 [-http] [design] = - Replace HTTP_MALFORMED_FRAME error code (by LPardue) https://github.com/quicwg/base-drafts/pull/2662 = - Stream ID is 62-bits (by martinthomson) https://github.com/quicwg/base-drafts/pull/2660 [-transport] [editorial= ] = - Fix two typos in the changelog section of transport draft (by dtikhonov) https://github.com/quicwg/base-drafts/pull/2659 = - Fix typo: drop a doubled word (by dtikhonov) https://github.com/quicwg/base-drafts/pull/2658 = 5 pull requests received 11 new comments: - #2646 use max_ack_delay =3D 0 before receving the TPs (5 by marten-seem= ann, mikkelfj) https://github.com/quicwg/base-drafts/pull/2646 [-recovery] [-transport= ] [design] = - #2510 all HTTP/3 protocol violations should lead to connection errors (= 2 by LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/2510 [-http] = - #1998 introduce a max_connection_ids transport parameter (2 by martinth= omson, marten-seemann) https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] = - #2662 Replace HTTP_MALFORMED_FRAME error code (1 by LPardue) https://github.com/quicwg/base-drafts/pull/2662 = - #2642 Don't send PING in Initial or Handshake (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/2642 [-recovery] [design] = 9 pull requests merged: - all HTTP/3 protocol violations should lead to connection errors https://github.com/quicwg/base-drafts/pull/2510 [-http] [design] = - introduce a max_connection_ids transport parameter https://github.com/quicwg/base-drafts/pull/1998 [-transport] [design] = - Stream ID is 62-bits https://github.com/quicwg/base-drafts/pull/2660 [-transport] [editorial= ] = - Suggestion for #2499 https://github.com/quicwg/base-drafts/pull/2503 [-transport] [editorial= ] = - Transport parameters are mandatory. Fixes #2528 https://github.com/quicwg/base-drafts/pull/2560 [-tls] [design] = - Fix typo: drop a doubled word https://github.com/quicwg/base-drafts/pull/2658 = - Fix two typos in the changelog section of transport draft https://github.com/quicwg/base-drafts/pull/2659 = - Remove lost_pn and avoid integer underflow https://github.com/quicwg/base-drafts/pull/2651 [-recovery] [editorial] = - Move "Discarding Keys and Packet State" up https://github.com/quicwg/base-drafts/pull/2652 [-recovery] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============7324647560692005027== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday May 05, 2019

Issues

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

5 issues created:

9 issues received 37 new comments:

10 issues closed:

Pull requests

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

6 pull requests submitted:

5 pull requests received 11 new comments:

9 pull requests merged:

Repositories tracked by this digest:

--===============7324647560692005027==-- From nobody Mon May 6 09:10: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 D241E1200C5 for ; Mon, 6 May 2019 09:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eVABnIUMrSU for ; Mon, 6 May 2019 09:09:59 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388491200FC for ; Mon, 6 May 2019 09:09:58 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id h21so11536630ljk.13 for ; Mon, 06 May 2019 09:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EFAL8Y0T/4slFnaK66uF0x/nuw+3W5gaN68fDil5RW4=; b=noFezMNHP2BV/Dwy8W8d9BV8/QJO8D0TkbTtAQJbz0S2dqVgYpvBQrs39WimBcHyXB x7qf8dKVgmELuiD3CiiYp8+gltIW+E3SPYKwhB61zYdSs9R9q7f6Kj3zijuutz74Wmr1 20uw5WMixL5WW+4s6e05rddW5POaljFaHUhic= 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=EFAL8Y0T/4slFnaK66uF0x/nuw+3W5gaN68fDil5RW4=; b=bEC1QCu3kz0Mf5kVedLx3GdfkhY2tldgam/ofjBbw01JNy0y+qVvOq+XVdTzlF5X6O 0U/QAiqxwlFUmxgsGo+szwQGM70ZURRNUX4ESjXo7aGbi5TADlftOCgXve/x89BJRFUC sNv0kX63E/mvPDY4AjerBRKpjexc+u++j5W4xYu51zALHOvjyixnArI2sTR7gW6v2Zlg pq8pgkbPGkyLP/IR8cZDEbJhsG1MOTNXAX3feqGx3LqV6+Mfjc2LBK5K42u9zUbTIKGR gZflPle9+KfZbq7YWtlZ3vOfK4zXGyl9wpx1zHz57u5a89GmlFHcqtLk3Tp7ffQPkVmc g3Dg== X-Gm-Message-State: APjAAAVL5+hYJca90Cs36ke30Dx9ulvQF8paO2Z9c79mBhpZmfAUqwb0 BSlZ/QQWTIEy3ewFKRZwy3tnIoZNXe3Ykrg7T5A06w== X-Google-Smtp-Source: APXvYqyqPFFBKYO0ylPhknMfBIVWL/yUJ+4PUGOD2/1qavutoWiLp3NeT80eW1ugQXA5SD53ypJS3qKasv00l5YayCc= X-Received: by 2002:a2e:9954:: with SMTP id r20mr4682637ljj.24.1557158996965; Mon, 06 May 2019 09:09:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robin MARX Date: Mon, 6 May 2019 18:09:45 +0200 Message-ID: Subject: Re: QUIC Symposium : May 7 in Belgium To: Iyedi Goma Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000df91c705883a54cd" 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, 06 May 2019 16:10:03 -0000 --000000000000df91c705883a54cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, The QUIC Symposium will take place tomorrow. We have a great line-up of local researchers giving a total of 10 talks! We decided to Taunt the Gods (and Murphy) by trying to livestream the event as requested here. We will not provide the opportunity to ask questions remotely though. URLs for the YouTube livestream and more details about the talks can be found at the website: https://quic.edm.uhasselt.be/symposium19/ After the event, we will also put the slides online and hopefully split the livestream up into individual videos. With best regards, Robin On Thu, 21 Mar 2019 at 20:51, Iyedi Goma wrote: > Great news > > I really hope we could have opportunity to follow the symposium remotely. > > Regards > Serge parfait Goma > > Le mer. 20 mars 2019 =C3=A0 18:18, Robin MARX a > =C3=A9crit : > >> Hello everyone, >> >> We are organizing an informal QUIC (and HTTP/3) Symposium on Tuesday May >> 7 in Diepenbeek, Belgium. >> More information can be found at: >> https://quic.edm.uhasselt.be/symposium19 >> >> During the excellent EPIQ workshop in Greece last December, we noticed >> that there are a lot of academics working on QUIC in Belgium and Germany= . >> The main idea behind the Symposium is to bring together those researcher= s >> and students and create a stronger local community. >> However, anyone with an interest in the topic and the will and ability t= o >> travel to Belgium is more than welcome. >> >> The goal is that anyone can present (early) results from their research >> or practical experience, but there is also room for discussions, >> brainstorming, small workshops/hackaton, etc. >> You can request or offer content at our "Call for Papers": >> https://goo.gl/forms/62SmRuSOR3zuREVn1 >> >> The event is free (including free lunch!) but we do ask that you registe= r >> before April 30. >> This can be done at: https://goo.gl/forms/8brKkLXXhVl7UCJg1 >> >> We hope to see some of you there! >> With best regards, >> Robin Marx and Oliver Hohlfeld >> >> -- >> >> Robin Marx >> PhD researcher - web performance >> Expertise centre for Digital Media >> >> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 >> >> www.uhasselt.be >> Universiteit Hasselt - Campus Diepenbeek >> Agoralaan Gebouw D - B-3590 Diepenbeek >> Kantoor EDM-2.05 >> >> >> --=20 Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --000000000000df91c705883a54cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

The QUIC Symposium will= take place tomorrow. We have a great line-up of local researchers giving a= total of 10 talks!=C2=A0
We decided to Taunt the Gods (and Murph= y) by trying to livestream the event as requested here.=C2=A0
We will = not provide the opportunity to ask questions remotely though.=C2=A0
URLs for the YouTube livestream and more details about the talks can = be found at the website:=C2=A0https://quic.edm.uhasselt.be/symposium19/

=
After the event, we will also put the slides online and hopefully spli= t the livestream up into individual videos.=C2=A0

= With best regards,
Robin

On Thu, 21 Mar 2019 at 20:51,= Iyedi Goma <iyedigoma@gmail.com<= /a>> wrote:
<= div dir=3D"auto">Great news

I = really hope we could have opportunity to follow the symposium remotely.=C2= =A0

Regards
Serge parfait Goma

Le mer. 20 mars 2019 =C3=A0 18:18, Robin= MARX <robin= .marx@uhasselt.be> a =C3=A9crit=C2=A0:
Hello everyone,

We are organizing= an informal QUIC (and HTTP/3) Symposium on Tuesday May 7 in Diepenbeek, Be= lgium.=C2=A0
More information can be found at:=C2=A0https://quic.edm.uhasselt.be/symposium19

Dur= ing the excellent EPIQ workshop in Greece last December, we noticed that th= ere are a lot of academics working on QUIC in Belgium and Germany.=C2=A0
The main idea behind the Symposium is to bring together those resea= rchers and students and create a stronger local community.
Howeve= r, anyone with an interest in the topic and the will and ability to travel = to Belgium is more than welcome.=C2=A0

The goal is= that anyone can present (early) results from their research or practical e= xperience, but there is also room for discussions, brainstorming, small wor= kshops/hackaton, etc.=C2=A0=C2=A0
You can request or offer conten= t at our "Call for Papers":=C2=A0https://goo.gl/form= s/62SmRuSOR3zuREVn1

The event is free (includi= ng free lunch!) but we do ask that you register before April 30.
= This can be done at:=C2=A0https://goo.gl/forms/8brKkLXXhVl7UCJ= g1

We hope to see some of you ther= e!
With best regards,
Robin Marx and Oliver Hohlfeld

--

=
Robin=C2=A0Marx
PhD researcher= - web performance
Expertise centre for Digital Media
=C2=A0
= T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Un= iversiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2= =A0EDM-2.05
=C2=A0
3D""
=


--

<= td style=3D"font-family:Verdana,Geneva,sans-serif">Agoralaan Gebouw D - = B-3590 Diepenbeek --000000000000df91c705883a54cd-- From nobody Mon May 6 22:37: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 37927120072 for ; Mon, 6 May 2019 22:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.35 X-Spam-Level: X-Spam-Status: No, score=-0.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.648] 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 uZlm85JjEZRO for ; Mon, 6 May 2019 22:37:56 -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 5A1D712002F for ; Mon, 6 May 2019 22:37:56 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id z5so7999653lji.10 for ; Mon, 06 May 2019 22:37:56 -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=gmK7oyOUngJXxf8S5g0HG6hIq0twIoR8KyxcZ5hVFJk=; b=iOnpHJGvcVs9ceGS1vYi7b9S39WSdlPRey9T67HNDZy6JYUkwK1CxS/AW15TYh3MyO 6TfEtaehdXRrv2l7w+cvr/DulI5I0wbyMJO329KzNW0f5unNwT+eEBfEeRh+CBG0afs/ fi9c2VXkVaqmpniDGCJqO5fPi5mkaO7jgwMP3St/pAmAvnRgAyc9c41BihKgB1YMTTOX kkjyq9JixHXgU5iOS/uPfTUa9eFHtMALIZBZ6BonPxLw6lFMAFcDDTCrvJ8py82+lefQ qTIkO67dv556IeRNqxnDjDLQVEriTfIxAFu3rmcXEalh7kwcITWV9bOr0s5uQHzTJDlr E+7A== 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=gmK7oyOUngJXxf8S5g0HG6hIq0twIoR8KyxcZ5hVFJk=; b=co9txJW69NKfTMHpTaCJgukkk+XgeMtvmyy25OiO5E/zMmHXqZxnoFLVGZhTNXs4KP qXatk5/pFY3O1G1xV6+IjQdeFPd6VBcFBHx/E9alwcTUeX+8hzaykoSPBAjzG4AN52Lf mX1rhjBd8EptRQD+sxFzhMfYjKC4nK2uHn1r3Ss53D6b1he5TQHrQaJBQgNu5iP0kk3l ZTHisSJYXQQW+kaDWQesf7YPdZ7RaQtjgBkWuQLhI+uaAVQ//Is2mVUG0/lJ+L0YJU8B 2L0Ks8VAdt7lU7qbey9psRI4Hdu19unx50QJnWQadXAP9eluzCkK1rsod53MSvopm7/b sI5A== X-Gm-Message-State: APjAAAX0IYOjIw0QTxhMaiZADbsIABEEfP2K6nre86f3jQZ2NwDnW+HP CXF76ya0kp9HFPRCoW3gNN5LtP4kRmFbwY5Ud64= X-Google-Smtp-Source: APXvYqxNgcOyZGaMAjWndqFpUxQS1Q1mXjilx9rZCUYSelDb6L5+C0PBlvMOiLCG8qpcrQA//QH7SroCz8FPqfr2RRI= X-Received: by 2002:a2e:84ca:: with SMTP id q10mr2490800ljh.117.1557207474456; Mon, 06 May 2019 22:37:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Mon, 6 May 2019 22:37:43 -0700 Message-ID: Subject: Re: Open sourced mvfst - implementation of QUIC by Facebook To: Udip Pant Cc: QUIC WG Content-Type: multipart/alternative; boundary="0000000000005b4b880588459eff" 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, 07 May 2019 05:37:58 -0000 --0000000000005b4b880588459eff Content-Type: text/plain; charset="UTF-8" Thank you so much for opening this up! Glad to see the code finally (and also happy to see that you're experimenting with new congestion controllers :-)) - jana On Thu, May 2, 2019 at 4:36 PM Udip Pant wrote: > Hello everyone, > > We open sourced mvfst, an implementation of IETF-QUIC by Facebook: > https://github.com/facebookincubator/mvfst. > It has both the client and server implementations and includes features > such as multi-threaded sever, connection-id based routing, GSO support, > APIs for statistics and transport events, and happy eyeballs support. > > I hope you can try it out and give us feedback. For discussions, join our > slack channel: mvfst > > . > > Thanks, > Udip > --0000000000005b4b880588459eff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you so much for opening this up! Glad to see the cod= e finally (and also happy to see that you're experimenting with new con= gestion controllers :-))

- jana

On Thu, May 2, 2019= at 4:36 PM Udip Pant <udippant@gm= ail.com> wrote:
Hello everyone,

We open sourced = mvfst,=C2=A0an implementation of= IETF-QUIC by Facebook:=C2=A0https://github.com/facebookincubator/mvfst.= =C2=A0
It has both the client and server implementations and incl= udes features such as multi-threaded sever, connection-id based routing, GS= O support, APIs for statistics and transport events, and happy eyeballs sup= port.

I hope you can try it out and give us feedba= ck. For discussions, join our slack channel:=C2=A0mvfst.

Thanks,
Udip
--0000000000005b4b880588459eff-- From nobody Tue May 7 14:25: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 138F6120167 for ; Tue, 7 May 2019 14:25: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10UtWb2xHgRW for ; Tue, 7 May 2019 14:25:43 -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 5AA7F12015D for ; Tue, 7 May 2019 14:25:43 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id b10so403852wmj.4 for ; Tue, 07 May 2019 14:25: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=3RlQFydWA/srMBbOY+w1zFLM3I6B4vF2asyZpHlYom0=; b=U6yVwnvJQmIehYy2HHIv0Uq1fR/AFGJGxkrzFhAUOgbxcVuyBx5MjzpeLrmqLI/9Jz eTi2Klvhs0HAedgBp1tiwNfw00WrCVmUbRVs6t0u66wk/htZfddbfxfwyWM4cE3Zjitn OsZSe9lYGgJ2f5uqcvUwYkLeG18EklZcivuG45qS5ZHV5nI/UmnbGj2U9CPZh/Jay8P5 bldsqqgB0cyw1LR4Yp6yZN600dTRNDFY0ge76QZuSELBHexs59lq2b8CYptptVUAIWrA M4w6nlU8ztSO7rpatXJpgAsmdGIwSuxO/eFJ6piRzeMcjoa4ZFG+CR78oJRBPmcNvnXQ aXXw== 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=3RlQFydWA/srMBbOY+w1zFLM3I6B4vF2asyZpHlYom0=; b=KasivsYuIwQYUAKKNFFQe6ufZ7FtUrWXqyOSiK9jq12bqCu13i6a3Q2MoV2TN4jj6W liZg06rcIh8vMUy6uZLbKCwRkrn8Y79qSddFooMkzkJAzGfnQC4Zy7/4Eorbx8rGe3BS JCGQ0YTaaLXHsF0RK8lQeJG0fX4aJ6V4uucGUNawhjRq3WL/AZ7Yd+m1oTxu2SHvg93x BeyH8+PWGf7wLkK0jfEhgmqXfep3pIFzVljJhC+RSLIazJFr6t6X2SQII8R35kWoPOjk oXLWwopfHQASq/te0EYQM0ztEpeA8yyrpKaSvnwZOfV31iK5VG7GaiUjKutFCvSsC7rQ 8LXg== X-Gm-Message-State: APjAAAXpzs2/uHQAgLNNRhL8wDSgGOdY3irV5pOQZcJlQgIIohEoLx2w r2TD7tHeAZcS07GKkTiOSbkaFw2UHHGeFd19HZYSvQi6 X-Google-Smtp-Source: APXvYqw3nLsIYIASCVaIgx8452gZFECkLCefyBQehszDmBb5/vxcF85h8yTQKP/zct+8vIFU8SHOnwCMqMBALpPb0yw= X-Received: by 2002:a7b:c00e:: with SMTP id c14mr323523wmb.110.1557264341682; Tue, 07 May 2019 14:25:41 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Tue, 7 May 2019 14:25:30 -0700 Message-ID: Subject: Output of the discard keys design team To: QUIC Content-Type: multipart/alternative; boundary="000000000000e84fa0058852dbd6" 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, 07 May 2019 21:25:45 -0000 --000000000000e84fa0058852dbd6 Content-Type: text/plain; charset="UTF-8" Hi everyone, The discard keys design team has reached consensus on how to move forward with discarding keys, and has produced a PR to modify the spec: https://github.com/quicwg/base-drafts/pull/2673 In a nutshell, we leverage acknowledgments as an explicit signal that indicates that an endpoint is in a given state, and use that to allow the peer to make progress. We believe that this PR prevents the potential deadlocks discussed in issues #2214 and #2267. Please let us know your thoughts in response to this email. Thanks, David --000000000000e84fa0058852dbd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

The=C2=A0discard keys design team has reached consensus on how to m= ove forward with discarding keys, and has produced a PR to modify the spec:=


In a nutshell, we leverage acknowledgments as an explicit = signal that indicates that an endpoint is in a given state, and use that to= allow the peer to make progress. We believe that this PR prevents the pote= ntial deadlocks discussed in=C2=A0issues #2214 and #2267.

Please let us know your thoughts in response to this email.

Thanks,
David
--000000000000e84fa0058852dbd6-- From nobody Tue May 7 20:32: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 643C5120073 for ; Tue, 7 May 2019 20:32:50 -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=ZRJEohd8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=7bQ6v/ww Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MouhMPWblWfW for ; Tue, 7 May 2019 20:32:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B381200CD for ; Tue, 7 May 2019 20:32:47 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 82F0E21F85; Tue, 7 May 2019 23:32:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 07 May 2019 23:32:46 -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=Hl/k30C6Ott/wid5JtGfvQd1bBOZGD ex9BGAbZrAk7E=; b=ZRJEohd8kfgnPKjP/sIDAuKK4IRMcrUMyFkWyDPAXwOAFz r944IXK9e0512xwZTjvWrAS7gukFd6fMHOE8WxyFEWnRdUbGEKnNKDb4FDcCL1Ja K4Xp3zDfyd7ZQGMhKamiDi+AeGmq9zuptoN4+OVygT/zs+eS0QuxkAsV+WTc8VEE 6VNo8nAXUgqF8ok27tvRkfFXMdLr7D53/pikYyQfinoVraH/YBVcjOP5+fr2U7P3 tbaRTGnb9dB/lbyprWS9qBdQkVl8YCkcr+BOSNPioOg78ji87BSBZcM0cjEGVetD +34tnIY8PFdksKcm6syVQQcJnCZszMbadzuhOGPQ== 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=fm2; bh=Hl/k30 C6Ott/wid5JtGfvQd1bBOZGDex9BGAbZrAk7E=; b=7bQ6v/wwX7rExg/n1wIVHJ PpOn1H2lVCIJn/0+xcCarCBn0WY1R5fGcvSX7MjYUHaBrgWGIK1SLOlqEgp43Kqc //oiGJ32KconYRYDQBwp8EIwhv3HWP56XBM9Ut5Hyte21yb/USmM6x+a5k+nF9qB Nv0ZOkBv7OBKvjtb8pPCuyO1gLJ2PhHvwslsq2R7UVJDwyXWPSwo4Qx1VjC0+ydG kQ4jzODJj2q6Rn25cHLq/hLuv1z7qLQomqz7LvA4lg6E0CRPVkynTJZQX6Oar0Z4 QpEIhS2+ysjRe6F4S1fM/J89rm3/D28adq8m9gh8jbBpNINfCPOhbhl8B0LJmC9g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkedugdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtjehmtdhhtddvnecuhfhrohhmpeforghrkhcupfho 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 63432103CF; Tue, 7 May 2019 23:32:44 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Agenda for the London Interim meeting Message-Id: Date: Wed, 8 May 2019 13:32:41 +1000 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.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: Wed, 08 May 2019 03:32:50 -0000 ... is at: https://github.com/quicwg/wg-materials/blob/master/interim-19-05/agenda.md Suggestions (including for "as time permits" sessions) welcome. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed May 8 23:54: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 DD9BA120086 for ; Wed, 8 May 2019 23:54: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] 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 QkzWzZIVXdRJ for ; Wed, 8 May 2019 23:54:34 -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 EEC1F120049 for ; Wed, 8 May 2019 23:54:33 -0700 (PDT) Received: from eggert.org (unknown [62.248.255.8]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 21ED920049 for ; Thu, 9 May 2019 09:54:30 +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 F107F841F4B for ; Thu, 9 May 2019 09:54:25 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_076C2734-7788-4FDD-A359-34362417FE9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Consensus Call: client should send PING in Initial or Handshake, but PINGs are forbidden in these packets Date: Thu, 9 May 2019 09:54:25 +0300 References: <90528B66-48F6-4788-AE0E-9EF141592476@eggert.org> To: QUIC IETF mailing list In-Reply-To: <90528B66-48F6-4788-AE0E-9EF141592476@eggert.org> Message-Id: <05C01CC5-F5FE-4209-8E8A-A9FE67ABC46D@eggert.org> X-MailScanner-ID: F107F841F4B.A41DB 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, 09 May 2019 06:54:36 -0000 --Apple-Mail=_076C2734-7788-4FDD-A359-34362417FE9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hearing no pushback, consensus declared. On 2019-4-26, at 9:48, Lars Eggert wrote: >=20 > 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, > Lars (for the chairs) --Apple-Mail=_076C2734-7788-4FDD-A359-34362417FE9A 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----- iQIzBAEBCgAdFiEEDrrUO3PMwKM8fddaHbmKvSnuNPgFAlzTzqEACgkQHbmKvSnu NPjCmRAAkvv80ewQDliN4i+bEtGhzcI4TKbvAe2DwRxST/a6ERSZqMEnEGKyvbav 4aiktLisshMF3BGIQEwGgVVsIWC7ySmKxkuD2AkgPLi+y5mPEJfqraKIm/bi7LUH dosbd6QOQp1BpA+GySvZN++3Uuszd1zzi4GonoHyZbXsuvd26CNSZVQeO1YcT8d6 Q910CN3uPovIWWVGkSzPpcGtfOJz6e1qqs4fsShDy+XKza8gefFSaPahH0DTmCI2 gSJIjdnAXSESwwq1eCaHeXZp2R2BUGMjZlRlk5RUzW4SgH8IqZwLo7KCarSS+7OP joNXjEa68FK15976sXJBjeFX84D5vQU45C2qdZ7OEyM3rHQMppwTtVmj7mARVpih o3vsZgEDQJplxguUWBZDSYjI3rJCBly6nmijLkdpmJ4yaz1jVntk4CSftvsE+J6p +WIPVG0wuL4UFxVj2BzEgV6PNcaauDiMNytuJyDvtOaL9wwC4V+ufFavHrDpF1L+ LJcRqqJbYxQL73z2atUZ/KAKeSMZwezZkbhEE4l1UHNmMIlB/792wOcmqlhg9Vr/ bNJVjAXhDTFQsVWHv1+cVJ1f6NJFDOpAfyJzOK69a8RLM8afzPFKoCFbxgtZqwHK IMdWOVszkWOtW+dPetgLTkQLkmZBOCRA/nU/L5fODLw0i65RsyM= =p/VY -----END PGP SIGNATURE----- --Apple-Mail=_076C2734-7788-4FDD-A359-34362417FE9A-- From nobody Thu May 9 18:39: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 9A6BB120045 for ; Thu, 9 May 2019 18:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPzrikIfCC_E for ; Thu, 9 May 2019 18:39:27 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B815A120004 for ; Thu, 9 May 2019 18:39:26 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id x132so2965977lfd.0 for ; Thu, 09 May 2019 18:39: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; bh=FaU2JinMAIVADHxowOgDcH6owVqMyQRFw4SEBCHrXuw=; b=Jg5iYH/gFiRyhP7K8YBSgztGy6yA/nPpkw/oGJsjiT03sVCcSmd8ps80UztUdV3RzQ pWAY6nBT5I2/Ujz0e2qtLTX3fYCm+ej3BHX2teiTRtOo6stjlx1860L8ORy25HI4F0xD UMoIUT493CpFPqrvypxGqnVv0MjR6dKRRjy+MuEanCap2TXJF8avuUI5mmq7I1kJuam1 plHLGGOEWwVTDNTZn9yla5hOljXbrc9RWfQWM+0ontMGjIU1KwGJ6pfyp+LkRQBVurbL x+SLn6LxQmkGJYPTk53X+EIuaZhFFpfgmd7FRW/wvN2PWuz/toL1XltyfjpA4544mRmf RZOQ== 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=FaU2JinMAIVADHxowOgDcH6owVqMyQRFw4SEBCHrXuw=; b=F4qy60YZnsPhHJcrFwm60ISqsredymqfx1tIsD3Acs3IYxD1hpkyY6NF5jpKO7K35n Ie2AQky1ExAxCO+8G6O8USTFsoAbjDC9LqJIgrhftf5t4xKeMX/Mte07kdhnVmd3CweK EC2X1JDK2AkIoqVfCqKoQe0Szl7jfO4TWZAFl/Kj3WEPlqkkNecXCJl5MSiXSncM9XK0 IEG+DB+nFSpIFmkSx5EOS9GEREcZxb2fmcrXAenR0chNV/gl3qm3WQ7Dlmiln7bvL0Sk ltxxjYFr8MRVMUggljWT2DDJ6ThxrY4bCfelHTbs6VaLryI3YuFE2MFiUW2twzzxGafy Y90A== X-Gm-Message-State: APjAAAWGWP1CdoCeZVvwUTdQyJOIgFQqcV4QQGvS+jN8spm0KmzXfD5w rLOVDZC/BlmXqbh9POw5aSkEEf7RXaKtsrtoE4GheA== X-Google-Smtp-Source: APXvYqxzmZUJnGqFOuLTt0KHU2Maddve0NNMAnCbKPoyNBYPXd9XGojdAAEyeNCEqTADIup5MDQbt0pZlq0HE0Zouv4= X-Received: by 2002:ac2:5621:: with SMTP id b1mr4447520lff.27.1557452364636; Thu, 09 May 2019 18:39:24 -0700 (PDT) MIME-Version: 1.0 References: <20190503122143.GA26519@ubuntu-dmitri> In-Reply-To: <20190503122143.GA26519@ubuntu-dmitri> From: Jana Iyengar Date: Thu, 9 May 2019 18:39:13 -0700 Message-ID: Subject: Re: Duplicated TPs vs duped HTTP/3 settings To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000f2e72305887ea29a" 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, 10 May 2019 01:39:29 -0000 --000000000000f2e72305887ea29a Content-Type: text/plain; charset="UTF-8" Hi Dmitri, Your proposal sounds quite reasonable. Can you open an issue for it? This will be a design issue that will need consensus. - jana On Fri, May 3, 2019 at 5:22 AM Dmitri Tikhonov wrote: > Hello, > > A recent GitHub discussion [1] reminded me that duplicated transport > parameters MUST be treated as error [2]. This is in contrast to > duplicated HTTP/3 settings, which MAY be treated as an error. > > Why the inconsistency? > > The checks for duplicated transport (or settings) parameters are > expensive, because one has to maintain an arbitrarily-sized set > of possibly large numbers. > > I propose we switch the duplicate TP parameters enforcement to > "MAY treat as error." > > - Dmitri. > > 1. https://github.com/quicwg/base-drafts/issues/2663 > 2. https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-7.3 > > --000000000000f2e72305887ea29a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dmitri,

Your proposal sounds quite r= easonable. Can you open an issue for it? This will be a design issue that w= ill need consensus.

- jana

On Fri, May 3, 201= 9 at 5:22 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
Hello,

A recent GitHub discussion [1] reminded me that duplicated transport
parameters MUST be treated as error [2].=C2=A0 This is in contrast to
duplicated HTTP/3 settings, which MAY be treated as an error.

Why the inconsistency?

The checks for duplicated transport (or settings) parameters are
expensive, because one has to maintain an arbitrarily-sized set
of possibly large numbers.

I propose we switch the duplicate TP parameters enforcement to
"MAY treat as error."

=C2=A0 - Dmitri.

1. https://github.com/quicwg/base-drafts/issues/266= 3
2. https://tools.ietf.org/html/d= raft-ietf-quic-transport-20#section-7.3

--000000000000f2e72305887ea29a-- From nobody Fri May 10 00:31: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 110FA120177 for ; Fri, 10 May 2019 00:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLgrFfUEGvN7 for ; Fri, 10 May 2019 00:31:33 -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 D9FA4120125 for ; Fri, 10 May 2019 00:31:32 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id r76so4188454lja.12 for ; Fri, 10 May 2019 00:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5mnL05yEFjMVXeQ+HMGvVsbr3iNBE6p+KSAZxw8CPlA=; b=cIegoj+s/cvOdaj0udKFbfgctlIQ6ykJs2OpJLXIgb4GeAkDLiRswrjwmNGO+Cjoir Aw6Sqsz0Hxo3l3RPdLXHqxeHcOv4l3vFFoR0yv5BlKecBlNHpgigeQizZkwdMDsm8bZc o6Y1JDTjDXZfX9+nHPgvA+UUPN/oTVEQPRDos= 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=5mnL05yEFjMVXeQ+HMGvVsbr3iNBE6p+KSAZxw8CPlA=; b=R6CHgxkhIxUd2Q8LwdPEsT7XaQtN5EEVLEN96OZQw3moBV/hBPp16clzS9LhYF+W3t OJI+Miu6/7KHAEw1x6HVOgq7TslNhZ1J2RNla9HQ03ujyViupZbiR8J/Xg78UYXyGTdL Id/EhkD8tu2gxR6Dav9lrEZb1f5+xFCsVtixoVazjeNSoieaB9J9quezfagrifZFpbli CC4BmmKL9WjRbA1xM8OZVEha99cPb5QK8pzaJOBo7NMAKHvUr6DANu8nBKZc4rpYsKex jnAhBbRPEdffjTVDlfKxGAWM9WLks9wP6o1plga46oRUA+iOHJjTBLrwVkTp8fIGWEDz blew== X-Gm-Message-State: APjAAAW2wx8SxfbdNta3Gbn+e6QAmijzZB2FiPR8RWIuJo0N0wYQ2+Kf uGtMi9M2k4pPmGR+KrVdySWkx5yCh4u7mFVqHlBHIw== X-Google-Smtp-Source: APXvYqzdLPQzI0c2y1PEAPA9qORVo5llnkI4D/xFLmdEWGh/C0Z8OuRCDGxpFIAqFJxjxbxS7QQ0MS47/1yoiJ6bb9Q= X-Received: by 2002:a2e:3607:: with SMTP id d7mr4396620lja.188.1557473490715; Fri, 10 May 2019 00:31:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robin MARX Date: Fri, 10 May 2019 09:31:19 +0200 Message-ID: Subject: Re: QUIC Symposium : May 7 in Belgium To: Iyedi Goma Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002968ba0588838e95" 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, 10 May 2019 07:31:36 -0000 --0000000000002968ba0588838e95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, The slides and videos (and 1 new paper!) for the QUIC Symposium talks are now online on the website: https://quic.edm.uhasselt.be/symposium19/ We've had some excellent talks on a large variety of subjects. Contact information for most of the speakers can be found in the "introduction" slide deck. Feedback is always appreciated! With best regards, Robin On Mon, 6 May 2019 at 18:09, Robin MARX wrote: > Hello everyone, > > The QUIC Symposium will take place tomorrow. We have a great line-up of > local researchers giving a total of 10 talks! > We decided to Taunt the Gods (and Murphy) by trying to livestream the > event as requested here. > We will not provide the opportunity to ask questions remotely though. > > URLs for the YouTube livestream and more details about the talks can be > found at the website: https://quic.edm.uhasselt.be/symposium19/ > > After the event, we will also put the slides online and hopefully split > the livestream up into individual videos. > > With best regards, > Robin > > On Thu, 21 Mar 2019 at 20:51, Iyedi Goma wrote: > >> Great news >> >> I really hope we could have opportunity to follow the symposium remotely= . >> >> Regards >> Serge parfait Goma >> >> Le mer. 20 mars 2019 =C3=A0 18:18, Robin MARX a >> =C3=A9crit : >> >>> Hello everyone, >>> >>> We are organizing an informal QUIC (and HTTP/3) Symposium on Tuesday Ma= y >>> 7 in Diepenbeek, Belgium. >>> More information can be found at: >>> https://quic.edm.uhasselt.be/symposium19 >>> >>> During the excellent EPIQ workshop in Greece last December, we noticed >>> that there are a lot of academics working on QUIC in Belgium and German= y. >>> The main idea behind the Symposium is to bring together those >>> researchers and students and create a stronger local community. >>> However, anyone with an interest in the topic and the will and ability >>> to travel to Belgium is more than welcome. >>> >>> The goal is that anyone can present (early) results from their research >>> or practical experience, but there is also room for discussions, >>> brainstorming, small workshops/hackaton, etc. >>> You can request or offer content at our "Call for Papers": >>> https://goo.gl/forms/62SmRuSOR3zuREVn1 >>> >>> The event is free (including free lunch!) but we do ask that you >>> register before April 30. >>> This can be done at: https://goo.gl/forms/8brKkLXXhVl7UCJg1 >>> >>> We hope to see some of you there! >>> With best regards, >>> Robin Marx and Oliver Hohlfeld >>> >>> -- >>> >>> Robin Marx >>> PhD researcher - web performance >>> Expertise centre for Digital Media >>> >>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 >>> >>> www.uhasselt.be >>> Universiteit Hasselt - Campus Diepenbeek >>> Agoralaan Gebouw D - B-3590 Diepenbeek >>> Kantoor EDM-2.05 >>> >>> >>> > > -- > > Robin Marx > PhD researcher - web performance > Expertise centre for Digital Media > > T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 > > www.uhasselt.be > Universiteit Hasselt - Campus Diepenbeek > Agoralaan Gebouw D - B-3590 Diepenbeek > Kantoor EDM-2.05 > > > --=20 Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --0000000000002968ba0588838e95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

The slides and videos (= and 1 new paper!) for the QUIC Symposium talks are now online on the websit= e:=C2=A0https://quic.edm.uhasselt.be/symposium19/
We've had = some excellent talks on a large variety of subjects. Contact information fo= r most of the speakers can be found in the "introduction" slide d= eck.=C2=A0

Feedback is always appreciated!

With best regards,
Robin


On= Mon, 6 May 2019 at 18:09, Robin MARX <robin.marx@uhasselt.be> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hello eve= ryone,

The QUIC Symposium will take place tomorrow. We h= ave a great line-up of local researchers giving a total of 10 talks!=C2=A0<= /div>
We decided to Taunt the Gods (and Murphy) by trying to livestream= the event as requested here.=C2=A0
We will not provide the opportunit= y to ask questions remotely though.=C2=A0

URLs for the YouTube= livestream and more details about the talks can be found at the website:= =C2=A0https://quic.edm.uhasselt.be/symposium19/

A= fter the event, we will also put the slides online and hopefully split the = livestream up into individual videos.=C2=A0

With b= est regards,
Robin

On Thu, 21 Mar 2019 at 20:51, Iyedi= Goma <iyedigom= a@gmail.com> wrote:
Great news

I really hope we could have opportunity to follow the symposium r= emotely.=C2=A0

Regards
Serge parfait Goma

Le mer. 20 mars 2019 =C3=A0 1= 8:18, Robin MARX <robin.marx@uhasselt.be> a =C3=A9crit=C2=A0:
=
Hello everyone,

We are= organizing an informal QUIC (and HTTP/3) Symposium on Tuesday May 7 in Die= penbeek, Belgium.=C2=A0
More information can be found at:=C2=A0https://quic.edm.uhasselt.be/symposium19

During the excellent EPIQ workshop in Greece last December, we noti= ced that there are a lot of academics working on QUIC in Belgium and German= y.=C2=A0
The main idea behind the Symposium is to bring together = those researchers and students and create a stronger local community.
=
However, anyone with an interest in the topic and the will and ability= to travel to Belgium is more than welcome.=C2=A0

= The goal is that anyone can present (early) results from their research or = practical experience, but there is also room for discussions, brainstorming= , small workshops/hackaton, etc.=C2=A0=C2=A0
You can request or o= ffer content at our "Call for Papers":=C2=A0https://= goo.gl/forms/62SmRuSOR3zuREVn1

The event is fr= ee (including free lunch!) but we do ask that you register before April 30.=
This can be done at:=C2=A0https://goo.gl/forms/8brK= kLXXhVl7UCJg1

We hope to see some = of you there!
With best regards,
Robin Marx and Oliver = Hohlfeld

--
=
Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digita= l Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 9= 4
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""
<= td style=3D"font-family:Verdana,Geneva,sans-serif">PhD researcher - web per= formance
Robin=C2=A0Marx
E= xpertise centre for Digital Media
=C2=A0
T += 32(0)11 26 84 79 - GS= M +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit= Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05<= /td>
=C2=A0
3D""
=

--

Ro= bin=C2=A0Marx=
PhD researcher - web performance
Expertise centre for Digital Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
= =C2=A0
www.uhasselt.be
Un= iversiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2= =A0EDM-2.05
=C2=A0
3D""
=


--

= T = +32(0)11 26 84 79 - G= SM +32(0)497 72 86 94
Robin=C2=A0Marx
PhD researcher - web pe= rformance
= Expertise centre for Digital Media
=C2=A0
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campu= s Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
= =C2=A0
3D"=
--0000000000002968ba0588838e95-- From nobody Fri May 10 03:26: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 D5BCE120046 for ; Fri, 10 May 2019 03:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOX0OcAqfc1h for ; Fri, 10 May 2019 03:26:06 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 494B012002F for ; Fri, 10 May 2019 03:26:06 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id q15so2914457wmj.0 for ; Fri, 10 May 2019 03:26:06 -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=zBFg9LcdLVXUJYw623PGIzrjxGvLCA4kjMezMSllDg0=; b=YmCVSxp/PmhDZI/CmjiNK0XHbAKS62K9bMadlWmk8Vu09rWg1OvfFYAbExKHiIQ3jW FFjOmAzyt6P6XJWfNi6PcLgf96DFerKn/AwI4HeS8MU598E/1FmWcicUqmwDaSWLxgcl iu+v38S80gOwpoe10C7VKjL7UvEQ9yhy0+50lGe9WevO4x0CP+L0hKWX8egCrZhrxjMp EMR4f7UEFqve9v6UwIN6AmCZ1BbbVPaNO2b2kgxtbbexhGfUKF1BjdkoAgOhrRdGlIMi hVL5Zn16uhLmEpdP8+aFsPvwHgIrrg6gdwIJSUoTgKaWCo/Q4aJA8Zsuye4GAdsuW29o 3tjw== 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=zBFg9LcdLVXUJYw623PGIzrjxGvLCA4kjMezMSllDg0=; b=n1J47b8fkZQ3p/5UkM/xBJ/q0YbOYc4s4aswHd+IolF1/CZEnxOXGxbS5qd0/wfaYI gkG2PRSadd8s+SJj2TB5MfNeqbRJebdLqVW4VS2plqUoEpB+jGWfGKX8Zm4nNipM3UeR uBImRutRScZvK/vdy6kzLDpGo3Jc1K7CbP24IxSoXVWuvQpm6uHxEOjjXX8QuhKEWV3O bwjCB8kHpgqoqCp7uZKwjusOrtCOnTnp+K0ejDHI2Hf+KzAjNDGIZQn+9y0ALtNyxS9j Mx9ieGtSjlZTMxWja41hsGJIFoPLfqd/8Y+To430iwEL/+6CMJdGPA+HzKmhOaPo79RM xMQA== X-Gm-Message-State: APjAAAVXtG6t1dRBzQqxKWDyeOlsAUxFPEhwWN6jkuEyumBZ2kvO8AD4 FjIaPnWtKZiq6KMp818vmRflq/UFSfUyMp0UnbFkMQ== X-Google-Smtp-Source: APXvYqzsuNwhEcfDlZL2Rw86YQGNQ+irzZ53w9pOEiJSRvSegEzJj7+7T8Idx6izR689lZVvk3l3cx/Ovif/dNKH1FM= X-Received: by 2002:a1c:a3c2:: with SMTP id m185mr6094460wme.17.1557483964379; Fri, 10 May 2019 03:26:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Fri, 10 May 2019 06:25:51 -0400 Message-ID: Subject: Re: Output of the discard keys design team To: David Schinazi Cc: QUIC Content-Type: multipart/alternative; boundary="000000000000712122058885fe4c" 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, 10 May 2019 10:26:08 -0000 --000000000000712122058885fe4c Content-Type: text/plain; charset="UTF-8" Thank you for working through this with members of the design team and for writing this up so nicely. The PR looks great. *From: *David Schinazi *Date: *Tue, May 7, 2019 at 5:25 PM *To: *QUIC Hi everyone, > > The discard keys design team has reached consensus on how to move forward > with discarding keys, and has produced a PR to modify the spec: > > https://github.com/quicwg/base-drafts/pull/2673 > > In a nutshell, we leverage acknowledgments as an explicit signal that > indicates that an endpoint is in a given state, and use that to allow the > peer to make progress. We believe that this PR prevents the potential > deadlocks discussed in issues #2214 and #2267. > > Please let us know your thoughts in response to this email. > > Thanks, > David > --000000000000712122058885fe4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for working through this with members of the des= ign team and for writing this up so nicely.=C2=A0 The PR looks great.
=
From: David Schinazi <dschinazi.ietf@gmail.com>
D= ate: Tue, May 7, 2019 at 5:25 PM
To: QUIC
<= br>
Hi everyone,

The=C2= =A0discard keys design team has reached consensus on how to move forward wi= th discarding keys, and has produced a PR to modify the spec:
https://github.com/quicwg/base-drafts/pull/2673

In a nutshell, we leverage acknowledgments as an expli= cit signal that indicates that an endpoint is in a given state, and use tha= t to allow the peer to make progress. We believe that this PR prevents the = potential deadlocks discussed in=C2=A0issues #2214 and #2267.
Please let us know your thoughts in response to this email.

Thanks,
David
--000000000000712122058885fe4c-- From nobody Fri May 10 07:42: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 A03BF120248 for ; Fri, 10 May 2019 07:42:39 -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 (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 22ceuVhriYEK for ; Fri, 10 May 2019 07:42:37 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 49081120242 for ; Fri, 10 May 2019 07:42:32 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id d13so6849063qth.5 for ; Fri, 10 May 2019 07:42:32 -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=Z/QXSNjoY1v+KmCDR1kt4IHbMy07DZq+lxY5/Vlx5qw=; b=DO6vdyFdhsKE3ou/hMFDRM4VKwMppj4QHehfXo2hAm3Faelg27V3O24QIWyKQeyS6J HmGjcc5fki4S/eSTmOQ5xrD8qiOD6wA5jswxiLbujJUZcA5S7uv0O5DfwV2+rE1l7d7w LI8PJa7v5vfuTnins78ctC6YFkDkrGazMQBF9RlLPR6ACKIUzPwLSN1F0ZZ09E6iUjmH 1vJMG38QdwLat2zlDNlHAoMUFEW1Ou6ske1s6sRG20g9S2uXKSU9liWgBRl73LmolKaI QU7hXe5R+/ZD0cQuBgtKlHc87up9/90FoZL++9aF4HBqsr7KQiCgSaoph60Vxo51X7yO zejA== 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=Z/QXSNjoY1v+KmCDR1kt4IHbMy07DZq+lxY5/Vlx5qw=; b=eT7Pgn6dguhrr5/Cc+5kEaLx+QKoiw/VoSznTz3/JjbkcrVY6YFuf9K4hlyiEvxL0L ggBvfESOiaaz4gQs4AQYMR3c0hsvnTsmL2Ol0eySfPKbqzhFwpACJNKaVYY5GSWr728A /YaeUT93kmH2jLvJ2rmlJwiTMTRmz94n6NKZZ6RYGYKKIQUpzKBNCkQALsdU3e12Gaoq 7g7hA3Wd1bKRf1s4uwpa0nT+rCX+hKLbimW4fGroM6n8CboAMvA1uEuCUVoy/pSAjUCx seiO/krFP/lXmsNs0OsJNEnOQomUWlzfBwAsJjxqk20t0NGcmFTbH1ud5RQ6i3Y0mGWu r+vw== X-Gm-Message-State: APjAAAUD9aLNYyx3TkJqI+n0v8EqhrHY85kID8L9E2UFSVbArlLeF0NB DAj1tjnmBRlEHysuMFMPgq24EQ== X-Google-Smtp-Source: APXvYqx5FH7HnAIloOzGEyBsJOtrdNpnTx0SyEXahfoN2+o5eZEnd5gInLDxFYSSdxdcD6tNVKysjA== X-Received: by 2002:a0c:99d7:: with SMTP id y23mr9667496qve.0.1557499351344; Fri, 10 May 2019 07:42:31 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id w40sm3258692qth.35.2019.05.10.07.42.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 07:42:30 -0700 (PDT) Date: Fri, 10 May 2019 10:42:26 -0400 From: Dmitri Tikhonov To: Jana Iyengar Cc: IETF QUIC WG Subject: Re: Duplicated TPs vs duped HTTP/3 settings Message-ID: <20190510144225.GA11226@ubuntu-dmitri> Mail-Followup-To: Jana Iyengar , IETF QUIC WG References: <20190503122143.GA26519@ubuntu-dmitri> 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: Fri, 10 May 2019 14:42:46 -0000 Done: https://github.com/quicwg/base-drafts/issues/2689 Thank you, - Dmitri. On Thu, May 09, 2019 at 06:39:13PM -0700, Jana Iyengar wrote: > Hi Dmitri, > > Your proposal sounds quite reasonable. Can you open an issue for it? This > will be a design issue that will need consensus. > > - jana > > On Fri, May 3, 2019 at 5:22 AM Dmitri Tikhonov > wrote: > > > Hello, > > > > A recent GitHub discussion [1] reminded me that duplicated transport > > parameters MUST be treated as error [2]. This is in contrast to > > duplicated HTTP/3 settings, which MAY be treated as an error. > > > > Why the inconsistency? > > > > The checks for duplicated transport (or settings) parameters are > > expensive, because one has to maintain an arbitrarily-sized set > > of possibly large numbers. > > > > I propose we switch the duplicate TP parameters enforcement to > > "MAY treat as error." > > > > - Dmitri. > > > > 1. https://github.com/quicwg/base-drafts/issues/2663 > > 2. https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-7.3 > > > > From nobody Fri May 10 19:24: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 CE65A120229 for ; Fri, 10 May 2019 19:24:28 -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=QTWqnF4t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iXjopMF6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gmEpgAriAWJ for ; Fri, 10 May 2019 19:24:26 -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 B07501201F0 for ; Fri, 10 May 2019 19:24:26 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E4B3721FC1 for ; Fri, 10 May 2019 22:24:25 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 10 May 2019 22:24:25 -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=xBBM5o1f6IjIeEooJJZcqvaAVdNsIgM xfmc3jWQOQ48=; b=QTWqnF4tYTI+JSFlL3JArFj2vWaXTSihWKX8ifUSqEWDqMe K051TODqfmg2C1c/c6i1a6WHIPYCquWwI3An/MtKMF4HMVrqDtCSZdm2BDXZkzuZ eDD+IFGniEkyqVxr/wB43mDPysGioE534iEnBHFid4aREYRPEhL7Zvc3ulUMZMt3 LwzO1yAORwkAh+N75ScG1hYYpvfWWcLJloeptNSh2u1GDt5nqCMZz78gtriMnPq7 mD0E21QNdqnqFNXpHmplNF71PO0eEaJOV1fhcpviBxJukoQT+p4mZ5djwyGt/gQU knm0RlCnHiFcf7Je34AyVUi+vbacF+e/dM+8yvQ== 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=fm2; bh=xBBM5o 1f6IjIeEooJJZcqvaAVdNsIgMxfmc3jWQOQ48=; b=iXjopMF65aTj2yqfaDqwUP 6gFbViG3xkr3BIKNFBoe67LiyhpbF1HHDCH+L020l0D1ChjLYQ5Jbgi+nujMct8H i2AcsTgwFJbhmawQR3+7d4/ri+pTFZG0WCvh/HMkEb7u9/rHkzndfwGwtSe7i592 BHPCEyqGSHS/4ZRcECLqa2H1por/Bn2oG2uiFTinPWIilTAJJKurIn30QEZc2jaX ug1DD+M0V0W/QwC/Js1GCl+Z8eJ+lBvKYEy8S+ynGCGbVZ1AZOFOBGVGkUtvO6fv 3EY1Qwh6RNLChCjSAduLaj2l55Zxs0v6Ox1hVGZrR8/PjZBifKiFT47L1TUqvrjw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeelgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 404977C3DB; Fri, 10 May 2019 22:24:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <2026002a-c35b-4dcc-83a4-c7af19fc8369@www.fastmail.com> In-Reply-To: References: Date: Fri, 10 May 2019 22:24:25 -0400 From: "Martin Thomson" To: quic@ietf.org Subject: Re: Output of the discard keys design team 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: Sat, 11 May 2019 02:24:29 -0000 Yeah, I have to second Ian's praise here. This looks easy, but David has done a good job here. On Fri, May 10, 2019, at 20:26, Ian Swett wrote: > Thank you for working through this with members of the design team and > for writing this up so nicely. The PR looks great. > > *From: *David Schinazi > *Date: *Tue, May 7, 2019 at 5:25 PM > *To: *QUIC > > > Hi everyone, > > > > The discard keys design team has reached consensus on how to move forward with discarding keys, and has produced a PR to modify the spec: > > > > https://github.com/quicwg/base-drafts/pull/2673 > > > > In a nutshell, we leverage acknowledgments as an explicit signal that indicates that an endpoint is in a given state, and use that to allow the peer to make progress. We believe that this PR prevents the potential deadlocks discussed in issues #2214 and #2267. > > > > Please let us know your thoughts in response to this email. > > > > Thanks, > > David From nobody Fri May 10 23:41:44 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 68DDB120048 for ; Fri, 10 May 2019 23:41: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2fC412vNTt6 for ; Fri, 10 May 2019 23:41:40 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 7121112009C for ; Fri, 10 May 2019 23:41:40 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id s3so12875705itk.1 for ; Fri, 10 May 2019 23:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=F4HfFb1zH7PE6VlqPznWQHRS0uARugJtNWbuqCZUxWU=; b=rzu++5K94EBHs+LqaQFxEoXVIwXahCLY46CPUqhe/uPaPKU9siE+//qjpziu8gsbLz jrfLAuvflTyhwWD7yq+hVIbomcjsjgMUknrQJI2lEwCFGdKCx1yVZ8CSqk4bjU/9Wg8A w0OEEBoxbcx0gNG8QmeCaU3nBgylyjXTxKThaRhzP7qMbJMafS4QXtUx6jL7HFJsKvIi NcHmnsL0Ph1ls73YG2rFTxEj9xZuB/l/UQ7DfKpzkEBu2XJj9VEXo1DnjyPoMMYMRFiE SWcGR/u6IaFUhwzoPg8ZHBlgtXBheLaBRsmTvVvsH1WvN8EOhupxXbXpUGkp8Z+p/vf0 r8lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=F4HfFb1zH7PE6VlqPznWQHRS0uARugJtNWbuqCZUxWU=; b=lNHw+oW6LPc5hA+T65+C/fG9bqrWfcQIa7HoNpynksMCrODUpDJ56Vvlbvbh7Ak7vc GWBkHgYrC/Wngqgj/DdDpnd4mo6krZgFmoovwWPiDR28a/YNe09osR4KkvA8rtrM9L+e Bs/6EqkLV9fGDWPh6+EQ7JBLo0AJy68RUgdJsFLUo0e48VTLUsCkuzcbWgvGhISB17DW wQJ/kfyC6bt/tupCQHlrsXX0OFdke9PKr2woBa/UE8qKJBLFFLv7VPxe81qwq+ZlaXXa uv0H5lW/Fvul2D7YzEE3z50/nTYSTHaKCuiRPk/LIV2o3IGWaoba6RJpzC+SKgvLfgpJ tEYQ== X-Gm-Message-State: APjAAAU0QTQWXNG/T2aRzxrnVmIDzD9B5dZZHZhgOAcLYiNy7sLS8ng/ NKaJPJk7iBTTq5aZrR5KnfL8oglb6gmU5RTQV9TtkQ== X-Google-Smtp-Source: APXvYqzWaGZOwWfa3sDw5c2B+3so+KJTp6l6JscaXijEQXEVphe8SzZga82kZTepS7gpFQ5ZfLkBwaGWyqb2xKBbhVc= X-Received: by 2002:a24:5c83:: with SMTP id q125mr10577243itb.70.1557556899760; Fri, 10 May 2019 23:41:39 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 11 May 2019 08:41:38 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <2026002a-c35b-4dcc-83a4-c7af19fc8369@www.fastmail.com> References: <2026002a-c35b-4dcc-83a4-c7af19fc8369@www.fastmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 11 May 2019 08:41:38 +0200 Message-ID: Subject: Re: Output of the discard keys design team To: Martin Thomson , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba4f94058896f99c" 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, 11 May 2019 06:41:43 -0000 --000000000000ba4f94058896f99c Content-Type: text/plain; charset="UTF-8" Yes, the distinction between Handshake Complete and Handshake Confirmed is important. On 11 May 2019 at 04.24.43, Martin Thomson (mt@lowentropy.net) wrote: Yeah, I have to second Ian's praise here. This looks easy, but David has done a good job here. On Fri, May 10, 2019, at 20:26, Ian Swett wrote: > Thank you for working through this with members of the design team and > for writing this up so nicely. The PR looks great. > > *From: *David Schinazi > *Date: *Tue, May 7, 2019 at 5:25 PM > *To: *QUIC > > > Hi everyone, > > > > The discard keys design team has reached consensus on how to move forward with discarding keys, and has produced a PR to modify the spec: > > > > https://github.com/quicwg/base-drafts/pull/2673 > > > > In a nutshell, we leverage acknowledgments as an explicit signal that indicates that an endpoint is in a given state, and use that to allow the peer to make progress. We believe that this PR prevents the potential deadlocks discussed in issues #2214 and #2267. > > > > Please let us know your thoughts in response to this email. > > > > Thanks, > > David --000000000000ba4f94058896f99c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, the distinction= between Handshake Complete and Handshake Confirmed is important.

On 11 May 2019 at 04.24.43, Martin Thomson (mt@lowentropy.net) wrote:

Yeah, I have = to second Ian's praise here. This looks easy, but David has done a goo= d job here.

On Fri, May 10, 2019, at 20:26, Ian Swett wrote:
> Thank you for working through this with members of the design team= and =20
> for writing this up so nicely. The PR looks great.
> =20
> *From: *David Schinazi <dschinazi.ietf@gmail.com>
> *Date: *Tue, May 7, 2019 at 5:25 PM
> *To: *QUIC
> =20
> > Hi everyone,
> > =20
> > The discard keys design team has reached consensus on how to = move forward with discarding keys, and has produced a PR to modify the spec= :
> > =20
> > h= ttps://github.com/quicwg/base-drafts/pull/2673
> > =20
> > In a nutshell, we leverage acknowledgments as an explicit sig= nal that indicates that an endpoint is in a given state, and use that to al= low the peer to make progress. We believe that this PR prevents the potenti= al deadlocks discussed in issues #2214 and #2267.
> > =20
> > Please let us know your thoughts in response to this email.
> > =20
> > Thanks,
> > David

--000000000000ba4f94058896f99c-- From nobody Sat May 11 17:45: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 6A093120148 for ; Sat, 11 May 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=CfXSSyO8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=5smLzagg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykmVlBtQbCGC for ; Sat, 11 May 2019 17:45:24 -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 5D4B91200D8 for ; Sat, 11 May 2019 17:45:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 762EC2B5 for ; Sat, 11 May 2019 20:45:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 11 May 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= fm2; bh=e5WB0+VZCiN9u5ZZt1xXLCPJeNRHazT4vver1TWtUnQ=; b=CfXSSyO8 cEDoVs9p+WDDheJwEeUI7pXEbOnCj6TaYRufYTgrl0jh+PKRNkh3W7JPMITy+fBc UkK2S8YFEMMNnIYTc5bYd6gCtsuUrV3jdtmO5wG3e9E75AfYVubbEeAHIR1ejFuJ SQBCryQyB7LxyGK4hXk9HN5Xp4zl3gLxQoQMESH3mUTJyrLBrg58JmrNsy7IGdg3 QXvfLkVo98sScJhq1YXLZ9GS8eLpFnIEijAKOdaCHpB9zgtPASpH6AiHMGZMenGN PxScz39gmDkuWqziR8VfJdWnn4R45fuFYVUbWNmaSHP1M2iApfGr8eP611O7g1GL rp1MgZ188spdQA== 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=e5WB0+VZCiN9u5ZZt1xXLCPJeNRHa zT4vver1TWtUnQ=; b=5smLzaggI/RdAl5N4L9BzbMtKerC7dwRtBB+0hBWvvsg8 Do1WnWEBs7/NFVkOSe9tJlFh76eOkVHMBY1nqDcaMAkE7bQDHErOsQxu+gLIavxY DssULsA7+/3NbJ24qbo1zp4PWH2KevESu08zx1robAIixGPYkcAu592oK3ct5lgP LXBdt918/5hs4YNJHx77GcRWsQLIzwclYxCStR7Ntj+0fBYF9gX79wHdAT7zxx4+ S3RYknc3TQf5xWnwPYdFJhO+Oc8v3AmCjMRDMaEMmGCqGP6PaEFmuvFlKvqunNkF 2GHeNFlAitfvY3R29EMiazi8DtIYvT/PI2mkSC/OA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrledugdefjecutefuodetggdotefrodftvf 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 7FC38103CB for ; Sat, 11 May 2019 20:45:21 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id D4BD7C2393 for ; Sun, 12 May 2019 00:45:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============2143666831473282037==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190512004517.D4BD7C2393@cloud.mnot.net> Date: Sun, 12 May 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, 12 May 2019 00:45:28 -0000 --===============2143666831473282037== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+5/-2/=F0=9F=92=AC89) 5 issues created: - Checking duplicate TPs is onerous (by dtikhonov) https://github.com/quicwg/base-drafts/issues/2689 = - Pacing when under-utilizing the Congestion Window (by gorryfair) https://github.com/quicwg/base-drafts/issues/2686 = - CC state after a change of path? (by gorryfair) https://github.com/quicwg/base-drafts/issues/2685 = - Section 9.4: Contains a mixture of transport and congestion control fun= ctions (by gorryfair) https://github.com/quicwg/base-drafts/issues/2684 = - DUPLICATE_PUSH push ID validation (by LPardue) https://github.com/quicwg/base-drafts/issues/2681 = 17 issues received 89 new comments: - #2670 Remove ack_delay_exponent TP (24 by kazuho, janaiyengar, mikkelfj= , nibanks, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/2670 [-transport] [has-pro= posal] = - #2502 PRIORITY frame on control stream referencing unopened request str= eam (17 by kazuho, pmeenan, MikeBishop, ianswett, rmarx, LPardue) https://github.com/quicwg/base-drafts/issues/2502 [-http] [editorial] = - #2308 handling of coalesced packets with decryption errors creates DoS = opportunity (9 by igorlord, janaiyengar, kazuho, huitema, mikkelfj) https://github.com/quicwg/base-drafts/issues/2308 [-transport] [design] = - #2686 Pacing when under-utilizing the Congestion Window (8 by janaiyeng= ar, ianswett, gorryfair, mikkelfj) https://github.com/quicwg/base-drafts/issues/2686 = - #2403 The number of Connection ID is unbounded to NEW_CONNECTION_ID sen= der (5 by martinthomson, tatsuhiro-t, mnot, ianswett) https://github.com/quicwg/base-drafts/issues/2403 [-transport] [has-pro= posal] [invalid] = - #2630 Define "under-utilization" of cwnd (4 by janaiyengar, gorryfair) https://github.com/quicwg/base-drafts/issues/2630 [-recovery] [design] = - #2672 Transport error codes would be smaller and more consistent as a v= arint (4 by kazuho, LPardue, ianswett) https://github.com/quicwg/base-drafts/issues/2672 [-transport] = - #2689 Checking duplicate TPs is onerous (3 by ianswett, janaiyengar, Mi= keBishop) https://github.com/quicwg/base-drafts/issues/2689 [-transport] = - #2645 Retire My Own CID (3 by nibanks, janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/issues/2645 [-transport] = - #2360 0-RTT flow control limits can't be increased (2 by mnot, MikeBish= op) https://github.com/quicwg/base-drafts/issues/2360 [-transport] [design]= [has-proposal] = - #2644 RTT measurement using PATH_* frames (2 by janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/2644 [-recovery] [editoria= l] = - #2654 Section 9.4 of Transport contains transport and congestion contro= l functions (2 by larseggert, gorryfair) https://github.com/quicwg/base-drafts/issues/2654 [-transport] [invalid= ] = - #2678 Unidirectional stream (some or) all the control things in HTTP/3 = (2 by kazuho, dtikhonov) https://github.com/quicwg/base-drafts/issues/2678 [-http] [design] = - #2593 Persistent congestion interaction with app limited state (1 by ia= nswett) https://github.com/quicwg/base-drafts/issues/2593 [-recovery] = - #2220 Move HTTP Section 5 before Section 4 (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2220 [-http] [editorial] = - #2410 H3 guidance on malformed request/response is light (1 by kazuho) https://github.com/quicwg/base-drafts/issues/2410 [-http] [design] = - #2681 DUPLICATE_PUSH push ID validation (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2681 = 2 issues closed: - Section 9.4 of Transport contains transport and congestion control func= tions https://github.com/quicwg/base-drafts/issues/2654 [-transport] [inval= id] = - The number of Connection ID is unbounded to NEW_CONNECTION_ID sender ht= tps://github.com/quicwg/base-drafts/issues/2403 [-transport] [has-proposal]= [invalid] = Pull requests ------------- * quicwg/base-drafts (+8/-0/=F0=9F=92=AC21) 8 pull requests submitted: - Relax requirement of detecting duplicate TPs on receiver (by janaiyenga= r) https://github.com/quicwg/base-drafts/pull/2691 = - Placeholder -1 (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2690 [-http] [design] = - Clarify server CONNECTION_CLOSE with Handshake (by ianswett) https://github.com/quicwg/base-drafts/pull/2688 = - New paths may seed initial_rtt (by ianswett) https://github.com/quicwg/base-drafts/pull/2687 [-recovery] = - Pull some H2 content into the introduction (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2683 [-http] [editorial] = - Allow AES_128_CCM_8 in QUIC (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2682 = - Change error codes from 16-bit to varints (by ianswett) https://github.com/quicwg/base-drafts/pull/2680 [-transport] [design] = - change the ack delay exponent to an ack delay multiplier (by marten-see= mann) https://github.com/quicwg/base-drafts/pull/2679 = 6 pull requests received 21 new comments: - #2642 Don't send PING in Initial or Handshake (7 by martinthomson, ians= wett, janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/pull/2642 [-recovery] [design] = - #2679 change the ack delay exponent to an ack delay multiplier (5 by ma= rtinthomson, marten-seemann, mikkelfj) https://github.com/quicwg/base-drafts/pull/2679 [design] = - #2676 ignore the ack delay in Initial and Handshake packets (3 by marti= nthomson, marten-seemann) https://github.com/quicwg/base-drafts/pull/2676 [-recovery] [editorial] = - #2680 Change error codes from 16-bit to varints (3 by LPardue, ianswett) https://github.com/quicwg/base-drafts/pull/2680 [-transport] [design] = - #2677 Trigger unhappy (2 by janaiyengar, LPardue) https://github.com/quicwg/base-drafts/pull/2677 [-http] [editorial] = - #2673 Output of the discard keys design team (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2673 [-transport] [design] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============2143666831473282037== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday May 12, 2019

Issues

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

5 issues created:

17 issues received 89 new comments:

2 issues closed:

Pull requests

quicwg/base-drafts (+8/-0/=F0=9F=92=AC21)

8 pull requests submitted:

6 pull requests received 21 new comments:

Repositories tracked by this digest:

--===============2143666831473282037==-- From nobody Mon May 13 13:58: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 16D541200B9 for ; Mon, 13 May 2019 13:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN5htfi5-4Iv for ; Mon, 13 May 2019 13:58:26 -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 D08BE12006A for ; Mon, 13 May 2019 13:58:25 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id 198so679014wme.3 for ; Mon, 13 May 2019 13:58:25 -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=GPlHfKDLMVf4clZcu39qq7o3YBwt73fEZYysZ/7npL0=; b=rBNHjpstmGQtKsLPpGkfSX/mL+n4mLU7p8hCXNj3+NAd4sNpv+9w6wnC0VmUq12CFF GHeTfJT8yUT3Qx0MR8H2KGxfsKnT33U8fl4gAti9YMmn4D0WXbh9xKxU0z3+JSNqZia+ eKJzSZInXZh2qPRTpnG8grCLIsuYjHm0Cp+lQgZS3GU5SeuzT/Z3t3J0SXc9V0HWRif1 G2IoX7TGwloCJ+6SuiT4+m9zxh/V/f6J9S9F/JCnk1i6GHf3gua9k/esF0+BV75Pkhrm N4F5HSBbM6hnqyXLgEVSxUvdu/0DxWRNi2W8+OlbNNc9JanQri/yo+IdXley3fUbxbxk FFPA== 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=GPlHfKDLMVf4clZcu39qq7o3YBwt73fEZYysZ/7npL0=; b=TGs348/RHjnYWp9eW8WIlPLdANLjn1K67n4e6pgTvlokLKJIUxWv1qpEKcJS4n7oNj nFyuBZReOL0Kj1XWbm7n+yxRT6HPnlTqZBxVVNLmJiuqzptoA7gbl1aQ2Vf4NHKJQ+iO qkOJ5H/HRFaVsFegKGUZSQB7QNUwAndC+0BnBgpclACvGfOpZZtbP3hxOphoRNd4nW95 3jd57E8vp0AiIHZAH4opDGZ4PkcmqkjMkktnjk84gaxMiiEvSPH3JeD7T1P774ttSo+Y 3i9XpHBS1DpoykrCFsIKa6drxYaPU04awRjCrkVSzGamj3Dgcab+1GIderVktgleS4xZ xioQ== X-Gm-Message-State: APjAAAWg/wGO1vXwc89pKhiAxR5n9T8BbrrS8CRc2dClGRYlGpuzjC5R FHOQToOE8oFoU2AbVWOj80FXU3sL7DXExj8c1wEgzQ== X-Google-Smtp-Source: APXvYqwHwvbPaiRT9/iSd0XneojZ078BO7oPHCb96Pq8gBQWes/Q2Q9bGwMQtUK/3L6O897pxzQpUOXrrKsQDwOTYiE= X-Received: by 2002:a1c:ca0b:: with SMTP id a11mr17204188wmg.52.1557781104131; Mon, 13 May 2019 13:58:24 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Mon, 13 May 2019 13:58:12 -0700 Message-ID: Subject: Big TP codespace To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000005982dc0588cb2d91" 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, 13 May 2019 20:58:28 -0000 --0000000000005982dc0588cb2d91 Content-Type: text/plain; charset="UTF-8" Here's an annoying part of the transport parameter spec: There are 2^16 possible TPs and I should handle them all gracefully, but the highest standard one is 13. I also MUST blow up the connection if there's a duplicate TP. For 13 TPs, I can very easily check for duplicates with a 16-bit field. But to meet this requirement, I need an 8KB field or a fancier, more time-consuming data structure, which is really cumbersome. If I'm actually supporting a handful of experimental TPs, it's easy to track those by exception. What I'd propose is that we MUST end the connection if there's a duplicate of any of the TPs I actually support. What do people think? --0000000000005982dc0588cb2d91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's an annoying part of the transport parameter spe= c:

There are 2^16 possible TPs and I should handle them = all gracefully, but the highest standard one is 13. I also MUST blow up the= connection if there's a duplicate TP. For 13 TPs, I can very easily ch= eck for duplicates with a 16-bit field. But to meet this requirement, I nee= d an 8KB field or a fancier, more time-consuming data structure, which is r= eally cumbersome.

If I'm actually supporting a= handful of experimental TPs, it's easy to track those by exception. Wh= at I'd propose is that we MUST end the connection if there's a dupl= icate of any of the TPs I actually support.

What d= o people think?
--0000000000005982dc0588cb2d91-- From nobody Mon May 13 14:05: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 A45421200E6 for ; Mon, 13 May 2019 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARdkQu-L7aRr for ; Mon, 13 May 2019 14:05:56 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 A878412006A for ; Mon, 13 May 2019 14:05:55 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id w8so14378789wrl.6 for ; Mon, 13 May 2019 14:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ftPBIKm/HN3kJP5Tb1Q8sNczPAkPQdFQkZSbyVtvfFs=; b=QhGHc/syInFXimOQ46qdqeYT8cGtbHfcfGrfZTsAbvbR2oNIQmjcPJA35mEvdo9+5M LhkNf19Vzy1NAv9xXt9Fq1NGjT+Uc9e4aMaHaR5Z4uFwN4f3MKKTnvzpeez+cVmpdMMT Q3NTzYX65+OttvU4n7fAX4DB3v0iACSHnPCYSNAxvKy8MT0ccePQrq9p4ALTQl3smQyU sFMjbY1l55ZBVPGJkRAuXa5mahgBoXt84iacHY2Dunmpf16KbNmSL6gB1kvEchOoAsFT kswz5hM/idBZfgaWqvRiRYUCa3Y+Xkoc2UqKMtO1kbxvSv+rT4eq0OHAjl1PJonZalNh X1MQ== 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=ftPBIKm/HN3kJP5Tb1Q8sNczPAkPQdFQkZSbyVtvfFs=; b=K0aO2g8+ewG+96Y4PmIrBzptmt6p8qL82jPnUI4HlV8qrpQ9/sfzrcL1bF9fA/o/3V SysEHcPn3ZNZyVHFDCD8785fZL/UENvDWy1MCqWmAngl2sN/pudcf33Lxz+FWA0VghgU DeNFqn/Whi3lc8PN21zWfcA2WOMD3pbALgI3SRWGOjybnwCWx9BmIodteH3KEdtrpm+2 01h526KE+aeGNPRMJCLhTuPVOg9RC6PfYo5iU/YHgL7iSKpvmvxClulZXRJnfLYBnpJ8 y8keYL6QSRRXBf7qw4sFZa+GVmKIFUelNRlAfgYhBQsRlXkBdGUXF1b5Mlj2E0i5VM5C JvEg== X-Gm-Message-State: APjAAAUqqajmLFQHFiWF76jmwYdL/vbCjShwk4FUINS3nUkIJXiqys3D CIA1S5OJSZc9Fpr5qTKNzsM/YMmMe5mhTDjmeDYpJ4QS3Kg= X-Google-Smtp-Source: APXvYqxM0gnfMDRk3PUM9fuMczNblbQ748HMRg7elOZcF0oI1lFVdAPBrri6j1nklBPzReznoFRE9plOG80pi/IM1bg= X-Received: by 2002:adf:ec51:: with SMTP id w17mr20044097wrn.326.1557781553999; Mon, 13 May 2019 14:05:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matt Joras Date: Mon, 13 May 2019 14:05:42 -0700 Message-ID: Subject: Re: Big TP codespace To: Martin Duke 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: Mon, 13 May 2019 21:05:58 -0000 On Mon, May 13, 2019 at 1:58 PM Martin Duke wrote= : > > Here's an annoying part of the transport parameter spec: > > There are 2^16 possible TPs and I should handle them all gracefully, but = the highest standard one is 13. I also MUST blow up the connection if there= 's a duplicate TP. For 13 TPs, I can very easily check for duplicates with = a 16-bit field. But to meet this requirement, I need an 8KB field or a fanc= ier, more time-consuming data structure, which is really cumbersome. > > If I'm actually supporting a handful of experimental TPs, it's easy to tr= ack those by exception. What I'd propose is that we MUST end the connection= if there's a duplicate of any of the TPs I actually support. > > What do people think? Isn't this covered by https://github.com/quicwg/base-drafts/issues/2689? Matt Joras From nobody Mon May 13 14:06:49 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 D5DFD1200E6 for ; Mon, 13 May 2019 14:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR9cokxut5DL for ; Mon, 13 May 2019 14:06:45 -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 4843112006A for ; Mon, 13 May 2019 14:06:45 -0700 (PDT) Received: from xsmtp11.mail2web.com ([168.144.250.181]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hQI9i-0005nW-0D for quic@ietf.org; Mon, 13 May 2019 23:06:43 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp11.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hQI9f-0002Eg-6F for quic@ietf.org; Mon, 13 May 2019 17:06:39 -0400 Received: (qmail 19832 invoked from network); 13 May 2019 21:06:37 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 May 2019 21:06:37 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Mon, 13 May 2019 14:06:35 -0700 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Duke Subject: Re: Big TP codespace X-Originating-IP: 168.144.250.181 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0XJZQFAmqAilMiozUWhfaCSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59ft+O9RwDzbkVeAbCF+jwhdY/sevPPdLVvjz7b14RFNIS30ONArWHUY/dwk7 0VyeflhTPSw+CekCTYoDa8nAx3W503+K7Ju/qxRhvHDAT5LyR61Qv/sjUDXLdm6w1gNv1euKTrwh UfUHUrPvTkTGu7YwVDQ0hbqcLWUbjgHMZS6COdI/uLAeALf3vLWnw0F/4+fmuTv/CYIzmchrGsA6 CN6O7qbWTdT56xh4Rya20+oBtwahqtg42IMQXC/e/thfmehs05Web8nJyEMtLxwhnYinDFrKlNc7 qNKmpnIY9d8cOJUa+B0z/Xg2ESGxDSOWWoTyIUtK8Miz//+1AD61I8sOcFFSGcngeU5u06zO01Ld 6NjlDHh8k6TTdHl8m1/8O//LcKgaYLn9Y2q9E0HrGD+jCxD87nTuKNDHZcdemthLkqDpZM3xHzQl xdue7fUC9q7F1XmBPhxEiL0yttQP9uki5/U5VEu6WXZTQHS449Z7XKgMOlMXouVH2CIVZDts2T7H eSzVrzv/acBM9KS0WP7inBWQPIehIGHmXDmzMq4X2rV+rVDNpQlPgj2UsWgdCMlErSs0X3oyoTc8 j/o7qulxsTYEnr45ya3Uk8GnAJ4jBIaPmF/7MAKyW1Kb4FKGpjTaUtnUcHrOeGzbCj2VUybf9KSX azc67cH0cTVlK0hzzWT8ejMS+MvVWyYUud5TQz0CdtHHho6eOcc1DLlOtNr7w6nIoDr0sXUZ7YZo Z/GZ+uzRF59HP/BJhHTXmEFmma55NKotYZMP4QxilpD1WJVxdwYWcRoGRTsLxqa8TRmmuv9qwM7R XpJS8RjTdyh2j5DIweuSooT6tSPU1x5zpUpIPziDkWQ5faPk5nJXHz00MDRj9D8HLKHAKpPGP8EP nuB53cHIFHavQpo3FUDrLYIQ 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, 13 May 2019 21:06:47 -0000 =20 > On May 13, 2019, at 1:58 PM, Martin Duke wrote: >=20 > What do people think? I think the general rule of protocol policing should be "MUST NOT" do dastar= dly stuff, and "MAY" drop the connection when that happens. -- Christian Huitema=20= From nobody Mon May 13 17:19: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 56BDD120026 for ; Mon, 13 May 2019 17:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulgw6pTVvJvC for ; Mon, 13 May 2019 17:19:35 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D83E120088 for ; Mon, 13 May 2019 17:19:34 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id 188so12629044ljf.9 for ; Mon, 13 May 2019 17:19:34 -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=EKE6ojGLm5KdGbwtXyXwbDU20Es4qaw9QE+IvzNQGBc=; b=dpYS9B8vLucIUofM8kdEzTLqq1M62n9gz50utk48LlvSkdt14NRLXTKNG/lmyW943j KK75rrYWb7W+rZVVHknvUnS9kcyShO6FFMkT0B4PIGmXB2DNNK18/dyKjvgPjwYO+Eyo Z0HXPzDzqBhFk2GBIzDmrPghHcu+jvGaN1vkGZWtf99AMWim41NiLx5h/+/9ry9eruXW ytOCtF1wBnr9gcs/6awuZmyD8bkmvIZv97fXODNFCMC8zOTtTLBd4p6fOqmi/e7Eiffs LlHiwD07vvJWC8kSe8uE5T4At1BzXj6qcBwGISzrxs+z3Kd/tijEWS+Cpfc0xJlBnQBa i6NQ== 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=EKE6ojGLm5KdGbwtXyXwbDU20Es4qaw9QE+IvzNQGBc=; b=gkMHmz9XISK3hZxjKAG98R4+dLgk7jjFSwotjmeg9fvnN08Chw2unna9NIqf3DBRP+ GuscUmEkhQ4Fldn3wLfxSh9TSyNqFAqQA9AoVdLhQBmbP6o+Bk1FrbweOHXiygYiTB+T XWI+DKPeoI9dKWPAwMKkqybdfuR2j40XRXrwaiFwXTq2JiTTAjZyZF3fFFUt8YuEJ7AD hxOgmUhFUwjRKuh3JC4x1Q+JdUPO4UNrgjQdcATMqB3KZW4Sfu7/e2483x4AFS5/axqV TaYJblJO5mHQby/3SA08U3YVOIMcy0ohaBLL0FD4CBYjFzFf9qDMPb5PPDy9cbqBnn7c qvEQ== X-Gm-Message-State: APjAAAXHpIYvKEktTLr15TueOnJjSpi4ldb0GLlmzf/SZV64Wk7Ie64r 5y98WeE/EFiS1T3T28KGDuXSy76CTnQaMZ5OLvU= X-Google-Smtp-Source: APXvYqzyEJ8Ec+E7qwzcJ+2uYRZbYt6iuGDnWl+L6w1wPanysdXimzY4qeVfZ1BTq2U1iJwnxnukXW1LaFGadlVBqH8= X-Received: by 2002:a2e:91c3:: with SMTP id u3mr15011573ljg.130.1557793172718; Mon, 13 May 2019 17:19:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 13 May 2019 17:19:21 -0700 Message-ID: Subject: Re: Big TP codespace To: Christian Huitema Cc: Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b189ae0588cdfce3" 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, 14 May 2019 00:19:38 -0000 --000000000000b189ae0588cdfce3 Content-Type: text/plain; charset="UTF-8" Our implementation checks for duplicates only for the transport parameters it supports. I think #2691 is the correct solution. +1 to the design principle of encouraging but not requiring detection of errors like this David On Mon, May 13, 2019 at 2:06 PM Christian Huitema wrote: > > > > On May 13, 2019, at 1:58 PM, Martin Duke > wrote: > > > > What do people think? > > I think the general rule of protocol policing should be "MUST NOT" do > dastardly stuff, and "MAY" drop the connection when that happens. > > -- Christian Huitema > --000000000000b189ae0588cdfce3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Our implementation checks for duplicates only for the tran= sport parameters it supports. I think #2691 is the correct solution.

+1 to the design principle of encouraging but not requiring detecti= on of errors like this

David

On Mon, May = 13, 2019 at 2:06 PM Christian Huitema <huitema@huitema.net> wrote:
=C2=A0

> On May 13, 2019, at 1:58 PM, Martin Duke <martin.h.duke@gmail.com> wrote:<= br> >
> What do people think?

I think the general rule of protocol policing should be "MUST NOT"= ; do dastardly stuff, and "MAY" drop the connection when that hap= pens.

-- Christian Huitema
--000000000000b189ae0588cdfce3-- From nobody Tue May 14 17:21: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 6607712009E for ; Tue, 14 May 2019 17:21:52 -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] 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 loWfHi5FC6Ee for ; Tue, 14 May 2019 17:21:50 -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 0D5C612004C for ; Tue, 14 May 2019 17:21:50 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id m20so879071lji.2 for ; Tue, 14 May 2019 17:21: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=WJednx4Sm9gthKlzlNHOEkdmyiMbPwvA7eEDigmGsVo=; b=mbmMwb6jH6ya1xJ8v3sOMIgBg+qMrP48uTr+P97et4pMTLnmHJX59kPI2sIsImT3g3 iUQsroGzFaVhrwTI+TLb2J5EFhJY/M9IH++LH+p3w7hQmaKYpRc18WB7l6vJY/N+7pSg +0sXBFt0Q583ATX7qKozVYyKss22ccHmO5q3H7Sr20xXAvdfanjZRJjCschPeSzT1hoX +nqgh20I3s6w1ilSGrtukYk9VcY6AKzMEcNTf2hz0vV/mcV+WTZFJvmNASFBqLcExIe7 wvdxx3zq+8ZvzfWpzn0/qofSdgUdn+vKOVMLBfQuMsjgF9xcDlq53qmendi2m2wF/ECp 9WSw== 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=WJednx4Sm9gthKlzlNHOEkdmyiMbPwvA7eEDigmGsVo=; b=Invsl5fa4K42UHgd/z3LUkpc8JfDr8pyG9uB8BeoTGl9fWFACNfOywk572xg3obpml xYBzwUa9Eh+VZEaXZM4Hq4loFzmePLZraOY3ER2fnbuNynYK+iDXGRhJ4poSPI227NPX vjTHe7pw/0RKnL8YlA0M+gqOluLmM91bd71SZ88YoxWry3cE4doItUqtk0cZmvmznR4/ ZRzfd8IP+QPB9DbHZ9Ec38p7TPYAU1ohTT3yR32ez193PjTfcMCr7tIGkp1Oo0CmcZVp dSSLdP58CgCpRkwYzeaJU623uCtHZoTcvx4WieYCSehTJPTxamurHTSsMyJFYWS4s4Jc xuWg== X-Gm-Message-State: APjAAAUUdZM/Nj96FEDxuRMJlbrvS+7hLicK/dAW3O8D22Ax+TpFEhmG jjV9KVzogTol32iMMOiDJsod6ITEfAsQrY+Tzj9Bcw== X-Google-Smtp-Source: APXvYqxqweHy4KugpNe8rD/ahnouLzAiRFba7ykM3hoRq0oOlKMAeQhfVCTge1g9LITIQSMglsH4Njsd7cZCZvbbCcg= X-Received: by 2002:a2e:860a:: with SMTP id a10mr9370051lji.158.1557879708334; Tue, 14 May 2019 17:21:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 14 May 2019 17:21:11 -0700 Message-ID: Subject: Re: Big TP codespace To: David Schinazi Cc: Christian Huitema , IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="0000000000009e55870588e22268" 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, 15 May 2019 00:21:52 -0000 --0000000000009e55870588e22268 Content-Type: text/plain; charset="UTF-8" What's the bigger principle you are endorsing? What errors "like this" are we not requiring detection of? On Mon, May 13, 2019 at 5:19 PM David Schinazi wrote: > Our implementation checks for duplicates only for the transport parameters > it supports. I think #2691 > is the correct > solution. > > +1 to the design principle of encouraging but not requiring detection of > errors like this > > David > > On Mon, May 13, 2019 at 2:06 PM Christian Huitema > wrote: > >> >> >> > On May 13, 2019, at 1:58 PM, Martin Duke >> wrote: >> > >> > What do people think? >> >> I think the general rule of protocol policing should be "MUST NOT" do >> dastardly stuff, and "MAY" drop the connection when that happens. >> >> -- Christian Huitema >> > --0000000000009e55870588e22268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's the bigger principle you are endorsing? What er= rors "like this" are we not requiring detection of?

=
On Mon, Ma= y 13, 2019 at 5:19 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Our implementation check= s for duplicates only for the transport parameters it supports. I think #2691 is the correct solution.

+1 to the desig= n principle of encouraging but not requiring detection of errors like this<= br>

David

On Mon, May 13, 2019 at 2:06 PM Chr= istian Huitema <huitema@huitema.net> wrote:
=C2=A0

> On May 13, 2019, at 1:58 PM, Martin Duke <martin.h.duke@gmail.com> wrote:<= br> >
> What do people think?

I think the general rule of protocol policing should be "MUST NOT"= ; do dastardly stuff, and "MAY" drop the connection when that hap= pens.

-- Christian Huitema
--0000000000009e55870588e22268-- From nobody Wed May 15 10:20: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 3E4EF1203A8 for ; Wed, 15 May 2019 10:20:44 -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 iyXMaz-kMg1b for ; Wed, 15 May 2019 10:20:40 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680129.outbound.protection.outlook.com [40.107.68.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 ACDBB12039E for ; Wed, 15 May 2019 10:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UNaxoPmnxRFxDApV+G96DpmNVPRhfxyABq8vYmdv/D4=; b=BppnqRgslH4eKjQ0A3rFQNE5dVOE12LtL/kF2ZNTBTe7OSj13B+/ySqiuN07qf+rfJCPZEimlN6uIGgE3ejqMgTJQ+cDnpyDqvvZRgNjRsg/XJHz6qKmILUkLST+pR7c/YTspIjOtFw06YH4ZIML+u3BvuXJFuL0tsVR9G0KT0o= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.164.151) by CY4PR22MB0502.namprd22.prod.outlook.com (10.172.141.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.24; Wed, 15 May 2019 17:20:35 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::5e:10a3:8225:425]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::5e:10a3:8225:425%5]) with mapi id 15.20.1878.024; Wed, 15 May 2019 17:20:35 +0000 From: Mike Bishop To: Eric Rescorla , David Schinazi CC: IETF QUIC WG , Christian Huitema , Martin Duke Subject: RE: Big TP codespace Thread-Topic: Big TP codespace Thread-Index: AQHVCc6oZAwMXA1OvUK2tAABvpSGsaZpi+GAgAA13ICAAZLYgIABD22w Date: Wed, 15 May 2019 17:20:35 +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: 64e43833-dc1f-4ce5-1bf7-08d6d959a4ba x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR22MB0502; x-ms-traffictypediagnostic: CY4PR22MB0502: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39830400003)(136003)(376002)(346002)(366004)(199004)(189003)(5660300002)(14454004)(8936002)(52536014)(73956011)(66556008)(508600001)(26005)(81156014)(81166006)(8676002)(3480700005)(7736002)(74316002)(66066001)(66476007)(86362001)(25786009)(7116003)(790700001)(6116002)(3846002)(64756008)(76116006)(66946007)(66446008)(53546011)(606006)(14444005)(53936002)(74482002)(6506007)(229853002)(33656002)(6306002)(4326008)(6436002)(68736007)(186003)(236005)(9686003)(55016002)(54906003)(486006)(110136005)(256004)(11346002)(446003)(476003)(102836004)(54896002)(6246003)(76176011)(7696005)(99286004)(316002)(71200400001)(2906002)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0502; 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: eq3gVmSWeGPorn9/SJfPgEtcutGKSqLFr3an4676/qPOu7z9RuP/4hd7bgijt76cfL6LR+IZjYkI+oxeNzNT5UTr9/RBGghdhzn3a0ZU/OArmASt6PlADbRYfmWfeE4tMO4xFKIKbuYJSEPoZu4JFgmT3ZVcQK/HtgFWsm8slXUDIBexNtM6bjjfib1bV1g7UQiOatHn5IEpgpuAzTxSfpQSSVH45HiHqZWXY3I0yJ8z+q+FMoD4YPaxZKTVC1ZZRO2zOFkIrNBljFLTZDIBTrrpKTzGewl1GPwrsMz0ne0gT0J0/JsTPU6lPPylJApCg792iPOtFYUlOikKt5UcwDzXPMTy/zzSGKlLI74+SHrty/EKKJ9Uyalrd1N0R5n/vIB9wDTWCEcvJToNq0ZaxuRAQy3UnVeM58a2+KDglL4= Content-Type: multipart/alternative; boundary="_000_CY4PR22MB0983FBE5C72EF1D46DAC27ECDA090CY4PR22MB0983namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 64e43833-dc1f-4ce5-1bf7-08d6d959a4ba X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2019 17:20:35.7099 (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-Transport-CrossTenantHeadersStamped: CY4PR22MB0502 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, 15 May 2019 17:20:44 -0000 --_000_CY4PR22MB0983FBE5C72EF1D46DAC27ECDA090CY4PR22MB0983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgYWdyZWVkIGluIFRva3lvIHRoYXQgd2Ugd291bGQgbm90IG1hbmRhdGUgdGhhdCBpbXBsZW1l bnRhdGlvbnMgY2hlY2sgZm9yIGltcHJvcGVyIHBlZXIgYmVoYXZpb3Igd2hlbiBkb2luZyBzbyBy ZXF1aXJlZCBzdWJzdGFudGlhbCBleHRyYSB3b3JrLiAgSW1wbGVtZW50YXRpb25zIE1VU1QgZXJy b3Igb3V0IG9uIGVhc2lseS1kZXRlY3RlZCBlcnJvcnMsIGJ1dCBvbmx5IFNIT1VMRC9NQVkgZXJy b3Igb24gdGhpbmdzIHRoZXkgd291bGQgaGF2ZSB0byBhY3RpdmVseSBjaGVjayAodW5sZXNzIHRo ZXnigJlyZSBhbHJlYWR5IHJlcXVpcmVkIHRvIGFjdGl2ZWx5IGNoZWNrIGZvciBzZWN1cml0eSBy ZWFzb25zLCBpbiB3aGljaCBjYXNlIHRoZXJl4oCZcyBubyBleHRyYSB3b3JrKS4NCg0KRnJvbTog UVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0K U2VudDogVHVlc2RheSwgTWF5IDE0LCAyMDE5IDU6MjEgUE0NClRvOiBEYXZpZCBTY2hpbmF6aSA8 ZHNjaGluYXppLmlldGZAZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjsgTWFydGluIER1a2Ug PG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IEJpZyBUUCBjb2Rlc3BhY2UN Cg0KV2hhdCdzIHRoZSBiaWdnZXIgcHJpbmNpcGxlIHlvdSBhcmUgZW5kb3JzaW5nPyBXaGF0IGVy cm9ycyAibGlrZSB0aGlzIiBhcmUgd2Ugbm90IHJlcXVpcmluZyBkZXRlY3Rpb24gb2Y/DQoNCk9u IE1vbiwgTWF5IDEzLCAyMDE5IGF0IDU6MTkgUE0gRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpP dXIgaW1wbGVtZW50YXRpb24gY2hlY2tzIGZvciBkdXBsaWNhdGVzIG9ubHkgZm9yIHRoZSB0cmFu c3BvcnQgcGFyYW1ldGVycyBpdCBzdXBwb3J0cy4gSSB0aGluayAjMjY5MTxodHRwczovL2dpdGh1 Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjY5MS9maWxlcz4gaXMgdGhlIGNvcnJlY3Qg c29sdXRpb24uDQoNCisxIHRvIHRoZSBkZXNpZ24gcHJpbmNpcGxlIG9mIGVuY291cmFnaW5nIGJ1 dCBub3QgcmVxdWlyaW5nIGRldGVjdGlvbiBvZiBlcnJvcnMgbGlrZSB0aGlzDQoNCkRhdmlkDQoN Ck9uIE1vbiwgTWF5IDEzLCAyMDE5IGF0IDI6MDYgUE0gQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRl bWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS4ubmV0Pj4gd3JvdGU6DQoNCg0K PiBPbiBNYXkgMTMsIDIwMTksIGF0IDE6NTggUE0sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtl QGdtYWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4g V2hhdCBkbyBwZW9wbGUgdGhpbms/DQoNCkkgdGhpbmsgdGhlIGdlbmVyYWwgcnVsZSBvZiBwcm90 b2NvbCBwb2xpY2luZyBzaG91bGQgYmUgIk1VU1QgTk9UIiBkbyBkYXN0YXJkbHkgc3R1ZmYsIGFu ZCAiTUFZIiBkcm9wIHRoZSBjb25uZWN0aW9uIHdoZW4gdGhhdCBoYXBwZW5zLg0KDQotLSBDaHJp c3RpYW4gSHVpdGVtYQ0K --_000_CY4PR22MB0983FBE5C72EF1D46DAC27ECDA090CY4PR22MB0983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBhZ3JlZWQgaW4gVG9reW8gdGhhdCB3ZSB3b3VsZCBub3QgbWFuZGF0ZSB0 aGF0IGltcGxlbWVudGF0aW9ucyBjaGVjayBmb3IgaW1wcm9wZXIgcGVlciBiZWhhdmlvciB3aGVu IGRvaW5nIHNvIHJlcXVpcmVkIHN1YnN0YW50aWFsIGV4dHJhIHdvcmsuJm5ic3A7IEltcGxlbWVu dGF0aW9ucyBNVVNUIGVycm9yIG91dCBvbiBlYXNpbHktZGV0ZWN0ZWQgZXJyb3JzLCBidXQgb25s eSBTSE9VTEQvTUFZIGVycm9yIG9uIHRoaW5ncw0KIHRoZXkgd291bGQgaGF2ZSB0byBhY3RpdmVs eSBjaGVjayAodW5sZXNzIHRoZXnigJlyZSBhbHJlYWR5IHJlcXVpcmVkIHRvIGFjdGl2ZWx5IGNo ZWNrIGZvciBzZWN1cml0eSByZWFzb25zLCBpbiB3aGljaCBjYXNlIHRoZXJl4oCZcyBubw0KPGk+ ZXh0cmE8L2k+IHdvcmspLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJ QyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRXJp YyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTQsIDIwMTkgNToyMSBQ TTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdtYWls LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs7IENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgTWFydGlu IER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogQmlnIFRQIGNvZGVzcGFjZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hh dCdzIHRoZSBiaWdnZXIgcHJpbmNpcGxlIHlvdSBhcmUgZW5kb3JzaW5nPyBXaGF0IGVycm9ycyAm cXVvdDtsaWtlIHRoaXMmcXVvdDsgYXJlIHdlIG5vdCByZXF1aXJpbmcgZGV0ZWN0aW9uIG9mPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkg MTMsIDIwMTkgYXQgNToxOSBQTSBEYXZpZCBTY2hpbmF6aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRz Y2hpbmF6aS5pZXRmQGdtYWlsLmNvbSI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk91ciBp bXBsZW1lbnRhdGlvbiBjaGVja3MgZm9yIGR1cGxpY2F0ZXMgb25seSBmb3IgdGhlIHRyYW5zcG9y dCBwYXJhbWV0ZXJzIGl0IHN1cHBvcnRzLiBJIHRoaW5rDQo8YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMjY5MS9maWxlcyIgdGFyZ2V0PSJfYmxhbmsi PiMyNjkxPC9hPiBpcyB0aGUgY29ycmVjdCBzb2x1dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byB0aGUgZGVzaWduIHByaW5jaXBsZSBv ZiBlbmNvdXJhZ2luZyBidXQgbm90IHJlcXVpcmluZyBkZXRlY3Rpb24gb2YgZXJyb3JzIGxpa2Ug dGhpczxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBNb24sIE1heSAxMywgMjAxOSBhdCAyOjA2IFBNIENocmlzdGlhbiBIdWl0ZW1hICZs dDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLi5uZXQiIHRhcmdldD0iX2JsYW5rIj5o dWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PGJyPg0KPGJyPg0KJmd0OyBPbiBNYXkgMTMsIDIwMTksIGF0 IDE6NTggUE0sIE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLmguZHVrZUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGF0IGRvIHBlb3BsZSB0aGluaz88YnI+DQo8 YnI+DQpJIHRoaW5rIHRoZSBnZW5lcmFsIHJ1bGUgb2YgcHJvdG9jb2wgcG9saWNpbmcgc2hvdWxk IGJlICZxdW90O01VU1QgTk9UJnF1b3Q7IGRvIGRhc3RhcmRseSBzdHVmZiwgYW5kICZxdW90O01B WSZxdW90OyBkcm9wIHRoZSBjb25uZWN0aW9uIHdoZW4gdGhhdCBoYXBwZW5zLjxicj4NCjxicj4N Ci0tIENocmlzdGlhbiBIdWl0ZW1hIDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR22MB0983FBE5C72EF1D46DAC27ECDA090CY4PR22MB0983namp_-- From nobody Wed May 15 10:44: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 7D58C1203D5 for ; Wed, 15 May 2019 10:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doDBktlqMdot for ; Wed, 15 May 2019 10:44:28 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F93D1203D9 for ; Wed, 15 May 2019 10:44:28 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id z5so530357lji.10 for ; Wed, 15 May 2019 10:44: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=eUjNPja5SaXyc/xuU3iCBszgnbvh5/jgZTCHSDFHaK0=; b=WX1rw9N/sXWDDOjhV2oCFM7LUN+63iF5/FBGtfOWkgPubmrjW42aCa9G9NpouLIQqF lZmE57tNGJ9coZIjs50LscRNbANurcx/iA54Srxls1uh7/pwgjtXx0rV+0L3vo1jBvWC sDeK+n9JxB65ibR21Fj/mmqdzMjOImIKn9Csoc35FkxmCpxIB5MmfXiym0+ulH1Vo9H1 Re/Bli7YNXqEL31EvFZZ1VDNJc5z6GasmkextQ0+KFcZ4KmBqUE2TLmCZNdXBLYwvAMz Sje80O1CGbknhHy1w72aXY0XwF6POhkWOKfNjigjTxRI0zEfjMgm8msEJRD6w22I+CB0 7Z+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eUjNPja5SaXyc/xuU3iCBszgnbvh5/jgZTCHSDFHaK0=; b=oaQMkzLlzibt6R8DASA8neOmNLc9WL/ta9AmEjY/5kgWxCRR6z5XT8kL3qiQN2Ea8y n+KX+k7poXbVQAtn9BlktG1ewdRniXXtrXnK4O8DfjkaKrfqA/Q/ZEIgD3R4ExbwWEuh moCDKjhTk1FgduZJ2pbU9wYCNgoEy1MYjjCe7ic0J6oys48bYp5QJB7/zRhpPCYT2sc/ ITagiCg7+2qRvNr5G7nZahdkuIFGXSADf/oRy1mmpOCcgEuko4dXMhFYBoAf6CJtCAvF 5Vow40EKjerrsi2ynTt0m0bEUA/Kd/1BC/SITDuk4kV0C1Z59jCLhPXxHQUU47W5bebq sCcg== X-Gm-Message-State: APjAAAXFCEAEOf/HO+2v+mMEh9+Yr6SiOzQ7cqtaG6sxr/LuOmrhw1vd /2ZZAUSVeTtAc/XOwilH+kitAyY6STbIdUdytok= X-Google-Smtp-Source: APXvYqxmY5OLxQUZRQAXxo/2+kA7NOnwKGxlNLDq0wb8y9NYfSr1AeXgqlJZaImMrnKhgzcPNoGsx9ywb+3hzpzevoo= X-Received: by 2002:a2e:8644:: with SMTP id i4mr8011578ljj.0.1557942266314; Wed, 15 May 2019 10:44:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 15 May 2019 10:44:15 -0700 Message-ID: Subject: Re: Big TP codespace To: Mike Bishop Cc: Eric Rescorla , IETF QUIC WG , Christian Huitema , Martin Duke Content-Type: multipart/alternative; boundary="0000000000005d44f00588f0b390" 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, 15 May 2019 17:44:31 -0000 --0000000000005d44f00588f0b390 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @ekr, the principle I was endorsing is the one Mike mentioned. On Wed, May 15, 2019 at 10:20 AM Mike Bishop wrote: > We agreed in Tokyo that we would not mandate that implementations check > for improper peer behavior when doing so required substantial extra work. > Implementations MUST error out on easily-detected errors, but only > SHOULD/MAY error on things they would have to actively check (unless > they=E2=80=99re already required to actively check for security reasons, = in which > case there=E2=80=99s no *extra* work). > > > > *From:* QUIC *On Behalf Of * Eric Rescorla > *Sent:* Tuesday, May 14, 2019 5:21 PM > *To:* David Schinazi > *Cc:* IETF QUIC WG ; Christian Huitema ; > Martin Duke > *Subject:* Re: Big TP codespace > > > > What's the bigger principle you are endorsing? What errors "like this" ar= e > we not requiring detection of? > > > > On Mon, May 13, 2019 at 5:19 PM David Schinazi > wrote: > > Our implementation checks for duplicates only for the transport parameter= s > it supports. I think #2691 > is the correct > solution. > > > > +1 to the design principle of encouraging but not requiring detection of > errors like this > > > > David > > > > On Mon, May 13, 2019 at 2:06 PM Christian Huitema > wrote: > > > > > On May 13, 2019, at 1:58 PM, Martin Duke > wrote: > > > > What do people think? > > I think the general rule of protocol policing should be "MUST NOT" do > dastardly stuff, and "MAY" drop the connection when that happens. > > -- Christian Huitema > > --0000000000005d44f00588f0b390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@ekr, the principle I was endorsing is the one Mike mentio= ned.

On Wed, May 15, 2019 at 10:20 AM Mike Bishop <mbishop@evequefou.be> wrote:

We agreed in Tokyo that we would not mandate that im= plementations check for improper peer behavior when doing so required subst= antial extra work.=C2=A0 Implementations MUST error out on easily-detected = errors, but only SHOULD/MAY error on things they would have to actively check (unless they=E2=80=99re already required= to actively check for security reasons, in which case there=E2=80=99s no extra work).

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Eric Rescorla
Sent: Tuesday, May 14, 2019 5:21 PM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Christian Huitema <huitema@huitema.net>; Martin Duke <= ;martin.h.duke= @gmail.com>
Subject: Re: Big TP codespace

=C2=A0

What's the bigger principle you are endorsing? W= hat errors "like this" are we not requiring detection of?<= u>

=C2=A0

On Mon, May 13, 2019 at 5:19 PM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com" target=3D"_blank">dschinazi.ietf= @gmail.com> wrote:

Our implementation checks for duplicates only for th= e transport parameters it supports. I think #2691 is the correct solution.

=C2=A0

+1 to the design principle of encouraging but not re= quiring detection of errors like this

=C2=A0

David

=C2=A0

On Mon, May 13, 2019 at 2:06 PM Christian Huitema &l= t;huitema@huitema= .net> wrote:

=C2=A0

> On May 13, 2019, at 1:58 PM, Martin Duke <martin.h.duke@gmail.com> wrote:<= br> >
> What do people think?

I think the general rule of protocol policing should be "MUST NOT"= ; do dastardly stuff, and "MAY" drop the connection when that hap= pens.

-- Christian Huitema

--0000000000005d44f00588f0b390-- From nobody Wed May 15 13:55: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 620611201FA for ; Wed, 15 May 2019 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 D5AdYdAPXkaC for ; Wed, 15 May 2019 13:55:02 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 EFA1D12028B for ; Wed, 15 May 2019 13:55:01 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id a64so926788qkg.5 for ; Wed, 15 May 2019 13:55:01 -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:mime-version :content-disposition:user-agent; bh=P+DwXnWmsRlzOOJAShRUccD7HPmEpIVPn2gTKokW33g=; b=H3hLGP4nj0usxuH4uAJJnzQ586fd5lEjutpkFTNu5Px43Le2kwhOPXOzisC/4g3UmM mf+N6u5p9dQ4LgynqtTqIdlAe/5BAu7tbxBBgHVtu9QmPnFLg9IaJvLCERjYC2VJGhyx vz4ke3bYxtJv/wYXO1qRGZZTFLnxAGhFjUBiBa//2cYbbCdJWGxfpndx1svwjLRbWoJ6 kOtoUjXmI0ZXS5p5G/Gg7qESKv8o8sFhA7UsfGH2K9aFGfiFFCEwxEDrwOEnjvwSKobl t0YPJ7GY+mxyM4O+M1Fo/Db5/k9kNHZsIYleYoBKVEkL6bBnvjNHKkIVvDRZNxkMHhr7 HfVw== 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:mime-version:content-disposition:user-agent; bh=P+DwXnWmsRlzOOJAShRUccD7HPmEpIVPn2gTKokW33g=; b=Sfm2XJo4iwzHeP0YSLE7j22KSyjPGnzQ1SFd1qTefHHqFVjEVgCD8+jmKrSoYgDKfO fhu7nsXmdmaFoTsl3sLtcFv4Eeb3YtkSQJ6M94JHJuEKnwZqs/hlMa2tfPEcpapIHkYp iRbE9AcwD2uVP5X/ctUcdTcfrxY+ojB1pukT+riN85NMI22RTh9pHuTOP3wZa6CauwTL yzWOlAgaQ145bAuvkxvBlH6qLXRd6vTJi6Ec3c3+86ksO8QQbUJ3jjcy+8TawDpml4mA e9Wb2iKR8t6FaOqMkg2Lq9H48RD8RvnNJ9wOey2Sy0V0Xj+HiKxJCl/l/pl404VmZmxq ejjA== X-Gm-Message-State: APjAAAWmquD/MW2XffYmypaiW4hQFOkf9wgt6dC4X6aQ3bn1rI2lu4BF qDoj4lZpBsmrqLrkGVnkiKBDMA== X-Google-Smtp-Source: APXvYqz/BHf2GzQXuFVjhPPEihn2YKjupaCw2fbvFBQt9byq9MqsXM7KKGbiZwM2kTx8rnZoR7glfg== X-Received: by 2002:ae9:f218:: with SMTP id m24mr26376076qkg.261.1557953701140; Wed, 15 May 2019 13:55:01 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id 22sm1665267qkl.4.2019.05.15.13.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 May 2019 13:55:00 -0700 (PDT) Date: Wed, 15 May 2019 16:54:52 -0400 From: Dmitri Tikhonov To: Ian Swett Cc: IETF QUIC WG Subject: HTTP/3 with strict priorities (PR #2700) Message-ID: <20190515205451.GA32701@ubuntu-dmitri> Mail-Followup-To: Ian Swett , IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 15 May 2019 20:55:10 -0000 Hello Ian, You opened a PR that proposes YAHPM (Yet Another HTTP Prioritization Mechanism) -- HTTP/3 with Strict Priorities. Having read through the diff, I have several questions. I am using this medium because your PR does not have an associated bug. 1. What is a _strict priority_? There is no definition of strict priority that I could find in the diff. Do strict priorities work outside of the dependency tree? For example, which stream has higher priority in the following figure? (Root Node) / \ / \ (Placeholder A, (Placeholder B, Weight 50) Weight 100) | | V V (Stream P, (Stream Q, Priority 100) Priority 50) 2. Why require PRIORITY frames delivered on own streams? " In order to ensure that prioritization is processed in a " consistent order, any subsequent PRIORITY frames for that " request MUST be sent on the request stream. This requirement is unfortunate, as Lucas Pardue has already observed (see PR comments). Is this done to avoid introducing false stream dependencies or is there another reason for this requirement? 3. What problem do all-or-nothing resources solve? " When [weight is] absent, indicates the resource should be " delivered all at once or not at all. This is new. I don't believe I've seen it in other prioritization proposals. Adding this dimension increases complexity. What problem do these all-or-nothing resources solve? Thank you, - Dmitri. From nobody Wed May 15 14:51: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 CE5841200D8 for ; Wed, 15 May 2019 14:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dixPmJoOKXpo for ; Wed, 15 May 2019 14:51:42 -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 B90B81200A2 for ; Wed, 15 May 2019 14:51:41 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id f8so1124777wrt.1 for ; Wed, 15 May 2019 14:51: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; bh=Wqrhl88qWV10Zq9Ye/F5cUcOCQwNgaKYCQT2vOnCb0Q=; b=NPj3iLSA2kSe7CrLcCmBq2NqqYTTxzxVpT/J/mle+3FDkyU8Jx30K55Av/9GNGhW0d Ot9ZKfbO1MLK1iWj0qAY6Mcj6QYqrsBHlFSNzPsMCV1HKgWUGL29twyhEOjMgCFU6Rzi mKegc3i1uUEfaZw9UytHElc1S73w96p6ysoQlD4Ji+9LMDVCwd6tdl0rV5KNyz6R0w+c NMRztExny3XcfBkreg9HCbtLKiwUyKMH258yNuAq8V631f227EMDiulphtnUWBMxyLgX oGSPcgLyVGWbXYVezltLGirxMEiCp5mfoqaVvnrpL7q363Zq2MTvrZXz55zBQ3OmJwQu f1DQ== 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=Wqrhl88qWV10Zq9Ye/F5cUcOCQwNgaKYCQT2vOnCb0Q=; b=o/ZcqeT5VRKUB0g73CfcBVHvc/i59KKTB4hgM3e3hDUAAy7XY0DgVvV+6J+uLaNdQw 49iaDn9/hZyysL936PdmPs1s2a8EO+6jYaPtwKiOQfx6FXrd0ZcUTSUvqMP/mnGShNsV hyUAQxKbGEI9Ve/F0UZTqusuQEVCbSlQJIIEGimYt4NjEdXPBZttbJoG9ajlPcwqwl7t lalwNHK+XqH0D5/5vvCTvoAzc6rXDkVrkpNfW7BcUTmX6UgUa7+xVMEih/1ZAg4sKgOS rcMK2MOkh9Uv7+zZFnsLw0w9HGq35xlw8q+0b8u4ymZlePJX+/NI6H4iGeHKIWELNhw/ Kwxg== X-Gm-Message-State: APjAAAV97xyLK6OzCkWWwuMyK+yEG5wVcWR6wc9ytijq80hyzmH7H3VZ I2U5+vbhKuOe3qPIUUusvoyR/PJ0qPyOb/TsQOzBaQ== X-Google-Smtp-Source: APXvYqyVse6yfrcXfpTNtwGcEkFdygf8QaCgPU5HmjbeJ/ZTBbmVWryIazP8R4rkeR+n3euSKYXw7MAxAYdLB0gdb8I= X-Received: by 2002:adf:eb87:: with SMTP id t7mr26016169wrn.39.1557957099877; Wed, 15 May 2019 14:51:39 -0700 (PDT) MIME-Version: 1.0 References: <20190515205451.GA32701@ubuntu-dmitri> In-Reply-To: <20190515205451.GA32701@ubuntu-dmitri> From: Ian Swett Date: Wed, 15 May 2019 17:51:27 -0400 Message-ID: Subject: Re: HTTP/3 with strict priorities (PR #2700) To: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000083de250588f427f3" 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, 15 May 2019 21:51:45 -0000 --00000000000083de250588f427f3 Content-Type: text/plain; charset="UTF-8" Thanks for taking a look Dmitri. I just added Issue #2502 to the PR. It was inadvertently sent out slightly before it was done, so there are some details I'm still trying to fix. On Wed, May 15, 2019 at 4:55 PM Dmitri Tikhonov wrote: > Hello Ian, > > You opened a PR that proposes YAHPM (Yet Another HTTP Prioritization > Mechanism) -- HTTP/3 with Strict Priorities. Having read through the > diff, I have several questions. I am using this medium because your > PR does not have an associated bug. > > 1. What is a _strict priority_? > > There is no definition of strict priority that I could find > in the diff. Do strict priorities work outside of the > dependency tree? For example, which stream has higher priority > in the following figure? > > (Root Node) > / \ > / \ > (Placeholder A, (Placeholder B, > Weight 50) Weight 100) > | | > V V > (Stream P, (Stream Q, > Priority 100) Priority 50) > Strict priorities are only relative to other siblings under the same placeholder/root. I'll clarify that. Currently the text says "Higher priority elements have all available data sent before elements of lower priority." > 2. Why require PRIORITY frames delivered on own streams? > > " In order to ensure that prioritization is processed in a > " consistent order, any subsequent PRIORITY frames for that > " request MUST be sent on the request stream. > > This requirement is unfortunate, as Lucas Pardue has already > observed (see PR comments). Is this done to avoid introducing > false stream dependencies or is there another reason for this > requirement? > I made the change because it was a simplification that was possible, but I think it's a poor choice on my part so I'm going to go back to allowing PRIORITY on either the request stream or control stream, I just haven't had a chance to update the PR yet. > > 3. What problem do all-or-nothing resources solve? > > " When [weight is] absent, indicates the resource should be > " delivered all at once or not at all. > > This is new. I don't believe I've seen it in other prioritization > proposals. Adding this dimension increases complexity. What > problem do these all-or-nothing resources solve? > This is an effort to incorporate Patrick Meenan's Round Robin Sequential and Round Robin Interleaved proposal, as outlined on slide 49 here: https://github.com/HTTPWorkshop/workshop2019/blob/master/talks/pardue-jones-priorities.pdf or here: http3-prioritization-proposal I'm sure Patrick could rewrite this text more clearly, and I think Patrick's explanation for the motivation is solid. > > Thank you, > > - Dmitri. > > --00000000000083de250588f427f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for taking a= look Dmitri.=C2=A0 I just added Issue #2502=C2=A0to the PR.=C2=A0 It was inadverten= tly sent out slightly before it was done, so there are some details I'm= still trying to fix.

On Wed, May 15, 2019 at 4:55 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
Hel= lo Ian,

You opened a PR that proposes YAHPM (Yet Another HTTP Prioritization
Mechanism) -- HTTP/3 with Strict Priorities.=C2=A0 Having read through the<= br> diff, I have several questions.=C2=A0 I am using this medium because your PR does not have an associated bug.

1. What is a _strict priority_?

=C2=A0 =C2=A0 There is no definition of strict priority that I could find =C2=A0 =C2=A0 in the diff.=C2=A0 Do strict priorities work outside of the =C2=A0 =C2=A0 dependency tree?=C2=A0 For example, which stream has higher p= riority
=C2=A0 =C2=A0 in the following figure?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Root Node)
=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=A0 /=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 (Placeholder A,=C2=A0 =C2=A0 =C2=A0(Placeholder B,
=C2=A0 =C2=A0 =C2=A0Weight 50)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Weight 100)
=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 V=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0 (Stream P,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Stream Q,
=C2=A0 =C2=A0 =C2=A0Priority 100)=C2=A0 =C2=A0 =C2=A0 =C2=A0Priority 50)

Strict priorities are only relative to ot= her siblings under the same placeholder/root.=C2=A0 I'll clarify that.= =C2=A0 Currently the text says "Higher priority elements have all avai= lable data sent before elements of lower priority."


2. Why require PRIORITY frames delivered on own streams?

=C2=A0 =C2=A0 " In order to ensure that prioritization is processed in= a
=C2=A0 =C2=A0 " consistent order, any subsequent PRIORITY frames for t= hat
=C2=A0 =C2=A0 " request MUST be sent on the request stream.

=C2=A0 =C2=A0 This requirement is unfortunate, as Lucas Pardue has already<= br> =C2=A0 =C2=A0 observed (see PR comments).=C2=A0 Is this done to avoid intro= ducing
=C2=A0 =C2=A0 false stream dependencies or is there another reason for this=
=C2=A0 =C2=A0 requirement?

I made the c= hange because it was a simplification that was possible, but I think it'= ;s a poor choice on my part so I'm going to go back to allowing PRIORIT= Y on either the request stream or control stream, I just haven't had a = chance to update the PR yet.

3. What problem do all-or-nothing resources solve?

=C2=A0 =C2=A0 " When [weight is] absent, indicates the resource should= be
=C2=A0 =C2=A0 " delivered all at once or not at all.

=C2=A0 =C2=A0 This is new.=C2=A0 I don't believe I've seen it in ot= her prioritization
=C2=A0 =C2=A0 proposals.=C2=A0 Adding this dimension increases complexity.= =C2=A0 What
=C2=A0 =C2=A0 problem do these all-or-nothing resources solve?

This is an effort to incorporate Patrick Meenan'= ;s Round Robin Sequential and Round Robin Interleaved proposal, as outlined= on slide 49 here:=C2=A0https://github.com/HTTP= Workshop/workshop2019/blob/master/talks/pardue-jones-priorities.pdf=C2= =A0or here:=C2=A0http3-prioritization-proposal

I'm sure Patrick could rewrite this text more clearly,= and I think Patrick's explanation for the motivation is solid.

Thank you,

=C2=A0 - Dmitri.

--00000000000083de250588f427f3-- From nobody Wed May 15 18:47: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 9DD13120192 for ; Wed, 15 May 2019 18:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3N54qFGYFIN for ; Wed, 15 May 2019 18:47:25 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 6E67A120183 for ; Wed, 15 May 2019 18:47:24 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id f1so1282356lfl.6 for ; Wed, 15 May 2019 18:47:24 -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=1W3hWG/xXhtOglZ4c11ah5er0d0CZkT48XxkbQ8XSZE=; b=e770l3INuRkjz8urNCtAgKGCngrZnbmHjThOyINBhz6GzY9vWxKvxFbzbllmXRNRlN zsgzM+RMy0+ikfWWhlQPb8PRifeuTMPCFqrhkGSCIFwv7+NAln7/gSNddtODuoVrl9bK FaYJ+wuedOrs9tfwx5lxWxk3VhC+Jq+apkB1A2nIZWJL8KhrMvcODEv9t3oZkwQXfOcQ 8ycVWIk4fEjW4+nQYbGgR5x321VvP71Ns/2HOXL6iZLWDfgr2DqJMuChX5t5iWYLNrjQ GfDcgFkgNp1EEbVwTNWickgBzfcwMJPs+nc1dz7F88Pzgmgi6xQVsSGHrte1jTOs0GwM W45w== 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=1W3hWG/xXhtOglZ4c11ah5er0d0CZkT48XxkbQ8XSZE=; b=mnM1OGnfECmwD9jUxDdxA5fDLK72ke4MNKtDprRAzOoMcnbju5oua8E0zyy9/9rojw Y6ZTdzHgqpw0dXMwx2fhtT864a+qOCbvt871jevrYOiHLvG+duqVhCCIPAZrntNGffi+ eW9ImfF18StetHnixo/Doy0ugeKHY+nX+TKGOG9TDQrViHrafFZd0AL6wJAyGeOBhcle a01ylYCp+L20kmnANRJeGPvx0TpoWGZBfp2ApbMgOJRrlXsqSjNgfkbTL7tIqjHXBpgK or/ljXWkQZKwadU6W4qZpaOiCZm0W8/0SA40ot2gc4/o9RttrjbA3PkLEMsp0ICGhuiI 1Uyg== X-Gm-Message-State: APjAAAW1RnvTZl/nmKkalRWEV59JRoIHpCY5so7byr1/bKB+6e95QwYA oVtlIETiSyGcug1SYYkMbDbvgUk35Am8GwwO9Rc= X-Google-Smtp-Source: APXvYqzzOaNj1gZVG9TpQoFjEWstZ6oWJYCzS5f/8f4cZZTkkyqadBx5DGY/+JGlpl0NwyZakDOE6MlAgXVkjbrgqjs= X-Received: by 2002:ac2:5621:: with SMTP id b1mr23283019lff.27.1557971241577; Wed, 15 May 2019 18:47:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Wed, 15 May 2019 18:47:10 -0700 Message-ID: Subject: Re: Big TP codespace To: David Schinazi Cc: Mike Bishop , Eric Rescorla , IETF QUIC WG , Christian Huitema , Martin Duke Content-Type: multipart/alternative; boundary="0000000000006caf240588f7720b" 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, 16 May 2019 01:47:28 -0000 --0000000000006caf240588f7720b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Martin, the text in #2691 supports what you want to accomplish, but doesn't require everyone to do the same thing. I think that's all we need. On Wed, May 15, 2019 at 10:44 AM David Schinazi wrote: > @ekr, the principle I was endorsing is the one Mike mentioned. > > On Wed, May 15, 2019 at 10:20 AM Mike Bishop wrote= : > >> We agreed in Tokyo that we would not mandate that implementations check >> for improper peer behavior when doing so required substantial extra work= . >> Implementations MUST error out on easily-detected errors, but only >> SHOULD/MAY error on things they would have to actively check (unless >> they=E2=80=99re already required to actively check for security reasons,= in which >> case there=E2=80=99s no *extra* work). >> >> >> >> *From:* QUIC *On Behalf Of * Eric Rescorla >> *Sent:* Tuesday, May 14, 2019 5:21 PM >> *To:* David Schinazi >> *Cc:* IETF QUIC WG ; Christian Huitema < >> huitema@huitema.net>; Martin Duke >> *Subject:* Re: Big TP codespace >> >> >> >> What's the bigger principle you are endorsing? What errors "like this" >> are we not requiring detection of? >> >> >> >> On Mon, May 13, 2019 at 5:19 PM David Schinazi >> wrote: >> >> Our implementation checks for duplicates only for the transport >> parameters it supports. I think #2691 >> is the correct >> solution. >> >> >> >> +1 to the design principle of encouraging but not requiring detection of >> errors like this >> >> >> >> David >> >> >> >> On Mon, May 13, 2019 at 2:06 PM Christian Huitema >> wrote: >> >> >> >> > On May 13, 2019, at 1:58 PM, Martin Duke >> wrote: >> > >> > What do people think? >> >> I think the general rule of protocol policing should be "MUST NOT" do >> dastardly stuff, and "MAY" drop the connection when that happens. >> >> -- Christian Huitema >> >> --0000000000006caf240588f7720b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin, the text in #2691 supports what you want to accomp= lish, but doesn't require everyone to do the same thing. I think that&#= 39;s all we need.

On Wed, May 15, 2019 at 10:44 AM David Schinazi <dschinazi.ietf@gmail.com> wrot= e:
@ekr, the principle I was endorsing is the one Mike mentioned.
On Wed, M= ay 15, 2019 at 10:20 AM Mike Bishop <mbishop@evequefou.be> wrote:

We agreed in Tokyo that we would not mandate that im= plementations check for improper peer behavior when doing so required subst= antial extra work.=C2=A0 Implementations MUST error out on easily-detected = errors, but only SHOULD/MAY error on things they would have to actively check (unless they=E2=80=99re already required= to actively check for security reasons, in which case there=E2=80=99s no extra work).

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Eric Rescorla
Sent: Tuesday, May 14, 2019 5:21 PM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Christian Huitema <huitema@huitema.net>; Martin Duke <= ;martin.h.duke= @gmail.com>
Subject: Re: Big TP codespace

=C2=A0

What's the bigger principle you are endorsing? W= hat errors "like this" are we not requiring detection of?<= u>

=C2=A0

On Mon, May 13, 2019 at 5:19 PM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com" target=3D"_blank">dschinazi.ietf= @gmail.com> wrote:

Our implementation checks for duplicates only for th= e transport parameters it supports. I think #2691 is the correct solution.

=C2=A0

+1 to the design principle of encouraging but not re= quiring detection of errors like this

=C2=A0

David

=C2=A0

On Mon, May 13, 2019 at 2:06 PM Christian Huitema &l= t;huitema@huitema= ..net> wrote:

=C2=A0

> On May 13, 2019, at 1:58 PM, Martin Duke <martin.h.duke@gmail.com> wrote:<= br> >
> What do people think?

I think the general rule of protocol policing should be "MUST NOT"= ; do dastardly stuff, and "MAY" drop the connection when that hap= pens.

-- Christian Huitema

--0000000000006caf240588f7720b-- From nobody Wed May 15 19:11: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 2244C1202E5 for ; Wed, 15 May 2019 19:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqwQsgZ2kceT for ; Wed, 15 May 2019 19:11:19 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 644C81202E9 for ; Wed, 15 May 2019 19:11:17 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id d128so1249873vsc.10 for ; Wed, 15 May 2019 19:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dunh+QcOcLIi6JzRpGkojhECFmzUKYgWpZSDGVNhOu4=; b=GGMa2KRSWF5A+U44xlaLG6mT5ZZ7Gd9VgGBOknUeQunNWob+wk8MS0IL+q7AdNsHbv IC8F56DvfRM2DptGhLwRQzka2KqjyGF68MGPbze2D91qaxAPKOHhrpOv5Jdltc9yzo0s dOGO4Ew5UxOM52rED+L1uxdGSrKJg1ibv9fdiltgH8/6q+4yD/fEToRoNkEknoVNxC1L aIAF7nNv99+qPVzf8sA78IAbA+j/Njxmu8yWgdz1ydfDqGdyDwgZ1EnxkxpQQSlBjnrA rBuQSQvqUdzYoKOlVwHYNNIHSKY9XSkyb7ND41w597QvDweQVz5WwGhC6SidfchggPPW br5Q== 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=dunh+QcOcLIi6JzRpGkojhECFmzUKYgWpZSDGVNhOu4=; b=tzNcc1tEy1/OyNrXGOveWdVYGrSgScjARTMuNVXEamo73PZrPKF+/WsMRzlHpLM/H2 KF1if4j/+bbRD+qOOSPnFtGPAWO+yW15e0aeZ+1xQY5/ivga4o1JSfNxgUoyrXWCjj97 cjHIuvlj+WTYCFxQMKoQOKKSbxcrHzNqmZZ9RPGhJVHIwdYHQgvJ0qZuw1LqZeSEk7A+ dJJU6SL6EMiccHq0Go55/NrbPuQF8Cc+t2SdkRQs0BA9xp25gnELbxG0gmF+SIJ8r6X2 E9883DjkE7mnWG9dbVCIcGscivaNnJAmt5aYx+c0zNrIFY61uIwSEQx3qeJLgi0qqjO4 Wtkw== X-Gm-Message-State: APjAAAW5cyHy8qM12yrECcNUWlCRcpeEJaY8W2vcZFL/YDcED0k/n/sv zMdxfJd5Mztb3U8aW5PhBQ1ynpW3sv64mMGxtsmDJTab X-Google-Smtp-Source: APXvYqyUEbS4pSlrp2eGNQi1RsnJUZ/FfQWQDgaKyB+7Rs3yJbQ68Hm5wl5RC7qq507G8YRTNI5JNyRiPO13i+WdW/8= X-Received: by 2002:a67:e286:: with SMTP id g6mr16325301vsf.113.1557972676028; Wed, 15 May 2019 19:11:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Wed, 15 May 2019 19:11:06 -0700 Message-ID: Subject: Re: QUIC API trial in Chrome To: QUIC WG Content-Type: multipart/alternative; boundary="000000000000ecaf0c0588f7c7ca" 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, 16 May 2019 02:11:28 -0000 --000000000000ecaf0c0588f7c7ca Content-Type: text/plain; charset="UTF-8" The QUIC P2P API has now been extended to support QUIC DATAGRAMs, and will soon be available in an origin trial in Chrome and Edgium: https://lists.w3.org/Archives/Public/public-ortc/2019May/0000.html So if you're interested to explore writing QUIC applications with reliable streams as well as datagrams, now is your chance! On Wed, Feb 20, 2019 at 9:44 AM Bernard Aboba wrote: > For those of you who are interested in experimenting with QUIC P2P > application development in Javascript, there is now an opportunity to do so: > http://lists.w3.org/Archives/Public/public-ortc/2019Feb/0000.html > --000000000000ecaf0c0588f7c7ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The QUIC P2P API has now been extended to support QUIC DAT= AGRAMs, and will soon be available in an origin trial in Chrome and Edgium:=

So if you're interested to explore = writing QUIC applications with reliable streams as well as datagrams, now i= s your chance!

On Wed, Feb 20, 2019 at 9:44 AM Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com">bernard.aboba@gmail.com> w= rote:
For those of you who are interested in experiment= ing with QUIC P2P application development in Javascript, there is now an op= portunity to do so:
--000000000000ecaf0c0588f7c7ca-- From nobody Thu May 16 12:01: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 1134A120243 for ; Thu, 16 May 2019 12:01: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_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 ZV9AdOmRgzZi for ; Thu, 16 May 2019 12:01:46 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 008CC120242 for ; Thu, 16 May 2019 12:01:45 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id c77so3210685wmd.1 for ; Thu, 16 May 2019 12:01:45 -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=Tyjmn+LD2TBJm5uOv++3yOGYk8vRK2o/38Z3X7UyJ3c=; b=rm5aUNrfK7P/1tNsNgH3D/wKJJ+rmSSqWQ0rfdxXaFre6/61Wk9eNmYaet0zvcn23h 3zwZaQzL39yhWqJGHxLQk/Ixl+InwEsL/29YbV9u4X9I+OcJaINBcXXUrSw0KHtqFg7L 0Y9aUW8J6Bj3tTX7ZrhngpVmJbKICc2k27bRwyLPdqc84hCu2lxsLGYWEs1L0hTjsiyV fOcw+6lzP0EGpR+6wl07TY07OyNwwwel/++mpUatEfLUgy1MhpFTBu1oYas6lDFelRND Ifbuq/nFXQk8vhELGCLbuwzCk/93QpDAN0qpOOFaQvyFLKdPtjr50OmH15ODnjaPKPMB c9mg== 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=Tyjmn+LD2TBJm5uOv++3yOGYk8vRK2o/38Z3X7UyJ3c=; b=FSl4tVEtob8Dps939mx+02FIWJYJhumcdTIdzosfHHJtfml8v6VvC9Z00kjNeMzos6 G8SH3O1szHwFGa9h47vL9cRiffHs/pGy3Z3TrRqCKiiU0pGwstq+2AF6dqEmTOAqnD0R tppOk/PrAtFQodKAZdVdPoMM8IjTdfj0bOXRkClTJVzrTRv4WwU4PZlbJMtWQaZ19DSC 7kxPexUi1TauzsdCA+IkeWqx7vQcnLA27omH4iBS+gfb3hcOpWFQ9wEqFXPKl4HY0OPg XpOdv4YTsesIoVCr4POExlHifK4CZUGS4k7cJuXZo5L2LlTloBqgW/Hn0ehywtAVRhnb /c1w== X-Gm-Message-State: APjAAAUj40xoVdIKRN78KIVjLNYoChQuVNignKp0SXHk6o1IGun/32JP wDkqO59+f/v1JvkUJKPBl+EWiEtqoCPq/uZUcmQ= X-Google-Smtp-Source: APXvYqwFzRGkR2DYxiRDYBhgtnelZHEzuevBM9/uTazU94/B8X42hjr6aZLdEHSZBCMSGUo15+DHNAMqZriENYAnq/c= X-Received: by 2002:a1c:ac07:: with SMTP id v7mr27308011wme.49.1558033304227; Thu, 16 May 2019 12:01:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Thu, 16 May 2019 12:01:32 -0700 Message-ID: Subject: Re: Big TP codespace To: Jana Iyengar Cc: David Schinazi , Mike Bishop , Eric Rescorla , IETF QUIC WG , Christian Huitema Content-Type: multipart/alternative; boundary="000000000000a592fb058905e538" 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, 16 May 2019 19:01:49 -0000 --000000000000a592fb058905e538 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable yep, i'm conversing in there. On Wed, May 15, 2019 at 6:47 PM Jana Iyengar wrote: > Martin, the text in #2691 supports what you want to accomplish, but > doesn't require everyone to do the same thing. I think that's all we need= . > > On Wed, May 15, 2019 at 10:44 AM David Schinazi > wrote: > >> @ekr, the principle I was endorsing is the one Mike mentioned. >> >> On Wed, May 15, 2019 at 10:20 AM Mike Bishop >> wrote: >> >>> We agreed in Tokyo that we would not mandate that implementations check >>> for improper peer behavior when doing so required substantial extra wor= k. >>> Implementations MUST error out on easily-detected errors, but only >>> SHOULD/MAY error on things they would have to actively check (unless >>> they=E2=80=99re already required to actively check for security reasons= , in which >>> case there=E2=80=99s no *extra* work). >>> >>> >>> >>> *From:* QUIC *On Behalf Of * Eric Rescorla >>> *Sent:* Tuesday, May 14, 2019 5:21 PM >>> *To:* David Schinazi >>> *Cc:* IETF QUIC WG ; Christian Huitema < >>> huitema@huitema.net>; Martin Duke >>> *Subject:* Re: Big TP codespace >>> >>> >>> >>> What's the bigger principle you are endorsing? What errors "like this" >>> are we not requiring detection of? >>> >>> >>> >>> On Mon, May 13, 2019 at 5:19 PM David Schinazi >>> wrote: >>> >>> Our implementation checks for duplicates only for the transport >>> parameters it supports. I think #2691 >>> is the correct >>> solution. >>> >>> >>> >>> +1 to the design principle of encouraging but not requiring detection o= f >>> errors like this >>> >>> >>> >>> David >>> >>> >>> >>> On Mon, May 13, 2019 at 2:06 PM Christian Huitema >>> wrote: >>> >>> >>> >>> > On May 13, 2019, at 1:58 PM, Martin Duke >>> wrote: >>> > >>> > What do people think? >>> >>> I think the general rule of protocol policing should be "MUST NOT" do >>> dastardly stuff, and "MAY" drop the connection when that happens. >>> >>> -- Christian Huitema >>> >>> --000000000000a592fb058905e538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yep, i'm conversing in there.

On Wed, May 15, 2019 at 6= :47 PM Jana Iyengar <jri.ietf@gmai= l.com> wrote:
Martin, the text in #2691 supports what you want to a= ccomplish, but doesn't require everyone to do the same thing. I think t= hat's all we need.

On Wed, May 15, 2019 at 10:44 AM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com" target=3D"_blank">dschinazi.ietf= @gmail.com> wrote:
@ekr, the principle I was endorsing is the one = Mike mentioned.

On Wed, May 15, 2019 at 10:20 AM Mike Bishop <mbishop@evequefou.be>= ; wrote:

We agreed in Tokyo that we would not mandate that im= plementations check for improper peer behavior when doing so required subst= antial extra work.=C2=A0 Implementations MUST error out on easily-detected = errors, but only SHOULD/MAY error on things they would have to actively check (unless they=E2=80=99re already required= to actively check for security reasons, in which case there=E2=80=99s no extra work).

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Eric Rescorla
Sent: Tuesday, May 14, 2019 5:21 PM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>; Christian Huitema <huitema@huitema.net>; Martin Duke <= ;martin.h.duke= @gmail.com>
Subject: Re: Big TP codespace

=C2=A0

What's the bigger principle you are endorsing? W= hat errors "like this" are we not requiring detection of?<= u>

=C2=A0

On Mon, May 13, 2019 at 5:19 PM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com" target=3D"_blank">dschinazi.ietf= @gmail.com> wrote:

Our implementation checks for duplicates only for th= e transport parameters it supports. I think #2691 is the correct solution.

=C2=A0

+1 to the design principle of encouraging but not re= quiring detection of errors like this

=C2=A0

David

=C2=A0

On Mon, May 13, 2019 at 2:06 PM Christian Huitema &l= t;huitema@huitema= ..net> wrote:

=C2=A0

> On May 13, 2019, at 1:58 PM, Martin Duke <martin.h.duke@gmail.com> wrote:<= br> >
> What do people think?

I think the general rule of protocol policing should be "MUST NOT"= ; do dastardly stuff, and "MAY" drop the connection when that hap= pens.

-- Christian Huitema

--000000000000a592fb058905e538-- From nobody Fri May 17 07:56: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 C0B001200E3 for ; Fri, 17 May 2019 07:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Znl_fjRTf9Wr for ; Fri, 17 May 2019 07:56:07 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 8D402120363 for ; Fri, 17 May 2019 07:55:49 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id h1so8351708qtp.1 for ; Fri, 17 May 2019 07:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=1C3KpaWAnC6bLx36qRvXMR+Laj8QYqMDjW3j9/6emQQ=; b=xe0GpPzJrlgFjo8ML9dhvPCSPC+hopAHPeh+4cvC6gmEw+GqcTExa3T/0WUpfKg3Gb paYKpL0vc79Z5KfckhVH8oXe/SJGTUjy+WFy38S+pZflD1wWB2srZPMsqDtoHhdFtUcN c+NuwzY9hNRSIG7uRJXHCYHtdnzoa72lqTJ0EUH37PJMqY2wJrnm6xwnX6UPELW6GmGv 1AHz44qRFd5La2DCD0ciPjgl/v2f4qQ/LUqe1Ick8r0SgDTJXJyn8bWruV49h/aZEU9Z /o7IgvO7AHW3n8IHhoGjfiFfe5eMlpUcvpUZy2UlSsBJwYZiQCs99JgrsWdsB2LzR32B sv+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=1C3KpaWAnC6bLx36qRvXMR+Laj8QYqMDjW3j9/6emQQ=; b=je3r8czhUEJgKqlCjhKQtOvSS+/qA0hZB+jcOQDlRncomZXpxaZAv53R/Oaz5k+phy W0494KK2owS3COr0+oxtkludzHHF7ZCV7nMGnlVj1N/nlm5wTQmEkf2d79uKHP2C+Gnl A1Rn9Wd2ZI+B13Mns0s/3IN+RI1VLXdunJmhV+3znTyw8veTLM2o0i+QbNRcjSj0V81u rdC11jgciib317E92whxL/hO/E6wDhxmqBXctBX/ot+gNvN81to/1tTVahzcda7mDqXz UQussKgDHjYWJ19YioSMO+83DukvWhwKnmJjKHaqwOlBG222ITgZ/QedolvJ8CuttoPE EyNA== X-Gm-Message-State: APjAAAU5Fjvbj34aa8PzlVcbcOzKx8MQKexSbGR/YqMB/R4R3/8EyoxH zAIA9PcaTQAYeaFiC8COCZ6dJW180rg= X-Google-Smtp-Source: APXvYqzLE7pfGGYss3MB7KyY/FGYw6xEYn8PSb7DDetGvRsPjyPAxcZ+EJS2q1/TDswA+sgG7LRfug== X-Received: by 2002:aed:3e57:: with SMTP id m23mr50032004qtf.246.1558104948289; Fri, 17 May 2019 07:55:48 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id p37sm5950259qtj.90.2019.05.17.07.55.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 May 2019 07:55:47 -0700 (PDT) Date: Fri, 17 May 2019 10:55:41 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Re: HTTP/3 with strict priorities (PR #2700) Message-ID: <20190517145540.GA13238@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG References: <20190515205451.GA32701@ubuntu-dmitri> 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: Fri, 17 May 2019 14:56:10 -0000 On Wed, May 15, 2019 at 05:51:27PM -0400, Ian Swett wrote: > > 1. What is a _strict priority_? > > > > There is no definition of strict priority that I could find > > in the diff. Do strict priorities work outside of the > > dependency tree? For example, which stream has higher priority > > in the following figure? > > --- 8< --- 8< --- 8< --- > > Strict priorities are only relative to other siblings under the same > placeholder/root. I'll clarify that. Currently the text says "Higher > priority elements have all available data sent before elements of lower > priority." I see, so this is two levels of prioritization, with weights (if present) serving to determine how resources are allocated to streams that have the same priority. This feature is analogous to priority and concurrency in Patrick Meenan's proposal. [1] > > 3. What problem do all-or-nothing resources solve? > > > > " When [weight is] absent, indicates the resource should be > > " delivered all at once or not at all. > > > > This is new. I don't believe I've seen it in other prioritization > > proposals. Adding this dimension increases complexity. What > > problem do these all-or-nothing resources solve? > > > > This is an effort to incorporate Patrick Meenan's Round Robin Sequential > and Round Robin Interleaved proposal, as outlined on slide 49 here: > https://github.com/HTTPWorkshop/workshop2019/blob/master/talks/pardue-jones-priorities.pdf > or > here: http3-prioritization-proposal > > > I'm sure Patrick could rewrite this text more clearly, and I think > Patrick's explanation for the motivation is solid. I could not find the "all at once or not at all" concept mentioned in these documents, nor did I succeed in mapping the "not at all" part to anything in Patrick's proposal. Where can I find his explanation for the motivation? - Dmitri. 1. https://github.com/pmeenan/http3-prioritization-proposal From nobody Fri May 17 14:00: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 F1D9D12016F for ; Fri, 17 May 2019 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQU8BPCDi6gK for ; Fri, 17 May 2019 14:00:13 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 E2941120046 for ; Fri, 17 May 2019 14:00:12 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id f8so2065744wrt.1 for ; Fri, 17 May 2019 14:00:12 -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=ojC4Ea23ZQ8Pv6tYu3IW993XkEvSMxijP8hJ7r7uI0M=; b=Tifssx+uypCVO2qFqf/TFS9GTbrZM4FxSfAJ08xEMm4Y8MbMKhoXvSERSIM2WB1hVz Vq9W9uQndFHpwSs1x8Cbd3nX1ZCSW0WbyRMkNgr9RxEi+LQpN8QcGhmBBoSMimoETP+o E3yf2vvrFB1Pd/uh1GjRslNGsyveXhk8vx5BUgLiXt2wpih7uNuwhp7fu1ta76JH00w3 HBkn29adhMPWm29T/CobIMWQSQaAohe31/kbVxJYeoim/SvmCG5BzYnTvJh5H/sxClUg ET/TCWXwX81JZtBCnspDbzu0f4ctoMqKU1s/pPvhFUuI7L74hEkBKQ5ZavcEHCZEJK8/ WsfA== 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=ojC4Ea23ZQ8Pv6tYu3IW993XkEvSMxijP8hJ7r7uI0M=; b=UAunUJZF53+yTxqYQf1MD04o7TPdQIQ6UT6GGzZCohZXh3B5HVhRMlk3Du01ykC2a9 yOZRDPmUI40Uc5QCKjg8kIJqlZfoRqVJiQMkKQ5O2Tc8iayViGyJXdQpviDvMXfpKPy6 EZLX5RBKwX2YvAZUd6K2AomI/OoC4Xp9ub+0QEIZNs1WZAx4uNESP1IGyHhxW1MFdiku QSEahgKyHZevdprKlxqe7VTkLDWQ0bShB01YYrvupOygk5+SGb9EiKPLAyuW5mMLv7uN Om0Oxn82l1YejZWkn283/1kqjE3wKmHp0KE5c+MG0HOWssSXWxJFRY4sRftZOSiIATeZ Zc8w== X-Gm-Message-State: APjAAAVd2bwZK2zFLTNI4V8DpA1RuUYyxZ/2eSqehV20LDmVdi/kIO/x uE2xhu45QKoGZbE5F8EOwTXg9Fg88akufyHVAq3s4+u5X4Q3pA== X-Google-Smtp-Source: APXvYqw3Z2jYmt/tqLWTWpxbwhr9WnKLDWCysG34ic1ARn5joH+sSKsvhN0nffjpJqgBULyxF9dMo7XeIKdYg4luPGI= X-Received: by 2002:a5d:534b:: with SMTP id t11mr19719753wrv.297.1558126810635; Fri, 17 May 2019 14:00:10 -0700 (PDT) MIME-Version: 1.0 References: <20190515205451.GA32701@ubuntu-dmitri> <20190517145540.GA13238@ubuntu-dmitri> In-Reply-To: <20190517145540.GA13238@ubuntu-dmitri> From: Ian Swett Date: Fri, 17 May 2019 16:59:58 -0400 Message-ID: Subject: Re: HTTP/3 with strict priorities (PR #2700) To: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000108f0b05891babbf" 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, 17 May 2019 21:00:16 -0000 --000000000000108f0b05891babbf Content-Type: text/plain; charset="UTF-8" On Fri, May 17, 2019 at 10:56 AM Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Wed, May 15, 2019 at 05:51:27PM -0400, Ian Swett wrote: > > > 1. What is a _strict priority_? > > > > > > There is no definition of strict priority that I could find > > > in the diff. Do strict priorities work outside of the > > > dependency tree? For example, which stream has higher priority > > > in the following figure? > > > > --- 8< --- 8< --- 8< --- > > > > Strict priorities are only relative to other siblings under the same > > placeholder/root. I'll clarify that. Currently the text says "Higher > > priority elements have all available data sent before elements of lower > > priority." > > I see, so this is two levels of prioritization, with weights (if present) > serving to determine how resources are allocated to streams that have the > same priority. This feature is analogous to priority and concurrency in > Patrick Meenan's proposal. [1] > > > > 3. What problem do all-or-nothing resources solve? > > > > > > " When [weight is] absent, indicates the resource should be > > > " delivered all at once or not at all. > > > > > > This is new. I don't believe I've seen it in other prioritization > > > proposals. Adding this dimension increases complexity. What > > > problem do these all-or-nothing resources solve? > > > > > > > This is an effort to incorporate Patrick Meenan's Round Robin Sequential > > and Round Robin Interleaved proposal, as outlined on slide 49 here: > > > https://github.com/HTTPWorkshop/workshop2019/blob/master/talks/pardue-jones-priorities.pdf > > or > > here: http3-prioritization-proposal > > < > https://github.com/pmeenan/http3-prioritization-proposal/blob/master/README.md > > > > > > I'm sure Patrick could rewrite this text more clearly, and I think > > Patrick's explanation for the motivation is solid. > > I could not find the "all at once or not at all" concept mentioned > in these documents, nor did I succeed in mapping the "not at all" > part to anything in Patrick's proposal. Where can I find his > explanation for the motivation? > I'm referencing "Sequential" and "Interleaved" on slide 49. I added this text after your original review, which hopefully is clearer: "Higher priority elements have all available data sent before elements of lower priority. When multiple elements have the same priority, if a weight is specified, elements with weights are interleaved. If a weight is 0, either because it is the default weight or it was not specified, then elements are delivered sequentially and all available data from one element is sent before any data from the next. If a given priority level has some elements with weights and some without, the two groups share the available bandwidth equally." > - Dmitri. > > 1. https://github.com/pmeenan/http3-prioritization-proposal > > --000000000000108f0b05891babbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 17, 2019= at 10:56 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Wed, May 15, 2019 at 05:51:27PM -0400, = Ian Swett wrote:
> > 1. What is a _strict priority_?
> >
> >=C2=A0 =C2=A0 =C2=A0There is no definition of strict priority that= I could find
> >=C2=A0 =C2=A0 =C2=A0in the diff.=C2=A0 Do strict priorities work o= utside of the
> >=C2=A0 =C2=A0 =C2=A0dependency tree?=C2=A0 For example, which stre= am has higher priority
> >=C2=A0 =C2=A0 =C2=A0in the following figure?
> >
--- 8< --- 8< --- 8< ---
>
> Strict priorities are only relative to other siblings under the same > placeholder/root.=C2=A0 I'll clarify that.=C2=A0 Currently the tex= t says "Higher
> priority elements have all available data sent before elements of lowe= r
> priority."

I see, so this is two levels of prioritization, with weights (if present) serving to determine how resources are allocated to streams that have the same priority.=C2=A0 This feature is analogous to priority and concurrency = in
Patrick Meenan's proposal. [1]

> > 3. What problem do all-or-nothing resources solve?
> >
> >=C2=A0 =C2=A0 =C2=A0" When [weight is] absent, indicates the = resource should be
> >=C2=A0 =C2=A0 =C2=A0" delivered all at once or not at all. > >
> >=C2=A0 =C2=A0 =C2=A0This is new.=C2=A0 I don't believe I'v= e seen it in other prioritization
> >=C2=A0 =C2=A0 =C2=A0proposals.=C2=A0 Adding this dimension increas= es complexity.=C2=A0 What
> >=C2=A0 =C2=A0 =C2=A0problem do these all-or-nothing resources solv= e?
> >
>
> This is an effort to incorporate Patrick Meenan's Round Robin Sequ= ential
> and Round Robin Interleaved proposal, as outlined on slide 49 here: > https= ://github.com/HTTPWorkshop/workshop2019/blob/master/talks/pardue-jones-prio= rities.pdf
> or
> here: http3-prioritization-proposal
> <https://githu= b.com/pmeenan/http3-prioritization-proposal/blob/master/README.md> >
> I'm sure Patrick could rewrite this text more clearly, and I think=
> Patrick's explanation for the motivation is solid.

I could not find the "all at once or not at all" concept mentione= d
in these documents, nor did I succeed in mapping the "not at all"=
part to anything in Patrick's proposal.=C2=A0 Where can I find his
explanation for the motivation?

I'm= referencing "Sequential" and "Interleaved" on slide 49= .=C2=A0=C2=A0

I added this text after your origina= l review, which hopefully is clearer:
"Higher priority eleme= nts have all available data sent before elements of lower
priorit= y.=C2=A0 When multiple elements have the same priority, if a weight is
specified, elements with weights are interleaved.=C2=A0 If a weight i= s 0, either
because it is the default weight or it was not specif= ied, then elements are
delivered sequentially and all available d= ata from one element is sent before
any data from the next.=C2=A0= If a given priority level has some elements with
weights and som= e without, the two groups share the available bandwidth equally."


=C2=A0 - Dmitri.

1. https://github.com/pmeenan/http3-prioriti= zation-proposal

--000000000000108f0b05891babbf-- From nobody Fri May 17 17:40: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 00D751202BD for ; Fri, 17 May 2019 17:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j53xUl85auG for ; Fri, 17 May 2019 17:40:25 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 36C341200E9 for ; Fri, 17 May 2019 17:40:25 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id m3so8616641wrv.2 for ; Fri, 17 May 2019 17:40:25 -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=kM3f2B1J8hy5mTc3KaRoEdNBPh2khWEQk213a+3CWr0=; b=mnXRWIdO/P9hnn4aEVtGSB51ZvdN5U9L7r9OZDgA9QG+15UGM2vkv7U+ahL5XQbUAb OSLq4w0OkNAZf0fswO/jRRh5ZCht9c15yZYFatqMA7e75nV75VyCeIu+nv6Jds1P1946 yS22FPRL30E0YiwHZoKNn2QFUR1u12PAxEQgg6Lbf1h/Ex3+22xrrXeTm7YPz76r/Yey CeVOWHP8/muT5m5DqxTWbmq8PWn4IPDZiDleiI0xmsWanrG5QVy2DszXDJO0gdHp2Co9 fu2GY3SI81EAzkK4kuvBrvA/K+vrBSdjTjXqb9gi4qIuW7oEYB1DuvqdmNmA3dJhClVb WpFw== 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=kM3f2B1J8hy5mTc3KaRoEdNBPh2khWEQk213a+3CWr0=; b=iNqH8gcEPMBlhXyqm/3AWX1dBuObwgT6DrBADMmdIt+JJZ7vibqDCvoXqv5O/otQid soM/HRe1yXHjNr25fyfZlrNTNX0DMvNOikEzQ3dDf+jl+baaCrNcQMfkr/0HEcdLi6yj p6S6GLeDMqcZm4Ek2vqk9b/sn/HxyFMowR/00jCa3IycVXBBX4/wh2eAR5bEbs2wFHL4 VPj8Bxsc2xgVfx6kRr+SytdJrLONHpab77BR54GNG2RWcPMl30mDymwcY6lkyj0EhH67 5SQLNmWFSzL+OxFHkAmn/xQwsCIiqT50RvVS5QxW4it7Sd3+aA6wfm1tl8G7d71NCVo+ IPQQ== X-Gm-Message-State: APjAAAVZI2qeGN0eUpBw2jCikaC5AxVgrtEjZ1FTk5KIj3+zZrtqKWEG 5odvy5lpdnQMujUnWsuwW8t32ICoLEELw66bdwflEvOS/6E= X-Google-Smtp-Source: APXvYqySSNCGJkEf/3/zcuo0+rd0XmxccuXouTxZrmGzlsDpxJx1X6IcbFLXYDYpKTZClykC4BNYGavNjblIkQFfCGE= X-Received: by 2002:adf:dd0d:: with SMTP id a13mr19147310wrm.153.1558140023530; Fri, 17 May 2019 17:40:23 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Fri, 17 May 2019 17:40:11 -0700 Message-ID: Subject: QUIC-LB To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000009ced2d05891ebe74" 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, 18 May 2019 00:40:27 -0000 --0000000000009ced2d05891ebe74 Content-Type: text/plain; charset="UTF-8" As many of you know, the QUIC Load Balancers Working Group has plugging way for close to a year. Here's a snapshot of our current progress: https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/ We are reaching the point of diminishing returns. The draft is deliberately expansive, providing lots of options in anticipation of the WG eliminating some as unimportant use cases. While there are a handful of open issues, we hope to obtain WG adoption in the near future. I would certainly hope that, when QUIC ships, there is a QUIC-LB draft in a reasonably mature state (ie, vetted by the working group as a whole) so that equipment and software vendors can converge on a standard solution. If you're interested in the working group taking over this work sooner rather than later, I encourage you to make this known to the chairs. Thanks Martin The other one. No, the *other* other one. --0000000000009ced2d05891ebe74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As many of you know, the QUIC Load B= alancers Working Group has plugging way for close to a year.

=
Here's a snapshot of our current progress:
<= br>
We are reaching the point of diminishing returns. The draft i= s deliberately expansive, providing lots of options in anticipation of the = WG eliminating some as unimportant use cases.

Whil= e there are a handful of open issues, we hope to obtain WG adoption in the = near future. I would certainly hope that, when QUIC ships, there is a QUIC-= LB draft in a reasonably mature state (ie, vetted by the working group as a= whole) so that equipment and software vendors can converge on a standard s= olution.

If you're interested in the working g= roup taking over this work sooner rather than later, I encourage you to mak= e this known to the chairs.

Thanks
Marti= n
The other one. No, the other other one.
<= /div> --0000000000009ced2d05891ebe74-- From nobody Sat May 18 04:44:26 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 AA03C120177 for ; Sat, 18 May 2019 04:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqmbfPfIPTdV for ; Sat, 18 May 2019 04:44:22 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 305B0120124 for ; Sat, 18 May 2019 04:44:22 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id s20so7534399ioj.7 for ; Sat, 18 May 2019 04:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=n1hGo27+6WNtHKaehh/hZILVrtCD93qfo8/0j8TUeZc=; b=kxapTIYRsL6kvXqaz2DVKJTmJhBQitAPoQthiez1gkr4QNMiRU8PGa8OGzEtkX9Vae A0xkIdGK4VMoRuYr2Murp0EHsFHIQa7bL7l+jJt89zOaGaHqW36zDVEPQsYjrx0TpA2n YD2sd9BaZCJioHUqaPkZPLN8OZEPp9jMD3CVhzKlcHdg+UCLY294B8pG86uiJDnT2IlY vQXXuf+asuSCWz22BgmwfXpDWR+I+JOrYcC3bdGKKPDik31zhy6F4I/kvs8tKr7rK8bZ Pjvi4NF3FPsK6KyegvfJAtspJbw/RXcsepaQUY/VCTcy9HgXliCvIzeh4Eb0dQAIeSzk GdMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=n1hGo27+6WNtHKaehh/hZILVrtCD93qfo8/0j8TUeZc=; b=uoTZq30CKj09nm7O3eLthQR1M4/OTwdZ4QpxTeqay3e5wAW/St9BzHl3rqkF314A7P W1tQaUo6ks4o+CGMiVBVVbMr31YDXsFUYafPWvKYkddFQo35Xo2RyeUeIgZDm8O8Zq0I y19N8C2rBWhhJCuztg0lj/y3Oq7meCMH0YZbSD9SGNhZanwUOFeFFeCy0QlZNPSxRfaT 4+PrEugs7TT/I6dtfuehIty59gaut/FncjKkTXqcSin4xtZ7ASpzzt2Fz3tvlGX3gHcJ bw8r9C/LcTvu/2WhwVa84yq7xnodmo8hSrjlxxmDtMNvDrxSwcTr70gsm7rs40OXua8e ZyJw== X-Gm-Message-State: APjAAAXdiSyKl7uSfSkClfLCWLvVcSKuc4k+cbSb/UvYq0NcHhMil1og uxVlvhnhD60ENnafioYw+sw+LyUYNAMp5islyCcRwg== X-Google-Smtp-Source: APXvYqzs5ab8X2O7iAO49LighTTZfgxbzI86M+Bls/Nu8hakpwbKhI7GLi0zZ4dKvoVpvxHW6ASI7EalIB2Lt2u2Pz0= X-Received: by 2002:a05:6602:1c1:: with SMTP id w1mr20890723iot.75.1558179861243; Sat, 18 May 2019 04:44:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 18 May 2019 04:44:19 -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: Sat, 18 May 2019 04:44:19 -0700 Message-ID: Subject: Re: QUIC-LB To: IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="000000000000202dea05892805ba" 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, 18 May 2019 11:44:25 -0000 --000000000000202dea05892805ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for making this work. On a first pass over the text I was originally concerned about insider off-path attackers, but the auth token deals with that. I=E2=80=99m not sure that a further complication of a fully handshake= d LB protocol would be beneficial. Note that a load balancer might have many different users that do not trust each other and which are potentially off-path attackers towards one another . The load balancer might have to deal with many auth tokens at once. This is not necessarily a problem, but something to keep in mind. If the load balancer decides the token it is probably easy to manage. If the off-path insiders can see each others traffic, they can also see the auth tokens and steal them. This could be very bad. Well - technically off-path attackers cannot see traffic, but that is a simplistic assumption since switches can be manipulated easily to divert traffic temporarily. I believe there needs to a be some additional signature validation to the LB messages like a HMAC key or similar. I see the point of setting a QUIC version for LBv1, but it defeats the stated design goal of making it hide among QUIC packets. I=E2=80=99d remove= that design goal. The real purpose of the packaging appears to make the packets compatible with the traffic on the same network interfaces. I have not carefully read the section on message types, but the overall design seems simple enough and easy to add as an extension to an existing QUIC server implementation. Summarising what I write below: I recommend replacing the obfuscated divisor based algorithm with an efficient reversible integer hash algorithm. For the ciphers I recommend merging them into a single construct controlled by configuration parameters, and I suggest encrypting the entire CID, possible with an extra block that only the server needs to deal with. This will automatically protect additional server info bits. This makes the encryption a padded one or two block cipher with optional auth tag encoded as encrypted 0 padding. The 0 padding is simple and useful, but relatively weak. It would be simple to design something stronger that would allow a load balancer to filter more bad traffic before it hits a server. Mikkel Some minor and major feedback from reading through https://tools.ietf.org/html/draft-duke-quic-load-balancers-04 Sect. 1. : "QUIC allows servers (or load balancers) to designate an initial connection ID =E2=80=9C This could be misread os the original connection ID. I think the text needs to clarify that this ID happens after a server endpoint is chosen randomly and the first assigned ID ensures that the load balancers maintains that path. Sect. 1. : "In the absence of any shared state between load balancer and server, the load balancer must maintain a relatively expensive table of server-generated connection IDs, and will not route packets correctly if they use a connection ID that was originally communicated in a protected NEW_CONNECTION_ID frame. =E2=80=9C I=E2=80=99m not sure that you can generally say that it would not be routed correctly, but it cannot guarantee it in all cases. Very minor: Sect. 3. terms not explained: SCID (explained later), middlebox, 0/1-RTT, mix of 0RTT 1-RTT use of dash. A reference to invariants could clarify SCID= . A discussion on QUIC versions, or at least variants, would be useful before assuming CID placement at offset 1 in 3.1.1. Sect. 3.2.1. typo "routing mask that with more than=E2=80=9D. Sect. 3.2.1. complex formulation, suggest dropping first paragraph of these= : "The load balancer MUST NOT select a routing mask that with more than 126 routing bits set to 1, which allows at least 2 bits for config rotation (see Section 5 ) and 16 for server purposes in a maximum- length connection ID. The first two bits of an SCID MUST NOT be routing bits; these are reserved for config rotation. =E2=80=9C The latter paragraph fully captures the design and is much easier to unders= tand. Sect. 3.2. : I was initially concerned about performance, but the division can be converted into a multiplication and few other operations, but that will typically require some preselect divisors that are statically compiled and which an attacker will quickly learn. See alt. proposal below. Sect. 3.3.1.: Typo: "using the as many of the first octets=E2=80=9D Sect. 3.3.1: Reference to QUIC header protection is not a good idea since it is version dependent and as such an unnecessary dependency. Sect. 3.3.1.: The text is not clear about what is meant by =E2=80=9Cthe tok= en=E2=80=9D. In fact I don=E2=80=99t understand it. Is it a configuration parameter to make= the nonce configuration cycle specific? (Reading further, I guess this references the authentication token - if so, I=E2=80=99m not sure it is a g= ood idea to use it here since it might help crack the auth token without adding significant value to CID protection - you could just zero-pad instead). Sect. 3.3.1 Why not encrypt the additional server chosen CID =E2=80=9Cinfo= =E2=80=9D bits using the same key rather than requiring them to appear random. It is hard to squeeze in something crypto safe in a small space - this can be handled by using 1 bit of the nonce for CID=E2=80=99s longer than 16 bytes. The LB = need not decrypt the second block of the CID if there is one. Sect. 3.3.3.: Formulation: =E2=80=9C AES-ECB encrypts this nonce=E2=80=9D, = technically the nonce isn=E2=80=99t encrypted but used to encrypt the server_id. Also, ECB = cannot encrypt as it is an algorithm and not a process. This text is better "The server decrypts the server ID using 128-bit AES Electronic Codebook (ECB) mode,=E2=80=9D, but why would the server want to decrypt = its own server id? I can see it wants to encrypt it to generate a CID. Sect. 3.3. Overall: why is this a stream cipher. It looks like a block cipher to me. You could perhaps distinguish it from 3.4 by calling it a padded block cipher, or just padded cipher? To become a stream cipher you need a counter or similar progress. My suggestion to use one nonce bit for a second CID block is essentially that. Sect. 3.4.1.: using the word =E2=80=9Coctets=E2=80=9D instead of =E2=80=9Cb= ytes=E2=80=9D which is used elsewhere, and in QUIC. If my suggestion of encrypting a second block beyond 16 bytes is followed, the zero padding should be placed in first blok so the load balancer need not decrypt the second block. Sect. 3.4. The 0 paddding adds some protection against random attackers, but near zero protection against middleboxes that flips a bit to route traffic to wrong the server. A previously learned CID could also be used by none-middle boxes to flood a specific server without the load balancer being able to filter this. A checksum/tag of some sort would improve this. I don=E2=80=99t see why you would want a separate algorithm for 3.3 and 3.4= , especially if you follow my suggestion to also encrypt the additional =E2=80=9Cinfo=E2=80=9D bits. If you want more security, you just make the C= ID longer. Then 3.4. becoems a special case of 3.3. and you just need to mention it in security considerations. The zero padding length of 3.4. would then be allowed to be 0 to support both case 3.3. and 3.4 but recommended to be at least for 4 bytes for secure operation. I=E2=80=99d suggest an alternative to algorithm 3.2 which is simpler and fa= ster than generic division. You can get fast division by using a set of static divisors, but these are quickly learned by attackers. The following hash is a perfect bijective mapping and also has an efficient reverse mapping making it easy to generate CIDs for a specific server modulo. There is also a 64 bit version. The hash seed can be rotated. See also discussion on stackoverflow: http://stackoverflow.com/a/12996028 My version with hash seed added: /* This assumes the key points to a 32-bit aligned value. */ static inline size_t ht_uint32_hash_function(const void *key, size_t len) { uint32_t x =3D *(uint32_t *)key + (uint32_t)(HT_HASH_SEED); (void)len; /* http://stackoverflow.com/a/12996028 */ x =3D ((x >> 16) ^ x) * UINT32_C(0x45d9f3b); x =3D ((x >> 16) ^ x) * UINT32_C(0x45d9f3b); x =3D ((x >> 16) ^ x); return x; } inverse function without hash seed: unsigned int unhash(unsigned int x) { x =3D ((x >> 16) ^ x) * 0x119de1f3; x =3D ((x >> 16) ^ x) * 0x119de1f3; x =3D (x >> 16) ^ x; return x;} On 18 May 2019 at 02.40.42, Martin Duke (martin.h.duke@gmail.com) wrote: As many of you know, the QUIC Load Balancers Working Group has plugging way for close to a year. Here's a snapshot of our current progress: https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/ We are reaching the point of diminishing returns. The draft is deliberately expansive, providing lots of options in anticipation of the WG eliminating some as unimportant use cases. While there are a handful of open issues, we hope to obtain WG adoption in the near future. I would certainly hope that, when QUIC ships, there is a QUIC-LB draft in a reasonably mature state (ie, vetted by the working group as a whole) so that equipment and software vendors can converge on a standard solution. If you're interested in the working group taking over this work sooner rather than later, I encourage you to make this known to the chairs. Thanks Martin The other one. No, the *other* other one. --000000000000202dea05892805ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Thanks for making th= is work. On a first pass over the text I was originally concerned about ins= ider off-path attackers, but the auth token deals with that. I=E2=80=99m no= t sure that a further complication of a fully handshaked LB protocol would = be beneficial.
Note t= hat a load balancer might have many different users that do not trust each = other and which are potentially off-path attackers towards one another . Th= e load balancer might have to deal with many auth tokens at once. This is n= ot necessarily a problem, but something to keep in mind. If the load balanc= er decides the token it is probably easy to manage.

If the off-path insiders can see each others= traffic, they can also see the auth tokens and steal them. This could be v= ery bad. Well - technically off-path attackers cannot see traffic, but that= is a simplistic assumption since switches can be manipulated easily to div= ert traffic temporarily. I believe there needs to a be some additional sign= ature validation to the LB messages like a HMAC key or similar.

I see the point of setting a QUI= C version for LBv1, but it defeats the stated design goal of making it hide= among QUIC packets. I=E2=80=99d remove that design goal. The real purpose = of the packaging appears to make the packets compatible with the traffic on= the same network interfaces.

I have not carefully read the section on message types, but the ov= erall design seems simple enough and easy to add as an extension to an exis= ting QUIC server implementation.

Summarising what I write below: I recommend replacing the obfus= cated divisor based algorithm with an efficient reversible integer hash alg= orithm. For the ciphers I recommend merging them into a single construct co= ntrolled by configuration parameters, and I suggest encrypting the entire C= ID, possible with an extra block that only the server needs to deal with. T= his will automatically protect additional server info bits. This makes the = encryption a padded one or two block cipher with optional auth tag encoded = as encrypted 0 padding. The 0 padding is simple and useful, but relatively = weak. It would be simple to design something stronger that would allow a lo= ad balancer to filter more bad traffic before it hits a server.

Mikkel


Some minor and major feedback from reading through <= a href=3D"https://tools.ietf.org/html/draft-duke-quic-load-balancers-04">ht= tps://tools.ietf.org/html/draft-duke-quic-load-balancers-04

Sect. 1. :
"QUIC allows servers (or load balancers) to designate an initial
   conn=
ection ID =E2=80=9C

This could be misread os the original connection ID. I think the text=
 needs to clarify that this ID happens after a server endpoint is chosen ra=
ndomly and the first assigned ID ensures that the load balancers maintains =
that path.

Sect. 1. :
"In the absence of any shared state between load
   ba=
lancer and server, the load balancer must maintain a relatively
   expensive table of server-generated connection IDs, and will not
   route packets correctly if they use a connection ID that was
   originally communicated in a protected NEW_CONNECTION_ID frame.
=E2=80=9C

I=E2=80=99m not sure that you can generally say that it would=
 not be routed correctly, but it cannot guarantee it in all cases.
Very minor:

A discussion on QUIC versions, or at least variants, would be useful bef= ore assuming CID placement at offset 1 in 3.1.1.

Sect. 3.2.1. typo "routing mask that with more than=E2= =80=9D.
Sect. 3.2.1. complex formula= tion, suggest dropping first paragraph of these:
"The lo= ad balancer MUST NOT select a routing mask that with more than
= 
   126 routing b=
its set to 1, which allows at least 2 bits for config
   rotation (see Section 5) and 16 for server purposes in a ma=
ximum-
   length connection ID.

   The first two bits of an SCID MUST NOT be routing bits; these are
   reserved for config rotation.
=E2=80=9C
The latter paragraph fully captures the design and is much easier to=
 understand.

Sect. 3.2. : I was initially c= oncerned about performance, but the division can be converted into a multip= lication and few other operations, but that will typically require some pre= select divisors that are statically compiled and which an attacker will qui= ckly learn. See alt. proposal below.

Sect. 3.3.1.: Typo: &quo= t;using the as many of the first octets= =E2=80=9D
Sect. 3.3.1: Reference to QUIC header protection= is not a good idea since it is version dependent and as such an unnecessar= y dependency.
Sect. 3.3.1.: The text is not cle= ar about what is meant by=C2=A0=E2=80=9Cthe token=E2=80=9D. In fact I don= =E2=80=99t understand it. Is it a configuration parameter to make the nonce= configuration cycle specific? (Reading further, I guess this references th= e authentication token - if so, I=E2=80=99m not sure it is a good idea to u= se it here since it might help crack the auth token without adding signific= ant value to CID protection - you could just zero-pad instead).
Sect. = 3.3.1 Why not encrypt the additional server chosen CID=C2=A0=E2=80=9Cinfo= =E2=80=9D=C2=A0bits using the same key rather than requiring them to appear= random. It is hard to squeeze in something crypto safe in a small space - = this can be handled by using 1 bit of the nonce for CID=E2=80=99s longer th= an 16 bytes. The LB need not decrypt the second block of the CID if there i= s one.
Sect. 3.3.3.: Formulation:=C2=A0= =E2=80=9C AES-ECB encrypt= s this nonce= =E2=80=9D, technically the nonce isn=E2=80=99t encrypted but used to encryp= t the server_id. Also, ECB cannot encrypt as it is an algorithm and not a p= rocess. This text is better "The server decrypts the server ID using 128-bit AES Electronic
   Code=
book (ECB) mode,=E2=80=9D, but why would the server want to decrypt its own server id? I =
can see it wants to encrypt it to generate a CID.

Sect. 3.3. Overall: w= hy is this a stream cipher. It looks like a block cipher to me. You could p= erhaps distinguish it from 3.4 by calling it a padded block cipher, or just= padded cipher? To become a stream cipher you need a counter or similar pro= gress. My suggestion to use one nonce bit for a second CID block is essenti= ally that.







My version with hash seed added:
/* This assumes the key points to a 32-bit aligned value. */
static inline size_t ht_uint32_hash_function(const void *key, size_t len)=
{
=C2=A0 =C2=A0 uint32_t x =3D *(uint32_t *)key + (uin= t32_t)(HT_HASH_SEED);

=C2=A0 =C2=A0 (void)len;

=C2=A0 =C2= =A0 x =3D ((x >> 16) ^ x) * UINT32_C(0x45d9f3b);
=C2=A0 =C2= =A0 x =3D ((x >> 16) ^ x) * UINT32_C(0x45d9f3b);
=C2=A0 =C2= =A0 x =3D ((x >> 16) ^ x);
=C2=A0 =C2=A0 return x;
}
inverse function without hash seed:
unsigned=
 int unhash(unsigned int x) {
    x =3D ((x >> 16) ^ x) * 0x119de1f3;
    x =3D ((x >> 16) ^ x) * 0x119de1f3;
    x =3D (x >> 16) ^ x;
    return=
 x;
}


On 18= May 2019 at 02.40.42, Martin Duke (martin.h.duke@gmail.com) wrote:

As many of you know, the QUIC Load Balancers Working Group has plugging way for close to a year.

Here's a snapshot of our current progress:

We are reaching the point of diminishing returns. The draft is deliberately expansive, providing lots of options in anticipation of the WG eliminating some as unimportant use cases.

While there are a handful of open issues, we hope to obtain WG adoption in the near future. I would certainly hope that, when QUIC ships, there is a QUIC-LB draft in a reasonably mature state (ie, vetted by the working group as a whole) so that equipment and software vendors can converge on a standard solution.

If you're interested in the working group taking over this work sooner rather than later, I encourage you to make this known to the chairs.

Thanks
Martin
The other one. No, the other other one.
--000000000000202dea05892805ba-- From nobody Sat May 18 17:45: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 874BF1200B5 for ; Sat, 18 May 2019 17:45: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, 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=tuKuNMGf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KzIMrb4k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7ufdbMR7D2v for ; Sat, 18 May 2019 17:45:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AA112004F for ; Sat, 18 May 2019 17:45:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9992424094 for ; Sat, 18 May 2019 20:45:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 18 May 2019 20:45:21 -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=NvpCCdQRKl5BCqJtkWXCCofF2uTXqag0joSexTAKw08=; b=tuKuNMGf fbw6RbylgEsUwc+6FzM9Bp/ry+znDNIf4F0aOBRYCIp0ojjetYXz6RhVdS5ZQQGh 3cOgVORwHFCqwrBfTznbIBfT5UZWsuRAX1gQyNo39lhqzzAGj/YfBylOCBIKAAwB hRuxc4Kg//v2XY9YemPBD11ms5QSnGOFMFw/pQaRNNqI0F9+VZYiRPU+t3R5vomu KQ6vENmT+edAMt+p+FQvvVmBTO365xnADTAT6M0zNN2tqnXHeY47pHv6EcZHtf4T 8wgqzOLgMrDFsOtrEt4koEx3dtppoUzWFaXURZnIsSmsJyoVLzoGFugEE3bvRXFE ngfopnlkyuiVBg== 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=NvpCCdQRKl5BCqJtkWXCCofF2uTXq ag0joSexTAKw08=; b=KzIMrb4kiXu5G+fffmHreQsjFGvYv0XLYbaiGKIpaKeja o+Dgwhxiow5nfECv5UW3lluPWVoapFcfGGI6wPM15ck2PXWjD+u021Yra3vSv57j MHa5ozLowPMu1Lr8uYWzB58buOY/AFPbXe5d3RU1wyn6pg27b6s35p70yzizrS+I 5U0N3TdrWAif92Y6vBe0xnvhttCDURRBJVwFKpFvBYPUGrcSx2RjE3iRdAIoYv+1 XEt6/FXrTTi0BnM2nq+khsN4CCvNK6ef5pgQPawfug9uyBiWwi41Tfqqwa+Zl15v B3JUnQVS9BtbwRb0IUjO1R0QZFvLldV78j8JMs6yQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddthedgfeekucetufdoteggodetrfdotf 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 C69F7103CB for ; Sat, 18 May 2019 20:45:19 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id C02BEC0383 for ; Sun, 19 May 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============6080908309798540698==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190519004516.C02BEC0383@cloud.mnot.net> Date: Sun, 19 May 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, 19 May 2019 00:45:26 -0000 --===============6080908309798540698== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+7/-7/=F0=9F=92=AC53) 7 issues created: - Make it easier to see where frames belong (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2721 = - Privacy of spin with multiple connections on same 5 tuple (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2720 = - Unclear conditions in long header descr. (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2719 = - Truncated http stream error handling is aggressive (by mikkelfj) https://github.com/quicwg/base-drafts/issues/2718 = - GOAWAY errors are wrong (by MikeBishop) https://github.com/quicwg/base-drafts/issues/2714 [-http] [design] = - Prohibiting server-initiated streams for h3 (by martinthomson) https://github.com/quicwg/base-drafts/issues/2711 = - Second SETTINGS frame on any stream other than the control stream error= (by DaanDeMeyer) https://github.com/quicwg/base-drafts/issues/2706 = 13 issues received 53 new comments: - #2581 Bring back AEAD_AES_128_CCM_8 now that we pad the plaintext (12 b= y janaiyengar, mikkelfj, DavidSchinazi, ianswett, RyanAtGoogle, ekr) https://github.com/quicwg/base-drafts/issues/2581 [-tls] [design] = - #2711 Prohibiting server-initiated streams for h3 (7 by martinthomson, = MikeBishop, kazuho, LPardue, mikkelfj) https://github.com/quicwg/base-drafts/issues/2711 [-http] = - #2645 Retire My Own CID (7 by mikkelfj, janaiyengar, nibanks, ianswett) https://github.com/quicwg/base-drafts/issues/2645 [-transport] = - #2699 HTTP/3 Client handling of SERVER_BUSY error code needs to be spec= ified (6 by pravb, LPardue, ianswett) https://github.com/quicwg/base-drafts/issues/2699 [-http] [design] = - #2551 Replace HTTP_MALFORMED_FRAME for something simpler (5 by kazuho, = afrind, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2551 [-http] [design] = - #2706 Second SETTINGS frame on any stream other than the control stream= error (4 by DaanDeMeyer, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2706 = - #2718 Truncated http stream error handling is aggressive (3 by martinth= omson, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2718 [-http] [design] = - #2389 Be clearer about the purpose of disable_migration (3 by igorlord,= janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/issues/2389 [-transport] [design] = - #2719 Unclear conditions in long header descr. (2 by MikeBishop, mikkel= fj) https://github.com/quicwg/base-drafts/issues/2719 [-transport] [editori= al] = - #2225 Confusing text around push streams (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/2225 [-http] [editorial] = - #2367 Text banning post-handshake client auth is unclear (1 by janaiyen= gar) https://github.com/quicwg/base-drafts/issues/2367 [-transport] [editori= al] = - #2685 CC state after a change of path? (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/2685 [-transport] = - #2686 Pacing when under-utilizing the Congestion Window (1 by janaiyeng= ar) https://github.com/quicwg/base-drafts/issues/2686 [-recovery] [editoria= l] = 7 issues closed: - How do I generate an RST? https://github.com/quicwg/base-drafts/issues/= 2228 [-http] [design] = - Can I send non-data frames on CONNECT streams? https://github.com/quicw= g/base-drafts/issues/2229 [-http] [design] = - GOAWAY errors are wrong https://github.com/quicwg/base-drafts/issues/27= 14 [-http] [design] = - When can PUSH_PROMISE frames be sent? https://github.com/quicwg/base-dr= afts/issues/2230 [-http] [editorial] = - Second SETTINGS frame on any stream other than the control stream error= https://github.com/quicwg/base-drafts/issues/2706 = - Move HTTP Section 5 before Section 4 https://github.com/quicwg/base-dra= fts/issues/2220 [-http] [editorial] = - Discuss HTTP/2 more in the introduction https://github.com/quicwg/base-= drafts/issues/1601 [-http] [editorial] = Pull requests ------------- * quicwg/base-drafts (+16/-11/=F0=9F=92=AC48) 16 pull requests submitted: - HTTP/3 Zero-weighting (by rmarx) https://github.com/quicwg/base-drafts/pull/2723 = - Specify push stream truncated last frame error. (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2722 = - Fix formatting of some recovery pseudo-code (by ghedo) https://github.com/quicwg/base-drafts/pull/2717 = - Reaplace mentions of MAX_STREAM_ID with MAX_STREAMS in HTTP/3 (by ghedo) https://github.com/quicwg/base-drafts/pull/2716 = - Specify error for a DATA frame before any HEADERS frames (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2715 [-http] [design] = - Fix GOAWAY errors properly (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2713 [-http] [design] = - Specify error on receipt a DATA frame before a HEADERS frame on a reque= st stream (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2712 = - Split SETTINGS handling error text (by LPardue) https://github.com/quicwg/base-drafts/pull/2710 = - Specify server error on receipt of a PUSH_PROMISE frame (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2709 = - Specify HEADERS on control stream error. (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2708 = - Fix GOAWAY connection errors. (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2707 = - Fix GOAWAY connection errors. (by DaanDeMeyer) https://github.com/quicwg/base-drafts/pull/2705 = - Push SHOULD precede reference (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2704 [-http] [editorial] = - CONNECT error: MUST close, SHOULD RST (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2703 [-http] [design] = - Prohibit other frame types on CONNECT (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2702 [-http] [design] = - Reorder sections (by MikeBishop) https://github.com/quicwg/base-drafts/pull/2701 [-http] [editorial] = 15 pull requests received 48 new comments: - #2700 HTTP/3 with strict priorities (16 by kazuho, pmeenan, mikkelfj, M= ikeBishop, ianswett, rmarx, dtikhonov, LPardue) https://github.com/quicwg/base-drafts/pull/2700 = - #2723 HTTP/3 Zero-weighting (5 by igorlord, DaanDeMeyer, mikkelfj) https://github.com/quicwg/base-drafts/pull/2723 = - #2665 Reference 8.2 of RFC7540 to explain Server Push (5 by MikeBishop,= ianswett) https://github.com/quicwg/base-drafts/pull/2665 [-http] [editorial] = - #2712 Specify error on receipt a DATA frame before a HEADERS frame on a= request stream (4 by LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/2712 = - #2701 Reorder sections (3 by martinthomson, janaiyengar, MikeBishop) https://github.com/quicwg/base-drafts/pull/2701 [-http] [editorial] [me= rge-imminent] = - #2690 Orphan Placeholder (2 by kazuho, rmarx) https://github.com/quicwg/base-drafts/pull/2690 [-http] [design] = - #2691 Relax requirement of detecting duplicate TPs on receiver (2 by ja= naiyengar, martinduke) https://github.com/quicwg/base-drafts/pull/2691 [-transport] = - #2707 Fix GOAWAY connection errors. (2 by LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/2707 [-http] [design] = - #2673 Output of the discard keys design team (2 by DavidSchinazi, janai= yengar) https://github.com/quicwg/base-drafts/pull/2673 [-transport] [design] = - #2687 New paths may seed initial_rtt (2 by janaiyengar, ianswett) https://github.com/quicwg/base-drafts/pull/2687 [-recovery] = - #2702 Prohibit other frame types on CONNECT (1 by kazuho) https://github.com/quicwg/base-drafts/pull/2702 [-http] [design] = - #2703 CONNECT error: MUST close, SHOULD RST (1 by ekr) https://github.com/quicwg/base-drafts/pull/2703 [-http] [design] = - #2708 Specify HEADERS on control stream error. (1 by LPardue) https://github.com/quicwg/base-drafts/pull/2708 = - #2710 Split SETTINGS handling error text (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2710 [-http] [editorial] = - #2713 Fix GOAWAY errors properly (1 by MikeBishop) https://github.com/quicwg/base-drafts/pull/2713 [-http] [design] = 11 pull requests merged: - CONNECT error: MUST close, SHOULD RST https://github.com/quicwg/base-drafts/pull/2703 [-http] [design] = - Prohibit other frame types on CONNECT https://github.com/quicwg/base-drafts/pull/2702 [-http] [design] = - Fix GOAWAY connection errors. https://github.com/quicwg/base-drafts/pull/2707 [-http] [design] = - Reference 8.2 of RFC7540 to explain Server Push https://github.com/quicwg/base-drafts/pull/2665 [-http] [editorial] = - Push SHOULD precede reference https://github.com/quicwg/base-drafts/pull/2704 [-http] [editorial] = - Replace mentions of MAX_STREAM_ID with MAX_STREAMS in HTTP/3 https://github.com/quicwg/base-drafts/pull/2716 = - Fix formatting of some recovery pseudo-code https://github.com/quicwg/base-drafts/pull/2717 = - Split SETTINGS handling error text https://github.com/quicwg/base-drafts/pull/2710 [-http] [editorial] = - Specify server error on receipt of a PUSH_PROMISE frame https://github.com/quicwg/base-drafts/pull/2709 [-http] [design] = - Reorder sections https://github.com/quicwg/base-drafts/pull/2701 [-http] [editorial] [me= rge-imminent] = - Pull some H2 content into the introduction https://github.com/quicwg/base-drafts/pull/2683 [-http] [editorial] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============6080908309798540698== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday May 19, 2019

Issues

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

7 issues created:

13 issues received 53 new comments:

7 issues closed:

Pull requests

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

16 pull requests submitted:

15 pull requests received 48 new comments:

11 pull requests merged:

Repositories tracked by this digest:

--===============6080908309798540698==-- From nobody Mon May 20 07:19: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 0C59A120089 for ; Mon, 20 May 2019 07:19:34 -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_PASS=-0.001, UNPARSEABLE_RELAY=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 iwx4lL6dnYBW for ; Mon, 20 May 2019 07:19:32 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9840012008F for ; Mon, 20 May 2019 07:19:32 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4571HQ50BKzCrsk; Mon, 20 May 2019 16:19:30 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 4571HQ43kQzDq7p; Mon, 20 May 2019 16:19:30 +0200 (CEST) Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([fe80::849f:f804:b713:d99a%21]) with mapi id 14.03.0439.000; Mon, 20 May 2019 16:19:30 +0200 From: To: Mark Nottingham , QUIC IETF mailing list CC: Lars Eggert Subject: RE: Agenda for the London Interim meeting Thread-Topic: Agenda for the London Interim meeting Thread-Index: AQHVBU6+emUY9cprwkmn2WrWPUzwkqZ0ItCw Date: Mon, 20 May 2019 14:19:30 +0000 Message-ID: <14798_1558361970_5CE2B772_14798_309_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931E47A66@OPEXCAUBM44.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 20 May 2019 14:19:34 -0000 Hi Mark, I probably forget to register to the interim for a remote participation. Can you add me to the remote participants ? Best regards Emile -----Message d'origine----- De=A0: QUIC [mailto:quic-bounces@ietf.org] De la part de Mark Nottingham Envoy=E9=A0: mercredi 8 mai 2019 05:33 =C0=A0: QUIC IETF mailing list Cc=A0: Lars Eggert Objet=A0: Agenda for the London Interim meeting .... is at: https://github.com/quicwg/wg-materials/blob/master/interim-19-05/agenda.md Suggestions (including for "as time permits" sessions) welcome. Cheers, -- Mark Nottingham https://www.mnot.net/ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon May 20 09:24:44 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 E89311201B0 for ; Mon, 20 May 2019 09:24:42 -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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 pKUo4r88sIiA for ; Mon, 20 May 2019 09:24:40 -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 B68FF1201CF for ; Mon, 20 May 2019 09:24:28 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4KGDAnJ023512; Mon, 20 May 2019 17:24:20 +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=KSNTbwtxD79cnuZGS08VPUcX9D7/9tsbFdaxbJP+Cdk=; b=VG5DxoktB9KC/o7xWcDaXh+E+glpNp5W5zeRfvM0D/Vu4wIT6QdjeMkAQqPL8x5rSMUP LhxOYnOy2do91iCpLttiSDemijp3DejVNrOnzhYPH51/gf1mAWtoX2PDVCCIvrSo0az2 QPUCtEPgaApKJfOwFKwwsu3Al4ZQoljx0zpEWZhxNUYi4PVon3N8CZ2XdYZAaOQMX/jh T+p0+ffw8ATa41r1DOmRKwpLpSBth8EHeeH1vFjLRAd0X2BeR5WOYwxaz590CbYhkeuM Z2+lLvFoaqRuJLMp4KneVIOiK00jbbkkj1vGkrIIzng2oRsEhJ2QKj1UFE7hkE0mqTsz jA== 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 2skxmc86tr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 May 2019 17:24:20 +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 x4KGHrEh029019; Mon, 20 May 2019 12:24:19 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2sjdcv826a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 20 May 2019 12:24:19 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 20 May 2019 12:24:17 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1473.003; Mon, 20 May 2019 12:24:17 -0400 From: "Lubashev, Igor" To: "emile.stephan@orange.com" , Mark Nottingham , QUIC IETF mailing list CC: Lars Eggert Subject: RE: Agenda for the London Interim meeting Thread-Topic: Agenda for the London Interim meeting Thread-Index: AQHVBU6/xijDhdqjd0uq86QEKM0mlqZ0ZoQA///feAA= Date: Mon, 20 May 2019 16:24:17 +0000 Message-ID: References: <14798_1558361970_5CE2B772_14798_309_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931E47A66@OPEXCAUBM44.corporate.adroot.infra.ftgroup> In-Reply-To: <14798_1558361970_5CE2B772_14798_309_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931E47A66@OPEXCAUBM44.corporate.adroot.infra.ftgroup> 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.87] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_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-1905200105 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_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-1905200105 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, 20 May 2019 16:24:43 -0000 Mark, I registered as in-person, but I will have to be remote. Could you, = please, send me the remote participant link? Many thanks, - Igor > -----Original Message----- > From: emile.stephan@orange.com > Sent: Monday, May 20, 2019 10:20 AM > To: Mark Nottingham ; QUIC IETF mailing list > > Cc: Lars Eggert > Subject: RE: Agenda for the London Interim meeting >=20 > Hi Mark, >=20 > I probably forget to register to the interim for a remote participation. > Can you add me to the remote participants ? >=20 > Best regards > Emile >=20 > -----Message d'origine----- > De=A0: QUIC [mailto:quic-bounces@ietf.org] De la part de Mark Nottingham > Envoy=E9=A0: mercredi 8 mai 2019 05:33 =C0=A0: QUIC IETF mailing list Cc= =A0: Lars Eggert > Objet=A0: Agenda for the London Interim meeting >=20 > ..... is at: > https://github.com/quicwg/wg-materials/blob/master/interim-19- > 05/agenda.md >=20 > Suggestions (including for "as time permits" sessions) welcome. >=20 > Cheers, >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Tue May 21 06:48: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 E1C35120043; Tue, 21 May 2019 06:48:40 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 97nPPaqa8FUS; Tue, 21 May 2019 06:48:38 -0700 (PDT) Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (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 22C67120041; Tue, 21 May 2019 06:48:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,495,1549929600"; d="scan'208,217";a="7936522" X-IPAS-Result: =?us-ascii?q?A2GLAQBtAORc/wEBeAplHAEBAQQBAQcEAQGBUgYBAQsBg?= =?us-ascii?q?Q6BAlgRUSESMqh6gn2CVYMnFIFnCQEBAQEBAQEBASsJAQIBAYRAAoInIzUID?= =?us-ascii?q?gEDAQEBBAEBAQECAQECAmkcDIVOATBMEgEFEBVWJgEEAQ0NE4MIgR1tD6gDG?= =?us-ascii?q?oQtQYUoBoE0AYFfjAeBV4VrAgMBgSU6gzqCJgSSVJVPBwKBK2QDggyEH4ZAh?= =?us-ascii?q?i1yi3EDiUaJPoMYhnKQTwE2gVczGieDOYsRhT9CgVEIi3IBgSABAQ?= X-URL-LookUp-ScanningError: 1 From: Kuhn Nicolas To: "tsvwg@ietf.org" , IETF QUIC WG , "'tls@ietf.org'" CC: "'emile.stephan@orange.com'" , "'gorry@erg.abdn.ac.uk'" , Kuhn Nicolas Subject: Updates on the "Transport parameters for 0-RTT connections" draft Thread-Topic: Updates on the "Transport parameters for 0-RTT connections" draft Thread-Index: AdUP24Zg+1VIa8FMRoKfDVG/fwUlTg== Date: Tue, 21 May 2019 13:47:28 +0000 Deferred-Delivery: Tue, 21 May 2019 13:48:27 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24628.005 x-tm-as-result: No--19.463400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_" MIME-Version: 1.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: Tue, 21 May 2019 13:48:41 -0000 --_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Following the different feedbacks on this draft, we have proposed an update= d version on the "Transport parameters for 0-RTT connections". https://datatracker.ietf.org/doc/draft-kuhn-quic-0rtt-bdp/ The draft proposes a solution where path characteristics are shared between= the peers to improve the ingress traffic for 0-RTT connections. The difference with version 01 are mainly based on the received feedback. In short, we now a BDP_metadata structure so that various path parameters c= an be exposed to the client (MTU, RTT, bandwidth, loss-rate). We have also added a section to discuss what happens when BDP is used incor= rectly. Let us know if we have any views or interest in this proposal. Cheers, Nico for the authors --_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Following the different feedbac= ks on this draft, we have proposed an updated version on the “Transpo= rt parameters for 0-RTT connections”.

https://datatracker.ietf.org/doc/dr= aft-kuhn-quic-0rtt-bdp/

 

The draft proposes a solution w= here path characteristics are shared between the peers to improve the ingre= ss traffic for 0-RTT connections.

 

The difference with version 01 = are mainly based on the received feedback.

In short, we now a BDP_metadata= structure so that various path parameters can be exposed to the client (MT= U, RTT, bandwidth, loss-rate).

We have also added a section to= discuss what happens when BDP is used incorrectly.

 

Let us know if we have any view= s or interest in this proposal.

 

Cheers,

 

Nico for the authors=

 

--_000_F3B0A07CFD358240926B78A680E166FF1EBEEF69TWMBXP03cnesnet_-- From nobody Tue May 21 06:52: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 30773120043 for ; Tue, 21 May 2019 06:52:28 -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=m/W2mv3G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xQzhaIpp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Igchycj-ToTB for ; Tue, 21 May 2019 06:52: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 A65FD120041 for ; Tue, 21 May 2019 06:52:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B0236506; Tue, 21 May 2019 09:52:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 21 May 2019 09:52:24 -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=C AA5pNIaDPyhAuUMuBqf/GWO1jC/l/Sgh+hh10eNuRU=; b=m/W2mv3GhiF2BxTom 7a+av4VgZWtjIvJYV19rGfsHExQPeYx1nvTM2jcmbfJFQIxTOOfhIf6JzVO7B63S vm/DNPqCBs/Ie2AK03PUimx016LLjc1o1SqxkonmrCr6jVA3R4tXtxb11u8ttHEB eRIHm1Zl0xlauq35/hG8ddtRtETIFCbmBCMVy9m8xBcqzhEH4bJoaWu5hbR5aQcf fGHlL8oyVS7ulg4SNJYps65vkkdogFmLoN4+zx+AtPsQ5H6+wogGh6hSLtFv5sBr MGyw6mr5D7mw3R2Zl7EVJiA4a1w/F+q191J/1JvCoadjwOmZczIC2Ifx2kEg8Rio +Z3jw== 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=CAA5pNIaDPyhAuUMuBqf/GWO1jC/l/Sgh+hh10eNu RU=; b=xQzhaIppe0QGKR2WC/7t2m1gznRrsgbkI7LZ/EKDYQ+80mkLyfhqFJ0jw GeB9z7ZTZSikXeozDhNOM5u0/K9PCcstA42hJ+mIblQPbGxMX4D5pqTHT2/pZkwp 4y4TRyCIovWdSk+fv1Qmiq098PNvUbKNpK0dwuPKcgTC+/0jjPFHwOkafkbolAMf FZ+PtCWtBARngx6/dDHxx+AGfgzaepgwIr8faFszNEb3x8AXtylBCgP4QSPOJjuD XyS/TcTQJlQa4G367GuCzZU8Cdl7tusTS92aMIx6X+PC6YGZdPh8em6BIpN3x0U3 VRLDuSvJ9YEP1YU21tlxIJFltCORQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddutddgjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepvddujedrudefkedriedv rddvgeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.203.87] (unknown [217.138.62.243]) by mail.messagingengine.com (Postfix) with ESMTPA id 67CFD80062; Tue, 21 May 2019 09:52:20 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: Agenda for the London Interim meeting From: Mark Nottingham In-Reply-To: Date: Tue, 21 May 2019 14:52:17 +0100 Cc: "emile.stephan@orange.com" , QUIC IETF mailing list , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: References: <14798_1558361970_5CE2B772_14798_309_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931E47A66@OPEXCAUBM44.corporate.adroot.infra.ftgroup> To: "Lubashev, Igor" X-Mailer: Apple Mail (2.3445.104.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, 21 May 2019 13:52:28 -0000 You and the other people who asked privately have been added to the = remote participation list; if you haven't received an invite, please = respond privately. In the future, please do register on time; we cannot guarantee that = we'll respond to last-minute e-mails. Thanks, > On 20 May 2019, at 5:24 pm, Lubashev, Igor = wrote: >=20 > Mark, I registered as in-person, but I will have to be remote. Could = you, please, send me the remote participant link? >=20 > Many thanks, >=20 > - Igor >=20 >> -----Original Message----- >> From: emile.stephan@orange.com >> Sent: Monday, May 20, 2019 10:20 AM >> To: Mark Nottingham ; QUIC IETF mailing list >> >> Cc: Lars Eggert >> Subject: RE: Agenda for the London Interim meeting >>=20 >> Hi Mark, >>=20 >> I probably forget to register to the interim for a remote = participation. >> Can you add me to the remote participants ? >>=20 >> Best regards >> Emile >>=20 >> -----Message d'origine----- >> De : QUIC [mailto:quic-bounces@ietf.org] De la part de Mark = Nottingham >> Envoy=C3=A9 : mercredi 8 mai 2019 05:33 =C3=80 : QUIC IETF mailing = list Cc : Lars Eggert >> Objet : Agenda for the London Interim meeting >>=20 >> ..... is at: >> https://github.com/quicwg/wg-materials/blob/master/interim-19- >> 05/agenda.md >>=20 >> Suggestions (including for "as time permits" sessions) welcome. >>=20 >> Cheers, >>=20 >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >>=20 >> __________________________________________________________ >> __________________________________________________________ >> _____ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites >> ou copies sans autorisation. Si vous avez recu ce message par erreur, = veuillez >> le signaler a l'expediteur et le detruire ainsi que les pieces = jointes. Les >> messages electroniques etant susceptibles d'alteration, Orange = decline toute >> responsabilite si ce message a ete altere, deforme ou falsifie. = Merci. >>=20 >> This message and its attachments may contain confidential or = privileged >> information that may be protected by law; they should not be = distributed, >> used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete >> this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been >> modified, changed or falsified. >> Thank you. >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed May 22 07:12: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 7AA71120033 for ; Wed, 22 May 2019 07:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BI3M2663c1m1 for ; Wed, 22 May 2019 07:12:47 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 4471F12004F for ; Wed, 22 May 2019 07:12:46 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id z128so1549914qkb.6 for ; Wed, 22 May 2019 07:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=MlHCW3JoS/VEdAfqnBa6PX37/ILvL0Jmvt0Jsts7k70=; b=0P35hiRqVzyGEZ4xHwNtmZwW4YkWbz9JHkzI/mNbfqeFldUz2ym3YcAciVc3Ve+erd BofejR0yokQO9X1qjEjjf5zLnS/DfPV+SpBEdcMIm2A22giVYb5u/nhPMt5ZRknJHuQH L13J1CK5kke3fMcG/kmssgtCSFf9xbCj92Av4+/uPdVs/2u1MReneuwp+1GNHOpbpkNt Y5H0kWjUvfe4vkBrnmA6DURnps7jvDqmkHmDecyxiD2ogZit8ofPlfQZB/AnHewuEgnf CXEY3Ma8haWco0ybBXZC7RGUcws6JMCCxWxwiu3cIgvczqxuqAXIY4PwKhv9oAGaHYfv W+CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=MlHCW3JoS/VEdAfqnBa6PX37/ILvL0Jmvt0Jsts7k70=; b=R6ahmEN7dW0F4XGqyLsTMTk/nsgn6IMOpltZTmCGBp734gzNCDzaTeYfkLH6EwgyCf 0hifsuy5+GzagAcbf5EWIDgZSgM4n6lCo9jOxh25S/J4J/dH1kTLWEDHl8o9v01Z3Vsr MEjNwhG5jSX3nFH6NLvv2bsmzxTyuphDwZtUnUgQs3b3jebF4ywKJb2nqypCsZLlQbI/ vlRKG61H69LvcwQC30kLjUSZEk9XXpOPRQ/uO2WEUDeAyX9I7taIoerZ3QyIQNmmSnR+ XsN2hH4fzCUxYuF9dv/NveK87GkiUznba2chXHLsnbOs6EoXoGcceJ2gKmFyXsTBAHGZ mOHg== X-Gm-Message-State: APjAAAVwPj6tsm3eE8MMLkjhYGr0sgQGO9s+dRkrEjc8bTbKo3s3tMaD oZGVQoIUlWRR2Et72d1638Ju5BY3g9c= X-Google-Smtp-Source: APXvYqye8nF4Yi3X9H6uQpEM0Yy5kjC9CAIDeKinMOvSW6LpJeIfPgRg1maOn4QDbn0UbBXweIgKvQ== X-Received: by 2002:a37:a8d7:: with SMTP id r206mr56634772qke.264.1558534365083; Wed, 22 May 2019 07:12:45 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id t58sm13474721qtj.4.2019.05.22.07.12.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 07:12:44 -0700 (PDT) Date: Wed, 22 May 2019 10:12:39 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Fibonaccing CID lengths Message-ID: <20190522141238.GA23472@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 22 May 2019 14:12:48 -0000 Idea: we can keep the one-byte SCIDL/DCIDL field but map the 4-bit parts to a larger range of values. For example, we could map the 16 values to a range of Fibonacci numbers: 0 -> 0 1 -> 1 2 -> 2 3 -> 3 4 -> 5 5 -> 8 6 -> 13 7 -> 21 8 -> 34 9 -> 55 10 -> 89 11 -> 144 12 -> 233 13 -> 377 14 -> 610 15 -> 987 This particular mapping has several profitable properties: - It covers the whole range of values from zero to the practical maximum imposed by the protocol (about 1K). - There is a good selection of small values. - 8 is one of the values, convenient for storage in uint64_t. - Each step up is not too large (double or more) or too small (less than 50% increase). - The mapping can be easily generated: its name says how. - Dmitri. From nobody Wed May 22 09:11: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 6F1F7120099 for ; Wed, 22 May 2019 09:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEfEtgDn_g1z for ; Wed, 22 May 2019 09:11:00 -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 0476112015E for ; Wed, 22 May 2019 09:10:47 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id w37so4601753edw.4 for ; Wed, 22 May 2019 09:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=DSSBXXs78bBY/xnRFQbiZN0L2KXEzKX2Zd0rQvhdoO8=; b=FwByW4am8HIm0+Qqxlbll2BER+dkFh1vDq6lIPX3Jdb/oHUOBxUbJdl1UEcj3yPZwF I0bZz5genVfkZ/up+Ee051pxxf50rQBLcmZ4sYEtHMio4zFKo/x8bmWmzFJCCEunqKwG hGZ1TOjTE3ehAxv7W/BYx+7lMME2tAQJdkqWZfk71VK9MfE/p2Ga6F2EL4VRdJnI73pI aUXotKtTMkIpHuTfVOMfjpPRW3JmJzr4QSwCIv/yqI4WXxMDFW2U20Ilg7cM4/pP8ccU HbbXgfTRAEEX+btn2TL/8NzMAknT4dtf3Gd7zDM92OhBONTPv61NQjRoFNexv5xMCcXk FWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=DSSBXXs78bBY/xnRFQbiZN0L2KXEzKX2Zd0rQvhdoO8=; b=P8yHw81Xjeu++Jb1sV+XSbu3ch6xlNqUeqZUUgA1MffWZ6z/ZpXcRPbzd0SY2zpeUC L9JolwcBoORa5sGeOZ6OLwNlfqQrG7AbqawYcIhvtW3zmo/qIjo3YMuPLct3i6///tVi UcGfb/slNq6PCPTGyi8+b2ZiIMb4L3KhaIezFKfi47TefJhjevIpNfrvEW72nmjmCXbN o3Ehli0KbloynJI5jNEBk/9nTEdPXlz7bcnnO0yPaPb2cnHaCrZ+YWhBRDONWjMS3fpf 9Vnds/pFGpZ7Knm9U91aY3jRAKEn/FbTfjfkre+3Kb5rlpstsshRJ59foMGooHe6FpG9 fQig== X-Gm-Message-State: APjAAAUNsInGtd7jOIl23uxJcmvOpMqwiqoiO7TZvR7+2ktr6BtUEUS1 /Z8uZWvXLLpo5FwyyBfVM+CDjKwLpRW1VBV5klE= X-Google-Smtp-Source: APXvYqy9jcF1WKwuTG3b9oSXX/haib3wv5zpUjiiR4Ab2G/R7daP06rSr6CsVMDppjh1j5qIH75iThh8tmCCAuNbfKg= X-Received: by 2002:a50:a5ed:: with SMTP id b42mr89057115edc.178.1558541446535; Wed, 22 May 2019 09:10:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 May 2019 12:10:44 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20190522141238.GA23472@ubuntu-dmitri> References: <20190522141238.GA23472@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 22 May 2019 12:10:44 -0400 Message-ID: Subject: Re: Fibonaccing CID lengths To: Dmitri Tikhonov , IETF QUIC WG Content-Type: multipart/alternative; boundary="00000000000049e31a05897c35a5" 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, 22 May 2019 16:11:02 -0000 --00000000000049e31a05897c35a5 Content-Type: text/plain; charset="UTF-8" Another benefit: I get to use Fibonachi numbers again :) But, it would arbitrarily consume more bandwidth than necessary, much more than what is saved in a single byte SCIL/DCIL field. If we keep the recenlty proposes 1 byte DCIL and 1 byte SCIL fields we have 0..255 bytes. If we need more without the complexity of varints that are bad for hardware and fast routing in general, we could make all lengths <= 127 single byte multiples, and all above 127 8 byte multiples. That gives you 2K of routing bits and is stil easy to decode in hardware. On 22 May 2019 at 16.13.07, Dmitri Tikhonov (dtikhonov@litespeedtech.com) wrote: Idea: we can keep the one-byte SCIDL/DCIDL field but map the 4-bit parts to a larger range of values. For example, we could map the 16 values to a range of Fibonacci numbers: 0 -> 0 1 -> 1 2 -> 2 3 -> 3 4 -> 5 5 -> 8 6 -> 13 7 -> 21 8 -> 34 9 -> 55 10 -> 89 11 -> 144 12 -> 233 13 -> 377 14 -> 610 15 -> 987 This particular mapping has several profitable properties: - It covers the whole range of values from zero to the practical maximum imposed by the protocol (about 1K). - There is a good selection of small values. - 8 is one of the values, convenient for storage in uint64_t. - Each step up is not too large (double or more) or too small (less than 50% increase). - The mapping can be easily generated: its name says how. - Dmitri. --00000000000049e31a05897c35a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Another benefit: I g= et to use Fibonachi numbers again :)

But, it would arbitrarily consume more bandwidth than neces= sary, much more than what is saved in a single byte SCIL/DCIL field.
<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
If we keep the recenlty p= roposes 1 byte DCIL =C2=A0and 1 byte SCIL fields we have 0..255 bytes.
If we need more w= ithout the complexity of varints that are bad for hardware and fast routing= in general, we could make all lengths <=3D 127 single byte multiples, a= nd all above 127 8 byte multiples. That gives you 2K of routing bits and is= stil easy to decode in hardware.


On 22 May 2019 at = 16.13.07, Dmitri Tikhonov (d= tikhonov@litespeedtech.com) wrote:

Idea: we can keep the one-byte SCI= DL/DCIDL field but map the 4-bit
parts to a larger range of values. For example, we could map the
16 values to a range of Fibonacci numbers:

0 -> 0
1 -> 1
2 -> 2
3 -> 3
4 -> 5
5 -> 8
6 -> 13
7 -> 21
8 -> 34
9 -> 55
10 -> 89
11 -> 144
12 -> 233
13 -> 377
14 -> 610
15 -> 987

This particular mapping has several profitable properties:

- It covers the whole range of values from zero to the
practical maximum imposed by the protocol (about 1K).

- There is a good selection of small values.

- 8 is one of the values, convenient for storage in
uint64_t.

- Each step up is not too large (double or more) or too
small (less than 50% increase).

- The mapping can be easily generated: its name says how.

- Dmitri.

--00000000000049e31a05897c35a5-- From nobody Wed May 22 10:19: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 DA0121201E3 for ; Wed, 22 May 2019 10:19:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 3fFKYJXJZ7wE for ; Wed, 22 May 2019 10:19:55 -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 73B0F1201C5 for ; Wed, 22 May 2019 10:19:55 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hTUu7-0003PQ-2M for quic@ietf.org; Wed, 22 May 2019 19:19:52 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp11.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hTUtz-00031P-F1 for quic@ietf.org; Wed, 22 May 2019 13:19:44 -0400 Received: (qmail 8548 invoked from network); 22 May 2019 17:19:40 -0000 Received: from unknown (HELO [172.16.0.40]) (Authenticated-user:_huitema@huitema.net@[194.168.27.109]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 May 2019 17:19:40 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Dmitri Tikhonov , IETF QUIC WG References: <20190522141238.GA23472@ubuntu-dmitri> 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: Wed, 22 May 2019 10:19:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------05FD530BC4DE2BF1BE1DA939" Content-Language: en-US Subject: Re: Fibonaccing CID lengths 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/gcnlw0fbJ1LThpDP3PaEa+mzHFASpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fuTrZj0FJleUq89vtPcS92c/sevPPdLVvjz7b14RFNIS30ONArWHUY/dwk7 0VyeflhfZdf1siwYNJirk4ABKayR03+K7Ju/qxRhvHDAT5LyR61Qv/sjUDXLdm6w1gNv1euKTrwh UfUHUrPvTkTGu7YwVDQ0hbqcLWUbjgHMZS6COdI/uLAeALf3vLWnw0F/4+fmuTv/CYIzmchrGsA6 CN6O7qbWTdT56xh4Rya20+oBtwahqtg42IMQXC/e/thfmehs05Web8nJyEMtLxwhnYinDFrKlNc7 qNKmpnIY9d8cOJUa+B0z/Xg2ESGxDSOWWoTyIUtK8Miz//+1AD61I8sOcFFSGcngeU5u06zO01Ld 6NjlDHh8k6TTdHl8m1/8O//LcKgaYLn9Y2q9E0HrGD+jIHjY8SMqrVnLB8zxJZ2gRYJc0fBCmpgg jy0UKnyK8P7MO43A0fmmeeY6um8aEqFSOt2OIZNKhGSfBClMxIRKWn/p5S8STECj5CmwQ/HLD+lZ grf8O4fCcE58MPRP63lGgm8BxMqbV4LFlyV46oL0QvpitEUswqzQUazHtjXfNyLWhuGcMiZMw32k gmUMjt0Kf1EFHNqDSgIqYM1jvxNdwN242ySziaAO3+KgxwSs6rxc9aUV1oY4fX3W5eOCNA39+Unl G6+NjwHqPIX/LAm6V+FBIvayVTsIQIBDLijve/q4nmQbNZtkLGXkdb9MK/DUo4eLRFi+U5i8mhS0 Ju9L9gabCWcFl8Cgf6PtjbUPOWcwrYUp/ijFdSqarEyNDJVZ32H2SUbz3g7i+R0UfgKk7Nuw6GQf Xaxj/Hs3Tgs9mpgmbmeTgFKBgc4kmBS2brus/2P6101zTyk48iFA4BWf3Q== 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, 22 May 2019 17:19:58 -0000 This is a multi-part message in MIME format. --------------05FD530BC4DE2BF1BE1DA939 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 5/22/2019 9:10 AM, Mikkel Fahnøe Jørgensen wrote: > Another benefit: I get to use Fibonachi numbers again :) > > But, it would arbitrarily consume more bandwidth than necessary, much > more than what is saved in a single byte SCIL/DCIL field. > > If we keep the recenlty proposes 1 byte DCIL  and 1 byte SCIL fields > we have 0..255 bytes. > If we need more without the complexity of varints that are bad for > hardware and fast routing in general, we could make all lengths <= 127 > single byte multiples, and all above 127 8 byte multiples. That gives > you 2K of routing bits and is stil easy to decode in hardware. > > > On 22 May 2019 at 16.13.07, Dmitri Tikhonov > (dtikhonov@litespeedtech.com ) wrote: > >> Idea: we can keep the one-byte SCIDL/DCIDL field but map the 4-bit >> parts to a larger range of values. For example, we could map the >> 16 values to a range of Fibonacci numbers: >> >> 0 -> 0 >> 1 -> 1 Hey, wait a minute. Doesn't the Fibonacci sequence start by 1,1,2,3? Why do you have a zero there? >> 2 -> 2 >> 3 -> 3 >> 4 -> 5 >> 5 -> 8 >> 6 -> 13 >> 7 -> 21 >> 8 -> 34 >> 9 -> 55 >> 10 -> 89 >> 11 -> 144 >> 12 -> 233 >> 13 -> 377 >> 14 -> 610 >> 15 -> 987 >> >> This particular mapping has several profitable properties: >> >> - It covers the whole range of values from zero to the >> practical maximum imposed by the protocol (about 1K). >> >> - There is a good selection of small values. >> >> - 8 is one of the values, convenient for storage in >> uint64_t. >> >> - Each step up is not too large (double or more) or too >> small (less than 50% increase). >> >> - The mapping can be easily generated: its name says how. Yes, that looks like a proposal that we should seriously consider. -- Christian Huitema --------------05FD530BC4DE2BF1BE1DA939 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/22/2019 9:10 AM, Mikkel Fahnøe Jørgensen wrote:
Another benefit: I get to use Fibonachi numbers again :)

But, it would arbitrarily consume more bandwidth than necessary, much more than what is saved in a single byte SCIL/DCIL field.

If we keep the recenlty proposes 1 byte DCIL  and 1 byte SCIL fields we have 0..255 bytes.
If we need more without the complexity of varints that are bad for hardware and fast routing in general, we could make all lengths <= 127 single byte multiples, and all above 127 8 byte multiples. That gives you 2K of routing bits and is stil easy to decode in hardware.


On 22 May 2019 at 16.13.07, Dmitri Tikhonov (dtikhonov@litespeedtech.com) wrote:

Idea: we can keep the one-byte SCIDL/DCIDL field but map the 4-bit
parts to a larger range of values. For example, we could map the
16 values to a range of Fibonacci numbers:

0 -> 0
1 -> 1

Hey, wait a minute. Doesn't the Fibonacci sequence start by 1,1,2,3? Why do you have a zero there?

2 -> 2
3 -> 3
4 -> 5
5 -> 8
6 -> 13
7 -> 21
8 -> 34
9 -> 55
10 -> 89
11 -> 144
12 -> 233
13 -> 377
14 -> 610
15 -> 987

This particular mapping has several profitable properties:

- It covers the whole range of values from zero to the
practical maximum imposed by the protocol (about 1K).

- There is a good selection of small values.

- 8 is one of the values, convenient for storage in
uint64_t.

- Each step up is not too large (double or more) or too
small (less than 50% increase).

- The mapping can be easily generated: its name says how.

Yes, that looks like a proposal that we should seriously consider.

-- Christian Huitema

--------------05FD530BC4DE2BF1BE1DA939-- From nobody Wed May 22 13:04: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 74040120117 for ; Wed, 22 May 2019 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tSKnxuWdR7pX for ; Wed, 22 May 2019 13:04:18 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C71E212006E for ; Wed, 22 May 2019 13:04:17 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id d10so2349632qko.4 for ; Wed, 22 May 2019 13:04:17 -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=YiE4enjHOA6yJivKw5aU+OcnxvoxNCq82IFnEiK4C2A=; b=1fx447C2LKptm1U6gqO9KWnAQSVGcRXptM1/Af/rJjsUktqx+gujLPcxZ54kOi0pV9 vDn8Ahm0LrMzuInX/cpkeQt1cycgxwvGQu7+gcmbVLF8C/jOrB0QvN/T90n5sSByhi7t /KcX8KkcKSq2OZjhfKWSpaHAuJtMKSb49Vu9JDZOvQ7mwBvQACFjh2nIwsCh4xeALcpO /67fCtvJ99QY6ZSGGiwIIpu5A4T056MKP+KJA2xBjytvFG9Mf+7DrC2CrAlAXMPmJV1d vOa9xlgNUhDX2fLc6kWfF1tTmmZD08OCTz0lwsbJnhAZX2/JdAjCpI3MrF2MoOQc+A1C tm9w== 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=YiE4enjHOA6yJivKw5aU+OcnxvoxNCq82IFnEiK4C2A=; b=WCO7XhOeg4sLpXVA1EMiXrWGHDz4KnQ2aD5WmUWPnQC96S/E1sY8YVyeYJCTDyxaQu dzwvtU2mmA6y/LMwcnYLd1GMNesrhX251sJFp3CfT6cLjIExisdR7iBPzC1MdyxyJi/a cdkvHmRKjbcgK3+aeI3giFOcRfN5oN1KD8d9mR46mLkZ00kUaRNkTQYwWCxRqgPxJNvh ubqFShKTNd3SchX4rtWM3TuaryBfNuGksaknvLeaTUk8PjZ8WSuNU6b53Af7CuOGYcAd igj+6QIA8T+hWftXe8zKMvLa2+p3QWng6rg4rcRcJasHK8RkmEA2T6HjNa3llX58BcUF XbBw== X-Gm-Message-State: APjAAAXLk62xehHsYNzCO9GhJWTUONv8shB3Rz+nDP13YCw6RiuPtmYT 4h0lhfB68mbWvVk9H6qe9JWwHg== X-Google-Smtp-Source: APXvYqzfGw7lqZi5q8NPaTNQnv9heEeBnyXg4+EItN4guKjyWIn9lebJxxGtD+i/aKXTkCrH7rmpvQ== X-Received: by 2002:a37:5945:: with SMTP id n66mr69295718qkb.295.1558555456995; Wed, 22 May 2019 13:04:16 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id k53sm12559473qtb.65.2019.05.22.13.04.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 13:04:16 -0700 (PDT) Date: Wed, 22 May 2019 16:04:07 -0400 From: Dmitri Tikhonov To: Christian Huitema Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG Subject: Re: Fibonaccing CID lengths Message-ID: <20190522200406.GA28789@ubuntu-dmitri> Mail-Followup-To: Christian Huitema , Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG References: <20190522141238.GA23472@ubuntu-dmitri> 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: Wed, 22 May 2019 20:04:19 -0000 On Wed, May 22, 2019 at 10:19:38AM -0700, Christian Huitema wrote: > Yes, that looks like a proposal that we should seriously consider. While the example is lighthearted, the proposal is serious: that is, remap 0 - 15 values of the nybble to a different set. Do we need to represent every intermediate number between 0 and 48 (the maximum of the current PR)? What if instead we do the following: 0 -> 0 1 -> 1 2 -> 2 3 -> 3 4 -> 4 5 -> 6 6 -> 8 7 -> 12 8 -> 16 9 -> 20 10 -> 24 11 -> 28 12 -> 32 13 -> 40 14 -> 48 15 -> 64 This is as valid an approach as encoding the length in 8 bits and having to deal with invalid values or using a varint and having to deal with even more invalid values. - Dmitri. From nobody Wed May 22 20:37:10 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 8E457120147 for ; Wed, 22 May 2019 20:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZFLaTnK9KQj for ; Wed, 22 May 2019 20:37:08 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F611120025 for ; Wed, 22 May 2019 20:37:07 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id q16so4032322ljj.8 for ; Wed, 22 May 2019 20:37:07 -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 :content-transfer-encoding; bh=pkvKZLyC9b53Mag0i/YMKd9pozAX0pxeMJTfxPIXmb8=; b=jo+ljWDV68QsgXtdH6eNCI+HAnWXyacUsBm7RS/S0WTX+OoDlOo+12sD5k1e2FnRR8 EgX2Lw11wqGZoO2qXwSkrJM2vQzYr09q1ENCSomqxC0dbyQ9jJvL28mbWICbPxuLe6vF AUNfAhKU5dOqMYOx0rf09P953K0r7MymUWSx5kdRNdQnu5aK7vhFgHpAZtRFYmbPwjwv uVdftNwb8JKdlFbqLIoi8bIo7Z9yi2mXDYK6IIm9+n6zfyRPpqWllHycy1M+qcaEyZtX IBteGERe2ZoAPSs0ztGBSbKtj/CDSjrPr0ANOa0d+XYqytNgDa+XMWHNUfNS3rkHd+v3 9fdA== 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:content-transfer-encoding; bh=pkvKZLyC9b53Mag0i/YMKd9pozAX0pxeMJTfxPIXmb8=; b=CxU+J/6pGLLd1jSp7OdVpLuQP9cgLICSjOZxlIPOX4ko2pBuVbkz1O0R5CKoNf65Om Wh5kFo74/riHyKdU2NIJXI6aYpynVuJEHML6Hi+u8qUXUa9JhSsa4bZrPvmurnkOqx1F BO0sm5JV0c2j40s9IpGKTydhlClFAgdgOJAtO3WfIMkIjEFpILx/6HJiOcoUwmosaW5E f8Zg63bE9Q5ZtHn/eeCiGhr67kyXbBgOe5Jztyj5uWd4b2f5OQwitNoP24dY/vqWeyI9 7E46Yy1jLhcr8qsYgsIAZTxNgtS4U6N65zyvESFH8IyqdafDOoKT3r1T0uZbwC2IqAqd QM0g== X-Gm-Message-State: APjAAAUNkmhYI7mDcl0c68KulqYPAZ9qbD77qv8Evt8KJ1H4J1IE/kmD 38cnSRe4xkGBMql4LHAvUEPsfcCT3TbdmtYzKr8= X-Google-Smtp-Source: APXvYqxBRAC7csDKBPSKIsIIAf/7xGxRT340vjUebecmL3KuV4vq6EmaG5aRKiqvdX5gBvPtIzO4quMS9vyLM9bqLz8= X-Received: by 2002:a2e:298d:: with SMTP id p13mr46431520ljp.64.1558582625864; Wed, 22 May 2019 20:37:05 -0700 (PDT) MIME-Version: 1.0 References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> In-Reply-To: <20190522200406.GA28789@ubuntu-dmitri> From: Kazuho Oku Date: Thu, 23 May 2019 04:36:54 +0100 Message-ID: Subject: Re: Fibonaccing CID lengths To: Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 23 May 2019 03:37:09 -0000 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov : > > On Wed, May 22, 2019 at 10:19:38AM -0700, Christian Huitema wrote: > > Yes, that looks like a proposal that we should seriously consider. > > While the example is lighthearted, the proposal is serious: that is, > remap 0 - 15 values of the nybble to a different set. Do we need to > represent every intermediate number between 0 and 48 (the maximum of > the current PR)? The question is what you gain by compressing the length to 4 bits. I'd argue that the downside of compression is that endpoints would be required to use a CID that is longer than necessary. For example, if we are to allow only CID length of even-number bytes, there would be in average one byte (8-bit) overhead per CID. That dwarfs the benefit of saving 4-bit in the length of the CIDL field. While I think using a 4-bit CIDL field could be beneficial for avoiding ossification, I think I might agree with Martin Duke that CIDL is currently an invariant that we are happy to accept ossification. So, what's the benefit? > > What if instead we do the following: > > 0 -> 0 > 1 -> 1 > 2 -> 2 > 3 -> 3 > 4 -> 4 > 5 -> 6 > 6 -> 8 > 7 -> 12 > 8 -> 16 > 9 -> 20 > 10 -> 24 > 11 -> 28 > 12 -> 32 > 13 -> 40 > 14 -> 48 > 15 -> 64 > > This is as valid an approach as encoding the length in 8 bits and > having to deal with invalid values or using a varint and having > to deal with even more invalid values. > > - Dmitri. > --=20 Kazuho Oku From nobody Wed May 22 22:08: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 6A4EE1200F7 for ; Wed, 22 May 2019 22:08:02 -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 (1024-bit key) header.d=fb.com header.b=Wuiw7O+7; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=E0T1n9k8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJIRH0cFrI4k for ; Wed, 22 May 2019 22:08:00 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 AEA5F120073 for ; Wed, 22 May 2019 22:08:00 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4N4wrfO014821; Wed, 22 May 2019 22:07:52 -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=L+7+nvJrwiZpwCjo0lq0lz6ybTFWZUrnYmVTZnFfDpY=; b=Wuiw7O+7nfnDAfatur1EteeXV+j2gX1pYLLjcvIv+Yx6ch1wvRQQjwhOoKRNfaoBeHAq cD6jjujGQrW6M43f3rJV334ZXa7fWzXn4r5c5qQY1jBKoxdocM9L+8Ln8vOtVpQSkXps bGvDUyQl/2UpFrGFO2A8wHJKEOWaYuEZ+/k= Received: from mail.thefacebook.com (mailout.thefacebook.com [199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2snabk2551-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 May 2019 22:07:52 -0700 Received: from prn-mbx05.TheFacebook.com (2620:10d:c081:6::19) by prn-hub06.TheFacebook.com (2620:10d:c081:35::130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 22 May 2019 22:07:50 -0700 Received: from prn-hub01.TheFacebook.com (2620:10d:c081:35::125) by prn-mbx05.TheFacebook.com (2620:10d:c081:6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Wed, 22 May 2019 22:07:50 -0700 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5 via Frontend Transport; Wed, 22 May 2019 22:07:50 -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=L+7+nvJrwiZpwCjo0lq0lz6ybTFWZUrnYmVTZnFfDpY=; b=E0T1n9k8WQjPObM8K/JGZ8Q+NxOLxwxReWZAPHNah9wdiCTiiKP+sU7EFhJQ/oWqCkzYQZeQpPnKZy0SyLZwgGWel0/EPmZfsBFuBVgSAgo59N0FnIBPqbQxJE0t8u92W1lEQ29nfdzzfm97tpRx6xIZ5KgBRKYOjlz7+AIyh8U= Received: from CY4PR15MB1542.namprd15.prod.outlook.com (10.172.160.9) by CY4PR15MB1832.namprd15.prod.outlook.com (10.174.54.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.17; Thu, 23 May 2019 05:07:48 +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.1922.016; Thu, 23 May 2019 05:07:48 +0000 From: Roberto Peon To: Kazuho Oku , Christian Huitema , =?ks_c_5601-1987?B?TWlra2VsIEZhaG6pqmUgSqmqcmdlbnNlbg==?= , IETF QUIC WG Subject: Re: Fibonaccing CID lengths Thread-Topic: Fibonaccing CID lengths Thread-Index: AQHVEKiAeOO8WaR5Lk65vFlegNPyYaZ3UIAAgAATQACAAC31gIAAfoEAgAAYYqw= Date: Thu, 23 May 2019 05:07:48 +0000 Message-ID: References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.98.65.155] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d62d7b01-a89d-4530-7609-08d6df3c9987 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR15MB1832; x-ms-traffictypediagnostic: CY4PR15MB1832: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 00462943DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(136003)(376002)(346002)(189003)(199004)(99286004)(7696005)(110136005)(5660300002)(561944003)(25786009)(3846002)(6116002)(76176011)(316002)(86362001)(486006)(256004)(68736007)(52536014)(14454004)(3480700005)(66574012)(476003)(478600001)(71200400001)(71190400001)(9686003)(186003)(102836004)(54896002)(66946007)(73956011)(6506007)(53546011)(6246003)(26005)(33656002)(53936002)(7116003)(7736002)(446003)(2906002)(66446008)(11346002)(66556008)(66476007)(64756008)(91956017)(74316002)(76116006)(66066001)(229853002)(6436002)(55016002)(8676002)(8936002)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1832; 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: P77S5YkKhceE4IR0dTtQfGFshCmTHDbQzV4yzpIfwd9IJYxDbwyuM67AABJppYCtjBT3m+bRn6BOTOAaK4/Cwq5OMO2vUdWzCvXpd+IHV5A5Q9ieN+tzYSkbZdJLnPxv7nrN5vvePY6r9Vu7dpk28ylTfkZQIIiqGtcThCav98vxCF1EU79PjR0mdRLecUNJo9xf10hFBiK+j02PvT9dqV5oxYI7lg7N4JNJvBNkmpf/lsP0u2j/fXqAnW4VBs7Lbl7uDRvB3XIiGCRXA417XiKLn9D5I3BB2nEHvEPptSq90UC6bbXcrbe1swGgkVxWud/5g2lm+JI/4au+T39TjfcXad9ewdpDNmh7OKGn8/0sik50P1gs1FgIbwxhx+CWHWs3YBwTGgutv1gJvt8sYVLRHogoKTAD9e2zYzXTw3E= Content-Type: multipart/alternative; boundary="_000_CY4PR15MB15423897359517403F682F6ACD010CY4PR15MB1542namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d62d7b01-a89d-4530-7609-08d6df3c9987 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 05:07:48.5886 (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-Transport-CrossTenantHeadersStamped: CY4PR15MB1832 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-23_05:, , 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=599 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905230035 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: Thu, 23 May 2019 05:08:02 -0000 --_000_CY4PR15MB15423897359517403F682F6ACD010CY4PR15MB1542namp_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSdkIGJlIGZpYmJpbmcgaWYgSSBzYWlkIEkgbGlrZWQgdGhlIGVuY29kaW5nIHByb3Bvc2FsLg0K QSBieXRlIHNlZW1zIHRvIG9mZmVyIGVub3VnaCByYW5nZSBvZiBwb3NzaWJpbGl0aWVzIHRoYXQg d2UgYXJlIHdhbnRpbmcgdG8gY29uc3RyYWluIHRoZW0gcmVhZHkuDQoNCkhvdyBhYm91dCB3ZSBz aW1wbHkgYXNzZXJ0IGZvciBhbGwgYml0LXBhdHRlcm5zIHdobyByZXByZXNlbnQgdmFsdWVzIDw9 IHRoZSBpbnRlbmRlZCBtYXgsIHRoZXkgbWVhbiB3aGF0IHlvdSdkIG5haXZlbHkgZXhwZWN0Pw0K VGhpcyBkb2Vzbid0IGltcGx5IGEgbGluZWFyIG1hcHBpbmcgb3IgYW55IG1hcHBpbmcgZm9yIHZh bHVlcyBpbiBleGNlc3Mgb2YgbWF4DQotPVINCg0KDQoNCkZyb206IEthenVobyBPa3UNClNlbnQ6 IFRodXJzZGF5LCBNYXkgMjMsIDQ6MzcgQU0NClN1YmplY3Q6IFJlOiBGaWJvbmFjY2luZyBDSUQg bGVuZ3Rocw0KVG86IENocmlzdGlhbiBIdWl0ZW1hLCBNaWtrZWwgRmFobqmqZSBKqapyZ2Vuc2Vu LCBJRVRGIFFVSUMgV0cNCg0KDQoyMDE50rQ16sUyMuztKOKpKSAyMTowNCBEbWl0cmkgVGlraG9u b3YgPGR0aWtob25vdkBsaXRlc3BlZWR0ZWNoLmNvbT46DQo+DQo+IE9uIFdlZCwgTWF5IDIyLCAy MDE5IGF0IDEwOjE5OjM4QU0gLTA3MDAsIENocmlzdGlhbiBIdWl0ZW1hIHdyb3RlOg0KPiA+IFll cywgdGhhdCBsb29rcyBsaWtlIGEgcHJvcG9zYWwgdGhhdCB3ZSBzaG91bGQgc2VyaW91c2x5IGNv bnNpZGVyLg0KPg0KPiBXaGlsZSB0aGUgZXhhbXBsZSBpcyBsaWdodGhlYXJ0ZWQsIHRoZSBwcm9w b3NhbCBpcyBzZXJpb3VzOiB0aGF0IGlzLA0KPiByZW1hcCAwIC0gMTUgdmFsdWVzIG9mIHRoZSBu eWJibGUgdG8gYSBkaWZmZXJlbnQgc2V0LiAgRG8gd2UgbmVlZCB0bw0KPiByZXByZXNlbnQgZXZl cnkgaW50ZXJtZWRpYXRlIG51bWJlciBiZXR3ZWVuIDAgYW5kIDQ4ICh0aGUgbWF4aW11bSBvZg0K PiB0aGUgY3VycmVudCBQUik/DQoNClRoZSBxdWVzdGlvbiBpcyB3aGF0IHlvdSBnYWluIGJ5IGNv bXByZXNzaW5nIHRoZSBsZW5ndGggdG8gNCBiaXRzLg0KDQpJJ2QgYXJndWUgdGhhdCB0aGUgZG93 bnNpZGUgb2YgY29tcHJlc3Npb24gaXMgdGhhdCBlbmRwb2ludHMgd291bGQgYmUNCnJlcXVpcmVk IHRvIHVzZSBhIENJRCB0aGF0IGlzIGxvbmdlciB0aGFuIG5lY2Vzc2FyeS4gRm9yIGV4YW1wbGUs IGlmDQp3ZSBhcmUgdG8gYWxsb3cgb25seSBDSUQgbGVuZ3RoIG9mIGV2ZW4tbnVtYmVyIGJ5dGVz LCB0aGVyZSB3b3VsZCBiZQ0KaW4gYXZlcmFnZSBvbmUgYnl0ZSAoOC1iaXQpIG92ZXJoZWFkIHBl ciBDSUQuIFRoYXQgZHdhcmZzIHRoZSBiZW5lZml0DQpvZiBzYXZpbmcgNC1iaXQgaW4gdGhlIGxl bmd0aCBvZiB0aGUgQ0lETCBmaWVsZC4NCg0KV2hpbGUgSSB0aGluayB1c2luZyBhIDQtYml0IENJ REwgZmllbGQgY291bGQgYmUgYmVuZWZpY2lhbCBmb3INCmF2b2lkaW5nIG9zc2lmaWNhdGlvbiwg SSB0aGluayBJIG1pZ2h0IGFncmVlIHdpdGggTWFydGluIER1a2UgdGhhdA0KQ0lETCBpcyBjdXJy ZW50bHkgYW4gaW52YXJpYW50IHRoYXQgd2UgYXJlIGhhcHB5IHRvIGFjY2VwdA0Kb3NzaWZpY2F0 aW9uLg0KDQpTbywgd2hhdCdzIHRoZSBiZW5lZml0Pw0KDQo+DQo+IFdoYXQgaWYgaW5zdGVhZCB3 ZSBkbyB0aGUgZm9sbG93aW5nOg0KPg0KPiAgICAgIDAgLT4gMA0KPiAgICAgIDEgLT4gMQ0KPiAg ICAgIDIgLT4gMg0KPiAgICAgIDMgLT4gMw0KPiAgICAgIDQgLT4gNA0KPiAgICAgIDUgLT4gNg0K PiAgICAgIDYgLT4gOA0KPiAgICAgIDcgLT4gMTINCj4gICAgICA4IC0+IDE2DQo+ICAgICAgOSAt PiAyMA0KPiAgICAgIDEwIC0+IDI0DQo+ICAgICAgMTEgLT4gMjgNCj4gICAgICAxMiAtPiAzMg0K PiAgICAgIDEzIC0+IDQwDQo+ICAgICAgMTQgLT4gNDgNCj4gICAgICAxNSAtPiA2NA0KPg0KPiBU aGlzIGlzIGFzIHZhbGlkIGFuIGFwcHJvYWNoIGFzIGVuY29kaW5nIHRoZSBsZW5ndGggaW4gOCBi aXRzIGFuZA0KPiBoYXZpbmcgdG8gZGVhbCB3aXRoIGludmFsaWQgdmFsdWVzIG9yIHVzaW5nIGEg dmFyaW50IGFuZCBoYXZpbmcNCj4gdG8gZGVhbCB3aXRoIGV2ZW4gbW9yZSBpbnZhbGlkIHZhbHVl cy4NCj4NCj4gICAtIERtaXRyaS4NCj4NCg0KDQotLQ0KS2F6dWhvIE9rdQ0KDQoNCg0K --_000_CY4PR15MB15423897359517403F682F6ACD010CY4PR15MB1542namp_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
I'd be fibbing if I said I liked the encoding proposal.
A byte seems to offer enough range of possibilities that we are wanting to = constrain them ready.

How about we simply assert for all bit-patterns who represent values <= =3D the intended max, they mean what you'd naively expect?
This doesn't imply a linear mapping or any mapping for values in excess of = max
-=3DR



From: Kazuho Oku
Sent: Thursday, May 23, 4:37 AM
Subject: Re: Fibonaccing CID lengths
To: Christian Huitema, Mikkel Fahn=A9=AAe J=A9=AArgensen, IETF QUIC WG


2019=D2=B45=EA=C522=EC=ED(=E2=A9) 21:04 Dmitri Tikhonov <dtikhonov@lites= peedtech.com>:
>
> On Wed, May 22, 2019 at 10:19:38AM -0700, Christian Huitema wrote:
> > Yes, that looks like a proposal that we should seriously consider= .
>
> While the example is lighthearted, the proposal is serious: that is,
> remap 0 - 15 values of the nybble to a different set.  Do we need= to
> represent every intermediate number between 0 and 48 (the maximum of
> the current PR)?

The question is what you gain by compressing the length to 4 bits.

I'd argue that the downside of compression is that endpoints would be
required to use a CID that is longer than necessary. For example, if
we are to allow only CID length of even-number bytes, there would be
in average one byte (8-bit) overhead per CID. That dwarfs the benefit
of saving 4-bit in the length of the CIDL field.

While I think using a 4-bit CIDL field could be beneficial for
avoiding ossification, I think I might agree with Martin Duke that
CIDL is currently an invariant that we are happy to accept
ossification.

So, what's the benefit?

>
> What if instead we do the following:
>
>      0 -> 0
>      1 -> 1
>      2 -> 2
>      3 -> 3
>      4 -> 4
>      5 -> 6
>      6 -> 8
>      7 -> 12
>      8 -> 16
>      9 -> 20
>      10 -> 24
>      11 -> 28
>      12 -> 32
>      13 -> 40
>      14 -> 48
>      15 -> 64
>
> This is as valid an approach as encoding the length in 8 bits and
> having to deal with invalid values or using a varint and having
> to deal with even more invalid values.
>
>   - Dmitri.
>


--
Kazuho Oku



--_000_CY4PR15MB15423897359517403F682F6ACD010CY4PR15MB1542namp_-- From nobody Thu May 23 01:21:39 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 4ECA612016B for ; Thu, 23 May 2019 01:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jdlj7_bUs5EM for ; Thu, 23 May 2019 01:21:36 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 AD1A212002F for ; Thu, 23 May 2019 01:21:36 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id i26so5698234qtr.10 for ; Thu, 23 May 2019 01:21:36 -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:content-transfer-encoding :in-reply-to:user-agent; bh=amaTts0EeLB5ZOVBE1CFw6wUn4/hXZ3iUSN8L+1ef/M=; b=HeQf/T4NC0YAceoidV9aOIk95B8VQlc+h/8FOwtV4GPPX2aqylx3hfDvWG1wB1yzC2 BjMJEhw3S72Bw8FKGj23FzBwqYyk6+HkbMZg2jKl1FIcCDE4ie1z9Q0TjAdoXnHFr9ZA 3nRHokr4zqygG5XFie8IFyJiZqb8D/V+l+H+Wz6C06uZrNo3IXYbMZC+HlYbwQfq5AWE 5bCJIG8fpvGM2smvcvPDQqvnhVKW1+U9x6BZ8cYMUmtFO1U8etazs/KqcDGYAs88LKBL e+BVPEV4uNnNYdZKNRfPCTfuZf8EZQjvshisW94IVkmkl6058ZC0meaQ/+SUBO1QaZhW uZ/Q== 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 :content-transfer-encoding:in-reply-to:user-agent; bh=amaTts0EeLB5ZOVBE1CFw6wUn4/hXZ3iUSN8L+1ef/M=; b=amXAQu364XSKfBdfZ810tBdw2T1j7mQASeOe2IjFUzvd2No6kBItF8fJzwn6Ag7z1e eg260tyN9bFJHLWGheoYMk7tnxhpIIvNPBl2h2kSfGBpmhxUAPoz40E4XM9Bae1l/Zee JOF8qLOP8BAMku6J7TNOlK/TI4y5zDuok1sAilX52h2xzVV9/R0vjeg9MpjdUEhJJovq p0UyfPcOHIEkIexIqumncg4xgVtop88Diazuodwq3aXSUmTdgTb9yjaFJi8Ki7xROTW/ 4jXbPW21+UlKThNS59/8XjG7u1PwOvWZoNtjySQesKZ9MIrxcKFqZSNFJEFqKpy5PRLU 28Gg== X-Gm-Message-State: APjAAAVG937E5aTU2ZkMchNAJ3ojCDaMwbd/6Qr0FAGIKbTbWVbC+DCh XIop8EdyxMMHoeRMYqlOFp+XRA== X-Google-Smtp-Source: APXvYqxx9wkX/eZuUYFgZcafBHQ9yfnOMcYpk3tQ4zMmAK3Kt7npP2eZEP/zD8ozs5ont4VLVheafQ== X-Received: by 2002:ac8:182e:: with SMTP id q43mr80849789qtj.128.1558599695911; Thu, 23 May 2019 01:21:35 -0700 (PDT) Received: from ubuntu-dmitri (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id g124sm475068qkf.55.2019.05.23.01.21.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 01:21:35 -0700 (PDT) Date: Thu, 23 May 2019 04:21:30 -0400 From: Dmitri Tikhonov To: Kazuho Oku Cc: Christian Huitema , Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG Subject: Re: Fibonaccing CID lengths Message-ID: <20190523082129.GA6712@ubuntu-dmitri> Mail-Followup-To: Kazuho Oku , Christian Huitema , Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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, 23 May 2019 08:21:38 -0000 On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote: > 2019年5月22日(水) 21:04 Dmitri Tikhonov : > > While the example is lighthearted, the proposal is serious: that is, > > remap 0 - 15 values of the nybble to a different set. Do we need to > > represent every intermediate number between 0 and 48 (the maximum of > > the current PR)? > > The question is what you gain by compressing the length to 4 bits. > ----- 8< --- 8< --- 8< --- > > So, what's the benefit? Smaller change to the drafts -- and existing code. - Dmitri. From nobody Thu May 23 08:08: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 ABCEB1200A2 for ; Thu, 23 May 2019 08:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mxRg32yEGzZ for ; Thu, 23 May 2019 08:08:30 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22B812004A for ; Thu, 23 May 2019 08:08:29 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id z5so5797387lji.10 for ; Thu, 23 May 2019 08:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5HArPIOzzW2F1iVRtYqQQUYktXBJLRIbWJt5rjXTL/4=; b=HAa5Fvhd0EnsLHFtW8ftrWT2K14rYhGCJerMiJlH5jMRS4yMbKxafZycqUZwJtAgfi PWRB8fpm78/eRsaHqx3OAiG2qhJJloKLWggRwXB6yU2vQJwF+MclUtP47X3+Qdcf4DNq mlBZ8fdZHhZqS0qhqnlD0eG+UMnQp/F7mk7hhjhy8+/kxJEwp/4Wd24XEnFiwE70bjj7 s1JZs2L/4M4Syqr0XB3HSVM/xwfX779MgSVLmUvPZd6Y9hWpjp3YBqaFfflMKKJc2YRf Hu92s54LvzigojxyTOP9PojHf6N6665+vhjUz0Ytk4UnprHuJ4CDBqB/TiXaFBF7gF6w n8VQ== 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=5HArPIOzzW2F1iVRtYqQQUYktXBJLRIbWJt5rjXTL/4=; b=DgcczLrrXrS+xE6gyFuntthItksUrgpd5pwTThrdE8pv8NlxR7R7d8OB5hLfDU6kLb K32yArOAOko2pnvcWLjAeEbCyVBbrzPVAGOCWEHLrfO0m/o4JwTLAI6wjasvxfEPOdNr rmYIL41BiolfftKETV6M73NqM/NxmoshInbTlVzXxNdJzUQzpDaeOaHjJpbKMHT/rKZg VnXcDCxRtkZ35SSnVXeFs7bWXOVNVVtRgjea72IdotNlhJvqynlmumVEx5F1o9O/piqz 17/nduKV6zPu1kYqxRdD5HS3nfMq4bSzsiBK7vvRWq6yFRXwFj6fnYnb1UVkJJd9fW8C ovJA== X-Gm-Message-State: APjAAAXXXnCNhv1e9MdGA+xvTcdXud62wdEDQNxHGvJQVfv0LD7HhZeM GZj8kwrvmms3ouyaaGauIyIVl9e5R4iCeHtMnik= X-Google-Smtp-Source: APXvYqw/E4GLTVig1qwvZ8BAC+i4389dQOjOkzA5rOD8Uk1pmYK1BKNXM0TaVMXw8Ulz8YuJWqB46+K3XnAfM6PEqI0= X-Received: by 2002:a2e:9ac8:: with SMTP id p8mr39529381ljj.154.1558624107763; Thu, 23 May 2019 08:08:27 -0700 (PDT) MIME-Version: 1.0 References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> <20190523082129.GA6712@ubuntu-dmitri> In-Reply-To: <20190523082129.GA6712@ubuntu-dmitri> From: David Schinazi Date: Thu, 23 May 2019 16:08:16 +0100 Message-ID: Subject: Re: Fibonaccing CID lengths To: Kazuho Oku , Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000481e1605898f741b" 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, 23 May 2019 15:08:33 -0000 --000000000000481e1605898f741b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This encoding would be harder to deploy on our servers than having two 8-bit lengths. The only benefit of this is saving 8 bits on long headers, and that's not worth the complexity. On Thu, May 23, 2019 at 9:21 AM Dmitri Tikhonov wrote: > On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote: > > 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov : > > > While the example is lighthearted, the proposal is serious: that is, > > > remap 0 - 15 values of the nybble to a different set. Do we need to > > > represent every intermediate number between 0 and 48 (the maximum of > > > the current PR)? > > > > The question is what you gain by compressing the length to 4 bits. > > > ----- 8< --- 8< --- 8< --- > > > > So, what's the benefit? > > Smaller change to the drafts -- and existing code. > > - Dmitri. > > --000000000000481e1605898f741b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This encoding would be harder to deploy on our servers tha= n having two 8-bit lengths. The only benefit of this is saving 8 bits on lo= ng headers, and that's not worth the complexity.

On Thu, May 23, 2019 at= 9:21 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuh= o Oku wrote:
> 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov &l= t;dtikhono= v@litespeedtech.com>:
> > While the example is lighthearted, the proposal is serious: that = is,
> > remap 0 - 15 values of the nybble to a different set.=C2=A0 Do we= need to
> > represent every intermediate number between 0 and 48 (the maximum= of
> > the current PR)?
>
> The question is what you gain by compressing the length to 4 bits.
>
----- 8< --- 8< --- 8< ---
>
> So, what's the benefit?

Smaller change to the drafts -- and existing code.

=C2=A0 - Dmitri.

--000000000000481e1605898f741b-- From nobody Thu May 23 08:14: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 DD53A1200A2 for ; Thu, 23 May 2019 08:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcDrs9Nw47Il for ; Thu, 23 May 2019 08:14: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 D39041200FC for ; Thu, 23 May 2019 08:13:52 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id j24so5848733ljg.1 for ; Thu, 23 May 2019 08:13: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=KI4VDQBPQYnKP6s5Iv65uj/YdasCLlylqxz7zKTXUdc=; b=MLjsd2N04aURI+UYWhuOgIEpVTDrOVuAcEBD7VRXndbOVIW3Pu/XqqIxkW5UKzSr9C PG87vvz1T22YVWqka5x2/XrIAEVXQvIw/mx1T7ezOdEx4RW6mNuNORMNEUm125kjKcj5 c684lFHCGZ2f+5CNuHCPv56rY6z3x7VviMwNuCKsat6oi8KHGN5FOu35uyIPtjD+IaeP tJ2sibDBWezQMjyYnJ9j4OWtGNCKbxTT2msk09MKRcz1YL/rSRAZYznwH/OfreI9/rhQ ua4o0o7Kcev1W3yI8Gvwi3T1vZoEeYUyLdVJaY+CwPFNGzZHH+ZVZrDiwGgmIRzxSl75 efbQ== 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=KI4VDQBPQYnKP6s5Iv65uj/YdasCLlylqxz7zKTXUdc=; b=lNu1to543D26H8xQ3SV/C3KlVFTdvDWI1qY6FbAl90g9RMbyeOWNU4vYAOVyn05cUr jLhiVU5GSdaamufz351hGluT7a10QkMLOqQ6/IfpkNMeFTu98dokyUtnf0D/dGiGOMax UYzlV3OhH2oIrZ9dwx2U8coWw5W0JJ0DpA8K8sfnPy+cu+keMHUnNkP3+Ei7c8805tuL tDoRQvDxW4v/iaKhX0tTHKtx7XPbyvA0ypv4WAj0OH4BB1p8g1gPK7SWnzufv5rU9QEK dvmhrSr/ZV0SBpr6lce0bUx/rW/AtARX3Oal3BPfE0XtfdT3I65hT6r0pEmjquPk8h6H zdAw== X-Gm-Message-State: APjAAAW4bsC+pCN7V/cyWzZA49GrP+GQVBwRgLOvkgnawr0+d0tSr90f dB/XGxRb6pw1czVvIOteWjbjooPsPZqfCaroB0A= X-Google-Smtp-Source: APXvYqy3O1bjUENvGMksXhfoPy/cwlQ0DjTVxKXb9koKi8u+BDQobDGy8ZZq9ArfBGCCW9Ik1tmDpCTjDkH5gUrkQ1k= X-Received: by 2002:a2e:960e:: with SMTP id v14mr25994222ljh.31.1558624430958; Thu, 23 May 2019 08:13:50 -0700 (PDT) MIME-Version: 1.0 References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> <20190523082129.GA6712@ubuntu-dmitri> In-Reply-To: From: Marten Seemann Date: Thu, 23 May 2019 16:13:39 +0100 Message-ID: Subject: Re: Fibonaccing CID lengths To: David Schinazi Cc: Kazuho Oku , Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000008babd105898f87eb" 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, 23 May 2019 15:14:34 -0000 --0000000000008babd105898f87eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Using an 8-bit encoding would also prevent ossification of the first two bits of each connection ID length field. These bits would always be 0 (in QUIC v1), since connection ID lengths above 48 can never occur. On Thu, May 23, 2019 at 4:08 PM David Schinazi wrote: > This encoding would be harder to deploy on our servers than having two > 8-bit lengths. The only benefit of this is saving 8 bits on long headers, > and that's not worth the complexity. > > On Thu, May 23, 2019 at 9:21 AM Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > >> On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote: >> > 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov : >> > > While the example is lighthearted, the proposal is serious: that is, >> > > remap 0 - 15 values of the nybble to a different set. Do we need to >> > > represent every intermediate number between 0 and 48 (the maximum of >> > > the current PR)? >> > >> > The question is what you gain by compressing the length to 4 bits. >> > >> ----- 8< --- 8< --- 8< --- >> > >> > So, what's the benefit? >> >> Smaller change to the drafts -- and existing code. >> >> - Dmitri. >> >> --0000000000008babd105898f87eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Using an 8-bit encoding would also prevent ossification of= the first two bits of each connection ID length field. These bits would al= ways be 0 (in QUIC v1), since connection ID lengths above 48 can never occu= r.

On Thu, May 23, 2019 at 4:08 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
This encodin= g would be harder to deploy on our servers than having two 8-bit lengths. T= he only benefit of this is saving 8 bits on long headers, and that's no= t worth the complexity.

On Thu, May 23, 2019 at 9:21 AM Dmitri Tikhonov <= dtikhonov@= litespeedtech.com> wrote:
On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote= :
> 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov &l= t;dtikhono= v@litespeedtech.com>:
> > While the example is lighthearted, the proposal is serious: that = is,
> > remap 0 - 15 values of the nybble to a different set.=C2=A0 Do we= need to
> > represent every intermediate number between 0 and 48 (the maximum= of
> > the current PR)?
>
> The question is what you gain by compressing the length to 4 bits.
>
----- 8< --- 8< --- 8< ---
>
> So, what's the benefit?

Smaller change to the drafts -- and existing code.

=C2=A0 - Dmitri.

--0000000000008babd105898f87eb-- From nobody Thu May 23 08:19: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 3CF8C120130 for ; Thu, 23 May 2019 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id powNmwqgrn9g for ; Thu, 23 May 2019 08:18:51 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 6FA87120126 for ; Thu, 23 May 2019 08:18:03 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id w33so6382640edb.10 for ; Thu, 23 May 2019 08:18:03 -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=7KTB47IGxxQKgjkcuoIQmJWz1YxEemKbHvN4QOJhCv4=; b=n3qA0PusaBBlqyItApa0hXbCx0xWyRQKPXwNblOhR4yhEJaL+Nq5k8W1Ojbl/h5dya Vy40IhYqr3PleIGBr6pWqs40l7gk6Gp1YdqyENyC2CaatdXdYJ7gneQoo0fak7oCggat 3GyVjQKnyyB1BXBizNHBeynGjlvcKHtsFePEaxXY+79713/gUqYMJemITgrKetAHGiu6 4xFnfHAxgw4gQD08VFpSsk2I6BrNrDG0Mveu7dGz40ep3I6XpxrHX4/5Ix5+2t899aDX q0V3HRJQD+yNYgVYjRNJyEQIGOfQ6gmPVvKir+gRMFxI8fI8gLSDH12HoZa5LETUIZ9Q z+Gw== 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=7KTB47IGxxQKgjkcuoIQmJWz1YxEemKbHvN4QOJhCv4=; b=l/eM7wD3PnZSi1PBfuHrOEL/y//hRnalnrhwnUkkmtuwKECAydsoAbBiyfTsAAmkho C36vy8J91AhxTYmG30fPzE+a1WTgAHwBrSF8ifZ8EvrS52yCd5nD9FjuIDGHVd2ODzV5 zgb3NGP/BQPanX/nG7Y+BlxaZnl8EdvNlLlxE0PrshBjMs3urhKjzSlQMrc+lhwS+Oqv ETXNPcfLw1JraNq1MuRm9MrEP61SgrVTuAXCU2ksJX+zbLXmlRtt8PHzY8e6E2uF1CHE 6fTJAS/R3zyx0E3nWpuam4Y1gLtCminVCv4j3Nu+AuTIM9i1RVicgjIVuvvsWuRFwmc5 m6aQ== X-Gm-Message-State: APjAAAWfU0M7vEzNwzAugCDo9dklvUrRm2dqAw1G2gGelsc9dLx33YMU Q+x+yrGUCmhlCXmR3shtCWelDrr3qpE2k0cncWHLpw== X-Google-Smtp-Source: APXvYqwRi37m7vOUUk5o35D3hVHGQNrpBfEtAQvI3RRq2K/E74Dg0u7vJ5KI7lyFtgC0kzSZGE9tHSGjVhbKcyIyRnc= X-Received: by 2002:a17:906:fc02:: with SMTP id ov2mr8751984ejb.22.1558624682022; Thu, 23 May 2019 08:18:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 23 May 2019 08:18:00 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> <20190523082129.GA6712@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 23 May 2019 08:18:00 -0700 Message-ID: Subject: Re: Fibonaccing CID lengths To: David Schinazi , Marten Seemann Cc: IETF QUIC WG , Christian Huitema , Kazuho Oku Content-Type: multipart/alternative; boundary="000000000000829dcc05898f96ce" 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, 23 May 2019 15:18:54 -0000 --000000000000829dcc05898f96ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m all for the 8 bit lengths, but I don=E2=80=99t see how they pre= vent ossification of the first two bits? Regardless this kind of ossification is not important since middle boxes will lock down on CID lengths they support and mistreat other lengths. The length field is just one part of this. On 23 May 2019 at 17.13.51, Marten Seemann (martenseemann@gmail.com) wrote: Using an 8-bit encoding would also prevent ossification of the first two bits of each connection ID length field. These bits would always be 0 (in QUIC v1), since connection ID lengths above 48 can never occur. On Thu, May 23, 2019 at 4:08 PM David Schinazi wrote: > This encoding would be harder to deploy on our servers than having two > 8-bit lengths. The only benefit of this is saving 8 bits on long headers, > and that's not worth the complexity. > > On Thu, May 23, 2019 at 9:21 AM Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > >> On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote: >> > 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov : >> > > While the example is lighthearted, the proposal is serious: that is, >> > > remap 0 - 15 values of the nybble to a different set. Do we need to >> > > represent every intermediate number between 0 and 48 (the maximum of >> > > the current PR)? >> > >> > The question is what you gain by compressing the length to 4 bits. >> > >> ----- 8< --- 8< --- 8< --- >> > >> > So, what's the benefit? >> >> Smaller change to the drafts -- and existing code. >> >> - Dmitri. >> >> --000000000000829dcc05898f96ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m all for = the 8 bit lengths, but I don=E2=80=99t see how they prevent ossification of= the first two bits?

= Regardless this kind of ossification is not important since middle boxes wi= ll lock down on CID lengths they support and mistreat other lengths. The le= ngth field is just one part of this.



On 23 May 2= 019 at 17.13.51, Marten Seemann (martenseemann@gmail.com) wrote:

Using an 8-bit encoding would also prevent ossification of the first two bits of each connection ID length field. These bits would always be 0 (in QUIC v1), since connection ID lengths above 48 can never occur.

On Thu, May 23, 2019 at 4:08 PM David Schinazi <dschinazi.ie= tf@gmail.com> wrote:
This encoding would be harder to deploy on our servers than having two 8-bit lengths. The only benefit of this is saving 8 bits on long headers, and that's not worth the complexity.

On Thu, May 23, 2019 at 9:21 AM Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Thu, May 23, 2019 at 04:36:54AM +0100, Kazuho Oku wrote:
> 2019=E5=B9=B45=E6=9C=8822=E6=97=A5(=E6=B0=B4) 21:04 Dmitri Tikhonov &l= t;dtikhono= v@litespeedtech.com>:
> > While the example is lighthearted, the proposal is serious: that is,
> > remap 0 - 15 values of the nybble to a different set.=C2=A0 Do we need to
> > represent every intermediate number between 0 and 48 (the maximum of
> > the current PR)?
>
> The question is what you gain by compressing the length to 4 bits.
>
----- 8< --- 8< --- 8< ---
>
> So, what's the benefit?

Smaller change to the drafts -- and existing code.

=C2=A0 - Dmitri.

--000000000000829dcc05898f96ce-- From nobody Fri May 24 05:56: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 61D47120144 for ; Fri, 24 May 2019 05:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DpWjMxxhnqeO for ; Fri, 24 May 2019 05:56:05 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 6270C12003F for ; Fri, 24 May 2019 05:56:05 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id a132so7322623qkb.13 for ; Fri, 24 May 2019 05:56:05 -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:content-transfer-encoding :in-reply-to:user-agent; bh=IIG/jc9bCIU8QwSq3P7mQS81VvL51IiiQO4DYvZYKck=; b=PMZlV2GtBON8z14ZBD5YNeZLgtBcNnNr7aqjsU7fQO6YKU0YENYPNpBA4HbPLAcGQC oV9x4JxFiXqEiy+KwBzyFOF6/3MRG2l2t8EIsLfd+oJJpVU9SQaIp03+4OCZSxfbuhv6 4bIgTVjeAIE1XQnIzGFtBpwOwxsLRc7LKV7wUwGTtgOjGGTIgwYBXWLJ18B1TPwyBykc 0XpfEf99c8gFfb6okG7/obY6m8kRo3QuF7BT7yRYwLOR8SIRcRi0Zj9/G9pB/vVUHLSv VXEv4Z46n7d9HMBzuV2sZYqamXgoE6+6xtxl1zD9LrI6WICtxogv0bJ7vifZU6q0L5h1 JFRQ== 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 :content-transfer-encoding:in-reply-to:user-agent; bh=IIG/jc9bCIU8QwSq3P7mQS81VvL51IiiQO4DYvZYKck=; b=dLlJl+eeeGQ5QaM6PKvhOd5rQDRU+VVS1H+RlD39Iudnhlb3NCdFpBZdu8pwAxaHbe bBVG28s8/Sf3HM+ITGAWMLgEqXZmBPdrTIoFt0Pxva/8d2cnssKakIAUAJpSpEzy4DvD Qn7HKYiLP4hwHZSfu9y80xtyLSwVHcfJVmCbPK6Cxdl2v9ZWOuSfwkfFjw0P+4sseu4O KwO9i4/eGAREApyAES6pke7Rnhk1v4rYNA7kR4sZba91fyJk7535hxEQ5QwsrnSQzidP XO093k8Dbm897iTtMdnOVhCvyxOk8zvtx0AkCd/bFryqbKhKU3f5IoQaban1IZdZYx/k vbAw== X-Gm-Message-State: APjAAAX6JIPDER0769A0y+qXZP1UdRQGvW7sqnIgDojl9KJ68qexL50y MjXke3++1B0CJlmn8J9VS0eaHA== X-Google-Smtp-Source: APXvYqxadaOo4k4I3B9hGT6q2Z+/Yf0sDRe3GQ3YO9aUDkWUmXRU0icCxWg+ud1Y8oJ+mTG+URvVPw== X-Received: by 2002:ac8:2617:: with SMTP id u23mr85013555qtu.141.1558702564566; Fri, 24 May 2019 05:56:04 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id e133sm1562615qkb.76.2019.05.24.05.56.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 05:56:03 -0700 (PDT) Date: Fri, 24 May 2019 08:55:58 -0400 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: David Schinazi , Marten Seemann , IETF QUIC WG , Christian Huitema , Kazuho Oku Subject: Re: Fibonaccing CID lengths Message-ID: <20190524125557.GA23853@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , David Schinazi , Marten Seemann , IETF QUIC WG , Christian Huitema , Kazuho Oku References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> <20190523082129.GA6712@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: Fri, 24 May 2019 12:56:08 -0000 On Thu, May 23, 2019 at 08:18:00AM -0700, Mikkel Fahnøe Jørgensen wrote: > I’m all for the 8 bit lengths, but I don’t see how they prevent > ossification of the first two bits? I believe Marten meant 8-bit encoding for both DCID and SCID length, just like what we have now. In the 4-bits-per-length scheme, it is likely that no single bit will be found to always have a particular value. This would prevent ossification. - Dmitri. From nobody Fri May 24 13:02: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 257151200F3 for ; Fri, 24 May 2019 13:02: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, 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=ayaZg75C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TP6QWMij Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTEof4y3Wi53 for ; Fri, 24 May 2019 13:02:18 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4691200F1 for ; Fri, 24 May 2019 13:02:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 1945A633; Fri, 24 May 2019 16:02:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 24 May 2019 16:02:18 -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=fAoSRHVQqmVeSINolxMm8Z/nl8xl30 GsruBrcH8hIAg=; b=ayaZg75CTy6EZ7T8RtJszJHj31xB6Bo2WQuARyTxIpHfAM Sb2IxdnA4bjrDtwR3CfBdx6dgDfjbLZ1XVZR76feKH0ARJ28SO2QYnfHgZa5ilen AVWFXb3XN+Tf5ojsxKmr7/9SKv6AzTgho0TmooBoiihsdSnENZ42FwU8LZwDY4Xc bSp3A6gitmYfiXfbleItx9TuiJGgKeTIvXOu4c4vZHP3ue1QtLObX0RYxjqo2pZd g+V9tSF0rHBgez5pRgeaxtFIkDaBZdOSWpaFFNCcMgzaaJi6sXg77a6H2iSX92pi KDmITcolcSzoKweP2h0vOuNkJtRj3YARq1beuOKQ== 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=fm2; bh=fAoSRH VQqmVeSINolxMm8Z/nl8xl30GsruBrcH8hIAg=; b=TP6QWMijq4b+zwJsH+yf9A mOmChgI3BXu2W9+EWxCQUeWmrhwdaRFHPuKg6y3lBBXIUnqr/7LEpiNIZtbABAGO bCJv3A4EGYQ5UjZon/AWtT2+PhmT3B7LSvwPP5nXmuWicwziQrm9CO6XmgY8bZE8 FkP8gKZ3im2kVVw3aiDte1zWv5dMNaWXgtH3RZ9U2Qe4A5ky+4Bur9zLSauWcRp+ SgfPwFVnm/dEDK7bg8uWX4RMv+MQAVV+LhOBXdsdzs6PPkxNZcah9QQ4GVbuoDE9 deBLvtpXq3a4+JUYb+gsg+EReG3hp71n69P8OJ3XcRsF+QyWKumqvW3bUXmbEiJw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudduiedgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhtgfgggfukfffvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduieejrdelkedrfeeirdej tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [172.21.0.215] (unknown [167.98.36.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 650008005C; Fri, 24 May 2019 16:02:15 -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.8\)) Subject: DRAFT minutes from the London interim Message-Id: <6810364D-6A76-453F-9249-E8FBF401AB15@mnot.net> Date: Fri, 24 May 2019 21:02:12 +0100 Cc: Lars Eggert To: QUIC IETF mailing list X-Mailer: Apple Mail (2.3445.104.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: Fri, 24 May 2019 20:02:21 -0000 ... are available at: = https://github.com/quicwg/wg-materials/blob/master/interim-19-05/minutes.m= d As always, suggestions and corrections appreciated, either in a Pull = Request or in response to this message. Thanks again to our scribes, and our hosts. This was a productive = meeting. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri May 24 20:12: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 521A7120340 for ; Fri, 24 May 2019 20:12:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2DeqTR-L0VN for ; Fri, 24 May 2019 20:12:01 -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 E24B1120123 for ; Fri, 24 May 2019 20:12:00 -0700 (PDT) Received: from [66.113.192.14] (helo=xsmtp02.mail2web.com) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hUN6E-0005LA-EZ for quic@ietf.org; Sat, 25 May 2019 05:11:59 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hUN6B-0008BL-9H for quic@ietf.org; Fri, 24 May 2019 23:11:56 -0400 Received: (qmail 19722 invoked from network); 25 May 2019 03:11:51 -0000 Received: from unknown (HELO [192.168.9.35]) (Authenticated-user:_huitema@huitema.net@[67.129.15.3]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 May 2019 03:11:51 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , David Schinazi , Marten Seemann , IETF QUIC WG , Kazuho Oku References: <20190522141238.GA23472@ubuntu-dmitri> <20190522200406.GA28789@ubuntu-dmitri> <20190523082129.GA6712@ubuntu-dmitri> <20190524125557.GA23853@ubuntu-dmitri> 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: <1639ec5e-ec91-0a68-2ea1-5178dc8b20d3@huitema.net> Date: Fri, 24 May 2019 20:11:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190524125557.GA23853@ubuntu-dmitri> Content-Type: multipart/alternative; boundary="------------9A41A229C218142B6F478C34" Content-Language: en-US Subject: Re: Fibonaccing CID lengths 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/gcnlw0fbJ1LThpDP3PaEa+mzHFASpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcnqpk5VeF3xR4kF6iVwRtbgN zB/4Jkrw1eDLcif59fu2ckZtSEshRaN01QcPyu9+/sevPPdLVvjz7b14RFNIS3a8YhJ35wl01TiS 31UcsRt851TaRAUkTN+SrghOjOYz03+K7Ju/qxRhvHDAT5LyR61Qv/sjUDXLdm6w1gNv1euKTrwh UfUHUrPvTkTGu7YwVDQ0hbqcLWUbjgHMZS6COdI/uLAeALf3vLWnw0F/4+fmuTv/CYIzmchrGsA6 CN6O7qbWTdT56xh4Rya20+oBtwahqtg42IMQXC/e/thfmehs05Web8nJyEMtLxwhnYinDFrKlNc7 qNKmpnIY9d8cOJUa+B0z/Xg2ESGxDSOWWoTyIUtK8Miz//+1AD61I8sOcFFSGcngeU5u06zO01Ld 6NjlDHh8k6TTdHl8m1/8O//LcKgaYLn9Y2q9E0HrGD+j+fGw1CK4jkjkEyu72s9owQ7UqFmoc7zj YJSAV3JUSvLvOO+Hbv5IdqW6ntDSv9XhrRYSbBjCo2sk7ijoTjkI86yp/agYZfrnDk8+IFUpab7m 9Ql4Ld7qe/xoNQPgy7UpxcIWHOi9y3yF+Ot2t6dhJc2bXYMFScrLivfWmWkJo22CHZOREywSBAd6 WuRFS3mxWkOXVm+COyPL3m30pl2D10KR20fJjHecvS3hLwZSCSk8CVsONrMJuGzuoGnKTKcymM5H 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: Sat, 25 May 2019 03:12:06 -0000 This is a multi-part message in MIME format. --------------9A41A229C218142B6F478C34 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/24/2019 5:55 AM, Dmitri Tikhonov wrote: > On Thu, May 23, 2019 at 08:18:00AM -0700, Mikkel Fahn=C3=B8e J=C3=B8rge= nsen wrote: >> I=E2=80=99m all for the 8 bit lengths, but I don=E2=80=99t see how the= y prevent >> ossification of the first two bits? > I believe Marten meant 8-bit encoding for both DCID and SCID length, > just like what we have now. In the 4-bits-per-length scheme, it is > likely that no single bit will be found to always have a particular > value. This would prevent ossification. The current format of the long header encodes two lengths in one byte, followed by the Dest CID and the Source CID. The proposal that got consensus in London is to replace that by one byte of length of DCID, DCID, one byte of SCID, SCID. The general agreement is that given the usage of the long header, it is not necessary to compress the length fiel= d. This would be a change in the invariants. Ossification of the format is not really a concern. By definition, the invariants are supposed to ossify. But there is an ossification risk for the actual length. As far as V1 is concerned, we agreed to limit the actual length to less than 64 bytes. The two most significant bits of the two length fields will be zero, so there is a possibility that middle-boxes will use that to detect whether a packet is using QUIC. The risk there is that this would prevent future versions from using CID lengths larger than 64 bytes= =2E -- Christian Huitema --------------9A41A229C218142B6F478C34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/24/2019 5:55 AM, Dmitri Tikhonov wrote:
On Thu, May 23, 2019 at 08:18:00AM -0700, Mikkel Fahnøe Jørgensen wrote:

I’m all for the 8 bit lengths, but I don’t see how they prevent
ossification of the first two bits?

I believe Marten meant 8-bit encoding for both DCID and SCID length,
just like what we have now.  In the 4-bits-per-length scheme, it is
likely that no single bit will be found to always have a particular
value.  This would prevent ossification.

The current format of the long header encodes two lengths in one byte, followed by the Dest CID and the Source CID. The proposal that got consensus in London is to replace that by one byte of length of DCID, DCID, one byte of SCID, SCID. The general agreement is that given the usage of the long header, it is not necessary to compress the length field.

This would be a change in the invariants. Ossification of the format is not really a concern. By definition, the invariants are supposed to ossify. But there is an ossification risk for the actual length.

As far as V1 is concerned, we agreed to limit the actual length to less than 64 bytes. The two most significant bits of the two length fields will be zero, so there is a possibility that middle-boxes will use that to detect whether a packet is using QUIC. The risk there is that this would prevent future versions from using CID lengths larger than 64 bytes.

-- Christian Huitema

--------------9A41A229C218142B6F478C34-- From nobody Sat May 25 17:45: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 2EFFB12002F for ; Sat, 25 May 2019 17:45:29 -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=k7APkU9C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RrjTEtET Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj9MdABmFciJ for ; Sat, 25 May 2019 17:45:24 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232D01200D7 for ; Sat, 25 May 2019 17:45:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3745820F25 for ; Sat, 25 May 2019 20:45:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 25 May 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=zA3P+rJ0lGGTJvHFuhluYXO9A36cdQWLffHmVw96Z70=; b=k7APkU9C r0FAMRac3mQ7KhEiuvInbXPuCpvRFqZZHreEoV0wXNPsQSlscOan6XHMhElsn3Sa kKU9ggZD50iDbjsl44AKiPJg6+KEoOGvQiGQ7EUSqpx3sJ5SW/VPJeKAMczQr6XK ldyTjWquooVL4CO6cxpHu9AqYksQEja5x4+3lLqfXPHbue+sZ1S1nMna9fFCv4bd FH5SKAWOwyTh6IYYuCgZv3HvYH8mbSGgQWlV/dyIbGCowNKbZNgFKiVHt0szy558 SMAMlvO44HenpaWeIUAT7ODPU0jZzrjm1wSI6CItd6kBTvJVgLh++oitUYYPDL6b e//D8rFnsrNmpw== 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=zA3P+rJ0lGGTJvHFuhluYXO9A36cd QWLffHmVw96Z70=; b=RrjTEtETBztTEFTQIuLu+xO0zBIusP+yMN1Fhu8Hbt/0w AP4xM8grPdXbtOe2SiJInBTQjb1kJMi7FDaXNtgfpHumHg6nsvqd9mMSXXXUlkNc t9skHD9hlhoTlmW8lvY6oTFP8eX76/CcEVFOPVT5W0FD1FSuwX4fivUKMNGM8obY 8OQ+CprCBZ3bI8p7SEk4bgGhGjL4TOzs1aWO+OUtic25atsv708Od9CMQLNKRaA1 O4t6wH1loqFNYU2nZ9zCRRpev+cTI/hZe6yh5OkSarxDfd9ZfdC8LKNM1XeUfSWR cqh3fC44kiNoZ4iqf29O0v0hqhRxrniFFV7SBvzYQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudduledgfeefucetufdoteggodetrfdotf 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 8715480060 for ; Sat, 25 May 2019 20:45:20 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id EA817C03B8 for ; Sun, 26 May 2019 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============5880941385752096621==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20190526004516.EA817C03B8@cloud.mnot.net> Date: Sun, 26 May 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, 26 May 2019 00:45:29 -0000 --===============5880941385752096621== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+4/-7/=F0=9F=92=AC120) 4 issues created: - ECN Algorithm (by martinthomson) https://github.com/quicwg/base-drafts/issues/2755 = - Lessen the divergence from the HTTP/2 prioritization scheme by requirin= g all PRIORITY frames to be sent on the control stream (by kazuho) https://github.com/quicwg/base-drafts/issues/2754 = - NUM_PLACEHOLDERS MUST NOT be zero (by kazuho) https://github.com/quicwg/base-drafts/issues/2753 = - Retransmitting ACKs may cause misleading RTT samples (by ianswett) https://github.com/quicwg/base-drafts/issues/2748 [-recovery] = 41 issues received 120 new comments: - #2645 Retire My Own CID (34 by kazuho, marten-seemann, mikkelfj, ianswe= tt, mnot, erickinnear, martinthomson, nibanks) https://github.com/quicwg/base-drafts/issues/2645 [-transport] [design] = - #2496 QUIC Version Ossification (17 by kazuho, marten-seemann, mikkelfj= , mnot, martinthomson, huitema, ekr) https://github.com/quicwg/base-drafts/issues/2496 [-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 (7 by kazuho, = ianswett, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/issues/2754 [-http] = - #2739 HTTP/3 priorities are too complex for a majority of implementatio= ns (6 by rmarx, pmeenan, LPardue, mikkelfj) https://github.com/quicwg/base-drafts/issues/2739 [-http] = - #2753 NUM_PLACEHOLDERS MUST NOT be zero (5 by kazuho, dtikhonov, MikeBi= shop) https://github.com/quicwg/base-drafts/issues/2753 [-http] = - #2699 HTTP/3 Client handling of SERVER_BUSY error code needs to be spec= ified (3 by udippant, pravb, LPardue) https://github.com/quicwg/base-drafts/issues/2699 [-http] [design] = - #2744 Idle Timer Can Fire Even with Outstanding Data to Send (3 by mart= inthomson, mikkelfj, nibanks) https://github.com/quicwg/base-drafts/issues/2744 [-transport] [editori= al] = - #2630 Define "under-utilization" of cwnd (3 by maolson-msft, pravb, ian= swett) https://github.com/quicwg/base-drafts/issues/2630 [-recovery] [design] = - #2170 Embed QUIC version in expansion (3 by larseggert, ekr, mikkelfj) https://github.com/quicwg/base-drafts/issues/2170 [-tls] [design] = - #2308 handling of coalesced packets with decryption errors creates DoS = opportunity (2 by erickinnear, larseggert) https://github.com/quicwg/base-drafts/issues/2308 [-transport] [design] = - #2205 Largest acked in ACK frame MUST NOT decrease (2 by janaiyengar, l= arseggert) https://github.com/quicwg/base-drafts/issues/2205 [-transport] [design] = - #2342 Spoofed connection migration as a DoS vector (2 by erickinnear, l= arseggert) https://github.com/quicwg/base-drafts/issues/2342 [-transport] [design] = - #2742 Automatic applicability of new TLS cipher suites (2 by ekr, mikke= lfj) https://github.com/quicwg/base-drafts/issues/2742 [-tls] [editorial] = - #2644 RTT measurement using PATH_* frames (2 by rpaulo, ianswett) https://github.com/quicwg/base-drafts/issues/2644 [-recovery] [editoria= l] = - #2143 Be more conservative about migration? (2 by erickinnear, larsegge= rt) https://github.com/quicwg/base-drafts/issues/2143 [-transport] [design] = - #2546 ACK of ACK are useful (2 by igorlord, larseggert) https://github.com/quicwg/base-drafts/issues/2546 [-transport] [design] = - #2192 Optimistic ACK in early handshake (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2192 [-transport] [design] = - #2580 Is path validation a SHOULD or a MUST -- pick one! (1 by igorlord) https://github.com/quicwg/base-drafts/issues/2580 [-transport] [design]= [proposal-ready] = - #2711 Prohibiting server-initiated streams for h3 (1 by vasilvv) https://github.com/quicwg/base-drafts/issues/2711 [-http] = - #1860 ACK-only feedback loop in recovery instead of transport (1 by ian= swett) https://github.com/quicwg/base-drafts/issues/1860 [-recovery] [editoria= l] = - #2593 Persistent congestion interaction with app limited state (1 by ia= nswett) https://github.com/quicwg/base-drafts/issues/2593 [-recovery] [editoria= l] = - #2596 Should platform delays be included in ack-delay? (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2596 [-recovery] [design] = - #2728 Recovery: exit initial slow start on RTT increase (1 by mnot) https://github.com/quicwg/base-drafts/issues/2728 [-recovery] = - #2602 Idle timeout needs more description and a recommendation (1 by mn= ot) https://github.com/quicwg/base-drafts/issues/2602 [-transport] [design] = - #2734 Placeholder limits make for awkward clients (1 by ianswett) https://github.com/quicwg/base-drafts/issues/2734 [-http] = - #2100 Avoid creating QPACK codec streams when unnecessary (1 by afrind) https://github.com/quicwg/base-drafts/issues/2100 [-qpack] [design] = - #2755 ECN Algorithm (1 by gorryfair) https://github.com/quicwg/base-drafts/issues/2755 [-recovery] = - #2632 H3 GOAWAY should be symmetric and cover bidi and uni streams (1 b= y MikeBishop) https://github.com/quicwg/base-drafts/issues/2632 [-http] [design] = - #2180 Is Retry a new connection or what? (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2180 [-transport] [editori= al] = - #2488 Provide address validation token in Alt-Svc (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/2488 [-http] = - #2258 Initial maximum table size needs clarification. (1 by afrind) https://github.com/quicwg/base-drafts/issues/2258 [-qpack] [design] = - #2084 Discuss requirement that connection IDs not be correlatable (1 by= larseggert) https://github.com/quicwg/base-drafts/issues/2084 [-transport] [design] = - #2394 Spoofed retry token attack on IP authentication (1 by ekr) https://github.com/quicwg/base-drafts/issues/2394 [-transport] [design] = - #2389 Be clearer about the purpose of disable_migration (1 by larsegger= t) https://github.com/quicwg/base-drafts/issues/2389 [-transport] [design] = - #2684 Mixture of transport and congestion control functions (1 by larse= ggert) https://github.com/quicwg/base-drafts/issues/2684 [-transport] [editori= al] = - #2550 Apply GREASE to transport parameters (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2550 [-transport] [design] = - #2552 Saving a round-trip time in the initial handshakes with retry (1 = by mnot) https://github.com/quicwg/base-drafts/issues/2552 [-transport] [design] = - #2555 Define idle period for congestion control (1 by pravb) https://github.com/quicwg/base-drafts/issues/2555 [-recovery] [design] = - #2556 Should kPersistentCongestionThreshold be 2 or 3? (1 by mnot) https://github.com/quicwg/base-drafts/issues/2556 [-recovery] [design] = - #2685 CC state after a change of path? (1 by larseggert) https://github.com/quicwg/base-drafts/issues/2685 [-transport] [design] = - #2686 Pacing when under-utilizing the Congestion Window (1 by gorryfair) https://github.com/quicwg/base-drafts/issues/2686 [-recovery] [editoria= l] = 7 issues closed: - Initial maximum table size needs clarification. https://github.com/quic= wg/base-drafts/issues/2258 [-qpack] [design] = - Recovery: exit initial slow start on RTT increase https://github.com/qu= icwg/base-drafts/issues/2728 [-recovery] = - Automatic applicability of new TLS cipher suites https://github.com/qui= cwg/base-drafts/issues/2742 [-tls] [editorial] = - NEW_TOKEN token and encryption https://github.com/quicwg/base-drafts/is= sues/2543 [-transport] [editorial] = - Optimistic ACK in early handshake https://github.com/quicwg/base-drafts= /issues/2192 [-transport] [design] = - Connection ID Length changes https://github.com/quicwg/base-drafts/issu= es/2473 [-transport] [design] = - Idle timeout needs more description and a recommendation https://github= .com/quicwg/base-drafts/issues/2602 [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+10/-4/=F0=9F=92=AC18) 10 pull requests submitted: - transport: fix broken ref to PTO in recovery (by reschke) https://github.com/quicwg/base-drafts/pull/2758 = - fix typo (by marten-seemann) https://github.com/quicwg/base-drafts/pull/2757 = - Remove AEAD_AES_256_GCM (by DavidSchinazi) https://github.com/quicwg/base-drafts/pull/2756 = - ECN verification text (by janaiyengar) https://github.com/quicwg/base-drafts/pull/2752 = - Enable/disable/coordinate spin per path (by martinthomson) https://github.com/quicwg/base-drafts/pull/2751 [-transport] [editorial= ] = - Don't use ECN if packets are discarded (by martinthomson) https://github.com/quicwg/base-drafts/pull/2750 [-transport] [editorial= ] = - Allow longer CIDs (by martinduke) https://github.com/quicwg/base-drafts/pull/2749 = - Recommend only one packet per encryption level (by martinthomson) https://github.com/quicwg/base-drafts/pull/2747 = - Clients use the same crypto handshake after Retry (by martinthomson) https://github.com/quicwg/base-drafts/pull/2746 [-transport] [design] = - Keep idle timeout asymmetric (by martinthomson) https://github.com/quicwg/base-drafts/pull/2745 [-transport] [editorial= ] = 11 pull requests received 18 new comments: - #2749 Allow longer CIDs (7 by DavidSchinazi, dtikhonov, martinduke, mik= kelfj) https://github.com/quicwg/base-drafts/pull/2749 = - #2743 Better articulate principles for ciphersuites (2 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2743 [-tls] [editorial] = - #2700 HTTP/3 with strict priorities (1 by rmarx) https://github.com/quicwg/base-drafts/pull/2700 = - #2574 Add normative language for stateless reset (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2574 [-transport] = - #2746 Clients use the same crypto handshake after Retry (1 by martintho= mson) https://github.com/quicwg/base-drafts/pull/2746 [-transport] [design] = - #2747 Recommend only one packet per encryption level (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/2747 [-transport] [design] = - #2750 Don't use ECN if packets are discarded (1 by mirjak) https://github.com/quicwg/base-drafts/pull/2750 [-transport] [editorial= ] = - #2756 Remove AEAD_AES_256_CCM (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2756 [-tls] [editorial] = - #2647 Clarify that unlinkability is required for NEW_TOKEN tokens. Chan= ges =E2=80=A6 (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2647 [-transport] [editorial= ] = - #2682 Allow AES_128_CCM_8 in QUIC (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/2682 [-tls] = - #2687 New paths may seed initial_rtt (1 by rpaulo) https://github.com/quicwg/base-drafts/pull/2687 [-recovery] = 4 pull requests merged: - Remove AEAD_AES_256_CCM https://github.com/quicwg/base-drafts/pull/2756 [-tls] [editorial] = - Better articulate principles for ciphersuites https://github.com/quicwg/base-drafts/pull/2743 [-tls] [editorial] = - Clarify that unlinkability is required for NEW_TOKEN tokens. Changes = =E2=80=A6 https://github.com/quicwg/base-drafts/pull/2647 [-transport] [editorial= ] = - transport: replace "stateless retry" in text with "retry" https://github.com/quicwg/base-drafts/pull/2738 [-transport] [editorial= ] = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============5880941385752096621== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday May 26, 2019

Issues

quicwg/base-drafts (+4/-7/=F0=9F=92=AC120)

4 issues created:

41 issues received 120 new comments:

7 issues closed:

Pull requests

quicwg/base-drafts (+10/-4/=F0=9F=92=AC18)

10 pull requests submitted:

11 pull requests received 18 new comments:

4 pull requests merged:

Repositories tracked by this digest:

 --===============5880941385752096621==-- From nobody Mon May 27 22:33: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 657F412006A for ; Mon, 27 May 2019 22:33:54 -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=bLEMq+5V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=flRqXUh1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhKPzE5ANUAw for ; Mon, 27 May 2019 22:33:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BF112008D for ; Mon, 27 May 2019 22:33:51 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 430C821FAE; Tue, 28 May 2019 01:33:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 28 May 2019 01:33:50 -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=CiZgW/DKKG3vmyCfKvDfwNN6wuHIPX w9o1vvGVTnPhw=; b=bLEMq+5VIE5ibEv13A/jn8Adq1Od9cKz5IrckBnMxQ80f5 EJRgT8d1z5aptyGyPhA+js6bXIc0i7GNXuqMHGHx5WsX6NlG11aT6IGDnQRJOBa+ 9QUkPUPMINtRYzD8Wb13MdVbLMvoOIyKD1SxVeokUhW2U6wdzArBZwp1DSxwBiKe P4ylUeYgj3qqGh9xUfdAifrrVPUlavy7m+9NBi1Z/sfFNXI8IUIpdiFo1K8vfs3X TD43jD72Br4lyB9zBb3Nc7wMctmhyDlWZ8B9daNjxl0IfXlLUX1ikdD6YrAYmloa VJJQHob8TdPs8gdJFqWTva6aqZbh70OWul168Dsw== 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=fm2; bh=CiZgW/ DKKG3vmyCfKvDfwNN6wuHIPXw9o1vvGVTnPhw=; b=flRqXUh1wJJzfNe+m5ZjLZ +KsKprM90hannlHnjlTDiadhWwnsTR/Me5miZ3O1/jqHojGHtdv5j5o5qed/zlaH Ijm7b9Qz7yhB8+96JFHEfQwR8FpaAyqSHBgfvuLMFUv/2LMQhyMIEahQb9YB3sXc MdJT6y8jCf1/NqueTdUoq9H9vhBtWuYacm0hBUFOVxSl1Z3GOP+0CTRmpGz66937 0jxgdKgrSg8dObYqZkwBNiAaHuGesRch5Xy5Xx32Q3EMTX9byA9swvWx6dGDuV24 29/0afrQ3qsdT2M37t9BdBQsx/D/prX24U9+NEzUcDX9SgqVvyABk3m4nshqG3CQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvgedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfp ohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinhepmh hnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 20EBA8005B; Tue, 28 May 2019 01:33:47 -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: Tue, 28 May 2019 15:33:43 +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, 28 May 2019 05:33:54 -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!). * #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) Absent any pushback, we'll declare consensus at the end of the week. Cheers, -- Mark Nottingham https://www.mnot.net/