From nobody Wed Mar 1 04:53:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6434D12954D for ; Wed, 1 Mar 2017 04:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cNEzJziYRmMR for ; Wed, 1 Mar 2017 04:52:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 766BC12954A for ; Wed, 1 Mar 2017 04:52:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 22FF4200043; Wed, 1 Mar 2017 12:52:58 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 0CB44200004; Wed, 1 Mar 2017 12:52:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488372778; bh=8xJL2e3qqg0CZTIhAdrrM+iR0DXt55ZSa/ZR4VLCjgA=; l=510; h=From:To:CC:Date:References:In-Reply-To:From; b=cGfvUV1bZep+8o86KC0/H0uVXR00Jcr3619Qw9ukYjasJILTYsxz/OAslymD0GkrO jdYPFtkTrTfTmIvW8D2Nel0JS17pbCygSCiBTKXKyxSkxC44ahcYF+VBVIhtJDJ0Ts BAsrpUnZlYONpW3XUlXGWSnkatARLoKJmIqz9hm8= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id E836A1E07C; Wed, 1 Mar 2017 12:52:57 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Mar 2017 07:52:57 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 1 Mar 2017 07:52:57 -0500 From: "Salz, Rich" To: Victor Vasiliev , Martin Thomson Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO9GLASB39Y9keFGs57FrIlLqF/v3MAgAAxZBA= Date: Wed, 1 Mar 2017 12:52:56 +0000 Message-ID: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 12:52:59 -0000 PiBNeSBwZXJzb25hbCBwcmVmZXJlbmNlIGhlcmUgbGllcyB3aXRoIHRoZSBhbGdvcml0aG1zIHdo aWNoIGNhbiBiZSBpbXBsZW1lbnRlZCBvbiBhIHR5cGljYWwgQ1BVIHdpdGhvdXQgYSBsb29rdXAg dGFibGUgLS0gdGhhdCBpcyB0byBzYXksIG5vdCBDUkMgb3IgR0hBU0guwqAgR0hBU0ggbWlnaHQg YmUgZmluZSBzaW5jZSBpdCdzIE1USSBmb3IgVExTIGFueXdheXMuDQoNClNvIHlvdSB3YW50IHNv bWV0aGluZyB0aGF0IGNhbiBiZSBkb25lIGluIGNvbnN0YW50LXRpbWUgd2l0aG91dCBkYXRhLWRl cGVuZGFudCBzaWRlLWNoYW5uZWxzPyAgKzEgdG8gdGhhdC4gIEdIQVNIIGlzbid0IGluIFRMUywg dW5sZXNzIEknbSBtaXN0YWtlbiB0aG8uDQoNCg0K From nobody Wed Mar 1 08:10:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513DC1295B8 for ; Wed, 1 Mar 2017 08:10:47 -0800 (PST) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5fXoAeWC44y for ; Wed, 1 Mar 2017 08:10:46 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E6312951A for ; Wed, 1 Mar 2017 08:10:46 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 25so21787623pgy.0 for ; Wed, 01 Mar 2017 08:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rPEVpCPGUaWGySt7izC/2sZa4m9v+h6fMmEyod+niwU=; b=Nv2ZjB12dnCjOGQBjhkNQyvHaUeZUQ+SxHQ3H2JdKSN0vTZodVYaK8mL/WVmewARwf QHVXDhQ5/3tquJKbj5moW0wzC5XvQUMcqczGMxfMMtNt2lYMMkb+V56yxFxKmks3GBeN 9BDDvs7L1hVzzwJmvbnaVS8xVL9yIqT4LMPww= 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=rPEVpCPGUaWGySt7izC/2sZa4m9v+h6fMmEyod+niwU=; b=KJa3dubRLVroJnAcUXBDOHQ/yLKBxsJ4Z2k7jhPSciyZ8rPFGR2Fge+Rnk1d77HO6r AEU+AUAFB5Y0oWan0td26X8bPO5bu2uTV0yYOls9YZ4q6gKA7HG1txvdy7LdX3wHQvBW epoRMu/Bg1KEdYQgUdmsfVZT4p6rdHoTVF50lRHULOpedbPnNifAbHtGoxVjNMx4SaLL UYEcJGyaxC/T+crxY2PcUYy0FEfeYMvP+yx9AoUQl/qpfmk0HtgO8SohNUEnX6Hal3fZ uWb5zLC0+KPkA5BaLvh+wPd4W8SexiiVGHGDhLugIgQMd7rpIYixg6MZQh/BoUuqOZ42 o5Xg== X-Gm-Message-State: AMke39kxm4ycOddlvdsDubWl4KNwyS4pwg5NdfYKeQzt3HZoXzevm4nQE+LFTD5C15SbxiPT1mOscJr1JoWB+Q1l X-Received: by 10.84.136.135 with SMTP id 7mr11439911pll.149.1488384645579; Wed, 01 Mar 2017 08:10:45 -0800 (PST) MIME-Version: 1.0 References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> From: David Benjamin Date: Wed, 01 Mar 2017 16:10:34 +0000 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Salz, Rich" , Victor Vasiliev , Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c13edd61705ce0549ad8eb7 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:10:47 -0000 --94eb2c13edd61705ce0549ad8eb7 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 7:53 AM Salz, Rich wrote: > > My personal preference here lies with the algorithms which can be > implemented on a typical CPU without a lookup table -- that is to say, not > CRC or GHASH. GHASH might be fine since it's MTI for TLS anyways. > > So you want something that can be done in constant-time without > data-dependant side-channels? +1 to that. GHASH isn't in TLS, unless I'm > mistaken tho. > (GHASH is what AES-GCM uses.) --94eb2c13edd61705ce0549ad8eb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 1,= 2017 at 7:53 AM Salz, Rich <rsalz@a= kamai.com> wrote:
> My = personal preference here lies with the algorithms which can be implemented = on a typical CPU without a lookup table -- that is to say, not CRC or GHASH= .=C2=A0 GHASH might be fine since it's MTI for TLS anyways.

So you want something that can be done in constant-time without data-depend= ant side-channels?=C2=A0 +1 to that.=C2=A0 GHASH isn't in TLS, unless I= 'm mistaken tho.

(GHASH is what AES-GCM uses.)
--94eb2c13edd61705ce0549ad8eb7-- From nobody Wed Mar 1 08:11:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F95A129598 for ; Wed, 1 Mar 2017 08:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Uu6vdpAKZxGn for ; Wed, 1 Mar 2017 08:11:34 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 55F941295B3 for ; Wed, 1 Mar 2017 08:11:32 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DC177200017; Wed, 1 Mar 2017 16:11:31 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C61FA200004; Wed, 1 Mar 2017 16:11:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488384691; bh=7QmkwfREmFCEE3QlXyWjIrkYXK752RMHl+15lxltW58=; l=96; h=From:To:CC:Date:References:In-Reply-To:From; b=VGT5IxWfY43BpAjoNejfQboZm+GawTIXFDOpMvnYRwB938bTJhMIIHnUrNqf3kYkp +33qFa/WLC0bZimv3g8SEv/VbepkAUbVFAJzknoQ4TBJCsNE8ZebIC/VcBr3mPpUCX pvVbFZXNQ6DIHTcgD9ednCBFi78hPyVlA9TUL5zg= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id AB7D898088; Wed, 1 Mar 2017 16:11:31 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Mar 2017 11:11:31 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 1 Mar 2017 11:11:31 -0500 From: "Salz, Rich" To: David Benjamin , Victor Vasiliev , Martin Thomson Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO9GLASB39Y9keFGs57FrIlLqF/v3MAgAAxZBCAAItJAP//rF7w Date: Wed, 1 Mar 2017 16:11:30 +0000 Message-ID: <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:11:35 -0000 PiAgKEdIQVNIIGlzIHdoYXQgQUVTLUdDTSB1c2VzLikNCg0KLi4uIGFhbmQsIEkgd2FzIHdyb25n LiAgT29wcy4NCg== From nobody Wed Mar 1 08:41:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59DD129600 for ; Wed, 1 Mar 2017 08:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vi9jY67XyOJB for ; Wed, 1 Mar 2017 08:41:42 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0801295FB for ; Wed, 1 Mar 2017 08:41:42 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id v200so36651466ywc.3 for ; Wed, 01 Mar 2017 08:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vitp+L+cOhZa8rkYKLCIFTHPmJ+lBZn1xF38c7ZvhEA=; b=syAllR0zLLlrOi/sE+E8TdQPW+bRBqIHjSyTOCz3LlTrs882bdS2cwLXVERxwbMTas h1i2obZrgylLABPyMLs9qUrYt8tRvIsodC3qY5zzqqe8c/RAuql8EqbJnIfYKzHFfuus 2/5JasbyjNu1Qc0z3JTqLba/nhgfT+OQkG8L2cjF8yWw2VpYadqOaH7YlOOLfzn7KrEE rXOeV81N0ZEGhMt1TEEnxxUz1WoxhumBjN8sd5/j0YIjlNycp5XqhLrsM8Isicj4K3KE 3Mu9HlYm7vhd5NjWBfDMAn5bisPDqXWRvcukLAJgtkLo9THtGrGwTMdT8WgSqDFnyo+C 1f3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vitp+L+cOhZa8rkYKLCIFTHPmJ+lBZn1xF38c7ZvhEA=; b=Xg/JbgK2pZDu7mQkMQbbvdh6aOi7q2M+eVItmoEM85Bp3YT4AwBrG4oUqDTeHYTH/g EOmNpTG3dBwINGTp/NxlylvqowDb/SxbIvli6Bky+VmczQJS+CVpeLlpq5UmrVfCZRvi zR5KJpfn6lVzRk9/z32pbMvZ7DYLQWX+9jFa3MWVoEYRpXCCg7tJzLPaH3pVztubrezj H4+vtHMRueAwChX/pQ7HLB0be02F4LwZ20W7KElYtC4J4VIVthqBNqTbp9bFtKjCOeEY Q0baW8P9cNbIEDOVtk91r7uTl36yrqe3sr3X1NZ4PFHpxOha6OoD/b/WUY8KbbebsiVE PWvA== X-Gm-Message-State: AMke39lSnqWE+keXtqx+ZMpesgsi735r5sLu5dbjfEmYitjmzA/Pdr1qSNHAai1dsGlN2bkAsLZLKvNt7BPka4VN X-Received: by 10.129.125.5 with SMTP id y5mr3068421ywc.120.1488386501197; Wed, 01 Mar 2017 08:41:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.50.139 with HTTP; Wed, 1 Mar 2017 08:41:20 -0800 (PST) In-Reply-To: <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ian Swett Date: Wed, 1 Mar 2017 11:41:20 -0500 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11493644b1bc400549adfc1b Archived-At: Cc: Victor Vasiliev , IETF QUIC WG , Martin Thomson , David Benjamin X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:41:44 -0000 --001a11493644b1bc400549adfc1b Content-Type: text/plain; charset=UTF-8 +1 to making it version dependent and I agree 32 bits is probably plenty to filter out internet junk. On Wed, Mar 1, 2017 at 11:11 AM, Salz, Rich wrote: > > (GHASH is what AES-GCM uses.) > > ... aand, I was wrong. Oops. > --001a11493644b1bc400549adfc1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to making it version dependent and I agree 32 bits is p= robably plenty to filter out internet junk.

On Wed, Mar 1, 2017 at 11:11 AM, Salz, Rich= <rsalz@akamai.com> wrote:
= >=C2=A0 (GHASH is what AES-GCM uses.)

... aand, I was wrong.=C2=A0 Oops.

--001a11493644b1bc400549adfc1b-- From nobody Wed Mar 1 08:57:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE477129600 for ; Wed, 1 Mar 2017 08:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4_pEHNj0hKi1 for ; Wed, 1 Mar 2017 08:57:25 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC1D1294EB for ; Wed, 1 Mar 2017 08:57:25 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0768E200048; Wed, 1 Mar 2017 16:57:25 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E4DED200002; Wed, 1 Mar 2017 16:57:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488387444; bh=yaBCbhXXTvG0hfTymS116QuBmRVG3MjVTvEO8zDMd/k=; l=13416; h=From:To:CC:Date:References:In-Reply-To:From; b=mFHe+nMiLu5pfvm93a3VRFF2fnxtMWnDAiHQd3qCQpkPRMk9x9lU7LPtpMA6J0ZIH 08jc+XCBTq7m2tqfnP6OrLiNvbJosykDhlEhKrT1viys58n15OdJKdgADCgLO1lBAE U+U1s061+I1ijxtGGid6Ks9M1d/C0QF80m6hGgiQ= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id B5FFE98088; Wed, 1 Mar 2017 16:57:24 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Mar 2017 11:57:24 -0500 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.1178.000; Wed, 1 Mar 2017 11:57:24 -0500 From: "Lubashev, Igor" To: Ian Swett , "Salz, Rich" Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO6lru5zftGP0qojvtmiwHwlKF/v3MAgACFdQCAADc4AIAAAEMAgAAIVgD//6/6YA== Date: Wed, 1 Mar 2017 16:57:23 +0000 Message-ID: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.121] Content-Type: multipart/alternative; boundary="_000_fa613a4faee94b8694d01f3d52767974usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: Victor Vasiliev , IETF QUIC WG , Martin Thomson , David Benjamin X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:57:27 -0000 --_000_fa613a4faee94b8694d01f3d52767974usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggICsxIHRvIG1ha2luZyBpdCB2ZXJzaW9uIGRlcGVuZGVudA0KDQpJYW4sIHNvIHlvdSBhcmUg bm90IHRvbyBjb25jZXJuZWQgd2l0aCB0aGUgc2VydmVyIG5vdCBiZWluZyBhYmxlIHRvIHRlbGwg d2hldGhlciB0aGUgdW5rbm93biB2ZXJzaW9uIG51bWJlciBpcyBkdWUgdG8gYSBjb3JydXB0aW9u IG9yIGp1c3QgYW4gdW5rbm93biB2ZXJzaW9uPyBUaGF0IGluZm9ybWF0aW9uIGluZm9ybXMgdGhl IHNlcnZlciBiZWhhdmlvciDigJMgZHJvcCB0aGUgcGFja2V0IG9yIHNlbmQgYSB2ZXJzaW9uIG5l Z290aWF0aW9uIHBhY2tldC4NCg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBn b29nbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwMSwgMjAxNyAxMTo0MSBBTQ0KVG86 IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+DQpDYzogVmljdG9yIFZhc2lsaWV2IDx2YXNp bHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhv bXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVu QGNocm9taXVtLm9yZz4NClN1YmplY3Q6IFJlOiBCaWtlIHNoZWQgd2FybmluZzogaW50ZWdyaXR5 IGNoZWNrIGZvciB1bnByb3RlY3RlZCBwYWNrZXRzDQoNCisxIHRvIG1ha2luZyBpdCB2ZXJzaW9u IGRlcGVuZGVudCBhbmQgSSBhZ3JlZSAzMiBiaXRzIGlzIHByb2JhYmx5IHBsZW50eSB0byBmaWx0 ZXIgb3V0IGludGVybmV0IGp1bmsuDQoNCk9uIFdlZCwgTWFyIDEsIDIwMTcgYXQgMTE6MTEgQU0s IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3 cm90ZToNCj4gIChHSEFTSCBpcyB3aGF0IEFFUy1HQ00gdXNlcy4pDQoNCi4uLiBhYW5kLCBJIHdh cyB3cm9uZy4gIE9vcHMuDQoNCg== --_000_fa613a4faee94b8694d01f3d52767974usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ1MjMzMTk3NTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk5NDE2MjgzNiAtNDMx NDMzMjU2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6NjgyMzE2NTEzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMzk3ODkyNDEyIC04OTcyNjg3MDggNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPiYjNDM7MSB0byBtYWtpbmcgaXQgdmVy c2lvbiBkZXBlbmRlbnQ8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JYW4sIHNvIHlv dSBhcmUgbm90IHRvbyBjb25jZXJuZWQgd2l0aCB0aGUgc2VydmVyIG5vdCBiZWluZyBhYmxlIHRv IHRlbGwgd2hldGhlciB0aGUgdW5rbm93biB2ZXJzaW9uIG51bWJlciBpcyBkdWUgdG8gYSBjb3Jy dXB0aW9uIG9yIGp1c3QgYW4gdW5rbm93biB2ZXJzaW9uPyBUaGF0IGluZm9ybWF0aW9uDQogaW5m b3JtcyB0aGUgc2VydmVyIGJlaGF2aW9yIOKAkyBkcm9wIHRoZSBwYWNrZXQgb3Igc2VuZCBhIHZl cnNpb24gbmVnb3RpYXRpb24gcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0 dEBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDEsIDIw MTcgMTE6NDEgQU08YnI+DQo8Yj5Ubzo8L2I+IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnZAZ29vZ2xl LmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9t c29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyBEYXZpZCBCZW5qYW1pbiAmbHQ7 ZGF2aWRiZW5AY2hyb21pdW0ub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQmlrZSBz aGVkIHdhcm5pbmc6IGludGVncml0eSBjaGVjayBmb3IgdW5wcm90ZWN0ZWQgcGFja2V0czxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSB0byBtYWtpbmcgaXQgdmVy c2lvbiBkZXBlbmRlbnQgYW5kIEkgYWdyZWUgMzIgYml0cyBpcyBwcm9iYWJseSBwbGVudHkgdG8g ZmlsdGVyIG91dCBpbnRlcm5ldCBqdW5rLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXIgMSwgMjAxNyBhdCAxMToxMSBBTSwgU2FseiwgUmlj aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5y c2FsekBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAoR0hBU0ggaXMgd2hhdCBBRVMtR0NN IHVzZXMuKTxicj4NCjxicj4NCi4uLiBhYW5kLCBJIHdhcyB3cm9uZy4mbmJzcDsgT29wcy48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_fa613a4faee94b8694d01f3d52767974usma1exdag1mb5msgcorpak_-- From nobody Wed Mar 1 09:15:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADA5129623 for ; Wed, 1 Mar 2017 09:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WoCZ2k3nc75e for ; Wed, 1 Mar 2017 09:15:29 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F97B129627 for ; Wed, 1 Mar 2017 09:15:29 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id f192so25729665oic.3 for ; Wed, 01 Mar 2017 09:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2CovOrL2n9LaDOKUNS6L9Ut8CKdLbc+2A+ZFjmuDab8=; b=kXhky/xe2BdTV6+9nNtdG0Y/bvHFVoh/jzRAGpUh/K+BzjcmM+2ft1xM23HNZcy9Np 1nHO5fULAbwafLo95riNxgLqR5xfO1QkQ+r7O0tpp3ROa7B8Ods2VZnDp6WN14vdz0MC yR9+do9YK9oe79ET0BNKSjCTDWjpd7LRl7jih93GklC/hxRrSeK5AXJVW/dTyiAxc97z IM9iCkNCNt4bcbdX8UKlx6o1xPteWZHRFjBJN92sfQUhgbosM84NrdgAS7bK+ITU6sTH awIJhMMpa3dp9TcAPt9gfj5qREFyP3tfwJon9YjJ3gdPM/MFB5k2zeDZ0xRoFiQ+YPaz BtVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2CovOrL2n9LaDOKUNS6L9Ut8CKdLbc+2A+ZFjmuDab8=; b=afnYMy/5zq+oOp+mzMkiba3xmXP+UQu2rf0DtAsqsGEBxVvGgf4e8yYLKfWVCTBGHG BAt9pW+A3+M7Bv1xU7zgoI+itWWszxCGn4x/We/7yh21zdKvcnfmeIApMf5mXvL3gW9C r4jwLy62tzyQJySiOUx4IhF2aMB3gOEocm+8f5Sse6fI4Hhv2aM3jkDdEgAdYCZOqg7K L/1WqpsCORjD7luoevzGhSuwH+5oygU8F33VnxaNuNsj+zU4YkGCXpsyswq3H5SZQ8Go J11rmjsN6xi6S8k01cTd3yups3cuEO2FQndnGyb/N8q2YQD4rHkinNTymFVg+OTLaHnl WUGw== X-Gm-Message-State: AMke39mhTSMTL6Jv0osLDSUUJ2GTc0HsqaiyKTV78EC7ECgmfgFLRuGoPuB5qe8Gk4NvlcORU7Y2ke3+i1QJNg== X-Received: by 10.202.72.6 with SMTP id v6mr4836742oia.177.1488388528251; Wed, 01 Mar 2017 09:15:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.142.85 with HTTP; Wed, 1 Mar 2017 09:14:57 -0800 (PST) In-Reply-To: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ted Hardie Date: Wed, 1 Mar 2017 09:14:57 -0800 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a113db24883aca60549ae7529 Archived-At: Cc: "Salz, Rich" , Ian Swett , David Benjamin , Victor Vasiliev , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:15:31 -0000 --001a113db24883aca60549ae7529 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 1, 2017 at 8:57 AM, Lubashev, Igor wrote: > =C3=98 +1 to making it version dependent > > > > Ian, so you are not too concerned with the server not being able to tell > whether the unknown version number is due to a corruption or just an > unknown version? That information informs the server behavior =E2=80=93 d= rop the > packet or send a version negotiation packet. > > > If the version number is corrupted and the server responds with a version negotiation packet, what's the harm? Presumably the server will respond with a list of supported versions and the client will pick one (potentially the same one it picked the first time). As long as clients don't assume they have to change version when they get a version negotiation packet from the server, this seems to be a reasonable result. Am I missing something that makes this worse? regards, Ted > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Wednesday, March 01, 2017 11:41 AM > *To:* Salz, Rich > *Cc:* Victor Vasiliev ; IETF QUIC WG ; > Martin Thomson ; David Benjamin < > davidben@chromium.org> > *Subject:* Re: Bike shed warning: integrity check for unprotected packets > > > > +1 to making it version dependent and I agree 32 bits is probably plenty > to filter out internet junk. > > > > On Wed, Mar 1, 2017 at 11:11 AM, Salz, Rich wrote: > > > (GHASH is what AES-GCM uses.) > > ... aand, I was wrong. Oops. > > > --001a113db24883aca60549ae7529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 1, 2017 at 8:57 AM, Lubashev, Igor <iluba= she@akamai.com> wrote:

=C3=98=C2=A0 +1 to making it version dependent

=C2=A0

Ian, so you are not too concerned with the server n= ot being able to tell whether the unknown version number is due to a corrup= tion or just an unknown version? That information informs the server behavior =E2=80=93 drop the packet or send a version ne= gotiation packet.

=C2=A0


If the version number is corrupted and the server respond= s with a version negotiation packet, what's the harm?=C2=A0 Presumably = the server will respond with a list of supported versions and the client wi= ll pick one (potentially the same one it picked the first time).=C2=A0 As l= ong as clients don't assume they have to change version when they get a= version negotiation packet from the server, this seems to be a reasonable = result.

Am I missing something that makes this worse?
=
regards,

Ted

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Wednesday, March 01, 2017 11:41 AM
To: Salz, Rich <rsalz@akamai.com>
Cc: Victor Vasiliev <vasilvv@google.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= martin.thomso= n@gmail.com>; David Benjamin <davidben@chromium.org>
Subject: Re: Bike shed warning: integrity check for unprotected pack= ets

=C2=A0

+1 to making it version dependent and I agree 32 bit= s is probably plenty to filter out internet junk.

=C2=A0

On Wed, Mar 1, 2017 at 11:11 AM, Salz, Rich <rsalz@akamai.com> = wrote:

>=C2=A0 (GHASH is what AES-GCM uses.)

... aand, I was wrong.=C2=A0 Oops.

=C2=A0


--001a113db24883aca60549ae7529-- From nobody Wed Mar 1 09:36:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF6129613 for ; Wed, 1 Mar 2017 09:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 biXkLyaAmNR5 for ; Wed, 1 Mar 2017 09:36:37 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id B307E1204D9 for ; Wed, 1 Mar 2017 09:36:37 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4BB20200043; Wed, 1 Mar 2017 17:36:37 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 356C0200041; Wed, 1 Mar 2017 17:36:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488389797; bh=q1D/Hxa4N8oDeqD89tsjF27gL9m2C1hXa7r9KZFNPt4=; l=15304; h=From:To:CC:Date:References:In-Reply-To:From; b=u6AkW6hZFFp0aemMHiu7PN2Nq3vhgRssJw703/3NhDu+mRYTP2ol6YsCoBBCvhw4F F4nBaFwCH8XQLbbUsMZ3DgHl/lrU8laeu48C0OSo6Kd1vv/bXjEpyoSDqiDrPGuq89 RSdnytNL/wi2RoRe6HDQD1KIucgFxYd0f6sRlfbs= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 05F381E07C; Wed, 1 Mar 2017 17:36:37 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Mar 2017 12:36:36 -0500 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.1178.000; Wed, 1 Mar 2017 12:36:36 -0500 From: "Lubashev, Igor" To: Ted Hardie Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO6lru5zftGP0qojvtmiwHwlKF/v3MAgACFdQCAADc4AIAAAEMAgAAIVgD//6/6YIAAWWqA//+t+PA= Date: Wed, 1 Mar 2017 17:36:35 +0000 Message-ID: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.121] Content-Type: multipart/alternative; boundary="_000_f7fce25bba054dbab8fbba3989f45cdfusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "Salz, Rich" , Ian Swett , David Benjamin , Victor Vasiliev , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:36:39 -0000 --_000_f7fce25bba054dbab8fbba3989f45cdfusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQganVzdCBvcGVucyB1cCBtb3JlIGNvcm5lciBjYXNlcyB0byBjb25zaWRlciBhbmQgZG9jdW1l bnQuICBUaGlzIGlzIGJ5IG5vIG1lYW5zIGFuIGltcG9ydGFudCBkZWNpc2lvbiBmb3IgbWUuICBJ IHRlbmQgdG8gcHJlZmVyIGtlZXBpbmcgdGhpbmdzIHNpbXBsZSB3aGVyZSBleHRlbnNpYmlsaXR5 IG5lZWRzIHNlZW0gdmVyeSBsb3cuIEJ1dCBJIHVuZGVyc3RhbmQgb3RoZXJzIG1ha2luZyBkaWZm ZXJlbnQgdHJhZGUtb2Zmcy4NCg0KRnJvbTogVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdt YWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDEsIDIwMTcgMTI6MTUgUE0NClRvOiBM dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkNjOiBJYW4gU3dldHQgPGlhbnN3 ZXR0QGdvb2dsZS5jb20+OyBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjsgVmljdG9yIFZh c2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+ OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgRGF2aWQgQmVuamFt aW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZz4NClN1YmplY3Q6IFJlOiBCaWtlIHNoZWQgd2Fybmlu ZzogaW50ZWdyaXR5IGNoZWNrIGZvciB1bnByb3RlY3RlZCBwYWNrZXRzDQoNCk9uIFdlZCwgTWFy IDEsIDIwMTcgYXQgODo1NyBBTSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208 bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCg0KPiAgKzEgdG8gbWFraW5nIGl0 IHZlcnNpb24gZGVwZW5kZW50DQoNCklhbiwgc28geW91IGFyZSBub3QgdG9vIGNvbmNlcm5lZCB3 aXRoIHRoZSBzZXJ2ZXIgbm90IGJlaW5nIGFibGUgdG8gdGVsbCB3aGV0aGVyIHRoZSB1bmtub3du IHZlcnNpb24gbnVtYmVyIGlzIGR1ZSB0byBhIGNvcnJ1cHRpb24gb3IganVzdCBhbiB1bmtub3du IHZlcnNpb24/IFRoYXQgaW5mb3JtYXRpb24gaW5mb3JtcyB0aGUgc2VydmVyIGJlaGF2aW9yIOKA kyBkcm9wIHRoZSBwYWNrZXQgb3Igc2VuZCBhIHZlcnNpb24gbmVnb3RpYXRpb24gcGFja2V0Lg0K DQoNCklmIHRoZSB2ZXJzaW9uIG51bWJlciBpcyBjb3JydXB0ZWQgYW5kIHRoZSBzZXJ2ZXIgcmVz cG9uZHMgd2l0aCBhIHZlcnNpb24gbmVnb3RpYXRpb24gcGFja2V0LCB3aGF0J3MgdGhlIGhhcm0/ ICBQcmVzdW1hYmx5IHRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIHdpdGggYSBsaXN0IG9mIHN1cHBv cnRlZCB2ZXJzaW9ucyBhbmQgdGhlIGNsaWVudCB3aWxsIHBpY2sgb25lIChwb3RlbnRpYWxseSB0 aGUgc2FtZSBvbmUgaXQgcGlja2VkIHRoZSBmaXJzdCB0aW1lKS4gIEFzIGxvbmcgYXMgY2xpZW50 cyBkb24ndCBhc3N1bWUgdGhleSBoYXZlIHRvIGNoYW5nZSB2ZXJzaW9uIHdoZW4gdGhleSBnZXQg YSB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldCBmcm9tIHRoZSBzZXJ2ZXIsIHRoaXMgc2VlbXMg dG8gYmUgYSByZWFzb25hYmxlIHJlc3VsdC4NCkFtIEkgbWlzc2luZyBzb21ldGhpbmcgdGhhdCBt YWtlcyB0aGlzIHdvcnNlPw0KcmVnYXJkcywNClRlZA0KDQoNCg0KRnJvbTogSWFuIFN3ZXR0IFtt YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpT ZW50OiBXZWRuZXNkYXksIE1hcmNoIDAxLCAyMDE3IDExOjQxIEFNDQpUbzogU2FseiwgUmljaCA8 cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFpLmNvbT4+DQpDYzogVmljdG9yIFZh c2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb208bWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbT4+OyBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgTWFydGlu IFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25A Z21haWwuY29tPj47IERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBjaHJvbWl1bS5vcmc8bWFpbHRv OmRhdmlkYmVuQGNocm9taXVtLm9yZz4+DQpTdWJqZWN0OiBSZTogQmlrZSBzaGVkIHdhcm5pbmc6 IGludGVncml0eSBjaGVjayBmb3IgdW5wcm90ZWN0ZWQgcGFja2V0cw0KDQorMSB0byBtYWtpbmcg aXQgdmVyc2lvbiBkZXBlbmRlbnQgYW5kIEkgYWdyZWUgMzIgYml0cyBpcyBwcm9iYWJseSBwbGVu dHkgdG8gZmlsdGVyIG91dCBpbnRlcm5ldCBqdW5rLg0KDQpPbiBXZWQsIE1hciAxLCAyMDE3IGF0 IDExOjExIEFNLCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2Ft YWkuY29tPj4gd3JvdGU6DQo+ICAoR0hBU0ggaXMgd2hhdCBBRVMtR0NNIHVzZXMuKQ0KDQouLi4g YWFuZCwgSSB3YXMgd3JvbmcuICBPb3BzLg0KDQoNCg== --_000_f7fce25bba054dbab8fbba3989f45cdfusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t Njc5MjAzMzQ1NzcyNTIwMzcwOG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm02NzkyMDMzNDU3NzI1MjAz NzA4bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm02NzkyMDMzNDU3NzI1MjAzNzA4bXNvbGlzdHBhcmFn cmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzY3OTIwMzM0NTc3MjUyMDM3MDhtc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SXQganVzdCBvcGVucyB1cCBtb3JlIGNvcm5l ciBjYXNlcyB0byBjb25zaWRlciBhbmQgZG9jdW1lbnQuICZuYnNwO1RoaXMgaXMgYnkgbm8gbWVh bnMgYW4gaW1wb3J0YW50IGRlY2lzaW9uIGZvciBtZS4mbmJzcDsgSSB0ZW5kIHRvIHByZWZlciBr ZWVwaW5nIHRoaW5ncyBzaW1wbGUgd2hlcmUgZXh0ZW5zaWJpbGl0eQ0KIG5lZWRzIHNlZW0gdmVy eSBsb3cuIEJ1dCBJIHVuZGVyc3RhbmQgb3RoZXJzIG1ha2luZyBkaWZmZXJlbnQgdHJhZGUtb2Zm cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIE1hcmNoIDAxLCAyMDE3IDEyOjE1IFBNPGJyPg0KPGI+VG86PC9iPiBM dWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IFNhbHosIFJpY2ggJmx0O3Jz YWx6QGFrYW1haS5jb20mZ3Q7OyBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnZAZ29vZ2xlLmNv bSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29u ICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyBEYXZpZCBCZW5qYW1pbiAmbHQ7ZGF2 aWRiZW5AY2hyb21pdW0ub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQmlrZSBzaGVk IHdhcm5pbmc6IGludGVncml0eSBjaGVjayBmb3IgdW5wcm90ZWN0ZWQgcGFja2V0czxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDEsIDIwMTcgYXQgODo1 NyBBTSwgTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWku Y29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ibTY3OTIwMzM0NTc3MjUyMDM3MDhtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOw0KPC9zcGFuPiYjNDM7MSB0byBtYWtpbmcg aXQgdmVyc2lvbiBkZXBlbmRlbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWFuLCBzbyB5b3UgYXJlIG5vdCB0b28g Y29uY2VybmVkIHdpdGggdGhlIHNlcnZlciBub3QgYmVpbmcgYWJsZSB0byB0ZWxsIHdoZXRoZXIg dGhlIHVua25vd24gdmVyc2lvbiBudW1iZXIgaXMgZHVlDQogdG8gYSBjb3JydXB0aW9uIG9yIGp1 c3QgYW4gdW5rbm93biB2ZXJzaW9uPyBUaGF0IGluZm9ybWF0aW9uIGluZm9ybXMgdGhlIHNlcnZl ciBiZWhhdmlvciDigJMgZHJvcCB0aGUgcGFja2V0IG9yIHNlbmQgYSB2ZXJzaW9uIG5lZ290aWF0 aW9uIHBhY2tldC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgdGhlIHZlcnNpb24gbnVtYmVyIGlzIGNvcnJ1cHRl ZCBhbmQgdGhlIHNlcnZlciByZXNwb25kcyB3aXRoIGEgdmVyc2lvbiBuZWdvdGlhdGlvbiBwYWNr ZXQsIHdoYXQncyB0aGUgaGFybT8mbmJzcDsgUHJlc3VtYWJseSB0aGUgc2VydmVyIHdpbGwgcmVz cG9uZCB3aXRoIGEgbGlzdCBvZiBzdXBwb3J0ZWQgdmVyc2lvbnMgYW5kIHRoZSBjbGllbnQgd2ls bCBwaWNrIG9uZQ0KIChwb3RlbnRpYWxseSB0aGUgc2FtZSBvbmUgaXQgcGlja2VkIHRoZSBmaXJz dCB0aW1lKS4mbmJzcDsgQXMgbG9uZyBhcyBjbGllbnRzIGRvbid0IGFzc3VtZSB0aGV5IGhhdmUg dG8gY2hhbmdlIHZlcnNpb24gd2hlbiB0aGV5IGdldCBhIHZlcnNpb24gbmVnb3RpYXRpb24gcGFj a2V0IGZyb20gdGhlIHNlcnZlciwgdGhpcyBzZWVtcyB0byBiZSBhIHJlYXNvbmFibGUgcmVzdWx0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbSBJIG1pc3Npbmcgc29tZXRoaW5nIHRoYXQgbWFr ZXMgdGhpcyB3b3JzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IElhbiBTd2V0dCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAwMSwgMjAxNyAxMTo0 MSBBTTxicj4NCjxiPlRvOjwvYj4gU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6 QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWkuY29tPC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+IFZpY3RvciBWYXNpbGlldiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZhc2lsdnZA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsdnZAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBJ RVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KIERhdmlkIEJlbmphbWluICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWRiZW5AY2hy b21pdW0ub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEJpa2Ugc2hlZCB3YXJu aW5nOiBpbnRlZ3JpdHkgY2hlY2sgZm9yIHVucHJvdGVjdGVkIHBhY2tldHM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JiM0MzsxIHRvIG1ha2luZyBpdCB2ZXJzaW9u IGRlcGVuZGVudCBhbmQgSSBhZ3JlZSAzMiBiaXRzIGlzIHByb2JhYmx5IHBsZW50eSB0byBmaWx0 ZXIgb3V0IGludGVybmV0IGp1bmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIE1hciAxLCAyMDE3IGF0IDExOjEx IEFNLCBTYWx6LCBSaWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jm5ic3A7IChHSEFTSCBpcyB3aGF0IEFFUy1HQ00gdXNl cy4pPGJyPg0KPGJyPg0KLi4uIGFhbmQsIEkgd2FzIHdyb25nLiZuYnNwOyBPb3BzLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f7fce25bba054dbab8fbba3989f45cdfusma1exdag1mb5msgcorpak_-- From nobody Wed Mar 1 10:00:59 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6C129621 for ; Wed, 1 Mar 2017 10:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cg2zmNshhu12 for ; Wed, 1 Mar 2017 10:00:55 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 9999D1294A9 for ; Wed, 1 Mar 2017 10:00:55 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id s15so16076697ywg.0 for ; Wed, 01 Mar 2017 10:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hPk+s2Nxl93ezVyBW/dapqlIAyZ1RLaOAJgc2+FQAk4=; b=L4dAjvcocO/IptpUANbzA17gGDKLCCRwro9renNo5vO0MAmRPTiWipfLigM0Wha+h+ im8NXJRs5oStAOxA2UEUc8rcGuuLq7SQa+EfQdIbjcs7x7A23wVCOfjqRidrIZuLAzJ7 Dkjo8jDGy2vs0e2pXpUlCUsuNrxIUvl84aZLqyfRgxPpOL8MlMm0vj2wX+Tz06aN72Xc RYF/aVCoYX77FYELexwS5+DYQ1468fwZDi/oPsyIKmdVZciEqwutStcfSNT+F/w+TGcr Xt6ueMfnb/CbjpApAWwmdBjp7O9kGeqPkz5eSQjNNKttWb90o88RrxmYB1ChCjBAoGkx A8HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hPk+s2Nxl93ezVyBW/dapqlIAyZ1RLaOAJgc2+FQAk4=; b=EEIz1SNs+fFSj9D7BkM4TiFsmSakJTmUMCvBEaeckmPCNV8sHDJGOwVtcN34OB6a72 rQ4sd1lrTH28101axI68RkjrDwFhRZJYeQSMoDlNsuh3HiCctM1qGagC2qiZk+VahJir gtFLuM/BXKFMwiNbzolrXeVlF6w+OJmB8xxfspywIeAPFoT9BBm0K8MvNH0tMmksydIA VFBnZevHo6+5ASAm+uOFy67SnDYLEqbI0JMkBRaEDn30FM1Mg1eQZNwu9Ud+S348Akrv pjIE28a+6c1q3882m71HDnOf+RHsrLj+AQX2CDOIPvcVmV683oFuWWEtxN9l532+OUHh cOKA== X-Gm-Message-State: AMke39n6k4vkmKJZTIRiFr7FkbFemOmE//gmZrDRi60FHwsoWzV4wE9JoZEEwOsEgCgkT8IWxfl6d5hlRuT5TQps X-Received: by 10.129.125.5 with SMTP id y5mr3170228ywc.120.1488391254564; Wed, 01 Mar 2017 10:00:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.50.139 with HTTP; Wed, 1 Mar 2017 10:00:33 -0800 (PST) In-Reply-To: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ian Swett Date: Wed, 1 Mar 2017 13:00:33 -0500 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a11493644045df30549af18ad Archived-At: Cc: Ted Hardie , "Salz, Rich" , David Benjamin , Victor Vasiliev , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:00:57 -0000 --001a11493644045df30549af18ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the logic is still fairly simple: 1) Look at version, if you support it, check the hash and move forward. 2) If you don't support the version, don't check the hash and sent a version negotiation packet. #2 would change to "do check the hash" if we made the hash fixed. On Wed, Mar 1, 2017 at 12:36 PM, Lubashev, Igor wrote= : > It just opens up more corner cases to consider and document. This is by > no means an important decision for me. I tend to prefer keeping things > simple where extensibility needs seem very low. But I understand others > making different trade-offs. > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Wednesday, March 01, 2017 12:15 PM > *To:* Lubashev, Igor > *Cc:* Ian Swett ; Salz, Rich ; > Victor Vasiliev ; IETF QUIC WG ; > Martin Thomson ; David Benjamin < > davidben@chromium.org> > *Subject:* Re: Bike shed warning: integrity check for unprotected packets > > > > On Wed, Mar 1, 2017 at 8:57 AM, Lubashev, Igor > wrote: > > =C3=98 +1 to making it version dependent > > > > Ian, so you are not too concerned with the server not being able to tell > whether the unknown version number is due to a corruption or just an > unknown version? That information informs the server behavior =E2=80=93 d= rop the > packet or send a version negotiation packet. > > > > > > If the version number is corrupted and the server responds with a version > negotiation packet, what's the harm? Presumably the server will respond > with a list of supported versions and the client will pick one (potential= ly > the same one it picked the first time). As long as clients don't assume > they have to change version when they get a version negotiation packet fr= om > the server, this seems to be a reasonable result. > > Am I missing something that makes this worse? > > regards, > > Ted > > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Wednesday, March 01, 2017 11:41 AM > *To:* Salz, Rich > *Cc:* Victor Vasiliev ; IETF QUIC WG ; > Martin Thomson ; David Benjamin < > davidben@chromium.org> > *Subject:* Re: Bike shed warning: integrity check for unprotected packets > > > > +1 to making it version dependent and I agree 32 bits is probably plenty > to filter out internet junk. > > > > On Wed, Mar 1, 2017 at 11:11 AM, Salz, Rich wrote: > > > (GHASH is what AES-GCM uses.) > > ... aand, I was wrong. Oops. > > > > > --001a11493644045df30549af18ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the logic is still fairly simple:
1) Look at v= ersion, if you support it, check the hash and move forward.
2) If= you don't support the version, don't check the hash and sent a ver= sion negotiation packet.

#2 would change to "= do check the hash" if we made the hash fixed.



= On Wed, Mar 1, 2017 at 12:36 PM, Lubashev, Igor <ilubashe@akamai.com= > wrote:

It just opens up more corner cases to consider and = document.=C2=A0 This is by no means an important decision for me.=C2=A0 I t= end to prefer keeping things simple where extensibility needs seem very low. But I understand others making different trade-offs.<= u>

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Wednesday, March 01, 2017 12:15 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Ian Swett <ianswett@google.com>; Salz, Rich <rsalz@akamai.com>; Victor Vasiliev <= ;vasilvv@google.com= >; IETF QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; David Ben= jamin <davidb= en@chromium.org>
Subject: Re: Bike shed warning: integrity check for unprotected pack= ets

=C2=A0

On Wed, Mar 1, 2017 at 8:57 AM, Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:

=C3=98=C2=A0 +1 to making it version dependent

=C2=A0

Ian, so you are not too concerned with the server n= ot being able to tell whether the unknown version number is due to a corruption or just an unknown version? That information informs the s= erver behavior =E2=80=93 drop the packet or send a version negotiation pack= et.

=C2=A0

=C2=A0

If the version number= is corrupted and the server responds with a version negotiation packet, wh= at's the harm?=C2=A0 Presumably the server will respond with a list of = supported versions and the client will pick one (potentially the same one it picked the first time).=C2=A0 As long as clie= nts don't assume they have to change version when they get a version ne= gotiation packet from the server, this seems to be a reasonable result.<= /u>

Am I missing somethin= g that makes this worse?

regards,

Ted


=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Wednesday, March 01, 2017 11:41 AM
To: Salz, Rich <rsalz@akamai.com>
Cc: Victor Vasiliev <vasilvv@google.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <= martin.thomso= n@gmail.com>; David Benjamin <davidben@chromium.org>
Subject: Re: Bike shed warning: integrity check for unprotected pack= ets

=C2=A0

+1 to making it version dependent and I agree 32 bit= s is probably plenty to filter out internet junk.

=C2=A0

On Wed, Mar 1, 2017 at 11:11 AM, Salz, Rich <rsalz@akamai.com> = wrote:

>=C2=A0 (GHASH is what AES-GCM uses.)

... aand, I was wrong.=C2=A0 Oops.

=C2=A0

=C2=A0


--001a11493644045df30549af18ad-- From nobody Wed Mar 1 10:56:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6307129855 for ; Wed, 1 Mar 2017 10:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA4NRNLiSEDs for ; Wed, 1 Mar 2017 10:56:00 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6DB12966A for ; Wed, 1 Mar 2017 10:56:00 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u188so85725800qkc.2 for ; Wed, 01 Mar 2017 10:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qnwPPfFkCtpaJcbWt4BTiWuehYDlHF4nbAjuvsnNUns=; b=p7o5s/nEpjuF4vslAQ+8qnMKtyPAL+Xr8Kz6gd0WdedGUezO/N8qjhuBO7SPEfnLF6 E6PDaZxugN7WnzRw7q7dBibAfvZZfz37X2FHWZAIokd3leEzJvhpJcaDCRdYMYFOpF8V Ud2octBcF54byAA4iSCT/XmevsBif7WobYR1M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qnwPPfFkCtpaJcbWt4BTiWuehYDlHF4nbAjuvsnNUns=; b=CEpR/hiPDe29cf9rGDt9T+DqJod9yE4dlvCCvjAkxk3ed6hh8qLBq7b5jmU5pkTk8h 1+u0ZjHSxukw3Q5CBDMJz9p7cnvVxBa/QSFaySNYU8Sh4RdFUIakibWlbhSurYbMKn1N Bc0vCk/bKzB7bU4++VgbQMwM1JQv/PFaOfMHZzJpqqq8PTbfHiWEUe7WUA5evDlXtpwl bzgvXi5VEr3HmkgaP04wthHaxaKtqikTMllW9ebJVwwSITAekHCQK1YwS5sMCkLy5Jhr sgiPeaD4tp7WzRxWRQKotlsTNjqqI2/+dS1Eq8vZmYnoykWybHyniO4Akm+QjYsO78sc 5Kig== X-Gm-Message-State: AMke39m9z3WszEiImrxkGJBG1/IWLtRB8pl5Y+Plw/uk9mpbFcLc+9pqoagDqPBtWTKX3kdIQsPVOa9w6Y0feQ== X-Received: by 10.237.46.129 with SMTP id k1mr13214533qtd.135.1488394559342; Wed, 01 Mar 2017 10:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Wed, 1 Mar 2017 10:55:58 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: <00308ab6b0ac4e31bb9ec0c1fa1c22c3@usma1ex-dag1mb5.msg.corp.akamai.com> References: <00308ab6b0ac4e31bb9ec0c1fa1c22c3@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kyle Rose Date: Wed, 1 Mar 2017 13:55:58 -0500 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=94eb2c065a60ff0e090549afdc75 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Kazuho Oku , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 18:56:04 -0000 --94eb2c065a60ff0e090549afdc75 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2017 at 8:07 PM, Lubashev, Igor wrote: > -----Original Message----- > >From: Martin Thomson [mailto:martin.thomson@gmail.com] > > > >> How would a server know which server to redirect this packet to? > > > > I assume that the server would have more state than the load balancer. > > Unfortunately, this means the server would need not only its own state but > also the state of all of its peers behind that load balancer. > Not necessarily. It seems like we're trying to mash two requirements into one mechanism. The two requirements are: (1) Some cookie issued by the server farm to offload minimal state for the load balancer so it doesn't have to track every connection attempt and established connection (2) A connection ID that the server needs in plaintext to find connection state across 5-tuple changes, but that must actually be a set of unlinkable connection IDs or a mechanism for generating unlinkable connection IDs for privacy from observers If the cookies are stable identifiers mostly bijective with actual servers, and if there are many more servers than clients, then it doesn't reveal a lot of information to an observer trying to correlate client IPs: it's basically equivalent to the server IP in terms of information. (It's N times worse than a single load-balanced IP fronting N servers.) One advantage of this approach is that the connection ID is really only needed when establishing a new flow: otherwise, the server just uses 5-tuple to index into the connection context. If the client knows it's changing flows or adding a new flow, it can send an unused connection ID to the server to link that new flow into the connection context; if it doesn't know (e.g., NAT rebinding), the server can drop alien packets until the client decides to re-establish the flow with an unused connection ID. (There could also be some signal from the server to the client that "you are alien", but authentication with PKC would be expensive.) One disadvantage is that you have two conflicting forces around the size of this cookie: limiting the size of this space to prevent servers from issuing unique plaintext client identifiers, vs. keeping the space large and sparse so an attacker can't walk it. There's no way to really enforce what the server puts here: we can only provide guidance that this cookie space is for server identification *only*, and that care must be taken to make sure it does not enable tracking of individual clients. In any event, this is no worse from that perspective than an arbitrary server-chosen connection ID that appears in every single packet and is subject to the problem of flow changes unknown to the client. There's also a general problem with load balancers: without a pre-established cookie, the client is probably limited to a single datagram for 0-RTT unless the load balancing algorithm is a function of connection information that doesn't vary across 0-RTT packets from a single connection. Load balancers probably want to balance load, not randomly assign. As with so many of the privacy discussions on transport topics, I don't really have a strong opinion about whether this is a good idea or not: preventing every kind of client tracking at this layer is probably futile. I do, however, think it's important to discuss the entire space of alternatives and pick something that actually achieves a balance of privacy, security, and operability that users will for the most part be satisfied with. Kyle --94eb2c065a60ff0e090549afdc75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2017 at 8:07 PM, Lubashev, Igor <= ;ilubashe@akamai.c= om> wrote:
-----Original Message-----
>From: Martin Thomson [mailto:martin.thomson@gmail.com]
>
>> How would a server know which server= to redirect this packet to?
>
> I assume that the server would have more state than the load balancer.=

Unfortunately, this means the server would need not only its own sta= te but also the state of all of its peers behind that load balancer.

Not necessarily. It= seems like we're trying to mash two requirements into one mechanism. T= he two requirements are:

(1) Some c= ookie issued by the server farm to offload minimal state for the load balan= cer so it doesn't have to track every connection attempt and establishe= d connection
(2) A connection ID that t= he server needs in plaintext to find connection state across 5-tuple change= s, but that must actually be a set of unlinkable connection IDs or a mechan= ism for generating unlinkable connection IDs for privacy from observers
=
If the cookies are stable identifiers = mostly bijective with actual servers, and if there are many more servers th= an clients, then it doesn't reveal a lot of information to an observer = trying to correlate client IPs: it's basically equivalent to the server= IP in terms of information. (It's N times worse than a single load-bal= anced IP fronting N servers.)

One a= dvantage of this approach is that the connection ID is really only needed w= hen establishing a new flow: otherwise, the server just uses 5-tuple to ind= ex into the connection context. If the client knows it's changing flows= or adding a new flow, it can send an unused connection ID to the server to= link that new flow into the connection context; if it doesn't know (e.= g., NAT rebinding), the server can drop alien packets until the client deci= des to re-establish the flow with an unused connection ID. (There could als= o be some signal from the server to the client that "you are alien&quo= t;, but authentication with PKC would be expensive.)

One disadvantage is that you have two conflicting forces = around the size of this cookie: limiting the size of this space to prevent = servers from issuing unique plaintext client identifiers, vs. keeping the s= pace large and sparse so an attacker can't walk it. There's no way = to really enforce what the server puts here: we can only provide guidance t= hat this cookie space is for server identification *only*, and that care mu= st be taken to make sure it does not enable tracking of individual clients.= In any event, this is no worse from that perspective than an arbitrary ser= ver-chosen connection ID that appears in every single packet and is subject= to the problem of flow changes unknown to the client.

There&#= 39;s also a general problem with load balancers: without a pre-established = cookie, the client is probably limited to a single datagram for 0-RTT unles= s the load balancing algorithm is a function of connection information that= doesn't vary across 0-RTT packets from a single connection. Load balan= cers probably want to balance load, not randomly assign.

As with so = many of the privacy discussions on transport topics, I don't really hav= e a strong opinion about whether this is a good idea or not: preventing eve= ry kind of client tracking at this layer is probably futile. I do, however,= think it's important to discuss the entire space of alternatives and p= ick something that actually achieves a balance of privacy, security, and op= erability that users will for the most part be satisfied with.
Kyle

--94eb2c065a60ff0e090549afdc75-- From nobody Wed Mar 1 13:27:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C625B1296DF for ; Wed, 1 Mar 2017 13:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 idFsm00kXhuh for ; Wed, 1 Mar 2017 13:27:47 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9601296CE for ; Wed, 1 Mar 2017 13:27:47 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u188so93033445qkc.2 for ; Wed, 01 Mar 2017 13:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j/+jNmLVjzoOrtTDXos7EOsmx7CfUp48zV7H1LM6chI=; b=rtJIDoUXXNkcpaImdbKjhaB82UtUktGlF2eTqOAKhsDgKae0bjPWwJdJtBXM9cvx5L abuSOde/E4CR9s9LDKXxE98JuUdW+V0gsAPM6TVUnPt73HD8B3NTZggVuhfiA2/seKL7 6dDeCg7ceUwtsxOR6Qp+kx+zVJmReaiqq8u7gLYDjiosYy9u2uERpdQgdi6rfYObTRqb q3wnmc3fZu5+Igk13X6YLdmDAga0zk4hXGMsyN/LwRC4eAbNT3qSkK0gvOORZ4YWq8GV lwBRO0ZUQ5029zTMPZgnU1CUeC4OT1UBemqhFbK6U4ddAU/gP++GP+8o15Fynw2dPSIf QgFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j/+jNmLVjzoOrtTDXos7EOsmx7CfUp48zV7H1LM6chI=; b=bhJDMCxRtNDPekfqeyXfex0A3U+KXyk9TC9p8HFZ4tgJbfZHcDEfrajMmooJJ27vfj ScdjH4owoLACjp/GL94qn4o88B1uA+kHBSkIF0SLZUGQIQ46djs0yf9igwu71Ij63ZkH zbH0fTNBn3c04H89h8PK7cKg5eTJxuq1T+bhKFtz79dONjMGo3Q1Nbc5wtWewCfauocr 2D9YqyhQoqQPsWWyfuqe3L3nUdR+X8p/o/uf/K4WGUmWX6F+lV0mPhY+eMgEW/MhYiyK MP/0Matb4Mg29gRxLjLSWPpsszi8AF9up6x7Mz54mW9nBDjMI4qNXYAE7ppYKMUx/xrX 9bPg== X-Gm-Message-State: AMke39nHVmz6qcxt8ouEQhSGuMhbxHXqbVyBtxwi7KxItKwuICYyxU3TTBAbbgRkA4+OOWzl5JDuttqLLFMJgA== X-Received: by 10.200.3.214 with SMTP id z22mr13735803qtg.3.1488403666741; Wed, 01 Mar 2017 13:27:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 13:27:46 -0800 (PST) In-Reply-To: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 2 Mar 2017 08:27:46 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 21:27:49 -0000 On 1 March 2017 at 23:52, Salz, Rich wrote: > So you want something that can be done in constant-time without data-dependant side-channels? The key would be public, the data is going to be also. That's not a requirement. From nobody Wed Mar 1 13:30:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0A71296B5 for ; Wed, 1 Mar 2017 13:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j69u25hsllh for ; Wed, 1 Mar 2017 13:30:39 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CAE1296AC for ; Wed, 1 Mar 2017 13:30:39 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n127so93041225qkf.0 for ; Wed, 01 Mar 2017 13:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CJjY1H4E6apOy181sodx3oVIaOiqEU9nb0vy/z7yfhc=; b=gtVRUid9+htHICpkmoW2/G4vztip5kHTOVl9Cq72I1IncVeCk4GYOXf65ZpRRnPBXy ryyye2/Lsr0G2Bt2mEACzgUb248ZEt/fzUS0m7SsJn+OrhqNlK8xj2PJQSn1IcFjxRfx wHFz8BpOThojJvR2A1yPZVZRW00ZoVqgp+nRzhuGfy0V3yybJ8kXUbuahWdr2Kn6NzzJ sATA7nroYCQZ3IXxDV3sIfbKj9LWpvANjJlQpUI8yTI1FjCJF2xSdb0uc3VrI/dimHJ4 mTie0lfhiL+RWhnQia/LLpAN6OdEGiyekm9XncjiHII/vb1GaeAZTiW2sDfKNiopQx8a lANA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CJjY1H4E6apOy181sodx3oVIaOiqEU9nb0vy/z7yfhc=; b=p78sEAcRxWVy+68kosgaY1zxh6syXL8uBD0lNqJ8hR+duXcYdZGUlLmc+Divsksf0s 5BiggIHPV/DBcXp/zDl1C5RWGnGoQwzrr1w6l5uEAlV+UsZptPOXKhyt2FXgOR2gHUi2 PTqf4xdQjvn1OdjoFKPraaI2eJjDoam5fE+hEPK/P998sNhniU3aHKkzjm0K+Y7LL/i+ qvf65ZXFuKekDdbnlinFCtxVBU7FRHGfy4/lG0cIuMDuvlkrcbh1BRGH0DEDUHKt8ozq 2kA1t26f5NhMFItWRN+ZRjtmGX4nYXqvOQ6tA1TKvS4xb6X9e59nisfubCvJehyZASec llXg== X-Gm-Message-State: AMke39nucMYJI7uIRCG7YMUxpEK2hkOS8g2ahZIiAKTR9khQI+eJT/grE/Oz/MYfcQxTxhB28dkVZYFuIHVs3A== X-Received: by 10.200.39.200 with SMTP id x8mr13021436qtx.159.1488403838320; Wed, 01 Mar 2017 13:30:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 13:30:37 -0800 (PST) In-Reply-To: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 2 Mar 2017 08:30:37 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Salz, Rich" , Ian Swett , "Lubashev, Igor" , David Benjamin , Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 21:30:40 -0000 On 2 March 2017 at 04:14, Ted Hardie wrote: > Presumably the server will respond with a list of supported versions and the > client will pick one (potentially the same one it picked the first time). Actually, I think that the right approach here is to ignore a version negotiation packet that includes your already-chosen version. The client can just keep retransmitting it's initial packet. From nobody Wed Mar 1 13:55:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE61294AB for ; Wed, 1 Mar 2017 13:55:42 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fYFfNsHUUx9W for ; Wed, 1 Mar 2017 13:55:40 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E0B1293D6 for ; Wed, 1 Mar 2017 13:55:39 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id n127so94103843qkf.0 for ; Wed, 01 Mar 2017 13:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kKU0PPECwdsMeU4a7Ubvrv0SaO/zHFuoD7QqY0Ozq3E=; b=NhGT+LS/ePV7Wbe8ymy+/fHzBc9hT9334ruHHBNVb8c0GLxPc+DpAd7iRny3uUhIU9 XEMCMI/AVZp9Opx+Ke3X7p4d6NpIwvUfNuBM75vtrjPjLhb1VEimptzRLJKM7MWIw4E9 IwT8GMOpG8xtDUhE+KS9vmmugU3aVmLMG+usTqdvfAp39yZP2hzklHUWH2OqtSf9eoXM ISJJeTr4vKhdGYeDoS2Ljdj6c2fvCBKqpp+EQendWQuTJ6V3rx5fFOlxp6P43QwxqjYj yYSGWf6G3UycAuwEo47z1EvCXlq/+dtrD2Tc6/b0Yt94bulbXwmGxqVaL43I5vteH9gb 4Ung== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kKU0PPECwdsMeU4a7Ubvrv0SaO/zHFuoD7QqY0Ozq3E=; b=Y0RLvmfEPPkWgqd6qrVmhf4ARdgjHoBHRXc7AS6G61IZ4fj6QA6nqXuegg8vXR3ESk 9V5QF1FyrsKMKXHMCOcxCqj907PRM1n0RlD6orMZ890QZhxwNSUDYA+WXJ5RJ8xnHIcw 2FXgT1ubF3O6cZVwFlUZSN/h47CiewXaeuAPBYCIOhCOOVpLymRBIvbXO13zQe6fWiQB 6oQyPWoYAhNkzYu1lmPflDumLi4WoPKrGOSw0Z5eMRi2jUYjHIZjShmzy7apIDi9Qshb LCu9W+1DaFpRZ4umZ7Taut7Ql3R4bSZfalv/ix84sAHs3Cmxmf2P89C2i8TwD1Z6/Hrn xRUQ== X-Gm-Message-State: AMke39l9TND+K0Nkr4quucTqnLix05bHqyRZvqPqSQ+bQHxXh/z6SfIByaBFY+dFqNeAT4WkVum2jorOR6JWTSbs X-Received: by 10.55.71.149 with SMTP id u143mr13560254qka.81.1488405339029; Wed, 01 Mar 2017 13:55:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.47.4 with HTTP; Wed, 1 Mar 2017 13:55:38 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Wed, 1 Mar 2017 16:55:38 -0500 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114a816084287d0549b25f6c Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 21:55:42 -0000 --001a114a816084287d0549b25f6c Content-Type: text/plain; charset=UTF-8 On Wed, Mar 1, 2017 at 12:57 AM, Martin Thomson wrote: > On 1 March 2017 at 15:55, Victor Vasiliev wrote: > > I am not entirely clear -- are you suggesting to use CRC-32 (as defined > in > > V.42), or CRC-32Cc (as used in SCTP)? > > My mistake, I intended to state CRC32, the SCTP thing was in error > (it's a different polynomial and I failed to recognize that). > > > My personal preference here lies with the algorithms which can be > > implemented on a typical CPU without a lookup table -- that is to say, > not > > CRC or GHASH. GHASH might be fine since it's MTI for TLS anyways. > > You don't think that support in recent processors for CRC32 > instructions is enough to meet your requirement? > As far as I recall, SSE 4.2 uses CRC-32C and not CRC-32. One can use CLMUL for this, but it's not as widespread as SSE 4.2. On a second reflection, lookup tables are not that much of a problem as a polyfill. We won't be able to find a solution which works well for all embedded applications, because some of them would be very unhappy with lookup tables (required to polyfill CRC32 and GHASH), while others will be allergic to any form of integer multiplication (required for FNV1a and Poly1305). -- Victor. --001a114a816084287d0549b25f6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 1, 2017 at 12:57 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 1 March 2017 at 15:55, Victor Vasiliev <<= a href=3D"mailto:vasilvv@google.com">vasilvv@google.com> wrote:
> I am not entirely clear -- are you suggesting to use CRC-32 (as define= d in
> V.42), or CRC-32Cc (as used in SCTP)?

My mistake, I intended to state CRC32, the SCTP thing was in error (it's a different polynomial and I failed to recognize that).

> My personal preference here lies with the algorithms which can be
> implemented on a typical CPU without a lookup table -- that is to say,= not
> CRC or GHASH.=C2=A0 GHASH might be fine since it's MTI for TLS any= ways.

You don't think that support in recent processors for CRC32
instructions is enough to meet your requirement?

As far as I recall,= SSE 4.2 uses CRC-32C and not CRC-32.=C2=A0 One can use CLMUL
for this, but it's not as widespread as SSE 4.2.

On = a second reflection, lookup tables are not that much of a problem as a
polyfill.=C2=A0 We won't be able to find a = solution which works well for all
embedded = applications, because some of them would be very unhappy with lookup
<= div class=3D"gmail_extra">tables (required to polyfill CRC32 and GHASH), wh= ile others will be allergic to
any form of = integer multiplication (required for FNV1a and Poly1305).
=

=C2= =A0 -- Victor.
--001a114a816084287d0549b25f6c-- From nobody Wed Mar 1 14:39:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBC3128B37 for ; Wed, 1 Mar 2017 14:39:06 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 IeP2p1U1ZUx5 for ; Wed, 1 Mar 2017 14:39:05 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id DC1CD1293FF for ; Wed, 1 Mar 2017 14:39:04 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6133116C866; Wed, 1 Mar 2017 22:39:04 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 4ADEF16C912; Wed, 1 Mar 2017 22:39:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488407944; bh=yoPqEFXia/CVwf1ajUCXWurDoD1IVaevKshx5cXg1UA=; l=1708; h=From:To:CC:Date:References:In-Reply-To:From; b=mDHBm4ownzQoarKozr/R+t4OSyZbvGtsiSgYUKpFJ0hzIxVf5OZFMWyZdAifhH71B +YZoBVusyIeIv0DJENxWGvcECMqrhWG/PjrWxRJRYc1zKwwVtT88p8CWqwiGJp3Vb8 KlYA5pHeCQcOcR55hOiNidJsXQmw2mP5rttstURU= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 242A51E07C; Wed, 1 Mar 2017 22:39:04 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 1 Mar 2017 17:39:03 -0500 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.1178.000; Wed, 1 Mar 2017 17:39:03 -0500 From: "Lubashev, Igor" To: Martin Thomson , Ted Hardie Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO6lru5zftGP0qojvtmiwHwlKF/v3MAgACFdQCAADc4AIAAAEMAgAAIVgD//6/6YIAAWWqAgABHb4D//71EEA== Date: Wed, 1 Mar 2017 22:39:02 +0000 Message-ID: <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Salz, Rich" , Ian Swett , IETF QUIC WG , David Benjamin , Victor Vasiliev X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 22:39:06 -0000 PiBUaGUgY2xpZW50IGNhbiBqdXN0IGtlZXAgcmV0cmFuc21pdHRpbmcgaXQncyBpbml0aWFsIHBh Y2tldC4NCg0KVGhhdCBtYXkgYmUgYSBwcm9ibGVtLCBpZiB0aGUgcGF0aCBjYXVzZXMgYSBwZXJz aXN0ZW50LCBkZXRlcm1pbmlzdGljIGNvcnJ1cHRpb24gKGEgYmFkIGxpbmUgY2FyZCwgZXRjIC0t IHRoZXNlIHRoaW5ncyBoYXBwZW4pLiAgV291bGQgdGhlIHNlcnZlciB0aGVuIHJlcGx5IHdpdGgg YSB2ZXJzaW9ucyBuZWdvdGlhdGlvbiBwYWNrZXQgYWdhaW4/IEFuZCB0aGUgY2xpZW50IHJldHJh bnNtaXQgYWdhaW4/ICBUaGlzIGlzIHRoZSBraW5kIG9mIGNvbXBsZXhpdHkgYW5kIGNvcm5lciBj YXNlcyBJIHdhcyB3b3JyaWVkIGFib3V0Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29t XSANClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDEsIDIwMTcgNDozMSBQTQ0KVG86IFRlZCBIYXJk aWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWth bWFpLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IFNhbHosIFJpY2ggPHJz YWx6QGFrYW1haS5jb20+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbT47IElF VEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IERhdmlkIEJlbmphbWluIDxkYXZpZGJlbkBjaHJv bWl1bS5vcmc+DQpTdWJqZWN0OiBSZTogQmlrZSBzaGVkIHdhcm5pbmc6IGludGVncml0eSBjaGVj ayBmb3IgdW5wcm90ZWN0ZWQgcGFja2V0cw0KDQpPbiAyIE1hcmNoIDIwMTcgYXQgMDQ6MTQsIFRl ZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IFByZXN1bWFibHkgdGhlIHNl cnZlciB3aWxsIHJlc3BvbmQgd2l0aCBhIGxpc3Qgb2Ygc3VwcG9ydGVkIHZlcnNpb25zIA0KPiBh bmQgdGhlIGNsaWVudCB3aWxsIHBpY2sgb25lIChwb3RlbnRpYWxseSB0aGUgc2FtZSBvbmUgaXQg cGlja2VkIHRoZSBmaXJzdCB0aW1lKS4NCg0KQWN0dWFsbHksIEkgdGhpbmsgdGhhdCB0aGUgcmln aHQgYXBwcm9hY2ggaGVyZSBpcyB0byBpZ25vcmUgYSB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tl dCB0aGF0IGluY2x1ZGVzIHlvdXIgYWxyZWFkeS1jaG9zZW4gdmVyc2lvbi4gIFRoZSBjbGllbnQg Y2FuIGp1c3Qga2VlcCByZXRyYW5zbWl0dGluZyBpdCdzIGluaXRpYWwgcGFja2V0Lg0K From nobody Wed Mar 1 14:54:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B21129739 for ; Wed, 1 Mar 2017 14:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 Mk3mPXnJND2n for ; Wed, 1 Mar 2017 14:54:25 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D353127735 for ; Wed, 1 Mar 2017 14:54:25 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id u188so96459666qkc.2 for ; Wed, 01 Mar 2017 14:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F9y922jv8uGw3tl4GaEDcFCHOq9sI5zIZq7ShBz9wR4=; b=PUvUQ8Fd/F9n4AgYF5Qz8ayV/I9BPmE/v5i2J+C0C8ZMfrCB0uKQWv2jR8WLB3JDSS soDqIQN/mNVZxSGtUH6P9FoYF0n65/t2L2f0x1oGirDtrA4UCSLwUKVm48TQ1spPX0VY kwLzA7rWSSR8YhtmBTZObko+PIwmP4a05n/ouNhxy+S3q2TxheZBwLIYteNZX213GF58 ZTKS1lO5K6BXRdJl1Xnvo/FnrmT2P7lUSkbovqEnxKwjMuLL4Ba7+Zbijy7NeCEZuDoc ikP9T/Pv/cKmmJov4MxB4QPqnIw3XjV75tbWvDIof80rAxvnMWVJkMXOo7SwiMso6rg3 7Zgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F9y922jv8uGw3tl4GaEDcFCHOq9sI5zIZq7ShBz9wR4=; b=OVXOAjWaZXW0wALmX/iLs7V9u74QdCfagggQUa0Xuma4t3gC7gmKcu2XUACTgOhi1f M9IsLjAzd6DWpYkGYATI8XZI6CodTMRacyt9823z6I3kaDRmMhbX1p56VrMVmFtyO8VX nLIR15hcVIGNVlvfZaS9ddhLoWUY6kgKVbeCvGfBMV7Lf5N/h1GhVu9mnyt8/90ShTsW ucShZ45Klxi4CHi6JB5OjkIKXbPF2yXB765ekrAUMm5MFBgvafYKiF49knfyNIw7s3s6 fMA2rt37rEnWihoqaKnn84mtGIuPRQ3uI5RLz3a3eC3WW6rkKZfGk+B9f1WvJlCEfIob Mp+A== X-Gm-Message-State: AMke39nekldbkoJvWAXk1DTy4IV57KDEKjnS3IRPODk+K1JJd9kmvYNzjz3SkrF5nqI5p53djAJcxXP0mtsvQA== X-Received: by 10.233.216.68 with SMTP id u65mr13026661qkf.68.1488408864553; Wed, 01 Mar 2017 14:54:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 14:54:23 -0800 (PST) In-Reply-To: <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 2 Mar 2017 09:54:23 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ted Hardie , "Salz, Rich" , Ian Swett , David Benjamin , Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 22:54:27 -0000 On 2 March 2017 at 09:39, Lubashev, Igor wrote: > > That may be a problem, if the path causes a persistent, deterministic cor= ruption (a bad line card, etc -- these things happen). Would the server th= en reply with a versions negotiation packet again? And the client retransmi= t again? This is the kind of complexity and corner cases I was worried abo= ut. If the path is doing that, then I suspect that QUIC is not going to work. Arguably the path is busted and learning this is the first step in fixing it. From nobody Wed Mar 1 15:02:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CC129952 for ; Wed, 1 Mar 2017 15:02:07 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 J0JrnTX3EQMG for ; Wed, 1 Mar 2017 15:02:06 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 85056129607 for ; Wed, 1 Mar 2017 15:02:06 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F17B1200013; Wed, 1 Mar 2017 23:02:05 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id D18D820000C; Wed, 1 Mar 2017 23:02:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488409325; bh=/QDJhxp7tjZsbCBsK+AUc1XhyNN4ZryowxK5hpBIZAk=; l=2608; h=From:To:CC:Date:References:In-Reply-To:From; b=iLyz9P3/lkOkWt+rARz+nPI252ZWjKvaKyshJzNXQ36EfIWCgs/GxSSlAZt9QK2+P S77DHPmfTyviOyO1yUAVZKwW0amHVc3UMJdEKJy/ZWL0IWoDEhdL1lGDQ86UtzEa7h ySCmCh6pc9stsl01nM6I8B1+Ux5oCb7H0xJ11U8E= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B2FCA1E07C; Wed, 1 Mar 2017 23:02:05 +0000 (GMT) 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.1178.4; Wed, 1 Mar 2017 18:02:05 -0500 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.1178.000; Wed, 1 Mar 2017 18:02:05 -0500 From: "Lubashev, Igor" To: Martin Thomson Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO6lru5zftGP0qojvtmiwHwlKF/v3MAgACFdQCAADc4AIAAAEMAgAAIVgD//6/6YIAAWWqAgABHb4D//71EEIAAWiOA//+sX1A= Date: Wed, 1 Mar 2017 23:02:04 +0000 Message-ID: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ted Hardie , "Salz, Rich" , Ian Swett , David Benjamin , Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:02:08 -0000 RnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0K DQo+Pj4gVGhlIGNsaWVudCBjYW4ganVzdCBrZWVwIHJldHJhbnNtaXR0aW5nIGl0J3MgaW5pdGlh bCBwYWNrZXQuDQo+Pg0KPj4gVGhhdCBtYXkgYmUgYSBwcm9ibGVtLCBpZiB0aGUgcGF0aCBjYXVz ZXMgYSBwZXJzaXN0ZW50LCBkZXRlcm1pbmlzdGljIGNvcnJ1cHRpb24gKGEgYmFkIGxpbmUgY2Fy ZCwgZXRjIC0tIHRoZXNlIHRoaW5ncyBoYXBwZW4pLg0KPj4gV291bGQgdGhlIHNlcnZlciB0aGVu IHJlcGx5IHdpdGggYSB2ZXJzaW9ucyBuZWdvdGlhdGlvbiBwYWNrZXQgYWdhaW4/IEFuZCB0aGUg Y2xpZW50IHJldHJhbnNtaXQgYWdhaW4/DQo+PiBUaGlzIGlzIHRoZSBraW5kIG9mIGNvbXBsZXhp dHkgYW5kIGNvcm5lciBjYXNlcyBJIHdhcyB3b3JyaWVkIGFib3V0Lg0KPg0KPiBJZiB0aGUgcGF0 aCBpcyBkb2luZyB0aGF0LCB0aGVuIEkgc3VzcGVjdCB0aGF0IFFVSUMgaXMgbm90IGdvaW5nIHRv IHdvcmsNCg0KWWVzLCB0aGF0J3MgZm9yIHN1cmUuICBCdXQgSSB3b3VsZCBsaWtlIHRvIGF2b2lk IGNsaWVudCdzIGFuZCBzZXJ2ZXIncyBRVUlDIHN0YWNrcyBhdXRvbWF0aWNhbGx5IHNlbmRpbmcg YW4gdW5lbmRpbmcgc2VyaWVzIG9mIHBhY2tldHMgdG8gZWFjaCBvdGhlciBhcyBxdWlja2x5IGFz IHRoZXkgY2FuLiAgSS5lLiBjbGllbnQgcmV0cmFuc21pdHRpbmcsIHBhdGggY29ycnVwdGluZywg c2VydmVyIHJlcGx5aW5nIHdpdGggYSB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldCwgcmVwZWF0 LiAgSSdkIGJlIG11Y2ggYmV0dGVyIG9mIG9uZSBzaWRlIHdvdWxkIGp1c3Qgc3RvcCBxdWlja2x5 IGFuZCBib3VuY2UgdGhlIGVycm9yIHVwIHRvIHRoZSBjbGllbnQncyBhcHBsaWNhdGlvbi4NCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAx LCAyMDE3IDU6NTQgUE0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4N CkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0 QGdvb2dsZS5jb20+OyBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjsgVmljdG9yIFZhc2ls aWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBE YXZpZCBCZW5qYW1pbiA8ZGF2aWRiZW5AY2hyb21pdW0ub3JnPg0KU3ViamVjdDogUmU6IEJpa2Ug c2hlZCB3YXJuaW5nOiBpbnRlZ3JpdHkgY2hlY2sgZm9yIHVucHJvdGVjdGVkIHBhY2tldHMNCg0K T24gMiBNYXJjaCAyMDE3IGF0IDA5OjM5LCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFp LmNvbT4gd3JvdGU6DQo+DQo+IFRoYXQgbWF5IGJlIGEgcHJvYmxlbSwgaWYgdGhlIHBhdGggY2F1 c2VzIGEgcGVyc2lzdGVudCwgZGV0ZXJtaW5pc3RpYyBjb3JydXB0aW9uIChhIGJhZCBsaW5lIGNh cmQsIGV0YyAtLSB0aGVzZSB0aGluZ3MgaGFwcGVuKS4gIFdvdWxkIHRoZSBzZXJ2ZXIgdGhlbiBy ZXBseSB3aXRoIGEgdmVyc2lvbnMgbmVnb3RpYXRpb24gcGFja2V0IGFnYWluPyBBbmQgdGhlIGNs aWVudCByZXRyYW5zbWl0IGFnYWluPyAgVGhpcyBpcyB0aGUga2luZCBvZiBjb21wbGV4aXR5IGFu ZCBjb3JuZXIgY2FzZXMgSSB3YXMgd29ycmllZCBhYm91dC4NCg0KSWYgdGhlIHBhdGggaXMgZG9p bmcgdGhhdCwgdGhlbiBJIHN1c3BlY3QgdGhhdCBRVUlDIGlzIG5vdCBnb2luZyB0byB3b3JrLiAg QXJndWFibHkgdGhlIHBhdGggaXMgYnVzdGVkIGFuZCBsZWFybmluZyB0aGlzIGlzIHRoZSBmaXJz dCBzdGVwIGluIGZpeGluZyBpdC4NCg== From nobody Wed Mar 1 15:03:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6982112996C for ; Wed, 1 Mar 2017 15:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhpxFtUJDAVH for ; Wed, 1 Mar 2017 15:02:56 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 A868512995B for ; Wed, 1 Mar 2017 15:02:56 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s186so96397860qkb.1 for ; Wed, 01 Mar 2017 15:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AU2l4bZ1rli0rEaepxyy3ekgP09/jIkZHZGm4X7A/z0=; b=qaeiFXNwgbcrilQVAwOlPeySPGyjlC2oBTETIw86Y8h/MQIBvZSDfe1ds0HIu5SNOQ YOjo1FZK/26yWad+nX+WcOW8WhbIc6OBgccjk7Qw1kvxT/wpAUzvtcuF0PwsCQEHmV4A UJZjNC2Xbz7aK8Qt+iBzlXAHHftfUCt6y0Wz9WsBOoaTkocEUGTeXow8m9EvFm1hS/Gc bdO63S5fqoNwqMhaFgVnN5gEbSB+Iw2IbxyEeLRcP5jpGKZAKZoeDwrh8Gdx4kVUgRoq z7mwvmcOtWU3JNPvqCybK/AXdtMhADoXll1X7YhyeLWCqTqXBahTuahOzQ83AGpms86t jstA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AU2l4bZ1rli0rEaepxyy3ekgP09/jIkZHZGm4X7A/z0=; b=QKoXrSRJybh/X9dzJub9jj3hh34vqFzBv4x1QwuEuoqZO+OJFU8n+1WoE6m5WKSRua 8K2AsDQImAtKcMdvdEvOQEGK7wTu3VDI58ZZJTKH8J/bxQZYmzh/BgaVK06EEcHjVUZ2 2T7QCG6WvELKP4KVzvn++PJl8hEpfmSgoVRWH9ln0yl8F/5AqFN/vJ9KUYaYw59NAtyJ Lexbh3ylBVhcF+mxiHSipOnSJyPPlSZRWPxeaU5HeF+c/drfZyZQBPcu8l/i5WZ0ED8+ GH/HMapFARqZbpp9immlM+6JodZr4CTE7NRWKS/BGvcrJK2uDt7smoER8ah0L2p4KCan NH3g== X-Gm-Message-State: AMke39n3yGTPqHsD5yWK0wUyG7H+zVEvE/CqN9cVamDBJt0Jfz431gfTgwa353EQcu3adTsfH+GsBruqfuWqcQ== X-Received: by 10.55.18.144 with SMTP id 16mr13444915qks.5.1488409375830; Wed, 01 Mar 2017 15:02:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 15:02:55 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 2 Mar 2017 10:02:55 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Victor Vasiliev Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:02:58 -0000 On 2 March 2017 at 08:55, Victor Vasiliev wrote: > As far as I recall, SSE 4.2 uses CRC-32C and not CRC-32. One can use CLMUL > for this, but it's not as widespread as SSE 4.2. You are right. Despite being advertised as CRC32, it is indeed using the CRC32c polynomial. ARM has both from 8.1 onward. While this is an entertaining diversion, I don't think that speed is especially relevant to the choice of checksum algorithm. The bulk of QUIC packets will be protected with an AEAD. Speed concerns are less relevant here than things like code size, maintainability, and reuse. I'm thinking that CRC32c is the better choice here given its apparently greater prevalence. From nobody Wed Mar 1 15:04:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B05612956B for ; Wed, 1 Mar 2017 15:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 fp9KqUEKTuK9 for ; Wed, 1 Mar 2017 15:03:58 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8E11293E4 for ; Wed, 1 Mar 2017 15:03:58 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n127so96695526qkf.0 for ; Wed, 01 Mar 2017 15:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uIrT05IWEhJC83uWAmqcYyGKP76IXZzRwxvGTSSa6V8=; b=l4CKBv+eI+9evFCm6wjzhRoL1g75vMGOdWKbabpn9yRE+x/0a/UJKvNQOTgeWsB3Dv KeSSGwvHhpX9mKuPOu0x7W5s7QelOvYhTnej1y8MkioiI3oIZ9SQGWOVJDWdsTvNtZ0l WUDV9glYbf3NKCE6GdZ0XJw/FBoBDLCX1CsZI9Xc5gh/BitpSpGoBMMgWXf3HgrahmNX gKnzPULcPSNQPDdIHx56JlbBsBoqjXropTqLefSK6RgGYgLw3WOLcMiJUSQadTQCsWQW GXloNucICyBCcvF0ywmGhTs8MqXY09qHqENmKu1P0V8cMj1JOtyCNHEn6fq1zSUPhOLX O8Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uIrT05IWEhJC83uWAmqcYyGKP76IXZzRwxvGTSSa6V8=; b=nHyRH7OiDxa6zGtzzJBPJfcd3/evoAH6/pbrKIo6KHinsVSD990sKpytgTE49t82xv lez+8qfTZgOvY4bhUyVaaF6Q3c80AWCzEUCvpO3sIvOjoop4n+t4AN9h61ZJY5QOfx94 k9RyqS25NFhvOybOusNDwurdkjYF6oOi9k4A0cVPKegL6d/A6T9X5dDIe4WrEIKAAP0F AhJ0Y+iaJqXEVtXphDniIpVvYkzf1j2qk4Tbf/N8WRtuh7hSeWanb4VB0IkkPD0ckNV7 lJF0ClLcHE64vs8hX2ctpMGy1NC/cwGZsIwcehOLnC8xilF1wneDkWogChlBD1nYvJdj XDCw== X-Gm-Message-State: AMke39lWR7j/WYgMROhc/gLsZ78ZhZ79pi92ACAaD4VwqhG8ih0f1OhvcyT6KShAeqPkbBA7+vmHDLxLHp28XA== X-Received: by 10.55.27.219 with SMTP id m88mr12560080qkh.147.1488409437498; Wed, 01 Mar 2017 15:03:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 15:03:57 -0800 (PST) In-Reply-To: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 2 Mar 2017 10:03:57 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ted Hardie , "Salz, Rich" , Ian Swett , David Benjamin , Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:03:59 -0000 On 2 March 2017 at 10:02, Lubashev, Igor wrote: > Yes, that's for sure. But I would like to avoid client's and server's QU= IC stacks automatically sending an unending series of packets to each other= as quickly as they can. I.e. client retransmitting, path corrupting, serv= er replying with a version negotiation packet, repeat. I'd be much better = of one side would just stop quickly and bounce the error up to the client's= application. Given that your example was a pathological error, I am perfectly happy to let the client time this one out. That should only take a few seconds and a handful of exchanges. From nobody Wed Mar 1 17:02:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1A129455 for ; Wed, 1 Mar 2017 17:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et3qjgI_zkq4 for ; Wed, 1 Mar 2017 17:02:06 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0B7E8129431 for ; Wed, 1 Mar 2017 17:02:06 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v220steg029096 for ; Wed, 1 Mar 2017 20:02:05 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 28x8f593tk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 01 Mar 2017 20:02:05 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v221246X016143 for ; Wed, 1 Mar 2017 20:02:04 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2211uja016040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Mar 2017 20:01:57 -0500 Received: from mlpi432.sfdc.sbc.com (mlpi432.sfdc.sbc.com [144.151.223.11]) by mlpi407.sfdc.sbc.com (RSA Interceptor) for ; Thu, 2 Mar 2017 01:01:42 GMT Received: from sfdc.sbc.com (localhost [127.0.0.1]) by mlpi432.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id v2211gWQ028914 for ; Wed, 1 Mar 2017 20:01:42 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by mlpi432.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id v2211ZeV028690 for ; Wed, 1 Mar 2017 20:01:35 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 57F64E1079 for ; Wed, 1 Mar 2017 20:01:27 -0500 (EST) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 1 Mar 2017 20:01:34 -0500 From: "MORTON, ALFRED C (AL)" To: "quic@ietf.org" Subject: Re: New Version Notification for draft-kuehlewind-quic-appman-00.txt Thread-Topic: Re: New Version Notification for draft-kuehlewind-quic-appman-00.txt Thread-Index: AdKS8A34tYz3CPHtTNOYDAaNQaZZAA== Date: Thu, 2 Mar 2017 01:01:33 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25D31ADC@njmtexg4.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.178.187.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-01_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1703020007 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:02:06 -0000 Hi Mirja and Brian, I found your draft useful and a good guide to=20 topics I care about =3D=3D measuring performance of transport protocols. I have added some comments on related github issues, as well. thanks for starting -quic-appman, Al From nobody Wed Mar 1 17:35:59 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352C7129504 for ; Wed, 1 Mar 2017 17:35:58 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wjwGfCpmv0kj for ; Wed, 1 Mar 2017 17:35:56 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5841294C4 for ; Wed, 1 Mar 2017 17:35:56 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id s15so23896766ywg.0 for ; Wed, 01 Mar 2017 17:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WWm9/SXdrrDgrFinpY90EYGe9Ekg53LldLNMsfLmDxY=; b=FQjOnMw9kZX8V/K2mJ+jp91X/lokVMc2b9MPuuL9atG1Q4GYm8gmENRUf1XaHeELrn 5yjfyD+dvMO87L11NthjesxB5YxPjiBg9+VHVtgP7SzYnBHR3630t3GqVIO2pa3hw4M0 K7OnTLzt7X85rTyzRK2PZEboQAMKPD2qhi61LJV8TEYDJE2f7yHLavsJpUQ6AXplbJmS sx3OZ9Ix2tx3S28FqBU29T8xJ17OrdS89WLTLGaTndwK1Hn5d4mRVAffUELHqK1+xTVr 8eun7J4SUJCIynyyl8gPpNGGsnXREp40L78+AlfHk6ULMT1mtJRA11FZ/oS6nq1hQOx0 u+AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WWm9/SXdrrDgrFinpY90EYGe9Ekg53LldLNMsfLmDxY=; b=NYDp2hsZd+r9A8rMhBnqlrEgl2ffFC1OtK3IgunICw3UkN1QjXqUEEr1D+j1MmyAKQ VqTEFZxms/ESxUV7Ur9Yck0wH+iXGhFVz4cTo28Tn9mffGzfmT6etSyx/6SellUqF1SZ Y9bxJyENc62jgEoMRZ1Pej0wiYDXDDhMlOkHjOucTZPXYYY0Hi2MuRG6xdiPxNdagDjm eGip5snCXzJR819c8V/5xTJ2+AN1E7TUDqLbRUWFMTPSPWpGXKu5O/q9wcvdBlQHwOYk reRd2YGyCZizO65s/HPFsNLlUKZs7mWIlNlmF9yW4DVn2FcNu7MGXqcANt4PlQm4JTd0 hEHA== X-Gm-Message-State: AMke39ngrF/ge1VOzU1Qw0J6i2pMi7KyJ3QHxo3EkwPA0EmF5E6xJ5PuADAl3KE6JSzfPMsIQ2eX8BRwTeG7WXLd X-Received: by 10.129.82.16 with SMTP id g16mr3689484ywb.107.1488418555729; Wed, 01 Mar 2017 17:35:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.50.139 with HTTP; Wed, 1 Mar 2017 17:35:35 -0800 (PST) In-Reply-To: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Wed, 1 Mar 2017 20:35:35 -0500 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114dac084ae12d0549b57324 Archived-At: Cc: Ted Hardie , "Salz, Rich" , "Lubashev, Igor" , David Benjamin , Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:35:58 -0000 --001a114dac084ae12d0549b57324 Content-Type: text/plain; charset=UTF-8 It may be a pathological error, but I think we'd like to fail a bit more quickly on this one, because tight loops, particularly in low-latency environments, can be really nasty. If I send a packet with a version, and then receive a version negotiation packet, one of two cases arises: 1) The version I sent is not in the list of versions the server sent, and I start over. 2) The version I sent is in the list of versions the server sent, and the handshake fails, because that indicates something is very broken. If one was worried about #2 being a potential path for censorship, the client could ignore the version negotiation packet entirely as being invalid? On Wed, Mar 1, 2017 at 6:03 PM, Martin Thomson wrote: > On 2 March 2017 at 10:02, Lubashev, Igor wrote: > > Yes, that's for sure. But I would like to avoid client's and server's > QUIC stacks automatically sending an unending series of packets to each > other as quickly as they can. I.e. client retransmitting, path corrupting, > server replying with a version negotiation packet, repeat. I'd be much > better of one side would just stop quickly and bounce the error up to the > client's application. > > > Given that your example was a pathological error, I am perfectly happy > to let the client time this one out. That should only take a few > seconds and a handful of exchanges. > --001a114dac084ae12d0549b57324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It may be a pathological error, but I think we'd like = to fail a bit more quickly on this one, because tight loops, particularly i= n low-latency environments, can be really nasty.

If I se= nd a packet with a version, and then receive a version negotiation packet, = one of two cases arises:
1) The version I sent is not in the list= of versions the server sent, and I start over.
2) The version I = sent is in the list of versions the server sent, and the handshake fails, b= ecause that indicates something is very broken.

If= one was worried about #2 being a potential path for censorship, the client= could ignore the version negotiation packet entirely as being invalid?

On Wed, Mar 1, = 2017 at 6:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 2 March 2017 at 10:= 02, Lubashev, Igor <ilubashe@akamai.com> wrote:
> Yes, that's for sure.=C2=A0 But I would like to avoid client's= and server's QUIC stacks automatically sending an unending series of p= ackets to each other as quickly as they can.=C2=A0 I.e. client retransmitti= ng, path corrupting, server replying with a version negotiation packet, rep= eat.=C2=A0 I'd be much better of one side would just stop quickly and b= ounce the error up to the client's application.


Given that your example was a pathological error, I am perfectly hap= py
to let the client time this one out.=C2=A0 That should only take a few
seconds and a handful of exchanges.

--001a114dac084ae12d0549b57324-- From nobody Wed Mar 1 18:59:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE78129793 for ; Wed, 1 Mar 2017 18:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEYpd1BCDBKb for ; Wed, 1 Mar 2017 18:59:52 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB21129452 for ; Wed, 1 Mar 2017 18:59:52 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s186so103260032qkb.1 for ; Wed, 01 Mar 2017 18:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V0Yjepmb0sHXpHlJiTLtixILZ56LuDX9Gex1JF7qK8U=; b=r3ojLEjYTlL0bK7YVksDuZbUIlX6SQDbsIrHvPOs6c+azDrf5JM3Fj5sRrKQbO/Hqn jt+gLhJMYTLdGRqBzIjRLNBxuob44ZdAsLTuj7IVkNDodOdNPjcYsOokk7oJPDJZSpYu LME/MaMgknHvAr1Bsokr9ANYPa+ZBC333fBIkkLtS3EharPEvYzxg3mujB/RXI//zBY1 aH2G2Y89eu7X5X58GwQVeFmbqhnbL8yLOQc8XjHs8/ZMZnt1vB8gVq4hziSlqZafClDM yMxZE0q9qnf5GV6Ljh83Is+gperyRbIJO/4FCX66AAKAP06LSFYprCzDqvgEjXbcluHy 42Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V0Yjepmb0sHXpHlJiTLtixILZ56LuDX9Gex1JF7qK8U=; b=esOQnCVNdAiR4ZT9Fo+CSaP8klL5WAncTx0c2UNIxHz+v1U9FQFgNxOrr1nFyzEB8S uRGG2g3QjkwlQlI6TNYU1PsWtG7J0q5LH1CPHkdl0GwL37rUCEU3mGwQSVqX5vjsOSmA Vl6PBUDgv/a5oJTcqNn2Pvk10TVf2mihB50wiqtvHMInQ7NOxqIERoBwWlFDzOcaJ/JQ ZQkoJOuzdl09mo2LWi8q7Y3jkLsI4VGFXvReN3TftqEmgOcLxVsT25Akw1A6Vc0DL4Yj 1dckrusbGeNkeNS5dPWIASqWDdL4Wp5yAVIVek1QIKYSW79ynBY3eu4qQdnTEwP4L0NG HVOA== X-Gm-Message-State: AMke39n7TtMRGQ5qBWHPWg9GdMuDpTCwhyeuWvsExyAGgNwjuUq+M/FyPYIcVUFs4xxVVcOy4u3Fdm1txNqw0g== X-Received: by 10.55.217.16 with SMTP id u16mr14798901qki.144.1488423591750; Wed, 01 Mar 2017 18:59:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 18:59:51 -0800 (PST) In-Reply-To: References: <2be2266072df4eedbd4616eab28b810b@usma1ex-dag1mb1.msg.corp.akamai.com> <9a9e881993fd4562a5b9d1195a2e6cd6@usma1ex-dag1mb1.msg.corp.akamai.com> <5d7f3a1e3ad84de5ae4cb2c02727790b@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 2 Mar 2017 13:59:51 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ted Hardie , "Salz, Rich" , "Lubashev, Igor" , David Benjamin , Victor Vasiliev , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 02:59:53 -0000 On 2 March 2017 at 12:35, Ian Swett wrote: > 1) The version I sent is not in the list of versions the server sent, and I > start over. This only happens once. > 2) The version I sent is in the list of versions the server sent, and the > handshake fails, because that indicates something is very broken. I'm suggesting that you ignore this on the basis that either the server is reacting to corruption, or its an attack (yes, censorship being one example). I'd happily recommend that this be treated as fatal if it happened often. From nobody Thu Mar 2 01:52:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B1129680 for ; Thu, 2 Mar 2017 01:52:13 -0800 (PST) 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, RP_MATCHES_RCVD=-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 gCjezFjcSXPr for ; Thu, 2 Mar 2017 01:52:11 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A145C1296A2 for ; Thu, 2 Mar 2017 01:52:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vYnfL2F7vz15LhJ; Thu, 2 Mar 2017 10:52:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2N75SdJ2XDT; Thu, 2 Mar 2017 10:52:08 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11F5B.dip0.t-ipconnect.de [217.225.31.91]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 2 Mar 2017 10:52:08 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: New Version Notification for draft-kuehlewind-quic-appman-00.txt From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25D31ADC@njmtexg4.research.att.com> Date: Thu, 2 Mar 2017 10:52:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EA4DF2F-0232-4990-92F9-0F6050B831C6@tik.ee.ethz.ch> References: <4D7F4AD313D3FC43A053B309F97543CF25D31ADC@njmtexg4.research.att.com> To: "MORTON, ALFRED C (AL)" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 09:52:13 -0000 Thanks Al! In Tokyo we decided to spilt the applicability part and the = manageability part into two draft. We will submit those new drafts next = week. Of course contributors for both documents are still welcome! Mirja > Am 02.03.2017 um 02:01 schrieb MORTON, ALFRED C (AL) = : >=20 > Hi Mirja and Brian, >=20 > I found your draft useful and a good guide to=20 > topics I care about =3D=3D measuring performance > of transport protocols. >=20 > I have added some comments on related github issues, > as well. >=20 > thanks for starting -quic-appman, > Al >=20 From nobody Thu Mar 2 11:49:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C6E1295C1 for ; Thu, 2 Mar 2017 11:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 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, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=idzeOsGa; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=EiNU3uzu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMgGxpkJPhT6 for ; Thu, 2 Mar 2017 11:49:47 -0800 (PST) Received: from mx0a-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 46F14129545 for ; Thu, 2 Mar 2017 11:49:47 -0800 (PST) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v22JksAO005932 for ; Thu, 2 Mar 2017 11:49:46 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=JgijgCXPcXu/XQPXEbfA5pqBL6xF+AaG6yEDJVcjKYs=; b=idzeOsGaRTEhow47n5FTSt2mW0ae1InNuTbVZ8LL0PGNscFQLCRC8m2uB/i4b65aHBMs Dr37I/2VUWe/EwGApWlNzCiYrcdn0MlBcPe3u/xumJYoaYl7yBBw3ypaqfMmn7Pu03xK a+G+R1yK3jfzO2nYKL/GiqTDtAcQ2M9g8u8= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 28xs9er4bu-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 02 Mar 2017 11:49:46 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 2 Mar 2017 11:49:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JgijgCXPcXu/XQPXEbfA5pqBL6xF+AaG6yEDJVcjKYs=; b=EiNU3uzufogIGOOtu3B2uCc/2AiGi3g1NIAZXNqREwJn+WvZ4FtT1IdhMrDzNzB7a7SrOKipk+o8+f8iffl5kOchxghhJGyfXH56uQ4a9kxTGeL6xxiqIyaZq6a+F/NeTZmr4nmJEslWYIwIgC22KKg9Jp3pnfoiszyocEBPtxQ= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Thu, 2 Mar 2017 19:49:44 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0933.020; Thu, 2 Mar 2017 19:49:44 +0000 From: Subodh Iyengar To: "quic@ietf.org" Subject: Changing IPs and amplificiation Thread-Topic: Changing IPs and amplificiation Thread-Index: AQHSk4vZzdVTj95ycU+HkqruhCBHAA== Date: Thu, 2 Mar 2017 19:49:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-ms-office365-filtering-correlation-id: a5e3d46b-49ea-4599-7409-08d461a54633 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1456; x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:iaX8X+3CJcR2Oe1Kzcw0VXS1ENiqPl5QuNwfeZcweE4pex4/S/FhMZK4HD2CO1rgkXMN2j/MFLf/Kbr4h/3tulxVFbrSj9fik6q0VvHuyU/PI71Sf28nd0iaQOIqPxtWgCmPub+DAhbWbeEcUp4ayciWiHwec2NNTVUaHo++g1eN0o+jTRTQ0P0fttdXTxrp90RbTRKUocvCava28UvJngwtmdN3vU5P59YdXVdAByJjCZTanSUou/GMSlxAMIGN2TAAYV+VMLE6iQhmOvvxIvieKFYIlGcTu3dWJy+gZ+QuUkIm7KpJgtqenzmbOiEyP1rkzN4CnK3w5HqoIOs6FQ==; 20:HvVhqsNpOvvnivlw0b3GLvAJmzrQqo1cAFKkYXo1BJ01+rKxB3O/W6YZDuEODgrObz1fDYMTg29uOrdAuBBjECbMcgwz8VhfjI6yIJF/XM0o8/mdPLuHTRrmS0rd1+nBSewZmYovKF+55+3uZ8iesvUzs/AOgmjAjsl+3SbB/Ws= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39830400002)(39410400002)(57704003)(38730400002)(3660700001)(2906002)(3280700002)(92566002)(7736002)(77096006)(6606003)(86362001)(55016002)(6436002)(6506006)(5640700003)(9686003)(53936002)(110136004)(450100001)(50986999)(6116002)(54896002)(99286003)(74316002)(8936002)(7696004)(3846002)(54356999)(102836003)(3480700004)(25786008)(19627405001)(2351001)(106116001)(6916009)(1730700003)(66066001)(81166006)(8676002)(122556002)(5660300001)(2501003)(189998001)(2900100001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14556C411D2F6ECD671BB25AB6280MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 19:49:43.9706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-02_17:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:49:48 -0000 --_000_MWHPR15MB14556C411D2F6ECD671BB25AB6280MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A few colleagues, Kyle Nekritz, Alan Frindell and I were discussing QUIC's = behavior when source IP changes. After a QUIC connection is fully established, when a client's source IP cha= nges due to a NAT, the server would need to cache the last known IP address= because future UDP writes would go to the new source IP. How should the se= rver validate that the new IP is a reasonable address to send traffic if th= e sender is actually an attacker? Simply validating the cryptographic authenticity of packet doesn't seem lik= e it is enough since an attacker can change their IP without violating the = authenticity of their own packet. The server could use some heuristics to v= alidate the source IP, for example, the client didn't change it's ASN or su= bnet. However, without any validation it would seem like an attacker could = initially use the source token during connection establishment to prove pos= session of their IP, but later when a connection id is bound, they could ch= ange their IP to a target IP which they want to send amplification traffic = to. Do current deployments of QUIC use some other techniques to validate IP add= ress when it does change? Do we need a feature for the server to be able to= request revalidation in the middle of a connection? Subodh Iyengar --_000_MWHPR15MB14556C411D2F6ECD671BB25AB6280MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A few colleagues, Kyle Nekritz, Alan Frindell and I were discussing QUIC= 's behavior when source IP changes.

After a QUIC connection is fully established, when a client's source I= P changes due to a NAT, the server would need to cache the last known = IP address because future UDP writes would go to the new source I= P. How should the server validate that the new IP is a reasonable address to send traffic if the sender is actually an att= acker?

Simply validating the cryptographic authenticity of packet d= oesn't seem like it is enough since an attacker can change their IP without violating the authenticity of their own packet. The server could us= e some heuristics to validate the source IP, for example, the client didn't= change it's ASN or subnet. However, without any validation it wo= uld seem like an attacker could initially use the source token during connection establishment to prove possess= ion of their IP, but later when a connection id is bound, they could change= their IP to a target IP which they want to send amplification traffic to.<= br>
Do current deployments of QUIC use some other techniques to validate IP add= ress when it does change? Do we need a feature for the server to be able to= request revalidation in the middle of a connection?


Subodh Iyengar

--_000_MWHPR15MB14556C411D2F6ECD671BB25AB6280MWHPR15MB1455namp_-- From nobody Thu Mar 2 12:01:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CBB12962D for ; Thu, 2 Mar 2017 12:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=it-uc3m-es.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 hPcDTpHIAqO2 for ; Thu, 2 Mar 2017 12:01:12 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27D512962E for ; Thu, 2 Mar 2017 12:01:00 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t193so231732wmt.1 for ; Thu, 02 Mar 2017 12:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=GhAIluTwwgWkoZrCY/+e5a04N33L0f/P9W5gvKgCOao=; b=s9XIlkrE37MAViFatE1bIxPUqOIKZvEdFQEgRNPYI+p0ybS4L1/qTzZzJAutwQRTug ICc2pVjFNC+82jzhFly1cqXv6BIsFmMtiQVRpz+Xx2LSKtEAgNCSjTkKXq6kE8B17B3b QGTlfdS9Ui/Wvd3k+VWlH5KrLYKXqcc67GtUC7SdH4QPmx2Nlzyv9q3iBAvjmP+V/fmq wZUgRu1LeYNuJbI0NiN4hCh9q/QiiToHRuYiZNhz8gzRpqz/aHOhzZ1Md7jv8kZsIKGC 8pNWPRovs8tkAoEgotYS1Q/DWHXgHT9sqlQqE5DG3dqoZP0tTDwPkKptjSWTCrBFk1eq rZjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GhAIluTwwgWkoZrCY/+e5a04N33L0f/P9W5gvKgCOao=; b=WifnzQM+K13YBzNoabMO2uOV0Q/S/QHMwgaA6bm+6ENWEHhEf2bz8NuXp4eS1Vxjpc 8jEW0qkq9ZElXBBNqwRv2t4MIjKCImazJ79+Rux7KxzfJ0inCPJ38mjgkurD09VoRhyK gpEN17IoB/7NsGlIsfalVP/furIUrEzMJNTostKQ2RBHlOGCS0UKh42LmkEkUkKk2jvW kb8Zs974O0A1R0ya3Z7jUXCq9zIkfwLiLNLw0B3iAHMB1xGagotvaGUVWy+iNhxMqTrY cHuiZBIOcaToFeuLbzzVhuJ63PsxAz4//U99rq7KQsqAqgHKUqFnHqYLdVreYw7WYyfa YSnQ== X-Gm-Message-State: AMke39lyjrmZu9fsGon8IEfDr4yt6ZGRU9Y1tqdNxntKkKaU3CnAoHkhQQq+l0+lyg6paV58 X-Received: by 10.28.96.194 with SMTP id u185mr32658wmb.82.1488484858957; Thu, 02 Mar 2017 12:00:58 -0800 (PST) Received: from Macintosh-6.local (20.163.16.95.dynamic.jazztel.es. [95.16.163.20]) by smtp.gmail.com with ESMTPSA id q66sm28213497wmb.28.2017.03.02.12.00.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Mar 2017 12:00:58 -0800 (PST) Subject: Re: Changing IPs and amplificiation To: quic@ietf.org References: From: marcelo bagnulo braun Message-ID: <175b29b2-0b0e-8246-fcc2-0ce11559290d@it.uc3m.es> Date: Thu, 2 Mar 2017 21:00:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 20:01:15 -0000 isnt this covered in the security considerations of draft-ietf-quic-transport-01 or the attack yu are refferring is different? El 02/03/17 a las 20:49, Subodh Iyengar escribió: > > A few colleagues, Kyle Nekritz, Alan Frindell and I were discussing > QUIC's behavior when source IP changes. > > After a QUIC connection is fully established, when a client's > source IP changes due to a NAT, the server would need to cache the > last known IP address because future UDP writes would go to the new > source IP. How should the server validate that the new IP is a > reasonable address to send traffic if the sender is actually an attacker? > > Simply validating the cryptographic authenticity of packet doesn't > seem like it is enough since an attacker can change their IP without > violating the authenticity of their own packet. The server could use > some heuristics to validate the source IP, for example, the client > didn't change it's ASN or subnet. However, without any validation it > would seem like an attacker could initially use the source token > during connection establishment to prove possession of their IP, but > later when a connection id is bound, they could change their IP to a > target IP which they want to send amplification traffic to. > > Do current deployments of QUIC use some other techniques to validate > IP address when it does change? Do we need a feature for the server to > be able to request revalidation in the middle of a connection? > > > Subodh Iyengar > From nobody Thu Mar 2 12:22:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BFB129541; Thu, 2 Mar 2017 12:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utREy9UUW1n0; Thu, 2 Mar 2017 12:22:22 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772601295C1; Thu, 2 Mar 2017 12:22:22 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s186so142876853qkb.1; Thu, 02 Mar 2017 12:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nSgdWJEW2guNIcLeVUAd3PaLTKkD/etMBvMMQUiiUsY=; b=bcG4L5kNjGOMTxnZBlpigqKbEnYT0w4ZmlKh4MzshmpreOWR/0XY7MMo1sONTjevXa 0CUSmTmfAYB3qGajcWnFi5tvSRJzgDuhO8JDaINIWV5MKCwIx5NiNbbTktC2mk0jgYGR 7Et5UDlFE3ajG0xjQhIPgZCkP6d/Z8mjtyTvv3o7CqR0E+q/K8JesrRyNDjPCBAdyQLQ kAl/MkHYxuHk6JXY1TCAt+xqU4G4EZ+NZ/YXy4w/pjdel9+UOnyF3A/BPSjaNNLQxQf0 b2H/pyBBm88g426bg1jZtx8DNka7Ryq71PW0zDxEsaobVWcbK16SE9MT+U89QsYb0IW7 5xFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nSgdWJEW2guNIcLeVUAd3PaLTKkD/etMBvMMQUiiUsY=; b=dk1MLu+hH7r+CuTkMQ9mdRrsB/FsuA50tffsMyfeUgY9LXE46PaDG0JWy/YwCbY2Cv S81Qw4N47xmXFYZv8McXopNdKPNIMsC6RHPRm2lPlORaPsTCOPDVq1wNLQoMXOzhWtYK TlF+9wxhwTed8oyMd1TxTQ5jgjdjx5h77G1ozMjg1Kwofnf603pv6/YtivT6YKE5ls1A wWrKfeVsY+wXyGtLHBrqG/zw15U6a8xpP2R1J3fobmFqW1Azl41/5mpOUBn8Y/BVN1NF aEY9eC9D6dr4KG8dP6EcChjko9n5pOU1HqdQUW6rUletuIeqxovo1N9PxzsBR7jQWvA6 VXqg== X-Gm-Message-State: AMke39lJ38PsBYPMb+u57CdZn5my0apCC8c9G0fr88Lh1jAO1AfAh223Yid2Zj81hTx6RKxGieFQ1+E1Usck0g== X-Received: by 10.55.204.11 with SMTP id r11mr19679462qki.169.1488486141376; Thu, 02 Mar 2017 12:22:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.165.225 with HTTP; Thu, 2 Mar 2017 12:22:21 -0800 (PST) In-Reply-To: <57f78e9b-f75b-03da-0d3f-7405d645f7bd@it.uc3m.es> References: <57f78e9b-f75b-03da-0d3f-7405d645f7bd@it.uc3m.es> From: "Aron ." Date: Thu, 2 Mar 2017 15:22:21 -0500 Message-ID: Subject: Re: A single alarm in draft-ietf-quic-recovery To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a1149a43eb5cd000549c52f38 Archived-At: Cc: draft-ietf-quic-recovery@ietf.org, "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 20:22:24 -0000 --001a1149a43eb5cd000549c52f38 Content-Type: text/plain; charset=UTF-8 I think Marcelo poses interesting questions. I, too, would like to see the answers. Aron. On Tue, Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun wrote: > Hi, > > The current version of the draft uses a single alarm for all timer based > loss detection, as specified in section 3.4 of the draft. > > I am not sure i follow how you do this. > > I particular, I am uncertain you can avoid having two separated alarms, > one for the RTO and another one for tail probe (at least). > > I mean, if i understand correctly, the RTO alarm should be set when you > send the oldest packet (I guess a usual approximation is to set it when a > given packet becomes the oldest, i.e. it is ok to set it when an ack > arrives and acks the oldest packet (packet 5) making another packet (packet > 6) to become the oldest packet, instead of setting the alarm when packet 6 > was actually sent). > > I understand that the tail loss probe alarm is set when the last packet > was sent (and the connection is in open state). > > So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and > suppose no ACK is received. > > The RTO timer should be set when packet 1 is sent while the TLP timer > should be set when the packet 9 is sent. > > If i understand it correctly, according to the draft, the alarm will be > set in TLP mode (twice) and then it wil enter in RTO mode. > > Suppose no ack comes back, this basically means that the actual RTO will > be fired 2 TLP timeout later than the recommended RTO timeout, correct? > (neglecting the transmission delay for packets 1 to 9 which may not be > negligible if the number of inflight packets is high) > > I think a similar issue applies to the Early retransmit alarm. Again, the > RTO should be set when the oldest packet is sent, but setting the early > retransmit alarm will distort this. > I mean again consider the situation the sender sends packets 1,2 and 3. > While no acks are received, the TLP alarm is set. Suppose 1 RTT later, the > ack for packet 3 arrives. At this point, the Early retransmit timer is set. > Suppose now that no ack is received. RTT/4 later, the early retransmit > kicks in again and again and actually the RTO will be never be set, because > the alarm will always stay in early retransmit mode, no? > Maybe a defining a max number of early retransmit would fix this? > Probably having separated timers would also fix it (assuming we want a TCP > like behaviour when the oldest packet is retransmitted after an RTO timeout) > > An additional comment about the Early retransmit timer, the draft > references to RFC5827 to describe/explain this timer, but I personally > found this a bit of a stretch. I mean RFC5827, if i understand it > correctly, is about reducing the dupack threshold when the number of > inflight packets is low, while this early retransmit timer is, well, a > timer and it is used in any case when the latest packet has been acked. I > think this fits better with the "reordering settling" timer (step 4 in > section 5.2 of the RACK draft) being that the reordering settling timer > applies to all packets for which a later ack has been received (not only > the last ack, i mean). > Maybe it is worth to adopt the full "reordering settling" timer from RACK > (i.e. not limit to the case when the latests packet has been acked?) > I guess if we do this, then we will need the TLP timer and the reordering > settling timer to run in parallel. > > Regards, marcelo > > --001a1149a43eb5cd000549c52f38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Marcelo poses interesting questions.=C2=A0 I,= too, would like to see the answers.

=C2=A0 Aron.<= /div>

On Tue= , Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun <marcelo@it.uc3m.es&= gt; wrote:
Hi,

The current version of the draft uses a single alarm for all timer based lo= ss detection, as specified in section 3.4 of the draft.

I am not sure i follow how you do this.

I particular, I am uncertain you can avoid having two separated alarms, one= for the RTO and another one for tail probe (at least).

I mean, if i understand correctly, the RTO alarm should be set when you sen= d the oldest packet (I guess a usual approximation is to set it when a give= n packet becomes the oldest, i.e. it is ok to set it when an ack arrives an= d acks the oldest packet (packet 5) making another packet (packet 6) to bec= ome the oldest packet, instead of setting the alarm when packet 6 was actua= lly sent).

I understand that the tail loss probe alarm is set when the last packet was= sent (and the connection is in open state).

So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and suppos= e no ACK is received.

The RTO timer should be set when packet 1 is sent while the TLP timer shoul= d be set when the packet 9 is sent.

If i understand it correctly, according to the draft, the alarm will be set= in TLP mode (twice) and then it wil enter in RTO mode.

Suppose no ack comes back, this basically means that the actual RTO will be= fired 2 TLP timeout later than the recommended RTO timeout, correct? (negl= ecting the transmission delay for packets 1 to 9 which may not be negligibl= e if the number of inflight packets is high)

I think a similar issue applies to the Early retransmit alarm. Again, the R= TO should be set when the oldest packet is sent, but setting the early retr= ansmit alarm will distort this.
I mean again consider the situation the sender sends packets 1,2 and 3.
While no acks are received, the TLP alarm is set. Suppose 1 RTT later, the = ack for packet 3 arrives. At this point, the Early retransmit timer is set.= Suppose now that no ack is received. RTT/4 later, the early retransmit kic= ks in again and again and actually the RTO will be never be set, because th= e alarm will always stay in early retransmit mode, no?
Maybe a defining a max number of early retransmit would fix this?
Probably having separated timers would also fix it (assuming we want a TCP = like behaviour when the oldest packet is retransmitted after an RTO timeout= )

An additional comment about the Early retransmit timer, the draft reference= s to RFC5827 to describe/explain this timer, but I personally found this a = bit of a stretch. I mean RFC5827, if i understand it correctly, is about re= ducing the dupack threshold when the number of inflight packets is low, whi= le this early retransmit timer is, well, a timer and it is used in any case= when the latest packet has been acked. I think this fits better with the &= quot;reordering settling" timer (step 4 in section 5.2 of the RACK dra= ft) being that the reordering settling timer applies to all packets for whi= ch a later ack has been received (not only the last ack, i mean).
Maybe it is worth to adopt the full "reordering settling" timer f= rom RACK (i.e. not limit to the case when the latests packet has been acked= ?)
I guess if we do this, then we will need the TLP timer and the reordering s= ettling timer to run in parallel.

Regards, marcelo


--001a1149a43eb5cd000549c52f38-- From nobody Thu Mar 2 13:23:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE7129653 for ; Thu, 2 Mar 2017 13:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 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, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=DPUJZ5kb; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=QBiXFLfe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9G5Q7NI27T7 for ; Thu, 2 Mar 2017 13:23:25 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CF4120724 for ; Thu, 2 Mar 2017 13:23:25 -0800 (PST) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v22LMitE017593; Thu, 2 Mar 2017 13:23:25 -0800 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=KZF0GuPcjZDLX46uKjSHqHalpYYr6aK5k4KG8y+R8SY=; b=DPUJZ5kbswj9hnW0vVZxIwZpoG9pdDxBvgDYJzM5JZhu1zbVh2Uq3TlBqtGpwXT7PRE4 5/XrvVJgAJRcpSlMQ9Eqe91N38/9g4vhFyc0K+plRx4Aq7W5KnLbMoNMCHQqxSda1gY+ JgcvDLTPopUMmAmrPBTNsVN4lgSg8yvpm7Q= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 28xs9s0jcd-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 02 Mar 2017 13:23:25 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 2 Mar 2017 13:23:23 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KZF0GuPcjZDLX46uKjSHqHalpYYr6aK5k4KG8y+R8SY=; b=QBiXFLfeRRq+rFEc+bleNrWeX7FsmObhOWiR0Q4URJ8A7J/4Vd8Kqn/Eqh5z3kBUHYWmEHQJrqCwGzfy1xnaUMu1YmQfVx/mfUmnMPHDhZhabhY+wyGteJP/GmRvX+EaC9a1j/M74IbJxcPdbcw2HpOATUGcIspJ/cO80xEHp6E= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1454.namprd15.prod.outlook.com (10.173.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Thu, 2 Mar 2017 21:23:21 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0933.020; Thu, 2 Mar 2017 21:23:21 +0000 From: Subodh Iyengar To: marcelo bagnulo braun , "quic@ietf.org" Subject: Re: Changing IPs and amplificiation Thread-Topic: Changing IPs and amplificiation Thread-Index: AQHSk4vZzdVTj95ycU+HkqruhCBHAKGB+FGAgAAAYvc= Date: Thu, 2 Mar 2017 21:23:21 +0000 Message-ID: References: , <175b29b2-0b0e-8246-fcc2-0ce11559290d@it.uc3m.es> In-Reply-To: <175b29b2-0b0e-8246-fcc2-0ce11559290d@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: it.uc3m.es; dkim=none (message not signed) header.d=none;it.uc3m.es; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-ms-office365-filtering-correlation-id: 14057997-eece-4d6c-c713-08d461b25a88 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1454; x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 7:ER0Io+uG84YYTzgAR9fzDLJJjw6/F3UYgzfMRxpJiy8Pmr7+h0C3kaJbAfmfOio/7xSwSzaeQu/ReXcaE0LhcAH19v8YdSwYsRWAOASayYPUG6sKkZr4xLfjSe08WKIBSh3EEOofWKfqQ/K8/0jigF6MOFHZUZA4O+O6eeHuU3oaetew1V00LvhfdCsrvSbk3vNYl0u+teF3w8EOT63crqj/W4T/ofdsI83WvSMuhrMW/IqESP7p3WdzmJJW9jgJiZ70JIXPjbRjXP6eNPVnNS6i82BuLRWx2v6d/Jfm36luPeQ+jC8mKIxtZYGRc1ZKab1JwLThLUfA4IK08IsgiA==; 20:m/42CJ97eWpXj2ujf5G1hz4I+/JWSGQrGZDgC45EVOG+nSg7OC4tE+W9fiXVJeMJAizes9mp/CngK03pfV0gwEENPB5nqjDsS1cVdgILqsBy3Cjhg5OqVzAkN81orrvPO+vwSxVPcGK+YzUUnvLIHmsn+kQCryQRHYpbFcX9w2w= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1454; x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39830400002)(39410400002)(57704003)(377454003)(6506006)(2950100002)(229853002)(77096006)(6436002)(6606003)(106116001)(55016002)(54896002)(99286003)(9686003)(6306002)(54356999)(50986999)(236005)(19627405001)(3280700002)(76176999)(189998001)(53936002)(3660700001)(6246003)(66066001)(38730400002)(74316002)(7736002)(7906003)(5660300001)(33656002)(606005)(2906002)(7696004)(122556002)(25786008)(2501003)(53546006)(3480700004)(81166006)(8676002)(8936002)(92566002)(6116002)(2900100001)(3846002)(86362001)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB145508213C129C64B8C2AD71B6280MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 21:23:21.4746 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1454 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-02_17:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 21:23:27 -0000 --_000_MWHPR15MB145508213C129C64B8C2AD71B6280MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.= section.6.4 the current language in the draft addresses the threat of sourc= e address spoofing during the 0-RTT handshake where the client has a chance= to provide proof of the source address using the session ticket. This does= not address how the client could prove possession of the source address af= ter a handshake is finished and in the course of a regular connection. It looks like the https://quicwg.github.io/base-drafts/draft-ietf-quic-tran= sport.html#migration section is meant to be a placeholder for putting up ho= w to do validation if source address changes. More specifically I'm wonderi= ng if current deployments of QUIC use any techniques to do source address v= alidation after the source address changes which are not specified here. Subodh ________________________________ From: QUIC on behalf of marcelo bagnulo braun Sent: Thursday, March 2, 2017 12:00:57 PM To: quic@ietf.org Subject: Re: Changing IPs and amplificiation isnt this covered in the security considerations of draft-ietf-quic-transport-01 or the attack yu are refferring is different? El 02/03/17 a las 20:49, Subodh Iyengar escribi=F3: > > A few colleagues, Kyle Nekritz, Alan Frindell and I were discussing > QUIC's behavior when source IP changes. > > After a QUIC connection is fully established, when a client's > source IP changes due to a NAT, the server would need to cache the > last known IP address because future UDP writes would go to the new > source IP. How should the server validate that the new IP is a > reasonable address to send traffic if the sender is actually an attacker? > > Simply validating the cryptographic authenticity of packet doesn't > seem like it is enough since an attacker can change their IP without > violating the authenticity of their own packet. The server could use > some heuristics to validate the source IP, for example, the client > didn't change it's ASN or subnet. However, without any validation it > would seem like an attacker could initially use the source token > during connection establishment to prove possession of their IP, but > later when a connection id is bound, they could change their IP to a > target IP which they want to send amplification traffic to. > > Do current deployments of QUIC use some other techniques to validate > IP address when it does change? Do we need a feature for the server to > be able to request revalidation in the middle of a connection? > > > Subodh Iyengar > --_000_MWHPR15MB145508213C129C64B8C2AD71B6280MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In https://quicwg.github.io/base-drafts/draft-ietf-quic-t= ransport.html#rfc.section.6.4 the current language in the draft addresses the threat of source address spoofing duri= ng the 0-RTT handshake where the client has a chance to provide proof of th= e source address using the session ticket. This does not address how t= he client could prove possession of the source address after a handshake is finished and in the course of a regula= r connection.


It looks like the https://quicwg.github.io/base-drafts/draft-ietf= -quic-transport.html#migration section is meant to be a placeholder for putting up how to do validation if source ad= dress changes. More specifically I'm wondering if current deployments = of QUIC use any techniques to do source address validation after the s= ource address changes which are not specified here.


Subodh

From: QUIC <quic-bounc= es@ietf.org> on behalf of marcelo bagnulo braun <marcelo@it.uc3m.es&g= t;
Sent: Thursday, March 2, 2017 12:00:57 PM
To: quic@ietf.org
Subject: Re: Changing IPs and amplificiation
 
isnt this covered in the security considerations o= f
draft-ietf-quic-transport-01
  or the attack yu are refferring is different?


El 02/03/17 a las 20:49, Subodh Iyengar escribi=F3:
>
> A few colleagues, Kyle Nekritz, Alan Frindell and I were discussing > QUIC's behavior when source IP changes.
>
> After a QUIC connection is fully established, when a client's
> source IP changes due to a NAT, the server would need to cache the > last known IP address because future UDP writes would go to the new > source IP. How should the server validate that the new IP is a
> reasonable address to send traffic if the sender is actually an attack= er?
>
> Simply validating the cryptographic authenticity of packet doesn't > seem like it is enough since an attacker can change their IP without <= br> > violating the authenticity of their own packet. The server could use <= br> > some heuristics to validate the source IP, for example, the client > didn't change it's ASN or subnet. However, without any validation it <= br> > would seem like an attacker could initially use the source token
> during connection establishment to prove possession of their IP, but <= br> > later when a connection id is bound, they could change their IP to a <= br> > target IP which they want to send amplification traffic to.
>
> Do current deployments of QUIC use some other techniques to validate <= br> > IP address when it does change? Do we need a feature for the server to=
> be able to request revalidation in the middle of a connection?
>
>
> Subodh Iyengar
>

--_000_MWHPR15MB145508213C129C64B8C2AD71B6280MWHPR15MB1455namp_-- From nobody Thu Mar 2 14:28:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51449126BF7 for ; Thu, 2 Mar 2017 14:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-1J20Z8Zjwp for ; Thu, 2 Mar 2017 14:28:21 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 27111128B38 for ; Thu, 2 Mar 2017 14:28:21 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n127so148804657qkf.0 for ; Thu, 02 Mar 2017 14:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PyxOzh7erbmQ0a/W5avu8JG67fVU9ij+1ZnOGqXfUd8=; b=PvpO/kohjA+MOEGwZEnRyp2Hi/1ErEw7mVxPuwDee8kweL0QBvlQ5B2qcv34TyviLb Nx/2+2MU/48VGQrJF//DmT8PEWNwEsl5+Y/Ls4ZHYGOfhCAXGORUAuHxUeG+8MWqSiIg WTZiTEH/CJts+sOEGswbykt5p6Vr/W7jDUVW3fCkkI0Y0C8czEtV/7doeVMgMVWSfIOn +pjzHA+v5bnKpvs0pnQLWjnU2SOwQHNgoKEXZiVml1cLoSULSbTFO1k8kf8ImS/JXot9 rCgsQWBU9+y0txHVsoUSCLWtsXgOObvt6Z0vP/sRRvkx9YI3IlwGc8d7dNaefTYuHXPt 72pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PyxOzh7erbmQ0a/W5avu8JG67fVU9ij+1ZnOGqXfUd8=; b=By02CtP75g5skzWpGCA0Yto1t6uuphDEkBESPY9byKV2zRBdBcYQajZBmrJ8+64VHp kmBHlH/WX7eLes1OketFDLHNVayi1+B2raAIknoYwldStaCUCpL0eViQlEyeOeXgwyvI pQRUsrPKFIdwRxKHtyMfVqNlUAmKrUxczgbn/HyuKsIcocj1w5oiVjGJsY0u3C3J3CW3 ON3D/OK9S/oYS+QbVVWsDVBYYTteNSLvX6IXF2PVR6qsuzgHd7c2l6X+GFz2kuyvxkck T9lqukKlTRbhEZ3IOvLUQ8ysNwYgIgvEGLxEpdkmBfVMogMqtmaTQHznB1YBlGK6zu+y WzMQ== X-Gm-Message-State: AMke39na8YmU1VojS7E0NJ2cFgpQf8KrqJAxojeWgwbjdO6xwUnzMSqd6ccJt8+acdNKn/xlGHRTME1M7xR+vg== X-Received: by 10.200.46.91 with SMTP id s27mr21091799qta.278.1488493700243; Thu, 02 Mar 2017 14:28:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 2 Mar 2017 14:28:19 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 3 Mar 2017 09:28:19 +1100 Message-ID: Subject: Re: Changing IPs and amplificiation To: Subodh Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:28:22 -0000 On 3 March 2017 at 06:49, Subodh Iyengar wrote: > How should the server validate that the new IP is a reasonable address to > send traffic if the sender is actually an attacker? This is a question that already has an issue: https://github.com/quicwg/base-drafts/issues/161 I don't believe that it has an answer. The only possible answer that was offered was some combination of the server skipping packet numbers and then observing acks. That's a pretty low bandwidth channel. From nobody Thu Mar 2 16:32:07 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7A129667; Thu, 2 Mar 2017 16:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 71_NO8TlPCzj; Thu, 2 Mar 2017 16:32:05 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED172129607; Thu, 2 Mar 2017 16:32:04 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id 62so48477462oih.2; Thu, 02 Mar 2017 16:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jNguigdapbh9EUIbgs3I3GuPZSdTTRVrzntkbfnIAD8=; b=PvlLdrMiv2rfpsjFOFfShkDU+GB5SM6frhX8lXmsEdtaUqKoRBhMaymzR8fXJ7umVp cCDN8IjRTjQRtRCfGybQrkV2AF1QMk/uYi83nnbfGgZ6GqqP7fDpG/hNt8XSuigTxowT mfcaf/pDhXrU7qyBfRLbnipdOxsmri8N3XSFdrs+ns83cBdFEgk87xSpIQDj8SPK+b1P RSJdt6Cy3ekgFtoJl6G970kwWq8gsd7RmuN/OtNnOjjz3IhIXbDVM9suOgM5WysBDZ2m 8huzw67GV7+o3JaNWxViAnJnEQ5TpFyt7Ob24fBmLhTxEHUIw03bzVEbVUzzIQDIQPIx uwPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jNguigdapbh9EUIbgs3I3GuPZSdTTRVrzntkbfnIAD8=; b=a7hciE62KkhNk6ivaF7xL8LxRLMVEK0ZHjfB/i5XHygUeR/+RRkAI5kXlDQ3reY4N6 6UZ3MM53BsTaRrFXBXXVgcvGiPcPHpIt6EC/WUnaRJRL/O4NB8fvyCkGjbCmkLfyR6Ij Iqitbi6M5Xxg/RJaZTopc4egJVvVj6QznoTco9Gdtf4HXeIS3bw39XAWCIbyyECMONQH BNECx1Ufc4jgTitW27wz/gHfcPob9QArwT7scoMp2K07BhgrCBks51HpZseMU9pSr23B tFvbEwL4gMu/F+djrSLHqA1Elx07WOS6V0dPIIWSR3K0RqH9x+44H7R8iKheAiomGYMo hdfQ== X-Gm-Message-State: AMke39khJKAALsTrrAKl+JxjcYfMOuj9WyRTKndW8MzTeLXrNuwz9iHKPBzSWkGCKXwyKJvzZKwjuzjRZu4YRw== X-Received: by 10.202.216.139 with SMTP id p133mr5476oig.109.1488501124439; Thu, 02 Mar 2017 16:32:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Thu, 2 Mar 2017 16:32:04 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Thu, 2 Mar 2017 16:32:04 -0800 Message-ID: Subject: Re: sending an retransmitting packets in draft-ietf-quic-recovery To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a113d59aec527aa0549c8ac0b Archived-At: Cc: draft-ietf-quic-recovery@ietf.org, Ian Swett , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:32:06 -0000 --001a113d59aec527aa0549c8ac0b Content-Type: text/plain; charset=UTF-8 Some additional issues with this draft: - What is (acked_packet) when the alarm fires? - I'm not sure how DetectLostPackets supports RTOs. If we only iterate until reaching the largest acked packet, then we'll never check packets beyond that for loss. On Mon, Feb 20, 2017 at 1:18 AM, marcelo bagnulo braun wrote: > Hi, > > I am going though the loss detection algorithm described in section 3 of > draft-ietf-quic-recovery-01 and I have a question. > > I see that the MaybeRetransmitLostPackets() function is only called on > Alarm firing. In particular, the > MaybeRetransmitLostPackets() is not called when receiving in ack. > > Is that a mistake? > > I find strange that upon reception of an ACK, that determines that some > packets are lost, the retransmission function is called right away but a > timer is set and retransmission is triggered RTT/4 time later. > > Also, I guess upon ack reception, if no loss is detected but the windows > moves, new data should be transmitted and while i understand that the loss > detection algorithm may not be the right place to define the rules for > transmitting new packets, it may be worth mentioning it. > > Regards, marcelo > > --001a113d59aec527aa0549c8ac0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some additional issues with this draft:

- What is (acked_packet) when the alarm fires?

- = I'm not sure how DetectLostPackets supports RTOs. If we only iterate un= til reaching the largest acked packet, then we'll never check packets b= eyond that for loss.

On Mon, Feb 20, 2017 at 1:18 AM, marcelo bagnulo braun <= marcelo@it.uc3m.es> wrote:
= Hi,

I am going though the loss detection algorithm described in section 3 of dr= aft-ietf-quic-recovery-01 and I have a question.

I see that the MaybeRetransmitLostPackets() function is only called on Alar= m firing. In particular, the
MaybeRetransmitLostPackets() is not called when receiving in ack.

Is that a mistake?

I find strange that upon reception of an ACK, that determines that some pac= kets are lost, the retransmission function is called right away but a timer= is set and retransmission is triggered RTT/4 time later.

Also, I guess upon ack reception, if no loss is detected but the windows mo= ves, new data should be transmitted and while i understand that the loss de= tection algorithm may not be the right place to define the rules for transm= itting new packets, it may be worth mentioning it.

Regards, marcelo


--001a113d59aec527aa0549c8ac0b-- From nobody Thu Mar 2 18:19:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F311293DA for ; Thu, 2 Mar 2017 18:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 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, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=hKSdLMat; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=UtFtTmnj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ99QVBxt7SI for ; Thu, 2 Mar 2017 18:18:58 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386E71279EB for ; Thu, 2 Mar 2017 18:18:58 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2329fqZ014510; Thu, 2 Mar 2017 18:18:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=R7Cc7sEpMIKd3Ki8E9gLoIWEhCgrSPOx2Nr2gEpU55U=; b=hKSdLMat0xt590FDQaqjrz/zPUxLWnJUsJ1Ez8wVmFmYgHBGzSnIDLxSaoeLncz+TnhU qrh/dVC24VoJSgmTucKuqjtxgBOofprLp7o4LTzZuL4RjSF85VZeUcGNFUOK98NxCIp0 W0lWEaJT/JSQkMJNlz4OoqRb4Si66bi/zVU= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 28xs8bhqe0-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 02 Mar 2017 18:18:57 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.18) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 2 Mar 2017 18:18:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R7Cc7sEpMIKd3Ki8E9gLoIWEhCgrSPOx2Nr2gEpU55U=; b=UtFtTmnj/refB9Qqi8llnDrT0AfKj3zEIcoliUdqZBkG/+Lc76uxUoPtNrmDC5SfYv+FPaqdoo60WJRGo4r3hKTkFKzTjJOnmK+iwgELw0OrB1cA1CGXcIEI/+Jzb5KLeq2M+xkpmMLRzGxD98+TFpyr+qVwYWIU/VmEm9uDJE8= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Fri, 3 Mar 2017 02:18:54 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0933.020; Fri, 3 Mar 2017 02:18:54 +0000 From: Subodh Iyengar To: Martin Thomson Subject: Re: Changing IPs and amplificiation Thread-Topic: Changing IPs and amplificiation Thread-Index: AQHSk4vZzdVTj95ycU+HkqruhCBHAKGCIX6AgAA/+lM= Date: Fri, 3 Mar 2017 02:18:54 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-ms-office365-filtering-correlation-id: 571fe38c-1c22-4a85-7b00-08d461dba461 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1456; x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:fEfN657egQwfFzrb65CSb9XcEhJBB56B2lx26WHyegJXSOkUVnRaVsFMLC2VQiI8WLETNfrgWAcJSCOqLlUvBnVO+DyNVMx1FwHtxYdQuTCruGbS20Ln+JK2lb3Xk6GZSmt8RbaMjqzLYm+ZDESCdyk7qjQ3/dN0HL1BkT+siuE6jJpnsTbuphpwP0865NqZVKFc+om9Mjq//j4Lzcg/RV+CmJBqSz1xW7h8gFJMRmq+Xm2MiOxQXxrsi+GHpInA/szTfq1/C3UQrzuB5msfCOzFLon1e0akFlBRTGp5IBNama15z46eWdo6gAhW6W0QY7g9lFPqubv3jmDf55WVfA==; 20:1oTcQtMsdBHk2RnUCMKBryNgen0tHyZJcIZmQ/HNcSwYvH8DaKc7K8sxgx1q99H5Q/gbDNmJkOCtuHpYMkblB5t/KECyVJHNVMxm9VG4ATg//FJH+51GPYESw+x08pyWK4MsCIjI8kqa1l31crp8z9eKcGokztATZCMwFNS6Yl0= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148)(6042181); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(2950100002)(66066001)(81166006)(122556002)(8676002)(4326008)(6916009)(106116001)(2900100001)(33656002)(189998001)(7736002)(86362001)(77096006)(2906002)(5660300001)(38730400002)(3660700001)(229853002)(53546006)(236005)(92566002)(76176999)(3280700002)(3846002)(7696004)(54356999)(25786008)(6306002)(8936002)(102836003)(3480700004)(39060400002)(606005)(6436002)(55016002)(7906003)(6506006)(74316002)(6246003)(6116002)(99286003)(54896002)(110136004)(53936002)(50986999)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455E31056E804FEA3C332DDB62B0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 02:18:54.7204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-03_01:, , signatures=0 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:18:59 -0000 --_000_MWHPR15MB1455E31056E804FEA3C332DDB62B0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Martin, missed that open issue. Subodh ________________________________ From: QUIC on behalf of Martin Thomson Sent: Thursday, March 2, 2017 2:28:19 PM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: Changing IPs and amplificiation On 3 March 2017 at 06:49, Subodh Iyengar wrote: > How should the server validate that the new IP is a reasonable address to > send traffic if the sender is actually an attacker? This is a question that already has an issue: https://github.com/quicwg/base-drafts/issues/161 I don't believe that it has an answer. The only possible answer that was offered was some combination of the server skipping packet numbers and then observing acks. That's a pretty low bandwidth channel. --_000_MWHPR15MB1455E31056E804FEA3C332DDB62B0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Martin, missed that open issue.


Subodh

From: QUIC <quic-bounc= es@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>= ;
Sent: Thursday, March 2, 2017 2:28:19 PM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: Changing IPs and amplificiation
 
On 3 March 2017 at 06:49, Subodh Iyengar <subod= h@fb.com> wrote:
> How should the server validate that the new IP is a reasonable address= to
> send traffic if the sender is actually an attacker?

This is a question that already has an issue:

https://github= .com/quicwg/base-drafts/issues/161

I don't believe that it has an answer.  The only possible answer that<= br> was offered was some combination of the server skipping packet numbers
and then observing acks.  That's a pretty low bandwidth channel.

 --_000_MWHPR15MB1455E31056E804FEA3C332DDB62B0MWHPR15MB1455namp_-- From nobody Thu Mar 2 18:26:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5E129456 for ; Thu, 2 Mar 2017 18:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 rIC5NnGOKjKY for ; Thu, 2 Mar 2017 18:26:55 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2459112943F for ; Thu, 2 Mar 2017 18:26:55 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id 1so36517940qkl.3 for ; Thu, 02 Mar 2017 18:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EBbo72INPJBCiwIzzpC716G78n8P1eJa8J9TQIg4Y9c=; b=etrdmeWrq6hCQVFGsfwKlChlHSZ24ydJ1FZvDgVHphhl8deS+C1ytTx7bR4ap199Ss quleGroVsD/7ywDwHO1zFM2M38+G3PuT/Ji0lOoD8HDEzS1P3Jj2fKaQOzP8+pHnNzd7 Q0I5sc2XDCSd7uJ89N8tFOTcKPQdCoO1Km2IVrTDZWYZZZDVpUJBKmuVLGHB25u0OqGm aJyUvqqiCabhgV/Ephi+DRgt5GObU0s5f1t95xr1MK6SFqgcUG8aJ0xHtO9hJdAszwP7 FIfVAr1qL5Bp8TjgiT1yJDb2qFUApFqbMFw75hguFPn+njSTHMQQMtcfG+Be8r4RVIEP Hobg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EBbo72INPJBCiwIzzpC716G78n8P1eJa8J9TQIg4Y9c=; b=lrdNytbMWTzZWLr6+A7PfX5QHifP4OzRV/V5Z7MylvyUcmtimb2/rU9/ZdsMDJSDDO P4ONGJNYRrlRCI9jXuK+OYCnJy20igGBPFigmkf1Fel+NxgBM6QdON4Qi3bllzvwZfdt PRoNcxVwJk4Nn+UOubEi+bepyXrditcgz5v7M8qxfkj6waYiga/Cfuipxu4vq2TfDAnT YnddWmkGpJ1ATz7dQFVHxitP2LcjZNFDEEPeoCdCRnqkbHpqpsyb9HehOsqurbOv5DO8 9Vo8An3knZA/2Qvvqy78RyAJ0+9VzarwvCatVmUY1iHLpE/8RIgjRoamdtFImeckP6LT 0qHg== X-Gm-Message-State: AMke39mtPsgbsmN6HDGROeQur2AZPQht3bZJX9k8ikSJmVYlah9eGde4eirEEcuLAkKcy7rzsihG6xjecyXd1Q== X-Received: by 10.200.3.214 with SMTP id z22mr423468qtg.3.1488508014306; Thu, 02 Mar 2017 18:26:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 2 Mar 2017 18:26:53 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 3 Mar 2017 13:26:53 +1100 Message-ID: Subject: Re: Changing IPs and amplificiation To: Subodh Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:26:56 -0000 Easy to miss given the number we have right now. If you have any ideas on how we might *solve* this, I'm sure we'd be interested to discuss those ideas. I have some ideas, but they are all either kludgy or gross in some measure. On 3 March 2017 at 13:18, Subodh Iyengar wrote: > Thanks Martin, missed that open issue. > > > Subodh > > ________________________________ > From: QUIC on behalf of Martin Thomson > > Sent: Thursday, March 2, 2017 2:28:19 PM > To: Subodh Iyengar > Cc: quic@ietf.org > Subject: Re: Changing IPs and amplificiation > > On 3 March 2017 at 06:49, Subodh Iyengar wrote: >> How should the server validate that the new IP is a reasonable address to >> send traffic if the sender is actually an attacker? > > This is a question that already has an issue: > > https://github.com/quicwg/base-drafts/issues/161 > > I don't believe that it has an answer. The only possible answer that > was offered was some combination of the server skipping packet numbers > and then observing acks. That's a pretty low bandwidth channel. > From nobody Thu Mar 2 23:02:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5746F120725 for ; Thu, 2 Mar 2017 23:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Qz37KKaC2F24 for ; Thu, 2 Mar 2017 23:02:55 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C961F127077 for ; Thu, 2 Mar 2017 23:02:54 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id f54so104371845uaa.1 for ; Thu, 02 Mar 2017 23:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0/zayF94zYEzQE15U/NEkzEVdb1lXaI8HI6X70+gQlM=; b=MCInK70WfJbkOpwC2C1NZX/dioTTZkYgZ3DtVq2rpAr8DxhiyMowRY4X2rQiUwrrzU WwZBvh7SJ7BQSuIV/F2Tf1WqGuT3UpATfVStl9mR48duHERz6GvExM//cw3PL7Dc5/V/ RuiB+YwmdAGQBvjaJLdidBugPkNcA0QkDk0pgXIWLsFhPJPi9nWh7fMIxgUQfqyJ/MWY Eo3qq29OYs1H/QYeLEF4KOJVsORG5gb2+wVUlRS0gtcLAHD+01wagSH37q3ychBO5f3S XI+fiGCnJKwQbKZXukbgOhLp6YAIyy+ba6oPdmeXmRGiYQPe4fhwLrv+w36L1GbnQPsN f6hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0/zayF94zYEzQE15U/NEkzEVdb1lXaI8HI6X70+gQlM=; b=DlvgNciCAlB3TG+Aau2MrOMIXiFtsANDhyYlDIZnUa8D6B0MhY6Z1083BOJb/oERoG tzTmygUDVRE1YNFRJNhAkJ5SWqxaleHu9ZrQ7JzoQsxjVOK6eIhCfrA/qBUrWBapBHEr MMVb4dPY+8RkU5Bv+iBICPWBwXrYDhkM12juPn5cytx/MxbfrGqsbME2+mXsxhWUvvU2 YSH4ASg+3hrnRxTG0BqX0Fmx7+FsgrTSXpTOVLSD67VXOjVjaMAmwXBrWILJwEVuYvDJ zqckBZCwXn2sEt5+5id0e8xYUie9izlU0gEMWAo7bBccPMg3MclEa+2bgJm/aF2RQx0t m1Fw== X-Gm-Message-State: AMke39nV2qXCcOzCDyNRxuieuED/dFL0vtPyiUZzF2C6/CpiZZNUcSavHasMyVmzrFFzYY6tfG5UNmTU2k0SmOhY X-Received: by 10.31.15.211 with SMTP id 202mr328631vkp.151.1488524573489; Thu, 02 Mar 2017 23:02:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 2 Mar 2017 23:02:52 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 2 Mar 2017 23:02:52 -0800 Message-ID: Subject: Re: Changing IPs and amplificiation To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1143b4b471aa470549ce22ef Archived-At: Cc: Subodh Iyengar , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 07:02:56 -0000 --001a1143b4b471aa470549ce22ef Content-Type: text/plain; charset=UTF-8 Subodh, AFAICT, there are three issues here, and I think they're solvable. (I'll add this to the github issue.) 1. Amplification attack, where an attacker grows server's cwnd to a large value and then sends a spoofed packet with the victim's IP, causing a large amount of data to be dumped on the victim. Solution: When a server observes a change in the client's IP address, it records the current cwnd, clamps the cwnd down to MIN_CWND, and sends a PING frame to the new IP. When a packet sent to the new IP address is acked, the cwnd is restored. 2. Optimistic ack attack, where the attacker optimistically acks the PING packet sent by the server to the victim's IP, causing the server to again unleash it's large cwnd on the victim. Solution: On a change in the client's IP address, the server introduces a randomly sized gap in the packet sequence space. Any new data will now still be sent to the new client IP, but the sequence numbers will be discontiguous from transmissions to the old IP. Any acks for packets in the gap will result in an immediate termination of the connection. A malicious client will now have to either correctly guess the exact size of this gap or read packets going to the victim. 3. There's a slightly tricky issue hidden in here. Say a server observes an address change from IP A to B. What should a server do if it observes another address change while it's in the middle of validating one? Solution: There are three possible scenarios. (i) If the new IP is different than A, then restart validation of the newest IP. (ii) If the new IP is the same as A and the packet is reordered, then accept the packet and continue with the current validation. (iii) If the new IP is the same as A and the packet is newer than the one that triggered the last validation, then close the connection, since this doesn't look like a NAT rebinding. (This could be a MITM, who changes the IP address of one client -> server packet, hoping that the server reduces its cwnd or latches on to this new IP, causing a DoS of sorts.) - jana On Thu, Mar 2, 2017 at 6:26 PM, Martin Thomson wrote: > Easy to miss given the number we have right now. If you have any > ideas on how we might *solve* this, I'm sure we'd be interested to > discuss those ideas. I have some ideas, but they are all either > kludgy or gross in some measure. > > On 3 March 2017 at 13:18, Subodh Iyengar wrote: > > Thanks Martin, missed that open issue. > > > > > > Subodh > > > > ________________________________ > > From: QUIC on behalf of Martin Thomson > > > > Sent: Thursday, March 2, 2017 2:28:19 PM > > To: Subodh Iyengar > > Cc: quic@ietf.org > > Subject: Re: Changing IPs and amplificiation > > > > On 3 March 2017 at 06:49, Subodh Iyengar wrote: > >> How should the server validate that the new IP is a reasonable address > to > >> send traffic if the sender is actually an attacker? > > > > This is a question that already has an issue: > > > > https://github.com/quicwg/base-drafts/issues/161 > > > > I don't believe that it has an answer. The only possible answer that > > was offered was some combination of the server skipping packet numbers > > and then observing acks. That's a pretty low bandwidth channel. > > > > --001a1143b4b471aa470549ce22ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Subodh,

AFAICT, there are th= ree issues here, and I think they're solvable. (I'll add this to th= e github issue.)

1. Amplification attack, where an= attacker grows server's cwnd to a large value and then sends a spoofed= packet with the victim's IP, causing a large amount of data to be dump= ed on the victim.
Solution: When a server observes a change in th= e client's IP address, it records the current cwnd, clamps the cwnd dow= n to MIN_CWND, and sends a PING frame to the new IP. When a packet sent to = the new IP address is acked, the cwnd is restored.

2. Optimistic ack attack, where the attacker optimistically acks the = PING packet sent by the server to the victim's IP, causing the server t= o again unleash it's large cwnd on the victim.
Solution: On a= change in the client's IP address, the server introduces a randomly si= zed gap in the packet sequence space. Any new data will now still be sent t= o the new client IP, but the sequence numbers will be discontiguous from tr= ansmissions to the old IP. Any acks for packets in the gap will result in a= n immediate termination of the connection. A malicious client will now have= to either correctly guess the exact size of this gap or read packets going= to the victim.

3. There's a slightly tr= icky issue hidden in here. Say a server observes an address change from IP = A to B. What should a server do if it observes another address change while= it's in the middle of validating one?
Solution: There are three pos= sible scenarios.
(i) If the new IP is different than A, then = restart validation of the newest IP.=C2=A0
(ii) If the new IP is = the same as A and the packet is reordered, then accept the packet and conti= nue with the current validation.=C2=A0
(iii) If the new IP is =C2= =A0the same as A and the packet is newer than the one that triggered the la= st validation, then close the connection, since this doesn't look like = a NAT rebinding. (This could be a MITM, who changes the IP address of one c= lient -> server packet, hoping that the server reduces its cwnd or latch= es on to this new IP, causing a DoS of sorts.)

- j= ana


On Thu, Mar 2, 2017 at 6:26 PM, Martin Thomson <martin= .thomson@gmail.com> wrote:
= Easy to miss given the number we have right now.=C2=A0 If you have any
ideas on how we might *solve* this, I'm sure we'd be interested to<= br> discuss those ideas.=C2=A0 I have some ideas, but they are all either
kludgy or gross in some measure.

On 3 March 2017 at 13:18, Subodh Iyengar <subodh@fb.com> wrote:
> Thanks Martin, missed that open issue.
>
>
> Subodh
>
> ________________________________
> From: QUIC <quic-bounces@i= etf.org> on behalf of Martin Thomson
> <martin.thomson@gmail.c= om>
> Sent: Thursday, March 2, 2017 2:28:19 PM
> To: Subodh Iyengar
> Cc: quic@ietf.org
> Subject: Re: Changing IPs and amplificiation
>
> On 3 March 2017 at 06:49, Subodh Iyengar <subodh@fb.com> wrote:
>> How should the server validate that the new IP is a reasonable add= ress to
>> send traffic if the sender is actually an attacker?
>
> This is a question that already has an issue:
>
> https://github.com/quicwg/base-drafts/issu= es/161
>
> I don't believe that it has an answer.=C2=A0 The only possible ans= wer that
> was offered was some combination of the server skipping packet numbers=
> and then observing acks.=C2=A0 That's a pretty low bandwidth chann= el.
>


--001a1143b4b471aa470549ce22ef-- From nobody Fri Mar 3 01:38:33 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F6C1297DE for ; Fri, 3 Mar 2017 01:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 lmRrHPXCx8_g for ; Fri, 3 Mar 2017 01:38:29 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10106.outbound.protection.outlook.com [40.107.1.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88BE1297AC for ; Fri, 3 Mar 2017 01:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PpE0kJLO3avVOd2R3igcRVIFKArE2xao+r0m4VtZVMM=; b=tjS8byrCmwjWKL0ctRUUBCwu4optgKHk5oqzblststq7WDJ0B5wiJ98+T15sojb31e8Tn5J16gDvdic10b9CXqFdd7AQlKLTq2mh/ts0a6UR7GrMaJSIs0TccLaMRdQpD2EicK2E1bYUlOQu+34NMy+dvP4MU0nkRtXNhMm2Z3Q= Received: from AM4PR07MB1233.eurprd07.prod.outlook.com (10.164.81.139) by AM4PR07MB1236.eurprd07.prod.outlook.com (10.164.81.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Fri, 3 Mar 2017 09:38:25 +0000 Received: from AM4PR07MB1233.eurprd07.prod.outlook.com ([10.164.81.139]) by AM4PR07MB1233.eurprd07.prod.outlook.com ([10.164.81.139]) with mapi id 15.01.0947.015; Fri, 3 Mar 2017 09:38:25 +0000 From: "Swindells, Thomas (Nokia - GB)" To: Jana Iyengar , Martin Thomson Subject: RE: Changing IPs and amplificiation Thread-Topic: Changing IPs and amplificiation Thread-Index: AQHSk4vZzdVTj95ycU+HkqruhCBHAKGCIX6AgAA/+lOAAAKtgIAATRwAgAAgLPA= Date: Fri, 3 Mar 2017 09:38:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [86.187.246.98] x-ms-office365-filtering-correlation-id: eece0cef-38c9-45eb-fd6f-08d462190a5f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:AM4PR07MB1236; x-microsoft-exchange-diagnostics: 1; AM4PR07MB1236; 7:i5QqOIgo7Wg5nulM5Y+qcJ0UTfWl1XavPB+6DWejzFDOL+00yuP8i20q1hm881kGwfJTaxBEyFwhIptW3Zr36+kFaAP4TUbIH8153IxDb6oH2AIbUsiLizwUTgm+xwqP8PGlhMbylOh8HACuI4uJUoPLLHYcc8G2N2F5bFmFMElYdVxq0I7U3stxCdvscFAQPrQWt+Gr8QV1rNwLh4pNMgGPN93lsppPn8ILB7194am9S9U/x0H1PRsHBlk6hu55odXGeH4HYyoSpKPE9VMOe12BovcwvMDXTtP9mz1whpxKd/XeI3P0UQL1tG0y8VAOVmLZjTTWI3h2DOBMmSkOaQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM4PR07MB1236; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1236; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39840400002)(39410400002)(39860400002)(24454002)(377454003)(53936002)(2906002)(54356999)(6246003)(53546006)(122556002)(50986999)(39060400002)(106116001)(7736002)(189998001)(229853002)(3280700002)(8676002)(76176999)(5660300001)(236005)(66066001)(77096006)(4326008)(6116002)(81166006)(3480700004)(2950100002)(93886004)(3660700001)(74316002)(7696004)(3846002)(102836003)(790700001)(33656002)(99286003)(25786008)(54906002)(86362001)(9686003)(92566002)(55016002)(6306002)(38730400002)(6506006)(2900100001)(7906003)(606005)(6436002)(54896002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1236; H:AM4PR07MB1233.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR07MB123369BCCABE9E2499637609842B0AM4PR07MB1233eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 09:38:25.1974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1236 Archived-At: Cc: Subodh Iyengar , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:38:32 -0000 --_000_AM4PR07MB123369BCCABE9E2499637609842B0AM4PR07MB1233eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJlc3VtYWJseSBBLT5CLT5BIHdvdWxkIHBvdGVudGlhbGx5IGhhcHBlbiBjb21tb25seSB3aXRo IGRldmljZXMgd2hpY2ggYXJlIGZsaXAgZmxvcHBpbmcgYmV0d2VlbiBhIHdpZmkgYW5kIG1vYmls ZSBjb25uZWN0aW9uPyBUaGlzIHdvdWxkIG1lYW4gdGhhdCBOQVQgcmViaW5kaW5ncyBhcmVu4oCZ dCBnb2luZyB0byBiZSB0aGUgb25seSBjb21tb24gY2F1c2Ugb2YgSVAgYWRkcmVzcyBjaGFuZ2Vz Lg0KDQpBcG9sb2dpZXMgaWYgdGhpcyBpcyBhIHN0dXBpZCBxdWVzdGlvbiwgYnV0IHdoYXQgbGV2 ZWwgb2YgYXV0aGVudGljYXRpb24gd2lsbCB0aGUgcGFja2V0IHdoaWNoIGlzIG1hcmtlZCBhcyBj b21pbmcgZnJvbSBJUCBCIHVuZGVyZ28/IENhbiBhbiBhdHRhY2tlciBzaW1wbHkgcmVwbGF5IGEg Z2VudWluZSBwYWNrZXQgdG8gdGhlIHNlcnZlciwgbW9kaWZ5aW5nIGl0IHdpdGggYSBkaWZmZXJl bnQgc291cmNlIGFkZHJlc3MsIG9yIGRvZXMgdGhlIHBhY2tldCBudW1iZXIgYW5kIG90aGVyIGlu Zm9ybWF0aW9uIGFsc28gbmVlZCB0byBiZSBtb2RpZmllZCwgYW5kIGlmIHNvIGRvZXMgdGhpcyBy ZXF1aXJlIHRoZW0gdG8gaGF2ZSBwYXJ0cyBvZiB0aGUgZW5jcnlwdGlvbiBjb250ZXh0PyBJZiB0 aGUgcGFja2V0cyBhcmUgc3Ryb25nbHkgYXV0aGVudGljYXRlZCB0aGVuIGl0IHNlZW1zIGxpa2Ug dGhlIHByb2JhYmlsaXR5IGlzIHRoYXQgaXQgaXMgYSBjbGllbnQgKG9yIGdhdGV3YXkpIGZsaXAt ZmxvcHBpbmcgYmV0d2VlbiBhZGRyZXNzZXMgcmF0aGVyIHRoYW4gYW4gYXR0YWNrZXIsIGFuZCBr ZWVwaW5nIHRoZSBjb25uZWN0aW9uIGFsaXZlIGlzIHRoZSBkZXNpcmVkIGJlaGF2aW91ci4NCg0K VGhvbWFzDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IDAzIE1hcmNoIDIwMTcgMDc6MDMNClRvOiBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IFN1Ym9kaCBJeWVuZ2Fy IDxzdWJvZGhAZmIuY29tPjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IENoYW5naW5nIElQ cyBhbmQgYW1wbGlmaWNpYXRpb24NCg0KU3Vib2RoLA0KDQpBRkFJQ1QsIHRoZXJlIGFyZSB0aHJl ZSBpc3N1ZXMgaGVyZSwgYW5kIEkgdGhpbmsgdGhleSdyZSBzb2x2YWJsZS4gKEknbGwgYWRkIHRo aXMgdG8gdGhlIGdpdGh1YiBpc3N1ZS4pDQoNCjEuIEFtcGxpZmljYXRpb24gYXR0YWNrLCB3aGVy ZSBhbiBhdHRhY2tlciBncm93cyBzZXJ2ZXIncyBjd25kIHRvIGEgbGFyZ2UgdmFsdWUgYW5kIHRo ZW4gc2VuZHMgYSBzcG9vZmVkIHBhY2tldCB3aXRoIHRoZSB2aWN0aW0ncyBJUCwgY2F1c2luZyBh IGxhcmdlIGFtb3VudCBvZiBkYXRhIHRvIGJlIGR1bXBlZCBvbiB0aGUgdmljdGltLg0KU29sdXRp b246IFdoZW4gYSBzZXJ2ZXIgb2JzZXJ2ZXMgYSBjaGFuZ2UgaW4gdGhlIGNsaWVudCdzIElQIGFk ZHJlc3MsIGl0IHJlY29yZHMgdGhlIGN1cnJlbnQgY3duZCwgY2xhbXBzIHRoZSBjd25kIGRvd24g dG8gTUlOX0NXTkQsIGFuZCBzZW5kcyBhIFBJTkcgZnJhbWUgdG8gdGhlIG5ldyBJUC4gV2hlbiBh IHBhY2tldCBzZW50IHRvIHRoZSBuZXcgSVAgYWRkcmVzcyBpcyBhY2tlZCwgdGhlIGN3bmQgaXMg cmVzdG9yZWQuDQoNCjIuIE9wdGltaXN0aWMgYWNrIGF0dGFjaywgd2hlcmUgdGhlIGF0dGFja2Vy IG9wdGltaXN0aWNhbGx5IGFja3MgdGhlIFBJTkcgcGFja2V0IHNlbnQgYnkgdGhlIHNlcnZlciB0 byB0aGUgdmljdGltJ3MgSVAsIGNhdXNpbmcgdGhlIHNlcnZlciB0byBhZ2FpbiB1bmxlYXNoIGl0 J3MgbGFyZ2UgY3duZCBvbiB0aGUgdmljdGltLg0KU29sdXRpb246IE9uIGEgY2hhbmdlIGluIHRo ZSBjbGllbnQncyBJUCBhZGRyZXNzLCB0aGUgc2VydmVyIGludHJvZHVjZXMgYSByYW5kb21seSBz aXplZCBnYXAgaW4gdGhlIHBhY2tldCBzZXF1ZW5jZSBzcGFjZS4gQW55IG5ldyBkYXRhIHdpbGwg bm93IHN0aWxsIGJlIHNlbnQgdG8gdGhlIG5ldyBjbGllbnQgSVAsIGJ1dCB0aGUgc2VxdWVuY2Ug bnVtYmVycyB3aWxsIGJlIGRpc2NvbnRpZ3VvdXMgZnJvbSB0cmFuc21pc3Npb25zIHRvIHRoZSBv bGQgSVAuIEFueSBhY2tzIGZvciBwYWNrZXRzIGluIHRoZSBnYXAgd2lsbCByZXN1bHQgaW4gYW4g aW1tZWRpYXRlIHRlcm1pbmF0aW9uIG9mIHRoZSBjb25uZWN0aW9uLiBBIG1hbGljaW91cyBjbGll bnQgd2lsbCBub3cgaGF2ZSB0byBlaXRoZXIgY29ycmVjdGx5IGd1ZXNzIHRoZSBleGFjdCBzaXpl IG9mIHRoaXMgZ2FwIG9yIHJlYWQgcGFja2V0cyBnb2luZyB0byB0aGUgdmljdGltLg0KDQozLiBU aGVyZSdzIGEgc2xpZ2h0bHkgdHJpY2t5IGlzc3VlIGhpZGRlbiBpbiBoZXJlLiBTYXkgYSBzZXJ2 ZXIgb2JzZXJ2ZXMgYW4gYWRkcmVzcyBjaGFuZ2UgZnJvbSBJUCBBIHRvIEIuIFdoYXQgc2hvdWxk IGEgc2VydmVyIGRvIGlmIGl0IG9ic2VydmVzIGFub3RoZXIgYWRkcmVzcyBjaGFuZ2Ugd2hpbGUg aXQncyBpbiB0aGUgbWlkZGxlIG9mIHZhbGlkYXRpbmcgb25lPw0KU29sdXRpb246IFRoZXJlIGFy ZSB0aHJlZSBwb3NzaWJsZSBzY2VuYXJpb3MuDQooaSkgSWYgdGhlIG5ldyBJUCBpcyBkaWZmZXJl bnQgdGhhbiBBLCB0aGVuIHJlc3RhcnQgdmFsaWRhdGlvbiBvZiB0aGUgbmV3ZXN0IElQLg0KKGlp KSBJZiB0aGUgbmV3IElQIGlzIHRoZSBzYW1lIGFzIEEgYW5kIHRoZSBwYWNrZXQgaXMgcmVvcmRl cmVkLCB0aGVuIGFjY2VwdCB0aGUgcGFja2V0IGFuZCBjb250aW51ZSB3aXRoIHRoZSBjdXJyZW50 IHZhbGlkYXRpb24uDQooaWlpKSBJZiB0aGUgbmV3IElQIGlzICB0aGUgc2FtZSBhcyBBIGFuZCB0 aGUgcGFja2V0IGlzIG5ld2VyIHRoYW4gdGhlIG9uZSB0aGF0IHRyaWdnZXJlZCB0aGUgbGFzdCB2 YWxpZGF0aW9uLCB0aGVuIGNsb3NlIHRoZSBjb25uZWN0aW9uLCBzaW5jZSB0aGlzIGRvZXNuJ3Qg bG9vayBsaWtlIGEgTkFUIHJlYmluZGluZy4gKFRoaXMgY291bGQgYmUgYSBNSVRNLCB3aG8gY2hh bmdlcyB0aGUgSVAgYWRkcmVzcyBvZiBvbmUgY2xpZW50IC0+IHNlcnZlciBwYWNrZXQsIGhvcGlu ZyB0aGF0IHRoZSBzZXJ2ZXIgcmVkdWNlcyBpdHMgY3duZCBvciBsYXRjaGVzIG9uIHRvIHRoaXMg bmV3IElQLCBjYXVzaW5nIGEgRG9TIG9mIHNvcnRzLikNCg0KLSBqYW5hDQoNCg0KT24gVGh1LCBN YXIgMiwgMjAxNyBhdCA2OjI2IFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCkVhc3kgdG8g bWlzcyBnaXZlbiB0aGUgbnVtYmVyIHdlIGhhdmUgcmlnaHQgbm93LiAgSWYgeW91IGhhdmUgYW55 DQppZGVhcyBvbiBob3cgd2UgbWlnaHQgKnNvbHZlKiB0aGlzLCBJJ20gc3VyZSB3ZSdkIGJlIGlu dGVyZXN0ZWQgdG8NCmRpc2N1c3MgdGhvc2UgaWRlYXMuICBJIGhhdmUgc29tZSBpZGVhcywgYnV0 IHRoZXkgYXJlIGFsbCBlaXRoZXINCmtsdWRneSBvciBncm9zcyBpbiBzb21lIG1lYXN1cmUuDQoN Ck9uIDMgTWFyY2ggMjAxNyBhdCAxMzoxOCwgU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb208 bWFpbHRvOnN1Ym9kaEBmYi5jb20+PiB3cm90ZToNCj4gVGhhbmtzIE1hcnRpbiwgbWlzc2VkIHRo YXQgb3BlbiBpc3N1ZS4NCj4NCj4NCj4gU3Vib2RoDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uDQo+IDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+ DQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyLCAyMDE3IDI6Mjg6MTkgUE0NCj4gVG86IFN1Ym9k aCBJeWVuZ2FyDQo+IENjOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KPiBT dWJqZWN0OiBSZTogQ2hhbmdpbmcgSVBzIGFuZCBhbXBsaWZpY2lhdGlvbg0KPg0KPiBPbiAzIE1h cmNoIDIwMTcgYXQgMDY6NDksIFN1Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIuY29tPG1haWx0bzpz dWJvZGhAZmIuY29tPj4gd3JvdGU6DQo+PiBIb3cgc2hvdWxkIHRoZSBzZXJ2ZXIgdmFsaWRhdGUg dGhhdCB0aGUgbmV3IElQIGlzIGEgcmVhc29uYWJsZSBhZGRyZXNzIHRvDQo+PiBzZW5kIHRyYWZm aWMgaWYgdGhlIHNlbmRlciBpcyBhY3R1YWxseSBhbiBhdHRhY2tlcj8NCj4NCj4gVGhpcyBpcyBh IHF1ZXN0aW9uIHRoYXQgYWxyZWFkeSBoYXMgYW4gaXNzdWU6DQo+DQo+IGh0dHBzOi8vZ2l0aHVi LmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzE2MQ0KPg0KPiBJIGRvbid0IGJlbGlldmUg dGhhdCBpdCBoYXMgYW4gYW5zd2VyLiAgVGhlIG9ubHkgcG9zc2libGUgYW5zd2VyIHRoYXQNCj4g d2FzIG9mZmVyZWQgd2FzIHNvbWUgY29tYmluYXRpb24gb2YgdGhlIHNlcnZlciBza2lwcGluZyBw YWNrZXQgbnVtYmVycw0KPiBhbmQgdGhlbiBvYnNlcnZpbmcgYWNrcy4gIFRoYXQncyBhIHByZXR0 eSBsb3cgYmFuZHdpZHRoIGNoYW5uZWwuDQo+DQoNCg== --_000_AM4PR07MB123369BCCABE9E2499637609842B0AM4PR07MB1233eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlByZXN1bWFi bHkgQS0mZ3Q7Qi0mZ3Q7QSB3b3VsZCBwb3RlbnRpYWxseSBoYXBwZW4gY29tbW9ubHkgd2l0aCBk ZXZpY2VzIHdoaWNoIGFyZSBmbGlwIGZsb3BwaW5nIGJldHdlZW4gYSB3aWZpIGFuZCBtb2JpbGUg Y29ubmVjdGlvbj8gVGhpcyB3b3VsZCBtZWFuIHRoYXQNCiBOQVQgcmViaW5kaW5ncyBhcmVu4oCZ dCBnb2luZyB0byBiZSB0aGUgb25seSBjb21tb24gY2F1c2Ugb2YgSVAgYWRkcmVzcyBjaGFuZ2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5BcG9sb2dpZXMgaWYgdGhpcyBpcyBhIHN0dXBpZCBxdWVzdGlvbiwgYnV0 IHdoYXQgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24gd2lsbCB0aGUgcGFja2V0IHdoaWNoIGlzIG1h cmtlZCBhcyBjb21pbmcgZnJvbSBJUCBCIHVuZGVyZ28/IENhbiBhbiBhdHRhY2tlcg0KIHNpbXBs eSByZXBsYXkgYSBnZW51aW5lIHBhY2tldCB0byB0aGUgc2VydmVyLCBtb2RpZnlpbmcgaXQgd2l0 aCBhIGRpZmZlcmVudCBzb3VyY2UgYWRkcmVzcywgb3IgZG9lcyB0aGUgcGFja2V0IG51bWJlciBh bmQgb3RoZXIgaW5mb3JtYXRpb24gYWxzbyBuZWVkIHRvIGJlIG1vZGlmaWVkLCBhbmQgaWYgc28g ZG9lcyB0aGlzIHJlcXVpcmUgdGhlbSB0byBoYXZlIHBhcnRzIG9mIHRoZSBlbmNyeXB0aW9uIGNv bnRleHQ/IElmIHRoZSBwYWNrZXRzIGFyZQ0KIHN0cm9uZ2x5IGF1dGhlbnRpY2F0ZWQgdGhlbiBp dCBzZWVtcyBsaWtlIHRoZSBwcm9iYWJpbGl0eSBpcyB0aGF0IGl0IGlzIGEgY2xpZW50IChvciBn YXRld2F5KSBmbGlwLWZsb3BwaW5nIGJldHdlZW4gYWRkcmVzc2VzIHJhdGhlciB0aGFuIGFuIGF0 dGFja2VyLCBhbmQga2VlcGluZyB0aGUgY29ubmVjdGlvbiBhbGl2ZSBpcyB0aGUgZGVzaXJlZCBi ZWhhdmlvdXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRob21hczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8Yj5TZW50OjwvYj4gMDMgTWFy Y2ggMjAxNyAwNzowMzxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50 aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFN1Ym9kaCBJeWVuZ2FyICZsdDtz dWJvZGhAZmIuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog Q2hhbmdpbmcgSVBzIGFuZCBhbXBsaWZpY2lhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TdWJvZGgsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFGQUlDVCwgdGhlcmUgYXJlIHRocmVlIGlzc3VlcyBo ZXJlLCBhbmQgSSB0aGluayB0aGV5J3JlIHNvbHZhYmxlLiAoSSdsbCBhZGQgdGhpcyB0byB0aGUg Z2l0aHViIGlzc3VlLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MS4gQW1wbGlmaWNhdGlvbiBhdHRhY2ssIHdoZXJlIGFuIGF0dGFja2VyIGdy b3dzIHNlcnZlcidzIGN3bmQgdG8gYSBsYXJnZSB2YWx1ZSBhbmQgdGhlbiBzZW5kcyBhIHNwb29m ZWQgcGFja2V0IHdpdGggdGhlIHZpY3RpbSdzIElQLCBjYXVzaW5nIGEgbGFyZ2UgYW1vdW50IG9m IGRhdGEgdG8gYmUgZHVtcGVkIG9uIHRoZSB2aWN0aW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb2x1dGlvbjogV2hlbiBhIHNlcnZlciBvYnNl cnZlcyBhIGNoYW5nZSBpbiB0aGUgY2xpZW50J3MgSVAgYWRkcmVzcywgaXQgcmVjb3JkcyB0aGUg Y3VycmVudCBjd25kLCBjbGFtcHMgdGhlIGN3bmQgZG93biB0byBNSU5fQ1dORCwgYW5kIHNlbmRz IGEgUElORyBmcmFtZSB0byB0aGUgbmV3IElQLiBXaGVuIGEgcGFja2V0IHNlbnQgdG8gdGhlIG5l dyBJUCBhZGRyZXNzIGlzIGFja2VkLCB0aGUgY3duZCBpcyByZXN0b3JlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIE9wdGlt aXN0aWMgYWNrIGF0dGFjaywgd2hlcmUgdGhlIGF0dGFja2VyIG9wdGltaXN0aWNhbGx5IGFja3Mg dGhlIFBJTkcgcGFja2V0IHNlbnQgYnkgdGhlIHNlcnZlciB0byB0aGUgdmljdGltJ3MgSVAsIGNh dXNpbmcgdGhlIHNlcnZlciB0byBhZ2FpbiB1bmxlYXNoIGl0J3MgbGFyZ2UgY3duZCBvbiB0aGUg dmljdGltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U29sdXRpb246IE9uIGEgY2hhbmdlIGluIHRoZSBjbGllbnQncyBJUCBhZGRyZXNzLCB0aGUg c2VydmVyIGludHJvZHVjZXMgYSByYW5kb21seSBzaXplZCBnYXAgaW4gdGhlIHBhY2tldCBzZXF1 ZW5jZSBzcGFjZS4gQW55IG5ldyBkYXRhIHdpbGwgbm93IHN0aWxsIGJlIHNlbnQgdG8gdGhlIG5l dyBjbGllbnQgSVAsIGJ1dCB0aGUgc2VxdWVuY2UgbnVtYmVycyB3aWxsIGJlIGRpc2NvbnRpZ3Vv dXMgZnJvbSB0cmFuc21pc3Npb25zDQogdG8gdGhlIG9sZCBJUC4gQW55IGFja3MgZm9yIHBhY2tl dHMgaW4gdGhlIGdhcCB3aWxsIHJlc3VsdCBpbiBhbiBpbW1lZGlhdGUgdGVybWluYXRpb24gb2Yg dGhlIGNvbm5lY3Rpb24uIEEgbWFsaWNpb3VzIGNsaWVudCB3aWxsIG5vdyBoYXZlIHRvIGVpdGhl ciBjb3JyZWN0bHkgZ3Vlc3MgdGhlIGV4YWN0IHNpemUgb2YgdGhpcyBnYXAgb3IgcmVhZCBwYWNr ZXRzIGdvaW5nIHRvIHRoZSB2aWN0aW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gVGhlcmUncyBhIHNsaWdodGx5IHRyaWNr eSBpc3N1ZSBoaWRkZW4gaW4gaGVyZS4gU2F5IGEgc2VydmVyIG9ic2VydmVzIGFuIGFkZHJlc3Mg Y2hhbmdlIGZyb20gSVAgQSB0byBCLiBXaGF0IHNob3VsZCBhIHNlcnZlciBkbyBpZiBpdCBvYnNl cnZlcyBhbm90aGVyIGFkZHJlc3MgY2hhbmdlIHdoaWxlIGl0J3MgaW4gdGhlIG1pZGRsZSBvZiB2 YWxpZGF0aW5nIG9uZT88YnI+DQpTb2x1dGlvbjogVGhlcmUgYXJlIHRocmVlIHBvc3NpYmxlIHNj ZW5hcmlvcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPihpKSBJZiB0aGUgbmV3IElQIGlzIGRpZmZlcmVudCB0aGFuIEEsIHRoZW4gcmVzdGFydCB2 YWxpZGF0aW9uIG9mIHRoZSBuZXdlc3QgSVAuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oaWkpIElmIHRoZSBuZXcgSVAgaXMgdGhlIHNh bWUgYXMgQSBhbmQgdGhlIHBhY2tldCBpcyByZW9yZGVyZWQsIHRoZW4gYWNjZXB0IHRoZSBwYWNr ZXQgYW5kIGNvbnRpbnVlIHdpdGggdGhlIGN1cnJlbnQgdmFsaWRhdGlvbi4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihpaWkpIElmIHRo ZSBuZXcgSVAgaXMgJm5ic3A7dGhlIHNhbWUgYXMgQSBhbmQgdGhlIHBhY2tldCBpcyBuZXdlciB0 aGFuIHRoZSBvbmUgdGhhdCB0cmlnZ2VyZWQgdGhlIGxhc3QgdmFsaWRhdGlvbiwgdGhlbiBjbG9z ZSB0aGUgY29ubmVjdGlvbiwgc2luY2UgdGhpcyBkb2Vzbid0IGxvb2sgbGlrZSBhIE5BVCByZWJp bmRpbmcuIChUaGlzIGNvdWxkIGJlIGEgTUlUTSwgd2hvIGNoYW5nZXMgdGhlIElQIGFkZHJlc3Mg b2YNCiBvbmUgY2xpZW50IC0mZ3Q7IHNlcnZlciBwYWNrZXQsIGhvcGluZyB0aGF0IHRoZSBzZXJ2 ZXIgcmVkdWNlcyBpdHMgY3duZCBvciBsYXRjaGVzIG9uIHRvIHRoaXMgbmV3IElQLCBjYXVzaW5n IGEgRG9TIG9mIHNvcnRzLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMiwgMjAxNyBhdCA2OjI2IFBNLCBNYXJ0 aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FYXN5IHRvIG1pc3MgZ2l2ZW4gdGhlIG51bWJl ciB3ZSBoYXZlIHJpZ2h0IG5vdy4mbmJzcDsgSWYgeW91IGhhdmUgYW55PGJyPg0KaWRlYXMgb24g aG93IHdlIG1pZ2h0ICpzb2x2ZSogdGhpcywgSSdtIHN1cmUgd2UnZCBiZSBpbnRlcmVzdGVkIHRv PGJyPg0KZGlzY3VzcyB0aG9zZSBpZGVhcy4mbmJzcDsgSSBoYXZlIHNvbWUgaWRlYXMsIGJ1dCB0 aGV5IGFyZSBhbGwgZWl0aGVyPGJyPg0Ka2x1ZGd5IG9yIGdyb3NzIGluIHNvbWUgbWVhc3VyZS48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAzIE1hcmNoIDIwMTcgYXQgMTM6MTgsIFN1 Ym9kaCBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNvbSI+c3Vib2RoQGZi LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgVGhhbmtzIE1hcnRpbiwgbWlzc2VkIHRoYXQg b3BlbiBpc3N1ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgU3Vib2RoPGJyPg0KJmd0 Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEZy b206IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNvbjxicj4N CiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwgTWFy Y2ggMiwgMjAxNyAyOjI4OjE5IFBNPGJyPg0KJmd0OyBUbzogU3Vib2RoIEl5ZW5nYXI8YnI+DQom Z3Q7IENjOiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBDaGFuZ2luZyBJUHMgYW5kIGFtcGxpZmljaWF0aW9uPGJy Pg0KJmd0Ozxicj4NCiZndDsgT24gMyBNYXJjaCAyMDE3IGF0IDA2OjQ5LCBTdWJvZGggSXllbmdh ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iPnN1Ym9kaEBmYi5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIb3cgc2hvdWxkIHRoZSBzZXJ2ZXIgdmFsaWRhdGUgdGhh dCB0aGUgbmV3IElQIGlzIGEgcmVhc29uYWJsZSBhZGRyZXNzIHRvPGJyPg0KJmd0OyZndDsgc2Vu ZCB0cmFmZmljIGlmIHRoZSBzZW5kZXIgaXMgYWN0dWFsbHkgYW4gYXR0YWNrZXI/PGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhpcyBpcyBhIHF1ZXN0aW9uIHRoYXQgYWxyZWFkeSBoYXMgYW4gaXNzdWU6 PGJyPg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy9pc3N1ZXMvMTYxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29t L3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMTYxPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEkg ZG9uJ3QgYmVsaWV2ZSB0aGF0IGl0IGhhcyBhbiBhbnN3ZXIuJm5ic3A7IFRoZSBvbmx5IHBvc3Np YmxlIGFuc3dlciB0aGF0PGJyPg0KJmd0OyB3YXMgb2ZmZXJlZCB3YXMgc29tZSBjb21iaW5hdGlv biBvZiB0aGUgc2VydmVyIHNraXBwaW5nIHBhY2tldCBudW1iZXJzPGJyPg0KJmd0OyBhbmQgdGhl biBvYnNlcnZpbmcgYWNrcy4mbmJzcDsgVGhhdCdzIGEgcHJldHR5IGxvdyBiYW5kd2lkdGggY2hh bm5lbC48YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM4PR07MB123369BCCABE9E2499637609842B0AM4PR07MB1233eurp_-- From nobody Fri Mar 3 03:34:26 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7247212984A for ; Fri, 3 Mar 2017 03:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 mKquJqAQWHZX for ; Fri, 3 Mar 2017 03:34:24 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B19A1297CE for ; Fri, 3 Mar 2017 03:34:24 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id h9so15975011qke.2 for ; Fri, 03 Mar 2017 03:34:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z93v+Wh0yJ56iRti9GbMaPflHnORXGhS1UQvi+CI2Ro=; b=elHhSgPt+F7bzK90KZfasjVTVI9arFo7i8cHNL/bnoILI+GaYmtQtQ8SsoSGpiq2PW oe121V2icqgywpMHmO08KyANbBULcIH3jD1MQcAIJJc0Ixy45vfGP83k7mKaAeRWMDkA H+YxcVp/DFS65U9ObaghJgmnAo7FqA+FBKg7WsqFYjxJEMAHMxll2zETnuwkmEsZqE8x MqjAM47uDs7nJpRJugNR7dRlJELokj9McPG7aPZAEJm0DWHggfYmdw5eNyg/M1ZAl4Qk ngqQcECJtvo5+vVGRrTQXlgsrbgRgL/l//fuB+8nre44UCAGMwuyApuWZNCFftQUPuIb Zmug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z93v+Wh0yJ56iRti9GbMaPflHnORXGhS1UQvi+CI2Ro=; b=oBRdBuFMM3cOWnDUrUYloPo8FdnSVlevFBNWOkbAXRTmD0nUl2zYCKzl1aQBqOt+Ew UP6WBq0LLHgzlW49S5SNOjW8Q/CLyksfuFwXBQMQ19AVVQAr3p+DQNikZWllIZ9GfkL9 nzGEbdNfT8SpRllWKq1fmGeIIFEjy+37f9pXKaBYStKolH4qCf1n4Y4lSA85nj/ptUP4 GihBFwJT1JagHNSBnsgvuXreCkMSO1Jv/2Lxb4x++2XNbvgwWjrNQxjdjWlnb+j+pRpD ScdlbZHxplvTloi2vAypYuT1hN2yD/LTynE82yG02XNsYW1COAnFhMdY9rtbpVyxrrX3 F9/Q== X-Gm-Message-State: AMke39m8loVOobf+vKfAzbwJkYFAx9q0Y3i74YydULqFMk/tVamrwEbW00v9efwbyBPeEkqBeuh3G6DkSBYapA== X-Received: by 10.200.46.208 with SMTP id i16mr2121267qta.13.1488540863176; Fri, 03 Mar 2017 03:34:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Fri, 3 Mar 2017 03:34:22 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 3 Mar 2017 22:34:22 +1100 Message-ID: Subject: Re: Changing IPs and amplificiation To: "Swindells, Thomas (Nokia - GB)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , Subodh Iyengar , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 11:34:25 -0000 On 3 March 2017 at 20:38, Swindells, Thomas (Nokia - GB) wrote: > Can an attacker simply replay a genuine packet to the server, modifying it > with a different source address, or does the packet number and other > information also need to be modified, and if so does this require them to > have parts of the encryption context? If the packets are strongly > authenticated then it seems like the probability is that it is a client (or > gateway) flip-flopping between addresses rather than an attacker, and > keeping the connection alive is the desired behaviour. Packets with duplicate numbers will be dropped (they will be decoded with a vastly different packet number and decryption will then fail). As it stands, IP and port are not authenticated. I don't believe that it is possible to have a functional protocol and authenticate these. So an attacker could move packets from one path to another. But it requires an on-path attacker to receive the values on the return side. As long as we can do the return routeability check as marcelo and Jana observe, we can avoid sending too much down a path that neither the client nor the attacker are on (noting that client and attacker may be one and the same). From nobody Fri Mar 3 08:06:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9D21294CC for ; Fri, 3 Mar 2017 08:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 PffahyMdkUZ0 for ; Fri, 3 Mar 2017 08:06:13 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 656C4129490 for ; Fri, 3 Mar 2017 08:06:13 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8B95043344D; Fri, 3 Mar 2017 16:06:12 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 6A9F7433404; Fri, 3 Mar 2017 16:06:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488557172; bh=c6d2mO+S5gxl+WAM1kvsj2YY2xPTClkXyvCZc7UKbis=; l=32058; h=From:To:CC:Date:References:In-Reply-To:From; b=hQLLfJFa5Eay9LCLdLEAS8i1V+hY8t3ER//1UlJTCf3LoTdodhIw7ejKVoMdoa0KS BPy9pxISc5aL80OXH8DgW79nlpvEJUA+W6VvgaTvLCE5R/7u8/BYgDmvIhNh8GfKaN EKN041cXbJmBACpf/oTNP22YXAF49+MWflIeC3To= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 4EE041FC86; Fri, 3 Mar 2017 16:06:12 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 3 Mar 2017 11:06:11 -0500 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.1178.000; Fri, 3 Mar 2017 11:06:11 -0500 From: "Lubashev, Igor" To: Kyle Rose Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF/cgQAgAAF/ICAAAOBgIAAAjyAgAAC7gD//6yKwIABftUAgAKX3eA= Date: Fri, 3 Mar 2017 16:06:11 +0000 Message-ID: References: <00308ab6b0ac4e31bb9ec0c1fa1c22c3@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.32] Content-Type: multipart/alternative; boundary="_000_afdb0a6d928a46438e6b3b86a10d6797usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Kazuho Oku , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:06:16 -0000 --_000_afdb0a6d928a46438e6b3b86a10d6797usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBwcm9wb3NhbCBoYXMgdHdvIHBhcnRzOg0KDQpQYXJ0IDEuIEhhdmUgdGhlIGNsaWVudCBz ZWxlY3QgYSBDb25uZWN0aW9uSUQgdGhhdCBkb2VzIE5PVCBzaG93IHVwIGluIHRoZSBjbGVhciBp biBwYWNrZXRzLiBJdCBpcyBvbmx5IHNlbnQgYnkgdGhlIGNsaWVudCBlbmNyeXB0ZWQgYnkgZWl0 aGVyIDAtUlRUIG9yIDEtUlRUIGtleXMuICBDb25uZWN0aW9uIHRyYWNraW5nIGlzIGRvbmUgb25s eSB1c2luZyB0aGUgNS10dXBsZS4gIFRoZW4sIHRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgYSDigJxy ZXN1bXB0aW9u4oCdIHBoYXNlIGlmIHRoZSBjbGllbnQgY2hhbmdlcyBpdHMgNS10dXBsZS4NClRo ZSBnb2FsIGhlcmUgaXMgdG8gcmVkdWNlIGxpbmthYmlsaXR5IChhbmQgbWF5YmUgZ2FpbiBhIGZl dyBiaXRzIGluIHRoZSBwYWNrZXRzKS4NCg0KUGFydCAyLiBUbyBjb21wZW5zYXRlIGZvciB0aGUg bGFjayBvZiBTZXJ2ZXItQ29udHJpYnV0ZWQgQ29ubmVjdGlvbklELCBiZWNhdXNlIGxvYWQgYmFs YW5jZXJzIG1heSBuZWVkIGl0LCB3ZSBhZGQgY2xlYXJ0ZXh0IFNlcnZlci1Db250cmlidXRlZCBT ZXJ2ZXJJRCBpbnRvIGFsbCBjbGllbnTihpJzZXJ2ZXIgcGFja2V0cyBpZiB0aGUgU2VydmVyIHBy b3ZpZGVzIG9uZSBkdXJpbmcgdGhlIGhhbmRzaGFrZS4NClRoaXMgcGFydCBhYm91dCBTZXJ2ZXIt Q29udHJpYnV0ZWQgU2VydmVySUQgZmllbGQgaXMgY2xvc2VseSByZWxhdGVkIHRvIElzc3VlIDIw NSAoaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjA1KS4NCg0K SXMgdGhhdCBjb3JyZWN0Pw0KDQpOb3csIGlmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRo ZSBwcm9wb3NlZCBvcGVyYXRpb24gb2YgdGhlIHByb3RvY29sIHdvdWxkIGJlOg0KDQoxLiBDbGll bnQgaW5pdGlhdGVzIHRoZSBoYW5kc2hha2UgKDEtUlRUIG9yIDAtUlRUKS4gIEF0IHRoaXMgcG9p bnQsIHRoZSBjb25uZWN0aW9uIGlzIG9ubHkgaWRlbnRpZmllZCBieSB0aGUgNS10dXBsZSBhbmQg Y2Fubm90IG1pZ3JhdGUuDQoNCjIuIFdoZW4gY2xpZW50IGhhcyAwLVJUVCBvciAxLVJUVCBrZXlz LCB0aGUgY2xpZW50IHRlbGxzIHRoZSBzZXJ2ZXIgdGhhdCB0aGlzIGlzIGEgbmV3IGNvbm5lY3Rp b24gYW5kIHdoYXQgaXRzIENvbm5lY3Rpb25JRCBpcy4NCg0KMy4gU29tZXRpbWUgZHVyaW5nIHRo ZSBoYW5kc2hha2UsIHRoZSBTZXJ2ZXIgTUFZIHNlbmQgdGhlIGNsaWVudCBpdHMgU2VydmVySUQg dGhhdCB0aGUgY2xpZW50IE1VU1QgaW5jbHVkZSBpbiBwbGFpbnRleHQgaW4gYWxsIHN1YnNlcXVl bnQgcGFja2V0cy4NCg0KNC4gSWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgYSBub24taGFuZHNoYWtlIHBh Y2tldCBmcm9tIGFuIHVua25vd24gNS10dXBsZSwgaXQgc2VuZHMgYSBQVUJMSUNfUkVTRVQgKD8p IHdpdGgg4oCcdW5rbm93biA1LXR1cGxl4oCdIGVycm9yIGNvZGUuDQoNCjUuIElmIGEgY2xpZW50 IHJlY2VpdmVzIGEgUFVCTElDX1JFU0VUICg/KSB3aXRoIOKAnHVua25vd24gNS10dXBsZeKAnSwg aXQgaW5pdGlhdGVzIDAtUlRUIGhhbmRzaGFrZSBhbmQgdXNpbmcgMC1SVFQga2V5cyBpdCB0ZWxs cyB0aGUgc2VydmVyIHRoYXQgdGhpcyBpcyBhIHJlc3VtcHRpb24gb2YgY29ubmVjdGlvbiB3aXRo IENvbm5lY3Rpb25JRC4NCg0KDQotICAgICAgICAgIElnb3INCg0KDQpGcm9tOiBLeWxlIFJvc2Ug W21haWx0bzprcm9zZUBrcm9zZS5vcmddDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDAxLCAyMDE3 IDE6NTYgUE0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkNjOiBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgUnlhbiBIYW1pbHRvbiA8 cmNoQGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBLYXp1aG8gT2t1 IDxrYXp1aG9va3VAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFdoZW4gc2hvdWxkIHNlcnZlci1j aG9zZW4gY29ubmVjdGlvbiBJRHMgYmUgc2VudCBhbmQgaG93IGFyZSB0aGV5IGluZGljYXRlZD8N Cg0KT24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgODowNyBQTSwgTHViYXNoZXYsIElnb3IgPGlsdWJh c2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT5dDQo+ DQo+PiBIb3cgd291bGQgYSBzZXJ2ZXIga25vdyB3aGljaCBzZXJ2ZXIgdG8gcmVkaXJlY3QgdGhp cyBwYWNrZXQgdG8/DQo+DQo+IEkgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciB3b3VsZCBoYXZlIG1v cmUgc3RhdGUgdGhhbiB0aGUgbG9hZCBiYWxhbmNlci4NCg0KVW5mb3J0dW5hdGVseSwgdGhpcyBt ZWFucyB0aGUgc2VydmVyIHdvdWxkIG5lZWQgbm90IG9ubHkgaXRzIG93biBzdGF0ZSBidXQgYWxz byB0aGUgc3RhdGUgb2YgYWxsIG9mIGl0cyBwZWVycyBiZWhpbmQgdGhhdCBsb2FkIGJhbGFuY2Vy Lg0KDQpOb3QgbmVjZXNzYXJpbHkuIEl0IHNlZW1zIGxpa2Ugd2UncmUgdHJ5aW5nIHRvIG1hc2gg dHdvIHJlcXVpcmVtZW50cyBpbnRvIG9uZSBtZWNoYW5pc20uIFRoZSB0d28gcmVxdWlyZW1lbnRz IGFyZToNCigxKSBTb21lIGNvb2tpZSBpc3N1ZWQgYnkgdGhlIHNlcnZlciBmYXJtIHRvIG9mZmxv YWQgbWluaW1hbCBzdGF0ZSBmb3IgdGhlIGxvYWQgYmFsYW5jZXIgc28gaXQgZG9lc24ndCBoYXZl IHRvIHRyYWNrIGV2ZXJ5IGNvbm5lY3Rpb24gYXR0ZW1wdCBhbmQgZXN0YWJsaXNoZWQgY29ubmVj dGlvbg0KKDIpIEEgY29ubmVjdGlvbiBJRCB0aGF0IHRoZSBzZXJ2ZXIgbmVlZHMgaW4gcGxhaW50 ZXh0IHRvIGZpbmQgY29ubmVjdGlvbiBzdGF0ZSBhY3Jvc3MgNS10dXBsZSBjaGFuZ2VzLCBidXQg dGhhdCBtdXN0IGFjdHVhbGx5IGJlIGEgc2V0IG9mIHVubGlua2FibGUgY29ubmVjdGlvbiBJRHMg b3IgYSBtZWNoYW5pc20gZm9yIGdlbmVyYXRpbmcgdW5saW5rYWJsZSBjb25uZWN0aW9uIElEcyBm b3IgcHJpdmFjeSBmcm9tIG9ic2VydmVycw0KSWYgdGhlIGNvb2tpZXMgYXJlIHN0YWJsZSBpZGVu dGlmaWVycyBtb3N0bHkgYmlqZWN0aXZlIHdpdGggYWN0dWFsIHNlcnZlcnMsIGFuZCBpZiB0aGVy ZSBhcmUgbWFueSBtb3JlIHNlcnZlcnMgdGhhbiBjbGllbnRzLCB0aGVuIGl0IGRvZXNuJ3QgcmV2 ZWFsIGEgbG90IG9mIGluZm9ybWF0aW9uIHRvIGFuIG9ic2VydmVyIHRyeWluZyB0byBjb3JyZWxh dGUgY2xpZW50IElQczogaXQncyBiYXNpY2FsbHkgZXF1aXZhbGVudCB0byB0aGUgc2VydmVyIElQ IGluIHRlcm1zIG9mIGluZm9ybWF0aW9uLiAoSXQncyBOIHRpbWVzIHdvcnNlIHRoYW4gYSBzaW5n bGUgbG9hZC1iYWxhbmNlZCBJUCBmcm9udGluZyBOIHNlcnZlcnMuKQ0KT25lIGFkdmFudGFnZSBv ZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlIGNvbm5lY3Rpb24gSUQgaXMgcmVhbGx5IG9ubHkg bmVlZGVkIHdoZW4gZXN0YWJsaXNoaW5nIGEgbmV3IGZsb3c6IG90aGVyd2lzZSwgdGhlIHNlcnZl ciBqdXN0IHVzZXMgNS10dXBsZSB0byBpbmRleCBpbnRvIHRoZSBjb25uZWN0aW9uIGNvbnRleHQu IElmIHRoZSBjbGllbnQga25vd3MgaXQncyBjaGFuZ2luZyBmbG93cyBvciBhZGRpbmcgYSBuZXcg ZmxvdywgaXQgY2FuIHNlbmQgYW4gdW51c2VkIGNvbm5lY3Rpb24gSUQgdG8gdGhlIHNlcnZlciB0 byBsaW5rIHRoYXQgbmV3IGZsb3cgaW50byB0aGUgY29ubmVjdGlvbiBjb250ZXh0OyBpZiBpdCBk b2Vzbid0IGtub3cgKGUuZy4sIE5BVCByZWJpbmRpbmcpLCB0aGUgc2VydmVyIGNhbiBkcm9wIGFs aWVuIHBhY2tldHMgdW50aWwgdGhlIGNsaWVudCBkZWNpZGVzIHRvIHJlLWVzdGFibGlzaCB0aGUg ZmxvdyB3aXRoIGFuIHVudXNlZCBjb25uZWN0aW9uIElELiAoVGhlcmUgY291bGQgYWxzbyBiZSBz b21lIHNpZ25hbCBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCB0aGF0ICJ5b3UgYXJlIGFs aWVuIiwgYnV0IGF1dGhlbnRpY2F0aW9uIHdpdGggUEtDIHdvdWxkIGJlIGV4cGVuc2l2ZS4pDQpP bmUgZGlzYWR2YW50YWdlIGlzIHRoYXQgeW91IGhhdmUgdHdvIGNvbmZsaWN0aW5nIGZvcmNlcyBh cm91bmQgdGhlIHNpemUgb2YgdGhpcyBjb29raWU6IGxpbWl0aW5nIHRoZSBzaXplIG9mIHRoaXMg c3BhY2UgdG8gcHJldmVudCBzZXJ2ZXJzIGZyb20gaXNzdWluZyB1bmlxdWUgcGxhaW50ZXh0IGNs aWVudCBpZGVudGlmaWVycywgdnMuIGtlZXBpbmcgdGhlIHNwYWNlIGxhcmdlIGFuZCBzcGFyc2Ug c28gYW4gYXR0YWNrZXIgY2FuJ3Qgd2FsayBpdC4gVGhlcmUncyBubyB3YXkgdG8gcmVhbGx5IGVu Zm9yY2Ugd2hhdCB0aGUgc2VydmVyIHB1dHMgaGVyZTogd2UgY2FuIG9ubHkgcHJvdmlkZSBndWlk YW5jZSB0aGF0IHRoaXMgY29va2llIHNwYWNlIGlzIGZvciBzZXJ2ZXIgaWRlbnRpZmljYXRpb24g Km9ubHkqLCBhbmQgdGhhdCBjYXJlIG11c3QgYmUgdGFrZW4gdG8gbWFrZSBzdXJlIGl0IGRvZXMg bm90IGVuYWJsZSB0cmFja2luZyBvZiBpbmRpdmlkdWFsIGNsaWVudHMuIEluIGFueSBldmVudCwg dGhpcyBpcyBubyB3b3JzZSBmcm9tIHRoYXQgcGVyc3BlY3RpdmUgdGhhbiBhbiBhcmJpdHJhcnkg c2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEIHRoYXQgYXBwZWFycyBpbiBldmVyeSBzaW5nbGUg cGFja2V0IGFuZCBpcyBzdWJqZWN0IHRvIHRoZSBwcm9ibGVtIG9mIGZsb3cgY2hhbmdlcyB1bmtu b3duIHRvIHRoZSBjbGllbnQuDQpUaGVyZSdzIGFsc28gYSBnZW5lcmFsIHByb2JsZW0gd2l0aCBs b2FkIGJhbGFuY2Vyczogd2l0aG91dCBhIHByZS1lc3RhYmxpc2hlZCBjb29raWUsIHRoZSBjbGll bnQgaXMgcHJvYmFibHkgbGltaXRlZCB0byBhIHNpbmdsZSBkYXRhZ3JhbSBmb3IgMC1SVFQgdW5s ZXNzIHRoZSBsb2FkIGJhbGFuY2luZyBhbGdvcml0aG0gaXMgYSBmdW5jdGlvbiBvZiBjb25uZWN0 aW9uIGluZm9ybWF0aW9uIHRoYXQgZG9lc24ndCB2YXJ5IGFjcm9zcyAwLVJUVCBwYWNrZXRzIGZy b20gYSBzaW5nbGUgY29ubmVjdGlvbi4gTG9hZCBiYWxhbmNlcnMgcHJvYmFibHkgd2FudCB0byBi YWxhbmNlIGxvYWQsIG5vdCByYW5kb21seSBhc3NpZ24uDQoNCkFzIHdpdGggc28gbWFueSBvZiB0 aGUgcHJpdmFjeSBkaXNjdXNzaW9ucyBvbiB0cmFuc3BvcnQgdG9waWNzLCBJIGRvbid0IHJlYWxs eSBoYXZlIGEgc3Ryb25nIG9waW5pb24gYWJvdXQgd2hldGhlciB0aGlzIGlzIGEgZ29vZCBpZGVh IG9yIG5vdDogcHJldmVudGluZyBldmVyeSBraW5kIG9mIGNsaWVudCB0cmFja2luZyBhdCB0aGlz IGxheWVyIGlzIHByb2JhYmx5IGZ1dGlsZS4gSSBkbywgaG93ZXZlciwgdGhpbmsgaXQncyBpbXBv cnRhbnQgdG8gZGlzY3VzcyB0aGUgZW50aXJlIHNwYWNlIG9mIGFsdGVybmF0aXZlcyBhbmQgcGlj ayBzb21ldGhpbmcgdGhhdCBhY3R1YWxseSBhY2hpZXZlcyBhIGJhbGFuY2Ugb2YgcHJpdmFjeSwg c2VjdXJpdHksIGFuZCBvcGVyYWJpbGl0eSB0aGF0IHVzZXJzIHdpbGwgZm9yIHRoZSBtb3N0IHBh cnQgYmUgc2F0aXNmaWVkIHdpdGguDQoNCkt5bGUNCg0K --_000_afdb0a6d928a46438e6b3b86a10d6797usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWls LTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDY1MTA5NDMxOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzk1MTc2Njk4IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE5NDEzMjkyMDg7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5Nzk3Mzc0 MTIgLTY0MDA5MzM2NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjU7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjIwNDgyOTE2Mzk7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NTk3Nzk1 NjggLTE5MDgzNTkxMzggNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1s ZXZlbC10ZXh0OiJcKCUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91ciBwcm9wb3NhbCBoYXMgdHdvIHBhcnRzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5QYXJ0IDEuIEhhdmUgdGhlIGNsaWVudCBzZWxlY3QgYSBDb25uZWN0aW9u SUQgdGhhdCBkb2VzIE5PVCBzaG93IHVwIGluIHRoZSBjbGVhciBpbiBwYWNrZXRzLiBJdCBpcyBv bmx5IHNlbnQgYnkgdGhlIGNsaWVudCBlbmNyeXB0ZWQgYnkgZWl0aGVyIDAtUlRUIG9yIDEtUlRU IGtleXMuJm5ic3A7IENvbm5lY3Rpb24NCiB0cmFja2luZyBpcyBkb25lIG9ubHkgdXNpbmcgdGhl IDUtdHVwbGUuJm5ic3A7IFRoZW4sIHRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgYSDigJxyZXN1bXB0 aW9u4oCdIHBoYXNlIGlmIHRoZSBjbGllbnQgY2hhbmdlcyBpdHMgNS10dXBsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBn b2FsIGhlcmUgaXMgdG8gcmVkdWNlIGxpbmthYmlsaXR5IChhbmQgbWF5YmUgZ2FpbiBhIGZldyBi aXRzIGluIHRoZSBwYWNrZXRzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UGFydCAyLiBUbyBjb21wZW5zYXRl IGZvciB0aGUgbGFjayBvZiBTZXJ2ZXItQ29udHJpYnV0ZWQgQ29ubmVjdGlvbklELCBiZWNhdXNl IGxvYWQgYmFsYW5jZXJzIG1heSBuZWVkIGl0LCB3ZSBhZGQgY2xlYXJ0ZXh0IFNlcnZlci1Db250 cmlidXRlZCBTZXJ2ZXJJRCBpbnRvIGFsbCBjbGllbnTihpJzZXJ2ZXINCiBwYWNrZXRzIGlmIHRo ZSBTZXJ2ZXIgcHJvdmlkZXMgb25lIGR1cmluZyB0aGUgaGFuZHNoYWtlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBwYXJ0 IGFib3V0IFNlcnZlci1Db250cmlidXRlZCBTZXJ2ZXJJRCBmaWVsZCBpcyBjbG9zZWx5IHJlbGF0 ZWQgdG8gSXNzdWUgMjA1ICg8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2Ut ZHJhZnRzL2lzc3Vlcy8yMDUiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv aXNzdWVzLzIwNTwvYT4pLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklzIHRoYXQgY29ycmVjdD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Tm93LCBpZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0aGUgcHJvcG9zZWQg b3BlcmF0aW9uIG9mIHRoZSBwcm90b2NvbCB3b3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MS4gQ2xp ZW50IGluaXRpYXRlcyB0aGUgaGFuZHNoYWtlICgxLVJUVCBvciAwLVJUVCkuJm5ic3A7IEF0IHRo aXMgcG9pbnQsIHRoZSBjb25uZWN0aW9uIGlzIG9ubHkgaWRlbnRpZmllZCBieSB0aGUgNS10dXBs ZSBhbmQgY2Fubm90IG1pZ3JhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjIuIFdoZW4gY2xpZW50IGhhcyAw LVJUVCBvciAxLVJUVCBrZXlzLCB0aGUgY2xpZW50IHRlbGxzIHRoZSBzZXJ2ZXIgdGhhdCB0aGlz IGlzIGEgbmV3IGNvbm5lY3Rpb24gYW5kIHdoYXQgaXRzIENvbm5lY3Rpb25JRCBpcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+My4gU29tZXRpbWUgZHVyaW5nIHRoZSBoYW5kc2hha2UsIHRoZSBTZXJ2ZXIgTUFZ IHNlbmQgdGhlIGNsaWVudCBpdHMgU2VydmVySUQgdGhhdCB0aGUgY2xpZW50IE1VU1QgaW5jbHVk ZSBpbiBwbGFpbnRleHQgaW4gYWxsIHN1YnNlcXVlbnQgcGFja2V0cy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ NC4gSWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgYSBub24taGFuZHNoYWtlIHBhY2tldCBmcm9tIGFuIHVu a25vd24gNS10dXBsZSwgaXQgc2VuZHMgYSBQVUJMSUNfUkVTRVQgKD8pIHdpdGgg4oCcdW5rbm93 biA1LXR1cGxl4oCdIGVycm9yIGNvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjUuIElmIGEgY2xpZW50IHJl Y2VpdmVzIGEgUFVCTElDX1JFU0VUICg/KSB3aXRoIOKAnHVua25vd24gNS10dXBsZeKAnSwgaXQg aW5pdGlhdGVzIDAtUlRUIGhhbmRzaGFrZSBhbmQgdXNpbmcgMC1SVFQga2V5cyBpdCB0ZWxscyB0 aGUgc2VydmVyIHRoYXQgdGhpcyBpcyBhIHJlc3VtcHRpb24gb2YgY29ubmVjdGlvbg0KIHdpdGgg Q29ubmVjdGlvbklELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzMiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JZ29yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IEt5bGUgUm9zZSBbbWFpbHRvOmtyb3NlQGtyb3NlLm9yZ10N Cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDAxLCAyMDE3IDE6NTYgUE08YnI+ DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNv bSZndDs7IFJ5YW4gSGFtaWx0b24gJmx0O3JjaEBnb29nbGUuY29tJmd0OzsgSUVURiBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0OzsgS2F6dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFdoZW4gc2hvdWxkIHNlcnZlci1jaG9zZW4g Y29ubmVjdGlvbiBJRHMgYmUgc2VudCBhbmQgaG93IGFyZSB0aGV5IGluZGljYXRlZD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgODowNyBQTSwgTHViYXNoZXYsIElnb3IgJmx0Ozxh IGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1YmFz aGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbC0iPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDtGcm9tOiBN YXJ0aW4gVGhvbXNvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT5dPC9zcGFuPjxicj4NCjxzcGFuIGNs YXNzPSJnbWFpbC0iPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyZn dDsgSG93IHdvdWxkIGEgc2VydmVyIGtub3cgd2hpY2ggc2VydmVyIHRvIHJlZGlyZWN0IHRoaXMg cGFja2V0IHRvPzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7PC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDsgSSBhc3N1bWUgdGhhdCB0aGUgc2VydmVyIHdv dWxkIGhhdmUgbW9yZSBzdGF0ZSB0aGFuIHRoZSBsb2FkIGJhbGFuY2VyLjwvc3Bhbj48YnI+DQo8 YnI+DQpVbmZvcnR1bmF0ZWx5LCB0aGlzIG1lYW5zIHRoZSBzZXJ2ZXIgd291bGQgbmVlZCBub3Qg b25seSBpdHMgb3duIHN0YXRlIGJ1dCBhbHNvIHRoZSBzdGF0ZSBvZiBhbGwgb2YgaXRzIHBlZXJz IGJlaGluZCB0aGF0IGxvYWQgYmFsYW5jZXIuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5Ob3QgbmVjZXNzYXJpbHkuIEl0IHNlZW1zIGxpa2Ugd2UncmUgdHJ5aW5nIHRvIG1hc2gg dHdvIHJlcXVpcmVtZW50cyBpbnRvIG9uZSBtZWNoYW5pc20uIFRoZSB0d28gcmVxdWlyZW1lbnRz IGFyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PigxKSBTb21lIGNvb2tpZSBpc3N1ZWQgYnkgdGhlIHNlcnZlciBmYXJtIHRvIG9mZmxvYWQgbWlu aW1hbCBzdGF0ZSBmb3IgdGhlIGxvYWQgYmFsYW5jZXIgc28gaXQgZG9lc24ndCBoYXZlIHRvIHRy YWNrIGV2ZXJ5IGNvbm5lY3Rpb24gYXR0ZW1wdCBhbmQgZXN0YWJsaXNoZWQgY29ubmVjdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4oMikgQSBjb25uZWN0aW9uIElEIHRoYXQgdGhlIHNlcnZl ciBuZWVkcyBpbiBwbGFpbnRleHQgdG8gZmluZCBjb25uZWN0aW9uIHN0YXRlIGFjcm9zcyA1LXR1 cGxlIGNoYW5nZXMsIGJ1dCB0aGF0IG11c3QgYWN0dWFsbHkgYmUgYSBzZXQgb2YgdW5saW5rYWJs ZSBjb25uZWN0aW9uIElEcyBvciBhIG1lY2hhbmlzbSBmb3IgZ2VuZXJhdGluZyB1bmxpbmthYmxl IGNvbm5lY3Rpb24NCiBJRHMgZm9yIHByaXZhY3kgZnJvbSBvYnNlcnZlcnM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SWYgdGhlIGNvb2tpZXMgYXJlIHN0YWJsZSBpZGVudGlmaWVycyBtb3N0bHkg YmlqZWN0aXZlIHdpdGggYWN0dWFsIHNlcnZlcnMsIGFuZCBpZiB0aGVyZSBhcmUgbWFueSBtb3Jl IHNlcnZlcnMgdGhhbiBjbGllbnRzLCB0aGVuIGl0IGRvZXNuJ3QgcmV2ZWFsIGEgbG90IG9mIGlu Zm9ybWF0aW9uIHRvIGFuIG9ic2VydmVyIHRyeWluZyB0byBjb3JyZWxhdGUgY2xpZW50DQogSVBz OiBpdCdzIGJhc2ljYWxseSBlcXVpdmFsZW50IHRvIHRoZSBzZXJ2ZXIgSVAgaW4gdGVybXMgb2Yg aW5mb3JtYXRpb24uIChJdCdzIE4gdGltZXMgd29yc2UgdGhhbiBhIHNpbmdsZSBsb2FkLWJhbGFu Y2VkIElQIGZyb250aW5nIE4gc2VydmVycy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uZSBh ZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0IHRoZSBjb25uZWN0aW9uIElEIGlzIHJl YWxseSBvbmx5IG5lZWRlZCB3aGVuIGVzdGFibGlzaGluZyBhIG5ldyBmbG93OiBvdGhlcndpc2Us IHRoZSBzZXJ2ZXIganVzdCB1c2VzIDUtdHVwbGUgdG8gaW5kZXggaW50byB0aGUgY29ubmVjdGlv biBjb250ZXh0LiBJZiB0aGUgY2xpZW50IGtub3dzDQogaXQncyBjaGFuZ2luZyBmbG93cyBvciBh ZGRpbmcgYSBuZXcgZmxvdywgaXQgY2FuIHNlbmQgYW4gdW51c2VkIGNvbm5lY3Rpb24gSUQgdG8g dGhlIHNlcnZlciB0byBsaW5rIHRoYXQgbmV3IGZsb3cgaW50byB0aGUgY29ubmVjdGlvbiBjb250 ZXh0OyBpZiBpdCBkb2Vzbid0IGtub3cgKGUuZy4sIE5BVCByZWJpbmRpbmcpLCB0aGUgc2VydmVy IGNhbiBkcm9wIGFsaWVuIHBhY2tldHMgdW50aWwgdGhlIGNsaWVudCBkZWNpZGVzIHRvIHJlLWVz dGFibGlzaA0KIHRoZSBmbG93IHdpdGggYW4gdW51c2VkIGNvbm5lY3Rpb24gSUQuIChUaGVyZSBj b3VsZCBhbHNvIGJlIHNvbWUgc2lnbmFsIGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50IHRo YXQgJnF1b3Q7eW91IGFyZSBhbGllbiZxdW90OywgYnV0IGF1dGhlbnRpY2F0aW9uIHdpdGggUEtD IHdvdWxkIGJlIGV4cGVuc2l2ZS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uZSBkaXNhZHZh bnRhZ2UgaXMgdGhhdCB5b3UgaGF2ZSB0d28gY29uZmxpY3RpbmcgZm9yY2VzIGFyb3VuZCB0aGUg c2l6ZSBvZiB0aGlzIGNvb2tpZTogbGltaXRpbmcgdGhlIHNpemUgb2YgdGhpcyBzcGFjZSB0byBw cmV2ZW50IHNlcnZlcnMgZnJvbSBpc3N1aW5nIHVuaXF1ZSBwbGFpbnRleHQgY2xpZW50IGlkZW50 aWZpZXJzLCB2cy4ga2VlcGluZyB0aGUgc3BhY2UNCiBsYXJnZSBhbmQgc3BhcnNlIHNvIGFuIGF0 dGFja2VyIGNhbid0IHdhbGsgaXQuIFRoZXJlJ3Mgbm8gd2F5IHRvIHJlYWxseSBlbmZvcmNlIHdo YXQgdGhlIHNlcnZlciBwdXRzIGhlcmU6IHdlIGNhbiBvbmx5IHByb3ZpZGUgZ3VpZGFuY2UgdGhh dCB0aGlzIGNvb2tpZSBzcGFjZSBpcyBmb3Igc2VydmVyIGlkZW50aWZpY2F0aW9uICpvbmx5Kiwg YW5kIHRoYXQgY2FyZSBtdXN0IGJlIHRha2VuIHRvIG1ha2Ugc3VyZSBpdCBkb2VzIG5vdCBlbmFi bGUNCiB0cmFja2luZyBvZiBpbmRpdmlkdWFsIGNsaWVudHMuIEluIGFueSBldmVudCwgdGhpcyBp cyBubyB3b3JzZSBmcm9tIHRoYXQgcGVyc3BlY3RpdmUgdGhhbiBhbiBhcmJpdHJhcnkgc2VydmVy LWNob3NlbiBjb25uZWN0aW9uIElEIHRoYXQgYXBwZWFycyBpbiBldmVyeSBzaW5nbGUgcGFja2V0 IGFuZCBpcyBzdWJqZWN0IHRvIHRoZSBwcm9ibGVtIG9mIGZsb3cgY2hhbmdlcyB1bmtub3duIHRv IHRoZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZXJlJ3MgYWxzbyBhIGdlbmVyYWwgcHJvYmxlbSB3aXRoIGxvYWQgYmFsYW5jZXJzOiB3aXRo b3V0IGEgcHJlLWVzdGFibGlzaGVkIGNvb2tpZSwgdGhlIGNsaWVudCBpcyBwcm9iYWJseSBsaW1p dGVkIHRvIGEgc2luZ2xlIGRhdGFncmFtIGZvciAwLVJUVCB1bmxlc3MgdGhlIGxvYWQgYmFsYW5j aW5nIGFsZ29yaXRobSBpcyBhIGZ1bmN0aW9uIG9mIGNvbm5lY3Rpb24gaW5mb3JtYXRpb24gdGhh dCBkb2Vzbid0DQogdmFyeSBhY3Jvc3MgMC1SVFQgcGFja2V0cyBmcm9tIGEgc2luZ2xlIGNvbm5l Y3Rpb24uIExvYWQgYmFsYW5jZXJzIHByb2JhYmx5IHdhbnQgdG8gYmFsYW5jZSBsb2FkLCBub3Qg cmFuZG9tbHkgYXNzaWduLjxicj4NCjxicj4NCkFzIHdpdGggc28gbWFueSBvZiB0aGUgcHJpdmFj eSBkaXNjdXNzaW9ucyBvbiB0cmFuc3BvcnQgdG9waWNzLCBJIGRvbid0IHJlYWxseSBoYXZlIGEg c3Ryb25nIG9waW5pb24gYWJvdXQgd2hldGhlciB0aGlzIGlzIGEgZ29vZCBpZGVhIG9yIG5vdDog cHJldmVudGluZyBldmVyeSBraW5kIG9mIGNsaWVudCB0cmFja2luZyBhdCB0aGlzIGxheWVyIGlz IHByb2JhYmx5IGZ1dGlsZS4gSSBkbywgaG93ZXZlciwgdGhpbmsgaXQncyBpbXBvcnRhbnQgdG8N CiBkaXNjdXNzIHRoZSBlbnRpcmUgc3BhY2Ugb2YgYWx0ZXJuYXRpdmVzIGFuZCBwaWNrIHNvbWV0 aGluZyB0aGF0IGFjdHVhbGx5IGFjaGlldmVzIGEgYmFsYW5jZSBvZiBwcml2YWN5LCBzZWN1cml0 eSwgYW5kIG9wZXJhYmlsaXR5IHRoYXQgdXNlcnMgd2lsbCBmb3IgdGhlIG1vc3QgcGFydCBiZSBz YXRpc2ZpZWQgd2l0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkt5 bGU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_afdb0a6d928a46438e6b3b86a10d6797usma1exdag1mb5msgcorpak_-- From nobody Fri Mar 3 09:03:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3434C129953 for ; Fri, 3 Mar 2017 09:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OasAg_O7Er6S for ; Fri, 3 Mar 2017 09:03:26 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B0512943D for ; Fri, 3 Mar 2017 09:03:26 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id p77so84752518ywg.1 for ; Fri, 03 Mar 2017 09:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T0i93JcQxmLayW+WBr5U9DAZ8OVz6d7V52c/E5fwUKY=; b=OY7YYjAEsaKcVNCsaK+Dss/3JTNhiqcYU6PwS3Ja2obA1yI0k/rN7l8LrkEBCQ70cQ cwtVhrIPyxb79/XBtVfZqPrR8jmSdbexUxhlYUCY5M5xNqkQsJLtaZc2OW20uzK4TWo8 8R7lEdd81+4SfKWEyXhJC/0g1lZgMYUnk95AvFMtqYS7UPPqZHYB/kL3raZjGM6BX4kQ WBn3dTubUrKFtVW4WQy1YkNFPfi1PkH/9kCLS4xoMNcyosmkw08NhuYaFGIRB9TVr9KT iO4WD9L2qhbnKj57KD8JgZsF9nD8/Ec8EA+mlruqnsjqLlF4Y9dAGyJZYiZxGnvLC1wJ Vqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T0i93JcQxmLayW+WBr5U9DAZ8OVz6d7V52c/E5fwUKY=; b=QnPlZWUX+Rlt8DPAeaBFtgYpMdZMks3B8hHZ+Ze0wgqEB4fJd0X26JmOAGuo4oqTCz jmvucbtd0dt73/y4xOIUiqMXJt+jEFqKXLnbhY7XvasDoXTu532RniQpPRddTQoS468T wuBGb0PdKIFbWRNjahL5/aJl/49D9LImgL1oU/vnfbhtB0XbJmxLPW6+PnKfUJifD6JY 0CF0IJU1aM0tJth/X+Hcv5nTwTaXLVwkkywBv78esixO49MCr/50+rO1JTrPqtAizRYH vAbOc8uzIgsyv9ASxSsiR9PmuaOl8LvWxTx2sBxUzaU5RvQ9qEnO96eN9uduyajXP5cx LQvA== X-Gm-Message-State: AMke39nO4NmS/IS5u1UwVAZ/t5Bw72TnIXhYVdFcwLi5a0+I+F9PQ/vBNMHE5usJ02ocfRd5mVuahu+LnEIpj37m X-Received: by 10.129.72.144 with SMTP id v138mr2468917ywa.331.1488560605018; Fri, 03 Mar 2017 09:03:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.198.10 with HTTP; Fri, 3 Mar 2017 09:03:04 -0800 (PST) In-Reply-To: <57f78e9b-f75b-03da-0d3f-7405d645f7bd@it.uc3m.es> References: <57f78e9b-f75b-03da-0d3f-7405d645f7bd@it.uc3m.es> From: Ian Swett Date: Fri, 3 Mar 2017 12:03:04 -0500 Message-ID: Subject: Re: A single alarm in draft-ietf-quic-recovery To: marcelo bagnulo braun Content-Type: multipart/alternative; boundary=001a114d93b41756920549d68623 Archived-At: Cc: draft-ietf-quic-recovery@ietf.org, "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:03:28 -0000 --001a114d93b41756920549d68623 Content-Type: text/plain; charset=UTF-8 Great questions, sorry for the delay. Answers inline. On Tue, Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun wrote: > Hi, > > The current version of the draft uses a single alarm for all timer based > loss detection, as specified in section 3.4 of the draft. > > I am not sure i follow how you do this. > > I particular, I am uncertain you can avoid having two separated alarms, > one for the RTO and another one for tail probe (at least). > > I mean, if i understand correctly, the RTO alarm should be set when you > send the oldest packet (I guess a usual approximation is to set it when a > given packet becomes the oldest, i.e. it is ok to set it when an ack > arrives and acks the oldest packet (packet 5) making another packet (packet > 6) to become the oldest packet, instead of setting the alarm when packet 6 > was actually sent). > > I understand that the tail loss probe alarm is set when the last packet > was sent (and the connection is in open state). > QUIC sets the RTO alarm based on the most recently sent packet, just like TLP, and it always sends TLPs before arming the RTO timer. These are two subtle but significant difference from how TLP and RTO are defined in TCP. Both are less aggressive than TCP, which I tend to think is good in this case. QUIC's goal is to continue making forward progress, not only move the left edge forward, so we didn't see a need to have two competing retransmission timers for almost identical purposes. Another important difference is that QUIC's TLP retransmits the earliest outstanding packet when no new data is available, not the most recent, under the theory it's more likely to be lost and QUIC's packet numbers means there are no issues with ambiguity. > So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and > suppose no ACK is received. > > The RTO timer should be set when packet 1 is sent while the TLP timer > should be set when the packet 9 is sent. > > If i understand it correctly, according to the draft, the alarm will be > set in TLP mode (twice) and then it wil enter in RTO mode. > > Suppose no ack comes back, this basically means that the actual RTO will > be fired 2 TLP timeout later than the recommended RTO timeout, correct? > (neglecting the transmission delay for packets 1 to 9 which may not be > negligible if the number of inflight packets is high) > That's correct and intended. > > I think a similar issue applies to the Early retransmit alarm. Again, the > RTO should be set when the oldest packet is sent, but setting the early > retransmit alarm will distort this. > I mean again consider the situation the sender sends packets 1,2 and 3. > While no acks are received, the TLP alarm is set. Suppose 1 RTT later, the > ack for packet 3 arrives. At this point, the Early retransmit timer is set. > Suppose now that no ack is received. RTT/4 later, the early retransmit > kicks in again and again and actually the RTO will be never be set, because > the alarm will always stay in early retransmit mode, no? > Maybe a defining a max number of early retransmit would fix this? > Probably having separated timers would also fix it (assuming we want a TCP > like behaviour when the oldest packet is retransmitted after an RTO timeout) > > The intent was that when the early retransmit timer went off after 1/4 RTT, all packets less than the largest acked would be declared lost, which I believe is the TCP behavior for early retransmit as well(with the addition of a timer). But as you note, that's not properly stated in the document, so I'll fix that in a PR. > An additional comment about the Early retransmit timer, the draft > references to RFC5827 to describe/explain this timer, but I personally > found this a bit of a stretch. I mean RFC5827, if i understand it > correctly, is about reducing the dupack threshold when the number of > inflight packets is low, while this early retransmit timer is, well, a > timer and it is used in any case when the latest packet has been acked. I > think this fits better with the "reordering settling" timer (step 4 in > section 5.2 of the RACK draft) being that the reordering settling timer > applies to all packets for which a later ack has been received (not only > the last ack, i mean). > Maybe it is worth to adopt the full "reordering settling" timer from RACK > (i.e. not limit to the case when the latests packet has been acked?) > I guess if we do this, then we will need the TLP timer and the reordering > settling timer to run in parallel. > You're correct, early retransmit comes from RFC5827, but the timer is mentioned as an improvement described in a paper I'm unable to locate at the moment and also implemented in Linux. I believe "reordering settling" is similar to use_time_loss mode. The pseudocode is intended to be written in a way to describe both nack based loss detection and time based detection(which uses the timer, similar to RACK), but now that I re-read through it, it's insufficiently specified for time loss mode, so I'm working on a PR to fix that. RACK didn't exist when QUIC's nack and time loss detection were written, so it's possible there's some opportunity for syncing up their descriptions. > > Regards, marcelo > I'll add some text clarifying some of the difference from TCP and adding some justification after fixing the time loss and early retransmit issues. QUIC's approach is much more closely modeled on recent Linux TCP implementations than IETF RFCs, but many details are subtly or not-so-subtly different because data is rebundled into new packets, instead of retransmitting packets. --001a114d93b41756920549d68623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great questions, sorry for the delay.=C2=A0 Answers inline= .

On Tue, Feb 21, = 2017 at 2:40 AM, marcelo bagnulo braun <marcelo@it.uc3m.es>= wrote:
Hi,

The current version of the draft uses a single alarm for all timer based lo= ss detection, as specified in section 3.4 of the draft.

I am not sure i follow how you do this.

I particular, I am uncertain you can avoid having two separated alarms, one= for the RTO and another one for tail probe (at least).

I mean, if i understand correctly, the RTO alarm should be set when you sen= d the oldest packet (I guess a usual approximation is to set it when a give= n packet becomes the oldest, i.e. it is ok to set it when an ack arrives an= d acks the oldest packet (packet 5) making another packet (packet 6) to bec= ome the oldest packet, instead of setting the alarm when packet 6 was actua= lly sent).

I understand that the tail loss probe alarm is set when the last packet was= sent (and the connection is in open state).

QUIC sets the RTO alarm based on the most recently sent packet, just = like TLP, and it always sends TLPs before arming the RTO timer.=C2=A0 These= are two subtle but significant difference from how TLP and RTO are defined= in TCP.=C2=A0 Both are less aggressive than TCP, which I tend to think is = good in this case.=C2=A0 QUIC's goal is to continue making forward prog= ress, not only move the left edge forward, so we didn't see a need to h= ave two competing retransmission timers for almost identical purposes.

Another important difference is that QUIC's TLP re= transmits the earliest outstanding packet when no new data is available, no= t the most recent, under the theory it's more likely to be lost and QUI= C's packet numbers means there are no issues with ambiguity.
=

So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and suppos= e no ACK is received.

The RTO timer should be set when packet 1 is sent while the TLP timer shoul= d be set when the packet 9 is sent.

If i understand it correctly, according to the draft, the alarm will be set= in TLP mode (twice) and then it wil enter in RTO mode.

Suppose no ack comes back, this basically means that the actual RTO will be= fired 2 TLP timeout later than the recommended RTO timeout, correct? (negl= ecting the transmission delay for packets 1 to 9 which may not be negligibl= e if the number of inflight packets is high)

That's correct and intended.
=C2=A0

I think a similar issue applies to the Early retransmit alarm. Again, the R= TO should be set when the oldest packet is sent, but setting the early retr= ansmit alarm will distort this.
I mean again consider the situation the sender sends packets 1,2 and 3.
While no acks are received, the TLP alarm is set. Suppose 1 RTT later, the = ack for packet 3 arrives. At this point, the Early retransmit timer is set.= Suppose now that no ack is received. RTT/4 later, the early retransmit kic= ks in again and again and actually the RTO will be never be set, because th= e alarm will always stay in early retransmit mode, no?
Maybe a defining a max number of early retransmit would fix this?
Probably having separated timers would also fix it (assuming we want a TCP = like behaviour when the oldest packet is retransmitted after an RTO timeout= )


The intent was that when the early ret= ransmit timer went off after 1/4 RTT, all packets less than the largest ack= ed would be declared lost, which I believe is the TCP behavior for early re= transmit as well(with the addition of a timer).=C2=A0 But as you note, that= 's not properly stated in the document, so I'll fix that in a PR.
=C2=A0
An additional comment about the Early retransmit timer, the draft reference= s to RFC5827 to describe/explain this timer, but I personally found this a = bit of a stretch. I mean RFC5827, if i understand it correctly, is about re= ducing the dupack threshold when the number of inflight packets is low, whi= le this early retransmit timer is, well, a timer and it is used in any case= when the latest packet has been acked. I think this fits better with the &= quot;reordering settling" timer (step 4 in section 5.2 of the RACK dra= ft) being that the reordering settling timer applies to all packets for whi= ch a later ack has been received (not only the last ack, i mean).
Maybe it is worth to adopt the full "reordering settling" timer f= rom RACK (i.e. not limit to the case when the latests packet has been acked= ?)
I guess if we do this, then we will need the TLP timer and the reordering s= ettling timer to run in parallel.

You&#= 39;re correct, early retransmit comes from RFC5827, but the timer is mentio= ned as an improvement described in a paper I'm unable to locate at the = moment and also implemented in Linux.

I believe &q= uot;reordering settling" is similar to use_time_loss mode.=C2=A0 The p= seudocode is intended to be written in a way to describe both nack based lo= ss detection and time based detection(which uses the timer, similar to RACK= ), but now that I re-read through it, it's insufficiently specified for= time loss mode, so I'm working on a PR to fix that.=C2=A0 RACK didn= 9;t exist when QUIC's nack and time loss detection were written, so it&= #39;s possible there's some opportunity for syncing up their descriptio= ns.
=C2=A0

Regards, marcelo

I'll add some t= ext clarifying some of the difference from TCP and adding some justificatio= n after fixing the time loss and early retransmit issues.=C2=A0 QUIC's = approach is much more closely modeled on recent Linux TCP implementations t= han IETF RFCs, but many details are subtly or not-so-subtly different becau= se data is rebundled into new packets, instead of retransmitting packets. = =C2=A0
--001a114d93b41756920549d68623-- From nobody Fri Mar 3 10:42:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7C2129974 for ; Fri, 3 Mar 2017 10:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdqOLTKxV4d2 for ; Fri, 3 Mar 2017 10:42:19 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 3211712996F for ; Fri, 3 Mar 2017 10:42:19 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n127so190466763qkf.0 for ; Fri, 03 Mar 2017 10:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CoBV9RykuEHBbz+qM7zsXbVeAfrD+/CSLXhc0ybRz7I=; b=UsMJ2zEKmgdaOo4Y1NT9iUZpY1D+k33yYqw7Glqu1qek0Drw2gy7Gk1NjjK9/hvQ1P qkydYbquR5Ot4VHOOZxBDlNKTdIGGqngOkY1tjOwFounKTpYLfH2dgautMU92ngTxtqU sA6dF3UYECMAjEIk0HpGAsG99YjcRKxd3y3lo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CoBV9RykuEHBbz+qM7zsXbVeAfrD+/CSLXhc0ybRz7I=; b=Tl5iMNjdtTLG+FSrQyHoUfYJRcfLygjbbECtitAESzW0yKD6mygerL0Z+QQtUPr+uX 0lLMiRz4E1CCoCrlmbHme3LLVaYT9zNPoA8GOHko+8LstElp7xFLdcYhe1uUWcJHaGR9 /t15OcWj83nV1bOiljIHLuiGFWq/++UGLoqekCediBXHPvOHpBcZ61ptwOkJPdgIcftG 7LWdaEekwk6WQfA3O1uP7be+DAsejDK6JCnUjJMv4E2cD71xnxQTgGSGHjrRNSgM4nUk RCmezDbfJgcGHM2O05xwD1n6Foy32Grfn1//IcmkqpjjpvghNp4QWSAkjhyKcmaksLit VasQ== X-Gm-Message-State: AMke39nJUt9KgVMdUjgoc82hTd0iYVZDgD/Bu/PDvQaHaVdDqdtkZuj6V9zBuTMdYpa4s2GV+xk/uxwOG8sK9Q== X-Received: by 10.200.42.151 with SMTP id b23mr4077275qta.163.1488566538155; Fri, 03 Mar 2017 10:42:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 3 Mar 2017 10:42:17 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <00308ab6b0ac4e31bb9ec0c1fa1c22c3@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kyle Rose Date: Fri, 3 Mar 2017 13:42:17 -0500 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a1142f5c2bb557a0549d7e7f5 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Kazuho Oku , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 18:42:21 -0000 --001a1142f5c2bb557a0549d7e7f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 3, 2017 at 11:06 AM, Lubashev, Igor wrote= : > Your proposal has two parts: > > > > Part 1. Have the client select a ConnectionID that does NOT show up in th= e > clear in packets. It is only sent by the client encrypted by either 0-RTT > or 1-RTT keys. Connection tracking is done only using the 5-tuple. Then= , > there would need to be a =E2=80=9Cresumption=E2=80=9D phase if the client= changes its > 5-tuple. > > The goal here is to reduce linkability (and maybe gain a few bits in the > packets). > > > > Part 2. To compensate for the lack of Server-Contributed ConnectionID, > because load balancers may need it, we add cleartext Server-Contributed > ServerID into all client=E2=86=92server packets if the Server provides on= e during > the handshake. > > This part about Server-Contributed ServerID field is closely related to > Issue 205 (https://github.com/quicwg/base-drafts/issues/205). > > > > Is that correct? > Basically. It explicitly uncouples load balancing state from connection ID, allowing the connection ID to uniquely identify that client and server but not be passively observable. > Now, if I understand it correctly, the proposed operation of the protocol > would be: > > > > 1. Client initiates the handshake (1-RTT or 0-RTT). At this point, the > connection is only identified by the 5-tuple and cannot migrate. > > > > 2. When client has 0-RTT or 1-RTT keys, the client tells the server that > this is a new connection and what its ConnectionID is. > > > > 3. Sometime during the handshake, the Server MAY send the client its > ServerID that the client MUST include in plaintext in all subsequent > packets. > > > > 4. If a server receives a non-handshake packet from an unknown 5-tuple, i= t > sends a PUBLIC_RESET (?) with =E2=80=9Cunknown 5-tuple=E2=80=9D error cod= e. > > > > 5. If a client receives a PUBLIC_RESET (?) with =E2=80=9Cunknown 5-tuple= =E2=80=9D, it > initiates 0-RTT handshake and using 0-RTT keys it tells the server that > this is a resumption of connection with ConnectionID. > Steps 1-3 reflect my thinking. 4 and 5 are where things get tricky. If the client knows the 5-tuple has changed, it can skip the step of sending with the old connection ID and do one of the following: - Immediately initiate a new connection with 0-RTT and present the unique connection ID so the server can transfer all connection state to that new 5-tuple. - Skip PKC and send a previously-unused shared secret in the clear to the server (e.g., using a rolling code on the connection ID) as weak proof that this new 5-tuple is the legit owner of the connection state. (Strong proof comes in the form of being able to speak over the encrypted channel.) Doing this preemptively reveals less information about the client's movements, but is not always possible. If the client *doesn't* know the 5-tuple is changing, you run into the situation in step 4. Sending a public reset then signals to a passive observer that a client has probably changed its address, likely making for easy traffic analysis to link the two connections, but this seems no worse than any of the other proposals short of always sending a different connection ID in every packet. (Sending different connection IDs in every packet is still probably feasible at the cost of either wire or state space, depending on how it's implemented. Not sure if it's worth the complexity, but the same can be said for anything other than a static plaintext connection ID in all packets.) Part of the difficulty of explaining this is the over-use of the word "connection", which is why I used "flow" in my original reply. With TLS we talk about a "session" when referring to resumption, but that term describes the security context, and has nothing to do with the application data streams being protected, which are 1:1 with TCP connections and so do not resume across connections without application support. I think what we're all proposing, irrespective of mechanism, is that with QUIC the entire connection context, including the state of all streams, be resumed with a new 5-tuple once ownership of the connection context has been transferred to that new 5-tuple. Kyle --001a1142f5c2bb557a0549d7e7f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 3, 2017 at 11:06 AM, Lubashev, Igor <ilubashe@akamai.com&g= t; wrote:

Your proposal has two parts:

=C2=A0

Part 1. Have the client select a ConnectionID that do= es NOT show up in the clear in packets. It is only sent by the client encry= pted by either 0-RTT or 1-RTT keys.=C2=A0 Connection tracking is done only using the 5-tuple.=C2=A0 Then, there would need to b= e a =E2=80=9Cresumption=E2=80=9D phase if the client changes its 5-tuple.

The goal here is to reduce linkability (and maybe gai= n a few bits in the packets).

=C2=A0

Part 2. To compensate for the lack of Server-Contribu= ted ConnectionID, because load balancers may need it, we add cleartext Serv= er-Contributed ServerID into all client=E2=86=92server packets if the Server provides one during the handshake.

This part about Server-Contributed ServerID field is = closely related to Issue 205 (https://github.com/quicwg/base-draft= s/issues/205).

=C2=A0

Is that correct?

<= div>
Basically. It explicitly uncouples load balancing state = from connection ID, allowing the connection ID to uniquely identify that cl= ient and server but not be passively observable.
=C2=A0
=

<= /u>

Now, if I understand it correctly, the proposed opera= tion of the protocol would be:

=C2=A0

1. Client initiates the handshake (1-RTT or 0-RTT).= =C2=A0 At this point, the connection is only identified by the 5-tuple and = cannot migrate.

=C2=A0

2. When client has 0-RTT or 1-RTT keys, the client te= lls the server that this is a new connection and what its ConnectionID is.<= u>

=C2=A0

3. Sometime during the handshake, the Server MAY send= the client its ServerID that the client MUST include in plaintext in all s= ubsequent packets.

=C2=A0

4. If a server receives a non-handshake packet from a= n unknown 5-tuple, it sends a PUBLIC_RESET (?) with =E2=80=9Cunknown 5-tupl= e=E2=80=9D error code.

=C2=A0

5. If a client receives a PUBLIC_RESET (?) with =E2= =80=9Cunknown 5-tuple=E2=80=9D, it initiates 0-RTT handshake and using 0-RT= T keys it tells the server that this is a resumption of connection with ConnectionID.


= Steps 1-3 reflect my thinking. 4 and 5 are where things get tricky.

=
If the client knows the 5-tuple has changed, it can skip the ste= p of sending with the old connection ID and do one of the following:
=C2=A0- Immediately initiate a new connection with 0-RTT and pr= esent the unique connection ID so the server can transfer all connection st= ate to that new 5-tuple.
=C2=A0- Skip PKC and send a previous= ly-unused shared secret in the clear to the server (e.g., using a rolling c= ode on the connection ID) as weak proof that this new 5-tuple is the legit = owner of the connection state. (Strong proof comes in the form of being abl= e to speak over the encrypted channel.)

Doing this preemp= tively reveals less information about the client's movements, but is no= t always possible.

If the client *doesn't*= know the 5-tuple is changing, you run into the situation in step 4. Sendin= g a public reset then signals to a passive observer that a client has proba= bly changed its address, likely making for easy traffic analysis to link th= e two connections, but this seems no worse than any of the other proposals = short of always sending a different connection ID in every packet. (Sending= different connection IDs in every packet is still probably feasible at the= cost of either wire or=20 state space, depending on how it's implemented. Not sure if it's wo= rth=20 the complexity, but the same can be said for anything other than a static p= laintext connection ID in all packets.)

Part o= f the difficulty of explaining this is the over-use of the word "conne= ction", which is why I used "flow" in my original reply. Wit= h TLS we talk about a "session" when referring to resumption, but= that term describes the security context, and has nothing to do with the a= pplication data streams being protected, which are 1:1 with TCP connections= and so do not resume across connections without application support. I thi= nk what we're all proposing, irrespective of mechanism, is that with QU= IC the entire connection context, including the state of all streams, be re= sumed with a new 5-tuple once ownership of the connection context has been = transferred to that new 5-tuple.

Kyle
--001a1142f5c2bb557a0549d7e7f5-- From nobody Fri Mar 3 11:09:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBD71295C0 for ; Fri, 3 Mar 2017 11:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.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 q0rdsQ0DEM9j for ; Fri, 3 Mar 2017 11:09:13 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0050.outbound.protection.outlook.com [104.47.41.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15E91294CF for ; Fri, 3 Mar 2017 11:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IjvSirRhE5JLfZKlPH/8MwiIk94Mba+QPkZynmwXwpM=; b=fcuxw/LpOZwTijL2b3ba7NoyoaWDhdH+2L4yRTNvaUrGYyRGvAWwkDspR7WeIzisDFBmIAyoiIECIknrUoOebHLv1RkLexmJDDDALXf5Rj9tcYzw2nG2b8U3roA1QG5Ml02kktF3n8sCJVyx8i9jz3AaPhsQ5j15K5Jn2MRZIAw= Received: from BN6PR02MB2323.namprd02.prod.outlook.com (10.168.254.13) by BN6PR02MB2324.namprd02.prod.outlook.com (10.168.254.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Fri, 3 Mar 2017 19:09:10 +0000 Received: from BN6PR02MB2323.namprd02.prod.outlook.com ([10.168.254.13]) by BN6PR02MB2323.namprd02.prod.outlook.com ([10.168.254.13]) with mapi id 15.01.0933.019; Fri, 3 Mar 2017 19:09:10 +0000 From: Michael Thornburgh To: Martin Thomson , "Swindells, Thomas (Nokia - GB)" Subject: RE: Changing IPs and amplificiation Thread-Topic: Changing IPs and amplificiation Thread-Index: AQHSk4vZzdVTj95ycU+HkqruhCBHAKGCIX6AgAA/+lOAAAKtgIAATRwAgAAgLPCAACuwAIAAerDi Date: Fri, 3 Mar 2017 19:09:10 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [25.168.111.132] x-ms-office365-filtering-correlation-id: 09132437-5bc6-4e22-c177-08d46268c600 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR02MB2324; x-microsoft-exchange-diagnostics: 1; BN6PR02MB2324; 7:+JoRS4n602W1l/s6pjSciPuuS/MrdPbnHVdpBQSDEAyNwOe7wlj5v1UY8FMPP8l9kR979w5CNoHPtUDDZ9WaXJ6QDyEEC9+GsmtnWv7rzVbUcjVT/Jw+JaxJ2NdFZhdsZx5CV/KEnUPVY28TVMr/vtCU472fpUHM9CWJbK1sxUVPQJhCepunIIpU87X/3S0SmhijJEGmhXWielz0aNTyJQZUO3CeFuNhsoq5H+8Ksx+pYAMApARXyma93p7W0SKavtAMzuXF5poIPSmZWjKZQmE1Flp5HK1I8SCxI/LpQsbS93cn+kh/f+PXXRZeS45cA7TUeTpJBT9UqVxBfbjXoQ==; 20:v2AzqzmD4vMszvAnJLtHRNPoChTBhU75Tx1D09E9rgtlCYNGGS/3/S1gtZ+fa7EhRC/IY63XGm8cziSDYas/q2sZTEMmXVcSJWf2EuMXovbO26upmWHc6puaZFejPBw45wao02B1rBCbSXD4OHZbnpkOUIfdakaWATUcDQj8Knc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:BN6PR02MB2324; BCL:0; PCL:0; RULEID:; SRVR:BN6PR02MB2324; x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(24454002)(377454003)(8676002)(3280700002)(81166006)(229853002)(2906002)(92566002)(74316002)(66066001)(77096006)(6436002)(3480700004)(3660700001)(189998001)(8936002)(50986999)(305945005)(54356999)(76176999)(33656002)(106116001)(6506006)(99286003)(102836003)(2900100001)(55016002)(25786008)(53936002)(53546006)(7696004)(8990500004)(2950100002)(93886004)(38730400002)(5660300001)(3846002)(7736002)(9686003)(86362001)(122556002)(68736007)(6116002)(6306002)(39060400002)(10090500001)(54906002)(4326008)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR02MB2324; H:BN6PR02MB2323.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 19:09:10.1769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2324 Archived-At: Cc: Jana Iyengar , Subodh Iyengar , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 19:09:15 -0000 > From: QUIC [quic-bounces@ietf.org] on behalf of Martin Thomson [martin.th= omson@gmail.com] > Sent: Friday, March 3, 2017 3:34 AM >=20 > On 3 March 2017 at 20:38, Swindells, Thomas (Nokia - GB) > wrote: > > Can an attacker simply replay a genuine packet to the server, modifying= it > > with a different source address, or does the packet number and other > > information also need to be modified, and if so does this require them = to > > have parts of the encryption context? If the packets are strongly > > authenticated then it seems like the probability is that it is a client= (or > > gateway) flip-flopping between addresses rather than an attacker, and > > keeping the connection alive is the desired behaviour. >=20 > Packets with duplicate numbers will be dropped (they will be decoded > with a vastly different packet number and decryption will then fail). >=20 > As it stands, IP and port are not authenticated. I don't believe that > it is possible to have a functional protocol and authenticate these. > So an attacker could move packets from one path to another. But it > requires an on-path attacker to receive the values on the return side. >=20 > As long as we can do the return routeability check as marcelo and Jana > observe, we can avoid sending too much down a path that neither the > client nor the attacker are on (noting that client and attacker may be > one and the same). to safely verify an address change you need something like a "ping-reply" t= hat will return verbatim whatever was sent in a ping. just acking the ping isn'= t sufficient. for the method RTMFP uses, see section 3.5.4.2 of RFC 7016: https://tools.ietf.org/html/rfc7016#section-3.5.4.2 this method is very conservative and doesn't send any data to a new address (other than the connectivity check) until the connectivity check is receive= d. if you're busy sending data, this costs you one RTT, and maybe even one RTO. the met= hod could be modified a bit to optimistically change DESTADDR right away and se= t an alarm (for "something that's probably enough" like N * RTO where N isn't too big)= for changing the address back. if the alarm fires, someone was screwing with y= ou and you change the address back and don't try the optimistic method again. if = you get the connectivity check reply then you clear the alarm and everything is awesome= . in every case, when changing the destination address, the safe thing to do = is to collapse the congestion window back to CWND_INIT, since you don't know anything for sure about the new path. only acks for newly sent packets should increase the congestion window, so any acks that might be draining out of the network wouldn't improperly increase the congestion win= dow for the new path. -mike From nobody Fri Mar 3 15:57:23 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D08129666; Fri, 3 Mar 2017 15:55:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Subject: quic - Requested session has been scheduled for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532333.15846.17427675472419836197.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:23 -0800 Archived-At: Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:23 -0000 Dear Lars Eggert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:30:00) Thursday, Morning Session I 0900-1130 Room Name: Vevey 1/2 size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: irtfopen artarea taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch httpbis tls saag tsvarea Second Priority: rtcweb webpush acme t2trg People who must be present: Sean Turner Mark Nottingham Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Mike Bishop Ian Swett Resources Requested: Projector in room Meetecho support in room Experimental room setup (boardroom and classroom) subject to availability Special Requests: Please ping us if you have agenda pressure, to see if we can give up the second slot. --------------------------------------------------------- From nobody Sun Mar 5 05:46:59 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3828B1295B6; Sun, 5 Mar 2017 05:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKOPAf-9odG4; Sun, 5 Mar 2017 05:46:56 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4388C1295AD; Sun, 5 Mar 2017 05:46:55 -0800 (PST) Received: from mail-ot0-f177.google.com (mail-ot0-f177.google.com [74.125.82.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9735B278333; Sun, 5 Mar 2017 22:46:53 +0900 (JST) Received: by mail-ot0-f177.google.com with SMTP id i1so98487858ota.3; Sun, 05 Mar 2017 05:46:53 -0800 (PST) X-Gm-Message-State: AMke39n6GhwdwRxChF0zbSG5+KFm9rJHoL5M7wmb9wntCgTp6MF2DSisDyXGIuCoG/r9X6AfCv5N8kTyhJudeg== X-Received: by 10.157.31.57 with SMTP id x54mr5404986otd.186.1488721612193; Sun, 05 Mar 2017 05:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Sun, 5 Mar 2017 05:46:51 -0800 (PST) In-Reply-To: References: <57f78e9b-f75b-03da-0d3f-7405d645f7bd@it.uc3m.es> From: Yoshifumi Nishida Date: Sun, 5 Mar 2017 05:46:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: A single alarm in draft-ietf-quic-recovery To: Ian Swett Content-Type: multipart/alternative; boundary=001a113d054add5a710549fc0258 Archived-At: Cc: marcelo bagnulo braun , draft-ietf-quic-recovery@ietf.org, "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 13:46:58 -0000 --001a113d054add5a710549fc0258 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 3, 2017 at 9:03 AM, Ian Swett wrote: > Great questions, sorry for the delay. Answers inline. > > On Tue, Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun > wrote: > >> Hi, >> >> The current version of the draft uses a single alarm for all timer based >> loss detection, as specified in section 3.4 of the draft. >> >> I am not sure i follow how you do this. >> >> I particular, I am uncertain you can avoid having two separated alarms, >> one for the RTO and another one for tail probe (at least). >> >> I mean, if i understand correctly, the RTO alarm should be set when you >> send the oldest packet (I guess a usual approximation is to set it when a >> given packet becomes the oldest, i.e. it is ok to set it when an ack >> arrives and acks the oldest packet (packet 5) making another packet (packet >> 6) to become the oldest packet, instead of setting the alarm when packet 6 >> was actually sent). >> >> I understand that the tail loss probe alarm is set when the last packet >> was sent (and the connection is in open state). >> > > QUIC sets the RTO alarm based on the most recently sent packet, just like > TLP, and it always sends TLPs before arming the RTO timer. These are two > subtle but significant difference from how TLP and RTO are defined in TCP. > Both are less aggressive than TCP, which I tend to think is good in this > case. QUIC's goal is to continue making forward progress, not only move > the left edge forward, so we didn't see a need to have two competing > retransmission timers for almost identical purposes. > > Another important difference is that QUIC's TLP retransmits the earliest > outstanding packet when no new data is available, not the most recent, > under the theory it's more likely to be lost and QUIC's packet numbers > means there are no issues with ambiguity. > > >> So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and >> suppose no ACK is received. >> >> The RTO timer should be set when packet 1 is sent while the TLP timer >> should be set when the packet 9 is sent. >> >> If i understand it correctly, according to the draft, the alarm will be >> set in TLP mode (twice) and then it wil enter in RTO mode. >> >> Suppose no ack comes back, this basically means that the actual RTO will >> be fired 2 TLP timeout later than the recommended RTO timeout, correct? >> (neglecting the transmission delay for packets 1 to 9 which may not be >> negligible if the number of inflight packets is high) >> > > That's correct and intended. > let's say if we send 2 packets almost simultaneously, the alarm duration will be set to (2 * srtt)? (I presume srtt is larger than kMinTLPTimeout here) and, if we send 3 packets almost simultaneously, the alarm duration will be set to (srtt + 4 * rttvar)? If this is correct, depends on rttvar, we might wait longer when we send 2 packets? BTW, The draft says: o tlp_count: The number of times a tail loss probe has been sent without receiving an ack. o rto_count: The number of times an rto has been sent without receiving an ack. Are these correct? It seems to me that they are the number of times alarms have been set. BTW, I think it would be great if you could put a call graph for these pseudo functions in the feature version if possible. Thanks, -- Yoshi --001a113d054add5a710549fc0258 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Mar 3, 2017 at 9:03 AM, Ian Swett <ianswett@google.com> wrote:
Great questions, sorry for the delay.=C2=A0 Answers inline.

On Tue, Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun <= span dir=3D"ltr"><marcelo@it.uc3m.es> wrote:
Hi,<= br>
The current version of the draft uses a single alarm for all timer based lo= ss detection, as specified in section 3.4 of the draft.

I am not sure i follow how you do this.

I particular, I am uncertain you can avoid having two separated alarms, one= for the RTO and another one for tail probe (at least).

I mean, if i understand correctly, the RTO alarm should be set when you sen= d the oldest packet (I guess a usual approximation is to set it when a give= n packet becomes the oldest, i.e. it is ok to set it when an ack arrives an= d acks the oldest packet (packet 5) making another packet (packet 6) to bec= ome the oldest packet, instead of setting the alarm when packet 6 was actua= lly sent).

I understand that the tail loss probe alarm is set when the last packet was= sent (and the connection is in open state).

QUIC sets the RTO alarm based on the most recently sent packet= , just like TLP, and it always sends TLPs before arming the RTO timer.=C2= =A0 These are two subtle but significant difference from how TLP and RTO ar= e defined in TCP.=C2=A0 Both are less aggressive than TCP, which I tend to = think is good in this case.=C2=A0 QUIC's goal is to continue making for= ward progress, not only move the left edge forward, so we didn't see a = need to have two competing retransmission timers for almost identical purpo= ses.

Another important difference is that QUIC'= ;s TLP retransmits the earliest outstanding packet when no new data is avai= lable, not the most recent, under the theory it's more likely to be los= t and QUIC's packet numbers means there are no issues with ambiguity.


So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and suppos= e no ACK is received.

The RTO timer should be set when packet 1 is sent while the TLP timer shoul= d be set when the packet 9 is sent.

If i understand it correctly, according to the draft, the alarm will be set= in TLP mode (twice) and then it wil enter in RTO mode.

Suppose no ack comes back, this basically means that the actual RTO will be= fired 2 TLP timeout later than the recommended RTO timeout, correct? (negl= ecting the transmission delay for packets 1 to 9 which may not be negligibl= e if the number of inflight packets is high)

That's correct and intended.
let's say if we send 2 packets almost simultaneously, the = alarm duration will be set to (2 * srtt)?
(I presume srtt is larg= er than kMinTLPTimeout here)=C2=A0

and, if we send= 3 packets almost simultaneously, the alarm duration will be set to (srtt += 4 * rttvar)?
If this is correct, depends on rttvar, we might wai= t longer when we send 2 packets?

BTW, The draft sa= ys:
   o  t=
lp_count: The number of times a tail loss probe has been sent
      without receiving an ack.

   o  rto_count: The number of times an rto has been sent without
      receiving an ack.

Are these correct? It seems to me that they ar= e the number of times alarms have been set.

BTW, I= think it would be great if you could put a call graph for these pseudo fun= ctions in the feature version if possible.

Thanks,=
--
Yoshi


=C2= =A0

--001a113d054add5a710549fc0258-- From nobody Sun Mar 5 14:16:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAB61294ED for ; Sun, 5 Mar 2017 14:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 J8CdFVRkLyDl for ; Sun, 5 Mar 2017 14:16:46 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4711294C5 for ; Sun, 5 Mar 2017 14:16:45 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id n127so247321800qkf.0 for ; Sun, 05 Mar 2017 14:16:45 -0800 (PST) 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=jI3svEris4un6voOdbLgQ4XOKdAfGZypnGqdyqnHfoM=; b=rj3el0tl/GuDJ4wTOltCjefecaKmaJPOGP3M7eg/c8Su4EKpEbu04O+t9g1pW3U0gx AY5dwcUcgCFrt+8nQ0P3QPq/8UucTSO9TDJjyGFXrOnAM4b7TW2UMCELoVF2TsjuT40d 8RYlL9wib3pRY80lRwae81/3+R1rO4C8AoNPFvI72JcsMopOm5iruBQevbHem21yK6Um E34OO/H5wQ1GW/0X7TcUp95xoIWwYXQqyKHQj2T/7y6gnGgs7QqmsdKyJxWKxx13BG4B u1xFTYoP9s7CUdGM82MPi9n/GCLy5jKQz9htgMxc+5loOLU+n4iNyXatXnDV3ZO+HaNC uG9A== 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=jI3svEris4un6voOdbLgQ4XOKdAfGZypnGqdyqnHfoM=; b=O0urxVFTDAhDdFqSMUW45/IeTDo75fkcTWIkQcD3pdjPSOcqHXGPVah+axparugM5e DzINdclACFJXdSekBRDsW3gRP45Ia+bMcX9ioBLQKmqiI446K7aiDXCEhA8WM5b1wo1N huazBDjqZarCWMwFZa8U/+kPkEENIMfW/Hq31BVyGPKYgS1kPSGoGHOQ+IG2Xb3sGwub EjxouHDSkD5A5F/W5JJ61Tm+8pB2Cn6zU4JRn9QcndYZAYSqXPx4csjOvqfTaoJjxuXg qxg2NtM/fzR6Djjq8PZk2C9gDENSTw347JNFDT0671sNvpI5mz3FOY5bRNfzKE+NCgod +1FQ== X-Gm-Message-State: AMke39lIhg0F5pO5HsPLlU+FFViQIG2enxtQOJLKbh+icOLmT/7xKELLf3OnhapOPE57Cjp+2mdaJYnx5mSN2w== X-Received: by 10.200.46.208 with SMTP id i16mr13194851qta.13.1488752204824; Sun, 05 Mar 2017 14:16:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 5 Mar 2017 14:16:44 -0800 (PST) From: Martin Thomson Date: Mon, 6 Mar 2017 09:16:44 +1100 Message-ID: Subject: Move GOAWAY to HTTP draft To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 22:16:47 -0000 Mirja asks an interesting question: > I'm actually wondering if GOAWAY is really part of the transport semantics or should be an application layer signal...? -- https://github.com/quicwg/base-drafts/pull/354#issuecomment-283937992 I can't think of a reason not to move GOAWAY. Should we? From nobody Sun Mar 5 14:36:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472781294C5 for ; Sun, 5 Mar 2017 14:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 P-5QStdQt1WA for ; Sun, 5 Mar 2017 14:36:39 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA4F1293E1 for ; Sun, 5 Mar 2017 14:36:38 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v198so23160760ywc.2 for ; Sun, 05 Mar 2017 14:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rwq/d5/lCQXDvOxPPrPSfbkoxyZEaBgtAMHc/NXKC9M=; b=UfdfIF23ih/WZf7tZoVVmadkHz9LPPIm3qTScHYCZtDFKm9bdxlyXma9NQPDv4wlQL isandqXM3JXM9a5OoqLvFq98J6s9OFRelwq7SlBglQZf/+XjxZgGAc8UGlqaoYDfzpHk 39saCiac7wsgPACBP5KoBkBv8KMW7DU0sICt/Bo69Mtwzh8kzjvKZbQCV9hPTYNIfyh0 ZWNPpMePMankZrjkO+2O9RDuJ4tEniBUI3mXitMSz1V4o+8X42/5t2MtLmOzQsNQYSLU 9nUmRhqGaAwnsv1/A3ePrms78ZBBNb7/VIqQkwMwtaPHThMRRzlzbtqmknV8uxARwCcs 0oRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rwq/d5/lCQXDvOxPPrPSfbkoxyZEaBgtAMHc/NXKC9M=; b=dgsOkABojG5Uh+icVIYHLYdJhQZVQYGqRkL3HqLGSh0xe0qbDPo+1LTDk9HvCxQjub sI14c101lNnlRzaz/incy7yXTv3YMLCHwu47KrVesLQvqqZ1BCR4pMK9nVDPNDxmpsBx uEPutiNkW+mE8gxXDKaXDeCpxKeXtG4by+VGYndQjpRtntZjlvoUSkGsVEUu1RuIFaCq I00/C4eoK6tthMx7U58cKcOcgacGFpZV0JbPBE+OQnPveNr7UgvtcM6EnbBT7Lmvxurp A+zaaJ/8T0g+feENrMXQ3U2JQvicnntq3aK11jigq4094pXjoWxgJERoaAXY2pAsBChF f3Ew== X-Gm-Message-State: AMke39m9/P/l0Ov9aOMpGHX7alEQR5Tnwsx9b0F3Ar8MLf4jqFBIM0aq7RIqAt9tQyWPzbMs9/STB10iKnj1Buud X-Received: by 10.13.237.1 with SMTP id w1mr9468966ywe.7.1488753398044; Sun, 05 Mar 2017 14:36:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.198.10 with HTTP; Sun, 5 Mar 2017 14:36:17 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sun, 5 Mar 2017 17:36:17 -0500 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0864a873816a054a0369ed Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 22:36:40 -0000 --94eb2c0864a873816a054a0369ed Content-Type: text/plain; charset=UTF-8 I believe we want a way to do a clean shutdown and say what the GOAWAY will/could say(once a second stream id is added): "No more streams after these will be created and existing streams will be finished, then we're done." The question of whether we need GOAWAY is very much intertwined with the conversations about CONNECTION_CLOSE and public reset. Currently, I think GOAWAY should be used for clean connection termination, analogous to TCP's FIN WAIT. In a multiplexed transport, a way to indicate that no new streams will be opened seems critical for a clean close. Conceptually, it's a connection level FIN. I can imagine doing this with CONNECTION_CLOSE instead, but then you'd have to specify the max stream ids and use a reserved error code that has a very different meaning from the error cases. So my current thinking is: - clean shutdown = GOAWAY and then silent close once the fin wait style timeout expires - error shutdown = CONNECTION_CLOSE or public reset(depending on how that discussion resolves) which indicates no more data should be expected for the connection. That being said, we could rename it to CONNECTION_FIN if that made it feel more transporty and less confusing than re-using the HTTP2 term. On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson wrote: > Mirja asks an interesting question: > > > I'm actually wondering if GOAWAY is really part of the transport > semantics or should be an application layer signal...? -- > https://github.com/quicwg/base-drafts/pull/354#issuecomment-283937992 > > I can't think of a reason not to move GOAWAY. Should we? > > --94eb2c0864a873816a054a0369ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe we want a way to do a clean shutdown and say wha= t the GOAWAY will/could say(once a second stream id is added):
"No= more streams after these will be created and existing streams will be fini= shed, then we're done."

The question of w= hether we need GOAWAY is very much intertwined with the conversations about= CONNECTION_CLOSE and public reset.=C2=A0 Currently, I think GOAWAY should = be used for clean connection termination, analogous to TCP's FIN WAIT.= =C2=A0 In a multiplexed transport, a way to indicate that no new streams wi= ll be opened seems critical for a clean close.=C2=A0 Conceptually, it's= a connection level FIN.

I can imagine doing this = with CONNECTION_CLOSE instead, but then you'd have to specify the max s= tream ids and use a reserved error code that has a very different meaning f= rom the error cases.

So my current thinking is:
=C2=A0- clean shutdown =3D GOAWAY and then silent close once the fi= n wait style timeout expires
=C2=A0- error shutdown =3D CONNECTIO= N_CLOSE or public reset(depending on how that discussion resolves) which in= dicates no more data should be expected for the connection.

<= /div>
That being said, we could rename it to CONNECTION_FIN if that mad= e it feel more transporty and less confusing than re-using the HTTP2 term.<= /div>


On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
Mirj= a asks an interesting question:

> I'm actually wondering if GOAWAY is really part of the transport s= emantics or should be an application layer signal...? -- https://github.com/quicwg/base-drafts/pull/3= 54#issuecomment-283937992

I can't think of a reason not to move GOAWAY.=C2=A0 Should we?


--94eb2c0864a873816a054a0369ed-- From nobody Sun Mar 5 14:51:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B49129555 for ; Sun, 5 Mar 2017 14:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 sbxmo8VQxzp4 for ; Sun, 5 Mar 2017 14:51:28 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 82D271294AE for ; Sun, 5 Mar 2017 14:51:28 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id p64so10108498qke.1 for ; Sun, 05 Mar 2017 14:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tvFsRkH8RKEVyAdM3py8PDvrMcnlmAT9sn3lWvAXLyM=; b=f7sRK87+Z2k2EV1x+48pTbVT/icHD5hm2N0CzgW53jGojmScbjkSPSMTcR53qS9cIu 5DECIn/xw70SYfOCvKf+N1BZ4MgLq+s1e6mB/KeMT/qzPyZBPt58jetVNGvS+U8bpenv D2erqn2BNe4RCB8DBfjXw08mRR7AUE4nSoILBOr1ryZZFFr8Igjf9dkZwzTOp6B8noWG 5vtO66WISspoTWiualmlyO4hzGdU4gkEGHhzc8L+s4sjULMY9XYXE15z4tjQDZ+1HoxV zfqgvuO4jjwCh1XHXFhQ6mT/DSw1mYwSXUkdnnqnOumoaxThW1lhbfhf1biHt4iBmiKY z9xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tvFsRkH8RKEVyAdM3py8PDvrMcnlmAT9sn3lWvAXLyM=; b=hqE+h0aLm+wORWc4jZHsev+6HdHGx81fB6C/W1Y4i6kF/wQAGLJEGg3HVJI3OX1Mrp Skrx9IIUqqE6htwfcb49zjNFhuwO8s1jJZ2qfp3XXfkaZicSbMeKRRFUDoEgbgf0IjJH STR8+8Ymkupuk6PMlrXfyTWCOhzSlur00uT044YUJ5TisxH2cczehLyBxh0I+g7ft6I1 Av4togGqfadzVA5BYzplTb75p2INaIXVirg39BzjYTKC5F1xPCw3l26GwoaRXqxtR9p8 f/gWx+3HLZzTwCTz8inLOHcLh7rm2lm9rb0xGWFpGR1dJ7UfiONtKQIj53eDYKTBa7WW 7xrA== X-Gm-Message-State: AMke39llIKm6pRvObEVNKrpkKv2tutm2IJjx1MlnY9AD29YbFB7DCs8h+uPY1t9KF82gBT1gzevt/tbU+VeeUQ== X-Received: by 10.237.51.5 with SMTP id u5mr14584403qtd.247.1488754287641; Sun, 05 Mar 2017 14:51:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 5 Mar 2017 14:51:27 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 6 Mar 2017 09:51:27 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 22:51:30 -0000 You see, I agree that GOAWAY - or something like it - is critical for clean shutdown. But it's just one potential design. There are two pieces of information that it carries: 1. the connection is going to go away 2. these streams never got used and so if you want to do something with them elsewhere, go for it For the first, you suggest that you need a signal so that you can start a timer. I don't think that the timer is necessary, or something we should assume. Some connections might take a long time to settle down after GOAWAY and that is fine. Some HTTP/2 implementations send GOAWAY with a value of 2^31-1; they want to trigger a failover, but don't want to disrupt any current activity. For that reason, I think that FIN WAIT is a nasty design choice. The second is something that I don't think that the transport needs to know. I couldn't think of a reason. And the application protocol knows even better which streams were unused than QUIC. QUIC only knows if bytes crossed the threshold between it and the application protocol. At that point, it has to assume that something important happened. On the other hand, the application protocol can happily abandon streams that didn't result in any real work getting done. For instance, receiving a few QPACK octets might not result in any real activity because the implementation waits until the entire header block is present before doing work. Or an HTTP request was just on a queue awaiting processing and was cleanly removed from that queue. I said before that GOAWAY is just one potential design choice. Another design doesn't even involve establishing whether streams can be retried. That's something that might be HTTP-specific. On 6 March 2017 at 09:36, Ian Swett wrote: > I believe we want a way to do a clean shutdown and say what the GOAWAY > will/could say(once a second stream id is added): > "No more streams after these will be created and existing streams will be > finished, then we're done." > > The question of whether we need GOAWAY is very much intertwined with the > conversations about CONNECTION_CLOSE and public reset. Currently, I think > GOAWAY should be used for clean connection termination, analogous to TCP's > FIN WAIT. In a multiplexed transport, a way to indicate that no new streams > will be opened seems critical for a clean close. Conceptually, it's a > connection level FIN. > > I can imagine doing this with CONNECTION_CLOSE instead, but then you'd have > to specify the max stream ids and use a reserved error code that has a very > different meaning from the error cases. > > So my current thinking is: > - clean shutdown = GOAWAY and then silent close once the fin wait style > timeout expires > - error shutdown = CONNECTION_CLOSE or public reset(depending on how that > discussion resolves) which indicates no more data should be expected for the > connection. > > That being said, we could rename it to CONNECTION_FIN if that made it feel > more transporty and less confusing than re-using the HTTP2 term. > > > On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson > wrote: >> >> Mirja asks an interesting question: >> >> > I'm actually wondering if GOAWAY is really part of the transport >> > semantics or should be an application layer signal...? -- >> > https://github.com/quicwg/base-drafts/pull/354#issuecomment-283937992 >> >> I can't think of a reason not to move GOAWAY. Should we? >> > From nobody Sun Mar 5 15:27:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F92129521 for ; Sun, 5 Mar 2017 15:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 n6Iwho24KQAm for ; Sun, 5 Mar 2017 15:27:18 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 D7F27126579 for ; Sun, 5 Mar 2017 15:27:17 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id 203so40717126ith.0 for ; Sun, 05 Mar 2017 15:27:17 -0800 (PST) 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=pVtppLWgE05R26JANkwysDJaAsfdZXmsB/wZ1dtwzbY=; b=tHQltgMVTOmCLLQafA0d+0tygxzPZV+9FgsJM8f8RxWWeGW1w4sUxl1jcCzEFI8cSn Omyh2M2QkAFWpjoPNTKNqYrr/lQbI2t8Heipcq9QaRzfKW8V/3gl0ADMOIO8fh2yDjtF vHOaQQ46uiD70/7jR4oJ6JJ+dl5ZlJHPGpslPz72u+flSXdfW08JE90rVXL6elbqe8PE 5FqkIJACFWzk/0j2aQTS4Qe9NViufY1FbBYhJm+irERvPCjtqqjuJEV+tHChNKg5x3So 8LfD9SYKeRSXRrD/7svDq8zwE5VjQVlIgYmcbUCacoJjX2P5ToqCYL4t1lQ1jahynFkb GjmA== 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=pVtppLWgE05R26JANkwysDJaAsfdZXmsB/wZ1dtwzbY=; b=peBzIZU2xPxdHAnidCcQvWtsEons45GxLHyYKsvRVTKAaTau1mC4b9+8hBiOvMfk/R FNOky9CU62WrWtu3PfAWfyHFv5FrAloHwc6T/vrKl0Y4HdmOCtQ9fUmREDAhteOypHhH ORYnSSlvoOgASfJ7T/rZoAnAyIaAzn9596HNmiwOFmkIhajljzz84QVcr59OJNxNrLEz R8zlcLZRusXFMpEgwf3HTqdiNcfUQigHIkcG7+a+mOr5Ov7NO6v3kiBI5AQ6ASSg//xV bqUDB7WoFmmS+3cyabdHxk09uvWBkVuoVkSFe2o0X9SI41juKcIku6f5ivjukUiAAY0L xclg== X-Gm-Message-State: AMke39m2FDZA/eUQ64eejQ3kuIKB9Smay8Z6XsczdP0xQ6GlLSBhlsvucxfAV3uFHukLyJx5HiXTojGB4ZguRg== X-Received: by 10.36.169.12 with SMTP id r12mr12569388ite.69.1488756437226; Sun, 05 Mar 2017 15:27:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Clemente Date: Sun, 05 Mar 2017 23:27:06 +0000 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson , Ian Swett Content-Type: multipart/alternative; boundary=f403045fb11c991b28054a041e0b Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 23:27:19 -0000 --f403045fb11c991b28054a041e0b Content-Type: text/plain; charset=UTF-8 One additional point is that there might be applications other than HTTP where streams are more long lived, potentially even for the whole duration of the connection. Even other applications might require more streams to be opened for a clean shutdown. In both cases, a GOAWAY carrying information about the highest stream number might not be very useful. Since we're effectively defining part of the API that implementations will expose to applications here, I feel that we should think more about its general applicability. On Sun, 5 Mar 2017 at 23:51 Martin Thomson wrote: > You see, I agree that GOAWAY - or something like it - is critical for > clean shutdown. But it's just one potential design. There are two > pieces of information that it carries: > > 1. the connection is going to go away > 2. these streams never got used and so if you want to do something > with them elsewhere, go for it > > For the first, you suggest that you need a signal so that you can > start a timer. I don't think that the timer is necessary, or > something we should assume. Some connections might take a long time > to settle down after GOAWAY and that is fine. Some HTTP/2 > implementations send GOAWAY with a value of 2^31-1; they want to > trigger a failover, but don't want to disrupt any current activity. > > For that reason, I think that FIN WAIT is a nasty design choice. > > The second is something that I don't think that the transport needs to > know. I couldn't think of a reason. > > And the application protocol knows even better which streams were > unused than QUIC. QUIC only knows if bytes crossed the threshold > between it and the application protocol. At that point, it has to > assume that something important happened. On the other hand, the > application protocol can happily abandon streams that didn't result in > any real work getting done. For instance, receiving a few QPACK > octets might not result in any real activity because the > implementation waits until the entire header block is present before > doing work. Or an HTTP request was just on a queue awaiting > processing and was cleanly removed from that queue. > > I said before that GOAWAY is just one potential design choice. > Another design doesn't even involve establishing whether streams can > be retried. That's something that might be HTTP-specific. > > On 6 March 2017 at 09:36, Ian Swett wrote: > > I believe we want a way to do a clean shutdown and say what the GOAWAY > > will/could say(once a second stream id is added): > > "No more streams after these will be created and existing streams will be > > finished, then we're done." > > > > The question of whether we need GOAWAY is very much intertwined with the > > conversations about CONNECTION_CLOSE and public reset. Currently, I > think > > GOAWAY should be used for clean connection termination, analogous to > TCP's > > FIN WAIT. In a multiplexed transport, a way to indicate that no new > streams > > will be opened seems critical for a clean close. Conceptually, it's a > > connection level FIN. > > > > I can imagine doing this with CONNECTION_CLOSE instead, but then you'd > have > > to specify the max stream ids and use a reserved error code that has a > very > > different meaning from the error cases. > > > > So my current thinking is: > > - clean shutdown = GOAWAY and then silent close once the fin wait style > > timeout expires > > - error shutdown = CONNECTION_CLOSE or public reset(depending on how > that > > discussion resolves) which indicates no more data should be expected for > the > > connection. > > > > That being said, we could rename it to CONNECTION_FIN if that made it > feel > > more transporty and less confusing than re-using the HTTP2 term. > > > > > > On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson > > > wrote: > >> > >> Mirja asks an interesting question: > >> > >> > I'm actually wondering if GOAWAY is really part of the transport > >> > semantics or should be an application layer signal...? -- > >> > https://github.com/quicwg/base-drafts/pull/354#issuecomment-283937992 > >> > >> I can't think of a reason not to move GOAWAY. Should we? > >> > > > > --f403045fb11c991b28054a041e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One additional point is that there might be applicati= ons other than HTTP where streams are more long lived, potentially even for= the whole duration of the connection. Even other applications might requir= e more streams to be opened for a clean shutdown. In both cases, a GOAWAY c= arrying information about the highest stream number might not be very usefu= l.

Since we're effectively defining part of th= e API that implementations will expose to applications here, I feel that we= should think more about its general applicability.

On Sun, 5 Mar 2017 at 23:51 Ma= rtin Thomson <martin.thomson= @gmail.com> wrote:
You see,= I agree that GOAWAY - or something like it - is critical for
clean shutdown.=C2=A0 But it's just one potential design.=C2=A0 There a= re two
pieces of information that it carries:

1. the connection is going to go away
2. these streams never got used and so if you want to do something
with them elsewhere, go for it

For the first, you suggest that you need a signal so that you can
start a timer.=C2=A0 I don't think that the timer is necessary, or
something we should assume.=C2=A0 Some connections might take a long time to settle down after GOAWAY and that is fine.=C2=A0 Some HTTP/2
implementations send GOAWAY with a value of 2^31-1; they want to
trigger a failover, but don't want to disrupt any current activity.

For that reason, I think that FIN WAIT is a nasty design choice.

The second is something that I don't think that the transport needs to<= br class=3D"gmail_msg"> know.=C2=A0 I couldn't think of a reason.

And the application protocol knows even better which streams were
unused than QUIC.=C2=A0 QUIC only knows if bytes crossed the threshold
between it and the application protocol.=C2=A0 At that point, it has to
assume that something important happened.=C2=A0 On the other hand, the
application protocol can happily abandon streams that didn't result in<= br class=3D"gmail_msg"> any real work getting done.=C2=A0 For instance, receiving a few QPACK
octets might not result in any real activity because the
implementation waits until the entire header block is present before
doing work.=C2=A0 Or an HTTP request was just on a queue awaiting
processing and was cleanly removed from that queue.

I said before that GOAWAY is just one potential design choice.
Another design doesn't even involve establishing whether streams can be retried.=C2=A0 That's something that might be HTTP-specific.

On 6 March 2017 at 09:36, Ian Swett <ianswett@google.com> wrote= :
> I believe we want a way to do a clean shutdown and say what the GOAWAY=
> will/could say(once a second stream id is added):
> "No more streams after these will be created and existing streams= will be
> finished, then we're done."
>
> The question of whether we need GOAWAY is very much intertwined with t= he
> conversations about CONNECTION_CLOSE and public reset.=C2=A0 Currently= , I think
> GOAWAY should be used for clean connection termination, analogous to T= CP's
> FIN WAIT.=C2=A0 In a multiplexed transport, a way to indicate that no = new streams
> will be opened seems critical for a clean close.=C2=A0 Conceptually, i= t's a
> connection level FIN.
>
> I can imagine doing this with CONNECTION_CLOSE instead, but then you&#= 39;d have
> to specify the max stream ids and use a reserved error code that has a= very
> different meaning from the error cases.
>
> So my current thinking is:
>=C2=A0 - clean shutdown =3D GOAWAY and then silent close once the fin w= ait style
> timeout expires
>=C2=A0 - error shutdown =3D CONNECTION_CLOSE or public reset(depending = on how that
> discussion resolves) which indicates no more data should be expected f= or the
> connection.
>
> That being said, we could rename it to CONNECTION_FIN if that made it = feel
> more transporty and less confusing than re-using the HTTP2 term.
>
>
> On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson <martin.thoms= on@gmail.com>
> wrote:
>>
>> Mirja asks an interesting question:
>>
>> > I'm actually wondering if GOAWAY is really part of the tr= ansport
>> > semantics or should be an application layer signal...? --
>> > https://github.com/quicwg/base-drafts/pull/354#issuecomment-283937992
>>
>> I can't think of a reason not to move GOAWAY.=C2=A0 Should we?=
>>
>

--f403045fb11c991b28054a041e0b-- From nobody Sun Mar 5 17:16:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B86128B37 for ; Sun, 5 Mar 2017 17:16:32 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ugMs1hOYYTWG for ; Sun, 5 Mar 2017 17:16:30 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 71900124281 for ; Sun, 5 Mar 2017 17:16:30 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id o4so48477810ywd.3 for ; Sun, 05 Mar 2017 17:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pIKdORvZFOGcfnOZEDIl93pKVBitxnCZEcm1b8d4g+c=; b=gf5GnvV2SANuRrQolY8HnYj6EoUiHW6kX9gXEIlI7hW1rgKaIiVSu2hdKNVB99wPbh X65zGLBrB54e+eTs90xFrFdshTH0oOeIdWN7PfwXlg5aQBPwqZ1GFhQTvarFkmRko7b9 NAKu3wNdEuUyuShLz7WLc8k7eiJBp4sP98u5d7xuBM0bZ6lfJjtzo+CeCecLpzjlzD0a Odruf5wfeX5+OwOF0tOlzVJ4X9ohotY8zWN1MfbWG7xmC+uUU5B8iYYLXRZpHarM5dOx 2bFue1I2X/7QnZTwMcgU0/tm3utYqEm0iDl/czxQc5d5c26YoskyQgsIBoWOE5Sb3YKe BcmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pIKdORvZFOGcfnOZEDIl93pKVBitxnCZEcm1b8d4g+c=; b=LllsDD20fgCHya1WHNTg3xvSv38kQAvQKz0rPV3OgG2yhNKo/+wMfB9JR9qS5zI1XS E7WcFzB6+csHLrvcQcTX/8BmtSHLgjsr5FUuXFmhXiiQbPM50iIgDYIxKDAjoMYxlWJ9 yr8qmLxtegF0y4yZ5gRhLL70d02QBDWFHfRmpM2sTxedzB1vWS8kJjNnbF0p0bZoEuxh YHL/XecfIqpMh+QVWDixU1acNdG4cSKy4gYtFn8jduPA3FawpTSxlHkHJ8dB+bjwk0nf XCezT4B/hgiHCUTEEpXhfBeCphvNnVt1PF9fgzvnVgYM2KVeqj5E7UJ+pxyrD0gYvwzl 8ZOg== X-Gm-Message-State: AMke39klQ1ffzRsCGnRZP6D4As02jtb0H6zGwVLfAlv6QltNVlhbwU4R//pT6gYUqSHNoeoL6OoF/KAqYzBxX5kM X-Received: by 10.37.170.242 with SMTP id t105mr9496952ybi.174.1488762989482; Sun, 05 Mar 2017 17:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.198.10 with HTTP; Sun, 5 Mar 2017 17:16:09 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sun, 5 Mar 2017 20:16:09 -0500 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Lucas Clemente Content-Type: multipart/alternative; boundary=94eb2c19aeb024e6ed054a05a5c6 Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 01:16:32 -0000 --94eb2c19aeb024e6ed054a05a5c6 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 5, 2017 at 6:23 PM, Lucas Clemente wrote: > One additional point is that there might be applications other than HTTP > where streams are more long lived, potentially even for the whole duration > of the connection. Even other applications might require more streams to be > opened for a clean shutdown. In both cases, a GOAWAY carrying information > about the highest stream number might not be very useful. > In both those cases, a GOAWAY could be useful, but may not be critical, since it seems the application is defining the stream usage fairly clearly. > Since we're effectively defining part of the API that implementations will > expose to applications here, I feel that we should think more about its > general applicability. > > > On Sun, 5 Mar 2017 at 23:51 Martin Thomson > wrote: > >> You see, I agree that GOAWAY - or something like it - is critical for >> clean shutdown. But it's just one potential design. There are two >> pieces of information that it carries: >> >> 1. the connection is going to go away >> 2. these streams never got used and so if you want to do something >> with them elsewhere, go for it >> >> #2 would never have occurred to me if you hadn't pointed it out. I think the most critical thing GOAWAY indicates is when the connection is going to be completed in a clean way, because it indicates what the final stream IDs will be. > For the first, you suggest that you need a signal so that you can >> start a timer. I don't think that the timer is necessary, or >> something we should assume. Some connections might take a long time >> to settle down after GOAWAY and that is fine. Some HTTP/2 >> implementations send GOAWAY with a value of 2^31-1; they want to >> trigger a failover, but don't want to disrupt any current activity. >> >> For that reason, I think that FIN WAIT is a nasty design choice. >> > If you care about both sides knowing all the data they sent was received and all the data they received was acked, I believe you end up with a state machine using timers that's not so different from TCP's TIME_WAIT. Possibly we don't care about providing that, but TCP provides it, so I assumed we'd want to? The second is something that I don't think that the transport needs to >> know. I couldn't think of a reason. >> >> Totally agreed. > And the application protocol knows even better which streams were >> unused than QUIC. QUIC only knows if bytes crossed the threshold >> between it and the application protocol. At that point, it has to >> assume that something important happened. On the other hand, the >> application protocol can happily abandon streams that didn't result in >> any real work getting done. For instance, receiving a few QPACK >> octets might not result in any real activity because the >> implementation waits until the entire header block is present before >> doing work. Or an HTTP request was just on a queue awaiting >> processing and was cleanly removed from that queue. >> >> I said before that GOAWAY is just one potential design choice. >> Another design doesn't even involve establishing whether streams can >> be retried. That's something that might be HTTP-specific. >> > Can you explain what the other design is a bit more? > >> On 6 March 2017 at 09:36, Ian Swett wrote: >> > I believe we want a way to do a clean shutdown and say what the GOAWAY >> > will/could say(once a second stream id is added): >> > "No more streams after these will be created and existing streams will >> be >> > finished, then we're done." >> > >> > The question of whether we need GOAWAY is very much intertwined with the >> > conversations about CONNECTION_CLOSE and public reset. Currently, I >> think >> > GOAWAY should be used for clean connection termination, analogous to >> TCP's >> > FIN WAIT. In a multiplexed transport, a way to indicate that no new >> streams >> > will be opened seems critical for a clean close. Conceptually, it's a >> > connection level FIN. >> > >> > I can imagine doing this with CONNECTION_CLOSE instead, but then you'd >> have >> > to specify the max stream ids and use a reserved error code that has a >> very >> > different meaning from the error cases. >> > >> > So my current thinking is: >> > - clean shutdown = GOAWAY and then silent close once the fin wait style >> > timeout expires >> > - error shutdown = CONNECTION_CLOSE or public reset(depending on how >> that >> > discussion resolves) which indicates no more data should be expected >> for the >> > connection. >> > >> > That being said, we could rename it to CONNECTION_FIN if that made it >> feel >> > more transporty and less confusing than re-using the HTTP2 term. >> > >> > >> > On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson < >> martin.thomson@gmail.com> >> > wrote: >> >> >> >> Mirja asks an interesting question: >> >> >> >> > I'm actually wondering if GOAWAY is really part of the transport >> >> > semantics or should be an application layer signal...? -- >> >> > https://github.com/quicwg/base-drafts/pull/354#issuecomment- >> 283937992 >> >> >> >> I can't think of a reason not to move GOAWAY. Should we? >> >> >> > >> >> --94eb2c19aeb024e6ed054a05a5c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 5, 2017 at 6:23 PM, Lucas Clemente <lucas@lclemente.org<= /a>> wrote:
=
One additional point is that there might be applications o= ther than HTTP where streams are more long lived, potentially even for the = whole duration of the connection. Even other applications might require mor= e streams to be opened for a clean shutdown. In both cases, a GOAWAY carryi= ng information about the highest stream number might not be very useful.

In both those cases, a GOAWAY could be = useful, but may not be critical, since it seems the application is defining= the stream usage fairly clearly.=C2=A0





And the application protocol knows even better which streams were
unused than QUIC.=C2=A0 QUIC only knows if bytes crossed the threshold
between it and the application protocol.=C2=A0 At that point, it has to
assume that something important happened.=C2=A0 On the other hand, the
application protocol can happily abandon streams that didn't result in<= br class=3D"m_-7183943248153667142gmail-m_-3030197613973174566gmail_msg"> any real work getting done.=C2=A0 For instance, receiving a few QPACK
octets might not result in any real activity because the
implementation waits until the entire header block is present before
doing work.=C2=A0 Or an HTTP request was just on a queue awaiting
processing and was cleanly removed from that queue.

I said before that GOAWAY is just one potential design choice.
Another design doesn't even involve establishing whether streams can be retried.=C2=A0 That's something that might be HTTP-specific.


On 6 March 2017 at 09:36, Ian Swett <ianswett@google.com> wrote:
> I believe we want a way to do a clean shutdown and say what the GOAWAY=
> will/could say(once a second stream id is added):
> "No more streams after these will be created and existing streams= will be
> finished, then we're done."
>
> The question of whether we need GOAWAY is very much intertwined with t= he
> conversations about CONNECTION_CLOSE and public reset.=C2=A0 Currently= , I think
> GOAWAY should be used for clean connection termination, analogous to T= CP's
> FIN WAIT.=C2=A0 In a multiplexed transport, a way to indicate that no = new streams
> will be opened seems critical for a clean close.=C2=A0 Conceptually, i= t's a
> connection level FIN.
>
> I can imagine doing this with CONNECTION_CLOSE instead, but then you&#= 39;d have
> to specify the max stream ids and use a reserved error code that has a= very
> different meaning from the error cases.
>
> So my current thinking is:
>=C2=A0 - clean shutdown =3D GOAWAY and then silent close once the fin w= ait style
> timeout expires
>=C2=A0 - error shutdown =3D CONNECTION_CLOSE or public reset(depending = on how that
> discussion resolves) which indicates no more data should be expected f= or the
> connection.
>
> That being said, we could rename it to CONNECTION_FIN if that made it = feel
> more transporty and less confusing than re-using the HTTP2 term.
>
>
> On Sun, Mar 5, 2017 at 5:16 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> Mirja asks an interesting question:
>>
>> > I'm actually wondering if GOAWAY is really part of the tr= ansport
>> > semantics or should be an application layer signal...? --
>> > https://github.com/qui= cwg/base-drafts/pull/354#issuecomment-283937992
>>
>> I can't think of a reason not to move GOAWAY.=C2=A0 Should we?=
>>
>


--94eb2c19aeb024e6ed054a05a5c6-- From nobody Sun Mar 5 19:05:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB5A127ABE for ; Sun, 5 Mar 2017 19:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oOxPdZ8Ax3u for ; Sun, 5 Mar 2017 19:04:57 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F679126D73 for ; Sun, 5 Mar 2017 19:04:57 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id v125so73055595qkh.2 for ; Sun, 05 Mar 2017 19:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IICiAljDokhVObBT0RqGGKStiF3NftSCfL0WxTpxARM=; b=n3Ss7MBy+f2DahGwYwcqTZfm8AwJGWmNNysDxV3KBLISYJzM8wx5+6ryefLGA1pMfJ oFjGsY8bKdUSQtB0EWk94XRaCgPu/AnV5gPwS4x8Hu0yLX2pFnIHPVfjGOaxGkb/dhaC 81RCKQ+uT0ggQtsZMbnhD8RRTsTjHJeya2ReTCuuFBvLUI46R02ntzB7d8x4eu3PGdJ8 whufnCp8mHb7VJ/0FmpevQ5bOT73xq9YbiTBttGkvyXSmjwvTOn1miiXO7uLHTw4WYAD fywwClZNGcGnt/gNSFku/6ZGfKM+zAnPLDddn1d9xmQWxoE/OzKsOUuedBDWutpjBIb7 S1wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IICiAljDokhVObBT0RqGGKStiF3NftSCfL0WxTpxARM=; b=ZC8K56lVHiCyMefZ3rmQnrvlTqEfR1Noe9+MqJUO53jhtwAYdjfq1Sn00pMysOZ/Oq UhbrYT85Q0AHj/NOzZ3YFZ50C1oryujxMx1TB3ic895IC2dvkC4Y5PQazZ4YtrABmult +lWNgl8a336LJfvzO0tvy+O4TyWUCTJ4EdbQIBS8XUTP0Z40QJpJPAZRrdSm+Pl65uA2 rThEmCEke3GrOr0VAqeM4P1xj9ZkSMlBAWHSW+UoV4PDTDqBh44IkUVgbWQ8NaRVCcNK a14mbkB0fvMp1HAGcC6G1f/bTeFK7dW74oDUeBWJwVB0Ki1/JqftxKVSxpTyYCHq8YcG vTzg== X-Gm-Message-State: AMke39mW/l5/2vHfyjZR9UUjbjzs7PlYQ6pQlxyNHKhnxK76+NPVG3Yh1Ci20P6tvkWGs11JxBqtigM3rMMuuw== X-Received: by 10.200.46.91 with SMTP id s27mr15083473qta.278.1488769496585; Sun, 05 Mar 2017 19:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 5 Mar 2017 19:04:56 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 6 Mar 2017 14:04:56 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG , Lucas Clemente X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 03:04:59 -0000 On 6 March 2017 at 12:16, Ian Swett wrote: > If you care about both sides knowing all the data they sent was received > and all the data they received was acked, I believe you end up with a state > machine using timers that's not so different from TCP's TIME_WAIT. > Possibly we don't care about providing that, but TCP provides it, so I > assumed we'd want to? Assumptions are dangerous. I definitely think that some implementations will maintain a timer, but I can't say that ALL will. The idea that you have an unbounded duration on a shutdown command doesn't make a lot of sense. On the other hand, there are cases where graceful >> timely. That was something we definitely learned in HTTP/2 very late in development. For example, a server might want to shift load but don't care about the load that you have already taken on. I can imagine servers nudging new requests onto other nodes something like Alt-Svc/ALTSVC and GOAWAY, but leaving the old session open indefinitely. This makes much less sense in HTTP, because *most* requests are fairly tightly time bounded in one way or other. But a general purpose protocol doesn't need to have the same constraints. If we were to multiplex websockets with HTTP (leaving aside for the moment whether that's a good idea or not) that might be an example where using simple timers makes little sense. >> I said before that GOAWAY is just one potential design choice. >> Another design doesn't even involve establishing whether streams can >> be retried. That's something that might be HTTP-specific. > > > Can you explain what the other design is a bit more? Let's say that you are doing the WebRTC thing where you send individual video frames in separate streams (leaving aside for the moment whether that's a good idea or not). When you shut something like that down, you might not care if frame 63412 made it through or not. You could just say "I'm going away" and that's it. The stream identifiers in GOAWAY are only needed in protocols that a) care about retries and b) aren't consistently idempotent. From nobody Mon Mar 6 05:38:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8441294EF for ; Mon, 6 Mar 2017 05:38:12 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 txeZG7ztcR6t for ; Mon, 6 Mar 2017 05:38:11 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1031296EF for ; Mon, 6 Mar 2017 05:38:10 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id o4so57405727ywd.3 for ; Mon, 06 Mar 2017 05:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HAyvS+BUoRxGpiPQOaBSNB4+VDt2zEwV09iO4TtKHtI=; b=SAYP9YcI0/8UouiCPr9/RKD/4QuA4ek7joEpwUTAiH2kSiUvvWM8NX2/0T8ErN0pfu pa5ozJE1P5ihgi6hMGhD7YXAalfyoI6qENEp1JwJpsvevGrZ/OTL9zqmmCj051Y9QGoE DH088RrKcMhaTlCDqvY1jzkYZukw8cucviP00OE3muKXaDTFUBXNHLsgOlqQGlP08eVn vco3aRD7gCVplTNH45k7UAc0cHa3M1FwWBQUIHM0k84IV6MVjlNDp9CGdYd/cisGVrb2 T7TLono1KlQAxZvJyCfLdf2i9bl88JaBUU900wc9yPim/Y9wm+JdOtgTu4jz72JZlLNg Pjxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HAyvS+BUoRxGpiPQOaBSNB4+VDt2zEwV09iO4TtKHtI=; b=B16sdSW4KfbIU/713yKw/UQ79Bkthmn3ptTHLjTKQu9ZiCpsG8lral2YEh6IeiQ4Vi CTuMlLjISXmm4IEVoPTYsVWpiLR1rnJql3763MKuhEmBwRtLNpUoYsTHUGzcklp/wbDe EnO/SoGr6jE6/bf2abylc2CtCqAekYLPeHY3aXvTUI9bT0FHVsaedbsZ3jUsl5isZiLy e6F1DjrK+4vmbv16KJPIKngAGTInpI8H//Ebnq8b7eCIQc3aBdlT802ZQIwRl+IzX6KE vaeyONOq5iv58cC7Xd5asMHYUfJK1ldzk6MQ2ooV6nQMs3D+l4KLX/rTzOlluZ4Z+u+y XVaQ== X-Gm-Message-State: AMke39n0TnSMG4EjP2XqDQ4fvIqcPq8xgXNGD9VJ5HiGIp/wztYUZC6dzCqGaSKbOa2qaW4AtIFwWymejtuqhda+ X-Received: by 10.129.80.69 with SMTP id e66mr12187155ywb.241.1488807490013; Mon, 06 Mar 2017 05:38:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.198.10 with HTTP; Mon, 6 Mar 2017 05:37:49 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Mon, 6 Mar 2017 08:37:49 -0500 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson , Martin Duke Content-Type: multipart/alternative; boundary=001a1147f0789548b3054a10010e Archived-At: Cc: IETF QUIC WG , Lucas Clemente X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 13:38:12 -0000 --001a1147f0789548b3054a10010e Content-Type: text/plain; charset=UTF-8 On Sun, Mar 5, 2017 at 10:04 PM, Martin Thomson wrote: > On 6 March 2017 at 12:16, Ian Swett wrote: > > If you care about both sides knowing all the data they sent was received > > and all the data they received was acked, I believe you end up with a > state > > machine using timers that's not so different from TCP's TIME_WAIT. > > Possibly we don't care about providing that, but TCP provides it, so I > > assumed we'd want to? > > Assumptions are dangerous. I definitely think that some > implementations will maintain a timer, but I can't say that ALL will. > Agreed, some applications may not need a graceful close. So I guess that provides two options: 1) Make every application implement their own graceful close if they need it and only provide a way to kill the connection immediately. 2) Provide a transport layer graceful close(GOAWAY, or CONNECTION_FIN, etc). Not having a way to close the connection gracefully seems like a missing feature, but I'm not hung up on having it if it's really not generally useful. > The idea that you have an unbounded duration on a shutdown command > doesn't make a lot of sense. On the other hand, there are cases where > graceful >> timely. That was something we definitely learned in > HTTP/2 very late in development. For example, a server might want to > shift load but don't care about the load that you have already taken > on. I can imagine servers nudging new requests onto other nodes > something like Alt-Svc/ALTSVC and GOAWAY, but leaving the old session > open indefinitely. > > This makes much less sense in HTTP, because *most* requests are fairly > tightly time bounded in one way or other. But a general purpose > protocol doesn't need to have the same constraints. If we were to > multiplex websockets with HTTP (leaving aside for the moment whether > that's a good idea or not) that might be an example where using simple > timers makes little sense. > >> I said before that GOAWAY is just one potential design choice. > >> Another design doesn't even involve establishing whether streams can > >> be retried. That's something that might be HTTP-specific. > > > > > > Can you explain what the other design is a bit more? > > Let's say that you are doing the WebRTC thing where you send > individual video frames in separate streams (leaving aside for the > moment whether that's a good idea or not). When you shut something > like that down, you might not care if frame 63412 made it through or > not. You could just say "I'm going away" and that's it. > > The stream identifiers in GOAWAY are only needed in protocols that a) > care about retries and b) aren't consistently idempotent. > --001a1147f0789548b3054a10010e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 5, 2017 at 10:04 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 6 March 2017 at 12:16, Ian Swett <ianswett@google.com> wrote:
> If you care about both sides knowing all the data they sent was receiv= ed
> and all the data they received was acked, I believe you end up with a = state
> machine using timers that's not so different from TCP's TIME_W= AIT.
> Possibly we don't care about providing that, but TCP provides it, = so I
> assumed we'd want to?

Assumptions are dangerous.=C2=A0 I definitely think that some
implementations will maintain a timer, but I can't say that ALL will.

Agreed, some applications may not need a= graceful close. =C2=A0

So I guess that provides t= wo options:
1) Make every application implement their own gracefu= l close if they need it and only provide a way to kill the connection immed= iately.
2) Provide a transport layer graceful close(GOAWAY, or CO= NNECTION_FIN, etc).

Not having a way to close the = connection gracefully seems like a missing feature, but I'm not hung up= on having it if it's really not generally useful.

=

The idea that you have an unbounded duration on a shutdown command
doesn't make a lot of sense.=C2=A0 On the other hand, there are cases w= here
graceful >> timely.=C2=A0 That was something we definitely learned in=
HTTP/2 very late in development.=C2=A0 For example, a server might want to<= br> shift load but don't care about the load that you have already taken on.=C2=A0 I can imagine servers nudging new requests onto other nodes
something like Alt-Svc/ALTSVC and GOAWAY, but leaving the old session
open indefinitely.

This makes much less sense in HTTP, because *most* requests are fairly
tightly time bounded in one way or other.=C2=A0 But a general purpose
protocol doesn't need to have the same constraints.=C2=A0 If we were to=
multiplex websockets with HTTP (leaving aside for the moment whether
that's a good idea or not) that might be an example where using simple<= br> timers makes little sense.=C2=A0

>> I said before that GOAWAY is just one potential design choice.
>> Another design doesn't even involve establishing whether strea= ms can
>> be retried.=C2=A0 That's something that might be HTTP-specific= .
>
>
> Can you explain what the other design is a bit more?

Let's say that you are doing the WebRTC thing where you send
individual video frames in separate streams (leaving aside for the
moment whether that's a good idea or not).=C2=A0 When you shut somethin= g
like that down, you might not care if frame 63412 made it through or
not.=C2=A0 You could just say "I'm going away" and that's= it.

The stream identifiers in GOAWAY are only needed in protocols that a)
care about retries and b) aren't consistently idempotent.

--001a1147f0789548b3054a10010e-- From nobody Mon Mar 6 12:34:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C21299DC for ; Mon, 6 Mar 2017 12:34:13 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 G8nJJj8p7WNv for ; Mon, 6 Mar 2017 12:34:12 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C841299F7 for ; Mon, 6 Mar 2017 12:34:12 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id o4so69133770ywd.3 for ; Mon, 06 Mar 2017 12:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hp6X2NDtKTcF6e6bJ5I7UhdwNjbqEXrCk39cY1gOChc=; b=BevvAtMFqMh2/tt8azbQC7qv32GKagS0dhjeqNFrpPl55zncCR0girrIbwsdiZxynR 3iHz5Epm7/elJuzOUIJiW1bXVlG4hlLPs5iHVavktidz+o/7D6ltbBip8BnGPGA1JHHn boASS2cfMEsFLtFOBeiUvZcR9zsJL3KW6B4crhYZeYAH6u1HtylqjAYALy8vDr3LvmCR xNh8848EfYCAFXyjL1GcNQKUexhomyLtOuPSry7v9m7IET5qmgVS6Do3/VMfR9Bm8lvt rJ2clE2lad7AEKMDNUqVGp3zIJ05PPhfeFZ1XzokNrlg0HwqkNcEIvMD9fyA7ryUAbA6 6fBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hp6X2NDtKTcF6e6bJ5I7UhdwNjbqEXrCk39cY1gOChc=; b=gtbGjS5B2nbr8xHnNGA//Uv2fiAjh7tzuLbjWr6eakhNQOrtK16Seq6QuRIK7N3o+x HgvpoJ/AJk9cu8Vo9xXgqhh5XuWlkKa9c82sV4rFyjFmGY33B04AXOYEKIxiHIiySyBs D4KBUUe6QxJfaTH3xlQpUFzXypvQdbNq05wLybbC9Q9/3ZtpCpDW15vI967FiTNDCtG4 orKgIr70ARPWVxUI+3gPgdxEVqN3Zi88wenBdM0V26uskTM7UZHHBY7yQTQjimHlEs86 wdiQRS/7nkL4QZsNQLRkyP9PuwUz1yxTsE5eC/CsGPoWh3RG+zBE8aeAJpjR8e1WBlSF 2LKA== X-Gm-Message-State: AMke39kzV/TwDTdME+LJt1mqCl5w2PAfJeq44daJeRZtWaDKEShvpphM1V8PuQMOF8tqvAtsy7y2rYjMIxYt9PEK X-Received: by 10.13.252.4 with SMTP id m4mr12233776ywf.232.1488832451158; Mon, 06 Mar 2017 12:34:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Mon, 6 Mar 2017 12:33:50 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Mon, 6 Mar 2017 15:33:50 -0500 Message-ID: Subject: Re: sending an retransmitting packets in draft-ietf-quic-recovery To: Martin Duke Content-Type: multipart/alternative; boundary=94eb2c064a50623c87054a15d11a Archived-At: Cc: marcelo bagnulo braun , draft-ietf-quic-recovery@ietf.org, "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 20:34:13 -0000 --94eb2c064a50623c87054a15d11a Content-Type: text/plain; charset=UTF-8 Yes, that's a mistake, if receiving an ack causes packets to be considered lost, then you would try to retransmit them immediately. I just fixed that in Github. I'm not sure how much to go into what one should transmit in the recovery doc, but I will at least try to add some detail about when it's recommended to retransmit vs send new data, in line with the recommendations in the core transport doc. Martin: acked_packet is intended to be the largest acked packet, but currently that's ambiguous. RTO packets aren't actually considered lost until a larger packet is acknowledged in QUIC. If done correctly, this is equivalent to TCP with F-RTO, but instead of undoing the CWND reduction, you just wait until knowing if it was a real RTO before enacting the CWND reduction. That is a case where the recovery interacts fairly directly with the congestion controller, and as such, needs to be properly documented. On Thu, Mar 2, 2017 at 7:32 PM, Martin Duke wrote: > Some additional issues with this draft: > > - What is (acked_packet) when the alarm fires? > > - I'm not sure how DetectLostPackets supports RTOs. If we only iterate > until reaching the largest acked packet, then we'll never check packets > beyond that for loss. > > On Mon, Feb 20, 2017 at 1:18 AM, marcelo bagnulo braun > wrote: > >> Hi, >> >> I am going though the loss detection algorithm described in section 3 of >> draft-ietf-quic-recovery-01 and I have a question. >> >> I see that the MaybeRetransmitLostPackets() function is only called on >> Alarm firing. In particular, the >> MaybeRetransmitLostPackets() is not called when receiving in ack. >> >> Is that a mistake? >> >> I find strange that upon reception of an ACK, that determines that some >> packets are lost, the retransmission function is called right away but a >> timer is set and retransmission is triggered RTT/4 time later. >> >> Also, I guess upon ack reception, if no loss is detected but the windows >> moves, new data should be transmitted and while i understand that the loss >> detection algorithm may not be the right place to define the rules for >> transmitting new packets, it may be worth mentioning it. >> >> Regards, marcelo >> >> > --94eb2c064a50623c87054a15d11a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, that's a mistake, if receiving an ack causes pack= ets to be considered lost, then you would try to retransmit them immediatel= y.=C2=A0 I just fixed that in Github.

I'm not sure h= ow much to go into what one should transmit in the recovery doc, but I will= at least try to add some detail about when it's recommended to retrans= mit vs send new data, in line with the recommendations in the core transpor= t doc.

Martin:
acked_packet is intended = to be the largest acked packet, but currently that's ambiguous.

RTO packets aren't actually considered lost unti= l a larger packet is acknowledged in QUIC.=C2=A0 If done correctly, this is= equivalent to TCP with F-RTO, but instead of undoing the CWND reduction, y= ou just wait until knowing if it was a real RTO before enacting the CWND re= duction.=C2=A0 That is a case where the recovery interacts fairly directly = with the congestion controller, and as such, needs to be properly documente= d.

On Thu, Mar 2, 2017 at 7:32 PM, Martin Duke <martin.h.duke@gmail.= com> wrote:
Some additional issues with this draft:

- What is (ack= ed_packet) when the alarm fires?

- I'm not sur= e how DetectLostPackets supports RTOs. If we only iterate until reaching th= e largest acked packet, then we'll never check packets beyond that for = loss.

On Mon, Feb 20, 2017 at 1:18 AM, ma= rcelo bagnulo braun <marcelo@it.uc3m.es> wrote:
Hi,

I am going though the loss detection algorithm described in section 3 of dr= aft-ietf-quic-recovery-01 and I have a question.

I see that the MaybeRetransmitLostPackets() function is only called on Alar= m firing. In particular, the
MaybeRetransmitLostPackets() is not called when receiving in ack.

Is that a mistake?

I find strange that upon reception of an ACK, that determines that some pac= kets are lost, the retransmission function is called right away but a timer= is set and retransmission is triggered RTT/4 time later.

Also, I guess upon ack reception, if no loss is detected but the windows mo= ves, new data should be transmitted and while i understand that the loss de= tection algorithm may not be the right place to define the rules for transm= itting new packets, it may be worth mentioning it.

Regards, marcelo



--94eb2c064a50623c87054a15d11a-- From nobody Mon Mar 6 13:11:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63771294C3; Mon, 6 Mar 2017 13:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txfHCPqe0dt1; Mon, 6 Mar 2017 13:11:19 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7423A1294F1; Mon, 6 Mar 2017 13:11:19 -0800 (PST) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 41593278F56; Tue, 7 Mar 2017 06:11:17 +0900 (JST) Received: by mail-oi0-f52.google.com with SMTP id m124so92290493oig.1; Mon, 06 Mar 2017 13:11:17 -0800 (PST) X-Gm-Message-State: AMke39nGJaZY87EXe0mGuldq0wxnOzFFEyfkvF1irMx+VtM4Rc65Fd16CHwaJZVRvmvVE2c5F1u5aLRPtMC+Zw== X-Received: by 10.202.186.7 with SMTP id k7mr8019558oif.206.1488834675913; Mon, 06 Mar 2017 13:11:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.82.27 with HTTP; Mon, 6 Mar 2017 13:11:15 -0800 (PST) In-Reply-To: References: From: Yoshifumi Nishida Date: Mon, 6 Mar 2017 13:11:15 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: sending an retransmitting packets in draft-ietf-quic-recovery To: Ian Swett Content-Type: multipart/alternative; boundary=001a113cd384fcbdbf054a1655bd Archived-At: Cc: marcelo bagnulo braun , draft-ietf-quic-recovery@ietf.org, "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 21:11:21 -0000 --001a113cd384fcbdbf054a1655bd Content-Type: text/plain; charset=UTF-8 Hi Ian, On Mon, Mar 6, 2017 at 12:33 PM, Ian Swett wrote: > Yes, that's a mistake, if receiving an ack causes packets to be considered > lost, then you would try to retransmit them immediately. I just fixed that > in Github. > > I'm not sure how much to go into what one should transmit in the recovery > doc, but I will at least try to add some detail about when it's recommended > to retransmit vs send new data, in line with the recommendations in the > core transport doc. > > Martin: > acked_packet is intended to be the largest acked packet, but currently > that's ambiguous. > > RTO packets aren't actually considered lost until a larger packet is > acknowledged in QUIC. If done correctly, this is equivalent to TCP with > F-RTO, but instead of undoing the CWND reduction, you just wait until > knowing if it was a real RTO before enacting the CWND reduction. That is a > case where the recovery interacts fairly directly with the congestion > controller, and as such, needs to be properly documented. > Hmm.. Let's say we've sent packet 1 and acked. Then, I think the largest acked packet will be 1. Now, we sent packet 2,3,4,5, but all are lost, so no ACK has been received. Since DetectLostPackets() always checks unacked packets which are less than acked_packet, as far as I think these packets won't be checked in the function. -- Yoshi --001a113cd384fcbdbf054a1655bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ian,

On Mon, Mar 6, 2017 at 12:33 PM, Ian Swett <= ;ianswett@google.c= om> wrote:
Yes, that's a mistake, if receiving an ack causes p= ackets to be considered lost, then you would try to retransmit them immedia= tely.=C2=A0 I just fixed that in Github.

I'm not sur= e how much to go into what one should transmit in the recovery doc, but I w= ill at least try to add some detail about when it's recommended to retr= ansmit vs send new data, in line with the recommendations in the core trans= port doc.

Martin:
acked_packet is intend= ed to be the largest acked packet, but currently that's ambiguous.

RTO packets aren't actually considered lost u= ntil a larger packet is acknowledged in QUIC.=C2=A0 If done correctly, this= is equivalent to TCP with F-RTO, but instead of undoing the CWND reduction= , you just wait until knowing if it was a real RTO before enacting the CWND= reduction.=C2=A0 That is a case where the recovery interacts fairly direct= ly with the congestion controller, and as such, needs to be properly docume= nted.

Hmm.. Let's say we've sent packet 1 and acked.=C2=A0 Then, = I think the largest acked packet will be 1.
Now, we sent packet 2,3,4,5, but all are lost, so no ACK has been rec= eived.
Since=C2=A0DetectLostPackets() always checks unacked = packets which are less than acked_packet, as far as I think these packets w= on't be checked in the function.=C2=A0
--
Yoshi=C2= =A0
--001a113cd384fcbdbf054a1655bd-- From nobody Mon Mar 6 14:45:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914431294EB for ; Mon, 6 Mar 2017 14:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHbBYGxAzBA6 for ; Mon, 6 Mar 2017 14:44:58 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9C0129489 for ; Mon, 6 Mar 2017 14:44:58 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id p64so61279987qke.1 for ; Mon, 06 Mar 2017 14:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3vXiQ4hLDvhcmjqJZCkTSSLvbmnHgtOA7GxxdVtk2hU=; b=QYxC9jZvotqo3SOMvQNg15SlwSMj8rqnMHFxUW1u5+oXYzc/GHqV57zBRCTBN47lqn KCxAhy8eqAG83eiGasgUHKInY8LRFBwUNC0a03viAH7jCURFaHRkYg9VkN2MLnk7Y28Y 7/5Zmt8w6inhqt3p9FD5gjtQwdHmZuY+1ASmnnvnVHPtSZGXAZaHQ4Um9erbxP6mi7dw FJC/HRgdru+qrMVX8UajdkpfAvDXJetN61D72k++zbt7p9Ic8xU2kK07RxGrrpYr9GBZ xCAR7MXCDOuJ7D+W5T1Cud0I8dYaDXkkveFd5W1EI0G+cBSfwSAUTRQ1cN2XVEKTZzey dPZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3vXiQ4hLDvhcmjqJZCkTSSLvbmnHgtOA7GxxdVtk2hU=; b=cWoua1Uxl2WQ0oQ4khnYuw4j8m0tW/GCF4Mz9nuTKT/SrvtAX7PSCSlYAjv4S7GL8R V0G9VeKOVw3JFPkXe5z8e/lc70FbA2GGAsGJlac857e1cosoAs71RagA0Z+PO1GX3mYK 2KOiepWDEvRmM0Tw0O/LhvON+TL1iNj26/UkRWGwWzr+5e7mlHMiCA/CEcf/ZPFJL5x7 JSBExe+jsqWJ4cLPHCRNIXIP9zDOvUW46BuKwcUv4fA2EOmk7gGPvDnEPK3JFhuSMpxk JJz60RtxJpiA7Ro7JA0bSIfj3HrtkNBEqf3wOy/oeTFWEP44l3HQ+BZBzzbBOCAmO7Vv XBfg== X-Gm-Message-State: AMke39nt3GoN/FfDrcCaZgfXL851srQfKvdSNwqIhtB6pi+l9ugpL6mnSvPGRXSuoHHxF++pCv04IpL+OqKuVw== X-Received: by 10.55.17.138 with SMTP id 10mr19476210qkr.202.1488840297576; Mon, 06 Mar 2017 14:44:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 14:44:57 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 7 Mar 2017 09:44:57 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG , Lucas Clemente , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:44:59 -0000 On 7 March 2017 at 00:37, Ian Swett wrote: > Not having a way to close the connection gracefully seems like a missing > feature, but I'm not hung up on having it if it's really not generally > useful. We made a similar decision with priority. Multiplexing without priority is - at best - lame. But we now require that the application protocol manage priority and any signaling that might be needed. The same decision could be made for graceful shutdown, and based on this discussion, I'm inclined to think that it's the right decision. From nobody Mon Mar 6 15:06:47 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2B4129A5B for ; Mon, 6 Mar 2017 15:06:46 -0800 (PST) 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 GNA7Du_x3n2f for ; Mon, 6 Mar 2017 15:06:45 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 D76C012896F for ; Mon, 6 Mar 2017 15:06:44 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id o24so59411165otb.1 for ; Mon, 06 Mar 2017 15:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SjA5gfqOiTCNUmUWPyrCRiFSeC/46AqNGHTAZUxknkY=; b=LY00LLH0+BASug3V2COWlo2CU9K42TDYWOujXjYOwaSpxpa0IKR77DNY+P0Em+vgvO Iu8y/27GmfvahmkjPZiDmo1qKXEMAgDnpzEwz2vFvlqQI/RifiyCUaIqFb0Gf0pB5Cj7 PJkYyFgS9fq6xkV386JpDZI9bOmlIJhUz+4nitbtnZmCDsxvKWLQDaXk0GeZxWbzoJd2 i/+WQqSoXDco8dVo23M4UTpXSOFufLlTX3xUgp/oi3E4pJrXOmJAirFmdej/gHpdx/Ue KxIL2v5UTK1KUolrVN2cFHD4UoavbZV/Im18IXtR35JEFLB72BOlKtZMwwFMA1yfty7r 8OqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SjA5gfqOiTCNUmUWPyrCRiFSeC/46AqNGHTAZUxknkY=; b=fleD5WjkRG7sPhoX2uNm4fccfEAp/emwn73XVlaTVGBBGHtf4kWell9sYTqMSqAwGI sL1fVRHy4Ywd06nj7gehpvEgB+zdzpvxIqpYh23PzwM5BEGa4w72Uyu1RS8humUQDyzF uYT6wUsXCYedobXaXONBMcjM9I5f7PLHWCziCyo6QBCB2j3KqVCiuLXkNB+qDe/Q0BtE BRjvLftrGtcdGUjs3lFOOZcZwTpxJ4uye7/BtfUfKcEcKW19UgzjJvVBDcAOvuyOfm6Z V/oMxQGipv5uMQ0F1VfDeAt+lQJt69NgYNmUBz/sKyeBoAtg+SyjX5x+jYzXzUUpIFtm Ygeg== X-Gm-Message-State: AMke39ljLdfIuuyhbHNScz3ab1LAiW97aRqSC3zfieSkPvFN26MBdY9xkshHfuYvaKGSibqNgyktsodJtMgIwA== X-Received: by 10.157.13.230 with SMTP id 93mr10679558ots.13.1488841604229; Mon, 06 Mar 2017 15:06:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Mon, 6 Mar 2017 15:06:43 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Mon, 6 Mar 2017 15:06:43 -0800 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c116b8af2770a054a17f289 Archived-At: Cc: Ian Swett , IETF QUIC WG , Lucas Clemente X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 23:06:46 -0000 --94eb2c116b8af2770a054a17f289 Content-Type: text/plain; charset=UTF-8 So I think the GOAWAY-less QUIC clean-shutdown protocol behavior is as follows, trying to imitate TCP semantics where possible: Application sends close() QUIC stops initiating streams Finish delivering all outstanding streams, send a FIN bit, and close the stream the FIN is acked. Wait patiently for all the peer's stream FINs and ack them. * *QUIC makes the assumption that the peer will open no more streams* * If the acknowledgment of the peer's last FINs was not itself acked because it had data with it, then start a TIME-WAIT timer. If not, or when the TIME-WAIT timer expires, silently delete all state (or, if we want to signal middleboxes, send a PUBLIC_RESET). I think I'm alright with that, particularly if we send that Reset. We wouldn't have to assume that the peer will open no more streams if we were to repurpose GOAWAY to mean "I'm not starting any more streams", which in my view would be a bit cleaner. On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson wrote: > On 7 March 2017 at 00:37, Ian Swett wrote: > > Not having a way to close the connection gracefully seems like a missing > > feature, but I'm not hung up on having it if it's really not generally > > useful. > > We made a similar decision with priority. Multiplexing without > priority is - at best - lame. But we now require that the application > protocol manage priority and any signaling that might be needed. The > same decision could be made for graceful shutdown, and based on this > discussion, I'm inclined to think that it's the right decision. > --94eb2c116b8af2770a054a17f289 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So I think the GOAWAY-less QUIC clean-shutdown protocol be= havior is as follows, trying to imitate TCP semantics where possible:
<= br>
Application sends close()
QUIC stops initiating str= eams
Finish delivering all outstanding streams, send a FIN bit, a= nd close the stream the FIN is acked.
Wait patiently for all the = peer's stream FINs and ack them.
* QUIC makes the assumpti= on that the peer will open no more streams *
If the acknowled= gment of the peer's last FINs was not itself acked because it had data = with it, then start a TIME-WAIT timer.
If not, or when the TIME-W= AIT timer expires, silently delete all state (or, if we want to signal midd= leboxes, send a PUBLIC_RESET).

I think I'm alr= ight with that, particularly if we send that Reset.

We wouldn't have to assume that the peer will open no more streams if= we were to repurpose GOAWAY to mean "I'm not starting any more st= reams", which in my view would be a bit cleaner.

On Mon, Mar 6, 2017 at 2:44= PM, Martin Thomson <martin.thomson@gmail.com> wrote:=
On 7 March 2017 at 00:3= 7, Ian Swett <ianswett@google.com= > wrote:
> Not having a way to close the connection gracefully seems like a missi= ng
> feature, but I'm not hung up on having it if it's really not g= enerally
> useful.

We made a similar decision with priority.=C2=A0 Multiplexing without=
priority is - at best - lame.=C2=A0 But we now require that the application=
protocol manage priority and any signaling that might be needed.=C2=A0 The<= br> same decision could be made for graceful shutdown, and based on this
discussion, I'm inclined to think that it's the right decision.

--94eb2c116b8af2770a054a17f289-- From nobody Mon Mar 6 15:30:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23245129505 for ; Mon, 6 Mar 2017 15:30:15 -0800 (PST) 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 SLGNJ2vvryyX for ; Mon, 6 Mar 2017 15:30:13 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811061294ED for ; Mon, 6 Mar 2017 15:30:13 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id i1so124496495ota.3 for ; Mon, 06 Mar 2017 15:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ieCn0R1CqT1z9/LEeQW+Ye8gk/fAQQUZ2F2/AGbyPpw=; b=jpbvU5oc/2O1fntCR5ajilhwhOaFqUifLZsLEUHEDCZdGDq7BVj02QnXrDf67iT1mD 5j/FBL3lehN0B+JX5++doF6xg1gtwouk2iFpr5li1jHGqzb73mDAkjynVEraAe745Rf8 52OPHxVk6a70nIcjCGOaHXGHXZoCkOBaokjwa1TsBBPCAbTS6F7mRo6Gi2gQ/KyQEJgo qkPciGZxg4ZvazykNb8zD0ATVIPBLuyDJaaVJ+rc1eSt2VMuBVxSZJy2YT5cJK51RIPh /kU9b/FigZ/DTfWMZXPl4zjp3EuMwrdr0soQO54Li+Ekz62kiMtFFlC6g/s5HxsPmTAP W51w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ieCn0R1CqT1z9/LEeQW+Ye8gk/fAQQUZ2F2/AGbyPpw=; b=sl+mafyCoYbuxAtwbrG+kgZ2a+TOcIiei/+jgWhii3LGfHyLV7NZ7dj7MmuGpDM++X AJPK3gz2xvXX8aVfH9DNBGWueTrSXtoCL4b0QZ+cvbO0VxzfQrHZ3PQS/hp3jalOSB6q 6l5qtB+h7oTuhp+CXpOStKQ2lCUAqe+it0XkNvUv5D5IoCRerwEDwRJgTIZIOdibb6U4 nP5HPXOHoQ6hWkR/26Tz8nKaoC4OTQ0EJwirh/vhr8sLTEmD1P2+cp1nfRw/d4cIxCTy fOCP9GnpHMBK1f3ApIsWfnruZWEtxbrnk3xOEC9AbtJp7mp5cokUU9R9FJtYbvM/8gSC I7JQ== X-Gm-Message-State: AMke39nAJA/cItx70xK8/f2cm2UvuRr6LWRpDewX/ONT8Kl8PiYo6dPPQV9ZS+uoppLUJhU6X7DO12EiTSXrug== X-Received: by 10.157.21.82 with SMTP id z18mr11118532otz.29.1488843012533; Mon, 06 Mar 2017 15:30:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.42.10 with HTTP; Mon, 6 Mar 2017 15:29:42 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Mon, 6 Mar 2017 15:29:42 -0800 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Duke Content-Type: multipart/alternative; boundary=94eb2c1917a2e37525054a184655 Archived-At: Cc: Lucas Clemente , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 23:30:15 -0000 --94eb2c1917a2e37525054a184655 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke wrote: > So I think the GOAWAY-less QUIC clean-shutdown protocol behavior is as > follows, trying to imitate TCP semantics where possible: > > Application sends close() > QUIC stops initiating streams > Finish delivering all outstanding streams, send a FIN bit, and close the > stream the FIN is acked. > So, this seems subtly limiting. If QUIC stops initiating streams, it could notify the other endpoint that it had entered shutdown and then let the other side complete the shutdown at any point from then on. For some applications, the emitter initiating shutdown may mean that the receiver is also done; for others, the reliability of stream delivery required may be variable depending on the application semantics and the availability of FEC. How about Application sends close QUIC stops initiating streams, send FIN_START QUIC delivers outstanding streams until receiving FIN_COMPLETE If all streams delivered and no FIN_COMPLETE, start timer. I believe that lets you get the same semantics in the set above, by simply delivering the FIN_COMPLETE when all outstanding streams are delivered, but it may open up other semantics as well. regards, Ted > Wait patiently for all the peer's stream FINs and ack them. > * *QUIC makes the assumption that the peer will open no more streams* * > If the acknowledgment of the peer's last FINs was not itself acked because > it had data with it, then start a TIME-WAIT timer. > If not, or when the TIME-WAIT timer expires, silently delete all state > (or, if we want to signal middleboxes, send a PUBLIC_RESET). > > I think I'm alright with that, particularly if we send that Reset. > > We wouldn't have to assume that the peer will open no more streams if we > were to repurpose GOAWAY to mean "I'm not starting any more streams", which > in my view would be a bit cleaner. > > On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson > wrote: > >> On 7 March 2017 at 00:37, Ian Swett wrote: >> > Not having a way to close the connection gracefully seems like a missing >> > feature, but I'm not hung up on having it if it's really not generally >> > useful. >> >> We made a similar decision with priority. Multiplexing without >> priority is - at best - lame. But we now require that the application >> protocol manage priority and any signaling that might be needed. The >> same decision could be made for graceful shutdown, and based on this >> discussion, I'm inclined to think that it's the right decision. >> > > --94eb2c1917a2e37525054a184655 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke <martin= .h.duke@gmail.com> wrote:
So I = think the GOAWAY-less QUIC clean-shutdown protocol behavior is as follows, = trying to imitate TCP semantics where possible:

Applicat= ion sends close()
QUIC stops initiating streams
Finish = delivering all outstanding streams, send a FIN bit, and close the stream th= e FIN is acked.

So, this seems = subtly limiting.=C2=A0 If QUIC stops initiating streams, it could notify th= e other endpoint that it had entered shutdown and then let the other side c= omplete the shutdown at any point from then on.=C2=A0 For some applications= , the emitter initiating shutdown may mean that the receiver is also done; = for others, the reliability of stream delivery required may be variable dep= ending on the application semantics and the availability of FEC.

How about

Application sends close
Q= UIC stops initiating streams, send FIN_START
QUIC delivers ou= tstanding streams until receiving FIN_COMPLETE
If all streams= delivered and no FIN_COMPLETE, start timer.

I= believe that lets you get the same semantics in the set above, by simply d= elivering the FIN_COMPLETE when all outstanding streams are delivered, but = it may open up other semantics as well.

regards,

<= /div>
Ted
=C2=A0
Wait patiently for all the peer's stream FINs and ack= them.
* QUIC makes the assumption that the peer will open no = more streams *
If the acknowledgment of the peer's last F= INs was not itself acked because it had data with it, then start a TIME-WAI= T timer.
If not, or when the TIME-WAIT timer expires, silently de= lete all state (or, if we want to signal middleboxes, send a PUBLIC_RESET).=

I think I'm alright with that, particularly i= f we send that Reset.

We wouldn't have to assu= me that the peer will open no more streams if we were to repurpose GOAWAY t= o mean "I'm not starting any more streams", which in my view = would be a bit cleaner.
=

On Mon, Mar 6, 20= 17 at 2:44 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 7 March 2017 at 00:37= , Ian Swett <ia= nswett@google.com> wrote:
> Not having a way to close the connection gracefully seems like a missi= ng
> feature, but I'm not hung up on having it if it's really not g= enerally
> useful.

We made a similar decision with priority.=C2=A0 Multiplexing without=
priority is - at best - lame.=C2=A0 But we now require that the application=
protocol manage priority and any signaling that might be needed.=C2=A0 The<= br> same decision could be made for graceful shutdown, and based on this
discussion, I'm inclined to think that it's the right decision.


--94eb2c1917a2e37525054a184655-- From nobody Mon Mar 6 15:40:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9852E129545 for ; Mon, 6 Mar 2017 15:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUMpPynRBv7q for ; Mon, 6 Mar 2017 15:40:16 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B76C1294ED for ; Mon, 6 Mar 2017 15:40:16 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id y76so50498772qkb.0 for ; Mon, 06 Mar 2017 15:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hvFiOXTrANOVkB7NQmTu8o/YeJpVqvsDqup1EclGwYs=; b=GUwa2Kn3SLSJbn9yzDVLaffu2w9GDPh2+N4Uopj/Uzr+pWmJJ0okO+V+PKk3eJeeBY rI+co/+WJsJvPpmi8C/EnTYWRP+wy4R+7LevHGopLIDV9QQQhjtO3GnD+ZB840OeeQAa N8k8e+MIOleU/79ryXE9UgkZxJFrRdosznqhZrCw4swUWUihQ15iaEv7qOeosCrlxxhe hkmcT5oJgy1iZGGxFriObQI93kgM7AYAal2sdUlTLhKREea7zkDVXdC0o/0u7S8mNN0L eNO4Brjo0lzZfbVvRraf0gvfMVNvWIfXKripbyijeB9Oj9OY/YZnOzEfPWuivYHhu41y BStA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hvFiOXTrANOVkB7NQmTu8o/YeJpVqvsDqup1EclGwYs=; b=MFGnKcIxQ+n7Y20OYNLSNwmm1YoMiS/qP2kYik0o14CPo9rsS0XD32APXykMJSg+cK q2snz/wntX8XKf/luwfIsxgIdDguqVpcWd8dOqrMDcs0z00/Ocaiihan069OIEnoIfFR DzgKe5YV5xTvw7fzxVoVJa2/d12JnriTz5YRjZDyybLMpMNmiD8AwOxFPEcEL8C+rqL/ CGpTUVgsO/7zYguzh4ovr9hnENn5Qq0OR/Xv3L6AHxAtmh1f30mB6ticgCFnTMnx3GAG kujjYuYLN7bqB9SKhYfMisCd/4r8nzEGQIBoD0nUADP9gL8+DHsaSXYkEtlEKu4zn+C2 d1lw== X-Gm-Message-State: AMke39kIejqIENRBbTOkBbuAKofrm4zXH2OU1b/HecBvtc/Fjqv+bfhpFxLAD1MO6+uE9Eu0h4XHVMQwvVJEHg== X-Received: by 10.233.216.68 with SMTP id u65mr17330643qkf.68.1488843615284; Mon, 06 Mar 2017 15:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 15:40:14 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 7 Mar 2017 10:40:14 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ian Swett , IETF QUIC WG , Lucas Clemente , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 23:40:17 -0000 I think that both are likely to run afoul of a simple problem in HTTP: the control stream (stream 3) can't be closed. The graceful shutdown I was imagining was, specifically for HTTP. 1. HTTP application calls shutdown() locally (assuming that close() is immediate) 2. HTTP layer signals intent to close (including last stream identifiers) 3. HTTP layer stops opening new streams 4. HTTP layer waits for all open requests and pushes to complete or error out (which means waiting for RST_STREAM or FIN in both directions AND waiting for an ACK for any RST_STREAM or FIN that it initiated itself) X. The peer HTTP layer receives intent to close and does the same 5. HTTP layer (on either end) calls close() 6. QUIC layer sends CONNECTION_CLOSE and terminates the connection That doesn't rely on any QUIC-layer signaling. Also, stream 3 never closes. It doesn't have to. Its contents are critical, but only as long as there are requests/responses/pushes in flight. On 7 March 2017 at 10:29, Ted Hardie wrote: > On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke wrote: >> >> So I think the GOAWAY-less QUIC clean-shutdown protocol behavior is as >> follows, trying to imitate TCP semantics where possible: >> >> Application sends close() >> QUIC stops initiating streams >> Finish delivering all outstanding streams, send a FIN bit, and close the >> stream the FIN is acked. > > > So, this seems subtly limiting. If QUIC stops initiating streams, it could > notify the other endpoint that it had entered shutdown and then let the > other side complete the shutdown at any point from then on. For some > applications, the emitter initiating shutdown may mean that the receiver is > also done; for others, the reliability of stream delivery required may be > variable depending on the application semantics and the availability of FEC. > > How about > > Application sends close > QUIC stops initiating streams, send FIN_START > QUIC delivers outstanding streams until receiving FIN_COMPLETE > If all streams delivered and no FIN_COMPLETE, start timer. > > I believe that lets you get the same semantics in the set above, by simply > delivering the FIN_COMPLETE when all outstanding streams are delivered, but > it may open up other semantics as well. > > regards, > > Ted > >> >> Wait patiently for all the peer's stream FINs and ack them. >> * QUIC makes the assumption that the peer will open no more streams * >> If the acknowledgment of the peer's last FINs was not itself acked because >> it had data with it, then start a TIME-WAIT timer. >> If not, or when the TIME-WAIT timer expires, silently delete all state >> (or, if we want to signal middleboxes, send a PUBLIC_RESET). >> >> I think I'm alright with that, particularly if we send that Reset. >> >> We wouldn't have to assume that the peer will open no more streams if we >> were to repurpose GOAWAY to mean "I'm not starting any more streams", which >> in my view would be a bit cleaner. >> >> On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson >> wrote: >>> >>> On 7 March 2017 at 00:37, Ian Swett wrote: >>> > Not having a way to close the connection gracefully seems like a >>> > missing >>> > feature, but I'm not hung up on having it if it's really not generally >>> > useful. >>> >>> We made a similar decision with priority. Multiplexing without >>> priority is - at best - lame. But we now require that the application >>> protocol manage priority and any signaling that might be needed. The >>> same decision could be made for graceful shutdown, and based on this >>> discussion, I'm inclined to think that it's the right decision. >> >> > From nobody Mon Mar 6 16:53:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2E129ACB for ; Mon, 6 Mar 2017 16:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 gY7dhY04dP-J for ; Mon, 6 Mar 2017 16:53:55 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 547DF129AD2 for ; Mon, 6 Mar 2017 16:52:15 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6F9B822E1F3 for ; Mon, 6 Mar 2017 19:52:08 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Adjustments to the issue resolution documentation Message-Id: Date: Tue, 7 Mar 2017 11:52:05 +1100 To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 00:53:58 -0000 Hi everyone, Based on our experience so far in running the process, and after = discussion with Lars and the Editors, I've made a few changes to the = documentation in CONTRIBUTING.md regarding how issues are resolved. See: = https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolvin= g-issues In particular, we now have an explicit `has-consensus` label to reflect = those issues where we've declared WG consensus. `Closed` issues are merely those that have a proposal reflected in the = document that we *believe* reflects consensus, but that hasn't been = confirmed yet. Does that make sense to everyone? Hopefully this will reflect the = process more clearly, and be easier to understand. If this causes = concern or if you have other suggestions, please bring it up. Cheers, P.S. Keen observers will note that we only have declared consensus on = one issue -- hopefully that number will increase once we get a new set = of drafts out and reviewed. -- Mark Nottingham https://www.mnot.net/ From nobody Mon Mar 6 17:08:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FF91298A0 for ; Mon, 6 Mar 2017 17:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 U6vXhs2rBhl5 for ; Mon, 6 Mar 2017 17:08:38 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 1C3B2129644 for ; Mon, 6 Mar 2017 17:08:38 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id u48so128678963wrc.0 for ; Mon, 06 Mar 2017 17:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3fdBVJ8REBQlWBfkvdkn/B9ApbL4MmRj/uidYCMu+vI=; b=QSXsHnZwp6czX7YhqgjfHjQD2nBeEJWht3EowzOO2vXsOP0sUcek+xW4U4xXbNgULd he+S4z5ax9VwnN/XInb/nvu40OfwUdbgthlX5sXT4FGBME/1TJMZpK7Oxp9FkbjdMfHh M5JbUN9yUVlezqiMOvNaRX260C+jTLDQu39zlKe0Q+16V6MSkbKbLk8qhxWdhJnUxgwu hFPbWy801PpjHeT2rTInWOQ1fnaWSaJmC2qkMvWo9VsF5R5Henr7UHx2YaobIdop6z8C hTkp7s8AmzK1WX7kXWD/VxUfMhVcOFSVt4LpBF4pjgcM8iO9YL6c5D4sjaaIJrgN2nxq DnmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3fdBVJ8REBQlWBfkvdkn/B9ApbL4MmRj/uidYCMu+vI=; b=JAL+SPuAFKHpiEKSfWIac6K9GlIhvNmykGPYzxnAuDduKdSkClyAF03V1HyE4yy8V9 9cTh1yN66Z0H4AVDi0or3BUkNV8hRBU+YFVTT+n6+eykU7KvuNNyvA5qgV/umIxrUy80 nsIFKxnPCFvyEyyqNcb2z+0Efbo1V0KHjQSvYCOuDTw4mdG/+3/13sjEuoADjXdwA2dp ltqhnT0DbGBjAqqSG/QP+wQ5uNM9kszoo2rd3swffXFWuuB+XyXJW1mdlNreZgitCI2x fhJiEBiE1XpUyJTSQby7XzUCPkVB75AbgZ453wjXpvV3lOgurGz9JKk3caMXNHNDlrIj gqaA== X-Gm-Message-State: AMke39lnTtqwTMY4+BD5ONqTlSy2rmAtY65qWomufOJhCxmzB3hc8bKDUc3S1k3grmXpPfqzw9mDrI9v0LXWttGr X-Received: by 10.223.160.243 with SMTP id n48mr18205359wrn.198.1488848916395; Mon, 06 Mar 2017 17:08:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.19.7 with HTTP; Mon, 6 Mar 2017 17:08:35 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Mon, 6 Mar 2017 17:08:35 -0800 Message-ID: Subject: Re: Adjustments to the issue resolution documentation To: Mark Nottingham Content-Type: multipart/alternative; boundary=94eb2c184874c97a14054a19a636 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 01:08:39 -0000 --94eb2c184874c97a14054a19a636 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8B On Mon, Mar 6, 2017 at 4:52 PM, Mark Nottingham wrote: > Hi everyone, > > Based on our experience so far in running the process, and after > discussion with Lars and the Editors, I've made a few changes to the > documentation in CONTRIBUTING.md regarding how issues are resolved. > > See: > https://github.com/quicwg/base-drafts/blob/master/ > CONTRIBUTING.md#resolving-issues > > In particular, we now have an explicit `has-consensus` label to reflect > those issues where we've declared WG consensus. > > `Closed` issues are merely those that have a proposal reflected in the > document that we *believe* reflects consensus, but that hasn't been > confirmed yet. > > Does that make sense to everyone? =E2=80=8BThis makes a lot of sense to me, since it makes it very explicit w= hich issue have consensus and which we believe to have consensus.=E2=80=8B Thank= s for doing this! > Hopefully this will reflect the process more clearly, and be easier to > understand. If this causes concern or if you have other suggestions, plea= se > bring it up. > > Cheers, > > P.S. Keen observers will note that we only have declared consensus on one > issue -- hopefully that number will increase once we get a new set of > drafts out and reviewed. > > -- > Mark Nottingham https://www.mnot.net/ > > --94eb2c184874c97a14054a19a636 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8B


On Mon, Mar 6, 2017 at 4:52= PM, Mark Nottingham <mnot@mnot.net> wrote:
=
Hi everyone,

Based on our experience so far in running the process, and after discussion= with Lars and the Editors, I've made a few changes to the documentatio= n in CONTRIBUTING.md regarding how issues are resolved.

See:
=C2=A0 https://github.com/quicwg/base-drafts/blob/master/CONTRIBUT= ING.md#resolving-issues

In particular, we now have an explicit `has-consensus` label to reflect tho= se issues where we've declared WG consensus.

`Closed` issues are merely those that have a proposal reflected in the docu= ment that we *believe* reflects consensus, but that hasn't been confirm= ed yet.

Does that make sense to everyone?

=E2=80=8BThis makes a lot of sense to me, since it makes it very explici= t which issue have consensus and which we believe to have consensus.=E2=80= =8B Thanks for doing this!
=C2=A0
Hopefully this will reflect the process more clearly, and be ea= sier to understand. If this causes concern or if you have other suggestions= , please bring it up.

Cheers,

P.S. Keen observers will note that we only have declared consensus on one i= ssue -- hopefully that number will increase once we get a new set of drafts= out and reviewed.

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


--94eb2c184874c97a14054a19a636-- From nobody Mon Mar 6 17:16:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BEC12944D for ; Mon, 6 Mar 2017 17:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9oAZu2lYXXjE for ; Mon, 6 Mar 2017 17:16:20 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3856129A75 for ; Mon, 6 Mar 2017 17:16:19 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id 72so191647149uaf.3 for ; Mon, 06 Mar 2017 17:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xK0QbVPdvCGvA8AkhpPfqVEBMK2EVcByLTht5wnvwsI=; b=QOAIQh/iArI6rpL8wX4WhEstItBCcf3mFAFt7M3JerDyvb8P1XDgJRFpDZfU9Ig+6q +5KwiFkTldnNiekjpg/eS5z3COnhahmX6q+bs/f/Y08aaPxjADFIN6MSBPlQSoZmk4P1 fy6adbtEv5/mAfVGyZm2ZV4i41EvXeFNDF8btTRJKH9iCjqWhagGovD3puG7YhEcfIfa dFfND11syV2vxRzVUdiupsmOxrfIvjdl5iF4WT7uaqT+rUHkTltzaJhvr3XcFkg5pROV 2uyoXi954MYKGbHF7HT1TtJ0AjkNb0zb7molNDVOz1tQD08Mkf1x/SycnQDVIAhPQB/H FCpg== 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=xK0QbVPdvCGvA8AkhpPfqVEBMK2EVcByLTht5wnvwsI=; b=CHLGVSMm3idk9ciLxrnkjbm9NL0yQ9+kg8KsVWwvxSahHvqotduuZ5m5haoUPXCnmX LZ/mi79I0/MT4nIVVDjF9wLoSVM/0J5QZVv59/hc/lIleXNanxSIgFCT2Bx/E4rEML1M LvrZI/Bv0Judol18kRirSl24DyGByn2d1VGO6DtO8/kB3d/jmkOEXoIU/YvlceiCdiJd JVW+Te0Rndvf/jdyXLkcCKV4yKv7Diar24WDBsr5knuw6rBTzMwePqWrvQ9nUU8s9iNi +v08+7wpNf/12X5bMj5H33w+nPOKU1m7b9y41Wz1B2SZXD69gaW4cjGJxqm9VYs1y/+F LwxQ== X-Gm-Message-State: AMke39m1KenWgdG81KcNTPSM5XmSU0NSxbpYt8cbm6FPLtzZ1EQwfFrQv75UkJzM9wcfTPeVR6U84gkXTlsLf4fi X-Received: by 10.31.107.212 with SMTP id k81mr6538039vki.116.1488849378604; Mon, 06 Mar 2017 17:16:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Mon, 6 Mar 2017 17:16:18 -0800 (PST) From: Jana Iyengar Date: Mon, 6 Mar 2017 17:16:18 -0800 Message-ID: Subject: Return of the alternate header proposal To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a11478ace56597b054a19c28d Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 01:16:22 -0000 --001a11478ace56597b054a19c28d Content-Type: text/plain; charset=UTF-8 Hi all, Based on the (very constructive) discussion around the previous alternate header proposal , I've crafted PR #361 that incorporates mailing-list feedback. This PR does not attempt to be the final form of the header, but it hopes to be a significant way forward in that direction. This PR closes a large number of issues. I'd like to get this merged into the draft by the draft deadline (a week from now), with the understanding that this format may still change as we discuss issues further. Please read and provide feedback. The PR is a bit invasive and unfortunately large, so I'll summarize a few salient points about it here. - The PR includes a header-form bit that allows easy distinction between long and short headers. It also delineates version-independent fields from version-specific ones. - The PR introduces use of Server-selected Connection ID, and specifies rules for distinguishing it from the client-selected one. In summary, server-selected Connection IDs are used for the final handshake packet (ServerHello) and all subsequent packets. Everything before it uses the client-selected Connection ID, including intermediate server handshake packets (those carrying HelloRetryRequests). - Connection ID in a packet is available to a stateless load balancer: always present in long headers and indicated via a CONNECTION_ID flag in short headers. In all cases, the connection ID field is in the same location. - Public Reset packets are required to include a Proof, but the proof is TBD. Thanks, - jana --001a11478ace56597b054a19c28d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Based on the (very c= onstructive) discussion around the previous alternate header proposal= , I've crafted PR #361=C2=A0that incorporates mailing-list feedback. This PR does n= ot attempt to be the final form of the header, but it hopes to be a signifi= cant way forward in that direction.

This PR closes= a large number of issues. I'd like to get this merged into the draft b= y the draft deadline (a week from now), with the understanding that=C2=A0this format may still change as we discuss i= ssues further. Please read and provide feedback.

The PR is a bit invasive and = unfortunately large, so I'll summarize a few salient points about it he= re.=C2=A0

- The PR includes a header-form bit that= allows easy distinction between long and short headers. It also delineates= version-independent fields from version-specific ones.

- The PR introduces use of Server-selected Connection ID, and specifi= es rules for distinguishing it from the client-selected one. In summary, se= rver-selected Connection IDs are used for the final handshake packet (Serve= rHello) and all subsequent packets. Everything before it uses the client-se= lected Connection ID, including intermediate server handshake packets (thos= e carrying HelloRetryRequests).

- Connection I= D in a packet is available to a stateless load balancer: always present in = long headers and indicated via a CONNECTION_ID flag in short headers. In al= l cases, the connection ID field is in the same location.

- Public Reset packets are required to include a Proof, but the pro= of is TBD.

Thanks,
- jana
--001a11478ace56597b054a19c28d-- From nobody Mon Mar 6 19:22:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39E129AC4 for ; Mon, 6 Mar 2017 19:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 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, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=SL+8sKP9; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=OdDX5ztH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAu1cEe3Q4QE for ; Mon, 6 Mar 2017 19:22:27 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2CE129ABA for ; Mon, 6 Mar 2017 19:22:27 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v273EQ3p029988 for ; Mon, 6 Mar 2017 19:22:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=p7ErGwPOr/A+wKWH/Mq8NM8J9tDipkNjlL2nEBSS7Pg=; b=SL+8sKP9PCkCOx26Rm/INru//0i8+Sj2Na8+ZIofs+GWlax7p3yzh/lvTRU9KAsmBGGa wVkk6gEEOWxNXGm8UwtdmXWOEBVc2mCftObfWFzqIfReVsa+OQBnkoS6cwbG+ccC7n6a 9z22szX+AhCDxxJhMpq8cmFCvqC0vY6J9wU= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 291hrf0md4-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 06 Mar 2017 19:22:27 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Mar 2017 19:22:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p7ErGwPOr/A+wKWH/Mq8NM8J9tDipkNjlL2nEBSS7Pg=; b=OdDX5ztHifO5zuP20I6xSb487zwfLJHP06Lt6K8xWHfPvNofiKdUbPjVQi2GkCx/pvhM1oOW/J1syKM5Kt96nx7nBoD7+BafneaavlEDvEhDQx4dLy+HGM4jW+Fg/olqHjtXtz4fVMn0hTGiomwfuZtIUgV0Wph2+1T+0LN864U= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1454.namprd15.prod.outlook.com (10.173.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 03:22:23 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0947.018; Tue, 7 Mar 2017 03:22:23 +0000 From: Subodh Iyengar To: "quic@ietf.org" Subject: Empty Stream with FIN Thread-Topic: Empty Stream with FIN Thread-Index: AQHSlvBX8BKm39cSRU+92Fou1/ZUKg== Date: Tue, 7 Mar 2017 03:22:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::1ef8] x-ms-office365-filtering-correlation-id: 76cf1f92-b2d7-4fa8-6954-08d465092c2e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1454; x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 7:eXx1AYdy+YBGUuWKULsHqOjNMMV/cpMovZsnCP9QzM+TmbH5pGo3bBE8iV11d6pNlIgEspc3bclrNg9lwEmZEZWeqXBvlL4h+32DimCkB02oj0yhOA0+LsDt3dhzr5VSs9760uzqusdP8OaAXp8syBObbrI19kguhEtzL8G2XXfWd2IDH0VHSLCWmR+Fg8Fsd6nwk2WG2XfGviK5I7sskKh+atPUbonC5n3KaIucMa3Q1sH4SkE7F+/3XWH6bJWlanBFUZ1yutMkooA4t+RN29DpYyGJ5F6UfhCB2Wbka83sWI7weP1P3gJuLHnF80eoE7vYLjgXZNwrnbe4VDuySQ==; 20:m8W3PCQfKr83NvS+6Vo7YJXr7X4Ww5O5W/1SEdQs9zX7ZVjP+VKnWMS8uZc5zmTgI4utLuRlElTF9u1AZ8IJ1htywjsj6i78ruiZQsRWBOBM72cdP4dTkg28WTCz1WES7dzjJPGsR9/HR7+sXLSrVs/I6b6WtePQk1jKYUQOrv0= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1454; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(2906002)(450100001)(99286003)(7736002)(6506006)(19627405001)(53936002)(7696004)(2900100001)(3280700002)(3660700001)(55016002)(92566002)(86362001)(5660300001)(122556002)(6606003)(6916009)(2501003)(110136004)(38730400002)(6436002)(33656002)(7906003)(54356999)(77096006)(74316002)(236005)(50986999)(106116001)(606005)(6306002)(54896002)(9686003)(3480700004)(8936002)(1730700003)(5640700003)(8676002)(81166006)(2351001)(6116002)(102836003)(25786008)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455A551EECE5BE4B3B70859B62F0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 03:22:23.3600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1454 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-07_02:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:22:28 -0000 --_000_MWHPR15MB1455A551EECE5BE4B3B70859B62F0MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It seems strange that for an empty stream frame with a FIN bit, the sender = needs to use the last offset + 1. Is there an existential reason for using = offset + 1 during the FIN with empty stream case? It seems easier to be abl= e to deal with the FIN bit on a stream with data, and a stream without data= uniformly. I also noticed https://github.com/quicwg/base-drafts/issues/240 which propo= ses getting rid of FINs completely. Subodh --_000_MWHPR15MB1455A551EECE5BE4B3B70859B62F0MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It seems strange that for an empty stream frame with a FIN b= it, the sender needs to use the last offset + 1. Is there an existential reason for using offset + 1 during the FIN with e= mpty stream case? It seems easier to be able to deal with the F= IN bit on a stream with data, and a stream without data uniformly.

I also noticed https://github.com/quicwg/base-drafts/issues/240 which propo= ses getting rid of FINs completely. 

Subodh
--_000_MWHPR15MB1455A551EECE5BE4B3B70859B62F0MWHPR15MB1455namp_-- From nobody Mon Mar 6 19:31:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25697129ABA for ; Mon, 6 Mar 2017 19:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 YjpqJ8O5sr2y for ; Mon, 6 Mar 2017 19:31:09 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 8DC20129AC7 for ; Mon, 6 Mar 2017 19:31:09 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id v125so125429577qkh.2 for ; Mon, 06 Mar 2017 19:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f6/8vZZgr1Ov4KS4GkHkP2BqPg/126hWVy0OfLYwgkw=; b=ftLHKCrSDMf1HIophHKxidFJPPsrhJAwTvvuw1XfBKgRdngg991UbCEGTjTciL0lt5 MrsA6xP1z+AAJCKsagUwbybnngcJ/PbIH1GNYpOWgE1PbikKU6FSZwngD50WKDNv6NHm itbk+6Ivv9+2zsF/OKOVQ2ht0AJfjGLwQ4c4bFCP+6qbhWXaSvxs/LCFdgX29GivnU9Y qde0l67nJ2ql7FvamcjnnOR2/jx7ypTwmm5Yn1CX6Kbv9RdYVf1hakBQ/SnrmtNr2OtD YEHN14qcjBiH+3yO/qfXywq5AyyNiGyePFxn7jXQOk4nCGPLDRvzN6A6EfOWBJROEjgz +lQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f6/8vZZgr1Ov4KS4GkHkP2BqPg/126hWVy0OfLYwgkw=; b=JV3IPlC08zEXrzb+ieecpxbiUylAX2LAVux9i2BO0j7teS9nhQQVz1REEWuML8vnN4 nYqKnNSgaEr4vbIhbL6sL6pJmKbVrBr42lTxW+Q54zwoqONzisU09cy1e2sjDHpOTHvZ Br8JI77DkS89NGH/NmDx0ARluS9Hg+VD+s4v/ryjz9KkHhUyqipBnBqW6ecK/9YrxcSB BmuCKdX1mxLMUcn19yzIBlRo/cSDzJWb29/dTZeEYMJAqV22cMBA9whHce15oxroZzyL VBnRE1r2K/9bv6hY2czXLwSi3IEKN02hQiqFv/DxeOa/EOdhqSCynGbocp3U6DTvtzcz 0BBA== X-Gm-Message-State: AMke39mLbwFr1ZFiG+jFrLeuto+5HRIgul8I6wyeyHVZ3AGYyTkuugX6ofZpsDGSEn1krVYk/81BISyhlnTxkw== X-Received: by 10.233.216.68 with SMTP id u65mr17945391qkf.68.1488857468723; Mon, 06 Mar 2017 19:31:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 19:31:08 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 7 Mar 2017 14:31:08 +1100 Message-ID: Subject: Re: Empty Stream with FIN To: Subodh Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:31:11 -0000 On 7 March 2017 at 14:22, Subodh Iyengar wrote: > It seems strange that for an empty stream frame with a FIN bit, the sender > needs to use the last offset + 1. Is there an existential reason for using > offset + 1 during the FIN with empty stream case? It seems easier to be able > to deal with the FIN bit on a stream with data, and a stream without data > uniformly. You always send the offset of the last byte + 1. If you send 1 byte, the offset of that byte is 0. However, if you send a RST_STREAM, then you signal "1". When you send the next set of bytes, the offset of that byte is 1. That's the case even when you are sending zero bytes (which is what you send when sending a FIN. > I also noticed https://github.com/quicwg/base-drafts/issues/240 which > proposes getting rid of FINs completely. Not completely, just where they are always empty (the client side of the stream in server push). From nobody Mon Mar 6 19:33:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294AD129AC7 for ; Mon, 6 Mar 2017 19:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rju4LCI92E3V for ; Mon, 6 Mar 2017 19:32:58 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0090.outbound.protection.outlook.com [104.47.33.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D32129ABA for ; Mon, 6 Mar 2017 19:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CXDQevfQv1Siw5BSwM2/l4rXc8zmZNptfv34Pc1F1fk=; b=Lerjae8vDVpS9el+A6PXhGGkbewGUNMsMP+KuQga/6ClW2eVeD1l8yyX0MhvKWoasPhZ+K6ZNAjfL3qKzH5741VTzMRDbc9KSUYe5OOfMQ+FZZrFiDy9uM3DibnsdaXLBadrRyRcjLp/wNeSDZhHI+Sj9zg7o/Z5XGh3oSj+kBI= Received: from CY4PR03MB2710.namprd03.prod.outlook.com (10.173.43.141) by CY4PR03MB2711.namprd03.prod.outlook.com (10.173.43.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 03:32:51 +0000 Received: from CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) by CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 03:32:51 +0000 From: Mike Bishop To: Subodh Iyengar , "quic@ietf.org" Subject: RE: Empty Stream with FIN Thread-Topic: Empty Stream with FIN Thread-Index: AQHSlvBX8BKm39cSRU+92Fou1/ZUKqGIuR6v Date: Tue, 7 Mar 2017 03:32:51 +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: fb.com; dkim=none (message not signed) header.d=none;fb.com; dmarc=none action=none header.from=microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:600:8300:3b9a:712d:9453:4697:ce8e] x-ms-office365-filtering-correlation-id: c9dfdb1e-c3d6-4663-0f57-08d4650aa278 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR03MB2711; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2711; 7:MYGzULeQj8cirqVQFdLupoFZxrg6kY5Am+yz+t9Rwk3OAUrsfACAzwsyWS5D4SA8/SoqpuNw8xFm6f3LNWDTxqmlGjh12nk+AZiEugxEmX5/Yc75B7k9eZm+A9PGrU9iqW94nbgWtlMnPm4ecKqGUZCwuEtwcUAcXXI66tSednj5J1Ol4EQXpMJAY7qgujFJcvHtztRFwKp7Xyx+EJCLL6rEUQA61Bg9l5T+q1sVEFfn39FTpm2h6kjEuO1JSe4M+1PiskAr8Q5/+zte55YfAN0XRcPVe/OeQWVVzX/rq5tAOhSvfGzIxQpHaWu7ZhIpSUdBhW/B202ZINDMLRJYXgPHbroJJbYXkZ0xhAoCj18= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY4PR03MB2711; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2711; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39850400002)(39410400002)(39860400002)(377454003)(102836003)(2906002)(6116002)(9886003)(7696004)(10290500002)(8936002)(2501003)(8676002)(81166006)(3280700002)(106116001)(3660700001)(3480700004)(10090500001)(2950100002)(76176999)(9686003)(55016002)(236005)(5660300001)(122556002)(54356999)(99286003)(189998001)(54896002)(92566002)(6306002)(86362001)(50986999)(25786008)(7906003)(74316002)(229853002)(2900100001)(7736002)(33656002)(53546006)(6246003)(5005710100001)(38730400002)(19627405001)(53936002)(77096006)(606005)(6436002)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2711; H:CY4PR03MB2710.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB2710C478EB93DCC3A644A0C1872F0CY4PR03MB2710namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 03:32:51.3235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2711 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:33:00 -0000 --_000_CY4PR03MB2710C478EB93DCC3A644A0C1872F0CY4PR03MB2710namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, alternately stated, the last offset is the next byte you would have s= ent. For an empty stream, that would be zero, which seems logical. Sent from my Windows 10 phone From: Subodh Iyengar Sent: Monday, March 6, 2017 7:22 PM To: quic@ietf.org Subject: Empty Stream with FIN It seems strange that for an empty stream frame with a FIN bit, the sender = needs to use the last offset + 1. Is there an existential reason for using = offset + 1 during the FIN with empty stream case? It seems easier to be abl= e to deal with the FIN bit on a stream with data, and a stream without data= uniformly. I also noticed https://github.com/quicwg/base-drafts/issues/240 which propo= ses getting rid of FINs completely. Subodh --_000_CY4PR03MB2710C478EB93DCC3A644A0C1872F0CY4PR03MB2710namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, alternately stated, the last offset is the nex= t byte you would have sent.  For an empty stream, that would be zero, = which seems logical.

 

Sent from my Windows 10 phone

 

From: Subodh Iyengar
Sent: Monday, March 6, 2017 7:22 PM
To: quic@ietf.org
Subject: Empty Stream with FIN

 

It seems strange that for an empty stream frame with a FIN b= it, the sender needs to use the last offset + 1. Is there an existential reason for using offset + 1 during the FIN with e= mpty stream case? It seems easier to be able to deal with the F= IN bit on a stream with data, and a stream without data uniformly.

I also noticed https://github.com/quicwg/base-drafts/issues/240 which propo= ses getting rid of FINs completely. 

Subodh
--_000_CY4PR03MB2710C478EB93DCC3A644A0C1872F0CY4PR03MB2710namp_-- From nobody Mon Mar 6 19:45:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF05128BA2 for ; Mon, 6 Mar 2017 19:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 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, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=V+kq125t; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IWiJ90eM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vPJ8wBAcObj for ; Mon, 6 Mar 2017 19:45:15 -0800 (PST) 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 E0EF312706D for ; Mon, 6 Mar 2017 19:45:14 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v273iH9m023937; Mon, 6 Mar 2017 19:45:12 -0800 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=fBA4wN1sx+kwwkc+vw6/+TjV5ooP74LldcucOpkAkPw=; b=V+kq125trN3kVtuc1haUOFuKZU4WUWoNuUXimOMi4nhdHDNt8jhxIDm/QLFJB4ZSCH4i Y5cX4Mj10eT2TgmfwftkO7EbsrppN/VAgT2xXo5YTRwo95RxvBWrFo0s7ImQwPuxfVXR lVJec5BrFUhWl/sfWx9/gYiPnqVObAPdx1E= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 291jnr0dyb-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 06 Mar 2017 19:45:12 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.24) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Mar 2017 19:45:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fBA4wN1sx+kwwkc+vw6/+TjV5ooP74LldcucOpkAkPw=; b=IWiJ90eMLfy2OAjQ9zm6zbfaIBkxxKqm+j8bicu67HOz5gy1JRn5s+ubDRobV098uK6fuTR3vufy4z7ePK1rW1Z4bh5X+XWzhJweiTl5oB3ECuqscTKvkbe8Z1w5JUCreqWlqwyay4FSfXxEqiDUpXQFy3LTvVFhD37BlIwKOrI= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 03:45:08 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0947.018; Tue, 7 Mar 2017 03:45:09 +0000 From: Subodh Iyengar To: Mike Bishop , "quic@ietf.org" Subject: Re: Empty Stream with FIN Thread-Topic: Empty Stream with FIN Thread-Index: AQHSlvBX8BKm39cSRU+92Fou1/ZUKqGIuR6vgAAAPBE= Date: Tue, 7 Mar 2017 03:45:08 +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: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::1ef8] x-ms-office365-filtering-correlation-id: bcd7e387-1823-40c2-462f-08d4650c5a0f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1456; x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:cETAdgIpwTjXLsIx3+0w4Q/RIdr9tTPVnXOtPQ4mwltksHCfLcqYKRLV3ZsR6UV/gD8W9RSbG9iJS7yCoRTdzbLyS5IdHD9c/oZL0R9f/LKmhRQGpY4EouxkdsnEDQ+jWeASStv2z8+mhUAsEYwK0SfE2qbvGPoJ2kgij8VySWuEipeK37R3+t4gcjlZUHAPbc5Bdy1lNlxmF8NXHmTvcqIKMOzZ3fbabzuPgwndhOn/qqdYKI20XWgYYHCR0TnvoQ79h4XQd8YLRh2eGmaPoBdIKsK49JRhIXXMdUvT9ep8pZYXC30xQQiNiLdq2mq3SmcOgPtgywDahQVWGJDQ+g==; 20:OKHPAf6HxCibqlOZtiB1z7cZO/az+IrP+CtIi2RErvmKI+WTd6fYQIER7UupuPeDs5b4Omked9vHQW3Rtcj9AlOHkJ4VgTYjs/PcBoMcQIrXBIWJ+5CDJmqKKVPNH0EnwXp0ySTMQAxDoE8U45P50/cnCh5/Pvu7/PkedxK7OT0= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(377454003)(51914003)(54896002)(3660700001)(25786008)(81166006)(6506006)(8666007)(6246003)(77096006)(229853002)(6116002)(106116001)(86362001)(55016002)(3480700004)(9686003)(2950100002)(6436002)(8676002)(122556002)(99286003)(53936002)(6306002)(8936002)(606005)(38730400002)(5660300001)(7696004)(236005)(1511001)(53546006)(102836003)(33656002)(2906002)(92566002)(3280700002)(7906003)(2561002)(19627405001)(2501003)(7736002)(50986999)(189998001)(74316002)(54356999)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14550C60DC22F0D5C7AC1314B62F0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 03:45:08.7903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-07_03:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:45:16 -0000 --_000_MWHPR15MB14550C60DC22F0D5C7AC1314B62F0MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Well, alternately stated, the last offset is the next byte you would have= sent. For an empty stream, that would be zero, which seems logical. Ya I'm not suggesting that it doesn't make logical sense, and it is definit= ely one way to do it. What was strange to me was that with this construction, a receiver would ne= ed to handle the case of a FIN with an empty stream separately from the cas= e of a FIN on a stream. An alternate similarly logical construction would b= e to set the offset to be the position of the FIN in the stream which seems= more consistent with RST_STREAM. This has the added benefit of simplifying= an implementation which could deal with it in the same code path as gettin= g a FIN on a stream with data. > Not completely, just where they are always empty (the client side of the stream in server push). Thanks for the clarification @martin Subodh ________________________________ From: QUIC on behalf of Mike Bishop Sent: Monday, March 6, 2017 7:32:51 PM To: Subodh Iyengar; quic@ietf.org Subject: RE: Empty Stream with FIN Well, alternately stated, the last offset is the next byte you would have s= ent. For an empty stream, that would be zero, which seems logical. Sent from my Windows 10 phone From: Subodh Iyengar Sent: Monday, March 6, 2017 7:22 PM To: quic@ietf.org Subject: Empty Stream with FIN It seems strange that for an empty stream frame with a FIN bit, the sender = needs to use the last offset + 1. Is there an existential reason for using = offset + 1 during the FIN with empty stream case? It seems easier to be abl= e to deal with the FIN bit on a stream with data, and a stream without data= uniformly. I also noticed https://github.com/quicwg/base-drafts/issues/240 which propo= ses getting rid of FINs completely. Subodh --_000_MWHPR15MB14550C60DC22F0D5C7AC1314B62F0MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> Well, alternately stated, the last o= ffset is the next byte you would have sent.  For an empty stream, that would be zero, which seems logical.

Ya I'm not suggesting that it doesn't make log= ical sense, and it is definitely one way to do it.
 
What was strange to me was that with this construction, a receiver wou= ld need to handle the case of a FIN with an empty stream separately from th= e case of a FIN on a stream. An alternate similarly logical construction wo= uld be to set the offset to be the position of the FIN in the stream which seems more consistent with RST_ST= REAM. This has the added benefit of simplifying an implementation which cou= ld deal with it in the same code path as getting a FIN on a stream with dat= a.

> Not= completely, just where they are always empty (the client side of the stream in= server push).

Thanks for the clarification @martin

Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Mike Bishop <Michael.Bishop@microsoft.com>=
Sent: Monday, March 6, 2017 7:32:51 PM
To: Subodh Iyengar; quic@ietf.org
Subject: RE: Empty Stream with FIN
 

Well, alternately stated, the last offset is the nex= t byte you would have sent.  For an empty stream, that would be zero, = which seems logical.

 

Sent from my Windows 10 phone

 

From: Subodh Iyengar
Sent: Monday, March 6, 2017 7:22 PM
To: quic@ietf.org
Subject: Empty Stream with FIN

 

It seems strange that for an empty stream frame with a FIN b= it, the sender needs to use the last offset + 1. Is there an existential reason for using offset + 1 during the FIN with e= mpty stream case? It seems easier to be able to deal with the F= IN bit on a stream with data, and a stream without data uniformly.

I also noticed https://github.com/quicwg/base-drafts/issues/240 which propo= ses getting rid of FINs completely. 

Subodh
--_000_MWHPR15MB14550C60DC22F0D5C7AC1314B62F0MWHPR15MB1455namp_-- From nobody Mon Mar 6 19:53:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1276129AE1 for ; Mon, 6 Mar 2017 19:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 zm9X1_yRVGwT for ; Mon, 6 Mar 2017 19:53:30 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 36F88129ADF for ; Mon, 6 Mar 2017 19:53:30 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id y76so57470191qkb.0 for ; Mon, 06 Mar 2017 19:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BmlzYdLlIhHDQ4z6mvCKfBB3y9Ui9i4Q7/bD8W3d8bA=; b=MSwLoS0NNH+OgIN48gW2JLuDVD4SLni0iLMpQi1h+/sIMPbjLWAnSNG9jA4sSMr3WU iDBbhCB/hFuaW4vcI2c7+tMSaW22NWN/aG6HOhSBrWEbpoAEze5SfKqy/czJexLnapKA 0wHXBQNZR5xPtSxrwQK4WGi0z8/CoQBDFrHZcpLTwrdNULClRf50WbflqDB+I+oxKVMD LvCAMMK38yQmxVSPI13yissQIK5kWApvONBtOgo24BEDKsHsho8UtWKIenZy3rMAE+xC TyamNw785c32gcZKxzsLg123fXQ1S5Iq9uXInKwgseKt+kkcNNqwTk5D39eGa/NYDXk+ nbTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BmlzYdLlIhHDQ4z6mvCKfBB3y9Ui9i4Q7/bD8W3d8bA=; b=AkALxQwziI0/xf7SDMAYNtp2U7JbS9bI+RW3mUWGqgih8dqZRURCTr7pzh3AIm1jQi FwXrfjFA5fWgnAzOc1i0ZfjBmxkBAcpZjriYB4KXMMWsrCO0alEF1uAoBUo81P1ku05K 0OpXWCKh2P4jUXRXyMwSblVx2lqIIrfcHpkR4Y+WK2Yx1QBvVVUDYfQqmDnq8EnhDfcb PUlSLpdu2LrnvMBzqpBiGersZG08iDDZ5HvzLX1n+DqQiawuBZwr7VtqTQS45izrYyBP ZKDMH2C2QxNN3Gioo0VRAK8F1SF3sNUj+rBVwjjnektOxc+ge2/Nc82uxJf4LF65b5jD lrkQ== X-Gm-Message-State: AMke39lQGT8/3BjsRvGCJarGW9J2CH5qN/Am1DAzsDA5GP/Q2RHwpr96MXeECQy2GPVYF10m+gMmCvSi04jbRQ== X-Received: by 10.200.3.214 with SMTP id z22mr20965809qtg.3.1488858809315; Mon, 06 Mar 2017 19:53:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 6 Mar 2017 19:53:28 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 7 Mar 2017 14:53:28 +1100 Message-ID: Subject: Re: Empty Stream with FIN To: Subodh Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 03:53:32 -0000 On 7 March 2017 at 14:45, Subodh Iyengar wrote: > What was strange to me was that with this construction, a receiver would > need to handle the case of a FIN with an empty stream separately from the > case of a FIN on a stream. An alternate similarly logical construction would > be to set the offset to be the position of the FIN in the stream which seems > more consistent with RST_STREAM. This has the added benefit of simplifying > an implementation which could deal with it in the same code path as getting > a FIN on a stream with data. I think that the reason is that you can know where the end of a stream is by the same calculation every time: + . If this frame is empty, then this produces the answer in the draft. Assuming that the logical position of the FIN is always on (or before) the next octet. From nobody Mon Mar 6 20:13:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB058129409 for ; Mon, 6 Mar 2017 20:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 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, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=IvsUdIUK; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=JpliGb6U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RniuxRfF8BxY for ; Mon, 6 Mar 2017 20:13:40 -0800 (PST) Received: from mx0a-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 AEACA1279EB for ; Mon, 6 Mar 2017 20:13:39 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.20/8.16.0.20) with SMTP id v274BTgE026345; Mon, 6 Mar 2017 20:13:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=hVImrzTsxO19A5G/AiGdDw6LjCoYSjb+/5BQ59kfSG8=; b=IvsUdIUK/1CEmrDugX4K3KU3uSVkPwsC0cKgc9VGWhUW3/J9E6I8azPdnlO0oQCsLmLY KKcc2UUqXGhEsLniPuaWkaAkCo4adDFVsWv7yfKKW1noGQrG/AjPPySzUhxbUJpkfo7X m7CUBhLceJlu4A/MF4TTSAlQGs0N8C8X47o= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0001303.ppops.net with ESMTP id 291mejg6bs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 06 Mar 2017 20:13:36 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Mar 2017 23:13:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hVImrzTsxO19A5G/AiGdDw6LjCoYSjb+/5BQ59kfSG8=; b=JpliGb6Uht54cAQQK+2+LxK+sKMrzAsYm8m/ZqjedD7V+U+bhXW7NHEosQxNDIHTWJrCNDBTUbBE5Cr11oE37L7hvY4graV9lgiByCCTZqlHPzXrJMCj7k46OiaVg4RlovzHMLmoXWRFXV+QbgmiutjAYU348RNarMYfYGCwUOU= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1454.namprd15.prod.outlook.com (10.173.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 04:13:33 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0947.018; Tue, 7 Mar 2017 04:13:33 +0000 From: Subodh Iyengar To: Martin Thomson Subject: Re: Empty Stream with FIN Thread-Topic: Empty Stream with FIN Thread-Index: AQHSlvBX8BKm39cSRU+92Fou1/ZUKqGIuR6vgAAAPBGAAAWHAIAABKdA Date: Tue, 7 Mar 2017 04:13:33 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::1ef8] x-ms-office365-filtering-correlation-id: a5a81021-c850-4cd7-89d5-08d465105226 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR15MB1454; x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 7:vtCekRDBi0O8M0D1sg1dKkHpzinnJESq3EMqBQu23mk2gdaCyTiZEVtdykJ4LwkLp7mpXNjXNrn3pkZxgNqzV/oWZmGZs5Ckv08lm+59xtoXmUBeh6he5/E+DvBF3dVekKKUxdcsBooY3FItZTqaXoxHdKLe9IkCWhbcMVriZIrF7X3k/+l/lQRj61DbJ8Re24trVJLwUwnDNhFjfdvyAt6pZaNw+27RHAGb5Mt2YKyF4NiL1gJm/+Y/S80CCl8o6bfPkqRZ0m8ZUMuPfFH4jOrkVTlwuSq6jVawC1fWqoyH2cL459q1v47UNXWOiqECsvns9XilGDzmAEa3o46XlQ==; 20:8U4OXegBtPP2JQUKwfWCtTY2uDoH7m2vI+2O17/dgHVuC2HmdDLvD/fXRK3t8kwwEd291Dn3C9B09D3PUshUHY59vy4AdDMe2ayQ24nrGOJR4mp00H20ea39vbkN86BfPjJh9SvBK6tnS9x4whfigpe4008RwEVVDWpBH2TaI6M= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1454; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(24454002)(51444003)(2906002)(6246003)(99286003)(7736002)(39060400002)(6506006)(3660700001)(4326008)(53936002)(8666007)(7696004)(2900100001)(3280700002)(55016002)(92566002)(86362001)(5660300001)(122556002)(6916009)(2950100002)(110136004)(38730400002)(106116001)(6436002)(33656002)(54356999)(229853002)(74316002)(77096006)(50986999)(9686003)(3480700004)(54896002)(8936002)(8676002)(81166006)(6116002)(53546006)(102836003)(54906002)(189998001)(25786008)(93886004)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14555A76E4245556D72EBA06B62F0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 04:13:33.6160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1454 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-07_03:, , signatures=0 Archived-At: Cc: Mike Bishop , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 04:13:41 -0000 --_000_MWHPR15MB14555A76E4245556D72EBA06B62F0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think that the reason is that you can know where the end of a stream is by the same calculation every time: + . If this frame is empty, then this produces the answer in the draft. Assuming that the logical position of the FIN is always on (or before) the next octet. Sounds good. Putting it that way does keep it consistent across the empty F= IN and the non-empty stream case. Thanks, Subodh ________________________________ From: QUIC on behalf of Martin Thomson Sent: Monday, March 6, 2017 7:53:28 PM To: Subodh Iyengar Cc: Mike Bishop; quic@ietf.org Subject: Re: Empty Stream with FIN On 7 March 2017 at 14:45, Subodh Iyengar wrote: > What was strange to me was that with this construction, a receiver would > need to handle the case of a FIN with an empty stream separately from the > case of a FIN on a stream. An alternate similarly logical construction wo= uld > be to set the offset to be the position of the FIN in the stream which se= ems > more consistent with RST_STREAM. This has the added benefit of simplifyin= g > an implementation which could deal with it in the same code path as getti= ng > a FIN on a stream with data. I think that the reason is that you can know where the end of a stream is by the same calculation every time: + . If this frame is empty, then this produces the answer in the draft. Assuming that the logical position of the FIN is always on (or before) the next octet. --_000_MWHPR15MB14555A76E4245556D72EBA06B62F0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I thi= nk that the reason is that you can know where the end of a stream is by the same cal= culation every time: <offset> + <number of octets in this frame>.&nb= sp; If this frame is empty, then this produces the answer in
the draft.  A= ssuming that the logical position of the FIN is always on
(or before) the ne= xt octet.


Sounds good. Putting it that way does keep it consistent across the empt= y FIN and the non-empty stream case.


Thanks,

Subodh

From: QUIC <quic-bounc= es@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>= ;
Sent: Monday, March 6, 2017 7:53:28 PM
To: Subodh Iyengar
Cc: Mike Bishop; quic@ietf.org
Subject: Re: Empty Stream with FIN
 
On 7 March 2017 at 14:45, Subodh Iyengar <subod= h@fb.com> wrote:
> What was strange to me was that with this construction, a receiver wou= ld
> need to handle the case of a FIN with an empty stream separately from = the
> case of a FIN on a stream. An alternate similarly logical construction= would
> be to set the offset to be the position of the FIN in the stream which= seems
> more consistent with RST_STREAM. This has the added benefit of simplif= ying
> an implementation which could deal with it in the same code path as ge= tting
> a FIN on a stream with data.


I think that the reason is that you can know where the end of a stream
is by the same calculation every time: <offset> + <number of o= ctets in
this frame>.  If this frame is empty, then this produces the answer= in
the draft.  Assuming that the logical position of the FIN is always on=
(or before) the next octet.

 --_000_MWHPR15MB14555A76E4245556D72EBA06B62F0MWHPR15MB1455namp_-- From nobody Tue Mar 7 08:59:26 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6E81294EF for ; Tue, 7 Mar 2017 08:59:24 -0800 (PST) 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 3WtDSfvxaIHT for ; Tue, 7 Mar 2017 08:59:22 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 576901294D0 for ; Tue, 7 Mar 2017 08:59:22 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id o24so9287279otb.1 for ; Tue, 07 Mar 2017 08:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ziYZpUV/JJu7wYY0d3TLZ9FN7rkJ26jims7lM09swuE=; b=eV2U5gWOIMnMIHIH9GkG0cEWpx+q+OM5b775qdaTwCSOF6bZN3NmWqK2h4ChD9PnPw qvFZp/lwR1ABUokwKNT6iglkCJIXnrEhzdWGgmR5ysGgUq1qU8qwQLMC0ZHOIOtWcZT5 QxNmOdWbSDa+kNtSSgfKUh1uQ7S6aCAb5inD5HTduZuStGGuQzxKkXfNummBlQys6MaQ J5h3IWTj9FP+N7+WeFHvFqK5s/SWVFLbrpEwLzG4okpbaD7bjNrgcMbboYvUxkvGSEp4 7VztCz5Y6V58HHlpOjxuVsuXFsQb4iWjHd8zsQ+LikgBhJ0nNlI5wTpQaVRIDkNBz7E0 slXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ziYZpUV/JJu7wYY0d3TLZ9FN7rkJ26jims7lM09swuE=; b=TUzKtrnDp9AkpnuzpH1Qt7Io3TnSQ8i4PoGWfcNXPmbq2P7e8Q44L4GBmMEtn86HLT L6RESgc9PjORVwKFlEJaJfM71PYLW5C1ZDvhUXofAjnTg2mmpilObYIJvn79lofdyuYu jlHoKmICx7/pjyzWsXJgW0kXtfTxSXJSt3XmUd4KsOg+1qtFn8MHzbYOS4yEo54KY1lw jWmdInrvBi/Z5CGKMm7sJP2hL/H06EJusguiFD21b+4ocLi5wydzDJrn8nJYGUZbTFZa HJiIkGN2Jctpf33cfwKBBR8O2uJEyV+RBQFT9q1Ksntd7Gkwi0pGk3znyDuM6gXXrpBA 5VgA== X-Gm-Message-State: AMke39neTfjj4/2q1Ee1IdhHq8fDXjSLw+L7ZZN5bKKnJr4ndbuzz5YjH3VdiaiXu1VVR1a7BWXD76hYQNULQg== X-Received: by 10.157.63.145 with SMTP id r17mr717127otc.47.1488905961379; Tue, 07 Mar 2017 08:59:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.42.10 with HTTP; Tue, 7 Mar 2017 08:58:50 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Tue, 7 Mar 2017 08:58:50 -0800 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c01770ee9e04054a26ee56 Archived-At: Cc: Ian Swett , IETF QUIC WG , Lucas Clemente , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 16:59:24 -0000 --001a11c01770ee9e04054a26ee56 Content-Type: text/plain; charset=UTF-8 Howdy, On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson wrote: > I think that both are likely to run afoul of a simple problem in HTTP: > the control stream (stream 3) can't be closed. > > I don't think that's actually a problem with what I suggested. It simply means that for the HTTP mapping, the defined behavior is to send FIN_COMPLETE after all open requests and pushes complete. If it arrives before then, you'd have to treat it as a protocol error for the mapping. What I'm trying to avoid is baking in the requirement that FIN_COMPLETE (or its moral equivalent) always occur then, since it will make using other types of streams harder. Possibly I have missed something, though; happy to hear more. Ted > The graceful shutdown I was imagining was, specifically for HTTP. > > 1. HTTP application calls shutdown() locally (assuming that close() is > immediate) > 2. HTTP layer signals intent to close (including last stream identifiers) > 3. HTTP layer stops opening new streams > 4. HTTP layer waits for all open requests and pushes to complete or > error out (which means waiting for RST_STREAM or FIN in both > directions AND waiting for an ACK for any RST_STREAM or FIN that it > initiated itself) > X. The peer HTTP layer receives intent to close and does the same > 5. HTTP layer (on either end) calls close() > 6. QUIC layer sends CONNECTION_CLOSE and terminates the connection > > That doesn't rely on any QUIC-layer signaling. > > Also, stream 3 never closes. It doesn't have to. Its contents are > critical, but only as long as there are requests/responses/pushes in > flight. > > On 7 March 2017 at 10:29, Ted Hardie wrote: > > On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke > wrote: > >> > >> So I think the GOAWAY-less QUIC clean-shutdown protocol behavior is as > >> follows, trying to imitate TCP semantics where possible: > >> > >> Application sends close() > >> QUIC stops initiating streams > >> Finish delivering all outstanding streams, send a FIN bit, and close the > >> stream the FIN is acked. > > > > > > So, this seems subtly limiting. If QUIC stops initiating streams, it > could > > notify the other endpoint that it had entered shutdown and then let the > > other side complete the shutdown at any point from then on. For some > > applications, the emitter initiating shutdown may mean that the receiver > is > > also done; for others, the reliability of stream delivery required may be > > variable depending on the application semantics and the availability of > FEC. > > > > How about > > > > Application sends close > > QUIC stops initiating streams, send FIN_START > > QUIC delivers outstanding streams until receiving FIN_COMPLETE > > If all streams delivered and no FIN_COMPLETE, start timer. > > > > I believe that lets you get the same semantics in the set above, by > simply > > delivering the FIN_COMPLETE when all outstanding streams are delivered, > but > > it may open up other semantics as well. > > > > regards, > > > > Ted > > > >> > >> Wait patiently for all the peer's stream FINs and ack them. > >> * QUIC makes the assumption that the peer will open no more streams * > >> If the acknowledgment of the peer's last FINs was not itself acked > because > >> it had data with it, then start a TIME-WAIT timer. > >> If not, or when the TIME-WAIT timer expires, silently delete all state > >> (or, if we want to signal middleboxes, send a PUBLIC_RESET). > >> > >> I think I'm alright with that, particularly if we send that Reset. > >> > >> We wouldn't have to assume that the peer will open no more streams if we > >> were to repurpose GOAWAY to mean "I'm not starting any more streams", > which > >> in my view would be a bit cleaner. > >> > >> On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson < > martin.thomson@gmail.com> > >> wrote: > >>> > >>> On 7 March 2017 at 00:37, Ian Swett wrote: > >>> > Not having a way to close the connection gracefully seems like a > >>> > missing > >>> > feature, but I'm not hung up on having it if it's really not > generally > >>> > useful. > >>> > >>> We made a similar decision with priority. Multiplexing without > >>> priority is - at best - lame. But we now require that the application > >>> protocol manage priority and any signaling that might be needed. The > >>> same decision could be made for graceful shutdown, and based on this > >>> discussion, I'm inclined to think that it's the right decision. > >> > >> > > > --001a11c01770ee9e04054a26ee56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I think that both are likely to run afoul of a simple problem in HTTP= :
the control stream (stream 3) can't be closed.

I don't think that's actually a problem with = what I suggested.=C2=A0 It simply means that for the HTTP mapping, the defi= ned behavior is to send FIN_COMPLETE after all open requests and pushes com= plete.=C2=A0 If it arrives before then, you'd have to treat it as a pro= tocol error for the mapping.=C2=A0 What I'm trying to avoid is baking i= n the requirement that FIN_COMPLETE (or its moral equivalent) always occur = then, since it will make using other types of streams harder.

=
Possibly I have missed something, though; happy to hear more.

<= /div>
Ted

=C2=A0
The graceful shutdown I was imagining was, specifically for HTTP.

1. HTTP application calls shutdown() locally (assuming that close() is
immediate)
2. HTTP layer signals intent to close (including last stream identifiers) 3. HTTP layer stops opening new streams
4. HTTP layer waits for all open requests and pushes to complete or
error out (which means waiting for RST_STREAM or FIN in both
directions AND waiting for an ACK for any RST_STREAM or FIN that it
initiated itself)
X. The peer HTTP layer receives intent to close and does the same
5. HTTP layer (on either end) calls close()
6. QUIC layer sends CONNECTION_CLOSE and terminates the connection

That doesn't rely on any QUIC-layer signaling.

Also, stream 3 never closes.=C2=A0 It doesn't have to.=C2=A0 Its conten= ts are
critical, but only as long as there are requests/responses/pushes in
flight.

On 7 March 2017 at 10:29, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
>>
>> So I think the GOAWAY-less QUIC clean-shutdown protocol behavior i= s as
>> follows, trying to imitate TCP semantics where possible:
>>
>> Application sends close()
>> QUIC stops initiating streams
>> Finish delivering all outstanding streams, send a FIN bit, and clo= se the
>> stream the FIN is acked.
>
>
> So, this seems subtly limiting.=C2=A0 If QUIC stops initiating streams= , it could
> notify the other endpoint that it had entered shutdown and then let th= e
> other side complete the shutdown at any point from then on.=C2=A0 For = some
> applications, the emitter initiating shutdown may mean that the receiv= er is
> also done; for others, the reliability of stream delivery required may= be
> variable depending on the application semantics and the availability o= f FEC.
>
> How about
>
> Application sends close
> QUIC stops initiating streams, send FIN_START
> QUIC delivers outstanding streams until receiving FIN_COMPLETE
> If all streams delivered and no FIN_COMPLETE, start timer.
>
> I believe that lets you get the same semantics in the set above, by si= mply
> delivering the FIN_COMPLETE when all outstanding streams are delivered= , but
> it may open up other semantics as well.
>
> regards,
>
> Ted
>
>>
>> Wait patiently for all the peer's stream FINs and ack them. >> * QUIC makes the assumption that the peer will open no more stream= s *
>> If the acknowledgment of the peer's last FINs was not itself a= cked because
>> it had data with it, then start a TIME-WAIT timer.
>> If not, or when the TIME-WAIT timer expires, silently delete all s= tate
>> (or, if we want to signal middleboxes, send a PUBLIC_RESET).
>>
>> I think I'm alright with that, particularly if we send that Re= set.
>>
>> We wouldn't have to assume that the peer will open no more str= eams if we
>> were to repurpose GOAWAY to mean "I'm not starting any mo= re streams", which
>> in my view would be a bit cleaner.
>>
>> On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>>
>>> On 7 March 2017 at 00:37, Ian Swett <ianswett@google.com> wrote:
>>> > Not having a way to close the connection gracefully seems= like a
>>> > missing
>>> > feature, but I'm not hung up on having it if it's= really not generally
>>> > useful.
>>>
>>> We made a similar decision with priority.=C2=A0 Multiplexing w= ithout
>>> priority is - at best - lame.=C2=A0 But we now require that th= e application
>>> protocol manage priority and any signaling that might be neede= d.=C2=A0 The
>>> same decision could be made for graceful shutdown, and based o= n this
>>> discussion, I'm inclined to think that it's the right = decision.
>>
>>
>

--001a11c01770ee9e04054a26ee56-- From nobody Tue Mar 7 09:15:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A33129582 for ; Tue, 7 Mar 2017 09:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbkJ6MYX5LKY for ; Tue, 7 Mar 2017 09:15:10 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0124.outbound.protection.outlook.com [104.47.42.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BBA1294F0 for ; Tue, 7 Mar 2017 09:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wImHUqILJdMx0bjx5hjmBaG4+d+nVVUv9/Gxth72ub0=; b=MsY46pWF9e7sUk+HKN4f9/3pDJPYHl1muMP9n8+LQxaz4TPil2mkcwT5nPdp6NBcdVDaPhFzKt8JVOLlQuLcNjYp8mLVMHR/rYVTDxmLrRR+UJR0DUpeyRckDq1gcWFC1DqDtK4L9jWTh42yVsRChOxaKcRmmoYTj9OS8gApZCE= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 17:15:08 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 17:15:07 +0000 From: Mike Bishop To: Ted Hardie , Martin Thomson Subject: RE: Move GOAWAY to HTTP draft Thread-Topic: Move GOAWAY to HTTP draft Thread-Index: AQHSlf4x+1FK6xgGX0mOGjIclw5osqGG1dGAgAAEPYCAACiUsIAAHj8AgACw04CAAJjegIAABhWAgAAGbACAAALxAIABIi8AgAAEjdA= Date: Tue, 7 Mar 2017 17:15:07 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2607:fb90:fd0:6b36:6c61:7f08:230:62ac] x-ms-office365-filtering-correlation-id: 66dbcf95-2cbd-4ff9-71b2-08d4657d8136 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:iurAU6RwEKtJIuyw8ckDWapWQz9DgPkL9VYKU2MGmvwB9aFm94kTGFc8K64jEse4kQPSwjU5x6FlSXK0timbxoKpeSkuo5OvqV/CZmkc/9osscD2VqHu5TtARfEYnkAJ3boy/1gd4CAmNujQWlE6v3ZklPznqVstE8H1gEsfoF9VhlZXkBq6en2ciCpeeCWRrgoiSX3vMgmH1sfD79gFMQZGrb19GWYqcJk2FWQB8P4CL8IC9pj4vxinXA1dugVBbyJZf3jYTSUMb8DI+y19fK2eXMW7IPrbkd9ZfQZWIBwNW6UgmJts8bqaYG22hyQ0uo2TFfxNZ93cEVXKmLCKiapPDzGpB5uqQqTBhSxkAHU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(6072148)(6042181); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(51444003)(86612001)(74316002)(4326008)(2900100001)(5005710100001)(86362001)(10090500001)(7736002)(50986999)(236005)(54356999)(76176999)(102836003)(106116001)(6116002)(8990500004)(10290500002)(122556002)(2906002)(8676002)(81166006)(3660700001)(38730400002)(8936002)(6246003)(53546006)(6436002)(25786008)(93886004)(55016002)(3280700002)(54906002)(99286003)(9686003)(54896002)(229853002)(39060400002)(77096006)(7696004)(6506006)(33656002)(5660300001)(2950100002)(53936002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27081281B747910080F01C15872F0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 17:15:07.6986 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Ian Swett , IETF QUIC WG , Lucas Clemente , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:15:12 -0000 --_000_BN6PR03MB27081281B747910080F01C15872F0BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We could also change the HTTP draft to say that as part of shutdown, you *d= o* close the control stream after all other streams have been closed. If t= he control stream closes before any other stream, it's an error. Sent from my Windows 10 phone From: Ted Hardie Sent: Tuesday, March 7, 2017 8:59 AM To: Martin Thomson Cc: Ian Swett; IETF QUIC WG; Lucas Clemente; Martin Duke Subject: Re: Move GOAWAY to HTTP draft Howdy, On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson > wrote: I think that both are likely to run afoul of a simple problem in HTTP: the control stream (stream 3) can't be closed. I don't think that's actually a problem with what I suggested. It simply m= eans that for the HTTP mapping, the defined behavior is to send FIN_COMPLET= E after all open requests and pushes complete. If it arrives before then, = you'd have to treat it as a protocol error for the mapping. What I'm tryin= g to avoid is baking in the requirement that FIN_COMPLETE (or its moral equ= ivalent) always occur then, since it will make using other types of streams= harder. Possibly I have missed something, though; happy to hear more. Ted The graceful shutdown I was imagining was, specifically for HTTP. 1. HTTP application calls shutdown() locally (assuming that close() is immediate) 2. HTTP layer signals intent to close (including last stream identifiers) 3. HTTP layer stops opening new streams 4. HTTP layer waits for all open requests and pushes to complete or error out (which means waiting for RST_STREAM or FIN in both directions AND waiting for an ACK for any RST_STREAM or FIN that it initiated itself) X. The peer HTTP layer receives intent to close and does the same 5. HTTP layer (on either end) calls close() 6. QUIC layer sends CONNECTION_CLOSE and terminates the connection That doesn't rely on any QUIC-layer signaling. Also, stream 3 never closes. It doesn't have to. Its contents are critical, but only as long as there are requests/responses/pushes in flight. On 7 March 2017 at 10:29, Ted Hardie > wrote: > On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke > wrote: >> >> So I think the GOAWAY-less QUIC clean-shutdown protocol behavior is as >> follows, trying to imitate TCP semantics where possible: >> >> Application sends close() >> QUIC stops initiating streams >> Finish delivering all outstanding streams, send a FIN bit, and close the >> stream the FIN is acked. > > > So, this seems subtly limiting. If QUIC stops initiating streams, it cou= ld > notify the other endpoint that it had entered shutdown and then let the > other side complete the shutdown at any point from then on. For some > applications, the emitter initiating shutdown may mean that the receiver = is > also done; for others, the reliability of stream delivery required may be > variable depending on the application semantics and the availability of F= EC. > > How about > > Application sends close > QUIC stops initiating streams, send FIN_START > QUIC delivers outstanding streams until receiving FIN_COMPLETE > If all streams delivered and no FIN_COMPLETE, start timer. > > I believe that lets you get the same semantics in the set above, by simpl= y > delivering the FIN_COMPLETE when all outstanding streams are delivered, b= ut > it may open up other semantics as well. > > regards, > > Ted > >> >> Wait patiently for all the peer's stream FINs and ack them. >> * QUIC makes the assumption that the peer will open no more streams * >> If the acknowledgment of the peer's last FINs was not itself acked becau= se >> it had data with it, then start a TIME-WAIT timer. >> If not, or when the TIME-WAIT timer expires, silently delete all state >> (or, if we want to signal middleboxes, send a PUBLIC_RESET). >> >> I think I'm alright with that, particularly if we send that Reset. >> >> We wouldn't have to assume that the peer will open no more streams if we >> were to repurpose GOAWAY to mean "I'm not starting any more streams", wh= ich >> in my view would be a bit cleaner. >> >> On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson > >> wrote: >>> >>> On 7 March 2017 at 00:37, Ian Swett > wrote: >>> > Not having a way to close the connection gracefully seems like a >>> > missing >>> > feature, but I'm not hung up on having it if it's really not generall= y >>> > useful. >>> >>> We made a similar decision with priority. Multiplexing without >>> priority is - at best - lame. But we now require that the application >>> protocol manage priority and any signaling that might be needed. The >>> same decision could be made for graceful shutdown, and based on this >>> discussion, I'm inclined to think that it's the right decision. >> >> > --_000_BN6PR03MB27081281B747910080F01C15872F0BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We could also change the HTTP draft to say that as p= art of shutdown, you *do* close the control stream after all other s= treams have been closed.  If the control stream closes before any othe= r stream, it's an error.

 

Sent from my Windows 10 phone

 

From: Ted Hardie
Sent: Tuesday, March 7, 2017 8:59 AM
To: Martin Thomson Cc: Ian Swett; IETF QUIC WG; Lucas Clemente= ; Martin Duke
Subject: Re: Move GOAWAY to HTTP draft

 

Howdy,

On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson <= span dir=3D"ltr"> <martin.th= omson@gmail.com> wrote:
I think that both are likely to run afoul of a simple problem in HTTP:
the control stream (stream 3) can't be closed.

I don't think that's actually a problem with what I suggested.  I= t simply means that for the HTTP mapping, the defined behavior is to send F= IN_COMPLETE after all open requests and pushes complete.  If it arrive= s before then, you'd have to treat it as a protocol error for the mapping.  What I'm trying to avoid is baking i= n the requirement that FIN_COMPLETE (or its moral equivalent) always occur = then, since it will make using other types of streams harder.

Possibly I have missed something, though; happy to hear more.

Ted

 
The graceful shutdown I was imagining was, specifically for HTTP.

1. HTTP application calls shutdown() locally (assuming that close() is
immediate)
2. HTTP layer signals intent to close (including last stream identifiers) 3. HTTP layer stops opening new streams
4. HTTP layer waits for all open requests and pushes to complete or
error out (which means waiting for RST_STREAM or FIN in both
directions AND waiting for an ACK for any RST_STREAM or FIN that it
initiated itself)
X. The peer HTTP layer receives intent to close and does the same
5. HTTP layer (on either end) calls close()
6. QUIC layer sends CONNECTION_CLOSE and terminates the connection

That doesn't rely on any QUIC-layer signaling.

Also, stream 3 never closes.  It doesn't have to.  Its contents a= re
critical, but only as long as there are requests/responses/pushes in
flight.

On 7 March 2017 at 10:29, Ted Hardie <ted.ietf@gmail.com> wrote:
> On Mon, Mar 6, 2017 at 3:06 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
>>
>> So I think the GOAWAY-less QUIC clean-shutdown protocol behavior i= s as
>> follows, trying to imitate TCP semantics where possible:
>>
>> Application sends close()
>> QUIC stops initiating streams
>> Finish delivering all outstanding streams, send a FIN bit, and clo= se the
>> stream the FIN is acked.
>
>
> So, this seems subtly limiting.  If QUIC stops initiating streams= , it could
> notify the other endpoint that it had entered shutdown and then let th= e
> other side complete the shutdown at any point from then on.  For = some
> applications, the emitter initiating shutdown may mean that the receiv= er is
> also done; for others, the reliability of stream delivery required may= be
> variable depending on the application semantics and the availability o= f FEC.
>
> How about
>
> Application sends close
> QUIC stops initiating streams, send FIN_START
> QUIC delivers outstanding streams until receiving FIN_COMPLETE
> If all streams delivered and no FIN_COMPLETE, start timer.
>
> I believe that lets you get the same semantics in the set above, by si= mply
> delivering the FIN_COMPLETE when all outstanding streams are delivered= , but
> it may open up other semantics as well.
>
> regards,
>
> Ted
>
>>
>> Wait patiently for all the peer's stream FINs and ack them.
>> * QUIC makes the assumption that the peer will open no more stream= s *
>> If the acknowledgment of the peer's last FINs was not itself acked= because
>> it had data with it, then start a TIME-WAIT timer.
>> If not, or when the TIME-WAIT timer expires, silently delete all s= tate
>> (or, if we want to signal middleboxes, send a PUBLIC_RESET).
>>
>> I think I'm alright with that, particularly if we send that Reset.=
>>
>> We wouldn't have to assume that the peer will open no more streams= if we
>> were to repurpose GOAWAY to mean "I'm not starting any more s= treams", which
>> in my view would be a bit cleaner.
>>
>> On Mon, Mar 6, 2017 at 2:44 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>>
>>> On 7 March 2017 at 00:37, Ian Swett <ianswett@google.com> wrote:
>>> > Not having a way to close the connection gracefully seems= like a
>>> > missing
>>> > feature, but I'm not hung up on having it if it's really = not generally
>>> > useful.
>>>
>>> We made a similar decision with priority.  Multiplexing w= ithout
>>> priority is - at best - lame.  But we now require that th= e application
>>> protocol manage priority and any signaling that might be neede= d.  The
>>> same decision could be made for graceful shutdown, and based o= n this
>>> discussion, I'm inclined to think that it's the right decision= .
>>
>>
>

--_000_BN6PR03MB27081281B747910080F01C15872F0BN6PR03MB2708namp_-- From nobody Tue Mar 7 10:45:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66F81295E7 for ; Tue, 7 Mar 2017 10:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41jJtuRctaMi for ; Tue, 7 Mar 2017 10:45:40 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0120.outbound.protection.outlook.com [104.47.36.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6815D129467 for ; Tue, 7 Mar 2017 10:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vhg2BKbVpZCil6vLFHi9YCnZAt2cjkc02up6eeaDXO0=; b=HPyHhsEmAcU7te6LgFqXwuL8da44TL/oomqxfDDyYY/LplL9zlPSQyuLormSm8tLxW5wkvIOeRO0JnwDENH0DRjASy/8Fsz9dDujP444XqH/dRZm2eD/2Rrdhjl839Tyonc0TNixkNV4mYXnR6yGjpwPhsG1a5H+G5OfGtx5uck= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 18:45:38 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 18:45:38 +0000 From: Mike Bishop To: IETF QUIC WG Subject: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcg== Date: Tue, 7 Mar 2017 18:45:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9::557] x-ms-office365-filtering-correlation-id: cc4a22c9-9222-4776-6ffa-08d4658a2648 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:MhvyGZDhQJMGNc1mp8al85dWi/tXe318MDFcxgaLEtz2fxvHi0ZUjeZC566+mGLl9QuzriEP3LjUFeIp0owP3DvMpnC1dW+8Wy5tRhfI/4wnQfXQh6vCXkqQ03/BP/WgFJigwTn6LHfPin6C+OK5sThL+ZN7FiYFnvceZtGiM2T2xpehmJRaoS4LuUQOmCiUabwEZNAjeajOG81y5Pl7KrB1TrV0j4fNIizx00TjsKe5I158ZMr/sTJhlGBXGtXL1nHCYZ3ODahtjrnyUnWcV4QnORCQcg5PG/1KzuzxWUxEb/N5ddDwLloaIqmJgrehjk5jkeT06h6tJ4dbvBnY/S8cDjDXf2sPJPJaPU5NWHQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39850400002)(39450400003)(39410400002)(5005710100001)(7696004)(236005)(6306002)(9686003)(54896002)(7116003)(33656002)(6436002)(25786008)(606005)(790700001)(122556002)(86612001)(102836003)(6116002)(110136004)(7736002)(77096006)(6506006)(3660700001)(86362001)(38730400002)(10290500002)(74316002)(6916009)(8676002)(3280700002)(55016002)(5660300001)(99286003)(7906003)(54356999)(3480700004)(53936002)(8936002)(50986999)(10090500001)(2900100001)(2906002)(189998001)(221733001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A66471259D48A97DC5E6872F0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 18:45:38.6849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:45:43 -0000 --_000_BN6PR03MB2708A66471259D48A97DC5E6872F0BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Tokyo interim, we had a discussion around Issue #165, PR #171 proposing a REQUEST_RST frame, and the fact that Google QU= IC currently special-cases the same semantics to a RST_STREAM with a specif= ic error code. (There is a TODO in the text to write up this "special case= .") My sense of the consensus at the interim was that special casing parti= cular error codes felt hacky, and there was moderate support for making it = a different frame type altogether, but people wanted to look at the PR in m= ore detail. At Martin's suggestion, the frame in the PR has been renamed to DISINTEREST= . It's an explicit signal that incoming data is not being read by the appl= ication and will be discarded by the transport upon receipt; the receiver o= f a DISINTEREST frame is suggested to abruptly terminate the stream in ques= tion. In terms of application API, think of it as the wire signal that the= read handle has been closed. I think this should explicitly not be a special case of a RST_STREAM error = code, because it has different semantics around retransmissions. In partic= ular, the sender of a DISINTEREST frame might still be sending data, still = be retransmitting lost STREAM frames, and still expecting that data to be c= onsumed. A special case around whether to process the incoming data, I cou= ld accept; a special case around whether retransmission is still enabled on= the stream feels really wrong. In order to enable this, the PR changes the semantics of RST_STREAM as well= . Streams consist of a data channel in each direction. That data channel = can be closed cleanly (FIN) or abruptly (RST_STREAM) in each direction. If= cleanly, data gets retransmitted in that direction. If abruptly, nothing = more will be sent, whether it got through or not. Only the sender can clos= e their data channel, and only they decide how and when it closes. (Though= DISINTEREST is a strong signal there's no point in continuing to transmit.= ) In Tokyo, we said we wanted to wait while folks reviewed the PR. We've had= a month, and I've gotten some good feedback from one more person (thanks, = Lucas!). Have people reviewed and are okay with it? Have people not looke= d and violently disagree? If so, let's discuss. We still have a few days = before the draft deadline; maybe we can reach consensus before -02? --_000_BN6PR03MB2708A66471259D48A97DC5E6872F0BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Tokyo interim, we had a discussion around Iss= ue #165, PR #17= 1 proposing a REQUEST_RST frame, and the fact that Google QUIC currentl= y special-cases the same semantics to a RST_STREAM with a specific error co= de.  (There is a TODO in the text to write up this “special case.”)  My sense of the consen= sus at the interim was that special casing particular error codes felt hack= y, and there was moderate support for making it a different frame type alto= gether, but people wanted to look at the PR in more detail.

 

At Martin’s suggestion, the frame in the PR ha= s been renamed to DISINTEREST.  It’s an explicit signal that inc= oming data is not being read by the application and will be discarded by th= e transport upon receipt; the receiver of a DISINTEREST frame is suggested to abruptly terminate the stream in question.  In = terms of application API, think of it as the wire signal that the read hand= le has been closed.

 

I think this should explicitly not be a special case= of a RST_STREAM error code, because it has different semantics around retr= ansmissions.  In particular, the sender of a DISINTEREST frame might s= till be sending data, still be retransmitting lost STREAM frames, and still expecting that data to be consumed.  A = special case around whether to process the incoming data, I could accept; a= special case around whether retransmission is still enabled on the stream = feels really wrong.

 

In order to enable this, the PR changes the semantic= s of RST_STREAM as well.  Streams consist of a data channel in each di= rection.  That data channel can be closed cleanly (FIN) or abruptly (R= ST_STREAM) in each direction.  If cleanly, data gets retransmitted in that= direction.  If abruptly, nothing more will be sent, whether it got th= rough or not.  Only the sender can close their data channel, and only = they decide how and when it closes.  (Though DISINTEREST is a strong signal there’s no point in continuing to transmit.)=

 

In Tokyo, we said we wanted to wait while folks revi= ewed the PR.  We’ve had a month, and I’ve gotten some good= feedback from one more person (thanks, Lucas!).  Have people reviewed= and are okay with it?  Have people not looked and violently disagree?  If so, let’s discuss.  We still have a few days= before the draft deadline; maybe we can reach consensus before -02?

--_000_BN6PR03MB2708A66471259D48A97DC5E6872F0BN6PR03MB2708namp_-- From nobody Tue Mar 7 10:59:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4437E1295ED for ; Tue, 7 Mar 2017 10:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3EvsE4ZT5XB6 for ; Tue, 7 Mar 2017 10:59:52 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 D21061295C1 for ; Tue, 7 Mar 2017 10:59:51 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 72so17286918uaf.3 for ; Tue, 07 Mar 2017 10:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ds8uf5iIocMx9jKwbGfVY3oiPzXh2VGLL67oUeNkam4=; b=Y6Tobb4SqY3xuxm5NABJwGpLDb3xqK/9HfeNGsU6FQhwsKjSP3Wc+MAzK0I9WEBb1L 6ZQ07fN9W08ZvuKHqjl7lbMYLHlemE+3jg4QmJoj2/yRXgjSqvxVoBMxKcIwkXEQBmG4 N0CIlt9XSBD9XxzDjVG5N9cNAo6ymli+yi3Q4PGZ3yXmK/0fhEJa2obo1/wWb4j79dI6 xcNWjQh/q/Zj5JV/H6hi/62cYpT+YgZUCRn4+kFUO1EG6xGr1dnIWmwY3KeEbzgXEx/t JUK140g+sgEO86AY4EY/0Ioptr1f01QGgkgBbQkwzxMW5tN36F/Zk81eTpiYcA+w/evl GWbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ds8uf5iIocMx9jKwbGfVY3oiPzXh2VGLL67oUeNkam4=; b=k1wxXG36ppIcJ/fFQIVa8veEQEoKuViznqVnZoL7fc2ValAqvJMNNHopJjTTAb5eup bXiVrlT3L+QGl4WJte+KbiVdmLvYAv4KoKZi8uiYpp65oDW3msSoBnZhzjz2oUnviF4Z Ym5+aC42EewTz7HuOQz9v6G/1mq0has2eKoI+Wf4TF5PbYNP7G807bmcDf9JcNpUw1wX y8cSMm4v+3cVLWHlK9NVjtFdnwIcBCXg5iN+X2KT0MrJ//4nIjJQNouP5waVL8jb5Byq m7dl1aauVjxZ+Zx/05kCHRPKe9puDJHv7KOSdZeWhuN8P56IY4mnnAPLS4jtjTrGuwhm i0EA== X-Gm-Message-State: AMke39k2TnySSuh7V/42nQlg2xcWu37rpgvPQM/Kb1hUIh4VTFOODTPLJGZ+/EqD342zCMuHFmHJU5bhMnOD5O6x X-Received: by 10.31.200.199 with SMTP id y190mr1106763vkf.115.1488913190720; Tue, 07 Mar 2017 10:59:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 7 Mar 2017 10:59:50 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 7 Mar 2017 10:59:50 -0800 Message-ID: Subject: Re: Adjustments to the issue resolution documentation To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a114d9d48d609c2054a289d31 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 18:59:53 -0000 --001a114d9d48d609c2054a289d31 Content-Type: text/plain; charset=UTF-8 Sounds good to me! On Mon, Mar 6, 2017 at 4:52 PM, Mark Nottingham wrote: > Hi everyone, > > Based on our experience so far in running the process, and after > discussion with Lars and the Editors, I've made a few changes to the > documentation in CONTRIBUTING.md regarding how issues are resolved. > > See: > https://github.com/quicwg/base-drafts/blob/master/ > CONTRIBUTING.md#resolving-issues > > In particular, we now have an explicit `has-consensus` label to reflect > those issues where we've declared WG consensus. > > `Closed` issues are merely those that have a proposal reflected in the > document that we *believe* reflects consensus, but that hasn't been > confirmed yet. > > Does that make sense to everyone? Hopefully this will reflect the process > more clearly, and be easier to understand. If this causes concern or if you > have other suggestions, please bring it up. > > Cheers, > > P.S. Keen observers will note that we only have declared consensus on one > issue -- hopefully that number will increase once we get a new set of > drafts out and reviewed. > > -- > Mark Nottingham https://www.mnot.net/ > > --001a114d9d48d609c2054a289d31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me!

On Mon, Mar 6, 2017 at 4:52 PM, Mark Nottingham <mnot@= mnot.net> wrote:
Hi every= one,

Based on our experience so far in running the process, and after discussion= with Lars and the Editors, I've made a few changes to the documentatio= n in CONTRIBUTING.md regarding how issues are resolved.

See:
=C2=A0 https://git= hub.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md#resolving-= issues

In particular, we now have an explicit `has-consensus` label to reflect tho= se issues where we've declared WG consensus.

`Closed` issues are merely those that have a proposal reflected in the docu= ment that we *believe* reflects consensus, but that hasn't been confirm= ed yet.

Does that make sense to everyone? Hopefully this will reflect the process m= ore clearly, and be easier to understand. If this causes concern or if you = have other suggestions, please bring it up.

Cheers,

P.S. Keen observers will note that we only have declared consensus on one i= ssue -- hopefully that number will increase once we get a new set of drafts= out and reviewed.

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


--001a114d9d48d609c2054a289d31-- From nobody Tue Mar 7 11:21:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668F129483 for ; Tue, 7 Mar 2017 11:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRTr5gjukAFQ for ; Tue, 7 Mar 2017 11:21:34 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 B718112943D for ; Tue, 7 Mar 2017 11:21:34 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id i1so14355947ota.3 for ; Tue, 07 Mar 2017 11:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8pk24M4KIW+UogVMNJhrCY7cSQiAj7BxtU5ScbO5XGI=; b=beKLlcUo7rI65CEL+7QgzNuVQ0cnNTBsynUC7wyArlzcHuP6f6KFopsJxquOuGBBjg F7AlIsUs87jJrKNDH/QeiTZRBMdjZusbXqj628s85LmaP1IZDcqKFnnjb2HjY1h2UXsJ GWdmpThXu2ccdEycyd7Kw4deOQ3YmNeKgr15n2omG80xX1+MNOlS2AJYkt0zbGOaRlQ8 Mxva/g0rlp+tgJlFjF1VxKDtJ9sOmZDRw6veLpUGUynJSMnMCQpinDhFBmxn1g1NaiCp Zk2EqQuvVuo7o0SjhJhZCzv6HnJUsczpNTmC7PjGwpUmG3yLKZFQYwHIzxtRNNOmuPII LV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8pk24M4KIW+UogVMNJhrCY7cSQiAj7BxtU5ScbO5XGI=; b=t2IPxQniPrLnbqwGQKGuGD+E5cddW6C6uHigckEf5Axh4DjEXVNx840XgCvj0z1UtP BTCe/Yfv4QEQVF+dSxZ5t4sc/aWNbxq+tvjIkIRhuhl649P1SjltwGgH6EK2SZzPczb7 8bGra0w4FSq1ocXv46JWW1VdJpPJFMtzGXss4/SiMhHL5EpF2LG/tg1wzqZkLQpzo4ko J+m2kOlQPK+9OxSzmk93jjl7OyXIh09ksvd4XYhbjk+ISAS9qZtVpNCKG5REedm7Fehf oqns/XOfLZtHHnTcQMfN3JXZHIcfAgx/j+RVKhsSppcqu7jQNUiiqLJDDuwSdhV2CrUf wqLw== X-Gm-Message-State: AMke39kg5nEJMY4PgFobAcBRIuTMVr4UagLJixCv5DDsneIrPX8PG2+R//g/Ow0j0s9znBuJXagkw6Fsf3W/4w== X-Received: by 10.129.177.8 with SMTP id p8mr501109ywh.327.1488914493983; Tue, 07 Mar 2017 11:21:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 7 Mar 2017 11:20:53 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 7 Mar 2017 11:20:53 -0800 Message-ID: Subject: Re: Return of the alternate header proposal To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c13ce3883ec13054a28eb9d Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:21:36 -0000 --94eb2c13ce3883ec13054a28eb9d Content-Type: text/plain; charset=UTF-8 Hi Jana, I sent a bunch of comments in the PR. I think this is in the right direction, but I also have some concerns. To summarize my technical comments: - I don't think the key phase bit mechanism works correctly. - I'm not thrilled about having the packet # and conn id length depend on a per-packet basis. Why can't we negotiate these? Plus, I have a bunch of editorial comments. -Ekr On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar wrote: > Hi all, > > Based on the (very constructive) discussion around the previous alternate > header proposal > , I've > crafted PR #361 that > incorporates mailing-list feedback. This PR does not attempt to be the > final form of the header, but it hopes to be a significant way forward in > that direction. > > This PR closes a large number of issues. I'd like to get this merged into > the draft by the draft deadline (a week from now), with the understanding > that this format may still change as we discuss issues further. Please > read and provide feedback. > > The PR is a bit invasive and unfortunately large, so I'll summarize a few > salient points about it here. > > - The PR includes a header-form bit that allows easy distinction between > long and short headers. It also delineates version-independent fields from > version-specific ones. > > - The PR introduces use of Server-selected Connection ID, and specifies > rules for distinguishing it from the client-selected one. In summary, > server-selected Connection IDs are used for the final handshake packet > (ServerHello) and all subsequent packets. Everything before it uses the > client-selected Connection ID, including intermediate server handshake > packets (those carrying HelloRetryRequests). > > - Connection ID in a packet is available to a stateless load balancer: > always present in long headers and indicated via a CONNECTION_ID flag in > short headers. In all cases, the connection ID field is in the same > location. > > - Public Reset packets are required to include a Proof, but the proof is > TBD. > > Thanks, > - jana > --94eb2c13ce3883ec13054a28eb9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jana,

I sent a bunch of comments in = the PR. I think this is in the right direction, but I also
have s= ome concerns. To summarize my technical comments:

= - I don't think the key phase bit mechanism works correctly.
= - I'm not thrilled about having the packet # and conn id length depend = on a per-packet
=C2=A0 basis. Why can't we negotiate these?

Plus, I have a bunch of editorial comments.

-Ekr

On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar <jri@google.com= > wrote:
<= div>Hi all,

Based on the (very constructive) discu= ssion around the previous alternate header proposal= , I've crafted PR #361=C2=A0that incorporates mailing-list feedba= ck. This PR does not attempt to be the final form of the header, but it hop= es to be a significant way forward in that direction.

<= div>This PR closes a large number of issues. I'd like to get this merge= d into the draft by the draft deadline (a week from now), with the understa= nding that=C2=A0this format may still chan= ge as we discuss issues further. Please read and provide feedback.

The PR is a= bit invasive and unfortunately large, so I'll summarize a few salient = points about it here.=C2=A0

- The PR includes a he= ader-form bit that allows easy distinction between long and short headers. = It also delineates version-independent fields from version-specific ones.

- The PR introduces use of Server-selected Connecti= on ID, and specifies rules for distinguishing it from the client-selected o= ne. In summary, server-selected Connection IDs are used for the final hands= hake packet (ServerHello) and all subsequent packets. Everything before it = uses the client-selected Connection ID, including intermediate server hands= hake packets (those carrying HelloRetryRequests).

<= div>- Connection ID in a packet is available to a stateless load balancer: = always present in long headers and indicated via a CONNECTION_ID flag in sh= ort headers. In all cases, the connection ID field is in the same location.=

- Public Reset packets are required to include a = Proof, but the proof is TBD.

Thanks,
- j= ana

--94eb2c13ce3883ec13054a28eb9d-- From nobody Tue Mar 7 11:25:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90B12943D for ; Tue, 7 Mar 2017 11:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LTlJPBC7rPII for ; Tue, 7 Mar 2017 11:25:39 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CD112940F for ; Tue, 7 Mar 2017 11:25:39 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id x37so14603014ota.2 for ; Tue, 07 Mar 2017 11:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NCsEVWhQzKkfogV5GniRFk+i681t4YMHYgZxgqPkCeQ=; b=jahkd0+bgnM0pbhTwwP/GXPphED8hhPeEJ7Ejg4WI3ZtmY+ov3AHYIKiDbGhIEdgAw xaziwc3Wq4ddV0l5SvJwMb6PsmvdWolakYYxKhtBty9i0TODRMQWtVjWhzx2UkTvLMw8 HUn9Af3GcXy67eW4Vuj/vLMEDbV3uFE6fwfCVCGTeJEEh1dKf1Sth18dlUtzlPzfKbto oMTgnuNVasyUxnSR4+PbQRQfEjLUcsCNDAp3ucF91LoSRbXmBbdILiX2H+VVOqZjvM2+ E+q5gyCMLLE7cHGNU4tduWhdGQskjZVO9qKZxJunb0a/w+PP4935EY6olj+ZTXRCmCo2 EoKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NCsEVWhQzKkfogV5GniRFk+i681t4YMHYgZxgqPkCeQ=; b=tzWEM8Z02Hi5XUsDkuPpRji/AO/PQvJ9ScrwITsKB+hksAI9EHnCEKgU/T2F+WPLRK cuUazk5INMiG1Rgz94dzUfS3PJPVq1X/X3tOVD7Jb9DNd/CR9pAHyW5v34XTSlblglw/ 5dDKO1CvJS/lKUSZeJJFfLY3mWWkkvQI0jxJk4wYzs4GojdD+XpD7LpXIFKl1sfgdseS bwAHEkCqQzdZQpJ+oiuwoUfn8W5nBDl7X4bbWSSSCTe+pubao5V7dllgAvxKS8koEgKi MRkssmX78vNwdvp7fvBJRERaMd0YKb58g6Q6oWjgdvXwJ98gjEUOFKfHf16dPA5b5aqZ 7ovQ== X-Gm-Message-State: AMke39nH3fUqgpna7LwcKAj0lmIg2ItyvD2ngBy6SJW5q7OkpfR/cs+lCMpDaaZ1rkD92J54lIEbpeNrUmYkjayw X-Received: by 10.37.39.202 with SMTP id n193mr523138ybn.127.1488914738362; Tue, 07 Mar 2017 11:25:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Tue, 7 Mar 2017 11:25:17 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 7 Mar 2017 14:25:17 -0500 Message-ID: Subject: Re: Return of the alternate header proposal To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c13565c15140a054a28fa1b Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:25:41 -0000 --94eb2c13565c15140a054a28fa1b Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 2:20 PM, Eric Rescorla wrote: > Hi Jana, > > I sent a bunch of comments in the PR. I think this is in the right > direction, but I also > have some concerns. To summarize my technical comments: > > - I don't think the key phase bit mechanism works correctly. > - I'm not thrilled about having the packet # and conn id length depend on > a per-packet > basis. Why can't we negotiate these? > The major negative of negotiating the packet number length is that it makes it impossible for passive observers to know what the length is. Which would make monitoring and features such as packet number echo impractical. > > Plus, I have a bunch of editorial comments. > > -Ekr > > On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar wrote: > >> Hi all, >> >> Based on the (very constructive) discussion around the previous >> alternate header proposal >> , I've >> crafted PR #361 that >> incorporates mailing-list feedback. This PR does not attempt to be the >> final form of the header, but it hopes to be a significant way forward in >> that direction. >> >> This PR closes a large number of issues. I'd like to get this merged into >> the draft by the draft deadline (a week from now), with the understanding >> that this format may still change as we discuss issues further. Please >> read and provide feedback. >> >> The PR is a bit invasive and unfortunately large, so I'll summarize a few >> salient points about it here. >> >> - The PR includes a header-form bit that allows easy distinction between >> long and short headers. It also delineates version-independent fields from >> version-specific ones. >> >> - The PR introduces use of Server-selected Connection ID, and specifies >> rules for distinguishing it from the client-selected one. In summary, >> server-selected Connection IDs are used for the final handshake packet >> (ServerHello) and all subsequent packets. Everything before it uses the >> client-selected Connection ID, including intermediate server handshake >> packets (those carrying HelloRetryRequests). >> >> - Connection ID in a packet is available to a stateless load balancer: >> always present in long headers and indicated via a CONNECTION_ID flag in >> short headers. In all cases, the connection ID field is in the same >> location. >> >> - Public Reset packets are required to include a Proof, but the proof is >> TBD. >> >> Thanks, >> - jana >> > > --94eb2c13565c15140a054a28fa1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 7, 2017 at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi Jana,

I sent a bunch of comments in the PR. I think this is in the right direc= tion, but I also
have some concerns. To summarize my technical co= mments:

- I don't think the key phase bit mech= anism works correctly.
- I'm not thrilled about having the pa= cket # and conn id length depend on a per-packet
=C2=A0 basis. Wh= y can't we negotiate these?

The major negative of negotiating the packet number length is that it make= s it impossible for passive observers to know what the length is.=C2=A0 Whi= ch would make monitoring and features such as packet number echo impractica= l.
=C2=A0

Plus, I have a bunch of editorial comments.
-Ekr

On Mon, Mar 6, 2017 at 5= :16 PM, Jana Iyengar <jri@google.com> wrote:
Hi all,

Base= d on the (very constructive) discussion around the prev= ious alternate header proposal, I've crafted PR #361=C2=A0tha= t incorporates mailing-list feedback. This PR does not attempt to be the fi= nal form of the header, but it hopes to be a significant way forward in tha= t direction.

This PR closes a large number of issu= es. I'd like to get this merged into the draft by the draft deadline (a= week from now), with the understanding that=C2=A0this format may still change as we discuss issues further. Please r= ead and provide feedback.

The PR is a bit invasive and unfortunately large, so= I'll summarize a few salient points about it here.=C2=A0
- The PR includes a header-form bit that allows easy distinctio= n between long and short headers. It also delineates version-independent fi= elds from version-specific ones.

- The PR introduc= es use of Server-selected Connection ID, and specifies rules for distinguis= hing it from the client-selected one. In summary, server-selected Connectio= n IDs are used for the final handshake packet (ServerHello) and all subsequ= ent packets. Everything before it uses the client-selected Connection ID, i= ncluding intermediate server handshake packets (those carrying HelloRetryRe= quests).

- Connection ID in a packet is availa= ble to a stateless load balancer: always present in long headers and indica= ted via a CONNECTION_ID flag in short headers. In all cases, the connection= ID field is in the same location.

- Public Reset = packets are required to include a Proof, but the proof is TBD.
Thanks,
- jana


--94eb2c13565c15140a054a28fa1b-- From nobody Tue Mar 7 11:41:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19F812948F for ; Tue, 7 Mar 2017 11:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qNk5FS1o1vt7 for ; Tue, 7 Mar 2017 11:41:42 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BDB129426 for ; Tue, 7 Mar 2017 11:41:42 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id q7so13395915uaf.2 for ; Tue, 07 Mar 2017 11:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AwOk0zw0iRCfDykKbuILUdydwGArMoIS+g2U2zU3Hf0=; b=X6bynHw/33EcWkmeG6bNxMyfMNRZ0Wb3G9JKzD/S9aOgSDdUCt9/orsjvS9CLd31bL BG4SvIPaCbYccThsWdU7aXNcCp2cLA58O3Oy6ZYTgR7YRWaY3gCT9UlqXtqcsnUhZ3Zq NaFissBPiCtgeDDg/sQcnGHCwrizDulmqQtCZg8FleV4EITwdA0DADYltuJ+MzCPw8yX cLWDzT0q93ElC0kGnTct1IU4fL41K3RyikQ9OtErfnNb4OQh7Bld9ATqXECMnktRx2SK g3FNwVOs/auFieeAOEDfscbchcdhVPH3lEmxcuafCTGY1l+JPxEVmDK19nzmd5UvCozc VNsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AwOk0zw0iRCfDykKbuILUdydwGArMoIS+g2U2zU3Hf0=; b=l+x6uC1B/DdXH5INS/JBzTszUus0M1Z9n9ROuiwULG/gh8REuUvlCWL/FWylKSK/0/ KhRbs6EGu5Xac0r5JHB2xaHGcF/tZLQ127utPS1cIl2MtnuN/O6SuDweuMXEMe9op2GW maJDhs/5miwHzwNNwdsKKAn8iAibXz+JkgXEdnwaotT3rgegknb5YfhIdC9uglaM4m4L 7DzJpCZthksJvHWGE6Xlio0RJYQSAHQ4fjMz9YuNtAo8X/HVaT/p760Oe1y+JtSoouX1 zBopLTBvfJ5WC6eoxkrj3lXjAHhzGIKZqgF4MiXNIHyu5xFFpv8wBkqVok7JRXq9NaSd 4/vg== X-Gm-Message-State: AMke39mRnjGkE2a04DyOEj6PnUGosyKvjsH/3T5z7dM9A91m4WvHaUudiyb2hybLHp25K9C/A46UP0zmKuRycW/f X-Received: by 10.176.2.71 with SMTP id 65mr1151950uas.155.1488915699657; Tue, 07 Mar 2017 11:41:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 7 Mar 2017 11:41:39 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 7 Mar 2017 11:41:39 -0800 Message-ID: Subject: Re: Return of the alternate header proposal To: Ian Swett Content-Type: multipart/alternative; boundary=001a11428a36613da6054a2933a3 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:41:44 -0000 --001a11428a36613da6054a2933a3 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 7, 2017 at 11:25 AM, Ian Swett wrote: > On Tue, Mar 7, 2017 at 2:20 PM, Eric Rescorla wrote: > >> Hi Jana, >> >> I sent a bunch of comments in the PR. I think this is in the right >> direction, but I also >> > Thanks, will respond on PR. > have some concerns. To summarize my technical comments: >> >> - I don't think the key phase bit mechanism works correctly. >> > I'll take a look at your comments. > - I'm not thrilled about having the packet # and conn id length depend on >> a per-packet >> basis. Why can't we negotiate these? >> > > The major negative of negotiating the packet number length is that it > makes it impossible for passive observers to know what the length is. > Which would make monitoring and features such as packet number echo > impractical. > I'll add that without these bits, we need middleboxes (including load balancers) to look into the handshake stream frames to determine what's being negotiated. This means that we either require middleboxes to change if we change the stream frame or the handshake format in the future, or we make those bits version-independent. I also have concerns with middleboxes getting this parsing wrong, which can ossify bits inside the handshake stream frames in quite unfortunate ways. Plus, I have a bunch of editorial comments. >> > Thanks! Will take a look. - jana > -Ekr >> >> On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar wrote: >> >>> Hi all, >>> >>> Based on the (very constructive) discussion around the previous >>> alternate header proposal >>> , >>> I've crafted PR #361 that >>> incorporates mailing-list feedback. This PR does not attempt to be the >>> final form of the header, but it hopes to be a significant way forward in >>> that direction. >>> >>> This PR closes a large number of issues. I'd like to get this merged >>> into the draft by the draft deadline (a week from now), with the >>> understanding that this format may still change as we discuss issues >>> further. Please read and provide feedback. >>> >>> The PR is a bit invasive and unfortunately large, so I'll summarize a >>> few salient points about it here. >>> >>> - The PR includes a header-form bit that allows easy distinction between >>> long and short headers. It also delineates version-independent fields from >>> version-specific ones. >>> >>> - The PR introduces use of Server-selected Connection ID, and specifies >>> rules for distinguishing it from the client-selected one. In summary, >>> server-selected Connection IDs are used for the final handshake packet >>> (ServerHello) and all subsequent packets. Everything before it uses the >>> client-selected Connection ID, including intermediate server handshake >>> packets (those carrying HelloRetryRequests). >>> >>> - Connection ID in a packet is available to a stateless load balancer: >>> always present in long headers and indicated via a CONNECTION_ID flag in >>> short headers. In all cases, the connection ID field is in the same >>> location. >>> >>> - Public Reset packets are required to include a Proof, but the proof is >>> TBD. >>> >>> Thanks, >>> - jana >>> >> >> > --001a11428a36613da6054a2933a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 7, 2017 at 11:25 AM, Ian Swett <ianswett@google.com> wrote:
On Tue, Mar 7, 201= 7 at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi Jana,

I sent a bu= nch of comments in the PR. I think this is in the right direction, but I al= so

Thanks, will respond on PR.
=C2=A0
have some concerns. To summarize my technical comments:

- I don't think the key phase bit mechanism wor= ks correctly.

I'll take a look at your comments.
=C2= =A0
- I'm not thrilled about having the pack= et # and conn id length depend on a per-packet
=C2=A0 basis. Why = can't we negotiate these?

The major negative of negotiating the packet number length is that it= makes it impossible for passive observers to know what the length is.=C2= =A0 Which would make monitoring and features such as packet number echo imp= ractical.

I'll = add that without these bits, we need middleboxes (including load balancers)= to look into the handshake stream frames to determine what's being neg= otiated. This means that we either require middleboxes to change if we chan= ge the stream frame or the handshake format in the future, or we make those= bits version-independent.=C2=A0

I also have conce= rns with middleboxes getting this parsing wrong, which can ossify bits insi= de the handshake stream frames in quite unfortunate ways.

Plus, I have a bunch of editorial comments.
<= /div>

Thanks! Will take a look.

- jana

=C2=A0
-Ekr

On Mon, Mar 6, 2017 at 5:1= 6 PM, Jana Iyengar <jri@google.com> wrote:
Hi all,

Based = on the (very constructive) discussion around the previo= us alternate header proposal, I've crafted PR #361=C2=A0that = incorporates mailing-list feedback. This PR does not attempt to be the fina= l form of the header, but it hopes to be a significant way forward in that = direction.

This PR closes a large number of issues= . I'd like to get this merged into the draft by the draft deadline (a w= eek from now), with the understanding that=C2=A0this format may still change as we discuss issues further. Please rea= d and provide feedback.
<= br>
The PR is a bit invasive and unfortunately large, so I= 'll summarize a few salient points about it here.=C2=A0

<= /div>
- The PR includes a header-form bit that allows easy distinction = between long and short headers. It also delineates version-independent fiel= ds from version-specific ones.

- The PR introduces= use of Server-selected Connection ID, and specifies rules for distinguishi= ng it from the client-selected one. In summary, server-selected Connection = IDs are used for the final handshake packet (ServerHello) and all subsequen= t packets. Everything before it uses the client-selected Connection ID, inc= luding intermediate server handshake packets (those carrying HelloRetryRequ= ests).

- Connection ID in a packet is availabl= e to a stateless load balancer: always present in long headers and indicate= d via a CONNECTION_ID flag in short headers. In all cases, the connection I= D field is in the same location.

- Public Reset pa= ckets are required to include a Proof, but the proof is TBD.

=
Thanks,
- jana



--001a11428a36613da6054a2933a3-- From nobody Tue Mar 7 15:20:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF311295D9 for ; Tue, 7 Mar 2017 15:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PSH0cJP8Yee for ; Tue, 7 Mar 2017 15:20:34 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 0C1301295B7 for ; Tue, 7 Mar 2017 15:20:34 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id p64so32419563qke.1 for ; Tue, 07 Mar 2017 15:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nflUxM0AKDpR+pSaE28Jv3+nwLDz4M9vlDp4rdj+yA0=; b=PuTncPsFawId0gy0w0TrCX212U8p4aOJr3a1B/xE+MjXjNPW3FIJoO3NXcRjo/k3Fg o7BoObxk9kpLWVJscboIzHa548V4H0YZYjohubUv0uYlhersgV24mwKlMsX9bjXlFmqh ZQb8oNT2Zg645HLznhO4H2Gqu6Uh6Xp2eyuGZPrGKVRT/vLI4/8SRMt89Bh5trYEOceT x4V3+jFecrjcLbVYDRwhrckBXiCgZyJhaXHPdsWqtSTleP0pih/4BZwhKGx0IZhC6UT+ 6Z6ZnZFaPpdhDyJF2qJH39q+4OoUteXfIRcFiKlFT8FrncS3gRvUCJhTukwKFmEWs1v3 3oWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nflUxM0AKDpR+pSaE28Jv3+nwLDz4M9vlDp4rdj+yA0=; b=GNUytSDHtZpXCxEsIIBNf9KUWQN+mBOPFlxDpcLff7TaH35Kc8O5phE/R5AHSoC6Mz q9sTDlQIlSOxsyIGsG+N/bSs/7X/x8F6Y/fovntmGuL7ZSqipZtw8yP8sfHiA/R5FCnr PmFqp7RpI1sCOHcp19fqSSSlPGuOlqDl2Be9Ddz+AIyFf8ubYJXUMckxsVa6tFCLPUS8 fKAEkXcWJheDXU4sG+syEoZUxmFEWYSqlEf5zKtpr4Y44ct4iccDT3h0wmYLngJzWhKr XXgGOnnOZKwU/rhLPFBrJ7u6KOF+HW0oNAssjJ1eLqkJzlCmoPCI29fP+bndvfSALr8T f0ow== X-Gm-Message-State: AMke39lXmZHQUjxAesnDtwtrNmQH6lBMgU0laWXoUkfjerEl3IKdDRZduvZvJ7rVS9+X5uXTUpx4JNUiscbnHg== X-Received: by 10.200.33.210 with SMTP id 18mr3858968qtz.159.1488928833173; Tue, 07 Mar 2017 15:20:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 15:20:32 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Mar 2017 10:20:32 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ian Swett , IETF QUIC WG , Lucas Clemente , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 23:20:35 -0000 On 8 March 2017 at 03:58, Ted Hardie wrote: > > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson > wrote: >> >> I think that both are likely to run afoul of a simple problem in HTTP: >> the control stream (stream 3) can't be closed. >> > I don't think that's actually a problem with what I suggested. It simply > means that for the HTTP mapping, the defined behavior is to send > FIN_COMPLETE after all open requests and pushes complete. If it arrives > before then, you'd have to treat it as a protocol error for the mapping. > What I'm trying to avoid is baking in the requirement that FIN_COMPLETE (or > its moral equivalent) always occur then, since it will make using other > types Sure. I had inferred that you were doing this entirely at the transport layer, which doesn't really allow you to do that. From nobody Tue Mar 7 17:34:07 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA8D1294C0 for ; Tue, 7 Mar 2017 17:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjcZ2zn9RwSC for ; Tue, 7 Mar 2017 17:34:04 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68000129447 for ; Tue, 7 Mar 2017 17:34:04 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id p64so37852975qke.1 for ; Tue, 07 Mar 2017 17:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AQo4Bj1T2JuLGFUKfQazRGws1ZeQ4DxgP0mEXzxI9sU=; b=pQcLz+/BjkLw3359zQZOiLIZqc0nBf2bs25KrAiUXgQrILn/y2MU4rvTC9skXDVlrb 8KWcV1UqKsVxdAhkKshS9LOzNNzxdqgO4dQ809HWm7SiXlH6/4lq1MtNw327Yd5jgnlK FtHe9RPeWGPEWiWadGr9ih+I9gto00a1TB0qWVyCdrSAKEWGZSBnw0OWiKxo2yGkfjf+ 04Od7lbujFmZv93gUf7dyPP2lUbAVrVraFqu5H6Z46ceiip1CSP9YQpwlpmS8AVV3Y6d HxCjpYyxmVdGzbJKTjpwhiXiGR+Pr6bVFXcAz80NmXUqlra4mhimeQZMTemXsxy1Qxbr C/9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AQo4Bj1T2JuLGFUKfQazRGws1ZeQ4DxgP0mEXzxI9sU=; b=XHiIinpULVtdelcBx8xjYICdpENscfoAbLEZej0iOHIAngCBbjsh2r9sWfQXnGfH7Q 2s+o7fbLteAqGnyi5pCYtsD/aFcNdFse1C0aH/YJ/fEbLqBA7BOFJxsYbFDSyeClSQSm eA4eM4pTMBf3Zrp6A2Jpy8NzSSpWf+fN77kV0a0T8V4waiWs2s2fVPRnq8eP4C03yj49 GrHrgOUVGVY/MaI5hfLCV9siUucVjgEakUNeYj0CGeu4FJoSxN5j5s7npjCMCPPVBRMw l2MhbH1UL8I+szl3q9VI98+exdJQUdSvl6VoPuk55RIc8D1pWnBSyhf2wW5+6i3b9AYe 67+A== X-Gm-Message-State: AMke39nskbKHdIMhEwrR/ERbsesTsbgGoX8ajn6Euadhfz1gfX3E+FVRa9XFbwQkKAfG6awfwjsogZ1ItGYA2Q== X-Received: by 10.200.3.214 with SMTP id z22mr4752891qtg.3.1488936843557; Tue, 07 Mar 2017 17:34:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 17:34:03 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Mar 2017 12:34:03 +1100 Message-ID: Subject: Re: DISINTEREST frame To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:34:06 -0000 I think that this is a step in the right direction. We have use cases that this serves. On 8 March 2017 at 05:45, Mike Bishop wrote: > At the Tokyo interim, we had a discussion around Issue #165, PR #171 > proposing a REQUEST_RST frame, and the fact that Google QUIC currently > special-cases the same semantics to a RST_STREAM with a specific error co= de. > (There is a TODO in the text to write up this =E2=80=9Cspecial case.=E2= =80=9D) My sense of > the consensus at the interim was that special casing particular error cod= es > felt hacky, and there was moderate support for making it a different fram= e > type altogether, but people wanted to look at the PR in more detail. > > > > At Martin=E2=80=99s suggestion, the frame in the PR has been renamed to D= ISINTEREST. > It=E2=80=99s an explicit signal that incoming data is not being read by t= he > application and will be discarded by the transport upon receipt; the > receiver of a DISINTEREST frame is suggested to abruptly terminate the > stream in question. In terms of application API, think of it as the wire > signal that the read handle has been closed. > > > > I think this should explicitly not be a special case of a RST_STREAM erro= r > code, because it has different semantics around retransmissions. In > particular, the sender of a DISINTEREST frame might still be sending data= , > still be retransmitting lost STREAM frames, and still expecting that data= to > be consumed. A special case around whether to process the incoming data,= I > could accept; a special case around whether retransmission is still enabl= ed > on the stream feels really wrong. > > > > In order to enable this, the PR changes the semantics of RST_STREAM as we= ll. > Streams consist of a data channel in each direction. That data channel c= an > be closed cleanly (FIN) or abruptly (RST_STREAM) in each direction. If > cleanly, data gets retransmitted in that direction. If abruptly, nothing > more will be sent, whether it got through or not. Only the sender can cl= ose > their data channel, and only they decide how and when it closes. (Though > DISINTEREST is a strong signal there=E2=80=99s no point in continuing to = transmit.) > > > > In Tokyo, we said we wanted to wait while folks reviewed the PR. We=E2= =80=99ve had > a month, and I=E2=80=99ve gotten some good feedback from one more person = (thanks, > Lucas!). Have people reviewed and are okay with it? Have people not loo= ked > and violently disagree? If so, let=E2=80=99s discuss. We still have a f= ew days > before the draft deadline; maybe we can reach consensus before -02? From nobody Tue Mar 7 18:40:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74F8128B37 for ; Tue, 7 Mar 2017 18:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 TgvX9Dx2uxso for ; Tue, 7 Mar 2017 18:40:20 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8E6120724 for ; Tue, 7 Mar 2017 18:40:19 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id g10so14070904wrg.2 for ; Tue, 07 Mar 2017 18:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x4p0uIJKPUjWXSmEE3yfy8BtMxPTWc8mB5ol9AGME7k=; b=VP0KijbkSUrKyUW5irBLv6by9DRliEzwknay+0qrio6Y9J7S3wgp/bUuBmS9GOccUj JrX8Isr+XRJiaT7ZlRAg8m2llckFmDk4Q+YcpXbkx4qdGbNkf5sR/BVv9UoTwHjOt1SQ 7XvP9MPA6DrVr/C3TQnGekwzIafQSTrZC36AEh6BeOa8sJVzPielzJKqzwfN8KnOfq76 pW7QbUOo7VTqk2OmgmDuWYkKL03/i6SSZkhsn4775Z4y4BxL8U+A2A4CdPHADXJpdB/h rGuYZZaHH8K4r48rjemPS7LO6+ou0o9AYmVOa4kURRBHEG+Ba4pBZtbyz/HLbo/wPTs/ pcDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x4p0uIJKPUjWXSmEE3yfy8BtMxPTWc8mB5ol9AGME7k=; b=fKulK3QA4wAlk6bGZOhwMWqNFq8oUu5xzopXBhmTY0XRfy0y491ojHY/Pyha68Vu5D 7bmbIVPH5UZd91tymG5HgANhB9/hNNNViOvZrNp84zFca+QfIHKhl3bjjso/4+UOKL7G 93BdsL25GhJFpcncNKVcE57f6VVAP7EUn9vplU/X2YeU5KqDLrE7aKoABVBp722m9GJI AuR+yA2J7r8hFDtW8D1o5A321jgaMyIKkDgUQ9BP1WLNpwCuWmXb7aD9fukoLgycKzcJ CauTfzRgv8YSJU5ooXsC4r01K0BUN8ySCGlJ4HDF2hne8qUJQTfnqn+qmRGp2nMRMxyj 7rGw== X-Gm-Message-State: AMke39kKqEq+iZVfYTXF6pj0bkA+ld03x/clSmHKYGptuxSPgHPi8PMrhgcXyzJJg2xf5u4C1LOPprSzrwRmAmfL X-Received: by 10.223.163.21 with SMTP id c21mr2756892wrb.115.1488940818011; Tue, 07 Mar 2017 18:40:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.19.7 with HTTP; Tue, 7 Mar 2017 18:40:17 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Tue, 7 Mar 2017 18:40:17 -0800 Message-ID: Subject: Re: DISINTEREST frame To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045f1a5c8cf035054a2f0cfd Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:40:21 -0000 --f403045f1a5c8cf035054a2f0cfd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds reasonable to me. We should also clarify the impact it has on flow-control. I assume that since the sender of such a frame will not be reading, the receiver of the frame (and the sender of data) needs to stop sending since it will not be receiving flow control updates. We'll also want to clarify the HTTP mapping since HTTP/2 defines the RST_STREAM + NO_ERROR semantics that is leveraged in the current QUIC doc. But these are both minor points. On Tue, Mar 7, 2017 at 5:34 PM, Martin Thomson wrote: > I think that this is a step in the right direction. We have use cases > that this serves. > > On 8 March 2017 at 05:45, Mike Bishop > wrote: > > At the Tokyo interim, we had a discussion around Issue #165, PR #171 > > proposing a REQUEST_RST frame, and the fact that Google QUIC currently > > special-cases the same semantics to a RST_STREAM with a specific error > code. > > (There is a TODO in the text to write up this =E2=80=9Cspecial case.=E2= =80=9D) My sense > of > > the consensus at the interim was that special casing particular error > codes > > felt hacky, and there was moderate support for making it a different > frame > > type altogether, but people wanted to look at the PR in more detail. > > > > > > > > At Martin=E2=80=99s suggestion, the frame in the PR has been renamed to > DISINTEREST. > > It=E2=80=99s an explicit signal that incoming data is not being read by= the > > application and will be discarded by the transport upon receipt; the > > receiver of a DISINTEREST frame is suggested to abruptly terminate the > > stream in question. In terms of application API, think of it as the wi= re > > signal that the read handle has been closed. > > > > > > > > I think this should explicitly not be a special case of a RST_STREAM > error > > code, because it has different semantics around retransmissions. In > > particular, the sender of a DISINTEREST frame might still be sending > data, > > still be retransmitting lost STREAM frames, and still expecting that > data to > > be consumed. A special case around whether to process the incoming > data, I > > could accept; a special case around whether retransmission is still > enabled > > on the stream feels really wrong. > > > > > > > > In order to enable this, the PR changes the semantics of RST_STREAM as > well. > > Streams consist of a data channel in each direction. That data channel > can > > be closed cleanly (FIN) or abruptly (RST_STREAM) in each direction. If > > cleanly, data gets retransmitted in that direction. If abruptly, nothi= ng > > more will be sent, whether it got through or not. Only the sender can > close > > their data channel, and only they decide how and when it closes. (Thou= gh > > DISINTEREST is a strong signal there=E2=80=99s no point in continuing t= o > transmit.) > > > > > > > > In Tokyo, we said we wanted to wait while folks reviewed the PR. We=E2= =80=99ve > had > > a month, and I=E2=80=99ve gotten some good feedback from one more perso= n (thanks, > > Lucas!). Have people reviewed and are okay with it? Have people not > looked > > and violently disagree? If so, let=E2=80=99s discuss. We still have a= few days > > before the draft deadline; maybe we can reach consensus before -02? > > --f403045f1a5c8cf035054a2f0cfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds reasonable to me. We should also clarify the impact= it has on flow-control. I assume that since the sender of such a frame wil= l not be reading, the receiver of the frame (and the sender of data) needs = to stop sending since it will not be receiving flow control updates.
<= div class=3D"gmail_default" style=3D"font-family:trebuchet ms,sans-serif"><= br>
We'll also want to clarify the HTTP mapping since HTTP/2 defin= es the RST_STREAM + NO_ERROR semantics that is leveraged in the current QUI= C doc.

But these are both minor points.

On Tue, Mar 7, 2017 at 5:3= 4 PM, Martin Thomson <martin.thomson@gmail.com> wrote= :
I think that this is a step in the righ= t direction.=C2=A0 We have use cases
that this serves.

On 8 March 2017 at 05:45, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> At the Tokyo interim, we had a discussion around Issue #165, PR #171 > proposing a REQUEST_RST frame, and the fact that Google QUIC currently=
> special-cases the same semantics to a RST_STREAM with a specific error= code.
> (There is a TODO in the text to write up this =E2=80=9Cspecial case.= =E2=80=9D)=C2=A0 My sense of
> the consensus at the interim was that special casing particular error = codes
> felt hacky, and there was moderate support for making it a different f= rame
> type altogether, but people wanted to look at the PR in more detail. >
>
>
> At Martin=E2=80=99s suggestion, the frame in the PR has been renamed t= o DISINTEREST.
> It=E2=80=99s an explicit signal that incoming data is not being read b= y the
> application and will be discarded by the transport upon receipt; the > receiver of a DISINTEREST frame is suggested to abruptly terminate the=
> stream in question.=C2=A0 In terms of application API, think of it as = the wire
> signal that the read handle has been closed.
>
>
>
> I think this should explicitly not be a special case of a RST_STREAM e= rror
> code, because it has different semantics around retransmissions.=C2=A0= In
> particular, the sender of a DISINTEREST frame might still be sending d= ata,
> still be retransmitting lost STREAM frames, and still expecting that d= ata to
> be consumed.=C2=A0 A special case around whether to process the incomi= ng data, I
> could accept; a special case around whether retransmission is still en= abled
> on the stream feels really wrong.
>
>
>
> In order to enable this, the PR changes the semantics of RST_STREAM as= well.
> Streams consist of a data channel in each direction.=C2=A0 That data c= hannel can
> be closed cleanly (FIN) or abruptly (RST_STREAM) in each direction.=C2= =A0 If
> cleanly, data gets retransmitted in that direction.=C2=A0 If abruptly,= nothing
> more will be sent, whether it got through or not.=C2=A0 Only the sende= r can close
> their data channel, and only they decide how and when it closes.=C2=A0= (Though
> DISINTEREST is a strong signal there=E2=80=99s no point in continuing = to transmit.)
>
>
>
> In Tokyo, we said we wanted to wait while folks reviewed the PR.=C2=A0= We=E2=80=99ve had
> a month, and I=E2=80=99ve gotten some good feedback from one more pers= on (thanks,
> Lucas!).=C2=A0 Have people reviewed and are okay with it?=C2=A0 Have p= eople not looked
> and violently disagree?=C2=A0 If so, let=E2=80=99s discuss.=C2=A0 We s= till have a few days
> before the draft deadline; maybe we can reach consensus before -02?

--f403045f1a5c8cf035054a2f0cfd-- From nobody Tue Mar 7 18:53:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0238F128B37 for ; Tue, 7 Mar 2017 18:53:07 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 EQw8D15a42YM for ; Tue, 7 Mar 2017 18:53:05 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 1CCE6129532 for ; Tue, 7 Mar 2017 18:53:04 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id p64so40822856qke.1 for ; Tue, 07 Mar 2017 18:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YpHkKgh6LQ8fGIy0ZqxooKrJ3Gcu8uewFqt10Ile4pQ=; b=DxP2eH1hFYoZqFYUE9VhNu9axfOSBDkDEMDyY3OC4YxCJNhSjMMXA2GGIPyAVFUslO qS2yuxXai+Ftqmi7w0x8DzJOV+Gq5wKgKi50Du4B25jrx5SmwrTgTRLyq2Hp12UCJwMB iX5ToqCnOMViB48XRz/M121mXZXrOcej75CqY2vpRsJEyN/qwZUhryqYkk7cdxXdFiMw d4IAyyeP4w/A5+DLTfR268Uyg2thda1dCHJoeQVmZeh48/Hwb/5TpsvaibfxERr9mLC7 6jK7chgu6eLjmLSViic2zzwpMMK6lhmdbtqRJS3f0RKb5XfHAuM3ALVZqlUsjvIcKrLQ FLUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YpHkKgh6LQ8fGIy0ZqxooKrJ3Gcu8uewFqt10Ile4pQ=; b=q4uAjocdNua5c62oM83CpocirFZtr4tDQKTv02IAB/tP2BbS4VU+50YCXuMda+AtJR VbhYrQAtgqKK5DEH3iZc+2kzqn3L1HRSyVPyVaRw9Jc0FCeFDgabBdN1e/WTSJYM0u39 1w2OvD2Kkaj66YkWFpQVjMfz/6OG8frJ/xyouzGvd7CgtaHKHV2727Y8wrwQI0Xp59nX g0Mwj+l9xdalQ4r2AuoB7nmzVnCYNHpvGRAqpPRznSf10GNb3Np/ua1euQyWDRCNDx6d rWv9FaEcA2ROOTAsFyeDajk6ox5bHrIpZQmY+6YmipeEexq84XvgkUshiW7/ErsKjb5j RGsA== X-Gm-Message-State: AMke39mhbp+KEDTH+sXidxBUfgijoJyIClbwagFTSdAKQ5XWahL6DrpM/ySsNDlvqUQfYKvdjPkZvbI8gkvQA6cK X-Received: by 10.37.223.20 with SMTP id w20mr859310ybg.129.1488941582966; Tue, 07 Mar 2017 18:53:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Tue, 7 Mar 2017 18:52:42 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 7 Mar 2017 21:52:42 -0500 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0880cc254c03054a2f3a4e Archived-At: Cc: Ted Hardie , IETF QUIC WG , Lucas Clemente , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:53:07 -0000 --94eb2c0880cc254c03054a2f3a4e Content-Type: text/plain; charset=UTF-8 After thinking about it more, if no one else has objections to "Make every application implement their own graceful close if they need it and only provide a way to kill the connection immediately.", I'm fine with it as well. On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson wrote: > On 8 March 2017 at 03:58, Ted Hardie wrote: > > > > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson > > > wrote: > >> > >> I think that both are likely to run afoul of a simple problem in HTTP: > >> the control stream (stream 3) can't be closed. > >> > > I don't think that's actually a problem with what I suggested. It simply > > means that for the HTTP mapping, the defined behavior is to send > > FIN_COMPLETE after all open requests and pushes complete. If it arrives > > before then, you'd have to treat it as a protocol error for the mapping. > > What I'm trying to avoid is baking in the requirement that FIN_COMPLETE > (or > > its moral equivalent) always occur then, since it will make using other > > types > > Sure. I had inferred that you were doing this entirely at the > transport layer, which doesn't really allow you to do that. > --94eb2c0880cc254c03054a2f3a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After thinking about it more, if no one else has objection= s to "Make every application implement their own graceful close if the= y need it and only provide a way to kill the connection immediately.",= I'm fine with it as well.

On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 8 March 2017 at 03:58, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> I think that both are likely to run afoul of a simple problem in H= TTP:
>> the control stream (stream 3) can't be closed.
>>
> I don't think that's actually a problem with what I suggested.= =C2=A0 It simply
> means that for the HTTP mapping, the defined behavior is to send
> FIN_COMPLETE after all open requests and pushes complete.=C2=A0 If it = arrives
> before then, you'd have to treat it as a protocol error for the ma= pping.
> What I'm trying to avoid is baking in the requirement that FIN_COM= PLETE (or
> its moral equivalent) always occur then, since it will make using othe= r
> types

Sure.=C2=A0 I had inferred that you were doing this entirely at the<= br> transport layer, which doesn't really allow you to do that.

--94eb2c0880cc254c03054a2f3a4e-- From nobody Tue Mar 7 19:01:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52180129400 for ; Tue, 7 Mar 2017 19:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 oUCWNbXV2pIu for ; Tue, 7 Mar 2017 19:01:20 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id AA3A6128B37 for ; Tue, 7 Mar 2017 19:01:20 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0AF8D16C86C; Wed, 8 Mar 2017 03:01:20 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id DF41D16C859; Wed, 8 Mar 2017 03:01:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488942079; bh=GrjHBsekEnmBmOCIDJlpxrvWF0vLpXsGwvk+Ts0nE+0=; l=4492; h=From:To:CC:Date:References:In-Reply-To:From; b=v0kuQaX/1o6l6u5HElktnZD91FagTBeGOzmaQIeiMsRHz2P8C9xSgxfSLBDF1rM7c hfWQR/c2WmhFZJwAZzKpwD1z9c6XMwCfgDI9WzJMeTc7MfGta6GI8IWxKiQQG80So0 MB2/M+0pmhNeVRW2U1wg1aqaY4NRZtIG9o4a1jhA= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id BA06E98084; Wed, 8 Mar 2017 03:01:19 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Mar 2017 22:01:19 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Mar 2017 22:01:19 -0500 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.1178.000; Tue, 7 Mar 2017 22:01:18 -0500 From: "Lubashev, Igor" To: Martin Thomson , Mike Bishop Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AA= Date: Wed, 8 Mar 2017 03:01:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:01:22 -0000 QSBtaW5vciBwb2ludC4NCg0KKyBbLi4uXSBJZiB0aGUgRElTSU5URVJFU1QgZnJhbWUgaXMgcmVj ZWl2ZWQgb24gYQ0KK3N0cmVhbSB0aGF0IGlzIGFscmVhZHkgaW4gdGhlICJoYWxmLWNsb3NlZCAo bG9jYWwpIiBvciAiY2xvc2VkIiBzdGF0ZXMsIGENCitSU1RfU1RSRUFNIGZyYW1lIFNIT1VMRCBz dGlsbCBiZSBzZW50DQoNCldoYXQgaWYgdGhlIHNlbmRlciBhbHJlYWR5IHJlY2VpdmVkIGFuIEFD SyBmb3IgYSBwYWNrZXQgdGhhdCBjb250YWluZWQgRklOIG9yIFJTVF9TVFJFQU0gZm9yIHRoYXQg c3RyZWFtPyAgSXMgdGhlIHJlY29tbWVuZGF0aW9uIHN0aWxsICJTSE9VTEQgc2VuZCBSU1RfU1RS RUFNIj8gKFRoaXMgY2FuIGhhcHBlbiBpbiBjYXNlIG9mIHBhY2tldCByZW9yZGVyaW5nLikNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgTWFyY2ggMDcsIDIw MTcgODozNCBQTQ0KVG86IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBESVNJTlRF UkVTVCBmcmFtZQ0KDQpJIHRoaW5rIHRoYXQgdGhpcyBpcyBhIHN0ZXAgaW4gdGhlIHJpZ2h0IGRp cmVjdGlvbi4gIFdlIGhhdmUgdXNlIGNhc2VzIHRoYXQgdGhpcyBzZXJ2ZXMuDQoNCk9uIDggTWFy Y2ggMjAxNyBhdCAwNTo0NSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b20+IHdyb3RlOg0KPiBBdCB0aGUgVG9reW8gaW50ZXJpbSwgd2UgaGFkIGEgZGlzY3Vzc2lvbiBh cm91bmQgSXNzdWUgIzE2NSwgUFIgIzE3MSANCj4gcHJvcG9zaW5nIGEgUkVRVUVTVF9SU1QgZnJh bWUsIGFuZCB0aGUgZmFjdCB0aGF0IEdvb2dsZSBRVUlDIGN1cnJlbnRseSANCj4gc3BlY2lhbC1j YXNlcyB0aGUgc2FtZSBzZW1hbnRpY3MgdG8gYSBSU1RfU1RSRUFNIHdpdGggYSBzcGVjaWZpYyBl cnJvciBjb2RlLg0KPiAoVGhlcmUgaXMgYSBUT0RPIGluIHRoZSB0ZXh0IHRvIHdyaXRlIHVwIHRo aXMg4oCcc3BlY2lhbCBjYXNlLuKAnSkgIE15IA0KPiBzZW5zZSBvZiB0aGUgY29uc2Vuc3VzIGF0 IHRoZSBpbnRlcmltIHdhcyB0aGF0IHNwZWNpYWwgY2FzaW5nIA0KPiBwYXJ0aWN1bGFyIGVycm9y IGNvZGVzIGZlbHQgaGFja3ksIGFuZCB0aGVyZSB3YXMgbW9kZXJhdGUgc3VwcG9ydCBmb3IgDQo+ IG1ha2luZyBpdCBhIGRpZmZlcmVudCBmcmFtZSB0eXBlIGFsdG9nZXRoZXIsIGJ1dCBwZW9wbGUg d2FudGVkIHRvIGxvb2sgYXQgdGhlIFBSIGluIG1vcmUgZGV0YWlsLg0KPg0KPg0KPg0KPiBBdCBN YXJ0aW7igJlzIHN1Z2dlc3Rpb24sIHRoZSBmcmFtZSBpbiB0aGUgUFIgaGFzIGJlZW4gcmVuYW1l ZCB0byBESVNJTlRFUkVTVC4NCj4gSXTigJlzIGFuIGV4cGxpY2l0IHNpZ25hbCB0aGF0IGluY29t aW5nIGRhdGEgaXMgbm90IGJlaW5nIHJlYWQgYnkgdGhlIA0KPiBhcHBsaWNhdGlvbiBhbmQgd2ls bCBiZSBkaXNjYXJkZWQgYnkgdGhlIHRyYW5zcG9ydCB1cG9uIHJlY2VpcHQ7IHRoZSANCj4gcmVj ZWl2ZXIgb2YgYSBESVNJTlRFUkVTVCBmcmFtZSBpcyBzdWdnZXN0ZWQgdG8gYWJydXB0bHkgdGVy bWluYXRlIHRoZSANCj4gc3RyZWFtIGluIHF1ZXN0aW9uLiAgSW4gdGVybXMgb2YgYXBwbGljYXRp b24gQVBJLCB0aGluayBvZiBpdCBhcyB0aGUgDQo+IHdpcmUgc2lnbmFsIHRoYXQgdGhlIHJlYWQg aGFuZGxlIGhhcyBiZWVuIGNsb3NlZC4NCj4NCj4NCj4NCj4gSSB0aGluayB0aGlzIHNob3VsZCBl eHBsaWNpdGx5IG5vdCBiZSBhIHNwZWNpYWwgY2FzZSBvZiBhIFJTVF9TVFJFQU0gDQo+IGVycm9y IGNvZGUsIGJlY2F1c2UgaXQgaGFzIGRpZmZlcmVudCBzZW1hbnRpY3MgYXJvdW5kIHJldHJhbnNt aXNzaW9ucy4gIA0KPiBJbiBwYXJ0aWN1bGFyLCB0aGUgc2VuZGVyIG9mIGEgRElTSU5URVJFU1Qg ZnJhbWUgbWlnaHQgc3RpbGwgYmUgDQo+IHNlbmRpbmcgZGF0YSwgc3RpbGwgYmUgcmV0cmFuc21p dHRpbmcgbG9zdCBTVFJFQU0gZnJhbWVzLCBhbmQgc3RpbGwgDQo+IGV4cGVjdGluZyB0aGF0IGRh dGEgdG8gYmUgY29uc3VtZWQuICBBIHNwZWNpYWwgY2FzZSBhcm91bmQgd2hldGhlciB0byANCj4g cHJvY2VzcyB0aGUgaW5jb21pbmcgZGF0YSwgSSBjb3VsZCBhY2NlcHQ7IGEgc3BlY2lhbCBjYXNl IGFyb3VuZCANCj4gd2hldGhlciByZXRyYW5zbWlzc2lvbiBpcyBzdGlsbCBlbmFibGVkIG9uIHRo ZSBzdHJlYW0gZmVlbHMgcmVhbGx5IHdyb25nLg0KPg0KPg0KPg0KPiBJbiBvcmRlciB0byBlbmFi bGUgdGhpcywgdGhlIFBSIGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiBSU1RfU1RSRUFNIGFzIHdl bGwuDQo+IFN0cmVhbXMgY29uc2lzdCBvZiBhIGRhdGEgY2hhbm5lbCBpbiBlYWNoIGRpcmVjdGlv bi4gIFRoYXQgZGF0YSANCj4gY2hhbm5lbCBjYW4gYmUgY2xvc2VkIGNsZWFubHkgKEZJTikgb3Ig YWJydXB0bHkgKFJTVF9TVFJFQU0pIGluIGVhY2ggDQo+IGRpcmVjdGlvbi4gIElmIGNsZWFubHks IGRhdGEgZ2V0cyByZXRyYW5zbWl0dGVkIGluIHRoYXQgZGlyZWN0aW9uLiAgSWYgDQo+IGFicnVw dGx5LCBub3RoaW5nIG1vcmUgd2lsbCBiZSBzZW50LCB3aGV0aGVyIGl0IGdvdCB0aHJvdWdoIG9y IG5vdC4gIA0KPiBPbmx5IHRoZSBzZW5kZXIgY2FuIGNsb3NlIHRoZWlyIGRhdGEgY2hhbm5lbCwg YW5kIG9ubHkgdGhleSBkZWNpZGUgaG93IA0KPiBhbmQgd2hlbiBpdCBjbG9zZXMuICAoVGhvdWdo IERJU0lOVEVSRVNUIGlzIGEgc3Ryb25nIHNpZ25hbCB0aGVyZeKAmXMgbm8gDQo+IHBvaW50IGlu IGNvbnRpbnVpbmcgdG8gdHJhbnNtaXQuKQ0KPg0KPg0KPg0KPiBJbiBUb2t5bywgd2Ugc2FpZCB3 ZSB3YW50ZWQgdG8gd2FpdCB3aGlsZSBmb2xrcyByZXZpZXdlZCB0aGUgUFIuICANCj4gV2XigJl2 ZSBoYWQgYSBtb250aCwgYW5kIEnigJl2ZSBnb3R0ZW4gc29tZSBnb29kIGZlZWRiYWNrIGZyb20g b25lIG1vcmUgDQo+IHBlcnNvbiAodGhhbmtzLCBMdWNhcyEpLiAgSGF2ZSBwZW9wbGUgcmV2aWV3 ZWQgYW5kIGFyZSBva2F5IHdpdGggaXQ/ICANCj4gSGF2ZSBwZW9wbGUgbm90IGxvb2tlZCBhbmQg dmlvbGVudGx5IGRpc2FncmVlPyAgSWYgc28sIGxldOKAmXMgZGlzY3Vzcy4gIA0KPiBXZSBzdGls bCBoYXZlIGEgZmV3IGRheXMgYmVmb3JlIHRoZSBkcmFmdCBkZWFkbGluZTsgbWF5YmUgd2UgY2Fu IHJlYWNoIGNvbnNlbnN1cyBiZWZvcmUgLTAyPw0KDQo= From nobody Tue Mar 7 19:16:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA89F129469 for ; Tue, 7 Mar 2017 19:16:48 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 56di8p9_ajgX for ; Tue, 7 Mar 2017 19:16:46 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6C9129410 for ; Tue, 7 Mar 2017 19:16:46 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id t8so2872082vke.3 for ; Tue, 07 Mar 2017 19:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0rjbMRqGVAqHbYIDshhsjd63Nf/5OjIDakisnqiePuU=; b=BOXH9nvTJiiEDp/11ZvGlFhdMYUno7HimZKBNEXdpjjgoeob+6j/xhrekCurXhJ+QY +0gdMXGOFfA8HZqu1PqaLG6prAe+hq1lqsiCyNNGwZ6eRX8cH1f92G+ujBKdWLBKVP2C a3Fsp9NGFSUo13vM6yecm8WPZVvaxXe0EguqJ9TFSDgUdp20EzmN2OxuhtBZc3loU1if Kmd0N04VMUE9uQC4f9adWtErCorE9J2QE1OMNIJkFyrY3K++aW9xXqSV6zjZwCwWYmpL owDt9t3tMIFSV8gSkI2oaawvvvZ28wNcHkOayqzZJVD8iKJEUxvPYPsPEMbJv+kVIxP8 dFcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0rjbMRqGVAqHbYIDshhsjd63Nf/5OjIDakisnqiePuU=; b=ZL04LdriYzyR75GEBSyCS0QhjGw1PvkJJQo2MgTM6XmlvigNw3npKBjEl72Riyi6gn kpM/idfaC7JjSWYOAyK9ovxX+Fu2v1/WsLjb4bbZvW2ME7Qgu3KnFVQZ52gXbsljIpWC GE6lJ4G+hfVYTtbbd0zenGMi8+hDK4hkA/OxGZSLH80VW18pAkAwFUGao1qUE34YGQkx qzFOJWxJEuhsB/YVbTyZOClagquCXtXVdvcXG06wCwa9buAsbV8om4kYDP7inNeV4pJ8 SJqH7PJm/mqFUog7oLm7a6p/suwVgNu8gA4a8YEsWp2bYr8bqM9nam05kwnfTGdpXosz vwBw== X-Gm-Message-State: AMke39lBGgvWEFwl39GJgjjMIPBG5yG09NVt3+xgUE9DBpmWhSvI6cXBNbNKlFdB+fD7lVci/Q34vEIdNis0du+f X-Received: by 10.31.125.12 with SMTP id y12mr2336876vkc.161.1488943004881; Tue, 07 Mar 2017 19:16:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 7 Mar 2017 19:16:44 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 7 Mar 2017 19:16:44 -0800 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c14c356e5eab0054a2f8eee Archived-At: Cc: Lucas Clemente , Ted Hardie , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:16:49 -0000 --94eb2c14c356e5eab0054a2f8eee Content-Type: text/plain; charset=UTF-8 After chatting with Martin offline, it's growing on me as well. The key insights in my mind are: 1. It's preferable for each endpoint to indicate the streams it is closing, to avoid requiring upper-layer retries of new streams in flight. 2. The semantics of stream creation are different for different apps. HTTP generally has the client creating a stream and the server responds on the same stream. A different application can have very different client-server interactions. For instance, a client creates a stream which requires a a server to create multiple streams in response, which in turn require further client stream creations. In this case, QUIC has no idea what the "last" stream ought to be, and this needs to be indicated by the application. 3. Since in the general case the app protocol is expected to be involved in figuring out what graceful close looks like, it makes sense to define it per app. In other words, make it part of the app mapping to QUIC. For HTTP, this would be a GOAWAY frame on Stream 3. Once all streams are closed, HTTP closes Stream 3. 4. Graceful close by the app means that the QUIC connection can immediately go into TIME_WAIT on a connection close from the app. It is a clean separation of concerns for sure. I'd like to ruminate on this a bit, since sometimes that helps. This seems like good fodder for Chicago. On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett wrote: > After thinking about it more, if no one else has objections to "Make every > application implement their own graceful close if they need it and only > provide a way to kill the connection immediately.", I'm fine with it as > well. > > On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson > wrote: > >> On 8 March 2017 at 03:58, Ted Hardie wrote: >> > >> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson < >> martin.thomson@gmail.com> >> > wrote: >> >> >> >> I think that both are likely to run afoul of a simple problem in HTTP: >> >> the control stream (stream 3) can't be closed. >> >> >> > I don't think that's actually a problem with what I suggested. It >> simply >> > means that for the HTTP mapping, the defined behavior is to send >> > FIN_COMPLETE after all open requests and pushes complete. If it arrives >> > before then, you'd have to treat it as a protocol error for the mapping. >> > What I'm trying to avoid is baking in the requirement that FIN_COMPLETE >> (or >> > its moral equivalent) always occur then, since it will make using other >> > types >> >> Sure. I had inferred that you were doing this entirely at the >> transport layer, which doesn't really allow you to do that. >> > > --94eb2c14c356e5eab0054a2f8eee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After chatting with Martin offline, it's growing on me= as well. The key insights in my mind are:

1. It's p= referable for each endpoint to indicate the streams it is closing, to avoid= requiring upper-layer retries of new streams in flight.

2. The semantics of stream creation are different for different apps= . HTTP generally has the client creating a stream and the server responds o= n the same stream. A different application can have very different client-s= erver interactions. For instance, a client creates a stream which requires = a a server to create multiple streams in response, which in turn require fu= rther client stream creations. In this case, QUIC has no idea what the &quo= t;last" stream ought to be, and this needs to be indicated by the appl= ication.

3. Since in the general case the app prot= ocol is expected to be involved in figuring out what graceful close looks l= ike, it makes sense to define it per app. In other words, make it part of t= he app mapping to QUIC. For HTTP, this would be a GOAWAY frame on Stream 3.= Once all streams are closed, HTTP closes Stream 3.

4. Graceful close by the app means that the QUIC connection can immediate= ly go into TIME_WAIT on a connection close from the app.

It is a clean separation of concerns for sure. I'd like to rumin= ate on this a bit, since sometimes that helps.=C2=A0

This seems like good fodder for Chicago.

On Tue, Mar 7, 2017 at 6:52 PM, I= an Swett <ianswett@google.com> wrote:
After thinking about it more, if no one else= has objections to "Make every application implement their own gracefu= l close if they need it and only provide a way to kill the connection immed= iately.", I'm fine with it as well.

On= Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 8 Mar= ch 2017 at 03:58, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson <martin.thomson@gmail.com>=
> wrote:
>>
>> I think that both are likely to run afoul of a simple problem in H= TTP:
>> the control stream (stream 3) can't be closed.
>>
> I don't think that's actually a problem with what I suggested.= =C2=A0 It simply
> means that for the HTTP mapping, the defined behavior is to send
> FIN_COMPLETE after all open requests and pushes complete.=C2=A0 If it = arrives
> before then, you'd have to treat it as a protocol error for the ma= pping.
> What I'm trying to avoid is baking in the requirement that FIN_COM= PLETE (or
> its moral equivalent) always occur then, since it will make using othe= r
> types

Sure.=C2=A0 I had inferred that you were doing this entirely at the<= br> transport layer, which doesn't really allow you to do that.


--94eb2c14c356e5eab0054a2f8eee-- From nobody Tue Mar 7 19:34:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7B129418 for ; Tue, 7 Mar 2017 19:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fauJB30rYkO4 for ; Tue, 7 Mar 2017 19:34:27 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3BD2124281 for ; Tue, 7 Mar 2017 19:34:26 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id y76so42314771qkb.0 for ; Tue, 07 Mar 2017 19:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=21jqUsP5Ci+Rj8X/YOMAUyUeUvfBa1spB4JrIYGDoso=; b=SnoYVt9xVHvbY9A6qDasqSTmaUy3HhKOstPKYC4qC8OmAt0ZfaIbRyj0kwaz6GUdkI varnM6DNNjuJ+08wluR1aVg58E4ag3tGP4+41RW/6xotkadu5Eef93wP3yC01uEloxkJ 5StDirA5eF1V8/LcC1nCIzFqscX5dqpMby4i/sQmmflT3wBABfpa+AJlhDay36lVNeuL 7w3aBFOks/OsFKmReDkVRZVmqSFP32owzJ/6VgxrlvgdeEyiFuhE/O2MHET4C86EzmYq gUtyggakXj+IEjaMfHxnap47AsBjRPSjZOC/CAUgbKecJx+1TQMC8jin1vHTf5iZK0TO 3wBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=21jqUsP5Ci+Rj8X/YOMAUyUeUvfBa1spB4JrIYGDoso=; b=P8BMkWwmUQNNzAiuWEhBYFDzGWP6UOVs3gQlNYhVc7elWLjWMPRbhX8q2hjZhfhrsL bYHDeOQv7OvTeHM3WQJ8zj1GxglgIfk+A6IrRgnjIhAczoGmi/vVC2QyvScFOtesOJKZ 4Gy8BIDotwc3Z08QbZqQtlQiDvMu2LV3VZZgh7rRbvF+EiMIofYS+pLXFPshCndusZ/T nGqX2wR+mX5FODATEot78UNQ1NgrLsH6Y16CCyKiWTcKaNgHatJkZMAbJ0jQvv4Uha9N acrfqk95v2Yc2Eu1gVA5l5Hfh4v/4N3pBAojJ65yVlvvyzrylPx433ajsq1rvA40VpUB DHKw== X-Gm-Message-State: AMke39mdiX8eX7UbcXyn7K+JQE7LrGrGsnWMNtpV3Oj5bhx08Ks76jDvhl0fwCplO55Vuh5Be1vBM8lF4z+HXQ== X-Received: by 10.200.3.214 with SMTP id z22mr5272737qtg.3.1488944066057; Tue, 07 Mar 2017 19:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 19:34:25 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Mar 2017 14:34:25 +1100 Message-ID: Subject: Re: DISINTEREST frame To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:34:28 -0000 On 8 March 2017 at 14:01, Lubashev, Igor wrote: > + [...] If the DISINTEREST frame is received on a > +stream that is already in the "half-closed (local)" or "closed" states, a > +RST_STREAM frame SHOULD still be sent > > What if the sender already received an ACK for a packet that contained FIN or RST_STREAM for that stream? Is the recommendation still "SHOULD send RST_STREAM"? (This can happen in case of packet reordering.) I think that the advice should be that RST_STREAM is sent unless all outstanding data has been sent AND acknowledged. You are right, if the state is all long gone, likely due to reordering, then there is no point in resetting. From nobody Tue Mar 7 19:51:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC8D129418 for ; Tue, 7 Mar 2017 19:51:42 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 t7xwHM1mWN2H for ; Tue, 7 Mar 2017 19:51:41 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB2D129410 for ; Tue, 7 Mar 2017 19:51:41 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 93C6B433415; Wed, 8 Mar 2017 03:51:40 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 732AB433407; Wed, 8 Mar 2017 03:51:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488945100; bh=z7oR5SQ8TExOCXaRUBctcgT1GnhAsMXnC38B+wnBp8A=; l=3761; h=From:To:CC:Date:References:In-Reply-To:From; b=TUq/DASK6JKf6ofVV+00vl0h7mNfyRhYIC+lPzR0RQO/dA5eRi6uFUFp7fqMsxmr2 r2vKtfhFxp0OiGEKthR431pRdTBuGSmAAZyr26qZ0Ju/s6VeadmAksEjHMLEskvqFj /XTG4Jj/6+a1Q8UcSeObm2TvWj6tLYYpO71e9ov0= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 6F0DA1FC88; Wed, 8 Mar 2017 03:51:40 +0000 (GMT) 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.1178.4; Tue, 7 Mar 2017 22:51:39 -0500 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.1178.000; Tue, 7 Mar 2017 22:51:39 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AD//9VqgP//sP/m Date: Wed, 8 Mar 2017 03:51:39 +0000 Message-ID: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_436570d5fa794f779a74d22d4c975432usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:51:43 -0000 --_000_436570d5fa794f779a74d22d4c975432usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why require ALL outstanding data to be ACKed to suppress RST_SYREAM? Why is= an ACK of FIN not enough? The peer now has the stream in "half-closed (rem= ote)" or "closed" already; he is not keeping any rcv data buffers anymore; = why send RST_STREAM? -----Original Message----- From: Martin Thomson [martin.thomson@gmail.com] Received: Tuesday, 07 Mar 2017, 10:34PM To: Lubashev, Igor [ilubashe@akamai.com] CC: Mike Bishop [Michael.Bishop@microsoft.com]; IETF QUIC WG [quic@ietf.org= ] Subject: Re: DISINTEREST frame On 8 March 2017 at 14:01, Lubashev, Igor wrote: > + [...] If the DISINTEREST frame is received on a > +stream that is already in the "half-closed (local)" or "closed" states, = a > +RST_STREAM frame SHOULD still be sent > > What if the sender already received an ACK for a packet that contained FI= N or RST_STREAM for that stream? Is the recommendation still "SHOULD send = RST_STREAM"? (This can happen in case of packet reordering.) I think that the advice should be that RST_STREAM is sent unless all outstanding data has been sent AND acknowledged. You are right, if the state is all long gone, likely due to reordering, then there is no point in resetting. --_000_436570d5fa794f779a74d22d4c975432usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why require ALL outstanding data to be ACKed to suppress R= ST_SYREAM? Why is an ACK of FIN not enough? The peer now has the stream in = "half-closed (remote)" or "closed" already; he is not keeping any rcv data buffers anymore; why send RST_STRE= AM?

-----Original Message-----
From: Martin Thomson [martin.thomson@gmail.com]
Received: Tuesday, 07 Mar 2017, 10:34PM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: Mike Bishop [Michael.Bishop@microsoft.com]; IETF QUIC WG [quic@i= etf.org]
Subject: Re: DISINTEREST frame

On 8 March 2017 at 14:01, Lubashev, Igor <iluba= she@akamai.com> wrote:
> + [...] If the DISINTEREST frame is received on a
> +stream that is already in the "half-closed (local)" or = "closed" states, a
> +RST_STREAM frame SHOULD still be sent
>
> What if the sender already received an ACK for a packet that contained= FIN or RST_STREAM for that stream?  Is the recommendation still "= ;SHOULD send RST_STREAM"? (This can happen in case of packet reorderin= g.)


I think that the advice should be that RST_STREAM is sent unless all
outstanding data has been sent AND acknowledged.  You are right, if the state is all long gone, likely due to reordering, then there is no
point in resetting.
 --_000_436570d5fa794f779a74d22d4c975432usma1exdag1mb5msgcorpak_-- From nobody Tue Mar 7 19:53:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6855D129418 for ; Tue, 7 Mar 2017 19:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 E8qbfRjbmIz2 for ; Tue, 7 Mar 2017 19:53:54 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93EC129410 for ; Tue, 7 Mar 2017 19:53:53 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id y76so42955198qkb.0 for ; Tue, 07 Mar 2017 19:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bcAyMSs9BdMrNO5wvbQ9x9ltlr9RlaCHGyemXDKzcQU=; b=gMXz7mwHDEestz7IvoZv65lo/HNS2ZVpDJ/CstyHGxYiSp/CFjE/zdeqcDQyOfRRT1 figa/Dv16mXqqux+CbIHYQtu7w7OjP1sLQv//HpPza4vJG0E1oLPrcjTFKbn7rd4yvrQ h0UptRYCmxxzfAdg0dICRlbJIPfMLjmGKu8qs4JOjF2SUHigcb3DBjegJoDES4KKJKOP KvhDsidmSIjW4aDTm8b1DpPlfvOicFT0Sob7BWvMgcdMD8gwk788vBLEUnWAualTZcTH rYGwNRgf4USzkkMWtbaeWysjGB9Vw2V1JA0VUU2vMhnFhga1ZNPex9soL8nZqPmmGKvO Mmlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bcAyMSs9BdMrNO5wvbQ9x9ltlr9RlaCHGyemXDKzcQU=; b=lnAbh/dIg8Vv9S9koIqoisR0VEbuUhH5TzbGYVDGefD9llVnaVl0ZIcGbtjZoSOxms NTQTDPf6Z+I2ZSIMQu6izPC/b5BW1UKrMkV1sj+PEtUkXtQMGUoUz5FWwRu1ze3djbPD BYl2958f1ozhN/c/RCFidzuem2K7DC35NPK4f4RJ4DhU/45e7tCmIfZhKqA+m842Mb9p 6l2JM94w0KFBEk47JHQXxfUMY3WnDNTCqWS4HcuWoFCr8j00QNleZFjhdbh8wMi22BHs euDl6VNfW+O4hdsRsY70FnpIIMVj/QGqNOmlvKYdpNW2z5NEcEDm5PTDW+z2mLHe6Rd8 Oq9g== X-Gm-Message-State: AMke39nE6xa5A6cIP+eOhausByYKY6s+DE83mqLgq+MNGpZNDe5HW2gC/B/pvfS4Ra1XD/pJYioicFpqj+x5ng== X-Received: by 10.200.33.210 with SMTP id 18mr5028286qtz.159.1488945233132; Tue, 07 Mar 2017 19:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 19:53:52 -0800 (PST) In-Reply-To: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Wed, 8 Mar 2017 14:53:52 +1100 Message-ID: Subject: Re: DISINTEREST frame To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:53:55 -0000 On 8 March 2017 at 14:51, Lubashev, Igor wrote: > Why require ALL outstanding data to be ACKed to suppress RST_SYREAM? Why is > an ACK of FIN not enough? The peer now has the stream in "half-closed > (remote)" or "closed" already; he is not keeping any rcv data buffers > anymore; why send RST_STREAM? You can ACK the packet that contained FIN without ever having received the packet that preceded it. In that case, you want to send RST_STREAM to say "I'm going to stop retransmitting those bytes." From nobody Tue Mar 7 20:27:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897DF128BA2 for ; Tue, 7 Mar 2017 20:27:10 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KyNHrWwvtMbo for ; Tue, 7 Mar 2017 20:27:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7066B12706D for ; Tue, 7 Mar 2017 20:27:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 13F26433407; Wed, 8 Mar 2017 04:27:09 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E6E6B433415; Wed, 8 Mar 2017 04:27:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488947228; bh=EaHKwuKEopTm7AcIxqO71bRtyMTjxDnqv17eOujsHC8=; l=3285; h=From:To:CC:Date:References:In-Reply-To:From; b=tZ6n6XQTapMHClYztlulDSGhIEM9//F+IBJBL3te9B9pRJGX4MkUix1uz22QGmr6v m0pcRW5PDzhfiWadqkHcodggvDfwW/viub5iOkwyCWffvtCgFcqhAcueGGxA9euxpb mY+i7tfq3j2qkGqhYwA5tzEF9oxmcAV6xHgegJ+0= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E26FF1FC8E; Wed, 8 Mar 2017 04:27:08 +0000 (GMT) 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.1178.4; Tue, 7 Mar 2017 23:27:08 -0500 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.1178.000; Tue, 7 Mar 2017 23:27:08 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AD//9VqgP//sP/mgABUcAD//7V6AA== Date: Wed, 8 Mar 2017 04:27:08 +0000 Message-ID: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_b4688e1c025f4f4d880d9d01513876e1usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:27:10 -0000 --_000_b4688e1c025f4f4d880d9d01513876e1usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why do you need to say "I'm going to stop retransmitting those bytes" to so= meone who just told you that "I'm going to throw away anything I receive fr= om you" (DISINTEREST)? -----Original Message----- From: Martin Thomson [martin.thomson@gmail.com] Received: Tuesday, 07 Mar 2017, 10:53PM To: Lubashev, Igor [ilubashe@akamai.com] CC: quic@ietf.org [quic@ietf.org]; Michael.Bishop@microsoft.com [Michael.Bi= shop@microsoft.com] Subject: Re: DISINTEREST frame On 8 March 2017 at 14:51, Lubashev, Igor wrote: > Why require ALL outstanding data to be ACKed to suppress RST_SYREAM? Why = is > an ACK of FIN not enough? The peer now has the stream in "half-closed > (remote)" or "closed" already; he is not keeping any rcv data buffers > anymore; why send RST_STREAM? You can ACK the packet that contained FIN without ever having received the packet that preceded it. In that case, you want to send RST_STREAM to say "I'm going to stop retransmitting those bytes." --_000_b4688e1c025f4f4d880d9d01513876e1usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why do you need to say "I'm going to stop retransmitt= ing those bytes" to someone who just told you that "I'm going to = throw away anything I receive from you" (DISINTEREST)?

-----Original Message-----
From: Martin Thomson [martin.thomson@gmail.com]
Received: Tuesday, 07 Mar 2017, 10:53PM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: quic@ietf.org [quic@ietf.org]; Michael.Bishop@microsoft.com [Mic= hael.Bishop@microsoft.com]
Subject: Re: DISINTEREST frame

On 8 March 2017 at 14:51, Lubashev, Igor <iluba= she@akamai.com> wrote:
> Why require ALL outstanding data to be ACKed to suppress RST_SYREAM? W= hy is
> an ACK of FIN not enough? The peer now has the stream in "half-cl= osed
> (remote)" or "closed" already; he is not keeping any rc= v data buffers
> anymore; why send RST_STREAM?


You can ACK the packet that contained FIN without ever having received
the packet that preceded it.  In that case, you want to send
RST_STREAM to say "I'm going to stop retransmitting those bytes."=
--_000_b4688e1c025f4f4d880d9d01513876e1usma1exdag1mb5msgcorpak_-- From nobody Tue Mar 7 20:28:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7A128BA2 for ; Tue, 7 Mar 2017 20:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKnnnafPne4Q for ; Tue, 7 Mar 2017 20:28:39 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353EF12706D for ; Tue, 7 Mar 2017 20:28:39 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id p64so44044765qke.1 for ; Tue, 07 Mar 2017 20:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wLCdT3deAHp4NpHMoKceNh1FHBNGw9xmDjsOx3qrfqI=; b=Fsi8OHkrtFC4D2gcZnx//qb56wcLZYuJEMi9xfEH5zrj2NWf9ezeIs7QZoRpl0C23N Wjo3xipm6GWAsBxRDLXKveT7odZruzgOVaks3ITD5Ue5dJFcwrwfBt56+a3YGzjl4Esc oe86qeoJXUAedmlO8GbroIJh1ZSIBVxWq7Gu6XZ15hA/PRmGGAFCH7EqpjhtaUM1pzCL f8f1/4MW6vScZ7Ea6QxqTgFSTHzuvw9fjnUSkDVA3Y6MDK1uzz0RXS3woQOwRuMlOE0r OdBgMSYYR9lHnX84kJL2cvmo25kR8SOkTZRSOLYO2HzIxGB3XaQIxEzg1wRSEa4U2wSj JFGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wLCdT3deAHp4NpHMoKceNh1FHBNGw9xmDjsOx3qrfqI=; b=nZqTrqYB18iwI50l22UsSNek1iNVZvKZhBz/SFKPAAvF3NvT8WSk2kRWHlAB4IEPUm 5cc9hq4oImk7wbUKtoKZZrGIgbKDOs14KPScVferV/MgfpCfeD+atYoPik8o9DwWk5mw nbmpjPeA16TRMEhBxVTe7YCTb+ioqShDCaQ+M/228zUCMUlhn/6P3/YClhd85a7NbFnC dB4w8GQQDvN9lu2SP/w0BULZoizbB48ytCa4IKezp/ejPSVt/VoYvhHA6zNTCyifCSM3 jZbCV3J8hfuJ6v4ObQxdEZ3ucupSqxnapwFvWEcr3+094CAMl3NUb+RmwtCsf1cXUfsK IALw== X-Gm-Message-State: AFeK/H1msuDiVaSuR6/59ik0TFCbTcv/TprZdk7gbVQxReWS8gTZesFxuix8ZzaA1PLJdfv4FqHAGo1OzXsNkQ== X-Received: by 10.55.27.219 with SMTP id m88mr4828034qkh.147.1488947318355; Tue, 07 Mar 2017 20:28:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 20:28:37 -0800 (PST) In-Reply-To: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Wed, 8 Mar 2017 15:28:37 +1100 Message-ID: Subject: Re: DISINTEREST frame To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:28:41 -0000 On 8 March 2017 at 15:27, Lubashev, Igor wrote: > Why do you need to say "I'm going to stop retransmitting those bytes" to > someone who just told you that "I'm going to throw away anything I receive > from you" (DISINTEREST)? Because DISINTEREST doesn't actually affect the state of the stream, it's a request to the sender of a stream to cease transmission. The bytes will still be delivered unless the sender explicitly abandons them. From nobody Tue Mar 7 20:35:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7908E129400 for ; Tue, 7 Mar 2017 20:35:23 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 x6tUtj7GM7qH for ; Tue, 7 Mar 2017 20:35:22 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 42F88127ABE for ; Tue, 7 Mar 2017 20:35:21 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 168D0433415; Wed, 8 Mar 2017 04:35:21 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id F1DE2433407; Wed, 8 Mar 2017 04:35:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488947720; bh=4NqQGC+IGKnlEpH/UDQDXqSZe+spli9qbx/CeFUogE0=; l=3672; h=From:To:CC:Date:References:In-Reply-To:From; b=yxLYmg3jDz+qcQ5yLgcby7/E+oDBUkdxkTk3Jsr4joCGAJCYUUoM6zQwPbLkvy/ZG sUR6yZBlLvW9pi0YW94tYHxYQakVna55/pcjjBlTw7xUpADYW0a9cZVPywVqBQ5Fh0 NSDaR1bNIt+kXGdzELYZ8vkgwwJdBQ+k0dI9l1+A= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EB6CD1FC88; Wed, 8 Mar 2017 04:35:20 +0000 (GMT) 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.1178.4; Tue, 7 Mar 2017 23:35:20 -0500 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.1178.000; Tue, 7 Mar 2017 23:35:20 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AD//9VqgP//sP/mgABUcAD//7V6AIAAVDuA//+uD6I= Date: Wed, 8 Mar 2017 04:35:19 +0000 Message-ID: <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_46a68309730c48e380b1b61055fb9dd2usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:35:23 -0000 --_000_46a68309730c48e380b1b61055fb9dd2usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are taking about a case when the sender of the stream is already in "hal= f-closed (local)" (or "closed") and the receiver is already in "half-closed= (remote)" (or "closed"). This RST_STREAM will not affect the state of the = stream for any peer. The only information RST_STREAM contains now is "I wil= l not transmit". But the peer already sent DISINTERESTED to indicate it doe= s not care about retransmissions. -----Original Message----- From: Martin Thomson [martin.thomson@gmail.com] Received: Tuesday, 07 Mar 2017, 11:28PM To: Lubashev, Igor [ilubashe@akamai.com] CC: quic@ietf.org [quic@ietf.org]; Michael.Bishop@microsoft.com [Michael.Bi= shop@microsoft.com] Subject: Re: DISINTEREST frame On 8 March 2017 at 15:27, Lubashev, Igor wrote: > Why do you need to say "I'm going to stop retransmitting those bytes" to > someone who just told you that "I'm going to throw away anything I receiv= e > from you" (DISINTEREST)? Because DISINTEREST doesn't actually affect the state of the stream, it's a request to the sender of a stream to cease transmission. The bytes will still be delivered unless the sender explicitly abandons them. --_000_46a68309730c48e380b1b61055fb9dd2usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We are taking about a case when the sender of the stream i= s already in "half-closed (local)" (or "closed") and th= e receiver is already in "half-closed (remote)" (or "closed&= quot;). This RST_STREAM will not affect the state of the stream for any peer. The = only information RST_STREAM contains now is "I will not transmit"= . But the peer already sent DISINTERESTED to indicate it does not care abou= t retransmissions.

-----Original Message-----
From: Martin Thomson [martin.thomson@gmail.com]
Received: Tuesday, 07 Mar 2017, 11:28PM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: quic@ietf.org [quic@ietf.org]; Michael.Bishop@microsoft.com [Mic= hael.Bishop@microsoft.com]
Subject: Re: DISINTEREST frame

On 8 March 2017 at 15:27, Lubashev, Igor <iluba= she@akamai.com> wrote:
> Why do you need to say "I'm going to stop retransmitting those by= tes" to
> someone who just told you that "I'm going to throw away anything = I receive
> from you" (DISINTEREST)?


Because DISINTEREST doesn't actually affect the state of the stream,
it's a request to the sender of a stream to cease transmission.  The bytes will still be delivered unless the sender explicitly abandons
them.
 --_000_46a68309730c48e380b1b61055fb9dd2usma1exdag1mb5msgcorpak_-- From nobody Tue Mar 7 20:41:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3741279EB for ; Tue, 7 Mar 2017 20:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnQHvhGjNTIl for ; Tue, 7 Mar 2017 20:41:47 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 7330312706D for ; Tue, 7 Mar 2017 20:41:47 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id v125so43631777qkh.2 for ; Tue, 07 Mar 2017 20:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XrQ5uP3th3l6aeKUvBmHYe0LNXtqcRRphzhh5iVWOJo=; b=NIVqLDu4d0kvkny4lkzBkEEyXrFhG+rKbDSQPJpcN64ZoYWaW2Gr6Rg2xRYh2gnJ8/ s2VN+Omr/AA4+3l3x0fHTdhxeP2JtVn5OPFdjkQ5NoysD68GE8MhDK3O+AOnna/AY3Eb tGo5iBSHhzgu5Ev7BISlsrcBU36uxyP4g/Kkl3Pl1c5KPD46nMD01gjOiz+e0wuE5WHW K3FSFEIv4T6NYnlOou/tcSQTWDQGITUHo+ZQwn5BaKMozqXPbpIrqH4UA2LD3vFKm/xW 0dkvOkpizjOqqsZkeVf9dgrzESAGO67rIgAsqcGnQI0a5QJYdMF4s79b417si46A0icJ gpoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XrQ5uP3th3l6aeKUvBmHYe0LNXtqcRRphzhh5iVWOJo=; b=D4dRMgBELyGJPSNDb51o2yDygVMIgj2iLgWpZDCeIb+gRN3ahcJXaxFjtGFhiadR/7 gL1Bi9s+ULMNGwQo5uEFKmNLJNbjwnhgKhpbuPllV4/6zg+uerdE0MaxwrmD7eLWSUE0 H1ljaovxY1r4qD98IteaSYvXm2o9BengHBWdKo+qmMFGz5Lu9ZwWw0wjprDiBA2z4Mku E1SGTKvuoFomdi+cR+gWhOven6y9HwajXwf7pih4IE4UJVHBPh5Vu1ZQRyfHfbHE4d4w Gj8cvj/QudTPJAUw4wb2m2dRG2CEsQ5/qQBZ7KX3jQ7tj2LH5B7B9BmSZVye6SlKCInY PeUA== X-Gm-Message-State: AMke39m8EZERnbqAMikJ3Wz0rFeeJ2phIlPWOZJxuzvyNQwDf7tiTKI8SCe5DVEmBek5CkHVtWcwlFuJmslcyg== X-Received: by 10.200.33.210 with SMTP id 18mr5205222qtz.159.1488948106672; Tue, 07 Mar 2017 20:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 7 Mar 2017 20:41:46 -0800 (PST) In-Reply-To: <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Wed, 8 Mar 2017 15:41:46 +1100 Message-ID: Subject: Re: DISINTEREST frame To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:41:48 -0000 On 8 March 2017 at 15:35, Lubashev, Igor wrote: > We are taking about a case when the sender of the stream is already in > "half-closed (local)" (or "closed") and the receiver is already in > "half-closed (remote)" (or "closed"). This RST_STREAM will not affect the > state of the stream for any peer. The only information RST_STREAM contains > now is "I will not transmit". But the peer already sent DISINTERESTED to > indicate it does not care about retransmissions. Even after closing a stream, an endpoint needs to retransmit data. It closes when it first sends the FIN. From nobody Wed Mar 8 06:51:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652AB129416 for ; Wed, 8 Mar 2017 06:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6uhzJ60qk29u for ; Wed, 8 Mar 2017 06:51:33 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 E232312949E for ; Wed, 8 Mar 2017 06:51:32 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id f54so38192538uaa.1 for ; Wed, 08 Mar 2017 06:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A07t7C+VZSkSfuWZgdfG59zQzxkvZUiZ1bdP9Rhu5L4=; b=jibiZOGzrbZ5znuIadp1m/bTHbM6uNPL2L31WwUv3GWoR30h4czldJz2Vx/AJyWnIs wy3dmBK0PaKUCDdwu6nw++tt5pX2ZB26GBFckMWS3yRmM0xI78XXN8MNjdVjhE8ZlDzl KyeYyddduyhx31JEiCr5MwDFpSd8LSlugNUv1U05DE/kdurfSFLDm3R3LakOEKiluRfZ 7BC7HY0ZyJo5mP6w+voR+69D65gg8sPQ8e7NEB8BICqsuZP8YvydE3evGPyaxs/h0JF3 OjPiDl4Ds1QjFjt3SxlrZWAvamj31UMKTuUsSe0ZLZMbQ+U727m9X8knJlA0DKRFroua Fjkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A07t7C+VZSkSfuWZgdfG59zQzxkvZUiZ1bdP9Rhu5L4=; b=kxLt/LUVdRPRtbo2ynXdKcXMw6MoSILHGra700Eae0X8mDzlP2xaol0oYLRcVXYjTf BA4Z30hsX/ToMleyX27YM24iw0XtE61F4/rmqa8rI1dpV5Ybmx2Q4KDtJozz4a8t+E9u CyqIeOGJ34kUwgowyl1LQUIO60Tb9tyNN9BLiLHuXigE27FdLcrQ/uXcJl1lAFYKXZ0p 4XC/J6ewTu7n5piqwIci1FD8PDNWIjgfcgm41ktHChWzUu27fLpE6d9JbZsllG28mQPa 9bh3PIgChRVohonu6MENSC+WW1eFn3FYXeZ6nAWwQP2RyVYOE63lCY5JAo1vIsE+SNqf 6csQ== X-Gm-Message-State: AMke39mywfITIbUvmlNlT6We2zQzLiKzrA5PNL+K7XfLK3eecsvMdLrn7ldgUUwm1G6o43FBADKrwcVSNCkNrirE X-Received: by 10.37.110.139 with SMTP id j133mr1773961ybc.143.1488984691152; Wed, 08 Mar 2017 06:51:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Wed, 8 Mar 2017 06:51:10 -0800 (PST) In-Reply-To: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Wed, 8 Mar 2017 09:51:10 -0500 Message-ID: Subject: Re: DISINTEREST frame To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1148b49c983188054a394354 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "Lubashev, Igor" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 14:51:34 -0000 --001a1148b49c983188054a394354 Content-Type: text/plain; charset=UTF-8 Martin's right, you definitely need "RST_STREAM is sent unless all outstanding data has been sent AND acknowledged.", otherwise the peer waits forever for data that won't arrive. Question: Why call it DISINTEREST, instead of REQUEST_RST? It wasn't obvious to me what DISINTEREST was until I read further, whereas REQUEST_RST is pretty obvious, assuming you know about RST_STREAM. On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson wrote: > On 8 March 2017 at 15:35, Lubashev, Igor wrote: > > We are taking about a case when the sender of the stream is already in > > "half-closed (local)" (or "closed") and the receiver is already in > > "half-closed (remote)" (or "closed"). This RST_STREAM will not affect the > > state of the stream for any peer. The only information RST_STREAM > contains > > now is "I will not transmit". But the peer already sent DISINTERESTED to > > indicate it does not care about retransmissions. > > Even after closing a stream, an endpoint needs to retransmit data. It > closes when it first sends the FIN. > > --001a1148b49c983188054a394354 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin's right, you definitely need "RST_STREAM i= s sent unless all outstanding data has been sent AND acknowledged.", o= therwise the peer waits forever for data that won't arrive.

Question: Why call it DISINTEREST, instead of REQUEST_RST?=C2=A0 It= wasn't obvious to me what DISINTEREST was until I read further, wherea= s REQUEST_RST is pretty obvious, assuming you know about RST_STREAM.
<= /div>

On Tue, Mar = 7, 2017 at 11:41 PM, Martin Thomson <martin.thomson@gmail.com&g= t; wrote:
On 8 Ma= rch 2017 at 15:35, Lubashev, Igor <ilubashe@akamai.com> wrote:
> We are taking about a case when the sender of the stream is already in=
> "half-closed (local)" (or "closed") and the receiv= er is already in
> "half-closed (remote)" (or "closed"). This RST_STR= EAM will not affect the
> state of the stream for any peer. The only information RST_STREAM cont= ains
> now is "I will not transmit". But the peer already sent DISI= NTERESTED to
> indicate it does not care about retransmissions.

Even after closing a stream, an endpoint needs to retransmit data.= =C2=A0 It
closes when it first sends the FIN.


--001a1148b49c983188054a394354-- From nobody Wed Mar 8 08:04:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5E51294AD for ; Wed, 8 Mar 2017 08:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQBQGnAA950D for ; Wed, 8 Mar 2017 08:04:02 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF57126CD8 for ; Wed, 8 Mar 2017 08:04:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.36,264,1486454400"; d="asc'?scan'208,217";a="188105688" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx141-out.netapp.com with ESMTP; 08 Mar 2017 07:53:58 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Mar 2017 08:03:00 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 8 Mar 2017 08:03:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XJNy2SgZf/nq1pfFXcVborT31VizXEzA8afe+IvdH6Y=; b=RwaUonPj6cyIk6IuGkmadVnv4XSecHN1FYGgPbN7shq73xW8+nWRj5H6MyivuLrrA5Y0dRZikmr44uXOKtwQQdOj2F7sLPpw0W3rT/2FDHz4j0PxFEMWl5Z4jaVjqSYMGuHtUv0H4s+Y8mwjOpT4rADW2b5N4uvcAGfuVk5LRpA= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 16:03:01 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 16:03:00 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Fwd: BCP 145, RFC 8085 on UDP Usage Guidelines Thread-Topic: BCP 145, RFC 8085 on UDP Usage Guidelines Thread-Index: AQHSl5DR1Y97ay9/402lOAzb3IpDQQ== Date: Wed, 8 Mar 2017 16:03:00 +0000 Message-ID: <167A40AF-BD55-4067-9A67-CCA90290A82B@netapp.com> References: <20170307221737.3DBA1B819A0@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [188.174.91.51] x-ms-office365-filtering-correlation-id: 4648d5a1-6106-4639-a8f2-08d4663c9886 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1155; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:SclcuDebr5lOKZbdDDOMdcnOutvmu/ojUonFy/UVIKU273hJtFOHx3ArKMWwJgI2jAPVJCvSJyg3TrR74/AuBqB7fn/a1e+uWuaS6m8qelmTdo5Adkoy6m8brFjl5P8VBdhtCnEnlrOdGZwPSbNjVEe9WHubbxIygISc1R7tAvEf1mIXRvoqr3x+thnDcAfFo0EGx2S855RigaYg094s1c9yIaACL+WNNgE5dHNASwRnvGsCrQcCp3rltQzCpi18PKdPEzihyzXdqVxwduzFKHAkW9/y6TbYqf5+jQ8Hkzd8xZEoV7lHc2hz3CMlHm4E7oDlIydqxrhfSzxI+nstsw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(51444003)(2900100001)(33656002)(3846002)(3660700001)(81166006)(8676002)(36756003)(6306002)(2473003)(54896002)(99286003)(53936002)(6512007)(106116001)(6436002)(6506006)(3280700002)(7736002)(606005)(77096006)(7906003)(6486002)(25786008)(236005)(86362001)(5660300001)(229853002)(189998001)(82746002)(50226002)(2906002)(66066001)(76176999)(83716003)(50986999)(102836003)(57306001)(99936001)(110136004)(6116002)(122556002)(38730400002)(8936002)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_95786802-1CA6-4A71-8C0A-A1A249028F06"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 16:03:00.8490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:04:05 -0000 --Apple-Mail=_95786802-1CA6-4A71-8C0A-A1A249028F06 Content-Type: multipart/alternative; boundary="Apple-Mail=_60B999D1-3785-4C3D-9ED1-0943349D1919" --Apple-Mail=_60B999D1-3785-4C3D-9ED1-0943349D1919 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii During the chartering phase, the IESG remarked whether QUIC was going to = be aligned with the recommendations in this RFC-to-be. Since it just = came out, I wanted to make the WG aware. I think that it's pretty obvious that QUIC will be aligned. I can't even = think of a design aspect where we'd significantly deviate, but since = we'll have ample motivation, that will be sufficient to justify. Lars > Begin forwarded message: >=20 > From: "rfc-editor@rfc-editor.org" > Subject: BCP 145, RFC 8085 on UDP Usage Guidelines > Date: March 7, 2017 at 23:17:37 GMT+1 > To: "ietf-announce@ietf.org" , = "rfc-dist@rfc-editor.org" > Cc: "drafts-update-ref@iana.org" , = "tsvwg@ietf.org" , "rfc-editor@rfc-editor.org" = > Reply-To: "ietf@ietf.org" >=20 > A new Request for Comments is now available in online RFC libraries. >=20 > BCP 145 > RFC 8085 >=20 > Title: UDP Usage Guidelines > Author: L. Eggert, > G. Fairhurst, > G. Shepherd > Status: Best Current Practice > Stream: IETF > Date: March 2017 > Mailbox: lars@netapp.com, > gorry@erg.abdn.ac.uk, > gjshep@gmail.com > Pages: 55 > Characters: 145359 > Obsoletes: RFC 5405 > See Also: BCP 145 >=20 > I-D Tag: draft-ietf-tsvwg-rfc5405bis-19.txt >=20 > URL: https://www.rfc-editor.org/info/rfc8085 >=20 > DOI: 10.17487/RFC8085 >=20 > The User Datagram Protocol (UDP) provides a minimal message-passing > transport that has no inherent congestion control mechanisms. This > document provides guidelines on the use of UDP for the designers of > applications, tunnels, and other protocols that use UDP. Congestion > control guidelines are a primary focus, but the document also > provides guidance on other topics, including message sizes, > reliability, checksums, middlebox traversal, the use of Explicit > Congestion Notification (ECN), Differentiated Services Code Points > (DSCPs), and ports. >=20 > Because congestion control is critical to the stable operation of the > Internet, applications and other protocols that choose to use UDP as > an Internet transport must employ mechanisms to prevent congestion > collapse and to establish some degree of fairness with concurrent > traffic. They may also need to implement additional mechanisms, > depending on how they use UDP. >=20 > Some guidance is also applicable to the design of other protocols > (e.g., protocols layered directly on IP or via IP-based tunnels), > especially when these protocols do not themselves provide congestion > control. >=20 > This document obsoletes RFC 5405 and adds guidelines for multicast > UDP usage. >=20 > This document is a product of the Transport Area Working Group Working = Group of the IETF. >=20 >=20 > BCP: This document specifies an Internet Best Current Practices for = the > Internet Community, and requests discussion and suggestions for > improvements. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 --Apple-Mail=_60B999D1-3785-4C3D-9ED1-0943349D1919 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii During the chartering phase, the IESG remarked whether QUIC = was going to be aligned with the recommendations in this RFC-to-be. = Since it just came out, I wanted to make the WG aware.

I think that it's pretty obvious that = QUIC will be aligned. I can't even think of a design aspect where we'd = significantly deviate, but since we'll have ample motivation, that will = be sufficient to justify.

Lars
Reply-To: = "ietf@ietf.org" <ietf@ietf.org>

A new Request for Comments is = now available in online RFC libraries.

=        BCP 145 =        
=        RFC 8085

       Title: =      UDP Usage Guidelines
=        Author: =     L. Eggert,
=             &n= bsp;      G. Fairhurst,
=             &n= bsp;      G. Shepherd
=        Status: =     Best Current Practice
=        Stream: =     IETF
=        Date: =       March 2017
=        Mailbox:    lars@netapp.com,
=             &n= bsp;      gorry@erg.abdn.ac.uk, =
=             &n= bsp;      gjshep@gmail.com
       Pages: =      55
=        Characters: 145359
       Obsoletes: =  RFC 5405
=        See Also:   BCP = 145

=        I-D Tag: =    draft-ietf-tsvwg-rfc5405bis-19.txt

       URL: =        https://www.rfc-editor.org/info/rfc8085

       DOI: =        10.17487/RFC8085

The User Datagram Protocol (UDP) provides a = minimal message-passing
transport that has no inherent = congestion control mechanisms.  This
document = provides guidelines on the use of UDP for the designers of
applications, tunnels, and other protocols that use UDP. =  Congestion
control guidelines are a primary focus, = but the document also
provides guidance on other topics, = including message sizes,
reliability, checksums, middlebox = traversal, the use of Explicit
Congestion Notification = (ECN), Differentiated Services Code Points
(DSCPs), and = ports.

Because congestion control is = critical to the stable operation of the
Internet, = applications and other protocols that choose to use UDP as
an Internet transport must employ mechanisms to prevent = congestion
collapse and to establish some degree of = fairness with concurrent
traffic.  They may also need = to implement additional mechanisms,
depending on how they = use UDP.

Some guidance is also applicable = to the design of other protocols
(e.g., protocols layered = directly on IP or via IP-based tunnels),
especially when = these protocols do not themselves provide congestion
control.

This document obsoletes = RFC 5405 and adds guidelines for multicast
UDP usage.

This document is a product of the Transport = Area Working Group Working Group of the IETF.


BCP: This document specifies an Internet Best = Current Practices for the
Internet Community, and requests = discussion and suggestions for
improvements. Distribution = of this memo is unlimited.

This = announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 https://www.ietf.org/mailman/listinfo/ietf-announce
 https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search
For = downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to = either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are = for
unlimited distribution.

The RFC Editor Team
Association Management = Solutions, LLC



= --Apple-Mail=_60B999D1-3785-4C3D-9ED1-0943349D1919-- --Apple-Mail=_95786802-1CA6-4A71-8C0A-A1A249028F06 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----- iQIcBAEBCgAGBQJYwCszAAoJEFS1wwm/cMFXVe4QALwBrpjm03ywNvZTm2PFbhkk c8U4XRVnqT01DdfPgqwfji/6JKVeouw3WV0+eGXquLqUM7wl5EPZ5X7/cczrG1e+ yFZ8sXq5UUs4ZZibibNQed1o+3B6qdUfXwYfthKrpQOKfEt+Zw+inqWkaOi+quLx 5+Z/jVPUykwcb1N9N9djosRMoznhwCL1T8vn9b6rmFf2DaEgMdIuf+JnTMTcRDdJ ZOvfXREpX/BSbzR5ux9uW2H49P5xTu3QPuKRKf1whiOjoSJI2b/LNvNiMJw8KZaA uWs03kYYr86aLulvxxsWduRzQLENVG2kL/fboypR/K8N18moYECpOXMwWlSQL5eX WJXEb3sBm9VOPgVS7jsitmWNadv47awvUo59/JwIyKF5UGtZF4JQQhyNtTSNfZ1I G6p/hItaBE1PO2NuUKLKz9qakOAQW7l+70DWs3eTwfRj9duHAvX16gyXU5bNtSnU djCM2YA7WJyaY2TPTWmiyY8FxMyWbO2rnk5LDzibRjJ9Ec8RFJgz19QsUg7IY3SA kwPKIS3bT8YE8ZQE2d/BVT5Kn99caNq582cY2u2NMCww2qnPZw1aWa3x8E7O0j/6 1XwhnIuVjZ2stv9xKyz8jxso7CkhZPSzpfiZJJroZazO7uUaM5vzm8PW0rqz56WC YbITzrTy0CiA3Steu/t7 =NkWS -----END PGP SIGNATURE----- --Apple-Mail=_95786802-1CA6-4A71-8C0A-A1A249028F06-- From nobody Wed Mar 8 08:07:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A75126D74 for ; Wed, 8 Mar 2017 08:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeR_DtwOkZX0 for ; Wed, 8 Mar 2017 08:07:40 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0112.outbound.protection.outlook.com [104.47.42.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633C7126CD8 for ; Wed, 8 Mar 2017 08:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7sdQZqQyeVWQxKZrjSz0JYKKcZYp0zQjtVGRgaXvY1c=; b=YTp318rcapyARmIOrIztpw4YM7sWzQkCXcjrIJ6vcSA7Wjfzd1Q3DZx7P0jPjkZ2RQcIVcy4Qg8cQp3JlCxtuq/zF7IXLuSHvyEVsJFXh2BON1hWggWi112Uh7WvxQN2GwQNVgTZkiSFdmgj0hkBw9+xCQcBCq8QNJjMAb/lGEA= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 16:07:38 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 16:07:38 +0000 From: Mike Bishop To: Ian Swett , Martin Thomson Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAO9+SAAAMMFAAAASgWgAAAmhSAAAAT0QAAASltAAAADUSAAAA754AAADmrAAAVSHUAAAKR2qA= Date: Wed, 8 Mar 2017 16:07:38 +0000 Message-ID: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [172.58.43.250] x-ms-office365-filtering-correlation-id: a2081851-97b6-46c5-e370-08d4663d3e39 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:hQilDy4/zuiePAsqk9ex5pOfjncXyxVq69nLOJW1Ay79nxElkQTgb6PUF4XQGN8MiRr8pRoMmNwQ2ADg+VuArgHJ2kyBXuvziKdWMUSnIy7kBjn3IQpRbuTb3X7JzkEmeIVSxscWy+JKDZMEWsiriKbjUUrtC/zECXbio1hnVWq9LIyQ69niEQ6WqxRjwQBCSgcGdyyK/EiQIpu09OMtnpiu5N2GjkVagBufbdv7RdDqLh9syVI2iGJkCD1LAiFNrUfWvxwyAlAdNgCDbnCNeuvBiSMJr5BDaFu7EZRlww2Szrg0WZUTVLoYxk3IgZNvs3tk/x7LHmrAHtL5yE/d6k2ORoGvEbfIGBX7RCFhBDc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39410400002)(39860400002)(39840400002)(377454003)(24454002)(2906002)(53936002)(3480700004)(99286003)(10290500002)(74316002)(5660300001)(2950100002)(3280700002)(54906002)(8676002)(55016002)(54356999)(66066001)(189998001)(4326008)(221733001)(2900100001)(50986999)(19609705001)(76176999)(8990500004)(8936002)(10090500001)(7116003)(229853002)(81166006)(7696004)(54896002)(5005710100001)(9686003)(236005)(6306002)(6506006)(39060400002)(6246003)(33656002)(38730400002)(7736002)(86362001)(3660700001)(3846002)(790700001)(25786008)(6116002)(93886004)(53546006)(122556002)(6436002)(102836003)(86612001)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708D2D9EF72D4EE8F3F610E872E0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 16:07:38.7070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: "Lubashev, Igor" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:07:42 -0000 --_000_BN6PR03MB2708D2D9EF72D4EE8F3F610E872E0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm90aCBuYW1lcyBhcmUgYWJvdXQgZXF1YWwgdG8gbWUuICBSRVFVRVNUX1JTVCBpcyBhIHZlcnkg Y2xlYXIgc3RhdGVtZW50IGF0IHRoZSB0cmFuc3BvcnQgbGV2ZWwgb2Ygd2hhdCBpdCBkb2VzLiAg RElTSU5URVJFU1QgaXMgYSB2ZXJ5IGNsZWFyIHN0YXRlbWVudCBhYm91dCB3aGF0IGFwcGxpY2F0 aW9uIGJlaGF2aW9yIGl0IHJlZmxlY3RzIGFuZCB3aHkgeW914oCZZCBzZW5kIGl0LiAgQm90aCBu YW1lcyBhcmUgc29tZXdoYXQgb3BhcXVlIGZyb20gdGhlIG9wcG9zaXRlIHN0YW5kcG9pbnQuDQoN CkkgdGhpbmsgTWFydGluIGhhcyBzb21lIHVsdGltYXRlIGdvYWwgb2YgbW92aW5nIGF3YXkgZnJv bSB0aGUgYmFnZ2FnZSB0aGF0IGNvbWVzIHdpdGggdGhlIHRlcm1zIFJTVCBhbmQgRklOIGZyb20g VENQLiAgSWYgc28sIGhlIGNhbiBleHBvdW5kIHdoZW4gaXTigJlzIGNvbnZlbmllbnQgZm9yIGhp bS4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggOCwgMjAxNyA2OjUxIEFNDQpUbzogTWFydGluIFRob21zb24gPG1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkNjOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWth bWFpLmNvbT47IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPjsgcXVp Y0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IERJU0lOVEVSRVNUIGZyYW1lDQoNCk1hcnRpbidzIHJp Z2h0LCB5b3UgZGVmaW5pdGVseSBuZWVkICJSU1RfU1RSRUFNIGlzIHNlbnQgdW5sZXNzIGFsbCBv dXRzdGFuZGluZyBkYXRhIGhhcyBiZWVuIHNlbnQgQU5EIGFja25vd2xlZGdlZC4iLCBvdGhlcndp c2UgdGhlIHBlZXIgd2FpdHMgZm9yZXZlciBmb3IgZGF0YSB0aGF0IHdvbid0IGFycml2ZS4NCg0K UXVlc3Rpb246IFdoeSBjYWxsIGl0IERJU0lOVEVSRVNULCBpbnN0ZWFkIG9mIFJFUVVFU1RfUlNU PyAgSXQgd2Fzbid0IG9idmlvdXMgdG8gbWUgd2hhdCBESVNJTlRFUkVTVCB3YXMgdW50aWwgSSBy ZWFkIGZ1cnRoZXIsIHdoZXJlYXMgUkVRVUVTVF9SU1QgaXMgcHJldHR5IG9idmlvdXMsIGFzc3Vt aW5nIHlvdSBrbm93IGFib3V0IFJTVF9TVFJFQU0uDQoNCk9uIFR1ZSwgTWFyIDcsIDIwMTcgYXQg MTE6NDEgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRv Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gOCBNYXJjaCAyMDE3IGF0IDE1 OjM1LCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVA YWthbWFpLmNvbT4+IHdyb3RlOg0KPiBXZSBhcmUgdGFraW5nIGFib3V0IGEgY2FzZSB3aGVuIHRo ZSBzZW5kZXIgb2YgdGhlIHN0cmVhbSBpcyBhbHJlYWR5IGluDQo+ICJoYWxmLWNsb3NlZCAobG9j YWwpIiAob3IgImNsb3NlZCIpIGFuZCB0aGUgcmVjZWl2ZXIgaXMgYWxyZWFkeSBpbg0KPiAiaGFs Zi1jbG9zZWQgKHJlbW90ZSkiIChvciAiY2xvc2VkIikuIFRoaXMgUlNUX1NUUkVBTSB3aWxsIG5v dCBhZmZlY3QgdGhlDQo+IHN0YXRlIG9mIHRoZSBzdHJlYW0gZm9yIGFueSBwZWVyLiBUaGUgb25s eSBpbmZvcm1hdGlvbiBSU1RfU1RSRUFNIGNvbnRhaW5zDQo+IG5vdyBpcyAiSSB3aWxsIG5vdCB0 cmFuc21pdCIuIEJ1dCB0aGUgcGVlciBhbHJlYWR5IHNlbnQgRElTSU5URVJFU1RFRCB0bw0KPiBp bmRpY2F0ZSBpdCBkb2VzIG5vdCBjYXJlIGFib3V0IHJldHJhbnNtaXNzaW9ucy4NCg0KRXZlbiBh ZnRlciBjbG9zaW5nIGEgc3RyZWFtLCBhbiBlbmRwb2ludCBuZWVkcyB0byByZXRyYW5zbWl0IGRh dGEuICBJdA0KY2xvc2VzIHdoZW4gaXQgZmlyc3Qgc2VuZHMgdGhlIEZJTi4NCg0K --_000_BN6PR03MB2708D2D9EF72D4EE8F3F610E872E0BN6PR03MB2708namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C b3RoIG5hbWVzIGFyZSBhYm91dCBlcXVhbCB0byBtZS4mbmJzcDsgUkVRVUVTVF9SU1QgaXMgYSB2 ZXJ5IGNsZWFyIHN0YXRlbWVudCBhdCB0aGUgdHJhbnNwb3J0IGxldmVsIG9mIHdoYXQgaXQgZG9l cy4mbmJzcDsgRElTSU5URVJFU1QgaXMgYSB2ZXJ5IGNsZWFyIHN0YXRlbWVudCBhYm91dCB3aGF0 IGFwcGxpY2F0aW9uIGJlaGF2aW9yIGl0IHJlZmxlY3RzIGFuZCB3aHkgeW914oCZZCBzZW5kIGl0 LiZuYnNwOyBCb3RoIG5hbWVzIGFyZSBzb21ld2hhdA0KIG9wYXF1ZSBmcm9tIHRoZSBvcHBvc2l0 ZSBzdGFuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIE1hcnRpbiBoYXMg c29tZSB1bHRpbWF0ZSBnb2FsIG9mIG1vdmluZyBhd2F5IGZyb20gdGhlIGJhZ2dhZ2UgdGhhdCBj b21lcyB3aXRoIHRoZSB0ZXJtcyBSU1QgYW5kIEZJTiBmcm9tIFRDUC4mbmJzcDsgSWYgc28sIGhl IGNhbiBleHBvdW5kIHdoZW4gaXTigJlzIGNvbnZlbmllbnQgZm9yIGhpbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD4m bmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENv bXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBJYW4gU3dl dHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBNYXJjaCA4LCAyMDE3IDY6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29u ICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWJhc2hl diwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IE1pa2UgQmlzaG9wICZsdDtNaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogRElTSU5URVJFU1QgZnJhbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1hcnRpbidzIHJpZ2h0LCB5b3UgZGVmaW5pdGVseSBuZWVkICZxdW90O1JTVF9TVFJFQU0g aXMgc2VudCB1bmxlc3MgYWxsIG91dHN0YW5kaW5nIGRhdGEgaGFzIGJlZW4gc2VudCBBTkQgYWNr bm93bGVkZ2VkLiZxdW90Oywgb3RoZXJ3aXNlIHRoZSBwZWVyIHdhaXRzIGZvcmV2ZXIgZm9yIGRh dGEgdGhhdCB3b24ndCBhcnJpdmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5RdWVzdGlvbjogV2h5IGNhbGwgaXQgRElTSU5URVJFU1QsIGluc3RlYWQgb2Yg UkVRVUVTVF9SU1Q/Jm5ic3A7IEl0IHdhc24ndCBvYnZpb3VzIHRvIG1lIHdoYXQgRElTSU5URVJF U1Qgd2FzIHVudGlsIEkgcmVhZCBmdXJ0aGVyLCB3aGVyZWFzIFJFUVVFU1RfUlNUIGlzIHByZXR0 eSBvYnZpb3VzLCBhc3N1bWluZyB5b3Uga25vdyBhYm91dCBSU1RfU1RSRUFNLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA3 LCAyMDE3IGF0IDExOjQxIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gOCBNYXJjaCAy MDE3IGF0IDE1OjM1LCBMdWJhc2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hl QGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 IFdlIGFyZSB0YWtpbmcgYWJvdXQgYSBjYXNlIHdoZW4gdGhlIHNlbmRlciBvZiB0aGUgc3RyZWFt IGlzIGFscmVhZHkgaW48YnI+DQomZ3Q7ICZxdW90O2hhbGYtY2xvc2VkIChsb2NhbCkmcXVvdDsg KG9yICZxdW90O2Nsb3NlZCZxdW90OykgYW5kIHRoZSByZWNlaXZlciBpcyBhbHJlYWR5IGluPGJy Pg0KJmd0OyAmcXVvdDtoYWxmLWNsb3NlZCAocmVtb3RlKSZxdW90OyAob3IgJnF1b3Q7Y2xvc2Vk JnF1b3Q7KS4gVGhpcyBSU1RfU1RSRUFNIHdpbGwgbm90IGFmZmVjdCB0aGU8YnI+DQomZ3Q7IHN0 YXRlIG9mIHRoZSBzdHJlYW0gZm9yIGFueSBwZWVyLiBUaGUgb25seSBpbmZvcm1hdGlvbiBSU1Rf U1RSRUFNIGNvbnRhaW5zPGJyPg0KJmd0OyBub3cgaXMgJnF1b3Q7SSB3aWxsIG5vdCB0cmFuc21p dCZxdW90Oy4gQnV0IHRoZSBwZWVyIGFscmVhZHkgc2VudCBESVNJTlRFUkVTVEVEIHRvPGJyPg0K Jmd0OyBpbmRpY2F0ZSBpdCBkb2VzIG5vdCBjYXJlIGFib3V0IHJldHJhbnNtaXNzaW9ucy48YnI+ DQo8YnI+DQpFdmVuIGFmdGVyIGNsb3NpbmcgYSBzdHJlYW0sIGFuIGVuZHBvaW50IG5lZWRzIHRv IHJldHJhbnNtaXQgZGF0YS4mbmJzcDsgSXQ8YnI+DQpjbG9zZXMgd2hlbiBpdCBmaXJzdCBzZW5k cyB0aGUgRklOLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708D2D9EF72D4EE8F3F610E872E0BN6PR03MB2708namp_-- From nobody Wed Mar 8 08:09:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A481294C6 for ; Wed, 8 Mar 2017 08:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9HXs0HEZHWi for ; Wed, 8 Mar 2017 08:09:44 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0138.outbound.protection.outlook.com [104.47.38.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD17129499 for ; Wed, 8 Mar 2017 08:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dr8O3YeLh8DR3dync6nQ6Ju8WmunT5VI6GZOgGTnvj0=; b=GxU0yqOF/EBFSrQgO7uqyYgUspFgbu8M34APXvRQ69/YNORAuwR4k+qJaa3788EMuFfd1aiapjDPmtnGn1ST1/KuODcpSMgZkkTtkRWvDMULdedpjAqiTg5jzAw//9xcDlsb5Opj8xb7y9zt8YhbNdgHYdillmtVk0rmED8hlhg= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 16:09:41 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 16:09:41 +0000 From: Mike Bishop To: Ryan Hamilton , Martin Thomson Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAO9+SAAAJQLIAAHDOT0A== Date: Wed, 8 Mar 2017 16:09:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [172.58.43.250] x-ms-office365-filtering-correlation-id: e8c7df04-aa98-41cf-48da-08d4663d8740 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:0+RGc0d48MTg81pF+kGM0pQC2tXyaaqADxzz8Ymd2oyu+TZqwZLAzKabl0vglNbvu/H1j06k9qUQZrJnX4H3HkOigWY3RgC4WqqVB31qPzHdDH8t5mMihlnGkIbHjbI0GkxOUhzLWU+Zhzv7A1nhWk4RvrB1to/BYAjeChN6TKENlolYm+e9+iPd90FFbd1F5VhI1VmVcxc7rPFwG1btXjdRMDMvPxI3gGbZr8vsqCXWaPpzmh1Amq5TS+SmfU3sCO5PszLAV6Bs1GcZyuVLNoaQPpNEmhYp/3Gdh+5Ly/U/9oucibh6DlkhgDMKdvlBVPlt5UGa1lsIrGUZ86zjjOoevgPi2W2fo+DFNPhdwxM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(24454002)(377454003)(51444003)(2950100002)(236005)(9686003)(81166006)(5660300001)(10290500002)(55016002)(2900100001)(7696004)(8990500004)(6306002)(53546006)(54896002)(5005710100001)(221733001)(99286003)(3660700001)(54356999)(8936002)(86612001)(19609705001)(6436002)(77096006)(6506006)(8676002)(50986999)(25786008)(76176999)(4326008)(86362001)(229853002)(33656002)(790700001)(189998001)(39060400002)(3280700002)(122556002)(10090500001)(2906002)(53936002)(3480700004)(74316002)(102836003)(7116003)(6246003)(66066001)(6116002)(38730400002)(3846002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708F4FFEA21ECC0852A06EB872E0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 16:09:41.2070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:09:46 -0000 --_000_BN6PR03MB2708F4FFEA21ECC0852A06EB872E0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgYSBnb29kIHBvaW50IOKAkyB0aGUgUFIgY3VycmVudGx5IGRpc2N1c3NlcyB0aGUg aW1wYWN0IG9uIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sIChldmVyeXRoaW5nIHdvcmtz IGxpa2Ugbm9ybWFsKSwgYnV0IGRvZXNu4oCZdCBkaXNjdXNzIHdoYXQgZWl0aGVyIHBhcnR5IHNo b3VsZCBkbyB3aXRoIHN0cmVhbS1sZXZlbCBmbG93IGNvbnRyb2wuICBQcm9iYWJseSBqdXN0IGxl dHRpbmcgaXQgYmxvY2sgaXMgZmluZSDigJMgdGhlIHNlbmRlciB3aWxsIHByb2JhYmx5IHNlZSB0 aGUgRElTSU5URVJFU1QgYmVmb3JlIHRoZXkgZ2V0IGJsb2NrZWQsIGFuZCBpZiBub3QsIHRoZXJl 4oCZcyBubyBoYXJtLg0KDQpGcm9tOiBSeWFuIEhhbWlsdG9uIFttYWlsdG86cmNoQGdvb2dsZS5j b21dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCA3LCAyMDE3IDY6NDAgUE0NClRvOiBNYXJ0aW4gVGhv bXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IE1pa2UgQmlzaG9wIDxNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IERJU0lOVEVSRVNUIGZyYW1lDQoNClNvdW5kcyByZWFzb25hYmxlIHRvIG1lLiBX ZSBzaG91bGQgYWxzbyBjbGFyaWZ5IHRoZSBpbXBhY3QgaXQgaGFzIG9uIGZsb3ctY29udHJvbC4g SSBhc3N1bWUgdGhhdCBzaW5jZSB0aGUgc2VuZGVyIG9mIHN1Y2ggYSBmcmFtZSB3aWxsIG5vdCBi ZSByZWFkaW5nLCB0aGUgcmVjZWl2ZXIgb2YgdGhlIGZyYW1lIChhbmQgdGhlIHNlbmRlciBvZiBk YXRhKSBuZWVkcyB0byBzdG9wIHNlbmRpbmcgc2luY2UgaXQgd2lsbCBub3QgYmUgcmVjZWl2aW5n IGZsb3cgY29udHJvbCB1cGRhdGVzLg0KDQpXZSdsbCBhbHNvIHdhbnQgdG8gY2xhcmlmeSB0aGUg SFRUUCBtYXBwaW5nIHNpbmNlIEhUVFAvMiBkZWZpbmVzIHRoZSBSU1RfU1RSRUFNICsgTk9fRVJS T1Igc2VtYW50aWNzIHRoYXQgaXMgbGV2ZXJhZ2VkIGluIHRoZSBjdXJyZW50IFFVSUMgZG9jLg0K DQpCdXQgdGhlc2UgYXJlIGJvdGggbWlub3IgcG9pbnRzLg0KDQpPbiBUdWUsIE1hciA3LCAyMDE3 IGF0IDU6MzQgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGF0IHRoaXMg aXMgYSBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rpb24uICBXZSBoYXZlIHVzZSBjYXNlcw0KdGhh dCB0aGlzIHNlcnZlcy4NCg0KT24gOCBNYXJjaCAyMDE3IGF0IDA1OjQ1LCBNaWtlIEJpc2hvcCA8 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KPiBBdCB0aGUgVG9reW8gaW50ZXJpbSwgd2UgaGFkIGEgZGlzY3Vz c2lvbiBhcm91bmQgSXNzdWUgIzE2NSwgUFIgIzE3MQ0KPiBwcm9wb3NpbmcgYSBSRVFVRVNUX1JT VCBmcmFtZSwgYW5kIHRoZSBmYWN0IHRoYXQgR29vZ2xlIFFVSUMgY3VycmVudGx5DQo+IHNwZWNp YWwtY2FzZXMgdGhlIHNhbWUgc2VtYW50aWNzIHRvIGEgUlNUX1NUUkVBTSB3aXRoIGEgc3BlY2lm aWMgZXJyb3IgY29kZS4NCj4gKFRoZXJlIGlzIGEgVE9ETyBpbiB0aGUgdGV4dCB0byB3cml0ZSB1 cCB0aGlzIOKAnHNwZWNpYWwgY2FzZS7igJ0pICBNeSBzZW5zZSBvZg0KPiB0aGUgY29uc2Vuc3Vz IGF0IHRoZSBpbnRlcmltIHdhcyB0aGF0IHNwZWNpYWwgY2FzaW5nIHBhcnRpY3VsYXIgZXJyb3Ig Y29kZXMNCj4gZmVsdCBoYWNreSwgYW5kIHRoZXJlIHdhcyBtb2RlcmF0ZSBzdXBwb3J0IGZvciBt YWtpbmcgaXQgYSBkaWZmZXJlbnQgZnJhbWUNCj4gdHlwZSBhbHRvZ2V0aGVyLCBidXQgcGVvcGxl IHdhbnRlZCB0byBsb29rIGF0IHRoZSBQUiBpbiBtb3JlIGRldGFpbC4NCj4NCj4NCj4NCj4gQXQg TWFydGlu4oCZcyBzdWdnZXN0aW9uLCB0aGUgZnJhbWUgaW4gdGhlIFBSIGhhcyBiZWVuIHJlbmFt ZWQgdG8gRElTSU5URVJFU1QuDQo+IEl04oCZcyBhbiBleHBsaWNpdCBzaWduYWwgdGhhdCBpbmNv bWluZyBkYXRhIGlzIG5vdCBiZWluZyByZWFkIGJ5IHRoZQ0KPiBhcHBsaWNhdGlvbiBhbmQgd2ls bCBiZSBkaXNjYXJkZWQgYnkgdGhlIHRyYW5zcG9ydCB1cG9uIHJlY2VpcHQ7IHRoZQ0KPiByZWNl aXZlciBvZiBhIERJU0lOVEVSRVNUIGZyYW1lIGlzIHN1Z2dlc3RlZCB0byBhYnJ1cHRseSB0ZXJt aW5hdGUgdGhlDQo+IHN0cmVhbSBpbiBxdWVzdGlvbi4gIEluIHRlcm1zIG9mIGFwcGxpY2F0aW9u IEFQSSwgdGhpbmsgb2YgaXQgYXMgdGhlIHdpcmUNCj4gc2lnbmFsIHRoYXQgdGhlIHJlYWQgaGFu ZGxlIGhhcyBiZWVuIGNsb3NlZC4NCj4NCj4NCj4NCj4gSSB0aGluayB0aGlzIHNob3VsZCBleHBs aWNpdGx5IG5vdCBiZSBhIHNwZWNpYWwgY2FzZSBvZiBhIFJTVF9TVFJFQU0gZXJyb3INCj4gY29k ZSwgYmVjYXVzZSBpdCBoYXMgZGlmZmVyZW50IHNlbWFudGljcyBhcm91bmQgcmV0cmFuc21pc3Np b25zLiAgSW4NCj4gcGFydGljdWxhciwgdGhlIHNlbmRlciBvZiBhIERJU0lOVEVSRVNUIGZyYW1l IG1pZ2h0IHN0aWxsIGJlIHNlbmRpbmcgZGF0YSwNCj4gc3RpbGwgYmUgcmV0cmFuc21pdHRpbmcg bG9zdCBTVFJFQU0gZnJhbWVzLCBhbmQgc3RpbGwgZXhwZWN0aW5nIHRoYXQgZGF0YSB0bw0KPiBi ZSBjb25zdW1lZC4gIEEgc3BlY2lhbCBjYXNlIGFyb3VuZCB3aGV0aGVyIHRvIHByb2Nlc3MgdGhl IGluY29taW5nIGRhdGEsIEkNCj4gY291bGQgYWNjZXB0OyBhIHNwZWNpYWwgY2FzZSBhcm91bmQg d2hldGhlciByZXRyYW5zbWlzc2lvbiBpcyBzdGlsbCBlbmFibGVkDQo+IG9uIHRoZSBzdHJlYW0g ZmVlbHMgcmVhbGx5IHdyb25nLg0KPg0KPg0KPg0KPiBJbiBvcmRlciB0byBlbmFibGUgdGhpcywg dGhlIFBSIGNoYW5nZXMgdGhlIHNlbWFudGljcyBvZiBSU1RfU1RSRUFNIGFzIHdlbGwuDQo+IFN0 cmVhbXMgY29uc2lzdCBvZiBhIGRhdGEgY2hhbm5lbCBpbiBlYWNoIGRpcmVjdGlvbi4gIFRoYXQg ZGF0YSBjaGFubmVsIGNhbg0KPiBiZSBjbG9zZWQgY2xlYW5seSAoRklOKSBvciBhYnJ1cHRseSAo UlNUX1NUUkVBTSkgaW4gZWFjaCBkaXJlY3Rpb24uICBJZg0KPiBjbGVhbmx5LCBkYXRhIGdldHMg cmV0cmFuc21pdHRlZCBpbiB0aGF0IGRpcmVjdGlvbi4gIElmIGFicnVwdGx5LCBub3RoaW5nDQo+ IG1vcmUgd2lsbCBiZSBzZW50LCB3aGV0aGVyIGl0IGdvdCB0aHJvdWdoIG9yIG5vdC4gIE9ubHkg dGhlIHNlbmRlciBjYW4gY2xvc2UNCj4gdGhlaXIgZGF0YSBjaGFubmVsLCBhbmQgb25seSB0aGV5 IGRlY2lkZSBob3cgYW5kIHdoZW4gaXQgY2xvc2VzLiAgKFRob3VnaA0KPiBESVNJTlRFUkVTVCBp cyBhIHN0cm9uZyBzaWduYWwgdGhlcmXigJlzIG5vIHBvaW50IGluIGNvbnRpbnVpbmcgdG8gdHJh bnNtaXQuKQ0KPg0KPg0KPg0KPiBJbiBUb2t5bywgd2Ugc2FpZCB3ZSB3YW50ZWQgdG8gd2FpdCB3 aGlsZSBmb2xrcyByZXZpZXdlZCB0aGUgUFIuICBXZeKAmXZlIGhhZA0KPiBhIG1vbnRoLCBhbmQg SeKAmXZlIGdvdHRlbiBzb21lIGdvb2QgZmVlZGJhY2sgZnJvbSBvbmUgbW9yZSBwZXJzb24gKHRo YW5rcywNCj4gTHVjYXMhKS4gIEhhdmUgcGVvcGxlIHJldmlld2VkIGFuZCBhcmUgb2theSB3aXRo IGl0PyAgSGF2ZSBwZW9wbGUgbm90IGxvb2tlZA0KPiBhbmQgdmlvbGVudGx5IGRpc2FncmVlPyAg SWYgc28sIGxldOKAmXMgZGlzY3Vzcy4gIFdlIHN0aWxsIGhhdmUgYSBmZXcgZGF5cw0KPiBiZWZv cmUgdGhlIGRyYWZ0IGRlYWRsaW5lOyBtYXliZSB3ZSBjYW4gcmVhY2ggY29uc2Vuc3VzIGJlZm9y ZSAtMDI/DQoNCg== --_000_BN6PR03MB2708F4FFEA21ECC0852A06EB872E0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIGEgZ29vZCBwb2ludCDigJMgdGhlIFBSIGN1cnJl bnRseSBkaXNjdXNzZXMgdGhlIGltcGFjdCBvbiBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJv bCAoZXZlcnl0aGluZyB3b3JrcyBsaWtlIG5vcm1hbCksIGJ1dCBkb2VzbuKAmXQgZGlzY3VzcyB3 aGF0IGVpdGhlciBwYXJ0eSBzaG91bGQgZG8gd2l0aCBzdHJlYW0tbGV2ZWwgZmxvdyBjb250cm9s LiZuYnNwOyBQcm9iYWJseSBqdXN0IGxldHRpbmcgaXQgYmxvY2sNCiBpcyBmaW5lIOKAkyB0aGUg c2VuZGVyIHdpbGwgcHJvYmFibHkgc2VlIHRoZSBESVNJTlRFUkVTVCBiZWZvcmUgdGhleSBnZXQg YmxvY2tlZCwgYW5kIGlmIG5vdCwgdGhlcmXigJlzIG5vIGhhcm0uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUnlhbiBIYW1pbHRv biBbbWFpbHRvOnJjaEBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFy Y2ggNywgMjAxNyA2OjQwIFBNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFy dGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBCaXNob3AgJmx0 O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBESVNJTlRFUkVTVCBmcmFtZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+U291bmRzIHJlYXNvbmFi bGUgdG8gbWUuIFdlIHNob3VsZCBhbHNvIGNsYXJpZnkgdGhlIGltcGFjdCBpdCBoYXMgb24gZmxv dy1jb250cm9sLiBJIGFzc3VtZSB0aGF0IHNpbmNlIHRoZSBzZW5kZXIgb2Ygc3VjaCBhIGZyYW1l IHdpbGwgbm90IGJlIHJlYWRpbmcsIHRoZSByZWNlaXZlciBvZiB0aGUgZnJhbWUgKGFuZCB0aGUN CiBzZW5kZXIgb2YgZGF0YSkgbmVlZHMgdG8gc3RvcCBzZW5kaW5nIHNpbmNlIGl0IHdpbGwgbm90 IGJlIHJlY2VpdmluZyBmbG93IGNvbnRyb2wgdXBkYXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+ V2UnbGwgYWxzbyB3YW50IHRvIGNsYXJpZnkgdGhlIEhUVFAgbWFwcGluZyBzaW5jZSBIVFRQLzIg ZGVmaW5lcyB0aGUgUlNUX1NUUkVBTSAmIzQzOyBOT19FUlJPUiBzZW1hbnRpY3MgdGhhdCBpcyBs ZXZlcmFnZWQgaW4gdGhlIGN1cnJlbnQgUVVJQyBkb2MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1 dCB0aGVzZSBhcmUgYm90aCBtaW5vciBwb2ludHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA3LCAyMDE3IGF0 IDU6MzQgUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayB0aGF0IHRoaXMgaXMgYSBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rpb24u Jm5ic3A7IFdlIGhhdmUgdXNlIGNhc2VzPGJyPg0KdGhhdCB0aGlzIHNlcnZlcy48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpPbiA4IE1hcmNoIDIwMTcgYXQgMDU6NDUsIE1pa2UgQmlzaG9w ICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSI+TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgQXQgdGhlIFRv a3lvIGludGVyaW0sIHdlIGhhZCBhIGRpc2N1c3Npb24gYXJvdW5kIElzc3VlICMxNjUsIFBSICMx NzE8YnI+DQomZ3Q7IHByb3Bvc2luZyBhIFJFUVVFU1RfUlNUIGZyYW1lLCBhbmQgdGhlIGZhY3Qg dGhhdCBHb29nbGUgUVVJQyBjdXJyZW50bHk8YnI+DQomZ3Q7IHNwZWNpYWwtY2FzZXMgdGhlIHNh bWUgc2VtYW50aWNzIHRvIGEgUlNUX1NUUkVBTSB3aXRoIGEgc3BlY2lmaWMgZXJyb3IgY29kZS48 YnI+DQomZ3Q7IChUaGVyZSBpcyBhIFRPRE8gaW4gdGhlIHRleHQgdG8gd3JpdGUgdXAgdGhpcyDi gJxzcGVjaWFsIGNhc2Uu4oCdKSZuYnNwOyBNeSBzZW5zZSBvZjxicj4NCiZndDsgdGhlIGNvbnNl bnN1cyBhdCB0aGUgaW50ZXJpbSB3YXMgdGhhdCBzcGVjaWFsIGNhc2luZyBwYXJ0aWN1bGFyIGVy cm9yIGNvZGVzPGJyPg0KJmd0OyBmZWx0IGhhY2t5LCBhbmQgdGhlcmUgd2FzIG1vZGVyYXRlIHN1 cHBvcnQgZm9yIG1ha2luZyBpdCBhIGRpZmZlcmVudCBmcmFtZTxicj4NCiZndDsgdHlwZSBhbHRv Z2V0aGVyLCBidXQgcGVvcGxlIHdhbnRlZCB0byBsb29rIGF0IHRoZSBQUiBpbiBtb3JlIGRldGFp bC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEF0IE1hcnRpbuKAmXMg c3VnZ2VzdGlvbiwgdGhlIGZyYW1lIGluIHRoZSBQUiBoYXMgYmVlbiByZW5hbWVkIHRvIERJU0lO VEVSRVNULjxicj4NCiZndDsgSXTigJlzIGFuIGV4cGxpY2l0IHNpZ25hbCB0aGF0IGluY29taW5n IGRhdGEgaXMgbm90IGJlaW5nIHJlYWQgYnkgdGhlPGJyPg0KJmd0OyBhcHBsaWNhdGlvbiBhbmQg d2lsbCBiZSBkaXNjYXJkZWQgYnkgdGhlIHRyYW5zcG9ydCB1cG9uIHJlY2VpcHQ7IHRoZTxicj4N CiZndDsgcmVjZWl2ZXIgb2YgYSBESVNJTlRFUkVTVCBmcmFtZSBpcyBzdWdnZXN0ZWQgdG8gYWJy dXB0bHkgdGVybWluYXRlIHRoZTxicj4NCiZndDsgc3RyZWFtIGluIHF1ZXN0aW9uLiZuYnNwOyBJ biB0ZXJtcyBvZiBhcHBsaWNhdGlvbiBBUEksIHRoaW5rIG9mIGl0IGFzIHRoZSB3aXJlPGJyPg0K Jmd0OyBzaWduYWwgdGhhdCB0aGUgcmVhZCBoYW5kbGUgaGFzIGJlZW4gY2xvc2VkLjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGluayB0aGlzIHNob3VsZCBleHBs aWNpdGx5IG5vdCBiZSBhIHNwZWNpYWwgY2FzZSBvZiBhIFJTVF9TVFJFQU0gZXJyb3I8YnI+DQom Z3Q7IGNvZGUsIGJlY2F1c2UgaXQgaGFzIGRpZmZlcmVudCBzZW1hbnRpY3MgYXJvdW5kIHJldHJh bnNtaXNzaW9ucy4mbmJzcDsgSW48YnI+DQomZ3Q7IHBhcnRpY3VsYXIsIHRoZSBzZW5kZXIgb2Yg YSBESVNJTlRFUkVTVCBmcmFtZSBtaWdodCBzdGlsbCBiZSBzZW5kaW5nIGRhdGEsPGJyPg0KJmd0 OyBzdGlsbCBiZSByZXRyYW5zbWl0dGluZyBsb3N0IFNUUkVBTSBmcmFtZXMsIGFuZCBzdGlsbCBl eHBlY3RpbmcgdGhhdCBkYXRhIHRvPGJyPg0KJmd0OyBiZSBjb25zdW1lZC4mbmJzcDsgQSBzcGVj aWFsIGNhc2UgYXJvdW5kIHdoZXRoZXIgdG8gcHJvY2VzcyB0aGUgaW5jb21pbmcgZGF0YSwgSTxi cj4NCiZndDsgY291bGQgYWNjZXB0OyBhIHNwZWNpYWwgY2FzZSBhcm91bmQgd2hldGhlciByZXRy YW5zbWlzc2lvbiBpcyBzdGlsbCBlbmFibGVkPGJyPg0KJmd0OyBvbiB0aGUgc3RyZWFtIGZlZWxz IHJlYWxseSB3cm9uZy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IElu IG9yZGVyIHRvIGVuYWJsZSB0aGlzLCB0aGUgUFIgY2hhbmdlcyB0aGUgc2VtYW50aWNzIG9mIFJT VF9TVFJFQU0gYXMgd2VsbC48YnI+DQomZ3Q7IFN0cmVhbXMgY29uc2lzdCBvZiBhIGRhdGEgY2hh bm5lbCBpbiBlYWNoIGRpcmVjdGlvbi4mbmJzcDsgVGhhdCBkYXRhIGNoYW5uZWwgY2FuPGJyPg0K Jmd0OyBiZSBjbG9zZWQgY2xlYW5seSAoRklOKSBvciBhYnJ1cHRseSAoUlNUX1NUUkVBTSkgaW4g ZWFjaCBkaXJlY3Rpb24uJm5ic3A7IElmPGJyPg0KJmd0OyBjbGVhbmx5LCBkYXRhIGdldHMgcmV0 cmFuc21pdHRlZCBpbiB0aGF0IGRpcmVjdGlvbi4mbmJzcDsgSWYgYWJydXB0bHksIG5vdGhpbmc8 YnI+DQomZ3Q7IG1vcmUgd2lsbCBiZSBzZW50LCB3aGV0aGVyIGl0IGdvdCB0aHJvdWdoIG9yIG5v dC4mbmJzcDsgT25seSB0aGUgc2VuZGVyIGNhbiBjbG9zZTxicj4NCiZndDsgdGhlaXIgZGF0YSBj aGFubmVsLCBhbmQgb25seSB0aGV5IGRlY2lkZSBob3cgYW5kIHdoZW4gaXQgY2xvc2VzLiZuYnNw OyAoVGhvdWdoPGJyPg0KJmd0OyBESVNJTlRFUkVTVCBpcyBhIHN0cm9uZyBzaWduYWwgdGhlcmXi gJlzIG5vIHBvaW50IGluIGNvbnRpbnVpbmcgdG8gdHJhbnNtaXQuKTxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gVG9reW8sIHdlIHNhaWQgd2Ugd2FudGVkIHRvIHdh aXQgd2hpbGUgZm9sa3MgcmV2aWV3ZWQgdGhlIFBSLiZuYnNwOyBXZeKAmXZlIGhhZDxicj4NCiZn dDsgYSBtb250aCwgYW5kIEnigJl2ZSBnb3R0ZW4gc29tZSBnb29kIGZlZWRiYWNrIGZyb20gb25l IG1vcmUgcGVyc29uICh0aGFua3MsPGJyPg0KJmd0OyBMdWNhcyEpLiZuYnNwOyBIYXZlIHBlb3Bs ZSByZXZpZXdlZCBhbmQgYXJlIG9rYXkgd2l0aCBpdD8mbmJzcDsgSGF2ZSBwZW9wbGUgbm90IGxv b2tlZDxicj4NCiZndDsgYW5kIHZpb2xlbnRseSBkaXNhZ3JlZT8mbmJzcDsgSWYgc28sIGxldOKA mXMgZGlzY3Vzcy4mbmJzcDsgV2Ugc3RpbGwgaGF2ZSBhIGZldyBkYXlzPGJyPg0KJmd0OyBiZWZv cmUgdGhlIGRyYWZ0IGRlYWRsaW5lOyBtYXliZSB3ZSBjYW4gcmVhY2ggY29uc2Vuc3VzIGJlZm9y ZSAtMDI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708F4FFEA21ECC0852A06EB872E0BN6PR03MB2708namp_-- From nobody Wed Mar 8 09:10:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2742C1270B4 for ; Wed, 8 Mar 2017 09:10:22 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 sRp_nFnzUaZh for ; Wed, 8 Mar 2017 09:10:20 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9B24F12947B for ; Wed, 8 Mar 2017 09:10:20 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1470416C019; Wed, 8 Mar 2017 17:10:20 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id E8B3216BE2A; Wed, 8 Mar 2017 17:10:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488993019; bh=QfZpn1xUHddEQiYx453l+t1SpLIKqGh7ea/jWIw6rP4=; l=13732; h=From:To:CC:Date:References:In-Reply-To:From; b=KwerOa+Q80pbpzmy+vFV2bzhvRPYLIl9mJw12d50Va3W0hp8ozvwnxzPHf/noK5Ei 6Bifa15DlcWFZWCT/da5qXIRGJzLXCACE7SxlO2Nupwc6FfuoZxozC0rb8zwZk4nWl vA3T2j6vRBTgExnHj+HORA8RgyecI6lywSdrg6mI= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id BE5A01E080; Wed, 8 Mar 2017 17:10:19 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Mar 2017 12:10:19 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Mar 2017 12:10:18 -0500 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.1178.000; Wed, 8 Mar 2017 12:10:18 -0500 From: "Lubashev, Igor" To: Ian Swett , Martin Thomson Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AD//9VqgP//sP/mgABUcAD//7V6AIAAVDuA//+uD6IACrPRAAAVSHYAAAXDLkA= Date: Wed, 8 Mar 2017 17:10:17 +0000 Message-ID: <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.30] Content-Type: multipart/alternative; boundary="_000_890aa285e7244443a12594c6f399245eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:10:22 -0000 --_000_890aa285e7244443a12594c6f399245eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIHlvdSBkZWZpbml0ZWx5IG5lZWQgIlJTVF9TVFJFQU0gaXMgc2VudCB1bmxlc3MgYWxsIG91 dHN0YW5kaW5nIGRhdGEgaGFzIGJlZW4gc2VudCBBTkQgYWNrbm93bGVkZ2VkLiIsIG90aGVyd2lz ZSB0aGUgcGVlciB3YWl0cyBmb3JldmVyIGZvciBkYXRhIHRoYXQgd29uJ3QgYXJyaXZlLg0KDQoN CkkgZ3Vlc3MgdGhpcyBpcyB0aGUgY29yZSBvZiB0aGUgcXVlc3Rpb24sIHdoaWNoIGdvZXMgYmV5 b25kIHRoZSBjaG9pY2UgZm9yIHRoaXMgcmFyZSBjb25kaXRpb24uIOKAnEl0IGlzIHJlYXNvbmFi bGUgdG8gdGhpbmsgdGhhdCB0aGUgcGVlciB3aG8gc2VudCBESVNJTlRFUkVTVCBpcyBzdGlsbCB3 YWl0aW5nIGZvciBhbnkgZGF0YT/igJ0gIFRoZSB3aG9sZSBwb2ludCBvZiBESVNJTlRFUkVTVCBp cyB0byBpbmRpY2F0ZSB0aGF0IOKAnEkgYW0gbm90IHdhaXRpbmcgZm9yIGFueSBtb3JlIGRhdGHi gJ0uDQoNCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNl bnQ6IFdlZG5lc2RheSwgTWFyY2ggMDgsIDIwMTcgOTo1MSBBTQ0KVG86IE1hcnRpbiBUaG9tc29u IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb20+OyBNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tOyBxdWljQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogRElTSU5URVJFU1QgZnJhbWUNCg0KTWFydGluJ3MgcmlnaHQsIHlvdSBk ZWZpbml0ZWx5IG5lZWQgIlJTVF9TVFJFQU0gaXMgc2VudCB1bmxlc3MgYWxsIG91dHN0YW5kaW5n IGRhdGEgaGFzIGJlZW4gc2VudCBBTkQgYWNrbm93bGVkZ2VkLiIsIG90aGVyd2lzZSB0aGUgcGVl ciB3YWl0cyBmb3JldmVyIGZvciBkYXRhIHRoYXQgd29uJ3QgYXJyaXZlLg0KDQpRdWVzdGlvbjog V2h5IGNhbGwgaXQgRElTSU5URVJFU1QsIGluc3RlYWQgb2YgUkVRVUVTVF9SU1Q/ICBJdCB3YXNu J3Qgb2J2aW91cyB0byBtZSB3aGF0IERJU0lOVEVSRVNUIHdhcyB1bnRpbCBJIHJlYWQgZnVydGhl ciwgd2hlcmVhcyBSRVFVRVNUX1JTVCBpcyBwcmV0dHkgb2J2aW91cywgYXNzdW1pbmcgeW91IGtu b3cgYWJvdXQgUlNUX1NUUkVBTS4NCg0KT24gVHVlLCBNYXIgNywgMjAxNyBhdCAxMTo0MSBQTSwg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiA4IE1hcmNoIDIwMTcgYXQgMTU6MzUsIEx1YmFz aGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Pj4gd3JvdGU6DQo+IFdlIGFyZSB0YWtpbmcgYWJvdXQgYSBjYXNlIHdoZW4gdGhlIHNlbmRlciBv ZiB0aGUgc3RyZWFtIGlzIGFscmVhZHkgaW4NCj4gImhhbGYtY2xvc2VkIChsb2NhbCkiIChvciAi Y2xvc2VkIikgYW5kIHRoZSByZWNlaXZlciBpcyBhbHJlYWR5IGluDQo+ICJoYWxmLWNsb3NlZCAo cmVtb3RlKSIgKG9yICJjbG9zZWQiKS4gVGhpcyBSU1RfU1RSRUFNIHdpbGwgbm90IGFmZmVjdCB0 aGUNCj4gc3RhdGUgb2YgdGhlIHN0cmVhbSBmb3IgYW55IHBlZXIuIFRoZSBvbmx5IGluZm9ybWF0 aW9uIFJTVF9TVFJFQU0gY29udGFpbnMNCj4gbm93IGlzICJJIHdpbGwgbm90IHRyYW5zbWl0Ii4g QnV0IHRoZSBwZWVyIGFscmVhZHkgc2VudCBESVNJTlRFUkVTVEVEIHRvDQo+IGluZGljYXRlIGl0 IGRvZXMgbm90IGNhcmUgYWJvdXQgcmV0cmFuc21pc3Npb25zLg0KDQpFdmVuIGFmdGVyIGNsb3Np bmcgYSBzdHJlYW0sIGFuIGVuZHBvaW50IG5lZWRzIHRvIHJldHJhbnNtaXQgZGF0YS4gIEl0DQpj bG9zZXMgd2hlbiBpdCBmaXJzdCBzZW5kcyB0aGUgRklOLg0KDQo= --_000_890aa285e7244443a12594c6f399245eusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNDYzODY5Njg7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTgxNTg2MjY4IC0x NTkwMTM4NDQ0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+eW91IGRlZmluaXRl bHkgbmVlZCAmcXVvdDtSU1RfU1RSRUFNIGlzIHNlbnQgdW5sZXNzIGFsbCBvdXRzdGFuZGluZyBk YXRhIGhhcyBiZWVuIHNlbnQgQU5EIGFja25vd2xlZGdlZC4mcXVvdDssIG90aGVyd2lzZSB0aGUg cGVlciB3YWl0cyBmb3JldmVyIGZvciBkYXRhIHRoYXQgd29uJ3QgYXJyaXZlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SSBndWVzcyB0aGlzIGlzIHRoZSBjb3JlIG9mIHRoZSBxdWVzdGlvbiwgd2hpY2gg Z29lcyBiZXlvbmQgdGhlIGNob2ljZSBmb3IgdGhpcyByYXJlIGNvbmRpdGlvbi4g4oCcSXQgaXMg cmVhc29uYWJsZSB0byB0aGluayB0aGF0IHRoZSBwZWVyIHdobyBzZW50IERJU0lOVEVSRVNUIGlz IHN0aWxsIHdhaXRpbmcNCiBmb3IgYW55IGRhdGE/4oCdJm5ic3A7IFRoZSB3aG9sZSBwb2ludCBv ZiBESVNJTlRFUkVTVCBpcyB0byBpbmRpY2F0ZSB0aGF0IOKAnEkgYW0gPGk+bm90PC9pPiB3YWl0 aW5nIGZvciBhbnkgbW9yZSBkYXRh4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0 dEBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDgsIDIw MTcgOTo1MSBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9t c29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHVi YXNoZUBha2FtYWkuY29tJmd0OzsgTWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTsgcXVpY0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRElTSU5URVJFU1QgZnJhbWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJ0aW4ncyByaWdodCwgeW91IGRlZmlu aXRlbHkgbmVlZCAmcXVvdDtSU1RfU1RSRUFNIGlzIHNlbnQgdW5sZXNzIGFsbCBvdXRzdGFuZGlu ZyBkYXRhIGhhcyBiZWVuIHNlbnQgQU5EIGFja25vd2xlZGdlZC4mcXVvdDssIG90aGVyd2lzZSB0 aGUgcGVlciB3YWl0cyBmb3JldmVyIGZvciBkYXRhIHRoYXQgd29uJ3QgYXJyaXZlLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UXVlc3Rpb246IFdoeSBjYWxs IGl0IERJU0lOVEVSRVNULCBpbnN0ZWFkIG9mIFJFUVVFU1RfUlNUPyZuYnNwOyBJdCB3YXNuJ3Qg b2J2aW91cyB0byBtZSB3aGF0IERJU0lOVEVSRVNUIHdhcyB1bnRpbCBJIHJlYWQgZnVydGhlciwg d2hlcmVhcyBSRVFVRVNUX1JTVCBpcyBwcmV0dHkgb2J2aW91cywgYXNzdW1pbmcgeW91IGtub3cg YWJvdXQgUlNUX1NUUkVBTS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgNywgMjAxNyBhdCAxMTo0MSBQTSwgTWFydGluIFRo b21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPk9uIDggTWFyY2ggMjAxNyBhdCAxNTozNSwgTHViYXNoZXYsIElnb3Ig Jmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWku Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBXZSBhcmUgdGFraW5nIGFib3V0IGEgY2FzZSB3 aGVuIHRoZSBzZW5kZXIgb2YgdGhlIHN0cmVhbSBpcyBhbHJlYWR5IGluPGJyPg0KJmd0OyAmcXVv dDtoYWxmLWNsb3NlZCAobG9jYWwpJnF1b3Q7IChvciAmcXVvdDtjbG9zZWQmcXVvdDspIGFuZCB0 aGUgcmVjZWl2ZXIgaXMgYWxyZWFkeSBpbjxicj4NCiZndDsgJnF1b3Q7aGFsZi1jbG9zZWQgKHJl bW90ZSkmcXVvdDsgKG9yICZxdW90O2Nsb3NlZCZxdW90OykuIFRoaXMgUlNUX1NUUkVBTSB3aWxs IG5vdCBhZmZlY3QgdGhlPGJyPg0KJmd0OyBzdGF0ZSBvZiB0aGUgc3RyZWFtIGZvciBhbnkgcGVl ci4gVGhlIG9ubHkgaW5mb3JtYXRpb24gUlNUX1NUUkVBTSBjb250YWluczxicj4NCiZndDsgbm93 IGlzICZxdW90O0kgd2lsbCBub3QgdHJhbnNtaXQmcXVvdDsuIEJ1dCB0aGUgcGVlciBhbHJlYWR5 IHNlbnQgRElTSU5URVJFU1RFRCB0bzxicj4NCiZndDsgaW5kaWNhdGUgaXQgZG9lcyBub3QgY2Fy ZSBhYm91dCByZXRyYW5zbWlzc2lvbnMuPGJyPg0KPGJyPg0KRXZlbiBhZnRlciBjbG9zaW5nIGEg c3RyZWFtLCBhbiBlbmRwb2ludCBuZWVkcyB0byByZXRyYW5zbWl0IGRhdGEuJm5ic3A7IEl0PGJy Pg0KY2xvc2VzIHdoZW4gaXQgZmlyc3Qgc2VuZHMgdGhlIEZJTi48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_890aa285e7244443a12594c6f399245eusma1exdag1mb5msgcorpak_-- From nobody Wed Mar 8 09:18:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD762129511 for ; Wed, 8 Mar 2017 09:18:37 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 R9EVZNGWmB31 for ; Wed, 8 Mar 2017 09:18:36 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 451371294E4 for ; Wed, 8 Mar 2017 09:18:36 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 03C0B16C975; Wed, 8 Mar 2017 17:18:36 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id DC88616C912; Wed, 8 Mar 2017 17:18:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488993515; bh=zLc9NciEIZMKjjw9xz9zyjvz+bE8rOtipmSAAjoY+jk=; l=21044; h=From:To:CC:Date:References:In-Reply-To:From; b=G7PhKcptFyB1SIysFRjN+gsYbsaDskyrQs5ZMaBymjtG4AM8ibEnHSbo3XIS+0RHQ MFDYcrATyHOiRPsP42p1+Msc5fL+CTwpxYdKIILMtHbG8k6/BYa1KkksgIYDAhCIrs Qzphj7YgFr7MhW6yPcqQPtYs9l9x5U60L06E0KSY= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 923D398084; Wed, 8 Mar 2017 17:18:35 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 8 Mar 2017 12:18:34 -0500 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.1178.000; Wed, 8 Mar 2017 12:18:34 -0500 From: "Lubashev, Igor" To: "Lubashev, Igor" , Ian Swett , Martin Thomson Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AD//9VqgP//sP/mgABUcAD//7V6AIAAVDuA//+uD6IACrPRAAAVSHYAAAXDLkAACzgJ8A== Date: Wed, 8 Mar 2017 17:18:33 +0000 Message-ID: <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com> References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.30] Content-Type: multipart/alternative; boundary="_000_07b1d227554f4b57a6da37c6a0a0c811usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:18:38 -0000 --_000_07b1d227554f4b57a6da37c6a0a0c811usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UC5TLg0KICBUaGUgcGFyYWdyYXBoIGFib3ZlIHN0YXRlczoNCg0KDQrDmCAgW1NUUkVBTSBmcmFt ZXMgcmVjZWl2ZWQgYWZ0ZXIgc2VuZGluZyBESVNJTlRFUkVTVF0gd2lsbCBiZSBkaXNjYXJkZWQN Cg0KU28gSSByZWFkIGl0IHRoYXQgdGhlIHBlZXIgd2hvIHNlbmQgRElTSU5URVJFU1Qgd2lsbCBu b3QgYmUgd2FpdGluZyBmb3IgdGhhdCBkYXRhLiAgVGhhdCBwZWVyIGRvZXMgbm90IG5lZWQgYW55 IGFjY291bnRpbmcgZm9yIGZsb3cgY29udHJvbCBlaXRoZXIsIHNpbmNlIGhlIGhhcyBhbHJlYWR5 IHJlY2VpdmVkIHRoZSBGSU4gKHdpdGggdGhlIGJ5dGUgb2Zmc2V0KSBhbmQgaXMgYWxyZWFkeSBp biDigJxoYWxmLWNsb3NlZCAocmVtb3RlKeKAnSBvciDigJxjbG9zZWTigJ0gc3RhdGUuDQoNCg0K RnJvbTogTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXQ0KU2VudDog V2VkbmVzZGF5LCBNYXJjaCAwOCwgMjAxNyAxMjoxMCBQTQ0KVG86IElhbiBTd2V0dCA8aWFuc3dl dHRAZ29vZ2xlLmNvbT47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+ DQpDYzogTWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTsgcXVpY0BpZXRmLm9yZw0KU3ViamVj dDogUkU6IERJU0lOVEVSRVNUIGZyYW1lDQoNCg0Kw5ggIHlvdSBkZWZpbml0ZWx5IG5lZWQgIlJT VF9TVFJFQU0gaXMgc2VudCB1bmxlc3MgYWxsIG91dHN0YW5kaW5nIGRhdGEgaGFzIGJlZW4gc2Vu dCBBTkQgYWNrbm93bGVkZ2VkLiIsIG90aGVyd2lzZSB0aGUgcGVlciB3YWl0cyBmb3JldmVyIGZv ciBkYXRhIHRoYXQgd29uJ3QgYXJyaXZlLg0KDQoNCkkgZ3Vlc3MgdGhpcyBpcyB0aGUgY29yZSBv ZiB0aGUgcXVlc3Rpb24sIHdoaWNoIGdvZXMgYmV5b25kIHRoZSBjaG9pY2UgZm9yIHRoaXMgcmFy ZSBjb25kaXRpb24uIOKAnEl0IGlzIHJlYXNvbmFibGUgdG8gdGhpbmsgdGhhdCB0aGUgcGVlciB3 aG8gc2VudCBESVNJTlRFUkVTVCBpcyBzdGlsbCB3YWl0aW5nIGZvciBhbnkgZGF0YT/igJ0gIFRo ZSB3aG9sZSBwb2ludCBvZiBESVNJTlRFUkVTVCBpcyB0byBpbmRpY2F0ZSB0aGF0IOKAnEkgYW0g bm90IHdhaXRpbmcgZm9yIGFueSBtb3JlIGRhdGHigJ0uDQoNCg0KRnJvbTogSWFuIFN3ZXR0IFtt YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDgsIDIw MTcgOTo1MSBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208 bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+DQpDYzogTHViYXNoZXYsIElnb3IgPGls dWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PjsgTWljaGFlbC5C aXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT47 IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogRElTSU5U RVJFU1QgZnJhbWUNCg0KTWFydGluJ3MgcmlnaHQsIHlvdSBkZWZpbml0ZWx5IG5lZWQgIlJTVF9T VFJFQU0gaXMgc2VudCB1bmxlc3MgYWxsIG91dHN0YW5kaW5nIGRhdGEgaGFzIGJlZW4gc2VudCBB TkQgYWNrbm93bGVkZ2VkLiIsIG90aGVyd2lzZSB0aGUgcGVlciB3YWl0cyBmb3JldmVyIGZvciBk YXRhIHRoYXQgd29uJ3QgYXJyaXZlLg0KDQpRdWVzdGlvbjogV2h5IGNhbGwgaXQgRElTSU5URVJF U1QsIGluc3RlYWQgb2YgUkVRVUVTVF9SU1Q/ICBJdCB3YXNuJ3Qgb2J2aW91cyB0byBtZSB3aGF0 IERJU0lOVEVSRVNUIHdhcyB1bnRpbCBJIHJlYWQgZnVydGhlciwgd2hlcmVhcyBSRVFVRVNUX1JT VCBpcyBwcmV0dHkgb2J2aW91cywgYXNzdW1pbmcgeW91IGtub3cgYWJvdXQgUlNUX1NUUkVBTS4N Cg0KT24gVHVlLCBNYXIgNywgMjAxNyBhdCAxMTo0MSBQTSwgTWFydGluIFRob21zb24gPG1hcnRp bi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3Jv dGU6DQpPbiA4IE1hcmNoIDIwMTcgYXQgMTU6MzUsIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBh a2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4gd3JvdGU6DQo+IFdlIGFyZSB0 YWtpbmcgYWJvdXQgYSBjYXNlIHdoZW4gdGhlIHNlbmRlciBvZiB0aGUgc3RyZWFtIGlzIGFscmVh ZHkgaW4NCj4gImhhbGYtY2xvc2VkIChsb2NhbCkiIChvciAiY2xvc2VkIikgYW5kIHRoZSByZWNl aXZlciBpcyBhbHJlYWR5IGluDQo+ICJoYWxmLWNsb3NlZCAocmVtb3RlKSIgKG9yICJjbG9zZWQi KS4gVGhpcyBSU1RfU1RSRUFNIHdpbGwgbm90IGFmZmVjdCB0aGUNCj4gc3RhdGUgb2YgdGhlIHN0 cmVhbSBmb3IgYW55IHBlZXIuIFRoZSBvbmx5IGluZm9ybWF0aW9uIFJTVF9TVFJFQU0gY29udGFp bnMNCj4gbm93IGlzICJJIHdpbGwgbm90IHRyYW5zbWl0Ii4gQnV0IHRoZSBwZWVyIGFscmVhZHkg c2VudCBESVNJTlRFUkVTVEVEIHRvDQo+IGluZGljYXRlIGl0IGRvZXMgbm90IGNhcmUgYWJvdXQg cmV0cmFuc21pc3Npb25zLg0KDQpFdmVuIGFmdGVyIGNsb3NpbmcgYSBzdHJlYW0sIGFuIGVuZHBv aW50IG5lZWRzIHRvIHJldHJhbnNtaXQgZGF0YS4gIEl0DQpjbG9zZXMgd2hlbiBpdCBmaXJzdCBz ZW5kcyB0aGUgRklOLg0KDQo= --_000_07b1d227554f4b57a6da37c6a0a0c811usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo5MzA3MDAwNzE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjY2MDIxMTgxMiAxNzE2Nzk1MjM0IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTY7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjExNDYzODY5Njg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xNTgxNTg2MjY4IC0xNTkwMTM4NDQ0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwx OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+UC5TLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7IFRoZSBwYXJhZ3JhcGggYWJvdmUgc3RhdGVz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1NUUkVBTSBmcmFt ZXMgcmVjZWl2ZWQgYWZ0ZXIgc2VuZGluZyBESVNJTlRFUkVTVF0gd2lsbCBiZSBkaXNjYXJkZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+U28gSSByZWFkIGl0IHRoYXQgdGhlIHBlZXIgd2hvIHNlbmQgRElTSU5U RVJFU1Qgd2lsbA0KPGk+bm90PC9pPiBiZSB3YWl0aW5nIGZvciB0aGF0IGRhdGEuJm5ic3A7IFRo YXQgcGVlciBkb2VzIG5vdCBuZWVkIGFueSBhY2NvdW50aW5nIGZvciBmbG93IGNvbnRyb2wgZWl0 aGVyLCBzaW5jZSBoZSBoYXMgYWxyZWFkeSByZWNlaXZlZCB0aGUgRklOICh3aXRoIHRoZSBieXRl IG9mZnNldCkgYW5kIGlzIGFscmVhZHkgaW4g4oCcaGFsZi1jbG9zZWQgKHJlbW90ZSnigJ0gb3Ig 4oCcY2xvc2Vk4oCdIHN0YXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDgsIDIwMTcgMTI6MTAgUE08YnI+DQo8Yj5Ubzo8 L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IE1hcnRpbiBUaG9tc29u ICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tOyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBESVNJTlRFUkVTVCBmcmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+eW91IGRlZmluaXRlbHkgbmVlZCAmcXVvdDtSU1RfU1RS RUFNIGlzIHNlbnQgdW5sZXNzIGFsbCBvdXRzdGFuZGluZyBkYXRhIGhhcyBiZWVuIHNlbnQgQU5E IGFja25vd2xlZGdlZC4mcXVvdDssIG90aGVyd2lzZSB0aGUgcGVlciB3YWl0cyBmb3JldmVyIGZv ciBkYXRhIHRoYXQgd29uJ3QgYXJyaXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBndWVzcyB0aGlz IGlzIHRoZSBjb3JlIG9mIHRoZSBxdWVzdGlvbiwgd2hpY2ggZ29lcyBiZXlvbmQgdGhlIGNob2lj ZSBmb3IgdGhpcyByYXJlIGNvbmRpdGlvbi4g4oCcSXQgaXMgcmVhc29uYWJsZSB0byB0aGluayB0 aGF0IHRoZSBwZWVyIHdobyBzZW50IERJU0lOVEVSRVNUIGlzIHN0aWxsIHdhaXRpbmcNCiBmb3Ig YW55IGRhdGE/4oCdJm5ic3A7IFRoZSB3aG9sZSBwb2ludCBvZiBESVNJTlRFUkVTVCBpcyB0byBp bmRpY2F0ZSB0aGF0IOKAnEkgYW0gPGk+bm90PC9pPiB3YWl0aW5nIGZvciBhbnkgbW9yZSBkYXRh 4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBJYW4gU3dldHQgWzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29t Ij5tYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBNYXJjaCAwOCwgMjAxNyA5OjUxIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhv bXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGlu LnRob21zb25AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEx1YmFzaGV2LCBJZ29y ICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFp LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b20iPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86cXVp Y0BpZXRmLm9yZyI+DQpxdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog RElTSU5URVJFU1QgZnJhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N YXJ0aW4ncyByaWdodCwgeW91IGRlZmluaXRlbHkgbmVlZCAmcXVvdDtSU1RfU1RSRUFNIGlzIHNl bnQgdW5sZXNzIGFsbCBvdXRzdGFuZGluZyBkYXRhIGhhcyBiZWVuIHNlbnQgQU5EIGFja25vd2xl ZGdlZC4mcXVvdDssIG90aGVyd2lzZSB0aGUgcGVlciB3YWl0cyBmb3JldmVyIGZvciBkYXRhIHRo YXQgd29uJ3QgYXJyaXZlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UXVlc3Rpb246IFdoeSBjYWxsIGl0IERJU0lOVEVSRVNULCBpbnN0ZWFkIG9mIFJFUVVF U1RfUlNUPyZuYnNwOyBJdCB3YXNuJ3Qgb2J2aW91cyB0byBtZSB3aGF0IERJU0lOVEVSRVNUIHdh cyB1bnRpbCBJIHJlYWQgZnVydGhlciwgd2hlcmVhcyBSRVFVRVNUX1JTVCBpcyBwcmV0dHkgb2J2 aW91cywgYXNzdW1pbmcgeW91IGtub3cgYWJvdXQgUlNUX1NUUkVBTS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgNywgMjAx NyBhdCAxMTo0MSBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5PbiA4IE1hcmNoIDIwMTcgYXQgMTU6MzUsIEx1YmFzaGV2LCBJ Z29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWth bWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgV2UgYXJlIHRha2luZyBhYm91dCBhIGNh c2Ugd2hlbiB0aGUgc2VuZGVyIG9mIHRoZSBzdHJlYW0gaXMgYWxyZWFkeSBpbjxicj4NCiZndDsg JnF1b3Q7aGFsZi1jbG9zZWQgKGxvY2FsKSZxdW90OyAob3IgJnF1b3Q7Y2xvc2VkJnF1b3Q7KSBh bmQgdGhlIHJlY2VpdmVyIGlzIGFscmVhZHkgaW48YnI+DQomZ3Q7ICZxdW90O2hhbGYtY2xvc2Vk IChyZW1vdGUpJnF1b3Q7IChvciAmcXVvdDtjbG9zZWQmcXVvdDspLiBUaGlzIFJTVF9TVFJFQU0g d2lsbCBub3QgYWZmZWN0IHRoZTxicj4NCiZndDsgc3RhdGUgb2YgdGhlIHN0cmVhbSBmb3IgYW55 IHBlZXIuIFRoZSBvbmx5IGluZm9ybWF0aW9uIFJTVF9TVFJFQU0gY29udGFpbnM8YnI+DQomZ3Q7 IG5vdyBpcyAmcXVvdDtJIHdpbGwgbm90IHRyYW5zbWl0JnF1b3Q7LiBCdXQgdGhlIHBlZXIgYWxy ZWFkeSBzZW50IERJU0lOVEVSRVNURUQgdG88YnI+DQomZ3Q7IGluZGljYXRlIGl0IGRvZXMgbm90 IGNhcmUgYWJvdXQgcmV0cmFuc21pc3Npb25zLjxicj4NCjxicj4NCkV2ZW4gYWZ0ZXIgY2xvc2lu ZyBhIHN0cmVhbSwgYW4gZW5kcG9pbnQgbmVlZHMgdG8gcmV0cmFuc21pdCBkYXRhLiZuYnNwOyBJ dDxicj4NCmNsb3NlcyB3aGVuIGl0IGZpcnN0IHNlbmRzIHRoZSBGSU4uPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_07b1d227554f4b57a6da37c6a0a0c811usma1exdag1mb5msgcorpak_-- From nobody Wed Mar 8 10:00:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7526E1270B4 for ; Wed, 8 Mar 2017 10:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jlOZYjnZ1AY for ; Wed, 8 Mar 2017 10:00:00 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0103.outbound.protection.outlook.com [104.47.42.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75D51294B2 for ; Wed, 8 Mar 2017 09:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nzqRBtjLS0pGmmCg3SX3Jq2dnK+SceS94TUbCjfRLbc=; b=QIdpEg/95U5q1rxGXv7MONVB+wxlpruUh6PQGvTxOP4hDIf6TXP4ThG5JLZ1yarJU+M2RfrqM5cVXsSoSvta16uzKc0bIm6OIa7tjp789FmNQOE1lT/burVXOiAQop6yQBjd/D8fMaAXFmoUaJCf/ZG0BPJV4iu3RnfkS+PEnFI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 8 Mar 2017 17:53:42 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Wed, 8 Mar 2017 17:53:42 +0000 From: Mike Bishop To: "Lubashev, Igor" , Ian Swett , Martin Thomson Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAO9+SAAAMMFAAAASgWgAAAmhSAAAAT0QAAASltAAAADUSAAAA754AAADmrAAAVSHUAAATbzYAAAEnpgAAAXurg Date: Wed, 8 Mar 2017 17:53:42 +0000 Message-ID: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:b::51f] x-ms-office365-filtering-correlation-id: 79c93c08-0afe-43a6-9450-08d4664c0f48 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:1HlOyufm9bPyddCi8qDM+FxU3vlnP7pVL11BPW56q09dSbRwvTPvcvrxWJ1n0JXBb0IMn0UBHvQc02DJfvxcagznQ6IBsJyRtSm1K27dd44M3HoL97uWk96nsyCO0KlSXge5NerczgcWJ+NCsoWGcOoyIP6Lw1aunS1nhIXXPONhb8gEmPO8x6vVd3vlMFa0E1Z7ui2eaWYVjV4LA7Jn8CbUvpdIO7+sQZXoynM08bSW3wrVPMQZE1jDmTD/OUUl82xem4bwGJztbykTCT8Notc58HnK1zrm2npnlLhxNase5lPIlGFXqSzJa7PpuEXYYJRHmmseLTAZkZwZc7Bhlbz54ezTsSrWx/BV1vLMBr8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(24454002)(377454003)(6436002)(3660700001)(6306002)(99286003)(8936002)(19609705001)(25786008)(3280700002)(6246003)(53546006)(54896002)(5660300001)(81166006)(2906002)(9686003)(221733001)(8676002)(93886004)(38730400002)(53936002)(189998001)(77096006)(2950100002)(229853002)(33656002)(7696004)(6506006)(39060400002)(3480700004)(86362001)(7116003)(236005)(102836003)(7736002)(55016002)(50986999)(76176999)(5005710100001)(2900100001)(86612001)(74316002)(54356999)(122556002)(10290500002)(790700001)(10090500001)(8990500004)(4326008)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708B9AA3E888186562D806D872E0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2017 17:53:42.3232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 18:00:01 -0000 --_000_BN6PR03MB2708B9AA3E888186562D806D872E0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW914oCZcmUgY29ycmVjdCB0aGF0IHRoZSBzZW5kZXIgb2YgRElTSU5URVJFU1Qgbm8gbG9uZ2Vy IGNhcmVzIGFib3V0IHRoZSBkYXRhLCBvdGhlciB0aGFuIGZvciBmbG93IGNvbnRyb2wgYW5kIHN0 YXRlIGNvbnNpc3RlbmN5Lg0KDQpJIGhhZCBiZWVuIHRyeWluZyB0byBhcHByb2FjaCBpdCBmcm9t IGEgcHJpbmNpcGxlIHRoYXQgb25seSB0aGUgc2VuZGVyIGNhbiBhZmZlY3QgdGhlIHN0cmVhbSBz dGF0ZSBpbiB0aGVpciBkaXJlY3Rpb24g4oCTIHRoZSByZWNlaXZlciBjYW4gb25seSByZXF1ZXN0 IGNoYW5nZXMuICBBcyB0aGUgZHJhZnQgY3VycmVudGx5IHJlYWRzLCB0aGUgcmVjZWl2ZXIgY291 bnRzIGZsb3cgY29udHJvbCBhcyBTVFJFQU0gZnJhbWVzIGFyZSByZWNlaXZlZCwgYW5kIHVwb24g cmVjZWlwdCBvZiBhIFJTVF9TVFJFQU0uICBJZiBhIFNUUkVBTSBmcmFtZSBpcyBkZWxheWVkLCBp dCBkb2VzbuKAmXQgKHlldCkgY291bnQgYWdhaW5zdCB0aGUgcmVjZWl2ZXLigJlzIGZsb3cgY29u dHJvbCB3aW5kb3csIGV2ZW4gaWYgaXQgY2FuIGluZmVyIHRoYXQgdGhlIGRhdGEgaGFzIGJlZW4g c2VudCAoYnkgdmlydHVlIG9mIHJlY2VpdmluZyBhIGxhdGVyIG9mZnNldCkuICBPbmx5IHVwb24g cmVjZWlwdCBvZiBhIFJTVF9TVFJFQU0gZG8geW91IGFjY291bnQgYWxsIG91dHN0YW5kaW5nIGRh dGEgYWdhaW5zdCB0aGUgZmxvdyBjb250cm9sIHdpbmRvdy4NCg0KQ2hhbmdpbmcgaXQgc28gdGhh dCBhbGwgZGF0YSB1cCB0byB0aGUgZnVydGhlc3Qgb2Zmc2V0IHJlY2VpdmVkIG9uIGEgc3RyZWFt IGNvdW50cyBpcyBjZXJ0YWlubHkgcG9zc2libGUsIGJ1dCBmZWVscyBsaWtlIGFuIG9ydGhvZ29u YWwgY2hhbmdlIHRvIHRoaXMgUFIuICBJ4oCZdmUgb3BlbmVkIGlzc3VlICMzNzAgZm9yIHRoYXQu ICBJbiB0aGF0IHdvcmxkLCB0aGUgcmVxdWlyZW1lbnQgd291bGQgYmUgdG8gcmVsaWFibHkgZGVs aXZlciBlaXRoZXIgYSBSU1RfU1RSRUFNIG9yIGEgU1RSRUFNIGZyYW1lIHdpdGggdGhlIEZJTiBi aXQgc2V0IChiYXNpY2FsbHksIHlvdSBNVVNUIGNvbW11bmljYXRlIHlvdXIgZmluYWwgb2Zmc2V0 KS4gIFNvIGxvbmcgYXMgb25lIG9mIHRob3NlIGdldHMgdGhyb3VnaCwgRElTSU5URVJFU1QgYnkg aXRzZWxmIGNvdWxkIHN0b3AgcmV0cmFuc21pc3Npb25zLiAgVGhhdCBmZWVscyBtYXJnaW5hbGx5 IG1vcmUgY29tcGxpY2F0ZWQsIHNpbmNlIGl0IGFkZHMgYW4gYWRkaXRpb25hbCBwYXRoIHRvIHN0 b3AgcmV0cmFuc21pc3Npb24gb24gYSBzdHJlYW0gYW5kIG1ha2VzIHRoZSBhY2NvdW50aW5nIGxv Z2ljIG9uIHJlY2VpcHQgb2YgYSBTVFJFQU0gZnJhbWUgbW9yZSBjb21wbGljYXRlZC4NCg0KTXkg aW5jbGluYXRpb24gaXMgdG8gbGVhdmUgcmV0cmFuc21pc3Npb25zIHRpZWQgdG8gaGF2aW5nIHNl bnQgUlNUX1NUUkVBTSwgYnV0IEnigJlsbCBkZWZlciB0byBvdGhlcnMgd2hldGhlciB0aGUgY29t cGxleGl0eSBpcyB3b3J0aCB0aGUgcG90ZW50aWFsIHNhdmluZ3MuDQoNCkZyb206IEx1YmFzaGV2 LCBJZ29yIFttYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFy Y2ggOCwgMjAxNyA5OjE5IEFNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5j b20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBNYXJ0aW4gVGhvbXNvbiA8bWFy dGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBt aWNyb3NvZnQuY29tPjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IERJU0lOVEVSRVNUIGZy YW1lDQoNClAuUy4NCiAgVGhlIHBhcmFncmFwaCBhYm92ZSBzdGF0ZXM6DQoNCg0KICAqICAgW1NU UkVBTSBmcmFtZXMgcmVjZWl2ZWQgYWZ0ZXIgc2VuZGluZyBESVNJTlRFUkVTVF0gd2lsbCBiZSBk aXNjYXJkZWQNCg0KU28gSSByZWFkIGl0IHRoYXQgdGhlIHBlZXIgd2hvIHNlbmQgRElTSU5URVJF U1Qgd2lsbCBub3QgYmUgd2FpdGluZyBmb3IgdGhhdCBkYXRhLiAgVGhhdCBwZWVyIGRvZXMgbm90 IG5lZWQgYW55IGFjY291bnRpbmcgZm9yIGZsb3cgY29udHJvbCBlaXRoZXIsIHNpbmNlIGhlIGhh cyBhbHJlYWR5IHJlY2VpdmVkIHRoZSBGSU4gKHdpdGggdGhlIGJ5dGUgb2Zmc2V0KSBhbmQgaXMg YWxyZWFkeSBpbiDigJxoYWxmLWNsb3NlZCAocmVtb3RlKeKAnSBvciDigJxjbG9zZWTigJ0gc3Rh dGUuDQoNCg0KRnJvbTogTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwOCwgMjAxNyAxMjoxMCBQTQ0KVG86IElhbiBTd2V0 dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+Pg0KQ2M6IE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGll dGYub3JnPg0KU3ViamVjdDogUkU6IERJU0lOVEVSRVNUIGZyYW1lDQoNCg0KICAqICAgeW91IGRl ZmluaXRlbHkgbmVlZCAiUlNUX1NUUkVBTSBpcyBzZW50IHVubGVzcyBhbGwgb3V0c3RhbmRpbmcg ZGF0YSBoYXMgYmVlbiBzZW50IEFORCBhY2tub3dsZWRnZWQuIiwgb3RoZXJ3aXNlIHRoZSBwZWVy IHdhaXRzIGZvcmV2ZXIgZm9yIGRhdGEgdGhhdCB3b24ndCBhcnJpdmUuDQoNCg0KSSBndWVzcyB0 aGlzIGlzIHRoZSBjb3JlIG9mIHRoZSBxdWVzdGlvbiwgd2hpY2ggZ29lcyBiZXlvbmQgdGhlIGNo b2ljZSBmb3IgdGhpcyByYXJlIGNvbmRpdGlvbi4g4oCcSXQgaXMgcmVhc29uYWJsZSB0byB0aGlu ayB0aGF0IHRoZSBwZWVyIHdobyBzZW50IERJU0lOVEVSRVNUIGlzIHN0aWxsIHdhaXRpbmcgZm9y IGFueSBkYXRhP+KAnSAgVGhlIHdob2xlIHBvaW50IG9mIERJU0lOVEVSRVNUIGlzIHRvIGluZGlj YXRlIHRoYXQg4oCcSSBhbSBub3Qgd2FpdGluZyBmb3IgYW55IG1vcmUgZGF0YeKAnS4NCg0KDQpG cm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDogV2VkbmVz ZGF5LCBNYXJjaCAwOCwgMjAxNyA5OjUxIEFNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4NCkNjOiBM dWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFp LmNvbT4+OyBNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hv cEBtaWNyb3NvZnQuY29tPjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBESVNJTlRFUkVTVCBmcmFtZQ0KDQpNYXJ0aW4ncyByaWdodCwgeW91IGRlZmlu aXRlbHkgbmVlZCAiUlNUX1NUUkVBTSBpcyBzZW50IHVubGVzcyBhbGwgb3V0c3RhbmRpbmcgZGF0 YSBoYXMgYmVlbiBzZW50IEFORCBhY2tub3dsZWRnZWQuIiwgb3RoZXJ3aXNlIHRoZSBwZWVyIHdh aXRzIGZvcmV2ZXIgZm9yIGRhdGEgdGhhdCB3b24ndCBhcnJpdmUuDQoNClF1ZXN0aW9uOiBXaHkg Y2FsbCBpdCBESVNJTlRFUkVTVCwgaW5zdGVhZCBvZiBSRVFVRVNUX1JTVD8gIEl0IHdhc24ndCBv YnZpb3VzIHRvIG1lIHdoYXQgRElTSU5URVJFU1Qgd2FzIHVudGlsIEkgcmVhZCBmdXJ0aGVyLCB3 aGVyZWFzIFJFUVVFU1RfUlNUIGlzIHByZXR0eSBvYnZpb3VzLCBhc3N1bWluZyB5b3Uga25vdyBh Ym91dCBSU1RfU1RSRUFNLg0KDQpPbiBUdWUsIE1hciA3LCAyMDE3IGF0IDExOjQxIFBNLCBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDggTWFyY2ggMjAxNyBhdCAxNTozNSwgTHViYXNoZXYs IElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3 cm90ZToNCj4gV2UgYXJlIHRha2luZyBhYm91dCBhIGNhc2Ugd2hlbiB0aGUgc2VuZGVyIG9mIHRo ZSBzdHJlYW0gaXMgYWxyZWFkeSBpbg0KPiAiaGFsZi1jbG9zZWQgKGxvY2FsKSIgKG9yICJjbG9z ZWQiKSBhbmQgdGhlIHJlY2VpdmVyIGlzIGFscmVhZHkgaW4NCj4gImhhbGYtY2xvc2VkIChyZW1v dGUpIiAob3IgImNsb3NlZCIpLiBUaGlzIFJTVF9TVFJFQU0gd2lsbCBub3QgYWZmZWN0IHRoZQ0K PiBzdGF0ZSBvZiB0aGUgc3RyZWFtIGZvciBhbnkgcGVlci4gVGhlIG9ubHkgaW5mb3JtYXRpb24g UlNUX1NUUkVBTSBjb250YWlucw0KPiBub3cgaXMgIkkgd2lsbCBub3QgdHJhbnNtaXQiLiBCdXQg dGhlIHBlZXIgYWxyZWFkeSBzZW50IERJU0lOVEVSRVNURUQgdG8NCj4gaW5kaWNhdGUgaXQgZG9l cyBub3QgY2FyZSBhYm91dCByZXRyYW5zbWlzc2lvbnMuDQoNCkV2ZW4gYWZ0ZXIgY2xvc2luZyBh IHN0cmVhbSwgYW4gZW5kcG9pbnQgbmVlZHMgdG8gcmV0cmFuc21pdCBkYXRhLiAgSXQNCmNsb3Nl cyB3aGVuIGl0IGZpcnN0IHNlbmRzIHRoZSBGSU4uDQoNCg== --_000_BN6PR03MB2708B9AA3E888186562D806D872E0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjkzMDcwMDA3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NjYwMjExODEyIDE3MTY3OTUyMzQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTE0NjM4 Njk2ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1 ODE1ODYyNjggLTE1OTAxMzg0NDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Zb3XigJlyZSBjb3JyZWN0IHRoYXQgdGhlIHNlbmRlciBvZiBESVNJTlRFUkVTVCBubyBs b25nZXIgY2FyZXMgYWJvdXQgdGhlIGRhdGEsIG90aGVyIHRoYW4gZm9yIGZsb3cgY29udHJvbCBh bmQgc3RhdGUgY29uc2lzdGVuY3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGFkIGJlZW4gdHJ5aW5nIHRv IGFwcHJvYWNoIGl0IGZyb20gYSBwcmluY2lwbGUgdGhhdCBvbmx5IHRoZSBzZW5kZXIgY2FuIGFm ZmVjdCB0aGUgc3RyZWFtIHN0YXRlIGluIHRoZWlyIGRpcmVjdGlvbiDigJMgdGhlIHJlY2VpdmVy IGNhbiBvbmx5IHJlcXVlc3QgY2hhbmdlcy4mbmJzcDsgQXMgdGhlIGRyYWZ0DQogY3VycmVudGx5 IHJlYWRzLCB0aGUgcmVjZWl2ZXIgY291bnRzIGZsb3cgY29udHJvbCBhcyBTVFJFQU0gZnJhbWVz IGFyZSByZWNlaXZlZCwgYW5kIHVwb24gcmVjZWlwdCBvZiBhIFJTVF9TVFJFQU0uJm5ic3A7IElm IGEgU1RSRUFNIGZyYW1lIGlzIGRlbGF5ZWQsIGl0IGRvZXNu4oCZdCAoeWV0KSBjb3VudCBhZ2Fp bnN0IHRoZSByZWNlaXZlcuKAmXMgZmxvdyBjb250cm9sIHdpbmRvdywgZXZlbiBpZiBpdCBjYW4g aW5mZXIgdGhhdCB0aGUgZGF0YSBoYXMgYmVlbg0KIHNlbnQgKGJ5IHZpcnR1ZSBvZiByZWNlaXZp bmcgYSBsYXRlciBvZmZzZXQpLiZuYnNwOyBPbmx5IHVwb24gcmVjZWlwdCBvZiBhIFJTVF9TVFJF QU0gZG8geW91IGFjY291bnQgYWxsIG91dHN0YW5kaW5nIGRhdGEgYWdhaW5zdCB0aGUgZmxvdyBj b250cm9sIHdpbmRvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hhbmdpbmcgaXQgc28gdGhhdCBhbGwgZGF0 YSB1cCB0byB0aGUgZnVydGhlc3Qgb2Zmc2V0IHJlY2VpdmVkIG9uIGEgc3RyZWFtIGNvdW50cyBp cyBjZXJ0YWlubHkgcG9zc2libGUsIGJ1dCBmZWVscyBsaWtlIGFuIG9ydGhvZ29uYWwgY2hhbmdl IHRvIHRoaXMgUFIuJm5ic3A7IEnigJl2ZSBvcGVuZWQgaXNzdWUNCiAjMzcwIGZvciB0aGF0LiZu YnNwOyBJbiB0aGF0IHdvcmxkLCB0aGUgcmVxdWlyZW1lbnQgd291bGQgYmUgdG8gcmVsaWFibHkg ZGVsaXZlciA8aT5laXRoZXI8L2k+IGEgUlNUX1NUUkVBTQ0KPGk+b3I8L2k+IGEgU1RSRUFNIGZy YW1lIHdpdGggdGhlIEZJTiBiaXQgc2V0IChiYXNpY2FsbHksIHlvdSBNVVNUIGNvbW11bmljYXRl IHlvdXIgZmluYWwgb2Zmc2V0KS4mbmJzcDsgU28gbG9uZyBhcyBvbmUgb2YgdGhvc2UgZ2V0cyB0 aHJvdWdoLCBESVNJTlRFUkVTVCBieSBpdHNlbGYgY291bGQgc3RvcCByZXRyYW5zbWlzc2lvbnMu Jm5ic3A7IFRoYXQgZmVlbHMgbWFyZ2luYWxseSBtb3JlIGNvbXBsaWNhdGVkLCBzaW5jZSBpdCBh ZGRzIGFuIGFkZGl0aW9uYWwNCiBwYXRoIHRvIHN0b3AgcmV0cmFuc21pc3Npb24gb24gYSBzdHJl YW0gYW5kIG1ha2VzIHRoZSBhY2NvdW50aW5nIGxvZ2ljIG9uIHJlY2VpcHQgb2YgYSBTVFJFQU0g ZnJhbWUgbW9yZSBjb21wbGljYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgaW5jbGluYXRpb24gaXMg dG8gbGVhdmUgcmV0cmFuc21pc3Npb25zIHRpZWQgdG8gaGF2aW5nIHNlbnQgUlNUX1NUUkVBTSwg YnV0IEnigJlsbCBkZWZlciB0byBvdGhlcnMgd2hldGhlciB0aGUgY29tcGxleGl0eSBpcyB3b3J0 aCB0aGUgcG90ZW50aWFsIHNhdmluZ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTHVi YXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgTWFyY2ggOCwgMjAxNyA5OjE5IEFNPGJyPg0KPGI+VG86PC9iPiBMdWJh c2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFu c3dldHRAZ29vZ2xlLmNvbSZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IERJU0lOVEVSRVNUIGZyYW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QLlMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgVGhlIHBhcmFncmFw aCBhYm92ZSBzdGF0ZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5bU1RSRUFNIGZyYW1lcyByZWNlaXZlZCBhZnRlciBzZW5kaW5nIERJU0lO VEVSRVNUXSB3aWxsIGJlIGRpc2NhcmRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyBJIHJlYWQg aXQgdGhhdCB0aGUgcGVlciB3aG8gc2VuZCBESVNJTlRFUkVTVCB3aWxsDQo8aT5ub3Q8L2k+IGJl IHdhaXRpbmcgZm9yIHRoYXQgZGF0YS4mbmJzcDsgVGhhdCBwZWVyIGRvZXMgbm90IG5lZWQgYW55 IGFjY291bnRpbmcgZm9yIGZsb3cgY29udHJvbCBlaXRoZXIsIHNpbmNlIGhlIGhhcyBhbHJlYWR5 IHJlY2VpdmVkIHRoZSBGSU4gKHdpdGggdGhlIGJ5dGUgb2Zmc2V0KSBhbmQgaXMgYWxyZWFkeSBp biDigJxoYWxmLWNsb3NlZCAocmVtb3RlKeKAnSBvciDigJxjbG9zZWTigJ0gc3RhdGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMdWJhc2hldiwgSWdvciBbPGEgaHJl Zj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPm1haWx0bzppbHViYXNoZUBha2FtYWkuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA4LCAyMDE3IDEyOjEw IFBNPGJyPg0KPGI+VG86PC9iPiBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0 dEBnb29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7IE1hcnRpbiBUaG9tc29u ICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOk1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBESVNJTlRFUkVTVCBmcmFtZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwx IGxldmVsMSBsZm80Ij55b3UgZGVmaW5pdGVseSBuZWVkICZxdW90O1JTVF9TVFJFQU0gaXMgc2Vu dCB1bmxlc3MgYWxsIG91dHN0YW5kaW5nIGRhdGEgaGFzIGJlZW4gc2VudCBBTkQgYWNrbm93bGVk Z2VkLiZxdW90Oywgb3RoZXJ3aXNlIHRoZSBwZWVyIHdhaXRzIGZvcmV2ZXIgZm9yIGRhdGEgdGhh dCB3b24ndCBhcnJpdmUuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGd1ZXNzIHRoaXMgaXMg dGhlIGNvcmUgb2YgdGhlIHF1ZXN0aW9uLCB3aGljaCBnb2VzIGJleW9uZCB0aGUgY2hvaWNlIGZv ciB0aGlzIHJhcmUgY29uZGl0aW9uLiDigJxJdCBpcyByZWFzb25hYmxlIHRvIHRoaW5rIHRoYXQg dGhlIHBlZXIgd2hvIHNlbnQgRElTSU5URVJFU1QgaXMgc3RpbGwgd2FpdGluZw0KIGZvciBhbnkg ZGF0YT/igJ0mbmJzcDsgVGhlIHdob2xlIHBvaW50IG9mIERJU0lOVEVSRVNUIGlzIHRvIGluZGlj YXRlIHRoYXQg4oCcSSBhbSA8aT5ub3Q8L2k+IHdhaXRpbmcgZm9yIGFueSBtb3JlIGRhdGHigJ0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IElhbiBTd2V0dCBbPGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iPm1h aWx0bzppYW5zd2V0dEBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIE1hcmNoIDA4LCAyMDE3IDk6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29u ICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0 OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29t PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSI+ TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpxdWljQGll dGYub3JnIj4NCnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBESVNJ TlRFUkVTVCBmcmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcnRp bidzIHJpZ2h0LCB5b3UgZGVmaW5pdGVseSBuZWVkICZxdW90O1JTVF9TVFJFQU0gaXMgc2VudCB1 bmxlc3MgYWxsIG91dHN0YW5kaW5nIGRhdGEgaGFzIGJlZW4gc2VudCBBTkQgYWNrbm93bGVkZ2Vk LiZxdW90Oywgb3RoZXJ3aXNlIHRoZSBwZWVyIHdhaXRzIGZvcmV2ZXIgZm9yIGRhdGEgdGhhdCB3 b24ndCBhcnJpdmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5RdWVzdGlvbjogV2h5IGNhbGwgaXQgRElTSU5URVJFU1QsIGluc3RlYWQgb2YgUkVRVUVTVF9S U1Q/Jm5ic3A7IEl0IHdhc24ndCBvYnZpb3VzIHRvIG1lIHdoYXQgRElTSU5URVJFU1Qgd2FzIHVu dGlsIEkgcmVhZCBmdXJ0aGVyLCB3aGVyZWFzIFJFUVVFU1RfUlNUIGlzIHByZXR0eSBvYnZpb3Vz LCBhc3N1bWluZyB5b3Uga25vdyBhYm91dCBSU1RfU1RSRUFNLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA3LCAyMDE3IGF0 IDExOjQxIFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPk9uIDggTWFyY2ggMjAxNyBhdCAxNTozNSwgTHViYXNoZXYsIElnb3Ig Jmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWku Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBXZSBhcmUgdGFraW5nIGFib3V0IGEgY2FzZSB3 aGVuIHRoZSBzZW5kZXIgb2YgdGhlIHN0cmVhbSBpcyBhbHJlYWR5IGluPGJyPg0KJmd0OyAmcXVv dDtoYWxmLWNsb3NlZCAobG9jYWwpJnF1b3Q7IChvciAmcXVvdDtjbG9zZWQmcXVvdDspIGFuZCB0 aGUgcmVjZWl2ZXIgaXMgYWxyZWFkeSBpbjxicj4NCiZndDsgJnF1b3Q7aGFsZi1jbG9zZWQgKHJl bW90ZSkmcXVvdDsgKG9yICZxdW90O2Nsb3NlZCZxdW90OykuIFRoaXMgUlNUX1NUUkVBTSB3aWxs IG5vdCBhZmZlY3QgdGhlPGJyPg0KJmd0OyBzdGF0ZSBvZiB0aGUgc3RyZWFtIGZvciBhbnkgcGVl ci4gVGhlIG9ubHkgaW5mb3JtYXRpb24gUlNUX1NUUkVBTSBjb250YWluczxicj4NCiZndDsgbm93 IGlzICZxdW90O0kgd2lsbCBub3QgdHJhbnNtaXQmcXVvdDsuIEJ1dCB0aGUgcGVlciBhbHJlYWR5 IHNlbnQgRElTSU5URVJFU1RFRCB0bzxicj4NCiZndDsgaW5kaWNhdGUgaXQgZG9lcyBub3QgY2Fy ZSBhYm91dCByZXRyYW5zbWlzc2lvbnMuPGJyPg0KPGJyPg0KRXZlbiBhZnRlciBjbG9zaW5nIGEg c3RyZWFtLCBhbiBlbmRwb2ludCBuZWVkcyB0byByZXRyYW5zbWl0IGRhdGEuJm5ic3A7IEl0PGJy Pg0KY2xvc2VzIHdoZW4gaXQgZmlyc3Qgc2VuZHMgdGhlIEZJTi48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708B9AA3E888186562D806D872E0BN6PR03MB2708namp_-- From nobody Wed Mar 8 13:07:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2356127A91 for ; Wed, 8 Mar 2017 13:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajjIGiYnSKZ3 for ; Wed, 8 Mar 2017 13:07:50 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 98CEF129495 for ; Wed, 8 Mar 2017 13:07:50 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 1so87500921qkl.3 for ; Wed, 08 Mar 2017 13:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SqIZ7ECRmE7CmCplQ6Xsk4LHv3rterHOG4PVoOgSbjQ=; b=ldxYvoVS2DvXiiGtc7hyslvMD4EudKx3/pfqVAH+Z21lWfBk1T/u3kc2WrMH1Yjtpl kEQS4kkXcczDH+gODYQlhVqtXRpetV8KFmWh0fvy2yIyZNUw4exjUymK0FpdL7JPsavV sdq1fG53AZKMpl3vPPs8xcuusJWxDx6OIL1aog1PNqmNtS9vnmzLYDM8fIQws6mbJRH5 /DVNS+UbzPR2VaEH15OlRRyc1ZBKrKpnmLbNxzPdROYkBNsPxZFSSc+FM+VEzYvvMlJY 5CVguXhThpABuB+SjDbBrap7XKJrxONse02X575OlxZnn/bTLywPqvr5e0TrYfd2DUEo VZcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SqIZ7ECRmE7CmCplQ6Xsk4LHv3rterHOG4PVoOgSbjQ=; b=h1doqXV7PljwYJ6/EPOVlsRsNYNxB8M+d/d7f70kFnjxTREMmB/p/OTA3y8qFlSerE Ka/X/VGQ4dbFZN1bopNXAvb7LLP+uD+4tuKKi0499lr1Ap1J702zASw5QW6szAu+PVSe zsZPKgRzT1VtllKHxmak8dttP8tNeKOwDW/tH24FWuS0cFXPDTCJRgoCiBOHiVpCYw2V 6gdvjzKyPT/eyJosEBd5oLG1kT4sdNSX8VqCyHYRbLB4eBnV9xPvg+E/GAXmgz6qMG8x +N/4keHxx0pPJBrb2s2i0kbl952dcE2OFoTzQ3RCO6olxNAMBuC+wpcG1r7yByWMMlWO CEaA== X-Gm-Message-State: AMke39m34bdRoRTcgpYDhLdYoOvHhrWTGBbA85qQ136gX/NaawYw7yrEORjr+PlyrnmsgL3XDP/TeAYJ4A4iYQ== X-Received: by 10.55.185.131 with SMTP id j125mr9748453qkf.115.1489007269582; Wed, 08 Mar 2017 13:07:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Mar 2017 13:07:49 -0800 (PST) In-Reply-To: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 9 Mar 2017 08:07:49 +1100 Message-ID: Subject: Re: DISINTEREST frame To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ian Swett , "Lubashev, Igor" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:07:52 -0000 On 9 March 2017 at 03:07, Mike Bishop wrote: > I think Martin has some ultimate goal of moving away from the baggage tha= t > comes with the terms RST and FIN from TCP. If so, he can expound when it= =E2=80=99s > convenient for him. At some point I plan to propose new names for these control related mechanisms. FIN, RST, and SYN have proven to carry some baggage. From nobody Wed Mar 8 13:39:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7112957F for ; Wed, 8 Mar 2017 13:39:41 -0800 (PST) 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 vM1zMEevOhi7 for ; Wed, 8 Mar 2017 13:39:40 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 1A91A1295DA for ; Wed, 8 Mar 2017 13:39:40 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id o24so43978181otb.1 for ; Wed, 08 Mar 2017 13:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=kS7pAx6QBmhtx+GEgkg1s5hhKYXEhsJq07pjnsA3/Z4=; b=i+5hTct5jCnN/YS/CG/LRplzcaUAMcXGIkI/qj3L87jgwXBW2dWNc0Ce6uXjGRNEPU RtztITC2N8kGzOtXDsQ/gvXrKl8LrpcgP86RAJueyTl6TqCgWaWFWYEnI8S57RyKSVgn opKJ264hhLet9wVAMLjRJ9dFZrmu8AYu2UBpSbWSGBrFWxqri7kOOzaF0DuW52n546iN TExx69B5VruMYFibwwBh+EOR7Bw87gHbqYQB+gW9tlzHiTiV7zhZ19dHaDUd+WQinBOA Iw19Exrr/TnqI6fJr5tp+S/3p21sNrTiMw5sgV6+peFpXlBUgwctrc5pe4VedKn9qrWt G8gA== 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=kS7pAx6QBmhtx+GEgkg1s5hhKYXEhsJq07pjnsA3/Z4=; b=eeH5Wk1l29tywCLbR7rbtNXr+/OVh4jzeinraiR+okHUazsEQUpenFzD2txbTpXbd/ YpIZMLofHiowu+gNJ4Hnf3CunzP6KA6Y6BP7+uo2nYLDTsg4R1CXd23OMklqcRr1HlMp Nc6TmhuCr0oMNDPuAYBx/xFSW7C4VVz12C6LDxfLmc1GXtRk1rCzrWpiteCBn318mQcP v1OYSgoKcs5u+LNEIz0NVY+pnS4NIUxGYYP8meKogdUY1Z3paTLIjhCzj7CWivTlrhvs IyJReqIX+uwkDpvdC1+uxCHGgt9Ornkx1eQIEkaU5+IRTE54FfZUMKmajnFZFW83At7P 7aQg== X-Gm-Message-State: AMke39mjuQ55a+22FPQhjSW9yB5HAH2Uk4n9ystVYB0uja5Gpyx3RJP6MnOofeRGirs573qHpeRckDkITXCJkQ== X-Received: by 10.129.92.2 with SMTP id q2mr2057660ywb.87.1489009179228; Wed, 08 Mar 2017 13:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 8 Mar 2017 13:38:58 -0800 (PST) From: Eric Rescorla Date: Wed, 8 Mar 2017 13:38:58 -0800 Message-ID: Subject: Middlebox introspection/self-describing packets To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114d6f1632122f054a3ef7b3 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 21:39:41 -0000 --001a114d6f1632122f054a3ef7b3 Content-Type: text/plain; charset=UTF-8 There's recently been some back and forth on the headers PR about the value of having packets be self-describing so that middleboxes can parse them. To take a concrete example, consider the connection_id. In general, it seems that mostly packets in a given direction either need connection_ids or don't (assuming that the point of connection_id is partly to handle unexpected NAT rebinding.), so this seems like a prime thing to negotiate. Jana argued in the PR that the reason to have a bit is to allow middleboxes to know how to parse the packet. It seems like it would be good to come to agreement about our attitude towards middlebox inspection. I have been generally taking the position that we should conceal as much as possible from middleboxes and only expose what is needed to make the protocol work (i.e., if possible I would encrypt conn_id and packet number). It seems like perhaps not everyone shares that objective, so I thought I would ask what principles other people thought they were adhering to. Jana? MT? Others? -Ekr --001a114d6f1632122f054a3ef7b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's recently been some back and forth on the heade= rs PR about the
value of having packets be self-describing so that midd= leboxes can parse
them.=C2=A0

To take a = concrete example, consider the connection_id. In general, it seems
that mostly packets in a given direction either need connection_ids or do= n't
(assuming that the point of connection_id is partly to ha= ndle unexpected
NAT rebinding.), so this seems like a prime thing= to negotiate. Jana argued
in the PR that the reason to have a bi= t is to allow middleboxes to know how
to parse the packet.
<= div>
It seems like it would be good to come to agreement abou= t our attitude towards
middlebox inspection. I have been generall= y taking the position that we should
conceal as much as possible = from middleboxes and only expose what is needed
to make the proto= col work (i.e., if possible I would encrypt conn_id and packet
nu= mber). It seems like perhaps not everyone shares that objective, so I thoug= ht
I would ask what principles other people thought they were adh= ering to.

Jana? MT? Others?

-Ekr



--001a114d6f1632122f054a3ef7b3-- From nobody Wed Mar 8 14:45:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338231294A9 for ; Wed, 8 Mar 2017 14:45:27 -0800 (PST) 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 bNEsX4vl9IsT for ; Wed, 8 Mar 2017 14:45:25 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C61129519 for ; Wed, 8 Mar 2017 14:45:24 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 693B7340DC0; Wed, 8 Mar 2017 23:45:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.19342); Wed, 8 Mar 2017 23:45:22 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 8 Mar 2017 23:45:22 +0100 (CET) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.4]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10854474; Wed, 08 Mar 2017 23:45:22 +0100 From: Brian Trammell (IETF) Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5B498F5B-EAB9-41AD-8F34-27C46B8E9757"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Middlebox introspection/self-describing packets Date: Wed, 8 Mar 2017 23:45:20 +0100 In-Reply-To: To: Eric Rescorla References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 22:45:27 -0000 --Apple-Mail=_5B498F5B-EAB9-41AD-8F34-27C46B8E9757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi ekr, The point in this space I'd use is =E2=80=9Cexpose nothing without = necessity, or clear benefit with mutual cooperation of the endpoints, = but ensure exposed information is efficiently usable.=E2=80=9D > On 8 Mar 2017, at 22:38, Eric Rescorla wrote: >=20 > There's recently been some back and forth on the headers PR about the > value of having packets be self-describing so that middleboxes can = parse > them. >=20 > To take a concrete example, consider the connection_id. In general, it = seems > that mostly packets in a given direction either need connection_ids or = don't > (assuming that the point of connection_id is partly to handle = unexpected > NAT rebinding.), so this seems like a prime thing to negotiate. Jana = argued > in the PR that the reason to have a bit is to allow middleboxes to = know how > to parse the packet. Taking the case of Connection ID, specifically, it does seem to be a = candidate for moving to negotiation, saving one header bit pretty much = everywhere. Connection ID is designed for load balancers, and one could = define negotiation to be mandatory on the client side: if the server = gives you a connection ID, then the client MUST return it. Otherwise, = any device trying to observe the Connection ID would have to keep the = has-a-Connection-ID state observed during the negotiation, and it = wouldn't have access to that state when the Connection ID is used during = rebinding. In this case, saving the bit costs you the possibility of client-side = choice on whether to not return the Connection ID, which seems to me to = violate the mutual cooperation principle. Cheers, Brian >=20 > It seems like it would be good to come to agreement about our attitude = towards > middlebox inspection. I have been generally taking the position that = we should > conceal as much as possible from middleboxes and only expose what is = needed > to make the protocol work (i.e., if possible I would encrypt conn_id = and packet > number). It seems like perhaps not everyone shares that objective, so = I thought > I would ask what principles other people thought they were adhering = to. >=20 > Jana? MT? Others? >=20 > -Ekr >=20 >=20 >=20 --Apple-Mail=_5B498F5B-EAB9-41AD-8F34-27C46B8E9757 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----- iQIcBAEBCAAGBQJYwImBAAoJEIoSt78L6kajnKoP/Rx9A0sem2td+oP3NU81U5d6 47bRmZD2oc5fD5RtQiUMBSKwiBShydRU5uAPXlLKLfEdOBsNaNz/A1PoOa8GCGdo utOz3F9gmI3pHbE6K5oRICXnMR9HRvF1L274+Dz00/N8k94Xn6+70ttbstV3+NL0 PHRtWanAsGPDU4/42kT+KLAUk6ap4MA/xYs6vTmGccYc3G0KTCjIn6BU/BFX16gj YbhSMCmxlb4yY/xAYtPwXka+M9Wfpmlyc5DMDChVhVPawuIhxTf+8nsfeWKaGr2X 95BZdZfLZR6SkHMSzNgvIMEtLfENj6b3Z7y2G9jd48aX/zkdEKsJ+mDtGawINJG0 W+93Wr04NT5AotbEocN5jlYeGlKJaWrp3K8Ises9VG8e82LBH+LKd6AynNGb3kEF W2coI71k6uS0R1OdRCv5mGzYjaQKVVWpuyrwzXYx/CLvjrq4sgnDDuU+ZYEBx/T8 fRtKwSfaODrbASfcJRgQletzvLIaH6OwoCPj0hM30kOffeZh6YwrA7JLuJhKrEz0 jF3HJ+7pyxxvVYRCHoBM+MK7msjMr12VRTdpa2urN4tn2dymFpHRUBr+EVBQg7aB 0ExuKclWQg9W9vsnrYAgilNm+oGBzb88O/HRwiVGm3s7NbE28cIE8DK2BZXSuFHv KQdt5ZC2eHUyzvLNSj/C =ypcw -----END PGP SIGNATURE----- --Apple-Mail=_5B498F5B-EAB9-41AD-8F34-27C46B8E9757-- From nobody Wed Mar 8 15:43:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B481294B3 for ; Wed, 8 Mar 2017 15:43:44 -0800 (PST) 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 zqYdx2INnczd for ; Wed, 8 Mar 2017 15:43:42 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A804127058 for ; Wed, 8 Mar 2017 15:43:42 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id o24so45801879otb.1 for ; Wed, 08 Mar 2017 15:43:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AeGDfWw1sqo2InJELLNqrBIidsTKcs6KU6cpwN014OY=; b=rBY4UNg1P5JhbHP6FW8mD5IW4LVJNqbN/Ol9l894kHAZAu6IWs1rV6F9VRiFpiZMQ3 PaEvNmz61mtKqwiVB2xay3EbXZBM8MBSoJAJHFG1o1cBfSTJdFQDksx7pWtdeYxlmWcX 3k4c404Pnws7cX0yT4tCROlUYl59xmXm5KL6v20+mK6MiGod+KXSXAqqN+oIEVTpmWVu OqaD0VEvvJkpG+ipxVWSb85GR+8OgeC+AnWpg9sA+14w3lEZolGvbwHyQ0Rf7eKPfzNR YWBeCNOSh6zxQmdFESoszTpJiwl1bQGXkDom69IOyc778uZDTMCqc5dcFz4ZZ2wqnyG1 he9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AeGDfWw1sqo2InJELLNqrBIidsTKcs6KU6cpwN014OY=; b=lCrIJhcSIe92DhJU3Lb+OjSFof14fN+2zOY71xFswMRwPJmcdXDvQHkRWSWqsqBr7y y1/VC2XPr8bzVubPWVgTlACqnyu2tbw+drPlinS1j0hqLj+XQfogFrwF4fJ3cBr7K9jZ L3+WzwkvNda4+80rPhS4Ni5kX5I4sdztbr7Iggv6hZGHG9loQEQGu+G/hmi/mTP4RLnb DXwR1Fw4Y6qSUPPTrPH2GJ3aaAYCgOo6XuHR798NkkzA3KoDdPa0f+rEO2VUHETYPns9 fxBvBLFzDsqhbdqknoNPHJGHtGYJ7VLEKq2T17Y6AiREsXqIvBayqUDjO7XLNztAER6U b1zg== X-Gm-Message-State: AFeK/H1hnXi3R3a+b2EIIjBo997X3FDtYGfj2foRh2QZ03WkccRyt4AJzBYxWyFc3hgWtz9q2rR80zvyuAHkbg== X-Received: by 10.157.8.212 with SMTP id 78mr6229364otf.83.1489016621954; Wed, 08 Mar 2017 15:43:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Wed, 8 Mar 2017 15:43:41 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 8 Mar 2017 15:43:41 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11c15a08d100ae054a40b27d Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 23:43:45 -0000 --001a11c15a08d100ae054a40b27d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have a substantially different position on middlebox inspection. First is the load balancing point, which many people have already made. Second, service providers have an interest in (1) measuring the quality of service they provide to customers, (2) enforcing bandwidth limitations, etc. on users, and (3) identifying application types to provide QoS where it matters. I think (1) and (2) can be done without a meaningful loss of privacy, although (3) is highly problematic. To that end, there are a number of open issues looking to expose some transport state to middleboxes= : - Packet number echo to allow RTT measurements (#269) - ECN to allow a non-loss rate-limiting signal (replacing TCP zero-window) (#68) - Public flag bits to indicate flow-control and loss-detection causes of throttling, to aid in troubleshooting (#279) - I believe it was someone from Orange in Tokyo who asked "how am I going to troubleshoot this?" - Replacing CONNECTION_CLOSE to an authenticated Public Reset to clear connection state on middleboxes. (#353) No one has yet demonstrated that any of these are meaningful losses of privacy. They also require no modifications to the packet itself. For all the above reasons I am somewhat concerned about all of the surreptitious connection-ID changes, but I think all of these features are valuable regardless of how those discussions turn out. On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell wrote: > hi ekr, > > The point in this space I'd use is =E2=80=9Cexpose nothing without necess= ity, or > clear benefit with mutual cooperation of the endpoints, but ensure expose= d > information is efficiently usable.=E2=80=9D > > > On 8 Mar 2017, at 22:38, Eric Rescorla wrote: > > > > There's recently been some back and forth on the headers PR about the > > value of having packets be self-describing so that middleboxes can pars= e > > them. > > > > To take a concrete example, consider the connection_id. In general, it > seems > > that mostly packets in a given direction either need connection_ids or > don't > > (assuming that the point of connection_id is partly to handle unexpecte= d > > NAT rebinding.), so this seems like a prime thing to negotiate. Jana > argued > > in the PR that the reason to have a bit is to allow middleboxes to know > how > > to parse the packet. > > Taking the case of Connection ID, specifically, it does seem to be a > candidate for moving to negotiation, saving one header bit pretty much > everywhere. Connection ID is designed for load balancers, and one could > define negotiation to be mandatory on the client side: if the server give= s > you a connection ID, then the client MUST return it. Otherwise, any devic= e > trying to observe the Connection ID would have to keep the > has-a-Connection-ID state observed during the negotiation, and it wouldn'= t > have access to that state when the Connection ID is used during rebinding= . > > In this case, saving the bit costs you the possibility of client-side > choice on whether to not return the Connection ID, which seems to me to > violate the mutual cooperation principle. > > Cheers, > > Brian > > > > > > It seems like it would be good to come to agreement about our attitude > towards > > middlebox inspection. I have been generally taking the position that we > should > > conceal as much as possible from middleboxes and only expose what is > needed > > to make the protocol work (i.e., if possible I would encrypt conn_id an= d > packet > > number). It seems like perhaps not everyone shares that objective, so I > thought > > I would ask what principles other people thought they were adhering to. > > > > Jana? MT? Others? > > > > -Ekr > > > > > > > > --001a11c15a08d100ae054a40b27d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a substantially different position on middlebox ins= pection. First is the load balancing point, which many people have already = made.

Second, service providers have an interest in (1) = measuring the quality of service they provide to customers, (2) enforcing b= andwidth limitations, etc. on users, and (3) identifying application types = to provide QoS where it matters. I think (1) and (2) can be done without a = meaningful loss of privacy, although (3) is highly problematic. To that end= , there are a number of open issues looking to expose some transport state = to middleboxes:
- Packet number echo to allow RTT measurements (#= 269)
- ECN to allow a non-loss rate-limiting signal (replacing TC= P zero-window) (#68)=C2=A0
- Public flag bits to indicate flow-co= ntrol and loss-detection causes of throttling, to aid in troubleshooting (#= 279) - I believe it was someone from Orange in Tokyo who asked "how am= I going to troubleshoot this?"
- Replacing CONNECTION_CLOSE= to an authenticated Public Reset to clear connection state on middleboxes.= (#353)=C2=A0

No one has yet demonstrated that any= of these are meaningful losses of privacy. They also require no modificati= ons to the packet itself.

For all the above reason= s I am somewhat concerned about all of the surreptitious connection-ID chan= ges, but I think all of these features are valuable regardless of how those= discussions turn out.

On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell <ietf@tra= mmell.ch> wrote:
hi ekr,<= br>
The point in this space I'd use is =E2=80=9Cexpose nothing without nece= ssity, or clear benefit with mutual cooperation of the endpoints, but ensur= e exposed information is efficiently usable.=E2=80=9D

> On 8 Mar 2017, at 22:38, Eric Rescorla <ekr@rtfm.com> wrote:
>
> There's recently been some back and forth on the headers PR about = the
> value of having packets be self-describing so that middleboxes can par= se
> them.
>
> To take a concrete example, consider the connection_id. In general, it= seems
> that mostly packets in a given direction either need connection_ids or= don't
> (assuming that the point of connection_id is partly to handle unexpect= ed
> NAT rebinding.), so this seems like a prime thing to negotiate. Jana a= rgued
> in the PR that the reason to have a bit is to allow middleboxes to kno= w how
> to parse the packet.

Taking the case of Connection ID, specifically, it does seem to be a= candidate for moving to negotiation, saving one header bit pretty much eve= rywhere. Connection ID is designed for load balancers, and one could define= negotiation to be mandatory on the client side: if the server gives you a = connection ID, then the client MUST return it. Otherwise, any device trying= to observe the Connection ID would have to keep the has-a-Connection-ID st= ate observed during the negotiation, and it wouldn't have access to tha= t state when the Connection ID is used during rebinding.

In this case, saving the bit costs you the possibility of client-side choic= e on whether to not return the Connection ID, which seems to me to violate = the mutual cooperation principle.

Cheers,

Brian


>
> It seems like it would be good to come to agreement about our attitude= towards
> middlebox inspection. I have been generally taking the position that w= e should
> conceal as much as possible from middleboxes and only expose what is n= eeded
> to make the protocol work (i.e., if possible I would encrypt conn_id a= nd packet
> number). It seems like perhaps not everyone shares that objective, so = I thought
> I would ask what principles other people thought they were adhering to= .
>
> Jana? MT? Others?
>
> -Ekr
>
>
>


--001a11c15a08d100ae054a40b27d-- From nobody Wed Mar 8 16:03:21 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A71294C3 for ; Wed, 8 Mar 2017 16:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6YJACTmw6Ml for ; Wed, 8 Mar 2017 16:03:18 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4339B129473 for ; Wed, 8 Mar 2017 16:03:18 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id v125so93568588qkh.2 for ; Wed, 08 Mar 2017 16:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JSeCZSrRxsBkcJGPTIJcksWwqBQ6c+17S9Nx6Cogtio=; b=LX6GBTDEtOmYpiqjtabrWdGOiZ8KQT8NStKNwCSKV53rOS/2ITeZGdo7pBOB7UwofC ndTuVq3WXcJEVDdj0IkADVbSIqGfqT1ShaTn/WSSKnZ4YA/dqHf1jDQLnqUeRmoydsAT mo6um+SEcsgMpkM62gPEosqUw8u69fLonhmlNvzSUW2wCqSV6Ih4Fk7uaxUjUccp5o8D tmkilFZ8EHHA1LXE93WIaBRjX6C15HDQuCg5c+80SgdWWdMw3MOQZO7U3oFmWhi64nYS baA1xC/rsHdoQzQYcJESOjCMOrQqjVtiRi4eCHD6q78lllPpZInTET1G7CZr68h+lxIi Ijcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JSeCZSrRxsBkcJGPTIJcksWwqBQ6c+17S9Nx6Cogtio=; b=keQiT+5xgb3AtLxD3ZDIZ1wkuuZ5IIFFrkRN97xaW/ti44CDzf5TvfWlLCq36FDQQR DXKEYPMXFMcjM1X3RfZPen1Fn9/+qFPPqPjqb+69z1hR7DlMycCHKTan8f0clPY0kcQ8 XxlktolCvAD5Q6/fSMBy2EUrdRjaHav6HWn8Q+kJJNJRFKy4t/yQG5VGuJEpKwJqOMWs gfIh7bHW3AuCWEo0qhBONTz2zX6FsKhKPSIGPskUyK84/uoJLHSMOin+8bIjksiMhOBv 7DI4AMocEdOlYNeTjHWMhY6ERywhYUjKRKMbiYnJgwOQz8wIp0sQhxGtp1CghVCWKvIX rEsA== X-Gm-Message-State: AMke39kQn5mMsUE5QsYxNlU7q3Ezbhk8Za1o8lBxUzcZUBjgnSfB8yS+TtICeTHvEyciH3CG554xPGxVxOhqEQ== X-Received: by 10.200.46.91 with SMTP id s27mr11674552qta.278.1489017797297; Wed, 08 Mar 2017 16:03:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Mar 2017 16:03:16 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Mar 2017 11:03:16 +1100 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:03:19 -0000 On 9 March 2017 at 10:43, Martin Duke wrote: > - Public flag bits to indicate flow-control and loss-detection causes of > throttling, to aid in troubleshooting (#279) - [...] > No one has yet demonstrated that any of these are meaningful losses of > privacy. Let's try the above as an example. We know very well that flow control can be used to observe the size of encrypted data. Flow control in QUIC ignores any padding, so being able to observe flow control in action defeats a traffic analysis technique. (I apologize, but I can't find the paper on attack specifics right now. I remember seeing a paper copy on mnot's desk when I was there last, and it had a twee name and everything.) From nobody Wed Mar 8 16:09:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A01294E1 for ; Wed, 8 Mar 2017 16:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXhH-T9W4_oV for ; Wed, 8 Mar 2017 16:09:52 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597A81294C3 for ; Wed, 8 Mar 2017 16:09:52 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id 2so28658255oif.0 for ; Wed, 08 Mar 2017 16:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=InQcTGRprroBa1YZxueLCuNNSND1V8UFjkM6cWbTSb4=; b=IHQ0M6Le+8Wc4K7SciidFAQQB1vfnBKB+53rp25og1jlWOdA4hr8HlnBfejkoo1pnN EgaCSPmKZQHtA16CZyR6Z1/e+DATFvtutkIqMIiroZWT4ibl2YO8hEYGJuznT1BGQqPI UBbS6Vqs34apkl8zKvsmmw7OFMirF8GYMogQVdDLyqyGK3eFFas91eTe1Z1Igjwa1bOc OyrLgYd/vxWKjHfDXTfFXwCG/dqsEoGh41UGT/2MGYKCDAuwt2UinHEZuiWwYGJj0rKC xDYF7YF48qajZ5CwkrHz6tVoBESBYwil5E8MHr3eM1ZMpMasErDISryXIckEFj0RnjwU Xfng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=InQcTGRprroBa1YZxueLCuNNSND1V8UFjkM6cWbTSb4=; b=Jwxf8NH1xv3InwFIYZQR5CJ3epyq+/7Ydy0P3rr7kpwULMqpzQ8CpjE33N8p8U1Otr WzfnHU6PN+T8fsKwkPFEQ+a50cqSWSukftbSGbWGNcCJmE9uJLud612Nj+Avd+/3+mbu qumfEoOmTyhqpHdvL5qskjTm26Id9wRBTXessvrUsSee3yyWHasSruQsMNwSyGkR1o+O /J3jfIMQfY+N1xewF7LqVo3ND7+CtLTfPuoMG1QMBzY3bO2fHuFLIS2lGSscNts6cHKf VmvqvLDIxPNMVUJaB+it7UsZwCpYTXZoih6zxUjq7yhe1HoGLB7SeluU3SSpRssM2rkP LSoQ== X-Gm-Message-State: AMke39nLL/q5wQBpKQtFD3P896H4BouY9NdcC3gkbfPaDlYfeF4zJzKv5/jy6O8uo+RMBiqGPI3EuQLPbSqYZQ== X-Received: by 10.202.216.139 with SMTP id p133mr5406598oig.109.1489018191762; Wed, 08 Mar 2017 16:09:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Wed, 8 Mar 2017 16:09:51 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 8 Mar 2017 16:09:51 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113d59ae625cae054a41102b Archived-At: Cc: Brian Trammell , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:09:54 -0000 --001a113d59ae625cae054a41102b Content-Type: text/plain; charset=UTF-8 The proposal in #279 is nothing like fully-baked, but it's a bit indicating that the receiver is advertising zero-window, not indicating how big the window ever was. It might even be ambiguous about stream vs. connection flow control. I can't remember if we're sending an initial window in the clear or not, and this is worth thinking about, but it's not clear to me that's an issue. On Wed, Mar 8, 2017 at 4:03 PM, Martin Thomson wrote: > On 9 March 2017 at 10:43, Martin Duke wrote: > > - Public flag bits to indicate flow-control and loss-detection causes of > > throttling, to aid in troubleshooting (#279) - > > [...] > > > No one has yet demonstrated that any of these are meaningful losses of > > privacy. > > Let's try the above as an example. We know very well that flow > control can be used to observe the size of encrypted data. Flow > control in QUIC ignores any padding, so being able to observe flow > control in action defeats a traffic analysis technique. > > (I apologize, but I can't find the paper on attack specifics right > now. I remember seeing a paper copy on mnot's desk when I was there > last, and it had a twee name and everything.) > --001a113d59ae625cae054a41102b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The proposal in #279 is nothing like fully-baked, but it&#= 39;s a bit indicating that the receiver is advertising zero-window, not ind= icating how big the window ever was. It might even be ambiguous about strea= m vs. connection flow control.

I can't remember if w= e're sending an initial window in the clear or not, and this is worth t= hinking about, but it's not clear to me that's an issue.

On Wed, Mar 8, 2= 017 at 4:03 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 9 March 2= 017 at 10:43, Martin Duke <ma= rtin.h.duke@gmail.com> wrote:
> - Public flag bits to indicate flow-control and loss-detection causes = of
> throttling, to aid in troubleshooting (#279) -

[...]

> No one has yet demonstrated that any of these are meaningful losses of=
> privacy.

Let's try the above as an example.=C2=A0 We know very well that = flow
control can be used to observe the size of encrypted data.=C2=A0 Flow
control in QUIC ignores any padding, so being able to observe flow
control in action defeats a traffic analysis technique.

(I apologize, but I can't find the paper on attack specifics right
now.=C2=A0 I remember seeing a paper copy on mnot's desk when I was the= re
last, and it had a twee name and everything.)

--001a113d59ae625cae054a41102b-- From nobody Wed Mar 8 16:13:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDCB1294F3 for ; Wed, 8 Mar 2017 16:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOprevxHOSgi for ; Wed, 8 Mar 2017 16:13:08 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F031294DF for ; Wed, 8 Mar 2017 16:13:07 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id 1so95188352qkl.3 for ; Wed, 08 Mar 2017 16:13:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YJEFfUNooVYPiMDTffiurJOL+g9EmgefYUUUwLJmESo=; b=UI0BZI0lzV/l/eKMgbHH/PS9OP41pHZBrVL94zxTOOkMeOSacuKYMdDZMJjxXl/j/d FdnxJloI/SMTRVo7PAD8WSQNfwVKTAkt8eXDLiDUHvIHMHvw+AAaSm/VTA+dolvGFkd2 YwmI2cXG78szhEZjAmBco1x9C6i9ba4XrnbUsXFFseND5hhHLP0kLARJzLYZy79pOOh9 CkYiAuOM2TrQtoYZQTvVKJlCMtU235DetXjpEyp9CDSUq5UXzd/HLQxpEAZHLb1UpvgQ kzmX2UJXIA1iSN9Sz3iNB26kFPO+Gs1NuaaDwhjR+tTiJTmSr8Lm8V4X+h4DTjYBZMZ8 UJYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YJEFfUNooVYPiMDTffiurJOL+g9EmgefYUUUwLJmESo=; b=LB86JlL9QtoeRk/8qoaZPfkTS9GbXDyEVqmdLDpEv5mN3nwD8EDUefrZKBZO2t9Bs0 uC3ft28rUMx0TAj9rjcHp9xmJBUXJUwIApQJF3lVTBU4SViFpYqUgV1u24VRNAfUf8hN 5pkW7BI9EkEzVSzrpnP6x0tKIkgDzVAS2fGb2dEOLQ56WSc1D7E79B33B2N+uEyYt6Rs HTpkY0dptKquOujH4bju3FDqPIh0Gj7vkizaQPp28+4j1GZk6P+T5q0jR5Fy7UI+hJWp KkvYcBLbIeiZVILh1XCsa9L+UxZLOz2xFkwt8iWTnrgB2yeYcekbsyBxbKLtPI1Cx9+V uVCQ== X-Gm-Message-State: AMke39kv+vPXb43g2UN4NvoSRsKuYu1eRinLPZzPv0tPX15MPs4FKdJFYoIQHer4xxuQRjWgwJ6XrZwxf8TS3A== X-Received: by 10.233.237.20 with SMTP id c20mr11171528qkg.144.1489018387085; Wed, 08 Mar 2017 16:13:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Mar 2017 16:13:06 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Mar 2017 11:13:06 +1100 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:13:09 -0000 On 9 March 2017 at 11:09, Martin Duke wrote: > The proposal in #279 is nothing like fully-baked, but it's a bit indicating > that the receiver is advertising zero-window, not indicating how big the > window ever was. It might even be ambiguous about stream vs. connection flow > control. > > I can't remember if we're sending an initial window in the clear or not, and > this is worth thinking about, but it's not clear to me that's an issue. It's very definitely an issue. Being able to observe when the flow control window hits zero was used in the attack (the one I can't find). From nobody Wed Mar 8 16:23:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048C71294C3 for ; Wed, 8 Mar 2017 16:23:43 -0800 (PST) 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, 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 Mfsk7N1fFOE6 for ; Wed, 8 Mar 2017 16:23:41 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD241127601 for ; Wed, 8 Mar 2017 16:23:41 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id y76so96045831qkb.0 for ; Wed, 08 Mar 2017 16:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pz8JuCq6YUnW+8x68p8vAEiB/tqrsUC2viLEnk3KWDQ=; b=djg6SGZpiNbHAH9DsrZtoVPo6OHIdaRt1G53PcP94VKHgO9poT2ApyznPZ2FCnqu2i q6/NSEcXEmVKutPfIBYfF9r6ysk1ERmt1lAU7GgpTHiJN8+aVbPgE9L3eeFECSxSNbyo X5RrcP1AR8R/31IGaYeX01WWok3d/jHLYnF7I0otVHqEimYSVTxFUlTjXnEwT8miO6xR g7eKUNW/5LcxvjT9KBuYFXKdzFAPWNPbZmcNgwr7n5ygIjK6txZAwLuFnszRVjHwHIRx XpYmtdhdKZQcykvZ8ONmn8M4tfv91qUfIwBgnQQ8az6LjaxK7OB8q4u/Fw6CAgVZMM84 6S4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pz8JuCq6YUnW+8x68p8vAEiB/tqrsUC2viLEnk3KWDQ=; b=bmOZlsSDqqdRbyAZUPACuDXf7hd2FS+rYkZ/7A3f56HJdj/RsOdYUXu6HprI9daUMG rK4t0DtHNfIAwHyfe2sASEGz3XHNwJnuWmUT7RIA+yR9lJphVzYOOJpMOkL9emCzyVQ5 dKZugmUCA2QeNeDQWRQ3i+7l7XDOq4cMkpCkf74DmdT5FVOGA45VonWFujOmo3UWYn37 VNGW+YSXr+jkVleW4wskCqJ0KZ1Qn/eoGX1NkWurM0BvTDrNhNoQPl5+2+hg60K7lYK1 nFe28near4fL7AH3gKxqmMc6Yn5ia1ciUdVI/YTUqeFce0bLqmDWOlFWTuREg2jQG1Hz Fa/A== X-Gm-Message-State: AMke39n59lgxj0Ka/qnjkGPmrpxeBm4vC40KexPAyvTyyAfMKABcVbdq0GFf5+SPHQqVQ4S3Yk8uwvGo38Gj7A== X-Received: by 10.237.34.250 with SMTP id q55mr11582750qtc.144.1489019020827; Wed, 08 Mar 2017 16:23:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Mar 2017 16:23:40 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Mar 2017 11:23:40 +1100 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Brian Trammell , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 00:23:43 -0000 Found it! https://www.blackhat.com/docs/us-16/materials/us-16-VanGoethem-HEIST-HTTP-Encrypted-Information-Can-Be-Stolen-Through-TCP-Windows-wp.pdf I don't know what is worse, that these have naff names, or that I forget them so quickly. Added to #279. On 9 March 2017 at 11:13, Martin Thomson wrote: > On 9 March 2017 at 11:09, Martin Duke wrote: >> The proposal in #279 is nothing like fully-baked, but it's a bit indicating >> that the receiver is advertising zero-window, not indicating how big the >> window ever was. It might even be ambiguous about stream vs. connection flow >> control. >> >> I can't remember if we're sending an initial window in the clear or not, and >> this is worth thinking about, but it's not clear to me that's an issue. > > It's very definitely an issue. Being able to observe when the flow > control window hits zero was used in the attack (the one I can't > find). From nobody Wed Mar 8 17:46:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99981295D9 for ; Wed, 8 Mar 2017 17:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 zFp2MyvaK5DZ for ; Wed, 8 Mar 2017 17:45:58 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB9D12953D for ; Wed, 8 Mar 2017 17:45:57 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 8 Mar 2017 20:45:55 -0500 From: Dave Dolson To: Martin Duke , Brian Trammell Subject: RE: Middlebox introspection/self-describing packets Thread-Topic: Middlebox introspection/self-describing packets Thread-Index: AQHSmFSBe5LHTHc90EmU7CpJzM5KXqGL3nwAgAAQToD//8t6MA== Date: Thu, 9 Mar 2017 01:45:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.2] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870541281wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 01:46:00 -0000 --_000_E8355113905631478EFF04F5AA706E9870541281wtlexchp1sandvi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Within the context of PLUS, we have attempted to assemble a list of benefit= s provided by on-path middleboxes. Please see https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits= -02 >From the abstract: A primary goal of this document is to provide information to working groups developing new transport protocols, in particular the PLUS and QUIC working groups, to aid understanding of what might be gained or lost by design decisions that may affect (or be affected by) middlebox operation. The authors hope this will provide context for discussion about what sorts = of middlebox functions are worth supporting. We believe many important diagnostic and network protection mechanisms requ= ire some visibility into the transport connection, without violating privac= y. Please take a look. -Dave ________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Martin Duke [martin.h.duke@= gmail.com] Sent: Wednesday, March 08, 2017 6:43 PM To: Brian Trammell Cc: Eric Rescorla; IETF QUIC WG Subject: Re: Middlebox introspection/self-describing packets I have a substantially different position on middlebox inspection. First is= the load balancing point, which many people have already made. Second, service providers have an interest in (1) measuring the quality of = service they provide to customers, (2) enforcing bandwidth limitations, etc= . on users, and (3) identifying application types to provide QoS where it m= atters. I think (1) and (2) can be done without a meaningful loss of privac= y, although (3) is highly problematic. To that end, there are a number of o= pen issues looking to expose some transport state to middleboxes: - Packet number echo to allow RTT measurements (#269) - ECN to allow a non-loss rate-limiting signal (replacing TCP zero-window) = (#68) - Public flag bits to indicate flow-control and loss-detection causes of th= rottling, to aid in troubleshooting (#279) - I believe it was someone from = Orange in Tokyo who asked "how am I going to troubleshoot this?" - Replacing CONNECTION_CLOSE to an authenticated Public Reset to clear conn= ection state on middleboxes. (#353) No one has yet demonstrated that any of these are meaningful losses of priv= acy. They also require no modifications to the packet itself. For all the above reasons I am somewhat concerned about all of the surrepti= tious connection-ID changes, but I think all of these features are valuable= regardless of how those discussions turn out. On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell > wrote: hi ekr, The point in this space I'd use is =93expose nothing without necessity, or = clear benefit with mutual cooperation of the endpoints, but ensure exposed = information is efficiently usable.=94 > On 8 Mar 2017, at 22:38, Eric Rescorla = > wrote: > > There's recently been some back and forth on the headers PR about the > value of having packets be self-describing so that middleboxes can parse > them. > > To take a concrete example, consider the connection_id. In general, it se= ems > that mostly packets in a given direction either need connection_ids or do= n't > (assuming that the point of connection_id is partly to handle unexpected > NAT rebinding.), so this seems like a prime thing to negotiate. Jana argu= ed > in the PR that the reason to have a bit is to allow middleboxes to know h= ow > to parse the packet. Taking the case of Connection ID, specifically, it does seem to be a candid= ate for moving to negotiation, saving one header bit pretty much everywhere= . Connection ID is designed for load balancers, and one could define negoti= ation to be mandatory on the client side: if the server gives you a connect= ion ID, then the client MUST return it. Otherwise, any device trying to obs= erve the Connection ID would have to keep the has-a-Connection-ID state obs= erved during the negotiation, and it wouldn't have access to that state whe= n the Connection ID is used during rebinding. In this case, saving the bit costs you the possibility of client-side choic= e on whether to not return the Connection ID, which seems to me to violate = the mutual cooperation principle. Cheers, Brian > > It seems like it would be good to come to agreement about our attitude to= wards > middlebox inspection. I have been generally taking the position that we s= hould > conceal as much as possible from middleboxes and only expose what is need= ed > to make the protocol work (i.e., if possible I would encrypt conn_id and = packet > number). It seems like perhaps not everyone shares that objective, so I t= hought > I would ask what principles other people thought they were adhering to. > > Jana? MT? Others? > > -Ekr > > > --_000_E8355113905631478EFF04F5AA706E9870541281wtlexchp1sandvi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Within the context of PLUS, we have attempted to assemble a list of = benefits provided by on-path middleboxes.
Please see https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits-02

>From the abstract:
   A primary goal of this document is to provide information to workin=
g=0A=
   groups developing new transport protocols, in particular the PLUS and=0A=
   QUIC working groups, to aid understanding of what might be gained or=0A=
   lost by design decisions that may affect (or be affected by)=0A=
   middlebox operation.
The authors hope this will provide context for discussion about what sorts = of middlebox functions are worth supporting.
We believe many important diagnostic and network protection mechanisms requ= ire some visibility into the transport connection, without violating privac= y.

Please take a look.

-Dave



From: QUIC [quic-bounces@ietf.org] on b= ehalf of Martin Duke [martin.h.duke@gmail.com]
Sent: Wednesday, March 08, 2017 6:43 PM
To: Brian Trammell
Cc: Eric Rescorla; IETF QUIC WG
Subject: Re: Middlebox introspection/self-describing packets

I have a substantially different position on middlebox ins= pection. First is the load balancing point, which many people have already = made.

Second, service providers have an interest in (1) measuring the qualit= y of service they provide to customers, (2) enforcing bandwidth limitations= , etc. on users, and (3) identifying application types to provide QoS where= it matters. I think (1) and (2) can be done without a meaningful loss of privacy, although (3) is highly p= roblematic. To that end, there are a number of open issues looking to expos= e some transport state to middleboxes:
- Packet number echo to allow RTT measurements (#269)
- ECN to allow a non-loss rate-limiting signal (replacing TCP zero-win= dow) (#68) 
- Public flag bits to indicate flow-control and loss-detection causes = of throttling, to aid in troubleshooting (#279) - I believe it was someone = from Orange in Tokyo who asked "how am I going to troubleshoot this?&q= uot;
- Replacing CONNECTION_CLOSE to an authenticated Public Reset to clear= connection state on middleboxes. (#353) 

No one has yet demonstrated that any of these are meaningful losses of= privacy. They also require no modifications to the packet itself.

For all the above reasons I am somewhat concerned about all of the sur= reptitious connection-ID changes, but I think all of these features are val= uable regardless of how those discussions turn out.

On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell <= span dir=3D"ltr"> <ietf@trammell.ch<= /a>> wrote:
hi ekr,

The point in this space I'd use is =93expose nothing without necessity, or = clear benefit with mutual cooperation of the endpoints, but ensure exposed = information is efficiently usable.=94

> On 8 Mar 2017, at 22:38, Eric Rescorla <ekr@rtfm.com> wrote:
>
> There's recently been some back and forth on the headers PR about the<= br> > value of having packets be self-describing so that middleboxes can par= se
> them.
>
> To take a concrete example, consider the connection_id. In general, it= seems
> that mostly packets in a given direction either need connection_ids or= don't
> (assuming that the point of connection_id is partly to handle unexpect= ed
> NAT rebinding.), so this seems like a prime thing to negotiate. Jana a= rgued
> in the PR that the reason to have a bit is to allow middleboxes to kno= w how
> to parse the packet.

Taking the case of Connection ID, specifically, it does seem to be a= candidate for moving to negotiation, saving one header bit pretty much eve= rywhere. Connection ID is designed for load balancers, and one could define= negotiation to be mandatory on the client side: if the server gives you a connection ID, then the client = MUST return it. Otherwise, any device trying to observe the Connection ID w= ould have to keep the has-a-Connection-ID state observed during the negotia= tion, and it wouldn't have access to that state when the Connection ID is used during rebinding.

In this case, saving the bit costs you the possibility of client-side choic= e on whether to not return the Connection ID, which seems to me to violate = the mutual cooperation principle.

Cheers,

Brian


>
> It seems like it would be good to come to agreement about our attitude= towards
> middlebox inspection. I have been generally taking the position that w= e should
> conceal as much as possible from middleboxes and only expose what is n= eeded
> to make the protocol work (i.e., if possible I would encrypt conn_id a= nd packet
> number). It seems like perhaps not everyone shares that objective, so = I thought
> I would ask what principles other people thought they were adhering to= .
>
> Jana? MT? Others?
>
> -Ekr
>
>
>


--_000_E8355113905631478EFF04F5AA706E9870541281wtlexchp1sandvi_-- From nobody Wed Mar 8 17:46:59 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA6B1295D9 for ; Wed, 8 Mar 2017 17:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNpcYYbjOnkx for ; Wed, 8 Mar 2017 17:46:56 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1599012953D for ; Wed, 8 Mar 2017 17:46:56 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v76so1659329ywg.0 for ; Wed, 08 Mar 2017 17:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ezd1dxsOnsf/1M3UxMneTA4BKwMkwHfWxWIzjHxWIvo=; b=SNQiFMYeHYQYln7L64IQq3ZxlcHdOM/Ol6L4411dJHFJxVa8YifD4Yzx1gLib3HsVU vLXNe+gTeira7O/Q5m9tmZzuRYek/vKVSPsoLIg1Avm2/zPfDpWhDhjobYKiG8oAOa2J rTRD1reljzgcOflFwKNeaMHWNbfTsnTOdjjXPYWvEXsLvuozddagKSTZds8X/UgR8jbm 4kb205DoHCXRU4QGzDBPrFoKNbGJI5Ui1CPI26AxltzNRzvzT7Co53NFn30D18LKuoBl 2iQEz7WCXbEFFOdKSKtEdxA2H7ROxaEo0RbfiB81rnEghfl7aaerpbapGK+J3mDbIbvO JpSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ezd1dxsOnsf/1M3UxMneTA4BKwMkwHfWxWIzjHxWIvo=; b=HOlUU5tpfwhpWhR4dIJHinXvn5qbRpdye9bdMWNdAql7hA+ggvQ15MiXq7VWkThdZ9 XDFHmKM7e0/Sj0LxJ/o3TM1hgn4eC88aKF+DM2uPRSxlocFIIbvEVbHZ8YqfRxSb6jKz 3O3J1Y9OCR8VpwPTydMxBEOIFa1KJ2mrsFistIi8yE/IFvXDYMF3KSSg6vZdjpYobABJ ++wFTYK5eK2M+u4cijApz7JRLHFbl9lsKFQ9IbW4r8pTIPpYcEzhP1Jyi2WVjFXeE6Pi 1OQrKsxeD4WZRLAQmxK4PwSl+Avnbf7DAU+dEE+6SFzsR5D2txjABdwsTli5qMTQ0+2b Z8ZQ== X-Gm-Message-State: AMke39lANXKwoXyTvnHQh00T9txZcdWaNnM2bGgwr/yUtm/EnL94UhhOCRVuXiDoQPWgkncEh5KW9Dv7WesdYA== X-Received: by 10.13.240.196 with SMTP id z187mr2497757ywe.337.1489024015345; Wed, 08 Mar 2017 17:46:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 8 Mar 2017 17:46:14 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 8 Mar 2017 17:46:14 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Brian Trammell Content-Type: multipart/alternative; boundary=94eb2c034eb07f4560054a426be8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 01:46:58 -0000 --94eb2c034eb07f4560054a426be8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell wrote: > hi ekr, > > The point in this space I'd use is =E2=80=9Cexpose nothing without necess= ity, or > clear benefit with mutual cooperation of the endpoints, but ensure expose= d > information is efficiently usable.=E2=80=9D > > > On 8 Mar 2017, at 22:38, Eric Rescorla wrote: > > > > There's recently been some back and forth on the headers PR about the > > value of having packets be self-describing so that middleboxes can pars= e > > them. > > > > To take a concrete example, consider the connection_id. In general, it > seems > > that mostly packets in a given direction either need connection_ids or > don't > > (assuming that the point of connection_id is partly to handle unexpecte= d > > NAT rebinding.), so this seems like a prime thing to negotiate. Jana > argued > > in the PR that the reason to have a bit is to allow middleboxes to know > how > > to parse the packet. > > Taking the case of Connection ID, specifically, it does seem to be a > candidate for moving to negotiation, saving one header bit pretty much > everywhere. Connection ID is designed for load balancers, and one could > define negotiation to be mandatory on the client side: if the server give= s > you a connection ID, then the client MUST return it. Otherwise, any devic= e > trying to observe the Connection ID would have to keep the > has-a-Connection-ID state observed during the negotiation, and it wouldn'= t > have access to that state when the Connection ID is used during rebinding= . > To the extent to which the connection ID is (a) unique (b) long and (c) in a predictable place when it is present, it seems like it shouldn't be hard to look for it in that place whether the bit is there or not. In any case, what's the persuasive benefit for middleboxes to have this information. In this case, saving the bit costs you the possibility of client-side > choice on whether to not return the Connection ID, which seems to me to > violate the mutual cooperation principle. > Well, with negotiation, someone has to decide. The bit just moves that to the client. Except that if the load balancer *needs* it, then the client has to conform= . -Ekr > > Cheers, > > Brian > > > > > > It seems like it would be good to come to agreement about our attitude > towards > > middlebox inspection. I have been generally taking the position that we > should > > conceal as much as possible from middleboxes and only expose what is > needed > > to make the protocol work (i.e., if possible I would encrypt conn_id an= d > packet > > number). It seems like perhaps not everyone shares that objective, so I > thought > > I would ask what principles other people thought they were adhering to. > > > > Jana? MT? Others? > > > > -Ekr > > > > > > > > --94eb2c034eb07f4560054a426be8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell <ietf@trammell.ch>= ; wrote:
hi ekr,

The point in this space I'd use is =E2=80=9Cexpose nothing without nece= ssity, or clear benefit with mutual cooperation of the endpoints, but ensur= e exposed information is efficiently usable.=E2=80=9D

> On 8 Mar 2017, at 22:38, Eric Rescorla <ekr@rtfm.com> wrote:
>
> There's recently been some back and forth on the headers PR about = the
> value of having packets be self-describing so that middleboxes can par= se
> them.
>
> To take a concrete example, consider the connection_id. In general, it= seems
> that mostly packets in a given direction either need connection_ids or= don't
> (assuming that the point of connection_id is partly to handle unexpect= ed
> NAT rebinding.), so this seems like a prime thing to negotiate. Jana a= rgued
> in the PR that the reason to have a bit is to allow middleboxes to kno= w how
> to parse the packet.

Taking the case of Connection ID, specifically, it does seem to be a= candidate for moving to negotiation, saving one header bit pretty much eve= rywhere. Connection ID is designed for load balancers, and one could define= negotiation to be mandatory on the client side: if the server gives you a = connection ID, then the client MUST return it. Otherwise, any device trying= to observe the Connection ID would have to keep the has-a-Connection-ID st= ate observed during the negotiation, and it wouldn't have access to tha= t state when the Connection ID is used during rebinding.

To the extent to which the connection ID is (a) unique (b= ) long and (c) in a predictable place when it is
present, it seem= s like it shouldn't be hard to look for it in that place whether the bi= t is there or not.
In any case, what's the persuasive benefit= for middleboxes to have this information.

In this case, saving the bit costs you the possibility of client-side choic= e on whether to not return the Connection ID, which seems to me to violate = the mutual cooperation principle.

Well,= with negotiation, someone has to decide. The bit just moves that to the cl= ient.
Except that if the load balancer *needs* it, then the clien= t has to conform.

-Ekr
=C2=A0

Cheers,

Brian


>
> It seems like it would be good to come to agreement about our attitude= towards
> middlebox inspection. I have been generally taking the position that w= e should
> conceal as much as possible from middleboxes and only expose what is n= eeded
> to make the protocol work (i.e., if possible I would encrypt conn_id a= nd packet
> number). It seems like perhaps not everyone shares that objective, so = I thought
> I would ask what principles other people thought they were adhering to= .
>
> Jana? MT? Others?
>
> -Ekr
>
>
>


--94eb2c034eb07f4560054a426be8-- From nobody Wed Mar 8 18:16:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CE51294B6 for ; Wed, 8 Mar 2017 18:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhFt3LZZJYx3 for ; Wed, 8 Mar 2017 18:16:09 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0130.outbound.protection.outlook.com [104.47.32.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1901294A4 for ; Wed, 8 Mar 2017 18:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D/hgfxD5NUYffLz9pAcTFHJ42W4gu8HdaM+xZzloTM4=; b=M/mPalSK+EZRWBe3k1xY6trum5rqaa80XizdT/iO9HXZM7TbSc58emjWNQ7wn+DE8W0pRRx9XUcS7CkdD0b0lR9io50sSyAS20SokPEOaM0pPn0JktKiJXqMD7Vtp1mG+cgLqQUBM64i5fXKn7TSMjqnovS0xjKFVc9rb7DMuJc= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 02:16:07 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 02:16:07 +0000 From: Mike Bishop To: "quic@ietf.org" Subject: Divergence from HTTP/2 Thread-Topic: Divergence from HTTP/2 Thread-Index: AdKYd70rURZiuYADRA293Bil8tNr6A== Date: Thu, 9 Mar 2017 02:16:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.58.46.158] x-ms-office365-filtering-correlation-id: 0ea5e0e8-8447-45c9-73ed-08d466923f1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:WgGyWcQVioMtZROUDSkpZzYFcdtIQatbFzAR7b2bQ5EQXvFPJjn7IVmxn+Jt95YOViTSa1B/3zOov5wt/IpD1Ocv8Y7LsLqRwP3gpSBHe0oQrvT1nYH+CIeURs+/ZwFmasHg8rLrwIkggayycnYO3gRA0qHbFF40aU5Tx2UZXXLV9pyFMV/02ZFmpgoNKGTKwMuhywJaiLjZZ0fBUx5YUPUkI5LgUj6f3zajXmP2sItMJd/AyTXYkw7bAWTHF4D5+mXEVCkvJMaKnrTd2qYlcYqi3IOWkJ/ZrA9HYxNziP27kH1bq+XIr75mXegfNver7BaaSl+NxOu1v2C5TkaBKdijjanSDTUM9jpi9QxpG88= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39860400002)(39450400003)(39850400002)(51444003)(236005)(55016002)(8936002)(33656002)(54896002)(86612001)(2906002)(122556002)(8676002)(1730700003)(8990500004)(54356999)(6436002)(50986999)(6506006)(99286003)(2351001)(7736002)(77096006)(606005)(790700001)(3846002)(9686003)(81166006)(3660700001)(25786008)(6116002)(102836003)(5630700001)(7906003)(5640700003)(189998001)(7696004)(53936002)(3280700002)(66066001)(5005710100001)(5660300001)(10290500002)(2900100001)(2501003)(74316002)(110136004)(86362001)(10090500001)(38730400002)(6916009)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708F4CFE9DB1B2C113AD8A487210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 02:16:07.4738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 02:16:11 -0000 --_000_BN6PR03MB2708F4CFE9DB1B2C113AD8A487210BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At this point, I don't think anyone expects that HTTP/QUIC and HTTP/2 are t= he same protocol. However, the draft currently still attempts to define th= em as close cousins. In PR #363, I've consolidated almost all of the "different from HTTP/2" text int= o a new section and excised a lot of stuff about "HTTP/2 has this, but HTTP= /QUIC doesn't need it" from the main body of the document. Martin has advo= cated making a clean break from HTTP/2 and defining our own IANA registry f= or frame types and settings, just as we already have for errors. We can, o= ut of respect for legacy, use the same values where appropriate and reserve= existing values currently in use on the HTTP/2 side. I think that's a good idea, and it's a fairly small step from the current s= tate of #363. I've created PR #376 to actually make that split. Comments from the WG about either would be welcome. --_000_BN6PR03MB2708F4CFE9DB1B2C113AD8A487210BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At this point, I don’t think anyone expects th= at HTTP/QUIC and HTTP/2 are the same protocol.  However, the draft cur= rently still attempts to define them as close cousins.  In PR #363, I&#= 8217;ve consolidated almost all of the “different from HTTP/2” = text into a new section and excised a lot of stuff about “HTTP/2 has = this, but HTTP/QUIC doesn’t need it” from the main body of the document.  Martin has advocated making a clean break from HTTP/2 = and defining our own IANA registry for frame types and settings, just as we= already have for errors.  We can, out of respect for legacy, use the = same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

 

I think that’s a good idea, and it’s a f= airly small step from the current state of #363.  I’ve created PR #376 to a= ctually make that split.

 

Comments from the WG about either would be welcome.<= o:p>

--_000_BN6PR03MB2708F4CFE9DB1B2C113AD8A487210BN6PR03MB2708namp_-- From nobody Wed Mar 8 18:31:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB81295FB for ; Wed, 8 Mar 2017 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjtVuctrL_tK for ; Wed, 8 Mar 2017 18:31:55 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 7FB771294B6 for ; Wed, 8 Mar 2017 18:31:55 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id v76so2150027ywg.0 for ; Wed, 08 Mar 2017 18:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+uww6UtK3WhND3f69I3FcBuNSbT5oZw3aJP+9z0f2gs=; b=GhxhR1T1+H2sEj4QLApRQnnMVZnKprIA7lJU5g61f5OIOG/Pbm95C1TEU2Qyxf2Xox eQFuDJBEVQmNROKbt9TbzA/s8meuC7lNfuwuPg+OmqqM4Lgt6M5DVf3oSMXEqkP0gUPB iMYQURnOqUeL1jh037xsEp+JAzV8/HFxFYjBtzR6aYS7srFxh23FnrqU0aRwnwAU+LMy oGRWfvnA+DOh6T0HTi42BFgRiDk778+VYy8pZKY/0vzGIA36S8iZJ7+dlXCtUCwhzP5W FOyJsQT6/bym0lyOrl84EYvdz7m5QuL1auiVosJ7UqU34LQwNHuxnMPKi424iMiY/xlY 8r/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+uww6UtK3WhND3f69I3FcBuNSbT5oZw3aJP+9z0f2gs=; b=qHMcE32x3RGqRkyV/AxT3uZxqB4l/Gt5ZkY1EVs7J35kREjLod6sHN0EdLr7HAAq3u Jpppc3EbB37b6Mwn/EC3bSSd2eJgkW//rvDSQyswyn6CNGaEh5+kihBHvDV1hWCH9Iwg MNoIsM3MSwjElgY/R8Jfp+zYWlsrtK1EUKSv8y7G5qbBLT8EzsQfpcQ1mVDdYKc2paGx POFCe5BkYe9hf2v//nLrnSzUutUM2yNQ4oL8luie84Saq6/cHVzP2zfS/s6lwQuXpf15 Cte2i0Kt7cn2dPLrR25n3p0McgpVFWTxx40+p3ggt6h/s9HdATiMxDUCGSirsMGQFnlF Wnvg== X-Gm-Message-State: AMke39lV0LJd3UckiRScaXfBx1QijND5Ix6Fs1NDonGnlEypy1fQ3Z2V65CBdIhODiKU4wQaVkCsRe3x5Ip4Hw== X-Received: by 10.13.250.67 with SMTP id k64mr2385169ywf.125.1489026714759; Wed, 08 Mar 2017 18:31:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 8 Mar 2017 18:31:14 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 8 Mar 2017 18:31:14 -0800 Message-ID: Subject: Re: Divergence from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c07f34a650afa054a430c7d Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 02:31:57 -0000 --94eb2c07f34a650afa054a430c7d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 8, 2017 at 6:16 PM, Mike Bishop wrote: > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are > the same protocol. > Hmm.. I'm still hoping we can in fact converge them or at least maximize overlap. That said, I'll take a look at this PR and send comments. -Ekr > However, the draft currently still attempts to define them as close > cousins. In PR #363 , > I=E2=80=99ve consolidated almost all of the =E2=80=9Cdifferent from HTTP/= 2=E2=80=9D text into a new > section and excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HT= TP/QUIC > doesn=E2=80=99t need it=E2=80=9D from the main body of the document. Mar= tin has advocated > making a clean break from HTTP/2 and defining our own IANA registry for > frame types and settings, just as we already have for errors. We can, ou= t > of respect for legacy, use the same values where appropriate and reserve > existing values currently in use on the HTTP/2 side. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from the WG about either would be welcome. > --94eb2c07f34a650afa054a430c7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 8, 2017 at 6:16 PM, Mike Bishop <Michael.Bishop@microso= ft.com> wrote:

At this point, I don=E2=80=99t think anyone expects = that HTTP/QUIC and HTTP/2 are the same protocol.=C2=A0


Hmm.. I'm still hoping we can in fact conve= rge them or at least maximize overlap.

That said, = I'll take a look at this PR and send comments.

-Ekr
=C2=A0

However, the draft currently still atte= mpts to define them as close cousins.=C2=A0 In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdiffere= nt from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff = about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D from the main body of the document.=C2=A0 Martin has advocated making a clean break from HTTP/2 = and defining our own IANA registry for frame types and settings, just as we= already have for errors.=C2=A0 We can, out of respect for legacy, use the = same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from the WG about either would be welcome.<= u>


--94eb2c07f34a650afa054a430c7d-- From nobody Wed Mar 8 18:41:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB62129654 for ; Wed, 8 Mar 2017 18:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhpEy3Le6ZVJ for ; Wed, 8 Mar 2017 18:41:52 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0098.outbound.protection.outlook.com [104.47.33.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAD612962D for ; Wed, 8 Mar 2017 18:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+vPpfQZYJqN0U9AaMLULgoJf+8fL7QCOWQjD3EByeGY=; b=nh1ypUDXDamSrKi/mK0c/kFy7RoOFaMuXqH97RLzO+MqpAA7T0w7iiufFda+896sW1n5dKNV44yMiXxhbzdy5ApXDrEkjPxUf9FDVDU45O9GQDKKh1Jx0ToLJuUEEBLuC3ZWVH/3K1MTakqkaLeQZ362XMICj1Gz3LjOJdt3fkM= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 02:41:48 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 02:41:48 +0000 From: Mike Bishop To: Eric Rescorla Subject: RE: Divergence from HTTP/2 Thread-Topic: Divergence from HTTP/2 Thread-Index: AdKYd70rURZiuYADRA293Bil8tNr6AABXu4AAABee3M= Date: Thu, 9 Mar 2017 02:41:48 +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: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.16.14.232] x-ms-office365-filtering-correlation-id: f0a9fa9c-3155-4f5e-a242-08d46695d57d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:aTBYUqkaXSdo2XFIbwJyDvVpixWRGDxmBE0140GvE7rJhO/bsxx7vc8YdcCa+qsoGwzQnxbqy86taRONQphpf7Yh7EGR9EwPR+I2nFVmRNWRtqztFVsbm2jbttXko7N3O5yP2hbttdY3cSDb5KTQ6N/rOiz3AIJLj0/RayFg2DK4dHxqjbQ3ZJQZP3QDILBNROi7d6+qCMaS7Wdvv1BGD0S+e3pf3VqMQUAkdQTHNOOOxL+Vz1BQ8n4uQpfcT71ljppiRAsdoy+dQqZ9LFXThs+5BCRPTqqLfRwq2kbLb9B5nYqz3rkU76ia1uad5n3ruOWu4iEPk6dRLVkK8Fym7kIDHA1JXrahCKxIknvRH48= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39860400002)(39850400002)(39450400003)(39840400002)(24454002)(377454003)(2900100001)(9886003)(7906003)(74316002)(102836003)(7736002)(86362001)(236005)(55016002)(5005710100001)(76176999)(86612001)(50986999)(6116002)(10090500001)(4326008)(8990500004)(54356999)(3846002)(122556002)(10290500002)(81166006)(5660300001)(9686003)(38730400002)(8676002)(6246003)(99286003)(6436002)(6306002)(606005)(3660700001)(54896002)(3280700002)(8936002)(25786008)(53546006)(2950100002)(33656002)(7696004)(6506006)(77096006)(229853002)(110136004)(53936002)(6916009)(189998001)(2906002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708C17D701387A81028488787210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 02:41:48.1835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 02:41:54 -0000 --_000_BN6PR03MB2708C17D701387A81028488787210BN6PR03MB2708namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =85and validating assumptions like that is part of why we have a mailing li= st. ?? Sent from my Windows 10 phone From: Eric Rescorla Sent: Wednesday, March 8, 2017 6:31 PM To: Mike Bishop Cc: quic@ietf.org Subject: Re: Divergence from HTTP/2 On Wed, Mar 8, 2017 at 6:16 PM, Mike Bishop > wrote: At this point, I don=92t think anyone expects that HTTP/QUIC and HTTP/2 are= the same protocol. Hmm.. I'm still hoping we can in fact converge them or at least maximize ov= erlap. That said, I'll take a look at this PR and send comments. -Ekr However, the draft currently still attempts to define them as close cousins= . In PR #363, I=92ve conso= lidated almost all of the =93different from HTTP/2=94 text into a new secti= on and excised a lot of stuff about =93HTTP/2 has this, but HTTP/QUIC doesn= =92t need it=94 from the main body of the document. Martin has advocated m= aking a clean break from HTTP/2 and defining our own IANA registry for fram= e types and settings, just as we already have for errors. We can, out of r= espect for legacy, use the same values where appropriate and reserve existi= ng values currently in use on the HTTP/2 side. I think that=92s a good idea, and it=92s a fairly small step from the curre= nt state of #363. I=92ve created PR #376 to actually make that split. Comments from the WG about either would be welcome. --_000_BN6PR03MB2708C17D701387A81028488787210BN6PR03MB2708namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

=85and validating assumptions like that is part of w= hy we have a mailing list.  😉=

 

Sent from my Windows 10 phone

 

From: Eric Rescorla
Sent: Wednesday, March 8, 2017 6:31 PM
To: Mike Bishop<= br> Cc: quic@ietf.org
Subject: Re: Divergence from HTTP/2

 

On Wed, Mar 8, 2017 at 6:16 PM, Mike Bishop <Micha= el.Bishop@microsoft.com> wrote:

At this point, I don=92t think anyone expects that H= TTP/QUIC and HTTP/2 are the same protocol. 


Hmm.. I'm still hoping we can in fact converge them or at least maximi= ze overlap.

That said, I'll take a look at this PR and send comments.

-Ekr
 

However, the draft currently still attempts to defin= e them as close cousins.  In PR #363, I=92ve consolidated almost all of the =93different from HTTP= /2=94 text into a new section and excised a lot of stuff about =93HTTP/2 ha= s this, but HTTP/QUIC doesn=92t need it=94 from the main body of the document.  Martin has advocated making a clean b= reak from HTTP/2 and defining our own IANA registry for frame types and set= tings, just as we already have for errors.  We can, out of respect for= legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.=

 

I think that=92s a good idea, and it=92s a fairly sm= all step from the current state of #363.  I=92ve created PR #376 to actually make that split.

 

Comments from the WG about either would be welcome.<= u>


--_000_BN6PR03MB2708C17D701387A81028488787210BN6PR03MB2708namp_-- From nobody Wed Mar 8 20:36:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72033129525 for ; Wed, 8 Mar 2017 20:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fMQzcr1mLELD for ; Wed, 8 Mar 2017 20:36:26 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id E6C051294C0 for ; Wed, 8 Mar 2017 20:36:25 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6480616C7C6; Thu, 9 Mar 2017 04:36:25 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 3A1FE16C788; Thu, 9 Mar 2017 04:36:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489034185; bh=fjr7k3idBuoIM3NDCrLgDMhr9B8UCmsX3r/EBrKGmCc=; l=18672; h=From:To:CC:Date:References:In-Reply-To:From; b=g7wcu3Sko8+VsAfQMjiUXi2I+cPSopSRuqx1CiedubrcG2TRJYLSCwiNCGNBNWMeT b3WbP6yGJCY0pZx16LBQcrtcPFapJp69axAAhbZ3lokOSL6F76I6JC8Qz7Ey5wB6gV DexC3JkfAdloqHWrBUIyrLrbD9HePApLO0uf8+Vg= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 0910B1E07C; Thu, 9 Mar 2017 04:36:25 +0000 (GMT) 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.1178.4; Wed, 8 Mar 2017 23:36:24 -0500 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.1178.000; Wed, 8 Mar 2017 23:36:24 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "ianswett@google.com" , "Michael.Bishop@microsoft.com" Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAZchqAAAmG4AD//9VqgP//sP/mgABUcAD//7V6AIAAVDuA//+uD6IACrPRAAAVSHYAAAXDLkAACzgJ8AAKmz0AAAk+iAA= Date: Thu, 9 Mar 2017 04:36:23 +0000 Message-ID: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_de58521eea6a4ec1a51ea9d1b51e8f39usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 04:36:27 -0000 --_000_de58521eea6a4ec1a51ea9d1b51e8f39usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for opening the issue, Mike! > In that world, the requirement would be to reliably > deliver either a RST_STREAM or a STREAM frame > with the FIN bit set (basically, you MUST > communicate your final offset). So long as one of > those gets through, DISINTEREST by itself could > stop retransmissions. That feels marginally more > complicated Here is where our sense of "complexity" differs. To me, RST_STREAM and STRE= AM+FIN are virtually identical, because they cause identical transitions of= stream states. It is just that the former says "I am done and will not ret= ransmit" while the later says "I am done and will retransmit (unless you te= ll me you do not need my data -- something I am arguing is implicit in this= promise)". -----Original Message----- From: Mike Bishop [Michael.Bishop@microsoft.com] Received: Wednesday, 08 Mar 2017, 12:53PM To: Lubashev, Igor [ilubashe@akamai.com]; Ian Swett [ianswett@google.com]; = Martin Thomson [martin.thomson@gmail.com] CC: quic@ietf.org [quic@ietf.org] Subject: RE: DISINTEREST frame You're correct that the sender of DISINTEREST no longer cares about the dat= a, other than for flow control and state consistency. I had been trying to approach it from a principle that only the sender can = affect the stream state in their direction - the receiver can only request = changes. As the draft currently reads, the receiver counts flow control as= STREAM frames are received, and upon receipt of a RST_STREAM. If a STREAM= frame is delayed, it doesn't (yet) count against the receiver's flow contr= ol window, even if it can infer that the data has been sent (by virtue of r= eceiving a later offset). Only upon receipt of a RST_STREAM do you account= all outstanding data against the flow control window. Changing it so that all data up to the furthest offset received on a stream= counts is certainly possible, but feels like an orthogonal change to this = PR. I've opened issue #370 for that. In that world, the requirement would= be to reliably deliver either a RST_STREAM or a STREAM frame with the FIN = bit set (basically, you MUST communicate your final offset). So long as on= e of those gets through, DISINTEREST by itself could stop retransmissions. = That feels marginally more complicated, since it adds an additional path t= o stop retransmission on a stream and makes the accounting logic on receipt= of a STREAM frame more complicated. My inclination is to leave retransmissions tied to having sent RST_STREAM, = but I'll defer to others whether the complexity is worth the potential savi= ngs. From: Lubashev, Igor [mailto:ilubashe@akamai.com] Sent: Wednesday, March 8, 2017 9:19 AM To: Lubashev, Igor ; Ian Swett ; = Martin Thomson Cc: Mike Bishop ; quic@ietf.org Subject: RE: DISINTEREST frame P.S. The paragraph above states: * [STREAM frames received after sending DISINTEREST] will be discarded So I read it that the peer who send DISINTEREST will not be waiting for tha= t data. That peer does not need any accounting for flow control either, si= nce he has already received the FIN (with the byte offset) and is already i= n "half-closed (remote)" or "closed" state. From: Lubashev, Igor [mailto:ilubashe@akamai.com] Sent: Wednesday, March 08, 2017 12:10 PM To: Ian Swett >; Martin Tho= mson > Cc: Michael.Bishop@microsoft.com; quic= @ietf.org Subject: RE: DISINTEREST frame * you definitely need "RST_STREAM is sent unless all outstanding data h= as been sent AND acknowledged.", otherwise the peer waits forever for data = that won't arrive. I guess this is the core of the question, which goes beyond the choice for = this rare condition. "It is reasonable to think that the peer who sent DISI= NTEREST is still waiting for any data?" The whole point of DISINTEREST is = to indicate that "I am not waiting for any more data". From: Ian Swett [mailto:ianswett@google.com] Sent: Wednesday, March 08, 2017 9:51 AM To: Martin Thomson > Cc: Lubashev, Igor >; Micha= el.Bishop@microsoft.com; quic@ietf.org= Subject: Re: DISINTEREST frame Martin's right, you definitely need "RST_STREAM is sent unless all outstand= ing data has been sent AND acknowledged.", otherwise the peer waits forever= for data that won't arrive. Question: Why call it DISINTEREST, instead of REQUEST_RST? It wasn't obvio= us to me what DISINTEREST was until I read further, whereas REQUEST_RST is = pretty obvious, assuming you know about RST_STREAM. On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson > wrote: On 8 March 2017 at 15:35, Lubashev, Igor > wrote: > We are taking about a case when the sender of the stream is already in > "half-closed (local)" (or "closed") and the receiver is already in > "half-closed (remote)" (or "closed"). This RST_STREAM will not affect the > state of the stream for any peer. The only information RST_STREAM contain= s > now is "I will not transmit". But the peer already sent DISINTERESTED to > indicate it does not care about retransmissions. Even after closing a stream, an endpoint needs to retransmit data. It closes when it first sends the FIN. --_000_de58521eea6a4ec1a51ea9d1b51e8f39usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for opening the issue, Mike!

> In that world, the requirement would be to reliably
> deliver either a RST_STREAM or a STREAM frame
> with the FIN bit set (basically, you MUST
> communicate your final offset). So long as one of
> those gets through, DISINTEREST by itself could
> stop retransmissions. That feels marginally more
> complicated

Here is where our sense of "complexity" differs. To me, RST_STREA= M and STREAM+FIN are virtually identical, because they cause identical = transitions of stream states. It is just that the former says "I am do= ne and will not retransmit" while the later says "I am done and will retransmit (unless you tell me you do not need my data --= something I am arguing is implicit in this promise)".

-----Original Message-----
From: Mike Bishop [Michael.Bishop@microsoft.com]
Received: Wednesday, 08 Mar 2017, 12:53PM
To: Lubashev, Igor [ilubashe@akamai.com]; Ian Swett [ianswett@google= .com]; Martin Thomson [martin.thomson@gmail.com]
CC: quic@ietf.org [quic@ietf.org]
Subject: RE: DISINTEREST frame

You’re correct that the sender of DISINTERES= T no longer cares about the data, other than for flow control and state con= sistency.

 

I had been trying to approach it from a principle = that only the sender can affect the stream state in their direction –= the receiver can only request changes.  As the draft currently reads, the receiver counts flow control as STREAM frames are rec= eived, and upon receipt of a RST_STREAM.  If a STREAM frame is delayed= , it doesn’t (yet) count against the receiver’s flow control wi= ndow, even if it can infer that the data has been sent (by virtue of receiving a later offset).  Only upon receipt of a= RST_STREAM do you account all outstanding data against the flow control wi= ndow.

 

Changing it so that all data up to the furthest of= fset received on a stream counts is certainly possible, but feels like an o= rthogonal change to this PR.  I’ve opened issue #370 for that.  In that world, the requirement would be to reliably d= eliver either a RST_STREAM or a STREAM frame with the FIN bit set (basically, you MUST communic= ate your final offset).  So long as one of those gets through, DISINTE= REST by itself could stop retransmissions.  That feels marginally more= complicated, since it adds an additional path to stop retransmission on a stream and makes the accounting logic on = receipt of a STREAM frame more complicated.

 

My inclination is to leave retransmissions tied to= having sent RST_STREAM, but I’ll defer to others whether the complex= ity is worth the potential savings.

 

From: Lubashev, Igor [mailto:iluba= she@akamai.com]
Sent: Wednesday, March 8, 2017 9:19 AM
To: Lubashev, Igor <ilubashe@akamai.com>; Ian Swett <ianswe= tt@google.com>; Martin Thomson <martin.thomson@gmail.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org<= br> Subject: RE: DISINTEREST frame

 

P.S.

  The paragraph above states:

 

  • [STREAM frames r= eceived after sending DISINTEREST] will be discarded

 

So I read it that the peer who send DISINTEREST wi= ll not be waiting for that data.  That peer does not need any acco= unting for flow control either, since he has already received the FIN (with= the byte offset) and is already in “half-closed (remote)” or &= #8220;closed” state.

 

 

From: Lubashev, Igor [mailto:ilubashe@akamai.com]
Sent: Wednesday, March 08, 2017 12:10 PM
To: Ian Swett <ianswett@go= ogle.com>; Martin Thomson <martin.thomson@gmail.com>
Cc: Michael.Bishop@m= icrosoft.com; quic@ietf.org
Subject: RE: DISINTEREST frame

 

  • you definitely nee= d "RST_STREAM is sent unless all outstanding data has been sent AND ac= knowledged.", otherwise the peer waits forever for data that won't arr= ive.

 

 

I guess this is the core of the question, which go= es beyond the choice for this rare condition. “It is reasonable to th= ink that the peer who sent DISINTEREST is still waiting for any data?”  The whole point of DISINTEREST is to indicate t= hat “I am not waiting for any more data”.

 

 

From: Ian Swett [mailto:ianswett@google.com]
Sent: Wednesday, March 08, 2017 9:51 AM
To: Martin Thomson <m= artin.thomson@gmail.com>
Cc: Lubashev, Igor <ilubas= he@akamai.com>; Michael.Bishop@microsoft.co= m; quic@ietf.org
Subject: Re: DISINTEREST frame

 

Martin's right, you definitely need "RST_STREAM= is sent unless all outstanding data has been sent AND acknowledged.",= otherwise the peer waits forever for data that won't arrive.

 

Question: Why call it DISINTEREST, instead of REQUES= T_RST?  It wasn't obvious to me what DISINTEREST was until I read furt= her, whereas REQUEST_RST is pretty obvious, assuming you know about RST_STR= EAM.

 

On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

On 8 March 2017 at 15= :35, Lubashev, Igor <ilubashe@aka= mai.com> wrote:
> We are taking about a case when the sender of the stream is already in=
> "half-closed (local)" (or "closed") and the receiv= er is already in
> "half-closed (remote)" (or "closed"). This RST_STR= EAM will not affect the
> state of the stream for any peer. The only information RST_STREAM cont= ains
> now is "I will not transmit". But the peer already sent DISI= NTERESTED to
> indicate it does not care about retransmissions.

Even after closing a stream, an endpoint needs to retransmit data.  It=
closes when it first sends the FIN.

 

--_000_de58521eea6a4ec1a51ea9d1b51e8f39usma1exdag1mb5msgcorpak_-- From nobody Wed Mar 8 23:27:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFEA128E18 for ; Wed, 8 Mar 2017 23:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 VHsWjxz9Vh3n for ; Wed, 8 Mar 2017 23:27:52 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 3A47A1204D9 for ; Wed, 8 Mar 2017 23:27:52 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id f54so65410935uaa.1 for ; Wed, 08 Mar 2017 23:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s6784W2AoDEdNpFAuW+EkaHbNKeyeOTPOuEC/fFyg6s=; b=Y1oyxCNbtSS6LNCUA4Zi+lEHfFfpvOo7/5V1LwmNkCGXTBCKmzRn2GvEgFqnFv4TNz fECCCVo4dG50M75LQvMNPkPLVOtagcyyS4cTUVWnpqv5L7j9eUorc6iQtaQqrrRrXMKs wiXtXCvNLbNXOJgYMWr5dpmHEANvKsloj29tG3681C0ahtf2cXc0vm6rwGz4GGd8KT18 XM3XzICowIQ8u/QYrO4DgA8ktRYkzgDlSl68on7VFZeYbZ94QZ1v8hurQ3P9AoUVO7+I AIQcMW9SCsD7PC5vWph+KepxXcqS+o3m1Vhq77HNfzXjSZDm+l1sUAi/bhbprd0fJmrK EcnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s6784W2AoDEdNpFAuW+EkaHbNKeyeOTPOuEC/fFyg6s=; b=jMFjllHG+s24Knhz7q8ziVEOKI7GgtSAgEy3LHWZdxIDecdVtoQYZ6UKGfbaTJZ+zc Z+xtL+3NsUs3aHc8NCXk8kcSzRxibohOJvZgRxNLIrxYWnSubIUPMHq4YjDGeZUF2MTo umNCyAnjwPY4RwU7+lqiwAwvBVM0iPuBYWiapvKQ7++SZlm59cm/9cksb0erMQmW11qZ hVvO1nSoyaAqSKf6A9b1c0iCHvDCImtjWklDZC8eSGSZOXPpqA4fU8nAQTjOiF9S/hQA 63PB2B178mEHcSCC6gA1R3EWuVrp2EIYewpbSuIeKlKoqQewvWSO4B6UL/pixGQgjvDr FQdQ== X-Gm-Message-State: AMke39nzcsXBnwCjyDek8u8tNINCo/Cz+NhNyrPKIFa2xAg/L6vjj0wKDkdMjsxJsgsYMNrs6xLrBbx5Hp1gzuo6 X-Received: by 10.176.8.5 with SMTP id a5mr5739704uaf.143.1489044471078; Wed, 08 Mar 2017 23:27:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Wed, 8 Mar 2017 23:27:50 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 8 Mar 2017 23:27:50 -0800 Message-ID: Subject: Re: Return of the alternate header proposal To: Ian Swett Content-Type: multipart/alternative; boundary=f403045f882ec13517054a472ef3 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 07:27:54 -0000 --f403045f882ec13517054a472ef3 Content-Type: text/plain; charset=UTF-8 I've received many helpful comments on the PR, which I've now incorporated and I've gotten one approval. I've also gotten go-aheads from almost everyone, so I'd like to land this PR on Thursday (PST), if possible. I'm giving a heads-up to those who may not have had a chance to go over it yet: please do it soon. If I don't hear otherwise, I plan to land this PR at noon on Thursday (PST). On Tue, Mar 7, 2017 at 11:41 AM, Jana Iyengar wrote: > On Tue, Mar 7, 2017 at 11:25 AM, Ian Swett wrote: > >> On Tue, Mar 7, 2017 at 2:20 PM, Eric Rescorla wrote: >> >>> Hi Jana, >>> >>> I sent a bunch of comments in the PR. I think this is in the right >>> direction, but I also >>> >> > Thanks, will respond on PR. > > >> have some concerns. To summarize my technical comments: >>> >>> - I don't think the key phase bit mechanism works correctly. >>> >> > I'll take a look at your comments. > > >> - I'm not thrilled about having the packet # and conn id length depend on >>> a per-packet >>> basis. Why can't we negotiate these? >>> >> >> The major negative of negotiating the packet number length is that it >> makes it impossible for passive observers to know what the length is. >> Which would make monitoring and features such as packet number echo >> impractical. >> > > I'll add that without these bits, we need middleboxes (including load > balancers) to look into the handshake stream frames to determine what's > being negotiated. This means that we either require middleboxes to change > if we change the stream frame or the handshake format in the future, or we > make those bits version-independent. > > I also have concerns with middleboxes getting this parsing wrong, which > can ossify bits inside the handshake stream frames in quite unfortunate > ways. > > Plus, I have a bunch of editorial comments. >>> >> > Thanks! Will take a look. > > - jana > > > >> -Ekr >>> >>> On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar wrote: >>> >>>> Hi all, >>>> >>>> Based on the (very constructive) discussion around the previous >>>> alternate header proposal >>>> , >>>> I've crafted PR #361 that >>>> incorporates mailing-list feedback. This PR does not attempt to be the >>>> final form of the header, but it hopes to be a significant way forward in >>>> that direction. >>>> >>>> This PR closes a large number of issues. I'd like to get this merged >>>> into the draft by the draft deadline (a week from now), with the >>>> understanding that this format may still change as we discuss issues >>>> further. Please read and provide feedback. >>>> >>>> The PR is a bit invasive and unfortunately large, so I'll summarize a >>>> few salient points about it here. >>>> >>>> - The PR includes a header-form bit that allows easy distinction >>>> between long and short headers. It also delineates version-independent >>>> fields from version-specific ones. >>>> >>>> - The PR introduces use of Server-selected Connection ID, and specifies >>>> rules for distinguishing it from the client-selected one. In summary, >>>> server-selected Connection IDs are used for the final handshake packet >>>> (ServerHello) and all subsequent packets. Everything before it uses the >>>> client-selected Connection ID, including intermediate server handshake >>>> packets (those carrying HelloRetryRequests). >>>> >>>> - Connection ID in a packet is available to a stateless load balancer: >>>> always present in long headers and indicated via a CONNECTION_ID flag in >>>> short headers. In all cases, the connection ID field is in the same >>>> location. >>>> >>>> - Public Reset packets are required to include a Proof, but the proof >>>> is TBD. >>>> >>>> Thanks, >>>> - jana >>>> >>> >>> >> > --f403045f882ec13517054a472ef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've received many helpful comments on the PR, which I= 've now incorporated and I've gotten one approval. I've also go= tten go-aheads from almost everyone, so I'd like to land this PR on Thu= rsday (PST), if possible. I'm giving a heads-up to those who may not ha= ve had a chance to go over it yet: please do it soon.

If= I don't hear otherwise, I plan to land this PR at noon on Thursday (PS= T).

On= Tue, Mar 7, 2017 at 11:41 AM, Jana Iyengar <jri@google.com> = wrote:
On Tue, Mar 7, 2017 a= t 11:25 AM, Ian Swett <ianswett@google.com> wrote:
On Tue, Mar 7, 2017 at 2:20 PM, Eric Rescorla = <ekr= @rtfm.com> wrote:
Hi Jana,

I sent a bunch of comments in the PR. = I think this is in the right direction, but I also

Thanks, will respond on PR.
=C2=A0
<= div>have some concerns. To summarize my technical comments:

<= /div>
- I don't think the key phase bit mechanism works correctly.<= /div>

I'll take a look at your comments.
=
=C2=A0
- I'm not thrilled about having the packet = # and conn id length depend on a per-packet
=C2=A0 basis. Why can= 't we negotiate these?

The major negative of negotiating the packet number length is that it ma= kes it impossible for passive observers to know what the length is.=C2=A0 W= hich would make monitoring and features such as packet number echo impracti= cal.

I'l= l add that without these bits, we need middleboxes (including load balancer= s) to look into the handshake stream frames to determine what's being n= egotiated. This means that we either require middleboxes to change if we ch= ange the stream frame or the handshake format in the future, or we make tho= se bits version-independent.=C2=A0

I also have con= cerns with middleboxes getting this parsing wrong, which can ossify bits in= side the handshake stream frames in quite unfortunate ways.

Plus, I have a bunch of editorial comments= .

Thanks! Will take a look.

- jana

=C2=A0
-Ekr

On Mon, Mar 6, 2017 at 5:16 PM, Jana Iyengar <jri@go= ogle.com> wrote:
Hi all,

Based on the (very construct= ive) discussion around the previous alternate header pr= oposal, I've crafted PR #361=C2=A0that incorporates mailing-l= ist feedback. This PR does not attempt to be the final form of the header, = but it hopes to be a significant way forward in that direction.
<= br>
This PR closes a large number of issues. I'd like to get = this merged into the draft by the draft deadline (a week from now), with th= e understanding that=C2=A0this format may = still change as we discuss issues further. Please read and provide feedback= .

T= he PR is a bit invasive and unfortunately large, so I'll summarize a fe= w salient points about it here.=C2=A0

- The PR inc= ludes a header-form bit that allows easy distinction between long and short= headers. It also delineates version-independent fields from version-specif= ic ones.

- The PR introduces use of Server-selecte= d Connection ID, and specifies rules for distinguishing it from the client-= selected one. In summary, server-selected Connection IDs are used for the f= inal handshake packet (ServerHello) and all subsequent packets. Everything = before it uses the client-selected Connection ID, including intermediate se= rver handshake packets (those carrying HelloRetryRequests).
<= br>
- Connection ID in a packet is available to a stateless load = balancer: always present in long headers and indicated via a CONNECTION_ID = flag in short headers. In all cases, the connection ID field is in the same= location.

- Public Reset packets are required to = include a Proof, but the proof is TBD.

Thanks,
- jana




--f403045f882ec13517054a472ef3-- From nobody Thu Mar 9 00:51:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE55E1294DA for ; Thu, 9 Mar 2017 00:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12CuVExScyCe for ; Thu, 9 Mar 2017 00:51:00 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF891294BE for ; Thu, 9 Mar 2017 00:51:00 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id v125so106727084qkh.2 for ; Thu, 09 Mar 2017 00:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=guaVuPxe071pUfbPiESV8lbWb6soRuhVDPtkPkeQx6o=; b=iWxFbcryGICA2anUP1IhzS+cUuwa5TuTdObIGJcJfV49+5xlqAiWWJauuS/Jic1VC3 epN42O6/dYxw475An8MfJpIqovxj50mwauUgYsbLPrfKFLklSRqawlJ+OsebxC8mxBnN VjXu5Zw41zWqQBMMF7VK6Gs0y3hexk7Jg4qPKxq6WYR+s2QlrvBH0kG6Xsj1BSdB6a1k X7vetlUnmgZiYzNbA3lG3mPSVmw2XOFZsSLEspMNLqzw1A6A88c8uAEV0RUABgVKqdck ngAzhVEmGe2bzEptNSa7j4fHM2DTSIKRbOVAyUsdlyxk/dZN2GeS5pZqCp1mJagibVSQ ywXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=guaVuPxe071pUfbPiESV8lbWb6soRuhVDPtkPkeQx6o=; b=pV06Dz3qw2Ut0M8/b3TWZtMb4FZwPQorptdDGJ0sCqpbJJOyxqIgRHFi8LCGmUWAk2 88otLQs3aA6EO4qrEhpQ9VpCq96/7KMk0db2Mn4AbkBe7VF5pzypmAw9qM+J76JJTOwl 32VW6mBosp3MAhlVCWv9giEKUBZes5OXMkPEFDjavpAhhFT4DJ0sfyK7ZTKtXQSKYgE3 VVex5IFbCha+hZeKs2bvVbxkRdsEBmqAail/bPM9O1SZB0FcVXEYhvhGgCR5dP7S1SRB Vuz4qHNE129p6OzXUhL65z329+35j6m7JIa1SLpci1otmRJMx3CGuiVaW/ckCC+7OAgP HuDw== X-Gm-Message-State: AMke39lUAqdprcR4KoqDq2uysOY12oiawQ1UYUKDEDdF0pC5P1ZsCpO2RSBFuJN5iWL3SI4sdrjES9GhN/T6Bg== X-Received: by 10.237.34.250 with SMTP id q55mr13377918qtc.144.1489049459897; Thu, 09 Mar 2017 00:50:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Mar 2017 00:50:59 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Mar 2017 19:50:59 +1100 Message-ID: Subject: Re: Return of the alternate header proposal To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ian Swett , IETF QUIC WG , Eric Rescorla X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 08:51:02 -0000 On 9 March 2017 at 18:27, Jana Iyengar wrote: > I've received many helpful comments on the PR, which I've now incorporated > and I've gotten one approval. I've also gotten go-aheads from almost > everyone, so I'd like to land this PR on Thursday (PST), if possible. I'm > giving a heads-up to those who may not have had a chance to go over it yet: > please do it soon. > > If I don't hear otherwise, I plan to land this PR at noon on Thursday (PST). I think that this is a good idea. I don't think that we need to have consensus on every detail of this (and I don't think we do), but I think that this will unblock a bunch of other work. I hope that this is acceptable to chairs process-wise. On that point, a question for the chairs in light of Mark's recent email regarding consensus decisions. I expect that this single change will result in a bunch of issues being closed. A lot of those will be closed as now being irrelevant, but some might not be fully "closed" in the sense that the underlying concern wasn't addressed. I hope that the people reviewing this will identify new issues where this PR fell short of meeting their goals. Is that an acceptable process here? Do you want to avoid marking the issues we close as a result of this change with "has-consensus"? From nobody Thu Mar 9 01:07:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9D129438 for ; Thu, 9 Mar 2017 01:07:30 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=IOAA1zSx; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=S/nmdxlG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuRQMnfaPYUG for ; Thu, 9 Mar 2017 01:07:29 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F501293EE for ; Thu, 9 Mar 2017 01:07:28 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id 2655F15A08C0; Thu, 9 Mar 2017 10:07:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489050447; bh=zEaCmQPaOVDDOPzkJnMfGbQvxSJf8N697NY4FF/7VJg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IOAA1zSxuj7dM7PgNfddHgVl8w3yWshE9y34nj4lyvETiRzfNCBV9R1fuWcdvnwO5 483cNtOuUyVobZ0X6ZTrEu8k0UG9hp1SUvHDHLaTUpyazfTApna9CHB8GhjPe99RYm +mSYpaJ1lsnlmy1yI998WKSzzf/UfXe2qpGeX0QI= Received: from [100.93.169.87] (unknown [109.40.3.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 416E315A06A1; Thu, 9 Mar 2017 10:07:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489050446; bh=zEaCmQPaOVDDOPzkJnMfGbQvxSJf8N697NY4FF/7VJg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=S/nmdxlG74fc0jlwHrWNU1osoAaC+4eknHf+978FNu5odS/AreTIKj8gfNAH3JALH vrK2l5zVGXlv3SvuMuRf1eSTJPKblXpJV7I5+Eykz21lUt3H0d+S9B4Xt8M5S3aJ1F svsDZwRnXEkwWFAlkl/JL1FRh3WqrM7JFBho87nQ= Content-Type: multipart/alternative; boundary=Apple-Mail-E3487D84-5E82-4305-A0D3-CAC334D3F124 Mime-Version: 1.0 (1.0) Subject: Re: Divergence from HTTP/2 From: Stefan Eissing X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 9 Mar 2017 10:07:23 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> References: To: Mike Bishop Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 09:07:31 -0000 --Apple-Mail-E3487D84-5E82-4305-A0D3-CAC334D3F124 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for separating this out, Mike. For spare time folks this makes follow= ing this aspect easier. My first impression is that any hope to have http/2 over tcp and quic needs t= o be abandoned. Which will give the world a third protocol to carry http sem= antics. What does that mean for the evolution of http, I wonder. -stefan > Am 09.03.2017 um 03:16 schrieb Mike Bishop := >=20 > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HTT= P/2 are the same protocol. However, the draft currently still attempts to d= efine them as close cousins. In PR #363, I=E2=80=99ve consolidated almost a= ll of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new section an= d excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn= =E2=80=99t need it=E2=80=9D from the main body of the document. Martin has a= dvocated making a clean break from HTTP/2 and defining our own IANA registry= for frame types and settings, just as we already have for errors. We can, o= ut of respect for legacy, use the same values where appropriate and reserve e= xisting values currently in use on the HTTP/2 side. > =20 > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step f= rom the current state of #363. I=E2=80=99ve created PR #376 to actually mak= e that split. > =20 > Comments from the WG about either would be welcome. --Apple-Mail-E3487D84-5E82-4305-A0D3-CAC334D3F124 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for separating this o= ut, Mike. For spare time folks this makes following this aspect easier.

My first impression is that any hope to have http/2 ove= r tcp and quic needs to be abandoned. Which will give the world a third prot= ocol to carry http semantics.

What does that mean f= or the evolution of http, I wonder.

-stefan

Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:

=

At this point, I don=E2=80=99t think anyone expects t= hat HTTP/QUIC and HTTP/2 are the same protocol.  However, the draft cur= rently still attempts to define them as close cousins.  In PR #363, I=E2= =80=99ve consolidated almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80= =9D text into a new section and excised a lot of stuff about =E2=80=9CHTTP/2= has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80=9D from the main body= of the document.  Martin has advocated making a clean break from HTTP/2 a= nd defining our own IANA registry for frame types and settings, just as we a= lready have for errors.  We can, out of respect for legacy, use the sam= e values where appropriate and reserve existing values currently in use on the HTTP/2 side.

 

I think that=E2=80=99s a good idea, and it=E2=80=99s a= fairly small step from the current state of #363.  I=E2=80=99ve create= d PR #376 to ac= tually make that split.

 

Comments from the WG about either would be welcome.

= --Apple-Mail-E3487D84-5E82-4305-A0D3-CAC334D3F124-- From nobody Thu Mar 9 02:22:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421D6129500 for ; Thu, 9 Mar 2017 02:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcjBmjqvuHIm for ; Thu, 9 Mar 2017 02:22:54 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 345391294ED for ; Thu, 9 Mar 2017 02:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489054971; l=1733; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=q/AB5S7GjeN9w+QSn6yMU9SICMGHMgfVsY/3WqIfJ1k=; b=RJbBX4Px/JD1P3BbpazCXOkJBMPk4jQC4KXpJhMyceWd6+jVmYRF2Y6u8GzWS8O5rR vhj35yuQUkfhg2hw+/wx0Le6QBxojZ0VvPGTBMhe4oOpzNMy9bkiA42AwmMsX484zUok R6IeTCdAom/aQTAShT0fSO+pZdEK9gFjIqXsE= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyCBKUXHiiJD900p0TuPJc3Hp+vSQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:3d34:f546:88b2:b6b8] ([2001:4dd0:ff67:0:3d34:f546:88b2:b6b8]) by smtp.strato.de (RZmta 40.1 AUTH) with ESMTPSA id N02e5et29AMp0A6 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 9 Mar 2017 11:22:51 +0100 (CET) Subject: Re: Middlebox introspection/self-describing packets To: quic@ietf.org References: From: Roland Zink Message-ID: Date: Thu, 9 Mar 2017 11:22:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:22:56 -0000 Hi Martin, The main thing which seems to be used in this attack seems the TCP congestion control algorithm and the initial window. Assuming QUIC will use the same it will be attackable as well with or without exposing this to the network. The attack even does run within the endpoint and does not require access to the network at all. According to this paper it doesn't seem wise to use HPACK in HTTP2, at least without padding. Should header compression be done in QUIC? Btw. middleboxes which are able to influence the TCP congestion control algorithm and the initial window (like a PEP) actually may make this attack more difficult. Regards, Roland Am 09.03.2017 um 01:23 schrieb Martin Thomson: > Found it! > > https://www.blackhat.com/docs/us-16/materials/us-16-VanGoethem-HEIST-HTTP-Encrypted-Information-Can-Be-Stolen-Through-TCP-Windows-wp.pdf > > I don't know what is worse, that these have naff names, or that I > forget them so quickly. Added to #279. > > On 9 March 2017 at 11:13, Martin Thomson wrote: >> On 9 March 2017 at 11:09, Martin Duke wrote: >>> The proposal in #279 is nothing like fully-baked, but it's a bit indicating >>> that the receiver is advertising zero-window, not indicating how big the >>> window ever was. It might even be ambiguous about stream vs. connection flow >>> control. >>> >>> I can't remember if we're sending an initial window in the clear or not, and >>> this is worth thinking about, but it's not clear to me that's an issue. >> It's very definitely an issue. Being able to observe when the flow >> control window hits zero was used in the attack (the one I can't >> find). From nobody Thu Mar 9 02:39:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3206128DF6 for ; Thu, 9 Mar 2017 02:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 6_8f4aeKQWHX for ; Thu, 9 Mar 2017 02:39:46 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0054.outbound.protection.outlook.com [104.47.0.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC53127071 for ; Thu, 9 Mar 2017 02:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KiRK565yQbiJqkzqxvrZeuN5oyAifVOYut3hyan8xQo=; b=dOlGr76Z7qKg5bPlCQGwr0NStox8j3ddI0R+UrhKKzuLmv9MjKmUncCHjiredMTeQQYhksIWeuWOm7irmJiLZbY+OMgdanfVICqDYtxN43v2IeeGqhB/JzKBTI+lhylksU5Nj/hX+iJksaMLo5D4yoEwzZy/mlchiPZ+hIAd/pk= Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) by HE1PR0802MB2473.eurprd08.prod.outlook.com (10.175.34.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 10:39:43 +0000 Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) by HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 10:39:43 +0000 From: Hannes Tschofenig To: "quic@ietf.org" Subject: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Topic: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Index: AdKYwCv+WlyzFqftRk6FS9cmOv7E4Q== Date: Thu, 9 Mar 2017 10:39:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.114.23] x-ms-office365-filtering-correlation-id: 0d511c7d-cb8d-4a86-0117-08d466d8990c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0802MB2473; x-microsoft-exchange-diagnostics: 1; HE1PR0802MB2473; 7:h/SPfLbr2qzyUZ1rufm39MPlZpFJjVqRImk+kXZ182OImSn5kYcv6H4pvZ1Yz0Pge1FQQG6ZzNBlIwuWhkEQpdpSmjNxctEnN4nkgbMVmeIpP3J+3dFfZqQx9LpwYXYcEAlbCXho1gM45PNbqrqZgt3ulpoHWszm5HKdYDMenE2f0ErewSNURZhHADHaG8VTIdbog1ml5Zc7Vk8Ij40NCX3F/N0Da4PtRTmSB0t/oa8IMiFEWCiW1QZg97+kFniZNBMDfg33/hnA9W36PD+9itO7nx48Kv97ne61y+q8p1ytjw7JVKj/X5hZYgKKXWE68I2y9k8lrxdZufkcdPwnVQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558025)(6072148); SRVR:HE1PR0802MB2473; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0802MB2473; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(53754006)(40434004)(7736002)(7696004)(5890100001)(305945005)(9686003)(122556002)(2900100001)(5660300001)(33656002)(50986999)(2351001)(230783001)(2501003)(6916009)(54356999)(3280700002)(8936002)(66066001)(74316002)(189998001)(6116002)(53936002)(102836003)(3846002)(5640700003)(8676002)(86362001)(6436002)(38730400002)(99286003)(110136004)(25786008)(77096006)(3660700001)(1730700003)(6506006)(55016002)(2906002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0802MB2473; H:HE1PR0802MB2475.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 10:39:43.1111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2473 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:39:48 -0000 Hi all, I just took a brief look at draft-kuehlewind-quic-applicability-00 and read= the following statement: "While there is no evidence of widespread, system= atic disadvantage of UDP traffic compared to TCP in the Internet [Edeline16= ], somewhere between three [Trammell16] and five [Swett16] percent of netwo= rks simply block UDP traffic." I wonder whether something can also be said about the use of UDP in enterpr= ise environments since we have run into problems with firewalls being more = aggressively configured to block UDP traffic, compared to TCP, in our IoT d= eployments with CoAP (which lead us to work on the CoAP over TCP spec). Furthermore, of the disadvantages of UDP over TCP is that NATs have shorter= timeouts for UDP-based protocols than for TCP-based protocols. Hence, you = need to send keep-alive messages more frequently. (At least according to th= is older study: Eggert, L., "An experimental study of home gateway characte= ristics", Proceedings of the 10th annual conference on Internet measurement= , 2010. Does the group see any problems with this, particularly when QUIC = is used in the mobile space? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu Mar 9 02:43:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF314129468 for ; Thu, 9 Mar 2017 02:43:34 -0800 (PST) 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, 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 T0WmjW6MGV-T for ; Thu, 9 Mar 2017 02:43:32 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AFA12945B for ; Thu, 9 Mar 2017 02:43:32 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4871C340548; Thu, 9 Mar 2017 11:43:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.30889); Thu, 9 Mar 2017 11:43:30 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 9 Mar 2017 11:43:30 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10909147; Thu, 09 Mar 2017 11:43:30 +0100 Subject: Re: Middlebox introspection/self-describing packets Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F7F4A36E-7DFE-4C88-8B65-4CA75205F2FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 9 Mar 2017 11:43:29 +0100 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:43:35 -0000 --Apple-Mail=_F7F4A36E-7DFE-4C88-8B65-4CA75205F2FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 09 Mar 2017, at 02:46, Eric Rescorla wrote: >=20 > On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell = wrote: >> hi ekr, >> Taking the case of Connection ID, specifically, it does seem to be a = candidate for moving to negotiation, saving one header bit pretty much = everywhere. Connection ID is designed for load balancers, and one could = define negotiation to be mandatory on the client side: if the server = gives you a connection ID, then the client MUST return it. Otherwise, = any device trying to observe the Connection ID would have to keep the = has-a-Connection-ID state observed during the negotiation, and it = wouldn't have access to that state when the Connection ID is used during = rebinding. >>=20 > To the extent to which the connection ID is (a) unique (b) long and = (c) in a predictable place when it is > present, it seems like it shouldn't be hard to look for it in that = place whether the bit is there or not. > In any case, what's the persuasive benefit for middleboxes to have = this information. Here "middleboxes" means "middleboxes other than load balancers" here, = correct? You could certainly encrypt this information, at the cost of = requiring the load balancer to be the server-side party to the TLS = session. To understate, I'm not sure that architecture is universally = applicable. >> In this case, saving the bit costs you the possibility of client-side = choice on whether to not return the Connection ID, which seems to me to = violate the mutual cooperation principle. >=20 > Well, with negotiation, someone has to decide. The bit just moves that = to the client. > Except that if the load balancer *needs* it, then the client has to = conform. The load balancer needs it to balance load efficiently. I presume that a = client that was very interested in not providing tracking information = could refuse to make Connection ID available, at the cost of degraded = performance. (f that's not the case, if failure to send connection ID = leads to connection failure, then "negotiation" is a euphemism: the = server informs the client whether it must send a connection ID, probably = encrypted, and nobody needs any flags, unless the presence of connection = ID changes the offsets of fields we *do* want to explicitly expose, such = as packet number echo (https://github.com/quicwg/base-drafts/issues/269) = or troubleshooting flags = (https://github.com/quicwg/base-drafts/issues/279). Cheers, Brian --Apple-Mail=_F7F4A36E-7DFE-4C88-8B65-4CA75205F2FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwTHRAAoJEIoSt78L6kajczUQAMbUU2SGMbyt8szLvNtfOwTl Mrg6dJtuC+Lf5AFK198BtU0isGG23hTtSWmh+YxatsGhKbyYkzYO5IGdNj6Dh9xy uwLiTb3okak+n1N6gqNad1GvFODam+jQ6xrd9yY83w9r/v7xght9pB8lQj8QO8cE c9lfKBFFY9Ia8uZ61O8c8THYp9sSkgLGX/LFtG9bBZdoayoCHcPfpgsCxPaHlLY8 qhgN/l8cLB1AjYNd3abytGjq9yUA5xldTalMvHMPQIDygSWUSQy8Ghm9q6EXne2U fsINwei+tgEU3WmMz92qShMCw8PAb1orLd7RHGQmNnJ6+dkjpvHd04rTP0QQrrPS YoW3VQz4u7a+rnA6nF5EA7IKLQsjfEwItD5Zm97MOP1h24TCoHT+PaUq94zeF3zh wiDywDb4A62pMdatmu9ec+bSM4ghIu6INmCIkiSGux96Q2gA2I0HMUQJIWXX2AJV QeVbD8Vd63QmitzjaByUfXnU962sitf0AJjcdHIllUmH1Qlk5b+O27dMSqZrpSBk +MvhwWjcByU2FZWtjvgab9yIC8X7j1+NrOl5P7br4DZNPcQS536FP/6yGl1myl2U u5ax/XmvC4QH3HfciTgYapwzGg0DSizG9qp0U0WzAS5Falqq9rCyur1IlGPSOGqR P2ummvEf8ULQN8VyttJp =QsBD -----END PGP SIGNATURE----- --Apple-Mail=_F7F4A36E-7DFE-4C88-8B65-4CA75205F2FE-- From nobody Thu Mar 9 02:50:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949A7129454 for ; Thu, 9 Mar 2017 02:50:22 -0800 (PST) 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, RP_MATCHES_RCVD=-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 Pv7sowKeUtkX for ; Thu, 9 Mar 2017 02:50:20 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F3A12943F for ; Thu, 9 Mar 2017 02:50:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vf6cB32LQzMmgq; Thu, 9 Mar 2017 11:50:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIGLRcdVJlEC; Thu, 9 Mar 2017 11:50:17 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 9 Mar 2017 11:50:17 +0100 (CET) Subject: Re: DISINTEREST frame To: Mike Bishop , "Lubashev, Igor" References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <8ed2217a-e65c-a24f-b192-796e553337f3@tik.ee.ethz.ch> Date: Thu, 9 Mar 2017 11:50:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:50:22 -0000 Okay, that's now a little bit a hack but after sending DISINTEREST you could just acknowledge all data up to the highest packet number you've seen, no matter if you received them or not because you don't need them anymore anynway; that would avoid any retransmissions... Mirja On 08.03.2017 18:53, Mike Bishop wrote: > You’re correct that the sender of DISINTEREST no longer cares about the data, > other than for flow control and state consistency. > > > > I had been trying to approach it from a principle that only the sender can > affect the stream state in their direction – the receiver can only request > changes. As the draft currently reads, the receiver counts flow control as > STREAM frames are received, and upon receipt of a RST_STREAM. If a STREAM > frame is delayed, it doesn’t (yet) count against the receiver’s flow control > window, even if it can infer that the data has been sent (by virtue of > receiving a later offset). Only upon receipt of a RST_STREAM do you account > all outstanding data against the flow control window. > > > > Changing it so that all data up to the furthest offset received on a stream > counts is certainly possible, but feels like an orthogonal change to this > PR. I’ve opened issue #370 for that. In that world, the requirement would > be to reliably deliver /either/ a RST_STREAM /or/ a STREAM frame with the FIN > bit set (basically, you MUST communicate your final offset). So long as one > of those gets through, DISINTEREST by itself could stop retransmissions. > That feels marginally more complicated, since it adds an additional path to > stop retransmission on a stream and makes the accounting logic on receipt of > a STREAM frame more complicated. > > > > My inclination is to leave retransmissions tied to having sent RST_STREAM, > but I’ll defer to others whether the complexity is worth the potential savings. > > > > *From:*Lubashev, Igor [mailto:ilubashe@akamai.com] > *Sent:* Wednesday, March 8, 2017 9:19 AM > *To:* Lubashev, Igor ; Ian Swett ; > Martin Thomson > *Cc:* Mike Bishop ; quic@ietf.org > *Subject:* RE: DISINTEREST frame > > > > P.S. > > The paragraph above states: > > > > * [STREAM frames received after sending DISINTEREST] will be discarded > > > > So I read it that the peer who send DISINTEREST will /not/ be waiting for > that data. That peer does not need any accounting for flow control either, > since he has already received the FIN (with the byte offset) and is already > in “half-closed (remote)†or “closed†state. > > > > > > *From:*Lubashev, Igor [mailto:ilubashe@akamai.com] > *Sent:* Wednesday, March 08, 2017 12:10 PM > *To:* Ian Swett >; Martin > Thomson > > *Cc:* Michael.Bishop@microsoft.com ; > quic@ietf.org > *Subject:* RE: DISINTEREST frame > > > > * you definitely need "RST_STREAM is sent unless all outstanding data has > been sent AND acknowledged.", otherwise the peer waits forever for data > that won't arrive. > > > > > > I guess this is the core of the question, which goes beyond the choice for > this rare condition. “It is reasonable to think that the peer who sent > DISINTEREST is still waiting for any data?†The whole point of DISINTEREST > is to indicate that “I am /not/ waiting for any more dataâ€. > > > > > > *From:*Ian Swett [mailto:ianswett@google.com] > *Sent:* Wednesday, March 08, 2017 9:51 AM > *To:* Martin Thomson > > *Cc:* Lubashev, Igor >; > Michael.Bishop@microsoft.com ; > quic@ietf.org > *Subject:* Re: DISINTEREST frame > > > > Martin's right, you definitely need "RST_STREAM is sent unless all > outstanding data has been sent AND acknowledged.", otherwise the peer waits > forever for data that won't arrive. > > > > Question: Why call it DISINTEREST, instead of REQUEST_RST? It wasn't obvious > to me what DISINTEREST was until I read further, whereas REQUEST_RST is > pretty obvious, assuming you know about RST_STREAM. > > > > On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson > wrote: > > On 8 March 2017 at 15:35, Lubashev, Igor > wrote: > > We are taking about a case when the sender of the stream is already in > > "half-closed (local)" (or "closed") and the receiver is already in > > "half-closed (remote)" (or "closed"). This RST_STREAM will not affect the > > state of the stream for any peer. The only information RST_STREAM contains > > now is "I will not transmit". But the peer already sent DISINTERESTED to > > indicate it does not care about retransmissions. > > Even after closing a stream, an endpoint needs to retransmit data. It > closes when it first sends the FIN. > > > From nobody Thu Mar 9 02:58:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0287112945B for ; Thu, 9 Mar 2017 02:57:59 -0800 (PST) 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, 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 hz-bdiZLii-d for ; Thu, 9 Mar 2017 02:57:57 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA1112943F for ; Thu, 9 Mar 2017 02:57:56 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A80D4340DBD; Thu, 9 Mar 2017 11:57:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.975); Thu, 9 Mar 2017 11:57:55 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 9 Mar 2017 11:57:55 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10911281; Thu, 09 Mar 2017 11:57:55 +0100 Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CD1B1737-689E-4DBB-BC39-7CCF4FBDD537"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 9 Mar 2017 11:57:54 +0100 Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:57:59 -0000 --Apple-Mail=_CD1B1737-689E-4DBB-BC39-7CCF4FBDD537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Hannes, > On 09 Mar 2017, at 11:39, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I just took a brief look at draft-kuehlewind-quic-applicability-00 and = read the following statement: "While there is no evidence of widespread, = systematic disadvantage of UDP traffic compared to TCP in the Internet = [Edeline16], somewhere between three [Trammell16] and five [Swett16] = percent of networks simply block UDP traffic." We could maybe be clearer here. The Edeline paper looks at differential = treatment: bandwidth capping (which we have anecdotal evidence for but = requires DoSing a network to find/confirm, and is therefore questionably = ethical from an active Internet measurement standpoint) or latency = disadvantage. I guess you could call "my access network won't let me use = non-DNS UDP" a "systematic disadvantage". > I wonder whether something can also be said about the use of UDP in = enterprise environments since we have run into problems with firewalls = being more aggressively configured to block UDP traffic, compared to = TCP, in our IoT deployments with CoAP (which lead us to work on the CoAP = over TCP spec). Enterprise networks and access networks in highly challenged = environments (i.e., all you get is DNS to a local resolver and = proxied-caching no-S HTTP) is where those three to five percent come = from. > Furthermore, of the disadvantages of UDP over TCP is that NATs have = shorter timeouts for UDP-based protocols than for TCP-based protocols. = Hence, you need to send keep-alive messages more frequently. (At least = according to this older study: Eggert, L., "An experimental study of = home gateway characteristics", Proceedings of the 10th annual conference = on Internet measurement , 2010. Does the group see any problems with = this, particularly when QUIC is used in the mobile space? I thought we'd covered that here (indeed, that study and its = implications have been discussed on this list). If not, we should = mention the effects of shorter UDP timeouts in this draft, yes. Thanks, cheers, Brian > Ciao > Hannes >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 --Apple-Mail=_CD1B1737-689E-4DBB-BC39-7CCF4FBDD537 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwTUzAAoJEIoSt78L6kajeOMQAMZbZwEfYdskT/wpsSUs8BaV o2yjyezwIztQrlSu1OlguBZQw2BZqikclrx3x19lesi3/yxbYjsGojUyiPymRMin yqmcGiMfp+MFGhSUA0oKJA+pT/RzbMX49NFA+fBk08+lfMuyeudknBNapDsKGeiN mYtbSscig8djoEcpH/D92VnfmqS6+W9xq6QKy9XpcJ6+lITtdhPJRLPLAuk+uvDf BQx7O7MAzDy9AX1+YMAo0qtRmhb5BL5dnl81szlzWeGrj1XvgdnlGLkyvtbHnl6u 3D2VbNMf21FZmYQ3CWhknxiRq/mgJ9dSOtwX6UaplmLQJ00XHvLVYUjtnpfRNpyk BDMZHA26XwtCno570nLTJ0BKl2fsKFPKHHqZdWNE7seNZYWuf+sEI0ZTBbr5Ov6s lVANi8lObG/7nM6hvsTjoZvIyRUJtu4RbtO/P/4ADtUnQQ0R/uu6jONlyHNajiPC FVdOMP1qO89wFIqvN46WmSO77r86a/2OteB0H78FPaKHyO3efb0upoAipAbMtTMK idplWdWJvdT0gg31IiltioSdl38uJaOpI+YLqgEjApOEsYB7rnsI5NGe77xtEFWM OuFNDOAmUP9ps55NJkDTewKfrqTsKIoVOW2YMzIqtdvv0nJn+HjAvFUkie26NTK/ wep217GB9swz3CoEHdyo =VHaw -----END PGP SIGNATURE----- --Apple-Mail=_CD1B1737-689E-4DBB-BC39-7CCF4FBDD537-- From nobody Thu Mar 9 03:01:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E168C129466 for ; Thu, 9 Mar 2017 03:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 yzy5h-0hHx1h for ; Thu, 9 Mar 2017 03:01:51 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0053.outbound.protection.outlook.com [104.47.1.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0CB7127071 for ; Thu, 9 Mar 2017 03:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q5vTNSDyTviD92sFYyBSSBlwejwNFt99TG/SfII+Mag=; b=oc/oEV6mNUzFnO9xqbmeFyaTs5R4nHa98FTSlwkgCtSb0eeSdcWycfZr2fQIrXYLKnNoA8rVwh4cevkD6U2Filg/8i4CgCHOIcqD63HriYyBSKCdtcc19PxnTSrzZVUh89daQGYGepl5yq8Z3FjQdKBExJbjaCAW62bPPEsemik= Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) by HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 11:01:48 +0000 Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) by HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 11:01:48 +0000 From: Hannes Tschofenig To: "Brian Trammell (IETF)" Subject: RE: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Topic: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Index: AdKYwCv+WlyzFqftRk6FS9cmOv7E4QAA9S0AAAAI+ZA= Date: Thu, 9 Mar 2017 11:01:47 +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: trammell.ch; dkim=none (message not signed) header.d=none;trammell.ch; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.114.23] x-ms-office365-filtering-correlation-id: 519e01d4-813d-49f7-1c7d-08d466dbaebc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0802MB2475; x-microsoft-exchange-diagnostics: 1; HE1PR0802MB2475; 7:9eIgzWzfbTjcnkf0LprwwJkuH6tsBh8QK0Ccp6Dgs5470JTBxZVMiK1HeaCaT0MrJxpI7Pz2u56X/C8TvdPwlia3+J843GwH681uyPFxsYjxiD/9Ggr41+b2cC2pBGVj0zbotHGVjU2lVxbsNzbP1hs/AKNgpJiklyC53OZctL4IljS3GIHfWhOyRdcKZtUov27WcjfILVdb9DfLbL8v7BMKUa+1JIzLCcNxpvLXpzrBYBOf07Z4/5ulrNVUZY2DgOUhsYVopDMvFk7W9pu7w+fXbk1koPHlSoQvHxkHpK+X/steJYjytf888TEL8qmnvvhISo0y1HCMq0mbVDwFOw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:HE1PR0802MB2475; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0802MB2475; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39410400002)(39840400002)(39450400003)(39850400002)(40434004)(110136004)(53936002)(81166006)(4326008)(6116002)(38730400002)(230783001)(102836003)(122556002)(2950100002)(86362001)(6246003)(6916009)(8676002)(7696004)(5660300001)(8936002)(54356999)(7736002)(3846002)(3280700002)(33656002)(3660700001)(5890100001)(229853002)(74316002)(66066001)(2906002)(50986999)(77096006)(99286003)(6506006)(6436002)(2900100001)(25786008)(76176999)(55016002)(9686003)(189998001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0802MB2475; H:HE1PR0802MB2475.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 11:01:47.5642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2475 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:01:53 -0000 Hi Brian, Thanks for the quic (!) response. > I just took a brief look at draft-kuehlewind-quic-applicability-00 and re= ad the following statement: "While there is no evidence of widespread, syst= ematic disadvantage of UDP traffic compared to TCP in the Internet [Edeline= 16], somewhere between three [Trammell16] and five [Swett16] percent of net= works simply block UDP traffic." We could maybe be clearer here. The Edeline paper looks at differential tre= atment: bandwidth capping (which we have anecdotal evidence for but require= s DoSing a network to find/confirm, and is therefore questionably ethical f= rom an active Internet measurement standpoint) or latency disadvantage. I g= uess you could call "my access network won't let me use non-DNS UDP" a "sys= tematic disadvantage". [Hannes] I have tried to find the paper but I failed. > I wonder whether something can also be said about the use of UDP in enter= prise environments since we have run into problems with firewalls being mor= e aggressively configured to block UDP traffic, compared to TCP, in our IoT= deployments with CoAP (which lead us to work on the CoAP over TCP spec). Enterprise networks and access networks in highly challenged environments (= i.e., all you get is DNS to a local resolver and proxied-caching no-S HTTP)= is where those three to five percent come from. [Hannes] Where do I find the details of this investigation? > Furthermore, of the disadvantages of UDP over TCP is that NATs have short= er timeouts for UDP-based protocols than for TCP-based protocols. Hence, yo= u need to send keep-alive messages more frequently. (At least according to = this older study: Eggert, L., "An experimental study of home gateway charac= teristics", Proceedings of the 10th annual conference on Internet measureme= nt , 2010. Does the group see any problems with this, particularly when QUI= C is used in the mobile space? I thought we'd covered that here (indeed, that study and its implications h= ave been discussed on this list). If not, we should mention the effects of = shorter UDP timeouts in this draft, yes. [Hannes] It would be great if the research community could re-do the story = since it is already getting a bit old. ~6 years is a long time in the Inter= net age. Ciao Hannes Thanks, cheers, Brian > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Thu Mar 9 03:22:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA2129532 for ; Thu, 9 Mar 2017 03:22:04 -0800 (PST) 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, 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 WvKk6Inst7MB for ; Thu, 9 Mar 2017 03:22:03 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F078E12950A for ; Thu, 9 Mar 2017 03:22:02 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9317B340A3D; Thu, 9 Mar 2017 12:22:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.6226); Thu, 9 Mar 2017 12:22:01 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 9 Mar 2017 12:22:01 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10914719; Thu, 09 Mar 2017 12:22:01 +0100 Subject: Re: Middlebox introspection/self-describing packets Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DA938C34-3073-4F04-BCA9-68D864DA35DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell (IETF) In-Reply-To: Date: Thu, 9 Mar 2017 12:22:00 +0100 Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:22:04 -0000 --Apple-Mail=_DA938C34-3073-4F04-BCA9-68D864DA35DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, There is a long and storied history of work on traffic analysis that = squeezes bits of entropy from wherever they leak. While reducing = information exposure makes analyses of this class harder, at the end of = the day any defense bumps up against size (bandwidth efficiency) and = timing (latency). In a world where latency and bandwidth efficiency are = important -- and I do think we still live in that world, otherwise 0-RTT = goes away and draft-ietf-quic-tls gets way simpler -- protecting against = traffic analysis is always more difficult than finding another way to = fingerprint. Given this history -- my favorite timing/sizing analysis paper [1], = which recovers content identification from NetFlow data with anonymized = addresses, is ten years old now -- I'm somewhat skeptical of claims = about the power of a particular form of redaction against generalized = traffic analysis. Obviously, there is a place for allowing users to = choose to trade off bandwidth efficiency and latency for privacy -- Tor = exists, and it works, for example -- but I'm not sure we want to go down = the rabbithole of trying to add analysis resistance to QUIC in the = general case. Cheers, Brian [1]: = https://www.usenix.org/legacy/event/sec07/tech/full_papers/coull/coull_htm= l/main.html > On 09 Mar 2017, at 01:23, Martin Thomson = wrote: >=20 > Found it! >=20 > = https://www.blackhat.com/docs/us-16/materials/us-16-VanGoethem-HEIST-HTTP-= Encrypted-Information-Can-Be-Stolen-Through-TCP-Windows-wp.pdf >=20 > I don't know what is worse, that these have naff names, or that I > forget them so quickly. Added to #279. >=20 > On 9 March 2017 at 11:13, Martin Thomson = wrote: >> On 9 March 2017 at 11:09, Martin Duke = wrote: >>> The proposal in #279 is nothing like fully-baked, but it's a bit = indicating >>> that the receiver is advertising zero-window, not indicating how big = the >>> window ever was. It might even be ambiguous about stream vs. = connection flow >>> control. >>>=20 >>> I can't remember if we're sending an initial window in the clear or = not, and >>> this is worth thinking about, but it's not clear to me that's an = issue. >>=20 >> It's very definitely an issue. Being able to observe when the flow >> control window hits zero was used in the attack (the one I can't >> find). >=20 --Apple-Mail=_DA938C34-3073-4F04-BCA9-68D864DA35DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwTrYAAoJEIoSt78L6kajvAIQAJ6/7zckglzW8D9OtIZLKSqq rE+ypQmKMLGVkO95dYXnqKE2MNJ1I6++fDzxIbZ0IdEsa8lvHuEwvOePmRzBwWVJ 9pFbAV921T0izt88uNja506Yj/9sfWuGt1IrcE/BBgYAzbTYNYUqxnrVLlq5lkUZ n4XmbGI8tGOhOEHWkPFfdrM7BO7Yq20X/PkVxbev+ksw23D7H0VIHihfZbmxgMA0 SrY2tVkxw8sGvdp2vh4juW5AwPJcv9iySdjjG8COu5uDoQ1p9a7SKWgTAWAJfjX1 Ayj0cTlnxE3LUY64FTayAfGe9Uh0I0/6/9zGmGkbqmCtw0sszNUM/OP+Y1yTqcdW ft1bYJ9i5VXFjMaefV7jC1RhCxyynxG3iUb89rZMIP3yFGWpORt29t6+aZtdiLKG x9LIyeF9HINUzklOZGaSMtPkHOUY0I4noIzs2UPAGLOzGR+ApuRxveidum0/0DRQ imMV9q65pny3AFhSzvbhHlKids0vC5mFAjEx6LnZtcuT4siThODT3hKiPDFxB5/D 1IkIcesMPmqeZfsOfMQ0a/5iYMG1DtsCPXJViAo0Q59fahgeICbo9iVH0AjshsIg LVfc3RV/SWKwRExwtoLhzF33aDYiLHTyOc6Gq6tDEVhTx9DUxRhPPOUbm9RFHGn4 zoPGejWCx2wWofjsrlSs =9eln -----END PGP SIGNATURE----- --Apple-Mail=_DA938C34-3073-4F04-BCA9-68D864DA35DA-- From nobody Thu Mar 9 03:23:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B76129517 for ; Thu, 9 Mar 2017 03:23:16 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2ENzvxRgSW9f for ; Thu, 9 Mar 2017 03:23:15 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2D712950A for ; Thu, 9 Mar 2017 03:23:15 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id p77so6352758ywg.1 for ; Thu, 09 Mar 2017 03:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hXqANypFBI0/tUlc1LKRg8KgBKjQ5dzIS4PATClw5uc=; b=Xt9HhZw563g8f+ddDzk1MS+Y1F5T+dNeWVRljG73y92G6aNLrNdQ+rP0sXf5z/r4CU c+AooLoQ4Bgnw+cM1xzOW3qAlnyPOM+j4Fb3x/5Ok+YwCbQpAAKRUaNCRN8/mwbTscai 0RaFZy2lS1ipkwCOxLFj/FDeT4jVHTjvzmwr58ChLk6G6yxXYP5UiLMjCUVcx0BCcrTc 2il68grf3pFyCZRB3CMVMTMQHsVHjqAz6HOXkanRfBLE/Z7/aMbgVed+irH7NyzYnGWf GFeWFT+1rVTmkryLMvHPDDUs33Io9gnHUDhRRHmmrJNY9jp2EwvjVr+mVfL2yow/abHj Brzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hXqANypFBI0/tUlc1LKRg8KgBKjQ5dzIS4PATClw5uc=; b=oVKgCjbJWP94OOlSBcfkM+sGCq77IYjtyBbpCxD7jEhqejz4PHrucfDNoeHWTJumlz wLAPBA0ymb2ORSiduqDUnSrJmsNYG+XIXNOxEGIt+1il7/zQMElhm9undKKgbYtyVX+a 0GF3pDTwpeDHcaOAuZwQhx4IFC0rBmycxShCJOOe7zJY5sjc45aZ55Zabxd7uHZvSkL1 UhE2Xkvv7QXwYe1CVT9zmfNwg7dipCMIEL/9P/JtisulHNYWhfizAUxUZPQ/avRzIcb5 kqNfjuR2C7fxl0/yG7GzGzwNWqktF5q89gxO8YEgyFQUVgWsZ+zMJkaaQU1Vt+aZ8j9f JVJA== X-Gm-Message-State: AMke39nmwARMDGZKkLrGuih/uDK/dDjYzASv9IYjT+AhY8+E0VgJ+fdxr55bKsuoF+MkV8lOIQgsb6dSkgrM3ONX X-Received: by 10.129.124.84 with SMTP id x81mr3227735ywc.271.1489058594079; Thu, 09 Mar 2017 03:23:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.207.4 with HTTP; Thu, 9 Mar 2017 03:22:53 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Thu, 9 Mar 2017 20:22:53 +0900 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1149416897a99e054a4a7899" Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:23:17 -0000 --001a1149416897a99e054a4a7899 Content-Type: multipart/alternative; boundary=001a114941688d5220054a4a78de --001a114941688d5220054a4a78de Content-Type: text/plain; charset=UTF-8 My 2 yen. First, I would personally classify middleboxes as any element on the path between two communicating endpoints that are not administered by an entity that administers one of the endpoints. To take the case with which I am most familiar: my mobile phone is one endpoint, the mobile operator's devices are middleboxes as are all others at least until my packets enter the network of the endpoint with which I'm communicating. In the remote network, if I'm talking to, say, another mobile device then the remote mobile network operator's devices are still middleboxes. If on the other hand I'm talking to a monolithic service composed of several elements, then those firewalls, load balancers, and so forth I would not classify as middleboxes. I would offer up a better term for this latter category of devices, but I do not yet have one (they are kind of auxiliary/colleague/cooperating boxes). I think the distinction is important because middleboxes as I've tried to define them cannot be presumed to be acting in the best interest of the communicating parties. All other boxes might be "fixed" to work well with QUIC. Whether the "fixing" necessitates exposing protocol information to middleboxes as defined above is, I think, something to be considered on a function-by-function basis. Second, I feel very strongly that whatever is exposed to middleboxes should not be easily abused (even by accident) in such a way as to prevent seamless connection migration. With a new transport like QUIC there's a wonderful opportunity to get this right, and if we fail we won't get to try again for many many years I fear. --001a114941688d5220054a4a78de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My 2 yen.

First, I would personally cla= ssify middleboxes as any element on the path between two communicating endp= oints that are not administered by an entity that administers one of the en= dpoints.

To take the case with which I am most fam= iliar: my mobile phone is one endpoint, the mobile operator's devices a= re middleboxes as are all others at least until my packets enter the networ= k of the endpoint with which I'm communicating.=C2=A0 In the remote net= work, if I'm talking to, say, another mobile device then the remote mob= ile network operator's devices are still middleboxes.=C2=A0 If on the o= ther hand I'm talking to a monolithic service composed of several eleme= nts, then those firewalls, load balancers, and so forth I would not classif= y as middleboxes.=C2=A0 I would offer up a better term for this latter cate= gory of devices, but I do not yet have one (they are kind of auxiliary/coll= eague/cooperating boxes).

I think the distinction = is important because middleboxes as I've tried to define them cannot be= presumed to be acting in the best interest of the communicating parties.= =C2=A0 All other boxes might be "fixed" to work well with QUIC.= =C2=A0 Whether the "fixing" necessitates exposing protocol inform= ation to middleboxes as defined above is, I think, something to be consider= ed on a function-by-function basis.

Second, I feel= very strongly that whatever is exposed to middleboxes should not be easily= abused (even by accident) in such a way as to prevent seamless connection = migration.=C2=A0 With a new transport like QUIC there's a wonderful opp= ortunity to get this right, and if we fail we won't get to try again fo= r many many years I fear.
--001a114941688d5220054a4a78de-- --001a1149416897a99e054a4a7899 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgN+PnL3Rxj7/fZGGz1MZ7Iz+1dZrea9kM S5bopCx4JRYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMzA5 MTEyMzE0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAKrXx4B3IcVUeSM/H/P/F/oJz1qyx2rUDnZpZ/gODYpZnwrG8VJL 3X4sJTMbyuHDL2ZOq1GrNEKK+BIZaO0j6jNDKCIyZ0AhaWZocSJIkTVg9o2tKsKwpQXJNKrjmEtM JHVo1kSSOGT+mLHJrHZ96cspEeKxIfNLRSNm13RQ5hWrnsPewjSfyflTXZdVuUKNJighTrKv7Uwd IY8jFvMrUi9RoRqLAJvbd1AMds3Vkllw4bMj2OmcWXOUHFoDUgUuIro+FJsRG7TI7ut7uberW3I/ 9TA6mS47K2w2fUbRJcGpGrVXKGRdOZ/4heLSbCDTNQWzsglc5ZnxJqWEWnVLfTM= --001a1149416897a99e054a4a7899-- From nobody Thu Mar 9 03:31:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87820129537 for ; Thu, 9 Mar 2017 03:31:01 -0800 (PST) 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, 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 DcGFPee0D029 for ; Thu, 9 Mar 2017 03:30:59 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A30C129532 for ; Thu, 9 Mar 2017 03:30:59 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 06F8C3404F3; Thu, 9 Mar 2017 12:30:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.6624); Thu, 9 Mar 2017 12:30:57 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 9 Mar 2017 12:30:57 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10915756; Thu, 09 Mar 2017 12:30:57 +0100 Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E6EE6C1D-9853-493A-B570-40C17DEEC9EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 9 Mar 2017 12:30:57 +0100 Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:31:01 -0000 --Apple-Mail=_E6EE6C1D-9853-493A-B570-40C17DEEC9EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 09 Mar 2017, at 12:01, Hannes Tschofenig = wrote: >=20 > Hi Brian, >=20 > Thanks for the quic (!) response. >=20 >> I just took a brief look at draft-kuehlewind-quic-applicability-00 = and read the following statement: "While there is no evidence of = widespread, systematic disadvantage of UDP traffic compared to TCP in = the Internet [Edeline16], somewhere between three [Trammell16] and five = [Swett16] percent of networks simply block UDP traffic." >=20 > We could maybe be clearer here. The Edeline paper looks at = differential treatment: bandwidth capping (which we have anecdotal = evidence for but requires DoSing a network to find/confirm, and is = therefore questionably ethical from an active Internet measurement = standpoint) or latency disadvantage. I guess you could call "my access = network won't let me use non-DNS UDP" a "systematic disadvantage". >=20 > [Hannes] I have tried to find the paper but I failed. >=20 >> I wonder whether something can also be said about the use of UDP in = enterprise environments since we have run into problems with firewalls = being more aggressively configured to block UDP traffic, compared to = TCP, in our IoT deployments with CoAP (which lead us to work on the CoAP = over TCP spec). >=20 > Enterprise networks and access networks in highly challenged = environments (i.e., all you get is DNS to a local resolver and = proxied-caching no-S HTTP) is where those three to five percent come = from. >=20 > [Hannes] Where do I find the details of this investigation? Ian gave a talk (at MAPRG, I think). The Edeline paper is in arXiv, = https://arxiv.org/pdf/1612.07816.pdf -- papers that painstakingly = measure something most people think is obvious are hard to publish = academically. >> Furthermore, of the disadvantages of UDP over TCP is that NATs have = shorter timeouts for UDP-based protocols than for TCP-based protocols. = Hence, you need to send keep-alive messages more frequently. (At least = according to this older study: Eggert, L., "An experimental study of = home gateway characteristics", Proceedings of the 10th annual conference = on Internet measurement , 2010. Does the group see any problems with = this, particularly when QUIC is used in the mobile space? >=20 > I thought we'd covered that here (indeed, that study and its = implications have been discussed on this list). If not, we should = mention the effects of shorter UDP timeouts in this draft, yes. >=20 > [Hannes] It would be great if the research community could re-do the = story since it is already getting a bit old. ~6 years is a long time in = the Internet age. Basic network handling on CPE is a pretty mature market though. Throwing = a student at this (on someone else's menagerie) is on my list of stuff = to do someday, though. >=20 > Ciao > Hannes >=20 >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 >> Ciao >> Hannes >>=20 >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >>=20 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 --Apple-Mail=_E6EE6C1D-9853-493A-B570-40C17DEEC9EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwTzxAAoJEIoSt78L6kajOQQP/1/eHl8MfYQ0przMvQhn65H2 ESi50Q8PxjmeS7638MFfYJmf2olk8sUhWNCsAemsLoWnMY1tDN8vcNWX/nhFWRnP F2PJRD3i55X10jBhirjoEn3TGgHBqMwGNPIkXsQgJcsQp0oQKljyTA9GXpZzLn0u rZFQoJvD+TQtXD4sAGdxmBk+KquqF7os+xnacU33tAuLUbt8U40dvQ5HaCeHFOA8 MNPYYRkcxpN2UrDOHx/KNspbCShaag+FmvHhY+RUl3vlym8tAP4DwO1KnAToL2/r 4tRfkirrRSQOSy0iO0AQhvzoEJw6G5O00n+LR063MNADwWG6xJHphJ524rwFhPOp Gtv6SY278VDVoYqiqZ73gYN69+0friWeHrUIiSX+zjcAyHjQpJPVeXkPNP7/vbvf OOB8EQAFp9ZgoZ84TwgDM/lD6v/9st6BHl+JE5eyz0aBxOVloNTNg4ZSgO96QEcp hwo9r35ozJlAOPoXXyVDZ3by/8TLfYGgwFJhVGY/dtSE30qnJAKZpwAcQ/0fyzQ8 B33FHfIkqMTZQ9he5AA7lN/OfO2E9yb9snrF16QoenjAYfiJkeuuFCWugixnzJ5N K/dfA4zw5CkfOTzx6Sx2YdpEalWiEbk+xjN5S8Oeiks3jsNwtQyKNIlE3EaPTr59 qcNoPJfMig+RhirvLUy/ =g47T -----END PGP SIGNATURE----- --Apple-Mail=_E6EE6C1D-9853-493A-B570-40C17DEEC9EA-- From nobody Thu Mar 9 04:35:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88255129572 for ; Thu, 9 Mar 2017 04:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg60AQfbJsRX for ; Thu, 9 Mar 2017 04:35:01 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 C6900129458 for ; Thu, 9 Mar 2017 04:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489062481; l=2216; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=NbiqP9d3WZreKzcL2bw93U2VIkLXSDy35PmNZx8gyN4=; b=aI98l6isMovYwNKqye4re8V6cvbeAqXDcpHmL2uWm3sAwPPdHv0LhlXORMrDbs/DNI 2ew6yMpV2/fKn0h/PuKs7Zoye6fjuwUt9ziWt5qnhu7cZvLe2+bgsiysba3UsgElwX8h boYMSIxLVfF1JhkaIg87R2Mpm/qi99t79ZXzE= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyCBKUXHiiJD900p0TuPJc3Hp+vSQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:3d34:f546:88b2:b6b8] ([2001:4dd0:ff67:0:3d34:f546:88b2:b6b8]) by smtp.strato.de (RZmta 40.1 AUTH) with ESMTPSA id K063d9t29CS01Wl (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 9 Mar 2017 13:28:00 +0100 (CET) Subject: Re: Middlebox introspection/self-describing packets To: quic@ietf.org References: From: Roland Zink Message-ID: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> Date: Thu, 9 Mar 2017 13:28:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:35:02 -0000 My 2 cents. Neither the middleboxes nor the auxiliary boxes especially not the other endpoint(s) can be trusted to work in the end users interest. Even my own endpoints can't be trusted as vault 7 seems to proof (https://wikileaks.org/ciav7p1/). Do I now need to intercept all connections from my TV? QUIC has the potential to spam the network from user space code. The network should be able to detect misuse as fast as possible. Roland Am 09.03.2017 um 12:22 schrieb Erik Kline: > My 2 yen. > > First, I would personally classify middleboxes as any element on the > path between two communicating endpoints that are not administered by > an entity that administers one of the endpoints. > > To take the case with which I am most familiar: my mobile phone is one > endpoint, the mobile operator's devices are middleboxes as are all > others at least until my packets enter the network of the endpoint > with which I'm communicating. In the remote network, if I'm talking > to, say, another mobile device then the remote mobile network > operator's devices are still middleboxes. If on the other hand I'm > talking to a monolithic service composed of several elements, then > those firewalls, load balancers, and so forth I would not classify as > middleboxes. I would offer up a better term for this latter category > of devices, but I do not yet have one (they are kind of > auxiliary/colleague/cooperating boxes). > > I think the distinction is important because middleboxes as I've tried > to define them cannot be presumed to be acting in the best interest of > the communicating parties. All other boxes might be "fixed" to work > well with QUIC. Whether the "fixing" necessitates exposing protocol > information to middleboxes as defined above is, I think, something to > be considered on a function-by-function basis. > > Second, I feel very strongly that whatever is exposed to middleboxes > should not be easily abused (even by accident) in such a way as to > prevent seamless connection migration. With a new transport like QUIC > there's a wonderful opportunity to get this right, and if we fail we > won't get to try again for many many years I fear. From nobody Thu Mar 9 04:41:33 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9A1129438 for ; Thu, 9 Mar 2017 04:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 u8BierCrjYle for ; Thu, 9 Mar 2017 04:41:27 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B331295D8 for ; Thu, 9 Mar 2017 04:41:26 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id o4so7064990ywd.3 for ; Thu, 09 Mar 2017 04:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qg1XeRDstKYIxRIlO9hxnfamALx76fer/BKTBDcJ/Vw=; b=Ma80ZDFiphag4m2nLb5sZBDgjcxMikHBPB8Bfbim0p+H2KkSgn6AfMdo8LStiZYywq C5Ut4u6kVG/i4sAtXKX29krPsjzKOZIAx9YHKuzZRiVK0DEVu9cHvZXWwocJtGjePw8f aa0BGAw6BtIRdb/3sGjpAdkegRovLvonrzeZTxfF9tb/Zv+u+xjeo1tIOBXpCRv9L9lo rMo77801RRbnjLNusA4Qlzw1YfP/7KpXvSvgH/q6grNc+/MLH0+ldBgVN9p/ESdxtIFS 9USR0c1A3FH8OD/tMIQYHJZ/d0ZwfFzjCndA5M6Tf3jjfuORmr4U1wvHediOp68bHHvz V3qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qg1XeRDstKYIxRIlO9hxnfamALx76fer/BKTBDcJ/Vw=; b=qFGIlb+xQavF2oKgngLvTifAKimeN+HihKF4btFqHkX3JbV6jwOAqiWrjvV33HuneL xL/8oi9KTe8zX9t2iTuKSINwiv95Nf/W3TkJ8EfUzv9MjdgdiDeyzKoMUOxagUgAykSY CcQkj4ofDDKrmxfObS3yQBM+ij4FanttGZDSg87Qp5MzKGhW3CRPbgVZdzkI0nRfBvmm 5NIyrRpM8E3zN3KHsSg2yrWqlz8HlS4+lDR9n9UcsPb/S6DLvKMINj5ApvPWEIMmu5lk QtMtBQQCBFU+cxudmVYezMnkWDjrHWNVUkFizQQYz0MFF4J4c07f179zCavMBAPT+gPg XZ9w== X-Gm-Message-State: AMke39n7RC1eW3gmaorFxlZv5WR4sJfPxWGe6X4YnSavpZ3r7YXmmu5UR5l3d0dYIYlvLog8yXGVfetemfmKoSe8 X-Received: by 10.13.254.66 with SMTP id o63mr3624994ywf.318.1489063285735; Thu, 09 Mar 2017 04:41:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 04:41:05 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Mar 2017 07:41:05 -0500 Message-ID: Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 To: "Brian Trammell (IETF)" Content-Type: multipart/alternative; boundary=94eb2c080010322f0e054a4b90f3 Archived-At: Cc: Hannes Tschofenig , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:41:31 -0000 --94eb2c080010322f0e054a4b90f3 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 6:30 AM, Brian Trammell (IETF) wrote: > > > On 09 Mar 2017, at 12:01, Hannes Tschofenig > wrote: > > > > Hi Brian, > > > > Thanks for the quic (!) response. > > > >> I just took a brief look at draft-kuehlewind-quic-applicability-00 and > read the following statement: "While there is no evidence of widespread, > systematic disadvantage of UDP traffic compared to TCP in the Internet > [Edeline16], somewhere between three [Trammell16] and five [Swett16] > percent of networks simply block UDP traffic." > > > > We could maybe be clearer here. The Edeline paper looks at differential > treatment: bandwidth capping (which we have anecdotal evidence for but > requires DoSing a network to find/confirm, and is therefore questionably > ethical from an active Internet measurement standpoint) or latency > disadvantage. I guess you could call "my access network won't let me use > non-DNS UDP" a "systematic disadvantage". > > > > [Hannes] I have tried to find the paper but I failed. > > > >> I wonder whether something can also be said about the use of UDP in > enterprise environments since we have run into problems with firewalls > being more aggressively configured to block UDP traffic, compared to TCP, > in our IoT deployments with CoAP (which lead us to work on the CoAP over > TCP spec). > > > > Enterprise networks and access networks in highly challenged > environments (i.e., all you get is DNS to a local resolver and > proxied-caching no-S HTTP) is where those three to five percent come from. > > > > [Hannes] Where do I find the details of this investigation? > > Ian gave a talk (at MAPRG, I think). The Edeline paper is in arXiv, > https://arxiv.org/pdf/1612.07816.pdf -- papers that painstakingly measure > something most people think is obvious are hard to publish academically. > Yes, my talk was in Berlin 2016 at TSV Open( https://datatracker.ietf.org/meeting/96/agenda/tsvarea/). I sent Mirja a PDF copy of the slides, but I'm not sure where they are posted. To second what Brian said, most 'networks' which block QUIC are corporations that are large enough to have their own AS number. I've never found a major ISP that blocks UDP 443. > > >> Furthermore, of the disadvantages of UDP over TCP is that NATs have > shorter timeouts for UDP-based protocols than for TCP-based protocols. > Hence, you need to send keep-alive messages more frequently. (At least > according to this older study: Eggert, L., "An experimental study of home > gateway characteristics", Proceedings of the 10th annual conference on > Internet measurement , 2010. Does the group see any problems with this, > particularly when QUIC is used in the mobile space? > > > > I thought we'd covered that here (indeed, that study and its > implications have been discussed on this list). If not, we should mention > the effects of shorter UDP timeouts in this draft, yes. > > > > [Hannes] It would be great if the research community could re-do the > story since it is already getting a bit old. ~6 years is a long time in the > Internet age. > > Basic network handling on CPE is a pretty mature market though. Throwing a > student at this (on someone else's menagerie) is on my list of stuff to do > someday, though. > > > > > > Ciao > > Hannes > > > > > > Thanks, cheers, > > > > Brian > > > > > >> Ciao > >> Hannes > >> > >> IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > >> > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > > > --94eb2c080010322f0e054a4b90f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 6:30 AM, Brian Trammell (IETF) <ietf@trammell.ch>= wrote:

> On 09 Mar 2017, at 12:01, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
>
> Hi Brian,
>
> Thanks for the quic (!) response.
>
>> I just took a brief look at draft-kuehlewind-quic-applicabili= ty-00 and read the following statement: "While there is no evidence of= widespread, systematic disadvantage of UDP traffic compared to TCP in the = Internet [Edeline16], somewhere between three [Trammell16] and five [Swett1= 6] percent of networks simply block UDP traffic."
>
> We could maybe be clearer here. The Edeline paper looks at differentia= l treatment: bandwidth capping (which we have anecdotal evidence for but re= quires DoSing a network to find/confirm, and is therefore questionably ethi= cal from an active Internet measurement standpoint) or latency disadvantage= . I guess you could call "my access network won't let me use non-D= NS UDP" a "systematic disadvantage".
>
> [Hannes] I have tried to find the paper but I failed.
>
>> I wonder whether something can also be said about the use of UDP i= n enterprise environments since we have run into problems with firewalls be= ing more aggressively configured to block UDP traffic, compared to TCP, in = our IoT deployments with CoAP (which lead us to work on the CoAP over TCP s= pec).
>
> Enterprise networks and access networks in highly challenged environme= nts (i.e., all you get is DNS to a local resolver and proxied-caching no-S = HTTP) is where those three to five percent come from.
>
> [Hannes] Where do I find the details of this investigation?

Ian gave a talk (at MAPRG, I think). The Edeline paper is in arXiv, = https://arxiv.org/pdf/1612.07816.pdf -- papers that pa= instakingly measure something most people think is obvious are hard to publ= ish academically.

Yes, my talk was in B= erlin 2016 at TSV Open(https://datatracker.ietf.org/meeting/96/agenda/tsvarea/= ).=C2=A0 I sent Mirja a PDF copy of the slides, but I'm not sure where = they are posted.

To second what Brian said, most &= #39;networks' which block QUIC are corporations that are large enough t= o have their own AS number.=C2=A0 I've never found a major ISP that blo= cks UDP 443.
=C2=A0

>> Furthermore, of the disadvantages of UDP over TCP is that NATs hav= e shorter timeouts for UDP-based protocols than for TCP-based protocols. He= nce, you need to send keep-alive messages more frequently. (At least accord= ing to this older study: Eggert, L., "An experimental study of home ga= teway characteristics", Proceedings of the 10th annual conference on I= nternet measurement , 2010. Does the group see any problems with this, part= icularly when QUIC is used in the mobile space?
>
> I thought we'd covered that here (indeed, that study and its impli= cations have been discussed on this list). If not, we should mention the ef= fects of shorter UDP timeouts in this draft, yes.
>
> [Hannes] It would be great if the research community could re-do the s= tory since it is already getting a bit old. ~6 years is a long time in the = Internet age.

Basic network handling on CPE is a pretty mature market though. Thro= wing a student at this (on someone else's menagerie) is on my list of s= tuff to do someday, though.


>
> Ciao
> Hannes
>
>
> Thanks, cheers,
>
> Brian
>
>
>> Ciao
>> Hannes
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments a= re confidential and may also be privileged. If you are not the intended rec= ipient, please notify the sender immediately and do not disclose the conten= ts to any other person, use it for any purpose, or store or copy the inform= ation in any medium. Thank you.
>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you.
>


--94eb2c080010322f0e054a4b90f3-- From nobody Thu Mar 9 04:49:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13BA1295AE for ; Thu, 9 Mar 2017 04:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3aqYJh1ej69g for ; Thu, 9 Mar 2017 04:49:00 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C615129438 for ; Thu, 9 Mar 2017 04:49:00 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id d88so2349133ybi.0 for ; Thu, 09 Mar 2017 04:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/bj4K54LVADpt2KE3XCVomHqhtU/CZoevKJkccQWHyE=; b=Y1iLNi44DixICFsUmrtJ6Xu9ctv4FJBNwxf1zj+FiMY0/O6KJtAkY4Qn2/s39hV0X/ b3X5kh3kT+cO5robjaUVFzvUVwOohkJzTl4DYqYEzz5NP1ImMH2bjkZKKsZiRpZJQDIo uwcQz6MlNvYgBpUXzuE2KLBytXQfaITu/MvtQ47X1ViofSuigSfyq8f7ACgiTsxZlN/g oqBVUaWrYAx7qjUCYNjOgz3wjFfmRseuaOmx/W2i7ONs3izhDVOZ6iD0AP/qwtfQ/TZu vE6t9v11w6KMl+l0r3rbBgj9BRiOu23pGtW9zy/hQ2A+Sq7bebrriMkq9JBHbaWkIQge lsAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/bj4K54LVADpt2KE3XCVomHqhtU/CZoevKJkccQWHyE=; b=aurH92pv3DCL7LCvv260/4g+ShzpdOkNi8Rp/ht+itV+6XKxHYs6jk+QzOaxyqhHu0 QWqceXA80iGTaIk+EdVYkcSFtBlbf4y3pUQSjFffGLl1xK593F/W3tl4yjK54q91jQsI FXc186+vb7xF9+6u5iJUVXRZzhxeGpqe3HTIxWcBR7tH+Jefl5JDsPT8VwBjDjlOqu9a LtsoBrbJKQI5bx3Q2DuYOKBOu/hoeguE8c+33vZbt4CyEnMOEfaWLl2rdJxPY5KKK+u8 UV4KyFs3mjkNzu+NWvBvSlJi9WT7OdQkTUFLVsvw/VbF1CBgSA896KvuQ0M5iWbPNic8 WlCA== X-Gm-Message-State: AMke39kXWd/S/d/D1i/ghbw8ertoVfgxB5iGbKocVI5zYqxL5d4EuuW0b0Ds/OQUTWZ6fv0rGml/txBQCeisUH9o X-Received: by 10.37.39.202 with SMTP id n193mr3431753ybn.127.1489063739463; Thu, 09 Mar 2017 04:48:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 04:48:38 -0800 (PST) In-Reply-To: <8ed2217a-e65c-a24f-b192-796e553337f3@tik.ee.ethz.ch> References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com> <8ed2217a-e65c-a24f-b192-796e553337f3@tik.ee.ethz.ch> From: Ian Swett Date: Thu, 9 Mar 2017 07:48:38 -0500 Message-ID: Subject: Re: DISINTEREST frame To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=94eb2c13565c3d7407054a4babe2 Archived-At: Cc: Mike Bishop , "Lubashev, Igor" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:49:02 -0000 --94eb2c13565c3d7407054a4babe2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 5:50 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Okay, that's now a little bit a hack but after sending DISINTEREST you > could just acknowledge all data up to the highest packet number you've > seen, no matter if you received them or not because you don't need them > anymore anynway; that would avoid any retransmissions... > > That would 'work' if exactly one stream was active and there weren't any important non-Stream frames you were inadvertently acking. But most of the time it will result in major state inconsistency, so I would never recommend acking non-received packets in the QUIC transport doc. > Mirja > > On 08.03.2017 18:53, Mike Bishop wrote: > >> You=E2=80=99re correct that the sender of DISINTEREST no longer cares ab= out the >> data, >> other than for flow control and state consistency. >> >> >> >> I had been trying to approach it from a principle that only the sender c= an >> affect the stream state in their direction =E2=80=93 the receiver can on= ly request >> changes. As the draft currently reads, the receiver counts flow control >> as >> STREAM frames are received, and upon receipt of a RST_STREAM. If a STRE= AM >> frame is delayed, it doesn=E2=80=99t (yet) count against the receiver=E2= =80=99s flow >> control >> window, even if it can infer that the data has been sent (by virtue of >> receiving a later offset). Only upon receipt of a RST_STREAM do you >> account >> all outstanding data against the flow control window. >> >> >> >> Changing it so that all data up to the furthest offset received on a >> stream >> counts is certainly possible, but feels like an orthogonal change to thi= s >> PR. I=E2=80=99ve opened issue #370 for that. In that world, the requir= ement >> would >> be to reliably deliver /either/ a RST_STREAM /or/ a STREAM frame with th= e >> FIN >> bit set (basically, you MUST communicate your final offset). So long as >> one >> of those gets through, DISINTEREST by itself could stop retransmissions. >> That feels marginally more complicated, since it adds an additional path >> to >> stop retransmission on a stream and makes the accounting logic on receip= t >> of >> a STREAM frame more complicated. >> >> >> >> My inclination is to leave retransmissions tied to having sent RST_STREA= M, >> but I=E2=80=99ll defer to others whether the complexity is worth the pot= ential >> savings. >> >> >> >> *From:*Lubashev, Igor [mailto:ilubashe@akamai.com] >> *Sent:* Wednesday, March 8, 2017 9:19 AM >> *To:* Lubashev, Igor ; Ian Swett < >> ianswett@google.com>; >> Martin Thomson >> *Cc:* Mike Bishop ; quic@ietf.org >> *Subject:* RE: DISINTEREST frame >> >> >> >> P.S. >> >> The paragraph above states: >> >> >> >> * [STREAM frames received after sending DISINTEREST] will be discarded >> >> >> >> So I read it that the peer who send DISINTEREST will /not/ be waiting fo= r >> that data. That peer does not need any accounting for flow control >> either, >> since he has already received the FIN (with the byte offset) and is >> already >> in =E2=80=9Chalf-closed (remote)=E2=80=9D or =E2=80=9Cclosed=E2=80=9D st= ate. >> >> >> >> >> >> *From:*Lubashev, Igor [mailto:ilubashe@akamai.com] >> *Sent:* Wednesday, March 08, 2017 12:10 PM >> *To:* Ian Swett >; >> Martin >> Thomson > >> *Cc:* Michael.Bishop@microsoft.com = ; >> quic@ietf.org >> *Subject:* RE: DISINTEREST frame >> >> >> >> * you definitely need "RST_STREAM is sent unless all outstanding data >> has >> been sent AND acknowledged.", otherwise the peer waits forever for >> data >> that won't arrive. >> >> >> >> >> >> I guess this is the core of the question, which goes beyond the choice f= or >> this rare condition. =E2=80=9CIt is reasonable to think that the peer wh= o sent >> DISINTEREST is still waiting for any data?=E2=80=9D The whole point of >> DISINTEREST >> is to indicate that =E2=80=9CI am /not/ waiting for any more data=E2=80= =9D. >> >> >> >> >> >> *From:*Ian Swett [mailto:ianswett@google.com] >> *Sent:* Wednesday, March 08, 2017 9:51 AM >> *To:* Martin Thomson > martin.thomson@gmail.com>> >> *Cc:* Lubashev, Igor >; >> Michael.Bishop@microsoft.com ; >> quic@ietf.org >> *Subject:* Re: DISINTEREST frame >> >> >> >> Martin's right, you definitely need "RST_STREAM is sent unless all >> outstanding data has been sent AND acknowledged.", otherwise the peer >> waits >> forever for data that won't arrive. >> >> >> >> Question: Why call it DISINTEREST, instead of REQUEST_RST? It wasn't >> obvious >> to me what DISINTEREST was until I read further, whereas REQUEST_RST is >> pretty obvious, assuming you know about RST_STREAM. >> >> >> >> On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson > > wrote: >> >> On 8 March 2017 at 15:35, Lubashev, Igor > > wrote: >> > We are taking about a case when the sender of the stream is alread= y >> in >> > "half-closed (local)" (or "closed") and the receiver is already in >> > "half-closed (remote)" (or "closed"). This RST_STREAM will not >> affect the >> > state of the stream for any peer. The only information RST_STREAM >> contains >> > now is "I will not transmit". But the peer already sent >> DISINTERESTED to >> > indicate it does not care about retransmissions. >> >> Even after closing a stream, an endpoint needs to retransmit data. = It >> closes when it first sends the FIN. >> >> >> >> > --94eb2c13565c3d7407054a4babe2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 5:50 AM, Mirja K=C3=BChlewind <mirja.kueh= lewind@tik.ee.ethz.ch> wrote:
Okay, that's now a little bit a hack but after sending DISINTEREST y= ou could just acknowledge all data up to the highest packet number you'= ve seen, no matter if you received them or not because you don't need t= hem anymore anynway; that would avoid any retransmissions...


That would 'work' if exactly o= ne stream was active and there weren't any important non-Stream frames = you were inadvertently acking.=C2=A0 But most of the time it will result in= major state inconsistency, so I would never recommend acking non-received = packets in the QUIC transport doc.
=C2=A0
Mirja

On 08.03.2017 18:53, Mike Bishop wrote:
You=E2=80=99re correct that the sender of DISINTEREST no longer cares about= the data,
other than for flow control and state consistency.



I had been trying to approach it from a principle that only the sender can<= br> affect the stream state in their direction =E2=80=93 the receiver can only = request
changes.=C2=A0 As the draft currently reads, the receiver counts flow contr= ol as
STREAM frames are received, and upon receipt of a RST_STREAM.=C2=A0 If a ST= REAM
frame is delayed, it doesn=E2=80=99t (yet) count against the receiver=E2=80= =99s flow control
window, even if it can infer that the data has been sent (by virtue of
receiving a later offset).=C2=A0 Only upon receipt of a RST_STREAM do you a= ccount
all outstanding data against the flow control window.



Changing it so that all data up to the furthest offset received on a stream=
counts is certainly possible, but feels like an orthogonal change to this PR.=C2=A0 I=E2=80=99ve opened issue #370 for that.=C2=A0 In that world, the= requirement would
 be to reliably deliver /either/ a RST_STREAM /or/ a STREAM frame with the F= IN
bit set (basically, you MUST communicate your final offset).=C2=A0 So long = as one
of those gets through, DISINTEREST by itself could stop retransmissions. That feels marginally more complicated, since it adds an additional path to=
stop retransmission on a stream and makes the accounting logic on receipt o= f
a STREAM frame more complicated.



My inclination is to leave retransmissions tied to having sent RST_STREAM,<= br> but I=E2=80=99ll defer to others whether the complexity is worth the potent= ial savings.



 *From:*Lubashev, Igor [mailto:ilubashe@akamai.com]
*Sent:* Wednesday, March 8, 2017 9:19 AM
*To:* Lubashev, Igor <ilubashe@akamai.com>; Ian Swett <ianswett@google.com>;
Martin Thomson <martin.thomson@gmail.com>
*Cc:* Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org
*Subject:* RE: DISINTEREST frame



P.S.

=C2=A0 The paragraph above states:



 =C2=A0 * [STREAM frames received after sending DISINTEREST] will be discard= ed



So I read it that the peer who send DISINTEREST will /not/ be waiting for
that data.=C2=A0 That peer does not need any accounting for flow control ei= ther,
since he has already received the FIN (with the byte offset) and is already=
in =E2=80=9Chalf-closed (remote)=E2=80=9D or =E2=80=9Cclosed=E2=80=9D state= .





*From:*Lubashev, Igor [mailto:ilubashe@akamai.com]
*Sent:* Wednesday, March 08, 2017 12:10 PM
*To:* Ian Swett <ianswett@google.com <mailto:ianswett@google.com>>; Martin
Thomson <m= artin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
*Cc:* Mic= hael.Bishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>;<= br> quic@ietf.org <ma= ilto:quic@ietf.org&g= t;
*Subject:* RE: DISINTEREST frame



=C2=A0 * you definitely need "RST_STREAM is sent unless all outstandin= g data has
=C2=A0 =C2=A0 been sent AND acknowledged.", otherwise the peer waits f= orever for data
=C2=A0 =C2=A0 that won't arrive.





I guess this is the core of the question, which goes beyond the choice for<= br> this rare condition. =E2=80=9CIt is reasonable to think that the peer who s= ent
DISINTEREST is still waiting for any data?=E2=80=9D=C2=A0 The whole point o= f DISINTEREST
 is to indicate that =E2=80=9CI am /not/ waiting for any more data=E2=80=9D.=





*From:*Ian Swett [mailto:ianswett@google.com]
*Sent:* Wednesday, March 08, 2017 9:51 AM
*To:* Martin Thomson <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>= ;>
*Cc:* Lubashev, Igor <ilubashe@akamai.com <mailto:ilubashe@akamai.com>>;
Michael.B= ishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>;
quic@ietf.org <ma= ilto:quic@ietf.org&g= t;
*Subject:* Re: DISINTEREST frame



Martin's right, you definitely need "RST_STREAM is sent unless all=
outstanding data has been sent AND acknowledged.", otherwise the peer = waits
forever for data that won't arrive.



Question: Why call it DISINTEREST, instead of REQUEST_RST?=C2=A0 It wasn= 9;t obvious
to me what DISINTEREST was until I read further, whereas REQUEST_RST is
pretty obvious, assuming you know about RST_STREAM.



On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson <martin.thomson@gmail.com
<mailto:ma= rtin.thomson@gmail.com>> wrote:

=C2=A0 =C2=A0 On 8 March 2017 at 15:35, Lubashev, Igor <ilubashe@akamai.com
= =C2=A0 =C2=A0 <mailto:ilubashe@akamai.com>> wrote:
=C2=A0 =C2=A0 > We are taking about a case when the sender of the stream= is already in
=C2=A0 =C2=A0 > "half-closed (local)" (or "closed") = and the receiver is already in
=C2=A0 =C2=A0 > "half-closed (remote)" (or "closed")= . This RST_STREAM will not affect the
=C2=A0 =C2=A0 > state of the stream for any peer. The only information R= ST_STREAM contains
=C2=A0 =C2=A0 > now is "I will not transmit". But the peer alr= eady sent DISINTERESTED to
=C2=A0 =C2=A0 > indicate it does not care about retransmissions.

=C2=A0 =C2=A0 Even after closing a stream, an endpoint needs to retransmit = data.=C2=A0 It
=C2=A0 =C2=A0 closes when it first sends the FIN.





--94eb2c13565c3d7407054a4babe2-- From nobody Thu Mar 9 04:49:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D8B1295B0 for ; Thu, 9 Mar 2017 04:49:03 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 Hak2a5KXqZrd for ; Thu, 9 Mar 2017 04:49:02 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40068.outbound.protection.outlook.com [40.107.4.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8A81295A7 for ; Thu, 9 Mar 2017 04:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YK4kaRXqQ19pO0SD58+NFAPmvDjhPMu57+Ed+EQ4QII=; b=ogFsLrUzRcbSfFVqsdwHhzIjrtT5QFXoaBoJ3RPfZQ2h3ABJDMbauHzyVg8B+ssBaKeXUeyHRM3WgtqUV+9+5N3ALTkKX63r6/fhn5SRyGEP9jl5v5S4Jf2oOZlizp1U+6htFohHci4HlI48GnRic5zpKcDQebSOQmpWVr4lZb4= Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) by HE1PR0802MB2474.eurprd08.prod.outlook.com (10.175.34.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 12:48:59 +0000 Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) by HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 12:48:58 +0000 From: Hannes Tschofenig To: Ian Swett , "Brian Trammell (IETF)" Subject: RE: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Topic: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Index: AdKYwCv+WlyzFqftRk6FS9cmOv7E4QAA9S0AAAAI+ZAAAR6FgAACcwqAAAAtXyA= Date: Thu, 9 Mar 2017 12:48:58 +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: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.114.23] x-ms-office365-filtering-correlation-id: d2fbe97c-3c00-4f08-cef4-08d466eaa7ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR0802MB2474; x-microsoft-exchange-diagnostics: 1; HE1PR0802MB2474; 7:MkpBKvYNMUTneb8Z6gxcHhFu9gAmNYssKz/Bxdx9HPAnE6l4STtjgdPEQqKdrcYgJROKo4PnqTm0l2y1f7MvaYpIoCvTkmNJ+A/s3ufIEwV+w+vWCcWN/2l9vLwUxWytNK9mJ9tlrwNsZvZvXMXqe1+GsTBQUXqCcbffeImKWvI9z4W1nwIzyo2/N2fj2Qybm0EZwDWjcgsS6UxQdZ3DXjniXslMJu/PkqhJKYlr2nGR8sfchpjNJXvmV8tFnQ3vU8d8ZbDxSTMJrQQe9AUwEA4CNpZo8SFdYNgq7HssWm9RdecgqjWDoRa5XSQDQ/gtI4rvBYcoLiLUA4XbuUDooQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:HE1PR0802MB2474; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0802MB2474; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39850400002)(39450400003)(39410400002)(39840400002)(40434004)(6436002)(77096006)(9686003)(606005)(54896002)(236005)(25786008)(6306002)(86362001)(6506006)(53936002)(2906002)(189998001)(122556002)(33656002)(5660300001)(230783001)(66066001)(93886004)(229853002)(50986999)(7696004)(2950100002)(55016002)(99286003)(2900100001)(8936002)(5890100001)(7736002)(54356999)(3280700002)(3660700001)(6246003)(9326002)(3846002)(102836003)(790700001)(81166006)(6116002)(4326008)(8676002)(38730400002)(7906003)(74316002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0802MB2474; H:HE1PR0802MB2475.eurprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0802MB2475FA4659A24AE145B10D40FA210HE1PR0802MB2475_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 12:48:58.2930 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2474 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:49:04 -0000 --_000_HE1PR0802MB2475FA4659A24AE145B10D40FA210HE1PR0802MB2475_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWFuLA0KDQoNCsOYICBZZXMsIG15IHRhbGsgd2FzIGluIEJlcmxpbiAyMDE2IGF0IFRTViBP cGVuKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ni9hZ2VuZGEvdHN2YXJl YS8pLiAgSSBzZW50IE1pcmphIGEgUERGIGNvcHkgb2YgdGhlIHNsaWRlcywgYnV0IEknbSBub3Qg c3VyZSB3aGVyZSB0aGV5IGFyZSBwb3N0ZWQuDQoNCkZvdW5kIHRoZW0gYXQgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni10c3ZhcmVhLTIucGRmDQoN Cg0Kw5ggIFRvIHNlY29uZCB3aGF0IEJyaWFuIHNhaWQsIG1vc3QgJ25ldHdvcmtzJyB3aGljaCBi bG9jayBRVUlDIGFyZSBjb3Jwb3JhdGlvbnMgdGhhdCBhcmUgbGFyZ2UgZW5vdWdoIHRvIGhhdmUg dGhlaXIgb3duIEFTIG51bWJlci4gIEkndmUgbmV2ZXIgZm91bmQgYSBtYWpvciBJU1AgdGhhdCBi bG9ja3MgVURQIDQ0My4NCg0KSGF2ZSB5b3UgdGVzdGVkIHRoZSByZXN1bHRzIG9mIHVzaW5nIFVE UCBvbiBwb3J0cyBvdGhlciB0aGFuIDQ0MyBhbmQgd2hldGhlciB0aGUgYmxvY2tpbmcgcmF0ZSBp bmNyZWFzZXM/DQoNCkNpYW8NCkhhbm5lcw0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= --_000_HE1PR0802MB2475FA4659A24AE145B10D40FA210HE1PR0802MB2475_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwt O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6Mjk3ODA1MzIxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNDA1ODgxNDI4IC0xMDA1MjAwMCAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAx MzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIElhbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5ZZXMsIG15IHRhbGsgd2FzIGluIEJlcmxpbiAy MDE2IGF0IFRTViBPcGVuKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy85Ni9hZ2VuZGEvdHN2YXJlYS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVl dGluZy85Ni9hZ2VuZGEvdHN2YXJlYS88L2E+KS4mbmJzcDsgSSBzZW50IE1pcmphIGEgUERGIGNv cHkgb2YgdGhlIHNsaWRlcywgYnV0IEknbSBub3Qgc3VyZQ0KIHdoZXJlIHRoZXkgYXJlIHBvc3Rl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Rm91bmQgdGhlbSBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni10c3ZhcmVhLTIucGRmIj5odHRwczovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LXRzdmFyZWEtMi5wZGY8L2E+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5UbyBzZWNvbmQgd2hhdCBCcmlhbiBzYWlkLCBtb3N0ICduZXR3b3Jrcycgd2hpY2gg YmxvY2sgUVVJQyBhcmUgY29ycG9yYXRpb25zIHRoYXQgYXJlIGxhcmdlIGVub3VnaCB0byBoYXZl IHRoZWlyIG93biBBUyBudW1iZXIuJm5ic3A7IEkndmUgbmV2ZXIgZm91bmQgYSBtYWpvciBJU1Ag dGhhdCBibG9ja3MgVURQIDQ0My48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhhdmUgeW91IHRlc3RlZCB0aGUgcmVzdWx0cyBvZiB1 c2luZyBVRFAgb24gcG9ydHMgb3RoZXIgdGhhbiA0NDMgYW5kIHdoZXRoZXIgdGhlIGJsb2NraW5n IHJhdGUgaW5jcmVhc2VzPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaWFvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhhbm5lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR0802MB2475FA4659A24AE145B10D40FA210HE1PR0802MB2475_-- From nobody Thu Mar 9 04:52:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79CF1295AD for ; Thu, 9 Mar 2017 04:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 GvKowg_F75Gi for ; Thu, 9 Mar 2017 04:52:14 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 4C1231295AC for ; Thu, 9 Mar 2017 04:52:14 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id v198so7151617ywc.2 for ; Thu, 09 Mar 2017 04:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IGkMEu8tUju83P5CzU2EZ/GDuL87a7ockPVixWuHDpE=; b=F1rNVcV2yPDEk/IkpoaRhXmXJ5VtiJRaw19HKAdfT7nnS44axebibVbQQUesWsL021 wweLLOyfPYNO3hJ9KGN/qWGvvpn5YB6ownqlhfeqSEF9OnJU3LxofdGRCKDD4uqezm2p M124EdvnF6ApO0LGmbaE4GJ4/E8X3f57pR2eUYruthF5gvcOPSTXn2MV50RSZmNLDE9i dnbGDmJ+aXNMo8BOzTOCHs1VpDM0u4DOFgR25DFXiWL+moYsxFkGr4Vx1XvYG2Ve30LA 858Q6PiC5xrZy+lwjcjKOUkKXaTL5lV+1NdFIhJhaUP1r5P9P2+C7SeV6U3Xc+f1KUqF RcnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IGkMEu8tUju83P5CzU2EZ/GDuL87a7ockPVixWuHDpE=; b=bbwVgshCwJVTCoclnHLoc961H1nScufH+kJVIDUVAm+yJkYTieEBNxjwGO3Iab6O+Z 79FqmjslHxJ1l4/GajCsRVKLPERMQqUauXE9WhpiIyb36bRIkzJB7w73lkImyjq/XhMq dbj/OgPbZFCwzRjGvHvrFg5kG65gUhl/BfCE1d7ph6MlcZUTAcwtripvAvduOb8ufzAf NPpWJQyLmXDOI8dIAkRJL60Wz7BgLFNuwa6ok8XpId6wcgJKPloKGFZht+jxz2QzM2bT LKRNqbKan1newei12wC9bsw/U7Fl+uIRj3PpkvCY3J8vZJfBGuag0ywYwafZDq8FRenF gi2Q== X-Gm-Message-State: AMke39nTzwgzNDdQpVZnk5V/tdcz3QJ0WDBi7cyhwTY441TVLFgKT7afALc9v5Gzs93VbY9l7BQ4rcOjpx8Acqb3 X-Received: by 10.13.231.130 with SMTP id q124mr3503576ywe.84.1489063933444; Thu, 09 Mar 2017 04:52:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 04:51:52 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Mar 2017 07:51:52 -0500 Message-ID: Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=94eb2c07ee7ccd9279054a4bb603 Archived-At: Cc: "Brian Trammell \(IETF\)" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:52:16 -0000 --94eb2c07ee7ccd9279054a4bb603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 7:48 AM, Hannes Tschofenig wrote: > Hi Ian, > > > > =C3=98 Yes, my talk was in Berlin 2016 at TSV Open(https://datatracker.i= etf. > org/meeting/96/agenda/tsvarea/). I sent Mirja a PDF copy of the slides, > but I'm not sure where they are posted. > > > > Found them at https://www.ietf.org/proceedings/96/slides/slides- > 96-tsvarea-2.pdf > > > > =C3=98 To second what Brian said, most 'networks' which block QUIC are > corporations that are large enough to have their own AS number. I've nev= er > found a major ISP that blocks UDP 443. > > > > Have you tested the results of using UDP on ports other than 443 and > whether the blocking rate increases? > > > We have some data from about 4 years ago on this, but I don't have it easily available. I don't remember 443 being dramatically more open than other ports. In general, it seemed UDP either was blocked or wasn't. > Ciao > > Hannes > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > --94eb2c07ee7ccd9279054a4bb603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 9, 2017 at 7:48 AM, Hannes Tschofenig <Hannes.Tschofen= ig@arm.com> wrote:

Hi Ian,

=C2=A0

=C3=98=C2=A0 Yes, my talk was in Berlin 2016 at TSV Open(https://datatracker.ietf.org/meeting/96/agenda/tsvarea/).=C2=A0 I sent Mirja a PDF copy of the slides, but I'm not sure where they are posted.

=C3=98=C2=A0 To second what Brian said, most 'networks&#= 39; which block QUIC are corporations that are large enough to have their o= wn AS number.=C2=A0 I've never found a major ISP that blocks UDP 443.

=C2=A0

Have you tested the resul= ts of using UDP on ports other than 443 and whether the blocking rate incre= ases?

=C2=A0

<= /div>

We have some data f= rom about 4 years ago on this, but I don't have it easily available.=C2= =A0 I don't remember 443 being dramatically more open than other ports.= =C2=A0 In general, it seemed UDP either was blocked or wasn't. =C2=A0
=C2=A0

Ciao

Hannes

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--94eb2c07ee7ccd9279054a4bb603-- From nobody Thu Mar 9 04:59:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D801295B0 for ; Thu, 9 Mar 2017 04:59:42 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vuSNqHM5tvWX for ; Thu, 9 Mar 2017 04:59:41 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CFA129598 for ; Thu, 9 Mar 2017 04:59:41 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v198so7225941ywc.2 for ; Thu, 09 Mar 2017 04:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A6TixqNjG/zYg0HY52p55y3pm54caa0sdz+ICqIgERQ=; b=KQ3uMuI2nvXhn8XX+T8yfM8nrBDaPSGzZiiiNQ7MGGlMxYfg+mgt/m5JhuPJlP+VKY eAC6YbBIoyAutHhfiUv3M9D/h30Jw+0a7Gdei2dASeuos+t2J3n2J4OpBfgAdjhU//xk BXdTQOg2i7UAHcjBeBUXaRtE9Gv7QoHzouMT/qbqprnyh1ZijVCuguKp+HmZynCkmmWB W988AO/7Ao6RVtiV+20XuDmQQHluiP4RSoUtVTEm7Z944YW6NfQ2L6/H0V7yymtZUXsW A4asPEQoam3Tvx7TbCa6tOMze8hCl1hua3XB2DZTjh5+mwj2Kc+ozXca5DQ/fldycUOc Q4ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A6TixqNjG/zYg0HY52p55y3pm54caa0sdz+ICqIgERQ=; b=rI3vNZi1fMumTZcc8Ckzx0VT10mCB7hL3rtsxqq9SIEnDLz7WiQ4FZ9lxIcsreL1pL SjeOzqUUgfm/7RMdDAbn3UEzGN/AEiWFXY5on2xuarNLiYuzNGvoNQOGtpAS+kIjIs+Z 0BNtqGAHu60fdUY6oKD/zuq/DPW5r4Yjk7Au5KD9dJK+cUB6C/RR3ze0HnZcNsWEJBK7 /TmGz3S07OhmAGzf/Qmz7Go+Er3ilhf2hDiEDF6YDD69LbdOCCokWKNLX2FTJ/q4P7Fn 2K4xrGRXAgaZGnkO85sBw8OJBKcWKD2w7RNV2dYy7RNFGmlFyq7NBWJcHDXyL5uJjiTf vE2Q== X-Gm-Message-State: AMke39nBtKYeaE9TzVI54yrl+TjxHyHPGjlzg0khd60FXKkOouLS6gg0DlTFi7m/nEcJ+chgF6TeyPKIT7LyeCVe X-Received: by 10.13.252.4 with SMTP id m4mr3526929ywf.232.1489064380215; Thu, 09 Mar 2017 04:59:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 04:59:19 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Mar 2017 07:59:19 -0500 Message-ID: Subject: Re: Return of the alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c064a506ec663054a4bd1cc Archived-At: Cc: Jana Iyengar , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:59:42 -0000 --94eb2c064a506ec663054a4bd1cc Content-Type: text/plain; charset=UTF-8 Sounds good to me as well. On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson wrote: > On 9 March 2017 at 18:27, Jana Iyengar wrote: > > I've received many helpful comments on the PR, which I've now > incorporated > > and I've gotten one approval. I've also gotten go-aheads from almost > > everyone, so I'd like to land this PR on Thursday (PST), if possible. I'm > > giving a heads-up to those who may not have had a chance to go over it > yet: > > please do it soon. > > > > If I don't hear otherwise, I plan to land this PR at noon on Thursday > (PST). > > I think that this is a good idea. I don't think that we need to have > consensus on every detail of this (and I don't think we do), but I > think that this will unblock a bunch of other work. I hope that this > is acceptable to chairs process-wise. > > On that point, a question for the chairs in light of Mark's recent > email regarding consensus decisions. I expect that this single change > will result in a bunch of issues being closed. A lot of those will be > closed as now being irrelevant, but some might not be fully "closed" > in the sense that the underlying concern wasn't addressed. I hope > that the people reviewing this will identify new issues where this PR > fell short of meeting their goals. Is that an acceptable process > here? Do you want to avoid marking the issues we close as a result of > this change with "has-consensus"? > --94eb2c064a506ec663054a4bd1cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds good to me as well.

On Thu, Mar 9, 2017 at 3:50 AM, Martin Thom= son <martin.thomson@gmail.com> wrote:
On 9 March 2017 at 18:27, Jana Iyengar = <jri@google.com> wrote:
> I've received many helpful comments on the PR, which I've now = incorporated
> and I've gotten one approval. I've also gotten go-aheads from = almost
> everyone, so I'd like to land this PR on Thursday (PST), if possib= le. I'm
> giving a heads-up to those who may not have had a chance to go over it= yet:
> please do it soon.
>
> If I don't hear otherwise, I plan to land this PR at noon on Thurs= day (PST).

I think that this is a good idea.=C2=A0 I don't think that we ne= ed to have
consensus on every detail of this (and I don't think we do), but I
think that this will unblock a bunch of other work.=C2=A0 I hope that this<= br> is acceptable to chairs process-wise.

On that point, a question for the chairs in light of Mark's recent
email regarding consensus decisions.=C2=A0 I expect that this single change=
will result in a bunch of issues being closed.=C2=A0 A lot of those will be=
closed as now being irrelevant, but some might not be fully "closed&qu= ot;
in the sense that the underlying concern wasn't addressed.=C2=A0 I hope=
that the people reviewing this will identify new issues where this PR
fell short of meeting their goals.=C2=A0 Is that an acceptable process
here?=C2=A0 Do you want to avoid marking the issues we close as a result of=
this change with "has-consensus"?

--94eb2c064a506ec663054a4bd1cc-- From nobody Thu Mar 9 05:04:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8E12957B for ; Thu, 9 Mar 2017 05:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrevzjnUaOho for ; Thu, 9 Mar 2017 05:04:05 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8F521129572 for ; Thu, 9 Mar 2017 05:04:05 -0800 (PST) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 173633A0A3 for ; Thu, 9 Mar 2017 08:04:02 -0500 (EST) Received: by mail-qk0-f177.google.com with SMTP id 1so116782869qkl.3 for ; Thu, 09 Mar 2017 05:04:02 -0800 (PST) X-Gm-Message-State: AMke39lDCkwKD4ExKACSuZJwgE4abFwT+5e/LS4u6/mrhrLETTXyXvxIbk3AvWiTgIIgd4NLlYlhuotviGa96g== X-Received: by 10.200.34.144 with SMTP id f16mr14495365qta.186.1489064641772; Thu, 09 Mar 2017 05:04:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.177.130 with HTTP; Thu, 9 Mar 2017 05:04:01 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Thu, 9 Mar 2017 08:04:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of the alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f41fe058166054a4be130 Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG , Eric Rescorla X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:04:07 -0000 --001a113f41fe058166054a4be130 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson wrote: > hope > that the people reviewing this will identify new issues where this PR > fell short of meeting their goals. Is that an acceptable process > here? > I completely agree with this. At this relatively early stage we need to lean harder into landing stuff and then opening follow-on issues.. right now there is a significant body of work that you have to hold in your head "I know roughly how this is going to change" to meaningfully use even the editor's copy - closing that gap would be very helpful. Obviously the header is a big one. For something like this I would suggest marking it consensus and perhaps just commenting on any known caveats to help with paper trail. --001a113f41fe058166054a4be130 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
hope
that the people reviewing this will identify new issues where this PR
fell short of meeting their goals.=C2=A0 Is that an acceptable process
here?


I co= mpletely agree with this. At this relatively early stage we need to lean ha= rder into landing stuff and then opening follow-on issues.. right now there= is a significant body of work that you have to hold in your head "I k= now roughly how this is going to change" to meaningfully use even the = editor's copy - closing that gap would be very helpful. Obviously the h= eader is a big one.

For something l= ike this I would suggest marking it consensus and perhaps just commenting o= n any known caveats to help with paper trail.
--001a113f41fe058166054a4be130-- From nobody Thu Mar 9 06:03:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E59B129638 for ; Thu, 9 Mar 2017 06:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsZt6rUQRo3K for ; Thu, 9 Mar 2017 06:02:50 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 7DB1A129635 for ; Thu, 9 Mar 2017 06:02:50 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id a5so2776619ybb.2 for ; Thu, 09 Mar 2017 06:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MafafnOANedKDvdDECevTRKHk11onZK0gATr1SLx87c=; b=iVRzbmtQ+ljhI2xZuJm1ty+elWhLrT6LxEkMOw6slIifVZogmc4kGzyzCBgQSTRdM8 AbwmeyWvwScfOkRltTUc8Zg9R4vh0rhEq/6fDFpxCqGWnqIxGUO1jjeEklPinHBevujk Z7310mSp8w7Cg4pBIZsFL1icPMmtSienZxxADI1S05P1hrUIb62vtg2r4vMbWQy76L13 gpjD19phVdwe5Cavi2fu4YaE/dxcT9TzQ1DnPePxVeki5lTn+Tsgretdbu5atXgqK0Mx GOek3OsMXupkTkcw1UBrjvA73ZUCMTiRcW2JSSqCF0LXqlY0o2HilzuOlmLqhqg8z2OI 7CWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MafafnOANedKDvdDECevTRKHk11onZK0gATr1SLx87c=; b=Q7d6C9DzkWqKg/8z5EiFAH00+J7mLYW/WmXfqhpd25lblDhWvoFbVji6uhEO9Xt2rJ 5a3JIBvxwGlJGjuK+c1eNIVVJNPcCgVEX0fH5CMqh/BIKDu2akhm8xGOY/EXcQaXz7Ou IlQL1YgovmkTBmhACp1u8PPIDRGfmeVawxgNZPekmkhvGdIr1HhM3ZJJgqrcODC8+/kB HppfSgfQrvzJt+nQ5G2kukkkJDVCkis1BakeOz+i/EQyaAEeS2hkBJdi8UlG0B2Jg9mM MsEA8z+VK8gt1LZY2OeUWI0LtGPBvOsDCCuOSbkYSGUoU5EdRUe5bPHxWw6J+WxGClEU +pOQ== X-Gm-Message-State: AMke39m0Eng8a9zS4OdH+a3K3wbt1l5wScpGK0imXo28AwUfygyI0aqaMrELvAOLtmicwE2cZpXgSh8KYi2K5A== X-Received: by 10.37.53.138 with SMTP id c132mr3870689yba.105.1489068169523; Thu, 09 Mar 2017 06:02:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 06:02:09 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 06:02:09 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: "Brian Trammell (IETF)" Content-Type: multipart/alternative; boundary=001a114bbb324a97fa054a4cb3f5 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:02:52 -0000 --001a114bbb324a97fa054a4cb3f5 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 2:43 AM, Brian Trammell (IETF) wrote: > > > On 09 Mar 2017, at 02:46, Eric Rescorla wrote: > > > > On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell wrote: > >> hi ekr, > > > > >> Taking the case of Connection ID, specifically, it does seem to be a > candidate for moving to negotiation, saving one header bit pretty much > everywhere. Connection ID is designed for load balancers, and one could > define negotiation to be mandatory on the client side: if the server gives > you a connection ID, then the client MUST return it. Otherwise, any device > trying to observe the Connection ID would have to keep the > has-a-Connection-ID state observed during the negotiation, and it wouldn't > have access to that state when the Connection ID is used during rebinding. > >> > > To the extent to which the connection ID is (a) unique (b) long and (c) > in a predictable place when it is > > present, it seems like it shouldn't be hard to look for it in that place > whether the bit is there or not. > > In any case, what's the persuasive benefit for middleboxes to have this > information. > > Here "middleboxes" means "middleboxes other than load balancers" here, > correct? Yes. Load balancers are attached to an endpoint. > You could certainly encrypt this information, at the cost of requiring the > load balancer to be the server-side party to the TLS session. To > understate, I'm not sure that architecture is universally applicable. > You could encrypt this information without that, by having a separate key that's shared with the load balancer. You don't need the server side to be a party to the TLS connection. >> In this case, saving the bit costs you the possibility of client-side > choice on whether to not return the Connection ID, which seems to me to > violate the mutual cooperation principle. > > > > Well, with negotiation, someone has to decide. The bit just moves that > to the client. > > Except that if the load balancer *needs* it, then the client has to > conform. > > The load balancer needs it to balance load efficiently. That's not entirely clear. Note that in the original QUIC design, the client supplied the connection ID, so the server side merely had to load balance based on some combination of a random value and the client's IP. I presume that a client that was very interested in not providing tracking > information could refuse to make Connection ID available, at the cost of > degraded performance. (f that's not the case, if failure to send connection > ID leads to connection failure, then "negotiation" is a euphemism: the > server informs the client whether it must send a connection ID, probably > encrypted, and nobody needs any flags, unless the presence of connection ID > changes the offsets of fields we *do* want to explicitly expose, such as > packet number echo (https://github.com/quicwg/base-drafts/issues/269) or > troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279). > Not to put too fine a point on it, but there's far from consensus that we want to expose either of these. -Ekr > > Cheers, > > Brian > --001a114bbb324a97fa054a4cb3f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 2:43 AM, Brian Trammell (IETF) <ietf@trammell.ch= > wrote:
<= br> > On 09 Mar 2017, at 02:46, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell <ietf@trammell.ch> wrote:
>> hi ekr,

<snip>

>> Taking the case of Connection ID, specifically, it does seem to be= a candidate for moving to negotiation, saving one header bit pretty much e= verywhere. Connection ID is designed for load balancers, and one could defi= ne negotiation to be mandatory on the client side: if the server gives you = a connection ID, then the client MUST return it. Otherwise, any device tryi= ng to observe the Connection ID would have to keep the has-a-Connection-ID = state observed during the negotiation, and it wouldn't have access to t= hat state when the Connection ID is used during rebinding.
>>
> To the extent to which the connection ID is (a) unique (b) long and (c= ) in a predictable place when it is
> present, it seems like it shouldn't be hard to look for it in that= place whether the bit is there or not.
> In any case, what's the persuasive benefit for middleboxes to have= this information.

Here "middleboxes" means "middleboxes other than load= balancers" here, correct?

Yes. Load b= alancers are attached to an endpoint.

=C2=A0
=
You could certainly encrypt this informatio= n, at the cost of requiring the load balancer to be the server-side party t= o the TLS session. To understate, I'm not sure that architecture is uni= versally applicable.

You could encrypt = this information without that, by having a separate key that's shared
with the load balancer. You don't need the server side to be a= party to the TLS connection.


>> In this case, saving the bit costs you the possibility of client-s= ide choice on whether to not return the Connection ID, which seems to me to= violate the mutual cooperation principle.
>
> Well, with negotiation, someone has to decide. The bit just moves that= to the client.
> Except that if the load balancer *needs* it, then the client has to co= nform.

The load balancer needs it to balance load efficiently.=

That's not entirely clear. Note that in the origina= l QUIC design, the client supplied
the connection ID, so the serv= er side merely had to load balance based on some combination
of a= random value and the client's IP.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I presume that a client that was very intere= sted in not providing tracking information could refuse to make Connection = ID available, at the cost of degraded performance. (f that's not the ca= se, if failure to send connection ID leads to connection failure, then &quo= t;negotiation" is a euphemism: the server informs the client whether i= t must send a connection ID, probably encrypted, and nobody needs any flags= , unless the presence of connection ID changes the offsets of fields we *do= * want to explicitly expose, such as packet number echo (https://github.com/quicwg/base-drafts/issues/269) or troubles= hooting flags (https://github.com/quicwg/base-d= rafts/issues/279).

Not to put too f= ine a point on it, but there's far from consensus that we want to expos= e
either of these.

-Ekr
=C2=A0=

Cheers,

Brian

--001a114bbb324a97fa054a4cb3f5-- From nobody Thu Mar 9 06:10:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC311129632 for ; Thu, 9 Mar 2017 06:10:45 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 UAz2wyE5Hwhz for ; Thu, 9 Mar 2017 06:10:44 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE5D129606 for ; Thu, 9 Mar 2017 06:10:44 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id p77so8086742ywg.1 for ; Thu, 09 Mar 2017 06:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yPDeVYPaZDk6YqPDRt1lUNUbt7ufpfOKm+kc4P9KTX4=; b=Yiih7grET7tyiRpuZRyp2TiTmnoh7wlAOIsB6amJHlhNi/6JIX2S7hBaYxPAzlW8ow c3p0WGWDf33xtTW54hiHkj/FOxI96F9PxFHbubVNNQXU8giFOjwABM9EJTfX174gIzDu p9P1Oowhu131HgHFC0arJTxpPWqQ/X9WDvdmyZor0KfUn9YagkPeA2D5+iJooO6dy8Xi qV0kn0J86P70obiK45KyhLe5++0F1vU9PqaShU8EwTW+3WXbKoLGZn+NpvRNJEkb/3Di grODOjYA0a8En5oxTAHAFsH2xi2Wun/S6SHEt/CinNSSrIctxmIXwSeGzmQbAsBhMSzt CYXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yPDeVYPaZDk6YqPDRt1lUNUbt7ufpfOKm+kc4P9KTX4=; b=s44QGxdt+gC94nY+3EnSFblkki3YPARDQfeF+XYP51cjFgue6oS4npCJuLHAECXnWE uiTs7OhhnbH5QkGHS0DcXlrIj73U6kDmBeuTBqgzmM8MyhP9kTCUSwNelBH0dgEkP8HG HNvnfGdhZLRJZo7wiIKYQUHLcZkwImCEdCl52B6IxpjWnZjKFo0T0RBsWhLx3Ni3TdkL R9qRyXWfqPk27E3SOFWDYTIzZuqdzzYk7LLL3h5h2y3qNI21ry2ExovMmiy5dnq8wAyf XBS2x1gwXyRZrK2qUp8/YR/3OVh5JsYwm5F3DJUtG9UXEkltpxM/DHdQovmgpxUTRamJ HSSg== X-Gm-Message-State: AMke39mLYuf1tmZetb37sB2happDe6Kn7DP16cNPJKJN4zrd9NORVV0Sv5Igz1K6Ir/rCKs/pvMKPwM9HGO2Mg== X-Received: by 10.129.177.8 with SMTP id p8mr3903274ywh.327.1489068643786; Thu, 09 Mar 2017 06:10:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 06:10:03 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 06:10:03 -0800 Message-ID: Subject: Re: Return of the alternate header proposal To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c13ce388f4246054a4ccf0b Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:10:46 -0000 --94eb2c13ce388f4246054a4ccf0b Content-Type: text/plain; charset=UTF-8 As Martin notes, I think there are a number of things that need discussion here, but I'm happy to land it as a step in the right direction. On Thu, Mar 9, 2017 at 5:04 AM, Patrick McManus wrote: > > On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson > wrote: > >> hope >> that the people reviewing this will identify new issues where this PR >> fell short of meeting their goals. Is that an acceptable process >> here? >> > > > I completely agree with this. At this relatively early stage we need to > lean harder into landing stuff and then opening follow-on issues.. right > now there is a significant body of work that you have to hold in your head > "I know roughly how this is going to change" to meaningfully use even the > editor's copy - closing that gap would be very helpful. Obviously the > header is a big one. > > For something like this I would suggest marking it consensus and perhaps > just commenting on any known caveats to help with paper trail. > --94eb2c13ce388f4246054a4ccf0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Martin notes, I think there are a number of things that= need discussion here, but I'm happy to land it as a step in the right = direction.

O= n Thu, Mar 9, 2017 at 5:04 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:

On T= hu, Mar 9, 2017 at 3:50 AM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
hope=
that the people reviewing this will identify new issues where this PR
fell short of meeting their goals.=C2=A0 Is that an acceptable process
here?


I completely agree with this. At this relatively early stage we need to = lean harder into landing stuff and then opening follow-on issues.. right no= w there is a significant body of work that you have to hold in your head &q= uot;I know roughly how this is going to change" to meaningfully use ev= en the editor's copy - closing that gap would be very helpful. Obviousl= y the header is a big one.

For some= thing like this I would suggest marking it consensus and perhaps just comme= nting on any known caveats to help with paper trail.

--94eb2c13ce388f4246054a4ccf0b-- From nobody Thu Mar 9 06:28:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918B5129465 for ; Thu, 9 Mar 2017 06:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 utmpjpKO-yeQ for ; Thu, 9 Mar 2017 06:28:35 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 90124128AC9 for ; Thu, 9 Mar 2017 06:28:35 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id m133so2967383ybb.1 for ; Thu, 09 Mar 2017 06:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i57/qwnLP5jKetZTT3RHL7OMhUeSI7lKLzeysnJoZ1k=; b=cMbKSk9vsUVzbIBtoUsxy1BgSD1MUxvxrSG7Is7NWCXSutjV31fzCFFz9oHSm6wBvZ LqjydT1hmc7HWwrvoYn6SLXYgGRsj0pQlS3aFzSj1Xul9Xe6v4XTQYp6OCoNaZfjJajN H9S67JQbML/y7l8XmLGEOIvCWRmovB6fwekJGnToAOPONtmTNlasmR8EVFGlc6U6dQJ4 12fI9QfufW9gjVVKwqVQqTdfLL0UsUbXlNB1L3aVOU+xTiaRUsxKxOuoSdiGADSt2vJM LTMYujv7Fzj0fXKtq+t4sBcBFzybjeX4KbnpZY7lHDaT9aNW5OZy1EHRetX0oLfV0SPV AppA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i57/qwnLP5jKetZTT3RHL7OMhUeSI7lKLzeysnJoZ1k=; b=mj0ZAfEZQjjefSZEM1EqbhSRdg0Isot5CFZXZCBw8dXgG+4vIaUpch2q3eQwFMzzvc IHsaDYfxh9PUwn9s6omcL8J8oWfbNFbnz21kKJaQc1Syg0tEobI1zEJ20KE54RDEq3Mt OEAfWDRgPXeCGTPw+778+A0RzWmySY4b6Q6iMMcPC+uh3+fDGM0J/ZFKPBklhWQrMQWa DxzXjO6xRFsNTEbz52MbsevG886n9hPwY7lKpYZogikjCmJKWytwviUI0453Umz1wKIS v+AGwaN29udTlehKVTB5SFpuP+L2p2v6dLMYFkK0s0O3LbE4YRrvM7/DE2ymDbSrCANd LH5g== X-Gm-Message-State: AMke39lGx9KHf8KOlGRaMIe+QrV9yDuC51yw3yz4jta5tzxhQ8dfNCGMI1Nh4V4e94JPuu479/rr21uW1Qp9Jm/A X-Received: by 10.37.110.139 with SMTP id j133mr3723696ybc.143.1489069714564; Thu, 09 Mar 2017 06:28:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 06:28:14 -0800 (PST) In-Reply-To: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> From: Ian Swett Date: Thu, 9 Mar 2017 09:28:14 -0500 Message-ID: Subject: Re: Divergence from HTTP/2 To: Stefan Eissing Content-Type: multipart/alternative; boundary=001a1148b49c626480054a4d0f43 Archived-At: Cc: Mike Bishop , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:28:37 -0000 --001a1148b49c626480054a4d0f43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for sending this out to the list. I always hoped we could keep HTTP over QUIC as similar to H2 as possible, but as you've pointed out previously, a lot of HTTP/2 was adding transport features such as multiple streams and flow control on top of an existing transport. Switching to QPACK would be another dramatic departure. I'm not excited about QUIC abandoning HTTP2, but it may make enough technical and documentation sense to be the right thing to do. I am concerned this could expand the scope of the HTTP mapping too much, so if we're going to make this choice, I'd like to know what types of changes are in scope. On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing wrote: > Thanks for separating this out, Mike. For spare time folks this makes > following this aspect easier. > > My first impression is that any hope to have http/2 over tcp and quic > needs to be abandoned. Which will give the world a third protocol to carr= y > http semantics. > > What does that mean for the evolution of http, I wonder. > > -stefan > > Am 09.03.2017 um 03:16 schrieb Mike Bishop = : > > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are > the same protocol. However, the draft currently still attempts to define > them as close cousins. In PR #363 > , I=E2=80=99ve consolidat= ed > almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new= section and > excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC does= n=E2=80=99t need > it=E2=80=9D from the main body of the document. Martin has advocated mak= ing a > clean break from HTTP/2 and defining our own IANA registry for frame type= s > and settings, just as we already have for errors. We can, out of respect > for legacy, use the same values where appropriate and reserve existing > values currently in use on the HTTP/2 side. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from the WG about either would be welcome. > > --001a1148b49c626480054a4d0f43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for sending this out to the list.=C2=A0 I always ho= ped we could keep HTTP over QUIC as similar to H2 as possible, but as you&#= 39;ve pointed out previously, a lot of HTTP/2 was adding transport features= such as multiple streams and flow control on top of an existing transport.= =C2=A0 Switching to QPACK would be another dramatic departure.

I'm not excited about QUIC abandoning HTTP2, but it may make eno= ugh technical and documentation sense to be the right thing to do.=C2=A0 I = am concerned this could expand the scope of the HTTP mapping too much, so i= f we're going to make this choice, I'd like to know what types of c= hanges are in scope.=C2=A0

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
Thanks for separating thi= s out, Mike. For spare time folks this makes following this aspect easier.<= /div>

My first impression is that any hope to have http/= 2 over tcp and quic needs to be abandoned. Which will give the world a thir= d protocol to carry http semantics.

What does that= mean for the evolution of http, I wonder.

-stefan

Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bisho= p@microsoft.com>:

At this point, I don=E2=80=99t think anyone expects = that HTTP/QUIC and HTTP/2 are the same protocol.=C2=A0 However, the draft c= urrently still attempts to define them as close cousins.=C2=A0 In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdiffere= nt from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff = about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D from the main body of the document.=C2=A0 Martin has advocated making a clean break from HTTP/2 = and defining our own IANA registry for frame types and settings, just as we= already have for errors.=C2=A0 We can, out of respect for legacy, use the = same values where appropriate and reserve existing values currently in use on the HTTP/2 side.

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from the WG about either would be welcome.<= u>


--001a1148b49c626480054a4d0f43-- From nobody Thu Mar 9 06:37:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D712112941E for ; Thu, 9 Mar 2017 06:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDQ85W0C4wdR for ; Thu, 9 Mar 2017 06:37:26 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CDC128AC9 for ; Thu, 9 Mar 2017 06:37:26 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id a5so3020403ybb.2 for ; Thu, 09 Mar 2017 06:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AwY0Me4AdecCWHXcEPE/9QfTayDp/UjhTQ/8aVqPqVI=; b=QI6ta+l3q2ov/vIz3tCHcEVv2y9dVfEyybQLYMjOj/6x2H20ADq+ucsDZbaZv0b1WT MhWeGXEvcXpW0njPrHgZ5Ik2n7T7h+CSbnWszYZyaK32OtmM7M+ymxF49iJTtHxeDL+A EsKAo/1/iv4WBIZHpJfKyRDdZvJqDzGUi0Ho+p5MpOZnzX2sLs5SS10kJW6VOl2KfQM3 CqSq1tRFPGvMYMBW+4s1UCAJ9tuTe0n1Wc8ovBq6BeEViXXpecMEcun5MPTKrHCWWiQR Lt65A0uy8x64WnRM/POAUJ1ibb0ZsOQ/ChmLia4Ke/gMX3eUeQfaZEv6a2ZszZiRFiFC XeuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AwY0Me4AdecCWHXcEPE/9QfTayDp/UjhTQ/8aVqPqVI=; b=bXBeNFsjx6vT/BaAyLegwc9XLGE2MN3RIA6Mi1xYsG5qcjztw5dqiG5xtce2mbiACW QuchRd2Cn/oUsJnynhhRk0urdE+VjNlq6xf20JAxGaU8JeVyG3pdveocIKGLsay7il03 InWAAb/DxvAJSnaP2RsJZzUAiTTIi1oE70f6zJ0izKX90tiqDFngEAQQYcyggF4IPRFz iKGPYPhIA0rfhHHATUB3L+m3qFmGtzd2jkKX1qgXwUVPQEeezmAE2bjbd2IblJYWmEnh rYeqkCqOhiazvR6N5sJbSyssLlsUxQDT91JjsDEslGIrooaIP3stC28jJSQvp4ALA+nX fdkw== X-Gm-Message-State: AMke39mR8HGqyxy9eGNUCRLwoQDFYs8V2IesXPy91PGqgJOSRaYBJNwVFhoXRbJbYS3let4vQMb7jr6IwcOp5g== X-Received: by 10.37.173.82 with SMTP id l18mr4308384ybe.107.1489070245431; Thu, 09 Mar 2017 06:37:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 06:36:44 -0800 (PST) In-Reply-To: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> References: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> From: Eric Rescorla Date: Thu, 9 Mar 2017 06:36:44 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Roland Zink Content-Type: multipart/alternative; boundary=f403045eb8ea0655e7054a4d2fc3 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:37:30 -0000 --f403045eb8ea0655e7054a4d2fc3 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 4:28 AM, Roland Zink wrote: > Do I now need to intercept all connections from my TV? > Uh.... yes? More generally, E2E encryption between closed source devices and some network mother ship clearly presents a risk to user privacy and security even in cases where the device isn't compromised. For instance, how much of your recorded voice is being sent back to Amazon via Alexa? It would be nice not to have to trust Amazon about this. We don't really have a good solution for this (I think MITM boxes clearly aren't it), though there's some interesting work coming out of Stanford [0] that tries to address this. -Ekr [0] https://forum.stanford.edu/events/2016/slides/iot/Judson.pdf > > QUIC has the potential to spam the network from user space code. The > network should be able to detect misuse as fast as possible. > > Roland > > > > Am 09.03.2017 um 12:22 schrieb Erik Kline: > >> My 2 yen. >> >> First, I would personally classify middleboxes as any element on the path >> between two communicating endpoints that are not administered by an entity >> that administers one of the endpoints. >> >> To take the case with which I am most familiar: my mobile phone is one >> endpoint, the mobile operator's devices are middleboxes as are all others >> at least until my packets enter the network of the endpoint with which I'm >> communicating. In the remote network, if I'm talking to, say, another >> mobile device then the remote mobile network operator's devices are still >> middleboxes. If on the other hand I'm talking to a monolithic service >> composed of several elements, then those firewalls, load balancers, and so >> forth I would not classify as middleboxes. I would offer up a better term >> for this latter category of devices, but I do not yet have one (they are >> kind of auxiliary/colleague/cooperating boxes). >> >> I think the distinction is important because middleboxes as I've tried to >> define them cannot be presumed to be acting in the best interest of the >> communicating parties. All other boxes might be "fixed" to work well with >> QUIC. Whether the "fixing" necessitates exposing protocol information to >> middleboxes as defined above is, I think, something to be considered on a >> function-by-function basis. >> >> Second, I feel very strongly that whatever is exposed to middleboxes >> should not be easily abused (even by accident) in such a way as to prevent >> seamless connection migration. With a new transport like QUIC there's a >> wonderful opportunity to get this right, and if we fail we won't get to try >> again for many many years I fear. >> > > --f403045eb8ea0655e7054a4d2fc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 4:28 AM, Roland Zink <roland@zinks.de> wrot= e:
Do I now need to intercept all connections from my TV?

Uh.... yes?

More genera= lly, E2E encryption between closed source devices and some network
mother ship clearly presents a risk to user privacy and security even in = cases where
the device isn't compromised. For instance, how m= uch of your recorded voice is
being sent back to Amazon via Alexa= ? It would be nice not to have to trust Amazon
about this. We don= 't really have a good solution for this (I think MITM boxes clearly
aren't it), though there's some interesting work coming out = of Stanford [0] that
tries to address this.

<= div>-Ekr

=C2=A0

QUIC has the potential to spam the network from user space code. The networ= k should be able to detect misuse as fast as possible.

Roland


Am 09.03.2017 um 12:22 schrieb Erik Kline:
My 2 yen.

First, I would personally classify middleboxes as any element on the path b= etween two communicating endpoints that are not administered by an entity t= hat administers one of the endpoints.

To take the case with which I am most familiar: my mobile phone is one endp= oint, the mobile operator's devices are middleboxes as are all others a= t least until my packets enter the network of the endpoint with which I'= ;m communicating.=C2=A0 In the remote network, if I'm talking to, say, = another mobile device then the remote mobile network operator's devices= are still middleboxes.=C2=A0 If on the other hand I'm talking to a mon= olithic service composed of several elements, then those firewalls, load ba= lancers, and so forth I would not classify as middleboxes.=C2=A0 I would of= fer up a better term for this latter category of devices, but I do not yet = have one (they are kind of auxiliary/colleague/cooperating boxes).

I think the distinction is important because middleboxes as I've tried = to define them cannot be presumed to be acting in the best interest of the = communicating parties.=C2=A0 All other boxes might be "fixed" to = work well with QUIC.=C2=A0 Whether the "fixing" necessitates expo= sing protocol information to middleboxes as defined above is, I think, some= thing to be considered on a function-by-function basis.

Second, I feel very strongly that whatever is exposed to middleboxes should= not be easily abused (even by accident) in such a way as to prevent seamle= ss connection migration.=C2=A0 With a new transport like QUIC there's a= wonderful opportunity to get this right, and if we fail we won't get t= o try again for many many years I fear.


--f403045eb8ea0655e7054a4d2fc3-- From nobody Thu Mar 9 06:42:33 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0601512943C for ; Thu, 9 Mar 2017 06:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02wmA0ck13JE for ; Thu, 9 Mar 2017 06:42:28 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0110.outbound.protection.outlook.com [104.47.38.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34266129485 for ; Thu, 9 Mar 2017 06:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JPOuI9SzPStpXKde1SlC8hT1zNhS4WbjztfM5mEhlUA=; b=GRuIzsLwU284JK7DxqeErWY4w5w4IyqB2iaNoYYmS43bnp1NiplRWrgU7NeRVSRQdV0+WViOB4NE63DNA5S7Pkdc2lSsqn8CIY2POGemZM5SD7ezPXoX0pLRECHFHyMK7CJ/STPh/RUedJL2EK7PlhCUzn+xjREVzJAgR1Z762c= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 14:42:26 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 14:42:26 +0000 From: Mike Bishop To: =?Windows-1252?Q?Mirja_K=FChlewind?= , "Lubashev, Igor" Subject: RE: DISINTEREST frame Thread-Topic: DISINTEREST frame Thread-Index: AdKXcDHfunnFPGrnRMK6X50HH8pWcgAO9+SAAAMMFAAAASgWgAAAmhSAAAAT0QAAASltAAAADUSAAAA754AAADmrAAAVSHUAAATbzYAAAEnpgAAAXurgACRcUYAACBuSFg== Date: Thu, 9 Mar 2017 14:42:26 +0000 Message-ID: References: <436570d5fa794f779a74d22d4c975432@usma1ex-dag1mb5.msg.corp.akamai.com> <46a68309730c48e380b1b61055fb9dd2@usma1ex-dag1mb5.msg.corp.akamai.com> <890aa285e7244443a12594c6f399245e@usma1ex-dag1mb5.msg.corp.akamai.com> <07b1d227554f4b57a6da37c6a0a0c811@usma1ex-dag1mb5.msg.corp.akamai.com> , <8ed2217a-e65c-a24f-b192-796e553337f3@tik.ee.ethz.ch> In-Reply-To: <8ed2217a-e65c-a24f-b192-796e553337f3@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none;tik.ee.ethz.ch; dmarc=none action=none header.from=microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [24.16.14.232] x-ms-office365-filtering-correlation-id: 9aaf50f6-245b-4317-7374-08d466fa815a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:Kp+Vk2sXDpnzX7A2ibgDcO9wrexTjo5raBoiWnK0f0fjUSttTwLVD6913lnFO8s/sfP3EqqJfTWWsg7bwX2dkTpCBEkMfhbgIM/mekrtXrlbhd5DbapYkr3Mx14nvnFXIWkFaYLg6Ip6UNQmBuNQXplPaIuCYRUncJ+wPwxs/Iui82CPmf+eWqjBNM1D1tf/SJD7KRr1co9DuVz7WX2WhA8y30GpjuEYbur5K9yzGENobtef25u6StXoNvZZwVNSLgqMJ3xP4Qg3rPL9VI7rBw1qlgzsJOCetzcC9vUXJDJRT+NiDSvkAddE9r9xOSQI6aZAfssGBQBPpoTtTIaRIEyWqHyLK3cOyWfJDtYxcW4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39860400002)(39840400002)(39850400002)(24454002)(377454003)(236005)(55016002)(8936002)(76176999)(33656002)(54896002)(99286003)(8676002)(122556002)(2906002)(8990500004)(50986999)(54356999)(6436002)(6506006)(7736002)(77096006)(229853002)(3280700002)(3846002)(3660700001)(81166006)(3480700004)(9686003)(25786008)(6116002)(102836003)(53936002)(189998001)(7696004)(5005710100001)(66066001)(7116003)(5660300001)(10290500002)(4326008)(221733001)(2900100001)(53546006)(74316002)(2950100002)(86362001)(10090500001)(38730400002)(6246003)(93886004)(9886003)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708402D83876986A2C08A6C87210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 14:42:26.1159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:42:31 -0000 --_000_BN6PR03MB2708402D83876986A2C08A6C87210BN6PR03MB2708namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, because those packets could have contained frames from other streams. = It would totally violate the semantics of ACK and likely break the connecti= on. Sent from my Windows 10 phone From: Mirja K=FChlewind Sent: Thursday, March 9, 2017 2:50 AM To: Mike Bishop; Lubashev, Igor Cc: quic@ietf.org Subject: Re: DISINTEREST frame Okay, that's now a little bit a hack but after sending DISINTEREST you coul= d just acknowledge all data up to the highest packet number you've seen, no matter if you received them or not because you don't need them anymore anynway; that would avoid any retransmissions... Mirja On 08.03.2017 18:53, Mike Bishop wrote: > You=92re correct that the sender of DISINTEREST no longer cares about the= data, > other than for flow control and state consistency. > > > > I had been trying to approach it from a principle that only the sender ca= n > affect the stream state in their direction =96 the receiver can only requ= est > changes. As the draft currently reads, the receiver counts flow control = as > STREAM frames are received, and upon receipt of a RST_STREAM. If a STREA= M > frame is delayed, it doesn=92t (yet) count against the receiver=92s flow = control > window, even if it can infer that the data has been sent (by virtue of > receiving a later offset). Only upon receipt of a RST_STREAM do you acco= unt > all outstanding data against the flow control window. > > > > Changing it so that all data up to the furthest offset received on a stre= am > counts is certainly possible, but feels like an orthogonal change to this > PR. I=92ve opened issue #370 for that. In that world, the requirement w= ould > be to reliably deliver /either/ a RST_STREAM /or/ a STREAM frame with the= FIN > bit set (basically, you MUST communicate your final offset). So long as = one > of those gets through, DISINTEREST by itself could stop retransmissions. > That feels marginally more complicated, since it adds an additional path = to > stop retransmission on a stream and makes the accounting logic on receipt= of > a STREAM frame more complicated. > > > > My inclination is to leave retransmissions tied to having sent RST_STREAM= , > but I=92ll defer to others whether the complexity is worth the potential = savings. > > > > *From:*Lubashev, Igor [mailto:ilubashe@akamai.com] > *Sent:* Wednesday, March 8, 2017 9:19 AM > *To:* Lubashev, Igor ; Ian Swett ; > Martin Thomson > *Cc:* Mike Bishop ; quic@ietf.org > *Subject:* RE: DISINTEREST frame > > > > P.S. > > The paragraph above states: > > > > * [STREAM frames received after sending DISINTEREST] will be discarded > > > > So I read it that the peer who send DISINTEREST will /not/ be waiting for > that data. That peer does not need any accounting for flow control eithe= r, > since he has already received the FIN (with the byte offset) and is alrea= dy > in =93half-closed (remote)=94 or =93closed=94 state. > > > > > > *From:*Lubashev, Igor [mailto:ilubashe@akamai.com] > *Sent:* Wednesday, March 08, 2017 12:10 PM > *To:* Ian Swett >; Marti= n > Thomson > > *Cc:* Michael.Bishop@microsoft.com ; > quic@ietf.org > *Subject:* RE: DISINTEREST frame > > > > * you definitely need "RST_STREAM is sent unless all outstanding data h= as > been sent AND acknowledged.", otherwise the peer waits forever for da= ta > that won't arrive. > > > > > > I guess this is the core of the question, which goes beyond the choice fo= r > this rare condition. =93It is reasonable to think that the peer who sent > DISINTEREST is still waiting for any data?=94 The whole point of DISINTE= REST > is to indicate that =93I am /not/ waiting for any more data=94. > > > > > > *From:*Ian Swett [mailto:ianswett@google.com] > *Sent:* Wednesday, March 08, 2017 9:51 AM > *To:* Martin Thomson > > *Cc:* Lubashev, Igor >; > Michael.Bishop@microsoft.com ; > quic@ietf.org > *Subject:* Re: DISINTEREST frame > > > > Martin's right, you definitely need "RST_STREAM is sent unless all > outstanding data has been sent AND acknowledged.", otherwise the peer wai= ts > forever for data that won't arrive. > > > > Question: Why call it DISINTEREST, instead of REQUEST_RST? It wasn't obv= ious > to me what DISINTEREST was until I read further, whereas REQUEST_RST is > pretty obvious, assuming you know about RST_STREAM. > > > > On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson > wrote: > > On 8 March 2017 at 15:35, Lubashev, Igor > wrote: > > We are taking about a case when the sender of the stream is already= in > > "half-closed (local)" (or "closed") and the receiver is already in > > "half-closed (remote)" (or "closed"). This RST_STREAM will not affe= ct the > > state of the stream for any peer. The only information RST_STREAM c= ontains > > now is "I will not transmit". But the peer already sent DISINTEREST= ED to > > indicate it does not care about retransmissions. > > Even after closing a stream, an endpoint needs to retransmit data. I= t > closes when it first sends the FIN. > > > --_000_BN6PR03MB2708402D83876986A2C08A6C87210BN6PR03MB2708namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

No, because those packets could have contained fra= mes from other streams.  It would totally violate the semantics of ACK= and likely break the connection.

 

Sent from my Windows 10 phone

 

From: Mirja K=FChlewind
Sent: Thursday, March 9, 2017 2:50 AM
To: Mike Bishop;= Lubashev, Igor
Cc: quic@ietf.org
Subject: Re: DISINTEREST frame

 

Okay, that's now a little bit a hack but after sen= ding DISINTEREST you could
just acknowledge all data up to the highest packet number you've seen, no <= br> matter if you received them or not because you don't need them anymore
anynway; that would avoid any retransmissions...

Mirja

On 08.03.2017 18:53, Mike Bishop wrote:
> You=92re correct that the sender of DISINTEREST no longer cares about = the data,
> other than for flow control and state consistency.
>
>
>
> I had been trying to approach it from a principle that only the sender= can
> affect the stream state in their direction =96 the receiver can only r= equest
> changes.  As the draft currently reads, the receiver counts flow = control as
> STREAM frames are received, and upon receipt of a RST_STREAM.  If= a STREAM
> frame is delayed, it doesn=92t (yet) count against the receiver=92s fl= ow control
> window, even if it can infer that the data has been sent (by virtue of=
> receiving a later offset).  Only upon receipt of a RST_STREAM do = you account
> all outstanding data against the flow control window.
>
>
>
> Changing it so that all data up to the furthest offset received on a s= tream
> counts is certainly possible, but feels like an orthogonal change to t= his
> PR.  I=92ve opened issue #370 for that.  In that world, the = requirement would
> be to reliably deliver /either/ a RST_STREAM /or/ a STREAM frame with = the FIN
> bit set (basically, you MUST communicate your final offset).  So = long as one
> of those gets through, DISINTEREST by itself could stop retransmission= s.
> That feels marginally more complicated, since it adds an additional pa= th to
> stop retransmission on a stream and makes the accounting logic on rece= ipt of
> a STREAM frame more complicated.
>
>
>
> My inclination is to leave retransmissions tied to having sent RST_STR= EAM,
> but I=92ll defer to others whether the complexity is worth the potenti= al savings.
>
>
>
> *From:*Lubashev, Igor [mailto:i= lubashe@akamai.com]
> *Sent:* Wednesday, March 8, 2017 9:19 AM
> *To:* Lubashev, Igor <ilubashe@akamai.com>; Ian Swett <ianswe= tt@google.com>;
> Martin Thomson <martin.thomson@gmail.com>
> *Cc:* Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org<= br> > *Subject:* RE: DISINTEREST frame
>
>
>
> P.S.
>
>   The paragraph above states:
>
>
>
>   * [STREAM frames received after sending DISINTEREST] will = be discarded
>
>
>
> So I read it that the peer who send DISINTEREST will /not/ be waiting = for
> that data.  That peer does not need any accounting for flow contr= ol either,
> since he has already received the FIN (with the byte offset) and is al= ready
> in =93half-closed (remote)=94 or =93closed=94 state.
>
>
>
>
>
> *From:*Lubashev, Igor [mailto:i= lubashe@akamai.com]
> *Sent:* Wednesday, March 08, 2017 12:10 PM
> *To:* Ian Swett <ianswett@google.com <mailto:ianswett@google.com>>; Martin
> Thomson <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
> *Cc:* Michael.Bishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>;
> quic@ietf.org <mailto:quic@ietf.or= g>
> *Subject:* RE: DISINTEREST frame
>
>
>
>   * you definitely need "RST_STREAM is sent unless all = outstanding data has
>     been sent AND acknowledged.", otherwise t= he peer waits forever for data
>     that won't arrive.
>
>
>
>
>
> I guess this is the core of the question, which goes beyond the choice= for
> this rare condition. =93It is reasonable to think that the peer who se= nt
> DISINTEREST is still waiting for any data?=94  The whole point of= DISINTEREST
> is to indicate that =93I am /not/ waiting for any more data=94.
>
>
>
>
>
> *From:*Ian Swett [mailto:ianswe= tt@google.com]
> *Sent:* Wednesday, March 08, 2017 9:51 AM
> *To:* Martin Thomson <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
> *Cc:* Lubashev, Igor <ilubashe@akamai.com <mailto:ilubashe@akamai.com>>;
> Michael.Bishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>;
> quic@ietf.org <mailto:quic@ietf.or= g>
> *Subject:* Re: DISINTEREST frame
>
>
>
> Martin's right, you definitely need "RST_STREAM is sent unless al= l
> outstanding data has been sent AND acknowledged.", otherwise the = peer waits
> forever for data that won't arrive.
>
>
>
> Question: Why call it DISINTEREST, instead of REQUEST_RST?  It wa= sn't obvious
> to me what DISINTEREST was until I read further, whereas REQUEST_RST i= s
> pretty obvious, assuming you know about RST_STREAM.
>
>
>
> On Tue, Mar 7, 2017 at 11:41 PM, Martin Thomson <martin.thomson@gma= il.com
> <mailto:martin.thomson@= gmail.com>> wrote:
>
>     On 8 March 2017 at 15:35, Lubashev, Igor <i= lubashe@akamai.com
>     <mai= lto:ilubashe@akamai.com>> wrote:
>     > We are taking about a case when the sende= r of the stream is already in
>     > "half-closed (local)" (or "= ;closed") and the receiver is already in
>     > "half-closed (remote)" (or &quo= t;closed"). This RST_STREAM will not affect the
>     > state of the stream for any peer. The onl= y information RST_STREAM contains
>     > now is "I will not transmit". B= ut the peer already sent DISINTERESTED to
>     > indicate it does not care about retransmi= ssions.
>
>     Even after closing a stream, an endpoint needs= to retransmit data.  It
>     closes when it first sends the FIN.
>
>
>
 --_000_BN6PR03MB2708402D83876986A2C08A6C87210BN6PR03MB2708namp_-- From nobody Thu Mar 9 06:56:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E222812964D for ; Thu, 9 Mar 2017 06:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArftWHPhvquG for ; Thu, 9 Mar 2017 06:56:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD1E12965A for ; Thu, 9 Mar 2017 06:56:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D453DBE47; Thu, 9 Mar 2017 14:56:30 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFzppjMsi6Po; Thu, 9 Mar 2017 14:56:26 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BA687BE6F; Thu, 9 Mar 2017 14:56:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489071386; bh=qA+f7TPtiX2tEbL/SMH+rMwNc0p1gPlLnMQBH0QJdGg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=JvfgAiZHFpP3zb4SSn3/Mq//2YPmLBXikNjZvO8IqK90CRgnCVZxXa49W3wkq0zgh WA4dz7qkr3/KpjIHGAudnzS/5O81XAHWVMuysDlQ7hkne9zg/MG9KiQ4U+HsCHpUwP Cij3pLzgc7fRhJSfGJ9zS0NlsfQ6Bk/YmTNwnsBA= Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla , Roland Zink References: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1f76148a-5688-a54f-fe3c-07405e738d6d@cs.tcd.ie> Date: Thu, 9 Mar 2017 14:56:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uIWk3a3UOsqH2w7WXLOOVrCWllnlFU6SS" Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:56:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uIWk3a3UOsqH2w7WXLOOVrCWllnlFU6SS Content-Type: multipart/mixed; boundary="NNVnpwfC8e2un0gWDecHe0x1hSW5GkWH7"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Roland Zink Cc: IETF QUIC WG Message-ID: <1f76148a-5688-a54f-fe3c-07405e738d6d@cs.tcd.ie> Subject: Re: Middlebox introspection/self-describing packets References: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> In-Reply-To: --NNVnpwfC8e2un0gWDecHe0x1hSW5GkWH7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/03/17 14:36, Eric Rescorla wrote: > aren't it), though there's some interesting work coming out of Stanford= [0] > that > tries to address this. >=20 > -Ekr >=20 > [0] https://forum.stanford.edu/events/2016/slides/iot/Judson.pdf >=20 It's very unclear to me that it's possible to usefully take a two party protocol like TLS and change it into a multiparty protocol without fatal side-effects. As the slide deck [0] notes for example, those "auditors" get access to all cookies/passwords etc. But I hope we can agree that while the problem is real, this is not the WG to try solve that particular problem. S. --NNVnpwfC8e2un0gWDecHe0x1hSW5GkWH7-- --uIWk3a3UOsqH2w7WXLOOVrCWllnlFU6SS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYwW0ZAAoJEC88hzaAX42isVMH/0oNX3t+r5ORrh0HbVAtu+ak JMSxChDanhJ16qovMCNrvY3+VnmE+oxBYkeOWbtrUzlVehhhMx/e4Yug+fEHbvbB KHkiHdi1zWLExSfw2wf+lIZqF9RMQFn8zV3wgBaF0pAkf2W3eAz42rwqKe0w7fz5 JPA4T4hhs2tUMj8uVy71F7tLDpjyeUz7bmxgOVZROok8TreVA+4Z+ak1Rsw7PFP0 6RXBeu8ioa0yxVJHUWCn7sAeNMy9Ivy/ZTeS4hPdgCqgUEsgbvtV7xnTsj7P4+R1 X2Dokt0qVLK2tzYzqGL3Y/iF7lwhWqXw50vVkigFKajvgLuH6wGdIS93h/HA4ZM= =YFTt -----END PGP SIGNATURE----- --uIWk3a3UOsqH2w7WXLOOVrCWllnlFU6SS-- From nobody Thu Mar 9 06:59:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9593F12964D for ; Thu, 9 Mar 2017 06:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RCGaW4pIAIWy for ; Thu, 9 Mar 2017 06:59:51 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF3D129665 for ; Thu, 9 Mar 2017 06:59:51 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id p77so8850324ywg.1 for ; Thu, 09 Mar 2017 06:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bm6rsPPPP7ffDmhhUpjRYN8dWaiyQb9tyWRFtIQEqHQ=; b=YWu9UsGe+5yBWzrcl7FrbnFkK/0+5syNIYkQIbhHcNRiTkKcoaOcH+bjQ9lCudO4OJ eukXQgfNyZrHj7y+IOuvJ+vACNrrTUQ6cDtJ5POOHR7agjnUesaaduiVqvFprmMbXdiY Fi7HhfmzvmHaOIDEzog4Bz4slb8+1/hpvspH0Lyg39HfsiccfdK/rdWGi2jFhXVnJtye CCwyIilYmWaFVr1QRUKT+C06DDE+jSWeNxKh+KriVF7TJAX130+ypJFUhD0xbzPyUuHh xfDbeIJcRZoZBTDbUbnDQJToKa00/nFniXHYnFSxkFbu/WyXnHcumX/wMYRTnhazBPD9 REfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bm6rsPPPP7ffDmhhUpjRYN8dWaiyQb9tyWRFtIQEqHQ=; b=PGqc0TJ1sKYdRHwr3KDbMOpaCOmO3+f97tsG8Ao/RD3j/hGd7fY+7zDcubDGPX3BIx bEJVZz2DT8Y8RIBrLTP+LpLgdHQyBWnyQMzhH2yduAcQB+rAkb2jW1hjB4rV+aUoG9Fh CqWVpi7Z9YIDQLTKgDU+fZu1ZHjfUDhe08fkf0xoeuLMvbROZVvZi4KWn1Vd3WmTpq+E hpHKiHN9ef3L3e72vHMDemBuzfOL5tZZerEUS+36a9/9bX2TwSCacdtRoQD00rsI6Wyp Bbjyen6VFDbnQaQVxN4IkBWPX5OUSXl4yIv+xvAkFwVCrhKUK/BXJYPdZn2k1moIG8HT uRUA== X-Gm-Message-State: AMke39kWXf0s0uHtMMqCM5QRPqbcrgT/fMQ6D47yHnnOQgE3TsxN6Qwa5kJ1vcy4Yl5HVDtmhdMEfI0KJs/24Zwo X-Received: by 10.13.204.88 with SMTP id o85mr4020805ywd.347.1489071590612; Thu, 09 Mar 2017 06:59:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 06:59:30 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Mar 2017 09:59:30 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Martin Duke Content-Type: multipart/alternative; boundary=001a1148248434a589054a4d7f21 Archived-At: Cc: Brian Trammell , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:59:53 -0000 --001a1148248434a589054a4d7f21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 8, 2017 at 6:43 PM, Martin Duke wrote= : > I have a substantially different position on middlebox inspection. First > is the load balancing point, which many people have already made. > > Second, service providers have an interest in (1) measuring the quality o= f > service they provide to customers, (2) enforcing bandwidth limitations, > etc. on users, and (3) identifying application types to provide QoS where > it matters. I think (1) and (2) can be done without a meaningful loss of > privacy, although (3) is highly problematic. To that end, there are a > number of open issues looking to expose some transport state to middlebox= es: > - Packet number echo to allow RTT measurements (#269) > - ECN to allow a non-loss rate-limiting signal (replacing TCP zero-window= ) > (#68) > - Public flag bits to indicate flow-control and loss-detection causes of > throttling, to aid in troubleshooting (#279) - I believe it was someone > from Orange in Tokyo who asked "how am I going to troubleshoot this?" > - Replacing CONNECTION_CLOSE to an authenticated Public Reset to clear > connection state on middleboxes. (#353) > > The first three are the reasons I have in mind for using flags to indicate negotiating connection ID presence and packet number length. If we want to expose any subset of these to pieces of the network besides cooperating load balancers, then we need packet number for #269 and for that we need to know it's size and location. If we don't need any of the first three proposals, then there's no need to have a middlebox parse anything and we should likely negotiate everything. The question about how we're going to troubleshoot QUIC is real for me, since I don't want to be debugging other people's networks for the rest of time. But I'm not completely sure what is and isn't necessary yet. No one has yet demonstrated that any of these are meaningful losses of > privacy. They also require no modifications to the packet itself. > > For all the above reasons I am somewhat concerned about all of the > surreptitious connection-ID changes, but I think all of these features ar= e > valuable regardless of how those discussions turn out. > > On Wed, Mar 8, 2017 at 2:45 PM, Brian Trammell wrote: > >> hi ekr, >> >> The point in this space I'd use is =E2=80=9Cexpose nothing without neces= sity, or >> clear benefit with mutual cooperation of the endpoints, but ensure expos= ed >> information is efficiently usable.=E2=80=9D >> >> > On 8 Mar 2017, at 22:38, Eric Rescorla wrote: >> > >> > There's recently been some back and forth on the headers PR about the >> > value of having packets be self-describing so that middleboxes can par= se >> > them. >> > >> > To take a concrete example, consider the connection_id. In general, it >> seems >> > that mostly packets in a given direction either need connection_ids or >> don't >> > (assuming that the point of connection_id is partly to handle unexpect= ed >> > NAT rebinding.), so this seems like a prime thing to negotiate. Jana >> argued >> > in the PR that the reason to have a bit is to allow middleboxes to kno= w >> how >> > to parse the packet. >> >> Taking the case of Connection ID, specifically, it does seem to be a >> candidate for moving to negotiation, saving one header bit pretty much >> everywhere. Connection ID is designed for load balancers, and one could >> define negotiation to be mandatory on the client side: if the server giv= es >> you a connection ID, then the client MUST return it. Otherwise, any devi= ce >> trying to observe the Connection ID would have to keep the >> has-a-Connection-ID state observed during the negotiation, and it wouldn= 't >> have access to that state when the Connection ID is used during rebindin= g. >> >> In this case, saving the bit costs you the possibility of client-side >> choice on whether to not return the Connection ID, which seems to me to >> violate the mutual cooperation principle. >> >> Cheers, >> >> Brian >> >> >> > >> > It seems like it would be good to come to agreement about our attitude >> towards >> > middlebox inspection. I have been generally taking the position that w= e >> should >> > conceal as much as possible from middleboxes and only expose what is >> needed >> > to make the protocol work (i.e., if possible I would encrypt conn_id >> and packet >> > number). It seems like perhaps not everyone shares that objective, so = I >> thought >> > I would ask what principles other people thought they were adhering to= . >> > >> > Jana? MT? Others? >> > >> > -Ekr >> > >> > >> > >> >> > --001a1148248434a589054a4d7f21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 8, 2017 at 6:43 PM, Martin Duke <martin.h.duke@gmail.com= > wrote:
I hav= e a substantially different position on middlebox inspection. First is the = load balancing point, which many people have already made.

Second, service providers have an interest in (1) measuring the quality = of service they provide to customers, (2) enforcing bandwidth limitations, = etc. on users, and (3) identifying application types to provide QoS where i= t matters. I think (1) and (2) can be done without a meaningful loss of pri= vacy, although (3) is highly problematic. To that end, there are a number o= f open issues looking to expose some transport state to middleboxes:
<= div>- Packet number echo to allow RTT measurements (#269)
- ECN t= o allow a non-loss rate-limiting signal (replacing TCP zero-window) (#68)= =C2=A0
- Public flag bits to indicate flow-control and loss-detec= tion causes of throttling, to aid in troubleshooting (#279) - I believe it = was someone from Orange in Tokyo who asked "how am I going to troubles= hoot this?"
- Replacing CONNECTION_CLOSE to an authenticated= Public Reset to clear connection state on middleboxes. (#353)=C2=A0
<= div>

The first three are th= e reasons I have in mind for using flags to indicate negotiating connection= ID presence and packet number length. =C2=A0 If we want to expose any subs= et of these to pieces of the network besides cooperating load balancers, th= en we need packet number for #269 and for that we need to know it's siz= e and location.

If we don't need any of the fi= rst three proposals, then there's no need to have a middlebox parse any= thing and we should likely negotiate everything.

T= he question about how we're going to troubleshoot QUIC is real for me, = since I don't want to be debugging other people's networks for the = rest of time.=C2=A0 But I'm not completely sure what is and isn't n= ecessary yet.

No one has yet demonstrated that any of these are = meaningful losses of privacy. They also require no modifications to the pac= ket itself.

For all the above reasons I am somewha= t concerned about all of the surreptitious connection-ID changes, but I thi= nk all of these features are valuable regardless of how those discussions t= urn out.

On Wed, Mar 8, 2017 at 2:45 PM, = Brian Trammell <ietf@trammell.ch> wrote:
hi ekr,

The point in this space I'd use is =E2=80=9Cexpose nothing without nece= ssity, or clear benefit with mutual cooperation of the endpoints, but ensur= e exposed information is efficiently usable.=E2=80=9D

> On 8 Mar 2017, at 22:38, Eric Rescorla <ekr@rtfm.com> wrote:
>
> There's recently been some back and forth on the headers PR about = the
> value of having packets be self-describing so that middleboxes can par= se
> them.
>
> To take a concrete example, consider the connection_id. In general, it= seems
> that mostly packets in a given direction either need connection_ids or= don't
> (assuming that the point of connection_id is partly to handle unexpect= ed
> NAT rebinding.), so this seems like a prime thing to negotiate. Jana a= rgued
> in the PR that the reason to have a bit is to allow middleboxes to kno= w how
> to parse the packet.

Taking the case of Connection ID, specifically, it does seem to be a= candidate for moving to negotiation, saving one header bit pretty much eve= rywhere. Connection ID is designed for load balancers, and one could define= negotiation to be mandatory on the client side: if the server gives you a = connection ID, then the client MUST return it. Otherwise, any device trying= to observe the Connection ID would have to keep the has-a-Connection-ID st= ate observed during the negotiation, and it wouldn't have access to tha= t state when the Connection ID is used during rebinding.

In this case, saving the bit costs you the possibility of client-side choic= e on whether to not return the Connection ID, which seems to me to violate = the mutual cooperation principle.

Cheers,

Brian


>
> It seems like it would be good to come to agreement about our attitude= towards
> middlebox inspection. I have been generally taking the position that w= e should
> conceal as much as possible from middleboxes and only expose what is n= eeded
> to make the protocol work (i.e., if possible I would encrypt conn_id a= nd packet
> number). It seems like perhaps not everyone shares that objective, so = I thought
> I would ask what principles other people thought they were adhering to= .
>
> Jana? MT? Others?
>
> -Ekr
>
>
>



--001a1148248434a589054a4d7f21-- From nobody Thu Mar 9 07:07:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69C412966D for ; Thu, 9 Mar 2017 07:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwlAZv8YRnqr for ; Thu, 9 Mar 2017 07:07:27 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E382112966A for ; Thu, 9 Mar 2017 07:07:26 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id y76so123207175qkb.0 for ; Thu, 09 Mar 2017 07:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4qZe3phnXu/XHshze4U6okw8MHsO3oKVV+IjVnTyrCE=; b=PPRFDTk9bNTt3ELohDD4pda6rooVtMg/q0M8GTQ581LBqF3FplFTqJmTHYSUDThuJU xDBDLfp+GhGLM6wCpcYD+Ax0r+ZxeyoAec0Wc9yeBTBmnhmekk+3L4gIqn+To+s3qeXi VtawfMIyS3ozM3k+yXRVNZ8zK9CxVEq0u42eY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4qZe3phnXu/XHshze4U6okw8MHsO3oKVV+IjVnTyrCE=; b=dfXMzjJxyEQijJy1LsWGOUPWcul4fvD3gjklj4vguHWB0x0mQ3vi2LBiza8S1WKa4Z Wckg0rsvC+H01UlXNS4n2jCK25aPboGCfAacYicph/HhnUCURVO/6zCkpSorxNu61Bwn Yd98WfvsnfQpli6lPfXZE9bEI+lY/QmxdgP4JhLRAZbb6wFd3VWBdE29IfH0LwbrUIjM lkIyEbQd+CTUK4vxG5gIyUBKtU7SrBAjxehH4zGvp3D+qXl3RY9l5xz6+337BWjj34qL apDjygs1pl2rripgayc2Jo6KrwOQiuTjCSxWFFG5BntSYV6qmwdpr84P3MSWJn7iuShd scDw== X-Gm-Message-State: AMke39mImlZ7ultOS1VMowcX15dfDurleJTKH6tFIL0Cw6YfMzfrSgFNegJHB7PT/GRr0/SCNGVZGQAuxC9qiw== X-Received: by 10.55.47.4 with SMTP id v4mr14195232qkh.77.1489072045749; Thu, 09 Mar 2017 07:07:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Thu, 9 Mar 2017 07:07:25 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: From: Kyle Rose Date: Thu, 9 Mar 2017 10:07:25 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114f41085512a6054a4d9a6f Archived-At: Cc: "Brian Trammell \(IETF\)" , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:07:29 -0000 --001a114f41085512a6054a4d9a6f Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 9:02 AM, Eric Rescorla wrote: > The load balancer needs it to balance load efficiently. > > > That's not entirely clear. Note that in the original QUIC design, the > client supplied > the connection ID, so the server side merely had to load balance based on > some combination > of a random value and the client's IP. > That too-tightly constrains load balancing. Without connection tracking (which means shared state across multiple machines in a farm of load balancers) or a server-chosen cookie, you're limited to algorithms that are a function of connection ID and 5-tuple. In particular, you can't choose a target server based on its current load. Random assignment may be good enough for some application profiles, but not all. Kyle --001a114f41085512a6054a4d9a6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 9:02 AM, Eric Rescorla <ekr@rtfm.com> wrote:
The load balancer needs it to balance load efficient= ly.

That's not entirely clear= . Note that in the original QUIC design, the client supplied
the = connection ID, so the server side merely had to load balance based on some = combination
of a random value and the client's IP.

That too-tightly constrains l= oad balancing. Without connection tracking (which means shared state across= multiple machines in a farm of load balancers) or a server-chosen cookie, = you're limited to algorithms that are a function of connection ID and 5= -tuple. In particular, you can't choose a target server based on its cu= rrent load. Random assignment may be good enough for some application profi= les, but not all.

Kyle

--001a114f41085512a6054a4d9a6f-- From nobody Thu Mar 9 07:07:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F74C129679 for ; Thu, 9 Mar 2017 07:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOuO5xsdrBwL for ; Thu, 9 Mar 2017 07:07:46 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE7312967A for ; Thu, 9 Mar 2017 07:07:46 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id d88so3263219ybi.0 for ; Thu, 09 Mar 2017 07:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6fbJdUJ/a7tf1yl9IVHx8aYPe5sF9fA4xIBFOQXLdwM=; b=cIgs1G0FO13qV/9BWLoKzl2827OizkkQrtZfNXG7VUiFq0Gga/r6tUkxUgAdQvbB9u jK0bBkMUuJfkhYhmGXEQtp4FVnzZdlGx3R7tLf6TQBIi0qdWHWDi4+deW+dFB2g2prIR /M6OKlmdY00y1FRTVxGZRULj9ciiHTSnqKVSvhtIr7x3hWHrkCtu2k4ndDDMQbatiGwC 7m6z86tnXNH/fZQXD4WXYyVFfrhGSthDmEhAiG1sG1LLRiOvVvacKVqYnRWmk/JoQLi9 kjkVYn9DMqCB0Xw6Yftyd2JL0mS3NLNINrA272AeLr6igXyYjI9nhfQqDIN6ncpRlt4v FPVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6fbJdUJ/a7tf1yl9IVHx8aYPe5sF9fA4xIBFOQXLdwM=; b=OH7YDwBXk8E9LE5DbGepvb6exunNTNvTVRhyT7b0tf4u/tJ8llmB664UnkcY8Z7R5Q mpU8+51KNzMDX5cBg6lod6+IkJ0XTJHE7WwYBLiHsDIgU8f7TyxXW/j8iWR05fNKZ38f RLEWr3CMToUOQTtV7hWYz+bEDF6mC47t0Cha62J+MnCn9U/oZpnx1n0FPZUpuf5IG3XA oA9jqgQN7srVJKPLPqIFLNgzqE4YYJFLPxzhBiozpb7nDyR2azJyAK7AR0pAfId+urst A9rRncpvt7+OKHG+sIOJQlWCWR/j3MGPI9z+QEpraxPkvmlSy0P3YoHTi/k88HSmRQ1W ZhaQ== X-Gm-Message-State: AMke39m4l/vUS2s7yjTRSGo2AcHLyy2qZPL5CHejPl4hujbOu6ackuNTbE6JvkZV1Y9gI1xL8L+1yt0idcuqmw== X-Received: by 10.37.201.196 with SMTP id z187mr4317800ybf.161.1489072065573; Thu, 09 Mar 2017 07:07:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 07:07:04 -0800 (PST) In-Reply-To: <1f76148a-5688-a54f-fe3c-07405e738d6d@cs.tcd.ie> References: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> <1f76148a-5688-a54f-fe3c-07405e738d6d@cs.tcd.ie> From: Eric Rescorla Date: Thu, 9 Mar 2017 07:07:04 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114d88ea84c376054a4d9b82 Archived-At: Cc: IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:07:48 -0000 --001a114d88ea84c376054a4d9b82 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 6:56 AM, Stephen Farrell wrote: > > > On 09/03/17 14:36, Eric Rescorla wrote: > > aren't it), though there's some interesting work coming out of Stanford > [0] > > that > > tries to address this. > > > > -Ekr > > > > [0] https://forum.stanford.edu/events/2016/slides/iot/Judson.pdf > > > > It's very unclear to me that it's possible to usefully > take a two party protocol like TLS and change it into a > multiparty protocol without fatal side-effects. As the > slide deck [0] notes for example, those "auditors" get > access to all cookies/passwords etc. > Sorry, I should have been clearer that I wasn't endorsing this strategy. That's what the juxtaposition of "don't really have a good solution" with "interesting work" was intended to convey, but I guess I could have been more explicit. I think there are a number of technical challenges here: - TLS is a fairly blunt tool that protects nothing or everything - The Web has tended to do a really bad job of separating authentication from confidentiality (and in general supplying authentication via confidentiality through various kinds of bearer tokens) I do think it's important that people keep thinking about it, because the problem of devices that are nominally under your control being hard to trust is also serious. That doesn't mean that we currently have a good strategy for solving it. But I hope we can agree that while the problem is real, > this is not the WG to try solve that particular problem. > Yes. -Ekr > > S. > > --001a114d88ea84c376054a4d9b82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 9, 2017 at 6:56 AM, Stephen Farrell <stephen.farrell@c= s.tcd.ie> wrote:


On 09/03/17 14:36, Eric Rescorla wrote:
> aren't it), though there's some interesting work coming out of= Stanford [0]
> that
> tries to address this.
>
> -Ekr
>
> [0] https://forum.stanford.edu/events/2016/slides/iot/Judson.pdf
>

It's very unclear to me that it's possible to usefully
take a two party protocol like TLS and change it into a
multiparty protocol without fatal side-effects. As the
slide deck [0] notes for example, those "auditors" get
access to all cookies/passwords etc.

So= rry, I should have been clearer that I wasn't endorsing this strategy. = That's
what the juxtaposition of "don't really have = a good solution" with "interesting
work" was inten= ded to convey, but I guess I could have been more explicit.
I thi= nk there are a number of technical challenges here:

- TLS is a fairly blunt tool that protects nothing or everything
- The Web has tended to do a really bad job of separating authentication<= /div>
=C2=A0 =C2=A0from confidentiality (and in general supplying authe= ntication via confidentiality
=C2=A0 =C2=A0through various kinds = of bearer tokens)

I do think it's important th= at people keep thinking about it, because the
problem of devi= ces that are nominally under your control being hard to trust
is = also serious. That doesn't mean that we currently have a good strategy<= /div>
for solving it.


But I hope we can agree that while the problem is real, this is not the WG to try solve that particular problem.

Yes.

-Ekr
=C2=A0
=

S.


--001a114d88ea84c376054a4d9b82-- From nobody Thu Mar 9 07:08:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E862129679 for ; Thu, 9 Mar 2017 07:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt-aeKORtbdN for ; Thu, 9 Mar 2017 07:08:49 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D955312966A for ; Thu, 9 Mar 2017 07:08:48 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id o4so9020354ywd.3 for ; Thu, 09 Mar 2017 07:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wlbYY4iX6zFdTpIloa7XHhGX84DgnAVxawo9xDtYLoc=; b=fe5wt5fIktRd//7WNjodk9DnQEJ9sRYExl0x74c3kEuGmq55PDc8gqfPMWCN3feT13 Kg3yHY3+3NkjLofWJD+H47sA8x/a2KJs8RBtgOtAvYMGI2taQZNBpynebquFVXQPNmJY rnG5bsBXobjNwDn0l2vkyQRp9BMp6yWvBmkz0QmfL55KRfaH/IsqUmcMIcgDpMfVtcAo n1N8bGWEcSw9NuOs2rmNKXBAyZhRFCdHAnhyhP+eJhKuqJ2EFj6BUmKs/l29xk52z3bG cg6MHLU43RwPvQOOyqvcvx3yww61ySwsaUTNuGj4dwxV74pZtEAOHNEebJ7IINGdiQ4i qqtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wlbYY4iX6zFdTpIloa7XHhGX84DgnAVxawo9xDtYLoc=; b=CvH/1YKD+ITurm6XvKaZTTIe9xuwlTeaV7XWqVWk0zvsvDKRV9qLKZU+WXMQBPw1CM o0w0ECFsFm5dtCpxYEWHPzrdWQxEkmoK2NAjrhlPdarvqUvq4Rm0tIRCxaArmBT4l8ec eoE98cZVUG+z8PMJzmN4ZQjfW5ZrcsjkzuZU44XpbrkOZUqC7vHR3HgqFPGrCCIEwNep abf+HycO/waM17ZPFkUd3twfEOO61Kes2i2poGh7Jm3Bckik9BCJKhedoPejWK12XiO3 iglLrbIsT6XL/2WqgaV6PF74HuQgJROQCJU2BTJef6ci1jwjb2SfoGwI05aD9HcxbAl9 6fpw== X-Gm-Message-State: AMke39mHQJb5Bjh/HuRwJkgJXw6UrEukxMcJfsmczwYJ7x/SpO+ZRYz9AVS6SCzj2x8XrOCAlVaIm0VCifvs2A== X-Received: by 10.129.92.2 with SMTP id q2mr4096247ywb.87.1489072127980; Thu, 09 Mar 2017 07:08:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 07:08:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 07:08:07 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose Content-Type: multipart/alternative; boundary=001a114d6f163bfaff054a4d9f04 Archived-At: Cc: "Brian Trammell \(IETF\)" , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:08:51 -0000 --001a114d6f163bfaff054a4d9f04 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 7:07 AM, Kyle Rose wrote: > On Thu, Mar 9, 2017 at 9:02 AM, Eric Rescorla wrote: > >> The load balancer needs it to balance load efficiently. >> >> >> That's not entirely clear. Note that in the original QUIC design, the >> client supplied >> the connection ID, so the server side merely had to load balance based on >> some combination >> of a random value and the client's IP. >> > > That too-tightly constrains load balancing. Without connection tracking > (which means shared state across multiple machines in a farm of load > balancers) or a server-chosen cookie, you're limited to algorithms that are > a function of connection ID and 5-tuple. In particular, you can't choose a > target server based on its current load. Random assignment may be good > enough for some application profiles, but not all. > Well, that may be true, but I'm merely observing that that's the present design of gQUIC. -Ekr > > Kyle > > --001a114d6f163bfaff054a4d9f04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 7:07 AM, Kyle Rose <krose@krose.org> wrote:
On Thu, Mar 9, 2017= at 9:02 AM, Eric Rescorla <ekr@rtfm.com> wrote:
The= load balancer needs it to balance load efficiently.

That's not entirely clear. Note that in the original QUIC desi= gn, the client supplied
the connection ID, so the server side mer= ely had to load balance based on some combination
of a random val= ue and the client's IP.

That too-tightly constrains load balancing. Without connect= ion tracking (which means shared state across multiple machines in a farm o= f load balancers) or a server-chosen cookie, you're limited to algorith= ms that are a function of connection ID and 5-tuple. In particular, you can= 't choose a target server based on its current load. Random assignment = may be good enough for some application profiles, but not all.
<= /div>

Well, that may be true, but I&#= 39;m merely observing that that's the present design of gQUIC.

-Ekr

<= span class=3D"HOEnZb">

<= span class=3D"HOEnZb">
Kyle


--001a114d6f163bfaff054a4d9f04-- From nobody Thu Mar 9 07:25:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9901295E5 for ; Thu, 9 Mar 2017 07:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgdBbFeDYyX3 for ; Thu, 9 Mar 2017 07:25:32 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A311294A5 for ; Thu, 9 Mar 2017 07:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D9uMJHpMducjbnxEjEtFrXyvdOU91jpTpMgFIF1YWnM=; b=EgXirf42mKRYC9tcvUhfASqtkQofUmvCkYuUi28u/4AVz5r1yuscbkD7sfAahd3U09me78n43fb4JXyDqTX2O8uw3LZM2K7YJ5/962hmrOtyv7bTgGuMs25PksWK07geHQVJVWNsQd9ZhsibYywUth8Q7m06rtv9ZS97hx4n8xk= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 15:25:29 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 15:25:29 +0000 From: Mike Bishop To: Ian Swett , Hannes Tschofenig Subject: RE: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Topic: UDP Usage and draft-kuehlewind-quic-applicability-00 Thread-Index: AdKYwCv+WlyzFqftRk6FS9cmOv7E4QAA9S0AAAAI+ZAAAR6FgAACcwqAAAAtXyAAADMKAAAFVpVQ Date: Thu, 9 Mar 2017 15:25:29 +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: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8300:3b9a:d0ce:a235:e7d3:26cc] x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 8b3c140f-1c03-46d9-abf8-08d46700852c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:6m9R4G+Se+P07O9KSRCk1zCjUZnQ/w33Aat3ahxa5TjkfGZOar0EA/FolR+u7dSyCihjh/UrdO0oVgZZEcXEioT7oDHrnmV1hOZkVW2Uq1XjqCegd9tjauchh+iBTVoZPc+sfdLooE4s/beoG+/PyePbhjdr8JEdFVPxCyzpHKTTMiJYT8CRdB4d2qZBl3JPB5aywyy8NcOqPN4s7u6FWCD981Ly3s5PjC5VpbrCA7/q0faosFW4IB3Le1DMiN7gv59wqzYgxKmIMusZKr/JHpeE1Ym7Dheposez7CLHsh8XLvXPgmrTelyZVlche4AdBeYKXcpjMvG50lWX/ZGSR9fUMzktTuOag/pcJmkx+1s= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(40434004)(377454003)(24454002)(10090500001)(122556002)(53936002)(2906002)(7906003)(790700001)(33656002)(3280700002)(189998001)(6116002)(38730400002)(7736002)(230783001)(74316002)(102836003)(6246003)(8990500004)(5005710100001)(10290500002)(55016002)(2900100001)(7696004)(6306002)(54906002)(99286003)(81166006)(3660700001)(5660300001)(54896002)(53546006)(236005)(2950100002)(9686003)(50986999)(77096006)(8676002)(229853002)(25786008)(19609705001)(86362001)(6506006)(76176999)(4326008)(93886004)(5890100001)(86612001)(606005)(8936002)(6436002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708452E115EE4EC21233EFD87210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 15:25:29.5697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: "Brian Trammell \(IETF\)" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:25:34 -0000 --_000_BN6PR03MB2708452E115EE4EC21233EFD87210BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGFydCBvZiBtZSB3b25kZXJzIHdoZXRoZXIgUVVJQyB3aWxsIHdpbmQgdXAgcnVubmluZyBvdmVy IHBvcnQgNTMgZm9yIHRoZSBzYW1lIHJlYXNvbiB0aGF0IGV2ZXJ5IHByb3RvY29sIGluIHRoZSB3 b3JsZCBzZWVtcyB0byBydW4gb3ZlciBUTFMgb24gVENQIHBvcnQgNDQzLiAgOy0pDQoNCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dl dHQNClNlbnQ6IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDQ6NTIgQU0NClRvOiBIYW5uZXMgVHNj aG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4NCkNjOiBCcmlhbiBUcmFtbWVsbCAo SUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogVURQ IFVzYWdlIGFuZCBkcmFmdC1rdWVobGV3aW5kLXF1aWMtYXBwbGljYWJpbGl0eS0wMA0KDQoNCk9u IFRodSwgTWFyIDksIDIwMTcgYXQgNzo0OCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+PiB3cm90 ZToNCkhpIElhbiwNCg0KDQo+ICBZZXMsIG15IHRhbGsgd2FzIGluIEJlcmxpbiAyMDE2IGF0IFRT ViBPcGVuKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ni9hZ2VuZGEvdHN2 YXJlYS8pLiAgSSBzZW50IE1pcmphIGEgUERGIGNvcHkgb2YgdGhlIHNsaWRlcywgYnV0IEknbSBu b3Qgc3VyZSB3aGVyZSB0aGV5IGFyZSBwb3N0ZWQuDQoNCkZvdW5kIHRoZW0gYXQgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni10c3ZhcmVhLTIucGRm DQoNCg0KPiAgVG8gc2Vjb25kIHdoYXQgQnJpYW4gc2FpZCwgbW9zdCAnbmV0d29ya3MnIHdoaWNo IGJsb2NrIFFVSUMgYXJlIGNvcnBvcmF0aW9ucyB0aGF0IGFyZSBsYXJnZSBlbm91Z2ggdG8gaGF2 ZSB0aGVpciBvd24gQVMgbnVtYmVyLiAgSSd2ZSBuZXZlciBmb3VuZCBhIG1ham9yIElTUCB0aGF0 IGJsb2NrcyBVRFAgNDQzLg0KDQpIYXZlIHlvdSB0ZXN0ZWQgdGhlIHJlc3VsdHMgb2YgdXNpbmcg VURQIG9uIHBvcnRzIG90aGVyIHRoYW4gNDQzIGFuZCB3aGV0aGVyIHRoZSBibG9ja2luZyByYXRl IGluY3JlYXNlcz8NCg0KDQpXZSBoYXZlIHNvbWUgZGF0YSBmcm9tIGFib3V0IDQgeWVhcnMgYWdv IG9uIHRoaXMsIGJ1dCBJIGRvbid0IGhhdmUgaXQgZWFzaWx5IGF2YWlsYWJsZS4gIEkgZG9uJ3Qg cmVtZW1iZXIgNDQzIGJlaW5nIGRyYW1hdGljYWxseSBtb3JlIG9wZW4gdGhhbiBvdGhlciBwb3J0 cy4gIEluIGdlbmVyYWwsIGl0IHNlZW1lZCBVRFAgZWl0aGVyIHdhcyBibG9ja2VkIG9yIHdhc24n dC4NCg0KQ2lhbw0KSGFubmVzDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0 aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Us IG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlv dS4NCg0K --_000_BN6PR03MB2708452E115EE4EC21233EFD87210BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t LTc1NDI4NTkwMDA1NzUxNDQ0MzNtc29saXN0cGFyYWdyYXBoLCBsaS5tLTc1NDI4NTkwMDA1NzUx NDQ0MzNtc29saXN0cGFyYWdyYXBoLCBkaXYubS03NTQyODU5MDAwNTc1MTQ0NDMzbXNvbGlzdHBh cmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXy03NTQyODU5MDAwNTc1MTQ0NDMzbXNvbGlzdHBh cmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5QYXJ0IG9mIG1lIHdvbmRlcnMgd2hldGhlciBRVUlDIHdpbGwgd2lu ZCB1cCBydW5uaW5nIG92ZXIgcG9ydCA1MyBmb3IgdGhlIHNhbWUgcmVhc29uIHRoYXQgZXZlcnkg cHJvdG9jb2wgaW4gdGhlIHdvcmxkIHNlZW1zIHRvIHJ1biBvdmVyIFRMUyBvbiBUQ1AgcG9ydCA0 NDMuJm5ic3A7IDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCA5LCAy MDE3IDQ6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMu VHNjaG9mZW5pZ0Bhcm0uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gVHJhbW1lbGwgKElF VEYpICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0OzsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogVURQIFVzYWdlIGFuZCBkcmFmdC1rdWVobGV3aW5kLXF1aWMtYXBwbGljYWJp bGl0eS0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1h ciA5LCAyMDE3IGF0IDc6NDggQU0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWls dG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkhhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBJYW4sDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0ibS03NTQyODU5MDAwNTc1MTQ0NDMzbXNvbGlzdHBhcmFncmFwaCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+w5g8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPlllcywgbXkgdGFs ayB3YXMgaW4gQmVybGluIDIwMTYgYXQgVFNWIE9wZW4oPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzk2L2FnZW5kYS90c3ZhcmVhLyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ni9hZ2VuZGEvdHN2YXJlYS88 L2E+KS4mbmJzcDsgSSBzZW50IE1pcmphIGEgUERGIGNvcHkgb2YgdGhlIHNsaWRlcywgYnV0DQog SSdtIG5vdCBzdXJlIHdoZXJlIHRoZXkgYXJlIHBvc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm91bmQgdGhlbSBhdA0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni10c3Zh cmVhLTIucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVk aW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LXRzdmFyZWEtMi5wZGY8L2E+IDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Im0tNzU0Mjg1OTAwMDU3NTE0NDQzM21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0Qi PsOYPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj5UbyBzZWNvbmQgd2hh dCBCcmlhbiBzYWlkLCBtb3N0ICduZXR3b3Jrcycgd2hpY2ggYmxvY2sgUVVJQyBhcmUgY29ycG9y YXRpb25zIHRoYXQgYXJlIGxhcmdlIGVub3VnaCB0byBoYXZlIHRoZWlyIG93biBBUyBudW1iZXIu Jm5ic3A7IEkndmUgbmV2ZXIgZm91bmQgYSBtYWpvciBJU1AgdGhhdCBibG9ja3MgVURQIDQ0My48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhh dmUgeW91IHRlc3RlZCB0aGUgcmVzdWx0cyBvZiB1c2luZyBVRFAgb24gcG9ydHMgb3RoZXIgdGhh biA0NDMgYW5kIHdoZXRoZXIgdGhlIGJsb2NraW5nDQogcmF0ZSBpbmNyZWFzZXM/IDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSBoYXZlIHNvbWUgZGF0YSBmcm9tIGFib3V0IDQgeWVhcnMgYWdvIG9u IHRoaXMsIGJ1dCBJIGRvbid0IGhhdmUgaXQgZWFzaWx5IGF2YWlsYWJsZS4mbmJzcDsgSSBkb24n dCByZW1lbWJlciA0NDMgYmVpbmcgZHJhbWF0aWNhbGx5IG1vcmUgb3BlbiB0aGFuIG90aGVyIHBv cnRzLiZuYnNwOyBJbiBnZW5lcmFsLCBpdCBzZWVtZWQgVURQIGVpdGhlciB3YXMgYmxvY2tlZCBv ciB3YXNuJ3QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNpYW88L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IYW5uZXM8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzDQogdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708452E115EE4EC21233EFD87210BN6PR03MB2708namp_-- From nobody Thu Mar 9 07:28:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FC7129D39 for ; Wed, 22 Feb 2017 16:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88-Gv1Rbq8Jb for ; Wed, 22 Feb 2017 16:30:39 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74538129D29 for ; Wed, 22 Feb 2017 16:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UfpXBQOpWJIq5Er+rl0tEij9SYxYHNCntR8J6jLEPPs=; b=E0WAteQr8BAQwuzyT9GrAIbNiA96gsAYRUy311nUfZ1j0KoorOdzDC/ga2AqZ822exFQ/cHnJPoxoEHU3NJI3y5+mS9MHLDVSfY3PKy1pRdjH3tUs05NbD+aR/L6n5BDmXgl7CxB/6LG6x4LfHCu6hUDg/6kL3pCfQObNyKWG6I= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 00:30:36 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 00:30:36 +0000 From: Mike Bishop To: Jana Iyengar , Phillip Hallam-Baker Subject: RE: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Topic: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Index: AQHSjOEdDzxr00Ts+EONPowXtDkG56F1RM/QgAA9agCAAC0sAIAADnzw Date: Thu, 23 Feb 2017 00:30:35 +0000 Message-ID: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::51f] x-ms-office365-filtering-correlation-id: 9cc36ca0-da50-4c86-b018-08d45b832f90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:AgSUwaB2pn1fCsnuXPzfzawErClUpaFZ8p72uh8aa/zNRANY1wRhkRJBa0Jgxxi3UInFeEu3bpgVFfD8BcLJoWqTn8WHJry5xNK5U7YxVSRCbc7VNKxIqmi07oz64TZ3qFzZFsOnrxU6qcews9cjqCWWeJM4UX5rMiHwaU8IT/DZMvi39+lCNsyt/usM6Xp2REc/s2us0GcqsFGw4Opz7+MP/S2FDcmR5pw5Qub4uxG5YZ3OMcGqEJyu/r18wi0iapkCRv4LptBa1oqAGRpU8jJnnlUuIMl8clnMxiOm5U7SHL0lSMtwJcfhAaVSIPLQOifES5WOsqaZf8ucQXIMDuQNeQ0FrI3QZg+hPG2c48s= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(24454002)(377454003)(129404003)(377424004)(13464003)(122556002)(7696004)(4326007)(53936002)(86612001)(10710500007)(229853002)(6246003)(3660700001)(53386004)(6436002)(790700001)(92566002)(3280700002)(2906002)(86362001)(38730400002)(5660300001)(6506006)(16799955002)(19609705001)(7110500001)(102836003)(189998001)(6116002)(8990500004)(8676002)(5005710100001)(53546006)(50986999)(10290500002)(7906003)(10090500001)(93886004)(76176999)(106116001)(54896002)(7416002)(8936002)(33656002)(230783001)(54356999)(2950100002)(7736002)(2420400007)(606005)(9686003)(99286003)(6306002)(55016002)(74316002)(54906002)(14971765001)(77096006)(15650500001)(81166006)(25786008)(236005)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A4A502E865333337CE6087530BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 00:30:35.8984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-Mailman-Approved-At: Thu, 09 Mar 2017 07:28:01 -0800 Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , "Bob Briscoe \(ietf@bobbriscoe.net\)" , Ingemar Johansson S , "mirja.kuehlewind@tik.ee.ethz.ch" , marcelo bagnulo braun , Piers O'Hanlon , IETF QUIC WG , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:30:42 -0000 --_000_BN6PR03MB2708A4A502E865333337CE6087530BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIFBIQuKAmXMgY29tbWVudCBhcyBhIHR5cGljYWxseS1zYXJjYXN0aWMgd2F5IG9mIHNh eWluZyB0aGF0IHRoZSBJbnRyb2R1Y3Rpb24gb2YgdGhpcyBkcmFmdCBhc3N1bWVzIHF1aXRlIGEg Yml0IG9mIGtub3dsZWRnZSB0aGF0IGlzIHBlcmhhcHMgYmVzdCBzcGVsbGVkIG91dCB3aXRoIHNv bWUgcmVsZXZhbnQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcy4gIFRoYXQgaXMsIGFmdGVyIGFsbCwg dGhlIHBvaW50IG9mIGFuIGludHJvZHVjdGlvbi4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmEgSXllbmdhcg0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAyMiwgMjAxNyAzOjM3IFBNDQpUbzogUGhpbGxpcCBIYWxsYW0tQmFrZXIg PHBoaWxsQGhhbGxhbWJha2VyLmNvbT4NCkNjOiAnZ29ycnlAZXJnLmFiZG4uYWMudWsnIChnb3Jy eUBlcmcuYWJkbi5hYy51aykgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPjsgQm9iIEJyaXNjb2UgKGll dGZAYm9iYnJpc2NvZS5uZXQpIDxpZXRmQGJvYmJyaXNjb2UubmV0PjsgSW5nZW1hciBKb2hhbnNz b24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyBtaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoOyBtYXJjZWxvIGJhZ251bG8gYnJhdW4gPG1hcmNlbG9AaXQudWMzbS5l cz47IFBpZXJzIE8nSGFubG9uIDxwaWVycy5vaGFubG9uQGNzLm94LmFjLnVrPjsgSUVURiBRVUlD IFdHIDxxdWljQGlldGYub3JnPjsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUpIDxrb2Vu LmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+DQpTdWJqZWN0OiBSZTogRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dA0K DQpPbiBXZWQsIEZlYiAyMiwgMjAxNyBhdCAxMjo1NSBQTSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIg PHBoaWxsQGhhbGxhbWJha2VyLmNvbTxtYWlsdG86cGhpbGxAaGFsbGFtYmFrZXIuY29tPj4gd3Jv dGU6DQpUaGlzIGlzIHRoZSBlbnRpcmV0eSBvZiB0aGUgaW50cm9kdWN0aW9uOg0KDQogICBFQ04g c3VwcG9ydCBpbiB0cmFuc3BvcnQgcHJvdG9jb2xzIGlzIGEgZnVuZGFtZW50YWwgZmVhdHVyZSB0 aGF0DQogICBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIFFVSUMgc3BlY2lmaWNhdGlvbiBhcyBh IG1hbmRhdG9yeSBlbGVtZW50Lg0KICAgVGhlIGJlbmVmaXRzIG9mIEVDTiBpcyBkZXNjcmliZWQg aW4gW0ktRC5pZXRmLWFxbS1lY24tYmVuZWZpdHNdLiAgVGhlDQogICBFQ04gc3VwcG9ydCBzaG91 bGQgYmUgaW1wbGVtZW50ZWQgdG8gc3VwcG9ydCBib3RoIHByZXNlbnQgYW5kIGZ1dHVyZQ0KICAg RUNOLCB0aGUgbGF0dGVyIGlzIG91dGxpbmVkIGluIFtJLUQuaWV0Zi10c3Z3Zy1lY24tZXhwZXJp bWVudGF0aW9uXSwNCiAgIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3QgaXMgdGhlIGFiaWxpdHkgdG8g ZGlzY3JpbWluYXRlIGJldHdlZW4gY2xhc3NpYw0KICAgRUNOIGFuZCBMNFMgRUNOIGJ5IG1lYW5z IG9mIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIHRoZSB1c2Ugb2YgdGhlDQogICBFQ1QoMCkgYW5k IEVDVCgxKSBjb2RlIHBvaW50cy4gIFRoaXMgZHJhZnQgZG9lcyBob3dldmVyIG5vdCBkZWx2ZQ0K ICAgaW50byB0aGUgZGV0YWlscyBvZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGltcGxlbWVudGF0 aW9uLg0KDQpJIGhhdmUgYWJzb2x1dGVseSBubyBpZGVhIHdoYXQgRUNOIGlzLiBJIGFtIG9wcG9z ZWQgdG8gdGhlIFdHIHNwZW5kaW5nIGFueSB0aW1lIG9uIEVDTiB1bnRpbCBpdCBjYW4gYmUgZXhw bGFpbmVkIGluIHRlcm1zIHRoYXQgZG8gbm90IHJlZmVyZW5jZSB5ZXQgbW9yZSBqYXJnb24uDQoN CkhhcHB5IHRvIGhlbHAuIEVDTiBpcyBkZWZpbmVkIGluIFJGQyAzMTY4PGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmMzMTY4PiwgYW5kIGlzIGFuIGV4cGxpY2l0IHNpZ25hbCBmcm9tIHRo ZSBhIG5ldHdvcmsgc3dpdGNoIG9yIHJvdXRlciBhYm91dCBjb25nZXN0aW9uIGF0IGEgbGluaywg c28gdGhhdCBlbmRwb2ludHMgY2FuIHVzZSB0aGlzIHNpZ25hbCBpbnN0ZWFkIG9mIGxvc3MgZm9y IGRldGVjdGluZyBhbmQgcmVhY3RpbmcgdG8gY29uZ2VzdGlvbi4gVGhlIGJlbmVmaXRzIG9mIGRv aW5nIHRoaXMgYXJlIGRvY3VtZW50ZWQgaW50IGhlIEktRCB0aGF0IGlzIGxpbmtlZCBpbiB0aGUg YWJzdHJhY3QuIEVDTiBoYXMgYmVlbiBhIHByZXR0eSBzaWduaWZpY2FudCB0aGluZyBpbiB0cmFu c3BvcnQgZm9yIGFib3V0IHR3byBkZWNhZGVzLCBidXQgaGFzIGhhZCBhbiB1cGhpbGwgYmF0dGxl IHNpbmNlIEVDTiByZXF1aXJlcyBzdXBwb3J0IGluIHRoZSBuZXR3b3JrIGFuZCBhdCBlbmRwb2lu dHMuDQoNClRoZXJlIGhhdmUgYmVlbiBtYW55IGVmZm9ydHMgdG8gdHJ5IGFuZCBkZXBsb3kgaXQg aW4gbmV0d29yayBkZXZpY2VzIGFuZCBhdCBlbmRwb2ludHMgZm9yIGFib3V0IGFzIGxvbmcgYXMg UkZDIDMxNjggaGFzIGV4aXN0ZWQuIEVDTiBoYXMgYmVlbiBkZXBsb3llZCBpbiBiaXRzIGF0IHJv dXRlcnMgYW5kIGluIGVuZHBvaW50cywgYnV0IGR1ZSB0byBsb25nLXN0YW5kaW5nIGJ1Z3MgaW4g b2xkZXIgaG9tZS1yb3V0ZXJzIGFuZCB3aWZpIGJveGVzLCBhbmQgaXNzdWVzIGFyb3VuZCB1c2Ug b2YgdGhlc2UgYml0cyBpbiB0aGUgSVAgaGVhZGVyLCBpdCB3YXMgZ2VuZXJhbGx5IG5vdCB0dXJu ZWQgb24gYW55d2hlcmUuIFRoaXMgc2VlbXMgdG8gYmUgY2hhbmdpbmcgbm93LCBlc3BlY2lhbGx5 IGFzIGJ1ZmZlcmJsb2F0IGJlY29tZXMgYW4gaW5jcmVhc2luZ2x5IHZpc2libGUgaXNzdWUuIEJy aWFuIFRyYW1tZWxsIChJQUIpIGFuZCBNaXJqYSBLdWVobGV3aW5kIChUcmFuc3BvcnQgQUQpIGhh dmUgYmVlbiBhY3RpdmVseSBkb2luZyBtZWFzdXJlbWVudCBhYm91dCB0aGUgY3VycmVudCBkZXBs b3ltZW50IHN0YXRlIG9mIEVDTjsgaGVyZSdzIGEgYmxvZyBwb3N0IGJ5IEJyaWFuPGh0dHBzOi8v bWFtaS1wcm9qZWN0LmV1L2luZGV4LnBocC8yMDE2LzA2LzEzLzcwLW9mLXBvcHVsYXItd2ViLXNp dGVzLXN1cHBvcnQtZWNuLz4gZnJvbSBsYXN0IHN1bW1lciBzYXlpbmcgdGhhdCBhIGxhcmdlIG51 bWJlciBvZiB3ZWJzZXJ2ZXJzIGRvIHN1cHBvcnQgRUNOLiBUaGVyZSdzIHN1cHBvcnQgZm9yIEVD TiBidWlsdCBpbnRvIFRDUCAoc2VlIFNlY3Rpb24gMy4yIGFuZCA0LjMgb2YgdGhlIFRDUCBSb2Fk bWFwIFJGQzxodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NDE0PiksIHRoZXJl J3MgYmVlbiBhIHRvbiBvZiB3b3JrIGFyb3VuZCByZS11c2luZyBFQ04gc2lnbmFsaW5nIGZvciBy aWNoZXIgY29uZ2VzdGlvbiBpbmZvcm1hdGlvbi4NCg0KU2luY2UgVENQIGFuZCBTQ1RQIGhhdmUg c3VwcG9ydCBmb3IgRUNOLCBhbmQgdGhlIGZ1dHVyZSBtYXkgc2VlIEVDTiBkZXBsb3ltZW50IGlu Y3JlYXNlIHlldCwgaXQncyBleHBlY3RlZCB0aGF0IFFVSUMgd291bGQgaGF2ZSBlcXVpdmFsZW50 IG1lY2hhbmlzbXMgdG8gc3VwcG9ydCB1c2Ugb2YgRUNOLiBUaGlzIHdvcmsgaXMgdmVyeSBtdWNo IGluIHNjb3BlLCBhcyBwYXJ0IG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgYXNwZWN0IG9mIFFV SUMuDQoNCkhvcGUgdGhpcyBoZWxwcywNCi0gamFuYQ0KDQoNCg0KT24gV2VkLCBGZWIgMjIsIDIw MTcgYXQgMTI6MjIgUE0sIEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25A ZXJpY3Nzb24uY29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KSGkNCg0KSSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIEVDTiBpbiBR VUlDIGRyYWZ0LiBUaGUgbWFpbiBjaGFuZ2UgYSBkZXNjcmlwdGlvbiBvZiB0aGUgRUNOIG5lZ290 aWF0aW9uLg0KDQovSW5nZW1hcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc+XQ0KU2VudDogZGVuIDIyIGZlYnJ1YXJpIDIwMTcgMDg6NTYNClRvOiBJbmdlbWFy IEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJbmdlbWFyIEpvaGFuc3NvbiBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1qb2hhbnNzb24t cXVpYy1lY24NClJldmlzaW9uOiAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAgIEVDTiBzdXBwb3J0 IGluIFFVSUMNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTAyLTIxDQpHcm91cDogICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMTINClVSTDogICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtam9oYW5zc29uLXF1aWMt ZWNuLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxDQpEaWZmOiAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWpvaGFuc3Nvbi1x dWljLWVjbi0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBvdXRsaW5lcyB0aGUgRUNOIHN1 cHBvcnQgaW4gUVVJQy4gIFRoZSBpbnRlbnRpb24gaXMgdGhhdA0KICAgbW9zdCBvZiB0aGUgbWF0 ZXJpYWwgZW5kcyB1cCB1cGRhdGluZyBvdGhlciBuZXcgb3IgZXhpc3RpbmcgUVVJQw0KICAgcHJv dG9jb2wgc3BlY2lmaWNhdGlvbnMsIHRodXMgaXQgbWF5IGJlIHBvc3NpYmxlIHRoYXQgdGhpcyBk cmFmdCBkb2VzDQogICBub3Qgd2FycmFudCBhIHdvcmtpbmcgZ3JvdXAgc3RhdHVzLg0KDQoNCg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+ Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_BN6PR03MB2708A4A502E865333337CE6087530BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHJlYWQgUEhC4oCZcyBjb21tZW50IGFzIGEgdHlwaWNhbGx5LXNhcmNhc3RpYyB3YXkgb2Ygc2F5 aW5nIHRoYXQgdGhlIEludHJvZHVjdGlvbiBvZiB0aGlzIGRyYWZ0IGFzc3VtZXMgcXVpdGUgYSBi aXQgb2Yga25vd2xlZGdlIHRoYXQgaXMgcGVyaGFwcyBiZXN0IHNwZWxsZWQgb3V0IHdpdGggc29t ZSByZWxldmFudCBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzLiZuYnNwOyBUaGF0IGlzLCBhZnRlciBh bGwsIHRoZSBwb2ludA0KIG9mIGFuIGludHJvZHVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZg0KPC9iPkphbmEgSXllbmdhcjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDIyLCAyMDE3IDM6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWxsaXAgSGFsbGFt LUJha2VyICZsdDtwaGlsbEBoYWxsYW1iYWtlci5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAnZ29y cnlAZXJnLmFiZG4uYWMudWsnIChnb3JyeUBlcmcuYWJkbi5hYy51aykgJmx0O2dvcnJ5QGVyZy5h YmRuLmFjLnVrJmd0OzsgQm9iIEJyaXNjb2UgKGlldGZAYm9iYnJpc2NvZS5uZXQpICZsdDtpZXRm QGJvYmJyaXNjb2UubmV0Jmd0OzsgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7OyBtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNo OyBtYXJjZWxvIGJhZ251bG8gYnJhdW4gJmx0O21hcmNlbG9AaXQudWMzbS5lcyZndDs7DQogUGll cnMgTydIYW5sb24gJmx0O3BpZXJzLm9oYW5sb25AY3Mub3guYWMudWsmZ3Q7OyBJRVRGIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRSkg Jmx0O2tvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFu c3Nvbi1xdWljLWVjbi0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgMTI6NTUgUE0sIFBoaWxsaXAgSGFsbGFt LUJha2VyICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGxAaGFsbGFtYmFrZXIuY29tIiB0YXJnZXQ9 Il9ibGFuayI+cGhpbGxAaGFsbGFtYmFrZXIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoaXMgaXMgdGhlIGVudGlyZXR5IG9m IHRoZSBpbnRyb2R1Y3Rpb246ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZuYnNwO0VD TiBzdXBwb3J0IGluIHRyYW5zcG9ydCBwcm90b2NvbHMgaXMgYSBmdW5kYW1lbnRhbCBmZWF0dXJl IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZuYnNwO3Nob3Vs ZCBiZSBpbmNsdWRlZCBpbiB0aGUgUVVJQyBzcGVjaWZpY2F0aW9uIGFzIGEgbWFuZGF0b3J5IGVs ZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyAmbmJzcDtUaGUg YmVuZWZpdHMgb2YgRUNOIGlzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtYXFtLWVjbi1iZW5lZml0 c10uJm5ic3A7IFRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsgJm5i c3A7RUNOIHN1cHBvcnQgc2hvdWxkIGJlIGltcGxlbWVudGVkIHRvIHN1cHBvcnQgYm90aCBwcmVz ZW50IGFuZCBmdXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZu YnNwO0VDTiwgdGhlIGxhdHRlciBpcyBvdXRsaW5lZCBpbiBbSS1ELmlldGYtdHN2d2ctZWNuLWV4 cGVyaW1lbnRhdGlvbl0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyAm bmJzcDtvZiBwYXJ0aWN1bGFyIGludGVyZXN0IGlzIHRoZSBhYmlsaXR5IHRvIGRpc2NyaW1pbmF0 ZSBiZXR3ZWVuIGNsYXNzaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 ICZuYnNwO0VDTiBhbmQgTDRTIEVDTiBieSBtZWFucyBvZiBkaWZmZXJlbnRpYXRpb24gYmV0d2Vl biB0aGUgdXNlIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsg Jm5ic3A7RUNUKDApIGFuZCBFQ1QoMSkgY29kZSBwb2ludHMuJm5ic3A7IFRoaXMgZHJhZnQgZG9l cyBob3dldmVyIG5vdCBkZWx2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDsgJm5ic3A7aW50byB0aGUgZGV0YWlscyBvZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGltcGxl bWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSBoYXZlIGFic29sdXRlbHkgbm8gaWRlYSB3aGF0 IEVDTiBpcy4gSSBhbSBvcHBvc2VkIHRvIHRoZSBXRyBzcGVuZGluZyBhbnkgdGltZSBvbiBFQ04g dW50aWwgaXQgY2FuIGJlIGV4cGxhaW5lZCBpbiB0ZXJtcyB0aGF0IGRvIG5vdCByZWZlcmVuY2Ug eWV0IG1vcmUgamFyZ29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhcHB5 IHRvIGhlbHAuIEVDTiBpcyBkZWZpbmVkIGluIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzMTY4Ij4NClJGQyAzMTY4PC9hPiwgYW5kIGlzIGFuIGV4cGxpY2l0IHNpZ25h bCBmcm9tIHRoZSBhIG5ldHdvcmsgc3dpdGNoIG9yIHJvdXRlciBhYm91dCBjb25nZXN0aW9uIGF0 IGEgbGluaywgc28gdGhhdCBlbmRwb2ludHMgY2FuIHVzZSB0aGlzIHNpZ25hbCBpbnN0ZWFkIG9m IGxvc3MgZm9yIGRldGVjdGluZyBhbmQgcmVhY3RpbmcgdG8gY29uZ2VzdGlvbi4gVGhlIGJlbmVm aXRzIG9mIGRvaW5nIHRoaXMgYXJlIGRvY3VtZW50ZWQgaW50IGhlIEktRCB0aGF0DQogaXMgbGlu a2VkIGluIHRoZSBhYnN0cmFjdC4gRUNOIGhhcyBiZWVuIGEgcHJldHR5IHNpZ25pZmljYW50IHRo aW5nIGluIHRyYW5zcG9ydCBmb3IgYWJvdXQgdHdvIGRlY2FkZXMsIGJ1dCBoYXMgaGFkIGFuIHVw aGlsbCBiYXR0bGUgc2luY2UgRUNOIHJlcXVpcmVzIHN1cHBvcnQgaW4gdGhlIG5ldHdvcmsgYW5k IGF0IGVuZHBvaW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaGF2ZSBiZWVuIG1hbnkgZWZmb3J0cyB0byB0cnkgYW5k IGRlcGxveSBpdCBpbiBuZXR3b3JrIGRldmljZXMgYW5kIGF0IGVuZHBvaW50cyBmb3IgYWJvdXQg YXMgbG9uZyBhcyBSRkMgMzE2OCBoYXMgZXhpc3RlZC4gRUNOIGhhcyBiZWVuIGRlcGxveWVkIGlu IGJpdHMgYXQgcm91dGVycyBhbmQgaW4gZW5kcG9pbnRzLCBidXQgZHVlIHRvIGxvbmctc3RhbmRp bmcgYnVncyBpbiBvbGRlciBob21lLXJvdXRlcnMNCiBhbmQgd2lmaSBib3hlcywgYW5kIGlzc3Vl cyBhcm91bmQgdXNlIG9mIHRoZXNlIGJpdHMgaW4gdGhlIElQIGhlYWRlciwgaXQgd2FzIGdlbmVy YWxseSBub3QgdHVybmVkIG9uIGFueXdoZXJlLiBUaGlzIHNlZW1zIHRvIGJlIGNoYW5naW5nIG5v dywgZXNwZWNpYWxseSBhcyBidWZmZXJibG9hdCBiZWNvbWVzIGFuIGluY3JlYXNpbmdseSB2aXNp YmxlIGlzc3VlLiBCcmlhbiBUcmFtbWVsbCAoSUFCKSBhbmQgTWlyamEgS3VlaGxld2luZCAoVHJh bnNwb3J0DQogQUQpIGhhdmUgYmVlbiBhY3RpdmVseSBkb2luZyBtZWFzdXJlbWVudCBhYm91dCB0 aGUgY3VycmVudCBkZXBsb3ltZW50IHN0YXRlIG9mIEVDTjsgaGVyZSdzIGENCjxhIGhyZWY9Imh0 dHBzOi8vbWFtaS1wcm9qZWN0LmV1L2luZGV4LnBocC8yMDE2LzA2LzEzLzcwLW9mLXBvcHVsYXIt d2ViLXNpdGVzLXN1cHBvcnQtZWNuLyI+DQpibG9nIHBvc3QgYnkgQnJpYW48L2E+Jm5ic3A7ZnJv bSBsYXN0IHN1bW1lciBzYXlpbmcgdGhhdCBhIGxhcmdlIG51bWJlciBvZiB3ZWJzZXJ2ZXJzIGRv IHN1cHBvcnQgRUNOLiBUaGVyZSdzIHN1cHBvcnQgZm9yIEVDTiBidWlsdCBpbnRvIFRDUCAoc2Vl IFNlY3Rpb24gMy4yIGFuZCA0LjMgb2YgdGhlDQo8YSBocmVmPSJodHRwczovL3RyYWMudG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3NDE0Ij5UQ1AgUm9hZG1hcCBSRkM8L2E+KSwgdGhlcmUncyBiZWVu IGEgdG9uIG9mIHdvcmsgYXJvdW5kIHJlLXVzaW5nIEVDTiBzaWduYWxpbmcgZm9yIHJpY2hlciBj b25nZXN0aW9uIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBUQ1AgYW5kIFNDVFAgaGF2ZSBzdXBwb3J0IGZvciBF Q04sIGFuZCB0aGUgZnV0dXJlIG1heSBzZWUgRUNOIGRlcGxveW1lbnQgaW5jcmVhc2UgeWV0LCBp dCdzIGV4cGVjdGVkIHRoYXQgUVVJQyB3b3VsZCBoYXZlIGVxdWl2YWxlbnQgbWVjaGFuaXNtcyB0 byBzdXBwb3J0IHVzZSBvZiBFQ04uIFRoaXMgd29yayBpcyB2ZXJ5IG11Y2ggaW4gc2NvcGUsIGFz IHBhcnQgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJvbA0KIGFzcGVjdCBvZiBRVUlDLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3BlIHRoaXMg aGVscHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tIGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDIyLCAy MDE3IGF0IDEyOjIyIFBNLCBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDs8YSBocmVmPSJtYWlsdG86 aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SGk8YnI+DQo8YnI+DQpJIGp1c3QgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUg RUNOIGluIFFVSUMgZHJhZnQuIFRoZSBtYWluIGNoYW5nZSBhIGRlc2NyaXB0aW9uIG9mIHRoZSBF Q04gbmVnb3RpYXRpb24uPGJyPg0KPGJyPg0KL0luZ2VtYXI8YnI+DQo8YnI+DQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+ IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KU2VudDogZGVuIDIy IGZlYnJ1YXJpIDIwMTcgMDg6NTY8YnI+DQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i bGFuayI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9oYW5zc29uLXF1aWMtZWNu LTAxLnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qb2hh bnNzb24tcXVpYy1lY24tMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg SW5nZW1hciBKb2hhbnNzb24gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4N Cjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFm dC1qb2hhbnNzb24tcXVpYy1lY248YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDswMTxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRUNO IHN1cHBvcnQgaW4gUVVJQzxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTctMDItMjE8YnI+ DQpHcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3Vi bWlzc2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTI8 YnI+DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpvaGFuc3Nvbi1x dWljLWVjbi0wMS50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEudHh0PC9hPjxicj4NClN0 YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvaGFuc3Nv bi1xdWljLWVjbi88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaGFuc3Nvbi1xdWlj LWVjbi0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1qb2hhbnNzb24tcXVpYy1lY24tMDE8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAx PC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIG1lbW8gb3V0 bGluZXMgdGhlIEVDTiBzdXBwb3J0IGluIFFVSUMuJm5ic3A7IFRoZSBpbnRlbnRpb24gaXMgdGhh dDxicj4NCiZuYnNwOyAmbmJzcDttb3N0IG9mIHRoZSBtYXRlcmlhbCBlbmRzIHVwIHVwZGF0aW5n IG90aGVyIG5ldyBvciBleGlzdGluZyBRVUlDPGJyPg0KJm5ic3A7ICZuYnNwO3Byb3RvY29sIHNw ZWNpZmljYXRpb25zLCB0aHVzIGl0IG1heSBiZSBwb3NzaWJsZSB0aGF0IHRoaXMgZHJhZnQgZG9l czxicj4NCiZuYnNwOyAmbmJzcDtub3Qgd2FycmFudCBhIHdvcmtpbmcgZ3JvdXAgc3RhdHVzLjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8 L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB2708A4A502E865333337CE6087530BN6PR03MB2708namp_-- From nobody Thu Mar 9 07:28:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D43F12950B for ; Wed, 22 Feb 2017 18:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 egkhYTPwweyi for ; Wed, 22 Feb 2017 18:43:07 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 587AF129E4D for ; Wed, 22 Feb 2017 18:38:04 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id g30so14047645uac.3 for ; Wed, 22 Feb 2017 18:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IBVbojDaHCsU2Bf1yJNRKrwll2fdkSVuXYBEFB2mWa8=; b=SIn5uXLhyRNdgOfu2A1S1dUrTJLQeewg15u4A2mW23G6m4aU1dYkpTMPjK7udvVHWa /zbZct8q0B7ilS5iYHzTLEhZOF0JQY7Baba8oHuie1d13Ug4vtK8lQqPxyh8wmAaNGET EbgLcFeyrjfy1DXXJMgXHvwXAWl4PlrCVLQhWerjpFuEVPol0ssbh7ThoU0Jz8U9ojpe S5CeDTmxZDFQm6Pfn2Dz1zhJNeJjLhjf5C7GZvRRtP3tcL5RCVgMYuhjAaG9L7SDiDbi NdeboxzxN8vn9iDu85lglBY3oOAnQ5LWQKd8DA4VmDu9cegLQpBGTwu/tVvbcQBIeC17 MxOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IBVbojDaHCsU2Bf1yJNRKrwll2fdkSVuXYBEFB2mWa8=; b=fWqJVJG/OAPmo6riQq3ufGu5H/61ncAoHMZi/6s3sIp4nVeJh13fkojH2K9mPtcXmM 8wKuFF03qaMKjHRN1ihbnV+5w7eqWONm2VW2nJY+qDRRBzF9QGMzcjlUa8Ith0c7fILg Tlhr52cdOiyf6DL870lFQMjrIW5QHeoX0z/4v1kH4JH/Doz1rYPvtAwGG2FqtJaBh9Gc 8DNAJWwD6yrn3vENHF/w8CNb1ZqCKQCGRgJspONuBYYX7vvOo+Eh+GqtXivadr6ZH+n0 lue83t1qFPumOkDr8ikkHrbqCvWwuwZHmEIvYqaq8qRkesXZOO7e4sWEehKcBGSVIypC u2KA== X-Gm-Message-State: AMke39mgZvG5shkFjxXEMrBhz8lRQPnFBMCYo/X7C/kScKLUMb41Wx9cOw802BEjtvIfUTXgqViZ4a1a4iXkuRkp X-Received: by 10.176.17.18 with SMTP id e18mr2077670uab.143.1487817483065; Wed, 22 Feb 2017 18:38:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Wed, 22 Feb 2017 18:38:02 -0800 (PST) In-Reply-To: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: Jana Iyengar Date: Wed, 22 Feb 2017 18:38:02 -0800 Message-ID: Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f403045e3b6e9241b2054929801d Archived-At: X-Mailman-Approved-At: Thu, 09 Mar 2017 07:28:01 -0800 Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , Mike Bishop , "Bob Briscoe \(ietf@bobbriscoe.net\)" , Ingemar Johansson S , "mirja.kuehlewind@tik.ee.ethz.ch" , marcelo bagnulo braun , Piers O'Hanlon , IETF QUIC WG , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 02:43:09 -0000 --f403045e3b6e9241b2054929801d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable QUIC, by being cross-area, makes it difficult for folks to review all docs, since it's uncommon for folks to know everything about all aspects of TLS, transport, and HTTP/2. This does make it an opportunity to write drafts that are clearer to a wider audience. In this case, I think a reference to RFC 3168 and a couple of sentences ought to be adequate. That said, I'll note that this cross-area work will require everyone to wear their humility hats more frequently. If you are frustrated, it's perhaps because you're encountering an area that was foreign to you until now. ECN is not outside-think for anyone who's been working on transport protocols for more than a day. I'd ask about something you don't understand first, and then consider declaring that the wg should not work on it. Prepare to be frustrated more often. On Wed, Feb 22, 2017 at 5:33 PM, Phillip Hallam-Baker wrote: > Not sarcastic at all. Just frustrated. Reading a draft should not require > recourse to Wikipedia. > > On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop > wrote: > >> I read PHB=E2=80=99s comment as a typically-sarcastic way of saying that= the >> Introduction of this draft assumes quite a bit of knowledge that is perh= aps >> best spelled out with some relevant informative references. That is, af= ter >> all, the point of an introduction. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar >> *Sent:* Wednesday, February 22, 2017 3:37 PM >> *To:* Phillip Hallam-Baker >> *Cc:* 'gorry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk) ; >> Bob Briscoe (ietf@bobbriscoe.net) ; Ingemar >> Johansson S ; >> mirja.kuehlewind@tik.ee.ethz.ch; marcelo bagnulo braun < >> marcelo@it.uc3m.es>; Piers O'Hanlon ; IETF >> QUIC WG ; De Schepper, Koen (Nokia - BE) < >> koen.de_schepper@nokia-bell-labs.com> >> *Subject:* Re: FW: New Version Notification for >> draft-johansson-quic-ecn-01.txt >> >> >> >> On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >> This is the entirety of the introduction: >> >> >> >> ECN support in transport protocols is a fundamental feature that >> >> should be included in the QUIC specification as a mandatory element. >> >> The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The >> >> ECN support should be implemented to support both present and future >> >> ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], >> >> of particular interest is the ability to discriminate between classic >> >> ECN and L4S ECN by means of differentiation between the use of the >> >> ECT(0) and ECT(1) code points. This draft does however not delve >> >> into the details of the congestion control implementation. >> >> >> >> I have absolutely no idea what ECN is. I am opposed to the WG spending >> any time on ECN until it can be explained in terms that do not reference >> yet more jargon. >> >> >> >> Happy to help. ECN is defined in RFC 3168 >> , and is an explicit signal from >> the a network switch or router about congestion at a link, so that >> endpoints can use this signal instead of loss for detecting and reacting= to >> congestion. The benefits of doing this are documented int he I-D that is >> linked in the abstract. ECN has been a pretty significant thing in >> transport for about two decades, but has had an uphill battle since ECN >> requires support in the network and at endpoints. >> >> >> >> There have been many efforts to try and deploy it in network devices and >> at endpoints for about as long as RFC 3168 has existed. ECN has been >> deployed in bits at routers and in endpoints, but due to long-standing b= ugs >> in older home-routers and wifi boxes, and issues around use of these bit= s >> in the IP header, it was generally not turned on anywhere. This seems to= be >> changing now, especially as bufferbloat becomes an increasingly visible >> issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD) have bee= n >> actively doing measurement about the current deployment state of ECN; >> here's a blog post by Brian >> from >> last summer saying that a large number of webservers do support ECN. >> There's support for ECN built into TCP (see Section 3.2 and 4.3 of the T= CP >> Roadmap RFC ), there's been a >> ton of work around re-using ECN signaling for richer congestion informat= ion. >> >> >> >> Since TCP and SCTP have support for ECN, and the future may see ECN >> deployment increase yet, it's expected that QUIC would have equivalent >> mechanisms to support use of ECN. This work is very much in scope, as pa= rt >> of the congestion control aspect of QUIC. >> >> >> >> Hope this helps, >> >> - jana >> >> >> >> >> >> >> >> On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S < >> ingemar.s.johansson@ericsson.com> wrote: >> >> Hi >> >> I just uploaded a new version of the ECN in QUIC draft. The main change = a >> description of the ECN negotiation. >> >> /Ingemar >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: den 22 februari 2017 08:56 >> To: Ingemar Johansson S >> Subject: New Version Notification for draft-johansson-quic-ecn-01.txt >> >> >> A new version of I-D, draft-johansson-quic-ecn-01.txt has been >> successfully submitted by Ingemar Johansson and posted to the IETF >> repository. >> >> Name: draft-johansson-quic-ecn >> Revision: 01 >> Title: ECN support in QUIC >> Document date: 2017-02-21 >> Group: Individual Submission >> Pages: 12 >> URL: https://www.ietf.org/internet- >> drafts/draft-johansson-quic-ecn-01.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-johansson-quic-ecn/ >> Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-01 >> Diff: https://www.ietf.org/rfcdiff? >> url2=3Ddraft-johansson-quic-ecn-01 >> >> Abstract: >> This memo outlines the ECN support in QUIC. The intention is that >> most of the material ends up updating other new or existing QUIC >> protocol specifications, thus it may be possible that this draft does >> not warrant a working group status. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> > > --f403045e3b6e9241b2054929801d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
QUIC, by being cross-area, makes it difficult for fol= ks to review all docs, since it's uncommon for folks to know everything= about all aspects of TLS, transport, and HTTP/2. This does make it an oppo= rtunity to write drafts that are clearer to a wider audience. In this case,= I think a reference to RFC 3168 and a couple of sentences ought to be adeq= uate.

That said, I'll note that this cross-are= a work will require everyone to wear their humility hats more frequently. I= f you are frustrated, it's perhaps because you're encountering an a= rea that was foreign to you until now. ECN is not outside-think for anyone = who's been working on transport protocols for more than a day. I'd = ask about something you don't understand first, and then consider decla= ring that the wg should not work on it.

Prepare to= be frustrated more often.

On Wed, Feb 22, 2017 at 5:33 PM, Phillip Hallam-Baker = <phill@hallambaker.com> wrote:
Not sarcastic at all. Just frustrated. Reading a draft should not req= uire recourse to Wikipedia.

On Wed, Feb 2= 2, 2017 at 7:30 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

I read PHB=E2=80=99s comment as a typically-sarcasti= c way of saying that the Introduction of this draft assumes quite a bit of = knowledge that is perhaps best spelled out with some relevant informative r= eferences.=C2=A0 That is, after all, the point of an introduction.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Wednesday, February 22, 2017 3:37 PM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: 'g= orry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk) <gorry@erg.abdn.ac.uk>; Bob Briscoe (ietf@bobbriscoe.net)= <ietf@bobbrisc= oe.net>; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; mirja.kuehlewind@tik.ee.ethz.ch; marcelo bagnulo braun <marcelo@it.uc3m.es>= ;; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; IETF QUIC WG <quic@ietf.org>; De Schepper,= Koen (Nokia - BE) <koen.de_schepper@nokia-bell-labs.com>
Subject: Re: FW: New Version Notification for draft-johansson-quic-e= cn-01.txt

=C2=A0

On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Bak= er <phill@hal= lambaker.com> wrote:

This is the entiret= y of the introduction: =C2=A0

=C2=A0

=C2=A0 =C2=A0ECN su= pport in transport protocols is a fundamental feature that

=C2=A0 =C2=A0should= be included in the QUIC specification as a mandatory element.

=C2=A0 =C2=A0The be= nefits of ECN is described in [I-D.ietf-aqm-ecn-benefits].=C2=A0 The=

=C2=A0 =C2=A0ECN su= pport should be implemented to support both present and future

=C2=A0 =C2=A0ECN, t= he latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation],<= u>

=C2=A0 =C2=A0of par= ticular interest is the ability to discriminate between classic

=C2=A0 =C2=A0ECN an= d L4S ECN by means of differentiation between the use of the<= /span>

=C2=A0 =C2=A0ECT(0)= and ECT(1) code points.=C2=A0 This draft does however not delve<= /u>

=C2=A0 =C2=A0into t= he details of the congestion control implementation.

=C2=A0

I have absolutely n= o idea what ECN is. I am opposed to the WG spending any time on ECN until i= t can be explained in terms that do not reference yet more jargon.

=C2=A0

Happy to help. ECN is defined in RFC 3168, and is an explicit signal from the a network switch or router= about congestion at a link, so that endpoints can use this signal instead = of loss for detecting and reacting to congestion. The benefits of doing thi= s are documented int he I-D that is linked in the abstract. ECN has been a pretty significant thing in tran= sport for about two decades, but has had an uphill battle since ECN require= s support in the network and at endpoints.=C2=A0

=C2=A0

There have been many efforts to try and deploy it in= network devices and at endpoints for about as long as RFC 3168 has existed= . ECN has been deployed in bits at routers and in endpoints, but due to lon= g-standing bugs in older home-routers and wifi boxes, and issues around use of these bits in the IP header, it w= as generally not turned on anywhere. This seems to be changing now, especia= lly as bufferbloat becomes an increasingly visible issue. Brian Trammell (I= AB) and Mirja Kuehlewind (Transport AD) have been actively doing measurement about the current deployment stat= e of ECN; here's a blog post by Brian=C2=A0from last summer saying that a large number of = webservers do support ECN. There's support for ECN built into TCP (see = Section 3.2 and 4.3 of the TCP = Roadmap RFC), there's been a ton of work around re-using ECN signal= ing for richer congestion information.

=C2=A0

Since TCP and SCTP have support for ECN, and the fut= ure may see ECN deployment increase yet, it's expected that QUIC would = have equivalent mechanisms to support use of ECN. This work is very much in= scope, as part of the congestion control aspect of QUIC.

=C2=A0

Hope this helps,

- jana

=C2=A0

=C2=A0

=C2=A0

On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson = S <ingemar.s.johansson@ericsson.com> wrote:

Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a d= escription of the ECN negotiation.

/Ingemar

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt<= br>

A new version of I-D, draft-johansson-quic-ecn-01.txt has been success= fully submitted by Ingemar Johansson and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-johansson-quic-ecn
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN support in QUIC
Document date:=C2=A0 2017-02-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.= txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/= draft-johansson-quic-ecn-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ww= w.ietf.org/rfcdiff?url2=3Ddraft-johansson-quic-ecn-01

Abstract:
=C2=A0 =C2=A0This memo outlines the ECN support in QUIC.=C2=A0 The intentio= n is that
=C2=A0 =C2=A0most of the material ends up updating other new or existing QU= IC
=C2=A0 =C2=A0protocol specifications, thus it may be possible that this dra= ft does
=C2=A0 =C2=A0not warrant a working group status.





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

The IETF Secretariat

=C2=A0

=C2=A0



--f403045e3b6e9241b2054929801d-- From nobody Thu Mar 9 07:28:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B3129629 for ; Wed, 22 Feb 2017 23:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAykjKcF8rco for ; Wed, 22 Feb 2017 23:38:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBB5129648 for ; Wed, 22 Feb 2017 23:38:26 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-5f-58ae9170bdc9 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id AE.59.11383.F619EA85; Thu, 23 Feb 2017 08:38:24 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 23 Feb 2017 08:38:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jf5SYquRSQ9Fdugk9R3XCQ7O4M15oyEIeBtR4CWTbMY=; b=VlkKt43wx7rc9XI56htBNgH4cCwME6Vlm2dw2Cng9N5VCS0IRGEae6erQCcYqi8tIRuQOKZvlSXjsYJH16ac1w0PRuDUo89ZAmlpI66YFvljVZhlHbu53FWMxCV/3TOsx+gXanOooG3aUs9g8QwJNRn+dtIClI7XAtGJ3ct2FBs= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 23 Feb 2017 07:38:02 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 07:38:02 +0000 From: Ingemar Johansson S To: Phillip Hallam-Baker , Jana Iyengar Subject: RE: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Topic: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Index: AQHSjOEdDzxr00Ts+EONPowXtDkG56F1RM/QgAA9agCAAC0sAIAADnzwgAASFQCAABH8AIAAA80AgABNbKA= Date: Thu, 23 Feb 2017 07:38:02 +0000 Message-ID: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-office365-filtering-correlation-id: b7647f24-674a-4ab8-e7aa-08d45bbee613 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB347; x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:uelc2S/GvNde+XjYPgzfqHHfZNdGHpBHNfJQLTTKexTg5J1tpaDLFZajBWslmEbSSLUL/KeK7+nEgRzL2PCY8zGKAtKXG9kgZFpbKY0eUBPRC7vV/K5JbYraTXC4uS4kQ/q+IkZAV8458CRiGJcK6btKa4YyujRr4ReDeXDg3DFEvlyr/SnCG9FJZCMhPaAMQQVRkvokm/bxPJ8IMetFpoZFMBz8p42kba9EOdIb7dqGjx6gnqut1vovhVt1YT1oHgDz/iypKYm5m2eWmdsl3/Y1v6EHDYeTIX/qL+KnJe9S5HJCzpvq2bys4Vph2B4ElgQTG4IoDAnWNqEvwvPX2w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB347; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(13464003)(129404003)(377424004)(24454002)(189002)(199003)(189998001)(3660700001)(97736004)(10710500007)(106116001)(8936002)(92566002)(6246003)(19609705001)(2900100001)(66066001)(38730400002)(2950100002)(122556002)(16799955002)(53546006)(6116002)(7110500001)(86362001)(790700001)(4326007)(3280700002)(105586002)(9326002)(3846002)(102836003)(2906002)(53386004)(606005)(106356001)(74316002)(7696004)(81156014)(54356999)(33656002)(77096006)(6436002)(53936002)(229853002)(8676002)(81166006)(7736002)(54906002)(101416001)(5660300001)(25786008)(230783001)(8666007)(14971765001)(9686003)(55016002)(76176999)(50986999)(7416002)(68736007)(7906003)(99286003)(6506006)(236005)(6306002)(2420400007)(15650500001)(93886004)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348512F16EC5B568D6460F5C2530DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 07:38:02.6780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUzMcRzH9/093P06jq/Tw2eRcWZknDTxM81TZr+ZWmU4+YOjn7SuB/er Js2UuUYPo9ysO3oikihCKhbOHGblUCmuJ2qORGOVm9Xc3S+b/16f7/v13efz/ezLkIrftC8T m5DM6xI0WqVERhnV98KWJuVXqwPGG2ewg1nnEfu0r5RmC56WUaxl9DLB6geuSdiyJ9mIvVll oNj8YadSm3WbZnNLp6yXcV97rDQ3frKO4nJ/2QmutDaFs1aNEFx5uYPgRt/dojl9/biUOz56 UcJZhkck4bIoWXA0r41N5XXL1u6VHSxrG0ZJ7U3E4YbaISIDXa8jshHDAF4BlwwB2UjGKHA1 gke2UUIsniNotp+mXQWF80gYaTgxmZwjoMpeiLKRh7OwIMh87etiCQ6GSvOY+9wTR8Cg1eq+ QOLHJNQMH6ddwUwcCg0WvVSUwqDfWkmJvA96W4rdTOEF0H7vg9uX4yi4b7hFic1aKWi7usTF Hs4G3S0N7mYI+0HPWLfbIbEPvO8vIVwMGEP5g1ekyF7w5dMELfr74WdnHi2+fy703Q0TlVDo KByb1LfCQGaRxDU/4BwSDFcKkBjEwtDbyklJC5/Lv9KiVEjAo64SWgxmg6OznhCDq1I4a8uf XBcPFTf0SNyEL3S1nkJnkL/pv8FFToSzll8Sk3sBM+CFsZ8yOYclsT/UNC4TlXlgyOmTirwI 9BeKpP+flyLpNeQl8MK++JjAQBWvi90vCIkJqgQ+uRY5/+PjO38C6tGXzxvMCDNIOVV+qOKG WkFrUoW0eDMChlR6yp/pq9UKebQm7QivS9yjS9HyghnNYiilj3xlZc9OBY7RJPNxPJ/E6/6l BOPhm4GMbxTB8jUOR2SINj0k3TFhM87Z5eexSl50dEcrt7YpxWifVtzXsu7h9O3W754+kYfi bT8iXm6Ms91uSpGdUTUyzd7qKuHjJrRtp6bZ3DtxjLP3hJsKIp+3hphU83Onc0HfHq5eE1Rz bmZQ15A6bnP7+w5/74XcluQDjuW7A9OiVUpKOKhZvpjUCZq/ge0IJYsDAAA= Archived-At: X-Mailman-Approved-At: Thu, 09 Mar 2017 07:28:01 -0800 Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , Mike Bishop , "Bob Briscoe \(ietf@bobbriscoe.net\)" , "mirja.kuehlewind@tik.ee.ethz.ch" , marcelo bagnulo braun , Piers O'Hanlon , IETF QUIC WG , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 07:38:30 -0000 --_000_DB4PR07MB348512F16EC5B568D6460F5C2530DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBjYW4gYWRkIGEgbW9yZSBjb21wcmVoZW5zaXZlIHRleHQgdGhhdCBkZXNjcmliZXMg RUNOIGEgYml0IGFuZCBhbiBleHBhbnNpb24gb2YgdGhlIGFjcm9ueW1zLCB0aGF0IHNvdW5kcyB2 ZXJ5IHJlYXNvbmFibGUuDQpJIGRvbuKAmXQgaG93ZXZlciB3YW50IHRvIGFkZCBhIGNvbXBsZXRl IEVDTiBjcmFzaC1jb3Vyc2UgaW50byB0aGUgZG9jdW1lbnQgIGFzIHRoaXMgdGV4dCBhbHJlYWR5 IGV4aXN0IGVsc2V3aGVyZSBpbiBUU1ZXRywgSUNDUkcgIGFuZCBBUU0gV0cgZG9jdW1lbnRzLg0K DQpSZWdhcmRzDQovSW5nZW1hcg0KDQpGcm9tOiBoYWxsYW1AZ21haWwuY29tIFttYWlsdG86aGFs bGFtQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpTZW50OiBk ZW4gMjMgZmVicnVhcmkgMjAxNyAwMzo1Mg0KVG86IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5j b20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyAnZ29y cnlAZXJnLmFiZG4uYWMudWsnIChnb3JyeUBlcmcuYWJkbi5hYy51aykgPGdvcnJ5QGVyZy5hYmRu LmFjLnVrPjsgQm9iIEJyaXNjb2UgKGlldGZAYm9iYnJpc2NvZS5uZXQpIDxpZXRmQGJvYmJyaXNj b2UubmV0PjsgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb20+OyBtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoOyBtYXJjZWxvIGJhZ251bG8g YnJhdW4gPG1hcmNlbG9AaXQudWMzbS5lcz47IFBpZXJzIE8nSGFubG9uIDxwaWVycy5vaGFubG9u QGNzLm94LmFjLnVrPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgRGUgU2NoZXBwZXIs IEtvZW4gKE5va2lhIC0gQkUpIDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+ DQpTdWJqZWN0OiBSZTogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9o YW5zc29uLXF1aWMtZWNuLTAxLnR4dA0KDQoNCg0KT24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgOToz OCBQTSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+ PiB3cm90ZToNClFVSUMsIGJ5IGJlaW5nIGNyb3NzLWFyZWEsIG1ha2VzIGl0IGRpZmZpY3VsdCBm b3IgZm9sa3MgdG8gcmV2aWV3IGFsbCBkb2NzLCBzaW5jZSBpdCdzIHVuY29tbW9uIGZvciBmb2xr cyB0byBrbm93IGV2ZXJ5dGhpbmcgYWJvdXQgYWxsIGFzcGVjdHMgb2YgVExTLCB0cmFuc3BvcnQs IGFuZCBIVFRQLzIuIFRoaXMgZG9lcyBtYWtlIGl0IGFuIG9wcG9ydHVuaXR5IHRvIHdyaXRlIGRy YWZ0cyB0aGF0IGFyZSBjbGVhcmVyIHRvIGEgd2lkZXIgYXVkaWVuY2UuIEluIHRoaXMgY2FzZSwg SSB0aGluayBhIHJlZmVyZW5jZSB0byBSRkMgMzE2OCBhbmQgYSBjb3VwbGUgb2Ygc2VudGVuY2Vz IG91Z2h0IHRvIGJlIGFkZXF1YXRlLg0KDQpUaGF0IHNhaWQsIEknbGwgbm90ZSB0aGF0IHRoaXMg Y3Jvc3MtYXJlYSB3b3JrIHdpbGwgcmVxdWlyZSBldmVyeW9uZSB0byB3ZWFyIHRoZWlyIGh1bWls aXR5IGhhdHMgbW9yZSBmcmVxdWVudGx5LiBJZiB5b3UgYXJlIGZydXN0cmF0ZWQsIGl0J3MgcGVy aGFwcyBiZWNhdXNlIHlvdSdyZSBlbmNvdW50ZXJpbmcgYW4gYXJlYSB0aGF0IHdhcyBmb3JlaWdu IHRvIHlvdSB1bnRpbCBub3cuIEVDTiBpcyBub3Qgb3V0c2lkZS10aGluayBmb3IgYW55b25lIHdo bydzIGJlZW4gd29ya2luZyBvbiB0cmFuc3BvcnQgcHJvdG9jb2xzIGZvciBtb3JlIHRoYW4gYSBk YXkuIEknZCBhc2sgYWJvdXQgc29tZXRoaW5nIHlvdSBkb24ndCB1bmRlcnN0YW5kIGZpcnN0LCBh bmQgdGhlbiBjb25zaWRlciBkZWNsYXJpbmcgdGhhdCB0aGUgd2cgc2hvdWxkIG5vdCB3b3JrIG9u IGl0Lg0KDQpBdXRob3JzIHNob3VsZCBub3QgcmVxdWlyZSByZWFkZXJzIHRvIGJlY29tZSBzdXBw bGljYW50cyBvciB3ZWFyICdodW1pbGl0eSBoYXRzJy4NCg0K4oCLSWYgeW91IHVzZSBhbiBhY3Jv bnltLCB5b3UgYWx3YXlzIGV4cGFuZCBpdCBvbiB0aGUgZmlyc3QgcmVmZXJlbmNlLiBJZiB5b3Ug YXJlIHVzaW5nIGEgZGVmaW5lZCB0ZXJtIHlvdSBhbHdheXMgY2l0ZSB0aGUgcmVmZXJlbmNlLuKA iyBJZiBFQ04gd2FzIHRoZSBvbmx5IHVuYm91bmQgYWNyb255bSBpbiB0aGUgaW50cm9kdWN0aW9u LCBJIG1pZ2h0IGhhdmUgbGV0IGl0IGdvLiBPbmx5IGl0IGNvbnRpbnVlcy4NCg0K4oCLIuKAiyBF Q04gYW5kIEw0UyBFQ04gYnkgbWVhbnMgb2YgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gdGhlIHVz ZSBvZiB0aGUNCiAgIEVDVCgwKSBhbmQgRUNUKDEpIGNvZGUgcG9pbnRzLiAgIg0KDQrigItUaGVy ZSBhcmUgdHdvIHJlYXNvbnMgdGhhdCBJIGRvbid0IGFjY2VwdCB3b3JrIG9mIHRoYXQga2luZC4g VGhlIGZpcnN0IGlzIHRoYXQgaXQgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgYW5kIGlmIEkgaGF2ZSB0 byBzdGFydCB3b3JraW5nIHRocm91Z2ggbG90cyBvZiBvdGhlciBkb2N1bWVudHMgdG8gd29yayBv dXQgd2hhdCB0aGUgYXV0aG9yIG1lYW5zLCBpdCBpcyBmYXIgbW9yZSBsaWtlbHkgdGhhbiBub3Qg dGhhdCB3ZSB3aWxsIGVuZCB1cCB3aXRoIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5ncyBvZiB3aGF0 IGlzIGJlaW5nIHNhaWQuDQoNCg0KDQpQcmVwYXJlIHRvIGJlIGZydXN0cmF0ZWQgbW9yZSBvZnRl bi4NCg0KT24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgNTozMyBQTSwgUGhpbGxpcCBIYWxsYW0tQmFr ZXIgPHBoaWxsQGhhbGxhbWJha2VyLmNvbTxtYWlsdG86cGhpbGxAaGFsbGFtYmFrZXIuY29tPj4g d3JvdGU6DQpOb3Qgc2FyY2FzdGljIGF0IGFsbC4gSnVzdCBmcnVzdHJhdGVkLiBSZWFkaW5nIGEg ZHJhZnQgc2hvdWxkIG5vdCByZXF1aXJlIHJlY291cnNlIHRvIFdpa2lwZWRpYS4NCg0KT24gV2Vk LCBGZWIgMjIsIDIwMTcgYXQgNzozMCBQTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN CkkgcmVhZCBQSELigJlzIGNvbW1lbnQgYXMgYSB0eXBpY2FsbHktc2FyY2FzdGljIHdheSBvZiBz YXlpbmcgdGhhdCB0aGUgSW50cm9kdWN0aW9uIG9mIHRoaXMgZHJhZnQgYXNzdW1lcyBxdWl0ZSBh IGJpdCBvZiBrbm93bGVkZ2UgdGhhdCBpcyBwZXJoYXBzIGJlc3Qgc3BlbGxlZCBvdXQgd2l0aCBz b21lIHJlbGV2YW50IGluZm9ybWF0aXZlIHJlZmVyZW5jZXMuICBUaGF0IGlzLCBhZnRlciBhbGws IHRoZSBwb2ludCBvZiBhbiBpbnRyb2R1Y3Rpb24uDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgMzoz NyBQTQ0KVG86IFBoaWxsaXAgSGFsbGFtLUJha2VyIDxwaGlsbEBoYWxsYW1iYWtlci5jb208bWFp bHRvOnBoaWxsQGhhbGxhbWJha2VyLmNvbT4+DQpDYzogJ2dvcnJ5QGVyZy5hYmRuLmFjLnVrPG1h aWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4nIChnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86 Z29ycnlAZXJnLmFiZG4uYWMudWs+KSA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5 QGVyZy5hYmRuLmFjLnVrPj47IEJvYiBCcmlzY29lIChpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0 bzppZXRmQGJvYmJyaXNjb2UubmV0PikgPGlldGZAYm9iYnJpc2NvZS5uZXQ8bWFpbHRvOmlldGZA Ym9iYnJpc2NvZS5uZXQ+PjsgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj47 IG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2g+OyBtYXJjZWxvIGJhZ251bG8gYnJhdW4gPG1hcmNlbG9AaXQudWMzbS5l czxtYWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzPj47IFBpZXJzIE8nSGFubG9uIDxwaWVycy5vaGFu bG9uQGNzLm94LmFjLnVrPG1haWx0bzpwaWVycy5vaGFubG9uQGNzLm94LmFjLnVrPj47IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBEZSBTY2hlcHBl ciwgS29lbiAoTm9raWEgLSBCRSkgPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNv bTxtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPj4NClN1YmplY3Q6 IFJlOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tcXVp Yy1lY24tMDEudHh0DQoNCk9uIFdlZCwgRmViIDIyLCAyMDE3IGF0IDEyOjU1IFBNLCBQaGlsbGlw IEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPG1haWx0bzpwaGlsbEBoYWxsYW1i YWtlci5jb20+PiB3cm90ZToNClRoaXMgaXMgdGhlIGVudGlyZXR5IG9mIHRoZSBpbnRyb2R1Y3Rp b246DQoNCiAgIEVDTiBzdXBwb3J0IGluIHRyYW5zcG9ydCBwcm90b2NvbHMgaXMgYSBmdW5kYW1l bnRhbCBmZWF0dXJlIHRoYXQNCiAgIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgUVVJQyBzcGVj aWZpY2F0aW9uIGFzIGEgbWFuZGF0b3J5IGVsZW1lbnQuDQogICBUaGUgYmVuZWZpdHMgb2YgRUNO IGlzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtYXFtLWVjbi1iZW5lZml0c10uICBUaGUNCiAgIEVD TiBzdXBwb3J0IHNob3VsZCBiZSBpbXBsZW1lbnRlZCB0byBzdXBwb3J0IGJvdGggcHJlc2VudCBh bmQgZnV0dXJlDQogICBFQ04sIHRoZSBsYXR0ZXIgaXMgb3V0bGluZWQgaW4gW0ktRC5pZXRmLXRz dndnLWVjbi1leHBlcmltZW50YXRpb25dLA0KICAgb2YgcGFydGljdWxhciBpbnRlcmVzdCBpcyB0 aGUgYWJpbGl0eSB0byBkaXNjcmltaW5hdGUgYmV0d2VlbiBjbGFzc2ljDQogICBFQ04gYW5kIEw0 UyBFQ04gYnkgbWVhbnMgb2YgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gdGhlIHVzZSBvZiB0aGUN CiAgIEVDVCgwKSBhbmQgRUNUKDEpIGNvZGUgcG9pbnRzLiAgVGhpcyBkcmFmdCBkb2VzIGhvd2V2 ZXIgbm90IGRlbHZlDQogICBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoZSBjb25nZXN0aW9uIGNvbnRy b2wgaW1wbGVtZW50YXRpb24uDQoNCkkgaGF2ZSBhYnNvbHV0ZWx5IG5vIGlkZWEgd2hhdCBFQ04g aXMuIEkgYW0gb3Bwb3NlZCB0byB0aGUgV0cgc3BlbmRpbmcgYW55IHRpbWUgb24gRUNOIHVudGls IGl0IGNhbiBiZSBleHBsYWluZWQgaW4gdGVybXMgdGhhdCBkbyBub3QgcmVmZXJlbmNlIHlldCBt b3JlIGphcmdvbi4NCg0KSGFwcHkgdG8gaGVscC4gRUNOIGlzIGRlZmluZWQgaW4gUkZDIDMxNjg8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjg+LCBhbmQgaXMgYW4gZXhwbGljaXQg c2lnbmFsIGZyb20gdGhlIGEgbmV0d29yayBzd2l0Y2ggb3Igcm91dGVyIGFib3V0IGNvbmdlc3Rp b24gYXQgYSBsaW5rLCBzbyB0aGF0IGVuZHBvaW50cyBjYW4gdXNlIHRoaXMgc2lnbmFsIGluc3Rl YWQgb2YgbG9zcyBmb3IgZGV0ZWN0aW5nIGFuZCByZWFjdGluZyB0byBjb25nZXN0aW9uLiBUaGUg YmVuZWZpdHMgb2YgZG9pbmcgdGhpcyBhcmUgZG9jdW1lbnRlZCBpbnQgaGUgSS1EIHRoYXQgaXMg bGlua2VkIGluIHRoZSBhYnN0cmFjdC4gRUNOIGhhcyBiZWVuIGEgcHJldHR5IHNpZ25pZmljYW50 IHRoaW5nIGluIHRyYW5zcG9ydCBmb3IgYWJvdXQgdHdvIGRlY2FkZXMsIGJ1dCBoYXMgaGFkIGFu IHVwaGlsbCBiYXR0bGUgc2luY2UgRUNOIHJlcXVpcmVzIHN1cHBvcnQgaW4gdGhlIG5ldHdvcmsg YW5kIGF0IGVuZHBvaW50cy4NCg0KVGhlcmUgaGF2ZSBiZWVuIG1hbnkgZWZmb3J0cyB0byB0cnkg YW5kIGRlcGxveSBpdCBpbiBuZXR3b3JrIGRldmljZXMgYW5kIGF0IGVuZHBvaW50cyBmb3IgYWJv dXQgYXMgbG9uZyBhcyBSRkMgMzE2OCBoYXMgZXhpc3RlZC4gRUNOIGhhcyBiZWVuIGRlcGxveWVk IGluIGJpdHMgYXQgcm91dGVycyBhbmQgaW4gZW5kcG9pbnRzLCBidXQgZHVlIHRvIGxvbmctc3Rh bmRpbmcgYnVncyBpbiBvbGRlciBob21lLXJvdXRlcnMgYW5kIHdpZmkgYm94ZXMsIGFuZCBpc3N1 ZXMgYXJvdW5kIHVzZSBvZiB0aGVzZSBiaXRzIGluIHRoZSBJUCBoZWFkZXIsIGl0IHdhcyBnZW5l cmFsbHkgbm90IHR1cm5lZCBvbiBhbnl3aGVyZS4gVGhpcyBzZWVtcyB0byBiZSBjaGFuZ2luZyBu b3csIGVzcGVjaWFsbHkgYXMgYnVmZmVyYmxvYXQgYmVjb21lcyBhbiBpbmNyZWFzaW5nbHkgdmlz aWJsZSBpc3N1ZS4gQnJpYW4gVHJhbW1lbGwgKElBQikgYW5kIE1pcmphIEt1ZWhsZXdpbmQgKFRy YW5zcG9ydCBBRCkgaGF2ZSBiZWVuIGFjdGl2ZWx5IGRvaW5nIG1lYXN1cmVtZW50IGFib3V0IHRo ZSBjdXJyZW50IGRlcGxveW1lbnQgc3RhdGUgb2YgRUNOOyBoZXJlJ3MgYSBibG9nIHBvc3QgYnkg QnJpYW48aHR0cHM6Ly9tYW1pLXByb2plY3QuZXUvaW5kZXgucGhwLzIwMTYvMDYvMTMvNzAtb2Yt cG9wdWxhci13ZWItc2l0ZXMtc3VwcG9ydC1lY24vPiBmcm9tIGxhc3Qgc3VtbWVyIHNheWluZyB0 aGF0IGEgbGFyZ2UgbnVtYmVyIG9mIHdlYnNlcnZlcnMgZG8gc3VwcG9ydCBFQ04uIFRoZXJlJ3Mg c3VwcG9ydCBmb3IgRUNOIGJ1aWx0IGludG8gVENQIChzZWUgU2VjdGlvbiAzLjIgYW5kIDQuMyBv ZiB0aGUgVENQIFJvYWRtYXAgUkZDPGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc0MTQ+KSwgdGhlcmUncyBiZWVuIGEgdG9uIG9mIHdvcmsgYXJvdW5kIHJlLXVzaW5nIEVDTiBz aWduYWxpbmcgZm9yIHJpY2hlciBjb25nZXN0aW9uIGluZm9ybWF0aW9uLg0KDQpTaW5jZSBUQ1Ag YW5kIFNDVFAgaGF2ZSBzdXBwb3J0IGZvciBFQ04sIGFuZCB0aGUgZnV0dXJlIG1heSBzZWUgRUNO IGRlcGxveW1lbnQgaW5jcmVhc2UgeWV0LCBpdCdzIGV4cGVjdGVkIHRoYXQgUVVJQyB3b3VsZCBo YXZlIGVxdWl2YWxlbnQgbWVjaGFuaXNtcyB0byBzdXBwb3J0IHVzZSBvZiBFQ04uIFRoaXMgd29y ayBpcyB2ZXJ5IG11Y2ggaW4gc2NvcGUsIGFzIHBhcnQgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJv bCBhc3BlY3Qgb2YgUVVJQy4NCg0KSG9wZSB0aGlzIGhlbHBzLA0KLSBqYW5hDQoNCg0KDQpPbiBX ZWQsIEZlYiAyMiwgMjAxNyBhdCAxMjoyMiBQTSwgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpIaQ0KDQpJIGp1c3QgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBv ZiB0aGUgRUNOIGluIFFVSUMgZHJhZnQuIFRoZSBtYWluIGNoYW5nZSBhIGRlc2NyaXB0aW9uIG9m IHRoZSBFQ04gbmVnb3RpYXRpb24uDQoNCi9JbmdlbWFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpTZW50OiBkZW4gMjIgZmVicnVhcmkgMjAxNyAwODo1 Ng0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+DQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAx LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEluZ2VtYXIgSm9oYW5zc29u IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRy YWZ0LWpvaGFuc3Nvbi1xdWljLWVjbg0KUmV2aXNpb246ICAgICAgIDAxDQpUaXRsZTogICAgICAg ICAgRUNOIHN1cHBvcnQgaW4gUVVJQw0KRG9jdW1lbnQgZGF0ZTogIDIwMTctMDItMjENCkdyb3Vw OiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMg0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1q b2hhbnNzb24tcXVpYy1lY24tMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24t MDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIG91dGxp bmVzIHRoZSBFQ04gc3VwcG9ydCBpbiBRVUlDLiAgVGhlIGludGVudGlvbiBpcyB0aGF0DQogICBt b3N0IG9mIHRoZSBtYXRlcmlhbCBlbmRzIHVwIHVwZGF0aW5nIG90aGVyIG5ldyBvciBleGlzdGlu ZyBRVUlDDQogICBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucywgdGh1cyBpdCBtYXkgYmUgcG9zc2li bGUgdGhhdCB0aGlzIGRyYWZ0IGRvZXMNCiAgIG5vdCB3YXJyYW50IGEgd29ya2luZyBncm91cCBz dGF0dXMuDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90 b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCg0K --_000_DB4PR07MB348512F16EC5B568D6460F5C2530DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBjYW4g YWRkIGEgbW9yZSBjb21wcmVoZW5zaXZlIHRleHQgdGhhdCBkZXNjcmliZXMgRUNOIGEgYml0IGFu ZCBhbiBleHBhbnNpb24gb2YgdGhlIGFjcm9ueW1zLCB0aGF0IHNvdW5kcyB2ZXJ5IHJlYXNvbmFi bGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkkgZG9u4oCZdCBob3dldmVyIHdhbnQgdG8gYWRkIGEgY29tcGxldGUgRUNOIGNy YXNoLWNvdXJzZSBpbnRvIHRoZSBkb2N1bWVudCAmbmJzcDthcyB0aGlzIHRleHQgYWxyZWFkeSBl eGlzdCBlbHNld2hlcmUgaW4gVFNWV0csIElDQ1JHICZuYnNwO2FuZCBBUU0gV0cgZG9jdW1lbnRz Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi9JbmdlbWFyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGhhbGxhbUBnbWFpbC5jb20gW21h aWx0bzpoYWxsYW1AZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsbGlwIEhhbGxh bS1CYWtlcjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMjMgZmVicnVhcmkgMjAxNyAwMzo1Mjxicj4N CjxiPlRvOjwvYj4gSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IE1pa2UgQmlzaG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tJmd0Ozsg J2dvcnJ5QGVyZy5hYmRuLmFjLnVrJyAoZ29ycnlAZXJnLmFiZG4uYWMudWspICZsdDtnb3JyeUBl cmcuYWJkbi5hYy51ayZndDs7IEJvYiBCcmlzY29lIChpZXRmQGJvYmJyaXNjb2UubmV0KSAmbHQ7 aWV0ZkBib2JicmlzY29lLm5ldCZndDs7IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIu cy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0OzsgbWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRo ei5jaDsNCiBtYXJjZWxvIGJhZ251bG8gYnJhdW4gJmx0O21hcmNlbG9AaXQudWMzbS5lcyZndDs7 IFBpZXJzIE8nSGFubG9uICZsdDtwaWVycy5vaGFubG9uQGNzLm94LmFjLnVrJmd0OzsgSUVURiBR VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0g QkUpICZsdDtrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1q b2hhbnNzb24tcXVpYy1lY24tMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDIyLCAyMDE3IGF0IDk6MzggUE0s IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlFVSUMsIGJ5IGJl aW5nIGNyb3NzLWFyZWEsIG1ha2VzIGl0IGRpZmZpY3VsdCBmb3IgZm9sa3MgdG8gcmV2aWV3IGFs bCBkb2NzLCBzaW5jZSBpdCdzIHVuY29tbW9uIGZvciBmb2xrcyB0byBrbm93IGV2ZXJ5dGhpbmcg YWJvdXQgYWxsIGFzcGVjdHMgb2YgVExTLCB0cmFuc3BvcnQsIGFuZCBIVFRQLzIuIFRoaXMgZG9l cyBtYWtlIGl0IGFuIG9wcG9ydHVuaXR5IHRvIHdyaXRlIGRyYWZ0cyB0aGF0IGFyZSBjbGVhcmVy DQogdG8gYSB3aWRlciBhdWRpZW5jZS4gSW4gdGhpcyBjYXNlLCBJIHRoaW5rIGEgcmVmZXJlbmNl IHRvIFJGQyAzMTY4IGFuZCBhIGNvdXBsZSBvZiBzZW50ZW5jZXMgb3VnaHQgdG8gYmUgYWRlcXVh dGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYXQgc2FpZCwgSSdsbCBub3RlIHRoYXQgdGhpcyBjcm9zcy1hcmVhIHdvcmsgd2lsbCByZXF1 aXJlIGV2ZXJ5b25lIHRvIHdlYXIgdGhlaXIgaHVtaWxpdHkgaGF0cyBtb3JlIGZyZXF1ZW50bHku IElmIHlvdSBhcmUgZnJ1c3RyYXRlZCwgaXQncyBwZXJoYXBzIGJlY2F1c2UgeW91J3JlIGVuY291 bnRlcmluZyBhbiBhcmVhIHRoYXQgd2FzIGZvcmVpZ24gdG8geW91IHVudGlsIG5vdy4gRUNOIGlz IG5vdCBvdXRzaWRlLXRoaW5rDQogZm9yIGFueW9uZSB3aG8ncyBiZWVuIHdvcmtpbmcgb24gdHJh bnNwb3J0IHByb3RvY29scyBmb3IgbW9yZSB0aGFuIGEgZGF5LiBJJ2QgYXNrIGFib3V0IHNvbWV0 aGluZyB5b3UgZG9uJ3QgdW5kZXJzdGFuZCBmaXJzdCwgYW5kIHRoZW4gY29uc2lkZXIgZGVjbGFy aW5nIHRoYXQgdGhlIHdnIHNob3VsZCBub3Qgd29yayBvbiBpdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXV0aG9ycyBzaG91bGQgbm90IHJlcXVpcmUgcmVhZGVycyB0byBiZWNvbWUgc3Vw cGxpY2FudHMgb3Igd2VhciAnaHVtaWxpdHkgaGF0cycuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAi0lmIHlvdSB1c2UgYW4gYWNyb255bSwg eW91IGFsd2F5cyBleHBhbmQgaXQgb24gdGhlIGZpcnN0IHJlZmVyZW5jZS4gSWYgeW91IGFyZSB1 c2luZyBhIGRlZmluZWQgdGVybSB5b3UgYWx3YXlzIGNpdGUgdGhlIHJlZmVyZW5jZS7igIsgSWYg RUNOIHdhcyB0aGUgb25seSB1bmJvdW5kIGFjcm9ueW0gaW4gdGhlIGludHJvZHVjdGlvbiwgSSBt aWdodCBoYXZlIGxldCBpdCBnby4gT25seSBpdCBjb250aW51ZXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAiyZxdW90O+KAiyBFQ04gYW5k IEw0UyBFQ04gYnkgbWVhbnMgb2YgZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gdGhlIHVzZSBvZiB0 aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtFQ1QoMCkgYW5kIEVDVCgxKSBjb2RlIHBvaW50cy4gJm5ic3A7JnF1b3Q7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAi1RoZXJlIGFyZSB0d28gcmVhc29ucyB0aGF0IEkgZG9uJ3QgYWNjZXB0IHdv cmsgb2YgdGhhdCBraW5kLiBUaGUgZmlyc3QgaXMgdGhhdCBpdCBtYWtlcyBubyBzZW5zZSB0byBt ZSBhbmQgaWYgSSBoYXZlIHRvIHN0YXJ0IHdvcmtpbmcgdGhyb3VnaCBsb3RzIG9mIG90aGVyIGRv Y3VtZW50cyB0byB3b3JrIG91dCB3aGF0IHRoZSBhdXRob3IgbWVhbnMsIGl0IGlzIGZhciBtb3Jl IGxpa2VseSB0aGFuIG5vdCB0aGF0DQogd2Ugd2lsbCBlbmQgdXAgd2l0aCBkaWZmZXJlbnQgdW5k ZXJzdGFuZGluZ3Mgb2Ygd2hhdCBpcyBiZWluZyBzYWlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlByZXBhcmUgdG8gYmUgZnJ1c3RyYXRlZCBtb3JlIG9mdGVuLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgRmViIDIyLCAyMDE3IGF0IDU6MzMgUE0sIFBoaWxsaXAgSGFsbGFtLUJha2VyICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbGxAaGFsbGFtYmFrZXIuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp bGxAaGFsbGFtYmFrZXIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc2FyY2FzdGljIGF0 IGFsbC4gSnVzdCBmcnVzdHJhdGVkLiBSZWFkaW5nIGEgZHJhZnQgc2hvdWxkIG5vdCByZXF1aXJl IHJlY291cnNlIHRvIFdpa2lwZWRpYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAyMiwgMjAxNyBh dCA3OjMwIFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgcmVhZCBQSELigJlzIGNvbW1lbnQgYXMgYSB0 eXBpY2FsbHktc2FyY2FzdGljIHdheSBvZiBzYXlpbmcgdGhhdCB0aGUgSW50cm9kdWN0aW9uIG9m IHRoaXMgZHJhZnQgYXNzdW1lcyBxdWl0ZSBhIGJpdCBvZiBrbm93bGVkZ2UgdGhhdCBpcyBwZXJo YXBzIGJlc3Qgc3BlbGxlZCBvdXQgd2l0aCBzb21lIHJlbGV2YW50DQogaW5mb3JtYXRpdmUgcmVm ZXJlbmNlcy4mbmJzcDsgVGhhdCBpcywgYWZ0ZXIgYWxsLCB0aGUgcG9pbnQgb2YgYW4gaW50cm9k dWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuYSBJ eWVuZ2FyPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgMzoz NyBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbGxpcCBIYWxsYW0tQmFrZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpwaGlsbEBoYWxsYW1iYWtlci5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsbEBoYWxsYW1i YWtlci5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJzxhIGhyZWY9Im1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPicg KDxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmdv cnJ5QGVyZy5hYmRuLmFjLnVrPC9hPikgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJk bi5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDs7IEJv Yg0KIEJyaXNjb2UgKDxhIGhyZWY9Im1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0IiB0YXJnZXQ9 Il9ibGFuayI+aWV0ZkBib2JicmlzY29lLm5ldDwvYT4pICZsdDs8YSBocmVmPSJtYWlsdG86aWV0 ZkBib2JicmlzY29lLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+ Jmd0OzsgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2luZEB0aWsuZWUu ZXRoei5jaDwvYT47IG1hcmNlbG8gYmFnbnVsbyBicmF1biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1h cmNlbG9AaXQudWMzbS5lcyIgdGFyZ2V0PSJfYmxhbmsiPm1hcmNlbG9AaXQudWMzbS5lczwvYT4m Z3Q7OyBQaWVycyBPJ0hhbmxvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBpZXJzLm9oYW5sb25AY3Mu b3guYWMudWsiIHRhcmdldD0iX2JsYW5rIj5waWVycy5vaGFubG9uQGNzLm94LmFjLnVrPC9hPiZn dDs7DQogSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgRGUgU2NoZXBwZXIsIEtvZW4gKE5v a2lhIC0gQkUpICZsdDs8YSBocmVmPSJtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxs LWxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxh YnMuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQ8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g V2VkLCBGZWIgMjIsIDIwMTcgYXQgMTI6NTUgUE0sIFBoaWxsaXAgSGFsbGFtLUJha2VyICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbGxAaGFsbGFtYmFrZXIuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhp bGxAaGFsbGFtYmFrZXIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpcyB0aGUgZW50aXJldHkgb2YgdGhl IGludHJvZHVjdGlvbjogJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7RUNOIHN1cHBvcnQgaW4gdHJhbnNw b3J0IHByb3RvY29scyBpcyBhIGZ1bmRhbWVudGFsIGZlYXR1cmUgdGhhdDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7c2hv dWxkIGJlIGluY2x1ZGVkIGluIHRoZSBRVUlDIHNwZWNpZmljYXRpb24gYXMgYSBtYW5kYXRvcnkg ZWxlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7ICZuYnNwO1RoZSBiZW5lZml0cyBvZiBFQ04gaXMgZGVzY3JpYmVkIGluIFtJ LUQuaWV0Zi1hcW0tZWNuLWJlbmVmaXRzXS4mbmJzcDsgVGhlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtFQ04gc3VwcG9y dCBzaG91bGQgYmUgaW1wbGVtZW50ZWQgdG8gc3VwcG9ydCBib3RoIHByZXNlbnQgYW5kIGZ1dHVy ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7RUNOLCB0aGUgbGF0dGVyIGlzIG91dGxpbmVkIGluIFtJLUQuaWV0Zi10c3Z3 Zy1lY24tZXhwZXJpbWVudGF0aW9uXSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO29mIHBhcnRpY3VsYXIgaW50ZXJlc3Qg aXMgdGhlIGFiaWxpdHkgdG8gZGlzY3JpbWluYXRlIGJldHdlZW4gY2xhc3NpYzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 RUNOIGFuZCBMNFMgRUNOIGJ5IG1lYW5zIG9mIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIHRoZSB1 c2Ugb2YgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDtFQ1QoMCkgYW5kIEVDVCgxKSBjb2RlIHBvaW50cy4mbmJzcDsg VGhpcyBkcmFmdCBkb2VzIGhvd2V2ZXIgbm90IGRlbHZlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtpbnRvIHRoZSBkZXRh aWxzIG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgYWJz b2x1dGVseSBubyBpZGVhIHdoYXQgRUNOIGlzLiBJIGFtIG9wcG9zZWQgdG8gdGhlIFdHIHNwZW5k aW5nIGFueSB0aW1lIG9uIEVDTiB1bnRpbCBpdCBjYW4gYmUgZXhwbGFpbmVkIGluIHRlcm1zIHRo YXQgZG8gbm90IHJlZmVyZW5jZSB5ZXQgbW9yZSBqYXJnb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGFwcHkgdG8gaGVscC4gRUNOIGlzIGRlZmluZWQgaW4NCjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMTY4IiB0YXJnZXQ9Il9ibGFuayI+UkZDIDMx Njg8L2E+LCBhbmQgaXMgYW4gZXhwbGljaXQgc2lnbmFsIGZyb20gdGhlIGEgbmV0d29yayBzd2l0 Y2ggb3Igcm91dGVyIGFib3V0IGNvbmdlc3Rpb24gYXQgYSBsaW5rLCBzbyB0aGF0IGVuZHBvaW50 cyBjYW4gdXNlIHRoaXMgc2lnbmFsIGluc3RlYWQgb2YgbG9zcyBmb3IgZGV0ZWN0aW5nIGFuZCBy ZWFjdGluZyB0byBjb25nZXN0aW9uLg0KIFRoZSBiZW5lZml0cyBvZiBkb2luZyB0aGlzIGFyZSBk b2N1bWVudGVkIGludCBoZSBJLUQgdGhhdCBpcyBsaW5rZWQgaW4gdGhlIGFic3RyYWN0LiBFQ04g aGFzIGJlZW4gYSBwcmV0dHkgc2lnbmlmaWNhbnQgdGhpbmcgaW4gdHJhbnNwb3J0IGZvciBhYm91 dCB0d28gZGVjYWRlcywgYnV0IGhhcyBoYWQgYW4gdXBoaWxsIGJhdHRsZSBzaW5jZSBFQ04gcmVx dWlyZXMgc3VwcG9ydCBpbiB0aGUgbmV0d29yayBhbmQgYXQgZW5kcG9pbnRzLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl cmUgaGF2ZSBiZWVuIG1hbnkgZWZmb3J0cyB0byB0cnkgYW5kIGRlcGxveSBpdCBpbiBuZXR3b3Jr IGRldmljZXMgYW5kIGF0IGVuZHBvaW50cyBmb3IgYWJvdXQgYXMgbG9uZyBhcyBSRkMgMzE2OCBo YXMgZXhpc3RlZC4gRUNOIGhhcyBiZWVuIGRlcGxveWVkIGluIGJpdHMgYXQgcm91dGVycyBhbmQg aW4NCiBlbmRwb2ludHMsIGJ1dCBkdWUgdG8gbG9uZy1zdGFuZGluZyBidWdzIGluIG9sZGVyIGhv bWUtcm91dGVycyBhbmQgd2lmaSBib3hlcywgYW5kIGlzc3VlcyBhcm91bmQgdXNlIG9mIHRoZXNl IGJpdHMgaW4gdGhlIElQIGhlYWRlciwgaXQgd2FzIGdlbmVyYWxseSBub3QgdHVybmVkIG9uIGFu eXdoZXJlLiBUaGlzIHNlZW1zIHRvIGJlIGNoYW5naW5nIG5vdywgZXNwZWNpYWxseSBhcyBidWZm ZXJibG9hdCBiZWNvbWVzIGFuIGluY3JlYXNpbmdseSB2aXNpYmxlDQogaXNzdWUuIEJyaWFuIFRy YW1tZWxsIChJQUIpIGFuZCBNaXJqYSBLdWVobGV3aW5kIChUcmFuc3BvcnQgQUQpIGhhdmUgYmVl biBhY3RpdmVseSBkb2luZyBtZWFzdXJlbWVudCBhYm91dCB0aGUgY3VycmVudCBkZXBsb3ltZW50 IHN0YXRlIG9mIEVDTjsgaGVyZSdzIGENCjxhIGhyZWY9Imh0dHBzOi8vbWFtaS1wcm9qZWN0LmV1 L2luZGV4LnBocC8yMDE2LzA2LzEzLzcwLW9mLXBvcHVsYXItd2ViLXNpdGVzLXN1cHBvcnQtZWNu LyIgdGFyZ2V0PSJfYmxhbmsiPg0KYmxvZyBwb3N0IGJ5IEJyaWFuPC9hPiZuYnNwO2Zyb20gbGFz dCBzdW1tZXIgc2F5aW5nIHRoYXQgYSBsYXJnZSBudW1iZXIgb2Ygd2Vic2VydmVycyBkbyBzdXBw b3J0IEVDTi4gVGhlcmUncyBzdXBwb3J0IGZvciBFQ04gYnVpbHQgaW50byBUQ1AgKHNlZSBTZWN0 aW9uIDMuMiBhbmQgNC4zIG9mIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzQxNCIgdGFyZ2V0PSJfYmxhbmsiPlRDUCBSb2FkbWFwIFJGQzwvYT4pLCB0 aGVyZSdzIGJlZW4gYSB0b24gb2Ygd29yayBhcm91bmQgcmUtdXNpbmcgRUNOIHNpZ25hbGluZyBm b3IgcmljaGVyIGNvbmdlc3Rpb24gaW5mb3JtYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TaW5jZSBUQ1AgYW5kIFNDVFAgaGF2 ZSBzdXBwb3J0IGZvciBFQ04sIGFuZCB0aGUgZnV0dXJlIG1heSBzZWUgRUNOIGRlcGxveW1lbnQg aW5jcmVhc2UgeWV0LCBpdCdzIGV4cGVjdGVkIHRoYXQgUVVJQyB3b3VsZCBoYXZlIGVxdWl2YWxl bnQgbWVjaGFuaXNtcyB0byBzdXBwb3J0IHVzZSBvZiBFQ04uIFRoaXMNCiB3b3JrIGlzIHZlcnkg bXVjaCBpbiBzY29wZSwgYXMgcGFydCBvZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGFzcGVjdCBv ZiBRVUlDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SG9wZSB0aGlzIGhlbHBzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBXZWQsIEZlYiAyMiwgMjAxNyBhdCAxMjoyMiBQTSwgSW5nZW1hciBKb2hh bnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaTxicj4NCjxicj4NCkkganVz dCB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBFQ04gaW4gUVVJQyBkcmFmdC4gVGhlIG1h aW4gY2hhbmdlIGEgZGVzY3JpcHRpb24gb2YgdGhlIEVDTiBuZWdvdGlhdGlvbi48YnI+DQo8YnI+ DQovSW5nZW1hcjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPl08YnI+DQpTZW50OiBkZW4gMjIgZmVicnVhcmkgMjAxNyAwODo1Njxicj4N ClRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pbmdlbWFyLnMuam9oYW5zc29u QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEudHh0PGJyPg0KPGJyPg0KPGJyPg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJbmdlbWFyIEpvaGFuc3NvbiBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbjxicj4N ClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAxPGJyPg0KVGl0bGU6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBFQ04gc3VwcG9ydCBpbiBRVUlDPGJyPg0KRG9j dW1lbnQgZGF0ZTombmJzcDsgMjAxNy0wMi0yMTxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxMjxicj4NClVSTDombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpvaGFu c3Nvbi1xdWljLWVjbi0wMS50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1qb2hhbnNzb24tcXVpYy1lY24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLzwvYT48YnI+DQpIdG1s aXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMTwv YT48YnI+DQpEaWZmOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWpvaGFuc3Nvbi1x dWljLWVjbi0wMSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDE8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6 PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgbWVtbyBvdXRsaW5lcyB0aGUgRUNOIHN1cHBvcnQgaW4g UVVJQy4mbmJzcDsgVGhlIGludGVudGlvbiBpcyB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwO21vc3Qg b2YgdGhlIG1hdGVyaWFsIGVuZHMgdXAgdXBkYXRpbmcgb3RoZXIgbmV3IG9yIGV4aXN0aW5nIFFV SUM8YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMsIHRodXMgaXQgbWF5 IGJlIHBvc3NpYmxlIHRoYXQgdGhpcyBkcmFmdCBkb2VzPGJyPg0KJm5ic3A7ICZuYnNwO25vdCB3 YXJyYW50IGEgd29ya2luZyBncm91cCBzdGF0dXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYg U2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB4PR07MB348512F16EC5B568D6460F5C2530DB4PR07MB348eurprd_-- From nobody Thu Mar 9 07:59:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A1212955D for ; Thu, 9 Mar 2017 07:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzTGy_ssaPrB for ; Thu, 9 Mar 2017 07:59:31 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0123.outbound.protection.outlook.com [104.47.37.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCBF129407 for ; Thu, 9 Mar 2017 07:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ny+fnJODD4SoZCTDL3sPzfexHHScu7wIeGRL/3ByLMk=; b=dtgYn4333seyd/qd1vb7lntfMwPsIWyQ2SK78G8rPIf2NNWu25do1ePW8eWPYRWcv2K4g+Gh7GvfxIM1VcyuT7NnnKVTThppRFgduRPB7aYcpAVy8jTNK/IcmiRmRHjFtvlIzW+0l5wGMXkvnL7NYC0b7YrjkY6rTHs33pSmYVw= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 15:59:29 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 15:59:29 +0000 From: Mike Bishop To: Ian Swett , Stefan Eissing Subject: RE: Divergence from HTTP/2 Thread-Topic: Divergence from HTTP/2 Thread-Index: AdKYd70rURZiuYADRA293Bil8tNr6AAPNMmAAAs0oAAAAu01AA== Date: Thu, 9 Mar 2017 15:59:28 +0000 Message-ID: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8300:3b9a:d0ce:a235:e7d3:26cc] x-ms-office365-filtering-correlation-id: c9afdae5-7185-4046-ee32-08d4670544bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:drphK1ptPhUq3vfKDd0yrrg/tirUFv2IuQhd6AKCVYAZET3BXbhiEpcs7GluKWeiHf4Zuc+UVEAygCaozOHET4XS/UBooFEcAvfb63lKFoVKyhAToPAammUVoxJA92wZrMYW0Hn6PHuHKIqvX9+msTv27cRQHvdSDwAYoikAq/YhjisKyNde8y+47kQLjf3NEDtF9UwEhBMsw5BaHWHs5fmB9P++69myJgwB6EV1yNL1GOhQ8RDl7t4VEF15JVWvdY6kxSOx0KqbViv7ekAXj57FPm33owU8GI7jCEOdhuB3eeaOghE7S1T8cCz0y0GgIZc4O+rizyLGFTS0G+TwP9tGgoO6ZFurNr47OOSpX60= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(24454002)(377454003)(2900100001)(53546006)(74316002)(4326008)(5005710100001)(10290500002)(5660300001)(6306002)(19609705001)(10090500001)(86362001)(2950100002)(38730400002)(6246003)(8990500004)(2906002)(122556002)(50986999)(6506006)(54356999)(6436002)(76176999)(8936002)(55016002)(236005)(99286003)(86612001)(8676002)(54896002)(33656002)(7906003)(53936002)(7696004)(606005)(790700001)(3280700002)(189998001)(229853002)(77096006)(7736002)(102836003)(25786008)(6116002)(3660700001)(9686003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27082EA0E375114390E1E24087210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 15:59:28.9534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:59:33 -0000 --_000_BN6PR03MB27082EA0E375114390E1E24087210BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gbWUsIGl04oCZcyBhIG1vc3RseSBlZGl0b3JpYWwgZGlmZmVyZW5jZSDigJMgZG8gd2UgdHJ5 IHRvIGNvbnRvcnQgdGhlIElBTkEgcmVnaXN0cnkgdG8gY2xhaW0gdGhlc2UgYXJlIHR3byB2YXJp YW50cyBvZiB0aGUgc2FtZSBwcm90b2NvbCwgb3IgZG8gd2UganVzdCB0ZWxsIElBTkEgdGhleeKA mXJlIGRpZmZlcmVudCBwcm90b2NvbHMgd2l0aCBkaWZmZXJlbnQgcmVnaXN0cmllcz8gIEkgZG9u 4oCZdCBzZWUgdGhhdCBvbmUgY2hvaWNlIGltcGxpZXMgYSBsYXJnZXIgc2NvcGUgdGhhbiB0aGUg b3RoZXIuICBJIHRoaW5rIHRoZSBtaXNzaW9uIGlzIHN0aWxsIHRoZSBzYW1lIOKAkyBkZWxpdmVy IEhUVFAgc2VtYW50aWNzIG92ZXIgUVVJQy4NCg0KV2XigJl2ZSBhbHJlYWR5IGRlY2lkZWQgd2Xi gJlyZSB3aWxsaW5nIHRvIG1ha2UgYSBudW1iZXIgb2YgZGVwYXJ0dXJlcyBmcm9tIEhUVFAvMiBi ZWNhdXNlIGl0IG1ha2VzIHRlY2huaWNhbCBzZW5zZSBpbiBlYWNoIGluZGl2aWR1YWwgY2FzZS4g IE9idmlvdXNseSwgaWYgUVVJQyB0YWtlcyBhIGRyYW1hdGljIHR1cm4gKGUuZy4gdW5yZWxhdGVk IHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgaW4gZWFjaCBkaXJlY3Rpb24pIHRoZSBIVFRQIG1hcHBp bmcgd291bGQgZG8gbGlrZXdpc2UgaW4gcmVzcG9uc2UgKHNlZSBicmFuY2ggdW5pZGlyZWN0aW9u YWwyKS4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNl bnQ6IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDY6MjggQU0NClRvOiBTdGVmYW4gRWlzc2luZyA8 c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4NCkNjOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5C aXNob3BAbWljcm9zb2Z0LmNvbT47IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBEaXZlcmdl bmNlIGZyb20gSFRUUC8yDQoNClRoYW5rcyBmb3Igc2VuZGluZyB0aGlzIG91dCB0byB0aGUgbGlz dC4gIEkgYWx3YXlzIGhvcGVkIHdlIGNvdWxkIGtlZXAgSFRUUCBvdmVyIFFVSUMgYXMgc2ltaWxh ciB0byBIMiBhcyBwb3NzaWJsZSwgYnV0IGFzIHlvdSd2ZSBwb2ludGVkIG91dCBwcmV2aW91c2x5 LCBhIGxvdCBvZiBIVFRQLzIgd2FzIGFkZGluZyB0cmFuc3BvcnQgZmVhdHVyZXMgc3VjaCBhcyBt dWx0aXBsZSBzdHJlYW1zIGFuZCBmbG93IGNvbnRyb2wgb24gdG9wIG9mIGFuIGV4aXN0aW5nIHRy YW5zcG9ydC4gIFN3aXRjaGluZyB0byBRUEFDSyB3b3VsZCBiZSBhbm90aGVyIGRyYW1hdGljIGRl cGFydHVyZS4NCg0KSSdtIG5vdCBleGNpdGVkIGFib3V0IFFVSUMgYWJhbmRvbmluZyBIVFRQMiwg YnV0IGl0IG1heSBtYWtlIGVub3VnaCB0ZWNobmljYWwgYW5kIGRvY3VtZW50YXRpb24gc2Vuc2Ug dG8gYmUgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLiAgSSBhbSBjb25jZXJuZWQgdGhpcyBjb3VsZCBl eHBhbmQgdGhlIHNjb3BlIG9mIHRoZSBIVFRQIG1hcHBpbmcgdG9vIG11Y2gsIHNvIGlmIHdlJ3Jl IGdvaW5nIHRvIG1ha2UgdGhpcyBjaG9pY2UsIEknZCBsaWtlIHRvIGtub3cgd2hhdCB0eXBlcyBv ZiBjaGFuZ2VzIGFyZSBpbiBzY29wZS4NCg0KT24gVGh1LCBNYXIgOSwgMjAxNyBhdCA0OjA3IEFN LCBTdGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTxtYWlsdG86c3Rl ZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4+IHdyb3RlOg0KVGhhbmtzIGZvciBzZXBhcmF0aW5n IHRoaXMgb3V0LCBNaWtlLiBGb3Igc3BhcmUgdGltZSBmb2xrcyB0aGlzIG1ha2VzIGZvbGxvd2lu ZyB0aGlzIGFzcGVjdCBlYXNpZXIuDQoNCk15IGZpcnN0IGltcHJlc3Npb24gaXMgdGhhdCBhbnkg aG9wZSB0byBoYXZlIGh0dHAvMiBvdmVyIHRjcCBhbmQgcXVpYyBuZWVkcyB0byBiZSBhYmFuZG9u ZWQuIFdoaWNoIHdpbGwgZ2l2ZSB0aGUgd29ybGQgYSB0aGlyZCBwcm90b2NvbCB0byBjYXJyeSBo dHRwIHNlbWFudGljcy4NCg0KV2hhdCBkb2VzIHRoYXQgbWVhbiBmb3IgdGhlIGV2b2x1dGlvbiBv ZiBodHRwLCBJIHdvbmRlci4NCg0KLXN0ZWZhbg0KDQpBbSAwOS4wMy4yMDE3IHVtIDAzOjE2IHNj aHJpZWIgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PjoNCkF0IHRoaXMgcG9pbnQsIEkgZG9u4oCZdCB0 aGluayBhbnlvbmUgZXhwZWN0cyB0aGF0IEhUVFAvUVVJQyBhbmQgSFRUUC8yIGFyZSB0aGUgc2Ft ZSBwcm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBkcmFmdCBjdXJyZW50bHkgc3RpbGwgYXR0ZW1wdHMg dG8gZGVmaW5lIHRoZW0gYXMgY2xvc2UgY291c2lucy4gIEluIFBSICMzNjM8aHR0cHM6Ly9naXRo dWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM2Mz4sIEnigJl2ZSBjb25zb2xpZGF0ZWQg YWxtb3N0IGFsbCBvZiB0aGUg4oCcZGlmZmVyZW50IGZyb20gSFRUUC8y4oCdIHRleHQgaW50byBh IG5ldyBzZWN0aW9uIGFuZCBleGNpc2VkIGEgbG90IG9mIHN0dWZmIGFib3V0IOKAnEhUVFAvMiBo YXMgdGhpcywgYnV0IEhUVFAvUVVJQyBkb2VzbuKAmXQgbmVlZCBpdOKAnSBmcm9tIHRoZSBtYWlu IGJvZHkgb2YgdGhlIGRvY3VtZW50LiAgTWFydGluIGhhcyBhZHZvY2F0ZWQgbWFraW5nIGEgY2xl YW4gYnJlYWsgZnJvbSBIVFRQLzIgYW5kIGRlZmluaW5nIG91ciBvd24gSUFOQSByZWdpc3RyeSBm b3IgZnJhbWUgdHlwZXMgYW5kIHNldHRpbmdzLCBqdXN0IGFzIHdlIGFscmVhZHkgaGF2ZSBmb3Ig ZXJyb3JzLiAgV2UgY2FuLCBvdXQgb2YgcmVzcGVjdCBmb3IgbGVnYWN5LCB1c2UgdGhlIHNhbWUg dmFsdWVzIHdoZXJlIGFwcHJvcHJpYXRlIGFuZCByZXNlcnZlIGV4aXN0aW5nIHZhbHVlcyBjdXJy ZW50bHkgaW4gdXNlIG9uIHRoZSBIVFRQLzIgc2lkZS4NCg0KSSB0aGluayB0aGF04oCZcyBhIGdv b2QgaWRlYSwgYW5kIGl04oCZcyBhIGZhaXJseSBzbWFsbCBzdGVwIGZyb20gdGhlIGN1cnJlbnQg c3RhdGUgb2YgIzM2My4gIEnigJl2ZSBjcmVhdGVkIFBSICMzNzY8aHR0cHM6Ly9naXRodWIuY29t L3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM3Nj4gdG8gYWN0dWFsbHkgbWFrZSB0aGF0IHNwbGl0 Lg0KDQpDb21tZW50cyBmcm9tIHRoZSBXRyBhYm91dCBlaXRoZXIgd291bGQgYmUgd2VsY29tZS4N Cg0K --_000_BN6PR03MB27082EA0E375114390E1E24087210BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5UbyBtZSwgaXTigJlzIGENCjxpPm1vc3RseTwvaT4gZWRpdG9yaWFsIGRpZmZlcmVuY2Ug 4oCTIGRvIHdlIHRyeSB0byBjb250b3J0IHRoZSBJQU5BIHJlZ2lzdHJ5IHRvIGNsYWltIHRoZXNl IGFyZSB0d28gdmFyaWFudHMgb2YgdGhlIHNhbWUgcHJvdG9jb2wsIG9yIGRvIHdlIGp1c3QgdGVs bCBJQU5BIHRoZXnigJlyZSBkaWZmZXJlbnQgcHJvdG9jb2xzIHdpdGggZGlmZmVyZW50IHJlZ2lz dHJpZXM/Jm5ic3A7IEkgZG9u4oCZdCBzZWUgdGhhdCBvbmUgY2hvaWNlIGltcGxpZXMgYSBsYXJn ZXIgc2NvcGUNCiB0aGFuIHRoZSBvdGhlci4mbmJzcDsgSSB0aGluayB0aGUgbWlzc2lvbiBpcyBz dGlsbCB0aGUgc2FtZSDigJMgZGVsaXZlciBIVFRQIHNlbWFudGljcyBvdmVyIFFVSUMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPldl4oCZdmUgYWxyZWFkeSBkZWNpZGVkIHdl4oCZcmUgd2lsbGluZyB0byBtYWtl IGEgbnVtYmVyIG9mIGRlcGFydHVyZXMgZnJvbSBIVFRQLzIgYmVjYXVzZSBpdCBtYWtlcyB0ZWNo bmljYWwgc2Vuc2UgaW4gZWFjaCBpbmRpdmlkdWFsIGNhc2UuJm5ic3A7IE9idmlvdXNseSwgaWYg UVVJQyB0YWtlcyBhIGRyYW1hdGljDQogdHVybiAoZS5nLiB1bnJlbGF0ZWQgdW5pZGlyZWN0aW9u YWwgc3RyZWFtcyBpbiBlYWNoIGRpcmVjdGlvbikgdGhlIEhUVFAgbWFwcGluZyB3b3VsZCBkbyBs aWtld2lzZSBpbiByZXNwb25zZSAoc2VlIGJyYW5jaCB1bmlkaXJlY3Rpb25hbDIpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSWFuIFN3ZXR0IFtt YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg TWFyY2ggOSwgMjAxNyA2OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBTdGVmYW4gRWlzc2luZyAmbHQ7 c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlz aG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRGl2ZXJnZW5jZSBmcm9tIEhUVFAvMjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Igc2VuZGluZyB0aGlzIG91dCB0 byB0aGUgbGlzdC4mbmJzcDsgSSBhbHdheXMgaG9wZWQgd2UgY291bGQga2VlcCBIVFRQIG92ZXIg UVVJQyBhcyBzaW1pbGFyIHRvIEgyIGFzIHBvc3NpYmxlLCBidXQgYXMgeW91J3ZlIHBvaW50ZWQg b3V0IHByZXZpb3VzbHksIGEgbG90IG9mIEhUVFAvMiB3YXMgYWRkaW5nIHRyYW5zcG9ydCBmZWF0 dXJlcyBzdWNoIGFzIG11bHRpcGxlIHN0cmVhbXMgYW5kIGZsb3cgY29udHJvbA0KIG9uIHRvcCBv ZiBhbiBleGlzdGluZyB0cmFuc3BvcnQuJm5ic3A7IFN3aXRjaGluZyB0byBRUEFDSyB3b3VsZCBi ZSBhbm90aGVyIGRyYW1hdGljIGRlcGFydHVyZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgZXhjaXRlZCBhYm91dCBRVUlDIGFiYW5kb25pbmcg SFRUUDIsIGJ1dCBpdCBtYXkgbWFrZSBlbm91Z2ggdGVjaG5pY2FsIGFuZCBkb2N1bWVudGF0aW9u IHNlbnNlIHRvIGJlIHRoZSByaWdodCB0aGluZyB0byBkby4mbmJzcDsgSSBhbSBjb25jZXJuZWQg dGhpcyBjb3VsZCBleHBhbmQgdGhlIHNjb3BlIG9mIHRoZSBIVFRQIG1hcHBpbmcgdG9vIG11Y2gs IHNvIGlmIHdlJ3JlIGdvaW5nIHRvIG1ha2UgdGhpcw0KIGNob2ljZSwgSSdkIGxpa2UgdG8ga25v dyB3aGF0IHR5cGVzIG9mIGNoYW5nZXMgYXJlIGluIHNjb3BlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciA5LCAy MDE3IGF0IDQ6MDcgQU0sIFN0ZWZhbiBFaXNzaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFu LmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZWZhbi5laXNzaW5nQGdy ZWVuYnl0ZXMuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Igc2VwYXJhdGluZyB0 aGlzIG91dCwgTWlrZS4gRm9yIHNwYXJlIHRpbWUgZm9sa3MgdGhpcyBtYWtlcyBmb2xsb3dpbmcg dGhpcyBhc3BlY3QgZWFzaWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NeSBmaXJzdCBpbXByZXNzaW9uIGlzIHRoYXQgYW55IGhvcGUgdG8g aGF2ZSBodHRwLzIgb3ZlciB0Y3AgYW5kIHF1aWMgbmVlZHMgdG8gYmUgYWJhbmRvbmVkLiBXaGlj aCB3aWxsIGdpdmUgdGhlIHdvcmxkIGEgdGhpcmQgcHJvdG9jb2wgdG8gY2FycnkgaHR0cCBzZW1h bnRpY3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoYXQgZG9lcyB0aGF0IG1lYW4gZm9yIHRoZSBldm9sdXRpb24gb2YgaHR0cCwgSSB3b25k ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPi1zdGVmYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KQW0gMDkuMDMuMjAxNyB1bSAwMzoxNiBzY2hyaWViIE1pa2UgQmlzaG9wICZsdDs8 YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhpcyBw b2ludCwgSSBkb27igJl0IHRoaW5rIGFueW9uZSBleHBlY3RzIHRoYXQgSFRUUC9RVUlDIGFuZCBI VFRQLzIgYXJlIHRoZSBzYW1lIHByb3RvY29sLiZuYnNwOyBIb3dldmVyLCB0aGUgZHJhZnQgY3Vy cmVudGx5IHN0aWxsIGF0dGVtcHRzIHRvIGRlZmluZSB0aGVtIGFzIGNsb3NlIGNvdXNpbnMuJm5i c3A7IEluDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1 bGwvMzYzIiB0YXJnZXQ9Il9ibGFuayI+UFIgIzM2MzwvYT4sIEnigJl2ZSBjb25zb2xpZGF0ZWQg YWxtb3N0IGFsbCBvZiB0aGUg4oCcZGlmZmVyZW50IGZyb20gSFRUUC8y4oCdIHRleHQgaW50byBh IG5ldyBzZWN0aW9uIGFuZCBleGNpc2VkIGEgbG90IG9mIHN0dWZmIGFib3V0IOKAnEhUVFAvMiBo YXMgdGhpcywgYnV0IEhUVFAvUVVJQyBkb2VzbuKAmXQgbmVlZCBpdOKAnSBmcm9tDQogdGhlIG1h aW4gYm9keSBvZiB0aGUgZG9jdW1lbnQuJm5ic3A7IE1hcnRpbiBoYXMgYWR2b2NhdGVkIG1ha2lu ZyBhIGNsZWFuIGJyZWFrIGZyb20gSFRUUC8yIGFuZCBkZWZpbmluZyBvdXIgb3duIElBTkEgcmVn aXN0cnkgZm9yIGZyYW1lIHR5cGVzIGFuZCBzZXR0aW5ncywganVzdCBhcyB3ZSBhbHJlYWR5IGhh dmUgZm9yIGVycm9ycy4mbmJzcDsgV2UgY2FuLCBvdXQgb2YgcmVzcGVjdCBmb3IgbGVnYWN5LCB1 c2UgdGhlIHNhbWUgdmFsdWVzIHdoZXJlIGFwcHJvcHJpYXRlDQogYW5kIHJlc2VydmUgZXhpc3Rp bmcgdmFsdWVzIGN1cnJlbnRseSBpbiB1c2Ugb24gdGhlIEhUVFAvMiBzaWRlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF04oCZcyBhIGdvb2QgaWRlYSwgYW5kIGl04oCZ cyBhIGZhaXJseSBzbWFsbCBzdGVwIGZyb20gdGhlIGN1cnJlbnQgc3RhdGUgb2YgIzM2My4mbmJz cDsgSeKAmXZlIGNyZWF0ZWQNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvcHVsbC8zNzYiIHRhcmdldD0iX2JsYW5rIj5QUiAjMzc2PC9hPiB0byBhY3R1YWxs eSBtYWtlIHRoYXQgc3BsaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db21tZW50cyBm cm9tIHRoZSBXRyBhYm91dCBlaXRoZXIgd291bGQgYmUgd2VsY29tZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB27082EA0E375114390E1E24087210BN6PR03MB2708namp_-- From nobody Thu Mar 9 08:09:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5724012949E for ; Thu, 9 Mar 2017 08:09:16 -0800 (PST) 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, 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 7V6zoQ_DVsZB for ; Thu, 9 Mar 2017 08:09:14 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499E5129496 for ; Thu, 9 Mar 2017 08:09:14 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6078C340F3C; Thu, 9 Mar 2017 17:09:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.21432); Thu, 9 Mar 2017 17:09:12 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 9 Mar 2017 17:09:12 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10953054; Thu, 09 Mar 2017 17:09:12 +0100 Subject: Re: Middlebox introspection/self-describing packets Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_ACEA8F8E-18B6-4ABF-8D26-E8FA531BFB9D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell (IETF) In-Reply-To: Date: Thu, 9 Mar 2017 17:09:11 +0100 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:09:16 -0000 --Apple-Mail=_ACEA8F8E-18B6-4ABF-8D26-E8FA531BFB9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Ekr, all, > > Well, with negotiation, someone has to decide. The bit just moves = that to the client. > > Except that if the load balancer *needs* it, then the client has to = conform. >=20 >> The load balancer needs it to balance load efficiently. >>=20 > That's not entirely clear. Note that in the original QUIC design, the = client supplied > the connection ID, so the server side merely had to load balance based = on some combination > of a random value and the client's IP. Right; should have said that "the assertion behind server-suggested = Connection ID proposal is that it's needed for efficient load = balancing". I'm taking that assertion at face value now, possibly = because I'm convinced of the utility of one of its side-effects: = providing some additional grade of assurance to a device on path that a = given packet was not injected off-path, which is useful in in-network = DoS mitigation (as in section 3.3 of the just-submitted manageability = draft). >> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at = the cost of degraded performance. (I would like to reiterate that I do think that it's necessary to allow = clients to veto server-proposed connection ID exposure.) >> (f that's not the case, if failure to send connection ID leads to = connection failure, then "negotiation" is a euphemism: the server = informs the client whether it must send a connection ID, probably = encrypted, and nobody needs any flags, unless the presence of connection = ID changes the offsets of fields we *do* want to explicitly expose, such = as packet number echo (https://github.com/quicwg/base-drafts/issues/269) = or troubleshooting flags = (https://github.com/quicwg/base-drafts/issues/279). >=20 > Not to put too fine a point on it, but there's far from consensus that = we want to expose > either of these. That's not too fine a point at all; I'm not presupposing consensus on = either of these. All I'm saying here is, should consensus emerge that = the benefits outweigh the costs (both in complexity and in risk) for = certain kinds of exposure to the path -- which I think may be the case = for some of the things under discussion in 279, and I'm obviously = convinced of the utility of packet number echo as in 269 or I wouldn't = have submitted two PRs on it -- we need to be clear that other choices = we make about the layout of the header doesn't make that harder than it = needs to be. Sticking variable-length/optional fields whose presence is = dependent on endpoint-shared state after the exposed fields is probably = sufficient for this. Cheers, Brian --Apple-Mail=_ACEA8F8E-18B6-4ABF-8D26-E8FA531BFB9D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwX4nAAoJEIoSt78L6kajyIsP/jVQ4ZYxmLa4lYThGJgf95va Bdxcv+tPEfBrIPAGGZj61xofu7NwpSUyyzkOZwqn3HZSRuy0etvq5oGO8arAFXx/ XNzwd5+Dd8uv6lypfPGpoVQLP9JsQLDXRLGZ8P/BJWJoN2l2nUpyS+N1Kd1AC5cw XzfE1w/ItyRbBI7wim+wweh+j0S+WytOsVeUb9Na+lyT6VIwm6j4E34T0tSz/GA9 h7aLOyYvIqI8gTL2A09bSdlyLQmzspzh7NAEw8X3xRiPp8O6GBt/YbatBV2UxVf1 Ep92ArbrSYPUKMIMtEO92ywEEnUkXopMfoxM3UWpd/jwOfHwJL5Ty7Tj4lbqoX1J HE6XCqUJJZSCCU6WdPYfdObzLJPBuNWk4GIEsfLP6WtZXjN77DEwpevdU2DhPfpS qdDLMRYXkEyJitYXKXc0aWt7Zs1EvxnU+x8ohdw4xzqcgi6dhngqYaG39c/a7Dqo 1NFkzD+fHOo4ZF/pArzf/HVX2BsBOQ92ZDdamYAZ/+QvKS2qzbuBEPQFYvuPPrnG BNxxXRJqv1cWXwelD6FpmflcesJ0eE0DQTpQfxW2+YTIsTAvss6xnw8z8nTa3I4b TiNbcZVdVjDu0PTkyxeIeCiYZfKfr4efxMUWmRk2mf0s4HwevbzdYrzLV/n7WMAz aiD4BPj66aj/wWOkeZgJ =6aIG -----END PGP SIGNATURE----- --Apple-Mail=_ACEA8F8E-18B6-4ABF-8D26-E8FA531BFB9D-- From nobody Thu Mar 9 08:46:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8CA129451 for ; Thu, 9 Mar 2017 08:46:31 -0800 (PST) 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, 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 WrcksBifRYMI for ; Thu, 9 Mar 2017 08:46:29 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637C5126CD8 for ; Thu, 9 Mar 2017 08:46:29 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E0106340C81; Thu, 9 Mar 2017 17:46:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.27941); Thu, 9 Mar 2017 17:46:27 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 9 Mar 2017 17:46:27 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 10957637; Thu, 09 Mar 2017 17:46:27 +0100 Subject: Re: Return of the alternate header proposal Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AE27F378-99E2-4F41-8400-A946C7799A28"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 9 Mar 2017 17:46:27 +0100 Message-Id: <3040C4D2-3EA5-4680-8501-C26EFF44E08C@trammell.ch> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG , Martin Thomson , Patrick McManus X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:46:31 -0000 --Apple-Mail=_AE27F378-99E2-4F41-8400-A946C7799A28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 to land it. Cheers, Brian > On 09 Mar 2017, at 15:10, Eric Rescorla wrote: >=20 > As Martin notes, I think there are a number of things that need = discussion here, but I'm happy to land it as a step in the right = direction. >=20 > On Thu, Mar 9, 2017 at 5:04 AM, Patrick McManus = wrote: >=20 > On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson = wrote: > hope > that the people reviewing this will identify new issues where this PR > fell short of meeting their goals. Is that an acceptable process > here? >=20 >=20 > I completely agree with this. At this relatively early stage we need = to lean harder into landing stuff and then opening follow-on issues.. = right now there is a significant body of work that you have to hold in = your head "I know roughly how this is going to change" to meaningfully = use even the editor's copy - closing that gap would be very helpful. = Obviously the header is a big one. >=20 > For something like this I would suggest marking it consensus and = perhaps just commenting on any known caveats to help with paper trail. >=20 --Apple-Mail=_AE27F378-99E2-4F41-8400-A946C7799A28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwYbjAAoJEIoSt78L6kaj0NkQAKTyXcLOfz2rrMsFNm/7yiXX TEcj73ThHyObL1iLRLoUh5js+VcHgy2zQaB9LKMCTGD4TQ9et5Fsw1nZVxxYNYNF WgkxaA4XHp1tmZ0zQhHBe8X2S1DWm+cF+QLpny3a4H5Tisvxu7chgZiYN6UkVbzx 4xBgzQ7eGxRGnZXJxvT/M7v2I5NyKuywVkv+/2LF0K2fS/KD0YfJxRbzcFwJpnFv bz8F2eSoq46v7d4TvSDeYgLg4WsyDn+sjSMheeHLdKXkBOuaGsICanmmWH8Y6Rw+ 3hVl5KYjXsGwsdJW6OcWCBQoY1uVmUPeFPF9BR7eX9REPnKuU2HKo/vcL9TJbZnJ PfBe15luQ+G3rW5M1cs3a/NSPXvnEDpMKPlzsV3Y9ePcD9VXwVJxyIr4NU3ts6xG Ld04BWvhhkAMn24Zkuc5PIezoT2BejkAmabEavJIlUnke7SUum9DWayYOzKsP/fl GIqB7NIUi1mbvoYigMhh7YlgmsRxMkQzegeh4/ruyjFp5qZkgd1t96s/4GNtKFf4 J4E/JzSQ2AVHU3k8H6SOrYXzBjUDmPn9aH0U/DAXx9qnL5UQ+QA8cZSD+0mYKV9E 7uRXPQ+gCaQcEK7lhYyFTrY3bTuFmSciafnEQQ7KP2SQpNqxnseXAlTv+xg9nuW8 Xwyh35kMlnGh5BbpRPfy =hxMm -----END PGP SIGNATURE----- --Apple-Mail=_AE27F378-99E2-4F41-8400-A946C7799A28-- From nobody Thu Mar 9 08:58:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C401294FF for ; Thu, 9 Mar 2017 08:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKCKhZzcUCQc for ; Thu, 9 Mar 2017 08:58:34 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004D912948B for ; Thu, 9 Mar 2017 08:58:33 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id y76so128738708qkb.0 for ; Thu, 09 Mar 2017 08:58:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uRytAqAtU6GwudmMIsHY7AmkFEn5cei1WdM7Wg/JI8Y=; b=gJ8Y+Esj06/ps1mkL5GsPe6xZsD+mHho1sThACFRWC7N7RS9XOTUcjGxwtGMchbmS8 KPPnRa4oVN9QEUmTW12wsnYhNnx1vxgIhKYzi2U0QyQtwo4lcm22ScUpdQEx313h1reu Wg8A1Hiz4lBc9h+WEClbsGWVnLKqgx3Du1FnA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uRytAqAtU6GwudmMIsHY7AmkFEn5cei1WdM7Wg/JI8Y=; b=J42HFTJV/n7eCjQzxYVYZOMGSkEWKKr59/0IP72//OB13fC+XU3SC7QWGMwubKqIk+ Ma99tx9nLz6CY3JkPH1mXRBvZtlr3Sr2h0o7TYv6qTkJxYJ+PDwFCMVC5B9xoMDc/dI7 hawvamDbRZ7+OMBRYVR9h7h9IhlNrYbdHizpJGsSMuXx7byMDa8qBD65B7oXbS2NL/Nc NuqXuEYUfYpjOMRTcc48bHauM23Dwm1eAOiEnptH05LqHfg6tWeIVd3Dad6XLR1H4tvf SatDVTZCyHPcN4pcTTPkr4nLOo1jQlCfyUplog6HnAH7KR91OPU2StcsMOKkp4pI9JaS jvCQ== X-Gm-Message-State: AFeK/H0/ncHd/3OXpK/80oB2UbhYI0wCnZtTTcxDI0pV6u0q246xtlCzFM1llScOKbcMEbjfUmfSMb7rgt3pWA== X-Received: by 10.55.142.69 with SMTP id q66mr14437909qkd.13.1489078712885; Thu, 09 Mar 2017 08:58:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Thu, 9 Mar 2017 08:58:32 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: From: Kyle Rose Date: Thu, 9 Mar 2017 11:58:32 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c083c7ab990dc054a4f2720 Archived-At: Cc: "Brian Trammell \(IETF\)" , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:58:37 -0000 --94eb2c083c7ab990dc054a4f2720 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 10:08 AM, Eric Rescorla wrote: > That too-tightly constrains load balancing. Without connection tracking >> (which means shared state across multiple machines in a farm of load >> balancers) or a server-chosen cookie, you're limited to algorithms that are >> a function of connection ID and 5-tuple. In particular, you can't choose a >> target server based on its current load. Random assignment may be good >> enough for some application profiles, but not all. >> > > Well, that may be true, but I'm merely observing that that's the present > design of gQUIC. > Understood. I just didn't want the gQUIC approach to be considered universally applicable on the basis of that statement. I'd still rather find a way to separate minimal load balancer state from session state, and to protect the latter, but I'm not sure if there's a way to do it that provides real value (i.e., isn't just advisory). Kyle --94eb2c083c7ab990dc054a4f2720 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 10:08 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
That too-tightly constrains load bala= ncing. Without connection tracking (which means shared state across multipl= e machines in a farm of load balancers) or a server-chosen cookie, you'= re limited to algorithms that are a function of connection ID and 5-tuple. = In particular, you can't choose a target server based on its current lo= ad. Random assignment may be good enough for some application profiles, but= not all.

Well, that may be tru= e, but I'm merely observing that that's the present design of gQUIC= .=C2=A0

Understood.= I just didn't want the gQUIC approach to be considered universally app= licable on the basis of that statement.

I'd still rather find a = way to separate minimal load balancer state from session state, and to prot= ect the latter, but I'm not sure if there's a way to do it that pro= vides real value (i.e., isn't just advisory).

Kyle
--94eb2c083c7ab990dc054a4f2720-- From nobody Thu Mar 9 09:08:07 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB901295D6 for ; Thu, 9 Mar 2017 09:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 15DwrIMGCyWp for ; Thu, 9 Mar 2017 09:08:04 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 05865129417 for ; Thu, 9 Mar 2017 09:08:04 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id q7so71566043uaf.2 for ; Thu, 09 Mar 2017 09:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WHAJesZEPEmtA/L1iMHcL2KYgjGJxpfDqqV1yZp1kVM=; b=UL7VXcaMmsN7xCY/Jrkl0DOwtFNnmRONxuBj2rs9eE49z2et3+rhzbFMQ5D4G5DHeg J0HMh5si2sE8imZAgnZJEcthOqMV7nXj78ieh+unwYLA9qeBBVwnVA1/zt6f5Gu2eqLL C7WpIZCq87nU9DmJjXWATkU2CIcv7iKg/hLjc9rX4HJmdoVxKZO/uYRyyaTvO86qMUaz 90EXkCHYVrGTYdyNjhpvI14F8Zxf3h5XxC8AvBHg+X8tfy9DQzQp0V+OwjVeEk1Zmaj+ pD6plAa0xFs+DhdLWAuDvChs+xeugG/4ff6gSC59HF7NtjXDFS0YKJYlXdTMK96i84Cu 3Uvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WHAJesZEPEmtA/L1iMHcL2KYgjGJxpfDqqV1yZp1kVM=; b=bToYM4nDk+RdWrqQ/uykmlMyWnRencU8AKSnmVNsjtoKByFxpbRQ2J3LVx4JlYMULx O6wOrKCuf6BcsbynQUf4S63jVx/oVBW80e4bJW+NO0nSqpWYZy8l/80o52SK3SOSR1xI ct1f+mSsR14kgJFT/TdEYdujczwsVnkflB13znX//s8RdeP4AfRoaUUn+n6lXLZDEk+Q E1RlC+DlpkcPDNQRCDbEp0u0dOAeyMdlxkDLnfNqhhvboZsJym1lB43BfV/qRZ/w0WBn ENgqAzRhx/5gMXbme8lOw4eFkcy6Xtp1WdNAddGGrpSiIzMle1kI/6tkyrC0FtVOlXwD ROUg== X-Gm-Message-State: AMke39nO4xHs2rKxzfUw1+Kdw1p6j5pqZpi93pnNNAC2weSGn1e5wlQnZ4vt0CNJmqLyDexFJbGV5/kkZSe75GUw X-Received: by 10.176.8.5 with SMTP id a5mr6680549uaf.143.1489079281185; Thu, 09 Mar 2017 09:08:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 9 Mar 2017 09:08:00 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Mar 2017 09:08:00 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Brian Trammell Content-Type: multipart/alternative; boundary=f403045f882e99bab0054a4f493f Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 17:08:07 -0000 --f403045f882e99bab0054a4f493f Content-Type: text/plain; charset=UTF-8 A thoughts as I catch up on this thread (and in response to ekr's original question): - As ekr points out, server-side middleboxes can always rely on connection IDs by policy. The value of the connection ID bit, in my mind, is for middleboxes not controlled by the server. Such middleboxes are likely to use the connection ID to identify connections where it exists. Without an explicit per-packet bit, a middlebox that wants to use connection ID will have to dig into the handshake to determine where it's presence negotiated. This leads to ossification of bits inside the cleartext handshake messages, which is highly undesirable. I'd rather that the connection ID bit be ossified. - As it stands, connection ID negotiation means that each side tells the peer what it wants the peer to do. In a world with (i) no connection ID bit and (ii) clients vetoing the server's request, policy decisions are hard for load balancers. In this world, there's no good way for server-side load balancers to know per connection whether it has a connection ID or not: to find connection state, the load balancer needs a key, which would be the connection ID, which may or may not be present for that connection. The load balancer could use the 4-tuple to key the connection, but that entirely defeats the point of using the connection ID. - The privacy implications of sharing connection ID is a separate conversation from the one this thread was started on. Though since some points were raised here and since they speak to the question of what information to share with middleboxes, I'll share my thoughts. We need to separate the use of connection ID use across NAT rebindings vs the use of connection ID use across client network changes. We'd all probably agree that NAT rebindings for UDP are a real concern, since NATs kill these bindings faster than they do TCP bindings. A TCP connection would have its connection identifier (the 4-tuple) be stable for the lifetime of a TCP connection. A QUIC connection would be similar, with the difference that the connection identifier here would be the connection ID. The connection ID does not expose any more state than a TCP connection would in this case. We'd all agree that connection ID use across client network changes is a new beast. To this end, I think we've generally agreed (informally anyways) that the client must use a new connection ID when it triggers connection migration to a different network. In sum, my argument is that having connection IDs stable across NAT rebindings is a necessity for QUIC to work well. As a result, middleboxes at various points in the network, specifically those past a NAT, are expected to use it to track connection state. Explicitly noting its presence in the packet anticipates this and eliminates this one reason for ossification of other bits deep in handshake messages needed otherwise for its inference. - jana On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: > hi Ekr, all, > > > > Well, with negotiation, someone has to decide. The bit just moves that > to the client. > > > Except that if the load balancer *needs* it, then the client has to > conform. > > > >> The load balancer needs it to balance load efficiently. > >> > > That's not entirely clear. Note that in the original QUIC design, the > client supplied > > the connection ID, so the server side merely had to load balance based > on some combination > > of a random value and the client's IP. > > Right; should have said that "the assertion behind server-suggested > Connection ID proposal is that it's needed for efficient load balancing". > I'm taking that assertion at face value now, possibly because I'm convinced > of the utility of one of its side-effects: providing some additional grade > of assurance to a device on path that a given packet was not injected > off-path, which is useful in in-network DoS mitigation (as in section 3.3 > of the just-submitted manageability draft). > > >> I presume that a client that was very interested in not providing > tracking information could refuse to make Connection ID available, at the > cost of degraded performance. > > (I would like to reiterate that I do think that it's necessary to allow > clients to veto server-proposed connection ID exposure.) > > >> (f that's not the case, if failure to send connection ID leads to > connection failure, then "negotiation" is a euphemism: the server informs > the client whether it must send a connection ID, probably encrypted, and > nobody needs any flags, unless the presence of connection ID changes the > offsets of fields we *do* want to explicitly expose, such as packet number > echo (https://github.com/quicwg/base-drafts/issues/269) or > troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279). > > > > Not to put too fine a point on it, but there's far from consensus that > we want to expose > > either of these. > > That's not too fine a point at all; I'm not presupposing consensus on > either of these. All I'm saying here is, should consensus emerge that the > benefits outweigh the costs (both in complexity and in risk) for certain > kinds of exposure to the path -- which I think may be the case for some of > the things under discussion in 279, and I'm obviously convinced of the > utility of packet number echo as in 269 or I wouldn't have submitted two > PRs on it -- we need to be clear that other choices we make about the > layout of the header doesn't make that harder than it needs to be. Sticking > variable-length/optional fields whose presence is dependent on > endpoint-shared state after the exposed fields is probably sufficient for > this. > > > Cheers, > > Brian > > --f403045f882e99bab0054a4f493f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A thoughts as I catch up on this thread (and in response t= o ekr's original question):

- As ekr points out, serv= er-side middleboxes can always rely on connection IDs by policy. The value = of the connection ID bit, in my mind, is for middleboxes not controlled by = the server. Such middleboxes are likely to use the connection ID to identif= y connections where it exists. Without an explicit per-packet bit, a middle= box that wants to use connection ID will have to dig into the handshake to = determine where it's presence negotiated. This leads to ossification of= bits inside the cleartext handshake messages, which is highly undesirable.= I'd rather that the connection ID bit be ossified.
- As it stands, connection ID negotiation means that each side = tells the peer what it wants the peer to do. In a world with (i) no connect= ion ID bit and (ii) clients vetoing the server's request, policy decisi= ons are hard for load balancers. In this world, there's no good way for= server-side load balancers to know per connection whether it has a connect= ion ID or not: to find connection state, the load balancer needs a key, whi= ch would be the connection ID, which may or may not be present for that con= nection. The load balancer could use the 4-tuple to key the connection, but= that entirely defeats the point of using the connection ID.

=
- The privacy implications of sharing connection ID is a separat= e conversation from the one this thread was started on. Though since some p= oints were raised here and since they speak to the question of what informa= tion to share with middleboxes, I'll share my thoughts.=C2=A0

We need to separate the use of connection ID use across NAT= rebindings vs the use of connection ID use across client network changes.= =C2=A0

We'd all probably agree that NAT rebind= ings for UDP are a real concern, since NATs kill these bindings faster than= they do TCP bindings. A TCP connection would have its connection identifie= r (the 4-tuple) be stable for the lifetime of a TCP connection. A QUIC conn= ection would be similar, with the difference that the connection identifier= here would be the connection ID. The connection ID does not expose any mor= e state than a TCP connection would in this case.

<= div>We'd all agree that connection ID use across client network changes= is a new beast. To this end, I think we've generally agreed (informall= y anyways) that the client must use a new connection ID when it triggers co= nnection migration to a different network.

In sum,= my argument is that having connection IDs stable across NAT rebindings is = a necessity for QUIC to work well. As a result, middleboxes at various poin= ts in the network, specifically those past a NAT, are expected to use it to= track connection state. Explicitly noting its presence in the packet antic= ipates this and eliminates this one reason for ossification of other bits d= eep in handshake messages needed otherwise for its inference.
- jana


On Thu, Mar 9, 2017 at 8:09 AM, Brian Tra= mmell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian


--f403045f882e99bab0054a4f493f-- From nobody Thu Mar 9 09:16:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4611112966B for ; Thu, 9 Mar 2017 09:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1A_1XmRfHhRA for ; Thu, 9 Mar 2017 09:16:35 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id EBFD4129493 for ; Thu, 9 Mar 2017 09:16:34 -0800 (PST) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id 824903A0A7 for ; Thu, 9 Mar 2017 12:16:34 -0500 (EST) Received: by mail-qk0-f179.google.com with SMTP id 1so129010479qkl.3 for ; Thu, 09 Mar 2017 09:16:34 -0800 (PST) X-Gm-Message-State: AFeK/H0R+b3bHVDER75k5lS9x0nWDKnpvSWyyoM/70ZjvPpg7S7hEgxWkGjxA+jS2C77H8KYji84D3tkuU+RBQ== X-Received: by 10.55.78.68 with SMTP id c65mr14540170qkb.305.1489079794135; Thu, 09 Mar 2017 09:16:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.177.130 with HTTP; Thu, 9 Mar 2017 09:16:33 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Thu, 9 Mar 2017 12:16:33 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 To: Mike Bishop Content-Type: multipart/alternative; boundary=001a114a9b8c2c0693054a4f6800 Archived-At: Cc: "Brian Trammell \(IETF\)" , Ian Swett , Hannes Tschofenig , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 17:16:36 -0000 --001a114a9b8c2c0693054a4f6800 Content-Type: text/plain; charset=UTF-8 no joke - I tested out 53/80/443 on a Digital Ocean virtual host last weekend and only 53 moved bidirectionally (it all worked inbound) - though I suspect that's more bug than policy and can be resolved by market interest. --001a114a9b8c2c0693054a4f6800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
no joke - I tested out 53/80/443 on a Digital Ocean v= irtual host last weekend and only 53 moved bidirectionally (it all worked i= nbound) - though I suspect that's more bug than policy and can be resol= ved by market interest.


--001a114a9b8c2c0693054a4f6800-- From nobody Thu Mar 9 09:33:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713CF1295A9 for ; Thu, 9 Mar 2017 09:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scbtRSZGdj2f for ; Thu, 9 Mar 2017 09:33:36 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8755A1294E8 for ; Thu, 9 Mar 2017 09:33:36 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id v76so11137923ywg.0 for ; Thu, 09 Mar 2017 09:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ij/P6XdCAjBil0POSMc31cozPfA8r8GLw28l8FEaWgA=; b=1Q2PmbSlihUj20F6Z/YRdH8W8KVZ4zkK8gzAwtqZiZzHAfbp2LX4UkWLOuH/g6Zj0a dq3EGbK5TPDo/fODWwCnQovHt+3O7xA+jJ7YshrIYbdVz7vo30bwJlcadGXZ9cJZ7ifV crtBxaYESxttUcXHBeksTKoYjkZmBaCtgZNXB5oEWBnocvv2he5orEaVSX1nCbnDzFS9 LcQ3EDNtkchbbd3k7tGRlEjd1sN0KRs65Sv51Qx/a2+8unMTnWIAdhW+xhFWrcGy0ffd QXfQcscFstq1gxTpF2LqVYc58u/8nBwp2EQmvmByR1OAO1hr+0tKX+TJ+ZmgGZtism5m no0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ij/P6XdCAjBil0POSMc31cozPfA8r8GLw28l8FEaWgA=; b=LDm/Fur+xAkjCha9x4iCGL/Y/NIRNeCii8VihUxbntAHhLpABFqDbwqmpv/bkAEDcB Pr4iuiVugoU6DPMEhI3sGBC3ZWJwvT0ba96COVDjVZmhCTGwCJ9IdHVrI4JVijNpTKe8 SHAHYhdOWznxIMkMWZ+ptt9Raj+e9EMBCyzDKwqrgWnmulQRJEuQ9Kguqb644dH8djtN yJXz6iwmdhep/qdUWACJH3+/AouIIV5JEVI2hWUga2DbkqbzolPmZ7vXc4FXNxiGQrOD wKR0oHSMf0uJUykkKuH4tzOHKO9Y/Fh5C1c23sPHEy2rcKsmKuc8DErc5PdM1B60FFbZ Rxxw== X-Gm-Message-State: AMke39m/pEUKbivxg55NOngtDW6Wk6JujGC8SUFXI7rjmv9kQsJVE2TjtAQsJGbGxDH7ijgaxG9qe+p/H5hEkQ== X-Received: by 10.129.152.22 with SMTP id p22mr5018000ywg.276.1489080815705; Thu, 09 Mar 2017 09:33:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 09:32:55 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 09:32:55 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c0b8fb40ffbd7054a4fa50c Archived-At: Cc: Brian Trammell , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 17:33:39 -0000 --94eb2c0b8fb40ffbd7054a4fa50c Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: > A thoughts as I catch up on this thread (and in response to ekr's original > question): > > - As ekr points out, server-side middleboxes can always rely on connection > IDs by policy. The value of the connection ID bit, in my mind, is for > middleboxes not controlled by the server. Such middleboxes are likely to > use the connection ID to identify connections where it exists. Without an > explicit per-packet bit, a middlebox that wants to use connection ID will > have to dig into the handshake to determine where it's presence negotiated. > This leads to ossification of bits inside the cleartext handshake messages, > which is highly undesirable. I'd rather that the connection ID bit be > ossified. > Sure, but this starts from the position that middleboxes should be using connection IDs. It's not clear to me that we want to encourage that. > - As it stands, connection ID negotiation means that each side tells the > peer what it wants the peer to do. In a world with (i) no connection ID bit > and (ii) clients vetoing the server's request, policy decisions are hard > for load balancers. In this world, there's no good way for server-side load > balancers to know per connection whether it has a connection ID or not: to > find connection state, the load balancer needs a key, which would be the > connection ID, which may or may not be present for that connection. The > load balancer could use the 4-tuple to key the connection, but that > entirely defeats the point of using the connection ID. > Hmm... This seems rather more to be the result of letting the client veto. In the design you propose, the server does: - If connection id bit is 1 look up connection ID - Otherwise, look up the host/port If you don't have a bit, you can - Look up the host/port - If it's missing assume that there is a connection ID and look for it - If that's missing, drop the packet > - The privacy implications of sharing connection ID is a separate > conversation from the one this thread was started on. Though since some > points were raised here and since they speak to the question of what > information to share with middleboxes, I'll share my thoughts. > > We need to separate the use of connection ID use across NAT rebindings vs > the use of connection ID use across client network changes. > > We'd all probably agree that NAT rebindings for UDP are a real concern, > since NATs kill these bindings faster than they do TCP bindings. > Actually, no, I'm not persuaded by this as yet. I agree with the statement that NATs kill these bindings faster, but it's not yet clear to me that connection IDs ameliorate these problems sufficiently to improve the situation. I'd be happy to see any data you have that supports this point. We'd all agree that connection ID use across client network changes is a > new beast. To this end, I think we've generally agreed (informally anyways) > that the client must use a new connection ID when it triggers connection > migration to a different network. > The difficulty is that we do not presently know how to arrange that you always use a new conn id on migration without using a new conn id on each packet. In sum, my argument is that having connection IDs stable across NAT > rebindings is a necessity for QUIC to work well. As a result, middleboxes > at various points in the network, specifically those past a NAT, are > expected to use it to track connection state. Explicitly noting its > presence in the packet anticipates this and eliminates this one reason for > ossification of other bits deep in handshake messages needed otherwise for > its inference. > I don't see you arguing that this is desirable so much as inevitable. So, if we had a design that was reasonably efficient that used a different connection ID per packet, then you would be fine with that and wouldn't feel the need to tell middleboxes where it was? -Ekr > > - jana > > > On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: > >> hi Ekr, all, >> >> > > Well, with negotiation, someone has to decide. The bit just moves >> that to the client. >> > > Except that if the load balancer *needs* it, then the client has to >> conform. >> > >> >> The load balancer needs it to balance load efficiently. >> >> >> > That's not entirely clear. Note that in the original QUIC design, the >> client supplied >> > the connection ID, so the server side merely had to load balance based >> on some combination >> > of a random value and the client's IP. >> >> Right; should have said that "the assertion behind server-suggested >> Connection ID proposal is that it's needed for efficient load balancing". >> I'm taking that assertion at face value now, possibly because I'm convinced >> of the utility of one of its side-effects: providing some additional grade >> of assurance to a device on path that a given packet was not injected >> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >> of the just-submitted manageability draft). >> >> >> I presume that a client that was very interested in not providing >> tracking information could refuse to make Connection ID available, at the >> cost of degraded performance. >> >> (I would like to reiterate that I do think that it's necessary to allow >> clients to veto server-proposed connection ID exposure.) >> >> >> (f that's not the case, if failure to send connection ID leads to >> connection failure, then "negotiation" is a euphemism: the server informs >> the client whether it must send a connection ID, probably encrypted, and >> nobody needs any flags, unless the presence of connection ID changes the >> offsets of fields we *do* want to explicitly expose, such as packet number >> echo (https://github.com/quicwg/base-drafts/issues/269) or >> troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279). >> > >> > Not to put too fine a point on it, but there's far from consensus that >> we want to expose >> > either of these. >> >> That's not too fine a point at all; I'm not presupposing consensus on >> either of these. All I'm saying here is, should consensus emerge that the >> benefits outweigh the costs (both in complexity and in risk) for certain >> kinds of exposure to the path -- which I think may be the case for some of >> the things under discussion in 279, and I'm obviously convinced of the >> utility of packet number echo as in 269 or I wouldn't have submitted two >> PRs on it -- we need to be clear that other choices we make about the >> layout of the header doesn't make that harder than it needs to be. Sticking >> variable-length/optional fields whose presence is dependent on >> endpoint-shared state after the exposed fields is probably sufficient for >> this. >> >> >> Cheers, >> >> Brian >> >> > --94eb2c0b8fb40ffbd7054a4fa50c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar <jri@google.com> wrote:
A thoughts as = I catch up on this thread (and in response to ekr's original question):=

- As ekr points out, server-side middleboxes can always = rely on connection IDs by policy. The value of the connection ID bit, in my= mind, is for middleboxes not controlled by the server. Such middleboxes ar= e likely to use the connection ID to identify connections where it exists. = Without an explicit per-packet bit, a middlebox that wants to use connectio= n ID will have to dig into the handshake to determine where it's presen= ce negotiated. This leads to ossification of bits inside the cleartext hand= shake messages, which is highly undesirable. I'd rather that the connec= tion ID bit be ossified.

Sure, but this starts from the position that middleboxes should be us= ing connection
IDs. It's not clear to me that we want to enco= urage that.


- As it stands, connection ID negotiation mea= ns that each side tells the peer what it wants the peer to do. In a world w= ith (i) no connection ID bit and (ii) clients vetoing the server's requ= est, policy decisions are hard for load balancers. In this world, there'= ;s no good way for server-side load balancers to know per connection whethe= r it has a connection ID or not: to find connection state, the load balance= r needs a key, which would be the connection ID, which may or may not be pr= esent for that connection. The load balancer could use the 4-tuple to key t= he connection, but that entirely defeats the point of using the connection = ID.

Hmm... This seems rat= her more to be the result of letting the client veto. In the design
you propose, the server does:

- If connection i= d bit is 1 look up connection ID
- Otherwise, look up the host/po= rt


If you don't have a bit, you= can

- Look up the host/port
- If it'= ;s missing assume that there is a connection ID and look for it
-= If that's missing, drop the packet


=

- = The privacy implications of sharing connection ID is a separate conversatio= n from the one this thread was started on. Though since some points were ra= ised here and since they speak to the question of what information to share= with middleboxes, I'll share my thoughts.=C2=A0

We need to separate the use of connection ID use across NAT rebindings v= s the use of connection ID use across client network changes.=C2=A0

We'd all probably agree that NAT rebindings for UDP a= re a real concern, since NATs kill these bindings faster than they do TCP b= indings.

Actually, no, I&= #39;m not persuaded by this as yet. I agree with the statement that NATs ki= ll these bindings
faster, but it's not yet clear to me that c= onnection IDs ameliorate these problems sufficiently to
improve t= he situation. I'd be happy to see any data you have that supports this = point.



We'd all agree that connection= ID use across client network changes is a new beast. To this end, I think = we've generally agreed (informally anyways) that the client must use a = new connection ID when it triggers connection migration to a different netw= ork.

The difficulty is th= at we do not presently know how to arrange that you always use a new conn i= d
on migration without using a new conn id on each packet.
<= div>

In sum, my argument is that having connection IDs stable across= NAT rebindings is a necessity for QUIC to work well. As a result, middlebo= xes at various points in the network, specifically those past a NAT, are ex= pected to use it to track connection state. Explicitly noting its presence = in the packet anticipates this and eliminates this one reason for ossificat= ion of other bits deep in handshake messages needed otherwise for its infer= ence.

I don't see you= arguing that this is desirable so much as inevitable. So, if we had a desi= gn that
was reasonably efficient that used a different connection= ID per packet, then you would be
fine with that and wouldn't= feel the need to tell middleboxes where it was?

-= Ekr
=C2=A0
<= div>

- ja= na


On = Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian



--94eb2c0b8fb40ffbd7054a4fa50c-- From nobody Thu Mar 9 10:00:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AC6129511 for ; Thu, 9 Mar 2017 10:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejkmpz5ZhhMf for ; Thu, 9 Mar 2017 10:00:02 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 42BE2128B44 for ; Thu, 9 Mar 2017 10:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489082400; l=18842; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=RnaPgScGlkO11CLtyGyjDqd1Y/G8hS3qWjZUik8T3m0=; b=SvNq5KxAYgPaQZ9W2bDo/X71CzncI0dBxQ/yLxlMZEhKJa5cuQqhNoXpL3Q1VVkvhY qA2EaOoIOsQfh4Q4tBcM8xjjTZDwbz5JBVUEMRF3XjxsVuPmDe41PZthZfkyctlD+Qcu coIXEezLFbTr+GUCXWH3x77Ch4kUVq6zPBPFU= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyCBKUXHiiJD900p0TuPJc3Hp+vSQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:3d34:f546:88b2:b6b8] ([2001:4dd0:ff67:0:3d34:f546:88b2:b6b8]) by smtp.strato.de (RZmta 40.1 AUTH) with ESMTPSA id 002ccdt29Hxx12s (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 9 Mar 2017 18:59:59 +0100 (CET) Subject: Re: Middlebox introspection/self-describing packets To: quic@ietf.org References: From: Roland Zink Message-ID: Date: Thu, 9 Mar 2017 19:00:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DBE2E1D6CD44713A1E58961B" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:00:06 -0000 This is a multi-part message in MIME format. --------------DBE2E1D6CD44713A1E58961B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit For TCP connections the middlebox (NAT) gets a signal when a connection ends. The NAT need to use the timeout only for connections where this doesn't happen. When there is no identificable connection and end signal then the NAT need to use the timeout for all such mappings. With a limited table size the timeout for such mappings needs to be shorter. With a identificable connection and an end signal NATs can increase the timeout for QUIC. Roland Am 09.03.2017 um 18:32 schrieb Eric Rescorla: > > > On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar > wrote: > > A thoughts as I catch up on this thread (and in response to ekr's > original question): > > - As ekr points out, server-side middleboxes can always rely on > connection IDs by policy. The value of the connection ID bit, in > my mind, is for middleboxes not controlled by the server. Such > middleboxes are likely to use the connection ID to identify > connections where it exists. Without an explicit per-packet bit, a > middlebox that wants to use connection ID will have to dig into > the handshake to determine where it's presence negotiated. This > leads to ossification of bits inside the cleartext handshake > messages, which is highly undesirable. I'd rather that the > connection ID bit be ossified. > > > Sure, but this starts from the position that middleboxes should be > using connection > IDs. It's not clear to me that we want to encourage that. > > > - As it stands, connection ID negotiation means that each side > tells the peer what it wants the peer to do. In a world with (i) > no connection ID bit and (ii) clients vetoing the server's > request, policy decisions are hard for load balancers. In this > world, there's no good way for server-side load balancers to know > per connection whether it has a connection ID or not: to find > connection state, the load balancer needs a key, which would be > the connection ID, which may or may not be present for that > connection. The load balancer could use the 4-tuple to key the > connection, but that entirely defeats the point of using the > connection ID. > > > Hmm... This seems rather more to be the result of letting the client > veto. In the design > you propose, the server does: > > - If connection id bit is 1 look up connection ID > - Otherwise, look up the host/port > > > If you don't have a bit, you can > > - Look up the host/port > - If it's missing assume that there is a connection ID and look for it > - If that's missing, drop the packet > > > > - The privacy implications of sharing connection ID is a separate > conversation from the one this thread was started on. Though since > some points were raised here and since they speak to the question > of what information to share with middleboxes, I'll share my > thoughts. > > We need to separate the use of connection ID use across NAT > rebindings vs the use of connection ID use across client network > changes. > > We'd all probably agree that NAT rebindings for UDP are a real > concern, since NATs kill these bindings faster than they do TCP > bindings. > > > Actually, no, I'm not persuaded by this as yet. I agree with the > statement that NATs kill these bindings > faster, but it's not yet clear to me that connection IDs ameliorate > these problems sufficiently to > improve the situation. I'd be happy to see any data you have that > supports this point. > > > > We'd all agree that connection ID use across client network > changes is a new beast. To this end, I think we've generally > agreed (informally anyways) that the client must use a new > connection ID when it triggers connection migration to a different > network. > > > The difficulty is that we do not presently know how to arrange that > you always use a new conn id > on migration without using a new conn id on each packet. > > > In sum, my argument is that having connection IDs stable across > NAT rebindings is a necessity for QUIC to work well. As a result, > middleboxes at various points in the network, specifically those > past a NAT, are expected to use it to track connection state. > Explicitly noting its presence in the packet anticipates this and > eliminates this one reason for ossification of other bits deep in > handshake messages needed otherwise for its inference. > > > I don't see you arguing that this is desirable so much as inevitable. > So, if we had a design that > was reasonably efficient that used a different connection ID per > packet, then you would be > fine with that and wouldn't feel the need to tell middleboxes where it > was? > > -Ekr > > > - jana > > > On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell > wrote: > > hi Ekr, all, > > > > Well, with negotiation, someone has to decide. The bit > just moves that to the client. > > > Except that if the load balancer *needs* it, then the > client has to conform. > > > >> The load balancer needs it to balance load efficiently. > >> > > That's not entirely clear. Note that in the original QUIC > design, the client supplied > > the connection ID, so the server side merely had to load > balance based on some combination > > of a random value and the client's IP. > > Right; should have said that "the assertion behind > server-suggested Connection ID proposal is that it's needed > for efficient load balancing". I'm taking that assertion at > face value now, possibly because I'm convinced of the utility > of one of its side-effects: providing some additional grade of > assurance to a device on path that a given packet was not > injected off-path, which is useful in in-network DoS > mitigation (as in section 3.3 of the just-submitted > manageability draft). > > >> I presume that a client that was very interested in not > providing tracking information could refuse to make Connection > ID available, at the cost of degraded performance. > > (I would like to reiterate that I do think that it's necessary > to allow clients to veto server-proposed connection ID exposure.) > > >> (f that's not the case, if failure to send connection ID > leads to connection failure, then "negotiation" is a > euphemism: the server informs the client whether it must send > a connection ID, probably encrypted, and nobody needs any > flags, unless the presence of connection ID changes the > offsets of fields we *do* want to explicitly expose, such as > packet number echo > (https://github.com/quicwg/base-drafts/issues/269 > ) or > troubleshooting flags > (https://github.com/quicwg/base-drafts/issues/279 > ). > > > > Not to put too fine a point on it, but there's far from > consensus that we want to expose > > either of these. > > That's not too fine a point at all; I'm not presupposing > consensus on either of these. All I'm saying here is, should > consensus emerge that the benefits outweigh the costs (both in > complexity and in risk) for certain kinds of exposure to the > path -- which I think may be the case for some of the things > under discussion in 279, and I'm obviously convinced of the > utility of packet number echo as in 269 or I wouldn't have > submitted two PRs on it -- we need to be clear that other > choices we make about the layout of the header doesn't make > that harder than it needs to be. Sticking > variable-length/optional fields whose presence is dependent on > endpoint-shared state after the exposed fields is probably > sufficient for this. > > > Cheers, > > Brian > > > --------------DBE2E1D6CD44713A1E58961B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

For TCP connections the middlebox (NAT) gets a signal when a connection ends. The NAT need to use the timeout only for connections where this doesn't happen. When there is no identificable connection and end signal then the NAT need to use the timeout for all such mappings. With a limited table size the timeout for such mappings needs to be shorter. With a identificable connection and an end signal NATs can increase the timeout for QUIC.

Roland


Am 09.03.2017 um 18:32 schrieb Eric Rescorla:


On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar <jri@google.com> wrote:
A thoughts as I catch up on this thread (and in response to ekr's original question):

- As ekr points out, server-side middleboxes can always rely on connection IDs by policy. The value of the connection ID bit, in my mind, is for middleboxes not controlled by the server. Such middleboxes are likely to use the connection ID to identify connections where it exists. Without an explicit per-packet bit, a middlebox that wants to use connection ID will have to dig into the handshake to determine where it's presence negotiated. This leads to ossification of bits inside the cleartext handshake messages, which is highly undesirable. I'd rather that the connection ID bit be ossified.

Sure, but this starts from the position that middleboxes should be using connection
IDs. It's not clear to me that we want to encourage that.


- As it stands, connection ID negotiation means that each side tells the peer what it wants the peer to do. In a world with (i) no connection ID bit and (ii) clients vetoing the server's request, policy decisions are hard for load balancers. In this world, there's no good way for server-side load balancers to know per connection whether it has a connection ID or not: to find connection state, the load balancer needs a key, which would be the connection ID, which may or may not be present for that connection. The load balancer could use the 4-tuple to key the connection, but that entirely defeats the point of using the connection ID.

Hmm... This seems rather more to be the result of letting the client veto. In the design
you propose, the server does:

- If connection id bit is 1 look up connection ID
- Otherwise, look up the host/port


If you don't have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look for it
- If that's missing, drop the packet



- The privacy implications of sharing connection ID is a separate conversation from the one this thread was started on. Though since some points were raised here and since they speak to the question of what information to share with middleboxes, I'll share my thoughts. 

We need to separate the use of connection ID use across NAT rebindings vs the use of connection ID use across client network changes. 

We'd all probably agree that NAT rebindings for UDP are a real concern, since NATs kill these bindings faster than they do TCP bindings.

Actually, no, I'm not persuaded by this as yet. I agree with the statement that NATs kill these bindings
faster, but it's not yet clear to me that connection IDs ameliorate these problems sufficiently to
improve the situation. I'd be happy to see any data you have that supports this point.



We'd all agree that connection ID use across client network changes is a new beast. To this end, I think we've generally agreed (informally anyways) that the client must use a new connection ID when it triggers connection migration to a different network.

The difficulty is that we do not presently know how to arrange that you always use a new conn id
on migration without using a new conn id on each packet.


In sum, my argument is that having connection IDs stable across NAT rebindings is a necessity for QUIC to work well. As a result, middleboxes at various points in the network, specifically those past a NAT, are expected to use it to track connection state. Explicitly noting its presence in the packet anticipates this and eliminates this one reason for ossification of other bits deep in handshake messages needed otherwise for its inference.

I don't see you arguing that this is desirable so much as inevitable. So, if we had a design that
was reasonably efficient that used a different connection ID per packet, then you would be
fine with that and wouldn't feel the need to tell middleboxes where it was?

-Ekr
 

- jana


On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves that to the client.
> > Except that if the load balancer *needs* it, then the client has to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, the client supplied
> the connection ID, so the server side merely had to load balance based on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-suggested Connection ID proposal is that it's needed for efficient load balancing". I'm taking that assertion at face value now, possibly because I'm convinced of the utility of one of its side-effects: providing some additional grade of assurance to a device on path that a given packet was not injected off-path, which is useful in in-network DoS mitigation (as in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing tracking information could refuse to make Connection ID available, at the cost of degraded performance.

(I would like to reiterate that I do think that it's necessary to allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads to connection failure, then "negotiation" is a euphemism: the server informs the client whether it must send a connection ID, probably encrypted, and nobody needs any flags, unless the presence of connection ID changes the offsets of fields we *do* want to explicitly expose, such as packet number echo (https://github.com/quicwg/base-drafts/issues/269) or troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing consensus on either of these. All I'm saying here is, should consensus emerge that the benefits outweigh the costs (both in complexity and in risk) for certain kinds of exposure to the path -- which I think may be the case for some of the things under discussion in 279, and I'm obviously convinced of the utility of packet number echo as in 269 or I wouldn't have submitted two PRs on it -- we need to be clear that other choices we make about the layout of the header doesn't make that harder than it needs to be. Sticking variable-length/optional fields whose presence is dependent on endpoint-shared state after the exposed fields is probably sufficient for this.


Cheers,

Brian




--------------DBE2E1D6CD44713A1E58961B-- From nobody Thu Mar 9 10:08:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1081296E1 for ; Thu, 9 Mar 2017 10:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V25JMPNc0n9x for ; Thu, 9 Mar 2017 10:08:27 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1F0129554 for ; Thu, 9 Mar 2017 10:08:27 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id v76so11553834ywg.0 for ; Thu, 09 Mar 2017 10:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ecfl+nYtgkTHy+LRfTeh8zNoXXoHa/cW46HGWfO/Xqo=; b=u7cGxwXpcbYizjrp/ewNtxHitON7uYpVIeXbpnFhs0mo9STwJnBUAd9v3NdOvoxaod MoIoKx2JZmzvezv1C50mVc/Y+F8RQe7pN1RkGkEhFXoXb5At+z1ayRdxyPLKsveWNV3z tvidVhUZfuPEZnwU5xcEG+lm3uoc+FM2L300O0Eq7RIoqr4S0we/Q83ABSWHMK8njqGg xfuEidNsI9RIjkj41OcoLEah1865s12ineeFCAUvYC8XnfEbUPyBFHqmPoVyso4Pgg03 MSDSQzZC+Lgb1pL+V1P+cGr6HeY6O69HLLcJm4xfN0Uf4gA/syXkt4nwsIzQclY9dPAJ 0aaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ecfl+nYtgkTHy+LRfTeh8zNoXXoHa/cW46HGWfO/Xqo=; b=MokJdLV/B13gg8L15Yxt4s6FqQHA3h6VPRsBvslp8wmrJQ7r3rXha3OliWo2VtJZ3+ XdBKRbV57n2ER6GgmTZov6+nMiCVKkrdGSKNzbf2tDS/xNFjZM9D4jWfljEFIOE0YRjT sjd+UgfemdidybkTWL8f6Ljq9bLneivsVMLoaimZgvu7JL+3j3MxZ1jk2U4zBTbXXLa4 5KDK9B7SQTGIQeVactMgmgA7JtlG5ylEAUokiaufuAJ4iy15HCj5uWQySN4Qysdkbf48 JbbtiSZ7BMxFQBiuMaG8CjAxD9d0InoPfLKa93qE/W/Kjc9BTHe/C9k64K4me40opA0M xrug== X-Gm-Message-State: AMke39kmUtxzpZtCHgM+iJiww9QPuMRtUp3WxpKaCzaUvmzSEYROdyJV7vcbJNLhXjy+0UKbpcpCTa6ifyT4RA== X-Received: by 10.13.240.196 with SMTP id z187mr4998790ywe.337.1489082906577; Thu, 09 Mar 2017 10:08:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 10:07:45 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 10:07:45 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Roland Zink Content-Type: multipart/alternative; boundary=94eb2c034eb0b03313054a502172 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:08:29 -0000 --94eb2c034eb0b03313054a502172 Content-Type: text/plain; charset=UTF-8 This seems like an argument for a visible close, not for a connection ID. -Ekr On Thu, Mar 9, 2017 at 10:00 AM, Roland Zink wrote: > For TCP connections the middlebox (NAT) gets a signal when a connection > ends. The NAT need to use the timeout only for connections where this > doesn't happen. When there is no identificable connection and end signal > then the NAT need to use the timeout for all such mappings. With a limited > table size the timeout for such mappings needs to be shorter. With a > identificable connection and an end signal NATs can increase the timeout > for QUIC. > Roland > > > > Am 09.03.2017 um 18:32 schrieb Eric Rescorla: > > > > On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: > >> A thoughts as I catch up on this thread (and in response to ekr's >> original question): >> >> - As ekr points out, server-side middleboxes can always rely on >> connection IDs by policy. The value of the connection ID bit, in my mind, >> is for middleboxes not controlled by the server. Such middleboxes are >> likely to use the connection ID to identify connections where it exists. >> Without an explicit per-packet bit, a middlebox that wants to use >> connection ID will have to dig into the handshake to determine where it's >> presence negotiated. This leads to ossification of bits inside the >> cleartext handshake messages, which is highly undesirable. I'd rather that >> the connection ID bit be ossified. >> > > Sure, but this starts from the position that middleboxes should be using > connection > IDs. It's not clear to me that we want to encourage that. > > >> - As it stands, connection ID negotiation means that each side tells the >> peer what it wants the peer to do. In a world with (i) no connection ID bit >> and (ii) clients vetoing the server's request, policy decisions are hard >> for load balancers. In this world, there's no good way for server-side load >> balancers to know per connection whether it has a connection ID or not: to >> find connection state, the load balancer needs a key, which would be the >> connection ID, which may or may not be present for that connection. The >> load balancer could use the 4-tuple to key the connection, but that >> entirely defeats the point of using the connection ID. >> > > Hmm... This seems rather more to be the result of letting the client veto. > In the design > you propose, the server does: > > - If connection id bit is 1 look up connection ID > - Otherwise, look up the host/port > > > If you don't have a bit, you can > > - Look up the host/port > - If it's missing assume that there is a connection ID and look for it > - If that's missing, drop the packet > > > >> - The privacy implications of sharing connection ID is a separate >> conversation from the one this thread was started on. Though since some >> points were raised here and since they speak to the question of what >> information to share with middleboxes, I'll share my thoughts. >> >> We need to separate the use of connection ID use across NAT rebindings vs >> the use of connection ID use across client network changes. >> >> We'd all probably agree that NAT rebindings for UDP are a real concern, >> since NATs kill these bindings faster than they do TCP bindings. >> > > Actually, no, I'm not persuaded by this as yet. I agree with the statement > that NATs kill these bindings > faster, but it's not yet clear to me that connection IDs ameliorate these > problems sufficiently to > improve the situation. I'd be happy to see any data you have that supports > this point. > > > > We'd all agree that connection ID use across client network changes is a >> new beast. To this end, I think we've generally agreed (informally anyways) >> that the client must use a new connection ID when it triggers connection >> migration to a different network. >> > > The difficulty is that we do not presently know how to arrange that you > always use a new conn id > on migration without using a new conn id on each packet. > > > In sum, my argument is that having connection IDs stable across NAT >> rebindings is a necessity for QUIC to work well. As a result, middleboxes >> at various points in the network, specifically those past a NAT, are >> expected to use it to track connection state. Explicitly noting its >> presence in the packet anticipates this and eliminates this one reason for >> ossification of other bits deep in handshake messages needed otherwise for >> its inference. >> > > I don't see you arguing that this is desirable so much as inevitable. So, > if we had a design that > was reasonably efficient that used a different connection ID per packet, > then you would be > fine with that and wouldn't feel the need to tell middleboxes where it was? > > -Ekr > > >> >> - jana >> >> >> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: >> >>> hi Ekr, all, >>> >>> > > Well, with negotiation, someone has to decide. The bit just moves >>> that to the client. >>> > > Except that if the load balancer *needs* it, then the client has to >>> conform. >>> > >>> >> The load balancer needs it to balance load efficiently. >>> >> >>> > That's not entirely clear. Note that in the original QUIC design, the >>> client supplied >>> > the connection ID, so the server side merely had to load balance based >>> on some combination >>> > of a random value and the client's IP. >>> >>> Right; should have said that "the assertion behind server-suggested >>> Connection ID proposal is that it's needed for efficient load balancing". >>> I'm taking that assertion at face value now, possibly because I'm convinced >>> of the utility of one of its side-effects: providing some additional grade >>> of assurance to a device on path that a given packet was not injected >>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>> of the just-submitted manageability draft). >>> >>> >> I presume that a client that was very interested in not providing >>> tracking information could refuse to make Connection ID available, at the >>> cost of degraded performance. >>> >>> (I would like to reiterate that I do think that it's necessary to allow >>> clients to veto server-proposed connection ID exposure.) >>> >>> >> (f that's not the case, if failure to send connection ID leads to >>> connection failure, then "negotiation" is a euphemism: the server informs >>> the client whether it must send a connection ID, probably encrypted, and >>> nobody needs any flags, unless the presence of connection ID changes the >>> offsets of fields we *do* want to explicitly expose, such as packet number >>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>> troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279 >>> ). >>> > >>> > Not to put too fine a point on it, but there's far from consensus that >>> we want to expose >>> > either of these. >>> >>> That's not too fine a point at all; I'm not presupposing consensus on >>> either of these. All I'm saying here is, should consensus emerge that the >>> benefits outweigh the costs (both in complexity and in risk) for certain >>> kinds of exposure to the path -- which I think may be the case for some of >>> the things under discussion in 279, and I'm obviously convinced of the >>> utility of packet number echo as in 269 or I wouldn't have submitted two >>> PRs on it -- we need to be clear that other choices we make about the >>> layout of the header doesn't make that harder than it needs to be. Sticking >>> variable-length/optional fields whose presence is dependent on >>> endpoint-shared state after the exposed fields is probably sufficient for >>> this. >>> >>> >>> Cheers, >>> >>> Brian >>> >>> >> > > --94eb2c034eb0b03313054a502172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like an argument for a visible close, not for a= connection ID.

-Ekr


On Thu, Mar 9, 2017 at 10:00 AM, Rolan= d Zink <roland@zinks.de> wrote:
=20 =20 =20

For TCP connections the middlebox (NAT) gets a signal when a connection ends. The NAT need to use the timeout only for connections where this doesn't happen. When there is no identificable connection and end signal then the NAT need to use the timeout for all such mappings. With a limited table size the timeout for such mappings needs to be shorter. With a identificable connection and an end signal NATs can increase the timeout for QUIC.

Roland



Am 09.03.2017 um 1= 8:32 schrieb Eric Rescorla:


On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar <jri@google.com> wrote:
A thoughts as I catch up on this thread (and in response to ekr's original question):

- As ekr points out, server-side middleboxes can always rely on connection IDs by policy. The value of the connection ID bit, in my mind, is for middleboxes not controlled by the server. Such middleboxes are likely to use the connection ID to identify connections where it exists. Without an explicit per-packet bit, a middlebox that wants to use connection ID will have to dig into the handshake to determine where it's presence negotiated. This leads to ossification of bits inside the cleartext handshake messages, which is highly undesirable. I'd rather that the connectio= n ID bit be ossified.

Sure, but this starts from the position that middleboxes should be using connection
IDs. It's not clear to me that we want to encourage that.


- As it stands, connection ID negotiation means that each side tells the peer what it wants the peer to do. In a world with (i) no connection ID bit and (ii) clients vetoing the server's request, policy decisions are hard for load balancers. In this world, there's no good way for server-side load balancers to know per connection whether it has a connection ID or not: to find connection state, the load balancer needs a key, which would be the connection ID, which may or may not be present for that connection. The load balancer could use the 4-tuple to key the connection, but that entirely defeats the point of using the connection ID.

Hmm... This seems rather more to be the result of letting the client veto. In the design
you propose, the server does:

- If connection id bit is 1 look up connection ID
- Otherwise, look up the host/port


If you don't have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look for it
- If that's missing, drop the packet



- The privacy implications of sharing connection ID is a separate conversation from the one this thread was started on. Though since some points were raised here and since they speak to the question of what information to share with middleboxes, I'll share my thoughts.=C2=A0

We need to separate the use of connection ID use across NAT rebindings vs the use of connection ID use across client network changes.=C2=A0

We'd all probably agree that NAT rebindings for UDP are a real concern, since NATs kill these bindings faster than they do TCP bindings.

Actually, no, I'm not persuaded by this as yet. I agre= e with the statement that NATs kill these bindings
faster, but it's not yet clear to me that connection IDs ameliorate these problems sufficiently to
improve the situation. I'd be happy to see any data yo= u have that supports this point.



We'd all agree that connection ID use across client network changes is a new beast. To this end, I think we've generally agreed (informally anyways) that the client must use a new connection ID when it triggers connection migration to a different network.

The difficulty is that we do not presently know how to arrange that you always use a new conn id
on migration without using a new conn id on each packet.


In sum, my argument is that having connection IDs stable across NAT rebindings is a necessity for QUIC to work well. As a result, middleboxes at various points in the network, specifically those past a NAT, are expected to use it to track connection state. Explicitly noting its presence in the packet anticipates this and eliminates this one reason for ossification of other bits deep in handshake messages needed otherwise for its inference.

I don't see you arguing that this is desirable so much as inevitable. So, if we had a design that
was reasonably efficient that used a different connection ID per packet, then you would be
fine with that and wouldn't feel the need to tell middleboxes where it was?

-Ekr
=C2=A0

- jana


On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves that to the client.
> > Except that if the load balancer *needs* it, then the client has to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, the client supplied
> the connection ID, so the server side merely had to load balance based on some combination
> of a random value and the client's IP.
Right; should have said that "the assertion behind server-suggested Connection ID proposal is that it's needed for efficient load balancing". I'm taking that assertion at f= ace value now, possibly because I'm convinced of th= e utility of one of its side-effects: providing some additional grade of assurance to a device on path that a given packet was not injected off-path, which is useful in in-network DoS mitigation (as in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing tracking information could refuse to make Connection ID available, at the cost of degraded performance.

(I would like to reiterate that I do think that it's necessary to allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure t= o send connection ID leads to connection failure, then "negotiation" is a euphem= ism: the server informs the client whether it must send a connection ID, probably encrypted, and nobody needs any flags, unless the presence of connection ID changes the offsets of fields we *do* want to explicitly expose, such as packet number echo (https://githu= b.com/quicwg/base-drafts/issues/269) or troubleshooting flags (= https://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus that we want to expose
> either of these.

That's not too fine a point at all; I= 9;m not presupposing consensus on either of these. All I'm saying here is, should consensus emerge that the benefits outweigh the costs (both in complexity and in risk) for certain kinds of exposure to the path -- which I think may be the case for some of the things under discussion in 279, and I'm obviously convinced of the utility of packet number echo as in 269 or I wouldn't have submitted two PRs on it -- we need to be clear that other choices we make about the layout of the header doesn't make that harder than it needs to be. Sticking variable-length/optional fields whose presence is dependent on endpoint-shared state after the exposed fields is probably sufficient for this.


Cheers,

Brian





--94eb2c034eb0b03313054a502172-- From nobody Thu Mar 9 10:12:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E501296E1 for ; Thu, 9 Mar 2017 10:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ea83KoEm6KOl for ; Thu, 9 Mar 2017 10:12:41 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 1007F1295CA for ; Thu, 9 Mar 2017 10:12:41 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id a5so4526186ybb.2 for ; Thu, 09 Mar 2017 10:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yTuG6O5GTEA3FdfJ17MIEtJvfMGvzWvJbSqbfKxRWDc=; b=gQWHn1t2IFefwrIGB9EkjDG/BwrVtr1NC+u+fSPV4GrXeEOshsicSpRbNZ8qrATekI dK3pXfMqPLxQbH6q67B6n/C2b+ubp0csnj4Q7KZp0ICstuR5Y2cddQAzDHnGqt2lTvhJ qd6CJKdWAJFAgd7CzbxRCBnP5nhQ3C23Iajne9f91JkMQp/88I0v+TqHl6nBVEr6a/U0 bDafzr/ZTb7+Bequ8rStOK+rMwbJ/LJIx0ICNyE1UAY0QUNxNQd31YXrnM5R5rN7Znkj /TGMsXg/d9YpscPKg4KaAGmdxIY3vNSkP4IRjgr03NEGTWc0jJe2A6b0YtSN7f3GWWf+ 58AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yTuG6O5GTEA3FdfJ17MIEtJvfMGvzWvJbSqbfKxRWDc=; b=SVXgNc7wGuQuEKYfjpZkzkchlItQGNET/GyPnvABC+gYG9LPGuA495sOd7kazyP4tA 7ceV3lbl6WlF+kzM4L24XD54lyggjRQJ0VVlurnuMEDXxLbY8kiQ5qpOyFnTv8/LbLRh EATa72wov3nit++3hlZKYrI6ZOicqwTIHRrP+NBEE+6YefQTGxJQ/eNUWALeNVJtC/kt l3hCgtm8pzks5zE4GAiZ9QVnmTm2E18NFaNJKNVtxLgfxJQLULvtCJlZoBZR5xKC1AmU x+0P76eLU6OWbDJ4OvnuEF5gq8Ueb/FVHpsGpclayF/V5ObU6AgmIkAE3x95flWi6kDa vzwg== X-Gm-Message-State: AMke39l6qxtos8vKY5Q8um1OIXQJSIp0lL+Gh7hIZYqBfRJ0r3iYOti/szsjWk1TpKulic4GDpJChH+fjHJV5vFp X-Received: by 10.37.110.139 with SMTP id j133mr4528783ybc.143.1489083159850; Thu, 09 Mar 2017 10:12:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 10:12:19 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Mar 2017 13:12:19 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1148b49cc9376f054a5030cb Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:12:43 -0000 --001a1148b49cc9376f054a5030cb Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla wrote: > > > On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: > >> A thoughts as I catch up on this thread (and in response to ekr's >> original question): >> >> - As ekr points out, server-side middleboxes can always rely on >> connection IDs by policy. The value of the connection ID bit, in my mind, >> is for middleboxes not controlled by the server. Such middleboxes are >> likely to use the connection ID to identify connections where it exists. >> Without an explicit per-packet bit, a middlebox that wants to use >> connection ID will have to dig into the handshake to determine where it's >> presence negotiated. This leads to ossification of bits inside the >> cleartext handshake messages, which is highly undesirable. I'd rather that >> the connection ID bit be ossified. >> > > Sure, but this starts from the position that middleboxes should be using > connection > IDs. It's not clear to me that we want to encourage that. > > >> - As it stands, connection ID negotiation means that each side tells the >> peer what it wants the peer to do. In a world with (i) no connection ID bit >> and (ii) clients vetoing the server's request, policy decisions are hard >> for load balancers. In this world, there's no good way for server-side load >> balancers to know per connection whether it has a connection ID or not: to >> find connection state, the load balancer needs a key, which would be the >> connection ID, which may or may not be present for that connection. The >> load balancer could use the 4-tuple to key the connection, but that >> entirely defeats the point of using the connection ID. >> > > Hmm... This seems rather more to be the result of letting the client veto. > In the design > you propose, the server does: > > - If connection id bit is 1 look up connection ID > - Otherwise, look up the host/port > > > If you don't have a bit, you can > > - Look up the host/port > - If it's missing assume that there is a connection ID and look for it > - If that's missing, drop the packet > > > >> - The privacy implications of sharing connection ID is a separate >> conversation from the one this thread was started on. Though since some >> points were raised here and since they speak to the question of what >> information to share with middleboxes, I'll share my thoughts. >> >> We need to separate the use of connection ID use across NAT rebindings vs >> the use of connection ID use across client network changes. >> >> We'd all probably agree that NAT rebindings for UDP are a real concern, >> since NATs kill these bindings faster than they do TCP bindings. >> > > Actually, no, I'm not persuaded by this as yet. I agree with the statement > that NATs kill these bindings > faster, but it's not yet clear to me that connection IDs ameliorate these > problems sufficiently to > improve the situation. I'd be happy to see any data you have that supports > this point. > > This happens often, particularly after 1 minute, and connection ID makes it work seamlessly, so I'm pretty sure it works sufficiently well. It is critical to longer(ie: 5 minute) idle timeouts. > > > We'd all agree that connection ID use across client network changes is a >> new beast. To this end, I think we've generally agreed (informally anyways) >> that the client must use a new connection ID when it triggers connection >> migration to a different network. >> > > The difficulty is that we do not presently know how to arrange that you > always use a new conn id > on migration without using a new conn id on each packet. > > > In sum, my argument is that having connection IDs stable across NAT >> rebindings is a necessity for QUIC to work well. As a result, middleboxes >> at various points in the network, specifically those past a NAT, are >> expected to use it to track connection state. Explicitly noting its >> presence in the packet anticipates this and eliminates this one reason for >> ossification of other bits deep in handshake messages needed otherwise for >> its inference. >> > > I don't see you arguing that this is desirable so much as inevitable. So, > if we had a design that > was reasonably efficient that used a different connection ID per packet, > then you would be > fine with that and wouldn't feel the need to tell middleboxes where it was? > I don't think having the same connection ID used after a NAT rebind is a problem. The attack of interest is linking one or more actions in one network with one or more on another network. If you're on the client side of the NAT nothing changes, and if you're on the server side you already know the set of ports(or ports and IPs) that a given NAT uses publicly, so they're all equivalent from the observer's perspective. The NAT is a physical entity and there are some fairly tight real-world constraints on where you end up during a rebind. Is there a different threat model that I'm not aware of? -Ekr > > >> >> - jana >> >> >> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: >> >>> hi Ekr, all, >>> >>> > > Well, with negotiation, someone has to decide. The bit just moves >>> that to the client. >>> > > Except that if the load balancer *needs* it, then the client has to >>> conform. >>> > >>> >> The load balancer needs it to balance load efficiently. >>> >> >>> > That's not entirely clear. Note that in the original QUIC design, the >>> client supplied >>> > the connection ID, so the server side merely had to load balance based >>> on some combination >>> > of a random value and the client's IP. >>> >>> Right; should have said that "the assertion behind server-suggested >>> Connection ID proposal is that it's needed for efficient load balancing". >>> I'm taking that assertion at face value now, possibly because I'm convinced >>> of the utility of one of its side-effects: providing some additional grade >>> of assurance to a device on path that a given packet was not injected >>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>> of the just-submitted manageability draft). >>> >>> >> I presume that a client that was very interested in not providing >>> tracking information could refuse to make Connection ID available, at the >>> cost of degraded performance. >>> >>> (I would like to reiterate that I do think that it's necessary to allow >>> clients to veto server-proposed connection ID exposure.) >>> >>> >> (f that's not the case, if failure to send connection ID leads to >>> connection failure, then "negotiation" is a euphemism: the server informs >>> the client whether it must send a connection ID, probably encrypted, and >>> nobody needs any flags, unless the presence of connection ID changes the >>> offsets of fields we *do* want to explicitly expose, such as packet number >>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>> troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279 >>> ). >>> > >>> > Not to put too fine a point on it, but there's far from consensus that >>> we want to expose >>> > either of these. >>> >>> That's not too fine a point at all; I'm not presupposing consensus on >>> either of these. All I'm saying here is, should consensus emerge that the >>> benefits outweigh the costs (both in complexity and in risk) for certain >>> kinds of exposure to the path -- which I think may be the case for some of >>> the things under discussion in 279, and I'm obviously convinced of the >>> utility of packet number echo as in 269 or I wouldn't have submitted two >>> PRs on it -- we need to be clear that other choices we make about the >>> layout of the header doesn't make that harder than it needs to be. Sticking >>> variable-length/optional fields whose presence is dependent on >>> endpoint-shared state after the exposed fields is probably sufficient for >>> this. >>> >>> >>> Cheers, >>> >>> Brian >>> >>> >> > --001a1148b49cc9376f054a5030cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Thu, Ma= r 9, 2017 at 9:08 AM, Jana Iyengar <jri@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
A thoughts as I catch up on = this thread (and in response to ekr's original question):

=
- As ekr points out, server-side middleboxes can always rely on connec= tion IDs by policy. The value of the connection ID bit, in my mind, is for = middleboxes not controlled by the server. Such middleboxes are likely to us= e the connection ID to identify connections where it exists. Without an exp= licit per-packet bit, a middlebox that wants to use connection ID will have= to dig into the handshake to determine where it's presence negotiated.= This leads to ossification of bits inside the cleartext handshake messages= , which is highly undesirable. I'd rather that the connection ID bit be= ossified.

S= ure, but this starts from the position that middleboxes should be using con= nection
IDs. It's not clear to me that we want to encourage t= hat.


- As it stands, connection ID negot= iation means that each side tells the peer what it wants the peer to do. In= a world with (i) no connection ID bit and (ii) clients vetoing the server&= #39;s request, policy decisions are hard for load balancers. In this world,= there's no good way for server-side load balancers to know per connect= ion whether it has a connection ID or not: to find connection state, the lo= ad balancer needs a key, which would be the connection ID, which may or may= not be present for that connection. The load balancer could use the 4-tupl= e to key the connection, but that entirely defeats the point of using the c= onnection ID.

Hmm.= .. This seems rather more to be the result of letting the client veto. In t= he design
you propose, the server does:

= - If connection id bit is 1 look up connection ID
- Otherwise, lo= ok up the host/port


If you don'= t have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look f= or it
- If that's missing, drop the packet



- The privacy implications of sharing con= nection ID is a separate conversation from the one this thread was started = on. Though since some points were raised here and since they speak to the q= uestion of what information to share with middleboxes, I'll share my th= oughts.=C2=A0

We need to separate the use of conne= ction ID use across NAT rebindings vs the use of connection ID use across c= lient network changes.=C2=A0

We'd all probably= agree that NAT rebindings for UDP are a real concern, since NATs kill thes= e bindings faster than they do TCP bindings.
=

Actually, no, I'm not persuaded by this as y= et. I agree with the statement that NATs kill these bindings
fast= er, but it's not yet clear to me that connection IDs ameliorate these p= roblems sufficiently to
improve the situation. I'd be happy t= o see any data you have that supports this point.


This = happens often, particularly after 1 minute, and connection ID makes it work= seamlessly, so I'm pretty sure it works sufficiently well.=C2=A0 It is= critical to longer(ie: 5 minute) idle timeouts.=C2=A0
=C2=A0


We= 9;d all agree that connection ID use across client network changes is a new= beast. To this end, I think we've generally agreed (informally anyways= ) that the client must use a new connection ID when it triggers connection = migration to a different network.

The difficulty is that we do not presently know how to arra= nge that you always use a new conn id
on migration without using = a new conn id on each packet.

In sum, my= argument is that having connection IDs stable across NAT rebindings is a n= ecessity for QUIC to work well. As a result, middleboxes at various points = in the network, specifically those past a NAT, are expected to use it to tr= ack connection state. Explicitly noting its presence in the packet anticipa= tes this and eliminates this one reason for ossification of other bits deep= in handshake messages needed otherwise for its inference.

I don't see you arguing that t= his is desirable so much as inevitable. So, if we had a design that
was reasonably efficient that used a different connection ID per packet,= then you would be
fine with that and wouldn't feel the need = to tell middleboxes where it was?
=
I don't think having the same connection ID used after a= NAT rebind is a problem.=C2=A0 The attack of interest is linking one or mo= re actions in one network with one or more on another network.=C2=A0 If you= 're on the client side of the NAT nothing changes, and if you're on= the server side you already know the set of ports(or ports and IPs) that a= given NAT uses publicly, so they're all equivalent from the observer&#= 39;s perspective.=C2=A0 The NAT is a physical entity and there are some fai= rly tight real-world constraints on where you end up during a rebind.
=

Is there a different threat model that I'm not aware of?
=

-Ekr
=C2=A0

<= /div>
- jana

<= div class=3D"gmail_extra">
On Thu, Mar 9, 201= 7 at 8:09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian




--001a1148b49cc9376f054a5030cb-- From nobody Thu Mar 9 10:13:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C216E1296F3 for ; Thu, 9 Mar 2017 10:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jp4-_dtm2XH for ; Thu, 9 Mar 2017 10:12:57 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (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 9D2D81296EF for ; Thu, 9 Mar 2017 10:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489083169; l=20890; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:Cc:References:To: Subject; bh=BbS+2IeCIjJDSS3AqoxpS4ZFcR2iW5TcUR74gIlMPNE=; b=sqp/0gS4KdOVlnr40dqUQWvrSz4aLltyIf/PsW9omMl8Z0+NjIUTO3xDvxu71YfS+Z zzpT5v5yoHNTvk+WwOXKDqsrTMFx/UQSDOrkxJTWld5C0e6j6SOFd29GHb56Lo6GZ3sv pJGxIduKf/KZTzvIM5u02QK1o2Z/PiGE4wrLs= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyCBKUXHiiJD900p0TuPJc3Hp+vSQ== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:3d34:f546:88b2:b6b8] ([2001:4dd0:ff67:0:3d34:f546:88b2:b6b8]) by smtp.strato.de (RZmta 40.1 AUTH) with ESMTPSA id e00ccdt29ICm1YI (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 9 Mar 2017 19:12:48 +0100 (CET) Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla References: From: Roland Zink Message-ID: Date: Thu, 9 Mar 2017 19:12:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B4ED805A49BB52615873A405" Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:12:59 -0000 This is a multi-part message in MIME format. --------------B4ED805A49BB52615873A405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Yes, it is only necessary to identify the connection. If it is done through IP addresses and ports or connection id shouldn't matter in this respect. Roland Am 09.03.2017 um 19:07 schrieb Eric Rescorla: > This seems like an argument for a visible close, not for a connection ID. > > -Ekr > > > On Thu, Mar 9, 2017 at 10:00 AM, Roland Zink > wrote: > > For TCP connections the middlebox (NAT) gets a signal when a > connection ends. The NAT need to use the timeout only for > connections where this doesn't happen. When there is no > identificable connection and end signal then the NAT need to use > the timeout for all such mappings. With a limited table size the > timeout for such mappings needs to be shorter. With a > identificable connection and an end signal NATs can increase the > timeout for QUIC. > > Roland > > > > Am 09.03.2017 um 18:32 schrieb Eric Rescorla: >> >> >> On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar > > wrote: >> >> A thoughts as I catch up on this thread (and in response to >> ekr's original question): >> >> - As ekr points out, server-side middleboxes can always rely >> on connection IDs by policy. The value of the connection ID >> bit, in my mind, is for middleboxes not controlled by the >> server. Such middleboxes are likely to use the connection ID >> to identify connections where it exists. Without an explicit >> per-packet bit, a middlebox that wants to use connection ID >> will have to dig into the handshake to determine where it's >> presence negotiated. This leads to ossification of bits >> inside the cleartext handshake messages, which is highly >> undesirable. I'd rather that the connection ID bit be ossified. >> >> >> Sure, but this starts from the position that middleboxes should >> be using connection >> IDs. It's not clear to me that we want to encourage that. >> >> >> - As it stands, connection ID negotiation means that each >> side tells the peer what it wants the peer to do. In a world >> with (i) no connection ID bit and (ii) clients vetoing the >> server's request, policy decisions are hard for load >> balancers. In this world, there's no good way for server-side >> load balancers to know per connection whether it has a >> connection ID or not: to find connection state, the load >> balancer needs a key, which would be the connection ID, which >> may or may not be present for that connection. The load >> balancer could use the 4-tuple to key the connection, but >> that entirely defeats the point of using the connection ID. >> >> >> Hmm... This seems rather more to be the result of letting the >> client veto. In the design >> you propose, the server does: >> >> - If connection id bit is 1 look up connection ID >> - Otherwise, look up the host/port >> >> >> If you don't have a bit, you can >> >> - Look up the host/port >> - If it's missing assume that there is a connection ID and look >> for it >> - If that's missing, drop the packet >> >> >> >> - The privacy implications of sharing connection ID is a >> separate conversation from the one this thread was started >> on. Though since some points were raised here and since they >> speak to the question of what information to share with >> middleboxes, I'll share my thoughts. >> >> We need to separate the use of connection ID use across NAT >> rebindings vs the use of connection ID use across client >> network changes. >> >> We'd all probably agree that NAT rebindings for UDP are a >> real concern, since NATs kill these bindings faster than they >> do TCP bindings. >> >> >> Actually, no, I'm not persuaded by this as yet. I agree with the >> statement that NATs kill these bindings >> faster, but it's not yet clear to me that connection IDs >> ameliorate these problems sufficiently to >> improve the situation. I'd be happy to see any data you have that >> supports this point. >> >> >> >> We'd all agree that connection ID use across client network >> changes is a new beast. To this end, I think we've generally >> agreed (informally anyways) that the client must use a new >> connection ID when it triggers connection migration to a >> different network. >> >> >> The difficulty is that we do not presently know how to arrange >> that you always use a new conn id >> on migration without using a new conn id on each packet. >> >> >> In sum, my argument is that having connection IDs stable >> across NAT rebindings is a necessity for QUIC to work well. >> As a result, middleboxes at various points in the network, >> specifically those past a NAT, are expected to use it to >> track connection state. Explicitly noting its presence in the >> packet anticipates this and eliminates this one reason for >> ossification of other bits deep in handshake messages needed >> otherwise for its inference. >> >> >> I don't see you arguing that this is desirable so much as >> inevitable. So, if we had a design that >> was reasonably efficient that used a different connection ID per >> packet, then you would be >> fine with that and wouldn't feel the need to tell middleboxes >> where it was? >> >> -Ekr >> >> >> - jana >> >> >> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell >> > wrote: >> >> hi Ekr, all, >> >> > > Well, with negotiation, someone has to decide. The >> bit just moves that to the client. >> > > Except that if the load balancer *needs* it, then the >> client has to conform. >> > >> >> The load balancer needs it to balance load efficiently. >> >> >> > That's not entirely clear. Note that in the original >> QUIC design, the client supplied >> > the connection ID, so the server side merely had to >> load balance based on some combination >> > of a random value and the client's IP. >> >> Right; should have said that "the assertion behind >> server-suggested Connection ID proposal is that it's >> needed for efficient load balancing". I'm taking that >> assertion at face value now, possibly because I'm >> convinced of the utility of one of its side-effects: >> providing some additional grade of assurance to a device >> on path that a given packet was not injected off-path, >> which is useful in in-network DoS mitigation (as in >> section 3.3 of the just-submitted manageability draft). >> >> >> I presume that a client that was very interested in >> not providing tracking information could refuse to make >> Connection ID available, at the cost of degraded performance. >> >> (I would like to reiterate that I do think that it's >> necessary to allow clients to veto server-proposed >> connection ID exposure.) >> >> >> (f that's not the case, if failure to send connection >> ID leads to connection failure, then "negotiation" is a >> euphemism: the server informs the client whether it must >> send a connection ID, probably encrypted, and nobody >> needs any flags, unless the presence of connection ID >> changes the offsets of fields we *do* want to explicitly >> expose, such as packet number echo >> (https://github.com/quicwg/base-drafts/issues/269 >> ) or >> troubleshooting flags >> (https://github.com/quicwg/base-drafts/issues/279 >> ). >> > >> > Not to put too fine a point on it, but there's far from >> consensus that we want to expose >> > either of these. >> >> That's not too fine a point at all; I'm not presupposing >> consensus on either of these. All I'm saying here is, >> should consensus emerge that the benefits outweigh the >> costs (both in complexity and in risk) for certain kinds >> of exposure to the path -- which I think may be the case >> for some of the things under discussion in 279, and I'm >> obviously convinced of the utility of packet number echo >> as in 269 or I wouldn't have submitted two PRs on it -- >> we need to be clear that other choices we make about the >> layout of the header doesn't make that harder than it >> needs to be. Sticking variable-length/optional fields >> whose presence is dependent on endpoint-shared state >> after the exposed fields is probably sufficient for this. >> >> >> Cheers, >> >> Brian >> >> >> > > --------------B4ED805A49BB52615873A405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes, it is only necessary to identify the connection. If it is done through IP addresses and ports or connection id shouldn't matter in this respect.


Roland


Am 09.03.2017 um 19:07 schrieb Eric Rescorla:
This seems like an argument for a visible close, not for a connection ID.

-Ekr


On Thu, Mar 9, 2017 at 10:00 AM, Roland Zink <roland@zinks.de> wrote:

For TCP connections the middlebox (NAT) gets a signal when a connection ends. The NAT need to use the timeout only for connections where this doesn't happen. When there is no identificable connection and end signal then the NAT need to use the timeout for all such mappings. With a limited table size the timeout for such mappings needs to be shorter. With a identificable connection and an end signal NATs can increase the timeout for QUIC.

Roland



Am 09.03.2017 um 18:32 schrieb Eric Rescorla:


On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar <jri@google.com> wrote:
A thoughts as I catch up on this thread (and in response to ekr's original question):

- As ekr points out, server-side middleboxes can always rely on connection IDs by policy. The value of the connection ID bit, in my mind, is for middleboxes not controlled by the server. Such middleboxes are likely to use the connection ID to identify connections where it exists. Without an explicit per-packet bit, a middlebox that wants to use connection ID will have to dig into the handshake to determine where it's presence negotiated. This leads to ossification of bits inside the cleartext handshake messages, which is highly undesirable. I'd rather that the connection ID bit be ossified.

Sure, but this starts from the position that middleboxes should be using connection
IDs. It's not clear to me that we want to encourage that.


- As it stands, connection ID negotiation means that each side tells the peer what it wants the peer to do. In a world with (i) no connection ID bit and (ii) clients vetoing the server's request, policy decisions are hard for load balancers. In this world, there's no good way for server-side load balancers to know per connection whether it has a connection ID or not: to find connection state, the load balancer needs a key, which would be the connection ID, which may or may not be present for that connection. The load balancer could use the 4-tuple to key the connection, but that entirely defeats the point of using the connection ID.

Hmm... This seems rather more to be the result of letting the client veto. In the design
you propose, the server does:

- If connection id bit is 1 look up connection ID
- Otherwise, look up the host/port


If you don't have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look for it
- If that's missing, drop the packet



- The privacy implications of sharing connection ID is a separate conversation from the one this thread was started on. Though since some points were raised here and since they speak to the question of what information to share with middleboxes, I'll share my thoughts. 

We need to separate the use of connection ID use across NAT rebindings vs the use of connection ID use across client network changes. 

We'd all probably agree that NAT rebindings for UDP are a real concern, since NATs kill these bindings faster than they do TCP bindings.

Actually, no, I'm not persuaded by this as yet. I agree with the statement that NATs kill these bindings
faster, but it's not yet clear to me that connection IDs ameliorate these problems sufficiently to
improve the situation. I'd be happy to see any data you have that supports this point.



We'd all agree that connection ID use across client network changes is a new beast. To this end, I think we've generally agreed (informally anyways) that the client must use a new connection ID when it triggers connection migration to a different network.

The difficulty is that we do not presently know how to arrange that you always use a new conn id
on migration without using a new conn id on each packet.


In sum, my argument is that having connection IDs stable across NAT rebindings is a necessity for QUIC to work well. As a result, middleboxes at various points in the network, specifically those past a NAT, are expected to use it to track connection state. Explicitly noting its presence in the packet anticipates this and eliminates this one reason for ossification of other bits deep in handshake messages needed otherwise for its inference.

I don't see you arguing that this is desirable so much as inevitable. So, if we had a design that
was reasonably efficient that used a different connection ID per packet, then you would be
fine with that and wouldn't feel the need to tell middleboxes where it was?

-Ekr
 

- jana


On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves that to the client.
> > Except that if the load balancer *needs* it, then the client has to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, the client supplied
> the connection ID, so the server side merely had to load balance based on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-suggested Connection ID proposal is that it's needed for efficient load balancing". I'm taking that assertion at face value now, possibly because I'm convinced of the utility of one of its side-effects: providing some additional grade of assurance to a device on path that a given packet was not injected off-path, which is useful in in-network DoS mitigation (as in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing tracking information could refuse to make Connection ID available, at the cost of degraded performance.

(I would like to reiterate that I do think that it's necessary to allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads to connection failure, then "negotiation" is a euphemism: the server informs the client whether it must send a connection ID, probably encrypted, and nobody needs any flags, unless the presence of connection ID changes the offsets of fields we *do* want to explicitly expose, such as packet number echo (https://github.com/quicwg/base-drafts/issues/269) or troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing consensus on either of these. All I'm saying here is, should consensus emerge that the benefits outweigh the costs (both in complexity and in risk) for certain kinds of exposure to the path -- which I think may be the case for some of the things under discussion in 279, and I'm obviously convinced of the utility of packet number echo as in 269 or I wouldn't have submitted two PRs on it -- we need to be clear that other choices we make about the layout of the header doesn't make that harder than it needs to be. Sticking variable-length/optional fields whose presence is dependent on endpoint-shared state after the exposed fields is probably sufficient for this.


Cheers,

Brian






--------------B4ED805A49BB52615873A405-- From nobody Thu Mar 9 10:18:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B771296F3 for ; Thu, 9 Mar 2017 10:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk8w-cC_uihP for ; Thu, 9 Mar 2017 10:18:25 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 046DE1296E1 for ; Thu, 9 Mar 2017 10:18:25 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v198so11628808ywc.2 for ; Thu, 09 Mar 2017 10:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aL+SewhLyqj+sXggFniFQ6xJYRfcWqWfqHlJylQPzWw=; b=Zdt358Prd4tS2ZNvzIYE9XxaDtWl6r5hhiavJNqLlX3XD1hZ7Vn7t/HgSMd0pOIT31 Y4lNBmmx0A2EdH5EGyvgX1RqjOQSufeUIySTvAls2Kx0utZFuG5b9ilw7NHDGHzc5lQk hW5gnG5vH4pkgxCpmvHKRWI9SrnqqdgtwFv20GjGkNhiErIbGPkFxQ+AnEKs1x8cpFRB ecU4q5Zg41leFs7XzFPVta3FaMDdi1P7GzdnTE+jJye240zUlZ1ek5ewdH2yyTzO5DmF p99/cLd6aN+lBjSWM55ZE7c9SvfasSwzsMkaG+gcJAwBfyeQE5SVh+iVEhVMXO+rnzzs kTLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aL+SewhLyqj+sXggFniFQ6xJYRfcWqWfqHlJylQPzWw=; b=AFxNkJEo2V3Z/QpLlAcMv3HE1UT2ilSN98cEPpUWiB08/i02eCzjUhLNET+0jbaT9y ucqpaUfXZKNB7LRIKXupDtoIGDwnYY58kyfQVukSjXGiGnd1fhYGMx2vZbCsjo68n54y FSwwf4EztKr2MZPRAArv7sLadu8dk1dY0dy8usR2fd7pqYxl/w5W831AKZqMtxCgfPz2 f9Xaol+kJu1nKeUtKK094EVbrYhY9HR6LLOGnCAc53PmTh139dml6X1RhsHaIdBM9z6b ZRnCkSiOT4xxvi5dBG4JIwE9wLxTA0Pu/24et+Hq3BNeaIWyZErXYVbro1xi2TrYK/a3 RQjw== X-Gm-Message-State: AMke39lmFsoi3tUh3esuauXJwPjW9zqbHXUPXghoVEsWNr2VqFfG96i682DD4BgWeGP08nGMK6hQJlRweqMVlQ== X-Received: by 10.129.125.5 with SMTP id y5mr4666459ywc.120.1489083504182; Thu, 09 Mar 2017 10:18:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 10:17:43 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 10:17:43 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Ian Swett Content-Type: multipart/alternative; boundary=001a114936444efda9054a5045c0 Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:18:28 -0000 --001a114936444efda9054a5045c0 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 10:12 AM, Ian Swett wrote: > > > On Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla wrote: > >> >> >> On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: >> >>> A thoughts as I catch up on this thread (and in response to ekr's >>> original question): >>> >>> - As ekr points out, server-side middleboxes can always rely on >>> connection IDs by policy. The value of the connection ID bit, in my mind, >>> is for middleboxes not controlled by the server. Such middleboxes are >>> likely to use the connection ID to identify connections where it exists. >>> Without an explicit per-packet bit, a middlebox that wants to use >>> connection ID will have to dig into the handshake to determine where it's >>> presence negotiated. This leads to ossification of bits inside the >>> cleartext handshake messages, which is highly undesirable. I'd rather that >>> the connection ID bit be ossified. >>> >> >> Sure, but this starts from the position that middleboxes should be using >> connection >> IDs. It's not clear to me that we want to encourage that. >> >> >>> - As it stands, connection ID negotiation means that each side tells the >>> peer what it wants the peer to do. In a world with (i) no connection ID bit >>> and (ii) clients vetoing the server's request, policy decisions are hard >>> for load balancers. In this world, there's no good way for server-side load >>> balancers to know per connection whether it has a connection ID or not: to >>> find connection state, the load balancer needs a key, which would be the >>> connection ID, which may or may not be present for that connection. The >>> load balancer could use the 4-tuple to key the connection, but that >>> entirely defeats the point of using the connection ID. >>> >> >> Hmm... This seems rather more to be the result of letting the client >> veto. In the design >> you propose, the server does: >> >> - If connection id bit is 1 look up connection ID >> - Otherwise, look up the host/port >> >> >> If you don't have a bit, you can >> >> - Look up the host/port >> - If it's missing assume that there is a connection ID and look for it >> - If that's missing, drop the packet >> >> >> >>> - The privacy implications of sharing connection ID is a separate >>> conversation from the one this thread was started on. Though since some >>> points were raised here and since they speak to the question of what >>> information to share with middleboxes, I'll share my thoughts. >>> >>> We need to separate the use of connection ID use across NAT rebindings >>> vs the use of connection ID use across client network changes. >>> >>> We'd all probably agree that NAT rebindings for UDP are a real concern, >>> since NATs kill these bindings faster than they do TCP bindings. >>> >> >> Actually, no, I'm not persuaded by this as yet. I agree with the >> statement that NATs kill these bindings >> faster, but it's not yet clear to me that connection IDs ameliorate these >> problems sufficiently to >> improve the situation. I'd be happy to see any data you have that >> supports this point. >> >> > This happens often, particularly after 1 minute, and connection ID makes > it work seamlessly, so I'm pretty sure it works sufficiently well. It is > critical to longer(ie: 5 minute) idle timeouts. > I am aware of this argument, but I was looking for something that looked a little more like data :) We'd all agree that connection ID use across client network changes is a >>> new beast. To this end, I think we've generally agreed (informally anyways) >>> that the client must use a new connection ID when it triggers connection >>> migration to a different network. >>> >> >> The difficulty is that we do not presently know how to arrange that you >> always use a new conn id >> on migration without using a new conn id on each packet. >> >> >> In sum, my argument is that having connection IDs stable across NAT >>> rebindings is a necessity for QUIC to work well. As a result, middleboxes >>> at various points in the network, specifically those past a NAT, are >>> expected to use it to track connection state. Explicitly noting its >>> presence in the packet anticipates this and eliminates this one reason for >>> ossification of other bits deep in handshake messages needed otherwise for >>> its inference. >>> >> >> I don't see you arguing that this is desirable so much as inevitable. So, >> if we had a design that >> was reasonably efficient that used a different connection ID per packet, >> then you would be >> fine with that and wouldn't feel the need to tell middleboxes where it >> was? >> > > I don't think having the same connection ID used after a NAT rebind is a > problem. > It actually is a small problem, because often many people are behind the same NAT. But I agree that the primary problem is network transitions. The attack of interest is linking one or more actions in one network with > one or more on another network. If you're on the client side of the NAT > nothing changes, and if you're on the server side you already know the set > of ports(or ports and IPs) that a given NAT uses publicly, so they're all > equivalent from the observer's perspective. The NAT is a physical entity > and there are some fairly tight real-world constraints on where you end up > during a rebind. > > Is there a different threat model that I'm not aware of? > See above. -Ekr > > -Ekr >> >> >>> >>> - jana >>> >>> >>> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: >>> >>>> hi Ekr, all, >>>> >>>> > > Well, with negotiation, someone has to decide. The bit just moves >>>> that to the client. >>>> > > Except that if the load balancer *needs* it, then the client has to >>>> conform. >>>> > >>>> >> The load balancer needs it to balance load efficiently. >>>> >> >>>> > That's not entirely clear. Note that in the original QUIC design, the >>>> client supplied >>>> > the connection ID, so the server side merely had to load balance >>>> based on some combination >>>> > of a random value and the client's IP. >>>> >>>> Right; should have said that "the assertion behind server-suggested >>>> Connection ID proposal is that it's needed for efficient load balancing". >>>> I'm taking that assertion at face value now, possibly because I'm convinced >>>> of the utility of one of its side-effects: providing some additional grade >>>> of assurance to a device on path that a given packet was not injected >>>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>>> of the just-submitted manageability draft). >>>> >>>> >> I presume that a client that was very interested in not providing >>>> tracking information could refuse to make Connection ID available, at the >>>> cost of degraded performance. >>>> >>>> (I would like to reiterate that I do think that it's necessary to allow >>>> clients to veto server-proposed connection ID exposure.) >>>> >>>> >> (f that's not the case, if failure to send connection ID leads to >>>> connection failure, then "negotiation" is a euphemism: the server informs >>>> the client whether it must send a connection ID, probably encrypted, and >>>> nobody needs any flags, unless the presence of connection ID changes the >>>> offsets of fields we *do* want to explicitly expose, such as packet number >>>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>>> troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279 >>>> ). >>>> > >>>> > Not to put too fine a point on it, but there's far from consensus >>>> that we want to expose >>>> > either of these. >>>> >>>> That's not too fine a point at all; I'm not presupposing consensus on >>>> either of these. All I'm saying here is, should consensus emerge that the >>>> benefits outweigh the costs (both in complexity and in risk) for certain >>>> kinds of exposure to the path -- which I think may be the case for some of >>>> the things under discussion in 279, and I'm obviously convinced of the >>>> utility of packet number echo as in 269 or I wouldn't have submitted two >>>> PRs on it -- we need to be clear that other choices we make about the >>>> layout of the header doesn't make that harder than it needs to be. Sticking >>>> variable-length/optional fields whose presence is dependent on >>>> endpoint-shared state after the exposed fields is probably sufficient for >>>> this. >>>> >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> >>> >> > --001a114936444efda9054a5045c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 10:12 AM, Ian Swett <ianswett@google.com&= gt; wrote:


On= Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:


On Thu, Mar 9, 2017 at 9:08 = AM, Jana Iyengar <jri@google.com> wrote:
A thoughts as I catch up on this thread (and= in response to ekr's original question):

- As ekr po= ints out, server-side middleboxes can always rely on connection IDs by poli= cy. The value of the connection ID bit, in my mind, is for middleboxes not = controlled by the server. Such middleboxes are likely to use the connection= ID to identify connections where it exists. Without an explicit per-packet= bit, a middlebox that wants to use connection ID will have to dig into the= handshake to determine where it's presence negotiated. This leads to o= ssification of bits inside the cleartext handshake messages, which is highl= y undesirable. I'd rather that the connection ID bit be ossified.
=

Sure, but this st= arts from the position that middleboxes should be using connection
IDs. It's not clear to me that we want to encourage that.
=

- As it stands, connection ID negotiation means that each side= tells the peer what it wants the peer to do. In a world with (i) no connec= tion ID bit and (ii) clients vetoing the server's request, policy decis= ions are hard for load balancers. In this world, there's no good way fo= r server-side load balancers to know per connection whether it has a connec= tion ID or not: to find connection state, the load balancer needs a key, wh= ich would be the connection ID, which may or may not be present for that co= nnection. The load balancer could use the 4-tuple to key the connection, bu= t that entirely defeats the point of using the connection ID.

Hmm... This seems rather more t= o be the result of letting the client veto. In the design
you pro= pose, the server does:

- If connection id bit is 1= look up connection ID
- Otherwise, look up the host/port


If you don't have a bit, you can
=

- Look up the host/port
- If it's missing= assume that there is a connection ID and look for it
- If that&#= 39;s missing, drop the packet



- The = privacy implications of sharing connection ID is a separate conversation fr= om the one this thread was started on. Though since some points were raised= here and since they speak to the question of what information to share wit= h middleboxes, I'll share my thoughts.=C2=A0

W= e need to separate the use of connection ID use across NAT rebindings vs th= e use of connection ID use across client network changes.=C2=A0
<= br>
We'd all probably agree that NAT rebindings for UDP are a= real concern, since NATs kill these bindings faster than they do TCP bindi= ngs.

Actually, no,= I'm not persuaded by this as yet. I agree with the statement that NATs= kill these bindings
faster, but it's not yet clear to me tha= t connection IDs ameliorate these problems sufficiently to
improv= e the situation. I'd be happy to see any data you have that supports th= is point.

<= div>
This happens often, particularly after 1 minute, = and connection ID makes it work seamlessly, so I'm pretty sure it works= sufficiently well.=C2=A0 It is critical to longer(ie: 5 minute) idle timeo= uts.=C2=A0

I am awa= re of this argument, but I was looking for something that looked a little m= ore like
data :)


We'd all agree that conn= ection ID use across client network changes is a new beast. To this end, I = think we've generally agreed (informally anyways) that the client must = use a new connection ID when it triggers connection migration to a differen= t network.

The dif= ficulty is that we do not presently know how to arrange that you always use= a new conn id
on migration without using a new conn id on each p= acket.


In sum, my argument is that having connectio= n IDs stable across NAT rebindings is a necessity for QUIC to work well. As= a result, middleboxes at various points in the network, specifically those= past a NAT, are expected to use it to track connection state. Explicitly n= oting its presence in the packet anticipates this and eliminates this one r= eason for ossification of other bits deep in handshake messages needed othe= rwise for its inference.

I don't see you arguing that this is desirable so much as inevit= able. So, if we had a design that
was reasonably efficient that u= sed a different connection ID per packet, then you would be
fine = with that and wouldn't feel the need to tell middleboxes where it was?<= /div>

I don't = think having the same connection ID used after a NAT rebind is a problem.

It actually is a sma= ll problem, because often many people are behind the same NAT.
Bu= t I agree that the primary problem is network transitions.



--001a114936444efda9054a5045c0-- From nobody Thu Mar 9 10:21:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51701296EC for ; Thu, 9 Mar 2017 10:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMFYpCqv_COI for ; Thu, 9 Mar 2017 10:21:26 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E99141296E1 for ; Thu, 9 Mar 2017 10:21:25 -0800 (PST) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by linode64.ducksong.com (Postfix) with ESMTPSA id 903A63A0A2 for ; Thu, 9 Mar 2017 13:21:24 -0500 (EST) Received: by mail-qk0-f179.google.com with SMTP id v125so129886207qkh.2 for ; Thu, 09 Mar 2017 10:21:24 -0800 (PST) X-Gm-Message-State: AMke39lwqN1gw43JBvFsTDhGfwOjXNlnGJQ3+T6B4s2GLraojFruHMXSXvrLS3ivO8ODxQIc7oY2q7mHBX+GTA== X-Received: by 10.200.42.151 with SMTP id b23mr15198647qta.163.1489083684114; Thu, 09 Mar 2017 10:21:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.177.130 with HTTP; Thu, 9 Mar 2017 10:21:23 -0800 (PST) In-Reply-To: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> From: Patrick McManus Date: Thu, 9 Mar 2017 13:21:23 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Divergence from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1142f5c2086ed3054a50503d Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:21:28 -0000 --001a1142f5c2086ed3054a50503d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, I think it would be good if you resent the question - particularly the bit about registries - in a new email with full background to both the quic and httpbis lists... That community might have opinions as well and QUIC wg is chartered explicitly to work closely with them. my opinion has solidified over time to the "separate protocols but same semantics (i.e. hq=3D=3Dh3)" position - esp wrt qpack which I think will be very valuable for hq. -P On Thu, Mar 9, 2017 at 10:59 AM, Mike Bishop wrote: > To me, it=E2=80=99s a *mostly* editorial difference =E2=80=93 do we try t= o contort the > IANA registry to claim these are two variants of the same protocol, or do > we just tell IANA they=E2=80=99re different protocols with different regi= stries? I > don=E2=80=99t see that one choice implies a larger scope than the other. = I think > the mission is still the same =E2=80=93 deliver HTTP semantics over QUIC. > > > > We=E2=80=99ve already decided we=E2=80=99re willing to make a number of d= epartures from > HTTP/2 because it makes technical sense in each individual case. > Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional > streams in each direction) the HTTP mapping would do likewise in response > (see branch unidirectional2). > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Thursday, March 9, 2017 6:28 AM > *To:* Stefan Eissing > *Cc:* Mike Bishop ; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > Thanks for sending this out to the list. I always hoped we could keep > HTTP over QUIC as similar to H2 as possible, but as you've pointed out > previously, a lot of HTTP/2 was adding transport features such as multipl= e > streams and flow control on top of an existing transport. Switching to > QPACK would be another dramatic departure. > > > > I'm not excited about QUIC abandoning HTTP2, but it may make enough > technical and documentation sense to be the right thing to do. I am > concerned this could expand the scope of the HTTP mapping too much, so if > we're going to make this choice, I'd like to know what types of changes a= re > in scope. > > > > On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing < > stefan.eissing@greenbytes.de> wrote: > > Thanks for separating this out, Mike. For spare time folks this makes > following this aspect easier. > > > > My first impression is that any hope to have http/2 over tcp and quic > needs to be abandoned. Which will give the world a third protocol to carr= y > http semantics. > > > > What does that mean for the evolution of http, I wonder. > > > > -stefan > > > Am 09.03.2017 um 03:16 schrieb Mike Bishop = : > > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are > the same protocol. However, the draft currently still attempts to define > them as close cousins. In PR #363 > , I=E2=80=99ve consolidat= ed > almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new= section and > excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC does= n=E2=80=99t need > it=E2=80=9D from the main body of the document. Martin has advocated mak= ing a > clean break from HTTP/2 and defining our own IANA registry for frame type= s > and settings, just as we already have for errors. We can, out of respect > for legacy, use the same values where appropriate and reserve existing > values currently in use on the HTTP/2 side. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from the WG about either would be welcome. > > > --001a1142f5c2086ed3054a50503d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike, I think it would be good if you resent the ques= tion - particularly the bit about registries - in a new email with full bac= kground to both the quic and httpbis lists... That community might have opi= nions as well and QUIC wg is chartered explicitly to work closely with them= .

my opinion has solidified over time to the "separa= te protocols but same semantics (i.e. hq=3D=3Dh3)" position - esp wrt = qpack which I think will be very valuable for hq.

-P
<= /div>

On= Thu, Mar 9, 2017 at 10:59 AM, Mike Bishop <Michael.Bishop@micr= osoft.com> wrote:

To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to contort the IANA = registry to claim these are two variants of the same protocol, or do we jus= t tell IANA they=E2=80=99re different protocols with different registries?= =C2=A0 I don=E2=80=99t see that one choice implies a larger scope than the other.=C2=A0 I think the mission is still the same =E2=80=93 deli= ver HTTP semantics over QUIC.

=C2=A0

We=E2=80=99ve already decided we=E2=80=99re willing= to make a number of departures from HTTP/2 because it makes technical sens= e in each individual case.=C2=A0 Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each direction) the HTTP ma= pping would do likewise in response (see branch unidirectional2).=

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org
Subject: Re: Divergence from HTTP/2

=C2=A0

Thanks for sending this out to the list.=C2=A0 I alw= ays hoped we could keep HTTP over QUIC as similar to H2 as possible, but as= you've pointed out previously, a lot of HTTP/2 was adding transport fe= atures such as multiple streams and flow control on top of an existing transport.=C2=A0 Switching to QPACK would be another= dramatic departure.

=C2=A0

I'm not excited about QUIC abandoning HTTP2, but= it may make enough technical and documentation sense to be the right thing= to do.=C2=A0 I am concerned this could expand the scope of the HTTP mappin= g too much, so if we're going to make this choice, I'd like to know what types of changes are in scope.=C2=A0<= /u>

=C2=A0

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <<= a href=3D"mailto:stefan.eissing@greenbytes.de" target=3D"_blank">stefan.eis= sing@greenbytes.de> wrote:

Thanks for separating this out, Mike. For spare time= folks this makes following this aspect easier.

=C2=A0

My first impression is that any hope to have http/2 = over tcp and quic needs to be abandoned. Which will give the world a third = protocol to carry http semantics.

=C2=A0

What does that mean for the evolution of http, I won= der.

=C2=A0

-stefan<= /span>


Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com><= wbr>:

At this point, I don=E2=80=99t think anyone expects = that HTTP/QUIC and HTTP/2 are the same protocol.=C2=A0 However, the draft c= urrently still attempts to define them as close cousins.=C2=A0 In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdiffere= nt from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff = about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D from the main body of the document.=C2=A0 Martin has advocated making a clean b= reak from HTTP/2 and defining our own IANA registry for frame types and set= tings, just as we already have for errors.=C2=A0 We can, out of respect for= legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.=

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from the WG about either would be welcome.<= u>

=C2=A0


--001a1142f5c2086ed3054a50503d-- From nobody Thu Mar 9 10:28:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375011296FB for ; Thu, 9 Mar 2017 10:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HmC3MCpD2tdh for ; Thu, 9 Mar 2017 10:28:39 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AEE1296F9 for ; Thu, 9 Mar 2017 10:28:39 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id d88so4653191ybi.0 for ; Thu, 09 Mar 2017 10:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0/y5XNGSaA4DaMeyqYwhpusjmSUpSiwNNFj/TfqZuwE=; b=lhmGHq4BKFqG9fnpsrOcklFfJumccNKjzyx3p7A6fSdgnVpADeeEUamQrxNqJoZw1f th9y/wGRV4ND+BptkGnA6tzrHKZDvySzyikI4qDDuj0O9WCIEyur9NXyvkdMLOqwsBNs uk0sfW/uoyBFDsbrBLOC2oCxXcthS/zd2MtOGWf0LMqytp1zgOozyyjjCgG3fruGNvCK mTBpEuT0BwBDUATino3vA7WBMOiNeSP89cETHNd8jgAHJSJHL3vNvuU1dT1G66V+/lx5 2twxcWg9+J58S+ZxBJjjDU7AlavHODV4l5oaezquZcBTDM/VqgX5woG/5HLiIpPWaqSE 1IZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0/y5XNGSaA4DaMeyqYwhpusjmSUpSiwNNFj/TfqZuwE=; b=tEeY7hCs40lH01yyJBnZE6zQ3kUMFTgYkEC+hQ8TEtMA/NiPrB+Tu3NGEbjSIoSuGh mhA1xbsMHUXVwCSYfPYXTTCVOkEgNcEaLyvQcU2yQlQ9sV9QLhnQmJal5Ge1ptR7EVof r2GbisIYY53BDJm1GuWb0fEME2XyyaCe53EeZZA1ytxVxiEAtV9lOD1bXqn2lqKtZdDC Lps3tRvUKyLGtB64XUhX4LScD33grO/uYcNT2uewQBs9n38CdUPqpUamv+2K09FIcOK4 tP8nTGnr7MQeneG5L1b2Uhmsj9jd13k7MW38gQtyrTSvZwfclC6J8VSYUQcehZBUY5FJ N8Cw== X-Gm-Message-State: AFeK/H2HKlTmxZeEcr67xQD/vvjIykDES2SEO1ZBAl+Hv42Az9XFeJGCFYpRq9Ye69qyrH9uUy6vMrkDzsWpTM/G X-Received: by 10.37.192.16 with SMTP id c16mr2560524ybf.195.1489084118013; Thu, 09 Mar 2017 10:28:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.143 with HTTP; Thu, 9 Mar 2017 10:28:17 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Mar 2017 13:28:17 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113a119ae5aea9054a506941 Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:28:42 -0000 --001a113a119ae5aea9054a506941 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 1:17 PM, Eric Rescorla wrote: > > > On Thu, Mar 9, 2017 at 10:12 AM, Ian Swett wrote: > >> >> >> On Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla wrote: >> >>> >>> >>> On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: >>> >>>> A thoughts as I catch up on this thread (and in response to ekr's >>>> original question): >>>> >>>> - As ekr points out, server-side middleboxes can always rely on >>>> connection IDs by policy. The value of the connection ID bit, in my mind, >>>> is for middleboxes not controlled by the server. Such middleboxes are >>>> likely to use the connection ID to identify connections where it exists. >>>> Without an explicit per-packet bit, a middlebox that wants to use >>>> connection ID will have to dig into the handshake to determine where it's >>>> presence negotiated. This leads to ossification of bits inside the >>>> cleartext handshake messages, which is highly undesirable. I'd rather that >>>> the connection ID bit be ossified. >>>> >>> >>> Sure, but this starts from the position that middleboxes should be using >>> connection >>> IDs. It's not clear to me that we want to encourage that. >>> >>> >>>> - As it stands, connection ID negotiation means that each side tells >>>> the peer what it wants the peer to do. In a world with (i) no connection ID >>>> bit and (ii) clients vetoing the server's request, policy decisions are >>>> hard for load balancers. In this world, there's no good way for server-side >>>> load balancers to know per connection whether it has a connection ID or >>>> not: to find connection state, the load balancer needs a key, which would >>>> be the connection ID, which may or may not be present for that connection. >>>> The load balancer could use the 4-tuple to key the connection, but that >>>> entirely defeats the point of using the connection ID. >>>> >>> >>> Hmm... This seems rather more to be the result of letting the client >>> veto. In the design >>> you propose, the server does: >>> >>> - If connection id bit is 1 look up connection ID >>> - Otherwise, look up the host/port >>> >>> >>> If you don't have a bit, you can >>> >>> - Look up the host/port >>> - If it's missing assume that there is a connection ID and look for it >>> - If that's missing, drop the packet >>> >>> >>> >>>> - The privacy implications of sharing connection ID is a separate >>>> conversation from the one this thread was started on. Though since some >>>> points were raised here and since they speak to the question of what >>>> information to share with middleboxes, I'll share my thoughts. >>>> >>>> We need to separate the use of connection ID use across NAT rebindings >>>> vs the use of connection ID use across client network changes. >>>> >>>> We'd all probably agree that NAT rebindings for UDP are a real concern, >>>> since NATs kill these bindings faster than they do TCP bindings. >>>> >>> >>> Actually, no, I'm not persuaded by this as yet. I agree with the >>> statement that NATs kill these bindings >>> faster, but it's not yet clear to me that connection IDs ameliorate >>> these problems sufficiently to >>> improve the situation. I'd be happy to see any data you have that >>> supports this point. >>> >>> >> This happens often, particularly after 1 minute, and connection ID makes >> it work seamlessly, so I'm pretty sure it works sufficiently well. It is >> critical to longer(ie: 5 minute) idle timeouts. >> > > I am aware of this argument, but I was looking for something that looked a > little more like > data :) > What data would you like? To my knowledge, it works 100% of the time where connection ID routing is implemented for our infrastructure, and we configure conservative 30 second timeouts anywhere we can't rely on connection ID. > > > We'd all agree that connection ID use across client network changes is a >>>> new beast. To this end, I think we've generally agreed (informally anyways) >>>> that the client must use a new connection ID when it triggers connection >>>> migration to a different network. >>>> >>> >>> The difficulty is that we do not presently know how to arrange that you >>> always use a new conn id >>> on migration without using a new conn id on each packet. >>> >>> >>> In sum, my argument is that having connection IDs stable across NAT >>>> rebindings is a necessity for QUIC to work well. As a result, middleboxes >>>> at various points in the network, specifically those past a NAT, are >>>> expected to use it to track connection state. Explicitly noting its >>>> presence in the packet anticipates this and eliminates this one reason for >>>> ossification of other bits deep in handshake messages needed otherwise for >>>> its inference. >>>> >>> >>> I don't see you arguing that this is desirable so much as inevitable. >>> So, if we had a design that >>> was reasonably efficient that used a different connection ID per packet, >>> then you would be >>> fine with that and wouldn't feel the need to tell middleboxes where it >>> was? >>> >> >> I don't think having the same connection ID used after a NAT rebind is a >> problem. >> > > It actually is a small problem, because often many people are behind the > same NAT. > It clearly links the post-rebind portion of the connection with the pre-rebind portion of the connection, but I don't think it does anything else. A TCP connection presumably wouldn't have rebound in a similar circumstance, so you could trivially connect the two parts of the connection. That being said, I'd be interested in seeing a design for a fully encrypted header design if it was at all practical. > But I agree that the primary problem is network transitions. > > The attack of interest is linking one or more actions in one network >> with one or more on another network. If you're on the client side of the >> NAT nothing changes, and if you're on the server side you already know the >> set of ports(or ports and IPs) that a given NAT uses publicly, so they're >> all equivalent from the observer's perspective. The NAT is a physical >> entity and there are some fairly tight real-world constraints on where you >> end up during a rebind. >> >> Is there a different threat model that I'm not aware of? >> > > See above. > > -Ekr > > >> >> -Ekr >>> >>> >>>> >>>> - jana >>>> >>>> >>>> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell >>>> wrote: >>>> >>>>> hi Ekr, all, >>>>> >>>>> > > Well, with negotiation, someone has to decide. The bit just moves >>>>> that to the client. >>>>> > > Except that if the load balancer *needs* it, then the client has >>>>> to conform. >>>>> > >>>>> >> The load balancer needs it to balance load efficiently. >>>>> >> >>>>> > That's not entirely clear. Note that in the original QUIC design, >>>>> the client supplied >>>>> > the connection ID, so the server side merely had to load balance >>>>> based on some combination >>>>> > of a random value and the client's IP. >>>>> >>>>> Right; should have said that "the assertion behind server-suggested >>>>> Connection ID proposal is that it's needed for efficient load balancing". >>>>> I'm taking that assertion at face value now, possibly because I'm convinced >>>>> of the utility of one of its side-effects: providing some additional grade >>>>> of assurance to a device on path that a given packet was not injected >>>>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>>>> of the just-submitted manageability draft). >>>>> >>>>> >> I presume that a client that was very interested in not providing >>>>> tracking information could refuse to make Connection ID available, at the >>>>> cost of degraded performance. >>>>> >>>>> (I would like to reiterate that I do think that it's necessary to >>>>> allow clients to veto server-proposed connection ID exposure.) >>>>> >>>>> >> (f that's not the case, if failure to send connection ID leads to >>>>> connection failure, then "negotiation" is a euphemism: the server informs >>>>> the client whether it must send a connection ID, probably encrypted, and >>>>> nobody needs any flags, unless the presence of connection ID changes the >>>>> offsets of fields we *do* want to explicitly expose, such as packet number >>>>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>>>> troubleshooting flags (https://github.com/quicwg/bas >>>>> e-drafts/issues/279). >>>>> > >>>>> > Not to put too fine a point on it, but there's far from consensus >>>>> that we want to expose >>>>> > either of these. >>>>> >>>>> That's not too fine a point at all; I'm not presupposing consensus on >>>>> either of these. All I'm saying here is, should consensus emerge that the >>>>> benefits outweigh the costs (both in complexity and in risk) for certain >>>>> kinds of exposure to the path -- which I think may be the case for some of >>>>> the things under discussion in 279, and I'm obviously convinced of the >>>>> utility of packet number echo as in 269 or I wouldn't have submitted two >>>>> PRs on it -- we need to be clear that other choices we make about the >>>>> layout of the header doesn't make that harder than it needs to be. Sticking >>>>> variable-length/optional fields whose presence is dependent on >>>>> endpoint-shared state after the exposed fields is probably sufficient for >>>>> this. >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> >>>>> >>>> >>> >> > --001a113a119ae5aea9054a506941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 1:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Mar 9, 2017 a= t 10:12 AM, Ian Swett <ianswett@google.com> wrote:

=
On Thu, Mar 9, 2017 at 12:32 PM, Eric = Rescorla <ekr@rtfm.com> wrote:
=


On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar &l= t;jri@google.com>= ; wrote:
A though= ts as I catch up on this thread (and in response to ekr's original ques= tion):

- As ekr points out, server-side middleboxes can a= lways rely on connection IDs by policy. The value of the connection ID bit,= in my mind, is for middleboxes not controlled by the server. Such middlebo= xes are likely to use the connection ID to identify connections where it ex= ists. Without an explicit per-packet bit, a middlebox that wants to use con= nection ID will have to dig into the handshake to determine where it's = presence negotiated. This leads to ossification of bits inside the cleartex= t handshake messages, which is highly undesirable. I'd rather that the = connection ID bit be ossified.
Sure, but this starts from the position that middleboxes= should be using connection
IDs. It's not clear to me that we= want to encourage that.


- As it stands, connection= ID negotiation means that each side tells the peer what it wants the peer = to do. In a world with (i) no connection ID bit and (ii) clients vetoing th= e server's request, policy decisions are hard for load balancers. In th= is world, there's no good way for server-side load balancers to know pe= r connection whether it has a connection ID or not: to find connection stat= e, the load balancer needs a key, which would be the connection ID, which m= ay or may not be present for that connection. The load balancer could use t= he 4-tuple to key the connection, but that entirely defeats the point of us= ing the connection ID.

=
Hmm... This seems rather more to be the result of letting the client v= eto. In the design
you propose, the server does:

- If connection id bit is 1 look up connection ID
- Othe= rwise, look up the host/port


If you= don't have a bit, you can

- Look up the host/= port
- If it's missing assume that there is a connection ID a= nd look for it
- If that's missing, drop the packet



- The privacy implications of sharing connect= ion ID is a separate conversation from the one this thread was started on. = Though since some points were raised here and since they speak to the quest= ion of what information to share with middleboxes, I'll share my though= ts.=C2=A0

We need to separate the use of connectio= n ID use across NAT rebindings vs the use of connection ID use across clien= t network changes.=C2=A0

We'd all probably agr= ee that NAT rebindings for UDP are a real concern, since NATs kill these bi= ndings faster than they do TCP bindings.

Actually, no, I'm not persuaded by this as yet. = I agree with the statement that NATs kill these bindings
faster, = but it's not yet clear to me that connection IDs ameliorate these probl= ems sufficiently to
improve the situation. I'd be happy to se= e any data you have that supports this point.


This happens = often, particularly after 1 minute, and connection ID makes it work seamles= sly, so I'm pretty sure it works sufficiently well.=C2=A0 It is critica= l to longer(ie: 5 minute) idle timeouts.=C2=A0

I am aware of this argument, but I was l= ooking for something that looked a little more like
data :)
=

What data would you like= ?=C2=A0 To my knowledge, it works 100% of the time where connection ID rout= ing is implemented for our infrastructure, and we configure conservative 30= second timeouts anywhere we can't rely on connection ID.
=C2= =A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
We'd all agree= that connection ID use across client network changes is a new beast. To th= is end, I think we've generally agreed (informally anyways) that the cl= ient must use a new connection ID when it triggers connection migration to = a different network.

The difficulty is that we do not presently know how to arrange that you = always use a new conn id
on migration without using a new conn id= on each packet.


In sum, my argument is that having= connection IDs stable across NAT rebindings is a necessity for QUIC to wor= k well. As a result, middleboxes at various points in the network, specific= ally those past a NAT, are expected to use it to track connection state. Ex= plicitly noting its presence in the packet anticipates this and eliminates = this one reason for ossification of other bits deep in handshake messages n= eeded otherwise for its inference.

<= /div>
I don't see you arguing that this is desirable so much= as inevitable. So, if we had a design that
was reasonably effici= ent that used a different connection ID per packet, then you would be
=
fine with that and wouldn't feel the need to tell middleboxes wher= e it was?

I = don't think having the same connection ID used after a NAT rebind is a = problem.

It = actually is a small problem, because often many people are behind the same = NAT.

It clearly lin= ks the post-rebind portion of the connection with the pre-rebind portion of= the connection, but I don't think it does anything else.=C2=A0 A TCP c= onnection presumably wouldn't have rebound in a similar circumstance, s= o you could trivially connect the two parts of the connection.
That being said, I'd be interested in seeing a design for = a fully encrypted header design if it was at all practical.
=C2= =A0
But I agree that the primary probl= em is network transitions.

=C2=A0 The attack of interest is linking one or more = actions in one network with one or more on another network.=C2=A0 If you= 9;re on the client side of the NAT nothing changes, and if you're on th= e server side you already know the set of ports(or ports and IPs) that a gi= ven NAT uses publicly, so they're all equivalent from the observer'= s perspective.=C2=A0 The NAT is a physical entity and there are some fairly= tight real-world constraints on where you end up during a rebind.

Is there a different threat model that I'm not aware of?

See above.

-Ekr
=C2=A0

-Ekr
=
=C2=A0

- jana
=

On Thu, Mar 9, 2017 at 8:09 AM, Bria= n Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian






--001a113a119ae5aea9054a506941-- From nobody Thu Mar 9 10:39:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DBB1297BF for ; Thu, 9 Mar 2017 10:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 WKk4thMHFCXS for ; Thu, 9 Mar 2017 10:39:54 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B949512979D for ; Thu, 9 Mar 2017 10:39:53 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id m133so4701794ybb.1 for ; Thu, 09 Mar 2017 10:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l5Ezn03FP/gspzU8TJdPb6R+GXIaO6X1yx6FfEoVxSk=; b=KI3Z32Y7aMwX6Sir8J5fTSg9HVFzRmyuOyuRK1nFL4Dy2lMV6DV1sTwTJjdidyr47J lR8BMe4gWD4RnhhrAdUjTpRPaZrOaY3SFsMg6cJR+Ociy5N7SGbdpkyxweCHQA4XrIXT DOz8zeIal/V9Sm6eyVstfjZl1HLi4k9yXgK6DqIpjtfjRIgIM1BIL9sT3BNXuWLkVfD5 MaaJFwGAYKxHGFOShl9KiaKACfPjm+2oAtYO7AN4O143g9nddJtyQ8tBDwgyiQi3XSfi qY2mf+ObCsjNl6Z7L85wGAezR0ics7lqywo2JorkqJ9KdmV40cC49P/X0WxbU/8tTL3Q Py4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l5Ezn03FP/gspzU8TJdPb6R+GXIaO6X1yx6FfEoVxSk=; b=DCI88r45c8nREVhMx/IK+zYH5laNfXgksG9gcuGaBmReeKEIbm+dq5gKxN+5eosFUD 40KOFZArscbB5iKYGq5QGph044yWF8zUFxvOzuFEQw3p9io6fLun8piGi3P5K7pGX/In cC7B3Nvpt6WcPTxqgHFl0iLOMPrCXpnsTHq/8VbmpYaVrXZJmdc7lxB+a7Vydzp9rT0K jUsPdQsUuJimJCAGqWv6HyzQhdKoRBAM8Ncoyj2PO4QvjUDikLEHAOUHAKd0XGAthKkM lskmN4i7GMooRlVS8bcL1q2Sd9+X3uvF8OWtuakqHimtyeFQtnl3h7j6tz8qzWXa6Tkr Q59Q== X-Gm-Message-State: AMke39nIcpZgbc5xDHnCb3VIiCRxa1ximOu+cIR5gUyPrX5ksGgwJlGBOZhfMEqKIp9Kp+d6JeD1HHlVbjJ/CA== X-Received: by 10.37.201.196 with SMTP id z187mr5148454ybf.161.1489084792764; Thu, 09 Mar 2017 10:39:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 10:39:12 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 10:39:12 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Ian Swett Content-Type: multipart/alternative; boundary=001a114d88ea1d0e4d054a509293 Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:39:56 -0000 --001a114d88ea1d0e4d054a509293 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 10:28 AM, Ian Swett wrote: > On Thu, Mar 9, 2017 at 1:17 PM, Eric Rescorla wrote: > >> >> >> On Thu, Mar 9, 2017 at 10:12 AM, Ian Swett wrote: >> >>> >>> >>> On Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: >>>> >>>>> A thoughts as I catch up on this thread (and in response to ekr's >>>>> original question): >>>>> >>>>> - As ekr points out, server-side middleboxes can always rely on >>>>> connection IDs by policy. The value of the connection ID bit, in my mind, >>>>> is for middleboxes not controlled by the server. Such middleboxes are >>>>> likely to use the connection ID to identify connections where it exists. >>>>> Without an explicit per-packet bit, a middlebox that wants to use >>>>> connection ID will have to dig into the handshake to determine where it's >>>>> presence negotiated. This leads to ossification of bits inside the >>>>> cleartext handshake messages, which is highly undesirable. I'd rather that >>>>> the connection ID bit be ossified. >>>>> >>>> >>>> Sure, but this starts from the position that middleboxes should be >>>> using connection >>>> IDs. It's not clear to me that we want to encourage that. >>>> >>>> >>>>> - As it stands, connection ID negotiation means that each side tells >>>>> the peer what it wants the peer to do. In a world with (i) no connection ID >>>>> bit and (ii) clients vetoing the server's request, policy decisions are >>>>> hard for load balancers. In this world, there's no good way for server-side >>>>> load balancers to know per connection whether it has a connection ID or >>>>> not: to find connection state, the load balancer needs a key, which would >>>>> be the connection ID, which may or may not be present for that connection. >>>>> The load balancer could use the 4-tuple to key the connection, but that >>>>> entirely defeats the point of using the connection ID. >>>>> >>>> >>>> Hmm... This seems rather more to be the result of letting the client >>>> veto. In the design >>>> you propose, the server does: >>>> >>>> - If connection id bit is 1 look up connection ID >>>> - Otherwise, look up the host/port >>>> >>>> >>>> If you don't have a bit, you can >>>> >>>> - Look up the host/port >>>> - If it's missing assume that there is a connection ID and look for it >>>> - If that's missing, drop the packet >>>> >>>> >>>> >>>>> - The privacy implications of sharing connection ID is a separate >>>>> conversation from the one this thread was started on. Though since some >>>>> points were raised here and since they speak to the question of what >>>>> information to share with middleboxes, I'll share my thoughts. >>>>> >>>>> We need to separate the use of connection ID use across NAT rebindings >>>>> vs the use of connection ID use across client network changes. >>>>> >>>>> We'd all probably agree that NAT rebindings for UDP are a real >>>>> concern, since NATs kill these bindings faster than they do TCP bindings. >>>>> >>>> >>>> Actually, no, I'm not persuaded by this as yet. I agree with the >>>> statement that NATs kill these bindings >>>> faster, but it's not yet clear to me that connection IDs ameliorate >>>> these problems sufficiently to >>>> improve the situation. I'd be happy to see any data you have that >>>> supports this point. >>>> >>>> >>> This happens often, particularly after 1 minute, and connection ID makes >>> it work seamlessly, so I'm pretty sure it works sufficiently well. It is >>> critical to longer(ie: 5 minute) idle timeouts. >>> >> >> I am aware of this argument, but I was looking for something that looked >> a little more like >> data :) >> > > What data would you like? To my knowledge, it works 100% of the time > where connection ID routing is implemented for our infrastructure, and we > configure conservative 30 second timeouts anywhere we can't rely on > connection ID. > I'll think about how to phrase the question precisely and either send e-mail or grab you in ORD. We'd all agree that connection ID use across client network changes is a >>>>> new beast. To this end, I think we've generally agreed (informally anyways) >>>>> that the client must use a new connection ID when it triggers connection >>>>> migration to a different network. >>>>> >>>> >>>> The difficulty is that we do not presently know how to arrange that you >>>> always use a new conn id >>>> on migration without using a new conn id on each packet. >>>> >>>> >>>> In sum, my argument is that having connection IDs stable across NAT >>>>> rebindings is a necessity for QUIC to work well. As a result, middleboxes >>>>> at various points in the network, specifically those past a NAT, are >>>>> expected to use it to track connection state. Explicitly noting its >>>>> presence in the packet anticipates this and eliminates this one reason for >>>>> ossification of other bits deep in handshake messages needed otherwise for >>>>> its inference. >>>>> >>>> >>>> I don't see you arguing that this is desirable so much as inevitable. >>>> So, if we had a design that >>>> was reasonably efficient that used a different connection ID per >>>> packet, then you would be >>>> fine with that and wouldn't feel the need to tell middleboxes where it >>>> was? >>>> >>> >>> I don't think having the same connection ID used after a NAT rebind is a >>> problem. >>> >> >> It actually is a small problem, because often many people are behind the >> same NAT. >> > > It clearly links the post-rebind portion of the connection with the > pre-rebind portion of the connection, but I don't think it does anything > else. A TCP connection presumably wouldn't have rebound in a similar > circumstance, so you could trivially connect the two parts of the > connection. > I don't disagree with this statement. And to which our target is no worse than TCP, then mission accomplished here. But it's still part of the threat model :) -Ekr > > That being said, I'd be interested in seeing a design for a fully > encrypted header design if it was at all practical. > > >> But I agree that the primary problem is network transitions. >> >> The attack of interest is linking one or more actions in one network >>> with one or more on another network. If you're on the client side of the >>> NAT nothing changes, and if you're on the server side you already know the >>> set of ports(or ports and IPs) that a given NAT uses publicly, so they're >>> all equivalent from the observer's perspective. The NAT is a physical >>> entity and there are some fairly tight real-world constraints on where you >>> end up during a rebind. >>> >>> Is there a different threat model that I'm not aware of? >>> >> >> See above. >> >> -Ekr >> >> >>> >>> -Ekr >>>> >>>> >>>>> >>>>> - jana >>>>> >>>>> >>>>> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell >>>>> wrote: >>>>> >>>>>> hi Ekr, all, >>>>>> >>>>>> > > Well, with negotiation, someone has to decide. The bit just moves >>>>>> that to the client. >>>>>> > > Except that if the load balancer *needs* it, then the client has >>>>>> to conform. >>>>>> > >>>>>> >> The load balancer needs it to balance load efficiently. >>>>>> >> >>>>>> > That's not entirely clear. Note that in the original QUIC design, >>>>>> the client supplied >>>>>> > the connection ID, so the server side merely had to load balance >>>>>> based on some combination >>>>>> > of a random value and the client's IP. >>>>>> >>>>>> Right; should have said that "the assertion behind server-suggested >>>>>> Connection ID proposal is that it's needed for efficient load balancing". >>>>>> I'm taking that assertion at face value now, possibly because I'm convinced >>>>>> of the utility of one of its side-effects: providing some additional grade >>>>>> of assurance to a device on path that a given packet was not injected >>>>>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>>>>> of the just-submitted manageability draft). >>>>>> >>>>>> >> I presume that a client that was very interested in not providing >>>>>> tracking information could refuse to make Connection ID available, at the >>>>>> cost of degraded performance. >>>>>> >>>>>> (I would like to reiterate that I do think that it's necessary to >>>>>> allow clients to veto server-proposed connection ID exposure.) >>>>>> >>>>>> >> (f that's not the case, if failure to send connection ID leads to >>>>>> connection failure, then "negotiation" is a euphemism: the server informs >>>>>> the client whether it must send a connection ID, probably encrypted, and >>>>>> nobody needs any flags, unless the presence of connection ID changes the >>>>>> offsets of fields we *do* want to explicitly expose, such as packet number >>>>>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>>>>> troubleshooting flags (https://github.com/quicwg/bas >>>>>> e-drafts/issues/279). >>>>>> > >>>>>> > Not to put too fine a point on it, but there's far from consensus >>>>>> that we want to expose >>>>>> > either of these. >>>>>> >>>>>> That's not too fine a point at all; I'm not presupposing consensus on >>>>>> either of these. All I'm saying here is, should consensus emerge that the >>>>>> benefits outweigh the costs (both in complexity and in risk) for certain >>>>>> kinds of exposure to the path -- which I think may be the case for some of >>>>>> the things under discussion in 279, and I'm obviously convinced of the >>>>>> utility of packet number echo as in 269 or I wouldn't have submitted two >>>>>> PRs on it -- we need to be clear that other choices we make about the >>>>>> layout of the header doesn't make that harder than it needs to be. Sticking >>>>>> variable-length/optional fields whose presence is dependent on >>>>>> endpoint-shared state after the exposed fields is probably sufficient for >>>>>> this. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a114d88ea1d0e4d054a509293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 10:28 AM, Ian Swett <ianswett@google.com&= gt; wrote:
On T= hu, Mar 9, 2017 at 1:17 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Mar 9, 2017 at 10:12 AM,= Ian Swett <ianswett@google.com> wrote:


On Thu, Mar 9, 2017 at 12:32 PM, Eric Rescorla <ekr@r= tfm.com> wrote:


O= n Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar <jri@google.com> = wrote:
A thoughts as I c= atch up on this thread (and in response to ekr's original question):
- As ekr points out, server-side middleboxes can always rel= y on connection IDs by policy. The value of the connection ID bit, in my mi= nd, is for middleboxes not controlled by the server. Such middleboxes are l= ikely to use the connection ID to identify connections where it exists. Wit= hout an explicit per-packet bit, a middlebox that wants to use connection I= D will have to dig into the handshake to determine where it's presence = negotiated. This leads to ossification of bits inside the cleartext handsha= ke messages, which is highly undesirable. I'd rather that the connectio= n ID bit be ossified.

Sure, but this starts from the position that middleboxes should b= e using connection
IDs. It's not clear to me that we want to = encourage that.


- As it stands, connection ID negot= iation means that each side tells the peer what it wants the peer to do. In= a world with (i) no connection ID bit and (ii) clients vetoing the server&= #39;s request, policy decisions are hard for load balancers. In this world,= there's no good way for server-side load balancers to know per connect= ion whether it has a connection ID or not: to find connection state, the lo= ad balancer needs a key, which would be the connection ID, which may or may= not be present for that connection. The load balancer could use the 4-tupl= e to key the connection, but that entirely defeats the point of using the c= onnection ID.

Hmm.= .. This seems rather more to be the result of letting the client veto. In t= he design
you propose, the server does:

= - If connection id bit is 1 look up connection ID
- Otherwise, lo= ok up the host/port


If you don'= t have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look f= or it
- If that's missing, drop the packet


- The privacy implications of sharing connection ID is= a separate conversation from the one this thread was started on. Though si= nce some points were raised here and since they speak to the question of wh= at information to share with middleboxes, I'll share my thoughts.=C2=A0=

We need to separate the use of connection ID use = across NAT rebindings vs the use of connection ID use across client network= changes.=C2=A0

We'd all probably agree that N= AT rebindings for UDP are a real concern, since NATs kill these bindings fa= ster than they do TCP bindings.

Actually, no, I'm not persuaded by this as yet. I agree w= ith the statement that NATs kill these bindings
faster, but it= 9;s not yet clear to me that connection IDs ameliorate these problems suffi= ciently to
improve the situation. I'd be happy to see any dat= a you have that supports this point.


This happens often, pa= rticularly after 1 minute, and connection ID makes it work seamlessly, so I= 'm pretty sure it works sufficiently well.=C2=A0 It is critical to long= er(ie: 5 minute) idle timeouts.=C2=A0
<= div>
I am aware of this argument, but I was looking fo= r something that looked a little more like
data :)

What data would you l= ike?=C2=A0 To my knowledge, it works 100% of the time where connection ID r= outing is implemented for our infrastructure, and we configure conservative= 30 second timeouts anywhere we can't rely on connection ID.

I'll think about how to p= hrase the question precisely and either send e-mail
or grab you i= n ORD.



=
We'd all agree that connection ID use= across client network changes is a new beast. To this end, I think we'= ve generally agreed (informally anyways) that the client must use a new con= nection ID when it triggers connection migration to a different network.

The difficulty is th= at we do not presently know how to arrange that you always use a new conn i= d
on migration without using a new conn id on each packet.
<= span>


In sum, my argument is that having connection IDs stable= across NAT rebindings is a necessity for QUIC to work well. As a result, m= iddleboxes at various points in the network, specifically those past a NAT,= are expected to use it to track connection state. Explicitly noting its pr= esence in the packet anticipates this and eliminates this one reason for os= sification of other bits deep in handshake messages needed otherwise for it= s inference.

I don= 't see you arguing that this is desirable so much as inevitable. So, if= we had a design that
was reasonably efficient that used a differ= ent connection ID per packet, then you would be
fine with that an= d wouldn't feel the need to tell middleboxes where it was?
<= /div>

I don't think having= the same connection ID used after a NAT rebind is a problem.

It actually is a small pr= oblem, because often many people are behind the same NAT.
=

It clearly links the post-reb= ind portion of the connection with the pre-rebind portion of the connection= , but I don't think it does anything else.=C2=A0 A TCP connection presu= mably wouldn't have rebound in a similar circumstance, so you could tri= vially connect the two parts of the connection.

I don't disagree with this statement. And = to which our target is no worse than TCP, then
mission accomplish= ed here. But it's still part of the threat model :)

-Ekr
=C2=A0

=
That being said, I'd be interested in seeing a design for a fully = encrypted header design if it was at all practical.
<= div>=C2=A0
But I agree that the prima= ry problem is network transitions.

=C2=A0 The attack of interest is linking one or more acti= ons in one network with one or more on another network.=C2=A0 If you're= on the client side of the NAT nothing changes, and if you're on the se= rver side you already know the set of ports(or ports and IPs) that a given = NAT uses publicly, so they're all equivalent from the observer's pe= rspective.=C2=A0 The NAT is a physical entity and there are some fairly tig= ht real-world constraints on where you end up during a rebind.
Is there a different threat model that I'm not aware of?
<= /div>

See above.
-Ekr
=C2=A0

-Ekr
=C2= =A0

- jana<= /div>


On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@tra= mmell.ch> wrote:
hi Ekr, = all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian







--001a114d88ea1d0e4d054a509293-- From nobody Thu Mar 9 10:44:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171CB1297A7 for ; Thu, 9 Mar 2017 10:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 h_DzUnK-W5a3 for ; Thu, 9 Mar 2017 10:44:35 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 CA17512979D for ; Thu, 9 Mar 2017 10:44:34 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id p77so11950067ywg.1 for ; Thu, 09 Mar 2017 10:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sKR+zjCmH4OZJT+pLZH8jMGGYAxXMfnNhdWjBUKN0Jw=; b=D3v4BeKGkh5KecOWYmgyqkEC55Fm9uKtcI9svyQnkwSR7AtXozmPK08iuqh/ML9il7 gdM2m4p+2FZSvyn1scaCdnhO3fXX0C61i2N7pV6LCjMazzF4hwK1GGyOqEGiuDnDjywL 4sQOX9UtzBHODEE3Abfq7e0Be5c5p92l5zKBTWD2HEMvOS/fbQFibor23yc5sC7cc7Au twDO5Rg/Odbxq/GVe0lGBeG3LfE7h2izu+Z/keatUPOXLTVjo/4W9NQ83QCRVVJTw/ku 57QaP3Qek6i0eGXALBw0fEa2iEOKoR88jsj0ZXVh9jkSnwFpGs42LJ7gPmHmkiKE4lKx xBOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sKR+zjCmH4OZJT+pLZH8jMGGYAxXMfnNhdWjBUKN0Jw=; b=gcbsRIpE+6NC2GGln9pioaslsoWosceJY1INqHMHnhAgL3SB4fgUuIw71dirsDoScy r9mtzOJrgpiHY46+vn226sB8PFG9AqK9miRXumhhOScoONsku0ey9mcMsNxlsj9tQIy6 QCO21kjefP7r1qqF72eD4GcMz20biv2o87ik1LnI6yLyYhEVLd8TSJLTW1uL48Wwxqpb F5kB3++Dt4BgyPlEre0Dj9kgqeWNSMXxA8ZmsXtYVXNFggZi6gXkI8SCKaTFiYl90bAn /zjNjtGjkYgN3wS4vC02ynVP1HGghF8M5oLZNeaz9Ixv3h3JOLWz+1KQblT1gqJ5BdzB sMzw== X-Gm-Message-State: AMke39ko/xmIa9+e7MT858zowm0NhhefwbUH1ub6+Id7J2G73l9LoAfXPLUpgv0Dg8FQ1BCKPN4meefKra/O1dtq X-Received: by 10.13.237.1 with SMTP id w1mr4871370ywe.7.1489085073460; Thu, 09 Mar 2017 10:44:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.65 with HTTP; Thu, 9 Mar 2017 10:44:32 -0800 (PST) In-Reply-To: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> From: Wenbo Zhu Date: Thu, 9 Mar 2017 10:44:32 -0800 Message-ID: Subject: Re: Divergence from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c0864a8d869ab054a50a2e6 Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:44:37 -0000 --94eb2c0864a8d869ab054a50a2e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The HTTP mapping draft states: "Connectivity problems (e.g. firewall blocking UDP) may result in QUIC connection establishment failure, in which case the client should gracefully fall back to HTTP/2" If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seems to me that QUIC should define its own TCP fallback (as "slow" and simple as it needs be) .. .or will doing so create yet again another protocol variant for what http mapping is concerned? ( p.s. sorry if this has already been discussed before ...) On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop wrote: > To me, it=E2=80=99s a *mostly* editorial difference =E2=80=93 do we try t= o contort the > IANA registry to claim these are two variants of the same protocol, or do > we just tell IANA they=E2=80=99re different protocols with different regi= stries? I > don=E2=80=99t see that one choice implies a larger scope than the other. = I think > the mission is still the same =E2=80=93 deliver HTTP semantics over QUIC. > > > > We=E2=80=99ve already decided we=E2=80=99re willing to make a number of d= epartures from > HTTP/2 because it makes technical sense in each individual case. > Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional > streams in each direction) the HTTP mapping would do likewise in response > (see branch unidirectional2). > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Thursday, March 9, 2017 6:28 AM > *To:* Stefan Eissing > *Cc:* Mike Bishop ; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > Thanks for sending this out to the list. I always hoped we could keep > HTTP over QUIC as similar to H2 as possible, but as you've pointed out > previously, a lot of HTTP/2 was adding transport features such as multipl= e > streams and flow control on top of an existing transport. Switching to > QPACK would be another dramatic departure. > > > > I'm not excited about QUIC abandoning HTTP2, but it may make enough > technical and documentation sense to be the right thing to do. I am > concerned this could expand the scope of the HTTP mapping too much, so if > we're going to make this choice, I'd like to know what types of changes a= re > in scope. > > > > On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing < > stefan.eissing@greenbytes.de> wrote: > > Thanks for separating this out, Mike. For spare time folks this makes > following this aspect easier. > > > > My first impression is that any hope to have http/2 over tcp and quic > needs to be abandoned. Which will give the world a third protocol to carr= y > http semantics. > > > > What does that mean for the evolution of http, I wonder. > > > > -stefan > > > Am 09.03.2017 um 03:16 schrieb Mike Bishop = : > > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are > the same protocol. However, the draft currently still attempts to define > them as close cousins. In PR #363 > , I=E2=80=99ve consolidat= ed > almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new= section and > excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC does= n=E2=80=99t need > it=E2=80=9D from the main body of the document. Martin has advocated mak= ing a > clean break from HTTP/2 and defining our own IANA registry for frame type= s > and settings, just as we already have for errors. We can, out of respect > for legacy, use the same values where appropriate and reserve existing > values currently in use on the HTTP/2 side. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from the WG about either would be welcome. > > > --94eb2c0864a8d869ab054a50a2e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The HTTP = mapping draft states:

&= quot;Connectivity problems (e.g. firewall = blocking UDP) may result in QUIC=C2=A0connection establishment f= ailure, in which case the client should=C2=A0gracefully fall back to HT= TP/2"

If QUIC and its HTTP mapping se= rve effectively as HTTP/3, then it seems to me that QUIC should define its = own TCP fallback (as "slow" and simple as it needs be) .. .or wil= l doing so create yet again another protocol variant for what http mapping = is concerned? =C2=A0 ( p.s. sorry=C2=A0if this has already been discuss= ed before ...)

On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop <M= ichael.Bishop@microsoft.com> wrote:

To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to contort the IANA = registry to claim these are two variants of the same protocol, or do we jus= t tell IANA they=E2=80=99re different protocols with different registries?= =C2=A0 I don=E2=80=99t see that one choice implies a larger scope than the other.=C2=A0 I think the mission is still the same =E2=80=93 deli= ver HTTP semantics over QUIC.

=C2=A0

We=E2=80=99ve already decided we=E2=80=99re willing= to make a number of departures from HTTP/2 because it makes technical sens= e in each individual case.=C2=A0 Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each direction) the HTTP ma= pping would do likewise in response (see branch unidirectional2).=

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org
Subject: Re: Divergence from HTTP/2

=C2=A0

Thanks for sending this out to the list.=C2=A0 I alw= ays hoped we could keep HTTP over QUIC as similar to H2 as possible, but as= you've pointed out previously, a lot of HTTP/2 was adding transport fe= atures such as multiple streams and flow control on top of an existing transport.=C2=A0 Switching to QPACK would be another= dramatic departure.

=C2=A0

I'm not excited about QUIC abandoning HTTP2, but= it may make enough technical and documentation sense to be the right thing= to do.=C2=A0 I am concerned this could expand the scope of the HTTP mappin= g too much, so if we're going to make this choice, I'd like to know what types of changes are in scope.=C2=A0<= /u>

=C2=A0

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <<= a href=3D"mailto:stefan.eissing@greenbytes.de" target=3D"_blank">stefan.eis= sing@greenbytes.de> wrote:

Thanks for separating this out, Mike. For spare time= folks this makes following this aspect easier.

=C2=A0

My first impression is that any hope to have http/2 = over tcp and quic needs to be abandoned. Which will give the world a third = protocol to carry http semantics.

=C2=A0

What does that mean for the evolution of http, I won= der.

=C2=A0

-stefan<= /span>


Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com><= wbr>:

At this point, I don=E2=80=99t think anyone expects = that HTTP/QUIC and HTTP/2 are the same protocol.=C2=A0 However, the draft c= urrently still attempts to define them as close cousins.=C2=A0 In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdiffere= nt from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff = about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D from the main body of the document.=C2=A0 Martin has advocated making a clean b= reak from HTTP/2 and defining our own IANA registry for frame types and set= tings, just as we already have for errors.=C2=A0 We can, out of respect for= legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.=

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from the WG about either would be welcome.<= u>

=C2=A0


--94eb2c0864a8d869ab054a50a2e6-- From nobody Thu Mar 9 10:53:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FFB1297D0 for ; Thu, 9 Mar 2017 10:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfsUWdpWvBES for ; Thu, 9 Mar 2017 10:53:34 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0136.outbound.protection.outlook.com [104.47.32.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5291297CB for ; Thu, 9 Mar 2017 10:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VjPvthNDuHZNxgr48S31mAR4hAm7LNB8Vpk7S2SG9Hg=; b=ovqFWlJiULtSCJ3RPDDeKmWj6rnkdn9HKh6qxjjA4VaxnPvq6vNUqe8hQHu9A3wB0+1sgoCw8jKeAyg1nLLTkW5kOa7sq4yCdAli72oaW22+hFbI+rZnpT3weWg8GzuMOhmoPeLKrjv1BeB8IUKsQpogcOapAB05OSFuoPypdjo= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 18:53:32 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 18:53:32 +0000 From: Mike Bishop To: "quic@ietf.org" , HTTP working group mailing list Subject: HTTP/QUIC Diverging from HTTP/2 Thread-Topic: HTTP/QUIC Diverging from HTTP/2 Thread-Index: AdKZAt9YNciLyZHpRWy2RhBs+G6fSw== Date: Thu, 9 Mar 2017 18:53:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::297] x-ms-office365-filtering-correlation-id: c049f22d-7141-4f70-d432-08d4671d9596 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:UR0kZDG6kvwPf3lfXm1TS9FYVYgNQ8SersOnTXPadMbw4uen+AKVHvMxEXH17Vx/ol3hQaCxSqw7eipxtQZonWAzjyzJVnjYTYZrd1GIqMDY2hwmiEEO3KG7fGjc0UzZJdUdtdk85TF+rAKLVugOjyupFI3juRQrD5yFtKwdQb1F49p2sIks/YQ03y/NocOSL0QXMF0jPIrUz5Dy1q7t0cvdXlIlZlX7sphSfAbsQTpzGmcOoODvL2gBP1rOjNQOrwE2zCPhK2anSX1urkbU3OIqRAN94sP2LcAOARH/eeCFjl2q10EP6P2JPdhQRjGVvHwTGNkM1XLPCjIjWSueCajWATY9684qmZOEHIBU1HA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(51444003)(2501003)(2900100001)(74316002)(5005710100001)(10290500002)(5660300001)(6306002)(86362001)(38730400002)(10090500001)(50986999)(2906002)(6506006)(6436002)(54356999)(122556002)(236005)(55016002)(8936002)(99286003)(8676002)(54896002)(33656002)(7906003)(53936002)(7696004)(790700001)(3280700002)(189998001)(77096006)(7736002)(25786008)(6116002)(102836003)(9686003)(3660700001)(606005)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270868CA114256023414AC9187210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 18:53:32.4922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:53:37 -0000 --_000_BN6PR03MB270868CA114256023414AC9187210BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At Patrick's suggestion, I'm restating this question and addressing it to b= oth the HTTP and QUIC working groups. Apologies if you're already followin= g along in QUIC and get this twice after having already seen it the first t= ime. HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session on = QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3. = A number of HTTP/2 frames weren't necessary, since they were duplicative o= f services QUIC provides. In draft -01, we removed the full mux layer from= Stream 3, instead letting QUIC deal with all the stream management. This = necessitated changes to several of the remaining frames. By the current ed= itor's copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several= frames of the same name and purpose exist. Likewise, RFC7540 defines six = settings, three of which are inapplicable in HTTP/QUIC. However, the draft currently still attempts to define them as close cousins= . It updates the HTTP/2 frame and setting registries with additional colum= ns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification if applicable) and= attempts to coexist with HTTP/2 in the same registry. (QUIC defines a uni= fied error space, which means a separate registry of error codes for HTTP/Q= UIC regardless.) In PR #363, I've consolidat= ed almost all of the "different from HTTP/2" text into a new top-level sect= ion and excised a lot of "HTTP/2 has this, but HTTP/QUIC doesn't need it" t= ext from the main body of the document. Martin has advocated making a clea= n break from HTTP/2 and defining our own IANA registry for frame types and = settings, just as we already have for errors. We can, out of respect for o= ur cousin, use the same values where appropriate and reserve existing value= s currently in use on the HTTP/2 side. I think that's a good idea, and it's a fairly small step from the current s= tate of #363. I've created PR #376 to actually make that split. Comments from both WGs about the two PRs would be welcome. (Feedback so fa= r from the QUIC side seems to mostly be "separate with regrets," but not un= iversally.) --_000_BN6PR03MB270868CA114256023414AC9187210BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At Patrick’s suggestion, I’m restating t= his question and addressing it to both the HTTP and QUIC working groups.&nb= sp; Apologies if you’re already following along in QUIC and get this = twice after having already seen it the first time.

 

HTTP/QUIC started off (draft -00) with a mostly-comp= lete HTTP/2 session on QUIC Stream 3, including a full HTTP/2 multiplexing = layer within Stream 3.  A number of HTTP/2 frames weren’t necess= ary, since they were duplicative of services QUIC provides.  In draft -01, we removed the full mux layer from Stre= am 3, instead letting QUIC deal with all the stream management.  This = necessitated changes to several of the remaining frames.  By the curre= nt editor’s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frame= s of the same name and purpose exist.  Likewise, RFC7540 defines six s= ettings, three of which are inapplicable in HTTP/QUIC.

 

However, the draft currently still attempts to defin= e them as close cousins.  It updates the HTTP/2 frame and setting regi= stries with additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Spec= ification if applicable) and attempts to coexist with HTTP/2 in the same registry.  (QUIC defines a unified er= ror space, which means a separate registry of error codes for HTTP/QUIC reg= ardless.)

 

In PR #363, I’ve consolidated almost all of the “different fro= m HTTP/2” text into a new top-level section and excised a lot of R= 20;HTTP/2 has this, but HTTP/QUIC doesn’t need it” text from th= e main body of the document.  Martin has advocated making a clean brea= k from HTTP/2 and defining our own IANA registry for frame types and setting= s, just as we already have for errors.  We can, out of respect for our= cousin, use the same values where appropriate and reserve existing values = currently in use on the HTTP/2 side.

 

I think that’s a good idea, and it’s a f= airly small step from the current state of #363.  I’ve created PR #376 to a= ctually make that split.

 

Comments from both WGs about the two PRs would be we= lcome.  (Feedback so far from the QUIC side seems to mostly be “= separate with regrets,” but not universally.)

--_000_BN6PR03MB270868CA114256023414AC9187210BN6PR03MB2708namp_-- From nobody Thu Mar 9 10:54:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2991297D0 for ; Thu, 9 Mar 2017 10:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1yBCb-Ho_RT for ; Thu, 9 Mar 2017 10:54:34 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0127.outbound.protection.outlook.com [104.47.32.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 D8B141297CB for ; Thu, 9 Mar 2017 10:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XWONL60WIgHznZKOC+/WTwEcySaWESaweVM27RXGtlY=; b=erRZopkPoNoTyFBbpJImcEPP/obN/tMsqSfrkx/Ae0WcjN5MJpoTkwNwdA37NSNsaXgFxEK9A/CohscX59p2sFAbNFhu6S9qlzZL/fwDrUk86oxiDBVRoRAsG8Z4Vq7sqfiC5zZJnVGVMAEIemTsebyQnAwDAakLod/YBgzb36E= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 18:54:32 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 18:54:31 +0000 From: Mike Bishop To: Wenbo Zhu Subject: RE: Divergence from HTTP/2 Thread-Topic: Divergence from HTTP/2 Thread-Index: AdKYd70rURZiuYADRA293Bil8tNr6AAPNMmAAAs0oAAAAu01AAAGBksAAABQmLA= Date: Thu, 9 Mar 2017 18:54:31 +0000 Message-ID: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::297] x-ms-office365-filtering-correlation-id: 3a36db70-cae2-44b0-8ced-08d4671db8e1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:Kep2rZXbACOeZleVwoxWDvRmZqaO/X640n7SS8Zt6dWhbRERMqUfnyoddjfs745Qh0sAcoGecmDu8LQjydHOjB+32Ho74gwNtt+3M2o31mKURf6f6m7gQxad/f2nBMhepEuYeIiL9vTr12qEqLC0IavW5tO9Abge5/kKJRrPCsjuT33HKLprunHCirl3RnwQ7t5yJcy0sDZbKy89rZO7it0cnt5+hvKstjfI+tZccj9zn3D2B3FKwR+scNs5JOoumOBhIqgU5wNQIZqc6gf7HcNnXIKChHx5KYb69gxMvJoREjV8yKf59o66E1lMwCNYDMZK+KPv1ZFbkHVKJTX9B+HM2xUV4VoW1bANej7M3mY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(24454002)(377454003)(51444003)(2900100001)(53546006)(74316002)(4326008)(5005710100001)(10290500002)(5660300001)(6306002)(93886004)(19609705001)(6916009)(86362001)(2950100002)(110136004)(38730400002)(6246003)(10090500001)(8990500004)(50986999)(2906002)(6506006)(6436002)(54356999)(122556002)(76176999)(236005)(55016002)(8936002)(99286003)(86612001)(8676002)(54906002)(54896002)(33656002)(7906003)(53936002)(7696004)(790700001)(229853002)(3280700002)(189998001)(77096006)(7736002)(25786008)(6116002)(102836003)(9686003)(3660700001)(606005)(81166006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27081E15AD581B5C3711CFDB87210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 18:54:31.7396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 18:54:37 -0000 --_000_BN6PR03MB27081E15AD581B5C3711CFDB87210BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCwgc2luY2Ugd2XigJlyZSB0YWxraW5nIGFib3V0IGZhaWxpbmcgdG8gY29ubmVjdCB0byBh biBhbHRlcm5hdGl2ZSwgd2UgY291bGQganVzdCBzYXkgdGhhdCB0aGUgY2xpZW50IHNob3VsZCBm YWxsIGJhY2sgdG8gdGhlIG9yaWdpbiBvciBhIGRpZmZlcmVudCBhbHRlcm5hdGl2ZSwgcGVyIFJG Qzc4MzguICBUaGF0IHJlbW92ZXMgYW55IG1lbnRpb24gb2YgYSBwYXJ0aWN1bGFyIHRyYW5zcG9y dCBvciBhIHBhcnRpY3VsYXIgSFRUUCB2ZXJzaW9uLg0KDQpGcm9tOiBXZW5ibyBaaHUgW21haWx0 bzp3ZW5ib3pAZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDEwOjQ1 IEFNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzog SWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgU3RlZmFuIEVpc3NpbmcgPHN0ZWZhbi5l aXNzaW5nQGdyZWVuYnl0ZXMuZGU+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogRGl2ZXJn ZW5jZSBmcm9tIEhUVFAvMg0KDQpUaGUgSFRUUCBtYXBwaW5nIGRyYWZ0IHN0YXRlczoNCg0KIkNv bm5lY3Rpdml0eSBwcm9ibGVtcyAoZS5nLiBmaXJld2FsbCBibG9ja2luZyBVRFApIG1heSByZXN1 bHQgaW4gUVVJQyBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZmFpbHVyZSwgaW4gd2hpY2ggY2Fz ZSB0aGUgY2xpZW50IHNob3VsZCBncmFjZWZ1bGx5IGZhbGwgYmFjayB0byBIVFRQLzIiDQoNCklm IFFVSUMgYW5kIGl0cyBIVFRQIG1hcHBpbmcgc2VydmUgZWZmZWN0aXZlbHkgYXMgSFRUUC8zLCB0 aGVuIGl0IHNlZW1zIHRvIG1lIHRoYXQgUVVJQyBzaG91bGQgZGVmaW5lIGl0cyBvd24gVENQIGZh bGxiYWNrIChhcyAic2xvdyIgYW5kIHNpbXBsZSBhcyBpdCBuZWVkcyBiZSkgLi4gLm9yIHdpbGwg ZG9pbmcgc28gY3JlYXRlIHlldCBhZ2FpbiBhbm90aGVyIHByb3RvY29sIHZhcmlhbnQgZm9yIHdo YXQgaHR0cCBtYXBwaW5nIGlzIGNvbmNlcm5lZD8gICAoIHAucy4gc29ycnkgaWYgdGhpcyBoYXMg YWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBiZWZvcmUgLi4uKQ0KDQpPbiBUaHUsIE1hciA5LCAyMDE3 IGF0IDc6NTkgQU0sIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUbyBtZSwgaXTigJlz IGEgbW9zdGx5IGVkaXRvcmlhbCBkaWZmZXJlbmNlIOKAkyBkbyB3ZSB0cnkgdG8gY29udG9ydCB0 aGUgSUFOQSByZWdpc3RyeSB0byBjbGFpbSB0aGVzZSBhcmUgdHdvIHZhcmlhbnRzIG9mIHRoZSBz YW1lIHByb3RvY29sLCBvciBkbyB3ZSBqdXN0IHRlbGwgSUFOQSB0aGV54oCZcmUgZGlmZmVyZW50 IHByb3RvY29scyB3aXRoIGRpZmZlcmVudCByZWdpc3RyaWVzPyAgSSBkb27igJl0IHNlZSB0aGF0 IG9uZSBjaG9pY2UgaW1wbGllcyBhIGxhcmdlciBzY29wZSB0aGFuIHRoZSBvdGhlci4gIEkgdGhp bmsgdGhlIG1pc3Npb24gaXMgc3RpbGwgdGhlIHNhbWUg4oCTIGRlbGl2ZXIgSFRUUCBzZW1hbnRp Y3Mgb3ZlciBRVUlDLg0KDQpXZeKAmXZlIGFscmVhZHkgZGVjaWRlZCB3ZeKAmXJlIHdpbGxpbmcg dG8gbWFrZSBhIG51bWJlciBvZiBkZXBhcnR1cmVzIGZyb20gSFRUUC8yIGJlY2F1c2UgaXQgbWFr ZXMgdGVjaG5pY2FsIHNlbnNlIGluIGVhY2ggaW5kaXZpZHVhbCBjYXNlLiAgT2J2aW91c2x5LCBp ZiBRVUlDIHRha2VzIGEgZHJhbWF0aWMgdHVybiAoZS5nLiB1bnJlbGF0ZWQgdW5pZGlyZWN0aW9u YWwgc3RyZWFtcyBpbiBlYWNoIGRpcmVjdGlvbikgdGhlIEhUVFAgbWFwcGluZyB3b3VsZCBkbyBs aWtld2lzZSBpbiByZXNwb25zZSAoc2VlIGJyYW5jaCB1bmlkaXJlY3Rpb25hbDIpLg0KDQpGcm9t OiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBn b29nbGUuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDY6MjggQU0NClRvOiBT dGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTxtYWlsdG86c3RlZmFu LmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PjsgcXVp Y0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBEaXZlcmdlbmNl IGZyb20gSFRUUC8yDQoNClRoYW5rcyBmb3Igc2VuZGluZyB0aGlzIG91dCB0byB0aGUgbGlzdC4g IEkgYWx3YXlzIGhvcGVkIHdlIGNvdWxkIGtlZXAgSFRUUCBvdmVyIFFVSUMgYXMgc2ltaWxhciB0 byBIMiBhcyBwb3NzaWJsZSwgYnV0IGFzIHlvdSd2ZSBwb2ludGVkIG91dCBwcmV2aW91c2x5LCBh IGxvdCBvZiBIVFRQLzIgd2FzIGFkZGluZyB0cmFuc3BvcnQgZmVhdHVyZXMgc3VjaCBhcyBtdWx0 aXBsZSBzdHJlYW1zIGFuZCBmbG93IGNvbnRyb2wgb24gdG9wIG9mIGFuIGV4aXN0aW5nIHRyYW5z cG9ydC4gIFN3aXRjaGluZyB0byBRUEFDSyB3b3VsZCBiZSBhbm90aGVyIGRyYW1hdGljIGRlcGFy dHVyZS4NCg0KSSdtIG5vdCBleGNpdGVkIGFib3V0IFFVSUMgYWJhbmRvbmluZyBIVFRQMiwgYnV0 IGl0IG1heSBtYWtlIGVub3VnaCB0ZWNobmljYWwgYW5kIGRvY3VtZW50YXRpb24gc2Vuc2UgdG8g YmUgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLiAgSSBhbSBjb25jZXJuZWQgdGhpcyBjb3VsZCBleHBh bmQgdGhlIHNjb3BlIG9mIHRoZSBIVFRQIG1hcHBpbmcgdG9vIG11Y2gsIHNvIGlmIHdlJ3JlIGdv aW5nIHRvIG1ha2UgdGhpcyBjaG9pY2UsIEknZCBsaWtlIHRvIGtub3cgd2hhdCB0eXBlcyBvZiBj aGFuZ2VzIGFyZSBpbiBzY29wZS4NCg0KT24gVGh1LCBNYXIgOSwgMjAxNyBhdCA0OjA3IEFNLCBT dGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTxtYWlsdG86c3RlZmFu LmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4+IHdyb3RlOg0KVGhhbmtzIGZvciBzZXBhcmF0aW5nIHRo aXMgb3V0LCBNaWtlLiBGb3Igc3BhcmUgdGltZSBmb2xrcyB0aGlzIG1ha2VzIGZvbGxvd2luZyB0 aGlzIGFzcGVjdCBlYXNpZXIuDQoNCk15IGZpcnN0IGltcHJlc3Npb24gaXMgdGhhdCBhbnkgaG9w ZSB0byBoYXZlIGh0dHAvMiBvdmVyIHRjcCBhbmQgcXVpYyBuZWVkcyB0byBiZSBhYmFuZG9uZWQu IFdoaWNoIHdpbGwgZ2l2ZSB0aGUgd29ybGQgYSB0aGlyZCBwcm90b2NvbCB0byBjYXJyeSBodHRw IHNlbWFudGljcy4NCg0KV2hhdCBkb2VzIHRoYXQgbWVhbiBmb3IgdGhlIGV2b2x1dGlvbiBvZiBo dHRwLCBJIHdvbmRlci4NCg0KLXN0ZWZhbg0KDQpBbSAwOS4wMy4yMDE3IHVtIDAzOjE2IHNjaHJp ZWIgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PjoNCkF0IHRoaXMgcG9pbnQsIEkgZG9u4oCZdCB0aGlu ayBhbnlvbmUgZXhwZWN0cyB0aGF0IEhUVFAvUVVJQyBhbmQgSFRUUC8yIGFyZSB0aGUgc2FtZSBw cm90b2NvbC4gIEhvd2V2ZXIsIHRoZSBkcmFmdCBjdXJyZW50bHkgc3RpbGwgYXR0ZW1wdHMgdG8g ZGVmaW5lIHRoZW0gYXMgY2xvc2UgY291c2lucy4gIEluIFBSICMzNjM8aHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM2Mz4sIEnigJl2ZSBjb25zb2xpZGF0ZWQgYWxt b3N0IGFsbCBvZiB0aGUg4oCcZGlmZmVyZW50IGZyb20gSFRUUC8y4oCdIHRleHQgaW50byBhIG5l dyBzZWN0aW9uIGFuZCBleGNpc2VkIGEgbG90IG9mIHN0dWZmIGFib3V0IOKAnEhUVFAvMiBoYXMg dGhpcywgYnV0IEhUVFAvUVVJQyBkb2VzbuKAmXQgbmVlZCBpdOKAnSBmcm9tIHRoZSBtYWluIGJv ZHkgb2YgdGhlIGRvY3VtZW50LiAgTWFydGluIGhhcyBhZHZvY2F0ZWQgbWFraW5nIGEgY2xlYW4g YnJlYWsgZnJvbSBIVFRQLzIgYW5kIGRlZmluaW5nIG91ciBvd24gSUFOQSByZWdpc3RyeSBmb3Ig ZnJhbWUgdHlwZXMgYW5kIHNldHRpbmdzLCBqdXN0IGFzIHdlIGFscmVhZHkgaGF2ZSBmb3IgZXJy b3JzLiAgV2UgY2FuLCBvdXQgb2YgcmVzcGVjdCBmb3IgbGVnYWN5LCB1c2UgdGhlIHNhbWUgdmFs dWVzIHdoZXJlIGFwcHJvcHJpYXRlIGFuZCByZXNlcnZlIGV4aXN0aW5nIHZhbHVlcyBjdXJyZW50 bHkgaW4gdXNlIG9uIHRoZSBIVFRQLzIgc2lkZS4NCg0KSSB0aGluayB0aGF04oCZcyBhIGdvb2Qg aWRlYSwgYW5kIGl04oCZcyBhIGZhaXJseSBzbWFsbCBzdGVwIGZyb20gdGhlIGN1cnJlbnQgc3Rh dGUgb2YgIzM2My4gIEnigJl2ZSBjcmVhdGVkIFBSICMzNzY8aHR0cHM6Ly9naXRodWIuY29tL3F1 aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM3Nj4gdG8gYWN0dWFsbHkgbWFrZSB0aGF0IHNwbGl0Lg0K DQpDb21tZW50cyBmcm9tIHRoZSBXRyBhYm91dCBlaXRoZXIgd291bGQgYmUgd2VsY29tZS4NCg0K DQo= --_000_BN6PR03MB27081E15AD581B5C3711CFDB87210BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZWxsLCBzaW5jZSB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQgZmFpbGluZyB0byBjb25uZWN0IHRvIGFu IGFsdGVybmF0aXZlLCB3ZSBjb3VsZCBqdXN0IHNheSB0aGF0IHRoZSBjbGllbnQgc2hvdWxkIGZh bGwgYmFjayB0byB0aGUgb3JpZ2luIG9yIGEgZGlmZmVyZW50IGFsdGVybmF0aXZlLCBwZXIgUkZD NzgzOC4mbmJzcDsgVGhhdCByZW1vdmVzIGFueSBtZW50aW9uIG9mIGEgcGFydGljdWxhciB0cmFu c3BvcnQgb3IgYSBwYXJ0aWN1bGFyDQogSFRUUCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gV2VuYm8gWmh1IFttYWlsdG86d2VuYm96QGdvb2dsZS5jb21dIDxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyAxMDo0NSBBTTxicj4NCjxi PlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBT dGVmYW4gRWlzc2luZyAmbHQ7c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSZndDs7IHF1aWNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IERpdmVyZ2VuY2UgZnJvbSBIVFRQLzI8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIEhUVFAgbWFwcGluZyBkcmFm dCBzdGF0ZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+JnF1b3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Db25uZWN0aXZpdHkg cHJvYmxlbXMgKGUuZy4gZmlyZXdhbGwgYmxvY2tpbmcgVURQKSBtYXkgcmVzdWx0IGluIFFVSUMm bmJzcDtjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZmFpbHVyZSwgaW4gd2hpY2ggY2FzZSB0aGUg Y2xpZW50IHNob3VsZCZuYnNwO2dyYWNlZnVsbHkgZmFsbCBiYWNrIHRvIEhUVFAvMiZxdW90Ozwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5JZiBRVUlDIGFuZCBpdHMgSFRUUCBtYXBwaW5nIHNlcnZlIGVm ZmVjdGl2ZWx5IGFzIEhUVFAvMywgdGhlbiBpdCBzZWVtcyB0byBtZSB0aGF0IFFVSUMgc2hvdWxk IGRlZmluZSBpdHMgb3duIFRDUCBmYWxsYmFjayAoYXMgJnF1b3Q7c2xvdyZxdW90OyBhbmQgc2lt cGxlIGFzIGl0IG5lZWRzIGJlKSAuLiAub3Igd2lsbCBkb2luZw0KIHNvIGNyZWF0ZSB5ZXQgYWdh aW4gYW5vdGhlciBwcm90b2NvbCB2YXJpYW50IGZvciB3aGF0IGh0dHAgbWFwcGluZyBpcyBjb25j ZXJuZWQ/ICZuYnNwOyAoIHAucy4gc29ycnkmbmJzcDtpZiB0aGlzIGhhcyBhbHJlYWR5IGJlZW4g ZGlzY3Vzc2VkIGJlZm9yZSAuLi4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciA5LCAyMDE3IGF0IDc6NTkgQU0s IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VG8gbWUsIGl04oCZcyBhDQo8aT5tb3N0bHk8L2k+IGVkaXRvcmlh bCBkaWZmZXJlbmNlIOKAkyBkbyB3ZSB0cnkgdG8gY29udG9ydCB0aGUgSUFOQSByZWdpc3RyeSB0 byBjbGFpbSB0aGVzZSBhcmUgdHdvIHZhcmlhbnRzIG9mIHRoZSBzYW1lIHByb3RvY29sLCBvciBk byB3ZSBqdXN0IHRlbGwgSUFOQSB0aGV54oCZcmUgZGlmZmVyZW50IHByb3RvY29scyB3aXRoIGRp ZmZlcmVudCByZWdpc3RyaWVzPyZuYnNwOyBJIGRvbuKAmXQgc2VlIHRoYXQgb25lIGNob2ljZSBp bXBsaWVzIGEgbGFyZ2VyIHNjb3BlDQogdGhhbiB0aGUgb3RoZXIuJm5ic3A7IEkgdGhpbmsgdGhl IG1pc3Npb24gaXMgc3RpbGwgdGhlIHNhbWUg4oCTIGRlbGl2ZXIgSFRUUCBzZW1hbnRpY3Mgb3Zl ciBRVUlDLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2XigJl2ZSBhbHJlYWR5IGRlY2lk ZWQgd2XigJlyZSB3aWxsaW5nIHRvIG1ha2UgYSBudW1iZXIgb2YgZGVwYXJ0dXJlcyBmcm9tIEhU VFAvMiBiZWNhdXNlIGl0IG1ha2VzIHRlY2huaWNhbCBzZW5zZSBpbiBlYWNoIGluZGl2aWR1YWwg Y2FzZS4mbmJzcDsgT2J2aW91c2x5LCBpZiBRVUlDIHRha2VzIGEgZHJhbWF0aWMgdHVybg0KIChl LmcuIHVucmVsYXRlZCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGluIGVhY2ggZGlyZWN0aW9uKSB0 aGUgSFRUUCBtYXBwaW5nIHdvdWxkIGRvIGxpa2V3aXNlIGluIHJlc3BvbnNlIChzZWUgYnJhbmNo IHVuaWRpcmVjdGlvbmFsMikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwv Yj4gSWFuIFN3ZXR0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyA2OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBTdGVm YW4gRWlzc2luZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMu ZGUiIHRhcmdldD0iX2JsYW5rIj5zdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5C aXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IERpdmVy Z2VuY2UgZnJvbSBIVFRQLzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFu a3MgZm9yIHNlbmRpbmcgdGhpcyBvdXQgdG8gdGhlIGxpc3QuJm5ic3A7IEkgYWx3YXlzIGhvcGVk IHdlIGNvdWxkIGtlZXAgSFRUUCBvdmVyIFFVSUMgYXMgc2ltaWxhciB0byBIMiBhcyBwb3NzaWJs ZSwgYnV0IGFzIHlvdSd2ZSBwb2ludGVkIG91dCBwcmV2aW91c2x5LCBhIGxvdCBvZiBIVFRQLzIg d2FzIGFkZGluZw0KIHRyYW5zcG9ydCBmZWF0dXJlcyBzdWNoIGFzIG11bHRpcGxlIHN0cmVhbXMg YW5kIGZsb3cgY29udHJvbCBvbiB0b3Agb2YgYW4gZXhpc3RpbmcgdHJhbnNwb3J0LiZuYnNwOyBT d2l0Y2hpbmcgdG8gUVBBQ0sgd291bGQgYmUgYW5vdGhlciBkcmFtYXRpYyBkZXBhcnR1cmUuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JJ20gbm90IGV4Y2l0ZWQgYWJvdXQgUVVJQyBhYmFuZG9uaW5nIEhUVFAyLCBidXQgaXQg bWF5IG1ha2UgZW5vdWdoIHRlY2huaWNhbCBhbmQgZG9jdW1lbnRhdGlvbiBzZW5zZSB0byBiZSB0 aGUgcmlnaHQgdGhpbmcgdG8gZG8uJm5ic3A7IEkgYW0gY29uY2VybmVkIHRoaXMgY291bGQgZXhw YW5kIHRoZSBzY29wZSBvZg0KIHRoZSBIVFRQIG1hcHBpbmcgdG9vIG11Y2gsIHNvIGlmIHdlJ3Jl IGdvaW5nIHRvIG1ha2UgdGhpcyBjaG9pY2UsIEknZCBsaWtlIHRvIGtub3cgd2hhdCB0eXBlcyBv ZiBjaGFuZ2VzIGFyZSBpbiBzY29wZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFRodSwgTWFyIDksIDIwMTcgYXQgNDowNyBBTSwgU3RlZmFuIEVpc3NpbmcgJmx0Ozxh IGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlIiB0YXJnZXQ9Il9ibGFu ayI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciBzZXBhcmF0aW5n IHRoaXMgb3V0LCBNaWtlLiBGb3Igc3BhcmUgdGltZSBmb2xrcyB0aGlzIG1ha2VzIGZvbGxvd2lu ZyB0aGlzIGFzcGVjdCBlYXNpZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBmaXJzdCBpbXByZXNzaW9uIGlzIHRoYXQgYW55IGhv cGUgdG8gaGF2ZSBodHRwLzIgb3ZlciB0Y3AgYW5kIHF1aWMgbmVlZHMgdG8gYmUgYWJhbmRvbmVk LiBXaGljaCB3aWxsIGdpdmUgdGhlIHdvcmxkIGEgdGhpcmQgcHJvdG9jb2wgdG8gY2FycnkgaHR0 cCBzZW1hbnRpY3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5XaGF0IGRvZXMgdGhhdCBtZWFuIGZvciB0aGUgZXZvbHV0aW9uIG9mIGh0 dHAsIEkgd29uZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+LXN0ZWZhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpBbSAwOS4wMy4y MDE3IHVtIDAzOjE2IHNjaHJpZWIgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCB0aGlzIHBvaW50LCBJIGRvbuKAmXQgdGhp bmsgYW55b25lIGV4cGVjdHMgdGhhdCBIVFRQL1FVSUMgYW5kIEhUVFAvMiBhcmUgdGhlIHNhbWUg cHJvdG9jb2wuJm5ic3A7IEhvd2V2ZXIsIHRoZSBkcmFmdCBjdXJyZW50bHkgc3RpbGwgYXR0ZW1w dHMgdG8gZGVmaW5lIHRoZW0gYXMgY2xvc2UgY291c2lucy4mbmJzcDsgSW4NCjxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNjMiIHRhcmdldD0iX2Js YW5rIj5QUiAjMzYzPC9hPiwgSeKAmXZlIGNvbnNvbGlkYXRlZCBhbG1vc3QgYWxsIG9mIHRoZSDi gJxkaWZmZXJlbnQgZnJvbSBIVFRQLzLigJ0gdGV4dCBpbnRvIGEgbmV3IHNlY3Rpb24gYW5kIGV4 Y2lzZWQgYSBsb3Qgb2Ygc3R1ZmYgYWJvdXQg4oCcSFRUUC8yIGhhcyB0aGlzLCBidXQgSFRUUC9R VUlDIGRvZXNu4oCZdCBuZWVkIGl04oCdIGZyb20NCiB0aGUgbWFpbiBib2R5IG9mIHRoZSBkb2N1 bWVudC4mbmJzcDsgTWFydGluIGhhcyBhZHZvY2F0ZWQgbWFraW5nIGEgY2xlYW4gYnJlYWsgZnJv bSBIVFRQLzIgYW5kIGRlZmluaW5nIG91ciBvd24gSUFOQSByZWdpc3RyeSBmb3IgZnJhbWUgdHlw ZXMgYW5kIHNldHRpbmdzLCBqdXN0IGFzIHdlIGFscmVhZHkgaGF2ZSBmb3IgZXJyb3JzLiZuYnNw OyBXZSBjYW4sIG91dCBvZiByZXNwZWN0IGZvciBsZWdhY3ksIHVzZSB0aGUgc2FtZSB2YWx1ZXMg d2hlcmUgYXBwcm9wcmlhdGUNCiBhbmQgcmVzZXJ2ZSBleGlzdGluZyB2YWx1ZXMgY3VycmVudGx5 IGluIHVzZSBvbiB0aGUgSFRUUC8yIHNpZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J IHRoaW5rIHRoYXTigJlzIGEgZ29vZCBpZGVhLCBhbmQgaXTigJlzIGEgZmFpcmx5IHNtYWxsIHN0 ZXAgZnJvbSB0aGUgY3VycmVudCBzdGF0ZSBvZiAjMzYzLiZuYnNwOyBJ4oCZdmUgY3JlYXRlZA0K PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM3NiIg dGFyZ2V0PSJfYmxhbmsiPlBSICMzNzY8L2E+IHRvIGFjdHVhbGx5IG1ha2UgdGhhdCBzcGxpdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbW1lbnRzIGZyb20gdGhlIFdHIGFib3V0IGVp dGhlciB3b3VsZCBiZSB3ZWxjb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB27081E15AD581B5C3711CFDB87210BN6PR03MB2708namp_-- From nobody Thu Mar 9 11:03:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C027E1297F7 for ; Thu, 9 Mar 2017 11:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 E-fTxHQ5H9gH for ; Thu, 9 Mar 2017 11:03:08 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2D31294DC for ; Thu, 9 Mar 2017 11:03:08 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id o4so12173538ywd.3 for ; Thu, 09 Mar 2017 11:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tZmQHeoB9LvQjBk/98sqH9FZqWeif3xr0XRvcChAkZw=; b=YpnceKFDn3V8sAlZvi9plzUZZNGO3Cq+tBrj6xFHOBRXehm5fduFSwQGmEe1YE3mEU JPAuwE/F8PcvLv0Ub35gjIb+1WwujLNkTgT+o3VY4fRIund/mkmhGWW970+g21rEB5AN WfoKJs6r2hlLLdyTkngWGHHwiTvF4CDsaVrC+2dsRMwm4rpfSXxfh+D+4prtgOYZHo8V xo0heeY//vvmOx20J0Hu/zBOc03UkyHMYS8HcQ35XNX6djUKhQeT+HwPB+f9/DTcZ7yH Fx8k4Pta71BwvGEbe6s3KOB01UDul9Iwpj4o6gK1kWv/CRNAsCMKGSNL1at4foeXLazJ 6OQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tZmQHeoB9LvQjBk/98sqH9FZqWeif3xr0XRvcChAkZw=; b=PoTPAXkcDaT8Hu1ox51qv1+t4ukMUdwnxbCgou4oH/fjtdLtWVi9hOuCqH3u36jDe7 wO/doGvgSAT7InN80MqGbsiF5aJL16X2alD8boGi+ylQGgLfYNy+7ZDwcFmyHEych5KI urjsO2IfGxyo1FNwCZLjUgoEAx+j6okXi7WnxO0ag1YQYMn5D6jpzy/l4rdgy9tvtxPK oZNFK2gYWEKCS1aAqA1DpnxETdwzxhioLXrpw9UiedNDYbZsQu9AWR2dLSkOdD1IUrG8 7k+a0tIiz3YmWINH+ZgRe5eLCNDemeFx2AS82GIuxvFuL9S/toBtVcAhKVg0tXm5yRNC 0VTA== X-Gm-Message-State: AMke39mbFZlJgXg6ZOIywYgO8C2vgsdvJ5Uj4Hwm5uTBoEdorS3OQ71pv7Mdq5Vdy6OLFUcGeXowk1o0LnJv2g== X-Received: by 10.129.163.214 with SMTP id a205mr4871163ywh.285.1489086187820; Thu, 09 Mar 2017 11:03:07 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Thu, 9 Mar 2017 11:03:07 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Thu, 9 Mar 2017 14:03:07 -0500 X-Google-Sender-Auth: jwmrKfN7DRqglmHdH9mGct4Rp38 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c12849043dd33054a50e593 Archived-At: Cc: "Brian Trammell \(IETF\)" , Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:03:10 -0000 --94eb2c12849043dd33054a50e593 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 11:58 AM, Kyle Rose wrote: > On Thu, Mar 9, 2017 at 10:08 AM, Eric Rescorla wrote: > >> That too-tightly constrains load balancing. Without connection tracking >>> (which means shared state across multiple machines in a farm of load >>> balancers) or a server-chosen cookie, you're limited to algorithms that= are >>> a function of connection ID and 5-tuple. In particular, you can't choos= e a >>> target server based on its current load. Random assignment may be good >>> enough for some application profiles, but not all. >>> >> >> Well, that may be true, but I'm merely observing that that's the present >> design of gQUIC. >> > > Understood. I just didn't want the gQUIC approach to be considered > universally applicable on the basis of that statement. > > I'd still rather find a way to separate minimal load balancer state from > session state, and to protect the latter, but I'm not sure if there's a w= ay > to do it that provides real value (i.e., isn't just advisory). > > Kyle > =E2=80=8BSo I just had an idea that maybe is relevant and maybe is not. Bui= lt into QUIC is the idea that it is a conversation between one machine at the client (initiator) end and one machine at the server (responder) end. Is that real? Lets say that Alice is surfin' the Web and goes to a page that has streaming media, static content and such all from the same service but being served up via different physical machines. What happens today is that we either demultiplex the streams in the HTML by giving them all URIs to be resolved separately or we have a Tier 1 system on the service end that is acting as a front end to all those tier 2 resources. Both approaches have consequences. In the first case we end up with two machines in the same data center, often the same rack communicating through HTTP cookies bouncing off the client. Not just technically bad but needless EU tracking cookie complications. In the second, we have to have pipe huge amounts of data across our machine room when it could just be shipped directly out the door. What if we could change the model here? Instead of thinking of QUIC as being a Transport layer being implemented as an application layer kludge, maybe we are developing something a little bit higher level (presentation ?). Assume we have some internal protocol to hand off handling of a stream to a different host. We could do some interesting stuff. I would like to get rid of content IDs, stream IDs, everything. Every stream that is created is assigned a opaque unique identifier by the party that is going to receive the packets. The allowed length is long enough to allow whatever state needs to be packed therein. Standards are all about making decisions that don't matter while not making decisions that matter a lot to other people. =E2=80=8B --94eb2c12849043dd33054a50e593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 9, 2017 at 11:58 AM, Kyle Rose <krose@krose.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">On Thu, Mar 9, 2017 at 10:08 AM,= Eric Rescorla <ekr@rtfm.com> wrote:
T= hat too-tightly constrains load balancing. Without connection tracking (whi= ch means shared state across multiple machines in a farm of load balancers)= or a server-chosen cookie, you're limited to algorithms that are a fun= ction of connection ID and 5-tuple. In particular, you can't choose a t= arget server based on its current load. Random assignment may be good enoug= h for some application profiles, but not all.

<= div>Well, that may be true, but I'm merely observing that that's th= e present design of gQUIC.=C2=A0
<= br>
Understood. I just didn't want the gQUIC approach = to be considered universally applicable on the basis of that statement.
=
I'd still rather find a way to separate minimal load balancer state= from session state, and to protect the latter, but I'm not sure if the= re's a way to do it that provides real value (i.e., isn't just advi= sory).

=
Kyle

=E2=80=8BSo I just had an idea that may= be is relevant and maybe is not. Built into QUIC is the idea that it is a c= onversation between one machine at the client (initiator) end and one machi= ne at the server (responder) end.

Is that real?

= Lets say that Alice is surfin' the Web and goes to a page that has stre= aming media, static content and such all from the same service but being se= rved up via different physical machines.

What happens today is that we either demultiplex the stream= s in the HTML by giving them all URIs to be resolved separately or we have = a Tier 1 system on the service end that is acting as a front end to all tho= se tier 2 resources.

Both= approaches have consequences. In the first case we end up with two machine= s in the same data center, often the same rack communicating through HTTP c= ookies bouncing off the client.=C2=A0 Not just technically bad but needless= EU tracking cookie complications. In the second, we have to have pipe huge= amounts of data across our machine room when it could just be shipped dire= ctly out the door.


What if we could= change the model here? Instead of thinking of QUIC as being a Transport la= yer being implemented as an application layer kludge, maybe we are developi= ng something a little bit higher level (presentation ?).

Assume we have some internal protocol to ha= nd off handling of a stream to a different host. We could do some interesti= ng stuff.=C2=A0


I would like to get= rid of content IDs, stream IDs, everything. Every stream that is created i= s assigned a opaque unique identifier by the party that is going to receive= the packets. The allowed length is long enough to allow whatever state nee= ds to be packed therein.

= Standards are all about making decisions that don't matter while not ma= king decisions that matter a lot to other people.

=E2=80=8B




--94eb2c12849043dd33054a50e593-- From nobody Thu Mar 9 11:26:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F44129497 for ; Thu, 9 Mar 2017 11:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wEco2bpIFOiT for ; Thu, 9 Mar 2017 11:26:07 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 CF1E4126CD8 for ; Thu, 9 Mar 2017 11:26:06 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id u30so92685412uau.0 for ; Thu, 09 Mar 2017 11:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=viq7H17B51RUn8n/kIiNTIqwz9yjEKnRGjisQDsv3U8=; b=cLI/97T1W0en47pZqMxMwMyk5NmebDS1Rfnczi7jbg24stZejQHiPc5dZQVdynXCXt D2VKJq7G/1F+OYVWU6P0+SZ1emYNXaaBUwvz0rzMPOXrApei7jSKN5TvF2IMPUGwOg3W v+t0R3pPoAXjX5uVCWjZYAewwg5e+HiCgiZx+1kujm9VeyYrk0pAuFMzI3bUDs/l69CA Kfy/grW98Kw/DB3A+CpGAdlSu6rV62zHh92Jw9A0TVCUHW62BWPhVy3Cy16NB7wTyQnA OpZ3rBzI9k8DZ/A1ddw/qrHdWWSeUqDmt/h8OUG4zoWE3hJZo83FDdjK8dMAexJEwWtt kpsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=viq7H17B51RUn8n/kIiNTIqwz9yjEKnRGjisQDsv3U8=; b=riyMwy3TaeFebyb3EAs2C106F5OlJ1/+REo2wKSzly7Sk2zX8EBH9fxHZFRu/iKRUT B1sI/VL+PYjQlBelcWkmRrlGjwC7vlDxonFqMotn32YkVTSYb1IJPzKUczZ9hg0H8vlW +JxYzfbYnCOaoU8f86xytRhp6dCVhxt05XKWpSaf+R6tUsWcy+ed07eJqgLvz6N2wdSA ZAvkH5/SCm7KP2qQfwdPwNgtt2oK+XHt+zTUm2ZOmUwxZhqxbYRJiBnWptD1b3sFH+Ma DFcSeRVoTxCacls4NxptkN2VKp9gq20jbs5oO/MUfvAO4lFV4ginIHuvPNDciniHMrn5 28tA== X-Gm-Message-State: AMke39mIuCMznXrf4RZlW++r/cgbPyauwRczKa+r+EAz2XvLMp4H/2BwL711WIWXDtgK4u007iCIR6Pm1zSxYkUE X-Received: by 10.31.125.12 with SMTP id y12mr7556137vkc.161.1489087565473; Thu, 09 Mar 2017 11:26:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 9 Mar 2017 11:26:04 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Mar 2017 11:26:04 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c14c356618c68054a513789 Archived-At: Cc: Brian Trammell , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:26:10 -0000 --94eb2c14c356618c68054a513789 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 9:32 AM, Eric Rescorla wrote: > > > On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: > >> A thoughts as I catch up on this thread (and in response to ekr's >> original question): >> >> - As ekr points out, server-side middleboxes can always rely on >> connection IDs by policy. The value of the connection ID bit, in my mind, >> is for middleboxes not controlled by the server. Such middleboxes are >> likely to use the connection ID to identify connections where it exists. >> Without an explicit per-packet bit, a middlebox that wants to use >> connection ID will have to dig into the handshake to determine where it's >> presence negotiated. This leads to ossification of bits inside the >> cleartext handshake messages, which is highly undesirable. I'd rather that >> the connection ID bit be ossified. >> > > Sure, but this starts from the position that middleboxes should be using > connection > IDs. It's not clear to me that we want to encourage that. > Why not? It's a connection identifier, like the TCP 4-tuple. What do you gain from middleboxes not using the connection ID to identify connections? - As it stands, connection ID negotiation means that each side tells the >> peer what it wants the peer to do. In a world with (i) no connection ID bit >> and (ii) clients vetoing the server's request, policy decisions are hard >> for load balancers. In this world, there's no good way for server-side load >> balancers to know per connection whether it has a connection ID or not: to >> find connection state, the load balancer needs a key, which would be the >> connection ID, which may or may not be present for that connection. The >> load balancer could use the 4-tuple to key the connection, but that >> entirely defeats the point of using the connection ID. >> > > Hmm... This seems rather more to be the result of letting the client veto. > In the design > you propose, the server does: > > - If connection id bit is 1 look up connection ID > - Otherwise, look up the host/port > > > If you don't have a bit, you can > > - Look up the host/port > - If it's missing assume that there is a connection ID and look for it > - If that's missing, drop the packet > Yes, I was responding to Brian's email -- apologies for crossing the wires a bit. This method is plausible, but it increases the work per packet at load balancers by ~2x. - The privacy implications of sharing connection ID is a separate >> conversation from the one this thread was started on. Though since some >> points were raised here and since they speak to the question of what >> information to share with middleboxes, I'll share my thoughts. >> >> We need to separate the use of connection ID use across NAT rebindings vs >> the use of connection ID use across client network changes. >> >> We'd all probably agree that NAT rebindings for UDP are a real concern, >> since NATs kill these bindings faster than they do TCP bindings. >> > > Actually, no, I'm not persuaded by this as yet. I agree with the statement > that NATs kill these bindings > faster, but it's not yet clear to me that connection IDs ameliorate these > problems sufficiently to > improve the situation. I'd be happy to see any data you have that supports > this point. > I don't follow. I think you're agreeing with what I said above, that NAT rebindings happen faster for UDP. A QUIC packet post-rebinding for the same connection carries the same connection ID, which leads it back to the same server even if a NAT rebinding happened. Why do you think connection IDs don't ameliorate this problem (of NAT rebindings happen faster for UDP) sufficiently? In other words, what piece of this problem does connection ID not solve? We'd all agree that connection ID use across client network changes is a >> new beast. To this end, I think we've generally agreed (informally anyways) >> that the client must use a new connection ID when it triggers connection >> migration to a different network. >> > > The difficulty is that we do not presently know how to arrange that you > always use a new conn id > on migration without using a new conn id on each packet. > That's not true. We can arrange for an active client-driven migration to use a new connection ID. It's the NAT rebinding case that we can't handle without a new connection ID per packet. The reason I separated the connection ID question into NAT rebinding vs client migration was to also separate the privacy considerations for these two cases. While there's a real concern of privacy leakage across active client migrations, privacy leakage due to a stable connection ID across NAT rebindings is not different than that due to a stable TCP connection for the same duration. In sum, my argument is that having connection IDs stable across NAT >> rebindings is a necessity for QUIC to work well. As a result, middleboxes >> at various points in the network, specifically those past a NAT, are >> expected to use it to track connection state. Explicitly noting its >> presence in the packet anticipates this and eliminates this one reason for >> ossification of other bits deep in handshake messages needed otherwise for >> its inference. >> > > I don't see you arguing that this is desirable so much as inevitable. So, > if we had a design that > was reasonably efficient that used a different connection ID per packet, > then you would be > fine with that and wouldn't feel the need to tell middleboxes where it was? > I wouldn't because I think middleboxes need to see this to identify connections. I understand that server-side middleboxes can be included in such designs, but not all, and especially not operator ones which are neither client -controlled nor server-controlled. Operators have and continue to use passive monitoring techniques (note, I'm using this as a measurement term, not as a privacy leakage term, and yes, I appreciate that there's overlap) for monitoring their network. They've used the entire TCP header so far for doing this leading to ossification, and so I strongly agree that every bit should be considered. That said, I don't understand what problem denying them connection ID solves. - jana > -Ekr > > >> >> - jana >> >> >> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: >> >>> hi Ekr, all, >>> >>> > > Well, with negotiation, someone has to decide. The bit just moves >>> that to the client. >>> > > Except that if the load balancer *needs* it, then the client has to >>> conform. >>> > >>> >> The load balancer needs it to balance load efficiently. >>> >> >>> > That's not entirely clear. Note that in the original QUIC design, the >>> client supplied >>> > the connection ID, so the server side merely had to load balance based >>> on some combination >>> > of a random value and the client's IP. >>> >>> Right; should have said that "the assertion behind server-suggested >>> Connection ID proposal is that it's needed for efficient load balancing". >>> I'm taking that assertion at face value now, possibly because I'm convinced >>> of the utility of one of its side-effects: providing some additional grade >>> of assurance to a device on path that a given packet was not injected >>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>> of the just-submitted manageability draft). >>> >>> >> I presume that a client that was very interested in not providing >>> tracking information could refuse to make Connection ID available, at the >>> cost of degraded performance. >>> >>> (I would like to reiterate that I do think that it's necessary to allow >>> clients to veto server-proposed connection ID exposure.) >>> >>> >> (f that's not the case, if failure to send connection ID leads to >>> connection failure, then "negotiation" is a euphemism: the server informs >>> the client whether it must send a connection ID, probably encrypted, and >>> nobody needs any flags, unless the presence of connection ID changes the >>> offsets of fields we *do* want to explicitly expose, such as packet number >>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>> troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279 >>> ). >>> > >>> > Not to put too fine a point on it, but there's far from consensus that >>> we want to expose >>> > either of these. >>> >>> That's not too fine a point at all; I'm not presupposing consensus on >>> either of these. All I'm saying here is, should consensus emerge that the >>> benefits outweigh the costs (both in complexity and in risk) for certain >>> kinds of exposure to the path -- which I think may be the case for some of >>> the things under discussion in 279, and I'm obviously convinced of the >>> utility of packet number echo as in 269 or I wouldn't have submitted two >>> PRs on it -- we need to be clear that other choices we make about the >>> layout of the header doesn't make that harder than it needs to be. Sticking >>> variable-length/optional fields whose presence is dependent on >>> endpoint-shared state after the exposed fields is probably sufficient for >>> this. >>> >>> >>> Cheers, >>> >>> Brian >>> >>> >> > --94eb2c14c356618c68054a513789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 9, 2017 at 9:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Mar 9, 2017 a= t 9:08 AM, Jana Iyengar <jri@google.com> wrote:
A thoughts as I catch up on this thread= (and in response to ekr's original question):

- As e= kr points out, server-side middleboxes can always rely on connection IDs by= policy. The value of the connection ID bit, in my mind, is for middleboxes= not controlled by the server. Such middleboxes are likely to use the conne= ction ID to identify connections where it exists. Without an explicit per-p= acket bit, a middlebox that wants to use connection ID will have to dig int= o the handshake to determine where it's presence negotiated. This leads= to ossification of bits inside the cleartext handshake messages, which is = highly undesirable. I'd rather that the connection ID bit be ossified.<= /div>

Sure, but th= is starts from the position that middleboxes should be using connection
IDs. It's not clear to me that we want to encourage that.
<= /div>

Why not? It's a conne= ction identifier, like the TCP 4-tuple. What do you gain from middleboxes n= ot using the connection ID to identify connections?

- As it stands, connection ID negotiation means tha= t each side tells the peer what it wants the peer to do. In a world with (i= ) no connection ID bit and (ii) clients vetoing the server's request, p= olicy decisions are hard for load balancers. In this world, there's no = good way for server-side load balancers to know per connection whether it h= as a connection ID or not: to find connection state, the load balancer need= s a key, which would be the connection ID, which may or may not be present = for that connection. The load balancer could use the 4-tuple to key the con= nection, but that entirely defeats the point of using the connection ID.

Hmm... This seems ra= ther more to be the result of letting the client veto. In the design
<= div>you propose, the server does:

- If connection = id bit is 1 look up connection ID
- Otherwise, look up the host/p= ort


If you don't have a bit, yo= u can

- Look up the host/port
- If it= 9;s missing assume that there is a connection ID and look for it
= - If that's missing, drop the packet

Yes, I was responding to Brian's email -- apologi= es for crossing the wires a bit. This method is plausible, but it increases= the work per packet at load balancers by ~2x.=C2=A0

- The privacy implications of sharing connection I= D is a separate conversation from the one this thread was started on. Thoug= h since some points were raised here and since they speak to the question o= f what information to share with middleboxes, I'll share my thoughts.= =C2=A0

We need to separate the use of connection I= D use across NAT rebindings vs the use of connection ID use across client n= etwork changes.=C2=A0

We'd all probably agree = that NAT rebindings for UDP are a real concern, since NATs kill these bindi= ngs faster than they do TCP bindings.
Actually, no, I'm not persuaded by this as yet. I a= gree with the statement that NATs kill these bindings
faster, but= it's not yet clear to me that connection IDs ameliorate these problems= sufficiently to
improve the situation. I'd be happy to see a= ny data you have that supports this point.

I don't follow. I think you're agreeing wit= h what I said above, that NAT rebindings happen faster for UDP.=C2=A0 A QUI= C packet post-rebinding for the same connection carries the same connection= ID, which leads it back to the same server even if a NAT rebinding happene= d. Why do you think connection IDs don't ameliorate this problem (of NA= T rebindings happen faster for UDP) sufficiently? In other words, what piec= e of this problem does connection ID not solve?

We'd all agree that connection ID use across client= network changes is a new beast. To this end, I think we've generally a= greed (informally anyways) that the client must use a new connection ID whe= n it triggers connection migration to a different network.

The difficulty is that we do not p= resently know how to arrange that you always use a new conn id
on= migration without using a new conn id on each packet.

That's not true. We can arrange for= an active client-driven migration to use a new connection ID. It's the= NAT rebinding case that we can't handle without a new connection ID pe= r packet. The reason I separated the connection ID question into NAT rebind= ing vs client migration was to also separate the privacy considerations for= these two cases. While there's a real concern of privacy leakage acros= s active client migrations, privacy leakage due to a stable connection ID a= cross NAT rebindings is not different than that due to a stable TCP connect= ion for the same duration.

<= span class=3D"">
I= n sum, my argument is that having connection IDs stable across NAT rebindin= gs is a necessity for QUIC to work well. As a result, middleboxes at variou= s points in the network, specifically those past a NAT, are expected to use= it to track connection state. Explicitly noting its presence in the packet= anticipates this and eliminates this one reason for ossification of other = bits deep in handshake messages needed otherwise for its inference.

I don't see you argui= ng that this is desirable so much as inevitable. So, if we had a design tha= t
was reasonably efficient that used a different connection ID pe= r packet, then you would be
fine with that and wouldn't feel = the need to tell middleboxes where it was?

I wouldn't because I think middleboxes need to = see this to identify connections. I understand that server-side middleboxes= can be included in such designs, but not all, and especially not operator = ones which are neither client -controlled nor server-controlled. Operators = have and continue to use passive monitoring techniques (note, I'm using= this as a measurement term, not as a privacy leakage term, and yes, I appr= eciate that there's overlap) for monitoring their network. They've = used the entire TCP header so far for doing this leading to ossification, a= nd so I strongly agree that every bit should be considered. That said, I do= n't understand what problem denying them connection ID solves.

- jana
=C2=A0
-Ekr
=C2=A0

- jana


On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <= ietf@trammell.ch&= gt; wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian




--94eb2c14c356618c68054a513789-- From nobody Thu Mar 9 11:35:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964F129464 for ; Thu, 9 Mar 2017 11:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZrpcoET8fxQ for ; Thu, 9 Mar 2017 11:35:51 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACEB128AB0 for ; Thu, 9 Mar 2017 11:35:51 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id p77so12536956ywg.1 for ; Thu, 09 Mar 2017 11:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zrYnR8TuUy+Oj6Ip9E5wPjDzU+fl5N9vDFnb4Ez2Cd4=; b=ki5PKFAWepK1SZXaYKnQtoo+FrMDJKDESspcsTujKuEEOAekW5dEB+WFFiC6zndyIi qxtWvrA36XqRHeoCVi6I/Bk6l+vgZpvwCQvY+4xlKR1na3DDWqL3bRJKJqw4z9iX4BjR ZX2x3CaSBhPYqWSDhDwU08VfN1gzgLXih90E3rsPt/+ipOMOiUc25IWXC8DHVkyyn77P qTVF56MNdnUP1TNY8Vi686N1zmpiGvqToiOkLYTZsWdKVnsgZIGTj0iiIyBz4k9ZLN/N z5M6vVDR5fsS7CHql1GJR4QOlV1HqH/3SKNzkPfkhctUJj3CTN78fnGSK6CVpIFhTyNg OLrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zrYnR8TuUy+Oj6Ip9E5wPjDzU+fl5N9vDFnb4Ez2Cd4=; b=Cx6yf9XUUAN1qD4GJUq6n3eqfC4THRVleFfT+g4ufXVFo8CiDifBrJLksHt4YQWZ/r fUFiJbkXlDlprJ+Iivl9N7Ajv/hnDw6ZR4M+GQPVYnID+os8/DIl52DKuyIViF/1iW8P lc7L5fnqeWo9FLFl3QFEwis7LR1oAYcK+tAbfc7i27EKwdtRair8kjT/TbesTHhivukj xhrPqNCTKaSa+3PiX+cuzKP00YvsUmFY8YcmppVwO+blew9aPhxVkLlcK8btbGDIvt+t TFZFU6SaO6mbxxZY+aZVERsYqkIbq6xOy2GQql64n/Gazs09NXsgXOELZ3HEGy2cyKhX dn9w== X-Gm-Message-State: AMke39lSa/2ywqqO5xR0pinAPuDSB172pFHukJxbDN3dg1cCBHKk+8O8bgX5o/4/ErXBMYbRcgOwFscngtX48Q== X-Received: by 10.129.125.5 with SMTP id y5mr4898846ywc.120.1489088150323; Thu, 09 Mar 2017 11:35:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 11:35:09 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 11:35:09 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114936443d6a45054a515ae4 Archived-At: Cc: Brian Trammell , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:35:54 -0000 --001a114936443d6a45054a515ae4 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 11:26 AM, Jana Iyengar wrote: > On Thu, Mar 9, 2017 at 9:32 AM, Eric Rescorla wrote: > >> >> >> On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar wrote: >> >>> A thoughts as I catch up on this thread (and in response to ekr's >>> original question): >>> >>> - As ekr points out, server-side middleboxes can always rely on >>> connection IDs by policy. The value of the connection ID bit, in my mind, >>> is for middleboxes not controlled by the server. Such middleboxes are >>> likely to use the connection ID to identify connections where it exists. >>> Without an explicit per-packet bit, a middlebox that wants to use >>> connection ID will have to dig into the handshake to determine where it's >>> presence negotiated. This leads to ossification of bits inside the >>> cleartext handshake messages, which is highly undesirable. I'd rather that >>> the connection ID bit be ossified. >>> >> >> Sure, but this starts from the position that middleboxes should be using >> connection >> IDs. It's not clear to me that we want to encourage that. >> > > Why not? It's a connection identifier, like the TCP 4-tuple. What do you > gain from middleboxes not using the connection ID to identify connections? > Yeah, I wish they wouldn't use the 4-tuple either. In fact much of this conversation is driven by them doing nonsense based on the 4-tuple. > If you don't have a bit, you can >> >> - Look up the host/port >> - If it's missing assume that there is a connection ID and look for it >> - If that's missing, drop the packet >> > > Yes, I was responding to Brian's email -- apologies for crossing the wires > a bit. This method is plausible, but it increases the work per packet at > load balancers by ~2x. > Not really, because you can check in either order, so unless it's 50/50 you usually get the fast-path. Actually, no, I'm not persuaded by this as yet. I agree with the statement >> that NATs kill these bindings >> faster, but it's not yet clear to me that connection IDs ameliorate these >> problems sufficiently to >> improve the situation. I'd be happy to see any data you have that >> supports this point. >> > > I don't follow. I think you're agreeing with what I said above, that NAT > rebindings happen faster for UDP. A QUIC packet post-rebinding for the > same connection carries the same connection ID, which leads it back to the > same server even if a NAT rebinding happened. Why do you think connection > IDs don't ameliorate this problem (of NAT rebindings happen faster for UDP) > sufficiently? In other words, what piece of this problem does connection ID > not solve? > 1. Anything where it's the server speaking first after the rebind. 2. Situations where the server or client would have GCed the state anyway. I'm looking for data that indicates that the remaining cases are common enough to be important enough to take the privacy hit. As I said in my response to Ian, I'll try to figure out a more precise framing of the data that I would find persuasive. We'd all agree that connection ID use across client network changes is a >>> new beast. To this end, I think we've generally agreed (informally anyways) >>> that the client must use a new connection ID when it triggers connection >>> migration to a different network. >>> >> >> The difficulty is that we do not presently know how to arrange that you >> always use a new conn id >> on migration without using a new conn id on each packet. >> > > That's not true. We can arrange for an active client-driven migration to > use a new connection ID. It's the NAT rebinding case that we can't handle > without a new connection ID per packet. The reason I separated the > connection ID question into NAT rebinding vs client migration was to also > separate the privacy considerations for these two cases. While there's a > real concern of privacy leakage across active client migrations, privacy > leakage due to a stable connection ID across NAT rebindings is not > different than that due to a stable TCP connection for the same duration. > There are plenty of times when the client does a network change but doesn't know it has. Tethering is one example. In such cases, continuing to use the same connection ID presents a privacy threat. -Ekr >>> >>> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell wrote: >>> >>>> hi Ekr, all, >>>> >>>> > > Well, with negotiation, someone has to decide. The bit just moves >>>> that to the client. >>>> > > Except that if the load balancer *needs* it, then the client has to >>>> conform. >>>> > >>>> >> The load balancer needs it to balance load efficiently. >>>> >> >>>> > That's not entirely clear. Note that in the original QUIC design, the >>>> client supplied >>>> > the connection ID, so the server side merely had to load balance >>>> based on some combination >>>> > of a random value and the client's IP. >>>> >>>> Right; should have said that "the assertion behind server-suggested >>>> Connection ID proposal is that it's needed for efficient load balancing". >>>> I'm taking that assertion at face value now, possibly because I'm convinced >>>> of the utility of one of its side-effects: providing some additional grade >>>> of assurance to a device on path that a given packet was not injected >>>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>>> of the just-submitted manageability draft). >>>> >>>> >> I presume that a client that was very interested in not providing >>>> tracking information could refuse to make Connection ID available, at the >>>> cost of degraded performance. >>>> >>>> (I would like to reiterate that I do think that it's necessary to allow >>>> clients to veto server-proposed connection ID exposure.) >>>> >>>> >> (f that's not the case, if failure to send connection ID leads to >>>> connection failure, then "negotiation" is a euphemism: the server informs >>>> the client whether it must send a connection ID, probably encrypted, and >>>> nobody needs any flags, unless the presence of connection ID changes the >>>> offsets of fields we *do* want to explicitly expose, such as packet number >>>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>>> troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279 >>>> ). >>>> > >>>> > Not to put too fine a point on it, but there's far from consensus >>>> that we want to expose >>>> > either of these. >>>> >>>> That's not too fine a point at all; I'm not presupposing consensus on >>>> either of these. All I'm saying here is, should consensus emerge that the >>>> benefits outweigh the costs (both in complexity and in risk) for certain >>>> kinds of exposure to the path -- which I think may be the case for some of >>>> the things under discussion in 279, and I'm obviously convinced of the >>>> utility of packet number echo as in 269 or I wouldn't have submitted two >>>> PRs on it -- we need to be clear that other choices we make about the >>>> layout of the header doesn't make that harder than it needs to be. Sticking >>>> variable-length/optional fields whose presence is dependent on >>>> endpoint-shared state after the exposed fields is probably sufficient for >>>> this. >>>> >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> >>> >> > --001a114936443d6a45054a515ae4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 11:26 AM, Jana Iyengar <jri@google.com> wrote:
On Thu, Mar 9, 20= 17 at 9:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Mar 9, 2017 at 9:08 AM, Jana Iyengar = <j= ri@google.com> wrote:
A thoughts as I catch up on this thread (and in response to ekr= 's original question):

- As ekr points out, server-si= de middleboxes can always rely on connection IDs by policy. The value of th= e connection ID bit, in my mind, is for middleboxes not controlled by the s= erver. Such middleboxes are likely to use the connection ID to identify con= nections where it exists. Without an explicit per-packet bit, a middlebox t= hat wants to use connection ID will have to dig into the handshake to deter= mine where it's presence negotiated. This leads to ossification of bits= inside the cleartext handshake messages, which is highly undesirable. I= 9;d rather that the connection ID bit be ossified.
<= /blockquote>

Sure, but this starts from the posit= ion that middleboxes should be using connection
IDs. It's not= clear to me that we want to encourage that.

Why not? It's a connection identifier,= like the TCP 4-tuple. What do you gain from middleboxes not using the conn= ection ID to identify connections?

Yeah, I wish they wouldn't use the 4-tuple either. In f= act much of this conversation is driven by them doing nonsense based on the= 4-tuple.

=C2=A0
<= span class=3D"">
If you don't have a bi= t, you can

- Look up the host/port
- If = it's missing assume that there is a connection ID and look for it
=
- If that's missing, drop the packet

Yes, I was responding to Brian's emai= l -- apologies for crossing the wires a bit. This method is plausible, but = it increases the work per packet at load balancers by ~2x.=C2=A0

Not really, because you can c= heck in either order, so unless it's 50/50 you usually get the fast-pat= h.



Actually, no, I'm= not persuaded by this as yet. I agree with the statement that NATs kill th= ese bindings
faster, but it's not yet clear to me that connec= tion IDs ameliorate these problems sufficiently to
improve the si= tuation. I'd be happy to see any data you have that supports this point= .

I don'= t follow. I think you're agreeing with what I said above, that NAT rebi= ndings happen faster for UDP.=C2=A0 A QUIC packet post-rebinding for the sa= me connection carries the same connection ID, which leads it back to the sa= me server even if a NAT rebinding happened. Why do you think connection IDs= don't ameliorate this problem (of NAT rebindings happen faster for UDP= ) sufficiently? In other words, what piece of this problem does connection = ID not solve?

1. An= ything where it's the server speaking first after the rebind.
2. Situations where the server or client would have GCed the state anyway.=

I'm looking for data that indicates that the = remaining cases are common enough to be
important enough to take = the privacy hit. As I said in my response to Ian, I'll try to
figure out a more precise framing of the data that I would find persuasive= .


We'd all agree that connection ID use across clie= nt network changes is a new beast. To this end, I think we've generally= agreed (informally anyways) that the client must use a new connection ID w= hen it triggers connection migration to a different network.

The difficulty is that we do not= presently know how to arrange that you always use a new conn id
= on migration without using a new conn id on each packet.
<= /div>

That's not true. We can ar= range for an active client-driven migration to use a new connection ID. It&= #39;s the NAT rebinding case that we can't handle without a new connect= ion ID per packet. The reason I separated the connection ID question into N= AT rebinding vs client migration was to also separate the privacy considera= tions for these two cases. While there's a real concern of privacy leak= age across active client migrations, privacy leakage due to a stable connec= tion ID across NAT rebindings is not different than that due to a stable TC= P connection for the same duration.

There are plenty of times when the client does a network c= hange but doesn't know it
has. Tethering is one example. In s= uch cases, continuing to use the same connection
ID presents a pr= ivacy threat.

-Ekr


=
<= div>

O= n Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian





--001a114936443d6a45054a515ae4-- From nobody Thu Mar 9 11:39:21 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6801295B1 for ; Thu, 9 Mar 2017 11:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JJwGdfEqcJYy for ; Thu, 9 Mar 2017 11:39:18 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 4658E1294B0 for ; Thu, 9 Mar 2017 11:39:18 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id q7so76171562uaf.2 for ; Thu, 09 Mar 2017 11:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4vO3Fqacxnof7f/rGZSuMTc+vBlhP9Z1Lp02ylIO+4Q=; b=uY6FaKAlOOaJeDJl0/cxP2t8m3zQU1GXKbEXGTNnsxneEFB6T5Vtb+5I4FwwLInkgA acvI5mVXjaa3Ie8BpPygwQw0+2t2Lb1ruyN9rPsiZnPvRHh5AKx+JLjXcXFWDLx4eYki 7TFXcnlLDbAhTZPsBZEZJzZvChHkUWgXDadg7dSMxl9+q/bBNDcyO4ukXom7dcFYIL7J UmVS9WgHObcQnBOtxzAmnd8wLdf/BbQ8tkjLQ/ulOSzQRehtG8nBaXOrlRQFQr0cNaRU gE/mRxDp6W8N8nER+WfKGBiB+sjZiVxdQxzv8dvNqvZYyp6HNXbPU49Cat5UJwKIa/dr rpHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4vO3Fqacxnof7f/rGZSuMTc+vBlhP9Z1Lp02ylIO+4Q=; b=PbIhjKLpSwem9X4DXBLnxAOxWaY0iTrdcnOvfB194V0i+kV0Y5f8Qq7gYZ3qSJJH27 z+/OfW+zWaws7be3P6ztIZlPLqnUEvKZVUr2RbItX/37My3KkyLLgmjemWOj2vB4SinD ju2EiVrotOvZvnkF1UMUemwVyHbGNneCOcDedHp7o1lShpsagUKlEF06QvpURz4E0VNa BETWCXKXAAGOkEfd2ceugDA42UXBn5r9/SGqDPtf4tzGbqMS5Ka+bxNu6zFB+tWAxT88 mGtDhpGeab3Wv5h6i6O9BRGO3PUZshrRkJm3jfx+h3sMYwwqkxSeRDAF+0jU2teXoLah dogg== X-Gm-Message-State: AMke39nB4+nW6W1mFJMvbnY+i0Lg5Ya4bLWS6rSV0Yu5h32t+GreR9UfXuQ0uxFPImqmbc5cmlVIITbmQo1Do+8c X-Received: by 10.31.51.68 with SMTP id z65mr7642216vkz.40.1489088357059; Thu, 09 Mar 2017 11:39:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 9 Mar 2017 11:39:16 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Mar 2017 11:39:16 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1144a44e904275054a5166b1 Archived-At: Cc: Brian Trammell , Ian Swett , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:39:20 -0000 --001a1144a44e904275054a5166b1 Content-Type: text/plain; charset=UTF-8 Apologies -- I didn't see the flurry of emails over the past hour before writing my response. It clearly links the post-rebind portion of the connection with the >> pre-rebind portion of the connection, but I don't think it does anything >> else. A TCP connection presumably wouldn't have rebound in a similar >> circumstance, so you could trivially connect the two parts of the >> connection. >> > > I don't disagree with this statement. And to which our target is no worse > than TCP, then > mission accomplished here. But it's still part of the threat model :) > There's a fundamental tension between network manageability and the problem of linkability at the packet-level: the former relies on visible "flows" and the latter pushes against it. This is a much bigger conversation. --001a1144a44e904275054a5166b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Apologies -- I didn't see the flurry of emails over th= e past hour before writing my response.

=
=
It clearly links the post-rebind portion of the= connection with the pre-rebind portion of the connection, but I don't = think it does anything else.=C2=A0 A TCP connection presumably wouldn't= have rebound in a similar circumstance, so you could trivially connect the= two parts of the connection.

=
I don't disagree with this statement. And to which ou= r target is no worse than TCP, then
mission accomplished here. Bu= t it's still part of the threat model :)

There's a fundamental tension between network= manageability and the problem of linkability at the packet-level: the form= er relies on visible "flows" and the latter pushes against it. Th= is is a much bigger conversation.
--001a1144a44e904275054a5166b1-- From nobody Thu Mar 9 11:51:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6191293E3 for ; Thu, 9 Mar 2017 11:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IBjQTUH8uOgB for ; Thu, 9 Mar 2017 11:51:48 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 DA8B01293E1 for ; Thu, 9 Mar 2017 11:51:47 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id f54so87180985uaa.1 for ; Thu, 09 Mar 2017 11:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iIyUicmZt+LAmPu+OhmEbDJ0Hjoiw0nvokHab6AetzU=; b=cT6tW5JhW27X+YdHQJh1T0kErJfI+PPjGBsFvQOui5MdSLjCfIu/0l8C03z7z+tKTn 7TlGxcwZ0vxLaWH3HaxdgznUaGK+L/RoKbjNZL0oO1s5YBjkJ7EWJ94wRRnFUZE8gyxk WayTY3f3HyUGCEBaJu3HCbecToiWKIZep4TPJTGPqVb3IzdnYB6Lkm01GZKgCewMq8I1 Zd+Iqz8SJ1H3dQjWBzA7TKJal5+F9vIGqx9Y0/U956qaYoVDAuufIR6fukV8hBiR7DYp 4tZE2uYGDq9ZVEwAEz7NsJeEnRDwodnse7LDdQNLaa7ALlyv0Uiwc0XecL3f3KAtLxzA 63VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iIyUicmZt+LAmPu+OhmEbDJ0Hjoiw0nvokHab6AetzU=; b=gCQXjMjHE4KGLNmx+4lizxD7M8jaXLjpwGNqLt9EBpopyFR8Wf2tnzfYcX/3J+Ms1B QA8s5ZTYwMfyKRV3dLxqD2jxft8KLoy/miDwH1HILgeHqAw6ukINXIj3LQjO1wxrBoxI Jl24N3yjbtC0x3L9qnwiNO7JZ1dlwy4YIwVHYzkLR63gIgKrLnxq5UzqriI/gKJBg2js u7OmOzTfVXSaqy9YWwiAlCcRrUHeXRo5jPdXunT9xSXIXzycRl+I+UlRWCK6cN61pdU7 B6MmynKUI0cDjvMG+bC0JlKVuXImb30ZsNQfx2yGmehDYg+cVT8dK1PvKPZerJ8bDsMa K0Pg== X-Gm-Message-State: AMke39lX9esFH+faiZKF9GvYNb5GxNHKQs47l2xhw5OzEg7Ll58xYXSaBQuQOuWWR6NJ9NzL7GWWz3oG2ap3vqsW X-Received: by 10.31.13.200 with SMTP id 191mr6679008vkn.28.1489089106449; Thu, 09 Mar 2017 11:51:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 9 Mar 2017 11:51:45 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Mar 2017 11:51:45 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1141c5b43b284e054a5193a7 Archived-At: Cc: Brian Trammell , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:51:50 -0000 --001a1141c5b43b284e054a5193a7 Content-Type: text/plain; charset=UTF-8 > > Why not? It's a connection identifier, like the TCP 4-tuple. What do you >> gain from middleboxes not using the connection ID to identify connections? >> > > Yeah, I wish they wouldn't use the 4-tuple either. In fact much of this > conversation is driven by them doing nonsense based on the 4-tuple. > I understand now. FWIW, the stuff they do, using 4-tuples, includes AQM (see FQ-CoDel)... some of these things are useful. I'm not saying that's the only way to do it, and I've not thought (or know) about all the things that would break if the notion of flow was obliterated from public view. > If you don't have a bit, you can >>> >>> - Look up the host/port >>> - If it's missing assume that there is a connection ID and look for it >>> - If that's missing, drop the packet >>> >> >> Yes, I was responding to Brian's email -- apologies for crossing the >> wires a bit. This method is plausible, but it increases the work per packet >> at load balancers by ~2x. >> > > Not really, because you can check in either order, so unless it's 50/50 > you usually get the fast-path. > > > Actually, no, I'm not persuaded by this as yet. I agree with the statement >>> that NATs kill these bindings >>> faster, but it's not yet clear to me that connection IDs ameliorate >>> these problems sufficiently to >>> improve the situation. I'd be happy to see any data you have that >>> supports this point. >>> >> >> I don't follow. I think you're agreeing with what I said above, that NAT >> rebindings happen faster for UDP. A QUIC packet post-rebinding for the >> same connection carries the same connection ID, which leads it back to the >> same server even if a NAT rebinding happened. Why do you think connection >> IDs don't ameliorate this problem (of NAT rebindings happen faster for UDP) >> sufficiently? In other words, what piece of this problem does connection ID >> not solve? >> > > 1. Anything where it's the server speaking first after the rebind. > 2. Situations where the server or client would have GCed the state anyway. > I'm looking for data that indicates that the remaining cases are common > enough to be > important enough to take the privacy hit. As I said in my response to Ian, > I'll try to > figure out a more precise framing of the data that I would find persuasive. > That'd be helpful. > > We'd all agree that connection ID use across client network changes is a >>>> new beast. To this end, I think we've generally agreed (informally anyways) >>>> that the client must use a new connection ID when it triggers connection >>>> migration to a different network. >>>> >>> >>> The difficulty is that we do not presently know how to arrange that you >>> always use a new conn id >>> on migration without using a new conn id on each packet. >>> >> >> That's not true. We can arrange for an active client-driven migration to >> use a new connection ID. It's the NAT rebinding case that we can't handle >> without a new connection ID per packet. The reason I separated the >> connection ID question into NAT rebinding vs client migration was to also >> separate the privacy considerations for these two cases. While there's a >> real concern of privacy leakage across active client migrations, privacy >> leakage due to a stable connection ID across NAT rebindings is not >> different than that due to a stable TCP connection for the same duration. >> > > There are plenty of times when the client does a network change but > doesn't know it > has. Tethering is one example. In such cases, continuing to use the same > connection > ID presents a privacy threat. > The tethering case is real, but it's a corner case; connection migrations are dominated by untethered clients. - jana > -Ekr > > > >>>> >>>> On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell >>>> wrote: >>>> >>>>> hi Ekr, all, >>>>> >>>>> > > Well, with negotiation, someone has to decide. The bit just moves >>>>> that to the client. >>>>> > > Except that if the load balancer *needs* it, then the client has >>>>> to conform. >>>>> > >>>>> >> The load balancer needs it to balance load efficiently. >>>>> >> >>>>> > That's not entirely clear. Note that in the original QUIC design, >>>>> the client supplied >>>>> > the connection ID, so the server side merely had to load balance >>>>> based on some combination >>>>> > of a random value and the client's IP. >>>>> >>>>> Right; should have said that "the assertion behind server-suggested >>>>> Connection ID proposal is that it's needed for efficient load balancing". >>>>> I'm taking that assertion at face value now, possibly because I'm convinced >>>>> of the utility of one of its side-effects: providing some additional grade >>>>> of assurance to a device on path that a given packet was not injected >>>>> off-path, which is useful in in-network DoS mitigation (as in section 3.3 >>>>> of the just-submitted manageability draft). >>>>> >>>>> >> I presume that a client that was very interested in not providing >>>>> tracking information could refuse to make Connection ID available, at the >>>>> cost of degraded performance. >>>>> >>>>> (I would like to reiterate that I do think that it's necessary to >>>>> allow clients to veto server-proposed connection ID exposure.) >>>>> >>>>> >> (f that's not the case, if failure to send connection ID leads to >>>>> connection failure, then "negotiation" is a euphemism: the server informs >>>>> the client whether it must send a connection ID, probably encrypted, and >>>>> nobody needs any flags, unless the presence of connection ID changes the >>>>> offsets of fields we *do* want to explicitly expose, such as packet number >>>>> echo (https://github.com/quicwg/base-drafts/issues/269) or >>>>> troubleshooting flags (https://github.com/quicwg/bas >>>>> e-drafts/issues/279). >>>>> > >>>>> > Not to put too fine a point on it, but there's far from consensus >>>>> that we want to expose >>>>> > either of these. >>>>> >>>>> That's not too fine a point at all; I'm not presupposing consensus on >>>>> either of these. All I'm saying here is, should consensus emerge that the >>>>> benefits outweigh the costs (both in complexity and in risk) for certain >>>>> kinds of exposure to the path -- which I think may be the case for some of >>>>> the things under discussion in 279, and I'm obviously convinced of the >>>>> utility of packet number echo as in 269 or I wouldn't have submitted two >>>>> PRs on it -- we need to be clear that other choices we make about the >>>>> layout of the header doesn't make that harder than it needs to be. Sticking >>>>> variable-length/optional fields whose presence is dependent on >>>>> endpoint-shared state after the exposed fields is probably sufficient for >>>>> this. >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> >>>>> >>>> >>> >> > --001a1141c5b43b284e054a5193a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why not? It's a connec= tion identifier, like the TCP 4-tuple. What do you gain from middleboxes no= t using the connection ID to identify connections?

Yeah, I wish they wouldn&= #39;t use the 4-tuple either. In fact much of this conversation is driven b= y them doing nonsense based on the 4-tuple.

I understand now. FWIW, the stuff they do, using 4= -tuples, includes AQM (see FQ-CoDel)... =C2=A0some of these things are usef= ul. I'm not saying that's the only way to do it, and I've not t= hought (or know) about all the things that would break if the notion of flo= w was obliterated from public view.
=C2=A0
=
If you don't have a bit, you can

- Look u= p the host/port
- If it's missing assume that there is a conn= ection ID and look for it
- If that's missing, drop the packe= t

Yes, I was= responding to Brian's email -- apologies for crossing the wires a bit.= This method is plausible, but it increases the work per packet at load bal= ancers by ~2x.=C2=A0

Not really, because you can check in either order, so unless it= 9;s 50/50 you usually get the fast-path.=C2=A0
=


Actually, no, I= 'm not persuaded by this as yet. I agree with the statement that NATs k= ill these bindings
faster, but it's not yet clear to me that = connection IDs ameliorate these problems sufficiently to
improve = the situation. I'd be happy to see any data you have that supports this= point.

I do= n't follow. I think you're agreeing with what I said above, that NA= T rebindings happen faster for UDP.=C2=A0 A QUIC packet post-rebinding for = the same connection carries the same connection ID, which leads it back to = the same server even if a NAT rebinding happened. Why do you think connecti= on IDs don't ameliorate this problem (of NAT rebindings happen faster f= or UDP) sufficiently? In other words, what piece of this problem does conne= ction ID not solve?

1. Anything where it's the server speaking first after the rebi= nd.
2. Situations where the server or client would have GCed the = state anyway.=C2=A0
I'm looking for data that indicates t= hat the remaining cases are common enough to be
important enough = to take the privacy hit. As I said in my response to Ian, I'll try to
figure out a more precise framing of the data that I would find pe= rsuasive.

That'= d be helpful.
=C2=A0

=
We'd all agree that connection ID use across client network change= s is a new beast. To this end, I think we've generally agreed (informal= ly anyways) that the client must use a new connection ID when it triggers c= onnection migration to a different network.
<= div>
The difficulty is that we do not presently know h= ow to arrange that you always use a new conn id
on migration with= out using a new conn id on each packet.

That's not true. We can arrange for an acti= ve client-driven migration to use a new connection ID. It's the NAT reb= inding case that we can't handle without a new connection ID per packet= . The reason I separated the connection ID question into NAT rebinding vs c= lient migration was to also separate the privacy considerations for these t= wo cases. While there's a real concern of privacy leakage across active= client migrations, privacy leakage due to a stable connection ID across NA= T rebindings is not different than that due to a stable TCP connection for = the same duration.

There are plenty of times when the client does a network change but = doesn't know it
has. Tethering is one example. In such cases,= continuing to use the same connection
ID presents a privacy thre= at.

The tethering c= ase is real, but it's a corner case; connection migrations are dominate= d by untethered clients.

- jana
=C2=A0
-Ekr




On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <ietf@tra= mmell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian






--001a1141c5b43b284e054a5193a7-- From nobody Thu Mar 9 12:00:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5012984B for ; Thu, 9 Mar 2017 12:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0DoNbxJqfeN3 for ; Thu, 9 Mar 2017 12:00:25 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EBF1294F4 for ; Thu, 9 Mar 2017 12:00:18 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 72so91962800uaf.3 for ; Thu, 09 Mar 2017 12:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=agRDpRtELrEhKrF9m63cXyg9w2Q5HWF7Zgmca2FmKJg=; b=XSusPeeUAunT1JdWIDzabLzx3dzDY5iUQJgQaTmvPQq47xbuzsHYIqauIfcBJHpIbF MmnKzeVLnvpwA7Go3bIxEzjD7XhPeNHc2cBHENfraclBaspB/J4D4LqOTgt1CiEypyvY CQaWBHfJGE9eftcdDBfIshZbSF217dtUiacTlaaxZYkPhZKiYi3ZXmCYWxnosVWCZnH1 NM3v9sTFdiRAD09jYEND9KVIMBQehsJqDck5wiHW44EilRJFKRYbS/i58sJjtk3QXFAM DnkyPQUTk6C0bPFVTJIdSUe+R1qLcoMwxXDKW1QkRR2I3ZZcUq4tyDyaVJQkLgeuNX3H LUYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=agRDpRtELrEhKrF9m63cXyg9w2Q5HWF7Zgmca2FmKJg=; b=aAnvc0285kk0BZq7i855BgeaKIyO85mtsJ0IH7o5hWFIOt0yseU46r6NXE0MUVGUSJ 79r+YIhxFM4l3+Q5L3JvOzWXrc4iRH861zB9Cqb+rHTGug8z9YOA1TA99hrMalBlwM6j /FTHjKOn6BRjJ/D0ShMAUrC6gf01LOkso/uetO1UGnI4KJr574ZO3QktDx7STyYrFmq1 rTruouN5KYFpDmuDtpdqrJzPTMS6lky21MdlXBY9MVEih9AkQIUvTRb4trBTMZzjuoA8 Xg+QofcPYlOoDzublFdMYNSt69a+SumkWSQU0nzZUOWiDfAgLOWB3VGImLf8OHjmjZ/S 8KnQ== X-Gm-Message-State: AMke39n/OYAVeVDWd9lkuAsKDXrVnr+ID0u0i9QDIR9SzDjHPT3zzTuIduLgXMJX1cwuBD4Rc25NzuYwrX69I8U1 X-Received: by 10.159.54.205 with SMTP id p71mr6565963uap.61.1489089617435; Thu, 09 Mar 2017 12:00:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 9 Mar 2017 12:00:16 -0800 (PST) In-Reply-To: <3040C4D2-3EA5-4680-8501-C26EFF44E08C@trammell.ch> References: <3040C4D2-3EA5-4680-8501-C26EFF44E08C@trammell.ch> From: Jana Iyengar Date: Thu, 9 Mar 2017 12:00:16 -0800 Message-ID: Subject: Re: Return of the alternate header proposal To: "Brian Trammell (IETF)" Content-Type: multipart/alternative; boundary=94eb2c03d92ab0754f054a51b110 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Martin Thomson , Patrick McManus , Ian Swett X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:00:27 -0000 --94eb2c03d92ab0754f054a51b110 Content-Type: text/plain; charset=UTF-8 Landed. On Thu, Mar 9, 2017 at 8:46 AM, Brian Trammell (IETF) wrote: > +1 to land it. > > Cheers, > > Brian > > > On 09 Mar 2017, at 15:10, Eric Rescorla wrote: > > > > As Martin notes, I think there are a number of things that need > discussion here, but I'm happy to land it as a step in the right direction. > > > > On Thu, Mar 9, 2017 at 5:04 AM, Patrick McManus > wrote: > > > > On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson > wrote: > > hope > > that the people reviewing this will identify new issues where this PR > > fell short of meeting their goals. Is that an acceptable process > > here? > > > > > > I completely agree with this. At this relatively early stage we need to > lean harder into landing stuff and then opening follow-on issues.. right > now there is a significant body of work that you have to hold in your head > "I know roughly how this is going to change" to meaningfully use even the > editor's copy - closing that gap would be very helpful. Obviously the > header is a big one. > > > > For something like this I would suggest marking it consensus and perhaps > just commenting on any known caveats to help with paper trail. > > > > --94eb2c03d92ab0754f054a51b110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Landed.

On Thu, Mar 9, 2017 at 8:46 AM, Brian Trammell (IETF) <ietf@tr= ammell.ch> wrote:
+1 to la= nd it.

Cheers,

Brian

> On 09 Mar 2017, at 15:10, Eric Rescorla <ekr@rtfm.com> wrote:
>
> As Martin notes, I think there are a number of things that need discus= sion here, but I'm happy to land it as a step in the right direction. >
> On Thu, Mar 9, 2017 at 5:04 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
>
> On Thu, Mar 9, 2017 at 3:50 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> hope
> that the people reviewing this will identify new issues where this PR<= br> > fell short of meeting their goals.=C2=A0 Is that an acceptable process=
> here?
>
>
> I completely agree with this. At this relatively early stage we need t= o lean harder into landing stuff and then opening follow-on issues.. right = now there is a significant body of work that you have to hold in your head = "I know roughly how this is going to change" to meaningfully use = even the editor's copy - closing that gap would be very helpful. Obviou= sly the header is a big one.
>
> For something like this I would suggest marking it consensus and perha= ps just commenting on any known caveats to help with paper trail.
>


--94eb2c03d92ab0754f054a51b110-- From nobody Thu Mar 9 13:18:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C25129582 for ; Thu, 9 Mar 2017 13:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7htdAIBA04b for ; Thu, 9 Mar 2017 13:18:48 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0107.outbound.protection.outlook.com [104.47.36.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C8A12956E for ; Thu, 9 Mar 2017 13:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HkkxbhI1btH61XqICkXn32DKyFlkioCLAAOtlQ0cnoM=; b=nkDR/tEEPDQBisP4BOGW5xHBvxrCEGTTbprPC7U8wCw+2W5J5u3UCatJNYrMgo3wwR299QN9EVQ0Okm7qHj0D+A6Jv5JrbJkkYtK5E4ZGwmheEn6egnqejkjakcXQWxLzWATsIjq4ampSVLXUlPBbTV+RpV4UPrllx3V7PNFLSI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 21:18:46 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 21:18:46 +0000 From: Mike Bishop To: Alcides Viamontes E Subject: RE: HTTP/QUIC Diverging from HTTP/2 Thread-Topic: HTTP/QUIC Diverging from HTTP/2 Thread-Index: AdKZAt9YNciLyZHpRWy2RhBs+G6fSwABxuKAAAL3g9A= Date: Thu, 9 Mar 2017 21:18:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: shimmercat.com; dkim=none (message not signed) header.d=none;shimmercat.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::297] x-ms-office365-filtering-correlation-id: 5f97ea1c-ec00-4796-6b9a-08d46731df7f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:tcHOxE2B0n4BH/QGX1vxRSfq1ZY8NLpXK0gOIR5ymEhdmBfLy8kk1Mq08nW5W0m3gc9sLk5IispCpY3z+pe/GwDjl9y29RVmK6nQpewtQPoNL1l8ZTQXxCp9oOftpkexUD1725vCWnCXbOr/GD2KXmKrxfJI/jXPLG3OtJNX8uZ34s8ym+MFtRi2mW+ypORGea+QjQw0aVzcVVcIpixY4w3cQXW6y9bt4FBMVg/eANU6sXaql8Rn2AU/9z0lNyk21DGhmLXJpZsa+mAqG9rOYuaHtfWOX4zT84PYlOjLRXkEVupICCqgNNg8EJrDpuusxb4X8ekrEr6nf4uyJFJY2dasAXG/VxFWt7IXX2G9+Pw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(24454002)(48184003)(51444003)(377454003)(9686003)(5005710100001)(7696004)(54896002)(236005)(81166006)(229853002)(38730400002)(25786008)(790700001)(561944003)(6306002)(110136004)(77096006)(102836003)(6246003)(6506006)(33656002)(606005)(6436002)(53546006)(122556002)(6116002)(53386004)(3660700001)(86362001)(7736002)(53936002)(99286003)(10290500002)(5660300001)(74316002)(55016002)(8676002)(7906003)(3280700002)(54906002)(54356999)(2950100002)(2906002)(50986999)(2900100001)(76176999)(8936002)(10090500001)(4326008)(189998001)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708B44FBDD0E6C191D962E387210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 21:18:46.4467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 21:18:56 -0000 --_000_BN6PR03MB2708B44FBDD0E6C191D962E387210BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgcXVlc3Rpb24gYW55b25lIHdobyB0b2xkIHlvdSB0aGUgcm9hZCBmcm9tIGluaXRpYWwg cHJvcG9zYWwgKFNQRFkpIHRvIGZpbmFsIHN0YW5kYXJkIChIVFRQLzIpIG92ZXIgdGhlIGNvdXJz ZSBvZiBtdWx0aXBsZSB5ZWFycyB3b3VsZCBiZSDigJxqdXN0IGEgZmV3IHJlZmluZW1lbnRzLuKA nSBUaGF0IHNhaWQsIG91ciBpbXBsZW1lbnRhdGlvbiBvZiBIVFRQLzIgZGlkIHN0YXJ0IHdpdGgg YW4gaW1wbGVtZW50YXRpb24gb2YgU1BEWS8zLCB0aGVuIGV2b2x2ZWQgdG8gbWF0Y2ggdGhlIEhU VFAvMiBpbXBsZW1lbnRhdGlvbiBkcmFmdHMgYXMgdGhleSB3ZXJlIHB1Ymxpc2hlZCwgc28gSSB1 bmRlcnN0YW5kIHRoZSBwYWluIG9mIGFyY2hpdGVjdHVyYWwgY2hhbmdlcyBhcyB0aGUgZHJhZnQg ZXZvbHZlcy4gIEkgZG8gaG9wZSBwZW9wbGUgd2lsbCBiZSBkb2luZyB0aGUgc2FtZSB3aXRoIEhU VFAvUVVJQy4gSXTigJlzIGFuIGl0ZXJhdGl2ZSBwcm9jZXNzLCBhbmQgd2UgbmVlZCBpbXBsZW1l bnRlciBmZWVkYmFjayB0byBtYWtlIHRob3NlIHJlZmluZW1lbnRzLg0KDQpGV0lXLCBJIGRvbuKA mXQgc2VlIGVpdGhlciBhcyBiZWluZyBhIOKAnHRyYW5zcG9ydCBmb3IgSFRUUC8x4oCdLiAgSFRU UC8xLjEsIEhUVFAvMiwgYW5kIEhUVFAvUVVJQyBhcmUgbWFwcGluZ3Mgb2YgdGhlIHNhbWUgSFRU UCBzZW1hbnRpY3MgdG8gZGlmZmVyZW50IHRyYW5zcG9ydHMg4oCTIHRoZSBmaXJzdCB0d28gdG8g VENQLCB0aGUgc2Vjb25kIHRvIFFVSUMuICBUaGUgc2FtZSBIVFRQIHNlbWFudGljcyBzaG91bGQg YXBwbHkgdG8gYWxsIHRocmVlLiAgU2VydmVyIFB1c2ggaXMgdGhlIG9ubHkgcmVhbGx5IOKAnG5l d+KAnSBzZW1hbnRpYyBmb3IgSFRUUC8yLCBhbmQgZXZlbiB0aGF0IG1hbmFnZXMgdG8gZml0IHRo ZSBIVFRQIHJlcXVlc3QvcmVzcG9uc2UgbW9kZWwgYnkgaGF2aW5nIHRoZSBzZXJ2ZXIgcHJvcG9z ZSBhIHJlcXVlc3QuDQoNCkJ1dCB5ZXMsIFFVSUMgaGFzIHRoZSBjb21wbGV4aXR5IG9mIGEgbmV3 IHRyYW5zcG9ydCDigJMgeW914oCZcmUgaW1wbGVtZW50aW5nIGFuIGFsdGVybmF0aXZlIHRvIFRD UCBiZWZvcmUgcmVpbXBsZW1lbnRpbmcgYW4gSFRUUCBtYXBwaW5nIG9uIHRvcCBvZiBpdC4gIFRo YXQgbWFwcGluZyBzaG91bGQgYmUgbXVjaCBsaWdodGVyLXdlaWdodCB0aGFuIEhUVFAvMiBiZWNh dXNlIG11Y2ggb2Ygd2hhdCBIVFRQLzIgYnVpbGRzIG91dCBpcyBub3cgcHJvdmlkZWQgYnkgUVVJ QywgYnV0IGZpcnN0IHlvdSBoYXZlIHRvIGJ1aWxkIFFVSUMsIGFuZCBpbiB0aGVzZSBlYXJseSBk cmFmdHMgaXTigJlzIGNoYW5naW5nIHJhcGlkbHkuDQoNCkZyb206IEFsY2lkZXMgVmlhbW9udGVz IEUgW21haWx0bzphbGNpZGVzdkBzaGltbWVyY2F0LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBNYXJj aCA5LCAyMDE3IDExOjE5IEFNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20+DQpDYzogcXVpY0BpZXRmLm9yZzsgSFRUUCB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCA8aWV0Zi1odHRwLXdnQHczLm9yZz4NClN1YmplY3Q6IFJlOiBIVFRQL1FVSUMgRGl2ZXJn aW5nIGZyb20gSFRUUC8yDQoNCkhlbGxvIE1pa2UsDQoNCkkgaGF2ZSBzZXJ2ZXIgaW1wbGVtZW50 YXRpb25zIG9mIFNQRFkgYW5kIHRoZW4gbGF0ZXIgSFRUUC8yLCB3aGljaCB3YXMgc3VwcG9zZWQg dG8gYmUgdmVyeSBjbG9zZSB0byBTUERZIHdpdGgganVzdCBhIGZldyByZWZpbmVtZW50cy4gV2Vs bCBpdCB0dXJuZWQgb3V0IHRoYXQgdGhlc2UgIm1pbm9yIHJlZmluZW1lbnRzIiBvZiBIVFRQLzIg cmVxdWlyZWQgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBzb2Z0d2FyZSBhcmNoaXRlY3R1cmUuIElm IEkgaGFkIGtub3duIGZyb20gdGhlIG91dHNldCB0aGF0IEhUVFAvMiB3YXMgdGhhdCBkaWZmZXJl bnQgZnJvbSBTUERZLCBJIGNvdWxkIGhhdmUgc2F2ZWQgc29tZSB0aW1lIGJ5IGltcGxlbWVudGlu ZyBIVFRQLzIgZnJvbSBzY3JhdGNoIG9uIGZpcnN0IGluc3RhbmNlLg0KDQpXZSBoYXZlIGFsc28g Y29uc2lkZXJlZCB0byBpbXBsZW1lbnQgUVVJQyBmb3IgYSB0aW1lLCBidXQgdGhlIHByb3RvY29s IGFuZCB0aGUgZHJhZnQgZGVzY3JpYmluZyBpdCBsb29rIHF1aXRlIGNvbXBsZXgsIGFuZCB0aGlz IHRoaW5nIG9mIFFVSUMgYmVpbmcgYSB0cmFuc3BvcnQgZm9yIEhUVFAvMiBiZWluZyBhIHRyYW5z cG9ydCBmb3IgSFRUUC8xIGRvZXNuJ3QgbWFrZSBpdCBlYXNpZXIuIFNvIG15IGRyZWFtIHNjZW5h cmlvIHdvdWxkIGJlIHRvIGhhdmUgYSBzdGFuZGFyZCB3aGljaCBvbmx5IG1lbnRpb25zIEhUVFAv MiBpbiBwYXNzaW5nLiBPZiBjb3Vyc2UgUVVJQyBiZWluZyBhIHRyYW5zcG9ydCBmb3IgSFRUUC8x IHNlbWFudGljcyBpcyBjb21wbGV0ZWx5IGFjY2VwdGFibGUgYW5kIHRvIGEgcG9pbnQsIGV4cGVj dGVkLg0KDQoNCg0KDQpPbiBUaHUsIE1hciA5LCAyMDE3IGF0IDc6NTMgUE0sIE1pa2UgQmlzaG9w IDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQpBdCBQYXRyaWNr4oCZcyBzdWdnZXN0aW9uLCBJ4oCZbSByZXN0 YXRpbmcgdGhpcyBxdWVzdGlvbiBhbmQgYWRkcmVzc2luZyBpdCB0byBib3RoIHRoZSBIVFRQIGFu ZCBRVUlDIHdvcmtpbmcgZ3JvdXBzLiAgQXBvbG9naWVzIGlmIHlvdeKAmXJlIGFscmVhZHkgZm9s bG93aW5nIGFsb25nIGluIFFVSUMgYW5kIGdldCB0aGlzIHR3aWNlIGFmdGVyIGhhdmluZyBhbHJl YWR5IHNlZW4gaXQgdGhlIGZpcnN0IHRpbWUuDQoNCkhUVFAvUVVJQyBzdGFydGVkIG9mZiAoZHJh ZnQgLTAwKSB3aXRoIGEgbW9zdGx5LWNvbXBsZXRlIEhUVFAvMiBzZXNzaW9uIG9uIFFVSUMgU3Ry ZWFtIDMsIGluY2x1ZGluZyBhIGZ1bGwgSFRUUC8yIG11bHRpcGxleGluZyBsYXllciB3aXRoaW4g U3RyZWFtIDMuICBBIG51bWJlciBvZiBIVFRQLzIgZnJhbWVzIHdlcmVu4oCZdCBuZWNlc3Nhcnks IHNpbmNlIHRoZXkgd2VyZSBkdXBsaWNhdGl2ZSBvZiBzZXJ2aWNlcyBRVUlDIHByb3ZpZGVzLiAg SW4gZHJhZnQgLTAxLCB3ZSByZW1vdmVkIHRoZSBmdWxsIG11eCBsYXllciBmcm9tIFN0cmVhbSAz LCBpbnN0ZWFkIGxldHRpbmcgUVVJQyBkZWFsIHdpdGggYWxsIHRoZSBzdHJlYW0gbWFuYWdlbWVu dC4gIFRoaXMgbmVjZXNzaXRhdGVkIGNoYW5nZXMgdG8gc2V2ZXJhbCBvZiB0aGUgcmVtYWluaW5n IGZyYW1lcy4gIEJ5IHRoZSBjdXJyZW50IGVkaXRvcuKAmXMgY29weSwgbm8gSFRUUC8yIGZyYW1l IGV4aXN0cyB1bm1vZGlmaWVkIGluIEhUVFAvUVVJQywgdGhvdWdoIHNldmVyYWwgZnJhbWVzIG9m IHRoZSBzYW1lIG5hbWUgYW5kIHB1cnBvc2UgZXhpc3QuICBMaWtld2lzZSwgUkZDNzU0MCBkZWZp bmVzIHNpeCBzZXR0aW5ncywgdGhyZWUgb2Ygd2hpY2ggYXJlIGluYXBwbGljYWJsZSBpbiBIVFRQ L1FVSUMuDQoNCkhvd2V2ZXIsIHRoZSBkcmFmdCBjdXJyZW50bHkgc3RpbGwgYXR0ZW1wdHMgdG8g ZGVmaW5lIHRoZW0gYXMgY2xvc2UgY291c2lucy4gIEl0IHVwZGF0ZXMgdGhlIEhUVFAvMiBmcmFt ZSBhbmQgc2V0dGluZyByZWdpc3RyaWVzIHdpdGggYWRkaXRpb25hbCBjb2x1bW5zIChIVFRQLzIs IEhUVFAvUVVJQywgb3IgQm90aD87IEhUVFAvUVVJQyBTcGVjaWZpY2F0aW9uIGlmIGFwcGxpY2Fi bGUpIGFuZCBhdHRlbXB0cyB0byBjb2V4aXN0IHdpdGggSFRUUC8yIGluIHRoZSBzYW1lIHJlZ2lz dHJ5LiAgKFFVSUMgZGVmaW5lcyBhIHVuaWZpZWQgZXJyb3Igc3BhY2UsIHdoaWNoIG1lYW5zIGEg c2VwYXJhdGUgcmVnaXN0cnkgb2YgZXJyb3IgY29kZXMgZm9yIEhUVFAvUVVJQyByZWdhcmRsZXNz LikNCg0KSW4gUFIgIzM2MzxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1 bGwvMzYzPiwgSeKAmXZlIGNvbnNvbGlkYXRlZCBhbG1vc3QgYWxsIG9mIHRoZSDigJxkaWZmZXJl bnQgZnJvbSBIVFRQLzLigJ0gdGV4dCBpbnRvIGEgbmV3IHRvcC1sZXZlbCBzZWN0aW9uIGFuZCBl eGNpc2VkIGEgbG90IG9mIOKAnEhUVFAvMiBoYXMgdGhpcywgYnV0IEhUVFAvUVVJQyBkb2VzbuKA mXQgbmVlZCBpdOKAnSB0ZXh0IGZyb20gdGhlIG1haW4gYm9keSBvZiB0aGUgZG9jdW1lbnQuICBN YXJ0aW4gaGFzIGFkdm9jYXRlZCBtYWtpbmcgYSBjbGVhbiBicmVhayBmcm9tIEhUVFAvMiBhbmQg ZGVmaW5pbmcgb3VyIG93biBJQU5BIHJlZ2lzdHJ5IGZvciBmcmFtZSB0eXBlcyBhbmQgc2V0dGlu Z3MsIGp1c3QgYXMgd2UgYWxyZWFkeSBoYXZlIGZvciBlcnJvcnMuICBXZSBjYW4sIG91dCBvZiBy ZXNwZWN0IGZvciBvdXIgY291c2luLCB1c2UgdGhlIHNhbWUgdmFsdWVzIHdoZXJlIGFwcHJvcHJp YXRlIGFuZCByZXNlcnZlIGV4aXN0aW5nIHZhbHVlcyBjdXJyZW50bHkgaW4gdXNlIG9uIHRoZSBI VFRQLzIgc2lkZS4NCg0KSSB0aGluayB0aGF04oCZcyBhIGdvb2QgaWRlYSwgYW5kIGl04oCZcyBh IGZhaXJseSBzbWFsbCBzdGVwIGZyb20gdGhlIGN1cnJlbnQgc3RhdGUgb2YgIzM2My4gIEnigJl2 ZSBjcmVhdGVkIFBSICMzNzY8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9w dWxsLzM3Nj4gdG8gYWN0dWFsbHkgbWFrZSB0aGF0IHNwbGl0Lg0KDQpDb21tZW50cyBmcm9tIGJv dGggV0dzIGFib3V0IHRoZSB0d28gUFJzIHdvdWxkIGJlIHdlbGNvbWUuICAoRmVlZGJhY2sgc28g ZmFyIGZyb20gdGhlIFFVSUMgc2lkZSBzZWVtcyB0byBtb3N0bHkgYmUg4oCcc2VwYXJhdGUgd2l0 aCByZWdyZXRzLOKAnSBidXQgbm90IHVuaXZlcnNhbGx5LikNCg0KDQoNCi0tDQpBbGNpZGVzIFZp YW1vbnRlcyBFLg0KQ2hpZWYgRXhlY3V0aXZlIE9mZmljZXIsIFp1bnp1biBBQg0KKCs0NikgNzIy Mjk0NTQyDQood3d3LnNoaW1tZXJjYXQuY29tPGh0dHA6Ly93d3cuc2hpbW1lcmNhdC5jb20+IGlz IGEgcHJvcGVydHkgb2YgWnVuenVuIEFCKQ0K --_000_BN6PR03MB2708B44FBDD0E6C191D962E387210BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZZCBxdWVzdGlvbiBhbnlvbmUgd2hvIHRvbGQgeW91IHRoZSByb2FkIGZyb20gaW5pdGlhbCBw cm9wb3NhbCAoU1BEWSkgdG8gZmluYWwgc3RhbmRhcmQgKEhUVFAvMikgb3ZlciB0aGUgY291cnNl IG9mIG11bHRpcGxlIHllYXJzIHdvdWxkIGJlIOKAnGp1c3QgYSBmZXcgcmVmaW5lbWVudHMu4oCd IFRoYXQgc2FpZCwgb3VyIGltcGxlbWVudGF0aW9uIG9mIEhUVFAvMg0KPGk+ZGlkPC9pPiBzdGFy dCB3aXRoIGFuIGltcGxlbWVudGF0aW9uIG9mIFNQRFkvMywgdGhlbiBldm9sdmVkIHRvIG1hdGNo IHRoZSBIVFRQLzIgaW1wbGVtZW50YXRpb24gZHJhZnRzIGFzIHRoZXkgd2VyZSBwdWJsaXNoZWQs IHNvIEkgdW5kZXJzdGFuZCB0aGUgcGFpbiBvZiBhcmNoaXRlY3R1cmFsIGNoYW5nZXMgYXMgdGhl IGRyYWZ0IGV2b2x2ZXMuJm5ic3A7IEkgZG8gaG9wZSBwZW9wbGUgd2lsbCBiZSBkb2luZyB0aGUg c2FtZSB3aXRoIEhUVFAvUVVJQy4NCiBJdOKAmXMgYW4gaXRlcmF0aXZlIHByb2Nlc3MsIGFuZCB3 ZSBuZWVkIGltcGxlbWVudGVyIGZlZWRiYWNrIHRvIG1ha2UgdGhvc2UgcmVmaW5lbWVudHMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZXSVcsIEkgZG9u4oCZdCBzZWUgZWl0aGVyIGFzIGJlaW5n IGEg4oCcdHJhbnNwb3J0IGZvciBIVFRQLzHigJ0uJm5ic3A7IEhUVFAvMS4xLCBIVFRQLzIsIGFu ZCBIVFRQL1FVSUMgYXJlIG1hcHBpbmdzIG9mIHRoZSBzYW1lIEhUVFAgc2VtYW50aWNzIHRvIGRp ZmZlcmVudCB0cmFuc3BvcnRzIOKAkyB0aGUgZmlyc3QgdHdvIHRvIFRDUCwgdGhlIHNlY29uZCB0 byBRVUlDLiZuYnNwOyBUaGUgc2FtZSBIVFRQIHNlbWFudGljcyBzaG91bGQgYXBwbHkNCiB0byBh bGwgdGhyZWUuJm5ic3A7IFNlcnZlciBQdXNoIGlzIHRoZSBvbmx5IHJlYWxseSDigJxuZXfigJ0g c2VtYW50aWMgZm9yIEhUVFAvMiwgYW5kIGV2ZW4gdGhhdCBtYW5hZ2VzIHRvIGZpdCB0aGUgSFRU UCByZXF1ZXN0L3Jlc3BvbnNlIG1vZGVsIGJ5IGhhdmluZyB0aGUgc2VydmVyIHByb3Bvc2UgYSBy ZXF1ZXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgeWVzLCBRVUlDIGhhcyB0aGUgY29t cGxleGl0eSBvZiBhIG5ldyB0cmFuc3BvcnQg4oCTIHlvdeKAmXJlIGltcGxlbWVudGluZyBhbiBh bHRlcm5hdGl2ZSB0byBUQ1AgYmVmb3JlIHJlaW1wbGVtZW50aW5nIGFuIEhUVFAgbWFwcGluZyBv biB0b3Agb2YgaXQuJm5ic3A7IFRoYXQgbWFwcGluZyBzaG91bGQgYmUgbXVjaCBsaWdodGVyLXdl aWdodCB0aGFuIEhUVFAvMiBiZWNhdXNlIG11Y2ggb2Ygd2hhdCBIVFRQLzIgYnVpbGRzDQogb3V0 IGlzIG5vdyBwcm92aWRlZCBieSBRVUlDLCBidXQgZmlyc3QgeW91IGhhdmUgdG8gYnVpbGQgUVVJ QywgYW5kIGluIHRoZXNlIGVhcmx5IGRyYWZ0cyBpdOKAmXMgY2hhbmdpbmcgcmFwaWRseS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEFsY2lkZXMgVmlhbW9udGVzIEUgW21h aWx0bzphbGNpZGVzdkBzaGltbWVyY2F0LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTWFyY2ggOSwgMjAxNyAxMToxOSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0 O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBxdWljQGll dGYub3JnOyBIVFRQIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0ICZsdDtpZXRmLWh0dHAtd2dA dzMub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSFRUUC9RVUlDIERpdmVyZ2luZyBm cm9tIEhUVFAvMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gTWlrZSw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzZXJ2ZXIg aW1wbGVtZW50YXRpb25zIG9mIFNQRFkgYW5kIHRoZW4gbGF0ZXIgSFRUUC8yLCB3aGljaCB3YXMg c3VwcG9zZWQgdG8gYmUgdmVyeSBjbG9zZSB0byBTUERZIHdpdGgganVzdCBhIGZldyByZWZpbmVt ZW50cy4gV2VsbCBpdCB0dXJuZWQgb3V0IHRoYXQgdGhlc2UgJnF1b3Q7bWlub3IgcmVmaW5lbWVu dHMmcXVvdDsgb2YgSFRUUC8yIHJlcXVpcmVkIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc29mdHdh cmUgYXJjaGl0ZWN0dXJlLg0KIElmIEkgaGFkIGtub3duIGZyb20gdGhlIG91dHNldCB0aGF0IEhU VFAvMiB3YXMgdGhhdCBkaWZmZXJlbnQgZnJvbSBTUERZLCBJIGNvdWxkIGhhdmUgc2F2ZWQgc29t ZSB0aW1lIGJ5IGltcGxlbWVudGluZyBIVFRQLzIgZnJvbSBzY3JhdGNoIG9uIGZpcnN0IGluc3Rh bmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSBoYXZlIGFsc28gY29uc2lkZXJlZCB0byBpbXBsZW1lbnQgUVVJQyBmb3IgYSB0aW1lLCBi dXQgdGhlIHByb3RvY29sIGFuZCB0aGUgZHJhZnQgZGVzY3JpYmluZyBpdCBsb29rIHF1aXRlIGNv bXBsZXgsIGFuZCB0aGlzIHRoaW5nIG9mIFFVSUMgYmVpbmcgYSB0cmFuc3BvcnQgZm9yIEhUVFAv MiBiZWluZyBhIHRyYW5zcG9ydCBmb3IgSFRUUC8xIGRvZXNuJ3QgbWFrZSBpdCBlYXNpZXIuIFNv IG15IGRyZWFtDQogc2NlbmFyaW8gd291bGQgYmUgdG8gaGF2ZSBhIHN0YW5kYXJkIHdoaWNoIG9u bHkgbWVudGlvbnMgSFRUUC8yIGluIHBhc3NpbmcuIE9mIGNvdXJzZSBRVUlDIGJlaW5nIGEgdHJh bnNwb3J0IGZvciBIVFRQLzEgc2VtYW50aWNzIGlzIGNvbXBsZXRlbHkgYWNjZXB0YWJsZSBhbmQg dG8gYSBwb2ludCwgZXhwZWN0ZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWFyIDksIDIwMTcgYXQgNzo1 MyBQTSwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCBQYXRyaWNr4oCZcyBzdWdnZXN0aW9uLCBJ4oCZbSBy ZXN0YXRpbmcgdGhpcyBxdWVzdGlvbiBhbmQgYWRkcmVzc2luZyBpdCB0byBib3RoIHRoZSBIVFRQ IGFuZCBRVUlDIHdvcmtpbmcgZ3JvdXBzLiZuYnNwOyBBcG9sb2dpZXMgaWYgeW914oCZcmUgYWxy ZWFkeSBmb2xsb3dpbmcgYWxvbmcgaW4gUVVJQyBhbmQgZ2V0IHRoaXMNCiB0d2ljZSBhZnRlciBo YXZpbmcgYWxyZWFkeSBzZWVuIGl0IHRoZSBmaXJzdCB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SFRUUC9RVUlDIHN0YXJ0ZWQgb2ZmIChkcmFmdCAtMDApIHdpdGggYSBtb3N0bHkt Y29tcGxldGUgSFRUUC8yIHNlc3Npb24gb24gUVVJQyBTdHJlYW0gMywgaW5jbHVkaW5nIGEgZnVs bCBIVFRQLzIgbXVsdGlwbGV4aW5nIGxheWVyIHdpdGhpbiBTdHJlYW0gMy4mbmJzcDsgQSBudW1i ZXIgb2YgSFRUUC8yIGZyYW1lcw0KIHdlcmVu4oCZdCBuZWNlc3NhcnksIHNpbmNlIHRoZXkgd2Vy ZSBkdXBsaWNhdGl2ZSBvZiBzZXJ2aWNlcyBRVUlDIHByb3ZpZGVzLiZuYnNwOyBJbiBkcmFmdCAt MDEsIHdlIHJlbW92ZWQgdGhlIGZ1bGwgbXV4IGxheWVyIGZyb20gU3RyZWFtIDMsIGluc3RlYWQg bGV0dGluZyBRVUlDIGRlYWwgd2l0aCBhbGwgdGhlIHN0cmVhbSBtYW5hZ2VtZW50LiZuYnNwOyBU aGlzIG5lY2Vzc2l0YXRlZCBjaGFuZ2VzIHRvIHNldmVyYWwgb2YgdGhlIHJlbWFpbmluZyBmcmFt ZXMuJm5ic3A7DQogQnkgdGhlIGN1cnJlbnQgZWRpdG9y4oCZcyBjb3B5LCA8aT5ubzwvaT4gSFRU UC8yIGZyYW1lIGV4aXN0cyB1bm1vZGlmaWVkIGluIEhUVFAvUVVJQywgdGhvdWdoIHNldmVyYWwg ZnJhbWVzIG9mIHRoZSBzYW1lIG5hbWUgYW5kIHB1cnBvc2UgZXhpc3QuJm5ic3A7IExpa2V3aXNl LCBSRkM3NTQwIGRlZmluZXMgc2l4IHNldHRpbmdzLCB0aHJlZSBvZiB3aGljaCBhcmUgaW5hcHBs aWNhYmxlIGluIEhUVFAvUVVJQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhvd2V2ZXIs IHRoZSBkcmFmdCBjdXJyZW50bHkgc3RpbGwgYXR0ZW1wdHMgdG8gZGVmaW5lIHRoZW0gYXMgY2xv c2UgY291c2lucy4mbmJzcDsgSXQgdXBkYXRlcyB0aGUgSFRUUC8yIGZyYW1lIGFuZCBzZXR0aW5n IHJlZ2lzdHJpZXMgd2l0aCBhZGRpdGlvbmFsIGNvbHVtbnMgKEhUVFAvMiwgSFRUUC9RVUlDLCBv ciBCb3RoPzsNCiBIVFRQL1FVSUMgU3BlY2lmaWNhdGlvbiBpZiBhcHBsaWNhYmxlKSBhbmQgYXR0 ZW1wdHMgdG8gY29leGlzdCB3aXRoIEhUVFAvMiBpbiB0aGUgc2FtZSByZWdpc3RyeS4mbmJzcDsg KFFVSUMgZGVmaW5lcyBhIHVuaWZpZWQgZXJyb3Igc3BhY2UsIHdoaWNoIG1lYW5zIGEgc2VwYXJh dGUgcmVnaXN0cnkgb2YgZXJyb3IgY29kZXMgZm9yIEhUVFAvUVVJQyByZWdhcmRsZXNzLik8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v cXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMzYzIiB0YXJnZXQ9Il9ibGFuayI+UFIgIzM2MzwvYT4s IEnigJl2ZSBjb25zb2xpZGF0ZWQgYWxtb3N0IGFsbCBvZiB0aGUg4oCcZGlmZmVyZW50IGZyb20g SFRUUC8y4oCdIHRleHQgaW50byBhIG5ldyB0b3AtbGV2ZWwgc2VjdGlvbiBhbmQgZXhjaXNlZCBh IGxvdCBvZiDigJxIVFRQLzIgaGFzIHRoaXMsIGJ1dCBIVFRQL1FVSUMgZG9lc27igJl0IG5lZWQg aXTigJ0gdGV4dCBmcm9tDQogdGhlIG1haW4gYm9keSBvZiB0aGUgZG9jdW1lbnQuJm5ic3A7IE1h cnRpbiBoYXMgYWR2b2NhdGVkIG1ha2luZyBhIGNsZWFuIGJyZWFrIGZyb20gSFRUUC8yIGFuZCBk ZWZpbmluZyBvdXIgb3duIElBTkEgcmVnaXN0cnkgZm9yIGZyYW1lIHR5cGVzIGFuZCBzZXR0aW5n cywganVzdCBhcyB3ZSBhbHJlYWR5IGhhdmUgZm9yIGVycm9ycy4mbmJzcDsgV2UgY2FuLCBvdXQg b2YgcmVzcGVjdCBmb3Igb3VyIGNvdXNpbiwgdXNlIHRoZSBzYW1lIHZhbHVlcyB3aGVyZSBhcHBy b3ByaWF0ZQ0KIGFuZCByZXNlcnZlIGV4aXN0aW5nIHZhbHVlcyBjdXJyZW50bHkgaW4gdXNlIG9u IHRoZSBIVFRQLzIgc2lkZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhh dOKAmXMgYSBnb29kIGlkZWEsIGFuZCBpdOKAmXMgYSBmYWlybHkgc21hbGwgc3RlcCBmcm9tIHRo ZSBjdXJyZW50IHN0YXRlIG9mICMzNjMuJm5ic3A7IEnigJl2ZSBjcmVhdGVkDQo8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMzc2IiB0YXJnZXQ9Il9i bGFuayI+UFIgIzM3NjwvYT4gdG8gYWN0dWFsbHkgbWFrZSB0aGF0IHNwbGl0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Q29tbWVudHMgZnJvbSBib3RoIFdHcyBhYm91dCB0aGUgdHdvIFBS cyB3b3VsZCBiZSB3ZWxjb21lLiZuYnNwOyAoRmVlZGJhY2sgc28gZmFyIGZyb20gdGhlIFFVSUMg c2lkZSBzZWVtcyB0byBtb3N0bHkgYmUg4oCcc2VwYXJhdGUgd2l0aCByZWdyZXRzLOKAnSBidXQg bm90IHVuaXZlcnNhbGx5Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPkFsY2lkZXMgVmlhbW9udGVzIEUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+Q2hpZWYgRXhlY3V0aXZlIE9mZmljZXIsIFp1bnp1biBBQjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigm IzQzOzQ2KSA3MjIyOTQ1NDI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPig8YSBocmVmPSJodHRw Oi8vd3d3LnNoaW1tZXJjYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LnNoaW1tZXJjYXQuY29t PC9hPiBpcyBhIHByb3BlcnR5IG9mIFp1bnp1biBBQik8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708B44FBDD0E6C191D962E387210BN6PR03MB2708namp_-- From nobody Thu Mar 9 13:22:21 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973AA129542 for ; Thu, 9 Mar 2017 13:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 eESitZcWqQsU for ; Thu, 9 Mar 2017 13:22:10 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D85129546 for ; Thu, 9 Mar 2017 13:22:09 -0800 (PST) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 16:22:08 -0500 From: Dave Dolson To: Jana Iyengar , "quic@ietf.org" Subject: RE: Middlebox introspection/self-describing packets Thread-Topic: Middlebox introspection/self-describing packets Thread-Index: AQHSmFSBe5LHTHc90EmU7CpJzM5KXqGL3nwAgAAyiwCAAJYbgIAAN4KAgAAjfoCAABBvAIAABvaAgAAfnQCAAAKKgIAABKSA//+/gkA= Date: Thu, 9 Mar 2017 21:22:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9870544050wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 21:22:19 -0000 --_000_E8355113905631478EFF04F5AA706E9870544050wtlexchp1sandvi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQogICA+IEkndmUgbm90IHRob3VnaHQgKG9yIGtub3cpIGFib3V0IGFsbCB0aGUgdGhpbmdzIHRo YXQgd291bGQgYnJlYWsgaWYgdGhlIG5vdGlvbiBvZiBmbG93IHdhcyBvYmxpdGVyYXRlZCBmcm9t IHB1YmxpYyB2aWV3Lg0KDQpDYW4gd2UgZGlzY3VzcyBpdCBpbiB0aGUgY29udGV4dCBvZiB0aGlz IGRyYWZ0Pw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1kb2xzb24tcGx1cy1taWRk bGVib3gtYmVuZWZpdHMtMDEudHh0DQoNCldlIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGUg dGhpbmdzIHRoYXQgbWlnaHQgYnJlYWsgaWYgdmFyaW91cyB0cmFuc3BvcnQtbGF5ZXIgaW5mbyBp cyBub3QgcHJvdmlkZWQuDQoNCkhlcmXigJlzIHBhcnQgb2YgdGhlIHRhYmxlIG9mIGNvbnRlbnRz Og0KDQoNCiAgIDIuICBNZWFzdXJlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgMw0KICAgICAyLjEuICBQYWNrZXQgTG9zcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQogICAgIDIuMi4gIFJvdW5k IFRyaXAgVGltZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQN CiAgICAgMi4zLiAgTWVhc3VyaW5nIFBhY2tldCBSZW9yZGVyaW5nIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNQ0KICAgICAyLjQuICBUaHJvdWdocHV0IGFuZCBCb3R0bGVuZWNrIElk ZW50aWZpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gICA1DQogICAgIDIuNS4gIEREb1MgRGV0ZWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAg Mi42LiAgUGFja2V0IENvcnJ1cHRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNg0KICAgICAyLjcuICBBcHBsaWNhdGlvbi1MYXllciBNZWFzdXJlbWVudHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQogICAzLiAgQWN0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgICAgMy4xLiAg TkFUIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgNw0KICAgICAzLjIuICBGaXJld2FsbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA3DQogICAgIDMuMy4gIEREb1MgU2NydWJiaW5nICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgICAgMy40LiAgUGVyZm9y bWFuY2UtRW5oYW5jaW5nIFByb3hpZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOA0K ICAgICAzLjUuICBCYW5kd2lkdGggQWdncmVnYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA5DQogICAgIDMuNi4gIFByaW9yaXRpemF0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkNCiAgICAgMy43LiAgTWVhc3VyZW1lbnQt QmFzZWQgU2hhcGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQ0KDQoNCi1E YXZlDQoNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSmFuYSBJeWVuZ2FyDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDksIDIwMTcgMjo1 MiBQTQ0KVG86IEVyaWMgUmVzY29ybGENCkNjOiBCcmlhbiBUcmFtbWVsbDsgSUVURiBRVUlDIFdH DQpTdWJqZWN0OiBSZTogTWlkZGxlYm94IGludHJvc3BlY3Rpb24vc2VsZi1kZXNjcmliaW5nIHBh Y2tldHMNCg0KV2h5IG5vdD8gSXQncyBhIGNvbm5lY3Rpb24gaWRlbnRpZmllciwgbGlrZSB0aGUg VENQIDQtdHVwbGUuIFdoYXQgZG8geW91IGdhaW4gZnJvbSBtaWRkbGVib3hlcyBub3QgdXNpbmcg dGhlIGNvbm5lY3Rpb24gSUQgdG8gaWRlbnRpZnkgY29ubmVjdGlvbnM/DQoNClllYWgsIEkgd2lz aCB0aGV5IHdvdWxkbid0IHVzZSB0aGUgNC10dXBsZSBlaXRoZXIuIEluIGZhY3QgbXVjaCBvZiB0 aGlzIGNvbnZlcnNhdGlvbiBpcyBkcml2ZW4gYnkgdGhlbSBkb2luZyBub25zZW5zZSBiYXNlZCBv biB0aGUgNC10dXBsZS4NCg0KSSB1bmRlcnN0YW5kIG5vdy4gRldJVywgdGhlIHN0dWZmIHRoZXkg ZG8sIHVzaW5nIDQtdHVwbGVzLCBpbmNsdWRlcyBBUU0gKHNlZSBGUS1Db0RlbCkuLi4gIHNvbWUg b2YgdGhlc2UgdGhpbmdzIGFyZSB1c2VmdWwuIEknbSBub3Qgc2F5aW5nIHRoYXQncyB0aGUgb25s eSB3YXkgdG8gZG8gaXQsIGFuZCBJJ3ZlIG5vdCB0aG91Z2h0IChvciBrbm93KSBhYm91dCBhbGwg dGhlIHRoaW5ncyB0aGF0IHdvdWxkIGJyZWFrIGlmIHRoZSBub3Rpb24gb2YgZmxvdyB3YXMgb2Js aXRlcmF0ZWQgZnJvbSBwdWJsaWMgdmlldy4NCg0KSWYgeW91IGRvbid0IGhhdmUgYSBiaXQsIHlv dSBjYW4NCg0KLSBMb29rIHVwIHRoZSBob3N0L3BvcnQNCi0gSWYgaXQncyBtaXNzaW5nIGFzc3Vt ZSB0aGF0IHRoZXJlIGlzIGEgY29ubmVjdGlvbiBJRCBhbmQgbG9vayBmb3IgaXQNCi0gSWYgdGhh dCdzIG1pc3NpbmcsIGRyb3AgdGhlIHBhY2tldA0KDQpZZXMsIEkgd2FzIHJlc3BvbmRpbmcgdG8g QnJpYW4ncyBlbWFpbCAtLSBhcG9sb2dpZXMgZm9yIGNyb3NzaW5nIHRoZSB3aXJlcyBhIGJpdC4g VGhpcyBtZXRob2QgaXMgcGxhdXNpYmxlLCBidXQgaXQgaW5jcmVhc2VzIHRoZSB3b3JrIHBlciBw YWNrZXQgYXQgbG9hZCBiYWxhbmNlcnMgYnkgfjJ4Lg0KDQpOb3QgcmVhbGx5LCBiZWNhdXNlIHlv dSBjYW4gY2hlY2sgaW4gZWl0aGVyIG9yZGVyLCBzbyB1bmxlc3MgaXQncyA1MC81MCB5b3UgdXN1 YWxseSBnZXQgdGhlIGZhc3QtcGF0aC4NCg0KDQpBY3R1YWxseSwgbm8sIEknbSBub3QgcGVyc3Vh ZGVkIGJ5IHRoaXMgYXMgeWV0LiBJIGFncmVlIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IE5BVHMg a2lsbCB0aGVzZSBiaW5kaW5ncw0KZmFzdGVyLCBidXQgaXQncyBub3QgeWV0IGNsZWFyIHRvIG1l IHRoYXQgY29ubmVjdGlvbiBJRHMgYW1lbGlvcmF0ZSB0aGVzZSBwcm9ibGVtcyBzdWZmaWNpZW50 bHkgdG8NCmltcHJvdmUgdGhlIHNpdHVhdGlvbi4gSSdkIGJlIGhhcHB5IHRvIHNlZSBhbnkgZGF0 YSB5b3UgaGF2ZSB0aGF0IHN1cHBvcnRzIHRoaXMgcG9pbnQuDQoNCkkgZG9uJ3QgZm9sbG93LiBJ IHRoaW5rIHlvdSdyZSBhZ3JlZWluZyB3aXRoIHdoYXQgSSBzYWlkIGFib3ZlLCB0aGF0IE5BVCBy ZWJpbmRpbmdzIGhhcHBlbiBmYXN0ZXIgZm9yIFVEUC4gIEEgUVVJQyBwYWNrZXQgcG9zdC1yZWJp bmRpbmcgZm9yIHRoZSBzYW1lIGNvbm5lY3Rpb24gY2FycmllcyB0aGUgc2FtZSBjb25uZWN0aW9u IElELCB3aGljaCBsZWFkcyBpdCBiYWNrIHRvIHRoZSBzYW1lIHNlcnZlciBldmVuIGlmIGEgTkFU IHJlYmluZGluZyBoYXBwZW5lZC4gV2h5IGRvIHlvdSB0aGluayBjb25uZWN0aW9uIElEcyBkb24n dCBhbWVsaW9yYXRlIHRoaXMgcHJvYmxlbSAob2YgTkFUIHJlYmluZGluZ3MgaGFwcGVuIGZhc3Rl ciBmb3IgVURQKSBzdWZmaWNpZW50bHk/IEluIG90aGVyIHdvcmRzLCB3aGF0IHBpZWNlIG9mIHRo aXMgcHJvYmxlbSBkb2VzIGNvbm5lY3Rpb24gSUQgbm90IHNvbHZlPw0KDQoxLiBBbnl0aGluZyB3 aGVyZSBpdCdzIHRoZSBzZXJ2ZXIgc3BlYWtpbmcgZmlyc3QgYWZ0ZXIgdGhlIHJlYmluZC4NCjIu IFNpdHVhdGlvbnMgd2hlcmUgdGhlIHNlcnZlciBvciBjbGllbnQgd291bGQgaGF2ZSBHQ2VkIHRo ZSBzdGF0ZSBhbnl3YXkuDQpJJ20gbG9va2luZyBmb3IgZGF0YSB0aGF0IGluZGljYXRlcyB0aGF0 IHRoZSByZW1haW5pbmcgY2FzZXMgYXJlIGNvbW1vbiBlbm91Z2ggdG8gYmUNCmltcG9ydGFudCBl bm91Z2ggdG8gdGFrZSB0aGUgcHJpdmFjeSBoaXQuIEFzIEkgc2FpZCBpbiBteSByZXNwb25zZSB0 byBJYW4sIEknbGwgdHJ5IHRvDQpmaWd1cmUgb3V0IGEgbW9yZSBwcmVjaXNlIGZyYW1pbmcgb2Yg dGhlIGRhdGEgdGhhdCBJIHdvdWxkIGZpbmQgcGVyc3Vhc2l2ZS4NCg0KVGhhdCdkIGJlIGhlbHBm dWwuDQoNCg0KV2UnZCBhbGwgYWdyZWUgdGhhdCBjb25uZWN0aW9uIElEIHVzZSBhY3Jvc3MgY2xp ZW50IG5ldHdvcmsgY2hhbmdlcyBpcyBhIG5ldyBiZWFzdC4gVG8gdGhpcyBlbmQsIEkgdGhpbmsg d2UndmUgZ2VuZXJhbGx5IGFncmVlZCAoaW5mb3JtYWxseSBhbnl3YXlzKSB0aGF0IHRoZSBjbGll bnQgbXVzdCB1c2UgYSBuZXcgY29ubmVjdGlvbiBJRCB3aGVuIGl0IHRyaWdnZXJzIGNvbm5lY3Rp b24gbWlncmF0aW9uIHRvIGEgZGlmZmVyZW50IG5ldHdvcmsuDQoNClRoZSBkaWZmaWN1bHR5IGlz IHRoYXQgd2UgZG8gbm90IHByZXNlbnRseSBrbm93IGhvdyB0byBhcnJhbmdlIHRoYXQgeW91IGFs d2F5cyB1c2UgYSBuZXcgY29ubiBpZA0Kb24gbWlncmF0aW9uIHdpdGhvdXQgdXNpbmcgYSBuZXcg Y29ubiBpZCBvbiBlYWNoIHBhY2tldC4NCg0KVGhhdCdzIG5vdCB0cnVlLiBXZSBjYW4gYXJyYW5n ZSBmb3IgYW4gYWN0aXZlIGNsaWVudC1kcml2ZW4gbWlncmF0aW9uIHRvIHVzZSBhIG5ldyBjb25u ZWN0aW9uIElELiBJdCdzIHRoZSBOQVQgcmViaW5kaW5nIGNhc2UgdGhhdCB3ZSBjYW4ndCBoYW5k bGUgd2l0aG91dCBhIG5ldyBjb25uZWN0aW9uIElEIHBlciBwYWNrZXQuIFRoZSByZWFzb24gSSBz ZXBhcmF0ZWQgdGhlIGNvbm5lY3Rpb24gSUQgcXVlc3Rpb24gaW50byBOQVQgcmViaW5kaW5nIHZz IGNsaWVudCBtaWdyYXRpb24gd2FzIHRvIGFsc28gc2VwYXJhdGUgdGhlIHByaXZhY3kgY29uc2lk ZXJhdGlvbnMgZm9yIHRoZXNlIHR3byBjYXNlcy4gV2hpbGUgdGhlcmUncyBhIHJlYWwgY29uY2Vy biBvZiBwcml2YWN5IGxlYWthZ2UgYWNyb3NzIGFjdGl2ZSBjbGllbnQgbWlncmF0aW9ucywgcHJp dmFjeSBsZWFrYWdlIGR1ZSB0byBhIHN0YWJsZSBjb25uZWN0aW9uIElEIGFjcm9zcyBOQVQgcmVi aW5kaW5ncyBpcyBub3QgZGlmZmVyZW50IHRoYW4gdGhhdCBkdWUgdG8gYSBzdGFibGUgVENQIGNv bm5lY3Rpb24gZm9yIHRoZSBzYW1lIGR1cmF0aW9uLg0KDQpUaGVyZSBhcmUgcGxlbnR5IG9mIHRp bWVzIHdoZW4gdGhlIGNsaWVudCBkb2VzIGEgbmV0d29yayBjaGFuZ2UgYnV0IGRvZXNuJ3Qga25v dyBpdA0KaGFzLiBUZXRoZXJpbmcgaXMgb25lIGV4YW1wbGUuIEluIHN1Y2ggY2FzZXMsIGNvbnRp bnVpbmcgdG8gdXNlIHRoZSBzYW1lIGNvbm5lY3Rpb24NCklEIHByZXNlbnRzIGEgcHJpdmFjeSB0 aHJlYXQuDQoNClRoZSB0ZXRoZXJpbmcgY2FzZSBpcyByZWFsLCBidXQgaXQncyBhIGNvcm5lciBj YXNlOyBjb25uZWN0aW9uIG1pZ3JhdGlvbnMgYXJlIGRvbWluYXRlZCBieSB1bnRldGhlcmVkIGNs aWVudHMuDQoNCi0gamFuYQ0KDQotRWtyDQoNCg0KDQoNCk9uIFRodSwgTWFyIDksIDIwMTcgYXQg ODowOSBBTSwgQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJh bW1lbGwuY2g+PiB3cm90ZToNCmhpIEVrciwgYWxsLA0KDQo+ID4gV2VsbCwgd2l0aCBuZWdvdGlh dGlvbiwgc29tZW9uZSBoYXMgdG8gZGVjaWRlLiBUaGUgYml0IGp1c3QgbW92ZXMgdGhhdCB0byB0 aGUgY2xpZW50Lg0KPiA+IEV4Y2VwdCB0aGF0IGlmIHRoZSBsb2FkIGJhbGFuY2VyICpuZWVkcyog aXQsIHRoZW4gdGhlIGNsaWVudCBoYXMgdG8gY29uZm9ybS4NCj4NCj4+IFRoZSBsb2FkIGJhbGFu Y2VyIG5lZWRzIGl0IHRvIGJhbGFuY2UgbG9hZCBlZmZpY2llbnRseS4NCj4+DQo+IFRoYXQncyBu b3QgZW50aXJlbHkgY2xlYXIuIE5vdGUgdGhhdCBpbiB0aGUgb3JpZ2luYWwgUVVJQyBkZXNpZ24s IHRoZSBjbGllbnQgc3VwcGxpZWQNCj4gdGhlIGNvbm5lY3Rpb24gSUQsIHNvIHRoZSBzZXJ2ZXIg c2lkZSBtZXJlbHkgaGFkIHRvIGxvYWQgYmFsYW5jZSBiYXNlZCBvbiBzb21lIGNvbWJpbmF0aW9u DQo+IG9mIGEgcmFuZG9tIHZhbHVlIGFuZCB0aGUgY2xpZW50J3MgSVAuDQoNClJpZ2h0OyBzaG91 bGQgaGF2ZSBzYWlkIHRoYXQgInRoZSBhc3NlcnRpb24gYmVoaW5kIHNlcnZlci1zdWdnZXN0ZWQg Q29ubmVjdGlvbiBJRCBwcm9wb3NhbCBpcyB0aGF0IGl0J3MgbmVlZGVkIGZvciBlZmZpY2llbnQg bG9hZCBiYWxhbmNpbmciLiBJJ20gdGFraW5nIHRoYXQgYXNzZXJ0aW9uIGF0IGZhY2UgdmFsdWUg bm93LCBwb3NzaWJseSBiZWNhdXNlIEknbSBjb252aW5jZWQgb2YgdGhlIHV0aWxpdHkgb2Ygb25l IG9mIGl0cyBzaWRlLWVmZmVjdHM6IHByb3ZpZGluZyBzb21lIGFkZGl0aW9uYWwgZ3JhZGUgb2Yg YXNzdXJhbmNlIHRvIGEgZGV2aWNlIG9uIHBhdGggdGhhdCBhIGdpdmVuIHBhY2tldCB3YXMgbm90 IGluamVjdGVkIG9mZi1wYXRoLCB3aGljaCBpcyB1c2VmdWwgaW4gaW4tbmV0d29yayBEb1MgbWl0 aWdhdGlvbiAoYXMgaW4gc2VjdGlvbiAzLjMgb2YgdGhlIGp1c3Qtc3VibWl0dGVkIG1hbmFnZWFi aWxpdHkgZHJhZnQpLg0KDQo+PiBJIHByZXN1bWUgdGhhdCBhIGNsaWVudCB0aGF0IHdhcyB2ZXJ5 IGludGVyZXN0ZWQgaW4gbm90IHByb3ZpZGluZyB0cmFja2luZyBpbmZvcm1hdGlvbiBjb3VsZCBy ZWZ1c2UgdG8gbWFrZSBDb25uZWN0aW9uIElEIGF2YWlsYWJsZSwgYXQgdGhlIGNvc3Qgb2YgZGVn cmFkZWQgcGVyZm9ybWFuY2UuDQoNCihJIHdvdWxkIGxpa2UgdG8gcmVpdGVyYXRlIHRoYXQgSSBk byB0aGluayB0aGF0IGl0J3MgbmVjZXNzYXJ5IHRvIGFsbG93IGNsaWVudHMgdG8gdmV0byBzZXJ2 ZXItcHJvcG9zZWQgY29ubmVjdGlvbiBJRCBleHBvc3VyZS4pDQoNCj4+IChmIHRoYXQncyBub3Qg dGhlIGNhc2UsIGlmIGZhaWx1cmUgdG8gc2VuZCBjb25uZWN0aW9uIElEIGxlYWRzIHRvIGNvbm5l Y3Rpb24gZmFpbHVyZSwgdGhlbiAibmVnb3RpYXRpb24iIGlzIGEgZXVwaGVtaXNtOiB0aGUgc2Vy dmVyIGluZm9ybXMgdGhlIGNsaWVudCB3aGV0aGVyIGl0IG11c3Qgc2VuZCBhIGNvbm5lY3Rpb24g SUQsIHByb2JhYmx5IGVuY3J5cHRlZCwgYW5kIG5vYm9keSBuZWVkcyBhbnkgZmxhZ3MsIHVubGVz cyB0aGUgcHJlc2VuY2Ugb2YgY29ubmVjdGlvbiBJRCBjaGFuZ2VzIHRoZSBvZmZzZXRzIG9mIGZp ZWxkcyB3ZSAqZG8qIHdhbnQgdG8gZXhwbGljaXRseSBleHBvc2UsIHN1Y2ggYXMgcGFja2V0IG51 bWJlciBlY2hvIChodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8y NjkpIG9yIHRyb3VibGVzaG9vdGluZyBmbGFncyAoaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy9pc3N1ZXMvMjc5KS4NCj4NCj4gTm90IHRvIHB1dCB0b28gZmluZSBhIHBvaW50 IG9uIGl0LCBidXQgdGhlcmUncyBmYXIgZnJvbSBjb25zZW5zdXMgdGhhdCB3ZSB3YW50IHRvIGV4 cG9zZQ0KPiBlaXRoZXIgb2YgdGhlc2UuDQoNClRoYXQncyBub3QgdG9vIGZpbmUgYSBwb2ludCBh dCBhbGw7IEknbSBub3QgcHJlc3VwcG9zaW5nIGNvbnNlbnN1cyBvbiBlaXRoZXIgb2YgdGhlc2Uu IEFsbCBJJ20gc2F5aW5nIGhlcmUgaXMsIHNob3VsZCBjb25zZW5zdXMgZW1lcmdlIHRoYXQgdGhl IGJlbmVmaXRzIG91dHdlaWdoIHRoZSBjb3N0cyAoYm90aCBpbiBjb21wbGV4aXR5IGFuZCBpbiBy aXNrKSBmb3IgY2VydGFpbiBraW5kcyBvZiBleHBvc3VyZSB0byB0aGUgcGF0aCAtLSB3aGljaCBJ IHRoaW5rIG1heSBiZSB0aGUgY2FzZSBmb3Igc29tZSBvZiB0aGUgdGhpbmdzIHVuZGVyIGRpc2N1 c3Npb24gaW4gMjc5LCBhbmQgSSdtIG9idmlvdXNseSBjb252aW5jZWQgb2YgdGhlIHV0aWxpdHkg b2YgcGFja2V0IG51bWJlciBlY2hvIGFzIGluIDI2OSBvciBJIHdvdWxkbid0IGhhdmUgc3VibWl0 dGVkIHR3byBQUnMgb24gaXQgLS0gd2UgbmVlZCB0byBiZSBjbGVhciB0aGF0IG90aGVyIGNob2lj ZXMgd2UgbWFrZSBhYm91dCB0aGUgbGF5b3V0IG9mIHRoZSBoZWFkZXIgZG9lc24ndCBtYWtlIHRo YXQgaGFyZGVyIHRoYW4gaXQgbmVlZHMgdG8gYmUuIFN0aWNraW5nIHZhcmlhYmxlLWxlbmd0aC9v cHRpb25hbCBmaWVsZHMgd2hvc2UgcHJlc2VuY2UgaXMgZGVwZW5kZW50IG9uIGVuZHBvaW50LXNo YXJlZCBzdGF0ZSBhZnRlciB0aGUgZXhwb3NlZCBmaWVsZHMgaXMgcHJvYmFibHkgc3VmZmljaWVu dCBmb3IgdGhpcy4NCg0KDQpDaGVlcnMsDQoNCkJyaWFuDQoNCg0KDQoNCg0K --_000_E8355113905631478EFF04F5AA706E9870544050wtlexchp1sandvi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u Z21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLW0tNjQzNDQ0MjQ4 ODY2NDg1MTIyMG0tMjYyNDY1OTM3NzU4Mjg3NzAyM203NTM3NzAwMTI0OTkzODk4MzY1aG9lbnpi DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTY0MzQ0NDI0ODg2NjQ4NTEyMjBtXy0yNjI0NjU5 Mzc3NTgyODc3MDIzbV83NTM3NzAwMTI0OTkzODk4MzY1aG9lbnpiO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmZ3Q7DQo8L3NwYW4+SSd2ZSBu b3QgdGhvdWdodCAob3Iga25vdykgYWJvdXQgYWxsIHRoZSB0aGluZ3MgdGhhdCB3b3VsZCBicmVh ayBpZiB0aGUgbm90aW9uIG9mIGZsb3cgd2FzIG9ibGl0ZXJhdGVkIGZyb20gcHVibGljIHZpZXcu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkNhbiB3ZSBkaXNjdXNzIGl0IGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZHJhZnQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtZG9sc29uLXBsdXMtbWlkZGxlYm94LWJlbmVmaXRzLTAxLnR4dCI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1kb2xzb24tcGx1cy1taWRkbGVib3gtYmVuZWZpdHMtMDEu dHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoZSB0aGluZ3Mg dGhhdCBtaWdodCBicmVhayBpZiB2YXJpb3VzIHRyYW5zcG9ydC1sYXllciBpbmZvIGlzIG5vdCBw cm92aWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlcmXigJlzIHBhcnQgb2YgdGhlIHRhYmxlIG9mIGNvbnRlbnRz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAyLiZu YnNwOyBNZWFzdXJlbWVudHMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4xLiZu YnNwOyBQYWNrZXQgTG9zcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4mbmJzcDsmbmJzcDsgNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4yLiZuYnNwOyBSb3Vu ZCBUcmlwIFRpbWVzJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiZuYnNwOyZuYnNwOyA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjMuJm5ic3A7IE1lYXN1cmlu ZyBQYWNrZXQgUmVvcmRlcmluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZu YnNwOyA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyLjQuJm5ic3A7IFRocm91Z2hwdXQgYW5kIEJv dHRsZW5lY2sgSWRlbnRpZmljYXRpb24mbmJzcDsgLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7 IDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIuNS4mbmJzcDsgRERvUyBEZXRlY3Rpb24mbmJzcDsg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMi42LiZuYnNwOyBQYWNrZXQgQ29ycnVwdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMi43LiZuYnNwOyBBcHBsaWNhdGlvbi1MYXllciBNZWFzdXJlbWVudHMmbmJz cDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAzLiZu YnNwOyBBY3Rpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuMS4mbmJzcDsg TkFUIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu Jm5ic3A7Jm5ic3A7IDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuMi4mbmJzcDsgRmlyZXdhbGwm bmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJz cDsmbmJzcDsgNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMy4zLiZuYnNwOyBERG9TIFNjcnViYmlu ZyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZu YnNwOyA3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjQuJm5ic3A7IFBlcmZvcm1hbmNlLUVuaGFu Y2luZyBQcm94aWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA4PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAzLjUuJm5ic3A7IEJhbmR3aWR0aCBBZ2dyZWdhdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAzLjYuJm5ic3A7IFByaW9yaXRpemF0aW9uJm5ic3A7IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDMuNy4mbmJzcDsgTWVhc3VyZW1lbnQtQmFzZWQgU2hhcGluZyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIE1hcmNoIDA5LCAyMDE3IDI6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEVy aWMgUmVzY29ybGE8YnI+DQo8Yj5DYzo8L2I+IEJyaWFuIFRyYW1tZWxsOyBJRVRGIFFVSUMgV0c8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE1pZGRsZWJveCBpbnRyb3NwZWN0aW9uL3NlbGYtZGVz Y3JpYmluZyBwYWNrZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgbm90PyBJdCdzIGEgY29ubmVjdGlvbiBp ZGVudGlmaWVyLCBsaWtlIHRoZSBUQ1AgNC10dXBsZS4gV2hhdCBkbyB5b3UgZ2FpbiBmcm9tIG1p ZGRsZWJveGVzIG5vdCB1c2luZyB0aGUgY29ubmVjdGlvbiBJRCB0byBpZGVudGlmeSBjb25uZWN0 aW9ucz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVhaCwgSSB3aXNoIHRo ZXkgd291bGRuJ3QgdXNlIHRoZSA0LXR1cGxlIGVpdGhlci4gSW4gZmFjdCBtdWNoIG9mIHRoaXMg Y29udmVyc2F0aW9uIGlzIGRyaXZlbiBieSB0aGVtIGRvaW5nIG5vbnNlbnNlIGJhc2VkIG9uIHRo ZSA0LXR1cGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3Rh bmQgbm93LiBGV0lXLCB0aGUgc3R1ZmYgdGhleSBkbywgdXNpbmcgNC10dXBsZXMsIGluY2x1ZGVz IEFRTSAoc2VlIEZRLUNvRGVsKS4uLiAmbmJzcDtzb21lIG9mIHRoZXNlIHRoaW5ncyBhcmUgdXNl ZnVsLiBJJ20gbm90IHNheWluZyB0aGF0J3MgdGhlIG9ubHkgd2F5IHRvIGRvIGl0LCBhbmQgSSd2 ZSBub3QgdGhvdWdodCAob3Iga25vdykgYWJvdXQgYWxsIHRoZSB0aGluZ3MgdGhhdCB3b3VsZCBi cmVhaw0KIGlmIHRoZSBub3Rpb24gb2YgZmxvdyB3YXMgb2JsaXRlcmF0ZWQgZnJvbSBwdWJsaWMg dmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGRv bid0IGhhdmUgYSBiaXQsIHlvdSBjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBMb29rIHVwIHRoZSBob3N0L3BvcnQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSWYgaXQncyBtaXNzaW5n IGFzc3VtZSB0aGF0IHRoZXJlIGlzIGEgY29ubmVjdGlvbiBJRCBhbmQgbG9vayBmb3IgaXQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSWYgdGhh dCdzIG1pc3NpbmcsIGRyb3AgdGhlIHBhY2tldDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ZZXMsIEkgd2FzIHJlc3BvbmRpbmcgdG8gQnJpYW4ncyBlbWFpbCAtLSBhcG9sb2dp ZXMgZm9yIGNyb3NzaW5nIHRoZSB3aXJlcyBhIGJpdC4gVGhpcyBtZXRob2QgaXMgcGxhdXNpYmxl LCBidXQgaXQgaW5jcmVhc2VzIHRoZSB3b3JrIHBlciBwYWNrZXQgYXQgbG9hZCBiYWxhbmNlcnMg YnkgfjJ4LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgcmVh bGx5LCBiZWNhdXNlIHlvdSBjYW4gY2hlY2sgaW4gZWl0aGVyIG9yZGVyLCBzbyB1bmxlc3MgaXQn cyA1MC81MCB5b3UgdXN1YWxseSBnZXQgdGhlIGZhc3QtcGF0aC4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BY3R1YWxseSwgbm8sIEknbSBub3QgcGVyc3VhZGVkIGJ5IHRoaXMgYXMg eWV0LiBJIGFncmVlIHdpdGggdGhlIHN0YXRlbWVudCB0aGF0IE5BVHMga2lsbCB0aGVzZSBiaW5k aW5nczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZmFzdGVyLCBidXQgaXQncyBub3QgeWV0IGNsZWFyIHRvIG1lIHRoYXQgY29ubmVjdGlvbiBJRHMg YW1lbGlvcmF0ZSB0aGVzZSBwcm9ibGVtcyBzdWZmaWNpZW50bHkgdG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmltcHJvdmUgdGhlIHNpdHVhdGlv bi4gSSdkIGJlIGhhcHB5IHRvIHNlZSBhbnkgZGF0YSB5b3UgaGF2ZSB0aGF0IHN1cHBvcnRzIHRo aXMgcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgZm9s bG93LiBJIHRoaW5rIHlvdSdyZSBhZ3JlZWluZyB3aXRoIHdoYXQgSSBzYWlkIGFib3ZlLCB0aGF0 IE5BVCByZWJpbmRpbmdzIGhhcHBlbiBmYXN0ZXIgZm9yIFVEUC4mbmJzcDsgQSBRVUlDIHBhY2tl dCBwb3N0LXJlYmluZGluZyBmb3IgdGhlIHNhbWUgY29ubmVjdGlvbiBjYXJyaWVzIHRoZSBzYW1l IGNvbm5lY3Rpb24gSUQsIHdoaWNoIGxlYWRzIGl0IGJhY2sgdG8gdGhlIHNhbWUgc2VydmVyIGV2 ZW4NCiBpZiBhIE5BVCByZWJpbmRpbmcgaGFwcGVuZWQuIFdoeSBkbyB5b3UgdGhpbmsgY29ubmVj dGlvbiBJRHMgZG9uJ3QgYW1lbGlvcmF0ZSB0aGlzIHByb2JsZW0gKG9mIE5BVCByZWJpbmRpbmdz IGhhcHBlbiBmYXN0ZXIgZm9yIFVEUCkgc3VmZmljaWVudGx5PyBJbiBvdGhlciB3b3Jkcywgd2hh dCBwaWVjZSBvZiB0aGlzIHByb2JsZW0gZG9lcyBjb25uZWN0aW9uIElEIG5vdCBzb2x2ZT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gQW55dGhpbmcgd2hlcmUgaXQncyB0 aGUgc2VydmVyIHNwZWFraW5nIGZpcnN0IGFmdGVyIHRoZSByZWJpbmQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBTaXR1YXRpb25zIHdoZXJl IHRoZSBzZXJ2ZXIgb3IgY2xpZW50IHdvdWxkIGhhdmUgR0NlZCB0aGUgc3RhdGUgYW55d2F5LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkknbSBsb29raW5nIGZvciBkYXRhIHRoYXQgaW5kaWNhdGVzIHRoYXQg dGhlIHJlbWFpbmluZyBjYXNlcyBhcmUgY29tbW9uIGVub3VnaCB0byBiZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW1wb3J0YW50IGVub3VnaCB0 byB0YWtlIHRoZSBwcml2YWN5IGhpdC4gQXMgSSBzYWlkIGluIG15IHJlc3BvbnNlIHRvIElhbiwg SSdsbCB0cnkgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmZpZ3VyZSBvdXQgYSBtb3JlIHByZWNpc2UgZnJhbWluZyBvZiB0aGUgZGF0YSB0aGF0 IEkgd291bGQgZmluZCBwZXJzdWFzaXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF0J2QgYmUgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSdkIGFsbCBhZ3JlZSB0aGF0 IGNvbm5lY3Rpb24gSUQgdXNlIGFjcm9zcyBjbGllbnQgbmV0d29yayBjaGFuZ2VzIGlzIGEgbmV3 IGJlYXN0LiBUbyB0aGlzIGVuZCwgSSB0aGluayB3ZSd2ZSBnZW5lcmFsbHkgYWdyZWVkIChpbmZv cm1hbGx5IGFueXdheXMpIHRoYXQgdGhlIGNsaWVudCBtdXN0IHVzZSBhIG5ldyBjb25uZWN0aW9u IElEIHdoZW4gaXQgdHJpZ2dlcnMgY29ubmVjdGlvbiBtaWdyYXRpb24gdG8gYQ0KIGRpZmZlcmVu dCBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRpZmZpY3VsdHkgaXMg dGhhdCB3ZSBkbyBub3QgcHJlc2VudGx5IGtub3cgaG93IHRvIGFycmFuZ2UgdGhhdCB5b3UgYWx3 YXlzIHVzZSBhIG5ldyBjb25uIGlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5vbiBtaWdyYXRpb24gd2l0aG91dCB1c2luZyBhIG5ldyBjb25uIGlk IG9uIGVhY2ggcGFja2V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0 J3Mgbm90IHRydWUuIFdlIGNhbiBhcnJhbmdlIGZvciBhbiBhY3RpdmUgY2xpZW50LWRyaXZlbiBt aWdyYXRpb24gdG8gdXNlIGEgbmV3IGNvbm5lY3Rpb24gSUQuIEl0J3MgdGhlIE5BVCByZWJpbmRp bmcgY2FzZSB0aGF0IHdlIGNhbid0IGhhbmRsZSB3aXRob3V0IGEgbmV3IGNvbm5lY3Rpb24gSUQg cGVyIHBhY2tldC4gVGhlIHJlYXNvbiBJIHNlcGFyYXRlZCB0aGUgY29ubmVjdGlvbiBJRCBxdWVz dGlvbg0KIGludG8gTkFUIHJlYmluZGluZyB2cyBjbGllbnQgbWlncmF0aW9uIHdhcyB0byBhbHNv IHNlcGFyYXRlIHRoZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGZvciB0aGVzZSB0d28gY2FzZXMu IFdoaWxlIHRoZXJlJ3MgYSByZWFsIGNvbmNlcm4gb2YgcHJpdmFjeSBsZWFrYWdlIGFjcm9zcyBh Y3RpdmUgY2xpZW50IG1pZ3JhdGlvbnMsIHByaXZhY3kgbGVha2FnZSBkdWUgdG8gYSBzdGFibGUg Y29ubmVjdGlvbiBJRCBhY3Jvc3MgTkFUIHJlYmluZGluZ3MNCiBpcyBub3QgZGlmZmVyZW50IHRo YW4gdGhhdCBkdWUgdG8gYSBzdGFibGUgVENQIGNvbm5lY3Rpb24gZm9yIHRoZSBzYW1lIGR1cmF0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgcGxlbnR5 IG9mIHRpbWVzIHdoZW4gdGhlIGNsaWVudCBkb2VzIGEgbmV0d29yayBjaGFuZ2UgYnV0IGRvZXNu J3Qga25vdyBpdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+aGFzLiBUZXRoZXJpbmcgaXMgb25lIGV4YW1wbGUuIEluIHN1Y2ggY2FzZXMsIGNvbnRp bnVpbmcgdG8gdXNlIHRoZSBzYW1lIGNvbm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklEIHByZXNlbnRzIGEgcHJpdmFjeSB0aHJlYXQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXRoZXJpbmcgY2FzZSBp cyByZWFsLCBidXQgaXQncyBhIGNvcm5lciBjYXNlOyBjb25uZWN0aW9uIG1pZ3JhdGlvbnMgYXJl IGRvbWluYXRlZCBieSB1bnRldGhlcmVkIGNsaWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgTWFyIDksIDIwMTcgYXQgODowOSBBTSwgQnJpYW4gVHJhbW1lbGwgJmx0OzxhIGhy ZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkB0cmFtbWVs bC5jaDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5oaSBFa3IsIGFsbCw8YnI+DQo8YnI+DQomZ3Q7 ICZndDsgV2VsbCwgd2l0aCBuZWdvdGlhdGlvbiwgc29tZW9uZSBoYXMgdG8gZGVjaWRlLiBUaGUg Yml0IGp1c3QgbW92ZXMgdGhhdCB0byB0aGUgY2xpZW50Ljxicj4NCiZndDsgJmd0OyBFeGNlcHQg dGhhdCBpZiB0aGUgbG9hZCBiYWxhbmNlciAqbmVlZHMqIGl0LCB0aGVuIHRoZSBjbGllbnQgaGFz IHRvIGNvbmZvcm0uPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBsb2FkIGJhbGFuY2VyIG5l ZWRzIGl0IHRvIGJhbGFuY2UgbG9hZCBlZmZpY2llbnRseS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsgVGhhdCdzIG5vdCBlbnRpcmVseSBjbGVhci4gTm90ZSB0aGF0IGluIHRoZSBvcmlnaW5hbCBR VUlDIGRlc2lnbiwgdGhlIGNsaWVudCBzdXBwbGllZDxicj4NCiZndDsgdGhlIGNvbm5lY3Rpb24g SUQsIHNvIHRoZSBzZXJ2ZXIgc2lkZSBtZXJlbHkgaGFkIHRvIGxvYWQgYmFsYW5jZSBiYXNlZCBv biBzb21lIGNvbWJpbmF0aW9uPGJyPg0KJmd0OyBvZiBhIHJhbmRvbSB2YWx1ZSBhbmQgdGhlIGNs aWVudCdzIElQLjxicj4NCjxicj4NClJpZ2h0OyBzaG91bGQgaGF2ZSBzYWlkIHRoYXQgJnF1b3Q7 dGhlIGFzc2VydGlvbiBiZWhpbmQgc2VydmVyLXN1Z2dlc3RlZCBDb25uZWN0aW9uIElEIHByb3Bv c2FsIGlzIHRoYXQgaXQncyBuZWVkZWQgZm9yIGVmZmljaWVudCBsb2FkIGJhbGFuY2luZyZxdW90 Oy4gSSdtIHRha2luZyB0aGF0IGFzc2VydGlvbiBhdCBmYWNlIHZhbHVlIG5vdywgcG9zc2libHkg YmVjYXVzZSBJJ20gY29udmluY2VkIG9mIHRoZSB1dGlsaXR5IG9mIG9uZSBvZiBpdHMgc2lkZS1l ZmZlY3RzOg0KIHByb3ZpZGluZyBzb21lIGFkZGl0aW9uYWwgZ3JhZGUgb2YgYXNzdXJhbmNlIHRv IGEgZGV2aWNlIG9uIHBhdGggdGhhdCBhIGdpdmVuIHBhY2tldCB3YXMgbm90IGluamVjdGVkIG9m Zi1wYXRoLCB3aGljaCBpcyB1c2VmdWwgaW4gaW4tbmV0d29yayBEb1MgbWl0aWdhdGlvbiAoYXMg aW4gc2VjdGlvbiAzLjMgb2YgdGhlIGp1c3Qtc3VibWl0dGVkIG1hbmFnZWFiaWxpdHkgZHJhZnQp Ljxicj4NCjxicj4NCiZndDsmZ3Q7IEkgcHJlc3VtZSB0aGF0IGEgY2xpZW50IHRoYXQgd2FzIHZl cnkgaW50ZXJlc3RlZCBpbiBub3QgcHJvdmlkaW5nIHRyYWNraW5nIGluZm9ybWF0aW9uIGNvdWxk IHJlZnVzZSB0byBtYWtlIENvbm5lY3Rpb24gSUQgYXZhaWxhYmxlLCBhdCB0aGUgY29zdCBvZiBk ZWdyYWRlZCBwZXJmb3JtYW5jZS48YnI+DQo8YnI+DQooSSB3b3VsZCBsaWtlIHRvIHJlaXRlcmF0 ZSB0aGF0IEkgZG8gdGhpbmsgdGhhdCBpdCdzIG5lY2Vzc2FyeSB0byBhbGxvdyBjbGllbnRzIHRv IHZldG8gc2VydmVyLXByb3Bvc2VkIGNvbm5lY3Rpb24gSUQgZXhwb3N1cmUuKTxicj4NCjxicj4N CiZndDsmZ3Q7IChmIHRoYXQncyBub3QgdGhlIGNhc2UsIGlmIGZhaWx1cmUgdG8gc2VuZCBjb25u ZWN0aW9uIElEIGxlYWRzIHRvIGNvbm5lY3Rpb24gZmFpbHVyZSwgdGhlbiAmcXVvdDtuZWdvdGlh dGlvbiZxdW90OyBpcyBhIGV1cGhlbWlzbTogdGhlIHNlcnZlciBpbmZvcm1zIHRoZSBjbGllbnQg d2hldGhlciBpdCBtdXN0IHNlbmQgYSBjb25uZWN0aW9uIElELCBwcm9iYWJseSBlbmNyeXB0ZWQs IGFuZCBub2JvZHkgbmVlZHMgYW55IGZsYWdzLCB1bmxlc3MgdGhlIHByZXNlbmNlDQogb2YgY29u bmVjdGlvbiBJRCBjaGFuZ2VzIHRoZSBvZmZzZXRzIG9mIGZpZWxkcyB3ZSAqZG8qIHdhbnQgdG8g ZXhwbGljaXRseSBleHBvc2UsIHN1Y2ggYXMgcGFja2V0IG51bWJlciBlY2hvICg8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8yNjkiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy8yNjk8 L2E+KSBvciB0cm91Ymxlc2hvb3RpbmcNCiBmbGFncyAoPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjc5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvMjc5PC9hPikuPGJyPg0KJmd0 Ozxicj4NCiZndDsgTm90IHRvIHB1dCB0b28gZmluZSBhIHBvaW50IG9uIGl0LCBidXQgdGhlcmUn cyBmYXIgZnJvbSBjb25zZW5zdXMgdGhhdCB3ZSB3YW50IHRvIGV4cG9zZTxicj4NCiZndDsgZWl0 aGVyIG9mIHRoZXNlLjxicj4NCjxicj4NClRoYXQncyBub3QgdG9vIGZpbmUgYSBwb2ludCBhdCBh bGw7IEknbSBub3QgcHJlc3VwcG9zaW5nIGNvbnNlbnN1cyBvbiBlaXRoZXIgb2YgdGhlc2UuIEFs bCBJJ20gc2F5aW5nIGhlcmUgaXMsIHNob3VsZCBjb25zZW5zdXMgZW1lcmdlIHRoYXQgdGhlIGJl bmVmaXRzIG91dHdlaWdoIHRoZSBjb3N0cyAoYm90aCBpbiBjb21wbGV4aXR5IGFuZCBpbiByaXNr KSBmb3IgY2VydGFpbiBraW5kcyBvZiBleHBvc3VyZSB0byB0aGUgcGF0aCAtLSB3aGljaCBJDQog dGhpbmsgbWF5IGJlIHRoZSBjYXNlIGZvciBzb21lIG9mIHRoZSB0aGluZ3MgdW5kZXIgZGlzY3Vz c2lvbiBpbiAyNzksIGFuZCBJJ20gb2J2aW91c2x5IGNvbnZpbmNlZCBvZiB0aGUgdXRpbGl0eSBv ZiBwYWNrZXQgbnVtYmVyIGVjaG8gYXMgaW4gMjY5IG9yIEkgd291bGRuJ3QgaGF2ZSBzdWJtaXR0 ZWQgdHdvIFBScyBvbiBpdCAtLSB3ZSBuZWVkIHRvIGJlIGNsZWFyIHRoYXQgb3RoZXIgY2hvaWNl cyB3ZSBtYWtlIGFib3V0IHRoZSBsYXlvdXQgb2YNCiB0aGUgaGVhZGVyIGRvZXNuJ3QgbWFrZSB0 aGF0IGhhcmRlciB0aGFuIGl0IG5lZWRzIHRvIGJlLiBTdGlja2luZyB2YXJpYWJsZS1sZW5ndGgv b3B0aW9uYWwgZmllbGRzIHdob3NlIHByZXNlbmNlIGlzIGRlcGVuZGVudCBvbiBlbmRwb2ludC1z aGFyZWQgc3RhdGUgYWZ0ZXIgdGhlIGV4cG9zZWQgZmllbGRzIGlzIHByb2JhYmx5IHN1ZmZpY2ll bnQgZm9yIHRoaXMuPGJyPg0KPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkJyaWFuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E8355113905631478EFF04F5AA706E9870544050wtlexchp1sandvi_-- From nobody Thu Mar 9 13:56:41 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AC8129443 for ; Thu, 9 Mar 2017 13:56:40 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=RPRiI6nf; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=qurc8cMB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZuja_0ks5Mp for ; Thu, 9 Mar 2017 13:56:36 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E26C1294D4 for ; Thu, 9 Mar 2017 13:56:36 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id B26C515A0E68; Thu, 9 Mar 2017 22:56:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489096594; bh=Oovp43GfRyXOsOuQ9gFu+26DuDvPf2YO5TaNqtoBkJ0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=RPRiI6nf+QAfebpcPFJiScZFinTdLmuUFRy9Mz9MOYrYizrpvp+vaUnG1w34DQxjo 8WFvDCA+yXflAkZg4V+DhTixaxgPPVStHlQsg4dHfyYH+QQFHRj1AQnl+6wl+WERIx H5GbmgCHJrB6d5am+j9fv5Wft95lxXmEVyqOX3wo= Received: from [192.168.178.54] (unknown [93.211.96.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 7163D15A05F9; Thu, 9 Mar 2017 22:56:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489096593; bh=Oovp43GfRyXOsOuQ9gFu+26DuDvPf2YO5TaNqtoBkJ0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=qurc8cMB3no2kaiYIh9MWB8Fr62vxVaefKgM7CLYZw55B/HgcMEqvRhyliRHA8oB9 YYjO9dZb14Ss4mJG19EYrTgUJD1lohIwwjePKiLOe/TN1aTik5d6lhOALOH1u3m6Sx MayyihTv9IQDpVXKtODSSGx6eUPTSSJsqEjkUcK4= Content-Type: multipart/alternative; boundary=Apple-Mail-5151FBD6-E6AE-48D4-9756-F5B76DDB1D8C Mime-Version: 1.0 (1.0) Subject: Re: Divergence from HTTP/2 From: Stefan Eissing X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 9 Mar 2017 22:56:32 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0A814D18-F9D9-4901-B588-6F99A84E6088@greenbytes.de> References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> To: Patrick McManus Archived-At: Cc: Mike Bishop , Ian Swett , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 21:56:40 -0000 --Apple-Mail-5151FBD6-E6AE-48D4-9756-F5B76DDB1D8C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think registering frame types and whatnot as a new protocol for carrying h= ttp semantics is wise. Keeping frame names/numbers with same semantics is go= od for it can ease understanding, it is not mandatory.=20 I would hope that new frame types can be deployed in http/2 without also res= erving them in hq (and vice versa). Otherwise the burden for people making e= xtensions might be unnecessarily high. As an implementor, the question is how to make the abstractions work inside a= product supposed to support several transports for http applications. but t= hat is outside the scope of the WGs and maybe rightly so. Interestig times. -stefan > Am 09.03.2017 um 19:21 schrieb Patrick McManus : >=20 > Mike, I think it would be good if you resent the question - particularly t= he bit about registries - in a new email with full background to both the qu= ic and httpbis lists... That community might have opinions as well and QUIC w= g is chartered explicitly to work closely with them. >=20 > my opinion has solidified over time to the "separate protocols but same se= mantics (i.e. hq=3D=3Dh3)" position - esp wrt qpack which I think will be ve= ry valuable for hq. >=20 > -P >=20 >=20 >> On Thu, Mar 9, 2017 at 10:59 AM, Mike Bishop wrote: >> To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to c= ontort the IANA registry to claim these are two variants of the same protoco= l, or do we just tell IANA they=E2=80=99re different protocols with differen= t registries? I don=E2=80=99t see that one choice implies a larger scope th= an the other. I think the mission is still the same =E2=80=93 deliver HTTP s= emantics over QUIC. >>=20 >> =20 >>=20 >> We=E2=80=99ve already decided we=E2=80=99re willing to make a number of d= epartures from HTTP/2 because it makes technical sense in each individual ca= se. Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional= streams in each direction) the HTTP mapping would do likewise in response (= see branch unidirectional2). >>=20 >> =20 >>=20 >> From: Ian Swett [mailto:ianswett@google.com]=20 >> Sent: Thursday, March 9, 2017 6:28 AM >> To: Stefan Eissing >> Cc: Mike Bishop ; quic@ietf.org >> Subject: Re: Divergence from HTTP/2 >>=20 >> =20 >>=20 >> Thanks for sending this out to the list. I always hoped we could keep HT= TP over QUIC as similar to H2 as possible, but as you've pointed out previou= sly, a lot of HTTP/2 was adding transport features such as multiple streams a= nd flow control on top of an existing transport. Switching to QPACK would b= e another dramatic departure. >>=20 >> =20 >>=20 >> I'm not excited about QUIC abandoning HTTP2, but it may make enough techn= ical and documentation sense to be the right thing to do. I am concerned th= is could expand the scope of the HTTP mapping too much, so if we're going to= make this choice, I'd like to know what types of changes are in scope.=20 >>=20 >> =20 >>=20 >> On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing wrote: >>=20 >> Thanks for separating this out, Mike. For spare time folks this makes fol= lowing this aspect easier. >>=20 >> =20 >>=20 >> My first impression is that any hope to have http/2 over tcp and quic nee= ds to be abandoned. Which will give the world a third protocol to carry http= semantics. >>=20 >> =20 >>=20 >> What does that mean for the evolution of http, I wonder. >>=20 >> =20 >>=20 >> -stefan >>=20 >>=20 >> Am 09.03.2017 um 03:16 schrieb Mike Bishop = : >>=20 >> At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are the same protocol. However, the draft currently still attempts to d= efine them as close cousins. In PR #363, I=E2=80=99ve consolidated almost a= ll of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new section an= d excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn= =E2=80=99t need it=E2=80=9D from the main body of the document. Martin has a= dvocated making a clean break from HTTP/2 and defining our own IANA registry= for frame types and settings, just as we already have for errors. We can, o= ut of respect for legacy, use the same values where appropriate and reserve e= xisting values currently in use on the HTTP/2 side. >>=20 >> =20 >>=20 >> I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step f= rom the current state of #363. I=E2=80=99ve created PR #376 to actually mak= e that split. >>=20 >> =20 >>=20 >> Comments from the WG about either would be welcome. >>=20 >> =20 >>=20 >=20 --Apple-Mail-5151FBD6-E6AE-48D4-9756-F5B76DDB1D8C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think registering frame t= ypes and whatnot as a new protocol for carrying http semantics is wise. Keep= ing frame names/numbers with same semantics is good for it can ease understa= nding, it is not mandatory. 

I would hope that= new frame types can be deployed in http/2 without also reserving them in hq= (and vice versa). Otherwise the burden for people making extensions might b= e unnecessarily high.

As an implementor, the questi= on is how to make the abstractions work inside a product supposed to support= several transports for http applications. but that is outside the scope of t= he WGs and maybe rightly so.

Interestig times.

-stefan

Am 09.03.2017 um 19:21= schrieb Patrick McManus <pmcmanu= s@mozilla.com>:

Mike, I think it would be good if you resent the question - parti= cularly the bit about registries - in a new email with full background to bo= th the quic and httpbis lists... That community might have opinions as well a= nd QUIC wg is chartered explicitly to work closely with them.

<= div>my opinion has solidified over time to the "separate protocols but same s= emantics (i.e. hq=3D=3Dh3)" position - esp wrt qpack which I think will be v= ery valuable for hq.

-P


On Thu, Mar 9, 2017 at 10:59 AM, M= ike Bishop <Michael.Bishop@microsoft.com> wrote:

To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to contort the IANA r= egistry to claim these are two variants of the same protocol, or do we just t= ell IANA they=E2=80=99re different protocols with different registries? = ; I don=E2=80=99t see that one choice implies a larger scope than the other.  I think the mission is still the same =E2=80=93 deliv= er HTTP semantics over QUIC.

 

We=E2=80=99ve already decided we=E2=80=99re willing t= o make a number of departures from HTTP/2 because it makes technical sense i= n each individual case.  Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each direction) the HTTP map= ping would do likewise in response (see branch unidirectional2).

 

From: Ian Swett [mailto:ianswett@google.com]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org
Subject: Re: Divergence from HTTP/2

 

Thanks for sending this out to the list.  I alwa= ys hoped we could keep HTTP over QUIC as similar to H2 as possible, but as y= ou've pointed out previously, a lot of HTTP/2 was adding transport features s= uch as multiple streams and flow control on top of an existing transport.  Switching to QPACK would be another d= ramatic departure.

 

I'm not excited about QUIC abandoning HTTP2, but it m= ay make enough technical and documentation sense to be the right thing to do= .  I am concerned this could expand the scope of the HTTP mapping too m= uch, so if we're going to make this choice, I'd like to know what types of changes are in scope. 

 

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <stefan.eissi= ng@greenbytes.de> wrote:

Thanks for separating this out, Mike. For spare time f= olks this makes following this aspect easier.

 

My first impression is that any hope to have http/2 o= ver tcp and quic needs to be abandoned. Which will give the world a third pr= otocol to carry http semantics.

 

What does that mean for the evolution of http, I wond= er.

 

-stefan


Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:

At this point, I don=E2=80=99t think anyone expects t= hat HTTP/QUIC and HTTP/2 are the same protocol.  However, the draft cur= rently still attempts to define them as close cousins.  In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdifferent= from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff abo= ut =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80=9D f= rom the main body of the document.  Martin has advocated making a clean br= eak from HTTP/2 and defining our own IANA registry for frame types and setti= ngs, just as we already have for errors.  We can, out of respect for le= gacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.<= /u>

 

I think that=E2=80=99s a good idea, and it=E2=80=99s a= fairly small step from the current state of #363.  I=E2=80=99ve create= d PR #376 to actually make that split.

 

Comments from the WG about either would be welcome.

 


= --Apple-Mail-5151FBD6-E6AE-48D4-9756-F5B76DDB1D8C-- From nobody Thu Mar 9 14:01:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBB112946D for ; Thu, 9 Mar 2017 14:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 QsjXOtjV03WJ for ; Thu, 9 Mar 2017 14:01:02 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E771294D4 for ; Thu, 9 Mar 2017 14:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7151; q=dns/txt; s=iport; t=1489096862; x=1490306462; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=0FTPcoFEsBb9dHJaCR+4W16JfB3BRNrfXwBVZ7gssHA=; b=JNqdLd1L+BfoMcYBWTHhbqXXLTQiQnVraH2ZHEOEo1ZORw6/m4Oru6Va tP+hjWMghL5GvR5FmmISXfvM693tg6W8rMCOIc3++3DoM4nJ8OFBrvKTZ ODpztnPty8/03hW6NHHJmSiiEedt8F0hFb2kIXa/WyP6HSVVV6Ax7fbkR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AwD8z8FY/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKgdZg2CbW5ALhS2CDiqFeAKCMUAXAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?DAiNWEAsOCicDAgJGEQYBDAYCAQEXiVgNDrEpgiYrij0BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZOggWCaodagl8FkFeFI4Y/hnaCYYhhik+GUY8fhCAgATaBAzc?= =?us-ascii?q?fFYRaglciNQGKKgEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208,217";a="489619" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 22:01:01 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v29M10Ap002651; Thu, 9 Mar 2017 22:01:00 GMT Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla , Stephen Farrell References: <9a582259-b258-30d6-3cfd-92d75c3460ab@zinks.de> <1f76148a-5688-a54f-fe3c-07405e738d6d@cs.tcd.ie> From: Flemming Andreasen Message-ID: <6a92d28b-9cd4-d71d-e7f1-97ae09889b79@cisco.com> Date: Thu, 9 Mar 2017 17:01:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BFCAB67957635420D6F414E2" Archived-At: Cc: IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 22:01:04 -0000 This is a multi-part message in MIME format. --------------BFCAB67957635420D6F414E2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/9/17 10:07 AM, Eric Rescorla wrote: > > On Thu, Mar 9, 2017 at 6:56 AM, Stephen Farrell > > wrote: > > > > On 09/03/17 14:36, Eric Rescorla wrote: > > aren't it), though there's some interesting work coming out of > Stanford [0] > > that > > tries to address this. > > > > -Ekr > > > > [0] https://forum.stanford.edu/events/2016/slides/iot/Judson.pdf > > > > > It's very unclear to me that it's possible to usefully > take a two party protocol like TLS and change it into a > multiparty protocol without fatal side-effects. As the > slide deck [0] notes for example, those "auditors" get > access to all cookies/passwords etc. > > > Sorry, I should have been clearer that I wasn't endorsing this > strategy. That's > what the juxtaposition of "don't really have a good solution" with > "interesting > work" was intended to convey, but I guess I could have been more explicit. > I think there are a number of technical challenges here: > > - TLS is a fairly blunt tool that protects nothing or everything > - The Web has tended to do a really bad job of separating authentication > from confidentiality (and in general supplying authentication via > confidentiality > through various kinds of bearer tokens) > > I do think it's important that people keep thinking about it, because the > problem of devices that are nominally under your control being hard to > trust > is also serious. That doesn't mean that we currently have a good strategy > for solving it. > And even devices that could be "trusted" initially often end up being compromised (or affected otherwise, e.g. DoS'ed), often because they are not patched to remedy new/known vulnerabilities, and in many cases they never will be patched. If you accept that premise, then you find a role for some middleboxes (e.g FWs and IDS/IPS) to help here, and those boxes track "connections" (whether TCP or UDP today) and connection phases so they don't have to perform the same set of inspections and (slowpath) lookups on every single packet flowing through them. Having a readily available connection id would be helpful here. Thanks -- Flemming --------------BFCAB67957635420D6F414E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 3/9/17 10:07 AM, Eric Rescorla wrote:

On Thu, Mar 9, 2017 at 6:56 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 09/03/17 14:36, Eric Rescorla wrote:
> aren't it), though there's some interesting work coming out of Stanford [0]
> that
> tries to address this.
>
> -Ekr
>
> [0] https://forum.stanford.edu/events/2016/slides/iot/Judson.pdf
>

It's very unclear to me that it's possible to usefully
take a two party protocol like TLS and change it into a
multiparty protocol without fatal side-effects. As the
slide deck [0] notes for example, those "auditors" get
access to all cookies/passwords etc.

Sorry, I should have been clearer that I wasn't endorsing this strategy. That's
what the juxtaposition of "don't really have a good solution" with "interesting
work" was intended to convey, but I guess I could have been more explicit.
I think there are a number of technical challenges here:

- TLS is a fairly blunt tool that protects nothing or everything
- The Web has tended to do a really bad job of separating authentication
   from confidentiality (and in general supplying authentication via confidentiality
   through various kinds of bearer tokens)

I do think it's important that people keep thinking about it, because the
problem of devices that are nominally under your control being hard to trust
is also serious. That doesn't mean that we currently have a good strategy
for solving it.


And even devices that could be "trusted" initially often end up being compromised (or affected otherwise, e.g. DoS'ed), often because they are not patched to remedy new/known vulnerabilities, and in many cases they never will be patched. If you accept that premise, then you find a role for some middleboxes (e.g FWs and IDS/IPS) to help here, and those boxes track "connections" (whether TCP or UDP today) and connection phases so they don't have to perform the same set of inspections and (slowpath) lookups on every single packet flowing through them. Having a readily available connection id would be helpful here.

Thanks

-- Flemming









--------------BFCAB67957635420D6F414E2-- From nobody Thu Mar 9 18:24:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506E2129488 for ; Thu, 9 Mar 2017 18:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piwmSr2oBrN8 for ; Thu, 9 Mar 2017 18:24:27 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0098.outbound.protection.outlook.com [104.47.37.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C47C12944B for ; Thu, 9 Mar 2017 18:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yYIzQAIGtFuInVexVwJ0Q3g5BMVtprtgBKkK8EFymtQ=; b=P6+sv3w2cnLHm82bstBqvCHmFafqk8J5uQHO0KhuF3o5N3osr7Cy8NsBMfRvGihIs7FM8uW98A0DGnQdpPkh8ahgvfRwGZjrZTpjMcC4KhcXpthkiefT2ijs0BAmCvqu+NrStX0OOFkfb5JfrrAUWt1HVBM2qsms00AnXKSt1BQ= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Fri, 10 Mar 2017 02:09:57 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Fri, 10 Mar 2017 02:09:57 +0000 From: Mike Bishop To: "quic@ietf.org" , HTTP working group mailing list Subject: RE: HTTP/QUIC Diverging from HTTP/2 Thread-Topic: HTTP/QUIC Diverging from HTTP/2 Thread-Index: AdKZAt9YNciLyZHpRWy2RhBs+G6fSwAMq+0w Date: Fri, 10 Mar 2017 02:09:57 +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: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.58.46.178] x-ms-office365-filtering-correlation-id: f90e32d7-c5d3-4419-f378-08d4675a8cd6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:NScspr2Vb6YPjpq43+11ufKov42T/RY54bF7pjL7zxYJDboP+LOykXRHU1mqxWN0NWkngaEyJIMFdiuHYDqBlD8F8mKG8dnVGqZuc/5n7Cjb0+hRuOWgFtTI7CbAMZRlbpy5kN9TmudNzeqAvOYvMDML+Gf/5ZRu8f+wVFmyRV3SxSjeeXHXE1WKvkrCOYUo4lRvHi/6qrQVYeC/xXQFhEXL+VWXbXB1c2+yGnvc5dmcgI7CIzVZVHHqzvo22lLL7zqr6oVEqo5I/W15XK6PQ0SfZQwoBoJvsnQTMM7wB5amE+hPyjLwD8kvMCYVyQYDDgvWhlUOooUDkC2VCpRbmD9c8uc5mgP7K+78YGIfJoQ= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6042181); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51444003)(54356999)(2906002)(2950100002)(7906003)(74316002)(5660300001)(53936002)(99286003)(10290500002)(3280700002)(55016002)(8676002)(10090500001)(66066001)(189998001)(2900100001)(50986999)(8936002)(76176999)(236005)(229853002)(81166006)(7696004)(5005710100001)(9686003)(54896002)(606005)(6436002)(6116002)(53546006)(122556002)(33656002)(6506006)(6246003)(7736002)(2501003)(86362001)(3660700001)(790700001)(25786008)(6306002)(38730400002)(86612001)(102836003)(77096006)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708BEF0008BD24BF8387C6487200BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 02:09:57.1978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:24:32 -0000 --_000_BN6PR03MB2708BEF0008BD24BF8387C6487200BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of feedback on this so far: * Ekr: "Hoping we can converge, or at least maximize overlap" * Stefan: "any hope to [converge] needs to be abandoned" * Ian: "not excited... but it may... be the right thing to do" * Patrick: "separate protocols" * Martin: "keep the differences minimal" but "we're really building a = new protocol" * Alcides: if it's different, make the differences clear If I've misconstrued anyone's response, please speak now; and obviously, mo= re opinions are welcome. I would also appreciate reviews on the text of th= e PRs themselves. Unless there's strong pushback in the next ~14 hours, I expect to incorpora= te both PRs tomorrow, prior to the -02 publication. As Mark noted recently= , that doesn't claim full consensus has been reached, but there appears to = be general support for considering these separate protocols which are close= ly related, rather than two variants of a single protocol. From: Mike Bishop Sent: Thursday, March 9, 2017 10:54 AM To: quic@ietf.org; HTTP working group mailing list Subject: HTTP/QUIC Diverging from HTTP/2 At Patrick's suggestion, I'm restating this question and addressing it to b= oth the HTTP and QUIC working groups. Apologies if you're already followin= g along in QUIC and get this twice after having already seen it the first t= ime. HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session on = QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3. = A number of HTTP/2 frames weren't necessary, since they were duplicative o= f services QUIC provides. In draft -01, we removed the full mux layer from= Stream 3, instead letting QUIC deal with all the stream management. This = necessitated changes to several of the remaining frames. By the current ed= itor's copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several= frames of the same name and purpose exist. Likewise, RFC7540 defines six = settings, three of which are inapplicable in HTTP/QUIC. However, the draft currently still attempts to define them as close cousins= . It updates the HTTP/2 frame and setting registries with additional colum= ns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification if applicable) and= attempts to coexist with HTTP/2 in the same registry. (QUIC defines a uni= fied error space, which means a separate registry of error codes for HTTP/Q= UIC regardless.) In PR #363, I've consolidat= ed almost all of the "different from HTTP/2" text into a new top-level sect= ion and excised a lot of "HTTP/2 has this, but HTTP/QUIC doesn't need it" t= ext from the main body of the document. Martin has advocated making a clea= n break from HTTP/2 and defining our own IANA registry for frame types and = settings, just as we already have for errors. We can, out of respect for o= ur cousin, use the same values where appropriate and reserve existing value= s currently in use on the HTTP/2 side. I think that's a good idea, and it's a fairly small step from the current s= tate of #363. I've created PR #376 to actually make that split. Comments from both WGs about the two PRs would be welcome. (Feedback so fa= r from the QUIC side seems to mostly be "separate with regrets," but not un= iversally.) --_000_BN6PR03MB2708BEF0008BD24BF8387C6487200BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Summary of feedback on this so far:

  • E= kr:  “Hoping we can converge, or at least maximize overlap”= ;
  • Stefan:  “any hope to [converge] needs to be aba= ndoned”
  • Ian:  “not excited… but it may= … be the right thing to do”
  • Patrick:  “= ;separate protocols”
  • Martin:  “keep the diff= erences minimal” but “we're really building a new protocol̶= 1;
  • Alcides:  if it’s different, make the differenc= es clear

 

If I’ve misconstrued anyone’s response, = please speak now; and obviously, more opinions are welcome.  I would a= lso appreciate reviews on the text of the PRs themselves.

 

Unless there’s strong pushback in the next ~14= hours, I expect to incorporate both PRs tomorrow, prior to the -02 publica= tion.  As Mark noted recently, that doesn’t claim full consensus= has been reached, but there appears to be general support for considering these separate protocols which are closely related= , rather than two variants of a single protocol.

 

From: Mike Bishop
Sent: Thursday, March 9, 2017 10:54 AM
To: quic@ietf.org; HTTP working group mailing list <ietf-http-wg@= w3.org>
Subject: HTTP/QUIC Diverging from HTTP/2

 

At Patrick’s suggestion, I’m restating t= his question and addressing it to both the HTTP and QUIC working groups.&nb= sp; Apologies if you’re already following along in QUIC and get this = twice after having already seen it the first time.

 

HTTP/QUIC started off (draft -00) with a mostly-comp= lete HTTP/2 session on QUIC Stream 3, including a full HTTP/2 multiplexing = layer within Stream 3.  A number of HTTP/2 frames weren’t necess= ary, since they were duplicative of services QUIC provides.  In draft -01, we removed the full mux layer from Stre= am 3, instead letting QUIC deal with all the stream management.  This = necessitated changes to several of the remaining frames.  By the curre= nt editor’s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frame= s of the same name and purpose exist.  Likewise, RFC7540 defines six s= ettings, three of which are inapplicable in HTTP/QUIC.

 

However, the draft currently still attempts to defin= e them as close cousins.  It updates the HTTP/2 frame and setting regi= stries with additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Spec= ification if applicable) and attempts to coexist with HTTP/2 in the same registry.  (QUIC defines a unified er= ror space, which means a separate registry of error codes for HTTP/QUIC reg= ardless.)

 

In PR #363, I’ve consolidated almost all of the “different fro= m HTTP/2” text into a new top-level section and excised a lot of R= 20;HTTP/2 has this, but HTTP/QUIC doesn’t need it” text from th= e main body of the document.  Martin has advocated making a clean brea= k from HTTP/2 and defining our own IANA registry for frame types and setting= s, just as we already have for errors.  We can, out of respect for our= cousin, use the same values where appropriate and reserve existing values = currently in use on the HTTP/2 side.

 

I think that’s a good idea, and it’s a f= airly small step from the current state of #363.  I’ve created PR #376 to a= ctually make that split.

 

Comments from both WGs about the two PRs would be we= lcome.  (Feedback so far from the QUIC side seems to mostly be “= separate with regrets,” but not universally.)

--_000_BN6PR03MB2708BEF0008BD24BF8387C6487200BN6PR03MB2708namp_-- From nobody Thu Mar 9 18:28:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86C81294A2 for ; Thu, 9 Mar 2017 18:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXo_x9bQT-au for ; Thu, 9 Mar 2017 18:28:31 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5D212943B for ; Thu, 9 Mar 2017 18:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ulAugarjkMDefcoJtonFnH7rFLe5dgzmZXMPIrfzRtU=; b=WfWSBfmxsTlLmWzIvfitwl5msu4woJiqjE/EOkajicL0gT/bkYUxsA/ljz1dDq9RTvoXp4j2i5UjMHt+kETRgdEWwYhdogrd2dD8A0r31/LTNYu5QyJfhZCaJQlZKGNGerqdMX1DvRU+fh0kyHxdxOmzDKpGfjKjqOkvhjp+Vww= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Fri, 10 Mar 2017 00:51:46 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Fri, 10 Mar 2017 00:51:45 +0000 From: Mike Bishop To: Wenbo Zhu Subject: RE: Divergence from HTTP/2 Thread-Topic: Divergence from HTTP/2 Thread-Index: AdKYd70rURZiuYADRA293Bil8tNr6AAPNMmAAAs0oAAAAu01AAAGBksAAABQmLAAB96ogAABgtdgAAF5cQAAARwIsA== Date: Fri, 10 Mar 2017 00:51:45 +0000 Message-ID: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::297] x-ms-office365-filtering-correlation-id: ff455209-5631-418c-a48f-08d4674fa086 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:cbNLJP4NpF/VMP1E4Wpz6HYs+G9nunuay6bP/FBVudVJC0JIdieoDXSi3pzE3Tkx+w3va0RIWm/Jd/b5xLX3BENRQpEdeZjRaR/nBqbetPfpUprcEpj4hU+BqEKrhkb5jKcuUE7F2JKftk3qMA7s5/MazvnwEP8t7MRlu3u6VNIB1iPbG/NS/P7n2XOO9KqG5iVbibK5iZY4XJYDLvJS6Fp86QdBPHwAkpvJ+aCtJQPjjo5P3oDbL0yF8RTsuv94vEqteKLNXMwkcSkFgXf1Q8/ZDExf0YlOZEYK9NFi1/VqiS8uoQ9UsHgKSST18VomlKzpd9VRVkEEiXZcRlckcuGuo3nfBOzU0MU3bpwQO8w= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(211936372134217)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39860400002)(39450400003)(54094003)(51444003)(24454002)(377454003)(3660700001)(6436002)(6306002)(606005)(54896002)(99286003)(25786008)(19609705001)(93886004)(53546006)(3280700002)(38730400002)(81166006)(6246003)(8936002)(5660300001)(8676002)(9686003)(229853002)(6916009)(189998001)(110136004)(2950100002)(6506006)(77096006)(7696004)(53936002)(33656002)(2906002)(7736002)(74316002)(55016002)(86362001)(54906002)(50986999)(102836003)(5005710100001)(86612001)(76176999)(2900100001)(236005)(7906003)(122556002)(54356999)(790700001)(4326008)(10090500001)(6116002)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27086F08F5EEB6E18E48D92A87200BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 00:51:45.7932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:28:34 -0000 --_000_BN6PR03MB27086F08F5EEB6E18E48D92A87200BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2XigJl2ZSB0YWxrZWQgYSBsaXR0bGUgYml0IGFib3V0IHRoYXQuICBQcm9iYWJseSBub3QsIGZv ciB0aGUgcHJpbWFyeSByZWFzb24gdGhhdCBtb3N0IG9mIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVu IEhUVFAvMiBhbmQgSFRUUC9RVUlDIGV4aXN0IGJlY2F1c2UgUVVJQyBpcyBkaWZmZXJlbnQgZnJv bSBUQ1AuICBJZiB5b3XigJlyZSBydW5uaW5nIG92ZXIgVENQLCB5b3Ugc2hvdWxkIGp1c3QgdXNl IEhUVFAvMi4gIFRoYXQgY2FsY3VsdXMgbWlnaHQgY2hhbmdlIGlmIHdlIHN0YXJ0IGFsc28gYnJp bmdpbmcgaW4gbWFqb3IgbmV3IGZlYXR1cmVzIHRvIEhQQUNLLCBidXQgZXZlbiB0aGVuIEnigJlk IGV4cGVjdCBpdCB0byBiZSBhIGJhY2twb3J0IG9mIHBhcnRpY3VsYXIgZmVhdHVyZXM7IEhUVFAv Mi4xIGlmIHlvdSB3aWxsLiAg4oCcSFRUUC9RVUlD4oCdIG92ZXIgVENQIGp1c3QgZG9lc27igJl0 IHNlZW0gd29ydGggaW52ZXN0bWVudC4NCg0KSG93ZXZlciwgb24gdGhlIOKAnHN0aWxsIG5lZWRz IFRDUOKAnSBub3RlLCB5b3UgbWlnaHQgd2FudCB0byBsb29rIGF0IFBSIzM0ODxodHRwczovL2dp dGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMzQ4Pi4gIFRoYXQgcHJvcG9zZXMgYW4g aHR0cHE6Ly8gc2NoZW1lIHRvIGFjY29tbW9kYXRlIHNjZW5hcmlvcyB3aGVyZSB5b3UgZG9u4oCZ dCB3YW50L25lZWQgdG8gaGF2ZSBkdWFsIFRDUC9RVUlDIHN0YWNrcy4gIFRoZXJl4oCZcyBjdXJy ZW50bHkgbm8gd2F5IHRvIGhhdmUgYW4gYXV0aG9yaXRhdGl2ZSBIVFRQIG9yaWdpbiBvdmVyIFFV SUMgaWYgY2xpZW50IGFuZCBzZXJ2ZXIgY2Fu4oCZdCBmaXJzdCBzcGVhayBUQ1AgdG8gZXhjaGFu Z2UgYW4gQWx0LVN2YyBoZWFkZXIuICBUaGlzIHNlZW1zIGRpdmlkZWQgZW5vdWdoIHRoYXQgSSBk b27igJl0IGV4cGVjdCB0byBpbmNvcnBvcmF0ZSBpdCBpbiBkcmFmdCAtMDIsIGJ1dCBpcyBkZWZp bml0ZWx5IHdvcnRoIGRpc2N1c3NpbmcgYXQgc29tZSBwb2ludC4gIChUbyBiZSBjbGVhciwgdGhp cyB3aWxsIGJhc2ljYWxseSBuZXZlciBiZSBhIHdlYiBzY2VuYXJpbzsgSSBlbnZpc2lvbiB0aGlz IGFzIGJlaW5nIHByaW1hcmlseSB1c2VkIHRvIGlkZW50aWZ5IHNlcnZpY2UgZW5kcG9pbnRzIG9m IEhUVFAgQVBJcyB0aGF0IGNob29zZSB0byBiZSBzZXJ2ZWQgb3ZlciBRVUlDLikNCg0KRnJvbTog V2VuYm8gWmh1IFttYWlsdG86d2VuYm96QGdvb2dsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWFy Y2ggOSwgMjAxNyA0OjA0IFBNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgU3RlZmFuIEVp c3NpbmcgPHN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU+OyBxdWljQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogRGl2ZXJnZW5jZSBmcm9tIEhUVFAvMg0KDQoNCg0KDQpPbiBUaHUsIE1hciA5LCAy MDE3IGF0IDM6MjMgUE0sIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBY3R1YWxseSwg dGhhdOKAmXMgYWxtb3N0IGV4YWN0bHkgd2hhdCB0aGUgZHJhZnQgYWxyZWFkeSBzYXlzOg0KT24g cmVjZWlwdCBvZiBhbiBBbHQtU3ZjIGhlYWRlciBpbmRpY2F0aW5nIEhUVFAvUVVJQyBzdXBwb3J0 LCBhIGNsaWVudCBNQVkNCmF0dGVtcHQgdG8gZXN0YWJsaXNoIGEgUVVJQyBjb25uZWN0aW9uIHRv IHRoZSBpbmRpY2F0ZWQgaG9zdCBhbmQgcG9ydCBhbmQsIGlmDQpzdWNjZXNzZnVsLCBzZW5kIEhU VFAgcmVxdWVzdHMgdXNpbmcgdGhlIG1hcHBpbmcgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQu DQoNCkNvbm5lY3Rpdml0eSBwcm9ibGVtcyAoZS5nLiBmaXJld2FsbCBibG9ja2luZyBVRFApIGNh biByZXN1bHQgaW4gUVVJQyBjb25uZWN0aW9uDQplc3RhYmxpc2htZW50IGZhaWx1cmUsIGluIHdo aWNoIGNhc2UgdGhlIGNsaWVudCBTSE9VTEQgY29udGludWUgdXNpbmcgdGhlDQpleGlzdGluZyBj b25uZWN0aW9uIG9yIHRyeSBhbm90aGVyIGFsdGVybmF0aXZlIGVuZHBvaW50IG9mZmVyZWQgYnkg dGhlIG9yaWdpbi4NCg0KSXMgdGhlcmUgc29tZXRoaW5nIHlvdSB0aGluayB3ZSBuZWVkIHRvIGFk ZCB0byB0aGF0Pw0KTm8uIFRoZSBlZGl0b3IgY29weSBsb29rcyBnb29kLiAgKHNvcnJ5IGZvciBj b21tZW50aW5nIG9uIHRoZSB3cm9uZyBjb3B5KS4NCg0KPT09DQoNCkdpdmVuIHRoYXQgaHR0cC9x dWljIGlzIG5vdCBodHRwMi9xdWljLCBwcm90b2NvbHMgdGhhdCB3YW50IHF1aWMgd2lsbCBsaWtl bHkgaGF2ZSB0byBzdXBwb3J0IGJvdGggaHR0cC9xdWljIChvciBxdWljKSBhbmQgaHR0cC8yIGFz IHRyYW5zcG9ydHMuIEkgd29uZGVyIGlmIGEgYmV0dGVyIHNpdHVhdGlvbiB3b3VsZCBiZSBmb3Ig cXVpYyB0byBwcm92aWRlIGl0cyBvd24gVENQIGFsdGVybmF0aXZlLCBvciBzdWNoIGFuIGFsdGVy bmF0aXZlIHdvdWxkIGVuZCB1cCBiZWluZyBhcyBkaWZmaWN1bHQgYXMgZG9pbmcgaHR0cDIvcXVp Yy4NCg0KDQoNCkZyb206IFdlbmJvIFpodSBbbWFpbHRvOndlbmJvekBnb29nbGUuY29tPG1haWx0 bzp3ZW5ib3pAZ29vZ2xlLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyAyOjM5 IFBNDQoNClRvOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWls dG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0 dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj47IFN0ZWZhbiBFaXNzaW5n IDxzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPG1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVl bmJ5dGVzLmRlPj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogRGl2ZXJnZW5jZSBmcm9tIEhUVFAvMg0KDQoNCg0KT24gVGh1LCBNYXIgOSwgMjAxNyBh dCAxMDo1NCBBTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFp bHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCldlbGwsIHNpbmNlIHdl 4oCZcmUgdGFsa2luZyBhYm91dCBmYWlsaW5nIHRvIGNvbm5lY3QgdG8gYW4gYWx0ZXJuYXRpdmUs IHdlIGNvdWxkIGp1c3Qgc2F5IHRoYXQgdGhlIGNsaWVudCBzaG91bGQgZmFsbCBiYWNrIHRvIHRo ZSBvcmlnaW4gb3IgYSBkaWZmZXJlbnQgYWx0ZXJuYXRpdmUsIHBlciBSRkM3ODM4LiAgVGhhdCBy ZW1vdmVzIGFueSBtZW50aW9uIG9mIGEgcGFydGljdWxhciB0cmFuc3BvcnQgb3IgYSBwYXJ0aWN1 bGFyIEhUVFAgdmVyc2lvbi4NClllcywgbWVudGlvbmluZyBSRkMtNzgzOCB3aWxsIGJlIGdvb2Qu DQoNCg0KRnJvbTogV2VuYm8gWmh1IFttYWlsdG86d2VuYm96QGdvb2dsZS5jb208bWFpbHRvOndl bmJvekBnb29nbGUuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDEwOjQ1IEFN DQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29v Z2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyBTdGVmYW4gRWlzc2luZyA8c3Rl ZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTxtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRl cy5kZT4+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IERpdmVyZ2VuY2UgZnJvbSBIVFRQLzINCg0KVGhlIEhUVFAgbWFwcGluZyBkcmFmdCBzdGF0ZXM6 DQoNCiJDb25uZWN0aXZpdHkgcHJvYmxlbXMgKGUuZy4gZmlyZXdhbGwgYmxvY2tpbmcgVURQKSBt YXkgcmVzdWx0IGluIFFVSUMgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGZhaWx1cmUsIGluIHdo aWNoIGNhc2UgdGhlIGNsaWVudCBzaG91bGQgZ3JhY2VmdWxseSBmYWxsIGJhY2sgdG8gSFRUUC8y Ig0KDQpJZiBRVUlDIGFuZCBpdHMgSFRUUCBtYXBwaW5nIHNlcnZlIGVmZmVjdGl2ZWx5IGFzIEhU VFAvMywgdGhlbiBpdCBzZWVtcyB0byBtZSB0aGF0IFFVSUMgc2hvdWxkIGRlZmluZSBpdHMgb3du IFRDUCBmYWxsYmFjayAoYXMgInNsb3ciIGFuZCBzaW1wbGUgYXMgaXQgbmVlZHMgYmUpIC4uIC5v ciB3aWxsIGRvaW5nIHNvIGNyZWF0ZSB5ZXQgYWdhaW4gYW5vdGhlciBwcm90b2NvbCB2YXJpYW50 IGZvciB3aGF0IGh0dHAgbWFwcGluZyBpcyBjb25jZXJuZWQ/ICAgKCBwLnMuIHNvcnJ5IGlmIHRo aXMgaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgYmVmb3JlIC4uLikNCg0KT24gVGh1LCBNYXIg OSwgMjAxNyBhdCA3OjU5IEFNLCBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVG8gbWUs IGl04oCZcyBhIG1vc3RseSBlZGl0b3JpYWwgZGlmZmVyZW5jZSDigJMgZG8gd2UgdHJ5IHRvIGNv bnRvcnQgdGhlIElBTkEgcmVnaXN0cnkgdG8gY2xhaW0gdGhlc2UgYXJlIHR3byB2YXJpYW50cyBv ZiB0aGUgc2FtZSBwcm90b2NvbCwgb3IgZG8gd2UganVzdCB0ZWxsIElBTkEgdGhleeKAmXJlIGRp ZmZlcmVudCBwcm90b2NvbHMgd2l0aCBkaWZmZXJlbnQgcmVnaXN0cmllcz8gIEkgZG9u4oCZdCBz ZWUgdGhhdCBvbmUgY2hvaWNlIGltcGxpZXMgYSBsYXJnZXIgc2NvcGUgdGhhbiB0aGUgb3RoZXIu ICBJIHRoaW5rIHRoZSBtaXNzaW9uIGlzIHN0aWxsIHRoZSBzYW1lIOKAkyBkZWxpdmVyIEhUVFAg c2VtYW50aWNzIG92ZXIgUVVJQy4NCg0KV2XigJl2ZSBhbHJlYWR5IGRlY2lkZWQgd2XigJlyZSB3 aWxsaW5nIHRvIG1ha2UgYSBudW1iZXIgb2YgZGVwYXJ0dXJlcyBmcm9tIEhUVFAvMiBiZWNhdXNl IGl0IG1ha2VzIHRlY2huaWNhbCBzZW5zZSBpbiBlYWNoIGluZGl2aWR1YWwgY2FzZS4gIE9idmlv dXNseSwgaWYgUVVJQyB0YWtlcyBhIGRyYW1hdGljIHR1cm4gKGUuZy4gdW5yZWxhdGVkIHVuaWRp cmVjdGlvbmFsIHN0cmVhbXMgaW4gZWFjaCBkaXJlY3Rpb24pIHRoZSBIVFRQIG1hcHBpbmcgd291 bGQgZG8gbGlrZXdpc2UgaW4gcmVzcG9uc2UgKHNlZSBicmFuY2ggdW5pZGlyZWN0aW9uYWwyKS4N Cg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyA2OjI4IEFN DQpUbzogU3RlZmFuIEVpc3NpbmcgPHN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU8bWFpbHRv OnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU+Pg0KQ2M6IE1pa2UgQmlzaG9wIDxNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t Pj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogRGl2 ZXJnZW5jZSBmcm9tIEhUVFAvMg0KDQpUaGFua3MgZm9yIHNlbmRpbmcgdGhpcyBvdXQgdG8gdGhl IGxpc3QuICBJIGFsd2F5cyBob3BlZCB3ZSBjb3VsZCBrZWVwIEhUVFAgb3ZlciBRVUlDIGFzIHNp bWlsYXIgdG8gSDIgYXMgcG9zc2libGUsIGJ1dCBhcyB5b3UndmUgcG9pbnRlZCBvdXQgcHJldmlv dXNseSwgYSBsb3Qgb2YgSFRUUC8yIHdhcyBhZGRpbmcgdHJhbnNwb3J0IGZlYXR1cmVzIHN1Y2gg YXMgbXVsdGlwbGUgc3RyZWFtcyBhbmQgZmxvdyBjb250cm9sIG9uIHRvcCBvZiBhbiBleGlzdGlu ZyB0cmFuc3BvcnQuICBTd2l0Y2hpbmcgdG8gUVBBQ0sgd291bGQgYmUgYW5vdGhlciBkcmFtYXRp YyBkZXBhcnR1cmUuDQoNCkknbSBub3QgZXhjaXRlZCBhYm91dCBRVUlDIGFiYW5kb25pbmcgSFRU UDIsIGJ1dCBpdCBtYXkgbWFrZSBlbm91Z2ggdGVjaG5pY2FsIGFuZCBkb2N1bWVudGF0aW9uIHNl bnNlIHRvIGJlIHRoZSByaWdodCB0aGluZyB0byBkby4gIEkgYW0gY29uY2VybmVkIHRoaXMgY291 bGQgZXhwYW5kIHRoZSBzY29wZSBvZiB0aGUgSFRUUCBtYXBwaW5nIHRvbyBtdWNoLCBzbyBpZiB3 ZSdyZSBnb2luZyB0byBtYWtlIHRoaXMgY2hvaWNlLCBJJ2QgbGlrZSB0byBrbm93IHdoYXQgdHlw ZXMgb2YgY2hhbmdlcyBhcmUgaW4gc2NvcGUuDQoNCk9uIFRodSwgTWFyIDksIDIwMTcgYXQgNDow NyBBTSwgU3RlZmFuIEVpc3NpbmcgPHN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU8bWFpbHRv OnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU+PiB3cm90ZToNClRoYW5rcyBmb3Igc2VwYXJh dGluZyB0aGlzIG91dCwgTWlrZS4gRm9yIHNwYXJlIHRpbWUgZm9sa3MgdGhpcyBtYWtlcyBmb2xs b3dpbmcgdGhpcyBhc3BlY3QgZWFzaWVyLg0KDQpNeSBmaXJzdCBpbXByZXNzaW9uIGlzIHRoYXQg YW55IGhvcGUgdG8gaGF2ZSBodHRwLzIgb3ZlciB0Y3AgYW5kIHF1aWMgbmVlZHMgdG8gYmUgYWJh bmRvbmVkLiBXaGljaCB3aWxsIGdpdmUgdGhlIHdvcmxkIGEgdGhpcmQgcHJvdG9jb2wgdG8gY2Fy cnkgaHR0cCBzZW1hbnRpY3MuDQoNCldoYXQgZG9lcyB0aGF0IG1lYW4gZm9yIHRoZSBldm9sdXRp b24gb2YgaHR0cCwgSSB3b25kZXIuDQoNCi1zdGVmYW4NCg0KQW0gMDkuMDMuMjAxNyB1bSAwMzox NiBzY2hyaWViIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0 bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj46DQpBdCB0aGlzIHBvaW50LCBJIGRvbuKA mXQgdGhpbmsgYW55b25lIGV4cGVjdHMgdGhhdCBIVFRQL1FVSUMgYW5kIEhUVFAvMiBhcmUgdGhl IHNhbWUgcHJvdG9jb2wuICBIb3dldmVyLCB0aGUgZHJhZnQgY3VycmVudGx5IHN0aWxsIGF0dGVt cHRzIHRvIGRlZmluZSB0aGVtIGFzIGNsb3NlIGNvdXNpbnMuICBJbiBQUiAjMzYzPGh0dHBzOi8v Z2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNjM+LCBJ4oCZdmUgY29uc29saWRh dGVkIGFsbW9zdCBhbGwgb2YgdGhlIOKAnGRpZmZlcmVudCBmcm9tIEhUVFAvMuKAnSB0ZXh0IGlu dG8gYSBuZXcgc2VjdGlvbiBhbmQgZXhjaXNlZCBhIGxvdCBvZiBzdHVmZiBhYm91dCDigJxIVFRQ LzIgaGFzIHRoaXMsIGJ1dCBIVFRQL1FVSUMgZG9lc27igJl0IG5lZWQgaXTigJ0gZnJvbSB0aGUg bWFpbiBib2R5IG9mIHRoZSBkb2N1bWVudC4gIE1hcnRpbiBoYXMgYWR2b2NhdGVkIG1ha2luZyBh IGNsZWFuIGJyZWFrIGZyb20gSFRUUC8yIGFuZCBkZWZpbmluZyBvdXIgb3duIElBTkEgcmVnaXN0 cnkgZm9yIGZyYW1lIHR5cGVzIGFuZCBzZXR0aW5ncywganVzdCBhcyB3ZSBhbHJlYWR5IGhhdmUg Zm9yIGVycm9ycy4gIFdlIGNhbiwgb3V0IG9mIHJlc3BlY3QgZm9yIGxlZ2FjeSwgdXNlIHRoZSBz YW1lIHZhbHVlcyB3aGVyZSBhcHByb3ByaWF0ZSBhbmQgcmVzZXJ2ZSBleGlzdGluZyB2YWx1ZXMg Y3VycmVudGx5IGluIHVzZSBvbiB0aGUgSFRUUC8yIHNpZGUuDQoNCkkgdGhpbmsgdGhhdOKAmXMg YSBnb29kIGlkZWEsIGFuZCBpdOKAmXMgYSBmYWlybHkgc21hbGwgc3RlcCBmcm9tIHRoZSBjdXJy ZW50IHN0YXRlIG9mICMzNjMuICBJ4oCZdmUgY3JlYXRlZCBQUiAjMzc2PGh0dHBzOi8vZ2l0aHVi LmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNzY+IHRvIGFjdHVhbGx5IG1ha2UgdGhhdCBz cGxpdC4NCg0KQ29tbWVudHMgZnJvbSB0aGUgV0cgYWJvdXQgZWl0aGVyIHdvdWxkIGJlIHdlbGNv bWUuDQoNCg0KDQoNCg== --_000_BN6PR03MB27086F08F5EEB6E18E48D92A87200BN6PR03MB2708namp_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLW0tNzI3NDgxNDE1OTQzODkwMjEzN2dtYWlsLQ0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy03Mjc0ODE0MTU5NDM4OTAyMTM3Z21haWwtO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2XigJl2ZSB0YWxrZWQgYSBsaXR0bGUgYml0IGFib3V0IHRoYXQuJm5ic3A7 IFByb2JhYmx5IG5vdCwgZm9yIHRoZSBwcmltYXJ5IHJlYXNvbiB0aGF0IG1vc3Qgb2YgdGhlIGRp ZmZlcmVuY2VzIGJldHdlZW4gSFRUUC8yIGFuZCBIVFRQL1FVSUMgZXhpc3QgYmVjYXVzZSBRVUlD IGlzIGRpZmZlcmVudCBmcm9tIFRDUC4mbmJzcDsgSWYgeW914oCZcmUgcnVubmluZyBvdmVyIFRD UCwgeW91IHNob3VsZCBqdXN0IHVzZSBIVFRQLzIuJm5ic3A7IFRoYXQNCiBjYWxjdWx1cyBtaWdo dCBjaGFuZ2UgaWYgd2Ugc3RhcnQgYWxzbyBicmluZ2luZyBpbiBtYWpvciBuZXcgZmVhdHVyZXMg dG8gSFBBQ0ssIGJ1dCBldmVuIHRoZW4gSeKAmWQgZXhwZWN0IGl0IHRvIGJlIGEgYmFja3BvcnQg b2YgcGFydGljdWxhciBmZWF0dXJlczsgSFRUUC8yLjEgaWYgeW91IHdpbGwuJm5ic3A7IOKAnEhU VFAvUVVJQ+KAnSBvdmVyIFRDUCBqdXN0IGRvZXNu4oCZdCBzZWVtIHdvcnRoIGludmVzdG1lbnQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIG9uIHRoZSDigJxzdGlsbCBuZWVkcyBU Q1DigJ0gbm90ZSwgeW91IG1pZ2h0IHdhbnQgdG8gbG9vayBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM0OCI+UFIjMzQ4PC9hPi4mbmJzcDsg VGhhdCBwcm9wb3NlcyBhbiBodHRwcTovLyBzY2hlbWUgdG8gYWNjb21tb2RhdGUgc2NlbmFyaW9z IHdoZXJlIHlvdSBkb27igJl0IHdhbnQvbmVlZCB0byBoYXZlIGR1YWwgVENQL1FVSUMgc3RhY2tz LiZuYnNwOyBUaGVyZeKAmXMgY3VycmVudGx5IG5vIHdheSB0byBoYXZlIGFuIGF1dGhvcml0YXRp dmUgSFRUUCBvcmlnaW4gb3ZlciBRVUlDDQogaWYgY2xpZW50IGFuZCBzZXJ2ZXIgY2Fu4oCZdCBm aXJzdCBzcGVhayBUQ1AgdG8gZXhjaGFuZ2UgYW4gQWx0LVN2YyBoZWFkZXIuJm5ic3A7IFRoaXMg c2VlbXMgZGl2aWRlZCBlbm91Z2ggdGhhdCBJIGRvbuKAmXQgZXhwZWN0IHRvIGluY29ycG9yYXRl IGl0IGluIGRyYWZ0IC0wMiwgYnV0IGlzIGRlZmluaXRlbHkgd29ydGggZGlzY3Vzc2luZyBhdCBz b21lIHBvaW50LiZuYnNwOyAoVG8gYmUgY2xlYXIsIHRoaXMgd2lsbCBiYXNpY2FsbHkgbmV2ZXIg YmUgYSB3ZWIgc2NlbmFyaW87DQogSSBlbnZpc2lvbiB0aGlzIGFzIGJlaW5nIHByaW1hcmlseSB1 c2VkIHRvIGlkZW50aWZ5IHNlcnZpY2UgZW5kcG9pbnRzIG9mIEhUVFAgQVBJcyB0aGF0IGNob29z ZSB0byBiZSBzZXJ2ZWQgb3ZlciBRVUlDLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IFdlbmJvIFpodSBbbWFpbHRvOndlbmJvekBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIE1hcmNoIDksIDIwMTcgNDowNCBQTTxicj4NCjxiPlRvOjwvYj4gTWlr ZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBTdGVmYW4gRWlzc2lu ZyAmbHQ7c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IERpdmVyZ2VuY2UgZnJvbSBIVFRQLzI8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgOSwgMjAxNyBhdCAzOjIzIFBNLCBN aWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFjdHVhbGx5LCB0aGF04oCZcyBhbG1vc3QgZXhhY3RseSB3aGF0IHRo ZSBkcmFmdCBhbHJlYWR5IHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQpPbiByZWNlaXB0IG9mIGFuIEFsdC1TdmMgaGVhZGVyIGlu ZGljYXRpbmcgSFRUUC9RVUlDIHN1cHBvcnQsIGEgY2xpZW50IE1BWTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KYXR0ZW1wdCB0byBlc3Rh Ymxpc2ggYSBRVUlDIGNvbm5lY3Rpb24gdG8gdGhlIGluZGljYXRlZCBob3N0IGFuZCBwb3J0IGFu ZCwgaWY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NCnN1Y2Nlc3NmdWwsIHNlbmQgSFRUUCByZXF1ZXN0cyB1c2luZyB0aGUgbWFwcGluZyBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQ29ubmVjdGl2aXR5IHByb2JsZW1z IChlLmcuIGZpcmV3YWxsIGJsb2NraW5nIFVEUCkgY2FuIHJlc3VsdCBpbiBRVUlDIGNvbm5lY3Rp b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCmVzdGFibGlzaG1lbnQgZmFpbHVyZSwgaW4gd2hpY2ggY2FzZSB0aGUgY2xpZW50IFNIT1VM RCBjb250aW51ZSB1c2luZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCmV4aXN0aW5nIGNvbm5lY3Rpb24gb3IgdHJ5IGFub3RoZXIg YWx0ZXJuYXRpdmUgZW5kcG9pbnQgb2ZmZXJlZCBieSB0aGUgb3JpZ2luLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SXMgdGhlcmUgc29tZXRoaW5nIHlvdSB0aGluayB3ZSBuZWVkIHRvIGFk ZCB0byB0aGF0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Oby4gVGhlIGVkaXRvciBjb3B5IGxvb2tzIGdv b2QuICZuYnNwOyhzb3JyeSBmb3IgY29tbWVudGluZyBvbiB0aGUgd3JvbmcgY29weSkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0 aGF0IGh0dHAvcXVpYyBpcyBub3QgaHR0cDIvcXVpYywgcHJvdG9jb2xzIHRoYXQgd2FudCBxdWlj IHdpbGwgbGlrZWx5IGhhdmUgdG8gc3VwcG9ydCBib3RoIGh0dHAvcXVpYyAob3IgcXVpYykgYW5k IGh0dHAvMiBhcyB0cmFuc3BvcnRzLiBJIHdvbmRlciBpZiBhIGJldHRlciBzaXR1YXRpb24gd291 bGQgYmUgZm9yIHF1aWMgdG8gcHJvdmlkZSBpdHMgb3duIFRDUCBhbHRlcm5hdGl2ZSwgb3Igc3Vj aA0KIGFuIGFsdGVybmF0aXZlIHdvdWxkIGVuZCB1cCBiZWluZyBhcyBkaWZmaWN1bHQgYXMgZG9p bmcgaHR0cDIvcXVpYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGNsYXNzPSJnbWFpbC0iPjxiPkZyb206PC9i PiBXZW5ibyBaaHUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86d2VuYm96QGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj53ZW5ib3pAZ29vZ2xlLmNvbTwvYT5dDQo8L3NwYW4+PGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDI6MzkgUE08bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+VG86PC9iPiBNaWtlIEJp c2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7IFN0ZWZhbiBF aXNzaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSIg dGFyZ2V0PSJfYmxhbmsiPnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU8L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IERpdmVyZ2VuY2UgZnJvbSBIVFRQLzI8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g VGh1LCBNYXIgOSwgMjAxNyBhdCAxMDo1NCBBTSwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2VsbCwgc2luY2Ugd2XigJlyZSB0YWxraW5nIGFi b3V0IGZhaWxpbmcgdG8gY29ubmVjdCB0byBhbiBhbHRlcm5hdGl2ZSwgd2UgY291bGQganVzdCBz YXkgdGhhdCB0aGUgY2xpZW50IHNob3VsZCBmYWxsIGJhY2sgdG8gdGhlIG9yaWdpbiBvciBhIGRp ZmZlcmVudCBhbHRlcm5hdGl2ZSwgcGVyIFJGQzc4MzguJm5ic3A7DQogVGhhdCByZW1vdmVzIGFu eSBtZW50aW9uIG9mIGEgcGFydGljdWxhciB0cmFuc3BvcnQgb3IgYSBwYXJ0aWN1bGFyIEhUVFAg dmVyc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIG1lbnRpb25pbmcgUkZDLTc4Mzggd2ls bCBiZSBnb29kLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPkZyb206PC9iPiBXZW5ibyBaaHUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86d2Vu Ym96QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53ZW5ib3pAZ29vZ2xlLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDksIDIwMTcgMTA6NDUgQU08YnI+DQo8 Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86 aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208 L2E+Jmd0OzsgU3RlZmFuIEVpc3NpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2lu Z0BncmVlbmJ5dGVzLmRlIiB0YXJnZXQ9Il9ibGFuayI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRl cy5kZTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC1tLTcyNzQ4MTQx NTk0Mzg5MDIxMzdnbWFpbC0iPjxiPlN1YmplY3Q6PC9iPiBSZTogRGl2ZXJnZW5jZSBmcm9tIEhU VFAvMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBI VFRQIG1hcHBpbmcgZHJhZnQgc3RhdGVzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkNvbm5lY3Rpdml0eSBwcm9ibGVtcyAoZS5nLiBmaXJld2FsbCBibG9ja2luZyBVRFAp IG1heSByZXN1bHQgaW4gUVVJQyZuYnNwO2Nvbm5lY3Rpb24gZXN0YWJsaXNobWVudCBmYWlsdXJl LCBpbg0KIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBzaG91bGQmbmJzcDtncmFjZWZ1bGx5IGZhbGwg YmFjayB0byBIVFRQLzImcXVvdDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIFFVSUMgYW5k IGl0cyBIVFRQIG1hcHBpbmcgc2VydmUgZWZmZWN0aXZlbHkgYXMgSFRUUC8zLCB0aGVuIGl0IHNl ZW1zIHRvIG1lIHRoYXQgUVVJQyBzaG91bGQgZGVmaW5lIGl0cyBvd24gVENQIGZhbGxiYWNrDQog KGFzICZxdW90O3Nsb3cmcXVvdDsgYW5kIHNpbXBsZSBhcyBpdCBuZWVkcyBiZSkgLi4gLm9yIHdp bGwgZG9pbmcgc28gY3JlYXRlIHlldCBhZ2FpbiBhbm90aGVyIHByb3RvY29sIHZhcmlhbnQgZm9y IHdoYXQgaHR0cCBtYXBwaW5nIGlzIGNvbmNlcm5lZD8gJm5ic3A7ICggcC5zLiBzb3JyeSZuYnNw O2lmIHRoaXMgaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgYmVmb3JlIC4uLik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUaHUsIE1hciA5LCAyMDE3IGF0IDc6NTkgQU0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIG1lLCBpdOKAmXMgYQ0KPGk+bW9zdGx5PC9p PiBlZGl0b3JpYWwgZGlmZmVyZW5jZSDigJMgZG8gd2UgdHJ5IHRvIGNvbnRvcnQgdGhlIElBTkEg cmVnaXN0cnkgdG8gY2xhaW0gdGhlc2UgYXJlIHR3byB2YXJpYW50cyBvZiB0aGUgc2FtZSBwcm90 b2NvbCwgb3IgZG8gd2UganVzdCB0ZWxsIElBTkEgdGhleeKAmXJlIGRpZmZlcmVudCBwcm90b2Nv bHMgd2l0aCBkaWZmZXJlbnQgcmVnaXN0cmllcz8mbmJzcDsgSSBkb27igJl0IHNlZSB0aGF0IG9u ZSBjaG9pY2UgaW1wbGllcyBhIGxhcmdlciBzY29wZQ0KIHRoYW4gdGhlIG90aGVyLiZuYnNwOyBJ IHRoaW5rIHRoZSBtaXNzaW9uIGlzIHN0aWxsIHRoZSBzYW1lIOKAkyBkZWxpdmVyIEhUVFAgc2Vt YW50aWNzIG92ZXIgUVVJQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldl4oCZdmUgYWxy ZWFkeSBkZWNpZGVkIHdl4oCZcmUgd2lsbGluZyB0byBtYWtlIGEgbnVtYmVyIG9mIGRlcGFydHVy ZXMgZnJvbSBIVFRQLzIgYmVjYXVzZSBpdCBtYWtlcyB0ZWNobmljYWwgc2Vuc2UgaW4gZWFjaCBp bmRpdmlkdWFsIGNhc2UuJm5ic3A7IE9idmlvdXNseSwgaWYgUVVJQyB0YWtlcyBhIGRyYW1hdGlj IHR1cm4NCiAoZS5nLiB1bnJlbGF0ZWQgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBpbiBlYWNoIGRp cmVjdGlvbikgdGhlIEhUVFAgbWFwcGluZyB3b3VsZCBkbyBsaWtld2lzZSBpbiByZXNwb25zZSAo c2VlIGJyYW5jaCB1bmlkaXJlY3Rpb25hbDIpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDksIDIwMTcgNjoyOCBBTTxicj4NCjxiPlRv OjwvYj4gU3RlZmFuIEVpc3NpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2luZ0Bn cmVlbmJ5dGVzLmRlIiB0YXJnZXQ9Il9ibGFuayI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5k ZTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJp c2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBEaXZlcmdlbmNlIGZyb20gSFRUUC8yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzIGZvciBzZW5kaW5nIHRoaXMgb3V0IHRvIHRoZSBsaXN0LiZuYnNwOyBJIGFs d2F5cyBob3BlZCB3ZSBjb3VsZCBrZWVwIEhUVFAgb3ZlciBRVUlDIGFzIHNpbWlsYXIgdG8gSDIg YXMgcG9zc2libGUsIGJ1dCBhcyB5b3UndmUgcG9pbnRlZCBvdXQgcHJldmlvdXNseSwgYSBsb3Qg b2YgSFRUUC8yIHdhcyBhZGRpbmcNCiB0cmFuc3BvcnQgZmVhdHVyZXMgc3VjaCBhcyBtdWx0aXBs ZSBzdHJlYW1zIGFuZCBmbG93IGNvbnRyb2wgb24gdG9wIG9mIGFuIGV4aXN0aW5nIHRyYW5zcG9y dC4mbmJzcDsgU3dpdGNoaW5nIHRvIFFQQUNLIHdvdWxkIGJlIGFub3RoZXIgZHJhbWF0aWMgZGVw YXJ0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBleGNpdGVkIGFib3V0IFFVSUMgYWJhbmRvbmluZyBIVFRQ MiwgYnV0IGl0IG1heSBtYWtlIGVub3VnaCB0ZWNobmljYWwgYW5kIGRvY3VtZW50YXRpb24gc2Vu c2UgdG8gYmUgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLiZuYnNwOyBJIGFtIGNvbmNlcm5lZCB0aGlz IGNvdWxkIGV4cGFuZCB0aGUgc2NvcGUgb2YNCiB0aGUgSFRUUCBtYXBwaW5nIHRvbyBtdWNoLCBz byBpZiB3ZSdyZSBnb2luZyB0byBtYWtlIHRoaXMgY2hvaWNlLCBJJ2QgbGlrZSB0byBrbm93IHdo YXQgdHlwZXMgb2YgY2hhbmdlcyBhcmUgaW4gc2NvcGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBUaHUsIE1hciA5LCAyMDE3IGF0IDQ6MDcgQU0sIFN0ZWZhbiBFaXNz aW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSIgdGFy Z2V0PSJfYmxhbmsiPnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyBmb3Ig c2VwYXJhdGluZyB0aGlzIG91dCwgTWlrZS4gRm9yIHNwYXJlIHRpbWUgZm9sa3MgdGhpcyBtYWtl cyBmb2xsb3dpbmcgdGhpcyBhc3BlY3QgZWFzaWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgZmlyc3QgaW1wcmVzc2lvbiBpcyB0 aGF0IGFueSBob3BlIHRvIGhhdmUgaHR0cC8yIG92ZXIgdGNwIGFuZCBxdWljIG5lZWRzIHRvIGJl IGFiYW5kb25lZC4gV2hpY2ggd2lsbCBnaXZlIHRoZSB3b3JsZCBhIHRoaXJkIHByb3RvY29sIHRv IGNhcnJ5IGh0dHAgc2VtYW50aWNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCBkb2VzIHRoYXQgbWVhbiBmb3IgdGhlIGV2b2x1 dGlvbiBvZiBodHRwLCBJIHdvbmRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi1zdGVmYW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K QW0gMDkuMDMuMjAxNyB1bSAwMzoxNiBzY2hyaWViIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhpcyBwb2ludCwgSSBk b27igJl0IHRoaW5rIGFueW9uZSBleHBlY3RzIHRoYXQgSFRUUC9RVUlDIGFuZCBIVFRQLzIgYXJl IHRoZSBzYW1lIHByb3RvY29sLiZuYnNwOyBIb3dldmVyLCB0aGUgZHJhZnQgY3VycmVudGx5IHN0 aWxsIGF0dGVtcHRzIHRvIGRlZmluZSB0aGVtIGFzIGNsb3NlIGNvdXNpbnMuJm5ic3A7IEluDQo8 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMzYzIiB0 YXJnZXQ9Il9ibGFuayI+UFIgIzM2MzwvYT4sIEnigJl2ZSBjb25zb2xpZGF0ZWQgYWxtb3N0IGFs bCBvZiB0aGUg4oCcZGlmZmVyZW50IGZyb20gSFRUUC8y4oCdIHRleHQgaW50byBhIG5ldyBzZWN0 aW9uIGFuZCBleGNpc2VkIGEgbG90IG9mIHN0dWZmIGFib3V0IOKAnEhUVFAvMiBoYXMgdGhpcywg YnV0IEhUVFAvUVVJQyBkb2VzbuKAmXQgbmVlZCBpdOKAnSBmcm9tDQogdGhlIG1haW4gYm9keSBv ZiB0aGUgZG9jdW1lbnQuJm5ic3A7IE1hcnRpbiBoYXMgYWR2b2NhdGVkIG1ha2luZyBhIGNsZWFu IGJyZWFrIGZyb20gSFRUUC8yIGFuZCBkZWZpbmluZyBvdXIgb3duIElBTkEgcmVnaXN0cnkgZm9y IGZyYW1lIHR5cGVzIGFuZCBzZXR0aW5ncywganVzdCBhcyB3ZSBhbHJlYWR5IGhhdmUgZm9yIGVy cm9ycy4mbmJzcDsgV2UgY2FuLCBvdXQgb2YgcmVzcGVjdCBmb3IgbGVnYWN5LCB1c2UgdGhlIHNh bWUgdmFsdWVzIHdoZXJlIGFwcHJvcHJpYXRlDQogYW5kIHJlc2VydmUgZXhpc3RpbmcgdmFsdWVz IGN1cnJlbnRseSBpbiB1c2Ugb24gdGhlIEhUVFAvMiBzaWRlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SSB0aGluayB0aGF04oCZcyBhIGdvb2QgaWRlYSwgYW5kIGl04oCZcyBhIGZhaXJs eSBzbWFsbCBzdGVwIGZyb20gdGhlIGN1cnJlbnQgc3RhdGUgb2YgIzM2My4mbmJzcDsgSeKAmXZl IGNyZWF0ZWQNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv cHVsbC8zNzYiIHRhcmdldD0iX2JsYW5rIj5QUiAjMzc2PC9hPiB0byBhY3R1YWxseSBtYWtlIHRo YXQgc3BsaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db21tZW50cyBmcm9tIHRoZSBX RyBhYm91dCBlaXRoZXIgd291bGQgYmUgd2VsY29tZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB27086F08F5EEB6E18E48D92A87200BN6PR03MB2708namp_-- From nobody Thu Mar 9 18:28:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FB11294A2 for ; Thu, 9 Mar 2017 18:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7eVnqfvZHD7 for ; Thu, 9 Mar 2017 18:28:32 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0093.outbound.protection.outlook.com [104.47.34.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A4D129470 for ; Thu, 9 Mar 2017 18:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=llHhkuoJYI3XdRNrFjcmIG9iP541BRF727Cw2eRmq88=; b=EjBW83vNZgafFMqfU5iIsBO8gTPf38uNbbHHPelcu/xjpP/zFmoXg9BBzOK4LhchucCf3gUD4+vvYSy/OBot9Jm7aOU3lUEcBj6gmCogq0dPVpt1mE8uOo30E7EfdHpCP5Zc5MQdv/1G+GxJrw1FT1XUGvceJ3TgsR34Dm+mFNw= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 23:23:15 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 23:23:15 +0000 From: Mike Bishop To: Wenbo Zhu Subject: RE: Divergence from HTTP/2 Thread-Topic: Divergence from HTTP/2 Thread-Index: AdKYd70rURZiuYADRA293Bil8tNr6AAPNMmAAAs0oAAAAu01AAAGBksAAABQmLAAB96ogAABgtdg Date: Thu, 9 Mar 2017 23:23:15 +0000 Message-ID: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::297] x-ms-office365-filtering-correlation-id: d9da9903-5c52-4b43-2299-08d467434345 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:Wc9Be/JUHFHlQpVgRkPwMsHaXCs5TsM0lje5rqMb8BvGwNXLFpjyWjwr8YP9ApQ8UWWYswAHKQIyXwACtr6LSVqWHjy8b/zDabbNeKHQgvTp7xzcf+sOprcJGj5S2Spo5aRwiyFsuJ1FVHB5x02g7FaNtbeSAn2O7ZqXl8eFPcaUfPQmPBK+4T2lSECwfrH0S8846WiAJlPjmlssgz2gdSgjqg7sSOcbiiH/Biq1ywrp6CPLmimwm3RsI4SLbdjgoVWGUKnmnSFT4zYCq3RGuG+JQgq1VyfgV8HTP2jWHsEqLACaZ12x9+ZduSkBpBP9F11IHTUulb+hVBfuiAv2Vhds0+TMMegKiUvkwSHqIw8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39850400002)(51444003)(24454002)(377454003)(3660700001)(6436002)(6306002)(54896002)(99286003)(606005)(25786008)(19609705001)(93886004)(53546006)(3280700002)(81166006)(38730400002)(6246003)(8936002)(5660300001)(8676002)(9686003)(110136004)(229853002)(6916009)(189998001)(2906002)(2950100002)(7696004)(77096006)(6506006)(53936002)(33656002)(74316002)(55016002)(86362001)(54906002)(50986999)(5005710100001)(86612001)(76176999)(102836003)(2900100001)(236005)(7906003)(7736002)(6116002)(122556002)(54356999)(790700001)(4326008)(10090500001)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270824FCBCA4C28605923F4287210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 23:23:15.4219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:28:35 -0000 --_000_BN6PR03MB270824FCBCA4C28605923F4287210BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIHRoYXTigJlzIGFsbW9zdCBleGFjdGx5IHdoYXQgdGhlIGRyYWZ0IGFscmVhZHkg c2F5czoNCk9uIHJlY2VpcHQgb2YgYW4gQWx0LVN2YyBoZWFkZXIgaW5kaWNhdGluZyBIVFRQL1FV SUMgc3VwcG9ydCwgYSBjbGllbnQgTUFZDQphdHRlbXB0IHRvIGVzdGFibGlzaCBhIFFVSUMgY29u bmVjdGlvbiB0byB0aGUgaW5kaWNhdGVkIGhvc3QgYW5kIHBvcnQgYW5kLCBpZg0Kc3VjY2Vzc2Z1 bCwgc2VuZCBIVFRQIHJlcXVlc3RzIHVzaW5nIHRoZSBtYXBwaW5nIGRlc2NyaWJlZCBpbiB0aGlz IGRvY3VtZW50Lg0KDQpDb25uZWN0aXZpdHkgcHJvYmxlbXMgKGUuZy4gZmlyZXdhbGwgYmxvY2tp bmcgVURQKSBjYW4gcmVzdWx0IGluIFFVSUMgY29ubmVjdGlvbg0KZXN0YWJsaXNobWVudCBmYWls dXJlLCBpbiB3aGljaCBjYXNlIHRoZSBjbGllbnQgU0hPVUxEIGNvbnRpbnVlIHVzaW5nIHRoZQ0K ZXhpc3RpbmcgY29ubmVjdGlvbiBvciB0cnkgYW5vdGhlciBhbHRlcm5hdGl2ZSBlbmRwb2ludCBv ZmZlcmVkIGJ5IHRoZSBvcmlnaW4uDQoNCklzIHRoZXJlIHNvbWV0aGluZyB5b3UgdGhpbmsgd2Ug bmVlZCB0byBhZGQgdG8gdGhhdD8NCg0KRnJvbTogV2VuYm8gWmh1IFttYWlsdG86d2VuYm96QGdv b2dsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyAyOjM5IFBNDQpUbzogTWlr ZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzogSWFuIFN3ZXR0IDxp YW5zd2V0dEBnb29nbGUuY29tPjsgU3RlZmFuIEVpc3NpbmcgPHN0ZWZhbi5laXNzaW5nQGdyZWVu Ynl0ZXMuZGU+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogRGl2ZXJnZW5jZSBmcm9tIEhU VFAvMg0KDQoNCg0KT24gVGh1LCBNYXIgOSwgMjAxNyBhdCAxMDo1NCBBTSwgTWlrZSBCaXNob3Ag PE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20+PiB3cm90ZToNCldlbGwsIHNpbmNlIHdl4oCZcmUgdGFsa2luZyBhYm91dCBmYWls aW5nIHRvIGNvbm5lY3QgdG8gYW4gYWx0ZXJuYXRpdmUsIHdlIGNvdWxkIGp1c3Qgc2F5IHRoYXQg dGhlIGNsaWVudCBzaG91bGQgZmFsbCBiYWNrIHRvIHRoZSBvcmlnaW4gb3IgYSBkaWZmZXJlbnQg YWx0ZXJuYXRpdmUsIHBlciBSRkM3ODM4LiAgVGhhdCByZW1vdmVzIGFueSBtZW50aW9uIG9mIGEg cGFydGljdWxhciB0cmFuc3BvcnQgb3IgYSBwYXJ0aWN1bGFyIEhUVFAgdmVyc2lvbi4NClllcywg bWVudGlvbmluZyBSRkMtNzgzOCB3aWxsIGJlIGdvb2QuDQoNCg0KRnJvbTogV2VuYm8gWmh1IFtt YWlsdG86d2VuYm96QGdvb2dsZS5jb208bWFpbHRvOndlbmJvekBnb29nbGUuY29tPl0NClNlbnQ6 IFRodXJzZGF5LCBNYXJjaCA5LCAyMDE3IDEwOjQ1IEFNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRA Z29vZ2xlLmNvbT4+OyBTdGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5k ZTxtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4+OyBxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IERpdmVyZ2VuY2UgZnJvbSBIVFRQLzIN Cg0KVGhlIEhUVFAgbWFwcGluZyBkcmFmdCBzdGF0ZXM6DQoNCiJDb25uZWN0aXZpdHkgcHJvYmxl bXMgKGUuZy4gZmlyZXdhbGwgYmxvY2tpbmcgVURQKSBtYXkgcmVzdWx0IGluIFFVSUMgY29ubmVj dGlvbiBlc3RhYmxpc2htZW50IGZhaWx1cmUsIGluIHdoaWNoIGNhc2UgdGhlIGNsaWVudCBzaG91 bGQgZ3JhY2VmdWxseSBmYWxsIGJhY2sgdG8gSFRUUC8yIg0KDQpJZiBRVUlDIGFuZCBpdHMgSFRU UCBtYXBwaW5nIHNlcnZlIGVmZmVjdGl2ZWx5IGFzIEhUVFAvMywgdGhlbiBpdCBzZWVtcyB0byBt ZSB0aGF0IFFVSUMgc2hvdWxkIGRlZmluZSBpdHMgb3duIFRDUCBmYWxsYmFjayAoYXMgInNsb3ci IGFuZCBzaW1wbGUgYXMgaXQgbmVlZHMgYmUpIC4uIC5vciB3aWxsIGRvaW5nIHNvIGNyZWF0ZSB5 ZXQgYWdhaW4gYW5vdGhlciBwcm90b2NvbCB2YXJpYW50IGZvciB3aGF0IGh0dHAgbWFwcGluZyBp cyBjb25jZXJuZWQ/ICAgKCBwLnMuIHNvcnJ5IGlmIHRoaXMgaGFzIGFscmVhZHkgYmVlbiBkaXNj dXNzZWQgYmVmb3JlIC4uLikNCg0KT24gVGh1LCBNYXIgOSwgMjAxNyBhdCA3OjU5IEFNLCBNaWtl IEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVG8gbWUsIGl04oCZcyBhIG1vc3RseSBlZGl0b3Jp YWwgZGlmZmVyZW5jZSDigJMgZG8gd2UgdHJ5IHRvIGNvbnRvcnQgdGhlIElBTkEgcmVnaXN0cnkg dG8gY2xhaW0gdGhlc2UgYXJlIHR3byB2YXJpYW50cyBvZiB0aGUgc2FtZSBwcm90b2NvbCwgb3Ig ZG8gd2UganVzdCB0ZWxsIElBTkEgdGhleeKAmXJlIGRpZmZlcmVudCBwcm90b2NvbHMgd2l0aCBk aWZmZXJlbnQgcmVnaXN0cmllcz8gIEkgZG9u4oCZdCBzZWUgdGhhdCBvbmUgY2hvaWNlIGltcGxp ZXMgYSBsYXJnZXIgc2NvcGUgdGhhbiB0aGUgb3RoZXIuICBJIHRoaW5rIHRoZSBtaXNzaW9uIGlz IHN0aWxsIHRoZSBzYW1lIOKAkyBkZWxpdmVyIEhUVFAgc2VtYW50aWNzIG92ZXIgUVVJQy4NCg0K V2XigJl2ZSBhbHJlYWR5IGRlY2lkZWQgd2XigJlyZSB3aWxsaW5nIHRvIG1ha2UgYSBudW1iZXIg b2YgZGVwYXJ0dXJlcyBmcm9tIEhUVFAvMiBiZWNhdXNlIGl0IG1ha2VzIHRlY2huaWNhbCBzZW5z ZSBpbiBlYWNoIGluZGl2aWR1YWwgY2FzZS4gIE9idmlvdXNseSwgaWYgUVVJQyB0YWtlcyBhIGRy YW1hdGljIHR1cm4gKGUuZy4gdW5yZWxhdGVkIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgaW4gZWFj aCBkaXJlY3Rpb24pIHRoZSBIVFRQIG1hcHBpbmcgd291bGQgZG8gbGlrZXdpc2UgaW4gcmVzcG9u c2UgKHNlZSBicmFuY2ggdW5pZGlyZWN0aW9uYWwyKS4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWls dG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpTZW50 OiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyA2OjI4IEFNDQpUbzogU3RlZmFuIEVpc3NpbmcgPHN0 ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU8bWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0 ZXMuZGU+Pg0KQ2M6IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogRGl2ZXJnZW5jZSBmcm9tIEhUVFAvMg0KDQpU aGFua3MgZm9yIHNlbmRpbmcgdGhpcyBvdXQgdG8gdGhlIGxpc3QuICBJIGFsd2F5cyBob3BlZCB3 ZSBjb3VsZCBrZWVwIEhUVFAgb3ZlciBRVUlDIGFzIHNpbWlsYXIgdG8gSDIgYXMgcG9zc2libGUs IGJ1dCBhcyB5b3UndmUgcG9pbnRlZCBvdXQgcHJldmlvdXNseSwgYSBsb3Qgb2YgSFRUUC8yIHdh cyBhZGRpbmcgdHJhbnNwb3J0IGZlYXR1cmVzIHN1Y2ggYXMgbXVsdGlwbGUgc3RyZWFtcyBhbmQg ZmxvdyBjb250cm9sIG9uIHRvcCBvZiBhbiBleGlzdGluZyB0cmFuc3BvcnQuICBTd2l0Y2hpbmcg dG8gUVBBQ0sgd291bGQgYmUgYW5vdGhlciBkcmFtYXRpYyBkZXBhcnR1cmUuDQoNCkknbSBub3Qg ZXhjaXRlZCBhYm91dCBRVUlDIGFiYW5kb25pbmcgSFRUUDIsIGJ1dCBpdCBtYXkgbWFrZSBlbm91 Z2ggdGVjaG5pY2FsIGFuZCBkb2N1bWVudGF0aW9uIHNlbnNlIHRvIGJlIHRoZSByaWdodCB0aGlu ZyB0byBkby4gIEkgYW0gY29uY2VybmVkIHRoaXMgY291bGQgZXhwYW5kIHRoZSBzY29wZSBvZiB0 aGUgSFRUUCBtYXBwaW5nIHRvbyBtdWNoLCBzbyBpZiB3ZSdyZSBnb2luZyB0byBtYWtlIHRoaXMg Y2hvaWNlLCBJJ2QgbGlrZSB0byBrbm93IHdoYXQgdHlwZXMgb2YgY2hhbmdlcyBhcmUgaW4gc2Nv cGUuDQoNCk9uIFRodSwgTWFyIDksIDIwMTcgYXQgNDowNyBBTSwgU3RlZmFuIEVpc3NpbmcgPHN0 ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGU8bWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0 ZXMuZGU+PiB3cm90ZToNClRoYW5rcyBmb3Igc2VwYXJhdGluZyB0aGlzIG91dCwgTWlrZS4gRm9y IHNwYXJlIHRpbWUgZm9sa3MgdGhpcyBtYWtlcyBmb2xsb3dpbmcgdGhpcyBhc3BlY3QgZWFzaWVy Lg0KDQpNeSBmaXJzdCBpbXByZXNzaW9uIGlzIHRoYXQgYW55IGhvcGUgdG8gaGF2ZSBodHRwLzIg b3ZlciB0Y3AgYW5kIHF1aWMgbmVlZHMgdG8gYmUgYWJhbmRvbmVkLiBXaGljaCB3aWxsIGdpdmUg dGhlIHdvcmxkIGEgdGhpcmQgcHJvdG9jb2wgdG8gY2FycnkgaHR0cCBzZW1hbnRpY3MuDQoNCldo YXQgZG9lcyB0aGF0IG1lYW4gZm9yIHRoZSBldm9sdXRpb24gb2YgaHR0cCwgSSB3b25kZXIuDQoN Ci1zdGVmYW4NCg0KQW0gMDkuMDMuMjAxNyB1bSAwMzoxNiBzY2hyaWViIE1pa2UgQmlzaG9wIDxN aWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3Nv ZnQuY29tPj46DQpBdCB0aGlzIHBvaW50LCBJIGRvbuKAmXQgdGhpbmsgYW55b25lIGV4cGVjdHMg dGhhdCBIVFRQL1FVSUMgYW5kIEhUVFAvMiBhcmUgdGhlIHNhbWUgcHJvdG9jb2wuICBIb3dldmVy LCB0aGUgZHJhZnQgY3VycmVudGx5IHN0aWxsIGF0dGVtcHRzIHRvIGRlZmluZSB0aGVtIGFzIGNs b3NlIGNvdXNpbnMuICBJbiBQUiAjMzYzPGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1k cmFmdHMvcHVsbC8zNjM+LCBJ4oCZdmUgY29uc29saWRhdGVkIGFsbW9zdCBhbGwgb2YgdGhlIOKA nGRpZmZlcmVudCBmcm9tIEhUVFAvMuKAnSB0ZXh0IGludG8gYSBuZXcgc2VjdGlvbiBhbmQgZXhj aXNlZCBhIGxvdCBvZiBzdHVmZiBhYm91dCDigJxIVFRQLzIgaGFzIHRoaXMsIGJ1dCBIVFRQL1FV SUMgZG9lc27igJl0IG5lZWQgaXTigJ0gZnJvbSB0aGUgbWFpbiBib2R5IG9mIHRoZSBkb2N1bWVu dC4gIE1hcnRpbiBoYXMgYWR2b2NhdGVkIG1ha2luZyBhIGNsZWFuIGJyZWFrIGZyb20gSFRUUC8y IGFuZCBkZWZpbmluZyBvdXIgb3duIElBTkEgcmVnaXN0cnkgZm9yIGZyYW1lIHR5cGVzIGFuZCBz ZXR0aW5ncywganVzdCBhcyB3ZSBhbHJlYWR5IGhhdmUgZm9yIGVycm9ycy4gIFdlIGNhbiwgb3V0 IG9mIHJlc3BlY3QgZm9yIGxlZ2FjeSwgdXNlIHRoZSBzYW1lIHZhbHVlcyB3aGVyZSBhcHByb3By aWF0ZSBhbmQgcmVzZXJ2ZSBleGlzdGluZyB2YWx1ZXMgY3VycmVudGx5IGluIHVzZSBvbiB0aGUg SFRUUC8yIHNpZGUuDQoNCkkgdGhpbmsgdGhhdOKAmXMgYSBnb29kIGlkZWEsIGFuZCBpdOKAmXMg YSBmYWlybHkgc21hbGwgc3RlcCBmcm9tIHRoZSBjdXJyZW50IHN0YXRlIG9mICMzNjMuICBJ4oCZ dmUgY3JlYXRlZCBQUiAjMzc2PGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv cHVsbC8zNzY+IHRvIGFjdHVhbGx5IG1ha2UgdGhhdCBzcGxpdC4NCg0KQ29tbWVudHMgZnJvbSB0 aGUgV0cgYWJvdXQgZWl0aGVyIHdvdWxkIGJlIHdlbGNvbWUuDQoNCg0KDQo= --_000_BN6PR03MB270824FCBCA4C28605923F4287210BN6PR03MB2708namp_ 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 bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFsbHksIHRoYXTigJlz IGFsbW9zdCBleGFjdGx5IHdoYXQgdGhlIGRyYWZ0IGFscmVhZHkgc2F5czo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiByZWNl aXB0IG9mIGFuIEFsdC1TdmMgaGVhZGVyIGluZGljYXRpbmcgSFRUUC9RVUlDIHN1cHBvcnQsIGEg Y2xpZW50IE1BWTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPmF0dGVtcHQgdG8gZXN0YWJsaXNoIGEgUVVJQyBjb25uZWN0aW9uIHRv IHRoZSBpbmRpY2F0ZWQgaG9zdCBhbmQgcG9ydCBhbmQsIGlmPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+c3VjY2Vzc2Z1bCwgc2Vu ZCBIVFRQIHJlcXVlc3RzIHVzaW5nIHRoZSBtYXBwaW5nIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNvbm5lY3Rpdml0eSBwcm9ibGVtcyAoZS5nLiBmaXJld2Fs bCBibG9ja2luZyBVRFApIGNhbiByZXN1bHQgaW4gUVVJQyBjb25uZWN0aW9uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ZXN0YWJs aXNobWVudCBmYWlsdXJlLCBpbiB3aGljaCBjYXNlIHRoZSBjbGllbnQgU0hPVUxEIGNvbnRpbnVl IHVzaW5nIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPmV4aXN0aW5nIGNvbm5lY3Rpb24gb3IgdHJ5IGFub3RoZXIgYWx0ZXJu YXRpdmUgZW5kcG9pbnQgb2ZmZXJlZCBieSB0aGUgb3JpZ2luLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JcyB0aGVyZSBzb21ldGhpbmcgeW91IHRoaW5rIHdlIG5lZWQgdG8gYWRkIHRvIHRoYXQ/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBXZW5ibyBaaHUgW21haWx0bzp3 ZW5ib3pAZ29vZ2xlLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCA5LCAy MDE3IDI6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wICZsdDtNaWNoYWVsLkJpc2hv cEBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0 dEBnb29nbGUuY29tJmd0OzsgU3RlZmFuIEVpc3NpbmcgJmx0O3N0ZWZhbi5laXNzaW5nQGdyZWVu Ynl0ZXMuZGUmZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBEaXZl cmdlbmNlIGZyb20gSFRUUC8yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1hciA5LCAyMDE3 IGF0IDEwOjU0IEFNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3Nv ZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldlbGwsIHNpbmNlIHdl4oCZcmUgdGFsa2lu ZyBhYm91dCBmYWlsaW5nIHRvIGNvbm5lY3QgdG8gYW4gYWx0ZXJuYXRpdmUsIHdlIGNvdWxkIGp1 c3Qgc2F5IHRoYXQgdGhlIGNsaWVudCBzaG91bGQgZmFsbCBiYWNrIHRvIHRoZSBvcmlnaW4gb3Ig YSBkaWZmZXJlbnQgYWx0ZXJuYXRpdmUsIHBlciBSRkM3ODM4LiZuYnNwOw0KIFRoYXQgcmVtb3Zl cyBhbnkgbWVudGlvbiBvZiBhIHBhcnRpY3VsYXIgdHJhbnNwb3J0IG9yIGEgcGFydGljdWxhciBI VFRQIHZlcnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgbWVudGlvbmluZyBSRkMtNzgzOCB3 aWxsIGJlIGdvb2QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFdlbmJvIFpodSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzp3ZW5ib3pAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndlbmJv ekBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggOSwg MjAxNyAxMDo0NSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1h aWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJYW4gU3dldHQg Jmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBTdGVmYW4gRWlzc2luZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGUiIHRhcmdldD0iX2JsYW5rIj5zdGVm YW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPHNwYW4gY2xh c3M9ImdtYWlsLSI+PGI+U3ViamVjdDo8L2I+IFJlOiBEaXZlcmdlbmNlIGZyb20gSFRUUC8yPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIEhUVFAgbWFw cGluZyBkcmFmdCBzdGF0ZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Q29ubmVjdGl2aXR5IHByb2JsZW1zIChlLmcuIGZpcmV3YWxsIGJsb2NraW5nIFVEUCkgbWF5IHJl c3VsdCBpbiBRVUlDJm5ic3A7Y29ubmVjdGlvbiBlc3RhYmxpc2htZW50IGZhaWx1cmUsIGluDQog d2hpY2ggY2FzZSB0aGUgY2xpZW50IHNob3VsZCZuYnNwO2dyYWNlZnVsbHkgZmFsbCBiYWNrIHRv IEhUVFAvMiZxdW90Ozwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgUVVJQyBhbmQgaXRzIEhU VFAgbWFwcGluZyBzZXJ2ZSBlZmZlY3RpdmVseSBhcyBIVFRQLzMsIHRoZW4gaXQgc2VlbXMgdG8g bWUgdGhhdCBRVUlDIHNob3VsZCBkZWZpbmUgaXRzIG93biBUQ1AgZmFsbGJhY2sNCiAoYXMgJnF1 b3Q7c2xvdyZxdW90OyBhbmQgc2ltcGxlIGFzIGl0IG5lZWRzIGJlKSAuLiAub3Igd2lsbCBkb2lu ZyBzbyBjcmVhdGUgeWV0IGFnYWluIGFub3RoZXIgcHJvdG9jb2wgdmFyaWFudCBmb3Igd2hhdCBo dHRwIG1hcHBpbmcgaXMgY29uY2VybmVkPyAmbmJzcDsgKCBwLnMuIHNvcnJ5Jm5ic3A7aWYgdGhp cyBoYXMgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBiZWZvcmUgLi4uKTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwg TWFyIDksIDIwMTcgYXQgNzo1OSBBTSwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VG8gbWUsIGl04oCZcyBhDQo8aT5tb3N0bHk8L2k+IGVkaXRv cmlhbCBkaWZmZXJlbmNlIOKAkyBkbyB3ZSB0cnkgdG8gY29udG9ydCB0aGUgSUFOQSByZWdpc3Ry eSB0byBjbGFpbSB0aGVzZSBhcmUgdHdvIHZhcmlhbnRzIG9mIHRoZSBzYW1lIHByb3RvY29sLCBv ciBkbyB3ZSBqdXN0IHRlbGwgSUFOQSB0aGV54oCZcmUgZGlmZmVyZW50IHByb3RvY29scyB3aXRo IGRpZmZlcmVudCByZWdpc3RyaWVzPyZuYnNwOyBJIGRvbuKAmXQgc2VlIHRoYXQgb25lIGNob2lj ZSBpbXBsaWVzIGEgbGFyZ2VyIHNjb3BlDQogdGhhbiB0aGUgb3RoZXIuJm5ic3A7IEkgdGhpbmsg dGhlIG1pc3Npb24gaXMgc3RpbGwgdGhlIHNhbWUg4oCTIGRlbGl2ZXIgSFRUUCBzZW1hbnRpY3Mg b3ZlciBRVUlDLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2XigJl2ZSBhbHJlYWR5IGRl Y2lkZWQgd2XigJlyZSB3aWxsaW5nIHRvIG1ha2UgYSBudW1iZXIgb2YgZGVwYXJ0dXJlcyBmcm9t IEhUVFAvMiBiZWNhdXNlIGl0IG1ha2VzIHRlY2huaWNhbCBzZW5zZSBpbiBlYWNoIGluZGl2aWR1 YWwgY2FzZS4mbmJzcDsgT2J2aW91c2x5LCBpZiBRVUlDIHRha2VzIGEgZHJhbWF0aWMgdHVybg0K IChlLmcuIHVucmVsYXRlZCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGluIGVhY2ggZGlyZWN0aW9u KSB0aGUgSFRUUCBtYXBwaW5nIHdvdWxkIGRvIGxpa2V3aXNlIGluIHJlc3BvbnNlIChzZWUgYnJh bmNoIHVuaWRpcmVjdGlvbmFsMikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9t OjwvYj4gSWFuIFN3ZXR0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyA2OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBT dGVmYW4gRWlzc2luZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0 ZXMuZGUiIHRhcmdldD0iX2JsYW5rIj5zdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IERp dmVyZ2VuY2UgZnJvbSBIVFRQLzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGFua3MgZm9yIHNlbmRpbmcgdGhpcyBvdXQgdG8gdGhlIGxpc3QuJm5ic3A7IEkgYWx3YXlzIGhv cGVkIHdlIGNvdWxkIGtlZXAgSFRUUCBvdmVyIFFVSUMgYXMgc2ltaWxhciB0byBIMiBhcyBwb3Nz aWJsZSwgYnV0IGFzIHlvdSd2ZSBwb2ludGVkIG91dCBwcmV2aW91c2x5LCBhIGxvdCBvZiBIVFRQ LzIgd2FzIGFkZGluZw0KIHRyYW5zcG9ydCBmZWF0dXJlcyBzdWNoIGFzIG11bHRpcGxlIHN0cmVh bXMgYW5kIGZsb3cgY29udHJvbCBvbiB0b3Agb2YgYW4gZXhpc3RpbmcgdHJhbnNwb3J0LiZuYnNw OyBTd2l0Y2hpbmcgdG8gUVBBQ0sgd291bGQgYmUgYW5vdGhlciBkcmFtYXRpYyBkZXBhcnR1cmUu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JJ20gbm90IGV4Y2l0ZWQgYWJvdXQgUVVJQyBhYmFuZG9uaW5nIEhUVFAyLCBidXQg aXQgbWF5IG1ha2UgZW5vdWdoIHRlY2huaWNhbCBhbmQgZG9jdW1lbnRhdGlvbiBzZW5zZSB0byBi ZSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uJm5ic3A7IEkgYW0gY29uY2VybmVkIHRoaXMgY291bGQg ZXhwYW5kIHRoZSBzY29wZSBvZg0KIHRoZSBIVFRQIG1hcHBpbmcgdG9vIG11Y2gsIHNvIGlmIHdl J3JlIGdvaW5nIHRvIG1ha2UgdGhpcyBjaG9pY2UsIEknZCBsaWtlIHRvIGtub3cgd2hhdCB0eXBl cyBvZiBjaGFuZ2VzIGFyZSBpbiBzY29wZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFRodSwgTWFyIDksIDIwMTcgYXQgNDowNyBBTSwgU3RlZmFuIEVpc3NpbmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlIiB0YXJnZXQ9Il9i bGFuayI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciBzZXBhcmF0 aW5nIHRoaXMgb3V0LCBNaWtlLiBGb3Igc3BhcmUgdGltZSBmb2xrcyB0aGlzIG1ha2VzIGZvbGxv d2luZyB0aGlzIGFzcGVjdCBlYXNpZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBmaXJzdCBpbXByZXNzaW9uIGlzIHRoYXQgYW55 IGhvcGUgdG8gaGF2ZSBodHRwLzIgb3ZlciB0Y3AgYW5kIHF1aWMgbmVlZHMgdG8gYmUgYWJhbmRv bmVkLiBXaGljaCB3aWxsIGdpdmUgdGhlIHdvcmxkIGEgdGhpcmQgcHJvdG9jb2wgdG8gY2Fycnkg aHR0cCBzZW1hbnRpY3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5XaGF0IGRvZXMgdGhhdCBtZWFuIGZvciB0aGUgZXZvbHV0aW9uIG9m IGh0dHAsIEkgd29uZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LXN0ZWZhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpBbSAwOS4w My4yMDE3IHVtIDAzOjE2IHNjaHJpZWIgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BdCB0aGlzIHBvaW50LCBJIGRvbuKAmXQg dGhpbmsgYW55b25lIGV4cGVjdHMgdGhhdCBIVFRQL1FVSUMgYW5kIEhUVFAvMiBhcmUgdGhlIHNh bWUgcHJvdG9jb2wuJm5ic3A7IEhvd2V2ZXIsIHRoZSBkcmFmdCBjdXJyZW50bHkgc3RpbGwgYXR0 ZW1wdHMgdG8gZGVmaW5lIHRoZW0gYXMgY2xvc2UgY291c2lucy4mbmJzcDsgSW4NCjxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNjMiIHRhcmdldD0i X2JsYW5rIj5QUiAjMzYzPC9hPiwgSeKAmXZlIGNvbnNvbGlkYXRlZCBhbG1vc3QgYWxsIG9mIHRo ZSDigJxkaWZmZXJlbnQgZnJvbSBIVFRQLzLigJ0gdGV4dCBpbnRvIGEgbmV3IHNlY3Rpb24gYW5k IGV4Y2lzZWQgYSBsb3Qgb2Ygc3R1ZmYgYWJvdXQg4oCcSFRUUC8yIGhhcyB0aGlzLCBidXQgSFRU UC9RVUlDIGRvZXNu4oCZdCBuZWVkIGl04oCdIGZyb20NCiB0aGUgbWFpbiBib2R5IG9mIHRoZSBk b2N1bWVudC4mbmJzcDsgTWFydGluIGhhcyBhZHZvY2F0ZWQgbWFraW5nIGEgY2xlYW4gYnJlYWsg ZnJvbSBIVFRQLzIgYW5kIGRlZmluaW5nIG91ciBvd24gSUFOQSByZWdpc3RyeSBmb3IgZnJhbWUg dHlwZXMgYW5kIHNldHRpbmdzLCBqdXN0IGFzIHdlIGFscmVhZHkgaGF2ZSBmb3IgZXJyb3JzLiZu YnNwOyBXZSBjYW4sIG91dCBvZiByZXNwZWN0IGZvciBsZWdhY3ksIHVzZSB0aGUgc2FtZSB2YWx1 ZXMgd2hlcmUgYXBwcm9wcmlhdGUNCiBhbmQgcmVzZXJ2ZSBleGlzdGluZyB2YWx1ZXMgY3VycmVu dGx5IGluIHVzZSBvbiB0aGUgSFRUUC8yIHNpZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JIHRoaW5rIHRoYXTigJlzIGEgZ29vZCBpZGVhLCBhbmQgaXTigJlzIGEgZmFpcmx5IHNtYWxs IHN0ZXAgZnJvbSB0aGUgY3VycmVudCBzdGF0ZSBvZiAjMzYzLiZuYnNwOyBJ4oCZdmUgY3JlYXRl ZA0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM3 NiIgdGFyZ2V0PSJfYmxhbmsiPlBSICMzNzY8L2E+IHRvIGFjdHVhbGx5IG1ha2UgdGhhdCBzcGxp dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbW1lbnRzIGZyb20gdGhlIFdHIGFib3V0 IGVpdGhlciB3b3VsZCBiZSB3ZWxjb21lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR03MB270824FCBCA4C28605923F4287210BN6PR03MB2708namp_-- From nobody Thu Mar 9 18:29:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25009129470 for ; Thu, 9 Mar 2017 18:28:51 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 HvZA6Aif2Xqv for ; Thu, 9 Mar 2017 18:28:40 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 EB74D12943B for ; Thu, 9 Mar 2017 18:28:39 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id v76so16180593ywg.0 for ; Thu, 09 Mar 2017 18:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t/bmk882LrgHFqbaIFtn0S39hiJOEYp+jnOExRf4vK8=; b=yqWpwlb4I8SHbPN//WRERmSm6JjZaGcTw204BAFxlV6gJ+swYBOsSTe4tUDN4pkUJC xY25/WXTtxsExlRqQgJ7pvOzjw4dJjNupzAdJ6xqhlekhmPvaGoYNN34Q8Pz2nxqzRND gSBnoDhJwtxJDlFKNYKr2va3AIDV07mwIcTUG16cQXnvEM4pWFLHBSMhjma6T/iV6LqU apmEA7NlcEiy6dr/gStUSAr5KkvTIQxoF2jl/Zna+tkNh2wfAUT1WXj/UKRabZiFh2TX LxvgyDM089pVmLYLjnegfFehLlqyUvBFBlKUQzFtEsY2Mwc+2weO6KfswrwsNTeRlxCt fu4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t/bmk882LrgHFqbaIFtn0S39hiJOEYp+jnOExRf4vK8=; b=eVsBFQopb3oddVq+WyMolzzlY4CLo0+FgQkJCnWQGLJlNS+tiI1sW27GzGjjeovMKK /0UwkWX9VnQc2eArC6mQo1YHDubusR6O147K2BoNBmqwlRIu1IGD48tMkMiuq1JUB74u ImlhBS4mT5qQklg5KkjZKtXM0KpyCnfg4fOh1y5hr9aG0KRHQrAvDAxwwAxB1i2vMRQd xDmFo4QyXKkzdlYhexXBWMW7AGJOXTnE9hK5iYLaAYlU7N9PeM/Y8dvTbdDXhkqZ7Rx9 hsjmRfn9GNN5bXLFRjvGGRhLaEJ+qCrbhxWZNKpqk0HwCcs8qmcPAfBnNCYOmlOXiyHX RnCA== X-Gm-Message-State: AMke39lh7D0nfPcMbWdXSpMORurb7/0/xTFa0mJ+N48CFqliqAckgicPjhrlD7+AgHYIvZYRyedHL5nH0g86xw== X-Received: by 10.129.108.214 with SMTP id h205mr6362582ywc.71.1489112919280; Thu, 09 Mar 2017 18:28:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 18:27:58 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Mar 2017 18:27:58 -0800 Message-ID: Subject: Re: HTTP/QUIC Diverging from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=001a114e81dc95a4f5054a571e6e Archived-At: Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:28:52 -0000 --001a114e81dc95a4f5054a571e6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop wrote: > Summary of feedback on this so far: > > - Ekr: =E2=80=9CHoping we can converge, or at least maximize overlap= =E2=80=9D > - Stefan: =E2=80=9Cany hope to [converge] needs to be abandoned=E2=80= =9D > - Ian: =E2=80=9Cnot excited=E2=80=A6 but it may=E2=80=A6 be the right= thing to do=E2=80=9D > - Patrick: =E2=80=9Cseparate protocols=E2=80=9D > - Martin: =E2=80=9Ckeep the differences minimal=E2=80=9D but =E2=80= =9Cwe're really building a > new protocol=E2=80=9D > - Alcides: if it=E2=80=99s different, make the differences clear > > > > If I=E2=80=99ve misconstrued anyone=E2=80=99s response, please speak now;= and obviously, > more opinions are welcome. I would also appreciate reviews on the text o= f > the PRs themselves. > > > > Unless there=E2=80=99s strong pushback in the next ~14 hours, I expect to > incorporate both PRs tomorrow, prior to the -02 publication. As Mark not= ed > recently, that doesn=E2=80=99t claim full consensus has been reached, but= there > appears to be general support for considering these separate protocols > which are closely related, rather than two variants of a single protocol. > > > This seems like pretty weak consensus, so I'd prefer we discuss this in ORD rather than having you merge this now. -Ekr *From:* Mike Bishop > *Sent:* Thursday, March 9, 2017 10:54 AM > *To:* quic@ietf.org; HTTP working group mailing list > *Subject:* HTTP/QUIC Diverging from HTTP/2 > > > > At Patrick=E2=80=99s suggestion, I=E2=80=99m restating this question and = addressing it to > both the HTTP and QUIC working groups. Apologies if you=E2=80=99re alrea= dy > following along in QUIC and get this twice after having already seen it t= he > first time. > > > > HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session o= n > QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3= . > A number of HTTP/2 frames weren=E2=80=99t necessary, since they were dupl= icative of > services QUIC provides. In draft -01, we removed the full mux layer from > Stream 3, instead letting QUIC deal with all the stream management. This > necessitated changes to several of the remaining frames. By the current > editor=E2=80=99s copy, *no* HTTP/2 frame exists unmodified in HTTP/QUIC, = though > several frames of the same name and purpose exist. Likewise, RFC7540 > defines six settings, three of which are inapplicable in HTTP/QUIC. > > > > However, the draft currently still attempts to define them as close > cousins. It updates the HTTP/2 frame and setting registries with > additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification = if > applicable) and attempts to coexist with HTTP/2 in the same registry. > (QUIC defines a unified error space, which means a separate registry of > error codes for HTTP/QUIC regardless.) > > > > In PR #363 , I=E2=80=99ve > consolidated almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D te= xt into a new > top-level section and excised a lot of =E2=80=9CHTTP/2 has this, but HTTP= /QUIC > doesn=E2=80=99t need it=E2=80=9D text from the main body of the document.= Martin has > advocated making a clean break from HTTP/2 and defining our own IANA > registry for frame types and settings, just as we already have for errors= . > We can, out of respect for our cousin, use the same values where > appropriate and reserve existing values currently in use on the HTTP/2 si= de. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from both WGs about the two PRs would be welcome. (Feedback so > far from the QUIC side seems to mostly be =E2=80=9Cseparate with regrets,= =E2=80=9D but not > universally.) > --001a114e81dc95a4f5054a571e6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

Summary of feedback on this so far:

  • Ekr:=C2=A0 =E2=80=9CHopin= g we can converge, or at least maximize overlap=E2=80=9D
    • =
  • Stefan:=C2=A0 =E2=80=9Can= y hope to [converge] needs to be abandoned=E2=80=9D
  • Ian:=C2=A0 =E2=80=9Cnot excite= d=E2=80=A6 but it may=E2=80=A6 be the right thing to do=E2=80=9D<= /u>
  • Patrick:=C2=A0 = =E2=80=9Cseparate protocols=E2=80=9D
  • Martin:=C2=A0 =E2=80=9Ckeep the differences m= inimal=E2=80=9D but =E2=80=9Cwe're really building a new protocol=E2=80= =9D
  • Alc= ides:=C2=A0 if it=E2=80=99s different, make the differences clear=

=C2=A0

If I=E2=80=99ve misconstrued anyone=E2=80=99s respon= se, please speak now; and obviously, more opinions are welcome.=C2=A0 I wou= ld also appreciate reviews on the text of the PRs themselves.=

=C2=A0

Unless there=E2=80=99s strong pushback in the next ~= 14 hours, I expect to incorporate both PRs tomorrow, prior to the -02 publi= cation.=C2=A0 As Mark noted recently, that doesn=E2=80=99t claim full conse= nsus has been reached, but there appears to be general support for considering these separate protocols which are closely related= , rather than two variants of a single protocol.

=C2=A0


<= /div>
This seems like pretty weak consensus, so I'd prefer we discu= ss this in ORD rather than
having you merge this now.
<= br>
-Ekr

From: Mike Bishop
Sent: Thursday, March 9, 2017 10:54 AM
To: quic@ietf.org= ; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: HTTP/QUIC Diverging from HTTP/2

=C2=A0

At Patrick=E2=80=99s suggestion, I=E2=80=99m restati= ng this question and addressing it to both the HTTP and QUIC working groups= .=C2=A0 Apologies if you=E2=80=99re already following along in QUIC and get= this twice after having already seen it the first time.

=C2=A0

HTTP/QUIC started off (draft -00) with a mostly-comp= lete HTTP/2 session on QUIC Stream 3, including a full HTTP/2 multiplexing = layer within Stream 3.=C2=A0 A number of HTTP/2 frames weren=E2=80=99t nece= ssary, since they were duplicative of services QUIC provides.=C2=A0 In draft -01, we removed the full mux layer from Stre= am 3, instead letting QUIC deal with all the stream management.=C2=A0 This = necessitated changes to several of the remaining frames.=C2=A0 By the curre= nt editor=E2=80=99s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frame= s of the same name and purpose exist.=C2=A0 Likewise, RFC7540 defines six s= ettings, three of which are inapplicable in HTTP/QUIC.

=C2=A0

However, the draft currently still attempts to defin= e them as close cousins.=C2=A0 It updates the HTTP/2 frame and setting regi= stries with additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Spec= ification if applicable) and attempts to coexist with HTTP/2 in the same registry.=C2=A0 (QUIC defines a unified er= ror space, which means a separate registry of error codes for HTTP/QUIC reg= ardless.)

=C2=A0

In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdifferent= from HTTP/2=E2=80=9D text into a new top-level section and excised a lot o= f =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80=9D = text from the main body of the document.=C2=A0 Martin has advocated making = a clean break from HTTP/2 and defining our own IANA registry for frame types and setting= s, just as we already have for errors.=C2=A0 We can, out of respect for our= cousin, use the same values where appropriate and reserve existing values = currently in use on the HTTP/2 side.

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from both WGs about the two PRs would be we= lcome.=C2=A0 (Feedback so far from the QUIC side seems to mostly be =E2=80= =9Cseparate with regrets,=E2=80=9D but not universally.)


--001a114e81dc95a4f5054a571e6e-- From nobody Thu Mar 9 18:33:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685E51294A9 for ; Thu, 9 Mar 2017 18:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Q73nsJMr-w2q for ; Thu, 9 Mar 2017 18:32:53 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D5B129477 for ; Thu, 9 Mar 2017 18:32:51 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id p77so16206202ywg.1 for ; Thu, 09 Mar 2017 18:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sErT9aGk6Yj0qJeNdzpyGnBzAHiEpZEw0haIerjypAM=; b=ur+zWw45TBylw0o1FEvsyV45Ha6tdW+IAcZ9CS5VT49pRFRCmbq/hDuh6LPYPHwcBX L8FT9xlWS1xuhPhJcifj+kkrax31REcC1/12kOow3vz+E+mYypPUqa4fS5cDVgQpM63Q fc+HqN20sPes29f6IW7IWY9M7dj7Ux5q8DsI9QlDfWzRfHL+ToRUvEOPFuj0Oh1MlXYe 0SPt38bj1URIgxHkXAx6ZH6751RhOZW15/dz2FJ0EEFz5zPqFtTxK7BTHHDuheqzD9Ao R3HJSQqLvgk9B7LVLSoCA+i4nplXXIXAe9NsSmmblhE/sf7oLC4X66lhTYayWzKV6H2x /QIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sErT9aGk6Yj0qJeNdzpyGnBzAHiEpZEw0haIerjypAM=; b=jZ8GGy//joKW+GOUDledXjdNBYpq5QWMNGc+TCzS5YRdGpLNiE2Ir6Z9LUfURaOS/j r6RJmxbV8ByC14O9YT6UsDIqSnM00rUkSbGKev5ZpLoqCwgtlXQK985Dmjhp0GdIA30W QiyX3xjjCc3yLGncOtolTLmjMFUdUYGqudw2BvEGxAWxYCGUZLXaA33C2JCg4vZ6QBMq 4Tcx52/ckTm0wcAtgnuulnmBfTKs4VpdAag0pN0cCPnIYvzD7xDH8TCiVUtgbq9wx7+d Mk7F9zR4GZM/EOwrtcD3GhrY0Vqp+iAk1RUC8sBcgRJrvOyACq3H0COQJojNcdfAOHno In9w== X-Gm-Message-State: AMke39mX/ZYgpDheWLVEu/YRauY4ELZY4EOyfAQEbTA3rPgnIJpGYPJ896lQXCwi3EaWv1WR6GsQYiqv9YPn0s+u X-Received: by 10.129.125.5 with SMTP id y5mr5449665ywc.120.1489099134489; Thu, 09 Mar 2017 14:38:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.65 with HTTP; Thu, 9 Mar 2017 14:38:53 -0800 (PST) In-Reply-To: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> From: Wenbo Zhu Date: Thu, 9 Mar 2017 14:38:53 -0800 Message-ID: Subject: Re: Divergence from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=001a11493644f2ce59054a53e891 Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:32:54 -0000 --001a11493644f2ce59054a53e891 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 10:54 AM, Mike Bishop wrote: > Well, since we=E2=80=99re talking about failing to connect to an alternat= ive, we > could just say that the client should fall back to the origin or a > different alternative, per RFC7838. That removes any mention of a > particular transport or a particular HTTP version. > Yes, mentioning RFC-7838 will be good. > > *From:* Wenbo Zhu [mailto:wenboz@google.com] > *Sent:* Thursday, March 9, 2017 10:45 AM > *To:* Mike Bishop > *Cc:* Ian Swett ; Stefan Eissing < > stefan.eissing@greenbytes.de>; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > The HTTP mapping draft states: > > > > "Connectivity problems (e.g. firewall blocking UDP) may result in > QUIC connection establishment failure, in which case the client > should gracefully fall back to HTTP/2" > > > > If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seems t= o > me that QUIC should define its own TCP fallback (as "slow" and simple as = it > needs be) .. .or will doing so create yet again another protocol variant > for what http mapping is concerned? ( p.s. sorry if this has already be= en > discussed before ...) > > > > On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop > wrote: > > To me, it=E2=80=99s a *mostly* editorial difference =E2=80=93 do we try t= o contort the > IANA registry to claim these are two variants of the same protocol, or do > we just tell IANA they=E2=80=99re different protocols with different regi= stries? I > don=E2=80=99t see that one choice implies a larger scope than the other. = I think > the mission is still the same =E2=80=93 deliver HTTP semantics over QUIC. > > > > We=E2=80=99ve already decided we=E2=80=99re willing to make a number of d= epartures from > HTTP/2 because it makes technical sense in each individual case. > Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional > streams in each direction) the HTTP mapping would do likewise in response > (see branch unidirectional2). > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Thursday, March 9, 2017 6:28 AM > *To:* Stefan Eissing > *Cc:* Mike Bishop ; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > Thanks for sending this out to the list. I always hoped we could keep > HTTP over QUIC as similar to H2 as possible, but as you've pointed out > previously, a lot of HTTP/2 was adding transport features such as multipl= e > streams and flow control on top of an existing transport. Switching to > QPACK would be another dramatic departure. > > > > I'm not excited about QUIC abandoning HTTP2, but it may make enough > technical and documentation sense to be the right thing to do. I am > concerned this could expand the scope of the HTTP mapping too much, so if > we're going to make this choice, I'd like to know what types of changes a= re > in scope. > > > > On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing < > stefan.eissing@greenbytes.de> wrote: > > Thanks for separating this out, Mike. For spare time folks this makes > following this aspect easier. > > > > My first impression is that any hope to have http/2 over tcp and quic > needs to be abandoned. Which will give the world a third protocol to carr= y > http semantics. > > > > What does that mean for the evolution of http, I wonder. > > > > -stefan > > > Am 09.03.2017 um 03:16 schrieb Mike Bishop = : > > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are > the same protocol. However, the draft currently still attempts to define > them as close cousins. In PR #363 > , I=E2=80=99ve consolidat= ed > almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new= section and > excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC does= n=E2=80=99t need > it=E2=80=9D from the main body of the document. Martin has advocated mak= ing a > clean break from HTTP/2 and defining our own IANA registry for frame type= s > and settings, just as we already have for errors. We can, out of respect > for legacy, use the same values where appropriate and reserve existing > values currently in use on the HTTP/2 side. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from the WG about either would be welcome. > > > > > --001a11493644f2ce59054a53e891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 10:54 AM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

Well, since we=E2=80=99re talking about failing to c= onnect to an alternative, we could just say that the client should fall bac= k to the origin or a different alternative, per RFC7838.=C2=A0 That removes= any mention of a particular transport or a particular HTTP version.

Yes, mentioning RFC-7838 wi= ll be good.=C2=A0

=C2=A0

From: Wenbo Zhu [mailto:wenboz@google.com]
Sent: Thursday, March 9, 2017 10:45 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Ian Swett <ianswett@google.com>; Stefan Eissing <stefan.eissing@greenbytes.de<= /a>>; quic@ietf.= org
Subject: Re: Divergence from HTTP/2

=C2=A0

The HTT= P mapping draft states:

=C2=A0

"<= span style=3D"color:black">Connectivity problems (e.g. firewall blocking UD= P) may result in QUIC=C2=A0connection establishment failure, in which case = the client should=C2=A0gracefully fall back to HTTP/2"

=C2=A0

If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seem= s to me that QUIC should define its own TCP fallback (as "slow" a= nd simple as it needs be) .. .or will doing so create yet again another protocol variant for what http mapping is conc= erned? =C2=A0 ( p.s. sorry=C2=A0if this has already been discussed before .= ..)

=C2=A0

On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to contort the IANA = registry to claim these are two variants of the same protocol, or do we jus= t tell IANA they=E2=80=99re different protocols with different registries?= =C2=A0 I don=E2=80=99t see that one choice implies a larger scope than the other.=C2=A0 I think the mission is still the same =E2=80=93 deli= ver HTTP semantics over QUIC.

=C2=A0

We=E2=80=99ve already decided we=E2=80=99re willing = to make a number of departures from HTTP/2 because it makes technical sense= in each individual case.=C2=A0 Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each direction) the HTTP mapping= would do likewise in response (see branch unidirectional2).<= /p>

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org
Subject: Re: Divergence from HTTP/2

=C2=A0

Thanks for sending this out to the list.=C2=A0 I alw= ays hoped we could keep HTTP over QUIC as similar to H2 as possible, but as= you've pointed out previously, a lot of HTTP/2 was adding transport features such as multiple streams and flow control on top of an = existing transport.=C2=A0 Switching to QPACK would be another dramatic depa= rture.

=C2=A0

I'm not excited about QUIC abandoning HTTP2, but= it may make enough technical and documentation sense to be the right thing= to do.=C2=A0 I am concerned this could expand the scope of the HTTP mapping too much, so if we're going to make this choice, I= 9;d like to know what types of changes are in scope.=C2=A0

=C2=A0

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <<= a href=3D"mailto:stefan.eissing@greenbytes.de" target=3D"_blank">stefan.eis= sing@greenbytes.de> wrote:

Thanks for separating this out, Mike. For spare time= folks this makes following this aspect easier.

=C2=A0

My first impression is that any hope to have http/2 = over tcp and quic needs to be abandoned. Which will give the world a third = protocol to carry http semantics.

=C2=A0

What does that mean for the evolution of http, I won= der.

=C2=A0=

-stefan


Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com><= wbr>:

At this point, I don=E2=80=99t think anyone expects = that HTTP/QUIC and HTTP/2 are the same protocol.=C2=A0 However, the draft c= urrently still attempts to define them as close cousins.=C2=A0 In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdiffere= nt from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff = about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D from the main body of the document.=C2=A0 Martin has advocated making a clean b= reak from HTTP/2 and defining our own IANA registry for frame types and set= tings, just as we already have for errors.=C2=A0 We can, out of respect for= legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.=

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from the WG about either would be welcome.<= u>

=C2=A0

=C2=A0


--001a11493644f2ce59054a53e891-- From nobody Thu Mar 9 18:40:26 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1764B12943B for ; Thu, 9 Mar 2017 18:40:25 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uTBeIkkUpWnV for ; Thu, 9 Mar 2017 18:40:23 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D5D1294FA for ; Thu, 9 Mar 2017 18:40:21 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id v76so16298438ywg.0 for ; Thu, 09 Mar 2017 18:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uHi8yqcYODc/Ev1hHv8xzBi8Vd13qOOwJOLKj55fUsw=; b=stVJuoMJ2I3Jjwvsts8DwvSvVKaL32s+KGxDPunjkdNuCJT78qirKoUK/uQOJ1NTNr 2lSVxyBRFH115sx0V5qLrX30bofRz9//7+eFsMsbGsYE8vRSoLna5QDBdOPJrKnvHwqZ Mz0YZu2+3SOROPJdENGpJPoGBFsAtyQqMvtuAWlE5DG8FxtFaLcy/vmy1lwlJNb+FK0c uo4ZSqNU4hRdxjQadUW2LXsqDlub195RcJnhz8JJOHj3fI93IGLXpd8IwwDlNEE71XHv /XMpiB7T1RfZOTaSYVm3t94l6Mw/XGMEI6cMI10DSpVm+VQd/gATQzOYQJkWsZscmJxj GgJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uHi8yqcYODc/Ev1hHv8xzBi8Vd13qOOwJOLKj55fUsw=; b=QwkiPGveWiz18soUcyVkfwqRxXCvSAhg/btwxqQ5ST8Wgn2+IF4OKBbnbixMiFw4bQ S3Xox8IUkpCIYnBYk7gqmYbzieeOLmBMbn0F7+5gvBahH8WYCvmFm3ZyLA9dyWJ7p5ap sBhY3Kzj2sN4ZysHEFzvf5xArxvIccTLjEEWq19VPde7Hw3bJ4p8qgYXrf0d0SaFksmY x7qHIPMUQaf3CRbIKQpKXm0i++cK33I/TOenacMbIJ5mHufAtgpx1Ogl+tYraBxLcGIa IsJSAs2XvdWhK/YJtqftZblBZeSSyEPW0puQQ0sTzPt3yeZHzm+nxEmEA7Oc1ZAU1FgJ etUQ== X-Gm-Message-State: AMke39mQwJN5XSCs7pDETxMtQmorpTSNgLhwFz7yo06Oo8/uutZAsdfj6VONmkC+/J0dNlu/8ZJkyOIN9+BUQdNV X-Received: by 10.37.178.1 with SMTP id i1mr5957726ybj.44.1489104263280; Thu, 09 Mar 2017 16:04:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.8.65 with HTTP; Thu, 9 Mar 2017 16:04:22 -0800 (PST) In-Reply-To: References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> From: Wenbo Zhu Date: Thu, 9 Mar 2017 16:04:22 -0800 Message-ID: Subject: Re: Divergence from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=f403045e4beaa5d279054a551ae1 Archived-At: Cc: Ian Swett , "quic@ietf.org" , Stefan Eissing X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:40:25 -0000 --f403045e4beaa5d279054a551ae1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 3:23 PM, Mike Bishop wrote: > Actually, that=E2=80=99s almost exactly what the draft already says: > > On receipt of an Alt-Svc header indicating HTTP/QUIC support, a client MA= Y > > attempt to establish a QUIC connection to the indicated host and port and= , > if > > successful, send HTTP requests using the mapping described in this > document. > > > > Connectivity problems (e.g. firewall blocking UDP) can result in QUIC > connection > > establishment failure, in which case the client SHOULD continue using the > > existing connection or try another alternative endpoint offered by the > origin. > > > > Is there something you think we need to add to that? > No. The editor copy looks good. (sorry for commenting on the wrong copy). =3D=3D=3D Given that http/quic is not http2/quic, protocols that want quic will likely have to support both http/quic (or quic) and http/2 as transports. I wonder if a better situation would be for quic to provide its own TCP alternative, or such an alternative would end up being as difficult as doing http2/quic. > > > *From:* Wenbo Zhu [mailto:wenboz@google.com] > *Sent:* Thursday, March 9, 2017 2:39 PM > > *To:* Mike Bishop > *Cc:* Ian Swett ; Stefan Eissing < > stefan.eissing@greenbytes.de>; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > > > > > On Thu, Mar 9, 2017 at 10:54 AM, Mike Bishop > wrote: > > Well, since we=E2=80=99re talking about failing to connect to an alternat= ive, we > could just say that the client should fall back to the origin or a > different alternative, per RFC7838. That removes any mention of a > particular transport or a particular HTTP version. > > Yes, mentioning RFC-7838 will be good. > > > > > > *From:* Wenbo Zhu [mailto:wenboz@google.com] > *Sent:* Thursday, March 9, 2017 10:45 AM > *To:* Mike Bishop > *Cc:* Ian Swett ; Stefan Eissing < > stefan.eissing@greenbytes.de>; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > The HTTP mapping draft states: > > > > "Connectivity problems (e.g. firewall blocking UDP) may result in > QUIC connection establishment failure, in which case the client > should gracefully fall back to HTTP/2" > > > > If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seems t= o > me that QUIC should define its own TCP fallback (as "slow" and simple as = it > needs be) .. .or will doing so create yet again another protocol variant > for what http mapping is concerned? ( p.s. sorry if this has already be= en > discussed before ...) > > > > On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop > wrote: > > To me, it=E2=80=99s a *mostly* editorial difference =E2=80=93 do we try t= o contort the > IANA registry to claim these are two variants of the same protocol, or do > we just tell IANA they=E2=80=99re different protocols with different regi= stries? I > don=E2=80=99t see that one choice implies a larger scope than the other. = I think > the mission is still the same =E2=80=93 deliver HTTP semantics over QUIC. > > > > We=E2=80=99ve already decided we=E2=80=99re willing to make a number of d= epartures from > HTTP/2 because it makes technical sense in each individual case. > Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional > streams in each direction) the HTTP mapping would do likewise in response > (see branch unidirectional2). > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Thursday, March 9, 2017 6:28 AM > *To:* Stefan Eissing > *Cc:* Mike Bishop ; quic@ietf.org > *Subject:* Re: Divergence from HTTP/2 > > > > Thanks for sending this out to the list. I always hoped we could keep > HTTP over QUIC as similar to H2 as possible, but as you've pointed out > previously, a lot of HTTP/2 was adding transport features such as multipl= e > streams and flow control on top of an existing transport. Switching to > QPACK would be another dramatic departure. > > > > I'm not excited about QUIC abandoning HTTP2, but it may make enough > technical and documentation sense to be the right thing to do. I am > concerned this could expand the scope of the HTTP mapping too much, so if > we're going to make this choice, I'd like to know what types of changes a= re > in scope. > > > > On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing < > stefan.eissing@greenbytes.de> wrote: > > Thanks for separating this out, Mike. For spare time folks this makes > following this aspect easier. > > > > My first impression is that any hope to have http/2 over tcp and quic > needs to be abandoned. Which will give the world a third protocol to carr= y > http semantics. > > > > What does that mean for the evolution of http, I wonder. > > > > -stefan > > > Am 09.03.2017 um 03:16 schrieb Mike Bishop = : > > At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and HT= TP/2 are > the same protocol. However, the draft currently still attempts to define > them as close cousins. In PR #363 > , I=E2=80=99ve consolidat= ed > almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new= section and > excised a lot of stuff about =E2=80=9CHTTP/2 has this, but HTTP/QUIC does= n=E2=80=99t need > it=E2=80=9D from the main body of the document. Martin has advocated mak= ing a > clean break from HTTP/2 and defining our own IANA registry for frame type= s > and settings, just as we already have for errors. We can, out of respect > for legacy, use the same values where appropriate and reserve existing > values currently in use on the HTTP/2 side. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from the WG about either would be welcome. > > > > > > > --f403045e4beaa5d279054a551ae1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


<= br>
On Thu, Mar 9, 2017 at 3:23 PM, Mike Bishop <= span dir=3D"ltr"><Michael.Bishop@microsoft.com> wrote:

Actually, that=E2=80=99s almost exactly what the dra= ft already says:

On receipt of an Alt-Svc= header indicating HTTP/QUIC support, a client MAY

attempt to establish a Q= UIC connection to the indicated host and port and, if

successful, send HTTP re= quests using the mapping described in this document.

=C2=A0

Connectivity problems (e= .g. firewall blocking UDP) can result in QUIC connection

establishment failure, i= n which case the client SHOULD continue using the

existing connection or t= ry another alternative endpoint offered by the origin.

=C2=A0

Is there something you think we need to add to that?=

No. The editor copy looks good. =C2=A0(so= rry for commenting on the wrong copy).

=3D=3D=3D

Given that http/quic is not http2/quic, protocols t= hat want quic will likely have to support both http/quic (or quic) and http= /2 as transports. I wonder if a better situation would be for quic to provi= de its own TCP alternative, or such an alternative would end up being as di= fficult as doing http2/quic.

=C2=A0

=

=C2=A0

From: Wenbo Zhu [mailt= o:wenboz@google.com<= /a>]
Sent: Thursday, March 9, 2017 2:39 PM

=

=C2=A0

=C2=A0

=C2=A0

On Thu, Mar 9, 2017 at 10:54 AM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:

Well, since we=E2=80=99re talking about failing to c= onnect to an alternative, we could just say that the client should fall bac= k to the origin or a different alternative, per RFC7838.=C2=A0 That removes any mention of a particular transport or a particular HTTP ve= rsion.

Yes, mentioning RFC-7838 will be good.=C2=A0<= u>

=C2=A0

=C2=A0

From: Wenbo Zhu [mailto:wenboz@google.com]
Sent: Thursday, March 9, 2017 10:45 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Ian Swett <ianswett@google.com>; Stefan Eissing <stefan.eissing@greenbytes.de<= /a>>; quic@ietf.org
Subject: Re: Dive= rgence from HTTP/2

=C2=A0

The HTT= P mapping draft states:

=C2=A0

"<= span style=3D"color:black">Connectivity problems (e.g. firewall blocking UD= P) may result in QUIC=C2=A0connection establishment failure, in which case the client should=C2=A0gracefully fall back to HTTP/2"

=C2=A0

If QUIC and its HTTP mapping serve effectively as HTTP/3, then it seem= s to me that QUIC should define its own TCP fallback (as "slow" and simple as it needs be) .. .or will doing so creat= e yet again another protocol variant for what http mapping is concerned? = =C2=A0 ( p.s. sorry=C2=A0if this has already been discussed before ...)

=C2=A0

On Thu, Mar 9, 2017 at 7:59 AM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to contort the IANA = registry to claim these are two variants of the same protocol, or do we jus= t tell IANA they=E2=80=99re different protocols with different registries?= =C2=A0 I don=E2=80=99t see that one choice implies a larger scope than the other.=C2=A0 I think the mission is still the same =E2=80=93 deli= ver HTTP semantics over QUIC.

=C2=A0

We=E2=80=99ve already decided we=E2=80=99re willing = to make a number of departures from HTTP/2 because it makes technical sense= in each individual case.=C2=A0 Obviously, if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in each direction) the HTTP mapping= would do likewise in response (see branch unidirectional2).<= /p>

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Thursday, March 9, 2017 6:28 AM
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; quic@ietf.org
Subject: Re: Divergence from HTTP/2

=C2=A0

Thanks for sending this out to the list.=C2=A0 I alw= ays hoped we could keep HTTP over QUIC as similar to H2 as possible, but as= you've pointed out previously, a lot of HTTP/2 was adding transport features such as multiple streams and flow control on top of an = existing transport.=C2=A0 Switching to QPACK would be another dramatic depa= rture.

=C2=A0

I'm not excited about QUIC abandoning HTTP2, but= it may make enough technical and documentation sense to be the right thing= to do.=C2=A0 I am concerned this could expand the scope of the HTTP mapping too much, so if we're going to make this choice, I= 9;d like to know what types of changes are in scope.=C2=A0

=C2=A0

On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing <<= a href=3D"mailto:stefan.eissing@greenbytes.de" target=3D"_blank">stefan.eis= sing@greenbytes.de> wrote:

Thanks for separating this out, Mike. For spare time= folks this makes following this aspect easier.

=C2=A0

My first impression is that any hope to have http/2 = over tcp and quic needs to be abandoned. Which will give the world a third = protocol to carry http semantics.

=C2=A0

What does that mean for the evolution of http, I won= der.

=C2=A0=

-stefan


Am 09.03.2017 um 03:16 schrieb Mike Bishop <Michael.Bishop@microsoft.com><= wbr>:

At this point, I don=E2=80=99t think anyone expects = that HTTP/QUIC and HTTP/2 are the same protocol.=C2=A0 However, the draft c= urrently still attempts to define them as close cousins.=C2=A0 In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdiffere= nt from HTTP/2=E2=80=9D text into a new section and excised a lot of stuff = about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D from the main body of the document.=C2=A0 Martin has advocated making a clean b= reak from HTTP/2 and defining our own IANA registry for frame types and set= tings, just as we already have for errors.=C2=A0 We can, out of respect for= legacy, use the same values where appropriate and reserve existing values currently in use on the HTTP/2 side.=

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from the WG about either would be welcome.<= u>

=C2=A0

=C2=A0

=C2=A0


--f403045e4beaa5d279054a551ae1-- From nobody Thu Mar 9 18:45:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED41294E1 for ; Thu, 9 Mar 2017 18:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 ATGTTTac8oMz for ; Thu, 9 Mar 2017 18:45:31 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76794129506 for ; Thu, 9 Mar 2017 18:45:29 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id y76so149852233qkb.0 for ; Thu, 09 Mar 2017 18:45:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aNCyN84oHXwoYmhATO+eazU2tQNA/l9Ihw4i0zV4RFo=; b=ZxB0etzds9MEDQayWEW0EWciimaa2VzASmtHgM+NgKWA7Pb567NRmT3aXzTbXqIdrZ eXO+8f14dB1ASuKudMrXUoh9bLO3+Icni64+VTza5QUuc/MEDpxUQQf6gGP6ftk+XCva S10d7nb89P3YD3NaT/moaS+DkPO347sHRWM+AFRMjafpi25/r9+joiakCob9zjef0vO4 AiN4LH0SxmLYAj1r2Hx95X49Mmv/FUm60sY6ztSI+DogdbkwYNE+brej/OdHWHBM7JF1 9tsjMMNDINAQGXAqzA5tWDqQio5eU60TXFAu3lBmleT1YDpCPgxghQ5wsxsrt6VTB4Va Q+IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aNCyN84oHXwoYmhATO+eazU2tQNA/l9Ihw4i0zV4RFo=; b=CPynio7XVO4Uc8scqo1AJhNNoPmC1aUb19/8UyOujawme4XeXaveUbEHEAdpTrkhHg 2r+94l2RyOyIpj+I7qsRlA+Cy8H72B8v7yTn++ZuLSPTBtDfpzKVSNTvzWAcQA1mdkqd mdNGw8UzgYolYXUF0mX5BEjy+3/IfXwFhiwH0T3hn+GHx2HO4UFYQbzTiymDoRkiMnoP 3xO5zwxLCvVRJzGRp/V/YS88D4CtSQPBlZRA39Uf0lNtAW3jtA0BPyr/F1+V+LOQUvat N0fyMXeNO1PHXnYwuyRaQAbZFVZajgPC0RbyS3U/b7dxNtJv+YF7LgnqO2EcVkySolt5 Q8xw== X-Gm-Message-State: AMke39necsf5BJcphNj4nrDnoyeYWjj/mbEVjn48OUbTZmP2kUojnUkGhyoM1BcmRMCDpZwOv32F+Xmqye5PzQ== X-Received: by 10.200.46.91 with SMTP id s27mr17876386qta.278.1489102724130; Thu, 09 Mar 2017 15:38:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Mar 2017 15:38:43 -0800 (PST) In-Reply-To: <0A814D18-F9D9-4901-B588-6F99A84E6088@greenbytes.de> References: <1937571D-7321-4DEA-9233-F20B9CC5D299@greenbytes.de> <0A814D18-F9D9-4901-B588-6F99A84E6088@greenbytes.de> From: Martin Thomson Date: Fri, 10 Mar 2017 10:38:43 +1100 Message-ID: Subject: Re: Divergence from HTTP/2 To: Stefan Eissing Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mike Bishop , Ian Swett , "quic@ietf.org" , Patrick McManus X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 02:45:32 -0000 The goal should remain as you say: to keep the differences minimal. I don't see us creating a protocol that doesn't have a stream for each request, for example. At some level, the abstractions will have to be the same (it's HTTP after all), but ideally we keep more common pieces than that. There are some things that just don't hold any more. You can't rely on absolute order between frames when they cross streams for instance. Unfortunately, that means that we can't assume that extension frames or settings will work automatically. Mike's text on this actually helps clarify this quite a lot, which should mean that new designs for h2 can be made with hq in mind so that they won't need any adjustment. On 10 March 2017 at 08:56, Stefan Eissing wr= ote: > I think registering frame types and whatnot as a new protocol for carryin= g > http semantics is wise. Keeping frame names/numbers with same semantics i= s > good for it can ease understanding, it is not mandatory. > > I would hope that new frame types can be deployed in http/2 without also > reserving them in hq (and vice versa). Otherwise the burden for people > making extensions might be unnecessarily high. > > As an implementor, the question is how to make the abstractions work insi= de > a product supposed to support several transports for http applications. b= ut > that is outside the scope of the WGs and maybe rightly so. > > Interestig times. > > -stefan > > Am 09.03.2017 um 19:21 schrieb Patrick McManus : > > Mike, I think it would be good if you resent the question - particularly = the > bit about registries - in a new email with full background to both the qu= ic > and httpbis lists... That community might have opinions as well and QUIC = wg > is chartered explicitly to work closely with them. > > my opinion has solidified over time to the "separate protocols but same > semantics (i.e. hq=3D=3Dh3)" position - esp wrt qpack which I think will = be very > valuable for hq. > > -P > > > On Thu, Mar 9, 2017 at 10:59 AM, Mike Bishop > wrote: >> >> To me, it=E2=80=99s a mostly editorial difference =E2=80=93 do we try to= contort the IANA >> registry to claim these are two variants of the same protocol, or do we = just >> tell IANA they=E2=80=99re different protocols with different registries?= I don=E2=80=99t >> see that one choice implies a larger scope than the other. I think the >> mission is still the same =E2=80=93 deliver HTTP semantics over QUIC. >> >> >> >> We=E2=80=99ve already decided we=E2=80=99re willing to make a number of = departures from >> HTTP/2 because it makes technical sense in each individual case. Obviou= sly, >> if QUIC takes a dramatic turn (e.g. unrelated unidirectional streams in = each >> direction) the HTTP mapping would do likewise in response (see branch >> unidirectional2). >> >> >> >> From: Ian Swett [mailto:ianswett@google.com] >> Sent: Thursday, March 9, 2017 6:28 AM >> To: Stefan Eissing >> Cc: Mike Bishop ; quic@ietf.org >> Subject: Re: Divergence from HTTP/2 >> >> >> >> Thanks for sending this out to the list. I always hoped we could keep >> HTTP over QUIC as similar to H2 as possible, but as you've pointed out >> previously, a lot of HTTP/2 was adding transport features such as multip= le >> streams and flow control on top of an existing transport. Switching to >> QPACK would be another dramatic departure. >> >> >> >> I'm not excited about QUIC abandoning HTTP2, but it may make enough >> technical and documentation sense to be the right thing to do. I am >> concerned this could expand the scope of the HTTP mapping too much, so i= f >> we're going to make this choice, I'd like to know what types of changes = are >> in scope. >> >> >> >> On Thu, Mar 9, 2017 at 4:07 AM, Stefan Eissing >> wrote: >> >> Thanks for separating this out, Mike. For spare time folks this makes >> following this aspect easier. >> >> >> >> My first impression is that any hope to have http/2 over tcp and quic >> needs to be abandoned. Which will give the world a third protocol to car= ry >> http semantics. >> >> >> >> What does that mean for the evolution of http, I wonder. >> >> >> >> -stefan >> >> >> Am 09.03.2017 um 03:16 schrieb Mike Bishop : >> >> At this point, I don=E2=80=99t think anyone expects that HTTP/QUIC and H= TTP/2 are >> the same protocol. However, the draft currently still attempts to defin= e >> them as close cousins. In PR #363, I=E2=80=99ve consolidated almost all= of the >> =E2=80=9Cdifferent from HTTP/2=E2=80=9D text into a new section and exci= sed a lot of stuff >> about =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2= =80=9D from the main body of >> the document. Martin has advocated making a clean break from HTTP/2 and >> defining our own IANA registry for frame types and settings, just as we >> already have for errors. We can, out of respect for legacy, use the sam= e >> values where appropriate and reserve existing values currently in use on= the >> HTTP/2 side. >> >> >> >> I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step= from the current >> state of #363. I=E2=80=99ve created PR #376 to actually make that split= . >> >> >> >> Comments from the WG about either would be welcome. >> >> > > From nobody Thu Mar 9 19:06:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E4512951B for ; Thu, 9 Mar 2017 19:06:49 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDUHztKXopSQ for ; Thu, 9 Mar 2017 19:06:41 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B851C12947E for ; Thu, 9 Mar 2017 18:59:55 -0800 (PST) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5921)) with SMTP id <0000985813@smtp.qbik.com>; Fri, 10 Mar 2017 15:59:52 +1300 From: "Adrien de Croy" To: "Mike Bishop" , "quic@ietf.org" , "HTTP working group mailing list" Subject: Re: HTTP/QUIC Diverging from HTTP/2 Date: Fri, 10 Mar 2017 02:59:52 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBCC162149-CA28-431C-93E8-0CBA13C30F5C" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrien de Croy List-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 Mar 2017 03:06:49 -0000 --------=_MBCC162149-CA28-431C-93E8-0CBA13C30F5C Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike for the benefit of those of us who maybe aren't so familiar with QUIC,=20 are there any good resources you can refer us to which deal with the=20 bigger picture such as why even have QUIC? So far our experience with QUIC (as a proxy) has been to simply block=20 it, since it provides a bypass mechanism for proxy control. Regards Adrien ------ Original Message ------ From: "Mike Bishop" To: "quic@ietf.org" ; "HTTP working group mailing list"=20 Sent: 10/03/2017 3:09:57 PM Subject: RE: HTTP/QUIC Diverging from HTTP/2 >Summary of feedback on this so far: > >Ekr: =E2=80=9CHoping we can converge, or at least maximize overlap=E2=80= =9DStefan: =20 >=E2=80=9Cany hope to [converge] needs to be abandoned=E2=80=9DIan: =E2= =80=9Cnot excited=E2=80=A6 but=20 >it may=E2=80=A6 be the right thing to do=E2=80=9DPatrick: =E2=80=9Csepara= te protocols=E2=80=9DMartin: =20 >=E2=80=9Ckeep the differences minimal=E2=80=9D but =E2=80=9Cwe're really= building a new=20 >protocol=E2=80=9DAlcides: if it=E2=80=99s different, make the differences= clear > > >If I=E2=80=99ve misconstrued anyone=E2=80=99s response, please speak now;= and=20 >obviously, more opinions are welcome. I would also appreciate reviews=20 >on the text of the PRs themselves. > > > >Unless there=E2=80=99s strong pushback in the next ~14 hours, I expect = to=20 >incorporate both PRs tomorrow, prior to the -02 publication. As Mark=20 >noted recently, that doesn=E2=80=99t claim full consensus has been reached= , but=20 >there appears to be general support for considering these separate=20 >protocols which are closely related, rather than two variants of a=20 >single protocol. > > > >From: Mike Bishop >Sent: Thursday, March 9, 2017 10:54 AM >To:quic@ietf.org; HTTP working group mailing list >Subject: HTTP/QUIC Diverging from HTTP/2 > > > >At Patrick=E2=80=99s suggestion, I=E2=80=99m restating this question and= addressing it=20 >to both the HTTP and QUIC working groups. Apologies if you=E2=80=99re = already=20 >following along in QUIC and get this twice after having already seen it= =20 >the first time. > > > >HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session= =20 >on QUIC Stream 3, including a full HTTP/2 multiplexing layer within=20 >Stream 3. A number of HTTP/2 frames weren=E2=80=99t necessary, since they= were=20 >duplicative of services QUIC provides. In draft -01, we removed the=20 >full mux layer from Stream 3, instead letting QUIC deal with all the=20 >stream management. This necessitated changes to several of the=20 >remaining frames. By the current editor=E2=80=99s copy, no HTTP/2 frame= exists=20 >unmodified in HTTP/QUIC, though several frames of the same name and=20 >purpose exist. Likewise, RFC7540 defines six settings, three of which=20 >are inapplicable in HTTP/QUIC. > > > >However, the draft currently still attempts to define them as close=20 >cousins. It updates the HTTP/2 frame and setting registries with=20 >additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC=20 >Specification if applicable) and attempts to coexist with HTTP/2 in the= =20 >same registry. (QUIC defines a unified error space, which means a=20 >separate registry of error codes for HTTP/QUIC regardless.) > > > >In PR #363 , I=E2=80=99= ve=20 >consolidated almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D = text into a new=20 >top-level section and excised a lot of =E2=80=9CHTTP/2 has this, but HTTP/= QUIC=20 >doesn=E2=80=99t need it=E2=80=9D text from the main body of the document.= Martin has=20 >advocated making a clean break from HTTP/2 and defining our own IANA=20 >registry for frame types and settings, just as we already have for=20 >errors. We can, out of respect for our cousin, use the same values=20 >where appropriate and reserve existing values currently in use on the=20 >HTTP/2 side. > > > >I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step= from the=20 >current state of #363. I=E2=80=99ve created PR #376=20 > to actually make that=20 >split. > > > >Comments from both WGs about the two PRs would be welcome. (Feedback=20 >so far from the QUIC side seems to mostly be =E2=80=9Cseparate with regret= s,=E2=80=9D=20 >but not universally.) > --------=_MBCC162149-CA28-431C-93E8-0CBA13C30F5C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Mike

for the bene= fit of those of us who maybe aren't so familiar with QUIC, are there any= good resources you can refer us to which deal with the bigger picture such= as why even have QUIC?

So far our experience= with QUIC (as a proxy) has been to simply block it, since it provides a= bypass mechanism for proxy control.

Regards

Adrien


------ Original Message ------
From: "Mike Bishop" <Michael.Bishop@microsoft.com>
To: "quic@ietf.org" <quic@ietf.org= >; "HTTP working group mailing list" <ietf-http-wg@w3.org>
Sent: 10/03/2017 3:09:57 PM
Subject: RE: HTTP/QUIC Diverging from HTTP/2

Summary of feedback on this so far:

  • E= kr:=C2=A0 =E2=80=9CHoping we can converge, or at least maximize overlap=E2= =80=9D
  • Stefan:=C2=A0 =E2=80=9Cany = hope to [converge] needs to be abandoned=E2=80=9D=
  • Ian:=C2=A0 =E2=80=9Cnot excited=E2=80=A6 but it may=E2=80=A6= be the right thing to do=E2=80=9D
    • Patr= ick:=C2=A0 =E2=80=9Cseparate protocols=E2=80=9D
  • Martin:=C2=A0 =E2=80=9Ckeep the differences minimal=E2=80=9D but= =E2=80=9Cwe're really building a new protocol=E2=80=9D
  • Alcides:=C2=A0 if it=E2=80=99s different, make the differen= ces clear

=C2=A0

If I=E2=80=99ve misconstrued anyone=E2=80=99s respon= se, please speak now; and obviously, more opinions are welcome.=C2=A0 I = would also appreciate reviews on the text of the PRs themselves.

=C2=A0

Unless there=E2=80=99s strong pushback in the next= ~14 hours, I expect to incorporate both PRs tomorrow, prior to the -02 = publication.=C2=A0 As Mark noted recently, that doesn=E2=80=99t claim full= consensus has been reached, but there appears to be general support for considering these separate protocols which are closely related= , rather than two variants of a single protocol.<= /o:p>

=C2=A0

From: Mike Bishop
Sent: Thursday, March 9, 2017 10:54 AM
To: quic@ietf.org; HTTP working= group mailing list <ietf-http-wg= @w3.org>
Subject: HTTP/QUIC Diverging from HTTP/2

=C2=A0

At Patrick=E2=80=99s suggestion, I=E2=80=99m restati= ng this question and addressing it to both the HTTP and QUIC working groups= .=C2=A0 Apologies if you=E2=80=99re already following along in QUIC and = get this twice after having already seen it the first time.

=C2=A0

HTTP/QUIC started off (draft -00) with a mostly-comp= lete HTTP/2 session on QUIC Stream 3, including a full HTTP/2 multiplexing= layer within Stream 3.=C2=A0 A number of HTTP/2 frames weren=E2=80=99t = necessary, since they were duplicative of services QUIC provides.=C2=A0 In draft -01, we removed the full mux layer from Stre= am 3, instead letting QUIC deal with all the stream management.=C2=A0 This= necessitated changes to several of the remaining frames.=C2=A0 By the curr= ent editor=E2=80=99s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frame= s of the same name and purpose exist.=C2=A0 Likewise, RFC7540 defines six= settings, three of which are inapplicable in HTTP/QUIC.

=C2=A0

However, the draft currently still attempts to defin= e them as close cousins.=C2=A0 It updates the HTTP/2 frame and setting regi= stries with additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Spec= ification if applicable) and attempts to coexist with HTTP/2 in the same registry.=C2=A0 (QUIC defines a unified= error space, which means a separate registry of error codes for HTTP/QUIC= regardless.)

=C2=A0

In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdifferent= from HTTP/2=E2=80=9D text into a new top-level section and excised a lot= of =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80= =9D text from the main body of the document.=C2=A0 Martin has advocated = making a clean break from HTTP/2 and defining our own IANA registry for frame types and setting= s, just as we already have for errors.=C2=A0 We can, out of respect for = our cousin, use the same values where appropriate and reserve existing valu= es currently in use on the HTTP/2 side.

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99= s a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve= created PR #376 to= actually make that split.

=C2=A0

Comments from both WGs about the two PRs would be= welcome.=C2=A0 (Feedback so far from the QUIC side seems to mostly be =E2= =80=9Cseparate with regrets,=E2=80=9D but not universally.)

--------=_MBCC162149-CA28-431C-93E8-0CBA13C30F5C-- From nobody Thu Mar 9 19:12:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15264129547 for ; Thu, 9 Mar 2017 19:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw44tstl0Oi4 for ; Thu, 9 Mar 2017 19:12:50 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3AF129530 for ; Thu, 9 Mar 2017 19:12:50 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id y76so150472690qkb.0 for ; Thu, 09 Mar 2017 19:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AWZUCc+HpJP7cJrohKYD31SKM8cfhXxyrTBXVSOJ/nU=; b=aa0xau4gjXmPaLuNHXZ1GdcSujAyly8fdmws1bYNe+qlpzXAz8C3KWsF+R9FgVWCgl FVzWE6/PK2cIlTEjtAbZcyruDOpY6GmICgQGEInLO9M5fknBkNwxP7CWYMwAdH0xDtcX BGXMpRqGQNSy37MdqqmFZ3FPkWpcQyBRX76ymwsQJKK9eEOLFZWc1yWkQEoEqp/vhwDA jB/J2Gdk3q2AC0DNKeAeSmQ3JKtDrW1oaLlck4P8mMO0fQcMOuDXKpmkhlnx2E5mHM5j Sk190EFRShZ7a3khwDUxkgScpdcWrYW1DUq4eXDTJ6HhddthjqS4Tw3jVnAb3yxycco+ Z1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AWZUCc+HpJP7cJrohKYD31SKM8cfhXxyrTBXVSOJ/nU=; b=O8vsKYXFDUu798N8r/bZkN63y95EL8SkwWAedZhGJE5y7iW4H5ktkDEXFqXHIMYlKQ Ptf1i6+QgToZPHiyNglLUuKXKUfnur0ug8gotiwB77c9ASYcMxhKVfajr3vcE6jiRkTF JW7DNcbPLhGHD13METxyvB3kMfsihjHMKRaVjOd9YKRGW5CUaCLjjubDHGyAAqPNQgGk b61SFufo5Bumg7RoHGCSqSQdjYjv9BigNJ1DkXrj2/JyAlr4tGdPp6IoaJv8RbZlgALI 65VlRyuw+SHxWV/YldGvT7exfdad/C3XpemqZ+GviDV7g/knzAGjxJQ0GgjvqLs4dvQs 074w== X-Gm-Message-State: AMke39mBvwvbejykydF01QOo2Pt0Wo5zMzl+4bUVJ2JWDaIPkRKKWtNofG2DyAx7qM9JhkaU5JeWeuf0Z8IiEg== X-Received: by 10.200.46.91 with SMTP id s27mr18585064qta.278.1489115569008; Thu, 09 Mar 2017 19:12:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Mar 2017 19:12:48 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 10 Mar 2017 14:12:48 +1100 Message-ID: Subject: Re: HTTP/QUIC Diverging from HTTP/2 To: Adrien de Croy Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:12:52 -0000 On 10 March 2017 at 13:59, Adrien de Croy wrote: > for the benefit of those of us who maybe aren't so familiar with QUIC, are > there any good resources you can refer us to which deal with the bigger > picture such as why even have QUIC? This probably isn't the place for that discussion. I would recommend reading the drafts. They aren't complete, but you will gain some appreciation for what is going on. Think about this in terms of replacing TCP, not HTTP. There are higher level things around, like this old presentation: https://docs.google.com/presentation/d/1T9GtMz1CvPpZtmF8g-W7j9XHZBOCp9cu1fW0sMsmpoo From nobody Thu Mar 9 19:19:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30869129547 for ; Thu, 9 Mar 2017 19:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 9SoaH-9anUvS for ; Thu, 9 Mar 2017 19:19:10 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8CC12951B for ; Thu, 9 Mar 2017 19:19:09 -0800 (PST) Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5921)) with SMTP id <0000985833@smtp.qbik.com>; Fri, 10 Mar 2017 16:19:07 +1300 From: "Adrien de Croy" To: "Martin Thomson" Subject: Re: HTTP/QUIC Diverging from HTTP/2 Date: Fri, 10 Mar 2017 03:19:07 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mike Bishop , "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Adrien de Croy List-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 Mar 2017 03:19:12 -0000 thanks for that. Yes, the whole meta discussion about why / benefits etc can influence=20 adoption pressure, and decisions around whether we should support it or=20 block it. Cheers Adrien ------ Original Message ------ From: "Martin Thomson" To: "Adrien de Croy" Cc: "Mike Bishop" ; "quic@ietf.org"=20 ; "HTTP working group mailing list" Sent: 10/03/2017 4:12:48 PM Subject: Re: HTTP/QUIC Diverging from HTTP/2 >On 10 March 2017 at 13:59, Adrien de Croy wrote: >> for the benefit of those of us who maybe aren't so familiar with=20 >>QUIC, are >> there any good resources you can refer us to which deal with the=20 >>bigger >> picture such as why even have QUIC? > > >This probably isn't the place for that discussion. I would recommend >reading the drafts. They aren't complete, but you will gain some >appreciation for what is going on. Think about this in terms of >replacing TCP, not HTTP. There are higher level things around, like >this old presentation: >https://docs.google.com/presentation/d/1T9GtMz1CvPpZtmF8g-W7j9XHZBOCp9cu1f= W0sMsmpoo From nobody Thu Mar 9 19:25:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC01E1295A1 for ; Thu, 9 Mar 2017 19:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K800kcvsEJHH for ; Thu, 9 Mar 2017 19:25:13 -0800 (PST) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431FE12959D for ; Thu, 9 Mar 2017 19:25:12 -0800 (PST) Subject: Re: HTTP/QUIC Diverging from HTTP/2 To: Adrien de Croy , Martin Thomson References: From: Andy Green Message-ID: <5e8c43a6-fd15-6cdc-c507-ca33e64b7206@warmcat.com> Date: Fri, 10 Mar 2017 11:25:02 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mike Bishop , "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 03:25:15 -0000 On 03/10/2017 11:19 AM, Adrien de Croy wrote: > > thanks for that. > > Yes, the whole meta discussion about why / benefits etc can influence > adoption pressure, and decisions around whether we should support it > or block it. If I can run websockets over it, it will already be more useful than http/2 for me... -Andy > > Cheers > > Adrien > > > ------ Original Message ------ > From: "Martin Thomson" > To: "Adrien de Croy" > Cc: "Mike Bishop" ; "quic@ietf.org" > ; "HTTP working group mailing list" > Sent: 10/03/2017 4:12:48 PM > Subject: Re: HTTP/QUIC Diverging from HTTP/2 > >> On 10 March 2017 at 13:59, Adrien de Croy wrote: >>> for the benefit of those of us who maybe aren't so familiar with >>> QUIC, are >>> there any good resources you can refer us to which deal with the >>> bigger >>> picture such as why even have QUIC? >> >> >> This probably isn't the place for that discussion. I would recommend >> reading the drafts. They aren't complete, but you will gain some >> appreciation for what is going on. Think about this in terms of >> replacing TCP, not HTTP. There are higher level things around, like >> this old presentation: >> https://docs.google.com/presentation/d/1T9GtMz1CvPpZtmF8g-W7j9XHZBOCp9cu1fW0sMsmpoo >> > > From nobody Thu Mar 9 20:33:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DED1295C7 for ; Thu, 9 Mar 2017 20:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Iz3z0HEKVC89 for ; Thu, 9 Mar 2017 20:33:07 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FDF71295BE for ; Thu, 9 Mar 2017 20:33:07 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id u108so57490142wrb.3 for ; Thu, 09 Mar 2017 20:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xbk8O05Q3l9lwYObVPFKmL4W5mNba+5wF4XMn/0qI3s=; b=IwOI7XilNCXW+QVxe7X1qeLRGqTwW/1SWyo7KkwQmwVxrQ+Kf/X7lTr3Sv1hOprG4C CSOeM49tFy9r0ajxeqZxMIJ0alBNwXPe2obLEEUbqqLyJ9zs9mjr4bDDwGBSn9EI+3kp N4ZHoVeT2Prf5ZNToXFj5+g4rpTW3+3/1GyIYVf4HVJfg34XsYjfH3AVIC8+/9lYJXLo SKHXn698JQp1ANQ9Zk2+ZYoYJnN2xndOPn0LCP54Bl2Kmh6EfCdb/OYfbk2RKA2CsSlG gz4tfQskg+EDAkCoK4uNhkrO2qdIpowXgjDCVj0/BeKgy4WkzJnFgo8nYHdf0ev2maTC hWWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xbk8O05Q3l9lwYObVPFKmL4W5mNba+5wF4XMn/0qI3s=; b=CU+6dIOfV0x0uek95TcA45LFOpqIBM8uOxuLeOXzkdLPexskPcAStD8TTVc8S8XA/V bpX4I1llvEoUDJi+QqKQfXc0qcw2CxHC3vmw8oXT6nACailiWdEqUQYv44dFc1aSJRrS Mu6rgw8KZ2heUcfOh4gebs8StujROMr60RUtXypyQsd+4P6yES9Bi7X/uizC9d+kLeGJ WLT3AqmLps6oSz2mmp9Ys+nUkZ1vmV+svqTRVG85EFQfngNQ2GJT/G/lZ0x3yXdbavrH 7rgLunGFjjwbXQkglInH5uRu/GkZYE3PDOoGIG1e9BYY3dwueuTEweaAF/fuRzsE7JRE 3jtg== X-Gm-Message-State: AMke39keVk4RhrGnWhfz/1EjKl5nzLj8x156KtGd/UMr9QwVEHVHD5KaH4lyHM+l/NE9EaS/csvU6iOvAgDNl+gD X-Received: by 10.223.174.164 with SMTP id y33mr13637339wrc.166.1489120385907; Thu, 09 Mar 2017 20:33:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.19.7 with HTTP; Thu, 9 Mar 2017 20:33:05 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 9 Mar 2017 20:33:05 -0800 Message-ID: Subject: Re: HTTP/QUIC Diverging from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=001a11409574a18722054a58dbba Archived-At: Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 04:33:09 -0000 --001a11409574a18722054a58dbba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop wrote: > Summary of feedback on this so far: > > - Ekr: =E2=80=9CHoping we can converge, or at least maximize overlap= =E2=80=9D > - Stefan: =E2=80=9Cany hope to [converge] needs to be abandoned=E2=80= =9D > - Ian: =E2=80=9Cnot excited=E2=80=A6 but it may=E2=80=A6 be the right= thing to do=E2=80=9D > - Patrick: =E2=80=9Cseparate protocols=E2=80=9D > - Martin: =E2=80=9Ckeep the differences minimal=E2=80=9D but =E2=80= =9Cwe're really building a > new protocol=E2=80=9D > - Alcides: if it=E2=80=99s different, make the differences clear > > > > If I=E2=80=99ve misconstrued anyone=E2=80=99s response, please speak now;= and obviously, > more opinions are welcome. I would also appreciate reviews on the text o= f > the PRs themselves. > > > > Unless there=E2=80=99s strong pushback in the next ~14 hours, I expect to > incorporate both PRs tomorrow, prior to the -02 publication. As Mark > noted recently, that doesn=E2=80=99t claim full consensus has been reache= d, but > there appears to be general support for considering these separate > protocols which are closely related, rather than two variants of a single > protocol. > > =E2=80=8BFor the record, I agree with ekr. As much as possible, let's be si= milar to HTTP/2. Of course, QUIC natively provides multiplexing but does not provide in-order delivery. As a consequence, HTTP over QUIC will have differences.= =E2=80=8B But where we have the opportunities to overlap, that sounds desirable. --001a11409574a18722054a58dbba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 9, 2017 at 6:09 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Summary of feedback on this so far:

  • Ekr:=C2=A0 =E2=80=9CHopin= g we can converge, or at least maximize overlap=E2=80=9D
    • =
  • Stefan:=C2=A0 =E2=80=9Can= y hope to [converge] needs to be abandoned=E2=80=9D
  • Ian:=C2=A0 =E2=80=9Cnot excite= d=E2=80=A6 but it may=E2=80=A6 be the right thing to do=E2=80=9D<= /u>
  • Patrick:=C2=A0 = =E2=80=9Cseparate protocols=E2=80=9D
  • Martin:=C2=A0 =E2=80=9Ckeep the differences m= inimal=E2=80=9D but =E2=80=9Cwe're really building a new protocol=E2=80= =9D
  • Alc= ides:=C2=A0 if it=E2=80=99s different, make the differences clear=

=C2=A0

If I=E2=80=99ve misconstrued anyone=E2=80=99s respon= se, please speak now; and obviously, more opinions are welcome.=C2=A0 I wou= ld also appreciate reviews on the text of the PRs themselves.=

=C2=A0

Unless there=E2=80=99s strong pushback in the next ~= 14 hours, I expect to incorporate both PRs tomorrow, prior to the -02 publication= .=C2=A0 As Mark noted recently, that doesn=E2=80=99t claim full consensus h= as been reached, but there appears to be general support for considering these separate protocols which are closely related= , rather than two variants of a single protocol.


=E2=80=8BFor = the record, I agree with ekr. As much as possible, let's be similar to = HTTP/2. Of course, QUIC natively provides multiplexing but does not provide= in-order delivery. As a consequence, HTTP over QUIC will have differences.= =E2=80=8B But where we have the opportunities to overlap, that sounds desir= able.
--001a11409574a18722054a58dbba-- From nobody Thu Mar 9 21:39:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49BB129555 for ; Thu, 9 Mar 2017 21:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 3D3mU6XuRetB for ; Thu, 9 Mar 2017 21:39:08 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD6412941C for ; Thu, 9 Mar 2017 21:39:08 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 487DF43340F; Fri, 10 Mar 2017 05:39:07 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 31B50433408; Fri, 10 Mar 2017 05:39:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489124347; bh=T9Uay5ZXy/3ZZC0wD8OycKwD6XZgmtQaTD5O+KSiO2s=; l=22678; h=From:To:CC:Date:References:In-Reply-To:From; b=PCefqypBuSgPwopuPFTTnmaK0nFS5G4rcV6tZ7mSB3rG81NbunDQHH7aUKH2zLcez nCSDbIcwqkKQgiqNZLxRbD4YbwIF3L6GFz1kKA7aNRHPUAXdMuiquPDdScEVIW9PiF o6wC7UFLB/hTnxKyWxN9RO/grc2VKT+gkPM4e1pY= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 1783A1FC8D; Fri, 10 Mar 2017 05:39:07 +0000 (GMT) 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.1178.4; Fri, 10 Mar 2017 00:39:06 -0500 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.1178.000; Fri, 10 Mar 2017 00:39:06 -0500 From: "Lubashev, Igor" To: "ekr@rtfm.com" , "jri@google.com" Subject: RE: Middlebox introspection/self-describing packets Thread-Topic: Middlebox introspection/self-describing packets Thread-Index: AQHSmFSC3N3Dd/ULcEG0HqoeLtLnu6GL3nwAgAAyiwCAAJYbgIAAN4KAgAAjfoCAABBvAIAABvaAgAAfnQCAAAKKgIAABKOAgABQSpY= Date: Fri, 10 Mar 2017 05:39:06 +0000 Message-ID: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_9906aa175d054dbbad9b647719f8b42cusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "ietf@trammell.ch" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 05:39:11 -0000 --_000_9906aa175d054dbbad9b647719f8b42cusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The tethering case is real, but it's a corner case; > connection migrations are dominated by > untethered clients. I would not be banking on tethering remaining a fringe activity. This may b= e true today, but it is rapidly changing with proliferation of connected ca= rs, buses, trains, and other mobile hotspots. And I will not even venture a= guess about technologies available in 10-15 years. - Igor -----Original Message----- From: Jana Iyengar [jri@google.com] Received: Thursday, 09 Mar 2017, 2:51PM To: Eric Rescorla [ekr@rtfm.com] CC: Brian Trammell [ietf@trammell.ch]; IETF QUIC WG [quic@ietf.org] Subject: Re: Middlebox introspection/self-describing packets Why not? It's a connection identifier, like the TCP 4-tuple. What do you ga= in from middleboxes not using the connection ID to identify connections? Yeah, I wish they wouldn't use the 4-tuple either. In fact much of this con= versation is driven by them doing nonsense based on the 4-tuple. I understand now. FWIW, the stuff they do, using 4-tuples, includes AQM (se= e FQ-CoDel)... some of these things are useful. I'm not saying that's the = only way to do it, and I've not thought (or know) about all the things that= would break if the notion of flow was obliterated from public view. If you don't have a bit, you can - Look up the host/port - If it's missing assume that there is a connection ID and look for it - If that's missing, drop the packet Yes, I was responding to Brian's email -- apologies for crossing the wires = a bit. This method is plausible, but it increases the work per packet at lo= ad balancers by ~2x. Not really, because you can check in either order, so unless it's 50/50 you= usually get the fast-path. Actually, no, I'm not persuaded by this as yet. I agree with the statement = that NATs kill these bindings faster, but it's not yet clear to me that connection IDs ameliorate these p= roblems sufficiently to improve the situation. I'd be happy to see any data you have that supports = this point. I don't follow. I think you're agreeing with what I said above, that NAT re= bindings happen faster for UDP. A QUIC packet post-rebinding for the same = connection carries the same connection ID, which leads it back to the same = server even if a NAT rebinding happened. Why do you think connection IDs do= n't ameliorate this problem (of NAT rebindings happen faster for UDP) suffi= ciently? In other words, what piece of this problem does connection ID not = solve? 1. Anything where it's the server speaking first after the rebind. 2. Situations where the server or client would have GCed the state anyway. I'm looking for data that indicates that the remaining cases are common eno= ugh to be important enough to take the privacy hit. As I said in my response to Ian, = I'll try to figure out a more precise framing of the data that I would find persuasive. That'd be helpful. We'd all agree that connection ID use across client network changes is a ne= w beast. To this end, I think we've generally agreed (informally anyways) t= hat the client must use a new connection ID when it triggers connection mig= ration to a different network. The difficulty is that we do not presently know how to arrange that you alw= ays use a new conn id on migration without using a new conn id on each packet. That's not true. We can arrange for an active client-driven migration to us= e a new connection ID. It's the NAT rebinding case that we can't handle wit= hout a new connection ID per packet. The reason I separated the connection = ID question into NAT rebinding vs client migration was to also separate the= privacy considerations for these two cases. While there's a real concern o= f privacy leakage across active client migrations, privacy leakage due to a= stable connection ID across NAT rebindings is not different than that due = to a stable TCP connection for the same duration. There are plenty of times when the client does a network change but doesn't= know it has. Tethering is one example. In such cases, continuing to use the same co= nnection ID presents a privacy threat. The tethering case is real, but it's a corner case; connection migrations a= re dominated by untethered clients. - jana -Ekr On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell > wrote: hi Ekr, all, > > Well, with negotiation, someone has to decide. The bit just moves that = to the client. > > Except that if the load balancer *needs* it, then the client has to con= form. > >> The load balancer needs it to balance load efficiently. >> > That's not entirely clear. Note that in the original QUIC design, the cli= ent supplied > the connection ID, so the server side merely had to load balance based on= some combination > of a random value and the client's IP. Right; should have said that "the assertion behind server-suggested Connect= ion ID proposal is that it's needed for efficient load balancing". I'm taki= ng that assertion at face value now, possibly because I'm convinced of the = utility of one of its side-effects: providing some additional grade of assu= rance to a device on path that a given packet was not injected off-path, wh= ich is useful in in-network DoS mitigation (as in section 3.3 of the just-s= ubmitted manageability draft). >> I presume that a client that was very interested in not providing tracki= ng information could refuse to make Connection ID available, at the cost of= degraded performance. (I would like to reiterate that I do think that it's necessary to allow cli= ents to veto server-proposed connection ID exposure.) >> (f that's not the case, if failure to send connection ID leads to connec= tion failure, then "negotiation" is a euphemism: the server informs the cli= ent whether it must send a connection ID, probably encrypted, and nobody ne= eds any flags, unless the presence of connection ID changes the offsets of = fields we *do* want to explicitly expose, such as packet number echo (https= ://github.com/quicwg/base-drafts/issues/269) or troubleshooting flags (https://github.com= /quicwg/base-drafts/issues/279). > > Not to put too fine a point on it, but there's far from consensus that we= want to expose > either of these. That's not too fine a point at all; I'm not presupposing consensus on eithe= r of these. All I'm saying here is, should consensus emerge that the benefi= ts outweigh the costs (both in complexity and in risk) for certain kinds of= exposure to the path -- which I think may be the case for some of the thin= gs under discussion in 279, and I'm obviously convinced of the utility of p= acket number echo as in 269 or I wouldn't have submitted two PRs on it -- w= e need to be clear that other choices we make about the layout of the heade= r doesn't make that harder than it needs to be. Sticking variable-length/op= tional fields whose presence is dependent on endpoint-shared state after th= e exposed fields is probably sufficient for this. Cheers, Brian --_000_9906aa175d054dbbad9b647719f8b42cusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The tethering case is real, but it's a corner case; > connection migrations are dominated by
> untethered clients.

I would not be banking on tethering remaining a fringe activity. This may b= e true today, but it is rapidly changing with proliferation of connected ca= rs, buses, trains, and other mobile hotspots. And I will not even venture a= guess about technologies available in 10-15 years.

- Igor


-----Original Message-----
From: Jana Iyengar [jri@google.com]
Received: Thursday, 09 Mar 2017, 2:51PM
To: Eric Rescorla [ekr@rtfm.com]
CC: Brian Trammell [ietf@trammell.ch]; IETF QUIC WG [quic@ietf.org]<= br> Subject: Re: Middlebox introspection/self-describing packets
Why not? It's a connection identifier, like the TCP 4-tuple. What do y= ou gain from middleboxes not using the connection ID to identify connection= s?
Yeah, I wish they wouldn't use the 4-tuple either. In fact much of thi= s conversation is driven by them doing nonsense based on the 4-tuple.

I understand now. FWIW, the stuff they do, using 4-tuples, includes AQ= M (see FQ-CoDel)...  some of these things are useful. I'm not saying t= hat's the only way to do it, and I've not thought (or know) about all the t= hings that would break if the notion of flow was obliterated from public view.
 
If you don't have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look for it=
- If that's missing, drop the packet
Yes, I was responding to Brian's email -- apologies for crossing the w= ires a bit. This method is plausible, but it increases the work per packet = at load balancers by ~2x. 
Not really, because you can check in either order, so unless it's 50/5= 0 you usually get the fast-path. 


Actually, no, I'm not persuaded by this as yet. I agree with the state= ment that NATs kill these bindings
faster, but it's not yet clear to me that connection IDs ameliorate th= ese problems sufficiently to
improve the situation. I'd be happy to see any data you have that supp= orts this point.
I don't follow. I think you're agreeing with what I said above, that N= AT rebindings happen faster for UDP.  A QUIC packet post-rebinding for= the same connection carries the same connection ID, which leads it back to= the same server even if a NAT rebinding happened. Why do you think connection IDs don't ameliorate this problem (o= f NAT rebindings happen faster for UDP) sufficiently? In other words, what = piece of this problem does connection ID not solve?
1. Anything where it's the server speaking first after the rebind.
2. Situations where the server or client would have GCed the state any= way. 
I'm looking for data that indicates that the remaining cases are commo= n enough to be
important enough to take the privacy hit. As I said in my response to = Ian, I'll try to
figure out a more precise framing of the data that I would find persua= sive.

That'd be helpful.
 

We'd all agree that connection ID use across client network changes is= a new beast. To this end, I think we've generally agreed (informally anywa= ys) that the client must use a new connection ID when it triggers connectio= n migration to a different network.
The difficulty is that we do not presently know how to arrange that yo= u always use a new conn id
on migration without using a new conn id on each packet.
That's not true. We can arrange for an active client-driven migration = to use a new connection ID. It's the NAT rebinding case that we can't handl= e without a new connection ID per packet. The reason I separated the connec= tion ID question into NAT rebinding vs client migration was to also separate the privacy considerations for th= ese two cases. While there's a real concern of privacy leakage across activ= e client migrations, privacy leakage due to a stable connection ID across N= AT rebindings is not different than that due to a stable TCP connection for the same duration.
There are plenty of times when the client does a network change but do= esn't know it
has. Tethering is one example. In such cases, continuing to use the sa= me connection
ID presents a privacy threat.

The tethering case is real, but it's a corner case; connection migrati= ons are dominated by untethered clients.

- jana
 
-Ekr




On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <= span dir=3D"ltr"> <ietf@trammell.ch<= /a>> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, the = client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load balancin= g". I'm taking that assertion at face value now, possibly because I'm = convinced of the utility of one of its side-effects: providing some additional grade of assurance to a device on path that a gi= ven packet was not injected off-path, which is useful in in-network DoS mit= igation (as in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary to al= low clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads to = connection failure, then "negotiation" is a euphemism: the server= informs the client whether it must send a connection ID, probably encrypte= d, and nobody needs any flags, unless the presence of connection ID changes the offsets of fields we *do* want to explicitly = expose, such as packet number echo (https://github.com/quicwg/base-drafts/issues/269) or troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus that= we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing consensus o= n either of these. All I'm saying here is, should consensus emerge that the= benefits outweigh the costs (both in complexity and in risk) for certain k= inds of exposure to the path -- which I think may be the case for some of the things under discussion in 2= 79, and I'm obviously convinced of the utility of packet number echo as in = 269 or I wouldn't have submitted two PRs on it -- we need to be clear that = other choices we make about the layout of the header doesn't make that harder than it needs to be. Stickin= g variable-length/optional fields whose presence is dependent on endpoint-s= hared state after the exposed fields is probably sufficient for this.


Cheers,

Brian






--_000_9906aa175d054dbbad9b647719f8b42cusma1exdag1mb5msgcorpak_-- From nobody Thu Mar 9 22:24:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5741412940B for ; Thu, 9 Mar 2017 22:24:42 -0800 (PST) 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, RP_MATCHES_RCVD=-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 QJJm9kIGe4iy for ; Thu, 9 Mar 2017 22:24:40 -0800 (PST) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by ietfa.amsl.com (Postfix) with ESMTP id 8B286127A90 for ; Thu, 9 Mar 2017 22:24:40 -0800 (PST) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id EFB61273E2; Fri, 10 Mar 2017 06:24:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v2A6OaUE003864; Fri, 10 Mar 2017 06:24:36 GMT (envelope-from phk@phk.freebsd.dk) To: Mike Bishop Subject: Re: HTTP/QUIC Diverging from HTTP/2 In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3862.1489127076.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Mar 2017 06:24:36 +0000 Message-ID: <3863.1489127076@critter.freebsd.dk> Archived-At: Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 06:24:42 -0000 -------- In message , Mike Bishop writes: >but there appears to be general support for considering these separate >protocols which are closely related, rather than two variants of a >single protocol. If so, it would be incredibly short-sighted to not take the chance to drop some of the worst bogons overboard while you have the chance. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Thu Mar 9 22:24:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F205A1295DB for ; Thu, 9 Mar 2017 22:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 lgdd9cJhXK-d for ; Thu, 9 Mar 2017 22:24:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713401295CD for ; Thu, 9 Mar 2017 22:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4527; q=dns/txt; s=iport; t=1489127094; x=1490336694; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=UILLXXQ0jHM7V2Cl2zHQ8aU1TOw6UWOlVkPwO0F/iXM=; b=Tqv55XiEEa5T21VEXVW1Uwlq4ToVn3i22P/eVYHw+SBtaoi5NORfy0hh WHZBaZXw4hZrmkZBGg0rAA3Wj/ryETZhEYOW4rqN1dvz7sBMV4F4d/64D iXc6BT/P+PsSfE/FGLGzndOngZstCtSmMlzMzv4qy4Wf+TlA+g7coabeL s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcBAC3RcJY/xbLJq1HFhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJugW6EQIsAkF2QC4Utgg6GIgKCcxYBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBI1YQCwQBEyoCAlcGAQwIAQGJdAixIYImK4o/AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBDg+IU4JqhB+DO4JfAQScOYN4ggmMN4pPhlGTPyYGK4EDIhUIFxWHFD+?= =?us-ascii?q?KYAEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,139,1486425600"; d="asc'?scan'208,217";a="650317660" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 06:24:52 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2A6OpxZ018401; Fri, 10 Mar 2017 06:24:51 GMT Subject: Re: Middlebox introspection/self-describing packets To: "Lubashev, Igor" , "ekr@rtfm.com" , "jri@google.com" References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> From: Eliot Lear Message-ID: <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> Date: Fri, 10 Mar 2017 07:24:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5fAKtlbX16l4r6KRA3gW0h4Qw7SN24hOD" Archived-At: Cc: "ietf@trammell.ch" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 06:24:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5fAKtlbX16l4r6KRA3gW0h4Qw7SN24hOD Content-Type: multipart/mixed; boundary="evepTIrh31IWILNiexbj6QbTm5Mbtnl5h"; protected-headers="v1" From: Eliot Lear To: "Lubashev, Igor" , "ekr@rtfm.com" , "jri@google.com" Cc: "ietf@trammell.ch" , "quic@ietf.org" Message-ID: <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> Subject: Re: Middlebox introspection/self-describing packets References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> --evepTIrh31IWILNiexbj6QbTm5Mbtnl5h Content-Type: multipart/alternative; boundary="------------11B2367460F9FF642792FACD" This is a multi-part message in MIME format. --------------11B2367460F9FF642792FACD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/10/17 6:39 AM, Lubashev, Igor wrote: > > The tethering case is real, but it's a corner case; > > connection migrations are dominated by > > untethered clients. > > I would not be banking on tethering remaining a fringe activity. This > may be true today, but it is rapidly changing with proliferation of > connected cars, buses, trains, and other mobile hotspots. And I will > not even venture a guess about technologies available in 10-15 years. But you can't engineer around such vagaries. =20 Eliot --------------11B2367460F9FF642792FACD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 3/10/17 6:39 AM, Lubashev, Igor wrote:
> The tethering case is real, but it's a corner case;
> connection migrations are dominated by
> untethered clients.

I would not be banking on tethering remaining a fringe activity. This may be true today, but it is rapidly changing with proliferation of connected cars, buses, trains, and other mobile hotspots. And I will not even venture a guess about technologies available in 10-15 years.

But you can't engineer around such vagaries.
=C2=A0
Eliot
--------------11B2367460F9FF642792FACD-- --evepTIrh31IWILNiexbj6QbTm5Mbtnl5h-- --5fAKtlbX16l4r6KRA3gW0h4Qw7SN24hOD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwkazAAoJEIe2a0bZ0nozvIQH/Rgz3XzCLPtU6eemkotbGd6G hSoU0uO4nxg/np540pg8qYRA2p8thFFrVqpd2JpESCZt9p3oX9Wnywl5FDeSnnou YpPnLkVF81mHcMh192mEUyrtTBy0YouZTc6Wk0FkhJwSAJEAi1X+brZSHRLl7HR8 ThJ1Nuz83dcPoFb3YjPoOM0SzicBXDWElkaw6sZOODz+dBHYGX4Rn16dOmdeFwvG VFx7IPc4bd1NO99fGxuJAI1Epx0d8XN4zhOO5W+Q8l6g8jsCEoP1B0tTDzb38CF9 RpNv7yY52b5hHPsuLX1fSoiyZepmNUEtA/zomAE/zKogguj/0uqZVCFZomc6mGU= =Jif3 -----END PGP SIGNATURE----- --5fAKtlbX16l4r6KRA3gW0h4Qw7SN24hOD-- From nobody Thu Mar 9 23:46:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C381296EE for ; Thu, 9 Mar 2017 23:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zniwEJT3oEhq for ; Thu, 9 Mar 2017 23:46:38 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7AE1295E6 for ; Thu, 9 Mar 2017 23:36:17 -0800 (PST) Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id v2A7aE7e008151 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Mar 2017 08:36:14 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id v2A7aBr5008139; Fri, 10 Mar 2017 08:36:12 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 10 Mar 2017 08:36:11 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Andy Green Subject: Re: HTTP/QUIC Diverging from HTTP/2 In-Reply-To: <5e8c43a6-fd15-6cdc-c507-ca33e64b7206@warmcat.com> Message-ID: References: <5e8c43a6-fd15-6cdc-c507-ca33e64b7206@warmcat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: Adrien de Croy , Mike Bishop , "quic@ietf.org" , Martin Thomson , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 07:46:38 -0000 On Fri, 10 Mar 2017, Andy Green wrote: > If I can run websockets over it, it will already be more useful than http/2 > for me... I've not seen anyone speak up about websockets for QUIC so I'd say the situation there is equal to h2: needing people to actively work on it or it won't happen. (and I'm sure someone can/will correct me if I'm wrong) -- / daniel.haxx.se From nobody Thu Mar 9 23:49:23 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0139612949E for ; Thu, 9 Mar 2017 08:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jnbua4p3uKY for ; Thu, 9 Mar 2017 08:03:33 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0102.outbound.protection.outlook.com [104.47.42.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F41129698 for ; Thu, 9 Mar 2017 08:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KuneabTwQdVfWg7PxRV7C34O6oca+XVXFpus3I/RACI=; b=WRatwSUK3DPS6AiAMNthpqpD/E5AmhU2C67IAY0XPB2Kx7mDcemjgZcCGlHVxZeG8sF0zLai9jil0zJCCjFJmPslG7papkkOajF8UCPerA+nWAuFsdffF3eFpX+HfX+gluAAhpnRkdnAQYowKwf7cD/MnXPEEagTmRWH8JNex4c= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 9 Mar 2017 16:03:29 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 9 Mar 2017 16:03:29 +0000 From: Mike Bishop To: Ingemar Johansson S , "Phillip Hallam-Baker" , Jana Iyengar Subject: RE: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Topic: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Index: AQHSjOEdDzxr00Ts+EONPowXtDkG56F1RM/QgAA9agCAAC0sAIAADnzwgAASFQCAABH8AIAAA80AgABNbKCAFpA8EA== Date: Thu, 9 Mar 2017 16:03:29 +0000 Message-ID: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:8300:3b9a:d0ce:a235:e7d3:26cc] x-ms-office365-filtering-correlation-id: 8411be52-3150-4182-8f33-08d46705d3ec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:v9btud/i12/8Hste9xZyd/JDP/+7fRud19n0O3XHrJNGdXCVoC0DrFzyjWHbtHffLNOrE45YivxnwmIddl5gGtS5K1pvFEhAqkuh4gfpZLB5FMtQ8ZXqFSF5Xyg/QT9HCjqB6g6KK1IkJ3nbEfUaNoexvtCZ1ULAIMaS9uE/4pqZzjZHz7XsV4aLf8FDoviEfgoui2nF8poomCGWGXJTBF51qA3BGLDM06WEkOY9cezsftNYiReuOYJuxxURFiOm5vZgmGnC1AICHx4R4v7O+NWvvY6OTDStKl0BAhS1gj0LeKO/9iulsV/F5oYydJJi6ziTYdrvgJiTGAMD5UEIH1eAGkLxcR8+e189lYRDXxc= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(24454002)(377454003)(13464003)(129404003)(377424004)(2900100001)(53546006)(74316002)(4326008)(5005710100001)(10290500002)(7416002)(5660300001)(2420400007)(6306002)(93886004)(19609705001)(230783001)(10090500001)(86362001)(15650500001)(2950100002)(38730400002)(6246003)(53386004)(8990500004)(2906002)(122556002)(50986999)(6506006)(106116001)(54356999)(6436002)(76176999)(8936002)(16799955002)(55016002)(236005)(99286003)(86612001)(54906002)(8676002)(54896002)(33656002)(7906003)(14971765001)(10710500007)(53936002)(7696004)(7110500001)(606005)(790700001)(3280700002)(189998001)(229853002)(77096006)(7736002)(102836003)(25786008)(6116002)(3660700001)(9686003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708A99BA37EA11B238C317887210BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2017 16:03:29.1731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: X-Mailman-Approved-At: Thu, 09 Mar 2017 23:49:21 -0800 Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , "Bob Briscoe \(ietf@bobbriscoe.net\)" , "mirja.kuehlewind@tik.ee.ethz.ch" , marcelo bagnulo braun , Piers O'Hanlon , IETF QUIC WG , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:03:37 -0000 --_000_BN6PR03MB2708A99BA37EA11B238C317887210BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBxdWljayBvdmVydmlldyBvZiB3aGF0IGl0IGlzIGFuZCB3aHkgaXQgbWF0dGVycyBwbHVzIGlu Zm9ybWF0aW9uYWwgcmVmZXJlbmNlcyB0byBob3cgaXQgd29ya3Mgc2VlbXMgbGlrZSBhIHJlYXNv bmFibGUgY29tYmluYXRpb24uDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBJbmdlbWFyIEpvaGFuc3NvbiBTDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDIyLCAyMDE3IDExOjM4IFBNDQpUbzogUGhpbGxpcCBIYWxsYW0tQmFrZXIgPHBo aWxsQGhhbGxhbWJha2VyLmNvbT47IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+DQpDYzog J2dvcnJ5QGVyZy5hYmRuLmFjLnVrJyAoZ29ycnlAZXJnLmFiZG4uYWMudWspIDxnb3JyeUBlcmcu YWJkbi5hYy51az47IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPjsg Qm9iIEJyaXNjb2UgKGlldGZAYm9iYnJpc2NvZS5uZXQpIDxpZXRmQGJvYmJyaXNjb2UubmV0Pjsg bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDsgbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxt YXJjZWxvQGl0LnVjM20uZXM+OyBQaWVycyBPJ0hhbmxvbiA8cGllcnMub2hhbmxvbkBjcy5veC5h Yy51az47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IERlIFNjaGVwcGVyLCBLb2VuIChO b2tpYSAtIEJFKSA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPg0KU3ViamVj dDogUkU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1x dWljLWVjbi0wMS50eHQNCg0KSGkNCg0KSSBjYW4gYWRkIGEgbW9yZSBjb21wcmVoZW5zaXZlIHRl eHQgdGhhdCBkZXNjcmliZXMgRUNOIGEgYml0IGFuZCBhbiBleHBhbnNpb24gb2YgdGhlIGFjcm9u eW1zLCB0aGF0IHNvdW5kcyB2ZXJ5IHJlYXNvbmFibGUuDQpJIGRvbuKAmXQgaG93ZXZlciB3YW50 IHRvIGFkZCBhIGNvbXBsZXRlIEVDTiBjcmFzaC1jb3Vyc2UgaW50byB0aGUgZG9jdW1lbnQgIGFz IHRoaXMgdGV4dCBhbHJlYWR5IGV4aXN0IGVsc2V3aGVyZSBpbiBUU1ZXRywgSUNDUkcgIGFuZCBB UU0gV0cgZG9jdW1lbnRzLg0KDQpSZWdhcmRzDQovSW5nZW1hcg0KDQpGcm9tOiBoYWxsYW1AZ21h aWwuY29tPG1haWx0bzpoYWxsYW1AZ21haWwuY29tPiBbbWFpbHRvOmhhbGxhbUBnbWFpbC5jb21d IE9uIEJlaGFsZiBPZiBQaGlsbGlwIEhhbGxhbS1CYWtlcg0KU2VudDogZGVuIDIzIGZlYnJ1YXJp IDIwMTcgMDM6NTINClRvOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlA Z29vZ2xlLmNvbT4+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5j b208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PjsgJ2dvcnJ5QGVyZy5hYmRu LmFjLnVrJyAoZ29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVr PikgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+OyBC b2IgQnJpc2NvZSAoaWV0ZkBib2JicmlzY29lLm5ldDxtYWlsdG86aWV0ZkBib2JicmlzY29lLm5l dD4pIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Pj47IElu Z2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0 bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+OyBtaXJqYS5rdWVobGV3aW5kQHRp ay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgbWFy Y2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM8bWFpbHRvOm1hcmNlbG9AaXQu dWMzbS5lcz4+OyBQaWVycyBPJ0hhbmxvbiA8cGllcnMub2hhbmxvbkBjcy5veC5hYy51azxtYWls dG86cGllcnMub2hhbmxvbkBjcy5veC5hYy51az4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUp IDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb208bWFpbHRvOmtvZW4uZGVfc2No ZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbT4+DQpTdWJqZWN0OiBSZTogRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dA0KDQoNCg0K T24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgOTozOCBQTSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xl LmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3cm90ZToNClFVSUMsIGJ5IGJlaW5nIGNyb3Nz LWFyZWEsIG1ha2VzIGl0IGRpZmZpY3VsdCBmb3IgZm9sa3MgdG8gcmV2aWV3IGFsbCBkb2NzLCBz aW5jZSBpdCdzIHVuY29tbW9uIGZvciBmb2xrcyB0byBrbm93IGV2ZXJ5dGhpbmcgYWJvdXQgYWxs IGFzcGVjdHMgb2YgVExTLCB0cmFuc3BvcnQsIGFuZCBIVFRQLzIuIFRoaXMgZG9lcyBtYWtlIGl0 IGFuIG9wcG9ydHVuaXR5IHRvIHdyaXRlIGRyYWZ0cyB0aGF0IGFyZSBjbGVhcmVyIHRvIGEgd2lk ZXIgYXVkaWVuY2UuIEluIHRoaXMgY2FzZSwgSSB0aGluayBhIHJlZmVyZW5jZSB0byBSRkMgMzE2 OCBhbmQgYSBjb3VwbGUgb2Ygc2VudGVuY2VzIG91Z2h0IHRvIGJlIGFkZXF1YXRlLg0KDQpUaGF0 IHNhaWQsIEknbGwgbm90ZSB0aGF0IHRoaXMgY3Jvc3MtYXJlYSB3b3JrIHdpbGwgcmVxdWlyZSBl dmVyeW9uZSB0byB3ZWFyIHRoZWlyIGh1bWlsaXR5IGhhdHMgbW9yZSBmcmVxdWVudGx5LiBJZiB5 b3UgYXJlIGZydXN0cmF0ZWQsIGl0J3MgcGVyaGFwcyBiZWNhdXNlIHlvdSdyZSBlbmNvdW50ZXJp bmcgYW4gYXJlYSB0aGF0IHdhcyBmb3JlaWduIHRvIHlvdSB1bnRpbCBub3cuIEVDTiBpcyBub3Qg b3V0c2lkZS10aGluayBmb3IgYW55b25lIHdobydzIGJlZW4gd29ya2luZyBvbiB0cmFuc3BvcnQg cHJvdG9jb2xzIGZvciBtb3JlIHRoYW4gYSBkYXkuIEknZCBhc2sgYWJvdXQgc29tZXRoaW5nIHlv dSBkb24ndCB1bmRlcnN0YW5kIGZpcnN0LCBhbmQgdGhlbiBjb25zaWRlciBkZWNsYXJpbmcgdGhh dCB0aGUgd2cgc2hvdWxkIG5vdCB3b3JrIG9uIGl0Lg0KDQpBdXRob3JzIHNob3VsZCBub3QgcmVx dWlyZSByZWFkZXJzIHRvIGJlY29tZSBzdXBwbGljYW50cyBvciB3ZWFyICdodW1pbGl0eSBoYXRz Jy4NCg0K4oCLSWYgeW91IHVzZSBhbiBhY3JvbnltLCB5b3UgYWx3YXlzIGV4cGFuZCBpdCBvbiB0 aGUgZmlyc3QgcmVmZXJlbmNlLiBJZiB5b3UgYXJlIHVzaW5nIGEgZGVmaW5lZCB0ZXJtIHlvdSBh bHdheXMgY2l0ZSB0aGUgcmVmZXJlbmNlLuKAiyBJZiBFQ04gd2FzIHRoZSBvbmx5IHVuYm91bmQg YWNyb255bSBpbiB0aGUgaW50cm9kdWN0aW9uLCBJIG1pZ2h0IGhhdmUgbGV0IGl0IGdvLiBPbmx5 IGl0IGNvbnRpbnVlcy4NCg0K4oCLIuKAiyBFQ04gYW5kIEw0UyBFQ04gYnkgbWVhbnMgb2YgZGlm ZmVyZW50aWF0aW9uIGJldHdlZW4gdGhlIHVzZSBvZiB0aGUNCiAgIEVDVCgwKSBhbmQgRUNUKDEp IGNvZGUgcG9pbnRzLiAgIg0KDQrigItUaGVyZSBhcmUgdHdvIHJlYXNvbnMgdGhhdCBJIGRvbid0 IGFjY2VwdCB3b3JrIG9mIHRoYXQga2luZC4gVGhlIGZpcnN0IGlzIHRoYXQgaXQgbWFrZXMgbm8g c2Vuc2UgdG8gbWUgYW5kIGlmIEkgaGF2ZSB0byBzdGFydCB3b3JraW5nIHRocm91Z2ggbG90cyBv ZiBvdGhlciBkb2N1bWVudHMgdG8gd29yayBvdXQgd2hhdCB0aGUgYXV0aG9yIG1lYW5zLCBpdCBp cyBmYXIgbW9yZSBsaWtlbHkgdGhhbiBub3QgdGhhdCB3ZSB3aWxsIGVuZCB1cCB3aXRoIGRpZmZl cmVudCB1bmRlcnN0YW5kaW5ncyBvZiB3aGF0IGlzIGJlaW5nIHNhaWQuDQoNCg0KDQpQcmVwYXJl IHRvIGJlIGZydXN0cmF0ZWQgbW9yZSBvZnRlbi4NCg0KT24gV2VkLCBGZWIgMjIsIDIwMTcgYXQg NTozMyBQTSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIgPHBoaWxsQGhhbGxhbWJha2VyLmNvbTxtYWls dG86cGhpbGxAaGFsbGFtYmFrZXIuY29tPj4gd3JvdGU6DQpOb3Qgc2FyY2FzdGljIGF0IGFsbC4g SnVzdCBmcnVzdHJhdGVkLiBSZWFkaW5nIGEgZHJhZnQgc2hvdWxkIG5vdCByZXF1aXJlIHJlY291 cnNlIHRvIFdpa2lwZWRpYS4NCg0KT24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgNzozMCBQTSwgTWlr ZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkkgcmVhZCBQSELigJlzIGNvbW1lbnQgYXMgYSB0 eXBpY2FsbHktc2FyY2FzdGljIHdheSBvZiBzYXlpbmcgdGhhdCB0aGUgSW50cm9kdWN0aW9uIG9m IHRoaXMgZHJhZnQgYXNzdW1lcyBxdWl0ZSBhIGJpdCBvZiBrbm93bGVkZ2UgdGhhdCBpcyBwZXJo YXBzIGJlc3Qgc3BlbGxlZCBvdXQgd2l0aCBzb21lIHJlbGV2YW50IGluZm9ybWF0aXZlIHJlZmVy ZW5jZXMuICBUaGF0IGlzLCBhZnRlciBhbGwsIHRoZSBwb2ludCBvZiBhbiBpbnRyb2R1Y3Rpb24u DQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMjIsIDIwMTcgMzozNyBQTQ0KVG86IFBoaWxsaXAgSGFsbGFtLUJha2Vy IDxwaGlsbEBoYWxsYW1iYWtlci5jb208bWFpbHRvOnBoaWxsQGhhbGxhbWJha2VyLmNvbT4+DQpD YzogJ2dvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4nIChn b3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+KSA8Z29ycnlA ZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj47IEJvYiBCcmlzY29l IChpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PikgPGlldGZA Ym9iYnJpc2NvZS5uZXQ8bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ+PjsgSW5nZW1hciBKb2hh bnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIu cy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj47IG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHou Y2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBtYXJjZWxvIGJhZ251 bG8gYnJhdW4gPG1hcmNlbG9AaXQudWMzbS5lczxtYWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzPj47 IFBpZXJzIE8nSGFubG9uIDxwaWVycy5vaGFubG9uQGNzLm94LmFjLnVrPG1haWx0bzpwaWVycy5v aGFubG9uQGNzLm94LmFjLnVrPj47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4+OyBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRSkgPGtvZW4uZGVf c2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbTxtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tp YS1iZWxsLWxhYnMuY29tPj4NClN1YmplY3Q6IFJlOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEudHh0DQoNCk9uIFdlZCwgRmViIDIy LCAyMDE3IGF0IDEyOjU1IFBNLCBQaGlsbGlwIEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFr ZXIuY29tPG1haWx0bzpwaGlsbEBoYWxsYW1iYWtlci5jb20+PiB3cm90ZToNClRoaXMgaXMgdGhl IGVudGlyZXR5IG9mIHRoZSBpbnRyb2R1Y3Rpb246DQoNCiAgIEVDTiBzdXBwb3J0IGluIHRyYW5z cG9ydCBwcm90b2NvbHMgaXMgYSBmdW5kYW1lbnRhbCBmZWF0dXJlIHRoYXQNCiAgIHNob3VsZCBi ZSBpbmNsdWRlZCBpbiB0aGUgUVVJQyBzcGVjaWZpY2F0aW9uIGFzIGEgbWFuZGF0b3J5IGVsZW1l bnQuDQogICBUaGUgYmVuZWZpdHMgb2YgRUNOIGlzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtYXFt LWVjbi1iZW5lZml0c10uICBUaGUNCiAgIEVDTiBzdXBwb3J0IHNob3VsZCBiZSBpbXBsZW1lbnRl ZCB0byBzdXBwb3J0IGJvdGggcHJlc2VudCBhbmQgZnV0dXJlDQogICBFQ04sIHRoZSBsYXR0ZXIg aXMgb3V0bGluZWQgaW4gW0ktRC5pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb25dLA0KICAg b2YgcGFydGljdWxhciBpbnRlcmVzdCBpcyB0aGUgYWJpbGl0eSB0byBkaXNjcmltaW5hdGUgYmV0 d2VlbiBjbGFzc2ljDQogICBFQ04gYW5kIEw0UyBFQ04gYnkgbWVhbnMgb2YgZGlmZmVyZW50aWF0 aW9uIGJldHdlZW4gdGhlIHVzZSBvZiB0aGUNCiAgIEVDVCgwKSBhbmQgRUNUKDEpIGNvZGUgcG9p bnRzLiAgVGhpcyBkcmFmdCBkb2VzIGhvd2V2ZXIgbm90IGRlbHZlDQogICBpbnRvIHRoZSBkZXRh aWxzIG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgaW1wbGVtZW50YXRpb24uDQoNCkkgaGF2ZSBh YnNvbHV0ZWx5IG5vIGlkZWEgd2hhdCBFQ04gaXMuIEkgYW0gb3Bwb3NlZCB0byB0aGUgV0cgc3Bl bmRpbmcgYW55IHRpbWUgb24gRUNOIHVudGlsIGl0IGNhbiBiZSBleHBsYWluZWQgaW4gdGVybXMg dGhhdCBkbyBub3QgcmVmZXJlbmNlIHlldCBtb3JlIGphcmdvbi4NCg0KSGFwcHkgdG8gaGVscC4g RUNOIGlzIGRlZmluZWQgaW4gUkZDIDMxNjg8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzMxNjg+LCBhbmQgaXMgYW4gZXhwbGljaXQgc2lnbmFsIGZyb20gdGhlIGEgbmV0d29yayBzd2l0 Y2ggb3Igcm91dGVyIGFib3V0IGNvbmdlc3Rpb24gYXQgYSBsaW5rLCBzbyB0aGF0IGVuZHBvaW50 cyBjYW4gdXNlIHRoaXMgc2lnbmFsIGluc3RlYWQgb2YgbG9zcyBmb3IgZGV0ZWN0aW5nIGFuZCBy ZWFjdGluZyB0byBjb25nZXN0aW9uLiBUaGUgYmVuZWZpdHMgb2YgZG9pbmcgdGhpcyBhcmUgZG9j dW1lbnRlZCBpbnQgaGUgSS1EIHRoYXQgaXMgbGlua2VkIGluIHRoZSBhYnN0cmFjdC4gRUNOIGhh cyBiZWVuIGEgcHJldHR5IHNpZ25pZmljYW50IHRoaW5nIGluIHRyYW5zcG9ydCBmb3IgYWJvdXQg dHdvIGRlY2FkZXMsIGJ1dCBoYXMgaGFkIGFuIHVwaGlsbCBiYXR0bGUgc2luY2UgRUNOIHJlcXVp cmVzIHN1cHBvcnQgaW4gdGhlIG5ldHdvcmsgYW5kIGF0IGVuZHBvaW50cy4NCg0KVGhlcmUgaGF2 ZSBiZWVuIG1hbnkgZWZmb3J0cyB0byB0cnkgYW5kIGRlcGxveSBpdCBpbiBuZXR3b3JrIGRldmlj ZXMgYW5kIGF0IGVuZHBvaW50cyBmb3IgYWJvdXQgYXMgbG9uZyBhcyBSRkMgMzE2OCBoYXMgZXhp c3RlZC4gRUNOIGhhcyBiZWVuIGRlcGxveWVkIGluIGJpdHMgYXQgcm91dGVycyBhbmQgaW4gZW5k cG9pbnRzLCBidXQgZHVlIHRvIGxvbmctc3RhbmRpbmcgYnVncyBpbiBvbGRlciBob21lLXJvdXRl cnMgYW5kIHdpZmkgYm94ZXMsIGFuZCBpc3N1ZXMgYXJvdW5kIHVzZSBvZiB0aGVzZSBiaXRzIGlu IHRoZSBJUCBoZWFkZXIsIGl0IHdhcyBnZW5lcmFsbHkgbm90IHR1cm5lZCBvbiBhbnl3aGVyZS4g VGhpcyBzZWVtcyB0byBiZSBjaGFuZ2luZyBub3csIGVzcGVjaWFsbHkgYXMgYnVmZmVyYmxvYXQg YmVjb21lcyBhbiBpbmNyZWFzaW5nbHkgdmlzaWJsZSBpc3N1ZS4gQnJpYW4gVHJhbW1lbGwgKElB QikgYW5kIE1pcmphIEt1ZWhsZXdpbmQgKFRyYW5zcG9ydCBBRCkgaGF2ZSBiZWVuIGFjdGl2ZWx5 IGRvaW5nIG1lYXN1cmVtZW50IGFib3V0IHRoZSBjdXJyZW50IGRlcGxveW1lbnQgc3RhdGUgb2Yg RUNOOyBoZXJlJ3MgYSBibG9nIHBvc3QgYnkgQnJpYW48aHR0cHM6Ly9tYW1pLXByb2plY3QuZXUv aW5kZXgucGhwLzIwMTYvMDYvMTMvNzAtb2YtcG9wdWxhci13ZWItc2l0ZXMtc3VwcG9ydC1lY24v PiBmcm9tIGxhc3Qgc3VtbWVyIHNheWluZyB0aGF0IGEgbGFyZ2UgbnVtYmVyIG9mIHdlYnNlcnZl cnMgZG8gc3VwcG9ydCBFQ04uIFRoZXJlJ3Mgc3VwcG9ydCBmb3IgRUNOIGJ1aWx0IGludG8gVENQ IChzZWUgU2VjdGlvbiAzLjIgYW5kIDQuMyBvZiB0aGUgVENQIFJvYWRtYXAgUkZDPGh0dHBzOi8v dHJhYy50b29scy5pZXRmLm9yZy9odG1sL3JmYzc0MTQ+KSwgdGhlcmUncyBiZWVuIGEgdG9uIG9m IHdvcmsgYXJvdW5kIHJlLXVzaW5nIEVDTiBzaWduYWxpbmcgZm9yIHJpY2hlciBjb25nZXN0aW9u IGluZm9ybWF0aW9uLg0KDQpTaW5jZSBUQ1AgYW5kIFNDVFAgaGF2ZSBzdXBwb3J0IGZvciBFQ04s IGFuZCB0aGUgZnV0dXJlIG1heSBzZWUgRUNOIGRlcGxveW1lbnQgaW5jcmVhc2UgeWV0LCBpdCdz IGV4cGVjdGVkIHRoYXQgUVVJQyB3b3VsZCBoYXZlIGVxdWl2YWxlbnQgbWVjaGFuaXNtcyB0byBz dXBwb3J0IHVzZSBvZiBFQ04uIFRoaXMgd29yayBpcyB2ZXJ5IG11Y2ggaW4gc2NvcGUsIGFzIHBh cnQgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBhc3BlY3Qgb2YgUVVJQy4NCg0KSG9wZSB0aGlz IGhlbHBzLA0KLSBqYW5hDQoNCg0KDQpPbiBXZWQsIEZlYiAyMiwgMjAxNyBhdCAxMjoyMiBQTSwg SW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFp bHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaQ0KDQpJIGp1 c3QgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgRUNOIGluIFFVSUMgZHJhZnQuIFRoZSBt YWluIGNoYW5nZSBhIGRlc2NyaXB0aW9uIG9mIHRoZSBFQ04gbmVnb3RpYXRpb24uDQoNCi9Jbmdl bWFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQpTZW50 OiBkZW4gMjIgZmVicnVhcmkgMjAxNyAwODo1Ng0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGlu Z2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29u QGVyaWNzc29uLmNvbT4+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IEluZ2VtYXIgSm9oYW5zc29uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbg0KUmV2aXNp b246ICAgICAgIDAxDQpUaXRsZTogICAgICAgICAgRUNOIHN1cHBvcnQgaW4gUVVJQw0KRG9jdW1l bnQgZGF0ZTogIDIwMTctMDItMjENCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOiAgICAgICAgICAxMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDEudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5z c29uLXF1aWMtZWNuLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBtZW1vIG91dGxpbmVzIHRoZSBFQ04gc3VwcG9ydCBpbiBRVUlDLiAg VGhlIGludGVudGlvbiBpcyB0aGF0DQogICBtb3N0IG9mIHRoZSBtYXRlcmlhbCBlbmRzIHVwIHVw ZGF0aW5nIG90aGVyIG5ldyBvciBleGlzdGluZyBRVUlDDQogICBwcm90b2NvbCBzcGVjaWZpY2F0 aW9ucywgdGh1cyBpdCBtYXkgYmUgcG9zc2libGUgdGhhdCB0aGlzIGRyYWZ0IGRvZXMNCiAgIG5v dCB3YXJyYW50IGEgd29ya2luZyBncm91cCBzdGF0dXMuDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg0KDQoNCg0K --_000_BN6PR03MB2708A99BA37EA11B238C317887210BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAu ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkEgcXVpY2sgb3ZlcnZpZXcgb2Ygd2hhdCBpdCBpcyBhbmQgd2h5IGl0IG1hdHRlcnMgcGx1 cyBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZXMgdG8gaG93IGl0IHdvcmtzIHNlZW1zIGxpa2UgYSBy ZWFzb25hYmxlIGNvbWJpbmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMg W21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkluZ2Vt YXIgSm9oYW5zc29uIFM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyMiwg MjAxNyAxMTozOCBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbGxpcCBIYWxsYW0tQmFrZXIgJmx0O3Bo aWxsQGhhbGxhbWJha2VyLmNvbSZndDs7IEphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiAnZ29ycnlAZXJnLmFiZG4uYWMudWsnIChnb3JyeUBlcmcuYWJk bi5hYy51aykgJmx0O2dvcnJ5QGVyZy5hYmRuLmFjLnVrJmd0OzsgTWlrZSBCaXNob3AgJmx0O01p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7OyBCb2IgQnJpc2NvZSAoaWV0ZkBib2Jicmlz Y29lLm5ldCkgJmx0O2lldGZAYm9iYnJpc2NvZS5uZXQmZ3Q7OyBtaXJqYS5rdWVobGV3aW5kQHRp ay5lZS5ldGh6LmNoOyBtYXJjZWxvIGJhZ251bG8gYnJhdW4gJmx0O21hcmNlbG9AaXQudWMzbS5l cyZndDs7DQogUGllcnMgTydIYW5sb24gJmx0O3BpZXJzLm9oYW5sb25AY3Mub3guYWMudWsmZ3Q7 OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBEZSBTY2hlcHBlciwgS29lbiAo Tm9raWEgLSBCRSkgJmx0O2tvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbSZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkkgY2FuIGFkZCBhIG1vcmUgY29tcHJlaGVuc2l2ZSB0ZXh0IHRoYXQgZGVzY3JpYmVzIEVDTiBh IGJpdCBhbmQgYW4gZXhwYW5zaW9uIG9mIHRoZSBhY3JvbnltcywgdGhhdCBzb3VuZHMgdmVyeSBy ZWFzb25hYmxlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgaG93ZXZlciB3YW50IHRvIGFkZCBhIGNvbXBsZXRl IEVDTiBjcmFzaC1jb3Vyc2UgaW50byB0aGUgZG9jdW1lbnQgJm5ic3A7YXMgdGhpcyB0ZXh0IGFs cmVhZHkgZXhpc3QgZWxzZXdoZXJlIGluIFRTVldHLCBJQ0NSRyAmbmJzcDthbmQgQVFNIFdHIGRv Y3VtZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4vSW5nZW1hcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFp bHRvOmhhbGxhbUBnbWFpbC5jb20iPmhhbGxhbUBnbWFpbC5jb208L2E+IFs8YSBocmVmPSJtYWls dG86aGFsbGFtQGdtYWlsLmNvbSI+bWFpbHRvOmhhbGxhbUBnbWFpbC5jb208L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5QaGlsbGlwIEhhbGxhbS1CYWtlcjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4g MjMgZmVicnVhcmkgMjAxNyAwMzo1Mjxicj4NCjxiPlRvOjwvYj4gSmFuYSBJeWVuZ2FyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBnb29nbGUuY29tPC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyAn Z29ycnlAZXJnLmFiZG4uYWMudWsnICg8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMu dWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPikgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OzsNCiBCb2IgQnJpc2Nv ZSAoPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPmlldGZAYm9iYnJpc2NvZS5u ZXQ8L2E+KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPmlldGZAYm9i YnJpc2NvZS5uZXQ8L2E+Jmd0OzsgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29u QGVyaWNzc29uLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2giPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+OyBtYXJj ZWxvIGJhZ251bG8gYnJhdW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJjZWxvQGl0LnVjM20uZXMi Pm1hcmNlbG9AaXQudWMzbS5lczwvYT4mZ3Q7OyBQaWVycyBPJ0hhbmxvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBpZXJzLm9oYW5sb25AY3Mub3guYWMudWsiPnBpZXJzLm9oYW5sb25AY3Mub3guYWMu dWs8L2E+Jmd0OzsNCiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYu b3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs7IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJF KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNv bSI+a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpv aGFuc3Nvbi1xdWljLWVjbi0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgOTozOCBQTSwg SmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlFVSUMsIGJ5IGJlaW5nIGNyb3NzLWFyZWEsIG1ha2Vz IGl0IGRpZmZpY3VsdCBmb3IgZm9sa3MgdG8gcmV2aWV3IGFsbCBkb2NzLCBzaW5jZSBpdCdzIHVu Y29tbW9uIGZvciBmb2xrcyB0byBrbm93IGV2ZXJ5dGhpbmcgYWJvdXQgYWxsIGFzcGVjdHMgb2Yg VExTLCB0cmFuc3BvcnQsIGFuZCBIVFRQLzIuIFRoaXMgZG9lcyBtYWtlIGl0IGFuIG9wcG9ydHVu aXR5IHRvIHdyaXRlIGRyYWZ0cyB0aGF0IGFyZSBjbGVhcmVyDQogdG8gYSB3aWRlciBhdWRpZW5j ZS4gSW4gdGhpcyBjYXNlLCBJIHRoaW5rIGEgcmVmZXJlbmNlIHRvIFJGQyAzMTY4IGFuZCBhIGNv dXBsZSBvZiBzZW50ZW5jZXMgb3VnaHQgdG8gYmUgYWRlcXVhdGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc2FpZCwgSSdsbCBub3Rl IHRoYXQgdGhpcyBjcm9zcy1hcmVhIHdvcmsgd2lsbCByZXF1aXJlIGV2ZXJ5b25lIHRvIHdlYXIg dGhlaXIgaHVtaWxpdHkgaGF0cyBtb3JlIGZyZXF1ZW50bHkuIElmIHlvdSBhcmUgZnJ1c3RyYXRl ZCwgaXQncyBwZXJoYXBzIGJlY2F1c2UgeW91J3JlIGVuY291bnRlcmluZyBhbiBhcmVhIHRoYXQg d2FzIGZvcmVpZ24gdG8geW91IHVudGlsIG5vdy4gRUNOIGlzIG5vdCBvdXRzaWRlLXRoaW5rDQog Zm9yIGFueW9uZSB3aG8ncyBiZWVuIHdvcmtpbmcgb24gdHJhbnNwb3J0IHByb3RvY29scyBmb3Ig bW9yZSB0aGFuIGEgZGF5LiBJJ2QgYXNrIGFib3V0IHNvbWV0aGluZyB5b3UgZG9uJ3QgdW5kZXJz dGFuZCBmaXJzdCwgYW5kIHRoZW4gY29uc2lkZXIgZGVjbGFyaW5nIHRoYXQgdGhlIHdnIHNob3Vs ZCBub3Qgd29yayBvbiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycyBzaG91 bGQgbm90IHJlcXVpcmUgcmVhZGVycyB0byBiZWNvbWUgc3VwcGxpY2FudHMgb3Igd2VhciAnaHVt aWxpdHkgaGF0cycuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAi0lmIHlvdSB1c2UgYW4gYWNyb255bSwgeW91IGFsd2F5cyBleHBhbmQgaXQg b24gdGhlIGZpcnN0IHJlZmVyZW5jZS4gSWYgeW91IGFyZSB1c2luZyBhIGRlZmluZWQgdGVybSB5 b3UgYWx3YXlzIGNpdGUgdGhlIHJlZmVyZW5jZS7igIsgSWYgRUNOIHdhcyB0aGUgb25seSB1bmJv dW5kIGFjcm9ueW0gaW4gdGhlIGludHJvZHVjdGlvbiwgSSBtaWdodCBoYXZlIGxldCBpdCBnby4g T25seSBpdCBjb250aW51ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPuKAiyZxdW90O+KAiyBFQ04gYW5kIEw0UyBFQ04gYnkgbWVhbnMgb2Yg ZGlmZmVyZW50aWF0aW9uIGJldHdlZW4gdGhlIHVzZSBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtFQ1QoMCkgYW5k IEVDVCgxKSBjb2RlIHBvaW50cy4gJm5ic3A7JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAi1RoZXJlIGFy ZSB0d28gcmVhc29ucyB0aGF0IEkgZG9uJ3QgYWNjZXB0IHdvcmsgb2YgdGhhdCBraW5kLiBUaGUg Zmlyc3QgaXMgdGhhdCBpdCBtYWtlcyBubyBzZW5zZSB0byBtZSBhbmQgaWYgSSBoYXZlIHRvIHN0 YXJ0IHdvcmtpbmcgdGhyb3VnaCBsb3RzIG9mIG90aGVyIGRvY3VtZW50cyB0byB3b3JrIG91dCB3 aGF0IHRoZSBhdXRob3IgbWVhbnMsIGl0IGlzIGZhciBtb3JlIGxpa2VseSB0aGFuIG5vdCB0aGF0 DQogd2Ugd2lsbCBlbmQgdXAgd2l0aCBkaWZmZXJlbnQgdW5kZXJzdGFuZGluZ3Mgb2Ygd2hhdCBp cyBiZWluZyBzYWlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QcmVwYXJlIHRvIGJlIGZydXN0cmF0ZWQgbW9yZSBvZnRl bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAyMiwgMjAxNyBhdCA1OjMzIFBNLCBQaGlsbGlwIEhh bGxhbS1CYWtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxsQGhhbGxhbWJha2VyLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnBoaWxsQGhhbGxhbWJha2VyLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBzYXJjYXN0aWMgYXQgYWxs LiBKdXN0IGZydXN0cmF0ZWQuIFJlYWRpbmcgYSBkcmFmdCBzaG91bGQgbm90IHJlcXVpcmUgcmVj b3Vyc2UgdG8gV2lraXBlZGlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDIyLCAyMDE3IGF0IDc6 MzAgUE0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgcmVhZCBQSELigJlzIGNvbW1lbnQgYXMgYSB0eXBpY2FsbHktc2FyY2FzdGljIHdheSBv ZiBzYXlpbmcgdGhhdCB0aGUgSW50cm9kdWN0aW9uIG9mIHRoaXMgZHJhZnQgYXNzdW1lcyBxdWl0 ZSBhIGJpdCBvZiBrbm93bGVkZ2UgdGhhdCBpcyBwZXJoYXBzIGJlc3Qgc3BlbGxlZCBvdXQgd2l0 aCBzb21lIHJlbGV2YW50DQogaW5mb3JtYXRpdmUgcmVmZXJlbmNlcy4mbmJzcDsgVGhhdCBpcywg YWZ0ZXIgYWxsLCB0aGUgcG9pbnQgb2YgYW4gaW50cm9kdWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuYSBJeWVuZ2FyPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgRmVicnVhcnkgMjIsIDIwMTcgMzozNyBQTTxicj4NCjxiPlRvOjwvYj4gUGhp bGxpcCBIYWxsYW0tQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsbEBoYWxsYW1iYWtlci5j b20iIHRhcmdldD0iX2JsYW5rIj5waGlsbEBoYWxsYW1iYWtlci5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gJzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayIgdGFyZ2V0PSJf YmxhbmsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPicgKDxhIGhyZWY9Im1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51ayIgdGFyZ2V0PSJfYmxhbmsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPikg Jmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayIgdGFyZ2V0PSJfYmxhbmsi PmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDs7IEJvYg0KIEJyaXNjb2UgKDxhIGhyZWY9Im1h aWx0bzppZXRmQGJvYmJyaXNjb2UubmV0IiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBib2JicmlzY29l Lm5ldDwvYT4pICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+Jmd0OzsgSW5nZW1hciBKb2hhbnNzb24g UyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OzsN CjxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9 Il9ibGFuayI+bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT47IG1hcmNlbG8gYmFn bnVsbyBicmF1biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmNlbG9AaXQudWMzbS5lcyIgdGFyZ2V0 PSJfYmxhbmsiPm1hcmNlbG9AaXQudWMzbS5lczwvYT4mZ3Q7OyBQaWVycyBPJ0hhbmxvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBpZXJzLm9oYW5sb25AY3Mub3guYWMudWsiIHRhcmdldD0iX2JsYW5r Ij5waWVycy5vaGFubG9uQGNzLm94LmFjLnVrPC9hPiZndDs7DQogSUVURiBRVUlDIFdHICZsdDs8 YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5v cmc8L2E+Jmd0OzsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUpICZsdDs8YSBocmVmPSJt YWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tIiB0YXJnZXQ9Il9ibGFu ayI+a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpv aGFuc3Nvbi1xdWljLWVjbi0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBGZWIgMjIsIDIwMTcgYXQgMTI6 NTUgUE0sIFBoaWxsaXAgSGFsbGFtLUJha2VyICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbGxAaGFs bGFtYmFrZXIuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbGxAaGFsbGFtYmFrZXIuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhpcyBpcyB0aGUgZW50aXJldHkgb2YgdGhlIGludHJvZHVjdGlvbjogJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7RUNOIHN1cHBvcnQgaW4gdHJhbnNwb3J0IHByb3RvY29scyBpcyBhIGZ1bmRh bWVudGFsIGZlYXR1cmUgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7c2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBR VUlDIHNwZWNpZmljYXRpb24gYXMgYSBtYW5kYXRvcnkgZWxlbWVudC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO1RoZSBi ZW5lZml0cyBvZiBFQ04gaXMgZGVzY3JpYmVkIGluIFtJLUQuaWV0Zi1hcW0tZWNuLWJlbmVmaXRz XS4mbmJzcDsgVGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtFQ04gc3VwcG9ydCBzaG91bGQgYmUgaW1wbGVtZW50ZWQg dG8gc3VwcG9ydCBib3RoIHByZXNlbnQgYW5kIGZ1dHVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7RUNOLCB0aGUgbGF0 dGVyIGlzIG91dGxpbmVkIGluIFtJLUQuaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uXSw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwO29mIHBhcnRpY3VsYXIgaW50ZXJlc3QgaXMgdGhlIGFiaWxpdHkgdG8gZGlzY3Jp bWluYXRlIGJldHdlZW4gY2xhc3NpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7RUNOIGFuZCBMNFMgRUNOIGJ5IG1lYW5z IG9mIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIHRoZSB1c2Ugb2YgdGhlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtFQ1Qo MCkgYW5kIEVDVCgxKSBjb2RlIHBvaW50cy4mbmJzcDsgVGhpcyBkcmFmdCBkb2VzIGhvd2V2ZXIg bm90IGRlbHZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDtpbnRvIHRoZSBkZXRhaWxzIG9mIHRoZSBjb25nZXN0aW9uIGNv bnRyb2wgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgYWJzb2x1dGVseSBubyBpZGVhIHdoYXQgRUNO IGlzLiBJIGFtIG9wcG9zZWQgdG8gdGhlIFdHIHNwZW5kaW5nIGFueSB0aW1lIG9uIEVDTiB1bnRp bCBpdCBjYW4gYmUgZXhwbGFpbmVkIGluIHRlcm1zIHRoYXQgZG8gbm90IHJlZmVyZW5jZSB5ZXQg bW9yZSBqYXJnb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGFwcHkgdG8gaGVs cC4gRUNOIGlzIGRlZmluZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmMzMTY4IiB0YXJnZXQ9Il9ibGFuayI+UkZDIDMxNjg8L2E+LCBhbmQgaXMgYW4gZXhwbGlj aXQgc2lnbmFsIGZyb20gdGhlIGEgbmV0d29yayBzd2l0Y2ggb3Igcm91dGVyIGFib3V0IGNvbmdl c3Rpb24gYXQgYSBsaW5rLCBzbyB0aGF0IGVuZHBvaW50cyBjYW4gdXNlIHRoaXMgc2lnbmFsIGlu c3RlYWQgb2YgbG9zcyBmb3IgZGV0ZWN0aW5nIGFuZCByZWFjdGluZyB0byBjb25nZXN0aW9uLg0K IFRoZSBiZW5lZml0cyBvZiBkb2luZyB0aGlzIGFyZSBkb2N1bWVudGVkIGludCBoZSBJLUQgdGhh dCBpcyBsaW5rZWQgaW4gdGhlIGFic3RyYWN0LiBFQ04gaGFzIGJlZW4gYSBwcmV0dHkgc2lnbmlm aWNhbnQgdGhpbmcgaW4gdHJhbnNwb3J0IGZvciBhYm91dCB0d28gZGVjYWRlcywgYnV0IGhhcyBo YWQgYW4gdXBoaWxsIGJhdHRsZSBzaW5jZSBFQ04gcmVxdWlyZXMgc3VwcG9ydCBpbiB0aGUgbmV0 d29yayBhbmQgYXQgZW5kcG9pbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgaGF2ZSBiZWVuIG1hbnkgZWZmb3J0 cyB0byB0cnkgYW5kIGRlcGxveSBpdCBpbiBuZXR3b3JrIGRldmljZXMgYW5kIGF0IGVuZHBvaW50 cyBmb3IgYWJvdXQgYXMgbG9uZyBhcyBSRkMgMzE2OCBoYXMgZXhpc3RlZC4gRUNOIGhhcyBiZWVu IGRlcGxveWVkIGluIGJpdHMgYXQgcm91dGVycyBhbmQgaW4NCiBlbmRwb2ludHMsIGJ1dCBkdWUg dG8gbG9uZy1zdGFuZGluZyBidWdzIGluIG9sZGVyIGhvbWUtcm91dGVycyBhbmQgd2lmaSBib3hl cywgYW5kIGlzc3VlcyBhcm91bmQgdXNlIG9mIHRoZXNlIGJpdHMgaW4gdGhlIElQIGhlYWRlciwg aXQgd2FzIGdlbmVyYWxseSBub3QgdHVybmVkIG9uIGFueXdoZXJlLiBUaGlzIHNlZW1zIHRvIGJl IGNoYW5naW5nIG5vdywgZXNwZWNpYWxseSBhcyBidWZmZXJibG9hdCBiZWNvbWVzIGFuIGluY3Jl YXNpbmdseSB2aXNpYmxlDQogaXNzdWUuIEJyaWFuIFRyYW1tZWxsIChJQUIpIGFuZCBNaXJqYSBL dWVobGV3aW5kIChUcmFuc3BvcnQgQUQpIGhhdmUgYmVlbiBhY3RpdmVseSBkb2luZyBtZWFzdXJl bWVudCBhYm91dCB0aGUgY3VycmVudCBkZXBsb3ltZW50IHN0YXRlIG9mIEVDTjsgaGVyZSdzIGEN CjxhIGhyZWY9Imh0dHBzOi8vbWFtaS1wcm9qZWN0LmV1L2luZGV4LnBocC8yMDE2LzA2LzEzLzcw LW9mLXBvcHVsYXItd2ViLXNpdGVzLXN1cHBvcnQtZWNuLyIgdGFyZ2V0PSJfYmxhbmsiPg0KYmxv ZyBwb3N0IGJ5IEJyaWFuPC9hPiZuYnNwO2Zyb20gbGFzdCBzdW1tZXIgc2F5aW5nIHRoYXQgYSBs YXJnZSBudW1iZXIgb2Ygd2Vic2VydmVycyBkbyBzdXBwb3J0IEVDTi4gVGhlcmUncyBzdXBwb3J0 IGZvciBFQ04gYnVpbHQgaW50byBUQ1AgKHNlZSBTZWN0aW9uIDMuMiBhbmQgNC4zIG9mIHRoZQ0K PGEgaHJlZj0iaHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQxNCIgdGFyZ2V0 PSJfYmxhbmsiPlRDUCBSb2FkbWFwIFJGQzwvYT4pLCB0aGVyZSdzIGJlZW4gYSB0b24gb2Ygd29y ayBhcm91bmQgcmUtdXNpbmcgRUNOIHNpZ25hbGluZyBmb3IgcmljaGVyIGNvbmdlc3Rpb24gaW5m b3JtYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5TaW5jZSBUQ1AgYW5kIFNDVFAgaGF2ZSBzdXBwb3J0IGZvciBFQ04sIGFuZCB0 aGUgZnV0dXJlIG1heSBzZWUgRUNOIGRlcGxveW1lbnQgaW5jcmVhc2UgeWV0LCBpdCdzIGV4cGVj dGVkIHRoYXQgUVVJQyB3b3VsZCBoYXZlIGVxdWl2YWxlbnQgbWVjaGFuaXNtcyB0byBzdXBwb3J0 IHVzZSBvZiBFQ04uIFRoaXMNCiB3b3JrIGlzIHZlcnkgbXVjaCBpbiBzY29wZSwgYXMgcGFydCBv ZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGFzcGVjdCBvZiBRVUlDLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG9wZSB0aGlzIGhlbHBz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t IGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEZlYiAy MiwgMjAxNyBhdCAxMjoyMiBQTSwgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij5IaTxicj4NCjxicj4NCkkganVzdCB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBFQ04gaW4gUVVJQyBkcmFmdC4gVGhlIG1haW4gY2hhbmdlIGEgZGVzY3JpcHRpb24g b2YgdGhlIEVDTiBuZWdvdGlhdGlvbi48YnI+DQo8YnI+DQovSW5nZW1hcjxicj4NCjxicj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl08YnI+DQpTZW50 OiBkZW4gMjIgZmVicnVhcmkgMjAxNyAwODo1Njxicj4NClRvOiBJbmdlbWFyIEpvaGFuc3NvbiBT ICZsdDs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iIHRh cmdldD0iX2JsYW5rIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJy Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qb2hhbnNzb24t cXVpYy1lY24tMDEudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBJbmdlbWFyIEpvaGFuc3NvbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbjxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzAxPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBFQ04gc3VwcG9ydCBpbiBRVUlDPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNy0w Mi0yMTxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAxMjxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtam9o YW5zc29uLXF1aWMtZWNuLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQ8L2E+ PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24v IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt am9oYW5zc29uLXF1aWMtZWNuLzwvYT48YnI+DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9oYW5z c29uLXF1aWMtZWNuLTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMTwvYT48YnI+DQpEaWZmOiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qb2hhbnNzb24tcXVp Yy1lY24tMDE8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMg bWVtbyBvdXRsaW5lcyB0aGUgRUNOIHN1cHBvcnQgaW4gUVVJQy4mbmJzcDsgVGhlIGludGVudGlv biBpcyB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwO21vc3Qgb2YgdGhlIG1hdGVyaWFsIGVuZHMgdXAg dXBkYXRpbmcgb3RoZXIgbmV3IG9yIGV4aXN0aW5nIFFVSUM8YnI+DQombmJzcDsgJm5ic3A7cHJv dG9jb2wgc3BlY2lmaWNhdGlvbnMsIHRodXMgaXQgbWF5IGJlIHBvc3NpYmxlIHRoYXQgdGhpcyBk cmFmdCBkb2VzPGJyPg0KJm5ic3A7ICZuYnNwO25vdCB3YXJyYW50IGEgd29ya2luZyBncm91cCBz dGF0dXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50b29scy5p ZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708A99BA37EA11B238C317887210BN6PR03MB2708namp_-- From nobody Thu Mar 9 23:49:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB37129853 for ; Thu, 9 Mar 2017 11:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=shimmercat-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 Uk9L1dbwIrPA for ; Thu, 9 Mar 2017 11:18:51 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 710E4128824 for ; Thu, 9 Mar 2017 11:18:51 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id u30so92471186uau.0 for ; Thu, 09 Mar 2017 11:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shimmercat-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e6M2cAkhG9JIFa7lTw2xOKCodUc2H3ZbZna4+tSeYzA=; b=BgVtdVElQ7JV7BY8TftWKBMYfff0i19DZAEkZNx0zZR291pLwxgGriuqeSmXdVLMop /2B95+9WuY++zebGsf387dH1bXL1dTUQI1hldoA99rfBpu7zHs0ODsPOaUvacrIhR841 mSlS3EXNzxFH6e7GcoCE/iISLMppmbIlNKYYYWW0I3NrurnXNmrXtpuL70ZdWcSTpFXD Fzpv+y7oN4CNgQF3ks5epAYMhw9rQ/R8QcY8Gm3lv3qdfjP8smm5t94FBJrcOgf1/0JE WDm+Yv+pvcjr5OTnWtQycfHfwjBktz6gG7AYkf554xgqytPXKVFZQmFr1GCz92nGOGwg cbEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e6M2cAkhG9JIFa7lTw2xOKCodUc2H3ZbZna4+tSeYzA=; b=S12oy+U6jr0Nkzk/sCNrckSvAyTTDjJ0kk6PMywBjobldCV/uv2aw1Gwxo8HZGJ+Rq F7vUUTresxoXHgC+8wzf8MAmRg32tI3SV307d50C3v3XYNedvoN4eCNX4Cc/doi4Xi7T HwYwh2XCK8gJ/QwxGL3jP36lVhQYk8/Fjs8Dc42yhYu8zGXAsVztTcg5JQOTs/uiLOyF pysz+AIyIc2CgHVyEMMVuS1ZXDJaeYdSWgKRncoy1asg9KkcJvU6lGHwnD3Z51vOt6p8 IJPc63kPpT3hD0Gsr1ZPKhFw1+z6wXN65eig1oJDTPNkuiVqYwo64sUx7XLQY4KkCDxa Cniw== X-Gm-Message-State: AMke39m75dtceQvYO9wfHiMnGmyR318+3wLGPPDadVZW65/zPeUv3TJsOT481bJ3NTc+7F3B6QY57nM2vt1EG2i0 X-Received: by 10.176.83.75 with SMTP id y11mr7130362uay.94.1489087130061; Thu, 09 Mar 2017 11:18:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.3.133 with HTTP; Thu, 9 Mar 2017 11:18:49 -0800 (PST) In-Reply-To: References: From: Alcides Viamontes E Date: Thu, 9 Mar 2017 20:18:49 +0100 Message-ID: Subject: Re: HTTP/QUIC Diverging from HTTP/2 To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c191e9c6dc03e054a511d96 Archived-At: X-Mailman-Approved-At: Thu, 09 Mar 2017 23:49:21 -0800 Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:18:53 -0000 --94eb2c191e9c6dc03e054a511d96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Mike, I have server implementations of SPDY and then later HTTP/2, which was supposed to be very close to SPDY with just a few refinements. Well it turned out that these "minor refinements" of HTTP/2 required a completely different software architecture. If I had known from the outset that HTTP/2 was that different from SPDY, I could have saved some time by implementing HTTP/2 from scratch on first instance. We have also considered to implement QUIC for a time, but the protocol and the draft describing it look quite complex, and this thing of QUIC being a transport for HTTP/2 being a transport for HTTP/1 doesn't make it easier. So my dream scenario would be to have a standard which only mentions HTTP/2 in passing. Of course QUIC being a transport for HTTP/1 semantics is completely acceptable and to a point, expected. On Thu, Mar 9, 2017 at 7:53 PM, Mike Bishop wrote: > At Patrick=E2=80=99s suggestion, I=E2=80=99m restating this question and = addressing it to > both the HTTP and QUIC working groups. Apologies if you=E2=80=99re alrea= dy > following along in QUIC and get this twice after having already seen it t= he > first time. > > > > HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session o= n > QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3= . > A number of HTTP/2 frames weren=E2=80=99t necessary, since they were dupl= icative of > services QUIC provides. In draft -01, we removed the full mux layer from > Stream 3, instead letting QUIC deal with all the stream management. This > necessitated changes to several of the remaining frames. By the current > editor=E2=80=99s copy, *no* HTTP/2 frame exists unmodified in HTTP/QUIC, = though > several frames of the same name and purpose exist. Likewise, RFC7540 > defines six settings, three of which are inapplicable in HTTP/QUIC. > > > > However, the draft currently still attempts to define them as close > cousins. It updates the HTTP/2 frame and setting registries with > additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification = if > applicable) and attempts to coexist with HTTP/2 in the same registry. > (QUIC defines a unified error space, which means a separate registry of > error codes for HTTP/QUIC regardless.) > > > > In PR #363 , I=E2=80=99ve > consolidated almost all of the =E2=80=9Cdifferent from HTTP/2=E2=80=9D te= xt into a new > top-level section and excised a lot of =E2=80=9CHTTP/2 has this, but HTTP= /QUIC > doesn=E2=80=99t need it=E2=80=9D text from the main body of the document.= Martin has > advocated making a clean break from HTTP/2 and defining our own IANA > registry for frame types and settings, just as we already have for errors= . > We can, out of respect for our cousin, use the same values where > appropriate and reserve existing values currently in use on the HTTP/2 si= de. > > > > I think that=E2=80=99s a good idea, and it=E2=80=99s a fairly small step = from the current > state of #363. I=E2=80=99ve created PR #376 > to actually make that > split. > > > > Comments from both WGs about the two PRs would be welcome. (Feedback so > far from the QUIC side seems to mostly be =E2=80=9Cseparate with regrets,= =E2=80=9D but not > universally.) > --=20 Alcides Viamontes E. Chief Executive Officer, Zunzun AB (+46) 722294542 (www.shimmercat.com is a property of Zunzun AB) --94eb2c191e9c6dc03e054a511d96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Mike,

I have server implementatio= ns of SPDY and then later HTTP/2, which was supposed to be very close to SP= DY with just a few refinements. Well it turned out that these "minor r= efinements" of HTTP/2 required a completely different software archite= cture. If I had known from the outset that HTTP/2 was that different from S= PDY, I could have saved some time by implementing HTTP/2 from scratch on fi= rst instance.

We have also considered to implement= QUIC for a time, but the protocol and the draft describing it look quite c= omplex, and this thing of QUIC being a transport for HTTP/2 being a transpo= rt for HTTP/1 doesn't make it easier. So my dream scenario would be to = have a standard which only mentions HTTP/2 in passing. Of course QUIC being= a transport for HTTP/1 semantics is completely acceptable and to a point, = expected.=C2=A0




On Thu, Mar 9, 2017 = at 7:53 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

At Patrick=E2=80=99s suggestion, I=E2=80=99m restati= ng this question and addressing it to both the HTTP and QUIC working groups= .=C2=A0 Apologies if you=E2=80=99re already following along in QUIC and get= this twice after having already seen it the first time.

=C2=A0

HTTP/QUIC started off (draft -00) with a mostly-comp= lete HTTP/2 session on QUIC Stream 3, including a full HTTP/2 multiplexing = layer within Stream 3.=C2=A0 A number of HTTP/2 frames weren=E2=80=99t nece= ssary, since they were duplicative of services QUIC provides.=C2=A0 In draft -01, we removed the full mux layer from Stre= am 3, instead letting QUIC deal with all the stream management.=C2=A0 This = necessitated changes to several of the remaining frames.=C2=A0 By the curre= nt editor=E2=80=99s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frame= s of the same name and purpose exist.=C2=A0 Likewise, RFC7540 defines six s= ettings, three of which are inapplicable in HTTP/QUIC.

=C2=A0

However, the draft currently still attempts to defin= e them as close cousins.=C2=A0 It updates the HTTP/2 frame and setting regi= stries with additional columns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Spec= ification if applicable) and attempts to coexist with HTTP/2 in the same registry.=C2=A0 (QUIC defines a unified er= ror space, which means a separate registry of error codes for HTTP/QUIC reg= ardless.)

=C2=A0

In PR #363, I=E2=80=99ve consolidated almost all of the =E2=80=9Cdifferent= from HTTP/2=E2=80=9D text into a new top-level section and excised a lot o= f =E2=80=9CHTTP/2 has this, but HTTP/QUIC doesn=E2=80=99t need it=E2=80=9D = text from the main body of the document.=C2=A0 Martin has advocated making = a clean break from HTTP/2 and defining our own IANA registry for frame types and setting= s, just as we already have for errors.=C2=A0 We can, out of respect for our= cousin, use the same values where appropriate and reserve existing values = currently in use on the HTTP/2 side.

=C2=A0

I think that=E2=80=99s a good idea, and it=E2=80=99s= a fairly small step from the current state of #363.=C2=A0 I=E2=80=99ve cre= ated PR #376 to actually make that split.

=C2=A0

Comments from both WGs about the two PRs would be we= lcome.=C2=A0 (Feedback so far from the QUIC side seems to mostly be =E2=80= =9Cseparate with regrets,=E2=80=9D but not universally.)




--
Alcides Viamontes E.
<= span style=3D"font-size:12.8px">Chief Executive Officer, Zunzun AB
(+46) 722294542
(www.shimmercat.com is= a property of Zunzun AB)
--94eb2c191e9c6dc03e054a511d96-- From nobody Fri Mar 10 00:39:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8141294FA for ; Fri, 10 Mar 2017 00:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=lukasa-co-uk.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 9mft4zpLP_sz for ; Fri, 10 Mar 2017 00:39:06 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FD1126B6D for ; Fri, 10 Mar 2017 00:39:06 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id v186so5176135wmd.0 for ; Fri, 10 Mar 2017 00:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OieS0sX4lRy1KU55dXukrOWknkvkjIm6eKA2p3fDpvM=; b=fhy3QvxG80+gn5oy3iA4TYnmTY4Z3CXOQrzOPxx5sTjN4KXyckLqdlQbd0PpDU2Fw7 GPpjzDySBYGVXkhZTf+Roz4Qbc2YPZmAFYxdnAm3Pj5Pztw14Gwn2Wu5A93vsr/ugYXy VekJ+0xMl9ogCeELSerhiDENbsLfCFx8fKQ9eCOqnpkqUje4j4xwCoxC6C39aNetjNli fxpDISHzl2AJI6fYuJWoNuprcFsIZf+oOquR95svulTPRsP0PisQOK+g3HDf+3PashKY pharAmW/gzhlK0gmKlbzaZ6AGzPIRv2yHUcGj/qPNlBwFmVLLjiUjfu8smOzRzZwNrfQ oDwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OieS0sX4lRy1KU55dXukrOWknkvkjIm6eKA2p3fDpvM=; b=lNz+/PwfMvEkqG2Ya9/G5tPiOs4IKTDL/MA0lWe0nW8x92wWCx3z0mLAcp88Ruo/Ej 3YYo+fAObfpf7MPrbXZjS9N3/h2scdE2h3h2BM4Sc6ru6txentV06e7uscTj1TUhzqT1 MOek8WNgruGXEtGC+xI7vBqiZvfgYZ34A/97F3BXUW96kPwbEaO7McZVzS43STrNjT7D 9M1Rsfv/JAKU4KQ9wmaKAtXLbEy38Fa8Skt1owPI7tKFSr5CCQn/1QRSW+GoEf3Himyk sKfTRX/sU6AUmmbjy8j59un/PlWBGQj0uVIkA7ech/an7wYIfC/uhAD4uPwWDiOHi+o8 RvIw== X-Gm-Message-State: AFeK/H1hOLu2vKgomTSUb4H+Q/8TlP0JuKz/lfzd84g9DFbK3zHYg+FrWpcKc7iNpsadjQ== X-Received: by 10.28.74.69 with SMTP id x66mr1236070wma.124.1489135144941; Fri, 10 Mar 2017 00:39:04 -0800 (PST) Received: from [192.168.1.3] (102.17.75.194.dyn.plus.net. [194.75.17.102]) by smtp.gmail.com with ESMTPSA id 136sm2226940wms.32.2017.03.10.00.39.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 00:39:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3272\)) Subject: Re: HTTP/QUIC Diverging from HTTP/2 From: Cory Benfield In-Reply-To: Date: Fri, 10 Mar 2017 08:39:02 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Bishop X-Mailer: Apple Mail (2.3272) Archived-At: Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 08:39:08 -0000 > On 10 Mar 2017, at 02:09, Mike Bishop = wrote: >=20 > Summary of feedback on this so far: > =E2=80=A2 Ekr: =E2=80=9CHoping we can converge, or at least = maximize overlap=E2=80=9D > =E2=80=A2 Stefan: =E2=80=9Cany hope to [converge] needs to be = abandoned=E2=80=9D > =E2=80=A2 Ian: =E2=80=9Cnot excited=E2=80=A6 but it may=E2=80=A6 = be the right thing to do=E2=80=9D > =E2=80=A2 Patrick: =E2=80=9Cseparate protocols=E2=80=9D > =E2=80=A2 Martin: =E2=80=9Ckeep the differences minimal=E2=80=9D = but =E2=80=9Cwe're really building a new protocol=E2=80=9D > =E2=80=A2 Alcides: if it=E2=80=99s different, make the = differences clear > =20 > If I=E2=80=99ve misconstrued anyone=E2=80=99s response, please speak = now; and obviously, more opinions are welcome. I would also appreciate = reviews on the text of the PRs themselves. > =20 > Unless there=E2=80=99s strong pushback in the next ~14 hours, I expect = to incorporate both PRs tomorrow, prior to the -02 publication. As Mark = noted recently, that doesn=E2=80=99t claim full consensus has been = reached, but there appears to be general support for considering these = separate protocols which are closely related, rather than two variants = of a single protocol. FWIW, I=E2=80=99m somewhere in between Ekr and Stefan. I think that = where possible overlap and convergence should be pursued, but I don=E2=80=99= t think we should hold our breaths. Ultimately I think in software = implementations there will be very little common code between HTTP/2 and = QUIC: barely any more than there is between HTTP/1.1 and HTTP/2, and = potentially less. That suggests that HTTP/2 and QUIC are no more closely = related to each other than HTTP/2 is to HTTP/1.1. That sounds to me like =E2=80=9Cclose cousins, but different = protocols=E2=80=9D. Cory From nobody Fri Mar 10 00:58:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82726129706 for ; Fri, 10 Mar 2017 00:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=Tcapl8p1; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=Tcapl8p1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KOmWg-tLP-c for ; Fri, 10 Mar 2017 00:58:31 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1FD126B6D for ; Fri, 10 Mar 2017 00:58:31 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id D3EBA15A1704; Fri, 10 Mar 2017 09:58:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489136309; bh=+jt1qRV2r+pZzsOCPdnfL1HtMuzBRkQOnYGchpwL/jI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Tcapl8p1+Y9h7bD3nuVYmGKlHjWCSawkQjjKgMAvJUeIUB6/7AQiScDd+sKQlME1k p5wQn6nWgWCaHiAH+5CrCGeCQydigDRHzzQCqf/Ifc6AVOC97NKBjVzLbhGKHGjVlU UcRC/OMfWJ5TbwNQMaNVBKDdai0RTo7tj4gKBISI= Received: from [192.168.1.38] (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 1CB2015A071A; Fri, 10 Mar 2017 09:58:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489136309; bh=+jt1qRV2r+pZzsOCPdnfL1HtMuzBRkQOnYGchpwL/jI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Tcapl8p1+Y9h7bD3nuVYmGKlHjWCSawkQjjKgMAvJUeIUB6/7AQiScDd+sKQlME1k p5wQn6nWgWCaHiAH+5CrCGeCQydigDRHzzQCqf/Ifc6AVOC97NKBjVzLbhGKHGjVlU UcRC/OMfWJ5TbwNQMaNVBKDdai0RTo7tj4gKBISI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 From: Stefan Eissing In-Reply-To: Date: Fri, 10 Mar 2017 09:58:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Patrick McManus X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Mike Bishop , Ian Swett , Hannes Tschofenig , "quic@ietf.org" , "Brian Trammell \(IETF\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 08:58:33 -0000 > Am 09.03.2017 um 18:16 schrieb Patrick McManus : >=20 > no joke - I tested out 53/80/443 on a Digital Ocean virtual host last = weekend and only 53 moved bidirectionally (it all worked inbound) - = though I suspect that's more bug than policy and can be resolved by = market interest. Deep down, everything is a DNS query. -Stefan From nobody Fri Mar 10 01:12:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B811297A5 for ; Fri, 10 Mar 2017 01:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 eE8jGasjlgSR for ; Fri, 10 Mar 2017 01:12:49 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0674129717 for ; Fri, 10 Mar 2017 01:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2294; q=dns/txt; s=iport; t=1489137168; x=1490346768; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=xBNGJjPQg+e62ALjlfyWGVgnp83xvxZ5wmJcNPZHh6U=; b=e1eS4HO2fCWUltRE3uAI7Jm39BzvASsJi2xf2arPM1bhMI4ZG9PEZdQO 1sbNZJ1WUJCy1bfFRry3+vlMN5Mof8Ui7rpK8b2wXHk980W/a3DdtGLy9 xQk5fWaUJ7wFVirjtJ8arCuCTHqJXhT4kNu1ja8MuPaXWJQgb5MSVcSTs k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAQCAbcJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhFyEQIoNc5A+H5U4gg6GIgKCdRgBAgEBAQEBAQFrKIUWAQQBI1Y?= =?us-ascii?q?FCwtCAgJXBgEMCAEBiXQIsQCCJopqAQEBAQEBAQEBAQEBAQEBAQEBEQ+IUwiCY?= =?us-ascii?q?odagl8BBJw5g3iCCYw3gWOIbIZRkz8fOIEDIhUIFxU/hlU/imABAQE?= X-IronPort-AV: E=Sophos;i="5.36,139,1486425600"; d="asc'?scan'208";a="650321118" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 09:12:46 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2A9Ckwu005865; Fri, 10 Mar 2017 09:12:46 GMT Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 To: "Brian Trammell (IETF)" , Hannes Tschofenig References: From: Eliot Lear Message-ID: <73ae956c-5091-3a4d-b0f5-1b24bc9c0d49@cisco.com> Date: Fri, 10 Mar 2017 10:12:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eSRG02ulDQXVF379pNltlRbuoJXmDETBI" Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 09:12:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eSRG02ulDQXVF379pNltlRbuoJXmDETBI Content-Type: multipart/mixed; boundary="fNec7CCtHlKwCtiGUqgcJDbOaRRbbtwiE"; protected-headers="v1" From: Eliot Lear To: "Brian Trammell (IETF)" , Hannes Tschofenig Cc: "quic@ietf.org" Message-ID: <73ae956c-5091-3a4d-b0f5-1b24bc9c0d49@cisco.com> Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 References: In-Reply-To: --fNec7CCtHlKwCtiGUqgcJDbOaRRbbtwiE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, On 3/9/17 12:30 PM, Brian Trammell (IETF) wrote: > Basic network handling on CPE is a pretty mature market though. Throwin= g a student at this (on someone else's menagerie) is on my list of stuff = to do someday, though. > I don't think it will remain so. How the CPE evolves will really depend on what is in the CP ;-) Directionality in particular remains important and will perhaps become more so with IoT devices. Also what happens in customer prem and what is handled upstream is evolving. --fNec7CCtHlKwCtiGUqgcJDbOaRRbbtwiE-- --eSRG02ulDQXVF379pNltlRbuoJXmDETBI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwm4NAAoJEIe2a0bZ0noz27kIAIylZIhUYbdC7NGqG4vaW2H/ Gb5eP0yg9VyLk3+rY2DJ7HubQ1cM5E5atVadqxFa0cQpvwMpNQadWDCxiS0xN5yJ CLG0rGns1lkJwLSFWp5rj5BTqa5p29PmmTXgCGzNY8tSJ5SJQ3QPLsjeY/MqB1aF rBGC5PMv0KfWEn5WVikElI15DpqoEkIvXk3EuXCpdlkf/a4bNzEO2XvLMCiiOCa/ 6LBtfexDzhCiV5yKd3NZn9zSjqdTH1r7/ZcNwpP1kFQHZjQXNBv5W9EjplWkpozi FX6GsXt/DwO393xEFbjPAQNfopA7jR0BubQtoEwyVUgblfqU23znWXKmRGq9axA= =JY9b -----END PGP SIGNATURE----- --eSRG02ulDQXVF379pNltlRbuoJXmDETBI-- From nobody Fri Mar 10 04:14:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216E1298AE for ; Fri, 10 Mar 2017 04:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 R3YBj0fvPuSk for ; Fri, 10 Mar 2017 04:14:30 -0800 (PST) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90CD1298AC for ; Fri, 10 Mar 2017 04:14:29 -0800 (PST) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v2ACER72025811; Fri, 10 Mar 2017 12:14:27 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0319.002; Fri, 10 Mar 2017 12:14:27 +0000 From: Lucas Pardue To: Mike Bishop , "quic@ietf.org" , HTTP working group mailing list Subject: RE: HTTP/QUIC Diverging from HTTP/2 Thread-Topic: HTTP/QUIC Diverging from HTTP/2 Thread-Index: AdKZAt9YNciLyZHpRWy2RhBs+G6fSwAiO2Lg Date: Fri, 10 Mar 2017 12:14:27 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A376F4517@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22932.006 x-tm-as-result: No--27.024400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A376F4517bgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:14:32 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A376F4517bgb01xud1012_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, my opinion as "not an implementer". I support a clean break. The background thinking on my part has been in relation to the ALTSVC exten= sion frame, and where its registration should be defined. An independent HT= TP/QUIC frame type table (that ports over the non-extension RFC 7540 frame = types) simplifies this problem, shifting the responsibility to the extensio= n documents (or their updates). As others have pointed out, there may be a = burden with the single table approach of requiring new HTTP/2 extensions to= consider HTTP/QUIC. I'd also say ALTSVC is a good case study for another reason. It defines a n= ew HTTP semantic that is mapped to both an HTTP Header Field and an HTTP/2 = extension frame, which are registered differently. The one risk with separate tables is that the Frame type codes diverge over= time. A pragmatic mitigation might be to reserve the code in both tables, = even if this is a placeholder for future work. In considering this topic, I was reminded of Mike's earlier work on decompo= sing HTTP, captured in the I-D draft-bishop-decomposing-http. Lucas From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop Sent: 09 March 2017 18:54 To: quic@ietf.org; HTTP working group mailing list Subject: HTTP/QUIC Diverging from HTTP/2 At Patrick's suggestion, I'm restating this question and addressing it to b= oth the HTTP and QUIC working groups. Apologies if you're already followin= g along in QUIC and get this twice after having already seen it the first t= ime. HTTP/QUIC started off (draft -00) with a mostly-complete HTTP/2 session on = QUIC Stream 3, including a full HTTP/2 multiplexing layer within Stream 3. = A number of HTTP/2 frames weren't necessary, since they were duplicative o= f services QUIC provides. In draft -01, we removed the full mux layer from= Stream 3, instead letting QUIC deal with all the stream management. This = necessitated changes to several of the remaining frames. By the current ed= itor's copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several= frames of the same name and purpose exist. Likewise, RFC7540 defines six = settings, three of which are inapplicable in HTTP/QUIC. However, the draft currently still attempts to define them as close cousins= . It updates the HTTP/2 frame and setting registries with additional colum= ns (HTTP/2, HTTP/QUIC, or Both?; HTTP/QUIC Specification if applicable) and= attempts to coexist with HTTP/2 in the same registry. (QUIC defines a uni= fied error space, which means a separate registry of error codes for HTTP/Q= UIC regardless.) In PR #363, I've consolidat= ed almost all of the "different from HTTP/2" text into a new top-level sect= ion and excised a lot of "HTTP/2 has this, but HTTP/QUIC doesn't need it" t= ext from the main body of the document. Martin has advocated making a clea= n break from HTTP/2 and defining our own IANA registry for frame types and = settings, just as we already have for errors. We can, out of respect for o= ur cousin, use the same values where appropriate and reserve existing value= s currently in use on the HTTP/2 side. I think that's a good idea, and it's a fairly small step from the current s= tate of #363. I've created PR #376 to actually make that split. Comments from both WGs about the two PRs would be welcome. (Feedback so fa= r from the QUIC side seems to mostly be "separate with regrets," but not un= iversally.) --_000_7CF7F94CB496BF4FAB1676F375F9666A376F4517bgb01xud1012_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW, my = opinion as “not an implementer”.

&nbs= p;

I support= a clean break.

&nbs= p;

The backg= round thinking on my part has been in relation to the ALTSVC extension fram= e, and where its registration should be defined. An independent HTTP/QUIC f= rame type table (that ports over the non-extension RFC 7540 frame types) simplifies this problem, shifting the = responsibility to the extension documents (or their updates). As others hav= e pointed out, there may be a burden with the single table approach of requ= iring new HTTP/2 extensions to consider HTTP/QUIC.

&nbs= p;

I’d= also say ALTSVC is a good case study for another reason. It defines a new = HTTP semantic that is mapped to both an HTTP Header Field and an HTTP/2 ext= ension frame, which are registered differently.

&nbs= p;

The one r= isk with separate tables is that the Frame type codes diverge over time. A = pragmatic mitigation might be to reserve the code in both tables, even if t= his is a placeholder for future work.

&nbs= p;

In consid= ering this topic, I was reminded of Mike’s earlier work on decomposin= g HTTP, captured in the I-D dr= aft-bishop-decomposing-http.

&nbs= p;

Lucas

&nbs= p;

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop
Sent: 09 March 2017 18:54
To: quic@ietf.org; HTTP working group mailing list <ietf-http-wg@= w3.org>
Subject: HTTP/QUIC Diverging from HTTP/2

 

At Patrick’s suggestion, = I’m restating this question and addressing it to both the HTTP and QU= IC working groups.  Apologies if you’re already following along = in QUIC and get this twice after having already seen it the first time.

 

HTTP/QUIC started off (draft -0= 0) with a mostly-complete HTTP/2 session on QUIC Stream 3, including a full= HTTP/2 multiplexing layer within Stream 3.  A number of HTTP/2 frames= weren’t necessary, since they were duplicative of services QUIC provides.  In draft -01, we removed the full mux lay= er from Stream 3, instead letting QUIC deal with all the stream management.=   This necessitated changes to several of the remaining frames.  = By the current editor’s copy, no HTTP/2 frame exists unmodified in HTTP/QUIC, though several frame= s of the same name and purpose exist.  Likewise, RFC7540 defines six s= ettings, three of which are inapplicable in HTTP/QUIC.

 

However, the draft currently st= ill attempts to define them as close cousins.  It updates the HTTP/2 f= rame and setting registries with additional columns (HTTP/2, HTTP/QUIC, or = Both?; HTTP/QUIC Specification if applicable) and attempts to coexist with HTTP/2 in the same registry.  (QUIC defi= nes a unified error space, which means a separate registry of error codes f= or HTTP/QUIC regardless.)

 

In PR #363, I’ve consolidated almost all of the “different fro= m HTTP/2” text into a new top-level section and excised a lot of R= 20;HTTP/2 has this, but HTTP/QUIC doesn’t need it” text from th= e main body of the document.  Martin has advocated making a clean brea= k from HTTP/2 and defining our own IANA registry for frame types and setting= s, just as we already have for errors.  We can, out of respect for our= cousin, use the same values where appropriate and reserve existing values = currently in use on the HTTP/2 side.

 

I think that’s a good ide= a, and it’s a fairly small step from the current state of #363. = I’ve created PR #376 to a= ctually make that split.

 

Comments from both WGs about th= e two PRs would be welcome.  (Feedback so far from the QUIC side seems= to mostly be “separate with regrets,” but not universally.)

--_000_7CF7F94CB496BF4FAB1676F375F9666A376F4517bgb01xud1012_-- From nobody Fri Mar 10 04:34:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F22129951 for ; Fri, 10 Mar 2017 04:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svWJSUarQ5jA for ; Fri, 10 Mar 2017 04:33:59 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 F1DFA1298C7 for ; Fri, 10 Mar 2017 04:33:58 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id v125so161269795qkh.2 for ; Fri, 10 Mar 2017 04:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6VHudOhRfGXVELuWDQSzioB6gYnUl3nLmSVxTqx4eJE=; b=V6Wrshq5rB1oluP/CUVp4veMLy5CEGukTlB2qah2Ijg9AhuU0CdQc6A1WtDoScoId4 uWa5NkXZbDrxTq103xq0Z0mNw9WdnjeVbxOdy6N1EP2B4b+OB012avMsie3RS9886M2J 18h07f5ht8z/WsMy/QIukfKMQsD+/Qb4xWr18= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6VHudOhRfGXVELuWDQSzioB6gYnUl3nLmSVxTqx4eJE=; b=m8dIKAhPvEElD6s3UJhzl0wv4/CE+ceR1I8l+STWGVg2w1HqBUoLqJFL1KLqaVYgVL JouzRIVzA2nXNVI4mm/eO/5uJFbdBRIG+V4YYEwGOTX7lo6ZBWBHf+v1qaO6m7pdEA6b Y3sLm55moXe6gvZzBHl/7DGFseo3NpZ92Cc6q/ZXvcZq42PNpc+xwXkty7Y/Y5wGg1S1 tz6g84jEw+E9NIdeyD6DsGSkmVFGwS9ESNzA0BeQenFlwkai9b81AFruLBF13H8+63Ak pEiI+lf+HEr1lUJEO58e5qBb7CfjE8KXwGYNV+ncCg5A/vjYCZk90DGvC33LMvQrjrp1 IPsA== X-Gm-Message-State: AMke39myiqvHdIusRUI/ceA7ZS4S9ULaIejAkue9ZG+Zc38af3xuvY8xBx+fu075wr9aPvfha5ewJnRHa/t9Fw== X-Received: by 10.200.42.78 with SMTP id l14mr20525211qtl.15.1489149237758; Fri, 10 Mar 2017 04:33:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 10 Mar 2017 04:33:57 -0800 (PST) X-Originating-IP: [2001:470:1f07:121:103e:c9ff:fe51:acfa] In-Reply-To: <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Kyle Rose Date: Fri, 10 Mar 2017 07:33:57 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11403d8655bd38054a5f93f0 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:34:01 -0000 --001a11403d8655bd38054a5f93f0 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 1:24 AM, Eliot Lear wrote: > On 3/10/17 6:39 AM, Lubashev, Igor wrote: > > I would not be banking on tethering remaining a fringe activity. This may > be true today, but it is rapidly changing with proliferation of connected > cars, buses, trains, and other mobile hotspots. And I will not even venture > a guess about technologies available in 10-15 years. > > > But you can't engineer around such vagaries. > I don't think you can assert that for all cases. I think you may be able to conclude some variant of that statement for classes of problems requiring the client to know where it is on the network. E.g., basing the answer to the statement "should my podcast player download a 100MB podcast?" on whether the device is connected to wifi can't take into account whether wifi is really cell tethering without extra telemetry. But you can certainly deal with linkability of clients obliviously changing networks if you're willing to accept some variant of never sending the same connection ID twice. The remaining questions are around the costs and tradeoffs of mechanisms to achieve this, including the perfectly legitimate question of whether it's worth any added complexity at all. Kyle --001a11403d8655bd38054a5f93f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 1:24 AM, Eliot Lear <lear@cisco.com> wrote:=
=20 =20 =20
=20
On 3/10/17 6:39 AM,= Lubashev, Igor wrote:
=20 =20 I would not be banking on tethering remaining a fringe= activity. This may be true today, but it is rapidly changing with proliferation of connected cars, buses, trains, and other mobile hotspots. And I will not even venture a guess about technologies available in 10-15 years.

 But you can't engineer around such vagaries.=

I don't think you can ass= ert that for all cases.

I think you may be able to conclude some var= iant of that statement for classes of problems requiring the client to know= where it is on the network. E.g., basing the answer to the statement "= ;should my podcast player download a 100MB podcast?" on whether the de= vice is connected to wifi can't take into account whether wifi is reall= y cell tethering without extra telemetry.

But you can cer= tainly deal with linkability of clients obliviously changing networks if yo= u're willing to accept some variant of never sending the same connectio= n ID twice. The remaining questions are around the costs and tradeoffs of m= echanisms to achieve this, including the perfectly legitimate question of w= hether it's worth any added complexity at all.

Kyle
--001a11403d8655bd38054a5f93f0-- From nobody Fri Mar 10 04:41:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2996F1298CC for ; Fri, 10 Mar 2017 04:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0yr1iX8aWjg for ; Fri, 10 Mar 2017 04:41:38 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 42FC612994F for ; Fri, 10 Mar 2017 04:33:53 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id h10so6509110ith.1 for ; Fri, 10 Mar 2017 04:33:53 -0800 (PST) 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=HLpUo2EkOufhq3TvfJEmiP8YsalqP/o0ETekqdbx4rc=; b=eW2UeGh/j7szm7TSVVg7Ok4AZl7Zb9q+8GWXgDFWYa0kf+X5ID0rGhkOnmKG6HlZUv AlB0dlETm1eSs5BFuodj3brtvil4/aKSHh5U5utyusrp/BN+NlCkc5ORJ0o414+1Tkkb j8B0JmnaSnYCx13PSyDHF7OYuEE4i4caVscYdcKlBC34sRyck/JklpaLk1ahqbl25mY6 RJHqGCjvc7fSuKwMlv5Yf6BxAHhUjCHjhNbwaQFMl/SXJGMgt/qPt5noPRaUjdayVT3Q 5qcg5LTufy6bUGHK2n/wyHm4c0Gm1saDDBxrF3q+d4t7E4T3lbRVBfFjd3INhIublHvu DL3w== 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=HLpUo2EkOufhq3TvfJEmiP8YsalqP/o0ETekqdbx4rc=; b=Qm6Gajlua8qnQY0nb6koi0sEveJwQO3Ef+XfY7PzrfkK12lbTx/Phhs77kGe0+eOY0 7rVCav9rCUUv6nMudEGcHa8GjxqpAbdh/Ll0FKxOYCb420sKuxQOkTEOvaibUK1GPX1D fUEENUAiJ17RNruRyI+yq6cYnNh+jKLV9NX/mcf9LyPN/QXEW1sluA/dzCuGt/0KZbOZ JI4JJ3WFf88RKrBK3qlyqxXleL1Z64HbtJZN3xrlfY+ERVnft6yEE5+BaKXsdE6dAyFQ wtE3CMfpeKy+ThzsonOcslxXtm7kJcJM56xLjuKhHZ5AJJlMTQ0WTniCct2llVZRamxr qTAw== X-Gm-Message-State: AFeK/H3leUxKd/WzoofnvLl7FpQPpLyWfN28envIhtqu9bRoenRf5TWw8yhTHWAw72ddaTaGSdxg9XqzYcfbvw== X-Received: by 10.36.127.73 with SMTP id r70mr1817484itc.11.1489149232592; Fri, 10 Mar 2017 04:33:52 -0800 (PST) MIME-Version: 1.0 References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> In-Reply-To: <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Lucas Clemente Date: Fri, 10 Mar 2017 12:33:41 +0000 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eliot Lear , "Lubashev, Igor" , "ekr@rtfm.com" , "jri@google.com" Content-Type: multipart/alternative; boundary=001a1147c5ae06bb1a054a5f9393 Archived-At: Cc: "ietf@trammell.ch" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 12:41:39 -0000 --001a1147c5ae06bb1a054a5f9393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm a bit late to this party, but I'd like to chime in from an implementor's perspective. I think we should be careful about adding even more complexity to the public header (and the protocol in general). Some of the proposals here would require information to be passed between otherwise cleanly separated areas of the protocol (e.g. for adding infos about received packets into the header), or make parsing the header even more complicated. This could increase the probability of bugs in implementations, or =E2=80=93 even wors= e =E2=80=93 in middleboxes, which could fail to understand uncommon public header configurations. On Fri, 10 Mar 2017 at 07:24 Eliot Lear wrote: > > On 3/10/17 6:39 AM, Lubashev, Igor wrote: > > > The tethering case is real, but it's a corner case; > > connection migrations are dominated by > > untethered clients. > > I would not be banking on tethering remaining a fringe activity. This may > be true today, but it is rapidly changing with proliferation of connected > cars, buses, trains, and other mobile hotspots. And I will not even ventu= re > a guess about technologies available in 10-15 years. > > > But you can't engineer around such vagaries. > > > Eliot > --001a1147c5ae06bb1a054a5f9393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm a bit late to this party, but I'd like to chim= e in from an implementor's perspective.

I think we s= hould be careful about adding even more complexity to the public header (an= d the protocol in general). Some of the proposals here would require inform= ation to be passed between otherwise cleanly separated areas of the protoco= l (e.g. for adding infos about received packets into the header), or make p= arsing the header even more complicated. This could increase the probabilit= y of bugs in implementations, or =E2=80=93 even worse =E2=80=93 in middlebo= xes, which could fail to understand uncommon public header configurations.<= /div>

O= n Fri, 10 Mar 2017 at 07:24 Eliot Lear <lear@cisco.com> wrote:


On 3/10/= 17 6:39 AM, Lubashev, Igor wrote:
=20 =20 > The tethering case is real, but it's a corner case;
> connection migrations are dominated by
> untethered clients.

I would not be banking on tethering remaining a fringe activity. This may be true today, but it is rapidly changing with proliferation of connected cars, buses, trains, and other mobile hotspots. And I will not even venture a guess about technologies available in 10-15 years.

But you can't engineer around such vagaries.

=C2=A0
Eliot
--001a1147c5ae06bb1a054a5f9393-- From nobody Fri Mar 10 05:30:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8FD129575 for ; Fri, 10 Mar 2017 05:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 P4_-uvSY7Ege for ; Fri, 10 Mar 2017 05:30:01 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C8B12956F for ; Fri, 10 Mar 2017 05:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8461; q=dns/txt; s=iport; t=1489152600; x=1490362200; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=oi1WtZSDrD8hqIVt27lbL50KOIuYcxAwAwcjhdtairo=; b=mZP+1DkcOggIEPAbad3PY0fZi9sN0G//LTGR/eDEAdbc/wEzz19mKhiw RdvNF6Fjkpw2V2gfVfRy/UgAeshJh84gJnoXi3ui78aN+WWGUPiCnhDVB 32z0IuUzl2eSU9KCplBpnFXYuxdenYLr91P69lYJJoF6/b8WEzOZefkAO E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVBgB4qcJY/xbLJq1HFhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJugW5gg2CLAZBdkAuFLYIOhiICgn0WAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?FI1YQCw4KFRIDAgJGEQYNBgIBAYl8r38PgSCCJiuKPAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQ4PiFOCaoQfdIJHgl8FnDqDeIIJjDeKUYZRk0AmAi+BAyIWCBcVhRQ?= =?us-ascii?q?dgWQ/NYoaAQEB?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="asc'?scan'208,217";a="651350347" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 13:29:56 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2ADTtFP000394; Fri, 10 Mar 2017 13:29:55 GMT Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Eliot Lear Message-ID: Date: Fri, 10 Mar 2017 14:29:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JCTdKoKnUfJJo2L2gcK3LGxp8ik8QCHUm" Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 13:30:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JCTdKoKnUfJJo2L2gcK3LGxp8ik8QCHUm Content-Type: multipart/mixed; boundary="WDBSjHfQlqC46IJL5UOKu6PxKrwg2PPkI"; protected-headers="v1" From: Eliot Lear To: Kyle Rose Cc: "Lubashev, Igor" , "ekr@rtfm.com" , "jri@google.com" , "ietf@trammell.ch" , "quic@ietf.org" Message-ID: Subject: Re: Middlebox introspection/self-describing packets References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> In-Reply-To: --WDBSjHfQlqC46IJL5UOKu6PxKrwg2PPkI Content-Type: multipart/alternative; boundary="------------82DBD7FCEABC5289BC12B8CF" This is a multi-part message in MIME format. --------------82DBD7FCEABC5289BC12B8CF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/10/17 1:33 PM, Kyle Rose wrote: > On Fri, Mar 10, 2017 at 1:24 AM, Eliot Lear > wrote: > > On 3/10/17 6:39 AM, Lubashev, Igor wrote: >> I would not be banking on tethering remaining a fringe activity. >> This may be true today, but it is rapidly changing with >> proliferation of connected cars, buses, trains, and other mobile >> hotspots. And I will not even venture a guess about technologies >> available in 10-15 years. > > But you can't engineer around such vagaries. > > > I don't think you can assert that for all cases. > > I think you may be able to conclude some variant of that statement for > classes of problems requiring the client to know where it is on the > network. E.g., basing the answer to the statement "should my podcast > player download a 100MB podcast?" on whether the device is connected > to wifi can't take into account whether wifi is really cell tethering > without extra telemetry. > But you can certainly deal with linkability of clients obliviously > changing networks if you're willing to accept some variant of never > sending the same connection ID twice. The remaining questions are > around the costs and tradeoffs of mechanisms to achieve this, > including the perfectly legitimate question of whether it's worth any > added complexity at all. Igor did not assert how the above technology will operate. For 3G networks, this probably matters very little in practice. On the other side of the spectrum (though not literally) there will be ad hoc networks that route only quite locally. And then there is 6lopan.=20 State your assumptions. Then design. Eliot --------------82DBD7FCEABC5289BC12B8CF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 3/10/17 1:33 PM, Kyle Rose wrote:
On Fri, Mar 10, 2017 at 1:24 AM, Eliot Lear <lear@cis= co.com> wrote:
=
On 3/10/17 6:39 AM, Lubashev, Igor wrote:
I would not be banking on tethering remaining a fringe activity. This may be true today, but it is rapidly changing with proliferation of connected cars, buses, trains, and other mobile hotspots. And I will not even venture a guess about technologies available in 10-15 years.

 But you can't engineer around such vagaries.

I don't think you can assert that for all cases.

I think you may be able to conclude some variant of that statement for classes of problems requiring the client to know where it is on the network. E.g., basing the answer to the statement "should my podcast player download a 100MB podcast?" on whether the device is connected to wifi can't take into account whether wifi is really cell tethering without extra telemetry.
But you can certainly deal with linkability of clients obliviously changing networks if you're willing to accept some variant of never sending the same connection ID twice. The remaining questions are around the costs and tradeoffs of mechanisms to achieve this, including the perfectly legitimate question of whether it's worth any added complexity at all.

Igor did not assert how the above technology will operate.=C2=A0 For = 3G networks, this probably matters very little in practice.=C2=A0 On the= other side of the spectrum (though not literally) there will be ad hoc networks that route only quite locally.=C2=A0 And then there is 6lopan.=C2=A0 State your assumptions.=C2=A0 Then design.

Eliot
--------------82DBD7FCEABC5289BC12B8CF-- --WDBSjHfQlqC46IJL5UOKu6PxKrwg2PPkI-- --JCTdKoKnUfJJo2L2gcK3LGxp8ik8QCHUm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwqpSAAoJEIe2a0bZ0nozS4MIAMjzUG+zcTPWzDsWb97kcFS5 w1liEZaPndZv97eHmTyoW/nensTU4Ly2dli+j+JkGrHO7XKBGAkAlmsBehC3dk5m nz5Ak4/UvK0TG4JFfTscV6MxowsqGvn8x1lAb7c0b+yMecjm/MnZyCO1Q0RtpMwz 5KY/SFZI0EYvo5O+6VKJLHbc3hYEm/Y1qSFza2u/zvPB+zSGk2KrH+f0VUpFJmFR NInpfSosOHiDeQBhjaUb3Bum/K95PEcWNVBuhdeVDYIKuGJ+msAO8YlyNUdgfaVW ET8A+zWWLStQKTnXEV1B+0oG5zT+zzm5xU8QOTTHmD149X31bf25f9qt3v1WDGg= =Npv7 -----END PGP SIGNATURE----- --JCTdKoKnUfJJo2L2gcK3LGxp8ik8QCHUm-- From nobody Fri Mar 10 07:05:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BE212996E for ; Fri, 10 Mar 2017 07:04:58 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 2bAkGeBKgza7 for ; Fri, 10 Mar 2017 07:04:57 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73B2129973 for ; Fri, 10 Mar 2017 07:04:56 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id p77so25232282ywg.1 for ; Fri, 10 Mar 2017 07:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKsnBmX3144TWx4P/Uu9N/DSuGtF+hvjt0zqrRNr/UY=; b=O5LHW6NGqoCrB7fGmf/YWHx0DJE4AXQbv0TQOe6ADxioNnXoxxfWUpe1x54ksVYiJ4 KcdSprq9/TQBx5u/wf6ZUwYwHjKgxhz6eB37Oq5xrUb8YOzl+/f8zYMQZxmdTGFfJuYr ksEyzlWBCR5csn7g9iUPl9mMjOA8hZxSJcdUs7F4ORt2R3IQBPIIzioNx0lVhvcTL5uV kTAFllcxeON4o0dDHfOtBAXBYq4Qz4YAjglKm1FsXGl1Jnz+3mufekfUt7HkVrR+2b5W lz5K/zhTBFbT1jDJVRG7ZWEdAFTqXe2n3QekSNk44Q86p/3cy+xRK8K+9eQy40H1wvMk zgMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IKsnBmX3144TWx4P/Uu9N/DSuGtF+hvjt0zqrRNr/UY=; b=ArXfJzDqaBIh6BsxGtAySaMrHa1LcbdzAPQwMEeka8mgWSBGSc6x3r7wVl8qYMx7kc ZFuX/D9HkHMHEtf6Eg/15GBb/6sXK18D2opcvYv9wq/PEGGRxsVrnkolijhR1IS7xBJI J/zD+rfZ0HP0kHQfRt9Fmi6UTdaQNs5V+ajAy9MLs+HUIEGe33I5Nq6xtCvNLuQtCVGn fQXSz/ZL0gKJYPXBPwN/bDmME/v0XNTsohk+JuA2QxpytDm3ldPKCHlJuzJe/UKbaAeF RskwFYwq8qZh0fEbtA9kDsSkMLn55GE+ZMUH/HoK31hMDJkwk4xi6LhVHtTfd0WWYokj 33Pw== X-Gm-Message-State: AMke39mevmAKmOApwV3fMECNvf8kxYcPRaM6pdOJ3bIKmy8rSaTQErLy8W8PisAoK3V7fpwGrprQuYJHiKUkNg== X-Received: by 10.37.173.82 with SMTP id l18mr8682477ybe.107.1489158296145; Fri, 10 Mar 2017 07:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 07:04:15 -0800 (PST) In-Reply-To: <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Eric Rescorla Date: Fri, 10 Mar 2017 07:04:15 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eliot Lear Content-Type: multipart/alternative; boundary=f403045eb8ea41ca18054a61af9e Archived-At: Cc: "jri@google.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:04:59 -0000 --f403045eb8ea41ca18054a61af9e Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 10:24 PM, Eliot Lear wrote: > > On 3/10/17 6:39 AM, Lubashev, Igor wrote: > > > The tethering case is real, but it's a corner case; > > connection migrations are dominated by > > untethered clients. > > I would not be banking on tethering remaining a fringe activity. This may > be true today, but it is rapidly changing with proliferation of connected > cars, buses, trains, and other mobile hotspots. And I will not even venture > a guess about technologies available in 10-15 years. > > > But you can't engineer around such vagaries. > Huh? The point here is that we shouldn't bake in assumptions that may not be true in the future and will have significantly negative consequences if they become untrue. -Ekr > > Eliot > --f403045eb8ea41ca18054a61af9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 10:24 PM, Eliot Lear <lear@cisco.com> wrote:
=20 =20 =20


On 3/10/17 6:39 AM= , Lubashev, Igor wrote:
=20 =20 > The tethering case is real, but it's a corner case;
> connection migrations are dominated by
> untethered clients.

I would not be banking on tethering remaining a fringe activity. This may be true today, but it is rapidly changing with proliferation of connected cars, buses, trains, and other mobile hotspots. And I will not even venture a guess about technologies available in 10-15 years.

 But you can't engineer around such vagaries.

Huh? The point here is that we shouldn't bake in assump= tions that may not be true in the
future and will have significan= tly negative consequences if they become untrue.

-= Ekr


=C2=A0
Eliot

--f403045eb8ea41ca18054a61af9e-- From nobody Fri Mar 10 07:22:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CCE129485 for ; Fri, 10 Mar 2017 07:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1Uvn79j7elEU for ; Fri, 10 Mar 2017 07:22:54 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C1E128AC9 for ; Fri, 10 Mar 2017 07:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4112; q=dns/txt; s=iport; t=1489159374; x=1490368974; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=oN3ThcMq33YLWQaaak7rSVsVQ1uVTJ+31+OPFceENVw=; b=KWEok031dEmDg9p/M/81JANPa9Ggk1jCoNSA+FPalDc9SE3fh943po7C Xc/LBbD6//IMdW99grtshu+hJgGu+7vv9ZhVGtHz5fv9fSevSburfqDYP tWK9wTnJ7pfB/9bYR2RBzjSMJhHSuD0pj6exMrkYjACfxTJoA11kTk+2u 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBwDQw8JY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhFyEQIsBkD4fkAuFLYIOhiICgwAXAQIBAQEBAQEBayiFDAoBBSN?= =?us-ascii?q?WEAsDAQoKKgICVwYNCAEBiXyxUIImK4o/AQEBAQEBAQEBAQEBAQEBAQEBAQEBD?= =?us-ascii?q?g+IUwiCYodagl8BBJV6hkCDeIIJjDeKUYZRk0AgATaBAyIWCBcVhxU/ik8BAQE?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="asc'?scan'208,217";a="653173594" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 15:22:49 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2AFMm4B014065; Fri, 10 Mar 2017 15:22:49 GMT Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Eliot Lear Message-ID: <6c9d2c13-8659-af90-a65a-8ebd5c75f24e@cisco.com> Date: Fri, 10 Mar 2017 16:22:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lfv29nWWAeE22txklR5GNdrM2LxX6Avf8" Archived-At: Cc: "jri@google.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 15:22:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lfv29nWWAeE22txklR5GNdrM2LxX6Avf8 Content-Type: multipart/mixed; boundary="812SkTxkTR5ENWbrCQ2Ts4c9xWklcPgUj"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla Cc: "Lubashev, Igor" , "jri@google.com" , "ietf@trammell.ch" , "quic@ietf.org" Message-ID: <6c9d2c13-8659-af90-a65a-8ebd5c75f24e@cisco.com> Subject: Re: Middlebox introspection/self-describing packets References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> In-Reply-To: --812SkTxkTR5ENWbrCQ2Ts4c9xWklcPgUj Content-Type: multipart/alternative; boundary="------------4F8CB8A98F24C595692AD92D" This is a multi-part message in MIME format. --------------4F8CB8A98F24C595692AD92D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/10/17 4:04 PM, Eric Rescorla wrote: > > Huh? The point here is that we shouldn't bake in assumptions that may > not be true in the > future and will have significantly negative consequences if they > become untrue. > The reverse is also true. Eliot --------------4F8CB8A98F24C595692AD92D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 3/10/17 4:04 PM, Eric Rescorla wrote:

Huh? The point here is that we shouldn't bake in assumptions that may not be true in the
future and will have significantly negative consequences if they become untrue.

The reverse is also true.

Eliot
--------------4F8CB8A98F24C595692AD92D-- --812SkTxkTR5ENWbrCQ2Ts4c9xWklcPgUj-- --lfv29nWWAeE22txklR5GNdrM2LxX6Avf8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwsTIAAoJEIe2a0bZ0nozAfoH/0cJQY8FglJpLjWmwfA77FBR uSQSIkQ/BlLcRh4NMfRzB8qjJ2aLH81ewbW3+LHyVs/pqum5zcM2YepedINV9MU6 ww/pOQy9r3BLcri0yGgfiTjU0bq+CUvtb775tyxVeZNUMu9JXTuvrjvcnM1wDXRT da7iQ/WrawcB5j7VY3qvFxipx+tVLYkSdZOapnaNV+Y9mIKdp/XpHc13k+GQc8zx WXhey9+HXyop9XEAshGFFzpfiUfi7nC6wtu7xXuwyaeoAX401MNW5d8byoxORkIQ 8twAZHKhsOHSwWXQlwiNbkh8iHDrtFtrUqO+nQjiK3Ewwo4LN57O3O8cMiDaUcE= =83Bw -----END PGP SIGNATURE----- --lfv29nWWAeE22txklR5GNdrM2LxX6Avf8-- From nobody Fri Mar 10 08:34:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6B712940A for ; Fri, 10 Mar 2017 08:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ocfNB28BuRZg for ; Fri, 10 Mar 2017 08:33:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93D128B38 for ; Fri, 10 Mar 2017 08:33:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id ECCA220000F; Fri, 10 Mar 2017 16:33:57 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id D5791200001; Fri, 10 Mar 2017 16:33:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489163637; bh=bzVCqyC+82u83YSerRVuYToeFrS/q19LXOv+J8swmVk=; l=17654; h=From:To:CC:Date:References:In-Reply-To:From; b=EP5NF1f3l14IY/ejeQxy4TqmK7vksfOKRTF1ku3HpG86t8SDUczqEfGPhvY+b6nDl txZ8DmXMCHqFNCQiG+KytQ6Ug0BNRmd3b8X6Ok4GkbrvSVeEuulWC51+6/9Wv9vQAu r0oPk31JmBl79Klg3P3D3m21hs/oZihW1d2OjCKA= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id A654998082; Fri, 10 Mar 2017 16:33:57 +0000 (GMT) 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.1178.4; Fri, 10 Mar 2017 11:33:57 -0500 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.1178.000; Fri, 10 Mar 2017 11:33:56 -0500 From: "Lubashev, Igor" To: Eliot Lear , Kyle Rose Subject: RE: Middlebox introspection/self-describing packets Thread-Topic: Middlebox introspection/self-describing packets Thread-Index: AQHSmFSC3N3Dd/ULcEG0HqoeLtLnu6GL3nwAgAAyiwCAAJYbgIAAN4KAgAAjfoCAABBvAIAABvaAgAAfnQCAAAKKgIAABKOAgABQSpaAAGCZgIAAZyCAgAAPogD//9jUAA== Date: Fri, 10 Mar 2017 16:33:56 +0000 Message-ID: <5adc5b17726a4ecbbfe20e37e4b84848@usma1ex-dag1mb5.msg.corp.akamai.com> References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.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.61] Content-Type: multipart/alternative; boundary="_000_5adc5b17726a4ecbbfe20e37e4b84848usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:34:00 -0000 --_000_5adc5b17726a4ecbbfe20e37e4b84848usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ubmVjdGVkIGNhcnMgd2FzIGp1c3QgdGhlIGZpcnN0IHRoaW5nIHRoYXQgY2FtZSB0byBtaW5k LiAgSSBkbyBub3Qgc2VlIHdoeSB0aGVzZSBjb3VsZCBub3QganVtcCB0byBXaUZpIHdoZW4gYXZh aWxhYmxlIChjYXJzIGFyZSBub3QgYWx3YXlzIHpvb21pbmcgYWxvbmcgYXQgaGlnaHdheSBzcGVl ZHMpLg0KDQpXaXRoIHNvbWUgbW9ybmluZyBjb2ZmZWUsIEkgY2FuIGFsc28gdGhpbmsgb2YgcGhv bmVzIHRldGhlcmluZyAob3ZlciBXaWZpLCBCbHVldG9vdGgvNkxvV1BBTiwgZXRjKSwgYSBteXJp YWQgb2YgY29ubmVjdGVkIHdlYXJhYmxlIGRldmljZXMgKHdhdGNoZXMsIFZSIGdsYXNzZXMsIGZp dG5lc3MgbW9uaXRvcnMsIHBvcnRhYmxlIEFWIHBsYXllcnMvcmVjb3JkZXJzLCBwYWNlbWFrZXJz 4oCUYmFkIGlkZWEhKS4NCg0KQmFzaWNhbGx5LCB0aGUgcG9pbnQgaXMgdGhhdCBmZXcgYXNzdW1w dGlvbnMgY2FuIGJlIG1hZGUgYWJvdXQgdGhlIHJlbGF0aXZlIHByZXZhbGVuY2Ugb2YgdGVjaG5v bG9naWVzIGluIHRoZSBsb25nIHRlcm0uICBGcm9tIGV4cGVyaWVuY2UsIHBlb3BsZSBnZW5lcmFs bHkgZ2V0IHRoaXMgdmVyeSB3cm9uZy4NCg0KDQotICAgICAgICAgIElnb3INCg0KDQpGcm9tOiBF bGlvdCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dDQpTZW50OiBGcmlkYXksIE1hcmNoIDEw LCAyMDE3IDg6MzAgQU0NClRvOiBLeWxlIFJvc2UgPGtyb3NlQGtyb3NlLm9yZz4NCkNjOiBMdWJh c2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IGVrckBydGZtLmNvbTsganJpQGdvb2ds ZS5jb207IGlldGZAdHJhbW1lbGwuY2g7IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBNaWRk bGVib3ggaW50cm9zcGVjdGlvbi9zZWxmLWRlc2NyaWJpbmcgcGFja2V0cw0KDQoNCg0KDQpPbiAz LzEwLzE3IDE6MzMgUE0sIEt5bGUgUm9zZSB3cm90ZToNCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0 IDE6MjQgQU0sIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNv bT4+IHdyb3RlOg0KT24gMy8xMC8xNyA2OjM5IEFNLCBMdWJhc2hldiwgSWdvciB3cm90ZToNCkkg d291bGQgbm90IGJlIGJhbmtpbmcgb24gdGV0aGVyaW5nIHJlbWFpbmluZyBhIGZyaW5nZSBhY3Rp dml0eS4gVGhpcyBtYXkgYmUgdHJ1ZSB0b2RheSwgYnV0IGl0IGlzIHJhcGlkbHkgY2hhbmdpbmcg d2l0aCBwcm9saWZlcmF0aW9uIG9mIGNvbm5lY3RlZCBjYXJzLCBidXNlcywgdHJhaW5zLCBhbmQg b3RoZXIgbW9iaWxlIGhvdHNwb3RzLiBBbmQgSSB3aWxsIG5vdCBldmVuIHZlbnR1cmUgYSBndWVz cyBhYm91dCB0ZWNobm9sb2dpZXMgYXZhaWxhYmxlIGluIDEwLTE1IHllYXJzLg0KDQpCdXQgeW91 IGNhbid0IGVuZ2luZWVyIGFyb3VuZCBzdWNoIHZhZ2FyaWVzLg0KDQpJIGRvbid0IHRoaW5rIHlv dSBjYW4gYXNzZXJ0IHRoYXQgZm9yIGFsbCBjYXNlcy4NCg0KSSB0aGluayB5b3UgbWF5IGJlIGFi bGUgdG8gY29uY2x1ZGUgc29tZSB2YXJpYW50IG9mIHRoYXQgc3RhdGVtZW50IGZvciBjbGFzc2Vz IG9mIHByb2JsZW1zIHJlcXVpcmluZyB0aGUgY2xpZW50IHRvIGtub3cgd2hlcmUgaXQgaXMgb24g dGhlIG5ldHdvcmsuIEUuZy4sIGJhc2luZyB0aGUgYW5zd2VyIHRvIHRoZSBzdGF0ZW1lbnQgInNo b3VsZCBteSBwb2RjYXN0IHBsYXllciBkb3dubG9hZCBhIDEwME1CIHBvZGNhc3Q/IiBvbiB3aGV0 aGVyIHRoZSBkZXZpY2UgaXMgY29ubmVjdGVkIHRvIHdpZmkgY2FuJ3QgdGFrZSBpbnRvIGFjY291 bnQgd2hldGhlciB3aWZpIGlzIHJlYWxseSBjZWxsIHRldGhlcmluZyB3aXRob3V0IGV4dHJhIHRl bGVtZXRyeS4NCkJ1dCB5b3UgY2FuIGNlcnRhaW5seSBkZWFsIHdpdGggbGlua2FiaWxpdHkgb2Yg Y2xpZW50cyBvYmxpdmlvdXNseSBjaGFuZ2luZyBuZXR3b3JrcyBpZiB5b3UncmUgd2lsbGluZyB0 byBhY2NlcHQgc29tZSB2YXJpYW50IG9mIG5ldmVyIHNlbmRpbmcgdGhlIHNhbWUgY29ubmVjdGlv biBJRCB0d2ljZS4gVGhlIHJlbWFpbmluZyBxdWVzdGlvbnMgYXJlIGFyb3VuZCB0aGUgY29zdHMg YW5kIHRyYWRlb2ZmcyBvZiBtZWNoYW5pc21zIHRvIGFjaGlldmUgdGhpcywgaW5jbHVkaW5nIHRo ZSBwZXJmZWN0bHkgbGVnaXRpbWF0ZSBxdWVzdGlvbiBvZiB3aGV0aGVyIGl0J3Mgd29ydGggYW55 IGFkZGVkIGNvbXBsZXhpdHkgYXQgYWxsLg0KDQpJZ29yIGRpZCBub3QgYXNzZXJ0IGhvdyB0aGUg YWJvdmUgdGVjaG5vbG9neSB3aWxsIG9wZXJhdGUuICBGb3IgM0cgbmV0d29ya3MsIHRoaXMgcHJv YmFibHkgbWF0dGVycyB2ZXJ5IGxpdHRsZSBpbiBwcmFjdGljZS4gIE9uIHRoZSBvdGhlciBzaWRl IG9mIHRoZSBzcGVjdHJ1bSAodGhvdWdoIG5vdCBsaXRlcmFsbHkpIHRoZXJlIHdpbGwgYmUgYWQg aG9jIG5ldHdvcmtzIHRoYXQgcm91dGUgb25seSBxdWl0ZSBsb2NhbGx5LiAgQW5kIHRoZW4gdGhl cmUgaXMgNmxvcGFuLiAgU3RhdGUgeW91ciBhc3N1bXB0aW9ucy4gIFRoZW4gZGVzaWduLg0KDQpF bGlvdA0K --_000_5adc5b17726a4ecbbfe20e37e4b84848usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5ob2VuemINCgl7bXNv LXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg1Mzc1Njc4OTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMxMTgzMDY2OCAtNTk2NzYyMTc2IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Q29ubmVjdGVkIGNhcnMg d2FzIGp1c3QgdGhlIGZpcnN0IHRoaW5nIHRoYXQgY2FtZSB0byBtaW5kLiZuYnNwOyBJIGRvIG5v dCBzZWUgd2h5IHRoZXNlIGNvdWxkIG5vdCBqdW1wIHRvIFdpRmkgd2hlbiBhdmFpbGFibGUgKGNh cnMgYXJlIG5vdCBhbHdheXMgem9vbWluZyBhbG9uZw0KIGF0IGhpZ2h3YXkgc3BlZWRzKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPldpdGggc29tZSBt b3JuaW5nIGNvZmZlZSwgSSBjYW4gYWxzbyB0aGluayBvZiBwaG9uZXMgdGV0aGVyaW5nIChvdmVy IFdpZmksIEJsdWV0b290aC82TG9XUEFOLCBldGMpLCBhIG15cmlhZCBvZiBjb25uZWN0ZWQgd2Vh cmFibGUgZGV2aWNlcyAod2F0Y2hlcywgVlIgZ2xhc3NlcywNCiBmaXRuZXNzIG1vbml0b3JzLCBw b3J0YWJsZSBBViBwbGF5ZXJzL3JlY29yZGVycywgcGFjZW1ha2Vyc+KAlGJhZCBpZGVhISkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5CYXNpY2FsbHks IHRoZSBwb2ludCBpcyB0aGF0IGZldyBhc3N1bXB0aW9ucyBjYW4gYmUgbWFkZSBhYm91dCB0aGUg cmVsYXRpdmUgcHJldmFsZW5jZSBvZiB0ZWNobm9sb2dpZXMgaW4gdGhlIGxvbmcgdGVybS4mbmJz cDsgRnJvbSBleHBlcmllbmNlLCBwZW9wbGUgZ2VuZXJhbGx5DQogZ2V0IHRoaXMgdmVyeSB3cm9u Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+SWdvcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiBFbGlvdCBM ZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBN YXJjaCAxMCwgMjAxNyA4OjMwIEFNPGJyPg0KPGI+VG86PC9iPiBLeWxlIFJvc2UgJmx0O2tyb3Nl QGtyb3NlLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNo ZUBha2FtYWkuY29tJmd0OzsgZWtyQHJ0Zm0uY29tOyBqcmlAZ29vZ2xlLmNvbTsgaWV0ZkB0cmFt bWVsbC5jaDsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogTWlkZGxlYm94 IGludHJvc3BlY3Rpb24vc2VsZi1kZXNjcmliaW5nIHBhY2tldHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMvMTAv MTcgMTozMyBQTSwgS3lsZSBSb3NlIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDEwLCAy MDE3IGF0IDE6MjQgQU0sIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAzLzEwLzE3IDY6MzkgQU0sIEx1YmFzaGV2LCBJZ29yIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB3b3Vs ZCBub3QgYmUgYmFua2luZyBvbiB0ZXRoZXJpbmcgcmVtYWluaW5nIGEgZnJpbmdlIGFjdGl2aXR5 LiBUaGlzIG1heSBiZSB0cnVlIHRvZGF5LCBidXQgaXQgaXMgcmFwaWRseSBjaGFuZ2luZyB3aXRo IHByb2xpZmVyYXRpb24gb2YgY29ubmVjdGVkIGNhcnMsIGJ1c2VzLCB0cmFpbnMsIGFuZA0KIG90 aGVyIG1vYmlsZSBob3RzcG90cy4gQW5kIEkgd2lsbCBub3QgZXZlbiB2ZW50dXJlIGEgZ3Vlc3Mg YWJvdXQgdGVjaG5vbG9naWVzIGF2YWlsYWJsZSBpbiAxMC0xNSB5ZWFycy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpCdXQg eW91IGNhbid0IGVuZ2luZWVyIGFyb3VuZCBzdWNoIHZhZ2FyaWVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv bid0IHRoaW5rIHlvdSBjYW4gYXNzZXJ0IHRoYXQgZm9yIGFsbCBjYXNlcy48YnI+DQo8YnI+DQpJ IHRoaW5rIHlvdSBtYXkgYmUgYWJsZSB0byBjb25jbHVkZSBzb21lIHZhcmlhbnQgb2YgdGhhdCBz dGF0ZW1lbnQgZm9yIGNsYXNzZXMgb2YgcHJvYmxlbXMgcmVxdWlyaW5nIHRoZSBjbGllbnQgdG8g a25vdyB3aGVyZSBpdCBpcyBvbiB0aGUgbmV0d29yay4gRS5nLiwgYmFzaW5nIHRoZSBhbnN3ZXIg dG8gdGhlIHN0YXRlbWVudCAmcXVvdDtzaG91bGQgbXkgcG9kY2FzdCBwbGF5ZXIgZG93bmxvYWQg YSAxMDBNQiBwb2RjYXN0PyZxdW90OyBvbiB3aGV0aGVyIHRoZQ0KIGRldmljZSBpcyBjb25uZWN0 ZWQgdG8gd2lmaSBjYW4ndCB0YWtlIGludG8gYWNjb3VudCB3aGV0aGVyIHdpZmkgaXMgcmVhbGx5 IGNlbGwgdGV0aGVyaW5nIHdpdGhvdXQgZXh0cmEgdGVsZW1ldHJ5LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgeW91IGNhbiBjZXJ0 YWlubHkgZGVhbCB3aXRoIGxpbmthYmlsaXR5IG9mIGNsaWVudHMgb2JsaXZpb3VzbHkgY2hhbmdp bmcgbmV0d29ya3MgaWYgeW91J3JlIHdpbGxpbmcgdG8gYWNjZXB0IHNvbWUgdmFyaWFudCBvZiBu ZXZlciBzZW5kaW5nIHRoZSBzYW1lIGNvbm5lY3Rpb24gSUQgdHdpY2UuIFRoZSByZW1haW5pbmcg cXVlc3Rpb25zIGFyZSBhcm91bmQgdGhlIGNvc3RzIGFuZCB0cmFkZW9mZnMgb2YgbWVjaGFuaXNt cw0KIHRvIGFjaGlldmUgdGhpcywgaW5jbHVkaW5nIHRoZSBwZXJmZWN0bHkgbGVnaXRpbWF0ZSBx dWVzdGlvbiBvZiB3aGV0aGVyIGl0J3Mgd29ydGggYW55IGFkZGVkIGNvbXBsZXhpdHkgYXQgYWxs LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJZ29yIGRpZCBub3QgYXNzZXJ0IGhv dyB0aGUgYWJvdmUgdGVjaG5vbG9neSB3aWxsIG9wZXJhdGUuJm5ic3A7IEZvciAzRyBuZXR3b3Jr cywgdGhpcyBwcm9iYWJseSBtYXR0ZXJzIHZlcnkgbGl0dGxlIGluIHByYWN0aWNlLiZuYnNwOyBP biB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgc3BlY3RydW0gKHRob3VnaCBub3QgbGl0ZXJhbGx5KSB0 aGVyZSB3aWxsIGJlIGFkIGhvYyBuZXR3b3JrcyB0aGF0IHJvdXRlIG9ubHkgcXVpdGUgbG9jYWxs eS4mbmJzcDsgQW5kIHRoZW4gdGhlcmUNCiBpcyA2bG9wYW4uJm5ic3A7IFN0YXRlIHlvdXIgYXNz dW1wdGlvbnMuJm5ic3A7IFRoZW4gZGVzaWduLjxicj4NCjxicj4NCkVsaW90PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5adc5b17726a4ecbbfe20e37e4b84848usma1exdag1mb5msgcorpak_-- From nobody Fri Mar 10 08:54:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A78F12967D for ; Fri, 10 Mar 2017 08:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 o3Iu_o4Nt285 for ; Fri, 10 Mar 2017 08:54:14 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B899912967A for ; Fri, 10 Mar 2017 08:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12228; q=dns/txt; s=iport; t=1489164853; x=1490374453; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=RSbb7zOKGeDIZKC9lE8ksaURgEBuLcprawpykarXI9M=; b=iJLUoLzVyu3bawoFo71c95O2hTZzhEPCANv4M2eZa9HzgeZ9AyxBSIEE Huv51dB1+LOEl0bE1TAaOAXwnXGIc/GRfGSKQHJ8Tl/U3gH6Bo5aHMIJD /wsD8I4Vjq4xd+ZCzmBGKEDqCx7YRfAQZFYR7osn07Tlhlx2tjsN+wU8u 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfBQDQ2MJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm6BboRAiwGQPh+QC4Utgg6GIgKDARcBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBIwpMBQsLGCoCAlcGAQwIAQEXiV0IsWuCJiuKPwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQ4PiFMIgVmBCYdagl8FnDyDeIIJjDeKUYZTk0AgATaBAyIWCBcVhxU?= =?us-ascii?q?/ik8BAQE?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="asc'?scan'208,217";a="653175590" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 16:54:11 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2AGsAR1031214; Fri, 10 Mar 2017 16:54:11 GMT Subject: Re: Middlebox introspection/self-describing packets To: "Lubashev, Igor" , Kyle Rose References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <5adc5b17726a4ecbbfe20e37e4b84848@usma1ex-dag1mb5.msg.corp.akamai.com> From: Eliot Lear Message-ID: <07846f0a-81ce-aff0-7856-7f8d58a7d5f0@cisco.com> Date: Fri, 10 Mar 2017 17:54:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5adc5b17726a4ecbbfe20e37e4b84848@usma1ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vI7CnevIfNvcsgvwpcCN9jwbTIi8E7FjD" Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:54:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vI7CnevIfNvcsgvwpcCN9jwbTIi8E7FjD Content-Type: multipart/mixed; boundary="WofVwoLH0PmPl482QkLlgrBU688njg6iU"; protected-headers="v1" From: Eliot Lear To: "Lubashev, Igor" , Kyle Rose Cc: "ekr@rtfm.com" , "jri@google.com" , "ietf@trammell.ch" , "quic@ietf.org" Message-ID: <07846f0a-81ce-aff0-7856-7f8d58a7d5f0@cisco.com> Subject: Re: Middlebox introspection/self-describing packets References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <5adc5b17726a4ecbbfe20e37e4b84848@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <5adc5b17726a4ecbbfe20e37e4b84848@usma1ex-dag1mb5.msg.corp.akamai.com> --WofVwoLH0PmPl482QkLlgrBU688njg6iU Content-Type: multipart/alternative; boundary="------------FCBA14E4F686D13CDC1CA2E3" This is a multi-part message in MIME format. --------------FCBA14E4F686D13CDC1CA2E3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/10/17 5:33 PM, Lubashev, Igor wrote: > > Connected cars was just the first thing that came to mind. I do not > see why these could not jump to WiFi when available (cars are not > always zooming along at highway speeds). > > =20 > They don't do that today (most that have connectivity have 3G). They MIGHT do that in the future (who knows?) but they might do something else (again, who knows?). > With some morning coffee, I can also think of phones tethering (over > Wifi, Bluetooth/6LoWPAN, etc), a myriad of connected wearable devices > (watches, VR glasses, fitness monitors, portable AV players/recorders, > pacemakers=E2=80=94bad idea!). > All of that is *possible*, I would grant you, and some if it will surely happen. The question it is necessary to engineer for that here, or whether some form of recovery is best handled at the application layer.=20 It's not like we haven't taken multiple swings at this exact same problem over the years (MIP, SCTP, etc), and yet nobody has wanted the complexity at layers below. > =20 > > Basically, the point is that few assumptions can be made about the > relative prevalence of technologies in the long term. From > experience, people generally get this very wrong. > And my point is that generality comes at a price. Future proofing too much can prevent you from getting past the present. That's why engineering towards solutions succeeds where architectural approaches have tended to fail. In this very organization. Eliot --------------FCBA14E4F686D13CDC1CA2E3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 3/10/17 5:33 PM, Lubashev, Igor wrote:

Connected cars was just the first thing that came to mind.=C2=A0 I do n= ot see why these could not jump to WiFi when available (cars are not always zooming along at highway speeds).

=C2=A0

They don't do that today (most that have connectivity have 3G).=C2=A0= They MIGHT do that in the future (who knows?) but they might do something else (again, who knows?).

With some morning coffee, I can also think of phones tethering (over Wifi, Bluetooth/6LoWPAN, etc), a myriad of connected wearable devices (watches, VR glasses, fitness monitors, portable AV players/recorders, pacemakers=E2=80=94bad idea!).=


All of that is *possible*, I would grant you, and some if it will surely happen.=C2=A0 The question it is necessary to engineer for tha= t here, or whether some form of recovery is best handled at the application layer.=C2=A0 It's not like we haven't taken multiple swin= gs at this exact same problem over the years (MIP, SCTP, etc), and yet nobody has wanted the complexity at layers below.

=C2=A0

Basically, the point is that few assumptions can be made about the relative prevalence of technologies in the long term.=C2=A0 F= rom experience, people generally get this very wrong.<= /span>


And my point is that generality comes at a price.=C2=A0 Future proofi= ng too much can prevent you from getting past the present.=C2=A0 That's = why engineering towards solutions succeeds where architectural approaches have tended to fail.=C2=A0 In this very organization.

Eliot
--------------FCBA14E4F686D13CDC1CA2E3-- --WofVwoLH0PmPl482QkLlgrBU688njg6iU-- --vI7CnevIfNvcsgvwpcCN9jwbTIi8E7FjD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwtoyAAoJEIe2a0bZ0nozh+8IALyXnJSiYq7TgUn1uPLqFuDy 7YP9Iwqa92IGtlHaqdgZHvd3MwFCPTw7PZ/DAixu7AJtat1BRPx9GDRQmRlXPNfs X+O9lfuUCeLjdaf0kF00tnPrRrZzJ3dAV5jZH9fNyUR0L5aUc99IiFZYHGGiBlN6 a7+GXwi45YcSYbspSZHFbjy5rsgzYI+G3GDSt1kF+2Lx9WYaqvw+R4e1qMjcfH2i fSb3WFioWI0nDQlAjSAgW3WoDwEOwyRYLwzpllrK+Y3GytQnWJ5prjtddne5WQL+ e1eEB5OrBuxYenFJSql0GNim0KWXj9G1Wn3yHjnXV35pro2ho82nSJQmkQPTAPw= =ITMi -----END PGP SIGNATURE----- --vI7CnevIfNvcsgvwpcCN9jwbTIi8E7FjD-- From nobody Fri Mar 10 09:08:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D798E129697 for ; Fri, 10 Mar 2017 09:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXenQ7Yi-ZoG for ; Fri, 10 Mar 2017 09:08:46 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8071294A9 for ; Fri, 10 Mar 2017 09:08:46 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id v125so173343495qkh.2 for ; Fri, 10 Mar 2017 09:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YakX+f486ocL9pbWv9vVbmcVVhQ70ILKMA85t934whs=; b=QmBkp1w/E9gjQ9WA1v+303jAfGSsy1iYqRoZ0m3hBrMfX1nWzyaIG/de87qG/eBYHr a3Bo1kjzcQDYEdW87YrdpR+XMoVq3q4VPsN8c9nrRbY/usSMoaa9KYxyKS8YE0Jrq8q/ kejSx/iZj5w6PFEffazSpBlQ2aLdRm7KqDJx8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YakX+f486ocL9pbWv9vVbmcVVhQ70ILKMA85t934whs=; b=Ey/xAEyLWsaHy026GGh5gWmRvVy2DRhDDBNMcn9XhYpd5Idvnwuj/8Tc0uBVVd10db +t5bg1o4CSvUUgYjMLGIsObq6QqtqysNYFAdQFIFuxNeAhzeuiEUSSUgqX0UcV/JeOOb sFsFM5xmwFedsGxSSv1FbjtaZjThlshlDvjUX3HD4eqdgyZsK9VpYE+RS5dW8/8xLj0c nFJ6e5O7Cp7K+3AIOEhvYdh8SzXNcfKuMvKwdc3r0i1drMR09ARhlDCvrP+yHE0+4kaf D5xB8EUAVX6gmBUFOcTCdzoNCQ1s6eZrUtAX97twG44g9ZiNNJ3I6MbsB+DNXEknYPrW IfUg== X-Gm-Message-State: AFeK/H2PaPMxsHMvZhPSBS1+WmZ8Qv4YAJAtndMUrXTnGmjLsvV6WxaSFcUBKEd3kTMTL8dnT5D4fJUFXzcmbg== X-Received: by 10.55.142.69 with SMTP id q66mr19724615qkd.13.1489165725126; Fri, 10 Mar 2017 09:08:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 10 Mar 2017 09:08:44 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Kyle Rose Date: Fri, 10 Mar 2017 12:08:44 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eliot Lear Content-Type: multipart/alternative; boundary=94eb2c083c7a0ef2de054a636a15 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:08:48 -0000 --94eb2c083c7a0ef2de054a636a15 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 8:29 AM, Eliot Lear wrote: > State your assumptions. Then design. > I think the key assumption from my perspective is that the protocol should expose to passive observers as little metadata that can be used to track the movements of users as possible while still keeping the network operable. So, for instance, is there a legitimate traffic management reason for a non-endpoint observer with tap points in different networks to be able to correlate different flows for the same connection? If the answer is "no" (and I would argue that it is), then the protocol would ideally not enable that. As I've argued many times, there is a limit to what we can do on the public internet as traffic analysis is very powerful; but I haven't yet seen the reduction that shows no possible benefit over simply putting a static connection ID in the clear in every packet. Kyle --94eb2c083c7a0ef2de054a636a15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 8:29 AM, Eliot Lear <lear@cisco.com> wrote:=
=20 =20 =20
State your assumptions.=C2=A0 Then design.

I th= ink the key assumption from my perspective is that the protocol should expo= se to passive observers as little metadata that can be used to track the mo= vements of users as possible while still keeping the network operable. So, = for instance, is there a legitimate traffic management reason for a non-end= point observer with tap points in different networks to be able to correlat= e different flows for the same connection? If the answer is "no" = (and I would argue that it is), then the protocol would ideally not enable = that.

As I've argued many times, there is a limit to what we can= do on the public internet as traffic analysis is very powerful; but I have= n't yet seen the reduction that shows no possible benefit over simply p= utting a static connection ID in the clear in every packet.

Kyle

--94eb2c083c7a0ef2de054a636a15-- From nobody Fri Mar 10 09:12:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DCA12969D for ; Fri, 10 Mar 2017 09:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 zXSzb5wn3pJk for ; Fri, 10 Mar 2017 09:12:31 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5118129697 for ; Fri, 10 Mar 2017 09:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6171; q=dns/txt; s=iport; t=1489165950; x=1490375550; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=wljI0JJ+NBvFc9k9ZN3t8yQHJUeZrHtdSUrBmO//aps=; b=XMUMiq2tpFvP5U+MYiaBYhwgozuFstkylnBQgOZei5pj2NnFQ690J3iI ccheNUuYNHAYhXghm/dyLLvDxgxCWeDmJTOxrolrc1ymCJpDz7A93Cf4p /fjjPaZaNN8YH0RSWCcsa5vwy1KIOri2eJae5FeXYTz/Zlp5cOXuQafH/ A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAgCK3cJY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyeBNWCDYIoOc5A+H5ALhS2CDoYiAoMAGAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBSNWEAsECgonAwICRhEGDQYCAQGJfLF0giYrij8BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEOD4hTCIJih1qCXwWcPIN4ggmMN4pRhlOTQB84gQMiFggXFYcVPzWKGgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="asc'?scan'208,217";a="653176018" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 17:12:28 +0000 Received: from [10.61.97.155] (dhcp-10-61-97-155.cisco.com [10.61.97.155]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2AHCSZQ017234; Fri, 10 Mar 2017 17:12:28 GMT Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: Eliot Lear Message-ID: <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> Date: Fri, 10 Mar 2017 18:12:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Cxs3MKLfiet1Gd16r4LtAhQvIw1TaGWwG" Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:12:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cxs3MKLfiet1Gd16r4LtAhQvIw1TaGWwG Content-Type: multipart/mixed; boundary="72FsFVqIPIw1hUtEEDaud7LPRj2pcBjhi"; protected-headers="v1" From: Eliot Lear To: Kyle Rose Cc: "Lubashev, Igor" , "ekr@rtfm.com" , "jri@google.com" , "ietf@trammell.ch" , "quic@ietf.org" Message-ID: <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> Subject: Re: Middlebox introspection/self-describing packets References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> In-Reply-To: --72FsFVqIPIw1hUtEEDaud7LPRj2pcBjhi Content-Type: multipart/alternative; boundary="------------1CDA78BB20940803B8331AA0" This is a multi-part message in MIME format. --------------1CDA78BB20940803B8331AA0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kyle: On 3/10/17 6:08 PM, Kyle Rose wrote: > On Fri, Mar 10, 2017 at 8:29 AM, Eliot Lear > wrote: > > State your assumptions. Then design. > > > I think the key assumption from my perspective is that the protocol > should expose to passive observers as little metadata that can be used > to track the movements of users as possible while still keeping the > network operable. That's a goal, not an assumption. The assumptions have to do with what environment this protocol will operate in over some period of time. I'm not arguing the goal mind you, and I'm not landing a view as to what the right answer here is to EKR's Q. But see my other message to Igor. You can engineer for worlds that will never exist or corner cases that will make your protocol complex to operate in. Or you could too narrowly engineer. Or maybe something in between. Choose wisely. Eliot --------------1CDA78BB20940803B8331AA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Kyle:


On 3/10/17 6:08 PM, Kyle Rose wrote:
On Fri, Mar 10, 2017 at 8:29 AM, Eliot Lear <lear@cis= co.com> wrote:
= State your assumptions.=C2=A0 Then design.

I think the key assumption from my perspective is that the protocol should expose to passive observers as little metadata that can be used to track the movements of users as possible while still keeping the network operable.
=

That's a goal, not an assumption.=C2=A0 The assumptions have to do wi= th what environment this protocol will operate in over some period of time.=C2=A0 I'm not arguing the goal mind you, and I'm not landing a = view as to what the right answer here is to EKR's Q.=C2=A0 But see my othe= r message to Igor.=C2=A0 You can engineer for worlds that will never ex= ist or corner cases that will make your protocol complex to operate in.=C2= =A0 Or you could too narrowly engineer.=C2=A0 Or maybe something in betwe= en.=C2=A0 Choose wisely.

Eliot

--------------1CDA78BB20940803B8331AA0-- --72FsFVqIPIw1hUtEEDaud7LPRj2pcBjhi-- --Cxs3MKLfiet1Gd16r4LtAhQvIw1TaGWwG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYwt58AAoJEIe2a0bZ0nozFJYH/1x3jbmULrtNzxXsFlarXukf UcF+O9DSVD0Q/zGaFwwturL3Rr/GMhKz5/pdUKq+QRmPEIBnpzrVh2wcs+llKdwC n/pngUmO+uKb5D2I8SRY8TU+qM24jxYyRPceBY18PbBMzbaOd+5hZFTxV0H3bnUG XuFZdRkIZhTBw3y60B9e6l9h2NohNL+GqAK4HrASqRYWbdnXPvsuCA5qhRKvgBww oUy2ZNlnV9tPCqPiP9seHe+X9fE1452lQVF7YxPbtmS4CrGNvULBK/BS9Nt04dla LL29YCYZ+m9qDyE+VJZNbaRjjNhBvkCepmGYu0sLw7/nc821gnx8K9sssMDIIPM= =1cs4 -----END PGP SIGNATURE----- --Cxs3MKLfiet1Gd16r4LtAhQvIw1TaGWwG-- From nobody Fri Mar 10 09:20:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312D9129987 for ; Fri, 10 Mar 2017 09:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PYv9DrFy4dN for ; Fri, 10 Mar 2017 09:20:17 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0136.outbound.protection.outlook.com [104.47.34.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C3312998E for ; Fri, 10 Mar 2017 09:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S/ZMjnJ0QpS1SCyb5iIywlbV+LJIUuQiQG+27DnlHUA=; b=GySdf540Cotr6vVa3ZRVt5LNScXnlBuraHVGarXMcCmZSgtF3rf8fnZqiQ5/xAwvnzptFyfzs9qywy3d3ge34RXFWsTbifU0EN/FBM+igS2ExW3If4JIj5AkUquOnpnarZ8GmPESCBvLLvwDWvMq87dnlG91UoDIluYWUYPIPBs= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Fri, 10 Mar 2017 17:20:15 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Fri, 10 Mar 2017 17:20:14 +0000 From: Mike Bishop To: Eric Rescorla Subject: RE: HTTP/QUIC Diverging from HTTP/2 Thread-Topic: HTTP/QUIC Diverging from HTTP/2 Thread-Index: AdKZAt9YNciLyZHpRWy2RhBs+G6fSwAMq+0wAAQX2wAAHwff0A== Date: Fri, 10 Mar 2017 17:20:14 +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: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.58.46.150] x-ms-office365-filtering-correlation-id: 6ba72b1c-dd47-4d71-b1e6-08d467d9b779 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:bsT1qra8JA2OJc2sY66jgyUNXa82gepdZQw6cK/CnenNl1l1zyke+2JM4wGw/DRPt2xyJ6hb8bXOHbCY7AAlyIEAVA+sBo+1T3BIdhCX4xgM2aeMKNpitjdvfO43kMPkOyIhEWWHwrVQ9W/No5pYjIwgGxWi2krZxsAohBwZxDhhNHKpUw9LC+dfC8V8DkEpSANqY8bki55IzYK/dMiemBxRZSvEtuV75le/NFS0MsuB5lJ/kFEVBKyauMkdboS/7w2QRh/eOyNHP6Vp+Joq0h9lxJ1O+sDnp/+uOUSIoUMR8+R25fmC+/e1wPgUFU+WZBhDwoyfMAsjoHMv8t9n7XLGZwRTXMGldYA0pR+KekU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 02426D11FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(51444003)(24454002)(377454003)(5005710100001)(9686003)(7696004)(54896002)(236005)(229853002)(81166006)(38730400002)(25786008)(790700001)(6116002)(110136004)(3660700001)(3846002)(102836003)(77096006)(86612001)(122556002)(606005)(6436002)(53546006)(86362001)(33656002)(6506006)(7736002)(6246003)(6306002)(10290500002)(5660300001)(74316002)(55016002)(8676002)(3280700002)(54906002)(7906003)(53936002)(99286003)(54356999)(2950100002)(2906002)(50986999)(19609705001)(4326008)(76176999)(8936002)(2900100001)(6916009)(10090500001)(66066001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708EFFD08761620114B066687200BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2017 17:20:14.8290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Cc: "quic@ietf.org" , HTTP working group mailing list X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:20:19 -0000 --_000_BN6PR03MB2708EFFD08761620114B066687200BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gZmluZSBob2xkaW5nIG9mZiBvbiB0aGUgc2Vjb25kIFBSIHRoYXQgYWN0dWFsbHkgZG9l cyB0aGUgc3BsaXQsIGlmIHlvdSB3YW50LiAgVGhlIGZpcnN0IFBSIHJlc29sdmVzIGFuIGlzc3Vl IChuZWVkIGFkdmljZSBvbiBtYXBwaW5nIEhUVFAvMiBleHRlbnNpb25zKSBhbmQgaXMgbW9zdGx5 IGVkaXRvcmlhbCBiZXlvbmQgdGhhdCwgc28gSeKAmW0gcGxhbm5pbmcgdG8gbWVyZ2UgdGhhdCBv bmUgdW5sZXNzIHlvdSBvYmplY3Qgc3BlY2lmaWNhbGx5IHRvIGl0Lg0KDQpGcm9tOiBFcmljIFJl c2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDksIDIw MTcgNjoyOCBQTQ0KVG86IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IEhUVFAgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgPGll dGYtaHR0cC13Z0B3My5vcmc+DQpTdWJqZWN0OiBSZTogSFRUUC9RVUlDIERpdmVyZ2luZyBmcm9t IEhUVFAvMg0KDQoNCk9uIFRodSwgTWFyIDksIDIwMTcgYXQgNjowOSBQTSwgTWlrZSBCaXNob3Ag PE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20+PiB3cm90ZToNClN1bW1hcnkgb2YgZmVlZGJhY2sgb24gdGhpcyBzbyBmYXI6DQoN CiAgKiAgIEVrcjogIOKAnEhvcGluZyB3ZSBjYW4gY29udmVyZ2UsIG9yIGF0IGxlYXN0IG1heGlt aXplIG92ZXJsYXDigJ0NCiAgKiAgIFN0ZWZhbjogIOKAnGFueSBob3BlIHRvIFtjb252ZXJnZV0g bmVlZHMgdG8gYmUgYWJhbmRvbmVk4oCdDQogICogICBJYW46ICDigJxub3QgZXhjaXRlZOKApiBi dXQgaXQgbWF54oCmIGJlIHRoZSByaWdodCB0aGluZyB0byBkb+KAnQ0KICAqICAgUGF0cmljazog IOKAnHNlcGFyYXRlIHByb3RvY29sc+KAnQ0KICAqICAgTWFydGluOiAg4oCca2VlcCB0aGUgZGlm ZmVyZW5jZXMgbWluaW1hbOKAnSBidXQg4oCcd2UncmUgcmVhbGx5IGJ1aWxkaW5nIGEgbmV3IHBy b3RvY29s4oCdDQogICogICBBbGNpZGVzOiAgaWYgaXTigJlzIGRpZmZlcmVudCwgbWFrZSB0aGUg ZGlmZmVyZW5jZXMgY2xlYXINCg0KSWYgSeKAmXZlIG1pc2NvbnN0cnVlZCBhbnlvbmXigJlzIHJl c3BvbnNlLCBwbGVhc2Ugc3BlYWsgbm93OyBhbmQgb2J2aW91c2x5LCBtb3JlIG9waW5pb25zIGFy ZSB3ZWxjb21lLiAgSSB3b3VsZCBhbHNvIGFwcHJlY2lhdGUgcmV2aWV3cyBvbiB0aGUgdGV4dCBv ZiB0aGUgUFJzIHRoZW1zZWx2ZXMuDQoNClVubGVzcyB0aGVyZeKAmXMgc3Ryb25nIHB1c2hiYWNr IGluIHRoZSBuZXh0IH4xNCBob3VycywgSSBleHBlY3QgdG8gaW5jb3Jwb3JhdGUgYm90aCBQUnMg dG9tb3Jyb3csIHByaW9yIHRvIHRoZSAtMDIgcHVibGljYXRpb24uICBBcyBNYXJrIG5vdGVkIHJl Y2VudGx5LCB0aGF0IGRvZXNu4oCZdCBjbGFpbSBmdWxsIGNvbnNlbnN1cyBoYXMgYmVlbiByZWFj aGVkLCBidXQgdGhlcmUgYXBwZWFycyB0byBiZSBnZW5lcmFsIHN1cHBvcnQgZm9yIGNvbnNpZGVy aW5nIHRoZXNlIHNlcGFyYXRlIHByb3RvY29scyB3aGljaCBhcmUgY2xvc2VseSByZWxhdGVkLCBy YXRoZXIgdGhhbiB0d28gdmFyaWFudHMgb2YgYSBzaW5nbGUgcHJvdG9jb2wuDQoNCg0KVGhpcyBz ZWVtcyBsaWtlIHByZXR0eSB3ZWFrIGNvbnNlbnN1cywgc28gSSdkIHByZWZlciB3ZSBkaXNjdXNz IHRoaXMgaW4gT1JEIHJhdGhlciB0aGFuDQpoYXZpbmcgeW91IG1lcmdlIHRoaXMgbm93Lg0KDQot RWtyDQoNCkZyb206IE1pa2UgQmlzaG9wDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyAx MDo1NCBBTQ0KVG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBIVFRQIHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IDxpZXRmLWh0dHAtd2dAdzMub3JnPG1haWx0bzppZXRm LWh0dHAtd2dAdzMub3JnPj4NClN1YmplY3Q6IEhUVFAvUVVJQyBEaXZlcmdpbmcgZnJvbSBIVFRQ LzINCg0KQXQgUGF0cmlja+KAmXMgc3VnZ2VzdGlvbiwgSeKAmW0gcmVzdGF0aW5nIHRoaXMgcXVl c3Rpb24gYW5kIGFkZHJlc3NpbmcgaXQgdG8gYm90aCB0aGUgSFRUUCBhbmQgUVVJQyB3b3JraW5n IGdyb3Vwcy4gIEFwb2xvZ2llcyBpZiB5b3XigJlyZSBhbHJlYWR5IGZvbGxvd2luZyBhbG9uZyBp biBRVUlDIGFuZCBnZXQgdGhpcyB0d2ljZSBhZnRlciBoYXZpbmcgYWxyZWFkeSBzZWVuIGl0IHRo ZSBmaXJzdCB0aW1lLg0KDQpIVFRQL1FVSUMgc3RhcnRlZCBvZmYgKGRyYWZ0IC0wMCkgd2l0aCBh IG1vc3RseS1jb21wbGV0ZSBIVFRQLzIgc2Vzc2lvbiBvbiBRVUlDIFN0cmVhbSAzLCBpbmNsdWRp bmcgYSBmdWxsIEhUVFAvMiBtdWx0aXBsZXhpbmcgbGF5ZXIgd2l0aGluIFN0cmVhbSAzLiAgQSBu dW1iZXIgb2YgSFRUUC8yIGZyYW1lcyB3ZXJlbuKAmXQgbmVjZXNzYXJ5LCBzaW5jZSB0aGV5IHdl cmUgZHVwbGljYXRpdmUgb2Ygc2VydmljZXMgUVVJQyBwcm92aWRlcy4gIEluIGRyYWZ0IC0wMSwg d2UgcmVtb3ZlZCB0aGUgZnVsbCBtdXggbGF5ZXIgZnJvbSBTdHJlYW0gMywgaW5zdGVhZCBsZXR0 aW5nIFFVSUMgZGVhbCB3aXRoIGFsbCB0aGUgc3RyZWFtIG1hbmFnZW1lbnQuICBUaGlzIG5lY2Vz c2l0YXRlZCBjaGFuZ2VzIHRvIHNldmVyYWwgb2YgdGhlIHJlbWFpbmluZyBmcmFtZXMuICBCeSB0 aGUgY3VycmVudCBlZGl0b3LigJlzIGNvcHksIG5vIEhUVFAvMiBmcmFtZSBleGlzdHMgdW5tb2Rp ZmllZCBpbiBIVFRQL1FVSUMsIHRob3VnaCBzZXZlcmFsIGZyYW1lcyBvZiB0aGUgc2FtZSBuYW1l IGFuZCBwdXJwb3NlIGV4aXN0LiAgTGlrZXdpc2UsIFJGQzc1NDAgZGVmaW5lcyBzaXggc2V0dGlu Z3MsIHRocmVlIG9mIHdoaWNoIGFyZSBpbmFwcGxpY2FibGUgaW4gSFRUUC9RVUlDLg0KDQpIb3dl dmVyLCB0aGUgZHJhZnQgY3VycmVudGx5IHN0aWxsIGF0dGVtcHRzIHRvIGRlZmluZSB0aGVtIGFz IGNsb3NlIGNvdXNpbnMuICBJdCB1cGRhdGVzIHRoZSBIVFRQLzIgZnJhbWUgYW5kIHNldHRpbmcg cmVnaXN0cmllcyB3aXRoIGFkZGl0aW9uYWwgY29sdW1ucyAoSFRUUC8yLCBIVFRQL1FVSUMsIG9y IEJvdGg/OyBIVFRQL1FVSUMgU3BlY2lmaWNhdGlvbiBpZiBhcHBsaWNhYmxlKSBhbmQgYXR0ZW1w dHMgdG8gY29leGlzdCB3aXRoIEhUVFAvMiBpbiB0aGUgc2FtZSByZWdpc3RyeS4gIChRVUlDIGRl ZmluZXMgYSB1bmlmaWVkIGVycm9yIHNwYWNlLCB3aGljaCBtZWFucyBhIHNlcGFyYXRlIHJlZ2lz dHJ5IG9mIGVycm9yIGNvZGVzIGZvciBIVFRQL1FVSUMgcmVnYXJkbGVzcy4pDQoNCkluIFBSICMz NjM8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM2Mz4sIEnigJl2 ZSBjb25zb2xpZGF0ZWQgYWxtb3N0IGFsbCBvZiB0aGUg4oCcZGlmZmVyZW50IGZyb20gSFRUUC8y 4oCdIHRleHQgaW50byBhIG5ldyB0b3AtbGV2ZWwgc2VjdGlvbiBhbmQgZXhjaXNlZCBhIGxvdCBv ZiDigJxIVFRQLzIgaGFzIHRoaXMsIGJ1dCBIVFRQL1FVSUMgZG9lc27igJl0IG5lZWQgaXTigJ0g dGV4dCBmcm9tIHRoZSBtYWluIGJvZHkgb2YgdGhlIGRvY3VtZW50LiAgTWFydGluIGhhcyBhZHZv Y2F0ZWQgbWFraW5nIGEgY2xlYW4gYnJlYWsgZnJvbSBIVFRQLzIgYW5kIGRlZmluaW5nIG91ciBv d24gSUFOQSByZWdpc3RyeSBmb3IgZnJhbWUgdHlwZXMgYW5kIHNldHRpbmdzLCBqdXN0IGFzIHdl IGFscmVhZHkgaGF2ZSBmb3IgZXJyb3JzLiAgV2UgY2FuLCBvdXQgb2YgcmVzcGVjdCBmb3Igb3Vy IGNvdXNpbiwgdXNlIHRoZSBzYW1lIHZhbHVlcyB3aGVyZSBhcHByb3ByaWF0ZSBhbmQgcmVzZXJ2 ZSBleGlzdGluZyB2YWx1ZXMgY3VycmVudGx5IGluIHVzZSBvbiB0aGUgSFRUUC8yIHNpZGUuDQoN CkkgdGhpbmsgdGhhdOKAmXMgYSBnb29kIGlkZWEsIGFuZCBpdOKAmXMgYSBmYWlybHkgc21hbGwg c3RlcCBmcm9tIHRoZSBjdXJyZW50IHN0YXRlIG9mICMzNjMuICBJ4oCZdmUgY3JlYXRlZCBQUiAj Mzc2PGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNzY+IHRvIGFj dHVhbGx5IG1ha2UgdGhhdCBzcGxpdC4NCg0KQ29tbWVudHMgZnJvbSBib3RoIFdHcyBhYm91dCB0 aGUgdHdvIFBScyB3b3VsZCBiZSB3ZWxjb21lLiAgKEZlZWRiYWNrIHNvIGZhciBmcm9tIHRoZSBR VUlDIHNpZGUgc2VlbXMgdG8gbW9zdGx5IGJlIOKAnHNlcGFyYXRlIHdpdGggcmVncmV0cyzigJ0g YnV0IG5vdCB1bml2ZXJzYWxseS4pDQoNCg== --_000_BN6PR03MB2708EFFD08761620114B066687200BN6PR03MB2708namp_ 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 O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI5NDQx MDg4MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg5MzcxNjExNDt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBmaW5lIGhv bGRpbmcgb2ZmIG9uIHRoZSBzZWNvbmQgUFIgdGhhdCBhY3R1YWxseSBkb2VzIHRoZSBzcGxpdCwg aWYgeW91IHdhbnQuJm5ic3A7IFRoZSBmaXJzdCBQUiByZXNvbHZlcyBhbiBpc3N1ZSAobmVlZCBh ZHZpY2Ugb24gbWFwcGluZyBIVFRQLzIgZXh0ZW5zaW9ucykgYW5kIGlzIG1vc3RseSBlZGl0b3Jp YWwgYmV5b25kIHRoYXQsIHNvIEnigJltIHBsYW5uaW5nIHRvIG1lcmdlIHRoYXQgb25lIHVubGVz cyB5b3UNCiBvYmplY3Qgc3BlY2lmaWNhbGx5IHRvIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpw PjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9z cGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVyaWMgUmVzY29ybGEgW21h aWx0bzpla3JAcnRmbS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggOSwg MjAxNyA2OjI4IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc7IEhUVFAg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgJmx0O2lldGYtaHR0cC13Z0B3My5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBIVFRQL1FVSUMgRGl2ZXJnaW5nIGZyb20gSFRUUC8yPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgOSwgMjAxNyBhdCA2OjA5 IFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlN1bW1hcnkgb2YgZmVlZGJhY2sgb24gdGhpcyBzbyBmYXI6 PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpFa3I6Jm5ic3A7IOKA nEhvcGluZyB3ZSBjYW4gY29udmVyZ2UsIG9yIGF0IGxlYXN0IG1heGltaXplIG92ZXJsYXDigJ08 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KU3RlZmFuOiZuYnNwOyDigJxhbnkgaG9wZSB0byBbY29u dmVyZ2VdIG5lZWRzIHRvIGJlIGFiYW5kb25lZOKAnTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJ YW46Jm5ic3A7IOKAnG5vdCBleGNpdGVk4oCmIGJ1dCBpdCBtYXnigKYgYmUgdGhlIHJpZ2h0IHRo aW5nIHRvIGRv4oCdPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClBhdHJpY2s6Jm5ic3A7IOKAnHNl cGFyYXRlIHByb3RvY29sc+KAnTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpNYXJ0aW46Jm5ic3A7 IOKAnGtlZXAgdGhlIGRpZmZlcmVuY2VzIG1pbmltYWzigJ0gYnV0IOKAnHdlJ3JlIHJlYWxseSBi dWlsZGluZyBhIG5ldyBwcm90b2NvbOKAnTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpBbGNpZGVz OiZuYnNwOyBpZiBpdOKAmXMgZGlmZmVyZW50LCBtYWtlIHRoZSBkaWZmZXJlbmNlcyBjbGVhcjxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgSeKAmXZlIG1pc2NvbnN0cnVlZCBh bnlvbmXigJlzIHJlc3BvbnNlLCBwbGVhc2Ugc3BlYWsgbm93OyBhbmQgb2J2aW91c2x5LCBtb3Jl IG9waW5pb25zIGFyZSB3ZWxjb21lLiZuYnNwOyBJIHdvdWxkIGFsc28gYXBwcmVjaWF0ZSByZXZp ZXdzIG9uIHRoZSB0ZXh0IG9mIHRoZSBQUnMgdGhlbXNlbHZlcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlVubGVzcyB0aGVyZeKAmXMgc3Ryb25nIHB1c2hiYWNrIGluIHRoZSBuZXh0IH4x NCBob3VycywgSSBleHBlY3QgdG8gaW5jb3Jwb3JhdGUgYm90aCBQUnMgdG9tb3Jyb3csIHByaW9y IHRvIHRoZSAtMDIgcHVibGljYXRpb24uJm5ic3A7IEFzIE1hcmsgbm90ZWQgcmVjZW50bHksIHRo YXQgZG9lc27igJl0IGNsYWltIGZ1bGwgY29uc2Vuc3VzDQogaGFzIGJlZW4gcmVhY2hlZCwgYnV0 IHRoZXJlIGFwcGVhcnMgdG8gYmUgZ2VuZXJhbCBzdXBwb3J0IGZvciBjb25zaWRlcmluZyB0aGVz ZSBzZXBhcmF0ZSBwcm90b2NvbHMgd2hpY2ggYXJlIGNsb3NlbHkgcmVsYXRlZCwgcmF0aGVyIHRo YW4gdHdvIHZhcmlhbnRzIG9mIGEgc2luZ2xlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNlZW1z IGxpa2UgcHJldHR5IHdlYWsgY29uc2Vuc3VzLCBzbyBJJ2QgcHJlZmVyIHdlIGRpc2N1c3MgdGhp cyBpbiBPUkQgcmF0aGVyIHRoYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmhhdmluZyB5b3UgbWVyZ2UgdGhpcyBub3cuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gTWlr ZSBCaXNob3ANCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggOSwgMjAxNyAxMDo1 NCBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjsgSFRUUCB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtaHR0cC13Z0B3My5vcmciIHRhcmdldD0iX2Js YW5rIj5pZXRmLWh0dHAtd2dAdzMub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSFRU UC9RVUlDIERpdmVyZ2luZyBmcm9tIEhUVFAvMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgUGF0cmlja+KAmXMgc3VnZ2VzdGlvbiwg SeKAmW0gcmVzdGF0aW5nIHRoaXMgcXVlc3Rpb24gYW5kIGFkZHJlc3NpbmcgaXQgdG8gYm90aCB0 aGUgSFRUUCBhbmQgUVVJQyB3b3JraW5nIGdyb3Vwcy4mbmJzcDsgQXBvbG9naWVzIGlmIHlvdeKA mXJlIGFscmVhZHkgZm9sbG93aW5nIGFsb25nIGluIFFVSUMgYW5kIGdldCB0aGlzDQogdHdpY2Ug YWZ0ZXIgaGF2aW5nIGFscmVhZHkgc2VlbiBpdCB0aGUgZmlyc3QgdGltZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhUVFAvUVVJQyBzdGFydGVkIG9mZiAoZHJhZnQgLTAwKSB3aXRoIGEg bW9zdGx5LWNvbXBsZXRlIEhUVFAvMiBzZXNzaW9uIG9uIFFVSUMgU3RyZWFtIDMsIGluY2x1ZGlu ZyBhIGZ1bGwgSFRUUC8yIG11bHRpcGxleGluZyBsYXllciB3aXRoaW4gU3RyZWFtIDMuJm5ic3A7 IEEgbnVtYmVyIG9mIEhUVFAvMiBmcmFtZXMNCiB3ZXJlbuKAmXQgbmVjZXNzYXJ5LCBzaW5jZSB0 aGV5IHdlcmUgZHVwbGljYXRpdmUgb2Ygc2VydmljZXMgUVVJQyBwcm92aWRlcy4mbmJzcDsgSW4g ZHJhZnQgLTAxLCB3ZSByZW1vdmVkIHRoZSBmdWxsIG11eCBsYXllciBmcm9tIFN0cmVhbSAzLCBp bnN0ZWFkIGxldHRpbmcgUVVJQyBkZWFsIHdpdGggYWxsIHRoZSBzdHJlYW0gbWFuYWdlbWVudC4m bmJzcDsgVGhpcyBuZWNlc3NpdGF0ZWQgY2hhbmdlcyB0byBzZXZlcmFsIG9mIHRoZSByZW1haW5p bmcgZnJhbWVzLiZuYnNwOw0KIEJ5IHRoZSBjdXJyZW50IGVkaXRvcuKAmXMgY29weSwgPGk+bm88 L2k+IEhUVFAvMiBmcmFtZSBleGlzdHMgdW5tb2RpZmllZCBpbiBIVFRQL1FVSUMsIHRob3VnaCBz ZXZlcmFsIGZyYW1lcyBvZiB0aGUgc2FtZSBuYW1lIGFuZCBwdXJwb3NlIGV4aXN0LiZuYnNwOyBM aWtld2lzZSwgUkZDNzU0MCBkZWZpbmVzIHNpeCBzZXR0aW5ncywgdGhyZWUgb2Ygd2hpY2ggYXJl IGluYXBwbGljYWJsZSBpbiBIVFRQL1FVSUMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I b3dldmVyLCB0aGUgZHJhZnQgY3VycmVudGx5IHN0aWxsIGF0dGVtcHRzIHRvIGRlZmluZSB0aGVt IGFzIGNsb3NlIGNvdXNpbnMuJm5ic3A7IEl0IHVwZGF0ZXMgdGhlIEhUVFAvMiBmcmFtZSBhbmQg c2V0dGluZyByZWdpc3RyaWVzIHdpdGggYWRkaXRpb25hbCBjb2x1bW5zIChIVFRQLzIsIEhUVFAv UVVJQywgb3IgQm90aD87DQogSFRUUC9RVUlDIFNwZWNpZmljYXRpb24gaWYgYXBwbGljYWJsZSkg YW5kIGF0dGVtcHRzIHRvIGNvZXhpc3Qgd2l0aCBIVFRQLzIgaW4gdGhlIHNhbWUgcmVnaXN0cnku Jm5ic3A7IChRVUlDIGRlZmluZXMgYSB1bmlmaWVkIGVycm9yIHNwYWNlLCB3aGljaCBtZWFucyBh IHNlcGFyYXRlIHJlZ2lzdHJ5IG9mIGVycm9yIGNvZGVzIGZvciBIVFRQL1FVSUMgcmVnYXJkbGVz cy4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Jbg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRo dWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM2MyIgdGFyZ2V0PSJfYmxhbmsiPlBSICMz NjM8L2E+LCBJ4oCZdmUgY29uc29saWRhdGVkIGFsbW9zdCBhbGwgb2YgdGhlIOKAnGRpZmZlcmVu dCBmcm9tIEhUVFAvMuKAnSB0ZXh0IGludG8gYSBuZXcgdG9wLWxldmVsIHNlY3Rpb24gYW5kIGV4 Y2lzZWQgYSBsb3Qgb2Yg4oCcSFRUUC8yIGhhcyB0aGlzLCBidXQgSFRUUC9RVUlDIGRvZXNu4oCZ dCBuZWVkIGl04oCdIHRleHQgZnJvbQ0KIHRoZSBtYWluIGJvZHkgb2YgdGhlIGRvY3VtZW50LiZu YnNwOyBNYXJ0aW4gaGFzIGFkdm9jYXRlZCBtYWtpbmcgYSBjbGVhbiBicmVhayBmcm9tIEhUVFAv MiBhbmQgZGVmaW5pbmcgb3VyIG93biBJQU5BIHJlZ2lzdHJ5IGZvciBmcmFtZSB0eXBlcyBhbmQg c2V0dGluZ3MsIGp1c3QgYXMgd2UgYWxyZWFkeSBoYXZlIGZvciBlcnJvcnMuJm5ic3A7IFdlIGNh biwgb3V0IG9mIHJlc3BlY3QgZm9yIG91ciBjb3VzaW4sIHVzZSB0aGUgc2FtZSB2YWx1ZXMgd2hl cmUgYXBwcm9wcmlhdGUNCiBhbmQgcmVzZXJ2ZSBleGlzdGluZyB2YWx1ZXMgY3VycmVudGx5IGlu IHVzZSBvbiB0aGUgSFRUUC8yIHNpZGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRo aW5rIHRoYXTigJlzIGEgZ29vZCBpZGVhLCBhbmQgaXTigJlzIGEgZmFpcmx5IHNtYWxsIHN0ZXAg ZnJvbSB0aGUgY3VycmVudCBzdGF0ZSBvZiAjMzYzLiZuYnNwOyBJ4oCZdmUgY3JlYXRlZA0KPGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzM3NiIgdGFy Z2V0PSJfYmxhbmsiPlBSICMzNzY8L2E+IHRvIGFjdHVhbGx5IG1ha2UgdGhhdCBzcGxpdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbW1lbnRzIGZyb20gYm90aCBXR3MgYWJvdXQgdGhl IHR3byBQUnMgd291bGQgYmUgd2VsY29tZS4mbmJzcDsgKEZlZWRiYWNrIHNvIGZhciBmcm9tIHRo ZSBRVUlDIHNpZGUgc2VlbXMgdG8gbW9zdGx5IGJlIOKAnHNlcGFyYXRlIHdpdGggcmVncmV0cyzi gJ0gYnV0IG5vdCB1bml2ZXJzYWxseS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708EFFD08761620114B066687200BN6PR03MB2708namp_-- From nobody Fri Mar 10 09:41:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CA8127077 for ; Fri, 10 Mar 2017 09:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 V8gwxjvHr3eg for ; Fri, 10 Mar 2017 09:41:50 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 56445129451 for ; Fri, 10 Mar 2017 09:41:50 -0800 (PST) Received: from mbp-4.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v2AHfmFT034039 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 10 Mar 2017 17:41:49 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mbp-4.local Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose , Eliot Lear References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> From: joel jaeggli Message-ID: Date: Fri, 10 Mar 2017 09:41:42 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LmjV4DfDajgFxbboMOGduWoxeOtQ8L9W0" Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:41:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LmjV4DfDajgFxbboMOGduWoxeOtQ8L9W0 Content-Type: multipart/mixed; boundary="rPwG7HBMbf5vnIIqOhGiOeevlACa7LpHt"; protected-headers="v1" From: joel jaeggli To: Kyle Rose , Eliot Lear Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" Message-ID: Subject: Re: Middlebox introspection/self-describing packets References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> In-Reply-To: --rPwG7HBMbf5vnIIqOhGiOeevlACa7LpHt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/10/17 9:08 AM, Kyle Rose wrote: > On Fri, Mar 10, 2017 at 8:29 AM, Eliot Lear > wrote: > > State your assumptions. Then design. > > > I think the key assumption from my perspective is that the protocol > should expose to passive observers as little metadata that can be used > to track the movements of users as possible while still keeping the > network operable. So, for instance, is there a legitimate traffic > management reason for a non-endpoint observer with tap points in > different networks to be able to correlate different flows for the > same connection? If the answer is "no" (and I would argue that it is), > then the protocol would ideally not enable that. Stable identifiers over the life of a "connection" as today with a "flow" can facilitate hashing, this could be / is simply stateless hashing across links or stateless distribution into stateful devices. with server assigned connection-id's pinning connections to particular endpoint in an otherwise stateless load-balanced service could be agnostic to changes in the 4 tuple. > As I've argued many times, there is a limit to what we can do on the > public internet as traffic analysis is very powerful; but I haven't > yet seen the reduction that shows no possible benefit over simply > putting a static connection ID in the clear in every packet. > > Kyle > --rPwG7HBMbf5vnIIqOhGiOeevlACa7LpHt-- --LmjV4DfDajgFxbboMOGduWoxeOtQ8L9W0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAljC5VcACgkQ8AA1q7Z/VrKHIQCcD75hUm0kbI54L9vsZq0EhhsZ cusAnjH1cD8quESuCG2u9h0oir1WK4JD =qbLr -----END PGP SIGNATURE----- --LmjV4DfDajgFxbboMOGduWoxeOtQ8L9W0-- From nobody Fri Mar 10 10:44:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C9512947B for ; Fri, 10 Mar 2017 10:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYBa4_16wYYI for ; Fri, 10 Mar 2017 10:44:42 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FAC12942F for ; Fri, 10 Mar 2017 10:44:42 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id 1so180702751qkl.3 for ; Fri, 10 Mar 2017 10:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cgIOesajqCmnEIjdmpd3uFWBhdyOY/le+kTASma/BH4=; b=dt+0E19mcjwy+mSvxQ+KRqsfMUsP672FB1Phiz75tSuklUSOMeTgVCSHftMIUrE8TT el+p7mZZrtrRFQXniVjJWTCcW8XYiNuIqkVjcxN1Up++KX+MZpWkNWuK5KqH28TUGuCm /Wb3/hwg704/KYQpwJSZ2AdsDDbk7iVUyyLxY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cgIOesajqCmnEIjdmpd3uFWBhdyOY/le+kTASma/BH4=; b=kMFWZMeN75oojLpC5Q9QvSFWnHC2UpclpiFd3xSYyDx6AdFcDtKm741FJc0CxuwKgJ Ogi0g79tMkcCJwKbdEYnQnhEmi3LRonw2JipI7FFMPGeNGf4m3+NwppJaQrYqh4DF+ho aw+hVxAAZqD1gWjCk73VL8m4c6+gJBdz3gsEsUCwVbwdOH0cGRKV7mzNEfWWTXHFzJEs QiYIyo00LN5uNz0vpKDETyvSzDKrPMDJ7374UM7zS2CIzIz4FXtPOAAMnAjFElIitcpM mHNjxO4se8buV7lZOToXU9ags/+9Zkda7Xe/K1dz+dJiM6AHvUVpmV7azyAKew6W2Pec 39NQ== X-Gm-Message-State: AMke39nLLRj0H8mK3uqBte/niCsfdOy0cuOe2hU6kpEEkXXcpoZqGZE8jYblfJv7MuhnmgJuAEon4ChCuJJyyA== X-Received: by 10.55.69.72 with SMTP id s69mr21646142qka.21.1489171004291; Fri, 10 Mar 2017 10:36:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 10 Mar 2017 10:36:43 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> From: Kyle Rose Date: Fri, 10 Mar 2017 13:36:43 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eliot Lear Content-Type: multipart/alternative; boundary=001a114ac874b89bcc054a64a493 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" , "ietf@trammell.ch" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:44:45 -0000 --001a114ac874b89bcc054a64a493 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 12:12 PM, Eliot Lear wrote: > That's a goal, not an assumption. > The assumption is that this is a goal for all new protocols. RFC 7258 and all that. > The assumptions have to do with what environment this protocol will > operate in over some period of time. I'm not arguing the goal mind you, > and I'm not landing a view as to what the right answer here is to EKR's Q. > But see my other message to Igor. You can engineer for worlds that will > never exist or corner cases that will make your protocol complex to operate > in. Or you could too narrowly engineer. Or maybe something in between. > Choose wisely. > I have repeatedly, in this very thread, questioned whether the benefits are worth the added complexity. I'm asking because I feel strongly that we need to have the conversation on this mailing list in the open, with the tradeoffs broadly understood. Given the contentious nature of the PLUS BoF in Berlin, I'm surprised more people haven't taken issue with designs that assume that a static connection ID for clients oblivious to network changes is okay. Kyle --001a114ac874b89bcc054a64a493 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 12:12 PM, Eliot Lear <lear@cisco.com> wrote= :
=20 =20 =20
That's a goal, not an assumption.

=
The assumption is that this is a goal for all new protocols. RFC 7258 = and all that.
=C2=A0
The assumptions have to do with what environment this protocol will operate in over some period of time.=C2=A0 I'm not arguing the goal mind you, and I'm not land= ing a view as to what the right answer here is to EKR's Q.=C2=A0 But see my ot= her message to Igor.=C2=A0 You can engineer for worlds that will never exis= t or corner cases that will make your protocol complex to operate in.=C2= =A0 Or you could too narrowly engineer.=C2=A0 Or maybe something in between= .=C2=A0 Choose wisely.

I have repeatedly, in this very = thread, questioned whether the benefits are worth the added complexity. I&#= 39;m asking because I feel strongly that we need to have the conversation o= n this mailing list in the open, with the tradeoffs broadly understood. Giv= en the contentious nature of the PLUS BoF in Berlin, I'm surprised more= people haven't taken issue with designs that assume that a static conn= ection ID for clients oblivious to network changes is okay.

Kyle
--001a114ac874b89bcc054a64a493-- From nobody Fri Mar 10 11:05:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4F1296D8 for ; Fri, 10 Mar 2017 11:05:23 -0800 (PST) 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 V7kLGL1Eq2oj for ; Fri, 10 Mar 2017 11:05:21 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A9F127058 for ; Fri, 10 Mar 2017 11:05:21 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cmPqn-0003L5-Mj for quic@ietf.org; Fri, 10 Mar 2017 20:05:18 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cmPqg-0001vn-Jw for quic@ietf.org; Fri, 10 Mar 2017 14:05:14 -0500 Received: (qmail 11640 invoked from network); 10 Mar 2017 19:05:10 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.223]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Mar 2017 19:05:08 -0000 To: quic@ietf.org References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> From: Christian Huitema Message-ID: Date: Fri, 10 Mar 2017 11:05:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BFFABF3C00789D89E9752EBD" Subject: Re: Middlebox introspection/self-describing packets X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXrSmcQr6Xk9n61fecGo5fAwRcOb18WfxGyg6Om6u4YYm7OBJqXM0TM9MkeW ByfjKXM5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK06Unk+ovW 8OxDhKv4jtZWxLbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4OawkTb+awG7VMldaRmL0vhtR5uZtTCm99yrLz JHh6+9FexdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+3pSiCKkaAoX/nv7Y+HHGvPcu6wTHpnlfUs9BUPj1rZ3 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:05:23 -0000 This is a multi-part message in MIME format. --------------BFFABF3C00789D89E9752EBD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 3/10/2017 10:36 AM, Kyle Rose wrote: > On Fri, Mar 10, 2017 at 12:12 PM, Eliot Lear > wrote: > > That's a goal, not an assumption. > > > The assumption is that this is a goal for all new protocols. RFC 7258 > and all that. > > > The assumptions have to do with what environment this protocol > will operate in over some period of time. I'm not arguing the > goal mind you, and I'm not landing a view as to what the right > answer here is to EKR's Q. But see my other message to Igor. You > can engineer for worlds that will never exist or corner cases that > will make your protocol complex to operate in. Or you could too > narrowly engineer. Or maybe something in between. Choose wisely. > > > I have repeatedly, in this very thread, questioned whether the > benefits are worth the added complexity. I'm asking because I feel > strongly that we need to have the conversation on this mailing list in > the open, with the tradeoffs broadly understood. Given the contentious > nature of the PLUS BoF in Berlin, I'm surprised more people haven't > taken issue with designs that assume that a static connection ID for > clients oblivious to network changes is okay. Let me second that. We don't want to create new long term static identifiers and yet another way to track devices as they move in the Internet. Yes, we also don't want to mandate something unduly complex. But then, the TLS working group was faced with essentially the same problem for "session resume", and came out with a pretty simple solution. I don't see why we could not have something similar in QUIC. -- Christian Huitema > > Kyle --------------BFFABF3C00789D89E9752EBD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 3/10/2017 10:36 AM, Kyle Rose wrote:
On Fri, Mar 10, 2017 at 12:12 PM, Eliot Lear <lear@cisco.com> wrote:
That's a goal, not an assumption.

The assumption is that this is a goal for all new protocols. RFC 7258 and all that.
 
The assumptions have to do with what environment this protocol will operate in over some period of time.  I'm not arguing the goal mind you, and I'm not landing a view as to what the right answer here is to EKR's Q.  But see my other message to Igor.  You can engineer for worlds that will never exist or corner cases that will make your protocol complex to operate in.  Or you could too narrowly engineer.  Or maybe something in between.  Choose wisely.

I have repeatedly, in this very thread, questioned whether the benefits are worth the added complexity. I'm asking because I feel strongly that we need to have the conversation on this mailing list in the open, with the tradeoffs broadly understood. Given the contentious nature of the PLUS BoF in Berlin, I'm surprised more people haven't taken issue with designs that assume that a static connection ID for clients oblivious to network changes is okay.

Let me second that. We don't want to create new long term static identifiers and yet another way to track devices as they move in the Internet. Yes, we also don't want to mandate something unduly complex. But then, the TLS working group was faced with essentially the same problem for "session resume", and came out with a pretty simple solution. I don't see why we could not have something similar in QUIC.

-- Christian Huitema



Kyle

--------------BFFABF3C00789D89E9752EBD-- From nobody Fri Mar 10 12:23:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AA712945F for ; Fri, 10 Mar 2017 12:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-X6zXoDNiNd for ; Fri, 10 Mar 2017 12:23:47 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE79129452 for ; Fri, 10 Mar 2017 12:23:47 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id p64so185512686qke.1 for ; Fri, 10 Mar 2017 12:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NJbLHId2gzEhd1Hrbm2uqNRY+Eh0Xlmffhp/TQRRYz4=; b=KLtNKUgPIbavOlcnbRiu1X/oxPI09iCyEKacCMp8kQ8AHy5rqyQcBgaiu++QFLwrtG h2btfDSDNlNGE49IFcH2htwc+M0Br1hYptKoSX8EB0UX37MI3WYhWoJx0CBW7BIEacK5 PV68GJRBdT9cjHm6TjtQ0KXaY/ie6S//ixetw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NJbLHId2gzEhd1Hrbm2uqNRY+Eh0Xlmffhp/TQRRYz4=; b=g37t+MVHnYIxhYjoPiPscIKSHWOuBa3sQu7Mw7GTtrIOmO77QK8BM54FeAQwWHWH2x s+oHPTM5CW43xUKN8EAFZH+s62W06RKk1et2arKahGQA3HvxkSfyn67yDR2KCzmsF4mY bg7UdrVPSLTVtSzHlKILmjZunuAAKVES6tfzXgJddLJ3ufPVHD4NOHJRnQje2rgxinqH Z6N/EKAe7w2f1WHUb8YrsZiRuE8BcsaDL4BaBfwA8MpjjynAtqyjf1j/Q9q04bb+IXtn f/oPnkNXIu3nsSen+VuTrfcN9EKXtTobzpHzwQtfPbwJiANdI4AXPzm5i93XPAF3SjoE Gksw== X-Gm-Message-State: AMke39nuH195SO+oeialjiXPGPIa6oHeed0gfeHH4Ye4QBvD67Uq69oqsDWhM1VFlkbSa8xmmE/aDWvuD76D1Q== X-Received: by 10.55.214.21 with SMTP id t21mr21466940qki.41.1489177426060; Fri, 10 Mar 2017 12:23:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 10 Mar 2017 12:23:45 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> From: Kyle Rose Date: Fri, 10 Mar 2017 15:23:45 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11465b227d0292054a6623da Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 20:23:49 -0000 --001a11465b227d0292054a6623da Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 2:05 PM, Christian Huitema wrote: > > Let me second that. We don't want to create new long term static > identifiers and yet another way to track devices as they move in the > Internet. Yes, we also don't want to mandate something unduly complex. But > then, the TLS working group was faced with essentially the same problem for > "session resume", and came out with a pretty simple solution. I don't see > why we could not have something similar in QUIC. > The problem is slightly more complex, in that TLS needs a unique identifier only when a new TCP connection is opened (where, MPTCP notwithstanding, TCP does not support client mobility, whereas a client can change network address in the middle of a QUIC connection, something we explicitly want to support. So the mitigation strategy would be different, and in some designs would involve greater overhead (e.g., doing the TLS-like thing and sending enough connection IDs in the first ACK to cover expected packets in flight, followed by more in every ACK thereafter) or different overhead (e.g., 0-RTT resume after discover of an alien packet leading to a public reset). But I think it's doable. Kyle --001a11465b227d0292054a6623da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 2:05 PM, Christian Huitema <huitema@huitema.net&= gt; wrote:
=20 =20 =20
Let me second that. We don't want to create new long term static identifiers and yet another way to track devices as they move in the Internet. Yes, we also don't want to mandate something unduly complex. But then, the TLS working group was faced with essentially the same problem for "session resume", and came out with a pr= etty simple solution. I don't see why we could not have something simila= r in QUIC.

The problem is sligh= tly more complex, in that TLS needs a unique identifier only when a new TCP= connection is opened (where, MPTCP notwithstanding, TCP does not support c= lient mobility, whereas a client can change network address in the middle o= f a QUIC connection, something we explicitly want to support.

So the= mitigation strategy would be different, and in some designs would involve = greater overhead (e.g., doing the TLS-like thing and sending enough connect= ion IDs in the first ACK to cover expected packets in flight, followed by m= ore in every ACK thereafter) or different overhead (e.g., 0-RTT resume afte= r discover of an alien packet leading to a public reset). But I think it= 9;s doable.

Kyle

--001a11465b227d0292054a6623da-- From nobody Fri Mar 10 12:52:26 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4B1294FC for ; Fri, 10 Mar 2017 12:52:24 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 NCTlbnJ8gwJw for ; Fri, 10 Mar 2017 12:52:23 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 43AAC1294DA for ; Fri, 10 Mar 2017 12:52:23 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id o4so31275443ywd.3 for ; Fri, 10 Mar 2017 12:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5AzjnTRlZihOFqqLj6da4VJFM1bEvLzMBSEBZtbHK8Q=; b=Z2/RubNtTgH+iywEAC2Tp3GiC3fU99a9qf1xGUNzZbAQehnp/3vQq15WkPSzoXDf64 1iKL1v/7GZm4SPKP0HvjMb65hW+vqJAs6TnMgAIPTTLyHbZsHfLpVli5d/OByMncDiaX rdxi63Jzp0sCmMhAzZW9BswFrd2SF+3GFAkugV0vvEfdhtYdaWQtSlcoUTWuqsLOWW91 B0Mv8ZNO6q64c6RRONj4vgnZkiArG3wH5MA61PX89q/SX6Um2l9xeHZj9kuwfhVq1FRb Bfw7SAH5Fnbgtc2bf60dkqq4410ax8JAI6lsqII9RN/WFsClKmY01tM0NvXPxeYjJxIl KY+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5AzjnTRlZihOFqqLj6da4VJFM1bEvLzMBSEBZtbHK8Q=; b=Edh3xmOQllikq4kDGR2/ZFqHJgv9xUmFVf8kBfmUgI+UIRl69TImFtHKDzNI/DOWdY EqHwqtdv0TxtPICfqPCn8VSFmEkncJkBdBjcqaJPfmEmhuN/RXIAKesTnp/RrYuwUVts GqaDIgrjUwE+oLbvxw/viY+DKytJLuvbQmHQmDmiIyD8CKkHMV9HRshVaH8sDE7Xa4Bs jhPEMxFq+NnU504oFp3AAkkEj7VVIwMl4lZN3Mc20vsbCg9LjwJFY7d/Jx0Io92uSCHb PYWxeXGY8uYbjNqZK6OECeWwKxkeZD8HzIiFc8eqiFcJ8+dMwr8B11uIXW0jEG1yoS/X 3WLg== X-Gm-Message-State: AMke39nfjNTbuo/O3dz/OQiiUNFrBff43LDQdhTbs9FZie4TWYVSFr6HvqJ0N/v/PY9HAXXAbn6nAi8kCjtktg== X-Received: by 10.129.152.22 with SMTP id p22mr10062320ywg.276.1489179142372; Fri, 10 Mar 2017 12:52:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 12:51:41 -0800 (PST) In-Reply-To: References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> From: Eric Rescorla Date: Fri, 10 Mar 2017 12:51:41 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c0b8fb4ca634d054a6689fd Archived-At: Cc: IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 20:52:24 -0000 --94eb2c0b8fb4ca634d054a6689fd Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 12:23 PM, Kyle Rose wrote: > On Fri, Mar 10, 2017 at 2:05 PM, Christian Huitema > wrote: > >> >> Let me second that. We don't want to create new long term static >> identifiers and yet another way to track devices as they move in the >> Internet. Yes, we also don't want to mandate something unduly complex. But >> then, the TLS working group was faced with essentially the same problem for >> "session resume", and came out with a pretty simple solution. I don't see >> why we could not have something similar in QUIC. >> > > The problem is slightly more complex, in that TLS needs a unique > identifier only when a new TCP connection is opened (where, MPTCP > notwithstanding, TCP does not support client mobility, whereas a client can > change network address in the middle of a QUIC connection, something we > explicitly want to support. > > So the mitigation strategy would be different, and in some designs would > involve greater overhead (e.g., doing the TLS-like thing and sending enough > connection IDs in the first ACK to cover expected packets in flight, > followed by more in every ACK thereafter) > FWIW, I don't think that you would ever need to send connection_ids for each packet, b/c you can generate them deterministically from a shared secret. That's not to say that this is a great design, but it is better than sending a huge pile of IDs -Ekr > or different overhead (e.g., 0-RTT resume after discover of an alien > packet leading to a public reset). But I think it's doable. > > Kyle > > --94eb2c0b8fb4ca634d054a6689fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 12:23 PM, Kyle Rose <krose@krose.org> wrote:
On Fri, Mar 10, 2= 017 at 2:05 PM, Christian Huitema <huitema@huitema.net> wr= ote:
=20 =20 =20
= Let me second that. We don't want to create new long term static identifiers and yet another way to track devices as they move in the Internet. Yes, we also don't want to mandate something unduly complex. But then, the TLS working group was faced with essentially the same problem for "session resume", and came out with a pr= etty simple solution. I don't see why we could not have something simila= r in QUIC.

The problem i= s slightly more complex, in that TLS needs a unique identifier only when a = new TCP connection is opened (where, MPTCP notwithstanding, TCP does not su= pport client mobility, whereas a client can change network address in the m= iddle of a QUIC connection, something we explicitly want to support.
So the mitigation strategy would be different, and in some designs would i= nvolve greater overhead (e.g., doing the TLS-like thing and sending enough = connection IDs in the first ACK to cover expected packets in flight, follow= ed by more in every ACK thereafter)

FWIW, I don't think that you would ever need to send = connection_ids for each packet, b/c you can generate them
determi= nistically from a shared secret. That's not to say that this is a great= design, but it is better than sending
a huge pile of IDs

-Ekr
=C2=A0
or different overhead (e.g., 0-RTT resume after discover of an alien pack= et leading to a public reset). But I think it's doable.

Kyle

<= /div>

--94eb2c0b8fb4ca634d054a6689fd-- From nobody Fri Mar 10 15:59:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77D1289C4 for ; Fri, 10 Mar 2017 15:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTU2oze0wDhn for ; Fri, 10 Mar 2017 15:59:26 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2914912948A for ; Fri, 10 Mar 2017 15:59:26 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p64so190784394qke.1 for ; Fri, 10 Mar 2017 15:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=midoUMcs45esQi8DfnJsYf8ANQm6QFHYuP1YOpQ/W9k=; b=NoVjX7qSL1xYHsiI1M+jYR8HWGvOMpXxXbAC1jI2Q5pws7POUpNJzGlnhZmqeYmzDF HD+AaFFfQm3G24AGnJWVVioB0v4i/DOK5nsVcL0q7r3zmFDvpR/jAdU7bp3NPyEKVABY lEq/UkCLEq/aDlkwNbn0wuEYYj8WaPx8IT8k0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=midoUMcs45esQi8DfnJsYf8ANQm6QFHYuP1YOpQ/W9k=; b=UTmCE+2lY635opKxXBW44ZPvv7WcrA/25R5KWOQHlGSBZZH8YOAu3Jn3Oi5S8jEwgR yEYyf8L7LQlEDkCdU+f3xRkO+Gel2c+kwF4cMMexQ0SDZ9swcUVYOJ9TgfNW0ZMKwn7n 0icIK71kPNj3eUhOnZPVTcuXPli7YnRw49RUhI3qLw9eHZcIcyvm7AeIS+OwuV5riK/C NZS/XIksOi+EOfUcLE50LJ4ZpYJLs2NkVNFfS+vXdktXekK0Hqkac+XEyPQx5s2sPi9g ngQkeEMVNJvLr+eXUAZVqeAUJtvBKLxFoK4NQZUqMxW5RZC2fBUCl540hyreI+wg9Cvq lrGQ== X-Gm-Message-State: AMke39nIL77L33ytSjCqWM2onhKWpxRHEoeXCrd8gPNo6A3JmnC+SLL6KlgbPSutZX0gwmq0s8bijfGL5UYv3Q== X-Received: by 10.55.214.21 with SMTP id t21mr22208134qki.41.1489190365099; Fri, 10 Mar 2017 15:59:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 10 Mar 2017 15:59:24 -0800 (PST) X-Originating-IP: [2001:470:1f07:121:103e:c9ff:fe51:acfa] In-Reply-To: References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> From: Kyle Rose Date: Fri, 10 Mar 2017 18:59:24 -0500 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11465b22b71886054a692631 Archived-At: Cc: IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 23:59:28 -0000 --001a11465b22b71886054a692631 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 3:51 PM, Eric Rescorla wrote: > > FWIW, I don't think that you would ever need to send connection_ids for > each packet, b/c you can generate them > deterministically from a shared secret. That's not to say that this is a > great design, but it is better than sending > a huge pile of IDs > Right, this is the rolling code stuff we were discussing in the other thread. One disadvantage of that approach is the need for a separate plaintext server cookie for load balancing state since the rolling code is essentially random, but that cookie can probably be smaller than a connection ID and should satisfy a different set of requirements, such as that the number of values used at any one time be proportional to the number of servers rather than to the number of clients. It's not great because this is simply guidance and is therefore subject to abuse, but I don't see any way out of the stateless load balancing pickle without it. Kyle --001a11465b22b71886054a692631 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 3:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>

FWI= W, I don't think that you would ever need to send connection_ids for ea= ch packet, b/c you can generate them
deterministically from a sha= red secret. That's not to say that this is a great design, but it is be= tter than sending
a huge pile of IDs=C2=A0

Right, this is the rolling code stuff we were dis= cussing in the other thread. One disadvantage of that approach is the need = for a separate plaintext server cookie for load balancing state since the r= olling code is essentially random, but that cookie can probably be smaller = than a connection ID and should satisfy a different set of requirements, su= ch as that the number of values used at any one time be proportional to the= number of servers rather than to the number of clients. It's not great= because this is simply guidance and is therefore subject to abuse, but I d= on't see any way out of the stateless load balancing pickle without it.=

Kyle

--001a11465b22b71886054a692631-- From nobody Fri Mar 10 16:04:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B67129495 for ; Fri, 10 Mar 2017 16:04:12 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 DXLzAjSOzTf9 for ; Fri, 10 Mar 2017 16:04:10 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD9512948A for ; Fri, 10 Mar 2017 16:04:10 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v198so33375467ywc.2 for ; Fri, 10 Mar 2017 16:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oDoSZ1vCt+bK7Rllh1d8X/vdrNDFFHPDkW7FY83zlng=; b=NWGt/z3dtKDnSBxNomvMrKhFEhITZ7P+KnLiYVHZm8pP7S9bLS2UpmwEBIrGwFO7Ct kBmSJNaV0P+hdfx0d94gfJ9/XNTTrXybSGyUaRS7z1pJi1NntJ+HDkav8qfZxbIjcvqL fWl3vtGU1itJlo9MjG0DqcG+0AGnCHBjQ9HA/o77TpkryJ+jGjwVptJFd9VQhAMBJwse SjvZWntK8GZa206NIpfqTMxoobjoPUYj+3w4rXPBpA73AAMWdTNAuIkTxQo1nopqRTE8 E8qhIhHAqshWDBxN+rWVEc07aUoEA9OKtGbWOKk5l8yOUAf/5D+MMWqH6u5vHAJab6/B 8NEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oDoSZ1vCt+bK7Rllh1d8X/vdrNDFFHPDkW7FY83zlng=; b=D2+cQiP0TbMkblTnppdLovPLCHETYe89VEWQCDDRXX2V9gzomK41kWMr0Zoifc5ojt K9BdeZuamv5aoVrF7q/zuIMKktc5KkKSbY9E4FoJ7X5JIDUVEingcQKuXeCYuYwgS1wN Gai2WgARFRHhtbA6a1pibCCYfzrBHib3v8Yfsz3Cb9num1jyF+rRTyUi4HFqmf3WaHdM jH4kjTnO7ECStySWrWBD1Z3bBROq4SMFA4/WaOhLWwDYrap7kviMP4VFxmGLcmTkEzVN IvrtTsCFh2rHQd3j1qFm1yS+ogLu8+loH+DWGRXpWkuvzqvv4Rt5GjQ7r36nxbn4t5IQ X11Q== X-Gm-Message-State: AMke39mjp2DuskJ22B3WLS1zYRubijGacyArJCfeDA4waRxn3iU5umN0HcYw2+VGK7fBhC6xbhATRPQLK31Tyw== X-Received: by 10.37.224.81 with SMTP id x78mr9170000ybg.80.1489190649997; Fri, 10 Mar 2017 16:04:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 16:03:29 -0800 (PST) In-Reply-To: References: <9906aa175d054dbbad9b647719f8b42c@usma1ex-dag1mb5.msg.corp.akamai.com> <385812dd-bb45-6baa-af70-6aaa9c1c1d3e@cisco.com> <084e0a73-1815-3ea7-e97f-c6e7fe1a2a06@cisco.com> From: Eric Rescorla Date: Fri, 10 Mar 2017 16:03:29 -0800 Message-ID: Subject: Re: Middlebox introspection/self-describing packets To: Kyle Rose Content-Type: multipart/alternative; boundary=94eb2c087358b24167054a693710 Archived-At: Cc: IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 00:04:12 -0000 --94eb2c087358b24167054a693710 Content-Type: text/plain; charset=UTF-8 Right. Just for my records: if the server hands out a token for each packet, then it can encrypt that token with a key known just to itself. Of course, as you note, this is sucky in other ways. -Ekr On Fri, Mar 10, 2017 at 3:59 PM, Kyle Rose wrote: > On Fri, Mar 10, 2017 at 3:51 PM, Eric Rescorla wrote: > >> >> FWIW, I don't think that you would ever need to send connection_ids for >> each packet, b/c you can generate them >> deterministically from a shared secret. That's not to say that this is a >> great design, but it is better than sending >> a huge pile of IDs >> > > Right, this is the rolling code stuff we were discussing in the other > thread. One disadvantage of that approach is the need for a separate > plaintext server cookie for load balancing state since the rolling code is > essentially random, but that cookie can probably be smaller than a > connection ID and should satisfy a different set of requirements, such as > that the number of values used at any one time be proportional to the > number of servers rather than to the number of clients. It's not great > because this is simply guidance and is therefore subject to abuse, but I > don't see any way out of the stateless load balancing pickle without it. > > Kyle > > --94eb2c087358b24167054a693710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right. Just for my records: if the server hands out a toke= n for each packet, then it can
encrypt that token with a key known just= to itself. Of course, as you note, this is sucky
in other ways.<= /div>

-Ekr


On Fri, Mar 10, 2017 at 3:59 PM, Kyl= e Rose <krose@krose.org> wrote:
= On Fri, Mar 10, 2017 at 3:51 PM, Eric Rescorla <ekr@rtfm.com= > wrote:

FWIW, I don't think that you would ever need to send connectio= n_ids for each packet, b/c you can generate them
deterministicall= y from a shared secret. That's not to say that this is a great design, = but it is better than sending
a huge pile of IDs=C2=A0
<= /div>

Right, this is the rolling cod= e stuff we were discussing in the other thread. One disadvantage of that ap= proach is the need for a separate plaintext server cookie for load balancin= g state since the rolling code is essentially random, but that cookie can p= robably be smaller than a connection ID and should satisfy a different set = of requirements, such as that the number of values used at any one time be = proportional to the number of servers rather than to the number of clients.= It's not great because this is simply guidance and is therefore subjec= t to abuse, but I don't see any way out of the stateless load balancing= pickle without it.

<= /font>
Kyle=


--94eb2c087358b24167054a693710-- From nobody Fri Mar 10 18:46:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321B1129503 for ; Fri, 10 Mar 2017 18:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 oDvGWjAn1YLS for ; Fri, 10 Mar 2017 18:46:16 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 59EBA1294F5 for ; Fri, 10 Mar 2017 18:46:16 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 72so130374223uaf.3 for ; Fri, 10 Mar 2017 18:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cIZk9aATXWajuAAQNsh7T8JfOMWqa6JTFZw8trmdMiU=; b=pAcqkmkI0GHAKmfmu7h12ixtGA65ahc6QsOOInomweFChpZMv0m3O/Ba7KXXSNG6KV tSj3knk18u0U4M0Zen9ZKJYZzrwyMkRWg2OQaofWiDlm3szvToNecPXeJLJyICuoCdCX +h+zbia4H/cOFKspyPivBgeRdMti0neov1PVLAw+nS35s2GLdBp7dtFB4r+kTtGt1P7C PMvrqqxqtJeV2eS7fwBSr43OGdHRqrMbPdT320r/6jKZDsAdfF1ElqqvSi2GlJt/JAMk 0OrvIxF1abCxXZ0qOE59Sknp5kASpItIuRjP/DDVUbgoStaZtYrgyYrWdQJ+ePq6JW6z Dd3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cIZk9aATXWajuAAQNsh7T8JfOMWqa6JTFZw8trmdMiU=; b=kJpAV21XggUkUKULqDhSBtn/jBBdrvLr7fCC6XzVt0Kia+PVWsrPLIsJ2kkGg9eqQk SeMytK2dlqA6SpKhB+oftygVgABiU/DjVGutw47wm+llJMNUV+k59wKnsUzq8Ye/2QZL 1ZiSC7H6DgxwO/G2iJSKuLRaEkmTQLivFujk//BC+eiGVLw6hyW7ijCPfQd7Ew60OqG+ e30fhCH7MwWAMAzhCMywkNeq21ZBzZMBv0v9PWhyZbXL0h6iikIqGmqoqfLgN3jP8Voa KWgsoBkHUwAPjQAACVb+moz3p6FuDUPfFQl/WRHmur2oNUEr6Oqo2I+nty5sIyu9eZdP fOvQ== X-Gm-Message-State: AMke39ksauFRuma/ZTUwOPhp+8FAAflHLWcP+bT8yRA6TX7dlIApOcMEouBmTHxEhOG5BqKsBVNubEStj6IXXdxn X-Received: by 10.176.83.79 with SMTP id y15mr9703648uay.141.1489200375111; Fri, 10 Mar 2017 18:46:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Fri, 10 Mar 2017 18:46:14 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Fri, 10 Mar 2017 18:46:14 -0800 Message-ID: Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-00 To: Mike Bishop Content-Type: multipart/alternative; boundary=94eb2c0cfd325c1ffc054a6b7b67 Archived-At: Cc: "Brian Trammell \(IETF\)" , Ian Swett , Hannes Tschofenig , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 02:46:18 -0000 --94eb2c0cfd325c1ffc054a6b7b67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 7:25 AM, Mike Bishop wrote: > Part of me wonders whether QUIC will wind up running over port 53 for the > same reason that every protocol in the world seems to run over TLS on TCP > port 443. ;-) > We do have port negotiation in Alt-Svc for QUIC. It's a hammer that's available to us :-) I suspect we'll detect other failure modes -- middleboxes that drop packets that don't look like DNS packets. I think there's ~10% that we need to write off for any new protocol at this point. *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Thursday, March 9, 2017 4:52 AM > *To:* Hannes Tschofenig > *Cc:* Brian Trammell (IETF) ; quic@ietf.org > *Subject:* Re: UDP Usage and draft-kuehlewind-quic-applicability-00 > > > > > > On Thu, Mar 9, 2017 at 7:48 AM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > Hi Ian, > > > > =C3=98 Yes, my talk was in Berlin 2016 at TSV Open(https://datatracker.i= etf. > org/meeting/96/agenda/tsvarea/). I sent Mirja a PDF copy of the slides, > but I'm not sure where they are posted. > > > > Found them at https://www.ietf.org/proceedings/96/slides/slides- > 96-tsvarea-2.pdf > > > > =C3=98 To second what Brian said, most 'networks' which block QUIC are > corporations that are large enough to have their own AS number. I've nev= er > found a major ISP that blocks UDP 443. > > > > Have you tested the results of using UDP on ports other than 443 and > whether the blocking rate increases? > > > > > > We have some data from about 4 years ago on this, but I don't have it > easily available. I don't remember 443 being dramatically more open than > other ports. In general, it seemed UDP either was blocked or wasn't. > > > > Ciao > > Hannes > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > --94eb2c0cfd325c1ffc054a6b7b67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --94eb2c116b8aedd662054acc27c2-- From nobody Wed Mar 15 16:12:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123F2129C4C for ; Wed, 15 Mar 2017 16:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 kt5tMgqccz5m for ; Wed, 15 Mar 2017 16:12:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 C40E3129C47 for ; Wed, 15 Mar 2017 16:12:48 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3BE0222E257; Wed, 15 Mar 2017 19:12:41 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Draft agenda for Chicago Message-Id: <42928A74-0BB6-4271-AFBD-0A2537D2A453@mnot.net> Date: Thu, 16 Mar 2017 10:12:39 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:12:51 -0000 ... is at: https://github.com/quicwg/wg-materials/blob/master/ietf98/agenda.md as well as in datatracker. If you'd like to be queued in the "Parking Lot", please ping the chairs. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 15 20:48:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA802131447 for ; Wed, 15 Mar 2017 20:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgoBqaHVu303 for ; Wed, 15 Mar 2017 20:48:30 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E6D130141 for ; Wed, 15 Mar 2017 20:48:30 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id y76so29745741qkb.0 for ; Wed, 15 Mar 2017 20:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ixul2xOk5B2MDLTz3SosqHjTZwUyhAUpadVyjXiy7f0=; b=nM0lsOzU56Qg9LCmDbaJRjF1JCuzdhb9tJBgIQgimBN9jd+gpFcrHQmyrP9+Yw4a9v LLeMAwuLQjhF3lxW1hh8p2zlfatVABaxpeXGHkrclhGaRI3rJLXraauYrUtQG0mI669p 6B75gtO3CjpL2VmYoJ9Avbxb3t7Q3oQ3aHTJ116YaKksqWYVkjzr1ar/KwaJFwDP5XAH 0y9jT3Ri50227M67rd0pF8ra0ZfmDiAr8gKtjj0sIaLNoSX/fhkDFSbJFaM/7QcMAoRq jiyThAaCT5Q/rZGhofo/xqTviCT6qtceYLoZAlN46hqkv+8V5NG/2A+hGz7ZYmWeyDsv 4Wfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ixul2xOk5B2MDLTz3SosqHjTZwUyhAUpadVyjXiy7f0=; b=CVnw3V5xBrEsbgCQ+0fjmbwMTIQhY3TFwZIiRe5dxQYUs6ryRBvBkrp3tXd3hMjxoj RmKO6Nda99ACTIUUVo1Q5E0XxDV8KGZhVUhC11nhuRHTwUgRoaqSKBZnZTZNU4N2dY1X JJ04gJbF1VVYQFN9JcnzLdw7xY9viLZ6F3rUEnMhzw5NxHgNE0JRdZK/r9IIanJKAE7e w8iMOBS1qf+NbJWWhoxBM1Nd3cm41TLPWlfoVtHeUDeirYSgAVQ0Swj28lHaYRXzgT6W /4izpYuBiQ6uYkQ5vn+JhuiLrptitU+5gG9mza3N8ehZPeG2LHkC20tjoylKEgDxLtvv sEFQ== X-Gm-Message-State: AFeK/H2mUKeBbdpVhJABlTD+gsoYhJI+nLtzZQlmebNh/qTNZOO16LCyv09UeqIo30ezbBTVeIKomNnLNeMQDQ== X-Received: by 10.55.18.144 with SMTP id 16mr6260207qks.5.1489636109846; Wed, 15 Mar 2017 20:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 15 Mar 2017 20:48:29 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 16 Mar 2017 14:48:29 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Duke Cc: Jana Iyengar , Ian Swett , Ted Hardie , IETF QUIC WG , Lucas Clemente Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 03:48:33 -0000 I don't think that "TCP-like" is the right benchmark here. That would apply to streams, but not the entire session. Even in HTTP, your signal doesn't work in one direction. A server generates streams in response to client streams. It can't say "I'm done with creating streams, but you continue for now" without cutting itself off from server push. You might not be sad about that, but you'd have to admit that would be a subjective decision. Given that we're aiming for a general purpose protocol, we can't guarantee that other applications will have clean transactional semantics such that your signal will be actionable at the transport layer. Only the application protocol knows when it is "done", so any signal of imminent shutdown is going to be up to them. What would a generic shutdown() do? You can't just close all open streams where they stand and hope that the application protocol will be happy. The more I think about this problem, the more I am convinced that the application needs to sort it out and then send a signal to the transport. That signal would be "start a timer (like FIN_WAIT2), if you don't see anything new in that time, discard state". HTTP would do that after receiving its own "I'm done" signals on its connection control stream and closing out any lingering streams and retransmissions. The real signaling (a GOAWAY or analogous) would have to be exchanged a long time before that. On 16 March 2017 at 09:06, Martin Duke wrote: > This doesn't match my perception of the contract between a TCP-like > transport layer and applications that use it in a "clean close", but then > neither does the existing bidirectional GOAWAY. A clean close should > indicate to the app that all written data has been received, and the peer > has successfully delivered all its intended data. > > What QUIC needs is a signal that says "I am done creating new streams but am > still willing to receive new ones". Although there ought to be stream-level > shutdown() calls in a future socket API, but a connection-level shutdown() > would send this signal and also FIN all remaining streams. After both QUIC > endpoints clean all this up at the transport layer, there is no need for a > further signal from the app. > > Forcing every app to create its own GOAWAY (or, in my vision, send-only > GOAWAY) mechanism seems rather heavyweight if it is a common feature of a > clean close. > > On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar wrote: >> >> After chatting with Martin offline, it's growing on me as well. The key >> insights in my mind are: >> >> 1. It's preferable for each endpoint to indicate the streams it is >> closing, to avoid requiring upper-layer retries of new streams in flight. >> >> 2. The semantics of stream creation are different for different apps. HTTP >> generally has the client creating a stream and the server responds on the >> same stream. A different application can have very different client-server >> interactions. For instance, a client creates a stream which requires a a >> server to create multiple streams in response, which in turn require further >> client stream creations. In this case, QUIC has no idea what the "last" >> stream ought to be, and this needs to be indicated by the application. >> >> 3. Since in the general case the app protocol is expected to be involved >> in figuring out what graceful close looks like, it makes sense to define it >> per app. In other words, make it part of the app mapping to QUIC. For HTTP, >> this would be a GOAWAY frame on Stream 3. Once all streams are closed, HTTP >> closes Stream 3. >> >> 4. Graceful close by the app means that the QUIC connection can >> immediately go into TIME_WAIT on a connection close from the app. >> >> It is a clean separation of concerns for sure. I'd like to ruminate on >> this a bit, since sometimes that helps. >> >> This seems like good fodder for Chicago. >> >> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett wrote: >>> >>> After thinking about it more, if no one else has objections to "Make >>> every application implement their own graceful close if they need it and >>> only provide a way to kill the connection immediately.", I'm fine with it as >>> well. >>> >>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson >>> wrote: >>>> >>>> On 8 March 2017 at 03:58, Ted Hardie wrote: >>>> > >>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson >>>> > >>>> > wrote: >>>> >> >>>> >> I think that both are likely to run afoul of a simple problem in >>>> >> HTTP: >>>> >> the control stream (stream 3) can't be closed. >>>> >> >>>> > I don't think that's actually a problem with what I suggested. It >>>> > simply >>>> > means that for the HTTP mapping, the defined behavior is to send >>>> > FIN_COMPLETE after all open requests and pushes complete. If it >>>> > arrives >>>> > before then, you'd have to treat it as a protocol error for the >>>> > mapping. >>>> > What I'm trying to avoid is baking in the requirement that >>>> > FIN_COMPLETE (or >>>> > its moral equivalent) always occur then, since it will make using >>>> > other >>>> > types >>>> >>>> Sure. I had inferred that you were doing this entirely at the >>>> transport layer, which doesn't really allow you to do that. >>> >>> >> > From nobody Wed Mar 15 21:52:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3F12002E for ; Wed, 15 Mar 2017 21:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QmRSHwIJe2Z for ; Wed, 15 Mar 2017 21:52:34 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84390120025 for ; Wed, 15 Mar 2017 21:52:34 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id x35so29081159qtc.2 for ; Wed, 15 Mar 2017 21:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UrsdHg4HAsRh9oQMIakZTnLgF6WQ2Tx9J5PIFgfBqZ0=; b=Os4H+WdGFpyvCoj2hYWe0fFTnBiTNo9jC3R1bChhPBWzf65FstTxMC2J/ziCxqlk65 vjISqlDKcqeIbbYYzdHkZjg+5KRI6Iq/Br/mCdHjibEqBV8bFqSbkOFrTRaJDvSxS4ur Td9daSL4Nwz7mletoO+EoA0JEEmsqQ4iPgOIiuACDI3PWVCEheQxGzVCKefWJA1J6/ZA zEciu5VQuOOi4afi4K8IxZvnGnHPamD7w/VH1X3DkcIeypASzRuBCTGhKgiAPW7/V5lA b4LUPSL33n/DfWH2iP7VH7QaGcolsri3Zsl7LBNG3tw3KWIPPcQI0xdsb3IsyAz6SRVR axFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UrsdHg4HAsRh9oQMIakZTnLgF6WQ2Tx9J5PIFgfBqZ0=; b=L9OFGSGdhtU8F0olQN6AX9D3vnHf/ZAd3Bp5NpCRue2z2+W9f2PR471Q0zy4NpcwMx ALLciS5OeOwPSRljJypeQpQIBqDdyL+Koq72I3/sutCwoh7iDX/3waG45tJabKfh1jEk EKMkwK480sOLcKKzbnn6/3E7ZRu1i0S65Os8zEoQhh5Pn5e6577KRzLIsiok4IhyEE5K oGr/pog5KIpzj2dtZKK3CyMRlTdfz0s3KImIoRxF8/7sMkQhNhpf54iZpcRL0R3OPghV 8nv+kYzIO2zFD3oC1qlbNOA9Tt8noGqVV+k8w4b3Ywlqw87O0w5tW+5bWW7C4+LHJtYT hUCw== X-Gm-Message-State: AFeK/H1gb0aJ3XxLu0p5eWjlldWy0RgBSr+ayFdBpv+Q09F7QfumSTQqIs2ef9JrjWcmXMXWP62BohcUHMo6AA== X-Received: by 10.237.41.100 with SMTP id s91mr6925981qtd.143.1489639953560; Wed, 15 Mar 2017 21:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 15 Mar 2017 21:52:33 -0700 (PDT) In-Reply-To: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> References: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> From: Martin Thomson Date: Thu, 16 Mar 2017 15:52:33 +1100 Message-ID: Subject: Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= 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.22 Precedence: list List-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 Mar 2017 04:52:37 -0000 Thanks for putting these together. # Bit ticket feedback I think that these drafts need to consider the protocol as a package, not focus on individual parts. Thus, you should talk about HTTP/QUIC and its properties, not talk about a transport protocol. That means referencing the HTTP mapping document for introductory matters and only referencing other documents when it is relevant to a particular point. Take for example the fallback section in the applicability draft. If you were to talk about the specifics of HTTP/QUIC, then you only need to talk about having HTTP/2 or HTTP/1.1 as a backstop. There is probably some advice that could be given that would be generic, but I suspect that without actually having more usage examples to drive this from, we would just get those laughably wrong (not all, but some). # Applicability The fact that this is encrypted is very prominent in the introduction. I expect that this is more of interest to the other document. ## Section 2 (Fallback) The point on fallback is that you will lose something, but you should not allow fallback to another protocol to degrade security guarantees. That is, you might lose performance (holb, multiplexing, etc...), but you shouldn't lose any expectation of confidentiality or integrity, if requirements for those things have been established. TCP by default does not support 0-RTT session resumption. Not sure what "defaults" for TCP might even be. The point that this paragraph seems to be trying to make is that falling back might result in some degradation of performance. The same paragraph is also saying that if you can't guarantee some level of security, then you SHOULD fail: Moreover, while encryption (in this case TLS) is inseparable integrated with QUIC, TLS negotiation over TCP can be blocked. In case it is RECOMMENDED to abort the connection I'm not sure why it's only a SHOULD though. I'm fairly sure that most clients will treat this as fatal already. This section doesn't need to be hopeful, or lobby for particular changes. We can use the mailing list for that. ## Section 3 (0-RTT) 0-RTT is more than one packet, contrary to what this text implies by talking about the "first packet" (note that the first packet is the ClientHello, which can be replayed ad nauseum to no ill effect). The discussion of loss here suggests a misunderstanding of the problem. The risk here is that the 0-RTT data can be replayed to a server on **a different connection** and - absent any application-layer means of detecting this - could be processed twice. Loss and retransmission of these packets is benign. Mark Nottingham talks about the relevance of idempotency at the HTTP layer and its relevance to this subject. I suggest that you read draft-nottingham-httpbis-retry-01. I don't think that you need to change the view here, though you might like to change to using some other terminology (replay protection, for instance). ## Section 4 (Multiplexing) We should probably spend a lot more time discussing the virtues of having multiple connections and whether it is possible to obtain different treatment for packets on the same flow. The editor's note is speculative and can be removed. ## Section 5 (Prioritization) The second paragraph here is speculative and can be removed. ## Section 8 (Versioning) I think that the key point to make here is that unlike other transport protocols, QUIC includes version negotiation. I like that you point out that very little is guaranteed to be stable between versions. Making a special point about TLS isn't that interesting and I would remove that. # Manageability This draft is obviously a lot further behind. It's also obviously scrambling to keep up, since it's much more exposed to some of the recent changes in the transport doc. I think that it is generally the right level of information to have. There are a few errors and omissions, but frankly - given where we are at - I'm surprised that this has tracked the drafts so well. ## what can network management learn from looking at QUIC I think that this needs to be clearer about the distinction between *this* version of QUIC and the version-agnostic parts of QUIC. The increment between the two is small, but relevant. The description of key phase is incorrect. It has nothing to do with 0-RTT (though 0-RTT once affected it, it doesn't now). It is for working out which key to use for the packet. The fact that a connection ID might change is a little under-emphasized. Admitted, the -transport draft doesn't actually define how this works, so maybe that can be added when we build that function. In Section 3.1: 0-RTT connection establishment, however, provides no particular heuristic for differentiation from random background traffic at this time. This is incorrect. The client still sends a ClientHello, which is in the clear. The fact that other packets might be sent and that there might be loss and reordering is relevant here though and probably needs to be called out. Those packets will look like random noise, and the temptation will be to just drop them, after all, I suspect that many servers will do the same. But there's a risk there. Similarly, this is incorrect: RTT can only be measured at connection establishment time, and only when 1-RTT establishment is used. We closed #185. (Section 3.3) In Section 3.3, this is incorrect, except under certain conditions: If the QUIC handshake was not observed by the defense system, the connection ID can be used as a confirmation signal as per [I-D.trammell-plus-statefulness]. This is (currently) only true in the following cases: 1. the server uses version negotiation 2. the server uses HelloRetryRequest (a stateless reject) 3. the server uses the client-selected connection ID (though I wouldn't want to rely on that) 4. the connection ID is sent in both directions (Google servers routinely avoid sending a connection ID) Section 3.3 also eventually needs a discussion of the impact of connection migration when it is combined with a change in connection ID. (Again, we don't have that feature now, so the omission is clearly not a problem now.) The stateful nature of the connection is not visible to the path in that case. In particular, this seems to be highly speculative: However, it is questionable if connection migrations needs to be supported in a DDOS attack or if a defense system might simply rely on the fast resumption mechanism provided by QUIC ## what can network management do to affect QUIC I think that the effect of dropping packets needs to be explored more. This is probably the only tool a network has (aside from perhaps a public reset), but it's a pretty powerful one. We'll know more when more is said about congestion control, of course. If we find that authenticated public resets aren't a strict requirement, that will need to be added. I don't know if you want to discuss how PMTUD might react to signals from a network, or whether networks really care about using MTU as a management tool. On 13 March 2017 at 21:58, Mirja K=C3=BChlewind wrote: > Hi all, > > as some of you have probably already noticed that we submitted two new dr= afts > draft-kuehlewind-quic-manageability-00 and > draft-kuehlewind-quic-applicability-00 > which are replacements for draft-kuehlewind-quic-appman as discussed in T= okyo. > > Beside the split we also added a little more content but given that the p= rotocol is still very much in change, there are still quite a few editor no= tes or incomplete sections. Still we=E2=80=99d be very happy about feedback= and additional input from others and are also still looking for additional= authors! > > See you in Chicago! > Mirja and Brian > > >> Anfang der weitergeleiteten Nachricht: >> >> Von: internet-drafts@ietf.org >> Betreff: New Version Notification for draft-kuehlewind-quic-manageabilit= y-00.txt >> Datum: 9. M=C3=A4rz 2017 um 12:12:51 MEZ >> An: "Mirja Kuehlewind" , "Brian Trammel= l" , "Dan Druta" , "Mirja K=C3=BChlewind"= >> >> >> A new version of I-D, draft-kuehlewind-quic-manageability-00.txt >> has been successfully submitted by Mirja Kuehlewind and posted to the >> IETF repository. >> >> Name: draft-kuehlewind-quic-manageability >> Revision: 00 >> Title: Manageability of the QUIC Transport Protocol >> Document date: 2017-03-09 >> Group: Individual Submission >> Pages: 10 >> URL: https://www.ietf.org/internet-drafts/draft-kuehlewind-qu= ic-manageability-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-m= anageability/ >> Htmlized: https://tools.ietf.org/html/draft-kuehlewind-quic-manage= ability-00 >> >> >> Abstract: >> This document discusses manageability of the QUIC transport protocol, >> focusing on caveats impacting network operations involving QUIC >> traffic. Its intended audience is network operators, as well as >> content providers that rely on the use of QUIC-aware middleboxes, >> e.g. for load balancing. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> Anfang der weitergeleiteten Nachricht: >> >> Von: internet-drafts@ietf.org >> Betreff: New Version Notification for draft-kuehlewind-quic-applicabilit= y-00.txt >> Datum: 8. M=C3=A4rz 2017 um 16:30:57 MEZ >> An: "Mirja Kuehlewind" , "Brian Trammel= l" , "Mirja K=C3=BChlewind" >> >> >> A new version of I-D, draft-kuehlewind-quic-applicability-00.txt >> has been successfully submitted by Brian Trammell and posted to the >> IETF repository. >> >> Name: draft-kuehlewind-quic-applicability >> Revision: 00 >> Title: Applicability of the QUIC Transport Protocol >> Document date: 2017-03-08 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/internet-drafts/draft-kuehlewind-qu= ic-applicability-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-a= pplicability/ >> Htmlized: https://tools.ietf.org/html/draft-kuehlewind-quic-applic= ability-00 >> >> >> Abstract: >> This document discusses the applicability of the QUIC transport >> protocol, focusing on caveats impacting application protocol >> development and deployment over QUIC. Its intended audience is >> designers of application protocol mappings to QUIC, and implementors >> of these application protocols. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > From nobody Wed Mar 15 23:05:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5291243F6 for ; Wed, 15 Mar 2017 23:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 83GbBLIjV96r for ; Wed, 15 Mar 2017 23:05:28 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525BF1243F3 for ; Wed, 15 Mar 2017 23:05:28 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id u30so20607335uau.0 for ; Wed, 15 Mar 2017 23:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jn7CyktJSmWSanywQlFig0dwVY+XwGXSSJozgE1phY4=; b=SSjaXASLK9M5WbXujfiXxpPlCNMlTbjouci86Yc04tjzmm8uSo7t+bm8O9MbjGWzWP blZKlHV95AB6IGIcsbmiWpwoMgh3pRuGihGwY2wndfmY2dlM3j8VoZX4eHcpGDFkNgC8 rG3YR3EtjP5WiHcUYSdOT9vUbtxuZJsuPbBUPdfF63bvtz2Y8/vqRAn4chw2lCEfVREs 6PqKizYUJeePltej5coDSqusQePxZ+MhHuqsVk1Dq+Cmtc266b5SUbPIwJ255wN4VJzC tJjVmqoeMBPNZkBSwmKcetrwp6b7KXV1Na1dQ0BvYPtFZjySJHRCxbbJqNyZaOpdUutQ apWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jn7CyktJSmWSanywQlFig0dwVY+XwGXSSJozgE1phY4=; b=YSOPFIGoXoJt3mxfvg05xgxAZTO7vr89yvgvm9Id2HqjX6Fm6U1BTMwLhN4X26E9sZ BhKH8tUq6Dz7xu1kavHPx42+1Ho/S3U+b6L8OomEPBtvbtuGJ9W8Yi5OU64rOpD/QN0r oFDXUqSsbIMKEqvqgupQvNmSCiuWx0Yv74aA11ksXd8Q2cjwVUV7gkKt8Zx9ULS9l9Gl DtonKEIe0LcqzAxZDQnk+fcI/1uHCot5utDuaPUm3LzPXfGupIf5CcdQtt72bx3jp328 Y5PlCBUshl7Mc9hc54CigQoC1SRKBQpSI4oYZmbTs6dELY7qJ9fZoTJ15A14hNtxKeC4 n0uQ== X-Gm-Message-State: AFeK/H10Sg3yFIMD/5oysPLqoQb+qSWqGxs5yAjY0ukqATj8FTA4EqIW3UsqCxetOs+cHNPAIACyeweLTAvRP09W X-Received: by 10.176.74.155 with SMTP id s27mr2127069uae.143.1489644327016; Wed, 15 Mar 2017 23:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Wed, 15 Mar 2017 23:05:26 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Mar 2017 23:05:26 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Cc: Martin Duke , Ian Swett , Ted Hardie , IETF QUIC WG , Lucas Clemente Content-Type: multipart/alternative; boundary=f403045ef654f462a4054ad2d806 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 06:05:31 -0000 --f403045ef654f462a4054ad2d806 Content-Type: text/plain; charset=UTF-8 I agree with what Martin (Thomson) said. The key thing to recognize is that QUIC streams are similar to TCP connections, but the QUIC connection is different --- it's a container. Applying TCP logic to QUIC streams makes sense, but the QUIC connection itself is a different beast that doesn't need to follow the logic of TCP connections. I have some thoughts on how to make QUIC connections seem more like containers, at least for connection close semantics. I'll try to write up something tomorrow. On Wed, Mar 15, 2017 at 8:48 PM, Martin Thomson wrote: > I don't think that "TCP-like" is the right benchmark here. That would > apply to streams, but not the entire session. > > Even in HTTP, your signal doesn't work in one direction. A server > generates streams in response to client streams. It can't say "I'm > done with creating streams, but you continue for now" without cutting > itself off from server push. You might not be sad about that, but > you'd have to admit that would be a subjective decision. > > Given that we're aiming for a general purpose protocol, we can't > guarantee that other applications will have clean transactional > semantics such that your signal will be actionable at the transport > layer. Only the application protocol knows when it is "done", so any > signal of imminent shutdown is going to be up to them. What would a > generic shutdown() do? You can't just close all open streams where > they stand and hope that the application protocol will be happy. > > The more I think about this problem, the more I am convinced that the > application needs to sort it out and then send a signal to the > transport. That signal would be "start a timer (like FIN_WAIT2), if > you don't see anything new in that time, discard state". HTTP would > do that after receiving its own "I'm done" signals on its connection > control stream and closing out any lingering streams and > retransmissions. The real signaling (a GOAWAY or analogous) would > have to be exchanged a long time before that. > > > On 16 March 2017 at 09:06, Martin Duke wrote: > > This doesn't match my perception of the contract between a TCP-like > > transport layer and applications that use it in a "clean close", but then > > neither does the existing bidirectional GOAWAY. A clean close should > > indicate to the app that all written data has been received, and the peer > > has successfully delivered all its intended data. > > > > What QUIC needs is a signal that says "I am done creating new streams > but am > > still willing to receive new ones". Although there ought to be > stream-level > > shutdown() calls in a future socket API, but a connection-level > shutdown() > > would send this signal and also FIN all remaining streams. After both > QUIC > > endpoints clean all this up at the transport layer, there is no need for > a > > further signal from the app. > > > > Forcing every app to create its own GOAWAY (or, in my vision, send-only > > GOAWAY) mechanism seems rather heavyweight if it is a common feature of a > > clean close. > > > > On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar wrote: > >> > >> After chatting with Martin offline, it's growing on me as well. The key > >> insights in my mind are: > >> > >> 1. It's preferable for each endpoint to indicate the streams it is > >> closing, to avoid requiring upper-layer retries of new streams in > flight. > >> > >> 2. The semantics of stream creation are different for different apps. > HTTP > >> generally has the client creating a stream and the server responds on > the > >> same stream. A different application can have very different > client-server > >> interactions. For instance, a client creates a stream which requires a a > >> server to create multiple streams in response, which in turn require > further > >> client stream creations. In this case, QUIC has no idea what the "last" > >> stream ought to be, and this needs to be indicated by the application. > >> > >> 3. Since in the general case the app protocol is expected to be involved > >> in figuring out what graceful close looks like, it makes sense to > define it > >> per app. In other words, make it part of the app mapping to QUIC. For > HTTP, > >> this would be a GOAWAY frame on Stream 3. Once all streams are closed, > HTTP > >> closes Stream 3. > >> > >> 4. Graceful close by the app means that the QUIC connection can > >> immediately go into TIME_WAIT on a connection close from the app. > >> > >> It is a clean separation of concerns for sure. I'd like to ruminate on > >> this a bit, since sometimes that helps. > >> > >> This seems like good fodder for Chicago. > >> > >> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett wrote: > >>> > >>> After thinking about it more, if no one else has objections to "Make > >>> every application implement their own graceful close if they need it > and > >>> only provide a way to kill the connection immediately.", I'm fine with > it as > >>> well. > >>> > >>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson < > martin.thomson@gmail.com> > >>> wrote: > >>>> > >>>> On 8 March 2017 at 03:58, Ted Hardie wrote: > >>>> > > >>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson > >>>> > > >>>> > wrote: > >>>> >> > >>>> >> I think that both are likely to run afoul of a simple problem in > >>>> >> HTTP: > >>>> >> the control stream (stream 3) can't be closed. > >>>> >> > >>>> > I don't think that's actually a problem with what I suggested. It > >>>> > simply > >>>> > means that for the HTTP mapping, the defined behavior is to send > >>>> > FIN_COMPLETE after all open requests and pushes complete. If it > >>>> > arrives > >>>> > before then, you'd have to treat it as a protocol error for the > >>>> > mapping. > >>>> > What I'm trying to avoid is baking in the requirement that > >>>> > FIN_COMPLETE (or > >>>> > its moral equivalent) always occur then, since it will make using > >>>> > other > >>>> > types > >>>> > >>>> Sure. I had inferred that you were doing this entirely at the > >>>> transport layer, which doesn't really allow you to do that. > >>> > >>> > >> > > > --f403045ef654f462a4054ad2d806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with what Martin (Thomson) said. The key thing to = recognize is that QUIC streams are similar to TCP connections, but the QUIC= connection is different --- it's a container. Applying TCP logic to QU= IC streams makes sense, but the QUIC connection itself is a different beast= that doesn't need to follow the logic of TCP connections.

I have some thoughts on how to make QUIC connections seem more like = containers, at least for connection close semantics. I'll try to write = up something tomorrow.

On Wed, Mar 15, 2017 at 8:48 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I don't think that "TCP-like" is the right benchmark he= re.=C2=A0 That would
apply to streams, but not the entire session.

Even in HTTP, your signal doesn't work in one direction.=C2=A0 A server=
generates streams in response to client streams.=C2=A0 It can't say &qu= ot;I'm
done with creating streams, but you continue for now" without cutting<= br> itself off from server push.=C2=A0 You might not be sad about that, but
you'd have to admit that would be a subjective decision.

Given that we're aiming for a general purpose protocol, we can't guarantee that other applications will have clean transactional
semantics such that your signal will be actionable at the transport
layer.=C2=A0 Only the application protocol knows when it is "done"= ;, so any
signal of imminent shutdown is going to be up to them.=C2=A0 What would a generic shutdown() do?=C2=A0 You can't just close all open streams wher= e
they stand and hope that the application protocol will be happy.

The more I think about this problem, the more I am convinced that the
application needs to sort it out and then send a signal to the
transport.=C2=A0 That signal would be "start a timer (like FIN_WAIT2),= if
you don't see anything new in that time, discard state".=C2=A0 HTT= P would
do that after receiving its own "I'm done" signals on its con= nection
control stream and closing out any lingering streams and
retransmissions.=C2=A0 The real signaling (a GOAWAY or analogous) would
have to be exchanged a long time before that.


On 16 March 2017 at 09:06, Martin Duke <martin.h.duke@gmail.com> wrote:
> This doesn't match my perception of the contract between a TCP-lik= e
> transport layer and applications that use it in a "clean close&qu= ot;, but then
> neither does the existing bidirectional GOAWAY. A clean close should > indicate to the app that all written data has been received, and the p= eer
> has successfully delivered all its intended data.
>
> What QUIC needs is a signal that says "I am done creating new str= eams but am
> still willing to receive new ones". Although there ought to be st= ream-level
> shutdown() calls in a future socket API, but a connection-level shutdo= wn()
> would send this signal and also FIN all remaining streams. After both = QUIC
> endpoints clean all this up at the transport layer, there is no need f= or a
> further signal from the app.
>
> Forcing every app to create its own GOAWAY (or, in my vision, send-onl= y
> GOAWAY) mechanism seems rather heavyweight if it is a common feature o= f a
> clean close.
>
> On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar <jri@google.com> wrote:
>>
>> After chatting with Martin offline, it's growing on me as well= . The key
>> insights in my mind are:
>>
>> 1. It's preferable for each endpoint to indicate the streams i= t is
>> closing, to avoid requiring upper-layer retries of new streams in = flight.
>>
>> 2. The semantics of stream creation are different for different ap= ps. HTTP
>> generally has the client creating a stream and the server responds= on the
>> same stream. A different application can have very different clien= t-server
>> interactions. For instance, a client creates a stream which requir= es a a
>> server to create multiple streams in response, which in turn requi= re further
>> client stream creations. In this case, QUIC has no idea what the &= quot;last"
>> stream ought to be, and this needs to be indicated by the applicat= ion.
>>
>> 3. Since in the general case the app protocol is expected to be in= volved
>> in figuring out what graceful close looks like, it makes sense to = define it
>> per app. In other words, make it part of the app mapping to QUIC. = For HTTP,
>> this would be a GOAWAY frame on Stream 3. Once all streams are clo= sed, HTTP
>> closes Stream 3.
>>
>> 4. Graceful close by the app means that the QUIC connection can >> immediately go into TIME_WAIT on a connection close from the app.<= br> >>
>> It is a clean separation of concerns for sure. I'd like to rum= inate on
>> this a bit, since sometimes that helps.
>>
>> This seems like good fodder for Chicago.
>>
>> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett <ianswett@google.com> wrote:
>>>
>>> After thinking about it more, if no one else has objections to= "Make
>>> every application implement their own graceful close if they n= eed it and
>>> only provide a way to kill the connection immediately.", = I'm fine with it as
>>> well.
>>>
>>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson <martin.thomson@gmail.com>
>>> wrote:
>>>>
>>>> On 8 March 2017 at 03:58, Ted Hardie <ted.ietf@gmail.com> wrote:
>>>> >
>>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson
>>>> > <marti= n.thomson@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I think that both are likely to run afoul of a si= mple problem in
>>>> >> HTTP:
>>>> >> the control stream (stream 3) can't be closed= .
>>>> >>
>>>> > I don't think that's actually a problem with = what I suggested.=C2=A0 It
>>>> > simply
>>>> > means that for the HTTP mapping, the defined behavior= is to send
>>>> > FIN_COMPLETE after all open requests and pushes compl= ete.=C2=A0 If it
>>>> > arrives
>>>> > before then, you'd have to treat it as a protocol= error for the
>>>> > mapping.
>>>> > What I'm trying to avoid is baking in the require= ment that
>>>> > FIN_COMPLETE (or
>>>> > its moral equivalent) always occur then, since it wil= l make using
>>>> > other
>>>> > types
>>>>
>>>> Sure.=C2=A0 I had inferred that you were doing this entire= ly at the
>>>> transport layer, which doesn't really allow you to do = that.
>>>
>>>
>>
>

--f403045ef654f462a4054ad2d806-- From nobody Thu Mar 16 14:05:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A84129A8E for ; Thu, 16 Mar 2017 14:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 XrgAgTLMbP5B for ; Thu, 16 Mar 2017 14:05:03 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 C8932127011 for ; Thu, 16 Mar 2017 14:05:02 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id i1so70783046ota.3 for ; Thu, 16 Mar 2017 14:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dkwzv1mozwuQci7wD4wgOxjw6M0lVuvjZfca6dd5Kz8=; b=k3zbryMNs3lYNvyRVQEhdIG1mD5ExMky8DV6d9nbpZnVFV9CfrL6w0qxpLMCkQQ1Lm FtLpb45XzM35690tRq5URpbjRLLSGZnki0Htp0HHYNl9a1aqn5R+S2wYDzNXw5sU5E1g 4clJQ6a13rR2U8kAyRXq9fpksRXe64BKebphBB/M3Edcd0hls7zntC9ymbpDKZWidsJI 7Foes0sI/n4+Ix3Tl6nPmTlItcl9xbhlB3wwsY+0fJwOrkalJIO6er5t5AkEhRS77x3L HTcnJGHpY4M5rnqVLrukEvE+k+sYlxEIlTWdEWsBjL6dty0aKEN3UnY7T2Lchcu+fcov WWQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dkwzv1mozwuQci7wD4wgOxjw6M0lVuvjZfca6dd5Kz8=; b=XcPCpZMbrOpK/pFGkwPr+GwA428XMZD8VeMrrza4WVFItf+NiJntskMsoEZjFh45eo R1BSkVme19XaGiwn7GQ/S+mhQQdmHNv9MNntvYCqwATw/Y+z8/aEvt9Y5xHE85ZwEGG7 oRom9ZfaOCgC0O7Xk9C0NY+EPa0yzFsosL+TLaX57lgTlBeTHOxPSvKQy4YaBZvCPdMt yFxWpRG/WUDvQSEoYSwVR9ZZYdF6bv5sPyDzWoJRNvXGeYh0owW1XfwTDMkFXb/oa01a Z6+g+1glyyXdTwJroa0G248WTQ2d8zrEbKExTJe2pxKmJ3coeOz8FzZw66oCxMPDcGtg JO2A== X-Gm-Message-State: AFeK/H3rLUISIQu1q0UDu3r/SkDUGxIYAFMJbZtpSyKlBC3+2a1Evp6p720hM2Cgh3/gYLKAyNEx0zEPR4PTCQ== X-Received: by 10.157.34.84 with SMTP id o78mr5450402ota.144.1489698302199; Thu, 16 Mar 2017 14:05:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Thu, 16 Mar 2017 14:05:01 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Thu, 16 Mar 2017 14:05:01 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Jana Iyengar Cc: Martin Thomson , Ian Swett , Ted Hardie , IETF QUIC WG , Lucas Clemente Content-Type: multipart/alternative; boundary=001a113c1bec200e83054adf6ae0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 21:05:05 -0000 --001a113c1bec200e83054adf6ae0 Content-Type: text/plain; charset=UTF-8 Alright, I think I'm convinced we can get rid of GOAWAY entirely. I would still like to have two types of application close (in terms of the application API), one that is not graceful (immediate PUBLIC_RESET) and one that is graceful (as you describe, "wait for X sec to make sure there are no non-PING, non-PADDING frames") that leads to a CONNECTION_CLOSE (or, as I would argue in #353, a delayed Public Reset) On Wed, Mar 15, 2017 at 11:05 PM, Jana Iyengar wrote: > I agree with what Martin (Thomson) said. The key thing to recognize is > that QUIC streams are similar to TCP connections, but the QUIC connection > is different --- it's a container. Applying TCP logic to QUIC streams makes > sense, but the QUIC connection itself is a different beast that doesn't > need to follow the logic of TCP connections. > > I have some thoughts on how to make QUIC connections seem more like > containers, at least for connection close semantics. I'll try to write up > something tomorrow. > > On Wed, Mar 15, 2017 at 8:48 PM, Martin Thomson > wrote: > >> I don't think that "TCP-like" is the right benchmark here. That would >> apply to streams, but not the entire session. >> >> Even in HTTP, your signal doesn't work in one direction. A server >> generates streams in response to client streams. It can't say "I'm >> done with creating streams, but you continue for now" without cutting >> itself off from server push. You might not be sad about that, but >> you'd have to admit that would be a subjective decision. >> >> Given that we're aiming for a general purpose protocol, we can't >> guarantee that other applications will have clean transactional >> semantics such that your signal will be actionable at the transport >> layer. Only the application protocol knows when it is "done", so any >> signal of imminent shutdown is going to be up to them. What would a >> generic shutdown() do? You can't just close all open streams where >> they stand and hope that the application protocol will be happy. >> >> The more I think about this problem, the more I am convinced that the >> application needs to sort it out and then send a signal to the >> transport. That signal would be "start a timer (like FIN_WAIT2), if >> you don't see anything new in that time, discard state". HTTP would >> do that after receiving its own "I'm done" signals on its connection >> control stream and closing out any lingering streams and >> retransmissions. The real signaling (a GOAWAY or analogous) would >> have to be exchanged a long time before that. >> >> >> On 16 March 2017 at 09:06, Martin Duke wrote: >> > This doesn't match my perception of the contract between a TCP-like >> > transport layer and applications that use it in a "clean close", but >> then >> > neither does the existing bidirectional GOAWAY. A clean close should >> > indicate to the app that all written data has been received, and the >> peer >> > has successfully delivered all its intended data. >> > >> > What QUIC needs is a signal that says "I am done creating new streams >> but am >> > still willing to receive new ones". Although there ought to be >> stream-level >> > shutdown() calls in a future socket API, but a connection-level >> shutdown() >> > would send this signal and also FIN all remaining streams. After both >> QUIC >> > endpoints clean all this up at the transport layer, there is no need >> for a >> > further signal from the app. >> > >> > Forcing every app to create its own GOAWAY (or, in my vision, send-only >> > GOAWAY) mechanism seems rather heavyweight if it is a common feature of >> a >> > clean close. >> > >> > On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar wrote: >> >> >> >> After chatting with Martin offline, it's growing on me as well. The key >> >> insights in my mind are: >> >> >> >> 1. It's preferable for each endpoint to indicate the streams it is >> >> closing, to avoid requiring upper-layer retries of new streams in >> flight. >> >> >> >> 2. The semantics of stream creation are different for different apps. >> HTTP >> >> generally has the client creating a stream and the server responds on >> the >> >> same stream. A different application can have very different >> client-server >> >> interactions. For instance, a client creates a stream which requires a >> a >> >> server to create multiple streams in response, which in turn require >> further >> >> client stream creations. In this case, QUIC has no idea what the "last" >> >> stream ought to be, and this needs to be indicated by the application. >> >> >> >> 3. Since in the general case the app protocol is expected to be >> involved >> >> in figuring out what graceful close looks like, it makes sense to >> define it >> >> per app. In other words, make it part of the app mapping to QUIC. For >> HTTP, >> >> this would be a GOAWAY frame on Stream 3. Once all streams are closed, >> HTTP >> >> closes Stream 3. >> >> >> >> 4. Graceful close by the app means that the QUIC connection can >> >> immediately go into TIME_WAIT on a connection close from the app. >> >> >> >> It is a clean separation of concerns for sure. I'd like to ruminate on >> >> this a bit, since sometimes that helps. >> >> >> >> This seems like good fodder for Chicago. >> >> >> >> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett wrote: >> >>> >> >>> After thinking about it more, if no one else has objections to "Make >> >>> every application implement their own graceful close if they need it >> and >> >>> only provide a way to kill the connection immediately.", I'm fine >> with it as >> >>> well. >> >>> >> >>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson < >> martin.thomson@gmail.com> >> >>> wrote: >> >>>> >> >>>> On 8 March 2017 at 03:58, Ted Hardie wrote: >> >>>> > >> >>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson >> >>>> > >> >>>> > wrote: >> >>>> >> >> >>>> >> I think that both are likely to run afoul of a simple problem in >> >>>> >> HTTP: >> >>>> >> the control stream (stream 3) can't be closed. >> >>>> >> >> >>>> > I don't think that's actually a problem with what I suggested. It >> >>>> > simply >> >>>> > means that for the HTTP mapping, the defined behavior is to send >> >>>> > FIN_COMPLETE after all open requests and pushes complete. If it >> >>>> > arrives >> >>>> > before then, you'd have to treat it as a protocol error for the >> >>>> > mapping. >> >>>> > What I'm trying to avoid is baking in the requirement that >> >>>> > FIN_COMPLETE (or >> >>>> > its moral equivalent) always occur then, since it will make using >> >>>> > other >> >>>> > types >> >>>> >> >>>> Sure. I had inferred that you were doing this entirely at the >> >>>> transport layer, which doesn't really allow you to do that. >> >>> >> >>> >> >> >> > >> > > --001a113c1bec200e83054adf6ae0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alright, I think I'm convinced we can get rid of GOAWA= Y entirely.

I would still like to have two types of appl= ication close (in terms of the application API), one that is not graceful (= immediate PUBLIC_RESET) and one that is graceful (as you describe, "wa= it for X sec to make sure there are no non-PING, non-PADDING frames") = that leads to a CONNECTION_CLOSE (or, as I would argue in #353, a delayed P= ublic Reset)

On Wed, Mar 15, 2017 at 11:05 PM, Jana Iyengar <= ;jri@google.com>= wrote:
I agree w= ith what Martin (Thomson) said. The key thing to recognize is that QUIC str= eams are similar to TCP connections, but the QUIC connection is different -= -- it's a container. Applying TCP logic to QUIC streams makes sense, bu= t the QUIC connection itself is a different beast that doesn't need to = follow the logic of TCP connections.

I have some thought= s on how to make QUIC connections seem more like containers, at least for c= onnection close semantics. I'll try to write up something tomorrow.
=
On Wed, Mar 15, 2017 at 8:48 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
I don't think that "TCP-like" is the right= benchmark here.=C2=A0 That would
apply to streams, but not the entire session.

Even in HTTP, your signal doesn't work in one direction.=C2=A0 A server=
generates streams in response to client streams.=C2=A0 It can't say &qu= ot;I'm
done with creating streams, but you continue for now" without cutting<= br> itself off from server push.=C2=A0 You might not be sad about that, but
you'd have to admit that would be a subjective decision.

Given that we're aiming for a general purpose protocol, we can't guarantee that other applications will have clean transactional
semantics such that your signal will be actionable at the transport
layer.=C2=A0 Only the application protocol knows when it is "done"= ;, so any
signal of imminent shutdown is going to be up to them.=C2=A0 What would a generic shutdown() do?=C2=A0 You can't just close all open streams wher= e
they stand and hope that the application protocol will be happy.

The more I think about this problem, the more I am convinced that the
application needs to sort it out and then send a signal to the
transport.=C2=A0 That signal would be "start a timer (like FIN_WAIT2),= if
you don't see anything new in that time, discard state".=C2=A0 HTT= P would
do that after receiving its own "I'm done" signals on its con= nection
control stream and closing out any lingering streams and
retransmissions.=C2=A0 The real signaling (a GOAWAY or analogous) would
have to be exchanged a long time before that.


On 16 March 2017 at 09:06, Martin Duke <martin.h.duke@gmail.com> wrote:
> This doesn't match my perception of the contract between a TCP-lik= e
> transport layer and applications that use it in a "clean close&qu= ot;, but then
> neither does the existing bidirectional GOAWAY. A clean close should > indicate to the app that all written data has been received, and the p= eer
> has successfully delivered all its intended data.
>
> What QUIC needs is a signal that says "I am done creating new str= eams but am
> still willing to receive new ones". Although there ought to be st= ream-level
> shutdown() calls in a future socket API, but a connection-level shutdo= wn()
> would send this signal and also FIN all remaining streams. After both = QUIC
> endpoints clean all this up at the transport layer, there is no need f= or a
> further signal from the app.
>
> Forcing every app to create its own GOAWAY (or, in my vision, send-onl= y
> GOAWAY) mechanism seems rather heavyweight if it is a common feature o= f a
> clean close.
>
> On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar <jri@google.com> wrote:
>>
>> After chatting with Martin offline, it's growing on me as well= . The key
>> insights in my mind are:
>>
>> 1. It's preferable for each endpoint to indicate the streams i= t is
>> closing, to avoid requiring upper-layer retries of new streams in = flight.
>>
>> 2. The semantics of stream creation are different for different ap= ps. HTTP
>> generally has the client creating a stream and the server responds= on the
>> same stream. A different application can have very different clien= t-server
>> interactions. For instance, a client creates a stream which requir= es a a
>> server to create multiple streams in response, which in turn requi= re further
>> client stream creations. In this case, QUIC has no idea what the &= quot;last"
>> stream ought to be, and this needs to be indicated by the applicat= ion.
>>
>> 3. Since in the general case the app protocol is expected to be in= volved
>> in figuring out what graceful close looks like, it makes sense to = define it
>> per app. In other words, make it part of the app mapping to QUIC. = For HTTP,
>> this would be a GOAWAY frame on Stream 3. Once all streams are clo= sed, HTTP
>> closes Stream 3.
>>
>> 4. Graceful close by the app means that the QUIC connection can >> immediately go into TIME_WAIT on a connection close from the app.<= br> >>
>> It is a clean separation of concerns for sure. I'd like to rum= inate on
>> this a bit, since sometimes that helps.
>>
>> This seems like good fodder for Chicago.
>>
>> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett <ianswett@google.com> wrote:
>>>
>>> After thinking about it more, if no one else has objections to= "Make
>>> every application implement their own graceful close if they n= eed it and
>>> only provide a way to kill the connection immediately.", = I'm fine with it as
>>> well.
>>>
>>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson <martin.thomson@gmail.com= >
>>> wrote:
>>>>
>>>> On 8 March 2017 at 03:58, Ted Hardie <ted.ietf@gmail.com> wrote: >>>> >
>>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson
>>>> > <martin.thomson@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I think that both are likely to run afoul of a si= mple problem in
>>>> >> HTTP:
>>>> >> the control stream (stream 3) can't be closed= .
>>>> >>
>>>> > I don't think that's actually a problem with = what I suggested.=C2=A0 It
>>>> > simply
>>>> > means that for the HTTP mapping, the defined behavior= is to send
>>>> > FIN_COMPLETE after all open requests and pushes compl= ete.=C2=A0 If it
>>>> > arrives
>>>> > before then, you'd have to treat it as a protocol= error for the
>>>> > mapping.
>>>> > What I'm trying to avoid is baking in the require= ment that
>>>> > FIN_COMPLETE (or
>>>> > its moral equivalent) always occur then, since it wil= l make using
>>>> > other
>>>> > types
>>>>
>>>> Sure.=C2=A0 I had inferred that you were doing this entire= ly at the
>>>> transport layer, which doesn't really allow you to do = that.
>>>
>>>
>>
>


--001a113c1bec200e83054adf6ae0-- From nobody Thu Mar 16 14:33:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E92129AB0 for ; Thu, 16 Mar 2017 14:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm3yKhXdCddS for ; Thu, 16 Mar 2017 14:33:00 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E9F129A73 for ; Thu, 16 Mar 2017 14:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yOCrOpWzcWTctndGe+v9wkO9zPiR6aJL3w3kvaPM2rQ=; b=l0RrkbQd6BwDmbu3xTqhgQ27ZLRGvKK6ozsq6kONZdC93TobKA17N9fWxaomPXkIYU1MQVaqayqzWRQbkDuV5UFpohWSFMzyrMZWfqIv/2PUz2PYBf97882+iGTLZ0VUZaqAQnZeON0Z5d22kiXai+i50Ak6LZ+ZbvfjLBc+WMw= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 16 Mar 2017 21:32:56 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 16 Mar 2017 21:32:56 +0000 From: Mike Bishop To: Martin Duke , Jana Iyengar CC: Lucas Clemente , Ian Swett , IETF QUIC WG , Martin Thomson , "Ted Hardie" Subject: RE: Move GOAWAY to HTTP draft Thread-Topic: Move GOAWAY to HTTP draft Thread-Index: AQHSlf4x+1FK6xgGX0mOGjIclw5osqGG1dGAgAAEPYCAACiUsIAAHj8AgACw04CAAJjegIAABhWAgAAGbACAAALxAIABIi8AgABqpQCAADtHAIAABrcAgAw79QCAAF+RgIAAJkMAgAD7WICAAAMe8A== Date: Thu, 16 Mar 2017 21:32:56 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::5b1] x-ms-office365-filtering-correlation-id: 1748101a-ee78-40b2-9737-08d46cb402fa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:w1iqS5Ucvn9kRkR+akGWwUsjaj87rQbloErZQqxSifMFzdoUG0qnwm8QrvMpk17hljKYshs4u2wV20Rf1BOfZHt1ySROFK1evMv8ANtIMU8pbKTgsluA9UnhRZbYsp8HRIg0XeDaZEEb+qIjpHYIB70cac4YNkoA4ugfmwlWQrlolNb2URqXYk0uKRANHLTUl59V/pJbmG1ALoLei7jqoVWq8pISWGtze79iGx+AUyR7mDMgVpxuCbeakyZApbmozL0gJsjo7TXuZaBTqN5d03FvgzUTMoT5m4nq2KvZVXxawhhBGAEYwykjPRs6uaY0K6dlt4hUWjvIkzrE0+fuKMTcD1W5543tuOhYL5XGFZ0= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(211936372134217)(21748063052155)(148717330147763); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(51444003)(24454002)(377454003)(93886004)(9686003)(33656002)(5005710100001)(2906002)(81166006)(236005)(25786008)(122556002)(38730400002)(86612001)(74316002)(6306002)(6246003)(77096006)(790700001)(6436002)(6506006)(6116002)(39060400002)(7736002)(102836003)(86362001)(3660700001)(3280700002)(229853002)(55016002)(5660300001)(54906002)(54896002)(7696004)(53936002)(99286003)(2950100002)(10290500002)(19609705001)(76176999)(2900100001)(10090500001)(8936002)(189998001)(4326008)(8676002)(8990500004)(50986999)(54356999)(53546008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27084228761DBE525A17937A87260BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 21:32:56.3629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 21:33:04 -0000 --_000_BN6PR03MB27084228761DBE525A17937A87260BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSBhbiBlbmRwb2ludCBsZXZlbCwgSeKAmW0gY29udGVudCB3aXRoIHRoZSBtb2RlbCBvZjoN Cg0KICAqICAgQSBmcmFtZSBpcyDigJxjb25maXJtZWQgZGVsaXZlcmVk4oCdIHdoZW4gYW4gQUNL IGlzIHJlY2VpdmVkIHdoaWNoIHNheXMgdGhlIGEgcGFja2V0IGNvbnRhaW5pbmcgdGhlIGZyYW1l IHdhcyByZWNlaXZlZCBieSB0aGUgcGVlcg0KICAqICAgQSBzdHJlYW0gaXMg4oCcY29uZmlybWVk IGNsb3NlZOKAnSB3aGVuIGFsbCBkYXRhLCBvciBhIFJTVF9TVFJFQU0sIGhhcyBiZWVuIGNvbmZp cm1lZCBkZWxpdmVyZWQgdG8gdGhlIGZhciBzaWRlIGFuZCB3aGVuIGFsbCBkYXRhIG9yIGEgUlNU X1NUUkVBTSBoYXMgYmVlbiByZWNlaXZlZCBhbmQgdGhlIEFDSyBpcyBjb25maXJtZWQgZGVsaXZl cmVkDQogICogICBPbmNlIGEgc2h1dGRvd24gaGFzIGJlZW4gdHJpZ2dlcmVkLCBhIGNvbm5lY3Rp b24gY2xvc2VzIHNpbGVudGx5IHdoZW4gYWxsIHN0cmVhbXMgYXJlIGVpdGhlciBjb25maXJtZWQg Y2xvc2VkIG9yIGlkbGUuDQoNClRoZXJlIGlzIGEgc2xpZ2h0IHJhY2UsIGluIHRoYXQgYSBwZWVy LWluaXRpYXRlZCBzdHJlYW0gY291bGQgYmUgb3BlbmVkIGR1cmluZyB0aGUgc2h1dGRvd24gd2Fp dC4gIEFzIG90aGVycyBoYXZlIG5vdGVkLCB0aGF0IGNhbiBiZSBoYW5kbGVkIGF0IHRoZSBhcHAg bGF5ZXIgYnkgZ2l2aW5nIGEgcHJlLXNodXRkb3duIG5vdGlmaWNhdGlvbi4NCg0KSG93ZXZlciwg eW91IHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgZnJhbWUgaGFzIGJlZW4gZGVsaXZlcmVkLiAgVGhh dCBpbXBsaWVzIGhhdmluZyBhIHdheSBmb3IgdGhlIGFwcGxpY2F0aW9uIHRvIHdhaXQgZm9yIHRo ZSBBQ0sgb2YgYSBwYXJ0aWN1bGFyIHBpZWNlIG9mIHN0cmVhbSBkYXRhOyB0aGF04oCZcyBub3Qg c29tZXRoaW5nIHdlIGN1cnJlbnRseSByZXF1aXJlIHRoZSB0cmFuc3BvcnQgdG8gZXhwb3NlLCBh bmQgSeKAmWQgcHJlZmVyIG5vdCB0byBtYWtlIGl0IGEgbmV3IHJlcXVpcmVtZW50LiAgVGhlIGFw cGxpY2F0aW9uIGNvdWxkIGFsc28gYWRkIGFuIGFwcC1sZXZlbCBBQ0sgb2Ygc29tZSBraW5kLCBv ciAoZm9yIEhUVFApIHRoZSBjbG9zaW5nIG9mIHN0cmVhbSAzIGNvdWxkIGJlIGFuIGltcGxpY2l0 IEFDSy4NCg0KQW5kIHRoZSBvdGhlciBxdWVzdGlvbiwgd2hldGhlciB3ZSB3YW50IHRvIGV4cG9z ZSB0byB0aGUgcGF0aCB0aGF0IHRoZSBjb25uZWN0aW9uIGhhcyBkZWZpbml0aXZlbHkgZW5kZWQu DQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNYXJ0aW4gRHVrZQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE2LCAyMDE3IDI6MDUgUE0NClRv OiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPg0KQ2M6IEx1Y2FzIENsZW1lbnRlIDxsdWNh c0BsY2xlbWVudGUub3JnPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgSUVURiBR VUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT47IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBN b3ZlIEdPQVdBWSB0byBIVFRQIGRyYWZ0DQoNCkFscmlnaHQsIEkgdGhpbmsgSSdtIGNvbnZpbmNl ZCB3ZSBjYW4gZ2V0IHJpZCBvZiBHT0FXQVkgZW50aXJlbHkuDQoNCkkgd291bGQgc3RpbGwgbGlr ZSB0byBoYXZlIHR3byB0eXBlcyBvZiBhcHBsaWNhdGlvbiBjbG9zZSAoaW4gdGVybXMgb2YgdGhl IGFwcGxpY2F0aW9uIEFQSSksIG9uZSB0aGF0IGlzIG5vdCBncmFjZWZ1bCAoaW1tZWRpYXRlIFBV QkxJQ19SRVNFVCkgYW5kIG9uZSB0aGF0IGlzIGdyYWNlZnVsIChhcyB5b3UgZGVzY3JpYmUsICJ3 YWl0IGZvciBYIHNlYyB0byBtYWtlIHN1cmUgdGhlcmUgYXJlIG5vIG5vbi1QSU5HLCBub24tUEFE RElORyBmcmFtZXMiKSB0aGF0IGxlYWRzIHRvIGEgQ09OTkVDVElPTl9DTE9TRSAob3IsIGFzIEkg d291bGQgYXJndWUgaW4gIzM1MywgYSBkZWxheWVkIFB1YmxpYyBSZXNldCkNCg0KT24gV2VkLCBN YXIgMTUsIDIwMTcgYXQgMTE6MDUgUE0sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFp bHRvOmpyaUBnb29nbGUuY29tPj4gd3JvdGU6DQpJIGFncmVlIHdpdGggd2hhdCBNYXJ0aW4gKFRo b21zb24pIHNhaWQuIFRoZSBrZXkgdGhpbmcgdG8gcmVjb2duaXplIGlzIHRoYXQgUVVJQyBzdHJl YW1zIGFyZSBzaW1pbGFyIHRvIFRDUCBjb25uZWN0aW9ucywgYnV0IHRoZSBRVUlDIGNvbm5lY3Rp b24gaXMgZGlmZmVyZW50IC0tLSBpdCdzIGEgY29udGFpbmVyLiBBcHBseWluZyBUQ1AgbG9naWMg dG8gUVVJQyBzdHJlYW1zIG1ha2VzIHNlbnNlLCBidXQgdGhlIFFVSUMgY29ubmVjdGlvbiBpdHNl bGYgaXMgYSBkaWZmZXJlbnQgYmVhc3QgdGhhdCBkb2Vzbid0IG5lZWQgdG8gZm9sbG93IHRoZSBs b2dpYyBvZiBUQ1AgY29ubmVjdGlvbnMuDQoNCkkgaGF2ZSBzb21lIHRob3VnaHRzIG9uIGhvdyB0 byBtYWtlIFFVSUMgY29ubmVjdGlvbnMgc2VlbSBtb3JlIGxpa2UgY29udGFpbmVycywgYXQgbGVh c3QgZm9yIGNvbm5lY3Rpb24gY2xvc2Ugc2VtYW50aWNzLiBJJ2xsIHRyeSB0byB3cml0ZSB1cCBz b21ldGhpbmcgdG9tb3Jyb3cuDQoNCk9uIFdlZCwgTWFyIDE1LCAyMDE3IGF0IDg6NDggUE0sIE1h cnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KSSBkb24ndCB0aGluayB0aGF0ICJUQ1AtbGlrZSIgaXMg dGhlIHJpZ2h0IGJlbmNobWFyayBoZXJlLiAgVGhhdCB3b3VsZA0KYXBwbHkgdG8gc3RyZWFtcywg YnV0IG5vdCB0aGUgZW50aXJlIHNlc3Npb24uDQoNCkV2ZW4gaW4gSFRUUCwgeW91ciBzaWduYWwg ZG9lc24ndCB3b3JrIGluIG9uZSBkaXJlY3Rpb24uICBBIHNlcnZlcg0KZ2VuZXJhdGVzIHN0cmVh bXMgaW4gcmVzcG9uc2UgdG8gY2xpZW50IHN0cmVhbXMuICBJdCBjYW4ndCBzYXkgIkknbQ0KZG9u ZSB3aXRoIGNyZWF0aW5nIHN0cmVhbXMsIGJ1dCB5b3UgY29udGludWUgZm9yIG5vdyIgd2l0aG91 dCBjdXR0aW5nDQppdHNlbGYgb2ZmIGZyb20gc2VydmVyIHB1c2guICBZb3UgbWlnaHQgbm90IGJl IHNhZCBhYm91dCB0aGF0LCBidXQNCnlvdSdkIGhhdmUgdG8gYWRtaXQgdGhhdCB3b3VsZCBiZSBh IHN1YmplY3RpdmUgZGVjaXNpb24uDQoNCkdpdmVuIHRoYXQgd2UncmUgYWltaW5nIGZvciBhIGdl bmVyYWwgcHVycG9zZSBwcm90b2NvbCwgd2UgY2FuJ3QNCmd1YXJhbnRlZSB0aGF0IG90aGVyIGFw cGxpY2F0aW9ucyB3aWxsIGhhdmUgY2xlYW4gdHJhbnNhY3Rpb25hbA0Kc2VtYW50aWNzIHN1Y2gg dGhhdCB5b3VyIHNpZ25hbCB3aWxsIGJlIGFjdGlvbmFibGUgYXQgdGhlIHRyYW5zcG9ydA0KbGF5 ZXIuICBPbmx5IHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCBrbm93cyB3aGVuIGl0IGlzICJkb25l Iiwgc28gYW55DQpzaWduYWwgb2YgaW1taW5lbnQgc2h1dGRvd24gaXMgZ29pbmcgdG8gYmUgdXAg dG8gdGhlbS4gIFdoYXQgd291bGQgYQ0KZ2VuZXJpYyBzaHV0ZG93bigpIGRvPyAgWW91IGNhbid0 IGp1c3QgY2xvc2UgYWxsIG9wZW4gc3RyZWFtcyB3aGVyZQ0KdGhleSBzdGFuZCBhbmQgaG9wZSB0 aGF0IHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCB3aWxsIGJlIGhhcHB5Lg0KDQpUaGUgbW9yZSBJ IHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSwgdGhlIG1vcmUgSSBhbSBjb252aW5jZWQgdGhhdCB0 aGUNCmFwcGxpY2F0aW9uIG5lZWRzIHRvIHNvcnQgaXQgb3V0IGFuZCB0aGVuIHNlbmQgYSBzaWdu YWwgdG8gdGhlDQp0cmFuc3BvcnQuICBUaGF0IHNpZ25hbCB3b3VsZCBiZSAic3RhcnQgYSB0aW1l ciAobGlrZSBGSU5fV0FJVDIpLCBpZg0KeW91IGRvbid0IHNlZSBhbnl0aGluZyBuZXcgaW4gdGhh dCB0aW1lLCBkaXNjYXJkIHN0YXRlIi4gIEhUVFAgd291bGQNCmRvIHRoYXQgYWZ0ZXIgcmVjZWl2 aW5nIGl0cyBvd24gIkknbSBkb25lIiBzaWduYWxzIG9uIGl0cyBjb25uZWN0aW9uDQpjb250cm9s IHN0cmVhbSBhbmQgY2xvc2luZyBvdXQgYW55IGxpbmdlcmluZyBzdHJlYW1zIGFuZA0KcmV0cmFu c21pc3Npb25zLiAgVGhlIHJlYWwgc2lnbmFsaW5nIChhIEdPQVdBWSBvciBhbmFsb2dvdXMpIHdv dWxkDQpoYXZlIHRvIGJlIGV4Y2hhbmdlZCBhIGxvbmcgdGltZSBiZWZvcmUgdGhhdC4NCg0KDQpP biAxNiBNYXJjaCAyMDE3IGF0IDA5OjA2LCBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFp bC5jb208bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQo+IFRoaXMgZG9l c24ndCBtYXRjaCBteSBwZXJjZXB0aW9uIG9mIHRoZSBjb250cmFjdCBiZXR3ZWVuIGEgVENQLWxp a2UNCj4gdHJhbnNwb3J0IGxheWVyIGFuZCBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgaXQgaW4gYSAi Y2xlYW4gY2xvc2UiLCBidXQgdGhlbg0KPiBuZWl0aGVyIGRvZXMgdGhlIGV4aXN0aW5nIGJpZGly ZWN0aW9uYWwgR09BV0FZLiBBIGNsZWFuIGNsb3NlIHNob3VsZA0KPiBpbmRpY2F0ZSB0byB0aGUg YXBwIHRoYXQgYWxsIHdyaXR0ZW4gZGF0YSBoYXMgYmVlbiByZWNlaXZlZCwgYW5kIHRoZSBwZWVy DQo+IGhhcyBzdWNjZXNzZnVsbHkgZGVsaXZlcmVkIGFsbCBpdHMgaW50ZW5kZWQgZGF0YS4NCj4N Cj4gV2hhdCBRVUlDIG5lZWRzIGlzIGEgc2lnbmFsIHRoYXQgc2F5cyAiSSBhbSBkb25lIGNyZWF0 aW5nIG5ldyBzdHJlYW1zIGJ1dCBhbQ0KPiBzdGlsbCB3aWxsaW5nIHRvIHJlY2VpdmUgbmV3IG9u ZXMiLiBBbHRob3VnaCB0aGVyZSBvdWdodCB0byBiZSBzdHJlYW0tbGV2ZWwNCj4gc2h1dGRvd24o KSBjYWxscyBpbiBhIGZ1dHVyZSBzb2NrZXQgQVBJLCBidXQgYSBjb25uZWN0aW9uLWxldmVsIHNo dXRkb3duKCkNCj4gd291bGQgc2VuZCB0aGlzIHNpZ25hbCBhbmQgYWxzbyBGSU4gYWxsIHJlbWFp bmluZyBzdHJlYW1zLiBBZnRlciBib3RoIFFVSUMNCj4gZW5kcG9pbnRzIGNsZWFuIGFsbCB0aGlz IHVwIGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGENCj4gZnVy dGhlciBzaWduYWwgZnJvbSB0aGUgYXBwLg0KPg0KPiBGb3JjaW5nIGV2ZXJ5IGFwcCB0byBjcmVh dGUgaXRzIG93biBHT0FXQVkgKG9yLCBpbiBteSB2aXNpb24sIHNlbmQtb25seQ0KPiBHT0FXQVkp IG1lY2hhbmlzbSBzZWVtcyByYXRoZXIgaGVhdnl3ZWlnaHQgaWYgaXQgaXMgYSBjb21tb24gZmVh dHVyZSBvZiBhDQo+IGNsZWFuIGNsb3NlLg0KPg0KPiBPbiBUdWUsIE1hciA3LCAyMDE3IGF0IDc6 MTYgUE0sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29t Pj4gd3JvdGU6DQo+Pg0KPj4gQWZ0ZXIgY2hhdHRpbmcgd2l0aCBNYXJ0aW4gb2ZmbGluZSwgaXQn cyBncm93aW5nIG9uIG1lIGFzIHdlbGwuIFRoZSBrZXkNCj4+IGluc2lnaHRzIGluIG15IG1pbmQg YXJlOg0KPj4NCj4+IDEuIEl0J3MgcHJlZmVyYWJsZSBmb3IgZWFjaCBlbmRwb2ludCB0byBpbmRp Y2F0ZSB0aGUgc3RyZWFtcyBpdCBpcw0KPj4gY2xvc2luZywgdG8gYXZvaWQgcmVxdWlyaW5nIHVw cGVyLWxheWVyIHJldHJpZXMgb2YgbmV3IHN0cmVhbXMgaW4gZmxpZ2h0Lg0KPj4NCj4+IDIuIFRo ZSBzZW1hbnRpY3Mgb2Ygc3RyZWFtIGNyZWF0aW9uIGFyZSBkaWZmZXJlbnQgZm9yIGRpZmZlcmVu dCBhcHBzLiBIVFRQDQo+PiBnZW5lcmFsbHkgaGFzIHRoZSBjbGllbnQgY3JlYXRpbmcgYSBzdHJl YW0gYW5kIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgb24gdGhlDQo+PiBzYW1lIHN0cmVhbS4gQSBkaWZm ZXJlbnQgYXBwbGljYXRpb24gY2FuIGhhdmUgdmVyeSBkaWZmZXJlbnQgY2xpZW50LXNlcnZlcg0K Pj4gaW50ZXJhY3Rpb25zLiBGb3IgaW5zdGFuY2UsIGEgY2xpZW50IGNyZWF0ZXMgYSBzdHJlYW0g d2hpY2ggcmVxdWlyZXMgYSBhDQo+PiBzZXJ2ZXIgdG8gY3JlYXRlIG11bHRpcGxlIHN0cmVhbXMg aW4gcmVzcG9uc2UsIHdoaWNoIGluIHR1cm4gcmVxdWlyZSBmdXJ0aGVyDQo+PiBjbGllbnQgc3Ry ZWFtIGNyZWF0aW9ucy4gSW4gdGhpcyBjYXNlLCBRVUlDIGhhcyBubyBpZGVhIHdoYXQgdGhlICJs YXN0Ig0KPj4gc3RyZWFtIG91Z2h0IHRvIGJlLCBhbmQgdGhpcyBuZWVkcyB0byBiZSBpbmRpY2F0 ZWQgYnkgdGhlIGFwcGxpY2F0aW9uLg0KPj4NCj4+IDMuIFNpbmNlIGluIHRoZSBnZW5lcmFsIGNh c2UgdGhlIGFwcCBwcm90b2NvbCBpcyBleHBlY3RlZCB0byBiZSBpbnZvbHZlZA0KPj4gaW4gZmln dXJpbmcgb3V0IHdoYXQgZ3JhY2VmdWwgY2xvc2UgbG9va3MgbGlrZSwgaXQgbWFrZXMgc2Vuc2Ug dG8gZGVmaW5lIGl0DQo+PiBwZXIgYXBwLiBJbiBvdGhlciB3b3JkcywgbWFrZSBpdCBwYXJ0IG9m IHRoZSBhcHAgbWFwcGluZyB0byBRVUlDLiBGb3IgSFRUUCwNCj4+IHRoaXMgd291bGQgYmUgYSBH T0FXQVkgZnJhbWUgb24gU3RyZWFtIDMuIE9uY2UgYWxsIHN0cmVhbXMgYXJlIGNsb3NlZCwgSFRU UA0KPj4gY2xvc2VzIFN0cmVhbSAzLg0KPj4NCj4+IDQuIEdyYWNlZnVsIGNsb3NlIGJ5IHRoZSBh cHAgbWVhbnMgdGhhdCB0aGUgUVVJQyBjb25uZWN0aW9uIGNhbg0KPj4gaW1tZWRpYXRlbHkgZ28g aW50byBUSU1FX1dBSVQgb24gYSBjb25uZWN0aW9uIGNsb3NlIGZyb20gdGhlIGFwcC4NCj4+DQo+ PiBJdCBpcyBhIGNsZWFuIHNlcGFyYXRpb24gb2YgY29uY2VybnMgZm9yIHN1cmUuIEknZCBsaWtl IHRvIHJ1bWluYXRlIG9uDQo+PiB0aGlzIGEgYml0LCBzaW5jZSBzb21ldGltZXMgdGhhdCBoZWxw cy4NCj4+DQo+PiBUaGlzIHNlZW1zIGxpa2UgZ29vZCBmb2RkZXIgZm9yIENoaWNhZ28uDQo+Pg0K Pj4gT24gVHVlLCBNYXIgNywgMjAxNyBhdCA2OjUyIFBNLCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdv b2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+IEFm dGVyIHRoaW5raW5nIGFib3V0IGl0IG1vcmUsIGlmIG5vIG9uZSBlbHNlIGhhcyBvYmplY3Rpb25z IHRvICJNYWtlDQo+Pj4gZXZlcnkgYXBwbGljYXRpb24gaW1wbGVtZW50IHRoZWlyIG93biBncmFj ZWZ1bCBjbG9zZSBpZiB0aGV5IG5lZWQgaXQgYW5kDQo+Pj4gb25seSBwcm92aWRlIGEgd2F5IHRv IGtpbGwgdGhlIGNvbm5lY3Rpb24gaW1tZWRpYXRlbHkuIiwgSSdtIGZpbmUgd2l0aCBpdCBhcw0K Pj4+IHdlbGwuDQo+Pj4NCj4+PiBPbiBUdWUsIE1hciA3LCAyMDE3IGF0IDY6MjAgUE0sIE1hcnRp biBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT4+DQo+Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+IE9uIDggTWFyY2ggMjAxNyBhdCAw Mzo1OCwgVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0ZkBnbWFp bC5jb20+PiB3cm90ZToNCj4+Pj4gPg0KPj4+PiA+IE9uIE1vbiwgTWFyIDYsIDIwMTcgYXQgMzo0 MCBQTSwgTWFydGluIFRob21zb24NCj4+Pj4gPiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KPj4+PiA+IHdyb3RlOg0KPj4+PiA+Pg0K Pj4+PiA+PiBJIHRoaW5rIHRoYXQgYm90aCBhcmUgbGlrZWx5IHRvIHJ1biBhZm91bCBvZiBhIHNp bXBsZSBwcm9ibGVtIGluDQo+Pj4+ID4+IEhUVFA6DQo+Pj4+ID4+IHRoZSBjb250cm9sIHN0cmVh bSAoc3RyZWFtIDMpIGNhbid0IGJlIGNsb3NlZC4NCj4+Pj4gPj4NCj4+Pj4gPiBJIGRvbid0IHRo aW5rIHRoYXQncyBhY3R1YWxseSBhIHByb2JsZW0gd2l0aCB3aGF0IEkgc3VnZ2VzdGVkLiAgSXQN Cj4+Pj4gPiBzaW1wbHkNCj4+Pj4gPiBtZWFucyB0aGF0IGZvciB0aGUgSFRUUCBtYXBwaW5nLCB0 aGUgZGVmaW5lZCBiZWhhdmlvciBpcyB0byBzZW5kDQo+Pj4+ID4gRklOX0NPTVBMRVRFIGFmdGVy IGFsbCBvcGVuIHJlcXVlc3RzIGFuZCBwdXNoZXMgY29tcGxldGUuICBJZiBpdA0KPj4+PiA+IGFy cml2ZXMNCj4+Pj4gPiBiZWZvcmUgdGhlbiwgeW91J2QgaGF2ZSB0byB0cmVhdCBpdCBhcyBhIHBy b3RvY29sIGVycm9yIGZvciB0aGUNCj4+Pj4gPiBtYXBwaW5nLg0KPj4+PiA+IFdoYXQgSSdtIHRy eWluZyB0byBhdm9pZCBpcyBiYWtpbmcgaW4gdGhlIHJlcXVpcmVtZW50IHRoYXQNCj4+Pj4gPiBG SU5fQ09NUExFVEUgKG9yDQo+Pj4+ID4gaXRzIG1vcmFsIGVxdWl2YWxlbnQpIGFsd2F5cyBvY2N1 ciB0aGVuLCBzaW5jZSBpdCB3aWxsIG1ha2UgdXNpbmcNCj4+Pj4gPiBvdGhlcg0KPj4+PiA+IHR5 cGVzDQo+Pj4+DQo+Pj4+IFN1cmUuICBJIGhhZCBpbmZlcnJlZCB0aGF0IHlvdSB3ZXJlIGRvaW5n IHRoaXMgZW50aXJlbHkgYXQgdGhlDQo+Pj4+IHRyYW5zcG9ydCBsYXllciwgd2hpY2ggZG9lc24n dCByZWFsbHkgYWxsb3cgeW91IHRvIGRvIHRoYXQuDQo+Pj4NCj4+Pg0KPj4NCj4NCg0KDQo= --_000_BN6PR03MB27084228761DBE525A17937A87260BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MjEyMTQwOTg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTI0NzU3Mzc2IDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIGFuIGVu ZHBvaW50IGxldmVsLCBJ4oCZbSBjb250ZW50IHdpdGggdGhlIG1vZGVsIG9mOjxvOnA+PC9vOnA+ PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPkEgZnJhbWUgaXMg4oCcY29uZmlybWVkIGRlbGl2ZXJlZOKAnSB3aGVuIGFuIEFD SyBpcyByZWNlaXZlZCB3aGljaCBzYXlzIHRoZSBhIHBhY2tldCBjb250YWluaW5nIHRoZSBmcmFt ZSB3YXMgcmVjZWl2ZWQgYnkgdGhlIHBlZXI8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj5BIHN0cmVhbSBpcyDigJxjb25maXJtZWQgY2xvc2Vk4oCdIHdoZW4gYWxsIGRhdGEsIG9y IGEgUlNUX1NUUkVBTSwgaGFzIGJlZW4gY29uZmlybWVkIGRlbGl2ZXJlZCB0byB0aGUgZmFyIHNp ZGUgYW5kIHdoZW4gYWxsIGRhdGEgb3IgYSBSU1RfU1RSRUFNIGhhcyBiZWVuIHJlY2VpdmVkIGFu ZCB0aGUgQUNLIGlzIGNvbmZpcm1lZA0KIGRlbGl2ZXJlZDxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPk9uY2UgYSBzaHV0ZG93biBoYXMgYmVlbiB0cmlnZ2VyZWQsIGEgY29ubmVj dGlvbiBjbG9zZXMgc2lsZW50bHkgd2hlbiBhbGwgc3RyZWFtcyBhcmUgZWl0aGVyIGNvbmZpcm1l ZCBjbG9zZWQgb3IgaWRsZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMg YSBzbGlnaHQgcmFjZSwgaW4gdGhhdCBhIHBlZXItaW5pdGlhdGVkIHN0cmVhbSBjb3VsZCBiZSBv cGVuZWQgZHVyaW5nIHRoZSBzaHV0ZG93biB3YWl0LiZuYnNwOyBBcyBvdGhlcnMgaGF2ZSBub3Rl ZCwgdGhhdCBjYW4gYmUgaGFuZGxlZCBhdCB0aGUgYXBwIGxheWVyIGJ5IGdpdmluZyBhIHByZS1z aHV0ZG93biBub3RpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHlv dSB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGZyYW1lIGhhcyBiZWVuIGRlbGl2ZXJlZC4mbmJzcDsg VGhhdCBpbXBsaWVzIGhhdmluZyBhIHdheSBmb3IgdGhlIGFwcGxpY2F0aW9uIHRvIHdhaXQgZm9y IHRoZSBBQ0sgb2YgYSBwYXJ0aWN1bGFyIHBpZWNlIG9mIHN0cmVhbSBkYXRhOyB0aGF04oCZcyBu b3Qgc29tZXRoaW5nIHdlIGN1cnJlbnRseSByZXF1aXJlIHRoZSB0cmFuc3BvcnQgdG8gZXhwb3Nl LCBhbmQNCiBJ4oCZZCBwcmVmZXIgbm90IHRvIG1ha2UgaXQgYSBuZXcgcmVxdWlyZW1lbnQuICZu YnNwO1RoZSBhcHBsaWNhdGlvbiBjb3VsZCBhbHNvIGFkZCBhbiBhcHAtbGV2ZWwgQUNLIG9mIHNv bWUga2luZCwgb3IgKGZvciBIVFRQKSB0aGUgY2xvc2luZyBvZiBzdHJlYW0gMyBjb3VsZCBiZSBh biBpbXBsaWNpdCBBQ0suPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0aGUgb3RoZXIgcXVl c3Rpb24sIHdoZXRoZXIgd2Ugd2FudCB0byBleHBvc2UgdG8gdGhlIHBhdGggdGhhdCB0aGUgY29u bmVjdGlvbiBoYXMgZGVmaW5pdGl2ZWx5IGVuZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVo YWxmIE9mDQo8L2I+TWFydGluIER1a2U8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNo IDE2LCAyMDE3IDI6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEphbmEgSXllbmdhciAmbHQ7anJpQGdv b2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWNhcyBDbGVtZW50ZSAmbHQ7bHVjYXNAbGNs ZW1lbnRlLm9yZyZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IElF VEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBNb3ZlIEdPQVdBWSB0byBIVFRQIGRyYWZ0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHJpZ2h0LCBJIHRoaW5rIEknbSBjb252 aW5jZWQgd2UgY2FuIGdldCByaWQgb2YgR09BV0FZIGVudGlyZWx5LjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzdGlsbCBsaWtlIHRvIGhhdmUg dHdvIHR5cGVzIG9mIGFwcGxpY2F0aW9uIGNsb3NlIChpbiB0ZXJtcyBvZiB0aGUgYXBwbGljYXRp b24gQVBJKSwgb25lIHRoYXQgaXMgbm90IGdyYWNlZnVsIChpbW1lZGlhdGUgUFVCTElDX1JFU0VU KSBhbmQgb25lIHRoYXQgaXMgZ3JhY2VmdWwgKGFzIHlvdSBkZXNjcmliZSwgJnF1b3Q7d2FpdCBm b3IgWCBzZWMgdG8gbWFrZSBzdXJlIHRoZXJlIGFyZSBubyBub24tUElORywNCiBub24tUEFERElO RyBmcmFtZXMmcXVvdDspIHRoYXQgbGVhZHMgdG8gYSBDT05ORUNUSU9OX0NMT1NFIChvciwgYXMg SSB3b3VsZCBhcmd1ZSBpbiAjMzUzLCBhIGRlbGF5ZWQgUHVibGljIFJlc2V0KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAx NSwgMjAxNyBhdCAxMTowNSBQTSwgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJp QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFncmVlIHdpdGggd2hhdCBNYXJ0aW4gKFRob21zb24pIHNhaWQuIFRoZSBrZXkgdGhpbmcg dG8gcmVjb2duaXplIGlzIHRoYXQgUVVJQyBzdHJlYW1zIGFyZSBzaW1pbGFyIHRvIFRDUCBjb25u ZWN0aW9ucywgYnV0IHRoZSBRVUlDIGNvbm5lY3Rpb24gaXMgZGlmZmVyZW50IC0tLSBpdCdzIGEg Y29udGFpbmVyLiBBcHBseWluZyBUQ1AgbG9naWMgdG8gUVVJQyBzdHJlYW1zIG1ha2VzIHNlbnNl LCBidXQgdGhlDQogUVVJQyBjb25uZWN0aW9uIGl0c2VsZiBpcyBhIGRpZmZlcmVudCBiZWFzdCB0 aGF0IGRvZXNuJ3QgbmVlZCB0byBmb2xsb3cgdGhlIGxvZ2ljIG9mIFRDUCBjb25uZWN0aW9ucy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBzb21l IHRob3VnaHRzIG9uIGhvdyB0byBtYWtlIFFVSUMgY29ubmVjdGlvbnMgc2VlbSBtb3JlIGxpa2Ug Y29udGFpbmVycywgYXQgbGVhc3QgZm9yIGNvbm5lY3Rpb24gY2xvc2Ugc2VtYW50aWNzLiBJJ2xs IHRyeSB0byB3cml0ZSB1cCBzb21ldGhpbmcgdG9tb3Jyb3cuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBN YXIgMTUsIDIwMTcgYXQgODo0OCBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIHRoYXQgJnF1b3Q7VENQLWxpa2UmcXVv dDsgaXMgdGhlIHJpZ2h0IGJlbmNobWFyayBoZXJlLiZuYnNwOyBUaGF0IHdvdWxkPGJyPg0KYXBw bHkgdG8gc3RyZWFtcywgYnV0IG5vdCB0aGUgZW50aXJlIHNlc3Npb24uPGJyPg0KPGJyPg0KRXZl biBpbiBIVFRQLCB5b3VyIHNpZ25hbCBkb2Vzbid0IHdvcmsgaW4gb25lIGRpcmVjdGlvbi4mbmJz cDsgQSBzZXJ2ZXI8YnI+DQpnZW5lcmF0ZXMgc3RyZWFtcyBpbiByZXNwb25zZSB0byBjbGllbnQg c3RyZWFtcy4mbmJzcDsgSXQgY2FuJ3Qgc2F5ICZxdW90O0knbTxicj4NCmRvbmUgd2l0aCBjcmVh dGluZyBzdHJlYW1zLCBidXQgeW91IGNvbnRpbnVlIGZvciBub3cmcXVvdDsgd2l0aG91dCBjdXR0 aW5nPGJyPg0KaXRzZWxmIG9mZiBmcm9tIHNlcnZlciBwdXNoLiZuYnNwOyBZb3UgbWlnaHQgbm90 IGJlIHNhZCBhYm91dCB0aGF0LCBidXQ8YnI+DQp5b3UnZCBoYXZlIHRvIGFkbWl0IHRoYXQgd291 bGQgYmUgYSBzdWJqZWN0aXZlIGRlY2lzaW9uLjxicj4NCjxicj4NCkdpdmVuIHRoYXQgd2UncmUg YWltaW5nIGZvciBhIGdlbmVyYWwgcHVycG9zZSBwcm90b2NvbCwgd2UgY2FuJ3Q8YnI+DQpndWFy YW50ZWUgdGhhdCBvdGhlciBhcHBsaWNhdGlvbnMgd2lsbCBoYXZlIGNsZWFuIHRyYW5zYWN0aW9u YWw8YnI+DQpzZW1hbnRpY3Mgc3VjaCB0aGF0IHlvdXIgc2lnbmFsIHdpbGwgYmUgYWN0aW9uYWJs ZSBhdCB0aGUgdHJhbnNwb3J0PGJyPg0KbGF5ZXIuJm5ic3A7IE9ubHkgdGhlIGFwcGxpY2F0aW9u IHByb3RvY29sIGtub3dzIHdoZW4gaXQgaXMgJnF1b3Q7ZG9uZSZxdW90Oywgc28gYW55PGJyPg0K c2lnbmFsIG9mIGltbWluZW50IHNodXRkb3duIGlzIGdvaW5nIHRvIGJlIHVwIHRvIHRoZW0uJm5i c3A7IFdoYXQgd291bGQgYTxicj4NCmdlbmVyaWMgc2h1dGRvd24oKSBkbz8mbmJzcDsgWW91IGNh bid0IGp1c3QgY2xvc2UgYWxsIG9wZW4gc3RyZWFtcyB3aGVyZTxicj4NCnRoZXkgc3RhbmQgYW5k IGhvcGUgdGhhdCB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wgd2lsbCBiZSBoYXBweS48YnI+DQo8 YnI+DQpUaGUgbW9yZSBJIHRoaW5rIGFib3V0IHRoaXMgcHJvYmxlbSwgdGhlIG1vcmUgSSBhbSBj b252aW5jZWQgdGhhdCB0aGU8YnI+DQphcHBsaWNhdGlvbiBuZWVkcyB0byBzb3J0IGl0IG91dCBh bmQgdGhlbiBzZW5kIGEgc2lnbmFsIHRvIHRoZTxicj4NCnRyYW5zcG9ydC4mbmJzcDsgVGhhdCBz aWduYWwgd291bGQgYmUgJnF1b3Q7c3RhcnQgYSB0aW1lciAobGlrZSBGSU5fV0FJVDIpLCBpZjxi cj4NCnlvdSBkb24ndCBzZWUgYW55dGhpbmcgbmV3IGluIHRoYXQgdGltZSwgZGlzY2FyZCBzdGF0 ZSZxdW90Oy4mbmJzcDsgSFRUUCB3b3VsZDxicj4NCmRvIHRoYXQgYWZ0ZXIgcmVjZWl2aW5nIGl0 cyBvd24gJnF1b3Q7SSdtIGRvbmUmcXVvdDsgc2lnbmFscyBvbiBpdHMgY29ubmVjdGlvbjxicj4N CmNvbnRyb2wgc3RyZWFtIGFuZCBjbG9zaW5nIG91dCBhbnkgbGluZ2VyaW5nIHN0cmVhbXMgYW5k PGJyPg0KcmV0cmFuc21pc3Npb25zLiZuYnNwOyBUaGUgcmVhbCBzaWduYWxpbmcgKGEgR09BV0FZ IG9yIGFuYWxvZ291cykgd291bGQ8YnI+DQpoYXZlIHRvIGJlIGV4Y2hhbmdlZCBhIGxvbmcgdGlt ZSBiZWZvcmUgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KT24gMTYgTWFyY2ggMjAxNyBhdCAwOTowNiwgTWFydGluIER1 a2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBU aGlzIGRvZXNuJ3QgbWF0Y2ggbXkgcGVyY2VwdGlvbiBvZiB0aGUgY29udHJhY3QgYmV0d2VlbiBh IFRDUC1saWtlPGJyPg0KJmd0OyB0cmFuc3BvcnQgbGF5ZXIgYW5kIGFwcGxpY2F0aW9ucyB0aGF0 IHVzZSBpdCBpbiBhICZxdW90O2NsZWFuIGNsb3NlJnF1b3Q7LCBidXQgdGhlbjxicj4NCiZndDsg bmVpdGhlciBkb2VzIHRoZSBleGlzdGluZyBiaWRpcmVjdGlvbmFsIEdPQVdBWS4gQSBjbGVhbiBj bG9zZSBzaG91bGQ8YnI+DQomZ3Q7IGluZGljYXRlIHRvIHRoZSBhcHAgdGhhdCBhbGwgd3JpdHRl biBkYXRhIGhhcyBiZWVuIHJlY2VpdmVkLCBhbmQgdGhlIHBlZXI8YnI+DQomZ3Q7IGhhcyBzdWNj ZXNzZnVsbHkgZGVsaXZlcmVkIGFsbCBpdHMgaW50ZW5kZWQgZGF0YS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBXaGF0IFFVSUMgbmVlZHMgaXMgYSBzaWduYWwgdGhhdCBzYXlzICZxdW90O0kgYW0gZG9u ZSBjcmVhdGluZyBuZXcgc3RyZWFtcyBidXQgYW08YnI+DQomZ3Q7IHN0aWxsIHdpbGxpbmcgdG8g cmVjZWl2ZSBuZXcgb25lcyZxdW90Oy4gQWx0aG91Z2ggdGhlcmUgb3VnaHQgdG8gYmUgc3RyZWFt LWxldmVsPGJyPg0KJmd0OyBzaHV0ZG93bigpIGNhbGxzIGluIGEgZnV0dXJlIHNvY2tldCBBUEks IGJ1dCBhIGNvbm5lY3Rpb24tbGV2ZWwgc2h1dGRvd24oKTxicj4NCiZndDsgd291bGQgc2VuZCB0 aGlzIHNpZ25hbCBhbmQgYWxzbyBGSU4gYWxsIHJlbWFpbmluZyBzdHJlYW1zLiBBZnRlciBib3Ro IFFVSUM8YnI+DQomZ3Q7IGVuZHBvaW50cyBjbGVhbiBhbGwgdGhpcyB1cCBhdCB0aGUgdHJhbnNw b3J0IGxheWVyLCB0aGVyZSBpcyBubyBuZWVkIGZvciBhPGJyPg0KJmd0OyBmdXJ0aGVyIHNpZ25h bCBmcm9tIHRoZSBhcHAuPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yY2luZyBldmVyeSBhcHAgdG8g Y3JlYXRlIGl0cyBvd24gR09BV0FZIChvciwgaW4gbXkgdmlzaW9uLCBzZW5kLW9ubHk8YnI+DQom Z3Q7IEdPQVdBWSkgbWVjaGFuaXNtIHNlZW1zIHJhdGhlciBoZWF2eXdlaWdodCBpZiBpdCBpcyBh IGNvbW1vbiBmZWF0dXJlIG9mIGE8YnI+DQomZ3Q7IGNsZWFuIGNsb3NlLjxicj4NCiZndDs8YnI+ DQomZ3Q7IE9uIFR1ZSwgTWFyIDcsIDIwMTcgYXQgNzoxNiBQTSwgSmFuYSBJeWVuZ2FyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQWZ0ZXIgY2hh dHRpbmcgd2l0aCBNYXJ0aW4gb2ZmbGluZSwgaXQncyBncm93aW5nIG9uIG1lIGFzIHdlbGwuIFRo ZSBrZXk8YnI+DQomZ3Q7Jmd0OyBpbnNpZ2h0cyBpbiBteSBtaW5kIGFyZTo8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IDEuIEl0J3MgcHJlZmVyYWJsZSBmb3IgZWFjaCBlbmRwb2ludCB0byBp bmRpY2F0ZSB0aGUgc3RyZWFtcyBpdCBpczxicj4NCiZndDsmZ3Q7IGNsb3NpbmcsIHRvIGF2b2lk IHJlcXVpcmluZyB1cHBlci1sYXllciByZXRyaWVzIG9mIG5ldyBzdHJlYW1zIGluIGZsaWdodC48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDIuIFRoZSBzZW1hbnRpY3Mgb2Ygc3RyZWFtIGNy ZWF0aW9uIGFyZSBkaWZmZXJlbnQgZm9yIGRpZmZlcmVudCBhcHBzLiBIVFRQPGJyPg0KJmd0OyZn dDsgZ2VuZXJhbGx5IGhhcyB0aGUgY2xpZW50IGNyZWF0aW5nIGEgc3RyZWFtIGFuZCB0aGUgc2Vy dmVyIHJlc3BvbmRzIG9uIHRoZTxicj4NCiZndDsmZ3Q7IHNhbWUgc3RyZWFtLiBBIGRpZmZlcmVu dCBhcHBsaWNhdGlvbiBjYW4gaGF2ZSB2ZXJ5IGRpZmZlcmVudCBjbGllbnQtc2VydmVyPGJyPg0K Jmd0OyZndDsgaW50ZXJhY3Rpb25zLiBGb3IgaW5zdGFuY2UsIGEgY2xpZW50IGNyZWF0ZXMgYSBz dHJlYW0gd2hpY2ggcmVxdWlyZXMgYSBhPGJyPg0KJmd0OyZndDsgc2VydmVyIHRvIGNyZWF0ZSBt dWx0aXBsZSBzdHJlYW1zIGluIHJlc3BvbnNlLCB3aGljaCBpbiB0dXJuIHJlcXVpcmUgZnVydGhl cjxicj4NCiZndDsmZ3Q7IGNsaWVudCBzdHJlYW0gY3JlYXRpb25zLiBJbiB0aGlzIGNhc2UsIFFV SUMgaGFzIG5vIGlkZWEgd2hhdCB0aGUgJnF1b3Q7bGFzdCZxdW90Ozxicj4NCiZndDsmZ3Q7IHN0 cmVhbSBvdWdodCB0byBiZSwgYW5kIHRoaXMgbmVlZHMgdG8gYmUgaW5kaWNhdGVkIGJ5IHRoZSBh cHBsaWNhdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDMuIFNpbmNlIGluIHRoZSBn ZW5lcmFsIGNhc2UgdGhlIGFwcCBwcm90b2NvbCBpcyBleHBlY3RlZCB0byBiZSBpbnZvbHZlZDxi cj4NCiZndDsmZ3Q7IGluIGZpZ3VyaW5nIG91dCB3aGF0IGdyYWNlZnVsIGNsb3NlIGxvb2tzIGxp a2UsIGl0IG1ha2VzIHNlbnNlIHRvIGRlZmluZSBpdDxicj4NCiZndDsmZ3Q7IHBlciBhcHAuIElu IG90aGVyIHdvcmRzLCBtYWtlIGl0IHBhcnQgb2YgdGhlIGFwcCBtYXBwaW5nIHRvIFFVSUMuIEZv ciBIVFRQLDxicj4NCiZndDsmZ3Q7IHRoaXMgd291bGQgYmUgYSBHT0FXQVkgZnJhbWUgb24gU3Ry ZWFtIDMuIE9uY2UgYWxsIHN0cmVhbXMgYXJlIGNsb3NlZCwgSFRUUDxicj4NCiZndDsmZ3Q7IGNs b3NlcyBTdHJlYW0gMy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDQuIEdyYWNlZnVsIGNs b3NlIGJ5IHRoZSBhcHAgbWVhbnMgdGhhdCB0aGUgUVVJQyBjb25uZWN0aW9uIGNhbjxicj4NCiZn dDsmZ3Q7IGltbWVkaWF0ZWx5IGdvIGludG8gVElNRV9XQUlUIG9uIGEgY29ubmVjdGlvbiBjbG9z ZSBmcm9tIHRoZSBhcHAuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJdCBpcyBhIGNsZWFu IHNlcGFyYXRpb24gb2YgY29uY2VybnMgZm9yIHN1cmUuIEknZCBsaWtlIHRvIHJ1bWluYXRlIG9u PGJyPg0KJmd0OyZndDsgdGhpcyBhIGJpdCwgc2luY2Ugc29tZXRpbWVzIHRoYXQgaGVscHMuPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGlzIHNlZW1zIGxpa2UgZ29vZCBmb2RkZXIgZm9y IENoaWNhZ28uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBUdWUsIE1hciA3LCAyMDE3 IGF0IDY6NTIgUE0sIElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFmdGVyIHRoaW5raW5nIGFib3V0 IGl0IG1vcmUsIGlmIG5vIG9uZSBlbHNlIGhhcyBvYmplY3Rpb25zIHRvICZxdW90O01ha2U8YnI+ DQomZ3Q7Jmd0OyZndDsgZXZlcnkgYXBwbGljYXRpb24gaW1wbGVtZW50IHRoZWlyIG93biBncmFj ZWZ1bCBjbG9zZSBpZiB0aGV5IG5lZWQgaXQgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7IG9ubHkgcHJv dmlkZSBhIHdheSB0byBraWxsIHRoZSBjb25uZWN0aW9uIGltbWVkaWF0ZWx5LiZxdW90OywgSSdt IGZpbmUgd2l0aCBpdCBhczxicj4NCiZndDsmZ3Q7Jmd0OyB3ZWxsLjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBUdWUsIE1hciA3LCAyMDE3IGF0IDY6MjAgUE0sIE1hcnRp biBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgT24gOCBNYXJjaCAyMDE3IGF0IDAzOjU4LCBUZWQgSGFyZGllICZsdDs8YSBocmVmPSJtYWls dG86dGVkLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGVkLmlldGZAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyAmZ3Q7IE9uIE1vbiwgTWFyIDYsIDIwMTcgYXQgMzo0MCBQTSwgTWFydGluIFRob21z b248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5j b208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIHRoaW5r IHRoYXQgYm90aCBhcmUgbGlrZWx5IHRvIHJ1biBhZm91bCBvZiBhIHNpbXBsZSBwcm9ibGVtIGlu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBIVFRQOjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgJmd0OyZndDsgdGhlIGNvbnRyb2wgc3RyZWFtIChzdHJlYW0gMykgY2FuJ3QgYmUgY2xvc2Vk Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsgSSBkb24ndCB0aGluayB0aGF0J3MgYWN0dWFsbHkgYSBwcm9ibGVtIHdpdGggd2hhdCBJIHN1 Z2dlc3RlZC4mbmJzcDsgSXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsgc2ltcGx5PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IG1lYW5zIHRoYXQgZm9yIHRoZSBIVFRQIG1hcHBpbmcsIHRo ZSBkZWZpbmVkIGJlaGF2aW9yIGlzIHRvIHNlbmQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZndDsg RklOX0NPTVBMRVRFIGFmdGVyIGFsbCBvcGVuIHJlcXVlc3RzIGFuZCBwdXNoZXMgY29tcGxldGUu Jm5ic3A7IElmIGl0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IGFycml2ZXM8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7ICZndDsgYmVmb3JlIHRoZW4sIHlvdSdkIGhhdmUgdG8gdHJlYXQgaXQgYXMg YSBwcm90b2NvbCBlcnJvciBmb3IgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IG1hcHBp bmcuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmZ3Q7IFdoYXQgSSdtIHRyeWluZyB0byBhdm9pZCBp cyBiYWtpbmcgaW4gdGhlIHJlcXVpcmVtZW50IHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZn dDsgRklOX0NPTVBMRVRFIChvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBpdHMgbW9yYWwg ZXF1aXZhbGVudCkgYWx3YXlzIG9jY3VyIHRoZW4sIHNpbmNlIGl0IHdpbGwgbWFrZSB1c2luZzxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmd0OyBvdGhlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmd0 OyB0eXBlczxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFN1cmUu Jm5ic3A7IEkgaGFkIGluZmVycmVkIHRoYXQgeW91IHdlcmUgZG9pbmcgdGhpcyBlbnRpcmVseSBh dCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydCBsYXllciwgd2hpY2ggZG9lc24n dCByZWFsbHkgYWxsb3cgeW91IHRvIGRvIHRoYXQuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB27084228761DBE525A17937A87260BN6PR03MB2708namp_-- From nobody Thu Mar 16 14:38:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC6129AB7 for ; Thu, 16 Mar 2017 14:38:17 -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 dG0sdeG9P0qL for ; Thu, 16 Mar 2017 14:38:15 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A3E129AB6 for ; Thu, 16 Mar 2017 14:38:14 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id o24so71271571otb.1 for ; Thu, 16 Mar 2017 14:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lUUVYMKUnC676QMiPQt5opOQh6UEi4tTHbM8SLrLpdU=; b=KYCBcnUlGxdZxKigU1Xyfwzcgkte8tBTCTlsbv14xDllNIYPUAp35SB4INAW+V0t68 3Fo7yqqnfo9WxTSBpKSGlARZZzWRS4YN4hK5wF71PuFUXxR5zTMDryPKWmKUplWCbs0T qY4HtNEvVqH+kvzf0TwR2EEX1WztbeQaB9yz0KNmakVyDLfY1ZiwBtL7jWrGrPk+hH1x SvbLPLImClwH2AmI4D5uCkfOYY1ODVLhrhQX+3bRqHWrou40w74OjqyLVb12+I0PKdO0 2RnZ5C10J/WZyJv4eXXx5usJAu61pcYYZ5r6skjf5E/cxRDBlsonPPMda2ONyHmUE/87 U8CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lUUVYMKUnC676QMiPQt5opOQh6UEi4tTHbM8SLrLpdU=; b=JvwgVoYB4ssGbwoR1Yv8bnxihvtEMbr5FT4VZRZLCHXjQS6ImSTIfZ8aLrCmkodVYI ZwvNcQHqug+3dIVU7a9RmBPvnsJe6wr9N6bK6OSOSNCAGA81kh6ywzyjrpGFhsOXnNdd wsJQcC9+/ph/mb1Mg6x7bW43tO4H1cVKcdWKL3Ovso0VNecqFfSN5EZiiKFjL5tCpWAb tS9OkODNww/jTpsL5ofkJi+YL8hvn8J8l0puEzU39pdEONyP8blfLjulmg2zrZH82fP1 e4V5+hvtwctIFN/NQC7r8fcUQKWXznrR1HwzdeCLbFNT/Q14RT9TI11bqLjmP3zCTfLq eVmg== X-Gm-Message-State: AFeK/H0kY4HIndoGMO9feUT0eJjCKeDwdHMmfaSk3ZnPTUawxg4OAGf49b98bpQKwlxuLJdJdItwZitLD1V4Ig== X-Received: by 10.157.12.210 with SMTP id o18mr5229554otd.99.1489700293606; Thu, 16 Mar 2017 14:38:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Thu, 16 Mar 2017 14:38:12 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Thu, 16 Mar 2017 14:38:12 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Mike Bishop Cc: Jana Iyengar , Lucas Clemente , Ian Swett , IETF QUIC WG , Martin Thomson , Ted Hardie Content-Type: multipart/alternative; boundary=001a113f5090d28419054adfe0ec Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 21:38:18 -0000 --001a113f5090d28419054adfe0ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, I agree with everything -- except that there is no way to "confirm delivery" of an ack in the general case: you do not ack a packet consisting only of acks. This is why we need some sort of timer at the end to make sure that the peer isn't still retransmitting stuff due to a lost ACK. On Thu, Mar 16, 2017 at 2:32 PM, Mike Bishop wrote: > From an endpoint level, I=E2=80=99m content with the model of: > > - A frame is =E2=80=9Cconfirmed delivered=E2=80=9D when an ACK is rece= ived which says > the a packet containing the frame was received by the peer > - A stream is =E2=80=9Cconfirmed closed=E2=80=9D when all data, or a R= ST_STREAM, has > been confirmed delivered to the far side and when all data or a RST_ST= REAM > has been received and the ACK is confirmed delivered > - Once a shutdown has been triggered, a connection closes silently > when all streams are either confirmed closed or idle. > > > > There is a slight race, in that a peer-initiated stream could be opened > during the shutdown wait. As others have noted, that can be handled at t= he > app layer by giving a pre-shutdown notification. > > > > However, you want to make sure that frame has been delivered. That > implies having a way for the application to wait for the ACK of a > particular piece of stream data; that=E2=80=99s not something we currentl= y require > the transport to expose, and I=E2=80=99d prefer not to make it a new requ= irement. > The application could also add an app-level ACK of some kind, or (for HTT= P) > the closing of stream 3 could be an implicit ACK. > > > > And the other question, whether we want to expose to the path that the > connection has definitively ended. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Martin Duke > *Sent:* Thursday, March 16, 2017 2:05 PM > *To:* Jana Iyengar > *Cc:* Lucas Clemente ; Ian Swett ; > IETF QUIC WG ; Martin Thomson ; > Ted Hardie > *Subject:* Re: Move GOAWAY to HTTP draft > > > > Alright, I think I'm convinced we can get rid of GOAWAY entirely. > > > > I would still like to have two types of application close (in terms of th= e > application API), one that is not graceful (immediate PUBLIC_RESET) and o= ne > that is graceful (as you describe, "wait for X sec to make sure there are > no non-PING, non-PADDING frames") that leads to a CONNECTION_CLOSE (or, a= s > I would argue in #353, a delayed Public Reset) > > > > On Wed, Mar 15, 2017 at 11:05 PM, Jana Iyengar wrote: > > I agree with what Martin (Thomson) said. The key thing to recognize is > that QUIC streams are similar to TCP connections, but the QUIC connection > is different --- it's a container. Applying TCP logic to QUIC streams mak= es > sense, but the QUIC connection itself is a different beast that doesn't > need to follow the logic of TCP connections. > > > > I have some thoughts on how to make QUIC connections seem more like > containers, at least for connection close semantics. I'll try to write up > something tomorrow. > > > > On Wed, Mar 15, 2017 at 8:48 PM, Martin Thomson > wrote: > > I don't think that "TCP-like" is the right benchmark here. That would > apply to streams, but not the entire session. > > Even in HTTP, your signal doesn't work in one direction. A server > generates streams in response to client streams. It can't say "I'm > done with creating streams, but you continue for now" without cutting > itself off from server push. You might not be sad about that, but > you'd have to admit that would be a subjective decision. > > Given that we're aiming for a general purpose protocol, we can't > guarantee that other applications will have clean transactional > semantics such that your signal will be actionable at the transport > layer. Only the application protocol knows when it is "done", so any > signal of imminent shutdown is going to be up to them. What would a > generic shutdown() do? You can't just close all open streams where > they stand and hope that the application protocol will be happy. > > The more I think about this problem, the more I am convinced that the > application needs to sort it out and then send a signal to the > transport. That signal would be "start a timer (like FIN_WAIT2), if > you don't see anything new in that time, discard state". HTTP would > do that after receiving its own "I'm done" signals on its connection > control stream and closing out any lingering streams and > retransmissions. The real signaling (a GOAWAY or analogous) would > have to be exchanged a long time before that. > > > > On 16 March 2017 at 09:06, Martin Duke wrote: > > This doesn't match my perception of the contract between a TCP-like > > transport layer and applications that use it in a "clean close", but th= en > > neither does the existing bidirectional GOAWAY. A clean close should > > indicate to the app that all written data has been received, and the pe= er > > has successfully delivered all its intended data. > > > > What QUIC needs is a signal that says "I am done creating new streams > but am > > still willing to receive new ones". Although there ought to be > stream-level > > shutdown() calls in a future socket API, but a connection-level > shutdown() > > would send this signal and also FIN all remaining streams. After both > QUIC > > endpoints clean all this up at the transport layer, there is no need fo= r > a > > further signal from the app. > > > > Forcing every app to create its own GOAWAY (or, in my vision, send-only > > GOAWAY) mechanism seems rather heavyweight if it is a common feature of= a > > clean close. > > > > On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar wrote: > >> > >> After chatting with Martin offline, it's growing on me as well. The ke= y > >> insights in my mind are: > >> > >> 1. It's preferable for each endpoint to indicate the streams it is > >> closing, to avoid requiring upper-layer retries of new streams in > flight. > >> > >> 2. The semantics of stream creation are different for different apps. > HTTP > >> generally has the client creating a stream and the server responds on > the > >> same stream. A different application can have very different > client-server > >> interactions. For instance, a client creates a stream which requires a= a > >> server to create multiple streams in response, which in turn require > further > >> client stream creations. In this case, QUIC has no idea what the "last= " > >> stream ought to be, and this needs to be indicated by the application. > >> > >> 3. Since in the general case the app protocol is expected to be involv= ed > >> in figuring out what graceful close looks like, it makes sense to > define it > >> per app. In other words, make it part of the app mapping to QUIC. For > HTTP, > >> this would be a GOAWAY frame on Stream 3. Once all streams are closed, > HTTP > >> closes Stream 3. > >> > >> 4. Graceful close by the app means that the QUIC connection can > >> immediately go into TIME_WAIT on a connection close from the app. > >> > >> It is a clean separation of concerns for sure. I'd like to ruminate on > >> this a bit, since sometimes that helps. > >> > >> This seems like good fodder for Chicago. > >> > >> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett wrote: > >>> > >>> After thinking about it more, if no one else has objections to "Make > >>> every application implement their own graceful close if they need it > and > >>> only provide a way to kill the connection immediately.", I'm fine wit= h > it as > >>> well. > >>> > >>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson < > martin.thomson@gmail.com> > >>> wrote: > >>>> > >>>> On 8 March 2017 at 03:58, Ted Hardie wrote: > >>>> > > >>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson > >>>> > > >>>> > wrote: > >>>> >> > >>>> >> I think that both are likely to run afoul of a simple problem in > >>>> >> HTTP: > >>>> >> the control stream (stream 3) can't be closed. > >>>> >> > >>>> > I don't think that's actually a problem with what I suggested. It > >>>> > simply > >>>> > means that for the HTTP mapping, the defined behavior is to send > >>>> > FIN_COMPLETE after all open requests and pushes complete. If it > >>>> > arrives > >>>> > before then, you'd have to treat it as a protocol error for the > >>>> > mapping. > >>>> > What I'm trying to avoid is baking in the requirement that > >>>> > FIN_COMPLETE (or > >>>> > its moral equivalent) always occur then, since it will make using > >>>> > other > >>>> > types > >>>> > >>>> Sure. I had inferred that you were doing this entirely at the > >>>> transport layer, which doesn't really allow you to do that. > >>> > >>> > >> > > > > > > > --001a113f5090d28419054adfe0ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike,

I agree with everything -- except= that there is no way to "confirm delivery" of an ack in the gene= ral case: you do not ack a packet consisting only of acks. This is why we n= eed some sort of timer at the end to make sure that the peer isn't stil= l retransmitting stuff due to a lost ACK.


On Thu, Mar 16, 2017 at = 2:32 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

From an endpoint level, I=E2=80=99m content with the= model of:

  • A frame is =E2=80=9Cconfirmed delivered=E2=80=9D when an ACK is receive= d which says the a packet containing the frame was received by the peer<= /u>
  • A stream is =E2=80=9Cconfirmed closed=E2=80=9D when al= l data, or a RST_STREAM, has been confirmed delivered to the far side and w= hen all data or a RST_STREAM has been received and the ACK is confirmed delivered
  • Once a shutdown has been triggered, a conn= ection closes silently when all streams are either confirmed closed or idle= .

=C2=A0

There is a slight race, in that a peer-initiated str= eam could be opened during the shutdown wait.=C2=A0 As others have noted, t= hat can be handled at the app layer by giving a pre-shutdown notification.<= u>

=C2=A0

However, you want to make sure that frame has been d= elivered.=C2=A0 That implies having a way for the application to wait for t= he ACK of a particular piece of stream data; that=E2=80=99s not something w= e currently require the transport to expose, and I=E2=80=99d prefer not to make it a new requirement.=C2=A0 The application= could also add an app-level ACK of some kind, or (for HTTP) the closing of= stream 3 could be an implicit ACK.

=C2=A0

And the other question, whether we want to expose to= the path that the connection has definitively ended.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Thursday, March 16, 2017 2:05 PM
To: Jana Iyengar <jri@google.com>
Cc: Lucas Clemente <lucas@lclemente.org>; Ian Swett <ianswett@google.com>; IETF QUIC= WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>; Ted Hardie <ted.ietf@gmail.com>
Subject: Re: Move GOAWAY to HTTP draft

=C2=A0

Alright, I think I'm convinced we can get rid of= GOAWAY entirely.

=C2=A0

I would still like to have two types of application = close (in terms of the application API), one that is not graceful (immediat= e PUBLIC_RESET) and one that is graceful (as you describe, "wait for X= sec to make sure there are no non-PING, non-PADDING frames") that leads to a CONNECTION_CLOSE (or, as I would= argue in #353, a delayed Public Reset)

=C2=A0

On Wed, Mar 15, 2017 at 11:05 PM, Jana Iyengar <<= a href=3D"mailto:jri@google.com" target=3D"_blank">jri@google.com> w= rote:

I agree with what Martin (Thomson) said. The key thi= ng to recognize is that QUIC streams are similar to TCP connections, but th= e QUIC connection is different --- it's a container. Applying TCP logic= to QUIC streams makes sense, but the QUIC connection itself is a different beast that doesn't need to follo= w the logic of TCP connections.

=C2=A0

I have some thoughts on how to make QUIC connections= seem more like containers, at least for connection close semantics. I'= ll try to write up something tomorrow.

=C2=A0

On Wed, Mar 15, 2017 at 8:48 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

I don't think that "TCP-like" is the r= ight benchmark here.=C2=A0 That would
apply to streams, but not the entire session.

Even in HTTP, your signal doesn't work in one direction.=C2=A0 A server=
generates streams in response to client streams.=C2=A0 It can't say &qu= ot;I'm
done with creating streams, but you continue for now" without cutting<= br> itself off from server push.=C2=A0 You might not be sad about that, but
you'd have to admit that would be a subjective decision.

Given that we're aiming for a general purpose protocol, we can't guarantee that other applications will have clean transactional
semantics such that your signal will be actionable at the transport
layer.=C2=A0 Only the application protocol knows when it is "done"= ;, so any
signal of imminent shutdown is going to be up to them.=C2=A0 What would a generic shutdown() do?=C2=A0 You can't just close all open streams wher= e
they stand and hope that the application protocol will be happy.

The more I think about this problem, the more I am convinced that the
application needs to sort it out and then send a signal to the
transport.=C2=A0 That signal would be "start a timer (like FIN_WAIT2),= if
you don't see anything new in that time, discard state".=C2=A0 HTT= P would
do that after receiving its own "I'm done" signals on its con= nection
control stream and closing out any lingering streams and
retransmissions.=C2=A0 The real signaling (a GOAWAY or analogous) would
have to be exchanged a long time before that.



On 16 March 2017 at 09:06, Martin Duke <martin.h.duke@gmail.com> wrote:
> This doesn't match my perception of the contract between a TCP-lik= e
> transport layer and applications that use it in a "clean close&qu= ot;, but then
> neither does the existing bidirectional GOAWAY. A clean close should > indicate to the app that all written data has been received, and the p= eer
> has successfully delivered all its intended data.
>
> What QUIC needs is a signal that says "I am done creating new str= eams but am
> still willing to receive new ones". Although there ought to be st= ream-level
> shutdown() calls in a future socket API, but a connection-level shutdo= wn()
> would send this signal and also FIN all remaining streams. After both = QUIC
> endpoints clean all this up at the transport layer, there is no need f= or a
> further signal from the app.
>
> Forcing every app to create its own GOAWAY (or, in my vision, send-onl= y
> GOAWAY) mechanism seems rather heavyweight if it is a common feature o= f a
> clean close.
>
> On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar <jri@google.com> wrote:
>>
>> After chatting with Martin offline, it's growing on me as well= . The key
>> insights in my mind are:
>>
>> 1. It's preferable for each endpoint to indicate the streams i= t is
>> closing, to avoid requiring upper-layer retries of new streams in = flight.
>>
>> 2. The semantics of stream creation are different for different ap= ps. HTTP
>> generally has the client creating a stream and the server responds= on the
>> same stream. A different application can have very different clien= t-server
>> interactions. For instance, a client creates a stream which requir= es a a
>> server to create multiple streams in response, which in turn requi= re further
>> client stream creations. In this case, QUIC has no idea what the &= quot;last"
>> stream ought to be, and this needs to be indicated by the applicat= ion.
>>
>> 3. Since in the general case the app protocol is expected to be in= volved
>> in figuring out what graceful close looks like, it makes sense to = define it
>> per app. In other words, make it part of the app mapping to QUIC. = For HTTP,
>> this would be a GOAWAY frame on Stream 3. Once all streams are clo= sed, HTTP
>> closes Stream 3.
>>
>> 4. Graceful close by the app means that the QUIC connection can >> immediately go into TIME_WAIT on a connection close from the app.<= br> >>
>> It is a clean separation of concerns for sure. I'd like to rum= inate on
>> this a bit, since sometimes that helps.
>>
>> This seems like good fodder for Chicago.
>>
>> On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett <ianswett@google.com> wrote:
>>>
>>> After thinking about it more, if no one else has objections to= "Make
>>> every application implement their own graceful close if they n= eed it and
>>> only provide a way to kill the connection immediately.", = I'm fine with it as
>>> well.
>>>
>>> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson <martin.thomson@gmail.com= >
>>> wrote:
>>>>
>>>> On 8 March 2017 at 03:58, Ted Hardie <ted.ietf@gmail.com> wrote: >>>> >
>>>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson
>>>> > <martin.thomson@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> I think that both are likely to run afoul of a si= mple problem in
>>>> >> HTTP:
>>>> >> the control stream (stream 3) can't be closed= .
>>>> >>
>>>> > I don't think that's actually a problem with = what I suggested.=C2=A0 It
>>>> > simply
>>>> > means that for the HTTP mapping, the defined behavior= is to send
>>>> > FIN_COMPLETE after all open requests and pushes compl= ete.=C2=A0 If it
>>>> > arrives
>>>> > before then, you'd have to treat it as a protocol= error for the
>>>> > mapping.
>>>> > What I'm trying to avoid is baking in the require= ment that
>>>> > FIN_COMPLETE (or
>>>> > its moral equivalent) always occur then, since it wil= l make using
>>>> > other
>>>> > types
>>>>
>>>> Sure.=C2=A0 I had inferred that you were doing this entire= ly at the
>>>> transport layer, which doesn't really allow you to do = that.
>>>
>>>
>>
>

=C2=A0

=C2=A0


--001a113f5090d28419054adfe0ec-- From nobody Thu Mar 16 16:01:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439E6129B5E for ; Thu, 16 Mar 2017 16:01: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDNbSoSQXUqx for ; Thu, 16 Mar 2017 16:01:24 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 49BD8129B53 for ; Thu, 16 Mar 2017 16:01:19 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v127so52350314qkb.2 for ; Thu, 16 Mar 2017 16:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=756nhvXnMcVjTZLiFaR9kBW36gGVoEulAQME19/2VhU=; b=GguHRpFwjw9+fkxDg4gOiywdz4ywnmdPmFaQJTbHQskKfJflTNcYc/TSa7ecW+UM+r HiSEbHH/G1OslUF3QdPjdvpi6KeMKENVP9QVE9yUNTEnPf07nKF9FRfAvl37lkDkJwUb GlffiZJnjNAOA1PY5Tmy3BS5e21VgoPSmajnD/Dsjf2ep1cV2MXjNphEFKSmb2BTqeca e5rMN5LK/5tURXgJsBh39HHWsb6x5r02inzfGOLM7EC3/4tSPu+6B0BoEd5J71UnJnDJ uy/TWTXvPlSpbtYqgP2EGTrZoxb6W8CJxPa1oArzNl6FNtp/6FXCYZQhxr96PFGHqDLF pJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=756nhvXnMcVjTZLiFaR9kBW36gGVoEulAQME19/2VhU=; b=AYqbmlFf4P1GJLWedAeCsi0xoAfP17Fk3rUlsngc7NsRhHAExcafabxKBq3JC/5liu YIxD+H2+/AZynJfEIvbnSaXwy85+mVJCPmi+1wS7rZMQkmOSmMvydQHIoDTiIaUvAfKo ArhqhSIHE5HU8ZzWL0hGQPzMAaUYHAKnq2bjFG6xQZ6iuM516ENnXv7NJ24YWdPmBopI 2bjNXTnZCiHEM65ueoM5n2udtNs9ING3sXgoADywWzlhT+VtTPAU+VulU769C5kWsMR3 OhJ8S2PmTkNPnetj6ToIVZhdNQIuvh1kJfvf/MW5upoxp6DeOEt6z6Y4jfbefYcGNd93 W7zw== X-Gm-Message-State: AFeK/H1KMKjjxXM/xXjQORqrcckjVM3upibYG81NoIbJH7QM7kT6ML3dbh59FWmvBg5FI0P/7yAMCjHNui6OBA== X-Received: by 10.55.27.219 with SMTP id m88mr9856976qkh.147.1489705278482; Thu, 16 Mar 2017 16:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 16:01:17 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 17 Mar 2017 10:01:17 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Duke Cc: Mike Bishop , Jana Iyengar , Lucas Clemente , Ian Swett , IETF QUIC WG , Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:01:26 -0000 On 17 March 2017 at 08:38, Martin Duke wrote: > > I agree with everything -- except that there is no way to "confirm delivery" > of an ack in the general case: you do not ack a packet consisting only of > acks. This is why we need some sort of timer at the end to make sure that > the peer isn't still retransmitting stuff due to a lost ACK. Yes, I agree with this. The model that I believe works best here is that you have two timers, depending on whether the application agreed to shutdown. The idle timer runs when the state that Mike described is reached, unless the application indicates that it's arranged to shutdown, and then you need a timer to deal with extra retransmissions and reordering and the like. From nobody Thu Mar 16 16:04:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ADD129B13 for ; Thu, 16 Mar 2017 16:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpYaIK-2p3fP for ; Thu, 16 Mar 2017 16:04:04 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0138.outbound.protection.outlook.com [104.47.32.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7518129B2F for ; Thu, 16 Mar 2017 16:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vFxItqxl7+oTcRMc1xNSwT1aWpGx5j1G+3x4X/zK/wE=; b=Ij5ijzjaVpAvzUwkZ2mqN8/1iZaP4FSMUVa1Hj7Yi+GZQZBLDpTl2PdaA6tgYnt/tm015utifKzktBnX+oLYUwNu8RKo19EppWNFJebjXQ+xgqQn9yP3zxvzZy88AUtCjGWNwmshxLs3i2rr2eVonQU13l8hLS/EzmdC3P2yJoE= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 16 Mar 2017 23:04:00 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Thu, 16 Mar 2017 23:04:00 +0000 From: Mike Bishop To: Martin Thomson , Martin Duke CC: Jana Iyengar , Lucas Clemente , "Ian Swett" , IETF QUIC WG , Ted Hardie Subject: RE: Move GOAWAY to HTTP draft Thread-Topic: Move GOAWAY to HTTP draft Thread-Index: AQHSlf4x+1FK6xgGX0mOGjIclw5osqGG1dGAgAAEPYCAACiUsIAAHj8AgACw04CAAJjegIAABhWAgAAGbACAAALxAIABIi8AgABqpQCAADtHAIAABrcAgAw79QCAAF+RgIAAJkMAgAD7WICAAAMe8IAABicAgAAXN4CAAABe8A== Date: Thu, 16 Mar 2017 23:04:00 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:a::5b1] x-ms-office365-filtering-correlation-id: 439e4371-c7cd-42a8-de5f-08d46cc0bbcb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:kwIl7a7ey8z4Jbnono+P1PR24vwmsKNDaqw/xkyE7A93pqB6t+njd+hWZq8BKLid/fbjOkrYVsZFt0jzIV9lefyd6Gw6rXHuHykKf/jThl6fhqpvEHJc8hrly+RzmwjlsVOhp6ismJT2IIXBTOOY1wgL1PDHGoqmv1suiRrjyDmoDPIoJSixSZCJ+EcK5J2HVGujMo8209Q51URW9afJrQBmOxOTYx3gFneHWfPunJeBVZ/9KC/9u1hvRnJP2+oWYk451ada7z0xwcSllHA1DSRlWJw/DylDNqFuCMchAYvwqaoFqlbJ7sYMABJxHAKjfcLs1N8+GtZz6OGUGIde29H67e+GpaMpTlkc6T21LV4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6042181)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(122556002)(6246003)(2906002)(9686003)(53936002)(39060400002)(4326008)(189998001)(102836003)(7736002)(10090500001)(33656002)(74316002)(6116002)(76176999)(3280700002)(5660300001)(55016002)(99286003)(8990500004)(2900100001)(3660700001)(2950100002)(10290500002)(5005710100001)(54906002)(7696004)(38730400002)(54356999)(8676002)(77096006)(93886004)(6436002)(86362001)(25786008)(229853002)(86612001)(6506006)(81166006)(50986999)(8936002)(305945005)(53546008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 23:04:00.3140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:04:07 -0000 QnV0IGlzbuKAmXQgcmVtb3ZhbCBvZiBTVE9QX1dBSVRJTkcgcHJlZGljYXRlZCBvbiBnZXR0aW5n IEFDS3Mgb2YgdGhlIEFDSyBmcmFtZXMgZXZlbnR1YWxseT8gIEJ1dCBJIGd1ZXNzIHRoYXQgcHJl c3VtZXMgdGhlcmUgd2lsbCBiZSBvdGhlciB0cmFmZmljIHRyaWdnZXJpbmcgQUNLIGdlbmVyYXRp b24gZXZlbnR1YWxseSwgd2hpY2ggd2lsbCB0aGVuIG1lbnRpb24gdGhlIEFDSy1vbmx5IHBhY2tl dC4NCg0KV2XigJlyZSByZWNvbW1lbmRpbmcgdGhlIHVzZSBvZiBXSU5ET1dfVVBEQVRFIG9yIFBJ TkcgdG8gdHJpZ2dlciBhbiBBQ0sgaWYgeW91IG5lZWQgb25lIOKAkyBwZXJoYXBzIHdlIHNob3Vs ZCBub3RlIHRoYXQgZHVyaW5nIHNodXRkb3duLCB5b3UgU0hPVUxEIHRyaWdnZXIgQUNLcyBzbyB5 b3UgY2FuIHZlcmlmeSBmaW5hbCBjbG9zdXJlLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21d IA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE2LCAyMDE3IDQ6MDEgUE0NClRvOiBNYXJ0aW4gRHVr ZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlz aG9wQG1pY3Jvc29mdC5jb20+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPjsgTHVjYXMg Q2xlbWVudGUgPGx1Y2FzQGxjbGVtZW50ZS5vcmc+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2ds ZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBUZWQgSGFyZGllIDx0ZWQuaWV0 ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogTW92ZSBHT0FXQVkgdG8gSFRUUCBkcmFmdA0KDQpP biAxNyBNYXJjaCAyMDE3IGF0IDA4OjM4LCBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFp bC5jb20+IHdyb3RlOg0KPg0KPiBJIGFncmVlIHdpdGggZXZlcnl0aGluZyAtLSBleGNlcHQgdGhh dCB0aGVyZSBpcyBubyB3YXkgdG8gImNvbmZpcm0gZGVsaXZlcnkiDQo+IG9mIGFuIGFjayBpbiB0 aGUgZ2VuZXJhbCBjYXNlOiB5b3UgZG8gbm90IGFjayBhIHBhY2tldCBjb25zaXN0aW5nIG9ubHkg DQo+IG9mIGFja3MuIFRoaXMgaXMgd2h5IHdlIG5lZWQgc29tZSBzb3J0IG9mIHRpbWVyIGF0IHRo ZSBlbmQgdG8gbWFrZSANCj4gc3VyZSB0aGF0IHRoZSBwZWVyIGlzbid0IHN0aWxsIHJldHJhbnNt aXR0aW5nIHN0dWZmIGR1ZSB0byBhIGxvc3QgQUNLLg0KDQoNClllcywgSSBhZ3JlZSB3aXRoIHRo aXMuICBUaGUgbW9kZWwgdGhhdCBJIGJlbGlldmUgd29ya3MgYmVzdCBoZXJlIGlzIHRoYXQgeW91 IGhhdmUgdHdvIHRpbWVycywgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIGFwcGxpY2F0aW9uIGFn cmVlZCB0byBzaHV0ZG93bi4gIFRoZSBpZGxlIHRpbWVyIHJ1bnMgd2hlbiB0aGUgc3RhdGUgdGhh dCBNaWtlIGRlc2NyaWJlZCBpcyByZWFjaGVkLCB1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIGluZGlj YXRlcyB0aGF0IGl0J3MgYXJyYW5nZWQgdG8gc2h1dGRvd24sIGFuZCB0aGVuIHlvdSBuZWVkIGEg dGltZXIgdG8gZGVhbCB3aXRoIGV4dHJhIHJldHJhbnNtaXNzaW9ucyBhbmQgcmVvcmRlcmluZyBh bmQgdGhlIGxpa2UuDQo= From nobody Thu Mar 16 16:27:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26F4129B59 for ; Thu, 16 Mar 2017 16:27:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 s3A1NunJxw-o for ; Thu, 16 Mar 2017 16:27:46 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD2A129A9B for ; Thu, 16 Mar 2017 16:27:46 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n11so3804134wma.0 for ; Thu, 16 Mar 2017 16:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JBdw37VJL8ZT6tZSfsHahu9VcU1NMdSC1bhT04KX25Y=; b=aF6gM64aMQvJ7kC1CElM0f0guKX8JuXvjcJwWUcPJm1OP1R6+Q2jHGe8WSjG9CO8eB 1m5uF/6l3GOgIXfwO8uKkq29HWvNnJ1gnSaETChqKF+54UrinKzfjwY698torPqVE7NU emDjvqZVezJLyU97nf4qaFQqIvYhKbEEI0SBNXw/tcqKMUxh70k5qjtoifiimrwWerN0 7f3XW1LBU1hF6NkPMTzUmunFh1cWyLSayK6pa6vrasmU6eYQjGf3BxH38c8J1MYG0mow c9NefRkgMtlsWXmYGP3lzkEiDOSLp9DklKWhkNaygimndM7SHsY1qdepog0nnn5MOy5S nKbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JBdw37VJL8ZT6tZSfsHahu9VcU1NMdSC1bhT04KX25Y=; b=MEOVHWjyCDUatym/zfmvDLRdI2NXwpsBK04cMgzMwDMt3aSOb/hesDffH6e03iTvWj lorK3ZHwKkK3vzN6D3ylNQi4DwwiCXwMNiZAt9B0Y+On7UebarvVAwrKDcB0zz4eKFS5 H20Ut4+Zw5Vp0Ey4LnIlx97sn7QC9nuPhw2JojTsxhN7vET9NZq4Q13t2g4fKQ0czTCl 7gDTdy6ix+TKZjS6oMlBBb2g88BnZaCg4+VHbgYgycs4yA8bEO9RzECcLPm3Bs1NSWUP lJtjStrZMqpObzM65qX9AjHAzPX4AzWs0MxAHRwwePXcYLmSU0djtMa8YxyaakORFwyh vc6w== X-Gm-Message-State: AFeK/H2QxHntT5AVRBX9T3NXLOnAWfFACEDXl7DK1kBYTW6GFrSnSgQFehgql3rcWJXFkD10Kvvaa4gx0IhX+tsL X-Received: by 10.28.136.204 with SMTP id k195mr177542wmd.99.1489706864911; Thu, 16 Mar 2017 16:27:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.19.7 with HTTP; Thu, 16 Mar 2017 16:27:43 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 16 Mar 2017 16:27:43 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Mike Bishop Cc: Martin Thomson , Martin Duke , Jana Iyengar , Ian Swett , IETF QUIC WG , Lucas Clemente , Ted Hardie Content-Type: multipart/alternative; boundary=001a114431d4812011054ae168af Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:27:48 -0000 --001a114431d4812011054ae168af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop wrote: > But isn=E2=80=99t removal of STOP_WAITING predicated on getting ACKs of t= he ACK > frames eventually? =E2=80=8BEventually yes. Immediately, no.=E2=80=8B > But I guess that presumes there will be other traffic triggering ACK > generation eventually, which will then mention the ACK-only packet. > =E2=80=8BExactly! An ACK *will* eventually be acknowledged. But it won't be= the result of an ACK-only packet being received by the peer (since those never solicit an ACK in response). --001a114431d4812011054ae168af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:
=
But isn=E2=80=99t removal of STOP_WAITING pr= edicated on getting ACKs of the ACK frames eventually?=C2=A0
<= div>
=E2=80=8BEventually yes. Immediately, no.=E2= =80=8B
=C2=A0
But I gu= ess that presumes there will be other traffic triggering ACK generation eve= ntually, which will then mention the ACK-only packet.
=
=E2=80=8BExactly! An ACK will eventually be ac= knowledged. But it won't be the result of an ACK-only packet being rece= ived by the peer (since those never solicit an ACK in response).
--001a114431d4812011054ae168af-- From nobody Thu Mar 16 19:08:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81073129BB3 for ; Thu, 16 Mar 2017 19:08:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 i8DjBmIF-pu3 for ; Thu, 16 Mar 2017 19:08:27 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5469212002E for ; Thu, 16 Mar 2017 19:08:27 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id d188so34119968vka.0 for ; Thu, 16 Mar 2017 19:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mqwYunSWKyjI9/R5YOeEpMWdT//vZuMHb9pMPRdF3Rk=; b=DGCAcKcCV1ehsXW2G1OQy9pBc3/PTsHYF1AFJXNSoTmoQ+612Lc2rz3uiBFLmf8rgz i6q9v59j/bPZ73WXR2456AM0Qf+MpllMHgiwpDykOF80aJTxIxIOlcobE3Od9d9CKb7+ aWjJq2KFmBaQlJcgr45B9jjLCwRbgvoWApqWeS1mEfD3Rs1SAKyyCi+M3on69hvsSq9p BohVQKdPaplkT9f5zRgb7mGt2vVjDcmSFmrGP71w21TJrcrCVYmm1Up288ByjdoB38ER vKEDb6D4W/ADHUfzY5N9bex26iB8Qt9OVHmQhUzamzBMKDnotz13hgPKyhUcCkkQCkTa Bopg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mqwYunSWKyjI9/R5YOeEpMWdT//vZuMHb9pMPRdF3Rk=; b=iPe/gAr2T1+TKF1NlvXHjc6cJDSyIp6C76EZxdVnGjSKh6WGSEauiOXAbdJA9uCYeT szczYZHGGQEEbPpr/8WjxAmt+YyTxdkUyIzsk2qbnn7d0ARKiaFESczYrDWEKe/QBmw8 8osKCdybodd7VBpNqN0HEIvt0YV6yOBOQ2XytEUKGC9WhgSXu6ycEixmVEAgrMYTCoDh oNq2cY8XLFuMX/8Izj+2kGGIrAlL3hVl8NTJVL4Rm1Qjh6TNhAO0MgGEglyqdL/Jal+1 ZzRWzmdn278NlJ9+MsEOvOoCzduQUDA0/Cb3bLX97YQjgMaqYLBJKBvsF1n1cBMOCaeP trbA== X-Gm-Message-State: AFeK/H1s2X6PS0KNXyV75eg8qE3QJwMCM7LOH+Hu4Bnd6Lqe9EFVVZfrnkCS9rcqcdN+wUL06Ef88ybius29RQUq X-Received: by 10.31.69.129 with SMTP id s123mr1445469vka.151.1489716506050; Thu, 16 Mar 2017 19:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 16 Mar 2017 19:08:25 -0700 (PDT) Received: by 10.103.15.6 with HTTP; Thu, 16 Mar 2017 19:08:25 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Thu, 16 Mar 2017 19:08:25 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Ryan Hamilton Cc: Ted Hardie , Ian Swett , Mike Bishop , Martin Duke , Martin Thomson , Lucas Clemente , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114da5c4291ed8054ae3a7c7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 02:08:29 -0000 --001a114da5c4291ed8054ae3a7c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was trying to come up with a coherent way to capture these cases (thanks Ryan, Ian and Martin for offline discussions). A few iterations later, I have a simplified proposal. When an app calls close() on a QUIC connection, the transport immediately tears down all state. We have to account for closing after idle and for the equivalent of a FIN_WAIT to retransmit or ack retransmissions. Before describing that, I'll define two time periods. IDLE is the amount of time that an endpoint closes the connection after, and DRAIN is the amount of time that an endpoint retransmits or sends acks of retransmissions at the tail of the connection. After all streams are closed (via FIN or RST_STREAM), the app is responsible for idle close. Assuming that the app negotiates this IDLE timeout value (or we could negotiate this in QUIC and expose it to the app, but that seems unnecessary), it waits for IDLE time, and then closed the connection. Importantly, neither endpoint initiates new streams after IDLE - DRAIN time has passed. Of course, if a new stream is created during this period, the app is out of idle. When the app wants to gracefully close the connection, the app peers can agree in some manner to close the connection, by closing Stream 3 in HTTP for example. The app waits for DRAIN time after all streams are closed and then closes the connection. Finally, we have the QUIC connection close, which I'll call error close here, since that's what it really is. On error close, we could do one of two things. QUIC could call back into the app, the app waits DRAIN period, and the app then closes the connection. Alternatively, QUIC could have a timer here that waits for DRAIN amount of time and then kills itself. I much prefer the first idea since it keeps the waiting logic entirely inside the app for all cases. This proposal would basically remove any waiting inside QUIC and moves that entire logic to the application. I could be missing something here, so I'd like to think about this some more. But y'all could poke holes in this sooner, so I'm sharing. I'm happy to write this in a separate email thread and/or a PR and/or issue, but airing this here for now. What do you think? Plausible? - jana On Mar 16, 2017 4:27 PM, "Ryan Hamilton" wrote: > =E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > >> But isn=E2=80=99t removal of STOP_WAITING predicated on getting ACKs of = the ACK >> frames eventually? > > > =E2=80=8BEventually yes. Immediately, no.=E2=80=8B > > >> But I guess that presumes there will be other traffic triggering ACK >> generation eventually, which will then mention the ACK-only packet. >> > > =E2=80=8BExactly! An ACK *will* eventually be acknowledged. But it won't = be the > result of an ACK-only packet being received by the peer (since those neve= r > solicit an ACK in response). > --001a114da5c4291ed8054ae3a7c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was trying to come up with a coherent way to capture th= ese cases (thanks Ryan, Ian and Martin for offline discussions). A few iter= ations later, I have a simplified proposal.

When an app calls close() on a QUIC connection, the transport= immediately tears down all state.

We have to account for closing after idle and for the equivalent= of a FIN_WAIT to retransmit or ack retransmissions. Before describing that= , I'll define two time periods. IDLE is the amount of time that an endp= oint closes the connection after, and DRAIN is the amount of time that an e= ndpoint retransmits or sends acks of retransmissions at the tail of the con= nection.

After all strea= ms are closed (via FIN or RST_STREAM), the app is responsible for idle clos= e. Assuming that the app negotiates this IDLE timeout value (or we could ne= gotiate this in QUIC and expose it to the app, but that seems unnecessary),= it waits for IDLE time, and then closed the connection. Importantly, neith= er endpoint initiates new streams after IDLE - DRAIN time has passed. Of co= urse, if a new stream is created during this period, the app is out of idle= .

When the app wants to = gracefully close the connection,=C2= =A0the app peers can agree in some manner to close the connection, by closi= ng Stream 3 in HTTP for example. The app waits=C2=A0for DRAIN time a= fter all streams are closed and then closes the connection.

Finally, we have the QUIC connection = close, which I'll call error close here, since that's what it reall= y is. On error close, we could do one of two things. QUIC could call back i= nto the app, the app waits DRAIN period, and the app then closes the connec= tion. Alternatively, QUIC could have a timer here that waits for DRAIN amou= nt of time and then kills itself. I much prefer the first idea since it kee= ps the waiting logic entirely inside the app for all cases.=C2=A0

This proposal would basically rem= ove any waiting inside QUIC and moves that entire logic to the application.=

I could be missing some= thing here, so I'd like to think about this some more. But y'all co= uld poke holes in this sooner, so I'm sharing. I'm happy to write t= his in a separate email thread and/or a PR and/or issue, but airing this he= re for now.

What do you = think? Plausible?

- jana=
On T= hu, Mar 9, 2017 at 7:25 AM, Mike Bishop <Michael.Bishop@microso= ft.com> wrote:

Part of me wonders whether QUIC will wind up running over port 53= for the same reason that every protocol in the world seems to run over TLS= on TCP port 443.=C2=A0 ;-)


We do have port negotiation in Alt-Svc for QUIC. It's a hammer = that's available to us :-)
I suspect we'll detect other f= ailure modes -- middleboxes that drop packets that don't look like DNS = packets. I think there's ~10% that we need to write off for any new pro= tocol at this point.


From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, March 9, 2017 4:52 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: Brian Trammell (IETF) <ietf@trammell.ch>; quic@ietf.org
Subject: Re: UDP Usage and draft-kuehlewind-quic-applicability-= 00

=C2=A0

=C2=A0

On Thu, Mar 9, 2017 at 7:48 AM, Hannes Tschofenig &l= t;Hannes.Tsc= hofenig@arm.com> wrote:

Hi Ian,

= =C2=A0

=C3=98=C2=A0 Yes, my talk was in Berlin 2016 at TSV Open(https://datatracker.ietf.org/meeting/96/agenda/tsvarea/).=C2=A0 I sent Mirja a PDF copy of the slides, but I'm not sure where they are posted.

=C3=98=C2=A0 To second what Brian said, most 'networks&#= 39; which block QUIC are corporations that are large enough to have their o= wn AS number.=C2=A0 I've never found a major ISP that blocks UDP 443.

= =C2=A0

Have you tested the results o= f using UDP on ports other than 443 and whether the blocking rate increases?

=C2=A0

=C2=A0

We have some data from about 4 years ago on this, bu= t I don't have it easily available.=C2=A0 I don't remember 443 bein= g dramatically more open than other ports.=C2=A0 In general, it seemed UDP = either was blocked or wasn't. =C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be privileg= ed. If you are not the intended recipient, please notify the sender immedia= tely and do not disclose the contents to any other person, use it for any purpose, or store or copy the informat= ion in any medium. Thank you.

=C2=A0


--94eb2c0cfd325c1ffc054a6b7b67-- From nobody Mon Mar 13 03:58:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1DA12955C for ; Mon, 13 Mar 2017 03:58:38 -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, RP_MATCHES_RCVD=-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 VbBNzRwFclcI for ; Mon, 13 Mar 2017 03:58:36 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3D712955F for ; Mon, 13 Mar 2017 03:58:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vhZbt3hPZzMrJP for ; Mon, 13 Mar 2017 11:58:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmY82odYigS1 for ; Mon, 13 Mar 2017 11:58:33 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11999.dip0.t-ipconnect.de [217.225.25.153]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA for ; Mon, 13 Mar 2017 11:58:33 +0100 (CET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 Message-Id: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> Date: Mon, 13 Mar 2017 11:58:40 +0100 To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 10:58:39 -0000 Hi all, as some of you have probably already noticed that we submitted two new = drafts=20 draft-kuehlewind-quic-manageability-00 and=20 draft-kuehlewind-quic-applicability-00=20 which are replacements for draft-kuehlewind-quic-appman as discussed in = Tokyo.=20 Beside the split we also added a little more content but given that the = protocol is still very much in change, there are still quite a few = editor notes or incomplete sections. Still we=E2=80=99d be very happy = about feedback and additional input from others and are also still = looking for additional authors! See you in Chicago! Mirja and Brian > Anfang der weitergeleiteten Nachricht: >=20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-kuehlewind-quic-manageability-00.txt > Datum: 9. M=C3=A4rz 2017 um 12:12:51 MEZ > An: "Mirja Kuehlewind" , "Brian = Trammell" , "Dan Druta" , "Mirja = K=C3=BChlewind" >=20 >=20 > A new version of I-D, draft-kuehlewind-quic-manageability-00.txt > has been successfully submitted by Mirja Kuehlewind and posted to the > IETF repository. >=20 > Name: draft-kuehlewind-quic-manageability > Revision: 00 > Title: Manageability of the QUIC Transport Protocol > Document date: 2017-03-09 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-manageability-0= 0.txt > Status: = https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/ > Htmlized: = https://tools.ietf.org/html/draft-kuehlewind-quic-manageability-00 >=20 >=20 > Abstract: > This document discusses manageability of the QUIC transport = protocol, > focusing on caveats impacting network operations involving QUIC > traffic. Its intended audience is network operators, as well as > content providers that rely on the use of QUIC-aware middleboxes, > e.g. for load balancing. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > Anfang der weitergeleiteten Nachricht: >=20 > Von: internet-drafts@ietf.org > Betreff: New Version Notification for = draft-kuehlewind-quic-applicability-00.txt > Datum: 8. M=C3=A4rz 2017 um 16:30:57 MEZ > An: "Mirja Kuehlewind" , "Brian = Trammell" , "Mirja K=C3=BChlewind" = >=20 >=20 > A new version of I-D, draft-kuehlewind-quic-applicability-00.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-kuehlewind-quic-applicability > Revision: 00 > Title: Applicability of the QUIC Transport Protocol > Document date: 2017-03-08 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-applicability-0= 0.txt > Status: = https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ > Htmlized: = https://tools.ietf.org/html/draft-kuehlewind-quic-applicability-00 >=20 >=20 > Abstract: > This document discusses the applicability of the QUIC transport > protocol, focusing on caveats impacting application protocol > development and deployment over QUIC. Its intended audience is > designers of application protocol mappings to QUIC, and implementors > of these application protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Mon Mar 13 16:21:22 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FE1129562; Mon, 13 Mar 2017 16:21:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-tls-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944727565.20417.10996806053293916766@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:21:15 -0700 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:21:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-02.txt Pages : 36 Date : 2017-03-13 Abstract: This document describes how Transport Layer Security (TLS) can be used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic . Working Group information can be found at https://github.com/quicwg ; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/tls . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-tls-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:23:00 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D814129BCE; Mon, 13 Mar 2017 16:22:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-recovery-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944737616.20300.6929514137954087335@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:22:56 -0700 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:22:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-02.txt Pages : 14 Date : 2017-03-13 Abstract: QUIC is a new multiplexed and secure transport atop UDP. QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. QUIC implements the spirit of known TCP loss detection mechanisms, described in RFCs, various Internet-drafts, and also those prevalent in the Linux TCP implementation. This document describes QUIC loss detection and congestion control, and attributes the TCP equivalent in RFCs, Internet-drafts, academic papers, and TCP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:23:26 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CFF129B24; Mon, 13 Mar 2017 16:23:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-http-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944740218.20429.9252784928604137647@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:23:22 -0700 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:23:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-02.txt Pages : 27 Date : 2017-03-13 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-http-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:25:08 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 910B5129C03; Mon, 13 Mar 2017 16:25:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-transport-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944750255.20433.16227401589493176609@ietfa.amsl.com> Date: Mon, 13 Mar 2017 16:25:02 -0700 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:25:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-02.txt Pages : 67 Date : 2017-03-13 Abstract: This document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-transport-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:58:03 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D31D129468 for ; Mon, 13 Mar 2017 16:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vyMqyXcGK73W for ; Mon, 13 Mar 2017 16:58:00 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 783C4129C5A for ; Mon, 13 Mar 2017 16:57:56 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y76so236186295qkb.0 for ; Mon, 13 Mar 2017 16:57:56 -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=7r3nwVexQTbmY271bVX92HLJ1eTNkvE+OS7giskFiaw=; b=rsQirdFlit0WAFjiupT8fxerrUWzgfeVCYZmeLHQVt9Ya27g5ETB3qsxJYexRrOkJh NLWI0aQsuXHu9nT0Nm3XmJird0x5H8mNScwA4eIPoSQsImifWPTepofVsqmF1xxqsF0q AiiCZlsLbDDVo8YzvEHjnPXXQXeZhGmNCAN8FRVO/nCnSNVQulQSDrkgTZA71OMjRthi 5Z11Kjb3609ygH3X5NDXw1pQ15n5Bcp8ayZi2fU0Usp2Q9ughIETCLmf98lxK8fgxyLR EVSHYxX4iLA1XYmM85pPfyZKqaAtRbC8DqAlodooCD27N4R2sEJX7cuTGFD31XJOgP0Q U3Hg== 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=7r3nwVexQTbmY271bVX92HLJ1eTNkvE+OS7giskFiaw=; b=M9OO2YJRgPelpOE/5HUuREafNKfXRUJVoGJ2pDq/8wmhFdLOslw0N3PSBDa71nJ8Vx 5w9N2tkaZvc69Iue7F92QFrvYri108hCyY3a2tjWOLIgd0PNXQKsDLq3ghX2C+9s0qMY nh87E8TGssb694sW4sTr/wXrF6hm9BwWl3eGJaUrik77Kf5d/+KjFombDzDaG47MjDOl QnQmRgQhbdgBPMRe8Aa3JOUv0nOrcusVSTMxKxKty21hwwdsaJQnZAWbHPsQKo0wCCpc v45f5nKlDsYCj95LL8XKhdNFEwen0xoXTmT9YXKR7R0dnqWs0MAV16WItVCF/dEnN592 RoZw== X-Gm-Message-State: AMke39kKLZOU4kOWFXtFwv5jMq++WcVYzBHmY7sEkNjH+REWOB/cWpGatqVRYF923MNE6phblPR1nO+ojWc4sQ== X-Received: by 10.55.185.131 with SMTP id j125mr33293189qkf.115.1489449475644; Mon, 13 Mar 2017 16:57:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 16:57:55 -0700 (PDT) From: Martin Thomson Date: Tue, 14 Mar 2017 10:57:55 +1100 Message-ID: Subject: Core drafts -02 out To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 23:58:01 -0000 The editors have submitted -02 versions of the base set of QUIC drafts. https://tools.ietf.org/html/draft-ietf-quic-transport-02 https://tools.ietf.org/html/draft-ietf-quic-tls-02 https://tools.ietf.org/html/draft-ietf-quic-recovery-02 https://tools.ietf.org/html/draft-ietf-quic-http-02 The list of changes is LONG. I won't even attempt to summarize the changes. There's a list of changes in an appendix in each draft. From nobody Tue Mar 14 07:46:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A626120263 for ; Tue, 14 Mar 2017 07:46:36 -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 M5g5jfG5cGE6 for ; Tue, 14 Mar 2017 07:46:34 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C865A131C2A for ; Tue, 14 Mar 2017 07:46:33 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BD480340E95 for ; Tue, 14 Mar 2017 15:46:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.11908); Tue, 14 Mar 2017 15:46:31 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Tue, 14 Mar 2017 15:46:31 +0100 (CET) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 11399777 for quic@ietf.org; Tue, 14 Mar 2017 15:46:31 +0100 From: "Brian Trammell (IETF)" X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_3DF37EED-C617-4336-BE9A-3FDC829DF50B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: on packet number echo Date: Tue, 14 Mar 2017 15:46:30 +0100 Message-Id: To: IETF QUIC WG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 14:46:36 -0000 --Apple-Mail=_3DF37EED-C617-4336-BE9A-3FDC829DF50B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, for those not watching github, there's a discussion on packet number = echo; my summary post in PR#391 is reproduced below: to summarize... there seem to be three possibilities emerging here: ### Echo (at least) once per RTT. Leave ACK frames unchanged. (This is what's written up in this PR). Rationale: What happens in the frame layer stays in the frame layer. = Packet number echo is a pure packet-layer change to the transport = protocol. Since this is additional overhead, we should work to minimize = it, hence once per RTT, the minimum frequency that works for passive = latency measurement. Upsides: It's a tiny change to the protocol as presently described, for = a low overhead cost per RTT (1-4 bytes, usually 2). The ACK frame = remains self-describing, so the ack frame handling component in an = implementation can remain separate from the packet handling component. = Endpoints can choose to echo more frequently (e.g., when configured to = do so for debugging purposes). Downsides: an echoing endpoint with a passively-cooperative peer can = intentionally skew passive measurements, since the value in the packet = header is not necessarily joined to the value in the ack frame. The = utility and practicality of such a thing is debatable. It's not clear = how good the resulting number/echo stream will be for one-point loss and = reordering estimation. ### Echo max-acked on every packet with an ACK frame, and remove it from = the ack frame. Rationale: This information already appears in the ACK layer, so there's = no additional overhead. Upsides: Echo frequency is higher; this should make loss and reordering = estimation work better at a single observation point. No additional = overhead. Downsides: Increased complexity of implementations, which have to pass = packet number echo information up the stack. No endpoint control over = how often packet numbers are echoed, since max-ack is required by the = transport mechanisms. Mixedsides (depending on your proclivities): The presence of an ACK = frame is now exposed to the path. ACK-frame-containing packets can (and = given the history of TCP, probably will) be treated differently by the = network in certain circumstances. ### Don't echo packet numbers at all (this is the no-build option) Cheers, Brian --Apple-Mail=_3DF37EED-C617-4336-BE9A-3FDC829DF50B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYyAJGAAoJEIoSt78L6kajzNMP/iJzXgsqfW6WCZjvjPKF1S8+ 6WcRZaXtyuV/Eo7EwdI6Q+/YINDA72wA0sHXf+mAnXIxj9tX21zfZgmqiMZGoOcO DzLjULLEYgLGIHAH3CEhrWm0mexyGW11lAA8oK4CDSyYg7nHziXdEZ6LjZO7Q+MU L9ShqbfnHpQULspzyi5G1hJvf+WY4SNfdih6TA1DaIUzj0b5ZOOgSNexcC/RS99c ftWM6iCDeDZMDh83gve3F1BvW5TeJPfuaxljSOSXh0kojfdIztZxBjMgScZdQ5ju 7llf3S2dAsBCaXetCAt6Tx0V61xEqRKofaAiag6iPkIWYRLLbl91nqbpoMwXLXLQ H9gbPIjjk2zNVYEYdikPl5jQ3I2fEso69hfL/zbdgoNHy8pkRYfKi9YSas44MrSD q+2pfN+bY3s0eJ0xyKWAgYSeL/xMhLYd5w7bo7yTAC/7g+tiYhQpbn58WGc2ceUY sV+Ga/2sTHVrW2FFHFdIS+U0fxlZdK6VJOmxb55jthSqCd8qbgI61ArFdb7OC6Sp 7HQMfKgA0uzDuZIhRSUbvP93TkLfYyuOFrMQihUK1VvRxqzPcvF8f0RZ/lHTNm3i waW1HyjvuKxMEC8eD1AUOSQEHMT3yW0SyU3BijGx2iwS3Y7c0E49uNj2pxglIKtX Ki61JNg+PZjlaZJ25fXt =sOA9 -----END PGP SIGNATURE----- --Apple-Mail=_3DF37EED-C617-4336-BE9A-3FDC829DF50B-- From nobody Tue Mar 14 09:31:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8BB1296FF for ; Tue, 14 Mar 2017 09:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdN7F8f8DVop for ; Tue, 14 Mar 2017 09:31:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023C7129501 for ; Tue, 14 Mar 2017 09:31:41 -0700 (PDT) X-AuditID: c1b4fb2d-2dacd98000006193-24-58c81aebd9fc Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 0F.8D.24979.BEA18C85; Tue, 14 Mar 2017 17:31:39 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 14 Mar 2017 17:30:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fit9x+7b4vv4jBr1tii8ESAQuKHBCb906ngk2W/26mg=; b=bKUFTom2dGRgup23ZLZTZ45C/rrbgQ6NkPYeOaT9h8OtRZgOdE+As5fNbHSWVD7buiMvgFkfrPCui1XoWMiwM7F0zTI4vw8ZsJZApiNN41WR1hIhHXbplFxIjIHg7NcXHLooUgdkJBgIw9T2ZrqSJmjpqs8Fjh49RHUECXxBdZ8= Received: from DB5PR07MB1271.eurprd07.prod.outlook.com (10.164.41.149) by DB5PR07MB1272.eurprd07.prod.outlook.com (10.164.41.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Tue, 14 Mar 2017 16:30:37 +0000 Received: from DB5PR07MB1271.eurprd07.prod.outlook.com ([fe80::49f1:3175:4f83:449]) by DB5PR07MB1271.eurprd07.prod.outlook.com ([fe80::49f1:3175:4f83:449%14]) with mapi id 15.01.0977.010; Tue, 14 Mar 2017 16:30:37 +0000 From: Marcus Ihlar To: "quic@ietf.org" Subject: RTTs and cellular network optimizations Thread-Topic: RTTs and cellular network optimizations Thread-Index: AdKc4AiSEj9znKaWTkOMY9pmDLnPLQ== Date: Tue, 14 Mar 2017 16:30:37 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.92] x-microsoft-exchange-diagnostics: 1; DB5PR07MB1272; 7:OSqHgGufgHCnVTp78C/qv9nt8/s0nyG3gA6VJPgspiIytIYLItb/jaw9iS3JmJg7XoMuGnY807idORfWGAlUdxbDDd6DslJy0u74pQTGnOaNB5tsGmF7Gqj6Kv6F1OfeoA5zzPRTYKywTD558nycGGXzscJg9piOxvwOx1SeZKQd3qmwVSUtv+XQ0KfO6FvWgcpPQsojenB/M16ulA2Nhl3ZQyQh2fL33JxaiwL5QdCZnb7aIkp7VJKP6J91KohJAL8YqEM466JIKY9JisTxx9fMsEBPf/vljQpPUm5us/IVEg8L8yndHmaNZ8sm0lXPhEB3fgC9PXdK+MmPURpxVA== x-ms-office365-filtering-correlation-id: b1a47ffb-acbf-4cd0-e16c-08d46af772b2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR07MB1272; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:DB5PR07MB1272; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1272; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(3660700001)(8936002)(3846002)(6306002)(99286003)(3280700002)(189998001)(9686003)(74316002)(5250100002)(81166006)(1730700003)(2351001)(5660300001)(2906002)(55016002)(54896002)(86362001)(2900100001)(102836003)(5630700001)(8676002)(2501003)(110136004)(7696004)(7736002)(5640700003)(38730400002)(6116002)(790700001)(33656002)(68736007)(54356999)(6436002)(6916009)(50986999)(53936002)(66066001)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB1272; H:DB5PR07MB1271.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB1271DD78827CF063C6AC5081E2240DB5PR07MB1271eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2017 16:30:37.6436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1272 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRiGe885Ox6ns9PSfFpKMvFHplPTVCLC/oQYmr9smGBDTyrqNnbM sqKUoPArhDLaHDltih8ZNsqJX+iWMXPkyjBYmeXsQ1Zhgoim2eaZsH/Xe9/Pc/Pc8FK4UMcT UUXyMkYll5WIST6hlhojo50iizTWvLIvuU7nl4JS9fo1LBNl84/nMyVF5Ywq5sR5fuGE7QOm /JZz2XzvBVGJ7Bk1yJcCOgEchgasBvEpIf0EQY1+hMc9LAhM3a2k+0HQ9TjMdLzEOacRA92D Oc/YFwTOzhWeO4ykJWCdrSXdHEiHg7btkY+b99KxYG03e/Sj8Gez3qVTLpbA5FCiWyboCBh5 2rwdI6BzwD61jNyM6FCYW/1EuBmng8G+0Ixxd9OgH5rCOQ6CRce/7XsQXYtg6eGMZygMNt7O b1cAug6HkVtaH85Ih0mHgdzhzb41DxfD8942T+ppML56T3DLGgyadHcQZ4RA05s6jzFPQPXd KoyrKYLZd9WI4xD48XGYx92tgLWtdYzrtgcm1AsEF5QJi58neA0oQuNVT+O1ovFa4fQo0A0u kxwfhvYWJ77D1lEH5q3rkE8XCmIZli0tOBIvYVRFeSyrkEvkTJkBuf7N2LO/0f2o23nShGgK if0FSp5FKuTJytmKUhMCChcHCpy7XJIgX1ZxhVEpclUXSxjWhA5QhDhYkNg5d1ZIF8jKmGKG UTKqHRejfEWVqDH2OjXtdybAsJS9/Hr373hbQqqJ/J43Lj3UYjOf0s1jAxcO/uoLUbTNJk2m GweyL/GV/UyXdfUmf/hYc4BBn9WfZovZms7NS0zdXB/7qU3WbmiGRHHhKcaqa+qspLBz03r/ 0KjBG3iP2tJzvzfD/Lg1Je3qfuJr4+g4dttOigm2UBYXiatY2X/YD5zuMwMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.21 Precedence: list List-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 Mar 2017 16:31:44 -0000 --_000_DB5PR07MB1271DD78827CF063C6AC5081E2240DB5PR07MB1271eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In issue 269 a case for packet number echoes is made. By having packet number echoes visible in the QUIC public header a passive = observer can get estimates of RTTs and in-flight packets. This also allows for active network optimizations that are less intrusive /= ossifying than what we typically see today. Cellular networks have typically been plagued by severe buffer bloat issues= due to lack of proper AQM functionality in the RAN. Many operators tend to deploy Performance Enhancing Proxies (PEP) as a way = to mitigate this problem. However, this solution is quite crude and require= s transparent termination of connections or manipulation of TCP segments. One possible optimization technique is a "centralized" AQM function that re= acts to increasing RTT:s. Such an AQM is a simplified form of a PEP, the ma= in difference being that the AQM does not terminate or manipulate connectio= ns in any way. We have tested this concept using TCP in a cellular network lab comparing i= t to Google-QUIC and TCP without AQM. We also ran the same tests with a TCP PEP. The PEP and AQM were deployed at= the Gi (interface point between Internet and cellular core network). The tests consisted of 10MB file downloads from Google drive using a dedica= ted server. The access consisted of a single LTE cell where the signal strength could b= e attenuated. These tests showed a significant decrease in buffer induced latency while h= aving small visible impact on throughput. We also saw that QUIC would greatly benefit from AQM when using a loss-base= d CCA over LTE. The centralized AQM had similar effects on buffer-induced latency as the TC= P Proxy See test result details below: Minimum RTT between server and device was ~50ms, RTT between server and PEP= / AQM is ~30ms. The measurements were performed at the server side except for the PEP case = where measurements were made at the proxy. Since the PEP terminates TCP tra= ffic we have added the server-proxy RTT to the PEP results. Full signal strength - Single user in cell TCP - Median RTT: 161ms, p95 RTT: 294ms QUIC - Median RTT: 60ms, p95 RTT: 72ms TCP + AQM - Median RTT: 88ms, p95 RTT: 112ms TCP + PEP - Median RTT: 65ms, p95 RTT: 170ms Full signal strength - Multiple users in cell TCP - Median RTT: 429ms, p95 RTT: 900ms QUIC - Median RTT: 342ms, p95 RTT: 594ms TCP + AQM - Median RTT: 91ms, p95 RTT: 127ms TCP + PEP - Median RTT: 75ms, p95 RTT: 200ms Weak signal strength - Single user in cell TCP - Median RTT: 279ms, p95 RTT: 405ms QUIC - Median RTT: 362ms, p95 RTT: 690ms TCP + AQM - Median RTT: 88ms, p95 RTT: 117ms TCP + PEP - Median RTT: 79ms, p95 RTT: 207ms Weak signal strength - Multiple users in cell TCP - Median RTT: 413ms, p95 RTT: 990ms QUIC - Median RTT: 717ms, p95 RTT: 1051ms TCP + AQM - Median RTT: 93ms, p95 RTT: 125ms TCP + PEP - Median RTT: 85ms, p95 RTT: 220ms //Marcus Ihlar --_000_DB5PR07MB1271DD78827CF063C6AC5081E2240DB5PR07MB1271eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

In issue 269 a case for packet = number echoes is made.

By having packet number echoes = visible in the QUIC public header a passive observer can get estimates of R= TTs and in-flight packets.

This also allows for active net= work optimizations that are less intrusive / ossifying than what we typical= ly see today.

Cellular networks have typicall= y been plagued by severe buffer bloat issues due to lack of proper AQM func= tionality in the RAN.

Many operators tend to deploy P= erformance Enhancing Proxies (PEP) as a way to mitigate this problem. Howev= er, this solution is quite crude and requires transparent termination of co= nnections or manipulation of TCP segments.

One possible optimization techn= ique is a “centralized” AQM function that reacts to increasing = RTT:s. Such an AQM is a simplified form of a PEP, the main difference being= that the AQM does not terminate or manipulate connections in any way.

 

We have tested this concept usi= ng TCP in a cellular network lab comparing it to Google-QUIC and TCP withou= t AQM.

We also ran the same tests with= a TCP PEP. The PEP and AQM were deployed at the Gi (interface point betwee= n Internet and cellular core network).

The tests consisted of 10MB fil= e downloads from Google drive using a dedicated server.

The access consisted of a singl= e LTE cell where the signal strength could be attenuated.=

 

These tests showed a significan= t decrease in buffer induced latency while having small visible impact on t= hroughput.

We also saw that QUIC would gre= atly benefit from AQM when using a loss-based CCA over LTE.

The centralized AQM had similar= effects on buffer-induced latency as the TCP Proxy

 

See test result details below:<= o:p>

Minimum RTT between server and = device was ~50ms, RTT between server and PEP / AQM is ~30ms.

The measurements were performed= at the server side except for the PEP case where measurements were made at= the proxy. Since the PEP terminates TCP traffic we have added the server-p= roxy RTT to the PEP results.

 

Full signal strength –= Single user in cell

TCP         =      - Median RTT: 161ms, p95 RTT: 294ms

QUIC    &nb= sp;       - Median RTT: 60ms,   p95= RTT: 72ms

TCP + AQM - Median RTT: 88ms,   p95 RT= T: 112ms

TCP + PEP   - Median RTT: 65ms,  =  p95 RTT: 170ms

 

Full signal strength –= Multiple users in cell

TCP         =      - Median RTT: 429ms, p95 RTT: 900ms

QUIC    &nb= sp;       - Median RTT: 342ms, p95 RTT: 594ms=

TCP + AQM - Median RTT: 91ms,   p95 RT= T: 127ms

TCP + PEP   - Median RTT: 75ms,  =  p95 RTT: 200ms

 

Weak signal strength –= Single user in cell

TCP         =      - Median RTT: 279ms, p95 RTT: 405ms

QUIC    &nb= sp;       - Median RTT: 362ms, p95 RTT: 690ms=

TCP + AQM - Median RTT: 88ms,   p95 RT= T: 117ms

TCP + PEP   - Median RTT: 79ms,  =  p95 RTT: 207ms

 

Weak signal strength –= Multiple users in cell

TCP         =      - Median RTT: 413ms, p95 RTT: 990ms

QUIC    &nb= sp;       - Median RTT: 717ms, p95 RTT: 1051m= s

TCP + AQM - Median RTT: 93ms,   p95 RT= T: 125ms

TCP + PEP   - Median RTT: 85ms,  =  p95 RTT: 220ms

 

//Marcus Ihlar

--_000_DB5PR07MB1271DD78827CF063C6AC5081E2240DB5PR07MB1271eurp_-- From nobody Tue Mar 14 16:57:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B70C12945F for ; Tue, 14 Mar 2017 16:57:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WIUr_JPRCIKb for ; Tue, 14 Mar 2017 16:57:12 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 D9C101316DC for ; Tue, 14 Mar 2017 16:57:11 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o4so979318ywd.3 for ; Tue, 14 Mar 2017 16:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vfVKsEKhM6Ixg8JGwDtpg2JjN0XwuNT/doBkGqZR5u0=; b=SFEVIag0FApCTN0LOkA53bRzXgYZk6wjXgPr4KKvHha0t5bIf0lrglHlpS5bSm+hie s+Tw2iUOTuI2NuqgtRnEc1rs9EhU2+SbpzM5jqVNj5ijnulS+DMmU1sGXdH7XYDXQiR7 ONDZMLg/5tkuWI3EIg/EInbebTLW9fj3aom9NUqhCJRj2zpB2xn6cyl0bj8hoC3p9/mq eq6eA3fDQjKGjWKmO4Yas+Rvv+TzJKw3ws6I19dwOR43FWB7ZjwSfjwGb8GTG1kg+vfo D1TLc9FzuoLVHHnvGXw0oKI2Krq2mYsoxDNhsVV5MSlvJY9UoqVKh8R2oBC/pgHakvjZ nB7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vfVKsEKhM6Ixg8JGwDtpg2JjN0XwuNT/doBkGqZR5u0=; b=aWfc8THPeelG6fV9VPOLMvktT2AdoILKZ5CoP/YLhltYgf+B0kRxpXwSJPVx2EJDmT rAGy6ggyOr5W3AHnyyHFTyF+9+huNSCR+sazI24Opcp7rcJolF3ISD5kwydN9Y/1PzXb Z3BZQsB4nfb1LQdDHdQSSeaNCak28CBG1JWSh+wuhevZN75KSW56gD+Ey7kg2h9h0Tjd I5RLS13a9X0a/n6NcJeQwtRhm9dOiWhe/aZYb8wfqqDQzuXjewShL+v4Nz2xm+E2YfN+ /FCazhy72rTK6N0b13BlWze6YlVae5G90hciLL6zvKCakyPYzkhprGugjo0z7SmaqrAr JXqg== X-Gm-Message-State: AFeK/H1b/wr1mDIiVTpKCnvlDGFRK6pirD3TkiB7HutdEobVXzoQxJAWSjRkiDlkSpuM2DbKihzV2N+d+sUQHkEb X-Received: by 10.129.39.206 with SMTP id n197mr262631ywn.304.1489535830908; Tue, 14 Mar 2017 16:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.203 with HTTP; Tue, 14 Mar 2017 16:56:50 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Tue, 14 Mar 2017 19:56:50 -0400 Message-ID: Subject: Re: on packet number echo To: "Brian Trammell (IETF)" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1141f722152cf3054ab99681 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:57:14 -0000 --001a1141f722152cf3054ab99681 Content-Type: text/plain; charset=UTF-8 Thanks for summarizing this Brian. The first option means that an implementation could not send the echo, for example if a network was using it in a way that was harmful to users. This provides an incentive for networks that do use it to either do nothing active with it or use it to improve user experience. (see Marcus Ihlar's thread for that) I think the largest upside(or downside, depending upon your perspective) of the second option where the largest acked is included with every frame is that it means one MUST implement this correctly to implement QUIC, at least if they want to use the standard ack frame. Personally, my largest concern with the second case is that of differential treatment of acks. What if an ack packet contains other data, and a middlebox decides that only the most recent ack needs to be delivered(a common TCP approach), so the data bundled with the ack is inadvertently lost? At this point, I lean towards the first option, because I understand the implications better, but I could be convinced otherwise. Either way, I think both of these are potentially worthy of including and I think they're preferable to doing nothing. On Tue, Mar 14, 2017 at 10:46 AM, Brian Trammell (IETF) wrote: > Greetings, all, > > for those not watching github, there's a discussion on packet number echo; > my summary post in PR#391 is reproduced below: > > to summarize... there seem to be three possibilities emerging here: > > ### Echo (at least) once per RTT. Leave ACK frames unchanged. > > (This is what's written up in this PR). > > Rationale: What happens in the frame layer stays in the frame layer. > Packet number echo is a pure packet-layer change to the transport protocol. > Since this is additional overhead, we should work to minimize it, hence > once per RTT, the minimum frequency that works for passive latency > measurement. > > Upsides: It's a tiny change to the protocol as presently described, for a > low overhead cost per RTT (1-4 bytes, usually 2). The ACK frame remains > self-describing, so the ack frame handling component in an implementation > can remain separate from the packet handling component. Endpoints can > choose to echo more frequently (e.g., when configured to do so for > debugging purposes). > > Downsides: an echoing endpoint with a passively-cooperative peer can > intentionally skew passive measurements, since the value in the packet > header is not necessarily joined to the value in the ack frame. The utility > and practicality of such a thing is debatable. It's not clear how good the > resulting number/echo stream will be for one-point loss and reordering > estimation. > > ### Echo max-acked on every packet with an ACK frame, and remove it from > the ack frame. > > Rationale: This information already appears in the ACK layer, so there's > no additional overhead. > > Upsides: Echo frequency is higher; this should make loss and reordering > estimation work better at a single observation point. No additional > overhead. > > Downsides: Increased complexity of implementations, which have to pass > packet number echo information up the stack. No endpoint control over how > often packet numbers are echoed, since max-ack is required by the transport > mechanisms. > > Mixedsides (depending on your proclivities): The presence of an ACK frame > is now exposed to the path. ACK-frame-containing packets can (and given the > history of TCP, probably will) be treated differently by the network in > certain circumstances. > > ### Don't echo packet numbers at all > > (this is the no-build option) > > > > Cheers, > > Brian > > --001a1141f722152cf3054ab99681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for summarizing this Brian.

The = first option means that an implementation could not send the echo, for exam= ple if a network was using it in a way that was harmful to users.=C2=A0 Thi= s provides an incentive for networks that do use it to either do nothing ac= tive with it or use it to improve user experience. (see Marcus Ihlar's = thread for that)

I think the largest upside(or= downside, depending upon your perspective) of the second option where the = largest acked is included with every frame is that it means one MUST implem= ent this correctly to implement QUIC, at least if they want to use the stan= dard ack frame.

Personally, my largest concern wit= h the second case is that of differential treatment of acks.=C2=A0 What if = an ack packet contains other data, and a middlebox decides that only the mo= st recent ack needs to be delivered(a common TCP approach), so the data bun= dled with the ack is inadvertently lost?

At this p= oint, I lean towards the first option, because I understand the implication= s better, but I could be convinced otherwise.

Eith= er way, I think both of these are potentially worthy of including and I thi= nk they're preferable to doing nothing.


On Tue, Mar 14, 2017 at 10:= 46 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
Greetings, all,

for those not watching github, there's a discussion on packet number ec= ho; my summary post in PR#391 is reproduced below:

to summarize... there seem to be three possibilities emerging here:

### Echo (at least) once per RTT. Leave ACK frames unchanged.

(This is what's written up in this PR).

Rationale: What happens in the frame layer stays in the frame layer. Packet= number echo is a pure packet-layer change to the transport protocol. Since= this is additional overhead, we should work to minimize it, hence once per= RTT, the minimum frequency that works for passive latency measurement.

Upsides: It's a tiny change to the protocol as presently described, for= a low overhead cost per RTT (1-4 bytes, usually 2). The ACK frame remains = self-describing, so the ack frame handling component in an implementation c= an remain separate from the packet handling component. Endpoints can choose= to echo more frequently (e.g., when configured to do so for debugging purp= oses).

Downsides: an echoing endpoint with a passively-cooperative peer can intent= ionally skew passive measurements, since the value in the packet header is = not necessarily joined to the value in the ack frame. The utility and pract= icality of such a thing is debatable. It's not clear how good the resul= ting number/echo stream will be for one-point loss and reordering estimatio= n.

### Echo max-acked on every packet with an ACK frame, and remove it from th= e ack frame.

Rationale: This information already appears in the ACK layer, so there'= s no additional overhead.

Upsides: Echo frequency is higher; this should make loss and reordering est= imation work better at a single observation point.=C2=A0 No additional over= head.

Downsides: Increased complexity of implementations, which have to pass pack= et number echo information up the stack. No endpoint control over how often= packet numbers are echoed, since max-ack is required by the transport mech= anisms.

Mixedsides (depending on your proclivities): The presence of an ACK frame i= s now exposed to the path. ACK-frame-containing packets can (and given the = history of TCP, probably will) be treated differently by the network in cer= tain circumstances.

### Don't echo packet numbers at all

(this is the no-build option)



Cheers,

Brian


--001a1141f722152cf3054ab99681-- From nobody Wed Mar 15 06:22:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62828130A92 for ; Wed, 15 Mar 2017 06:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=AZGxPQPO; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=PfCydsVP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd_ZW-ZreDIE for ; Wed, 15 Mar 2017 06:22:27 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B3F129C00 for ; Wed, 15 Mar 2017 06:22:26 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id 46F5015A3262; Wed, 15 Mar 2017 14:22:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489584145; bh=u86q9roZ5UjyMRaH+Xj1OyKbMoThQG7bfWB1niBgFks=; h=From:Subject:Date:References:To:In-Reply-To:From; b=AZGxPQPO/RDTk6Dc4cfwlQT8Zh5BzD/JFBMhECYaFhT5Kv3NbRk2PHHG4CNmYurw+ prvGoyxIQ0o61YfRyQavNQw/JxAe62NRh1X+z9uXk5S4BIsYT088o58+cf5nu7m67n MM4f/1/iT6xV8nHDzpmiFIQu3rlV9eC2+uLty9EA= Received: from delight.greenbytes.local (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 8933815A066B; Wed, 15 Mar 2017 14:22:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1489584143; bh=u86q9roZ5UjyMRaH+Xj1OyKbMoThQG7bfWB1niBgFks=; h=From:Subject:Date:References:To:In-Reply-To:From; b=PfCydsVP8800PHL6P0J0dBa1Z+6YEzOlSrsEZerxLmWbTD7MCH282kFZjveoB2rUq RBIfs+sLIsuYS9b8ABxTBfjR/aXPKTslK/FhKgYBslU+hBHp2Vi1LIecEfqofJdtRi z+4n7HG65tEhjanscOSaNHvZLDKPkXY8MEq8N998= From: Stefan Eissing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Core drafts -02 out Date: Wed, 15 Mar 2017 14:22:23 +0100 References: To: Martin Thomson , IETF QUIC WG In-Reply-To: Message-Id: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 13:22:29 -0000 > Am 14.03.2017 um 00:57 schrieb Martin Thomson = : >=20 > The editors have submitted -02 versions of the base set of QUIC = drafts. [...] > https://tools.ietf.org/html/draft-ietf-quic-http-02 Thanks, Martin! I assume that was announced to get feedback from the = lurkers here. ;-) I'll give this a try. All mistakes and misunderstandings are mine alone. = --------------------------------------------------------------------------= --------------- Very well written spec. Easy to understand for someone having read rfc = 7540 a bit.=20 I have some comments to the proposed HTTP mapping approach. Where the wg = has already discussed and exhausted alternatives, please excuse my = ignorance and ignore my comments. I had not the time to follow all = discussions ongoing on this topic. Feel free to cherry-pick what seems = helpful. > 4. Stream Mapping and Usage +1 to directly using quic stream ids instead of virtual h2 stream = identifier However, using 2 quic streams for a single request/response does not sit = well with me. I assume that stems from the wish to get rid of DATA = frames. Which sounds nice, but is it worth it? By doubling the # of = streams for a client, how much overhead does that introduce (I speak of = a server holding >10k quic "connections")? Also, the server needs to buffer data on quic streams 7, 11, 15, etc. = because HEADERs might arrive some time in the future on streams 5, 9, = 13, etc. or not. There is no way to route this data somewhere, because = the meta information is still missing. And there is still Holb on: > 4.2.1. Header Compression > ... > DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- > invariant? How much do we need to retain compatibility with > HTTP/2's HPACK? Using a counter in HEADERS is a crutch: - it is a highly specific solution to a common problem in http/quic: = synchronicity in connection level state changes. SETTINGS (see below) = has the same problem, as does have PRIORITY in HEADERS. It seems that = performance wise, all HEADERS could as well be sent on stream 3.=20 Now, solving Hol blocking for HEADERS would be a fine achievement.=20 > 5. HTTP Framing Layer > Frames are used only on the connection (stream 3) and message > (streams 5, 9, etc.) control streams.=20 And streams 4, 8, 12, etc. I assume. > 5.2.3. SETTINGS > ... > SETTINGS frames always apply to a connection, never a single stream. > A SETTINGS frame MUST be sent as the first frame of the connection > control stream (see Section 4) by each peer, and MUST NOT be sent > subsequently or on any other stream. If an endpoint receives an > SETTINGS frame on a different stream, the endpoint MUST respond with > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an > endpoint receives a second SETTINGS frame, the endpoint MUST respond > with a connection error of type HTTP_MULTIPLE_SETTINGS. What about HPACK state? The connection state change problem again = visible. This is a severe restriction on extensions mechanisms that want to = affect a connection. Because if the http/quic does not solve this = problem, how are they expected to do it? They either announce themselves = on the first SETTINGS or remain silent forever, it seems. How would an = extension handshake work then? Own stream 3 handshake frames? > 5.2.3.3. Usage in 0-RTT What about HPACK state? Does it need to be kept or is it reset? > HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push > content which the client has cached. > ... > HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the > requested data. Nitpick: seems redundant. The first could be replaced by the second. = Stream number will suffice. ---------------------------------------------------------- Taking two steps back: I think the main difficulty comes from the lack of a "hq connection = state" concept and how changes to that state can be managed. Evidence: - The 0-RTT mentions certain SETTINGS that need to be remembered by a = client. How would an extension add to this? Will every extension have to = come up with its own solution? - The HEADERs sequence number is a highly specific fix for the missing = state change - The SETTINGS-ONCE restriction simply avoids the problem by killing a = h2 mechanism If hq defines stream 3 as the place where connection state changes = happen *AND* synchronizes OPEN/CLOSE/RST of other streams on it, client = and server can have shareable concept of the connection state. I am no HPACK expert. The basic problem looks like concurrent editing = against a repository.=20 Both client and server start with connection state zero (CS-0) and the = predefined HPACK dictionary (HP-0). After SETTINGS exchange, client is = in CS-1 and server is in CS-2 for its side. Let's call the CS-1 HPACK = state HP-1. Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). = The HEADERS carries the connection state number it is based on (CS-1). = Client sends new HEADERS on stream 9, also based on CS-1. Client keeps = that delta around (HP-1.9).=20 Client then decides to announce a new connection state (CS-3) by sending = how it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The = description allows the server to update its HP-1 to HP-3 as well. Response HEADERS are also based on a server connection state, = explicitly, so the client knows which HP-X to use when decoding them. At = some time, the server sends an announcment of CS-4 with HPACK data on = stream 3 back to the client. For a 0-RTT, client and server could exchange the connection state id in = the initial SETTINGS, to make sure they have at least the same name = remembered as the other side. Client: "I was in CS-19 and you were in = CS-8." Server: "Yep." By implicitly adding all SETTINGS changes to connection states, the = problem is also solved for extensions. If one side receives HEADERS with an unknown connection state: - if the state id is greater than any known one: set a stream timeout = and wait for changes on stream 3 to arrive - state id less than max(known conn state): = STREAM_RST_UNKNOWN_CONN_STATE New SETTINGS value: MAX_CONN_STATE number of maximum connection state = the client/server is willing to keep, exchanged initially. Announcing a = new connection state allows the other side to drop the lowest one, if = MAX_CONN_STATE are used. To get optimal HPACK size compression, every HEADERs would also announce = a new connections state. To have less potential HOLB, connection states = do not change during request bursts. Something like that. -Stefan From nobody Wed Mar 15 10:37:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AA3131758 for ; Wed, 15 Mar 2017 10:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3dGv6Q-5iN0 for ; Wed, 15 Mar 2017 10:37:23 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB657131733 for ; Wed, 15 Mar 2017 10:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CLhKhBWIRkTJBpBFUtGu192M6w1fqyncXSNy0NO7zAI=; b=k1O1/gCFga5atBsw4jT1K/41+NCrMI9VauyXHriz64c7F2odfyakC+eT58DikE/IsQPtIGQ7S4zvJFH6NRb1FPO9YB5uX3684vRe/tAzByfNqcoIMQaAcGeDjWwVLGBNDisYXWL0S3QMtc0OLp6KEgvcMZ1R0vIEFr7EjO3C/d4= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Wed, 15 Mar 2017 17:37:21 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Wed, 15 Mar 2017 17:37:21 +0000 From: Mike Bishop To: Stefan Eissing , Martin Thomson , IETF QUIC WG Subject: RE: Core drafts -02 out Thread-Topic: Core drafts -02 out Thread-Index: AQHSnFW3hRyMfx+c6Ueu2fks77hV8qGV5bGAgAA4O1A= Date: Wed, 15 Mar 2017 17:37:20 +0000 Message-ID: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> In-Reply-To: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: greenbytes.de; dkim=none (message not signed) header.d=none;greenbytes.de; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::51f] x-ms-office365-filtering-correlation-id: 13a9402d-e9c2-45c2-f176-08d46bc9ef24 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:yGaB2l9iQv4g+zhhXiymOvGwbUTqMw0gN6w3pBfN21quFezgmyb5dX4fn6lPACs3OfSZwmD16QtjI4AZ13Kg4UETRhy5fm5vhzOx96JG0B4d/kOWmClQrI8ubjF8AjQEvZtyZEzpf7dIJj4scWTJqh8cPuZZGBQ2lf/gYuu5UmiQuzDl9dz2kBz3egqeKP3GhVYhUrMmEOMbQdKk0AI8wQ1hAr12zfH6aV4GZvFmHBeZEwE+WMKu/RVj/n24Ge7FIHhWGrttaPuWKGu579GuolPiZUztT4YV+xOYIdFdfsrhrJkB5AUN/tUqIO7wNUH2f/wJ6e1Bau4MhIyyyukxtrgZhwuslPaUWkUYdoNjndU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39410400002)(39450400003)(39850400002)(377454003)(13464003)(51914003)(57704003)(9686003)(39060400002)(2906002)(122556002)(53936002)(189998001)(561944003)(6246003)(38730400002)(3280700002)(53546007)(102836003)(7736002)(74316002)(33656002)(10090500001)(6116002)(7116003)(305945005)(99286003)(8990500004)(2900100001)(5660300001)(55016002)(3660700001)(2950100002)(7696004)(5005710100001)(10290500002)(6306002)(86612001)(8676002)(54356999)(6506006)(25786008)(229853002)(77096006)(6436002)(86362001)(81166006)(8936002)(50986999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 17:37:20.9294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 17:37:26 -0000 VGhhbmtzIGZvciB0aGUgZmVlZGJhY2shDQoNClllcywgeW91J3ZlIHJ1biBzdHJhaWdodCBpbnRv IHRoZSBiaWcgcXVhbmRhcnkgd2l0aCBIUEFDSy4gIEkgZG9uJ3QgdGhpbmsgYW55b25lIGV4cGVj dHMgdGhhdCB3ZSB3aWxsIHNoaXAgdGhpcyB3YXk7IEkgaGF2ZSBhIHByb3Bvc2FsIGluIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjayBm b3IgYW4gSFBBQ0stcmVwbGFjZW1lbnQgdGhhdCB3b3VsZCBzb2x2ZSBtYW55IG9mIHRoZXNlLiAg QnVjayBLcmFzaWMgaGFzIGEgcHJvcG9zYWwgd2hpY2ggaGUgaGFzIHNrZXRjaGVkIGluIGUtbWFp bCBidXQgbm90IHN1Ym1pdHRlZCBhcyBhIGRyYWZ0LiAgVGhlIG1haW4gcG9pbnQgb2YgdGhlIHNl cXVlbmNlIG51bWJlciB3YXMgdG8gZ2V0IHVzIG9mZiB0aGUgImV2ZXJ5dGhpbmcgb24gc3RyZWFt IDMiIG1vZGVsIGFuZCBsZXQgdXMgc29ydCBvdXQgdGhlIHByb2JsZW1zIG9mIEhQQUNLIGxhdGVy LiAgIzIyOCB0cmFja3MgZml4aW5nIEhQQUNLLCBpbiB3aGF0ZXZlciBmb3JtIHRoYXQgdGFrZXMu DQoNCldlIGNvdWxkIHNvbHZlIGl0IGluIHRoZSBzYW1lIHdheSB0aGF0IHdlIGRpZCBQUklPUklU WSwgYnkgYWRkaW5nIGFuICJhZmZlY3RlZCBzdHJlYW0gbnVtYmVyIiBmaWVsZCBhbmQgbW92aW5n IHRoZSBIRUFERVJTL1BVU0hfUFJPTUlTRSBmcmFtZXMgdG8gU3RyZWFtIDMgYXMgd2VsbC4gIEhv d2V2ZXIsIHRoYXQgaXMganVzdCBhcyBibG9ja2luZyBhcyB0aGUgY3VycmVudCBhcHByb2FjaCwg c28gbm90IHJlYWxseSBhbiBpbXByb3ZlbWVudC4gIFdvcnNlLCB0aGUgcmVhc29uIHdlIGNhbiB0 b2xlcmF0ZSBsYXJnZSBoZWFkZXIgZnJhbWVzIGlzIGJlY2F1c2UgdGhleSBvY2N1ciBvbiB0aGVp ciBvd24gc3RyZWFtcyBhbmQgZG9uJ3QgYmxvY2sgYXJyaXZhbCBvZiBkYXRhIGZyb20gb3RoZXIg c3RyZWFtcy4gIElmIGFsbCBoZWFkZXJzIG9jY3VyIG9uIGEgc2luZ2xlIHN0cmVhbSwgdGhhdCdz IG5vdCB0cnVlIC0tIHlvdSAqYXJlKiBibG9ja2luZyBtdXhpbmcgb2Ygb3RoZXIgc3RyZWFtcyBh Z2Fpbi4NCg0KSSBsaWtlIHRoZSBjb21wYXJpc29uIHRvIGNvbmN1cnJlbnQgZWRpdHMuICBXZSd2 ZSBkaXNjdXNzZWQgaGF2aW5nIHJvbGxpbmcgZGVsdGFzIGluIHZhcmlvdXMgbWVjaGFuaXNtczsg dGhlIHByb2JsZW0gaXMgdGhhdCBpdCByZXF1aXJlcyByZWFjaGluZyBpbnRvIHRoZSB0cmFuc3Bv cnQgZm9yIEFDSyBzdGF0ZSB0byBmaWd1cmUgb3V0IHdoZW4geW91IGNhbiBkaXNjYXJkIG9sZCBk ZWx0YXMgZm9yIGdvb2Qgb24gdGhlIHJlY2VpdmVyIHNpZGUuICBCdWNrJ3MgcHJvcG9zYWwgaXMg c2ltaWxhciwgZXNzZW50aWFsbHkgcmVxdWlyaW5nIHRoZSByZWNlaXZlciB0byBlY2hvIGJhY2sg dGhlIHBvaW50IHVwIHRvIHdoaWNoIGl0IGhhcyByZWNlaXZlZCBhbGwgZnJhbWVzLCBhbmQgdGhl IHNlbmRlciBzaG91bGRuJ3QgcmVmZXJlbmNlIHN0YXRlIHRoYXQgdGhlIHJlY2VpdmVyIGhhc24n dCBmdWxseSBhc3NpbWlsYXRlZCB5ZXQuICBJdCBmZWVscyBsaWtlIGFkZGluZyBhcHBsaWNhdGlv bi1sZXZlbCBBQ0tzIHRvIG1lLCB3aGljaCBJJ2QgbGlrZSB0byBhdm9pZC4NCg0KSFBBQ0sgaXMg YWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoZSB0d28tc3RyZWFtLXBlci1yZXF1ZXN0IGFw cHJvYWNoLiAgVGhlcmUgYXJlIHR3byByZWFzb25zIGZvciB0aGlzIC0tIG9uZSBpcyB0aGF0IEhQ QUNLIGZyYW1lcyAoaW4gdGhlIGN1cnJlbnQgZGVzaWduKSBjYW4ndCBiZSBsb3N0IHdoZW4gYSBz dHJlYW0gaXMgUlNULCBzbyB0aGUgZHJhZnQgZm9yYmlkcyByZXNldHRpbmcgY29udHJvbCBzdHJl YW1zLiAgU2luY2Ugd2Ugc3RpbGwgbmVlZCB0byBiZSBhYmxlIHRvIFJTVCByZXF1ZXN0cywgd2Ug YWRkIHRoZSBzZW1hbnRpYyB0aGF0IGtpbGxpbmcgdGhlIGRhdGEgc3RyZWFtIGltcGxpZXMgdGhl IHNhbWUgdGhpbmcgYWJvdXQgdGhlIGNvbnRyb2wgc3RyZWFtLiAgSXQncyBtZXNzeSwgYW5kIGhv cGVmdWxseSB3ZSBjYW4gcmVtb3ZlIHRoYXQgb25jZSBIUEFDSyBpcyBmaXhlZC4gIFRoZSBzZWNv bmQsIGFzIHlvdSBndWVzc2VkLCBpcyBub3QgZGVhbGluZyB3aXRoIERBVEEgZnJhbWVzLiAgIzI0 NSBub3RlcyB0aGF0LCBpZiB3ZSBmaXggSFBBQ0ssIHdlIGNvdWxkIGdvIGJhY2sgdG8gYSBzaW5n bGUgc3RyZWFtIHBlciByZXF1ZXN0OyBwcm9wb25lbnRzIG9mIGJvdGggImtlZXAgZnJhbWluZyBv dXQgb2YgdGhlIHdheSIgYW5kICJmZXdlciBzdHJlYW1zIGlzIGVhc2llciB0byBtYW5hZ2UiIGhh dmUgd2VpZ2hlZCBpbiB0aGVyZS4gIFBsZWFzZSBhZGQgeW91ciB2b2ljZS4NCg0KQXMgdG8gYnVm ZmVyaW5nLCBpdCdzIGFjdHVhbGx5IGVhc3kgZW5vdWdoIC0tIGp1c3QgZG9uJ3QgcmVhZCBmcm9t IGRhdGEgc3RyZWFtcyB1bnRpbCB5b3UndmUgc2VlbiB0aGUgaGVhZGVycy4gIFN1cmUsIHRoZSBz ZW5kZXIgd2lsbCBmaWxsIHVwIHRoZWlyIGZsb3cgY29udHJvbCB3aW5kb3cgb24gdGhhdCBzdHJl YW0gLS0gYW5kIHRoZW4gdGhleSdsbCBzdG9wIGFuZCBzZW5kIHlvdSBRVUlDIEJMT0NLRUQgZnJh bWVzLCB1bnRpbCB5b3Ugc3RhcnQgcmVhZGluZyB0aGUgYm9keSBhbmQgZ2VuZXJhdGluZyBXSU5E T1dfVVBEQVRFIGZyYW1lcy4gIE9uZSBvZiB0aGUgYmlnZ2VzdCBhcmd1bWVudHMgZm9yIHR3byBz dHJlYW1zIGluIG15IG1pbmQgaXMgbWFraW5nIHN1cmUgdGhhdCBhIHJlcXVlc3QgYmxvY2tlZCBp biB0aGlzIHdheSBkb2Vzbid0IGltcGVkZSB0aGUgZmxvdyBvZiBjb250cm9sIGZyYW1lcyBvbiB0 aGF0IHN0cmVhbSAtLSBmb3IgZXhhbXBsZSwgc2hvdWxkIHdlIHN1Y2Nlc3NmdWxseSBnZXQgY2Vy dGlmaWNhdGUgYXV0aCBmcmFtZXMgYWRkZWQsIGEgY2VydGlmaWNhdGUgcmVxdWVzdC4gIEkndmUg aGFkIHR3byBjdXN0b21lcnMgdGhpcyB3ZWVrIHRlbGxpbmcgbWUgaXQncyBhIGJ1ZyBpbiBvdXIg c2VydmVyIGNvZGUgdGhhdCB0aGVpciBUTFMgcmVuZWcgZ2V0cyBzdHVjayBpbiBUQ1AgYnVmZmVy cyBiZWhpbmQgYSBnaWFudCByZXF1ZXN0IGJvZHksIGJlY2F1c2UgdGhlIHNlcnZlciB3b24ndCBy ZWFkIGFuIHVuYXV0aGVudGljYXRlZCBib2R5IGFuZCB0aGUgY2xpZW50IHdvbid0IGhvbGQgb2Zm IHNlbmRpbmcgdGhlIGJvZHkgdW50aWwgYXV0aGVudGljYXRpb24gc3VjY2VlZHMuICBJJ2QgbGlr ZSB0byBzZWUgYmxvY2tzIGxpa2UgdGhhdCBiZWNvbWUgbGVzcyBwb3NzaWJsZSBpbiBRVUlDLCBh dCBsZWFzdC4NCg0KWWVzLCBtYWtpbmcgU0VUVElOR1MgaW1tdXRhYmxlIHJlZHVjZXMgdGhlIGZs ZXhpYmlsaXR5LiAgVGhlIG9waW5pb24gYXQgdGhlIGludGVyaW0gd2FzIHRoYXQgd2UgY291bGQg bGl2ZSB3aXRob3V0IGl0LCBhcyB3ZSBrbm93IG9mIGV4YWN0bHkgb25lIGltcGxlbWVudGF0aW9u IG9mIG9uZSBleHRlbnNpb24gdGhhdCBkb2VzIG1pZC1zdHJlYW0gc2V0dGluZyBjaGFuZ2VzLCBh bmQgSSBvd24gaXQuICDwn5iKICBJZiB0aGVyZSdzIGEgY29tcGVsbGluZyB1c2UgY2FzZSBmb3Ig Y2hhbmdpbmcgc2V0dGluZ3MgbWlkLXN0cmVhbSB3ZSB3ZXJlbid0IGF3YXJlIG9mLCB0aGF0J3Mg bmV3IGluZm9ybWF0aW9uIHRoYXQgY291bGQganVzdGlmeSB0aGUgY29tcGxleGl0eS4gIChCdXQg bm90ZSB0aGF0IHdpdGggMC1SVFQgY29ubmVjdGlvbiBzZXR1cCwgaXQgd291bGQgYmUgbmVhcmx5 IGFzIGNoZWFwIHRvIG9wZW4gYSBuZXcgY29ubmVjdGlvbiB3aXRoIHRoZSBuZXcgc2V0dGluZyBh bmQgdHJhbnNpdGlvbiB5b3VyIHRyYWZmaWMgdG8gaXQuKQ0KDQpOZWdvdGlhdGlvbiBzdGlsbCB3 b3Jrcywgc2luY2UgZWFjaCBzaWRlIHdvdWxkIHNpbXBseSBhZHZlcnRpc2UgdGhhdCB0aGV5IHN1 cHBvcnQgYW4gZXh0ZW5zaW9uIG9yIG5vdCwgYW5kIGNvbnNpZGVyIHRoZSBleHRlbnNpb24gdG8g YmUgYWN0aXZlIG9uY2UgeW91J3ZlIHNlZW4gdGhlIG90aGVyIHNpZGUncyBTRVRUSU5HUyBmcmFt ZS4gIFNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAt MDEjc2VjdGlvbi01LjIuNS4zIGZvciB0aGUgY29tcGxleGl0eSB0aGlzIGFsbG93ZWQgdXMgdG8g cmVtb3ZlLiAgQW4gZXh0ZW5zaW9uIGNvdWxkIGFkZCB0byB0aGUgbGlzdCBlYXNpbHkgLS0gaWYg eW91IHN1cHBvcnQgZXh0ZW5zaW9uIFgsIHlvdSBzaG91bGQgYWxzbyByZW1lbWJlciB0aGUgdmFs dWUgZm9yIHNldHRpbmcgWF9WQUwuICBDbGllbnRzIHRoYXQgZG9uJ3QgdXNlIHRoZSBleHRlbnNp b24gZG9uJ3QgY2FyZS4gIEFuIGV4dGVuc2lvbiB0aGF0IG5lZWRlZCBzb21lIG1vcmUgY29tcGxl eCBuZWdvdGlhdGlvbiB3b3VsZCBoYXZlIHRvIHVzZSBhbiBleHRlbnNpb24tc3BlY2lmaWMgZnJh bWUsIGl0J3MgdHJ1ZSwgYnV0IHdlIGhhdmVuJ3Qgc28gZmFyIHNlZW4gYW4gZXh0ZW5zaW9uIGRv IHRoYXQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RlZmFuIEVpc3NpbmcNClNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMTUsIDIwMTcgNjoyMiBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogQ29yZSBkcmFmdHMgLTAyIG91dA0KDQoNCj4gQW0gMTQuMDMuMjAxNyB1bSAw MDo1NyBzY2hyaWViIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Og0K PiANCj4gVGhlIGVkaXRvcnMgaGF2ZSBzdWJtaXR0ZWQgLTAyIHZlcnNpb25zIG9mIHRoZSBiYXNl IHNldCBvZiBRVUlDIGRyYWZ0cy4NClsuLi5dDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0wMg0KDQpUaGFua3MsIE1hcnRpbiEgSSBhc3N1bWUgdGhh dCB3YXMgYW5ub3VuY2VkIHRvIGdldCBmZWVkYmFjayBmcm9tIHRoZSBsdXJrZXJzIGhlcmUuIDst KQ0KDQpJJ2xsIGdpdmUgdGhpcyBhIHRyeS4gQWxsIG1pc3Rha2VzIGFuZCBtaXN1bmRlcnN0YW5k aW5ncyBhcmUgbWluZSBhbG9uZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KVmVyeSB3ZWxsIHdyaXR0ZW4gc3BlYy4gRWFzeSB0byB1bmRlcnN0YW5kIGZvciBzb21lb25l IGhhdmluZyByZWFkIHJmYyA3NTQwIGEgYml0LiANCg0KSSBoYXZlIHNvbWUgY29tbWVudHMgdG8g dGhlIHByb3Bvc2VkIEhUVFAgbWFwcGluZyBhcHByb2FjaC4gV2hlcmUgdGhlIHdnIGhhcyBhbHJl YWR5IGRpc2N1c3NlZCBhbmQgZXhoYXVzdGVkIGFsdGVybmF0aXZlcywgcGxlYXNlIGV4Y3VzZSBt eSBpZ25vcmFuY2UgYW5kIGlnbm9yZSBteSBjb21tZW50cy4gSSBoYWQgbm90IHRoZSB0aW1lIHRv IGZvbGxvdyBhbGwgZGlzY3Vzc2lvbnMgb25nb2luZyBvbiB0aGlzIHRvcGljLiBGZWVsIGZyZWUg dG8gY2hlcnJ5LXBpY2sgd2hhdCBzZWVtcyBoZWxwZnVsLg0KDQoNCj4gNC4gIFN0cmVhbSBNYXBw aW5nIGFuZCBVc2FnZQ0KDQorMSB0byBkaXJlY3RseSB1c2luZyBxdWljIHN0cmVhbSBpZHMgaW5z dGVhZCBvZiB2aXJ0dWFsIGgyIHN0cmVhbSANCitpZGVudGlmaWVyDQoNCkhvd2V2ZXIsIHVzaW5n IDIgcXVpYyBzdHJlYW1zIGZvciBhIHNpbmdsZSByZXF1ZXN0L3Jlc3BvbnNlIGRvZXMgbm90IHNp dCB3ZWxsIHdpdGggbWUuIEkgYXNzdW1lIHRoYXQgc3RlbXMgZnJvbSB0aGUgd2lzaCB0byBnZXQg cmlkIG9mIERBVEEgZnJhbWVzLiBXaGljaCBzb3VuZHMgbmljZSwgYnV0IGlzIGl0IHdvcnRoIGl0 PyBCeSBkb3VibGluZyB0aGUgIyBvZiBzdHJlYW1zIGZvciBhIGNsaWVudCwgaG93IG11Y2ggb3Zl cmhlYWQgZG9lcyB0aGF0IGludHJvZHVjZSAoSSBzcGVhayBvZiBhIHNlcnZlciBob2xkaW5nID4x MGsgcXVpYyAiY29ubmVjdGlvbnMiKT8NCg0KQWxzbywgdGhlIHNlcnZlciBuZWVkcyB0byBidWZm ZXIgZGF0YSBvbiBxdWljIHN0cmVhbXMgNywgMTEsIDE1LCBldGMuIGJlY2F1c2UgSEVBREVScyBt aWdodCBhcnJpdmUgc29tZSB0aW1lIGluIHRoZSBmdXR1cmUgb24gc3RyZWFtcyA1LCA5LCAxMywg ZXRjLiBvciBub3QuIFRoZXJlIGlzIG5vIHdheSB0byByb3V0ZSB0aGlzIGRhdGEgc29tZXdoZXJl LCBiZWNhdXNlIHRoZSBtZXRhIGluZm9ybWF0aW9uIGlzIHN0aWxsIG1pc3NpbmcuDQoNCkFuZCB0 aGVyZSBpcyBzdGlsbCBIb2xiIG9uOg0KDQo+IDQuMi4xLiAgSGVhZGVyIENvbXByZXNzaW9uDQo+ IC4uLg0KPiBESVNDVVNTOiAgS2VlcCBIUEFDSyB3aXRoIEhPTEI/ICBSZWRlc2lnbiBIUEFDSyB0 byBiZSBvcmRlci0NCj4gICAgICAgaW52YXJpYW50PyAgSG93IG11Y2ggZG8gd2UgbmVlZCB0byBy ZXRhaW4gY29tcGF0aWJpbGl0eSB3aXRoDQo+ICAgICAgIEhUVFAvMidzIEhQQUNLPw0KDQpVc2lu ZyBhIGNvdW50ZXIgaW4gSEVBREVSUyBpcyBhIGNydXRjaDoNCi0gaXQgaXMgYSBoaWdobHkgc3Bl Y2lmaWMgc29sdXRpb24gdG8gYSBjb21tb24gcHJvYmxlbSBpbiBodHRwL3F1aWM6IHN5bmNocm9u aWNpdHkgaW4gY29ubmVjdGlvbiBsZXZlbCBzdGF0ZSBjaGFuZ2VzLiBTRVRUSU5HUyAoc2VlIGJl bG93KSBoYXMgdGhlIHNhbWUgcHJvYmxlbSwgYXMgZG9lcyBoYXZlIFBSSU9SSVRZIGluIEhFQURF UlMuIEl0IHNlZW1zIHRoYXQgcGVyZm9ybWFuY2Ugd2lzZSwgYWxsIEhFQURFUlMgY291bGQgYXMg d2VsbCBiZSBzZW50IG9uIHN0cmVhbSAzLiANCg0KTm93LCBzb2x2aW5nIEhvbCBibG9ja2luZyBm b3IgSEVBREVSUyB3b3VsZCBiZSBhIGZpbmUgYWNoaWV2ZW1lbnQuIA0KDQo+IDUuICBIVFRQIEZy YW1pbmcgTGF5ZXINCj4gRnJhbWVzIGFyZSB1c2VkIG9ubHkgb24gdGhlIGNvbm5lY3Rpb24gKHN0 cmVhbSAzKSBhbmQgbWVzc2FnZQ0KPiAgICAoc3RyZWFtcyA1LCA5LCBldGMuKSBjb250cm9sIHN0 cmVhbXMuIA0KDQpBbmQgc3RyZWFtcyA0LCA4LCAxMiwgZXRjLiBJIGFzc3VtZS4NCg0KPiA1LjIu My4gIFNFVFRJTkdTDQo+IC4uLg0KPiBTRVRUSU5HUyBmcmFtZXMgYWx3YXlzIGFwcGx5IHRvIGEg Y29ubmVjdGlvbiwgbmV2ZXIgYSBzaW5nbGUgc3RyZWFtLg0KPiAgQSBTRVRUSU5HUyBmcmFtZSBN VVNUIGJlIHNlbnQgYXMgdGhlIGZpcnN0IGZyYW1lIG9mIHRoZSBjb25uZWN0aW9uICANCj4gY29u dHJvbCBzdHJlYW0gKHNlZSBTZWN0aW9uIDQpIGJ5IGVhY2ggcGVlciwgYW5kIE1VU1QgTk9UIGJl IHNlbnQgIA0KPiBzdWJzZXF1ZW50bHkgb3Igb24gYW55IG90aGVyIHN0cmVhbS4gIElmIGFuIGVu ZHBvaW50IHJlY2VpdmVzIGFuICANCj4gU0VUVElOR1MgZnJhbWUgb24gYSBkaWZmZXJlbnQgc3Ry ZWFtLCB0aGUgZW5kcG9pbnQgTVVTVCByZXNwb25kIHdpdGggIA0KPiBhIGNvbm5lY3Rpb24gZXJy b3Igb2YgdHlwZSBIVFRQX1NFVFRJTkdTX09OX1dST05HX1NUUkVBTS4gIElmIGFuICANCj4gZW5k cG9pbnQgcmVjZWl2ZXMgYSBzZWNvbmQgU0VUVElOR1MgZnJhbWUsIHRoZSBlbmRwb2ludCBNVVNU IHJlc3BvbmQgIA0KPiB3aXRoIGEgY29ubmVjdGlvbiBlcnJvciBvZiB0eXBlIEhUVFBfTVVMVElQ TEVfU0VUVElOR1MuDQoNCldoYXQgYWJvdXQgSFBBQ0sgc3RhdGU/IFRoZSBjb25uZWN0aW9uIHN0 YXRlIGNoYW5nZSBwcm9ibGVtIGFnYWluIHZpc2libGUuDQoNClRoaXMgaXMgYSBzZXZlcmUgcmVz dHJpY3Rpb24gb24gZXh0ZW5zaW9ucyBtZWNoYW5pc21zIHRoYXQgd2FudCB0byBhZmZlY3QgYSBj b25uZWN0aW9uLiBCZWNhdXNlIGlmIHRoZSBodHRwL3F1aWMgZG9lcyBub3Qgc29sdmUgdGhpcyBw cm9ibGVtLCBob3cgYXJlIHRoZXkgZXhwZWN0ZWQgdG8gZG8gaXQ/IFRoZXkgZWl0aGVyIGFubm91 bmNlIHRoZW1zZWx2ZXMgb24gdGhlIGZpcnN0IFNFVFRJTkdTIG9yIHJlbWFpbiBzaWxlbnQgZm9y ZXZlciwgaXQgc2VlbXMuIEhvdyB3b3VsZCBhbiBleHRlbnNpb24gaGFuZHNoYWtlIHdvcmsgdGhl bj8gT3duIHN0cmVhbSAzIGhhbmRzaGFrZSBmcmFtZXM/DQoNCj4gNS4yLjMuMy4gIFVzYWdlIGlu IDAtUlRUDQoNCldoYXQgYWJvdXQgSFBBQ0sgc3RhdGU/IERvZXMgaXQgbmVlZCB0byBiZSBrZXB0 IG9yIGlzIGl0IHJlc2V0Pw0KDQo+IEhUVFBfUFVTSF9BTFJFQURZX0lOX0NBQ0hFICgweDAzKTog IFRoZSBzZXJ2ZXIgaGFzIGF0dGVtcHRlZCB0byBwdXNoDQo+ICAgICAgY29udGVudCB3aGljaCB0 aGUgY2xpZW50IGhhcyBjYWNoZWQuDQo+IC4uLg0KPiBIVFRQX1JFUVVFU1RfQ0FOQ0VMTEVEICgw eDA0KTogIFRoZSBjbGllbnQgbm8gbG9uZ2VyIG5lZWRzIHRoZQ0KPiAgICAgcmVxdWVzdGVkIGRh dGEuDQoNCk5pdHBpY2s6IHNlZW1zIHJlZHVuZGFudC4gVGhlIGZpcnN0IGNvdWxkIGJlIHJlcGxh Y2VkIGJ5IHRoZSBzZWNvbmQuIFN0cmVhbSBudW1iZXIgd2lsbCBzdWZmaWNlLg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRh a2luZyB0d28gc3RlcHMgYmFjazoNCg0KSSB0aGluayB0aGUgbWFpbiBkaWZmaWN1bHR5IGNvbWVz IGZyb20gdGhlIGxhY2sgb2YgYSAiaHEgY29ubmVjdGlvbiBzdGF0ZSIgY29uY2VwdCBhbmQgaG93 IGNoYW5nZXMgdG8gdGhhdCBzdGF0ZSBjYW4gYmUgbWFuYWdlZC4gRXZpZGVuY2U6DQotIFRoZSAw LVJUVCBtZW50aW9ucyBjZXJ0YWluIFNFVFRJTkdTIHRoYXQgbmVlZCB0byBiZSByZW1lbWJlcmVk IGJ5IGEgY2xpZW50LiBIb3cgd291bGQgYW4gZXh0ZW5zaW9uIGFkZCB0byB0aGlzPyBXaWxsIGV2 ZXJ5IGV4dGVuc2lvbiBoYXZlIHRvIGNvbWUgdXAgd2l0aCBpdHMgb3duIHNvbHV0aW9uPw0KLSBU aGUgSEVBREVScyBzZXF1ZW5jZSBudW1iZXIgaXMgYSBoaWdobHkgc3BlY2lmaWMgZml4IGZvciB0 aGUgbWlzc2luZyBzdGF0ZSBjaGFuZ2UNCi0gVGhlIFNFVFRJTkdTLU9OQ0UgcmVzdHJpY3Rpb24g c2ltcGx5IGF2b2lkcyB0aGUgcHJvYmxlbSBieSBraWxsaW5nIGEgaDIgbWVjaGFuaXNtDQoNCklm IGhxIGRlZmluZXMgc3RyZWFtIDMgYXMgdGhlIHBsYWNlIHdoZXJlIGNvbm5lY3Rpb24gc3RhdGUg Y2hhbmdlcyBoYXBwZW4gKkFORCogc3luY2hyb25pemVzIE9QRU4vQ0xPU0UvUlNUIG9mIG90aGVy IHN0cmVhbXMgb24gaXQsIGNsaWVudCBhbmQgc2VydmVyIGNhbiBoYXZlIHNoYXJlYWJsZSBjb25j ZXB0IG9mIHRoZSBjb25uZWN0aW9uIHN0YXRlLg0KDQoNCkkgYW0gbm8gSFBBQ0sgZXhwZXJ0LiBU aGUgYmFzaWMgcHJvYmxlbSBsb29rcyBsaWtlIGNvbmN1cnJlbnQgZWRpdGluZyBhZ2FpbnN0IGEg cmVwb3NpdG9yeS4gDQpCb3RoIGNsaWVudCBhbmQgc2VydmVyIHN0YXJ0IHdpdGggY29ubmVjdGlv biBzdGF0ZSB6ZXJvIChDUy0wKSBhbmQgdGhlIHByZWRlZmluZWQgSFBBQ0sgZGljdGlvbmFyeSAo SFAtMCkuIEFmdGVyIFNFVFRJTkdTIGV4Y2hhbmdlLCBjbGllbnQgaXMgaW4gQ1MtMSBhbmQgc2Vy dmVyIGlzIGluIENTLTIgZm9yIGl0cyBzaWRlLiBMZXQncyBjYWxsIHRoZSAgQ1MtMSBIUEFDSyBz dGF0ZSBIUC0xLg0KDQpDbGllbnQgc2VuZHMgbmV3IEhFQURFUlMgb24gNSBhbmQga2VlcHMgdGhl IEhQQUNLIGRlbHRhIGFyb3VuZCAoSFAtMS41KS4gVGhlIEhFQURFUlMgY2FycmllcyB0aGUgY29u bmVjdGlvbiBzdGF0ZSBudW1iZXIgaXQgaXMgYmFzZWQgb24gKENTLTEpLiBDbGllbnQgc2VuZHMg bmV3IEhFQURFUlMgb24gc3RyZWFtIDksIGFsc28gYmFzZWQgb24gQ1MtMS4gQ2xpZW50IGtlZXBz IHRoYXQgZGVsdGEgYXJvdW5kIChIUC0xLjkpLiANCg0KQ2xpZW50IHRoZW4gZGVjaWRlcyB0byBh bm5vdW5jZSBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIChDUy0zKSBieSBzZW5kaW5nIGhvdyBpdCBh cHBsaWVkIHRoZSBkZWx0YXMgSFAtMS41IGFuZCBIUC0xLjkgdG8gY29tZSB1cCB3aXRoIEhQLTMu IFRoZSBkZXNjcmlwdGlvbiBhbGxvd3MgdGhlIHNlcnZlciB0byB1cGRhdGUgaXRzIEhQLTEgdG8g SFAtMyBhcyB3ZWxsLg0KDQpSZXNwb25zZSBIRUFERVJTIGFyZSBhbHNvIGJhc2VkIG9uIGEgc2Vy dmVyIGNvbm5lY3Rpb24gc3RhdGUsIGV4cGxpY2l0bHksIHNvIHRoZSBjbGllbnQga25vd3Mgd2hp Y2ggSFAtWCB0byB1c2Ugd2hlbiBkZWNvZGluZyB0aGVtLiBBdCBzb21lIHRpbWUsIHRoZSBzZXJ2 ZXIgc2VuZHMgYW4gYW5ub3VuY21lbnQgb2YgQ1MtNCB3aXRoIEhQQUNLIGRhdGEgb24gc3RyZWFt IDMgYmFjayB0byB0aGUgY2xpZW50Lg0KDQpGb3IgYSAwLVJUVCwgY2xpZW50IGFuZCBzZXJ2ZXIg Y291bGQgZXhjaGFuZ2UgdGhlIGNvbm5lY3Rpb24gc3RhdGUgaWQgaW4gdGhlIGluaXRpYWwgU0VU VElOR1MsIHRvIG1ha2Ugc3VyZSB0aGV5IGhhdmUgYXQgbGVhc3QgdGhlIHNhbWUgbmFtZSByZW1l bWJlcmVkIGFzIHRoZSBvdGhlciBzaWRlLiBDbGllbnQ6ICJJIHdhcyBpbiBDUy0xOSBhbmQgeW91 IHdlcmUgaW4gQ1MtOC4iIFNlcnZlcjogIlllcC4iDQoNCkJ5IGltcGxpY2l0bHkgYWRkaW5nIGFs bCBTRVRUSU5HUyBjaGFuZ2VzIHRvIGNvbm5lY3Rpb24gc3RhdGVzLCB0aGUgcHJvYmxlbSBpcyBh bHNvIHNvbHZlZCBmb3IgZXh0ZW5zaW9ucy4NCg0KSWYgb25lIHNpZGUgcmVjZWl2ZXMgSEVBREVS UyB3aXRoIGFuIHVua25vd24gY29ubmVjdGlvbiBzdGF0ZToNCi0gaWYgdGhlIHN0YXRlIGlkIGlz IGdyZWF0ZXIgdGhhbiBhbnkga25vd24gb25lOiBzZXQgYSBzdHJlYW0gdGltZW91dCBhbmQgd2Fp dCBmb3IgY2hhbmdlcyBvbiBzdHJlYW0gMyB0byBhcnJpdmUNCi0gc3RhdGUgaWQgbGVzcyB0aGFu IG1heChrbm93biBjb25uIHN0YXRlKTogU1RSRUFNX1JTVF9VTktOT1dOX0NPTk5fU1RBVEUNCg0K TmV3IFNFVFRJTkdTIHZhbHVlOiBNQVhfQ09OTl9TVEFURSBudW1iZXIgb2YgbWF4aW11bSBjb25u ZWN0aW9uIHN0YXRlIHRoZSBjbGllbnQvc2VydmVyIGlzIHdpbGxpbmcgdG8ga2VlcCwgZXhjaGFu Z2VkIGluaXRpYWxseS4gQW5ub3VuY2luZyBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIGFsbG93cyB0 aGUgb3RoZXIgc2lkZSB0byBkcm9wIHRoZSBsb3dlc3Qgb25lLCBpZiBNQVhfQ09OTl9TVEFURSBh cmUgdXNlZC4NCg0KVG8gZ2V0IG9wdGltYWwgSFBBQ0sgc2l6ZSBjb21wcmVzc2lvbiwgZXZlcnkg SEVBREVScyB3b3VsZCBhbHNvIGFubm91bmNlIGEgbmV3IGNvbm5lY3Rpb25zIHN0YXRlLiBUbyBo YXZlIGxlc3MgcG90ZW50aWFsIEhPTEIsIGNvbm5lY3Rpb24gc3RhdGVzIGRvIG5vdCBjaGFuZ2Ug ZHVyaW5nIHJlcXVlc3QgYnVyc3RzLg0KDQpTb21ldGhpbmcgbGlrZSB0aGF0Lg0KDQotU3RlZmFu DQoNCg0K From nobody Wed Mar 15 15:06:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD45129C0E for ; Wed, 15 Mar 2017 15:06:29 -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 Rtf-_ckl5PBO for ; Wed, 15 Mar 2017 15:06:28 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBFC129C1C for ; Wed, 15 Mar 2017 15:06:27 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id 19so35501930oti.0 for ; Wed, 15 Mar 2017 15:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yuyanQEHf61RHlAA7l0O3o3apXYlZLkMNXQtCMoWvpM=; b=LzYQhthwuI2HqrERAS9/gpetIZmqnrm6CSaOuZckW5eAzyvqZO1tM2zmWPtmSZz5jI pPjbGe6xdm6rK5y+gcdBNx505VTiFBL9xUZRoW8AHGrLNgeUD3v5hSxmpRYA7UeleRAM 7L8oC60TcIY4yhyfaC3ErjrHj/lD0mln5MI6sNPbfTySxHiY3WXpRoHi1BBBjek3EkAH GIcLbiuTvN4+YoirBPS3IhH5MI4++LDNh7tYFKsG4tgrZzNCs1WQsp5sgQpTwosliosS /067LL7kwLcRf2+LVsXJPRLR5S4gL8aoe8L632jE/A19ktOq102jj7bBK/3/QNfhUgb9 7baA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yuyanQEHf61RHlAA7l0O3o3apXYlZLkMNXQtCMoWvpM=; b=IyMePyIwRPIYPJCzV00OGonbiFjVjVnoCz/KTRKKMnp6GibhuzB7Ug6oRlm5K2+zxj /T74nsaqux3lxJix/ADNgh9yx6wUCLlI7yD/NDqhjZvGDihIczbH8Cv5ygXHaPuCeEbx +XE2GrMB8xi+DwKHVXgCxT92o17SaqW9nMoBtso1lXjXQv9zZMm9yg060ncNMlUvwdK2 nmJuDOGh+d6vaifT17w6zhMPT+JcAabhlw1/j2V5KmZXoihmISWgPpE3S6jdatx1xHQ8 CrN7V0fY7R8tGq1jzACD2tpIKJ1KIuFuinbOzKv8bSDoRtehmWAiH2BGheTvh0YtsEm8 ykRg== X-Gm-Message-State: AFeK/H0p1ruYK2999hh8fwnXt8toPmeLru0ft3PDpPH820qEYoyRys11Xp4AXDjeSte3maMW26SMaOYB1e4X4w== X-Received: by 10.157.13.230 with SMTP id 93mr3143250ots.13.1489615587233; Wed, 15 Mar 2017 15:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Wed, 15 Mar 2017 15:06:26 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Wed, 15 Mar 2017 15:06:26 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Jana Iyengar Cc: Ian Swett , Martin Thomson , Ted Hardie , IETF QUIC WG , Lucas Clemente Content-Type: multipart/alternative; boundary=94eb2c116b8aedd662054acc27c2 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 22:06:30 -0000 --94eb2c116b8aedd662054acc27c2 Content-Type: text/plain; charset=UTF-8 This doesn't match my perception of the contract between a TCP-like transport layer and applications that use it in a "clean close", but then neither does the existing bidirectional GOAWAY. A clean close should indicate to the app that all written data has been received, and the peer has successfully delivered all its intended data. What QUIC needs is a signal that says "I am done creating new streams but am still willing to receive new ones". Although there ought to be stream-level shutdown() calls in a future socket API, but a connection-level shutdown() would send this signal and also FIN all remaining streams. After both QUIC endpoints clean all this up at the transport layer, there is no need for a further signal from the app. Forcing every app to create its own GOAWAY (or, in my vision, send-only GOAWAY) mechanism seems rather heavyweight if it is a common feature of a clean close. On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar wrote: > After chatting with Martin offline, it's growing on me as well. The key > insights in my mind are: > > 1. It's preferable for each endpoint to indicate the streams it is > closing, to avoid requiring upper-layer retries of new streams in flight. > > 2. The semantics of stream creation are different for different apps. HTTP > generally has the client creating a stream and the server responds on the > same stream. A different application can have very different client-server > interactions. For instance, a client creates a stream which requires a a > server to create multiple streams in response, which in turn require > further client stream creations. In this case, QUIC has no idea what the > "last" stream ought to be, and this needs to be indicated by the > application. > > 3. Since in the general case the app protocol is expected to be involved > in figuring out what graceful close looks like, it makes sense to define it > per app. In other words, make it part of the app mapping to QUIC. For HTTP, > this would be a GOAWAY frame on Stream 3. Once all streams are closed, HTTP > closes Stream 3. > > 4. Graceful close by the app means that the QUIC connection can > immediately go into TIME_WAIT on a connection close from the app. > > It is a clean separation of concerns for sure. I'd like to ruminate on > this a bit, since sometimes that helps. > > This seems like good fodder for Chicago. > > On Tue, Mar 7, 2017 at 6:52 PM, Ian Swett wrote: > >> After thinking about it more, if no one else has objections to "Make >> every application implement their own graceful close if they need it and >> only provide a way to kill the connection immediately.", I'm fine with it >> as well. >> >> On Tue, Mar 7, 2017 at 6:20 PM, Martin Thomson >> wrote: >> >>> On 8 March 2017 at 03:58, Ted Hardie wrote: >>> > >>> > On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson < >>> martin.thomson@gmail.com> >>> > wrote: >>> >> >>> >> I think that both are likely to run afoul of a simple problem in HTTP: >>> >> the control stream (stream 3) can't be closed. >>> >> >>> > I don't think that's actually a problem with what I suggested. It >>> simply >>> > means that for the HTTP mapping, the defined behavior is to send >>> > FIN_COMPLETE after all open requests and pushes complete. If it >>> arrives >>> > before then, you'd have to treat it as a protocol error for the >>> mapping. >>> > What I'm trying to avoid is baking in the requirement that >>> FIN_COMPLETE (or >>> > its moral equivalent) always occur then, since it will make using other >>> > types >>> >>> Sure. I had inferred that you were doing this entirely at the >>> transport layer, which doesn't really allow you to do that. >>> >> >> > --94eb2c116b8aedd662054acc27c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This doesn't match my perception of the contract betwe= en a TCP-like transport layer and applications that use it in a "clean= close", but then neither does the existing bidirectional GOAWAY. A cl= ean close should indicate to the app that all written data has been receive= d, and the peer has successfully delivered all its intended data.

<= /div>
What QUIC needs is a signal that says "I am done creating ne= w streams but am still willing to receive new ones". Although there ou= ght to be stream-level shutdown() calls in a future socket API, but a conne= ction-level shutdown() would send this signal and also FIN all remaining st= reams. After both QUIC endpoints clean all this up at the transport layer, = there is no need for a further signal from the app.

Forcing every app to create its own GOAWAY (or, in my vision, send-only G= OAWAY) mechanism seems rather heavyweight if it is a common feature of a cl= ean close.

On Tue, Mar 7, 2017 at 7:16 PM, Jana Iyengar <jri@google.com> wrote:
After chattin= g with Martin offline, it's growing on me as well. The key insights in = my mind are:

1. It's preferable for each endpoint to= indicate the streams it is closing, to avoid requiring upper-layer retries= of new streams in flight.

2. The semantics of str= eam creation are different for different apps. HTTP generally has the clien= t creating a stream and the server responds on the same stream. A different= application can have very different client-server interactions. For instan= ce, a client creates a stream which requires a a server to create multiple = streams in response, which in turn require further client stream creations.= In this case, QUIC has no idea what the "last" stream ought to b= e, and this needs to be indicated by the application.

<= div>3. Since in the general case the app protocol is expected to be involve= d in figuring out what graceful close looks like, it makes sense to define = it per app. In other words, make it part of the app mapping to QUIC. For HT= TP, this would be a GOAWAY frame on Stream 3. Once all streams are closed, = HTTP closes Stream 3.

4. Graceful close by the app= means that the QUIC connection can immediately go into TIME_WAIT on a conn= ection close from the app.

It is a clean separatio= n of concerns for sure. I'd like to ruminate on this a bit, since somet= imes that helps.=C2=A0

This seems like good fodder= for Chicago.

On Tue, Mar 7, 2017 at = 6:52 PM, Ian Swett <ianswett@google.com> wrote:
After thinking about it more, if n= o one else has objections to "Make every application implement their o= wn graceful close if they need it and only provide a way to kill the connec= tion immediately.", I'm fine with it as well.

On Tue, Mar 7, 2017 at 6:= 20 PM, Martin Thomson <martin.thomson@gmail.com> wrot= e:
On 8 March 2017 at 03:58, Ted Ha= rdie <ted.ietf@g= mail.com> wrote:
>
> On Mon, Mar 6, 2017 at 3:40 PM, Martin Thomson <martin.thomson@gmail.com>=
> wrote:
>>
>> I think that both are likely to run afoul of a simple problem in H= TTP:
>> the control stream (stream 3) can't be closed.
>>
> I don't think that's actually a problem with what I suggested.= =C2=A0 It simply
> means that for the HTTP mapping, the defined behavior is to send
> FIN_COMPLETE after all open requests and pushes complete.=C2=A0 If it = arrives
> before then, you'd have to treat it as a protocol error for the ma= pping.
> What I'm trying to avoid is baking in the requirement that FIN_COM= PLETE (or
> its moral equivalent) always occur then, since it will make using othe= r
> types

Sure.=C2=A0 I had inferred that you were doing this entirely at the<= br> transport layer, which doesn't really allow you to do that.




On Ma= r 16, 2017 4:27 PM, "Ryan Hamilton" <rch@google.com> wrote:
=E2=80=8B= =E2=80=8BOn Thu, Mar 16, 2017 = at 4:04 PM, Mike Bishop <Michael.Bishop@microsoft.com= > wrote:<= /div>
But isn=E2=80=99t removal of STOP_WAITING predicated on gett= ing ACKs of the ACK frames eventually?=C2=A0

=E2=80=8BEventually yes. Immediately, no.=E2=80=8B
=C2=A0
But I guess that presumes= there will be other traffic triggering ACK generation eventually, which wi= ll then mention the ACK-only packet.

=E2=80=8BExactly! An ACK will eventually be acknowledged. But i= t won't be the result of an ACK-only packet being received by the peer = (since those never solicit an ACK in response).
--001a114da5c4291ed8054ae3a7c7-- From nobody Thu Mar 16 22:18:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35C6127010 for ; Thu, 16 Mar 2017 22:18:26 -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 jztAKwYaIeuV for ; Thu, 16 Mar 2017 22:18:25 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 24427126E01 for ; Thu, 16 Mar 2017 22:18:25 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id x37so79974671ota.2 for ; Thu, 16 Mar 2017 22:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KjeSMKZ/V9R1BOsapCVDDd0T+Ad5zouhWzBx6Hke84w=; b=ERJvQc/NEzIWlvZhw3LtOUUEy6dSxmREWA+dVVQ8Nx44KR021ASp6VdDli/OSR5jT7 lGmVNtR/ExK9mrcDwQL2mE9/+VyOzVkTzN4UyCVo3xR3kXCKfLlZ1XZlJrKS3bp/R7SF tUCeskT4tMf7+Xzl+/h7mrwYhszjrcsn/QOwvDN8p4nq1tdugUB3S9bcZK9bYBDDe4dO sP/gamRBaq1VylpdjGt6JSM7ga+dwoAswrz9IoCi4KQeEXnWdPKsOlch3havv1DwpBHK M3BvspjPECrfdpfnmBhaeJk2d8xmipo3Ms0YPfL1Y4fACeRtFVsojNLhtOtzHXxlmsgL rn0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KjeSMKZ/V9R1BOsapCVDDd0T+Ad5zouhWzBx6Hke84w=; b=DGSj/rt720/FEcTS0d+24z8hAIT+UcHRNYOtuttElAfcSACKQp+TvPwqCU5r4ujwhR nAAy2QfFcHGjaiJt8kf7RsnWk83aod1fTfrwFQqmOY20r5iIO7Q3I30up1Pc5uCkwFa7 M1v+joejWRT5WwozFiATO4ZT84PmG3TmB2GFF30DPOFct4jyD6I20khX7yiyUzRo56uo 1j6ilCsGctDYoIGPnB9f/zDmOT9pqqcz0h4+TxciMXRbID3y4a1ZrdM7LBIE0Ngw3eEA e1p9ZyzKcOixYnuqsc7PrLuIdwwK2DN4IC7rVBGZXmuKVa1MamrlnsUa+bYn5g9FhSd+ UOdQ== X-Gm-Message-State: AFeK/H37kpf698x+v4j0zOfc6rzjICFfK6hsjOWbiVxOKTnj+IXSNj/930O9D+5xxvzVvQy2AZ672II6lHehBQ== X-Received: by 10.202.182.11 with SMTP id g11mr7197835oif.110.1489727904516; Thu, 16 Mar 2017 22:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.11.180 with HTTP; Thu, 16 Mar 2017 22:18:23 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Thu, 16 Mar 2017 22:18:23 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Jana Iyengar Cc: Ryan Hamilton , Ted Hardie , Ian Swett , Mike Bishop , Martin Thomson , Lucas Clemente , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113caa448f9125054ae64e62 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 05:18:27 -0000 --001a113caa448f9125054ae64e62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The DRAIN timer in your concept is common to most/all apps and should therefore be in QUIC. To force every application developer to implement a timer to perform a clean close seems pointlessly duplicative. Moreover, in any case I think a packet needs to go over the wire at the QUIC layer. On Thu, Mar 16, 2017 at 7:08 PM, Jana Iyengar wrote: > I was trying to come up with a coherent way to capture these cases (thank= s > Ryan, Ian and Martin for offline discussions). A few iterations later, I > have a simplified proposal. > > When an app calls close() on a QUIC connection, the transport immediately > tears down all state. > > We have to account for closing after idle and for the equivalent of a > FIN_WAIT to retransmit or ack retransmissions. Before describing that, I'= ll > define two time periods. IDLE is the amount of time that an endpoint clos= es > the connection after, and DRAIN is the amount of time that an endpoint > retransmits or sends acks of retransmissions at the tail of the connectio= n. > > After all streams are closed (via FIN or RST_STREAM), the app is > responsible for idle close. Assuming that the app negotiates this IDLE > timeout value (or we could negotiate this in QUIC and expose it to the ap= p, > but that seems unnecessary), it waits for IDLE time, and then closed the > connection. Importantly, neither endpoint initiates new streams after IDL= E > - DRAIN time has passed. Of course, if a new stream is created during thi= s > period, the app is out of idle. > > When the app wants to gracefully close the connection, the app peers can > agree in some manner to close the connection, by closing Stream 3 in HTTP > for example. The app waits for DRAIN time after all streams are closed > and then closes the connection. > > Finally, we have the QUIC connection close, which I'll call error close > here, since that's what it really is. On error close, we could do one of > two things. QUIC could call back into the app, the app waits DRAIN period= , > and the app then closes the connection. Alternatively, QUIC could have a > timer here that waits for DRAIN amount of time and then kills itself. I > much prefer the first idea since it keeps the waiting logic entirely insi= de > the app for all cases. > > This proposal would basically remove any waiting inside QUIC and moves > that entire logic to the application. > > I could be missing something here, so I'd like to think about this some > more. But y'all could poke holes in this sooner, so I'm sharing. I'm happ= y > to write this in a separate email thread and/or a PR and/or issue, but > airing this here for now. > > What do you think? Plausible? > > - jana > > On Mar 16, 2017 4:27 PM, "Ryan Hamilton" wrote: > >> =E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop < >> Michael.Bishop@microsoft.com> wrote: >> >>> But isn=E2=80=99t removal of STOP_WAITING predicated on getting ACKs of= the ACK >>> frames eventually? >> >> >> =E2=80=8BEventually yes. Immediately, no.=E2=80=8B >> >> >>> But I guess that presumes there will be other traffic triggering ACK >>> generation eventually, which will then mention the ACK-only packet. >>> >> >> =E2=80=8BExactly! An ACK *will* eventually be acknowledged. But it won't= be the >> result of an ACK-only packet being received by the peer (since those nev= er >> solicit an ACK in response). >> > --001a113caa448f9125054ae64e62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The DRAIN timer in your concept is common to most/all= apps and should therefore be in QUIC. To force every application developer= to implement a timer to perform a clean close seems pointlessly duplicativ= e.

Moreover, in any case I think a packet needs to= go over the wire at the QUIC layer.
=
On Thu, Mar 16, 2017 at 7:08 PM, Jana Iyenga= r <jri@google.com> wrote:
I was trying to come up with a coherent way to capture these= cases (thanks Ryan, Ian and Martin for offline discussions). A few iterati= ons later, I have a simplified proposal.

When an app calls close() on a QUIC connection, the transport im= mediately tears down all state.

We have to account for closing after idle and for the equivalent = of a FIN_WAIT to retransmit or ack retransmissions. Before describing that,= I'll define two time periods. IDLE is the amount of time that an endpo= int closes the connection after, and DRAIN is the amount of time that an en= dpoint retransmits or sends acks of retransmissions at the tail of the conn= ection.

After all stream= s are closed (via FIN or RST_STREAM), the app is responsible for idle close= . Assuming that the app negotiates this IDLE timeout value (or we could neg= otiate this in QUIC and expose it to the app, but that seems unnecessary), = it waits for IDLE time, and then closed the connection. Importantly, neithe= r endpoint initiates new streams after IDLE - DRAIN time has passed. Of cou= rse, if a new stream is created during this period, the app is out of idle.=

When the app wants to g= racefully close the connection,=C2= =A0the app peers can agree in some manner to close the connection, by closi= ng Stream 3 in HTTP for example. The app waits=C2=A0for DRAIN time a= fter all streams are closed and then closes the connection.

Finally, we have the QUIC connection = close, which I'll call error close here, since that's what it reall= y is. On error close, we could do one of two things. QUIC could call back i= nto the app, the app waits DRAIN period, and the app then closes the connec= tion. Alternatively, QUIC could have a timer here that waits for DRAIN amou= nt of time and then kills itself. I much prefer the first idea since it kee= ps the waiting logic entirely inside the app for all cases.=C2=A0

This proposal would basically rem= ove any waiting inside QUIC and moves that entire logic to the application.=

I could be missing some= thing here, so I'd like to think about this some more. But y'all co= uld poke holes in this sooner, so I'm sharing. I'm happy to write t= his in a separate email thread and/or a PR and/or issue, but airing this he= re for now.

What do you = think? Plausible?

- jana

On Mar 16, 2017 4:27 PM, "Ryan Hamilton" <= ;rch@google.com>= wrote:
=E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
But isn=E2= =80=99t removal of STOP_WAITING predicated on getting ACKs of the ACK frame= s eventually?=C2=A0

=E2=80=8BE= ventually yes. Immediately, no.=E2=80=8B
=C2=A0
But I guess that presumes there will be other traf= fic triggering ACK generation eventually, which will then mention the ACK-o= nly packet.

=E2=80=8BExactly! An= ACK will eventually be acknowledged. But it won't be the result= of an ACK-only packet being received by the peer (since those never solici= t an ACK in response).

--001a113caa448f9125054ae64e62-- From nobody Fri Mar 17 00:00:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664411243F6 for ; Fri, 17 Mar 2017 00:00:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8qhir3a0uVCn for ; Fri, 17 Mar 2017 00:00:50 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3DF1243FE for ; Fri, 17 Mar 2017 00:00:49 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id x75so36273859vke.2 for ; Fri, 17 Mar 2017 00:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9XK+Mf1qZM6LAUAZnIGc1YFSTFm9lpIFnHbibbHLu7Q=; b=SFr8ZRGcG53h6kmVCX3N9R1EtIBXTHJTOY36f3MShpOrw3NepBdOQdvSXusdELvq2D m3jyZyeUI0YDTGVJ6NAWp32jDzpn0jpF4gjv3D18CQYWzVwic55I2dmPKoe8c4BFdcqD KXCvF3U6ZPZJ5rjKXANJOOt1fWZq25ZGR/a4KG68zDeWwgess19wstnEV+Ti3gXrtxC0 Bao0sqxaFjm8OF4/kgzR6x3fdVIFrHf54DJZFEQQhffPbhBIml2/w8xrDmbkPhV53Mpt pXpCeRJppsrCNZQKFZaUlbqdtoVSiyrlYNrF0Ma6yGqtpd5MJQbuOKSFyGFQmZtqPLCs e6XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9XK+Mf1qZM6LAUAZnIGc1YFSTFm9lpIFnHbibbHLu7Q=; b=OjG2Ljmcl70vNRqo4edXf3EIHSwJ60ea4Lj53CTR3ln8x1adDNGl13mNz2oLeqKEVs 0MGM9pY6+J8MNcU3X4ZbsXhI2jCrwXvjD1hJpRKvnxOnF8MoRc76K6yu78+blt2nXZyv whdyNxKdStQWBlveZYWRjqjEHegNl8vigdLTJ3UQVdFHHC6s24IHfjqruGUL2E5qRddZ ehMZEUgVvNaVwUQUSVkecVl9Wnco9HWwui1rWhQurR5YhotOEKa82WMWn3ejuEO3nz5a /VvxEhddiCxqabAFiBcgfzJUX/KjWETFGIR3HpPAUw3a+8DtIqELHYytOWCmvB8CLalb vpoQ== X-Gm-Message-State: AFeK/H3E7+Xu19CIYmxw4nZIiF1EvJ4ZPk0J1d3t+NR0iwQAEjiOIBKh+tbwgtLNggu/tQyAjGOLMebLUNk7Gclr X-Received: by 10.31.59.197 with SMTP id i188mr739337vka.40.1489734048428; Fri, 17 Mar 2017 00:00:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Fri, 17 Mar 2017 00:00:47 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 17 Mar 2017 00:00:47 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Duke Cc: Ryan Hamilton , Ted Hardie , Ian Swett , Mike Bishop , Martin Thomson , Lucas Clemente , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1142f178c48966054ae7bc25 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 07:00:53 -0000 --001a1142f178c48966054ae7bc25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 16, 2017 at 10:18 PM, Martin Duke wrote: > The DRAIN timer in your concept is common to most/all apps and should > therefore be in QUIC. To force every application developer to implement a > timer to perform a clean close seems pointlessly duplicative. > Yeah, I was in two minds about this. This is a reasonable expectation to have from the transport (though not all apps need this), so we could move the DRAIN time (after close() and error close) to inside QUIC. This would make the error close logic more contained inside QUIC. The application could still do the logic required for an idle close. Moreover, in any case I think a packet needs to go over the wire at the > QUIC layer. > I don't think this is required. What packet are you thinking about? - jana > On Thu, Mar 16, 2017 at 7:08 PM, Jana Iyengar wrote: > >> I was trying to come up with a coherent way to capture these cases >> (thanks Ryan, Ian and Martin for offline discussions). A few iterations >> later, I have a simplified proposal. >> >> When an app calls close() on a QUIC connection, the transport immediatel= y >> tears down all state. >> >> We have to account for closing after idle and for the equivalent of a >> FIN_WAIT to retransmit or ack retransmissions. Before describing that, I= 'll >> define two time periods. IDLE is the amount of time that an endpoint clo= ses >> the connection after, and DRAIN is the amount of time that an endpoint >> retransmits or sends acks of retransmissions at the tail of the connecti= on. >> >> After all streams are closed (via FIN or RST_STREAM), the app is >> responsible for idle close. Assuming that the app negotiates this IDLE >> timeout value (or we could negotiate this in QUIC and expose it to the a= pp, >> but that seems unnecessary), it waits for IDLE time, and then closed the >> connection. Importantly, neither endpoint initiates new streams after ID= LE >> - DRAIN time has passed. Of course, if a new stream is created during th= is >> period, the app is out of idle. >> >> When the app wants to gracefully close the connection, the app peers can >> agree in some manner to close the connection, by closing Stream 3 in HTT= P >> for example. The app waits for DRAIN time after all streams are closed >> and then closes the connection. >> >> Finally, we have the QUIC connection close, which I'll call error close >> here, since that's what it really is. On error close, we could do one of >> two things. QUIC could call back into the app, the app waits DRAIN perio= d, >> and the app then closes the connection. Alternatively, QUIC could have a >> timer here that waits for DRAIN amount of time and then kills itself. I >> much prefer the first idea since it keeps the waiting logic entirely ins= ide >> the app for all cases. >> >> This proposal would basically remove any waiting inside QUIC and moves >> that entire logic to the application. >> >> I could be missing something here, so I'd like to think about this some >> more. But y'all could poke holes in this sooner, so I'm sharing. I'm hap= py >> to write this in a separate email thread and/or a PR and/or issue, but >> airing this here for now. >> >> What do you think? Plausible? >> >> - jana >> >> On Mar 16, 2017 4:27 PM, "Ryan Hamilton" wrote: >> >>> =E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop < >>> Michael.Bishop@microsoft.com> wrote: >>> >>>> But isn=E2=80=99t removal of STOP_WAITING predicated on getting ACKs o= f the ACK >>>> frames eventually? >>> >>> >>> =E2=80=8BEventually yes. Immediately, no.=E2=80=8B >>> >>> >>>> But I guess that presumes there will be other traffic triggering ACK >>>> generation eventually, which will then mention the ACK-only packet. >>>> >>> >>> =E2=80=8BExactly! An ACK *will* eventually be acknowledged. But it won'= t be the >>> result of an ACK-only packet being received by the peer (since those ne= ver >>> solicit an ACK in response). >>> >> > --001a1142f178c48966054ae7bc25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 16, 2017 at 10:18 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
The DRAIN timer in your concept is common to most/all apps and should the= refore be in QUIC. To force every application developer to implement a time= r to perform a clean close seems pointlessly duplicative.

Yeah, I was in two minds about this. This is a r= easonable expectation to have from the transport (though not all apps need = this), so we could move the DRAIN time (after close() and error close) to i= nside QUIC. This would make the error close logic more contained inside QUI= C. The application could still do the logic required for an idle close.

Moreo= ver, in any case I think a packet needs to go over the wire at the QUIC lay= er.

I don't think this is r= equired. What packet are you thinking about?

- jan= a
=C2=A0
O= n Thu, Mar 16, 2017 at 7:08 PM, Jana Iyengar <jri@google.com> = wrote:
I was trying to = come up with a coherent way to capture these cases (thanks Ryan, Ian and Ma= rtin for offline discussions). A few iterations later, I have a simplified = proposal.

When an app calls cl= ose() on a QUIC connection, the transport immediately tears down all state.=

We have to account for = closing after idle and for the equivalent of a FIN_WAIT to retransmit or ac= k retransmissions. Before describing that, I'll define two time periods= . IDLE is the amount of time that an endpoint closes the connection after, = and DRAIN is the amount of time that an endpoint retransmits or sends acks = of retransmissions at the tail of the connection.
After all streams are closed (via FIN or RST_STRE= AM), the app is responsible for idle close. Assuming that the app negotiate= s this IDLE timeout value (or we could negotiate this in QUIC and expose it= to the app, but that seems unnecessary), it waits for IDLE time, and then = closed the connection. Importantly, neither endpoint initiates new streams = after IDLE - DRAIN time has passed. Of course, if a new stream is created d= uring this period, the app is out of idle.

When the app wants to gracefully close the connection,=C2=A0the app peers can agree in some = manner to close the connection, by closing Stream 3 in HTTP for example. Th= e app waits=C2=A0for DRAIN time after all streams are closed and the= n closes the connection.

Finally, we have the QUIC connection close, which I'll call error clos= e here, since that's what it really is. On error close, we could do one= of two things. QUIC could call back into the app, the app waits DRAIN peri= od, and the app then closes the connection. Alternatively, QUIC could have = a timer here that waits for DRAIN amount of time and then kills itself. I m= uch prefer the first idea since it keeps the waiting logic entirely inside = the app for all cases.=C2=A0

This proposal would basically remove any waiting inside QUIC and moves= that entire logic to the application.

I could be missing something here, so I'd like to think = about this some more. But y'all could poke holes in this sooner, so I&#= 39;m sharing. I'm happy to write this in a separate email thread and/or= a PR and/or issue, but airing this here for now.
What do you think? Plausible?
- jana

On Mar 16, 2017 4:27 PM, = "Ryan Hamilton" <rch@google.com> wrote:
=E2=80=8B=E2=80=8BOn Thu, Mar 16, 2017 at 4:04 PM, Mike Bishop <Michael.Bishop@microsoft.co= m> wrote:=
But isn=E2=80=99t removal of STOP_WAITING predicated on get= ting ACKs of the ACK frames eventually?=C2=A0

<= div>
=E2=80= =8BEventually yes. Immediately, no.=E2=80=8B
=C2=A0
But I guess that presumes there will be other = traffic triggering ACK generation eventually, which will then mention the A= CK-only packet.

=E2=80=8BExactly! An ACK will eve= ntually be acknowledged. But it won't be the result of an ACK-only pack= et being received by the peer (since those never solicit an ACK in response= ).


--001a1142f178c48966054ae7bc25-- From nobody Fri Mar 17 02:22:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F3126DC2 for ; Fri, 17 Mar 2017 02:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 xW4XXk2oqwjj for ; Fri, 17 Mar 2017 02:22:39 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 DC686126D73 for ; Fri, 17 Mar 2017 02:22:38 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5A38222E1FA; Fri, 17 Mar 2017 05:22:32 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Consensus Call on issues closed by the -02 drafts Message-Id: <71B75EF9-8745-4057-8354-EC09BB518C27@mnot.net> Date: Fri, 17 Mar 2017 20:22:29 +1100 Cc: Lars Eggert To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 09:22:42 -0000 Everyone, The -02 drafts incorporate the proposed resolutions to a number of = issues that have been discussed.=20 Those issues are listed below. Please have a look through them, and if = there are any resolutions that you feel need more discussion, please = bring it up, either here on the mailing list or in the issue itself. Issues that we need to discuss more will be reopened. The remaining ones = will be flagged as `has-consensus`. There are a lot of them, so we're not going to do this until after the = Chicago meeting (at the earliest) to give people a chance to discuss on = the list as well as in the meeting. See = for a reminder about the process we're using here. Even when = we have consensus, we can reopen an issue if new information emerges = (and that can take a variety of forms). This list is also available at = . Cheers, ## Transport #35 - Starting packet number #40 - Variable-length fields #49 - Transport parameter advertisements #50 - Updating Transport parameters #51 - QUIC version number scheme #52 - Source address validation #55 - What can change in a different version #56 - Extending flags #57 - Advice on STOP_WAITING #59 - Define ICSL parameter #62 - Finding frame lengths #63 - ACK retransmission #64 - Path MTU Discovery #66 - Remove STOP_WAITING #67 - Picking packet number length #69 - Minimum packet size #70 - Move ACK/STOP_WAITING into the packet header #74 - Application-defined error codes #104 - Priority in QUIC Transport #108 - Maximum stream number #112 - Greasing version negotiation #114 - STREAM retransmission priority #116 - COPTs as empty transport parameters #117 - SCUP #118 - Source Address Token encoding #119 - Server-proposed connection ID #124 - Alt-Svc quic version hint #126 - Separate transport parameters for 0-RTT #133 - Connection ID in version negotiation #135 - DoS using Version Negotiation Packets #136 - First client packet size #139 - Minimum MTU #147 - Reflection Attack Resistance #148 - QUIC packet header complexity #157 - Updated information in retransmitted frames #158 - Padding between frames #159 - Time format #162 - RST_STREAM and flow control #163 - RST_STREAM and connection-level flow control #164 - Padding handshake packets #168 - Ordering of ACK Frame fields #174 - Stream Reservation #181 - Remove SETTINGS[_ACK] #185 - Reliable identification of the initial packet for a connection #201 - Do streams 0 and 1 count towards MSPC? #204 - Streams not contributing to connection-level flow control #243 - AEAD Associated Data #244 - Need a NONCE in version negotiation packets #262 - Don't encrypt client handshake with 1-RTT keys #285 - Policing packet number size #286 - Outstanding packets and packet number size #289 - Avoid using Public Reset where possible #291 - ACKing ACK #292 - Does any portion of the QUIC framing require 4 byte alignment? #293 - Does the connection id need to be in a consistent location? #295 - Connection ID on a version negotiation packet #308 - "retransmitting" old timestamps in ACK frames #323 - Smaller packet number representations #340 - Scale flow control offsets #341 - What does it mean to acknowledge something? #347 - Clarify meaning/definition of GOAWAY #349 - When should server-chosen connection IDs be sent and how are they = indicated? #352 - Does GOAWAY need an error code ## Recovery #63 - ACK retransmission #169 - Response to lost handshake packets ## TLS #12 - Decouple QUIC version and ALPN=20 #25 - Key update forward secrecy #26 - Which bit can KEY_PHASE use? #27 - Fix KEY_PHASE for early data #34 - ACK rules and packet protection #87 - QUIC advertisement description #97 - Version Negotiation + TLS #226 - Authenticating public parts of the packet header #243 - AEAD Associated Data #262 - Don't encrypt client handshake with 1-RTT keys #272 - Signaling TLS handshake failure ## HTTP 75 - SETTING syncronization 87 - QUIC advertisement description 95 - CONNECT 104 - Priority in QUIC Transport 124 - Alt-Svc quic version hint 127 - Frame header reserved bits 154 - HTTP Stream ID Size 173 - Size of HTTP Header Sequence Numbers 176 - RST_STREAM breaks HPACK 181 - Remove SETTINGS[_ACK] 202 - HTTP: Why are we defining CONNECT? 204 - Streams not contributing to connection-level flow control 229 - Use a quic=3D parameter for Alt-Svc rather than collide with = existing use of v=3D 242 - HTTP extension mechanisms 297 - Remove the quic parameter from Alt-Svc 364 - Mid-frame close -- Mark Nottingham https://www.mnot.net/ From nobody Fri Mar 17 02:51:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6A1270AC for ; Fri, 17 Mar 2017 02:51:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UCKmfuxzQtp for ; Fri, 17 Mar 2017 02:51:03 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A73D127071 for ; Fri, 17 Mar 2017 02:51:03 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p64so60042346qke.1 for ; Fri, 17 Mar 2017 02:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oNHoqw3458cgGxM7+RStn5k0ORya6obixgmcR/t6zWs=; b=tz7qv4NRiCx8MiDbeW6x93zj6LC8opztaEw2rVBlGEUpI2QeX5EqPbywOkamxzglwy Mg7pfNRDlYHDGxtbf74vnF3Nj6pNfrjX4Eq1EMwD6oYq1ZMlkptTn83ntyLWnD8RZxAU Ss2Sny8FTjtucIKz35Za37n60RQ7KCqgOqRvWVvlyRqNjB8AG1bspWJB5PardpKZbgsQ 5X1S/bI+xAcOWjNaNLXYuueSfJrcocA3HtqH0hKNd+hhUx3Dpa9JIi4k8Q1WYOpuYTQr zco9bJfnF6bVJ1xFFIRlGmf/QNaOgMHayrh93btSCCVTsaaT69msPgsQjkfYtEir2mvL JJXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oNHoqw3458cgGxM7+RStn5k0ORya6obixgmcR/t6zWs=; b=tC2v+CevX1n+oz9w6EH7cwLgueldL7AU3Y6n2X8rfdNRmYdY78M9ge40YuNTSccnyd uPGXGCW7u4WSPrPPdlJG8KvTYJg0iOsPD/t+r8XGQ/78jMb+UfQmd1nBvqAiiPssJU8A SKsQdgINqsoN2p+mkMwUgAUZH5xz/WL9dLIJjUjbbDwyt3oz7wtMhgeI7s0FRs1DKXvW QVHKK8aMhZ3bOI8z7BcyFrH8dzRqKIQjOj+7UZhXjfAcq84ToFr38LCSbtKpNpRi1VW2 mAj3G3JpuptHUlfTLS2tseyy6IESN6JBLfK0bwBTyAxPcYJHNxFK9UPP7rPS5JY5uglP 7yIw== X-Gm-Message-State: AFeK/H1aUYqIfMGFod+3KAUfXuZMKPguFYSnkZJSgv2YaYl6ODUIr63lDCjpQpnAY4Cg6iIHDjTzYhInVPxkoQ== X-Received: by 10.55.93.68 with SMTP id r65mr11122714qkb.68.1489744262250; Fri, 17 Mar 2017 02:51:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Fri, 17 Mar 2017 02:51:01 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 17 Mar 2017 20:51:01 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Jana Iyengar Cc: Martin Duke , Ryan Hamilton , Ted Hardie , Ian Swett , Mike Bishop , Lucas Clemente , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 09:51:04 -0000 On 17 March 2017 at 18:00, Jana Iyengar wrote: > On Thu, Mar 16, 2017 at 10:18 PM, Martin Duke > wrote: >> >> The DRAIN timer in your concept is common to most/all apps and should >> therefore be in QUIC. To force every application developer to implement a >> timer to perform a clean close seems pointlessly duplicative. > > > Yeah, I was in two minds about this. This is a reasonable expectation to > have from the transport (though not all apps need this), so we could move > the DRAIN time (after close() and error close) to inside QUIC. This would > make the error close logic more contained inside QUIC. The application could > still do the logic required for an idle close. I had the same sense as Martin here, and this would be easier in some ways. Note that one consequence of your model is that the idle timer moves under encryption because it would be an HTTP setting, not a transport parameter. I can see pros and cons to that. >> Moreover, in any case I think a packet needs to go over the wire at the >> QUIC layer. > > I don't think this is required. What packet are you thinking about? I can't think of a reason either. Any packet that QUIC sends is going to cost radio/battery/bandwidth where it would otherwise be silent and I would prefer silent unless there is a good reason. From nobody Fri Mar 17 03:07:07 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B51299FA for ; Fri, 17 Mar 2017 03:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6ecxdcU39orH for ; Fri, 17 Mar 2017 03:07:04 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A26C127071 for ; Fri, 17 Mar 2017 03:07:04 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id n21so58491530qta.1 for ; Fri, 17 Mar 2017 03:07:03 -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=xBqMhm/Bj52sDKEXWMfOGmS9P3DucUih1rrKDd+IoeA=; b=ZJaYsqVCY96e1d22KZrENbEgi/SW331Qixn1b8ck11AAH8ZHuhYtqdNI1/s237VkQw HhgngS/istDZ+GZgPx8iJy8j57YsAgZqu3y3BoACIuPq4v2CogM0Ovupc3hcFYM6OcFZ 9H8wL4NlmItkt0Oo/b1IGFbEWQ9IVgmK7pLfGKmC8Ek114X6/7VtaarZ1PPcm0bkXY64 PHLyLYWKl574IQVIW5duJWhK63BgcClSZjKi5w1HJF23vqB/usm3h/BHJWddltmLElq5 C5PLX2Roc7lFGzXzG8tkFlI8VEka4PLj0KbCNZaWylt2wmA0EBipEmN/irZ4Vyjo5fac x4dA== 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=xBqMhm/Bj52sDKEXWMfOGmS9P3DucUih1rrKDd+IoeA=; b=m0ZDTYw/1ESRY1qojkySTGGw2/i0MjWPWxzbEFx3QlrffXw1GSCWa+5zEF8eDl0kvg POlAHwSvV57dxgnvaCjemMwm1BbLcQYIAi3TZGxx05cVLzg7Y7QHq2MZ/NFI9cFjZNGi SKBFfp3gXxkLieHCoVH8rgvscQJ5CMoD25fHzH/SFGkkUoHlIfd84QDpiINA98zDkXzu vtLhcr9k255DhgMNUXVzHMXiFnOTLoymYGINuR0XykJlGc9Uz3ZEt2Y4G7xVFrxxa89U g4hrcTp4htIly5iRKTN2e/W+J02mfREbPLe2M5MSU/7jls1w0E5KGBqXcWuCEAk5ZmQi G7FA== X-Gm-Message-State: AFeK/H1ITTWTqaoUepwbvVh4l1m7yeMARA4GmlQ7oLCXRGaCga4+bceBJPTH8N0p6uWC48wTlgBdTcS0BdGbGg== X-Received: by 10.200.3.214 with SMTP id z22mr13737706qtg.3.1489745222857; Fri, 17 Mar 2017 03:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Fri, 17 Mar 2017 03:07:02 -0700 (PDT) From: Martin Thomson Date: Fri, 17 Mar 2017 21:07:02 +1100 Message-ID: Subject: PSA: github issues are now available offline To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 10:07:06 -0000 We have been saving issues to the `gh-issues` branch in the repository for some time now. Anyone with an up-to-date clone of the repository can checkout this branch and see two files: issues.json and pulls.json. These files contain summary information about all issues including things like title, labels, people, and the issue summary (comments are much bigger and harder to retrieve, I'm still not sure whether it is worthwhile loading all of these). I recently added issues.html to this. It's crude, but it has a view of the issues that you can access offline. There are some basic filtering options there as well. You can see the results online here: https://rawgit.com/quicwg/base-drafts/gh-issues/issues.html When I say crude, I'm not messing around. You will need Firefox to read this when you are offline. I'm not a web developer, so I used the tools I'm familiar with. The code runs in Chrome, but Chrome won't load file scheme resources (so the link above works, but you will be sad if you try to look at your local copy). And Edge doesn't like async functions (yet). Also, I didn't test Safari. Pull requests are always welcome if people find those limitations annoying and have the means and inclination to work on fixing them. See https://github.com/martinthomson/i-d-template/blob/master/template/issues.html From nobody Fri Mar 17 04:25:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796E7128CFF for ; Fri, 17 Mar 2017 04:25:56 -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, RP_MATCHES_RCVD=-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 ktjQkIzDQ8Da for ; Fri, 17 Mar 2017 04:25:52 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972B8128CDB for ; Fri, 17 Mar 2017 04:25:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vl31V1krfzMrBX; Fri, 17 Mar 2017 12:25:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gWnuPtGkOaL; Fri, 17 Mar 2017 12:25:48 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 17 Mar 2017 12:25:48 +0100 (CET) Subject: Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 To: Martin Thomson , IETF QUIC WG References: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <58b235ad-a9bb-d453-0157-f874687ae241@tik.ee.ethz.ch> Date: Fri, 17 Mar 2017 12:25:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 11:25:56 -0000 Hi Martin, thanks a lot for your feedback! As you mentioned yourself there are still some speculative comments in both drafts and we will definitely remove them in future versions. In this case as we submitted those drafts, mainly to implement the split into two drafts, quite a couple of days before the -02 versions of the other draft, we tried to already capture some aspects that where still under discussion but likely to make it into the drafts. But see below for details. Mirja On 16.03.2017 05:52, Martin Thomson wrote: > Thanks for putting these together. > > # Bit ticket feedback > > I think that these drafts need to consider the protocol as a package, > not focus on individual parts. Thus, you should talk about HTTP/QUIC > and its properties, not talk about a transport protocol. That means > referencing the HTTP mapping document for introductory matters and > only referencing other documents when it is relevant to a particular > point. So I'm actually not sure here and that's something I'd like to discuss. I would guess that applicability together with H2 will anyway be discussed in the H2 mapping draft. However, no matter what, I'm sure there will be people that will try to use QUIC with other higher layer protocols and applications and I think we need to give some advise here as well, especially if there are know assumptions we made in the protocol design about the application behavior or capabilities. Also the group is supposed to potentially recharter at some point to write more mapping documents. I also saw this document also as capturing what we learned from h2 for future mapping. > > Take for example the fallback section in the applicability draft. If > you were to talk about the specifics of HTTP/QUIC, then you only need > to talk about having HTTP/2 or HTTP/1.1 as a backstop. That's what we had in the previous version but then Ted talked about what would you do if you use QUIC for DNS in some issue thread and we tried to generalize this a bit. Again I think the h2 mapping doc also needs to talk about the h2 case specifically. > > There is probably some advice that could be given that would be > generic, but I suspect that without actually having more usage > examples to drive this from, we would just get those laughably wrong > (not all, but some). I disagree, writing down the assumption we make about application behavior when we made certain design decisions for the transport is a good thing. > > > # Applicability > > The fact that this is encrypted is very prominent in the introduction. > I expect that this is more of interest to the other document. That's a little bit an artifact from the previous version where manageability was included. But why do you think this is not interesting for this document? I think the two most important points in this document (fallback and 0-RTT) are directly connected to the fact that quic is encrypted by default. > > ## Section 2 (Fallback) > > The point on fallback is that you will lose something, but you should > not allow fallback to another protocol to degrade security guarantees. > That is, you might lose performance (holb, multiplexing, etc...), but > you shouldn't lose any expectation of confidentiality or integrity, if > requirements for those things have been established. Good point. We were more focusing on the problem that you might even lose connectivity if you don't have an adequate way to fall-back. This is not the case for H2, but might be fore other applications. The point on performance is a separate point on should be spelled out as well. I'll add this. > > TCP by default does not support 0-RTT session resumption. > > Not sure what "defaults" for TCP might even be. The point that this > paragraph seems to be trying to make is that falling back might result > in some degradation of performance. This was only meant to say that you have to negotiate it and the chances are high that this is simply not supported by the other end. We can spell it out to make it more meaningful. > > The same paragraph is also saying that if you can't guarantee some > level of security, then you SHOULD fail: > > Moreover, while encryption (in this case TLS) is > inseparable integrated with QUIC, TLS negotiation over TCP can be > blocked. In case it is RECOMMENDED to abort the connection > > I'm not sure why it's only a SHOULD though. I'm fairly sure that most > clients will treat this as fatal already. I don't really see how to make this a MUST. If you have a service where you cannot risk to lose connectivity to your costumers, is it better to not even try to use QUIC directly but only try TLS over TCP and then fallback to unencrypted TCP if TLS is blocked? I don't think this is a protocol level decision that e.g. influences interoperability; it's rather an economic decision. > > This section doesn't need to be hopeful, or lobby for particular > changes. We can use the mailing list for that. Yes, the word 'hope' is misplaced here. Do you proposed to remove this paragraph completely, or do you think it's useful to have a reference to manageability draft there? > > ## Section 3 (0-RTT) > > 0-RTT is more than one packet, contrary to what this text implies by > talking about the "first packet" (note that the first packet is the > ClientHello, which can be replayed ad nauseum to no ill effect). Yes, that's a mistake (was probably thinking to much about tcp syn data stll). Will fix that. > > The discussion of loss here suggests a misunderstanding of the > problem. The risk here is that the 0-RTT data can be replayed to a > server on **a different connection** and - absent any > application-layer means of detecting this - could be processed twice. > Loss and retransmission of these packets is benign. So we meant retransmission to include replay; I agree that's the wrong word and causes confusion. Will fix that. > > Mark Nottingham talks about the relevance of idempotency at the HTTP > layer and its relevance to this subject. I suggest that you read > draft-nottingham-httpbis-retry-01. I don't think that you need to > change the view here, though you might like to change to using some > other terminology (replay protection, for instance). Thanks! Probably good to give a reference to this draft anyway! I wasn't aware of this yet. > > ## Section 4 (Multiplexing) > > We should probably spend a lot more time discussing the virtues of > having multiple connections and whether it is possible to obtain > different treatment for packets on the same flow. > > The editor's note is speculative and can be removed. We added this based on the mailing list discussions on draft-abilash-quic-network-00. Your are absolutely right that these speculations should be removed from the draft and discussed as issues on the protocols. However, I didn't really know so far how to phrase an issue on that because we didn't really discuss this at all so far and I didn't want to lose it. > > ## Section 5 (Prioritization) > > The second paragraph here is speculative and can be removed. Here the point was to give application some guidance how to implement prioritization on the application level (and when it might be useful). Again this was not meant to be specific advise for h2 but other applications. However, while some prioritization can be implemented in the higher layer, prioritization of retransmission can only be done by quic. The point regarding the interface is actually another question I have. Should this document talk about the quic transport interface. How much advise to we want to give? Do we maybe even want to talk about an abstract api? > > ## Section 8 (Versioning) > > I think that the key point to make here is that unlike other transport > protocols, QUIC includes version negotiation. I like that you point > out that very little is guaranteed to be stable between versions. > Making a special point about TLS isn't that interesting and I would > remove that. This was especially meant to be advise to people who already have in mind that they want to implement quic with a different crypto. Again, I've been seeing this as general guidance for quic transport (and not for quic+tls+h2). As such I've been trying to capture guidance for future mappings and future versions of quic. > > > # Manageability > > This draft is obviously a lot further behind. It's also obviously > scrambling to keep up, since it's much more exposed to some of the > recent changes in the transport doc. Yes! I think that it is generally the > right level of information to have. There are a few errors and > omissions, but frankly - given where we are at - I'm surprised that > this has tracked the drafts so well. Thanks! > > > ## what can network management learn from looking at QUIC > > I think that this needs to be clearer about the distinction between > *this* version of QUIC and the version-agnostic parts of QUIC. The > increment between the two is small, but relevant. Yes, but that's also very much under discussion... > > The description of key phase is incorrect. It has nothing to do with > 0-RTT (though 0-RTT once affected it, it doesn't now). It is for > working out which key to use for the packet. Yes that's an artifact from an older version. > > The fact that a connection ID might change is a little > under-emphasized. Admitted, the -transport draft doesn't actually > define how this works, so maybe that can be added when we build that > function. Yes! > > In Section 3.1: > 0-RTT connection establishment, however, provides no particular > heuristic for differentiation from random background traffic at this > time. > > This is incorrect. The client still sends a ClientHello, which is in > the clear. The fact that other packets might be sent and that there > might be loss and reordering is relevant here though and probably > needs to be called out. Those packets will look like random noise, > and the temptation will be to just drop them, after all, I suspect > that many servers will do the same. But there's a risk there. The difference is that you do see data before you've got an confirmation from the other end. But yes, you are right, the sentence above is not correct neither. Will fix. > > Similarly, this is incorrect: > RTT can > only be measured at connection establishment time, and only when > 1-RTT establishment is used. Yes. > > > We closed #185. (Section 3.3) after the draft was submitted. > > In Section 3.3, this is incorrect, except under certain conditions: > If the QUIC handshake was not observed by the defense system, the > connection ID can be used as a confirmation signal as per > [I-D.trammell-plus-statefulness]. > > This is (currently) only true in the following cases: > 1. the server uses version negotiation > 2. the server uses HelloRetryRequest (a stateless reject) > 3. the server uses the client-selected connection ID (though I > wouldn't want to rely on that) > 4. the connection ID is sent in both directions (Google servers > routinely avoid sending a connection ID) This was meant to address the case where a middlebox doesn't see any of the handshake but see the middle of the connection. In this case, if presented, seeing the same connection id on the reverse path, gives you a good hit that both ends actually want to talk to each other. > > Section 3.3 also eventually needs a discussion of the impact of > connection migration when it is combined with a change in connection > ID. (Again, we don't have that feature now, so the omission is > clearly not a problem now.) The stateful nature of the connection is > not visible to the path in that case. In particular, this seems to be > highly speculative: > However, it is > questionable if connection migrations needs to be supported in a DDOS > attack or if a defense system might simply rely on the fast > resumption mechanism provided by QUIC This was more a comment for DDOS system. Today we don't have this kind of connection migration. There is a 'fear' that if quic's connection migration is not visible to the DDOS system it cannot handle quic traffic sufficiently. However, what happens if the middlebox doesn't know about the migration? The connection will break in a DDOS scenario, and quic has to reconnect... i don't think that actually a problem. However, I didn't want to give a recommendation that those system should not track migration yet, because we are still discussing how migration will work. > > > ## what can network management do to affect QUIC > > I think that the effect of dropping packets needs to be explored more. > This is probably the only tool a network has (aside from perhaps a > public reset), but it's a pretty powerful one. We'll know more when > more is said about congestion control, of course. If we find that > authenticated public resets aren't a strict requirement, that will > need to be added. Agreed. > > I don't know if you want to discuss how PMTUD might react to signals > from a network, or whether networks really care about using MTU as a > management tool. Yes, would probably be good to say something. Let me try to figure out what we could usefully say here. > > > > On 13 March 2017 at 21:58, Mirja Kühlewind > wrote: >> Hi all, >> >> as some of you have probably already noticed that we submitted two new drafts >> draft-kuehlewind-quic-manageability-00 and >> draft-kuehlewind-quic-applicability-00 >> which are replacements for draft-kuehlewind-quic-appman as discussed in Tokyo. >> >> Beside the split we also added a little more content but given that the protocol is still very much in change, there are still quite a few editor notes or incomplete sections. Still we’d be very happy about feedback and additional input from others and are also still looking for additional authors! >> >> See you in Chicago! >> Mirja and Brian >> >> >>> Anfang der weitergeleiteten Nachricht: >>> >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for draft-kuehlewind-quic-manageability-00.txt >>> Datum: 9. März 2017 um 12:12:51 MEZ >>> An: "Mirja Kuehlewind" , "Brian Trammell" , "Dan Druta" , "Mirja Kühlewind" >>> >>> >>> A new version of I-D, draft-kuehlewind-quic-manageability-00.txt >>> has been successfully submitted by Mirja Kuehlewind and posted to the >>> IETF repository. >>> >>> Name: draft-kuehlewind-quic-manageability >>> Revision: 00 >>> Title: Manageability of the QUIC Transport Protocol >>> Document date: 2017-03-09 >>> Group: Individual Submission >>> Pages: 10 >>> URL: https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-manageability-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-manageability/ >>> Htmlized: https://tools.ietf.org/html/draft-kuehlewind-quic-manageability-00 >>> >>> >>> Abstract: >>> This document discusses manageability of the QUIC transport protocol, >>> focusing on caveats impacting network operations involving QUIC >>> traffic. Its intended audience is network operators, as well as >>> content providers that rely on the use of QUIC-aware middleboxes, >>> e.g. for load balancing. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> Anfang der weitergeleiteten Nachricht: >>> >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for draft-kuehlewind-quic-applicability-00.txt >>> Datum: 8. März 2017 um 16:30:57 MEZ >>> An: "Mirja Kuehlewind" , "Brian Trammell" , "Mirja Kühlewind" >>> >>> >>> A new version of I-D, draft-kuehlewind-quic-applicability-00.txt >>> has been successfully submitted by Brian Trammell and posted to the >>> IETF repository. >>> >>> Name: draft-kuehlewind-quic-applicability >>> Revision: 00 >>> Title: Applicability of the QUIC Transport Protocol >>> Document date: 2017-03-08 >>> Group: Individual Submission >>> Pages: 7 >>> URL: https://www.ietf.org/internet-drafts/draft-kuehlewind-quic-applicability-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-kuehlewind-quic-applicability/ >>> Htmlized: https://tools.ietf.org/html/draft-kuehlewind-quic-applicability-00 >>> >>> >>> Abstract: >>> This document discusses the applicability of the QUIC transport >>> protocol, focusing on caveats impacting application protocol >>> development and deployment over QUIC. Its intended audience is >>> designers of application protocol mappings to QUIC, and implementors >>> of these application protocols. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> From nobody Fri Mar 17 07:06:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D7129446 for ; Fri, 17 Mar 2017 07:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1D3_GQ7bAV3j for ; Fri, 17 Mar 2017 07:06:35 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id DAD02129447 for ; Fri, 17 Mar 2017 07:06:34 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0BFB93A0A3 for ; Fri, 17 Mar 2017 10:06:34 -0400 (EDT) Received: by mail-qk0-f172.google.com with SMTP id 1so65077614qkl.3 for ; Fri, 17 Mar 2017 07:06:34 -0700 (PDT) X-Gm-Message-State: AFeK/H2JtckUBjqHWbSltwzdVtlBcUfgLIbMya21EIozbsGwFi/lb8Jo7HJswD7pJTwoUgY/WvOSqd6HRl0w6w== X-Received: by 10.55.6.7 with SMTP id 7mr14740455qkg.200.1489759593754; Fri, 17 Mar 2017 07:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.130 with HTTP; Fri, 17 Mar 2017 07:06:33 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Fri, 17 Mar 2017 10:06:33 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Duke Cc: Jana Iyengar , Mike Bishop , Ted Hardie , Ian Swett , Ryan Hamilton , Lucas Clemente , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary=001a114d809c630f87054aedaf1c Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 14:06:37 -0000 --001a114d809c630f87054aedaf1c Content-Type: text/plain; charset=UTF-8 On Fri, Mar 17, 2017 at 1:18 AM, Martin Duke wrote: > The DRAIN timer in your concept is common to most/all apps and should > therefore be in QUIC. To force every application developer to implement a > timer to perform a clean close seems pointlessly duplicative. > > I think I agree with this - and it would also help to have a sensible baseline here rather than having apps not think through the consequences and just doing 0-idle after last write (which brings up the specter of repeating TCP RST and unintentional data loss as part of supposedly clean shutdown) - that seems like a transport responsibility. --001a114d809c630f87054aedaf1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Mar 17, 2017 at 1:18 AM, Martin Duke <martin.h.duke@gmail.c= om> wrote:
The DRAIN timer in your concept is common to most/all apps and should= therefore be in QUIC. To force every application developer to implement a = timer to perform a clean close seems pointlessly duplicative.

I think I agree with this - a= nd it would also help to have a sensible baseline here rather than having a= pps not think through the consequences and just doing 0-idle after last wri= te (which brings up the specter of repeating TCP RST and unintentional data= loss as part of supposedly clean shutdown) - that seems like a transport r= esponsibility.
=C2=A0
--001a114d809c630f87054aedaf1c-- From nobody Fri Mar 17 09:58:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D021201F2 for ; Fri, 17 Mar 2017 09:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dQgAno9s-Pu9 for ; Fri, 17 Mar 2017 09:58:42 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EBB1294A5 for ; Fri, 17 Mar 2017 09:58:41 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id q7so47516974uaf.2 for ; Fri, 17 Mar 2017 09:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EBa1E3M8sSermUdWIQX6Q04SJPSCTHpojlBe7dMIhwY=; b=Rz+d9FZtqhLWHqh0BB0ZHuG2RviJEzVhJ9/CWXbtMSH8VeishJLE9hV2H5SIZJF07q yI4bPRsdfaEmpIXwk/VElKOG3pRx/FmRDM7Lrn7MoKdGYMSX6fLS/mytdIReinZF9TYv IyZjJOWf8l3OXC9SD5DbubiArd2jFRP0j9nX3LCqUcHz4CEc3q7gJmH0tOGK0iHDP49U 0NQVcE12JKvQrJvVOskhExsa/xrmJ+QiaUEbm6ypKg0oFR1drRZs3fZhcYZvGHD8V8Cq zGEpDAG12K3QLedADbnrWVI/Lh9U34ejS3EitP30N76mmJOhENFTxp/zzCjC8FUsNio/ X2Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EBa1E3M8sSermUdWIQX6Q04SJPSCTHpojlBe7dMIhwY=; b=E1fUihjDmmJgpi5ICeAirwcOxpSXAxqPGBGB/E97Te7dPueT4LGSO+bxL5R2Ksx1KK DGrSjlib+vJA+AGo5HFCv0xozcvqW7MaHhdEG4lP89qpr49VcS4hwmaSBvYXdRoXgtWA BrI6+OJwmqUsubzfbbKUWn3XBrddFUdJxGJC/+BzS84sY42Soc0b9/+hs3nluslvCHO5 U4JJ6dSMT8TbOf2406GI1GJIECE/xN5OfKy6SNZ0rkG9Xsd3cIXNOnYQOCQHiw80I463 1EUiFtN84KI4Ovon/xItReiPp2dEc+E3/0L3rg0I/xCW679Lyb/KZBYf08IIWG/rd9wU vSSA== X-Gm-Message-State: AFeK/H3nBrJAkvLcUWmqVftmmZ6w5XDkxCLjV5GRqT/MGWfsFoCE3YdVajc3nhrzmFOmVvd1Ygut06yHALgYjARP X-Received: by 10.159.54.205 with SMTP id p71mr5353768uap.61.1489769920720; Fri, 17 Mar 2017 09:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Fri, 17 Mar 2017 09:58:39 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 17 Mar 2017 09:58:39 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Cc: Martin Duke , Ryan Hamilton , Ted Hardie , Ian Swett , Mike Bishop , Lucas Clemente , IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c03d92aecbf3c054af01640 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 16:58:44 -0000 --94eb2c03d92aecbf3c054af01640 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 17, 2017 at 2:51 AM, Martin Thomson wrote: > On 17 March 2017 at 18:00, Jana Iyengar wrote: > > On Thu, Mar 16, 2017 at 10:18 PM, Martin Duke > > wrote: > >> > >> The DRAIN timer in your concept is common to most/all apps and should > >> therefore be in QUIC. To force every application developer to implement > a > >> timer to perform a clean close seems pointlessly duplicative. > > > > > > Yeah, I was in two minds about this. This is a reasonable expectation to > > have from the transport (though not all apps need this), so we could move > > the DRAIN time (after close() and error close) to inside QUIC. This would > > make the error close logic more contained inside QUIC. The application > could > > still do the logic required for an idle close. > > I had the same sense as Martin here, and this would be easier in some > ways. Note that one consequence of your model is that the idle timer > moves under encryption because it would be an HTTP setting, not a > transport parameter. I can see pros and cons to that. Good point, that had not occurred to me. I'm wary of middleboxes reading into the ClientHello messages to pull out a value, so it's more a pro from my point of view than a con. But, it is a difference for sure. >> Moreover, in any case I think a packet needs to go over the wire at the > >> QUIC layer. > > > > I don't think this is required. What packet are you thinking about? > > I can't think of a reason either. Any packet that QUIC sends is going > to cost radio/battery/bandwidth where it would otherwise be silent and > I would prefer silent unless there is a good reason. > --94eb2c03d92aecbf3c054af01640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 17, 2017 at 2:51 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 17 March 2017 at 18:00, Jana Iyengar <jri@google.com> wrote:
> On Thu, Mar 16, 2017 at 10:18 PM, Martin Duke <martin.h.duke@gmail.com>
> wrote:
>>
>> The DRAIN timer in your concept is common to most/all apps and sho= uld
>> therefore be in QUIC. To force every application developer to impl= ement a
>> timer to perform a clean close seems pointlessly duplicative.
>
>
> Yeah, I was in two minds about this. This is a reasonable expectation = to
> have from the transport (though not all apps need this), so we could m= ove
> the DRAIN time (after close() and error close) to inside QUIC. This wo= uld
> make the error close logic more contained inside QUIC. The application= could
> still do the logic required for an idle close.

I had the same sense as Martin here, and this would be easier in som= e
ways.=C2=A0 Note that one consequence of your model is that the idle timer<= br> moves under encryption because it would be an HTTP setting, not a
transport parameter.=C2=A0 I can see pros and cons to that.

Good point, that had not occurred to me. I'm wary of m= iddleboxes reading into the ClientHello messages to pull out a value, so it= 's more a pro from my point of view than a con. But, it is a difference= for sure.

>> Moreover, in any case I think a packet needs to go over the wire a= t the
>> QUIC layer.
>
> I don't think this is required. What packet are you thinking about= ?

I can't think of a reason either.=C2=A0 Any packet that QUIC sen= ds is going
to cost radio/battery/bandwidth where it would otherwise be silent and
I would prefer silent unless there is a good reason.

--94eb2c03d92aecbf3c054af01640-- From nobody Fri Mar 17 10:00:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88D91294D7 for ; Fri, 17 Mar 2017 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc8-lwSINTkb for ; Fri, 17 Mar 2017 10:00:25 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0135.outbound.protection.outlook.com [104.47.32.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B5F1294CA for ; Fri, 17 Mar 2017 10:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FAou4/h7L6CrJzkfrfJE9FCK0JTiefp3ZFiooTShmpc=; b=IQ5y9/Dt/ocne/Hckz34mW3/rVwTw3e0XExKkOWmi7nEob9yNunTARFP0aKrGfKGTHVacoBzsWos7LP49LwmKuGR/BDIQvqCuknsfWkMQIAnNTtpPoNBo9JravybDu3wPxIJdKVGQ9VSCu4jITFnwpQ5P/ZI1rdosOrSAOmKzkU= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Fri, 17 Mar 2017 17:00:19 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.020; Fri, 17 Mar 2017 17:00:19 +0000 From: Mike Bishop To: Patrick McManus , Martin Duke CC: Ted Hardie , Ian Swett , "Ryan Hamilton" , Lucas Clemente , Jana Iyengar , IETF QUIC WG , Martin Thomson Subject: RE: Move GOAWAY to HTTP draft Thread-Topic: Move GOAWAY to HTTP draft Thread-Index: AQHSlf4x+1FK6xgGX0mOGjIclw5osqGG1dGAgAAEPYCAACiUsIAAHj8AgACw04CAAJjegIAABhWAgAAGbACAAALxAIABIi8AgABqpQCAADtHAIAABrcAgAw79QCAAF+RgIAAJkMAgAD7WICAAAMe8IAABicAgAAXN4CAAABe8IAABwSAgAAs54CAADUTgIAAk5GAgAAoGyA= Date: Fri, 17 Mar 2017 17:00:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [172.58.43.42] x-ms-office365-filtering-correlation-id: 0aaa0f03-5804-4ae8-051e-08d46d5717d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:qelmPfSdVc/8FrTJCYP5L8li77lFyrswrSNno7EskFOBMki7Ixsirouewqa07fwZ/FRd1DuQsLxsrxX0lY3c3DJHSoJYGzV38dA1L+uomdyakflZxK+pGf3sgeE/Np3dxRlOpPv4YfgktP4nQ53h9zLsHDIw8eBdjuIoPWgyPOHXExgUbACz/B7gL/+9UBIJ/MSnbrKk5Rj+LQ0d7c1eU+F+5XLFiA1xF/6bJDm/2Vva+jBwoHPkWRXEwZ03vOcm76DxEZXsutB8CFdjXF+erhFnAGwDUMgtirGTrCNBRAaWj1fX04chKjrVayay83BVKKeOtFnDhM4gYgXqdul/zzzH7cBhxtEpTkxBRg/6Jdo= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(24454002)(377454003)(2906002)(5005710100001)(93886004)(33656002)(9686003)(25786008)(81166006)(3846002)(236005)(86612001)(122556002)(77096006)(74316002)(6306002)(38730400002)(6246003)(7736002)(39060400002)(790700001)(6506006)(6116002)(6436002)(102836003)(86362001)(3660700001)(55016002)(229853002)(54906002)(5660300001)(7696004)(53936002)(99286003)(10290500002)(54896002)(2950100002)(19609705001)(76176999)(8990500004)(8936002)(66066001)(2900100001)(10090500001)(4326008)(189998001)(8676002)(54356999)(50986999)(3280700002)(53546008); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB270871EC1095B1DA865EA2D787390BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2017 17:00:19.2950 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 17:00:28 -0000 --_000_BN6PR03MB270871EC1095B1DA865EA2D787390BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBndWVzcyBJ4oCZbSBzdGlsbCBhIGxpdHRsZSBzdHVjayBvbiB3aHkgdGhlcmXigJlzIGEgdGlt ZXIgaW4gdGhlIGNsZWFuIGNhc2UgYW55d2F5LiAgSW4gdGhlIGNsZWFuIGNhc2UsIGl0IHNob3Vs ZCBiZSBhIGRldGVybWluaXN0aWMgY2xvc3VyZSBiYXNlZCBvbiByZWFjaGluZyBhIGRlZmluZWQg ZW5kIHN0YXRlLCBzaG91bGRu4oCZdCBpdD8gIEluIGFuIGVycm9yIGNsb3NlLCB5b3UgcHJvYmFi bHkgZG9u4oCZdCBoYXZlIGVub3VnaCBzaGFyZWQgc3RhdGUgdG8gaGF2ZSB0aGF0IHJlcXVpcmVt ZW50LCBzbyBhIHRpbWVyIG1heSBiZSByZXF1aXJlZC4NCg0KSSB0aGluayB3ZSBhbGwgYWdyZWUg dGhhdCB0aGUgY29ubmVjdGlvbiBiZWluZyBjbG9zZWQgaXMgZXF1aXZhbGVudCB0byBzYXlpbmcg YWxsIHN0cmVhbXMgYXJlIGNsb3NlZCwgdGhvdWdoIHlvdSBjYW4gbWFrZSBhIGNhc2UgZm9yIGVp dGhlciBiZWluZyB0aGUgY2F1c2Ugb2YgdGhlIG90aGVyLiAgR29pbmcgYSBzdGVwIGJleW9uZCB0 aGF0LCB0aGUgY29ubmVjdGlvbiBpcyDigJxjbG9zZWTigJ0gKGFuZCBzdGF0ZSBjYW4gYmUgZGlz Y2FyZGVkKSB3aGVuIGFsbCBzdHJlYW1zIGFyZSBlaXRoZXIgaWRsZSBvciBjbG9zZWQsIGJvdGgg c2lkZXMgYWdyZWUgb24gYWxsIHN0cmVhbSBzdGF0ZXMsIGFuZCB0aGUgYXBwIGhhcyBpbmRpY2F0 ZWQgYSBkZXNpcmUgdG8gY2xvc2UgdGhlIGNvbm5lY3Rpb24uDQoNCkJhc2VkIG9uIHRoZSBuZXcg QUNLIHRleHQgaW4gLTAyLCB3ZSBoYXZlIGEgZGVmaW5lZCBjb25jZXB0IG9mIHdoZW4gdGhlIG90 aGVyIHNpZGUgaGFzIGNhdWdodCB1cCB0byB0aGUgbG9jYWwgcGVyc3BlY3RpdmUgb2YgYSBzdHJl YW0gc3RhdGU6ICBXaGVuIGFsbCBvdXRzdGFuZGluZyBTVFJFQU0gZnJhbWVzIHRocm91Z2ggdGhl IEZJTiBoYXZlIGJlZW4gQUNL4oCZZCwgb3Igd2hlbiBhIFJTVF9TVFJFQU0gZnJhbWUgaGFzIGJl ZW4gQUNL4oCZZC4gIFRvIGtub3cgdGhhdCBib3RoIHNpZGVzIGFyZSBpbiBzeW5jLCB5b3UgYWxz byBuZWVkIHRvIGtub3cgdGhhdCB5b3VyIEFDS3MgaGF2ZSBiZWVuIHJlY2VpdmVkLCBzbyB5b3Ug bmVlZCB0byBzdGFydCBzb2xpY2l0aW5nIEFDS3Mgb2YgYW55IEFDS3Mgd2hpY2ggY292ZXIgYW55 IFNUUkVBTSBvciBSU1RfU1RSRUFNIGZyYW1lcy4gIFlvdSBzaG91bGQgcXVpY2tseSByZWFjaCBh IHN0YXRlIHdoZXJlIGFsbCBzdHJlYW1zIGFyZSBlaXRoZXIgY2xvc2VkIG9yIGlkbGUsIGFuZCBu ZWl0aGVyIHNpZGUgaXMgZXhwZWN0aW5nIG1vcmUgQUNLcy4gIEF0IHRoYXQgcG9pbnQsIHlvdSBj YW4gZGlzY2FyZCBhbGwgc3RhdGUgc2lsZW50bHkuDQoNClBlcmhhcHMgYSBjbGVhbiBjbG9zdXJl IGxvb2tzIGxpa2UgdGhpczoNCg0KICAqICAgQXBwIG5vdGlmaWVzIHBlZXIgKGF0IGFwcCBsYXll cikgb2YgaW50ZW50IHRvIGNsb3NlIHRoZSBjb25uZWN0aW9uDQogICAgICogICBDYXZlYXQgaXMg YmVjYXVzZSBpbiBIVFRQLCB3aGVyZSBzZXJ2ZXJzIG9ubHkgaW5pdGlhdGUgaW4gcmVhY3Rpb24g dG8gcmVxdWVzdHMsIGFuIGlkbGUgY2xpZW50IGNvdWxkIG9wdCB0byBjbG9zZSB3aXRob3V0IGNv b3JkaW5hdGlvbiwgc2luY2UgdGhlIHNlcnZlciB3b27igJl0IGJlIHNlbmRpbmcgYW55dGhpbmcu DQogICAgICogICBOb3RlIHRoYXQgdGhpcyBzdHJvbmdseSBpbXBsaWVzIGV2ZXJ5IHByb3RvY29s IG1hcHBpbmcgd2lsbCBuZWVkIGEgY29udHJvbCBzdHJlYW0NCiAgKiAgIEFwcCBjYWxscyBzaHV0 ZG93bigpIG9uIGVhY2ggc2lkZQ0KICAqICAgVHJhbnNwb3J0IGRvZXMgdGhlIGZvbGxvd2luZyBv biBzaHV0ZG93bigpOg0KICAgICAqICAgUHJvaGliaXRzIGluaXRpYXRpbmcgbmV3IHN0cmVhbXMN CiAgICAgKiAgIFdhaXRzIGZvciBhbGwgYXBwLWNvbnRyb2xsZWQgc3RyZWFtcyB0byBjbG9zZSBp biB0aGUgbG9jYWwgcGVyc3BlY3RpdmUNCiAgICAgICAgKiAgIFBlZXIgY291bGQgc3RpbGwgaW5p dGlhdGUgbmV3IHN0cmVhbXM7IHdlIHJlbHkgb24gdGhlIGFwcCB0byBpbmZvcm0gdGhlbSB0aGV5 IHNob3VsZG7igJl0IGFuZCByZWplY3QgYW55IG5ldyBzdHJlYW1zDQogICAgICogICBCZWdpbnMg YWN0aXZlbHkgc29saWNpdGluZyBBQ0tzIG9mIEFDS3Mgd2hlcmUgbmVjZXNzYXJ5IChieSBpbmNs dWRpbmcgV0lORE9XX1VQREFURSBvciBQSU5HIGZyYW1lcykNCiAgICAgICAgKiAgIFdoZXJlIG5l Y2Vzc2FyeSA9PiBBQ0sgY292ZXJzIGEgU1RSRUFNIG9yIFJTVF9TVFJFQU0gZnJhbWUNCiAgICAg KiAgIERpc2NhcmQgYWxsIHN0YXRlIHdoZW4gbm8gQUNLcyBhcmUgb3V0c3RhbmRpbmcNCg0KDQpG cm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF0 cmljayBNY01hbnVzDQpTZW50OiBGcmlkYXksIE1hcmNoIDE3LCAyMDE3IDc6MDcgQU0NClRvOiBN YXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpDYzogTWlrZSBCaXNob3AgPE1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5j b20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBSeWFuIEhhbWlsdG9uIDxyY2hA Z29vZ2xlLmNvbT47IEx1Y2FzIENsZW1lbnRlIDxsdWNhc0BsY2xlbWVudGUub3JnPjsgSmFuYSBJ eWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1h cnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogTW92 ZSBHT0FXQVkgdG8gSFRUUCBkcmFmdA0KDQoNCk9uIEZyaSwgTWFyIDE3LCAyMDE3IGF0IDE6MTgg QU0sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLmgu ZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBEUkFJTiB0aW1lciBpbiB5b3VyIGNvbmNlcHQg aXMgY29tbW9uIHRvIG1vc3QvYWxsIGFwcHMgYW5kIHNob3VsZCB0aGVyZWZvcmUgYmUgaW4gUVVJ Qy4gVG8gZm9yY2UgZXZlcnkgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHRvIGltcGxlbWVudCBhIHRp bWVyIHRvIHBlcmZvcm0gYSBjbGVhbiBjbG9zZSBzZWVtcyBwb2ludGxlc3NseSBkdXBsaWNhdGl2 ZS4NCg0KDQpJIHRoaW5rIEkgYWdyZWUgd2l0aCB0aGlzIC0gYW5kIGl0IHdvdWxkIGFsc28gaGVs cCB0byBoYXZlIGEgc2Vuc2libGUgYmFzZWxpbmUgaGVyZSByYXRoZXIgdGhhbiBoYXZpbmcgYXBw cyBub3QgdGhpbmsgdGhyb3VnaCB0aGUgY29uc2VxdWVuY2VzIGFuZCBqdXN0IGRvaW5nIDAtaWRs ZSBhZnRlciBsYXN0IHdyaXRlICh3aGljaCBicmluZ3MgdXAgdGhlIHNwZWN0ZXIgb2YgcmVwZWF0 aW5nIFRDUCBSU1QgYW5kIHVuaW50ZW50aW9uYWwgZGF0YSBsb3NzIGFzIHBhcnQgb2Ygc3VwcG9z ZWRseSBjbGVhbiBzaHV0ZG93bikgLSB0aGF0IHNlZW1zIGxpa2UgYSB0cmFuc3BvcnQgcmVzcG9u c2liaWxpdHkuDQoNCg== --_000_BN6PR03MB270871EC1095B1DA865EA2D787390BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA2MTQ0 NjU0MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjI1 NzYwNDg0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIEnigJltIHN0aWxsIGEgbGl0dGxlIHN0dWNrIG9uIHdo eSB0aGVyZeKAmXMgYSB0aW1lciBpbiB0aGUgY2xlYW4gY2FzZSBhbnl3YXkuJm5ic3A7IEluIHRo ZSBjbGVhbiBjYXNlLCBpdCBzaG91bGQgYmUgYSBkZXRlcm1pbmlzdGljIGNsb3N1cmUgYmFzZWQg b24gcmVhY2hpbmcgYSBkZWZpbmVkIGVuZCBzdGF0ZSwgc2hvdWxkbuKAmXQgaXQ/Jm5ic3A7IElu IGFuIGVycm9yIGNsb3NlLCB5b3UgcHJvYmFibHkgZG9u4oCZdCBoYXZlDQogZW5vdWdoIHNoYXJl ZCBzdGF0ZSB0byBoYXZlIHRoYXQgcmVxdWlyZW1lbnQsIHNvIGEgdGltZXIgbWF5IGJlIHJlcXVp cmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHdlIGFsbCBhZ3JlZSB0aGF0IHRo ZSBjb25uZWN0aW9uIGJlaW5nIGNsb3NlZCBpcyBlcXVpdmFsZW50IHRvIHNheWluZyBhbGwgc3Ry ZWFtcyBhcmUgY2xvc2VkLCB0aG91Z2ggeW91IGNhbiBtYWtlIGEgY2FzZSBmb3IgZWl0aGVyIGJl aW5nIHRoZSBjYXVzZSBvZiB0aGUgb3RoZXIuJm5ic3A7IEdvaW5nIGEgc3RlcCBiZXlvbmQgdGhh dCwgdGhlIGNvbm5lY3Rpb24gaXMg4oCcY2xvc2Vk4oCdIChhbmQgc3RhdGUgY2FuDQogYmUgZGlz Y2FyZGVkKSB3aGVuIGFsbCBzdHJlYW1zIGFyZSBlaXRoZXIgaWRsZSBvciBjbG9zZWQsIGJvdGgg c2lkZXMgYWdyZWUgb24gYWxsIHN0cmVhbSBzdGF0ZXMsIGFuZCB0aGUgYXBwIGhhcyBpbmRpY2F0 ZWQgYSBkZXNpcmUgdG8gY2xvc2UgdGhlIGNvbm5lY3Rpb24uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJhc2VkIG9uIHRoZSBuZXcgQUNLIHRleHQgaW4gLTAyLCB3ZSBoYXZlIGEgZGVmaW5lZCBj b25jZXB0IG9mIHdoZW4gdGhlIG90aGVyIHNpZGUgaGFzIGNhdWdodCB1cCB0byB0aGUgbG9jYWwg cGVyc3BlY3RpdmUgb2YgYSBzdHJlYW0gc3RhdGU6Jm5ic3A7IFdoZW4gYWxsIG91dHN0YW5kaW5n IFNUUkVBTSBmcmFtZXMgdGhyb3VnaCB0aGUgRklOIGhhdmUgYmVlbiBBQ0vigJlkLCBvciB3aGVu IGEgUlNUX1NUUkVBTSBmcmFtZQ0KIGhhcyBiZWVuIEFDS+KAmWQuJm5ic3A7IFRvIGtub3cgdGhh dCBib3RoIHNpZGVzIGFyZSBpbiBzeW5jLCB5b3UgYWxzbyBuZWVkIHRvIGtub3cgdGhhdCB5b3Vy IEFDS3MgaGF2ZSBiZWVuIHJlY2VpdmVkLCBzbyB5b3UgbmVlZCB0byBzdGFydCBzb2xpY2l0aW5n IEFDS3Mgb2YgYW55IEFDS3Mgd2hpY2ggY292ZXIgYW55IFNUUkVBTSBvciBSU1RfU1RSRUFNIGZy YW1lcy4mbmJzcDsgWW91DQo8aT5zaG91bGQ8L2k+IHF1aWNrbHkgcmVhY2ggYSBzdGF0ZSB3aGVy ZSBhbGwgc3RyZWFtcyBhcmUgZWl0aGVyIGNsb3NlZCBvciBpZGxlLCBhbmQgbmVpdGhlciBzaWRl IGlzIGV4cGVjdGluZyBtb3JlIEFDS3MuJm5ic3A7IEF0IHRoYXQgcG9pbnQsIHlvdSBjYW4gZGlz Y2FyZCBhbGwgc3RhdGUgc2lsZW50bHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBlcmhhcHMg YSBjbGVhbiBjbG9zdXJlIGxvb2tzIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5BcHAg bm90aWZpZXMgcGVlciAoYXQgYXBwIGxheWVyKSBvZiBpbnRlbnQgdG8gY2xvc2UgdGhlIGNvbm5l Y3Rpb248bzpwPjwvbzpwPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xl Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+Q2F2ZWF0IGlzIGJlY2F1c2UgaW4gSFRUUCwgd2hlcmUg c2VydmVycyBvbmx5IGluaXRpYXRlIGluIHJlYWN0aW9uIHRvIHJlcXVlc3RzLCBhbiBpZGxlIGNs aWVudCBjb3VsZCBvcHQgdG8gY2xvc2Ugd2l0aG91dCBjb29yZGluYXRpb24sIHNpbmNlIHRoZSBz ZXJ2ZXIgd29u4oCZdCBiZSBzZW5kaW5nIGFueXRoaW5nLjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzEiPk5vdGUgdGhhdCB0aGlzIHN0cm9uZ2x5IGltcGxpZXMgZXZlcnkgcHJvdG9j b2wgbWFwcGluZyB3aWxsIG5lZWQgYSBjb250cm9sIHN0cmVhbTxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkFwcCBjYWxscyBzaHV0ZG93bigpIG9uIGVhY2gg c2lkZTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlRyYW5zcG9ydCBkb2VzIHRo ZSBmb2xsb3dpbmcgb24gc2h1dGRvd24oKTo8bzpwPjwvbzpwPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+UHJvaGliaXRzIGlu aXRpYXRpbmcgbmV3IHN0cmVhbXM8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj5X YWl0cyBmb3IgYWxsIGFwcC1jb250cm9sbGVkIHN0cmVhbXMgdG8gY2xvc2UgaW4gdGhlIGxvY2Fs IHBlcnNwZWN0aXZlPG86cD48L286cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzEiPlBlZXIgY291bGQgc3RpbGwgaW5pdGlhdGUg bmV3IHN0cmVhbXM7IHdlIHJlbHkgb24gdGhlIGFwcCB0byBpbmZvcm0gdGhlbSB0aGV5IHNob3Vs ZG7igJl0IGFuZCByZWplY3QgYW55IG5ldyBzdHJlYW1zPG86cD48L286cD48L2xpPjwvdWw+DQo8 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+QmVnaW5zIGFjdGl2ZWx5IHNvbGljaXRpbmcgQUNLcyBv ZiBBQ0tzIHdoZXJlIG5lY2Vzc2FyeSAoYnkgaW5jbHVkaW5nIFdJTkRPV19VUERBVEUgb3IgUElO RyBmcmFtZXMpPG86cD48L286cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9InNx dWFyZSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzEiPldoZXJlIG5lY2Vzc2FyeSA9Jmd0OyBBQ0sgY292 ZXJzIGEgU1RSRUFNIG9yIFJTVF9TVFJFQU0gZnJhbWU8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMiBsZm8xIj5EaXNjYXJkIGFsbCBzdGF0ZSB3aGVuIG5vIEFDS3MgYXJl IG91dHN0YW5kaW5nPG86cD48L286cD48L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5QYXRyaWNrIE1jTWFudXM8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBNYXJjaCAxNywgMjAxNyA3OjA3IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gRHVr ZSAmbHQ7bWFydGluLmguZHVrZUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJp c2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IFRlZCBIYXJkaWUgJmx0 O3RlZC5pZXRmQGdtYWlsLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNv bSZndDs7IFJ5YW4gSGFtaWx0b24gJmx0O3JjaEBnb29nbGUuY29tJmd0OzsgTHVjYXMgQ2xlbWVu dGUgJmx0O2x1Y2FzQGxjbGVtZW50ZS5vcmcmZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29n bGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWFydGluDQog VGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogTW92ZSBHT0FXQVkgdG8gSFRUUCBkcmFmdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEZyaSwgTWFyIDE3LCAyMDE3IGF0IDE6MTggQU0sIE1hcnRpbiBEdWtlICZs dDs8YSBocmVmPSJtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBEUkFJTiB0aW1lciBpbiB5b3VyIGNvbmNl cHQgaXMgY29tbW9uIHRvIG1vc3QvYWxsIGFwcHMgYW5kIHNob3VsZCB0aGVyZWZvcmUgYmUgaW4g UVVJQy4gVG8gZm9yY2UgZXZlcnkgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHRvIGltcGxlbWVudCBh IHRpbWVyIHRvIHBlcmZvcm0gYSBjbGVhbiBjbG9zZSBzZWVtcyBwb2ludGxlc3NseSBkdXBsaWNh dGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgSSBhZ3JlZSB3aXRoIHRoaXMgLSBh bmQgaXQgd291bGQgYWxzbyBoZWxwIHRvIGhhdmUgYSBzZW5zaWJsZSBiYXNlbGluZSBoZXJlIHJh dGhlciB0aGFuIGhhdmluZyBhcHBzIG5vdCB0aGluayB0aHJvdWdoIHRoZSBjb25zZXF1ZW5jZXMg YW5kIGp1c3QgZG9pbmcgMC1pZGxlIGFmdGVyIGxhc3Qgd3JpdGUgKHdoaWNoIGJyaW5ncyB1cCB0 aGUgc3BlY3RlciBvZiByZXBlYXRpbmcgVENQIFJTVCBhbmQNCiB1bmludGVudGlvbmFsIGRhdGEg bG9zcyBhcyBwYXJ0IG9mIHN1cHBvc2VkbHkgY2xlYW4gc2h1dGRvd24pIC0gdGhhdCBzZWVtcyBs aWtlIGEgdHJhbnNwb3J0IHJlc3BvbnNpYmlsaXR5Ljxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_BN6PR03MB270871EC1095B1DA865EA2D787390BN6PR03MB2708namp_-- From nobody Fri Mar 17 12:05:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1299C12940B for ; Fri, 17 Mar 2017 12:05:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zcR_zZ9zz0gA for ; Fri, 17 Mar 2017 12:05:46 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040E71273E2 for ; Fri, 17 Mar 2017 12:05:44 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id q7so49403103uaf.2 for ; Fri, 17 Mar 2017 12:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xuoHIbI2Ptq6goBFQFB2pEUyrowBcT/Cpw45FBNGJuQ=; b=gTNZ2Q+pPtdIxm4gOhghMO93SQYbB5Rq+r9K/rUWrZtD/8TuDQgwRee66/pDaPouWd hQ/+7Hhzh4uupcO1SCC3Dj4hnJWsvsGpqEFmhZgKrfgimrsE79iGjSFROBWKVDrjVc3y iY5TKa74tQxO/gfN5Kz0TmKVRGJBlOwqQF067Sb3WIDi+kdAzkkjiWmVQoqzpKJDGRxn xNvj+6uL7b3VyRsBmt2EzbPyu1l12EXVLaLibMIOQnpzBV9HhS1tzEuyN9EID3vcMDSE x4ydFhG2KxKIpGY9y8dNVuth34BYP3QDi5Y4rFf2XceCsujtwSHfdNVBgrM0yhEFgpqU EozA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xuoHIbI2Ptq6goBFQFB2pEUyrowBcT/Cpw45FBNGJuQ=; b=dt/rfA0RCoVi7CGZv1Zd2sim9/e5fZB+8CNiSPX27tVprTm+eu+SeT5iIPHdCkK9Mz yhYbHWJwiVuZID9rFrh1LEj0HYxzE1Iu0+HXulBtdzENwdE5ObKSVuX/LHIyw/yVRDKc KcQz7BJHDwfRHdiwqrwb90wivceKmN0GfbjJV5PQKOt+BOW2wjYdLtIA3hF8l8oY034U bwmO17JoAhigNpbzgRQO3FoJK2o6NlSVwaDTPclVv9VQ5PmUCl3bsBV6vBjOK/pIFu8X 1FeIIZjhnzYYMW8S1M5E7TZmBi4v/rpgaO4nKESdzRqX2dKst0P4B8DzrO5BV9WYL+cs O8Ag== X-Gm-Message-State: AFeK/H32kPLldGKCcFd0y7qYzbZDCS5GLl3atOqBfoSaYD+7XziGL2dhLMs/simXY1QC8e2cLjA6RlFZFHDO7Lyv X-Received: by 10.176.80.72 with SMTP id z8mr7412996uaz.139.1489777542806; Fri, 17 Mar 2017 12:05:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Fri, 17 Mar 2017 12:05:42 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 17 Mar 2017 12:05:42 -0700 Message-ID: Subject: Re: PSA: github issues are now available offline To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c1925563c5d7d054af1dd10 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 19:05:48 -0000 --94eb2c1925563c5d7d054af1dd10 Content-Type: text/plain; charset=UTF-8 Cool -- thanks for setting this up, Martin! On Fri, Mar 17, 2017 at 3:07 AM, Martin Thomson wrote: > We have been saving issues to the `gh-issues` branch in the repository > for some time now. Anyone with an up-to-date clone of the repository > can checkout this branch and see two files: issues.json and > pulls.json. These files contain summary information about all issues > including things like title, labels, people, and the issue summary > (comments are much bigger and harder to retrieve, I'm still not sure > whether it is worthwhile loading all of these). > > I recently added issues.html to this. It's crude, but it has a view > of the issues that you can access offline. There are some basic > filtering options there as well. > > You can see the results online here: > https://rawgit.com/quicwg/base-drafts/gh-issues/issues.html > > When I say crude, I'm not messing around. You will need Firefox to > read this when you are offline. I'm not a web developer, so I used the > tools I'm familiar with. The code runs in Chrome, but Chrome won't > load file scheme resources (so the link above works, but you will be > sad if you try to look at your local copy). And Edge doesn't like > async functions (yet). Also, I didn't test Safari. Pull requests are > always welcome if people find those limitations annoying and have the > means and inclination to work on fixing them. See > https://github.com/martinthomson/i-d-template/blob/master/template/issues. > html > > --94eb2c1925563c5d7d054af1dd10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cool -- thanks for setting this up, Martin!

On Fri, Mar 17, 2017 at 3:= 07 AM, Martin Thomson <martin.thomson@gmail.com> wrot= e:
We have been saving issues to the `gh-= issues` branch in the repository
for some time now.=C2=A0 Anyone with an up-to-date clone of the repository<= br> can checkout this branch and see two files: issues.json and
pulls.json.=C2=A0 These files contain summary information about all issues<= br> including things like title, labels, people, and the issue summary
(comments are much bigger and harder to retrieve, I'm still not sure whether it is worthwhile loading all of these).

I recently added issues.html to this.=C2=A0 It's crude, but it has a vi= ew
of the issues that you can access offline.=C2=A0 There are some basic
filtering options there as well.

You can see the results online here:
https://rawgit.com/quicwg/base-draft= s/gh-issues/issues.html

When I say crude, I'm not messing around.=C2=A0 You will need Firefox t= o
read this when you are offline. I'm not a web developer, so I used the<= br> tools I'm familiar with.=C2=A0 The code runs in Chrome, but Chrome won&= #39;t
load file scheme resources (so the link above works, but you will be
sad if you try to look at your local copy).=C2=A0 And Edge doesn't like=
async functions (yet).=C2=A0 Also, I didn't test Safari.=C2=A0 Pull req= uests are
always welcome if people find those limitations annoying and have the
means and inclination to work on fixing them.=C2=A0 See
https://github.com/martinthomson/i-d-template/blob/master/template/issues.html=


--94eb2c1925563c5d7d054af1dd10-- From nobody Fri Mar 17 15:44:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01435129551 for ; Fri, 17 Mar 2017 15:44:08 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8j5x6R2R3Xx for ; Fri, 17 Mar 2017 15:44:06 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B642127419 for ; Fri, 17 Mar 2017 15:44:06 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id 1so75937241qkl.3 for ; Fri, 17 Mar 2017 15:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=of4abWHjTirsuB0+RrLaE8gqHZvtFxRO//rBuCnWY4w=; b=s0ay9oa09NEB8SvaLVASqcOCsXE8XYf93hulZ5JTdeEhXG35Wk2jk5smgwNF+Vmork I5PdNZCGdbilBqaKuUcBaXb4Amp2HHe3jVsrJGhj7fXyy43uq2e8rtizIoq3e4K3vv6Z K+uMrq7naOG+7luK0L/1xRARmHyZxcOmG0d6r0R8LOBR05SPu/yBJCjMTWOmp5M8LR5L 2bi8DH0oHwLH11RhvDf4LhJ9UZgLyOBsp6xwxCjcjCscYX9MPy3TjZ68aXRO7MZzDc0/ ZLuAykwOr1H0pCu5RsqNIHCUBY9NX0bG9arAyQWUdanA3aV1T+HVqnIxFnZyD4Gu3W37 0/gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=of4abWHjTirsuB0+RrLaE8gqHZvtFxRO//rBuCnWY4w=; b=nfFmsJVS0yPGnEPGH9TiTofs9zVuJy96JkzYYL6Q/rnRL9KkB+Rs5RoujLWR4bmQUe Tl9ga9qmfCTWglv4FIyj3PCOM/HEg5npUCuHmdqbqpNG8gKX0LDvepto4weOZhf4tdIp x9zYxkKz26X90VjJhsNX5ryJNiXEZQotDDFzYALImkYEHVv2UkVi+0VqVF/LA6N+6yiM jAkXO2T2lubOugv16D7p20jrFepnNNRIIYBsslGLze6jjfUigxw6Is7vQBTRa5UcQsBe EeaXtUPKQsW1rsFsmf29IN8ghwYkIxSLCOSPiW95gmobLDtPjICxQSeOkPRwtLxI9LDK fCYQ== X-Gm-Message-State: AFeK/H1G2zJ9q57YtfC8/09i2gQjp3Go1+VrQfVebaQtEqb0k997cYU6y8W9GJfqVKd9pmJhFmj9Tj4Bf4TbEA== X-Received: by 10.55.18.144 with SMTP id 16mr15939644qks.5.1489790645503; Fri, 17 Mar 2017 15:44:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Fri, 17 Mar 2017 15:44:04 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 18 Mar 2017 09:44:04 +1100 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Mike Bishop Cc: Patrick McManus , Martin Duke , Ted Hardie , Ian Swett , Ryan Hamilton , Lucas Clemente , Jana Iyengar , 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.22 Precedence: list List-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 Mar 2017 22:44:08 -0000 On 18 March 2017 at 04:00, Mike Bishop wrote= : > I guess I=E2=80=99m still a little stuck on why there=E2=80=99s a timer i= n the clean case > anyway. In the clean case, it should be a deterministic closure based on > reaching a defined end state, shouldn=E2=80=99t it? In an error close, y= ou probably > don=E2=80=99t have enough shared state to have that requirement, so a tim= er may be > required. DRAIN is for the case where you have skew in this agreed end state. For instance, an endpoint might have send an unneeded retransmission, but later received an ACK. The endpoint that sent the ACK reaches a quiescent state when it sends the ACK and so could close. But it could later receive the extra retransmission. You want to have that retransmission hit the connection state so that it can be cleanly dropped, rather than hitting the "this is a new packet" code path, that's all. From nobody Sun Mar 19 16:09:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE11120227 for ; Sun, 19 Mar 2017 16:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8w3C55rqUecT for ; Sun, 19 Mar 2017 16:09:13 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417A5120025 for ; Sun, 19 Mar 2017 16:09:13 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id r45so95531103qte.3 for ; Sun, 19 Mar 2017 16:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZUcke/LBhySZ/hTBF1LaZQu2xtTusaofbWyc6zdEx2A=; b=OWNq/qlZrXYIAhAu+7qycEUFLtPkDp2tf0AU2EcN1xxt93Wq6UcOf9gGMUWkmxFtxI ND+1jMReaEBENHbXANlXeysLciWira1b/pY3Z0fTY4bdVZQlZ7B8+oDgGbeTCJ7ZvhVl GWkjya7uo9TiBSDmKzkv4VoLDQf5Yasgc/zUKwZ2/iQWi0PlFS71luI/jdGOKxaBCSmf DGcTsrzyIr0IfmULjVk+DmDcnqJaccX8E3nMBSWh2ktDrunHrjDR0nRU5ijBLI+g9N7d qOLFwDShkObmEnrp8sepN8jtxyb2xYfP5doP7Lx0iwoSNP1cNicXFbPrkb//8Dl/BT9A VmcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZUcke/LBhySZ/hTBF1LaZQu2xtTusaofbWyc6zdEx2A=; b=TVPOb2XxxFjoIuj6CL+arp0pMOnD2KTp9rvIVWInCR2DHCD+nowhh/cBZbFjrH1wdp YceYrQqJs6tvBoeLEVxfe7QbXhMY7kEpSF1Ttp2ZRNIm6KVzUXhX7RISwbhlc/AMQbJU pVRa07R3gKv7OgsqxXbdqqePTo+J27W7Z6Jj68522TR1e0X/c6T2cGwNyxM+6tnDi8w4 TbiMLOYDdXx3QA2gGPYIwg4/pCB8mCVC1ivuEEKaFYecKZsnW8pRUSdJZQBbq2Ya/00m hUWHvfrfYQzgF1odZWabTROco3F64jp5Uwmgw31Ewy8DxcEB99mM+pAE8cGjq0VPVtNB jA4g== X-Gm-Message-State: AFeK/H2jBDOEdfUNkYKEQV2h/d2sFYb3lHHXL2Itd8oQVc3OAK5U/WeTR9LwytwJsKM7mzoNoTjj4jm0UWTTEA== X-Received: by 10.237.41.100 with SMTP id s91mr26028220qtd.143.1489964952255; Sun, 19 Mar 2017 16:09:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Sun, 19 Mar 2017 16:09:11 -0700 (PDT) In-Reply-To: <58b235ad-a9bb-d453-0157-f874687ae241@tik.ee.ethz.ch> References: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> <58b235ad-a9bb-d453-0157-f874687ae241@tik.ee.ethz.ch> From: Martin Thomson Date: Mon, 20 Mar 2017 10:09:11 +1100 Message-ID: Subject: Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= 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.22 Precedence: list List-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 Mar 2017 23:09:16 -0000 On 17 March 2017 at 22:25, Mirja K=C3=BChlewind wrote: >> I think that these drafts need to consider the protocol as a package, >> not focus on individual parts. Thus, you should talk about HTTP/QUIC >> and its properties, not talk about a transport protocol. That means >> referencing the HTTP mapping document for introductory matters and >> only referencing other documents when it is relevant to a particular >> point. > > > So I'm actually not sure here and that's something I'd like to discuss. I > would guess that applicability together with H2 will anyway be discussed = in > the H2 mapping draft. However, no matter what, I'm sure there will be peo= ple > that will try to use QUIC with other higher layer protocols and applicati= ons > and I think we need to give some advise here as well, especially if there > are know assumptions we made in the protocol design about the application > behavior or capabilities. Also the group is supposed to potentially > recharter at some point to write more mapping documents. I also saw this > document also as capturing what we learned from h2 for future mapping. There's a real risk of mis-applying lessons when all you have is one example. See our discussion about closing connections and how preconceptions based on experience with TCP have coloured that discussion. > That's a little bit an artifact from the previous version where > manageability was included. But why do you think this is not interesting = for > this document? I think the two most important points in this document > (fallback and 0-RTT) are directly connected to the fact that quic is > encrypted by default. I disagree. Both of those are consequences of other aspects of the design. >> The same paragraph is also saying that if you can't guarantee some >> level of security, then you SHOULD fail: >> >> Moreover, while encryption (in this case TLS) is >> inseparable integrated with QUIC, TLS negotiation over TCP can be >> blocked. In case it is RECOMMENDED to abort the connection >> >> I'm not sure why it's only a SHOULD though. I'm fairly sure that most >> clients will treat this as fatal already. > > I don't really see how to make this a MUST. If you have a service where y= ou > cannot risk to lose connectivity to your costumers, is it better to not e= ven > try to use QUIC directly but only try TLS over TCP and then fallback to > unencrypted TCP if TLS is blocked? It's easy, you delete the word SHOULD and type the word MUST. In HTTP, when you can't get TLS, you can't resolve an https:// URI. We have a very clear rule that says that you prefer to fail than to accept the risk of compromise. This is critical to the functioning of the protocol. That might not be true for DNS over QUIC where the expectations for security are - shall we say - lower. But all this needs to say is that if you have some security expectations and you find that fallback would lead to them being in some way compromised, you fail. >> This section doesn't need to be hopeful, or lobby for particular >> changes. We can use the mailing list for that. > > Yes, the word 'hope' is misplaced here. Do you proposed to remove this > paragraph completely, or do you think it's useful to have a reference to > manageability draft there? I'd remove the paragraph until we have something more concrete. >> ## Section 4 (Multiplexing) >> >> We should probably spend a lot more time discussing the virtues of >> having multiple connections and whether it is possible to obtain >> different treatment for packets on the same flow. >> >> The editor's note is speculative and can be removed. > > > We added this based on the mailing list discussions on > draft-abilash-quic-network-00. Your are absolutely right that these > speculations should be removed from the draft and discussed as issues on = the > protocols. However, I didn't really know so far how to phrase an issue on > that because we didn't really discuss this at all so far and I didn't wan= t > to lose it. I'd recommend using an issue tracker for these sorts of things. >> ## Section 5 (Prioritization) >> >> The second paragraph here is speculative and can be removed. > > > Here the point was to give application some guidance how to implement > prioritization on the application level (and when it might be useful). Ag= ain > this was not meant to be specific advise for h2 but other applications. > However, while some prioritization can be implemented in the higher layer= , > prioritization of retransmission can only be done by quic. That is where we come back to my earlier point. I don't believe that you can generically make sensible decisions about priority. I believe that this is why the working group decided to not include priority signaling in the core transport. I don't see how you can make any better recommendation here. > The point regarding the interface is actually another question I have. > Should this document talk about the quic transport interface. How much > advise to we want to give? Do we maybe even want to talk about an abstrac= t > api? That's a big question. If we do have anything, I suspect that it will be useful to have a guide at some point. What I'd do for this right now is open an issue in the aforementioned tracker and sit on it. We're too far away from settling on the details of the protocol to come up with anything concrete right now. >> ## Section 8 (Versioning) >> >> I think that the key point to make here is that unlike other transport >> protocols, QUIC includes version negotiation. I like that you point >> out that very little is guaranteed to be stable between versions. >> Making a special point about TLS isn't that interesting and I would >> remove that. > > > This was especially meant to be advise to people who already have in mind > that they want to implement quic with a different crypto. Again, I've bee= n > seeing this as general guidance for quic transport (and not for > quic+tls+h2). As such I've been trying to capture guidance for future > mappings and future versions of quic. Revising the protocol to include a new cryptographic handshake protocol is an exceptional circumstance that doesn't need optimizing for. If we have that many handshake protocols that it is a real problem, we're in serious trouble. >> In Section 3.3, this is incorrect, except under certain conditions: >> If the QUIC handshake was not observed by the defense system, the >> connection ID can be used as a confirmation signal as per >> [I-D.trammell-plus-statefulness]. >> >> This is (currently) only true in the following cases: >> 1. the server uses version negotiation >> 2. the server uses HelloRetryRequest (a stateless reject) >> 3. the server uses the client-selected connection ID (though I >> wouldn't want to rely on that) >> 4. the connection ID is sent in both directions (Google servers >> routinely avoid sending a connection ID) > > > This was meant to address the case where a middlebox doesn't see any of t= he > handshake but see the middle of the connection. In this case, if presente= d, > seeing the same connection id on the reverse path, gives you a good hit t= hat > both ends actually want to talk to each other. That only invalidates some of my points, leaving the last one. I think that you need to be very clear about what it is that you can see here, the list above is probably a good thing to have. >> However, it is >> questionable if connection migrations needs to be supported in a DDOS >> attack or if a defense system might simply rely on the fast >> resumption mechanism provided by QUIC > > > This was more a comment for DDOS system. Today we don't have this kind of > connection migration. There is a 'fear' that if quic's connection migrati= on > is not visible to the DDOS system it cannot handle quic traffic > sufficiently. However, what happens if the middlebox doesn't know about t= he > migration? The connection will break in a DDOS scenario, and quic has to > reconnect... i don't think that actually a problem. However, I didn't wan= t > to give a recommendation that those system should not track migration yet= , > because we are still discussing how migration will work. I see where you are going now. That text probably just needs some work. Some expository text would be useful, I think. From nobody Tue Mar 21 00:48:26 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DAE129630 for ; Tue, 21 Mar 2017 00:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 chu7020DuARY for ; Tue, 21 Mar 2017 00:48:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 BDC5012962F for ; Tue, 21 Mar 2017 00:48:23 -0700 (PDT) Received: from [192.168.178.20] ([93.217.116.137]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MZU7V-1cc8YT2DLJ-00LFe3; Tue, 21 Mar 2017 08:48:20 +0100 Subject: Re: Core drafts -02 out To: Martin Thomson , IETF QUIC WG References: From: Julian Reschke Message-ID: <6c1d98bc-676e-1ae7-3cff-a7c0dadb4663@gmx.de> Date: Tue, 21 Mar 2017 08:48:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Yp0ylqlqmoULK1Vhj3Ps3izVexsW/C873PzrchcvTSQqTHKDBV/ hkK1IUB1SC/UTl2d0ffryQUkLlzrPaAuD0ErZmSJ/cJtAyB3fM0Nam8u1xLnJZhkP0zCgsm yX4hhEY7p2pGJn2er50oy/QRAO4fnzrvf+c4+0iSyQBpbUgjAHOrdGEFtOr77rMfI3X0U+K /ji3KYqdOHhqbdmoP/sNA== X-UI-Out-Filterresults: notjunk:1;V01:K0:gYFhrCwQCcM=:zzFkYcH0bKppXpHgkKYGud IyHYKQAgshc1bK2GFRwfTWsmOrNwPQfDQnJ1CDrKRrVszIMpTfrdxUSVT6cSWrM2Kha4msSTT CoqVwkTbj0f1lmHPDpaZaVuydInGKquxeECYD2PfbZzJkeJDaQSTuEYZhfruUEl0WaZUDVVbs RRMidkfAihmABDo27IEUje39/BvSbtkPgbfxLv2pvypAE+mLFuCuVSPJz96vJNhq2kibW3IBw TgKkDcg8+qMuvkvZoNmN2bXYybLVWYI9lQTAjUiBFMXW1FqQ6rpfPs9XgSK/3tKSUYd40EbJZ 1i4WM7h3AffFs93RziNkVbtRdz4wsYPgOF0yX4C74tNZ69lY+PRC0RMcHcUdCnGXnmnkSZKm1 t7y2BM1dhOeasgVBZObRQaZoFBRGyesQUK3d6A9DGti5b5OxGrS5psjG+8FgYPBHo+mivb0qj ORj/cgXx5cqc1+zmq9Xkht+dojhL3DSqyowfAQ66CsHuVdWv29esgvKpsN+9Jp/vOBFNK0MQj 3RNRunycNNFKlAyJJ17GIbiOevekyCui7He7qK2YCRE2NjeyUFnQh/2zqUbWbOTM4ryoZBF+m 1WUCFaQRHgNZ7ZhkHrWXcPclhVIozuBZ0Tge4eA7ljOSfl1AJNFhF4Rrc84M0ffDmmbH8neiS mAAqMpNnMcR4mdhNXc+xyE7PM8VdtKEIkCztQqZSpPXJ4TLGxlqkN5Y1lNJrQFV5FiX/BMYa7 R4XdPNjEzV4m0mXYhSNG+G8/zBaWVMBLoUqTESMJg2IrSlZGWOSOa79kye2fd7F/+RdVd/rzm 1g6+M3+ Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 07:48:26 -0000 On 2017-03-14 00:57, Martin Thomson wrote: > The editors have submitted -02 versions of the base set of QUIC drafts. > > https://tools.ietf.org/html/draft-ietf-quic-transport-02 > https://tools.ietf.org/html/draft-ietf-quic-tls-02 > https://tools.ietf.org/html/draft-ietf-quic-recovery-02 > https://tools.ietf.org/html/draft-ietf-quic-http-02 > ... Here's a nit: the drafts currently cite their sibling drafts in a way that doesn't conform to the applicable rules. For instance, in we have: > [QUIC-TRANSPORT] > Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based > Multiplexed and Secure Transport". That lacks the draft name, the publication date, and the mandatory "work in progress" clause. Essentially, a newbie reader would have to do a web search for the document title. Best regards, Julian From nobody Tue Mar 21 01:28:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7BA129680 for ; Tue, 21 Mar 2017 01:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_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=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 L8fDVm3T6-v4 for ; Tue, 21 Mar 2017 01:27:59 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932AC127333 for ; Tue, 21 Mar 2017 01:27:59 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v127so129540578qkb.2 for ; Tue, 21 Mar 2017 01:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8FHSy4T7YS+DPnWI+dhsLKna97luIcsQBBN15jqQwik=; b=VrQl41MAPEBEx3uiAJ3y4A/2ITWgLLUR2qayoPuggQkbl+YSqY9B8oxDVJC/He29Ft V5yTJwSFS+dIvqZl51P4wBB+wHFxcGNR7TumxjM0kkMalcNBoKE/u+j/afnYYJQE7KWD t99Pb0GyhGPxxHsWX+GHRm10yGff95XSL2o/tpJSS1C2rY0X+Ong4qGea0RFYtZkvRMQ 2ZlS8ae0VoEfZjXV4vF3cJtO35c0CbyQljgDRLRPWWeSVq0j1d7W6F1nzna9yUg08fSj YwH5D+PLYE5BZZVaR93wbKgD8qwoa8ZiJQQbS9hqL63wfkV93VVPths+GBEKYLB4GjQZ Fb4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8FHSy4T7YS+DPnWI+dhsLKna97luIcsQBBN15jqQwik=; b=DNsCzkNQEdoAYL9PdYY+PtqxsDv+v1f9NBEgXUVo0MIaodhXyEUL5uc+eKFSENLGTV ytSwKUHv+cY/LraCxqXS1dWjPQL9DwU6lfPD5v9nhWe12rdegbM+CSYjm8z+3cdoflyR Vusdzdkj69P0lL1KMI4QSV0ilOL2IQa4+jw0PYgWYd1xu0DoZa+p2CosWvQS6sX0Q0UR GSTtQmJLHETuNWjzYcEwtxhXHF/yoMYscGQte0uECDnPtXtrTb9U+CJSLNPM20frHSOM UfST608rC810aqoWP4vOLDsEufElt8c70cpM7JuA89VYhp3id4S2r8SGA4UTgC31mcQL h3+w== X-Gm-Message-State: AFeK/H0xu2O28cTGRlfdEm4vPbK/8nAkC4NlvrpyXIGU7RUhou5y8xkgKhotX6DvI9S+AO13IwRd7weGIEX9Zw== X-Received: by 10.233.237.20 with SMTP id c20mr30758596qkg.144.1490084878750; Tue, 21 Mar 2017 01:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 01:27:58 -0700 (PDT) Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 01:27:58 -0700 (PDT) In-Reply-To: <6c1d98bc-676e-1ae7-3cff-a7c0dadb4663@gmx.de> References: <6c1d98bc-676e-1ae7-3cff-a7c0dadb4663@gmx.de> From: Martin Thomson Date: Tue, 21 Mar 2017 19:27:58 +1100 Message-ID: Subject: Re: Core drafts -02 out To: Julian Reschke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1148b42ae21ccc054b396b28 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 08:28:01 -0000 --001a1148b42ae21ccc054b396b28 Content-Type: text/plain; charset=UTF-8 Hi Julian, yes I am aware of this, but I wanted to avoid manual fix ups for these. If you could open an issue, I will work on automating the process of generating references. On 21 Mar. 2017 18:48, "Julian Reschke" wrote: > On 2017-03-14 00:57, Martin Thomson wrote: > >> The editors have submitted -02 versions of the base set of QUIC drafts. >> >> https://tools.ietf.org/html/draft-ietf-quic-transport-02 >> https://tools.ietf.org/html/draft-ietf-quic-tls-02 >> https://tools.ietf.org/html/draft-ietf-quic-recovery-02 >> https://tools.ietf.org/html/draft-ietf-quic-http-02 >> ... >> > > > Here's a nit: the drafts currently cite their sibling drafts in a way that > doesn't conform to the applicable rules. For instance, in < > https://tools.ietf.org/html/draft-ietf-quic-http-02#section-10.1> we have: > > [QUIC-TRANSPORT] >> Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based >> Multiplexed and Secure Transport". >> > > That lacks the draft name, the publication date, and the mandatory "work > in progress" clause. > > Essentially, a newbie reader would have to do a web search for the > document title. > > Best regards, Julian > > --001a1148b42ae21ccc054b396b28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Julian, yes I am aware of this, but I wanted to avoid = manual fix ups for these. If you could open an issue, I will work on automa= ting the process of generating references.
=
On 21 Mar. 2017 18:48, "Julian Reschke&= quot; <julian.reschke@gmx.de> wrote:
On 2017= -03-14 00:57, Martin Thomson wrote:
The editors have submitted -02 versions of the base set of QUIC drafts.

https://tools.ietf.org/html/draft-ietf-= quic-transport-02
https://tools.ietf.org/html/draft-ietf-quic-t= ls-02
https://tools.ietf.org/html/draft-ietf-q= uic-recovery-02
https://tools.ietf.org/html/draft-ietf-quic-= http-02
...


Here's a nit: the drafts currently cite their sibling drafts in a way t= hat doesn't conform to the applicable rules. For instance, in <https://tools.ietf.org/html/draft-ie= tf-quic-http-02#section-10.1> we have:

=C2=A0 =C2=A0[QUIC-TRANSPORT]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Iyengar, J., Ed. and M. Th= omson, Ed., "QUIC: A UDP-Based
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multiplexed and Secure Tra= nsport".

That lacks the draft name, the publication date, and the mandatory "wo= rk in progress" clause.

Essentially, a newbie reader would have to do a web search for the document= title.

Best regards, Julian

--001a1148b42ae21ccc054b396b28-- From nobody Tue Mar 21 15:04:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047AC129BBF for ; Tue, 21 Mar 2017 15:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bwkQdV2wR341 for ; Tue, 21 Mar 2017 15:04:40 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83BD129735 for ; Tue, 21 Mar 2017 15:04:40 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id 190so16454428itm.0 for ; Tue, 21 Mar 2017 15:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0A5bNeSMVq2AorpWkgvBP65MpQydt+QWfcfY+lfVmKY=; b=ZSGPH58Nqvx4hS5n4PZG/96BhmnFqn7dvsl+avaqeiihAPyBGSiKnH8IsxwGeQ6u13 rpW99UdnybKzX0F1jOIEEbVqvzXqGFgqFtRT904XFrwM9h3g0vftRy1zmE8jBOKqUAl+ oENsYb29Bs54I/8f1foG5ConCRWPDfRmKS620l4GbQXf3wFK83oJAQS1ZSOeh3maj8j4 Xe60YNkAjoug+rPn8+8P6PNqbrATsPDPsXPg/f9qC4Cq5+Kc7uO8gX5dEOk/DpR4QpXd rVDlt6w3/KNHIhas/r3ierxLPPkZUgKoBkWREczBnEkdFiT5zRuR3XU1e24BGXwfU0yO QTIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0A5bNeSMVq2AorpWkgvBP65MpQydt+QWfcfY+lfVmKY=; b=mEPZkyCZUGajcDhti5UJB15H6HfVI2HWeUKokhtR13P7ZF0oL88+vcMZsOzh8doaCt 2yFvxAqapgA64Pr3MqGfHrubBum8gSu2d+ahW1QDSuhV2Zkvzysq5VDQ3sAZPc/0CTKA yZAv7MUBQUAyve5XmxXcilduZ/4Q1GMwR99VkR+3ACU3GyPG2Xv4NzmjiypZE2tjEMOh /J9tKzoJLIjAjjdVGaWS66Mfi5+Dw6LEX2ILiwmuwcbFdWBoEYDbsE9mX90XYZgRAtd7 l9LnAGNdAyrVE9SGp8t608y1m9OONGE7cy6Ne/zfuK5iNGPR9OvM5ck3adGvUVpXhfb1 gPuw== X-Gm-Message-State: AFeK/H3q9lTf27YaWZ45cr80rdOEGwiI9IHCzVzdSPsKtQvXwHENSReixRqoN23V/3Ow6M68ltGcQKV5kBi/nYAn X-Received: by 10.36.14.77 with SMTP id 74mr4944980ite.115.1490133879914; Tue, 21 Mar 2017 15:04:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Tue, 21 Mar 2017 15:04:19 -0700 (PDT) In-Reply-To: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> From: "Charles 'Buck' Krasic" Date: Tue, 21 Mar 2017 15:04:19 -0700 Message-ID: Subject: Re: Core drafts -02 out To: Mike Bishop Cc: Stefan Eissing , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1143d756954dbd054b44d48c Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 22:04:44 -0000 --001a1143d756954dbd054b44d48c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Folks. I've put together a first attempt at my QPACK proposal: draft-krasic-quic-hpack-00.html draft-krasic-quic-hpack-00.txt Apologies in advance, this is my first attempt at an IETF draft. On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop wrote: > Thanks for the feedback! > > Yes, you've run straight into the big quandary with HPACK. I don't think > anyone expects that we will ship this way; I have a proposal in > https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack for an > HPACK-replacement that would solve many of these. Buck Krasic has a > proposal which he has sketched in e-mail but not submitted as a draft. T= he > main point of the sequence number was to get us off the "everything on > stream 3" model and let us sort out the problems of HPACK later. #228 > tracks fixing HPACK, in whatever form that takes. > > We could solve it in the same way that we did PRIORITY, by adding an > "affected stream number" field and moving the HEADERS/PUSH_PROMISE frames > to Stream 3 as well. However, that is just as blocking as the current > approach, so not really an improvement. Worse, the reason we can tolerat= e > large header frames is because they occur on their own streams and don't > block arrival of data from other streams. If all headers occur on a sing= le > stream, that's not true -- you *are* blocking muxing of other streams aga= in. > > I like the comparison to concurrent edits. We've discussed having rollin= g > deltas in various mechanisms; the problem is that it requires reaching in= to > the transport for ACK state to figure out when you can discard old deltas > for good on the receiver side. Buck's proposal is similar, essentially > requiring the receiver to echo back the point up to which it has received > all frames, and the sender shouldn't reference state that the receiver > hasn't fully assimilated yet. It feels like adding application-level ACK= s > to me, which I'd like to avoid. > > HPACK is also one of the reasons for the two-stream-per-request approach. > There are two reasons for this -- one is that HPACK frames (in the curren= t > design) can't be lost when a stream is RST, so the draft forbids resettin= g > control streams. Since we still need to be able to RST requests, we add > the semantic that killing the data stream implies the same thing about th= e > control stream. It's messy, and hopefully we can remove that once HPACK = is > fixed. The second, as you guessed, is not dealing with DATA frames. #24= 5 > notes that, if we fix HPACK, we could go back to a single stream per > request; proponents of both "keep framing out of the way" and "fewer > streams is easier to manage" have weighed in there. Please add your voic= e. > > As to buffering, it's actually easy enough -- just don't read from data > streams until you've seen the headers. Sure, the sender will fill up the= ir > flow control window on that stream -- and then they'll stop and send you > QUIC BLOCKED frames, until you start reading the body and generating > WINDOW_UPDATE frames. One of the biggest arguments for two streams in my > mind is making sure that a request blocked in this way doesn't impede the > flow of control frames on that stream -- for example, should we > successfully get certificate auth frames added, a certificate request. > I've had two customers this week telling me it's a bug in our server code > that their TLS reneg gets stuck in TCP buffers behind a giant request bod= y, > because the server won't read an unauthenticated body and the client won'= t > hold off sending the body until authentication succeeds. I'd like to see > blocks like that become less possible in QUIC, at least. > > Yes, making SETTINGS immutable reduces the flexibility. The opinion at > the interim was that we could live without it, as we know of exactly one > implementation of one extension that does mid-stream setting changes, and= I > own it. =F0=9F=98=8A If there's a compelling use case for changing sett= ings > mid-stream we weren't aware of, that's new information that could justify > the complexity. (But note that with 0-RTT connection setup, it would be > nearly as cheap to open a new connection with the new setting and > transition your traffic to it.) > > Negotiation still works, since each side would simply advertise that they > support an extension or not, and consider the extension to be active once > you've seen the other side's SETTINGS frame. See > https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5.3 for > the complexity this allowed us to remove. An extension could add to the > list easily -- if you support extension X, you should also remember the > value for setting X_VAL. Clients that don't use the extension don't care= . > An extension that needed some more complex negotiation would have to use = an > extension-specific frame, it's true, but we haven't so far seen an > extension do that. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing > Sent: Wednesday, March 15, 2017 6:22 AM > To: Martin Thomson ; IETF QUIC WG > > Subject: Re: Core drafts -02 out > > > > Am 14.03.2017 um 00:57 schrieb Martin Thomson >: > > > > The editors have submitted -02 versions of the base set of QUIC drafts. > [...] > > https://tools.ietf.org/html/draft-ietf-quic-http-02 > > Thanks, Martin! I assume that was announced to get feedback from the > lurkers here. ;-) > > I'll give this a try. All mistakes and misunderstandings are mine alone. > > ------------------------------------------------------------ > ----------------------------- > > Very well written spec. Easy to understand for someone having read rfc > 7540 a bit. > > I have some comments to the proposed HTTP mapping approach. Where the wg > has already discussed and exhausted alternatives, please excuse my > ignorance and ignore my comments. I had not the time to follow all > discussions ongoing on this topic. Feel free to cherry-pick what seems > helpful. > > > > 4. Stream Mapping and Usage > > +1 to directly using quic stream ids instead of virtual h2 stream > +identifier > > However, using 2 quic streams for a single request/response does not sit > well with me. I assume that stems from the wish to get rid of DATA frames= . > Which sounds nice, but is it worth it? By doubling the # of streams for a > client, how much overhead does that introduce (I speak of a server holdin= g > >10k quic "connections")? > > Also, the server needs to buffer data on quic streams 7, 11, 15, etc. > because HEADERs might arrive some time in the future on streams 5, 9, 13, > etc. or not. There is no way to route this data somewhere, because the me= ta > information is still missing. > > And there is still Holb on: > > > 4.2.1. Header Compression > > ... > > DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- > > invariant? How much do we need to retain compatibility with > > HTTP/2's HPACK? > > Using a counter in HEADERS is a crutch: > - it is a highly specific solution to a common problem in http/quic: > synchronicity in connection level state changes. SETTINGS (see below) has > the same problem, as does have PRIORITY in HEADERS. It seems that > performance wise, all HEADERS could as well be sent on stream 3. > > Now, solving Hol blocking for HEADERS would be a fine achievement. > > > 5. HTTP Framing Layer > > Frames are used only on the connection (stream 3) and message > > (streams 5, 9, etc.) control streams. > > And streams 4, 8, 12, etc. I assume. > > > 5.2.3. SETTINGS > > ... > > SETTINGS frames always apply to a connection, never a single stream. > > A SETTINGS frame MUST be sent as the first frame of the connection > > control stream (see Section 4) by each peer, and MUST NOT be sent > > subsequently or on any other stream. If an endpoint receives an > > SETTINGS frame on a different stream, the endpoint MUST respond with > > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an > > endpoint receives a second SETTINGS frame, the endpoint MUST respond > > with a connection error of type HTTP_MULTIPLE_SETTINGS. > > What about HPACK state? The connection state change problem again visible= . > > This is a severe restriction on extensions mechanisms that want to affect > a connection. Because if the http/quic does not solve this problem, how a= re > they expected to do it? They either announce themselves on the first > SETTINGS or remain silent forever, it seems. How would an extension > handshake work then? Own stream 3 handshake frames? > > > 5.2.3.3. Usage in 0-RTT > > What about HPACK state? Does it need to be kept or is it reset? > > > HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push > > content which the client has cached. > > ... > > HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the > > requested data. > > Nitpick: seems redundant. The first could be replaced by the second. > Stream number will suffice. > > ---------------------------------------------------------- > > Taking two steps back: > > I think the main difficulty comes from the lack of a "hq connection state= " > concept and how changes to that state can be managed. Evidence: > - The 0-RTT mentions certain SETTINGS that need to be remembered by a > client. How would an extension add to this? Will every extension have to > come up with its own solution? > - The HEADERs sequence number is a highly specific fix for the missing > state change > - The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 > mechanism > > If hq defines stream 3 as the place where connection state changes happen > *AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and serv= er > can have shareable concept of the connection state. > > > I am no HPACK expert. The basic problem looks like concurrent editing > against a repository. > Both client and server start with connection state zero (CS-0) and the > predefined HPACK dictionary (HP-0). After SETTINGS exchange, client is in > CS-1 and server is in CS-2 for its side. Let's call the CS-1 HPACK state > HP-1. > > Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). > The HEADERS carries the connection state number it is based on (CS-1). > Client sends new HEADERS on stream 9, also based on CS-1. Client keeps th= at > delta around (HP-1.9). > > Client then decides to announce a new connection state (CS-3) by sending > how it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The > description allows the server to update its HP-1 to HP-3 as well. > > Response HEADERS are also based on a server connection state, explicitly, > so the client knows which HP-X to use when decoding them. At some time, t= he > server sends an announcment of CS-4 with HPACK data on stream 3 back to t= he > client. > > For a 0-RTT, client and server could exchange the connection state id in > the initial SETTINGS, to make sure they have at least the same name > remembered as the other side. Client: "I was in CS-19 and you were in > CS-8." Server: "Yep." > > By implicitly adding all SETTINGS changes to connection states, the > problem is also solved for extensions. > > If one side receives HEADERS with an unknown connection state: > - if the state id is greater than any known one: set a stream timeout and > wait for changes on stream 3 to arrive > - state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE > > New SETTINGS value: MAX_CONN_STATE number of maximum connection state the > client/server is willing to keep, exchanged initially. Announcing a new > connection state allows the other side to drop the lowest one, if > MAX_CONN_STATE are used. > > To get optimal HPACK size compression, every HEADERs would also announce = a > new connections state. To have less potential HOLB, connection states do > not change during request bursts. > > Something like that. > > -Stefan > > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1143d756954dbd054b44d48c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks.

I've put together a first= attempt at my QPACK proposal:

draft-krasic-quic-hpack-00.html
Apologies in advance, this is my first attempt at an IETF draf= t.


On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop <Mich= ael.Bishop@microsoft.com> wrote:
Thanks for the feedback!

Yes, you've run straight into the big quandary with HPACK.=C2=A0 I don&= #39;t think anyone expects that we will ship this way; I have a proposal in= https://tools.ietf.org/html/draft-= bishop-quic-http-and-qpack for an HPACK-replacement that would sol= ve many of these.=C2=A0 Buck Krasic has a proposal which he has sketched in= e-mail but not submitted as a draft.=C2=A0 The main point of the sequence = number was to get us off the "everything on stream 3" model and l= et us sort out the problems of HPACK later.=C2=A0 #228 tracks fixing HPACK,= in whatever form that takes.

We could solve it in the same way that we did PRIORITY, by adding an "= affected stream number" field and moving the HEADERS/PUSH_PROMISE fram= es to Stream 3 as well.=C2=A0 However, that is just as blocking as the curr= ent approach, so not really an improvement.=C2=A0 Worse, the reason we can = tolerate large header frames is because they occur on their own streams and= don't block arrival of data from other streams.=C2=A0 If all headers o= ccur on a single stream, that's not true -- you *are* blocking muxing o= f other streams again.

I like the comparison to concurrent edits.=C2=A0 We've discussed having= rolling deltas in various mechanisms; the problem is that it requires reac= hing into the transport for ACK state to figure out when you can discard ol= d deltas for good on the receiver side.=C2=A0 Buck's proposal is simila= r, essentially requiring the receiver to echo back the point up to which it= has received all frames, and the sender shouldn't reference state that= the receiver hasn't fully assimilated yet.=C2=A0 It feels like adding = application-level ACKs to me, which I'd like to avoid.

HPACK is also one of the reasons for the two-stream-per-request approach.= =C2=A0 There are two reasons for this -- one is that HPACK frames (in the c= urrent design) can't be lost when a stream is RST, so the draft forbids= resetting control streams.=C2=A0 Since we still need to be able to RST req= uests, we add the semantic that killing the data stream implies the same th= ing about the control stream.=C2=A0 It's messy, and hopefully we can re= move that once HPACK is fixed.=C2=A0 The second, as you guessed, is not dea= ling with DATA frames.=C2=A0 #245 notes that, if we fix HPACK, we could go = back to a single stream per request; proponents of both "keep framing = out of the way" and "fewer streams is easier to manage" have= weighed in there.=C2=A0 Please add your voice.

As to buffering, it's actually easy enough -- just don't read from = data streams until you've seen the headers.=C2=A0 Sure, the sender will= fill up their flow control window on that stream -- and then they'll s= top and send you QUIC BLOCKED frames, until you start reading the body and = generating WINDOW_UPDATE frames.=C2=A0 One of the biggest arguments for two= streams in my mind is making sure that a request blocked in this way doesn= 't impede the flow of control frames on that stream -- for example, sho= uld we successfully get certificate auth frames added, a certificate reques= t.=C2=A0 I've had two customers this week telling me it's a bug in = our server code that their TLS reneg gets stuck in TCP buffers behind a gia= nt request body, because the server won't read an unauthenticated body = and the client won't hold off sending the body until authentication suc= ceeds.=C2=A0 I'd like to see blocks like that become less possible in Q= UIC, at least.

Yes, making SETTINGS immutable reduces the flexibility.=C2=A0 The opinion a= t the interim was that we could live without it, as we know of exactly one = implementation of one extension that does mid-stream setting changes, and I= own it.=C2=A0 =F0=9F=98=8A=C2=A0 If there's a compelling use case for = changing settings mid-stream we weren't aware of, that's new inform= ation that could justify the complexity.=C2=A0 (But note that with 0-RTT co= nnection setup, it would be nearly as cheap to open a new connection with t= he new setting and transition your traffic to it.)

Negotiation still works, since each side would simply advertise that they s= upport an extension or not, and consider the extension to be active once yo= u've seen the other side's SETTINGS frame.=C2=A0 See https://tools.ietf.org/html/draft-ietf-qui= c-http-01#section-5.2.5.3 for the complexity this allowed us to re= move.=C2=A0 An extension could add to the list easily -- if you support ext= ension X, you should also remember the value for setting X_VAL.=C2=A0 Clien= ts that don't use the extension don't care.=C2=A0 An extension that= needed some more complex negotiation would have to use an extension-specif= ic frame, it's true, but we haven't so far seen an extension do tha= t.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Stefan Eissing
Sent: Wednesday, March 15, 2017 6:22 AM
To: Martin Thomson <martin.t= homson@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Core drafts -02 out


> Am 14.03.2017 um 00:57 schrieb Martin Thomson <martin.thomson@gmail.com>:
>
> The editors have submitted -02 versions of the base set of QUIC drafts= .
[...]
> https://tools.ietf.org/html/draft-ietf-= quic-http-02

Thanks, Martin! I assume that was announced to get feedback from the lurker= s here. ;-)

I'll give this a try. All mistakes and misunderstandings are mine alone= .

-----------------------------------------------------------------= ------------------------

Very well written spec. Easy to understand for someone having read rfc 7540= a bit.

I have some comments to the proposed HTTP mapping approach. Where the wg ha= s already discussed and exhausted alternatives, please excuse my ignorance = and ignore my comments. I had not the time to follow all discussions ongoin= g on this topic. Feel free to cherry-pick what seems helpful.


> 4.=C2=A0 Stream Mapping and Usage

+1 to directly using quic stream ids instead of virtual h2 stream
+identifier

However, using 2 quic streams for a single request/response does not sit we= ll with me. I assume that stems from the wish to get rid of DATA frames. Wh= ich sounds nice, but is it worth it? By doubling the # of streams for a cli= ent, how much overhead does that introduce (I speak of a server holding >= ;10k quic "connections")?

Also, the server needs to buffer data on quic streams 7, 11, 15, etc. becau= se HEADERs might arrive some time in the future on streams 5, 9, 13, etc. o= r not. There is no way to route this data somewhere, because the meta infor= mation is still missing.

And there is still Holb on:

> 4.2.1.=C2=A0 Header Compression
> ...
> DISCUSS:=C2=A0 Keep HPACK with HOLB?=C2=A0 Redesign HPACK to be order-=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0invariant?=C2=A0 How much do we need to reta= in compatibility with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/2's HPACK?

Using a counter in HEADERS is a crutch:
- it is a highly specific solution to a common problem in http/quic: synchr= onicity in connection level state changes. SETTINGS (see below) has the sam= e problem, as does have PRIORITY in HEADERS. It seems that performance wise= , all HEADERS could as well be sent on stream 3.

Now, solving Hol blocking for HEADERS would be a fine achievement.

> 5.=C2=A0 HTTP Framing Layer
> Frames are used only on the connection (stream 3) and message
>=C2=A0 =C2=A0 (streams 5, 9, etc.) control streams.

And streams 4, 8, 12, etc. I assume.

> 5.2.3.=C2=A0 SETTINGS
> ...
> SETTINGS frames always apply to a connection, never a single stream. >=C2=A0 A SETTINGS frame MUST be sent as the first frame of the connecti= on
> control stream (see Section 4) by each peer, and MUST NOT be sent
> subsequently or on any other stream.=C2=A0 If an endpoint receives an<= br> > SETTINGS frame on a different stream, the endpoint MUST respond with > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM.=C2=A0 If an<= br> > endpoint receives a second SETTINGS frame, the endpoint MUST respond > with a connection error of type HTTP_MULTIPLE_SETTINGS.

What about HPACK state? The connection state change problem again visible.<= br>
This is a severe restriction on extensions mechanisms that want to affect a= connection. Because if the http/quic does not solve this problem, how are = they expected to do it? They either announce themselves on the first SETTIN= GS or remain silent forever, it seems. How would an extension handshake wor= k then? Own stream 3 handshake frames?

> 5.2.3.3.=C2=A0 Usage in 0-RTT

What about HPACK state? Does it need to be kept or is it reset?

> HTTP_PUSH_ALREADY_IN_CACHE (0x03):=C2=A0 The server has attempted to p= ush
>=C2=A0 =C2=A0 =C2=A0 content which the client has cached.
> ...
> HTTP_REQUEST_CANCELLED (0x04):=C2=A0 The client no longer needs the >=C2=A0 =C2=A0 =C2=A0requested data.

Nitpick: seems redundant. The first could be replaced by the second. Stream= number will suffice.

----------------------------------------------------------

Taking two steps back:

I think the main difficulty comes from the lack of a "hq connection st= ate" concept and how changes to that state can be managed. Evidence: - The 0-RTT mentions certain SETTINGS that need to be remembered by a clien= t. How would an extension add to this? Will every extension have to come up= with its own solution?
- The HEADERs sequence number is a highly specific fix for the missing stat= e change
- The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 m= echanism

If hq defines stream 3 as the place where connection state changes happen *= AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and server = can have shareable concept of the connection state.


I am no HPACK expert. The basic problem looks like concurrent editing again= st a repository.
Both client and server start with connection state zero (CS-0) and the pred= efined HPACK dictionary (HP-0). After SETTINGS exchange, client is in CS-1 = and server is in CS-2 for its side. Let's call the=C2=A0 CS-1 HPACK sta= te HP-1.

Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). Th= e HEADERS carries the connection state number it is based on (CS-1). Client= sends new HEADERS on stream 9, also based on CS-1. Client keeps that delta= around (HP-1.9).

Client then decides to announce a new connection state (CS-3) by sending ho= w it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The descrip= tion allows the server to update its HP-1 to HP-3 as well.

Response HEADERS are also based on a server connection state, explicitly, s= o the client knows which HP-X to use when decoding them. At some time, the = server sends an announcment of CS-4 with HPACK data on stream 3 back to the= client.

For a 0-RTT, client and server could exchange the connection state id in th= e initial SETTINGS, to make sure they have at least the same name remembere= d as the other side. Client: "I was in CS-19 and you were in CS-8.&quo= t; Server: "Yep."

By implicitly adding all SETTINGS changes to connection states, the problem= is also solved for extensions.

If one side receives HEADERS with an unknown connection state:
- if the state id is greater than any known one: set a stream timeout and w= ait for changes on stream 3 to arrive
- state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE
New SETTINGS value: MAX_CONN_STATE number of maximum connection state the c= lient/server is willing to keep, exchanged initially. Announcing a new conn= ection state allows the other side to drop the lowest one, if MAX_CONN_STAT= E are used.

To get optimal HPACK size compression, every HEADERs would also announce a = new connections state. To have less potential HOLB, connection states do no= t change during request bursts.

Something like that.

-Stefan





--
=
= Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

--001a1143d756954dbd054b44d48c-- From nobody Tue Mar 21 15:14:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9F12F253 for ; Tue, 21 Mar 2017 15:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 eem3oJmWS5OE for ; Tue, 21 Mar 2017 15:14:53 -0700 (PDT) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C950126C83 for ; Tue, 21 Mar 2017 15:14:52 -0700 (PDT) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v2LMEoCx026084; Tue, 21 Mar 2017 22:14:50 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0319.002; Tue, 21 Mar 2017 22:14:50 +0000 From: Lucas Pardue To: "Charles 'Buck' Krasic" CC: IETF QUIC WG Subject: RE: Core drafts -02 out Thread-Topic: Core drafts -02 out Thread-Index: AQHSnFW3fEMDfc2nQEqGhaTBBGBtIqGV5bGAgABHOwCACbiVgIAAAjpy Date: Tue, 21 Mar 2017 22:14:49 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A376F6784@bgb01xud1012> References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4179-8.100.1062-22956.002 x-tm-as-result: No--20.055200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A376F6784bgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 22:14:56 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A376F6784bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnVjaywNCg0KVGhhbmtzIGZvciB5b3VyIHByb3Bvc2FsLCBJJ2xsIGhhdmUgYSBwcm9wZXIg cmVhZCBvbiB0aGUgcGxhbmUgb3ZlciB0byBDaGljYWdvIQ0KDQpUaGUgSFRNTCB2ZXJzaW9uIGxp bmsgd2FzIGJyb2tlbiBmb3IgbWUsIGJ1dCB0aGlzIG9uZSB3b3JrcyAtIGh0dHBzOi8va3Jhc2lj LmdpdGh1Yi5pby9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay9kcmFmdC1rcmFzaWMtcXVpYy1ocGFj ay0wMC5odG1sLg0KDQpSZWdhcmRzDQpMdWNhcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IFFVSUMgW3F1aWMtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmIG9mIENo YXJsZXMgJ0J1Y2snIEtyYXNpYyBbY2tyYXNpY0Bnb29nbGUuY29tXQ0KU2VudDogMjEgTWFyY2gg MjAxNyAyMjowNA0KVG86IE1pa2UgQmlzaG9wDQpDYzogU3RlZmFuIEVpc3Npbmc7IElFVEYgUVVJ QyBXRzsgTWFydGluIFRob21zb24NClN1YmplY3Q6IFJlOiBDb3JlIGRyYWZ0cyAtMDIgb3V0DQoN CkhpIEZvbGtzLg0KDQpJJ3ZlIHB1dCB0b2dldGhlciBhIGZpcnN0IGF0dGVtcHQgYXQgbXkgUVBB Q0sgcHJvcG9zYWw6DQoNCmRyYWZ0LWtyYXNpYy1xdWljLWhwYWNrLTAwLmh0bWw8aHR0cDovL2Ry YWZ0LWtyYXNpYy1xdWljLWhwYWNrLTAwLmh0bWw+DQpkcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0w MC50eHQ8aHR0cHM6Ly9rcmFzaWMuZ2l0aHViLmlvL2RyYWZ0LWtyYXNpYy1xdWljLWhwYWNrL2Ry YWZ0LWtyYXNpYy1xdWljLWhwYWNrLTAwLnR4dD4NCg0KQXBvbG9naWVzIGluIGFkdmFuY2UsIHRo aXMgaXMgbXkgZmlyc3QgYXR0ZW1wdCBhdCBhbiBJRVRGIGRyYWZ0Lg0KDQoNCk9uIFdlZCwgTWFy IDE1LCAyMDE3IGF0IDEwOjM3IEFNLCBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9z b2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhh bmtzIGZvciB0aGUgZmVlZGJhY2shDQoNClllcywgeW91J3ZlIHJ1biBzdHJhaWdodCBpbnRvIHRo ZSBiaWcgcXVhbmRhcnkgd2l0aCBIUEFDSy4gIEkgZG9uJ3QgdGhpbmsgYW55b25lIGV4cGVjdHMg dGhhdCB3ZSB3aWxsIHNoaXAgdGhpcyB3YXk7IEkgaGF2ZSBhIHByb3Bvc2FsIGluIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjayBmb3Ig YW4gSFBBQ0stcmVwbGFjZW1lbnQgdGhhdCB3b3VsZCBzb2x2ZSBtYW55IG9mIHRoZXNlLiAgQnVj ayBLcmFzaWMgaGFzIGEgcHJvcG9zYWwgd2hpY2ggaGUgaGFzIHNrZXRjaGVkIGluIGUtbWFpbCBi dXQgbm90IHN1Ym1pdHRlZCBhcyBhIGRyYWZ0LiAgVGhlIG1haW4gcG9pbnQgb2YgdGhlIHNlcXVl bmNlIG51bWJlciB3YXMgdG8gZ2V0IHVzIG9mZiB0aGUgImV2ZXJ5dGhpbmcgb24gc3RyZWFtIDMi IG1vZGVsIGFuZCBsZXQgdXMgc29ydCBvdXQgdGhlIHByb2JsZW1zIG9mIEhQQUNLIGxhdGVyLiAg IzIyOCB0cmFja3MgZml4aW5nIEhQQUNLLCBpbiB3aGF0ZXZlciBmb3JtIHRoYXQgdGFrZXMuDQoN CldlIGNvdWxkIHNvbHZlIGl0IGluIHRoZSBzYW1lIHdheSB0aGF0IHdlIGRpZCBQUklPUklUWSwg YnkgYWRkaW5nIGFuICJhZmZlY3RlZCBzdHJlYW0gbnVtYmVyIiBmaWVsZCBhbmQgbW92aW5nIHRo ZSBIRUFERVJTL1BVU0hfUFJPTUlTRSBmcmFtZXMgdG8gU3RyZWFtIDMgYXMgd2VsbC4gIEhvd2V2 ZXIsIHRoYXQgaXMganVzdCBhcyBibG9ja2luZyBhcyB0aGUgY3VycmVudCBhcHByb2FjaCwgc28g bm90IHJlYWxseSBhbiBpbXByb3ZlbWVudC4gIFdvcnNlLCB0aGUgcmVhc29uIHdlIGNhbiB0b2xl cmF0ZSBsYXJnZSBoZWFkZXIgZnJhbWVzIGlzIGJlY2F1c2UgdGhleSBvY2N1ciBvbiB0aGVpciBv d24gc3RyZWFtcyBhbmQgZG9uJ3QgYmxvY2sgYXJyaXZhbCBvZiBkYXRhIGZyb20gb3RoZXIgc3Ry ZWFtcy4gIElmIGFsbCBoZWFkZXJzIG9jY3VyIG9uIGEgc2luZ2xlIHN0cmVhbSwgdGhhdCdzIG5v dCB0cnVlIC0tIHlvdSAqYXJlKiBibG9ja2luZyBtdXhpbmcgb2Ygb3RoZXIgc3RyZWFtcyBhZ2Fp bi4NCg0KSSBsaWtlIHRoZSBjb21wYXJpc29uIHRvIGNvbmN1cnJlbnQgZWRpdHMuICBXZSd2ZSBk aXNjdXNzZWQgaGF2aW5nIHJvbGxpbmcgZGVsdGFzIGluIHZhcmlvdXMgbWVjaGFuaXNtczsgdGhl IHByb2JsZW0gaXMgdGhhdCBpdCByZXF1aXJlcyByZWFjaGluZyBpbnRvIHRoZSB0cmFuc3BvcnQg Zm9yIEFDSyBzdGF0ZSB0byBmaWd1cmUgb3V0IHdoZW4geW91IGNhbiBkaXNjYXJkIG9sZCBkZWx0 YXMgZm9yIGdvb2Qgb24gdGhlIHJlY2VpdmVyIHNpZGUuICBCdWNrJ3MgcHJvcG9zYWwgaXMgc2lt aWxhciwgZXNzZW50aWFsbHkgcmVxdWlyaW5nIHRoZSByZWNlaXZlciB0byBlY2hvIGJhY2sgdGhl IHBvaW50IHVwIHRvIHdoaWNoIGl0IGhhcyByZWNlaXZlZCBhbGwgZnJhbWVzLCBhbmQgdGhlIHNl bmRlciBzaG91bGRuJ3QgcmVmZXJlbmNlIHN0YXRlIHRoYXQgdGhlIHJlY2VpdmVyIGhhc24ndCBm dWxseSBhc3NpbWlsYXRlZCB5ZXQuICBJdCBmZWVscyBsaWtlIGFkZGluZyBhcHBsaWNhdGlvbi1s ZXZlbCBBQ0tzIHRvIG1lLCB3aGljaCBJJ2QgbGlrZSB0byBhdm9pZC4NCg0KSFBBQ0sgaXMgYWxz byBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoZSB0d28tc3RyZWFtLXBlci1yZXF1ZXN0IGFwcHJv YWNoLiAgVGhlcmUgYXJlIHR3byByZWFzb25zIGZvciB0aGlzIC0tIG9uZSBpcyB0aGF0IEhQQUNL IGZyYW1lcyAoaW4gdGhlIGN1cnJlbnQgZGVzaWduKSBjYW4ndCBiZSBsb3N0IHdoZW4gYSBzdHJl YW0gaXMgUlNULCBzbyB0aGUgZHJhZnQgZm9yYmlkcyByZXNldHRpbmcgY29udHJvbCBzdHJlYW1z LiAgU2luY2Ugd2Ugc3RpbGwgbmVlZCB0byBiZSBhYmxlIHRvIFJTVCByZXF1ZXN0cywgd2UgYWRk IHRoZSBzZW1hbnRpYyB0aGF0IGtpbGxpbmcgdGhlIGRhdGEgc3RyZWFtIGltcGxpZXMgdGhlIHNh bWUgdGhpbmcgYWJvdXQgdGhlIGNvbnRyb2wgc3RyZWFtLiAgSXQncyBtZXNzeSwgYW5kIGhvcGVm dWxseSB3ZSBjYW4gcmVtb3ZlIHRoYXQgb25jZSBIUEFDSyBpcyBmaXhlZC4gIFRoZSBzZWNvbmQs IGFzIHlvdSBndWVzc2VkLCBpcyBub3QgZGVhbGluZyB3aXRoIERBVEEgZnJhbWVzLiAgIzI0NSBu b3RlcyB0aGF0LCBpZiB3ZSBmaXggSFBBQ0ssIHdlIGNvdWxkIGdvIGJhY2sgdG8gYSBzaW5nbGUg c3RyZWFtIHBlciByZXF1ZXN0OyBwcm9wb25lbnRzIG9mIGJvdGggImtlZXAgZnJhbWluZyBvdXQg b2YgdGhlIHdheSIgYW5kICJmZXdlciBzdHJlYW1zIGlzIGVhc2llciB0byBtYW5hZ2UiIGhhdmUg d2VpZ2hlZCBpbiB0aGVyZS4gIFBsZWFzZSBhZGQgeW91ciB2b2ljZS4NCg0KQXMgdG8gYnVmZmVy aW5nLCBpdCdzIGFjdHVhbGx5IGVhc3kgZW5vdWdoIC0tIGp1c3QgZG9uJ3QgcmVhZCBmcm9tIGRh dGEgc3RyZWFtcyB1bnRpbCB5b3UndmUgc2VlbiB0aGUgaGVhZGVycy4gIFN1cmUsIHRoZSBzZW5k ZXIgd2lsbCBmaWxsIHVwIHRoZWlyIGZsb3cgY29udHJvbCB3aW5kb3cgb24gdGhhdCBzdHJlYW0g LS0gYW5kIHRoZW4gdGhleSdsbCBzdG9wIGFuZCBzZW5kIHlvdSBRVUlDIEJMT0NLRUQgZnJhbWVz LCB1bnRpbCB5b3Ugc3RhcnQgcmVhZGluZyB0aGUgYm9keSBhbmQgZ2VuZXJhdGluZyBXSU5ET1df VVBEQVRFIGZyYW1lcy4gIE9uZSBvZiB0aGUgYmlnZ2VzdCBhcmd1bWVudHMgZm9yIHR3byBzdHJl YW1zIGluIG15IG1pbmQgaXMgbWFraW5nIHN1cmUgdGhhdCBhIHJlcXVlc3QgYmxvY2tlZCBpbiB0 aGlzIHdheSBkb2Vzbid0IGltcGVkZSB0aGUgZmxvdyBvZiBjb250cm9sIGZyYW1lcyBvbiB0aGF0 IHN0cmVhbSAtLSBmb3IgZXhhbXBsZSwgc2hvdWxkIHdlIHN1Y2Nlc3NmdWxseSBnZXQgY2VydGlm aWNhdGUgYXV0aCBmcmFtZXMgYWRkZWQsIGEgY2VydGlmaWNhdGUgcmVxdWVzdC4gIEkndmUgaGFk IHR3byBjdXN0b21lcnMgdGhpcyB3ZWVrIHRlbGxpbmcgbWUgaXQncyBhIGJ1ZyBpbiBvdXIgc2Vy dmVyIGNvZGUgdGhhdCB0aGVpciBUTFMgcmVuZWcgZ2V0cyBzdHVjayBpbiBUQ1AgYnVmZmVycyBi ZWhpbmQgYSBnaWFudCByZXF1ZXN0IGJvZHksIGJlY2F1c2UgdGhlIHNlcnZlciB3b24ndCByZWFk IGFuIHVuYXV0aGVudGljYXRlZCBib2R5IGFuZCB0aGUgY2xpZW50IHdvbid0IGhvbGQgb2ZmIHNl bmRpbmcgdGhlIGJvZHkgdW50aWwgYXV0aGVudGljYXRpb24gc3VjY2VlZHMuICBJJ2QgbGlrZSB0 byBzZWUgYmxvY2tzIGxpa2UgdGhhdCBiZWNvbWUgbGVzcyBwb3NzaWJsZSBpbiBRVUlDLCBhdCBs ZWFzdC4NCg0KWWVzLCBtYWtpbmcgU0VUVElOR1MgaW1tdXRhYmxlIHJlZHVjZXMgdGhlIGZsZXhp YmlsaXR5LiAgVGhlIG9waW5pb24gYXQgdGhlIGludGVyaW0gd2FzIHRoYXQgd2UgY291bGQgbGl2 ZSB3aXRob3V0IGl0LCBhcyB3ZSBrbm93IG9mIGV4YWN0bHkgb25lIGltcGxlbWVudGF0aW9uIG9m IG9uZSBleHRlbnNpb24gdGhhdCBkb2VzIG1pZC1zdHJlYW0gc2V0dGluZyBjaGFuZ2VzLCBhbmQg SSBvd24gaXQuICDwn5iKICBJZiB0aGVyZSdzIGEgY29tcGVsbGluZyB1c2UgY2FzZSBmb3IgY2hh bmdpbmcgc2V0dGluZ3MgbWlkLXN0cmVhbSB3ZSB3ZXJlbid0IGF3YXJlIG9mLCB0aGF0J3MgbmV3 IGluZm9ybWF0aW9uIHRoYXQgY291bGQganVzdGlmeSB0aGUgY29tcGxleGl0eS4gIChCdXQgbm90 ZSB0aGF0IHdpdGggMC1SVFQgY29ubmVjdGlvbiBzZXR1cCwgaXQgd291bGQgYmUgbmVhcmx5IGFz IGNoZWFwIHRvIG9wZW4gYSBuZXcgY29ubmVjdGlvbiB3aXRoIHRoZSBuZXcgc2V0dGluZyBhbmQg dHJhbnNpdGlvbiB5b3VyIHRyYWZmaWMgdG8gaXQuKQ0KDQpOZWdvdGlhdGlvbiBzdGlsbCB3b3Jr cywgc2luY2UgZWFjaCBzaWRlIHdvdWxkIHNpbXBseSBhZHZlcnRpc2UgdGhhdCB0aGV5IHN1cHBv cnQgYW4gZXh0ZW5zaW9uIG9yIG5vdCwgYW5kIGNvbnNpZGVyIHRoZSBleHRlbnNpb24gdG8gYmUg YWN0aXZlIG9uY2UgeW91J3ZlIHNlZW4gdGhlIG90aGVyIHNpZGUncyBTRVRUSU5HUyBmcmFtZS4g IFNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAtMDEj c2VjdGlvbi01LjIuNS4zIGZvciB0aGUgY29tcGxleGl0eSB0aGlzIGFsbG93ZWQgdXMgdG8gcmVt b3ZlLiAgQW4gZXh0ZW5zaW9uIGNvdWxkIGFkZCB0byB0aGUgbGlzdCBlYXNpbHkgLS0gaWYgeW91 IHN1cHBvcnQgZXh0ZW5zaW9uIFgsIHlvdSBzaG91bGQgYWxzbyByZW1lbWJlciB0aGUgdmFsdWUg Zm9yIHNldHRpbmcgWF9WQUwuICBDbGllbnRzIHRoYXQgZG9uJ3QgdXNlIHRoZSBleHRlbnNpb24g ZG9uJ3QgY2FyZS4gIEFuIGV4dGVuc2lvbiB0aGF0IG5lZWRlZCBzb21lIG1vcmUgY29tcGxleCBu ZWdvdGlhdGlvbiB3b3VsZCBoYXZlIHRvIHVzZSBhbiBleHRlbnNpb24tc3BlY2lmaWMgZnJhbWUs IGl0J3MgdHJ1ZSwgYnV0IHdlIGhhdmVuJ3Qgc28gZmFyIHNlZW4gYW4gZXh0ZW5zaW9uIGRvIHRo YXQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh bGYgT2YgU3RlZmFuIEVpc3NpbmcNClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTUsIDIwMTcgNjoy MiBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRv Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IENvcmUgZHJhZnRzIC0wMiBvdXQN Cg0KDQo+IEFtIDE0LjAzLjIwMTcgdW0gMDA6NTcgc2NocmllYiBNYXJ0aW4gVGhvbXNvbiA8bWFy dGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PjoN Cj4NCj4gVGhlIGVkaXRvcnMgaGF2ZSBzdWJtaXR0ZWQgLTAyIHZlcnNpb25zIG9mIHRoZSBiYXNl IHNldCBvZiBRVUlDIGRyYWZ0cy4NClsuLi5dDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0wMg0KDQpUaGFua3MsIE1hcnRpbiEgSSBhc3N1bWUgdGhh dCB3YXMgYW5ub3VuY2VkIHRvIGdldCBmZWVkYmFjayBmcm9tIHRoZSBsdXJrZXJzIGhlcmUuIDst KQ0KDQpJJ2xsIGdpdmUgdGhpcyBhIHRyeS4gQWxsIG1pc3Rha2VzIGFuZCBtaXN1bmRlcnN0YW5k aW5ncyBhcmUgbWluZSBhbG9uZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KVmVyeSB3ZWxsIHdyaXR0ZW4gc3BlYy4gRWFzeSB0byB1bmRlcnN0YW5kIGZvciBzb21lb25l IGhhdmluZyByZWFkIHJmYyA3NTQwIGEgYml0Lg0KDQpJIGhhdmUgc29tZSBjb21tZW50cyB0byB0 aGUgcHJvcG9zZWQgSFRUUCBtYXBwaW5nIGFwcHJvYWNoLiBXaGVyZSB0aGUgd2cgaGFzIGFscmVh ZHkgZGlzY3Vzc2VkIGFuZCBleGhhdXN0ZWQgYWx0ZXJuYXRpdmVzLCBwbGVhc2UgZXhjdXNlIG15 IGlnbm9yYW5jZSBhbmQgaWdub3JlIG15IGNvbW1lbnRzLiBJIGhhZCBub3QgdGhlIHRpbWUgdG8g Zm9sbG93IGFsbCBkaXNjdXNzaW9ucyBvbmdvaW5nIG9uIHRoaXMgdG9waWMuIEZlZWwgZnJlZSB0 byBjaGVycnktcGljayB3aGF0IHNlZW1zIGhlbHBmdWwuDQoNCg0KPiA0LiAgU3RyZWFtIE1hcHBp bmcgYW5kIFVzYWdlDQoNCisxIHRvIGRpcmVjdGx5IHVzaW5nIHF1aWMgc3RyZWFtIGlkcyBpbnN0 ZWFkIG9mIHZpcnR1YWwgaDIgc3RyZWFtDQoraWRlbnRpZmllcg0KDQpIb3dldmVyLCB1c2luZyAy IHF1aWMgc3RyZWFtcyBmb3IgYSBzaW5nbGUgcmVxdWVzdC9yZXNwb25zZSBkb2VzIG5vdCBzaXQg d2VsbCB3aXRoIG1lLiBJIGFzc3VtZSB0aGF0IHN0ZW1zIGZyb20gdGhlIHdpc2ggdG8gZ2V0IHJp ZCBvZiBEQVRBIGZyYW1lcy4gV2hpY2ggc291bmRzIG5pY2UsIGJ1dCBpcyBpdCB3b3J0aCBpdD8g QnkgZG91YmxpbmcgdGhlICMgb2Ygc3RyZWFtcyBmb3IgYSBjbGllbnQsIGhvdyBtdWNoIG92ZXJo ZWFkIGRvZXMgdGhhdCBpbnRyb2R1Y2UgKEkgc3BlYWsgb2YgYSBzZXJ2ZXIgaG9sZGluZyA+MTBr IHF1aWMgImNvbm5lY3Rpb25zIik/DQoNCkFsc28sIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gYnVmZmVy IGRhdGEgb24gcXVpYyBzdHJlYW1zIDcsIDExLCAxNSwgZXRjLiBiZWNhdXNlIEhFQURFUnMgbWln aHQgYXJyaXZlIHNvbWUgdGltZSBpbiB0aGUgZnV0dXJlIG9uIHN0cmVhbXMgNSwgOSwgMTMsIGV0 Yy4gb3Igbm90LiBUaGVyZSBpcyBubyB3YXkgdG8gcm91dGUgdGhpcyBkYXRhIHNvbWV3aGVyZSwg YmVjYXVzZSB0aGUgbWV0YSBpbmZvcm1hdGlvbiBpcyBzdGlsbCBtaXNzaW5nLg0KDQpBbmQgdGhl cmUgaXMgc3RpbGwgSG9sYiBvbjoNCg0KPiA0LjIuMS4gIEhlYWRlciBDb21wcmVzc2lvbg0KPiAu Li4NCj4gRElTQ1VTUzogIEtlZXAgSFBBQ0sgd2l0aCBIT0xCPyAgUmVkZXNpZ24gSFBBQ0sgdG8g YmUgb3JkZXItDQo+ICAgICAgIGludmFyaWFudD8gIEhvdyBtdWNoIGRvIHdlIG5lZWQgdG8gcmV0 YWluIGNvbXBhdGliaWxpdHkgd2l0aA0KPiAgICAgICBIVFRQLzIncyBIUEFDSz8NCg0KVXNpbmcg YSBjb3VudGVyIGluIEhFQURFUlMgaXMgYSBjcnV0Y2g6DQotIGl0IGlzIGEgaGlnaGx5IHNwZWNp ZmljIHNvbHV0aW9uIHRvIGEgY29tbW9uIHByb2JsZW0gaW4gaHR0cC9xdWljOiBzeW5jaHJvbmlj aXR5IGluIGNvbm5lY3Rpb24gbGV2ZWwgc3RhdGUgY2hhbmdlcy4gU0VUVElOR1MgKHNlZSBiZWxv dykgaGFzIHRoZSBzYW1lIHByb2JsZW0sIGFzIGRvZXMgaGF2ZSBQUklPUklUWSBpbiBIRUFERVJT LiBJdCBzZWVtcyB0aGF0IHBlcmZvcm1hbmNlIHdpc2UsIGFsbCBIRUFERVJTIGNvdWxkIGFzIHdl bGwgYmUgc2VudCBvbiBzdHJlYW0gMy4NCg0KTm93LCBzb2x2aW5nIEhvbCBibG9ja2luZyBmb3Ig SEVBREVSUyB3b3VsZCBiZSBhIGZpbmUgYWNoaWV2ZW1lbnQuDQoNCj4gNS4gIEhUVFAgRnJhbWlu ZyBMYXllcg0KPiBGcmFtZXMgYXJlIHVzZWQgb25seSBvbiB0aGUgY29ubmVjdGlvbiAoc3RyZWFt IDMpIGFuZCBtZXNzYWdlDQo+ICAgIChzdHJlYW1zIDUsIDksIGV0Yy4pIGNvbnRyb2wgc3RyZWFt cy4NCg0KQW5kIHN0cmVhbXMgNCwgOCwgMTIsIGV0Yy4gSSBhc3N1bWUuDQoNCj4gNS4yLjMuICBT RVRUSU5HUw0KPiAuLi4NCj4gU0VUVElOR1MgZnJhbWVzIGFsd2F5cyBhcHBseSB0byBhIGNvbm5l Y3Rpb24sIG5ldmVyIGEgc2luZ2xlIHN0cmVhbS4NCj4gIEEgU0VUVElOR1MgZnJhbWUgTVVTVCBi ZSBzZW50IGFzIHRoZSBmaXJzdCBmcmFtZSBvZiB0aGUgY29ubmVjdGlvbg0KPiBjb250cm9sIHN0 cmVhbSAoc2VlIFNlY3Rpb24gNCkgYnkgZWFjaCBwZWVyLCBhbmQgTVVTVCBOT1QgYmUgc2VudA0K PiBzdWJzZXF1ZW50bHkgb3Igb24gYW55IG90aGVyIHN0cmVhbS4gIElmIGFuIGVuZHBvaW50IHJl Y2VpdmVzIGFuDQo+IFNFVFRJTkdTIGZyYW1lIG9uIGEgZGlmZmVyZW50IHN0cmVhbSwgdGhlIGVu ZHBvaW50IE1VU1QgcmVzcG9uZCB3aXRoDQo+IGEgY29ubmVjdGlvbiBlcnJvciBvZiB0eXBlIEhU VFBfU0VUVElOR1NfT05fV1JPTkdfU1RSRUFNLiAgSWYgYW4NCj4gZW5kcG9pbnQgcmVjZWl2ZXMg YSBzZWNvbmQgU0VUVElOR1MgZnJhbWUsIHRoZSBlbmRwb2ludCBNVVNUIHJlc3BvbmQNCj4gd2l0 aCBhIGNvbm5lY3Rpb24gZXJyb3Igb2YgdHlwZSBIVFRQX01VTFRJUExFX1NFVFRJTkdTLg0KDQpX aGF0IGFib3V0IEhQQUNLIHN0YXRlPyBUaGUgY29ubmVjdGlvbiBzdGF0ZSBjaGFuZ2UgcHJvYmxl bSBhZ2FpbiB2aXNpYmxlLg0KDQpUaGlzIGlzIGEgc2V2ZXJlIHJlc3RyaWN0aW9uIG9uIGV4dGVu c2lvbnMgbWVjaGFuaXNtcyB0aGF0IHdhbnQgdG8gYWZmZWN0IGEgY29ubmVjdGlvbi4gQmVjYXVz ZSBpZiB0aGUgaHR0cC9xdWljIGRvZXMgbm90IHNvbHZlIHRoaXMgcHJvYmxlbSwgaG93IGFyZSB0 aGV5IGV4cGVjdGVkIHRvIGRvIGl0PyBUaGV5IGVpdGhlciBhbm5vdW5jZSB0aGVtc2VsdmVzIG9u IHRoZSBmaXJzdCBTRVRUSU5HUyBvciByZW1haW4gc2lsZW50IGZvcmV2ZXIsIGl0IHNlZW1zLiBI b3cgd291bGQgYW4gZXh0ZW5zaW9uIGhhbmRzaGFrZSB3b3JrIHRoZW4/IE93biBzdHJlYW0gMyBo YW5kc2hha2UgZnJhbWVzPw0KDQo+IDUuMi4zLjMuICBVc2FnZSBpbiAwLVJUVA0KDQpXaGF0IGFi b3V0IEhQQUNLIHN0YXRlPyBEb2VzIGl0IG5lZWQgdG8gYmUga2VwdCBvciBpcyBpdCByZXNldD8N Cg0KPiBIVFRQX1BVU0hfQUxSRUFEWV9JTl9DQUNIRSAoMHgwMyk6ICBUaGUgc2VydmVyIGhhcyBh dHRlbXB0ZWQgdG8gcHVzaA0KPiAgICAgIGNvbnRlbnQgd2hpY2ggdGhlIGNsaWVudCBoYXMgY2Fj aGVkLg0KPiAuLi4NCj4gSFRUUF9SRVFVRVNUX0NBTkNFTExFRCAoMHgwNCk6ICBUaGUgY2xpZW50 IG5vIGxvbmdlciBuZWVkcyB0aGUNCj4gICAgIHJlcXVlc3RlZCBkYXRhLg0KDQpOaXRwaWNrOiBz ZWVtcyByZWR1bmRhbnQuIFRoZSBmaXJzdCBjb3VsZCBiZSByZXBsYWNlZCBieSB0aGUgc2Vjb25k LiBTdHJlYW0gbnVtYmVyIHdpbGwgc3VmZmljZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUYWtpbmcgdHdvIHN0ZXBzIGJh Y2s6DQoNCkkgdGhpbmsgdGhlIG1haW4gZGlmZmljdWx0eSBjb21lcyBmcm9tIHRoZSBsYWNrIG9m IGEgImhxIGNvbm5lY3Rpb24gc3RhdGUiIGNvbmNlcHQgYW5kIGhvdyBjaGFuZ2VzIHRvIHRoYXQg c3RhdGUgY2FuIGJlIG1hbmFnZWQuIEV2aWRlbmNlOg0KLSBUaGUgMC1SVFQgbWVudGlvbnMgY2Vy dGFpbiBTRVRUSU5HUyB0aGF0IG5lZWQgdG8gYmUgcmVtZW1iZXJlZCBieSBhIGNsaWVudC4gSG93 IHdvdWxkIGFuIGV4dGVuc2lvbiBhZGQgdG8gdGhpcz8gV2lsbCBldmVyeSBleHRlbnNpb24gaGF2 ZSB0byBjb21lIHVwIHdpdGggaXRzIG93biBzb2x1dGlvbj8NCi0gVGhlIEhFQURFUnMgc2VxdWVu Y2UgbnVtYmVyIGlzIGEgaGlnaGx5IHNwZWNpZmljIGZpeCBmb3IgdGhlIG1pc3Npbmcgc3RhdGUg Y2hhbmdlDQotIFRoZSBTRVRUSU5HUy1PTkNFIHJlc3RyaWN0aW9uIHNpbXBseSBhdm9pZHMgdGhl IHByb2JsZW0gYnkga2lsbGluZyBhIGgyIG1lY2hhbmlzbQ0KDQpJZiBocSBkZWZpbmVzIHN0cmVh bSAzIGFzIHRoZSBwbGFjZSB3aGVyZSBjb25uZWN0aW9uIHN0YXRlIGNoYW5nZXMgaGFwcGVuICpB TkQqIHN5bmNocm9uaXplcyBPUEVOL0NMT1NFL1JTVCBvZiBvdGhlciBzdHJlYW1zIG9uIGl0LCBj bGllbnQgYW5kIHNlcnZlciBjYW4gaGF2ZSBzaGFyZWFibGUgY29uY2VwdCBvZiB0aGUgY29ubmVj dGlvbiBzdGF0ZS4NCg0KDQpJIGFtIG5vIEhQQUNLIGV4cGVydC4gVGhlIGJhc2ljIHByb2JsZW0g bG9va3MgbGlrZSBjb25jdXJyZW50IGVkaXRpbmcgYWdhaW5zdCBhIHJlcG9zaXRvcnkuDQpCb3Ro IGNsaWVudCBhbmQgc2VydmVyIHN0YXJ0IHdpdGggY29ubmVjdGlvbiBzdGF0ZSB6ZXJvIChDUy0w KSBhbmQgdGhlIHByZWRlZmluZWQgSFBBQ0sgZGljdGlvbmFyeSAoSFAtMCkuIEFmdGVyIFNFVFRJ TkdTIGV4Y2hhbmdlLCBjbGllbnQgaXMgaW4gQ1MtMSBhbmQgc2VydmVyIGlzIGluIENTLTIgZm9y IGl0cyBzaWRlLiBMZXQncyBjYWxsIHRoZSAgQ1MtMSBIUEFDSyBzdGF0ZSBIUC0xLg0KDQpDbGll bnQgc2VuZHMgbmV3IEhFQURFUlMgb24gNSBhbmQga2VlcHMgdGhlIEhQQUNLIGRlbHRhIGFyb3Vu ZCAoSFAtMS41KS4gVGhlIEhFQURFUlMgY2FycmllcyB0aGUgY29ubmVjdGlvbiBzdGF0ZSBudW1i ZXIgaXQgaXMgYmFzZWQgb24gKENTLTEpLiBDbGllbnQgc2VuZHMgbmV3IEhFQURFUlMgb24gc3Ry ZWFtIDksIGFsc28gYmFzZWQgb24gQ1MtMS4gQ2xpZW50IGtlZXBzIHRoYXQgZGVsdGEgYXJvdW5k IChIUC0xLjkpLg0KDQpDbGllbnQgdGhlbiBkZWNpZGVzIHRvIGFubm91bmNlIGEgbmV3IGNvbm5l Y3Rpb24gc3RhdGUgKENTLTMpIGJ5IHNlbmRpbmcgaG93IGl0IGFwcGxpZWQgdGhlIGRlbHRhcyBI UC0xLjUgYW5kIEhQLTEuOSB0byBjb21lIHVwIHdpdGggSFAtMy4gVGhlIGRlc2NyaXB0aW9uIGFs bG93cyB0aGUgc2VydmVyIHRvIHVwZGF0ZSBpdHMgSFAtMSB0byBIUC0zIGFzIHdlbGwuDQoNClJl c3BvbnNlIEhFQURFUlMgYXJlIGFsc28gYmFzZWQgb24gYSBzZXJ2ZXIgY29ubmVjdGlvbiBzdGF0 ZSwgZXhwbGljaXRseSwgc28gdGhlIGNsaWVudCBrbm93cyB3aGljaCBIUC1YIHRvIHVzZSB3aGVu IGRlY29kaW5nIHRoZW0uIEF0IHNvbWUgdGltZSwgdGhlIHNlcnZlciBzZW5kcyBhbiBhbm5vdW5j bWVudCBvZiBDUy00IHdpdGggSFBBQ0sgZGF0YSBvbiBzdHJlYW0gMyBiYWNrIHRvIHRoZSBjbGll bnQuDQoNCkZvciBhIDAtUlRULCBjbGllbnQgYW5kIHNlcnZlciBjb3VsZCBleGNoYW5nZSB0aGUg Y29ubmVjdGlvbiBzdGF0ZSBpZCBpbiB0aGUgaW5pdGlhbCBTRVRUSU5HUywgdG8gbWFrZSBzdXJl IHRoZXkgaGF2ZSBhdCBsZWFzdCB0aGUgc2FtZSBuYW1lIHJlbWVtYmVyZWQgYXMgdGhlIG90aGVy IHNpZGUuIENsaWVudDogIkkgd2FzIGluIENTLTE5IGFuZCB5b3Ugd2VyZSBpbiBDUy04LiIgU2Vy dmVyOiAiWWVwLiINCg0KQnkgaW1wbGljaXRseSBhZGRpbmcgYWxsIFNFVFRJTkdTIGNoYW5nZXMg dG8gY29ubmVjdGlvbiBzdGF0ZXMsIHRoZSBwcm9ibGVtIGlzIGFsc28gc29sdmVkIGZvciBleHRl bnNpb25zLg0KDQpJZiBvbmUgc2lkZSByZWNlaXZlcyBIRUFERVJTIHdpdGggYW4gdW5rbm93biBj b25uZWN0aW9uIHN0YXRlOg0KLSBpZiB0aGUgc3RhdGUgaWQgaXMgZ3JlYXRlciB0aGFuIGFueSBr bm93biBvbmU6IHNldCBhIHN0cmVhbSB0aW1lb3V0IGFuZCB3YWl0IGZvciBjaGFuZ2VzIG9uIHN0 cmVhbSAzIHRvIGFycml2ZQ0KLSBzdGF0ZSBpZCBsZXNzIHRoYW4gbWF4KGtub3duIGNvbm4gc3Rh dGUpOiBTVFJFQU1fUlNUX1VOS05PV05fQ09OTl9TVEFURQ0KDQpOZXcgU0VUVElOR1MgdmFsdWU6 IE1BWF9DT05OX1NUQVRFIG51bWJlciBvZiBtYXhpbXVtIGNvbm5lY3Rpb24gc3RhdGUgdGhlIGNs aWVudC9zZXJ2ZXIgaXMgd2lsbGluZyB0byBrZWVwLCBleGNoYW5nZWQgaW5pdGlhbGx5LiBBbm5v dW5jaW5nIGEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgYWxsb3dzIHRoZSBvdGhlciBzaWRlIHRvIGRy b3AgdGhlIGxvd2VzdCBvbmUsIGlmIE1BWF9DT05OX1NUQVRFIGFyZSB1c2VkLg0KDQpUbyBnZXQg b3B0aW1hbCBIUEFDSyBzaXplIGNvbXByZXNzaW9uLCBldmVyeSBIRUFERVJzIHdvdWxkIGFsc28g YW5ub3VuY2UgYSBuZXcgY29ubmVjdGlvbnMgc3RhdGUuIFRvIGhhdmUgbGVzcyBwb3RlbnRpYWwg SE9MQiwgY29ubmVjdGlvbiBzdGF0ZXMgZG8gbm90IGNoYW5nZSBkdXJpbmcgcmVxdWVzdCBidXJz dHMuDQoNClNvbWV0aGluZyBsaWtlIHRoYXQuDQoNCi1TdGVmYW4NCg0KDQoNCg0KDQotLQ0KQ2hh cmxlcyAnQnVjaycgS3Jhc2ljIHwgU29mdHdhcmUgRW5naW5lZXIgfCBja3Jhc2ljQGdvb2dsZS5j b208bWFpbHRvOmNrcmFzaWNAZ29vZ2xlLmNvbT4gfCArMSAoNDA4KSA0MTItMTE0MQ0KDQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A376F6784bgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9j c3MiIGlkPSJvd2FQYXJhU3R5bGUiPjwvc3R5bGU+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KOnJv b3QgLmJiY2NvbV9zcG9uc29yOm5vdChib2R5KSwKOnJvb3QgLmJiY2NvbV9jb21wYW5pb24KeyBk aXNwbGF5OiBub25lICFpbXBvcnRhbnQ7IH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgZnBzdHls ZT0iMSIgb2NzaT0iMCI+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjtmb250LWZhbWlseTog VGFob21hO2NvbG9yOiAjMDAwMDAwO2ZvbnQtc2l6ZTogMTBwdDsiPkhpIEJ1Y2ssDQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgZm9yIHlvdXIgcHJvcG9zYWwsIEknbGwgaGF2ZSBhIHBy b3BlciByZWFkIG9uIHRoZSBwbGFuZSBvdmVyIHRvIENoaWNhZ28hPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGUgSFRNTCB2ZXJzaW9uIGxpbmsgd2FzIGJyb2tlbiBmb3IgbWUsIGJ1 dCB0aGlzIG9uZSB3b3JrcyAtIDxhIGhyZWY9Imh0dHBzOi8va3Jhc2ljLmdpdGh1Yi5pby9kcmFm dC1rcmFzaWMtcXVpYy1ocGFjay9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sIj4NCmh0 dHBzOi8va3Jhc2ljLmdpdGh1Yi5pby9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay9kcmFmdC1rcmFz aWMtcXVpYy1ocGFjay0wMC5odG1sPC9hPi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+THVjYXM8YnI+DQo8ZGl2Pg0KPGhyIHRhYmluZGV4PSItMSI+ DQo8ZGl2IGlkPSJkaXZScEYzMzA0OTMiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyBmb250LXNpemU6IDE2cHg7IGRp cmVjdGlvbjogbHRyOyI+DQo8Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiIGNvbG9yPSIjMDAw MDAwIj48Yj5Gcm9tOjwvYj4gUVVJQyBbcXVpYy1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYg b2YgQ2hhcmxlcyAnQnVjaycgS3Jhc2ljIFtja3Jhc2ljQGdvb2dsZS5jb21dPGJyPg0KPGI+U2Vu dDo8L2I+IDIxIE1hcmNoIDIwMTcgMjI6MDQ8YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wPGJy Pg0KPGI+Q2M6PC9iPiBTdGVmYW4gRWlzc2luZzsgSUVURiBRVUlDIFdHOyBNYXJ0aW4gVGhvbXNv bjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ29yZSBkcmFmdHMgLTAyIG91dDxicj4NCjwvZm9u dD48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7IGZvbnQtc2l6ZTogMTZweDsiPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyBmb250LXNpemU6IDE2cHg7Ij4NCjxkaXYgZGlyPSJsdHIi PkhpIEZvbGtzLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSd2ZSBwdXQgdG9nZXRoZXIgYSBm aXJzdCBhdHRlbXB0IGF0IG15IFFQQUNLIHByb3Bvc2FsOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL2RyYWZ0LWtyYXNpYy1xdWljLWhwYWNrLTAwLmh0bWwi IHRhcmdldD0iX2JsYW5rIj5kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sPC9hPjxicj4N CjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL2tyYXNpYy5naXRodWIuaW8vZHJhZnQta3Jh c2ljLXF1aWMtaHBhY2svZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAudHh0IiB0YXJnZXQ9Il9i bGFuayI+ZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAudHh0PC9hPjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+QXBvbG9naWVzIGluIGFkdmFuY2UsIHRoaXMgaXMgbXkgZmly c3QgYXR0ZW1wdCBhdCBhbiBJRVRGIGRyYWZ0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBXZWQsIE1hciAxNSwgMjAxNyBhdCAxMDozNyBBTSwgTWlrZSBCaXNob3AgPHNwYW4g ZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBhZGRpbmct bGVmdDoxZXgiPg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2shPGJyPg0KPGJyPg0KWWVzLCB5b3Un dmUgcnVuIHN0cmFpZ2h0IGludG8gdGhlIGJpZyBxdWFuZGFyeSB3aXRoIEhQQUNLLiZuYnNwOyBJ IGRvbid0IHRoaW5rIGFueW9uZSBleHBlY3RzIHRoYXQgd2Ugd2lsbCBzaGlwIHRoaXMgd2F5OyBJ IGhhdmUgYSBwcm9wb3NhbCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC88d2JyPmRyYWZ0LWJpc2hv cC1xdWljLWh0dHAtYW5kLTx3YnI+cXBhY2s8L2E+IGZvciBhbiBIUEFDSy1yZXBsYWNlbWVudCB0 aGF0IHdvdWxkIHNvbHZlIG1hbnkgb2YgdGhlc2UuJm5ic3A7IEJ1Y2sgS3Jhc2ljIGhhcyBhIHBy b3Bvc2FsIHdoaWNoIGhlIGhhcyBza2V0Y2hlZCBpbiBlLW1haWwgYnV0IG5vdCBzdWJtaXR0ZWQg YXMgYSBkcmFmdC4mbmJzcDsgVGhlIG1haW4gcG9pbnQgb2YgdGhlIHNlcXVlbmNlIG51bWJlcg0K IHdhcyB0byBnZXQgdXMgb2ZmIHRoZSAmcXVvdDtldmVyeXRoaW5nIG9uIHN0cmVhbSAzJnF1b3Q7 IG1vZGVsIGFuZCBsZXQgdXMgc29ydCBvdXQgdGhlIHByb2JsZW1zIG9mIEhQQUNLIGxhdGVyLiZu YnNwOyAjMjI4IHRyYWNrcyBmaXhpbmcgSFBBQ0ssIGluIHdoYXRldmVyIGZvcm0gdGhhdCB0YWtl cy48YnI+DQo8YnI+DQpXZSBjb3VsZCBzb2x2ZSBpdCBpbiB0aGUgc2FtZSB3YXkgdGhhdCB3ZSBk aWQgUFJJT1JJVFksIGJ5IGFkZGluZyBhbiAmcXVvdDthZmZlY3RlZCBzdHJlYW0gbnVtYmVyJnF1 b3Q7IGZpZWxkIGFuZCBtb3ZpbmcgdGhlIEhFQURFUlMvUFVTSF9QUk9NSVNFIGZyYW1lcyB0byBT dHJlYW0gMyBhcyB3ZWxsLiZuYnNwOyBIb3dldmVyLCB0aGF0IGlzIGp1c3QgYXMgYmxvY2tpbmcg YXMgdGhlIGN1cnJlbnQgYXBwcm9hY2gsIHNvIG5vdCByZWFsbHkgYW4gaW1wcm92ZW1lbnQuJm5i c3A7IFdvcnNlLA0KIHRoZSByZWFzb24gd2UgY2FuIHRvbGVyYXRlIGxhcmdlIGhlYWRlciBmcmFt ZXMgaXMgYmVjYXVzZSB0aGV5IG9jY3VyIG9uIHRoZWlyIG93biBzdHJlYW1zIGFuZCBkb24ndCBi bG9jayBhcnJpdmFsIG9mIGRhdGEgZnJvbSBvdGhlciBzdHJlYW1zLiZuYnNwOyBJZiBhbGwgaGVh ZGVycyBvY2N1ciBvbiBhIHNpbmdsZSBzdHJlYW0sIHRoYXQncyBub3QgdHJ1ZSAtLSB5b3UgKmFy ZSogYmxvY2tpbmcgbXV4aW5nIG9mIG90aGVyIHN0cmVhbXMgYWdhaW4uPGJyPg0KPGJyPg0KSSBs aWtlIHRoZSBjb21wYXJpc29uIHRvIGNvbmN1cnJlbnQgZWRpdHMuJm5ic3A7IFdlJ3ZlIGRpc2N1 c3NlZCBoYXZpbmcgcm9sbGluZyBkZWx0YXMgaW4gdmFyaW91cyBtZWNoYW5pc21zOyB0aGUgcHJv YmxlbSBpcyB0aGF0IGl0IHJlcXVpcmVzIHJlYWNoaW5nIGludG8gdGhlIHRyYW5zcG9ydCBmb3Ig QUNLIHN0YXRlIHRvIGZpZ3VyZSBvdXQgd2hlbiB5b3UgY2FuIGRpc2NhcmQgb2xkIGRlbHRhcyBm b3IgZ29vZCBvbiB0aGUgcmVjZWl2ZXIgc2lkZS4mbmJzcDsNCiBCdWNrJ3MgcHJvcG9zYWwgaXMg c2ltaWxhciwgZXNzZW50aWFsbHkgcmVxdWlyaW5nIHRoZSByZWNlaXZlciB0byBlY2hvIGJhY2sg dGhlIHBvaW50IHVwIHRvIHdoaWNoIGl0IGhhcyByZWNlaXZlZCBhbGwgZnJhbWVzLCBhbmQgdGhl IHNlbmRlciBzaG91bGRuJ3QgcmVmZXJlbmNlIHN0YXRlIHRoYXQgdGhlIHJlY2VpdmVyIGhhc24n dCBmdWxseSBhc3NpbWlsYXRlZCB5ZXQuJm5ic3A7IEl0IGZlZWxzIGxpa2UgYWRkaW5nIGFwcGxp Y2F0aW9uLWxldmVsIEFDS3MNCiB0byBtZSwgd2hpY2ggSSdkIGxpa2UgdG8gYXZvaWQuPGJyPg0K PGJyPg0KSFBBQ0sgaXMgYWxzbyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoZSB0d28tc3RyZWFt LXBlci1yZXF1ZXN0IGFwcHJvYWNoLiZuYnNwOyBUaGVyZSBhcmUgdHdvIHJlYXNvbnMgZm9yIHRo aXMgLS0gb25lIGlzIHRoYXQgSFBBQ0sgZnJhbWVzIChpbiB0aGUgY3VycmVudCBkZXNpZ24pIGNh bid0IGJlIGxvc3Qgd2hlbiBhIHN0cmVhbSBpcyBSU1QsIHNvIHRoZSBkcmFmdCBmb3JiaWRzIHJl c2V0dGluZyBjb250cm9sIHN0cmVhbXMuJm5ic3A7IFNpbmNlIHdlIHN0aWxsDQogbmVlZCB0byBi ZSBhYmxlIHRvIFJTVCByZXF1ZXN0cywgd2UgYWRkIHRoZSBzZW1hbnRpYyB0aGF0IGtpbGxpbmcg dGhlIGRhdGEgc3RyZWFtIGltcGxpZXMgdGhlIHNhbWUgdGhpbmcgYWJvdXQgdGhlIGNvbnRyb2wg c3RyZWFtLiZuYnNwOyBJdCdzIG1lc3N5LCBhbmQgaG9wZWZ1bGx5IHdlIGNhbiByZW1vdmUgdGhh dCBvbmNlIEhQQUNLIGlzIGZpeGVkLiZuYnNwOyBUaGUgc2Vjb25kLCBhcyB5b3UgZ3Vlc3NlZCwg aXMgbm90IGRlYWxpbmcgd2l0aCBEQVRBIGZyYW1lcy4mbmJzcDsNCiAjMjQ1IG5vdGVzIHRoYXQs IGlmIHdlIGZpeCBIUEFDSywgd2UgY291bGQgZ28gYmFjayB0byBhIHNpbmdsZSBzdHJlYW0gcGVy IHJlcXVlc3Q7IHByb3BvbmVudHMgb2YgYm90aCAmcXVvdDtrZWVwIGZyYW1pbmcgb3V0IG9mIHRo ZSB3YXkmcXVvdDsgYW5kICZxdW90O2Zld2VyIHN0cmVhbXMgaXMgZWFzaWVyIHRvIG1hbmFnZSZx dW90OyBoYXZlIHdlaWdoZWQgaW4gdGhlcmUuJm5ic3A7IFBsZWFzZSBhZGQgeW91ciB2b2ljZS48 YnI+DQo8YnI+DQpBcyB0byBidWZmZXJpbmcsIGl0J3MgYWN0dWFsbHkgZWFzeSBlbm91Z2ggLS0g anVzdCBkb24ndCByZWFkIGZyb20gZGF0YSBzdHJlYW1zIHVudGlsIHlvdSd2ZSBzZWVuIHRoZSBo ZWFkZXJzLiZuYnNwOyBTdXJlLCB0aGUgc2VuZGVyIHdpbGwgZmlsbCB1cCB0aGVpciBmbG93IGNv bnRyb2wgd2luZG93IG9uIHRoYXQgc3RyZWFtIC0tIGFuZCB0aGVuIHRoZXknbGwgc3RvcCBhbmQg c2VuZCB5b3UgUVVJQyBCTE9DS0VEIGZyYW1lcywgdW50aWwgeW91IHN0YXJ0DQogcmVhZGluZyB0 aGUgYm9keSBhbmQgZ2VuZXJhdGluZyBXSU5ET1dfVVBEQVRFIGZyYW1lcy4mbmJzcDsgT25lIG9m IHRoZSBiaWdnZXN0IGFyZ3VtZW50cyBmb3IgdHdvIHN0cmVhbXMgaW4gbXkgbWluZCBpcyBtYWtp bmcgc3VyZSB0aGF0IGEgcmVxdWVzdCBibG9ja2VkIGluIHRoaXMgd2F5IGRvZXNuJ3QgaW1wZWRl IHRoZSBmbG93IG9mIGNvbnRyb2wgZnJhbWVzIG9uIHRoYXQgc3RyZWFtIC0tIGZvciBleGFtcGxl LCBzaG91bGQgd2Ugc3VjY2Vzc2Z1bGx5DQogZ2V0IGNlcnRpZmljYXRlIGF1dGggZnJhbWVzIGFk ZGVkLCBhIGNlcnRpZmljYXRlIHJlcXVlc3QuJm5ic3A7IEkndmUgaGFkIHR3byBjdXN0b21lcnMg dGhpcyB3ZWVrIHRlbGxpbmcgbWUgaXQncyBhIGJ1ZyBpbiBvdXIgc2VydmVyIGNvZGUgdGhhdCB0 aGVpciBUTFMgcmVuZWcgZ2V0cyBzdHVjayBpbiBUQ1AgYnVmZmVycyBiZWhpbmQgYSBnaWFudCBy ZXF1ZXN0IGJvZHksIGJlY2F1c2UgdGhlIHNlcnZlciB3b24ndCByZWFkIGFuIHVuYXV0aGVudGlj YXRlZA0KIGJvZHkgYW5kIHRoZSBjbGllbnQgd29uJ3QgaG9sZCBvZmYgc2VuZGluZyB0aGUgYm9k eSB1bnRpbCBhdXRoZW50aWNhdGlvbiBzdWNjZWVkcy4mbmJzcDsgSSdkIGxpa2UgdG8gc2VlIGJs b2NrcyBsaWtlIHRoYXQgYmVjb21lIGxlc3MgcG9zc2libGUgaW4gUVVJQywgYXQgbGVhc3QuPGJy Pg0KPGJyPg0KWWVzLCBtYWtpbmcgU0VUVElOR1MgaW1tdXRhYmxlIHJlZHVjZXMgdGhlIGZsZXhp YmlsaXR5LiZuYnNwOyBUaGUgb3BpbmlvbiBhdCB0aGUgaW50ZXJpbSB3YXMgdGhhdCB3ZSBjb3Vs ZCBsaXZlIHdpdGhvdXQgaXQsIGFzIHdlIGtub3cgb2YgZXhhY3RseSBvbmUgaW1wbGVtZW50YXRp b24gb2Ygb25lIGV4dGVuc2lvbiB0aGF0IGRvZXMgbWlkLXN0cmVhbSBzZXR0aW5nIGNoYW5nZXMs IGFuZCBJIG93biBpdC4mbmJzcDsg8J+YiiZuYnNwOyBJZiB0aGVyZSdzIGEgY29tcGVsbGluZw0K IHVzZSBjYXNlIGZvciBjaGFuZ2luZyBzZXR0aW5ncyBtaWQtc3RyZWFtIHdlIHdlcmVuJ3QgYXdh cmUgb2YsIHRoYXQncyBuZXcgaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBqdXN0aWZ5IHRoZSBjb21w bGV4aXR5LiZuYnNwOyAoQnV0IG5vdGUgdGhhdCB3aXRoIDAtUlRUIGNvbm5lY3Rpb24gc2V0dXAs IGl0IHdvdWxkIGJlIG5lYXJseSBhcyBjaGVhcCB0byBvcGVuIGEgbmV3IGNvbm5lY3Rpb24gd2l0 aCB0aGUgbmV3IHNldHRpbmcgYW5kIHRyYW5zaXRpb24geW91cg0KIHRyYWZmaWMgdG8gaXQuKTxi cj4NCjxicj4NCk5lZ290aWF0aW9uIHN0aWxsIHdvcmtzLCBzaW5jZSBlYWNoIHNpZGUgd291bGQg c2ltcGx5IGFkdmVydGlzZSB0aGF0IHRoZXkgc3VwcG9ydCBhbiBleHRlbnNpb24gb3Igbm90LCBh bmQgY29uc2lkZXIgdGhlIGV4dGVuc2lvbiB0byBiZSBhY3RpdmUgb25jZSB5b3UndmUgc2VlbiB0 aGUgb3RoZXIgc2lkZSdzIFNFVFRJTkdTIGZyYW1lLiZuYnNwOyBTZWUNCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0wMSNzZWN0aW9uLTUu Mi41LjMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sLzx3YnI+ZHJhZnQtaWV0Zi1xdWljLWh0dHAtMDEjPHdicj5zZWN0aW9uLTUu Mi41LjM8L2E+IGZvciB0aGUgY29tcGxleGl0eSB0aGlzIGFsbG93ZWQgdXMgdG8gcmVtb3ZlLiZu YnNwOyBBbiBleHRlbnNpb24gY291bGQgYWRkIHRvIHRoZSBsaXN0IGVhc2lseSAtLSBpZiB5b3Ug c3VwcG9ydCBleHRlbnNpb24gWCwgeW91IHNob3VsZCBhbHNvIHJlbWVtYmVyIHRoZSB2YWx1ZSBm b3Igc2V0dGluZyBYX1ZBTC4mbmJzcDsNCiBDbGllbnRzIHRoYXQgZG9uJ3QgdXNlIHRoZSBleHRl bnNpb24gZG9uJ3QgY2FyZS4mbmJzcDsgQW4gZXh0ZW5zaW9uIHRoYXQgbmVlZGVkIHNvbWUgbW9y ZSBjb21wbGV4IG5lZ290aWF0aW9uIHdvdWxkIGhhdmUgdG8gdXNlIGFuIGV4dGVuc2lvbi1zcGVj aWZpYyBmcmFtZSwgaXQncyB0cnVlLCBidXQgd2UgaGF2ZW4ndCBzbyBmYXIgc2VlbiBhbiBleHRl bnNpb24gZG8gdGhhdC48YnI+DQo8c3BhbiBjbGFzcz0iIj48YnI+DQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mIFN0ZWZhbiBFaXNzaW5nPGJyPg0KU2VudDogV2VkbmVzZGF5LCBNYXJj aCAxNSwgMjAxNyA2OjIyIEFNPGJyPg0KVG86IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRo b21zb25AZ21haWwuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+ DQpTdWJqZWN0OiBSZTogQ29yZSBkcmFmdHMgLTAyIG91dDxicj4NCjxicj4NCjxicj4NCiZndDsg QW0gMTQuMDMuMjAxNyB1bSAwMDo1NyBzY2hyaWViIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVm PSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGlu LnRob21zb25AZ21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGVkaXRv cnMgaGF2ZSBzdWJtaXR0ZWQgLTAyIHZlcnNpb25zIG9mIHRoZSBiYXNlIHNldCBvZiBRVUlDIGRy YWZ0cy48YnI+DQpbLi4uXTxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcXVpYy1odHRwLTAyIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC88d2JyPmRyYWZ0LWlldGYtcXVp Yy1odHRwLTAyPC9hPjxicj4NCjxicj4NClRoYW5rcywgTWFydGluISBJIGFzc3VtZSB0aGF0IHdh cyBhbm5vdW5jZWQgdG8gZ2V0IGZlZWRiYWNrIGZyb20gdGhlIGx1cmtlcnMgaGVyZS4gOy0pPGJy Pg0KPGJyPg0KSSdsbCBnaXZlIHRoaXMgYSB0cnkuIEFsbCBtaXN0YWtlcyBhbmQgbWlzdW5kZXJz dGFuZGluZ3MgYXJlIG1pbmUgYWxvbmUuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVmVyeSB3ZWxsIHdyaXR0ZW4gc3BlYy4g RWFzeSB0byB1bmRlcnN0YW5kIGZvciBzb21lb25lIGhhdmluZyByZWFkIHJmYyA3NTQwIGEgYml0 Ljxicj4NCjxicj4NCkkgaGF2ZSBzb21lIGNvbW1lbnRzIHRvIHRoZSBwcm9wb3NlZCBIVFRQIG1h cHBpbmcgYXBwcm9hY2guIFdoZXJlIHRoZSB3ZyBoYXMgYWxyZWFkeSBkaXNjdXNzZWQgYW5kIGV4 aGF1c3RlZCBhbHRlcm5hdGl2ZXMsIHBsZWFzZSBleGN1c2UgbXkgaWdub3JhbmNlIGFuZCBpZ25v cmUgbXkgY29tbWVudHMuIEkgaGFkIG5vdCB0aGUgdGltZSB0byBmb2xsb3cgYWxsIGRpc2N1c3Np b25zIG9uZ29pbmcgb24gdGhpcyB0b3BpYy4gRmVlbCBmcmVlIHRvIGNoZXJyeS1waWNrDQogd2hh dCBzZWVtcyBoZWxwZnVsLjxicj4NCjxicj4NCjxicj4NCiZndDsgNC4mbmJzcDsgU3RyZWFtIE1h cHBpbmcgYW5kIFVzYWdlPGJyPg0KPGJyPg0KJiM0MzsxIHRvIGRpcmVjdGx5IHVzaW5nIHF1aWMg c3RyZWFtIGlkcyBpbnN0ZWFkIG9mIHZpcnR1YWwgaDIgc3RyZWFtPGJyPg0KPC9zcGFuPiYjNDM7 aWRlbnRpZmllcjxicj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJy Pg0KSG93ZXZlciwgdXNpbmcgMiBxdWljIHN0cmVhbXMgZm9yIGEgc2luZ2xlIHJlcXVlc3QvcmVz cG9uc2UgZG9lcyBub3Qgc2l0IHdlbGwgd2l0aCBtZS4gSSBhc3N1bWUgdGhhdCBzdGVtcyBmcm9t IHRoZSB3aXNoIHRvIGdldCByaWQgb2YgREFUQSBmcmFtZXMuIFdoaWNoIHNvdW5kcyBuaWNlLCBi dXQgaXMgaXQgd29ydGggaXQ/IEJ5IGRvdWJsaW5nIHRoZSAjIG9mIHN0cmVhbXMgZm9yIGEgY2xp ZW50LCBob3cgbXVjaCBvdmVyaGVhZCBkb2VzIHRoYXQNCiBpbnRyb2R1Y2UgKEkgc3BlYWsgb2Yg YSBzZXJ2ZXIgaG9sZGluZyAmZ3Q7MTBrIHF1aWMgJnF1b3Q7Y29ubmVjdGlvbnMmcXVvdDspPzxi cj4NCjxicj4NCkFsc28sIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gYnVmZmVyIGRhdGEgb24gcXVpYyBz dHJlYW1zIDcsIDExLCAxNSwgZXRjLiBiZWNhdXNlIEhFQURFUnMgbWlnaHQgYXJyaXZlIHNvbWUg dGltZSBpbiB0aGUgZnV0dXJlIG9uIHN0cmVhbXMgNSwgOSwgMTMsIGV0Yy4gb3Igbm90LiBUaGVy ZSBpcyBubyB3YXkgdG8gcm91dGUgdGhpcyBkYXRhIHNvbWV3aGVyZSwgYmVjYXVzZSB0aGUgbWV0 YSBpbmZvcm1hdGlvbiBpcyBzdGlsbCBtaXNzaW5nLjxicj4NCjxicj4NCkFuZCB0aGVyZSBpcyBz dGlsbCBIb2xiIG9uOjxicj4NCjxicj4NCiZndDsgNC4yLjEuJm5ic3A7IEhlYWRlciBDb21wcmVz c2lvbjxicj4NCiZndDsgLi4uPGJyPg0KJmd0OyBESVNDVVNTOiZuYnNwOyBLZWVwIEhQQUNLIHdp dGggSE9MQj8mbmJzcDsgUmVkZXNpZ24gSFBBQ0sgdG8gYmUgb3JkZXItPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ludmFyaWFudD8mbmJzcDsgSG93IG11Y2ggZG8gd2UgbmVl ZCB0byByZXRhaW4gY29tcGF0aWJpbGl0eSB3aXRoPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0hUVFAvMidzIEhQQUNLPzxicj4NCjxicj4NClVzaW5nIGEgY291bnRlciBpbiBI RUFERVJTIGlzIGEgY3J1dGNoOjxicj4NCi0gaXQgaXMgYSBoaWdobHkgc3BlY2lmaWMgc29sdXRp b24gdG8gYSBjb21tb24gcHJvYmxlbSBpbiBodHRwL3F1aWM6IHN5bmNocm9uaWNpdHkgaW4gY29u bmVjdGlvbiBsZXZlbCBzdGF0ZSBjaGFuZ2VzLiBTRVRUSU5HUyAoc2VlIGJlbG93KSBoYXMgdGhl IHNhbWUgcHJvYmxlbSwgYXMgZG9lcyBoYXZlIFBSSU9SSVRZIGluIEhFQURFUlMuIEl0IHNlZW1z IHRoYXQgcGVyZm9ybWFuY2Ugd2lzZSwgYWxsIEhFQURFUlMgY291bGQgYXMgd2VsbCBiZSBzZW50 DQogb24gc3RyZWFtIDMuPGJyPg0KPGJyPg0KTm93LCBzb2x2aW5nIEhvbCBibG9ja2luZyBmb3Ig SEVBREVSUyB3b3VsZCBiZSBhIGZpbmUgYWNoaWV2ZW1lbnQuPGJyPg0KPGJyPg0KJmd0OyA1LiZu YnNwOyBIVFRQIEZyYW1pbmcgTGF5ZXI8YnI+DQomZ3Q7IEZyYW1lcyBhcmUgdXNlZCBvbmx5IG9u IHRoZSBjb25uZWN0aW9uIChzdHJlYW0gMykgYW5kIG1lc3NhZ2U8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAoc3RyZWFtcyA1LCA5LCBldGMuKSBjb250cm9sIHN0cmVhbXMuPGJyPg0KPGJyPg0KQW5k IHN0cmVhbXMgNCwgOCwgMTIsIGV0Yy4gSSBhc3N1bWUuPGJyPg0KPGJyPg0KJmd0OyA1LjIuMy4m bmJzcDsgU0VUVElOR1M8YnI+DQomZ3Q7IC4uLjxicj4NCiZndDsgU0VUVElOR1MgZnJhbWVzIGFs d2F5cyBhcHBseSB0byBhIGNvbm5lY3Rpb24sIG5ldmVyIGEgc2luZ2xlIHN0cmVhbS48YnI+DQom Z3Q7Jm5ic3A7IEEgU0VUVElOR1MgZnJhbWUgTVVTVCBiZSBzZW50IGFzIHRoZSBmaXJzdCBmcmFt ZSBvZiB0aGUgY29ubmVjdGlvbjxicj4NCiZndDsgY29udHJvbCBzdHJlYW0gKHNlZSBTZWN0aW9u IDQpIGJ5IGVhY2ggcGVlciwgYW5kIE1VU1QgTk9UIGJlIHNlbnQ8YnI+DQomZ3Q7IHN1YnNlcXVl bnRseSBvciBvbiBhbnkgb3RoZXIgc3RyZWFtLiZuYnNwOyBJZiBhbiBlbmRwb2ludCByZWNlaXZl cyBhbjxicj4NCiZndDsgU0VUVElOR1MgZnJhbWUgb24gYSBkaWZmZXJlbnQgc3RyZWFtLCB0aGUg ZW5kcG9pbnQgTVVTVCByZXNwb25kIHdpdGg8YnI+DQomZ3Q7IGEgY29ubmVjdGlvbiBlcnJvciBv ZiB0eXBlIEhUVFBfU0VUVElOR1NfT05fV1JPTkdfU1RSRUFNLiZuYnNwOyBJZiBhbjxicj4NCiZn dDsgZW5kcG9pbnQgcmVjZWl2ZXMgYSBzZWNvbmQgU0VUVElOR1MgZnJhbWUsIHRoZSBlbmRwb2lu dCBNVVNUIHJlc3BvbmQ8YnI+DQomZ3Q7IHdpdGggYSBjb25uZWN0aW9uIGVycm9yIG9mIHR5cGUg SFRUUF9NVUxUSVBMRV9TRVRUSU5HUy48YnI+DQo8YnI+DQpXaGF0IGFib3V0IEhQQUNLIHN0YXRl PyBUaGUgY29ubmVjdGlvbiBzdGF0ZSBjaGFuZ2UgcHJvYmxlbSBhZ2FpbiB2aXNpYmxlLjxicj4N Cjxicj4NClRoaXMgaXMgYSBzZXZlcmUgcmVzdHJpY3Rpb24gb24gZXh0ZW5zaW9ucyBtZWNoYW5p c21zIHRoYXQgd2FudCB0byBhZmZlY3QgYSBjb25uZWN0aW9uLiBCZWNhdXNlIGlmIHRoZSBodHRw L3F1aWMgZG9lcyBub3Qgc29sdmUgdGhpcyBwcm9ibGVtLCBob3cgYXJlIHRoZXkgZXhwZWN0ZWQg dG8gZG8gaXQ/IFRoZXkgZWl0aGVyIGFubm91bmNlIHRoZW1zZWx2ZXMgb24gdGhlIGZpcnN0IFNF VFRJTkdTIG9yIHJlbWFpbiBzaWxlbnQgZm9yZXZlciwgaXQNCiBzZWVtcy4gSG93IHdvdWxkIGFu IGV4dGVuc2lvbiBoYW5kc2hha2Ugd29yayB0aGVuPyBPd24gc3RyZWFtIDMgaGFuZHNoYWtlIGZy YW1lcz88YnI+DQo8YnI+DQomZ3Q7IDUuMi4zLjMuJm5ic3A7IFVzYWdlIGluIDAtUlRUPGJyPg0K PGJyPg0KV2hhdCBhYm91dCBIUEFDSyBzdGF0ZT8gRG9lcyBpdCBuZWVkIHRvIGJlIGtlcHQgb3Ig aXMgaXQgcmVzZXQ/PGJyPg0KPGJyPg0KJmd0OyBIVFRQX1BVU0hfQUxSRUFEWV9JTl9DQUNIRSAo MHgwMyk6Jm5ic3A7IFRoZSBzZXJ2ZXIgaGFzIGF0dGVtcHRlZCB0byBwdXNoPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRlbnQgd2hpY2ggdGhlIGNsaWVudCBoYXMgY2FjaGVkLjxi cj4NCiZndDsgLi4uPGJyPg0KJmd0OyBIVFRQX1JFUVVFU1RfQ0FOQ0VMTEVEICgweDA0KTombmJz cDsgVGhlIGNsaWVudCBubyBsb25nZXIgbmVlZHMgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7cmVxdWVzdGVkIGRhdGEuPGJyPg0KPGJyPg0KTml0cGljazogc2VlbXMgcmVkdW5kYW50 LiBUaGUgZmlyc3QgY291bGQgYmUgcmVwbGFjZWQgYnkgdGhlIHNlY29uZC4gU3RyZWFtIG51bWJl ciB3aWxsIHN1ZmZpY2UuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVGFraW5nIHR3byBz dGVwcyBiYWNrOjxicj4NCjxicj4NCkkgdGhpbmsgdGhlIG1haW4gZGlmZmljdWx0eSBjb21lcyBm cm9tIHRoZSBsYWNrIG9mIGEgJnF1b3Q7aHEgY29ubmVjdGlvbiBzdGF0ZSZxdW90OyBjb25jZXB0 IGFuZCBob3cgY2hhbmdlcyB0byB0aGF0IHN0YXRlIGNhbiBiZSBtYW5hZ2VkLiBFdmlkZW5jZTo8 YnI+DQotIFRoZSAwLVJUVCBtZW50aW9ucyBjZXJ0YWluIFNFVFRJTkdTIHRoYXQgbmVlZCB0byBi ZSByZW1lbWJlcmVkIGJ5IGEgY2xpZW50LiBIb3cgd291bGQgYW4gZXh0ZW5zaW9uIGFkZCB0byB0 aGlzPyBXaWxsIGV2ZXJ5IGV4dGVuc2lvbiBoYXZlIHRvIGNvbWUgdXAgd2l0aCBpdHMgb3duIHNv bHV0aW9uPzxicj4NCi0gVGhlIEhFQURFUnMgc2VxdWVuY2UgbnVtYmVyIGlzIGEgaGlnaGx5IHNw ZWNpZmljIGZpeCBmb3IgdGhlIG1pc3Npbmcgc3RhdGUgY2hhbmdlPGJyPg0KLSBUaGUgU0VUVElO R1MtT05DRSByZXN0cmljdGlvbiBzaW1wbHkgYXZvaWRzIHRoZSBwcm9ibGVtIGJ5IGtpbGxpbmcg YSBoMiBtZWNoYW5pc208YnI+DQo8YnI+DQpJZiBocSBkZWZpbmVzIHN0cmVhbSAzIGFzIHRoZSBw bGFjZSB3aGVyZSBjb25uZWN0aW9uIHN0YXRlIGNoYW5nZXMgaGFwcGVuICpBTkQqIHN5bmNocm9u aXplcyBPUEVOL0NMT1NFL1JTVCBvZiBvdGhlciBzdHJlYW1zIG9uIGl0LCBjbGllbnQgYW5kIHNl cnZlciBjYW4gaGF2ZSBzaGFyZWFibGUgY29uY2VwdCBvZiB0aGUgY29ubmVjdGlvbiBzdGF0ZS48 YnI+DQo8YnI+DQo8YnI+DQpJIGFtIG5vIEhQQUNLIGV4cGVydC4gVGhlIGJhc2ljIHByb2JsZW0g bG9va3MgbGlrZSBjb25jdXJyZW50IGVkaXRpbmcgYWdhaW5zdCBhIHJlcG9zaXRvcnkuPGJyPg0K Qm90aCBjbGllbnQgYW5kIHNlcnZlciBzdGFydCB3aXRoIGNvbm5lY3Rpb24gc3RhdGUgemVybyAo Q1MtMCkgYW5kIHRoZSBwcmVkZWZpbmVkIEhQQUNLIGRpY3Rpb25hcnkgKEhQLTApLiBBZnRlciBT RVRUSU5HUyBleGNoYW5nZSwgY2xpZW50IGlzIGluIENTLTEgYW5kIHNlcnZlciBpcyBpbiBDUy0y IGZvciBpdHMgc2lkZS4gTGV0J3MgY2FsbCB0aGUmbmJzcDsgQ1MtMSBIUEFDSyBzdGF0ZSBIUC0x Ljxicj4NCjxicj4NCkNsaWVudCBzZW5kcyBuZXcgSEVBREVSUyBvbiA1IGFuZCBrZWVwcyB0aGUg SFBBQ0sgZGVsdGEgYXJvdW5kIChIUC0xLjUpLiBUaGUgSEVBREVSUyBjYXJyaWVzIHRoZSBjb25u ZWN0aW9uIHN0YXRlIG51bWJlciBpdCBpcyBiYXNlZCBvbiAoQ1MtMSkuIENsaWVudCBzZW5kcyBu ZXcgSEVBREVSUyBvbiBzdHJlYW0gOSwgYWxzbyBiYXNlZCBvbiBDUy0xLiBDbGllbnQga2VlcHMg dGhhdCBkZWx0YSBhcm91bmQgKEhQLTEuOSkuPGJyPg0KPGJyPg0KQ2xpZW50IHRoZW4gZGVjaWRl cyB0byBhbm5vdW5jZSBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIChDUy0zKSBieSBzZW5kaW5nIGhv dyBpdCBhcHBsaWVkIHRoZSBkZWx0YXMgSFAtMS41IGFuZCBIUC0xLjkgdG8gY29tZSB1cCB3aXRo IEhQLTMuIFRoZSBkZXNjcmlwdGlvbiBhbGxvd3MgdGhlIHNlcnZlciB0byB1cGRhdGUgaXRzIEhQ LTEgdG8gSFAtMyBhcyB3ZWxsLjxicj4NCjxicj4NClJlc3BvbnNlIEhFQURFUlMgYXJlIGFsc28g YmFzZWQgb24gYSBzZXJ2ZXIgY29ubmVjdGlvbiBzdGF0ZSwgZXhwbGljaXRseSwgc28gdGhlIGNs aWVudCBrbm93cyB3aGljaCBIUC1YIHRvIHVzZSB3aGVuIGRlY29kaW5nIHRoZW0uIEF0IHNvbWUg dGltZSwgdGhlIHNlcnZlciBzZW5kcyBhbiBhbm5vdW5jbWVudCBvZiBDUy00IHdpdGggSFBBQ0sg ZGF0YSBvbiBzdHJlYW0gMyBiYWNrIHRvIHRoZSBjbGllbnQuPGJyPg0KPGJyPg0KRm9yIGEgMC1S VFQsIGNsaWVudCBhbmQgc2VydmVyIGNvdWxkIGV4Y2hhbmdlIHRoZSBjb25uZWN0aW9uIHN0YXRl IGlkIGluIHRoZSBpbml0aWFsIFNFVFRJTkdTLCB0byBtYWtlIHN1cmUgdGhleSBoYXZlIGF0IGxl YXN0IHRoZSBzYW1lIG5hbWUgcmVtZW1iZXJlZCBhcyB0aGUgb3RoZXIgc2lkZS4gQ2xpZW50OiAm cXVvdDtJIHdhcyBpbiBDUy0xOSBhbmQgeW91IHdlcmUgaW4gQ1MtOC4mcXVvdDsgU2VydmVyOiAm cXVvdDtZZXAuJnF1b3Q7PGJyPg0KPGJyPg0KQnkgaW1wbGljaXRseSBhZGRpbmcgYWxsIFNFVFRJ TkdTIGNoYW5nZXMgdG8gY29ubmVjdGlvbiBzdGF0ZXMsIHRoZSBwcm9ibGVtIGlzIGFsc28gc29s dmVkIGZvciBleHRlbnNpb25zLjxicj4NCjxicj4NCklmIG9uZSBzaWRlIHJlY2VpdmVzIEhFQURF UlMgd2l0aCBhbiB1bmtub3duIGNvbm5lY3Rpb24gc3RhdGU6PGJyPg0KLSBpZiB0aGUgc3RhdGUg aWQgaXMgZ3JlYXRlciB0aGFuIGFueSBrbm93biBvbmU6IHNldCBhIHN0cmVhbSB0aW1lb3V0IGFu ZCB3YWl0IGZvciBjaGFuZ2VzIG9uIHN0cmVhbSAzIHRvIGFycml2ZTxicj4NCi0gc3RhdGUgaWQg bGVzcyB0aGFuIG1heChrbm93biBjb25uIHN0YXRlKTogU1RSRUFNX1JTVF9VTktOT1dOX0NPTk5f U1RBVEU8YnI+DQo8YnI+DQpOZXcgU0VUVElOR1MgdmFsdWU6IE1BWF9DT05OX1NUQVRFIG51bWJl ciBvZiBtYXhpbXVtIGNvbm5lY3Rpb24gc3RhdGUgdGhlIGNsaWVudC9zZXJ2ZXIgaXMgd2lsbGlu ZyB0byBrZWVwLCBleGNoYW5nZWQgaW5pdGlhbGx5LiBBbm5vdW5jaW5nIGEgbmV3IGNvbm5lY3Rp b24gc3RhdGUgYWxsb3dzIHRoZSBvdGhlciBzaWRlIHRvIGRyb3AgdGhlIGxvd2VzdCBvbmUsIGlm IE1BWF9DT05OX1NUQVRFIGFyZSB1c2VkLjxicj4NCjxicj4NClRvIGdldCBvcHRpbWFsIEhQQUNL IHNpemUgY29tcHJlc3Npb24sIGV2ZXJ5IEhFQURFUnMgd291bGQgYWxzbyBhbm5vdW5jZSBhIG5l dyBjb25uZWN0aW9ucyBzdGF0ZS4gVG8gaGF2ZSBsZXNzIHBvdGVudGlhbCBIT0xCLCBjb25uZWN0 aW9uIHN0YXRlcyBkbyBub3QgY2hhbmdlIGR1cmluZyByZXF1ZXN0IGJ1cnN0cy48YnI+DQo8YnI+ DQpTb21ldGhpbmcgbGlrZSB0aGF0Ljxicj4NCjxicj4NCi1TdGVmYW48YnI+DQo8YnI+DQo8YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9 ImFsbCI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KLS0gPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfc2ln bmF0dXJlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbic7IGZvbnQt c2l6ZTptZWRpdW0iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoODUsODUsODUpOyBmb250LWZhbWls eTpzYW5zLXNlcmlmOyBsaW5lLWhlaWdodDoyMHB4OyBmb250LXNpemU6c21hbGwiPjxzcGFuIHN0 eWxlPSJib3JkZXItdG9wLXdpZHRoOjJweDsgYm9yZGVyLXJpZ2h0LXdpZHRoOjBweDsgYm9yZGVy LWJvdHRvbS13aWR0aDowcHg7IGJvcmRlci1sZWZ0LXdpZHRoOjBweDsgYm9yZGVyLXRvcC1zdHls ZTpzb2xpZDsgYm9yZGVyLXJpZ2h0LXN0eWxlOnNvbGlkOyBib3JkZXItYm90dG9tLXN0eWxlOnNv bGlkOyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLXRvcC1jb2xvcjpyZ2IoMjEzLDE1 LDM3KTsgYm9yZGVyLXJpZ2h0LWNvbG9yOnJnYigyMTMsMTUsMzcpOyBib3JkZXItYm90dG9tLWNv bG9yOnJnYigyMTMsMTUsMzcpOyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjEzLDE1LDM3KTsgcGFk ZGluZy10b3A6MnB4OyBtYXJnaW4tdG9wOjJweCI+Q2hhcmxlcw0KICdCdWNrJyBLcmFzaWMmbmJz cDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJib3JkZXItdG9wLXdpZHRoOjJweDsgYm9yZGVyLXJpZ2h0 LXdpZHRoOjBweDsgYm9yZGVyLWJvdHRvbS13aWR0aDowcHg7IGJvcmRlci1sZWZ0LXdpZHRoOjBw eDsgYm9yZGVyLXRvcC1zdHlsZTpzb2xpZDsgYm9yZGVyLXJpZ2h0LXN0eWxlOnNvbGlkOyBib3Jk ZXItYm90dG9tLXN0eWxlOnNvbGlkOyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgYm9yZGVyLXRv cC1jb2xvcjpyZ2IoNTEsMTA1LDIzMik7IGJvcmRlci1yaWdodC1jb2xvcjpyZ2IoNTEsMTA1LDIz Mik7IGJvcmRlci1ib3R0b20tY29sb3I6cmdiKDUxLDEwNSwyMzIpOyBib3JkZXItbGVmdC1jb2xv cjpyZ2IoNTEsMTA1LDIzMik7IHBhZGRpbmctdG9wOjJweDsgbWFyZ2luLXRvcDoycHgiPiZuYnNw O1NvZnR3YXJlDQogRW5naW5lZXImbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJib3JkZXItdG9w LXdpZHRoOjJweDsgYm9yZGVyLXJpZ2h0LXdpZHRoOjBweDsgYm9yZGVyLWJvdHRvbS13aWR0aDow cHg7IGJvcmRlci1sZWZ0LXdpZHRoOjBweDsgYm9yZGVyLXRvcC1zdHlsZTpzb2xpZDsgYm9yZGVy LXJpZ2h0LXN0eWxlOnNvbGlkOyBib3JkZXItYm90dG9tLXN0eWxlOnNvbGlkOyBib3JkZXItbGVm dC1zdHlsZTpzb2xpZDsgYm9yZGVyLXRvcC1jb2xvcjpyZ2IoMCwxNTMsNTcpOyBib3JkZXItcmln aHQtY29sb3I6cmdiKDAsMTUzLDU3KTsgYm9yZGVyLWJvdHRvbS1jb2xvcjpyZ2IoMCwxNTMsNTcp OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMCwxNTMsNTcpOyBwYWRkaW5nLXRvcDoycHg7IG1hcmdp bi10b3A6MnB4Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86Y2tyYXNpY0Bnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+Y2tyYXNpY0Bnb29nbGUuY29tPC9hPiZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5 bGU9ImJvcmRlci10b3Atd2lkdGg6MnB4OyBib3JkZXItcmlnaHQtd2lkdGg6MHB4OyBib3JkZXIt Ym90dG9tLXdpZHRoOjBweDsgYm9yZGVyLWxlZnQtd2lkdGg6MHB4OyBib3JkZXItdG9wLXN0eWxl OnNvbGlkOyBib3JkZXItcmlnaHQtc3R5bGU6c29saWQ7IGJvcmRlci1ib3R0b20tc3R5bGU6c29s aWQ7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBib3JkZXItdG9wLWNvbG9yOnJnYigyMzgsMTc4 LDE3KTsgYm9yZGVyLXJpZ2h0LWNvbG9yOnJnYigyMzgsMTc4LDE3KTsgYm9yZGVyLWJvdHRvbS1j b2xvcjpyZ2IoMjM4LDE3OCwxNyk7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMzgsMTc4LDE3KTsg cGFkZGluZy10b3A6MnB4OyBtYXJnaW4tdG9wOjJweCI+Jm5ic3A7PHNwYW4gdGl0bGU9IkNhbGwg d2l0aCBHb29nbGUgVm9pY2UiPiYjNDM7MQ0KICg0MDgpIDQxMi0xMTQxPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PGJyPg0KPGJyPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7CF7F94CB496BF4FAB1676F375F9666A376F6784bgb01xud1012_-- From nobody Tue Mar 21 16:30:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021D2129496 for ; Tue, 21 Mar 2017 16:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr0EBltADG0n for ; Tue, 21 Mar 2017 16:30:40 -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 0CCC7129409 for ; Tue, 21 Mar 2017 16:30:40 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cqTEb-0004pI-KJ for quic@ietf.org; Wed, 22 Mar 2017 00:30:38 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cqTE4-0005wA-Vq for quic@ietf.org; Tue, 21 Mar 2017 19:30:35 -0400 Received: (qmail 1610 invoked from network); 21 Mar 2017 23:30:04 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.235]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Mar 2017 23:30:03 -0000 To: quic@ietf.org References: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> <58b235ad-a9bb-d453-0157-f874687ae241@tik.ee.ethz.ch> From: Christian Huitema Message-ID: <771e4500-02bc-53cc-fb3c-543c9ebc39e2@huitema.net> Date: Tue, 21 Mar 2017 16:30:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXr44GwFVGcx9BqCV4Q6kRHXRcOb18WfxGyg6Om6u4YYmzGZgTQ10P29i8Cq ZqbAVNg5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+g3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0ZSkvDaOo Sn0wW/3waLzzVbbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWJKyg1OJH8aak+/hDMnS4uzLQQGIH13szEQZ25LjADnMNKE9KHxubof09 beZcyamvcqiSoo7BxyxRryqmiHuCdUetTZ/25DKDZC7RirBgbePcy8BFh+JufJrwsKmKW6bHd9QD sMspn/O/edVkHySM+CDVwFjZwEavmmk7Tr9uJ5mso9iv7kZ9azJt3DY/E7nm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:30:42 -0000 On 3/19/2017 4:09 PM, Martin Thomson wrote: > In HTTP, when you can't get TLS, you can't resolve an https:// URI. > We have a very clear rule that says that you prefer to fail than to > accept the risk of compromise. This is critical to the functioning of > the protocol. > > That might not be true for DNS over QUIC where the expectations for > security are - shall we say - lower. But all this needs to say is > that if you have some security expectations and you find that fallback > would lead to them being in some way compromised, you fail. I am not sure that security expectations for DNS over QUIC should be lower. I would expect DNS over QUIC to match the security of DNS over TLS (RFC 7858). We need consider the "game theory" aspects of any downgrade. If we allow fall back to a non encrypted alternative, then we reward the attackers. They block QUIC, observe the protocol silently switching to clear text, get access to the data that they are seeking, and all that without causing too many customer complaints. On the other hand, if blocking QUIC just blocks the service, customers will complain, to the service providers of course, but also very quickly to the intermediaries that set the block. For these blockers, the support cost will be much higher. And that means they will be less likely to block random services. -- Christian Huitema From nobody Tue Mar 21 17:34:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3D812940A for ; Tue, 21 Mar 2017 17:34:53 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0DRywMvwT_K for ; Tue, 21 Mar 2017 17:34:52 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64984129410 for ; Tue, 21 Mar 2017 17:34:52 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id y76so147878000qkb.0 for ; Tue, 21 Mar 2017 17:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LBLvGXIkv5snuYc4XaKAjAOFkSRl0Fl/UMlNf829Wvw=; b=uPULU9afj+Kohdg1T3QbAgx634gh4QCwWKe4pk6po4S4tMNcOd2dJ10MSgKzo7Ebct Y1JQpG7c8au+idRG6YrlrZGTLnMluV2LtBKg2ewIHDNNt0jv2TNdZBqlxNaBGQtnkiEe dTni45Nwqz8d02RgHhIbpJCIAFWI/daJ+OlzriVHKPmTqrV9emacWFXVxO7oD9p8yAdo /TzuUrjz5arsW2SMtFcutpW2i04/CS4TjXc99Mz3H9pbtgUy8oyNbH7+/gwqicnckLva QILjAY2zkRMKuqebFoI21zCX921e9TBPOjXKx7/BE8yfX3fxkHmIt9V9bDd2sIu2KkV4 UmKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LBLvGXIkv5snuYc4XaKAjAOFkSRl0Fl/UMlNf829Wvw=; b=Y6IvsuCJ4UcfjjnG5OB2CaXpmirLGbodmKpEvbrfatduLkEz8ykFUujOSBne1C4FuS iIXQIJBJMkcBxyyBdPhQnuA0eOtR2cMVZtTxP5PJrOmgo+wMB/Bgoo1+rbXEgQIrrF6w pb4qEdB+ExVR3Bjygq82ODNgsuntZIIqAFdvZMlSNzp3Jsi89d0uwsueqNFw3qTnlba7 QHF/uZWflCYXsUMc8Ump3zfYtD2uRoSeso5hhvwfXRW5yRmY3Bt02yzWuzvK1MRqQAbt Vyrzk9uSWBouNDv5KMVt7MwGLvKm2ik05KQGiFihCY9swOQKucCOsbNTNTY8Xk6J1GVh lV7A== X-Gm-Message-State: AFeK/H0Z/s/PbmEyoNuZPPmfFUksJCHEE22ARjMtek1Nhi2ecaHXOIrjPldC/LT08g2h2FlHAjSm1miKYNkT0g== X-Received: by 10.233.237.20 with SMTP id c20mr35024721qkg.144.1490142891498; Tue, 21 Mar 2017 17:34:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Tue, 21 Mar 2017 17:34:50 -0700 (PDT) In-Reply-To: <771e4500-02bc-53cc-fb3c-543c9ebc39e2@huitema.net> References: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> <58b235ad-a9bb-d453-0157-f874687ae241@tik.ee.ethz.ch> <771e4500-02bc-53cc-fb3c-543c9ebc39e2@huitema.net> From: Martin Thomson Date: Wed, 22 Mar 2017 11:34:50 +1100 Message-ID: Subject: Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 To: Christian Huitema Cc: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 00:34:54 -0000 On 22 March 2017 at 10:30, Christian Huitema wrote: > I am not sure that security expectations for DNS over QUIC should be > lower. I would expect DNS over QUIC to match the security of DNS over > TLS (RFC 7858). I did assumed that that did not exist, which might be unfair. > We need consider the "game theory" aspects of any downgrade. If we allow > fall back to a non encrypted alternative, then we reward the attackers. > They block QUIC, observe the protocol silently switching to clear text, > get access to the data that they are seeking, and all that without > causing too many customer complaints. On the other hand, if blocking > QUIC just blocks the service, customers will complain, to the service > providers of course, but also very quickly to the intermediaries that > set the block. For these blockers, the support cost will be much higher. > And that means they will be less likely to block random services. An excellent point. Though you are condoning a denial of service attack of a sort. Not sure where I stand on the morality of that. From nobody Wed Mar 22 10:50:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603B8129B72 for ; Wed, 22 Mar 2017 10:50:46 -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 3RbO6zEMRELz for ; Wed, 22 Mar 2017 10:50:44 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A1B1294E8 for ; Wed, 22 Mar 2017 10:50:40 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id i34so158300109qtc.0 for ; Wed, 22 Mar 2017 10:50:40 -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=U+in2OFMdBaDLFICUjhMzyDv4a68u+DhEY6CnBj6pJA=; b=NNYcLI50yT7exf9T9mRaYt4WDdelpAz/AR3WkUkvCKFfuo+/6QzDsjjq34rD99WSbl VvG+RwTCCwnoXcHxfYWiPfZxPe/3sCW/JqP0IDgraBoNe4y5KnaViS1zHarQ2zBAsS+v dxB7YnRoELtCd+kUqAi8YnaGPb67v4OBVY1+Gb1Dvs/hdcQAD7BJJbg90BZuY2IvS8Au YrSK+KwXssRxWH9knmCHfgMIoJFMtp2NBKXtiu1+LCjQeixd95+pGHDtzMOpl19rtTVm Q0Kd8Fvo/a1j0PcC7rsb+wyS4AEmPcHLL5mlMONhXPHsxuIhkQ1/1eFV75lzN9Jh6U3v zpDA== 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=U+in2OFMdBaDLFICUjhMzyDv4a68u+DhEY6CnBj6pJA=; b=iKk4Y9yUJV3iafuJYoFD0fRRHgsDsKzrqlMqOew/xlVgpIwSLKhNTbNqh230pO8quV Uj/ziOyGglPp6XwN6dw3is3P+9QN+RrQH8WT8ZxPlYNUXryetoJlDvNVbkK59Ew1aN1h 0eFXe08gep14HV+plL8XInqdU34b4cVjE/K4p3O9whA8JNB/LSfQOeAvdMFrp81PiqPK y+qnJV9XzB6VQD9D/Zc1ZYNL5cFKjJdKc01B+kidX7gx+EMWVAutqgoHOfunCAbfC/8F ZIaioWTNqJFnUH4JRCVpn5WCyZRukcSaigjpn5HbmjWkTcsd8mNtwm1X5jfOJTpbnqit 5nCA== X-Gm-Message-State: AFeK/H0NesfVpcY0gQZdiOf9PKGhCl8hEFw07f6z4ZQZ66HQ4rVL+VNCNYI/vwllvWsLua0q31cWoh0Ng3mIUg== X-Received: by 10.200.47.9 with SMTP id j9mr27677128qta.57.1490205039314; Wed, 22 Mar 2017 10:50:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.41 with HTTP; Wed, 22 Mar 2017 10:50:38 -0700 (PDT) From: "Aron ." Date: Wed, 22 Mar 2017 13:50:38 -0400 Message-ID: Subject: QUIC error codes -- too many *and* too few To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113773b402cf31054b556642 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 17:50:46 -0000 --001a113773b402cf31054b556642 Content-Type: text/plain; charset=UTF-8 Dear QUICsters, I believe that the QUIC protocol specification goes overboard in trying to have an error code for each error condition. Of course, the roots of this are historic: since both first client and server use the same code base, it makes sense to enumerate all possible errors to facilitate debugging. (An error code like QUIC_MAYBE_CORRUPTED_MEMORY is a good example of this.) However, as the number of QUIC implementations grows, a list of errors this long and this specific is, I think, ill-advised. My copy of *HTTP: The Definitive Guide (O'Reilly, 2002)* lists a grand total of eighteen 400-level codes. 15 years later, Wikipedia's list of HTTP status codes has twenty-eight. draft-ietf-quic-transport.md has about sixty. What is the client to do with these error codes? It can probably not do much more than log them. On the server side, finding a matching error code for an error condition would probably be a difficult task, especially if the implementation folds several checks into one. Other error codes are potential information leaks, such as some crypto-related codes. In regards to having too few error codes, it would be useful to have two catch-all error codes (like HTTP 400 and 500), one for client errors and one for server errors, which could be used (something like a MAY in the spec?) when an appropriate error code does not exist. An aspiring QUIC implementer. --001a113773b402cf31054b556642 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear=C2=A0QUICsters,

I belie= ve that the QUIC protocol specification goes overboard in trying to have an= error code for each error condition.=C2=A0 Of course, the roots of this ar= e historic: since both first client and server use the same code base, it m= akes sense to enumerate all possible errors to facilitate debugging.=C2=A0 = (An error code like QUIC_MAYBE_CORRUPTED= _MEMORY is a good example of this.)=C2=A0 However, as the number of = QUIC implementations grows, a list of errors this long and this specific is= , I think, ill-advised.

My copy of HTTP: The D= efinitive Guide (O'Reilly, 2002) lists a grand=C2=A0total of=C2=A0= eighteen 400-level codes.=C2=A0=C2=A015 years later, Wikipedia's list of HTTP status codes has twenty-eight.=C2= =A0 draft-ietf-quic-transport.md has = about sixty.=C2=A0 What is the client to do with these error codes?=C2=A0 I= t can probably not do much more than log them.

On = the server side, finding a matching error code for an error condition would= probably be a difficult task, especially if the implementation folds sever= al checks into one.=C2=A0 Other error codes are potential information leaks= , such as some crypto-related codes.

In regards to= having too few error codes, it would be useful to have two catch-all error= codes (like HTTP 400 and 500), one for client errors and one for server er= rors, which could be used (something like a MAY in the spec?) when an appro= priate error code does not exist.

=C2=A0 An aspiri= ng QUIC implementer.

--001a113773b402cf31054b556642-- From nobody Wed Mar 22 14:27:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB84C12922E for ; Wed, 22 Mar 2017 14:27:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eRHjn71ethu4 for ; Wed, 22 Mar 2017 14:26:59 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E37127097 for ; Wed, 22 Mar 2017 14:26:58 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r69so26384095vke.2 for ; Wed, 22 Mar 2017 14:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v6RNCJMEi5ozcZyS8HxrAKjEe1hx7BjAdPxwBG4ALNM=; b=VmVNMtOKOtffIal6Gw538i9ZAiODQumT35woH9bBj0pqWB1DHfyk/3gPRdAe0TAYEf 1tbr/dNQSvjC7E0RLTD70/OWTszAHiJnmeJ/OU2jYo8je9M+Xt560KxWkhgiFepMZtjt vaQsEJymNBA9vgC5fDgDRw92DxVhJSQJzYjbcFv+qDaTUggJK5uwO+Z57Z22AYgvdUi+ FjWFs0ouIbtHv0f/w1riWL0KPPKCHx2pZ4U+MtF8QCOTx78izxnSBlpSpPV7W97ou+FQ 29/z+9hnfHjeN3oxjC2ln2KdwcPmVX2b6XA1Z/PodsBOaotV/7it2r/fyQlF8g4bWrIR /1xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v6RNCJMEi5ozcZyS8HxrAKjEe1hx7BjAdPxwBG4ALNM=; b=hjM+ktBYIAeV9ywjYQrk7lJgtsJGochKhGJUsXurLt+D+vSkQHzDIukuHM29S6eJv+ T2aWdbK+qld5bIEExBqHzVVRpRMcDvvnwsmZ9ksjK9PsJRqGmBaPFfXr9ZKeos/Xah6O 4QPf94AbLUfCSg03ghLCimycYTyJ7d4mf1bx7OO1JrU9vird/0fjj+cSullzeIc552p4 MO2ccUxWbLS7qlIwAdxj1iWF2mPrw2ML2CVnUBR3sWGedBIIgpDp6LII2DjEo+vUv6Z9 CbgYs9IjS0JxpqaC1F+Ynt9touPwrFHBQ/K/dMYnB1h/QrNP4ImsIb+BQHbrR6t800Nn hGow== X-Gm-Message-State: AFeK/H2gL2wQSaY3YD+/+BWkugdLjyCaqD9lLLyulVy2mhKqxY3BYNCm8lZv6oJkvYq0EsLO1f7aG6K9B3pRBy8c X-Received: by 10.159.36.238 with SMTP id 101mr3639844uar.61.1490218017624; Wed, 22 Mar 2017 14:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Wed, 22 Mar 2017 14:26:57 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 22 Mar 2017 14:26:57 -0700 Message-ID: Subject: Re: QUIC error codes -- too many *and* too few To: "Aron ." Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1139895494b6af054b586b15 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 21:27:01 -0000 --001a1139895494b6af054b586b15 Content-Type: text/plain; charset=UTF-8 Hi Aron, Yes, this is definitely an issue we want to address going forward. Issue 211 was filed for exactly this. - jana On Wed, Mar 22, 2017 at 10:50 AM, Aron . wrote: > Dear QUICsters, > > I believe that the QUIC protocol specification goes overboard in trying to > have an error code for each error condition. Of course, the roots of this > are historic: since both first client and server use the same code base, it > makes sense to enumerate all possible errors to facilitate debugging. (An > error code like QUIC_MAYBE_CORRUPTED_MEMORY is a good example of this.) > However, as the number of QUIC implementations grows, a list of errors this > long and this specific is, I think, ill-advised. > > My copy of *HTTP: The Definitive Guide (O'Reilly, 2002)* lists a > grand total of eighteen 400-level codes. 15 years later, Wikipedia's > list of HTTP status codes > > has twenty-eight. draft-ietf-quic-transport.md > > has about sixty. What is the client to do with these error codes? It can > probably not do much more than log them. > > On the server side, finding a matching error code for an error condition > would probably be a difficult task, especially if the implementation folds > several checks into one. Other error codes are potential information > leaks, such as some crypto-related codes. > > In regards to having too few error codes, it would be useful to have two > catch-all error codes (like HTTP 400 and 500), one for client errors and > one for server errors, which could be used (something like a MAY in the > spec?) when an appropriate error code does not exist. > > An aspiring QUIC implementer. > > --001a1139895494b6af054b586b15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Aron,

Yes, this is definitely an iss= ue we want to address going forward. Issue 211 was filed for exactly this.
=
- jana

On Wed, Mar 22, 2017 at 10:50 AM, Aron . <aron.schats= @gmail.com> wrote:
Dear=C2=A0QUICsters,

I believe that = the QUIC protocol specification goes overboard in trying to have an error c= ode for each error condition.=C2=A0 Of course, the roots of this are histor= ic: since both first client and server use the same code base, it makes sen= se to enumerate all possible errors to facilitate debugging.=C2=A0 (An erro= r code like QUIC_MAYBE_CORRUPTED_MEMORY<= /font> is a good example of this.)=C2=A0 However, as the number of QUIC imp= lementations grows, a list of errors this long and this specific is, I thin= k, ill-advised.

My copy of HTTP: The Definitiv= e Guide (O'Reilly, 2002) lists a grand=C2=A0total of=C2=A0eighteen= 400-level codes.=C2=A0=C2=A015 years later, W= ikipedia's list of HTTP status codes has twenty-eight.=C2=A0 draft-ietf-quic-transport.md has about sixt= y.=C2=A0 What is the client to do with these error codes?=C2=A0 It can prob= ably not do much more than log them.

On the server= side, finding a matching error code for an error condition would probably = be a difficult task, especially if the implementation folds several checks = into one.=C2=A0 Other error codes are potential information leaks, such as = some crypto-related codes.

In regards to having to= o few error codes, it would be useful to have two catch-all error codes (li= ke HTTP 400 and 500), one for client errors and one for server errors, whic= h could be used (something like a MAY in the spec?) when an appropriate err= or code does not exist.

=C2=A0 An aspiring QUIC im= plementer.


--001a1139895494b6af054b586b15-- From nobody Wed Mar 22 14:43:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC012948D for ; Wed, 22 Mar 2017 14:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9iHocJfaJKa for ; Wed, 22 Mar 2017 14:43:30 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 60EC51294A8 for ; Wed, 22 Mar 2017 14:43:30 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id y76so166374550qkb.0 for ; Wed, 22 Mar 2017 14:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X2tcVWviIBD//u8GMw5wxyudv9PTLmYnWWlsvrnwSAM=; b=GQqHt0bsGALXqfxRJGfwekckvlViGudOOU7FQXCKU0yvl3i2fPAb5pwJFZFKQZHVpr UCHhiVcbc2Cy3LZlsMdGYZsihd2mC2IivRjsCWl8TE3ecjYsqDpVdxs6JxtjAkMYNQEw Oq6VMxXnDurvXkyzR0T1TjGxF5DTmk4F41j8FlNP8RHlgwAbNeqiCk6gK/XhPRyiREmi PgK5lqmJ+eDGNlnKX9vob8dXIoUtH8+hRuMv79+PNNxZjfiK59SqYFeHrVbC6dRy/V7f lK9iU+fV9QYrDPhSCwVWAACFes8HQ5mWNRFc24rMbGxlAJEvKzdUnV9nI2lWJ6qD26rD o85w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X2tcVWviIBD//u8GMw5wxyudv9PTLmYnWWlsvrnwSAM=; b=oD03z2EQmLSLDpHiKoJuN5fr9g9MlPjHrlrtDr7NEmnb+j705gFYk3nMjR/TrAT1yg xemUP2Ag45TLLtoGNaTvuCOCeSXvqhTS8J/ipwdlWKr4FWj4R/D7mrUyXozBeEZewF/9 3i8MFyjXsrAzuv5O3jbpBfjnZO26vvFOswHnRk2gj3cNF/E7wfGtFfUrBMklfBBlrsyu gzNWsNAHQpQIefB8NJdQKj3Ko9Owst4HojPS/7OSREIHu7TpyS2jdHZGxP7IdG+z1D4O 2KxGbcfL5fwiTaBEpk9gv7aaKPK0Z07GV7PBhmbKQ+TSfUnQjD3xGAB2dB0x9vyntZeK Vtcw== X-Gm-Message-State: AFeK/H0IP5AWiF/IPr1xW8IklPwYWvcmU4iZQ/mCPtvOkAwRUR6mhlm52AgCtj+/PPZqWhtqozuPiEeaiOD0mA== X-Received: by 10.55.33.139 with SMTP id f11mr9911723qki.5.1490219009493; Wed, 22 Mar 2017 14:43:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 22 Mar 2017 14:43:28 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 23 Mar 2017 08:43:28 +1100 Message-ID: Subject: Re: QUIC error codes -- too many *and* too few To: Jana Iyengar Cc: "Aron ." , IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 21:43:32 -0000 If anyone wants to come up with a proposal that rationalizes what we have, that would be very welcome. I did that for the TLS draft, which now has just three error codes, but that was easy because TLS provides its own well-established error signaling mechanism. Someone who wanted to help here would have to go through the draft and find those error codes that are actually used by the specification. Then from the remainder, either delete or find justification for each. After that, it might pay to collapse error codes that are too similar. I suspect that we will find the list is much shorter when we are done. On 23 March 2017 at 08:26, Jana Iyengar wrote: > Hi Aron, > > Yes, this is definitely an issue we want to address going forward. Issue 211 > was filed for exactly this. > > - jana > > On Wed, Mar 22, 2017 at 10:50 AM, Aron . wrote: >> >> Dear QUICsters, >> >> I believe that the QUIC protocol specification goes overboard in trying to >> have an error code for each error condition. Of course, the roots of this >> are historic: since both first client and server use the same code base, it >> makes sense to enumerate all possible errors to facilitate debugging. (An >> error code like QUIC_MAYBE_CORRUPTED_MEMORY is a good example of this.) >> However, as the number of QUIC implementations grows, a list of errors this >> long and this specific is, I think, ill-advised. >> >> My copy of HTTP: The Definitive Guide (O'Reilly, 2002) lists a grand total >> of eighteen 400-level codes. 15 years later, Wikipedia's list of HTTP >> status codes has twenty-eight. draft-ietf-quic-transport.md has about >> sixty. What is the client to do with these error codes? It can probably >> not do much more than log them. >> >> On the server side, finding a matching error code for an error condition >> would probably be a difficult task, especially if the implementation folds >> several checks into one. Other error codes are potential information leaks, >> such as some crypto-related codes. >> >> In regards to having too few error codes, it would be useful to have two >> catch-all error codes (like HTTP 400 and 500), one for client errors and one >> for server errors, which could be used (something like a MAY in the spec?) >> when an appropriate error code does not exist. >> >> An aspiring QUIC implementer. >> > From nobody Wed Mar 22 15:37:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104E0127342 for ; Wed, 22 Mar 2017 15:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=FY9CezJq; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=BcKmaNz/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTSbE2UCVgwa for ; Wed, 22 Mar 2017 15:37:06 -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 7B5E912709D for ; Wed, 22 Mar 2017 15:37:06 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2MMDjrG000585 for ; Wed, 22 Mar 2017 15:37:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=WEdW03UhNQYVrBgSguUNRI09VZZyauctET4hkMEYahs=; b=FY9CezJqIR0LLE1dF8HfEKWYp2EK3UvaLVioDbcE1wWEO9ZYTGOOlRMOlFgcR2c3OOeK 5lO/CX6qbUlWWXOijfazW5oCza2ERFAaZkQnDBMOoDldILYxMOuUgiZI8w8yGFyMlfea CW1lcG1tuFSFGoLqaWUJk/g1+k848WTTsVU= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 29bnhq3r6p-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Mar 2017 15:37:05 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 22 Mar 2017 15:37:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WEdW03UhNQYVrBgSguUNRI09VZZyauctET4hkMEYahs=; b=BcKmaNz/hn95tAiqJiRSkhlWRvt/pJ8akGkNdno/cTdeyRvMP+523M0zbFBoytUk2eRfC34I+QocSR+R+PU1IJ5k60NFfgwg5wZCi6AD6fCOpIAGxy4VdBS1VpxZHlYFFC15SROisuTLiUhRZBi+Y/f5a9XTs3jjfMJrnE1vbKw= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1454.namprd15.prod.outlook.com (10.173.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 22:37:02 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0977.020; Wed, 22 Mar 2017 22:37:02 +0000 From: Subodh Iyengar To: "quic@ietf.org" Subject: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjA== Date: Wed, 22 Mar 2017 22:37:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::1:16c7] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 7:2/H+uF5+WFFBE1/arRKxgSi+MzbruAKPyNo3ObLxjQgDjSb+nVancoAhtshj+6cYXzWgJ1TLxmRUbnc0NYKST7dBu/EWJ3uxg6pI4SnQ/hgOrpUq7y2NU+O6VCSRLGsxFBmPmyV1vK4nbMvsgZ7HhiOrt8AidS3LJ3Dhdnl+TJ42kA8GfYmOQ52Zkfj7s/7rw84tl2pghAo+yVMQWgJ5FqoWyS2LpwkU48H8WaT4AoMPADzs0HjCw2uuhE/i6cKlFBRScTQZ4BKB4hIJWDMsYKYEOZoOr/DXUjTOEWHCp27eLipiMJ4hnxyaymLA6bE8rHNeiNeH5EArRHNw/2372Q==; 20:igv2V2KaewPZ5vinh9f9EFqfQdKKqp9MmfTSUOM/d5JDTfglvtHCGAtMD/gcZPCsDtqh6aY2tOTc2AgN7wTOZdmo+RFeSJ9skJFj4W7mCp1SV4nLZQETcbDtbrBNflwesO/FmjM59/rBW0csr2C6PLujrJJrGaBQYpUjYnDUIwc= x-ms-office365-filtering-correlation-id: 781f7a58-134f-46d0-50a2-08d47173f609 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR15MB1454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148)(6042181); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1454; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2351001)(122556002)(19627405001)(74316002)(7736002)(1730700003)(110136004)(8676002)(38730400002)(2900100001)(81166006)(189998001)(6606003)(86362001)(8936002)(3280700002)(6916009)(7696004)(33656002)(5660300001)(9686003)(50986999)(54896002)(2906002)(5640700003)(6436002)(102836003)(2501003)(77096006)(6506006)(99286003)(25786009)(53936002)(55016002)(54356999)(3660700001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455B5E6D4F4FAC8411927E4B63C0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 22:37:02.6413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1454 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-22_19:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 22:37:08 -0000 --_000_MWHPR15MB1455B5E6D4F4FAC8411927E4B63C0MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There might be some strange cases around RSTs and FINs which I would love m= ore clarity on. Let's say that the following actions happen: 1) Client initiates a stream to the server and sends some data 2) Server sends a FIN to the client which the client receives. The client a= nd server are both half closed (remote and local respectively). 3) After some time the client sends a FIN to the server. So it's waiting fo= r the FIN and the ack of all the data before closing the stream. 4) Server sends a RST which races with the client sending the FIN. 5) Client gets a RST >From the draft I think it's ambiguous on what the client is supposed to do "An endpoint that receives a RST_STREAM frame (and which has not sent a FIN= or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUS= T NOT send any more data on the stream" So clearly a client should not send a RST stream in response However: "When an endpoint sends a RST_STREAM frame, data outstanding on that stream= SHOULD NOT be retransmitted, since subsequent data on this stream is expec= ted to not be delivered by the receiver." If the client decides to honor both of these requirements I believe it will= not retransmit the FIN. So if the FIN gets lost the client will have no id= ea whether the server has seen the FIN and reduced its number of streams counting towards the concurrency limit so that the client= can open up a new stream. It would need to track the ACK of the ACK of the= RST stream that the server sends back. Am I missing another requirement that prevents this from being an issue or = could "not sent a FIN" mean that "not sent a FIN that has been ACKed". Subodh --_000_MWHPR15MB1455B5E6D4F4FAC8411927E4B63C0MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There might be some strange cases around RSTs and FINs which I would love m= ore clarity on.

Let's say that the following actions happen:
1) Client initiates a stream to the server and sends some data
2) Server sends a FIN to the client which the client receives. The cli= ent and server are both half closed (remote and local respectively).
3) After some time the client sends a FIN to the server. So it's waiti= ng for the FIN and the ack of all the data before closing the stream.
4) Server sends a RST which races with the client sending the FIN.
5) Client gets a RST

From the draft I think it's ambiguous on what the client is supposed t= o do

"An endpoint= that receives a RST_STREAM frame (and which has not sent a FIN or a RST_ST= REAM) MUST immediately respond with a RST_STREAM frame, and MUST NOT send any more data on the stream"

So clearly a client should not send a RST stream in response

However:
"When an endpoint sends a RST_STREAM frame, data outstanding on that stream SHOULD NOT be retransm= itted, since subsequent data on this stream is expected to not be delivered= by the receiver."

If the client decides to honor both of these requirements I believe&nb= sp;it will not retransmit the FIN. So if the FIN gets lost the client will = have no idea whether the server has seen the FIN and reduced its
number of streams counting towards= the concurrency limit so that the client can open up a new stream. It woul= d need to track the ACK of the ACK of the RST stream that the server sends back.

Am I missing anot= her requirement that prevents this from being an issue or could "not s= ent a FIN" mean that "not sent a FIN that has been ACKed".

Subodh

--_000_MWHPR15MB1455B5E6D4F4FAC8411927E4B63C0MWHPR15MB1455namp_-- From nobody Wed Mar 22 17:44:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1481293E0 for ; Wed, 22 Mar 2017 17:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id surPimVXv5Q8 for ; Wed, 22 Mar 2017 17:44:40 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0134.outbound.protection.outlook.com [104.47.41.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFBB128AB0 for ; Wed, 22 Mar 2017 17:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1Pfu0YpdCoPs8Q8cLeg/ZkieqBpQjuQbZPhImW5eaoI=; b=dIHazEIb8hRPUfoZ/jj/IDhPv6rVHTtahdf//qEycbRC1yRoHstGamtlTJHgJKDrgLAxYS0gvwrcBcmfbHSl1tUkd+1hJzQOy/njjRPzfgiQ1g2wQTTRLBHpmA06288OV7M+me5YPFjxnlsmsyCxh/VI3CYZjQW84LwMkUHnAe4= Received: from CY4PR03MB2710.namprd03.prod.outlook.com (10.173.43.141) by CY4PR03MB2711.namprd03.prod.outlook.com (10.173.43.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 23 Mar 2017 00:44:38 +0000 Received: from CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) by CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) with mapi id 15.01.0947.020; Thu, 23 Mar 2017 00:44:38 +0000 From: Mike Bishop To: Subodh Iyengar , "quic@ietf.org" Subject: RE: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGhlpLf Date: Thu, 23 Mar 2017 00:44:37 +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: fb.com; dkim=none (message not signed) header.d=none;fb.com; dmarc=none action=none header.from=microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [76.181.219.18] x-ms-office365-filtering-correlation-id: 6d7a0519-75ff-4001-5f85-08d47185c8dd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:CY4PR03MB2711; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2711; 7:YdbcQWs8tqgCN0yXY6S/zt9Mh5BmvTYHbv2RptNF/5jkajLRBMa+D5Bhpwx+VRK+xRSA3N+h2bVn4egdX2GSdFRL35sjgS1Zu/s4e3Q3F0WOajTfS+T0MqqHtyqc6neFDew/ArYzk8AwXQn5cAUn4kMnFtkfWd7OGREQF4in/x93DJ9GWfvQQcEyUvD3J4N5v3q2kg2wR3OOVk7daQ8+DKn6K0Sd7Q9P6tid/jl9t1OD6HkXSb5BjqL+v8Bc471Nl6VWX4sLPASuwbw8xs4BbJYWZvPZ7dYguJ8edCQYa4bKqvxkxERAo/BZwUfGnrEycT43rRQteVc4IWE2DJvVaHCOPdIAZwIVqRGGxTu2Pe8= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6042181); SRVR:CY4PR03MB2711; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2711; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(5660300001)(102836003)(3846002)(3280700002)(6116002)(53936002)(8676002)(2501003)(81166006)(8936002)(33656002)(7696004)(2906002)(77096006)(3660700001)(189998001)(19627405001)(2950100002)(6506006)(99286003)(2900100001)(7736002)(236005)(9686003)(55016002)(50986999)(76176999)(38730400002)(86362001)(86612001)(54356999)(10290500002)(74316002)(6246003)(66066001)(8990500004)(229853002)(122556002)(6436002)(5005710100001)(54896002)(10090500001)(25786009)(53546009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2711; H:CY4PR03MB2710.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB2710F1A3096E0988AA6CEDF8873F0CY4PR03MB2710namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 00:44:37.8801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2711 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 00:44:42 -0000 --_000_CY4PR03MB2710F1A3096E0988AA6CEDF8873F0CY4PR03MB2710namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don=92t see these as in conflict. If the client receives a RST when it h= as already sent a FIN, it's not subject to the MUST. It may, of course, op= t to send a RST and abort retransmission. Or, it may choose to just let th= e sent data be, but with the obligation to retransmit it. Its obligation i= s to deliver the final offset, and all data up to that offset if the offset= is in a FIN. (Note that pulling in DISINTEREST or whatever we call it would hopefully cl= arify this, since it removes the requirement to generate a RST_STREAM when = receiving one.) Sent from my Windows 10 phone From: Subodh Iyengar Sent: Wednesday, March 22, 2017 6:37 PM To: quic@ietf.org Subject: FIN + RST behavior There might be some strange cases around RSTs and FINs which I would love m= ore clarity on. Let's say that the following actions happen: 1) Client initiates a stream to the server and sends some data 2) Server sends a FIN to the client which the client receives. The client a= nd server are both half closed (remote and local respectively). 3) After some time the client sends a FIN to the server. So it's waiting fo= r the FIN and the ack of all the data before closing the stream. 4) Server sends a RST which races with the client sending the FIN. 5) Client gets a RST >From the draft I think it's ambiguous on what the client is supposed to do "An endpoint that receives a RST_STREAM frame (and which has not sent a FIN= or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUS= T NOT send any more data on the stream" So clearly a client should not send a RST stream in response However: "When an endpoint sends a RST_STREAM frame, data outstanding on that stream= SHOULD NOT be retransmitted, since subsequent data on this stream is expec= ted to not be delivered by the receiver." If the client decides to honor both of these requirements I believe it will= not retransmit the FIN. So if the FIN gets lost the client will have no id= ea whether the server has seen the FIN and reduced its number of streams counting towards the concurrency limit so that the client= can open up a new stream. It would need to track the ACK of the ACK of the= RST stream that the server sends back. Am I missing another requirement that prevents this from being an issue or = could "not sent a FIN" mean that "not sent a FIN that has been ACKed". Subodh --_000_CY4PR03MB2710F1A3096E0988AA6CEDF8873F0CY4PR03MB2710namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I don=92t see these as in conflict.  If the cli= ent receives a RST when it has already sent a FIN, it's not subject to the = MUST.  It may, of course, opt to send a RST and abort retransmission.&= nbsp; Or, it may choose to just let the sent data be, but with the obligation to retransmit it.  Its obligation is to deliv= er the final offset, and all data up to that offset if the offset is in a F= IN.

 

(Note that pulling in DISINTEREST or whatever we cal= l it would hopefully clarify this, since it removes the requirement to gene= rate a RST_STREAM when receiving one.)

 

Sent from my Windows 10 phone

 

From: Subodh Iyengar
Sent: Wednesday, March 22, 2017 6:37 PM
To: quic@ietf.org
Subject: FIN + RST behavior

 

There might be some strange cases around RSTs and FINs which I would love m= ore clarity on.

Let's say that the following actions happen:
1) Client initiates a stream to the server and sends some data
2) Server sends a FIN to the client which the client receives. The cli= ent and server are both half closed (remote and local respectively).
3) After some time the client sends a FIN to the server. So it's waiti= ng for the FIN and the ack of all the data before closing the stream.
4) Server sends a RST which races with the client sending the FIN.
5) Client gets a RST

From the draft I think it's ambiguous on what the client is supposed t= o do

"An endpoint= that receives a RST_STREAM frame (and which has not sent a FIN or a RST_ST= REAM) MUST immediately respond with a RST_STREAM frame, and MUST NOT send any more data on the stream"

So clearly a client should not send a RST stream in response

However:
"When an endpoint sends a RST_STREAM frame, data outstanding on that stream SHOULD NOT be retransm= itted, since subsequent data on this stream is expected to not be delivered= by the receiver."

If the client decides to honor both of these requirements I believe&nb= sp;it will not retransmit the FIN. So if the FIN gets lost the client will = have no idea whether the server has seen the FIN and reduced its
number of streams counting towards= the concurrency limit so that the client can open up a new stream. It woul= d need to track the ACK of the ACK of the RST stream that the server sends back.

Am I missing anot= her requirement that prevents this from being an issue or could "not s= ent a FIN" mean that "not sent a FIN that has been ACKed".

Subodh

--_000_CY4PR03MB2710F1A3096E0988AA6CEDF8873F0CY4PR03MB2710namp_-- From nobody Wed Mar 22 17:45:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E650128954 for ; Wed, 22 Mar 2017 17:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc2KCeaJ9CWi for ; Wed, 22 Mar 2017 17:45:33 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A27128D19 for ; Wed, 22 Mar 2017 17:45:32 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id x35so163692438qtc.2 for ; Wed, 22 Mar 2017 17:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3yq94Jh+EO/8+PrM2eLN5p1L7QFzf9kJZbNF1ecoZYE=; b=edIdcOgT0sKdD8g2FnntatGyISXOk/3/MYdnvFb5KtxyEcjGe7EN8ise5moTSjL+BI nvR3+qu8QazqzW623FrErmqyGuX6j5zKekcNA8Qi41fQp0fXzEg6Z/pKgkVD7PqI/uuN dZaNexG0zhGMPBUS8yiROHDW/SHo94yYP0e62JlnJIh09ysV837UvUwIzvPPNLBjcOdE uWEy4bS+p0RcfdtSmXt+uhIO95M/OZ7vgAlGLR3Bmbqoa8ngEo65GqBAvYC1Xd5D19jI JvH+HS2cDnU/JLASPt/USk1l3/wPTXkNKEWoJlOzZGRIJxO9uO1ez7/T+1i0ql6qAx93 f1Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3yq94Jh+EO/8+PrM2eLN5p1L7QFzf9kJZbNF1ecoZYE=; b=aPMENRjYIBUISm+fJu8tA56y0G2bnRpPX8ese5numrzJN72UqpZU1qnx8JTvK0i/9q 00sOhFc1SSVe+JVnOXCqz7X7DWWaz97fUcwhXDRE85EKUOQSq3UVX28lmntOwtIWlCQg iWvVAlFap4zwJWPRfuk5I4W5UfqmPQLhnCa9Nz8FKRBlcaPci5BFq/qlab+tm7iyBNYh uB9yW9mRRR4Yh8rd8xYo9lUWU7XfTavgDYnEYidYOPsGN+tPkrUvnmS/tbeF3+M+ShXi 7VrVbxMWvlXQfYSLsFwxsXWEvajSjP/IA1lJ8Bjk8clc7bbt4qExrvxTtfXjARKTxkCF mATQ== X-Gm-Message-State: AFeK/H1riVuMIm5rw1PrsSrGa0jWJBMai1mGpl7svnS6hF08TmFCnfh1dhV60nqa1Sz7YiwiT5Vd/6QqbxRmAQ== X-Received: by 10.200.33.210 with SMTP id 18mr40231234qtz.159.1490229931937; Wed, 22 Mar 2017 17:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 22 Mar 2017 17:45:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 23 Mar 2017 11:45:31 +1100 Message-ID: Subject: Re: FIN + RST behavior To: Subodh Iyengar Cc: "quic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 00:45:35 -0000 This is just an error. Both endpoints need to end their stream in one way or other. The text about not sending a RST_STREAM needs to take into account the fact that any FIN or RST_STREAM that was previously sent ALSO needs to be acknowledged. A sender needs to wait for acknowledgment before transitioning to new states. Receivers just process and acknowledge. I agree that this is poorly documented. Here's the short version: Each endpoint has to end the stream one way or other. This establishes the final data offset for the stream, which is necessary for connection flow control accounting. A stream can be ended by either sending a STREAM frame with the FIN flag set, or a RST_STREAM frame. A stream isn't ended in the sending direction until a packet containing one of those two frames has been acknowledged. An endpoint MAY choose to switch from sending STREAM frames to sending RST_STREAM frames at any time. For the long version, you will have to wait until we get around to fixing https://github.com/quicwg/base-drafts/issues/413 On 23 March 2017 at 09:37, Subodh Iyengar wrote: > There might be some strange cases around RSTs and FINs which I would love > more clarity on. > > Let's say that the following actions happen: > 1) Client initiates a stream to the server and sends some data > 2) Server sends a FIN to the client which the client receives. The client > and server are both half closed (remote and local respectively). > 3) After some time the client sends a FIN to the server. So it's waiting for > the FIN and the ack of all the data before closing the stream. > 4) Server sends a RST which races with the client sending the FIN. > 5) Client gets a RST > > From the draft I think it's ambiguous on what the client is supposed to do > > "An endpoint that receives a RST_STREAM frame (and which has not sent a FIN > or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUST > NOT send any more data on the stream" > > So clearly a client should not send a RST stream in response > > However: > "When an endpoint sends a RST_STREAM frame, data outstanding on that stream > SHOULD NOT be retransmitted, since subsequent data on this stream is > expected to not be delivered by the receiver." > > If the client decides to honor both of these requirements I believe it will > not retransmit the FIN. So if the FIN gets lost the client will have no idea > whether the server has seen the FIN and reduced its > number of streams counting towards the concurrency limit so that the client > can open up a new stream. It would need to track the ACK of the ACK of the > RST stream that the server sends back. > > Am I missing another requirement that prevents this from being an issue or > could "not sent a FIN" mean that "not sent a FIN that has been ACKed". > > Subodh > From nobody Wed Mar 22 21:10:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD113129411 for ; Wed, 22 Mar 2017 21:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=Hs8iqh/R; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CJSSTARj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdR9CvfeQAAV for ; Wed, 22 Mar 2017 21:10:27 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E7E1200C5 for ; Wed, 22 Mar 2017 21:10:27 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2N47xtH017456; Wed, 22 Mar 2017 21:10:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=rhHGz9qJHod316Eq3+V+eklb5hSLAHNjDp65jvP5qkY=; b=Hs8iqh/RWl5p3YlIZG2Oo2w6ccKsD3sDnefzhS/MSx1m1cSgPNovUbnKwAKe7Qb0vRR6 xhSbp2K7PVZ0b0foGmIDGomv9gNUox3/Mg2tpd4Il2snY8O8vZbqIUPW/rkVCuTssCAh z5pb4LkaoS7MojuO2YrZPcbPl7DtwduIKHk= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 29byxf9a1d-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2017 21:10:25 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.14) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 22 Mar 2017 21:10:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rhHGz9qJHod316Eq3+V+eklb5hSLAHNjDp65jvP5qkY=; b=CJSSTARjo3dsPXHmd6DTaWfZzIq2QcOCmDYbOn6F4WdBgwGF7IzF6CPx3LtyY+nnkkuExOGDt6IYozseEGmtygxBMtYckuw/qdWlG2Sz4ZafTmEwJlS9tnhYVCdCClOw/XKHbMDOR9tEbiuyTJbYgs+/yWLYxs1anKoLt8QL818= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 04:10:21 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0977.020; Thu, 23 Mar 2017 04:10:21 +0000 From: Subodh Iyengar To: Martin Thomson CC: "quic@ietf.org" Subject: Re: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGhltKAgAAu7CA= Date: Thu, 23 Mar 2017 04:10:21 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-Mentions: martin.thomson@gmail.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.172.112.132] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:CDUcstSyiPON5+X/LtLOKil61X7skd6MmX7ZzQEWAXlSCqdxLGOG0oL3TOrIBTe37tymX2bGCYCoEh42bcCCE6YGoBUdTZuMfVg7ki9+w4pSX4c+pPizVo6jmjiXBrpG1WrQmOFhAQvM+sakfq12P4RhLdQOJFAcFWZadIb+lOR+ESn9Z2zEK+gUjH59KB3LaKk3jXqhClSnyGS0mRqzDh7PYoYiGG5yZY/q5ddAWln0BJUJ3c2TxIWzp7Ik6jOWtjZNCSFRebdIUEgzmagla86stCWw0avhZzji8vhDcXb0j3M8qthMoRLaC3DB/QGZYGQTGZiiyXa/xrgq5wjavA==; 20:nLcb+DqR0HKKq0BRXTx0p/qcmYqCFr6AbTK7YMXI1Wp2Pw15y4PsXtCwSLCfdGdAdj2NBdfybwYDDLYlWvHmyiwgGZALNzPVV6WR6cfd3lRwmZxEvx7rGPN3gl8c+ppq3Jg4yyOe1BaHstMDdWbrZTCoTHAwYS/WtfWaoDe22MU= x-ms-office365-filtering-correlation-id: 808944f4-26e0-43be-859c-08d471a28633 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR15MB1456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39830400002)(39410400002)(377454003)(24454002)(74316002)(3846002)(102836003)(6116002)(8676002)(6436002)(50986999)(122556002)(7906003)(7736002)(81166006)(66066001)(53546009)(33656002)(54356999)(8936002)(3280700002)(25786009)(76176999)(5660300001)(7696004)(2950100002)(86362001)(9686003)(77096006)(55016002)(6306002)(54896002)(99286003)(53936002)(606005)(6916009)(229853002)(236005)(110136004)(6246003)(6506006)(4326008)(38730400002)(39060400002)(2900100001)(2906002)(189998001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB145521D729498455F923679EB63F0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 04:10:21.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-23_03:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 04:10:30 -0000 --_000_MWHPR15MB145521D729498455F923679EB63F0MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable @Mike Bishop > I don=92t see these as in conflict. If the client receives a RST when it= has already sent a FIN, it's not subject to the MUST. It may, of course, = opt to send a RST and abort retransmission. Or, it may choose to just let = the sent data be, but with the obligation to retransmit it. Its obligation= is to deliver the final offset, and all data up to that offset if the offs= et is in a FIN. To confirm that I'm interpreting you correctly I'm going to try and rephras= e that a bit: The intent of the draft is that if the client receives the RS= T stream and it has already sent a FIN, it should ignore the RST, and perfo= rm retransmission of all the packets as it usually would, even if the serve= r is no longer interested in it. If it wanted to not retransmit the packets= , it should send a RST of it's own. @Martin Thomson > A sender needs to wait for acknowledgment before transitioning to new states. Receivers just process and acknowledge. Ya that's definitely a given. The issue here I was asking about was what if= there would never be an ACK for the FIN because the client decided to abor= t the retransmissions. > Both endpoints need to end their stream in one way or other. That's definitely true but it seems like closing a stream which is not init= iated by you has a different behavior with respect to closing streams initi= ated by you because you need to account for stream concurrency limit and connection flow control window differently. > Here's the short version: Ya this is definitely a very simplistic description of what needs to be don= e when a connection needs to be closed and doesn't account for how to keep = the client + server in sync for the concurrency limit and connection flow control window which is also very important. My questio= n was actually about the latter. This stuff gets hairy fast. For example in a clean close: 1) client sends FIN to server, sever gets FIN 2) Server sends ACK for the client's FIN (client is now half closed local) 2) server sends data and FIN (Server doesn't change state, it waits for the= ACK of all the bytes + FIN) 3) client gets all data and FIN and then ACKs all of it. 4) the client ACK for the server FIN gets lost >From the client's perspective it sent out all the ACKs for the FIN and does= n't know whether they got lost. How does the client know when the server has released a slot in it's concur= rency limit? The server can't immediately release this when it sends out th= e FIN because it still must keep state until it receives all the ACKs for the stream. I think the client need to keep track of the ACK of th= e ACKs of all the server sent bytes in the stream, which would be a bit sad= . Subodh ________________________________ From: Martin Thomson Sent: Wednesday, March 22, 2017 5:45:31 PM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior This is just an error. Both endpoints need to end their stream in one way or other. The text about not sending a RST_STREAM needs to take into account the fact that any FIN or RST_STREAM that was previously sent ALSO needs to be acknowledged. A sender needs to wait for acknowledgment before transitioning to new states. Receivers just process and acknowledge. I agree that this is poorly documented. Here's the short version: Each endpoint has to end the stream one way or other. This establishes the final data offset for the stream, which is necessary for connection flow control accounting. A stream can be ended by either sending a STREAM frame with the FIN flag set, or a RST_STREAM frame. A stream isn't ended in the sending direction until a packet containing one of those two frames has been acknowledged. An endpoint MAY choose to switch from sending STREAM frames to sending RST_STREAM frames at any time. For the long version, you will have to wait until we get around to fixing https://github.com/quicwg/base-drafts/issues/413 On 23 March 2017 at 09:37, Subodh Iyengar wrote: > There might be some strange cases around RSTs and FINs which I would love > more clarity on. > > Let's say that the following actions happen: > 1) Client initiates a stream to the server and sends some data > 2) Server sends a FIN to the client which the client receives. The client > and server are both half closed (remote and local respectively). > 3) After some time the client sends a FIN to the server. So it's waiting = for > the FIN and the ack of all the data before closing the stream. > 4) Server sends a RST which races with the client sending the FIN. > 5) Client gets a RST > > From the draft I think it's ambiguous on what the client is supposed to d= o > > "An endpoint that receives a RST_STREAM frame (and which has not sent a F= IN > or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MU= ST > NOT send any more data on the stream" > > So clearly a client should not send a RST stream in response > > However: > "When an endpoint sends a RST_STREAM frame, data outstanding on that stre= am > SHOULD NOT be retransmitted, since subsequent data on this stream is > expected to not be delivered by the receiver." > > If the client decides to honor both of these requirements I believe it wi= ll > not retransmit the FIN. So if the FIN gets lost the client will have no i= dea > whether the server has seen the FIN and reduced its > number of streams counting towards the concurrency limit so that the clie= nt > can open up a new stream. It would need to track the ACK of the ACK of th= e > RST stream that the server sends back. > > Am I missing another requirement that prevents this from being an issue o= r > could "not sent a FIN" mean that "not sent a FIN that has been ACKed". > > Subodh > --_000_MWHPR15MB145521D729498455F923679EB63F0MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
@Mike Bishop
> I don=92t see these as in conflict.  If the client receives a RST when= it has already sent a FIN, it's not subject to the MUST.  It may, of = course, opt to send a RST and abort retransmission.  Or, it may choose= to just let the sent data be, but with the obligation to retransmit it.  Its obligation is to deliver the final offset, and= all data up to that offset if the offset is in a FIN.

To confirm that I'm interpreting you correctly I'm going to try and rephras= e that a bit: The intent of the draft is that if the client receives t= he RST stream and it has already sent a FIN, it should ignor= e the RST, and perform retransmission of all the packets as it usually would, even if the server is no longer interested in it. If = it wanted to not retransmit the packets, it should send a RST of it's own.<= br>
@Martin Thomson
>  A sende= r needs to wait for acknowledgment before transitioning to new
states.  Rece= ivers just process and acknowledge.
Ya that's definitely a given. The issue here I was asking about was what if= there would never be an ACK for the FIN because the client decided to abor= t the retransmissions.

>  Both endpoints need to end their stream in one
way or other. = ;
That's definitely true but it seems like closing a stream which is not init= iated by you has a different behavior with respect to closing streams initi= ated by you because you need to account for
stream concurrency limit and connection flow control win= dow differently.

> Here's the short version:
Ya this is definitely a very simplistic description of what needs to be don= e when a connection needs to be closed and doesn't account for how to keep = the client + server in sync for the concurrency limit
and connection flow control window which is also ve= ry important. My question was actually about the latter.

This stuff gets hairy fast. 

For example in a clean close:
1) client sends FIN to server, sever gets FIN
2) Server sends ACK for the client's FIN (client is now half closed local)<= /div>
2) server sends data and FIN (Server doesn't change state, it waits fo= r the ACK of all the bytes + FIN)
3) client gets all data and FIN and then ACKs all of it.
4) the client ACK for the server FIN gets lost

From the client's perspective it s= ent out all the ACKs for the FIN and doesn't know whether they got lost. How does the client know = when the server has released a slot in it's concurrency limit? The= server can't immediately release this when it sends out the FIN because it still must keep state until it receives al= l the 
ACKs for the stream. I think the c= lient need to keep track of the ACK of the ACKs of all the server sent=  bytes in the stream, which would be a bit sad.

Subodh


From: Martin Thomson <= martin.thomson@gmail.com>
Sent: Wednesday, March 22, 2017 5:45:31 PM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior
 
This is just an error.  Both endpoints need t= o end their stream in one
way or other.  The text about not sending a RST_STREAM needs to take into account the fact that any FIN or RST_STREAM that was previously
sent ALSO needs to be acknowledged.

A sender needs to wait for acknowledgment before transitioning to new
states.  Receivers just process and acknowledge.

I agree that this is poorly documented.  Here's the short version:

Each endpoint has to end the stream one way or other.  This
establishes the final data offset for the stream, which is necessary
for connection flow control accounting.  A stream can be ended by
either sending a STREAM frame with the FIN flag set, or a RST_STREAM
frame.  A stream isn't ended in the sending direction until a packet containing one of those two frames has been acknowledged.  An endpoint=
MAY choose to switch from sending STREAM frames to sending RST_STREAM
frames at any time.

For the long version, you will have to wait until we get around to
fixing https:/= /github.com/quicwg/base-drafts/issues/413

On 23 March 2017 at 09:37, Subodh Iyengar <subodh@fb.com> wrote:
> There might be some strange cases around RSTs and FINs which I would l= ove
> more clarity on.
>
> Let's say that the following actions happen:
> 1) Client initiates a stream to the server and sends some data
> 2) Server sends a FIN to the client which the client receives. The cli= ent
> and server are both half closed (remote and local respectively).
> 3) After some time the client sends a FIN to the server. So it's waiti= ng for
> the FIN and the ack of all the data before closing the stream.
> 4) Server sends a RST which races with the client sending the FIN.
> 5) Client gets a RST
>
> From the draft I think it's ambiguous on what the client is supposed t= o do
>
> "An endpoint that receives a RST_STREAM frame (and which has not = sent a FIN
> or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and= MUST
> NOT send any more data on the stream"
>
> So clearly a client should not send a RST stream in response
>
> However:
> "When an endpoint sends a RST_STREAM frame, data outstanding on t= hat stream
> SHOULD NOT be retransmitted, since subsequent data on this stream is > expected to not be delivered by the receiver."
>
> If the client decides to honor both of these requirements I believe it= will
> not retransmit the FIN. So if the FIN gets lost the client will have n= o idea
> whether the server has seen the FIN and reduced its
> number of streams counting towards the concurrency limit so that the c= lient
> can open up a new stream. It would need to track the ACK of the ACK of= the
> RST stream that the server sends back.
>
> Am I missing another requirement that prevents this from being an issu= e or
> could "not sent a FIN" mean that "not sent a FIN that h= as been ACKed".
>
> Subodh
>
 --_000_MWHPR15MB145521D729498455F923679EB63F0MWHPR15MB1455namp_-- From nobody Thu Mar 23 04:04:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9CB131589 for ; Thu, 23 Mar 2017 04:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rjLiO2UTDYjD for ; Thu, 23 Mar 2017 04:04:51 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917D613158B for ; Thu, 23 Mar 2017 04:04:47 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y76so176467312qkb.0 for ; Thu, 23 Mar 2017 04:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=22sNuSbGLXrWGPFZn8VOnKDgvMnVX0SZma7zMqEl+AI=; b=T+GL+Ay27/ZZ4gcf1+7shilPeCO2QsB6oReLbbnBFgnGaEVwEbm9JSWoZ9fPlavTun 0osiZI4pNNQrJu4ISpXiEzAamvDbK7CBU6SUnU5L/PnXWtXsBLQTDeclaKUiyc6Jmk1L QGK/hE0zLIbhJLjJw4jHLG/2YZL7+8FJQ6U1Bj7pfCmp9uFwkFSeijGq1xXFnsI6fNTL bW/xl9m4RKkyTy9yW4Es1P4wkVq4ehKOy1crbH6EEo0KDUn+5OK/7oIn1QRDXLqZBDjW ECr4NUNZIY4VGEygny7AzTH2TsnK7rN61Sjk5m7qmSynTYOA7OHH0GWacTr1lD5QqWjR RW2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=22sNuSbGLXrWGPFZn8VOnKDgvMnVX0SZma7zMqEl+AI=; b=nc7g7oYdQhI9QuNn93GgYCUD9e/j40c85u4NEL7FObL/TYiiUhNGh4fLipdyfx8jFn cRLKgo8AuceStBDCN8wBoZNwEsA8p12idL6lei/ZBqXQbSiYRkwLGA3y01iFisTHxDnG xaTIJB89lSdl4iSiy/MD04g5f6NQ9KGXhqaB6gVFYQHJLfpj2ejVGGSDl+toVms7Qzmw rmIIMgK3U28TarDMdUDEY/gWouzc4ujLYcjFRs9vHGg4GIpv28kt6gbXZ57bf7TBtEXx j54u/idRCVVB7IJ1Vl+GKGB6VAGB4SkTI5Kv+YgIXHSlLNegmP7BarAkdc+DQHWRmvZN m0hw== X-Gm-Message-State: AFeK/H0g5IfdNoP7Ke58qos0zkP4h52dT6iqSbE3r8/r4QSUpQLe5hZcuH7m5korXLfZDolDcjbgKj2vpDT17A== X-Received: by 10.55.122.134 with SMTP id v128mr1442139qkc.115.1490267086703; Thu, 23 Mar 2017 04:04:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 23 Mar 2017 04:04:46 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 23 Mar 2017 22:04:46 +1100 Message-ID: Subject: Re: FIN + RST behavior To: Subodh Iyengar Cc: "quic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 11:04:53 -0000 On 23 March 2017 at 15:10, Subodh Iyengar wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it sends > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of the > ACKs of all the server sent bytes in the stream, which would be a bit sad. The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. From nobody Thu Mar 23 05:26:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CF1315BC for ; Thu, 23 Mar 2017 05:26:49 -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, RP_MATCHES_RCVD=-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 q31tuadMtE-n for ; Thu, 23 Mar 2017 05:26:46 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EDA1315D2 for ; Thu, 23 Mar 2017 05:26:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vpm4n2sK2z15Ndh; Thu, 23 Mar 2017 13:26:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA7uYi88x--c; Thu, 23 Mar 2017 13:26:31 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC22AF.dip0.t-ipconnect.de [93.236.34.175]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 23 Mar 2017 13:26:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00 From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 23 Mar 2017 13:26:30 +0100 Cc: Christian Huitema , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <59A08C0B-2AD3-4369-8274-F9E6B548D18B@tik.ee.ethz.ch> References: <8F3C60B8-BB54-422A-8E48-747CE3F43CC0@tik.ee.ethz.ch> <58b235ad-a9bb-d453-0157-f874687ae241@tik.ee.ethz.ch> <771e4500-02bc-53cc-fb3c-543c9ebc39e2@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 12:26:49 -0000 I think one thing we easily can say it that if you fall back to TCP, you = MUST fallback to TLS over TCP. > Am 22.03.2017 um 01:34 schrieb Martin Thomson = : >=20 > On 22 March 2017 at 10:30, Christian Huitema = wrote: >> I am not sure that security expectations for DNS over QUIC should be >> lower. I would expect DNS over QUIC to match the security of DNS over >> TLS (RFC 7858). >=20 > I did assumed that that did not exist, which might be unfair. >=20 >> We need consider the "game theory" aspects of any downgrade. If we = allow >> fall back to a non encrypted alternative, then we reward the = attackers. >> They block QUIC, observe the protocol silently switching to clear = text, >> get access to the data that they are seeking, and all that without >> causing too many customer complaints. On the other hand, if blocking >> QUIC just blocks the service, customers will complain, to the service >> providers of course, but also very quickly to the intermediaries that >> set the block. For these blockers, the support cost will be much = higher. >> And that means they will be less likely to block random services. >=20 > An excellent point. Though you are condoning a denial of service > attack of a sort. Not sure where I stand on the morality of that. >=20 From nobody Thu Mar 23 10:09:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB001294BD for ; Thu, 23 Mar 2017 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=lDlA1gfN; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=WDh/Su5l Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHfpbMKbwDnJ for ; Thu, 23 Mar 2017 10:09:17 -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 D60D012998C for ; Thu, 23 Mar 2017 10:09:16 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2NH3Iss008333; Thu, 23 Mar 2017 10:09:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=4xydGK5qKjapcZt3kU3d6YGR6qoUdSlhx8JFpORA/k8=; b=lDlA1gfN0J65777byzhVlzCF3Hdu5I9+nZMsxyBM6JHaUQ03Ef8Y9PDi3bIrhIcm9Pmw GEAtvpATX3XU0XYGa7ok8epJEVQGkbK3rKIJWAjHQsoL39MFVTlwevtBcon5m2JX9HZa hqRZGPD5qJzQqRfMs0a9zFlhvxdNRErZq5E= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 29ca0tjc8k-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2017 10:09:15 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.14) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 23 Mar 2017 10:09:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4xydGK5qKjapcZt3kU3d6YGR6qoUdSlhx8JFpORA/k8=; b=WDh/Su5lpCVFu1m1AEudX1vN8QcUMISuUaXD0GVoH36r3wNoEe6OVAeySnYDYYoJUwmvNfTxNOHJFU3Sc74vy4Augq4CN7qJXA5qOujo3/ZyrGzCs9SaKC1bhMMxnguQG/9Gt2uovRBF1+qIBTQiOsuWRiCD6QQu6sRNyxcvZ9Q= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1454.namprd15.prod.outlook.com (10.173.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Thu, 23 Mar 2017 17:09:11 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0977.021; Thu, 23 Mar 2017 17:09:11 +0000 From: Subodh Iyengar To: Martin Thomson CC: "quic@ietf.org" Subject: Re: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGhltKAgAAu7CCAAH4YAIAAZDLN Date: Thu, 23 Mar 2017 17:09:11 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-Mentions: martin.thomson@gmail.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 7:QlRUqPgjdHzr1T5Gmw+/sKhHTA3fdWtlat0u1yGZaKl3lBGMrsviT6nZzYCXJSfmhnSmp2OHnj2T9O5+ksMPUackNczO0ml487I7eOVBm803i03nH8oi+Ullr+ARWk3bCREZjsSNAKHlDFhTIc3DFIUqo6EDYq7LzbAHSYbwX+FN2fbeSByPM/K4n/QPeFF7FxDKZeH0cgfkYx751jyGIV89OamqaSkeNWwqjo+kUcOwZANieggjWPBnDVSsdJj1R8V4r8L0BgoZItKF+DgC/hie7M8+gxUPRl0nUBrsZzv5sSEQceam/QP4WzwuUEH8/jWAmnrKBfXCEi1l2d/z6g==; 20:uNmhlm11M36iJRqMXEOaSwNkxShi7vh8FkJicpfPJ8M3OXRWRSyhxQ/p2kIMI0TrfH06Zq3aTyaOKvPowSlkL1b3j4WrNkyikdFBOxtLbyu/RM0Jnoyd6eeDsT3GxGtTH88vI3WzVV24Fy/Nsk8/4kx3mfjo+CV1ECwczGK+KCo= x-ms-office365-filtering-correlation-id: c0734e48-41a7-48f1-3300-08d4720f53a2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR15MB1454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(6072148); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1454; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39830400002)(377454003)(24454002)(3846002)(54896002)(236005)(122556002)(39060400002)(99286003)(55016002)(102836003)(9686003)(6116002)(110136004)(6246003)(6506006)(6436002)(4326008)(8936002)(8676002)(25786009)(81166006)(53936002)(53546009)(77096006)(38730400002)(3280700002)(93886004)(86362001)(2900100001)(74316002)(3660700001)(7736002)(2906002)(561944003)(54356999)(76176999)(33656002)(50986999)(66066001)(5660300001)(6916009)(2950100002)(189998001)(7696004)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455956FFF7AB6730C1E345CB63F0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 17:09:11.8016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1454 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-23_15:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 17:09:19 -0000 --_000_MWHPR15MB1455956FFF7AB6730C1E345CB63F0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. Ya in the case of the previous example, it is a server resource since it's = a client initiated stream. @Martin Thomson I'm starting to like your = proposal of unidirectional streams more and more :) Subodh ________________________________ From: QUIC on behalf of Martin Thomson Sent: Thursday, March 23, 2017 4:04:46 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior On 23 March 2017 at 15:10, Subodh Iyengar wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it send= s > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of = the > ACKs of all the server sent bytes in the stream, which would be a bit sad= . The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. --_000_MWHPR15MB1455956FFF7AB6730C1E345CB63F0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>  The = client can consider its own resources to be available for use by
the server as soon= as it receives the FIN and processes it.  If this
were a server reso= urce, then you are right, it's not that simple
because the client= can't assume that the server has released state
yet.

Ya in the case of the previous example, it is a server resource s= ince it's a client initiated stream. 
@Martin Thomson I'm starting to li= ke your proposal of unidirectional streams more and more :)


Subodh


From: QUIC <quic-bounc= es@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>= ;
Sent: Thursday, March 23, 2017 4:04:46 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior
 
On 23 March 2017 at 15:10, Subodh Iyengar <subo= dh@fb.com> wrote:
> How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it s= ends
> out the FIN because it still must keep state until it receives all the=
> ACKs for the stream. I think the client need to keep track of the ACK = of the
> ACKs of all the server sent bytes in the stream, which would be a bit = sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

 --_000_MWHPR15MB1455956FFF7AB6730C1E345CB63F0MWHPR15MB1455namp_-- From nobody Thu Mar 23 10:52:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036A11315EE for ; Thu, 23 Mar 2017 10:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVC3DC_Vz5ai for ; Thu, 23 Mar 2017 10:52:19 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0126.outbound.protection.outlook.com [104.47.42.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB36C129B5C for ; Thu, 23 Mar 2017 10:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=keETf/cKI19Uwo8xbb4VuT0ixdPg7szGIteT8ziu1O0=; b=OH89ZXUhzhNKYtbMsFawRb+aX16pYb1jE/eVxjoLSJT1h12B0s4WCAUHLxt9+XOr9vUgM7DeZiQEBEHLn32z0+xPVWuhbzjmia1XhSEuhO8ZugsfbNXNdjPn7wp57kGvZC8uPjqBx/3cQPRXXvWhm4NswiH76rQW9QRD8hjDmW0= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 23 Mar 2017 17:52:03 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 17:52:03 +0000 From: Mike Bishop To: Charles 'Buck' Krasic CC: Stefan Eissing , Martin Thomson , IETF QUIC WG Subject: RE: Core drafts -02 out Thread-Topic: Core drafts -02 out Thread-Index: AQHSnFW3hRyMfx+c6Ueu2fks77hV8qGV5bGAgAA4O1CACceVgIAC0r5g Date: Thu, 23 Mar 2017 17:52:03 +0000 Message-ID: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [76.181.219.18] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:vR4H0r83tTjkFSDIvowjVpCTbeewj5PZk+MR46pZYCoCT4FmTSWuGRZ/fUG/HydD6rE+3oSgfPwpKxuXUr33fLvyBkq3VP0oeYS01a0+QH4bhL66QnJ7u3wCsmAOUIwQHO8OZUKr9CYyGQ12OL/VhZ+DCp8xboz2DMHj7znaTjdf8HEuHDzCBAeordeiftAh9Ts7fWAQoe1D3VHidECPdXxbqKFTg2u8tIBAxTFhdiVKGWlm07EYulijpnV7hbQ8aHbUxqcUvKfhjH1a53QXAYnxRFLZAl0UiONUAGOX3XhGbdvvOV4hFTyRYWqZDr8YnfwlnwwhS6rAcCzpPnDp/K3/OrFMLDa+sFloGyLaGBs= x-ms-office365-filtering-correlation-id: cc784169-2d9c-40a3-b85d-08d472155046 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39850400002)(39410400002)(39840400002)(39450400003)(24454002)(377454003)(51914003)(13464003)(57704003)(6916009)(66066001)(86612001)(5005710100001)(2950100002)(25786009)(74316002)(7696004)(53546009)(93886004)(10090500001)(8936002)(54356999)(7906003)(50986999)(76176999)(7736002)(6246003)(6116002)(8676002)(81166006)(122556002)(3846002)(790700001)(102836003)(2900100001)(110136004)(229853002)(189998001)(53936002)(606005)(8990500004)(1680700002)(6436002)(561944003)(6506006)(39060400002)(10290500002)(3280700002)(19609705001)(3660700001)(77096006)(53386004)(5660300001)(38730400002)(55016002)(7116003)(2906002)(86362001)(99286003)(9686003)(236005)(6306002)(4326008)(54896002)(54906002)(966004)(33656002)(376185003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708B2829B54BFF5DE1DA82C873F0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 17:52:03.1367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 17:52:24 -0000 --_000_BN6PR03MB2708B2829B54BFF5DE1DA82C873F0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsIEkgc2VlIGluIHRoZSBsaW5rcyBhcmUgaHR0cDovLyBhbmQgdGhlIGRyYWZ0IG5hbWUsIG5v IGhvc3QuICBJ4oCZbSBndWVzc2luZyB5b3UgbWVhbnQgaHR0cHM6Ly9naXRodWIuY29tL2tyYXNp Yy9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay9ibG9iL21hc3Rlci9kcmFmdC1rcmFzaWMtcXVpYy1o cGFjay0wMC5odG1sPyAgT25jZSB0aGUgdHJhY2tlciByZW9wZW5zIChzb21ldGltZSBTdW5kYXks IEkgdGhpbmspIHlvdSBzaG91bGQgcHJvYmFibHkgdXBsb2FkIHRob3NlIGF0IGRhdGF0cmFja2Vy LmlldGYub3JnIHRvIG1ha2UgaXQgYW4gb2ZmaWNpYWwgc3VibWlzc2lvbi4gIFlvdeKAmWxsIG5l ZWQgdG8gbWFrZSB0aGUgZHJhZnQgbmFtZSBpbiB0aGUgZmlsZSBtYXRjaCB0aGUgZmlsZSBuYW1l IGJlZm9yZSBpdCB3aWxsIHN1Y2Nlc3NmdWxseSB1cGxvYWQuDQoNCkFsc28sIGZvciBlYXNlIG9m IGRpc2N1c3Npb24sIHlvdSBtaWdodCBwaWNrIGEgZGlmZmVyZW50IG5hbWUgdGhhbiBRUEFDSywg c2luY2UgdGhlcmXigJlzIGFscmVhZHkgYSBkcmFmdCB3aXRoIHRoYXQgbmFtZS4gIChPciB3ZSBi b3RoIGNoYW5nZSBuYW1lcywgYW5kIGNhbGwgdGhlIGV2ZW50dWFsbHktYWRvcHRlZCBvbmUgUVBB Q0s7IHRoYXTigJlkIGJlIGZpbmUsIHRvby4pDQoNCkFzIHRvIGFjdHVhbCBmZWVkYmFjazogIEkg c2VlIHdoYXQgeW914oCZcmUgZ2V0dGluZyBhdCBoZXJlIGJlY2F1c2UgeW914oCZdmUgZXhwbGFp bmVkIGl0IOKAkyB0aGUgZGVjb2RlciBhY2tub3dsZWRnZXMgdGhlIHNlcXVlbmNlIG51bWJlciBp dOKAmXMgdXAgdG8sIHRoZW4gdGhlIGVuY29kZXIgdHJhY2tzIHRoYXQgYW5kIHVzZXMgaXQgb24g dGhlIGVuY29kZSBzaWRlLiAgSSB0aGluayBJ4oCZZCBoYXZlIGEgcmVhbGx5IGhhcmQgdGltZSBw YXJzaW5nIHRoZSBkb2N1bWVudCB3aXRob3V0IHRoYXQuICBJIHRoaW5rIHRoZSBzdHJvbmdlc3Qg YWR2YW50YWdlIG9mIHRoaXMgcHJvcG9zYWwgaXMgdGhhdCBhbiBlbmNvZGVyIGZvciB0aGlzIHNj aGVtZSBjb3VsZCBiZSB1c2VkIG92ZXIgSFRUUC8yLCBlbmFibGluZyBzaGFyZWQgY29kZTsgeW91 IHNob3VsZCBicmluZyB0aGF0IG91dCBtb3JlLg0KDQpUaGUgd2F5IHlvdeKAmXZlIGRlc2NyaWJl ZCB0aGUgZW5jb2RlciByZXF1aXJlcyB0aWdodCBpbnRlZ3JhdGlvbiBiZXR3ZWVuIHRoZSBwYWNr ZXRpemF0aW9uIGxvZ2ljIGFuZCB0aGUgaGVhZGVyIGNvbXByZXNzb3IgaW4gdHdvIHdheXM6DQoN CiAgKiAgIEl0IG5lZWRzIHRvIGtub3cgdGhlIOKAnHBhY2tldCBlcG9jaOKAnSAoZW5jb2RlIGVw b2NoIG9mIHRoZSBmaXJzdCBmcmFtZSBpbiB0aGUgY3VycmVudCBwYWNrZXQpIHdoaWxlIGNvbXBy ZXNzaW5nLCBidXQgdW50aWwgeW91IGtub3cgdGhlIHNpemUgb2YgdGhlIGNvbXByZXNzZWQgb3V0 cHV0LCB5b3UgY2Fu4oCZdCBrbm93IHdoZXRoZXIgaXQgd2lsbCBmaXQgaW4gdGhlIGN1cnJlbnQg cGFja2V0LiAgVGhhdCBpbiB0dXJuIG1lYW5zIHlvdeKAmWxsIG5lZWQgdG8gcm9sbCBiYWNrIGFu eSBzdGF0ZSBhbmQgcmUtZW5jb2RlIHdpdGggYSBkaWZmZXJlbnQgcGFja2V0IGVwb2NoIGlmIGl0 IHR1cm5zIG91dCBub3QgdG8gZml0Lg0KICAqICAgVGhlIOKAnGNvbW1pdCBlcG9jaOKAnSBpcyBk ZXRlcm1pbmVkLCBub3QgYnkgZGF0YSBhdCB0aGUgY29tcHJlc3NvciBsZXZlbCwgYnV0IGJ5IHJl YWNoaW5nIGludG8gdGhlIHRyYW5zcG9ydCBhbmQgY2hlY2tpbmcgd2hpY2ggcGFja2V0cyBjb250 YWluaW5nIHRoZSBTVFJFQU0gZnJhbWVzIGNvbnRhaW5pbmcgdGhlIEhQQUNLIGRhdGEgaW4gcXVl c3Rpb24gaGF2ZSBiZWVuIGFja25vd2xlZGdlZC4gIEFsc28gbm90ZSB0aGF0IEFDSyBkb2VzbuKA mXQgc2lnbmlmeSBkZWxpdmVyeSB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgKEhUVFApLCBqdXN0 IHByZXNlbmNlIGluIHRoZSBhcHByb3ByaWF0ZSBxdWV1ZS4NCg0KSW4gMi4yLjEuMSwgdGhlIGVu Y29kZXIgaXMgaW5mb3JtZWQgd2hldGhlciDigJxRUEFDSyBpcyBlbmFibGVkLOKAnSBidXQgc2lu Y2UgdGhhdCBjYW4gYmUgdG9nZ2xlZCBvbi9vZmYgb24gYSBwZXItaGVhZGVyLWZyYW1lIGJhc2lz IChhbmQgSSBob3BlIHlvdSByZWFsbHkgbWVhbnQgcGVyLWhlYWRlci1ibG9jayksIGl0IHNlZW1z IGxpa2UgdGhlIGRlY29kZXIgaXMganVzdCBmb2xsb3dpbmcgdGhlIGVuY29kZXLigJlzIGxlYWQg b24gdGhpcy4gIFdob+KAmXMgYWN0dWFsbHkgbWFraW5nIHRoYXQgZGVjaXNpb24/ICBZb3Ugc2F5 IGl0IGdldHMgdHVybmVkIG9mZiBpZiBhIGRyb3AgcmVzdWx0cywgYnV0IHRoZSBlbmNvZGVyIGlz IHRoZSBvbmUgd2hvIGtub3dzL2RldGVybWluZXMgdGhhdC4NCg0KVGhpcyBoYXMgdGhlIHNhbWUg cHJvYmxlbSBhcyB0aGUgY3VycmVudCBIUEFDSyBzdGF0ZSB0aGF0IFJTVCBvbiBhIGNvbnRyb2wg c3RyZWFtIGxvc2VzIGNyaXRpY2FsIGRhdGEgYW5kIHRoZXJl4oCZcyBubyB3YXkgdG8gcmVjb3Zl ci4gIEnigJltIHBlcnNvbmFsbHkgaG9waW5nIHdlIGNhbiBtYWtlIG91ciB3YXkgb3V0IG9mIHRo YXQgcmVxdWlyZW1lbnQuDQoNCkZyb206IENoYXJsZXMgJ0J1Y2snIEtyYXNpYyBbbWFpbHRvOmNr cmFzaWNAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDIxLCAyMDE3IDY6MDQgUE0N ClRvOiBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4NCkNjOiBTdGVm YW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT47IE1hcnRpbiBUaG9tc29u IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogQ29yZSBkcmFmdHMgLTAyIG91dA0KDQpIaSBGb2xrcy4NCg0KSSd2ZSBw dXQgdG9nZXRoZXIgYSBmaXJzdCBhdHRlbXB0IGF0IG15IFFQQUNLIHByb3Bvc2FsOg0KDQpkcmFm dC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sPGh0dHA6Ly9kcmFmdC1rcmFzaWMtcXVpYy1ocGFj ay0wMC5odG1sPg0KZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAudHh0PGh0dHBzOi8va3Jhc2lj LmdpdGh1Yi5pby9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay9kcmFmdC1rcmFzaWMtcXVpYy1ocGFj ay0wMC50eHQ+DQoNCkFwb2xvZ2llcyBpbiBhZHZhbmNlLCB0aGlzIGlzIG15IGZpcnN0IGF0dGVt cHQgYXQgYW4gSUVURiBkcmFmdC4NCg0KDQpPbiBXZWQsIE1hciAxNSwgMjAxNyBhdCAxMDozNyBB TSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr IQ0KDQpZZXMsIHlvdSd2ZSBydW4gc3RyYWlnaHQgaW50byB0aGUgYmlnIHF1YW5kYXJ5IHdpdGgg SFBBQ0suICBJIGRvbid0IHRoaW5rIGFueW9uZSBleHBlY3RzIHRoYXQgd2Ugd2lsbCBzaGlwIHRo aXMgd2F5OyBJIGhhdmUgYSBwcm9wb3NhbCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2sgZm9yIGFuIEhQQUNLLXJlcGxhY2VtZW50 IHRoYXQgd291bGQgc29sdmUgbWFueSBvZiB0aGVzZS4gIEJ1Y2sgS3Jhc2ljIGhhcyBhIHByb3Bv c2FsIHdoaWNoIGhlIGhhcyBza2V0Y2hlZCBpbiBlLW1haWwgYnV0IG5vdCBzdWJtaXR0ZWQgYXMg YSBkcmFmdC4gIFRoZSBtYWluIHBvaW50IG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIgd2FzIHRvIGdl dCB1cyBvZmYgdGhlICJldmVyeXRoaW5nIG9uIHN0cmVhbSAzIiBtb2RlbCBhbmQgbGV0IHVzIHNv cnQgb3V0IHRoZSBwcm9ibGVtcyBvZiBIUEFDSyBsYXRlci4gICMyMjggdHJhY2tzIGZpeGluZyBI UEFDSywgaW4gd2hhdGV2ZXIgZm9ybSB0aGF0IHRha2VzLg0KDQpXZSBjb3VsZCBzb2x2ZSBpdCBp biB0aGUgc2FtZSB3YXkgdGhhdCB3ZSBkaWQgUFJJT1JJVFksIGJ5IGFkZGluZyBhbiAiYWZmZWN0 ZWQgc3RyZWFtIG51bWJlciIgZmllbGQgYW5kIG1vdmluZyB0aGUgSEVBREVSUy9QVVNIX1BST01J U0UgZnJhbWVzIHRvIFN0cmVhbSAzIGFzIHdlbGwuICBIb3dldmVyLCB0aGF0IGlzIGp1c3QgYXMg YmxvY2tpbmcgYXMgdGhlIGN1cnJlbnQgYXBwcm9hY2gsIHNvIG5vdCByZWFsbHkgYW4gaW1wcm92 ZW1lbnQuICBXb3JzZSwgdGhlIHJlYXNvbiB3ZSBjYW4gdG9sZXJhdGUgbGFyZ2UgaGVhZGVyIGZy YW1lcyBpcyBiZWNhdXNlIHRoZXkgb2NjdXIgb24gdGhlaXIgb3duIHN0cmVhbXMgYW5kIGRvbid0 IGJsb2NrIGFycml2YWwgb2YgZGF0YSBmcm9tIG90aGVyIHN0cmVhbXMuICBJZiBhbGwgaGVhZGVy cyBvY2N1ciBvbiBhIHNpbmdsZSBzdHJlYW0sIHRoYXQncyBub3QgdHJ1ZSAtLSB5b3UgKmFyZSog YmxvY2tpbmcgbXV4aW5nIG9mIG90aGVyIHN0cmVhbXMgYWdhaW4uDQoNCkkgbGlrZSB0aGUgY29t cGFyaXNvbiB0byBjb25jdXJyZW50IGVkaXRzLiAgV2UndmUgZGlzY3Vzc2VkIGhhdmluZyByb2xs aW5nIGRlbHRhcyBpbiB2YXJpb3VzIG1lY2hhbmlzbXM7IHRoZSBwcm9ibGVtIGlzIHRoYXQgaXQg cmVxdWlyZXMgcmVhY2hpbmcgaW50byB0aGUgdHJhbnNwb3J0IGZvciBBQ0sgc3RhdGUgdG8gZmln dXJlIG91dCB3aGVuIHlvdSBjYW4gZGlzY2FyZCBvbGQgZGVsdGFzIGZvciBnb29kIG9uIHRoZSBy ZWNlaXZlciBzaWRlLiAgQnVjaydzIHByb3Bvc2FsIGlzIHNpbWlsYXIsIGVzc2VudGlhbGx5IHJl cXVpcmluZyB0aGUgcmVjZWl2ZXIgdG8gZWNobyBiYWNrIHRoZSBwb2ludCB1cCB0byB3aGljaCBp dCBoYXMgcmVjZWl2ZWQgYWxsIGZyYW1lcywgYW5kIHRoZSBzZW5kZXIgc2hvdWxkbid0IHJlZmVy ZW5jZSBzdGF0ZSB0aGF0IHRoZSByZWNlaXZlciBoYXNuJ3QgZnVsbHkgYXNzaW1pbGF0ZWQgeWV0 LiAgSXQgZmVlbHMgbGlrZSBhZGRpbmcgYXBwbGljYXRpb24tbGV2ZWwgQUNLcyB0byBtZSwgd2hp Y2ggSSdkIGxpa2UgdG8gYXZvaWQuDQoNCkhQQUNLIGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25z IGZvciB0aGUgdHdvLXN0cmVhbS1wZXItcmVxdWVzdCBhcHByb2FjaC4gIFRoZXJlIGFyZSB0d28g cmVhc29ucyBmb3IgdGhpcyAtLSBvbmUgaXMgdGhhdCBIUEFDSyBmcmFtZXMgKGluIHRoZSBjdXJy ZW50IGRlc2lnbikgY2FuJ3QgYmUgbG9zdCB3aGVuIGEgc3RyZWFtIGlzIFJTVCwgc28gdGhlIGRy YWZ0IGZvcmJpZHMgcmVzZXR0aW5nIGNvbnRyb2wgc3RyZWFtcy4gIFNpbmNlIHdlIHN0aWxsIG5l ZWQgdG8gYmUgYWJsZSB0byBSU1QgcmVxdWVzdHMsIHdlIGFkZCB0aGUgc2VtYW50aWMgdGhhdCBr aWxsaW5nIHRoZSBkYXRhIHN0cmVhbSBpbXBsaWVzIHRoZSBzYW1lIHRoaW5nIGFib3V0IHRoZSBj b250cm9sIHN0cmVhbS4gIEl0J3MgbWVzc3ksIGFuZCBob3BlZnVsbHkgd2UgY2FuIHJlbW92ZSB0 aGF0IG9uY2UgSFBBQ0sgaXMgZml4ZWQuICBUaGUgc2Vjb25kLCBhcyB5b3UgZ3Vlc3NlZCwgaXMg bm90IGRlYWxpbmcgd2l0aCBEQVRBIGZyYW1lcy4gICMyNDUgbm90ZXMgdGhhdCwgaWYgd2UgZml4 IEhQQUNLLCB3ZSBjb3VsZCBnbyBiYWNrIHRvIGEgc2luZ2xlIHN0cmVhbSBwZXIgcmVxdWVzdDsg cHJvcG9uZW50cyBvZiBib3RoICJrZWVwIGZyYW1pbmcgb3V0IG9mIHRoZSB3YXkiIGFuZCAiZmV3 ZXIgc3RyZWFtcyBpcyBlYXNpZXIgdG8gbWFuYWdlIiBoYXZlIHdlaWdoZWQgaW4gdGhlcmUuICBQ bGVhc2UgYWRkIHlvdXIgdm9pY2UuDQoNCkFzIHRvIGJ1ZmZlcmluZywgaXQncyBhY3R1YWxseSBl YXN5IGVub3VnaCAtLSBqdXN0IGRvbid0IHJlYWQgZnJvbSBkYXRhIHN0cmVhbXMgdW50aWwgeW91 J3ZlIHNlZW4gdGhlIGhlYWRlcnMuICBTdXJlLCB0aGUgc2VuZGVyIHdpbGwgZmlsbCB1cCB0aGVp ciBmbG93IGNvbnRyb2wgd2luZG93IG9uIHRoYXQgc3RyZWFtIC0tIGFuZCB0aGVuIHRoZXknbGwg c3RvcCBhbmQgc2VuZCB5b3UgUVVJQyBCTE9DS0VEIGZyYW1lcywgdW50aWwgeW91IHN0YXJ0IHJl YWRpbmcgdGhlIGJvZHkgYW5kIGdlbmVyYXRpbmcgV0lORE9XX1VQREFURSBmcmFtZXMuICBPbmUg b2YgdGhlIGJpZ2dlc3QgYXJndW1lbnRzIGZvciB0d28gc3RyZWFtcyBpbiBteSBtaW5kIGlzIG1h a2luZyBzdXJlIHRoYXQgYSByZXF1ZXN0IGJsb2NrZWQgaW4gdGhpcyB3YXkgZG9lc24ndCBpbXBl ZGUgdGhlIGZsb3cgb2YgY29udHJvbCBmcmFtZXMgb24gdGhhdCBzdHJlYW0gLS0gZm9yIGV4YW1w bGUsIHNob3VsZCB3ZSBzdWNjZXNzZnVsbHkgZ2V0IGNlcnRpZmljYXRlIGF1dGggZnJhbWVzIGFk ZGVkLCBhIGNlcnRpZmljYXRlIHJlcXVlc3QuICBJJ3ZlIGhhZCB0d28gY3VzdG9tZXJzIHRoaXMg d2VlayB0ZWxsaW5nIG1lIGl0J3MgYSBidWcgaW4gb3VyIHNlcnZlciBjb2RlIHRoYXQgdGhlaXIg VExTIHJlbmVnIGdldHMgc3R1Y2sgaW4gVENQIGJ1ZmZlcnMgYmVoaW5kIGEgZ2lhbnQgcmVxdWVz dCBib2R5LCBiZWNhdXNlIHRoZSBzZXJ2ZXIgd29uJ3QgcmVhZCBhbiB1bmF1dGhlbnRpY2F0ZWQg Ym9keSBhbmQgdGhlIGNsaWVudCB3b24ndCBob2xkIG9mZiBzZW5kaW5nIHRoZSBib2R5IHVudGls IGF1dGhlbnRpY2F0aW9uIHN1Y2NlZWRzLiAgSSdkIGxpa2UgdG8gc2VlIGJsb2NrcyBsaWtlIHRo YXQgYmVjb21lIGxlc3MgcG9zc2libGUgaW4gUVVJQywgYXQgbGVhc3QuDQoNClllcywgbWFraW5n IFNFVFRJTkdTIGltbXV0YWJsZSByZWR1Y2VzIHRoZSBmbGV4aWJpbGl0eS4gIFRoZSBvcGluaW9u IGF0IHRoZSBpbnRlcmltIHdhcyB0aGF0IHdlIGNvdWxkIGxpdmUgd2l0aG91dCBpdCwgYXMgd2Ug a25vdyBvZiBleGFjdGx5IG9uZSBpbXBsZW1lbnRhdGlvbiBvZiBvbmUgZXh0ZW5zaW9uIHRoYXQg ZG9lcyBtaWQtc3RyZWFtIHNldHRpbmcgY2hhbmdlcywgYW5kIEkgb3duIGl0LiAg8J+YiiAgSWYg dGhlcmUncyBhIGNvbXBlbGxpbmcgdXNlIGNhc2UgZm9yIGNoYW5naW5nIHNldHRpbmdzIG1pZC1z dHJlYW0gd2Ugd2VyZW4ndCBhd2FyZSBvZiwgdGhhdCdzIG5ldyBpbmZvcm1hdGlvbiB0aGF0IGNv dWxkIGp1c3RpZnkgdGhlIGNvbXBsZXhpdHkuICAoQnV0IG5vdGUgdGhhdCB3aXRoIDAtUlRUIGNv bm5lY3Rpb24gc2V0dXAsIGl0IHdvdWxkIGJlIG5lYXJseSBhcyBjaGVhcCB0byBvcGVuIGEgbmV3 IGNvbm5lY3Rpb24gd2l0aCB0aGUgbmV3IHNldHRpbmcgYW5kIHRyYW5zaXRpb24geW91ciB0cmFm ZmljIHRvIGl0LikNCg0KTmVnb3RpYXRpb24gc3RpbGwgd29ya3MsIHNpbmNlIGVhY2ggc2lkZSB3 b3VsZCBzaW1wbHkgYWR2ZXJ0aXNlIHRoYXQgdGhleSBzdXBwb3J0IGFuIGV4dGVuc2lvbiBvciBu b3QsIGFuZCBjb25zaWRlciB0aGUgZXh0ZW5zaW9uIHRvIGJlIGFjdGl2ZSBvbmNlIHlvdSd2ZSBz ZWVuIHRoZSBvdGhlciBzaWRlJ3MgU0VUVElOR1MgZnJhbWUuICBTZWUgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcXVpYy1odHRwLTAxI3NlY3Rpb24tNS4yLjUuMyBmb3Ig dGhlIGNvbXBsZXhpdHkgdGhpcyBhbGxvd2VkIHVzIHRvIHJlbW92ZS4gIEFuIGV4dGVuc2lvbiBj b3VsZCBhZGQgdG8gdGhlIGxpc3QgZWFzaWx5IC0tIGlmIHlvdSBzdXBwb3J0IGV4dGVuc2lvbiBY LCB5b3Ugc2hvdWxkIGFsc28gcmVtZW1iZXIgdGhlIHZhbHVlIGZvciBzZXR0aW5nIFhfVkFMLiAg Q2xpZW50cyB0aGF0IGRvbid0IHVzZSB0aGUgZXh0ZW5zaW9uIGRvbid0IGNhcmUuICBBbiBleHRl bnNpb24gdGhhdCBuZWVkZWQgc29tZSBtb3JlIGNvbXBsZXggbmVnb3RpYXRpb24gd291bGQgaGF2 ZSB0byB1c2UgYW4gZXh0ZW5zaW9uLXNwZWNpZmljIGZyYW1lLCBpdCdzIHRydWUsIGJ1dCB3ZSBo YXZlbid0IHNvIGZhciBzZWVuIGFuIGV4dGVuc2lvbiBkbyB0aGF0Lg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZWZhbiBFaXNzaW5n DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDE1LCAyMDE3IDY6MjIgQU0NClRvOiBNYXJ0aW4gVGhv bXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBDb3JlIGRyYWZ0cyAtMDIgb3V0DQoNCg0KPiBBbSAxNC4wMy4yMDE3 IHVtIDAwOjU3IHNjaHJpZWIgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj46DQo+DQo+IFRoZSBlZGl0b3JzIGhh dmUgc3VibWl0dGVkIC0wMiB2ZXJzaW9ucyBvZiB0aGUgYmFzZSBzZXQgb2YgUVVJQyBkcmFmdHMu DQpbLi4uXQ0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0 dHAtMDINCg0KVGhhbmtzLCBNYXJ0aW4hIEkgYXNzdW1lIHRoYXQgd2FzIGFubm91bmNlZCB0byBn ZXQgZmVlZGJhY2sgZnJvbSB0aGUgbHVya2VycyBoZXJlLiA7LSkNCg0KSSdsbCBnaXZlIHRoaXMg YSB0cnkuIEFsbCBtaXN0YWtlcyBhbmQgbWlzdW5kZXJzdGFuZGluZ3MgYXJlIG1pbmUgYWxvbmUu DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClZlcnkgd2VsbCB3cml0dGVu IHNwZWMuIEVhc3kgdG8gdW5kZXJzdGFuZCBmb3Igc29tZW9uZSBoYXZpbmcgcmVhZCByZmMgNzU0 MCBhIGJpdC4NCg0KSSBoYXZlIHNvbWUgY29tbWVudHMgdG8gdGhlIHByb3Bvc2VkIEhUVFAgbWFw cGluZyBhcHByb2FjaC4gV2hlcmUgdGhlIHdnIGhhcyBhbHJlYWR5IGRpc2N1c3NlZCBhbmQgZXho YXVzdGVkIGFsdGVybmF0aXZlcywgcGxlYXNlIGV4Y3VzZSBteSBpZ25vcmFuY2UgYW5kIGlnbm9y ZSBteSBjb21tZW50cy4gSSBoYWQgbm90IHRoZSB0aW1lIHRvIGZvbGxvdyBhbGwgZGlzY3Vzc2lv bnMgb25nb2luZyBvbiB0aGlzIHRvcGljLiBGZWVsIGZyZWUgdG8gY2hlcnJ5LXBpY2sgd2hhdCBz ZWVtcyBoZWxwZnVsLg0KDQoNCj4gNC4gIFN0cmVhbSBNYXBwaW5nIGFuZCBVc2FnZQ0KDQorMSB0 byBkaXJlY3RseSB1c2luZyBxdWljIHN0cmVhbSBpZHMgaW5zdGVhZCBvZiB2aXJ0dWFsIGgyIHN0 cmVhbQ0KK2lkZW50aWZpZXINCg0KSG93ZXZlciwgdXNpbmcgMiBxdWljIHN0cmVhbXMgZm9yIGEg c2luZ2xlIHJlcXVlc3QvcmVzcG9uc2UgZG9lcyBub3Qgc2l0IHdlbGwgd2l0aCBtZS4gSSBhc3N1 bWUgdGhhdCBzdGVtcyBmcm9tIHRoZSB3aXNoIHRvIGdldCByaWQgb2YgREFUQSBmcmFtZXMuIFdo aWNoIHNvdW5kcyBuaWNlLCBidXQgaXMgaXQgd29ydGggaXQ/IEJ5IGRvdWJsaW5nIHRoZSAjIG9m IHN0cmVhbXMgZm9yIGEgY2xpZW50LCBob3cgbXVjaCBvdmVyaGVhZCBkb2VzIHRoYXQgaW50cm9k dWNlIChJIHNwZWFrIG9mIGEgc2VydmVyIGhvbGRpbmcgPjEwayBxdWljICJjb25uZWN0aW9ucyIp Pw0KDQpBbHNvLCB0aGUgc2VydmVyIG5lZWRzIHRvIGJ1ZmZlciBkYXRhIG9uIHF1aWMgc3RyZWFt cyA3LCAxMSwgMTUsIGV0Yy4gYmVjYXVzZSBIRUFERVJzIG1pZ2h0IGFycml2ZSBzb21lIHRpbWUg aW4gdGhlIGZ1dHVyZSBvbiBzdHJlYW1zIDUsIDksIDEzLCBldGMuIG9yIG5vdC4gVGhlcmUgaXMg bm8gd2F5IHRvIHJvdXRlIHRoaXMgZGF0YSBzb21ld2hlcmUsIGJlY2F1c2UgdGhlIG1ldGEgaW5m b3JtYXRpb24gaXMgc3RpbGwgbWlzc2luZy4NCg0KQW5kIHRoZXJlIGlzIHN0aWxsIEhvbGIgb246 DQoNCj4gNC4yLjEuICBIZWFkZXIgQ29tcHJlc3Npb24NCj4gLi4uDQo+IERJU0NVU1M6ICBLZWVw IEhQQUNLIHdpdGggSE9MQj8gIFJlZGVzaWduIEhQQUNLIHRvIGJlIG9yZGVyLQ0KPiAgICAgICBp bnZhcmlhbnQ/ICBIb3cgbXVjaCBkbyB3ZSBuZWVkIHRvIHJldGFpbiBjb21wYXRpYmlsaXR5IHdp dGgNCj4gICAgICAgSFRUUC8yJ3MgSFBBQ0s/DQoNClVzaW5nIGEgY291bnRlciBpbiBIRUFERVJT IGlzIGEgY3J1dGNoOg0KLSBpdCBpcyBhIGhpZ2hseSBzcGVjaWZpYyBzb2x1dGlvbiB0byBhIGNv bW1vbiBwcm9ibGVtIGluIGh0dHAvcXVpYzogc3luY2hyb25pY2l0eSBpbiBjb25uZWN0aW9uIGxl dmVsIHN0YXRlIGNoYW5nZXMuIFNFVFRJTkdTIChzZWUgYmVsb3cpIGhhcyB0aGUgc2FtZSBwcm9i bGVtLCBhcyBkb2VzIGhhdmUgUFJJT1JJVFkgaW4gSEVBREVSUy4gSXQgc2VlbXMgdGhhdCBwZXJm b3JtYW5jZSB3aXNlLCBhbGwgSEVBREVSUyBjb3VsZCBhcyB3ZWxsIGJlIHNlbnQgb24gc3RyZWFt IDMuDQoNCk5vdywgc29sdmluZyBIb2wgYmxvY2tpbmcgZm9yIEhFQURFUlMgd291bGQgYmUgYSBm aW5lIGFjaGlldmVtZW50Lg0KDQo+IDUuICBIVFRQIEZyYW1pbmcgTGF5ZXINCj4gRnJhbWVzIGFy ZSB1c2VkIG9ubHkgb24gdGhlIGNvbm5lY3Rpb24gKHN0cmVhbSAzKSBhbmQgbWVzc2FnZQ0KPiAg ICAoc3RyZWFtcyA1LCA5LCBldGMuKSBjb250cm9sIHN0cmVhbXMuDQoNCkFuZCBzdHJlYW1zIDQs IDgsIDEyLCBldGMuIEkgYXNzdW1lLg0KDQo+IDUuMi4zLiAgU0VUVElOR1MNCj4gLi4uDQo+IFNF VFRJTkdTIGZyYW1lcyBhbHdheXMgYXBwbHkgdG8gYSBjb25uZWN0aW9uLCBuZXZlciBhIHNpbmds ZSBzdHJlYW0uDQo+ICBBIFNFVFRJTkdTIGZyYW1lIE1VU1QgYmUgc2VudCBhcyB0aGUgZmlyc3Qg ZnJhbWUgb2YgdGhlIGNvbm5lY3Rpb24NCj4gY29udHJvbCBzdHJlYW0gKHNlZSBTZWN0aW9uIDQp IGJ5IGVhY2ggcGVlciwgYW5kIE1VU1QgTk9UIGJlIHNlbnQNCj4gc3Vic2VxdWVudGx5IG9yIG9u IGFueSBvdGhlciBzdHJlYW0uICBJZiBhbiBlbmRwb2ludCByZWNlaXZlcyBhbg0KPiBTRVRUSU5H UyBmcmFtZSBvbiBhIGRpZmZlcmVudCBzdHJlYW0sIHRoZSBlbmRwb2ludCBNVVNUIHJlc3BvbmQg d2l0aA0KPiBhIGNvbm5lY3Rpb24gZXJyb3Igb2YgdHlwZSBIVFRQX1NFVFRJTkdTX09OX1dST05H X1NUUkVBTS4gIElmIGFuDQo+IGVuZHBvaW50IHJlY2VpdmVzIGEgc2Vjb25kIFNFVFRJTkdTIGZy YW1lLCB0aGUgZW5kcG9pbnQgTVVTVCByZXNwb25kDQo+IHdpdGggYSBjb25uZWN0aW9uIGVycm9y IG9mIHR5cGUgSFRUUF9NVUxUSVBMRV9TRVRUSU5HUy4NCg0KV2hhdCBhYm91dCBIUEFDSyBzdGF0 ZT8gVGhlIGNvbm5lY3Rpb24gc3RhdGUgY2hhbmdlIHByb2JsZW0gYWdhaW4gdmlzaWJsZS4NCg0K VGhpcyBpcyBhIHNldmVyZSByZXN0cmljdGlvbiBvbiBleHRlbnNpb25zIG1lY2hhbmlzbXMgdGhh dCB3YW50IHRvIGFmZmVjdCBhIGNvbm5lY3Rpb24uIEJlY2F1c2UgaWYgdGhlIGh0dHAvcXVpYyBk b2VzIG5vdCBzb2x2ZSB0aGlzIHByb2JsZW0sIGhvdyBhcmUgdGhleSBleHBlY3RlZCB0byBkbyBp dD8gVGhleSBlaXRoZXIgYW5ub3VuY2UgdGhlbXNlbHZlcyBvbiB0aGUgZmlyc3QgU0VUVElOR1Mg b3IgcmVtYWluIHNpbGVudCBmb3JldmVyLCBpdCBzZWVtcy4gSG93IHdvdWxkIGFuIGV4dGVuc2lv biBoYW5kc2hha2Ugd29yayB0aGVuPyBPd24gc3RyZWFtIDMgaGFuZHNoYWtlIGZyYW1lcz8NCg0K PiA1LjIuMy4zLiAgVXNhZ2UgaW4gMC1SVFQNCg0KV2hhdCBhYm91dCBIUEFDSyBzdGF0ZT8gRG9l cyBpdCBuZWVkIHRvIGJlIGtlcHQgb3IgaXMgaXQgcmVzZXQ/DQoNCj4gSFRUUF9QVVNIX0FMUkVB RFlfSU5fQ0FDSEUgKDB4MDMpOiAgVGhlIHNlcnZlciBoYXMgYXR0ZW1wdGVkIHRvIHB1c2gNCj4g ICAgICBjb250ZW50IHdoaWNoIHRoZSBjbGllbnQgaGFzIGNhY2hlZC4NCj4gLi4uDQo+IEhUVFBf UkVRVUVTVF9DQU5DRUxMRUQgKDB4MDQpOiAgVGhlIGNsaWVudCBubyBsb25nZXIgbmVlZHMgdGhl DQo+ICAgICByZXF1ZXN0ZWQgZGF0YS4NCg0KTml0cGljazogc2VlbXMgcmVkdW5kYW50LiBUaGUg Zmlyc3QgY291bGQgYmUgcmVwbGFjZWQgYnkgdGhlIHNlY29uZC4gU3RyZWFtIG51bWJlciB3aWxs IHN1ZmZpY2UuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KVGFraW5nIHR3byBzdGVwcyBiYWNrOg0KDQpJIHRoaW5rIHRoZSBt YWluIGRpZmZpY3VsdHkgY29tZXMgZnJvbSB0aGUgbGFjayBvZiBhICJocSBjb25uZWN0aW9uIHN0 YXRlIiBjb25jZXB0IGFuZCBob3cgY2hhbmdlcyB0byB0aGF0IHN0YXRlIGNhbiBiZSBtYW5hZ2Vk LiBFdmlkZW5jZToNCi0gVGhlIDAtUlRUIG1lbnRpb25zIGNlcnRhaW4gU0VUVElOR1MgdGhhdCBu ZWVkIHRvIGJlIHJlbWVtYmVyZWQgYnkgYSBjbGllbnQuIEhvdyB3b3VsZCBhbiBleHRlbnNpb24g YWRkIHRvIHRoaXM/IFdpbGwgZXZlcnkgZXh0ZW5zaW9uIGhhdmUgdG8gY29tZSB1cCB3aXRoIGl0 cyBvd24gc29sdXRpb24/DQotIFRoZSBIRUFERVJzIHNlcXVlbmNlIG51bWJlciBpcyBhIGhpZ2hs eSBzcGVjaWZpYyBmaXggZm9yIHRoZSBtaXNzaW5nIHN0YXRlIGNoYW5nZQ0KLSBUaGUgU0VUVElO R1MtT05DRSByZXN0cmljdGlvbiBzaW1wbHkgYXZvaWRzIHRoZSBwcm9ibGVtIGJ5IGtpbGxpbmcg YSBoMiBtZWNoYW5pc20NCg0KSWYgaHEgZGVmaW5lcyBzdHJlYW0gMyBhcyB0aGUgcGxhY2Ugd2hl cmUgY29ubmVjdGlvbiBzdGF0ZSBjaGFuZ2VzIGhhcHBlbiAqQU5EKiBzeW5jaHJvbml6ZXMgT1BF Ti9DTE9TRS9SU1Qgb2Ygb3RoZXIgc3RyZWFtcyBvbiBpdCwgY2xpZW50IGFuZCBzZXJ2ZXIgY2Fu IGhhdmUgc2hhcmVhYmxlIGNvbmNlcHQgb2YgdGhlIGNvbm5lY3Rpb24gc3RhdGUuDQoNCg0KSSBh bSBubyBIUEFDSyBleHBlcnQuIFRoZSBiYXNpYyBwcm9ibGVtIGxvb2tzIGxpa2UgY29uY3VycmVu dCBlZGl0aW5nIGFnYWluc3QgYSByZXBvc2l0b3J5Lg0KQm90aCBjbGllbnQgYW5kIHNlcnZlciBz dGFydCB3aXRoIGNvbm5lY3Rpb24gc3RhdGUgemVybyAoQ1MtMCkgYW5kIHRoZSBwcmVkZWZpbmVk IEhQQUNLIGRpY3Rpb25hcnkgKEhQLTApLiBBZnRlciBTRVRUSU5HUyBleGNoYW5nZSwgY2xpZW50 IGlzIGluIENTLTEgYW5kIHNlcnZlciBpcyBpbiBDUy0yIGZvciBpdHMgc2lkZS4gTGV0J3MgY2Fs bCB0aGUgIENTLTEgSFBBQ0sgc3RhdGUgSFAtMS4NCg0KQ2xpZW50IHNlbmRzIG5ldyBIRUFERVJT IG9uIDUgYW5kIGtlZXBzIHRoZSBIUEFDSyBkZWx0YSBhcm91bmQgKEhQLTEuNSkuIFRoZSBIRUFE RVJTIGNhcnJpZXMgdGhlIGNvbm5lY3Rpb24gc3RhdGUgbnVtYmVyIGl0IGlzIGJhc2VkIG9uIChD Uy0xKS4gQ2xpZW50IHNlbmRzIG5ldyBIRUFERVJTIG9uIHN0cmVhbSA5LCBhbHNvIGJhc2VkIG9u IENTLTEuIENsaWVudCBrZWVwcyB0aGF0IGRlbHRhIGFyb3VuZCAoSFAtMS45KS4NCg0KQ2xpZW50 IHRoZW4gZGVjaWRlcyB0byBhbm5vdW5jZSBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIChDUy0zKSBi eSBzZW5kaW5nIGhvdyBpdCBhcHBsaWVkIHRoZSBkZWx0YXMgSFAtMS41IGFuZCBIUC0xLjkgdG8g Y29tZSB1cCB3aXRoIEhQLTMuIFRoZSBkZXNjcmlwdGlvbiBhbGxvd3MgdGhlIHNlcnZlciB0byB1 cGRhdGUgaXRzIEhQLTEgdG8gSFAtMyBhcyB3ZWxsLg0KDQpSZXNwb25zZSBIRUFERVJTIGFyZSBh bHNvIGJhc2VkIG9uIGEgc2VydmVyIGNvbm5lY3Rpb24gc3RhdGUsIGV4cGxpY2l0bHksIHNvIHRo ZSBjbGllbnQga25vd3Mgd2hpY2ggSFAtWCB0byB1c2Ugd2hlbiBkZWNvZGluZyB0aGVtLiBBdCBz b21lIHRpbWUsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gYW5ub3VuY21lbnQgb2YgQ1MtNCB3aXRoIEhQ QUNLIGRhdGEgb24gc3RyZWFtIDMgYmFjayB0byB0aGUgY2xpZW50Lg0KDQpGb3IgYSAwLVJUVCwg Y2xpZW50IGFuZCBzZXJ2ZXIgY291bGQgZXhjaGFuZ2UgdGhlIGNvbm5lY3Rpb24gc3RhdGUgaWQg aW4gdGhlIGluaXRpYWwgU0VUVElOR1MsIHRvIG1ha2Ugc3VyZSB0aGV5IGhhdmUgYXQgbGVhc3Qg dGhlIHNhbWUgbmFtZSByZW1lbWJlcmVkIGFzIHRoZSBvdGhlciBzaWRlLiBDbGllbnQ6ICJJIHdh cyBpbiBDUy0xOSBhbmQgeW91IHdlcmUgaW4gQ1MtOC4iIFNlcnZlcjogIlllcC4iDQoNCkJ5IGlt cGxpY2l0bHkgYWRkaW5nIGFsbCBTRVRUSU5HUyBjaGFuZ2VzIHRvIGNvbm5lY3Rpb24gc3RhdGVz LCB0aGUgcHJvYmxlbSBpcyBhbHNvIHNvbHZlZCBmb3IgZXh0ZW5zaW9ucy4NCg0KSWYgb25lIHNp ZGUgcmVjZWl2ZXMgSEVBREVSUyB3aXRoIGFuIHVua25vd24gY29ubmVjdGlvbiBzdGF0ZToNCi0g aWYgdGhlIHN0YXRlIGlkIGlzIGdyZWF0ZXIgdGhhbiBhbnkga25vd24gb25lOiBzZXQgYSBzdHJl YW0gdGltZW91dCBhbmQgd2FpdCBmb3IgY2hhbmdlcyBvbiBzdHJlYW0gMyB0byBhcnJpdmUNCi0g c3RhdGUgaWQgbGVzcyB0aGFuIG1heChrbm93biBjb25uIHN0YXRlKTogU1RSRUFNX1JTVF9VTktO T1dOX0NPTk5fU1RBVEUNCg0KTmV3IFNFVFRJTkdTIHZhbHVlOiBNQVhfQ09OTl9TVEFURSBudW1i ZXIgb2YgbWF4aW11bSBjb25uZWN0aW9uIHN0YXRlIHRoZSBjbGllbnQvc2VydmVyIGlzIHdpbGxp bmcgdG8ga2VlcCwgZXhjaGFuZ2VkIGluaXRpYWxseS4gQW5ub3VuY2luZyBhIG5ldyBjb25uZWN0 aW9uIHN0YXRlIGFsbG93cyB0aGUgb3RoZXIgc2lkZSB0byBkcm9wIHRoZSBsb3dlc3Qgb25lLCBp ZiBNQVhfQ09OTl9TVEFURSBhcmUgdXNlZC4NCg0KVG8gZ2V0IG9wdGltYWwgSFBBQ0sgc2l6ZSBj b21wcmVzc2lvbiwgZXZlcnkgSEVBREVScyB3b3VsZCBhbHNvIGFubm91bmNlIGEgbmV3IGNvbm5l Y3Rpb25zIHN0YXRlLiBUbyBoYXZlIGxlc3MgcG90ZW50aWFsIEhPTEIsIGNvbm5lY3Rpb24gc3Rh dGVzIGRvIG5vdCBjaGFuZ2UgZHVyaW5nIHJlcXVlc3QgYnVyc3RzLg0KDQpTb21ldGhpbmcgbGlr ZSB0aGF0Lg0KDQotU3RlZmFuDQoNCg0KDQoNCi0tDQpDaGFybGVzICdCdWNrJyBLcmFzaWMgfCBT b2Z0d2FyZSBFbmdpbmVlciB8IGNrcmFzaWNAZ29vZ2xlLmNvbTxtYWlsdG86Y2tyYXNpY0Bnb29n bGUuY29tPiB8ICsxICg0MDgpIDQxMi0xMTQxDQo= --_000_BN6PR03MB2708B2829B54BFF5DE1DA82C873F0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBF bW9qaSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NTE3 NTEwODc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01 OTA4MDk2MCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWxsIEkgc2VlIGluIHRoZSBsaW5rcyBhcmUgaHR0cDovLyBhbmQg dGhlIGRyYWZ0IG5hbWUsIG5vIGhvc3QuJm5ic3A7IEnigJltIGd1ZXNzaW5nIHlvdSBtZWFudA0K PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2tyYXNpYy9kcmFmdC1rcmFzaWMtcXVpYy1ocGFj ay9ibG9iL21hc3Rlci9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sIj4NCmh0dHBzOi8v Z2l0aHViLmNvbS9rcmFzaWMvZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2svYmxvYi9tYXN0ZXIvZHJh ZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAuaHRtbDwvYT4/ICZuYnNwO09uY2UgdGhlIHRyYWNrZXIg cmVvcGVucyAoc29tZXRpbWUgU3VuZGF5LCBJIHRoaW5rKSB5b3Ugc2hvdWxkIHByb2JhYmx5IHVw bG9hZCB0aG9zZSBhdCBkYXRhdHJhY2tlci5pZXRmLm9yZyB0byBtYWtlIGl0IGFuIG9mZmljaWFs IHN1Ym1pc3Npb24uPGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4mbmJzcDsNCiBZb3XigJlsbCBu ZWVkIHRvIG1ha2UgdGhlIGRyYWZ0IG5hbWUgaW4gdGhlIGZpbGUgbWF0Y2ggdGhlIGZpbGUgbmFt ZSBiZWZvcmUgaXQgd2lsbCBzdWNjZXNzZnVsbHkgdXBsb2FkLjxvOnA+PC9vOnA+PC9hPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+QWxzbywgZm9yIGVh c2Ugb2YgZGlzY3Vzc2lvbiwgeW91IG1pZ2h0IHBpY2sgYSBkaWZmZXJlbnQgbmFtZSB0aGFuIFFQ QUNLLCBzaW5jZSB0aGVyZeKAmXMgYWxyZWFkeSBhIGRyYWZ0IHdpdGggdGhhdCBuYW1lLiZuYnNw OyAoT3Igd2UgYm90aCBjaGFuZ2UgbmFtZXMsIGFuZCBjYWxsIHRoZSBldmVudHVhbGx5LWFkb3B0 ZWQgb25lIFFQQUNLOyB0aGF04oCZZA0KIGJlIGZpbmUsIHRvby4pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj5BcyB0byBh Y3R1YWwgZmVlZGJhY2s6Jm5ic3A7IEkgc2VlIHdoYXQgeW914oCZcmUgZ2V0dGluZyBhdCBoZXJl IGJlY2F1c2UgeW914oCZdmUgZXhwbGFpbmVkIGl0IOKAkyB0aGUgZGVjb2RlciBhY2tub3dsZWRn ZXMgdGhlIHNlcXVlbmNlIG51bWJlciBpdOKAmXMgdXAgdG8sIHRoZW4gdGhlIGVuY29kZXIgdHJh Y2tzIHRoYXQgYW5kIHVzZXMgaXQgb24gdGhlDQogZW5jb2RlIHNpZGUuJm5ic3A7IEkgdGhpbmsg SeKAmWQgaGF2ZSBhIHJlYWxseSBoYXJkIHRpbWUgcGFyc2luZyB0aGUgZG9jdW1lbnQgd2l0aG91 dCB0aGF0LiZuYnNwOyBJIHRoaW5rIHRoZSBzdHJvbmdlc3QgYWR2YW50YWdlIG9mIHRoaXMgcHJv cG9zYWwgaXMgdGhhdCBhbiBlbmNvZGVyIGZvciB0aGlzIHNjaGVtZSBjb3VsZCBiZSB1c2VkIG92 ZXIgSFRUUC8yLCBlbmFibGluZyBzaGFyZWQgY29kZTsgeW91IHNob3VsZCBicmluZyB0aGF0IG91 dCBtb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+VGhlIHdheSB5b3XigJl2ZSBkZXNjcmliZWQgdGhlIGVuY29kZXIg cmVxdWlyZXMgdGlnaHQgaW50ZWdyYXRpb24gYmV0d2VlbiB0aGUgcGFja2V0aXphdGlvbiBsb2dp YyBhbmQgdGhlIGhlYWRlciBjb21wcmVzc29yIGluIHR3byB3YXlzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+SXQg bmVlZHMgdG8ga25vdyB0aGUg4oCccGFja2V0IGVwb2No4oCdIChlbmNvZGUgZXBvY2ggb2YgdGhl IGZpcnN0IGZyYW1lIGluIHRoZSBjdXJyZW50IHBhY2tldCkgd2hpbGUgY29tcHJlc3NpbmcsIGJ1 dCB1bnRpbCB5b3Uga25vdyB0aGUgc2l6ZQ0KIG9mIHRoZSBjb21wcmVzc2VkIG91dHB1dCwgeW91 IGNhbuKAmXQga25vdyB3aGV0aGVyIGl0IHdpbGwgZml0IGluIHRoZSBjdXJyZW50IHBhY2tldC4m bmJzcDsgVGhhdCBpbiB0dXJuIG1lYW5zIHlvdeKAmWxsIG5lZWQgdG8gcm9sbCBiYWNrIGFueSBz dGF0ZSBhbmQgcmUtZW5jb2RlIHdpdGggYSBkaWZmZXJlbnQgcGFja2V0IGVwb2NoIGlmIGl0IHR1 cm5zIG91dCBub3QgdG8gZml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+VGhlIOKAnGNv bW1pdCBlcG9jaOKAnSBpcyBkZXRlcm1pbmVkLCBub3QgYnkgZGF0YSBhdCB0aGUgY29tcHJlc3Nv ciBsZXZlbCwgYnV0IGJ5IHJlYWNoaW5nIGludG8gdGhlIHRyYW5zcG9ydCBhbmQgY2hlY2tpbmcg d2hpY2ggcGFja2V0cyBjb250YWluaW5nDQogdGhlIFNUUkVBTSBmcmFtZXMgY29udGFpbmluZyB0 aGUgSFBBQ0sgZGF0YSBpbiBxdWVzdGlvbiBoYXZlIGJlZW4gYWNrbm93bGVkZ2VkLiZuYnNwOyBB bHNvIG5vdGUgdGhhdCBBQ0sgZG9lc27igJl0IHNpZ25pZnkgZGVsaXZlcnkgdG8gdGhlIGFwcGxp Y2F0aW9uIGxheWVyIChIVFRQKSwganVzdCBwcmVzZW5jZSBpbiB0aGUgYXBwcm9wcmlhdGUgcXVl dWUuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxFbmRDb21wb3NlIj5JbiAyLjIuMS4xLCB0aGUgZW5jb2RlciBpcyBpbmZvcm1lZCB3 aGV0aGVyIOKAnFFQQUNLIGlzIGVuYWJsZWQs4oCdIGJ1dCBzaW5jZSB0aGF0IGNhbiBiZSB0b2dn bGVkIG9uL29mZiBvbiBhIHBlci1oZWFkZXItZnJhbWUgYmFzaXMgKGFuZCBJIGhvcGUgeW91IHJl YWxseSBtZWFudCBwZXItaGVhZGVyLWJsb2NrKSwgaXQgc2VlbXMgbGlrZSB0aGUNCiBkZWNvZGVy IGlzIGp1c3QgZm9sbG93aW5nIHRoZSBlbmNvZGVy4oCZcyBsZWFkIG9uIHRoaXMuJm5ic3A7IFdo b+KAmXMgYWN0dWFsbHkgbWFraW5nIHRoYXQgZGVjaXNpb24/Jm5ic3A7IFlvdSBzYXkgaXQgZ2V0 cyB0dXJuZWQgb2ZmIGlmIGEgZHJvcCByZXN1bHRzLCBidXQgdGhlIGVuY29kZXIgaXMgdGhlIG9u ZSB3aG8ga25vd3MvZGV0ZXJtaW5lcyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3Nl Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+VGhpcyBoYXMgdGhlIHNhbWUg cHJvYmxlbSBhcyB0aGUgY3VycmVudCBIUEFDSyBzdGF0ZSB0aGF0IFJTVCBvbiBhIGNvbnRyb2wg c3RyZWFtIGxvc2VzIGNyaXRpY2FsIGRhdGEgYW5kIHRoZXJl4oCZcyBubyB3YXkgdG8gcmVjb3Zl ci4mbmJzcDsgSeKAmW0gcGVyc29uYWxseSBob3Bpbmcgd2UgY2FuIG1ha2Ugb3VyIHdheSBvdXQg b2YgdGhhdCByZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVu ZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBDaGFy bGVzICdCdWNrJyBLcmFzaWMgW21haWx0bzpja3Jhc2ljQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMjEsIDIwMTcgNjowNCBQTTxicj4NCjxiPlRvOjwvYj4g TWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBTdGVmYW4gRWlzc2luZyAmbHQ7c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSZn dDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyBJRVRG IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBD b3JlIGRyYWZ0cyAtMDIgb3V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBGb2xr cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkndmUgcHV0 IHRvZ2V0aGVyIGEgZmlyc3QgYXR0ZW1wdCBhdCBteSBRUEFDSyBwcm9wb3NhbDo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cDovL2RyYWZ0LWtyYXNpYy1xdWljLWhwYWNrLTAwLmh0bWwiPmRyYWZ0LWtyYXNpYy1xdWljLWhw YWNrLTAwLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2tyYXNpYy5naXRodWIuaW8vZHJhZnQta3Jhc2lj LXF1aWMtaHBhY2svZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAudHh0Ij5kcmFmdC1rcmFzaWMt cXVpYy1ocGFjay0wMC50eHQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFwb2xvZ2llcyBpbiBhZHZhbmNlLCB0aGlzIGlzIG15IGZpcnN0 IGF0dGVtcHQgYXQgYW4gSUVURiBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAxNSwgMjAxNyBhdCAxMDozNyBB TSwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrITxicj4NCjxicj4NClllcywgeW91J3ZlIHJ1biBz dHJhaWdodCBpbnRvIHRoZSBiaWcgcXVhbmRhcnkgd2l0aCBIUEFDSy4mbmJzcDsgSSBkb24ndCB0 aGluayBhbnlvbmUgZXhwZWN0cyB0aGF0IHdlIHdpbGwgc2hpcCB0aGlzIHdheTsgSSBoYXZlIGEg cHJvcG9zYWwgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i aXNob3AtcXVpYy1odHRwLWFuZC1xcGFjayIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrPC9hPiBmb3Ig YW4gSFBBQ0stcmVwbGFjZW1lbnQgdGhhdCB3b3VsZCBzb2x2ZSBtYW55IG9mIHRoZXNlLiZuYnNw OyBCdWNrIEtyYXNpYyBoYXMgYSBwcm9wb3NhbCB3aGljaCBoZSBoYXMgc2tldGNoZWQgaW4gZS1t YWlsIGJ1dCBub3Qgc3VibWl0dGVkIGFzIGEgZHJhZnQuJm5ic3A7IFRoZSBtYWluIHBvaW50IG9m IHRoZSBzZXF1ZW5jZSBudW1iZXIgd2FzIHRvDQogZ2V0IHVzIG9mZiB0aGUgJnF1b3Q7ZXZlcnl0 aGluZyBvbiBzdHJlYW0gMyZxdW90OyBtb2RlbCBhbmQgbGV0IHVzIHNvcnQgb3V0IHRoZSBwcm9i bGVtcyBvZiBIUEFDSyBsYXRlci4mbmJzcDsgIzIyOCB0cmFja3MgZml4aW5nIEhQQUNLLCBpbiB3 aGF0ZXZlciBmb3JtIHRoYXQgdGFrZXMuPGJyPg0KPGJyPg0KV2UgY291bGQgc29sdmUgaXQgaW4g dGhlIHNhbWUgd2F5IHRoYXQgd2UgZGlkIFBSSU9SSVRZLCBieSBhZGRpbmcgYW4gJnF1b3Q7YWZm ZWN0ZWQgc3RyZWFtIG51bWJlciZxdW90OyBmaWVsZCBhbmQgbW92aW5nIHRoZSBIRUFERVJTL1BV U0hfUFJPTUlTRSBmcmFtZXMgdG8gU3RyZWFtIDMgYXMgd2VsbC4mbmJzcDsgSG93ZXZlciwgdGhh dCBpcyBqdXN0IGFzIGJsb2NraW5nIGFzIHRoZSBjdXJyZW50IGFwcHJvYWNoLCBzbyBub3QgcmVh bGx5IGFuIGltcHJvdmVtZW50LiZuYnNwOyBXb3JzZSwNCiB0aGUgcmVhc29uIHdlIGNhbiB0b2xl cmF0ZSBsYXJnZSBoZWFkZXIgZnJhbWVzIGlzIGJlY2F1c2UgdGhleSBvY2N1ciBvbiB0aGVpciBv d24gc3RyZWFtcyBhbmQgZG9uJ3QgYmxvY2sgYXJyaXZhbCBvZiBkYXRhIGZyb20gb3RoZXIgc3Ry ZWFtcy4mbmJzcDsgSWYgYWxsIGhlYWRlcnMgb2NjdXIgb24gYSBzaW5nbGUgc3RyZWFtLCB0aGF0 J3Mgbm90IHRydWUgLS0geW91ICphcmUqIGJsb2NraW5nIG11eGluZyBvZiBvdGhlciBzdHJlYW1z IGFnYWluLjxicj4NCjxicj4NCkkgbGlrZSB0aGUgY29tcGFyaXNvbiB0byBjb25jdXJyZW50IGVk aXRzLiZuYnNwOyBXZSd2ZSBkaXNjdXNzZWQgaGF2aW5nIHJvbGxpbmcgZGVsdGFzIGluIHZhcmlv dXMgbWVjaGFuaXNtczsgdGhlIHByb2JsZW0gaXMgdGhhdCBpdCByZXF1aXJlcyByZWFjaGluZyBp bnRvIHRoZSB0cmFuc3BvcnQgZm9yIEFDSyBzdGF0ZSB0byBmaWd1cmUgb3V0IHdoZW4geW91IGNh biBkaXNjYXJkIG9sZCBkZWx0YXMgZm9yIGdvb2Qgb24gdGhlIHJlY2VpdmVyIHNpZGUuJm5ic3A7 DQogQnVjaydzIHByb3Bvc2FsIGlzIHNpbWlsYXIsIGVzc2VudGlhbGx5IHJlcXVpcmluZyB0aGUg cmVjZWl2ZXIgdG8gZWNobyBiYWNrIHRoZSBwb2ludCB1cCB0byB3aGljaCBpdCBoYXMgcmVjZWl2 ZWQgYWxsIGZyYW1lcywgYW5kIHRoZSBzZW5kZXIgc2hvdWxkbid0IHJlZmVyZW5jZSBzdGF0ZSB0 aGF0IHRoZSByZWNlaXZlciBoYXNuJ3QgZnVsbHkgYXNzaW1pbGF0ZWQgeWV0LiZuYnNwOyBJdCBm ZWVscyBsaWtlIGFkZGluZyBhcHBsaWNhdGlvbi1sZXZlbCBBQ0tzDQogdG8gbWUsIHdoaWNoIEkn ZCBsaWtlIHRvIGF2b2lkLjxicj4NCjxicj4NCkhQQUNLIGlzIGFsc28gb25lIG9mIHRoZSByZWFz b25zIGZvciB0aGUgdHdvLXN0cmVhbS1wZXItcmVxdWVzdCBhcHByb2FjaC4mbmJzcDsgVGhlcmUg YXJlIHR3byByZWFzb25zIGZvciB0aGlzIC0tIG9uZSBpcyB0aGF0IEhQQUNLIGZyYW1lcyAoaW4g dGhlIGN1cnJlbnQgZGVzaWduKSBjYW4ndCBiZSBsb3N0IHdoZW4gYSBzdHJlYW0gaXMgUlNULCBz byB0aGUgZHJhZnQgZm9yYmlkcyByZXNldHRpbmcgY29udHJvbCBzdHJlYW1zLiZuYnNwOyBTaW5j ZSB3ZSBzdGlsbA0KIG5lZWQgdG8gYmUgYWJsZSB0byBSU1QgcmVxdWVzdHMsIHdlIGFkZCB0aGUg c2VtYW50aWMgdGhhdCBraWxsaW5nIHRoZSBkYXRhIHN0cmVhbSBpbXBsaWVzIHRoZSBzYW1lIHRo aW5nIGFib3V0IHRoZSBjb250cm9sIHN0cmVhbS4mbmJzcDsgSXQncyBtZXNzeSwgYW5kIGhvcGVm dWxseSB3ZSBjYW4gcmVtb3ZlIHRoYXQgb25jZSBIUEFDSyBpcyBmaXhlZC4mbmJzcDsgVGhlIHNl Y29uZCwgYXMgeW91IGd1ZXNzZWQsIGlzIG5vdCBkZWFsaW5nIHdpdGggREFUQSBmcmFtZXMuJm5i c3A7DQogIzI0NSBub3RlcyB0aGF0LCBpZiB3ZSBmaXggSFBBQ0ssIHdlIGNvdWxkIGdvIGJhY2sg dG8gYSBzaW5nbGUgc3RyZWFtIHBlciByZXF1ZXN0OyBwcm9wb25lbnRzIG9mIGJvdGggJnF1b3Q7 a2VlcCBmcmFtaW5nIG91dCBvZiB0aGUgd2F5JnF1b3Q7IGFuZCAmcXVvdDtmZXdlciBzdHJlYW1z IGlzIGVhc2llciB0byBtYW5hZ2UmcXVvdDsgaGF2ZSB3ZWlnaGVkIGluIHRoZXJlLiZuYnNwOyBQ bGVhc2UgYWRkIHlvdXIgdm9pY2UuPGJyPg0KPGJyPg0KQXMgdG8gYnVmZmVyaW5nLCBpdCdzIGFj dHVhbGx5IGVhc3kgZW5vdWdoIC0tIGp1c3QgZG9uJ3QgcmVhZCBmcm9tIGRhdGEgc3RyZWFtcyB1 bnRpbCB5b3UndmUgc2VlbiB0aGUgaGVhZGVycy4mbmJzcDsgU3VyZSwgdGhlIHNlbmRlciB3aWxs IGZpbGwgdXAgdGhlaXIgZmxvdyBjb250cm9sIHdpbmRvdyBvbiB0aGF0IHN0cmVhbSAtLSBhbmQg dGhlbiB0aGV5J2xsIHN0b3AgYW5kIHNlbmQgeW91IFFVSUMgQkxPQ0tFRCBmcmFtZXMsIHVudGls IHlvdSBzdGFydA0KIHJlYWRpbmcgdGhlIGJvZHkgYW5kIGdlbmVyYXRpbmcgV0lORE9XX1VQREFU RSBmcmFtZXMuJm5ic3A7IE9uZSBvZiB0aGUgYmlnZ2VzdCBhcmd1bWVudHMgZm9yIHR3byBzdHJl YW1zIGluIG15IG1pbmQgaXMgbWFraW5nIHN1cmUgdGhhdCBhIHJlcXVlc3QgYmxvY2tlZCBpbiB0 aGlzIHdheSBkb2Vzbid0IGltcGVkZSB0aGUgZmxvdyBvZiBjb250cm9sIGZyYW1lcyBvbiB0aGF0 IHN0cmVhbSAtLSBmb3IgZXhhbXBsZSwgc2hvdWxkIHdlIHN1Y2Nlc3NmdWxseQ0KIGdldCBjZXJ0 aWZpY2F0ZSBhdXRoIGZyYW1lcyBhZGRlZCwgYSBjZXJ0aWZpY2F0ZSByZXF1ZXN0LiZuYnNwOyBJ J3ZlIGhhZCB0d28gY3VzdG9tZXJzIHRoaXMgd2VlayB0ZWxsaW5nIG1lIGl0J3MgYSBidWcgaW4g b3VyIHNlcnZlciBjb2RlIHRoYXQgdGhlaXIgVExTIHJlbmVnIGdldHMgc3R1Y2sgaW4gVENQIGJ1 ZmZlcnMgYmVoaW5kIGEgZ2lhbnQgcmVxdWVzdCBib2R5LCBiZWNhdXNlIHRoZSBzZXJ2ZXIgd29u J3QgcmVhZCBhbiB1bmF1dGhlbnRpY2F0ZWQNCiBib2R5IGFuZCB0aGUgY2xpZW50IHdvbid0IGhv bGQgb2ZmIHNlbmRpbmcgdGhlIGJvZHkgdW50aWwgYXV0aGVudGljYXRpb24gc3VjY2VlZHMuJm5i c3A7IEknZCBsaWtlIHRvIHNlZSBibG9ja3MgbGlrZSB0aGF0IGJlY29tZSBsZXNzIHBvc3NpYmxl IGluIFFVSUMsIGF0IGxlYXN0Ljxicj4NCjxicj4NClllcywgbWFraW5nIFNFVFRJTkdTIGltbXV0 YWJsZSByZWR1Y2VzIHRoZSBmbGV4aWJpbGl0eS4mbmJzcDsgVGhlIG9waW5pb24gYXQgdGhlIGlu dGVyaW0gd2FzIHRoYXQgd2UgY291bGQgbGl2ZSB3aXRob3V0IGl0LCBhcyB3ZSBrbm93IG9mIGV4 YWN0bHkgb25lIGltcGxlbWVudGF0aW9uIG9mIG9uZSBleHRlbnNpb24gdGhhdCBkb2VzIG1pZC1z dHJlYW0gc2V0dGluZyBjaGFuZ2VzLCBhbmQgSSBvd24gaXQuJm5ic3A7DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1 MjI7PC9zcGFuPiZuYnNwOyBJZiB0aGVyZSdzIGEgY29tcGVsbGluZyB1c2UgY2FzZSBmb3IgY2hh bmdpbmcgc2V0dGluZ3MgbWlkLXN0cmVhbSB3ZSB3ZXJlbid0IGF3YXJlIG9mLCB0aGF0J3MgbmV3 IGluZm9ybWF0aW9uIHRoYXQgY291bGQganVzdGlmeSB0aGUgY29tcGxleGl0eS4mbmJzcDsgKEJ1 dCBub3RlIHRoYXQgd2l0aCAwLVJUVCBjb25uZWN0aW9uIHNldHVwLCBpdA0KIHdvdWxkIGJlIG5l YXJseSBhcyBjaGVhcCB0byBvcGVuIGEgbmV3IGNvbm5lY3Rpb24gd2l0aCB0aGUgbmV3IHNldHRp bmcgYW5kIHRyYW5zaXRpb24geW91ciB0cmFmZmljIHRvIGl0Lik8YnI+DQo8YnI+DQpOZWdvdGlh dGlvbiBzdGlsbCB3b3Jrcywgc2luY2UgZWFjaCBzaWRlIHdvdWxkIHNpbXBseSBhZHZlcnRpc2Ug dGhhdCB0aGV5IHN1cHBvcnQgYW4gZXh0ZW5zaW9uIG9yIG5vdCwgYW5kIGNvbnNpZGVyIHRoZSBl eHRlbnNpb24gdG8gYmUgYWN0aXZlIG9uY2UgeW91J3ZlIHNlZW4gdGhlIG90aGVyIHNpZGUncyBT RVRUSU5HUyBmcmFtZS4mbmJzcDsgU2VlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAtMDEjc2VjdGlvbi01LjIuNS4zIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLWh0dHAt MDEjc2VjdGlvbi01LjIuNS4zPC9hPiBmb3IgdGhlIGNvbXBsZXhpdHkgdGhpcyBhbGxvd2VkIHVz IHRvIHJlbW92ZS4mbmJzcDsgQW4gZXh0ZW5zaW9uIGNvdWxkIGFkZCB0byB0aGUgbGlzdCBlYXNp bHkgLS0gaWYgeW91IHN1cHBvcnQgZXh0ZW5zaW9uIFgsIHlvdSBzaG91bGQgYWxzbyByZW1lbWJl ciB0aGUgdmFsdWUgZm9yIHNldHRpbmcgWF9WQUwuJm5ic3A7IENsaWVudHMgdGhhdA0KIGRvbid0 IHVzZSB0aGUgZXh0ZW5zaW9uIGRvbid0IGNhcmUuJm5ic3A7IEFuIGV4dGVuc2lvbiB0aGF0IG5l ZWRlZCBzb21lIG1vcmUgY29tcGxleCBuZWdvdGlhdGlvbiB3b3VsZCBoYXZlIHRvIHVzZSBhbiBl eHRlbnNpb24tc3BlY2lmaWMgZnJhbWUsIGl0J3MgdHJ1ZSwgYnV0IHdlIGhhdmVuJ3Qgc28gZmFy IHNlZW4gYW4gZXh0ZW5zaW9uIGRvIHRoYXQuPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFN0 ZWZhbiBFaXNzaW5nPGJyPg0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxNSwgMjAxNyA2OjIyIEFN PGJyPg0KVG86IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgSUVURiBRVUlD IFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KU3ViamVjdDogUmU6IENvcmUgZHJhZnRzIC0wMiBvdXQ8YnI+DQo8YnI+DQo8YnI+ DQomZ3Q7IEFtIDE0LjAzLjIwMTcgdW0gMDA6NTcgc2NocmllYiBNYXJ0aW4gVGhvbXNvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25A Z21haWwuY29tPC9hPiZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGVkaXRvcnMgaGF2ZSBz dWJtaXR0ZWQgLTAyIHZlcnNpb25zIG9mIHRoZSBiYXNlIHNldCBvZiBRVUlDIGRyYWZ0cy48YnI+ DQpbLi4uXTxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcXVpYy1odHRwLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcXVpYy1odHRwLTAyPC9hPjxicj4NCjxicj4NClRoYW5rcywg TWFydGluISBJIGFzc3VtZSB0aGF0IHdhcyBhbm5vdW5jZWQgdG8gZ2V0IGZlZWRiYWNrIGZyb20g dGhlIGx1cmtlcnMgaGVyZS4gOy0pPGJyPg0KPGJyPg0KSSdsbCBnaXZlIHRoaXMgYSB0cnkuIEFs bCBtaXN0YWtlcyBhbmQgbWlzdW5kZXJzdGFuZGluZ3MgYXJlIG1pbmUgYWxvbmUuPGJyPg0KPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpWZXJ5IHdlbGwg d3JpdHRlbiBzcGVjLiBFYXN5IHRvIHVuZGVyc3RhbmQgZm9yIHNvbWVvbmUgaGF2aW5nIHJlYWQg cmZjIDc1NDAgYSBiaXQuPGJyPg0KPGJyPg0KSSBoYXZlIHNvbWUgY29tbWVudHMgdG8gdGhlIHBy b3Bvc2VkIEhUVFAgbWFwcGluZyBhcHByb2FjaC4gV2hlcmUgdGhlIHdnIGhhcyBhbHJlYWR5IGRp c2N1c3NlZCBhbmQgZXhoYXVzdGVkIGFsdGVybmF0aXZlcywgcGxlYXNlIGV4Y3VzZSBteSBpZ25v cmFuY2UgYW5kIGlnbm9yZSBteSBjb21tZW50cy4gSSBoYWQgbm90IHRoZSB0aW1lIHRvIGZvbGxv dyBhbGwgZGlzY3Vzc2lvbnMgb25nb2luZyBvbiB0aGlzIHRvcGljLiBGZWVsIGZyZWUgdG8gY2hl cnJ5LXBpY2sNCiB3aGF0IHNlZW1zIGhlbHBmdWwuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyA0LiZu YnNwOyBTdHJlYW0gTWFwcGluZyBhbmQgVXNhZ2U8YnI+DQo8YnI+DQomIzQzOzEgdG8gZGlyZWN0 bHkgdXNpbmcgcXVpYyBzdHJlYW0gaWRzIGluc3RlYWQgb2YgdmlydHVhbCBoMiBzdHJlYW08YnI+ DQomIzQzO2lkZW50aWZpZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpIb3dldmVyLCB1 c2luZyAyIHF1aWMgc3RyZWFtcyBmb3IgYSBzaW5nbGUgcmVxdWVzdC9yZXNwb25zZSBkb2VzIG5v dCBzaXQgd2VsbCB3aXRoIG1lLiBJIGFzc3VtZSB0aGF0IHN0ZW1zIGZyb20gdGhlIHdpc2ggdG8g Z2V0IHJpZCBvZiBEQVRBIGZyYW1lcy4gV2hpY2ggc291bmRzIG5pY2UsIGJ1dCBpcyBpdCB3b3J0 aCBpdD8gQnkgZG91YmxpbmcgdGhlICMgb2Ygc3RyZWFtcyBmb3IgYSBjbGllbnQsIGhvdyBtdWNo IG92ZXJoZWFkIGRvZXMgdGhhdA0KIGludHJvZHVjZSAoSSBzcGVhayBvZiBhIHNlcnZlciBob2xk aW5nICZndDsxMGsgcXVpYyAmcXVvdDtjb25uZWN0aW9ucyZxdW90Oyk/PGJyPg0KPGJyPg0KQWxz bywgdGhlIHNlcnZlciBuZWVkcyB0byBidWZmZXIgZGF0YSBvbiBxdWljIHN0cmVhbXMgNywgMTEs IDE1LCBldGMuIGJlY2F1c2UgSEVBREVScyBtaWdodCBhcnJpdmUgc29tZSB0aW1lIGluIHRoZSBm dXR1cmUgb24gc3RyZWFtcyA1LCA5LCAxMywgZXRjLiBvciBub3QuIFRoZXJlIGlzIG5vIHdheSB0 byByb3V0ZSB0aGlzIGRhdGEgc29tZXdoZXJlLCBiZWNhdXNlIHRoZSBtZXRhIGluZm9ybWF0aW9u IGlzIHN0aWxsIG1pc3NpbmcuPGJyPg0KPGJyPg0KQW5kIHRoZXJlIGlzIHN0aWxsIEhvbGIgb246 PGJyPg0KPGJyPg0KJmd0OyA0LjIuMS4mbmJzcDsgSGVhZGVyIENvbXByZXNzaW9uPGJyPg0KJmd0 OyAuLi48YnI+DQomZ3Q7IERJU0NVU1M6Jm5ic3A7IEtlZXAgSFBBQ0sgd2l0aCBIT0xCPyZuYnNw OyBSZWRlc2lnbiBIUEFDSyB0byBiZSBvcmRlci08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aW52YXJpYW50PyZuYnNwOyBIb3cgbXVjaCBkbyB3ZSBuZWVkIHRvIHJldGFpbiBj b21wYXRpYmlsaXR5IHdpdGg8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SFRU UC8yJ3MgSFBBQ0s/PGJyPg0KPGJyPg0KVXNpbmcgYSBjb3VudGVyIGluIEhFQURFUlMgaXMgYSBj cnV0Y2g6PGJyPg0KLSBpdCBpcyBhIGhpZ2hseSBzcGVjaWZpYyBzb2x1dGlvbiB0byBhIGNvbW1v biBwcm9ibGVtIGluIGh0dHAvcXVpYzogc3luY2hyb25pY2l0eSBpbiBjb25uZWN0aW9uIGxldmVs IHN0YXRlIGNoYW5nZXMuIFNFVFRJTkdTIChzZWUgYmVsb3cpIGhhcyB0aGUgc2FtZSBwcm9ibGVt LCBhcyBkb2VzIGhhdmUgUFJJT1JJVFkgaW4gSEVBREVSUy4gSXQgc2VlbXMgdGhhdCBwZXJmb3Jt YW5jZSB3aXNlLCBhbGwgSEVBREVSUyBjb3VsZCBhcyB3ZWxsIGJlIHNlbnQNCiBvbiBzdHJlYW0g My48YnI+DQo8YnI+DQpOb3csIHNvbHZpbmcgSG9sIGJsb2NraW5nIGZvciBIRUFERVJTIHdvdWxk IGJlIGEgZmluZSBhY2hpZXZlbWVudC48YnI+DQo8YnI+DQomZ3Q7IDUuJm5ic3A7IEhUVFAgRnJh bWluZyBMYXllcjxicj4NCiZndDsgRnJhbWVzIGFyZSB1c2VkIG9ubHkgb24gdGhlIGNvbm5lY3Rp b24gKHN0cmVhbSAzKSBhbmQgbWVzc2FnZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IChzdHJlYW1z IDUsIDksIGV0Yy4pIGNvbnRyb2wgc3RyZWFtcy48YnI+DQo8YnI+DQpBbmQgc3RyZWFtcyA0LCA4 LCAxMiwgZXRjLiBJIGFzc3VtZS48YnI+DQo8YnI+DQomZ3Q7IDUuMi4zLiZuYnNwOyBTRVRUSU5H Uzxicj4NCiZndDsgLi4uPGJyPg0KJmd0OyBTRVRUSU5HUyBmcmFtZXMgYWx3YXlzIGFwcGx5IHRv IGEgY29ubmVjdGlvbiwgbmV2ZXIgYSBzaW5nbGUgc3RyZWFtLjxicj4NCiZndDsmbmJzcDsgQSBT RVRUSU5HUyBmcmFtZSBNVVNUIGJlIHNlbnQgYXMgdGhlIGZpcnN0IGZyYW1lIG9mIHRoZSBjb25u ZWN0aW9uPGJyPg0KJmd0OyBjb250cm9sIHN0cmVhbSAoc2VlIFNlY3Rpb24gNCkgYnkgZWFjaCBw ZWVyLCBhbmQgTVVTVCBOT1QgYmUgc2VudDxicj4NCiZndDsgc3Vic2VxdWVudGx5IG9yIG9uIGFu eSBvdGhlciBzdHJlYW0uJm5ic3A7IElmIGFuIGVuZHBvaW50IHJlY2VpdmVzIGFuPGJyPg0KJmd0 OyBTRVRUSU5HUyBmcmFtZSBvbiBhIGRpZmZlcmVudCBzdHJlYW0sIHRoZSBlbmRwb2ludCBNVVNU IHJlc3BvbmQgd2l0aDxicj4NCiZndDsgYSBjb25uZWN0aW9uIGVycm9yIG9mIHR5cGUgSFRUUF9T RVRUSU5HU19PTl9XUk9OR19TVFJFQU0uJm5ic3A7IElmIGFuPGJyPg0KJmd0OyBlbmRwb2ludCBy ZWNlaXZlcyBhIHNlY29uZCBTRVRUSU5HUyBmcmFtZSwgdGhlIGVuZHBvaW50IE1VU1QgcmVzcG9u ZDxicj4NCiZndDsgd2l0aCBhIGNvbm5lY3Rpb24gZXJyb3Igb2YgdHlwZSBIVFRQX01VTFRJUExF X1NFVFRJTkdTLjxicj4NCjxicj4NCldoYXQgYWJvdXQgSFBBQ0sgc3RhdGU/IFRoZSBjb25uZWN0 aW9uIHN0YXRlIGNoYW5nZSBwcm9ibGVtIGFnYWluIHZpc2libGUuPGJyPg0KPGJyPg0KVGhpcyBp cyBhIHNldmVyZSByZXN0cmljdGlvbiBvbiBleHRlbnNpb25zIG1lY2hhbmlzbXMgdGhhdCB3YW50 IHRvIGFmZmVjdCBhIGNvbm5lY3Rpb24uIEJlY2F1c2UgaWYgdGhlIGh0dHAvcXVpYyBkb2VzIG5v dCBzb2x2ZSB0aGlzIHByb2JsZW0sIGhvdyBhcmUgdGhleSBleHBlY3RlZCB0byBkbyBpdD8gVGhl eSBlaXRoZXIgYW5ub3VuY2UgdGhlbXNlbHZlcyBvbiB0aGUgZmlyc3QgU0VUVElOR1Mgb3IgcmVt YWluIHNpbGVudCBmb3JldmVyLCBpdA0KIHNlZW1zLiBIb3cgd291bGQgYW4gZXh0ZW5zaW9uIGhh bmRzaGFrZSB3b3JrIHRoZW4/IE93biBzdHJlYW0gMyBoYW5kc2hha2UgZnJhbWVzPzxicj4NCjxi cj4NCiZndDsgNS4yLjMuMy4mbmJzcDsgVXNhZ2UgaW4gMC1SVFQ8YnI+DQo8YnI+DQpXaGF0IGFi b3V0IEhQQUNLIHN0YXRlPyBEb2VzIGl0IG5lZWQgdG8gYmUga2VwdCBvciBpcyBpdCByZXNldD88 YnI+DQo8YnI+DQomZ3Q7IEhUVFBfUFVTSF9BTFJFQURZX0lOX0NBQ0hFICgweDAzKTombmJzcDsg VGhlIHNlcnZlciBoYXMgYXR0ZW1wdGVkIHRvIHB1c2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgY29udGVudCB3aGljaCB0aGUgY2xpZW50IGhhcyBjYWNoZWQuPGJyPg0KJmd0OyAuLi48 YnI+DQomZ3Q7IEhUVFBfUkVRVUVTVF9DQU5DRUxMRUQgKDB4MDQpOiZuYnNwOyBUaGUgY2xpZW50 IG5vIGxvbmdlciBuZWVkcyB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1ZXN0 ZWQgZGF0YS48YnI+DQo8YnI+DQpOaXRwaWNrOiBzZWVtcyByZWR1bmRhbnQuIFRoZSBmaXJzdCBj b3VsZCBiZSByZXBsYWNlZCBieSB0aGUgc2Vjb25kLiBTdHJlYW0gbnVtYmVyIHdpbGwgc3VmZmlj ZS48YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVGFraW5nIHR3byBzdGVwcyBiYWNrOjxicj4NCjxi cj4NCkkgdGhpbmsgdGhlIG1haW4gZGlmZmljdWx0eSBjb21lcyBmcm9tIHRoZSBsYWNrIG9mIGEg JnF1b3Q7aHEgY29ubmVjdGlvbiBzdGF0ZSZxdW90OyBjb25jZXB0IGFuZCBob3cgY2hhbmdlcyB0 byB0aGF0IHN0YXRlIGNhbiBiZSBtYW5hZ2VkLiBFdmlkZW5jZTo8YnI+DQotIFRoZSAwLVJUVCBt ZW50aW9ucyBjZXJ0YWluIFNFVFRJTkdTIHRoYXQgbmVlZCB0byBiZSByZW1lbWJlcmVkIGJ5IGEg Y2xpZW50LiBIb3cgd291bGQgYW4gZXh0ZW5zaW9uIGFkZCB0byB0aGlzPyBXaWxsIGV2ZXJ5IGV4 dGVuc2lvbiBoYXZlIHRvIGNvbWUgdXAgd2l0aCBpdHMgb3duIHNvbHV0aW9uPzxicj4NCi0gVGhl IEhFQURFUnMgc2VxdWVuY2UgbnVtYmVyIGlzIGEgaGlnaGx5IHNwZWNpZmljIGZpeCBmb3IgdGhl IG1pc3Npbmcgc3RhdGUgY2hhbmdlPGJyPg0KLSBUaGUgU0VUVElOR1MtT05DRSByZXN0cmljdGlv biBzaW1wbHkgYXZvaWRzIHRoZSBwcm9ibGVtIGJ5IGtpbGxpbmcgYSBoMiBtZWNoYW5pc208YnI+ DQo8YnI+DQpJZiBocSBkZWZpbmVzIHN0cmVhbSAzIGFzIHRoZSBwbGFjZSB3aGVyZSBjb25uZWN0 aW9uIHN0YXRlIGNoYW5nZXMgaGFwcGVuICpBTkQqIHN5bmNocm9uaXplcyBPUEVOL0NMT1NFL1JT VCBvZiBvdGhlciBzdHJlYW1zIG9uIGl0LCBjbGllbnQgYW5kIHNlcnZlciBjYW4gaGF2ZSBzaGFy ZWFibGUgY29uY2VwdCBvZiB0aGUgY29ubmVjdGlvbiBzdGF0ZS48YnI+DQo8YnI+DQo8YnI+DQpJ IGFtIG5vIEhQQUNLIGV4cGVydC4gVGhlIGJhc2ljIHByb2JsZW0gbG9va3MgbGlrZSBjb25jdXJy ZW50IGVkaXRpbmcgYWdhaW5zdCBhIHJlcG9zaXRvcnkuPGJyPg0KQm90aCBjbGllbnQgYW5kIHNl cnZlciBzdGFydCB3aXRoIGNvbm5lY3Rpb24gc3RhdGUgemVybyAoQ1MtMCkgYW5kIHRoZSBwcmVk ZWZpbmVkIEhQQUNLIGRpY3Rpb25hcnkgKEhQLTApLiBBZnRlciBTRVRUSU5HUyBleGNoYW5nZSwg Y2xpZW50IGlzIGluIENTLTEgYW5kIHNlcnZlciBpcyBpbiBDUy0yIGZvciBpdHMgc2lkZS4gTGV0 J3MgY2FsbCB0aGUmbmJzcDsgQ1MtMSBIUEFDSyBzdGF0ZSBIUC0xLjxicj4NCjxicj4NCkNsaWVu dCBzZW5kcyBuZXcgSEVBREVSUyBvbiA1IGFuZCBrZWVwcyB0aGUgSFBBQ0sgZGVsdGEgYXJvdW5k IChIUC0xLjUpLiBUaGUgSEVBREVSUyBjYXJyaWVzIHRoZSBjb25uZWN0aW9uIHN0YXRlIG51bWJl ciBpdCBpcyBiYXNlZCBvbiAoQ1MtMSkuIENsaWVudCBzZW5kcyBuZXcgSEVBREVSUyBvbiBzdHJl YW0gOSwgYWxzbyBiYXNlZCBvbiBDUy0xLiBDbGllbnQga2VlcHMgdGhhdCBkZWx0YSBhcm91bmQg KEhQLTEuOSkuPGJyPg0KPGJyPg0KQ2xpZW50IHRoZW4gZGVjaWRlcyB0byBhbm5vdW5jZSBhIG5l dyBjb25uZWN0aW9uIHN0YXRlIChDUy0zKSBieSBzZW5kaW5nIGhvdyBpdCBhcHBsaWVkIHRoZSBk ZWx0YXMgSFAtMS41IGFuZCBIUC0xLjkgdG8gY29tZSB1cCB3aXRoIEhQLTMuIFRoZSBkZXNjcmlw dGlvbiBhbGxvd3MgdGhlIHNlcnZlciB0byB1cGRhdGUgaXRzIEhQLTEgdG8gSFAtMyBhcyB3ZWxs Ljxicj4NCjxicj4NClJlc3BvbnNlIEhFQURFUlMgYXJlIGFsc28gYmFzZWQgb24gYSBzZXJ2ZXIg Y29ubmVjdGlvbiBzdGF0ZSwgZXhwbGljaXRseSwgc28gdGhlIGNsaWVudCBrbm93cyB3aGljaCBI UC1YIHRvIHVzZSB3aGVuIGRlY29kaW5nIHRoZW0uIEF0IHNvbWUgdGltZSwgdGhlIHNlcnZlciBz ZW5kcyBhbiBhbm5vdW5jbWVudCBvZiBDUy00IHdpdGggSFBBQ0sgZGF0YSBvbiBzdHJlYW0gMyBi YWNrIHRvIHRoZSBjbGllbnQuPGJyPg0KPGJyPg0KRm9yIGEgMC1SVFQsIGNsaWVudCBhbmQgc2Vy dmVyIGNvdWxkIGV4Y2hhbmdlIHRoZSBjb25uZWN0aW9uIHN0YXRlIGlkIGluIHRoZSBpbml0aWFs IFNFVFRJTkdTLCB0byBtYWtlIHN1cmUgdGhleSBoYXZlIGF0IGxlYXN0IHRoZSBzYW1lIG5hbWUg cmVtZW1iZXJlZCBhcyB0aGUgb3RoZXIgc2lkZS4gQ2xpZW50OiAmcXVvdDtJIHdhcyBpbiBDUy0x OSBhbmQgeW91IHdlcmUgaW4gQ1MtOC4mcXVvdDsgU2VydmVyOiAmcXVvdDtZZXAuJnF1b3Q7PGJy Pg0KPGJyPg0KQnkgaW1wbGljaXRseSBhZGRpbmcgYWxsIFNFVFRJTkdTIGNoYW5nZXMgdG8gY29u bmVjdGlvbiBzdGF0ZXMsIHRoZSBwcm9ibGVtIGlzIGFsc28gc29sdmVkIGZvciBleHRlbnNpb25z Ljxicj4NCjxicj4NCklmIG9uZSBzaWRlIHJlY2VpdmVzIEhFQURFUlMgd2l0aCBhbiB1bmtub3du IGNvbm5lY3Rpb24gc3RhdGU6PGJyPg0KLSBpZiB0aGUgc3RhdGUgaWQgaXMgZ3JlYXRlciB0aGFu IGFueSBrbm93biBvbmU6IHNldCBhIHN0cmVhbSB0aW1lb3V0IGFuZCB3YWl0IGZvciBjaGFuZ2Vz IG9uIHN0cmVhbSAzIHRvIGFycml2ZTxicj4NCi0gc3RhdGUgaWQgbGVzcyB0aGFuIG1heChrbm93 biBjb25uIHN0YXRlKTogU1RSRUFNX1JTVF9VTktOT1dOX0NPTk5fU1RBVEU8YnI+DQo8YnI+DQpO ZXcgU0VUVElOR1MgdmFsdWU6IE1BWF9DT05OX1NUQVRFIG51bWJlciBvZiBtYXhpbXVtIGNvbm5l Y3Rpb24gc3RhdGUgdGhlIGNsaWVudC9zZXJ2ZXIgaXMgd2lsbGluZyB0byBrZWVwLCBleGNoYW5n ZWQgaW5pdGlhbGx5LiBBbm5vdW5jaW5nIGEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgYWxsb3dzIHRo ZSBvdGhlciBzaWRlIHRvIGRyb3AgdGhlIGxvd2VzdCBvbmUsIGlmIE1BWF9DT05OX1NUQVRFIGFy ZSB1c2VkLjxicj4NCjxicj4NClRvIGdldCBvcHRpbWFsIEhQQUNLIHNpemUgY29tcHJlc3Npb24s IGV2ZXJ5IEhFQURFUnMgd291bGQgYWxzbyBhbm5vdW5jZSBhIG5ldyBjb25uZWN0aW9ucyBzdGF0 ZS4gVG8gaGF2ZSBsZXNzIHBvdGVudGlhbCBIT0xCLCBjb25uZWN0aW9uIHN0YXRlcyBkbyBub3Qg Y2hhbmdlIGR1cmluZyByZXF1ZXN0IGJ1cnN0cy48YnI+DQo8YnI+DQpTb21ldGhpbmcgbGlrZSB0 aGF0Ljxicj4NCjxicj4NCi1TdGVmYW48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3Jk ZXI6c29saWQgI0Q1MEYyNSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij5DaGFybGVzICdCdWNrJyBLcmFz aWMmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQg IzMzNjlFOCAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDtTb2Z0d2FyZQ0KIEVuZ2luZWVyJm5i c3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICMwMDk5 MzkgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNrcmFzaWNAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNrcmFzaWNAZ29vZ2xlLmNvbTwvYT4mbmJzcDt8PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgI0VFQjIxMSAxLjVw dDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDsmIzQzOzENCiAoNDA4KSA0MTItMTE0MTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB2708B2829B54BFF5DE1DA82C873F0BN6PR03MB2708namp_-- From nobody Thu Mar 23 11:27:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE2129B5D for ; Thu, 23 Mar 2017 11:27:33 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 C5rb_JqHFpHo for ; Thu, 23 Mar 2017 11:27:31 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B40381315FE for ; Thu, 23 Mar 2017 11:27:31 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3AA4843343C; Thu, 23 Mar 2017 18:27:31 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2433143340A; Thu, 23 Mar 2017 18:27:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1490293651; bh=FHtNWHYb7PqLGdykfh1GD1ZrffghTJDqRMFbA2h8VU8=; l=13493; h=From:To:CC:Date:References:In-Reply-To:From; b=Hwmx/A2GT2KNRC0svY6i86rbK3y0vTnoBpMIr3jy9cqXkD5V0uZfCkcpcezj+9UJz hGydwvY9fPDFOwbFN4Ikjd7tnlGTevnG53goFxWT4rEeYUJRwRHSHKFyHkszPQO2bP TJuxRrwZk42kwodCEr1xR0trYT2bwiew2wMjD4C0= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1EFD11FC8B; Thu, 23 Mar 2017 18:27:31 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Mar 2017 14:27:30 -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.1178.4; Thu, 23 Mar 2017 14:27:30 -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.1178.000; Thu, 23 Mar 2017 14:27:30 -0400 From: "Lubashev, Igor" To: Subodh Iyengar , Martin Thomson CC: "quic@ietf.org" Subject: RE: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGh2eCAgAA5O4CAAHPJAIAAZdGA///G0xA= Date: Thu, 23 Mar 2017 18:27:29 +0000 Message-ID: <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.234] Content-Type: multipart/alternative; boundary="_000_8dde9f5fac4440a8ac6c04e27efc042fusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 18:27:34 -0000 --_000_8dde9f5fac4440a8ac6c04e27efc042fusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Concurrency limit is about the amount of local resources a remote peer can = consume. It is not about how much local resources can be consumed by the l= ocal application - these limits can be enforced without any help from the p= rotocol. So concurrency limit is really the number of concurrent in-progress streams= that a peer is willing to receive. This maps well with unidirectional str= eams, but this is not a requirement. To be put precisely, the concurrency = limit can be defined as "the max number of streams with non-zero unACKed by= tes sent by that peer". This means, peers can negotiate separate concurren= cy limits. - Igor From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Thursday, March 23, 2017 1:09 PM To: Martin Thomson Cc: quic@ietf.org Subject: Re: FIN + RST behavior > The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. Ya in the case of the previous example, it is a server resource since it's = a client initiated stream. @Martin Thomson I'm starting to like your = proposal of unidirectional streams more and more :) Subodh ________________________________ From: QUIC > on behalf = of Martin Thomson > Sent: Thursday, March 23, 2017 4:04:46 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior On 23 March 2017 at 15:10, Subodh Iyengar > wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it send= s > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of = the > ACKs of all the server sent bytes in the stream, which would be a bit sad= . The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. --_000_8dde9f5fac4440a8ac6c04e27efc042fusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Concurrency limit is about the amount of local reso= urces a remote peer can consume.  It is not about how much local resou= rces can be consumed by the local application – these limits can be enforced without any help from the protocol.

 

So concurrency limit is really the number of concur= rent in-progress streams that a peer is willing to receive.  This maps= well with unidirectional streams, but this is not a requirement.  To be put precisely, the concurrency limit can be def= ined as “the max number of streams with non-zero unACKed bytes sent b= y that peer”.  This means, peers can negotiate separate concurre= ncy limits.

 

-     &= nbsp;    Igor

 

From: Subodh Iyengar [mailto:subodh@= fb.com]
Sent: Thursday, March 23, 2017 1:09 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

&= gt;  The client can consider its own resources t= o be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

Ya in the case of the previous example, it is a server resource s= ince it's a client initiated stream. 
@Marti= n Thomson I'm starting to like your proposal of unidirectio= nal streams more and more :)

<= o:p> 

Subodh

<= o:p> 

From: QUIC &= lt;quic-bounces@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>
Sent: Thursday, March 23, 2017 4:04:46 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com> wrote:
> How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it s= ends
> out the FIN because it still must keep state until it receives all the=
> ACKs for the stream. I think the client need to keep track of the ACK = of the
> ACKs of all the server sent bytes in the stream, which would be a bit = sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

--_000_8dde9f5fac4440a8ac6c04e27efc042fusma1exdag1mb5msgcorpak_-- From nobody Thu Mar 23 11:30:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3186129B66 for ; Thu, 23 Mar 2017 11:30:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 XfyF-fKwuROW for ; Thu, 23 Mar 2017 11:30:29 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 79D36129B63 for ; Thu, 23 Mar 2017 11:30:26 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id v22so14454776uaa.1 for ; Thu, 23 Mar 2017 11:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gE4JbY+8YRfYRnXRcAB01U7DDE9jur0UCyHclzx0HRo=; b=LlmAL43X3zK7FRGEd9G2gFoVcMDqJBpp3E/F11rzC6BNbLzuTiCECEaERi60f4BJ7v LMZmYVx993RyMPfUo/MfssTUctGtNNwfmx/m0YNWeh0Epsq6nifMy8PXmtIJPpLCgBJj hnfXzdIjTIA/u3X6oai32rQC6MUViWxEu5rs4f0fudY+u522gjmkrw3o1vplhYOef8q+ cxY0n1HBxPp+9AfTByzsjcdDFDiH1YGfUeq9/0XZlJIapbmqcdwtcJ8w3jM/MmRYpKau kiUa8XyJmBROruAZnfANqHIJ7ev6q4gmtrhzktcQkO74pgkcoElz+0b3PCs4QyRoI/Z/ ZKKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gE4JbY+8YRfYRnXRcAB01U7DDE9jur0UCyHclzx0HRo=; b=RtlpVu/eLlZ16SFHsURHiEsxXxUKCK/bTfJzQ9K0uGrZObfkxNBbMAcsg3cGsUdXc2 78JdZXj9a7BkWWvx2fX+lpJqaDVuaUbsgV9nidDC82YKR8eAKbHBgqQkZC0rE67nNQEQ xRG7H2TXHk/KZIAnM5a62ahGFtdJRxUmlmmD24QgLnKkSNXCh/qmCPRxiEn93fAoUdov n0rUfpt9NaWRFhAi+Y9n30ydHjDkcUK1/SPkX/E7OzmSnHdPRK5xUtZug1WN33sqJWZ9 Sci/+rU173iCeCr5hcW0RTPTUecFh0bazaevaOXPeT0j5ebXSrFii8WZUowBazOCuXWF SB1w== X-Gm-Message-State: AFeK/H3Vm6zOmnW5qNfs3QNdiprFnvXNZPx7xayyld0DuUHimR7/Fv8nU9o0AllW1wg3gggYMeEqWnUkUwg7dIFJ X-Received: by 10.176.74.155 with SMTP id s27mr1787180uae.143.1490293825069; Thu, 23 Mar 2017 11:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 23 Mar 2017 11:30:24 -0700 (PDT) In-Reply-To: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> From: Jana Iyengar Date: Thu, 23 Mar 2017 14:30:24 -0400 Message-ID: Subject: Re: Core drafts -02 out To: Mike Bishop Cc: "Charles 'Buck' Krasic" , Stefan Eissing , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary=f403045ef6540ee39e054b6a127a Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 18:30:34 -0000 --f403045ef6540ee39e054b6a127a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 23, 2017 at 1:52 PM, Mike Bishop wrote: > All I see in the links are http:// and the draft name, no host. I=E2=80= =99m > guessing you meant https://github.com/krasic/draft-krasic-quic-hpack/blob= / > master/draft-krasic-quic-hpack-00.html? Once the tracker reopens > (sometime Sunday, I think) you should probably upload those at > datatracker.ietf.org to make it an official submission. You=E2=80=99ll n= eed to > make the draft name in the file match the file name before it will > successfully upload. > > > > Also, for ease of discussion, you might pick a different name than QPACK, > since there=E2=80=99s already a draft with that name. (Or we both change= names, > and call the eventually-adopted one QPACK; that=E2=80=99d be fine, too.) > Just on this one point: I like QPACK for the final one. Maybe it's fine to call it krasic-qpack and bishop-qpack for now? - jana > > > As to actual feedback: I see what you=E2=80=99re getting at here because= you=E2=80=99ve > explained it =E2=80=93 the decoder acknowledges the sequence number it=E2= =80=99s up to, > then the encoder tracks that and uses it on the encode side. I think I= =E2=80=99d > have a really hard time parsing the document without that. I think the > strongest advantage of this proposal is that an encoder for this scheme > could be used over HTTP/2, enabling shared code; you should bring that ou= t > more. > > > > The way you=E2=80=99ve described the encoder requires tight integration b= etween > the packetization logic and the header compressor in two ways: > > - It needs to know the =E2=80=9Cpacket epoch=E2=80=9D (encode epoch of= the first frame > in the current packet) while compressing, but until you know the size = of > the compressed output, you can=E2=80=99t know whether it will fit in t= he current > packet. That in turn means you=E2=80=99ll need to roll back any state= and > re-encode with a different packet epoch if it turns out not to fit. > - The =E2=80=9Ccommit epoch=E2=80=9D is determined, not by data at the= compressor > level, but by reaching into the transport and checking which packets > containing the STREAM frames containing the HPACK data in question hav= e > been acknowledged. Also note that ACK doesn=E2=80=99t signify deliver= y to the > application layer (HTTP), just presence in the appropriate queue. > > > > In 2.2.1.1, the encoder is informed whether =E2=80=9CQPACK is enabled,=E2= =80=9D but since > that can be toggled on/off on a per-header-frame basis (and I hope you > really meant per-header-block), it seems like the decoder is just followi= ng > the encoder=E2=80=99s lead on this. Who=E2=80=99s actually making that d= ecision? You say > it gets turned off if a drop results, but the encoder is the one who > knows/determines that. > > > > This has the same problem as the current HPACK state that RST on a contro= l > stream loses critical data and there=E2=80=99s no way to recover. I=E2= =80=99m personally > hoping we can make our way out of that requirement. > > > > *From:* Charles 'Buck' Krasic [mailto:ckrasic@google.com] > *Sent:* Tuesday, March 21, 2017 6:04 PM > *To:* Mike Bishop > *Cc:* Stefan Eissing ; Martin Thomson < > martin.thomson@gmail.com>; IETF QUIC WG > > *Subject:* Re: Core drafts -02 out > > > > Hi Folks. > > > > I've put together a first attempt at my QPACK proposal: > > > > draft-krasic-quic-hpack-00.html > > draft-krasic-quic-hpack-00.txt > > > > > Apologies in advance, this is my first attempt at an IETF draft. > > > > > > On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > > Thanks for the feedback! > > Yes, you've run straight into the big quandary with HPACK. I don't think > anyone expects that we will ship this way; I have a proposal in > https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack for an > HPACK-replacement that would solve many of these. Buck Krasic has a > proposal which he has sketched in e-mail but not submitted as a draft. T= he > main point of the sequence number was to get us off the "everything on > stream 3" model and let us sort out the problems of HPACK later. #228 > tracks fixing HPACK, in whatever form that takes. > > We could solve it in the same way that we did PRIORITY, by adding an > "affected stream number" field and moving the HEADERS/PUSH_PROMISE frames > to Stream 3 as well. However, that is just as blocking as the current > approach, so not really an improvement. Worse, the reason we can tolerat= e > large header frames is because they occur on their own streams and don't > block arrival of data from other streams. If all headers occur on a sing= le > stream, that's not true -- you *are* blocking muxing of other streams aga= in. > > I like the comparison to concurrent edits. We've discussed having rollin= g > deltas in various mechanisms; the problem is that it requires reaching in= to > the transport for ACK state to figure out when you can discard old deltas > for good on the receiver side. Buck's proposal is similar, essentially > requiring the receiver to echo back the point up to which it has received > all frames, and the sender shouldn't reference state that the receiver > hasn't fully assimilated yet. It feels like adding application-level ACK= s > to me, which I'd like to avoid. > > HPACK is also one of the reasons for the two-stream-per-request approach. > There are two reasons for this -- one is that HPACK frames (in the curren= t > design) can't be lost when a stream is RST, so the draft forbids resettin= g > control streams. Since we still need to be able to RST requests, we add > the semantic that killing the data stream implies the same thing about th= e > control stream. It's messy, and hopefully we can remove that once HPACK = is > fixed. The second, as you guessed, is not dealing with DATA frames. #24= 5 > notes that, if we fix HPACK, we could go back to a single stream per > request; proponents of both "keep framing out of the way" and "fewer > streams is easier to manage" have weighed in there. Please add your voic= e. > > As to buffering, it's actually easy enough -- just don't read from data > streams until you've seen the headers. Sure, the sender will fill up the= ir > flow control window on that stream -- and then they'll stop and send you > QUIC BLOCKED frames, until you start reading the body and generating > WINDOW_UPDATE frames. One of the biggest arguments for two streams in my > mind is making sure that a request blocked in this way doesn't impede the > flow of control frames on that stream -- for example, should we > successfully get certificate auth frames added, a certificate request. > I've had two customers this week telling me it's a bug in our server code > that their TLS reneg gets stuck in TCP buffers behind a giant request bod= y, > because the server won't read an unauthenticated body and the client won'= t > hold off sending the body until authentication succeeds. I'd like to see > blocks like that become less possible in QUIC, at least. > > Yes, making SETTINGS immutable reduces the flexibility. The opinion at > the interim was that we could live without it, as we know of exactly one > implementation of one extension that does mid-stream setting changes, and= I > own it. =F0=9F=98=8A If there's a compelling use case for changing sett= ings > mid-stream we weren't aware of, that's new information that could justify > the complexity. (But note that with 0-RTT connection setup, it would be > nearly as cheap to open a new connection with the new setting and > transition your traffic to it.) > > Negotiation still works, since each side would simply advertise that they > support an extension or not, and consider the extension to be active once > you've seen the other side's SETTINGS frame. See > https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5.3 for > the complexity this allowed us to remove. An extension could add to the > list easily -- if you support extension X, you should also remember the > value for setting X_VAL. Clients that don't use the extension don't care= . > An extension that needed some more complex negotiation would have to use = an > extension-specific frame, it's true, but we haven't so far seen an > extension do that. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing > Sent: Wednesday, March 15, 2017 6:22 AM > To: Martin Thomson ; IETF QUIC WG > > Subject: Re: Core drafts -02 out > > > > Am 14.03.2017 um 00:57 schrieb Martin Thomson >: > > > > The editors have submitted -02 versions of the base set of QUIC drafts. > [...] > > https://tools.ietf.org/html/draft-ietf-quic-http-02 > > Thanks, Martin! I assume that was announced to get feedback from the > lurkers here. ;-) > > I'll give this a try. All mistakes and misunderstandings are mine alone. > > ------------------------------------------------------------ > ----------------------------- > > Very well written spec. Easy to understand for someone having read rfc > 7540 a bit. > > I have some comments to the proposed HTTP mapping approach. Where the wg > has already discussed and exhausted alternatives, please excuse my > ignorance and ignore my comments. I had not the time to follow all > discussions ongoing on this topic. Feel free to cherry-pick what seems > helpful. > > > > 4. Stream Mapping and Usage > > +1 to directly using quic stream ids instead of virtual h2 stream > +identifier > > > However, using 2 quic streams for a single request/response does not sit > well with me. I assume that stems from the wish to get rid of DATA frames= . > Which sounds nice, but is it worth it? By doubling the # of streams for a > client, how much overhead does that introduce (I speak of a server holdin= g > >10k quic "connections")? > > Also, the server needs to buffer data on quic streams 7, 11, 15, etc. > because HEADERs might arrive some time in the future on streams 5, 9, 13, > etc. or not. There is no way to route this data somewhere, because the me= ta > information is still missing. > > And there is still Holb on: > > > 4.2.1. Header Compression > > ... > > DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- > > invariant? How much do we need to retain compatibility with > > HTTP/2's HPACK? > > Using a counter in HEADERS is a crutch: > - it is a highly specific solution to a common problem in http/quic: > synchronicity in connection level state changes. SETTINGS (see below) has > the same problem, as does have PRIORITY in HEADERS. It seems that > performance wise, all HEADERS could as well be sent on stream 3. > > Now, solving Hol blocking for HEADERS would be a fine achievement. > > > 5. HTTP Framing Layer > > Frames are used only on the connection (stream 3) and message > > (streams 5, 9, etc.) control streams. > > And streams 4, 8, 12, etc. I assume. > > > 5.2.3. SETTINGS > > ... > > SETTINGS frames always apply to a connection, never a single stream. > > A SETTINGS frame MUST be sent as the first frame of the connection > > control stream (see Section 4) by each peer, and MUST NOT be sent > > subsequently or on any other stream. If an endpoint receives an > > SETTINGS frame on a different stream, the endpoint MUST respond with > > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an > > endpoint receives a second SETTINGS frame, the endpoint MUST respond > > with a connection error of type HTTP_MULTIPLE_SETTINGS. > > What about HPACK state? The connection state change problem again visible= . > > This is a severe restriction on extensions mechanisms that want to affect > a connection. Because if the http/quic does not solve this problem, how a= re > they expected to do it? They either announce themselves on the first > SETTINGS or remain silent forever, it seems. How would an extension > handshake work then? Own stream 3 handshake frames? > > > 5.2.3.3. Usage in 0-RTT > > What about HPACK state? Does it need to be kept or is it reset? > > > HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push > > content which the client has cached. > > ... > > HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the > > requested data. > > Nitpick: seems redundant. The first could be replaced by the second. > Stream number will suffice. > > ---------------------------------------------------------- > > Taking two steps back: > > I think the main difficulty comes from the lack of a "hq connection state= " > concept and how changes to that state can be managed. Evidence: > - The 0-RTT mentions certain SETTINGS that need to be remembered by a > client. How would an extension add to this? Will every extension have to > come up with its own solution? > - The HEADERs sequence number is a highly specific fix for the missing > state change > - The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 > mechanism > > If hq defines stream 3 as the place where connection state changes happen > *AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and serv= er > can have shareable concept of the connection state. > > > I am no HPACK expert. The basic problem looks like concurrent editing > against a repository. > Both client and server start with connection state zero (CS-0) and the > predefined HPACK dictionary (HP-0). After SETTINGS exchange, client is in > CS-1 and server is in CS-2 for its side. Let's call the CS-1 HPACK state > HP-1. > > Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). > The HEADERS carries the connection state number it is based on (CS-1). > Client sends new HEADERS on stream 9, also based on CS-1. Client keeps th= at > delta around (HP-1.9). > > Client then decides to announce a new connection state (CS-3) by sending > how it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The > description allows the server to update its HP-1 to HP-3 as well. > > Response HEADERS are also based on a server connection state, explicitly, > so the client knows which HP-X to use when decoding them. At some time, t= he > server sends an announcment of CS-4 with HPACK data on stream 3 back to t= he > client. > > For a 0-RTT, client and server could exchange the connection state id in > the initial SETTINGS, to make sure they have at least the same name > remembered as the other side. Client: "I was in CS-19 and you were in > CS-8." Server: "Yep." > > By implicitly adding all SETTINGS changes to connection states, the > problem is also solved for extensions. > > If one side receives HEADERS with an unknown connection state: > - if the state id is greater than any known one: set a stream timeout and > wait for changes on stream 3 to arrive > - state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE > > New SETTINGS value: MAX_CONN_STATE number of maximum connection state the > client/server is willing to keep, exchanged initially. Announcing a new > connection state allows the other side to drop the lowest one, if > MAX_CONN_STATE are used. > > To get optimal HPACK size compression, every HEADERs would also announce = a > new connections state. To have less potential HOLB, connection states do > not change during request bursts. > > Something like that. > > -Stefan > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --f403045ef6540ee39e054b6a127a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 23, 2017 at 1:52 PM, Mike Bishop <Michael.Bishop@micros= oft.com> wrote:

All I see in the links are http:// and the draft nam= e, no host.=C2=A0 I=E2=80=99m guessing you meant https://github.com/krasic/draft-krasic-quic-hpack/blob/master/dra= ft-krasic-quic-hpack-00.html?=C2=A0 Once the tracker reopens (some= time Sunday, I think) you should probably upload those at datatracker.ietf.org to make i= t an official submission.=C2=A0 You=E2=80=99ll need to make the draft name in the file match the file name= before it will successfully upload.

=C2=A0

Also, for ease of discussion, you might pick a= different name than QPACK, since there=E2=80=99s already a draft with that= name.=C2=A0 (Or we both change names, and call the eventually-adopted one = QPACK; that=E2=80=99d be fine, too.)


Just= on this one point: I like QPACK for the final one. Maybe it's fine to = call it krasic-qpack and bishop-qpack for now?

- j= ana
=C2=A0

=C2=A0

As to actual feedback:=C2=A0 I see what you=E2= =80=99re getting at here because you=E2=80=99ve explained it =E2=80=93 the = decoder acknowledges the sequence number it=E2=80=99s up to, then the encod= er tracks that and uses it on the encode side.=C2=A0 I think I=E2=80=99d have a really hard time parsing the= document without that.=C2=A0 I think the strongest advantage of this propo= sal is that an encoder for this scheme could be used over HTTP/2, enabling = shared code; you should bring that out more.

=C2=A0

The way you=E2=80=99ve described the encoder r= equires tight integration between the packetization logic and the header co= mpressor in two ways:

  • It needs to know the =E2=80=9Cpacket epoch=E2=80=9D (encode epoch= of the first frame in the current packet) while compressing, but until you= know the size of the compressed output, you can=E2=80=99t know whether it will fit in th= e current packet.=C2=A0 That in turn means you=E2=80=99ll need to roll back= any state and re-encode with a different packet epoch if it turns out not = to fit.
  • The =E2=80=9Ccommit epoch=E2=80= =9D is determined, not by data at the compressor level, but by reaching int= o the transport and checking which packets containing the STREAM frames containing the HPACK data in question have been acknowle= dged.=C2=A0 Also note that ACK doesn=E2=80=99t signify delivery to the appl= ication layer (HTTP), just presence in the appropriate queue.=

=C2=A0

In 2.2.1.1, the encoder is informed whether = =E2=80=9CQPACK is enabled,=E2=80=9D but since that can be toggled on/off on= a per-header-frame basis (and I hope you really meant per-header-block), i= t seems like the decoder is just following the encoder=E2=80=99s lead on this.=C2=A0 Who=E2= =80=99s actually making that decision?=C2=A0 You say it gets turned off if = a drop results, but the encoder is the one who knows/determines that.

=C2=A0

This has the same problem as the current HPACK= state that RST on a control stream loses critical data and there=E2=80=99s= no way to recover.=C2=A0 I=E2=80=99m personally hoping we can make our way= out of that requirement.

=C2=A0

From: Charles 'Buck' Krasic [mailto:<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com]
Sent: Tuesday, March 21, 2017 6:04 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>; Martin Thom= son <marti= n.thomson@gmail.com>; IETF QUIC WG <quic@ietf.org>


Subject: Re: Core drafts -02 out

=C2=A0

Hi Folks.

=C2=A0

I've put together a first attempt at my QPACK pr= oposal:

=C2=A0

=C2=A0

Apologies in advance, this is my first attempt at an= IETF draft.

=C2=A0

=C2=A0

On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop <Michael.Bis= hop@microsoft.com> wrote:

Thanks for the feedback!

Yes, you've run straight into the big quandary with HPACK.=C2=A0 I don&= #39;t think anyone expects that we will ship this way; I have a proposal in https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack = for an HPACK-replacement that would solve many of these.=C2=A0 Buck Krasic = has a proposal which he has sketched in e-mail but not submitted as a draft= .=C2=A0 The main point of the sequence number was to get us off the "everything on stream 3" model and let us sort ou= t the problems of HPACK later.=C2=A0 #228 tracks fixing HPACK, in whatever = form that takes.

We could solve it in the same way that we did PRIORITY, by adding an "= affected stream number" field and moving the HEADERS/PUSH_PROMISE fram= es to Stream 3 as well.=C2=A0 However, that is just as blocking as the curr= ent approach, so not really an improvement.=C2=A0 Worse, the reason we can tolerate large header frames is because they occur on th= eir own streams and don't block arrival of data from other streams.=C2= =A0 If all headers occur on a single stream, that's not true -- you *ar= e* blocking muxing of other streams again.

I like the comparison to concurrent edits.=C2=A0 We've discussed having= rolling deltas in various mechanisms; the problem is that it requires reac= hing into the transport for ACK state to figure out when you can discard ol= d deltas for good on the receiver side.=C2=A0 Buck's proposal is similar, essentially requiring the receiver to echo= back the point up to which it has received all frames, and the sender shou= ldn't reference state that the receiver hasn't fully assimilated ye= t.=C2=A0 It feels like adding application-level ACKs to me, which I'd like to avoid.

HPACK is also one of the reasons for the two-stream-per-request approach.= =C2=A0 There are two reasons for this -- one is that HPACK frames (in the c= urrent design) can't be lost when a stream is RST, so the draft forbids= resetting control streams.=C2=A0 Since we still need to be able to RST requests, we add the semantic that killing the data= stream implies the same thing about the control stream.=C2=A0 It's mes= sy, and hopefully we can remove that once HPACK is fixed.=C2=A0 The second,= as you guessed, is not dealing with DATA frames.=C2=A0 #245 notes that, if we fix HPACK, we could go back to a single stream per = request; proponents of both "keep framing out of the way" and &qu= ot;fewer streams is easier to manage" have weighed in there.=C2=A0 Ple= ase add your voice.

As to buffering, it's actually easy enough -- just don't read from = data streams until you've seen the headers.=C2=A0 Sure, the sender will= fill up their flow control window on that stream -- and then they'll s= top and send you QUIC BLOCKED frames, until you start reading the body and generating WINDOW_UPDATE frames.=C2=A0 One of the big= gest arguments for two streams in my mind is making sure that a request blo= cked in this way doesn't impede the flow of control frames on that stre= am -- for example, should we successfully get certificate auth frames added, a certificate request.=C2=A0 I've h= ad two customers this week telling me it's a bug in our server code tha= t their TLS reneg gets stuck in TCP buffers behind a giant request body, be= cause the server won't read an unauthenticated body and the client won't hold off sending the body until authenticati= on succeeds.=C2=A0 I'd like to see blocks like that become less possibl= e in QUIC, at least.

Yes, making SETTINGS immutable reduces the flexibility.=C2=A0 The opinion a= t the interim was that we could live without it, as we know of exactly one = implementation of one extension that does mid-stream setting changes, and I= own it.=C2=A0 =F0=9F=98= =8A=C2=A0 If there's a compelling use case for changing settings= mid-stream we weren't aware of, that's new information that could = justify the complexity.=C2=A0 (But note that with 0-RTT connection setup, i= t would be nearly as cheap to open a new connection with the new setting and= transition your traffic to it.)

Negotiation still works, since each side would simply advertise that they s= upport an extension or not, and consider the extension to be active once yo= u've seen the other side's SETTINGS frame.=C2=A0 See https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5= .3 for the complexity this allowed us to remove.=C2=A0 An extension cou= ld add to the list easily -- if you support extension X, you should also re= member the value for setting X_VAL.=C2=A0 Clients that don't use the extension don't care.=C2=A0 An extension that needed= some more complex negotiation would have to use an extension-specific fram= e, it's true, but we haven't so far seen an extension do that.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing
Sent: Wednesday, March 15, 2017 6:22 AM
To: Martin Thomson <martin.thomson@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Core drafts -02 out


> Am 14.03.2017 um 00:57 schrieb Martin Thomson <martin.thomson@gmail.com>:=
>
> The editors have submitted -02 versions of the base set of QUIC drafts= .
[...]
> https://tools.ietf.org/html/draft-ietf-quic-http-02
Thanks, Martin! I assume that was announced to get feedback from the lurker= s here. ;-)

I'll give this a try. All mistakes and misunderstandings are mine alone= .

-----------------------------------------------------------------= ------------------------

Very well written spec. Easy to understand for someone having read rfc 7540= a bit.

I have some comments to the proposed HTTP mapping approach. Where the wg ha= s already discussed and exhausted alternatives, please excuse my ignorance = and ignore my comments. I had not the time to follow all discussions ongoin= g on this topic. Feel free to cherry-pick what seems helpful.


> 4.=C2=A0 Stream Mapping and Usage

+1 to directly using quic stream ids instead of virtual h2 stream
+identifier


However, using 2 quic streams for a single request/response does not sit we= ll with me. I assume that stems from the wish to get rid of DATA frames. Wh= ich sounds nice, but is it worth it? By doubling the # of streams for a cli= ent, how much overhead does that introduce (I speak of a server holding >10k quic "connections"= ;)?

Also, the server needs to buffer data on quic streams 7, 11, 15, etc. becau= se HEADERs might arrive some time in the future on streams 5, 9, 13, etc. o= r not. There is no way to route this data somewhere, because the meta infor= mation is still missing.

And there is still Holb on:

> 4.2.1.=C2=A0 Header Compression
> ...
> DISCUSS:=C2=A0 Keep HPACK with HOLB?=C2=A0 Redesign HPACK to be order-=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0invariant?=C2=A0 How much do we need to reta= in compatibility with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/2's HPACK?

Using a counter in HEADERS is a crutch:
- it is a highly specific solution to a common problem in http/quic: synchr= onicity in connection level state changes. SETTINGS (see below) has the sam= e problem, as does have PRIORITY in HEADERS. It seems that performance wise= , all HEADERS could as well be sent on stream 3.

Now, solving Hol blocking for HEADERS would be a fine achievement.

> 5.=C2=A0 HTTP Framing Layer
> Frames are used only on the connection (stream 3) and message
>=C2=A0 =C2=A0 (streams 5, 9, etc.) control streams.

And streams 4, 8, 12, etc. I assume.

> 5.2.3.=C2=A0 SETTINGS
> ...
> SETTINGS frames always apply to a connection, never a single stream. >=C2=A0 A SETTINGS frame MUST be sent as the first frame of the connecti= on
> control stream (see Section 4) by each peer, and MUST NOT be sent
> subsequently or on any other stream.=C2=A0 If an endpoint receives an<= br> > SETTINGS frame on a different stream, the endpoint MUST respond with > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM.=C2=A0 I= f an
> endpoint receives a second SETTINGS frame, the endpoint MUST respond > with a connection error of type HTTP_MULTIPLE_SETTINGS.

What about HPACK state? The connection state change problem again visible.<= br>
This is a severe restriction on extensions mechanisms that want to affect a= connection. Because if the http/quic does not solve this problem, how are = they expected to do it? They either announce themselves on the first SETTIN= GS or remain silent forever, it seems. How would an extension handshake work then? Own stream 3 handshake = frames?

> 5.2.3.3.=C2=A0 Usage in 0-RTT

What about HPACK state? Does it need to be kept or is it reset?

> HTTP_PUSH_ALREADY_IN_CACHE (0x03):=C2=A0 The server has attempted to p= ush
>=C2=A0 =C2=A0 =C2=A0 content which the client has cached.
> ...
> HTTP_REQUEST_CANCELLED (0x04):=C2=A0 The client no longer needs the >=C2=A0 =C2=A0 =C2=A0requested data.

Nitpick: seems redundant. The first could be replaced by the second. Stream= number will suffice.

----------------------------------------------------------

Taking two steps back:

I think the main difficulty comes from the lack of a "hq connection st= ate" concept and how changes to that state can be managed. Evidence: - The 0-RTT mentions certain SETTINGS that need to be remembered by a clien= t. How would an extension add to this? Will every extension have to come up= with its own solution?
- The HEADERs sequence number is a highly specific fix for the missing stat= e change
- The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 m= echanism

If hq defines stream 3 as the place where connection state changes happen *= AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and server = can have shareable concept of the connection state.


I am no HPACK expert. The basic problem looks like concurrent editing again= st a repository.
Both client and server start with connection state zero (CS-0) and the pred= efined HPACK dictionary (HP-0). After SETTINGS exchange, client is in CS-1 = and server is in CS-2 for its side. Let's call the=C2=A0 CS-1 HPACK sta= te HP-1.

Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). Th= e HEADERS carries the connection state number it is based on (CS-1). Client= sends new HEADERS on stream 9, also based on CS-1. Client keeps that delta= around (HP-1.9).

Client then decides to announce a new connection state (CS-3) by sending ho= w it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The descrip= tion allows the server to update its HP-1 to HP-3 as well.

Response HEADERS are also based on a server connection state, explicitly, s= o the client knows which HP-X to use when decoding them. At some time, the = server sends an announcment of CS-4 with HPACK data on stream 3 back to the= client.

For a 0-RTT, client and server could exchange the connection state id in th= e initial SETTINGS, to make sure they have at least the same name remembere= d as the other side. Client: "I was in CS-19 and you were in CS-8.&quo= t; Server: "Yep."

By implicitly adding all SETTINGS changes to connection states, the problem= is also solved for extensions.

If one side receives HEADERS with an unknown connection state:
- if the state id is greater than any known one: set a stream timeout and w= ait for changes on stream 3 to arrive
- state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE
New SETTINGS value: MAX_CONN_STATE number of maximum connection state the c= lient/server is willing to keep, exchanged initially. Announcing a new conn= ection state allows the other side to drop the lowest one, if MAX_CONN_STAT= E are used.

To get optimal HPACK size compression, every HEADERs would also announce a = new connections state. To have less potential HOLB, connection states do no= t change during request bursts.

Something like that.

-Stefan



=C2=A0

--

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


--f403045ef6540ee39e054b6a127a-- From nobody Thu Mar 23 11:58:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4311E131622 for ; Thu, 23 Mar 2017 11:58:01 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iLqynr1JscDW for ; Thu, 23 Mar 2017 11:57:57 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354FE129C01 for ; Thu, 23 Mar 2017 11:57:57 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id b140so3383916iof.1 for ; Thu, 23 Mar 2017 11:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GWIoDzg+3iZaninG7gPu6DYF8sLerlwSAV2J6VxqLig=; b=mkD9w6KxeZ9lV8mPwCyMMXQBKRYFL6MtsbZbXkEhl2xNm+DHIzHMsFojayO7CH3/s/ dJTM05DFRFadaumfrk/235GCaymbF6+XJJr491ZV/+raObWnmrH/TOOy7rbAxrnqtE+E /IgFWOVCfrX3XAyVyjj8sULfcLUgTzXFIwiyYOpJf/7uiwAyqsKVi73s8SV5gCqfx9G7 EsigeaEAEHYSm+YduN4/ffuh3XhaE6fQvVSjU4/fDu/horAr9Veeps4QcFl5DixFvTB2 KndcywHSC7QLYngzvNIUScT52OqyKK9WCN/6al0S6w3UnzWtpD1TYOIBZewihvVbqxzQ jqtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GWIoDzg+3iZaninG7gPu6DYF8sLerlwSAV2J6VxqLig=; b=Kcr1LJGxe1iI4xQ4oq7Q/w1ltGy8GlS7DDMtHozNFYIcj+XuTuU7bRy6UoAljYZ+8d QsuHXRFuPUICZkcv75Ta/uVme5K35T3mmL5elYHl1iUlhLi8QSRqHP6jfhpwQR2rO1mr TXA7us5TLTCllbqRrXOxLsk8zETBDQ5JNN5dDleiLwbclGlrZsje9CQZwkI7MHHqfrwj h/76KLzCAgymyoIpXf3PPyN3mdZHx7XkKWS130JTWxim1UijhqIDUR3QMJezcob0ALI6 DkKtyky86HfJcZciq5hKTtGGSiCrROZi3gB4b2/jJ8+rmXs7zq/htq+X8IHB+oIXmW4P lryA== X-Gm-Message-State: AFeK/H0hQ1FYliQ/J6yHqC2bQKe0QvPlTnx4lC1hHirVgT5P5UgAJvIDGkXDHR5a88c2r+RVY+pYuw1KshYygkkT X-Received: by 10.107.11.215 with SMTP id 84mr4059789iol.41.1490295476254; Thu, 23 Mar 2017 11:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Thu, 23 Mar 2017 11:57:55 -0700 (PDT) Received: by 10.36.200.4 with HTTP; Thu, 23 Mar 2017 11:57:55 -0700 (PDT) In-Reply-To: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> From: "Charles 'Buck' Krasic" Date: Thu, 23 Mar 2017 11:57:55 -0700 Message-ID: Subject: Re: Core drafts -02 out To: Mike Bishop Cc: Stefan Eissing , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113f8a74794560054b6a7491 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 18:58:01 -0000 --001a113f8a74794560054b6a7491 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 23, 2017 at 10:52 AM, Mike Bishop wrote: > All I see in the links are http:// and the draft name, no host. I=E2=80= =99m > guessing you meant https://github.com/krasic/draf > t-krasic-quic-hpack/blob/master/draft-krasic-quic-hpack-00.html? Once > the tracker reopens (sometime Sunday, I think) you should probably upload > those at datatracker.ietf.org to make it an official submission. You=E2= =80=99ll > need to make the draft name in the file match the file name before it wil= l > successfully upload. > > > Thanks for the prompt feedback! Apologies, as I mentioned it is my first attempt at an IETF draft, and it my first time using the tools as described in SETUP.md . Until I the tracker reopens and I submit properly, I would suggest https://krasic.github.io/draft-krasic-quic-hpack/dra ft-krasic-quic-qpack-latest.html > Also, for ease of discussion, you might pick a different name than QPACK, > since there=E2=80=99s already a draft with that name. (Or we both change= names, > and call the eventually-adopted one QPACK; that=E2=80=99d be fine, too.) > I'm fine with whatever. If draft-krasic vs draft-bishop isn't enough to differentiate, how about QPACK-ALT, or maybe QPACK-LITE? > > > As to actual feedback: I see what you=E2=80=99re getting at here because= you=E2=80=99ve > explained it =E2=80=93 the decoder acknowledges the sequence number it=E2= =80=99s up to, > then the encoder tracks that and uses it on the encode side. I think I= =E2=80=99d > have a really hard time parsing the document without that. I think the > strongest advantage of this proposal is that an encoder for this scheme > could be used over HTTP/2, enabling shared code; you should bring that ou= t > more. > I'll try to rework the text to emphise those points more and clarify. Nits: the decoder per-se doesn't ack, but the encoder tracks using existing transport level ack mechanisms (more on this below). Also, I think of this scheme as something a shared implementation could offer as an option, but I hadn't imagined the option would be ever be enabled in HTTP/2. It might be interesting to consider though. > > > The way you=E2=80=99ve described the encoder requires tight integration b= etween > the packetization logic and the header compressor in two ways: > > - It needs to know the =E2=80=9Cpacket epoch=E2=80=9D (encode epoch of= the first frame > in the current packet) while compressing, but until you know the size = of > the compressed output, you can=E2=80=99t know whether it will fit in t= he current > packet. That in turn means you=E2=80=99ll need to roll back any state= and > re-encode with a different packet epoch if it turns out not to fit. > > I don't think roll back is esssential. The space available in the current packet could be known when invoking the hpack encoder, so it would stop emitting representations if the packet reaches the space limit, and in that case return a header block that for a prefix of the provided header field list, and in later packets it would generate a continuation header block(s) for remaining header fields. > - > - The =E2=80=9Ccommit epoch=E2=80=9D is determined, not by data at the= compressor > level, but by reaching into the transport and checking which packets > containing the STREAM frames containing the HPACK data in question hav= e > been acknowledged. Also note that ACK doesn=E2=80=99t signify deliver= y to the > application layer (HTTP), just presence in the appropriate queue. > > > My understanding is that APIs are out of scope of most of the docs. However, in our implementation, the stream write interfaces uniformly provide a means of to confirm acknowledgement, so it is possible to do it without reaching down. I agree that ACK doesn't signify delivery to what is above HTTP, but one of advantages of not having legacy APIs (POSIX sockets) between QUIC and HTTP is that the implemenation can certainly ensure that ACK signifies delivery to HTTP. > In 2.2.1.1, the encoder is informed whether =E2=80=9CQPACK is enabled,=E2= =80=9D but since > that can be toggled on/off on a per-header-frame basis (and I hope you > really meant per-header-block), it seems like the decoder is just followi= ng > the encoder=E2=80=99s lead on this. Who=E2=80=99s actually making that d= ecision? You say > it gets turned off if a drop results, but the encoder is the one who > knows/determines that. > Yes, all decisions are made by the encoder, and as in HPACK the decoder strictly follows the encoder's lead. The "informed" language was simply alluding to the encoder side of the HPACK API being extended with QPACK related params. And yes, I meant "header block". Will fix that. This has the same problem as the current HPACK state that RST on a control > stream loses critical data and there=E2=80=99s no way to recover. I=E2= =80=99m personally > hoping we can make our way out of that requirement. > My position is that REFUSED should be the only kind of RST needed or allowed for control streams, and dealing with that is tractible. > > *From:* Charles 'Buck' Krasic [mailto:ckrasic@google.com] > *Sent:* Tuesday, March 21, 2017 6:04 PM > *To:* Mike Bishop > *Cc:* Stefan Eissing ; Martin Thomson < > martin.thomson@gmail.com>; IETF QUIC WG > > *Subject:* Re: Core drafts -02 out > > > > Hi Folks. > > > > I've put together a first attempt at my QPACK proposal: > > > > draft-krasic-quic-hpack-00.html > > draft-krasic-quic-hpack-00.txt > > > > > Apologies in advance, this is my first attempt at an IETF draft. > > > > > > On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > > Thanks for the feedback! > > Yes, you've run straight into the big quandary with HPACK. I don't think > anyone expects that we will ship this way; I have a proposal in > https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack for an > HPACK-replacement that would solve many of these. Buck Krasic has a > proposal which he has sketched in e-mail but not submitted as a draft. T= he > main point of the sequence number was to get us off the "everything on > stream 3" model and let us sort out the problems of HPACK later. #228 > tracks fixing HPACK, in whatever form that takes. > > We could solve it in the same way that we did PRIORITY, by adding an > "affected stream number" field and moving the HEADERS/PUSH_PROMISE frames > to Stream 3 as well. However, that is just as blocking as the current > approach, so not really an improvement. Worse, the reason we can tolerat= e > large header frames is because they occur on their own streams and don't > block arrival of data from other streams. If all headers occur on a sing= le > stream, that's not true -- you *are* blocking muxing of other streams aga= in. > > I like the comparison to concurrent edits. We've discussed having rollin= g > deltas in various mechanisms; the problem is that it requires reaching in= to > the transport for ACK state to figure out when you can discard old deltas > for good on the receiver side. Buck's proposal is similar, essentially > requiring the receiver to echo back the point up to which it has received > all frames, and the sender shouldn't reference state that the receiver > hasn't fully assimilated yet. It feels like adding application-level ACK= s > to me, which I'd like to avoid. > > HPACK is also one of the reasons for the two-stream-per-request approach. > There are two reasons for this -- one is that HPACK frames (in the curren= t > design) can't be lost when a stream is RST, so the draft forbids resettin= g > control streams. Since we still need to be able to RST requests, we add > the semantic that killing the data stream implies the same thing about th= e > control stream. It's messy, and hopefully we can remove that once HPACK = is > fixed. The second, as you guessed, is not dealing with DATA frames. #24= 5 > notes that, if we fix HPACK, we could go back to a single stream per > request; proponents of both "keep framing out of the way" and "fewer > streams is easier to manage" have weighed in there. Please add your voic= e. > > As to buffering, it's actually easy enough -- just don't read from data > streams until you've seen the headers. Sure, the sender will fill up the= ir > flow control window on that stream -- and then they'll stop and send you > QUIC BLOCKED frames, until you start reading the body and generating > WINDOW_UPDATE frames. One of the biggest arguments for two streams in my > mind is making sure that a request blocked in this way doesn't impede the > flow of control frames on that stream -- for example, should we > successfully get certificate auth frames added, a certificate request. > I've had two customers this week telling me it's a bug in our server code > that their TLS reneg gets stuck in TCP buffers behind a giant request bod= y, > because the server won't read an unauthenticated body and the client won'= t > hold off sending the body until authentication succeeds. I'd like to see > blocks like that become less possible in QUIC, at least. > > Yes, making SETTINGS immutable reduces the flexibility. The opinion at > the interim was that we could live without it, as we know of exactly one > implementation of one extension that does mid-stream setting changes, and= I > own it. =F0=9F=98=8A If there's a compelling use case for changing sett= ings > mid-stream we weren't aware of, that's new information that could justify > the complexity. (But note that with 0-RTT connection setup, it would be > nearly as cheap to open a new connection with the new setting and > transition your traffic to it.) > > Negotiation still works, since each side would simply advertise that they > support an extension or not, and consider the extension to be active once > you've seen the other side's SETTINGS frame. See > https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5.3 for > the complexity this allowed us to remove. An extension could add to the > list easily -- if you support extension X, you should also remember the > value for setting X_VAL. Clients that don't use the extension don't care= . > An extension that needed some more complex negotiation would have to use = an > extension-specific frame, it's true, but we haven't so far seen an > extension do that. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing > Sent: Wednesday, March 15, 2017 6:22 AM > To: Martin Thomson ; IETF QUIC WG > > Subject: Re: Core drafts -02 out > > > > Am 14.03.2017 um 00:57 schrieb Martin Thomson >: > > > > The editors have submitted -02 versions of the base set of QUIC drafts. > [...] > > https://tools.ietf.org/html/draft-ietf-quic-http-02 > > Thanks, Martin! I assume that was announced to get feedback from the > lurkers here. ;-) > > I'll give this a try. All mistakes and misunderstandings are mine alone. > > ------------------------------------------------------------ > ----------------------------- > > Very well written spec. Easy to understand for someone having read rfc > 7540 a bit. > > I have some comments to the proposed HTTP mapping approach. Where the wg > has already discussed and exhausted alternatives, please excuse my > ignorance and ignore my comments. I had not the time to follow all > discussions ongoing on this topic. Feel free to cherry-pick what seems > helpful. > > > > 4. Stream Mapping and Usage > > +1 to directly using quic stream ids instead of virtual h2 stream > +identifier > > > However, using 2 quic streams for a single request/response does not sit > well with me. I assume that stems from the wish to get rid of DATA frames= . > Which sounds nice, but is it worth it? By doubling the # of streams for a > client, how much overhead does that introduce (I speak of a server holdin= g > >10k quic "connections")? > > Also, the server needs to buffer data on quic streams 7, 11, 15, etc. > because HEADERs might arrive some time in the future on streams 5, 9, 13, > etc. or not. There is no way to route this data somewhere, because the me= ta > information is still missing. > > And there is still Holb on: > > > 4.2.1. Header Compression > > ... > > DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- > > invariant? How much do we need to retain compatibility with > > HTTP/2's HPACK? > > Using a counter in HEADERS is a crutch: > - it is a highly specific solution to a common problem in http/quic: > synchronicity in connection level state changes. SETTINGS (see below) has > the same problem, as does have PRIORITY in HEADERS. It seems that > performance wise, all HEADERS could as well be sent on stream 3. > > Now, solving Hol blocking for HEADERS would be a fine achievement. > > > 5. HTTP Framing Layer > > Frames are used only on the connection (stream 3) and message > > (streams 5, 9, etc.) control streams. > > And streams 4, 8, 12, etc. I assume. > > > 5.2.3. SETTINGS > > ... > > SETTINGS frames always apply to a connection, never a single stream. > > A SETTINGS frame MUST be sent as the first frame of the connection > > control stream (see Section 4) by each peer, and MUST NOT be sent > > subsequently or on any other stream. If an endpoint receives an > > SETTINGS frame on a different stream, the endpoint MUST respond with > > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an > > endpoint receives a second SETTINGS frame, the endpoint MUST respond > > with a connection error of type HTTP_MULTIPLE_SETTINGS. > > What about HPACK state? The connection state change problem again visible= . > > This is a severe restriction on extensions mechanisms that want to affect > a connection. Because if the http/quic does not solve this problem, how a= re > they expected to do it? They either announce themselves on the first > SETTINGS or remain silent forever, it seems. How would an extension > handshake work then? Own stream 3 handshake frames? > > > 5.2.3.3. Usage in 0-RTT > > What about HPACK state? Does it need to be kept or is it reset? > > > HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push > > content which the client has cached. > > ... > > HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the > > requested data. > > Nitpick: seems redundant. The first could be replaced by the second. > Stream number will suffice. > > ---------------------------------------------------------- > > Taking two steps back: > > I think the main difficulty comes from the lack of a "hq connection state= " > concept and how changes to that state can be managed. Evidence: > - The 0-RTT mentions certain SETTINGS that need to be remembered by a > client. How would an extension add to this? Will every extension have to > come up with its own solution? > - The HEADERs sequence number is a highly specific fix for the missing > state change > - The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 > mechanism > > If hq defines stream 3 as the place where connection state changes happen > *AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and serv= er > can have shareable concept of the connection state. > > > I am no HPACK expert. The basic problem looks like concurrent editing > against a repository. > Both client and server start with connection state zero (CS-0) and the > predefined HPACK dictionary (HP-0). After SETTINGS exchange, client is in > CS-1 and server is in CS-2 for its side. Let's call the CS-1 HPACK state > HP-1. > > Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). > The HEADERS carries the connection state number it is based on (CS-1). > Client sends new HEADERS on stream 9, also based on CS-1. Client keeps th= at > delta around (HP-1.9). > > Client then decides to announce a new connection state (CS-3) by sending > how it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The > description allows the server to update its HP-1 to HP-3 as well. > > Response HEADERS are also based on a server connection state, explicitly, > so the client knows which HP-X to use when decoding them. At some time, t= he > server sends an announcment of CS-4 with HPACK data on stream 3 back to t= he > client. > > For a 0-RTT, client and server could exchange the connection state id in > the initial SETTINGS, to make sure they have at least the same name > remembered as the other side. Client: "I was in CS-19 and you were in > CS-8." Server: "Yep." > > By implicitly adding all SETTINGS changes to connection states, the > problem is also solved for extensions. > > If one side receives HEADERS with an unknown connection state: > - if the state id is greater than any known one: set a stream timeout and > wait for changes on stream 3 to arrive > - state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE > > New SETTINGS value: MAX_CONN_STATE number of maximum connection state the > client/server is willing to keep, exchanged initially. Announcing a new > connection state allows the other side to drop the lowest one, if > MAX_CONN_STATE are used. > > To get optimal HPACK size compression, every HEADERs would also announce = a > new connections state. To have less potential HOLB, connection states do > not change during request bursts. > > Something like that. > > -Stefan > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 <(408)%20412-1141> --001a113f8a74794560054b6a7491 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 23, 2017 at 10:52 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

All I see in the links are http:// and the draft nam= e, no host.=C2=A0 I=E2=80=99m guessing you meant https://github.com/krasic/draft-krasic-quic-hpack/blob/master/dra= ft-krasic-quic-hpack-00.html?=C2=A0 Once the tracker reopens (some= time Sunday, I think) you should probably upload those at datatracker.ietf.org to make i= t an official submission.=C2=A0 You=E2=80=99ll need to make the draft name in the file match the file name= before it will successfully upload.

=C2=A0

Thanks for the prompt feedback!

Apologies, as I mentioned it is my first atte= mpt at an IETF draft, and it my first time using the tools as described in= =C2=A0SETUP.md.

Unti= l I the tracker reopens and I submit properly, I would suggest=C2=A0https://krasic.github.io/draft-krasic= -quic-hpack/draft-krasic-quic-qpack-latest.html
=C2= =A0

Also, for ease of discussion, you might pick a= different name than QPACK, since there=E2=80=99s already a draft with that= name.=C2=A0 (Or we both change names, and call the eventually-adopted one = QPACK; that=E2=80=99d be fine, too.)


I= 9;m fine with whatever.=C2=A0 If =C2=A0draft-krasic vs draft-bishop isn'= ;t enough to differentiate, =C2=A0how about QPACK-ALT, or maybe QPACK-LITE?= =C2=A0

<= u>

=C2=A0

As to actual feedback:=C2=A0 I see what you=E2= =80=99re getting at here because you=E2=80=99ve explained it =E2=80=93 the = decoder acknowledges the sequence number it=E2=80=99s up to, then the encod= er tracks that and uses it on the encode side.=C2=A0 I think I=E2=80=99d have a really hard time parsing the= document without that.=C2=A0 I think the strongest advantage of this propo= sal is that an encoder for this scheme could be used over HTTP/2, enabling = shared code; you should bring that out more.


I'll try to rework the text to emphise those p= oints more and clarify. =C2=A0=C2=A0

Nits: =C2=A0the decoder per-se doesn't ack, but the encode= r tracks using existing transport level ack mechanisms (more on this below)= . =C2=A0 Also, I think of this scheme as something a shared implementation = could offer as an option, but I hadn't imagined the option would be eve= r be enabled in HTTP/2.=C2=A0 It might be interesting to consider though.

<= /span>

=C2=A0

The way you=E2=80=99ve described the encoder r= equires tight integration between the packetization logic and the header co= mpressor in two ways:

  • It needs to know the = =E2=80=9Cpacket epoch=E2=80=9D (encode epoch of the first frame in the curr= ent packet) while compressing, but until you know the size of the compressed output, you can=E2=80=99t know whether it will fit in th= e current packet.=C2=A0 That in turn means you=E2=80=99ll need to roll back= any state and re-encode with a different packet epoch if it turns out not = to fit.
I don't think roll back is esssential. =C2=A0=C2=A0

The space available in the curren= t packet could be known when invoking the hpack encoder, so it would stop e= mitting representations if the packet reaches the space limit, and in that = case return a header block that for a prefix of the provided header field l= ist, and in later packets it would generate a continuation header block(s) = for remaining header fields.

    =
  • =
  • The =E2=80=9Ccom= mit epoch=E2=80=9D is determined, not by data at the compressor level, but = by reaching into the transport and checking which packets containing the STREAM frames containing the HPACK data in question have been acknowle= dged.=C2=A0 Also note that ACK doesn=E2=80=99t signify delivery to the appl= ication layer (HTTP), just presence in the appropriate queue.=

=C2=A0

My understanding is that APIs are ou= t of scope of most of the docs. =C2=A0 However, in our implementation, the = stream write interfaces uniformly provide a means of to confirm acknowledge= ment, =C2=A0so it is possible to do it without reaching down.=C2=A0

I agree that ACK doesn't si= gnify delivery to what is above HTTP, but one of advantages of not having l= egacy APIs (POSIX sockets) between QUIC and HTTP is that the implemenation = can certainly ensure that ACK signifies delivery to HTTP.

In 2.2.1.1, the encoder is informed whether = =E2=80=9CQPACK is enabled,=E2=80=9D but since that can be toggled on/off on= a per-header-frame basis (and I hope you really meant per-header-block), i= t seems like the decoder is just following the encoder=E2=80=99s lead on this.=C2=A0 Who=E2= =80=99s actually making that decision?=C2=A0 You say it gets turned off if = a drop results, but the encoder is the one who knows/determines that.

Yes, all = decisions are made by the encoder, and as in HPACK the decoder strictly fol= lows the encoder's lead. =C2=A0=C2=A0

=
The "informed" language was simply alluding to = the encoder side of the HPACK API being extended with QPACK related params.=

And yes, I meant "= header block".=C2=A0 Will fix that.

<= div dir=3D"ltr">

This has the same problem as the current HPACK= state that RST on a control stream loses critical data and there=E2=80=99s= no way to recover.=C2=A0 I=E2=80=99m personally hoping we can make our way= out of that requirement.

My position is that REFUSED should be the only kind o= f RST needed or allowed for control streams, and dealing with that is tract= ible.

=C2=A0

From: Charles 'Buck' Krasic [mailto:<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com]
Sent: Tuesday, March 21, 2017 6:04 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>; Martin Thom= son <marti= n.thomson@gmail.com>; IETF QUIC WG <quic@ietf.org>


Subject: Re: Core drafts -02 out

=C2=A0

Hi Folks.

=C2=A0

I've put together a first attempt at my QPACK pr= oposal:

=C2=A0

=C2=A0

Apologies in advance, this is my first attempt at an= IETF draft.

=C2=A0

=C2=A0

On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop <Michael.Bis= hop@microsoft.com> wrote:

Thanks for the feedback!

Yes, you've run straight into the big quandary with HPACK.=C2=A0 I don&= #39;t think anyone expects that we will ship this way; I have a proposal in https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack for a= n HPACK-replacement that would solve many of these.=C2=A0 Buck Krasic has a= proposal which he has sketched in e-mail but not submitted as a draft.=C2= =A0 The main point of the sequence number was to get us off the "everything on stream 3" model and let us sort ou= t the problems of HPACK later.=C2=A0 #228 tracks fixing HPACK, in whatever = form that takes.

We could solve it in the same way that we did PRIORITY, by adding an "= affected stream number" field and moving the HEADERS/PUSH_PROMISE fram= es to Stream 3 as well.=C2=A0 However, that is just as blocking as the curr= ent approach, so not really an improvement.=C2=A0 Worse, the reason we can tolerate large header frames is because they occur on th= eir own streams and don't block arrival of data from other streams.=C2= =A0 If all headers occur on a single stream, that's not true -- you *ar= e* blocking muxing of other streams again.

I like the comparison to concurrent edits.=C2=A0 We've discussed having= rolling deltas in various mechanisms; the problem is that it requires reac= hing into the transport for ACK state to figure out when you can discard ol= d deltas for good on the receiver side.=C2=A0 Buck's proposal is similar, essentially requiring the receiver to echo= back the point up to which it has received all frames, and the sender shou= ldn't reference state that the receiver hasn't fully assimilated ye= t.=C2=A0 It feels like adding application-level ACKs to me, which I'd like to avoid.

HPACK is also one of the reasons for the two-stream-per-request approach.= =C2=A0 There are two reasons for this -- one is that HPACK frames (in the c= urrent design) can't be lost when a stream is RST, so the draft forbids= resetting control streams.=C2=A0 Since we still need to be able to RST requests, we add the semantic that killing the data= stream implies the same thing about the control stream.=C2=A0 It's mes= sy, and hopefully we can remove that once HPACK is fixed.=C2=A0 The second,= as you guessed, is not dealing with DATA frames.=C2=A0 #245 notes that, if we fix HPACK, we could go back to a single stream per = request; proponents of both "keep framing out of the way" and &qu= ot;fewer streams is easier to manage" have weighed in there.=C2=A0 Ple= ase add your voice.

As to buffering, it's actually easy enough -- just don't read from = data streams until you've seen the headers.=C2=A0 Sure, the sender will= fill up their flow control window on that stream -- and then they'll s= top and send you QUIC BLOCKED frames, until you start reading the body and generating WINDOW_UPDATE frames.=C2=A0 One of the big= gest arguments for two streams in my mind is making sure that a request blo= cked in this way doesn't impede the flow of control frames on that stre= am -- for example, should we successfully get certificate auth frames added, a certificate request.=C2=A0 I've h= ad two customers this week telling me it's a bug in our server code tha= t their TLS reneg gets stuck in TCP buffers behind a giant request body, be= cause the server won't read an unauthenticated body and the client won't hold off sending the body until authenticati= on succeeds.=C2=A0 I'd like to see blocks like that become less possibl= e in QUIC, at least.

Yes, making SETTINGS immutable reduces the flexibility.=C2=A0 The opinion a= t the interim was that we could live without it, as we know of exactly one = implementation of one extension that does mid-stream setting changes, and I= own it.=C2=A0 =F0=9F=98= =8A=C2=A0 If there's a compelling use case for changing settings= mid-stream we weren't aware of, that's new information that could = justify the complexity.=C2=A0 (But note that with 0-RTT connection setup, i= t would be nearly as cheap to open a new connection with the new setting and= transition your traffic to it.)

Negotiation still works, since each side would simply advertise that they s= upport an extension or not, and consider the extension to be active once yo= u've seen the other side's SETTINGS frame.=C2=A0 See https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5= .3 for the complexity this allowed us to remove.=C2=A0 An extension cou= ld add to the list easily -- if you support extension X, you should also re= member the value for setting X_VAL.=C2=A0 Clients that don't use the extension don't care.=C2=A0 An extension that needed= some more complex negotiation would have to use an extension-specific fram= e, it's true, but we haven't so far seen an extension do that.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing
Sent: Wednesday, March 15, 2017 6:22 AM
To: Martin Thomson <martin.thomson@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Core drafts -02 out


> Am 14.03.2017 um 00:57 schrieb Martin Thomson <martin.thomson@gmail.com>:=
>
> The editors have submitted -02 versions of the base set of QUIC drafts= .
[...]
> https://tools.ietf.org/html/draft-ietf-quic-http-02
Thanks, Martin! I assume that was announced to get feedback from the lurker= s here. ;-)

I'll give this a try. All mistakes and misunderstandings are mine alone= .

-----------------------------------------------------------------= ------------------------

Very well written spec. Easy to understand for someone having read rfc 7540= a bit.

I have some comments to the proposed HTTP mapping approach. Where the wg ha= s already discussed and exhausted alternatives, please excuse my ignorance = and ignore my comments. I had not the time to follow all discussions ongoin= g on this topic. Feel free to cherry-pick what seems helpful.


> 4.=C2=A0 Stream Mapping and Usage

+1 to directly using quic stream ids instead of virtual h2 stream
+identifier


However, using 2 quic streams for a single request/response does not sit we= ll with me. I assume that stems from the wish to get rid of DATA frames. Wh= ich sounds nice, but is it worth it? By doubling the # of streams for a cli= ent, how much overhead does that introduce (I speak of a server holding >10k quic "connections"= ;)?

Also, the server needs to buffer data on quic streams 7, 11, 15, etc. becau= se HEADERs might arrive some time in the future on streams 5, 9, 13, etc. o= r not. There is no way to route this data somewhere, because the meta infor= mation is still missing.

And there is still Holb on:

> 4.2.1.=C2=A0 Header Compression
> ...
> DISCUSS:=C2=A0 Keep HPACK with HOLB?=C2=A0 Redesign HPACK to be order-=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0invariant?=C2=A0 How much do we need to reta= in compatibility with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/2's HPACK?

Using a counter in HEADERS is a crutch:
- it is a highly specific solution to a common problem in http/quic: synchr= onicity in connection level state changes. SETTINGS (see below) has the sam= e problem, as does have PRIORITY in HEADERS. It seems that performance wise= , all HEADERS could as well be sent on stream 3.

Now, solving Hol blocking for HEADERS would be a fine achievement.

> 5.=C2=A0 HTTP Framing Layer
> Frames are used only on the connection (stream 3) and message
>=C2=A0 =C2=A0 (streams 5, 9, etc.) control streams.

And streams 4, 8, 12, etc. I assume.

> 5.2.3.=C2=A0 SETTINGS
> ...
> SETTINGS frames always apply to a connection, never a single stream. >=C2=A0 A SETTINGS frame MUST be sent as the first frame of the connecti= on
> control stream (see Section 4) by each peer, and MUST NOT be sent
> subsequently or on any other stream.=C2=A0 If an endpoint receives an<= br> > SETTINGS frame on a different stream, the endpoint MUST respond with > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM.=C2=A0 I= f an
> endpoint receives a second SETTINGS frame, the endpoint MUST respond > with a connection error of type HTTP_MULTIPLE_SETTINGS.

What about HPACK state? The connection state change problem again visible.<= br>
This is a severe restriction on extensions mechanisms that want to affect a= connection. Because if the http/quic does not solve this problem, how are = they expected to do it? They either announce themselves on the first SETTIN= GS or remain silent forever, it seems. How would an extension handshake work then? Own stream 3 handshake = frames?

> 5.2.3.3.=C2=A0 Usage in 0-RTT

What about HPACK state? Does it need to be kept or is it reset?

> HTTP_PUSH_ALREADY_IN_CACHE (0x03):=C2=A0 The server has attempted to p= ush
>=C2=A0 =C2=A0 =C2=A0 content which the client has cached.
> ...
> HTTP_REQUEST_CANCELLED (0x04):=C2=A0 The client no longer needs the >=C2=A0 =C2=A0 =C2=A0requested data.

Nitpick: seems redundant. The first could be replaced by the second. Stream= number will suffice.

----------------------------------------------------------

Taking two steps back:

I think the main difficulty comes from the lack of a "hq connection st= ate" concept and how changes to that state can be managed. Evidence: - The 0-RTT mentions certain SETTINGS that need to be remembered by a clien= t. How would an extension add to this? Will every extension have to come up= with its own solution?
- The HEADERs sequence number is a highly specific fix for the missing stat= e change
- The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 m= echanism

If hq defines stream 3 as the place where connection state changes happen *= AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and server = can have shareable concept of the connection state.


I am no HPACK expert. The basic problem looks like concurrent editing again= st a repository.
Both client and server start with connection state zero (CS-0) and the pred= efined HPACK dictionary (HP-0). After SETTINGS exchange, client is in CS-1 = and server is in CS-2 for its side. Let's call the=C2=A0 CS-1 HPACK sta= te HP-1.

Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). Th= e HEADERS carries the connection state number it is based on (CS-1). Client= sends new HEADERS on stream 9, also based on CS-1. Client keeps that delta= around (HP-1.9).

Client then decides to announce a new connection state (CS-3) by sending ho= w it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The descrip= tion allows the server to update its HP-1 to HP-3 as well.

Response HEADERS are also based on a server connection state, explicitly, s= o the client knows which HP-X to use when decoding them. At some time, the = server sends an announcment of CS-4 with HPACK data on stream 3 back to the= client.

For a 0-RTT, client and server could exchange the connection state id in th= e initial SETTINGS, to make sure they have at least the same name remembere= d as the other side. Client: "I was in CS-19 and you were in CS-8.&quo= t; Server: "Yep."

By implicitly adding all SETTINGS changes to connection states, the problem= is also solved for extensions.

If one side receives HEADERS with an unknown connection state:
- if the state id is greater than any known one: set a stream timeout and w= ait for changes on stream 3 to arrive
- state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE
New SETTINGS value: MAX_CONN_STATE number of maximum connection state the c= lient/server is willing to keep, exchanged initially. Announcing a new conn= ection state allows the other side to drop the lowest one, if MAX_CONN_STAT= E are used.

To get optimal HPACK size compression, every HEADERs would also announce a = new connections state. To have less potential HOLB, connection states do no= t change during request bursts.

Something like that.

-Stefan



=C2=A0

--

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




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

--001a113f8a74794560054b6a7491-- From nobody Thu Mar 23 16:13:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446771294FF for ; Thu, 23 Mar 2017 16:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 946L2tGehwUA for ; Thu, 23 Mar 2017 16:12:58 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0103.outbound.protection.outlook.com [104.47.40.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A22C1292D3 for ; Thu, 23 Mar 2017 16:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D7J7wmlawURjCBxXVcYuM/nFiK+z8+ay1d9g4hA0hxI=; b=OKGCcQxZAqIW9cBXxHJ95Dwyj2vSWw80k/dXW1qxJUzj+45EJhtkGZaqj5zZoUKFI29MmUArquQkP4Pv8nUw0czSnWlIih35+CFTSjbvDq+5oa8F1EKf6hXqFRDqYA16QHQcK958DZIYqYc3YfzbyWDkI+ldenvOBS9ujdjxRN4= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.11; Thu, 23 Mar 2017 23:12:53 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0991.017; Thu, 23 Mar 2017 23:12:53 +0000 From: Mike Bishop To: Charles 'Buck' Krasic CC: Stefan Eissing , Martin Thomson , IETF QUIC WG Subject: RE: Core drafts -02 out Thread-Topic: Core drafts -02 out Thread-Index: AQHSnFW3hRyMfx+c6Ueu2fks77hV8qGV5bGAgAA4O1CACceVgIAC0r5ggAAd2ICAAEc8ow== Date: Thu, 23 Mar 2017 23:12:52 +0000 Message-ID: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [76.181.219.18] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:1f/M/CBVZwqxkDsK9fvpmycxIh+ImP8sOFZOapySeq6JYFbJySR7gQhrXjKBspD5HDLqzPgAyWddpgyxkHy3K9nFpNvxyjfYhJ/ZIxsQjoEOxrRO36qCDlHr1ZnW8jGtMQljr7HbzJV+FRLAYbLizSLaGrD8tfQeX6ruYfixQ3+pdT+rlqe6cn6mh+PhO2nxvOxDLLtm2LqU57JV3YnbK7s3eY4m/hhGUxh39LSDcN8RKg5kyYWmcFDGlFVg9cVMKkAEz3aW0igU4YrGI+iB3GT5Iqljyvz4VSlHz3vriQ+Mq25E5A18u0pOuA1Sqz3SXOYzyFiYDm4qP559DMyzXQM5WteIqWFRVC9HqYf6aAg= x-ms-office365-filtering-correlation-id: 47e44fb5-87c0-4da4-1982-08d472422214 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39410400002)(39450400003)(39860400002)(39840400002)(377454003)(57704003)(24454002)(51914003)(13464003)(76176999)(99286003)(53936002)(6116002)(53946003)(54896002)(4326008)(54906002)(9686003)(2906002)(77096006)(8936002)(7696004)(606005)(7116003)(229853002)(236005)(966004)(50986999)(74316002)(55016002)(66066001)(6436002)(10290500002)(122556002)(6506006)(93886004)(7736002)(10090500001)(25786009)(8676002)(5660300001)(2950100002)(6916009)(81166006)(6306002)(7906003)(189998001)(6246003)(5005710100001)(110136004)(39060400002)(3660700001)(53386004)(53546009)(3280700002)(2900100001)(97736004)(8990500004)(54356999)(86612001)(561944003)(86362001)(33656002)(38730400002)(102836003)(3846002)(376185003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27084E9ADE721FFF85980DEF873F0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 23:12:52.8230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 23:13:03 -0000 --_000_BN6PR03MB27084E9ADE721FFF85980DEF873F0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aCByZWdhcmQgdG8gaGVhZGVyIGJsb2NrIHZlcnN1cyBmcmFtZSwgdGhvdWdoLCB5b3UgZXhw bGljaXRseSBzYWlkIGluIHlvdXIgcmVwbHkgYmVmb3JlIHRoYXQgdGhlIGVuY29kZXIgY2FuIHN3 aXRjaCBtb2RlcyBiZXR3ZWVuIGZyYW1lcyBpbiBhIHNpbmdsZSBibG9jay4gIFNvIEkgdGhpbmsg eW91IG1lYW4gd2hhdCB5b3Ugd3JvdGU7IGl04oCZcyBqdXN0IHRoYXQgc3dpdGNoaW5nIHdoZXRo ZXIgdGhpbmdzIGNhbiBiZSBpbnRlcnByZXRlZCBvdXQgb2Ygb3JkZXIgbWlkLWJsb2NrIGZlZWxz IHdlaXJkLg0KDQpBbmQgUE9TSVggb3Igbm90LCBJIGRvbid0IHRoaW5rIHlvdSBjYW4gdW5pbGF0 ZXJhbGx5IGRlZmluZSBhIHNlbWFudGljIGFib3V0IGRlbGl2ZXJ5IHRvIHRoZSByZW1vdGUgYXBw IGxheWVyLiAgVGhvdWdoIHlvdSBjb3VsZCBjb21lIGNsb3NlIOKAkyBpZiB0aGUgY2FsbCBjb21w bGV0ZWQgd2hlbiB0aGUgd3JpdHRlbiBkYXRhIGFuZCBhbGwgcHJlY2VkaW5nIGRhdGEgb24gdGhl IHN0cmVhbSBoYWQgYmVlbiBBQ0vigJlkLCB5b3Uga25vdyBhdCBsZWFzdCB0aGF0IHRoZSBkYXRh IGlzIGF2YWlsYWJsZSB0byB0aGUgcmVtb3RlIGFwcCBsYXllciDigJMgd2hldGhlciBpdCByZWFk cyBwcm9tcHRseSBpcyBpdHMgb3duIHByb2JsZW0uDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIDEw IHBob25lDQoNCkZyb206IENoYXJsZXMgJ0J1Y2snIEtyYXNpYzxtYWlsdG86Y2tyYXNpY0Bnb29n bGUuY29tPg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDIzLCAyMDE3IDI6NTggUE0NClRvOiBNaWtl IEJpc2hvcDxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4NCkNjOiBTdGVmYW4g RWlzc2luZzxtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT47IE1hcnRpbiBUaG9t c29uPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0c8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQ29yZSBkcmFmdHMgLTAyIG91dA0KDQoNCg0K T24gVGh1LCBNYXIgMjMsIDIwMTcgYXQgMTA6NTIgQU0sIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJp c2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpBbGwgSSBzZWUgaW4gdGhlIGxpbmtzIGFyZSBodHRwOi8vIGFuZCB0aGUgZHJhZnQg bmFtZSwgbm8gaG9zdC4gIEnigJltIGd1ZXNzaW5nIHlvdSBtZWFudCBodHRwczovL2dpdGh1Yi5j b20va3Jhc2ljL2RyYWZ0LWtyYXNpYy1xdWljLWhwYWNrL2Jsb2IvbWFzdGVyL2RyYWZ0LWtyYXNp Yy1xdWljLWhwYWNrLTAwLmh0bWw/ICBPbmNlIHRoZSB0cmFja2VyIHJlb3BlbnMgKHNvbWV0aW1l IFN1bmRheSwgSSB0aGluaykgeW91IHNob3VsZCBwcm9iYWJseSB1cGxvYWQgdGhvc2UgYXQgZGF0 YXRyYWNrZXIuaWV0Zi5vcmc8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnPiB0byBtYWtlIGl0 IGFuIG9mZmljaWFsIHN1Ym1pc3Npb24uICBZb3XigJlsbCBuZWVkIHRvIG1ha2UgdGhlIGRyYWZ0 IG5hbWUgaW4gdGhlIGZpbGUgbWF0Y2ggdGhlIGZpbGUgbmFtZSBiZWZvcmUgaXQgd2lsbCBzdWNj ZXNzZnVsbHkgdXBsb2FkLg0KDQpUaGFua3MgZm9yIHRoZSBwcm9tcHQgZmVlZGJhY2shDQoNCkFw b2xvZ2llcywgYXMgSSBtZW50aW9uZWQgaXQgaXMgbXkgZmlyc3QgYXR0ZW1wdCBhdCBhbiBJRVRG IGRyYWZ0LCBhbmQgaXQgbXkgZmlyc3QgdGltZSB1c2luZyB0aGUgdG9vbHMgYXMgZGVzY3JpYmVk IGluIFNFVFVQLm1kPGh0dHBzOi8vZ2l0aHViLmNvbS9tYXJ0aW50aG9tc29uL2ktZC10ZW1wbGF0 ZS9ibG9iL21hc3Rlci9kb2MvU0VUVVAubWQ+Lg0KDQpVbnRpbCBJIHRoZSB0cmFja2VyIHJlb3Bl bnMgYW5kIEkgc3VibWl0IHByb3Blcmx5LCBJIHdvdWxkIHN1Z2dlc3QgaHR0cHM6Ly9rcmFzaWMu Z2l0aHViLmlvL2RyYWZ0LWtyYXNpYy1xdWljLWhwYWNrL2RyYWZ0LWtyYXNpYy1xdWljLXFwYWNr LWxhdGVzdC5odG1sDQoNCkFsc28sIGZvciBlYXNlIG9mIGRpc2N1c3Npb24sIHlvdSBtaWdodCBw aWNrIGEgZGlmZmVyZW50IG5hbWUgdGhhbiBRUEFDSywgc2luY2UgdGhlcmXigJlzIGFscmVhZHkg YSBkcmFmdCB3aXRoIHRoYXQgbmFtZS4gIChPciB3ZSBib3RoIGNoYW5nZSBuYW1lcywgYW5kIGNh bGwgdGhlIGV2ZW50dWFsbHktYWRvcHRlZCBvbmUgUVBBQ0s7IHRoYXTigJlkIGJlIGZpbmUsIHRv by4pDQoNCkknbSBmaW5lIHdpdGggd2hhdGV2ZXIuICBJZiAgZHJhZnQta3Jhc2ljIHZzIGRyYWZ0 LWJpc2hvcCBpc24ndCBlbm91Z2ggdG8gZGlmZmVyZW50aWF0ZSwgIGhvdyBhYm91dCBRUEFDSy1B TFQsIG9yIG1heWJlIFFQQUNLLUxJVEU/DQoNCkFzIHRvIGFjdHVhbCBmZWVkYmFjazogIEkgc2Vl IHdoYXQgeW914oCZcmUgZ2V0dGluZyBhdCBoZXJlIGJlY2F1c2UgeW914oCZdmUgZXhwbGFpbmVk IGl0IOKAkyB0aGUgZGVjb2RlciBhY2tub3dsZWRnZXMgdGhlIHNlcXVlbmNlIG51bWJlciBpdOKA mXMgdXAgdG8sIHRoZW4gdGhlIGVuY29kZXIgdHJhY2tzIHRoYXQgYW5kIHVzZXMgaXQgb24gdGhl IGVuY29kZSBzaWRlLiAgSSB0aGluayBJ4oCZZCBoYXZlIGEgcmVhbGx5IGhhcmQgdGltZSBwYXJz aW5nIHRoZSBkb2N1bWVudCB3aXRob3V0IHRoYXQuICBJIHRoaW5rIHRoZSBzdHJvbmdlc3QgYWR2 YW50YWdlIG9mIHRoaXMgcHJvcG9zYWwgaXMgdGhhdCBhbiBlbmNvZGVyIGZvciB0aGlzIHNjaGVt ZSBjb3VsZCBiZSB1c2VkIG92ZXIgSFRUUC8yLCBlbmFibGluZyBzaGFyZWQgY29kZTsgeW91IHNo b3VsZCBicmluZyB0aGF0IG91dCBtb3JlLg0KDQpJJ2xsIHRyeSB0byByZXdvcmsgdGhlIHRleHQg dG8gZW1waGlzZSB0aG9zZSBwb2ludHMgbW9yZSBhbmQgY2xhcmlmeS4NCg0KTml0czogIHRoZSBk ZWNvZGVyIHBlci1zZSBkb2Vzbid0IGFjaywgYnV0IHRoZSBlbmNvZGVyIHRyYWNrcyB1c2luZyBl eGlzdGluZyB0cmFuc3BvcnQgbGV2ZWwgYWNrIG1lY2hhbmlzbXMgKG1vcmUgb24gdGhpcyBiZWxv dykuICAgQWxzbywgSSB0aGluayBvZiB0aGlzIHNjaGVtZSBhcyBzb21ldGhpbmcgYSBzaGFyZWQg aW1wbGVtZW50YXRpb24gY291bGQgb2ZmZXIgYXMgYW4gb3B0aW9uLCBidXQgSSBoYWRuJ3QgaW1h Z2luZWQgdGhlIG9wdGlvbiB3b3VsZCBiZSBldmVyIGJlIGVuYWJsZWQgaW4gSFRUUC8yLiAgSXQg bWlnaHQgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lkZXIgdGhvdWdoLg0KDQpUaGUgd2F5IHlvdeKA mXZlIGRlc2NyaWJlZCB0aGUgZW5jb2RlciByZXF1aXJlcyB0aWdodCBpbnRlZ3JhdGlvbiBiZXR3 ZWVuIHRoZSBwYWNrZXRpemF0aW9uIGxvZ2ljIGFuZCB0aGUgaGVhZGVyIGNvbXByZXNzb3IgaW4g dHdvIHdheXM6DQoNCiAgKiAgIEl0IG5lZWRzIHRvIGtub3cgdGhlIOKAnHBhY2tldCBlcG9jaOKA nSAoZW5jb2RlIGVwb2NoIG9mIHRoZSBmaXJzdCBmcmFtZSBpbiB0aGUgY3VycmVudCBwYWNrZXQp IHdoaWxlIGNvbXByZXNzaW5nLCBidXQgdW50aWwgeW91IGtub3cgdGhlIHNpemUgb2YgdGhlIGNv bXByZXNzZWQgb3V0cHV0LCB5b3UgY2Fu4oCZdCBrbm93IHdoZXRoZXIgaXQgd2lsbCBmaXQgaW4g dGhlIGN1cnJlbnQgcGFja2V0LiAgVGhhdCBpbiB0dXJuIG1lYW5zIHlvdeKAmWxsIG5lZWQgdG8g cm9sbCBiYWNrIGFueSBzdGF0ZSBhbmQgcmUtZW5jb2RlIHdpdGggYSBkaWZmZXJlbnQgcGFja2V0 IGVwb2NoIGlmIGl0IHR1cm5zIG91dCBub3QgdG8gZml0Lg0KDQpJIGRvbid0IHRoaW5rIHJvbGwg YmFjayBpcyBlc3NzZW50aWFsLg0KDQpUaGUgc3BhY2UgYXZhaWxhYmxlIGluIHRoZSBjdXJyZW50 IHBhY2tldCBjb3VsZCBiZSBrbm93biB3aGVuIGludm9raW5nIHRoZSBocGFjayBlbmNvZGVyLCBz byBpdCB3b3VsZCBzdG9wIGVtaXR0aW5nIHJlcHJlc2VudGF0aW9ucyBpZiB0aGUgcGFja2V0IHJl YWNoZXMgdGhlIHNwYWNlIGxpbWl0LCBhbmQgaW4gdGhhdCBjYXNlIHJldHVybiBhIGhlYWRlciBi bG9jayB0aGF0IGZvciBhIHByZWZpeCBvZiB0aGUgcHJvdmlkZWQgaGVhZGVyIGZpZWxkIGxpc3Qs IGFuZCBpbiBsYXRlciBwYWNrZXRzIGl0IHdvdWxkIGdlbmVyYXRlIGEgY29udGludWF0aW9uIGhl YWRlciBibG9jayhzKSBmb3IgcmVtYWluaW5nIGhlYWRlciBmaWVsZHMuDQoNCg0KICAqDQogICog ICBUaGUg4oCcY29tbWl0IGVwb2No4oCdIGlzIGRldGVybWluZWQsIG5vdCBieSBkYXRhIGF0IHRo ZSBjb21wcmVzc29yIGxldmVsLCBidXQgYnkgcmVhY2hpbmcgaW50byB0aGUgdHJhbnNwb3J0IGFu ZCBjaGVja2luZyB3aGljaCBwYWNrZXRzIGNvbnRhaW5pbmcgdGhlIFNUUkVBTSBmcmFtZXMgY29u dGFpbmluZyB0aGUgSFBBQ0sgZGF0YSBpbiBxdWVzdGlvbiBoYXZlIGJlZW4gYWNrbm93bGVkZ2Vk LiAgQWxzbyBub3RlIHRoYXQgQUNLIGRvZXNu4oCZdCBzaWduaWZ5IGRlbGl2ZXJ5IHRvIHRoZSBh cHBsaWNhdGlvbiBsYXllciAoSFRUUCksIGp1c3QgcHJlc2VuY2UgaW4gdGhlIGFwcHJvcHJpYXRl IHF1ZXVlLg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgQVBJcyBhcmUgb3V0IG9mIHNjb3Bl IG9mIG1vc3Qgb2YgdGhlIGRvY3MuICAgSG93ZXZlciwgaW4gb3VyIGltcGxlbWVudGF0aW9uLCB0 aGUgc3RyZWFtIHdyaXRlIGludGVyZmFjZXMgdW5pZm9ybWx5IHByb3ZpZGUgYSBtZWFucyBvZiB0 byBjb25maXJtIGFja25vd2xlZGdlbWVudCwgIHNvIGl0IGlzIHBvc3NpYmxlIHRvIGRvIGl0IHdp dGhvdXQgcmVhY2hpbmcgZG93bi4NCg0KSSBhZ3JlZSB0aGF0IEFDSyBkb2Vzbid0IHNpZ25pZnkg ZGVsaXZlcnkgdG8gd2hhdCBpcyBhYm92ZSBIVFRQLCBidXQgb25lIG9mIGFkdmFudGFnZXMgb2Yg bm90IGhhdmluZyBsZWdhY3kgQVBJcyAoUE9TSVggc29ja2V0cykgYmV0d2VlbiBRVUlDIGFuZCBI VFRQIGlzIHRoYXQgdGhlIGltcGxlbWVuYXRpb24gY2FuIGNlcnRhaW5seSBlbnN1cmUgdGhhdCBB Q0sgc2lnbmlmaWVzIGRlbGl2ZXJ5IHRvIEhUVFAuDQpJbiAyLjIuMS4xLCB0aGUgZW5jb2RlciBp cyBpbmZvcm1lZCB3aGV0aGVyIOKAnFFQQUNLIGlzIGVuYWJsZWQs4oCdIGJ1dCBzaW5jZSB0aGF0 IGNhbiBiZSB0b2dnbGVkIG9uL29mZiBvbiBhIHBlci1oZWFkZXItZnJhbWUgYmFzaXMgKGFuZCBJ IGhvcGUgeW91IHJlYWxseSBtZWFudCBwZXItaGVhZGVyLWJsb2NrKSwgaXQgc2VlbXMgbGlrZSB0 aGUgZGVjb2RlciBpcyBqdXN0IGZvbGxvd2luZyB0aGUgZW5jb2RlcuKAmXMgbGVhZCBvbiB0aGlz LiAgV2hv4oCZcyBhY3R1YWxseSBtYWtpbmcgdGhhdCBkZWNpc2lvbj8gIFlvdSBzYXkgaXQgZ2V0 cyB0dXJuZWQgb2ZmIGlmIGEgZHJvcCByZXN1bHRzLCBidXQgdGhlIGVuY29kZXIgaXMgdGhlIG9u ZSB3aG8ga25vd3MvZGV0ZXJtaW5lcyB0aGF0Lg0KWWVzLCBhbGwgZGVjaXNpb25zIGFyZSBtYWRl IGJ5IHRoZSBlbmNvZGVyLCBhbmQgYXMgaW4gSFBBQ0sgdGhlIGRlY29kZXIgc3RyaWN0bHkgZm9s bG93cyB0aGUgZW5jb2RlcidzIGxlYWQuDQoNClRoZSAiaW5mb3JtZWQiIGxhbmd1YWdlIHdhcyBz aW1wbHkgYWxsdWRpbmcgdG8gdGhlIGVuY29kZXIgc2lkZSBvZiB0aGUgSFBBQ0sgQVBJIGJlaW5n IGV4dGVuZGVkIHdpdGggUVBBQ0sgcmVsYXRlZCBwYXJhbXMuDQoNCkFuZCB5ZXMsIEkgbWVhbnQg ImhlYWRlciBibG9jayIuICBXaWxsIGZpeCB0aGF0Lg0KDQpUaGlzIGhhcyB0aGUgc2FtZSBwcm9i bGVtIGFzIHRoZSBjdXJyZW50IEhQQUNLIHN0YXRlIHRoYXQgUlNUIG9uIGEgY29udHJvbCBzdHJl YW0gbG9zZXMgY3JpdGljYWwgZGF0YSBhbmQgdGhlcmXigJlzIG5vIHdheSB0byByZWNvdmVyLiAg SeKAmW0gcGVyc29uYWxseSBob3Bpbmcgd2UgY2FuIG1ha2Ugb3VyIHdheSBvdXQgb2YgdGhhdCBy ZXF1aXJlbWVudC4NCk15IHBvc2l0aW9uIGlzIHRoYXQgUkVGVVNFRCBzaG91bGQgYmUgdGhlIG9u bHkga2luZCBvZiBSU1QgbmVlZGVkIG9yIGFsbG93ZWQgZm9yIGNvbnRyb2wgc3RyZWFtcywgYW5k IGRlYWxpbmcgd2l0aCB0aGF0IGlzIHRyYWN0aWJsZS4NCg0KDQpGcm9tOiBDaGFybGVzICdCdWNr JyBLcmFzaWMgW21haWx0bzpja3Jhc2ljQGdvb2dsZS5jb208bWFpbHRvOmNrcmFzaWNAZ29vZ2xl LmNvbT5dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMSwgMjAxNyA2OjA0IFBNDQpUbzogTWlrZSBC aXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFN0ZWZhbiBFaXNzaW5nIDxzdGVmYW4uZWlzc2luZ0BncmVl bmJ5dGVzLmRlPG1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlPj47IE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5v cmc+Pg0KDQpTdWJqZWN0OiBSZTogQ29yZSBkcmFmdHMgLTAyIG91dA0KDQpIaSBGb2xrcy4NCg0K SSd2ZSBwdXQgdG9nZXRoZXIgYSBmaXJzdCBhdHRlbXB0IGF0IG15IFFQQUNLIHByb3Bvc2FsOg0K DQpkcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sPGh0dHA6Ly9kcmFmdC1rcmFzaWMtcXVp Yy1ocGFjay0wMC5odG1sPg0KZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAudHh0PGh0dHBzOi8v a3Jhc2ljLmdpdGh1Yi5pby9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay9kcmFmdC1rcmFzaWMtcXVp Yy1ocGFjay0wMC50eHQ+DQoNCkFwb2xvZ2llcyBpbiBhZHZhbmNlLCB0aGlzIGlzIG15IGZpcnN0 IGF0dGVtcHQgYXQgYW4gSUVURiBkcmFmdC4NCg0KDQpPbiBXZWQsIE1hciAxNSwgMjAxNyBhdCAx MDozNyBBTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgdGhlIGZl ZWRiYWNrIQ0KDQpZZXMsIHlvdSd2ZSBydW4gc3RyYWlnaHQgaW50byB0aGUgYmlnIHF1YW5kYXJ5 IHdpdGggSFBBQ0suICBJIGRvbid0IHRoaW5rIGFueW9uZSBleHBlY3RzIHRoYXQgd2Ugd2lsbCBz aGlwIHRoaXMgd2F5OyBJIGhhdmUgYSBwcm9wb3NhbCBpbiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2sgZm9yIGFuIEhQQUNLLXJlcGxh Y2VtZW50IHRoYXQgd291bGQgc29sdmUgbWFueSBvZiB0aGVzZS4gIEJ1Y2sgS3Jhc2ljIGhhcyBh IHByb3Bvc2FsIHdoaWNoIGhlIGhhcyBza2V0Y2hlZCBpbiBlLW1haWwgYnV0IG5vdCBzdWJtaXR0 ZWQgYXMgYSBkcmFmdC4gIFRoZSBtYWluIHBvaW50IG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIgd2Fz IHRvIGdldCB1cyBvZmYgdGhlICJldmVyeXRoaW5nIG9uIHN0cmVhbSAzIiBtb2RlbCBhbmQgbGV0 IHVzIHNvcnQgb3V0IHRoZSBwcm9ibGVtcyBvZiBIUEFDSyBsYXRlci4gICMyMjggdHJhY2tzIGZp eGluZyBIUEFDSywgaW4gd2hhdGV2ZXIgZm9ybSB0aGF0IHRha2VzLg0KDQpXZSBjb3VsZCBzb2x2 ZSBpdCBpbiB0aGUgc2FtZSB3YXkgdGhhdCB3ZSBkaWQgUFJJT1JJVFksIGJ5IGFkZGluZyBhbiAi YWZmZWN0ZWQgc3RyZWFtIG51bWJlciIgZmllbGQgYW5kIG1vdmluZyB0aGUgSEVBREVSUy9QVVNI X1BST01JU0UgZnJhbWVzIHRvIFN0cmVhbSAzIGFzIHdlbGwuICBIb3dldmVyLCB0aGF0IGlzIGp1 c3QgYXMgYmxvY2tpbmcgYXMgdGhlIGN1cnJlbnQgYXBwcm9hY2gsIHNvIG5vdCByZWFsbHkgYW4g aW1wcm92ZW1lbnQuICBXb3JzZSwgdGhlIHJlYXNvbiB3ZSBjYW4gdG9sZXJhdGUgbGFyZ2UgaGVh ZGVyIGZyYW1lcyBpcyBiZWNhdXNlIHRoZXkgb2NjdXIgb24gdGhlaXIgb3duIHN0cmVhbXMgYW5k IGRvbid0IGJsb2NrIGFycml2YWwgb2YgZGF0YSBmcm9tIG90aGVyIHN0cmVhbXMuICBJZiBhbGwg aGVhZGVycyBvY2N1ciBvbiBhIHNpbmdsZSBzdHJlYW0sIHRoYXQncyBub3QgdHJ1ZSAtLSB5b3Ug KmFyZSogYmxvY2tpbmcgbXV4aW5nIG9mIG90aGVyIHN0cmVhbXMgYWdhaW4uDQoNCkkgbGlrZSB0 aGUgY29tcGFyaXNvbiB0byBjb25jdXJyZW50IGVkaXRzLiAgV2UndmUgZGlzY3Vzc2VkIGhhdmlu ZyByb2xsaW5nIGRlbHRhcyBpbiB2YXJpb3VzIG1lY2hhbmlzbXM7IHRoZSBwcm9ibGVtIGlzIHRo YXQgaXQgcmVxdWlyZXMgcmVhY2hpbmcgaW50byB0aGUgdHJhbnNwb3J0IGZvciBBQ0sgc3RhdGUg dG8gZmlndXJlIG91dCB3aGVuIHlvdSBjYW4gZGlzY2FyZCBvbGQgZGVsdGFzIGZvciBnb29kIG9u IHRoZSByZWNlaXZlciBzaWRlLiAgQnVjaydzIHByb3Bvc2FsIGlzIHNpbWlsYXIsIGVzc2VudGlh bGx5IHJlcXVpcmluZyB0aGUgcmVjZWl2ZXIgdG8gZWNobyBiYWNrIHRoZSBwb2ludCB1cCB0byB3 aGljaCBpdCBoYXMgcmVjZWl2ZWQgYWxsIGZyYW1lcywgYW5kIHRoZSBzZW5kZXIgc2hvdWxkbid0 IHJlZmVyZW5jZSBzdGF0ZSB0aGF0IHRoZSByZWNlaXZlciBoYXNuJ3QgZnVsbHkgYXNzaW1pbGF0 ZWQgeWV0LiAgSXQgZmVlbHMgbGlrZSBhZGRpbmcgYXBwbGljYXRpb24tbGV2ZWwgQUNLcyB0byBt ZSwgd2hpY2ggSSdkIGxpa2UgdG8gYXZvaWQuDQoNCkhQQUNLIGlzIGFsc28gb25lIG9mIHRoZSBy ZWFzb25zIGZvciB0aGUgdHdvLXN0cmVhbS1wZXItcmVxdWVzdCBhcHByb2FjaC4gIFRoZXJlIGFy ZSB0d28gcmVhc29ucyBmb3IgdGhpcyAtLSBvbmUgaXMgdGhhdCBIUEFDSyBmcmFtZXMgKGluIHRo ZSBjdXJyZW50IGRlc2lnbikgY2FuJ3QgYmUgbG9zdCB3aGVuIGEgc3RyZWFtIGlzIFJTVCwgc28g dGhlIGRyYWZ0IGZvcmJpZHMgcmVzZXR0aW5nIGNvbnRyb2wgc3RyZWFtcy4gIFNpbmNlIHdlIHN0 aWxsIG5lZWQgdG8gYmUgYWJsZSB0byBSU1QgcmVxdWVzdHMsIHdlIGFkZCB0aGUgc2VtYW50aWMg dGhhdCBraWxsaW5nIHRoZSBkYXRhIHN0cmVhbSBpbXBsaWVzIHRoZSBzYW1lIHRoaW5nIGFib3V0 IHRoZSBjb250cm9sIHN0cmVhbS4gIEl0J3MgbWVzc3ksIGFuZCBob3BlZnVsbHkgd2UgY2FuIHJl bW92ZSB0aGF0IG9uY2UgSFBBQ0sgaXMgZml4ZWQuICBUaGUgc2Vjb25kLCBhcyB5b3UgZ3Vlc3Nl ZCwgaXMgbm90IGRlYWxpbmcgd2l0aCBEQVRBIGZyYW1lcy4gICMyNDUgbm90ZXMgdGhhdCwgaWYg d2UgZml4IEhQQUNLLCB3ZSBjb3VsZCBnbyBiYWNrIHRvIGEgc2luZ2xlIHN0cmVhbSBwZXIgcmVx dWVzdDsgcHJvcG9uZW50cyBvZiBib3RoICJrZWVwIGZyYW1pbmcgb3V0IG9mIHRoZSB3YXkiIGFu ZCAiZmV3ZXIgc3RyZWFtcyBpcyBlYXNpZXIgdG8gbWFuYWdlIiBoYXZlIHdlaWdoZWQgaW4gdGhl cmUuICBQbGVhc2UgYWRkIHlvdXIgdm9pY2UuDQoNCkFzIHRvIGJ1ZmZlcmluZywgaXQncyBhY3R1 YWxseSBlYXN5IGVub3VnaCAtLSBqdXN0IGRvbid0IHJlYWQgZnJvbSBkYXRhIHN0cmVhbXMgdW50 aWwgeW91J3ZlIHNlZW4gdGhlIGhlYWRlcnMuICBTdXJlLCB0aGUgc2VuZGVyIHdpbGwgZmlsbCB1 cCB0aGVpciBmbG93IGNvbnRyb2wgd2luZG93IG9uIHRoYXQgc3RyZWFtIC0tIGFuZCB0aGVuIHRo ZXknbGwgc3RvcCBhbmQgc2VuZCB5b3UgUVVJQyBCTE9DS0VEIGZyYW1lcywgdW50aWwgeW91IHN0 YXJ0IHJlYWRpbmcgdGhlIGJvZHkgYW5kIGdlbmVyYXRpbmcgV0lORE9XX1VQREFURSBmcmFtZXMu ICBPbmUgb2YgdGhlIGJpZ2dlc3QgYXJndW1lbnRzIGZvciB0d28gc3RyZWFtcyBpbiBteSBtaW5k IGlzIG1ha2luZyBzdXJlIHRoYXQgYSByZXF1ZXN0IGJsb2NrZWQgaW4gdGhpcyB3YXkgZG9lc24n dCBpbXBlZGUgdGhlIGZsb3cgb2YgY29udHJvbCBmcmFtZXMgb24gdGhhdCBzdHJlYW0gLS0gZm9y IGV4YW1wbGUsIHNob3VsZCB3ZSBzdWNjZXNzZnVsbHkgZ2V0IGNlcnRpZmljYXRlIGF1dGggZnJh bWVzIGFkZGVkLCBhIGNlcnRpZmljYXRlIHJlcXVlc3QuICBJJ3ZlIGhhZCB0d28gY3VzdG9tZXJz IHRoaXMgd2VlayB0ZWxsaW5nIG1lIGl0J3MgYSBidWcgaW4gb3VyIHNlcnZlciBjb2RlIHRoYXQg dGhlaXIgVExTIHJlbmVnIGdldHMgc3R1Y2sgaW4gVENQIGJ1ZmZlcnMgYmVoaW5kIGEgZ2lhbnQg cmVxdWVzdCBib2R5LCBiZWNhdXNlIHRoZSBzZXJ2ZXIgd29uJ3QgcmVhZCBhbiB1bmF1dGhlbnRp Y2F0ZWQgYm9keSBhbmQgdGhlIGNsaWVudCB3b24ndCBob2xkIG9mZiBzZW5kaW5nIHRoZSBib2R5 IHVudGlsIGF1dGhlbnRpY2F0aW9uIHN1Y2NlZWRzLiAgSSdkIGxpa2UgdG8gc2VlIGJsb2NrcyBs aWtlIHRoYXQgYmVjb21lIGxlc3MgcG9zc2libGUgaW4gUVVJQywgYXQgbGVhc3QuDQoNClllcywg bWFraW5nIFNFVFRJTkdTIGltbXV0YWJsZSByZWR1Y2VzIHRoZSBmbGV4aWJpbGl0eS4gIFRoZSBv cGluaW9uIGF0IHRoZSBpbnRlcmltIHdhcyB0aGF0IHdlIGNvdWxkIGxpdmUgd2l0aG91dCBpdCwg YXMgd2Uga25vdyBvZiBleGFjdGx5IG9uZSBpbXBsZW1lbnRhdGlvbiBvZiBvbmUgZXh0ZW5zaW9u IHRoYXQgZG9lcyBtaWQtc3RyZWFtIHNldHRpbmcgY2hhbmdlcywgYW5kIEkgb3duIGl0LiAg8J+Y iiAgSWYgdGhlcmUncyBhIGNvbXBlbGxpbmcgdXNlIGNhc2UgZm9yIGNoYW5naW5nIHNldHRpbmdz IG1pZC1zdHJlYW0gd2Ugd2VyZW4ndCBhd2FyZSBvZiwgdGhhdCdzIG5ldyBpbmZvcm1hdGlvbiB0 aGF0IGNvdWxkIGp1c3RpZnkgdGhlIGNvbXBsZXhpdHkuICAoQnV0IG5vdGUgdGhhdCB3aXRoIDAt UlRUIGNvbm5lY3Rpb24gc2V0dXAsIGl0IHdvdWxkIGJlIG5lYXJseSBhcyBjaGVhcCB0byBvcGVu IGEgbmV3IGNvbm5lY3Rpb24gd2l0aCB0aGUgbmV3IHNldHRpbmcgYW5kIHRyYW5zaXRpb24geW91 ciB0cmFmZmljIHRvIGl0LikNCg0KTmVnb3RpYXRpb24gc3RpbGwgd29ya3MsIHNpbmNlIGVhY2gg c2lkZSB3b3VsZCBzaW1wbHkgYWR2ZXJ0aXNlIHRoYXQgdGhleSBzdXBwb3J0IGFuIGV4dGVuc2lv biBvciBub3QsIGFuZCBjb25zaWRlciB0aGUgZXh0ZW5zaW9uIHRvIGJlIGFjdGl2ZSBvbmNlIHlv dSd2ZSBzZWVuIHRoZSBvdGhlciBzaWRlJ3MgU0VUVElOR1MgZnJhbWUuICBTZWUgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcXVpYy1odHRwLTAxI3NlY3Rpb24tNS4yLjUu MyBmb3IgdGhlIGNvbXBsZXhpdHkgdGhpcyBhbGxvd2VkIHVzIHRvIHJlbW92ZS4gIEFuIGV4dGVu c2lvbiBjb3VsZCBhZGQgdG8gdGhlIGxpc3QgZWFzaWx5IC0tIGlmIHlvdSBzdXBwb3J0IGV4dGVu c2lvbiBYLCB5b3Ugc2hvdWxkIGFsc28gcmVtZW1iZXIgdGhlIHZhbHVlIGZvciBzZXR0aW5nIFhf VkFMLiAgQ2xpZW50cyB0aGF0IGRvbid0IHVzZSB0aGUgZXh0ZW5zaW9uIGRvbid0IGNhcmUuICBB biBleHRlbnNpb24gdGhhdCBuZWVkZWQgc29tZSBtb3JlIGNvbXBsZXggbmVnb3RpYXRpb24gd291 bGQgaGF2ZSB0byB1c2UgYW4gZXh0ZW5zaW9uLXNwZWNpZmljIGZyYW1lLCBpdCdzIHRydWUsIGJ1 dCB3ZSBoYXZlbid0IHNvIGZhciBzZWVuIGFuIGV4dGVuc2lvbiBkbyB0aGF0Lg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZWZhbiBF aXNzaW5nDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDE1LCAyMDE3IDY6MjIgQU0NClRvOiBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBDb3JlIGRyYWZ0cyAtMDIgb3V0DQoNCg0KPiBBbSAxNC4w My4yMDE3IHVtIDAwOjU3IHNjaHJpZWIgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj46DQo+DQo+IFRoZSBlZGl0 b3JzIGhhdmUgc3VibWl0dGVkIC0wMiB2ZXJzaW9ucyBvZiB0aGUgYmFzZSBzZXQgb2YgUVVJQyBk cmFmdHMuDQpbLi4uXQ0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1x dWljLWh0dHAtMDINCg0KVGhhbmtzLCBNYXJ0aW4hIEkgYXNzdW1lIHRoYXQgd2FzIGFubm91bmNl ZCB0byBnZXQgZmVlZGJhY2sgZnJvbSB0aGUgbHVya2VycyBoZXJlLiA7LSkNCg0KSSdsbCBnaXZl IHRoaXMgYSB0cnkuIEFsbCBtaXN0YWtlcyBhbmQgbWlzdW5kZXJzdGFuZGluZ3MgYXJlIG1pbmUg YWxvbmUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClZlcnkgd2VsbCB3 cml0dGVuIHNwZWMuIEVhc3kgdG8gdW5kZXJzdGFuZCBmb3Igc29tZW9uZSBoYXZpbmcgcmVhZCBy ZmMgNzU0MCBhIGJpdC4NCg0KSSBoYXZlIHNvbWUgY29tbWVudHMgdG8gdGhlIHByb3Bvc2VkIEhU VFAgbWFwcGluZyBhcHByb2FjaC4gV2hlcmUgdGhlIHdnIGhhcyBhbHJlYWR5IGRpc2N1c3NlZCBh bmQgZXhoYXVzdGVkIGFsdGVybmF0aXZlcywgcGxlYXNlIGV4Y3VzZSBteSBpZ25vcmFuY2UgYW5k IGlnbm9yZSBteSBjb21tZW50cy4gSSBoYWQgbm90IHRoZSB0aW1lIHRvIGZvbGxvdyBhbGwgZGlz Y3Vzc2lvbnMgb25nb2luZyBvbiB0aGlzIHRvcGljLiBGZWVsIGZyZWUgdG8gY2hlcnJ5LXBpY2sg d2hhdCBzZWVtcyBoZWxwZnVsLg0KDQoNCj4gNC4gIFN0cmVhbSBNYXBwaW5nIGFuZCBVc2FnZQ0K DQorMSB0byBkaXJlY3RseSB1c2luZyBxdWljIHN0cmVhbSBpZHMgaW5zdGVhZCBvZiB2aXJ0dWFs IGgyIHN0cmVhbQ0KK2lkZW50aWZpZXINCg0KSG93ZXZlciwgdXNpbmcgMiBxdWljIHN0cmVhbXMg Zm9yIGEgc2luZ2xlIHJlcXVlc3QvcmVzcG9uc2UgZG9lcyBub3Qgc2l0IHdlbGwgd2l0aCBtZS4g SSBhc3N1bWUgdGhhdCBzdGVtcyBmcm9tIHRoZSB3aXNoIHRvIGdldCByaWQgb2YgREFUQSBmcmFt ZXMuIFdoaWNoIHNvdW5kcyBuaWNlLCBidXQgaXMgaXQgd29ydGggaXQ/IEJ5IGRvdWJsaW5nIHRo ZSAjIG9mIHN0cmVhbXMgZm9yIGEgY2xpZW50LCBob3cgbXVjaCBvdmVyaGVhZCBkb2VzIHRoYXQg aW50cm9kdWNlIChJIHNwZWFrIG9mIGEgc2VydmVyIGhvbGRpbmcgPjEwayBxdWljICJjb25uZWN0 aW9ucyIpPw0KDQpBbHNvLCB0aGUgc2VydmVyIG5lZWRzIHRvIGJ1ZmZlciBkYXRhIG9uIHF1aWMg c3RyZWFtcyA3LCAxMSwgMTUsIGV0Yy4gYmVjYXVzZSBIRUFERVJzIG1pZ2h0IGFycml2ZSBzb21l IHRpbWUgaW4gdGhlIGZ1dHVyZSBvbiBzdHJlYW1zIDUsIDksIDEzLCBldGMuIG9yIG5vdC4gVGhl cmUgaXMgbm8gd2F5IHRvIHJvdXRlIHRoaXMgZGF0YSBzb21ld2hlcmUsIGJlY2F1c2UgdGhlIG1l dGEgaW5mb3JtYXRpb24gaXMgc3RpbGwgbWlzc2luZy4NCg0KQW5kIHRoZXJlIGlzIHN0aWxsIEhv bGIgb246DQoNCj4gNC4yLjEuICBIZWFkZXIgQ29tcHJlc3Npb24NCj4gLi4uDQo+IERJU0NVU1M6 ICBLZWVwIEhQQUNLIHdpdGggSE9MQj8gIFJlZGVzaWduIEhQQUNLIHRvIGJlIG9yZGVyLQ0KPiAg ICAgICBpbnZhcmlhbnQ/ICBIb3cgbXVjaCBkbyB3ZSBuZWVkIHRvIHJldGFpbiBjb21wYXRpYmls aXR5IHdpdGgNCj4gICAgICAgSFRUUC8yJ3MgSFBBQ0s/DQoNClVzaW5nIGEgY291bnRlciBpbiBI RUFERVJTIGlzIGEgY3J1dGNoOg0KLSBpdCBpcyBhIGhpZ2hseSBzcGVjaWZpYyBzb2x1dGlvbiB0 byBhIGNvbW1vbiBwcm9ibGVtIGluIGh0dHAvcXVpYzogc3luY2hyb25pY2l0eSBpbiBjb25uZWN0 aW9uIGxldmVsIHN0YXRlIGNoYW5nZXMuIFNFVFRJTkdTIChzZWUgYmVsb3cpIGhhcyB0aGUgc2Ft ZSBwcm9ibGVtLCBhcyBkb2VzIGhhdmUgUFJJT1JJVFkgaW4gSEVBREVSUy4gSXQgc2VlbXMgdGhh dCBwZXJmb3JtYW5jZSB3aXNlLCBhbGwgSEVBREVSUyBjb3VsZCBhcyB3ZWxsIGJlIHNlbnQgb24g c3RyZWFtIDMuDQoNCk5vdywgc29sdmluZyBIb2wgYmxvY2tpbmcgZm9yIEhFQURFUlMgd291bGQg YmUgYSBmaW5lIGFjaGlldmVtZW50Lg0KDQo+IDUuICBIVFRQIEZyYW1pbmcgTGF5ZXINCj4gRnJh bWVzIGFyZSB1c2VkIG9ubHkgb24gdGhlIGNvbm5lY3Rpb24gKHN0cmVhbSAzKSBhbmQgbWVzc2Fn ZQ0KPiAgICAoc3RyZWFtcyA1LCA5LCBldGMuKSBjb250cm9sIHN0cmVhbXMuDQoNCkFuZCBzdHJl YW1zIDQsIDgsIDEyLCBldGMuIEkgYXNzdW1lLg0KDQo+IDUuMi4zLiAgU0VUVElOR1MNCj4gLi4u DQo+IFNFVFRJTkdTIGZyYW1lcyBhbHdheXMgYXBwbHkgdG8gYSBjb25uZWN0aW9uLCBuZXZlciBh IHNpbmdsZSBzdHJlYW0uDQo+ICBBIFNFVFRJTkdTIGZyYW1lIE1VU1QgYmUgc2VudCBhcyB0aGUg Zmlyc3QgZnJhbWUgb2YgdGhlIGNvbm5lY3Rpb24NCj4gY29udHJvbCBzdHJlYW0gKHNlZSBTZWN0 aW9uIDQpIGJ5IGVhY2ggcGVlciwgYW5kIE1VU1QgTk9UIGJlIHNlbnQNCj4gc3Vic2VxdWVudGx5 IG9yIG9uIGFueSBvdGhlciBzdHJlYW0uICBJZiBhbiBlbmRwb2ludCByZWNlaXZlcyBhbg0KPiBT RVRUSU5HUyBmcmFtZSBvbiBhIGRpZmZlcmVudCBzdHJlYW0sIHRoZSBlbmRwb2ludCBNVVNUIHJl c3BvbmQgd2l0aA0KPiBhIGNvbm5lY3Rpb24gZXJyb3Igb2YgdHlwZSBIVFRQX1NFVFRJTkdTX09O X1dST05HX1NUUkVBTS4gIElmIGFuDQo+IGVuZHBvaW50IHJlY2VpdmVzIGEgc2Vjb25kIFNFVFRJ TkdTIGZyYW1lLCB0aGUgZW5kcG9pbnQgTVVTVCByZXNwb25kDQo+IHdpdGggYSBjb25uZWN0aW9u IGVycm9yIG9mIHR5cGUgSFRUUF9NVUxUSVBMRV9TRVRUSU5HUy4NCg0KV2hhdCBhYm91dCBIUEFD SyBzdGF0ZT8gVGhlIGNvbm5lY3Rpb24gc3RhdGUgY2hhbmdlIHByb2JsZW0gYWdhaW4gdmlzaWJs ZS4NCg0KVGhpcyBpcyBhIHNldmVyZSByZXN0cmljdGlvbiBvbiBleHRlbnNpb25zIG1lY2hhbmlz bXMgdGhhdCB3YW50IHRvIGFmZmVjdCBhIGNvbm5lY3Rpb24uIEJlY2F1c2UgaWYgdGhlIGh0dHAv cXVpYyBkb2VzIG5vdCBzb2x2ZSB0aGlzIHByb2JsZW0sIGhvdyBhcmUgdGhleSBleHBlY3RlZCB0 byBkbyBpdD8gVGhleSBlaXRoZXIgYW5ub3VuY2UgdGhlbXNlbHZlcyBvbiB0aGUgZmlyc3QgU0VU VElOR1Mgb3IgcmVtYWluIHNpbGVudCBmb3JldmVyLCBpdCBzZWVtcy4gSG93IHdvdWxkIGFuIGV4 dGVuc2lvbiBoYW5kc2hha2Ugd29yayB0aGVuPyBPd24gc3RyZWFtIDMgaGFuZHNoYWtlIGZyYW1l cz8NCg0KPiA1LjIuMy4zLiAgVXNhZ2UgaW4gMC1SVFQNCg0KV2hhdCBhYm91dCBIUEFDSyBzdGF0 ZT8gRG9lcyBpdCBuZWVkIHRvIGJlIGtlcHQgb3IgaXMgaXQgcmVzZXQ/DQoNCj4gSFRUUF9QVVNI X0FMUkVBRFlfSU5fQ0FDSEUgKDB4MDMpOiAgVGhlIHNlcnZlciBoYXMgYXR0ZW1wdGVkIHRvIHB1 c2gNCj4gICAgICBjb250ZW50IHdoaWNoIHRoZSBjbGllbnQgaGFzIGNhY2hlZC4NCj4gLi4uDQo+ IEhUVFBfUkVRVUVTVF9DQU5DRUxMRUQgKDB4MDQpOiAgVGhlIGNsaWVudCBubyBsb25nZXIgbmVl ZHMgdGhlDQo+ICAgICByZXF1ZXN0ZWQgZGF0YS4NCg0KTml0cGljazogc2VlbXMgcmVkdW5kYW50 LiBUaGUgZmlyc3QgY291bGQgYmUgcmVwbGFjZWQgYnkgdGhlIHNlY29uZC4gU3RyZWFtIG51bWJl ciB3aWxsIHN1ZmZpY2UuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGFraW5nIHR3byBzdGVwcyBiYWNrOg0KDQpJIHRoaW5r IHRoZSBtYWluIGRpZmZpY3VsdHkgY29tZXMgZnJvbSB0aGUgbGFjayBvZiBhICJocSBjb25uZWN0 aW9uIHN0YXRlIiBjb25jZXB0IGFuZCBob3cgY2hhbmdlcyB0byB0aGF0IHN0YXRlIGNhbiBiZSBt YW5hZ2VkLiBFdmlkZW5jZToNCi0gVGhlIDAtUlRUIG1lbnRpb25zIGNlcnRhaW4gU0VUVElOR1Mg dGhhdCBuZWVkIHRvIGJlIHJlbWVtYmVyZWQgYnkgYSBjbGllbnQuIEhvdyB3b3VsZCBhbiBleHRl bnNpb24gYWRkIHRvIHRoaXM/IFdpbGwgZXZlcnkgZXh0ZW5zaW9uIGhhdmUgdG8gY29tZSB1cCB3 aXRoIGl0cyBvd24gc29sdXRpb24/DQotIFRoZSBIRUFERVJzIHNlcXVlbmNlIG51bWJlciBpcyBh IGhpZ2hseSBzcGVjaWZpYyBmaXggZm9yIHRoZSBtaXNzaW5nIHN0YXRlIGNoYW5nZQ0KLSBUaGUg U0VUVElOR1MtT05DRSByZXN0cmljdGlvbiBzaW1wbHkgYXZvaWRzIHRoZSBwcm9ibGVtIGJ5IGtp bGxpbmcgYSBoMiBtZWNoYW5pc20NCg0KSWYgaHEgZGVmaW5lcyBzdHJlYW0gMyBhcyB0aGUgcGxh Y2Ugd2hlcmUgY29ubmVjdGlvbiBzdGF0ZSBjaGFuZ2VzIGhhcHBlbiAqQU5EKiBzeW5jaHJvbml6 ZXMgT1BFTi9DTE9TRS9SU1Qgb2Ygb3RoZXIgc3RyZWFtcyBvbiBpdCwgY2xpZW50IGFuZCBzZXJ2 ZXIgY2FuIGhhdmUgc2hhcmVhYmxlIGNvbmNlcHQgb2YgdGhlIGNvbm5lY3Rpb24gc3RhdGUuDQoN Cg0KSSBhbSBubyBIUEFDSyBleHBlcnQuIFRoZSBiYXNpYyBwcm9ibGVtIGxvb2tzIGxpa2UgY29u Y3VycmVudCBlZGl0aW5nIGFnYWluc3QgYSByZXBvc2l0b3J5Lg0KQm90aCBjbGllbnQgYW5kIHNl cnZlciBzdGFydCB3aXRoIGNvbm5lY3Rpb24gc3RhdGUgemVybyAoQ1MtMCkgYW5kIHRoZSBwcmVk ZWZpbmVkIEhQQUNLIGRpY3Rpb25hcnkgKEhQLTApLiBBZnRlciBTRVRUSU5HUyBleGNoYW5nZSwg Y2xpZW50IGlzIGluIENTLTEgYW5kIHNlcnZlciBpcyBpbiBDUy0yIGZvciBpdHMgc2lkZS4gTGV0 J3MgY2FsbCB0aGUgIENTLTEgSFBBQ0sgc3RhdGUgSFAtMS4NCg0KQ2xpZW50IHNlbmRzIG5ldyBI RUFERVJTIG9uIDUgYW5kIGtlZXBzIHRoZSBIUEFDSyBkZWx0YSBhcm91bmQgKEhQLTEuNSkuIFRo ZSBIRUFERVJTIGNhcnJpZXMgdGhlIGNvbm5lY3Rpb24gc3RhdGUgbnVtYmVyIGl0IGlzIGJhc2Vk IG9uIChDUy0xKS4gQ2xpZW50IHNlbmRzIG5ldyBIRUFERVJTIG9uIHN0cmVhbSA5LCBhbHNvIGJh c2VkIG9uIENTLTEuIENsaWVudCBrZWVwcyB0aGF0IGRlbHRhIGFyb3VuZCAoSFAtMS45KS4NCg0K Q2xpZW50IHRoZW4gZGVjaWRlcyB0byBhbm5vdW5jZSBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIChD Uy0zKSBieSBzZW5kaW5nIGhvdyBpdCBhcHBsaWVkIHRoZSBkZWx0YXMgSFAtMS41IGFuZCBIUC0x LjkgdG8gY29tZSB1cCB3aXRoIEhQLTMuIFRoZSBkZXNjcmlwdGlvbiBhbGxvd3MgdGhlIHNlcnZl ciB0byB1cGRhdGUgaXRzIEhQLTEgdG8gSFAtMyBhcyB3ZWxsLg0KDQpSZXNwb25zZSBIRUFERVJT IGFyZSBhbHNvIGJhc2VkIG9uIGEgc2VydmVyIGNvbm5lY3Rpb24gc3RhdGUsIGV4cGxpY2l0bHks IHNvIHRoZSBjbGllbnQga25vd3Mgd2hpY2ggSFAtWCB0byB1c2Ugd2hlbiBkZWNvZGluZyB0aGVt LiBBdCBzb21lIHRpbWUsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4gYW5ub3VuY21lbnQgb2YgQ1MtNCB3 aXRoIEhQQUNLIGRhdGEgb24gc3RyZWFtIDMgYmFjayB0byB0aGUgY2xpZW50Lg0KDQpGb3IgYSAw LVJUVCwgY2xpZW50IGFuZCBzZXJ2ZXIgY291bGQgZXhjaGFuZ2UgdGhlIGNvbm5lY3Rpb24gc3Rh dGUgaWQgaW4gdGhlIGluaXRpYWwgU0VUVElOR1MsIHRvIG1ha2Ugc3VyZSB0aGV5IGhhdmUgYXQg bGVhc3QgdGhlIHNhbWUgbmFtZSByZW1lbWJlcmVkIGFzIHRoZSBvdGhlciBzaWRlLiBDbGllbnQ6 ICJJIHdhcyBpbiBDUy0xOSBhbmQgeW91IHdlcmUgaW4gQ1MtOC4iIFNlcnZlcjogIlllcC4iDQoN CkJ5IGltcGxpY2l0bHkgYWRkaW5nIGFsbCBTRVRUSU5HUyBjaGFuZ2VzIHRvIGNvbm5lY3Rpb24g c3RhdGVzLCB0aGUgcHJvYmxlbSBpcyBhbHNvIHNvbHZlZCBmb3IgZXh0ZW5zaW9ucy4NCg0KSWYg b25lIHNpZGUgcmVjZWl2ZXMgSEVBREVSUyB3aXRoIGFuIHVua25vd24gY29ubmVjdGlvbiBzdGF0 ZToNCi0gaWYgdGhlIHN0YXRlIGlkIGlzIGdyZWF0ZXIgdGhhbiBhbnkga25vd24gb25lOiBzZXQg YSBzdHJlYW0gdGltZW91dCBhbmQgd2FpdCBmb3IgY2hhbmdlcyBvbiBzdHJlYW0gMyB0byBhcnJp dmUNCi0gc3RhdGUgaWQgbGVzcyB0aGFuIG1heChrbm93biBjb25uIHN0YXRlKTogU1RSRUFNX1JT VF9VTktOT1dOX0NPTk5fU1RBVEUNCg0KTmV3IFNFVFRJTkdTIHZhbHVlOiBNQVhfQ09OTl9TVEFU RSBudW1iZXIgb2YgbWF4aW11bSBjb25uZWN0aW9uIHN0YXRlIHRoZSBjbGllbnQvc2VydmVyIGlz IHdpbGxpbmcgdG8ga2VlcCwgZXhjaGFuZ2VkIGluaXRpYWxseS4gQW5ub3VuY2luZyBhIG5ldyBj b25uZWN0aW9uIHN0YXRlIGFsbG93cyB0aGUgb3RoZXIgc2lkZSB0byBkcm9wIHRoZSBsb3dlc3Qg b25lLCBpZiBNQVhfQ09OTl9TVEFURSBhcmUgdXNlZC4NCg0KVG8gZ2V0IG9wdGltYWwgSFBBQ0sg c2l6ZSBjb21wcmVzc2lvbiwgZXZlcnkgSEVBREVScyB3b3VsZCBhbHNvIGFubm91bmNlIGEgbmV3 IGNvbm5lY3Rpb25zIHN0YXRlLiBUbyBoYXZlIGxlc3MgcG90ZW50aWFsIEhPTEIsIGNvbm5lY3Rp b24gc3RhdGVzIGRvIG5vdCBjaGFuZ2UgZHVyaW5nIHJlcXVlc3QgYnVyc3RzLg0KDQpTb21ldGhp bmcgbGlrZSB0aGF0Lg0KDQotU3RlZmFuDQoNCg0KDQoNCi0tDQpDaGFybGVzICdCdWNrJyBLcmFz aWMgfCBTb2Z0d2FyZSBFbmdpbmVlciB8IGNrcmFzaWNAZ29vZ2xlLmNvbTxtYWlsdG86Y2tyYXNp Y0Bnb29nbGUuY29tPiB8ICsxICg0MDgpIDQxMi0xMTQxPHRlbDooNDA4KSUyMDQxMi0xMTQxPg0K DQoNCg0KLS0NCkNoYXJsZXMgJ0J1Y2snIEtyYXNpYyB8IFNvZnR3YXJlIEVuZ2luZWVyIHwgY2ty YXNpY0Bnb29nbGUuY29tPG1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20+IHwgKzEgKDQwOCkgNDEy LTExNDE8dGVsOig0MDgpJTIwNDEyLTExNDE+DQoNCg== --_000_BN6PR03MB27084E9ADE721FFF85980DEF873F0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo1OTEyMDY0ODY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxG MEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzM5MDE2MTc0Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEI3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2l0aCByZWdhcmQgdG8gaGVhZGVyIGJsb2NrIHZlcnN1cyBmcmFtZSwgdGhvdWdoLCB5b3UgZXhw bGljaXRseSBzYWlkIGluIHlvdXIgcmVwbHkgYmVmb3JlIHRoYXQgdGhlIGVuY29kZXIgY2FuIHN3 aXRjaCBtb2RlcyBiZXR3ZWVuIGZyYW1lcyBpbiBhIHNpbmdsZSBibG9jay4mbmJzcDsgU28gSSB0 aGluayB5b3UgbWVhbiB3aGF0IHlvdSB3cm90ZTsgaXTigJlzIGp1c3QgdGhhdCBzd2l0Y2hpbmcg d2hldGhlciB0aGluZ3MNCiBjYW4gYmUgaW50ZXJwcmV0ZWQgb3V0IG9mIG9yZGVyIG1pZC1ibG9j ayBmZWVscyB3ZWlyZC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBQT1NJWCBvciBub3QsIEkgZG9uJ3QgdGhp bmsgeW91IGNhbiB1bmlsYXRlcmFsbHkgZGVmaW5lIGEgc2VtYW50aWMgYWJvdXQgZGVsaXZlcnkg dG8gdGhlIHJlbW90ZSBhcHAgbGF5ZXIuJm5ic3A7IFRob3VnaCB5b3UgY291bGQgY29tZSBjbG9z ZSDigJMgaWYgdGhlIGNhbGwgY29tcGxldGVkIHdoZW4gdGhlIHdyaXR0ZW4gZGF0YSBhbmQgYWxs IHByZWNlZGluZyBkYXRhIG9uIHRoZSBzdHJlYW0gaGFkIGJlZW4gQUNL4oCZZCwNCiB5b3Uga25v dyBhdCBsZWFzdCB0aGF0IHRoZSBkYXRhIGlzIGF2YWlsYWJsZSB0byB0aGUgcmVtb3RlIGFwcCBs YXllciDigJMgd2hldGhlciBpdCByZWFkcyBwcm9tcHRseSBpcyBpdHMgb3duIHByb2JsZW0uPC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZW50IGZyb20gbXkgV2luZG93cyAxMCBwaG9uZTwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6 cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PGI+RnJvbTogPC9iPjxhIGhyZWY9Im1haWx0bzpj a3Jhc2ljQGdvb2dsZS5jb20iPkNoYXJsZXMgJ0J1Y2snIEtyYXNpYzwvYT48YnI+DQo8Yj5TZW50 OiA8L2I+VGh1cnNkYXksIE1hcmNoIDIzLCAyMDE3IDI6NTggUE08YnI+DQo8Yj5UbzogPC9iPjxh IGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIj5NaWtlIEJpc2hvcDwv YT48YnI+DQo8Yj5DYzogPC9iPjxhIGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVlbmJ5 dGVzLmRlIj5TdGVmYW4gRWlzc2luZzwvYT47IDxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20iPg0KTWFydGluIFRob21zb248L2E+OyA8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyI+SUVURiBRVUlDIFdHPC9hPjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogQ29yZSBk cmFmdHMgLTAyIG91dDwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGRpcj0i bHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIFRodSwgTWFyIDIzLCAyMDE3IGF0IDEwOjUyIEFNLCBNaWtlIEJpc2hvcCA8 c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJtXy0yOTg1NTU1NDc4NDU0MjcwMjkybV8tMTc1MDU4NTc0MDQzNTgy OTI2OG1fLTQ3MjE0MDg1NTU4MTY4NTIxNzhXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWxsIEkgc2VlIGluIHRoZSBsaW5rcyBhcmUgaHR0cDovLyBhbmQgdGhlIGRyYWZ0IG5h bWUsIG5vIGhvc3QuJm5ic3A7IEnigJltIGd1ZXNzaW5nIHlvdSBtZWFudA0KPGEgaHJlZj0iaHR0 cHM6Ly9naXRodWIuY29tL2tyYXNpYy9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay9ibG9iL21hc3Rl ci9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2dpdGh1Yi5jb20va3Jhc2ljL2RyYWY8d2JyPnQta3Jhc2ljLXF1aWMtaHBhY2svYmxvYi9t YXN0ZTx3YnI+ci9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5oPHdicj50bWw8L2E+PyZuYnNw OyBPbmNlIHRoZSB0cmFja2VyIHJlb3BlbnMgKHNvbWV0aW1lIFN1bmRheSwgSSB0aGluaykgeW91 IHNob3VsZCBwcm9iYWJseSB1cGxvYWQgdGhvc2UgYXQNCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRhdGF0cmFja2VyLmlldGYub3JnPC9hPiB0 byBtYWtlIGl0IGFuIG9mZmljaWFsIHN1Ym1pc3Npb24uPGEgbmFtZT0ibV8tMjk4NTU1NTQ3ODQ1 NDI3MDI5Ml9tXy0xNzUwNTg1NzQwNDM1ODI5MjY4X21fLTQ3MjE0MDg1NTU4MTY4NTIxNzhfX01h aWxFbmRDb21wb3NlIj4mbmJzcDsgWW914oCZbGwgbmVlZCB0byBtYWtlIHRoZSBkcmFmdCBuYW1l IGluIHRoZSBmaWxlDQogbWF0Y2ggdGhlIGZpbGUgbmFtZSBiZWZvcmUgaXQgd2lsbCBzdWNjZXNz ZnVsbHkgdXBsb2FkLjx1PjwvdT48dT48L3U+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuPjx1PjwvdT4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5UaGFua3MgZm9y IHRoZSBwcm9tcHQgZmVlZGJhY2shPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxkaXY+QXBvbG9naWVzLCBhcyBJIG1lbnRpb25lZCBpdCBpcyBteSBm aXJzdCBhdHRlbXB0IGF0IGFuIElFVEYgZHJhZnQsIGFuZCBpdCBteSBmaXJzdCB0aW1lIHVzaW5n IHRoZSB0b29scyBhcyBkZXNjcmliZWQgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5j b20vbWFydGludGhvbXNvbi9pLWQtdGVtcGxhdGUvYmxvYi9tYXN0ZXIvZG9jL1NFVFVQLm1kIiB0 YXJnZXQ9Il9ibGFuayI+U0VUVVAubWQ8L2E+LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+VW50aWwgSSB0aGUgdHJhY2tlciByZW9wZW5zIGFuZCBJIHN1Ym1pdCBwcm9wZXJseSwgSSB3 b3VsZCBzdWdnZXN0Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9rcmFzaWMuZ2l0aHViLmlvL2RyYWZ0 LWtyYXNpYy1xdWljLWhwYWNrL2RyYWZ0LWtyYXNpYy1xdWljLXFwYWNrLWxhdGVzdC5odG1sIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9rcmFzaWMuZ2l0aHViLjx3YnI+aW8vZHJhZnQta3Jhc2lj LXF1aWMtaHBhY2svZHJhPHdicj5mdC1rcmFzaWMtcXVpYy1xcGFjay1sYXRlc3QuPHdicj5odG1s PC9hPjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJtXy0yOTg1NTU1NDc4NDU0MjcwMjkybV8tMTc1MDU4NTc0 MDQzNTgyOTI2OG1fLTQ3MjE0MDg1NTU4MTY4NTIxNzhXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3Bhbj5BbHNvLCBmb3IgZWFzZSBvZiBkaXNjdXNzaW9uLCB5b3UgbWlnaHQgcGljayBhIGRp ZmZlcmVudCBuYW1lIHRoYW4gUVBBQ0ssIHNpbmNlIHRoZXJl4oCZcyBhbHJlYWR5IGEgZHJhZnQg d2l0aCB0aGF0IG5hbWUuJm5ic3A7IChPciB3ZSBib3RoIGNoYW5nZSBuYW1lcywgYW5kIGNhbGwg dGhlIGV2ZW50dWFsbHktYWRvcHRlZCBvbmUgUVBBQ0s7IHRoYXTigJlkIGJlIGZpbmUsIHRvby4p PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5JJ20gZmluZSB3aXRoIHdoYXRldmVyLiZuYnNwOyBJZiAmbmJzcDtkcmFmdC1r cmFzaWMgdnMgZHJhZnQtYmlzaG9wIGlzbid0IGVub3VnaCB0byBkaWZmZXJlbnRpYXRlLCAmbmJz cDtob3cgYWJvdXQgUVBBQ0stQUxULCBvciBtYXliZSBRUEFDSy1MSVRFPyZuYnNwOzwvZGl2Pg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Im1fLTI5ODU1 NTU0Nzg0NTQyNzAyOTJtXy0xNzUwNTg1NzQwNDM1ODI5MjY4bV8tNDcyMTQwODU1NTgxNjg1MjE3 OFdvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48dT48L3U+Jm5ic3A7PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj5BcyB0byBhY3R1YWwg ZmVlZGJhY2s6Jm5ic3A7IEkgc2VlIHdoYXQgeW914oCZcmUgZ2V0dGluZyBhdCBoZXJlIGJlY2F1 c2UgeW914oCZdmUgZXhwbGFpbmVkIGl0IOKAkyB0aGUgZGVjb2RlciBhY2tub3dsZWRnZXMgdGhl IHNlcXVlbmNlIG51bWJlciBpdOKAmXMgdXAgdG8sIHRoZW4gdGhlIGVuY29kZXIgdHJhY2tzIHRo YXQgYW5kIHVzZXMgaXQgb24gdGhlIGVuY29kZSBzaWRlLiZuYnNwOyBJIHRoaW5rIEnigJlkIGhh dmUgYSByZWFsbHkNCiBoYXJkIHRpbWUgcGFyc2luZyB0aGUgZG9jdW1lbnQgd2l0aG91dCB0aGF0 LiZuYnNwOyBJIHRoaW5rIHRoZSBzdHJvbmdlc3QgYWR2YW50YWdlIG9mIHRoaXMgcHJvcG9zYWwg aXMgdGhhdCBhbiBlbmNvZGVyIGZvciB0aGlzIHNjaGVtZSBjb3VsZCBiZSB1c2VkIG92ZXIgSFRU UC8yLCBlbmFibGluZyBzaGFyZWQgY29kZTsgeW91IHNob3VsZCBicmluZyB0aGF0IG91dCBtb3Jl Ljwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+SSdsbCB0cnkgdG8gcmV3b3JrIHRoZSB0ZXh0IHRvIGVtcGhpc2UgdGhvc2Ug cG9pbnRzIG1vcmUgYW5kIGNsYXJpZnkuICZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1 dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPk5pdHM6ICZuYnNwO3RoZSBkZWNvZGVy IHBlci1zZSBkb2Vzbid0IGFjaywgYnV0IHRoZSBlbmNvZGVyIHRyYWNrcyB1c2luZyBleGlzdGlu ZyB0cmFuc3BvcnQgbGV2ZWwgYWNrIG1lY2hhbmlzbXMgKG1vcmUgb24gdGhpcyBiZWxvdykuICZu YnNwOyBBbHNvLCBJIHRoaW5rIG9mIHRoaXMgc2NoZW1lIGFzIHNvbWV0aGluZyBhIHNoYXJlZCBp bXBsZW1lbnRhdGlvbiBjb3VsZCBvZmZlciBhcyBhbiBvcHRpb24sIGJ1dCBJIGhhZG4ndCBpbWFn aW5lZA0KIHRoZSBvcHRpb24gd291bGQgYmUgZXZlciBiZSBlbmFibGVkIGluIEhUVFAvMi4mbmJz cDsgSXQgbWlnaHQgYmUgaW50ZXJlc3RpbmcgdG8gY29uc2lkZXIgdGhvdWdoLjwvZGl2Pg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Im1fLTI5ODU1NTU0 Nzg0NTQyNzAyOTJtXy0xNzUwNTg1NzQwNDM1ODI5MjY4bV8tNDcyMTQwODU1NTgxNjg1MjE3OFdv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj5UaGUgd2F5IHlvdeKAmXZl IGRlc2NyaWJlZCB0aGUgZW5jb2RlciByZXF1aXJlcyB0aWdodCBpbnRlZ3JhdGlvbiBiZXR3ZWVu IHRoZSBwYWNrZXRpemF0aW9uIGxvZ2ljIGFuZCB0aGUgaGVhZGVyIGNvbXByZXNzb3IgaW4gdHdv IHdheXM6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Im1fLTI5ODU1NTU0Nzg0NTQyNzAyOTJtXy0xNzUw NTg1NzQwNDM1ODI5MjY4bV8tNDcyMTQwODU1NTgxNjg1MjE3OE1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4+SXQgbmVlZHMgdG8ga25vdyB0aGUg4oCccGFj a2V0IGVwb2No4oCdIChlbmNvZGUgZXBvY2ggb2YgdGhlIGZpcnN0IGZyYW1lIGluIHRoZSBjdXJy ZW50IHBhY2tldCkgd2hpbGUgY29tcHJlc3NpbmcsIGJ1dCB1bnRpbCB5b3Uga25vdyB0aGUgc2l6 ZSBvZiB0aGUgY29tcHJlc3NlZCBvdXRwdXQsIHlvdSBjYW7igJl0IGtub3cgd2hldGhlciBpdCB3 aWxsIGZpdCBpbiB0aGUgY3VycmVudCBwYWNrZXQuJm5ic3A7IFRoYXQgaW4gdHVybiBtZWFucyB5 b3XigJlsbCBuZWVkDQogdG8gcm9sbCBiYWNrIGFueSBzdGF0ZSBhbmQgcmUtZW5jb2RlIHdpdGgg YSBkaWZmZXJlbnQgcGFja2V0IGVwb2NoIGlmIGl0IHR1cm5zIG91dCBub3QgdG8gZml0Ljwvc3Bh bj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPkkgZG9uJ3QgdGhpbmsgcm9sbCBiYWNrIGlzIGVz c3NlbnRpYWwuICZuYnNwOyZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iPlRoZSBzcGFjZSBhdmFpbGFibGUgaW4gdGhlIGN1cnJlbnQgcGFj a2V0IGNvdWxkIGJlIGtub3duIHdoZW4gaW52b2tpbmcgdGhlIGhwYWNrIGVuY29kZXIsIHNvIGl0 IHdvdWxkIHN0b3AgZW1pdHRpbmcgcmVwcmVzZW50YXRpb25zIGlmIHRoZSBwYWNrZXQgcmVhY2hl cyB0aGUgc3BhY2UgbGltaXQsIGFuZCBpbiB0aGF0IGNhc2UgcmV0dXJuIGEgaGVhZGVyIGJsb2Nr IHRoYXQgZm9yIGEgcHJlZml4IG9mIHRoZSBwcm92aWRlZA0KIGhlYWRlciBmaWVsZCBsaXN0LCBh bmQgaW4gbGF0ZXIgcGFja2V0cyBpdCB3b3VsZCBnZW5lcmF0ZSBhIGNvbnRpbnVhdGlvbiBoZWFk ZXIgYmxvY2socykgZm9yIHJlbWFpbmluZyBoZWFkZXIgZmllbGRzLjwvZGl2Pg0KPGRpdiBkaXI9 ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PC9kaXY+DQo8ZGl2IGRpcj0ibHRy Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJtXy0yOTg1 NTU1NDc4NDU0MjcwMjkybV8tMTc1MDU4NTc0MDQzNTgyOTI2OG1fLTQ3MjE0MDg1NTU4MTY4NTIx NzhXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Im1fLTI5ODU1NTU0Nzg0NTQyNzAyOTJtXy0xNzUwNTg1NzQwNDM1ODI5MjY4 bV8tNDcyMTQwODU1NTgxNjg1MjE3OE1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW4iPg0KPHNwYW4+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9saT48bGkgY2xhc3M9Im1fLTI5 ODU1NTU0Nzg0NTQyNzAyOTJtXy0xNzUwNTg1NzQwNDM1ODI5MjY4bV8tNDcyMTQwODU1NTgxNjg1 MjE3OE1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4+VGhl IOKAnGNvbW1pdCBlcG9jaOKAnSBpcyBkZXRlcm1pbmVkLCBub3QgYnkgZGF0YSBhdCB0aGUgY29t cHJlc3NvciBsZXZlbCwgYnV0IGJ5IHJlYWNoaW5nIGludG8gdGhlIHRyYW5zcG9ydCBhbmQgY2hl Y2tpbmcgd2hpY2ggcGFja2V0cyBjb250YWluaW5nIHRoZSBTVFJFQU0gZnJhbWVzIGNvbnRhaW5p bmcgdGhlIEhQQUNLIGRhdGEgaW4gcXVlc3Rpb24gaGF2ZSBiZWVuIGFja25vd2xlZGdlZC4mbmJz cDsgQWxzbyBub3RlIHRoYXQgQUNLIGRvZXNu4oCZdA0KIHNpZ25pZnkgZGVsaXZlcnkgdG8gdGhl IGFwcGxpY2F0aW9uIGxheWVyIChIVFRQKSwganVzdCBwcmVzZW5jZSBpbiB0aGUgYXBwcm9wcmlh dGUgcXVldWUuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4+PHU+PC91PiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPk15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBBUElzIGFyZSBvdXQgb2Ygc2NvcGUgb2YgbW9zdCBvZiB0aGUg ZG9jcy4gJm5ic3A7IEhvd2V2ZXIsIGluIG91ciBpbXBsZW1lbnRhdGlvbiwgdGhlIHN0cmVhbSB3 cml0ZSBpbnRlcmZhY2VzIHVuaWZvcm1seSBwcm92aWRlIGEgbWVhbnMgb2YgdG8gY29uZmlybSBh Y2tub3dsZWRnZW1lbnQsICZuYnNwO3NvIGl0IGlzIHBvc3NpYmxlIHRvIGRvIGl0IHdpdGhvdXQg cmVhY2hpbmcgZG93bi4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4N CjxkaXYgZGlyPSJhdXRvIj5JIGFncmVlIHRoYXQgQUNLIGRvZXNuJ3Qgc2lnbmlmeSBkZWxpdmVy eSB0byB3aGF0IGlzIGFib3ZlIEhUVFAsIGJ1dCBvbmUgb2YgYWR2YW50YWdlcyBvZiBub3QgaGF2 aW5nIGxlZ2FjeSBBUElzIChQT1NJWCBzb2NrZXRzKSBiZXR3ZWVuIFFVSUMgYW5kIEhUVFAgaXMg dGhhdCB0aGUgaW1wbGVtZW5hdGlvbiBjYW4gY2VydGFpbmx5IGVuc3VyZSB0aGF0IEFDSyBzaWdu aWZpZXMgZGVsaXZlcnkgdG8gSFRUUC48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Im1fLTI5ODU1NTU0Nzg0NTQyNzAy OTJtXy0xNzUwNTg1NzQwNDM1ODI5MjY4bV8tNDcyMTQwODU1NTgxNjg1MjE3OFdvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuPkluIDIuMi4xLjEsIHRoZSBlbmNvZGVyIGlzIGluZm9ybWVk IHdoZXRoZXIg4oCcUVBBQ0sgaXMgZW5hYmxlZCzigJ0gYnV0IHNpbmNlIHRoYXQgY2FuIGJlIHRv Z2dsZWQgb24vb2ZmIG9uIGEgcGVyLWhlYWRlci1mcmFtZSBiYXNpcyAoYW5kIEkgaG9wZSB5b3Ug cmVhbGx5IG1lYW50IHBlci1oZWFkZXItYmxvY2spLCBpdCBzZWVtcyBsaWtlIHRoZSBkZWNvZGVy IGlzIGp1c3QgZm9sbG93aW5nIHRoZSBlbmNvZGVy4oCZcw0KIGxlYWQgb24gdGhpcy4mbmJzcDsg V2hv4oCZcyBhY3R1YWxseSBtYWtpbmcgdGhhdCBkZWNpc2lvbj8mbmJzcDsgWW91IHNheSBpdCBn ZXRzIHR1cm5lZCBvZmYgaWYgYSBkcm9wIHJlc3VsdHMsIGJ1dCB0aGUgZW5jb2RlciBpcyB0aGUg b25lIHdobyBrbm93cy9kZXRlcm1pbmVzIHRoYXQuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+ WWVzLCBhbGwgZGVjaXNpb25zIGFyZSBtYWRlIGJ5IHRoZSBlbmNvZGVyLCBhbmQgYXMgaW4gSFBB Q0sgdGhlIGRlY29kZXIgc3RyaWN0bHkgZm9sbG93cyB0aGUgZW5jb2RlcidzIGxlYWQuICZuYnNw OyZuYnNwOzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1 dG8iPlRoZSAmcXVvdDtpbmZvcm1lZCZxdW90OyBsYW5ndWFnZSB3YXMgc2ltcGx5IGFsbHVkaW5n IHRvIHRoZSBlbmNvZGVyIHNpZGUgb2YgdGhlIEhQQUNLIEFQSSBiZWluZyBleHRlbmRlZCB3aXRo IFFQQUNLIHJlbGF0ZWQgcGFyYW1zLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iPkFuZCB5ZXMsIEkgbWVhbnQgJnF1b3Q7aGVhZGVyIGJsb2NrJnF1 b3Q7LiZuYnNwOyBXaWxsIGZpeCB0aGF0LjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwv ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0ibV8tMjk4NTU1NTQ3ODQ1NDI3MDI5Mm1fLTE3NTA1ODU3NDA0MzU4MjkyNjht Xy00NzIxNDA4NTU1ODE2ODUyMTc4V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuPjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+VGhp cyBoYXMgdGhlIHNhbWUgcHJvYmxlbSBhcyB0aGUgY3VycmVudCBIUEFDSyBzdGF0ZSB0aGF0IFJT VCBvbiBhIGNvbnRyb2wgc3RyZWFtIGxvc2VzIGNyaXRpY2FsIGRhdGEgYW5kIHRoZXJl4oCZcyBu byB3YXkgdG8gcmVjb3Zlci4mbmJzcDsgSeKAmW0gcGVyc29uYWxseSBob3Bpbmcgd2UgY2FuIG1h a2Ugb3VyIHdheSBvdXQgb2YgdGhhdCByZXF1aXJlbWVudC48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJh dXRvIj5NeSBwb3NpdGlvbiBpcyB0aGF0IFJFRlVTRUQgc2hvdWxkIGJlIHRoZSBvbmx5IGtpbmQg b2YgUlNUIG5lZWRlZCBvciBhbGxvd2VkIGZvciBjb250cm9sIHN0cmVhbXMsIGFuZCBkZWFsaW5n IHdpdGggdGhhdCBpcyB0cmFjdGlibGUuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+PGJyPg0KPC9k aXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJtXy0yOTg1NTU1NDc4NDU0MjcwMjkybV8tMTc1MDU4NTc0MDQzNTgyOTI2OG1f LTQ3MjE0MDg1NTU4MTY4NTIxNzhXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHNwYW4+PC9zcGFuPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IENoYXJsZXMgJ0J1Y2snIEtyYXNpYyBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5ja3Jh c2ljQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDIx LCAyMDE3IDY6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJt YWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gU3RlZmFuIEVp c3NpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlIiB0 YXJnZXQ9Il9ibGFuayI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTwvYT4mZ3Q7PHdicj47 IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDs7IElF VEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ibV8tMjk4 NTU1NTQ3ODQ1NDI3MDI5Mm1fLTE3NTA1ODU3NDA0MzU4MjkyNjhoNSI+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBDb3JlIGRyYWZ0cyAtMDIgb3V0PHU+PC91Pjx1PjwvdT48L2Rpdj4NCjwvZGl2 Pg0KPHA+PC9wPg0KPGRpdj4NCjxkaXYgY2xhc3M9Im1fLTI5ODU1NTU0Nzg0NTQyNzAyOTJtXy0x NzUwNTg1NzQwNDM1ODI5MjY4aDUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRm9sa3MuPHU+PC91 Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ3ZlIHB1dCB0 b2dldGhlciBhIGZpcnN0IGF0dGVtcHQgYXQgbXkgUVBBQ0sgcHJvcG9zYWw6PHU+PC91Pjx1Pjwv dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7 PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHA6Ly9kcmFmdC1rcmFzaWMtcXVpYy1ocGFjay0wMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+ ZHJhZnQta3Jhc2ljLXF1aWMtaHBhY2stMDAuaHRtPHdicj5sPC9hPjx1PjwvdT48dT48L3U+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9r cmFzaWMuZ2l0aHViLmlvL2RyYWZ0LWtyYXNpYy1xdWljLWhwYWNrL2RyYWZ0LWtyYXNpYy1xdWlj LWhwYWNrLTAwLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWtyYXNpYy1xdWljLWhwYWNrLTAw LnR4dDwvYT48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QXBvbG9naWVzIGluIGFkdmFuY2UsIHRoaXMgaXMgbXkgZmlyc3QgYXR0ZW1w dCBhdCBhbiBJRVRGIGRyYWZ0Ljx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDE1LCAyMDE3IGF0IDEwOjM3 IEFNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9h PiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI2NjY2NjYyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzIGZvciB0aGUgZmVlZGJhY2shPGJyPg0KPGJyPg0KWWVzLCB5b3UndmUg cnVuIHN0cmFpZ2h0IGludG8gdGhlIGJpZyBxdWFuZGFyeSB3aXRoIEhQQUNLLiZuYnNwOyBJIGRv bid0IHRoaW5rIGFueW9uZSBleHBlY3RzIHRoYXQgd2Ugd2lsbCBzaGlwIHRoaXMgd2F5OyBJIGhh dmUgYSBwcm9wb3NhbCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHI8d2JyPmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFj azwvYT4gZm9yIGFuIEhQQUNLLXJlcGxhY2VtZW50IHRoYXQgd291bGQgc29sdmUgbWFueSBvZiB0 aGVzZS4mbmJzcDsgQnVjayBLcmFzaWMgaGFzIGEgcHJvcG9zYWwgd2hpY2ggaGUgaGFzIHNrZXRj aGVkIGluIGUtbWFpbCBidXQgbm90IHN1Ym1pdHRlZCBhcyBhIGRyYWZ0LiZuYnNwOyBUaGUgbWFp biBwb2ludCBvZiB0aGUgc2VxdWVuY2UgbnVtYmVyIHdhcw0KIHRvIGdldCB1cyBvZmYgdGhlICZx dW90O2V2ZXJ5dGhpbmcgb24gc3RyZWFtIDMmcXVvdDsgbW9kZWwgYW5kIGxldCB1cyBzb3J0IG91 dCB0aGUgcHJvYmxlbXMgb2YgSFBBQ0sgbGF0ZXIuJm5ic3A7ICMyMjggdHJhY2tzIGZpeGluZyBI UEFDSywgaW4gd2hhdGV2ZXIgZm9ybSB0aGF0IHRha2VzLjxicj4NCjxicj4NCldlIGNvdWxkIHNv bHZlIGl0IGluIHRoZSBzYW1lIHdheSB0aGF0IHdlIGRpZCBQUklPUklUWSwgYnkgYWRkaW5nIGFu ICZxdW90O2FmZmVjdGVkIHN0cmVhbSBudW1iZXImcXVvdDsgZmllbGQgYW5kIG1vdmluZyB0aGUg SEVBREVSUy9QVVNIX1BST01JU0UgZnJhbWVzIHRvIFN0cmVhbSAzIGFzIHdlbGwuJm5ic3A7IEhv d2V2ZXIsIHRoYXQgaXMganVzdCBhcyBibG9ja2luZyBhcyB0aGUgY3VycmVudCBhcHByb2FjaCwg c28gbm90IHJlYWxseSBhbiBpbXByb3ZlbWVudC4mbmJzcDsgV29yc2UsDQogdGhlIHJlYXNvbiB3 ZSBjYW4gdG9sZXJhdGUgbGFyZ2UgaGVhZGVyIGZyYW1lcyBpcyBiZWNhdXNlIHRoZXkgb2NjdXIg b24gdGhlaXIgb3duIHN0cmVhbXMgYW5kIGRvbid0IGJsb2NrIGFycml2YWwgb2YgZGF0YSBmcm9t IG90aGVyIHN0cmVhbXMuJm5ic3A7IElmIGFsbCBoZWFkZXJzIG9jY3VyIG9uIGEgc2luZ2xlIHN0 cmVhbSwgdGhhdCdzIG5vdCB0cnVlIC0tIHlvdSAqYXJlKiBibG9ja2luZyBtdXhpbmcgb2Ygb3Ro ZXIgc3RyZWFtcyBhZ2Fpbi48YnI+DQo8YnI+DQpJIGxpa2UgdGhlIGNvbXBhcmlzb24gdG8gY29u Y3VycmVudCBlZGl0cy4mbmJzcDsgV2UndmUgZGlzY3Vzc2VkIGhhdmluZyByb2xsaW5nIGRlbHRh cyBpbiB2YXJpb3VzIG1lY2hhbmlzbXM7IHRoZSBwcm9ibGVtIGlzIHRoYXQgaXQgcmVxdWlyZXMg cmVhY2hpbmcgaW50byB0aGUgdHJhbnNwb3J0IGZvciBBQ0sgc3RhdGUgdG8gZmlndXJlIG91dCB3 aGVuIHlvdSBjYW4gZGlzY2FyZCBvbGQgZGVsdGFzIGZvciBnb29kIG9uIHRoZSByZWNlaXZlciBz aWRlLiZuYnNwOw0KIEJ1Y2sncyBwcm9wb3NhbCBpcyBzaW1pbGFyLCBlc3NlbnRpYWxseSByZXF1 aXJpbmcgdGhlIHJlY2VpdmVyIHRvIGVjaG8gYmFjayB0aGUgcG9pbnQgdXAgdG8gd2hpY2ggaXQg aGFzIHJlY2VpdmVkIGFsbCBmcmFtZXMsIGFuZCB0aGUgc2VuZGVyIHNob3VsZG4ndCByZWZlcmVu Y2Ugc3RhdGUgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzbid0IGZ1bGx5IGFzc2ltaWxhdGVkIHlldC4m bmJzcDsgSXQgZmVlbHMgbGlrZSBhZGRpbmcgYXBwbGljYXRpb24tbGV2ZWwgQUNLcw0KIHRvIG1l LCB3aGljaCBJJ2QgbGlrZSB0byBhdm9pZC48YnI+DQo8YnI+DQpIUEFDSyBpcyBhbHNvIG9uZSBv ZiB0aGUgcmVhc29ucyBmb3IgdGhlIHR3by1zdHJlYW0tcGVyLXJlcXVlc3QgYXBwcm9hY2guJm5i c3A7IFRoZXJlIGFyZSB0d28gcmVhc29ucyBmb3IgdGhpcyAtLSBvbmUgaXMgdGhhdCBIUEFDSyBm cmFtZXMgKGluIHRoZSBjdXJyZW50IGRlc2lnbikgY2FuJ3QgYmUgbG9zdCB3aGVuIGEgc3RyZWFt IGlzIFJTVCwgc28gdGhlIGRyYWZ0IGZvcmJpZHMgcmVzZXR0aW5nIGNvbnRyb2wgc3RyZWFtcy4m bmJzcDsgU2luY2Ugd2Ugc3RpbGwNCiBuZWVkIHRvIGJlIGFibGUgdG8gUlNUIHJlcXVlc3RzLCB3 ZSBhZGQgdGhlIHNlbWFudGljIHRoYXQga2lsbGluZyB0aGUgZGF0YSBzdHJlYW0gaW1wbGllcyB0 aGUgc2FtZSB0aGluZyBhYm91dCB0aGUgY29udHJvbCBzdHJlYW0uJm5ic3A7IEl0J3MgbWVzc3ks IGFuZCBob3BlZnVsbHkgd2UgY2FuIHJlbW92ZSB0aGF0IG9uY2UgSFBBQ0sgaXMgZml4ZWQuJm5i c3A7IFRoZSBzZWNvbmQsIGFzIHlvdSBndWVzc2VkLCBpcyBub3QgZGVhbGluZyB3aXRoIERBVEEg ZnJhbWVzLiZuYnNwOw0KICMyNDUgbm90ZXMgdGhhdCwgaWYgd2UgZml4IEhQQUNLLCB3ZSBjb3Vs ZCBnbyBiYWNrIHRvIGEgc2luZ2xlIHN0cmVhbSBwZXIgcmVxdWVzdDsgcHJvcG9uZW50cyBvZiBi b3RoICZxdW90O2tlZXAgZnJhbWluZyBvdXQgb2YgdGhlIHdheSZxdW90OyBhbmQgJnF1b3Q7ZmV3 ZXIgc3RyZWFtcyBpcyBlYXNpZXIgdG8gbWFuYWdlJnF1b3Q7IGhhdmUgd2VpZ2hlZCBpbiB0aGVy ZS4mbmJzcDsgUGxlYXNlIGFkZCB5b3VyIHZvaWNlLjxicj4NCjxicj4NCkFzIHRvIGJ1ZmZlcmlu ZywgaXQncyBhY3R1YWxseSBlYXN5IGVub3VnaCAtLSBqdXN0IGRvbid0IHJlYWQgZnJvbSBkYXRh IHN0cmVhbXMgdW50aWwgeW91J3ZlIHNlZW4gdGhlIGhlYWRlcnMuJm5ic3A7IFN1cmUsIHRoZSBz ZW5kZXIgd2lsbCBmaWxsIHVwIHRoZWlyIGZsb3cgY29udHJvbCB3aW5kb3cgb24gdGhhdCBzdHJl YW0gLS0gYW5kIHRoZW4gdGhleSdsbCBzdG9wIGFuZCBzZW5kIHlvdSBRVUlDIEJMT0NLRUQgZnJh bWVzLCB1bnRpbCB5b3Ugc3RhcnQNCiByZWFkaW5nIHRoZSBib2R5IGFuZCBnZW5lcmF0aW5nIFdJ TkRPV19VUERBVEUgZnJhbWVzLiZuYnNwOyBPbmUgb2YgdGhlIGJpZ2dlc3QgYXJndW1lbnRzIGZv ciB0d28gc3RyZWFtcyBpbiBteSBtaW5kIGlzIG1ha2luZyBzdXJlIHRoYXQgYSByZXF1ZXN0IGJs b2NrZWQgaW4gdGhpcyB3YXkgZG9lc24ndCBpbXBlZGUgdGhlIGZsb3cgb2YgY29udHJvbCBmcmFt ZXMgb24gdGhhdCBzdHJlYW0gLS0gZm9yIGV4YW1wbGUsIHNob3VsZCB3ZSBzdWNjZXNzZnVsbHkN CiBnZXQgY2VydGlmaWNhdGUgYXV0aCBmcmFtZXMgYWRkZWQsIGEgY2VydGlmaWNhdGUgcmVxdWVz dC4mbmJzcDsgSSd2ZSBoYWQgdHdvIGN1c3RvbWVycyB0aGlzIHdlZWsgdGVsbGluZyBtZSBpdCdz IGEgYnVnIGluIG91ciBzZXJ2ZXIgY29kZSB0aGF0IHRoZWlyIFRMUyByZW5lZyBnZXRzIHN0dWNr IGluIFRDUCBidWZmZXJzIGJlaGluZCBhIGdpYW50IHJlcXVlc3QgYm9keSwgYmVjYXVzZSB0aGUg c2VydmVyIHdvbid0IHJlYWQgYW4gdW5hdXRoZW50aWNhdGVkDQogYm9keSBhbmQgdGhlIGNsaWVu dCB3b24ndCBob2xkIG9mZiBzZW5kaW5nIHRoZSBib2R5IHVudGlsIGF1dGhlbnRpY2F0aW9uIHN1 Y2NlZWRzLiZuYnNwOyBJJ2QgbGlrZSB0byBzZWUgYmxvY2tzIGxpa2UgdGhhdCBiZWNvbWUgbGVz cyBwb3NzaWJsZSBpbiBRVUlDLCBhdCBsZWFzdC48YnI+DQo8YnI+DQpZZXMsIG1ha2luZyBTRVRU SU5HUyBpbW11dGFibGUgcmVkdWNlcyB0aGUgZmxleGliaWxpdHkuJm5ic3A7IFRoZSBvcGluaW9u IGF0IHRoZSBpbnRlcmltIHdhcyB0aGF0IHdlIGNvdWxkIGxpdmUgd2l0aG91dCBpdCwgYXMgd2Ug a25vdyBvZiBleGFjdGx5IG9uZSBpbXBsZW1lbnRhdGlvbiBvZiBvbmUgZXh0ZW5zaW9uIHRoYXQg ZG9lcyBtaWQtc3RyZWFtIHNldHRpbmcgY2hhbmdlcywgYW5kIEkgb3duIGl0LiZuYnNwOw0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2Vy aWYiPvCfmIo8L3NwYW4+Jm5ic3A7IElmIHRoZXJlJ3MgYSBjb21wZWxsaW5nIHVzZSBjYXNlIGZv ciBjaGFuZ2luZyBzZXR0aW5ncyBtaWQtc3RyZWFtIHdlIHdlcmVuJ3QgYXdhcmUgb2YsIHRoYXQn cyBuZXcgaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBqdXN0aWZ5IHRoZSBjb21wbGV4aXR5LiZuYnNw OyAoQnV0IG5vdGUgdGhhdCB3aXRoIDAtUlRUIGNvbm5lY3Rpb24gc2V0dXAsIGl0DQogd291bGQg YmUgbmVhcmx5IGFzIGNoZWFwIHRvIG9wZW4gYSBuZXcgY29ubmVjdGlvbiB3aXRoIHRoZSBuZXcg c2V0dGluZyBhbmQgdHJhbnNpdGlvbiB5b3VyIHRyYWZmaWMgdG8gaXQuKTxicj4NCjxicj4NCk5l Z290aWF0aW9uIHN0aWxsIHdvcmtzLCBzaW5jZSBlYWNoIHNpZGUgd291bGQgc2ltcGx5IGFkdmVy dGlzZSB0aGF0IHRoZXkgc3VwcG9ydCBhbiBleHRlbnNpb24gb3Igbm90LCBhbmQgY29uc2lkZXIg dGhlIGV4dGVuc2lvbiB0byBiZSBhY3RpdmUgb25jZSB5b3UndmUgc2VlbiB0aGUgb3RoZXIgc2lk ZSdzIFNFVFRJTkdTIGZyYW1lLiZuYnNwOyBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0wMSNzZWN0aW9uLTUuMi41LjMiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcjx3YnI+YWZ0LWlldGYt cXVpYy1odHRwLTAxI3NlY3Rpb24tPHdicj41LjIuNS4zPC9hPiBmb3IgdGhlIGNvbXBsZXhpdHkg dGhpcyBhbGxvd2VkIHVzIHRvIHJlbW92ZS4mbmJzcDsgQW4gZXh0ZW5zaW9uIGNvdWxkIGFkZCB0 byB0aGUgbGlzdCBlYXNpbHkgLS0gaWYgeW91IHN1cHBvcnQgZXh0ZW5zaW9uIFgsIHlvdSBzaG91 bGQgYWxzbyByZW1lbWJlciB0aGUgdmFsdWUgZm9yIHNldHRpbmcgWF9WQUwuJm5ic3A7DQogQ2xp ZW50cyB0aGF0IGRvbid0IHVzZSB0aGUgZXh0ZW5zaW9uIGRvbid0IGNhcmUuJm5ic3A7IEFuIGV4 dGVuc2lvbiB0aGF0IG5lZWRlZCBzb21lIG1vcmUgY29tcGxleCBuZWdvdGlhdGlvbiB3b3VsZCBo YXZlIHRvIHVzZSBhbiBleHRlbnNpb24tc3BlY2lmaWMgZnJhbWUsIGl0J3MgdHJ1ZSwgYnV0IHdl IGhhdmVuJ3Qgc28gZmFyIHNlZW4gYW4gZXh0ZW5zaW9uIGRvIHRoYXQuPGJyPg0KPGJyPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBRVUlDIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTdGVmYW4gRWlzc2luZzxicj4NClNlbnQ6IFdl ZG5lc2RheSwgTWFyY2ggMTUsIDIwMTcgNjoyMiBBTTxicj4NClRvOiBNYXJ0aW4gVGhvbXNvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IENvcmUgZHJhZnRzIC0wMiBvdXQ8YnI+DQo8YnI+ DQo8YnI+DQomZ3Q7IEFtIDE0LjAzLjIwMTcgdW0gMDA6NTcgc2NocmllYiBNYXJ0aW4gVGhvbXNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDs8YnI+DQom Z3Q7IFRoZSBlZGl0b3JzIGhhdmUgc3VibWl0dGVkIC0wMiB2ZXJzaW9ucyBvZiB0aGUgYmFzZSBz ZXQgb2YgUVVJQyBkcmFmdHMuPGJyPg0KWy4uLl08YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtaHR0cC0wMiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcjx3YnI+YWZ0LWlldGYtcXVpYy1odHRw LTAyPC9hPjxicj4NCjxicj4NClRoYW5rcywgTWFydGluISBJIGFzc3VtZSB0aGF0IHdhcyBhbm5v dW5jZWQgdG8gZ2V0IGZlZWRiYWNrIGZyb20gdGhlIGx1cmtlcnMgaGVyZS4gOy0pPGJyPg0KPGJy Pg0KSSdsbCBnaXZlIHRoaXMgYSB0cnkuIEFsbCBtaXN0YWtlcyBhbmQgbWlzdW5kZXJzdGFuZGlu Z3MgYXJlIG1pbmUgYWxvbmUuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPHdicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVmVyeSB3ZWxsIHdyaXR0ZW4gc3BlYy4gRWFzeSB0 byB1bmRlcnN0YW5kIGZvciBzb21lb25lIGhhdmluZyByZWFkIHJmYyA3NTQwIGEgYml0Ljxicj4N Cjxicj4NCkkgaGF2ZSBzb21lIGNvbW1lbnRzIHRvIHRoZSBwcm9wb3NlZCBIVFRQIG1hcHBpbmcg YXBwcm9hY2guIFdoZXJlIHRoZSB3ZyBoYXMgYWxyZWFkeSBkaXNjdXNzZWQgYW5kIGV4aGF1c3Rl ZCBhbHRlcm5hdGl2ZXMsIHBsZWFzZSBleGN1c2UgbXkgaWdub3JhbmNlIGFuZCBpZ25vcmUgbXkg Y29tbWVudHMuIEkgaGFkIG5vdCB0aGUgdGltZSB0byBmb2xsb3cgYWxsIGRpc2N1c3Npb25zIG9u Z29pbmcgb24gdGhpcyB0b3BpYy4gRmVlbCBmcmVlIHRvIGNoZXJyeS1waWNrDQogd2hhdCBzZWVt cyBoZWxwZnVsLjxicj4NCjxicj4NCjxicj4NCiZndDsgNC4mbmJzcDsgU3RyZWFtIE1hcHBpbmcg YW5kIFVzYWdlPGJyPg0KPGJyPg0KJiM0MzsxIHRvIGRpcmVjdGx5IHVzaW5nIHF1aWMgc3RyZWFt IGlkcyBpbnN0ZWFkIG9mIHZpcnR1YWwgaDIgc3RyZWFtPGJyPg0KJiM0MztpZGVudGlmaWVyPHU+ PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSG93ZXZlciwgdXNpbmcgMiBxdWljIHN0cmVh bXMgZm9yIGEgc2luZ2xlIHJlcXVlc3QvcmVzcG9uc2UgZG9lcyBub3Qgc2l0IHdlbGwgd2l0aCBt ZS4gSSBhc3N1bWUgdGhhdCBzdGVtcyBmcm9tIHRoZSB3aXNoIHRvIGdldCByaWQgb2YgREFUQSBm cmFtZXMuIFdoaWNoIHNvdW5kcyBuaWNlLCBidXQgaXMgaXQgd29ydGggaXQ/IEJ5IGRvdWJsaW5n IHRoZSAjIG9mIHN0cmVhbXMgZm9yIGEgY2xpZW50LCBob3cgbXVjaCBvdmVyaGVhZCBkb2VzIHRo YXQNCiBpbnRyb2R1Y2UgKEkgc3BlYWsgb2YgYSBzZXJ2ZXIgaG9sZGluZyAmZ3Q7MTBrIHF1aWMg JnF1b3Q7Y29ubmVjdGlvbnMmcXVvdDspPzxicj4NCjxicj4NCkFsc28sIHRoZSBzZXJ2ZXIgbmVl ZHMgdG8gYnVmZmVyIGRhdGEgb24gcXVpYyBzdHJlYW1zIDcsIDExLCAxNSwgZXRjLiBiZWNhdXNl IEhFQURFUnMgbWlnaHQgYXJyaXZlIHNvbWUgdGltZSBpbiB0aGUgZnV0dXJlIG9uIHN0cmVhbXMg NSwgOSwgMTMsIGV0Yy4gb3Igbm90LiBUaGVyZSBpcyBubyB3YXkgdG8gcm91dGUgdGhpcyBkYXRh IHNvbWV3aGVyZSwgYmVjYXVzZSB0aGUgbWV0YSBpbmZvcm1hdGlvbiBpcyBzdGlsbCBtaXNzaW5n Ljxicj4NCjxicj4NCkFuZCB0aGVyZSBpcyBzdGlsbCBIb2xiIG9uOjxicj4NCjxicj4NCiZndDsg NC4yLjEuJm5ic3A7IEhlYWRlciBDb21wcmVzc2lvbjxicj4NCiZndDsgLi4uPGJyPg0KJmd0OyBE SVNDVVNTOiZuYnNwOyBLZWVwIEhQQUNLIHdpdGggSE9MQj8mbmJzcDsgUmVkZXNpZ24gSFBBQ0sg dG8gYmUgb3JkZXItPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ludmFyaWFu dD8mbmJzcDsgSG93IG11Y2ggZG8gd2UgbmVlZCB0byByZXRhaW4gY29tcGF0aWJpbGl0eSB3aXRo PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hUVFAvMidzIEhQQUNLPzxicj4N Cjxicj4NClVzaW5nIGEgY291bnRlciBpbiBIRUFERVJTIGlzIGEgY3J1dGNoOjxicj4NCi0gaXQg aXMgYSBoaWdobHkgc3BlY2lmaWMgc29sdXRpb24gdG8gYSBjb21tb24gcHJvYmxlbSBpbiBodHRw L3F1aWM6IHN5bmNocm9uaWNpdHkgaW4gY29ubmVjdGlvbiBsZXZlbCBzdGF0ZSBjaGFuZ2VzLiBT RVRUSU5HUyAoc2VlIGJlbG93KSBoYXMgdGhlIHNhbWUgcHJvYmxlbSwgYXMgZG9lcyBoYXZlIFBS SU9SSVRZIGluIEhFQURFUlMuIEl0IHNlZW1zIHRoYXQgcGVyZm9ybWFuY2Ugd2lzZSwgYWxsIEhF QURFUlMgY291bGQgYXMgd2VsbCBiZSBzZW50DQogb24gc3RyZWFtIDMuPGJyPg0KPGJyPg0KTm93 LCBzb2x2aW5nIEhvbCBibG9ja2luZyBmb3IgSEVBREVSUyB3b3VsZCBiZSBhIGZpbmUgYWNoaWV2 ZW1lbnQuPGJyPg0KPGJyPg0KJmd0OyA1LiZuYnNwOyBIVFRQIEZyYW1pbmcgTGF5ZXI8YnI+DQom Z3Q7IEZyYW1lcyBhcmUgdXNlZCBvbmx5IG9uIHRoZSBjb25uZWN0aW9uIChzdHJlYW0gMykgYW5k IG1lc3NhZ2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAoc3RyZWFtcyA1LCA5LCBldGMuKSBjb250 cm9sIHN0cmVhbXMuPGJyPg0KPGJyPg0KQW5kIHN0cmVhbXMgNCwgOCwgMTIsIGV0Yy4gSSBhc3N1 bWUuPGJyPg0KPGJyPg0KJmd0OyA1LjIuMy4mbmJzcDsgU0VUVElOR1M8YnI+DQomZ3Q7IC4uLjxi cj4NCiZndDsgU0VUVElOR1MgZnJhbWVzIGFsd2F5cyBhcHBseSB0byBhIGNvbm5lY3Rpb24sIG5l dmVyIGEgc2luZ2xlIHN0cmVhbS48YnI+DQomZ3Q7Jm5ic3A7IEEgU0VUVElOR1MgZnJhbWUgTVVT VCBiZSBzZW50IGFzIHRoZSBmaXJzdCBmcmFtZSBvZiB0aGUgY29ubmVjdGlvbjxicj4NCiZndDsg Y29udHJvbCBzdHJlYW0gKHNlZSBTZWN0aW9uIDQpIGJ5IGVhY2ggcGVlciwgYW5kIE1VU1QgTk9U IGJlIHNlbnQ8YnI+DQomZ3Q7IHN1YnNlcXVlbnRseSBvciBvbiBhbnkgb3RoZXIgc3RyZWFtLiZu YnNwOyBJZiBhbiBlbmRwb2ludCByZWNlaXZlcyBhbjxicj4NCiZndDsgU0VUVElOR1MgZnJhbWUg b24gYSBkaWZmZXJlbnQgc3RyZWFtLCB0aGUgZW5kcG9pbnQgTVVTVCByZXNwb25kIHdpdGg8YnI+ DQomZ3Q7IGEgY29ubmVjdGlvbiBlcnJvciBvZiB0eXBlIEhUVFBfU0VUVElOR1NfT05fV1JPTkdf U1RSRUFNLjx3YnI+Jm5ic3A7IElmIGFuPGJyPg0KJmd0OyBlbmRwb2ludCByZWNlaXZlcyBhIHNl Y29uZCBTRVRUSU5HUyBmcmFtZSwgdGhlIGVuZHBvaW50IE1VU1QgcmVzcG9uZDxicj4NCiZndDsg d2l0aCBhIGNvbm5lY3Rpb24gZXJyb3Igb2YgdHlwZSBIVFRQX01VTFRJUExFX1NFVFRJTkdTLjxi cj4NCjxicj4NCldoYXQgYWJvdXQgSFBBQ0sgc3RhdGU/IFRoZSBjb25uZWN0aW9uIHN0YXRlIGNo YW5nZSBwcm9ibGVtIGFnYWluIHZpc2libGUuPGJyPg0KPGJyPg0KVGhpcyBpcyBhIHNldmVyZSBy ZXN0cmljdGlvbiBvbiBleHRlbnNpb25zIG1lY2hhbmlzbXMgdGhhdCB3YW50IHRvIGFmZmVjdCBh IGNvbm5lY3Rpb24uIEJlY2F1c2UgaWYgdGhlIGh0dHAvcXVpYyBkb2VzIG5vdCBzb2x2ZSB0aGlz IHByb2JsZW0sIGhvdyBhcmUgdGhleSBleHBlY3RlZCB0byBkbyBpdD8gVGhleSBlaXRoZXIgYW5u b3VuY2UgdGhlbXNlbHZlcyBvbiB0aGUgZmlyc3QgU0VUVElOR1Mgb3IgcmVtYWluIHNpbGVudCBm b3JldmVyLCBpdA0KIHNlZW1zLiBIb3cgd291bGQgYW4gZXh0ZW5zaW9uIGhhbmRzaGFrZSB3b3Jr IHRoZW4/IE93biBzdHJlYW0gMyBoYW5kc2hha2UgZnJhbWVzPzxicj4NCjxicj4NCiZndDsgNS4y LjMuMy4mbmJzcDsgVXNhZ2UgaW4gMC1SVFQ8YnI+DQo8YnI+DQpXaGF0IGFib3V0IEhQQUNLIHN0 YXRlPyBEb2VzIGl0IG5lZWQgdG8gYmUga2VwdCBvciBpcyBpdCByZXNldD88YnI+DQo8YnI+DQom Z3Q7IEhUVFBfUFVTSF9BTFJFQURZX0lOX0NBQ0hFICgweDAzKTombmJzcDsgVGhlIHNlcnZlciBo YXMgYXR0ZW1wdGVkIHRvIHB1c2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY29udGVu dCB3aGljaCB0aGUgY2xpZW50IGhhcyBjYWNoZWQuPGJyPg0KJmd0OyAuLi48YnI+DQomZ3Q7IEhU VFBfUkVRVUVTVF9DQU5DRUxMRUQgKDB4MDQpOiZuYnNwOyBUaGUgY2xpZW50IG5vIGxvbmdlciBu ZWVkcyB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1ZXN0ZWQgZGF0YS48YnI+ DQo8YnI+DQpOaXRwaWNrOiBzZWVtcyByZWR1bmRhbnQuIFRoZSBmaXJzdCBjb3VsZCBiZSByZXBs YWNlZCBieSB0aGUgc2Vjb25kLiBTdHJlYW0gbnVtYmVyIHdpbGwgc3VmZmljZS48YnI+DQo8YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQo8YnI+DQpUYWtpbmcgdHdvIHN0ZXBzIGJhY2s6PGJyPg0KPGJyPg0KSSB0 aGluayB0aGUgbWFpbiBkaWZmaWN1bHR5IGNvbWVzIGZyb20gdGhlIGxhY2sgb2YgYSAmcXVvdDto cSBjb25uZWN0aW9uIHN0YXRlJnF1b3Q7IGNvbmNlcHQgYW5kIGhvdyBjaGFuZ2VzIHRvIHRoYXQg c3RhdGUgY2FuIGJlIG1hbmFnZWQuIEV2aWRlbmNlOjxicj4NCi0gVGhlIDAtUlRUIG1lbnRpb25z IGNlcnRhaW4gU0VUVElOR1MgdGhhdCBuZWVkIHRvIGJlIHJlbWVtYmVyZWQgYnkgYSBjbGllbnQu IEhvdyB3b3VsZCBhbiBleHRlbnNpb24gYWRkIHRvIHRoaXM/IFdpbGwgZXZlcnkgZXh0ZW5zaW9u IGhhdmUgdG8gY29tZSB1cCB3aXRoIGl0cyBvd24gc29sdXRpb24/PGJyPg0KLSBUaGUgSEVBREVS cyBzZXF1ZW5jZSBudW1iZXIgaXMgYSBoaWdobHkgc3BlY2lmaWMgZml4IGZvciB0aGUgbWlzc2lu ZyBzdGF0ZSBjaGFuZ2U8YnI+DQotIFRoZSBTRVRUSU5HUy1PTkNFIHJlc3RyaWN0aW9uIHNpbXBs eSBhdm9pZHMgdGhlIHByb2JsZW0gYnkga2lsbGluZyBhIGgyIG1lY2hhbmlzbTxicj4NCjxicj4N CklmIGhxIGRlZmluZXMgc3RyZWFtIDMgYXMgdGhlIHBsYWNlIHdoZXJlIGNvbm5lY3Rpb24gc3Rh dGUgY2hhbmdlcyBoYXBwZW4gKkFORCogc3luY2hyb25pemVzIE9QRU4vQ0xPU0UvUlNUIG9mIG90 aGVyIHN0cmVhbXMgb24gaXQsIGNsaWVudCBhbmQgc2VydmVyIGNhbiBoYXZlIHNoYXJlYWJsZSBj b25jZXB0IG9mIHRoZSBjb25uZWN0aW9uIHN0YXRlLjxicj4NCjxicj4NCjxicj4NCkkgYW0gbm8g SFBBQ0sgZXhwZXJ0LiBUaGUgYmFzaWMgcHJvYmxlbSBsb29rcyBsaWtlIGNvbmN1cnJlbnQgZWRp dGluZyBhZ2FpbnN0IGEgcmVwb3NpdG9yeS48YnI+DQpCb3RoIGNsaWVudCBhbmQgc2VydmVyIHN0 YXJ0IHdpdGggY29ubmVjdGlvbiBzdGF0ZSB6ZXJvIChDUy0wKSBhbmQgdGhlIHByZWRlZmluZWQg SFBBQ0sgZGljdGlvbmFyeSAoSFAtMCkuIEFmdGVyIFNFVFRJTkdTIGV4Y2hhbmdlLCBjbGllbnQg aXMgaW4gQ1MtMSBhbmQgc2VydmVyIGlzIGluIENTLTIgZm9yIGl0cyBzaWRlLiBMZXQncyBjYWxs IHRoZSZuYnNwOyBDUy0xIEhQQUNLIHN0YXRlIEhQLTEuPGJyPg0KPGJyPg0KQ2xpZW50IHNlbmRz IG5ldyBIRUFERVJTIG9uIDUgYW5kIGtlZXBzIHRoZSBIUEFDSyBkZWx0YSBhcm91bmQgKEhQLTEu NSkuIFRoZSBIRUFERVJTIGNhcnJpZXMgdGhlIGNvbm5lY3Rpb24gc3RhdGUgbnVtYmVyIGl0IGlz IGJhc2VkIG9uIChDUy0xKS4gQ2xpZW50IHNlbmRzIG5ldyBIRUFERVJTIG9uIHN0cmVhbSA5LCBh bHNvIGJhc2VkIG9uIENTLTEuIENsaWVudCBrZWVwcyB0aGF0IGRlbHRhIGFyb3VuZCAoSFAtMS45 KS48YnI+DQo8YnI+DQpDbGllbnQgdGhlbiBkZWNpZGVzIHRvIGFubm91bmNlIGEgbmV3IGNvbm5l Y3Rpb24gc3RhdGUgKENTLTMpIGJ5IHNlbmRpbmcgaG93IGl0IGFwcGxpZWQgdGhlIGRlbHRhcyBI UC0xLjUgYW5kIEhQLTEuOSB0byBjb21lIHVwIHdpdGggSFAtMy4gVGhlIGRlc2NyaXB0aW9uIGFs bG93cyB0aGUgc2VydmVyIHRvIHVwZGF0ZSBpdHMgSFAtMSB0byBIUC0zIGFzIHdlbGwuPGJyPg0K PGJyPg0KUmVzcG9uc2UgSEVBREVSUyBhcmUgYWxzbyBiYXNlZCBvbiBhIHNlcnZlciBjb25uZWN0 aW9uIHN0YXRlLCBleHBsaWNpdGx5LCBzbyB0aGUgY2xpZW50IGtub3dzIHdoaWNoIEhQLVggdG8g dXNlIHdoZW4gZGVjb2RpbmcgdGhlbS4gQXQgc29tZSB0aW1lLCB0aGUgc2VydmVyIHNlbmRzIGFu IGFubm91bmNtZW50IG9mIENTLTQgd2l0aCBIUEFDSyBkYXRhIG9uIHN0cmVhbSAzIGJhY2sgdG8g dGhlIGNsaWVudC48YnI+DQo8YnI+DQpGb3IgYSAwLVJUVCwgY2xpZW50IGFuZCBzZXJ2ZXIgY291 bGQgZXhjaGFuZ2UgdGhlIGNvbm5lY3Rpb24gc3RhdGUgaWQgaW4gdGhlIGluaXRpYWwgU0VUVElO R1MsIHRvIG1ha2Ugc3VyZSB0aGV5IGhhdmUgYXQgbGVhc3QgdGhlIHNhbWUgbmFtZSByZW1lbWJl cmVkIGFzIHRoZSBvdGhlciBzaWRlLiBDbGllbnQ6ICZxdW90O0kgd2FzIGluIENTLTE5IGFuZCB5 b3Ugd2VyZSBpbiBDUy04LiZxdW90OyBTZXJ2ZXI6ICZxdW90O1llcC4mcXVvdDs8YnI+DQo8YnI+ DQpCeSBpbXBsaWNpdGx5IGFkZGluZyBhbGwgU0VUVElOR1MgY2hhbmdlcyB0byBjb25uZWN0aW9u IHN0YXRlcywgdGhlIHByb2JsZW0gaXMgYWxzbyBzb2x2ZWQgZm9yIGV4dGVuc2lvbnMuPGJyPg0K PGJyPg0KSWYgb25lIHNpZGUgcmVjZWl2ZXMgSEVBREVSUyB3aXRoIGFuIHVua25vd24gY29ubmVj dGlvbiBzdGF0ZTo8YnI+DQotIGlmIHRoZSBzdGF0ZSBpZCBpcyBncmVhdGVyIHRoYW4gYW55IGtu b3duIG9uZTogc2V0IGEgc3RyZWFtIHRpbWVvdXQgYW5kIHdhaXQgZm9yIGNoYW5nZXMgb24gc3Ry ZWFtIDMgdG8gYXJyaXZlPGJyPg0KLSBzdGF0ZSBpZCBsZXNzIHRoYW4gbWF4KGtub3duIGNvbm4g c3RhdGUpOiBTVFJFQU1fUlNUX1VOS05PV05fQ09OTl9TVEFURTxicj4NCjxicj4NCk5ldyBTRVRU SU5HUyB2YWx1ZTogTUFYX0NPTk5fU1RBVEUgbnVtYmVyIG9mIG1heGltdW0gY29ubmVjdGlvbiBz dGF0ZSB0aGUgY2xpZW50L3NlcnZlciBpcyB3aWxsaW5nIHRvIGtlZXAsIGV4Y2hhbmdlZCBpbml0 aWFsbHkuIEFubm91bmNpbmcgYSBuZXcgY29ubmVjdGlvbiBzdGF0ZSBhbGxvd3MgdGhlIG90aGVy IHNpZGUgdG8gZHJvcCB0aGUgbG93ZXN0IG9uZSwgaWYgTUFYX0NPTk5fU1RBVEUgYXJlIHVzZWQu PGJyPg0KPGJyPg0KVG8gZ2V0IG9wdGltYWwgSFBBQ0sgc2l6ZSBjb21wcmVzc2lvbiwgZXZlcnkg SEVBREVScyB3b3VsZCBhbHNvIGFubm91bmNlIGEgbmV3IGNvbm5lY3Rpb25zIHN0YXRlLiBUbyBo YXZlIGxlc3MgcG90ZW50aWFsIEhPTEIsIGNvbm5lY3Rpb24gc3RhdGVzIGRvIG5vdCBjaGFuZ2Ug ZHVyaW5nIHJlcXVlc3QgYnVyc3RzLjxicj4NCjxicj4NClNvbWV0aGluZyBsaWtlIHRoYXQuPGJy Pg0KPGJyPg0KLVN0ZWZhbjxicj4NCjxicj4NCjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyIGNsZWFyPSJhbGwiPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1 O2JvcmRlcjpzb2xpZCAjZDUwZjI1IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPkNoYXJsZXMgJ0J1Y2sn IEtyYXNpYyZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpz b2xpZCAjMzM2OWU4IDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwO1NvZnR3YXJlDQogRW5naW5l ZXImbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQg IzAwOTkzOSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86Y2tyYXNp Y0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2tyYXNpY0Bnb29nbGUuY29tPC9hPiZuYnNw Ozx3YnI+fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNl ZWIyMTEgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7JiM0MzsxDQo8YSBocmVmPSJ0ZWw6KDQw OCklMjA0MTItMTE0MSIgdmFsdWU9IiYjNDM7MTQwODQxMjExNDEiIHRhcmdldD0iX2JsYW5rIj4o NDA4KSA0MTItMTE0MTwvYT48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQo8ZGl2 IGNsYXNzPSJtXy0yOTg1NTU1NDc4NDU0MjcwMjkybV8tMTc1MDU4NTc0MDQzNTgyOTI2OGdtYWls X3NpZ25hdHVyZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbic7Zm9udC1zaXplOm1lZGl1bSI+PHNwYW4g c3R5bGU9ImNvbG9yOnJnYig4NSw4NSw4NSk7Zm9udC1mYW1pbHk6c2Fucy1zZXJpZjtsaW5lLWhl aWdodDoyMHB4O2ZvbnQtc2l6ZTpzbWFsbCI+PHNwYW4gc3R5bGU9ImJvcmRlci10b3Atd2lkdGg6 MnB4O2JvcmRlci1yaWdodC13aWR0aDowcHg7Ym9yZGVyLWJvdHRvbS13aWR0aDowcHg7Ym9yZGVy LWxlZnQtd2lkdGg6MHB4O2JvcmRlci10b3Atc3R5bGU6c29saWQ7Ym9yZGVyLXJpZ2h0LXN0eWxl OnNvbGlkO2JvcmRlci1ib3R0b20tc3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7 Ym9yZGVyLXRvcC1jb2xvcjpyZ2IoMjEzLDE1LDM3KTtib3JkZXItcmlnaHQtY29sb3I6cmdiKDIx MywxNSwzNyk7Ym9yZGVyLWJvdHRvbS1jb2xvcjpyZ2IoMjEzLDE1LDM3KTtib3JkZXItbGVmdC1j b2xvcjpyZ2IoMjEzLDE1LDM3KTtwYWRkaW5nLXRvcDoycHg7bWFyZ2luLXRvcDoycHgiPkNoYXJs ZXMNCiAnQnVjaycgS3Jhc2ljJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iYm9yZGVyLXRvcC13 aWR0aDoycHg7Ym9yZGVyLXJpZ2h0LXdpZHRoOjBweDtib3JkZXItYm90dG9tLXdpZHRoOjBweDti b3JkZXItbGVmdC13aWR0aDowcHg7Ym9yZGVyLXRvcC1zdHlsZTpzb2xpZDtib3JkZXItcmlnaHQt c3R5bGU6c29saWQ7Ym9yZGVyLWJvdHRvbS1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1zdHlsZTpz b2xpZDtib3JkZXItdG9wLWNvbG9yOnJnYig1MSwxMDUsMjMyKTtib3JkZXItcmlnaHQtY29sb3I6 cmdiKDUxLDEwNSwyMzIpO2JvcmRlci1ib3R0b20tY29sb3I6cmdiKDUxLDEwNSwyMzIpO2JvcmRl ci1sZWZ0LWNvbG9yOnJnYig1MSwxMDUsMjMyKTtwYWRkaW5nLXRvcDoycHg7bWFyZ2luLXRvcDoy cHgiPiZuYnNwO1NvZnR3YXJlDQogRW5naW5lZXImbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJi b3JkZXItdG9wLXdpZHRoOjJweDtib3JkZXItcmlnaHQtd2lkdGg6MHB4O2JvcmRlci1ib3R0b20t d2lkdGg6MHB4O2JvcmRlci1sZWZ0LXdpZHRoOjBweDtib3JkZXItdG9wLXN0eWxlOnNvbGlkO2Jv cmRlci1yaWdodC1zdHlsZTpzb2xpZDtib3JkZXItYm90dG9tLXN0eWxlOnNvbGlkO2JvcmRlci1s ZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci10b3AtY29sb3I6cmdiKDAsMTUzLDU3KTtib3JkZXItcmln aHQtY29sb3I6cmdiKDAsMTUzLDU3KTtib3JkZXItYm90dG9tLWNvbG9yOnJnYigwLDE1Myw1Nyk7 Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDAsMTUzLDU3KTtwYWRkaW5nLXRvcDoycHg7bWFyZ2luLXRv cDoycHgiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5ja3Jhc2ljQGdvb2dsZS5jb208L2E+Jm5ic3A7PHdicj58PC9zcGFuPjxzcGFuIHN0 eWxlPSJib3JkZXItdG9wLXdpZHRoOjJweDtib3JkZXItcmlnaHQtd2lkdGg6MHB4O2JvcmRlci1i b3R0b20td2lkdGg6MHB4O2JvcmRlci1sZWZ0LXdpZHRoOjBweDtib3JkZXItdG9wLXN0eWxlOnNv bGlkO2JvcmRlci1yaWdodC1zdHlsZTpzb2xpZDtib3JkZXItYm90dG9tLXN0eWxlOnNvbGlkO2Jv cmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci10b3AtY29sb3I6cmdiKDIzOCwxNzgsMTcpO2Jv cmRlci1yaWdodC1jb2xvcjpyZ2IoMjM4LDE3OCwxNyk7Ym9yZGVyLWJvdHRvbS1jb2xvcjpyZ2Io MjM4LDE3OCwxNyk7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIzOCwxNzgsMTcpO3BhZGRpbmctdG9w OjJweDttYXJnaW4tdG9wOjJweCI+Jm5ic3A7PHNwYW4gdGl0bGU9IkNhbGwgd2l0aCBHb29nbGUg Vm9pY2UiPjxhIGhyZWY9InRlbDooNDA4KSUyMDQxMi0xMTQxIiB2YWx1ZT0iJiM0MzsxNDA4NDEy MTE0MSIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7MQ0KICg0MDgpIDQxMi0xMTQxPC9hPjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjxicj4NCjxicj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB27084E9ADE721FFF85980DEF873F0BN6PR03MB2708namp_-- From nobody Thu Mar 23 17:18:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09D2129851 for ; Thu, 23 Mar 2017 17:18:36 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tsqPZNT-5sZq for ; Thu, 23 Mar 2017 17:18:32 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663D2128BE1 for ; Thu, 23 Mar 2017 17:18:32 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id y18so3526424itc.1 for ; Thu, 23 Mar 2017 17:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QnW+nf+GHtARk5UpVJv5zr6oykagX3t+0EmDfl9OfPg=; b=FDcWtbTwiV49+evUp+DT6zqpUCxNM63JSBAaQV49Bz4WDPZnqeMfXCTx1uvu5EGf6a RW1R36gqOWyHZ2EviFsCJqn+MdXz4LDOW37B1KsPb3/67RS19G6TwsiYau3U4Kw5yWCG rZbZDrwSyp+ecAk6u+VY+9pPwYVr9XVm71lJq9H/yR+y9JgURyYFabGi6YFOKxmhltVd STq+zsTJ688k9fzMHFEYrWN9CfzDBcEQO4xOL2mR/PbM6Nu7qC1YBzdY62P0DI53JjVv rCw9rlfJ/84g53IpqOpF9q45eVxxTPN+qXZ9NavVCyKojFZNFbWqrFR8A3HSQ2INQMGs v0Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QnW+nf+GHtARk5UpVJv5zr6oykagX3t+0EmDfl9OfPg=; b=LZoirLs0BHaZfU/XPUYxuAUm7cMFBPi8u0fX7N8M/w3qw8jmEOphltIm+8kzCvWr4R z4N9L9KfKL9BtguDzi95+j2ycmt14FtnWFK2aU6RLD0BS5NFP9TbSOo0j1fLs7NC3DbL hKZPtQMCznH9qImc/xg7t3PKhAqtr5r+qqLKQxO9R8AoKENpTxBQnPT4UoDzEKhFz8vO NutbDjxzHZN2NVNY7YUajUn2kNMi4EsqwCmsuJNXH3VQU4qBjgFQ8dCgIzbiaOiooXMS xfGe+C+YUmHIJu1fwWkoRViZ9R+LaTanraErqg/+ol/y5Ok8/0nfFYjPYp4EiFjxkTS6 dLUg== X-Gm-Message-State: AFeK/H3tzDxe+vWtVX9F15hiCYzbSvaaCs44H9nTCNbsRrW/TefytiUvl8NW3O9tpaLdri2xVh5AvqkCCpKTX3qu X-Received: by 10.36.13.70 with SMTP id 67mr508905itx.65.1490314711289; Thu, 23 Mar 2017 17:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Thu, 23 Mar 2017 17:18:10 -0700 (PDT) In-Reply-To: References: <75F554C8-74A5-40A3-816B-979272F8A147@greenbytes.de> From: "Charles 'Buck' Krasic" Date: Thu, 23 Mar 2017 17:18:10 -0700 Message-ID: Subject: Re: Core drafts -02 out To: Mike Bishop Cc: Stefan Eissing , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1143db5cf89c5e054b6eee6b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 00:18:37 -0000 --001a1143db5cf89c5e054b6eee6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 23, 2017 at 4:12 PM, Mike Bishop wrote: > With regard to header block versus frame, though, you explicitly said in > your reply before that the encoder can switch modes between frames in a > single block. So I think you mean what you wrote; it=E2=80=99s just that= switching > whether things can be interpreted out of order mid-block feels weird. > You're right. After re-reading Header Compression and Decompression just now, I see that I've been messing up the terminology, I was confusing header blocks with header block fragments. I will take a pass to correct that, and I think I need to call out that what I'm proposing diverges from the HTTP/2 description---my thinking is that a header block should be serialized packet/fragment-wise, as opposed to rfc5740 which says serialize the whole header block and then divide it into header block fragments. I agree that switching mid-block would feel weird, but it wouldn't be common at all. It should only be necessary if the table becomes full. I think experience will bear out that avoiding that > > And POSIX or not, I don't think you can unilaterally define a semantic > about delivery to the remote app layer. Though you could come close =E2= =80=93 if > the call completed when the written data and all preceding data on the > stream had been ACK=E2=80=99d, you know at least that the data is availab= le to the > remote app layer =E2=80=93 whether it reads promptly is its own problem. > I think you can go further than that and reason correctly about ordering in a coherent implementation. If HA has been fully acked before HB is encoded, then I think an implementation can quite reasonably guarantee that HA will be decoded before HB. I am confident this is true of ours. If it helps clarify at all, I'd remind that our implementation is single-threaded user level code. I can imagine how it might be more difficult (but not impossible) to reason about in an implementation that is multi-threaded and/or divided across a kernel-user boundary. > > Sent from my Windows 10 phone > > > > *From: *Charles 'Buck' Krasic > *Sent: *Thursday, March 23, 2017 2:58 PM > *To: *Mike Bishop > *Cc: *Stefan Eissing ; Martin Thomson > ; IETF QUIC WG > > *Subject: *Re: Core drafts -02 out > > > > > On Thu, Mar 23, 2017 at 10:52 AM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > >> All I see in the links are http:// and the draft name, no host. I=E2=80= =99m >> guessing you meant https://github.com/krasic/draf >> t-krasic-quic-hpack/blob/master/draft-krasic-quic-hpack-00.html? Once >> the tracker reopens (sometime Sunday, I think) you should probably uploa= d >> those at datatracker.ietf.org to make it an official submission. You=E2= =80=99ll >> need to make the draft name in the file match the file name before it wi= ll >> successfully upload. >> >> >> > Thanks for the prompt feedback! > > Apologies, as I mentioned it is my first attempt at an IETF draft, and it > my first time using the tools as described in SETUP.md > . > > Until I the tracker reopens and I submit properly, I would suggest > https://krasic.github.io/draft-krasic-quic-hpack/dra > ft-krasic-quic-qpack-latest.html > > >> Also, for ease of discussion, you might pick a different name than QPACK= , >> since there=E2=80=99s already a draft with that name. (Or we both chang= e names, >> and call the eventually-adopted one QPACK; that=E2=80=99d be fine, too.) >> > > I'm fine with whatever. If draft-krasic vs draft-bishop isn't enough to > differentiate, how about QPACK-ALT, or maybe QPACK-LITE? > >> >> >> As to actual feedback: I see what you=E2=80=99re getting at here becaus= e you=E2=80=99ve >> explained it =E2=80=93 the decoder acknowledges the sequence number it= =E2=80=99s up to, >> then the encoder tracks that and uses it on the encode side. I think I= =E2=80=99d >> have a really hard time parsing the document without that. I think the >> strongest advantage of this proposal is that an encoder for this scheme >> could be used over HTTP/2, enabling shared code; you should bring that o= ut >> more. >> > > I'll try to rework the text to emphise those points more and clarify. > > Nits: the decoder per-se doesn't ack, but the encoder tracks using > existing transport level ack mechanisms (more on this below). Also, I > think of this scheme as something a shared implementation could offer as = an > option, but I hadn't imagined the option would be ever be enabled in > HTTP/2. It might be interesting to consider though. > >> >> >> The way you=E2=80=99ve described the encoder requires tight integration = between >> the packetization logic and the header compressor in two ways: >> >> - It needs to know the =E2=80=9Cpacket epoch=E2=80=9D (encode epoch o= f the first >> frame in the current packet) while compressing, but until you know th= e size >> of the compressed output, you can=E2=80=99t know whether it will fit = in the current >> packet. That in turn means you=E2=80=99ll need to roll back any stat= e and >> re-encode with a different packet epoch if it turns out not to fit. >> >> I don't think roll back is esssential. > > The space available in the current packet could be known when invoking th= e > hpack encoder, so it would stop emitting representations if the packet > reaches the space limit, and in that case return a header block that for = a > prefix of the provided header field list, and in later packets it would > generate a continuation header block(s) for remaining header fields. > > >> - >> - The =E2=80=9Ccommit epoch=E2=80=9D is determined, not by data at th= e compressor >> level, but by reaching into the transport and checking which packets >> containing the STREAM frames containing the HPACK data in question ha= ve >> been acknowledged. Also note that ACK doesn=E2=80=99t signify delive= ry to the >> application layer (HTTP), just presence in the appropriate queue. >> >> >> > My understanding is that APIs are out of scope of most of the docs. > However, in our implementation, the stream write interfaces uniformly > provide a means of to confirm acknowledgement, so it is possible to do i= t > without reaching down. > > I agree that ACK doesn't signify delivery to what is above HTTP, but one > of advantages of not having legacy APIs (POSIX sockets) between QUIC and > HTTP is that the implemenation can certainly ensure that ACK signifies > delivery to HTTP. > >> In 2.2.1.1, the encoder is informed whether =E2=80=9CQPACK is enabled,= =E2=80=9D but since >> that can be toggled on/off on a per-header-frame basis (and I hope you >> really meant per-header-block), it seems like the decoder is just follow= ing >> the encoder=E2=80=99s lead on this. Who=E2=80=99s actually making that = decision? You say >> it gets turned off if a drop results, but the encoder is the one who >> knows/determines that. >> > Yes, all decisions are made by the encoder, and as in HPACK the decoder > strictly follows the encoder's lead. > > The "informed" language was simply alluding to the encoder side of the > HPACK API being extended with QPACK related params. > > And yes, I meant "header block". Will fix that. > > This has the same problem as the current HPACK state that RST on a contro= l >> stream loses critical data and there=E2=80=99s no way to recover. I=E2= =80=99m personally >> hoping we can make our way out of that requirement. >> > My position is that REFUSED should be the only kind of RST needed or > allowed for control streams, and dealing with that is tractible. > > >> >> *From:* Charles 'Buck' Krasic [mailto:ckrasic@google.com] >> *Sent:* Tuesday, March 21, 2017 6:04 PM >> *To:* Mike Bishop >> *Cc:* Stefan Eissing ; Martin Thomson < >> martin.thomson@gmail.com>; IETF QUIC WG >> >> *Subject:* Re: Core drafts -02 out >> >> >> >> Hi Folks. >> >> >> >> I've put together a first attempt at my QPACK proposal: >> >> >> >> draft-krasic-quic-hpack-00.html >> >> draft-krasic-quic-hpack-00.txt >> >> >> >> >> Apologies in advance, this is my first attempt at an IETF draft. >> >> >> >> >> >> On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop < >> Michael.Bishop@microsoft.com> wrote: >> >> Thanks for the feedback! >> >> Yes, you've run straight into the big quandary with HPACK. I don't thin= k >> anyone expects that we will ship this way; I have a proposal in >> https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack for an >> HPACK-replacement that would solve many of these. Buck Krasic has a >> proposal which he has sketched in e-mail but not submitted as a draft. = The >> main point of the sequence number was to get us off the "everything on >> stream 3" model and let us sort out the problems of HPACK later. #228 >> tracks fixing HPACK, in whatever form that takes. >> >> We could solve it in the same way that we did PRIORITY, by adding an >> "affected stream number" field and moving the HEADERS/PUSH_PROMISE frame= s >> to Stream 3 as well. However, that is just as blocking as the current >> approach, so not really an improvement. Worse, the reason we can tolera= te >> large header frames is because they occur on their own streams and don't >> block arrival of data from other streams. If all headers occur on a sin= gle >> stream, that's not true -- you *are* blocking muxing of other streams ag= ain. >> >> I like the comparison to concurrent edits. We've discussed having >> rolling deltas in various mechanisms; the problem is that it requires >> reaching into the transport for ACK state to figure out when you can >> discard old deltas for good on the receiver side. Buck's proposal is >> similar, essentially requiring the receiver to echo back the point up to >> which it has received all frames, and the sender shouldn't reference sta= te >> that the receiver hasn't fully assimilated yet. It feels like adding >> application-level ACKs to me, which I'd like to avoid. >> >> HPACK is also one of the reasons for the two-stream-per-request >> approach. There are two reasons for this -- one is that HPACK frames (i= n >> the current design) can't be lost when a stream is RST, so the draft >> forbids resetting control streams. Since we still need to be able to RS= T >> requests, we add the semantic that killing the data stream implies the s= ame >> thing about the control stream. It's messy, and hopefully we can remove >> that once HPACK is fixed. The second, as you guessed, is not dealing wi= th >> DATA frames. #245 notes that, if we fix HPACK, we could go back to a >> single stream per request; proponents of both "keep framing out of the w= ay" >> and "fewer streams is easier to manage" have weighed in there. Please a= dd >> your voice. >> >> As to buffering, it's actually easy enough -- just don't read from data >> streams until you've seen the headers. Sure, the sender will fill up th= eir >> flow control window on that stream -- and then they'll stop and send you >> QUIC BLOCKED frames, until you start reading the body and generating >> WINDOW_UPDATE frames. One of the biggest arguments for two streams in m= y >> mind is making sure that a request blocked in this way doesn't impede th= e >> flow of control frames on that stream -- for example, should we >> successfully get certificate auth frames added, a certificate request. >> I've had two customers this week telling me it's a bug in our server cod= e >> that their TLS reneg gets stuck in TCP buffers behind a giant request bo= dy, >> because the server won't read an unauthenticated body and the client won= 't >> hold off sending the body until authentication succeeds. I'd like to se= e >> blocks like that become less possible in QUIC, at least. >> >> Yes, making SETTINGS immutable reduces the flexibility. The opinion at >> the interim was that we could live without it, as we know of exactly one >> implementation of one extension that does mid-stream setting changes, an= d I >> own it. =F0=9F=98=8A If there's a compelling use case for changing set= tings >> mid-stream we weren't aware of, that's new information that could justif= y >> the complexity. (But note that with 0-RTT connection setup, it would be >> nearly as cheap to open a new connection with the new setting and >> transition your traffic to it.) >> >> Negotiation still works, since each side would simply advertise that the= y >> support an extension or not, and consider the extension to be active onc= e >> you've seen the other side's SETTINGS frame. See >> https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5.3 for >> the complexity this allowed us to remove. An extension could add to the >> list easily -- if you support extension X, you should also remember the >> value for setting X_VAL. Clients that don't use the extension don't car= e. >> An extension that needed some more complex negotiation would have to use= an >> extension-specific frame, it's true, but we haven't so far seen an >> extension do that. >> >> -----Original Message----- >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing >> Sent: Wednesday, March 15, 2017 6:22 AM >> To: Martin Thomson ; IETF QUIC WG < >> quic@ietf.org> >> Subject: Re: Core drafts -02 out >> >> >> > Am 14.03.2017 um 00:57 schrieb Martin Thomson > >: >> > >> > The editors have submitted -02 versions of the base set of QUIC drafts= . >> [...] >> > https://tools.ietf.org/html/draft-ietf-quic-http-02 >> >> Thanks, Martin! I assume that was announced to get feedback from the >> lurkers here. ;-) >> >> I'll give this a try. All mistakes and misunderstandings are mine alone. >> >> ------------------------------------------------------------ >> ----------------------------- >> >> Very well written spec. Easy to understand for someone having read rfc >> 7540 a bit. >> >> I have some comments to the proposed HTTP mapping approach. Where the wg >> has already discussed and exhausted alternatives, please excuse my >> ignorance and ignore my comments. I had not the time to follow all >> discussions ongoing on this topic. Feel free to cherry-pick what seems >> helpful. >> >> >> > 4. Stream Mapping and Usage >> >> +1 to directly using quic stream ids instead of virtual h2 stream >> +identifier >> >> >> However, using 2 quic streams for a single request/response does not sit >> well with me. I assume that stems from the wish to get rid of DATA frame= s. >> Which sounds nice, but is it worth it? By doubling the # of streams for = a >> client, how much overhead does that introduce (I speak of a server holdi= ng >> >10k quic "connections")? >> >> Also, the server needs to buffer data on quic streams 7, 11, 15, etc. >> because HEADERs might arrive some time in the future on streams 5, 9, 13= , >> etc. or not. There is no way to route this data somewhere, because the m= eta >> information is still missing. >> >> And there is still Holb on: >> >> > 4.2.1. Header Compression >> > ... >> > DISCUSS: Keep HPACK with HOLB? Redesign HPACK to be order- >> > invariant? How much do we need to retain compatibility with >> > HTTP/2's HPACK? >> >> Using a counter in HEADERS is a crutch: >> - it is a highly specific solution to a common problem in http/quic: >> synchronicity in connection level state changes. SETTINGS (see below) ha= s >> the same problem, as does have PRIORITY in HEADERS. It seems that >> performance wise, all HEADERS could as well be sent on stream 3. >> >> Now, solving Hol blocking for HEADERS would be a fine achievement. >> >> > 5. HTTP Framing Layer >> > Frames are used only on the connection (stream 3) and message >> > (streams 5, 9, etc.) control streams. >> >> And streams 4, 8, 12, etc. I assume. >> >> > 5.2.3. SETTINGS >> > ... >> > SETTINGS frames always apply to a connection, never a single stream. >> > A SETTINGS frame MUST be sent as the first frame of the connection >> > control stream (see Section 4) by each peer, and MUST NOT be sent >> > subsequently or on any other stream. If an endpoint receives an >> > SETTINGS frame on a different stream, the endpoint MUST respond with >> > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an >> > endpoint receives a second SETTINGS frame, the endpoint MUST respond >> > with a connection error of type HTTP_MULTIPLE_SETTINGS. >> >> What about HPACK state? The connection state change problem again visibl= e. >> >> This is a severe restriction on extensions mechanisms that want to affec= t >> a connection. Because if the http/quic does not solve this problem, how = are >> they expected to do it? They either announce themselves on the first >> SETTINGS or remain silent forever, it seems. How would an extension >> handshake work then? Own stream 3 handshake frames? >> >> > 5.2.3.3. Usage in 0-RTT >> >> What about HPACK state? Does it need to be kept or is it reset? >> >> > HTTP_PUSH_ALREADY_IN_CACHE (0x03): The server has attempted to push >> > content which the client has cached. >> > ... >> > HTTP_REQUEST_CANCELLED (0x04): The client no longer needs the >> > requested data. >> >> Nitpick: seems redundant. The first could be replaced by the second. >> Stream number will suffice. >> >> ---------------------------------------------------------- >> >> Taking two steps back: >> >> I think the main difficulty comes from the lack of a "hq connection >> state" concept and how changes to that state can be managed. Evidence: >> - The 0-RTT mentions certain SETTINGS that need to be remembered by a >> client. How would an extension add to this? Will every extension have to >> come up with its own solution? >> - The HEADERs sequence number is a highly specific fix for the missing >> state change >> - The SETTINGS-ONCE restriction simply avoids the problem by killing a h= 2 >> mechanism >> >> If hq defines stream 3 as the place where connection state changes happe= n >> *AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and ser= ver >> can have shareable concept of the connection state. >> >> >> I am no HPACK expert. The basic problem looks like concurrent editing >> against a repository. >> Both client and server start with connection state zero (CS-0) and the >> predefined HPACK dictionary (HP-0). After SETTINGS exchange, client is i= n >> CS-1 and server is in CS-2 for its side. Let's call the CS-1 HPACK stat= e >> HP-1. >> >> Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). >> The HEADERS carries the connection state number it is based on (CS-1). >> Client sends new HEADERS on stream 9, also based on CS-1. Client keeps t= hat >> delta around (HP-1.9). >> >> Client then decides to announce a new connection state (CS-3) by sending >> how it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The >> description allows the server to update its HP-1 to HP-3 as well. >> >> Response HEADERS are also based on a server connection state, explicitly= , >> so the client knows which HP-X to use when decoding them. At some time, = the >> server sends an announcment of CS-4 with HPACK data on stream 3 back to = the >> client. >> >> For a 0-RTT, client and server could exchange the connection state id in >> the initial SETTINGS, to make sure they have at least the same name >> remembered as the other side. Client: "I was in CS-19 and you were in >> CS-8." Server: "Yep." >> >> By implicitly adding all SETTINGS changes to connection states, the >> problem is also solved for extensions. >> >> If one side receives HEADERS with an unknown connection state: >> - if the state id is greater than any known one: set a stream timeout an= d >> wait for changes on stream 3 to arrive >> - state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STAT= E >> >> New SETTINGS value: MAX_CONN_STATE number of maximum connection state th= e >> client/server is willing to keep, exchanged initially. Announcing a new >> connection state allows the other side to drop the lowest one, if >> MAX_CONN_STATE are used. >> >> To get optimal HPACK size compression, every HEADERs would also announce >> a new connections state. To have less potential HOLB, connection states = do >> not change during request bursts. >> >> Something like that. >> >> -Stefan >> >> >> >> >> >> -- >> >> Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408= ) >> 412-1141 >> > > > > -- > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 <(408)%20412-1141> > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1143db5cf89c5e054b6eee6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 23, 2017 at 4:12 PM, Mike Bishop <Michael.Bishop@m= icrosoft.com> wrote:

With regard to header block versus frame, though, yo= u explicitly said in your reply before that the encoder can switch modes be= tween frames in a single block.=C2=A0 So I think you mean what you wrote; i= t=E2=80=99s just that switching whether things can be interpreted out of order mid-block feels weird.


You're right.=C2=A0 After re-reading=C2=A0= Header Compress= ion and Decompression=C2=A0just now, I see that =C2=A0I've been mes= sing up the terminology, I was confusing header blocks with header block fr= agments.=C2=A0 I will take a pass to correct that, and I think I need to ca= ll out that what I'm proposing diverges from the HTTP/2 description---m= y thinking is that a header block should be serialized packet/fragment-wise= , as opposed to rfc5740 which says serialize the whole header block and the= n divide it into header block fragments. =C2=A0

I = agree that switching mid-block would feel weird, but it wouldn't be com= mon at all.=C2=A0 It should only be necessary if the table becomes full.=C2= =A0 I think experience will bear out that avoiding that=C2=A0

=C2=A0

And POSIX or not, I don't think you can unilater= ally define a semantic about delivery to the remote app layer.=C2=A0 Though= you could come close =E2=80=93 if the call completed when the written data= and all preceding data on the stream had been ACK=E2=80=99d, you know at least that the data is available to the remote app layer =E2= =80=93 whether it reads promptly is its own problem.


I think you can go further than that and reason c= orrectly about ordering in a coherent implementation.

<= div>If HA has been fully acked before HB is encoded, then I think an implem= entation can quite reasonably guarantee that HA will be decoded before HB. = =C2=A0 I am confident this is true of ours. =C2=A0=C2=A0

If it helps clarify at all, I'd remind that our implementation i= s single-threaded user level code. =C2=A0 I can imagine how it might be mor= e difficult (but not impossible) to reason about in an implementation that = is multi-threaded and/or divided across a kernel-user boundary.
<= br>

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From: Charles 'Buck' K= rasic
Sent: Thursday, March 23, 2017 2:58 PM
To: Mike Bishop
Cc: Stefan Eissing; Martin Thomson; IETF= QUIC WG


Subject: Re: Core drafts -02 out

=C2=A0



On Thu, Mar 23, 2017 at 10:52 AM, Mike Bishop <Micha= el.Bishop@microsoft.com> wrote:

All I see in the links are http:// and the draft nam= e, no host.=C2=A0 I=E2=80=99m guessing you meant https://github.com/krasic/draft-krasic-quic-hpack/blob/master/dra= ft-krasic-quic-hpack-00.html?=C2=A0 Once the tracker reopens (some= time Sunday, I think) you should probably upload those at datatracker.ietf.= org to make it an official submission.=C2=A0 You=E2=80=99ll need to make the draft name in the file match the file name before it will successfully upload.<= /p>

=C2=A0

Thanks for the prompt feedback!

Apologies, as I mentioned it is my first attempt at an IETF draft, and= it my first time using the tools as described in=C2=A0SETUP.md.

Until I the tracker reopens and I submit properly, I would suggest=C2= =A0https://krasic.github.io/dr= aft-krasic-quic-hpack/draft-krasic-quic-qpack-latest.html
=C2=A0

Also, for ease of discussion, you might pick a= different name than QPACK, since there=E2=80=99s already a draft with that= name.=C2=A0 (Or we both change names, and call the eventually-adopted one = QPACK; that=E2=80=99d be fine, too.)


I'm fine with whatever.=C2=A0 If =C2=A0draft-krasic vs draft-bisho= p isn't enough to differentiate, =C2=A0how about QPACK-ALT, or maybe QP= ACK-LITE?=C2=A0

=C2=A0

As to actual feedback:=C2=A0 I see what you=E2= =80=99re getting at here because you=E2=80=99ve explained it =E2=80=93 the = decoder acknowledges the sequence number it=E2=80=99s up to, then the encod= er tracks that and uses it on the encode side.=C2=A0 I think I=E2=80=99d ha= ve a really hard time parsing the document without that.=C2=A0 I think the strongest a= dvantage of this proposal is that an encoder for this scheme could be used = over HTTP/2, enabling shared code; you should bring that out more.


I'll try to rework the text to emphise those points more and clari= fy. =C2=A0=C2=A0

Nits: =C2=A0the decoder per-se doesn't ack, but the e= ncoder tracks using existing transport level ack mechanisms (more on this b= elow). =C2=A0 Also, I think of this scheme as something a shared implementa= tion could offer as an option, but I hadn't imagined the option would be ever be enabled in HTTP/2.=C2=A0 It might be interesti= ng to consider though.

=C2=A0

The way you=E2=80=99ve described the encoder r= equires tight integration between the packetization logic and the header co= mpressor in two ways:

  • It needs to know the =E2=80=9Cpacket epoch=E2=80=9D (encode epoch of = the first frame in the current packet) while compressing, but until you kno= w the size of the compressed output, you can=E2=80=99t know whether it will= fit in the current packet.=C2=A0 That in turn means you=E2=80=99ll need to roll back any state and re-encode with a different packet epoch if it t= urns out not to fit.
I don't think roll back is esssential. =C2=A0=C2=A0

The space available in the current packet could be known = when invoking the hpack encoder, so it would stop emitting representations = if the packet reaches the space limit, and in that case return a header blo= ck that for a prefix of the provided header field list, and in later packets it would generate a continuation h= eader block(s) for remaining header fields.

  • The =E2=80=9Ccommit epoch=E2=80=9D is determined, not by data at the = compressor level, but by reaching into the transport and checking which pac= kets containing the STREAM frames containing the HPACK data in question hav= e been acknowledged.=C2=A0 Also note that ACK doesn=E2=80=99t signify delivery to the application layer (HTTP), just presence in the app= ropriate queue.

=C2=A0

My understanding is that APIs are out of scope of most of= the docs. =C2=A0 However, in our implementation, the stream write interfac= es uniformly provide a means of to confirm acknowledgement, =C2=A0so it is = possible to do it without reaching down.=C2=A0

I agree that ACK doesn't signify delivery to what is = above HTTP, but one of advantages of not having legacy APIs (POSIX sockets)= between QUIC and HTTP is that the implemenation can certainly ensure that = ACK signifies delivery to HTTP.

In 2.2.1.1, the encoder is informed whether = =E2=80=9CQPACK is enabled,=E2=80=9D but since that can be toggled on/off on= a per-header-frame basis (and I hope you really meant per-header-block), i= t seems like the decoder is just following the encoder=E2=80=99s lead on this.=C2=A0 Who=E2=80=99s actually making that decision?=C2=A0 You= say it gets turned off if a drop results, but the encoder is the one who k= nows/determines that.

Yes, all decisions are made by the encoder, and as in HPA= CK the decoder strictly follows the encoder's lead. =C2=A0=C2=A0

The "informed" language was simply alluding to = the encoder side of the HPACK API being extended with QPACK related params.=

And yes, I meant "header block".=C2=A0 Will fix= that.

This has the same problem as the current HPACK= state that RST on a control stream loses critical data and there=E2=80=99s= no way to recover.=C2=A0 I=E2=80=99m personally hoping we can make our way= out of that requirement.

My position is that REFUSED should be the only kind of RS= T needed or allowed for control streams, and dealing with that is tractible= .

=C2=A0

From: Charles 'Buck' Krasic [mailto:<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com]
Sent: Tuesday, March 21, 2017 6:04 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>; Martin Thom= son <marti= n.thomson@gmail.com>; IETF QUIC WG <quic@ietf.org>


Subject: Re: Core drafts -02 out

=C2=A0

Hi Folks.

=C2=A0

I've put together a first attempt at my QPACK pr= oposal:

=C2=A0

=C2=A0

Apologies in advance, this is my first attempt at an= IETF draft.

=C2=A0

=C2=A0

On Wed, Mar 15, 2017 at 10:37 AM, Mike Bishop <Michael.Bis= hop@microsoft.com> wrote:

Thanks for the feedback!

Yes, you've run straight into the big quandary with HPACK.=C2=A0 I don&= #39;t think anyone expects that we will ship this way; I have a proposal in https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack for a= n HPACK-replacement that would solve many of these.=C2=A0 Buck Krasic has a= proposal which he has sketched in e-mail but not submitted as a draft.=C2= =A0 The main point of the sequence number was to get us off the "everything on stream 3" model and let us sort= out the problems of HPACK later.=C2=A0 #228 tracks fixing HPACK, in whatev= er form that takes.

We could solve it in the same way that we did PRIORITY, by adding an "= affected stream number" field and moving the HEADERS/PUSH_PROMISE fram= es to Stream 3 as well.=C2=A0 However, that is just as blocking as the curr= ent approach, so not really an improvement.=C2=A0 Worse, the reason we can tolerate large header frames is because they occur on th= eir own streams and don't block arrival of data from other streams.=C2= =A0 If all headers occur on a single stream, that's not true -- you *ar= e* blocking muxing of other streams again.

I like the comparison to concurrent edits.=C2=A0 We've discussed having= rolling deltas in various mechanisms; the problem is that it requires reac= hing into the transport for ACK state to figure out when you can discard ol= d deltas for good on the receiver side.=C2=A0 Buck's proposal is similar, essentially requiring the receiver to echo= back the point up to which it has received all frames, and the sender shou= ldn't reference state that the receiver hasn't fully assimilated ye= t.=C2=A0 It feels like adding application-level ACKs to me, which I'd like to avoid.

HPACK is also one of the reasons for the two-stream-per-request approach.= =C2=A0 There are two reasons for this -- one is that HPACK frames (in the c= urrent design) can't be lost when a stream is RST, so the draft forbids= resetting control streams.=C2=A0 Since we still need to be able to RST requests, we add the semantic that killing the data= stream implies the same thing about the control stream.=C2=A0 It's mes= sy, and hopefully we can remove that once HPACK is fixed.=C2=A0 The second,= as you guessed, is not dealing with DATA frames.=C2=A0 #245 notes that, if we fix HPACK, we could go back to a single stream per = request; proponents of both "keep framing out of the way" and &qu= ot;fewer streams is easier to manage" have weighed in there.=C2=A0 Ple= ase add your voice.

As to buffering, it's actually easy enough -- just don't read from = data streams until you've seen the headers.=C2=A0 Sure, the sender will= fill up their flow control window on that stream -- and then they'll s= top and send you QUIC BLOCKED frames, until you start reading the body and generating WINDOW_UPDATE frames.=C2=A0 One of the big= gest arguments for two streams in my mind is making sure that a request blo= cked in this way doesn't impede the flow of control frames on that stre= am -- for example, should we successfully get certificate auth frames added, a certificate request.=C2=A0 I've h= ad two customers this week telling me it's a bug in our server code tha= t their TLS reneg gets stuck in TCP buffers behind a giant request body, be= cause the server won't read an unauthenticated body and the client won't hold off sending the body until authenticati= on succeeds.=C2=A0 I'd like to see blocks like that become less possibl= e in QUIC, at least.

Yes, making SETTINGS immutable reduces the flexibility.=C2=A0 The opinion a= t the interim was that we could live without it, as we know of exactly one = implementation of one extension that does mid-stream setting changes, and I= own it.=C2=A0 =F0=9F=98= =8A=C2=A0 If there's a compelling use case for changing settings= mid-stream we weren't aware of, that's new information that could = justify the complexity.=C2=A0 (But note that with 0-RTT connection setup, i= t would be nearly as cheap to open a new connection with the new setting and= transition your traffic to it.)

Negotiation still works, since each side would simply advertise that they s= upport an extension or not, and consider the extension to be active once yo= u've seen the other side's SETTINGS frame.=C2=A0 See https://tools.ietf.org/html/draft-ietf-quic-http-01#section-5.2.5= .3 for the complexity this allowed us to remove.=C2=A0 An extension cou= ld add to the list easily -- if you support extension X, you should also re= member the value for setting X_VAL.=C2=A0 Clients that don't use the extension don't care.=C2=A0 An extensio= n that needed some more complex negotiation would have to use an extension-= specific frame, it's true, but we haven't so far seen an extension = do that.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stefan Eissing
Sent: Wednesday, March 15, 2017 6:22 AM
To: Martin Thomson <martin.thomson@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Core drafts -02 out


> Am 14.03.2017 um 00:57 schrieb Martin Thomson <martin.thomson@gmail.com>:=
>
> The editors have submitted -02 versions of the base set of QUIC drafts= .
[...]
> https://tools.ietf.org/html/draft-ietf-quic-http-02
Thanks, Martin! I assume that was announced to get feedback from the lurker= s here. ;-)

I'll give this a try. All mistakes and misunderstandings are mine alone= .

-----------------------------------------------------------------= ------------------------

Very well written spec. Easy to understand for someone having read rfc 7540= a bit.

I have some comments to the proposed HTTP mapping approach. Where the wg ha= s already discussed and exhausted alternatives, please excuse my ignorance = and ignore my comments. I had not the time to follow all discussions ongoin= g on this topic. Feel free to cherry-pick what seems helpful.


> 4.=C2=A0 Stream Mapping and Usage

+1 to directly using quic stream ids instead of virtual h2 stream
+identifier


However, using 2 quic streams for a single request/response does not sit we= ll with me. I assume that stems from the wish to get rid of DATA frames. Wh= ich sounds nice, but is it worth it? By doubling the # of streams for a cli= ent, how much overhead does that introduce (I speak of a server holding >10k quic "connections"= ;)?

Also, the server needs to buffer data on quic streams 7, 11, 15, etc. becau= se HEADERs might arrive some time in the future on streams 5, 9, 13, etc. o= r not. There is no way to route this data somewhere, because the meta infor= mation is still missing.

And there is still Holb on:

> 4.2.1.=C2=A0 Header Compression
> ...
> DISCUSS:=C2=A0 Keep HPACK with HOLB?=C2=A0 Redesign HPACK to be order-=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0invariant?=C2=A0 How much do we need to reta= in compatibility with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/2's HPACK?

Using a counter in HEADERS is a crutch:
- it is a highly specific solution to a common problem in http/quic: synchr= onicity in connection level state changes. SETTINGS (see below) has the sam= e problem, as does have PRIORITY in HEADERS. It seems that performance wise= , all HEADERS could as well be sent on stream 3.

Now, solving Hol blocking for HEADERS would be a fine achievement.

> 5.=C2=A0 HTTP Framing Layer
> Frames are used only on the connection (stream 3) and message
>=C2=A0 =C2=A0 (streams 5, 9, etc.) control streams.

And streams 4, 8, 12, etc. I assume.

> 5.2.3.=C2=A0 SETTINGS
> ...
> SETTINGS frames always apply to a connection, never a single stream. >=C2=A0 A SETTINGS frame MUST be sent as the first frame of the connecti= on
> control stream (see Section 4) by each peer, and MUST NOT be sent
> subsequently or on any other stream.=C2=A0 If an endpoint receives an<= br> > SETTINGS frame on a different stream, the endpoint MUST respond with > a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM.=C2=A0 I= f an
> endpoint receives a second SETTINGS frame, the endpoint MUST respond > with a connection error of type HTTP_MULTIPLE_SETTINGS.

What about HPACK state? The connection state change problem again visible.<= br>
This is a severe restriction on extensions mechanisms that want to affect a= connection. Because if the http/quic does not solve this problem, how are = they expected to do it? They either announce themselves on the first SETTIN= GS or remain silent forever, it seems. How would an extension handshake work then? Own stream 3 handshake = frames?

> 5.2.3.3.=C2=A0 Usage in 0-RTT

What about HPACK state? Does it need to be kept or is it reset?

> HTTP_PUSH_ALREADY_IN_CACHE (0x03):=C2=A0 The server has attempted to p= ush
>=C2=A0 =C2=A0 =C2=A0 content which the client has cached.
> ...
> HTTP_REQUEST_CANCELLED (0x04):=C2=A0 The client no longer needs the >=C2=A0 =C2=A0 =C2=A0requested data.

Nitpick: seems redundant. The first could be replaced by the second. Stream= number will suffice.

----------------------------------------------------------

Taking two steps back:

I think the main difficulty comes from the lack of a "hq connection st= ate" concept and how changes to that state can be managed. Evidence: - The 0-RTT mentions certain SETTINGS that need to be remembered by a clien= t. How would an extension add to this? Will every extension have to come up= with its own solution?
- The HEADERs sequence number is a highly specific fix for the missing stat= e change
- The SETTINGS-ONCE restriction simply avoids the problem by killing a h2 m= echanism

If hq defines stream 3 as the place where connection state changes happen *= AND* synchronizes OPEN/CLOSE/RST of other streams on it, client and server = can have shareable concept of the connection state.


I am no HPACK expert. The basic problem looks like concurrent editing again= st a repository.
Both client and server start with connection state zero (CS-0) and the pred= efined HPACK dictionary (HP-0). After SETTINGS exchange, client is in CS-1 = and server is in CS-2 for its side. Let's call the=C2=A0 CS-1 HPACK sta= te HP-1.

Client sends new HEADERS on 5 and keeps the HPACK delta around (HP-1.5). Th= e HEADERS carries the connection state number it is based on (CS-1). Client= sends new HEADERS on stream 9, also based on CS-1. Client keeps that delta= around (HP-1.9).

Client then decides to announce a new connection state (CS-3) by sending ho= w it applied the deltas HP-1.5 and HP-1.9 to come up with HP-3. The descrip= tion allows the server to update its HP-1 to HP-3 as well.

Response HEADERS are also based on a server connection state, explicitly, s= o the client knows which HP-X to use when decoding them. At some time, the = server sends an announcment of CS-4 with HPACK data on stream 3 back to the= client.

For a 0-RTT, client and server could exchange the connection state id in th= e initial SETTINGS, to make sure they have at least the same name remembere= d as the other side. Client: "I was in CS-19 and you were in CS-8.&quo= t; Server: "Yep."

By implicitly adding all SETTINGS changes to connection states, the problem= is also solved for extensions.

If one side receives HEADERS with an unknown connection state:
- if the state id is greater than any known one: set a stream timeout and w= ait for changes on stream 3 to arrive
- state id less than max(known conn state): STREAM_RST_UNKNOWN_CONN_STATE
New SETTINGS value: MAX_CONN_STATE number of maximum connection state the c= lient/server is willing to keep, exchanged initially. Announcing a new conn= ection state allows the other side to drop the lowest one, if MAX_CONN_STAT= E are used.

To get optimal HPACK size compression, every HEADERs would also announce a = new connections state. To have less potential HOLB, connection states do no= t change during request bursts.

Something like that.

-Stefan



=C2=A0

--

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




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




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

--001a1143db5cf89c5e054b6eee6b-- From nobody Thu Mar 23 21:28:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0ED129431 for ; Thu, 23 Mar 2017 21:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ctb8edxj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=jwTL5hjf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DUntFqdc3wP for ; Thu, 23 Mar 2017 21:28:37 -0700 (PDT) Received: from mx0a-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 70E63129407 for ; Thu, 23 Mar 2017 21:28:37 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2O4Qr7o005621; Thu, 23 Mar 2017 21:28:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=/GBa+LwewvfGzzIC8PoHmK7N9JBm0qO1Mzb3WBepdVA=; b=ctb8edxjSiXnqtKpadHeogztrFSJ0kFRHtO8Y7t2RUhjAo7YnXxW2RlBJY/9GRyvSka5 eB20U97dSL4xOypBXeeteQ5OFE5MmuUKLFFr4e+OvdC4yG5jVDR7Xg84jeZgBPsV3VNZ fx3j3vP1nMxv0zs6v7yju6/X5kU7MgvXsFM= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0b-00082601.pphosted.com with ESMTP id 29cgcstq0g-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2017 21:28:32 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.30) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 24 Mar 2017 00:28:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/GBa+LwewvfGzzIC8PoHmK7N9JBm0qO1Mzb3WBepdVA=; b=jwTL5hjfMqsN1lvKqoe0TWuc4DnYcza+QltgUwWKm/QuPWbb+DSG836VCHYPfkzYYnlU4wUI0MpB0BViWwhRplBPlRcH6gftbvI5/t/GimogRnjm66OD6+NoJxkUGJVs0OE/1wQ84oYGpGITHslx11EFuH7KrlE+wvavdB8XFjA= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Fri, 24 Mar 2017 04:28:29 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0977.021; Fri, 24 Mar 2017 04:28:29 +0000 From: Subodh Iyengar To: "Lubashev, Igor" , Martin Thomson CC: "quic@ietf.org" Subject: Re: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGhltKAgAAu7CCAAH4YAIAAZDLNgAAXgICAAAogcw== Date: Fri, 24 Mar 2017 04:28:29 +0000 Message-ID: References: , , <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-Mentions: ilubashe@akamai.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 7:au1q+JGTCax2Z0jMcrAOHfjsvDz/AFZI3hC28nU/L+8516JfCujhcG4ItvUPEDD+8cU/XQLjR/N1KVi8616CuOEfeH3VrNLAskYcCyViA/RG85iEvKwP8GhmWiypIGhUa/vEQfuU7e/pxCKohlfZC+/DscRvrhm08YkV2IIIJbXCLXd+cWqGTAx6MHbCA6gC3KqsCUudq5EyMuW6WS/V7wstIuQ5+VhzyduZeZZLmAj4nRCPj93MWqu7MCxBObuppjWaUxs9HfNv6fW8iFjw0heFYXNHLZprf5PeZKrnIMH4buh8tdvY2pDopQ6vXG/MyVyktm7PNV9rCX0rmn4zqw==; 20:vhFBtHiwmPdrI10ndqNZYeflfEM+aN/gv2uErkAgm1JGU0DO/OJPPoToXriFhEvjLSvudqEP7dvY3h7REyWwJBuEa9rcgagsYWtUlx4P8OiFzzXayrE9nWTLJeAbKLUMT8PWsxF20+OIezy4a75eDK5GkeplEDE+qKKVSm/xMIc= x-ms-office365-filtering-correlation-id: 0c136176-9137-4cdf-4823-08d4726e38f0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR15MB1456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1456; x-forefront-prvs: 0256C18696 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39830400002)(51444003)(377454003)(24454002)(3280700002)(53546009)(25786009)(93886004)(790700001)(102836003)(6116002)(2906002)(86362001)(8676002)(66066001)(7696004)(2950100002)(3660700001)(81166006)(5660300001)(3846002)(4326008)(6246003)(38730400002)(33656002)(236005)(6306002)(54896002)(55016002)(99286003)(9686003)(189998001)(229853002)(6506006)(77096006)(6436002)(2900100001)(74316002)(7736002)(54356999)(8936002)(76176999)(19627405001)(50986999)(39060400002)(122556002)(53936002)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14556C117E35F0F38E366125B63F0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2017 04:28:29.0640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-24_03:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 04:28:40 -0000 --_000_MWHPR15MB14556C117E35F0F38E366125B63F0MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable @Lubashev, Igor >Concurrency limit is about the amount of local= resources a remote peer can consume. Let's say that for every stream there is an initiator (who is subject to st= ream limit) and a peer. Aren't the retransmission buffers which the peer has to hold onto until the= initiator ACKs them also a part of the local resources here? An initiator who doesn't ACK any bytes from the server forces a peer to kee= p state for it. However it could send it's own FIN which is ACKed normally. My question generally here is that with the current state machine seems tha= t it's difficult for both peers to get a consistent view of what each side = thinks that the open peer streams have. The peer should only release the retransmission buf= fers when it knows all of the data + FIN has been ACKed, and I think that's= when it should release the stream limit. However the initiator needs to know when this happens so = it would need to keep track of the ACKs for the ACKs it sent. Unidirectiona= l streams seem to make this simpler. >To be put precisely, the concurrency limit can be defined as =93the max nu= mber of streams with non-zero unACKed bytes sent by that peer=94. I'm not sure I understand your meaning here or maybe I'm confused by what y= ou consider as the peer. Can't the initiator just send a FIN and get an ACK for the FIN, however nev= er ACK the peer's frames? In this case the initiator would have "zero UNACK= ed bytes" but the peer would not. Subodh ________________________________ From: Lubashev, Igor Sent: Thursday, March 23, 2017 11:27:29 AM To: Subodh Iyengar; Martin Thomson Cc: quic@ietf.org Subject: RE: FIN + RST behavior Concurrency limit is about the amount of local resources a remote peer can = consume. It is not about how much local resources can be consumed by the l= ocal application =96 these limits can be enforced without any help from the= protocol. So concurrency limit is really the number of concurrent in-progress streams= that a peer is willing to receive. This maps well with unidirectional str= eams, but this is not a requirement. To be put precisely, the concurrency = limit can be defined as =93the max number of streams with non-zero unACKed = bytes sent by that peer=94. This means, peers can negotiate separate concu= rrency limits. - Igor From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Thursday, March 23, 2017 1:09 PM To: Martin Thomson Cc: quic@ietf.org Subject: Re: FIN + RST behavior > The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. Ya in the case of the previous example, it is a server resource since it's = a client initiated stream. @Martin Thomson I'm starting to like your = proposal of unidirectional streams more and more :) Subodh ________________________________ From: QUIC > on behalf = of Martin Thomson > Sent: Thursday, March 23, 2017 4:04:46 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior On 23 March 2017 at 15:10, Subodh Iyengar > wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it send= s > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of = the > ACKs of all the server sent bytes in the stream, which would be a bit sad= . The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. --_000_MWHPR15MB14556C117E35F0F38E366125B63F0MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

@Lubashev, Igor


>Concurrency limit is about the amount of = local resources a remote peer can consume.  


Let's say that for every stream there is an initiat= or (who is subject to stream limit) and a peer. 
Aren't the retransmission buffers which the peer has to hold onto unti= l the initiator ACKs them also a part of the local resources here?


An initiator who doesn't ACK any bytes from the server f= orces a peer to keep state for it. However it could send it's own FIN which= is ACKed normally.


My question generally here is that with the current stat= e machine seems that it's difficult for both peers to get a consistent view= of what each side thinks that the

open peer streams have. The peer should only release the= retransmission buffers when it knows all of the data + FIN has been AC= Ked, and I think that's when it should release

the stream limit. However the initiator needs to know when this happens so it would need to keep track of the ACKs for the ACKs it sent.&n= bsp;Unidirectional streams seem to make this simpler.

>To be put precisely, the concurrency limit can be = defined as =93the max number of streams with non-zero unACKed bytes sent by= that peer=94.


I'm not sure I understand your meanin= g here or maybe I'm confused by what you consider as the peer. =
Can't the initiator just send a FIN a= nd get an ACK for the FIN, however never ACK the peer's frames? In this case the initiator would have "zero UNACKed bytes&qu= ot; but the peer would not.

Subodh

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Thursday, March 23, 2017 11:27:29 AM
To: Subodh Iyengar; Martin Thomson
Cc: quic@ietf.org
Subject: RE: FIN + RST behavior
 

Concurrency limit is about the amount of local reso= urces a remote peer can consume.  It is not about how much local resou= rces can be consumed by the local application =96 these limits can be enforced without any help from the protocol.

 

So concurrency limit is really the number of concur= rent in-progress streams that a peer is willing to receive.  This maps= well with unidirectional streams, but this is not a requirement.  To be put precisely, the concurrency limit can be def= ined as =93the max number of streams with non-zero unACKed bytes sent by th= at peer=94.  This means, peers can negotiate separate concurrency limi= ts.

 

-     &= nbsp;    Igor

 

From: Subodh Iyengar [mailto:subodh@= fb.com]
Sent: Thursday, March 23, 2017 1:09 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

&= gt;  The client can consider its own resources t= o be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

Ya in the case of the previous example, it is a server resource s= ince it's a client initiated stream. 
@Marti= n Thomson I'm starting to like your proposal of unidirectio= nal streams more and more :)

<= o:p> 

Subodh

<= o:p> 

From: QUIC &= lt;quic-bounces@ietf.org> on behalf of Martin Thomson <martin.thomson@gmail.com>
Sent: Thursday, March 23, 2017 4:04:46 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com> wrote:
> How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it s= ends
> out the FIN because it still must keep state until it receives all the=
> ACKs for the stream. I think the client need to keep track of the ACK = of the
> ACKs of all the server sent bytes in the stream, which would be a bit = sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

--_000_MWHPR15MB14556C117E35F0F38E366125B63F0MWHPR15MB1455namp_-- From nobody Fri Mar 24 05:56:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139EC129444 for ; Fri, 24 Mar 2017 05:56:52 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nGSNwkbl_j2Y for ; Fri, 24 Mar 2017 05:56:49 -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 662AC1296CA for ; Fri, 24 Mar 2017 05:56:49 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2OCqUYP007976; Fri, 24 Mar 2017 12:56:44 GMT 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=S3z8SHR2X0x4ulPUI4HfquRL9ypZnTvAnKi9eWkFJto=; b=cxic/zFaBile8dFgyRBru5uM2ciQ4x6q3gvW5ieKxzJWhyLMDE567PL2CDd5CKcurrbu CSYciF34La1WI039wlvqII3aVqJo+XiFTykOZShkLVyPCmkl0efLB9RgjR6aL2I4RKfd 4xR0FXqECpYNAWFCpbym6pWsm33IMecs2cl5h8jT4hYTqlr17Bg9EgzFcRDfs+9yPLX/ O8Wo3kZIpY2fPCiTIq+imIMru8dZ+EJW9JpuulS2+7rZFdZXBguodmXCzLFA4ZEMtKEv 8FR6zBfddWIQ0NhVwBDAI1dHWfq293dVkkJBTlW78EXkSqGaNWKDflXxRTdqOd3oqJcL LA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29cnfmup3m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Mar 2017 12:56:43 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2OCp8QP020973; Fri, 24 Mar 2017 08:56:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 29b9ww8xnc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 24 Mar 2017 08:56:43 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Mar 2017 05:56:42 -0700 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.1178.000; Fri, 24 Mar 2017 08:56:42 -0400 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "subodh@fb.com" CC: "quic@ietf.org" Subject: RE: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGh2eCAgAA5O4CAAHPJAIAAZdGA///G0xCAAPb5gIAASu9p Date: Fri, 24 Mar 2017 12:56:41 +0000 Message-ID: <250e9b58e5294fca8e5a7e7a4c3643c8@usma1ex-dag1mb5.msg.corp.akamai.com> References: , , <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_250e9b58e5294fca8e5a7e7a4c3643c8usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703240112 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-24_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703240112 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 12:56:52 -0000 --_000_250e9b58e5294fca8e5a7e7a4c3643c8usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am not thinking about it from the perspective of the initiator of a strea= m. I am really thinking about a stream having two independent directions. I= t is the sender of the bytes (on a stream initiated by him or by the peer, = does not matter) that must count the stream toward his concurrency limit wh= ile there are any unacked sent bytes. (By peer, I mean "an endpoint".) The management of retransmit buffers is a local concern of the sender. If t= he buffers grow too large, the local app would not get a chance to write mo= re into them. We are only protecting reassembly buffers here. If we also wa= nt to protect a table containing state for active streams, we would need to= modify the definition for concurrent streams to "number of streams that th= is endpoint has sent any data on and still have unacked data or fin, or una= cked rst". - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 24 Mar 2017, 12:28AM To: Lubashev, Igor [ilubashe@akamai.com]; Martin Thomson [martin.thomson@gm= ail.com] CC: quic@ietf.org [quic@ietf.org] Subject: Re: FIN + RST behavior @Lubashev, Igor >Concurrency limit is about the amount of local= resources a remote peer can consume. Let's say that for every stream there is an initiator (who is subject to st= ream limit) and a peer. Aren't the retransmission buffers which the peer has to hold onto until the= initiator ACKs them also a part of the local resources here? An initiator who doesn't ACK any bytes from the server forces a peer to kee= p state for it. However it could send it's own FIN which is ACKed normally. My question generally here is that with the current state machine seems tha= t it's difficult for both peers to get a consistent view of what each side = thinks that the open peer streams have. The peer should only release the retransmission buf= fers when it knows all of the data + FIN has been ACKed, and I think that's= when it should release the stream limit. However the initiator needs to know when this happens so = it would need to keep track of the ACKs for the ACKs it sent. Unidirectiona= l streams seem to make this simpler. >To be put precisely, the concurrency limit can be defined as =93the max nu= mber of streams with non-zero unACKed bytes sent by that peer=94. I'm not sure I understand your meaning here or maybe I'm confused by what y= ou consider as the peer. Can't the initiator just send a FIN and get an ACK for the FIN, however nev= er ACK the peer's frames? In this case the initiator would have "zero UNACK= ed bytes" but the peer would not. Subodh ________________________________ From: Lubashev, Igor Sent: Thursday, March 23, 2017 11:27:29 AM To: Subodh Iyengar; Martin Thomson Cc: quic@ietf.org Subject: RE: FIN + RST behavior Concurrency limit is about the amount of local resources a remote peer can = consume. It is not about how much local resources can be consumed by the l= ocal application =96 these limits can be enforced without any help from the= protocol. So concurrency limit is really the number of concurrent in-progress streams= that a peer is willing to receive. This maps well with unidirectional str= eams, but this is not a requirement. To be put precisely, the concurrency = limit can be defined as =93the max number of streams with non-zero unACKed = bytes sent by that peer=94. This means, peers can negotiate separate concu= rrency limits. - Igor From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Thursday, March 23, 2017 1:09 PM To: Martin Thomson Cc: quic@ietf.org Subject: Re: FIN + RST behavior > The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. Ya in the case of the previous example, it is a server resource since it's = a client initiated stream. @Martin Thomson I'm starting to like your = proposal of unidirectional streams more and more :) Subodh ________________________________ From: QUIC > on behalf = of Martin Thomson > Sent: Thursday, March 23, 2017 4:04:46 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior On 23 March 2017 at 15:10, Subodh Iyengar > wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it send= s > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of = the > ACKs of all the server sent bytes in the stream, which would be a bit sad= . The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. --_000_250e9b58e5294fca8e5a7e7a4c3643c8usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I am not thinking about it from the perspective of the ini= tiator of a stream. I am really thinking about a stream having two independ= ent directions. It is the sender of the bytes (on a stream initiated by him or by the peer, does not matter) t= hat must count the stream toward his concurrency limit while there are any = unacked sent bytes. (By peer, I mean "an endpoint".)

The management of retransmit buffers is a local concern of the sender. If t= he buffers grow too large, the local app would not get a chance to write mo= re into them. We are only protecting reassembly buffers here. If we also wa= nt to protect a table containing state for active streams, we would need to modify the definition for concu= rrent streams to "number of streams that this endpoint has sent any da= ta on and still have unacked data or fin, or unacked rst".

- Igor

-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 24 Mar 2017, 12:28AM
To: Lubashev, Igor [ilubashe@akamai.com]; Martin Thomson [martin.tho= mson@gmail.com]
CC: quic@ietf.org [quic@ietf.org]
Subject: Re: FIN + RST behavior

@Lubashev, Igor


>Concurrency limit is about the amount of local r= esources a remote peer can consume.  


Let's say that for every stream there is an initiator (who= is subject to stream limit) and a peer. 
Aren't the retransmission buffers which the peer has to hold onto unti= l the initiator ACKs them also a part of the local resources here?


An initiator who doesn't ACK any bytes from the server for= ces a peer to keep state for it. However it could send it's own FIN which i= s ACKed normally.


My question generally here is that with the current state = machine seems that it's difficult for both peers to get a consistent view o= f what each side thinks that the

open peer streams have. The peer should only release the r= etransmission buffers when it knows all of the data + FIN has been ACKe= d, and I think that's when it should release

the stream limit. However the initiator needs = to know when this happens so it would need to keep track of the ACKs for the ACKs it sent. Unid= irectional streams seem to make this simpler.


>To be put precisely, the concurrency limit can be defined= as =93the max number of streams with non-zero unACKed bytes sent by that p= eer=94.


I'm not sure I understand your meaning = here or maybe I'm confused by what you consider as the peer. 
Can't the initiator just send a FIN and= get an ACK for the FIN, however never ACK the peer's frames? In this case the initiator would have "zero UNACKed bytes" = but the peer would not.

Subodh

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Thursday, March 23, 2017 11:27:29 AM
To: Subodh Iyengar; Martin Thomson
Cc: quic@ietf.org
Subject: RE: FIN + RST behavior
 

Concurrency limit is about the amount of local res= ources a remote peer can consume.  It is not about how much local reso= urces can be consumed by the local application =96 these limits can be enforced without any help from the protocol.

 

So concurrency limit is really the number of concu= rrent in-progress streams that a peer is willing to receive.  This map= s well with unidirectional streams, but this is not a requirement.  To be put precisely, the concurrency limit can be def= ined as =93the max number of streams with non-zero unACKed bytes sent by th= at peer=94.  This means, peers can negotiate separate concurrency limi= ts.

 

-  &nbs= p;       Igor

 

From: Subodh Iyengar [mailto:subod= h@fb.com]
Sent: Thursday, March 23, 2017 1:09 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

= >  The client can consider its own resource= s to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

Ya in the case of the previous example, it is a server resource s= ince it's a client initiated stream. 
@Mart= in Thomson I'm starting to like your proposal of unidirecti= onal streams more and more :)

=  

Subodh

=  

From: QU= IC <quic-bounces@ietf.org&g= t; on behalf of Martin Thomson <martin.thomson@gmail.com>
Sent: Thursday, March 23, 2017 4:04:46 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com> wrote:
> How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it s= ends
> out the FIN because it still must keep state until it receives all the=
> ACKs for the stream. I think the client need to keep track of the ACK = of the
> ACKs of all the server sent bytes in the stream, which would be a bit = sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

--_000_250e9b58e5294fca8e5a7e7a4c3643c8usma1exdag1mb5msgcorpak_-- From nobody Sat Mar 25 05:47:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E175D127010; Sat, 25 Mar 2017 05:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmRgna4F38X8; Sat, 25 Mar 2017 05:47:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF0E126D74; Sat, 25 Mar 2017 05:47:21 -0700 (PDT) X-AuditID: c1b4fb2d-275fe70000005be8-dc-58d666d5e8f1 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id CD.2A.23528.5D666D85; Sat, 25 Mar 2017 13:47:20 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sat, 25 Mar 2017 13:47:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sv/9ggK5km4UWQ9QwufPEPyHwOAPsFxWfP7cHuhEECA=; b=M0hxAv5mw17AzwnHwVW+IZXARm3wTW3yokBvv0JW0CSVVWzaaQig0J2uLi+u/4m8P8Lkki8c/7tUMQZlQH0sz5mlSGL3x+EHjbzAFFJf+86zeRNsgTjcj8DdZECOV/WChTNqjMoVl2yvx63eznFHHEDTWj61g0OXLL+pAq/ua00= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Sat, 25 Mar 2017 12:47:14 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0991.018; Sat, 25 Mar 2017 12:47:14 +0000 From: Ingemar Johansson S To: tcpm IETF list , "quic@ietf.org" Subject: On ACK rate issues and remedies in transport protocols Thread-Topic: On ACK rate issues and remedies in transport protocols Thread-Index: AdKlZTVrEpGJm/8LQESxP6miBqrqQA== Date: Sat, 25 Mar 2017 12:47:14 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [62.109.35.143] x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:B6LGDQEk7yjk0HftcwyZIVmlnU0ko3/TH/i+8DRH0kLwMzH7rW7Mwt7EDTqGI7CpQjCmP3pVt3IfBfFCoBnsVQtUboB6aUGBN9gNrU2eHm7zwdeX2zf0/78Zf8fFT02DGtRn0ntF9Xw6AMy2KPVb1ObQW6/gq5YGqrG4hR/v9iwqVhZRalTa9t/O1GWwhJzB8r8JmwpzfpdeITBSrzmEJgIg789WBi+Htmc3GQQj7G0azLNnB9bQxTkshrxYDxzLryxV/IhD5Jk3FCaAFw5eQnEXa94C4qq2fbc3yl2iO+RnxygEAe0mIFjg3Owxdj6uAP7EMqOPWT37sY3h280gvQ== x-ms-office365-filtering-correlation-id: a7f81aeb-3eab-4467-a196-08d4737d1060 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:DB4PR07MB348; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39850400002)(39410400002)(8676002)(81166006)(9326002)(8936002)(74316002)(7736002)(33656002)(2501003)(450100002)(5660300001)(86362001)(77096006)(54356999)(50986999)(25786009)(6506006)(38730400002)(9686003)(6116002)(3846002)(102836003)(790700001)(236005)(2906002)(189998001)(54896002)(2900100001)(55016002)(99286003)(19609705001)(122556002)(6306002)(3660700001)(6436002)(3280700002)(53936002)(66066001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2017 12:47:14.7394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUyM2K7iu6NtGsRBp8fKln0LOC22HZyPpMD k8eSJT+ZAhijuGxSUnMyy1KL9O0SuDKmHgsomGJa0XP9OXMD4wKDLkZODgkBE4md10+zdTFy cQgJrGOU+HJnDjuEc4JR4v2Ke2AZFoFeZonlR2awgrQICUxlkuhoU4eoOsYo0fzsGDtIgk3A RmLloe+MILaIgLPExI+fwWxhAXuJd0/aoeIuEr/3rwCaygFk60lsPSgCYrIIqEpc/u0AUsEr ECWx/cxMsFWMArIS97/fYwGxmQXEJW49mc8EcbWAxJI955khbFGJl4//sYKcwyjQzSjxYd41 qCJFiY6u04wgCQmBbmaJwy1boDp8Jdb+eMECYUdLzL/TChXPlFg+axszTHzKsS42CHsGk8S1 83EQtoxEy4cJzBBDb7JIPH07gwXiSSmJu1c6oR6WkXhxZy8rxNn5Es/a7rJCvCYocXLmE6jF ARLzJy9nn8CoOgvJd7OQtMxC0gIR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI4gsY2Vcxihan FhfnphsZ66UWZSYXF+fn6eWllmxiBCacg1t+6+5gXP3a8RCjAAejEg/vhyVXI4RYE8uKK3MP MUpwMCuJ8LLPAArxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TB KdXAmFjau3+28GtjzVVbZ91ZJPbUcOHi6P93v9Yv3XDwwYN5OyQ054eKbspoOBjYJrT/ZxPH TovrMyKsWf+auPfcDfHIUb7QN3v1qmee1dcbTef2Nl6QZj1r+2VRudC0aVdumPBLHL9fVZfO 39KytOTQ8Wq53bXqLAo7fytHxZfYPPO7YNndG71ioxJLcUaioRZzUXEiAD2lcJw0AwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 12:47:24 -0000 --_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have asked for a slot at TSVWG for a presentation on issued with transpor= t protocol ACKs. What I am in interested is to know what earlier work such = as RFC5690 exist and also if there are possibilities to reduce the ACK rate= in light of recent additions such as RACK and packet pacing. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I have asked for a slot at TSVWG for a presentation = on issued with transport protocol ACKs. What I am in interested is to know = what earlier work such as RFC5690 exist and also if there are possibilities= to reduce the ACK rate in light of recent additions such as RACK and packet pacing.

 

/Ingemar

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

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DB4PR07MB348D65A3427C583F9D91FF0C2310DB4PR07MB348eurprd_-- From nobody Sun Mar 26 11:05:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3C12967B for ; Sun, 26 Mar 2017 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 GMAswwT-Aadi for ; Sun, 26 Mar 2017 11:05:07 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DFD1270B4 for ; Sun, 26 Mar 2017 11:05:07 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id n5so10651949pgh.0 for ; Sun, 26 Mar 2017 11:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MoyUw8wI9EzGQHl867fmanCxPg9VVeJ3uJUi1NG+V1A=; b=oh63nJHq4168RgL1ilinQGaUgdzUBLEdnRRgQe96XvSYYrewzfBdtRZvaIR58bD7dm vy4VUuLSz7+5DXVB1Lbz4LM/mHzfFjB97r1AhFsyc0+X+y+YPfwYn3mfJ6Qrry+UviS3 QGlZWTXspRhCQ4PfCR/V6NX1Dm+Os94N6DXITshBNu3DQXyd8kOX2XEdkgXaFcIV84du agJZ8eHJFlP5IMB1E9pagVIgQLVXywjk/kJ9lE53syKICUy6nlROD8RSm1HraCk/lBTV Om9xIqovpJrj7GygUHnhg18w2rXw7LyEF6gzspVEEPQ6TVk+fmoGe2hlwZWs7dK0kG5d fX6A== 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=MoyUw8wI9EzGQHl867fmanCxPg9VVeJ3uJUi1NG+V1A=; b=cx01WKn6Zigd5hKqJkaUVMXgrdnvRWLXteavLra3jfYmitm0zDRDy2KpojpunGewMK OEB4NsqCVO1RAGlNheJDnLgEAJZhKkcpCSFwrYBMaxKbHpfNq9wuPPF5ePmH4IkjbXlC 7DXcgl2F2xK1KuoebubUf2ijGO7oNVubqFfzuxJeCEie/AbDzDUp8ccCSviZ14ilIbpN p1XKoEhhBvnF9+2LFqNPqNtFrydNsAvFrSxufuHcOZZxEv5+sPXLpVfhsbDRE9pPx2qh wG77Tzp36o0XM4BNT3HgoENPTfsrVhP+RspydRaQPpNw30zjJ/w8QGr2aF161IteBmpo RGbA== X-Gm-Message-State: AFeK/H3M6Xiody3BeQYcbSaEmNzjV6X0Nb9ccf0R628is9+Y8Y1K7kydLTOHLiOSDXS+AoCDZPORT/+tDQP1NXCT X-Received: by 10.98.20.8 with SMTP id 8mr21220763pfu.10.1490551506390; Sun, 26 Mar 2017 11:05:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.22 with HTTP; Sun, 26 Mar 2017 11:05:05 -0700 (PDT) From: Jana Iyengar Date: Sun, 26 Mar 2017 14:05:05 -0400 Message-ID: Subject: QUIC tutorial at 3PM today To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c03969e0f29e2054ba61102 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 18:05:09 -0000 --94eb2c03969e0f29e2054ba61102 Content-Type: text/plain; charset=UTF-8 PSA: There's a QUIC tutorial at 3PM today (in Zurich E/F). If you plan to attend, please note that this tutorial is intended for those unfamiliar with QUIC and is not a wg meeting. --94eb2c03969e0f29e2054ba61102 Content-Type: text/html; charset=UTF-8
PSA: There's a QUIC tutorial at 3PM today (in Zurich E/F). If you plan to attend, please note that this tutorial is intended for those unfamiliar with QUIC and is not a wg meeting.

--94eb2c03969e0f29e2054ba61102-- From nobody Sun Mar 26 12:37:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D696A1296A0 for ; Sun, 26 Mar 2017 12:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Qs1Z3Jtb2D for ; Sun, 26 Mar 2017 12:37:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBB612969B for ; Sun, 26 Mar 2017 12:37:47 -0700 (PDT) X-AuditID: c1b4fb2d-64c6598000005be8-79-58d818891720 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 91.32.23528.98818D85; Sun, 26 Mar 2017 21:37:46 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.339.0; Sun, 26 Mar 2017 21:37:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lIZgoONKwtOSmcXSQEi/5dF0HNN8dPkrX3HNb92fMOE=; b=YXxnhOXQjQWBWxIr/vzG1XCASPQqVCZWZpB36GXwQhMd1/MUTvxPFFmnfGDCum24IcWMwCkEbxpMu1ZVduhlp3pz8cbhxtJ6CSqgeogCdjXRtcByOTGzjiNRwV1D7Q03khMMHjuQqAnl55lle0eiYVnFHv1fhdqsbbFzuye9WqQ= Received: from DB5PR07MB1271.eurprd07.prod.outlook.com (10.164.41.149) by DB5PR07MB1269.eurprd07.prod.outlook.com (10.164.41.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Sun, 26 Mar 2017 19:37:19 +0000 Received: from DB5PR07MB1271.eurprd07.prod.outlook.com ([fe80::49f1:3175:4f83:449]) by DB5PR07MB1271.eurprd07.prod.outlook.com ([fe80::49f1:3175:4f83:449%14]) with mapi id 15.01.1005.007; Sun, 26 Mar 2017 19:37:18 +0000 From: Marcus Ihlar To: "ianswett@google.com" , "ietf@trammell.ch" CC: "quic@ietf.org" Subject: RE: on packet number echo Thread-Topic: on packet number echo Thread-Index: AdKjzVfoULcKwamLQcWSluk12k7rBQ== Date: Sun, 26 Mar 2017 19:37:18 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.80] x-microsoft-exchange-diagnostics: 1; DB5PR07MB1269; 7:anXJ/aFSKpL0Ugq8SaQGfNkm+Nj5SDoZFBA+ogLqSXLVR9vfzeily5PXRAY7SCS9MT2y4H08VF+dhy7WvvL2K1uwKjxT69QEGvs7JIe7HkLb02/6zre3XOTBNmvEKBYOrUiOGHMIGMFUHTkBH7eB5r6n7erWvouZqO2szafQh8gIq4T8kiTclYL5FEduwvs4SKUWLtzbG4jB3qd2yYfvqNML9bUIZG5xxB6e/o3eyk3hK9MgijUge88crTY+gKi+AWAnRvELBdbs+1vhyGbVofx0OxmAlrwjd748HRiW6DN2IOmDolackkR2tsJCediuNi6UF7lVkNH+8+5M8NtoJQ== x-ms-office365-filtering-correlation-id: b9166788-d025-4505-6724-08d4747f83b2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:DB5PR07MB1269; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:DB5PR07MB1269; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1269; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39850400002)(39410400002)(24454002)(377454003)(6436002)(6306002)(6506006)(55016002)(54896002)(9686003)(99286003)(86362001)(4326008)(54356999)(50986999)(2900100001)(7696004)(229853002)(5660300001)(33656002)(66066001)(53936002)(3480700004)(2906002)(189998001)(38730400002)(74316002)(5250100002)(8676002)(3660700001)(2501003)(3846002)(81166006)(102836003)(6116002)(8936002)(790700001)(25786009)(236005)(3280700002)(53546009)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB1269; H:DB5PR07MB1271.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB12719A91EFB76B1E7997A6A9E2300DB5PR07MB1271eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 19:37:18.3987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1269 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUyM2K7pW6XxI0Ig0ffWC1+3tvJarGx5R2b Rc8CbgdmjwWbSj2WLPnJ5PFk/0yWAOYoLpuU1JzMstQifbsEroyeo++YCj51MFY8a1BuYJzT ytjFyMkhIWAisW3DBSCbi0NIYD2jxPPXF9hAEkICJxgldl8PBrFZBHqZJSZes4eIT2OSWNPi A9HwkFHiaNMUsElsAnoSZ+52gzWLCERI9F2azgxiMwsoS0w53cAKYgsLKEn07rzE3sXIDlSj LHFaAKJaT+LOrkagCg6gVaoSN966goR5BWIktt1fBDaEUUBW4v73eywQA8Ulbj2ZzwRxvoDE kj3nmSFsUYmXj/+xglzGKNDPKHH59W2oIgWJJV8msoMkJAR6mCVOrbvEBLJMQsBXYvlHN4ia GIldr39DwyRb4s6zW1C2t0TLst0sEL2zmCQ2dJxgg0jISFyd/hkq8YFF4vjGuUwQP0pJ3L3S yQhhy0i8uLMX7DNmgXyJqfeCIT4TlDg58wnLBEa1WUgemoVQNQtJFURYU2L9Ln2IakWJKd0P 2SFsDYnWOXPZkcUXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAhMQge3/Nbdwbj6teMh RgEORiUeXoN91yKEWBPLiitzDzFKcDArifBerAQK8aYkVlalFuXHF5XmpBYfYpTmYFES53XY dyFCSCA9sSQ1OzW1ILUIJsvEwSnVwGijH/bGzUouVuNNdJ+YVKBKy5X05b7uYtKBC9UXVUcX iqwpCWFe/Ij7TeIz9qUGf3ur/ic47n6pa+Qk6zZnM5/H63z92ccYRGVXaB6cOZlnqrK6ycQb C1My7x6JLZzrcWvP4cv8bx6evhJ55uGvxvzb+h9+PPX47L/Ay0LhtPGHM/O1Jm3/UaTEUpyR aKjFXFScCADApAPxPgMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 19:37:51 -0000 --_000_DB5PR07MB12719A91EFB76B1E7997A6A9E2300DB5PR07MB1271eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBpc3N1ZSBJIGhhdmUgd2l0aCBvcHRpb24gMSBpcyB0aGF0IHRoYXQgbWFueSBl bmRwb2ludHMgbWFpbmx5IHJlY2VpdmUgZGF0YSBhbmQgb25seSByYXJlbHkgdHJhbnNtaXQgYWNr OmFibGUgZnJhbWVzLiBTdWNoIGVuZHBvaW50cyB3aWxsIGxpa2VseSAgaGF2ZSBvdXRkYXRlZCBS VFQtZXN0aW1hdGVzLiBUaGlzIGNvdWxkIGxlYWQgdG8gZWNob2VzIGJlaW5nIHRyYW5zbWl0dGVk IG1vcmUgdGhhbiBvbmNlIHBlciBSVFQgKG5vdCBhIHByb2JsZW0pLCBidXQgdGhlIG9wcG9zaXRl IGNvdWxkIGJlIHRydWUgYXMgd2VsbCBnaXZlbiB0aGUgbGV2ZWxzIG9mIGppdHRlciB3ZSBvYnNl cnZlIGluIGUuZyBjZWxsdWxhciBuZXR3b3Jrcy4NCg0KDQoNCi8vTWFyY3VzDQoNCkZyb206IFFV SUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQN ClNlbnQ6IGRlbiAxNSBtYXJzIDIwMTcgMDA6NTcNClRvOiBCcmlhbiBUcmFtbWVsbCAoSUVURikg PGlldGZAdHJhbW1lbGwuY2g+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IG9uIHBhY2tldCBudW1iZXIgZWNobw0KDQoNCg0KVGhhbmtzIGZvciBzdW1tYXJp emluZyB0aGlzIEJyaWFuLg0KDQoNCg0KVGhlIGZpcnN0IG9wdGlvbiBtZWFucyB0aGF0IGFuIGlt cGxlbWVudGF0aW9uIGNvdWxkIG5vdCBzZW5kIHRoZSBlY2hvLCBmb3IgZXhhbXBsZSBpZiBhIG5l dHdvcmsgd2FzIHVzaW5nIGl0IGluIGEgd2F5IHRoYXQgd2FzIGhhcm1mdWwgdG8gdXNlcnMuICBU aGlzIHByb3ZpZGVzIGFuIGluY2VudGl2ZSBmb3IgbmV0d29ya3MgdGhhdCBkbyB1c2UgaXQgdG8g ZWl0aGVyIGRvIG5vdGhpbmcgYWN0aXZlIHdpdGggaXQgb3IgdXNlIGl0IHRvIGltcHJvdmUgdXNl ciBleHBlcmllbmNlLiAoc2VlIE1hcmN1cyBJaGxhcidzIHRocmVhZCBmb3IgdGhhdCkNCg0KDQoN CkkgdGhpbmsgdGhlIGxhcmdlc3QgdXBzaWRlKG9yIGRvd25zaWRlLCBkZXBlbmRpbmcgdXBvbiB5 b3VyIHBlcnNwZWN0aXZlKSBvZiB0aGUgc2Vjb25kIG9wdGlvbiB3aGVyZSB0aGUgbGFyZ2VzdCBh Y2tlZCBpcyBpbmNsdWRlZCB3aXRoIGV2ZXJ5IGZyYW1lIGlzIHRoYXQgaXQgbWVhbnMgb25lIE1V U1QgaW1wbGVtZW50IHRoaXMgY29ycmVjdGx5IHRvIGltcGxlbWVudCBRVUlDLCBhdCBsZWFzdCBp ZiB0aGV5IHdhbnQgdG8gdXNlIHRoZSBzdGFuZGFyZCBhY2sgZnJhbWUuDQoNCg0KDQpQZXJzb25h bGx5LCBteSBsYXJnZXN0IGNvbmNlcm4gd2l0aCB0aGUgc2Vjb25kIGNhc2UgaXMgdGhhdCBvZiBk aWZmZXJlbnRpYWwgdHJlYXRtZW50IG9mIGFja3MuICBXaGF0IGlmIGFuIGFjayBwYWNrZXQgY29u dGFpbnMgb3RoZXIgZGF0YSwgYW5kIGEgbWlkZGxlYm94IGRlY2lkZXMgdGhhdCBvbmx5IHRoZSBt b3N0IHJlY2VudCBhY2sgbmVlZHMgdG8gYmUgZGVsaXZlcmVkKGEgY29tbW9uIFRDUCBhcHByb2Fj aCksIHNvIHRoZSBkYXRhIGJ1bmRsZWQgd2l0aCB0aGUgYWNrIGlzIGluYWR2ZXJ0ZW50bHkgbG9z dD8NCg0KDQoNCkF0IHRoaXMgcG9pbnQsIEkgbGVhbiB0b3dhcmRzIHRoZSBmaXJzdCBvcHRpb24s IGJlY2F1c2UgSSB1bmRlcnN0YW5kIHRoZSBpbXBsaWNhdGlvbnMgYmV0dGVyLCBidXQgSSBjb3Vs ZCBiZSBjb252aW5jZWQgb3RoZXJ3aXNlLg0KDQoNCg0KRWl0aGVyIHdheSwgSSB0aGluayBib3Ro IG9mIHRoZXNlIGFyZSBwb3RlbnRpYWxseSB3b3J0aHkgb2YgaW5jbHVkaW5nIGFuZCBJIHRoaW5r IHRoZXkncmUgcHJlZmVyYWJsZSB0byBkb2luZyBub3RoaW5nLg0KDQoNCg0KDQoNCk9uIFR1ZSwg TWFyIDE0LCAyMDE3IGF0IDEwOjQ2IEFNLCBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJh bW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90ZToNCg0KICAgR3JlZXRpbmdz LCBhbGwsDQoNCiAgIGZvciB0aG9zZSBub3Qgd2F0Y2hpbmcgZ2l0aHViLCB0aGVyZSdzIGEgZGlz Y3Vzc2lvbiBvbiBwYWNrZXQgbnVtYmVyIGVjaG87IG15IHN1bW1hcnkgcG9zdCBpbiBQUiMzOTEg aXMgcmVwcm9kdWNlZCBiZWxvdzoNCg0KICAgdG8gc3VtbWFyaXplLi4uIHRoZXJlIHNlZW0gdG8g YmUgdGhyZWUgcG9zc2liaWxpdGllcyBlbWVyZ2luZyBoZXJlOg0KDQogICAjIyMgRWNobyAoYXQg bGVhc3QpIG9uY2UgcGVyIFJUVC4gTGVhdmUgQUNLIGZyYW1lcyB1bmNoYW5nZWQuDQoNCiAgIChU aGlzIGlzIHdoYXQncyB3cml0dGVuIHVwIGluIHRoaXMgUFIpLg0KDQogICBSYXRpb25hbGU6IFdo YXQgaGFwcGVucyBpbiB0aGUgZnJhbWUgbGF5ZXIgc3RheXMgaW4gdGhlIGZyYW1lIGxheWVyLiBQ YWNrZXQgbnVtYmVyIGVjaG8gaXMgYSBwdXJlIHBhY2tldC1sYXllciBjaGFuZ2UgdG8gdGhlIHRy YW5zcG9ydCBwcm90b2NvbC4gU2luY2UgdGhpcyBpcyBhZGRpdGlvbmFsIG92ZXJoZWFkLCB3ZSBz aG91bGQgd29yayB0byBtaW5pbWl6ZSBpdCwgaGVuY2Ugb25jZSBwZXIgUlRULCB0aGUgbWluaW11 bSBmcmVxdWVuY3kgdGhhdCB3b3JrcyBmb3IgcGFzc2l2ZSBsYXRlbmN5IG1lYXN1cmVtZW50Lg0K DQogICBVcHNpZGVzOiBJdCdzIGEgdGlueSBjaGFuZ2UgdG8gdGhlIHByb3RvY29sIGFzIHByZXNl bnRseSBkZXNjcmliZWQsIGZvciBhIGxvdyBvdmVyaGVhZCBjb3N0IHBlciBSVFQgKDEtNCBieXRl cywgdXN1YWxseSAyKS4gVGhlIEFDSyBmcmFtZSByZW1haW5zIHNlbGYtZGVzY3JpYmluZywgc28g dGhlIGFjayBmcmFtZSBoYW5kbGluZyBjb21wb25lbnQgaW4gYW4gaW1wbGVtZW50YXRpb24gY2Fu IHJlbWFpbiBzZXBhcmF0ZSBmcm9tIHRoZSBwYWNrZXQgaGFuZGxpbmcgY29tcG9uZW50LiBFbmRw b2ludHMgY2FuIGNob29zZSB0byBlY2hvIG1vcmUgZnJlcXVlbnRseSAoZS5nLiwgd2hlbiBjb25m aWd1cmVkIHRvIGRvIHNvIGZvciBkZWJ1Z2dpbmcgcHVycG9zZXMpLg0KDQogICBEb3duc2lkZXM6 IGFuIGVjaG9pbmcgZW5kcG9pbnQgd2l0aCBhIHBhc3NpdmVseS1jb29wZXJhdGl2ZSBwZWVyIGNh biBpbnRlbnRpb25hbGx5IHNrZXcgcGFzc2l2ZSBtZWFzdXJlbWVudHMsIHNpbmNlIHRoZSB2YWx1 ZSBpbiB0aGUgcGFja2V0IGhlYWRlciBpcyBub3QgbmVjZXNzYXJpbHkgam9pbmVkIHRvIHRoZSB2 YWx1ZSBpbiB0aGUgYWNrIGZyYW1lLiBUaGUgdXRpbGl0eSBhbmQgcHJhY3RpY2FsaXR5IG9mIHN1 Y2ggYSB0aGluZyBpcyBkZWJhdGFibGUuIEl0J3Mgbm90IGNsZWFyIGhvdyBnb29kIHRoZSByZXN1 bHRpbmcgbnVtYmVyL2VjaG8gc3RyZWFtIHdpbGwgYmUgZm9yIG9uZS1wb2ludCBsb3NzIGFuZCBy ZW9yZGVyaW5nIGVzdGltYXRpb24uDQoNCiAgICMjIyBFY2hvIG1heC1hY2tlZCBvbiBldmVyeSBw YWNrZXQgd2l0aCBhbiBBQ0sgZnJhbWUsIGFuZCByZW1vdmUgaXQgZnJvbSB0aGUgYWNrIGZyYW1l Lg0KDQogICBSYXRpb25hbGU6IFRoaXMgaW5mb3JtYXRpb24gYWxyZWFkeSBhcHBlYXJzIGluIHRo ZSBBQ0sgbGF5ZXIsIHNvIHRoZXJlJ3Mgbm8gYWRkaXRpb25hbCBvdmVyaGVhZC4NCg0KICAgVXBz aWRlczogRWNobyBmcmVxdWVuY3kgaXMgaGlnaGVyOyB0aGlzIHNob3VsZCBtYWtlIGxvc3MgYW5k IHJlb3JkZXJpbmcgZXN0aW1hdGlvbiB3b3JrIGJldHRlciBhdCBhIHNpbmdsZSBvYnNlcnZhdGlv biBwb2ludC4gIE5vIGFkZGl0aW9uYWwgb3ZlcmhlYWQuDQoNCiAgIERvd25zaWRlczogSW5jcmVh c2VkIGNvbXBsZXhpdHkgb2YgaW1wbGVtZW50YXRpb25zLCB3aGljaCBoYXZlIHRvIHBhc3MgcGFj a2V0IG51bWJlciBlY2hvIGluZm9ybWF0aW9uIHVwIHRoZSBzdGFjay4gTm8gZW5kcG9pbnQgY29u dHJvbCBvdmVyIGhvdyBvZnRlbiBwYWNrZXQgbnVtYmVycyBhcmUgZWNob2VkLCBzaW5jZSBtYXgt YWNrIGlzIHJlcXVpcmVkIGJ5IHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtcy4NCg0KICAgTWl4ZWRz aWRlcyAoZGVwZW5kaW5nIG9uIHlvdXIgcHJvY2xpdml0aWVzKTogVGhlIHByZXNlbmNlIG9mIGFu IEFDSyBmcmFtZSBpcyBub3cgZXhwb3NlZCB0byB0aGUgcGF0aC4gQUNLLWZyYW1lLWNvbnRhaW5p bmcgcGFja2V0cyBjYW4gKGFuZCBnaXZlbiB0aGUgaGlzdG9yeSBvZiBUQ1AsIHByb2JhYmx5IHdp bGwpIGJlIHRyZWF0ZWQgZGlmZmVyZW50bHkgYnkgdGhlIG5ldHdvcmsgaW4gY2VydGFpbiBjaXJj dW1zdGFuY2VzLg0KDQogICAjIyMgRG9uJ3QgZWNobyBwYWNrZXQgbnVtYmVycyBhdCBhbGwNCg0K ICAgKHRoaXMgaXMgdGhlIG5vLWJ1aWxkIG9wdGlvbikNCg0KDQoNCiAgIENoZWVycywNCg0KICAg QnJpYW4NCg0KDQoNCg== --_000_DB5PR07MB12719A91EFB76B1E7997A6A9E2300DB5PR07MB1271eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iU1YiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBpc3N1ZSBJIGhhdmUgd2l0aCBv cHRpb24gMSBpcyB0aGF0IHRoYXQgbWFueSBlbmRwb2ludHMgbWFpbmx5IHJlY2VpdmUgZGF0YSBh bmQgb25seSByYXJlbHkgdHJhbnNtaXQgYWNrOmFibGUgZnJhbWVzLiBTdWNoIGVuZHBvaW50cw0K IHdpbGwgbGlrZWx5ICZuYnNwO2hhdmUgb3V0ZGF0ZWQgUlRULWVzdGltYXRlcy4gVGhpcyBjb3Vs ZCBsZWFkIHRvIGVjaG9lcyBiZWluZyB0cmFuc21pdHRlZCBtb3JlIHRoYW4gb25jZSBwZXIgUlRU IChub3QgYSBwcm9ibGVtKSwgYnV0IHRoZSBvcHBvc2l0ZSBjb3VsZCBiZSB0cnVlIGFzIHdlbGwg Z2l2ZW4gdGhlIGxldmVscyBvZiBqaXR0ZXIgd2Ugb2JzZXJ2ZSBpbiBlLmcgY2VsbHVsYXIgbmV0 d29ya3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4vL01hcmN1czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IGRlbiAxNSBtYXJzIDIwMTcgMDA6 NTc8YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIFRyYW1tZWxsIChJRVRGKSAmbHQ7aWV0ZkB0cmFtbWVs bC5jaCZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IG9uIHBhY2tldCBudW1iZXIgZWNobzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Igc3VtbWFyaXppbmcgdGhp cyBCcmlhbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBmaXJzdCBvcHRpb24gbWVhbnMgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBub3Qgc2Vu ZCB0aGUgZWNobywgZm9yIGV4YW1wbGUgaWYgYSBuZXR3b3JrIHdhcyB1c2luZyBpdCBpbiBhIHdh eSB0aGF0IHdhcyBoYXJtZnVsIHRvIHVzZXJzLiZuYnNwOyBUaGlzIHByb3ZpZGVzIGFuIGluY2Vu dGl2ZSBmb3IgbmV0d29ya3MgdGhhdCBkbyB1c2UgaXQgdG8gZWl0aGVyIGRvIG5vdGhpbmcgYWN0 aXZlIHdpdGggaXQNCiBvciB1c2UgaXQgdG8gaW1wcm92ZSB1c2VyIGV4cGVyaWVuY2UuIChzZWUg TWFyY3VzIElobGFyJ3MgdGhyZWFkIGZvciB0aGF0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBsYXJnZXN0IHVwc2lkZShv ciBkb3duc2lkZSwgZGVwZW5kaW5nIHVwb24geW91ciBwZXJzcGVjdGl2ZSkgb2YgdGhlIHNlY29u ZCBvcHRpb24gd2hlcmUgdGhlIGxhcmdlc3QgYWNrZWQgaXMgaW5jbHVkZWQgd2l0aCBldmVyeSBm cmFtZSBpcyB0aGF0IGl0IG1lYW5zIG9uZSBNVVNUIGltcGxlbWVudCB0aGlzIGNvcnJlY3RseSB0 byBpbXBsZW1lbnQgUVVJQywgYXQgbGVhc3QgaWYgdGhleSB3YW50DQogdG8gdXNlIHRoZSBzdGFu ZGFyZCBhY2sgZnJhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBlcnNvbmFsbHksIG15IGxhcmdlc3QgY29uY2VybiB3aXRoIHRoZSBzZWNv bmQgY2FzZSBpcyB0aGF0IG9mIGRpZmZlcmVudGlhbCB0cmVhdG1lbnQgb2YgYWNrcy4mbmJzcDsg V2hhdCBpZiBhbiBhY2sgcGFja2V0IGNvbnRhaW5zIG90aGVyIGRhdGEsIGFuZCBhIG1pZGRsZWJv eCBkZWNpZGVzIHRoYXQgb25seSB0aGUgbW9zdCByZWNlbnQgYWNrIG5lZWRzIHRvIGJlIGRlbGl2 ZXJlZChhIGNvbW1vbiBUQ1AgYXBwcm9hY2gpLA0KIHNvIHRoZSBkYXRhIGJ1bmRsZWQgd2l0aCB0 aGUgYWNrIGlzIGluYWR2ZXJ0ZW50bHkgbG9zdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhpcyBwb2ludCwgSSBsZWFuIHRvd2FyZHMg dGhlIGZpcnN0IG9wdGlvbiwgYmVjYXVzZSBJIHVuZGVyc3RhbmQgdGhlIGltcGxpY2F0aW9ucyBi ZXR0ZXIsIGJ1dCBJIGNvdWxkIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVpdGhlciB3YXksIEkgdGhp bmsgYm90aCBvZiB0aGVzZSBhcmUgcG90ZW50aWFsbHkgd29ydGh5IG9mIGluY2x1ZGluZyBhbmQg SSB0aGluayB0aGV5J3JlIHByZWZlcmFibGUgdG8gZG9pbmcgbm90aGluZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgMTQsIDIwMTcg YXQgMTA6NDYgQU0sIEJyaWFuIFRyYW1tZWxsIChJRVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZAdHJhbW1lbGwuY2giIHRhcmdldD0iX2JsYW5rIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5HcmVldGluZ3MsIGFsbCw8YnI+DQo8YnI+DQpm b3IgdGhvc2Ugbm90IHdhdGNoaW5nIGdpdGh1YiwgdGhlcmUncyBhIGRpc2N1c3Npb24gb24gcGFj a2V0IG51bWJlciBlY2hvOyBteSBzdW1tYXJ5IHBvc3QgaW4gUFIjMzkxIGlzIHJlcHJvZHVjZWQg YmVsb3c6PGJyPg0KPGJyPg0KdG8gc3VtbWFyaXplLi4uIHRoZXJlIHNlZW0gdG8gYmUgdGhyZWUg cG9zc2liaWxpdGllcyBlbWVyZ2luZyBoZXJlOjxicj4NCjxicj4NCiMjIyBFY2hvIChhdCBsZWFz dCkgb25jZSBwZXIgUlRULiBMZWF2ZSBBQ0sgZnJhbWVzIHVuY2hhbmdlZC48YnI+DQo8YnI+DQoo VGhpcyBpcyB3aGF0J3Mgd3JpdHRlbiB1cCBpbiB0aGlzIFBSKS48YnI+DQo8YnI+DQpSYXRpb25h bGU6IFdoYXQgaGFwcGVucyBpbiB0aGUgZnJhbWUgbGF5ZXIgc3RheXMgaW4gdGhlIGZyYW1lIGxh eWVyLiBQYWNrZXQgbnVtYmVyIGVjaG8gaXMgYSBwdXJlIHBhY2tldC1sYXllciBjaGFuZ2UgdG8g dGhlIHRyYW5zcG9ydCBwcm90b2NvbC4gU2luY2UgdGhpcyBpcyBhZGRpdGlvbmFsIG92ZXJoZWFk LCB3ZSBzaG91bGQgd29yayB0byBtaW5pbWl6ZSBpdCwgaGVuY2Ugb25jZSBwZXIgUlRULCB0aGUg bWluaW11bSBmcmVxdWVuY3kgdGhhdA0KIHdvcmtzIGZvciBwYXNzaXZlIGxhdGVuY3kgbWVhc3Vy ZW1lbnQuPGJyPg0KPGJyPg0KVXBzaWRlczogSXQncyBhIHRpbnkgY2hhbmdlIHRvIHRoZSBwcm90 b2NvbCBhcyBwcmVzZW50bHkgZGVzY3JpYmVkLCBmb3IgYSBsb3cgb3ZlcmhlYWQgY29zdCBwZXIg UlRUICgxLTQgYnl0ZXMsIHVzdWFsbHkgMikuIFRoZSBBQ0sgZnJhbWUgcmVtYWlucyBzZWxmLWRl c2NyaWJpbmcsIHNvIHRoZSBhY2sgZnJhbWUgaGFuZGxpbmcgY29tcG9uZW50IGluIGFuIGltcGxl bWVudGF0aW9uIGNhbiByZW1haW4gc2VwYXJhdGUgZnJvbSB0aGUgcGFja2V0IGhhbmRsaW5nDQog Y29tcG9uZW50LiBFbmRwb2ludHMgY2FuIGNob29zZSB0byBlY2hvIG1vcmUgZnJlcXVlbnRseSAo ZS5nLiwgd2hlbiBjb25maWd1cmVkIHRvIGRvIHNvIGZvciBkZWJ1Z2dpbmcgcHVycG9zZXMpLjxi cj4NCjxicj4NCkRvd25zaWRlczogYW4gZWNob2luZyBlbmRwb2ludCB3aXRoIGEgcGFzc2l2ZWx5 LWNvb3BlcmF0aXZlIHBlZXIgY2FuIGludGVudGlvbmFsbHkgc2tldyBwYXNzaXZlIG1lYXN1cmVt ZW50cywgc2luY2UgdGhlIHZhbHVlIGluIHRoZSBwYWNrZXQgaGVhZGVyIGlzIG5vdCBuZWNlc3Nh cmlseSBqb2luZWQgdG8gdGhlIHZhbHVlIGluIHRoZSBhY2sgZnJhbWUuIFRoZSB1dGlsaXR5IGFu ZCBwcmFjdGljYWxpdHkgb2Ygc3VjaCBhIHRoaW5nIGlzIGRlYmF0YWJsZS4NCiBJdCdzIG5vdCBj bGVhciBob3cgZ29vZCB0aGUgcmVzdWx0aW5nIG51bWJlci9lY2hvIHN0cmVhbSB3aWxsIGJlIGZv ciBvbmUtcG9pbnQgbG9zcyBhbmQgcmVvcmRlcmluZyBlc3RpbWF0aW9uLjxicj4NCjxicj4NCiMj IyBFY2hvIG1heC1hY2tlZCBvbiBldmVyeSBwYWNrZXQgd2l0aCBhbiBBQ0sgZnJhbWUsIGFuZCBy ZW1vdmUgaXQgZnJvbSB0aGUgYWNrIGZyYW1lLjxicj4NCjxicj4NClJhdGlvbmFsZTogVGhpcyBp bmZvcm1hdGlvbiBhbHJlYWR5IGFwcGVhcnMgaW4gdGhlIEFDSyBsYXllciwgc28gdGhlcmUncyBu byBhZGRpdGlvbmFsIG92ZXJoZWFkLjxicj4NCjxicj4NClVwc2lkZXM6IEVjaG8gZnJlcXVlbmN5 IGlzIGhpZ2hlcjsgdGhpcyBzaG91bGQgbWFrZSBsb3NzIGFuZCByZW9yZGVyaW5nIGVzdGltYXRp b24gd29yayBiZXR0ZXIgYXQgYSBzaW5nbGUgb2JzZXJ2YXRpb24gcG9pbnQuJm5ic3A7IE5vIGFk ZGl0aW9uYWwgb3ZlcmhlYWQuPGJyPg0KPGJyPg0KRG93bnNpZGVzOiBJbmNyZWFzZWQgY29tcGxl eGl0eSBvZiBpbXBsZW1lbnRhdGlvbnMsIHdoaWNoIGhhdmUgdG8gcGFzcyBwYWNrZXQgbnVtYmVy IGVjaG8gaW5mb3JtYXRpb24gdXAgdGhlIHN0YWNrLiBObyBlbmRwb2ludCBjb250cm9sIG92ZXIg aG93IG9mdGVuIHBhY2tldCBudW1iZXJzIGFyZSBlY2hvZWQsIHNpbmNlIG1heC1hY2sgaXMgcmVx dWlyZWQgYnkgdGhlIHRyYW5zcG9ydCBtZWNoYW5pc21zLjxicj4NCjxicj4NCk1peGVkc2lkZXMg KGRlcGVuZGluZyBvbiB5b3VyIHByb2NsaXZpdGllcyk6IFRoZSBwcmVzZW5jZSBvZiBhbiBBQ0sg ZnJhbWUgaXMgbm93IGV4cG9zZWQgdG8gdGhlIHBhdGguIEFDSy1mcmFtZS1jb250YWluaW5nIHBh Y2tldHMgY2FuIChhbmQgZ2l2ZW4gdGhlIGhpc3Rvcnkgb2YgVENQLCBwcm9iYWJseSB3aWxsKSBi ZSB0cmVhdGVkIGRpZmZlcmVudGx5IGJ5IHRoZSBuZXR3b3JrIGluIGNlcnRhaW4gY2lyY3Vtc3Rh bmNlcy48YnI+DQo8YnI+DQojIyMgRG9uJ3QgZWNobyBwYWNrZXQgbnVtYmVycyBhdCBhbGw8YnI+ DQo8YnI+DQoodGhpcyBpcyB0aGUgbm8tYnVpbGQgb3B0aW9uKTxicj4NCjxicj4NCjxicj4NCjxi cj4NCkNoZWVycyw8YnI+DQo8YnI+DQpCcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB5PR07MB12719A91EFB76B1E7997A6A9E2300DB5PR07MB1271eurp_-- From nobody Sun Mar 26 13:27:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8909A127076 for ; Sun, 26 Mar 2017 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=fToZ3vlq; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=dakZTqnN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THH_gX3pSLlq for ; Sun, 26 Mar 2017 13:27:28 -0700 (PDT) Received: from mx0a-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 0D6B6127275 for ; Sun, 26 Mar 2017 13:27:27 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2QKQww8030826; Sun, 26 Mar 2017 13:27:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=pZKGNi1IcaUVMhJrLXKke2rXFYdS2i0AErTZclT5AWw=; b=fToZ3vlqzwxpi5gx+yjbxXcFfHFcMevj90CnhrUOIur8JL40HVAY6qt1GO1m652qLAXl Jjebsn0Rr5ZZCUEQNvvQaSAHguBeUvMp1G1pyEBRWJUpqFxXz9xPciIJibYo22ux6bcg x6++YO5U6UqwmpZnDSQOTqiYLxKb6U4jhWg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0b-00082601.pphosted.com with ESMTP id 29dmc23cht-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Mar 2017 13:27:22 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 26 Mar 2017 16:27:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pZKGNi1IcaUVMhJrLXKke2rXFYdS2i0AErTZclT5AWw=; b=dakZTqnNMqSmVd3jKjWK1RUxaTx99o1S5jWMTuIlk0jTERAzYYqsHaA7WBnigfRO8N6qiM/yTP7CdkAR9GjclV1t8o24zRZ+im6sK0yYkcRswedClrF0KcF3PZJ+gQLgJmC1a+XZJL1xpaauJlV+LUN3wyjNRof3k6SUIHqWfSo= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sun, 26 Mar 2017 20:27:19 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0991.018; Sun, 26 Mar 2017 20:27:19 +0000 From: Subodh Iyengar To: "Lubashev, Igor" , "martin.thomson@gmail.com" CC: "quic@ietf.org" Subject: Re: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGhltKAgAAu7CCAAH4YAIAAZDLNgAAXgICAAAogc4ABK8iAgAOeKKc= Date: Sun, 26 Mar 2017 20:27:19 +0000 Message-ID: References: , , <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com>, , <250e9b58e5294fca8e5a7e7a4c3643c8@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <250e9b58e5294fca8e5a7e7a4c3643c8@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=fb.com; x-originating-ip: [2620:10d:c090:180::caa6] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 7:ZJpUFE/bJATQfjZxbRMgnMWLlGjYl1pIfjyOEljSkdCf69fsAfdLZWfYXkMJX5VdCG1FgzSVoFKlx0OuHGy0wqnebtOuty70NOsJCGKh0iB+DtNoBnzlJGcAFMaU4DthWnA9fmyOhSmvyazZm7iW36I0YEIfdj1+z/5NIsgbES/g+0NvCR0+8oBJWbxkOrO3naSGnGCDkez0rUbnn/XUmhNyNRLUHcGaE474nL8NdwGkPYarq7v36wyDU9vxALmtYg6Fix0ectUuL6MVvtxXdv0IaoKEnSaDW061TvtqJNls2yP4y+QayrhWcY3anNw+hNXHtOFruitsj5uaNEQAag==; 20:MP5L+SviI/KnLJH9qc5Vwkx9OqCy9Jn17vGflTfbBvuKxFcjkuhagj2/D7unnVOPxnkyIV8D7RzQtRZXi74DTwtDcFA9TwgYKyX1yvCON54+WfFlas3QzqK/lcoJ532AJoaxxmk4uIH4K/9wAMUDqAxHSrihTOG47t2HYwJ+WHk= x-ms-office365-filtering-correlation-id: 418725e3-4b43-4ed8-4e3e-08d474868080 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:MWHPR15MB1455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040408)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(201703131423033)(201702281528033)(201703061421033)(201703061406033)(20161123560025)(20161123558025)(20161123564025)(6072148); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1455; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39400400002)(39410400002)(51444003)(377454003)(24454002)(13464003)(93886004)(33656002)(561944003)(19627405001)(7696004)(2501003)(3660700001)(6116002)(102836003)(2950100002)(3280700002)(189998001)(7736002)(74316002)(8936002)(5660300001)(8676002)(236005)(25786009)(4326008)(39060400002)(38730400002)(53546009)(229853002)(55016002)(9686003)(54896002)(6436002)(6506006)(77096006)(2900100001)(6246003)(99286003)(81166006)(2906002)(53936002)(54356999)(50986999)(76176999)(86362001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455388350826978E960683DB6300MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 20:27:19.2631 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-26_17:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 20:27:30 -0000 --_000_MWHPR15MB1455388350826978E960683DB6300MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > We are only protecting reassembly buffers here Isn't that what the connection flow control window and the stream flow cont= rol window is for? > must count the stream toward his concurrency limit while there are any un= acked sent bytes. (By peer, I mean "an endpoint".) If this is the correct interpretation of how concurrency limit is accounted= for in the current draft, then it seems like it provides is no better prot= ection than the flow control window. The real value of a stream concurrency limit would be to be able to protect= the stream state table and to allow senders to protect their write buffers= . Sure, senders can slow themselves down, however putting that local limit = on yourself is another complexity in addition to the other sender side limi= ts like congestion control, and a tradeoff between throughput and buffer bu= ild-up. It seems like the draft could benefit from is explicit signaling of the ava= ilable concurrent limit similar to the flow control window which is explici= tly signaled. Then we can actually have the peer advertise a concurrent lim= it whenever it feels like it's ready to receive more streams, which would m= ake this way easier to account for resource usage in the state table and al= low the receiver to expand this limit in the future. Subodh ________________________________ From: Lubashev, Igor Sent: Friday, March 24, 2017 5:56:41 AM To: martin.thomson@gmail.com; Subodh Iyengar Cc: quic@ietf.org Subject: RE: FIN + RST behavior I am not thinking about it from the perspective of the initiator of a strea= m. I am really thinking about a stream having two independent directions. I= t is the sender of the bytes (on a stream initiated by him or by the peer, = does not matter) that must count the stream toward his concurrency limit wh= ile there are any unacked sent bytes. (By peer, I mean "an endpoint".) The management of retransmit buffers is a local concern of the sender. If t= he buffers grow too large, the local app would not get a chance to write mo= re into them. We are only protecting reassembly buffers here. If we also wa= nt to protect a table containing state for active streams, we would need to= modify the definition for concurrent streams to "number of streams that th= is endpoint has sent any data on and still have unacked data or fin, or una= cked rst". - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 24 Mar 2017, 12:28AM To: Lubashev, Igor [ilubashe@akamai.com]; Martin Thomson [martin.thomson@gm= ail.com] CC: quic@ietf.org [quic@ietf.org] Subject: Re: FIN + RST behavior @Lubashev, Igor >Concurrency limit is about the amount of local= resources a remote peer can consume. Let's say that for every stream there is an initiator (who is subject to st= ream limit) and a peer. Aren't the retransmission buffers which the peer has to hold onto until the= initiator ACKs them also a part of the local resources here? An initiator who doesn't ACK any bytes from the server forces a peer to kee= p state for it. However it could send it's own FIN which is ACKed normally. My question generally here is that with the current state machine seems tha= t it's difficult for both peers to get a consistent view of what each side = thinks that the open peer streams have. The peer should only release the retransmission buf= fers when it knows all of the data + FIN has been ACKed, and I think that's= when it should release the stream limit. However the initiator needs to know when this happens so = it would need to keep track of the ACKs for the ACKs it sent. Unidirectiona= l streams seem to make this simpler. >To be put precisely, the concurrency limit can be defined as =93the max nu= mber of streams with non-zero unACKed bytes sent by that peer=94. I'm not sure I understand your meaning here or maybe I'm confused by what y= ou consider as the peer. Can't the initiator just send a FIN and get an ACK for the FIN, however nev= er ACK the peer's frames? In this case the initiator would have "zero UNACK= ed bytes" but the peer would not. Subodh ________________________________ From: Lubashev, Igor Sent: Thursday, March 23, 2017 11:27:29 AM To: Subodh Iyengar; Martin Thomson Cc: quic@ietf.org Subject: RE: FIN + RST behavior Concurrency limit is about the amount of local resources a remote peer can = consume. It is not about how much local resources can be consumed by the l= ocal application =96 these limits can be enforced without any help from the= protocol. So concurrency limit is really the number of concurrent in-progress streams= that a peer is willing to receive. This maps well with unidirectional str= eams, but this is not a requirement. To be put precisely, the concurrency = limit can be defined as =93the max number of streams with non-zero unACKed = bytes sent by that peer=94. This means, peers can negotiate separate concu= rrency limits. - Igor From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Thursday, March 23, 2017 1:09 PM To: Martin Thomson Cc: quic@ietf.org Subject: Re: FIN + RST behavior > The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. Ya in the case of the previous example, it is a server resource since it's = a client initiated stream. @Martin Thomson I'm starting to like your = proposal of unidirectional streams more and more :) Subodh ________________________________ From: QUIC > on behalf = of Martin Thomson > Sent: Thursday, March 23, 2017 4:04:46 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior On 23 March 2017 at 15:10, Subodh Iyengar > wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it send= s > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of = the > ACKs of all the server sent bytes in the stream, which would be a bit sad= . The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. --_000_MWHPR15MB1455388350826978E960683DB6300MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> We are only protecting reassembly buffers here<= br> Isn't that what the connection flow control window and the stream flow cont= rol window is for?


> must count the stream towar= d his concurrency limit while there are any unacked sent bytes. (By peer, I= mean "an endpoint".)

If this is the correct interpretation of how concurrency limit is= accounted for in the current draft, then it seems like it provides is no b= etter protection than the flow control window. 

The real value of a stream concurrency limit would be to be able to protect= the stream state table and to allow senders to protect their write&nb= sp;buffers. Sure, senders can slow themselves down, however putting th= at local limit on yourself is another complexity in addition to the other sender side limits like congestion control, = and a tradeoff between throughput and buffer build-up.

It seems like the draft could benefit from is explicit signaling of the ava= ilable concurrent limit similar to the flow control window which is ex= plicitly signaled. Then we can actually have the peer advertise a concurren= t limit whenever it feels like it's ready to receive more streams, which would make this way easier to account = for resource usage in the state table and allow the receiver to e= xpand this limit in the future. 


Subodh

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Friday, March 24, 2017 5:56:41 AM
To: martin.thomson@gmail.com; Subodh Iyengar
Cc: quic@ietf.org
Subject: RE: FIN + RST behavior
 
I am not thinking about it from the perspective of th= e initiator of a stream. I am really thinking about a stream having two ind= ependent directions. It is the sender of the bytes (on a stream initiated by him or by the peer, does not matter= ) that must count the stream toward his concurrency limit while there are a= ny unacked sent bytes. (By peer, I mean "an endpoint".)

The management of retransmit buffers is a local concern of the sender. If t= he buffers grow too large, the local app would not get a chance to write mo= re into them. We are only protecting reassembly buffers here. If we also wa= nt to protect a table containing state for active streams, we would need to modify the definition for concu= rrent streams to "number of streams that this endpoint has sent any da= ta on and still have unacked data or fin, or unacked rst".

- Igor

-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 24 Mar 2017, 12:28AM
To: Lubashev, Igor [ilubashe@akamai.com]; Martin Thomson [martin.tho= mson@gmail.com]
CC: quic@ietf.org [quic@ietf.org]
Subject: Re: FIN + RST behavior

@Lubashev, Igor


>Concurrency limit is about the amount of local r= esources a remote peer can consume.  


Let's say that for every stream there is an initiator (who= is subject to stream limit) and a peer. 
Aren't the retransmission buffers which the peer has to hold onto unti= l the initiator ACKs them also a part of the local resources here?


An initiator who doesn't ACK any bytes from the server for= ces a peer to keep state for it. However it could send it's own FIN which i= s ACKed normally.


My question generally here is that with the current state = machine seems that it's difficult for both peers to get a consistent view o= f what each side thinks that the

open peer streams have. The peer should only release the r= etransmission buffers when it knows all of the data + FIN has been ACKe= d, and I think that's when it should release

the stream limit. However the initiator needs = to know when this happens so it would need to keep track of the ACKs for the ACKs it sent. Unid= irectional streams seem to make this simpler.


>To be put precisely, the concurrency limit can be defined= as =93the max number of streams with non-zero unACKed bytes sent by that p= eer=94.


I'm not sure I understand your meaning = here or maybe I'm confused by what you consider as the peer. 
Can't the initiator just send a FIN and= get an ACK for the FIN, however never ACK the peer's frames? In this case the initiator would have "zero UNACKed bytes" = but the peer would not.

Subodh

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Thursday, March 23, 2017 11:27:29 AM
To: Subodh Iyengar; Martin Thomson
Cc: quic@ietf.org
Subject: RE: FIN + RST behavior
 

Concurrency limit is about the amount of local res= ources a remote peer can consume.  It is not about how much local reso= urces can be consumed by the local application =96 these limits can be enforced without any help from the protocol.

 

So concurrency limit is really the number of concu= rrent in-progress streams that a peer is willing to receive.  This map= s well with unidirectional streams, but this is not a requirement.  To be put precisely, the concurrency limit can be def= ined as =93the max number of streams with non-zero unACKed bytes sent by th= at peer=94.  This means, peers can negotiate separate concurrency limi= ts.

 

-  &nbs= p;       Igor

 

From: Subodh Iyengar [mailto:subod= h@fb.com]
Sent: Thursday, March 23, 2017 1:09 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

= >  The client can consider its own resource= s to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

Ya in the case of the previous example, it is a server resource s= ince it's a client initiated stream. 
@Mart= in Thomson I'm starting to like your proposal of unidirecti= onal streams more and more :)

=  

Subodh

=  

From: QU= IC <quic-bounces@ietf.org&g= t; on behalf of Martin Thomson <martin.thomson@gmail.com>
Sent: Thursday, March 23, 2017 4:04:46 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com> wrote:
> How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it s= ends
> out the FIN because it still must keep state until it receives all the=
> ACKs for the stream. I think the client need to keep track of the ACK = of the
> ACKs of all the server sent bytes in the stream, which would be a bit = sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

--_000_MWHPR15MB1455388350826978E960683DB6300MWHPR15MB1455namp_-- From nobody Sun Mar 26 21:32:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96307128BE1 for ; Sun, 26 Mar 2017 21:32:13 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHbpN6qLb1zX for ; Sun, 26 Mar 2017 21:32:10 -0700 (PDT) Received: from mx0b-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 02F50126CD8 for ; Sun, 26 Mar 2017 21:32:09 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2R4RMAL027943; Mon, 27 Mar 2017 05:32:08 +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=jfSVCEHN/lEnevvFr36iu0Gt6dsGrv2VZ9IHENcrGQ4=; b=JXs9/tu8zoOWP1a4+GhUjkJWfQQSYNJ4f/dPztAfNRhob++Ncq0JQiHX+DeVBphTNxuP WlIqiB+vYlvJ/aYUiD98IIlKDoH7zPVcff25Ja21s/cTxUFcGQvDhK+n1O6USvpO8Zuw lTI40ZUXZ0udyV8HCrfpFS7B7rBxuRGwkD85WbLgbQ6uN1Qn649FiqOZQHadNJEym6Lu 4iKQfWjGcoSYmyjIBbc2tW2e3PZ5WexFl7Fl/ICP+XxcjHKANANwLDCN0/Dk40hUL6N5 9V7+LOqykASRxiFnxiW6BqZ0vA5rOxvswhWENnbrNUIzRxBxRlEXTbNsKUKG5SK6v9jh cQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 29dgpqqf8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2017 05:32:08 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2R4QCDJ013909; Mon, 27 Mar 2017 00:32:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 29dkvu8mps-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2017 00:32:06 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 26 Mar 2017 21:32:05 -0700 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.1178.000; Mon, 27 Mar 2017 00:32:05 -0400 From: "Lubashev, Igor" To: Subodh Iyengar , "martin.thomson@gmail.com" CC: "quic@ietf.org" Subject: RE: FIN + RST behavior Thread-Topic: FIN + RST behavior Thread-Index: AQHSo1zPcZTZN/tlZkuJR+NHZURtjKGh2eCAgAA5O4CAAHPJAIAAZdGA///G0xCAAPb5gIAASu9pgAPln4D//+nl0A== Date: Mon, 27 Mar 2017 04:32:05 +0000 Message-ID: <5ff7c87db6294103ad0baae2f94dee8a@usma1ex-dag1mb5.msg.corp.akamai.com> References: , , <8dde9f5fac4440a8ac6c04e27efc042f@usma1ex-dag1mb5.msg.corp.akamai.com>, , <250e9b58e5294fca8e5a7e7a4c3643c8@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.106] Content-Type: multipart/alternative; boundary="_000_5ff7c87db6294103ad0baae2f94dee8ausma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270037 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_04:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270037 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 27 Mar 2017 04:32:14 -0000 --_000_5ff7c87db6294103ad0baae2f94dee8ausma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the record, I was not trying to describe my understanding of the curren= t stream limit, just my thinking of what it should be. >> We are only protecting reassembly buffers here > Isn't that what the connection flow control window and the stream flow co= ntrol window is for? You are correct that connection flow control window protects the aggregate = amount of data committed to the reassembly buffers. The max number of conc= urrent streams controls the number of reassembly buffers (supposedly, there= could be significant fixed costs per reassembly buffer). >> while there are any unacked sent bytes. Yes, I withdraw that alternative and would go with something like "streams = that have sent any bytes and (have unacked bytes or RST_STREAM or if there = was no STREAM+FIN sent)". The size or number of write buffers should not be controlled by some static= pre-negotiated number. This is likely to be something that the sender can= (and will want to) control dynamically (just like write buffers are contro= lled dynamically by the kernel under memory pressure). - Igor From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Sunday, March 26, 2017 3:27 PM To: Lubashev, Igor ; martin.thomson@gmail.com Cc: quic@ietf.org Subject: Re: FIN + RST behavior > We are only protecting reassembly buffers here Isn't that what the connection flow control window and the stream flow cont= rol window is for? > must count the stream toward his concurrency limit while there are any un= acked sent bytes. (By peer, I mean "an endpoint".) If this is the correct interpretation of how concurrency limit is accounted= for in the current draft, then it seems like it provides is no better prot= ection than the flow control window. The real value of a stream concurrency limit would be to be able to protect= the stream state table and to allow senders to protect their write buffers= . Sure, senders can slow themselves down, however putting that local limit = on yourself is another complexity in addition to the other sender side limi= ts like congestion control, and a tradeoff between throughput and buffer bu= ild-up. It seems like the draft could benefit from is explicit signaling of the ava= ilable concurrent limit similar to the flow control window which is explici= tly signaled. Then we can actually have the peer advertise a concurrent lim= it whenever it feels like it's ready to receive more streams, which would m= ake this way easier to account for resource usage in the state table and al= low the receiver to expand this limit in the future. Subodh ________________________________ From: Lubashev, Igor > Sent: Friday, March 24, 2017 5:56:41 AM To: martin.thomson@gmail.com; Subodh Iyeng= ar Cc: quic@ietf.org Subject: RE: FIN + RST behavior I am not thinking about it from the perspective of the initiator of a strea= m. I am really thinking about a stream having two independent directions. I= t is the sender of the bytes (on a stream initiated by him or by the peer, = does not matter) that must count the stream toward his concurrency limit wh= ile there are any unacked sent bytes. (By peer, I mean "an endpoint".) The management of retransmit buffers is a local concern of the sender. If t= he buffers grow too large, the local app would not get a chance to write mo= re into them. We are only protecting reassembly buffers here. If we also wa= nt to protect a table containing state for active streams, we would need to= modify the definition for concurrent streams to "number of streams that th= is endpoint has sent any data on and still have unacked data or fin, or una= cked rst". - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Friday, 24 Mar 2017, 12:28AM To: Lubashev, Igor [ilubashe@akamai.com]; Martin Thomson [martin.thomson@gm= ail.com] CC: quic@ietf.org [quic@ietf.org] Subject: Re: FIN + RST behavior @Lubashev, Igor >Concurrency limit is about the amount of local resources a remote peer can= consume. Let's say that for every stream there is an initiator (who is subject to st= ream limit) and a peer. Aren't the retransmission buffers which the peer has to hold onto until the= initiator ACKs them also a part of the local resources here? An initiator who doesn't ACK any bytes from the server forces a peer to kee= p state for it. However it could send it's own FIN which is ACKed normally. My question generally here is that with the current state machine seems tha= t it's difficult for both peers to get a consistent view of what each side = thinks that the open peer streams have. The peer should only release the retransmission buf= fers when it knows all of the data + FIN has been ACKed, and I think that's= when it should release the stream limit. However the initiator needs to know when this happens so = it would need to keep track of the ACKs for the ACKs it sent. Unidirectiona= l streams seem to make this simpler. >To be put precisely, the concurrency limit can be defined as "the max numb= er of streams with non-zero unACKed bytes sent by that peer". I'm not sure I understand your meaning here or maybe I'm confused by what y= ou consider as the peer. Can't the initiator just send a FIN and get an ACK for the FIN, however nev= er ACK the peer's frames? In this case the initiator would have "zero UNACK= ed bytes" but the peer would not. Subodh ________________________________ From: Lubashev, Igor > Sent: Thursday, March 23, 2017 11:27:29 AM To: Subodh Iyengar; Martin Thomson Cc: quic@ietf.org Subject: RE: FIN + RST behavior Concurrency limit is about the amount of local resources a remote peer can = consume. It is not about how much local resources can be consumed by the l= ocal application - these limits can be enforced without any help from the p= rotocol. So concurrency limit is really the number of concurrent in-progress streams= that a peer is willing to receive. This maps well with unidirectional str= eams, but this is not a requirement. To be put precisely, the concurrency = limit can be defined as "the max number of streams with non-zero unACKed by= tes sent by that peer". This means, peers can negotiate separate concurren= cy limits. - Igor From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Thursday, March 23, 2017 1:09 PM To: Martin Thomson > Cc: quic@ietf.org Subject: Re: FIN + RST behavior > The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. Ya in the case of the previous example, it is a server resource since it's = a client initiated stream. @Martin Thomson I'm starting to like your = proposal of unidirectional streams more and more :) Subodh ________________________________ From: QUIC > on behalf = of Martin Thomson > Sent: Thursday, March 23, 2017 4:04:46 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: FIN + RST behavior On 23 March 2017 at 15:10, Subodh Iyengar > wrote: > How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it send= s > out the FIN because it still must keep state until it receives all the > ACKs for the stream. I think the client need to keep track of the ACK of = the > ACKs of all the server sent bytes in the stream, which would be a bit sad= . The client can consider its own resources to be available for use by the server as soon as it receives the FIN and processes it. If this were a server resource, then you are right, it's not that simple because the client can't assume that the server has released state yet. --_000_5ff7c87db6294103ad0baae2f94dee8ausma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the record, I was not trying to describe my und= erstanding of the current stream limit, just my thinking of what it should = be.

 

>> We are onl= y protecting reassembly buffers here
> Isn't that what the connection flow control window and the stream flow= control window is for?

 

You are correct that connection flow control window= protects the aggregate amount of data committed to the reassembly buffers.=   The max number of concurrent streams controls the number of reassembly buffers (supposedly, there could be significant f= ixed costs per reassembly buffer).

 

 

>> while there are any unacked sent bytes.

 

Yes, I withdraw that alternative and would go with = something like “streams that have sent any bytes and (have unacked by= tes or RST_STREAM or if there was no STREAM+FIN sent)”.

 

 

The size or number of write buffers should not be c= ontrolled by some static pre-negotiated number.  This is likely to be = something that the sender can (and will want to) control dynamically (just like write buffers are controlled dynamically by the ker= nel under memory pressure).

 

-     &= nbsp;    Igor

 

 

From: Subodh Iyengar [mailto:subodh@= fb.com]
Sent: Sunday, March 26, 2017 3:27 PM
To: Lubashev, Igor <ilubashe@akamai.com>; martin.thomson@gmail= .com
Cc: quic@ietf.org
Subject: Re: FIN + RST behavior

 

> We are only pr= otecting reassembly buffers here
Isn't that what the connection flow control window and the stream flow cont= rol window is for?

 

> must count the= stream toward his concurrency limit while there are any unacked sent bytes= . (By peer, I mean "an endpoint".)

If this is the correct interpretation of how concurrency limit is= accounted for in the current draft, then it seems like it provides is no b= etter protection than the flow control window. 

The real value of a stream concurrency limit would be to be able to protect= the stream state table and to allow senders to protect their write&nb= sp;buffers. Sure, senders can slow themselves down, however putting th= at local limit on yourself is another complexity in addition to the other sender side limits like congestion control, = and a tradeoff between throughput and buffer build-up.

It seems like the draft could benefit from is explicit signaling of the ava= ilable concurrent limit similar to the flow control window which is ex= plicitly signaled. Then we can actually have the peer advertise a concurren= t limit whenever it feels like it's ready to receive more streams, which would make this way easier to account = for resource usage in the state table and allow the receiver to e= xpand this limit in the future. 

 

Subodh=

From: Lubash= ev, Igor <ilubashe@akamai= .com>
Sent: Friday, March 24, 2017 5:56:41 AM
To: martin.tho= mson@gmail.com; Subodh Iyengar
Cc: quic@ietf.org
Subject: RE: FIN + RST behavior

 

I am not= thinking about it from the perspective of the initiator of a stream. I am = really thinking about a stream having two independent directions. It is the sender of the bytes (on a stream initiated by him or= by the peer, does not matter) that must count the stream toward his concur= rency limit while there are any unacked sent bytes. (By peer, I mean "= an endpoint".)

The management of retransmit buffers is a local concern of the sender. If t= he buffers grow too large, the local app would not get a chance to write mo= re into them. We are only protecting reassembly buffers here. If we also wa= nt to protect a table containing state for active streams, we would need to modify the definition for concu= rrent streams to "number of streams that this endpoint has sent any da= ta on and still have unacked data or fin, or unacked rst".

- Igor

-----Original Message-----
From: Subodh Iyengar [subodh@fb.com]
Received: Friday, 24 Mar 2017, 12:28AM
To: Lubashev, Igor [ilubashe@akamai.com]; Martin Thomson [martin.tho= mson@gmail.com]
CC: quic@ietf.org [quic@ietf.org]
Subject: Re: FIN + RST behavior

@Lubashev, Igor

 

>Concurrency limit = is about the amount of local resources a remote peer can consume.  

 

Let's say that for every stream there is an initiator (wh= o is subject to stream limit) and a peer. 
Aren't the retransmission buffers which the peer has to hold onto unti= l the initiator ACKs them also a part of the local resources here?

 

An initiator who doesn't ACK any bytes from the server fo= rces a peer to keep state for it. However it could send it's own FIN which = is ACKed normally.

 

My question generally here is that with the current state= machine seems that it's difficult for both peers to get a consistent view = of what each side thinks that the

open peer streams have. The peer should only release the = retransmission buffers when it knows all of the data + FIN has been ACK= ed, and I think that's when it should release

the stream limit. However the initiator needs to kno= w when this happens so it would need to keep track of the ACKs for the ACKs= it sent. Unidirectional streams seem to make this simpler.

<= br> >To be put precisely, the concurrency limit can be= defined as “the max number of streams with non-zero unACKed bytes se= nt by that peer”.

 

I'm not sure I understand your meaning here or maybe I'm= confused by what you consider as the peer. 

Can't the initiator just send a FIN and get an ACK for t= he FIN, however never ACK the peer's frames? In this case the initiator&nbs= p;would have "zero UNACKed bytes" but the peer would not.

 

Subodh

From: Lubash= ev, Igor <ilubashe@akamai= .com>
Sent: Thursday, March 23, 2017 11:27:29 AM
To: Subodh Iyengar; Martin Thomson
Cc: quic@ietf.org
Subject: RE: FIN + RST behavior

 

Concurrency limit is about the amount of local reso= urces a remote peer can consume.  It is not about how much local resou= rces can be consumed by the local application – these limits can be enforced without any help from the protocol.

 

So concurrency limit is really the number of concur= rent in-progress streams that a peer is willing to receive.  This maps= well with unidirectional streams, but this is not a requirement.  To be put precisely, the concurrency limit can be def= ined as “the max number of streams with non-zero unACKed bytes sent b= y that peer”.  This means, peers can negotiate separate concurre= ncy limits.

 

-        &n= bsp; Igor

 

 

On 23 March 2017 at 15:10, Subodh Iyengar <subodh@fb.com> wrote:
> How does the client know when the server has released a slot in it's > concurrency limit? The server can't immediately release this when it s= ends
> out the FIN because it still must keep state until it receives all the=
> ACKs for the stream. I think the client need to keep track of the ACK = of the
> ACKs of all the server sent bytes in the stream, which would be a bit = sad.


The client can consider its own resources to be available for use by
the server as soon as it receives the FIN and processes it.  If this were a server resource, then you are right, it's not that simple
because the client can't assume that the server has released state
yet.

--_000_5ff7c87db6294103ad0baae2f94dee8ausma1exdag1mb5msgcorpak_-- From nobody Mon Mar 27 03:36:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EB5120326 for ; Mon, 27 Mar 2017 03:36:47 -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, 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 mbSjdr4ty9T0 for ; Mon, 27 Mar 2017 03:36:44 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F511294E6 for ; Mon, 27 Mar 2017 03:36:42 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 30E3C340E10; Mon, 27 Mar 2017 12:36:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.19757); Mon, 27 Mar 2017 12:36:40 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 27 Mar 2017 12:36:40 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 12678042; Mon, 27 Mar 2017 12:36:40 +0200 Subject: Re: on packet number echo Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E15591A6-B6D4-4F58-B5FA-D7C6B4F5578B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Mon, 27 Mar 2017 12:36:41 +0200 Cc: "ianswett@google.com" , "quic@ietf.org" Message-Id: References: To: Marcus Ihlar X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 27 Mar 2017 10:36:47 -0000 --Apple-Mail=_E15591A6-B6D4-4F58-B5FA-D7C6B4F5578B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Marcus, > On 26 Mar 2017, at 21:37, Marcus Ihlar = wrote: >=20 > Hi, > The issue I have with option 1 is that that many endpoints mainly = receive data and only rarely transmit ack:able frames. Such endpoints = will likely have outdated RTT-estimates. This could lead to echoes = being transmitted more than once per RTT (not a problem), but the = opposite could be true as well given the levels of jitter we observe in = e.g cellular networks. >=20 Quoting Ian's note from Github on = https://github.com/quicwg/base-drafts/pull/391 for the list: > @britram I think it's ok to provide an RTT measurement less frequently = when little data is flowing. The removal of STOP_WAITING and acking acks = results in sending a retransmittable frame with an ack approximately = once per RTT. So both directions should get an RTT estimate = approximately once per RTT. Though I get your point about an RTT-driven echo (regardless of the = mechanism) being sensitive to large swings in RTT on short timescales. = Presumably, implementations in these situations could use more = aggressive RTT estimator smoothing regardless of echo, though... Cheers, Brian > //Marcus > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett > Sent: den 15 mars 2017 00:57 > To: Brian Trammell (IETF) > Cc: IETF QUIC WG > Subject: Re: on packet number echo >=20 > Thanks for summarizing this Brian. >=20 > The first option means that an implementation could not send the echo, = for example if a network was using it in a way that was harmful to = users. This provides an incentive for networks that do use it to either = do nothing active with it or use it to improve user experience. (see = Marcus Ihlar's thread for that) >=20 > I think the largest upside(or downside, depending upon your = perspective) of the second option where the largest acked is included = with every frame is that it means one MUST implement this correctly to = implement QUIC, at least if they want to use the standard ack frame. >=20 > Personally, my largest concern with the second case is that of = differential treatment of acks. What if an ack packet contains other = data, and a middlebox decides that only the most recent ack needs to be = delivered(a common TCP approach), so the data bundled with the ack is = inadvertently lost? >=20 > At this point, I lean towards the first option, because I understand = the implications better, but I could be convinced otherwise. >=20 > Either way, I think both of these are potentially worthy of including = and I think they're preferable to doing nothing. >=20 >=20 > On Tue, Mar 14, 2017 at 10:46 AM, Brian Trammell (IETF) = wrote: > Greetings, all, >=20 > for those not watching github, there's a discussion on packet number = echo; my summary post in PR#391 is reproduced below: >=20 > to summarize... there seem to be three possibilities emerging here: >=20 > ### Echo (at least) once per RTT. Leave ACK frames unchanged. >=20 > (This is what's written up in this PR). >=20 > Rationale: What happens in the frame layer stays in the frame layer. = Packet number echo is a pure packet-layer change to the transport = protocol. Since this is additional overhead, we should work to minimize = it, hence once per RTT, the minimum frequency that works for passive = latency measurement. >=20 > Upsides: It's a tiny change to the protocol as presently described, = for a low overhead cost per RTT (1-4 bytes, usually 2). The ACK frame = remains self-describing, so the ack frame handling component in an = implementation can remain separate from the packet handling component. = Endpoints can choose to echo more frequently (e.g., when configured to = do so for debugging purposes). >=20 > Downsides: an echoing endpoint with a passively-cooperative peer can = intentionally skew passive measurements, since the value in the packet = header is not necessarily joined to the value in the ack frame. The = utility and practicality of such a thing is debatable. It's not clear = how good the resulting number/echo stream will be for one-point loss and = reordering estimation. >=20 > ### Echo max-acked on every packet with an ACK frame, and remove it = from the ack frame. >=20 > Rationale: This information already appears in the ACK layer, so = there's no additional overhead. >=20 > Upsides: Echo frequency is higher; this should make loss and = reordering estimation work better at a single observation point. No = additional overhead. >=20 > Downsides: Increased complexity of implementations, which have to pass = packet number echo information up the stack. No endpoint control over = how often packet numbers are echoed, since max-ack is required by the = transport mechanisms. >=20 > Mixedsides (depending on your proclivities): The presence of an ACK = frame is now exposed to the path. ACK-frame-containing packets can (and = given the history of TCP, probably will) be treated differently by the = network in certain circumstances. >=20 > ### Don't echo packet numbers at all >=20 > (this is the no-build option) >=20 >=20 >=20 > Cheers, >=20 > Brian >=20 --Apple-Mail=_E15591A6-B6D4-4F58-B5FA-D7C6B4F5578B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY2Os5AAoJEIoSt78L6kajUasQAK1GeO2qFZ+mE2u+5fWi/OM9 LKp8Sl7ERb2da/IQmSADNmAsSd+k6i8YiRKsh91DGwxjfPJS+3/WkxKqZ6SKN5xi 2IxPmVbZNXTQ58azCyvpz4c8jPovxo94rLBixJsoPf/yKeVrPLyZzX+gcxCKFN7b 5BVCVsp44tFHHHolf3av7V2EwFFlnco5XYPWYRoElZxdX8wlhDnE1WLMVBWR76/Q VzdZjLK4cULcJzdxBPRvjhJIdkVT7p8RDbjAOtYasNAHeZ4QCchRgp5jNCD/r7mt yrdLE3LUCICf80zz4NL3D15ZGUssxFguLLB9lPEZe+AxZ8oPBXyzSSt4tYU4bolp +mDklJ/iQBTWSbuHyIc8cT9LZziwxZxrE1mkcr13n0zkz4uISoOVTKE5Wwq+JXHu z2DmQM1xmuXccfvjydd9C3HH6+vm82492C9I/fXuJfurVjv5HPOETOfdcop2oul6 E/KYN12U3cM4A4yEhpspkWPsUax+uC3y1l3d6AJ220IbJxFETbF4Jr9VbAHUPCm7 26H10cpxys0/wRkGiPWWm4XQicQd21IvC4/O6R7otAoFix/UYyOpX0gyDn66GYCc 5Ebwjz1Nnn2QJLZ0tM7tDy2Nio281skBunMonD8O2EBYsmb3OGAJNdkpVGnGAkht iGaX20nyG3L4DAYoweTl =/Idf -----END PGP SIGNATURE----- --Apple-Mail=_E15591A6-B6D4-4F58-B5FA-D7C6B4F5578B-- From nobody Mon Mar 27 11:56:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6265D12947E for ; Mon, 27 Mar 2017 11:56: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KLazLTVqd4VA for ; Mon, 27 Mar 2017 11:56:20 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFB6126C22 for ; Mon, 27 Mar 2017 11:56:20 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 190so64766953itm.0 for ; Mon, 27 Mar 2017 11:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3kjJQueKisVGkc9nm1KCSqdz3M4GdT0RJysNfT5AdZ0=; b=CrQ26qBRLohKGxnbgAkXpGyFgX2+Hst6yY8CViX68t4O6mRyCmsFz9/pXB4yacOr42 Fwoy+KCcABJyaKWHvAydzzz3E4mGqvTNF5Oofo6392dvhj23NoT7ALhecTwYXBaeHrWG RydBakWwpDs710gLTkLuP96X8yTug12qbm6v9KpRid4ai9dvvlQgJDmktZLrZBieXKVO raLpfQavyBa7F0mS44pIys4KXXvoEiKAp6xkXlGIOYRxJOb0wFOGCee3WbMeOF88qMtx xmZYfYWQ/hZfx3QQeTHrCvsxqAaB/w1PIcXOfb4bacw0NEJBXINJ1F6eYqWo0D67SmKf aF9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3kjJQueKisVGkc9nm1KCSqdz3M4GdT0RJysNfT5AdZ0=; b=rLUAmOrp9O8169R3tcgjYD77RTHmGT/1O9GWjl9Brb5NoN4KEvXssYWpqK2ZFOKr9F ZkGIU7/pecLeBoaWs1/XXBFMKYMkewq/i00xMaTvbxtJEfqzFjh7aok/BKXWU9pHkUwh 0ukXTzpdGIkng6egGjxgQE6XBiBIwq3VrEkyEjZYr8qwrgt9tzSInw9esIMrpTsmuJQa da0aeJJDotghoxfpgQO8MLMPct7TVNC+b4haOttazJUBu7zhh8D/gMWL35PTsSUsNTwH P6c4EVsnlyQ+661/MLzWlU/TC1ndntPiNPc8Nh/Ir2GdBCw94ElWQifJwaW/m617aSzz dJhA== X-Gm-Message-State: AFeK/H2G8RDbk2tZf0frkT6xoqJY4KnL8pOKkngn7ECm5fRrRDJaKqFWxEYbINwGWielijPlUqjxsK7JtEbHjXeL X-Received: by 10.107.11.215 with SMTP id 84mr21821607iol.41.1490640979106; Mon, 27 Mar 2017 11:56:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Mon, 27 Mar 2017 11:55:58 -0700 (PDT) In-Reply-To: <149064075827.30553.16052550201925667551.idtracker@ietfa.amsl.com> References: <149064075827.30553.16052550201925667551.idtracker@ietfa.amsl.com> From: "Charles 'Buck' Krasic" Date: Mon, 27 Mar 2017 11:55:58 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-krasic-quic-qcram-00.txt To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113f8a740c8a39054bbae6b4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 27 Mar 2017 18:56:22 -0000 --001a113f8a740c8a39054bbae6b4 Content-Type: text/plain; charset=UTF-8 FYI, I've submitted my draft. Apologies in advance if I've made mistakes, I'm a newbie to the IETF submissions process. ---------- Forwarded message ---------- From: Date: Mon, Mar 27, 2017 at 11:52 AM Subject: New Version Notification for draft-krasic-quic-qcram-00.txt To: Charles 'Buck' Krasic A new version of I-D, draft-krasic-quic-qcram-00.txt has been successfully submitted by Charles 'Buck' Krasic and posted to the IETF repository. Name: draft-krasic-quic-qcram Revision: 00 Title: Header Compression for HTTP over QUIC Document date: 2017-03-27 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-krasic-quic- qcram-00.txt Status: https://datatracker.ietf.org/doc/draft-krasic-quic-qcram/ Htmlized: https://tools.ietf.org/html/draft-krasic-quic-qcram-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-krasic-quic- qcram-00 Abstract: The design of the core QUIC transport and the mapping of HTTP semantics over it subsume many HTTP/2 features, prominent among them stream multiplexing and HTTP header compression. A key advantage of the QUIC transport is that provides stream multiplexing free of HoL blocking between streams, while in HTTP/2 multiplexed streams can suffer HoL blocking primarily due to HTTP/2's layering above TCP. However, assuming HPACK is used for header compression, HTTP over QUIC is still vulnerable to HoL blocking, because of how HPACK exploits header redundancies between multiplexed HTTP transactions. This draft defines QCRAM, a variation of HPACK and mechanisms in the QUIC HTTP mapping that allow QUIC implementations the flexibility to avoid header-compression induced HoL blocking. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a113f8a740c8a39054bbae6b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, I've submitted my draft. =C2=A0 Apologies in= advance if I've made mistakes, I'm a newbie to the IETF submission= s process.


---------- Fo= rwarded message ----------
From: <internet-draf= ts@ietf.org>
Date: Mon, Mar 27, 2017 at 11:52 AM
Subjec= t: New Version Notification for draft-krasic-quic-qcram-00.txt
To: Charl= es 'Buck' Krasic <ckrasic@= google.com>



A new version of I-D, draft-krasic-quic-qcram-00.txt
has been successfully submitted by Charles 'Buck' Krasic and posted= to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-krasic-quic-qcram
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Header Compression for HTTP over Q= UIC
Document date:=C2=A0 2017-03-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-krasic-quic-qcram-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-krasic-quic-qcram/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-krasic-quic-qcram-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-krasic-quic-qcram-00<= /a>


Abstract:
=C2=A0 =C2=A0The design of the core QUIC transport and the mapping of HTTP<= br> =C2=A0 =C2=A0semantics over it subsume many HTTP/2 features, prominent amon= g them
=C2=A0 =C2=A0stream multiplexing and HTTP header compression.=C2=A0 A key a= dvantage of
=C2=A0 =C2=A0the QUIC transport is that provides stream multiplexing free o= f HoL
=C2=A0 =C2=A0blocking between streams, while in HTTP/2 multiplexed streams = can
=C2=A0 =C2=A0suffer HoL blocking primarily due to HTTP/2's layering abo= ve TCP.
=C2=A0 =C2=A0However, assuming HPACK is used for header compression, HTTP o= ver
=C2=A0 =C2=A0QUIC is still vulnerable to HoL blocking, because of how HPACK=
=C2=A0 =C2=A0exploits header redundancies between multiplexed HTTP transact= ions.
=C2=A0 =C2=A0This draft defines QCRAM, a variation of HPACK and mechanisms = in the
=C2=A0 =C2=A0QUIC HTTP mapping that allow QUIC implementations the flexibil= ity to
=C2=A0 =C2=A0avoid header-compression induced HoL blocking.




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

The IETF Secretariat




--
Charles 'Buck' Kras= ic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141
<= br>
--001a113f8a740c8a39054bbae6b4-- From nobody Mon Mar 27 13:15:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCCC12962E for ; Mon, 27 Mar 2017 13:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuJQgiCh_lPT for ; Mon, 27 Mar 2017 13:15:37 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 D921012948E for ; Mon, 27 Mar 2017 13:15:35 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d10so43117516qke.1 for ; Mon, 27 Mar 2017 13:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dii56CWUI+03aQ1ppawYFaw/M8qs6rlg339IvnYgiB4=; b=GhE/moYvATg7Rz//LT3DI0PedT+caf8t6ggDA3lonuGSlsgY86hsy6WByLPGZ2FQDz h2RIV72HlxZW7K1BhJJO92fXLKZlMMKm59mq0hMDDJdVsSxWGCakn18EQq+dtJEJbaVQ GscLG2UR0Z41qHvK+dS/3G8Ri98A0ZOG5ZDA/dZLFfd700HuR9V3CeBD0mxmmFxcaw7B BiomggSHL1yTMgtW9Q3CDPTN5qs5jTJbVrD6Gmzlu1Y31esjHMYa1eTcME4WJKfxzKIZ 0pcU84lLLJb6dC5E7AeLiVFFNpqKDAbNm6SXu1YcZ0Q0TygQlwkk1/zLw+vwpArvMsfq iYzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dii56CWUI+03aQ1ppawYFaw/M8qs6rlg339IvnYgiB4=; b=kvcRBYioft9sN6C9tYNqMw5ZBeKIKUQb4NSZ6K46eRmA7HT+D3tESIwHCrtoxu0Ic6 zkz2vDknd2381MwCgwN3RxpHCD/qmvhqH8L8JQ8JPpuELf36SolSmzmvAFgbVKJOodMX Fce6OD6AF732jrGe4bJQu6DNVd9GZZ+PyhfLpENEWPtkeTnhGV2Ch5z76mdB8kaw15n5 uJ9Yp1ZJu2tJBHrnTkylFR2CyAYuOkVJNkHa6xugNiTkFa+z35nkwoLcyqziIR9hEHYA 9eswkickvQEldGd7Xdi1rODcrHFFGHkOspXDynm5Znb0KV+AxV9cpD2kPeaQ+6+VKFBr yGFw== X-Gm-Message-State: AFeK/H1gql3zqLMrSKK0/i5ww9QXvtclgETSvZmbzDdx2VkJzmKoVIdRl77uLadegtmx0zaaR4y89hRn7ntlxA== X-Received: by 10.55.176.135 with SMTP id z129mr21088871qke.308.1490645735106; Mon, 27 Mar 2017 13:15:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.41 with HTTP; Mon, 27 Mar 2017 13:15:34 -0700 (PDT) In-Reply-To: References: <149064075827.30553.16052550201925667551.idtracker@ietfa.amsl.com> From: "Aron ." Date: Mon, 27 Mar 2017 16:15:34 -0400 Message-ID: Subject: Re: New Version Notification for draft-krasic-quic-qcram-00.txt To: "Charles 'Buck' Krasic" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c06569486f0d1054bbc01ca Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 27 Mar 2017 20:15:38 -0000 --94eb2c06569486f0d1054bbc01ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHello Buck, One unmentioned impact of QCRAM is that to use Rules 1 and 2, header data must be kept somewhere until packets are generated. In other words, copied. In comparison, when HPACK is used, headers can be compressed as soon as they are generated and take up much less memory while they wait to be copied into outgoing packets. Aron. --94eb2c06569486f0d1054bbc01ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHello Buck,

One unm= entioned impact of QCRAM is that to use Rules 1 and=C2=A02,=C2=A0header dat= a must be kept somewhere until packets are generated.=C2=A0 In other words,= copied.=C2=A0 In comparison, when HPACK is used, headers can be compressed= as soon as they are generated=C2=A0and take up much less memory while they= wait to be copied into outgoing packets.

=C2=A0 A= ron.
--94eb2c06569486f0d1054bbc01ca-- From nobody Mon Mar 27 14:13:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52541129676 for ; Mon, 27 Mar 2017 14:13:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RriOUV7wdITq for ; Mon, 27 Mar 2017 14:13:51 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 4C2C212967B for ; Mon, 27 Mar 2017 14:13:51 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y18so90992552itc.0 for ; Mon, 27 Mar 2017 14:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W05YSxrmfUQxNys0wPSHvqbH9ncCw/V3r5oV2xY3G+o=; b=PmiLGIE/QmKyhgeJQEV59dlX9Bhrn3/k4nlopK6d8MeBTHfztIoA/2BDp7rMdgj5Za ltumRczrXBlR2ASG4nXPrIg+85Z31Fg9qnUPgNGrUx4mqhOghlwWdGaiz2JsWissPFtE ZQMvZJ+nDCqiN6eEY4nxHSSTt6WnG74H+DY1QxGVj9ie2yXMLWWg/B21zNFZXwnybAN5 7J2Fb/5NRWjNH3JLMLfexf2+qe5IJmpXkIEmdoa8g+jUX5mWkXRxjI8f7/9H+OYcE8S8 d3RZbhNdOHu9WFFcVI4AmvaQlezkqlnF2zKVFu48rjZTQvnKfzh0U9Q3fRGSHs1cftnj /JsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W05YSxrmfUQxNys0wPSHvqbH9ncCw/V3r5oV2xY3G+o=; b=nWFz8TVqYjpNOwVzAnwVXK/MPL7lou/fWL7H78+FZNWF2hxgPQo1biagU9ybaqnJhU m7cRa3l/UTHN0osDIx3ldy9pqT+qLRG++RwJq0N6UU71xEGxaFcN9rx1vHQMM8r1nTDS BtHsbWarA6RcwFavvi5faHHUuVWhCM8Sje3dk8Dg8xSRyEFdpz3habMhWwUcw7OVqB4a VLNFVTUyl56sI2ZkHs/Uh90D7SauMtC6AmS7iq1DHPIBlO1Lupf57YgzRHWrE8AOTKnX TspGeIOjCz+ZY5g29q0ckgMzCCrkQyQaqivTvFJ3Iq7tFtHx3ECVgZhlki+clbBh0a7j yplA== X-Gm-Message-State: AFeK/H11pSvMVjjFSEQOxhYsCNXt+ngBMclraQVrtoDfBV0xesfgNjIIsi7w/Y0wTs0NJ/y1D6blXc5y9RHTEI5v X-Received: by 10.36.17.211 with SMTP id 202mr12415794itf.98.1490649230577; Mon, 27 Mar 2017 14:13:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Mon, 27 Mar 2017 14:13:30 -0700 (PDT) In-Reply-To: References: <149064075827.30553.16052550201925667551.idtracker@ietfa.amsl.com> From: "Charles 'Buck' Krasic" Date: Mon, 27 Mar 2017 14:13:30 -0700 Message-ID: Subject: Re: New Version Notification for draft-krasic-quic-qcram-00.txt To: "Aron ." Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1143e796e030d7054bbcd19a Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 27 Mar 2017 21:13:53 -0000 --001a1143e796e030d7054bbcd19a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 27, 2017 at 1:15 PM, Aron . wrote: > =E2=80=8BHello Buck, > > One unmentioned impact of QCRAM is that to use Rules 1 and 2, header data > must be kept somewhere until packets are generated. > Agree. Although I think there might be scenarios like crazy huge header blocks where progressive encoding could conceivably reduce memory footprint, because the headers could be handled in a streaming fashion. > In other words, copied. > Not necessarily. If QCRAM takes or shares ownership of the original header data, then an extra copy would not be needed. > In comparison, when HPACK is used, headers can be compressed as soon as > they are generated and take up much less memory while they wait to be > copied into outgoing packets. > Perhaps, but its not clear to me whether this would be a significant overall memory impact. My gut instinct is that it would be not rise to the level of a first order memory issue, I'd imagine caches and send/receive buffers would be much larger. I agree that I should mention potential implications on memory footprints. Thanks for pointing it out. > > Aron. > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1143e796e030d7054bbcd19a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 27, 2017 at 1:15 PM, Aron . <aron.schats@gmail.com> wrote:
=E2=80=8BHello Buck,

One unmentioned impact of Q= CRAM is that to use Rules 1 and=C2=A02,=C2=A0header data must be kept somew= here until packets are generated.=C2=A0

<= /div>
Agree. =C2=A0

Although I think there mig= ht be scenarios like crazy huge header blocks where progressive encoding co= uld conceivably reduce memory footprint, because the headers could be handl= ed in a streaming fashion.
=C2=A0
In other words, copied.=C2=A0

Not necessarily. =C2=A0 If QCRAM takes or shares = ownership of the original header data, then an extra copy would not be need= ed.
=C2=A0
In comparison, when HPACK is used, headers can be compressed as soo= n as they are generated=C2=A0and take up much less memory while they wait t= o be copied into outgoing packets.

<= div>Perhaps, but its not clear to me whether this would be a significant ov= erall memory impact. =C2=A0 My gut instinct is that it would be not rise to= the level of a first order memory issue, =C2=A0I'd imagine caches and = send/receive buffers would be much larger. =C2=A0 =C2=A0=C2=A0



-- <= br>
Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0= ckrasic@google.com<= /a>=C2=A0|=C2=A0+1 (408) 412-11= 41

--001a1143e796e030d7054bbcd19a-- From nobody Tue Mar 28 05:33:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12131129504 for ; Tue, 28 Mar 2017 05:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0Hi1xsQQyOJ for ; Tue, 28 Mar 2017 05:33:40 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D164C129522 for ; Tue, 28 Mar 2017 05:33:39 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id r142so34805008qke.2 for ; Tue, 28 Mar 2017 05:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/1vh3CwWaYKy1SgqjmguIq4OWr+o2C70AoSeRhLcxIk=; b=ioT6zRtjug8LM3c+wiIsCorMzzjxESIQ0NCFDC0Ku8X+ySMJMzo1wttbdwRIl2L77h v1X7yk873Y+d/sHJf687yfPpKavpB4f61r43FsHqiCCr3WxE7HSzzxMHFp8IHHzOgztX RsW/6Kuvvram+ovctMKBCQz86L0EdFYRoX/AZAOXuKfMlW6g8fGm0YA72UHuk306JrQS +tETOI1gD3nJukXLYnMh/2k1mLufizH+PEl/7ZelS56F6uYc5PBTmI9lnvHdnWMdcu1R BChsyXkwjbK2U21T72l0RFJ3TaLU/Akkve0BHpKCpwOFmQzCmN3TYRUs6e9fw3zm/eg5 aD5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/1vh3CwWaYKy1SgqjmguIq4OWr+o2C70AoSeRhLcxIk=; b=Z31splqFyCxEpGmeBMs9fpk41b0w54bjIIrc/KDzIC5xZfDHWhRl+ZIFwWKbPdvccn UeDrthtS+DIYtbTQvaFDaIx9wXI0YkutcjXGaA37w/AX8w4tfP8EEhOhXNJqKjvHgib/ +CT5Zv8xszLZRd0ETUwWPFcyieaTa8IQgjHluHxCP7UgahG8KchqJXXvD8/ZinKTpXQj LU6D6Ii2hgLlHaUjErgOFkV40HOF8jJ9Y3PdwpPKqkZFk/f+D7ul19I57ulGsDwS/imn vK/jsK2j+fpR0v9xKyUQXIZxudRt4sJXpZPTDwof9XoE0+xdihCdcrK2X6Z3J/RAT7DA uDig== X-Gm-Message-State: AFeK/H1M1+SR/S5Wx0HoLp4bDXX1HsTnXXmF52DhtGwW2dOQuuS8Jp3aYdLaFMwzmWd6dzw7xdPvE29ANjfxCg== X-Received: by 10.55.67.66 with SMTP id q63mr4906963qka.49.1490704418984; Tue, 28 Mar 2017 05:33:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.41 with HTTP; Tue, 28 Mar 2017 05:33:38 -0700 (PDT) In-Reply-To: References: <149064075827.30553.16052550201925667551.idtracker@ietfa.amsl.com> From: "Aron ." Date: Tue, 28 Mar 2017 08:33:38 -0400 Message-ID: Subject: Re: New Version Notification for draft-krasic-quic-qcram-00.txt To: "Charles 'Buck' Krasic" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114abf885bfa59054bc9ab27 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 12:33:42 -0000 --001a114abf885bfa59054bc9ab27 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 27, 2017 at 5:13 PM, Charles 'Buck' Krasic wrote: > On Mon, Mar 27, 2017 at 1:15 PM, Aron . wrote: > In other words, copied. > > Not necessarily. If QCRAM takes or shares ownership of the original > header data, then an extra copy would not be needed > True, but that would likely complicate the API (I am thinking of code that uses a QUIC library). In other words, no free lunch. --001a114abf885bfa59054bc9ab27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 27, 2017 at 5:13 PM, Charles 'Buck' Krasic <ckrasic@googl= e.com> wrote:
On Mon, Mar 27, 2017 at 1= :15 PM, Aron . <aron.schats@gmail.com> wrote:In other words, copied.=C2=A0

Not necessarily. = =C2=A0 If QCRAM takes or shares ownership of the original header data, then= an extra copy would not be needed

True, but that would=C2=A0likely complicate the=C2=A0API (= I am thinking of=C2=A0code that uses a QUIC library).=C2=A0 In other words,= no free lunch.

--001a114abf885bfa59054bc9ab27-- From nobody Tue Mar 28 10:59:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4443612973E for ; Tue, 28 Mar 2017 10:59:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MUKv_0B5UQSp for ; Tue, 28 Mar 2017 10:59:45 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103ED129471 for ; Tue, 28 Mar 2017 10:59:44 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id y18so29274517itc.1 for ; Tue, 28 Mar 2017 10:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8ms3w0IHUJyoggFK8K3xHTRwkKH2Vk4LY62kzc6YDz4=; b=CRaCOaXEYxGQiPxQi+AK6nuJVHKnPtl+7uQwSIf3jChgun2P2oQIuhMbSXs4cZ0MoA sB91KDcN/COllDDuXcNlN1U3sTVpZ2OG0esx5p+lXXyka1hvqgWu4tzQ9+gk0135sAgE SHMOdRXSCwD4nVmEmZjHb5GdhgvA3ApkYTdcGJP2S1Eq8Yg33LXJCXs7zNLaKYqaYnRu qXGh66Zs9JA1kkk5W9uzwPmmex3rHQCahuuLHKcX+XL8tg5tJmEUVsBrqmsyFfUZDKXx SCumQ3KXcb9kD2w9AA9jSqgsQOIeLxB7r+cUzEDrvTAV7K0gv+lfTXrW3B9MsXBtGDSl zwFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8ms3w0IHUJyoggFK8K3xHTRwkKH2Vk4LY62kzc6YDz4=; b=fU2YT/eyv4vZIzs8kDdrnZQk80X/40wTxPAGLmPF84QJTXBeEmPCCjylWsWUDx0gRG tFP6X0+amdj0FNzAKVMiD5KQntukZdsOTxAqO9fOdNYZgdKzTfDFY7g2HKE0DgsNVJ0T mmnvt0MByS59+4Wa9F44CKjEdx8F4GclyEVjF3P59w77K5vKzBr3YDInWgYaxFT2fh9+ 2HhMWpd11jnCbju82B2Ij2xyCYzNtiLMmJ007eoPsQxH5l+BaD4H6xuLKaOGVKtIBlhz 9B6Fnf2GEDv14OlpCZNYLutLoDrqtbfLdNfjlhDSH0s38wyEQIHlQ2r6qDicWsltxz4H KCgA== X-Gm-Message-State: AFeK/H04CYr4NVyGTjguX8UeZCX7J0vAvyIsWsRZyPJNcrKRG1zhgQoDPPO/g6iUjIT83suFOY9fXd6pXAv/TuZf X-Received: by 10.107.164.36 with SMTP id n36mr26861149ioe.103.1490723983178; Tue, 28 Mar 2017 10:59:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Tue, 28 Mar 2017 10:59:22 -0700 (PDT) In-Reply-To: References: <149064075827.30553.16052550201925667551.idtracker@ietfa.amsl.com> From: "Charles 'Buck' Krasic" Date: Tue, 28 Mar 2017 10:59:22 -0700 Message-ID: Subject: Re: New Version Notification for draft-krasic-quic-qcram-00.txt To: "Aron ." Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114220ac7a2621054bce3948 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 17:59:47 -0000 --001a114220ac7a2621054bce3948 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 28, 2017 at 5:33 AM, Aron . wrote: > On Mon, Mar 27, 2017 at 5:13 PM, Charles 'Buck' Krasic > wrote: > >> On Mon, Mar 27, 2017 at 1:15 PM, Aron . wrote: >> In other words, copied. >> >> Not necessarily. If QCRAM takes or shares ownership of the original >> header data, then an extra copy would not be needed >> > > True, but that would likely complicate the API (I am thinking of code that > uses a QUIC library). In other words, no free lunch. > > Maybe or maybe not. Just as one data point, the interface in chromium takes ownership of the header data, here is a source code link . -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a114220ac7a2621054bce3948 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 28, 2017 at 5:33 AM, Aron . <aron.schats@gmail.com> wrote:
On Mon,= Mar 27, 2017 at 5:13 PM, Charles 'Buck' Krasic &= lt;ckrasic@google.c= om> wrote:
On = Mon, Mar 27, 2017 at 1:15 PM, Aron . <aron.schats@gmail.com> wrote:
In other words, copied.=C2= =A0

Not necessarily. =C2=A0 If QCRAM takes or shar= es ownership of the original header data, then an extra copy would not be n= eeded

True,= but that would=C2=A0likely complicate the=C2=A0API (I am thinking of=C2=A0= code that uses a QUIC library).=C2=A0 In other words, no free lunch.
<= /div>
Maybe or maybe not.=C2=A0 Just as one data point, =C2=A0= the interface in chromium takes ownership of the header data, here is a source code link.


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

--001a114220ac7a2621054bce3948-- From nobody Tue Mar 28 15:10:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11411271DF for ; Tue, 28 Mar 2017 15:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIJEAIQTmFH1 for ; Tue, 28 Mar 2017 15:10:06 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2E51294B0 for ; Tue, 28 Mar 2017 15:10:06 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r203so47288554oib.3 for ; Tue, 28 Mar 2017 15:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ve1Wb41ipZGHFFmdcpiBtb38lYHVnUQYGgEprcQH/zE=; b=JjSq1QfQWi5IpFapseFEXPwsditoUDOBhwIalx6vnKUL1ge4QGkU5O/psrfIB1UyFA WoAKC6TYnW8NTK1ITn3W0eNr03Jcxf/vRjXxVLmcQs/bUXfPCyVO0+s+BPb1kNk+/5ki HGkqNocrMFY83f44prcPxEJrdkq+Ls/IVC+CTX5eJ9qMvdm3Gq6dia3LVlyfIeUUwqGP pD27U7xb/7/HPv1O8u2XBIf8Rj9yZv1u79etVPLMiHM3zz7ydT0cjQB8pbGt5EdFLCsz LJAj0ZB3yRUtAKXeP/CDb5lQ/LxjiT/u7jt1vzfsD5jFP77+IkPzyAPd2I3exmXQQzD6 xpyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ve1Wb41ipZGHFFmdcpiBtb38lYHVnUQYGgEprcQH/zE=; b=uoIxnXRTBz/TJZCSp/kX4zamD0RVdTaicjuJ/MSNmwR9QX4dqSjgWNGIhx5VdGYzpB ihOyo2518q3wz3euYc52ttHFkZgwli+67xxsV6uFP8asNXUfQ15xVZl7oSk6A3Ilmxvo LNvQhKThxop0MB4FcjSF1NOw+tTk2YywfjzUO39814pVUB628RLz+lL1yDnpnLS3rOQE lmpgOMC9YT45tvt2WMrkQMduTmx0U96CCyRgGLncLp2qUSuOdb7X3XVyE8rMknT6poAi 6NTgcPF+p9ig6F0DwjEUu/0a4m9df6dtGu/03tnVoENZ6ld2ba2X/Ew4ei8AF2JV9pYs 5iIw== X-Gm-Message-State: AFeK/H0whu8NeKfzbw71QFyw+jR83FyZNP3TT5B+nKZhVevbESi7+Y984rnCoZlU8H4YD7StNGZafLAf87k0ow== X-Received: by 10.202.53.212 with SMTP id c203mr14239916oia.215.1490739005897; Tue, 28 Mar 2017 15:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.62.196 with HTTP; Tue, 28 Mar 2017 15:10:05 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Tue, 28 Mar 2017 15:10:05 -0700 Message-ID: Subject: Re: Move GOAWAY to HTTP draft To: Martin Thomson Cc: Mike Bishop , Patrick McManus , Ted Hardie , Ian Swett , Ryan Hamilton , Lucas Clemente , Jana Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113cf30ee64252054bd1b8a4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Mar 2017 22:10:09 -0000 --001a113cf30ee64252054bd1b8a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, the end of any exchange is a pure ACK, which may be lost. So at least one end has to remain around to send the ACK again if needed. As for a concluding packet, I agree that in a pure end-to-end world it is not only unnecessary, but harmful due to power consumption. However, in #353 we are discussing always sending a Public Reset to clear stateful middleboxes. For all the concern about power, I suspect most mobile operators are running these middleboxes and would appreciate the courtesy; they could even eat this packet before it gets to the phone if they'd like to optimize. It's how I would recommend operating to our service provider customers. I would recommend language as follows: 1) When an endpoint acknowledges a STREAM frame that closes all remaining streams, it starts the DRAIN timer. If the final FINs pass in flight, this will result in both sides starting DRAIN. 2) Endpoints SHOULD send a Public Reset with error code "Clean Close" (or whatever) if: (rule should say one of the following, but not both) (2a) When all streams are closed and they do not set the DRAIN timer. This would allow earlier cleanup of the DRAIN timer state, but causes simultaneous close cases to not send a reset at all. (2b) When the DRAIN timer expires. Guarantees at least one Reset, but doesn't save us any time on DRAIN. On Fri, Mar 17, 2017 at 3:44 PM, Martin Thomson wrote: > On 18 March 2017 at 04:00, Mike Bishop > wrote: > > I guess I=E2=80=99m still a little stuck on why there=E2=80=99s a timer= in the clean case > > anyway. In the clean case, it should be a deterministic closure based = on > > reaching a defined end state, shouldn=E2=80=99t it? In an error close,= you > probably > > don=E2=80=99t have enough shared state to have that requirement, so a t= imer may > be > > required. > > DRAIN is for the case where you have skew in this agreed end state. > For instance, an endpoint might have send an unneeded retransmission, > but later received an ACK. The endpoint that sent the ACK reaches a > quiescent state when it sends the ACK and so could close. But it > could later receive the extra retransmission. You want to have that > retransmission hit the connection state so that it can be cleanly > dropped, rather than hitting the "this is a new packet" code path, > that's all. > --001a113cf30ee64252054bd1b8a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, the end of any exchange is a pure ACK, which may= be lost. So at least one end has to remain around to send the ACK again if= needed.

As for a concluding packet, I agree that = in a pure end-to-end world it is not only unnecessary, but harmful due to p= ower consumption. However, in #353 we are discussing always sending a Publi= c Reset to clear stateful middleboxes. For all the concern about power, I s= uspect most mobile operators are running these middleboxes and would apprec= iate the courtesy; they could even eat this packet before it gets to the ph= one if they'd like to optimize. It's how I would recommend operatin= g to our service provider customers.

I would recom= mend language as follows:
1) When an endpoint acknowledges a STRE= AM frame that closes all remaining streams, it starts the DRAIN timer. If t= he final FINs pass in flight, this will result in both sides starting DRAIN= .
2) Endpoints SHOULD send a Public Reset with error code "C= lean Close" (or whatever) if: (rule should say one of the following, b= ut not both)
=C2=A0 =C2=A0(2a) When all streams are closed and th= ey do not set the DRAIN timer. This would allow earlier cleanup of the DRAI= N timer state, but causes simultaneous close cases to not send a reset at a= ll.
=C2=A0 =C2=A0(2b) When the DRAIN timer expires. Guarantees at= least one Reset, but doesn't save us any time on DRAIN.

=


On Fri, Mar 17, 2017 at 3:44 PM, Martin Thomson <martin.t= homson@gmail.com> wrote:
On 18 March 2017 at 04:00, Mike Bishop <Michael.Bishop@microsoft.com> wrote:<= br> > I guess I=E2=80=99m still a little stuck on why there=E2=80=99s a time= r in the clean case
> anyway.=C2=A0 In the clean case, it should be a deterministic closure = based on
> reaching a defined end state, shouldn=E2=80=99t it?=C2=A0 In an error = close, you probably
> don=E2=80=99t have enough shared state to have that requirement, so a = timer may be
> required.

DRAIN is for the case where you have skew in this agreed end state.<= br> For instance, an endpoint might have send an unneeded retransmission,
but later received an ACK.=C2=A0 The endpoint that sent the ACK reaches a quiescent state when it sends the ACK and so could close.=C2=A0 But it
could later receive the extra retransmission.=C2=A0 You want to have that retransmission hit the connection state so that it can be cleanly
dropped, rather than hitting the "this is a new packet" code path= ,
that's all.

--001a113cf30ee64252054bd1b8a4-- From nobody Thu Mar 30 05:31:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF9D12954A for ; Thu, 30 Mar 2017 05:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 SGgeDKXoyx1m for ; Thu, 30 Mar 2017 05:31:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D62B0129697 for ; Thu, 30 Mar 2017 05:31:05 -0700 (PDT) Received: from [192.168.1.57] ([5.10.171.186]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MMoU7-1cmfc147Xb-008Y1t for ; Thu, 30 Mar 2017 14:31:03 +0200 To: IETF QUIC WG From: Julian Reschke Subject: Reminder: QUIC WG meeting today, March 30, 14:00 UTC Message-ID: Date: Thu, 30 Mar 2017 14:31:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7HVhMkoGGX8fyuQNeH7e1JtVOxTmMPGwFF6cMhRreEhy3jgEy8e URh+C+x3ixNdgt/u7hgHk0E4TA6MZuXL3Tm+8Oj9E9jBSM9EGYjKNpyXIAZIkkeRQ8aS/Gc /u+Zpq+lIVj5pRvmnp/5xfDAhc/IO5Zc4jtmRai6zxdM3FKrkNC/medsmthAr89BUCMLEdu c+DzLEBuAtjNwvuoP55+w== X-UI-Out-Filterresults: notjunk:1;V01:K0:1Wn0KmHffcE=:04DN/T5cuXOmgHsqjYE7eb QZQBPCYyDw0U5MNFJpDc0qurv7cyCHF9I4v0Ljj5RSrUa2T3vCqFyss2/QX4ul6eitsz2Jjxx RtFs6VS8u/BJImjjTbFdwoZBetXzWHLA2y0wummvR5NnppQ0qQJDze4zJNV8qu6AmReEBVTJH z0o71rXB+c9ZYuveYyZGqVVG2pv4GdThXoN+VG4WO9NBKnTTU+ZgnjwHpaVvGUBOfo+sJXrwl 8Fb9T/cqQ/+OcnQ7qFFsxSU7jE6U19x4OjPa/npFXfNqE9RX0C/WZjdTrUT14th6nnUPL16kJ pHY+Qb8qEoyNsXX1XdcX7X570KasL4T2uSqWQXtyRUAJWlonLjnaYfKuq9O2R6SGdCUpmlUGR 2y21E1Z5JFJmFT7oUKJMyNTlNh6gMSOKacMySrmEYaCYhwZ7uXhSRaF4JrTJZPiBi+EkQnWPQ PgB9olbR2wDbw8G3GX3Z82d2MOSmSfNnEh1b09AzKx9NGTXMi/+YgaVSFnMelG7HqzCouxlii 2Y1Cxe0hK0oSJFSPdd0+M5yi8LIJLYUf0fuEvRiHDxX7n+zDw0jfnGoK5hui/G/lYcYrJlu9c 30rpQtZKeQMkj7TByVlkpubXk1+fI3OQix+e87pnXOSlQnrIStTz+4W0QB+UyKnAOXXN8ccLs yreQSuW5MF4bKXCDbB1oZdQqZFGyNRLs5ztpLGsyBwclrH8Hh6xtFMq45CGhA/w6C/iH25Okv fpwCvchrqL/+MrCqrWNInnuOqLY8LzhB0FbMgKDgcrBMOwKzVjHpUTQhjtJApSmJpK8wLYXZr Gc8wdcI Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 12:31:08 -0000 Agenda and remote participation details: https://www.ietf.org/proceedings/98/agenda/agenda-98-quic-03 Best regards, Julian From nobody Thu Mar 30 07:19:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED87D1293DA for ; Thu, 30 Mar 2017 07:19:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 nrWD5ZPmSfjI for ; Thu, 30 Mar 2017 07:19:10 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4994B128BB6 for ; Thu, 30 Mar 2017 07:19:10 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v76so24821050ywg.0 for ; Thu, 30 Mar 2017 07:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=lBG0RBpbATVjg9VGIzvXRPijJ2oo7V8tW4IWEvdTxPk=; b=GLlYygfGMhZ7JACaudkhmCiV9ziG9pxLQ52xDpB6MPjHd/Jwh59gGOA3SsG//OPLoY Pr8AgncQiznSUzgMh/3TcCz6B6DejdaFU8plzhNlk56NQe+MDjCFVu3OE+btfz8pdQsl OESD7velGsbYvItPF3cYhV9V7/8/IZR3ZBSwd9UAhuyE7P3LqWPpXSWfEfj86CtmXKhm I4l1b3rRNk7nE8MILcjyQ8zF2VMgfhr1cb06JNM8X+cpGHLbEWlfFy9u0fXBIhYFykxT vWtN2hXl8dduxACsY7wqPyZAiUSS+pkQhjQFHLg5JyroQRaAXKk41DLmsFAQqilvy0sp DWPQ== 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=lBG0RBpbATVjg9VGIzvXRPijJ2oo7V8tW4IWEvdTxPk=; b=pZSb1xIkUUPsCSOd9OkBwCYMvzAlN4lhMFhNJrg/VogSSn4dyw94Jds6wcn5x/1XEG CPlSJuunVRJTS74y1+CwBsAJqhozXy0/J7l/vyQoiUH0pa1+ZScoJkrfax6hR+XFeOnE 48+ZiPnONo+NrZAAAscI8TFAule72Pa6YBRvsEnc2+9+g0QTHq/y2/sVcnVZEii78eYa CQzeAjtZ+//dnYn5tSpr6ITMq2PTr75r84+dwkTZWIrFNIYTz9O59JneFRyqeulNxwb5 PxixQeWNb16dHwrhNSp57v8+BsrSwgMIyt0A1dadKt4TiFbGT3UP91A7oKH4rx+ClGMd gZgg== X-Gm-Message-State: AFeK/H1mW0nfrcIqNxlGpmfEbJ9gjcbNRvz+qaBLsIPLePfBgJ0tYB3LuSk5f0//YrVSY7qGPs4x91c2bFkmRA== X-Received: by 10.129.108.214 with SMTP id h205mr2509663ywc.71.1490883549261; Thu, 30 Mar 2017 07:19:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 30 Mar 2017 07:18:28 -0700 (PDT) From: Eric Rescorla Date: Thu, 30 Mar 2017 09:18:28 -0500 Message-ID: Subject: Notes on draft-kuehlewind-quic-manageability-00.txt To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114e81dc5b28a0054bf360c3 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 14:19:12 -0000 --001a114e81dc5b28a0054bf360c3 Content-Type: text/plain; charset=UTF-8 S 3.1 says: Stateful network devices such as firewalls use exposed header information to support state setup and tear-down. [I-D.trammell-plus-statefulness] provides a general model for in- network state management on these devices, independent of transport protocol. Features already present in QUIC may be used for state maintenance in this model. Here, there are two important goals: distinguishing valid QUIC connection establishment from other traffic, in order to establish state; and determining the end of a QUIC connection, in order to tear that state down. 1-RTT connection establishment, using a TLS handshake on stream 0, is detectable using heuristics similar to those used to detect TLS over TCP. 0-RTT connection establishment, however, provides no particular heuristic for differentiation from random background traffic at this time. This is not correct. TLS 1.3 0-RTT connection establishment looks like TLS 1.3 1-RTT connection establishment, so it's identifiable in the same way. -Ekr --001a114e81dc5b28a0054bf360c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0S 3.1 says:

=C2=A0 =C2= =A0Stateful network devices such as firewalls use exposed header
= =C2=A0 =C2=A0information to support state setup and tear-down.
= =C2=A0 =C2=A0[I-D.trammell-plus-statefulness] provides a general model for = in-
=C2=A0 =C2=A0network state management on these devices, indep= endent of transport
=C2=A0 =C2=A0protocol.=C2=A0 Features already= present in QUIC may be used for state
=C2=A0 =C2=A0maintenance i= n this model.=C2=A0 Here, there are two important goals:
=C2=A0 = =C2=A0distinguishing valid QUIC connection establishment from other
=C2=A0 =C2=A0traffic, in order to establish state; and determining the e= nd of a
=C2=A0 =C2=A0QUIC connection, in order to tear that state= down.

=C2=A0 =C2=A01-RTT connection establishment= , using a TLS handshake on stream 0, is
=C2=A0 =C2=A0detectable u= sing heuristics similar to those used to detect TLS over
=C2=A0 = =C2=A0TCP. 0-RTT connection establishment, however, provides no particular<= /div>
=C2=A0 =C2=A0heuristic for differentiation from random background= traffic at this
=C2=A0 =C2=A0time.

This= is not correct. TLS 1.3 0-RTT connection establishment looks like
TLS 1.3 1-RTT connection establishment, so it's identifiable in the
same way.

-Ekr

<= br>

--001a114e81dc5b28a0054bf360c3-- From nobody Thu Mar 30 07:26:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829D11294FB for ; Thu, 30 Mar 2017 07:26:03 -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, RP_MATCHES_RCVD=-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 Qg_UP4po8udB for ; Thu, 30 Mar 2017 07:26:01 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8BF129505 for ; Thu, 30 Mar 2017 07:25:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vv6PJ6H5nz15Nyy; Thu, 30 Mar 2017 16:25:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw2wzNoPHjkX; Thu, 30 Mar 2017 16:25:55 +0200 (CEST) X-MtScore: NO score=0 Received: from dhcp-8e47.meeting.ietf.org (dhcp-8e47.meeting.ietf.org [31.133.142.71]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 30 Mar 2017 16:25:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Notes on draft-kuehlewind-quic-manageability-00.txt From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 30 Mar 2017 09:25:51 -0500 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 14:26:03 -0000 Yes, that=E2=80=99s a an error. I believe Martin mentioned that already. Mirja > Am 30.03.2017 um 09:18 schrieb Eric Rescorla : >=20 > S 3.1 says: >=20 > Stateful network devices such as firewalls use exposed header > information to support state setup and tear-down. > [I-D.trammell-plus-statefulness] provides a general model for in- > network state management on these devices, independent of transport > protocol. Features already present in QUIC may be used for state > maintenance in this model. Here, there are two important goals: > distinguishing valid QUIC connection establishment from other > traffic, in order to establish state; and determining the end of a > QUIC connection, in order to tear that state down. >=20 > 1-RTT connection establishment, using a TLS handshake on stream 0, = is > detectable using heuristics similar to those used to detect TLS = over > TCP. 0-RTT connection establishment, however, provides no = particular > heuristic for differentiation from random background traffic at = this > time. >=20 > This is not correct. TLS 1.3 0-RTT connection establishment looks like > TLS 1.3 1-RTT connection establishment, so it's identifiable in the > same way. >=20 > -Ekr >=20 >=20 >=20 From nobody Thu Mar 30 08:41:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6566A12954C for ; Thu, 30 Mar 2017 08:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrHjDq6Hx-fG for ; Thu, 30 Mar 2017 08:41:33 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF86128BE1 for ; Thu, 30 Mar 2017 08:41:28 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id d191so26170387ywe.2 for ; Thu, 30 Mar 2017 08:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ohMbePmZ+NOjgBoJcOYjH5ty6NklE2yw0nrp4Iqyras=; b=RQ32CXM7YZ0vSppRhhujbgkgHNoC4G+6f3qwzpXcIPWdTK5E9c4czUTJq/eQonWTd5 i7uz21JYM1SinZKS043EtpWYoP6O3YcGoe6KTNAO1PhQjc0za2HvFxgqEcJjOE3z2nJz Kvg78hGd8wsZa90CsWZT7GUK2vaQOjHdMPNRRX4OBnqRT3RGC/QFK+xSi3mF6QL+kbk3 5KCTaLWXG2W1pkKe3fAlLie35k2aYmV+LoYIG5MCqQyY+Vr4sAZSMZFInb9uxM1oI3IH syrFftR3jJPI2/ZksQ/wHOAqjRh3fYjE7lppZBf6wyxNU08Kn3D5xXaQ+FGNvAm/gImK Os4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ohMbePmZ+NOjgBoJcOYjH5ty6NklE2yw0nrp4Iqyras=; b=PNXLu6gxQDtyTGsLuJyl+ljmLgfGsFXAy7eYV/yh2vbttF841ivT8KdKK56qn04vna sT896pzBMqWewA/gL8UwuYwtViMgMAeCckCSFH4TtSG88IZZE+9TN9aB8Cd1LCL6CQ11 Beaj0HhdJRlP2UClbm/rBJv7/mMEGiiu2HEolrCzN7ukFfiE9nagWxBPC1h4vWfuvLRW xft1br2t5Z5T3V/eLnF1ahry7dZ4Y43hW2Wy1eUbvJkah+Cb2EViR/flDbV3pF16i+7j YMLVAiUdEgsLTtXAxBwWeqPgPuaQXxE820HQb8xgiUHsT7QnWyupIA7tjyz2p2kmjw9/ /N+w== X-Gm-Message-State: AFeK/H0mmk/uKht5TkQ4ce0ZBOML8M027W+Vgeqclh2Ky2zYgDyYY1UQdTf7+AxkvamMQUFl0qds3dyw+fdVSw== X-Received: by 10.129.164.149 with SMTP id b143mr267517ywh.347.1490888487812; Thu, 30 Mar 2017 08:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Thu, 30 Mar 2017 08:41:27 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Thu, 30 Mar 2017 08:41:27 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Thu, 30 Mar 2017 10:41:27 -0500 Message-ID: Subject: Planning on new/different handshake protocols? To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c128d48b745d3054bf486a0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 15:41:35 -0000 --94eb2c128d48b745d3054bf486a0 Content-Type: text/plain; charset=UTF-8 Just for my better understanding, are people already planning to use handshake protocols that are not using TLS 1.3? Private replies are fine (since the working group is chartered for TLS 1.3 by default), and if I hear things I haven't heard recently, I'll summarize for the working group. Thanks, Spencer, as responsible AD --94eb2c128d48b745d3054bf486a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just for my better understanding, are people already plan= ning to use handshake protocols that are not using TLS 1.3?

Private replies are fine (since the working g= roup is chartered for TLS 1.3 by default), and if I hear things I haven'= ;t heard recently, I'll summarize for the working group.

Thanks,

Spencer, as responsible AD
--94eb2c128d48b745d3054bf486a0-- From nobody Thu Mar 30 09:13:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C4A129613 for ; Thu, 30 Mar 2017 09:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.997 X-Spam-Level: X-Spam-Status: No, score=-3.997 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 YaNfAeOMpSlA for ; Thu, 30 Mar 2017 09:12:57 -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 66FB11294C7 for ; Thu, 30 Mar 2017 09:12:57 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ctcgw-0004CD-V0 for quic@ietf.org; Thu, 30 Mar 2017 18:12:55 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ctcdM-00040f-7e for quic@ietf.org; Thu, 30 Mar 2017 12:09:16 -0400 Received: (qmail 22157 invoked from network); 30 Mar 2017 16:09:04 -0000 Received: from unknown (HELO [31.133.141.120]) (Authenticated-user:_huitema@huitema.net@[31.133.141.120]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Mar 2017 16:09:04 -0000 To: IETF QUIC WG From: Christian Huitema Message-ID: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> Date: Thu, 30 Mar 2017 11:09:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Abstract API X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.47) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXo1ecblNM7hpN6TYrFZY+19RcOb18WfxGyg6Om6u4YYmwTAPD6p5MbLdYOI Piao5eU5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qnTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0nrKAAmey s0BpT/bTqPTz5bbRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4Oa4tHfcnjrTubin0BRHlm0yNb6jieAcnBkVpX tF3NStfsxdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+3pSiCKkaAoX/nv7Y+HHGvPcu6wTHpnlfUs9BUPj1rZ3 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 16:12:59 -0000 Having an abstract API would greatly help writing "Foo over QUIC" specifications. Is anybody working on that? -- Christian Huitema From nobody Thu Mar 30 09:18:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B164212999B for ; Thu, 30 Mar 2017 09:18:21 -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, 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=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OCSGiz8W1GR for ; Thu, 30 Mar 2017 09:18:19 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9051412997E for ; Thu, 30 Mar 2017 09:18:17 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id r45so43584736qte.3 for ; Thu, 30 Mar 2017 09:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=uKyhsHfCaEdqx/dAgFME+cr9UmoKmmdzQRUZXQCNSCE=; b=GQcp9na6n5ZtrwPVOsuBP1UNhfEEqioVrdcw8K+aSBcYJLWd8q/w9n39ps+g2m4JMr wpSCJu3l/cPHyf3SIG3vTwmUKVIf02ecpe0e48Oc0vJ+rh67ni8aY2wy9H+M5uUX6INV lpOWI6JHNhtuIVGO48sxcy87tj/Q3hzaYOiDQ= 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:cc; bh=uKyhsHfCaEdqx/dAgFME+cr9UmoKmmdzQRUZXQCNSCE=; b=Gt08FQ2r3TliTGTqYLuhUoQiTCMtBMk1CnvtUrIubP/IPvvw5E1J8r96459gyDkmbx kKuGJbvYsi5Hf9FAjCIGuNhyTHQd59y3xe7zjt/GpxarXAG3y6C4XL6OhvnDd0iOG+3k EFmMeTr1woHF3FottYTaBN48/i/CqG/DLN23Ah0SNOBuikaa04c/K5vBEGhGkZY1jVxm HULCd9EYSXb47YK1SNaVdAIFos6Cx773CTlzkXSUpzc3DlPdIaNCcPD5n8MhMmLtgcq+ S8dgF854NDvTYXGLOJBCBG8FHO1Iwaupa/yiDjgGdXHdzsqmJqHrm3irRGbcjc613u/M a3bA== X-Gm-Message-State: AFeK/H1/wBQ8vvcYsHtZ6z7IRMsURorpbXdZFqB5x5PPxMXezlUgDAaD/bzs1o+9ewfZOuqnTxRdIQfQX3nbgQ== X-Received: by 10.200.42.78 with SMTP id l14mr602262qtl.15.1490890696404; Thu, 30 Mar 2017 09:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Thu, 30 Mar 2017 09:18:15 -0700 (PDT) X-Originating-IP: [31.133.141.179] From: Kyle Rose Date: Thu, 30 Mar 2017 11:18:15 -0500 Message-ID: Subject: Server-chosen connection ID, final cleartext packet, and load balancers To: IETF QUIC WG Cc: "Lubashev, Igor" , Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11403d865c4c2e054bf50a02 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 16:18:22 -0000 --001a11403d865c4c2e054bf50a02 Content-Type: text/plain; charset=UTF-8 I interpreted the discussion about connection ID early in the session as "everything prior to the final cleartext packet requires no load balancer state", and asked for clarification on the jabber channel. Ben Kaduk replied: q( I was hearing that, if you have a load-balancer setup, it has to be able to deal with zero or "random" connection IDs, because they will be used for the initial cleartext packets. Therefore, there's no reason to try and do something fancy once the server does have a chance to select something, so the server should just pick the client's initial value in most cases, and the load balancer would be based on some sort of persistent hashing-like thing. ) Is this right? ISTM the point of a server-chosen connection ID is to permit interesting (i.e., not consistent hash-based) load balancing by the server without out-of-band state sharing. In the general case, this means the server-provided connection ID being used on every single packet once more than a trivial amount of state (whatever fits in 64 bits) needs to be known to whatever the eventual LB-chosen server is. Encryption keys cannot be encoded in 64 bits. Is the intent of "final cleartext packet" combined with "TLS handshake always in the clear" that the server-chosen connection ID is not employed until the TLS handshake has completed? If so, it seems we've already decided that global state sharing is required. Alternatively, we could allow for 1-RTT with a consistent hash-chosen server to be followed immediately by a (possibly optimized) 0-RTT reconnect to an LB-chosen server with a session ticket. Or, we could split off connection ID and load balancer cookie and set the latter much earlier. Mostly I would like clarification on the actual status quo before trying to explore the design space. Kyle --001a11403d865c4c2e054bf50a02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I interpreted the discussion about connecti= on ID early in the session as "everything prior to the final cleartext= packet requires no load balancer state", and asked for clarification = on the jabber channel. Ben Kaduk replied:

q( I was hearing tha= t, if you have a load-balancer setup, it has to be
able to deal with zer= o or "random" connection IDs, because they will
be used for th= e initial cleartext packets.=C2=A0 Therefore, there's no
reason to t= ry and do something fancy once the server does have a
chance to select s= omething, so the server should just pick the
client's initial value = in most cases, and the load balancer would be
based on some sort of pers= istent hashing-like thing. )

Is this right? ISTM the point of = a server-chosen connection ID is to permit interesting (i.e., not consisten= t hash-based) load balancing by the server without out-of-band state sharin= g. In the general case, this means the server-provided connection ID being = used on every single packet once more than a trivial amount of state (whate= ver fits in 64 bits) needs to be known to whatever the eventual LB-chosen s= erver is.

Encryption keys cannot be encoded in 64 bits. I= s the intent of "final cleartext packet" combined with "TLS = handshake always in the clear" that the server-chosen connection ID is= not employed until the TLS handshake has completed? If so, it seems we'= ;ve already decided that global state sharing is required. Alternatively, w= e could allow for 1-RTT with a consistent hash-chosen server to be followed= immediately by a (possibly optimized) 0-RTT reconnect to an LB-chosen serv= er with a session ticket. Or, we could split off connection ID and load bal= ancer cookie and set the latter much earlier.

Mostly I wo= uld like clarification on the actual status quo before trying to explore th= e design space.

Kyle
<= div>
--001a11403d865c4c2e054bf50a02-- From nobody Thu Mar 30 09:24:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402BB1297AA for ; Thu, 30 Mar 2017 09:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGjvveODMhSZ for ; Thu, 30 Mar 2017 09:24:38 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1580B129613 for ; Thu, 30 Mar 2017 09:24:36 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f84so22559168ioj.0 for ; Thu, 30 Mar 2017 09:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Y42HRCpMN1mwQY3CM3RaVg1/KL5oWH5xWC0FrcfnEQk=; b=oLqoqkSUtUonvaiAAYoqyv6um0RI66RclfB+4ff0+HgLv/1mkktLWF4V650VAz4kQy s325gSRbMsj95NqbTrBlgYNEP5xlQDofZpWOqQYzPZfk6ijMrlY8rBxfjUbhardOIYWx hVmHxi4oR0S3ZFcSKvH+kHANMFIw7gXbDXa++yOoPArGncHIrQODUev8FF/R48C9sScO q/cKVWsG8XzZtt8N4NN3CvjCg22TIX+Ud+kZMNT/Ne6naH4IU3cIhlfYTQ/k4SbwNKxX dJLwX+dDQUFsduS5joc4xgcqsebMEwm3+1oc9G4/NnR5/NOqbf7vmfqNAGrj69/v//l6 Ei3Q== 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=Y42HRCpMN1mwQY3CM3RaVg1/KL5oWH5xWC0FrcfnEQk=; b=MTDSwBUm1VbFyVpRraIRhz2aojkadozz1fq5M6LrfXT0Ok8pv8JC+zmYWgGXyFO9A0 8n/FZa1HPdUjwfCZQ7fNqkOCsbEATX7aNvGMFaongxTQjvhpxqN99FHL36ECQki2lOD3 PUIH22pil8VrMNYCVciOgsz8OwN1VML5i+4iKvnQmBJ9SKZW5Lq+ifsq6CSOT/TYSLeO M1gYedbbWZIQMGDvbERVq1YOaIrZUOICLDTf60skOaU+tYnH+ohwcMn53wJeLPC5+uoN fgGc1A2IH6r/ACgh4Fp/Am8RYSCWj8PHuM2n3ITGbx4UgSF68HCW42Mk65fLY169bx6Y hOKw== X-Gm-Message-State: AFeK/H1kr4KihlogLXSkAPkjIygn1ma3pIcNiIT+OL4NE3GMELGBOE66VJ0K+18rsQo3eBU9r5sA2/pidLb8Uw== X-Received: by 10.107.53.170 with SMTP id k42mr1515510ioo.176.1490891075443; Thu, 30 Mar 2017 09:24:35 -0700 (PDT) MIME-Version: 1.0 References: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> In-Reply-To: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> From: Lucas Clemente Date: Thu, 30 Mar 2017 16:24:25 +0000 Message-ID: Subject: Re: Abstract API To: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1144975cf36976054bf52023 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 16:24:40 -0000 --001a1144975cf36976054bf52023 Content-Type: text/plain; charset=UTF-8 For the record, the quic-go API is quite minimal and documented at https://godoc.org/github.com/lucas-clemente/quic-go, with the most important interface being https://godoc.org/github.com/lucas-clemente/quic-go#Session Note that we have decided against offering APIs for explicitly opening or receiving streams by ID, and instead automatically assign stream IDs. On Thu, 30 Mar 2017 at 18:13 Christian Huitema wrote: > Having an abstract API would greatly help writing "Foo over QUIC" > specifications. Is anybody working on that? > > -- Christian Huitema > > --001a1144975cf36976054bf52023 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For the record, the quic-go API is quite minimal and = documented at https://godoc.org/github.com/lucas-clemente/quic-go, with the most i= mportant interface being https://godoc.org/github.com/lucas-clemente/quic-go#S= ession

Note that we have decided against offer= ing APIs for explicitly opening or receiving streams by ID, and instead aut= omatically assign stream IDs.


On Thu, 30 Mar 2017 at 18:13 Christian Huitema <<= a href=3D"mailto:huitema@huitema.net">huitema@huitema.net> wrote:
Having an abstract API would greatly = help writing "Foo over QUIC"
specifications. Is anybody working on that?

-- Christian Huitema

--001a1144975cf36976054bf52023-- From nobody Thu Mar 30 09:31:47 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40561297E1 for ; Thu, 30 Mar 2017 09:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Fd53ed6zkhUw for ; Thu, 30 Mar 2017 09:31:33 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2102712996E for ; Thu, 30 Mar 2017 09:31:33 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 21so44819274pgg.1 for ; Thu, 30 Mar 2017 09:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/XUBNGK+bRvEn0zbfeSlJ2HbwDmYY4pmFG6iz2n+0iE=; b=hRmqNg6wm0sSzBcECWUpBBdJpxty2YySm7YJ2v8ZVeT1W+nCqCcLmxSENA+kafGJCu EbVLyUzoTpDxtL5lntVCHutUcUCAzTRq6ZjyGKIUlNiuNlhZxqQs0Sdj7yp9ZlXD5Tx9 u+7L51zdF53+YhgMh66a3zGkFDtGipNvdIKD0NyzZJpqHQzPSXKXsKmRPVSRk9Zskbg/ FW/qXwx+L+3SP/4hzfV5gkvJ7bdJIWtjWcLsVOtoLN19HvKE1+mMYU+eMak5/7HxloQI Yh3bFEJzx3S4a+E4ZFtc4q1+dPDZSPLvDvaYuddOwHEF4STnudpwOUWY4FwqAJnpID81 dSUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/XUBNGK+bRvEn0zbfeSlJ2HbwDmYY4pmFG6iz2n+0iE=; b=l+in5RWnHp9pKpMk3Xu1ws3TT+DxNTa+2VC+jmbDDMFNYxjt+ZR6Gxwha8+fMZ4e5s EiquDPoRFjeGex7ITc8etLweAun7bV487qsAjsufej/hlpSevIcpQJF3nPuEC9wGxpd6 3K6P0EtVurMK8cnXiaF8hqYgN9F90UMDr9kN13lpgx6un1Ys7/2Idn/mUtjnYJgr2a6c Lh+7G/b7qEEY7zSpVcLPhAotMFBLPweKYoc/VaDKvG+Nti9EAhV2BWdLMZwu64hraVlh IFjI5PKAG4a/iVFD+JwRxKPllXR6nKrsWI+PMvRbCaswgSdmI0N0jJ2Z/Fch9vX+r2uQ Exgw== X-Gm-Message-State: AFeK/H1+RqYWPuTHiEeQGc6zjZtLZVdHf2Ie/QIJLlXlejfZa0efV25eDhNDyPsGHkpQ9zLxUMPfO0Y5tcDd3dZf X-Received: by 10.98.212.91 with SMTP id u27mr555707pfl.117.1490891492433; Thu, 30 Mar 2017 09:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.209 with HTTP; Thu, 30 Mar 2017 09:31:31 -0700 (PDT) In-Reply-To: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> References: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> From: Jana Iyengar Date: Thu, 30 Mar 2017 11:31:31 -0500 Message-ID: Subject: Re: Abstract API To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary=f403045ec18cceafa6054bf5399b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 16:31:37 -0000 --f403045ec18cceafa6054bf5399b Content-Type: text/plain; charset=UTF-8 I think Mirja was talking about adding this to the applicability draft, but I think it does make sense to have this in a separate doc. On Thu, Mar 30, 2017 at 11:09 AM, Christian Huitema wrote: > Having an abstract API would greatly help writing "Foo over QUIC" > specifications. Is anybody working on that? > > -- Christian Huitema > > --f403045ec18cceafa6054bf5399b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Mirja was talking about adding this to the applica= bility draft, but I think it does make sense to have this in a separate doc= .

On Thu, Ma= r 30, 2017 at 11:09 AM, Christian Huitema <huitema@huitema.net> wrote:
Having an abstract API would= greatly help writing "Foo over QUIC"
specifications. Is anybody working on that?

-- Christian Huitema


--f403045ec18cceafa6054bf5399b-- From nobody Thu Mar 30 09:45:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067C6129553 for ; Thu, 30 Mar 2017 09:45:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 G2ucJTG6jum8 for ; Thu, 30 Mar 2017 09:45:34 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 3C9261297E1 for ; Thu, 30 Mar 2017 09:45:34 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id y18so176095094itc.0 for ; Thu, 30 Mar 2017 09:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WgNImsuKd7q4AgOtoAKWM8WbVJaTykTHYF7fb5qzWhE=; b=unQ3I5Z06ARSGKHYwhxtrkkofahVRye26fa8nrYj84I0vx9wFSwVAlpfR9tPvjTJlt BO61EZTHjnfmAYYoa3DCP38e1PmCfZRWwP66ln2PMNJfAXkRg97lLbmkVOl7iJqZiSGT +wO/QvEK0Wll6mURiz7ivxxVhcGiZiXoxBsG2M/I8bCqhMDwwLT+RJ+w0lnkn/4RNQdf l4AJGVi24/IEGGJBIucq3/G8kw+Sm9wl1dk3X8X5AHnYQH04wVFhKhqIgv1Gh7C5+tXG JESEgo44TOphEahr430Ifq0UPhwhtg3EDvWEBG2zYhnY3BG37nWvGbUkptpGa0/OREjC dThw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WgNImsuKd7q4AgOtoAKWM8WbVJaTykTHYF7fb5qzWhE=; b=LS1SaQ8ZxEROx9BCzxYkuUow1oMi9F687uYT76D0Nv5ZvQV1iV469lbIGcPooZoilO DlBmZ5HFu5YXf8UaWOcDQOhuRFquOLzXZ+kAZiuKgHdsNEMQhrYUnZQ+Hj1e+/ClSX4w Rk67RJvG05P51TMS31S+VKVUs0/M50k6eAz7xK4xWbwCpXQThua5yxka0tqq4Obb7MhD DuovtWbrlWuLwdr8PGDD6y7K3Ob64Xg6pxQNvHCZy0PxAIttFCzTFLzAKXu0+ohGDvsp ZCGf1SCnS6qu5OhpDNQdexYNPCycfpPmZNdtOoRrKKsHvkzz9BarD9ZhPkTIqI+/mFSO qEsA== X-Gm-Message-State: AFeK/H3gZJona7frRsz/Z5JWjYZWHJQYUt6QEwZ7hbNw5oYLBK1RELtrOWLrUaan1llQ7OREo6zifd9ipzcVITyZ X-Received: by 10.36.196.8 with SMTP id v8mr5163285itf.115.1490892333464; Thu, 30 Mar 2017 09:45:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.200.4 with HTTP; Thu, 30 Mar 2017 09:45:12 -0700 (PDT) In-Reply-To: References: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> From: "Charles 'Buck' Krasic" Date: Thu, 30 Mar 2017 09:45:12 -0700 Message-ID: Subject: Re: Abstract API To: Jana Iyengar Cc: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c05d0d4efbe6c054bf56b78 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 16:45:36 -0000 --94eb2c05d0d4efbe6c054bf56b78 Content-Type: text/plain; charset=UTF-8 +1 to a separate doc. Designing a new API is a very big deal IMHO. Ossification of transport related APIs has been comparable to the wire format etc. For instance, I'd hope that after 30+ years of posix sockets and Winsock, we'd make progress on things like: o clean zero-copy of data, at least between mappings and transport. o clean cooperation of mapping and transport wrt packetization and framing. o important for apps to have better visibility into latency (which messages go in which RTTs) o would pave the way for advanced features like application controlled FEC etc. On Thu, Mar 30, 2017 at 9:31 AM, Jana Iyengar wrote: > I think Mirja was talking about adding this to the applicability draft, > but I think it does make sense to have this in a separate doc. > > On Thu, Mar 30, 2017 at 11:09 AM, Christian Huitema > wrote: > >> Having an abstract API would greatly help writing "Foo over QUIC" >> specifications. Is anybody working on that? >> >> -- Christian Huitema >> >> > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --94eb2c05d0d4efbe6c054bf56b78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to a separate doc. =C2=A0 Designing a new API is a very= big deal IMHO. =C2=A0 Ossification of transport related APIs has been comp= arable to the wire format etc. =C2=A0 =C2=A0For instance, I'd hope that= after 30+ years of posix sockets and Winsock, we'd make progress on th= ings like:
=C2=A0 o clean zero-copy of data, at least between mappings = and transport.
=C2=A0 o clean cooperation of mapping and transpor= t wrt packetization and framing.
=C2=A0 =C2=A0 =C2=A0 =C2=A0o imp= ortant for apps to have better visibility into latency (which messages go i= n which RTTs)
=C2=A0 =C2=A0 =C2=A0 =C2=A0o would pave the way for= advanced features like application controlled FEC etc.
=C2=A0 = =C2=A0 =C2=A0=C2=A0

On Thu, Mar 30, 2017 at 9:31 AM, Jana Iyengar <jri@google.com> wrote:
I t= hink Mirja was talking about adding this to the applicability draft, but I = think it does make sense to have this in a separate doc.

On Thu, Mar 30, 2017 at 11:09 AM, Christian Huitema <huitema@h= uitema.net> wrote:
Having a= n abstract API would greatly help writing "Foo over QUIC"
specifications. Is anybody working on that?

-- Christian Huitema





--
=
= Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

--94eb2c05d0d4efbe6c054bf56b78-- From nobody Thu Mar 30 10:33:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2301A126DFB for ; Thu, 30 Mar 2017 10:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=TQdNejpr; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=LVaan68K Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imB5x0P4W24B for ; Thu, 30 Mar 2017 10:33:47 -0700 (PDT) Received: from mx0a-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 02959129639 for ; Thu, 30 Mar 2017 10:33:46 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.20/8.16.0.20) with SMTP id v2UHUHgG003668; Thu, 30 Mar 2017 10:33:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=0cu61zhTjOjONJqT1EM8mB9q/8fynfkUEP+cmueAoSQ=; b=TQdNejprhzLDod5OnbL1bTMdOBiXSvO2mbAOXS9Xh2XICE8KXIcMcUXYlkAczCUlAokF DL48jnpzig+HFBa6PDyfLf+pZLlAdZvU3kodYyfbT6+PJqbvJdbD+vpSjDau26Nkg2N9 y4sa/QXTNxaL9v86gAOsIoBAujBMy5Ifjok= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 29gw9qsq26-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Mar 2017 10:33:45 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 30 Mar 2017 10:33:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0cu61zhTjOjONJqT1EM8mB9q/8fynfkUEP+cmueAoSQ=; b=LVaan68K1w1WtJNbnUtwaLTyLlnuEpe6s5hVH5TEzNXkbC2XOfmmxnSlVsoQ2Wh6S5TvN7AtEyiJivVr3ah2k9pbcwbWInEIyj/s1P3iEYcD+aMJFXjkLjiPsH5vvUR0FHDtiiM+j2gjdMCDSX1DwVJPvM7bLXwEnLm67Wetm24= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Thu, 30 Mar 2017 17:33:08 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.0991.022; Thu, 30 Mar 2017 17:33:08 +0000 From: Subodh Iyengar To: "quic@ietf.org" , "Lubashev, Igor" Subject: Changes to the connection id negotiation in -02 Thread-Topic: Changes to the connection id negotiation in -02 Thread-Index: AQHSqXtTygEOjXnJuU2csNhvjbXUbQ== Date: Thu, 30 Mar 2017 17:33:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-Mentions: ilubashe@akamai.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fb.com; x-originating-ip: [25.173.47.4] x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 7:ZtodxN0WpXd1ln0CnoHhdtyQcR7F4sfPh48db0vUveDASFfK6YujouTuUjkFMYJA2ET9IGL0A63x6NIO/zli9MdywAscRTNZqfR8J+w+gVredc3wJ5renZpbttK/s8mE0DMuq5NQ6oRBNRE3p6bXnbX1CxQmdAqKr7W0eInOZvWaDy2kk81tohu+ne3QIV4D16zwpGJlGy/QFdjFhF7d2K/A22k7QMvWsz4mZnEK0M4HXLFfsgHxnDBy1I3WaihTvhh540eVBlecMGsy+WUhXfQdU25rynBENU45ZkrdHLR54PiGgue/Qyh3OcOO82sCfUXgsO71pq1Omwr+FzdwNg==; 20:CiK0yOKknT1yj69hIXnkVYFHBhJyf0X/JZA4bXYDrfX1QbSDbsQsY9x9wvMb6Yh2spOmZVLz4pQVpwnJMbudIPz34fX0uT90g3pYhF/hUPsIsmWHEm3/pCI042xmh0s/RPTEV/OZKcvQJOPOpjiNLEunlqBW17FoOhW1Kt9zvC0= x-ms-office365-filtering-correlation-id: 4de0ed60-a17f-4520-fbad-08d47792d488 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MWHPR15MB1455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006067)(93001067)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1455; x-forefront-prvs: 02622CEF0A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39400400002)(39410400002)(39850400002)(39450400003)(33656002)(8936002)(54356999)(50986999)(81166006)(8676002)(3846002)(6116002)(102836003)(7696004)(6606003)(19627405001)(38730400002)(122556002)(2900100001)(53936002)(99286003)(54896002)(55016002)(236005)(9686003)(6506006)(25786009)(6436002)(77096006)(66066001)(3660700001)(2906002)(189998001)(3280700002)(2501003)(7736002)(86362001)(74316002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14551D5289AD2B04BBE437A3B6340MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2017 17:33:07.8158 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_14:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 17:33:49 -0000 --_000_MWHPR15MB14551D5289AD2B04BBE437A3B6340MWHPR15MB1455namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the WG meeting @Jana went though some changes which allowed a server to = choose connection id. The exact text in the draft seems to be "When a connection is initiated, th= e client MUST choose a random value and use it as the initial Connection ID= until the final value is available. The initial Connection ID is a suggest= ion to the server. The server echoes this value in all packets until the ha= ndshake is successful". I can see the security reasons to require the client to switch to the serve= r chosen id only after the handshake is successful, however I think it inte= racts poorly with stateless rejects. When a server wants to do a stateless reject of the client due to DoS conce= rns or any other reasons, it does this via a HelloRetryRequest in the TLS l= ayer. At this point a server might want to choose a connection id to send t= o the client so that it can choose an alternative backend it wants to direc= t the client to. Since the HRR does not mean that the handshake is successf= ul, the client will keep using the original connection id it and not respec= t the server's choice of backend. @Lubashev, Igor also brought up during offline = discussions that this is the same for version negotiation as well in case t= here are separate backend servers that support different versions. He also = brought up that it creates an ambiguity at a load balancer of whether it is= using the client chosen connection id or a server chosen one. The simplest alternative to change this to is something like: "In its first= flight, the client MUST not use any connection id, and should latch on to = the first connection id that the server sends", even before the handshake i= s complete However this means that the first flight would be routed by 5 tuple and if = a NAT rebinding occurs in the first flight that would cause the connection = to fail. Alternatively we could just allow clients to advertise their id, b= ut latch on to a server id as soon as they have one. It seems like it comes down to whether there was a major security rationale= for only binding connection id after the handshake was successful. Subodh --_000_MWHPR15MB14551D5289AD2B04BBE437A3B6340MWHPR15MB1455namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In the WG meeting @Jan= a went though some changes which allowed a server to choose connection= id.  

The exact text in the draft seems to be "When a connection is initiate= d, the client MUST choose a random value and use it as the initial Connecti= on ID until the final value is available. The initial Connection ID is a su= ggestion to the server. The server echoes this value in all packets until the handshake is successful".

I can see the security reasons to require the client to switch to the server chosen id only after the handshake is successful, however I thi= nk it interacts poorly with stateless rejects. 

When a server wants to do a stateless reject of the client due to DoS = concerns or any other reasons, it does this via a HelloRetryRequest in the = TLS layer. At this point a server might want to choose a connection id= to send to the client so that it can choose an alternative backend it wants to direct the client to. Since the HRR doe= s not mean that the handshake is successful, the client will keep usin= g the original connection id it and not respect the server's choice of= backend.

@Lubashev, Ig= or also brought up during offline discussions that this is the same for version negotiation as well in case there are se= parate backend servers that support different versions. He also brought up = that it creates an ambiguity at a load balancer of whether it is using the = client chosen connection id or a server chosen one.

The simplest alternative to change this to is something like: "In= its first flight, the client MUST not use any connection id, and should la= tch on to the first connection id that the server sends", even before = the handshake is complete

However this means that the first flight would be routed by 5 tuple an= d if a NAT rebinding occurs in the first flight that would cause the c= onnection to fail. Alternatively we could just allow clients to advertise t= heir id, but latch on to a server id as soon as they have one.

It seems like it comes down to whether there was a major security= rationale for only binding connection id after the handshake was successfu= l.

Subodh



--_000_MWHPR15MB14551D5289AD2B04BBE437A3B6340MWHPR15MB1455namp_-- From nobody Thu Mar 30 13:38:21 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935B01293D9 for ; Thu, 30 Mar 2017 13:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 CYtySROZG37j for ; Thu, 30 Mar 2017 13:38:18 -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 E2C12124B0A for ; Thu, 30 Mar 2017 13:37:29 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ctgox-0002nJ-Pv for quic@ietf.org; Thu, 30 Mar 2017 22:37:28 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ctgou-0007Hv-Bm for quic@ietf.org; Thu, 30 Mar 2017 16:37:25 -0400 Received: (qmail 16240 invoked from network); 30 Mar 2017 20:37:23 -0000 Received: from unknown (HELO [31.133.141.120]) (Authenticated-user:_huitema@huitema.net@[31.133.141.120]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Mar 2017 20:37:23 -0000 To: Charles 'Buck' Krasic , Jana Iyengar References: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> Cc: IETF QUIC WG From: Christian Huitema Message-ID: Date: Thu, 30 Mar 2017 15:37:20 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: Abstract API X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXonNveJV0f/MoLxAbd65h+zRcOb18WfxGyg6Om6u4YYm/WJK3fz899zEsBs V3LZxao5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKXTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0l2IoK9Jj buaPkuG+mV6Do7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgD5 8bDUIriOSOQTK7vaz2jBsjp0rjSY76LAIHA6cW4OayWB4LzfBGD5xZjOYZke3+cC79mpExGBya58 Y78lXOF+xdwDV/LdQk4Dnvnv/o4ZpIN8Tfe43vaXKX/yihCEqxIlRZaHuAWSnHeK3PdSA6Q+2n/k rhIYlNMbfS0wdTtG+3pSiCKkaAoX/nv7Y+HHGvPcu6wTHpnlfUs9BUPj1rZ3 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 20:38:21 -0000 On 3/30/2017 11:45 AM, Charles 'Buck' Krasic wrote: > +1 to a separate doc. Designing a new API is a very big deal IMHO. > Ossification of transport related APIs has been comparable to the wire > format etc. For instance, I'd hope that after 30+ years of posix > sockets and Winsock, we'd make progress on things like: > o clean zero-copy of data, at least between mappings and transport. > o clean cooperation of mapping and transport wrt packetization and > framing. > o important for apps to have better visibility into latency > (which messages go in which RTTs) > o would pave the way for advanced features like application > controlled FEC etc. > That's why I mentioned "Abstract" API. Stuff like zero copy tend to be very much system dependent, and he exact syntax is bound to be language dependent. But when you design an application API, you are concerned with issues like "can a node wait for the next stream initialization", which is in the domain of "abstract". -- Christian Huitema From nobody Thu Mar 30 13:54:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662FE129544 for ; Thu, 30 Mar 2017 13:54:43 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 upqx0K_tAbgi for ; Thu, 30 Mar 2017 13:54:39 -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 77AAB1294CC for ; Thu, 30 Mar 2017 13:54:34 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2UKprZ1010750; Thu, 30 Mar 2017 21:54:31 +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=PCk0cn+cgTVV979cWjiSXNyfJtU1yl+n49u8jDb26M0=; b=SXQ4WRNgloOMkSPQuE7vkpM/VgvDxMARXKYCbpnSBCtt+Q3NIqiD1wg9PaaNfpRt/u4c YrBlM7eUdN9zYi/Se34Kt+ytArOSyKZ7RTwOyFAonNmT2IsfP/Cf1SPbJUzS5VrFQ+kr NNhB4Q/slazX4g2RTtuvzL/MWrN3kCsTHOYc2zpFnx5oU/hpE+LE+lO5O29fMZWShxWX qujMH0wJj+qPNDe+x8l6YSvpd2XDoTpUwHRwl665s1lZQQxRyUK5gySLXWZEve03oq8h LC3XszLVJy0EfdmummU1OKs+LJws120NLLsj0rgMEG5D0Uz28/UEz8vjV+9cUCHjQdU3 CA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29h0g3kc3m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 21:54:31 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2UKfhwt005052; Thu, 30 Mar 2017 16:54:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 29fsutsa67-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 16:54:30 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 30 Mar 2017 13:54:29 -0700 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.1178.000; Thu, 30 Mar 2017 16:54:29 -0400 From: "Lubashev, Igor" To: Kyle Rose , IETF QUIC WG CC: Benjamin Kaduk Subject: RE: Server-chosen connection ID, final cleartext packet, and load balancers Thread-Topic: Server-chosen connection ID, final cleartext packet, and load balancers Thread-Index: AQHSqXFBT0Xxj0pa3EadbItmF76VCKGt1vdA Date: Thu, 30 Mar 2017 20:54:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.44] Content-Type: multipart/alternative; boundary="_000_cb9b72712d3a40c38bd97eabc4b6c5d3usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703300178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_16:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703300179 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 20:54:43 -0000 --_000_cb9b72712d3a40c38bd97eabc4b6c5d3usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VydmVyLWNvbnRyaWJ1dGVkIENvbm5lY3Rpb24gSUQgaXMgdGhlcmUgdG8gYWxsb3cgbG9hZCBi YWxhbmNlcnMgbG9jYXRlIHRoZSBiYWNrZW5kIHNlcnZlciB3L28ga2VlcGluZyBhIGRpc3RyaWJ1 dGVkIGNvbm5lY3Rpb24gdGFibGUuICBUaGlzIGlzIGVzcGVjaWFsbHkgaW1wb3J0YW50IGluIHRo ZSBjYXNlIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIG9yIGxvbmctbGl2ZWQgY29ubmVjdGlvbnMu DQoNClRoZXJlIGlzIG5vIG1hZ2ljIGFzc29jaWF0ZWQgd2l0aCDigJxsYXN0IHNlcnZlciBjbGVh cnRleHTigJ0sIGV4Y2VwdCBpdCBpcyBhIHdlbGwtZGVmaW5lZCBwb2ludDogY2xpZW50LWdlbmVy YXRlZCBjb25uZWN0aW9uIElEIGlmIChTaG9ydC1IZWFkZXIgb3IgVHlwZT0yfDUpOyBzZXJ2ZXIt Z2VuZXJhdGVkIG90aGVyd2lzZS4gIFtTbWFsbCBwcm9ibGVtIOKAkyBQdWJsaWMgUmVzZXQgY2Fu IGhhdmUgZWl0aGVyIGNvbm5lY3Rpb24gSUQhXS4NCg0KVGhlcmUgaXMgYW5vdGhlciBwcm9wb3Nh bCBieSBTdWJvZGggdG8gYWxsb3cgdGhlIHNlcnZlciB0byBjaG9vc2UgaXRzIGNvbm5lY3Rpb24g SUQgYXQgYW55IHRpbWUuICBJbiB0aGF0IHByb3Bvc2FsLCBjbGllbnQgYWx3YXlzIHN0YXJ0cyB3 aXRoIGNvbm5lY3Rpb24gSUQ9MCBhbmQgc2VydmVyIGlzIGZyZWUgdG8gY2hvb3NlIGl0cyBjb25u ZWN0aW9uIElEIGF0IGFueSB0aW1lLCBhbmQgdGhlIGNsaWVudCB0aGVuIGFsd2F5cyB1c2VzIHRo YXQuIFRoaXMgbWFrZXMgaXQgZXZlbiBlYXNpZXIgdG8gaWRlbnRpZnkgc2VydmVy4oCZcyBjb25u ZWN0aW9uIElEICgwIG9yIG5vbi0wKS4NCg0KDQotICAgICAgICAgIElnb3INCg0KRnJvbTogS3ls ZSBSb3NlIFttYWlsdG86a3Jvc2VAa3Jvc2Uub3JnXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMw LCAyMDE3IDExOjE4IEFNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KQ2M6IEx1 YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQmVuamFtaW4gS2FkdWsgPGthZHVr QG1pdC5lZHU+DQpTdWJqZWN0OiBTZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQsIGZpbmFsIGNs ZWFydGV4dCBwYWNrZXQsIGFuZCBsb2FkIGJhbGFuY2Vycw0KDQpJIGludGVycHJldGVkIHRoZSBk aXNjdXNzaW9uIGFib3V0IGNvbm5lY3Rpb24gSUQgZWFybHkgaW4gdGhlIHNlc3Npb24gYXMgImV2 ZXJ5dGhpbmcgcHJpb3IgdG8gdGhlIGZpbmFsIGNsZWFydGV4dCBwYWNrZXQgcmVxdWlyZXMgbm8g bG9hZCBiYWxhbmNlciBzdGF0ZSIsIGFuZCBhc2tlZCBmb3IgY2xhcmlmaWNhdGlvbiBvbiB0aGUg amFiYmVyIGNoYW5uZWwuIEJlbiBLYWR1ayByZXBsaWVkOg0KcSggSSB3YXMgaGVhcmluZyB0aGF0 LCBpZiB5b3UgaGF2ZSBhIGxvYWQtYmFsYW5jZXIgc2V0dXAsIGl0IGhhcyB0byBiZQ0KYWJsZSB0 byBkZWFsIHdpdGggemVybyBvciAicmFuZG9tIiBjb25uZWN0aW9uIElEcywgYmVjYXVzZSB0aGV5 IHdpbGwNCmJlIHVzZWQgZm9yIHRoZSBpbml0aWFsIGNsZWFydGV4dCBwYWNrZXRzLiAgVGhlcmVm b3JlLCB0aGVyZSdzIG5vDQpyZWFzb24gdG8gdHJ5IGFuZCBkbyBzb21ldGhpbmcgZmFuY3kgb25j ZSB0aGUgc2VydmVyIGRvZXMgaGF2ZSBhDQpjaGFuY2UgdG8gc2VsZWN0IHNvbWV0aGluZywgc28g dGhlIHNlcnZlciBzaG91bGQganVzdCBwaWNrIHRoZQ0KY2xpZW50J3MgaW5pdGlhbCB2YWx1ZSBp biBtb3N0IGNhc2VzLCBhbmQgdGhlIGxvYWQgYmFsYW5jZXIgd291bGQgYmUNCmJhc2VkIG9uIHNv bWUgc29ydCBvZiBwZXJzaXN0ZW50IGhhc2hpbmctbGlrZSB0aGluZy4gKQ0KSXMgdGhpcyByaWdo dD8gSVNUTSB0aGUgcG9pbnQgb2YgYSBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQgaXMgdG8g cGVybWl0IGludGVyZXN0aW5nIChpLmUuLCBub3QgY29uc2lzdGVudCBoYXNoLWJhc2VkKSBsb2Fk IGJhbGFuY2luZyBieSB0aGUgc2VydmVyIHdpdGhvdXQgb3V0LW9mLWJhbmQgc3RhdGUgc2hhcmlu Zy4gSW4gdGhlIGdlbmVyYWwgY2FzZSwgdGhpcyBtZWFucyB0aGUgc2VydmVyLXByb3ZpZGVkIGNv bm5lY3Rpb24gSUQgYmVpbmcgdXNlZCBvbiBldmVyeSBzaW5nbGUgcGFja2V0IG9uY2UgbW9yZSB0 aGFuIGEgdHJpdmlhbCBhbW91bnQgb2Ygc3RhdGUgKHdoYXRldmVyIGZpdHMgaW4gNjQgYml0cykg bmVlZHMgdG8gYmUga25vd24gdG8gd2hhdGV2ZXIgdGhlIGV2ZW50dWFsIExCLWNob3NlbiBzZXJ2 ZXIgaXMuDQpFbmNyeXB0aW9uIGtleXMgY2Fubm90IGJlIGVuY29kZWQgaW4gNjQgYml0cy4gSXMg dGhlIGludGVudCBvZiAiZmluYWwgY2xlYXJ0ZXh0IHBhY2tldCIgY29tYmluZWQgd2l0aCAiVExT IGhhbmRzaGFrZSBhbHdheXMgaW4gdGhlIGNsZWFyIiB0aGF0IHRoZSBzZXJ2ZXItY2hvc2VuIGNv bm5lY3Rpb24gSUQgaXMgbm90IGVtcGxveWVkIHVudGlsIHRoZSBUTFMgaGFuZHNoYWtlIGhhcyBj b21wbGV0ZWQ/IElmIHNvLCBpdCBzZWVtcyB3ZSd2ZSBhbHJlYWR5IGRlY2lkZWQgdGhhdCBnbG9i YWwgc3RhdGUgc2hhcmluZyBpcyByZXF1aXJlZC4gQWx0ZXJuYXRpdmVseSwgd2UgY291bGQgYWxs b3cgZm9yIDEtUlRUIHdpdGggYSBjb25zaXN0ZW50IGhhc2gtY2hvc2VuIHNlcnZlciB0byBiZSBm b2xsb3dlZCBpbW1lZGlhdGVseSBieSBhIChwb3NzaWJseSBvcHRpbWl6ZWQpIDAtUlRUIHJlY29u bmVjdCB0byBhbiBMQi1jaG9zZW4gc2VydmVyIHdpdGggYSBzZXNzaW9uIHRpY2tldC4gT3IsIHdl IGNvdWxkIHNwbGl0IG9mZiBjb25uZWN0aW9uIElEIGFuZCBsb2FkIGJhbGFuY2VyIGNvb2tpZSBh bmQgc2V0IHRoZSBsYXR0ZXIgbXVjaCBlYXJsaWVyLg0KTW9zdGx5IEkgd291bGQgbGlrZSBjbGFy aWZpY2F0aW9uIG9uIHRoZSBhY3R1YWwgc3RhdHVzIHF1byBiZWZvcmUgdHJ5aW5nIHRvIGV4cGxv cmUgdGhlIGRlc2lnbiBzcGFjZS4NCg0KS3lsZQ0KDQo= --_000_cb9b72712d3a40c38bd97eabc4b6c5d3usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MDczMTUyNDsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ5NzMzNjQgMTcz NzkwMTU2OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZXJ2ZXItY29udHJpYnV0ZWQgQ29ubmVjdGlv biBJRCBpcyB0aGVyZSB0byBhbGxvdyBsb2FkIGJhbGFuY2VycyBsb2NhdGUgdGhlIGJhY2tlbmQg c2VydmVyIHcvbyBrZWVwaW5nIGEgZGlzdHJpYnV0ZWQgY29ubmVjdGlvbiB0YWJsZS4mbmJzcDsg VGhpcyBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCBpbiB0aGUNCiBjYXNlIG9mIGNvbm5lY3Rpb24g bWlncmF0aW9uIG9yIGxvbmctbGl2ZWQgY29ubmVjdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJl IGlzIG5vIG1hZ2ljIGFzc29jaWF0ZWQgd2l0aCDigJxsYXN0IHNlcnZlciBjbGVhcnRleHTigJ0s IGV4Y2VwdCBpdCBpcyBhIHdlbGwtZGVmaW5lZCBwb2ludDogY2xpZW50LWdlbmVyYXRlZCBjb25u ZWN0aW9uIElEIGlmIChTaG9ydC1IZWFkZXIgb3IgVHlwZT0yfDUpOyBzZXJ2ZXItZ2VuZXJhdGVk DQogb3RoZXJ3aXNlLiZuYnNwOyBbU21hbGwgcHJvYmxlbSDigJMgUHVibGljIFJlc2V0IGNhbiBo YXZlIGVpdGhlciBjb25uZWN0aW9uIElEIV0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlIGlzIGFub3Ro ZXIgcHJvcG9zYWwgYnkgU3Vib2RoIHRvIGFsbG93IHRoZSBzZXJ2ZXIgdG8gY2hvb3NlIGl0cyBj b25uZWN0aW9uIElEIGF0IGFueSB0aW1lLiZuYnNwOyBJbiB0aGF0IHByb3Bvc2FsLCBjbGllbnQg YWx3YXlzIHN0YXJ0cyB3aXRoIGNvbm5lY3Rpb24gSUQ9MCBhbmQgc2VydmVyIGlzDQogZnJlZSB0 byBjaG9vc2UgaXRzIGNvbm5lY3Rpb24gSUQgYXQgYW55IHRpbWUsIGFuZCB0aGUgY2xpZW50IHRo ZW4gYWx3YXlzIHVzZXMgdGhhdC4gVGhpcyBtYWtlcyBpdCBldmVuIGVhc2llciB0byBpZGVudGlm eSBzZXJ2ZXLigJlzIGNvbm5lY3Rpb24gSUQgKDAgb3Igbm9uLTApLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZ29yPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBLeWxlIFJvc2UgW21haWx0bzpr cm9zZUBrcm9zZS5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDMwLCAy MDE3IDExOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFp LmNvbSZndDs7IEJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBTZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQsIGZpbmFsIGNsZWFydGV4dCBw YWNrZXQsIGFuZCBsb2FkIGJhbGFuY2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSBpbnRlcnByZXRlZCB0aGUgZGlzY3Vzc2lvbiBhYm91dCBjb25uZWN0aW9uIElEIGVhcmx5IGlu IHRoZSBzZXNzaW9uIGFzICZxdW90O2V2ZXJ5dGhpbmcgcHJpb3IgdG8gdGhlIGZpbmFsIGNsZWFy dGV4dCBwYWNrZXQgcmVxdWlyZXMgbm8gbG9hZCBiYWxhbmNlciBzdGF0ZSZxdW90OywgYW5kIGFz a2VkIGZvciBjbGFyaWZpY2F0aW9uIG9uIHRoZSBqYWJiZXIgY2hhbm5lbC4gQmVuDQogS2FkdWsg cmVwbGllZDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5xKCBJIHdhcyBoZWFyaW5nIHRoYXQsIGlmIHlvdSBo YXZlIGEgbG9hZC1iYWxhbmNlciBzZXR1cCwgaXQgaGFzIHRvIGJlPGJyPg0KYWJsZSB0byBkZWFs IHdpdGggemVybyBvciAmcXVvdDtyYW5kb20mcXVvdDsgY29ubmVjdGlvbiBJRHMsIGJlY2F1c2Ug dGhleSB3aWxsPGJyPg0KYmUgdXNlZCBmb3IgdGhlIGluaXRpYWwgY2xlYXJ0ZXh0IHBhY2tldHMu Jm5ic3A7IFRoZXJlZm9yZSwgdGhlcmUncyBubzxicj4NCnJlYXNvbiB0byB0cnkgYW5kIGRvIHNv bWV0aGluZyBmYW5jeSBvbmNlIHRoZSBzZXJ2ZXIgZG9lcyBoYXZlIGE8YnI+DQpjaGFuY2UgdG8g c2VsZWN0IHNvbWV0aGluZywgc28gdGhlIHNlcnZlciBzaG91bGQganVzdCBwaWNrIHRoZTxicj4N CmNsaWVudCdzIGluaXRpYWwgdmFsdWUgaW4gbW9zdCBjYXNlcywgYW5kIHRoZSBsb2FkIGJhbGFu Y2VyIHdvdWxkIGJlPGJyPg0KYmFzZWQgb24gc29tZSBzb3J0IG9mIHBlcnNpc3RlbnQgaGFzaGlu Zy1saWtlIHRoaW5nLiApPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SXMgdGhpcyByaWdodD8gSVNUTSB0aGUg cG9pbnQgb2YgYSBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQgaXMgdG8gcGVybWl0IGludGVy ZXN0aW5nIChpLmUuLCBub3QgY29uc2lzdGVudCBoYXNoLWJhc2VkKSBsb2FkIGJhbGFuY2luZyBi eSB0aGUgc2VydmVyIHdpdGhvdXQgb3V0LW9mLWJhbmQgc3RhdGUgc2hhcmluZy4gSW4gdGhlIGdl bmVyYWwgY2FzZSwNCiB0aGlzIG1lYW5zIHRoZSBzZXJ2ZXItcHJvdmlkZWQgY29ubmVjdGlvbiBJ RCBiZWluZyB1c2VkIG9uIGV2ZXJ5IHNpbmdsZSBwYWNrZXQgb25jZSBtb3JlIHRoYW4gYSB0cml2 aWFsIGFtb3VudCBvZiBzdGF0ZSAod2hhdGV2ZXIgZml0cyBpbiA2NCBiaXRzKSBuZWVkcyB0byBi ZSBrbm93biB0byB3aGF0ZXZlciB0aGUgZXZlbnR1YWwgTEItY2hvc2VuIHNlcnZlciBpcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+RW5jcnlwdGlvbiBrZXlzIGNhbm5vdCBiZSBlbmNvZGVkIGlu IDY0IGJpdHMuIElzIHRoZSBpbnRlbnQgb2YgJnF1b3Q7ZmluYWwgY2xlYXJ0ZXh0IHBhY2tldCZx dW90OyBjb21iaW5lZCB3aXRoICZxdW90O1RMUyBoYW5kc2hha2UgYWx3YXlzIGluIHRoZSBjbGVh ciZxdW90OyB0aGF0IHRoZSBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQgaXMgbm90IGVtcGxv eWVkIHVudGlsIHRoZSBUTFMgaGFuZHNoYWtlDQogaGFzIGNvbXBsZXRlZD8gSWYgc28sIGl0IHNl ZW1zIHdlJ3ZlIGFscmVhZHkgZGVjaWRlZCB0aGF0IGdsb2JhbCBzdGF0ZSBzaGFyaW5nIGlzIHJl cXVpcmVkLiBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBhbGxvdyBmb3IgMS1SVFQgd2l0aCBhIGNv bnNpc3RlbnQgaGFzaC1jaG9zZW4gc2VydmVyIHRvIGJlIGZvbGxvd2VkIGltbWVkaWF0ZWx5IGJ5 IGEgKHBvc3NpYmx5IG9wdGltaXplZCkgMC1SVFQgcmVjb25uZWN0IHRvIGFuIExCLWNob3NlbiBz ZXJ2ZXINCiB3aXRoIGEgc2Vzc2lvbiB0aWNrZXQuIE9yLCB3ZSBjb3VsZCBzcGxpdCBvZmYgY29u bmVjdGlvbiBJRCBhbmQgbG9hZCBiYWxhbmNlciBjb29raWUgYW5kIHNldCB0aGUgbGF0dGVyIG11 Y2ggZWFybGllci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1vc3RseSBJIHdvdWxkIGxpa2UgY2xhcmlmaWNhdGlvbiBvbiB0aGUgYWN0dWFsIHN0 YXR1cyBxdW8gYmVmb3JlIHRyeWluZyB0byBleHBsb3JlIHRoZSBkZXNpZ24gc3BhY2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkt5bGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_cb9b72712d3a40c38bd97eabc4b6c5d3usma1exdag1mb5msgcorpak_-- From nobody Thu Mar 30 14:08:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C558124B0A for ; Thu, 30 Mar 2017 14:08:15 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tHkZ6LRRYc-9 for ; Thu, 30 Mar 2017 14:08:12 -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 C49771292CE for ; Thu, 30 Mar 2017 14:07:05 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2UKpsKi028286; Thu, 30 Mar 2017 22:07:03 +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=aCZ99ZUo6Ss1ZkvAKk/nwwSKnbPDa9ieHcllfUt6DYA=; b=NrHqPytjgxvSVV8XVJokjSa7EkHAXigN08IqLZdDJsttugRcwm7JUecyvz2gDduOGZst X+KWGvaAiI6EvhX+uG4dG9BbZiR8WodJ+2SIlbS5OMW+4gWJHfpRHUEbf77Tyknzmx6g NkbSK9QD1gd5T9GjYsN0fliRaYZpRJ38VsRlmC6hmW9mKAnABHT1NWF4mOcw0LHRteZh kK7JYSu7DELTEXLcbjFyWRr2gzfrDDY+8efU63YIeGlU+tUM5itMIChG3yWv/MCvjCI8 eWzLL+tnQCxGIBHhaBqlzG38TQ2d4Z0jwjcfLss1dS2RC8v+0tVtwGzqWLp112cPtHQt eA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29gfhmc68n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 22:07:03 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2UKutiU012533; Thu, 30 Mar 2017 17:07:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 29fsutsach-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Mar 2017 17:07:01 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 30 Mar 2017 17:07:01 -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.1178.4; Thu, 30 Mar 2017 17:07:00 -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.1178.000; Thu, 30 Mar 2017 17:07:00 -0400 From: "Lubashev, Igor" To: "Lubashev, Igor" , Kyle Rose , "IETF QUIC WG" CC: Benjamin Kaduk Subject: RE: Server-chosen connection ID, final cleartext packet, and load balancers Thread-Topic: Server-chosen connection ID, final cleartext packet, and load balancers Thread-Index: AQHSqXFBT0Xxj0pa3EadbItmF76VCKGt1vdAgAAIbtA= Date: Thu, 30 Mar 2017 21:07:00 +0000 Message-ID: <14266ff101264a65bacbab86274b0f78@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.44] Content-Type: multipart/alternative; boundary="_000_14266ff101264a65bacbab86274b0f78usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703300179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-30_16:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703300179 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Mar 2017 21:08:15 -0000 --_000_14266ff101264a65bacbab86274b0f78usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZXJlIGlzIG5vIG1hZ2ljIGFzc29jaWF0ZWQgd2l0aCDigJxsYXN0IHNlcnZlciBjbGVh cnRleHTigJ0sIGV4Y2VwdCBpdCBpcyBhIHdlbGwtZGVmaW5lZCBwb2ludDogY2xpZW50LWdlbmVy YXRlZCBjb25uZWN0aW9uIElEIGlmIChTaG9ydC1IZWFkZXIgb3IgVHlwZT0yfDUpOyBzZXJ2ZXIt Z2VuZXJhdGVkIG90aGVyd2lzZS4gIFtTbWFsbCBwcm9ibGVtIOKAkyBQdWJsaWMgUmVzZXQgY2Fu IGhhdmUgZWl0aGVyIGNvbm5lY3Rpb24gSUQhXS4NCg0KU29ycnksIGdvdCB0aGlzIHdyb25nLiAg KmJsdXNoKg0KDQpDbGllbnQtZ2VuZXJhdGVkIGNvbm5lY3Rpb24gSUQgaWYgKExvbmctSGVhZGVy IEFORCBUeXBlPTJ8NSksDQpTZXJ2ZXItZ2VuZXJhdGVkIGNvbm5lY3Rpb24gSUQgb3RoZXJ3aXNl LCBleGNlcHQNCk5vIElkZWEsIGlmIChMb25nLUhlYWRlciBBTkQgVHlwZT04KS4NCg0KDQpGcm9t OiBMdWJhc2hldiwgSWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb21dDQpTZW50OiBUaHVy c2RheSwgTWFyY2ggMzAsIDIwMTcgMzo1NCBQTQ0KVG86IEt5bGUgUm9zZSA8a3Jvc2VAa3Jvc2Uu b3JnPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KQ2M6IEJlbmphbWluIEthZHVrIDxr YWR1a0BtaXQuZWR1Pg0KU3ViamVjdDogUkU6IFNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRCwg ZmluYWwgY2xlYXJ0ZXh0IHBhY2tldCwgYW5kIGxvYWQgYmFsYW5jZXJzDQoNClNlcnZlci1jb250 cmlidXRlZCBDb25uZWN0aW9uIElEIGlzIHRoZXJlIHRvIGFsbG93IGxvYWQgYmFsYW5jZXJzIGxv Y2F0ZSB0aGUgYmFja2VuZCBzZXJ2ZXIgdy9vIGtlZXBpbmcgYSBkaXN0cmlidXRlZCBjb25uZWN0 aW9uIHRhYmxlLiAgVGhpcyBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCBpbiB0aGUgY2FzZSBvZiBj b25uZWN0aW9uIG1pZ3JhdGlvbiBvciBsb25nLWxpdmVkIGNvbm5lY3Rpb25zLg0KDQpUaGVyZSBp cyBubyBtYWdpYyBhc3NvY2lhdGVkIHdpdGgg4oCcbGFzdCBzZXJ2ZXIgY2xlYXJ0ZXh04oCdLCBl eGNlcHQgaXQgaXMgYSB3ZWxsLWRlZmluZWQgcG9pbnQ6IGNsaWVudC1nZW5lcmF0ZWQgY29ubmVj dGlvbiBJRCBpZiAoU2hvcnQtSGVhZGVyIG9yIFR5cGU9Mnw1KTsgc2VydmVyLWdlbmVyYXRlZCBv dGhlcndpc2UuICBbU21hbGwgcHJvYmxlbSDigJMgUHVibGljIFJlc2V0IGNhbiBoYXZlIGVpdGhl ciBjb25uZWN0aW9uIElEIV0uDQoNClRoZXJlIGlzIGFub3RoZXIgcHJvcG9zYWwgYnkgU3Vib2Ro IHRvIGFsbG93IHRoZSBzZXJ2ZXIgdG8gY2hvb3NlIGl0cyBjb25uZWN0aW9uIElEIGF0IGFueSB0 aW1lLiAgSW4gdGhhdCBwcm9wb3NhbCwgY2xpZW50IGFsd2F5cyBzdGFydHMgd2l0aCBjb25uZWN0 aW9uIElEPTAgYW5kIHNlcnZlciBpcyBmcmVlIHRvIGNob29zZSBpdHMgY29ubmVjdGlvbiBJRCBh dCBhbnkgdGltZSwgYW5kIHRoZSBjbGllbnQgdGhlbiBhbHdheXMgdXNlcyB0aGF0LiBUaGlzIG1h a2VzIGl0IGV2ZW4gZWFzaWVyIHRvIGlkZW50aWZ5IHNlcnZlcuKAmXMgY29ubmVjdGlvbiBJRCAo MCBvciBub24tMCkuDQoNCg0KLSAgICAgICAgICBJZ29yDQoNCkZyb206IEt5bGUgUm9zZSBbbWFp bHRvOmtyb3NlQGtyb3NlLm9yZ10NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAzMCwgMjAxNyAxMTox OCBBTQ0KVG86IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4+DQpDYzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJh c2hlQGFrYW1haS5jb20+PjsgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU8bWFpbHRvOmth ZHVrQG1pdC5lZHU+Pg0KU3ViamVjdDogU2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElELCBmaW5h bCBjbGVhcnRleHQgcGFja2V0LCBhbmQgbG9hZCBiYWxhbmNlcnMNCg0KSSBpbnRlcnByZXRlZCB0 aGUgZGlzY3Vzc2lvbiBhYm91dCBjb25uZWN0aW9uIElEIGVhcmx5IGluIHRoZSBzZXNzaW9uIGFz ICJldmVyeXRoaW5nIHByaW9yIHRvIHRoZSBmaW5hbCBjbGVhcnRleHQgcGFja2V0IHJlcXVpcmVz IG5vIGxvYWQgYmFsYW5jZXIgc3RhdGUiLCBhbmQgYXNrZWQgZm9yIGNsYXJpZmljYXRpb24gb24g dGhlIGphYmJlciBjaGFubmVsLiBCZW4gS2FkdWsgcmVwbGllZDoNCnEoIEkgd2FzIGhlYXJpbmcg dGhhdCwgaWYgeW91IGhhdmUgYSBsb2FkLWJhbGFuY2VyIHNldHVwLCBpdCBoYXMgdG8gYmUNCmFi bGUgdG8gZGVhbCB3aXRoIHplcm8gb3IgInJhbmRvbSIgY29ubmVjdGlvbiBJRHMsIGJlY2F1c2Ug dGhleSB3aWxsDQpiZSB1c2VkIGZvciB0aGUgaW5pdGlhbCBjbGVhcnRleHQgcGFja2V0cy4gIFRo ZXJlZm9yZSwgdGhlcmUncyBubw0KcmVhc29uIHRvIHRyeSBhbmQgZG8gc29tZXRoaW5nIGZhbmN5 IG9uY2UgdGhlIHNlcnZlciBkb2VzIGhhdmUgYQ0KY2hhbmNlIHRvIHNlbGVjdCBzb21ldGhpbmcs IHNvIHRoZSBzZXJ2ZXIgc2hvdWxkIGp1c3QgcGljayB0aGUNCmNsaWVudCdzIGluaXRpYWwgdmFs dWUgaW4gbW9zdCBjYXNlcywgYW5kIHRoZSBsb2FkIGJhbGFuY2VyIHdvdWxkIGJlDQpiYXNlZCBv biBzb21lIHNvcnQgb2YgcGVyc2lzdGVudCBoYXNoaW5nLWxpa2UgdGhpbmcuICkNCklzIHRoaXMg cmlnaHQ/IElTVE0gdGhlIHBvaW50IG9mIGEgc2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEIGlz IHRvIHBlcm1pdCBpbnRlcmVzdGluZyAoaS5lLiwgbm90IGNvbnNpc3RlbnQgaGFzaC1iYXNlZCkg bG9hZCBiYWxhbmNpbmcgYnkgdGhlIHNlcnZlciB3aXRob3V0IG91dC1vZi1iYW5kIHN0YXRlIHNo YXJpbmcuIEluIHRoZSBnZW5lcmFsIGNhc2UsIHRoaXMgbWVhbnMgdGhlIHNlcnZlci1wcm92aWRl ZCBjb25uZWN0aW9uIElEIGJlaW5nIHVzZWQgb24gZXZlcnkgc2luZ2xlIHBhY2tldCBvbmNlIG1v cmUgdGhhbiBhIHRyaXZpYWwgYW1vdW50IG9mIHN0YXRlICh3aGF0ZXZlciBmaXRzIGluIDY0IGJp dHMpIG5lZWRzIHRvIGJlIGtub3duIHRvIHdoYXRldmVyIHRoZSBldmVudHVhbCBMQi1jaG9zZW4g c2VydmVyIGlzLg0KRW5jcnlwdGlvbiBrZXlzIGNhbm5vdCBiZSBlbmNvZGVkIGluIDY0IGJpdHMu IElzIHRoZSBpbnRlbnQgb2YgImZpbmFsIGNsZWFydGV4dCBwYWNrZXQiIGNvbWJpbmVkIHdpdGgg IlRMUyBoYW5kc2hha2UgYWx3YXlzIGluIHRoZSBjbGVhciIgdGhhdCB0aGUgc2VydmVyLWNob3Nl biBjb25uZWN0aW9uIElEIGlzIG5vdCBlbXBsb3llZCB1bnRpbCB0aGUgVExTIGhhbmRzaGFrZSBo YXMgY29tcGxldGVkPyBJZiBzbywgaXQgc2VlbXMgd2UndmUgYWxyZWFkeSBkZWNpZGVkIHRoYXQg Z2xvYmFsIHN0YXRlIHNoYXJpbmcgaXMgcmVxdWlyZWQuIEFsdGVybmF0aXZlbHksIHdlIGNvdWxk IGFsbG93IGZvciAxLVJUVCB3aXRoIGEgY29uc2lzdGVudCBoYXNoLWNob3NlbiBzZXJ2ZXIgdG8g YmUgZm9sbG93ZWQgaW1tZWRpYXRlbHkgYnkgYSAocG9zc2libHkgb3B0aW1pemVkKSAwLVJUVCBy ZWNvbm5lY3QgdG8gYW4gTEItY2hvc2VuIHNlcnZlciB3aXRoIGEgc2Vzc2lvbiB0aWNrZXQuIE9y LCB3ZSBjb3VsZCBzcGxpdCBvZmYgY29ubmVjdGlvbiBJRCBhbmQgbG9hZCBiYWxhbmNlciBjb29r aWUgYW5kIHNldCB0aGUgbGF0dGVyIG11Y2ggZWFybGllci4NCk1vc3RseSBJIHdvdWxkIGxpa2Ug Y2xhcmlmaWNhdGlvbiBvbiB0aGUgYWN0dWFsIHN0YXR1cyBxdW8gYmVmb3JlIHRyeWluZyB0byBl eHBsb3JlIHRoZSBkZXNpZ24gc3BhY2UuDQoNCkt5bGUNCg0K --_000_14266ff101264a65bacbab86274b0f78usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6NTA3MzE1MjQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE0OTczMzY0IDE3Mzc5MDE1NjggNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDozODgxOTM1NTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0yMTI4ODMzMzg2IDE0NjUzOTYwOTggNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlIGlzIG5vIG1hZ2ljIGFzc29jaWF0ZWQgd2l0aCDi gJxsYXN0IHNlcnZlciBjbGVhcnRleHTigJ0sIGV4Y2VwdCBpdCBpcyBhIHdlbGwtZGVmaW5lZCBw b2ludDogY2xpZW50LWdlbmVyYXRlZCBjb25uZWN0aW9uIElEIGlmIChTaG9ydC1IZWFkZXIgb3Ig VHlwZT0yfDUpOyBzZXJ2ZXItZ2VuZXJhdGVkDQogb3RoZXJ3aXNlLiZuYnNwOyBbU21hbGwgcHJv YmxlbSDigJMgUHVibGljIFJlc2V0IGNhbiBoYXZlIGVpdGhlciBjb25uZWN0aW9uIElEIV0uPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpTb3JyeSwgZ290IHRoaXMgd3JvbmcuJm5i c3A7ICpibHVzaCo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2xpZW50LWdlbmVyYXRlZCBjb25uZWN0aW9uIElE IGlmIChMb25nLUhlYWRlciBBTkQgVHlwZT0yfDUpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VydmVyLWdlbmVyYXRlZCBjb25u ZWN0aW9uIElEIG90aGVyd2lzZSwgZXhjZXB0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ObyBJZGVhLCBpZiAoTG9uZy1IZWFkZXIg QU5EIFR5cGU9OCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMdWJh c2hldiwgSWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3IDM6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IEt5bGUg Um9zZSAmbHQ7a3Jvc2VAa3Jvc2Uub3JnJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYu b3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gQmVuamFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBTZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQs IGZpbmFsIGNsZWFydGV4dCBwYWNrZXQsIGFuZCBsb2FkIGJhbGFuY2VyczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VydmVy LWNvbnRyaWJ1dGVkIENvbm5lY3Rpb24gSUQgaXMgdGhlcmUgdG8gYWxsb3cgbG9hZCBiYWxhbmNl cnMgbG9jYXRlIHRoZSBiYWNrZW5kIHNlcnZlciB3L28ga2VlcGluZyBhIGRpc3RyaWJ1dGVkIGNv bm5lY3Rpb24gdGFibGUuJm5ic3A7IFRoaXMgaXMgZXNwZWNpYWxseSBpbXBvcnRhbnQgaW4gdGhl DQogY2FzZSBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbiBvciBsb25nLWxpdmVkIGNvbm5lY3Rpb25z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UaGVyZSBpcyBubyBtYWdpYyBhc3NvY2lhdGVkIHdpdGgg4oCcbGFz dCBzZXJ2ZXIgY2xlYXJ0ZXh04oCdLCBleGNlcHQgaXQgaXMgYSB3ZWxsLWRlZmluZWQgcG9pbnQ6 IGNsaWVudC1nZW5lcmF0ZWQgY29ubmVjdGlvbiBJRCBpZiAoU2hvcnQtSGVhZGVyIG9yIFR5cGU9 Mnw1KTsgc2VydmVyLWdlbmVyYXRlZA0KIG90aGVyd2lzZS4mbmJzcDsgW1NtYWxsIHByb2JsZW0g 4oCTIFB1YmxpYyBSZXNldCBjYW4gaGF2ZSBlaXRoZXIgY29ubmVjdGlvbiBJRCFdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGVyZSBpcyBhbm90aGVyIHByb3Bvc2FsIGJ5IFN1Ym9kaCB0byBhbGxvdyB0aGUg c2VydmVyIHRvIGNob29zZSBpdHMgY29ubmVjdGlvbiBJRCBhdCBhbnkgdGltZS4mbmJzcDsgSW4g dGhhdCBwcm9wb3NhbCwgY2xpZW50IGFsd2F5cyBzdGFydHMgd2l0aCBjb25uZWN0aW9uIElEPTAg YW5kIHNlcnZlciBpcw0KIGZyZWUgdG8gY2hvb3NlIGl0cyBjb25uZWN0aW9uIElEIGF0IGFueSB0 aW1lLCBhbmQgdGhlIGNsaWVudCB0aGVuIGFsd2F5cyB1c2VzIHRoYXQuIFRoaXMgbWFrZXMgaXQg ZXZlbiBlYXNpZXIgdG8gaWRlbnRpZnkgc2VydmVy4oCZcyBjb25uZWN0aW9uIElEICgwIG9yIG5v bi0wKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SWdvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gS3lsZSBSb3NlIFs8YSBocmVmPSJtYWlsdG86a3Jvc2VAa3Jvc2Uub3JnIj5tYWlsdG86a3Jv c2VAa3Jvc2Uub3JnPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFyY2ggMzAs IDIwMTcgMTE6MTggQU08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Ij5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs7IEJlbmphbWluIEthZHVrICZsdDs8YSBocmVm PSJtYWlsdG86a2FkdWtAbWl0LmVkdSI+a2FkdWtAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRCwgZmluYWwgY2xlYXJ0ZXh0IHBh Y2tldCwgYW5kIGxvYWQgYmFsYW5jZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5J IGludGVycHJldGVkIHRoZSBkaXNjdXNzaW9uIGFib3V0IGNvbm5lY3Rpb24gSUQgZWFybHkgaW4g dGhlIHNlc3Npb24gYXMgJnF1b3Q7ZXZlcnl0aGluZyBwcmlvciB0byB0aGUgZmluYWwgY2xlYXJ0 ZXh0IHBhY2tldCByZXF1aXJlcyBubyBsb2FkIGJhbGFuY2VyIHN0YXRlJnF1b3Q7LCBhbmQgYXNr ZWQgZm9yIGNsYXJpZmljYXRpb24gb24gdGhlIGphYmJlciBjaGFubmVsLiBCZW4NCiBLYWR1ayBy ZXBsaWVkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPnEoIEkgd2FzIGhlYXJpbmcgdGhhdCwgaWYgeW91IGhh dmUgYSBsb2FkLWJhbGFuY2VyIHNldHVwLCBpdCBoYXMgdG8gYmU8YnI+DQphYmxlIHRvIGRlYWwg d2l0aCB6ZXJvIG9yICZxdW90O3JhbmRvbSZxdW90OyBjb25uZWN0aW9uIElEcywgYmVjYXVzZSB0 aGV5IHdpbGw8YnI+DQpiZSB1c2VkIGZvciB0aGUgaW5pdGlhbCBjbGVhcnRleHQgcGFja2V0cy4m bmJzcDsgVGhlcmVmb3JlLCB0aGVyZSdzIG5vPGJyPg0KcmVhc29uIHRvIHRyeSBhbmQgZG8gc29t ZXRoaW5nIGZhbmN5IG9uY2UgdGhlIHNlcnZlciBkb2VzIGhhdmUgYTxicj4NCmNoYW5jZSB0byBz ZWxlY3Qgc29tZXRoaW5nLCBzbyB0aGUgc2VydmVyIHNob3VsZCBqdXN0IHBpY2sgdGhlPGJyPg0K Y2xpZW50J3MgaW5pdGlhbCB2YWx1ZSBpbiBtb3N0IGNhc2VzLCBhbmQgdGhlIGxvYWQgYmFsYW5j ZXIgd291bGQgYmU8YnI+DQpiYXNlZCBvbiBzb21lIHNvcnQgb2YgcGVyc2lzdGVudCBoYXNoaW5n LWxpa2UgdGhpbmcuICk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JcyB0aGlzIHJpZ2h0PyBJU1RNIHRoZSBw b2ludCBvZiBhIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRCBpcyB0byBwZXJtaXQgaW50ZXJl c3RpbmcgKGkuZS4sIG5vdCBjb25zaXN0ZW50IGhhc2gtYmFzZWQpIGxvYWQgYmFsYW5jaW5nIGJ5 IHRoZSBzZXJ2ZXIgd2l0aG91dCBvdXQtb2YtYmFuZCBzdGF0ZSBzaGFyaW5nLiBJbiB0aGUgZ2Vu ZXJhbCBjYXNlLA0KIHRoaXMgbWVhbnMgdGhlIHNlcnZlci1wcm92aWRlZCBjb25uZWN0aW9uIElE IGJlaW5nIHVzZWQgb24gZXZlcnkgc2luZ2xlIHBhY2tldCBvbmNlIG1vcmUgdGhhbiBhIHRyaXZp YWwgYW1vdW50IG9mIHN0YXRlICh3aGF0ZXZlciBmaXRzIGluIDY0IGJpdHMpIG5lZWRzIHRvIGJl IGtub3duIHRvIHdoYXRldmVyIHRoZSBldmVudHVhbCBMQi1jaG9zZW4gc2VydmVyIGlzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5FbmNyeXB0aW9uIGtleXMgY2Fubm90IGJlIGVuY29kZWQgaW4g NjQgYml0cy4gSXMgdGhlIGludGVudCBvZiAmcXVvdDtmaW5hbCBjbGVhcnRleHQgcGFja2V0JnF1 b3Q7IGNvbWJpbmVkIHdpdGggJnF1b3Q7VExTIGhhbmRzaGFrZSBhbHdheXMgaW4gdGhlIGNsZWFy JnF1b3Q7IHRoYXQgdGhlIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRCBpcyBub3QgZW1wbG95 ZWQgdW50aWwgdGhlIFRMUyBoYW5kc2hha2UNCiBoYXMgY29tcGxldGVkPyBJZiBzbywgaXQgc2Vl bXMgd2UndmUgYWxyZWFkeSBkZWNpZGVkIHRoYXQgZ2xvYmFsIHN0YXRlIHNoYXJpbmcgaXMgcmVx dWlyZWQuIEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGFsbG93IGZvciAxLVJUVCB3aXRoIGEgY29u c2lzdGVudCBoYXNoLWNob3NlbiBzZXJ2ZXIgdG8gYmUgZm9sbG93ZWQgaW1tZWRpYXRlbHkgYnkg YSAocG9zc2libHkgb3B0aW1pemVkKSAwLVJUVCByZWNvbm5lY3QgdG8gYW4gTEItY2hvc2VuIHNl cnZlcg0KIHdpdGggYSBzZXNzaW9uIHRpY2tldC4gT3IsIHdlIGNvdWxkIHNwbGl0IG9mZiBjb25u ZWN0aW9uIElEIGFuZCBsb2FkIGJhbGFuY2VyIGNvb2tpZSBhbmQgc2V0IHRoZSBsYXR0ZXIgbXVj aCBlYXJsaWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TW9zdGx5IEkgd291bGQgbGlrZSBjbGFyaWZpY2F0aW9uIG9uIHRoZSBhY3R1YWwgc3Rh dHVzIHF1byBiZWZvcmUgdHJ5aW5nIHRvIGV4cGxvcmUgdGhlIGRlc2lnbiBzcGFjZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S3lsZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_14266ff101264a65bacbab86274b0f78usma1exdag1mb5msgcorpak_-- From nobody Thu Mar 30 17:04:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D864312869B for ; Thu, 30 Mar 2017 17:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGC0w3-ejmLm for ; Thu, 30 Mar 2017 17:04:45 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A881270A3 for ; Thu, 30 Mar 2017 17:04:44 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id d201so24657494qkc.0 for ; Thu, 30 Mar 2017 17:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=CyC+86GyZNPV1hRec3SpkPBhtx7afroAamxFBSLaLWg=; b=FvhmsXea18IWrkSkcWXOIBX7MDRWxe3xXWznqM9qWUZfLD9jM+zXAlc2fjze4xFdtV yP417RQ+ljcUmlA+H0mhPGiS2Kh0J7dwqwMh7LFms8ODsLVUkXO9jWPTqcfFRkllBFM4 1o2ma9jMFvbHvr/RlUY1BOB+5VxJ+97+d404aeO2T5j9uF8Zaq2tZTlH2X93vaZjW1ru dJfuDtX6b8upZWL4DtgtoOTz7enL44rysMIXgeXxZYP7b3bnTfJw2drdr3SvtcfGtkqB Ag15xF7RuhVCefWj2bcFQib/WM632yweKkbBM34jIf5JNqqMYr/ea7fDjoLHkBaoh5Gx 74fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=CyC+86GyZNPV1hRec3SpkPBhtx7afroAamxFBSLaLWg=; b=dHH70YBUB89mEHbvTHmvuKhWt5WdkG76ban+up4k8xXcykkCDaQIGqsYX6GRE7PkEG 1QXsgSzTuvSF9XiqSUvJuJneY3rtfkm6+qyHRmeAgHj1CpyQhOmJ2rtaymFfQlnoUhip N3gJJhKOCAvl+3nHBTSay7/QCYTrGmY4Tq+GAuRSdImQtbdw8QtsIHO4LEez/iyyENmo skD84uj50+36ZlsiBCnoTINyNM3zan0IEvQH73jIOu7jmsLxz8RK31hcv/wsYTjEoFwf LVVB91Qg6n6ZjGw55O3twjaq3LrayjqjweWZznuSPFkXpUkJpx4xDHN2NBjKZ4PTpyUN bf3Q== X-Gm-Message-State: AFeK/H3NohkyKJiAZMrgj251qwZ2RRTbrW+vnwHDN/bV+gldMHZFFL0/Fxcnl4UGoCs+Yqj3g0v61gfURD3GNg== X-Received: by 10.55.187.132 with SMTP id l126mr118312qkf.236.1490918683748; Thu, 30 Mar 2017 17:04:43 -0700 (PDT) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.12.149.169 with HTTP; Thu, 30 Mar 2017 17:04:43 -0700 (PDT) From: Jim Roskind Date: Thu, 30 Mar 2017 19:04:43 -0500 X-Google-Sender-Auth: kxTTUgxvt3_RI5WluZdRIvdO2nY Message-ID: Subject: Public Reset; Connection ID; Attack; Defense To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c0440c688b576054bfb8ec9 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Mar 2017 00:04:47 -0000 --94eb2c0440c688b576054bfb8ec9 Content-Type: text/plain; charset=UTF-8 I was asked to write up a vaguely plausible attack on a PublicReset that I noticed a few years back. Awareness of this caused me to not push (while I was at Google) for the implementation and deployment of authenticated PublicReset (we just deployed the forgeable flavor). I could see the resolution required(?) server selected IDs, which was anticipated as being useful for a variety of additional reasons. Now that we're finally moving in that direction, it is worth mentioning the issue. PROBLEM A PublicReset needs to be created by a server when a server receives packets that it believes are related to a previously closed connection. For example, this commonly(?) happens when a server bounces, losing all state, and is incapable of continuing the encrypted/authenticated dialog (i.e., the server no longer has applicable key material, and must instead construct the authenticated PublicReset based only on the ConnectionID and perhaps some persistent private key material). A PublicReset may similarly be generated if a connection has been closed for a while, and client sends a request using a ConnectionID that has been forgotten by a server. At the same time, the design requires that it is hard (impossible) for a third party attacker (disrupter?) to send a valid PublicReset. The general expectation is that a client (involved in an actual connection) will receive at least enough information to authenticate a PublicReset. Most critically, when a PublicReset is used, it is very publicly visible, and can be replayed. ...but that would only be an issue if the ConnectionID was reused. ATTACK: With client-selected ConnectionID, it was plausible that an adversary could: - Observe, and possibly forestall (delay?) transmission of a ClientHello containing ConnectionID X sent towards site Y - Race off to some server Y' and quickly obtain from Y' (an affiliated server?) effectively some PublicReset validation data for ConnectionID X, sufficient to be able to forge future PublicReset packets with said ConnectionID. For instance, it might receive a sample PublicReset for that ConnectionID! - Allow the original packet from to proceed to the original site Y, creating a connection using said ConnectionID X. The malicious racer can then disseminate a PublicReset packet at any point in the future. This (partially) negates the value of PublicReset feature. DEFENSE By allowing the server to specify a connectionID, we prevent a malicious racer from obtaining such info about an applicable PublicReset. Since we are already moving in this direction (server selects ConnectionID), we should probably continue to codify this, before proceeding deploy or to codify the details of the PublicReset. --94eb2c0440c688b576054bfb8ec9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was asked to write up a vaguely plausible attack on a Pu= blicReset that I noticed a few years back.=C2=A0 Awareness of this caused m= e to not push (while I was at Google) for the implementation and deployment= of authenticated PublicReset (we just deployed the forgeable flavor).=C2= =A0 I could see the resolution required(?) server selected IDs, which was a= nticipated as being useful for a variety of additional reasons. Now that we= 're finally moving in that direction, it is worth mentioning the issue.=

PROBLEM

A PublicReset needs to= be created by a server when a server receives packets that it believes are= related to a previously closed connection.=C2=A0 For example, this commonl= y(?) happens when a server bounces, losing all state, and is incapable of c= ontinuing the encrypted/authenticated dialog (i.e., the server no longer ha= s applicable key material, and must instead construct the authenticated Pub= licReset based only on the ConnectionID and perhaps some persistent private= key material). A PublicReset may similarly be generated if a connection ha= s been closed for a while, and client sends a request using a ConnectionID = that has been forgotten by a server.

At the same t= ime, the design requires that it is hard (impossible) for a third party att= acker (disrupter?) to send a valid PublicReset.

Th= e general expectation is that a client (involved in an actual connection) w= ill receive at least enough information to authenticate a PublicReset.=C2= =A0 Most critically, when a PublicReset is used, it is very publicly visibl= e, and can be replayed. =C2=A0...but that would only be an issue if the Con= nectionID was reused.

ATTACK:

=
With client-selected ConnectionID, it was plausible that an adversary = could:
  • Observe, and possibly forestall (delay?) transmiss= ion of a ClientHello containing ConnectionID X sent towards site Y
  • = Race off to some server Y' and quickly obtain from Y' (an affiliate= d server?) effectively some PublicReset validation data for ConnectionID X,= sufficient to be able to forge future PublicReset packets with said Connec= tionID. For instance, it might receive a sample PublicReset for that Connec= tionID!
  • Allow the original packet from to proceed to the original s= ite Y, creating a connection using said ConnectionID X.
The m= alicious racer can then disseminate a PublicReset packet at any point in th= e future.=C2=A0 This (partially) negates the value of PublicReset feature.<= /div>

DEFENSE

By allowing= the server to specify a connectionID, we prevent a malicious racer from ob= taining such info about an applicable PublicReset. =C2=A0

Since we are already moving in this direction (server selects Conne= ctionID), we should probably continue to codify this, before proceeding dep= loy or to codify the details of the PublicReset.

--94eb2c0440c688b576054bfb8ec9-- From nobody Thu Mar 30 22:42:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9867D1297C6 for ; Thu, 30 Mar 2017 22:42: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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUO1zq5vKfPp for ; Thu, 30 Mar 2017 22:42:19 -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 30D71128C82 for ; Thu, 30 Mar 2017 22:42:19 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2V5gDLw000642; Fri, 31 Mar 2017 06:42:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=uq8nI4nU6FEZf2T3pzStQfZjiCcSr1Z0wIku7vzzanc=; b=Sl4YZUpVO0DLQh0RiA04sx7fe4LRoUGEDOyTnTXIlNGS7egUr1Sr0CCm5pc9ms8CIH4j ZJKWaTG8b3Q4kel0SwoxeaLPkMw/DNOYOpo4vivw94Q0hBQ/O4sMO1NTPyDOnR7IcHNQ T7wzeDP9QhyjPztlr/FsFS3qTv6uAfNfeu1GlqB7uQokZUC/bIlCjozesoRciovP7XTw 2LMdmk4gTOiVVKIXaRJaAyU6pi8Lhsx8jsTZMkh3YRpxWsi+uKp6zN8iU56v53DEdwxf 0ySEHe3/9YtnFugvZyfwF4A9GGFpLKudaHQph2Rj2RAqYhXVYc1XkoIkH95aDTKVcryX MQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29gfhme46c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Mar 2017 06:42:15 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2V5gE3G000829; Fri, 31 Mar 2017 01:42:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 29fsutsfhv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 31 Mar 2017 01:42:14 -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.1178.4; Fri, 31 Mar 2017 01:42:13 -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.1178.000; Fri, 31 Mar 2017 01:42:13 -0400 From: "Lubashev, Igor" To: Jim Roskind , IETF QUIC WG Subject: RE: Public Reset; Connection ID; Attack; Defense Thread-Topic: Public Reset; Connection ID; Attack; Defense Thread-Index: AQHSqbJr7QmCPcVnskWVIgJdAE8NYaGuaQgQ Date: Fri, 31 Mar 2017 05:42:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.68] Content-Type: multipart/alternative; boundary="_000_e4f61453a3c04efaa35647adf63f9491usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703310052 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_04:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703310052 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Mar 2017 05:42:22 -0000 --_000_e4f61453a3c04efaa35647adf63f9491usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2tlciBzZWVtcyBpbnRlcmVzdGVkIGluIGRlbnlpbmcgWCBjb21tdW5pY2F0aW5n IHdpdGggWSBhbmQgcG9zc2Vzc2VzIHRoZSBjYXBhYmlsaXR5IHRvIChhKSByZWNlaXZlIGEgY29w eSBvZiBhbGwgWOKGklkgdHJhZmZpYzsgKGIpIGluamVjdCBwYWNrZXRzIHRvd2FyZCBYLCBzcG9v ZmluZyBZLCAoYykgb3V0LXJhY2UgWOKGklkgcGFja2V0cyB0byBZLiAgVGhhdCBhdHRhY2tlciBj YW4gc2ltcGx5IHVzZSBpdHMgKGEpIGFuZCAoYykgYWJpbGl0aWVzIHRvIGNhcHR1cmUgWOKAmXMg Y2xpZW50LWhlbGxvLCBtb2RpZnkgaXQgYSBsaXR0bGUgLS0gbGVhdmluZyBjbGllbnQtaWQgYWxv bmUsIGFuZCByYWNlIGl0IHRvIFkuICBBcyBhIHJlc3VsdCwgWOKAmXMgYWN0dWFsIHBhY2tldCB3 aWxsIGJlIGlnbm9yZWQgYW5kIHRoZSBoYW5kc2hha2Ugd2lsbCBmYWlsLg0KDQpJIGFtIG5vdCBj b25maWRlbnQgdGhhdCBzZXJ2ZXItc2VsZWN0ZWQgY29ubmVjdGlvbiBpZCB3b3VsZCBoZWxwIGhl cmUuICBUaGlzIHNlZW1zIHRvIGJlIGEgaGFyZCBwcm9ibGVtIHRvIHByb3RlY3QgY29ubmVjdGlv biBpbml0aWF0aW9uIGZyb20gYW4gYXR0YWNrZXIgY2FwYWJsZSBvZiAoYSkgYW5kIChjKS4NCg0K DQotICAgICAgICAgIElnb3INCg0KDQpGcm9tOiBKaW0gUm9za2luZCBbbWFpbHRvOkppbVJvc2tp bmRAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3IDc6MDUgUE0NClRv OiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBQdWJsaWMgUmVzZXQ7IENv bm5lY3Rpb24gSUQ7IEF0dGFjazsgRGVmZW5zZQ0KDQpJIHdhcyBhc2tlZCB0byB3cml0ZSB1cCBh IHZhZ3VlbHkgcGxhdXNpYmxlIGF0dGFjayBvbiBhIFB1YmxpY1Jlc2V0IHRoYXQgSSBub3RpY2Vk IGEgZmV3IHllYXJzIGJhY2suICBBd2FyZW5lc3Mgb2YgdGhpcyBjYXVzZWQgbWUgdG8gbm90IHB1 c2ggKHdoaWxlIEkgd2FzIGF0IEdvb2dsZSkgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgZGVw bG95bWVudCBvZiBhdXRoZW50aWNhdGVkIFB1YmxpY1Jlc2V0ICh3ZSBqdXN0IGRlcGxveWVkIHRo ZSBmb3JnZWFibGUgZmxhdm9yKS4gIEkgY291bGQgc2VlIHRoZSByZXNvbHV0aW9uIHJlcXVpcmVk KD8pIHNlcnZlciBzZWxlY3RlZCBJRHMsIHdoaWNoIHdhcyBhbnRpY2lwYXRlZCBhcyBiZWluZyB1 c2VmdWwgZm9yIGEgdmFyaWV0eSBvZiBhZGRpdGlvbmFsIHJlYXNvbnMuIE5vdyB0aGF0IHdlJ3Jl IGZpbmFsbHkgbW92aW5nIGluIHRoYXQgZGlyZWN0aW9uLCBpdCBpcyB3b3J0aCBtZW50aW9uaW5n IHRoZSBpc3N1ZS4NCg0KUFJPQkxFTQ0KDQpBIFB1YmxpY1Jlc2V0IG5lZWRzIHRvIGJlIGNyZWF0 ZWQgYnkgYSBzZXJ2ZXIgd2hlbiBhIHNlcnZlciByZWNlaXZlcyBwYWNrZXRzIHRoYXQgaXQgYmVs aWV2ZXMgYXJlIHJlbGF0ZWQgdG8gYSBwcmV2aW91c2x5IGNsb3NlZCBjb25uZWN0aW9uLiAgRm9y IGV4YW1wbGUsIHRoaXMgY29tbW9ubHkoPykgaGFwcGVucyB3aGVuIGEgc2VydmVyIGJvdW5jZXMs IGxvc2luZyBhbGwgc3RhdGUsIGFuZCBpcyBpbmNhcGFibGUgb2YgY29udGludWluZyB0aGUgZW5j cnlwdGVkL2F1dGhlbnRpY2F0ZWQgZGlhbG9nIChpLmUuLCB0aGUgc2VydmVyIG5vIGxvbmdlciBo YXMgYXBwbGljYWJsZSBrZXkgbWF0ZXJpYWwsIGFuZCBtdXN0IGluc3RlYWQgY29uc3RydWN0IHRo ZSBhdXRoZW50aWNhdGVkIFB1YmxpY1Jlc2V0IGJhc2VkIG9ubHkgb24gdGhlIENvbm5lY3Rpb25J RCBhbmQgcGVyaGFwcyBzb21lIHBlcnNpc3RlbnQgcHJpdmF0ZSBrZXkgbWF0ZXJpYWwpLiBBIFB1 YmxpY1Jlc2V0IG1heSBzaW1pbGFybHkgYmUgZ2VuZXJhdGVkIGlmIGEgY29ubmVjdGlvbiBoYXMg YmVlbiBjbG9zZWQgZm9yIGEgd2hpbGUsIGFuZCBjbGllbnQgc2VuZHMgYSByZXF1ZXN0IHVzaW5n IGEgQ29ubmVjdGlvbklEIHRoYXQgaGFzIGJlZW4gZm9yZ290dGVuIGJ5IGEgc2VydmVyLg0KDQpB dCB0aGUgc2FtZSB0aW1lLCB0aGUgZGVzaWduIHJlcXVpcmVzIHRoYXQgaXQgaXMgaGFyZCAoaW1w b3NzaWJsZSkgZm9yIGEgdGhpcmQgcGFydHkgYXR0YWNrZXIgKGRpc3J1cHRlcj8pIHRvIHNlbmQg YSB2YWxpZCBQdWJsaWNSZXNldC4NCg0KVGhlIGdlbmVyYWwgZXhwZWN0YXRpb24gaXMgdGhhdCBh IGNsaWVudCAoaW52b2x2ZWQgaW4gYW4gYWN0dWFsIGNvbm5lY3Rpb24pIHdpbGwgcmVjZWl2ZSBh dCBsZWFzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8gYXV0aGVudGljYXRlIGEgUHVibGljUmVzZXQu ICBNb3N0IGNyaXRpY2FsbHksIHdoZW4gYSBQdWJsaWNSZXNldCBpcyB1c2VkLCBpdCBpcyB2ZXJ5 IHB1YmxpY2x5IHZpc2libGUsIGFuZCBjYW4gYmUgcmVwbGF5ZWQuICAuLi5idXQgdGhhdCB3b3Vs ZCBvbmx5IGJlIGFuIGlzc3VlIGlmIHRoZSBDb25uZWN0aW9uSUQgd2FzIHJldXNlZC4NCg0KQVRU QUNLOg0KDQpXaXRoIGNsaWVudC1zZWxlY3RlZCBDb25uZWN0aW9uSUQsIGl0IHdhcyBwbGF1c2li bGUgdGhhdCBhbiBhZHZlcnNhcnkgY291bGQ6DQoNCiAgKiAgIE9ic2VydmUsIGFuZCBwb3NzaWJs eSBmb3Jlc3RhbGwgKGRlbGF5PykgdHJhbnNtaXNzaW9uIG9mIGEgQ2xpZW50SGVsbG8gY29udGFp bmluZyBDb25uZWN0aW9uSUQgWCBzZW50IHRvd2FyZHMgc2l0ZSBZDQogICogICBSYWNlIG9mZiB0 byBzb21lIHNlcnZlciBZJyBhbmQgcXVpY2tseSBvYnRhaW4gZnJvbSBZJyAoYW4gYWZmaWxpYXRl ZCBzZXJ2ZXI/KSBlZmZlY3RpdmVseSBzb21lIFB1YmxpY1Jlc2V0IHZhbGlkYXRpb24gZGF0YSBm b3IgQ29ubmVjdGlvbklEIFgsIHN1ZmZpY2llbnQgdG8gYmUgYWJsZSB0byBmb3JnZSBmdXR1cmUg UHVibGljUmVzZXQgcGFja2V0cyB3aXRoIHNhaWQgQ29ubmVjdGlvbklELiBGb3IgaW5zdGFuY2Us IGl0IG1pZ2h0IHJlY2VpdmUgYSBzYW1wbGUgUHVibGljUmVzZXQgZm9yIHRoYXQgQ29ubmVjdGlv bklEIQ0KICAqICAgQWxsb3cgdGhlIG9yaWdpbmFsIHBhY2tldCBmcm9tIHRvIHByb2NlZWQgdG8g dGhlIG9yaWdpbmFsIHNpdGUgWSwgY3JlYXRpbmcgYSBjb25uZWN0aW9uIHVzaW5nIHNhaWQgQ29u bmVjdGlvbklEIFguDQpUaGUgbWFsaWNpb3VzIHJhY2VyIGNhbiB0aGVuIGRpc3NlbWluYXRlIGEg UHVibGljUmVzZXQgcGFja2V0IGF0IGFueSBwb2ludCBpbiB0aGUgZnV0dXJlLiAgVGhpcyAocGFy dGlhbGx5KSBuZWdhdGVzIHRoZSB2YWx1ZSBvZiBQdWJsaWNSZXNldCBmZWF0dXJlLg0KDQpERUZF TlNFDQoNCkJ5IGFsbG93aW5nIHRoZSBzZXJ2ZXIgdG8gc3BlY2lmeSBhIGNvbm5lY3Rpb25JRCwg d2UgcHJldmVudCBhIG1hbGljaW91cyByYWNlciBmcm9tIG9idGFpbmluZyBzdWNoIGluZm8gYWJv dXQgYW4gYXBwbGljYWJsZSBQdWJsaWNSZXNldC4NCg0KU2luY2Ugd2UgYXJlIGFscmVhZHkgbW92 aW5nIGluIHRoaXMgZGlyZWN0aW9uIChzZXJ2ZXIgc2VsZWN0cyBDb25uZWN0aW9uSUQpLCB3ZSBz aG91bGQgcHJvYmFibHkgY29udGludWUgdG8gY29kaWZ5IHRoaXMsIGJlZm9yZSBwcm9jZWVkaW5n IGRlcGxveSBvciB0byBjb2RpZnkgdGhlIGRldGFpbHMgb2YgdGhlIFB1YmxpY1Jlc2V0Lg0KDQo= --_000_e4f61453a3c04efaa35647adf63f9491usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTk2MzgyMzQ4Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzkxOTQ5MDU2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNDQ5NzM2OTg3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTUzMzgyNTU2IDExNTkxMjcxMTIgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyBhdHRhY2tlciBzZWVtcyBpbnRlcmVzdGVkIGluIGRlbnlpbmcgWCBj b21tdW5pY2F0aW5nIHdpdGggWSBhbmQgcG9zc2Vzc2VzIHRoZSBjYXBhYmlsaXR5IHRvIChhKSBy ZWNlaXZlIGEgY29weSBvZiBhbGwgWOKGklkgdHJhZmZpYzsgKGIpIGluamVjdCBwYWNrZXRzIHRv d2FyZCBYLCBzcG9vZmluZw0KIFksIChjKSBvdXQtcmFjZSBY4oaSWSBwYWNrZXRzIHRvIFkuJm5i c3A7IFRoYXQgYXR0YWNrZXIgY2FuIHNpbXBseSB1c2UgaXRzIChhKSBhbmQgKGMpIGFiaWxpdGll cyB0byBjYXB0dXJlIFjigJlzIGNsaWVudC1oZWxsbywgbW9kaWZ5IGl0IGEgbGl0dGxlIC0tIGxl YXZpbmcgY2xpZW50LWlkIGFsb25lLCBhbmQgcmFjZSBpdCB0byBZLiAmbmJzcDtBcyBhIHJlc3Vs dCwgWOKAmXMgYWN0dWFsIHBhY2tldCB3aWxsIGJlIGlnbm9yZWQgYW5kIHRoZSBoYW5kc2hha2Ug d2lsbCBmYWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIG5vdCBjb25maWRlbnQgdGhhdCBzZXJ2ZXIt c2VsZWN0ZWQgY29ubmVjdGlvbiBpZCB3b3VsZCBoZWxwIGhlcmUuJm5ic3A7IFRoaXMgc2VlbXMg dG8gYmUgYSBoYXJkIHByb2JsZW0gdG8gcHJvdGVjdCBjb25uZWN0aW9uIGluaXRpYXRpb24gZnJv bSBhbiBhdHRhY2tlciBjYXBhYmxlIG9mIChhKSBhbmQNCiAoYykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklnb3I8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSmltIFJvc2tp bmQgW21haWx0bzpKaW1Sb3NraW5kQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgTWFyY2ggMzAsIDIwMTcgNzowNSBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBQdWJsaWMgUmVzZXQ7 IENvbm5lY3Rpb24gSUQ7IEF0dGFjazsgRGVmZW5zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgd2FzIGFza2VkIHRvIHdyaXRlIHVwIGEgdmFndWVseSBwbGF1c2libGUg YXR0YWNrIG9uIGEgUHVibGljUmVzZXQgdGhhdCBJIG5vdGljZWQgYSBmZXcgeWVhcnMgYmFjay4m bmJzcDsgQXdhcmVuZXNzIG9mIHRoaXMgY2F1c2VkIG1lIHRvIG5vdCBwdXNoICh3aGlsZSBJIHdh cyBhdCBHb29nbGUpIGZvciB0aGUgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgYXV0 aGVudGljYXRlZCBQdWJsaWNSZXNldCAod2UNCiBqdXN0IGRlcGxveWVkIHRoZSBmb3JnZWFibGUg Zmxhdm9yKS4mbmJzcDsgSSBjb3VsZCBzZWUgdGhlIHJlc29sdXRpb24gcmVxdWlyZWQoPykgc2Vy dmVyIHNlbGVjdGVkIElEcywgd2hpY2ggd2FzIGFudGljaXBhdGVkIGFzIGJlaW5nIHVzZWZ1bCBm b3IgYSB2YXJpZXR5IG9mIGFkZGl0aW9uYWwgcmVhc29ucy4gTm93IHRoYXQgd2UncmUgZmluYWxs eSBtb3ZpbmcgaW4gdGhhdCBkaXJlY3Rpb24sIGl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhlIGlz c3VlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UFJPQkxF TTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B IFB1YmxpY1Jlc2V0IG5lZWRzIHRvIGJlIGNyZWF0ZWQgYnkgYSBzZXJ2ZXIgd2hlbiBhIHNlcnZl ciByZWNlaXZlcyBwYWNrZXRzIHRoYXQgaXQgYmVsaWV2ZXMgYXJlIHJlbGF0ZWQgdG8gYSBwcmV2 aW91c2x5IGNsb3NlZCBjb25uZWN0aW9uLiZuYnNwOyBGb3IgZXhhbXBsZSwgdGhpcyBjb21tb25s eSg/KSBoYXBwZW5zIHdoZW4gYSBzZXJ2ZXIgYm91bmNlcywgbG9zaW5nIGFsbCBzdGF0ZSwgYW5k IGlzIGluY2FwYWJsZQ0KIG9mIGNvbnRpbnVpbmcgdGhlIGVuY3J5cHRlZC9hdXRoZW50aWNhdGVk IGRpYWxvZyAoaS5lLiwgdGhlIHNlcnZlciBubyBsb25nZXIgaGFzIGFwcGxpY2FibGUga2V5IG1h dGVyaWFsLCBhbmQgbXVzdCBpbnN0ZWFkIGNvbnN0cnVjdCB0aGUgYXV0aGVudGljYXRlZCBQdWJs aWNSZXNldCBiYXNlZCBvbmx5IG9uIHRoZSBDb25uZWN0aW9uSUQgYW5kIHBlcmhhcHMgc29tZSBw ZXJzaXN0ZW50IHByaXZhdGUga2V5IG1hdGVyaWFsKS4gQSBQdWJsaWNSZXNldA0KIG1heSBzaW1p bGFybHkgYmUgZ2VuZXJhdGVkIGlmIGEgY29ubmVjdGlvbiBoYXMgYmVlbiBjbG9zZWQgZm9yIGEg d2hpbGUsIGFuZCBjbGllbnQgc2VuZHMgYSByZXF1ZXN0IHVzaW5nIGEgQ29ubmVjdGlvbklEIHRo YXQgaGFzIGJlZW4gZm9yZ290dGVuIGJ5IGEgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB0aGUgc2FtZSB0aW1lLCB0aGUgZGVz aWduIHJlcXVpcmVzIHRoYXQgaXQgaXMgaGFyZCAoaW1wb3NzaWJsZSkgZm9yIGEgdGhpcmQgcGFy dHkgYXR0YWNrZXIgKGRpc3J1cHRlcj8pIHRvIHNlbmQgYSB2YWxpZCBQdWJsaWNSZXNldC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdl bmVyYWwgZXhwZWN0YXRpb24gaXMgdGhhdCBhIGNsaWVudCAoaW52b2x2ZWQgaW4gYW4gYWN0dWFs IGNvbm5lY3Rpb24pIHdpbGwgcmVjZWl2ZSBhdCBsZWFzdCBlbm91Z2ggaW5mb3JtYXRpb24gdG8g YXV0aGVudGljYXRlIGEgUHVibGljUmVzZXQuJm5ic3A7IE1vc3QgY3JpdGljYWxseSwgd2hlbiBh IFB1YmxpY1Jlc2V0IGlzIHVzZWQsIGl0IGlzIHZlcnkgcHVibGljbHkgdmlzaWJsZSwgYW5kIGNh biBiZSByZXBsYXllZC4NCiAmbmJzcDsuLi5idXQgdGhhdCB3b3VsZCBvbmx5IGJlIGFuIGlzc3Vl IGlmIHRoZSBDb25uZWN0aW9uSUQgd2FzIHJldXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QVRUQUNLOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIGNsaWVudC1zZWxlY3RlZCBD b25uZWN0aW9uSUQsIGl0IHdhcyBwbGF1c2libGUgdGhhdCBhbiBhZHZlcnNhcnkgY291bGQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCk9ic2VydmUsIGFuZCBwb3Nz aWJseSBmb3Jlc3RhbGwgKGRlbGF5PykgdHJhbnNtaXNzaW9uIG9mIGEgQ2xpZW50SGVsbG8gY29u dGFpbmluZyBDb25uZWN0aW9uSUQgWCBzZW50IHRvd2FyZHMgc2l0ZSBZPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUmFjZSBv ZmYgdG8gc29tZSBzZXJ2ZXIgWScgYW5kIHF1aWNrbHkgb2J0YWluIGZyb20gWScgKGFuIGFmZmls aWF0ZWQgc2VydmVyPykgZWZmZWN0aXZlbHkgc29tZSBQdWJsaWNSZXNldCB2YWxpZGF0aW9uIGRh dGEgZm9yIENvbm5lY3Rpb25JRCBYLCBzdWZmaWNpZW50IHRvIGJlIGFibGUgdG8gZm9yZ2UgZnV0 dXJlIFB1YmxpY1Jlc2V0IHBhY2tldHMgd2l0aCBzYWlkIENvbm5lY3Rpb25JRC4gRm9yIGluc3Rh bmNlLCBpdCBtaWdodCByZWNlaXZlIGENCiBzYW1wbGUgUHVibGljUmVzZXQgZm9yIHRoYXQgQ29u bmVjdGlvbklEITxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCkFsbG93IHRoZSBvcmlnaW5hbCBwYWNrZXQgZnJvbSB0byBwcm9j ZWVkIHRvIHRoZSBvcmlnaW5hbCBzaXRlIFksIGNyZWF0aW5nIGEgY29ubmVjdGlvbiB1c2luZyBz YWlkIENvbm5lY3Rpb25JRCBYLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBtYWxpY2lvdXMgcmFjZXIgY2FuIHRoZW4gZGlzc2VtaW5hdGUgYSBQ dWJsaWNSZXNldCBwYWNrZXQgYXQgYW55IHBvaW50IGluIHRoZSBmdXR1cmUuJm5ic3A7IFRoaXMg KHBhcnRpYWxseSkgbmVnYXRlcyB0aGUgdmFsdWUgb2YgUHVibGljUmVzZXQgZmVhdHVyZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5ERUZFTlNFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJ5IGFsbG93aW5nIHRoZSBzZXJ2ZXIgdG8gc3BlY2lmeSBhIGNvbm5lY3Rpb25JRCwg d2UgcHJldmVudCBhIG1hbGljaW91cyByYWNlciBmcm9tIG9idGFpbmluZyBzdWNoIGluZm8gYWJv dXQgYW4gYXBwbGljYWJsZSBQdWJsaWNSZXNldC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIHdlIGFyZSBhbHJlYWR5IG1v dmluZyBpbiB0aGlzIGRpcmVjdGlvbiAoc2VydmVyIHNlbGVjdHMgQ29ubmVjdGlvbklEKSwgd2Ug c2hvdWxkIHByb2JhYmx5IGNvbnRpbnVlIHRvIGNvZGlmeSB0aGlzLCBiZWZvcmUgcHJvY2VlZGlu ZyBkZXBsb3kgb3IgdG8gY29kaWZ5IHRoZSBkZXRhaWxzIG9mIHRoZSBQdWJsaWNSZXNldC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e4f61453a3c04efaa35647adf63f9491usma1exdag1mb5msgcorpak_-- From nobody Fri Mar 31 05:20:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C079A129487 for ; Fri, 31 Mar 2017 05:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpfAPN60cgsd for ; Fri, 31 Mar 2017 05:20:50 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28E31293F2 for ; Fri, 31 Mar 2017 05:20:49 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i34so63553828qtc.0 for ; Fri, 31 Mar 2017 05:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nghbxLeLS82Rk9hrDSaUyndk26H56h5GFkZwuVogx54=; b=XfKU940gTZnS1mVlRD60pH3wATaho3bDDlnStoAJrcUr0fbBHtd+8011ZhhSXp+OBA TbFJbRVtN//NdolielXlb26V0j1sBfBQMBVqvQ9WMQtNZOqx/C6TXppqd81D0o/Eda9M aAhZZQNxcL+UndoREEz6JvMNJNIwYjY7BIreyXm4VZxo5dd670SpQmsk23EXOx2BISeE vBtsdfnaJLygzojYqdBoBNURhiCq+pnVAzegv2rqCW0LqlA5p71GnsoxLR1XTmLi2bNF QIP3HUrD1Ep1SxWr9Dh9PPz5EaruyUy++p8zLlwJVSYndxcJKEIrpI4XFCH+Uct/WmkC 2mYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nghbxLeLS82Rk9hrDSaUyndk26H56h5GFkZwuVogx54=; b=MEIjnRC6eLmidGlQrs/5Umkr7MpwB2iQdaPV5wzi17lcDMz1lcFDCCYsj7gc61ylR8 7Y7hZ/93Nhl8Mz6ThknYhKntvfT3OVOeK1UQVg6h735l6J84LO4K/SOpholzc9LZLvbc SCae9XOeEH1YslE48Y65gAg6GFs0mJXrbhmbTcOi6iOmibJWFxl+Na2qNiYLv7ONt6TR SnZu5FZMms6jFD60vD5sxyUKOzcGoqFgaCNlye495fltlEDukm9CPwseG3Rzh3G1KmcY xDJfH3r+0i4Pbm5W83yaMenuanjqpxe6ZkJ5TsvgYSGsZDaZDaSSSHTeDBSHxtpwvkeV 87cQ== X-Gm-Message-State: AFeK/H3p03z5GNTGIxHuFeZlJ+w+G3wO8sD4H5iPDhb/kCxiXNKTSs0f6MAtEbsiYrtv71CEfyo8TGkO3cCLOQ== X-Received: by 10.200.33.210 with SMTP id 18mr2423447qtz.159.1490962849006; Fri, 31 Mar 2017 05:20:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Fri, 31 Mar 2017 05:20:48 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 31 Mar 2017 07:20:48 -0500 Message-ID: Subject: Re: Public Reset; Connection ID; Attack; Defense To: "Lubashev, Igor" Cc: Jim Roskind , 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.22 Precedence: list List-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, 31 Mar 2017 12:20:52 -0000 Thanks for writing this up Jim. It's an interesting attack, and it certainly seems plausible. If you consider a distributed server that doesn't ensure that connections IDs are unique across a scope larger than the scope of its PublicReset keys, then this is a problem. An attacker could exploit that by making a connection to a server that shares keys but does not guarantee uniqueness of connection IDs. It uses a matching connection ID and induces a PublicReset. Assuming the authentication design ekr proposes, the only way to generate a spoofed PublicReset is to get one, but this could be trivially done by sending a packet with a short header on a new 5-tuple. Sending the same PublicReset would then be enough to kill the other connection. This doesn't really need a race if the attacker is willing to allow some packets through. All it needs is the 5-tuple and selected connection ID for the victim flow. So Igor, I think that your (a) and (c) are relatively easy to achieve in practice. Certainly a lot easier to achieve than I'd like. The most obvious fix is to use server-selected connection IDs (as we currently have) and to recommend the scope of uniqueness match (or exceed) the scope of the keys used for PublicReset. That could mean operational burden, so I'd be interested in hearing ideas about better fixes. On 31 March 2017 at 00:42, Lubashev, Igor wrote: > This attacker seems interested in denying X communicating with Y and > possesses the capability to (a) receive a copy of all X=E2=86=92Y traffic= ; (b) > inject packets toward X, spoofing Y, (c) out-race X=E2=86=92Y packets to = Y. That > attacker can simply use its (a) and (c) abilities to capture X=E2=80=99s > client-hello, modify it a little -- leaving client-id alone, and race it = to > Y. As a result, X=E2=80=99s actual packet will be ignored and the handsh= ake will > fail. > > > > I am not confident that server-selected connection id would help here. T= his > seems to be a hard problem to protect connection initiation from an attac= ker > capable of (a) and (c). > > > > - Igor > > > > > > From: Jim Roskind [mailto:JimRoskind@gmail.com] > Sent: Thursday, March 30, 2017 7:05 PM > To: IETF QUIC WG > Subject: Public Reset; Connection ID; Attack; Defense > > > > I was asked to write up a vaguely plausible attack on a PublicReset that = I > noticed a few years back. Awareness of this caused me to not push (while= I > was at Google) for the implementation and deployment of authenticated > PublicReset (we just deployed the forgeable flavor). I could see the > resolution required(?) server selected IDs, which was anticipated as bein= g > useful for a variety of additional reasons. Now that we're finally moving= in > that direction, it is worth mentioning the issue. > > > > PROBLEM > > > > A PublicReset needs to be created by a server when a server receives pack= ets > that it believes are related to a previously closed connection. For > example, this commonly(?) happens when a server bounces, losing all state= , > and is incapable of continuing the encrypted/authenticated dialog (i.e., = the > server no longer has applicable key material, and must instead construct = the > authenticated PublicReset based only on the ConnectionID and perhaps some > persistent private key material). A PublicReset may similarly be generate= d > if a connection has been closed for a while, and client sends a request > using a ConnectionID that has been forgotten by a server. > > > > At the same time, the design requires that it is hard (impossible) for a > third party attacker (disrupter?) to send a valid PublicReset. > > > > The general expectation is that a client (involved in an actual connectio= n) > will receive at least enough information to authenticate a PublicReset. > Most critically, when a PublicReset is used, it is very publicly visible, > and can be replayed. ...but that would only be an issue if the Connectio= nID > was reused. > > > > ATTACK: > > > > With client-selected ConnectionID, it was plausible that an adversary cou= ld: > > Observe, and possibly forestall (delay?) transmission of a ClientHello > containing ConnectionID X sent towards site Y > Race off to some server Y' and quickly obtain from Y' (an affiliated > server?) effectively some PublicReset validation data for ConnectionID X, > sufficient to be able to forge future PublicReset packets with said > ConnectionID. For instance, it might receive a sample PublicReset for tha= t > ConnectionID! > Allow the original packet from to proceed to the original site Y, creatin= g a > connection using said ConnectionID X. > > The malicious racer can then disseminate a PublicReset packet at any poin= t > in the future. This (partially) negates the value of PublicReset feature= . > > > > DEFENSE > > > > By allowing the server to specify a connectionID, we prevent a malicious > racer from obtaining such info about an applicable PublicReset. > > > > Since we are already moving in this direction (server selects ConnectionI= D), > we should probably continue to codify this, before proceeding deploy or t= o > codify the details of the PublicReset. > > From nobody Fri Mar 31 07:12:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1957E12989D for ; Fri, 31 Mar 2017 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 EzP6Oh9qS9ee for ; Fri, 31 Mar 2017 07:11:52 -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 6DDE312988D for ; Fri, 31 Mar 2017 07:11:52 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.20/8.16.0.20) with SMTP id v2VE1qLp003603; Fri, 31 Mar 2017 15:11:48 +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=4/p6U7cUNPAjQSYuYwQLpXEA9IIFa3T03r0r1NzUuYo=; b=IjL7gwgA/6ZRRDBpzp4nTYCl6VIOdQql2vgGcMAglaL4BaYYKwcAFqgbnEROE/WWYVbs YEBbdnkAMQTviDGlpSvo0ewLGRaXiwpl09CDuDuTFjOozxh04S+ZU8SSRHuf+pNAFNkn q57ob//dnrH5/VMEOYkZ2NE0pyCwPDM0u37ybN1YO7wlIEQNtBpFca2agm66nw46j7ku 5f27+ldhjG9TAry4s3sRaB4SU5D8Zb/njK3Tv1sp7aWksNwFugKCKCsx0HezgepZpTul hDWO/Dy0fkl0AC4ypCVjBtyCpItyYx2uc2XhvOUfszmpsWOa6mNPAF6ryAIhovCs5dFA dA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29h0g3qe8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Mar 2017 15:11:48 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v2VEBKVf018022; Fri, 31 Mar 2017 10:11:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 29fsutsnyy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 31 Mar 2017 10:11:48 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 31 Mar 2017 10:11:47 -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.1178.000; Fri, 31 Mar 2017 10:11:46 -0400 From: "Lubashev, Igor" To: Martin Thomson CC: Jim Roskind , IETF QUIC WG Subject: RE: Public Reset; Connection ID; Attack; Defense Thread-Topic: Public Reset; Connection ID; Attack; Defense Thread-Index: AQHSqbJr7QmCPcVnskWVIgJdAE8NYaGuaQgQgAC5FgD//9M4EA== Date: Fri, 31 Mar 2017 14:11:46 +0000 Message-ID: <5b227dd9a8fc481db18662c5cb474e85@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703310129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-31_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703310128 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Mar 2017 14:11:54 -0000 TWFydGluIFRob21zb24gd3JvdGU6DQo+IFRoZSBtb3N0IG9idmlvdXMgZml4IGlzIHRvIHVzZSBz ZXJ2ZXItc2VsZWN0ZWQgY29ubmVjdGlvbiBJRHMgKGFzIHdlIGN1cnJlbnRseSBoYXZlKSBhbmQN Cj4gdG8gcmVjb21tZW5kIHRoZSBzY29wZSBvZiB1bmlxdWVuZXNzIG1hdGNoIChvciBleGNlZWQp IHRoZSBzY29wZSBvZiB0aGUga2V5cyB1c2VkDQo+IGZvciBQdWJsaWNSZXNldC4NCg0KVGhpcyBt YXkgaGVscCBhZ2FpbnN0IFB1YmxpY1Jlc2V0IGtpbGxpbmcgdGhlIGNvbm5lY3Rpb24uICBCdXQg aG93IGRvIHlvdSBkZWZlbmQgYWdhaW5zdCBhIHNpbXBsZXIgYXR0YWNrIC0tIHJhY2luZyBjbGll bnQncyBvd24gY2xpZW50LWhlbGxvIGJ1dCBtb2RpZnlpbmcgc29tZXRoaW5nIChmb3IgZXhhbXBs ZSBwYWNrZXQgIyBvciB2ZXJzaW9uKSBhaGVhZCBvZiB0aGUgY2xpZW50J3MgYWN0dWFsIGNsaWVu dC1oZWxsbz8gIChUaGUgYXR0YWNrIG9uIGNsaWVudC1oZWxsbyBkb2VzIHJlcXVpcmUgYmVpbmcg YWJsZSB0byBvYnNlcnZlIGNsaWVudC1oZWxsbyBtZXNzYWdlcyBhbmQgbm90IGp1c3Qgc29tZSBt ZXNzYWdlcy4pIA0K From nobody Fri Mar 31 09:32:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DCB12922E for ; Fri, 31 Mar 2017 09:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AX1HKXVRh16d for ; Fri, 31 Mar 2017 09:32:10 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F63A129533 for ; Fri, 31 Mar 2017 09:32:02 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id d201so41556977qkc.0 for ; Fri, 31 Mar 2017 09:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/Q8o4/H7j8DDJ+U27afATS1vZuggZ8lHW34xg+ZGolg=; b=MmuPxDCWMxfstWOir0Og4rLfFB7VT1HpIt3F6z0EOVT39aDcS7XPp4pIMY/LVhWP4G XV0LHthAFJZz6DrC88dCMtqh5//O2uCZrLB+z/969RteR9mh9OyAwkh8eWAd/wp+sF2U 0Cg0LE8FTPZ6xNYKUlpRYxLY5sJuVeHjHOuAbLxZxhcJ9M5LSwWaUVpDv2woni3z9mjO D4ylrRz1gPrhlI8sFd7i2ayBIZ9u70dTuxBYA/aZwQx8YIIe8BQg9XLJcKvGSoPHusMz HZILQwEWJ4Mtcsv76TnKyv0hdEbE8AxeMHjSa/qXZdlt7BlNd+JRWi8ZYo5R3EdUJCVI RbPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/Q8o4/H7j8DDJ+U27afATS1vZuggZ8lHW34xg+ZGolg=; b=Mj78mJgUuESeEJ5qeWnYq14jAzQoDj+nzEzFAdGS3lBjGzFxGYKuQx19BZkge7vrMo EfKJDrkKL2uVTjykBca0kbxF94IsGhzSRcy6+RrP5s47Q+pC/P0sVcJU0RA67C+0Lb51 5efUXy32gc/IIIcrnA0EFLGEShCbFxIjGe0ykQoC6UCueWFX7qc6w6hzbC+t+KKApsbb 1SWm4L+9cgx2qXa/hDLvi2aFgSP3J6wxQr7MEQ81m+Is0pTSWe1jO0M6bTQb2mVCwYbw rkjrlkCg32o4icBDqN5IZqA531wUG0bHhWuzCFPRjsU9HMa2oLtHVnJKu/4L/ObbV23i oiIw== X-Gm-Message-State: AFeK/H1PPP8Ry635Mfb298271HHDV2jfVQQ7Bva044/ovTd9rJM6bjzTzdiRZvjGwu5bHXnxn+VGGnTV5hrpnA== X-Received: by 10.55.126.195 with SMTP id z186mr3748512qkc.144.1490977921545; Fri, 31 Mar 2017 09:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Fri, 31 Mar 2017 09:32:01 -0700 (PDT) In-Reply-To: <5b227dd9a8fc481db18662c5cb474e85@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5b227dd9a8fc481db18662c5cb474e85@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Fri, 31 Mar 2017 11:32:01 -0500 Message-ID: Subject: Re: Public Reset; Connection ID; Attack; Defense To: "Lubashev, Igor" Cc: Jim Roskind , 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.22 Precedence: list List-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, 31 Mar 2017 16:32:11 -0000 That is not something that can be defended against without the server being willing to tentatively establish multiple concurrent handshakes on the same 5-tuple. I suspect that this specific problem falls into a class of problems that we have to just concede: an attacker can interfere with the handshake before a common key is established. On 31 March 2017 at 09:11, Lubashev, Igor wrote: > Martin Thomson wrote: >> The most obvious fix is to use server-selected connection IDs (as we cur= rently have) and >> to recommend the scope of uniqueness match (or exceed) the scope of the = keys used >> for PublicReset. > > This may help against PublicReset killing the connection. But how do you= defend against a simpler attack -- racing client's own client-hello but mo= difying something (for example packet # or version) ahead of the client's a= ctual client-hello? (The attack on client-hello does require being able to= observe client-hello messages and not just some messages.) From nobody Fri Mar 31 10:29:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4288C1294BF for ; Fri, 31 Mar 2017 10:29:39 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dqfAcA4A_J9K for ; Fri, 31 Mar 2017 10:29:37 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA75C12952D for ; Fri, 31 Mar 2017 10:29:36 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o81so3983083wmb.1 for ; Fri, 31 Mar 2017 10:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pf+aD4D5x5X958ud3xQMTE4BjcEAU120J2vYpQ5JbHY=; b=C2+skewqGhf+KyptgNK1xIypyQrrOlF3Lw+QdXMg6qYH4WasbnccHUtNmV6jfipyd4 Eo1JEHd7KgiCbSDHTu4onBZCfBwiMzeWsMDPQCS31tUh/6C42mhaO1lUkVtow0PxunJi wcWtCUaRy6mGjPeuRYgp8gEurGTHq2oUV2Bxp7sa9ielnDhwKBn8U4Gi6koNr9ixYbeQ m192/0zw+7Z+3vG/2JlNsZF9XuelYYwm8f4xFNSMh/aAcDsQldpYQzBavx73fX5YPRjK UhDRhveQtP4o22Tynjk8Dh1hFz4tf+n86b9mcNMT3RJ6XeDeGblaYaZg6JUkGumAc7GU LyOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pf+aD4D5x5X958ud3xQMTE4BjcEAU120J2vYpQ5JbHY=; b=JGmR1bwkytunfDxDNqSZFWFWRhhE+rZcUqBb1J0hW8mCJBHALgjQd708200y7e+7Qa DyTrOFWrTSUIUTNwGr3J1G5PQL1wpM/y4SlrGhyBombnFWxMdaYjHBh0U/16x3VoJNia WmaWNpH8HIXWpMGCwCEgwH1A/84sDOqGs2qixQ2OkrYv4j+uLuqteGmWa4K9hliXOVHv uroRRMoebsddCCQaAdmSjZZ3AilIhCxuY5rLO7S1KsY+5dSFuevNhmSc0zXStCq6fpzv 5wRPFwC3uggbTs4/z6mekgcnnjJAZo9htM9SB9WeUITNBqn8B+w1q64zFoQ7xy2E40ET mnHQ== X-Gm-Message-State: AFeK/H0x9qVjSrY7PpSXtGKixI16w7RvwlXli7mD2vFAzrS2b7Kpr9Rtvd+kuqGvcdMLzwN4QayGywdOoF31friK X-Received: by 10.28.168.130 with SMTP id r124mr4359436wme.34.1490981375362; Fri, 31 Mar 2017 10:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.143.15 with HTTP; Fri, 31 Mar 2017 10:29:34 -0700 (PDT) In-Reply-To: References: <5b227dd9a8fc481db18662c5cb474e85@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Fri, 31 Mar 2017 10:29:34 -0700 Message-ID: Subject: Re: Public Reset; Connection ID; Attack; Defense To: Martin Thomson Cc: "Lubashev, Igor" , Jim Roskind , IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114cc7ae3f3efd054c0a27a8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Mar 2017 17:29:39 -0000 --001a114cc7ae3f3efd054c0a27a8 Content-Type: text/plain; charset=UTF-8 Indeed. I believe that to be somewhat inevitable. On Fri, Mar 31, 2017 at 9:32 AM, Martin Thomson wrote: > That is not something that can be defended against without the server > being willing to tentatively establish multiple concurrent handshakes > on the same 5-tuple. I suspect that this specific problem falls into > a class of problems that we have to just concede: an attacker can > interfere with the handshake before a common key is established. > > On 31 March 2017 at 09:11, Lubashev, Igor wrote: > > Martin Thomson wrote: > >> The most obvious fix is to use server-selected connection IDs (as we > currently have) and > >> to recommend the scope of uniqueness match (or exceed) the scope of the > keys used > >> for PublicReset. > > > > This may help against PublicReset killing the connection. But how do > you defend against a simpler attack -- racing client's own client-hello but > modifying something (for example packet # or version) ahead of the client's > actual client-hello? (The attack on client-hello does require being able > to observe client-hello messages and not just some messages.) > > --001a114cc7ae3f3efd054c0a27a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed. I believe that to be somewhat inevitable.

On Fri, Mar 31, 2017= at 9:32 AM, Martin Thomson <martin.thomson@gmail.= com> wrote:
That is not som= ething that can be defended against without the server
being willing to tentatively establish multiple concurrent handshakes
on the same 5-tuple.=C2=A0 I suspect that this specific problem falls into<= br> a class of problems that we have to just concede: an attacker can
interfere with the handshake before a common key is established.

On 31 March 2017 at 09:11, Lubashev, Igor <ilubashe@akamai.com> wrote:
> Martin Thomson wrote:
>> The most obvious fix is to use server-selected connection IDs (as = we currently have) and
>> to recommend the scope of uniqueness match (or exceed) the scope o= f the keys used
>> for PublicReset.
>
> This may help against PublicReset killing the connection.=C2=A0 But ho= w do you defend against a simpler attack -- racing client's own client-= hello but modifying something (for example packet # or version) ahead of th= e client's actual client-hello?=C2=A0 (The attack on client-hello does = require being able to observe client-hello messages and not just some messa= ges.)


--001a114cc7ae3f3efd054c0a27a8-- From nobody Fri Mar 31 12:07:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BAE129329 for ; Fri, 31 Mar 2017 12:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt6IPk8vcsaN for ; Fri, 31 Mar 2017 12:07:36 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 1B8A912947D for ; Fri, 31 Mar 2017 12:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490987255; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ikZwawaXOnMgM4mM6mraa/MqS4CvQS+A4k0/HfPzhD0=; b=j73z/mvdMvhfjVe7xxGsOZ+btWbkAuB9Bhkljs223nKwHa3Rzqxy5JtrhXBZ+3B0 UejYMgP1EFLmfS9AFMCvHpEjx8SDwxnSaPTVuNhV2kKiAWliTM9BI1r7bfZa7jvV skiY10+FagEQcOiwNBqWRKTpjtLoBAkloiJjZlrF5/jXQRQ5+INT6dgKHkzVLSkY Q78bgXftWGc1cpqCst4Uq0nC6azqj47QZyyTHnkcWKqIkXQMoZ55y2KOVrBjkfaM ziXVkYQ/WimBp8XrFecpKOLoqWe44hQUK81XwPX9ggqtfM/bXUdlJD/G5Mt0q05V Iwf/h5a/ng5eIs0ihdoDWA==; Received: from relay27.apple.com (relay27.apple.com [17.171.128.108]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id C1.A1.25383.5F8AED85; Fri, 31 Mar 2017 12:07:35 -0700 (PDT) X-AuditID: 11973e12-ac7ff70000006327-05-58dea8f5a09a Received: from ma1-mmpp-sz11.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay27.apple.com (Apple SCV relay) with SMTP id A1.A9.01638.5F8AED85; Fri, 31 Mar 2017 15:07:33 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.168.191.112] by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONP0094414JUL20@ma1-mmpp-sz11.apple.com>; Fri, 31 Mar 2017 12:07:33 -0700 (PDT) Sender: tpauly@apple.com Subject: Re: Abstract API From: Tommy Pauly In-reply-to: Date: Fri, 31 Mar 2017 14:07:31 -0500 Cc: Charles 'Buck' Krasic , Jana Iyengar , IETF QUIC WG Message-id: <09EBED6F-AF9C-439B-A24C-245113AA7182@apple.com> References: <6659599c-238f-98d2-ca3a-8d7cef96b1e3@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUiuLohR/f7insRBqs36Vlcu/6E3WJy42x2 i0lHF7JY9CzgdmDxWLCp1OPWjFMsHkuW/GQKYI7isklJzcksSy3St0vgyli17BtLwQy+irs3 UxsY13J3MXJySAiYSCxqe8bexcjFISRwgFHi4rRvbDCJKQ+OMEEkzjJKtP2dzgKS4BUQlPgx +R6QzcHBLCAvcfC8LEiYWUBL4vujVrASIYFvjBL/eupBSoQFJCQ270kECQsLSErsfbAbbDyb gIrE8W8bmEFsTgF7ifPHlzOC2CwCqhL3v7UwQozMlVh65CMbyBheARuJM19VIa5pZJL4eucW E0iNiIC2xJrZ95ggTpaV6F44jRmkSELgNZvErWsr2CcwCs9CcvUshKtnIbl6ASPzKkah3MTM HN3MPBO9xIKCnFS95PzcTYygcJ9uJ7SD8dQqq0OMAhyMSjy8J7zvRQixJpYVV+YeYpTmYFES 533ceTdCSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PNZqua86+3N955l3QsWD5aabOq5/Ou 2M+a22fYKjfoR9znetR58HQed92vfU8Sb8xcdPdCnoGddbvblcl9Z/pV+yw0wpdNqjWp7pj7 QpfTQ5epUED5+XT2h4WpM9PDb5vaSXbW2UrvvSavM83y3DSRGIEDZu/mzolMTfu/qUiwl1d8 yVRPIyWW4oxEQy3mouJEAM7Lh4pYAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUiuLqBVffrinsRBl8Xiltcu/6E3WJy42x2 i0lHF7JY9CzgdmDxWLCp1OPWjFMsHkuW/GQKYI4ytEnLLypPLEpRKEouKLFVKs5ITMkvj7c0 NjJ1SCwoyEnVS87PVdK3s0lJzcksSy3St0swzFi17BtLwQy+irs3UxsY13J3MXJySAiYSEx5 cISpi5GLQ0jgLKNE29/pLCAJXgFBiR+T7wHZHBzMAvISB8/LgoSZBbQkvj9qBSsREvjGKPGv px6kRFhAQmLznkSQsLCApMTeB7vZQGw2ARWJ4982MIPYnAL2EuePL2cEsVkEVCXuf2thhBiZ K7H0yEc2kDG8AjYSZ76qQlzTyCTx9c4tJpAaEQFtiTWz7zFBnCwr0b1wGvMERoFZSA6dhXDo LCSHLmBkXsUoWJSak1hpZK4HD5pNjJBwz9nBeOem2SFGAQ5GJR5eBb97EUKsiWXFlbmHGCU4 mJVEeDOWAIV4UxIrq1KL8uOLSnNSiw8x+gA9MJFZSjQ5HxiLeSXxhsYWxpYmFgYGFhZGpjiE lcR5/5QDzRJITyxJzU5NLUgtghnHxMEp1cBYNL3gfNbbmbHSO51P6qS+PyX278HZu/6BAQt9 N9YV/v5w6bSVwiqpQo85C625jgv4fL174+UL26PJtj/jSxra2O/+Pft9x//7tZz+Cg9fbb3k 8SlOZGt58ItwnwVbHv+/mNqc3Xyh+bDPz9D/cloMx7drr/TIvqS80jbi5Wpjvx13Kj4lzcv/ q8QCTESGWsxFxYkAcSjkKKQCAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Mar 2017 19:07:38 -0000 Note that working out how an abstract transport API needs to overlay on top of QUIC is part of the goals we have for TAPS and the Post-Sockets effort there. As part of that, we're planning on do an analysis of how applications need to interact with the security layer of its 'transport' as well as the basic transport features. Since QUIC is a prime example of way in which those elements are combined and integrated, supporting QUIC is a main goal. Efforts so far in working on abstract API and requirements: https://tools.ietf.org/html/draft-trammell-taps-post-sockets https://tools.ietf.org/html/draft-pauly-taps-guidelines Thanks, Tommy > On Mar 30, 2017, at 3:37 PM, Christian Huitema wrote: > > > > On 3/30/2017 11:45 AM, Charles 'Buck' Krasic wrote: >> +1 to a separate doc. Designing a new API is a very big deal IMHO. >> Ossification of transport related APIs has been comparable to the wire >> format etc. For instance, I'd hope that after 30+ years of posix >> sockets and Winsock, we'd make progress on things like: >> o clean zero-copy of data, at least between mappings and transport. >> o clean cooperation of mapping and transport wrt packetization and >> framing. >> o important for apps to have better visibility into latency >> (which messages go in which RTTs) >> o would pave the way for advanced features like application >> controlled FEC etc. >> > That's why I mentioned "Abstract" API. Stuff like zero copy tend to be > very much system dependent, and he exact syntax is bound to be language > dependent. But when you design an application API, you are concerned > with issues like "can a node wait for the next stream initialization", > which is in the domain of "abstract". > > -- Christian Huitema >

=C2=A0 The attack of interest is linkin= g one or more actions in one network with one or more on another network.= =C2=A0 If you're on the client side of the NAT nothing changes, and if = you're on the server side you already know the set of ports(or ports an= d IPs) that a given NAT uses publicly, so they're all equivalent from t= he observer's perspective.=C2=A0 The NAT is a physical entity and there= are some fairly tight real-world constraints on where you end up during a = rebind.

Is there a different threat model that I'm not aw= are of?

See above.<= /div>

-Ekr
=C2=A0

-Ekr
=C2=A0
<= div>

- jana


On Thu, Mar 9, 2017 at 8= :09 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves= that to the client.
> > Except that if the load balancer *needs* it, then the client has = to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, = the client supplied
> the connection ID, so the server side merely had to load balance based= on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-sugge= sted Connection ID proposal is that it's needed for efficient load bala= ncing". I'm taking that assertion at face value now, possibly beca= use I'm convinced of the utility of one of its side-effects: providing = some additional grade of assurance to a device on path that a given packet = was not injected off-path, which is useful in in-network DoS mitigation (as= in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing = tracking information could refuse to make Connection ID available, at the c= ost of degraded performance.

(I would like to reiterate that I do think that it's necessary t= o allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads= to connection failure, then "negotiation" is a euphemism: the se= rver informs the client whether it must send a connection ID, probably encr= ypted, and nobody needs any flags, unless the presence of connection ID cha= nges the offsets of fields we *do* want to explicitly expose, such as packe= t number echo (https://github.com/quicwg/base-d= rafts/issues/269) or troubleshooting flags (http= s://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus = that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing con= sensus on either of these. All I'm saying here is, should consensus eme= rge that the benefits outweigh the costs (both in complexity and in risk) f= or certain kinds of exposure to the path -- which I think may be the case f= or some of the things under discussion in 279, and I'm obviously convin= ced of the utility of packet number echo as in 269 or I wouldn't have s= ubmitted two PRs on it -- we need to be clear that other choices we make ab= out the layout of the header doesn't make that harder than it needs to = be. Sticking variable-length/optional fields whose presence is dependent on= endpoint-shared state after the exposed fields is probably sufficient for = this.


Cheers,

Brian