From nobody Fri Dec 1 22:21: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 F394A12025C for ; Fri, 1 Dec 2017 22:21:09 -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 ktZ-IiYr5x-o for ; Fri, 1 Dec 2017 22:21:08 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 E73A512704B for ; Fri, 1 Dec 2017 22:21:07 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id z18so12155242wrb.8 for ; Fri, 01 Dec 2017 22:21:07 -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=RIwBZvnOHNvkO3NYVc6VOnWedIgqh5ULiAQ1+5hwppI=; b=uUi89YojpI35wVpwWYLUsZxjX3wKaRfgfiTfTd/olk9nVbL5nSjllxJffWJwry2V9G PJyGxujy2P4pwkjY+10ixNiqdBdJGwahP3lTYThkkYtBkmAJHP9kijXIZPmHKwPYSOKd MfnoP7vEzKvTAERmSyq/iHkoQoydTne1rL8D8b2JgF+H3Io3S8PWKjEjHFZy9ejfcBLA m7RwqECsTIs5lhTpAiMd0rOtAi0ajSJVLm7oxV6sa6JzlZMu/RxL9V8ye6ESY/T/HOb8 YmY38QMX96ciFKw34uRXH2vlK3IWQ+F0IEvhZqxEKvhOFjVHFPbOii6Q4axrJYhieGPg A+BQ== 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=RIwBZvnOHNvkO3NYVc6VOnWedIgqh5ULiAQ1+5hwppI=; b=nkjp2DBdR3EQoiEKPVqh+jQK8dZUn24UNw5jxL0rHrA75jEt74e8TFtTLNUcWw7GQY hHqEqV9jwINwQRQzOlpSu29kGb36CJNCrior8Mlny6HuO9MvElOGGkzyagu615dxv0rL B1eU6Xk8iVUZShenwp0DoLz1HyM46+p6vSOHpVsLw+PEAI1Av2AsOqyN6e3QD5DbYFZI o85RdSeyyaCt7wSrZUiqOp0mVmsKhlXTw8/R5hsHFcBgW6/aUF3EkgkvJLrIziwUaICw uGd/6+wjcxqVnkdubHPf5TZ2DU3TS/UJ+AByun8hTr+P8M3kZMMAvY+g7K19StSv+4iz JACA== X-Gm-Message-State: AJaThX77DzUhMCoedqDtRImtz74grdiaFIulWTTb47+JKL2efdj6r5mQ 5v+ZDEfNz0G1lgEylVGemhuACt5kFQP36kh+ZGutpw== X-Google-Smtp-Source: AGs4zMaAfknljyJJf10P5/OhdxAyPJmJqZJC5yo0yu2Kp03lG25ruCnnoJC5WI4poj50K4pGjMij3IYXbGY78ZkEXfY= X-Received: by 10.223.158.203 with SMTP id b11mr7005390wrf.256.1512195666238; Fri, 01 Dec 2017 22:21:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.3 with HTTP; Fri, 1 Dec 2017 22:21:05 -0800 (PST) From: Martin Duke Date: Fri, 1 Dec 2017 22:21:05 -0800 Message-ID: Subject: -08 draft? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0820c4048461e4055f557d71" 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, 02 Dec 2017 06:21:10 -0000 --089e0820c4048461e4055f557d71 Content-Type: text/plain; charset="UTF-8" Editors, What are the prospects for an -08 draft soon? The December interop is two weeks away and the VarInts change is both worth trying out and potentially a bit tricky to get right. I am reluctant to declare ff000008 without a document with a longer life than the latest github edit. Martin --089e0820c4048461e4055f557d71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Editors,

What are the prospects for an = -08 draft soon? The December interop is two weeks away and the VarInts chan= ge is both worth trying out and potentially a bit tricky to get right.

I am reluctant to declare ff000008 without a document = with a longer life than the latest github edit.

Ma= rtin
--089e0820c4048461e4055f557d71-- From nobody Sat Dec 2 00:28: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 A9AD112785F for ; Sat, 2 Dec 2017 00:28:10 -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 (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 Kz6QnZ36U-cf for ; Sat, 2 Dec 2017 00:28:08 -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 A32B8127077 for ; Sat, 2 Dec 2017 00:28:08 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id g191so4960290ywe.7 for ; Sat, 02 Dec 2017 00:28:08 -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=ubiB2Lmr92S0p7syVijw4LUy61qdtovsf7KU97pcPeI=; b=U3fgkR1Fc+RJHCWlF2hxwn9jGsEPbZGv/W21v/DFWEOlI/2+81D/F+FrACuQN5+ADE kvHMorq5nkaW6FsKIm9ZN49CMf/KxsWBKW6XA+06ciRIPFrbCZKBnmLqyTDXN8QwLfAG krcQOSfaOfwqtSnpKBXU7qJxBiBydfr5+LMD3LFSq8aBd7qWpYg7HZ5Ax59U86CSbAiJ +fsDjgzkZzTXUriMxVJkrfK0LL8hYNQMSVnzvkf8ftdZzzNnfYl4dSJJZ/zwoR1Ny9mD 6nImdz+sA4/GRiLG7+4ReGkEbaYbPVdYfoMJW3+WNV9vKNRzZUh+gQ8gfqwRulJj4vrf k+Qw== 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=ubiB2Lmr92S0p7syVijw4LUy61qdtovsf7KU97pcPeI=; b=XErRV36/zDiaJg+CpAIn1tumLvL87hnL7Ok4hCwveqODQVj+zLy8T17V7m9yj4FygS Jrt1cAMF3SwqZIAIO3mI7BPBhIpvh+7l2NFVvfPwjmY7h/CXvK2hWkrlL+0YzLPmzwCU zCo2D55MBBzUA/gkwK+/jT74oZ4a8zL+1JpIVpt8gofY2DLVrdqBNg7pm2N8w/0/R9vK D5qM5S5LeTuf0m8oiqnXhJINS1ez3irbvcZKrbRkNjRfSopS8QIcsXj1MaeRIfuCkFm2 1QULgei9fhBOxjxWHJddgz5h0qQPDkDXfGTDRn89bWkuU0MHW5qcUfm4m91oSnn/xL9V P1Mg== X-Gm-Message-State: AJaThX42Ks9eixsB+InsXHTff/tbEMT1KAbUYnB5Wn972jY5JUOASbpG 2QffSQXvzJUG3HrDhpmFm2ApgSwmS4UVcnabYG5SXQ== X-Google-Smtp-Source: AGs4zMZ+uBAJmhsU5UQa6S1kPPS3juasoKMSowRI0VhAqNtdRfo7V9qf0X19QwscL2cP/3wcAbbZkQzmJRMlp9KiWLU= X-Received: by 10.129.56.137 with SMTP id f131mr5837401ywa.139.1512203287290; Sat, 02 Dec 2017 00:28:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.134 with HTTP; Sat, 2 Dec 2017 00:28:06 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Sat, 2 Dec 2017 00:28:06 -0800 Message-ID: Subject: Re: -08 draft? To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114d792ac518f5055f574364" 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, 02 Dec 2017 08:28:11 -0000 --001a114d792ac518f5055f574364 Content-Type: text/plain; charset="UTF-8" Given the varint change is significant, it makes sense to cut a -08 draft before the next interop. I can't seem to remember if we discussed -08 for the December interop, but I'd rather have folks moving on to the new varint format anyways than stay behind. Others? On Fri, Dec 1, 2017 at 10:21 PM, Martin Duke wrote: > Editors, > > What are the prospects for an -08 draft soon? The December interop is two > weeks away and the VarInts change is both worth trying out and potentially > a bit tricky to get right. > > I am reluctant to declare ff000008 without a document with a longer life > than the latest github edit. > > Martin > --001a114d792ac518f5055f574364 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given the varint change is significant, it makes sense to = cut a -08 draft before the next interop. I can't seem to remember if we= discussed -08 for the December interop, but I'd rather have folks movi= ng on to the new varint format anyways than stay behind. Others?

On Fri, Dec 1, 2017 at= 10:21 PM, Martin Duke <martin.h.duke@gmail.com> wrote= :
Editors,

What are the prospects for an -08 draft soon? The December interop is= two weeks away and the VarInts change is both worth trying out and potenti= ally a bit tricky to get right.

I am reluctant to = declare ff000008 without a document with a longer life than the latest gith= ub edit.

Martin

--001a114d792ac518f5055f574364-- From nobody Sat Dec 2 01:11: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 8DBED1276AF for ; Sat, 2 Dec 2017 01:11:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 FPsQZhTTKouL for ; Sat, 2 Dec 2017 01:11:44 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4ED120721 for ; Sat, 2 Dec 2017 01:11:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,348,1508828400"; d="scan'208,217";a="231105289" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx143-out.netapp.com with ESMTP; 02 Dec 2017 01:11:43 -0800 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 2 Dec 2017 01:11:43 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 2 Dec 2017 01:11:42 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Sat, 2 Dec 2017 01:11:43 -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=Exfdx6ZWn+772LMEGSr4pArr4A9QdYM9Zwx4MTSW4EY=; b=RT09uknf14FH3gp0AB17N+7rPAL6GQhbEOmz5BabUEWfnDRcU/5L3NnZIklSppok2qG3AOHLSv4cnchNkOJO5N1714e0Q3x0soNPNvSgmSrdf8GUALrdgW8tfAP7PBfeWqrDvQdteqSpNf7HRrvJIQ47xPXG7dXeXWnlMkRySAI= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Sat, 2 Dec 2017 09:11:40 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0282.007; Sat, 2 Dec 2017 09:11:40 +0000 From: "Eggert, Lars" To: Jana Iyengar CC: Martin Duke , IETF QUIC WG Subject: Re: -08 draft? Thread-Topic: -08 draft? Thread-Index: AQHTazXFaduYCZRWckKobNnEDwRUMKMvuIgAgAAMLPE= Date: Sat, 2 Dec 2017 09:11:40 +0000 Message-ID: <78CEA230-B5A6-4DBB-8C71-3BC90208D4CB@netapp.com> 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=lars@netapp.com; x-originating-ip: [2001:a61:3614:8001:7494:c893:fcab:d04c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:A16iwOTfkmAmXNjCxKrYw48Yky/I4WSreZf9n5CoqAU+LvlQUeoLaUbng39PfIsHBIw7Lcjz+o9xuwj/GiQohavz63qUE1v7FdfboS0wdeofR8qW3teaooRJRseMtg7Vrxeh2/7OMGrg7YOGY8PJFqklX5aCx49w3Tfkh6zHbDQ2/TLZwVgpECK2ADww437at6Rvx61fXOecU2FTDo1Hu8fGOfsB/NUX8d2E9hoLoyoH1GpIMed3LwhjnuYUTAuoqq4+GWWrPkjeDFtgKLjNbEKfHOJW4a11RV4/1AUZFS5rtrTFakZPdeWmlPgLeUhJsvIVuMfTpnGzKNyi1xJt9Fz4zUsu1MAPimplYyMboxs=; 5:qoHAEKDEUl6jqL1nT2q5+HqA1DajGv7z5xtv43okXBPxlxzxjBHRYraxWONjzLZ14wpE1hRZ0leLyhgctt/6jUysnkk2m5yddT/7WCbUz44wAz+eJ4AMBneyMKiJhL9QXqDwb5MC0u7a+zMlTZ0mtQ3oCWZUlrWiipyxTmLWlBI=; 24:L3JpdtkSVImISjnerrhJtwgNA6YDp7J9RSc5A1UyHKh1q5UPiZeYTmwTNwxw5P6dQl9gpP2tKyJmWBNxcxmj+DXl8qZZyNCxLklAWEc96mg=; 7:LbFRW5Je4Cl3b+uUxHwmfVQ0n7Jp/j6FLQGX5KQSagOlLpEm9MhrpwO7r3zbMRYdpDpxtGSI0NxYn8RS+M9KFETgcoQF8Zb4/OgICFiyjJ/4MiON1iRAuAc/C7Y0SaTApq27feWlVTrDjbzuhWQxENjB0oNtFCcIC06FlpD2au7eteA55HLH1Yb7VWAWxzZXoZjZ3ybYgv5btp46d9JSMfOGc/vSpqSBenHktHZSSc/ZrtgzFlKRUlTdtruq5VH3 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 87bebc5f-e2ec-4a0c-a258-08d53964b2e5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231022)(920507027)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1763; x-forefront-prvs: 0509245D29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(199003)(24454002)(189002)(3280700002)(54896002)(6512007)(5660300001)(2950100002)(3660700001)(6916009)(53546010)(2900100001)(33656002)(101416001)(189998001)(316002)(7116003)(54906003)(81166006)(81156014)(2906002)(8676002)(25786009)(97736004)(86362001)(68736007)(34040400001)(4326008)(39060400002)(83716003)(14454004)(99286004)(53936002)(6246003)(229853002)(82746002)(106356001)(7736002)(236005)(105586002)(478600001)(77096006)(76176011)(6486002)(8936002)(6116002)(6436002)(102836003)(36756003)(54356011)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_78CEA230B5A64DBB8C713BC90208D4CBnetappcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 87bebc5f-e2ec-4a0c-a258-08d53964b2e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2017 09:11:40.1199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.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: Sat, 02 Dec 2017 09:11:45 -0000 --_000_78CEA230B5A64DBB8C713BC90208D4CBnetappcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIHBsZWFzZS4gQWxzbywgdGhlIGVkaXRvcuKAmXMgY29weSBoYXMgcGlja2VkIHVwIHF1aXRl IGEgZmV3IG90aGVyIGNoYW5nZXMgdG9vLCBzbyB0aGVyZeKAmXMgbW9yZSB0aGFuIGp1c3QgdmFy aW50LiBJIGFsc28gdGhpbmsgd2Ugc2hvdWxkIGRvIFRMUzEuMy1kcmFmdDIyLCBpdCBhdCBhbGwg cG9zc2libGUuDQoNCldoZW5ldmVyIHlvdSB0aGluayB5b3UgaGF2ZSBzb21ldGhpbmcgY29uc2lz dGVudCwgbGV04oCZcyBwdXNoIGFuIDA4IGZvciBEZWMgMTguIChXZSBjYW4gYWx3YXlzIGRvIDA5 IGZvciBKYW4gaW4gTUVMKS4NCg0KTGFycyAoYWxsIGhhdHMgb2ZmKQ0KDQotLQ0KU2VudCBmcm9t IGEgbW9iaWxlIGRldmljZTsgcGxlYXNlIGV4Y3VzZSB0eXBvcy4NCis0OSAxNTEgMTIwIDU1Nzkx DQoNCk9uIERlYyAyLCAyMDE3LCBhdCAwOToyOCwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNv bTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KR2l2ZW4gdGhlIHZhcmludCBjaGFu Z2UgaXMgc2lnbmlmaWNhbnQsIGl0IG1ha2VzIHNlbnNlIHRvIGN1dCBhIC0wOCBkcmFmdCBiZWZv cmUgdGhlIG5leHQgaW50ZXJvcC4gSSBjYW4ndCBzZWVtIHRvIHJlbWVtYmVyIGlmIHdlIGRpc2N1 c3NlZCAtMDggZm9yIHRoZSBEZWNlbWJlciBpbnRlcm9wLCBidXQgSSdkIHJhdGhlciBoYXZlIGZv bGtzIG1vdmluZyBvbiB0byB0aGUgbmV3IHZhcmludCBmb3JtYXQgYW55d2F5cyB0aGFuIHN0YXkg YmVoaW5kLiBPdGhlcnM/DQoNCk9uIEZyaSwgRGVjIDEsIDIwMTcgYXQgMTA6MjEgUE0sIE1hcnRp biBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFp bC5jb20+PiB3cm90ZToNCkVkaXRvcnMsDQoNCldoYXQgYXJlIHRoZSBwcm9zcGVjdHMgZm9yIGFu IC0wOCBkcmFmdCBzb29uPyBUaGUgRGVjZW1iZXIgaW50ZXJvcCBpcyB0d28gd2Vla3MgYXdheSBh bmQgdGhlIFZhckludHMgY2hhbmdlIGlzIGJvdGggd29ydGggdHJ5aW5nIG91dCBhbmQgcG90ZW50 aWFsbHkgYSBiaXQgdHJpY2t5IHRvIGdldCByaWdodC4NCg0KSSBhbSByZWx1Y3RhbnQgdG8gZGVj bGFyZSBmZjAwMDAwOCB3aXRob3V0IGEgZG9jdW1lbnQgd2l0aCBhIGxvbmdlciBsaWZlIHRoYW4g dGhlIGxhdGVzdCBnaXRodWIgZWRpdC4NCg0KTWFydGluDQoNCg== --_000_78CEA230B5A64DBB8C713BC90208D4CBnetappcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpZ ZXMgcGxlYXNlLiBBbHNvLCB0aGUgZWRpdG9y4oCZcyBjb3B5IGhhcyBwaWNrZWQgdXAgcXVpdGUg YSBmZXcgb3RoZXIgY2hhbmdlcyB0b28sIHNvIHRoZXJl4oCZcyBtb3JlIHRoYW4ganVzdCB2YXJp bnQuIEkgYWxzbyB0aGluayB3ZSBzaG91bGQgZG8gVExTMS4zLWRyYWZ0MjIsIGl0IGF0IGFsbCBw b3NzaWJsZS4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoZW5ldmVyIHlvdSB0aGluayB5b3Ug aGF2ZSBzb21ldGhpbmcgY29uc2lzdGVudCwgbGV04oCZcyBwdXNoIGFuIDA4IGZvciBEZWMgMTgu IChXZSBjYW4gYWx3YXlzIGRvIDA5IGZvciBKYW4gaW4gTUVMKS4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkxhcnMgKGFsbCBoYXRzIG9mZik8YnI+DQo8YnI+DQo8ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPi0tJm5ic3A7DQo8ZGl2PlNlbnQgZnJvbSBhIG1vYmlsZSBkZXZpY2U7IHBsZWFz ZSBleGN1c2UgdHlwb3MuPC9kaXY+DQo8ZGl2PiYjNDM7NDkgMTUxIDEyMCA1NTc5MTwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pjxicj4NCk9uIERlYyAyLCAyMDE3LCBhdCAwOToyOCwgSmFuYSBJeWVuZ2Fy ICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBnb29nbGUuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxk aXY+DQo8ZGl2IGRpcj0ibHRyIj5HaXZlbiB0aGUgdmFyaW50IGNoYW5nZSBpcyBzaWduaWZpY2Fu dCwgaXQgbWFrZXMgc2Vuc2UgdG8gY3V0IGEgLTA4IGRyYWZ0IGJlZm9yZSB0aGUgbmV4dCBpbnRl cm9wLiBJIGNhbid0IHNlZW0gdG8gcmVtZW1iZXIgaWYgd2UgZGlzY3Vzc2VkIC0wOCBmb3IgdGhl IERlY2VtYmVyIGludGVyb3AsIGJ1dCBJJ2QgcmF0aGVyIGhhdmUgZm9sa3MgbW92aW5nIG9uIHRv IHRoZSBuZXcgdmFyaW50IGZvcm1hdCBhbnl3YXlzIHRoYW4NCiBzdGF5IGJlaGluZC4gT3RoZXJz PzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj5PbiBGcmksIERlYyAxLCAyMDE3IGF0IDEwOjIxIFBNLCBNYXJ0aW4gRHVrZSA8c3Bh biBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IGRpcj0ibHRyIj5FZGl0b3JzLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hhdCBh cmUgdGhlIHByb3NwZWN0cyBmb3IgYW4gLTA4IGRyYWZ0IHNvb24/IFRoZSBEZWNlbWJlciBpbnRl cm9wIGlzIHR3byB3ZWVrcyBhd2F5IGFuZCB0aGUgVmFySW50cyBjaGFuZ2UgaXMgYm90aCB3b3J0 aCB0cnlpbmcgb3V0IGFuZCBwb3RlbnRpYWxseSBhIGJpdCB0cmlja3kgdG8gZ2V0IHJpZ2h0Ljwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBhbSByZWx1Y3RhbnQgdG8gZGVjbGFyZSBm ZjAwMDAwOCB3aXRob3V0IGEgZG9jdW1lbnQgd2l0aCBhIGxvbmdlciBsaWZlIHRoYW4gdGhlIGxh dGVzdCBnaXRodWIgZWRpdC48L2Rpdj4NCjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9y PSIjODg4ODg4Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk1hcnRpbjwvZGl2Pg0KPC9mb250 Pjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_78CEA230B5A64DBB8C713BC90208D4CBnetappcom_-- From nobody Sat Dec 2 11:30: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 49DA2128B51 for ; Sat, 2 Dec 2017 11:30:55 -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 lt7tJFf9rdRb for ; Sat, 2 Dec 2017 11:30:52 -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 887011271DF for ; Sat, 2 Dec 2017 11:30:51 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id l7so5299750ywa.13 for ; Sat, 02 Dec 2017 11:30: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=bUx/V/2G1OpvU9ruMXVkm+NnhS6z+SEyKBJdrn061p0=; b=eNowFyYFaX89njkCsnuB4F8YRTqvVeDX00J45oo04856an8qVjU28QdN7OionupwdX mccxbyCfJXamFf4pbYUVQRiIK9dHtmw1qvp7mH3a6XMyHTDY1tnVPmByCnqA7FCYlB5l fYxxMVgrvaXZjKaMOTICoDwnouHjuo7ZE6GhP+lYPMvSaGomi6a5WUvDYBx2pKxtu5E5 YVLqxIS9sgtDdg/hJX4lV0lYBblFnWkF/HqgSGP3x+wl3CKHHNkE8/hQQTWGzwnBzEsD +FE6BP+kZRg5hqWBZ+iQR4d8lGmm1euENh35/ha9I5oEIr76Bxu6/JHevsAn5bcJ+MbN Vvig== 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=bUx/V/2G1OpvU9ruMXVkm+NnhS6z+SEyKBJdrn061p0=; b=AgfsjIeTcCG5oxbh+kWAbHsyWfKAr+F1KjCAfmxkhXF8FjpfqV8zidPZT4qCmsM9IS Szl+8Mi1O6zK6m8+1mNTBVLZnmMukxnwzgPds/UxsNHmZrkLEWwCQetKOhjWAD7wrJck UXX8kHtQt5UaeFas5Ak5GOR5oZMhBYmAJiQ7cV/mTrSv06Mu+rPTXnZ8tP8bCcJQqlBT B42NUtG+bIPAGrIdDRmrWRXO4J4mGqwAKvyDTvx1e3t31MbGICiwth4qI7FU3pIivPI+ 0u81YWTlT9FgVt/Z7uTIoHUCNipznbSFxkN1ZTkIOICZcrv9aJYuIIoQKc/iQ1u/eQ0m NBDA== X-Gm-Message-State: AJaThX7lavzWDlYWUq9UR1z7hvPh/rxJhJEKjT19yXi2TZ8/7RBJ9b1v 2Oa+Ix5cJcuYTQbWYQUxhTIPlP/EwiS0qAlh+m1pZw== X-Google-Smtp-Source: AGs4zMYkRi3ojrocWkYPvDRG+w9ZwPp+Ge3xyAzIbkQpAzdD7ycuExlx93718DecrTzSGrqLA94UNffo8aJdPg9dJnM= X-Received: by 10.129.77.195 with SMTP id a186mr6703016ywb.363.1512243050725; Sat, 02 Dec 2017 11:30:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Sat, 2 Dec 2017 11:30:10 -0800 (PST) In-Reply-To: <78CEA230-B5A6-4DBB-8C71-3BC90208D4CB@netapp.com> References: <78CEA230-B5A6-4DBB-8C71-3BC90208D4CB@netapp.com> From: Eric Rescorla Date: Sat, 2 Dec 2017 11:30:10 -0800 Message-ID: Subject: Re: -08 draft? To: "Eggert, Lars" Cc: Jana Iyengar , IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="001a1140c8e6da5ca0055f6085a6" 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, 02 Dec 2017 19:30:55 -0000 --001a1140c8e6da5ca0055f6085a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 2, 2017 at 1:11 AM, Eggert, Lars wrote: > Yes please. Also, the editor=E2=80=99s copy has picked up quite a few oth= er > changes too, so there=E2=80=99s more than just varint. I also think we sh= ould do > TLS1.3-draft22, it at all possible. > I agree -22 has been published and I believe pretty much all the major stacks have -22 now either landed or in a branch [0]. -Ekr [0] PS, this is a declaration against interest because Mint doesn't have -22 yet, but I believe I can add it reasonably expeditiously. > > Whenever you think you have something consistent, let=E2=80=99s push an 0= 8 for Dec > 18. (We can always do 09 for Jan in MEL). > > Lars (all hats off) > > -- > Sent from a mobile device; please excuse typos. > +49 151 120 55791 <+49%201511%202055791> > > On Dec 2, 2017, at 09:28, Jana Iyengar wrote: > > Given the varint change is significant, it makes sense to cut a -08 draft > before the next interop. I can't seem to remember if we discussed -08 for > the December interop, but I'd rather have folks moving on to the new vari= nt > format anyways than stay behind. Others? > > On Fri, Dec 1, 2017 at 10:21 PM, Martin Duke > wrote: > >> Editors, >> >> What are the prospects for an -08 draft soon? The December interop is tw= o >> weeks away and the VarInts change is both worth trying out and potential= ly >> a bit tricky to get right. >> >> I am reluctant to declare ff000008 without a document with a longer life >> than the latest github edit. >> >> Martin >> > > --001a1140c8e6da5ca0055f6085a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Dec 2, 2017 at 1:11 AM, Eggert, Lars <lars@netapp.com> wro= te:
Yes please. Also, the editor=E2=80=99s copy has picked up quite a few other= changes too, so there=E2=80=99s more than just varint. I also think we sho= uld do TLS1.3-draft22, it at all possible.

I agree -22 has been published and I believe pretty much all the majo= r stacks have -22 now either landed or in a branch [0].

-Ekr

[0] PS, this is a declaration against i= nterest because Mint doesn't have -22 yet, but I believe I can add it r= easonably expeditiously.
=C2=A0

Whenever you think you have something consistent, let=E2=80=99s push a= n 08 for Dec 18. (We can always do 09 for Jan in MEL).

Lars (all hats off)

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

On Dec 2, 2017, at 09:28, Jana Iyengar <jri@google.com> wrote:

Given the varint change is significant, it makes sense to = cut a -08 draft before the next interop. I can't seem to remember if we= discussed -08 for the December interop, but I'd rather have folks movi= ng on to the new varint format anyways than stay behind. Others?

On Fri, Dec 1, 2017 at 10:21 PM, Martin Duke <martin.h.d= uke@gmail.com> wrote:
Editors,

What are the prospects for an -08 draft soon? The December interop is = two weeks away and the VarInts change is both worth trying out and potentia= lly a bit tricky to get right.

I am reluctant to declare ff000008 without a document with a longer li= fe than the latest github edit.

Martin


--001a1140c8e6da5ca0055f6085a6-- From nobody Sat Dec 2 13:08: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 237251286CA for ; Sat, 2 Dec 2017 13:08:33 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU1cNDuyD_sr for ; Sat, 2 Dec 2017 13:08:32 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1943127444 for ; Sat, 2 Dec 2017 13:08:31 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id g1so14770471ioc.8 for ; Sat, 02 Dec 2017 13:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=Ar0pyGXpeuFU06UUgZ19SKR9QHj6h2x6JeYefGaayRY=; b=i8O6t7DwfBaNyITA7wWHdxuIO8g2nECPnnCjYmsIRbSVv30rrfXDjGUjYFB9BEHXSh h6Pa8u0EyJlqPCTjtI51c1Illt0ZJG875k2wNS1DP/AJq4WkK7U4F/u5qZ1hoAlelRro xOXMD1jgnyt/g2wbUqCr1i3H51QWyfs7nORWhhe3igL2WZkLKKYlIN2zVgcl9oPknfAC SCBndc6ArVg5d0/EZGqEimaVGdT17nKTWwPqVySkssJOCZ1NrI/yj4ANiWPLQdEAwgjm 1giOTLAHVgTS+mGyjhzSea6pQKf4ggXSREfowtSdQ6fWQ+pfln2x2npy4UmUDkBw0hJ/ 0D7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=Ar0pyGXpeuFU06UUgZ19SKR9QHj6h2x6JeYefGaayRY=; b=AGVV1VKxZ3+npOlq+TtVb0sGVhlnZQgrDoBD5vevs+izgce+Dij73sflWfhQ6vgBS9 NJNOmcHtzfTkaNVHYj8PrX7TQEdWOaR8dA2QSp93T+Km/olXl+qgCR7Z5wuQloJkBPIS YN3yB5aHz52cVXV9J5Gr5PkhutBIgEdYhZ2XtbyMeyUz4B6KCkjxBBw/uN2AdLLEIquS jL+t7ttgki/OKf9VcxH0+Z0wo4zLcyTh3TQjKVd09dBnhLT4p6iJWALOr5X1s7WGGrdz tlVcWpBrdzpoAYTDO/8C15csSkJf0t3SJCAJJZm1ELd8nHl+DTlZ/FZm6YdMUcbXqlCZ yF4g== X-Gm-Message-State: AJaThX7wNwXc2fAzgwMxkIndTxxA/AyFcRclrP/yIIKrfCPicBfRjdSE 6iz8mUzcn9sZGmODkUCacUv/61OEOaRH5tnRAVt+IA== X-Google-Smtp-Source: AGs4zMaqq9nOv7z22ZIH54NGqYbJEosGSqggo0/M4eZKYA8WiKopOOXkz4YsKEinOL0JD57CnRrWXC1RnT+ZrsvCFCQ= X-Received: by 10.107.47.234 with SMTP id v103mr17030836iov.96.1512248910847; Sat, 02 Dec 2017 13:08:30 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 2 Dec 2017 16:08:29 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 2 Dec 2017 16:08:29 -0500 Message-ID: Subject: Legacy HTTP gateways To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1135a43824a6c1055f61e356" 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, 02 Dec 2017 21:08:33 -0000 --001a1135a43824a6c1055f61e356 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Say you only want to only implement a site based on the QUIC/HTTP protocol but you still want to support legacy HTTP and possibly HTTP/2 through a gateway. Or alternatively you might even want to always use legacy protocols via a frontend load balancer and only use QUIC to bridge the gap from an external load balancer into a secure network. Does the current QUIC/HTTP design process take this into account? For example a gateway might accept HTTP 1.0 and 1.1 and forward to QUIC/HTTP but may not support all features such as PUSH. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a1135a43824a6c1055f61e356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Say you only want to= only implement a site based on the QUIC/HTTP protocol but you still want t= o support legacy HTTP and possibly HTTP/2 through a gateway. Or alternative= ly you might even want to always use legacy protocols via a frontend load b= alancer and only use QUIC to bridge the gap from an external load balancer = into a secure network.


For example a gateway might = accept HTTP 1.0 and 1.1 and forward to QUIC/HTTP but may not support all fe= atures such as PUSH.


Kind R= egards,
Mikk= el Fahn=C3=B8e J=C3=B8rgensen

--001a1135a43824a6c1055f61e356-- From nobody Sun Dec 3 15:39: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 80299124BE8 for ; Sun, 3 Dec 2017 15:39: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 ISTXlHAiqUpd for ; Sun, 3 Dec 2017 15:39:26 -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 CE786120724 for ; Sun, 3 Dec 2017 15:39:26 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id j17so10587409oih.3 for ; Sun, 03 Dec 2017 15:39:26 -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=y9fAX0uDYuF7o/Ff0I4b2ONLO2bPokP3IOTKBmvJA3c=; b=l6YjPMLFccgqFVxTO2/mitkHDbhEobvmgL1+w+iVrKAId2EUFwWhf4ejWm3wu0Dqyh /tKiiz1srS0TMeN17BRt1PX/lCCLN/SvkejdZti5Jy9Gf1XreAKL0nQcALD1cZWlp0ik tmFYieCw4QNfg/6kt2Sk6YJgMylEEjSLrMYiR+kNURmxpZEwUIwC7SdsBzi0YRfo4+tu c5MPxmjrdLHzCUOY68tIkbCo03og0Ageahhl2wACWGR7mXkxVSBx+GFjoa8/zWQt0yQl 8py59O3Rh65vwgKdOADrOP9OJ+02hbG/tSBtk79RS64CvfZ6jM+0o0tLxyqmEg+oHsUO 6A7A== 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=y9fAX0uDYuF7o/Ff0I4b2ONLO2bPokP3IOTKBmvJA3c=; b=FcDuA5aD3h09I31MqawWpCVojJK5ytWkYh+9JQfaWplteVDmWWCcopRaNWQdLAR0w3 Sy0PBRUMhq8CgVyqvWVc8QAU84bqnJF0Nut9hiig4z5bKZWoCeUJjAR+MTOFQsli4MKi rkiN856KA6heV0C82OZhoW9zNiOGcXFVFx1j4MGLXL0QjzDfXsoKsbDQ2G3UrfYhaiOx JB7O3pdRy2uNfw0JHVhIUxeuptISrHvsOkOhdpFES4dzFz6sgi3b3a5aJg6xI4XBjpMJ /9b9AFNuwzy4lHUj6pfZqH5nYb/8TuQwMSzix5RDrxJBHGE2VGgdzXT9P1tW2aLfIAvH WHoA== X-Gm-Message-State: AJaThX5SWbZL8ticQKxDBXcXCyPg6+C+u+nZ60CPpDhhnM8hagCxiWxE jWdEbFFGiZiKwXRL29KekP/R8ZAx1MaZiDfyCnxQTo9p X-Google-Smtp-Source: AGs4zMZYFo99X6jMXHXEfxgEuR9iB32RYHvosDqWNT/6/iXrqOqpu6CUqzhmDO1Y8cWeVVbBoPMW3n7kU0StThv24n0= X-Received: by 10.202.48.8 with SMTP id w8mr12337674oiw.284.1512344365956; Sun, 03 Dec 2017 15:39:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 3 Dec 2017 15:39:25 -0800 (PST) From: Martin Thomson Date: Mon, 4 Dec 2017 10:39:25 +1100 Message-ID: Subject: Multiplexing and QUIC To: 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: Sun, 03 Dec 2017 23:39:28 -0000 This is already on the avtcore list (for those who are participating there), but I thought that I'd share my perspective on the multiplexing issue. https://datatracker.ietf.org/doc/html/draft-thomson-mux-principles In short, I say that multiplexing doesn't grant any special entitlement. We might make some changes to accommodate multiplexing for QUIC, but as a general-purpose protocol, QUIC can't let one use case constrain its design unnecessarily. QUIC also has a multiplexing concern we inherit by default: those deploying gQUIC will need to have a migration strategy. Many of the concerns raised about multiplexing QUIC with protocols like SRTP also apply to that version migration. I think that it would be unfortunate if the shape of gQUIC were to unduly constrain the shape of QUIC long term. From nobody Sun Dec 3 16:49: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 1E182127136 for ; Sun, 3 Dec 2017 16:49: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnOU5iAdsNFW for ; Sun, 3 Dec 2017 16:49:51 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 61A78127137 for ; Sun, 3 Dec 2017 16:49:51 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id i1so13377025oth.9 for ; Sun, 03 Dec 2017 16:49:51 -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=FbbilvEzFmAPnfrPLEjAqt64aQr+Zer09Ay0EJx+YTU=; b=V836pKnY0EeUu0n/SZ56ffo6+YGBTmWw3M8py/cxNojc/rOJBjwUPxGABlIdcIWx2W d3dM65HZaJqWsIdBo5COz8oUcjpz/w5Yj6xJ7Q7oyTluAX08l70Q14HfcOIL/PCFUnBd YT1vy0VGgzTw59+32c90eDJxD4gqXc/8DqY/aAMlOexAasJL/T7mHz9QQujhQTC0QpK0 qa9tAysrcTXYSaZppAfJiew1uyt/SciouHEz1Rkr1nnWolAdddAkRht3z/i9olhJwt7Z 2knM1kCvCgibP+7N5aU6m/I7z+18NiOMev/PdxqjOL175rR0Za8EtN86+nAr72imFJOE JcOQ== 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=FbbilvEzFmAPnfrPLEjAqt64aQr+Zer09Ay0EJx+YTU=; b=EUQDyopDUEFwFTJxrnypQNeZuoYF0l4ve+ybbFXnmQIAljqh/lqSISi1zvI4XLY+yU LaLFf89le+oPnWvNPVFixC3tQGemNMLvmnHMY++4f0hpMNS7OgEvdw//4zH6pGVVY4wf /8O5XWYsgQLLvtrafNiZdDaDavkKgpPc/+Nzr+xVMHxWc4zUSOIeJ8kYgS1vEFLL8Mw1 dfqnqLqs9FE+z8BGjcgPU575uWW6DlYJMOqouP/wVSk8YVVdBb3sTiWgj2uAgYxZQCu4 02gvXF2Oi+ei1uUf51+KqysoGwMxWR7sJtwbeojGeJEanac/8+dpsHnPTiYLqppTelt4 TtPw== X-Gm-Message-State: AJaThX7Qud8nyKUbh8yDaWpazZYILT0vId6m7Fivsr0mKXzZY3a5qCLq HZ2TXXQCmTv89Cx2tlEfp7zK4LMp75ZxHunb+9CTc1Tu X-Google-Smtp-Source: AGs4zMYx77isOU7NgR23hJ0s8T8kqUWVWcduWa8TA4GyKTfumP+BIv3PkEx2enVq4zKPZadR0N/nssiUEzdi3b+T8NQ= X-Received: by 10.157.74.4 with SMTP id h4mr14219066otf.308.1512348590593; Sun, 03 Dec 2017 16:49:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 3 Dec 2017 16:49:50 -0800 (PST) In-Reply-To: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> From: Martin Thomson Date: Mon, 4 Dec 2017 11:49:50 +1100 Message-ID: Subject: Re: Invariants draft To: Christian Huitema Cc: 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: Mon, 04 Dec 2017 00:49:53 -0000 Thanks for the comments Christian. I think that this is one of the most important points to reach agreement on, mainly because we get stuck with the outcome for a long time. On Fri, Dec 1, 2017 at 3:46 PM, Christian Huitema wrote: > As far as the general approach is concerned, your draft leaves me > somewhat uneasy. I understand the concern to beat ossification, and to > ensure that future developers can easily define and use extended > versions of QUIC. But at the same time, I am concerned with the tension > between "focusing on extensibility" and "ensuring interoperability". I don't think that this dichotomy is - as you make it - as serious as that. It's a reflection of a design philosophy. The philosophy reads like this: It's easier to design a protocol without extensibility points. Designing good and usable extensibility is really hard. So you invest your effort into designing a replacement strategy and only add the extensibility you know that you need. No matter how much of the protocol you mess up, as long as you can replace the entire protocol, you are never stuck. When we did HTTP/2, we had ALPN. We could have added a *lot* more extensibility to HTTP/2 than we did, but we didn't because we knew that HTTP/3 was always a possibility. That raised the bar for extensibility mechanisms, and I think we produced a better result, more quickly for it. For QUIC, this doc attempts to define that pivotal mechanism. That doesn't mean that QUIC version 2 will be substantially different. On the contrary, I expect that we'll make new versions with only modest changes. But those changes might *appear* to be significant. The hope is that significant changes will be possible because the protocol won't be so ossified as to make them impossible. You might think that this is familiar to Adam Langley's views on extensibility. That is "have one joint and keep it well oiled" -- . That's not coincidental. I happen to agree, see . This is part of the defense against ossification, but it's not complete. As Brian will point out, the actual wire image of a protocol is what ossifies, not what we say that the wire image is. But as you observed, we're working on improving that too. From nobody Sun Dec 3 16:53: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 8D5AF127201 for ; Sun, 3 Dec 2017 16:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUhGJVdTjxig for ; Sun, 3 Dec 2017 16:53:11 -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 230EC126B7E for ; Sun, 3 Dec 2017 16:53:11 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id h9so13397365oti.0 for ; Sun, 03 Dec 2017 16:53:11 -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=qvAJCThWtximp9gHjdf5ruNx1BrEXoIvbvd1PkztPYc=; b=UNkghka+ixxQkJqDM1oAYtx8A0pwAFQnNDGVT++7AsIcWLGkMY5BUef20BpvWdKav0 jjV2u6ABu6UON2IVY8ciaUsK/dZqUHOdFGrbZDw0dUsxXfvbTYyMjB37NPm0uMOohr3h FTCEVu2iT3WWnOsEPFTeMSSUJfRSJSZbnm/qh783eU1X/bwNzaOq/XvonhRM2xVP8CDy Wj5QUxunbnxn3BLFngnEpv49sk2kr5Q7uQsBwY0FNzsWZdFudRFJ4CnM46bvKJ0Wx9N4 CedfzUtGizHIMKggn8ri0d0WUi0M1SLrU38S4fv8mjqGpyYcIeD8kUV8nE5PfKzLcFlc JNiw== 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=qvAJCThWtximp9gHjdf5ruNx1BrEXoIvbvd1PkztPYc=; b=h6EygUUt95cKINrdSSrAa8TpmcUmzyOnTEwMIhocJotD5fnkTLrY6DJ9cwwRe4Ce/F fFU4IRWUg1w5VJq39shXFrx6oCmUnRmZBWa3mKmbG5hAWe7YWsGuj8Q/3ROW9Y6fYPgZ wi3cOH5bwZCL3y56XHymAMn7F1u8AzAzSNb9wz7mcVgW33PjegNzF2jX9cQEH9XSxTvw htop1Xq7liUlDxP5wF/+UTjjID4O1dXzWBJsFkXC3MmA/MBF+xqoF1/ivtqY1svyFnf8 JtaLBqvp39b0yTgSBSg2kqi1BSmM0g7iWXLIZPBu/RUmQB7zL0v/8TEkFy6lbtjWGt4m y3Hg== X-Gm-Message-State: AJaThX6b7shdblLP4NMYFhJ9zYHJWvGbEX8RD4WR5x51dF8gbh3QXbUK /GRZUx65CSzxMnOJWGrBh8B4rvlkp6zy0ZunfAc= X-Google-Smtp-Source: AGs4zMbQ2KS2A4qRjUO+pCSJYG/w+1rBEe8pH5QGLMCmSa/Lp1M70ikeARIxtAlV+5D82CsdkMGCAEwOoiyVy72CXNw= X-Received: by 10.157.32.19 with SMTP id n19mr14874313ota.133.1512348790493; Sun, 03 Dec 2017 16:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 3 Dec 2017 16:53:10 -0800 (PST) In-Reply-To: References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> From: Martin Thomson Date: Mon, 4 Dec 2017 11:53:10 +1100 Message-ID: Subject: Re: Invariants draft To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Christian Huitema , "quic@ietf.org" 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: Mon, 04 Dec 2017 00:53:12 -0000 On Fri, Dec 1, 2017 at 5:26 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Thanks for writing up. > Some input: > Appendix A, incorrect assumptions: > - A 5-tuple is unique to a single connection. > - A client uses ephemeral ports. > > More generally: I find it unfortunate that UDP is made an invariant, anf > possibly even IP. That's intentional. For instance, QUIC over DCCP would be something else entirely and not covered by this promise. The same applies to layering QUIC directly on top of IP, or any imaginable substrate (like your embedded device bus example). Nothing we do here would prevent those things. Though each - as an entirely new thing - would have to overcome its own challenges. From nobody Sun Dec 3 16:55: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 5F0F4126C26 for ; Sun, 3 Dec 2017 16:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt9Y0FCzm5b8 for ; Sun, 3 Dec 2017 16:55:44 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 C7865126B7E for ; Sun, 3 Dec 2017 16:55:44 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id b54so13385793otd.8 for ; Sun, 03 Dec 2017 16:55: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:content-transfer-encoding; bh=+qTB6JPtzElSMrhfG1YYtUoZk+1ZlsuElC9hToM9OGE=; b=IKXThU+8umaEeRBJhy3UCa4yNvb4sBPwbHS15WpLfQrIBi+E6gCrdfNYoZpwN6McpP 9x0qrZa4HLLOuwtkCnhB6Tp57kPwY3eiIPUOIq7d5n37TjfeyYEY0WMOZU9Ka90KOdlD JNaeEOmZ2Wy0CO8onz35J2tWcu+2wbfERZeAUAe2aKbXCyjND/eLlabCxVVjSn4ed6it SzGku9SnM7XnrSvL7sJzT2051BkqE69crmX5YFSVxegKbgQ88C7NNatXlG6KvfJ4LDpp vwqWk/p2RbDs4lAl40NT6eK98HAzSd5EBFm7UEdt5xwkEr2Bh5C2Mul5QtCBSyx2lFgz iZTw== 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=+qTB6JPtzElSMrhfG1YYtUoZk+1ZlsuElC9hToM9OGE=; b=OKLTKpAY5Kbh4z4ArosV6ZYnkbyudNq6LUlkS9i7akPZe9VGX0VeWC1xtQ5NHx0l45 woCUSGZm5od34bxp+JKNhX6okbuQbchFbXqXheiWCZQWAB5WO0bf/4eMMX6WgXcOMMFX sigYpjkx/RRIbsQtrYuxxoIMk+s2sA9S4jZSRvpoNq0qrq5BCzvv4AnqiRznmdKYHb2w TC2E6NVn/apKgDdkncWzlLZBs1yZ0XNpZgiVmlLClbnwiAU+brhdmHBFHXQ6ERqOfFKz Jw7I2EstqPYSNIMRmkjIUNPcUIWI2NIGmgvw6F3Njck2QgvDqEvn04B1pvE7dnvibqBi PoYg== X-Gm-Message-State: AJaThX6hGiZj68xa22DWyPQfAaNFstGMoP1bnOj3DcAxotizh5kSoJNC moTBx/CKYJQLC8j+cYpgTCYa3dH+DMb/j9y4PQRG8w== X-Google-Smtp-Source: AGs4zMY0SaNvt0MHShVSY97j5uEB73/Wz7xFXZbEJOh/6w4LdHx5kO3FZhyRb4ro7nSeg9OZCD7aQ70mtjkKgzO/D+Q= X-Received: by 10.157.74.4 with SMTP id h4mr14226891otf.308.1512348944088; Sun, 03 Dec 2017 16:55:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 3 Dec 2017 16:55:43 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 4 Dec 2017 11:55:43 +1100 Message-ID: Subject: Re: Legacy HTTP gateways To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 04 Dec 2017 00:55:46 -0000 Are you talking about the design or the process by which we produce the des= ign? The process takes all inputs. And I know that people are building gateways just like you describe. We have had requirements from them already. For instance, the ability to disable server push is a feature we have from HTTP/2 that was driven by similar requirements. On Sun, Dec 3, 2017 at 8:08 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Say you only want to only implement a site based on the QUIC/HTTP protoco= l > but you still want to support legacy HTTP and possibly HTTP/2 through a > gateway. Or alternatively you might even want to always use legacy protoc= ols > via a frontend load balancer and only use QUIC to bridge the gap from an > external load balancer into a secure network. > > Does the current QUIC/HTTP design process take this into account? > > For example a gateway might accept HTTP 1.0 and 1.1 and forward to QUIC/H= TTP > but may not support all features such as PUSH. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > From nobody Mon Dec 4 00:10: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 67AF5124205 for ; Mon, 4 Dec 2017 00:10:31 -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, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fIjU48V6qr5 for ; Mon, 4 Dec 2017 00:10:29 -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 C5A621241F5 for ; Mon, 4 Dec 2017 00:10:29 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id b5so10702956itc.3 for ; Mon, 04 Dec 2017 00:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=365S69uNjMLrlsMK1Ir/FmLEnsKNL2zwJGJPR3b2vZw=; b=hJdgJpYJnmFDE52h5IpubSvnO8jwvP4VbywICiWLQSIVexlezMgUQjXdgwk7FZ0/rf Zy61oFHkpiMWBErWy/Lf1oDtID33t/qkcaZe26X8noK58txe68XtSa7j1MZHf1ix2xpj QMV46V+piDzpQtRK6Ba+S4MLFWKzoul7wnC7XYyYIYDPMqt+pGCPoA2w+PLZuLR+G3dZ R1hiQLjBGqLHn9A3VbZO6UVXqF3aWdZbE4rQcYBKN52dlkvl2AQP89YtTtHvDuS37kz4 kBRKwdxqitIXYM+K0Zpi6aJ3lDYV0Wm06B0LwFUQtjOtMs6fpxYVTwmVaVRSMScBxJWP 62Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=365S69uNjMLrlsMK1Ir/FmLEnsKNL2zwJGJPR3b2vZw=; b=A8heGFQZ39M1EzNmUsot1jdpq8yZJ74PgeICV5/DZpjV6AS9SJot5uwKgUt6Ewm1v0 kZBnZ/Ehudr/cEBQKeWe8LZxt7Q49pKQU/3OaOiSufJ8I6mwGxbQtQ58eqf8cEHwvZH6 bzOFTnPPwXOeNPjDAdVNS7riRh6b4P2BAW6fuLPaLmDzyJvVtW+daD+n5Ck1CLMdiCti TVBD5r4NQ+AdJrnygfdsoaiAvjGmH/c6G3Hyc5Q/VbrUfZqYf5bd2klil+omVUAfcPeN 0ZUDYPvkOIXcKFI4kFoNAckaWretqbW0Oiser1GA80pTwXqSOxFBGHXLF12WjbQOeuuN oJZw== X-Gm-Message-State: AJaThX7/95YvBfZqsIavedf5RmsQEPlBEa7PhsJGju1nPGE1xUSaxHyD Ffbd9VNyttxXAfLMX/gEXATPXECKeOdugESEfk0= X-Google-Smtp-Source: AGs4zMZDfHca7eKXsZLgOqCgYI6Slxlb8JLq0nauArhIGznKnmeFaa5+igQTNxe85LrNkWsim4CB0MZUzZi0dgtS1wQ= X-Received: by 10.107.9.223 with SMTP id 92mr22260462ioj.16.1512375029140; Mon, 04 Dec 2017 00:10:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Dec 2017 03:10:28 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 4 Dec 2017 03:10:28 -0500 Message-ID: Subject: Re: Legacy HTTP gateways To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113eca346112c6055f7f40c2" 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, 04 Dec 2017 08:10:31 -0000 --001a113eca346112c6055f7f40c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you talking about the design or the process by which we produce the design? In-between: if the editors are aware of the mentioned concerns and consider addressing these if not already in the design? Your reply covers this nicely, thanks. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 December 2017 at 01.55.44, Martin Thomson (martin.thomson@gmail.com) wrote: Are you talking about the design or the process by which we produce the design? The process takes all inputs. And I know that people are building gateways just like you describe. We have had requirements from them already. For instance, the ability to disable server push is a feature we have from HTTP/2 that was driven by similar requirements. On Sun, Dec 3, 2017 at 8:08 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Say you only want to only implement a site based on the QUIC/HTTP protocol > but you still want to support legacy HTTP and possibly HTTP/2 through a > gateway. Or alternatively you might even want to always use legacy protocols > via a frontend load balancer and only use QUIC to bridge the gap from an > external load balancer into a secure network. > > Does the current QUIC/HTTP design process take this into account? > > For example a gateway might accept HTTP 1.0 and 1.1 and forward to QUIC/HTTP > but may not support all features such as PUSH. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > --001a113eca346112c6055f7f40c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Are you talking about the design or the process by= which we produce the design?=C2=A0

I= n-between: if the editors are aware of the mentioned concerns and consider = addressing these if not already in the design?

Your repl= y covers this nicely, thanks.

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

On 4 December 2017 at 01.55.44, Martin Thomson (<= a href=3D"mailto:martin.thomson@gmail.com">martin.thomson@gmail.com) wr= ote:

Are you talking about the design or the process by which we produce t= he design?

The process takes all inputs. And I know that people are building
gateways just like you describe. We have had requirements from them
already. For instance, the ability to disable server push is a
feature we have from HTTP/2 that was driven by similar requirements.

On Sun, Dec 3, 2017 at 8:08 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen
<mikkelfj@gmail.com> wr= ote:
> Say you only want to only implement a site based on the QUIC/HTTP = protocol
> but you still want to support legacy HTTP and possibly HTTP/2 thro= ugh a
> gateway. Or alternatively you might even want to always use legacy= protocols
> via a frontend load balancer and only use QUIC to bridge the gap f= rom an
> external load balancer into a secure network.
>
> Does the current QUIC/HTTP design process take this into account?
>
> For example a gateway might accept HTTP 1.0 and 1.1 and forward to= QUIC/HTTP
> but may not support all features such as PUSH.
>
>
> Kind Regards,
> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>
--001a113eca346112c6055f7f40c2-- From nobody Mon Dec 4 00:18: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 5DF12124205 for ; Mon, 4 Dec 2017 00:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 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_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhRLxJwij3Yt for ; Mon, 4 Dec 2017 00:17:58 -0800 (PST) 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 EFE171241F5 for ; Mon, 4 Dec 2017 00:17:57 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id t1so10734299ite.5 for ; Mon, 04 Dec 2017 00:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3ic+ThEd/n1XX/OxyO6rVjlr3HZEkaBNKVNFPwwnDTo=; b=fnSvIH79L2MJUXLY0AHk4RHJ2TLxpqoBuzgpyjFCxvR4K5ZBNvResgt1CCnDdbzHsK 4NOWBSZ+y+0xHkqVTUR0BkXac1dm2gVBwd2aQINLMHsUznX2/Tfil/jaJw0P9PDT6O1L s0DRxr/nqnYr7tRUMD2GOB889A9wf5iqiKeUsO8W/Rbxlo8zYv98oTy8Oo1miV2W2a1d 2eloboQowY1/j+JEH8mp+DOi+/BK2wUXI8st0y2SJM4sUpJPxkzX9MelpJ2DILAlBNUi FfakBLVF0MwGWxDzZMlAGE4Ujdrb2GgldcQqMPLWiMipDHk/ZmeMT5ykJ6K8flU6jvLD 0wMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3ic+ThEd/n1XX/OxyO6rVjlr3HZEkaBNKVNFPwwnDTo=; b=SonuqsA0Rfa6T4xG8+32fHgb/fDuMvfGh1H3aMERG21XaC1Sk2aWRP+rISO2MTRJlg JhlAGgxV0wRatuSvp3bkp7wFcgUgUGh435pk6xzzCQy5OAwR1GQZRSQLbmbLASZmun1M C8PpVfUDyonkZ+wQnPCgHJCcITUmSpmkxHY6dJPeZ1zDa9uurti+NTU4XTaKQgWBTab9 wDAD0DuYoL5cibcryTyuLP1IET29QL8tngsdvG2UjFfb1n1bKkBa05TOvxaLFI9K7JAa f+j7EREsSY7BG1aaimrPrV5WgVmo70thI+JkgDO2+Vxffy0b4/Bfa0BrQeNOEjvwKqge N+3w== X-Gm-Message-State: AKGB3mKJz97eizEtB6Ykf/YMVBHbEe0aVIk57Df2wT/MVhDPMof27MTK 3gImtlxcQm6lylBHGcucnqm1CH+/9NGEiTjsSKHqTw== X-Google-Smtp-Source: AGs4zMZ/J1gisdReV80ISFNVcerwofEb5tao0WrcDVW2UIR/1YsFFSVYUYW0IQsawY/EijJQoqoL35WOlkztZ/twK54= X-Received: by 10.36.95.14 with SMTP id r14mr11930335itb.42.1512375477429; Mon, 04 Dec 2017 00:17:57 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Dec 2017 03:17:56 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 4 Dec 2017 03:17:56 -0500 Message-ID: Subject: Re: Invariants draft To: Martin Thomson Cc: Christian Huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b57a1969e0055f7f5ba3" 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, 04 Dec 2017 08:17:59 -0000 --001a1144b57a1969e0055f7f5ba3 Content-Type: text/plain; charset="UTF-8" > More generally: I find it unfortunate that UDP is made an invariant, anf > possibly even IP. That's intentional. For instance, QUIC over DCCP would be something else entirely and not covered by this promise. The same applies to layering QUIC directly on top of IP, or any imaginable substrate (like your embedded device bus example). Nothing we do here would prevent those things. Though each - as an entirely new thing - would have to overcome its own challenges. That is a fair point. For example it might make sense to remove UDP but extend the type field with a routing class identifier for some networks or use cases and such a change could still build on the UDP invariants by stating where it differs. The same could be said about multiplexing. Perhaps my concern is more monopolising QUIC, the name, for UDP. Thus one could say QUIC/UDP invariants. But I also see you have to make some boundaries for a protocol. --001a1144b57a1969e0055f7f5ba3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
> = More generally: I find it unfortunate that UDP is made an invariant, anf=C2=A0
> possibly even IP.<= span class=3D"Apple-converted-space">=C2=A0

That's intent= ional. For instance, QUIC over DCCP would be something=C2=A0
else entirely and not covered by this pro= mise. The same applies to=C2=A0
layering QUIC directly on top of IP, or any imaginable substrate (like= =C2=A0
your embedded device= bus example). Nothing we do here would prevent=C2=A0
those things. Though each - as an entirely new t= hing - would have to=C2=A0
= overcome its own challenges.=C2=A0


That is a fair poin= t. For example it might make sense to remove UDP but extend the type field = with a routing class identifier for some networks or use cases and such a c= hange could still build on the UDP invariants by stating where it differs. = The same could be said about multiplexing. Perhaps my concern is more monop= olising QUIC, the name, for UDP. Thus one could say QUIC/UDP invariants. Bu= t I also see you have to make some boundaries for a protocol.

--001a1144b57a1969e0055f7f5ba3-- From nobody Mon Dec 4 02:06: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 86B40126E7A for ; Mon, 4 Dec 2017 02:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb4-a5TeCvxu for ; Mon, 4 Dec 2017 02:06:51 -0800 (PST) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9832127005 for ; Mon, 4 Dec 2017 02:06:50 -0800 (PST) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vB4A6esY021394; Mon, 4 Dec 2017 10:06:41 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.0361.001; Mon, 4 Dec 2017 10:06:40 +0000 From: Lucas Pardue To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Martin Thomson CC: "quic@ietf.org" , Christian Huitema Subject: RE: Invariants draft Thread-Topic: Invariants draft Thread-Index: AQHTalo6yBpldn/AqUWlcXfXOwAsJaMt6heAgAAb24CABFncAIAAfEQAgAAbp8A= Date: Mon, 4 Dec 2017 10:06:39 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAA094E@bgb01xud1012> References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> 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.4255-8.100.1062-23508.006 x-tm-as-result: No--17.423700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAA094Ebgb01xud1012_" 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: Mon, 04 Dec 2017 10:06:52 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAA094Ebgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCwgdGhlIFRyYW5zcG9ydCBkb2MgaXMgdGl0bGVkIOKAnFFVSUM6IEEgVURQLUJhc2VkIE11 bHRpcGxleGVkIGFuZCBTZWN1cmUgVHJhbnNwb3J04oCdIGJ1dCBRVUlDIGlzbuKAmXQgYW4gYW5h Z3JhbSBmb3IgUXVpY2sgVURQIEludGVybmV0IENvbm5lY3Rpb25zIGFueW1vcmUgcmlnaHQ/IEl0 4oCZcyBtb3JlIG9mIGFuIGFsbC1jYXBzIGlkZW50aWZpZXIgbGlrZSBLRkMuDQoNCg0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IDA0IERlY2VtYmVyIDIwMTcgMDg6MTgNClRvOiBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmc7 IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDogUmU6IElu dmFyaWFudHMgZHJhZnQNCg0KPiBNb3JlIGdlbmVyYWxseTogSSBmaW5kIGl0IHVuZm9ydHVuYXRl IHRoYXQgVURQIGlzIG1hZGUgYW4gaW52YXJpYW50LCBhbmYNCj4gcG9zc2libHkgZXZlbiBJUC4N Cg0KVGhhdCdzIGludGVudGlvbmFsLiBGb3IgaW5zdGFuY2UsIFFVSUMgb3ZlciBEQ0NQIHdvdWxk IGJlIHNvbWV0aGluZw0KZWxzZSBlbnRpcmVseSBhbmQgbm90IGNvdmVyZWQgYnkgdGhpcyBwcm9t aXNlLiBUaGUgc2FtZSBhcHBsaWVzIHRvDQpsYXllcmluZyBRVUlDIGRpcmVjdGx5IG9uIHRvcCBv ZiBJUCwgb3IgYW55IGltYWdpbmFibGUgc3Vic3RyYXRlIChsaWtlDQp5b3VyIGVtYmVkZGVkIGRl dmljZSBidXMgZXhhbXBsZSkuIE5vdGhpbmcgd2UgZG8gaGVyZSB3b3VsZCBwcmV2ZW50DQp0aG9z ZSB0aGluZ3MuIFRob3VnaCBlYWNoIC0gYXMgYW4gZW50aXJlbHkgbmV3IHRoaW5nIC0gd291bGQg aGF2ZSB0bw0Kb3ZlcmNvbWUgaXRzIG93biBjaGFsbGVuZ2VzLg0KDQoNCg0KVGhhdCBpcyBhIGZh aXIgcG9pbnQuIEZvciBleGFtcGxlIGl0IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gcmVtb3ZlIFVEUCBi dXQgZXh0ZW5kIHRoZSB0eXBlIGZpZWxkIHdpdGggYSByb3V0aW5nIGNsYXNzIGlkZW50aWZpZXIg Zm9yIHNvbWUgbmV0d29ya3Mgb3IgdXNlIGNhc2VzIGFuZCBzdWNoIGEgY2hhbmdlIGNvdWxkIHN0 aWxsIGJ1aWxkIG9uIHRoZSBVRFAgaW52YXJpYW50cyBieSBzdGF0aW5nIHdoZXJlIGl0IGRpZmZl cnMuIFRoZSBzYW1lIGNvdWxkIGJlIHNhaWQgYWJvdXQgbXVsdGlwbGV4aW5nLiBQZXJoYXBzIG15 IGNvbmNlcm4gaXMgbW9yZSBtb25vcG9saXNpbmcgUVVJQywgdGhlIG5hbWUsIGZvciBVRFAuIFRo dXMgb25lIGNvdWxkIHNheSBRVUlDL1VEUCBpbnZhcmlhbnRzLiBCdXQgSSBhbHNvIHNlZSB5b3Ug aGF2ZSB0byBtYWtlIHNvbWUgYm91bmRhcmllcyBmb3IgYSBwcm90b2NvbC4NCg== --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAA094Ebgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPldlbGwsIHRoZSBUcmFuc3BvcnQgZG9jIGlzIHRpdGxlZCDigJxRVUlDOiBBIFVE UC1CYXNlZCBNdWx0aXBsZXhlZCBhbmQgU2VjdXJlIFRyYW5zcG9ydOKAnSBidXQgUVVJQyBpc27i gJl0IGFuIGFuYWdyYW0gZm9yIFF1aWNrIFVEUCBJbnRlcm5ldCBDb25uZWN0aW9ucyBhbnltb3Jl IHJpZ2h0PyBJdOKAmXMgbW9yZSBvZiBhbiBhbGwtY2FwcyBpZGVudGlmaWVyDQogbGlrZSBLRkMu IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+U2VudDo8L2I+IDA0IERlY2Vt YmVyIDIwMTcgMDg6MTg8YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBxdWljQGlldGYub3JnOyBDaHJp c3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IEludmFyaWFudHMgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyBNb3JlIGdlbmVyYWxseTogSSBmaW5kIGl0IHVuZm9ydHVuYXRlIHRoYXQg VURQIGlzIG1hZGUgYW4gaW52YXJpYW50LCBhbmY8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KJmd0OyBwb3NzaWJseSBldmVuIElQLjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpUaGF0 J3MgaW50ZW50aW9uYWwuIEZvciBpbnN0YW5jZSwgUVVJQyBvdmVyIERDQ1Agd291bGQgYmUgc29t ZXRoaW5nPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCmVsc2UgZW50aXJlbHkgYW5kIG5vdCBjb3ZlcmVkIGJ5IHRoaXMgcHJvbWlzZS4gVGhlIHNh bWUgYXBwbGllcyB0bzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQpsYXllcmluZyBRVUlDIGRpcmVjdGx5IG9uIHRvcCBvZiBJUCwgb3IgYW55IGlt YWdpbmFibGUgc3Vic3RyYXRlIChsaWtlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnlvdXIgZW1iZWRkZWQgZGV2aWNlIGJ1cyBleGFtcGxlKS4g Tm90aGluZyB3ZSBkbyBoZXJlIHdvdWxkIHByZXZlbnQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KdGhvc2UgdGhpbmdzLiBUaG91Z2ggZWFjaCAt IGFzIGFuIGVudGlyZWx5IG5ldyB0aGluZyAtIHdvdWxkIGhhdmUgdG88c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0Kb3ZlcmNvbWUgaXRzIG93biBj aGFsbGVuZ2VzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYXQgaXMgYSBmYWlyIHBvaW50LiBGb3IgZXhhbXBs ZSBpdCBtaWdodCBtYWtlIHNlbnNlIHRvIHJlbW92ZSBVRFAgYnV0IGV4dGVuZCB0aGUgdHlwZSBm aWVsZCB3aXRoIGEgcm91dGluZyBjbGFzcyBpZGVudGlmaWVyIGZvciBzb21lIG5ldHdvcmtzIG9y IHVzZSBjYXNlcyBhbmQgc3VjaCBhIGNoYW5nZSBjb3VsZCBzdGlsbCBidWlsZA0KIG9uIHRoZSBV RFAgaW52YXJpYW50cyBieSBzdGF0aW5nIHdoZXJlIGl0IGRpZmZlcnMuIFRoZSBzYW1lIGNvdWxk IGJlIHNhaWQgYWJvdXQgbXVsdGlwbGV4aW5nLiBQZXJoYXBzIG15IGNvbmNlcm4gaXMgbW9yZSBt b25vcG9saXNpbmcgUVVJQywgdGhlIG5hbWUsIGZvciBVRFAuIFRodXMgb25lIGNvdWxkIHNheSBR VUlDL1VEUCBpbnZhcmlhbnRzLiBCdXQgSSBhbHNvIHNlZSB5b3UgaGF2ZSB0byBtYWtlIHNvbWUg Ym91bmRhcmllcyBmb3IgYSBwcm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAA094Ebgb01xud1012_-- From nobody Mon Dec 4 05:59: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 761C612741D for ; Mon, 4 Dec 2017 05:59:56 -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 oLEoOSog7oTx for ; Mon, 4 Dec 2017 05:59:53 -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 B72EE127369 for ; Mon, 4 Dec 2017 05:59:44 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 987E5340810; Mon, 4 Dec 2017 14:59:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.9345); Mon, 4 Dec 2017 14:59:42 +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; Mon, 4 Dec 2017 14:59:42 +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.18) with ESMTPSA id 38146791; Mon, 04 Dec 2017 14:59:40 +0100 From: "Brian Trammell (IETF)" Message-Id: <813A9ABD-86D9-4BC2-A5F6-F862F75D6CEB@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_6C8D1953-27E2-4A9C-AAAB-D1E1D796B613"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Invariants draft Date: Mon, 4 Dec 2017 14:59:39 +0100 In-Reply-To: Cc: Christian Huitema , QUIC WG To: Martin Thomson References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> X-Mailer: Apple Mail (2.3273) 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, 04 Dec 2017 13:59:56 -0000 --Apple-Mail=_6C8D1953-27E2-4A9C-AAAB-D1E1D796B613 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all, > On 4 Dec 2017, at 01:49, Martin Thomson = wrote: > For QUIC, this doc attempts to define that pivotal mechanism. That > doesn't mean that QUIC version 2 will be substantially different. On > the contrary, I expect that we'll make new versions with only modest > changes. But those changes might *appear* to be significant. The > hope is that significant changes will be possible because the protocol > won't be so ossified as to make them impossible. >=20 > You might think that this is familiar to Adam Langley's views on > extensibility. That is "have one joint and keep it well oiled" -- > . That's not > coincidental. I happen to agree, see > = . >=20 > This is part of the defense against ossification, but it's not > complete. As Brian will point out, the actual wire image of a > protocol is what ossifies, not what we say that the wire image is. > But as you observed, we're working on improving that too. Thanks for saying this so I don't have to. :) This document is (1) a very clear description of (2) what seem to be to = be the right set of prescriptive invariants. Thanks for putting it = together! On "it's the actual wire image that ossifies", I was divided = on whether or not this document should attempt to discuss "descriptive" = invariants, i.e. those parts of the Version 1 wire image that are less = likely to be deployably changeable in Version 2. Having read it, though, = I don't think they belong here, and I think we'll actually need some = deployment experience with Version 2 before we'll be smart enough to say = anything definitive about what's more or less ossifiable. I'm not sure = that our experience with TCP will translate very well here, especially = if we can turn the crank on a Version 2 by, say, late 2019. Indeed, I'm still a bit of a pessimist that invariants and greasing will = actually work as well as we (the WG) think they will. We don't really = have an experiment at Internet scale to demonstrate that greasing works = at the level that QUIC proposes to use it, and the threat model it = supposes for middlebox deployment behavior is ad-hoc and implicit. IMO = the best way to prove all this works quickly would be to define and = deploy versions 1 and 2 simultaneously, but I suspect that wouldn't have = the impact on the version 1 milestones that the WG and the chairs would = like to see. Might I suggest, though, that defining Version 2 milestones = now (I'd suggest that "whatever is shippable in late 2019", whether that = includes MP, PR, both, or neither, is a good target from a preventing = ossification PoV) might make sense in terms of committing the WG = publicly to exercising these mechanisms in a useful way? Cheers, Brian --Apple-Mail=_6C8D1953-27E2-4A9C-AAAB-D1E1D796B613 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlolVMsACgkQihK3vwvq RqNCAhAAqw7BVibBnm5CVVu4XUB63fWwZMtRLzNEVxXRvB0F0UzmM28JD+bmHmBN DNhUPBOsoZv/KsJu/F/EXTeMObI5+It+lO0RPAshObqD+uGh9zA+UA6TvgoChJgn QM2GupeVijpTkBSbSHleRApdGi6fXaLQifGL0OqMFUwla1H0oWlnOpmVuXE3LD3K VhstJB1gqid/c5QEDc4YD6yq5eXNskfg7bKR9dSGeJKAdTWnvgoVYckEnG9S1cx1 JwfoD3rSa0L/U7WTEKaRPIQI8uIQj58L9btwKUgqotFKf7UT8LKH2Yx8bp0isUWA 4MNs6W6hFeMtdTyB/rLeZ2QXhtGsB/J989V3/Zo3UwZKNKfEkmNANSadHNEhQRj7 EAuinag9ECdbeb0IsqbhnQ1/AU1xHU+YYMo1tYIF4alQ4NlIqpWeFR5hRFt3IUMB 56W34SYe4ddxDWHaCz7lVQw3DZVRmZJ06y+ZacJ+fsRGUhW+0x+ObmlJ33/F0ogz cC4VrpmIR7MnQwRmRgqG9IMi6BZVa7aRxPGewHzFxSsUd1W5P1WfjoDOusjFEnhc K6RYiZJSnyk79MJZmnyGI8xRVaevP2srqFwTkIhztLvHpclY0bsQuUOgnjsyZfEM yuOJ47rbfcGt9zCYAb7la4ZeLT70stp3FNZRs3pzwp08gZrf6NM= =Wy3k -----END PGP SIGNATURE----- --Apple-Mail=_6C8D1953-27E2-4A9C-AAAB-D1E1D796B613-- From nobody Mon Dec 4 06:46: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 6CD4F127601 for ; Mon, 4 Dec 2017 06:46:14 -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, HTML_MESSAGE=0.001, 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 iiJ9jRMDKTvs for ; Mon, 4 Dec 2017 06:46:12 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 27A321274D2 for ; Mon, 4 Dec 2017 06:46:10 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vB4EjQJg022506 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Dec 2017 15:45:27 +0100 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eLrzL-0001zn-Bg; Mon, 04 Dec 2017 15:44:55 +0100 From: "Philipp S. Tiesel" Message-Id: <2EC600A4-0FD3-4136-8022-B3F944E67A19@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_BDE07FF3-1385-4320-9AA2-27E5DD7F0DF8" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: Invariants draft Date: Mon, 4 Dec 2017 15:45:25 +0100 In-Reply-To: Cc: QUIC WG To: Martin Thomson References: X-Mailer: Apple Mail (2.3445.4.7) 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, 04 Dec 2017 14:46:14 -0000 --Apple-Mail=_BDE07FF3-1385-4320-9AA2-27E5DD7F0DF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 1. Dec 2017, at 05:09, Martin Thomson = wrote: >=20 > I've just submitted a personal draft that describes the invariants > that I think we agreed to in Singapore. >=20 > https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants = Reading the draft, I wondered whether we should put some rudimentary = amplification attack mitigation in the invariant version negation = description. Something alongside: =E2=80=9CDon=E2=80=99t send a version negotiation = packet in replay to a smaller packet=E2=80=9D. AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_BDE07FF3-1385-4320-9AA2-27E5DD7F0DF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On 1. Dec 2017, at 05:09, Martin Thomson = <martin.thomson@gmail.com> wrote:

I've = just submitted a personal draft that describes the invariants
that I think we agreed to in Singapore.

https://datatracker.ietf.org/doc/html/draft-thomson-quic-invari= ants

Reading the draft, I wondered whether we should = put some rudimentary amplification attack mitigation in the invariant = version negation description.

Something alongside: =E2=80=9CDon=E2=80=99t send a = version negotiation packet in replay to a smaller packet=E2=80=9D.
AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_BDE07FF3-1385-4320-9AA2-27E5DD7F0DF8-- From nobody Mon Dec 4 07:10: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 B6666127698 for ; Mon, 4 Dec 2017 07:10:03 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLA5AGsL_jIT for ; Mon, 4 Dec 2017 07:10:02 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE1E1275C5 for ; Mon, 4 Dec 2017 07:10:01 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id p139so13460239itb.1 for ; Mon, 04 Dec 2017 07:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=LG4TUm5d6MVy4G1Vxz4uBudaXeefpqEJp+ZirKer1Vg=; b=QcLtXdCiLKartLjWFytpNlgaNXtKz5Mzvd/OGoHV29XFaEvILUKjbDuuyekImHDeUq ECB9k6rYJP8VZB4tVc8ru5rqCVX4AKcknG06ndCRAjXUUdmXQaYOO8GNILNaxcCSwrqK lEul2y9fg4+PCdeWvzVjOFZ8EVC4BOO8y9UVk+EK9zlyWCLrWwx6HM8oKj5U6CT1T7bt kdhFne+qorRbt5JsAqDgDjzDdo4v1ZOhC0NY4Jl4Kt0+JWOIcaBd0VuB+D7Dq6GoIS7/ qLXTLg3vqiFugDHSHiPkUapn2n8hKVVN32PXkAq+kJKPPUPBei8DTuj8b5YfmH6ivAGH 9VjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=LG4TUm5d6MVy4G1Vxz4uBudaXeefpqEJp+ZirKer1Vg=; b=B9chBC3P0X4QM43DteiunnIKkdY4qc/L1blcwHuw9ef63BFbeaaZGyvjOikkbC/Gxb ok107Y+qFvCKyjPXmoLbaqSIE/SCLYzG7dEVCeASC1KtOfl3lj87WZMddj0IF6u1B+JO qGh3izb19P07TYF+FJ89+sBliCabeBos3kWt7PXKgNiXg1F2wR37+OgnNDn8fJLUzM9K MtcLz7WxEFQRxM93GcO9x9aWIrqQXpf0EMefNl52dsNkJ+WAtTYY8+cAXsuhUlCtPBZY lPoHZfxJNOLjczs6Ks7zgEvXe0Sa3z7NlPh5YKpUjtycdgGXixzcboH/btwKnWRAKIjW dGtw== X-Gm-Message-State: AJaThX6qszED6LH2ogVEW/XzqHCHFdBFgTSKEMv8A9Dmm3hUVdHQh2Sy vC4DqqHff8I+Mc+ZkOarSk2Wom4QtFlOuWKbjnA= X-Google-Smtp-Source: AGs4zMagOVOSOzYpkHYat8Cw3o2XrUVJtE6bmvb7JJNwEWywsml3ioUfYAUn9nEut52awjSLATQOi3VEIzURYqHhTL4= X-Received: by 10.36.0.209 with SMTP id 200mr13888470ita.55.1512400201234; Mon, 04 Dec 2017 07:10:01 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Dec 2017 10:10:00 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <2EC600A4-0FD3-4136-8022-B3F944E67A19@in-panik.de> References: <2EC600A4-0FD3-4136-8022-B3F944E67A19@in-panik.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 4 Dec 2017 10:10:00 -0500 Message-ID: Subject: Re: Invariants draft To: "Philipp S. Tiesel" , Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a11c14088c0be04055f851cdb" 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, 04 Dec 2017 15:10:04 -0000 --001a11c14088c0be04055f851cdb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Something alongside: =E2=80=9CDon=E2=80=99t send a version negotiation pack= et in replay to a smaller packet=E2=80=9D. You could imagine a QUIC version that is behind a DoS protected network where resources are highly constrained, such as battery powered sensor networks. They might want define a QUIC version that allows for a small initial packet size in order to save power and to reduce latency. Invariants should be rather conservative and only ensure that changes are consistently possible, not reduce the design space of new versions, IMHO. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 4 December 2017 at 15.46.24, Philipp S. Tiesel (phils@in-panik.de) wrote= : Hi, On 1. Dec 2017, at 05:09, Martin Thomson wrote: I've just submitted a personal draft that describes the invariants that I think we agreed to in Singapore. https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants Reading the draft, I wondered whether we should put some rudimentary amplification attack mitigation in the invariant version negation description. Something alongside: =E2=80=9CDon=E2=80=99t send a version negotiation pack= et in replay to a smaller packet=E2=80=9D. AVE! Philipp S. Tiesel / phils=E2=80=A6 --001a11c14088c0be04055f851cdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Something alongside: =E2=80=9CDon=E2= =80=99t send a version negotiation packet in replay to a smaller packet=E2= =80=9D.
<= br>
You coul= d imagine a QUIC version that is behind a DoS protected network where resou= rces are highly constrained, such as battery powered sensor networks. They = might want define a QUIC version that allows for a small initial packet siz= e in order to save power and to reduce latency.

Invariants should be rather conservative and o= nly ensure that changes are consistently possible, not reduce the design sp= ace of new versions, IMHO.

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


On 4 December 2017 at 15.46.24, Philipp S. Tiesel (phils@in-panik.de) wrote:

Hi,

On 1. Dec 2017, at 05:09, Martin Thomson <martin.thomson@gmail.com> w= rote:

I've just submitted a personal draft that describes the invariants
that I think we agreed to in Singapore.

https://datatracker.ietf.org/doc/html/draft-thomson-quic-in= variants

Reading the draft, I wondered whether we should put some rudimentary amplification attack mitigation in the invariant version negation description.

Something alongside: =E2=80=9CDon=E2=80=99t send a version negotiation= packet in replay to a smaller packet=E2=80=9D.

AVE!
=C2=A0 Philipp S. Tiesel / phils=E2=80=A6
 --001a11c14088c0be04055f851cdb-- From nobody Mon Dec 4 14:45: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 257E1128D44 for ; Mon, 4 Dec 2017 14:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxXZ50AHSE5s for ; Mon, 4 Dec 2017 14:45:24 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA79128D40 for ; Mon, 4 Dec 2017 14:45:24 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id f69so12900404oig.10 for ; Mon, 04 Dec 2017 14:45: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:content-transfer-encoding; bh=fr+pm9hn7fJRS9elP2uW3uDyXvAl2dr/uCmvUXIWxXE=; b=O5IkQyTTp8qllShZio2oNDTEOQ/E23CAMKXGVNq4dJZGKw4htZrs5rCVYAxuNU6Npo AMmEBxiYlSTB1hxMRZxYk8zZOMoO1renB0nwC2tl1rEmVFVCxuRSsBFxGILf4jgeKqnN fNOnAvt1Dj6fz1QOsZjiLKcDSORd2l9L6fQQtKiHRTu/bs0poZcL4OV9GxwdqC9ntO/a 0tErfejGaxvvtHSYmraw54poS2BZuH51aLLk9GUXgLXsMWAzumXaq5LCkvOkDNUAohTC MU3NFGiaHocfAMHhVlnt+nlTbZsNoPOqaQJauFbgPevmff57RLaVO8mYovd8cexe5isp 0U4g== 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=fr+pm9hn7fJRS9elP2uW3uDyXvAl2dr/uCmvUXIWxXE=; b=p22+PtLT8P/6XxsGxlBUnCAHTM0O8CNPBjINr1ZRS6p6xpTonUzPUm7dgHyUJszSMM 6gEK2AKMwUj/HdSfquRGypZ76bSsitvn1LvbpGLhJT+2Pbow5v0nB8J/pqW+9kIbIdwE xnWkVKAv3Wixok8ERbUTvhFp/z6uxBmzndnlK1Jd61OqJGWZZHCfTpFYOEyWQoPSC9Gx DUPbtJf2+fLc5ZpYBWUtuz8dhTs8CBYtZ5pJ5J+2rAiGgw4uSJ4IV6QG88Gj6OCgs2dA 38vrRtWwpdBu4PHJa0ChofFx9/i1uxC+J2TDNAcmlmcOfXPn/LfKZRo/STla1g14gX51 2TjQ== X-Gm-Message-State: AJaThX4NGcCDrrNe+lIsu65qfe0gTN1dMyehOU615JWWwWCXB4RdogpW cOqTT3XKvlHMxPWdjqK7jGINwFR4r7K9OotvEPdlKg== X-Google-Smtp-Source: AGs4zMaFHLrCUhqgwxCnXLW1Ndmf+ATs0gyWDLQMpKECOBwG7ezOJlCkUmaSmzo/ohPf5TmLGYP/QWy4ux0T11k6UkA= X-Received: by 10.202.180.69 with SMTP id d66mr8231686oif.92.1512427523213; Mon, 04 Dec 2017 14:45:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 4 Dec 2017 14:45:22 -0800 (PST) In-Reply-To: <813A9ABD-86D9-4BC2-A5F6-F862F75D6CEB@trammell.ch> References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> <813A9ABD-86D9-4BC2-A5F6-F862F75D6CEB@trammell.ch> From: Martin Thomson Date: Tue, 5 Dec 2017 09:45:22 +1100 Message-ID: Subject: Re: Invariants draft To: "Brian Trammell (IETF)" Cc: Christian Huitema , 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: Mon, 04 Dec 2017 22:45:26 -0000 On Tue, Dec 5, 2017 at 12:59 AM, Brian Trammell (IETF) w= rote: > Might I suggest, though, that defining Version 2 milestones now (I'd sugg= est that "whatever is shippable in late 2019", whether that includes MP, PR= , both, or neither, is a good target from a preventing ossification PoV) mi= ght make sense in terms of committing the WG publicly to exercising these m= echanisms in a useful way? I'm on board for that. Separately, it would be nice if the solution to the QUIC/realtime multiplexing problem was to define a version of QUIC specific to that application. That wouldn't be as good as two versions of QUIC-for-HTTP, but it would help. From nobody Mon Dec 4 14:57: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 54D0A128D40 for ; Mon, 4 Dec 2017 14:57: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 h0xDtOIO8eEh for ; Mon, 4 Dec 2017 14:57:42 -0800 (PST) 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 48B0A128D64 for ; Mon, 4 Dec 2017 14:57:42 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id u10so24952377qtg.2 for ; Mon, 04 Dec 2017 14:57: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=kio68I+8Osa0rsAN8QNfDfd4zMYhPSL/zd4wiPpkRhM=; b=cC1X5lYSrfLPqJuqsAA1FfvxMbperoKYepb1PyKwpEHrXvu1zUV2QnaOs/TAkz5QZc v6EyJr+TDFN/V/lQPhY0EgUhiAtSJSonMP7RSLU53zOasO/vMATmcbO41awfDBVy/vuZ 4WTiXjQ2K8MzqihNIWSf/FxOxAKAk+kPlgpuspQXHMChHq0Id/rWp24VS4O+cUn4LKUG ZvhoZqV1EsAzI3giaFxhHVNG9vWXdAxqeGPA0U1SIbATxPjcKdR/jTrub9GcLoBCxLQH K0onKG6HoDEmibUjHusCjnJgxsqwRL088ap8KdEjdIjqk4L6mHCGxZ/XTwAhWFbpg16S 62mw== 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=kio68I+8Osa0rsAN8QNfDfd4zMYhPSL/zd4wiPpkRhM=; b=ERvuTEU95yd+31Upw4PzyxvMSnV4uxPaSeUYFIuLPrvOwRCHeCOETfb98ENiaIypbt opYCWXA6OGUnetEokpSFn+kzqpcW+FcTxp6vBztZdL+oKd4Ah6rqUwMXVA06uZYPWm7/ l9j+GZVd/gWVsbS7y6FpXLyYE+CF5xP8d1rLOl94wjeQuEcxZe1wO38Z/Y/vl9lzs+Zs Wq1iTgyvG4PqSDenU3X+3yJUL2kEnQ22xLO/glGgY6cpmK12/j/DlzC0kKe5Lwlt7PKt Z3pYXDXDxAEOAbo1QFITdMZvLUqvXSLq7eths8KI43nvrFgJpFWQnMHIGN5DSbmzlba5 GaXw== X-Gm-Message-State: AKGB3mJhwYHkhPaZYBKDTCsqudIe8ml7rcU26xbS5fqEohrwHWaB71wI mabmM2QRar7pZ5hiH3lfLjxSH7Bo3Vad2PMGWLs= X-Google-Smtp-Source: AGs4zMZhCMq6pIGl0Coeax8l2GNKOxtxcqiX03YxHT79owtxcmDc5I4JyZBEjQt4qZhZtg19drIFt4cFGCwkARE61P0= X-Received: by 10.55.155.198 with SMTP id d189mr19958990qke.347.1512428261221; Mon, 04 Dec 2017 14:57:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Mon, 4 Dec 2017 14:57:10 -0800 (PST) In-Reply-To: References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> <813A9ABD-86D9-4BC2-A5F6-F862F75D6CEB@trammell.ch> From: Ted Hardie Date: Mon, 4 Dec 2017 14:57:10 -0800 Message-ID: Subject: Re: Invariants draft To: Martin Thomson Cc: "Brian Trammell (IETF)" , QUIC WG , Christian Huitema Content-Type: multipart/alternative; boundary="94eb2c0d040e422ccf055f8ba5e2" 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, 04 Dec 2017 22:57:44 -0000 --94eb2c0d040e422ccf055f8ba5e2 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 2:45 PM, Martin Thomson wrote: > On Tue, Dec 5, 2017 at 12:59 AM, Brian Trammell (IETF) > wrote: > > Might I suggest, though, that defining Version 2 milestones now (I'd > suggest that "whatever is shippable in late 2019", whether that includes > MP, PR, both, or neither, is a good target from a preventing ossification > PoV) might make sense in terms of committing the WG publicly to exercising > these mechanisms in a useful way? > > I'm on board for that. Separately, it would be nice if the solution > to the QUIC/realtime multiplexing problem was to define a version of > QUIC specific to that application. That wouldn't be as good as two > versions of QUIC-for-HTTP, but it would help. > > Not that the cast of characters is all that different, but do you anticipate that being the job of this group or RTCWebBis? Ted --94eb2c0d040e422ccf055f8ba5e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 4, 2017 at 2:45 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On Tue, Dec 5, 2017 at 12:59 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> Might I suggest, though, that defining Version 2 milestones now (I'= ;d suggest that "whatever is shippable in late 2019", whether tha= t includes MP, PR, both, or neither, is a good target from a preventing oss= ification PoV) might make sense in terms of committing the WG publicly to e= xercising these mechanisms in a useful way?

I'm on board for that.=C2=A0 Separately, it would be nice if the= solution
to the QUIC/realtime multiplexing problem was to define a version of
QUIC specific to that application.=C2=A0 That wouldn't be as good as tw= o
versions of QUIC-for-HTTP, but it would help.

Not that the cast of ch= aracters is all that different, but do you anticipate that being the job of= this group or RTCWebBis?=C2=A0

Ted
--94eb2c0d040e422ccf055f8ba5e2-- From nobody Mon Dec 4 15: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 570B9128D69 for ; Mon, 4 Dec 2017 15:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG1xyDSEGMFm for ; Mon, 4 Dec 2017 15:00:00 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 E4CCD128D40 for ; Mon, 4 Dec 2017 14:59:59 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id y10so16249228otg.10 for ; Mon, 04 Dec 2017 14:59:59 -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=RN3LLc6PFXNtlJNE+whVqJq4CETAvZezm9M/co9dhwQ=; b=i26gTwSJYF147nazA125yXiNjOafnRRmunInfsgJ7A/2uvCJDtVQSHT23lNy6rlkRM NYYdTOMN5/a1KrzYD8FPGu9ZN9QZ6Epc4vFMcVSTzM6wnHnF3rndbo+otloCOG1hLajr +SLP847eNurB/GWZ68MZTBqLrqZ4tjCuFsrUz1G8BkFeCvZgQ+nnrjC+glM62T0YOg5T c+kWhoLKwDSvjPwmvSfLwEROnSABYF0e59M0eGk8ZIUaYY6VZpiB72nBw9rC45Q6kCO6 UchwwTdn+TDfYXoM81uMAmJzNuLL5pTZOjjMj7/gv1N45T6+vpo1Qpd+/Lw42Ohf2enw WfYw== 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=RN3LLc6PFXNtlJNE+whVqJq4CETAvZezm9M/co9dhwQ=; b=Hay7YPFEhbmUgaipBtNheVquWY0UNfw6KT5RFLn22IuEvaNYe3ts54XbtU6RSzrmpZ 5JMeBwwcD/1RHa4d3oES5aoZ2UrRxySVg/rGTKj8uSsH10vQh59HnZcv6sgZQBe+jAwW aV31+BvzgveEb5c1W97SgF85cvqeHzLBXaqn0NL3vxNbl9zVW8krmAVjzLCCHQZgVBnl KA0sUamqhdauiROT2CaDzjpPLnq4POBo932WE14ixR9a+v+X3AYB0N0lj5yqtRNF6itC 2qnY5GuHZdIKqo6Cr2WaLjqNMBiymC3tl55TUr2aviPIe2rvEnVgybqynaG6jBnhyZOt 9ddg== X-Gm-Message-State: AJaThX5sCBf/sW7zEvLpPS2w+JtVz+k5+XI29wbhvIdmpnYCuQeuZnvx febHcL2F3QEjx/vsjOumiDF33cARTPtz2Yvg6Jg= X-Google-Smtp-Source: AGs4zMbJ6TluwPP7X2lpZhYmAb1hzRmKMCwrOvFliCU/6jeISmBlVs6IMF/hEnglTYeI48YKbATY9uMmWlecEvY+T5Q= X-Received: by 10.157.74.4 with SMTP id h4mr16981063otf.308.1512428399280; Mon, 04 Dec 2017 14:59:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 4 Dec 2017 14:59:58 -0800 (PST) In-Reply-To: References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> <813A9ABD-86D9-4BC2-A5F6-F862F75D6CEB@trammell.ch> From: Martin Thomson Date: Tue, 5 Dec 2017 09:59:58 +1100 Message-ID: Subject: Re: Invariants draft To: Ted Hardie Cc: "Brian Trammell (IETF)" , QUIC WG , Christian Huitema 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: Mon, 04 Dec 2017 23:00:01 -0000 On Tue, Dec 5, 2017 at 9:57 AM, Ted Hardie wrote: >> I'm on board for that. Separately, it would be nice if the solution >> to the QUIC/realtime multiplexing problem was to define a version of >> QUIC specific to that application. That wouldn't be as good as two >> versions of QUIC-for-HTTP, but it would help. >> > Not that the cast of characters is all that different, but do you anticipate > that being the job of this group or RTCWebBis? Much of the discussion here has happened in avtcore, who look after SRTP (I think). That would be a fine place, as would this group assuming that the effort is cheap (as it should be), but that's just a DISPATCH-style question. From nobody Mon Dec 4 17:29: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 13CEC12711B for ; Mon, 4 Dec 2017 17:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, TVD_SPACE_RATIO=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 Mn7FPUFxX9jt for ; Mon, 4 Dec 2017 17:29:01 -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 137C3126DED for ; Mon, 4 Dec 2017 17:29:01 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id m81so7499110ywd.2 for ; Mon, 04 Dec 2017 17:29:01 -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=FqLeCMNMGjri7sZJmHccx/mjXPMbn7rtrMVdUvKTeuk=; b=l4Ox0K4mSCpONMowji3UtaFFbgIZTpTqzHK2OSV5Hlzx/pmNEyqyMUqtb0XyHicVnd kdLH6rpkv9Xg6ZAQrAH38M0BT9NZeGzpPkQ9/WEM6xbodv5Y9pbft1KLpTopw+WPq30+ zHogBuIIx1o1yTgRxknHBZI/dTM3hqn4J6l4ozwQDvRbMjqqAGVICnOmXQbVTj+4zqao CkiEbQD9lxeLwj+HxC7bZMqpY+58tQFpWP58o6MXcAPvWkajGaA5Hm8sf7XQ/PpUsj9P DRMRT+danKJP6YHf2hQX/zHZOmzSd3yphnV/GHPwRrHjjdQp/CNLMN+yUSH15F2SRoH5 7DWg== 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=FqLeCMNMGjri7sZJmHccx/mjXPMbn7rtrMVdUvKTeuk=; b=jZxT9cj02sWI2+Kv0mQ2KVbw6XP1SsoahSETJjRW74AIzawh57HNlRWYE3SewIjxky o44tyOsb3D2e1psKyOyh2TsBhbD8VU1bH00wtx0moeb0tonGDWgn8kFlUfHWkgarkKPb yMXuMkYrHzu76UoYnErQI5oKfQ7yJylDPYRkq11OIV+RE8l8wwI/4qkJvVa18nrT3qAV hxY0YSzbvmwzB6LbwHU6EdOA14gnfVSdSLlQbTWAOeDewOhLp92XhSkC/NVFQnxWvp+5 2Vy/YzEKsGqPyiF63qm8+aL+44DRJCI4pTznj5hO29YGFg2UanWdIE/h8GB3wJBDu3A1 AdCg== X-Gm-Message-State: AJaThX4hCPHPOS/wFqL6I13D5Tsn+C+zhXKTQgBZo6v5PBX+u7U5V8k3 YrGTd307CMXdqGF5a80MVO5G6Rjh9tUr3UtGJZvPZ292n+4= X-Google-Smtp-Source: AGs4zMZs8gEVcfSnOipP3mq35yYcI5e4h7ZJG1j/dyTsiyVyo3fNOHdgaOHpBoOn6WsuQyIyEehFaEf4RbVHHDcNB9M= X-Received: by 10.129.77.195 with SMTP id a186mr11477798ywb.363.1512437340076; Mon, 04 Dec 2017 17:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Mon, 4 Dec 2017 17:28:19 -0800 (PST) From: Eric Rescorla Date: Mon, 4 Dec 2017 17:28:19 -0800 Message-ID: Subject: Third Implementation Draft Prototype To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1140c8e6668eb1055f8dc29b" 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, 05 Dec 2017 01:29:03 -0000 --001a1140c8e6668eb1055f8dc29b Content-Type: text/plain; charset="UTF-8" Here's my first cut: https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft --001a1140c8e6668eb1055f8dc29b Content-Type: text/html; charset="UTF-8" --001a1140c8e6668eb1055f8dc29b-- From nobody Mon Dec 4 17:44: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 3C7D2126E3A for ; Mon, 4 Dec 2017 17:44:12 -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 (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 C5lbj2kxJtHx for ; Mon, 4 Dec 2017 17:44:10 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 2A356126DED for ; Mon, 4 Dec 2017 17:44:10 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id u62so17681950ita.2 for ; Mon, 04 Dec 2017 17:44: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=UxQo0XmJNM2UX20wpus1l956k5jO7TaUBuFNTvY/wTs=; b=vgolVAGo8D4C33hzMB+ngcCxsogpbSJRKPvrnAMSqIs/+p2OKzlbtFg3jK5WETaQD5 m6GPqPuGbvbeHRep3LOFVZmeKLf/WiYRNWKWWHrWnLU8rrw5pjD7TcZv/Fsq5bxSKO86 Je1QR/bXl98yREJ0b0/KvI7MNgDbjhhyBWnpIwrgW946/b3/F/5SBQuj8yAQAM1logVA EJZO3wRGCvxrVYLZVSHdnFaNzdL4+wJ4in9zRP387DqRDCMFo9r0usRusuJmi6oFuD3D 8dyG/fh2t7KxgSLh1lQTDCLJEB8wsYdJBXT/46yJG6xxH83Z2kejSoyIFwFxGzvls5Ft oFTA== 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=UxQo0XmJNM2UX20wpus1l956k5jO7TaUBuFNTvY/wTs=; b=POTtJrGIgBkp1Htawyd0WCc2R0h0PlR0yb/F/ZStL/xlP8vb/v/lhKKdixaQpEocab c6oil1OBy2wcLkbuXtsAdfhc4wdB5BI5jOGjgxlJIBi5A4EqFsuualmKpsPNgMPjNcjz GrDLVNnvVBIb48/oinrfDHXAu+AUjoreBP+GVhsAjaNtU7VVUz/rSgIICeSntfqUXAZI xxyhyLwjrUUhXjfNh54wh2GPSgJy6nSyiz9fmy+03Uqn3x0alVE3jPSy6L7oZuTt8kPg kklS1UclJXbIsr+LIoFHw7ZuT5m14WdwOle+WGbWreMGxl18kr/itbGg8HxF/IbdDvl/ Yisw== X-Gm-Message-State: AJaThX6t+5RJu7i1IV/eNA7ateRRISps3ibquXsOc5GwduTky0ndYPKg RNbtFo18PJu++01safJTiOp0U7AZylsY809y6jsGvA== X-Google-Smtp-Source: AGs4zMbP9xbqXO2cOF1iVgBUwq/ky7XGGPPjPBrrcxY6NcgVYm3l+0YJDTzFvrGJRc8KORQZZtBbSEw9tMraweDXXLY= X-Received: by 10.107.6.81 with SMTP id 78mr26614321iog.204.1512438249267; Mon, 04 Dec 2017 17:44:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Mon, 4 Dec 2017 17:43:48 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Mon, 4 Dec 2017 20:43:48 -0500 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113ee458981e1a055f8df895" 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, 05 Dec 2017 01:44:12 -0000 --001a113ee458981e1a055f8df895 Content-Type: text/plain; charset="UTF-8" Possibly this is part of "Update to draft-08", but I'd like to explicitly state we're moving to TLS 1.3 draft 22. On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: > Here's my first cut: > https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft > --001a113ee458981e1a055f8df895 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Possibly this is part of "Update to draft-08", b= ut I'd like to explicitly state we're moving to TLS 1.3 draft 22.

On Mon, Dec 4= , 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:

--001a113ee458981e1a055f8df895-- From nobody Mon Dec 4 17:50: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 D3DF3126E3A for ; Mon, 4 Dec 2017 17:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIIvmMoHJszr for ; Mon, 4 Dec 2017 17:50:32 -0800 (PST) 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 C3FF0126DED for ; Mon, 4 Dec 2017 17:50:31 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id w190so11021081vkd.7 for ; Mon, 04 Dec 2017 17:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=kf+dAEFjwtvKpZxXMwYBt8adPtDKQGeQ4ilH21DsmEk=; b=k1EZMdBHn53nBQ7KKVpnohNL3BelW1KsFYyQvpE+6NOO4XdqjDtmFBOk0gfIHrTHLe f1NwgG2SppvuM6o1PsxQkvrkso3scqmyI7XjLumGL7XK5TYeA+0c6cdcZ72w8cUgKv7J Ub7B2iaqjcS+YMzgxzqPHIOdWs84yN/hO/7adZbjHh3daADf5BuyF7jokSnFTOK7Pp/3 INkM6eLqaCdx3E2kOimHPMc7pmGznOLJwtmTab1htcSLt5qi70pwRoo4MJBDWddyHoWN Hog2VTO3aWnTiYKCOsT62oZZBhkSw5qw6j7oZd3x7KnbTuypLKJR/lenfk6undduzSOj jyjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=kf+dAEFjwtvKpZxXMwYBt8adPtDKQGeQ4ilH21DsmEk=; b=GvpGcSKWNdXJ1Syn1NEu62OMM8i4glY1qWO+ZhgqaCf6vDWXAj3BP3Qxt7lRlYVnXc KhaIio319dmSyOnnVJOJC0rWDoahuymmaeBbaAzcVjYbSKPRHWNZvKt/k8xwr/sMVX13 I9wCMAmokU/smxoM4Ph85wmnUwoVbS6O0NTY7YPHzJ+MYgivKV6InmZzz52OGVn5pSrP BYIkCxvS1oNbvramxvtCmXe9f1RvEJdjGFkasL/e43SVTS/VCMwe8JaSgjMiUBxdqYfc yst7JsV2Fx/6r0eEoLAOONaBYvavRoNK/nk9US04feKpw4JZMCLJdNkdWjOkgDbOTNx/ nraw== X-Gm-Message-State: AKGB3mJTF6OkkNtZp7KUWjU2YQY3lpNZ19YYvOZSB4RQfwQpVjjciAY1 q+2jb/kDLZKHQvGxMi/mV4PDo1CM4sVSHsA8ccMeNQ== X-Google-Smtp-Source: AGs4zMa9bLiVDEHWp6MCn1ebOLGahTjDlk6Xk2JQL+cp3m7imwBORMME/D4lPJOfjzQ++oPtzpClXpIHdTIynlK8UoQ= X-Received: by 10.31.73.129 with SMTP id w123mr2116285vka.194.1512438630713; Mon, 04 Dec 2017 17:50:30 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Dec 2017 17:50:29 -0800 From: Marten Seemann In-Reply-To: References: X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Mon, 4 Dec 2017 17:50:29 -0800 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Eric Rescorla , Ian Swett Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114d66f6540e01055f8e0f8c" 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, 05 Dec 2017 01:50:34 -0000 --001a114d66f6540e01055f8e0f8c Content-Type: text/plain; charset="UTF-8" How do we transfer the 1 MB file? Can we move away from HTTP 0.9? On 5. December 2017 at 08:44:16, Ian Swett (ianswett@google.com) wrote: Possibly this is part of "Update to draft-08", but I'd like to explicitly state we're moving to TLS 1.3 draft 22. On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: > Here's my first cut: > https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft > --001a114d66f6540e01055f8e0f8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = How do we transfer t= he 1 MB file? Can we move away from HTTP 0.9?

On 5. Decem= ber 2017 at 08:44:16, Ian Swett (ian= swett@google.com) wrote:

Possibly this is part of "Update to draft-08", b= ut I'd like to explicitly state we're moving to TLS 1.3 draft 22.

On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:

--001a114d66f6540e01055f8e0f8c-- From nobody Mon Dec 4 17:58: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 9F8F5126E3A for ; Mon, 4 Dec 2017 17:58: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 EzVF8YClCroi for ; Mon, 4 Dec 2017 17:58:38 -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 DD604126DED for ; Mon, 4 Dec 2017 17:58:37 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id m129so7511832ywb.11 for ; Mon, 04 Dec 2017 17:58:37 -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=6LxXC9vln+cO5qvuj21fJx2WxjefTcUae51lt/ZTu+E=; b=DrrAEBVT4qPaLrf3pkX1yB0qCEVTmX+Fdw5Amo1K1wj36ihPRqSIyxROn+JVZEB6Lg w197t87ODTDg+mvF8J1e0VYKneIqcEJujTDQ3jsyAZxBbEnPMXE/iQkloiggldlC1FBW 03xkvpYjUrpw6nOWoHjeZOj4SxMrfm9k0PEV2zQ7YiHacgq5nnLLVrPPrpG50HF1WMvX cDsKQqq9/uLXMIXHJKij23kNcAJsX/N76XliuVaLCCF8ebwh5iUbalMNbkdFb00IJ8eV 3n8ZmzqjwcpFmPvxb39nS5JCXV+vnuoBWuMAVzA94/BEt5GEINfQ1NrP0zFm/63ajRFh nR7Q== 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=6LxXC9vln+cO5qvuj21fJx2WxjefTcUae51lt/ZTu+E=; b=Z5k0IA36KDyhAuctIIROJ78pwdEVv47MjIYnWfHMCFQ8pvLoFzzjqHEReYtwX+0D09 5LLWwmSBKSc3dRdKkFeEw7TQ0cx8hIuqTX4HBm84XIiswb1T1tKnpwbPc1rpbBqMuPcC Sf6JdwTeLeLN4QooqnW5ojbKSVIXZqq35cQkXx6esU/Ekzs4HGdI4nik+ejNimNQolyc rvCugbGDtrlFSJNWMXKaKxvK37xqtHyfw664e5mJiWgqIdaxl5aR8kSmeYdJJGOXk4eL BJ8MT0yqJIt7ic+OvUfFjG4VOICJyqF3U4VvFApA2oh32TBrLr+yaAqN99rAaQn0TUyU IbEw== X-Gm-Message-State: AJaThX4vwAXJi5BvHGJWRmlW3I1aZXNFXsItG2dugw2rBWbzTVAkQF8u QD9GeSwYGAUu6orj6vpT82299bO/jygzIm/RkpydSw== X-Google-Smtp-Source: AGs4zMZckqcMJQvGHayiBfWHUS67C1yX/oZzk6yCDZA0CAWDUt84J7C2DOl88Td3NVicRPQPZ1XvIaHFnQMWQC3XRCM= X-Received: by 10.129.77.195 with SMTP id a186mr11526188ywb.363.1512439116930; Mon, 04 Dec 2017 17:58:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Mon, 4 Dec 2017 17:57:56 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 4 Dec 2017 17:57:56 -0800 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Marten Seemann Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1140c8e64f2aa3055f8e2c39" 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, 05 Dec 2017 01:58:40 -0000 --001a1140c8e64f2aa3055f8e2c39 Content-Type: text/plain; charset="UTF-8" Why would we move away from HTTP/0.9 for this. On Mon, Dec 4, 2017 at 5:50 PM, Marten Seemann wrote: > How do we transfer the 1 MB file? Can we move away from HTTP 0.9? > > On 5. December 2017 at 08:44:16, Ian Swett (ianswett@google.com) wrote: > > Possibly this is part of "Update to draft-08", but I'd like to explicitly > state we're moving to TLS 1.3 draft 22. > > On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: > >> Here's my first cut: >> https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft >> > > --001a1140c8e64f2aa3055f8e2c39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why would we move away from HTTP/0.9 for this.

On Mon, Dec 4, 2017 at 5:= 50 PM, Marten Seemann <martenseemann@gmail.com> wrote:=
How do we transfer the 1 MB file? Can we move a= way from HTTP 0.9?

On 5. = December 2017 at 08:44:16, Ian Swett (ianswett@google.com) wrote:

Possibly this is part of "Update to draft-08", b= ut I'd like to explicitly state we're moving to TLS 1.3 draft 22.

On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:


--001a1140c8e64f2aa3055f8e2c39-- From nobody Mon Dec 4 18:00: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 7D84812711B for ; Mon, 4 Dec 2017 17:59:59 -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 HZAE6oivXK-C for ; Mon, 4 Dec 2017 17:59:58 -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 1C784126DED for ; Mon, 4 Dec 2017 17:59:58 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id t127so7473150ybf.9 for ; Mon, 04 Dec 2017 17:59:58 -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=UR0KewgFyguY7HNohO4AqXl3Ch+rNZnJ1Orx8C1FCKE=; b=y6aoxLRwRXu8/RPjKGS8uo9deHzYntJOc9dg1pERzfJ44xwBJHaCbo4PQHqvc5weFP gMJs97Q9BLQyfMhIhapWwpQ6PlRjEDmmZYISBvPeOpAt1tTQBNAu6nPOGA6tPcWcoisF Tmzs3nOJ2Y0vkC1B7Bq7MClI2g0neJKkJUX7pPNoafTUgY8M2ZC3uYmkJwZ4UdyF6PQj 1M7UEjQSCS/LvR0WzI+8akiZtZ6W/AdKVKfQpdgdtl0EXvLu+rVzFy6FOlWYYPQtqebv 11TW1aJVaFQA0FTtdphugOGTVePb0Sy3FujepG017OZk0DXIl6x6zecv9QF6sE7ZDsvR bIDQ== 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=UR0KewgFyguY7HNohO4AqXl3Ch+rNZnJ1Orx8C1FCKE=; b=RwwinJRh2ZB+Nh3zakcPWo9enNyis6kKih3+U5LngdRwqsXSGp2vODTkTw+ws7vzTG 6ws8yTSKmsWtsKg/2XG3G+BKohr+a3+CIy5beQoDFp5dgsSpjN4/OX9WPvV9G2c0vz7E 0oDBort0T4F7+kBQlv9P7Q2LbMIInoXGwnarYjz//+yAdXRu5prLWEXUIzysDut/vK+B I0HsNjI6iYRK/GJ+FQ4INtvIxWafJUOfDVY021qJeiJQkXvJY8YiYoezOWMvDF8UVmGV W6rUJ8yeJlRjFR/kuUDsdBvQKKy5b4DMygZuA83d8RExanJethebrtbGrSHyko2vY7mD 1bxg== X-Gm-Message-State: AJaThX4vs/xaPsKWjgmGt1c2Pl+7J7DwyPV6cZQsdBlD4XpOOidjDEbK 2EBiByQa/J1XpMnT4F1Tkt3ixJCY89+ztS1XP2d3lw== X-Google-Smtp-Source: AGs4zMb5ISykmscjhGZojHKCtJ8zwARIluJ+co/CpO7uGdTcJXvPuZ18qtSB4R1aNPeoOm/wIWnykCvESGlfyiEWvsQ= X-Received: by 10.37.106.70 with SMTP id f67mr10699391ybc.423.1512439197241; Mon, 04 Dec 2017 17:59:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Mon, 4 Dec 2017 17:59:16 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 4 Dec 2017 17:59:16 -0800 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Ian Swett Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113fcdb218af52055f8e310f" 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, 05 Dec 2017 01:59:59 -0000 --001a113fcdb218af52055f8e310f Content-Type: text/plain; charset="UTF-8" It is done. -Ekr On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett wrote: > Possibly this is part of "Update to draft-08", but I'd like to explicitly > state we're moving to TLS 1.3 draft 22. > > On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: > >> Here's my first cut: >> https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft >> > > --001a113fcdb218af52055f8e310f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is done.

-Ekr


On Mon, Dec 4= , 2017 at 5:43 PM, Ian Swett <ianswett@google.com> wrote:<= br>
Possibly this is part of= "Update to draft-08", but I'd like to explicitly state we= 9;re moving to TLS 1.3 draft 22.

On Mon, Dec 4,= 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:


--001a113fcdb218af52055f8e310f-- From nobody Tue Dec 5 09:13: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 D5133127871 for ; Tue, 5 Dec 2017 09:13:51 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCsFiTyO_0bq for ; Tue, 5 Dec 2017 09:13:50 -0800 (PST) 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 7F25D124319 for ; Tue, 5 Dec 2017 09:13:50 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id p139so3317697itb.1 for ; Tue, 05 Dec 2017 09:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=ZF9vsApERfbJih4gPJXge1faThL97O4O8cKHxKq3d4w=; b=aq+CI7oc1N3GgO20Iy1N8yLFhOvPloRaQTKXhsV7to5LzjM2nTSknhZ2YW6SgQMOBQ quGBcPQ6YON6UfZFSkYYiR8nZ2yx3iJrq+2q13qcl3x+YnlF09yIP5MVMn6xOH2EiDdU NXEPQzu/nZmX6i8J7uTDcQ1/FwNCKdeQb/ZxqRSVjoCJdzyxIUvRNRBsTFDNvbiRaOfp T1tRcb/E/Lr69G3U7tNnkImJyuKamCZLiBTYPE3Nt5mQLPZ07E4KrVqt1phMCda87DMe WFk+tXAqn2aW1guTn42sXLJEyDX3CBOpAY98dzA5ZRB496CeSlHTSjXOgvSUOBNx/ffj 2/qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=ZF9vsApERfbJih4gPJXge1faThL97O4O8cKHxKq3d4w=; b=fyjFfCuK3YPuLtSBtfGmyjEeHaMcCXwSKTZ7vYXZ3PsmS966Ew5HWMdDTbi2RjNaZY ffl7R0rjMwJzqnS6/bEsow6CMvgg7xwzUnyuQ5HUES6cOc78cLBC6EbRvaBgU8W9kH58 tCQy+9OvpWXMmRhF+Nr2TN6g+Nb33ddlifLBy7qghgCiRwjALdTAURb+emM4vM3Q4ZUj kDlSDS7g2fk0LuYw3B+luwFlWgzq5xhbFr1r6Q6fzO5iOO4qHLiOTX+Ds0Md0ii44B6p z7ImbNuJkLepgn+EQYebRcB49hCtyF4Jn03orW6jpVYd0Fbv8EiBWiPQhYh9b3jeF1bx O1ZA== X-Gm-Message-State: AJaThX7IqgCcdPLKmqxxMyF5q6MYyPZGciRHu8zrz0sJTTsskeRaYnt0 3J+hU3Km1YiaVeJsTLAdzwicWktbfKDEMewLJaxVqw== X-Google-Smtp-Source: AGs4zMZPeg02FgSXNOxpS/Xjv1D0/aaLL7WZTMSg1+z2N25k6LOmy+FyTWTrRjJLTrh+jl3/wKZQ1ZoEmf12i2GJVp0= X-Received: by 10.107.9.223 with SMTP id 92mr28660694ioj.16.1512494029551; Tue, 05 Dec 2017 09:13:49 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Dec 2017 09:13:48 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 5 Dec 2017 09:13:48 -0800 Message-ID: Subject: Simplify ACK frame retransmission To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113eca345b3c2d055f9af5bc" 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, 05 Dec 2017 17:13:52 -0000 --001a113eca345b3c2d055f9af5bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is the value in retransmitting ACK frames as opposed to either just A) periodically send ACK frames. or B) realize an ACK frame was lost and send ACK frames earlier than otherwise planned. or C) keep the span of the ACK frame for retransmission, but not any gap details. I define a span to be the min..max range of all packet numbers in an ACK frame including gaps. There is a lot of bookkeeping in tracking the exact ACK frame content which does not at all seem very useful. If more detail is needed beyond sending the current ACK state it would also be possible and practical to store the min and max packet number in a transmitted ACK frame such that if it is later considered lost, a new ACK frame can be send which will attempt to cover that range while prioritising most recent in case of space limitations. An implementation could be free to choose between option A, B, or C. This is sort af analogous to not retransmitting MAX values but rather sending updated information in case of loss. It is also not fully clarified if multiple ACK frames can exist in a packet with different or overlapping spans. I could open an issue, but there are so many different ACK frame issues that I thought it better to take it on the list, at least initially. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a113eca345b3c2d055f9af5bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = What is the value in= retransmitting ACK frames as opposed to either just

A) periodically send ACK frames.
or
B) realize an ACK frame was lost = and send ACK frames earlier than otherwise planned.
or
C) keep the span of the ACK frame for retransm= ission, but not any gap details.

I define a span to be the min..max range of all packet numbers = in an ACK frame including gaps.

There is a lot of bookkeeping in tracking the exact ACK frame co= ntent which does not at all seem very useful.
If more detail is needed beyond sending th= e current ACK state it would also be possible and practical to store the mi= n and max packet number in a transmitted ACK frame such that if it is later= considered lost, a new ACK frame can be send which will attempt to cover t= hat range while prioritising most recent in case of space limitations.

An implementation could b= e free to choose between option A, B, or C. This is sort af analogous to no= t retransmitting MAX values but rather sending updated information in case = of loss.

=
It is also n= ot fully clarified if multiple ACK frames can exist in a packet with differ= ent or overlapping spans.

I could open an issue, but th= ere are so many different ACK frame issues that I thought it better to take= it on the list, at least initially.

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

--001a113eca345b3c2d055f9af5bc-- From nobody Tue Dec 5 10:22: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 8529E12946F for ; Tue, 5 Dec 2017 10:22: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, 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=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 DgvJ7OE6gxUf for ; Tue, 5 Dec 2017 10:22:43 -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 B0E4112956C for ; Tue, 5 Dec 2017 10:22:43 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id m81so519388ywd.2 for ; Tue, 05 Dec 2017 10:22:43 -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=zy/SadZIbAPWlzo5lIkgBgil+dyYrXFyf5MiC+Wb+7U=; b=YUX5czYyC2p49jwUJ6GFIlwmJjHlwjpmG2sChqp3gKknu3wMYMUaskc00b3ou3rorG CgVicH8WvTptjuL4M2R/wEIh28b/KJANyCO56ZDbyC1vd/49E05MoT15rnU3ld+iRCzM mi9pp5GGXYPzZJluYmZ/YPeyXxYyYXpDgXjnJAWXAPggEKh0Z480GTqf4NLwrRJwMwSL 5eu7xClphyu3eYH5C4lxu27QheAQbXMhfjhIcVPT7mHHBzOjV/v9cYmWHLHZDkUi2YVN Ry0Iv+Rie5f9/n+SaA06EcdCN56XCBryWFoq7YVuOLgrQomMqhcY5NNgk6i7+IGP/Y0u mQ2w== 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=zy/SadZIbAPWlzo5lIkgBgil+dyYrXFyf5MiC+Wb+7U=; b=aooNyE7oudkYuXH+BPQCwH59vEbjrXscSuLebDUgjKlIvcz/twYn4IHZA/1Fp39XpH 6xhQ1LDMmWNCY4ZRRj3prhQMPqkOTsMNe0cs0nqEjZEEX58HQA9Hzz9mQRCKSc3CEvmi FsjLjyUwzsXvA/uTdgS5eH4GHBieVhAZM4+zZPlnkmw2prFTs5Jhz63aDIqfYg68VDeM D5KswmzsVWoaKzTjUI4ItUk2Y9nq/MoDZsD1ASiMdkLv0BCbZWuhYp9uRc04sN0PVBgE 8fEKK7opBEaZ3+AnNw7EoMJOsbzl41CZLYEze2eDkipvp7l1REmbUym/SA1TQpzKrref B0hg== X-Gm-Message-State: AJaThX7G6kq7o7JamsURt9wbgSGa80MWryTymliVroHrIz/2ayxjPXog c1ljcH6OfgaEmEdKHWnhwiEgxfeK6gmY3St/uRaKJg== X-Google-Smtp-Source: AGs4zMb2ANVHyLMsto3hPkpLPGiAnibgwUS2Q70Ko6HV83auqgOLbbUQAkztqkiilFkTh44iLgkM5X/HtGGaNFTxNuA= X-Received: by 10.129.82.79 with SMTP id g76mr13747196ywb.94.1512498162414; Tue, 05 Dec 2017 10:22:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Tue, 5 Dec 2017 10:22:41 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 5 Dec 2017 10:22:41 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114dac02b2bdd4055f9beb95" 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, 05 Dec 2017 18:22:47 -0000 --001a114dac02b2bdd4055f9beb95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mikkel, ACK frames are not retransmitted, see Section 9 of the transport draft. ACK frames are sent in response to received frames that elicit one, but no more. Not all frames elicit acks, as specified in Section 9. In general, tracking ACK loss is difficult, since ACKs don't elicit ACKs from the peer... so doing things based on ACK loss detection tends to be difficult. - jana On Tue, Dec 5, 2017 at 9:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > What is the value in retransmitting ACK frames as opposed to either just > > A) periodically send ACK frames. > or > B) realize an ACK frame was lost and send ACK frames earlier than > otherwise planned. > or > C) keep the span of the ACK frame for retransmission, but not any gap > details. > > I define a span to be the min..max range of all packet numbers in an ACK > frame including gaps. > > There is a lot of bookkeeping in tracking the exact ACK frame content > which does not at all seem very useful. > If more detail is needed beyond sending the current ACK state it would > also be possible and practical to store the min and max packet number in = a > transmitted ACK frame such that if it is later considered lost, a new ACK > frame can be send which will attempt to cover that range while prioritisi= ng > most recent in case of space limitations. > > An implementation could be free to choose between option A, B, or C. This > is sort af analogous to not retransmitting MAX values but rather sending > updated information in case of loss. > > It is also not fully clarified if multiple ACK frames can exist in a > packet with different or overlapping spans. > > I could open an issue, but there are so many different ACK frame issues > that I thought it better to take it on the list, at least initially. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --001a114dac02b2bdd4055f9beb95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mikkel,

ACK frames are not retransmi= tted, see Section 9=C2=A0of the tra= nsport draft. ACK frames are sent in response to received frames that elici= t one, but no more. Not all frames elicit acks, as specified in Section 9.<= /div>
In general, tracking ACK loss is difficult, since ACKs don't = elicit ACKs from the peer... so doing things based on ACK loss detection te= nds to be difficult.

- jana

On Tue, Dec 5, 2017 at 9= :13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
What is the value in retransmitting = ACK frames as opposed to either just

A) periodically= send ACK frames.
or
B) realize an ACK frame was lost and= send ACK frames earlier than otherwise planned.
or
C) = keep the span of the ACK frame for retransmission, but not any gap details.=

I define a span to be the min..max range of all pac= ket numbers in an ACK frame including gaps.

There is= a lot of bookkeeping in tracking the exact ACK frame content which does no= t at all seem very useful.
If more detail is needed beyond sending= the current ACK state it would also be possible and practical to store the= min and max packet number in a transmitted ACK frame such that if it is la= ter considered lost, a new ACK frame can be send which will attempt to cove= r that range while prioritising most recent in case of space limitations.

An implementation could be free to choose between op= tion A, B, or C. This is sort af analogous to not retransmitting MAX values= but rather sending updated information in case of loss.

It is also not fully clarified if multiple ACK frames can exist in a p= acket with different or overlapping spans.

I could open= an issue, but there are so many different ACK frame issues that I thought = it better to take it on the list, at least initially.

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


--001a114dac02b2bdd4055f9beb95-- From nobody Tue Dec 5 11:13: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 5D7721270A3 for ; Tue, 5 Dec 2017 11:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhxf7wIgi9vs for ; Tue, 5 Dec 2017 11:13:17 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4276F1243FE for ; Tue, 5 Dec 2017 11:13:17 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id o130so18072371itg.0 for ; Tue, 05 Dec 2017 11:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uMi47QJkOgBhYblhQvET8zv1VTfWZTvm+co+I5O258M=; b=u1nxQJKWzKKLscr/XkiQMaaf+SmObljU00X6W3juxdXL2ycXvsEQ5hv9Pmc+fKEdED Ue3J0xQQHkX04Wc/vNc1rwsacP3cJyrw+xZsYGA2cFibQEoWHCJTyIlbbalk6DlGNagR QWU+QT437mbuH6JcSQUdRNzJ1pAH91kH7/tYjUsgnjiT41dHkBU/LV2XA3wg+b7g635K Ae3H9QAn9Fqg/ZOwX40/dByZ3ealWtWYWiN0pfiNgs57gd8QbueRSdkU3WzeE2yfAVc7 eemifT+4fmJmO5Ghfqic90egAunCMVV8hRTW1wjL2YRSgLM71JN0Z7Y2gVz+71llrq0L vk9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uMi47QJkOgBhYblhQvET8zv1VTfWZTvm+co+I5O258M=; b=Nmn5muzeWxJJYlIQI7z9hwfXXuaiDNvXhQxHLwrLj1ph5bSu4kT+dib1z+X8S70a46 hUJQ2tFy+DQvOSg5iy/pMJlrNxpbtD6HbVjzjtDKqqSG5SevjIpXKHyOECZFEhmRycdv NC2t37EulT3aJZ7nS5pxJEyXea3KWOe/8qgWhnJX7AjoGDZRvsXxCusckKZUaa0Dsy6d fYc+zdye38FitQ5qRlOLPmBbpxZxZTJVSZxRYNL39cbR0RQJUlnl4uCRE9+BoUqkvDAh HrYMk7RtwqXXe2tYDmG7jWbNDNZ700KiJXJ/iW3tpD+wK91+QPOWRSYcFYvdm/TsakzU XieQ== X-Gm-Message-State: AKGB3mKKbZlKtA85b+eyYt1Te7HAvBh/79IFaWRnmt6RXJzb/ar9VAIJ bm5gH6FTTpets40ex+IHiCH1Wl2adBZ84+SDtcws+Q== X-Google-Smtp-Source: AGs4zMY+9GoSdhB1/wSM5CHY2AQRXasas8IQ585sEkzQQ6uLZCrxiK6u7QdQrWR52iLdFd6aVJ4+LbkNd53gx8pxg98= X-Received: by 10.36.95.14 with SMTP id r14mr18732781itb.42.1512501196336; Tue, 05 Dec 2017 11:13:16 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Dec 2017 11:13:15 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 5 Dec 2017 11:13:15 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: Jana Iyengar Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1144b57a87b866055f9ca074" 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, 05 Dec 2017 19:13:19 -0000 --001a1144b57a87b866055f9ca074 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oh great thanks, I have missed this change (in both senses). Many things have happened since I last had time to put some serious effort into QUIC. Now most of my major concerns have been addressed: - ack transmission is reasonably friendly (no timestamp bookkeeping, no retransmission bookkeeping) (but still difficult to understand text for ACK frame) - not sure about dropping the float16 format, but it was hard to document. - client ID is maintained throughout handshake and optional server ID is, or will be, known by separate field (TLS params) - protection against off-path clear text attacks. - non-unique 5-tuples are possible without loosing connection state - simplifying server to server with raw socket like interfaces and avoiding ephemeral port exhausting. - much simpler stream state diagram (no dual purpose RST stream, no ACK needed before transition). - 0 padding is random on wire via clear text AEAD. - initial packet has a well-defined 1200 byte length for all networks. - bad packets are ignored rather than causing errors during early handshake (at least in some cases) - prevents off-path DoS. - Stream ID is has sufficient range - allows for throw away streams needed for partial reliability and for game server state updates. - frame header encoding with varints rather than obscure frame type bits. - uni-directional streams that can close without peer response (although still with bidi complexity). - no random packet number jumps except at new connection ID allowing for compact data structures (but I think the random 32-bit gap at migration might be used to exhaust the packet number space prematurely, but you can just limit the number of acceptable migrations). - single frame async messages are now possibly, indirectly, via Ping or uni-streams. I really would like a QUIC version that only depends on AES, curve25519 (and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoid heavy TLS libraries, but this is still possible with a custom QUIC version. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 5 December 2017 at 19.22.43, Jana Iyengar (jri@google.com) wrote: Hi Mikkel, ACK frames are not retransmitted, see Section 9 of the transport draft. ACK frames are sent in response to received frames that elicit one, but no more. Not all frames elicit acks, as specified in Section 9. In general, tracking ACK loss is difficult, since ACKs don't elicit ACKs from the peer... so doing things based on ACK loss detection tends to be difficult. - jana On Tue, Dec 5, 2017 at 9:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > What is the value in retransmitting ACK frames as opposed to either just > > A) periodically send ACK frames. > or > B) realize an ACK frame was lost and send ACK frames earlier than > otherwise planned. > or > C) keep the span of the ACK frame for retransmission, but not any gap > details. > > I define a span to be the min..max range of all packet numbers in an ACK > frame including gaps. > > There is a lot of bookkeeping in tracking the exact ACK frame content > which does not at all seem very useful. > If more detail is needed beyond sending the current ACK state it would > also be possible and practical to store the min and max packet number in = a > transmitted ACK frame such that if it is later considered lost, a new ACK > frame can be send which will attempt to cover that range while prioritisi= ng > most recent in case of space limitations. > > An implementation could be free to choose between option A, B, or C. This > is sort af analogous to not retransmitting MAX values but rather sending > updated information in case of loss. > > It is also not fully clarified if multiple ACK frames can exist in a > packet with different or overlapping spans. > > I could open an issue, but there are so many different ACK frame issues > that I thought it better to take it on the list, at least initially. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --001a1144b57a87b866055f9ca074 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Oh great thanks,

I have missed this chang= e (in both senses).

M= any things have happened since I last had time to put some serious effort i= nto QUIC.
Now most of= my major concerns have been addressed:

- ack transmission is reasonably friendly (no timestamp = bookkeeping, no retransmission bookkeeping) (but still difficult to underst= and text for ACK frame) - not sure about dropping the float16 format, but i= t was hard to document.
- client ID is maintained throughout handshake and optional serv= er ID is, or will be, known by separate field (TLS params)
- protection against off-path= clear text attacks.
- non-unique 5-tuples are possible without loosing connection = state - simplifying server to server with raw socket like interfaces and av= oiding ephemeral port exhausting.
- much simpler stream state dia= gram (no dual purpose RST stream, no ACK needed before transition).
- 0 padding is= random on wire via clear text AEAD.
- initial packet has a well-defined 1200 byte lengt= h for all networks.
- bad packets are ignored rather than causing errors during early ha= ndshake (at least in some cases) - prevents off-path DoS.
- Stream ID is has sufficient = range - allows for throw away streams needed for partial reliability and fo= r game server state updates.
- frame header encoding with varints rather than obscure fr= ame type bits.
- uni-directional streams that can close without peer = response (although still with bidi complexity).
- no random packet numb= er jumps except at new connection ID allowing for compact data structures (= but I think the random 32-bit gap at migration might be used to exhaust the= packet number space prematurely, but you can just limit the number of acce= ptable migrations).
- single frame async messages are now possibl= y, indirectly, via Ping or uni-streams.

I really w= ould like a QUIC version that only depends on AES, curve25519 (and/or possi= bly salsa/poly) and ed25519 OpenSSH keys and certs to avoid heavy TLS libra= ries, but this is still possible with a custom QUIC version.

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


On 5 De= cember 2017 at 19.22.43, Jana Iyengar (jr= i@google.com) wrote:

<= span>
Hi Mikkel,

ACK frames are not retransmitted, see Section 9=C2=A0of the transport draft. ACK frames are sent in response to received frames that elicit one, but no more. Not all frames elicit acks, as specified in Section 9.
In general, tracking ACK loss is difficult, since ACKs don't elicit ACKs from the peer... so doing things based on ACK loss detection tends to be difficult.

- jana

On Tue, Dec 5, 2017 at 9:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
What is the value in retransmitting ACK frames as opposed to either just

A) periodically send ACK frames.
or
B) realize an ACK frame was lost and send ACK frames earlier than otherwise planned.
or
C) keep the span of the ACK frame for retransmission, but not any gap details.

I define a span to be the min..max range of all packet numbers in an ACK frame including gaps.

There is a lot of bookkeeping in tracking the exact ACK frame content which does not at all seem very useful.
If more detail is needed beyond sending the current ACK state it would also be possible and practical to store the min and max packet number in a transmitted ACK frame such that if it is later considered lost, a new ACK frame can be send which will attempt to cover that range while prioritising most recent in case of space limitations.

An implementation could be free to choose between option A, B, or C. This is sort af analogous to not retransmitting MAX values but rather sending updated information in case of loss.

It is also not fully clarified if multiple ACK frames can exist in a packet with different or overlapping spans.

I could open an issue, but there are so many different ACK frame issues that I thought it better to take it on the list, at least initially.

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


--001a1144b57a87b866055f9ca074-- From nobody Tue Dec 5 13:19: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 8134A1267BB for ; Tue, 5 Dec 2017 13:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgElK9C9rfPd for ; Tue, 5 Dec 2017 13:19:47 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 43A1412711A for ; Tue, 5 Dec 2017 13:19:47 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id h1so1759782wre.12 for ; Tue, 05 Dec 2017 13:19: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=ppbp4HDslbrI8u4MzMwjCmkJfr2eXHl797zPIJhtjy8=; b=lrMt1wYLydxgVOD/wajuYPwFHlq3he0AP3JCogUNvwYUD/4Xt1XF5ukoT8CyIDzub+ MUOr4wmgNzUAfG1YkiHRM32RNdKyrO8EbzytbH9tz+UH7gwQtmWiMBAWYArvaHccZCxz 94UVqHLYJIc18dPvYSFtk8QCZCxzQi+Stx96AAS2/C2a9/LmkL6XSBj3XSWWPkvEKkNi ajnXn26Sd9psUYjRYxsQuvQbSETX6+oEi8OHwSuBDaLDCVjuUCZHKTEN7HUVdeX/PmTR FpEfeWxzGap7axzD2a2TxxjO9Zfrmb7xCV7NKs4Mr8FZhRV8NvD/wL1Tq0uMYAW7ZgTu WvsA== 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=ppbp4HDslbrI8u4MzMwjCmkJfr2eXHl797zPIJhtjy8=; b=tgCAONzJc3FILSdVbj10OvBwM7HFzE/EHp/RHvgTyI/+C5Pj/HXts+ongKCrTxQM9B TxXvmTu+YcOWn6fEGomRhf9iSIFQLDnEcKb/tSA2vd5gDPIQReI1zYcmiIEfNxcxnlPo 3CQ3hW0zh5ac90UDw9C7Pl+XfBJaPmOBYikgyhaNGKhhYyNKtiUxP5xZZVYpOrF7MlhJ GS0PgVeJfKI/Ao8ZYC3NTOMYmfpJGYtTztTOwFz8G3lbiKgOxpzDcc0GlBhvJhaTpd3m iXmI6tyvgQgAsm021D+NTZ+NL4xRk2j9KsSR5tlQYXJTmQOsJToOaW6F759uSvbJgAsb 9vOA== X-Gm-Message-State: AJaThX6uXlHXVsfCEJVXCsOaC5cqv8vTK1QpTTosfIs2/84hGaHNx/lr 97uLk8my3pfG1Hs/s6zW94yJgGn7mbLPfqtKM1w= X-Google-Smtp-Source: AGs4zMa2bsD708Fk9kSOsIFQd3ty61oJQnlzVKMOBUzzl06Ro+is67+yI9UxYbGiYM15GzZMecsuD6SiugKl4Uf2dQQ= X-Received: by 10.223.158.203 with SMTP id b11mr16903417wrf.256.1512508785697; Tue, 05 Dec 2017 13:19:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.3 with HTTP; Tue, 5 Dec 2017 13:19:45 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Tue, 5 Dec 2017 13:19:45 -0800 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Eric Rescorla Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0820c404e4288d055f9e6475" 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, 05 Dec 2017 21:19:49 -0000 --089e0820c404e4288d055f9e6475 Content-Type: text/plain; charset="UTF-8" Isn't timeout-based loss recovery something that goes all the way back to the 1st implementation draft? On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla wrote: > It is done. > > -Ekr > > > On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett wrote: > >> Possibly this is part of "Update to draft-08", but I'd like to explicitly >> state we're moving to TLS 1.3 draft 22. >> >> On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: >> >>> Here's my first cut: >>> https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft >>> >> >> > --089e0820c404e4288d055f9e6475 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Isn't timeout-based loss recovery something that goes = all the way back to the 1st implementation draft?

On Mon, Dec 4, 2017 at 5:59 PM, Eric = Rescorla <ekr@rtfm.com> wrote:
=
It is done.

-Ekr


=
On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett <ia= nswett@google.com> wrote:
<= div dir=3D"ltr">Possibly this is part of "Update to draft-08", bu= t I'd like to explicitly state we're moving to TLS 1.3 draft 22.

On Mon,= Dec 4, 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">



--089e0820c404e4288d055f9e6475-- From nobody Tue Dec 5 13:23: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 3286F12711A for ; Tue, 5 Dec 2017 13:23:50 -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 Tp6tLaO5v-ji for ; Tue, 5 Dec 2017 13:23:48 -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 358721267BB for ; Tue, 5 Dec 2017 13:23:48 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id v190so744204ywg.4 for ; Tue, 05 Dec 2017 13:23: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=/9axP2KmyqKOuV7VcGoWsBlDeJYrmoHZmDIeNoVYDto=; b=USqAQMPf9wRMskwkW125nC1qYIVkToMeUWefWVrJ+0XLBDdQC8wzkd7mf6GKYjw8KI O2viONSv4B7AnTsmlmLaAUrpVW2jhNl3ADf7LIo6qWqlhf8zCKgPtfbiiQRY9eBLee1V XEV81E1Sx26T2mcS33jI9/6QybEXkg7l6W+Wrork0oJ3U1vpQQY1CNiGxI8siayfLR3A Mxhivb8OEBngHSXTEhFTETe2SsPHH61gZIx0sw8PDa/YZu9ezJsqzGt5XAxJspwCwSgg qIvT39y79fYr3xWJ9cR89c8HxDG9AkgThttKNAflf+sxKcUAgDrvz7Wp39pxnNjOEHKz u0Ow== 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=/9axP2KmyqKOuV7VcGoWsBlDeJYrmoHZmDIeNoVYDto=; b=tdmKDGswALgB9a5lo8xZ2FTXaBcjCnsRapPw4DTiD8MTl9TT0s+kyxiJPcnTm1nMlL e/nAuC8YIstGuCcz03qf/8uJCAvv8xzGCYZpC66bxLV7pbOuGavt/8CuUyLK8UcZd7eK 8FBvlnxNhGhrp+L4utNYwJTJsJe838w7QqDS2XE+REGT+VlcZzYP3IN4ziTg03LHkpPB BaIDVWhvRwzyVoxNEf54AMBmSWeV0OBrkzyOuvAsOCqeJRtbT4i9QS1mKCCZ45xnC/CB AB/BS6z9Vf+QkWOeyAxcZoLIiBet7asw9FvOYUZTKuNVhtkx1LjJA9iSKh0qyC8JB9/7 WhOg== X-Gm-Message-State: AJaThX6Bf6f1wuG1x1YgjLI9RyJb2EuxK7Oi3aQq/9nrCyUmu2chRjKc ohAIxhyPxKmA7N1q3YXhLEvDYzuj/wLgIKrGl82DOg== X-Google-Smtp-Source: AGs4zMZp9+0WrZt8bD/InVHoO6TqEsWKmouxA30swM0EotUOvfCe+nzZ+lpfYHAsAa+p9vohBxltbjPBa3N0nbl2yk0= X-Received: by 10.129.154.22 with SMTP id r22mr14033106ywg.296.1512509027454; Tue, 05 Dec 2017 13:23:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 5 Dec 2017 13:23:06 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 5 Dec 2017 13:23:06 -0800 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Martin Duke Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0bb4e84d29a5055f9e7325" 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, 05 Dec 2017 21:23:50 -0000 --94eb2c0bb4e84d29a5055f9e7325 Content-Type: text/plain; charset="UTF-8" Yes. This is actually demonstrating that it works :) I am trying to be responsive to the request for clear test cases. -Ekr On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke wrote: > Isn't timeout-based loss recovery something that goes all the way back to > the 1st implementation draft? > > On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla wrote: > >> It is done. >> >> -Ekr >> >> >> On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett wrote: >> >>> Possibly this is part of "Update to draft-08", but I'd like to >>> explicitly state we're moving to TLS 1.3 draft 22. >>> >>> On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: >>> >>>> Here's my first cut: >>>> https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft >>>> >>> >>> >> > --94eb2c0bb4e84d29a5055f9e7325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. This is actually demonstrating that it works :) I am = trying to be responsive to the request for clear test cases.

=
-Ekr


On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke <martin.h.duke@gm= ail.com> wrote:
Isn't timeout-based loss recovery something that goes all the way= back to the 1st implementation draft?

On Mon, = Dec 4, 2017 at 5:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:
It is done.

-Ekr


On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett <iansw= ett@google.com> wrote:
Possibly this is part of "Update to draft-08", but I= 'd like to explicitly state we're moving to TLS 1.3 draft 22.
=

On Mon, Dec 4, 2017 at 8:28 PM, Eric Resco= rla <ekr@rtfm.com> wrote:




--94eb2c0bb4e84d29a5055f9e7325-- From nobody Tue Dec 5 13: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 7F55212773A for ; Tue, 5 Dec 2017 13:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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.8, 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 3o3YzMdg1BKG for ; Tue, 5 Dec 2017 13:33:36 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0130.outbound.protection.outlook.com [104.47.38.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 9504A1267BB for ; Tue, 5 Dec 2017 13:33:36 -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=hGVEBHuSQ0jf5eEcsoWNDJOp3dqwBixNKNWCm/aIinM=; b=ByCT7f03RRxu3HYIxyJRgxv3gC5p29EYnlFjfKTqbFlMVQwJfdXladPQ92eUgVIM2tEAQPdMeXt1CddCl3ETrtXSRrdPir9cVzdoSCKGjTIqaUdi1uPo0p6GJ8aGhPzOB/Z51gBODira06vybZ3AnicpW/RQgZT9QlPIPjOfljs= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.1; Tue, 5 Dec 2017 21:33:33 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0323.001; Tue, 5 Dec 2017 21:33:33 +0000 From: Praveen Balasubramanian To: Eric Rescorla , Martin Duke CC: Ian Swett , IETF QUIC WG Subject: RE: Third Implementation Draft Prototype Thread-Topic: Third Implementation Draft Prototype Thread-Index: AQHTbWh1xD9h+qm1akyyhLuydU10kKMz+iwAgAAEUgCAAUQ8gIAAAPAAgAACT5A= Date: Tue, 5 Dec 2017 21:33:32 +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: [2001:4898:80e8:f::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0774; 6:l0S/U3IVICSFf3zjjpnBQykQlhvbwKaPwOMtgHcHQ/zdyGPsbBGBLyRsXvz0aoz+vFdOY0cL33Kz7Nht3ZnRdZj2VQoljQhK0ITRiqK17sYdaudIh6ZtA4dgWVNJ6Yf5nQE1PCW1SHXgMi2rxCI6WliRcJazZca5LzOtThBo2NLhqTBh/sYhwVJQof95VHUwI22cA7da80jX0Djl+IK2V6G+nJRx1e2Ppd2Ga/aZG4TubpcLR4rxJhYkj4l1jgoPhRaP+Ntv00g6FH/6LWxBoARAsJcmcQqimqR+oTwCmSojStWqwU+mzFV5Z1WFKF1z2EHJOCQwbc0wJoyEMLRFQ27y9F557uBO2gJtjZIxWVU=; 5:iP7SrJ33NiFcmoo41kyjwQ0qIuKN33f+DzmM4qD5j/DGsDhV3wfRbCOLcCMoe2qBLJ9oaqn02oT+dEMhoylOMUCm8tYsfj3A2wYzqqVnvoUfCo5VMewDuZ8rLsndMziiE4r63eOJq41lkxJQssgJ96S0IGB276rQYIgawnS4yr8=; 24:mc6Cur8tdp4ilu1cVbgLWORb1A6MKveapH8CGkt6k6Vgud/vjjTxs9QjigmI6Vakuplaj0Ywx5Az31lFhZ5oWZjhz7wavADdI332N63/MhU=; 7:WAMaIV6RPoIPzLUikqxeHcHkPy1L9Lpod9RXAu2/4To47hhl5pxr+ipJt3GmcW74M9jgQw2TSZBxlzrjOd0He4N4S2UkdXAYSLVXUS8NZyZaeVMFauFVno2HqoiWjZelWD8ejoaP3g1sWfdJ16j5CMgn8cF+uTFqPnADu7KmN3/bvRxxhd+YqAX4QjC1PLa/uIWmg2dTYfFbginzk5BpQLZU/YG+ObA6cE1EVCLtEuz4yfylF+AaDDxzr8zRQN2H x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fa972601-7672-442b-f02e-08d53c27d624 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:CY4PR21MB0774; x-ms-traffictypediagnostic: CY4PR21MB0774: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(920507027)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:CY4PR21MB0774; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0774; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(366004)(47760400005)(24454002)(199004)(189003)(25786009)(5660300001)(33656002)(106356001)(6506006)(7696005)(229853002)(790700001)(606006)(54906003)(53546010)(102836003)(316002)(81156014)(97736004)(74316002)(34040400001)(110136005)(8676002)(22452003)(99286004)(7736002)(76176011)(6116002)(105586002)(8990500004)(10290500003)(8936002)(2900100001)(10090500001)(93886005)(3480700004)(2906002)(3280700002)(236005)(81166006)(3660700001)(6436002)(14454004)(966005)(478600001)(68736007)(54896002)(6306002)(55016002)(9686003)(77096006)(19609705001)(2950100002)(39060400002)(86612001)(53936002)(6246003)(4326008)(101416001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0774; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01333310A186E4AE79CD7BC4B63D0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa972601-7672-442b-f02e-08d53c27d624 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 21:33:33.5523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0774 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, 05 Dec 2017 21:33:39 -0000 --_000_CY4PR21MB01333310A186E4AE79CD7BC4B63D0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFyZSB3ZSBnb2luZyB0byBleGVyY2lzZSB0aGUg4oCccmFuZG9tIDEwJSBsb3Nz4oCdIHRl c3QgY2FzZSBnaXZlbiB0aGlzIGlzIGFsbCByZW1vdGUgcGFydGljaXBhdGlvbj8NCg0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVz Y29ybGENClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDUsIDIwMTcgMToyMyBQTQ0KVG86IE1hcnRp biBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4NCkNjOiBJYW4gU3dldHQgPGlhbnN3ZXR0 QGdvb2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog VGhpcmQgSW1wbGVtZW50YXRpb24gRHJhZnQgUHJvdG90eXBlDQoNClllcy4gVGhpcyBpcyBhY3R1 YWxseSBkZW1vbnN0cmF0aW5nIHRoYXQgaXQgd29ya3MgOikgSSBhbSB0cnlpbmcgdG8gYmUgcmVz cG9uc2l2ZSB0byB0aGUgcmVxdWVzdCBmb3IgY2xlYXIgdGVzdCBjYXNlcy4NCg0KLUVrcg0KDQoN Ck9uIFR1ZSwgRGVjIDUsIDIwMTcgYXQgMToxOSBQTSwgTWFydGluIER1a2UgPG1hcnRpbi5oLmR1 a2VAZ21haWwuY29tPG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4+IHdyb3RlOg0KSXNu J3QgdGltZW91dC1iYXNlZCBsb3NzIHJlY292ZXJ5IHNvbWV0aGluZyB0aGF0IGdvZXMgYWxsIHRo ZSB3YXkgYmFjayB0byB0aGUgMXN0IGltcGxlbWVudGF0aW9uIGRyYWZ0Pw0KDQpPbiBNb24sIERl YyA0LCAyMDE3IGF0IDU6NTkgUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86 ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpJdCBpcyBkb25lLg0KDQotRWtyDQoNCg0KT24gTW9uLCBE ZWMgNCwgMjAxNyBhdCA1OjQzIFBNLCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFp bHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3cm90ZToNClBvc3NpYmx5IHRoaXMgaXMgcGFydCBv ZiAiVXBkYXRlIHRvIGRyYWZ0LTA4IiwgYnV0IEknZCBsaWtlIHRvIGV4cGxpY2l0bHkgc3RhdGUg d2UncmUgbW92aW5nIHRvIFRMUyAxLjMgZHJhZnQgMjIuDQoNCk9uIE1vbiwgRGVjIDQsIDIwMTcg YXQgODoyOCBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5j b20+PiB3cm90ZToNCkhlcmUncyBteSBmaXJzdCBjdXQ6DQpodHRwczovL2dpdGh1Yi5jb20vcXVp Y3dnL2Jhc2UtZHJhZnRzL3dpa2kvVGhpcmQtSW1wbGVtZW50YXRpb24tRHJhZnQ8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZn aXRodWIuY29tJTJGcXVpY3dnJTJGYmFzZS1kcmFmdHMlMkZ3aWtpJTJGVGhpcmQtSW1wbGVtZW50 YXRpb24tRHJhZnQmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNGRlY2Yw Mzc3NmEwNDAyY2NkYjEwOGQ1M2MyNjdkMDglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2NDgxMDU4MzYwODcyMzIyJnNkYXRhPUpuY0pDclU1WFRFQ1R4M1Aw dVNqMkxvQkpvZ214QlphTEdFeHpaY2VXcW8lM0QmcmVzZXJ2ZWQ9MD4NCg0KDQoNCg0K --_000_CY4PR21MB01333310A186E4AE79CD7BC4B63D0CY4PR21MB0133namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I b3cgYXJlIHdlIGdvaW5nIHRvIGV4ZXJjaXNlIHRoZSDigJxyYW5kb20gMTAlIGxvc3PigJ0gdGVz dCBjYXNlIGdpdmVuIHRoaXMgaXMgYWxsIHJlbW90ZSBwYXJ0aWNpcGF0aW9uPw0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIERlY2VtYmVyIDUsIDIwMTcgMToyMyBQTTxicj4NCjxiPlRvOjwvYj4gTWFy dGluIER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g SWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtx dWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVGhpcmQgSW1wbGVtZW50 YXRpb24gRHJhZnQgUHJvdG90eXBlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMu IFRoaXMgaXMgYWN0dWFsbHkgZGVtb25zdHJhdGluZyB0aGF0IGl0IHdvcmtzIDopIEkgYW0gdHJ5 aW5nIHRvIGJlIHJlc3BvbnNpdmUgdG8gdGhlIHJlcXVlc3QgZm9yIGNsZWFyIHRlc3QgY2FzZXMu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyA1LCAyMDE3IGF0 IDE6MTkgUE0sIE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLmguZHVrZUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Jc24ndCB0aW1lb3V0LWJhc2VkIGxvc3MgcmVjb3Zlcnkgc29tZXRoaW5nIHRoYXQg Z29lcyBhbGwgdGhlIHdheSBiYWNrIHRvIHRoZSAxc3QgaW1wbGVtZW50YXRpb24gZHJhZnQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNTo1OSBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdCBpcyBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBEZWMgNCwgMjAxNyBhdCA1OjQz IFBNLCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qb3NzaWJs eSB0aGlzIGlzIHBhcnQgb2YgJnF1b3Q7VXBkYXRlIHRvIGRyYWZ0LTA4JnF1b3Q7LCBidXQgSSdk IGxpa2UgdG8gZXhwbGljaXRseSBzdGF0ZSB3ZSdyZSBtb3ZpbmcgdG8gVExTIDEuMyBkcmFmdCAy Mi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBEZWMgNCwgMjAxNyBhdCA4OjI4IFBNLCBFcmljIFJlc2NvcmxhICZsdDs8 YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhlcmUncyBteSBmaXJzdCBjdXQ6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGcXVp Y3dnJTJGYmFzZS1kcmFmdHMlMkZ3aWtpJTJGVGhpcmQtSW1wbGVtZW50YXRpb24tRHJhZnQmYW1w O2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzRkZWNmMDM3NzZhMDQwMmNj ZGIxMDhkNTNjMjY3ZDA4JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNjQ4MTA1ODM2MDg3MjMyMiZhbXA7c2RhdGE9Sm5jSkNyVTVYVEVDVHgzUDB1U2oyTG9C Sm9nbXhCWmFMR0V4elpjZVdxbyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9UaGlyZC1JbXBsZW1lbnRh dGlvbi1EcmFmdDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB01333310A186E4AE79CD7BC4B63D0CY4PR21MB0133namp_-- From nobody Tue Dec 5 13:38: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 1422A128799 for ; Tue, 5 Dec 2017 13:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 Hem_-t_lpy_u for ; Tue, 5 Dec 2017 13:38:07 -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 1B9ED128792 for ; Tue, 5 Dec 2017 13:38:07 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id 184so754482ybw.12 for ; Tue, 05 Dec 2017 13:38:07 -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=LXqx1vPVY59XrnGZtuW7DNi0vEd6vhKZQbSXpV0yoLw=; b=kVhnkj0XX/SqXTD0+RcJbLNUc8NrsdUPxrI8sN12CVF58FHd2q/1c63D76U/ylGhXI HYXScQdurBPJI5t4s4oxbQCqbyyJ3bx/iBzG9RPtm4slrtJrxYIY0rG/pguvaB2JpIok TI9mUQxc/qczHKxvjdXOeOPSHzDm4gix8zJ8DaVgnYkSmTcEJ43mI77lmEk31lA5iT18 Ao/ib9wMJ+Xud5pT5j/3tCdgnREReP8i4CH4xJ772ndngcmkZGteCKZOwNCVrmjL0lIC hkkEPUnahp/YAxMyhPvaPDEwPiKnaGK8T9mWVL+zaUseDlzBTdPVSVj2xblEqGSe8z7B KoNQ== 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=LXqx1vPVY59XrnGZtuW7DNi0vEd6vhKZQbSXpV0yoLw=; b=lsVqS/YXsCirEO2Tiu8CIcmkk8WE3j/bHpVkKlwyAj7zo94REhgI6Q2O9L6386JVaO Qm7qHGTq3CtuQ/0Nse4v4+yWtIL2hthpOg8Tl3pQ2tCFx9dJF+pW6idRJ8O1FYGnICU/ 3wG31GS67IFHaclIbF7UihcDGc+rO3uF4pFslr7s9Vx50DCwUZ+Pu75zjbv7JxhedACE jsAamXpJTQlBkNTXHCW2J5W5ez+D5sTgT3z9NKRe19j7nUeAGaQN4dpkblmSvlbRqSIk /bxtveXLclU2iMCxdjrf1gw/0vadb4qPrX9bmYc8Wlfm5pHE65Xn53au1vNTNQ7xSKDl 1WPg== X-Gm-Message-State: AJaThX7d3zY2oaOMJt41bUKQNEG5EFDv+lpKo3pylQDjRy6OqFYCmXPU B2u/xGShpju9iTd1vYVAsC9RT5O8BfOGTRJXHtS1wQ== X-Google-Smtp-Source: AGs4zMYjqPeWoQ1bJOwBRAIDfyXjy/RagIysNdb7E1jTyFq8B36rTQWGzhJOaU6/T/xEAgIn1/mHEh2/YaPcEqirRC8= X-Received: by 10.37.246.39 with SMTP id t39mr13895240ybd.497.1512509886231; Tue, 05 Dec 2017 13:38:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 5 Dec 2017 13:37:25 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 5 Dec 2017 13:37:25 -0800 Message-ID: Subject: Re: Third Implementation Draft Prototype To: Praveen Balasubramanian Cc: Martin Duke , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045da8427cfa29055f9ea676" 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, 05 Dec 2017 21:38:14 -0000 --f403045da8427cfa29055f9ea676 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 5, 2017 at 1:33 PM, Praveen Balasubramanian wrote: > How are we going to exercise the =E2=80=9Crandom 10% loss=E2=80=9D test c= ase given this is > all remote participation? > I was more thinking this for MEL. Lars and I were talking about making a test harness, but that probably won't be available 12/18. -Ekr > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, December 5, 2017 1:23 PM > *To:* Martin Duke > *Cc:* Ian Swett ; IETF QUIC WG > *Subject:* Re: Third Implementation Draft Prototype > > > > Yes. This is actually demonstrating that it works :) I am trying to be > responsive to the request for clear test cases. > > > > -Ekr > > > > > > On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke > wrote: > > Isn't timeout-based loss recovery something that goes all the way back to > the 1st implementation draft? > > > > On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla wrote: > > It is done. > > > > -Ekr > > > > > > On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett wrote: > > Possibly this is part of "Update to draft-08", but I'd like to explicitly > state we're moving to TLS 1.3 draft 22. > > > > On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: > > Here's my first cut: > > https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft > > > > > > > > > > --f403045da8427cfa29055f9ea676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Dec 5, 2017 at 1:33 PM, Praveen Balasubramanian <pravb@micro= soft.com> wrote:

How are we going to exercise the =E2=80=9Crandom 10%= loss=E2=80=9D test case given this is all remote participation?

<= /div>

I was more thinking this for MEL.

Lars and I were talking about making a test harness, = but that probably won't be available 12/18.

-E= kr

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, December 5, 2017 1:23 PM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Ian Swett <ianswett@google.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Third Implementation Draft Prototype

<= div>

=C2=A0

Yes. This is actually demonstrating that it works :)= I am trying to be responsive to the request for clear test cases.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke <martin.h.duke@gmai= l.com> wrote:

Isn't timeout-based loss recovery something that= goes all the way back to the 1st implementation draft?

=C2=A0

On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

It is done.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett <ianswett@google.com&= gt; wrote:

Possibly this is part of "Update to draft-08&qu= ot;, but I'd like to explicitly state we're moving to TLS 1.3 draft= 22.

=C2=A0

On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--f403045da8427cfa29055f9ea676-- From nobody Tue Dec 5 13:52: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 D77C2128799 for ; Tue, 5 Dec 2017 13:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=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 kdvjPmqTQEfy for ; Tue, 5 Dec 2017 13:52:34 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0115.outbound.protection.outlook.com [104.47.37.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 BFF0412869B for ; Tue, 5 Dec 2017 13:52: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=2srpmOfKnJxIpmm7wJjkmXPyAXsLyvmn6Wal3sMghyg=; b=nrkIZnHvrUQgKHn3WT24ZaSWFMuEBgGVqP7fkrG1pWVS9gGyR7YjUry1Ktvfr1umihxqnI38H81sAn2qldmmUxOVeBRTLUldz2UtrdGAbYvHhXREhzcYv0C8rTTEwUjnQ0vCimIBaGD1VfgWtHdyrbpVbOfi6VJk09gGG5h+hmc= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0824.namprd21.prod.outlook.com (10.173.192.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.0; Tue, 5 Dec 2017 21:52:32 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0323.001; Tue, 5 Dec 2017 21:52:32 +0000 From: Praveen Balasubramanian To: Eric Rescorla CC: Martin Duke , Ian Swett , IETF QUIC WG Subject: RE: Third Implementation Draft Prototype Thread-Topic: Third Implementation Draft Prototype Thread-Index: AQHTbWh1xD9h+qm1akyyhLuydU10kKMz+iwAgAAEUgCAAUQ8gIAAAPAAgAACT5CAAAGxgIAAA2eQ Date: Tue, 5 Dec 2017 21:52:32 +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: [2001:4898:80e8:f::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0824; 6:54f6JEZStY2eW0eiNrtB6Qg8jmD6THSu+7casxKDJQPrhfVp196xOV6HNEZMczI8lfR9sCjLvBaQ1e1tDCWM6fAdiT1aYcgDckf1OVdM4kCRK2F9UTqxk2xQO/usb9XCsMtRVtYrtXy8uMKm/aI7s9dCEklCR3bU9cA9FMU32FbWzmy0l67NnNBR7Y2xpcihvVZptq/6QpuyKJrWtuBUITSLoskcghwqHNgB+l7mYCBxH7RPoLMzuQqkwiGJBY/7/b6tZ8Oxc/aLFE1UdR/I96qHRf/YMwiMzHzX9VsAdtJUhWTWrKNsuu1EsRP7YL8//dmTZhPEBYHneHcuSvjw2u22CeM51wbJhMhmct5H/Ik=; 5:L5b80V0/9QRLbzsxPHvc2A/7ylBXSK6o7AvzWiEwL17mZWWgBtRcUSh4BATgxhpN+AyRZFG3ThOpPaZOeID8r8haIK13ragTIuZ/TdGQU22Urd9dzGbBl5ZnPcyazam54PJzsy58lNOBCbKDZlADAzb9itI12i01Djq0pANpYjU=; 24:5kpHYguUUWTOsdazzPv1GHi8ia+A3w+tSW2K7pWlbnqCP4yO2MjbLo6Dww3Mad4ZgGI/ZHE+ib5b9zl+Otm9uwlqX+a5yYRleUUNpolC6ks=; 7:xwqdwc8NWyZO5KCSN2pf8sg2aOBCVqHr2btsIKeYw0TWeNzm9a85SuH7TUx8Bj2GZw4bVi0oiyTe0ZpnJnTOOYMq5qnpW5XQPImIunYP10vK6SX4XXmbY42hB92/F8Hy/88hSqizTQPbggciv8AbbuZiHk4s117hd4f8C/K+Ne8FWnUQ8PKRLpr7gHe2GLSuSbTwlvDJuF3AGyZyBsK8PUA2TdU94Qq3jM74DX2UMrHgAom5QaVxup8QZ+wKTvRi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 09314690-f731-42e7-71a5-08d53c2a7d2c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:CY4PR21MB0824; x-ms-traffictypediagnostic: CY4PR21MB0824: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(166708455590820)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(3231022)(920507027)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:CY4PR21MB0824; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR21MB0824; x-forefront-prvs: 0512CC5201 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(366004)(47760400005)(199004)(189003)(24454002)(97736004)(2906002)(478600001)(3280700002)(3480700004)(10290500003)(3660700001)(9686003)(236005)(86612001)(6306002)(54896002)(86362001)(106356001)(105586002)(53936002)(33656002)(8936002)(790700001)(6246003)(2900100001)(6116002)(102836003)(4326008)(101416001)(39060400002)(22452003)(6436002)(54906003)(55016002)(316002)(6916009)(2950100002)(8676002)(81166006)(81156014)(19609705001)(6506006)(76176011)(34040400001)(77096006)(7736002)(74316002)(5660300001)(25786009)(7696005)(229853002)(68736007)(966005)(14454004)(99286004)(53546010)(606006)(8990500004)(93886005)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0824; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01331D4A282564478E003796B63D0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09314690-f731-42e7-71a5-08d53c2a7d2c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 21:52:32.7744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0824 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, 05 Dec 2017 21:52:38 -0000 --_000_CY4PR21MB01331D4A282564478E003796B63D0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXZlbiBmb3IgTUVMIHRoZXJlIG1pZ2h0IGJlIGZvbGtzIHBhcnRpY2lwYXRpbmcgcmVtb3RlbHkg c28gd2UgbmVlZCB0byBmaWd1cmUgb3V0IGEgd2F5LiBDYW4gd2UgaGF2ZSB0aGUgY2xpZW50IHNp ZGUgaW1wbGVtZW50YXRpb25zIGluY29ycG9yYXRlIGEga25vYiBmb3IgZG9pbmcgdGhpcyBvbiBU eCBhbmQgUng/IEVpdGhlciBpbmxpbmUgaW4gdGhlIFFVSUMgY29kZSBvciBhcyBhbm90aGVyIHRv b2wgdGhhdCBydW5zIGxvY2FsbHkuIERvaW5nIHRoaXMgb24gc2VydmVyIHNpZGUgd2lsbCBiZSBj aGFsbGVuZ2luZyBiZWNhdXNlIG90aGVyIOKAnG5vbiBsb3NzIHJlY292ZXJ54oCdIHRlc3QgY2Fz ZXMgbWlnaHQgYmUgaW4gcHJvZ3Jlc3MgaW4gcGFyYWxsZWwuDQoNClRoYW5rcw0KDQpGcm9tOiBF cmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1i ZXIgNSwgMjAxNyAxOjM3IFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1p Y3Jvc29mdC5jb20+DQpDYzogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPjsg SWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFRoaXJkIEltcGxlbWVudGF0aW9uIERyYWZ0IFByb3RvdHlwZQ0K DQoNCg0KT24gVHVlLCBEZWMgNSwgMjAxNyBhdCAxOjMzIFBNLCBQcmF2ZWVuIEJhbGFzdWJyYW1h bmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KSG93IGFyZSB3ZSBnb2luZyB0byBleGVyY2lzZSB0aGUg4oCccmFuZG9tIDEwJSBsb3Nz 4oCdIHRlc3QgY2FzZSBnaXZlbiB0aGlzIGlzIGFsbCByZW1vdGUgcGFydGljaXBhdGlvbj8NCg0K SSB3YXMgbW9yZSB0aGlua2luZyB0aGlzIGZvciBNRUwuDQoNCkxhcnMgYW5kIEkgd2VyZSB0YWxr aW5nIGFib3V0IG1ha2luZyBhIHRlc3QgaGFybmVzcywgYnV0IHRoYXQgcHJvYmFibHkgd29uJ3Qg YmUgYXZhaWxhYmxlIDEyLzE4Lg0KDQotRWtyDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm IE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDUsIDIwMTcgMToyMyBQ TQ0KVG86IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LmguZHVrZUBnbWFpbC5jb20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxt YWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFRoaXJkIEltcGxlbWVudGF0aW9u IERyYWZ0IFByb3RvdHlwZQ0KDQpZZXMuIFRoaXMgaXMgYWN0dWFsbHkgZGVtb25zdHJhdGluZyB0 aGF0IGl0IHdvcmtzIDopIEkgYW0gdHJ5aW5nIHRvIGJlIHJlc3BvbnNpdmUgdG8gdGhlIHJlcXVl c3QgZm9yIGNsZWFyIHRlc3QgY2FzZXMuDQoNCi1Fa3INCg0KDQpPbiBUdWUsIERlYyA1LCAyMDE3 IGF0IDE6MTkgUE0sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86 bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNCklzbid0IHRpbWVvdXQtYmFzZWQgbG9z cyByZWNvdmVyeSBzb21ldGhpbmcgdGhhdCBnb2VzIGFsbCB0aGUgd2F5IGJhY2sgdG8gdGhlIDFz dCBpbXBsZW1lbnRhdGlvbiBkcmFmdD8NCg0KT24gTW9uLCBEZWMgNCwgMjAxNyBhdCA1OjU5IFBN LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3Rl Og0KSXQgaXMgZG9uZS4NCg0KLUVrcg0KDQoNCk9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNTo0MyBQ TSwgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUu Y29tPj4gd3JvdGU6DQpQb3NzaWJseSB0aGlzIGlzIHBhcnQgb2YgIlVwZGF0ZSB0byBkcmFmdC0w OCIsIGJ1dCBJJ2QgbGlrZSB0byBleHBsaWNpdGx5IHN0YXRlIHdlJ3JlIG1vdmluZyB0byBUTFMg MS4zIGRyYWZ0IDIyLg0KDQpPbiBNb24sIERlYyA0LCAyMDE3IGF0IDg6MjggUE0sIEVyaWMgUmVz Y29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpIZXJlJ3Mg bXkgZmlyc3QgY3V0Og0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtp L1RoaXJkLUltcGxlbWVudGF0aW9uLURyYWZ0PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUy RmJhc2UtZHJhZnRzJTJGd2lraSUyRlRoaXJkLUltcGxlbWVudGF0aW9uLURyYWZ0JmRhdGE9MDIl N0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzRkZWNmMDM3NzZhMDQwMmNjZGIxMDhkNTNj MjY3ZDA4JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQ4 MTA1ODM2MDg3MjMyMiZzZGF0YT1KbmNKQ3JVNVhURUNUeDNQMHVTajJMb0JKb2dteEJaYUxHRXh6 WmNlV3FvJTNEJnJlc2VydmVkPTA+DQoNCg0KDQoNCg0K --_000_CY4PR21MB01331D4A282564478E003796B63D0CY4PR21MB0133namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5F dmVuIGZvciBNRUwgdGhlcmUgbWlnaHQgYmUgZm9sa3MgcGFydGljaXBhdGluZyByZW1vdGVseSBz byB3ZSBuZWVkIHRvIGZpZ3VyZSBvdXQgYSB3YXkuIENhbiB3ZSBoYXZlIHRoZSBjbGllbnQgc2lk ZSBpbXBsZW1lbnRhdGlvbnMgaW5jb3Jwb3JhdGUgYSBrbm9iIGZvciBkb2luZyB0aGlzIG9uIFR4 IGFuZCBSeD8gRWl0aGVyIGlubGluZSBpbiB0aGUgUVVJQyBjb2RlIG9yIGFzIGFub3RoZXIgdG9v bCB0aGF0DQogcnVucyBsb2NhbGx5LiBEb2luZyB0aGlzIG9uIHNlcnZlciBzaWRlIHdpbGwgYmUg Y2hhbGxlbmdpbmcgYmVjYXVzZSBvdGhlciDigJxub24gbG9zcyByZWNvdmVyeeKAnSB0ZXN0IGNh c2VzIG1pZ2h0IGJlIGluIHByb2dyZXNzIGluIHBhcmFsbGVsLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVyaWMgUmVz Y29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBE ZWNlbWJlciA1LCAyMDE3IDE6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGlu IER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwuY29tJmd0OzsgSWFuIFN3ZXR0ICZsdDtpYW5z d2V0dEBnb29nbGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVGhpcmQgSW1wbGVtZW50YXRpb24gRHJhZnQgUHJvdG90 eXBlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyA1LCAyMDE3IGF0IDE6MzMgUE0sIFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SG93IGFyZSB3ZSBnb2luZyB0byBleGVyY2lzZSB0aGUg4oCccmFuZG9tIDEwJSBs b3Nz4oCdIHRlc3QgY2FzZSBnaXZlbiB0aGlzIGlzIGFsbCByZW1vdGUgcGFydGljaXBhdGlvbj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyBtb3JlIHRoaW5raW5nIHRoaXMgZm9yIE1FTC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFycyBh bmQgSSB3ZXJlIHRhbGtpbmcgYWJvdXQgbWFraW5nIGEgdGVzdCBoYXJuZXNzLCBidXQgdGhhdCBw cm9iYWJseSB3b24ndCBiZSBhdmFpbGFibGUgMTIvMTguPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4g UVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDUsIDIw MTcgMToyMyBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIER1a2UgJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi5oLmR1a2VA Z21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29n bGUuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFRoaXJkIEltcGxlbWVudGF0aW9uIERyYWZ0IFByb3RvdHlwZTxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVzLiBUaGlzIGlzIGFj dHVhbGx5IGRlbW9uc3RyYXRpbmcgdGhhdCBpdCB3b3JrcyA6KSBJIGFtIHRyeWluZyB0byBiZSBy ZXNwb25zaXZlIHRvIHRoZSByZXF1ZXN0IGZvciBjbGVhciB0ZXN0IGNhc2VzLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRGVjIDUsIDIwMTcgYXQg MToxOSBQTSwgTWFydGluIER1a2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklzbid0IHRpbWVv dXQtYmFzZWQgbG9zcyByZWNvdmVyeSBzb21ldGhpbmcgdGhhdCBnb2VzIGFsbCB0aGUgd2F5IGJh Y2sgdG8gdGhlIDFzdCBpbXBsZW1lbnRhdGlvbiBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgRGVjIDQs IDIwMTcgYXQgNTo1OSBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBy dGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBkb25lLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNTo0MyBQTSwgSWFuIFN3ZXR0ICZsdDs8YSBo cmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0 QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+UG9zc2libHkgdGhpcyBpcyBwYXJ0IG9mICZxdW90O1VwZGF0ZSB0byBkcmFmdC0w OCZxdW90OywgYnV0IEknZCBsaWtlIHRvIGV4cGxpY2l0bHkgc3RhdGUgd2UncmUgbW92aW5nIHRv IFRMUyAxLjMgZHJhZnQgMjIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIERlYyA0LCAyMDE3IGF0IDg6MjggUE0s IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0i X2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SGVyZSdzIG15IGZpcnN0IGN1dDo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUy RnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGd2lraSUyRlRoaXJkLUltcGxlbWVudGF0aW9uLURyYWZ0 JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M0ZGVjZjAzNzc2YTA0 MDJjY2RiMTA4ZDUzYzI2N2QwOCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSU3QzAlN0M2MzY0ODEwNTgzNjA4NzIzMjImYW1wO3NkYXRhPUpuY0pDclU1WFRFQ1R4M1AwdVNq MkxvQkpvZ214QlphTEdFeHpaY2VXcW8lM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvVGhpcmQtSW1wbGVt ZW50YXRpb24tRHJhZnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB01331D4A282564478E003796B63D0CY4PR21MB0133namp_-- From nobody Tue Dec 5 14: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 40CC71277BB for ; Tue, 5 Dec 2017 14:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, 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=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 xCbCvKI6RFR4 for ; Tue, 5 Dec 2017 14:44:38 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0094.outbound.protection.outlook.com [104.47.1.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98F7124319 for ; Tue, 5 Dec 2017 14:44:37 -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=ZbIeI+ZKSY1kdQaU3Bb3AF/xD4J9p4VrAxqgrqQtAck=; b=YiYW7hYKjvFqtz23rO8tMfYNr89zfb8oSo4MXdTfjs+0nwuqgkR5eakoPzN4tsl96pmSMVOL5k317wRk8AjCKqEVA0Md8RTcq07ZvsjQLgCJa/06vFU9Dq01s5uxXTmpKsa1mj3RYtpKVVOeYxfY0xkHe7hoPAWAIoJOqb/mgBk= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Tue, 5 Dec 2017 22:44:34 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::6021:c53d:b66d:4a61]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::6021:c53d:b66d:4a61%13]) with mapi id 15.20.0282.007; Tue, 5 Dec 2017 22:44:33 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Praveen Balasubramanian , Eric Rescorla CC: Ian Swett , IETF QUIC WG , Martin Duke , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Subject: Re: Third Implementation Draft Prototype Thread-Topic: Third Implementation Draft Prototype Thread-Index: AQHTbWhzk7BINKzcZ0eXuQ2hGLDNUqMz+iwAgAAEUgCAAUQ8gIAAAPAAgAAC6gCAAAEWgIAABDkAgAAOhwA= Date: Tue, 5 Dec 2017 22:44:33 +0000 Message-ID: <63B8A9DA-12CB-4A59-99AF-771CF749C8A4@nokia.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.127.129] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 6:Zi1EbqN/VyaRxhSB9vVCbaoXaHZRiPIJvwkX7qb/dG/LvZy05jr6DlURQ6aNuBLhTpAQxgQf29Gor/mQHUtjskR0x45PqBN0AXGNQxNCDzXZ5eAMlrPKZvz7uSC7iYp86Y5Y0jX+2eBL5ikaEoop2L8leEG5pzS0Su9pRCJqtawo/MOpywbBAg+vggplbpMszyjkHfj8DWA2OctjN0uxuc6Y4TGAPJgbCqcbtrfxGJyjVfubc6pVPpnyecLzNkH/ULmSL/HrOdVO6DeEUe9e7JfaPlBaxhn+6n0wqxUM2JCTs7vA9koUB0fMmeXUyjzIte4hDBGuzlRTx6SO46Hfv7XzOZalgSgebp/eohio7x4=; 5:j7ug+D1mkjj2L3KQPg2htl7BFYCWD7Zwjm8CyMFwoJe/DWmPYw+sKCeduA9UbkQgwBHsk9djELnYeGlcZ+d7ZHj+wzpDodsSSCZLIxbQ4HIL2307KXcgGYIW3A50caRT3nnELgmdx0o6u72G2+W5Z2pDv6G5qYCNIx/KfWr1K4U=; 24:HKZsOqO5hFX6PYkBzWm2qVabnU7vYkIFhTx5UZbnSiuTh0tOiqTspPV0XZw1LfvnKPweT8ibQF+iggUzv+/ELpz6UpRkt91qn42386HYIFY=; 7:0DfcM/0m2sCxhNSiHBKpKncj8Si6Xh6TXJZxdzQNEQRBuYgvA3p49skcOvPvU42nDryKvcOyeeNejSCdPDbIFoW3KfLqnihV9ydLvn2VFBQ3ESU6TNcORHmv6M6xFXhkwSC7hbTB3Qps85FT7Q2420fiQk/Lyyu5affjFjjbH7j+ROA9KIvLC8plf2A2yS0CnhsmRq1Jw0pQXpgud/nBjOu6WRiKhQo+NtiVAEop02mNhdQMcOr45fRVFwsvnL1P x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39860400002)(24454002)(199004)(189003)(81166006)(236005)(2421001)(82746002)(97736004)(105586002)(83506002)(58126008)(39060400002)(68736007)(3660700001)(6116002)(102836003)(3846002)(5660300001)(3280700002)(4326008)(106356001)(99286004)(101416001)(53546010)(8676002)(93886005)(76176011)(66066001)(6246003)(6486002)(6436002)(3480700004)(45080400002)(8936002)(14454004)(110136005)(2900100001)(25786009)(2906002)(966005)(53936002)(81156014)(8666007)(2561002)(33656002)(6512007)(478600001)(54896002)(5250100002)(34040400001)(107886003)(229853002)(7736002)(86362001)(2950100002)(6306002)(54906003)(83716003)(36756003)(6506006)(316002)(1511001)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bb61620a-d1b6-43f6-9ce0-08d53c31c14e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:VI1PR07MB1103; x-ms-traffictypediagnostic: VI1PR07MB1103: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(166708455590820)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231022)(920507027)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB1103; x-forefront-prvs: 0512CC5201 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_63B8A9DA12CB4A5999AF771CF749C8A4nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb61620a-d1b6-43f6-9ce0-08d53c31c14e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 22:44:33.6230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 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, 05 Dec 2017 22:44:41 -0000 --_000_63B8A9DA12CB4A5999AF771CF749C8A4nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gTGludXgsIHRoZSBlYXNpZXN0IGlzIHByb2JhYmx5IG5ldGVtKDgpLiAgU2VydmVyIHNpZGUg eW91IGNhbiBjb3VwbGUgaXQgd2l0aCBhIGZpbHRlciB0byBtYXRjaCBhIHNwZWNpZmljIGNsaWVu dCBhZGRyZXNzIG9yIGEgc2VydmVyIHBvcnQgaWYgeW91IHBsYW4gdG8gcnVuIGRpZmZlcmVudCBz ZXJ2ZXIgaW5zdGFuY2VzIGZvciBkaWZmZXJlbnQgdGVzdCBjYXNlcy4NCg0KT24gV2luZG93cywg b25lIHBvc3NpYmlsaXR5IHNlZW1zIHRvIGJlIENsdW1zeSAoaHR0cDovL2phZ3QuZ2l0aHViLmlv L2NsdW1zeS8pIChJIGhhdmUgemVybyBleHBlcmllbmNlIHdpdGggaXQuKQ0KDQpPbiBNYWMsIHRo ZSBOZXR3b3JrIExpbmsgQ29uZGl0aW9uZXIgZnJvbSBYY29kZS4NCg0KQ2hlZXJzDQoNCk9uIDA1 LzEyLzIwMTcsIDIxOjUyLCAiUVVJQyBvbiBiZWhhbGYgb2YgUHJhdmVlbiBCYWxhc3VicmFtYW5p YW4iIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5j b20+PiB3cm90ZToNCg0KRXZlbiBmb3IgTUVMIHRoZXJlIG1pZ2h0IGJlIGZvbGtzIHBhcnRpY2lw YXRpbmcgcmVtb3RlbHkgc28gd2UgbmVlZCB0byBmaWd1cmUgb3V0IGEgd2F5LiBDYW4gd2UgaGF2 ZSB0aGUgY2xpZW50IHNpZGUgaW1wbGVtZW50YXRpb25zIGluY29ycG9yYXRlIGEga25vYiBmb3Ig ZG9pbmcgdGhpcyBvbiBUeCBhbmQgUng/IEVpdGhlciBpbmxpbmUgaW4gdGhlIFFVSUMgY29kZSBv ciBhcyBhbm90aGVyIHRvb2wgdGhhdCBydW5zIGxvY2FsbHkuIERvaW5nIHRoaXMgb24gc2VydmVy IHNpZGUgd2lsbCBiZSBjaGFsbGVuZ2luZyBiZWNhdXNlIG90aGVyIOKAnG5vbiBsb3NzIHJlY292 ZXJ54oCdIHRlc3QgY2FzZXMgbWlnaHQgYmUgaW4gcHJvZ3Jlc3MgaW4gcGFyYWxsZWwuDQoNClRo YW5rcw0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgNSwgMjAxNyAxOjM3IFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFt YW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQpDYzogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1 a2VAZ21haWwuY29tPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgSUVURiBRVUlD IFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFRoaXJkIEltcGxlbWVudGF0aW9uIERy YWZ0IFByb3RvdHlwZQ0KDQoNCg0KT24gVHVlLCBEZWMgNSwgMjAxNyBhdCAxOjMzIFBNLCBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWlj cm9zb2Z0LmNvbT4+IHdyb3RlOg0KSG93IGFyZSB3ZSBnb2luZyB0byBleGVyY2lzZSB0aGUg4oCc cmFuZG9tIDEwJSBsb3Nz4oCdIHRlc3QgY2FzZSBnaXZlbiB0aGlzIGlzIGFsbCByZW1vdGUgcGFy dGljaXBhdGlvbj8NCg0KSSB3YXMgbW9yZSB0aGlua2luZyB0aGlzIGZvciBNRUwuDQoNCkxhcnMg YW5kIEkgd2VyZSB0YWxraW5nIGFib3V0IG1ha2luZyBhIHRlc3QgaGFybmVzcywgYnV0IHRoYXQg cHJvYmFibHkgd29uJ3QgYmUgYXZhaWxhYmxlIDEyLzE4Lg0KDQotRWtyDQoNCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy IDUsIDIwMTcgMToyMyBQTQ0KVG86IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNv bTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dl dHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyBJRVRGIFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFRoaXJk IEltcGxlbWVudGF0aW9uIERyYWZ0IFByb3RvdHlwZQ0KDQpZZXMuIFRoaXMgaXMgYWN0dWFsbHkg ZGVtb25zdHJhdGluZyB0aGF0IGl0IHdvcmtzIDopIEkgYW0gdHJ5aW5nIHRvIGJlIHJlc3BvbnNp dmUgdG8gdGhlIHJlcXVlc3QgZm9yIGNsZWFyIHRlc3QgY2FzZXMuDQoNCi1Fa3INCg0KDQpPbiBU dWUsIERlYyA1LCAyMDE3IGF0IDE6MTkgUE0sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNCklzbid0IHRp bWVvdXQtYmFzZWQgbG9zcyByZWNvdmVyeSBzb21ldGhpbmcgdGhhdCBnb2VzIGFsbCB0aGUgd2F5 IGJhY2sgdG8gdGhlIDFzdCBpbXBsZW1lbnRhdGlvbiBkcmFmdD8NCg0KT24gTW9uLCBEZWMgNCwg MjAxNyBhdCA1OjU5IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBy dGZtLmNvbT4+IHdyb3RlOg0KSXQgaXMgZG9uZS4NCg0KLUVrcg0KDQoNCk9uIE1vbiwgRGVjIDQs IDIwMTcgYXQgNTo0MyBQTSwgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tPj4gd3JvdGU6DQpQb3NzaWJseSB0aGlzIGlzIHBhcnQgb2YgIlVw ZGF0ZSB0byBkcmFmdC0wOCIsIGJ1dCBJJ2QgbGlrZSB0byBleHBsaWNpdGx5IHN0YXRlIHdlJ3Jl IG1vdmluZyB0byBUTFMgMS4zIGRyYWZ0IDIyLg0KDQpPbiBNb24sIERlYyA0LCAyMDE3IGF0IDg6 MjggUE0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4g d3JvdGU6DQpIZXJlJ3MgbXkgZmlyc3QgY3V0Og0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy93aWtpL1RoaXJkLUltcGxlbWVudGF0aW9uLURyYWZ0PGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHVi LmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGd2lraSUyRlRoaXJkLUltcGxlbWVudGF0aW9u LURyYWZ0JmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzRkZWNmMDM3NzZh MDQwMmNjZGIxMDhkNTNjMjY3ZDA4JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjQ4MTA1ODM2MDg3MjMyMiZzZGF0YT1KbmNKQ3JVNVhURUNUeDNQMHVTajJM b0JKb2dteEJaYUxHRXh6WmNlV3FvJTNEJnJlc2VydmVkPTA+DQoNCg0KDQoNCg0K --_000_63B8A9DA12CB4A5999AF771CF749C8A4nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i RU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+T24gTGludXgsIHRoZSBlYXNpZXN0IGlzIHByb2JhYmx5IG5ldGVtKDgpLiZu YnNwOyBTZXJ2ZXIgc2lkZSB5b3UgY2FuIGNvdXBsZSBpdCB3aXRoIGEgZmlsdGVyIHRvIG1hdGNo IGEgc3BlY2lmaWMgY2xpZW50IGFkZHJlc3Mgb3IgYSBzZXJ2ZXIgcG9ydCBpZiB5b3UgcGxhbiB0 byBydW4gZGlmZmVyZW50IHNlcnZlciBpbnN0YW5jZXMgZm9yIGRpZmZlcmVudA0KIHRlc3QgY2Fz ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPk9uIFdpbmRvd3MsIG9uZSBwb3NzaWJpbGl0eSBzZWVtcyB0byBiZSBDbHVtc3kg KDxhIGhyZWY9Imh0dHA6Ly9qYWd0LmdpdGh1Yi5pby9jbHVtc3kvKSI+aHR0cDovL2phZ3QuZ2l0 aHViLmlvL2NsdW1zeS8pPC9hPiAoSSBoYXZlIHplcm8gZXhwZXJpZW5jZSB3aXRoIGl0Lik8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+T24gTWFjLCB0aGUgTmV0d29yayBMaW5rIENvbmRpdGlvbmVyIGZyb20gWGNvZGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbiAwNS8xMi8yMDE3LCAyMTo1MiwgJnF1b3Q7UVVJQyBvbiBiZWhhbGYg b2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9m DQo8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSI+cHJhdmJAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+RXZlbiBmb3IgTUVMIHRoZXJlIG1pZ2h0IGJlIGZvbGtzIHBhcnRpY2lwYXRp bmcgcmVtb3RlbHkgc28gd2UgbmVlZCB0byBmaWd1cmUgb3V0IGEgd2F5LiBDYW4gd2UgaGF2ZSB0 aGUgY2xpZW50IHNpZGUgaW1wbGVtZW50YXRpb25zIGluY29ycG9yYXRlIGEga25vYiBmb3IgZG9p bmcgdGhpcyBvbiBUeCBhbmQgUng/IEVpdGhlciBpbmxpbmUgaW4gdGhlIFFVSUMgY29kZQ0KIG9y IGFzIGFub3RoZXIgdG9vbCB0aGF0IHJ1bnMgbG9jYWxseS4gRG9pbmcgdGhpcyBvbiBzZXJ2ZXIg c2lkZSB3aWxsIGJlIGNoYWxsZW5naW5nIGJlY2F1c2Ugb3RoZXIg4oCcbm9uIGxvc3MgcmVjb3Zl cnnigJ0gdGVzdCBjYXNlcyBtaWdodCBiZSBpbiBwcm9ncmVzcyBpbiBwYXJhbGxlbC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPkZyb206PC9iPiBF cmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIERlY2VtYmVyIDUsIDIwMTcgMTozNyBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBNYXJ0aW4gRHVrZSAmbHQ7bWFydGluLmguZHVrZUBnbWFpbC5jb20mZ3Q7OyBJYW4gU3dldHQg Jmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBUaGlyZCBJbXBsZW1lbnRhdGlvbiBEcmFm dCBQcm90b3R5cGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIFR1ZSwgRGVjIDUsIDIwMTcgYXQgMTozMyBQTSwg UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KSG93IGFyZSB3ZSBnb2luZyB0byBleGVyY2lzZSB0aGUg4oCccmFuZG9tIDEw JSBsb3Nz4oCdIHRlc3QgY2FzZSBnaXZlbiB0aGlzIGlzIGFsbCByZW1vdGUgcGFydGljaXBhdGlv bj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIHdhcyBtb3JlIHRoaW5raW5nIHRoaXMgZm9yIE1FTC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TGFycyBhbmQg SSB3ZXJlIHRhbGtpbmcgYWJvdXQgbWFraW5nIGEgdGVzdCBoYXJuZXNzLCBidXQgdGhhdCBwcm9i YWJseSB3b24ndCBiZSBhdmFpbGFibGUgMTIvMTguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3Js YTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciA1LCAyMDE3IDE6MjMgUE08YnI+ DQo8Yj5Ubzo8L2I+IE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLmguZHVr ZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0 dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7 OyBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBU aGlyZCBJbXBsZW1lbnRhdGlvbiBEcmFmdCBQcm90b3R5cGU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NClllcy4gVGhpcyBpcyBhY3R1YWxseSBkZW1vbnN0cmF0aW5nIHRoYXQgaXQg d29ya3MgOikgSSBhbSB0cnlpbmcgdG8gYmUgcmVzcG9uc2l2ZSB0byB0aGUgcmVxdWVzdCBmb3Ig Y2xlYXIgdGVzdCBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQotRWty PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpPbiBU dWUsIERlYyA1LCAyMDE3IGF0IDE6MTkgUE0sIE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWls dG86bWFydGluLmguZHVrZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtl QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpJc24ndCB0aW1lb3V0LWJhc2VkIGxvc3MgcmVj b3Zlcnkgc29tZXRoaW5nIHRoYXQgZ29lcyBhbGwgdGhlIHdheSBiYWNrIHRvIHRoZSAxc3QgaW1w bGVtZW50YXRpb24gZHJhZnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQpPbiBNb24sIERlYyA0LCAyMDE3IGF0IDU6NTkgUE0sIEVyaWMgUmVzY29ybGEg Jmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRm bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KSXQgaXMgZG9uZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM2LjBwdCI+DQotRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpPbiBNb24sIERlYyA0 LCAyMDE3IGF0IDU6NDMgUE0sIElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0 QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NClBvc3NpYmx5IHRoaXMgaXMgcGFydCBvZiAmcXVvdDtVcGRhdGUgdG8gZHJhZnQt MDgmcXVvdDssIGJ1dCBJJ2QgbGlrZSB0byBleHBsaWNpdGx5IHN0YXRlIHdlJ3JlIG1vdmluZyB0 byBUTFMgMS4zIGRyYWZ0IDIyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KT24gTW9uLCBEZWMgNCwgMjAxNyBhdCA4OjI4IFBNLCBFcmljIFJlc2Nvcmxh ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0 Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkhlcmUncyBteSBmaXJzdCBjdXQ6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRndpa2kl MkZUaGlyZC1JbXBsZW1lbnRhdGlvbi1EcmFmdCZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBt aWNyb3NvZnQuY29tJTdDNGRlY2YwMzc3NmEwNDAyY2NkYjEwOGQ1M2MyNjdkMDglN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDgxMDU4MzYwODcyMzIyJmFt cDtzZGF0YT1KbmNKQ3JVNVhURUNUeDNQMHVTajJMb0JKb2dteEJaYUxHRXh6WmNlV3FvJTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy93aWtpL1RoaXJkLUltcGxlbWVudGF0aW9uLURyYWZ0PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_63B8A9DA12CB4A5999AF771CF749C8A4nokiacom_-- From nobody Tue Dec 5 14:58: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 4B22F128B44 for ; Tue, 5 Dec 2017 14:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.756 X-Spam-Level: X-Spam-Status: No, score=0.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 XAjHpa_zhN3i for ; Tue, 5 Dec 2017 14:58:13 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1821212895E for ; Tue, 5 Dec 2017 14:58:13 -0800 (PST) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 29E843A0D7 for ; Tue, 5 Dec 2017 17:58:11 -0500 (EST) Received: by mail-lf0-f45.google.com with SMTP id f13so2142035lff.12 for ; Tue, 05 Dec 2017 14:58:11 -0800 (PST) X-Gm-Message-State: AJaThX6MIvXUHF9wmg7YACoy7u6oLfV7u6zTSTRAjSaYIqKc4sRo43RU zjbxQKNolMtbd+Avh47JcsW22a2XsXBja4Of8n8= X-Google-Smtp-Source: AGs4zMaU8CjixnqKG0/MV8gPD4s3aR8rD65q2cZ98Yvfj5ZG8rmKq87DYhJrwIrcBM5Por7e/DSf/vVdKnyR1FvVAVI= X-Received: by 10.25.84.90 with SMTP id i87mr10839025lfb.35.1512514689731; Tue, 05 Dec 2017 14:58:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.166.143 with HTTP; Tue, 5 Dec 2017 14:58:08 -0800 (PST) In-Reply-To: <63B8A9DA-12CB-4A59-99AF-771CF749C8A4@nokia.com> References: <63B8A9DA-12CB-4A59-99AF-771CF749C8A4@nokia.com> From: Patrick McManus Date: Tue, 5 Dec 2017 17:58:08 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Third Implementation Draft Prototype To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Praveen Balasubramanian , Eric Rescorla , Ian Swett , IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="94eb2c1cdffecc959e055f9fc4db" 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, 05 Dec 2017 22:58:16 -0000 --94eb2c1cdffecc959e055f9fc4db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable those will all work for the immediate use case of "drop 10%", but the more interesting case will be something like "what happens to flow control when rst_stream is dropped" and for that you're going to need something quic specific... maybe a harness with access to keys. It looks like all the cases ekr chose for the first instance of this test intentionally don't need to be able to know anything about packet contents to do the dropping so we can check those off while developing a more sophisticated testing approach.. On Tue, Dec 5, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = < thomas.fossati@nokia.com> wrote: > On Linux, the easiest is probably netem(8). Server side you can couple i= t > with a filter to match a specific client address or a server port if you > plan to run different server instances for different test cases. > > > > On Windows, one possibility seems to be Clumsy ( > http://jagt.github.io/clumsy/) (I have zero experience with it.) > > > > On Mac, the Network Link Conditioner from Xcode. > > > > Cheers > > > > On 05/12/2017, 21:52, "QUIC on behalf of Praveen Balasubramanian" < > quic-bounces@ietf.org on behalf of pravb@microsoft.com> wrote: > > > > Even for MEL there might be folks participating remotely so we need to > figure out a way. Can we have the client side implementations incorporate= a > knob for doing this on Tx and Rx? Either inline in the QUIC code or as > another tool that runs locally. Doing this on server side will be > challenging because other =E2=80=9Cnon loss recovery=E2=80=9D test cases = might be in > progress in parallel. > > > > Thanks > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Tuesday, December 5, 2017 1:37 PM > *To:* Praveen Balasubramanian > *Cc:* Martin Duke ; Ian Swett < > ianswett@google.com>; IETF QUIC WG > *Subject:* Re: Third Implementation Draft Prototype > > > > > > > > On Tue, Dec 5, 2017 at 1:33 PM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > How are we going to exercise the =E2=80=9Crandom 10% loss=E2=80=9D test c= ase given this is > all remote participation? > > > > I was more thinking this for MEL. > > > > Lars and I were talking about making a test harness, but that probably > won't be available 12/18. > > > > -Ekr > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, December 5, 2017 1:23 PM > *To:* Martin Duke > *Cc:* Ian Swett ; IETF QUIC WG > *Subject:* Re: Third Implementation Draft Prototype > > > > Yes. This is actually demonstrating that it works :) I am trying to be > responsive to the request for clear test cases. > > > > -Ekr > > > > > > On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke > wrote: > > Isn't timeout-based loss recovery something that goes all the way back to > the 1st implementation draft? > > > > On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla wrote: > > It is done. > > > > -Ekr > > > > > > On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett wrote: > > Possibly this is part of "Update to draft-08", but I'd like to explicitly > state we're moving to TLS 1.3 draft 22. > > > > On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla wrote: > > Here's my first cut: > > https://github.com/quicwg/base-drafts/wiki/Third-Implementation-Draft > > > > > > > > > > > > --94eb2c1cdffecc959e055f9fc4db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
those will all work for the immediate use case of &qu= ot;drop 10%", but the more interesting case will be something like &qu= ot;what happens to flow control when rst_stream is dropped" and for th= at you're going to need something quic specific... maybe a harness with= access to keys. It looks like all the cases ekr chose for the first instan= ce of this test intentionally don't need to be able to know anything ab= out packet contents to do the dropping so we can check those off while deve= loping a more sophisticated testing approach..



= On Tue, Dec 5, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = <thomas.fossati@nokia.com> wrote:

On Linux, the easiest is probably netem(8).=C2= =A0 Server side you can couple it with a filter to match a specific client = address or a server port if you plan to run different server instances for = different test cases.

=C2=A0

On Windows, one possibility seems to be Clumsy= (http://jagt.= github.io/clumsy/) (I have zero experience with it.)=

=C2=A0

On Mac, the Network Link Conditioner from Xcod= e.

=C2=A0

Cheers

=C2=A0

On 05/12/2017, 21:52, &= quot;QUIC on behalf of Praveen Balasubramanian" <quic-bounces@ietf.org on behal= f of pravb@microsoft.co= m> wrote:

=C2=A0

Even for MEL there migh= t be folks participating remotely so we need to figure out a way. Can we ha= ve the client side implementations incorporate a knob for doing this on Tx = and Rx? Either inline in the QUIC code or as another tool that runs locally. Doing this on server side will be ch= allenging because other =E2=80=9Cnon loss recovery=E2=80=9D test cases migh= t be in progress in parallel.

=C2=A0

Thanks

=C2=A0

From: Eric Resco= rla [mailto:ekr@rtfm.com<= /a>]
Sent: Tuesday, December 5, 2017 1:37 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Martin Duke <martin.h.duke@gmail.com>; Ian Swett <ianswett@google.com>; IETF= QUIC WG <quic@ietf.o= rg>
Subject: Re: Third Implementation Draft Prototype

=C2=A0

=C2=A0

=C2=A0

On Tue, Dec 5, 2017 at = 1:33 PM, Praveen Balasubramanian <pravb@microsoft.com> wrote:

How are we going to exercise the =E2=80=9Crandom 10% loss=E2=80=9D test cas= e given this is all remote participation?

=C2=A0

I was more thinking thi= s for MEL.

=C2=A0

Lars and I were talking= about making a test harness, but that probably won't be available 12/1= 8.

=C2=A0

-Ekr

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, December 5, 2017 1:23 PM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Ian Swett <ianswett@google.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Third Implementation Draft Prototype

=C2=A0

Yes. This is actually demonstrating that it works :) I am trying to be resp= onsive to the request for clear test cases.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Tue, Dec 5, 2017 at 1:19 PM, Martin Duke <martin.h.duke@gmail.com> wrote:=

Isn't timeout-based loss recovery something that goes all the way back = to the 1st implementation draft?

=C2=A0

On Mon, Dec 4, 2017 at 5:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:

It is done.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Mon, Dec 4, 2017 at 5:43 PM, Ian Swett <ianswett@google.com> wrote:

Possibly this is part of "Update to draft-08", but I'd like t= o explicitly state we're moving to TLS 1.3 draft 22.

=C2=A0

On Mon, Dec 4, 2017 at 8:28 PM, Eric Rescorla <ekr@rtfm.com> wrote:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--94eb2c1cdffecc959e055f9fc4db-- From nobody Tue Dec 5 16: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 905DF128B91 for ; Tue, 5 Dec 2017 16:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG1NW5xAScUY for ; Tue, 5 Dec 2017 16:06:29 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 EFD27128B8E for ; Tue, 5 Dec 2017 16:06:28 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id s4so1899802ote.4 for ; Tue, 05 Dec 2017 16:06: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:content-transfer-encoding; bh=lyxyaN0JaGri1x4oBklI/dBuwuYsAXZmIXq97A6029I=; b=gZlLwhUAWG0PONxrGj4oh1cY6c/SJMLmR7lx0bCht1PeWnmk/AEbBxFNTvvB1MthtT MQGDjUW290U3dOV3tAdFQetjQYat+p1WXOxkByO/cek+Mk/nwnI1357MvoL3wgCwSSrO tRa1Lu3sttY0JeSjGqXI7Ezk+n725lMFCxI5KN9y7Wj6Y+t3rlQtbi6u+L+p2sl08Zni MOHuidjmVOIq6eBtEkmdO7l1rHPusW78wrwPIvF//DW9naRq3YzWhEAMdpupiiTRX0ML 1kW4ZYhG9S5y0XJ1nU5nh4LhhYjxthJ2RTGmoJcdvjJ2bUsLS4Vua4rSty+ESYJzSWw9 /w2Q== 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=lyxyaN0JaGri1x4oBklI/dBuwuYsAXZmIXq97A6029I=; b=HWxiWuuX10AMB1U0WlJ1opPq1glmBmKzd7ZQk4xq5vsCBYgMxeFrpyD+rsXtp+DFPE L6hwsbI2JIiosZ7iiZ64bp3drpISNUaD7wiAYA6JvZoOrZbsEeC9sTi+Jc6CPLHo9mDo V5iXCNjkvexASbhfzB7vDpMUpJ6PXSOCXVnjpJQ+KLOg1GkjM13kOVsyacykbCu2rbmT 6S+I0d+mBOI9dwN/EHxtgC0+xahPcnHhvz8meqVnCtnL5HAkm7tRSpi+Xde1wfs2BpeF MA5auviOOcmqMpSXWxuyvdpT/f6fYvNrN2dE1aVCEPqRFrSH1EGQumF/mtLgEfMoEVRM 0UhQ== X-Gm-Message-State: AJaThX5O5XM7/yo/w0uhRv5i4uxsnF6cX3Py9BrfNpE6YLMHbV3zdh7R gcsH7Ra/Rv400fI1bfmloHvEnfFEkEpWPTlRbCU= X-Google-Smtp-Source: AGs4zMYrno/1xPNqFf7oVeEPpJe4Zvm60g0vneSGUV2dPy3EsWCdHbB7j+fH2FjD3R02qAvijS1bMDcOPkBFdxx8ZA8= X-Received: by 10.157.39.45 with SMTP id r42mr23365376ota.71.1512518788347; Tue, 05 Dec 2017 16:06:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 5 Dec 2017 16:06:27 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 6 Dec 2017 11:06:27 +1100 Message-ID: Subject: Re: Simplify ACK frame retransmission To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: 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: Wed, 06 Dec 2017 00:06:30 -0000 On Wed, Dec 6, 2017 at 6:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I really would like a QUIC version that only depends on AES, curve25519 > (and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoid > heavy TLS libraries, but this is still possible with a custom QUIC versio= n. Apart from the OpenSSH part, this is all possible right now with a profile of TLS. (I guess you mean raw public keys without X.509). All of what you describe is negotiable in TLS. You might not interoperate with many implementations, but it is possible, especially if you don't care for much interoperability. The biggest interoperability losses are where you go from X.509 to raw public keys (that is, RFC 7250), but Ed25519 is also only starting to be implemented. From nobody Tue Dec 5 17:28:51 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 3B7EE128B51; Tue, 5 Dec 2017 17:28:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151252372918.30817.13458599568535139420@ietfa.amsl.com> Date: Tue, 05 Dec 2017 17:28:49 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-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, 06 Dec 2017 01:28:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-08.txt Pages : 95 Date : 2017-12-05 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-08 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-08 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 Tue Dec 5 17:29: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 F2516127735; Tue, 5 Dec 2017 17:28:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151252372995.30761.2743597807121172227@ietfa.amsl.com> Date: Tue, 05 Dec 2017 17:28:49 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-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, 06 Dec 2017 01:28:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-08.txt Pages : 38 Date : 2017-12-05 Abstract: This document describes how Transport Layer Security (TLS) is 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 [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-tls [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-08 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-08 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 Tue Dec 5 17:38:16 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 D9D49124217; Tue, 5 Dec 2017 17:38:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151252428981.30686.2384485168604713646@ietfa.amsl.com> Date: Tue, 05 Dec 2017 17:38:09 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-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, 06 Dec 2017 01:38:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-08.txt Pages : 26 Date : 2017-12-05 Abstract: This document describes loss detection and congestion control mechanisms for 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 [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-08 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-08 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 Tue Dec 5 21:25: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 52015124E15 for ; Tue, 5 Dec 2017 21:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 AgYBGC9VY1kI for ; Tue, 5 Dec 2017 21:25:10 -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 3577512421A for ; Tue, 5 Dec 2017 21:25:10 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eMSCh-0004Ko-JV for quic@ietf.org; Wed, 06 Dec 2017 06:25:08 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eMSCf-0001Gt-5N for quic@ietf.org; Wed, 06 Dec 2017 00:25:05 -0500 Received: (qmail 8487 invoked from network); 6 Dec 2017 05:25:03 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.119]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Dec 2017 05:25:03 -0000 To: quic@ietf.org References: <151252372918.30817.13458599568535139420@ietfa.amsl.com> From: Christian Huitema Message-ID: <7d48c0af-1606-25e9-ba17-7d0ec160a6f3@huitema.net> Date: Tue, 5 Dec 2017 21:25:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151252372918.30817.13458599568535139420@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: I-D Action: draft-ietf-quic-transport-08.txt X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tiXX8MvStFfbqZIvToFKDsXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftAFTpl1ExIa4NSxIe75snUB98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLFQwbgMCItJaYYOhQRv6/ UBgttVPrA7edWruIIae3993h9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GaydQSHaKCADuB2RogJvWPZnHEeB4hpRrmo/duzUUp/La SapF+Sj4UeL9OCHSPat/NszzEFd2Bel1VMo/cyqNCHLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+lXmk/kN/ohhMsDjVJmzLuIj2lB9TLiDMfXuvSrucRXqLltlcS50veJ4w4EzZsk1xpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g 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: Wed, 06 Dec 2017 05:25:12 -0000 I am looking at the change list on that draft: > C.1. Since draft-ietf-quic-transport-07 > > o Employ variable-length integer encodings throughout (#595) > > o Draining period can terminate early (#869) I wish it were just that, but there were many more PR that went into draft 08. For example: * New PONG Frame, and new format for the PING frame, * New format for Transport Parameters, * New format for the packet header I am sure that I am still missing some. But the combination of all that is pretty large. Lots of code churn. -- Christian Huitema From nobody Tue Dec 5 21:32: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 1F7CC124E15 for ; Tue, 5 Dec 2017 21:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 Vn8vMagGHKXs for ; Tue, 5 Dec 2017 21:32:36 -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 B2E1D126BF6 for ; Tue, 5 Dec 2017 21:32:36 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eMSJu-0000UL-RD for quic@ietf.org; Wed, 06 Dec 2017 06:32:35 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eMSJr-00087e-Ef for quic@ietf.org; Wed, 06 Dec 2017 00:32:32 -0500 Received: (qmail 18025 invoked from network); 6 Dec 2017 05:32:29 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.119]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Dec 2017 05:32:29 -0000 To: quic@ietf.org References: <151252372918.30817.13458599568535139420@ietfa.amsl.com> <7d48c0af-1606-25e9-ba17-7d0ec160a6f3@huitema.net> From: Christian Huitema Message-ID: Date: Tue, 5 Dec 2017 21:32:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7d48c0af-1606-25e9-ba17-7d0ec160a6f3@huitema.net> Content-Type: multipart/alternative; boundary="------------A859F532C0E604CAEFE9C46A" Content-Language: en-US Subject: Re: I-D Action: draft-ietf-quic-transport-08.txt X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5pOMwXGroREfXB6/8G67+JAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKLDbvTFJbDsTnbi4O7xM7B98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPTmWL20QDaTB8w3xrEB2b t19IIOMLei2dFv8KApNhdkcHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFCFnwGKkv+DIQGXVP+Qhqh8ibYT4C2qF2lnc18bVJn66c k/qdxIjknY8g8aNaqTZjhLCYMXOzTHc/k6k44ZuegjwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTcmOtKpb1oAulsHm1CrhdOljI1dRH6f16eQCtvwPkeoyl2uO1aNahU3xgdP6yeyunl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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: Wed, 06 Dec 2017 05:32:38 -0000 This is a multi-part message in MIME format. --------------A859F532C0E604CAEFE9C46A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12/5/2017 9:25 PM, Christian Huitema wrote: > I am looking at the change list on that draft: > >> C.1. Since draft-ietf-quic-transport-07 >> >> o Employ variable-length integer encodings throughout (#595) >> >> o Draining period can terminate early (#869) > I wish it were just that, but there were many more PR that went into draft 08. For example: > > * New PONG Frame, and new format for the PING frame, > > * New format for Transport Parameters, > > * New format for the packet header > > I am sure that I am still missing some. But the combination of all that is pretty large. Lots of code churn. See, it is late, and I missed the point about bidir/unidir flows. That's a pretty big change too... -- Christian Huitema --------------A859F532C0E604CAEFE9C46A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 12/5/2017 9:25 PM, Christian Huitema wrote:
I am looking at the change list on that draft:


C.1.  Since draft-ietf-quic-transport-07

  o  Employ variable-length integer encodings throughout (#595)

  o  Draining period can terminate early (#869)

I wish it were just that, but there were many more PR that went into draft 08. For example:

* New PONG Frame, and new format for the PING frame,

* New format for Transport Parameters,

* New format for the packet header

I am sure that I am still missing some. But the combination of all that is pretty large. Lots of code churn.
See, it is late, and I missed the point about bidir/unidir flows. That's a pretty big change too...

-- Christian Huitema
--------------A859F532C0E604CAEFE9C46A-- From nobody Tue Dec 5 23:19:29 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 A464E126FDC; Tue, 5 Dec 2017 23:19:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151254476463.30781.5690602790102287626@ietfa.amsl.com> Date: Tue, 05 Dec 2017 23:19:24 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-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, 06 Dec 2017 07:19:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-08.txt Pages : 37 Date : 2017-12-05 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-08 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-08 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 Wed Dec 6 01:31: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 3761D126E3A for ; Wed, 6 Dec 2017 01:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Lx_kU0HUIU4 for ; Wed, 6 Dec 2017 01:31:11 -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 268DF126D05 for ; Wed, 6 Dec 2017 01:31:10 -0800 (PST) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vB69V9hv022394 for ; Wed, 6 Dec 2017 09:31:09 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 09:31:08 +0000 From: Lucas Pardue CC: "quic@ietf.org" Subject: RE: I-D Action: draft-ietf-quic-http-08.txt Thread-Topic: I-D Action: draft-ietf-quic-http-08.txt Thread-Index: AQHTbmKe18yvzY5qNUyLoKElqy3CZqM2DKA8 Date: Wed, 6 Dec 2017 09:31:08 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAA0DE3@bgb01xud1012> References: <151254476463.30781.5690602790102287626@ietfa.amsl.com> In-Reply-To: <151254476463.30781.5690602790102287626@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23512.006 x-tm-as-result: No--8.535400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2017 09:31:13 -0000 I think the reference to QUIC-TRANSPORT is borked. Assume it was supposed t= o be draft 08 but says 00 (work in progress). ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of internet-drafts@ietf.org [i= nternet-drafts@ietf.org] Sent: 06 December 2017 07:19 To: i-d-announce@ietf.org Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-08.txt Pages : 37 Date : 2017-12-05 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-08 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-http-08 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Wed Dec 6 01:52: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 528E4126D05 for ; Wed, 6 Dec 2017 01:52:21 -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 wO-RupnKtAP7 for ; Wed, 6 Dec 2017 01:52:19 -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 834CC1242F7 for ; Wed, 6 Dec 2017 01:52:19 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 184so2171207oii.2 for ; Wed, 06 Dec 2017 01:52:19 -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=L8YbA7Jnqk/DY8KOClPWHWVrEsJZ4CXGlQ2+D4Cbc+k=; b=hDHNjsaOiixbUH5rVMVmqu++l9keTufSIto3HtRh9MCKxwDs1PADK7jkxRwIwd0gPF KR2sHH+jnPKEN6h7rNQxtfmY7dskcOcwJmlj5LOkLPsX28fmia0w1hU7PefTlOH3rybf iw8oOjc/CPSSoA+NzOEtwzIE7guelVqNRUoivQPCLoMHnaxsx/qQiATewneQrQg1wSgl qWKDxj51SCDKx1aKxFJdlHmYnPisIQpKPIoqP4CGKx0sO99m/IElrMlZro34W++1rnmZ E6yuu8U8/ihayd1C1bOBlUXq7kFNL8BfZ+hIBzGzZ2zR+n8krsJuLDsQ4F7Smy5TxLHs xRBA== 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=L8YbA7Jnqk/DY8KOClPWHWVrEsJZ4CXGlQ2+D4Cbc+k=; b=hmr85rg4zZ8U4dKjMW9sJ0RG1ER4RSIJvDgbBXMiwYBWCDLSgm2jsLVlyEjKPpLF8a jOG/gdqbp5ksQGl+Q1+Pe4Vey/4OhcPpk15aLNbv6EbjECf/TBposDi2NtA0Y3VXAT+u isjEk9FbWjcRLhuagtZ/a5sjRUS5srwedrgboiEU+mZnVJ4KF/ooImSk0l1qWdYL0/HQ y5Ul0tTjqlkwcXIHuSi9f5awALGg++qqjqTp+qN/ITPSVrJ5No0Qvkkb9Y3Z0m8kbtiF S2tiiReCnuWhkbbz+4925uxHpEHTweuvLMaTntYY8oJfE630Y1ja1RptkiSaYRYRZWyz J0fA== X-Gm-Message-State: AJaThX4t0x8FkbvMis3SpzTD5KcpzZm/BqmVe5xL8wS2UuvN84cFl3vx WiNicEKfSczf3JjtbjDXB++Y4vViAlFZdixAbdggGS51 X-Google-Smtp-Source: AGs4zMaWjR4E8tdxxqHoynvrFM6YfBvT1Lh0OQzpliTustkwYMxkyRrP1OMdBfVUipAXCOthdffd+GIMZ+EMLKrtMQM= X-Received: by 10.202.166.206 with SMTP id t75mr19776381oij.28.1512553938582; Wed, 06 Dec 2017 01:52:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Wed, 6 Dec 2017 01:52:18 -0800 (PST) In-Reply-To: References: <151252372918.30817.13458599568535139420@ietfa.amsl.com> <7d48c0af-1606-25e9-ba17-7d0ec160a6f3@huitema.net> From: Martin Thomson Date: Wed, 6 Dec 2017 20:52:18 +1100 Message-ID: Subject: Re: I-D Action: draft-ietf-quic-transport-08.txt To: Christian Huitema Cc: 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, 06 Dec 2017 09:52:21 -0000 The list is here: https://github.com/quicwg/base-drafts/pull/993 On Wed, Dec 6, 2017 at 4:32 PM, Christian Huitema wrote: > > > On 12/5/2017 9:25 PM, Christian Huitema wrote: > > I am looking at the change list on that draft: > > C.1. Since draft-ietf-quic-transport-07 > > o Employ variable-length integer encodings throughout (#595) > > o Draining period can terminate early (#869) > > I wish it were just that, but there were many more PR that went into draft > 08. For example: > > * New PONG Frame, and new format for the PING frame, > > * New format for Transport Parameters, > > * New format for the packet header > > I am sure that I am still missing some. But the combination of all that is > pretty large. Lots of code churn. > > See, it is late, and I missed the point about bidir/unidir flows. That's a > pretty big change too... > > -- Christian Huitema From nobody Wed Dec 6 01:56: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 3242312726E for ; Wed, 6 Dec 2017 01:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNCtgD6VFCeP for ; Wed, 6 Dec 2017 01:56:15 -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 EAD81126D05 for ; Wed, 6 Dec 2017 01:56:14 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id d27so2850429ote.11 for ; Wed, 06 Dec 2017 01:56:14 -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=MLWHOFlmPLQfCiRbt42Qy7H3W+BRmulrgqk7kWmc/xg=; b=d1Kckcwdh3efg5/ddyiQWd74PLuFlrPoR5GEpdBljW74ecH1G7N6xCD0bWo/tCeD0s ceYUMKmkZjqfYPwU46KhMbVXqc+0J91EdyCuqmLxTm39973YnvFx8SZJEXp78d4VV9h1 Q8N172TYKZABSyT0ekYcPUUoABnJRd/ASh/B7y0UGX0vnSVyDS4sWn2UpnDLos/1Kcm3 EUnq3Sh5/qAaF7unr1GgqEuyoPOY0SE7ulNNER//3gOlN3IdPQXtBJspxbi6X6IET44o cRFzBQRWgxw91sKJHbNfFhxAlP2R1Lgyw2fBDniJX0CNNwHl0eBcX9rK+3vY9NQam1za vJQA== 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=MLWHOFlmPLQfCiRbt42Qy7H3W+BRmulrgqk7kWmc/xg=; b=g19ecKsMk7swD2Gel3H3w50lszGfptOTQNvhWCytCFw+aNa6jw+l0vq4CuSBMqYhna OvxZRTEx1/2794csROnoBtJkpC2SEhTwM5Z0Xx/GTDAPP7qPYGA84OJnRJL+k61MpDHf ygj2Wjq8V64qhTw9vZTkrLen13CvPChNeB2V33MHp2vUHXmZsHbb+NAVytYML7QSMbX4 5kpvdewyQxvJI2HXKuWTV2DqqeZBAOSxhQ5iL97p0BFLwFPJ/apc2VKmdkQltmlrKt6p i+G4w+wBb7HGYVIHqAbmUKLJJycHnMN22tk0ikTKbLLRq1xcTpaCslgo+uieHcvKeuod pagg== X-Gm-Message-State: AJaThX4uVaYSjEytO9D0egG0FHk/tkF4LOG/UXmAIJgkR7zOdu9d528I u2XlyCfe6H9iS6l+Nqj5lPQPAPvsIrxT3pRt/Lc= X-Google-Smtp-Source: AGs4zMaUIs6NyukHmn4JkUPDQ0na31IvQVXVgdqQJlRgRLhbo7uP///ZLcMvM/q6bmjLIXkABkmA0E+gtO3SVgPFfEs= X-Received: by 10.157.88.141 with SMTP id x13mr20751886otg.175.1512554174216; Wed, 06 Dec 2017 01:56:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Wed, 6 Dec 2017 01:56:13 -0800 (PST) In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAA0DE3@bgb01xud1012> References: <151254476463.30781.5690602790102287626@ietfa.amsl.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAA0DE3@bgb01xud1012> From: Martin Thomson Date: Wed, 6 Dec 2017 20:56:13 +1100 Message-ID: Subject: Re: I-D Action: draft-ietf-quic-http-08.txt To: Lucas Pardue 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: Wed, 06 Dec 2017 09:56:17 -0000 A tooling issue, and my fault. It shouldn't happen again. On Wed, Dec 6, 2017 at 8:31 PM, Lucas Pardue wrote: > I think the reference to QUIC-TRANSPORT is borked. Assume it was supposed to be draft 08 but says 00 (work in progress). > ________________________________________ > From: QUIC [quic-bounces@ietf.org] on behalf of internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: 06 December 2017 07:19 > To: i-d-announce@ietf.org > Cc: quic@ietf.org > Subject: I-D Action: draft-ietf-quic-http-08.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the QUIC WG of the IETF. > > Title : Hypertext Transfer Protocol (HTTP) over QUIC > Author : Mike Bishop > Filename : draft-ietf-quic-http-08.txt > Pages : 37 > Date : 2017-12-05 > > 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 are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-quic-http-08 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-08 > > > 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/ > > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > ----------------------------- > From nobody Wed Dec 6 02:45: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 AFE4912969E for ; Wed, 6 Dec 2017 02:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OlpycIk-46-b for ; Wed, 6 Dec 2017 02:45:02 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D39BC129601 for ; Wed, 6 Dec 2017 02:45:01 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C23051132B51 for ; Wed, 6 Dec 2017 10:44:57 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 6 Dec 2017 10:44:59 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 18:44:53 +0800 From: Roni Even To: Martin Thomson , QUIC WG Subject: RE: Invariants draft Thread-Topic: Invariants draft Thread-Index: AQHTalo+zYouD4oB90a4uPhl78f75aM2KBwQ Date: Wed, 6 Dec 2017 10:44:54 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD851F75@DGGEMM506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2017 10:45:04 -0000 SGksDQpJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IG5lZWRzIHNvbWUgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB3aHkgdGhlc2UgZmllbGRzIGFyZSBpbnZhcmlhbnRzLg0KRm9yIGV4YW1wbGUsIHdl IGNhbiBoYXZlIGEgbmV3IHZlcnNpb24gd2l0aCBhIG1lc3NhZ2UgdHlwZSB0aGF0IHdpbGwgbWVh biB0aGF0IHRoZSBoZWFkZXIgZm9ybWF0IGZyb20gdGhlIG5leHQgbWVzc2FnZSBjaGFuZ2VzIGFu ZCB0aGUgY29ubmVjdGlvbiBJRCB3aWxsIGJlIGluIGEgZGlmZmVyZW50IHBvc2l0aW9uIGZyb20g dGhlIG5leHQgbWVzc2FnZSB3aXRoIGhpZ2hlciBwYWNrZXQgbnVtYmVyLiAgSSBhc3N1bWUgdGhh dCB0aGlzIGlzIG5vdCBzb21ldGhpbmcgd2Ugd2FudCBpZiB0aGVyZSBpcyBhIG5lZWQgdG8gc3Vw cG9ydCByb3V0aW5nIGJhc2VkIG9uIGNvbm5lY3Rpb24gSUQgYnkgaW50ZXJtZWRpYXJ5IHdobyB3 aWxsIG5vdCBzdXBwb3J0IHRoaXMgbmV3IHZlcnNpb24uIFNvIGlmIHJvdXRpbmcgc3VwcG9ydCBp cyBtYW5kYXRvcnkgaXQgd2lsbCBiZSBnb29kIHRvIG1lbnRpb24gaXQgaW4gdGhpcyBkb2N1bWVu dC4NCg0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFVSUMg W21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNv bg0KPiBTZW50OiDXmdeV153CoNeVIDAxINeT16bXnteR16ggMjAxNyAwNjoxMA0KPiBUbzogUVVJ QyBXRw0KPiBTdWJqZWN0OiBJbnZhcmlhbnRzIGRyYWZ0DQo+IA0KPiBJJ3ZlIGp1c3Qgc3VibWl0 dGVkIGEgcGVyc29uYWwgZHJhZnQgdGhhdCBkZXNjcmliZXMgdGhlIGludmFyaWFudHMgdGhhdCBJ IHRoaW5rDQo+IHdlIGFncmVlZCB0byBpbiBTaW5nYXBvcmUuDQo+IA0KPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRob21zb24tcXVpYy1pbnZhcmlhbnRzDQo+ IA0KPiBUaGlzIGlzIGp1c3QgbWUgZm9yIHRoZSBtb21lbnQgKHRob3VnaCBKYW5hIGFuZCBNaWtl IHdlcmUgdmVyeSBoZWxwZnVsIGluDQo+IHJldmlld2luZyBhbiBldmVuIGRyYWZ0aWVyIGRyYWZ0 KS4gIEl0IGFsc28gYXNzdW1lcyBhIGZldyB0aGluZ3MgYWJvdXQgdGhlDQo+IGN1cnJlbnQgZHJh ZnRzIHRoYXQgYXJlbid0IHlldCB0cnVlLCBhbmQgbWF5IG5vdCBldmVuIGJlY29tZSB0cnVlLiAg RG9uJ3QNCj4gZm9jdXMgdG9vIG11Y2ggb24gdGhlIHNwZWNpZmljIGNvbnRlbnQgb2Ygd2hhdCBp cyBpbiBvciBvdXQsIGJlY2F1c2UgdGhhdCBzb3J0DQo+IG9mIGRldGFpbCBpcyBlYXN5IHRvIGZp eC4NCj4gDQo+IE1vcmUgdGhhbiBjb250ZW50LCBJJ2QgbGlrZSB0byBjb25jZW50cmF0ZSBvbiB0 aGUgZ2VuZXJhbCBhcHByb2FjaCBhbmQNCj4gc2NvcGUuICBNeSBob3BlIGlzIHRoYXQgd2UgY2Fu IGFncmVlIHRoYXQgdGhvc2UgYXJlIG1vcmUgb3IgbGVzcyBjb3JyZWN0Lg0KPiBBbmQgdGhlbiBh ZG9wdCB0aGUgZHJhZnQuICBBIGRyYWZ0IGxpa2UgdGhpcyBzaG91bGQgaGVscCBhZGRyZXNzIHF1 ZXN0aW9ucw0KPiBwZW9wbGUgaGF2ZSBiZWVuIGFza2luZyBhYm91dCB3aGF0IGNhbiBhbmQgY2Fu bm90IGNoYW5nZSBiZXR3ZWVuIFFVSUMNCj4gdmVyc2lvbnMuDQoNCg== From nobody Wed Dec 6 03:18: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 62AF8128CFF for ; Wed, 6 Dec 2017 03:18:14 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg3lxjbSY2Tq for ; Wed, 6 Dec 2017 03:18:08 -0800 (PST) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.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 F32EF128961 for ; Wed, 6 Dec 2017 03:18:07 -0800 (PST) Received: from BGB01XI1002.national.core.bbc.co.uk ([10.184.50.52]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vB6BI5Mx015493; Wed, 6 Dec 2017 11:18:05 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1002.national.core.bbc.co.uk ([10.184.50.52]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 11:18:02 +0000 From: Lucas Pardue To: Martin Thomson CC: "quic@ietf.org" Subject: RE: I-D Action: draft-ietf-quic-http-08.txt Thread-Topic: I-D Action: draft-ietf-quic-http-08.txt Thread-Index: AQHTbmKe18yvzY5qNUyLoKElqy3CZqM2DKA8gAAHgICAABacUA== Date: Wed, 6 Dec 2017 11:18:01 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAA0E6A@bgb01xud1012> References: <151254476463.30781.5690602790102287626@ietfa.amsl.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAA0DE3@bgb01xud1012> 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.213] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23512.006 x-tm-as-result: No--22.377700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2017 11:18:14 -0000 SGkgTWFydGluLA0KDQpHcmVhdCB0aGFua3MuIE5vdCBhIGh1Z2UgcHJvYmxlbSBidXQgZ29vZCB0 byBrbm93IGl0IGNhbiBiZSBhZGRyZXNzZWQsIEkgd29uZGVyIGhvdyBtYW55IGRyYWZ0IHZlcnNp b25zIHRoZXJlJ2xsIGJlIDspDQoNCkx1Y2FzDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b21dDQo+IFNlbnQ6IDA2IERlY2VtYmVyIDIwMTcgMDk6NTYNCj4gVG86IEx1Y2FzIFBhcmR1ZSA8 THVjYXMuUGFyZHVlQGJiYy5jby51az4NCj4gQ2M6IHF1aWNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcXVpYy1odHRwLTA4LnR4dA0KPg0KPiBBIHRvb2xp bmcgaXNzdWUsIGFuZCBteSBmYXVsdC4gIEl0IHNob3VsZG4ndCBoYXBwZW4gYWdhaW4uDQo+DQo+ IE9uIFdlZCwgRGVjIDYsIDIwMTcgYXQgODozMSBQTSwgTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJk dWVAYmJjLmNvLnVrPg0KPiB3cm90ZToNCj4gPiBJIHRoaW5rIHRoZSByZWZlcmVuY2UgdG8gUVVJ Qy1UUkFOU1BPUlQgaXMgYm9ya2VkLiBBc3N1bWUgaXQgd2FzDQo+IHN1cHBvc2VkIHRvIGJlIGRy YWZ0IDA4IGJ1dCBzYXlzIDAwICh3b3JrIGluIHByb2dyZXNzKS4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRnJvbTogUVVJQyBbcXVpYy1ib3VuY2Vz QGlldGYub3JnXSBvbiBiZWhhbGYgb2YNCj4gPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2lu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiBTZW50OiAwNiBEZWNlbWJlciAyMDE3IDA3OjE5 DQo+ID4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+IENjOiBxdWljQGlldGYub3JnDQo+ ID4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1xdWljLWh0dHAtMDgudHh0DQo+ID4N Cj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgUVVJQyBXRyBvZiB0aGUgSUVURi4NCj4gPg0KPiA+ICAgICAgICAgVGl0bGUg ICAgICAgICAgIDogSHlwZXJ0ZXh0IFRyYW5zZmVyIFByb3RvY29sIChIVFRQKSBvdmVyIFFVSUMN Cj4gPiAgICAgICAgIEF1dGhvciAgICAgICAgICA6IE1pa2UgQmlzaG9wDQo+ID4gICAgICAgICBG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXF1aWMtaHR0cC0wOC50eHQNCj4gPiAgICAgICAg IFBhZ2VzICAgICAgICAgICA6IDM3DQo+ID4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3 LTEyLTA1DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBUaGUgUVVJQyB0cmFuc3BvcnQgcHJv dG9jb2wgaGFzIHNldmVyYWwgZmVhdHVyZXMgdGhhdCBhcmUgZGVzaXJhYmxlDQo+ID4gICAgaW4g YSB0cmFuc3BvcnQgZm9yIEhUVFAsIHN1Y2ggYXMgc3RyZWFtIG11bHRpcGxleGluZywgcGVyLXN0 cmVhbSBmbG93DQo+ID4gICAgY29udHJvbCwgYW5kIGxvdy1sYXRlbmN5IGNvbm5lY3Rpb24gZXN0 YWJsaXNobWVudC4gIFRoaXMgZG9jdW1lbnQNCj4gPiAgICBkZXNjcmliZXMgYSBtYXBwaW5nIG9m IEhUVFAgc2VtYW50aWNzIG92ZXIgUVVJQy4gIFRoaXMgZG9jdW1lbnQgYWxzbw0KPiA+ICAgIGlk ZW50aWZpZXMgSFRUUC8yIGZlYXR1cmVzIHRoYXQgYXJlIHN1YnN1bWVkIGJ5IFFVSUMsIGFuZCBk ZXNjcmliZXMNCj4gPiAgICBob3cgSFRUUC8yIGV4dGVuc2lvbnMgY2FuIGJlIHBvcnRlZCB0byBR VUlDLg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig dGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXF1aWMtaHR0cC8NCj4gPg0KPiA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1xdWljLWh0dHAtMDgNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtcXVpYy1odHRwLTA4DQo+ID4NCj4gPiBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcXVpYy1odHRwLTA4DQo+ID4NCj4gPg0KPiA+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+ID4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ID4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBodHRwOi8vd3d3LmJiYy5jby51aw0KPiA+IFRoaXMgZS1t YWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWlu DQo+ID4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlIEJCQyB1 bmxlc3Mgc3BlY2lmaWNhbGx5DQo+IHN0YXRlZC4NCj4gPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBp dCBpbg0KPiA+IGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQo+ID4g RG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUNCj4gPiBpbmZvcm1hdGlvbiBpbiBhbnkg d2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQgYW5kIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4g aW1tZWRpYXRlbHkuDQo+ID4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFp bHMgc2VudCBvciByZWNlaXZlZC4NCj4gPiBGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWdu aWZ5IHlvdXIgY29uc2VudCB0byB0aGlzLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KaHR0cDovL3d3dy5i YmMuY28udWsNClRoaXMgZS1tYWlsIChhbmQgYW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRp YWwgYW5kDQptYXkgY29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3 cyBvZiB0aGUgQkJDIHVubGVzcyBzcGVjaWZpY2FsbHkgc3RhdGVkLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgaXQgaW4NCmVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQpE byBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZQ0KaW5mb3JtYXRpb24gaW4gYW55IHdheSBu b3IgYWN0IGluIHJlbGlhbmNlIG9uIGl0IGFuZCBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRl bHkuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBCQkMgbW9uaXRvcnMgZS1tYWlscw0Kc2VudCBvciBy ZWNlaXZlZC4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkgeW91ciBjb25zZW50 IHRvDQp0aGlzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Wed Dec 6 03:37: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 CC6D0126B7E; Wed, 6 Dec 2017 03:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 e8TsoTudzjBf; Wed, 6 Dec 2017 03:37:48 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 BF487124217; Wed, 6 Dec 2017 03:37:48 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E05ADDCA9BEFC; Wed, 6 Dec 2017 11:37:44 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 6 Dec 2017 11:37:46 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 19:37:25 +0800 From: Roni Even To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "quic@ietf.org" Subject: RE: I-D Action: draft-ietf-quic-transport-08.txt Thread-Topic: I-D Action: draft-ietf-quic-transport-08.txt Thread-Index: AQHTbjGbZ67KMM4pK0WjLbdJo68RlKM2MGVg Date: Wed, 6 Dec 2017 11:37:24 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD851FBE@DGGEMM506-MBS.china.huawei.com> References: <151252372918.30817.13458599568535139420@ietfa.amsl.com> In-Reply-To: <151252372918.30817.13458599568535139420@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 06 Dec 2017 11:37:57 -0000 SGksDQogSSBhbSB3b25kZXJpbmcgd2h5IGRpZCB5b3UgY2hhbmdlIHRoZSB0eXBlIGZpZWxkIHZh bHVlcyBmb3IgdGhlIHNob3J0IGhlYWRlci4gSSB3YXMgdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhh dCB0aGUgY2hhbmdlIHdhcyBvbmx5IGZvciB0aGUgbG9uZyBoZWFkZXIgLiBUaGlzIGNoYW5nZSB3 aWxsIG1ha2UgaXQgZGlmZmljdWx0IHRvIGFsbG9jYXRlIHRoZSBiaXRzIGZvciB0aGUgc3BpbiBi aXQuDQpUaGFua3MNClJvbmkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJu ZXQtDQo+IGRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiDXmdeV153CoNeTIDA2INeT16bXnteR16gg MjAxNyAwMzoyOQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBxdWljQGlldGYu b3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMDgu dHh0DQo+IA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBRVUlDIFdHIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBRVUlDOiBBIFVEUC1CYXNlZCBNdWx0aXBsZXhlZCBhbmQgU2VjdXJlIFRy YW5zcG9ydA0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEphbmEgSXllbmdhcg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIE1hcnRpbiBUaG9tc29uDQo+IAlGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTA4LnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDog OTUNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMTItMDUNCj4gDQo+IEFic3RyYWN0Og0KPiAg ICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIGNvcmUgb2YgdGhlIFFVSUMgdHJhbnNwb3J0IHBy b3RvY29sLiAgVGhpcw0KPiAgICBkb2N1bWVudCBkZXNjcmliZXMgY29ubmVjdGlvbiBlc3RhYmxp c2htZW50LCBwYWNrZXQgZm9ybWF0LA0KPiAgICBtdWx0aXBsZXhpbmcgYW5kIHJlbGlhYmlsaXR5 LiAgQWNjb21wYW55aW5nIGRvY3VtZW50cyBkZXNjcmliZSB0aGUNCj4gICAgY3J5cHRvZ3JhcGhp YyBoYW5kc2hha2UgYW5kIGxvc3MgZGV0ZWN0aW9uLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0Lw0KPiANCj4gVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0wOA0KPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQtMDgN Cj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcXVpYy10cmFu c3BvcnQtMDgNCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg== From nobody Wed Dec 6 04:19: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 6AC73127137 for ; Wed, 6 Dec 2017 04:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw_jqqTH6ZIy for ; Wed, 6 Dec 2017 04:19:32 -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 7E52512700F for ; Wed, 6 Dec 2017 04:19:24 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id o130so20241088itg.0 for ; Wed, 06 Dec 2017 04:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=AWP0CFIQPXg+/9O2ZeVvn+dglSRXZtgv5L7ry15CYd0=; b=Ix0F3DyDD4HL6CCMu/QQ9Wqvjn9ExB8pAmybvXkRbTo5bBJ3JYjmHkRjRyUEipxixP N4i9Zc1i/Ofg6jkc8EfNUCPmI3hWCxx8k5tRdH6OczH/WoAKRrchhqiTqmzmZZ8Xx/OX KUsv4ljlnJGesGI+yEb1LBe7E0B8hr0ajqMRx2WQxIrlsrgVlhzLYybuM2WPiGp1OsOl +Ylc1EeaEXQFlbqnVl6U1VN0s7pJIZiEBP2h9giR1uRzTPHljhWvfOZfUGOPlFo+PNGv SSTnxYwlIWejK9YcgPStfu26Z5YZey4tCafHlH9w9Mkja8YghryVTr3bFdZmRvN7wiwA DrNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=AWP0CFIQPXg+/9O2ZeVvn+dglSRXZtgv5L7ry15CYd0=; b=k0CH04e3Q6w3mExUfzXFgEB5rgTq8Gs4S/I4aZ6Z+eywjeGpG2TgVU6KaZSaY5tLye PEtzW2ertq7nfjVX2dXjUA0S2T5UZ6gGEJvzTDAjR7VvJXo4akvzD9UVwBqXy1bSzeUP ZyyZMiLp0gsPq2ahJMiEhjai3BH5rJ1+MofllRMNFxxTw1bm7Gn3GoBGQ4kcrU7BhO1G QCRP+m1nmVSDBwLtJlccNwtGAfJ1B8B4kH0BmjIy+n01pmkiql6tvXOpg27T/dCE1aGA ZgcHQUc1jllt6q+QAOjzEN1Q86uWOdqQyO13K0cdKTMe7gMry8+7dNqqq9eb6Y7DAMp/ kcsQ== X-Gm-Message-State: AJaThX4TIMOqZviUygMhY7LGIgq5eJoqlmDGLAK5cukY+jX/m4xJiC47 y7HCmkF68ZGtLNMuljIOVYM5VQycmKh78yHrHRc= X-Google-Smtp-Source: AGs4zMaqXgVLCRbMsOAcq1+Oez4IsE23MhFQNYTtrA1ljIPx0uKvDSq5IXE1sdt5aZXnsBUBEn+2OnA129hPDEdiD0Y= X-Received: by 10.36.0.209 with SMTP id 200mr22746979ita.55.1512562763852; Wed, 06 Dec 2017 04:19:23 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Dec 2017 04:19:22 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Dec 2017 04:19:22 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: Martin Thomson Cc: Jana Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c140883d7151055faaf648" 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, 06 Dec 2017 12:19:34 -0000 --001a11c140883d7151055faaf648 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 6 December 2017 at 01.06.28, Martin Thomson (martin.thomson@gmail.com) wrote: On Wed, Dec 6, 2017 at 6:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I really would like a QUIC version that only depends on AES, curve25519 > (and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoid > heavy TLS libraries, but this is still possible with a custom QUIC version. Apart from the OpenSSH part, this is all possible right now with a profile of TLS. (I guess you mean raw public keys without X.509). All of what you describe is negotiable in TLS. You might not interoperate with many implementations, but it is possible, especially if you don't care for much interoperability. The biggest interoperability losses are where you go from X.509 to raw public keys (that is, RFC 7250), but Ed25519 is also only starting to be implemented. That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 signatures which is the heavy part (RFC8017) and the draft does not appear to make this negotiable from what I can tell. If it allowed Ed25519 only with X25519 Key Exchange, the only big issue would be the certificate format. https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1 A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748 ]. As to Raw vs OpenSSH I will have to study the details further. Getting rid of DER would be very nice, but it can be overcome, but there is more to it. One part is the file/blob format, another is the metadata such as domain and expiration date, and the third is the tooling around it. OpenSSH has simple tooling and it can also be re-implemented standalone with just an Ed/X25519 library and simple blob parser/printer (I can open source one if anyone is interested). The alternative is to deal with OpenSSL tools and rather convoluted CA mechanisms and possibly trust chains. But I do acknowledge that the public internet evolves around these types of certificates and that this is unlikely to change. --001a11c140883d7151055faaf648 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgen= sen


On 6 December 2017 at 0= 1.06.28, Martin Thomson (martin= .thomson@gmail.com) wrote:

On Wed, Dec 6, 2017 at 6:13 AM, Mikke= l Fahn=C3=B8e J=C3=B8rgensen=C2=A0
<mikkelfj@gmail.com>= ; wrote:=C2=A0
> I reall= y would like a QUIC version that only depends on AES, curve25519=C2=A0
> (and/or possibly salsa/pol= y) and ed25519 OpenSSH keys and certs to avoid=C2=A0
> heavy TLS libraries, but this is still possi= ble with a custom QUIC version.=C2=A0=

Apart from the OpenSSH part, this is all possible right now = with a=C2=A0
profile of TLS= . (I guess you mean raw public keys without X.509). All=C2=A0
of what you describe is negotiable in TL= S.=C2=A0

You might not = interoperate with many implementations, but it is=C2=A0
possible, especially if you don't care for= much interoperability. The=C2=A0
biggest interoperability losses are where you go from X.509 to raw=C2=A0
public keys (that is, = RFC 7250), but Ed25519 is also only starting to=C2=A0
be implemented.=C2=A0

That is good to = hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 signatures which= is the heavy part (RFC8017) and the draft does not appear to make this neg= otiable from what I can tell. If it allowed Ed25519 only with X25519 Key Ex= change, the only big issue would be the certificate format.

https:= //tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1

A TLS-compliant application MUST support digital signatures wit=
h
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

As to Raw vs OpenSSH I will have to study the detai= ls further. Getting rid of DER would be very nice, but it can be overcome, = but there is more to it. One part is the file/blob format, another is the m= etadata such as domain and expiration date, and the third is the tooling ar= ound it. OpenSSH has simple tooling and it can also be re-implemented stand= alone with just an Ed/X25519 library and simple blob parser/printer (I can = open source one if anyone is interested). The alternative is to deal with O= penSSL tools and rather convoluted CA mechanisms and possibly trust chains.= But I do acknowledge that the public internet evolves around these types o= f certificates and that this is unlikely to change.


--001a11c140883d7151055faaf648-- From nobody Wed Dec 6 04:21: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 D3BF1126B7E for ; Wed, 6 Dec 2017 04:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE_cPyTPXZ0A for ; Wed, 6 Dec 2017 04:21:06 -0800 (PST) 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 F1FCE124D6C for ; Wed, 6 Dec 2017 04:21:05 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id d137so6847772itc.2 for ; Wed, 06 Dec 2017 04:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=E297cjbtPZOoOOkn1QLMZ/BWIEn4Pb05mcVW1MeckC4=; b=oydRI4xhyVM+wOp1gBqdbVFxtce4NWrw5QLsZJIgI9buVdemLOOP3zNjhof5QD0iMh 4UboLHxxRIRm+dqC0fVoW72VZli4wrKI/J2psLRcXZ81qCK1OWOG8J286OYcHv2ljlId OQ1vIZNnTxxE3X2x0/5dHKaJle7SypboZAhKgox/uxmRNcgj4KLRHdR2DLZeNEyneJxn aHoYgXkexjgl15yL0m52GBP3tY3SH2KDO4wzzRnGcF2886syjRD7aJMPE+cg4znChWig nFrw+6IS31yVnqSf6DQE1NqWrg3fb95qYYSPp2Q6NpYlM3FuB1RlWnGFggRXnDB+2VPQ wCkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=E297cjbtPZOoOOkn1QLMZ/BWIEn4Pb05mcVW1MeckC4=; b=ARt+3FuJ6XAGUeaxQx8CK64xnG22Ek3MBmkS7mWDUOjyDgtdcxVRhRuEjRZRo5nAbn 8i5BnRyGppZmDsCcl3naNzn5WHewnREkTQaFpaBOT+NxRdrdwQ6NaLh9PlagJn2o3Wo1 ob0gpQs6PbytMCIKBgX8+iXfM+sAcw30lLEE9f4hnmWDA4WM/hy4/UMCmszlTcRk7nQz /Ntgqlcn6Ie+A5NwZYwuOlU+wzxuoaR6GWBsZKO2LdH/xDtzrTRSaaAG9a5PiHI1/p0X GYC4QF28WqymTDUZEqnYcOee14c3ZNfKFtP9W/yhW8cfIxMGrlVTiuM7JokFxLFY/ULb 4UTg== X-Gm-Message-State: AKGB3mIyYEXrC4R+ehe5N2eZ+wctZXJwaEzt6iQ+f9ZlJTosXaymGc7J sZlOwDyVFFLCccyjYquS0jVHVnvuLxQjrLCd9Zilrw== X-Google-Smtp-Source: AGs4zMb4+tj5Ch2JHM68DZOWKDkjZCqE1tF1vcOrNf3cU8vaWHrA3naAnt6M11+4iE+4EcdJIdT5zYvVZNjRDTRgXAo= X-Received: by 10.36.25.20 with SMTP id b20mr23573410itb.31.1512562865326; Wed, 06 Dec 2017 04:21:05 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Dec 2017 04:21:04 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Dec 2017 04:21:04 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: Martin Thomson Cc: Jana Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114409d249d09f055faafc0d" 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, 06 Dec 2017 12:21:08 -0000 --001a114409d249d09f055faafc0d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That mail came out strange, but see inline comments in previous mail, it is not empty. On 6 December 2017 at 13.19.22, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 6 December 2017 at 01.06.28, Martin Thomson (martin.thomson@gmail.com) wrote: On Wed, Dec 6, 2017 at 6:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I really would like a QUIC version that only depends on AES, curve25519 > (and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoid > heavy TLS libraries, but this is still possible with a custom QUIC version. Apart from the OpenSSH part, this is all possible right now with a profile of TLS. (I guess you mean raw public keys without X.509). All of what you describe is negotiable in TLS. You might not interoperate with many implementations, but it is possible, especially if you don't care for much interoperability. The biggest interoperability losses are where you go from X.509 to raw public keys (that is, RFC 7250), but Ed25519 is also only starting to be implemented. That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 signatures which is the heavy part (RFC8017) and the draft does not appear to make this negotiable from what I can tell. If it allowed Ed25519 only with X25519 Key Exchange, the only big issue would be the certificate format. https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1 A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748 ]. As to Raw vs OpenSSH I will have to study the details further. Getting rid of DER would be very nice, but it can be overcome, but there is more to it. One part is the file/blob format, another is the metadata such as domain and expiration date, and the third is the tooling around it. OpenSSH has simple tooling and it can also be re-implemented standalone with just an Ed/X25519 library and simple blob parser/printer (I can open source one if anyone is interested). The alternative is to deal with OpenSSL tools and rather convoluted CA mechanisms and possibly trust chains. But I do acknowledge that the public internet evolves around these types of certificates and that this is unlikely to change. --001a114409d249d09f055faafc0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = That mail came out s= trange, but see inline comments in previous mail, it is not empty.


On 6 December 2017 at 13.19.22, Mikkel Fahn=C3=B8e J=C3=B8r= gensen (mikkelfj@gmail.com) wrote= :



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


On 6 December 2017 at 01.06.28, Martin Thomson (martin.thomson@gmail.c= om) wrote:

On Wed, Dec 6, 2017 at 6:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen=C2=A0
<mikkelfj@gmail.com> wrote:= =C2=A0
> I really would like a QUIC version that only depends on AES, curve25519=C2=A0
> (and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoid=C2=A0
> heavy TLS libraries, but this is still possible with a custom QUIC version.=C2=A0

Apart from the OpenSSH part, this is all possible right now with a=C2=A0
profile of TLS. (I guess you mean raw public keys without X.509). All=C2=A0
of what you describe is negotiable in TLS.=C2=A0

You might not interoperate with many implementations, but it is=C2=A0
possible, especially if you don't care for much interoperability. The=C2=A0
biggest interoperability losses are where you go from X.509 to raw=C2=A0
public keys (that is, RFC 7250), but Ed25519 is also only starting to=C2=A0
be implemented.=C2=A0

That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 signatures which is the heavy part (RFC8017) and the draft does not appear to make this negotiable from what I can tell. If it allowed Ed25519 only with X25519 Key Exchange, the only big issue would be the certificate format.

https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1

A TLS-compliant application MUST support digital sign=
atures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

As to Raw vs OpenSSH I will have to study the details further. Getting rid of DER would be very nice, but it can be overcome, but there is more to it. One part is the file/blob format, another is the metadata such as domain and expiration date, and the third is the tooling around it. OpenSSH has simple tooling and it can also be re-implemented standalone with just an Ed/X25519 library and simple blob parser/printer (I can open source one if anyone is interested). The alternative is to deal with OpenSSL tools and rather convoluted CA mechanisms and possibly trust chains. But I do acknowledge that the public internet evolves around these types of certificates and that this is unlikely to change.


--001a114409d249d09f055faafc0d-- From nobody Wed Dec 6 06:20: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 E49A41270FC for ; Wed, 6 Dec 2017 06:20:43 -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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 KPjtuFshW3_E for ; Wed, 6 Dec 2017 06:20:42 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 0DA1B1241FC for ; Wed, 6 Dec 2017 06:20:42 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id 184so1595843ybw.12 for ; Wed, 06 Dec 2017 06:20:42 -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=4VAMoXbwby1mG6jsJjVA4nqqcSp1RE95OmCR8jenoqM=; b=HZHhwHM7GDiVxaZ/xu8CkmzGV3UuZLa0Y5N918CNM1S2Lr4EH337qlm9SoloemHD2I QQGCW3sQ3VcaYTXqoznE27f9+swzIiVXWt9eiYSGldNBVDgtaNl8Ix9IFH5BExhvnxcv 8MnFwClKUlKxslqhrZX/dMyttesFMBpodWWCEu/XXaQt8hOCVza1dVzXTzLJ7ry9mUgW GSFXxu4keaw/ZUQSVjPVJM3bXjsfSUnbDgW0Og1AIZ0y/elVvUdcYf5dvD2toYeE3pEw IEIKBMyLwd/kJXolIa2ST/PIko5HbuXrzXwHZHfvA9hTH3ec26zqUD9J9m+kTEcQPl9W KQQQ== 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=4VAMoXbwby1mG6jsJjVA4nqqcSp1RE95OmCR8jenoqM=; b=L08vK1r5wYG/euFm9gAuugS7wocs2w8B6s2vGz/0xBJSOs6o+iFJDSXRyCG1aBNoEK L6ZorMhdgEnEtoq5VTbSiBXSFTWRSc4a5ajUzAgzospO3nKXC5+gcHb0tFBdvUcu6LzI ttR8ydEcnHEkTAbJBeyTQVz9KMf+qrLktQLsAai/bF0ckED2BAJFoYoZfKRI6xU7GWJ0 5Lj/1AoCf4datMIE6GIou9LWvHnz+Up/zZmaMacaRR9DnMdcehh9aNa6DY/If1RiKFeA VN0JuOOlNze60pcbxWM5IulKVEJ7Bt5oNnGQ87UNMtQjpM/7Ce7dwnh6KPP8WFeRLOSx li6g== X-Gm-Message-State: AJaThX4nAbjXnBtSmcdT+ppN6saU9E8c9HEIAGsclw6baWHJSi73NgN0 RvA4xyRvjdL5AgogHBnpQ3/QvkkmTiyE2Yu6Yqf4Lw== X-Google-Smtp-Source: AGs4zMYQAlDLhls+EkFqnUf25MrTi16buaAbVRmTyqMKoDQa3Ovyoy7F1GRLG60AfoviMULjIhGMiEF1eTAU+agVzhk= X-Received: by 10.37.16.134 with SMTP id 128mr15795873ybq.474.1512570041234; Wed, 06 Dec 2017 06:20:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 06:20:00 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 6 Dec 2017 06:20:00 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , Jana Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c0125a019122055faca8d5" 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, 06 Dec 2017 14:20:44 -0000 --001a11c0125a019122055faca8d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 6, 2017 at 4:19 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 6 December 2017 at 01.06.28, Martin Thomson (martin.thomson@gmail.com) > wrote: > > On Wed, Dec 6, 2017 at 6:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > I really would like a QUIC version that only depends on AES, curve25519 > > (and/or possibly salsa/poly) and ed25519 OpenSSH keys and certs to avoi= d > > > heavy TLS libraries, but this is still possible with a custom QUIC > version. > > Apart from the OpenSSH part, this is all possible right now with a > profile of TLS. (I guess you mean raw public keys without X.509). All > of what you describe is negotiable in TLS. > > You might not interoperate with many implementations, but it is > possible, especially if you don't care for much interoperability. The > biggest interoperability losses are where you go from X.509 to raw > public keys (that is, RFC 7250), but Ed25519 is also only starting to > be implemented. > > That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS= 1 > signatures which is the heavy part (RFC8017) and the draft does not appea= r > to make this negotiable from what I can tell. > This is just an interop requirement. I.e., if you don't do this then you will not be able to talk to the large number of servers who have RSA only keys embedded in PKCS#1 certs. It's quite possible to just support Ed25519, and you say so using the signature_algorithms extension. Obviously, if you say that, then you will have a handshake failure with anyone without a suitable key, but in a closed world that's fine. IMO it would be better to advertise the usual TLS/QUIC versions and be officially non-compliant than have a new version that differed only along this axis. I imagine we could put in some weasel words if necessary about closed environments. Ironically, I just debugged a failure of this type. > If it allowed Ed25519 only with X25519 Key Exchange, the only big issue > would be the certificate format. > > https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1 > > A TLS-compliant application MUST support digital signatures with > rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for > CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A > TLS-compliant application MUST support key exchange with secp256r1 > (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748 ]. > > > As to Raw vs OpenSSH I will have to study the details further. Getting ri= d > of DER would be very nice, but it can be overcome, but there is more to i= t. > One part is the file/blob format, another is the metadata such as domain > and expiration date, and the third is the tooling around it. OpenSSH has > simple tooling and it can also be re-implemented standalone with just an > Ed/X25519 library and simple blob parser/printer (I can open source one i= f > anyone is interested). The alternative is to deal with OpenSSL tools and > rather convoluted CA mechanisms and possibly trust chains. But I do > acknowledge that the public internet evolves around these types of > certificates and that this is unlikely to change > I'm having trouble visualizing your environment here. Are you doing TOFU, in which case this is just an issue of transporting the keys, or are you actually operating some kind of CA system? In any case, it's also possible to add OpenSSH certificates to TLS (it's just a code point), but I would generally not be in favor of that unless it was really needed. -Ekr --001a11c0125a019122055faca8d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 6, 2017 at 4:19 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mi= kkelfj@gmail.com> wrote:

<= br>
Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 6 December 2017 at 01.06.28, Martin Thomson (= martin.thomso= n@gmail.com) wrote:

On Wed, Dec 6, 20= 17 at 6:13 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen=C2=A0
<mikkelfj@gmail.com> wrote:=C2=A0
> I really would like a QUIC version that only depends on AES, curv= e25519=C2= =A0
> (and/or possibly salsa/poly) and ed25519 OpenSSH keys an= d certs to avoid=C2=A0
> heavy TLS libraries, but this is still possible= with a custom QUIC version.=C2=A0

Apart from the OpenSSH part, this is= all possible right now with a=C2=A0
profile of TLS. (I guess you mean raw = public keys without X.509). All=C2=A0
of what you describe is negotiable in= TLS.=C2= =A0

You might not interoperate with many implementations, but= it is=C2= =A0
possible, especially if you don't care for much interoper= ability. The=C2=A0
biggest interoperability losses are where you go from X.= 509 to raw= =C2=A0
public keys (that is, RFC 7250), but Ed25519 is also only = starting to=C2=A0
be implemented.=C2=A0
<= /div>

That is good to hear, but I believe the TLS1.3-22 draft requi= res RSA PKCS1 signatures which is the heavy part (RFC8017) and the draft do= es not appear to make this negotiable from what I can tell.

This is just an interop requirement. I.e., if you don'= t do this then you will not be able to talk to the large number of servers = who have RSA only keys embedded in PKCS#1 certs. It's quite possible to= just support Ed25519, and you say so using the signature_algorithms extens= ion. Obviously, if you say that, then you will have a handshake failure wit= h anyone without a suitable key, but in a closed world that's fine. IMO= it would be better to advertise the usual TLS/QUIC versions and be officia= lly non-compliant than have a new version that differed only along this axi= s. I imagine we could put in some weasel words if necessary about closed en= vironments.

Ironically, I just debugged a failure = of this type.

=C2=A0

If it allowed Ed25519 only with X25519 Key Ex= change, the only big issue would be the certificate format.


=C2=A0

htt= ps://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-9.1<= /p>

A TLS-compliant application MUST s=
upport digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

As to Raw vs OpenSSH I will have to study the detai= ls further. Getting rid of DER would be very nice, but it can be overcome, = but there is more to it. One part is the file/blob format, another is the m= etadata such as domain and expiration date, and the third is the tooling ar= ound it. OpenSSH has simple tooling and it can also be re-implemented stand= alone with just an Ed/X25519 library and simple blob parser/printer (I can = open source one if anyone is interested). The alternative is to deal with O= penSSL tools and rather convoluted CA mechanisms and possibly trust chains.= But I do acknowledge that the public internet evolves around these types o= f certificates and that this is unlikely to change

I'm having trouble visualizing your environment here. Are you doing = TOFU, in which case this is just an issue of transporting the keys, or are = you actually operating some kind of CA system? In any case, it's also p= ossible to add OpenSSH certificates to TLS (it's just a code point), bu= t I would generally not be in favor of that unless it was really needed.

-Ekr


--001a11c0125a019122055faca8d5-- From nobody Wed Dec 6 07:25: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 344EE126DD9 for ; Wed, 6 Dec 2017 07:25:12 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRX-zkfi8BYp for ; Wed, 6 Dec 2017 07:25:10 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13090120725 for ; Wed, 6 Dec 2017 07:25:10 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id x129so3036107iod.13 for ; Wed, 06 Dec 2017 07:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=RsDzjZGFrxwM4Eni0bBHmxPLJG7XYXNvvrMSPU7W8Sk=; b=GI7pJQlstU/YfJpfM2GUQhlsA9GAO5Q86IWMRBlbOtSggNWgj1RuDFzr6yMFYAiXwo rseLDEwyW7AJtnLLFwYqB9QTLauAaisBwIs6AGveJWis/YAQHmcMTVZ6zWjV/7ZPXNRU jqJo5YCRNtqLV3SmK0wDXwehYL3kQEnKSMePRl+Ct3I4GG612QUeoSiXDie+9nO4tc4J IU5qcUOirio7u9tZWVR3Obq8MulEgULroHm9wos++m8qYpLAUjk9Et5e3GCUul6/i+ZF ammyKPwczQMqkGglVkDIQbGKOe6t9UdQMVtpBPa2BXqwmhWhSLhvvsX82Bs1jM/YQ2dX ilHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=RsDzjZGFrxwM4Eni0bBHmxPLJG7XYXNvvrMSPU7W8Sk=; b=gZmqQ+9YSdBoX9GYnOsDtPQeJGUDs4gDGIzjsQUn7tBDLwob0o6DF8/kQQSHGZs7w+ xbYBw3xXj3aRFNYnBnsl4a82xJWG+JvAWx7nmxnaFHXeZlbw+aI33Y5gboMj6wB2Ri5N P7QCi5PwrFSUjkps7HKPiJEXgTCCPMNJm5Ufr8klolZiTca6MHIZwWvapvXWO/pXMUx4 RDrbVO3cp/bGzVoqd9jrZTWCkvKyErq/e+pKeiA2Lk2pfBOB6iCu2SZuQ2+JauqqXVM1 9x+pzPVTKVoKIhNchqpVAoKBa54p/iB3pncaLmwzBrtncpyOFfldkeEjcHzrreAIakZp ZjBQ== X-Gm-Message-State: AJaThX5bONLGh8Z0a/Zzg/ThsIFkLGL9O+gjk4mefqI0IF/nIfEdrqk8 BoHu3yvnSpTZ3lRqBk2ydtDwT/7JRXx44IcxoWY= X-Google-Smtp-Source: AGs4zMZFaeCbEe8hqf8rq1CzFV1+186XrlxUADD94eRk8UPkvfmcTLXM+Oymf978PysPBwPsGvfRSugsTcscTmmFeKU= X-Received: by 10.107.9.223 with SMTP id 92mr32737452ioj.16.1512573909287; Wed, 06 Dec 2017 07:25:09 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Dec 2017 07:25:08 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Dec 2017 07:25:08 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: Eric Rescorla Cc: Martin Thomson , Jana Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113eca348f48af055fad8ef2" 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, 06 Dec 2017 15:25:12 -0000 --001a113eca348f48af055fad8ef2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Answers inline below That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 > signatures which is the heavy part (RFC8017) and the draft does not appea= r > to make this negotiable from what I can tell. > This is just an interop requirement. I.e., if you don't do this then you will not be able to talk to the large number of servers who have RSA only keys embedded in PKCS#1 certs. It's quite possible to just support Ed25519, and you say so using the signature_algorithms extension. Obviously, if you say that, then you will have a handshake failure with anyone without a suitable key, but in a closed world that's fine. IMO it would be better to advertise the usual TLS/QUIC versions and be officially non-compliant than have a new version that differed only along this axis. I imagine we could put in some weasel words if necessary about closed environments. That would be fine with me, it is just that MUST in TLS sec. 9.1 is a strong word, so you couldn=E2=80=99t really say you use TLS1.3 and hence no= t QUIC, unless some permission was granted towards this use case. As to Raw vs OpenSSH I will have to study the details further. Getting rid > of DER would be very nice, but it can be overcome, but there is more to i= t. > One part is the file/blob format, another is the metadata such as domain > and expiration date, and the third is the tooling around it. OpenSSH has > simple tooling and it can also be re-implemented standalone with just an > Ed/X25519 library and simple blob parser/printer (I can open source one i= f > anyone is interested). The alternative is to deal with OpenSSL tools and > rather convoluted CA mechanisms and possibly trust chains. But I do > acknowledge that the public internet evolves around these types of > certificates and that this is unlikely to change > I'm having trouble visualizing your environment here. Are you doing TOFU, in which case this is just an issue of transporting the keys, or are you actually operating some kind of CA system? In any case, it's also possible to add OpenSSH certificates to TLS (it's just a code point), but I would generally not be in favor of that unless it was really needed. The environment is not fully fleshed out but in summary it is about server to server peer networking with multiple levels of trust and satellite access. Satellites might be non-standard low resource systems. I do have CA in mind, but for simpler use cases TOFU (trust on first sight) pointing to an authorized_keys file is also a consideration. I want some very trusted central piece of software to create and sign certs that other parties trust in order to establish a peer to peer server network. Shamirs Shared Secret could be part of the setup. In this case the minimum complexity needed to implement a CA is desirable and OpenSSH/Ed25519 is close to that as a model even if not using OpenSSH software directly. In addition, external parties might want to join a sub-net or create their own compatible key management infrastructure. In this case OpenSSH tooling is much simpler to use than OpenSSL and something operators do regularly for SSH login. It is beneficial that some server software can be configured to accept such a user provided key. Notably users might feel better knowing a key is generated by a piece of software they know and trust. The above does not require that QUIC uses OpenSSH directly, just that there is a low-cost translation. The use of DNS based auth is not very useful when network addresses might be routed on overlay networks and/or having address that are not advertised by DNS, or when not having any meaningful address at all (e.g. content based routing). Even without SSH tooling, it is reasonably easy to implement custom tools based on the same concept when the underlying primitives are largely the same. Some of this is not directly applicable to QUIC because it operates trust at a higher level, but such a system must still manage the keys used by QUIC connections and it is preferable that all components can agree on the basic primitives. --001a113eca348f48af055fad8ef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Answers inline below=
=C2=A0
=
<= div class=3D"gmail_extra">

That is good to hear, but I believe the T= LS1.3-22 draft requires RSA PKCS1 signatures which is the heavy part (RFC80= 17) and the draft does not appear to make this negotiable from what I can t= ell.

This is just an interop requirement. I= .e., if you don't do this then you will not be able to talk to the larg= e number of servers who have RSA only keys embedded in PKCS#1 certs. It'= ;s quite possible to just support Ed25519, and you say so using the signatu= re_algorithms extension. Obviously, if you say that, then you will have a h= andshake failure with anyone without a suitable key, but in a closed world = that's fine. IMO it would be better to advertise the usual TLS/QUIC ver= sions and be officially non-compliant than have a new version that differed= only along this axis. I imagine we could put in some weasel words if neces= sary about closed environments.

That would be fine with me, it is just that MUST in TLS sec.= 9.1 is a strong word, so you couldn=E2=80=99t really say you use TLS1.3 an= d hence not QUIC, unless some permission was granted towards this use case.=

=

As to Raw vs OpenSSH I will have to = study the details further. Getting rid of DER would be very nice, but it ca= n be overcome, but there is more to it. One part is the file/blob format, a= nother is the metadata such as domain and expiration date, and the third is= the tooling around it. OpenSSH has simple tooling and it can also be re-im= plemented standalone with just an Ed/X25519 library and simple blob parser/= printer (I can open source one if anyone is interested). The alternative is= to deal with OpenSSL tools and rather convoluted CA mechanisms and possibl= y trust chains. But I do acknowledge that the public internet evolves aroun= d these types of certificates and that this is unlikely to change

=
I'm having trouble visualizing your environment here.= Are you doing TOFU, in which case this is just an issue of transporting th= e keys, or are you actually operating some kind of CA system? In any case, = it's also possible to add OpenSSH certificates to TLS (it's just a = code point), but I would generally not be in favor of that unless it was re= ally needed.

The enviro= nment is not fully fleshed out but in summary it is about server to server = peer networking with multiple levels of trust and satellite access. Satelli= tes might be non-standard low resource systems.

I do have CA in mind,= but for simpler use cases TOFU (trust on first sight) pointing to an autho= rized_keys file is also a consideration.

I want some very trusted cen= tral piece of software to create and sign certs that other parties trust in= order to establish a peer to peer server network. Shamirs Shared Secret co= uld be part of the setup. In this case the minimum complexity needed to imp= lement a CA is desirable and OpenSSH/Ed25519 is close to that as a model ev= en if not using OpenSSH software directly.

In addition, external part= ies might want to join a sub-net or create their own compatible key managem= ent infrastructure. In this case OpenSSH tooling is much simpler to use tha= n OpenSSL and something operators do regularly for SSH login. It is benefic= ial that some server software can be configured to accept such a user provi= ded key. Notably users might feel better knowing a key is generated by a pi= ece of software they know and trust.

The above does not require that = QUIC uses OpenSSH directly, just that there is a low-cost translation.

<= p>The use of DNS based auth is not very useful when network addresses might= be routed on overlay networks and/or having address that are not advertise= d by DNS, or when not having any meaningful address at all (e.g. content ba= sed routing). Even without SSH tooling, it is reasonably easy to implement = custom tools based on the same concept when the underlying primitives are l= argely the same.

Some of this is not directly applicable to QUIC beca= use it operates trust at a higher level, but such a system must still manag= e the keys used by QUIC connections and it is preferable that all component= s can agree on the basic primitives.

--001a113eca348f48af055fad8ef2-- From nobody Wed Dec 6 10:22: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 6EF9B126CD8 for ; Wed, 6 Dec 2017 10:22:02 -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 ChYyI5-jzFFn for ; Wed, 6 Dec 2017 10:22:00 -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 071F21241F5 for ; Wed, 6 Dec 2017 10:22:00 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id l7so1911464ywa.13 for ; Wed, 06 Dec 2017 10:21:59 -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=1CHgSnQDm5pHOwWQnbmpof5IoOCxADI7zwzU4XmURVo=; b=ISxW1JhJD/wMTtXeQKBWEZfbjtjHHy/wsACekQ4Num88NF7kTBYrks5aYU07S6eDrE /bAiT5jU9RPs492r/N/mUe73U0F1fYyJptahHPMrEv0iLjd/IYcbp6wSH+c/G0Q1BNOr QYX2AZpOhBDw+hcfcaa07X7v9FfbYO+fQkLyv3wjpFxNlF4OzWv6LEcchDmCOAqRWFH3 dmrlT5vXfPnboIAq+5y2MHG4Gl76TsAzZgkCU/9gh+JuVxavamLxjMIonIVKzFk+lP3k n8lUnaajpXe+XeIA084sjoOjh0zQ6i/PGwXzroB5tEaHhKZ8RsNo9hhEJ+hklkmV4H4J kXQQ== 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=1CHgSnQDm5pHOwWQnbmpof5IoOCxADI7zwzU4XmURVo=; b=Tgw1TK7dtqOdOe00/s+phJHsM354e5tQVFVarbgWQsUdBgCUiuGKrr+/iGcQoAZGVv A/9jZEbltOw8Nb0VxrWvp7wkiUqTZRwQ4wd6XOMv95bv+sHFD8T/lt8IQgROjWA2VVv4 2mliHrh453sGWqNzgE2X1HiG20XwtnSlvKTZqJRNp6HjzaSFca44axSf424UHR2atgp7 vcj9vQQnXpRni2DXGhtDyaIE4gGBlvZUqW7UlKZ/qi/YdTM4R2/khwuZVmQTND5JvbYP TMoLhXMiq9UpptoE9pc2Y6coZzyCwe1fdxgboD4faAN2Mbada59LeNt92NdRXI8/3QQn YH6Q== X-Gm-Message-State: AJaThX5STfwZJOENrn6nBpPnFzUA8UrI4iH6cPt2GScfF2tXzAV4SHj0 DS+BnflVJDWrOcLrF10hJDpwQCxDz6cEDVPoPnkSrw== X-Google-Smtp-Source: AGs4zMZlJMKHPe3gFRLNG21AXjV+HN8D1PHEm8g0ER1kHqk9xHf2GSg4AuFkpu3pXm7qpiTr4/Jy00lyZsNZbgeyE78= X-Received: by 10.129.87.210 with SMTP id l201mr16940816ywb.2.1512584519078; Wed, 06 Dec 2017 10:21:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 10:21:18 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 6 Dec 2017 10:21:18 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , Jana Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11457576f3eca1055fb006e2" 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, 06 Dec 2017 18:22:02 -0000 --001a11457576f3eca1055fb006e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 6, 2017 at 7:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Answers inline below > > > That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS= 1 >> signatures which is the heavy part (RFC8017) and the draft does not appe= ar >> to make this negotiable from what I can tell. >> > This is just an interop requirement. I.e., if you don't do this then you > will not be able to talk to the large number of servers who have RSA only > keys embedded in PKCS#1 certs. It's quite possible to just support Ed2551= 9, > and you say so using the signature_algorithms extension. Obviously, if yo= u > say that, then you will have a handshake failure with anyone without a > suitable key, but in a closed world that's fine. IMO it would be better t= o > advertise the usual TLS/QUIC versions and be officially non-compliant tha= n > have a new version that differed only along this axis. I imagine we could > put in some weasel words if necessary about closed environments. > > That would be fine with me, it is just that MUST in TLS sec. 9.1 is a > strong word, so you couldn=E2=80=99t really say you use TLS1.3 and hence = not QUIC, > unless some permission was granted towards this use case. > Well, you would be a nonconformant QUIC implementation. It's not like you're going to get arrested. > As to Raw vs OpenSSH I will have to study the details further. Getting ri= d >> of DER would be very nice, but it can be overcome, but there is more to = it. >> One part is the file/blob format, another is the metadata such as domain >> and expiration date, and the third is the tooling around it. OpenSSH has >> simple tooling and it can also be re-implemented standalone with just an >> Ed/X25519 library and simple blob parser/printer (I can open source one = if >> anyone is interested). The alternative is to deal with OpenSSL tools and >> rather convoluted CA mechanisms and possibly trust chains. But I do >> acknowledge that the public internet evolves around these types of >> certificates and that this is unlikely to change >> > I'm having trouble visualizing your environment here. Are you doing TOFU, > in which case this is just an issue of transporting the keys, or are you > actually operating some kind of CA system? In any case, it's also possibl= e > to add OpenSSH certificates to TLS (it's just a code point), but I would > generally not be in favor of that unless it was really needed. > > The environment is not fully fleshed out but in summary it is about serve= r > to server peer networking with multiple levels of trust and satellite > access. Satellites might be non-standard low resource systems. > > I do have CA in mind, but for simpler use cases TOFU (trust on first > sight) pointing to an authorized_keys file is also a consideration. > > I want some very trusted central piece of software to create and sign > certs that other parties trust in order to establish a peer to peer serve= r > network. Shamirs Shared Secret could be part of the setup. In this case t= he > minimum complexity needed to implement a CA is desirable and > OpenSSH/Ed25519 is close to that as a model even if not using OpenSSH > software directly. > > In addition, external parties might want to join a sub-net or create thei= r > own compatible key management infrastructure. In this case OpenSSH toolin= g > is much simpler to use than OpenSSL and something operators do regularly > for SSH login. It is beneficial that some server software can be configur= ed > to accept such a user provided key. Notably users might feel better knowi= ng > a key is generated by a piece of software they know and trust. > > The above does not require that QUIC uses OpenSSH directly, just that > there is a low-cost translation. > > The use of DNS based auth is not very useful when network addresses might > be routed on overlay networks and/or having address that are not advertis= ed > by DNS, or when not having any meaningful address at all (e.g. content > based routing). Even without SSH tooling, it is reasonably easy to > implement custom tools based on the same concept when the underlying > primitives are largely the same. > > Some of this is not directly applicable to QUIC because it operates trust > at a higher level, but such a system must still manage the keys used by > QUIC connections and it is preferable that all components can agree on th= e > basic primitives. > OK. Well, I'm generally not that enthusiastic about inventing cert formats, but there's no technical obstacle that I know of. -Ekr --001a11457576f3eca1055fb006e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 6, 2017 at 7:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mi= kkelfj@gmail.com> wrote:
Answers i= nline below
=C2=A0

That is good to hear, but I believe the TLS1.3= -22 draft requires RSA PKCS1 signatures which is the heavy part (RFC8017) a= nd the draft does not appear to make this negotiable from what I can tell.<= /p>

This is just an interop requirement. I.e., = if you don't do this then you will not be able to talk to the large num= ber of servers who have RSA only keys embedded in PKCS#1 certs. It's qu= ite possible to just support Ed25519, and you say so using the signature_al= gorithms extension. Obviously, if you say that, then you will have a handsh= ake failure with anyone without a suitable key, but in a closed world that&= #39;s fine. IMO it would be better to advertise the usual TLS/QUIC versions= and be officially non-compliant than have a new version that differed only= along this axis. I imagine we could put in some weasel words if necessary = about closed environments.

That would be fine with me, it is just that MUST in TLS se= c. 9.1 is a strong word, so you couldn=E2=80=99t really say you use TLS1.3 = and hence not QUIC, unless some permission was granted towards this use cas= e.


Well, you would be a nonconfor= mant QUIC implementation. It's not like you're going to get arreste= d.=C2=A0


=C2=A0

As to Raw vs OpenSSH I will have to study the details further. Getting = rid of DER would be very nice, but it can be overcome, but there is more to= it. One part is the file/blob format, another is the metadata such as doma= in and expiration date, and the third is the tooling around it. OpenSSH has= simple tooling and it can also be re-implemented standalone with just an E= d/X25519 library and simple blob parser/printer (I can open source one if a= nyone is interested). The alternative is to deal with OpenSSL tools and rat= her convoluted CA mechanisms and possibly trust chains. But I do acknowledg= e that the public internet evolves around these types of certificates and t= hat this is unlikely to change

I'm having tr= ouble visualizing your environment here. Are you doing TOFU, in which case = this is just an issue of transporting the keys, or are you actually operati= ng some kind of CA system? In any case, it's also possible to add OpenS= SH certificates to TLS (it's just a code point), but I would generally = not be in favor of that unless it was really needed.

The environment is not fully fleshed o= ut but in summary it is about server to server peer networking with multipl= e levels of trust and satellite access. Satellites might be non-standard lo= w resource systems.

I do have CA in mind, but for simpler use cases T= OFU (trust on first sight) pointing to an authorized_keys file is also a co= nsideration.

I want some very trusted central piece of software to cr= eate and sign certs that other parties trust in order to establish a peer t= o peer server network. Shamirs Shared Secret could be part of the setup. In= this case the minimum complexity needed to implement a CA is desirable and= OpenSSH/Ed25519 is close to that as a model even if not using OpenSSH soft= ware directly.

In addition, external parties might want to join a sub= -net or create their own compatible key management infrastructure. In this = case OpenSSH tooling is much simpler to use than OpenSSL and something oper= ators do regularly for SSH login. It is beneficial that some server softwar= e can be configured to accept such a user provided key. Notably users might= feel better knowing a key is generated by a piece of software they know an= d trust.

The above does not require that QUIC uses OpenSSH directly, = just that there is a low-cost translation.

The use of DNS based auth = is not very useful when network addresses might be routed on overlay networ= ks and/or having address that are not advertised by DNS, or when not having= any meaningful address at all (e.g. content based routing). Even without S= SH tooling, it is reasonably easy to implement custom tools based on the sa= me concept when the underlying primitives are largely the same.

Some = of this is not directly applicable to QUIC because it operates trust at a h= igher level, but such a system must still manage the keys used by QUIC conn= ections and it is preferable that all components can agree on the basic pri= mitives.

OK.=C2=A0 Well, I'm generally not t= hat enthusiastic about inventing cert formats, but there's no technical= obstacle that I know of.

-Ekr

<= /div>

--001a11457576f3eca1055fb006e2-- From nobody Wed Dec 6 10: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 4D895124239 for ; Wed, 6 Dec 2017 10:42:32 -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 CeuggFgHCnpD for ; Wed, 6 Dec 2017 10:42:30 -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 0373F1241F5 for ; Wed, 6 Dec 2017 10:42:30 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id 184so1945897ybw.12 for ; Wed, 06 Dec 2017 10:42:29 -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=WR1j6lVHZtysyJGB/kwUU6odgDl9eyEhBlZdqOu7Ho0=; b=Nj5YZbY/AtvYEW81wQ7/jvgdBr0niF8kk7KL+IeeYkFFPk9OJ1XRCn/lpHYLvYhJLO xGvaji5BsrFK28B2CdfCvCZKcMtTINrJz3Biz916Nrc8qaSjTW0IP1wh1TPRgNSBOJAk Ss4UuUrrGsLTuHA71oaTe84DktzlUrMV6meVLC3yo+Bav7IrNx76aix8qF4MaGL2qx9q KCef7LSdY6VkJztjpG98ihZOG9yd3rBJV9PoLzSNtyugyU6vfRt5OtN8uB2L4pd7LYr1 brWFSHPlcKYnjRWXPfvLvlB6fnAtIfDs4jZXHZivbCinVulNH88Mx3mcamDbEfVNYjL8 SB0Q== 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=WR1j6lVHZtysyJGB/kwUU6odgDl9eyEhBlZdqOu7Ho0=; b=SHqqnsAG+LfY1iBlh0eF2JfEoI2rlw0gt629U9QVEvkBW+pi4aygSlO9Ob3oIF625q VosK6ekN2wg/Uli5tMClC35wIJqsUt6c7Gu8HG5O/r5IFao7wNRw7HNvBLMLm0N6PoPK 5jYzIXcLcWRQBIHqNQg9FLAP05pN4R/l5Ykan1OHfwiBX24/FxBQKEWMROPF49ecXEOR TzLBrpXx15mhZmk61K2isC08/VZ1ZJxjh8HIQmtI2s553zFkyfWdNCvqnFkpOnR/10ho 4W0M4YqDL2GqhsoFNlNgLXZURBpEsIdWQXosB4CJYZ0Ery/ix9zUDKPMquJSrNvMvgBM 9bgg== X-Gm-Message-State: AKGB3mIMRE0ml/kmY9tI8yo6XfU5oW8H+hmiAAQmqgmJp/XkYTb2mrdb A1zUgCybqo24Bo9OxdQWN6tpJxNJZm4PKc6cl7MHJFM3o1g= X-Google-Smtp-Source: AGs4zMYWlz/AF8Eyuabgy2d/zM1Rn7AAsmHIxx+ynyygVZIOEDC2cIIiqfgrYn7f1sATBZ27z0qPILcMrRO39QNIO54= X-Received: by 10.37.13.68 with SMTP id 65mr1066526ybn.416.1512585748952; Wed, 06 Dec 2017 10:42:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 10:41:48 -0800 (PST) From: Eric Rescorla Date: Wed, 6 Dec 2017 10:41:48 -0800 Message-ID: Subject: More on demultiplexing To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c061084263fd055fb05037" 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, 06 Dec 2017 18:42:32 -0000 --001a11c061084263fd055fb05037 Content-Type: text/plain; charset="UTF-8" I've been doing some thinking about the QUIC muxing story. It seems like the case that everyone has in their head is WebRTC, so I'd like to focus on that. It seems to me that there are two main deployment models one might have in mind: - A browser unilaterally decides to support QUIC-WebRTC and just advertises it in its SDP, so that if that browser encounters another such browser, they do QUIC - A service provider decides to do QUIC-WebRTC and turns it on for clients which can do it. These have different muxing requirements, and then there are also some subchoices about whether you want everything in WebRTC to be QUIC or just parts of it. As background, current WebRTC stacks attempt to mux all of the following protocols on the same 5-tuple: - STUN (for ICE and for TURN) - TURN channels - DTLS (for key management) - SRTP (for media) Note that I don't say SCTP because that's encapsulated in DTLS. STUN I think the general consensus is that we need to be able to mux STUN with QUIC, because otherwise we would need to reinvent all of STUN and ICE and that would be very not fun, and in some ways problematic because the non-ICE parts of STUN don't assume any server authentication so it's not clear how you would ever think to do them with QUIC. TURN TURN can either run over STUN, in which case it's covered by the previous case, or it can run in channels, which are not. If you're willing to abandon channels, then you don't have a problem. If you're not, then you need TURN channels to work. I've heard suggestions that we should run TURN over QUIC but I don't think that's sensible because the point of TURN channels is to reduce overhead, and at that point you probably could run the non-channel version of TURN without too much overhead loss vis-a-vis QUIC and then you wouldn't have to address other problems (e.g., server auth) that we never really resolved with TURN-TLS and would maybe come back with QUIC. DTLS and SRTP Exactly what you need here depends on the deployment model. One might imagine having QUIC-WebRTC in which the media and data channels are both carried on QUIC, but you might also imagine having the data channel be QUIC but the media being carried over RTP. I know there's active work on a mapping for media over QUIC, but it's obviously not as straightforward as a datachannels mapping, for which QUIC is basically a drop-in replacement for SCTP, so that's a consideration here. In the case where you wanted SRTP separately, you would then need to either (a) figure out a way to demux SRTP and QUIC or (b) not run them on the same 5-tuple. (b) seems natural at some level, but we adopted BUNDLE for a reason and this would push against that. So, it seems to me that if you want to run data-over-QUIC and media-over-SRTP you probably do need to figure out how to demux. In the case where you mux SRTP and QUIC on the same 5-tuple, you then have to address key management. You could, of course, run DTLS-SRTP and demux DTLS, but it seems like you could probably just use QUIC's TLS handshake the way you run DTLS-SRTP and do the SRTP exporter from there, so maybe you don't need to mux DTLS. -Ekr --001a11c061084263fd055fb05037 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been doing some thinking about the QUIC muxi= ng story. It seems
like the case that everyone has in their head = is WebRTC, so I'd like
to focus on that. It seems to me that = there are two main deployment models
one might have in mind:

- A browser unilaterally decides to support QUIC-WebRT= C and just advertises
=C2=A0 it in its SDP, so that if that brows= er encounters another such browser,
=C2=A0 they do QUIC

- A service provider decides to do QUIC-WebRTC and turns it= on for
=C2=A0 clients which can do it.

= These have different muxing requirements, and then there are also
some subchoices about whether you want everything in WebRTC to be QUIC
or just parts of it.


As back= ground, current WebRTC stacks attempt to mux all of the
following= protocols on the same 5-tuple:

- STUN (for ICE an= d for TURN)
- TURN channels
- DTLS (for key management)=
- SRTP (for media)

Note that I don'= t say SCTP because that's encapsulated in DTLS.

STUN
I think the general consensus is that we need to be able t= o mux STUN
with QUIC, because otherwise we would need to reinvent= all of STUN
and ICE and that would be very not fun, and in some = ways problematic
because the non-ICE parts of STUN don't assu= me any server authentication
so it's not clear how you would = ever think to do them with QUIC.


TU= RN
TURN can either run over STUN, in which case it's covered = by the previous
case, or it can run in channels, which are not. I= f you're willing to
abandon channels, then you don't have= a problem. If you're not, then you
need TURN channels to wor= k. I've heard suggestions that we should run
TURN over QUIC b= ut I don't think that's sensible because the point of
TUR= N channels is to reduce overhead, and at that point you probably
= could run the non-channel version of TURN without too much overhead
loss vis-a-vis QUIC and then you wouldn't have to address other prob= lems
(e.g., server auth) that we never really resolved with TURN-= TLS and would
maybe come back with QUIC.


DTLS and SRTP
Exactly what you need here depends = on the deployment model. One might
imagine having QUIC-WebRTC in = which the media and data channels are both
carried on QUIC, but y= ou might also imagine having the data channel be
QUIC but the med= ia being carried over RTP. I know there's active work
on a ma= pping for media over QUIC, but it's obviously not as straightforward
as a datachannels mapping, for which QUIC is basically a drop-in re= placement
for SCTP, so that's a consideration here.

In the case where you wanted SRTP separately, you would the= n need to
either (a) figure out a way to demux SRTP and QUIC or (= b) not run them
on the same 5-tuple.=C2=A0 (b) seems natural at s= ome level, but
we adopted BUNDLE for a reason and this would push= against that. So,
it seems to me that if you want to run data-ov= er-QUIC and
media-over-SRTP you probably do need to figure out ho= w to demux.

In the case where you mux SRTP and QUI= C on the same 5-tuple, you then
have to address key management. Y= ou could, of course, run DTLS-SRTP
and demux DTLS, but it seems l= ike you could probably just use QUIC's
TLS handshake the way = you run DTLS-SRTP and do the SRTP exporter from
there, so maybe y= ou don't need to mux DTLS.

-Ekr

=





=





=
--001a11c061084263fd055fb05037-- From nobody Wed Dec 6 10:55: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 3DB00126CD8 for ; Wed, 6 Dec 2017 10:55: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, 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 rCtCJ8w3Iw4d for ; Wed, 6 Dec 2017 10:55:37 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 69A74124B0A for ; Wed, 6 Dec 2017 10:55:37 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id r39so11416375qtr.13 for ; Wed, 06 Dec 2017 10:55: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=29KsEJADR1aYs6BvIY+lqxu23MoVmzBnUuEI25iJcoA=; b=olr/0x60RCWLMH5ODrI9SY10d0Peecd+pbepnXF868GDNuS4bcRBd2pWSH5aG6lbx4 faKPNAn8JsTRPy/Z26rRCku/CvvCVwXqK5mWf1JwGtAEepwvEZbdj5Ni8qD+axgXECAR QYwruKTnkTBFM+TbZobwAn2Cb7GtAaIo6qEb2mgxAJeWWwlfqqb1UZgZEcoR256emzuX XkhQRGS/+TNHeJjP1uObTVvwUqKp5RqKWZXof1nqhFdI4KJ3af6LsiLmGovJpePBZtV4 B8hXBSBIkUxv1VCjBXyU5V8QbAtPAmwQBb+m/PjUieqtV7XidvSulnIrow+Rihu3d499 OOdg== 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=29KsEJADR1aYs6BvIY+lqxu23MoVmzBnUuEI25iJcoA=; b=VMN+pyoEd1tU6HYTCDymDzcR22ck+0A4itVNmQ1FW/7GX3Jw7eYh8XQ+2o9Rtt5Sau JXUCpBrGnh2m93mDkiElIsnufExt9fDmyr2AP1aWcW95hnMDV2/NWxDF4AOpd+ryF2xW 2fqGPp3fHt0LlV2HGtS7OSVi1yxNEpQgP4ISVoZKt9+XKV4hd5B/blNR3KaRCv0i20Al iEGnlTctSMKmNPxHMdlzDVT7vo3ZqHGAoz1yD3n8dLXfPMCJT56ZSG1z9c79gixjGLy6 mkcfa5LVbcBErfYLKJ+LR9PHn2IZLAbwklnAq2EBA1biaoTF54dedZxd/siiXmXrUWj8 TtEg== X-Gm-Message-State: AKGB3mJLd6+t2QmklN7LIszHgZPFnt8KA3QQ13zrahhnJV34E3Kiwm7O xamKpo5eIoHZoYFPUrVxssxDzwMuurhtMJwt00f+jg== X-Google-Smtp-Source: AGs4zMZ0AHMqGHvIlp34AU777WM03vMZ9XL+ft7tS9uNY8jNLtLkuq3/te1dbOGMsMfpVwGTP44gu0Tx9x8V8w/mWic= X-Received: by 10.55.183.71 with SMTP id h68mr1071272qkf.315.1512586536291; Wed, 06 Dec 2017 10:55:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.18.33 with HTTP; Wed, 6 Dec 2017 10:55:35 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Wed, 6 Dec 2017 13:55:35 -0500 Message-ID: Subject: Re: Simplify ACK frame retransmission To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Eric Rescorla , Jana Iyengar , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c0594ce30b1bd055fb07f9d" 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, 06 Dec 2017 18:55:39 -0000 --94eb2c0594ce30b1bd055fb07f9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 6, 2017 at 10:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Answers inline below > > > That is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS= 1 >> signatures which is the heavy part (RFC8017) and the draft does not appe= ar >> to make this negotiable from what I can tell. >> > This is just an interop requirement. I.e., if you don't do this then you > will not be able to talk to the large number of servers who have RSA only > keys embedded in PKCS#1 certs. It's quite possible to just support Ed2551= 9, > and you say so using the signature_algorithms extension. Obviously, if yo= u > say that, then you will have a handshake failure with anyone without a > suitable key, but in a closed world that's fine. IMO it would be better t= o > advertise the usual TLS/QUIC versions and be officially non-compliant tha= n > have a new version that differed only along this axis. I imagine we could > put in some weasel words if necessary about closed environments. > > That would be fine with me, it is just that MUST in TLS sec. 9.1 is a > strong word, so you couldn=E2=80=99t really say you use TLS1.3 and hence = not QUIC, > unless some permission was granted towards this use case. > My reading of the spec is that application profile can override any requirement of section 9.1. The spec wording is somewhat ambiguous here, but I see no reason it could change ciphers, but not signature algorithms. --94eb2c0594ce30b1bd055fb07f9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 6, 2017 at 10:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@= gmail.com> wrote:
Answers inline = below
=C2=A0

That is good to hear, but I believe the TLS1.3-22 = draft requires RSA PKCS1 signatures which is the heavy part (RFC8017) and t= he draft does not appear to make this negotiable from what I can tell.

<= /div>
This is just an interop requirement. I.e., if y= ou don't do this then you will not be able to talk to the large number = of servers who have RSA only keys embedded in PKCS#1 certs. It's quite = possible to just support Ed25519, and you say so using the signature_algori= thms extension. Obviously, if you say that, then you will have a handshake = failure with anyone without a suitable key, but in a closed world that'= s fine. IMO it would be better to advertise the usual TLS/QUIC versions and= be officially non-compliant than have a new version that differed only alo= ng this axis. I imagine we could put in some weasel words if necessary abou= t closed environments.

That would be fine with me, it is just that MUST in TLS sec. 9= .1 is a strong word, so you couldn=E2=80=99t really say you use TLS1.3 and = hence not QUIC, unless some permission was granted towards this use case.


My reading of the spec is that app= lication profile can override any requirement of section 9.1.=C2=A0 =C2=A0T= he spec wording is somewhat ambiguous here, but I see no reason it could ch= ange ciphers, but not signature algorithms.

--94eb2c0594ce30b1bd055fb07f9d-- From nobody Wed Dec 6 11:02: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 05D561275FD for ; Wed, 6 Dec 2017 11:02: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 S-k0rPXFRa_q for ; Wed, 6 Dec 2017 11:02:49 -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 4C9A4127005 for ; Wed, 6 Dec 2017 11:02:49 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id k80so1979252ywe.0 for ; Wed, 06 Dec 2017 11:02:49 -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=3P6rQ8cfP9fLvXT3GoxLlOS13p/I6HeFFBkHjZm+nik=; b=HVfC7law/bdqWTIyjViMI/vBZzTptEUtl7xvC0CDAzyzgRg+Cuz/LJtB8AVEEkQ5j8 rA+XHGhqVxEISXY3fVsL03b6gCuA2KkvMOH/+5GD57HXtAJoddSdnrIatbgJWDVh3oup yVKF48L2Zj9U9YZognUvAwk3m7LjF7GzPJEkTw5IbkpE3ZKP+bPRsfwnhTXzK1RnOEZb JrUs1ZAsKsFa00BT0kiJuUnQVpjuFMHk8esA7i9VRjHTUPUudlru2k9cmuuCf4wdnUKD VYu6kONBaQzsiDTsVkPKRhWiIEWbtZ1x9XEYse7n73PAVUgIye+R2um59iDGZjARMz5R S7sQ== 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=3P6rQ8cfP9fLvXT3GoxLlOS13p/I6HeFFBkHjZm+nik=; b=H7VVTK4ckt0RSgmXi9HewT2NaWjk719KFyRXOetq3MEwUL7hWkx1oICAeC387XytXt n6ZSirY5fAN4wx3UJ6KXVqcH3iJwjpVLjGMaxpXiUSedzQlirUWnC7K48iAgT3YxGJ3g CmPnBxoHWqClL5LH4KfgZ8KGDlVo2x+HVuER/MaDgtn6RomkxjQTyDBp4hBN95LLNZb4 FZE9kI/t5VUaqS2XZeNYwQmOtKUk86JWLf0+OM1oDEMwjj0TksN8Gs1WUyoIgZj6ER+t KgO8+W3sU5V2Uh1uIdLnRiaCtrANR8dVKIX6ZA31LdUB703Mq1FGSGEeQmRseV9vnB3m GtOQ== X-Gm-Message-State: AJaThX5+F74e9Jjro/pW6XIEWb33mHDiSwvGjBcn2AKnAnZHpziECrXX nANUR1fYSe362LNa+85FGsr6Marq2G9mVfrJipwEPg== X-Google-Smtp-Source: AGs4zMZo60F/5KATmrqMu+vrvFXivKDUJZDr+rkKehT2ozwUwqhw0Npan4iycyQiVSXz05TQt76o/e62wWqRzI+Npgc= X-Received: by 10.129.77.195 with SMTP id a186mr16790960ywb.363.1512586968437; Wed, 06 Dec 2017 11:02:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 11:02:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 6 Dec 2017 11:02:07 -0800 Message-ID: Subject: Re: Simplify ACK frame retransmission To: Victor Vasiliev Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Jana Iyengar , IETF QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a1140c8e6f23b16055fb09812" 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, 06 Dec 2017 19:02:51 -0000 --001a1140c8e6f23b16055fb09812 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 6, 2017 at 10:55 AM, Victor Vasiliev wrote= : > On Wed, Dec 6, 2017 at 10:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> Answers inline below >> >> >> That is good to hear, but I believe the TLS1.3-22 draft requires RSA >>> PKCS1 signatures which is the heavy part (RFC8017) and the draft does n= ot >>> appear to make this negotiable from what I can tell. >>> >> This is just an interop requirement. I.e., if you don't do this then you >> will not be able to talk to the large number of servers who have RSA onl= y >> keys embedded in PKCS#1 certs. It's quite possible to just support Ed255= 19, >> and you say so using the signature_algorithms extension. Obviously, if y= ou >> say that, then you will have a handshake failure with anyone without a >> suitable key, but in a closed world that's fine. IMO it would be better = to >> advertise the usual TLS/QUIC versions and be officially non-compliant th= an >> have a new version that differed only along this axis. I imagine we coul= d >> put in some weasel words if necessary about closed environments. >> >> That would be fine with me, it is just that MUST in TLS sec. 9.1 is a >> strong word, so you couldn=E2=80=99t really say you use TLS1.3 and hence= not QUIC, >> unless some permission was granted towards this use case. >> > > My reading of the spec is that application profile can override any > requirement of section 9.1. The spec wording is somewhat ambiguous here= , > but I see no reason it could change ciphers, but not signature algorithms= . > I agree with that, but I don't think we should override that requirement for the IETF standard version of QUIC, because the same deployment considerations apply here. I agree that were Mikkel to write such a profile, that could override this. -Ekr --001a1140c8e6f23b16055fb09812 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 6, 2017 at 10:55 AM, Victor Vasiliev <= vasilvv@google.com<= /a>> wrote:
On Wed= , Dec 6, 2017 at 10:25 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gm= ail.com> wrote:
Answers inline below
=C2=A0

Th= at is good to hear, but I believe the TLS1.3-22 draft requires RSA PKCS1 si= gnatures which is the heavy part (RFC8017) and the draft does not appear to= make this negotiable from what I can tell.

This is just an interop requirement. I.e., if you don't do this then y= ou will not be able to talk to the large number of servers who have RSA onl= y keys embedded in PKCS#1 certs. It's quite possible to just support Ed= 25519, and you say so using the signature_algorithms extension. Obviously, = if you say that, then you will have a handshake failure with anyone without= a suitable key, but in a closed world that's fine. IMO it would be bet= ter to advertise the usual TLS/QUIC versions and be officially non-complian= t than have a new version that differed only along this axis. I imagine we = could put in some weasel words if necessary about closed environments.

That would be = fine with me, it is just that MUST in TLS sec. 9.1 is a strong word, so you= couldn=E2=80=99t really say you use TLS1.3 and hence not QUIC, unless some= permission was granted towards this use case.

<= br>
My reading of the spec is that application profile can= override any requirement of section 9.1.=C2=A0 =C2=A0The spec wording is s= omewhat ambiguous here, but I see no reason it could change ciphers, but no= t signature algorithms.

=
I agree with that, but I don't think we should override that requi= rement for the IETF standard version of QUIC, because the same deployment c= onsiderations apply here. I agree that were Mikkel to write such a profile,= that could override this.

-Ekr

--001a1140c8e6f23b16055fb09812-- From nobody Wed Dec 6 11:08: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 E44C1126DFE for ; Wed, 6 Dec 2017 11:08:07 -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_H4=-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=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az_GGXmRGkiq for ; Wed, 6 Dec 2017 11:08:05 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0095.outbound.protection.outlook.com [104.47.41.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61B8126CC4 for ; Wed, 6 Dec 2017 11:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gKgQxXaEbaPKbkG/2T4pWMX1yh7VMHrW6LNHmOMp1QY=; b=b677cJldsovrM3RvurRE3j7wA6L2N0U/JbTx+7j8hGT/rx0Ouie9JSWOGYtcFuUXkpf/+L3FkyrzKGfnGGD9wMQaMc9jPzIr4zyt2IBgcls0K0f7JiPR78NUOZqNtZGoiKqNQGuC6YMxPBMVKAlRi8W3I4RWiQHO7zH+g94siJQ= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2430.namprd08.prod.outlook.com (10.169.203.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 6 Dec 2017 19:08:00 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0302.007; Wed, 6 Dec 2017 19:08:00 +0000 From: Mike Bishop To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Eric Rescorla CC: Jana Iyengar , IETF QUIC WG , "Martin Thomson" Subject: RE: Simplify ACK frame retransmission Thread-Topic: Simplify ACK frame retransmission Thread-Index: AQHTbexvRtKA6XZomkKqMgctE68wtqM1EDmAgAAOIYCAAFHrgIAAzMcAgAAhtACAABIzAIAAPWeg Date: Wed, 6 Dec 2017 19:08: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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2430; 6:4DjrJBytqXqTZnSN29zzgu24ztQE92/loeZSgnnkRRBsL4UImvemRoE5y3Wu0j3JaUCA8C1+dFk/9J1WaDaAgFB5QE5mlgSrbKRReuEli8JQBfX62J8Pr51Y9WsPs9nVpfvYesoYWfjcIKfSpoWe0zJ6fEgCsl5KMfeWPEYJ/aDtG2pW7lgQAaNWG+XoelvrcMKyiY3m5ww8X4VYMqgVNvE1dVii97oUpGkbehXAHyaWRk6HWryhOo8eObcW3N0MkIqfWX+5osjlW270WAultNj08TfV5ZLNpMKTxmZtS6EA3pm/3ggnJu0kyOQcVRGNc46L3JkXQVsdyjpiD71OHdRTuZYVqQnwuOlFCUTtiqM=; 5:5YcgYGwYf9vhGdBfcxTFdjd1o45gfaWMqU31pY7bSOA2rDpumVV5E8gZjqTeGykvz0ZgmPDJ6aI9YcxCpfM+GyTfSLSYTwyTIJAFZZifYSWSbwcyPEAK2fzKbnZDiCl71LL1wJg8q0CS2SnAy1dQRaBelcpUYEDpU/K2NEPhp9U=; 24:r5ZeiLRvF2ORR9NBCtAcmrM+4wUB6jQW8c6sTUnZF92MH4nc87VulJnXZXPP2N6YcECI5YYV4aVFBEkKLExlOb7uouc+Bj6foRHd4N4pAmU=; 7:YePEvPNCpVvxcrBb3xiqHyaHJMREXdlcb+8z0MJ1LN0oTmPGr3TdHfqD/wnOs+2tMAbcdBUB7Q2d7Aju1+oQUUwd3aLID1kbwKKJJTrqCmwFpISVil9HZNAs5ye/tyzfLc5IfBwhkWlE6LbbAhqBn3wJSvNEuAvhi1mE0Hj17ivAq6YJe2rVcLq0QZDMA3HFDn/5sZtja5/jC7KpjNc8bZonPzH5phLZxUkAmqAtEY7eAR+3WMsBtQB4HuBkZoUu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7dc9895b-0ca1-4a61-9831-08d53cdcab62 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603286); SRVR:MWHPR08MB2430; x-ms-traffictypediagnostic: MWHPR08MB2430: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(920507027)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2430; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR08MB2430; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39830400002)(376002)(346002)(199004)(189003)(3846002)(55016002)(14454004)(6506006)(7696005)(102836003)(34040400001)(93886005)(106356001)(6116002)(77096006)(99286004)(8936002)(97736004)(74316002)(7736002)(6436002)(81156014)(8676002)(81166006)(76176011)(478600001)(790700001)(74482002)(105586002)(2950100002)(5660300001)(229853002)(110136005)(2906002)(25786009)(66066001)(2900100001)(68736007)(54906003)(54896002)(316002)(86362001)(9686003)(53546010)(6306002)(4326008)(53936002)(6246003)(3660700001)(39060400002)(3480700004)(3280700002)(101416001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2430; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB243251DEE1FA201CDEA0ED9EDA320MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 7dc9895b-0ca1-4a61-9831-08d53cdcab62 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 19:08:00.5817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2430 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, 06 Dec 2017 19:08:08 -0000 --_000_MWHPR08MB243251DEE1FA201CDEA0ED9EDA320MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZeKAmXMgdGhlIHRoaW5nOiAgVGhlIElFVEYgd3JpdGVzIHNwZWNpZmljYXRpb25zLCBidXQg ZG9lc27igJl0IGRvIGNlcnRpZmljYXRpb25zIG9mIGNvbmZvcm1hbmNlLiAgSWYgeW91IHdhbnQg dG8gZGVwbG95IHNvbWV0aGluZyB0aGF0IGRvZXNu4oCZdCBjb25mb3JtIHRvIHRoZSBzcGVjaWZp Y2F0aW9uLCB3aGF0IHlvdSBsb3NlIGlzIGludGVyb3BlcmFiaWxpdHkuICBJZiB5b3Ugd2FudCBp bnRlcm9wLCB3cml0ZSB1cCBhIGRvYyBhbmQgcHVibGlzaCBpdCAoaW5kZXBlbmRlbnQgc3VibWlz c2lvbiwgQUQtc3BvbnNvcmVkLCBub24tSUVURiB2ZW51ZSwgZXRjLiksIGFuZCByZWdpc3RlciBh biBhcHByb3ByaWF0ZSBJQU5BIGNvZGVwb2ludCBmb3IgeW91ciB2YXJpYW50LiAgSWYgeW91IGRv buKAmXQgY2FyZSBhYm91dCBpbnRlcm9wLCB0aGVuIHlvdeKAmXJlIG5vdCBnb2luZyB0byBiZSBz dWVkIGZvciB1c2luZyB0aGUgbmFtZXMgVExTIDEuMyBvciBRVUlDLg0KDQpGcm9tOiBRVUlDIFtt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA2LCAyMDE3IDc6MjUgQU0NClRv OiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+DQpDYzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29v Z2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogU2ltcGxpZnkgQUNLIGZyYW1l IHJldHJhbnNtaXNzaW9uDQoNCkFuc3dlcnMgaW5saW5lIGJlbG93DQoNCg0KVGhhdCBpcyBnb29k IHRvIGhlYXIsIGJ1dCBJIGJlbGlldmUgdGhlIFRMUzEuMy0yMiBkcmFmdCByZXF1aXJlcyBSU0Eg UEtDUzEgc2lnbmF0dXJlcyB3aGljaCBpcyB0aGUgaGVhdnkgcGFydCAoUkZDODAxNykgYW5kIHRo ZSBkcmFmdCBkb2VzIG5vdCBhcHBlYXIgdG8gbWFrZSB0aGlzIG5lZ290aWFibGUgZnJvbSB3aGF0 IEkgY2FuIHRlbGwuDQpUaGlzIGlzIGp1c3QgYW4gaW50ZXJvcCByZXF1aXJlbWVudC4gSS5lLiwg aWYgeW91IGRvbid0IGRvIHRoaXMgdGhlbiB5b3Ugd2lsbCBub3QgYmUgYWJsZSB0byB0YWxrIHRv IHRoZSBsYXJnZSBudW1iZXIgb2Ygc2VydmVycyB3aG8gaGF2ZSBSU0Egb25seSBrZXlzIGVtYmVk ZGVkIGluIFBLQ1MjMSBjZXJ0cy4gSXQncyBxdWl0ZSBwb3NzaWJsZSB0byBqdXN0IHN1cHBvcnQg RWQyNTUxOSwgYW5kIHlvdSBzYXkgc28gdXNpbmcgdGhlIHNpZ25hdHVyZV9hbGdvcml0aG1zIGV4 dGVuc2lvbi4gT2J2aW91c2x5LCBpZiB5b3Ugc2F5IHRoYXQsIHRoZW4geW91IHdpbGwgaGF2ZSBh IGhhbmRzaGFrZSBmYWlsdXJlIHdpdGggYW55b25lIHdpdGhvdXQgYSBzdWl0YWJsZSBrZXksIGJ1 dCBpbiBhIGNsb3NlZCB3b3JsZCB0aGF0J3MgZmluZS4gSU1PIGl0IHdvdWxkIGJlIGJldHRlciB0 byBhZHZlcnRpc2UgdGhlIHVzdWFsIFRMUy9RVUlDIHZlcnNpb25zIGFuZCBiZSBvZmZpY2lhbGx5 IG5vbi1jb21wbGlhbnQgdGhhbiBoYXZlIGEgbmV3IHZlcnNpb24gdGhhdCBkaWZmZXJlZCBvbmx5 IGFsb25nIHRoaXMgYXhpcy4gSSBpbWFnaW5lIHdlIGNvdWxkIHB1dCBpbiBzb21lIHdlYXNlbCB3 b3JkcyBpZiBuZWNlc3NhcnkgYWJvdXQgY2xvc2VkIGVudmlyb25tZW50cy4NCg0KVGhhdCB3b3Vs ZCBiZSBmaW5lIHdpdGggbWUsIGl0IGlzIGp1c3QgdGhhdCBNVVNUIGluIFRMUyBzZWMuIDkuMSBp cyBhIHN0cm9uZyB3b3JkLCBzbyB5b3UgY291bGRu4oCZdCByZWFsbHkgc2F5IHlvdSB1c2UgVExT MS4zIGFuZCBoZW5jZSBub3QgUVVJQywgdW5sZXNzIHNvbWUgcGVybWlzc2lvbiB3YXMgZ3JhbnRl ZCB0b3dhcmRzIHRoaXMgdXNlIGNhc2UuDQoNCkFzIHRvIFJhdyB2cyBPcGVuU1NIIEkgd2lsbCBo YXZlIHRvIHN0dWR5IHRoZSBkZXRhaWxzIGZ1cnRoZXIuIEdldHRpbmcgcmlkIG9mIERFUiB3b3Vs ZCBiZSB2ZXJ5IG5pY2UsIGJ1dCBpdCBjYW4gYmUgb3ZlcmNvbWUsIGJ1dCB0aGVyZSBpcyBtb3Jl IHRvIGl0LiBPbmUgcGFydCBpcyB0aGUgZmlsZS9ibG9iIGZvcm1hdCwgYW5vdGhlciBpcyB0aGUg bWV0YWRhdGEgc3VjaCBhcyBkb21haW4gYW5kIGV4cGlyYXRpb24gZGF0ZSwgYW5kIHRoZSB0aGly ZCBpcyB0aGUgdG9vbGluZyBhcm91bmQgaXQuIE9wZW5TU0ggaGFzIHNpbXBsZSB0b29saW5nIGFu ZCBpdCBjYW4gYWxzbyBiZSByZS1pbXBsZW1lbnRlZCBzdGFuZGFsb25lIHdpdGgganVzdCBhbiBF ZC9YMjU1MTkgbGlicmFyeSBhbmQgc2ltcGxlIGJsb2IgcGFyc2VyL3ByaW50ZXIgKEkgY2FuIG9w ZW4gc291cmNlIG9uZSBpZiBhbnlvbmUgaXMgaW50ZXJlc3RlZCkuIFRoZSBhbHRlcm5hdGl2ZSBp cyB0byBkZWFsIHdpdGggT3BlblNTTCB0b29scyBhbmQgcmF0aGVyIGNvbnZvbHV0ZWQgQ0EgbWVj aGFuaXNtcyBhbmQgcG9zc2libHkgdHJ1c3QgY2hhaW5zLiBCdXQgSSBkbyBhY2tub3dsZWRnZSB0 aGF0IHRoZSBwdWJsaWMgaW50ZXJuZXQgZXZvbHZlcyBhcm91bmQgdGhlc2UgdHlwZXMgb2YgY2Vy dGlmaWNhdGVzIGFuZCB0aGF0IHRoaXMgaXMgdW5saWtlbHkgdG8gY2hhbmdlDQpJJ20gaGF2aW5n IHRyb3VibGUgdmlzdWFsaXppbmcgeW91ciBlbnZpcm9ubWVudCBoZXJlLiBBcmUgeW91IGRvaW5n IFRPRlUsIGluIHdoaWNoIGNhc2UgdGhpcyBpcyBqdXN0IGFuIGlzc3VlIG9mIHRyYW5zcG9ydGlu ZyB0aGUga2V5cywgb3IgYXJlIHlvdSBhY3R1YWxseSBvcGVyYXRpbmcgc29tZSBraW5kIG9mIENB IHN5c3RlbT8gSW4gYW55IGNhc2UsIGl0J3MgYWxzbyBwb3NzaWJsZSB0byBhZGQgT3BlblNTSCBj ZXJ0aWZpY2F0ZXMgdG8gVExTIChpdCdzIGp1c3QgYSBjb2RlIHBvaW50KSwgYnV0IEkgd291bGQg Z2VuZXJhbGx5IG5vdCBiZSBpbiBmYXZvciBvZiB0aGF0IHVubGVzcyBpdCB3YXMgcmVhbGx5IG5l ZWRlZC4NCg0KVGhlIGVudmlyb25tZW50IGlzIG5vdCBmdWxseSBmbGVzaGVkIG91dCBidXQgaW4g c3VtbWFyeSBpdCBpcyBhYm91dCBzZXJ2ZXIgdG8gc2VydmVyIHBlZXIgbmV0d29ya2luZyB3aXRo IG11bHRpcGxlIGxldmVscyBvZiB0cnVzdCBhbmQgc2F0ZWxsaXRlIGFjY2Vzcy4gU2F0ZWxsaXRl cyBtaWdodCBiZSBub24tc3RhbmRhcmQgbG93IHJlc291cmNlIHN5c3RlbXMuDQoNCkkgZG8gaGF2 ZSBDQSBpbiBtaW5kLCBidXQgZm9yIHNpbXBsZXIgdXNlIGNhc2VzIFRPRlUgKHRydXN0IG9uIGZp cnN0IHNpZ2h0KSBwb2ludGluZyB0byBhbiBhdXRob3JpemVkX2tleXMgZmlsZSBpcyBhbHNvIGEg Y29uc2lkZXJhdGlvbi4NCg0KSSB3YW50IHNvbWUgdmVyeSB0cnVzdGVkIGNlbnRyYWwgcGllY2Ug b2Ygc29mdHdhcmUgdG8gY3JlYXRlIGFuZCBzaWduIGNlcnRzIHRoYXQgb3RoZXIgcGFydGllcyB0 cnVzdCBpbiBvcmRlciB0byBlc3RhYmxpc2ggYSBwZWVyIHRvIHBlZXIgc2VydmVyIG5ldHdvcmsu IFNoYW1pcnMgU2hhcmVkIFNlY3JldCBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBzZXR1cC4gSW4gdGhp cyBjYXNlIHRoZSBtaW5pbXVtIGNvbXBsZXhpdHkgbmVlZGVkIHRvIGltcGxlbWVudCBhIENBIGlz IGRlc2lyYWJsZSBhbmQgT3BlblNTSC9FZDI1NTE5IGlzIGNsb3NlIHRvIHRoYXQgYXMgYSBtb2Rl bCBldmVuIGlmIG5vdCB1c2luZyBPcGVuU1NIIHNvZnR3YXJlIGRpcmVjdGx5Lg0KDQpJbiBhZGRp dGlvbiwgZXh0ZXJuYWwgcGFydGllcyBtaWdodCB3YW50IHRvIGpvaW4gYSBzdWItbmV0IG9yIGNy ZWF0ZSB0aGVpciBvd24gY29tcGF0aWJsZSBrZXkgbWFuYWdlbWVudCBpbmZyYXN0cnVjdHVyZS4g SW4gdGhpcyBjYXNlIE9wZW5TU0ggdG9vbGluZyBpcyBtdWNoIHNpbXBsZXIgdG8gdXNlIHRoYW4g T3BlblNTTCBhbmQgc29tZXRoaW5nIG9wZXJhdG9ycyBkbyByZWd1bGFybHkgZm9yIFNTSCBsb2dp bi4gSXQgaXMgYmVuZWZpY2lhbCB0aGF0IHNvbWUgc2VydmVyIHNvZnR3YXJlIGNhbiBiZSBjb25m aWd1cmVkIHRvIGFjY2VwdCBzdWNoIGEgdXNlciBwcm92aWRlZCBrZXkuIE5vdGFibHkgdXNlcnMg bWlnaHQgZmVlbCBiZXR0ZXIga25vd2luZyBhIGtleSBpcyBnZW5lcmF0ZWQgYnkgYSBwaWVjZSBv ZiBzb2Z0d2FyZSB0aGV5IGtub3cgYW5kIHRydXN0Lg0KDQpUaGUgYWJvdmUgZG9lcyBub3QgcmVx dWlyZSB0aGF0IFFVSUMgdXNlcyBPcGVuU1NIIGRpcmVjdGx5LCBqdXN0IHRoYXQgdGhlcmUgaXMg YSBsb3ctY29zdCB0cmFuc2xhdGlvbi4NCg0KVGhlIHVzZSBvZiBETlMgYmFzZWQgYXV0aCBpcyBu b3QgdmVyeSB1c2VmdWwgd2hlbiBuZXR3b3JrIGFkZHJlc3NlcyBtaWdodCBiZSByb3V0ZWQgb24g b3ZlcmxheSBuZXR3b3JrcyBhbmQvb3IgaGF2aW5nIGFkZHJlc3MgdGhhdCBhcmUgbm90IGFkdmVy dGlzZWQgYnkgRE5TLCBvciB3aGVuIG5vdCBoYXZpbmcgYW55IG1lYW5pbmdmdWwgYWRkcmVzcyBh dCBhbGwgKGUuZy4gY29udGVudCBiYXNlZCByb3V0aW5nKS4gRXZlbiB3aXRob3V0IFNTSCB0b29s aW5nLCBpdCBpcyByZWFzb25hYmx5IGVhc3kgdG8gaW1wbGVtZW50IGN1c3RvbSB0b29scyBiYXNl ZCBvbiB0aGUgc2FtZSBjb25jZXB0IHdoZW4gdGhlIHVuZGVybHlpbmcgcHJpbWl0aXZlcyBhcmUg bGFyZ2VseSB0aGUgc2FtZS4NCg0KU29tZSBvZiB0aGlzIGlzIG5vdCBkaXJlY3RseSBhcHBsaWNh YmxlIHRvIFFVSUMgYmVjYXVzZSBpdCBvcGVyYXRlcyB0cnVzdCBhdCBhIGhpZ2hlciBsZXZlbCwg YnV0IHN1Y2ggYSBzeXN0ZW0gbXVzdCBzdGlsbCBtYW5hZ2UgdGhlIGtleXMgdXNlZCBieSBRVUlD IGNvbm5lY3Rpb25zIGFuZCBpdCBpcyBwcmVmZXJhYmxlIHRoYXQgYWxsIGNvbXBvbmVudHMgY2Fu IGFncmVlIG9uIHRoZSBiYXNpYyBwcmltaXRpdmVzLg0K --_000_MWHPR08MB243251DEE1FA201CDEA0ED9EDA320MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGVyZeKAmXMgdGhlIHRoaW5nOiZuYnNwOyBUaGUgSUVURiB3cml0ZXMgc3BlY2lmaWNh dGlvbnMsIGJ1dCBkb2VzbuKAmXQgZG8gY2VydGlmaWNhdGlvbnMgb2YgY29uZm9ybWFuY2UuJm5i c3A7IElmIHlvdSB3YW50IHRvIGRlcGxveSBzb21ldGhpbmcgdGhhdCBkb2VzbuKAmXQgY29uZm9y bSB0byB0aGUgc3BlY2lmaWNhdGlvbiwgd2hhdCB5b3UgbG9zZSBpcyBpbnRlcm9wZXJhYmlsaXR5 LiZuYnNwOyBJZiB5b3Ugd2FudCBpbnRlcm9wLCB3cml0ZQ0KIHVwIGEgZG9jIGFuZCBwdWJsaXNo IGl0IChpbmRlcGVuZGVudCBzdWJtaXNzaW9uLCBBRC1zcG9uc29yZWQsIG5vbi1JRVRGIHZlbnVl LCBldGMuKSwgYW5kIHJlZ2lzdGVyIGFuIGFwcHJvcHJpYXRlIElBTkEgY29kZXBvaW50IGZvciB5 b3VyIHZhcmlhbnQuJm5ic3A7IElmIHlvdSBkb27igJl0IGNhcmUgYWJvdXQgaW50ZXJvcCwgdGhl biB5b3XigJlyZSBub3QgZ29pbmcgdG8gYmUgc3VlZCBmb3IgdXNpbmcgdGhlIG5hbWVzIFRMUyAx LjMgb3IgUVVJQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgNiwgMjAxNyA3OjI1IEFNPGJyPg0KPGI+ VG86PC9iPiBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtx dWljQGlldGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWls LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNpbXBsaWZ5IEFDSyBmcmFtZSByZXRy YW5zbWlzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QW5zd2VycyBpbmxpbmUg YmVsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0IGlzIGdv b2QgdG8gaGVhciwgYnV0IEkgYmVsaWV2ZSB0aGUgVExTMS4zLTIyIGRyYWZ0IHJlcXVpcmVzIFJT QSBQS0NTMSBzaWduYXR1cmVzIHdoaWNoIGlzIHRoZSBoZWF2eSBwYXJ0IChSRkM4MDE3KSBhbmQg dGhlIGRyYWZ0IGRvZXMgbm90IGFwcGVhciB0byBtYWtlIHRoaXMgbmVnb3RpYWJsZSBmcm9tIHdo YXQgSSBjYW4NCiB0ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+VGhpcyBpcyBqdXN0IGFuIGludGVyb3AgcmVxdWlyZW1lbnQuIEkuZS4sIGlmIHlvdSBkb24n dCBkbyB0aGlzIHRoZW4geW91IHdpbGwgbm90IGJlIGFibGUgdG8gdGFsayB0byB0aGUgbGFyZ2Ug bnVtYmVyIG9mIHNlcnZlcnMgd2hvIGhhdmUgUlNBIG9ubHkga2V5cyBlbWJlZGRlZCBpbiBQS0NT IzENCiBjZXJ0cy4gSXQncyBxdWl0ZSBwb3NzaWJsZSB0byBqdXN0IHN1cHBvcnQgRWQyNTUxOSwg YW5kIHlvdSBzYXkgc28gdXNpbmcgdGhlIHNpZ25hdHVyZV9hbGdvcml0aG1zIGV4dGVuc2lvbi4g T2J2aW91c2x5LCBpZiB5b3Ugc2F5IHRoYXQsIHRoZW4geW91IHdpbGwgaGF2ZSBhIGhhbmRzaGFr ZSBmYWlsdXJlIHdpdGggYW55b25lIHdpdGhvdXQgYSBzdWl0YWJsZSBrZXksIGJ1dCBpbiBhIGNs b3NlZCB3b3JsZCB0aGF0J3MgZmluZS4gSU1PIGl0IHdvdWxkDQogYmUgYmV0dGVyIHRvIGFkdmVy dGlzZSB0aGUgdXN1YWwgVExTL1FVSUMgdmVyc2lvbnMgYW5kIGJlIG9mZmljaWFsbHkgbm9uLWNv bXBsaWFudCB0aGFuIGhhdmUgYSBuZXcgdmVyc2lvbiB0aGF0IGRpZmZlcmVkIG9ubHkgYWxvbmcg dGhpcyBheGlzLiBJIGltYWdpbmUgd2UgY291bGQgcHV0IGluIHNvbWUgd2Vhc2VsIHdvcmRzIGlm IG5lY2Vzc2FyeSBhYm91dCBjbG9zZWQgZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0IHdvdWxkIGJlIGZpbmUgd2l0aCBt ZSwgaXQgaXMganVzdCB0aGF0IE1VU1QgaW4gVExTIHNlYy4gOS4xIGlzIGEgc3Ryb25nIHdvcmQs IHNvIHlvdSBjb3VsZG7igJl0IHJlYWxseSBzYXkgeW91IHVzZSBUTFMxLjMgYW5kIGhlbmNlIG5v dCBRVUlDLCB1bmxlc3Mgc29tZSBwZXJtaXNzaW9uIHdhcyBncmFudGVkIHRvd2FyZHMNCiB0aGlz IHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXMgdG8g UmF3IHZzIE9wZW5TU0ggSSB3aWxsIGhhdmUgdG8gc3R1ZHkgdGhlIGRldGFpbHMgZnVydGhlci4g R2V0dGluZyByaWQgb2YgREVSIHdvdWxkIGJlIHZlcnkgbmljZSwgYnV0IGl0IGNhbiBiZSBvdmVy Y29tZSwgYnV0IHRoZXJlIGlzIG1vcmUgdG8gaXQuIE9uZSBwYXJ0IGlzIHRoZSBmaWxlL2Jsb2Ig Zm9ybWF0LCBhbm90aGVyDQogaXMgdGhlIG1ldGFkYXRhIHN1Y2ggYXMgZG9tYWluIGFuZCBleHBp cmF0aW9uIGRhdGUsIGFuZCB0aGUgdGhpcmQgaXMgdGhlIHRvb2xpbmcgYXJvdW5kIGl0LiBPcGVu U1NIIGhhcyBzaW1wbGUgdG9vbGluZyBhbmQgaXQgY2FuIGFsc28gYmUgcmUtaW1wbGVtZW50ZWQg c3RhbmRhbG9uZSB3aXRoIGp1c3QgYW4gRWQvWDI1NTE5IGxpYnJhcnkgYW5kIHNpbXBsZSBibG9i IHBhcnNlci9wcmludGVyIChJIGNhbiBvcGVuIHNvdXJjZSBvbmUgaWYgYW55b25lDQogaXMgaW50 ZXJlc3RlZCkuIFRoZSBhbHRlcm5hdGl2ZSBpcyB0byBkZWFsIHdpdGggT3BlblNTTCB0b29scyBh bmQgcmF0aGVyIGNvbnZvbHV0ZWQgQ0EgbWVjaGFuaXNtcyBhbmQgcG9zc2libHkgdHJ1c3QgY2hh aW5zLiBCdXQgSSBkbyBhY2tub3dsZWRnZSB0aGF0IHRoZSBwdWJsaWMgaW50ZXJuZXQgZXZvbHZl cyBhcm91bmQgdGhlc2UgdHlwZXMgb2YgY2VydGlmaWNhdGVzIGFuZCB0aGF0IHRoaXMgaXMgdW5s aWtlbHkgdG8gY2hhbmdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkknbSBo YXZpbmcgdHJvdWJsZSB2aXN1YWxpemluZyB5b3VyIGVudmlyb25tZW50IGhlcmUuIEFyZSB5b3Ug ZG9pbmcgVE9GVSwgaW4gd2hpY2ggY2FzZSB0aGlzIGlzIGp1c3QgYW4gaXNzdWUgb2YgdHJhbnNw b3J0aW5nIHRoZSBrZXlzLCBvciBhcmUgeW91IGFjdHVhbGx5IG9wZXJhdGluZyBzb21lDQoga2lu ZCBvZiBDQSBzeXN0ZW0/IEluIGFueSBjYXNlLCBpdCdzIGFsc28gcG9zc2libGUgdG8gYWRkIE9w ZW5TU0ggY2VydGlmaWNhdGVzIHRvIFRMUyAoaXQncyBqdXN0IGEgY29kZSBwb2ludCksIGJ1dCBJ IHdvdWxkIGdlbmVyYWxseSBub3QgYmUgaW4gZmF2b3Igb2YgdGhhdCB1bmxlc3MgaXQgd2FzIHJl YWxseSBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U aGUgZW52aXJvbm1lbnQgaXMgbm90IGZ1bGx5IGZsZXNoZWQgb3V0IGJ1dCBpbiBzdW1tYXJ5IGl0 IGlzIGFib3V0IHNlcnZlciB0byBzZXJ2ZXIgcGVlciBuZXR3b3JraW5nIHdpdGggbXVsdGlwbGUg bGV2ZWxzIG9mIHRydXN0IGFuZCBzYXRlbGxpdGUgYWNjZXNzLiBTYXRlbGxpdGVzIG1pZ2h0IGJl IG5vbi1zdGFuZGFyZCBsb3cNCiByZXNvdXJjZSBzeXN0ZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvIGhhdmUgQ0EgaW4gbWluZCwgYnV0IGZvciBz aW1wbGVyIHVzZSBjYXNlcyBUT0ZVICh0cnVzdCBvbiBmaXJzdCBzaWdodCkgcG9pbnRpbmcgdG8g YW4gYXV0aG9yaXplZF9rZXlzIGZpbGUgaXMgYWxzbyBhIGNvbnNpZGVyYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgd2FudCBzb21lIHZlcnkgdHJ1 c3RlZCBjZW50cmFsIHBpZWNlIG9mIHNvZnR3YXJlIHRvIGNyZWF0ZSBhbmQgc2lnbiBjZXJ0cyB0 aGF0IG90aGVyIHBhcnRpZXMgdHJ1c3QgaW4gb3JkZXIgdG8gZXN0YWJsaXNoIGEgcGVlciB0byBw ZWVyIHNlcnZlciBuZXR3b3JrLiBTaGFtaXJzIFNoYXJlZCBTZWNyZXQgY291bGQgYmUgcGFydA0K IG9mIHRoZSBzZXR1cC4gSW4gdGhpcyBjYXNlIHRoZSBtaW5pbXVtIGNvbXBsZXhpdHkgbmVlZGVk IHRvIGltcGxlbWVudCBhIENBIGlzIGRlc2lyYWJsZSBhbmQgT3BlblNTSC9FZDI1NTE5IGlzIGNs b3NlIHRvIHRoYXQgYXMgYSBtb2RlbCBldmVuIGlmIG5vdCB1c2luZyBPcGVuU1NIIHNvZnR3YXJl IGRpcmVjdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J biBhZGRpdGlvbiwgZXh0ZXJuYWwgcGFydGllcyBtaWdodCB3YW50IHRvIGpvaW4gYSBzdWItbmV0 IG9yIGNyZWF0ZSB0aGVpciBvd24gY29tcGF0aWJsZSBrZXkgbWFuYWdlbWVudCBpbmZyYXN0cnVj dHVyZS4gSW4gdGhpcyBjYXNlIE9wZW5TU0ggdG9vbGluZyBpcyBtdWNoIHNpbXBsZXIgdG8gdXNl IHRoYW4gT3BlblNTTCBhbmQNCiBzb21ldGhpbmcgb3BlcmF0b3JzIGRvIHJlZ3VsYXJseSBmb3Ig U1NIIGxvZ2luLiBJdCBpcyBiZW5lZmljaWFsIHRoYXQgc29tZSBzZXJ2ZXIgc29mdHdhcmUgY2Fu IGJlIGNvbmZpZ3VyZWQgdG8gYWNjZXB0IHN1Y2ggYSB1c2VyIHByb3ZpZGVkIGtleS4gTm90YWJs eSB1c2VycyBtaWdodCBmZWVsIGJldHRlciBrbm93aW5nIGEga2V5IGlzIGdlbmVyYXRlZCBieSBh IHBpZWNlIG9mIHNvZnR3YXJlIHRoZXkga25vdyBhbmQgdHJ1c3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBhYm92ZSBkb2VzIG5vdCByZXF1aXJlIHRo YXQgUVVJQyB1c2VzIE9wZW5TU0ggZGlyZWN0bHksIGp1c3QgdGhhdCB0aGVyZSBpcyBhIGxvdy1j b3N0IHRyYW5zbGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5UaGUgdXNlIG9mIEROUyBiYXNlZCBhdXRoIGlzIG5vdCB2ZXJ5IHVzZWZ1bCB3aGVuIG5l dHdvcmsgYWRkcmVzc2VzIG1pZ2h0IGJlIHJvdXRlZCBvbiBvdmVybGF5IG5ldHdvcmtzIGFuZC9v ciBoYXZpbmcgYWRkcmVzcyB0aGF0IGFyZSBub3QgYWR2ZXJ0aXNlZCBieSBETlMsIG9yIHdoZW4g bm90IGhhdmluZyBhbnkgbWVhbmluZ2Z1bA0KIGFkZHJlc3MgYXQgYWxsIChlLmcuIGNvbnRlbnQg YmFzZWQgcm91dGluZykuIEV2ZW4gd2l0aG91dCBTU0ggdG9vbGluZywgaXQgaXMgcmVhc29uYWJs eSBlYXN5IHRvIGltcGxlbWVudCBjdXN0b20gdG9vbHMgYmFzZWQgb24gdGhlIHNhbWUgY29uY2Vw dCB3aGVuIHRoZSB1bmRlcmx5aW5nIHByaW1pdGl2ZXMgYXJlIGxhcmdlbHkgdGhlIHNhbWUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNvbWUgb2YgdGhpcyBp cyBub3QgZGlyZWN0bHkgYXBwbGljYWJsZSB0byBRVUlDIGJlY2F1c2UgaXQgb3BlcmF0ZXMgdHJ1 c3QgYXQgYSBoaWdoZXIgbGV2ZWwsIGJ1dCBzdWNoIGEgc3lzdGVtIG11c3Qgc3RpbGwgbWFuYWdl IHRoZSBrZXlzIHVzZWQgYnkgUVVJQyBjb25uZWN0aW9ucyBhbmQgaXQgaXMgcHJlZmVyYWJsZSB0 aGF0DQogYWxsIGNvbXBvbmVudHMgY2FuIGFncmVlIG9uIHRoZSBiYXNpYyBwcmltaXRpdmVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR08MB243251DEE1FA201CDEA0ED9EDA320MWHPR08MB2432namp_-- From nobody Wed Dec 6 11:16: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 D81F6127005 for ; Wed, 6 Dec 2017 11:16:20 -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 cMYnwNwAwpiw for ; Wed, 6 Dec 2017 11:16:18 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A45A126CC4 for ; Wed, 6 Dec 2017 11:16:18 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id 33so11660025qtv.1 for ; Wed, 06 Dec 2017 11:16: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=JjvALUIFTOL0D5Muvok42Z6cUKbZCUWDzjaI7GO9c/g=; b=IUr1MOFb6g++HV9dX1ZSCbwHhPwIz8W8TTI4Cq+EI0mo6uR48LW+0o6ZxaZJe89oUe aYu0JsAqlyxjZz/Rm75HSMrtk7sslF+zaxVlRJWdUyYFCh5Y64D5hRZlRT//u2oNwVry Q5DdYzcCGJw3nmgDYdc5MK3q3n+ipyk1Cq/4/VM0mah1qG8QvXh8NAzRYt4YjEFVo7aB vk3V9TwpxRFukHMzFUnDtlzOZftc08Gif+ohVXdUkRYJNNNO3E3ej11rlHqb9wvq2tCY MWfjxgG+DufvUS/mAxtKTUBVptCAQWK40RuV1GN9LieyqUi4BMenHFsdrLYaB6iS1pBm 9tIA== 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=JjvALUIFTOL0D5Muvok42Z6cUKbZCUWDzjaI7GO9c/g=; b=k5UgyED+5gK88vY8nt4B0lXeu8P65S3CQt2DLpmtG+G2ad2R9HqJR21js0w2YsHbj6 BCUHclTiHR7GZ0B/2JpeFxBHVSntaDjxkCLQRsUIg3gZZ2ItY67CzN8vENNpUr0y4uwu 6ZQisEaE0Jl3om+3Xi6FBrxqSRZAne5B0gdwiKWpN4m5TDIQt+r8eA7WjfVwGDVwqvfX WeXETU+L4gKiv5msNVHoZxzRy+EhlHwWyw8Y76UznaLOIO8DCk5gflRb6UbYrkrjwrnE d8B+Op+6KF1zP3HNol7Z7witLZdKZMKALHDD8wYBw/5b/JqirS87S9qmXUlcIQ5nd5xt wfsA== X-Gm-Message-State: AKGB3mL44AKMQgbpx13dS2/MUPrVxZavYDhYsmdnzjVF/NrGY83NEKUg 2+unMgSInATn9+8V1Y1i9KxntiuNMHHKbmj51e3Fsg== X-Google-Smtp-Source: AGs4zMa9Q+988mUuAs/gKbX++DapdudS6zBZMpWw+fO5MhdnrRZac9wO+lUkB0cliN+Q0w/tw+W394cf1AaNjK9zvHU= X-Received: by 10.55.170.130 with SMTP id t124mr26530451qke.84.1512587776977; Wed, 06 Dec 2017 11:16:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Wed, 6 Dec 2017 11:15:46 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Wed, 6 Dec 2017 11:15:46 -0800 Message-ID: Subject: Re: More on demultiplexing To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05f874236fe2055fb0c9e0" 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, 06 Dec 2017 19:16:21 -0000 --94eb2c05f874236fe2055fb0c9e0 Content-Type: text/plain; charset="UTF-8" Howdy, Some additional thoughts and clarifying questions in-line. On Wed, Dec 6, 2017 at 10:41 AM, Eric Rescorla wrote: > I've been doing some thinking about the QUIC muxing story. It seems > like the case that everyone has in their head is WebRTC, so I'd like > to focus on that. It seems to me that there are two main deployment models > one might have in mind: > > I think there is a case zero here that we all agree should just work: downloading the javascript application for WebRTC should be the same over HTTPS-QUIC as it is for HTTPS-TLS. It's worth saying out loud only because we have to remember that this support is orthogonal: it neither helps nor hurts the WebRTC application's functioning once it is loaded in the browser. > - A browser unilaterally decides to support QUIC-WebRTC and just advertises > it in its SDP, so that if that browser encounters another such browser, > they do QUIC > > > - A service provider decides to do QUIC-WebRTC and turns it on for > clients which can do it. > > Probably worth pasting the usual ascii art here for the benefit of folks who think about QUIC and haven't thought about WebRTC much: +-----------+ +-----------+ | Web | | Web | | | Signaling | | | |-------------| | | Server | path | Server | | | | | +-----------+ +-----------+ / \ / \ Application-defined / \ over / \ HTTPS/WebSockets / Application-defined over \ / HTTPS/WebSockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ In your case one, the SDP flows over the signaling path, which is why this isn't an 'open box with enclosed ax' situation. For your case two, I'm assuming you mean a conference bridge situation, where the clients notify the bridge that they can handle QUIC and the bridge speaks some QUIC and some non-QUIC flavors of WebRTC. > These have different muxing requirements, and then there are also > some subchoices about whether you want everything in WebRTC to be QUIC > or just parts of it. > > > As background, current WebRTC stacks attempt to mux all of the > following protocols on the same 5-tuple: > > - STUN (for ICE and for TURN) > - TURN channels > - DTLS (for key management) > - SRTP (for media) > > Note that I don't say SCTP because that's encapsulated in DTLS. > > STUN > I think the general consensus is that we need to be able to mux STUN > with QUIC, because otherwise we would need to reinvent all of STUN > and ICE and that would be very not fun, and in some ways problematic > because the non-ICE parts of STUN don't assume any server authentication > so it's not clear how you would ever think to do them with QUIC. > > > TURN > TURN can either run over STUN, in which case it's covered by the previous > case, or it can run in channels, which are not. If you're willing to > abandon channels, then you don't have a problem. If you're not, then you > need TURN channels to work. I've heard suggestions that we should run > TURN over QUIC but I don't think that's sensible because the point of > TURN channels is to reduce overhead, and at that point you probably > could run the non-channel version of TURN without too much overhead > loss vis-a-vis QUIC and then you wouldn't have to address other problems > (e.g., server auth) that we never really resolved with TURN-TLS and would > maybe come back with QUIC. > > > DTLS and SRTP > Exactly what you need here depends on the deployment model. One might > imagine having QUIC-WebRTC in which the media and data channels are both > carried on QUIC, but you might also imagine having the data channel be > QUIC but the media being carried over RTP. I know there's active work > on a mapping for media over QUIC, but it's obviously not as straightforward > as a datachannels mapping, for which QUIC is basically a drop-in > replacement > for SCTP, so that's a consideration here. > > I agree that the QUIC substitution for the current data channel stack is pretty straight forward. On the media side, I have a question about using a PERC-like approach with QUIC. PERC's framework document gives this summary of its goals and methods: This solution framework focuses on the end-to-end privacy and integrity of the participant's media by limiting access of the end- to-end key information to trusted entities. However, this framework does give a Media Distributor access to RTP headers and all or most header extensions, as well as the ability to modify a certain subset of those headers and to add header extensions. Packets received by a Media Distributor or an endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two security contexts and two associated encryption keys: an "inner" key (an E2E key distinct for each transmitted media flow) for authenticated encryption of RTP media between endpoints and an "outer" key (HBH key) known only to media distributor and the adjacent endpoint) for the hop between an endpoint and a Media Distributor or between Media Distributor. Reference the following figure. If I am reading this correctly, the parallel method to use in PERC for QUIC would have a set of private keys for the media and would carry the media encrypted with those keys in one set of streams, but would make the header information available on a different set of streams, encrypted only at the transport layer . That makes the header information something that QUIC can pass up to the media distributor (presuming the endpoints were speaking QUIC to the media distributor), but the RTP protected as PERC intends. That looks fairly do-able to me, but my familiarity with PERC is glancing at best, so it would be useful if someone with more familiarity could comment. Supporting PERC has a lot of benefits for privacy, and I would like to make architectural support for it a requirement, if the timing allows. In the case where you wanted SRTP separately, you would then need to > either (a) figure out a way to demux SRTP and QUIC or (b) not run them > on the same 5-tuple. (b) seems natural at some level, but > we adopted BUNDLE for a reason and this would push against that. So, > it seems to me that if you want to run data-over-QUIC and > media-over-SRTP you probably do need to figure out how to demux. > > I think if you bundled all the media on one 5-tuple and had QUIC on another, the core NAT exhaustion problem would not be that bad. There are some corner cases where the media is meant to be tightly synced to the media and might end up on a different path because it is a different 5-tuple. If the paths are not equivalent latency, that can bite you. > In the case where you mux SRTP and QUIC on the same 5-tuple, you then > have to address key management. You could, of course, run DTLS-SRTP > and demux DTLS, but it seems like you could probably just use QUIC's > TLS handshake the way you run DTLS-SRTP and do the SRTP exporter from > there, so maybe you don't need to mux DTLS. > > Having to run DTLS for DTLS-SRTP seems kind of sub-optimal to me, but that's a gut reaction rather than a measured analysis. Ted > -Ekr > > > > > > > > > > > > --94eb2c05f874236fe2055fb0c9e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

Some additional thoughts and clar= ifying questions in-line.

On Wed, Dec 6, 2017 at 10:41 AM, Eric Rescorla <ekr@rtfm.= com> wrote:
I've been doing some thinking about the QUIC = muxing story. It seems
like the case that everyone has in their h= ead is WebRTC, so I'd like
to focus on that. It seems to me t= hat there are two main deployment models
one might have in mind:<= /div>


I think the= re is a case zero here that we all agree should just=20 work:=C2=A0 downloading the javascript application for WebRTC should be the= =20 same over HTTPS-QUIC as it is for HTTPS-TLS.=C2=A0 It's worth saying ou= t loud only because we have to remember that this support is orthogonal: it=20 neither helps nor hurts the WebRTC application's functioning once it is= =20 loaded in the browser.
=C2=A0
- A browser unil= aterally decides to support QUIC-WebRTC and just advertises
=C2= =A0 it in its SDP, so that if that browser encounters another such browser,=
=C2=A0 they do QUIC
=C2=A0

- A service provider decides to do QUIC-WebRTC and turns it on for=
=C2=A0 clients which can do it.


Probably worth pasting the usual ascii art here = for the benefit of folks who think about QUIC and haven't thought about= WebRTC much:

       =
         +-----------+             +-----------+
                |   Web     |             |   Web     |
                |           |  Signaling  |           |
                |           |-------------|           |
                |  Server   |   path      |  Server   |
                |           |             |           |
                +-----------+             +-----------+
                     /                           \
                    /                             \ Application-defined
                   /                               \ over
                  /                                 \ HTTPS/WebSockets
                 /  Application-defined over         \
                /   HTTPS/WebSockets                  \
               /                                       \
         +-----------+                           +-----------+
         |JS/HTML/CSS|                           |JS/HTML/CSS|
         +-----------+                           +-----------+
         +-----------+                           +-----------+
         |           |                           |           |
         |           |                           |           |
         |  Browser  | ------------------------- |  Browser  |
         |           |          Media path       |           |
         |           |                           |           |
         +-----------+                           +-----------+

In your case one, the SDP flows over the signaling pat= h, which is why this isn't an 'open box with enclosed ax' situa= tion.=C2=A0 For your case two, I'm assuming you mean a conference bridg= e situation, where the clients notify the bridge that they can handle QUIC = and the bridge speaks some QUIC and some non-QUIC flavors of WebRTC.
=C2=A0
These have different muxing requirements, and t= hen there are also
some subchoices about whether you want everyth= ing in WebRTC to be QUIC
or just parts of it.


As background, current WebRTC stacks attempt to mux al= l of the
following protocols on the same 5-tuple:

<= /div>
- STUN (for ICE and for TURN)
- TURN channels
- DTLS (for key management)
- SRTP (for media)

Note that I don't say SCTP because that's encapsulated in D= TLS.

STUN
I think the general consensus = is that we need to be able to mux STUN
with QUIC, because otherwi= se we would need to reinvent all of STUN
and ICE and that would b= e very not fun, and in some ways problematic
because the non-ICE = parts of STUN don't assume any server authentication
so it= 9;s not clear how you would ever think to do them with QUIC.

=

TURN
TURN can either run over STUN, in = which case it's covered by the previous
case, or it can run i= n channels, which are not. If you're willing to
abandon chann= els, then you don't have a problem. If you're not, then you
need TURN channels to work. I've heard suggestions that we should ru= n
TURN over QUIC but I don't think that's sensible becaus= e the point of
TURN channels is to reduce overhead, and at that p= oint you probably
could run the non-channel version of TURN witho= ut too much overhead
loss vis-a-vis QUIC and then you wouldn'= t have to address other problems
(e.g., server auth) that we neve= r really resolved with TURN-TLS and would
maybe come back with QU= IC.


DTLS and SRTP
Exactly= what you need here depends on the deployment model. One might
im= agine having QUIC-WebRTC in which the media and data channels are both
carried on QUIC, but you might also imagine having the data channel b= e
QUIC but the media being carried over RTP. I know there's a= ctive work
on a mapping for media over QUIC, but it's obvious= ly not as straightforward
as a datachannels mapping, for which QU= IC is basically a drop-in replacement
for SCTP, so that's a c= onsideration here.


I agree that the QUIC substitution for the current data channel stack is= pretty straight forward.

On the media side, I hav= e a question about using a PERC-like approach with QUIC.=C2=A0 PERC's f= ramework document gives this summary of its goals and methods:

   This solution framework focuses on the end-to-end =
privacy and
   integrity of the participant's media by limiting access of the end-
   to-end key information to trusted entities.  However, this framework
   does give a Media Distributor access to RTP headers and all or most
   header extensions, as well as the ability to modify a certain subset
   of those headers and to add header extensions.  Packets received by a
   Media Distributor or an endpoint are authenticated hop-by-hop.

   To enable all of the above, this framework defines the use of two
   security contexts and two associated encryption keys: an "inner&quo=
t; key
   (an E2E key distinct for each transmitted media flow) for
   authenticated encryption of RTP media between endpoints and an
   "outer" key (HBH key) known only to media distributor and the
   adjacent endpoint) for the hop between an endpoint and a Media
   Distributor or between Media Distributor.  Reference the following
   figure.
If I am reading this correctly, the parallel met= hod to use in PERC for QUIC would have a set of private keys for the media = and would carry the media encrypted with those keys in one set of streams, = but would make the header information available on a different set of strea= ms, encrypted only at the transport layer .=C2=A0 That makes the header inf= ormation something that QUIC can pass up to the media distributor (presumin= g the endpoints were speaking QUIC to the media distributor), but the RTP p= rotected as PERC intends.=C2=A0

That looks fa= irly do-able to me, but my familiarity with PERC is glancing at best, so it= would be useful if someone with more familiarity could comment.=C2=A0 Supp= orting PERC has a lot of benefits for privacy, and I would like to make arc= hitectural support for it a requirement, if the timing allows.

In the case where you wanted SRTP separately, you would= then need to
either (a) figure out a way to demux SRTP and QUIC = or (b) not run them
on the same 5-tuple.=C2=A0 (b) seems natural = at some level, but
we adopted BUNDLE for a reason and this would = push against that. So,
it seems to me that if you want to run dat= a-over-QUIC and
media-over-SRTP you probably do need to figure ou= t how to demux.

I think if you = bundled all the media on one 5-tuple and had QUIC on another, the core NAT = exhaustion problem would not be that bad.=C2=A0 There are some corner cases= where the media is meant to be tightly synced to the media and might end u= p on a different path because it is a different 5-tuple.=C2=A0 If the paths= are not equivalent latency, that can bite you.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
In the case where you mux SRTP and QUIC on the same 5-tuple, you the= n
have to address key management. You could, of course, run DTLS-= SRTP
and demux DTLS, but it seems like you could probably just us= e QUIC's
TLS handshake the way you run DTLS-SRTP and do the S= RTP exporter from
there, so maybe you don't need to mux DTLS.=


Having to run D= TLS for DTLS-SRTP seems kind of sub-optimal to me, but that's a gut rea= ction rather than a measured analysis.

Ted

=C2=A0
-Ekr

<= br>




<= br>





--94eb2c05f874236fe2055fb0c9e0-- From nobody Wed Dec 6 11:17: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 06DA1127909 for ; Wed, 6 Dec 2017 11:17:31 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6AuG2Ckk2jm for ; Wed, 6 Dec 2017 11:17:29 -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 94F71127977 for ; Wed, 6 Dec 2017 11:17:29 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id r6so8773737itr.3 for ; Wed, 06 Dec 2017 11:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=ZYshykN6WgvTl8p6LKgYhtWYwuohS7hmCGGb+ghV6EQ=; b=HefDSm6IfeY6T8f3fqt6k6EJV5U7hRIbO4W9zWkvRSWdRglkvGWiPFCmZjWZJfxquP YUtGTx31q2yDlITJb4/kR2I8hQ654N5aIz9HK8aJ/ZdzRaXrgD/MVB9yQ+RMWt7B8V2i H2I0Afv1m7Ur5BjMbPEFcb9VUPFgYDEBcGHBpA2L268cgUV3CUb4kBIYcywoCP2eFrxr hrie11V3wCF4v3J91BWJjTTDLxmrFyLB6zb3+aGC7ERJmArOfKb4zIxgrxs32kyM7nUO yFwx/hAPrrdH9VzvpNTbdLkd4b/YoQleimaV20Ty8EziYsBr24ykG67h7hptWzZpL9vU 0cRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=ZYshykN6WgvTl8p6LKgYhtWYwuohS7hmCGGb+ghV6EQ=; b=D04V4h1+YrnatKMl/ktsXfubHWVYoboKU1bJ0J7TRYoSfivZYHdEqa044gw/kjeL3a yhIjmoUlXR3ZHYkI2rKZlUK43fc3HHdsGJRjM+h5s4lAAfGJ5IQsvDRWfBUs5w6JF3HL R7U34bN1Wc6TLbNHB6wwtju9GUuXpnjm/YJrFnBEspU5y91bsaEtKPicRt9h4tSXXGH3 r45GOea0Zg1iDjzeOXqt+e7d3nj9kLA5w0XcCQfgojSR/hCKIfHwYxgx49F8pqMjBTz8 363LhCbp7p374111NqUIJQsXPuWr0ZYsz+5zLIFTtCxwcM++g8mjwmWhBkdd59rbydeb zyvw== X-Gm-Message-State: AJaThX7TGHRL5ZoR/bQ0jYPlx732sEdFswMAhkTINfxDPUpKlWWJdPii MW86DIpkLnLJDR4AJ9j9Fof6maycuehxySHDBMQ= X-Google-Smtp-Source: AGs4zMbA2cfC3iKCKj7hCer1u63Sqg5bf5SGcXmYyEhrXjxLg7zmft4jHVcwUhFuqi80F8JxFdTN0B5NZJZnVzBlcrI= X-Received: by 10.107.3.86 with SMTP id 83mr36416876iod.297.1512587848916; Wed, 06 Dec 2017 11:17:28 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Dec 2017 11:17:27 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Dec 2017 11:17:27 -0800 Message-ID: Subject: Re: More on demultiplexing To: Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113eb83a6d21e0055fb0cdc9" 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, 06 Dec 2017 19:17:31 -0000 --001a113eb83a6d21e0055fb0cdc9 Content-Type: text/plain; charset="UTF-8" On 6 December 2017 at 19.42.37, Eric Rescorla (ekr@rtfm.com) wrote: I've been doing some thinking about the QUIC muxing story. It seems like the case that everyone has in their head is WebRTC, so I'd like to focus on that. Well, the concern is probably that QUIC might not have a routable UDP port otherwise, and WebRTC is likely available. Another case could be port 53 for QUIC/DNS. --001a113eb83a6d21e0055fb0cdc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 6 December 2017 a= t 19.42.37, Eric Rescorla (ekr@rtfm.com= ) wrote:
I've been doing some thin= king about the QUIC muxing story. It seems
like the case that everyone has in their head is WebRTC, s= o I'd like
to focus on= that.

Well, the concern is probabl= y that QUIC might not have a routable UDP port otherwise, and WebRTC is lik= ely available.

Another case could be port 53 for QUIC/DNS.

--001a113eb83a6d21e0055fb0cdc9-- From nobody Wed Dec 6 11:25: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 8FC711275FD for ; Wed, 6 Dec 2017 11:25:34 -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 kPbaoSDjs1GH for ; Wed, 6 Dec 2017 11:25:33 -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 ED6DF12426E for ; Wed, 6 Dec 2017 11:25:32 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id p128so2007645yba.7 for ; Wed, 06 Dec 2017 11:25:32 -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=YbzHw1dpJCGcbAVQ6PQDEHav4BGMrbqIbEmVKgLBwk8=; b=T+1LqpTGlka1q7dxC2sYxlWgHYctT5ADZ9ZcwVtHe55E9PlUnoUmz8KbzKps1+mhb3 7wrpB9LYHhqlAaZTMgr84NiL7OyCyGcTTid9Uix930YhnzvjOmV9fDgoyrDoM3rCAQ+b Lqkb0kvHnci4mRaRm4Vi7L3xwkQ9tySIb88d2jUTryI2iM73N+gocm7773JqRmH7KXGf 0gzRwxJdYkLq1oTBzNscuBaKOZZ5ZixelDxvkOubxZqIzICBgfDNTS06YLCJINsRftxI 7vQlXPpAh2Y9RWkRV/1ALEvrqUGFeZeyKPXHOshk2jk+UFFADUscm9tE9IIWXr4H3Ddt HLNw== 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=YbzHw1dpJCGcbAVQ6PQDEHav4BGMrbqIbEmVKgLBwk8=; b=pmdU1kV8xMM0+HHeW79tqlbWH/dS4Tkr++3NkPhfTMehWqDIIvxfEofcPlsdiMX6MJ F3qeNceCPE2Yp5a0ebGfA+jBF6Oerp/vqEN/cG5XzLMAFpOb6m+o6ETXkj7n+M3EI3Ed P7yndMTJ+ifTQfgR9TjpDENjVweucJCSC5246LAQ7QGdZRiW6NhCZGhLAaVYH4EMohZ3 GWlEKda04EuhXdfOyPvnEc7TOUUdEnyUmliLDGpJlhS84FR7VJaAoMRWdLGje6/gISrv shkfJgCUthM9nakHul/hHpZqgk8SdHzEh4rXpu+0Gfn7SNze8M7/ai2un0Wnowv5V9H3 Q3LQ== X-Gm-Message-State: AJaThX5ZA7kVvT7GCOk2rx4WpalT8QEfwtqAXJ0DDdoYEPG6ym0Ycgy8 mf/cB893MrOuU0Jg4tQd+HAC1AvRQSj3BUL/hkcIUQ== X-Google-Smtp-Source: AGs4zMbx/AzcwGEN3eE6Se4eMe/xwPICb/37tTjGWVfQkUM31uQoLvtIC4xDLkBjdSf5F1kl4R2rHh96M29ZEwgwc/E= X-Received: by 10.37.107.82 with SMTP id o18mr15694087ybm.293.1512588332131; Wed, 06 Dec 2017 11:25:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 11:24:51 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 6 Dec 2017 11:24:51 -0800 Message-ID: Subject: Re: More on demultiplexing To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08267d303a80ec055fb0ead1" 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, 06 Dec 2017 19:25:34 -0000 --089e08267d303a80ec055fb0ead1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 6, 2017 at 11:17 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > On 6 December 2017 at 19.42.37, Eric Rescorla (ekr@rtfm.com) wrote: > > I've been doing some thinking about the QUIC muxing story. It seems > like the case that everyone has in their head is WebRTC, so I'd like > to focus on that. > > Well, the concern is probably that QUIC might not have a routable UDP por= t > otherwise, and WebRTC is likely available. > I don't understand what you are saying here. WebRTC does not have a defined port. -Ekr > Another case could be port 53 for QUIC/DNS. > --089e08267d303a80ec055fb0ead1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 6, 2017 at 11:17 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <m= ikkelfj@gmail.com> wrote:
<= div style=3D"word-wrap:break-word;line-break:after-white-space">
On 6 December 2017 at 19.42.37, Eric Rescorla (ekr@rtfm.com) wrote:
I've been doing some thinking ab= out the QUIC muxing story. It seems
like the case that everyone has in their head is WebRTC, so I'= ;d like
to focus on that.<= /div>

Well, the concern is probabl= y that QUIC might not have a routable UDP port otherwise, and WebRTC is lik= ely available.

I don't understand what you a= re saying here. WebRTC does not have a defined port.

-Ekr

=C2=A0

Anothe= r case could be port 53 for QUIC/DNS.


--089e08267d303a80ec055fb0ead1-- From nobody Wed Dec 6 11:39: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 6B2DC127873 for ; Wed, 6 Dec 2017 11:39:04 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4MBsdyCNMff for ; Wed, 6 Dec 2017 11:39:03 -0800 (PST) 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 DFC15128959 for ; Wed, 6 Dec 2017 11:39:02 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id m11so21516574iti.1 for ; Wed, 06 Dec 2017 11:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=TbfzzHfwjx+vCwspmc4q97WUEXf7pXJixTohD0l0R78=; b=q6OGeE0KQrkpH3XrF2w01Wg8rz+d+5buEGVj8/ZfiWj8NlxXRsAo7nqUvQRu5WGhrW q0yo3eK3YJMc+0XYbdxv9l3x+2qM1Wse+tE7pepu0Z4FTQi0bhSL700tXLvlw/04nG16 PKBq4vayCjineBf17512s0sKQDHJuX8nrj/UuifdEJ89chHoB0UsgQN6YkVCo8vNUwgf b9z3O5hXE5blwK3m30W9RZnxv3MdvPjNcGSJjBGOH9eA5133xifApmLC5qL3Gr00Q9xp mLAVbwHDHE2WoEQMBVbqyQwQMLe/m1B5BQ/BCevH64hevPPiLs4WsaVoktfINIwDGSoV ctmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=TbfzzHfwjx+vCwspmc4q97WUEXf7pXJixTohD0l0R78=; b=a2sIfiT+27Mqen8/ZLU64tv/uwmPi+l+GfOy4pbU1rCc1F9aLolYFF03kDGWFL4j7t L+T6QE1K3EiR8wDePuWgZK7fEo2kM+4C8HlKTUbxeEPlFDgr33K+4Eu7H5/QOIS39oP8 y1ktXpXLD6XCEVOqvuNwDkA7vpui2gxQveTgSWqe8LFiapxB7HqjhDJ7yYkcVmjp7TKD MeTBha6NXw5Y2S8mFUWTtchjCQrRh/oHTyK6GDJLO3WphkFhCyu5Ih/uTurNB6PTGY6E FcPQ1N+Oq9zySm6MB6CIAEDywaqp3gq8zP38jtiOGEQzx+jCG+QGLfEqE6982Acmcu3u hqUQ== X-Gm-Message-State: AJaThX4jT3a3S5RGkl5ik9Wg3cuabXGAaWJRJsGqdzs1DfVoLBcFHfOi qJCv+7emsXIMdO59/nUL5QdRb/1zTFHxWwtvj70pWg== X-Google-Smtp-Source: AGs4zMb9mC53cNRHAR0MJGli8Cm1VhvzXjaeODMAiqUDDUzcN5etHTv7M4mE3PULJqBOKg6K559/gt0iZ5OTOYmWwgI= X-Received: by 10.107.164.225 with SMTP id d94mr33710330ioj.175.1512589142300; Wed, 06 Dec 2017 11:39:02 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Dec 2017 11:39:01 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 6 Dec 2017 11:39:01 -0800 Message-ID: Subject: Re: More on demultiplexing To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11422366849e18055fb11ac9" 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, 06 Dec 2017 19:39:04 -0000 --001a11422366849e18055fb11ac9 Content-Type: text/plain; charset="UTF-8" I don't understand what you are saying here. WebRTC does not have a defined port. I was considering corporate and server firewalls, e.g. having QUIC traffic piggy backing on open ports for things like video chat, but come to think of it, this has more to do with NAT traversal. --001a11422366849e18055fb11ac9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I don't und= erstand what you are saying here. WebRTC does not have a defined port.


<= /div>
I was considering corporate and server firewalls, e.g. having QUI= C traffic piggy backing on open ports for things like video chat, but come = to think of it, this has more to do with NAT traversal.

--001a11422366849e18055fb11ac9-- From nobody Wed Dec 6 11:56: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 24BAA124D85 for ; Wed, 6 Dec 2017 11:56:55 -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 CeIYH9Y8_aVO for ; Wed, 6 Dec 2017 11:56:52 -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 C50E91243FE for ; Wed, 6 Dec 2017 11:56:52 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id m129so2027937ywb.11 for ; Wed, 06 Dec 2017 11:56: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=iTadUJ5rqrkWPniAmapcmelHt50oGHW0kvaXUaiu9vM=; b=lmeoMy5E+sYsRUJ9IMIrQ8OyE+NtS6GFcYD/Pwl5k8v68g1PAgMZFRGV2JBHZEdPK6 WEdFT4RlAsObjtqWbHC4UihoNGgDRY0i2KqhzoD6XVDgin3ulbN6JX7nZoUNw9PWSkKp nH/jAqY0nA0kZcetOkosJgidMKDnfesVc76V4E+sDc6clO2sXmK+CsXJrjdnDn2Vw6g6 J5PUCYFjrCTsXMHSMRsfG6SPltfFcAgkLhAjHsTPtuCE6FNerKEMxeNr0RychISrCVTv /p4indAgu0pQC2+EDWuvTC9QTPFlEzAi6l/78zC1+oOjgCzTrjWoI9OYuMF7sZYXY3Jw WZVQ== 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=iTadUJ5rqrkWPniAmapcmelHt50oGHW0kvaXUaiu9vM=; b=oRCu/gOEQHnhQpDW2ewNvRcvcvdoa5vey6qkgYIyEah0SxX/SsxOQHsTuynoxLJgwL 1Lk16ELaHQ6RznNDM0Q7nNHOz1Bldi76LCWLy4hwoorLeh5oHOsi9gWEfH8FOwz9Q6qd 4jcb3+5/xJgUHPrdU4tqex9uBbgPg3f7ai79itA60azaWld/md3hNDErZCiR8+Fjkn3W TpHPXbbLpy6Q3uG+F62BZ4oCD1kw64HBIRCCwZac8BltrAn4YhwDxxjrsdaVONtPcaxC 7kujeuXxFR2AUn0MGTDI9ULuV336kyEltEietDSMruzbGKefwRTrm770Y5Yfv+6vyYFe QOxw== X-Gm-Message-State: AJaThX50Ddtr2pUwfbzKtcN9Rghd+E14pyjVR4nJBvaqfWbuYlW1t3bD 4S3XC2eu2VnDipg7UvAXGabLHF7zB7PK9psd4Ig= X-Google-Smtp-Source: AGs4zMbIqLzDYCNX5bVBUSv+CHD6tey38ZgAgUYlSrrYrq5Tek5HduHYabX7fmEXTtxwqKgPSiv5q6rMbynSXOzsNM4= X-Received: by 10.13.248.2 with SMTP id i2mr18227055ywf.448.1512590211851; Wed, 06 Dec 2017 11:56:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.129.7 with HTTP; Wed, 6 Dec 2017 11:56:51 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD851F75@DGGEMM506-MBS.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD851F75@DGGEMM506-MBS.china.huawei.com> From: Spencer Dawkins at IETF Date: Wed, 6 Dec 2017 13:56:51 -0600 Message-ID: Subject: Re: Invariants draft To: Roni Even Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c07f7f444acde055fb15afc" 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, 06 Dec 2017 19:56:55 -0000 --94eb2c07f7f444acde055fb15afc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking with no hats ... On Wed, Dec 6, 2017 at 4:44 AM, Roni Even wrote: > Hi, > I think that the document needs some more information about why these > fields are invariants. > For example, we can have a new version with a message type that will mean > that the header format from the next message changes and the connection I= D > will be in a different position from the next message with higher packet > number. I assume that this is not something we want if there is a need t= o > support routing based on connection ID by intermediary who will not suppo= rt > this new version. So if routing support is mandatory it will be good to > mention it in this document. > I want to thank Martin for putting together version -00 of this draft. It's already very helpful. When I made the suggestion to progress work on invariants as a separate draft, I was thinking that the problem that solves, is making it easier to update QUIC specifications without simultaneously reopening the list of invariants and/or arguing about adding to that list. IIUC Roni's suggestion, I'm thinking that it's also worth adding information about why these invariants are invariant, in case we ever start arguing about taking an invariant away. I can easily imagine that some creative security person will, some day, think of some way that one of these invariants can be exploited to tell a third party something that the two endpoints didn't intend to share. If (when?) that happens, it would be good to have a clear understanding of the value of any invariant that's questioned, so we don't have to agree on that while we're trying to decide what to do, after an exploit is identified. Again, wearing no hats. Spencer > Roni > > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson > > Sent: =D7=99=D7=95=D7=9D =D7=95 01 =D7=93=D7=A6=D7=9E=D7=91=D7=A8 2017 = 06:10 > > To: QUIC WG > > Subject: Invariants draft > > > > I've just submitted a personal draft that describes the invariants that > I think > > we agreed to in Singapore. > > > > https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants > > > > This is just me for the moment (though Jana and Mike were very helpful = in > > reviewing an even draftier draft). It also assumes a few things about > the > > current drafts that aren't yet true, and may not even become true. Don= 't > > focus too much on the specific content of what is in or out, because > that sort > > of detail is easy to fix. > > > > More than content, I'd like to concentrate on the general approach and > > scope. My hope is that we can agree that those are more or less correc= t. > > And then adopt the draft. A draft like this should help address > questions > > people have been asking about what can and cannot change between QUIC > > versions. > > --94eb2c07f7f444acde055fb15afc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking with no hats ...

On Wed, Dec 6, 2017 at 4:44 AM, Roni Even <ron= i.even@huawei.com> wrote:
H= i,
I think that the document needs some more information about why these field= s are invariants.
For example, we can have a new version with a message type that will mean t= hat the header format from the next message changes and the connection ID w= ill be in a different position from the next message with higher packet num= ber.=C2=A0 I assume that this is not something we want if there is a need t= o support routing based on connection ID by intermediary who will not suppo= rt this new version. So if routing support is mandatory it will be good to = mention it in this document.

I want to = thank Martin for putting together version -00 of this draft. It's alrea= dy very helpful.

When I made the suggestion to pro= gress work on invariants as a separate draft, I was thinking that the probl= em that solves, is making it easier to update QUIC specifications without s= imultaneously reopening the list of invariants and/or arguing about adding = to that list.

IIUC Roni's suggestion, I'm = thinking that it's also worth adding information about why these invari= ants are invariant, in case we ever start arguing about taking an invariant= away.

I can easily imagine that some creative sec= urity person will, some day, think of some way that one of these invariants= can be exploited to tell a third party something that the two endpoints di= dn't intend to share. If (when?) that happens, it would be good to have= a clear understanding of the value of any invariant that's questioned,= so we don't have to agree on that while we're trying to decide wha= t to do, after an exploit is identified.=C2=A0

Aga= in, wearing no hats.

Spencer
=C2=A0
Roni

> -----Original Message-----
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Martin Thomson
> Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=95 01 =D7=93=D7=A6=D7=9E=D7=91=D7=A8= 2017 06:10
> To: QUIC WG
> Subject: Invariants draft
>
> I've just submitted a personal draft that describes the invariants= that I think
> we agreed to in Singapore.
>
> https://datatracker.ietf.org= /doc/html/draft-thomson-quic-invariants
>
> This is just me for the moment (though Jana and Mike were very helpful= in
> reviewing an even draftier draft).=C2=A0 It also assumes a few things = about the
> current drafts that aren't yet true, and may not even become true.= =C2=A0 Don't
> focus too much on the specific content of what is in or out, because t= hat sort
> of detail is easy to fix.
>
> More than content, I'd like to concentrate on the general approach= and
> scope.=C2=A0 My hope is that we can agree that those are more or less = correct.
> And then adopt the draft.=C2=A0 A draft like this should help address = questions
> people have been asking about what can and cannot change between QUIC<= br> > versions.


--94eb2c07f7f444acde055fb15afc-- From nobody Wed Dec 6 13:01: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 116701270A3 for ; Wed, 6 Dec 2017 13:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H8C8uk3u6Td for ; Wed, 6 Dec 2017 13:01:55 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 ADA5E126CF9 for ; Wed, 6 Dec 2017 13:01:55 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id f69so3498997oig.10 for ; Wed, 06 Dec 2017 13:01: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=LZP/vBi5XwZBbnqkPcLP73V2MhBy4kOOrC1Y34GE4co=; b=RXpsJHXFn5LdL77BNc7dmKwPaP8IvYadzXJ7e05EW05aNHVPvStveR1qd9gND33Y3e 5XX9Z6pCHXTXkdXN2wXz9vMmnDN8e7htqCdl1SR0AaFjar1X8UPRN6yuiURzk5ktX/uC m2nemKpvvC9Y5gs0ksXqVFdlPxcWAF8MUNhHio8jFpUgJd4aop/RBve8aWMRLYEwUP83 NUKKyja3yaXJCJ/zgeUEMAqSGk1X30VlInNFM2pKyNFWQX2WPGtI+P3SjrQIwgMp10fQ CBVLsVhXTaiq1/QAL/Wx6nPqLQCsfG/7f08ihzLcO2VgfR0BOUqGww+GNNe6FZgfLS5e MBqw== 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=LZP/vBi5XwZBbnqkPcLP73V2MhBy4kOOrC1Y34GE4co=; b=Y2mxp1xcrxdVFs4iYFaP16FSj8pYXW4XhjMJ4ZdIS/UpP5LEtrFjHm5iZZHnnKZvZv 3c6skLRELbt/mxN8HgXmDtQuPG8oxaRpioRrtdpEoVq31v7QxA6j2locPIni1BfA36ts A8ehM5JfPsiVZIgS/vVCgW6JsSuio4KmDPeHYSs05/6VFh6DeLP7tlyyb7bHbakYVXy3 UbA81jgFVaKDJ1K0h2BvaUiFhGqs9/xObCrHWuPYhDGAjUCK5syJQ+zGo+Cli+PzkPi2 azMPvz1zDY6JzWp6tFZFK0pZYo+utsuPY+Al4bBdaYPH04UN2ZihRo10w4f9xQE0n+/h zR1A== X-Gm-Message-State: AJaThX4j93ooYWh4gTxOBxxytnsTdCB8XN2KvJbCCyorIPJKaO1k8iqC hADmUyOdhRt5eF0CNbZ2YcFkBNuYryHTWUif02Y= X-Google-Smtp-Source: AGs4zMbPEpxdjzkK02jxKtvsWG8gUPcGtMgo06DeP0wJpXgOYDEurXx6G2OFJaHQQVOSTck4asoE10/vZawJ0EsRnXY= X-Received: by 10.202.166.206 with SMTP id t75mr21327642oij.28.1512594114959; Wed, 06 Dec 2017 13:01:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Wed, 6 Dec 2017 13:01:54 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD851F75@DGGEMM506-MBS.china.huawei.com> From: Martin Thomson Date: Thu, 7 Dec 2017 08:01:54 +1100 Message-ID: Subject: Re: Invariants draft To: Spencer Dawkins at IETF Cc: Roni Even , 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, 06 Dec 2017 21:01:57 -0000 On Thu, Dec 7, 2017 at 6:56 AM, Spencer Dawkins at IETF wrote: > IIUC Roni's suggestion, I'm thinking that it's also worth adding information > about why these invariants are invariant, in case we ever start arguing > about taking an invariant away. I can appreciate the desire for more detail, though the headline is already there: we want to preserve the ability to deploy a new version of QUIC. The piece that is perhaps missing is one that Jana convinced me to remove, namely the reasons for connection ID being in the draft. Some of that is in the section on connection ID. > I can easily imagine that some creative security person will, some day, > think of some way that one of these invariants can be exploited to tell a > third party something that the two endpoints didn't intend to share. If > (when?) that happens, it would be good to have a clear understanding of the > value of any invariant that's questioned, so we don't have to agree on that > while we're trying to decide what to do, after an exploit is identified. I worry less about exploitation of the invariants, but of the not-invariants that we inadvertently expose by virtue of only deploying a limited number of versions. All the stuff in the appendix, basically. And that is a list that I wish were shorter. From nobody Wed Dec 6 15:44: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 829C3128AA1 for ; Wed, 6 Dec 2017 15:44:00 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MlsXGG8iaH4 for ; Wed, 6 Dec 2017 15:43:58 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CCC128954 for ; Wed, 6 Dec 2017 15:43:58 -0800 (PST) Received: from [81.187.2.149] (port=45465 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eMjM4-00066Q-C2; Wed, 06 Dec 2017 23:43:56 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: More on demultiplexing From: Colin Perkins In-Reply-To: Date: Wed, 6 Dec 2017 23:43:53 +0000 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <61C0885E-3363-4B70-B64F-C471A4A16B3C@csperkins.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 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, 06 Dec 2017 23:44:00 -0000 > On 6 Dec 2017, at 18:41, Eric Rescorla wrote: >=20 > I've been doing some thinking about the QUIC muxing story. It seems > like the case that everyone has in their head is WebRTC, so I'd like > to focus on that. It seems to me that there are two main deployment = models > one might have in mind: >=20 > - A browser unilaterally decides to support QUIC-WebRTC and just = advertises > it in its SDP, so that if that browser encounters another such = browser, > they do QUIC >=20 > - A service provider decides to do QUIC-WebRTC and turns it on for > clients which can do it. >=20 > These have different muxing requirements, and then there are also > some subchoices about whether you want everything in WebRTC to be QUIC > or just parts of it. >=20 >=20 > As background, current WebRTC stacks attempt to mux all of the > following protocols on the same 5-tuple: >=20 > - STUN (for ICE and for TURN) > - TURN channels > - DTLS (for key management) > - SRTP (for media) >=20 > Note that I don't say SCTP because that's encapsulated in DTLS. >=20 > STUN > I think the general consensus is that we need to be able to mux STUN > with QUIC, because otherwise we would need to reinvent all of STUN > and ICE and that would be very not fun, and in some ways problematic > because the non-ICE parts of STUN don't assume any server = authentication > so it=E2=80=99s not clear how you would ever think to do them with = QUIC. Agree. > TURN > TURN can either run over STUN, in which case it's covered by the = previous > case, or it can run in channels, which are not. If you're willing to > abandon channels, then you don't have a problem. If you're not, then = you > need TURN channels to work. I've heard suggestions that we should run > TURN over QUIC but I don't think that's sensible because the point of > TURN channels is to reduce overhead, and at that point you probably > could run the non-channel version of TURN without too much overhead > loss vis-a-vis QUIC and then you wouldn't have to address other = problems > (e.g., server auth) that we never really resolved with TURN-TLS and = would > maybe come back with QUIC. Do TURN channels need to demux with QUIC? I was assuming we=E2=80=99d = run STUN/TURN channels to a server, or QUIC+STUN+DTLS+SRTP to a server, = but not both? (i.e., it=E2=80=99s either a TURN server or a media = endpoint, but not both). > DTLS and SRTP > Exactly what you need here depends on the deployment model. One might > imagine having QUIC-WebRTC in which the media and data channels are = both > carried on QUIC, but you might also imagine having the data channel be > QUIC but the media being carried over RTP. I know there's active work > on a mapping for media over QUIC, but it's obviously not as = straightforward > as a datachannels mapping, for which QUIC is basically a drop-in = replacement > for SCTP, so that's a consideration here. >=20 > In the case where you wanted SRTP separately, you would then need to > either (a) figure out a way to demux SRTP and QUIC or (b) not run them > on the same 5-tuple. (b) seems natural at some level, but > we adopted BUNDLE for a reason and this would push against that. So, > it seems to me that if you want to run data-over-QUIC and > media-over-SRTP you probably do need to figure out how to demux. agree. > In the case where you mux SRTP and QUIC on the same 5-tuple, you then > have to address key management. You could, of course, run DTLS-SRTP > and demux DTLS, but it seems like you could probably just use QUIC's > TLS handshake the way you run DTLS-SRTP and do the SRTP exporter from > there, so maybe you don't need to mux DTLS. Exporting SRTP keys from the QUIC handshake seems sensible, but is an = extra level of specification complexity. I suspect we=E2=80=99ll want = SRTP demux short term, key export in medium term, and RTP-in-QUIC in = longer term. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Dec 6 15:47: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 6C9D5128A32 for ; Wed, 6 Dec 2017 15:47:48 -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 RjTF_SOArQQT for ; Wed, 6 Dec 2017 15:47:46 -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 5D90C12871F for ; Wed, 6 Dec 2017 15:47:46 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id n25so2272206ywh.10 for ; Wed, 06 Dec 2017 15:47: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=jxAYG4WzX46RjUVHhPBXF9Snll+m4/v5tTBcDVNPe9I=; b=XL7q9pLlupDaVc73/jm5ctdxmC9UjZDQdBq8bSm8xmt/OEElmJQeVZVreTssmujjK4 6ixN6bzoZOmHCv4xmE+7B2k/7feJKhZazVMVvQC+FKb4hw4xgHTXDZTJKMWfEFqObpY+ zF+BBbuErx7ah7C86JAi4BSd2rDMMvG93j+ZAQmclbrWKCmoV8FESm4Izry6Lj59k8G1 s5iSZMdy7kx4H0/tLvuGVHEMloceJnTaoOl5RnNOnvV0+ZYd9y29hbjvL2sV1wpI21a6 ONs3j9RJVeNxfhX8059nE0XoNbQYOlO34GRHxfzjkwi+k04sF5ivUwn7mM/F+Dk2GCxH Fcyw== 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=jxAYG4WzX46RjUVHhPBXF9Snll+m4/v5tTBcDVNPe9I=; b=M3oHuXry5LPCR2A1s7gyDq2Ch7tbpZ9DnycUy7p/el6iU72yZjKXx2JW7yNc4uJUuN Cdxv/Bxpi3Hg6Fv3xeVYsoHkgnZP16uNOjPhw0T651eFUtFo+vE0Us/E8HytK0a9OKBA nfmnoxNuIKqAlR9jyb+ZOQ1yo3gyniqYl5kw2U21rFz3AuK373DWdEOB8yOIQ/xrjh7Z MhEz5dFfzIM5Jc3e79FgnzKkVF8yzcMfnPfo1jlVizw6A3B7QOir18dt/fWpBSSo4IcF aUzLRwe6XUXalPBlmeoWLy/DQo/Gw9IQ3dcgTq4AnidOPQbpaXc68ZfXwlYtBviNK9Fs UxkQ== X-Gm-Message-State: AJaThX5y5jetBj07K4p9e1p7OCvLj9MvabKp54aQcCBMriqQ47DK+kPa nIT/ozt0MxMbvViQ9SIl8CCrQuYBctnjS+juFoElcwEy X-Google-Smtp-Source: AGs4zMaW+ZbQmLqEW6pMAonpNkArBVsA3zIYDOAriMsImn+juXiY+uJUk0BXysQnCjwqxYue9zJvs2Aypm7G/sSI59o= X-Received: by 10.129.222.9 with SMTP id k9mr17689081ywj.47.1512604065573; Wed, 06 Dec 2017 15:47:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Wed, 6 Dec 2017 15:47:04 -0800 (PST) In-Reply-To: <61C0885E-3363-4B70-B64F-C471A4A16B3C@csperkins.org> References: <61C0885E-3363-4B70-B64F-C471A4A16B3C@csperkins.org> From: Eric Rescorla Date: Wed, 6 Dec 2017 15:47:04 -0800 Message-ID: Subject: Re: More on demultiplexing To: Colin Perkins Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043d048803b616055fb494ef" 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, 06 Dec 2017 23:47:48 -0000 --f403043d048803b616055fb494ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 6, 2017 at 3:43 PM, Colin Perkins wrote: > > > On 6 Dec 2017, at 18:41, Eric Rescorla wrote: > > > > I've been doing some thinking about the QUIC muxing story. It seems > > like the case that everyone has in their head is WebRTC, so I'd like > > to focus on that. It seems to me that there are two main deployment > models > > one might have in mind: > > > > - A browser unilaterally decides to support QUIC-WebRTC and just > advertises > > it in its SDP, so that if that browser encounters another such browse= r, > > they do QUIC > > > > - A service provider decides to do QUIC-WebRTC and turns it on for > > clients which can do it. > > > > These have different muxing requirements, and then there are also > > some subchoices about whether you want everything in WebRTC to be QUIC > > or just parts of it. > > > > > > As background, current WebRTC stacks attempt to mux all of the > > following protocols on the same 5-tuple: > > > > - STUN (for ICE and for TURN) > > - TURN channels > > - DTLS (for key management) > > - SRTP (for media) > > > > Note that I don't say SCTP because that's encapsulated in DTLS. > > > > STUN > > I think the general consensus is that we need to be able to mux STUN > > with QUIC, because otherwise we would need to reinvent all of STUN > > and ICE and that would be very not fun, and in some ways problematic > > because the non-ICE parts of STUN don't assume any server authenticatio= n > > so it=E2=80=99s not clear how you would ever think to do them with QUIC= . > > Agree. > > > TURN > > TURN can either run over STUN, in which case it's covered by the previo= us > > case, or it can run in channels, which are not. If you're willing to > > abandon channels, then you don't have a problem. If you're not, then yo= u > > need TURN channels to work. I've heard suggestions that we should run > > TURN over QUIC but I don't think that's sensible because the point of > > TURN channels is to reduce overhead, and at that point you probably > > could run the non-channel version of TURN without too much overhead > > loss vis-a-vis QUIC and then you wouldn't have to address other problem= s > > (e.g., server auth) that we never really resolved with TURN-TLS and wou= ld > > maybe come back with QUIC. > > Do TURN channels need to demux with QUIC? I was assuming we=E2=80=99d run > STUN/TURN channels to a server, or QUIC+STUN+DTLS+SRTP to a server, but n= ot > both? (i.e., it=E2=80=99s either a TURN server or a media endpoint, but n= ot both). > You might (for instance) start sending data to a TURN server and then have a srflx candidate succeed. > > In the case where you mux SRTP and QUIC on the same 5-tuple, you then > > have to address key management. You could, of course, run DTLS-SRTP > > and demux DTLS, but it seems like you could probably just use QUIC's > > TLS handshake the way you run DTLS-SRTP and do the SRTP exporter from > > there, so maybe you don't need to mux DTLS. > > Exporting SRTP keys from the QUIC handshake seems sensible, but is an > extra level of specification complexity. I suspect we=E2=80=99ll want SRT= P demux > short term Note that if you don't expert keys, then you need DTLS demux (or no bundle) -Ekr --f403043d048803b616055fb494ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 6, 2017 at 3:43 PM, Colin Perkins <csp@csperkins.org&g= t; wrote:

> On 6 Dec 2017, at 18:41, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I've been doing some thinking about the QUIC muxing story. It seem= s
> like the case that everyone has in their head is WebRTC, so I'd li= ke
> to focus on that. It seems to me that there are two main deployment mo= dels
> one might have in mind:
>
> - A browser unilaterally decides to support QUIC-WebRTC and just adver= tises
>=C2=A0 =C2=A0it in its SDP, so that if that browser encounters another = such browser,
>=C2=A0 =C2=A0they do QUIC
>
> - A service provider decides to do QUIC-WebRTC and turns it on for
>=C2=A0 =C2=A0clients which can do it.
>
> These have different muxing requirements, and then there are also
> some subchoices about whether you want everything in WebRTC to be QUIC=
> or just parts of it.
>
>
> As background, current WebRTC stacks attempt to mux all of the
> following protocols on the same 5-tuple:
>
> - STUN (for ICE and for TURN)
> - TURN channels
> - DTLS (for key management)
> - SRTP (for media)
>
> Note that I don't say SCTP because that's encapsulated in DTLS= .
>
> STUN
> I think the general consensus is that we need to be able to mux STUN > with QUIC, because otherwise we would need to reinvent all of STUN
> and ICE and that would be very not fun, and in some ways problematic > because the non-ICE parts of STUN don't assume any server authenti= cation
> so it=E2=80=99s not clear how you would ever think to do them with QUI= C.

Agree.

> TURN
> TURN can either run over STUN, in which case it's covered by the p= revious
> case, or it can run in channels, which are not. If you're willing = to
> abandon channels, then you don't have a problem. If you're not= , then you
> need TURN channels to work. I've heard suggestions that we should = run
> TURN over QUIC but I don't think that's sensible because the p= oint of
> TURN channels is to reduce overhead, and at that point you probably > could run the non-channel version of TURN without too much overhead > loss vis-a-vis QUIC and then you wouldn't have to address other pr= oblems
> (e.g., server auth) that we never really resolved with TURN-TLS and wo= uld
> maybe come back with QUIC.

Do TURN channels need to demux with QUIC? I was assuming we=E2=80=99= d run STUN/TURN channels to a server, or QUIC+STUN+DTLS+SRTP to a server, b= ut not both? (i.e., it=E2=80=99s either a TURN server or a media endpoint, = but not both).

You might (for instance)= start sending data to a TURN server and then have a srflx candidate succee= d.


=
> In the case where you mux SRTP and QUIC on the same 5-tuple, you then<= br> > have to address key management. You could, of course, run DTLS-SRTP > and demux DTLS, but it seems like you could probably just use QUIC'= ;s
> TLS handshake the way you run DTLS-SRTP and do the SRTP exporter from<= br> > there, so maybe you don't need to mux DTLS.

Exporting SRTP keys=C2=A0 from the QUIC handshake seems=C2=A0 sensib= le, but is an extra level of specification complexity. I suspect we=E2=80= =99ll want SRTP demux short term

Note that = if you don't expert keys, then you need DTLS demux (or no bundle)
=


-Ekr
=C2=A0
<= /div> --f403043d048803b616055fb494ef-- From nobody Wed Dec 6 21:03: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 E48FD12420B for ; Wed, 6 Dec 2017 21:03:57 -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, 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 FGgfjD5NhvAq for ; Wed, 6 Dec 2017 21:03:56 -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 57DBE1200F3 for ; Wed, 6 Dec 2017 21:03:56 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id y10so5380201otg.10 for ; Wed, 06 Dec 2017 21:03:56 -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=mj0rhFeM2IQYx7fWiq//Kgytm4/q9mVZYN4T8YCh7Uc=; b=feg94hpmufHvdPtvV3kkNgZ6r+GcyO8wYyq2hV8U6vLnEtnUkjoexWVUX/Vf8DxdSv myrILLv0y6DsSkjh/4qRsRAeSj4HVR97Zmg9864408c063BEFaSzdUjtNpj6YAeqwj9b 78fjqTpYIM3uP5HKzELNTw12MGm8zJu5dQB7b5i/DMoE7geSPu99jNmPXnisqAgsf2fs K8tbqeGgHp+cU3LnnCXoQHgVO5A8zj4p/sScDD0n0Bp2b3UlTcN6FOruTf8JKJ4Yc9bq YAcwMG0PGhTlsdinOJV2x/DcK7bs68WZvWBvJ5w1OUCO7f6jPIIIZGHv3bUUkZqI/hNg VYXw== 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=mj0rhFeM2IQYx7fWiq//Kgytm4/q9mVZYN4T8YCh7Uc=; b=WwPsJ7aHC77YVxBiDPI1StlZOw5D5sbuNmoEyKmJrTijuFuBLNai+CRUi+qdrHD9nM OGcY/mhtakD+gz200DrmHuBiLHo25IQqCw7DSDsUoeBT4B5fJQhmtxcsH1Hx+p0jGXL4 cxH4Bw0pqtYTPgVsnUfACAHRQ4t7BsB6ODHhgbjf74zsiQqBKx7yAS++8GWeiyCO4+r1 9vnyYNn8g9l7zoSeXQmhlcWr2RAPJedf4sarFhq5MF44lHgyJw9MhCHjHCyT+PgfwHko 0VkjRUN6k+7BuN5SCD/z8DvUM7JZ3UVj+kl0z2IgZT0PxQdEOWwyDFRkG9mpq7P5lnsB ixnQ== X-Gm-Message-State: AJaThX5Y/z407lSeDMha7w1lLx5L0ZUn8w+Fn47svg67KZTwKnR7iygS ly98KNOazsytiwPxicZ9g9hBHr4czwjJtF5XbGSkqEluysg= X-Google-Smtp-Source: AGs4zMabKXmcGtPl3n+4riunNsD0GGfrBjmDche8ZK8mQkiSSIqiMNEeWXjwaFir1GjahMUta4hFBYXlSp/EyLis0O4= X-Received: by 10.157.67.146 with SMTP id t18mr24581059ote.103.1512623035400; Wed, 06 Dec 2017 21:03:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Wed, 6 Dec 2017 21:03:54 -0800 (PST) From: Martin Thomson Date: Thu, 7 Dec 2017 16:03:54 +1100 Message-ID: Subject: Greasing more of QUIC To: 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: Thu, 07 Dec 2017 05:03:58 -0000 I've sort of promised a few times, to a few people, that I'd write up the state of play regarding greasing. I just did that and it got somewhat lengthy. So I decided that I'd put the words in a draft. Sorry. That's what you get when publishing drafts gets easier... https://datatracker.ietf.org/doc/html/draft-thomson-quic-grease Based on this, I'm a little more enthusiastic about protecting packet numbers, mainly for the secondary benefits that come with it. But I'll let others reach their own conclusions about that. From nobody Wed Dec 6 23:38: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 A29F91292CE for ; Wed, 6 Dec 2017 23:38:37 -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, 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=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 WGXeinEnl2ic for ; Wed, 6 Dec 2017 23:38:35 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989DC1292AE for ; Wed, 6 Dec 2017 23:38:35 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id 5so2621189ybp.4 for ; Wed, 06 Dec 2017 23:38: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=UxOVzKipo27o7YsMqR235XQtfep54HecRFddeU1UAK8=; b=Ye8K4MpcTz43ptLcOC2KnHhHDJVnqOXaQyFYXrHU63U6uQWYptcAFevZYBjmGaULfD KewHgVAiWxUx3d1oXgsEBMdcCkK6aBKkyKzhlu4uuf4gWOpLyvv+6gt3WVsbX5mVb6aw uOhIHujbWxALBXB3cYgA94YxUgn77z0vX6i5EmkKRyjAhwj/sH67tfchnOY+26fY1xSI U2mM3Tw8RkUq/YbKniJ4yOQoV3Bsrw1qOD3++LRl9/zdja8yHLl14+7+9p48sfjsw3AI fr0TEDBN892pcxWeUY+DsDWA5Kb7A01skpL7JeUgnIdYPEyxdvKgQBqqcxHcvE2KucVi 2CPA== 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=UxOVzKipo27o7YsMqR235XQtfep54HecRFddeU1UAK8=; b=XZoE5LcaiPw+FOZLHaCJOqqh3dfIg0Rj9bl40d7Udkp2Dd3VfDqQt6cXHijDBH2tO4 bmAJG61hS+AkA/5HtaPzYjh17cIkoycitNdqyugoUwkJsSUN7kcxEq1yomyr4sMRQvtT dttM8C/U11iEisB+8pg/6djynI8KrmaaYY9qhXNsX5Qtx4l8kJrlQKYbC7UaB0h7ZM8t rDwR0fWSF1KcCXVYxIxPmpILb/rif558iBRMs4uTJI3Yc3bYJ0twOeelcyI4REtqfOnG ZwY2ajgIm8kJ214c3jGHjfUc7dflS/CaK4VHfYKZncUclnpp/xL0duY9SkEvTCw2MjRe GfSA== X-Gm-Message-State: AKGB3mJQWcbWbAe46UQbvUvSHrOzIBEd94fxY+5lIB0p/K6eqC18w4Yx Y1rz/EUns91XluMaoO7oE2NH9mrZd7gHxe4wiumcsg== X-Google-Smtp-Source: AGs4zMZbLyNU+KYe5Foi44EmET+SaG+ZP/qSba0ZyZN9WqEbTsQCWXRU/3EcomA1S+6JK668w2fYK9n/uHL1DVv8sG8= X-Received: by 10.37.230.216 with SMTP id d207mr2941433ybh.290.1512632314316; Wed, 06 Dec 2017 23:38:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Wed, 6 Dec 2017 23:38:33 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 6 Dec 2017 23:38:33 -0800 Message-ID: Subject: Re: Greasing more of QUIC To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0a7faac5d4ed055fbb279a" 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, 07 Dec 2017 07:38:38 -0000 --94eb2c0a7faac5d4ed055fbb279a Content-Type: text/plain; charset="UTF-8" Martin, Thanks for writing this up! One main thought as I read the draft. I suspect the mechanisms here are a bit heavyweight for the greasing model I had in mind. The model I had in mind was that a middlebox that cared to read the spec would be able to interpret the packet types, but it couldn't from simply looking on the wire. I don't think we want to use a per-connection key, as load balancers will want to know the packet type and won't have the connection keys. Visibility for middleboxes is the reason we didn't encrypt the packet types in the first place. If you wanted to do a PRP based on this weaker model you'd end up using a known key per version, documented in the draft. Of course, the problem here is that you don't grease any values since the same permutation is used for a given version, and the permuted packet types remain fixed for the version. You could combine the version-specific key with something from the packet, perhaps the packet number (not the entire 64-bit number, only the visible part on the wire, for stateless middlebox operation), to permute the packet type, giving you more useful greasing. Alternatively, for this model of greasing I have in mind, all you need is to cover the entire space of possible types, not encrypt the packet type. A simple method would be, for instance, to use the result of (packet number % packet type). This has the unfortunate property that the packet type will basically start at a random point in its space but increment by one during the bulk of the connection, since most packets will use a single packet type (short header with 2-byte packet number). We can fix that somewhat by adding a random additive, also documented per version, after the mod operation: (packet number % packet type + random additive). This has the property that for consequent packets with the same packet type but increasing packet number, the resulting packet type will start at a random value per connection (since initial packet number is random) , and will increase by a fixed value for any given version. This is just me thinking off the top of my head, but that's roughly what I had in mind. It obviously assumes a weaker form of greasing than the ones in your draft is desirable. Thoughts? - jana On Wed, Dec 6, 2017 at 9:03 PM, Martin Thomson wrote: > I've sort of promised a few times, to a few people, that I'd write up > the state of play regarding greasing. I just did that and it got > somewhat lengthy. So I decided that I'd put the words in a draft. > Sorry. That's what you get when publishing drafts gets easier... > > https://datatracker.ietf.org/doc/html/draft-thomson-quic-grease > > Based on this, I'm a little more enthusiastic about protecting packet > numbers, mainly for the secondary benefits that come with it. But > I'll let others reach their own conclusions about that. > > --94eb2c0a7faac5d4ed055fbb279a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin,

Thanks for writing this u= p! One main thought as I read the draft.

I suspect the m= echanisms here are a bit heavyweight for the greasing model I had in mind. = The model I had in mind was that a middlebox that cared to read the spec wo= uld be able to interpret the packet types, but it couldn't from simply = looking on the wire. I don't think we want to use a per-connection key,= as load balancers will want to know the packet type and won't have the= connection keys. Visibility for middleboxes is the reason we didn't en= crypt the packet types in the first place.=C2=A0

I= f you wanted to do a PRP based on this weaker model you'd end up using = a known key per version, documented in the draft. Of course, the problem he= re is that you don't grease any values since the same permutation is us= ed for a given version, and the permuted packet types remain fixed for the = version.

You could combine the version-specific ke= y with something from the packet, perhaps the packet number (not the entire= 64-bit number, only the visible part on the wire, for stateless middlebox = operation), to permute the packet type, giving you more useful greasing.

Alternatively, for this model of greasing I have in = mind, all you need is to cover the entire space of possible types, not encr= ypt the packet type. A simple method would be, for instance, to use the res= ult of (packet number % packet type). This has the unfortunate property tha= t the packet type will basically start at a random point in its space but i= ncrement by one during the bulk of the connection, since most packets will = use a single packet type (short header with 2-byte packet number). We can f= ix that somewhat by adding a random additive, also documented per version, = after the mod operation: (packet number % packet type + random additive). T= his has the property that for consequent packets with the same packet type = but increasing packet number, the resulting packet type will start at a ran= dom value per connection (since initial packet number is random)=C2=A0, and= will increase by a fixed value for any given version.

=
This is just me thinking off the top of my head, but that's roughl= y what I had in mind. It obviously assumes a weaker form of greasing than t= he ones in your draft is desirable.

Thoughts?
- jana

On Wed, Dec 6, 2017 at 9:03 PM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
I'= ve sort of promised a few times, to a few people, that I'd write up
the state of play regarding greasing.=C2=A0 I just did that and it got
somewhat lengthy.=C2=A0 So I decided that I'd put the words in a draft.=
Sorry.=C2=A0 That's what you get when publishing drafts gets easier...<= br>
https://datatracker.ietf.org/doc= /html/draft-thomson-quic-grease

Based on this, I'm a little more enthusiastic about protecting packet numbers, mainly for the secondary benefits that come with it.=C2=A0 But
I'll let others reach their own conclusions about that.


--94eb2c0a7faac5d4ed055fbb279a-- From nobody Thu Dec 7 01:11: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 524EB120454 for ; Thu, 7 Dec 2017 01:11: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, 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 xg3UgMafO0Wy for ; Thu, 7 Dec 2017 01:11:42 -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 AC93F1200C1 for ; Thu, 7 Dec 2017 01:11:41 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3C638340E11; Thu, 7 Dec 2017 10:11:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.14314); Thu, 7 Dec 2017 10:11:40 +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, 7 Dec 2017 10:11:40 +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.18) with ESMTPSA id 38487100; Thu, 07 Dec 2017 10:11:40 +0100 From: "Brian Trammell (IETF)" Message-Id: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_FAAD140C-C1CF-4FF4-865F-52B1B16EBBBC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Greasing more of QUIC Date: Thu, 7 Dec 2017 10:11:39 +0100 In-Reply-To: Cc: QUIC WG To: Martin Thomson References: X-Mailer: Apple Mail (2.3273) 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, 07 Dec 2017 09:11:45 -0000 --Apple-Mail=_FAAD140C-C1CF-4FF4-865F-52B1B16EBBBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, > On 7 Dec 2017, at 06:03, Martin Thomson = wrote: >=20 > I've sort of promised a few times, to a few people, that I'd write up > the state of play regarding greasing. I just did that and it got > somewhat lengthy. So I decided that I'd put the words in a draft. > Sorry. That's what you get when publishing drafts gets easier... >=20 > https://datatracker.ietf.org/doc/html/draft-thomson-quic-grease First, I'll note that draft focuses on runtime adaptations: how can we = scramble the wire image to resist analysis by vendors who will implement = the results of that analysis in ways that might break future QUIC = versions by dropping packets? This is only part of the space of = mitigations available to us. There are also design- and deployment-time = adaptations: exercising the version negotiation mechanism, for instance, = by making the V2 header beyond the invariants gratuitously incompatible = with the V1 header and deploying it very, very soon after V1. When you said "this got lengthy", what I was hoping I'd see here, and = didn't, is an explicit statement of the threat model the greasing we = apply is meant to counter. "Ossification", yes, great, but in order to = be able to evaluate the tradeoffs (especially between XOR and FFX), we = need to get a bit more specific about what that means. I can think of a couple of axes along which we can classify these = models: (1) Adversary intent: what is the middlebox trying to do? Block QUIC? = Whitelist QUIC traffic to block non-QUIC UDP garbage? Track QUIC flow = state to whitelist QUIC traffic on a per-flow basis? Classify QUIC = traffic by version? Classify QUIC traffic by overlying application layer = protocol? Infer end-user activity through the analysis of QUIC traffic? = Break QUIC in subtle ways for evil fun? We should be clear about what = we're trying to keep from happening *with greasing* (as opposed to with = packet protection). (2) Adversary information: Does the middlebox's creator participate in = the standardization process? Does it passively consume the final or = intermediate products of the standardization process? Does it statically = or dynamically analyze the behavior of open-source implementations of = the protocol in a controlled envionment? Does it statically or = dynamizally analyze traffic captured from experimentation with open- and = closed-source deployments of the protocol on the open Internet? The = method by which the adversary figures out what the protocol does (3) I'm trying to come up with a non-pejorative way to say this but I = can't, so, adversary competence: Much of the trouble we've run into with = TCP is with lazy or simply bad implementation of well-meaning intent = ("we never see options so eh, why write that code?"), or with poor = design based on a fundamental misunderstanding of the problem space = ("this 2G network sucks, but it was expensive, so it must be TCP's = fault; let's screw around with ACK timing, which worked in our = experiments with $STACK_X, which is fine because clearly nobody will = ever run anything other than $STACK_X on this network"). In general the = assumption that laziness is a virtue holds -- designed systems in = state-intensive environments tend to try to minimize their state = requirements at the expense of correctness, and in any case, it makes = economic sense to minimize the effort and expense in designing and = implementing said systems, so corner cases will lead to cut corners. But = it is very hard to model the laziness of other people, so this is the = fuzziest and most guess-prone axis of the three. Greasing is of most utility, IMO, when it is used to prevent lazy, = somewhat-competent middlebox creators with access to but little interest = in reading the specs from expanding the set of invariants beyond those = which we prescribe, whether intentionally or unintentionally (indeed, a = non-lazy adversary working to intentionally expand the set of invariants = would just send a pull request on the invariants doc. :) ). Doing something to protect the ability to expand/change the location and = semantics of the packet type switching mechanism and the packet number = space and encoding in future versions seems like it's worth doing. = Attempting to make these mechanisms resistant to analysis, though, = doesn't seem like it has a benefit commensurate with effort and = proneness to error. > Based on this, I'm a little more enthusiastic about protecting packet > numbers, mainly for the secondary benefits that come with it. But > I'll let others reach their own conclusions about that. I'm also a *little* more enthusiastic, depending again on what the = threat model is, and whether we want the packet numbers to be decodable = at all along the path by devices which do understand the protocol (i.e. = for one- and two-point loss measurement, as well as to reject bad spin = bit samples, on which see = https://tools.ietf.org/html/draft-trammell-quic-spin-00#section-3.3). Cheers, Brian --Apple-Mail=_FAAD140C-C1CF-4FF4-865F-52B1B16EBBBC 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlopBcsACgkQihK3vwvq RqPGhQ/+K4miyA0GAnBCWE9p+rdcUpp1jlmFkYxaa5y+7rSJ1BXl5oBW6fxfBLvg YjVu9ppksfrg6PBpm0wr9p/kqjW0V4EFAZ1zJ0zV7JPks7C0aPpKIh2IzIuY6wWr j0RRnmd3Jqq2gYl1HCKhgsP/9+QZoBZOtX0bDDR7m3ekaURvd1Wmzb32SEJO05bB DaG+QFcInNKCVP5o1U2CahgmFlsGTWU+OWCSdLUli70EhpjVEM5fMIquE5jLKVfG mLpjgiTq9a/njLVjgg9+yEQE6+MlmVOg+vn1HRL2hhtNUBsXzcsSR/Mc57ExuoeR rTeTjIvHGChfVcnwecLXfXMdPqWh+M7OLullpPl93vtSl/i04C+0Af09voHgPmK5 aR7lBuuGivn7H4UZULmR8onWYpMAPqYuimUVK4lgbi7n0y+PEp7GKQBnG+FNQnk5 GA9WSKo7GjLe0KAPyAzBnqBOEYuO3N46VE18gzrMheaH/5q5dxJtPbD1lDE1JvpE wtjPS15utq8FmPXw1DFRvH/C2ARNCQmQIfpo+DZRbPnRM2GApL/xltJBiAdBtLuc 2iEjy+GWyU+TAmdevzvTk99J+esTH9ayX39K9VtyOv+l4RbBMWwNXcS6xlNjJi/U anOSJ0wRmKJkeMyDl1F8Q3mqVNvhvZ2zZ5lfRHEL7/tbzYdQRAk= =RVvQ -----END PGP SIGNATURE----- --Apple-Mail=_FAAD140C-C1CF-4FF4-865F-52B1B16EBBBC-- From nobody Thu Dec 7 10:59: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 9C794127076 for ; Thu, 7 Dec 2017 10:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 K_HrDohh0adi for ; Thu, 7 Dec 2017 10:59:50 -0800 (PST) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (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 22AE9126D3F for ; Thu, 7 Dec 2017 10:59:50 -0800 (PST) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1437A5350; Thu, 7 Dec 2017 13:59:44 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9FE8954B6; Thu, 7 Dec 2017 13:59:43 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 07 Dec 2017 13:59:44 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: More on demultiplexing From: Cullen Jennings In-Reply-To: Date: Thu, 7 Dec 2017 11:59:42 -0700 Cc: IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> References: To: Ted Hardie , 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, 07 Dec 2017 18:59:52 -0000 > On Dec 6, 2017, at 12:15 PM, Ted Hardie wrote: >=20 > I think if you bundled all the media on one 5-tuple and had QUIC on = another, the core NAT exhaustion problem would not be that bad.=20 It would be twice as bad :-) When creating the offer, the device that = creates it does not know if it will be getting QUIC based stuff or not = so you want to include both in the offer. For the same reason we don't = want to gather two ports for RTC and RTCP, I think we will want to run = both on same port. I think google's data showed that nat traversal = success rates were worse when using two ports instead of one.=20 So my preference would be to be able to multiplex WebRTC using QUIC and = and WebRTC not using QUIC on the same port.=20 From nobody Thu Dec 7 11:46: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 6372612948B for ; Thu, 7 Dec 2017 11:46:16 -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, 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=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 Zqf1FbUR5LT0 for ; Thu, 7 Dec 2017 11:46:14 -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 F1B121294E1 for ; Thu, 7 Dec 2017 11:46:09 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id y7so3434464ybm.8 for ; Thu, 07 Dec 2017 11:46:09 -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=PX4ae7N+HiDJ9vwNi9TKcvv2XpXejRw+TvneOHjTzcI=; b=s0AtCeXw/dk8zH8Q6LfXDeZK3HnSKCpAeS+dJNFsUsijXCd5XCiZBpjV2qdGmf/+Z2 hDzShUmL/8lYaTvxFEd77rKgtfkaEg+kRby+wsnzReJ9pGXUVpNPniaLS4AUgBWf1peq nYcHuLePAtpchp92Tp97pgSJ4eZWHY86TRl/lL44hon2Zll7SOUEG/ML/uc8kjIWAEWs 5+D3mWQl7WjsdG7gdOx//55AWr13/h+XqQvJTmUqlKDoA2TBji8hCk19AaWPJxF0h+HH BaE2w7QOfLSxD1u+42wNhWY3dn/siu3122fZywlt5e4ZBqGz7+koCL2FP3znL44ulFSi yVhA== 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=PX4ae7N+HiDJ9vwNi9TKcvv2XpXejRw+TvneOHjTzcI=; b=lDv5bUrTtSUCZrYS1bGrDq5MbVACjjGnShlLhDXAl1rMh+9kqGQ/RUKaRMeEKhNKRZ NE/jquNc/bnzlsfvPO/g+BvWzDFGRhO9u8m35jJHqlKTapvzggqHwYRRy3pMl+rgSb3l Fm2H5xxuuSLm0umHx9E8WKt/Q8/9gLHygRGAeyEsXiriQzm0vJo0UP/lPKpt08xyhino dQlsLqnXYuanG184+73hgaA5iOr0LZqTwRs1DYWo3hoV+3gRYoCiF9v5flANKhOos/Ng lFZB+Xf+LUwS3LsHNcPfftWqTbzzBKfCcxyj4WW3SdKW8iMmapqcwMmL/jiExcUEBxwi KYuQ== X-Gm-Message-State: AKGB3mIMSyUwxpepI64lqemkvGntvNwQuDkmMywsxQxWxpqB8SoYzqj6 0x7mBrAJck+YTSb4q4PtpwZgCoUTD5ow4ERQIHvlaw== X-Google-Smtp-Source: AGs4zMacs366TTZSM33VmrgcpWl9nTMnVVJnb4H1yPRbiFOAdZb2PWPX+WhZv7bMhaazB8wu/wvlUIIBVJm0l88DME0= X-Received: by 10.37.97.151 with SMTP id v145mr4111662ybb.106.1512675968837; Thu, 07 Dec 2017 11:46:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Thu, 7 Dec 2017 11:46:08 -0800 (PST) In-Reply-To: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> References: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> From: Jana Iyengar Date: Thu, 7 Dec 2017 11:46:08 -0800 Message-ID: Subject: Re: More on demultiplexing To: Cullen Jennings Cc: Ted Hardie , Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1142df62c917a5055fc55189" 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, 07 Dec 2017 19:46:16 -0000 --001a1142df62c917a5055fc55189 Content-Type: text/plain; charset="UTF-8" Up-leveling for a moment: Is it reasonable to consider a model where the endpoints determine which protocols need to be muxed and therefore which type bytes are kosher to use for QUIC on any given connection? I'll describe a simple strawman which is only meant to be illustrative. Strawman: Each application knows what protocols it may need to mux on the same port, and therefore knows which first bytes it may need to mux. Based on this information, in its transport params sent during the QUIC handshake, the client sends a list of packet types to avoid. The server similarly sends its list to the client in its transport params. Both endpoints use the union of the two sets as the packet types to avoid using in this connection. Both ends are now free to grease packet types over the rest of the type space. The greasing algorithm we specify for QUIC v1 will do the right thing and avoid using the types that the endpoints have agreed on. This leads to two types of packet types: - Muxing-agnostic packet types: We'd have to use some long header types to do the handshake where we communicate the muxing list. These might conflict with a muxing list if it exists, so we may want to choose these types a bit more carefully for QUIC v1. That said, I think this would only be a couple of packet types (Initial and Handshake types probably?) This may also be useful given that load balancers will likely want to know about handshake packets anyways. - Muxing-aware packet types: The rest of the packet types can be greased over the rest of the type space, avoiding values known to belong to protocols one of the endpoints wants to mux. Does this seem anywhere near reasonable? What am I missing if it isn't? On Thu, Dec 7, 2017 at 10:59 AM, Cullen Jennings wrote: > > > On Dec 6, 2017, at 12:15 PM, Ted Hardie wrote: > > > > I think if you bundled all the media on one 5-tuple and had QUIC on > another, the core NAT exhaustion problem would not be that bad. > > It would be twice as bad :-) When creating the offer, the device that > creates it does not know if it will be getting QUIC based stuff or not so > you want to include both in the offer. For the same reason we don't want to > gather two ports for RTC and RTCP, I think we will want to run both on same > port. I think google's data showed that nat traversal success rates were > worse when using two ports instead of one. > > So my preference would be to be able to multiplex WebRTC using QUIC and > and WebRTC not using QUIC on the same port. > > > --001a1142df62c917a5055fc55189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Up-leveling for a moment: Is it reasonable to conside= r a model where the endpoints determine which protocols need to be muxed an= d therefore which type bytes are kosher to use for QUIC on any given connec= tion?

I'll describe a simple strawman which is= only meant to be illustrative. Strawman: Each application knows what proto= cols it may need to mux on the same port, and therefore knows which first b= ytes it may need to mux. Based on this information, in its transport params= sent during the QUIC handshake, the client sends a list of packet types to= avoid. The server similarly sends its list to the client in its transport = params. Both endpoints use the union of the two sets as the packet types to= avoid using in this connection.

Both ends are now= free to grease packet types over the rest of the type space. The greasing = algorithm we specify for QUIC v1 will do the right thing and avoid using th= e types that the endpoints have agreed on.

This le= ads to two types of packet types:
- Muxing-agnostic packet types:= We'd have to use some long header types to do the handshake where we c= ommunicate the muxing list. These might conflict with a muxing list if it e= xists, so we may want to choose these types a bit more carefully for QUIC v= 1. That said, I think this would only be a couple of packet types (Initial = and Handshake types probably?) This may also be useful given that load bala= ncers will likely want to know about handshake packets anyways.=C2=A0
=
- Muxing-aware packet types: The rest of the packet types can be greas= ed over the rest of the type space, avoiding values known to belong to prot= ocols one of the endpoints wants to mux.

Does this= seem anywhere near reasonable? What am I missing if it isn't?


On Thu, Dec 7, 2017 at 10:59 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> On Dec 6, 2017, at 12:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> I think if you bundled all the media on one 5-tuple and had QUIC on an= other, the core NAT exhaustion problem would not be that bad.

It would be twice as bad :-) When creating the offer, the device tha= t creates it does not know if it will be getting QUIC based stuff or not so= you want to include both in the offer. For the same reason we don't wa= nt to gather two ports for RTC and RTCP, I think we will want to run both o= n same port. I think google's data showed that nat traversal success ra= tes were worse when using two ports instead of one.

So my preference would be to be able to multiplex WebRTC using QUIC and and= WebRTC not using QUIC on the same port.



--001a1142df62c917a5055fc55189-- From nobody Thu Dec 7 11:51: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 E81051293EE for ; Thu, 7 Dec 2017 11:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 m7HAmGYhV2-g for ; Thu, 7 Dec 2017 11:51:37 -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 1C7F71242EA for ; Thu, 7 Dec 2017 11:51:37 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eN2Ck-00015A-Id for quic@ietf.org; Thu, 07 Dec 2017 20:51:35 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eN2Cg-0002sY-T3 for quic@ietf.org; Thu, 07 Dec 2017 14:51:31 -0500 Received: (qmail 29931 invoked from network); 7 Dec 2017 19:51:29 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.119]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Dec 2017 19:51:29 -0000 To: Cullen Jennings , Ted Hardie , Eric Rescorla Cc: IETF QUIC WG References: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> From: Christian Huitema Message-ID: <65c4d1cd-8927-1a96-a45c-734e743279ac@huitema.net> Date: Thu, 7 Dec 2017 11:51:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: More on demultiplexing X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.41) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mdx2YVAIAURqYHpciU8VEAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftz9kBhqqzGShVAkm9QR5IHB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RVqmOxmOiu7eNKmi/WEUBdnGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAInD3q08gexeH56OZWSJPgEONoJfh+XjGSeeT90H/uIFn PqccHCnpsJbmcIJ2AD0fnrv9Yb7l38U/gOgHUE/N4WbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWWMqPnh3oWYEaqVdFM1yo4PfFcHV2tQAVqGdj/zM7G/GvAlpVif2edmNpSuMMbNDZ5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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, 07 Dec 2017 19:51:39 -0000 On 12/7/2017 10:59 AM, Cullen Jennings wrote: >> On Dec 6, 2017, at 12:15 PM, Ted Hardie wrote: >> >> I think if you bundled all the media on one 5-tuple and had QUIC on an= other, the core NAT exhaustion problem would not be that bad.=20 > It would be twice as bad :-) When creating the offer, the device that c= reates it does not know if it will be getting QUIC based stuff or not so = you want to include both in the offer. For the same reason we don't want = to gather two ports for RTC and RTCP, I think we will want to run both on= same port. I think google's data showed that nat traversal success rates= were worse when using two ports instead of one.=20 > > So my preference would be to be able to multiplex WebRTC using QUIC and= and WebRTC not using QUIC on the same port.=20 > +1. When dealing with NAT, there is a cost per port to "opening a hole for the port", in terms of messages to open the port, risks to cause resource exhaustion in a local NAT, and requirement to keep the port alive. Everything on one port is nice. By the way, how strongly do we feel about making decisions based on first byte alone? In the case of QUIC, the connection ID provides a pretty big clue. If we use that, demux becomes significantly simpler. There are still issues during the connection phase, as the first message from the peer carries an unknown connection ID, but that could be handled with special logic. Also, don't STUN messages carry a magic number precisely to help demuxing? -- Christian Huitema From nobody Thu Dec 7 12:00: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 09CFA1294F5 for ; Thu, 7 Dec 2017 12:00:57 -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, 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=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 u_0lvb0tanQw for ; Thu, 7 Dec 2017 12:00: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 3E4AC129512 for ; Thu, 7 Dec 2017 12:00:41 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id 184so3440865ybw.12 for ; Thu, 07 Dec 2017 12:00: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=+0E26XqY9kCq9AfbdaD4jPlyCPQov0XOQqO3rF3jXKQ=; b=eJQ/4KSXwHdSZqpfWiTQuxuVxzaWxCzn5KgSTcWAnqtnfVRyvDW2di2QWlaljleWzr 3b0cuqH1+N6RKT9UYthXftGnBM+nFbeCqR20yo269jiLH1nG1ojG6TEg5z3DA10uEc1q w6uQ5eFJtXeaxuOATPTNnLfIZLAW29ic9cwPSFAr1qcJel1vuUDM/xNLuoCXN0IDjzM8 YnZWnaDkR+E0WYUWPV8jMF23j78Txd8Fc6gdCGMuqvkkYWxogtYJUWHkWF1Crw7QTCUI icPfIpa6tm3d8xl8odoUDNKAlTG9Itecxc/M4mk5cVXWcbLnHDCq7ZCU4oPA7/yAN12/ EFuQ== 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=+0E26XqY9kCq9AfbdaD4jPlyCPQov0XOQqO3rF3jXKQ=; b=emmOS/Xr6oK8Ff1NTISV+ohtFr5onOtyQgLy5Klg9V2j0Vw9VvCzPIPoqeKh5wZops RM3Awj0Jd3ZsPhM+thHYihQowleq1trhHGeR8yhvim5y5cRCaQeFx8pqHrQSNxY6pxVl ihwg3rsHwgUBTOELJvWlKOZOI9J9SQEXjX/wv41Sy2NyGKoaFWOY6BQBjbAYTuhTHxh9 5kQGr1CQeUQw/ccHh9f81QmtA6HkngUJMOFH+UZ0f65ykB9+dRp4A26dDL8onHn7tK9L aPVm5khnVCi1gz4aVMYfmoUJBA2BHanuxdGkAfzL3edddteU9nnTDvhIWjJkL1rlv5K5 Rh7w== X-Gm-Message-State: AJaThX7Amdz/L/1BdrhC7cUGUXw0YQd++Cu8Hkq5wwmtFk3kCtmI3BqW TQct2IxSO1rHVxjFlvYMfWuJ0d9KfuthWSB5OMuOmQ== X-Google-Smtp-Source: AGs4zMbvuw4WVom0DLNZYm7VChxA2hvIffTPtl6EKT5YQGdBn4wFC7WeCPf7xp5Gk2YgUsduy+bcWqmKDD1OOMWi4yM= X-Received: by 10.37.192.196 with SMTP id c187mr19717776ybf.366.1512676840069; Thu, 07 Dec 2017 12:00:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Thu, 7 Dec 2017 12:00:39 -0800 (PST) In-Reply-To: <65c4d1cd-8927-1a96-a45c-734e743279ac@huitema.net> References: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> <65c4d1cd-8927-1a96-a45c-734e743279ac@huitema.net> From: Jana Iyengar Date: Thu, 7 Dec 2017 12:00:39 -0800 Message-ID: Subject: Re: More on demultiplexing To: Christian Huitema Cc: Cullen Jennings , Ted Hardie , Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113d4b1cb72a5d055fc58593" 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, 07 Dec 2017 20:00:57 -0000 --001a113d4b1cb72a5d055fc58593 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 7, 2017 at 11:51 AM, Christian Huitema wrote: > On 12/7/2017 10:59 AM, Cullen Jennings wrote: > > >> On Dec 6, 2017, at 12:15 PM, Ted Hardie wrote: > >> > >> I think if you bundled all the media on one 5-tuple and had QUIC on > another, the core NAT exhaustion problem would not be that bad. > > It would be twice as bad :-) When creating the offer, the device that > creates it does not know if it will be getting QUIC based stuff or not so > you want to include both in the offer. For the same reason we don't want to > gather two ports for RTC and RTCP, I think we will want to run both on same > port. I think google's data showed that nat traversal success rates were > worse when using two ports instead of one. > > > > So my preference would be to be able to multiplex WebRTC using QUIC and > and WebRTC not using QUIC on the same port. > > > +1. When dealing with NAT, there is a cost per port to "opening a hole > for the port", in terms of messages to open the port, risks to cause > resource exhaustion in a local NAT, and requirement to keep the port > alive. Everything on one port is nice. > I agree on this point. It's more than just nice -- it avoids strange partial failures when one part of the communication works (over one port) but the other part (over the other port) doesn't. > By the way, how strongly do we feel about making decisions based on > first byte alone? In the case of QUIC, the connection ID provides a > pretty big clue. If we use that, demux becomes significantly simpler. > There are still issues during the connection phase, as the first message > from the peer carries an unknown connection ID, but that could be > handled with special logic. Also, don't STUN messages carry a magic > number precisely to help demuxing? > Why have the same conversation once in one place when we can have it twice in two places :-) I raised this point in #426 , and Colin responded there, you may want to take a look. He does suggest using connection ID, but it's not yet clear to me that the C bit needs to be changed in that case. --001a113d4b1cb72a5d055fc58593 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 7, 2017 at 11:51 AM, Christian Huitema <huitema= @huitema.net> wrote:
On 12/7/2017 10:59 AM, Cullen Jennings wr= ote:

>> On Dec 6, 2017, at 12:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>>
>> I think if you bundled all the media on one 5-tuple and had QUIC o= n another, the core NAT exhaustion problem would not be that bad.
> It would be twice as bad :-) When creating the offer, the device that = creates it does not know if it will be getting QUIC based stuff or not so y= ou want to include both in the offer. For the same reason we don't want= to gather two ports for RTC and RTCP, I think we will want to run both on = same port. I think google's data showed that nat traversal success rate= s were worse when using two ports instead of one.
>
> So my preference would be to be able to multiplex WebRTC using QUIC an= d and WebRTC not using QUIC on the same port.
>
+1. When dealing with NAT, there is a cost per port to "op= ening a hole
for the port", in terms of messages to open the port, risks to cause resource exhaustion in a local NAT, and requirement to keep the port
alive. Everything on one port is nice.

= I agree on this point. It's more than just nice -- it avoids strange pa= rtial failures when one part of the communication works (over one port) but= the other part (over the other port) doesn't.=C2=A0
=C2=A0
By the way, how strongly do we feel about making decisions based on
first byte alone? In the case of QUIC, the connection ID provides a
pretty big clue. If we use that, demux becomes significantly simpler.
There are still issues during the connection phase, as the first message from the peer carries an unknown connection ID, but that could be
handled with special logic. Also, don't STUN messages carry a magic
number precisely to help demuxing?

Why = have the same conversation once in one place when we can have it twice in t= wo places :-) I raised this=C2=A0 point in #426, and Colin responded= there, you may want to take a look. He does suggest using connection ID, b= ut it's not yet clear to me that the C bit needs to be changed in that = case.
--001a113d4b1cb72a5d055fc58593-- From nobody Thu Dec 7 12:10: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 CEBBE1294CE for ; Thu, 7 Dec 2017 12:10:17 -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, MIME_QP_LONG_LINE=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 cd_RCllW6grr for ; Thu, 7 Dec 2017 12:10:16 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5B112948F for ; Thu, 7 Dec 2017 12:10:15 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id u84so5664050vke.10 for ; Thu, 07 Dec 2017 12:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0vuLtkREzXnCFmsRbiCb+h8Zf9JuspA5xcA/4zeYK+s=; b=M6HAKPHyTa3GLnq6U6UmD11D4qRMfBud+s9f/A4YmpjWfgp9xD1xn5c89ojQrsQxdZ s1+7kTvJChzrWguBX8q+h5nBpcA5LVcPoGF6GWgdf1zRV9AspH+I0CqJUPekTjNZXG1I t+DQpuKoqF+nANxOfFw2u0/9buSorCtIqIP5zymoKKJsrmyH3CPJB3CR9SLu09a5TZoy KIuj1u7DIim/7LRNTaPEKqp3scweFTq3In/YQhRYkcHDGHRBRcP6w3j+si8gaOumE6bk DUH+XuCYCSBeli8Xrr4ny6B1J1yeokTH1tc/GMPK55x4Jp9lywcmQMNLqFdOmprNl5m/ Ygww== 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=0vuLtkREzXnCFmsRbiCb+h8Zf9JuspA5xcA/4zeYK+s=; b=PRrJeyFQLCEU+gdFsMxQV2kEzswNWHBZA+iTdXDRgAMeFoP62U6tFDB2OlslvYsGGb akwvMSA4RSFLCg+IXYf4MthBh4nY8Dp1CjV+E4JBmAKUqCwpQsTtYRbYq5XYhTRt/x19 jwhnsReP9AeS+4J3JXt9etuUiIRuU3XJAoDeMqWNx3WIcbb7JvxC5vvcTDWv9ivPDPjH hyR07mu3DU5LX6ue+Mwl8TklAU+crtb1sQBqQMslUpFnYvpI0Lbp+qJAvwlCg+BbDIrF xI3a9jBIgpKnEaMO05nrr2jGsDnFEu6yhJJrIvDNQnDtz+v2iewPWII0oQsfuiDte9M9 vhKg== X-Gm-Message-State: AKGB3mJoqzPUgaIJK3bjp9bvrdeT56Uenkwkvn/xBto+2aynVa8c1mz4 /Ql/+EN7xRAQQcgT8QKWx9xAiRR1 X-Google-Smtp-Source: AGs4zMZqUC+r0lN89CP/UyVNfxKaS1MoF9KrdC9qPQARWaQ+Cs1H2W0DhKSOzLYZcg+kIOq57UaJRA== X-Received: by 10.31.227.193 with SMTP id a184mr14517998vkh.94.1512677414353; Thu, 07 Dec 2017 12:10:14 -0800 (PST) Received: from [10.235.87.114] ([73.85.206.186]) by smtp.gmail.com with ESMTPSA id d35sm4198203uag.38.2017.12.07.12.10.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 12:10:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-01A8DCB3-BBD6-41CF-969F-83DB364EDCEF Mime-Version: 1.0 (1.0) Subject: Re: More on demultiplexing From: Bernard Aboba X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Thu, 7 Dec 2017 15:10:12 -0500 Cc: Eric Rescorla , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: <2DDA3D4C-C1B7-4539-9532-3A9882E785C9@gmail.com> References: To: Ted Hardie 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, 07 Dec 2017 20:10:18 -0000 --Apple-Mail-01A8DCB3-BBD6-41CF-969F-83DB364EDCEF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Dec 6, 2017, at 2:15 PM, Ted Hardie wrote: >>=20 > I agree that the QUIC substitution for the current data channel stack is p= retty straight forward. [BA] Not quite true yet. To be able to completely substitute for SCTP, QUIC n= eeds support for unreliable streams. One message per stream and a timer enab= les support for maxPacketLifetime, but not maxRetransmits. So for now QUIC c= annot provide every use case supported by an SCTP data channel. That means t= hat some applications might want both (e.g. SCTP for small unreliable messag= es, QUIC for a background file transfer). > That looks fairly do-able to me, but my familiarity with PERC is glancing a= t best, so it would be useful if someone with more familiarity could comment= .=20 [BA] There is a basic question here which is whether the Javascript is trust= ed. Creating two transports under JS control is not the same model PERC is u= sing, where the KMF is administered separately from the conferencing service= . > I think if you bundled all the media on one 5-tuple and had QUIC on anothe= r, the core NAT exhaustion problem would not be that bad.=20 [BA] Virtually all WebRTC applications use BUNDLE today so the market for =E2= =80=9Cnot that bad=E2=80=9D doesn=E2=80=99t seem very big.=20 > Having to run DTLS for DTLS-SRTP seems kind of sub-optimal to me, but that= 's a gut reaction rather than a measured analysis. [BA] Sub-optimal perhaps, but initial deployments won=E2=80=99t support QUIC= -SRTP and could need to multiplex DTLS with QUIC anyway.= --Apple-Mail-01A8DCB3-BBD6-41CF-969F-83DB364EDCEF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Dec 6, 2017, at 2:15 PM,= Ted Hardie <ted.ietf@gmail.com= > wrote:
<= div class=3D"gmail_extra">

I agree that the QUIC substitution for the current data channel stack i= s pretty straight forward.

[BA] Not quite true yet. To be able to completely s= ubstitute for SCTP, QUIC needs support for unreliable streams. One message p= er stream and a timer enables support for maxPacketLifetime, but not maxRetr= ansmits. So for now QUIC cannot provide every use case supported by an SCTP d= ata channel. That means that some applications might want both (e.g. SCTP fo= r small unreliable messages, QUIC for a background file transfer).

That looks fairly do-abl= e to me, but my familiarity with PERC is glancing at best, so it would be us= eful if someone with more familiarity could comment. 

[BA] There is a ba= sic question here which is whether the Javascript is trusted. Creating two t= ransports under JS control is not the same model PERC is using, where the KM= F is administered separately from the conferencing service.

I think if you bundled all the m= edia on one 5-tuple and had QUIC on another, the core NAT exhaustion problem= would not be that bad. 

[BA] Virtually all WebRTC applications use BUND= LE today so the market for =E2=80=9Cnot that bad=E2=80=9D doesn=E2=80=99t se= em very big. 

<= div>Having to run DTLS for DTLS-SRTP seems kind of sub-optimal to me, but th= at's a gut reaction rather than a measured analysis.
=

[BA] Sub-optimal perhaps, but initial deployment= s won=E2=80=99t support QUIC-SRTP and could need to multiplex DTLS with QUIC= anyway.
= --Apple-Mail-01A8DCB3-BBD6-41CF-969F-83DB364EDCEF-- From nobody Thu Dec 7 12: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 CEC3A1293EE for ; Thu, 7 Dec 2017 12:11:59 -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, 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 ksrJUyNYFUJf for ; Thu, 7 Dec 2017 12:11:58 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 4FA0E12704A for ; Thu, 7 Dec 2017 12:11:58 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id l2so6135490uak.2 for ; Thu, 07 Dec 2017 12:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fw3jvwoBDMurnDLWI+vDgKymJ0dHY+xv3NTHpuNawJg=; b=Xif8KmXJGe4Pona+lqJEJcyfvTcMbayBFb474smzRd7kA77huAgjOtyvYO3BOKMEev noOVFwTuChsDE2/LlgxdhZBODVo3sFnWyh9l6JLnuYYcIL60d7/Y9Ni6rmEyO9936EJY S4dY8DARvMP2XEbTPIB0zIleabqG6YionQMJaj/jbI/AxQMr6n6QWdy5zker0SZHT8sP fJRXyY/tumwSc6aw2G2SJwhZRBPPgXkutUCYk4HV50SGQq6pTPtTV8QtEt5E6K852isD s04yowwRWwtD7YONGNpyy3tZflElkCd52XrUdOY3XcQPwLaI9czGFef/fKhxDZYQdbEy V56w== 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=fw3jvwoBDMurnDLWI+vDgKymJ0dHY+xv3NTHpuNawJg=; b=mbBuC5MIbnDtEiNa+AfP0HLNwMd0/gFqm7m36iT3ThXQ2j/kdkFmMVCoon7JLTgMNH yEb6ypzZm0qVv7mU3WkWH+QTHTlxYry7K30QMg393RPIeOkOejeAtvlS6Z9LoIArt/En OjxgyKzndkbq1LEhYkeXYZp1HuPfm77TdixNGRSl6txy2AisDRotH/EucDwGfrN2Apsq 7qOQugxCBVrIujs4li8Dz7TVAT7B0nb/PoF9H+kqhmAipf8cbIAUqxZgWbsmG03noEJs cUjSpo6J/aATOFaxWCeBRH3tZmUVXRDbwRS5XwHyNgvTGHj2DtXEnV006bPjhJqFc1wV QIVA== X-Gm-Message-State: AKGB3mIzX+Dk10wd19lsOw3Mh9nyDJsSEUeUAmZScJl4RcigUm0u3gMl w6j+npkb61RFVQnT0t1J4J3GS3/X X-Google-Smtp-Source: AGs4zMaXI07u6wWHdSIvgsdSsHk92AY5pE/47Dv4t8R0634EcNyfFCery0Tq/vId9nbSNqG0jFsPKA== X-Received: by 10.159.34.14 with SMTP id 14mr15423689uad.167.1512677517035; Thu, 07 Dec 2017 12:11:57 -0800 (PST) Received: from [10.235.87.114] ([73.85.206.186]) by smtp.gmail.com with ESMTPSA id k33sm2830056uaf.48.2017.12.07.12.11.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 12:11:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: More on demultiplexing From: Bernard Aboba X-Mailer: iPhone Mail (15C114) In-Reply-To: <61C0885E-3363-4B70-B64F-C471A4A16B3C@csperkins.org> Date: Thu, 7 Dec 2017 15:11:55 -0500 Cc: Eric Rescorla , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <8C764108-7D8B-4FDB-A3A9-1DA9AAB77C6A@gmail.com> References: <61C0885E-3363-4B70-B64F-C471A4A16B3C@csperkins.org> To: Colin Perkins 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, 07 Dec 2017 20:12:00 -0000 On Dec 6, 2017, at 6:43 PM, Colin Perkins wrote: >=20 > Exporting SRTP keys from the QUIC handshake seems sensible, but is an ex= tra level of specification complexity. I suspect we=E2=80=99ll want SRTP dem= ux short term, key export in medium term, and RTP-in-QUIC in longer term. [BA] +1.=20= From nobody Thu Dec 7 13:48: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 0679D127286 for ; Thu, 7 Dec 2017 13:48:49 -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 (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 xysUxd1Kg0Jl for ; Thu, 7 Dec 2017 13:48:46 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F80126CF9 for ; Thu, 7 Dec 2017 13:48:46 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id b5so533681itc.3 for ; Thu, 07 Dec 2017 13:48: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=TPb3wGl/54798sdmFEyLu397OeIdOsrLjn2siCnf1u0=; b=PV4JDNfAglx9LtBb8QmZnSKK+/Ba3CQqn3wUP40Am+X7B4t9Kcu1yzuyrO57vtWtra BB6OfXmmeZyPalgvbTEUkK2Zqe7vDd3/01mZ1rD2zvSQOAoxm00ZNHVsUAvSiypDcSx8 ERFt5njxxCkFa3YSz+Q7w9+ZxPMPtQ+7xzn9sd+PCLhBSwZkpCgmugiJfxIoJdvOmMAe vmDiEQa6rSljG+nKYqoivOEfQLgLLBqUL5F8AsndDbxdbbaAU0z771FRNKCK7z+s6RoV oMt5BlK+YKHV3NhIPKBbZJINQtF053KbLA5FoR4WFIpHknb4IjCAdsxudgJVALGAkAhR vXlQ== 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=TPb3wGl/54798sdmFEyLu397OeIdOsrLjn2siCnf1u0=; b=UtZWyZaZrB0ietbujd6PIb5bTdMvI/GawG2LmWHJewFJ+Zem/MAU6QRYpGgzymeWqh uMnZINUmvsvIJHvJWixmIK9IHpylqJf6VKAf8xzDQ5fkkfWrwo7kheDFOJQL2Awa4C60 JCw2ZsVD9f2oxBAQcb0QB86PopIL99w15v6SC02jhGXbJsSoKkmJz32Cr7u5ByemE5p3 3iIKaUf5kV76SePmNpy/+vnZ6PDNLwZYe+Es1O3uI20mtcCw9FWfsePsH4t3lzPJBRaj VUeO3DdoSnI9Wncnud79KB4uwF1I6DAUuI/SRn++rQMAYnGR0/Zt/tHMeaZTBTHv9rYh fDkg== X-Gm-Message-State: AKGB3mIcCWw1Re4UVUBagkHxrEjMiSsAAo2l9LmvhFufu3LyRcacJHCA tMsa5p2SpQHms/p6+mtssnls/eJcrbxXW/Pfff9/dw== X-Google-Smtp-Source: AGs4zMazjHnNGZHCgO08FzyLThcADHnUyQxLTQyqjN/ODxEPnb3JW9ai/xjCkRgSSZAAG2nWWkWBuAkBoyO2tI0pVCg= X-Received: by 10.36.145.203 with SMTP id i194mr3159549ite.73.1512683325538; Thu, 07 Dec 2017 13:48:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Thu, 7 Dec 2017 13:48:24 -0800 (PST) In-Reply-To: References: <1726D0F2-CE76-418C-BE24-CA3492F4CC27@iii.ca> <65c4d1cd-8927-1a96-a45c-734e743279ac@huitema.net> From: Ian Swett Date: Thu, 7 Dec 2017 16:48:24 -0500 Message-ID: Subject: Re: More on demultiplexing To: Jana Iyengar Cc: Christian Huitema , Ted Hardie , IETF QUIC WG , Eric Rescorla , Cullen Jennings Content-Type: multipart/alternative; boundary="94eb2c0ef6504749ef055fc708ad" 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, 07 Dec 2017 21:48:49 -0000 --94eb2c0ef6504749ef055fc708ad Content-Type: text/plain; charset="UTF-8" I was thinking along those lines as well, Jana, since I think we have a pretty general problem here, and if we grease the type byte, I think we can create a fairly simple solution. As you mentioned, the WebRTC over QUIC mapping would have to specify which QUIC codepoints could not be used in the short and long header. As a slight tweak on your idea, I think that only the application should specify what codepoints cannot be greased for the long header, but the transport params can contain additional codepoints which are to be avoided by the peer in the short header. So the list of codepoints to avoid are not negotiated, but communicated.(ie: the client might be fine with anything and the server might exclude DTLS codepoints). And any codepoints the application mapping specifies should be avoided do not need to be communicated in transport params. As an example, this means that even if the types are 0 through 3, those codepoints may be excluded and never sent on the wire and in reality, numbers more similar to the submitted PR#956 may be sent on wire. This means there may be conflicts between the long header and a different application that happens to be running on a given port, but those can be handled by looking for long headers and checking the version before doing any more expensive processing. Cases like WebRTC should be easy to handle by excluding the problematic codepoints in the WebRTC over QUIC mapping. The only(obvious) rule is that you can't exclude all ways to express a given type, but that's dependent upon the exact type byte greasing approach, which hopefully we can separate from the multiplexing approach. On Thu, Dec 7, 2017 at 3:00 PM, Jana Iyengar wrote: > On Thu, Dec 7, 2017 at 11:51 AM, Christian Huitema > wrote: > >> On 12/7/2017 10:59 AM, Cullen Jennings wrote: >> >> >> On Dec 6, 2017, at 12:15 PM, Ted Hardie wrote: >> >> >> >> I think if you bundled all the media on one 5-tuple and had QUIC on >> another, the core NAT exhaustion problem would not be that bad. >> > It would be twice as bad :-) When creating the offer, the device that >> creates it does not know if it will be getting QUIC based stuff or not so >> you want to include both in the offer. For the same reason we don't want to >> gather two ports for RTC and RTCP, I think we will want to run both on same >> port. I think google's data showed that nat traversal success rates were >> worse when using two ports instead of one. >> > >> > So my preference would be to be able to multiplex WebRTC using QUIC and >> and WebRTC not using QUIC on the same port. >> > >> +1. When dealing with NAT, there is a cost per port to "opening a hole >> for the port", in terms of messages to open the port, risks to cause >> resource exhaustion in a local NAT, and requirement to keep the port >> alive. Everything on one port is nice. >> > > I agree on this point. It's more than just nice -- it avoids strange > partial failures when one part of the communication works (over one port) > but the other part (over the other port) doesn't. > > >> By the way, how strongly do we feel about making decisions based on >> first byte alone? In the case of QUIC, the connection ID provides a >> pretty big clue. If we use that, demux becomes significantly simpler. >> There are still issues during the connection phase, as the first message >> from the peer carries an unknown connection ID, but that could be >> handled with special logic. Also, don't STUN messages carry a magic >> number precisely to help demuxing? >> > > Why have the same conversation once in one place when we can have it twice > in two places :-) I raised this point in #426 > , and Colin responded > there, you may want to take a look. He does suggest using connection ID, > but it's not yet clear to me that the C bit needs to be changed in that > case. > --94eb2c0ef6504749ef055fc708ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was thinking along those lines as well, Jana, since I th= ink we have a pretty general problem here, and if we grease the type byte, = I think we can create a fairly simple solution.

As you m= entioned, the WebRTC over QUIC mapping would have to specify which QUIC cod= epoints could not be used in the short and long header.=C2=A0 As a slight t= weak on your idea, I think that only the application should specify what co= depoints cannot be greased for the long header, but the transport params ca= n contain additional codepoints which are to be avoided by the peer in the = short header.=C2=A0 So the list of codepoints to avoid are not negotiated, = but communicated.(ie: the client might be fine with anything and the server= might exclude DTLS codepoints).=C2=A0 And any codepoints the application m= apping specifies should be avoided do not need to be communicated in transp= ort params.

As an example, this means that even if= the types are 0 through 3, those codepoints may be excluded and never sent= on the wire and in reality, numbers more similar to the submitted PR#956 m= ay be sent on wire.

This means there may be confli= cts between the long header and a different application that happens to be = running on a given port, but those can be handled by looking for long heade= rs and checking the version before doing any more expensive processing.=C2= =A0=C2=A0

Cases like WebRTC should be easy to hand= le by excluding the problematic codepoints in the WebRTC over QUIC mapping.=

The only(obvious) rule is that you can't excl= ude all ways to express a given type, but that's dependent upon the exa= ct type byte greasing approach, which hopefully we can separate from the mu= ltiplexing approach.

On Thu, Dec 7, 2017 at 3:00 PM, Jana Iyengar <jri@google.com= > wrote:
<= div class=3D"gmail_extra">
On Th= u, Dec 7, 2017 at 11:51 AM, Christian Huitema <huitema@huitema.net> wrote:
On 12/7/2017 10:59 AM, Cullen Jennings wrote:

>> On Dec 6, 2017, at 12:15 PM, Ted Hardie <te= d.ietf@gmail.com> wrote:
>>
>> I think if you bundled all the media on one 5-tuple and had QUIC o= n another, the core NAT exhaustion problem would not be that bad.
> It would be twice as bad :-) When creating the offer, the device that = creates it does not know if it will be getting QUIC based stuff or not so y= ou want to include both in the offer. For the same reason we don't want= to gather two ports for RTC and RTCP, I think we will want to run both on = same port. I think google's data showed that nat traversal success rate= s were worse when using two ports instead of one.
>
> So my preference would be to be able to multiplex WebRTC using QUIC an= d and WebRTC not using QUIC on the same port.
>
+1. When dealing with NAT, there is a cost per port to "op= ening a hole
for the port", in terms of messages to open the port, risks to cause resource exhaustion in a local NAT, and requirement to keep the port
alive. Everything on one port is nice.

I agree on this point. It's more than just nice -- it avoids str= ange partial failures when one part of the communication works (over one po= rt) but the other part (over the other port) doesn't.=C2=A0
=C2=A0
By the way, how strongly do we feel about making decisions based on
first byte alone? In the case of QUIC, the connection ID provides a
pretty big clue. If we use that, demux becomes significantly simpler.
There are still issues during the connection phase, as the first message from the peer carries an unknown connection ID, but that could be
handled with special logic. Also, don't STUN messages carry a magic
number precisely to help demuxing?

Why have the same conversation once in one place when we can have it twi= ce in two places :-) I raised this=C2=A0 point in #426, and Colin responded there, you may want to take= a look. He does suggest using connection ID, but it's not yet clear to= me that the C bit needs to be changed in that case.

--94eb2c0ef6504749ef055fc708ad-- From nobody Thu Dec 7 15:20: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 768FA127B73 for ; Thu, 7 Dec 2017 15:20:16 -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 (2048-bit key) header.d=mnot.net header.b=Dhb+ChqR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I4kwDFeC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztZ_wsoEsALc for ; Thu, 7 Dec 2017 15:20:13 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94BCF126B72 for ; Thu, 7 Dec 2017 15:20:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 719D720A8D; Thu, 7 Dec 2017 18:20:12 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 07 Dec 2017 18:20:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Y8we2G r5TkumKfCzfVEJPPwQOUVL+A7ADSYp0cjk/pU=; b=Dhb+ChqRhTo+ceiHH7/Lx5 1v+FbUm6AzDNMS/Z5J2S7+M7OO+lMPkVFlgCl6I42xnDhtkNZQ2mrGb+uT9LQl0s F0t6xl08QlhwJXi/5DtB3qAiA5wi3pBR55bUkONPyy5z1ho1OpoUtUxkAQpQ+z9R BSF1jWK7F9IcREcfuETjOGYRBCh04q3zToIRZa6DbbH7Y5AJj8W13fs1nF1JR2Ik 7SEaQpmpYj2Vo8VrEIIx+l93hxJs8vF/d80gwI2bVp3SRkN3gaz6QOLdKKKx+Ou7 EJb93rcxm4ngc+P+FWr0FSRUCFllz3l4froaRYszVkJuy2ITWkl8JnpYrwiE4tCg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Y8we2Gr5TkumKfCzfVEJPPwQOUVL+A7ADSYp0cjk/ pU=; b=I4kwDFeCWe1FIyAvXoiWPCUasYrkudgJwD2DIp7Boc5GT1iujjhyYldbr cDYKnuKTVRkQgwZW79xJQrkgNCZQnweBRuLhK5IVXpM1DCOyZY8kYGUr5KyYM4/7 MvpQHGa227Pl7gbPvbRz3aVRwVijqFuj/2hlcii/IQzo+N1Vyxl/oWTfPDakCsCv JkW7R9TJ39kj0BijadFhIz6VCpv1kBNHA2x018LnU1ee9SCixI33aONZNgMsPwcV GVvOIm7WXHYakYyx33t4odRoknT9AKmLmgzujS/gvW/zX6yFEXYNZY6Y9UnLzDHO yKgGxcXMJbnaKYmsUN96xKG4ta/Gg== X-ME-Sender: Received: from [192.168.1.18] (cpe-144-136-175-28.sa.bigpond.net.au [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id E3E38240A4; Thu, 7 Dec 2017 18:20:10 -0500 (EST) From: Mark Nottingham Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3913B1E9-051E-4019-A546-040A33D34D73" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Fri, 8 Dec 2017 10:20:07 +1100 Subject: Melbourne interim registration closing today References: <150712475270.24252.1965027482254580403@ietfa.amsl.com> Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.4.7) 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, 07 Dec 2017 23:20:16 -0000 --Apple-Mail=_3913B1E9-051E-4019-A546-040A33D34D73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reminder - registration for the Melbourne interim closes today, December = 8.=20 See: = https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangeme= nts.md = If you want to participate remotely, you also need to register. It's already after 10am on the 8th in Melbourne, but if it's still the = 8th where you are when you register, that's OK. > Begin forwarded message: >=20 > From: IESG Secretary > Subject: QUIC (quic) WG Interim Meeting: 2018-01-23 > Date: 5 October 2017 at 12:45:52 am AEDT > To: "IETF-Announce" > Cc: quic@ietf.org > Archived-At: = >=20 > The QUIC (quic) Working Group will hold > a multi-day interim meeting. >=20 > Session 1: > 2018-01-23 09:30 to 17:00 Australia/Melbourne > Session 2: > 2018-01-24 09:30 to 17:00 Australia/Melbourne > Session 3: > 2018-01-25 09:30 to 17:00 Australia/Melbourne >=20 > Meeting Location: > Melbourne, AU >=20 > Agenda: > TBD >=20 > Information about remote participation: > Remote participation information will be provided upon registration. >=20 > = https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangeme= nts.md >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_3913B1E9-051E-4019-A546-040A33D34D73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Reminder - registration for the Melbourne interim closes = today, December 8. 

See:
  https://github.com/quicwg/wg-materials/blob/master/interim-18-0= 1/arrangements.md

If you want to participate remotely, you also need to = register.

It's = already after 10am on the 8th in Melbourne, but if it's still the 8th = where you are when you register, that's OK.



Begin forwarded = message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Subject: = QUIC (quic) WG = Interim Meeting: 2018-01-23
Date: = 5 October 2017 at 12:45:52 am = AEDT
To: = "IETF-Announce" <ietf-announce@ietf.org>
Cc: quic@ietf.org
Archived-At: = <https://mailarchive.ietf.org/arch/msg/quic/uUCbfwIG_7igsH6se2jJ= zw2ZWJ4>

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

Session 1:
2018-01-23 =     09:30 to 17:00  Australia/Melbourne
Session 2:
2018-01-24 =     09:30 to 17:00  Australia/Melbourne
Session 3:
2018-01-25 =     09:30 to 17:00  Australia/Melbourne

Meeting Location:
Melbourne, = AU

Agenda:
TBD

Information about remote participation:
Remote participation information will be provided upon = registration.

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


--
Mark Nottingham  =  https://www.mnot.net/

= --Apple-Mail=_3913B1E9-051E-4019-A546-040A33D34D73-- From nobody Thu Dec 7 15: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 A50DC1286B2 for ; Thu, 7 Dec 2017 15: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyt-w5_IIIfb for ; Thu, 7 Dec 2017 15:51:49 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 31AF21275C5 for ; Thu, 7 Dec 2017 15:51:49 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id v21so7880654oth.6 for ; Thu, 07 Dec 2017 15:51:49 -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=N8ennN2OPKxTMiwNZZD7p3DQJfsRIVDIEkLcIvXOxVY=; b=nwHRTOnFeBOs+5Y6pcBWEjcb4538bD6MW2qEbPhUvxaHzFKQz+p0V6L3c/iUopmrPi XIShgZt9QLIO4D/Fxroa4vkjSF4IILcvUEiJcG0g8WVPbiYG0CgPTbk3ZAHl+KeiyXkv B2PrADa8DNkyyY5jp94Xdi4b288Igvgmj8T3VxVoWpbU33+gz1ZZZoawMI4MeeXw7/1a E5kSP1KCCRgww0WRfzprTheK8gPHSq1P+7xhrtYULxw8LhADcrDgOz97K7zvpT+T7uSp ytu3XwWx551gM8AzjgSNyj3H20gyhpw7Jxn17UVXJDobQBtCjLhdbhRMnFRBp5S+U5hk UTUA== 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=N8ennN2OPKxTMiwNZZD7p3DQJfsRIVDIEkLcIvXOxVY=; b=Hxj5XtI+H/yCuy06pjauLZ/5/VlR/I9THqaT4DTiFxajFr28kJC15IuZOFXbITfFov wPnsNbkYDA7tHxarljG2jNwapkJAL7di8Vl4JrhqGQyp1c0LnDiQk/PRziaSIILaRQ8J RQ3HKqkkKHMIujDUzjOAJUN+8OpSb1FoCpve+uSED8D/Lzbo8KwQm0Lz+jpTGqJn0Wyu MBLFOareQV6SAIC8e/QcD9hnjuAKMhsCA2QE1R5OCA4Oygjlfrb9Z7ubPMWMdQl6bOAY T+PSAUOibuiWIoM21cEzaEDwQ9wPWvsjoIexQFXuSKz8vU/UU7aObEw9jIaJuqXtL8XB fpAg== X-Gm-Message-State: AJaThX4fR3UroIhrfhklu6yL6FPJ56Pw9muUA0uAYnDZ8OFQtxrhxUW9 LAKHYTzPz3p5nk0LMhXj4QFMVqyDbib218jsP9I= X-Google-Smtp-Source: AGs4zMYrLmd28t9sXKJtcogs/ZXSQFhwqyAEYdxd5FKleJUA5XQQWG+mZWyq7oKRexE/DE2uOoXi0iXITqyd7FHAWPw= X-Received: by 10.157.88.141 with SMTP id x13mr25513212otg.175.1512690708411; Thu, 07 Dec 2017 15:51:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 7 Dec 2017 15:51:47 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 8 Dec 2017 10:51:47 +1100 Message-ID: Subject: Re: Greasing more of QUIC To: Jana Iyengar Cc: 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: Thu, 07 Dec 2017 23:51:51 -0000 On Thu, Dec 7, 2017 at 6:38 PM, Jana Iyengar wrote: > I suspect the mechanisms here are a bit heavyweight for the greasing model I > had in mind. Not really, see below. I included a more heavyweight option to show the range of options that I think we have in front of us. > The model I had in mind was that a middlebox that cared to read > the spec would be able to interpret the packet types, but it couldn't from > simply looking on the wire. I don't think we want to use a per-connection > key, as load balancers will want to know the packet type and won't have the > connection keys. Visibility for middleboxes is the reason we didn't encrypt > the packet types in the first place. I want to challenge this last point. I don't think that we've established a good reason for middleboxes to have visibility into the short header types, and anything that we do for the long header can probably only be based on the spec in exactly the way you describe - we never use anything other than a fixed key to protect packets with long headers. I'm personally more interested in packet numbers than packet types though. > If you wanted to do a PRP based on this weaker model you'd end up using a > known key per version, documented in the draft. Of course, the problem here > is that you don't grease any values since the same permutation is used for a > given version, and the permuted packet types remain fixed for the version. One property I'm looking for us to guarantee is that no value goes unused, even if the actual underlying value is the same. That means per-connection permutations. > You could combine the version-specific key with something from the packet, > perhaps the packet number (not the entire 64-bit number, only the visible > part on the wire, for stateless middlebox operation), to permute the packet > type, giving you more useful greasing. That's effectively what this does. The draft (I'm beginning to regret doing that now) mentions using connection ID, as input to the key. I should have added both packet number and even the ciphertext. You will observe that XOR is very close to what you describe if you take packet number as input to the key derivation (XOR and additional modulo N are very similar). If you took connection ID and packet number in the following form, you get almost exactly what you describe. E(x) = m ^ connection_id ^ packet_number > This is just me thinking off the top of my head, but that's roughly what I > had in mind. It obviously assumes a weaker form of greasing than the ones in > your draft is desirable. That is a reasonable position. Types will never really benefit much from anything more complex. For packet number, I wanted something stronger to support the ideas in the final section. From nobody Thu Dec 7 16:31: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 7CC4E120726 for ; Thu, 7 Dec 2017 16:31:10 -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 b21zQ5AQJST4 for ; Thu, 7 Dec 2017 16:31:08 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B90712871F for ; Thu, 7 Dec 2017 16:31:08 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id w131so6203829oiw.0 for ; Thu, 07 Dec 2017 16:31:08 -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=0Jkx8YaTYrLXuoUVcY+YRAL3MNazPq1gJvFCgFKWfnE=; b=mJRMkm+OGgTszXxrryqa79X8srolzfu5aweU+zRv/YpJOArn+WhUoRWz0WgsAjN5vJ X/D4cZvYK2CDQzgCHfFdV9taYuYmuJAk/CRWOnt/baXrYiCCx3xmrLo5nfrNslBWrrjz ENJVP1kPVzJ2N7nszc+kHJU8GRgEsS0yGA5gk0JM+dsi4k9kNdzpapLiUYBm6SL5BBH/ jvUByTCA9aVFGdd1C+FHlVUEiJy+wX028U7T9jnJjcdmtMUpYrLnjU46Xcu2K5l0h7Yb utXXXYI9zIzvSRB7wR/W9Iy9hRf9HE4EoHZsCnaX2JS3uzlV3p4GC41FLlMSWqtBSL1d 5aow== 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=0Jkx8YaTYrLXuoUVcY+YRAL3MNazPq1gJvFCgFKWfnE=; b=IH0MRZh8uIsX1BYRAY9fnGpX2KTEwfdrIzejdinKFibCZnjV+hLBlPixpoAInYCYyw 9GlRszgAXFel/Y8ktWUC0ZP/ElZk9JAGSXWL89BZ4wx4nmzFEaNJpejCDrDkLQ5qwWe1 3yfRbyBSSruuFP+V504hO/AbMn8a/665dKFlz/P3KlMp7A8i7jfB+NUOoznIFUwBCg9y XMqcPcHbDzxyzoQ6aTOi4upujQaLtPV4cKtaRvTHQSl24jrdhpt4KeRIC2ni0nSU5YYf 4HVI97L4jRIhYIBTPV67eT3NfXXRjsw40UQsUohzt1VR4Gb0/tI3Vath7CsD/H1OrPwD qOmw== X-Gm-Message-State: AJaThX4Ms0IGsdh3h+OA/54FGrMMmB4nJAF4rdE8X3YzTf54U6QuHAfX wfxz9446Uvg62WOchKJpTm2QUu73sXmFmkSEwj0Ev+5qSAg= X-Google-Smtp-Source: AGs4zMYHhAAYDr2sxbNKD2nHM7cONZTsWBrFnEC5fDgbz6PRKUPw2U4nhKnLhJuWUZ3SdCyGz0OG2J4dqNL1KnkhGng= X-Received: by 10.202.166.206 with SMTP id t75mr24395134oij.28.1512693067214; Thu, 07 Dec 2017 16:31:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 7 Dec 2017 16:31:06 -0800 (PST) In-Reply-To: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> References: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> From: Martin Thomson Date: Fri, 8 Dec 2017 11:31:06 +1100 Message-ID: Subject: Re: Greasing more of QUIC To: "Brian Trammell (IETF)" Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 08 Dec 2017 00:31:10 -0000 On Thu, Dec 7, 2017 at 8:11 PM, Brian Trammell (IETF) wr= ote: > hi Martin, > >> On 7 Dec 2017, at 06:03, Martin Thomson wrote= : >> >> I've sort of promised a few times, to a few people, that I'd write up >> the state of play regarding greasing. I just did that and it got >> somewhat lengthy. So I decided that I'd put the words in a draft. >> Sorry. That's what you get when publishing drafts gets easier... >> >> https://datatracker.ietf.org/doc/html/draft-thomson-quic-grease > > First, I'll note that draft focuses on runtime adaptations: how can we sc= ramble the wire image to resist analysis by vendors who will implement the = results of that analysis in ways that might break future QUIC versions by d= ropping packets? This is only part of the space of mitigations available to= us. There are also design- and deployment-time adaptations: exercising the= version negotiation mechanism, for instance, by making the V2 header beyon= d the invariants gratuitously incompatible with the V1 header and deploying= it very, very soon after V1. Right. And I still think that's a better general defense. > When you said "this got lengthy", what I was hoping I'd see here, and did= n't, is an explicit statement of the threat model the greasing we apply is = meant to counter. "Ossification", yes, great, but in order to be able to ev= aluate the tradeoffs (especially between XOR and FFX), we need to get a bit= more specific about what that means. > > I can think of a couple of axes along which we can classify these models: > > (1) Adversary intent: what is the middlebox trying to do? I don't think that intent matters here. One of the things I've learned from TLS that attempting to discern intent is like trying to comprehend Lovecraft's Deep Ones. It's a short trip from there to an asylum. Your next two points I consider to be points on a spectrum. The biggest problem is the one you alluded to above. The middlebox is deployed and is inflexible. It can be perfectly capable, understanding everything there is to understand about the protocol short of getting session keys, but that doesn't mean that changing anything is possible. Even if the upgrade pace of the middlebox is rapid - and our experience with TLS suggests the opposite - nothing safeguards flexibility better than being flexible. As I said, I think that the best we can do within any single version of the protocol is to force middleboxes into stateful inspection if they intend to look at version-dependent traits. This is confounded by the fact that even if a middlebox does stateful inspection, they won't necessarily see the version due to the possibility of connection migration. That said, as long as the number of packets required to prime stateful inspection exceeds or equals the number of packets that are required to correctly recover the version, this could be successful. Ideally, learning version is a prerequisite for recovery. > Greasing is of most utility, IMO, when it is used to prevent lazy, somewh= at-competent middlebox creators with access to but little interest in readi= ng the specs from expanding the set of invariants beyond those which we pre= scribe, whether intentionally or unintentionally (indeed, a non-lazy advers= ary working to intentionally expand the set of invariants would just send a= pull request on the invariants doc. :) ). That is more proactive than I'd look for. There's no business motivation for worrying about protocols that aren't deployed. Middlebox vendors definitely aren't stupid or lazy (notable exceptions aside). They implement what they need to, and read the specs as necessary. But what's deployed matters. That's where we get into trouble. The middlebox that has an "allow HTTPS" policy learns to examine flows more closely when people start using TLS over port 443 for other protocols to circumvent that policy. When they look too closely or too incautiously (see for example https://arxiv.org/pdf/1607.01639.pdf), we experience bizarre breakages. The point here is to increase the cost of the sort of casual, stateless inspection that can be destructive to the point that stateful inspection is more viable. Either that or encourage the use of techniques other than looking at packets. > Doing something to protect the ability to expand/change the location and = semantics of the packet type switching mechanism and the packet number spac= e and encoding in future versions seems like it's worth doing. Attempting t= o make these mechanisms resistant to analysis, though, doesn't seem like it= has a benefit commensurate with effort and proneness to error. The only analysis I'm looking to guard against is correlation across migrations. Using an unpredictable key has that advantage. (It also removes a bunch of really ugly properties from the current mitigation.) From nobody Fri Dec 8 00:45: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 6CB141201F8 for ; Fri, 8 Dec 2017 00:45:44 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4sahXBY6gpa for ; Fri, 8 Dec 2017 00:45:42 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 9ABFC126DEE for ; Fri, 8 Dec 2017 00:45:32 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id b5so3384539itc.3 for ; Fri, 08 Dec 2017 00:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=ZE+o8THP8r/S0+Lvxeub8ffz3wP3tsdrjx6gSt/VTUs=; b=dLVRDl02605xwpqdjiHpJRGujyTsZptWQeqsRPtmb4oucMsvlxUAjsaQl4GsgQE7kD e23ZFoGKdsENdbIRTtvCzpoJlqm7f1kvIWKGQKAO2Ij8JWNARXSB/Q7mh91FQjLPKPvr /I/7lPICTyaUyEVnn/I3GLgWKCjvRREbWof3lzkNZrgiJfQcjMTqqTzBgFsC9UmZ/XHp dCLrwPVoQn4wIgHADyO+SVqFbhmiUEDInKo62+e9aVYIYHauMUwdtgDMEvLNpyKeROkv d537YKM3mLDlhpdNQjU8KefczSrcB/5qHCQOF8PVq+FJeR7/c3OxUqdMslx8gkG8lmkd Zt1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=ZE+o8THP8r/S0+Lvxeub8ffz3wP3tsdrjx6gSt/VTUs=; b=Erustl2TrTXFTA8g0rTmy5AmULUG5PEy1CYxHCl1+cURDWWRMca9r5LY4OQWNwt5rN B0am2QPU95BeNyKUiZQojIoRZ3a+UYi1Mvs+ESbLjbCQPZU1/smxYL+qfQBydSsqsIKu z6FrEL2/pStq3IBvcYaqZrDg976dNUgnkoR8pahncJE0GaXjMQFEzQsCx2Hr6K/GtfL4 TIuYEuBkAAEcbaYPhZiIfP9w+wwa9RNzFVtMrbmGvPBdkL/jnAIMxvRycnnYq9zYIHY1 svikAAr+idLMbF4JDGIQaAVtiZiepmwpUzybJLQp3HXw7smj//l1U5vLC9p70cj1vhCH qE1w== X-Gm-Message-State: AJaThX6UoFNwUOSc5GjP9Cfyrm+nOoYnV4yr9Ud5vxv7BSFtqF3h70PB VGESDwQJaC4VZMfD9AgPLxir0k4U0TkHc9OVd+TcJA== X-Google-Smtp-Source: AGs4zMYhguuaOpxgychaMNTf5nbM/tjLq0PnVUzXI91thNcMqXbCf4Pp9h/KwlEsQjEN3+cEK1wz4i4/ETWQ6nAn/Tw= X-Received: by 10.107.47.234 with SMTP id v103mr38919608iov.96.1512722731662; Fri, 08 Dec 2017 00:45:31 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Dec 2017 00:45:30 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 8 Dec 2017 00:45:30 -0800 Message-ID: Subject: Feedback from first read of QUIC/HTTP draft 08 To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1135a438109da7055fd035a7" 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, 08 Dec 2017 08:45:44 -0000 --001a1135a438109da7055fd035a7 Content-Type: text/plain; charset="UTF-8" This was originally #1001, but moved here on upon request. Reading through the QUIC/HTTP-draft-08 a few things appeared unclear. This is just a summary based on my first pass over the document, so take it for what it is. I have only superficial knowledge of HTTP/2 in advance. 1. A bit too much discussion of HTTP/2 instead of leaving that for section 8. It does not help understanding QUIC/HTTP from scratch. And perhaps a bit too much assumption about HTTP/2 knowledge while implementers might have skipped that step in their evolution. 2. No explanation of how methods are communicated. Header fields reference HTTP 1.1 draft, but from skimming HTTP/2 doc, it is clear that these (as suspected) are transfered via special headers known as pseudo headers). 3. Lots of frame type flags, none used, and only a few types. Why not either remove flags and have more types, or have a type bit encoding for flags presence (this may be due to early state of draft, just mentioning). 4. Why are settings 16 bits instead of varints, and why is the space so large. A 256 or even 2K space would be easy to have in a table, 64K requires a map or switching logic. A settings space still requires that both ends understands a signficant portion of settings to make any real sense. Who decides to add more settings. Is this to have space for the next century, or just until the next QUIC version? 5. There is an End Header Block something, but it is unclear what it is. Is it a flag to be defined, or some pseudo header? 6. The GOWAY discussion could probably be shortened and made it bit clearer - it takes a few readings to understand the point of multiple GOWAY frames and why the ID can decrease (not sure I do fully understand). 7. A basic example of a short HTTP 1.1 request and how it looks in the protocol would be helpful. 8. The HPACK, to be replaced, doc is hard to parse, and it doesn't sound like it is as complicated as it reads. Hopefully a future QUIC equivalent would be a bit easier to digest. 9. The entire push hierarchy sounds very complex - I wonder what the takeaway from HTTP/2 is - is it really worthwhile, or is no-one using it yet, but in 10 years it will be huge? --001a1135a438109da7055fd035a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

This was originally #1001, b= ut moved here on upon request.

Reading through the QUIC/HTTP-draft-08 a few thin= gs appeared unclear. This is just a summary based on my first pass over the= document, so take it for what it is. I have only superficial knowledge of = HTTP/2 in advance.

  1. A bit too much discussion of HTTP/2 instead of leaving that for sec= tion 8. It does not help understanding QUIC/HTTP from scratch. And perhaps = a bit too much assumption about HTTP/2 knowledge while implementers might h= ave skipped that step in their evolution.
  2. No explanation of how methods are = communicated. Header fields reference HTTP 1.1 draft, but from skimming HTT= P/2 doc, it is clear that these (as suspected) are transfered via special h= eaders known as pseudo headers).
  3. Lots of frame type flags, none used, and on= ly a few types. Why not either remove flags and have more types, or have a = type bit encoding for flags presence (this may be due to early state of dra= ft, just mentioning).
  4. Why are settings 16 bits instead of varints, and why i= s the space so large. A 256 or even 2K space would be easy to have in a tab= le, 64K requires a map or switching logic. A settings space still requires = that both ends understands a signficant portion of settings to make any rea= l sense. Who decides to add more settings. Is this to have space for the ne= xt century, or just until the next QUIC version?
  5. There is an End Header Bloc= k something, but it is unclear what it is. Is it a flag to be defined, or s= ome pseudo header?
  6. The GOWAY discussion could probably be shortened and made= it bit clearer - it takes a few readings to understand the point of multip= le GOWAY frames and why the ID can decrease (not sure I do fully understand= ).
  7. A basic example of a short HTTP 1.1 request and how it looks in the proto= col would be helpful.
  8. The HPACK, to be replaced, doc is hard to parse, and i= t doesn't sound like it is as complicated as it reads. Hopefully a futu= re QUIC equivalent would be a bit easier to digest.
  9. The entire push hierarch= y sounds very complex - I wonder what the takeaway from HTTP/2 is - is it r= eally worthwhile, or is no-one using it yet, but in 10 years it will be hug= e?


--001a1135a438109da7055fd035a7-- From nobody Fri Dec 8 05:01: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 E3A15126C22 for ; Fri, 8 Dec 2017 05:01:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9LVzDvYVfJV for ; Fri, 8 Dec 2017 05:01:29 -0800 (PST) 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 414E4124D68 for ; Fri, 8 Dec 2017 05:01:29 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id a16so25743774qtj.3 for ; Fri, 08 Dec 2017 05:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=2E7nFR63roRv0RlI0aqEv16O9WjmbfEY+RIDEbcHxl0=; b=t9R9v0FEVJnC92FNCBC5u1rNogd6k3teeOuFqUt5yOWg6WHLrPE1CCyTohQnGVCiZA g4tPV2XYYUXM1/6r0ofQjio6B5XstXfj+Eb3md5gPF81uz9WZ1h6+3u4atoWiP/zS0/1 sLc0HjKbbhsilmWUskeOou5xNlMWFQUH7TysuCTXT80X03LXlIGMRJGxwazJQLDL+iBe KlJXaAt+aE+DvfdEdp/14XveDfSIWF6YsAz9iaZ+FF/OFYd+ThoK7v4Foh6UjtG4WJxU O/8GzxKEGrcZXnNseJIf4vZ1tAUvU0oE60eSItTUns6vfeI273Kt75c0LZDBWFbSAYOl HEhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=2E7nFR63roRv0RlI0aqEv16O9WjmbfEY+RIDEbcHxl0=; b=ZQG/gZbUkoBH05iOvd+NesVt+2D73eEq96XSYXiJPWxryUXZntHiT/zxF2yZYTwyHG AAw66ZvQTk86GTtQ03FbFL9eXvWuDIujUmjvIrwjZxAuREYEZhJKziCCiB1+G/Ptnzv3 +ZL/iqv9CW0CfoDtuZHoKF57fm4vGCCplEMlnN35pExvz0pCwR6p9lNvdoz3Sh0GiwF4 oaDeaZNahg9LPXncMwIbNnlyWiiMe/ono8ehp2HP5x7nHu8VhwHP1JGD0EJfgCl5ltp5 Oy7G5lUiAQb2cg5zbXdAMjqbmzHcK6tPoInQN+5QAEjkrez7UFJ5D5dItsKp+aHRbZ7w WZiw== X-Gm-Message-State: AKGB3mLCxLQ/KGfiHoB0vPbgp1NZzPPxfOnVzAc6VvO+cKEwrE9El0vX D/jRmmynmero47x/YYox+9tq+z2Z X-Google-Smtp-Source: AGs4zMaqKwDsOoxX/UcIt5mRkIf6pb7Gv94k+nBNcZ3a1o0bgRvn/o/KSszKtT3ZJMQc8h0iNYa5kQ== X-Received: by 10.200.46.167 with SMTP id h36mr15510758qta.267.1512738088304; Fri, 08 Dec 2017 05:01:28 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id g8sm4342911qth.68.2017.12.08.05.01.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 05:01:27 -0800 (PST) Date: Fri, 8 Dec 2017 08:01:23 -0500 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: IETF QUIC WG Subject: Re: Feedback from first read of QUIC/HTTP draft 08 Message-ID: <20171208130122.GA8878@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 08 Dec 2017 13:01:31 -0000 On Fri, Dec 08, 2017 at 12:45:30AM -0800, Mikkel Fahnøe Jørgensen wrote: > 8. The HPACK, to be replaced, doc is hard to parse There are three HPACK replacement proposals (neither of which is referenced by [draft-ietf-quic-http-08]): QPACK, QCRAM, and QMIN. Which one are you referring to? > and it doesn't sound like it is as complicated as it reads. > Hopefully a future QUIC equivalent would be a bit easier to > digest. If you offered some specific examples, I think it would be appreciated: we want to make the documents comprehensible on the first read. - Dmitri. From nobody Fri Dec 8 06:40: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 20274126C25 for ; Fri, 8 Dec 2017 06:40:09 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7dUa3CJiQym for ; Fri, 8 Dec 2017 06:40:06 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61158124D37 for ; Fri, 8 Dec 2017 06:40:06 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id u62so5258778ita.2 for ; Fri, 08 Dec 2017 06:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=gbD6WxgC1tFnyIop2gRCWxdHOP94Rn1seTPfYMGFst8=; b=IYJLiXTxK/rxIH+m9boUwAR8woP+X7pLAa0afSa6u4qbfju6aSyS5UqZpGjakvjxqN WQKP0BIB0dDFmAsbXI0n5xm6ylLsgrzx5WSVUeTYkaCYrkxaVFBPBYCjDv1Y5fdINML+ waJ9Z4+QbVoj6MynXfL/MCGVX7F9nqrD2ekKoBQg5EgzvCPgY7duNvz799UESD6U6ILR phibtUJHnDlG28N+s0f07cMvuSS1ohWgiM5riXM1L2nato/uc0Qq/g0E8fWCkrEWfamW lwcOIQ6Rn+qLr0/rmm7R5Qb/+ZLdtOhtNGRhlJ4w7uzXJreWGCuQ0UIpqJ7skIplI+gN mjhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=gbD6WxgC1tFnyIop2gRCWxdHOP94Rn1seTPfYMGFst8=; b=inDFsH352UjF18WAlYAEML+2L8Ld2TZwZlE1ONE8FJOb3zdtzgUwOsHVWdZmfPLUJs uTiMfgc8uooVHDeAxVg/aZhUcUcCR0KHGq0Us+T6CC18qe4UoztGI7doD+4+EEXrSOz9 LQNzEVZjfttsSWDHSBVzQHqj9dxmjC0B0i54EZqH0rAjQCWe69sa4hz/dMGjeX8qYqn6 RUhRE5z1o+j9EU7vkGklEvPGxb4fOXunNxUwcaP+fUJDYM2vvu8JoBEOX7E/5oL5PSX8 2pJzUp4LDY1JSCfJqsOvnvoKN+ouBDqSuTHi9FnYwog9uJe/4yENDp6zFEfam4Tr0dPS UtZg== X-Gm-Message-State: AJaThX7pLMuRMRCVrT605pzeYHIWZ6OCnCKaKkaaXrqfrk0eRwJvDWA2 gKUg4CgvLYRrEbvppBEtYC2vNtVlsTE44uU69KI= X-Google-Smtp-Source: AGs4zMYjAfAZU5PQg7U0h/JnrEJK4Kpsk7BheeAErkR4Zj2KNrRK4W6WU/kHxJYEyiiOcPOV//nFYvnIaTlBabjj8P0= X-Received: by 10.107.83.24 with SMTP id h24mr44578480iob.239.1512744005525; Fri, 08 Dec 2017 06:40:05 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Dec 2017 09:40:05 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20171208130122.GA8878@ubuntu-dmitri> References: <20171208130122.GA8878@ubuntu-dmitri> <20171208130122.GA8878@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 8 Dec 2017 09:40:05 -0500 Message-ID: Subject: Re: Feedback from first read of QUIC/HTTP draft 08 To: Dmitri Tikhonov Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08284d9015e3f2055fd529a8" 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, 08 Dec 2017 14:40:09 -0000 --089e08284d9015e3f2055fd529a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 8. The HPACK, to be replaced, doc is hard to parse There are three HPACK replacement proposals (neither of which is referenced by [draft-ietf-quic-http-08]): QPACK, QCRAM, and QMIN. Which one are you referring to? I=E2=80=99m just referring to the fact that I=E2=80=99m aware the HPACK is = not the long term solution, but this was the document I was referring to. I have not been looking into Q* yet. > and it doesn't sound like it is as complicated as it reads. > Hopefully a future QUIC equivalent would be a bit easier to > digest. If you offered some specific examples, I think it would be appreciated: we want to make the documents comprehensible on the first read. My intuition is that HPACK could largely be described by the following text, although details may be a bit off as I haven=E2=80=99t digged into al= l the details: HPACK represents HTTP headers in a compact form. Every valid name string and value string can be stored as a HPACK field. A valid name or value string conforms to HTTP 1.1 strings without space, =E2=80=98:=E2=80=99 and = CRLF delimited. A name may also be a pseudo-name starting with =E2=80=98:=E2=80=99 for exam= ple =E2=80=98:method=E2=80=99 used in HTTP/2. The fields are conceptually ordered similar to how the text representation is ordered in HTTP 1.1 such that a similar header can be recreated after decoding. The result of decoding a HPACK stream is exactly such a list, and updated internal state which makes the next exchange smaller in size. This internal state is kept in the dynamic name table discussed below. Some header names are used often and have a dedicated encoding in a static table. Some names are less general but may still be reused across requests, such names can be stored in a dynamic table for reuse. And finally some names should not compressed for security reasons or because it is not deemed efficient. The sender (encoder) decides which form to use, but can only choose the static form if the name is in the static table. Names are always case insensitive. The header values are always just explicit strings that are not compressed (or are they? - did not get that far in the text). We refer to such a string as ValueString. For security reasons and implementation simplicity, the format is simple and not extensible. Instead HPACK as a whole may be replaced by another compression if needed. HPACK depends on the sender (encoder) sending all operations in a specific order such that the decoder can reverse the encoding unambiguously. In the following the three forms of name encoding are discussed further, followed by how the entire list is encoded. The static table is list of known names that is a assigned an index between 1 and K, where K is the length of the static table. Each name is represented as an integer index into this table. We call this value StaticName. The following may not be exactly correct, but this is how I imagine it work from a quick skim. The dynamic table has a fixed size which is negotiated. The size may change, but always in a way that both sender and receiver is aware of it and only in a way the receiver permits. If the sender grows the table beyond the granted limit, this is a fatal error. The current size of the dynamic table is N. The table may not use all entries. If a name is stored in the table it is represented by the integer DynamicName which is in the range (1 + K =E2=80=A6 N + K). The size N may be zero in which case no name= s are encoded as a dynamic name. Otherwise the table is filled up such that the first name is given the value N + K, the next name the value N + K - 1 until the table fills up. After that, the process starts over with the next value again being N + K and so forth. The decoder has enough information to maintain the table as it changes. The encoded issues commands to add names to the table but does not explicitly evict names. The encoder can grow or shrink the table with a single command. In either case the new size takes effect once the table wraps the next time around. We refer to the dynamic table size N as the integer DynamicTableSize. When an encoder adds a name to the dynamic table, it does not send the name explicitly but via a huffman compression scheme based on static huffman codes. The net effect is a command with a bit string containing the compressed name to be added to the dynamic table. No index information is needed because the decoder is in sync. The encoder, by definition, does not need to add names to static table so there is no corresponding operation. We refer to the huffman encoded name as DynamicNameString. Finally the name can be stored explicitly without compression. There is no update command for this. We refer to an explicit string as ExplicitName. The encoding is a stream of commands which we list below, followed by a wire format representation. PushDynamicHeader(DynamicNameSring) ResizeDynamicTable(DynamicTableSize) AddImplicitHeader(StaticName | DynamicName, ValueString) AddExplicitHeader(ExplicitName, ValueString) Done() The encoder sends a list of commands in a very specific order. An implementation is free to choose how it orders these commands, except Done() comes last and AddImplicitHeader must only be called when there is a valid entry in the table being addressed. The decoder processes these commands in order and aborts the operation in case of any violation. The result of the decoding process is an order list of name/value pairs with exactly one field for each AddImplicit/Explicit commands. In addition the decoder now potentially has a populated dynamic table that can be reused by the next request which must be handled strictly after the previous in order to maintain sync. If the decoder wants to reduce or increase its dynamic table it can send this information to the decoder via command X (TBD). This is an async operation. The decoder cannot require the sender to go below a previous sent limit, but it can allow it to grow larger and advise it to shrink. The initial dynamic table size is an out of band parameter similar to the huffman table and the static table. An example is the following HTTP1.1 header where the status line with the GET method is replaced by HTTP/2 pseudo names: =E2=80=A6 example to follow =E2=80=A6 The dynamic table then looks like: ... The Huffman encoding is the list of symbols in appendix A along with the huffman algorithm, The static table is the list names in appendix B, or another set of names if agreed out of band. The wire format of ValueString is =E2=80=A6 The wire format of DynamicName is =E2=80=A6 The wire format of ExplicitString is =E2=80=A6. The wire format of command X header is =E2=80=A6 Appendix... --089e08284d9015e3f2055fd529a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = > 8. The HPACK, to be replaced, doc is hard to parse=C2= =A0

There are three HPACK = replacement proposals (neither of which is=C2=A0
referenced by [draft-ie= tf-quic-http-08]): QPACK, QCRAM, and QMIN.=C2=A0
Which one are you refer= ring to?=C2=A0

I=E2=80=99m just referring to the fact t= hat I=E2=80=99m aware the HPACK is not the long term solution, but this was= the document I was referring to. I have not been looking into Q* yet.

<= div style=3D"font-family:"helvetica Neue",helvetica;font-size:14p= x">
> and it doesn't sou= nd like it is as complicated as it reads.=C2=A0
> Hopefully a future = QUIC equivalent would be a bit easier to=C2=A0
> digest.=C2=A0
If you offered some specific examples, I think it would be appreciated:=C2= =A0
we want to make the documents comprehensible on the first read.=C2= =A0


My intuition is that HPACK could largely = be described by the following text, although details may be a bit off as I = haven=E2=80=99t digged into all the details:

HPACK represents HTTP hea= ders in a compact form. Every valid name string and value string can be sto= red as a HPACK field. A valid name or value string conforms to HTTP 1.1 str= ings without space, =E2=80=98:=E2=80=99 and CRLF delimited. A name may also= be a pseudo-name starting with =E2=80=98:=E2=80=99 for example =E2=80=98:m= ethod=E2=80=99 used in HTTP/2.

The fields are conceptually ordered sim= ilar to how the text representation is ordered in HTTP 1.1 such that a simi= lar header can be recreated after decoding. The result of decoding a HPACK = stream is exactly such a list, and updated internal state which makes the n= ext exchange smaller in size. This internal state is kept in the dynamic na= me table discussed below.

Some header names are used often and have a = dedicated encoding in a static table. Some names are less general but may s= till be reused across requests, such names can be stored in a dynamic table= for reuse. And finally some names should not compressed for security reaso= ns or because it is not deemed efficient. The sender (encoder) decides whic= h form to use, but can only choose the static form if the name is in the st= atic table. Names are always case insensitive.

The header values are a= lways just explicit strings that are not compressed (or are they? - did not= get that far in the text). We refer to such a string as ValueString.

= For security reasons and implementation simplicity, the format is simple an= d not extensible. Instead HPACK as a whole may be replaced by another compr= ession if needed. HPACK depends on the sender (encoder) sending all operati= ons in a specific order such that the decoder can reverse the encoding unam= biguously.

In the following the three forms of name encoding are discu= ssed further, followed by how the entire list is encoded.

The static t= able is list of known names that is a assigned an index between 1 and K, wh= ere K is the length of the static table. Each name is represented as an int= eger index into this table. We call this value StaticName.

The followi= ng may not be exactly correct, but this is how I imagine it work from a qui= ck skim.

The dynamic table has a fixed size which is negotiated. The s= ize may change, but always in a way that both sender and receiver is aware = of it and only in a way the receiver permits. If the sender grows the table= beyond the granted limit, this is a fatal error. The current size of the d= ynamic table is N. The table may not use all entries. If a name is stored i= n the table it is represented by the integer DynamicName which is in the ra= nge (1 + K =E2=80=A6 N + K). The size N may be zero in which case no names = are encoded as a dynamic name. Otherwise the table is filled up such that t= he first name is given the value N + K, the next name the value N + K - 1 u= ntil the table fills up. After that, the process starts over with the next = value again being N + K and so forth. The decoder has enough information to= maintain the table as it changes. The encoded issues commands to add names= to the table but does not explicitly evict names. The encoder can grow or = shrink the table with a single command. In either case the new size takes e= ffect once the table wraps the next time around. We refer to the dynamic ta= ble size N as the integer DynamicTableSize.

When an encoder adds a nam= e to the dynamic table, it does not send the name explicitly but via a huff= man compression scheme based on static huffman codes. The net effect is a c= ommand with a bit string containing the compressed name to be added to the = dynamic table. No index information is needed because the decoder is in syn= c. The encoder, by definition, does not need to add names to static table s= o there is no corresponding operation. We refer to the huffman encoded name= as DynamicNameString.

Finally the name can be stored explicitly witho= ut compression. There is no update command for this. We refer to an explici= t string as ExplicitName.

The encoding is a stream of commands which w= e list below, followed by a wire format representation.

PushDynamicHea= der(DynamicNameSring)

ResizeDynamicTable(DynamicTableSize)

AddImp= licitHeader(StaticName | DynamicName, ValueString)

AddExplicitHeader(E= xplicitName, ValueString)

Done()


The encoder sends a li= st of commands in a very specific order. An implementation is free to choos= e how it orders these commands, except Done() comes last and AddImplicitHea= der must only be called when there is a valid entry in the table being addr= essed.

The decoder processes these commands in order and aborts the op= eration in case of any violation. The result of the decoding process is an = order list of name/value pairs with exactly one field for each AddImplicit/= Explicit commands. In addition the decoder now potentially has a populated = dynamic table that can be reused by the next request which must be handled = strictly after the previous in order to maintain sync. If the decoder wants= to reduce or increase its dynamic table it can send this information to th= e decoder via command X (TBD). This is an async operation. The decoder cann= ot require the sender to go below a previous sent limit, but it can allow i= t to grow larger and advise it to shrink. The initial dynamic table size is= an out of band parameter similar to the huffman table and the static table= .


An example is the following HTTP1.1 header where the statu= s line with the GET method is replaced by HTTP/2 pseudo names:

=E2=80= =A6 example to follow =E2=80=A6

The dynamic table then looks like: ...=


The Huffman encoding is the list of symbols in appendix A a= long with the huffman algorithm,

The static table is the list names in= appendix B, or another set of names if agreed out of band.

The wire f= ormat of ValueString is =E2=80=A6

The wire format of =C2=A0DynamicName= is =E2=80=A6

The wire format of ExplicitString is =E2=80=A6.

The= wire format of command X header is =E2=80=A6

Appendix...


--089e08284d9015e3f2055fd529a8-- From nobody Fri Dec 8 07:03: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 5BD9A124D68 for ; Fri, 8 Dec 2017 07:03:00 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZjnsXOsG4PI for ; Fri, 8 Dec 2017 07:02:58 -0800 (PST) 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 D88E51243FE for ; Fri, 8 Dec 2017 07:02:57 -0800 (PST) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vB8F2tkp022366; Fri, 8 Dec 2017 15:02:55 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) with mapi id 14.03.0361.001; Fri, 8 Dec 2017 15:02:55 +0000 From: Lucas Pardue To: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , Dmitri Tikhonov CC: IETF QUIC WG Subject: RE: Feedback from first read of QUIC/HTTP draft 08 Thread-Topic: Feedback from first read of QUIC/HTTP draft 08 Thread-Index: AQHTcAD06w+C4FfWqUyFtJHP9T+FFaM5aUqAgAAbk4CAAAPzGw== Date: Fri, 8 Dec 2017 15:02:54 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAADF36@bgb01xud1012> References: <20171208130122.GA8878@ubuntu-dmitri> <20171208130122.GA8878@ubuntu-dmitri>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23516.007 x-tm-as-result: No--26.974700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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: Fri, 08 Dec 2017 15:03:00 -0000 Hi Mikkel, There was a recent thread on httpbis mailing list where we touched on the i= dea of HTTP header compression independent of version mapping. HPACK is qui= te a generic thing really - there's not much that is specific to HTTP/2. Your proposed text seems related to that thread, where do you see that belo= nginging? Do you think that RFC 7838 does not already explain it in an appr= opriate form? Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Mikkel Fahn=F8e J=F8rgensen= [mikkelfj@gmail.com] Sent: 08 December 2017 14:40 To: Dmitri Tikhonov Cc: IETF QUIC WG Subject: Re: Feedback from first read of QUIC/HTTP draft 08 > 8. The HPACK, to be replaced, doc is hard to parse There are three HPACK replacement proposals (neither of which is referenced by [draft-ietf-quic-http-08]): QPACK, QCRAM, and QMIN. Which one are you referring to? I=92m just referring to the fact that I=92m aware the HPACK is not the long= term solution, but this was the document I was referring to. I have not be= en looking into Q* yet. > and it doesn't sound like it is as complicated as it reads. > Hopefully a future QUIC equivalent would be a bit easier to > digest. If you offered some specific examples, I think it would be appreciated: we want to make the documents comprehensible on the first read. My intuition is that HPACK could largely be described by the following text= , although details may be a bit off as I haven=92t digged into all the deta= ils: HPACK represents HTTP headers in a compact form. Every valid name string an= d value string can be stored as a HPACK field. A valid name or value string= conforms to HTTP 1.1 strings without space, =91:=92 and CRLF delimited. A = name may also be a pseudo-name starting with =91:=92 for example =91:method= =92 used in HTTP/2. The fields are conceptually ordered similar to how the text representation = is ordered in HTTP 1.1 such that a similar header can be recreated after de= coding. The result of decoding a HPACK stream is exactly such a list, and u= pdated internal state which makes the next exchange smaller in size. This i= nternal state is kept in the dynamic name table discussed below. Some header names are used often and have a dedicated encoding in a static = table. Some names are less general but may still be reused across requests,= such names can be stored in a dynamic table for reuse. And finally some na= mes should not compressed for security reasons or because it is not deemed = efficient. The sender (encoder) decides which form to use, but can only cho= ose the static form if the name is in the static table. Names are always ca= se insensitive. The header values are always just explicit strings that are not compressed = (or are they? - did not get that far in the text). We refer to such a strin= g as ValueString. For security reasons and implementation simplicity, the format is simple an= d not extensible. Instead HPACK as a whole may be replaced by another compr= ession if needed. HPACK depends on the sender (encoder) sending all operati= ons in a specific order such that the decoder can reverse the encoding unam= biguously. In the following the three forms of name encoding are discussed further, fo= llowed by how the entire list is encoded. The static table is list of known names that is a assigned an index between= 1 and K, where K is the length of the static table. Each name is represent= ed as an integer index into this table. We call this value StaticName. The following may not be exactly correct, but this is how I imagine it work= from a quick skim. The dynamic table has a fixed size which is negotiated. The size may change= , but always in a way that both sender and receiver is aware of it and only= in a way the receiver permits. If the sender grows the table beyond the gr= anted limit, this is a fatal error. The current size of the dynamic table i= s N. The table may not use all entries. If a name is stored in the table it= is represented by the integer DynamicName which is in the range (1 + K =85= N + K). The size N may be zero in which case no names are encoded as a dyn= amic name. Otherwise the table is filled up such that the first name is giv= en the value N + K, the next name the value N + K - 1 until the table fills= up. After that, the process starts over with the next value again being N = + K and so forth. The decoder has enough information to maintain the table = as it changes. The encoded issues commands to add names to the table but do= es not explicitly evict names. The encoder can grow or shrink the table wit= h a single command. In either case the new size takes effect once the table= wraps the next time around. We refer to the dynamic table size N as the in= teger DynamicTableSize. When an encoder adds a name to the dynamic table, it does not send the name= explicitly but via a huffman compression scheme based on static huffman co= des. The net effect is a command with a bit string containing the compresse= d name to be added to the dynamic table. No index information is needed bec= ause the decoder is in sync. The encoder, by definition, does not need to a= dd names to static table so there is no corresponding operation. We refer t= o the huffman encoded name as DynamicNameString. Finally the name can be stored explicitly without compression. There is no = update command for this. We refer to an explicit string as ExplicitName. The encoding is a stream of commands which we list below, followed by a wir= e format representation. PushDynamicHeader(DynamicNameSring) ResizeDynamicTable(DynamicTableSize) AddImplicitHeader(StaticName | DynamicName, ValueString) AddExplicitHeader(ExplicitName, ValueString) Done() The encoder sends a list of commands in a very specific order. An implement= ation is free to choose how it orders these commands, except Done() comes l= ast and AddImplicitHeader must only be called when there is a valid entry i= n the table being addressed. The decoder processes these commands in order and aborts the operation in c= ase of any violation. The result of the decoding process is an order list o= f name/value pairs with exactly one field for each AddImplicit/Explicit com= mands. In addition the decoder now potentially has a populated dynamic tabl= e that can be reused by the next request which must be handled strictly aft= er the previous in order to maintain sync. If the decoder wants to reduce o= r increase its dynamic table it can send this information to the decoder vi= a command X (TBD). This is an async operation. The decoder cannot require t= he sender to go below a previous sent limit, but it can allow it to grow la= rger and advise it to shrink. The initial dynamic table size is an out of b= and parameter similar to the huffman table and the static table. An example is the following HTTP1.1 header where the status line with the G= ET method is replaced by HTTP/2 pseudo names: =85 example to follow =85 The dynamic table then looks like: ... The Huffman encoding is the list of symbols in appendix A along with the hu= ffman algorithm, The static table is the list names in appendix B, or another set of names i= f agreed out of band. The wire format of ValueString is =85 The wire format of DynamicName is =85 The wire format of ExplicitString is =85. The wire format of command X header is =85 Appendix... ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Fri Dec 8 07:39: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 9D62312704B for ; Fri, 8 Dec 2017 07:39:28 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrTl-WOdlkHD for ; Fri, 8 Dec 2017 07:39:26 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 72399127241 for ; Fri, 8 Dec 2017 07:39:23 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id 68so5534845ite.4 for ; Fri, 08 Dec 2017 07:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=XEgujVZxKRgEYAKBdH9+PVFEvlm+urjnKRCPlk5/bZk=; b=C+lKWW6SIRFBBpqT/5CqxHn1HdK1jZh5zrdjlu08tIQSdlinpZNdIJtBShAkAEDo9Q JPxcR/mU/76hniX/F1M0L+sCgSjsWhT8yCOZrLFL7uuzezBa1l9D93Dnz0ROZgQ7ph97 JmrAhXptFoahvFDvQn7uTcKnPdXCSIWQ5Ikdjtz+6JmZ91j4zVI0gNTK6bHPhHHkTCES blT51Bm9RipBpVT0mxwZym5E/mNo3bMBM1qrZETRAc4iiAlcczlBvopNgevVg2Cc1UIF Fhfcn11SQF24ANqjvQ3dJWyZZ7luw/M7CDcZiPO7wlmgs3h9Uxk7ErA4TZJlBqYXeMaE /jGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=XEgujVZxKRgEYAKBdH9+PVFEvlm+urjnKRCPlk5/bZk=; b=AUMePDqNVI40SvnTA4N0+90Vm2lmCYk7mMWNzCF8b8quguZ+7C8b0SqFkgbGUuOmjE pO7xDUmJm2ii8Fq/91/nSwYReprlzK5O5DtNz2CzZ0ZjFdSWpNOkl8DimPlPYKoFPnjv TGa2iV4IM3F4AZDndwjiXCVKX9DNbpdlMCEBB3B+3ByujJc3iFBde0/DmDqSa4SIDkOU SzN7hJ69bKfc80InaXqgjniv+LQw9njIN2wE/MjtWcxf5TmbSojSgnKQhRmHWOgUheSO Fqd2PTCfR3FTLWbZSsFGapdonn1HruzqeCyBE/0moeXGuAq9tSqHhTaeYlFt/f5XpVx2 ktXg== X-Gm-Message-State: AKGB3mKRns9aEFbUHFSMeuOokNsAbszfXPPC1/pjMecxzqdZ4puXlnPT j59h0XLmwtVzI0n+pZJG2hCp3/xbfOQWi8KYwts= X-Google-Smtp-Source: AGs4zMb1jkFKoT1apnYavsSUwkITx0t3TVyo4huAcCldvNC/UPtQRzg+WFSTrVHdBQjYu36CvInNkmj4pss+WHh4REA= X-Received: by 10.107.170.148 with SMTP id g20mr3431896ioj.175.1512747562753; Fri, 08 Dec 2017 07:39:22 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Dec 2017 10:39:21 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAADF36@bgb01xud1012> References: <20171208130122.GA8878@ubuntu-dmitri> <20171208130122.GA8878@ubuntu-dmitri> <7CF7F94CB496BF4FAB1676F375F9666A3BAADF36@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 8 Dec 2017 10:39:21 -0500 Message-ID: Subject: RE: Feedback from first read of QUIC/HTTP draft 08 To: Lucas Pardue , Dmitri Tikhonov Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1142593e1ce2b5055fd5fd34" 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, 08 Dec 2017 15:39:28 -0000 --001a1142593e1ce2b5055fd5fd34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 8 December 2017 at 16.02.56, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote= : Hi Mikkel, There was a recent thread on httpbis mailing list where we touched on the idea of HTTP header compression independent of version mapping. HPACK is quite a generic thing really - there's not much that is specific to HTTP/2. Your proposed text seems related to that thread, where do you see that belonginging? Do you think that RFC 7838 does not already explain it in an appropriate form? Hi Lucas, My original text was really on the first impressions of QUIC/HTTP and not on HPACK as such and hence the HTTP/2 reference. HPACK was just a single bullet noting that my initial impression of the HPACK text (admittedly quite late) was a fair bit more confusing than I would have expected. When asked to provide more details on why I found HPACK a bit complicated, I opted to suggest a simpler text as an example based on my overall understanding - just a quick write down. However, I cannot say if the HPACK has a good reason to be as it is without reading the document very carefully and understanding all the details. So my input should be taken from a naive first readers perspective. Those with more experience can better judge if the text can be used a guideline to simplify future packing algorithms, but as I stated in the beginning, take it for what it is. On the actual packing algorithms, I could have an opinion, but right now that is fairly low on my list of things to focus on. I=E2=80=99m sure someo= ne has thought long and hard over async complications. I can say though, is that overall ZSTD looks like a promising general purpose compression library that does support pre-registered dictionaries and now has a more liberal license than it used to have. As to QUIC/HTTP itself, I was a bit put off a bit about HTTP/2 prose. It is not necessarily bad or unwarranted, but from my perspective I didn=E2=80=99= t feel the need to dig into HTTP/2 unless there was a very specific reason such as: this is the list of permitted pseudoheaders and defined in HTTP/2 section x. And finally this wasn=E2=80=99t meant to put down the efforts placed on eit= her document. But I consider the initial uninformed impressions valuable because once you understand a problem, you can no longer see where others struggle and this is why I shared this. --001a1142593e1ce2b5055fd5fd34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 8 December 2017 a= t 16.02.56, Lucas Pardue (lucas.p= ardue@bbc.co.uk) wrote:

Hi Mikkel,

There was a recent thread on httpbis mailing list where we touched on t= he idea of HTTP header compression independent of version mapping. HPACK is= quite a generic thing really - there's not much that is specific to HT= TP/2.

Your proposed text seems related to that thread, where do you see that = belonginging? Do you think that RFC 7838 does not already explain it in an = appropriate form?


Hi Lucas,

My original text was really on the first impressions of QUIC/HTTP = and not on HPACK as such and hence the HTTP/2 reference. HPACK was just a s= ingle bullet noting that my initial impression of the HPACK text (admittedl= y quite late) was a fair bit more confusing than I would have expected. Whe= n asked to provide more details on why I found HPACK a bit complicated, I o= pted to suggest a simpler text as an example based on my overall understand= ing - just a quick write down. However, I cannot say if the HPACK has a goo= d reason to be as it is without reading the document very carefully and und= erstanding all the details. So my input should be taken from a naive first = readers perspective. Those with more experience can better judge if the tex= t can be used a guideline to simplify future packing algorithms, but as I s= tated in the beginning, take it for what it is.

On= the actual packing algorithms, I could have an opinion, but right now that= is fairly low on my list of things to focus on. I=E2=80=99m sure someone h= as thought long and hard over async complications. I can say though, is tha= t overall ZSTD looks like a promising general purpose compression library t= hat does support pre-registered dictionaries and now has a more liberal lic= ense than it used to have.

As to QUIC/HTTP itself,= I was a bit put off a bit about HTTP/2 prose. It is not necessarily bad or= unwarranted, but from my perspective I didn=E2=80=99t feel the need to dig= into HTTP/2 unless there was a very specific reason such as: this is the l= ist of permitted pseudoheaders and defined in HTTP/2 section x.
<= br>
And finally this wasn=E2=80=99t meant to put down the efforts= placed on either document. But I consider the initial uninformed impressio= ns valuable because once you understand a problem, you can no longer see wh= ere others struggle and this is why I shared this.
--001a1142593e1ce2b5055fd5fd34-- From nobody Fri Dec 8 08:20: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 6F7D1127005 for ; Fri, 8 Dec 2017 08:20:12 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-2RGSRrLNid for ; Fri, 8 Dec 2017 08:20:10 -0800 (PST) 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 EBAD3126D45 for ; Fri, 8 Dec 2017 08:20:09 -0800 (PST) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vB8GK7vn015966; Fri, 8 Dec 2017 16:20:07 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.0361.001; Fri, 8 Dec 2017 16:20:07 +0000 From: Lucas Pardue To: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , Dmitri Tikhonov CC: IETF QUIC WG Subject: RE: Feedback from first read of QUIC/HTTP draft 08 Thread-Topic: Feedback from first read of QUIC/HTTP draft 08 Thread-Index: AQHTcAD06w+C4FfWqUyFtJHP9T+FFaM5aUqAgAAbk4CAAAPzG4AADJyAgAAIrws= Date: Fri, 8 Dec 2017 16:20:06 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAADF65@bgb01xud1012> References: <20171208130122.GA8878@ubuntu-dmitri> <20171208130122.GA8878@ubuntu-dmitri> <7CF7F94CB496BF4FAB1676F375F9666A3BAADF36@bgb01xud1012>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23518.000 x-tm-as-result: No--20.717900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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: Fri, 08 Dec 2017 16:20:12 -0000 Hi Mikkel, I didn't mean to sound adversarial, rather in that httpbis thread I had rai= sed a question about extracting common semantics out of the HTTP/2 doc; you= r text seems quite aligned to that idea which I had independently. To give = a different example, HTTP server push could, IMO, benefit from be abstracte= d away from the HTTP/2 specifics in which it is defined. On that topic, I r= aised a few issues with push in HTTP/QUIC where I think some editorial chan= ges could help improve its readability. There are other changes (like uni s= treams) that needed to be shaken out before tackling improvements, so someb= ody issues remain open. (I'll get around to doing a PR soon). Fresh eyes are great for the very reason you describe. I'm sure many people= wouldn't go to the effort of writing up issues or suggesting improvents, s= o thanks for doing so. I think I agreed with most of what you wrote up. Regards Lucas Ps in my previous email I meant to say RFC 7541 (HPACK).=20 ________________________________________ From: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com] Sent: 08 December 2017 15:39 To: Lucas Pardue; Dmitri Tikhonov Cc: IETF QUIC WG Subject: RE: Feedback from first read of QUIC/HTTP draft 08 On 8 December 2017 at 16.02.56, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Hi Mikkel, There was a recent thread on httpbis mailing list where we touched on the i= dea of HTTP header compression independent of version mapping. HPACK is qui= te a generic thing really - there's not much that is specific to HTTP/2. Your proposed text seems related to that thread, where do you see that belo= nginging? Do you think that RFC 7838 does not already explain it in an appr= opriate form? Hi Lucas, My original text was really on the first impressions of QUIC/HTTP and not o= n HPACK as such and hence the HTTP/2 reference. HPACK was just a single bul= let noting that my initial impression of the HPACK text (admittedly quite l= ate) was a fair bit more confusing than I would have expected. When asked t= o provide more details on why I found HPACK a bit complicated, I opted to s= uggest a simpler text as an example based on my overall understanding - jus= t a quick write down. However, I cannot say if the HPACK has a good reason = to be as it is without reading the document very carefully and understandin= g all the details. So my input should be taken from a naive first readers p= erspective. Those with more experience can better judge if the text can be = used a guideline to simplify future packing algorithms, but as I stated in = the beginning, take it for what it is. On the actual packing algorithms, I could have an opinion, but right now th= at is fairly low on my list of things to focus on. I=92m sure someone has t= hought long and hard over async complications. I can say though, is that ov= erall ZSTD looks like a promising general purpose compression library that = does support pre-registered dictionaries and now has a more liberal license= than it used to have. As to QUIC/HTTP itself, I was a bit put off a bit about HTTP/2 prose. It is= not necessarily bad or unwarranted, but from my perspective I didn=92t fee= l the need to dig into HTTP/2 unless there was a very specific reason such = as: this is the list of permitted pseudoheaders and defined in HTTP/2 secti= on x. And finally this wasn=92t meant to put down the efforts placed on either do= cument. But I consider the initial uninformed impressions valuable because = once you understand a problem, you can no longer see where others struggle = and this is why I shared this. From nobody Fri Dec 8 15:15: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 8FC6E12025C for ; Fri, 8 Dec 2017 15:15:08 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7m5NP73VqXJ for ; Fri, 8 Dec 2017 15:15:06 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 CD319120227 for ; Fri, 8 Dec 2017 15:15:05 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id d14so4004620ioc.5 for ; Fri, 08 Dec 2017 15:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=mzrvomXquRfBzSdZixYZ6CUHlpYkFVEAv7uy4/VkmUQ=; b=a3b/h5C2klyivcQjvL/WQxr0tu2AMub83YKkN4INTZZiikrrMa7PDgsi1dgZj4a5K1 iqpLGncwMul8f9g2+voC4WxZ7A2cnolVcFvv1O3W7uhjS7nfWjES/xLwI/L3MubB4Cas F7b/VNCGnNlLfE8r77QBwSrc7GUqvvwiijACtVjsVOGnJnRYZy46M+gHiJulyKTn2OYL QHwol5R9TF3ZUi48Dc78/5R4SE9IBhcy1H8IlJq4VLRgtQIiHX+reMnxJlH0sbcu50Dw srI+sgw9wSjSbRlhYK9A2MPMOSFPeL8UOTPQkwgpLScWI6GKxZCnpFrKpwM5M0fU/lxS g1nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=mzrvomXquRfBzSdZixYZ6CUHlpYkFVEAv7uy4/VkmUQ=; b=HqqQipgaiTarvbsu3/mT/1DewFOsUf8qoGZSksFImgUMQF8C0FVmg/TEhSfTZgLrD+ eScW/fI/9uVx7s27AzJZXT1F+ngJEQNvnc4CC3PuGZG84eorZL7CGYHDCmjxfLeT0fbk lNs9roQASbJOyGMoHh9FVttn8bNHDXfqyuonib5NhaX2Q/kzNGKZCKmENN9W7kWFuKmv ZjMot8/pHHmO3EeQA4keCRhvitvSV1hUOkjMyFdfpslN3u8Peu+qZLpcnbgcwf3BjQsU eqFCw3Ui1jXfc1tTfgMUr9CBqHXjuGU0fqOccPYp3ySNGX2f0QIaXR1SvvUjYJYJoRwI Zj8A== X-Gm-Message-State: AJaThX6oHg4srYXTYsIdd/QFDdY8q0rDNmfhMY1UiwG6HEgZne7eMH6K EzbRnV3Rbeb80iNNB8Oxy0ETz9+Uo/5n409Q9p3cVA== X-Google-Smtp-Source: AGs4zMZeFn5WyGLoGIv5lHvhCUzeQ+fHDbI/cT471aLP2mNAx+MJFR2DuNfEa/gg5tL3zs7+yHMvpiGGXKsr7POpfxs= X-Received: by 10.107.3.86 with SMTP id 83mr46688341iod.297.1512774904753; Fri, 08 Dec 2017 15:15:04 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Dec 2017 18:15:01 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 8 Dec 2017 18:15:01 -0500 Message-ID: Subject: APack async header compression To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113eb83ad2b205055fdc5a2d" 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, 08 Dec 2017 23:15:08 -0000 --001a113eb83ad2b205055fdc5a2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, it turns out this async compression problem is very similar to certain async problems I have been working with related to distributed garbage collection, so I wrote up an algorithm based on exchanging bitmaps. At first it may sound a bit complex and it does require a good bitmap implementation, but it doesn=E2=80=99t have very much overhead nor any diff= icult heuristics. The main cost is a bitmap of dictionary size per active request aside from the dictionary itself so this is 100 bytes if there are 800 entries in the dynamic table. It also requires a reference count per entry on the sender side but this count only need to go up to the number of concurrent requests, so typically one byte. Beware of dragons, I just made it up, but I do have somewhat similar stuff that is actually working. The main idea is to have a free bitmap lazily synchronised between sender and receiver and prevent freeing up entries still in use. There is a level of HOL but it only delays eviction of old entries. There is only one shared dictionary. # APack An async header compression scheme. ## Problem We need to send an ordered list name/value pairs a strings from a sender to a receiver, typically, but not necessarily a HTTP header list. We call this an exhange, although it is essentially one-directional but we expect the name/value list to be used for constructing a subsequent response that we need not be concerned with here. We want to reduce the size of the exchange without significant complexity and time/space resource consumption and we must protect the receiver from abuse. Also we want to avoid optionally compression on some name/value pairs because that could compromise secrecy, for example a password field. In addition we want to have multiple exchanges and allow later exchanges to benefit from earlier exchanges to increase the compression ratio when reasonable. Multiple exchanges can happen overlapped in time. Each exchange happens over an ordered stream but seperate exhanges happen on separate uni-directional streams without any implied ordering across streams. We can have bi-directional streams too, but prefer not when not needed. The sender and the receiver has shared state across the exhanges and all exhanges, while active, has access to one or more shared bi-direcitonal control streams over which global synchronization can be achieved. However, if we only relied on shared streams we would have head of line blocking (HOL) unnecessarily introducing dependencies across exhanges. ## Solution The values are always sent explicitly as a string while the names are sent via a compression scheme that can improve across exchanges. The values may be compressed in a simplistic manner, but it carries no state. Runlength encoding and static huffman encoding is possible, but we just assume value is sent as is, because it does not affect any other part of the operation. We call this local string compression. Hence we focus on names. Names are either sent a strings in the same form as values. We call this explicit names. Explicit names may be subject to local string compression. Otherwise names are sent by reference into a dictionary that is known to both sender and receiver. We call this implicit names. We have to forms of implicit names: dynamic and static. Static names are a list of names known in advance out of band each assigned a unique index. Dynamic names a references into a dynamic dictionary that is updated by the sender and read by the receiver. When a dictionary is updated, the name is sent as an explicit string subject to local string compression. Our primary concern is now how to update the dicationary such that subsequent implicit dynamic name references will see the correct dictionary value. An exchange is roughly communicated as a list of commands where a command eithers sends a dynamic dictionary update, or name/value pair where the name is either explicit, implicit dynamic, or implicit static. When all name value pairs are sent, a final command indicates completion. If we only had one exchange at a time this would be all we needed because a dictionary could just be updated before using the value. To conserve space, some dictionary entries must be evicted. This can be explicit, or implied by a dictionary update because it is known to overtake an existing location. Abuse can be avoided by requiring that the sender reuses locations instead of indefinintely adding new entries and a limit on the number of entries can be negotiated in advance or out of band. The above is roughly the HPACK compression scheme without the gritty practical details. However, we need to handle multiple exchanges concurrently. The following will deal with an async solution. ## Asynchronous Problems We are not concerned with static names or and explicit names because these are transmitted trivially on single exchange stream. This leaves us with dynamic dictionary updates and references. We could send all updates on a shared control stream and all references on specific exhange stream. The only problem is that the reference might not have arrived yet, or it might have been replaced or evicted before the reference arrives. We could solve this problem by splitting the dictionary into multiple read only groups, sometimes called an epoch or a checkpoint such that a reference is known to belong one such. The trick is then to ensure the group survives long enough via coordination between sender and receiver. This is not necessarily a bad idea, but since it has been explored, we take a different approach. ## Asynchronous Solution When a dictionary entry is updated, this always happens on the control channel from sender to receiver. When a reference is sent on an exchange stream the sender increments a reference count locally on the dictionary entry but does not transmit it. When an exhange completes, this fact is sent on the control channel along with the exchange id and then decrements local reference counts on all entries sent through the exchange. The end of exchange message is called EOX. When the receiver sees an EOX message on the control channel it first checks a dead EOX map. If found, the dead entry is removed and no further action is taken. Otherwise receiver places the EOX message on a EOX queue that can also be accessed by EOX id. A scan will normally suffice due to the access pattern. The EOX queue entry has an empty eviction bitmap which will be discussed later. The receiver does not implicitly evict any dictionary entries and the sender does not evict any entries that do not have refcount zero. Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. If we assume the dictionary is table with 1000 entries, we can have a bitmap with 1000 entries. The sender periodically sends eviction bitmaps that may be runlength compressed. The receiver processes eviction bitmaps by finding the most recent EOX entry and merges the new eviction bitmap into it. If the queue is empty then all entries in the bitmap are evicted immediately. When the receiver evicts an entry it marks this in a commit bitmap that is initially empty. The receiver periodically sends the commit bitmap back to the sender while merging it into a free bitmap and clears the commit bitmap. The free bitmap is initially completely set but will have been partially cleared once there are commit bits. When the sender receives a commit bitmap it merges it into its freemap that also originally was complete set, but is no more. When the reciever completes an exchange on the dedicated exchange channel it looks up the exchange ID in the EOX index. If it finds any it removes the EOX entry and merges its eviction bitmap with the next older entry. If there is no older entry the bitmap is merged with the commit bitmap. If there is no matching EOX entry in the EOX queue, an entry is made in a dead EOX map. We can now see how we can allocate new dictionary entries: The receiver has free bitmap that is initially complete set. A working copy of the bitmap is saved. This is called the allocation map. It is not strictly needed, but helpful because it doesn't change when the commit bitmaps messages are used to update the free bitmap. The sender maintains a current position in the allocation bitmap which is originally at the first non-empty bit. (We assume there is one for now). The next allocation happens at the current index and the current index is advanced. The name is send on the control channel along with the index. We can avoid sending the index with a bit more coodination but for simplicity lets assume we send the index along. Eventually we reach the end of the allocation bitmap. When this happens we xor the allocation bitmap into the free bitmap to clear the consumed positions then make a new snapshot of the free bitmap and start over. If we still do not have a free loation, then we have no free location and we proceed with sending explicit names on each exhchange separately. We can avoid sending the index with each name update if we carefully coordinate when the allocation bitmap is snapshot. But it might not be worth the complexity. By snapshotting the free bitmap into the allocation bitmap we ensure that that we evict older entries first but when we send the index with each name update we could also choose any arbitrary set bit in the free bitmap directly and clear that bit. --001a113eb83ad2b205055fdc5a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
OK, it turns out this async compression probl= em is very similar to certain async problems I have been working with relat= ed to distributed garbage collection, so I wrote up an algorithm based on e= xchanging bitmaps. At first it may sound a bit complex and it does require = a good bitmap implementation, but it doesn=E2=80=99t have very much overhea= d nor any difficult heuristics. The main cost is a bitmap of dictionary siz= e per active request aside from the dictionary itself so this is 100 bytes = if there are 800 entries in the dynamic table. It also requires a reference= count per entry on the sender side but this count only need to go up to th= e number of concurrent requests, so typically one byte. Beware of dragons, = I just made it up, but I do have somewhat similar stuff that is actually wo= rking.

The main idea is to have a f= ree bitmap lazily synchronised between sender and receiver and prevent free= ing up entries still in use. There is a level of HOL but it only delays evi= ction of old entries. There is only one shared dictionary.


# APack

An async header compression scheme.

## Problem

We need to send an ordered list name/value pairs a strings from a = sender
to a receiver= , typically, but not necessarily a HTTP header list. We
call this an exhange, although it is es= sentially one-directional but we
expect the name/value list to be used for constructing a subse= quent
response that = we need not be concerned with here.

We want to reduce the size of the exchange without significant
complexity and time/space resou= rce consumption and we must protect the
receiver from abuse.

Also we want to avoid optionally compression on some name/value pairs=
because that could = compromise secrecy, for example a password field.

In addition we want to have multiple exchanges and allow la= ter exchanges
to ben= efit from earlier exchanges to increase the compression ratio when
reasonable.

Multiple exchanges can happen overlapped in time. E= ach exchange happens
over an ordered stream but seperate exhanges happen on separate
uni-directional streams withou= t any implied ordering across streams. We
can have bi-directional streams too, but prefer not w= hen not needed.

=
The sender and the = receiver has shared state across the exhanges and all
exhanges, while active, has access to one= or more shared bi-direcitonal
control streams over which global synchronization can be achieve= d.
However, if we on= ly relied on shared streams we would have head of line
blocking (HOL) unnecessarily introducing= dependencies across exhanges.


=
## Solution

The values are always sent explicitly as a= string while the names are
sent via a compression scheme that can improve across exchanges. Th= e
values may be comp= ressed in a simplistic manner, but it carries no
state. Runlength encoding and static huffman e= ncoding is possible, but
we just assume value is sent as is, because it does not affect any oth= er
part of the opera= tion. We call this local string compression.

Hence we focus on names. Names are either sent a strings in the s= ame
form as values. = We call this explicit names. Explicit names may be
subject to local string compression. Otherwi= se names are sent
by= reference into a dictionary that is known to both sender and
receiver. We call this implicit = names. We have to forms of implicit
names: dynamic and static. Static names are a list of names= known in
advance ou= t of band each assigned a unique index. Dynamic names a
references into a dynamic dictionary th= at is updated by the sender and
read by the receiver. When a dictionary is updated, the name is= sent as
an explicit= string subject to local string compression.

Our primary concern is now how to update the dicationary such tha= t
subsequent implici= t dynamic name references will see the correct
dictionary value.

An exchange is roughly communicated as a list of commands where a=
command eithers sen= ds a dynamic dictionary update, or name/value pair
where the name is either explicit, implicit = dynamic, or implicit static.
When all name value pairs are sent, a final command indicates
completion.

If we only had one exchange at a time this woul= d be all we needed
b= ecause a dictionary could just be updated before using the value.
To conserve space, some dicti= onary entries must be evicted. This can be
explicit, or implied by a dictionary update because = it is known to
overt= ake an existing location.

Abuse can= be avoided by requiring that the sender reuses locations
instead of indefinintely adding new e= ntries and a limit on the number of
entries can be negotiated in advance or out of band.
<= div id=3D"bloop_customfont" style=3D"margin:0px">
The above is roughly the HPACK compressio= n scheme without the gritty
practical details.

However,= we need to handle multiple exchanges concurrently.

The following will deal with an async solution.


## Asynchronous Problems

We are not concerned with static names or and explicit names because<= /div>
these are transmitte= d trivially on single exchange stream.

This leaves us with dynamic dictionary updates and references.

We could send all updates on a shared contr= ol stream and all references
on specific exhange stream. The only problem is that the reference= might
not have arri= ved yet, or it might have been replaced or evicted before
the reference arrives.

We could solve this problem by splitting the di= ctionary into multiple
read only groups, sometimes called an epoch or a checkpoint such that a<= /div>
reference is known t= o belong one such. The trick is then to ensure the
group survives long enough via coordination = between sender and receiver.
This is not necessarily a bad idea, but since it has been explored= , we
take a differen= t approach.


## Asynchronous Solution

When a dictionary entry is updated, this always= happens on the control
channel from sender to receiver. When a reference is sent on an exchang= e
stream the sender = increments a reference count locally on the dictionary
entry but does not transmit it. When an = exhange completes, this fact is
sent on the control channel along with the exchange id and then=
decrements local re= ference counts on all entries sent through the
exchange. The end of exchange message is called = EOX.

When the receiver sees an EOX = message on the control channel it first
checks a dead EOX map. If found, the dead entry is remo= ved and no
further a= ction is taken. Otherwise receiver places the EOX message on a
EOX queue that can also be acces= sed by EOX id. A scan will normally
suffice due to the access pattern.=C2=A0 The EOX queue entr= y has an empty
evict= ion bitmap which will be discussed later.

The receiver does not implicitly evict any dictionary entries and th= e
sender does not ev= ict any entries that do not have refcount zero.
Refcount zero entries are only evicted when spa= ce is needed, otherwise
we loose the history needed for efficient compression.

If we assume the dictionary is table with 1000 entr= ies, we can have a
b= itmap with 1000 entries. The sender periodically sends eviction bitmaps
that may be runlength c= ompressed.

The receiver processes e= viction bitmaps by finding the most recent EOX
entry and merges the new eviction bitmap into it= . If the queue is empty
then all entries in the bitmap are evicted immediately. When the
<= div id=3D"bloop_customfont" style=3D"margin:0px">receiver evicts an entry i= t marks this in a commit bitmap that is
initially empty. The receiver periodically sends the co= mmit bitmap back
to = the sender while merging it into a free bitmap and clears the commit
<= div id=3D"bloop_customfont" style=3D"margin:0px">bitmap. The free bitmap is= initially completely set but will have been
partially cleared once there are commit bits.

When the sender receives a commit bitma= p it merges it into its freemap
that also originally was complete set, but is no more.

When the reciever completes an exchange on = the dedicated exchange
channel it looks up the exchange ID in the EOX index. If it finds any it=
removes the EOX ent= ry and merges its eviction bitmap with the next older
entry. If there is no older entry the bit= map is merged with the commit
bitmap. If there is no matching EOX entry in the EOX queue, an en= try is
made in a dea= d EOX map.

We can now see how we ca= n allocate new dictionary entries:

The receiver has free bitmap that is initially complete set. A working
copy of the bitmap is s= aved. This is called the allocation map. It is
not strictly needed, but helpful because it does= n't change when the
commit bitmaps messages are used to update the free bitmap.

The sender maintains a current position in the= allocation bitmap which
is originally at the first non-empty bit. (We assume there is one for<= /div>
now).=C2=A0 The next= allocation happens at the current index and the current
index is advanced. The name is send on= the control channel along with
the index. We can avoid sending the index with a bit more coodi= nation
but for simpl= icity lets assume we send the index along.=C2=A0 Eventually we
reach the end of the allocation = bitmap. When this happens we xor the
allocation bitmap into the free bitmap to clear the consum= ed positions
then ma= ke a new snapshot of the free bitmap and start over. If we still
do not have a free loation, th= en we have no free location and we proceed
with sending explicit names on each exhchange separa= tely.

We can avoid sending the inde= x with each name update if we carefully
coordinate when the allocation bitmap is snapshot. But = it might not be
wort= h the complexity.
By snapshotting t= he free bitmap into the allocation bitmap we ensure
that that we evict older entries first but = when we send the index with
each name update we could also choose any arbitrary set bit in the = free
bitmap directly= and clear that bit.

--001a113eb83ad2b205055fdc5a2d-- From nobody Fri Dec 8 15:54: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 B7358120227 for ; Fri, 8 Dec 2017 15:54:14 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1sQWR3SDkql for ; Fri, 8 Dec 2017 15:54:13 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 EF0311200CF for ; Fri, 8 Dec 2017 15:54:12 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id w127so4059250iow.11 for ; Fri, 08 Dec 2017 15:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=E/woFKj8lq6C4siAUgIEeqiP5/A/E5n16yDQHMWCrRY=; b=RypdM2Pjus4isIpeObWcU4UEvjv4v4mau9evDOOhaqMve61w3B1b5LmVffeKiq9VrT PiND1Z1wYLyAb+3IwUu1QohCUlK6Pr32Y+EjW1kw1ju41Mx2WEM17q3Zusmil0vv+GIw rSzkTO8GGwakN6Tg3Ujme+LBxZ++Dhugxo2533OjglxWVwwWo2UmWUrXXgQY4rvWANRC YQ7yIPVSJB/vPf9wApEllcar16zhb+51l5ciu2hT1GVbT9IVESv4v6605vQjWCccmULG omXGw6Zu/i5MsbwAqRyLnXPMV7JK5aR6BXSYHQOFXAMIs58mCgXt+BVTAHlnzfIMfv5o lTOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=E/woFKj8lq6C4siAUgIEeqiP5/A/E5n16yDQHMWCrRY=; b=hnophtzvf0kvyJGi/7+IRYTV+xvhZz6GymcFltg7+ryBHjiaspL5HVUh+3ql7wUOxj Rxpf/LOniFXNdNu2EwRmGNfNnuT/k4N1vRqDGD8UCvt+kcsvsKyHqpGnPLF9s8EbxFgb +Y4Sjixfx/kcTJb6WLJZ01xFBXSupMet2bFDpVSDgnQsfZ6QqCqkIzSZt9LWM/hGUQ6B Zj4kKKlkXhd+k7DeAXyUMDXtD0Ak4yL4PebILtu118PZppxuq0Xh7Rbf/YmN30ZSUvsB HJ8waLOU6hh8agjyLk3+RNx/xjXd6RB91jInHd50nj0cyG+RWAG6h4HaOb4xvxyQ0zr4 JnvQ== X-Gm-Message-State: AJaThX4jJuH8apeqJoDiZrgiWT8PZ+fR+7mCKKiWX7xWSQjdDqJrZVRi sYg0nflEXKZI0pMuyeHIl7vANbVZbZyW2Mgh5jE//g== X-Google-Smtp-Source: AGs4zMaCfwyAIEGRMzayIyo9ExCzjAXd1DzHuiWXj6Gng4YFzDr5Wm2CAfWpJN3d6rihliepOCyZLCkU6OCB6WiY6JI= X-Received: by 10.107.83.24 with SMTP id h24mr46698350iob.239.1512777252088; Fri, 08 Dec 2017 15:54:12 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Dec 2017 18:54:11 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 8 Dec 2017 18:54:11 -0500 Message-ID: Subject: Re: APack async header compression To: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08284d90bc32a4055fdce627" 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, 08 Dec 2017 23:54:15 -0000 --089e08284d90bc32a4055fdce627 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Minor correction: The receiver can include all entries with refcount zero because it only tracks what may be evicted, not what is evicted. Eviction happens when the sender does on actual allocation from the allocation map. What is correct though, is that we only need to scan for zero entries when we have are running short of things to allocate. Old text: Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 December 2017 at 00.15.01, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: The receiver does not implicitly evict any dictionary entries and the sender does not evict any entries that do not have refcount zero. Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. --089e08284d90bc32a4055fdce627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Minor cor= rection: The receiver can include all entries with refcount zero because it= only tracks what may be evicted, not what is evicted. Eviction happens whe= n the sender does on actual allocation from the allocation map. What is cor= rect though, is that we only need to scan for zero entries when we have are= running short of things to allocate.

Old text:
=
Refcount zero entries are= only evicted when space is needed, otherwise
we loose the history needed for efficient compres= sion.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8r= gensen


On 9 December 2017 a= t 00.15.01, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

The receiver does not implicitly evict any dictionary entries and = the
sender d= oes not evict any entries that do not have refcount zero.
Refcount zero entries are onl= y evicted when space is needed, otherwise
we loose the history needed for efficient com= pression.
--089e08284d90bc32a4055fdce627-- From nobody Sat Dec 9 01: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 60E5B120727 for ; Sat, 9 Dec 2017 01:35:01 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id harq4MqZzny8 for ; Sat, 9 Dec 2017 01:34:59 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 A5FC612421A for ; Sat, 9 Dec 2017 01:34:59 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id w127so4817545iow.11 for ; Sat, 09 Dec 2017 01:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=cKuy4O5PmgThOzRBnKaGG+qWP4g32d1GuZn24fMYB/k=; b=jmgSCJCEJJ2e23lCo31xr+zGy94ctLBP09QDHdEiW7gnlS7mMuwhYfKTupy9XN2c4H YQM8mweHpbhOGW+/Bd9d8x54/eFrrUg9iKhF2V3eKlIu1TZBqiPUT8V2JDGjeI3GKyZV WMpBOFZu7DYJzU0UdN2+cqKpba5EIqhtr5vrtdcXmNJRnOFT4Vgd1kEGLFpJqKpYjP8M AecthSaXVmfTRDBtstVMD8utI48Qt1vgDWcJZg0XQCbis3bkxKSyMmu7s0woelCRKy1s 0WcPNEG2LOqCnrIRSQkTBBcqK14tuG8Y3EY/oUsJbQ4eJ06/EZuGssv1hr1Prm7JbiUm 6Lqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=cKuy4O5PmgThOzRBnKaGG+qWP4g32d1GuZn24fMYB/k=; b=j8LjzlUBdF8zuSj/+Kr+A9Z3BYacInyNSXN9GPCQXv+Eg4JukGZBLZXn0ePrKRXnC1 wld0L+2bYvKcU2eZQju0mFUc69834e6ixL9l8TlEBHj/+JyJR2IP3BhcgSL2p8bD3Cdu DDdPheEYOXUJNHHPBZCgha9VqoeVZ0rYuX+4qkQWZJ5cj1pkd1fOwn7adC/5UEUPoey6 hOBFuhvk0Bu4BlOgRC1uXHHCX9Wvjzys2VM0In9w4DstaRS1G7UljrvvOk2IWqX14Zpz 1ItxKqXIfiNkGDBLXgiLwtwLE3KNo6j4964NRLUnqRmYQI71gZArVD05Hp6dqfIAmIUC Ysfg== X-Gm-Message-State: AKGB3mIPaDBXy6g+K9wTAFSoOow9OG7Jl7mRUjzgfKmPRbSaXVsX32TQ ahYMx5GoJphBOR//s1jjGvfet/0rXrB2MAYedY4hXg== X-Google-Smtp-Source: AGs4zMZxiB+Dpi4ae67ERA9s1nA8D1cA2DzEmjwDP1evmfD2G0K1DHdm+9g+44sI4Z/e1Oahx619oUXzMwpCGDHk3uY= X-Received: by 10.107.170.148 with SMTP id g20mr6557218ioj.175.1512812098720; Sat, 09 Dec 2017 01:34:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 9 Dec 2017 01:34:57 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 9 Dec 2017 01:34:57 -0800 Message-ID: Subject: Re: APack async header compression To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1142593ec1987a055fe50356" 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, 09 Dec 2017 09:35:01 -0000 --001a1142593ec1987a055fe50356 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot to mention that a receiver must defer decoding of dynamic name references until the EOX message has been received on the control channel, otherwise it might read stale data. It must also perform the dynamic name decoding before the next commit bitmap is send on the return control channel. This still leads to some degree of HOL, but only on low data volumes, and, the control stream could be given high priority. Note that even if there are no dynamic updates in an exchange, or if the sender chooses to send updated names as explicit names on the exchange specific stream as well, the dynamic table may still depend on earlier updates, so it is still not safe to decode until EOX has been seen. Some mitigations could be taken to reduce this dependency, but it does not appear to be worth the complexity, and possibly additional bandwidth requirements. The following is not exactly correct: "When this happens we xor the allocation bitmap into the free bitmap=E2=80= =9D what we actually do is to clear the bits in the free bitmap which are set in the allocation bitmap, which is then replaced with a new free bitmap snapshot. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 December 2017 at 00.54.11, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Minor correction: The receiver can include all entries with refcount zero because it only tracks what may be evicted, not what is evicted. Eviction happens when the sender does on actual allocation from the allocation map. What is correct though, is that we only need to scan for zero entries when we have are running short of things to allocate. Old text: Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 December 2017 at 00.15.01, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: The receiver does not implicitly evict any dictionary entries and the sender does not evict any entries that do not have refcount zero. Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. --001a1142593ec1987a055fe50356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I forgot to mention = that a receiver must defer decoding of dynamic name references until the EO= X message has been received on the control channel, otherwise it might read= stale data. It must also perform the dynamic name decoding before the next= commit bitmap is send on the return control channel. This still leads to s= ome degree of HOL, but only on low data volumes, and, the control stream co= uld be given high priority.

Note that even if there are no dynamic updates in an exchange, or if= the sender chooses to send updated names as explicit names on the exchange= specific stream as well, the dynamic table may still depend on earlier upd= ates, so it is still not safe to decode until EOX has been seen. Some mitig= ations could be taken to reduce this dependency, but it does not appear to = be worth the complexity, and possibly additional bandwidth requirements.

The following is not ex= actly correct:
=C2=A0= "When this happens we xor the allocation bitmap into the free bitmap= =E2=80=9D=C2=A0

what = we actually do is to clear the bits in the free bitmap which are set in the= allocation bitmap, which is then replaced with a new free bitmap snapshot.=

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


On 9 De= cember 2017 at 00.54.11, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:


Minor correction: The receiver can include all entries with refcount zero because it only tracks what may be evicted, not what is evicted. Eviction happens when the sender does on actual allocation from the allocation map. What is correct though, is that we only need to scan for zero entries when we have are running short of things to allocate.

Old text:
Refcount zero entries are only evicted when space is needed, otherwise
we loose the history needed for efficient compression.

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


On 9 December 2017 at 00.15.01, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

The receiver does not implicitly evict any dictionary entries and the
sender does not evict any entries that do not have refcount zero.
Refcount zero entries are only evicted when space is needed, otherwise
we loose the history needed for efficient compression.
--001a1142593ec1987a055fe50356-- From nobody Sun Dec 10 09:24: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 706B0127868 for ; Sun, 10 Dec 2017 09:24:23 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRA8RvhTN1U2 for ; Sun, 10 Dec 2017 09:24:21 -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 E4BFC128BB6 for ; Sun, 10 Dec 2017 09:24:20 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id m11so9607624iti.1 for ; Sun, 10 Dec 2017 09:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=MCa4LdC725bHbFp77O2hStD8Uyz/+8S4+1YKhDI1Aq8=; b=AxnzvYJkqB2ZntKnspbDT7V/YgqyzEE/Yq2iL/LY4HUxeOp9lSaKQxPcIfBsjFN1H2 EErMFcupqecYuxHY2MtKXqdoBMgyzyQXOG6pKKROIQkWtHWlKhDxJKRMs9sFJpcI/U3t 9AP5gJGMOyyrZQ9a85JOCfvNk9fpcNQG1d+CmF3cxxKm1GJngEC5XIgKhLWNUJAxfhMW XMBtP6OyuhhrwDWKQKRsBcZ5VrZcHQYc5hwOr1K38abCfQhx0SQcuNs5FVAadfYLA2Cu Jh/gIsvWhiqgsK4RhVG9HJJjtprMqkPS4m6IPhcq7wGRqp1pOMy3EGh+J2gQGt8yGP9h JDHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=MCa4LdC725bHbFp77O2hStD8Uyz/+8S4+1YKhDI1Aq8=; b=fw1HSNmLI21uNDV2ekVA36j5YWOUCVdTyPkviL7kKQphz2KEd+H+DVFr/CwTOrU2DK N4m+zBeLLbNtvuTGIgBR14B17mVNsg5+iKA8OFxKmTR/BhRXSaDQRDvWmD+Z1C5+/hNW j4MlsxPqHZX2HD+taho3BV3BC1e3D5hbQV+ENEWkwAB4l6lJB+IAwyvPLHxw2pPr+8Ww ElnXf958QHlqeIejkTLT424fM4/aonqRhx2aGSvALvgd6HdgfnTRwh1PRItNzRMhV66S 4GGqu6Hd55beHvvByNWjJn7pu8b+UF0+VeO1SH873Y3xutrZbHivCMm+2K3gNjnJyaiI e4Tw== X-Gm-Message-State: AKGB3mIG1TiVM5i+L7T6B6MFILh2cfC19OPiQoS7Y4E0hfjODMH9zgrn q7cFyhasdJHF0S7FI74JriobJ2Bh8tby3yTjKvw13A== X-Google-Smtp-Source: AGs4zMZRibkbFUWC3ca852LnGfpVf2C5J2uItcaPey28+tgM7T3l1txcWqEqGa02CeWHxkXqrF9UB4Tdixm1gBvRYLg= X-Received: by 10.36.103.213 with SMTP id u204mr14032515itc.91.1512926659984; Sun, 10 Dec 2017 09:24:19 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 10 Dec 2017 09:24:19 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 10 Dec 2017 09:24:19 -0800 Message-ID: Subject: Re: APack async header compression To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114ab8d823c148055fffb024" 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, 10 Dec 2017 17:24:23 -0000 --001a114ab8d823c148055fffb024 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had discussion on Slack and was requested to do a writeup on git. While doing so I realised that though bitmaps do work, they might not be the best way to go for this use case because timestamps can cover the same problem with less accuracy, and accuracy isn=E2=80=99t exactly needed when you cach= e data and don=E2=80=99t know when they might be needed next. Timestamps are often= used in distributed garbage collection algorithms. So this resulted in APACK for timestamps. It turns out to be not very different from the ideas in QMIN, but it is also not exactly the same, but we are still trying to figure this out. A very rough first write up is placed on https://github.com/dvidelabs/apack while qmin is found at https://github.com/litespeedtech/qmin/blob/master/id-qmin.txt Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 December 2017 at 10.34.57, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: I forgot to mention that a receiver must defer decoding of dynamic name references until the EOX message has been received on the control channel, otherwise it might read stale data. It must also perform the dynamic name decoding before the next commit bitmap is send on the return control channel. This still leads to some degree of HOL, but only on low data volumes, and, the control stream could be given high priority. Note that even if there are no dynamic updates in an exchange, or if the sender chooses to send updated names as explicit names on the exchange specific stream as well, the dynamic table may still depend on earlier updates, so it is still not safe to decode until EOX has been seen. Some mitigations could be taken to reduce this dependency, but it does not appear to be worth the complexity, and possibly additional bandwidth requirements. The following is not exactly correct: "When this happens we xor the allocation bitmap into the free bitmap=E2=80= =9D what we actually do is to clear the bits in the free bitmap which are set in the allocation bitmap, which is then replaced with a new free bitmap snapshot. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 December 2017 at 00.54.11, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Minor correction: The receiver can include all entries with refcount zero because it only tracks what may be evicted, not what is evicted. Eviction happens when the sender does on actual allocation from the allocation map. What is correct though, is that we only need to scan for zero entries when we have are running short of things to allocate. Old text: Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 December 2017 at 00.15.01, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: The receiver does not implicitly evict any dictionary entries and the sender does not evict any entries that do not have refcount zero. Refcount zero entries are only evicted when space is needed, otherwise we loose the history needed for efficient compression. --001a114ab8d823c148055fffb024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I had discussion on = Slack and was requested to do a writeup on git. While doing so I realised t= hat though bitmaps do work, they might not be the best way to go for this u= se case because timestamps can cover the same problem with less accuracy, a= nd accuracy isn=E2=80=99t exactly needed when you cache data and don=E2=80= =99t know when they might be needed next. Timestamps are often used in dist= ributed garbage collection algorithms.


A very rough first write up is placed on

 https://github.com/dvidelabs/apa= ck

while

qmin is found at


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


On 9 December 2017 at 10.34.57, Mikkel Fahn=C3=B8e J=C3=B8rgensen= (mikkelfj@gmail.com) wrote:

=
I forgot to mention that a receiver must defer decoding of dynamic name references until the EOX message has been received on the control channel, otherwise it might read stale data. It must also perform the dynamic name decoding before the next commit bitmap is send on the return control channel. This still leads to some degree of HOL, but only on low data volumes, and, the control stream could be given high priority.

Note that even if there are no dynamic updates in an exchange, or if the sender chooses to send updated names as explicit names on the exchange specific stream as well, the dynamic table may still depend on earlier updates, so it is still not safe to decode until EOX has been seen. Some mitigations could be taken to reduce this dependency, but it does not appear to be worth the complexity, and possibly additional bandwidth requirements.

The following is not exactly correct:

=C2=A0"When this happens we xor the allocation bitmap into the free bitmap=E2=80=9D=C2=A0

what we actually do is to clear the bits in the free bitmap which are set in the allocation bitmap, which is then replaced with a new free bitmap snapshot.

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


On 9 December 2017 at 00.54.11, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:


Minor correction: The receiver can include all entries with refcount zero because it only tracks what may be evicted, not what is evicted. Eviction happens when the sender does on actual allocation from the allocation map. What is correct though, is that we only need to scan for zero entries when we have are running short of things to allocate.

Old text:
Refcount zero entries are only evicted when space is needed, otherwise
we loose the history needed for efficient compression.

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

On 9 December 2017 at 00.15.01, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

The receiver does not implicitly evict any dictionary entries and the
sender does not evict any entries that do not have refcount zero.
Refcount zero entries are only evicted when space is needed, otherwise
we loose the history needed for efficient compression.
--001a114ab8d823c148055fffb024-- From nobody Sun Dec 10 18:18: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 71CA112711A for ; Sun, 10 Dec 2017 18:18:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVUO202Av5Tw for ; Sun, 10 Dec 2017 18:18:31 -0800 (PST) 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 E03AD126DFB for ; Sun, 10 Dec 2017 18:18:30 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id g9so34831158qth.9 for ; Sun, 10 Dec 2017 18:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=GMtaQgpmrk+VflvbFtM5SH5zfMtd1MxCi0vlYRTLXX4=; b=BCz1hTRgX6DwNjjKAx8DQhaYBXWI6A/i2kZmhSH8OFOcL1wLyzSMlmhmp+3EytQo+P Qt7sv3S647vUZQ1h1A9chz1FOfuGkc6at16YUCaBmQEwsfwTi18gdr55jQV4Hki7ZQB3 +3WTvNV0ev7+93Kb0slLblnUS0ONgPfNh9thCkxf8vqeT94HsA/K1i6/H0hqz/fOO9it sPNk/MgCNFaE47M3lVS0YKzGiwwoB13QI6LZPDAFAPhgOvwS40IoKuGDf1uwYPUm5zti 12ZwSwsDXkHzoDI/E/c8T74WcBEewhcKa9Mjtx3fXLp0S/hRQB7Xd2duLhaqUHHEdNSR qGUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=GMtaQgpmrk+VflvbFtM5SH5zfMtd1MxCi0vlYRTLXX4=; b=lxtvIOCKSJ/HecHog+9LjPPc4neCaNq9PS3t6NXuQcXBLXTkqKBE06qD9d+uFzD5r1 uLP3nPWV827UnR/wkSfolnMrxhfEa1HyCxyy7PPx8KjXeUosiz9lHVeXNvrqTy+D0evv nxamejDDl8UoCooVMrM6v6BdHfzL5PzdIWQmjw5HGBWHRvdHeIhmrlxLV/Y+4zHRUYRI YspF7FO4NzUDU3XOQ2zEbuF+IDjtkvSDZH2g9NkWtrdrnMMjCEmLRiNxvBxRUMTcDmvz JeU/HERu0sc5kYyP3rkJcX8MBN6Ze8+dr1ujE9qeix6rlv2CK2NJRrdUGMOOaduwNDr6 DoPQ== X-Gm-Message-State: AKGB3mIuOFhg/BF/njGL/cMDm+ohECd8fAENvzTwFVtD/mo59mQr9/BY pT1yDLvLMUblsorNugIHm+91qg== X-Google-Smtp-Source: ACJfBouMLp+w2W3GBzMcaodl9TggfVOfE6o/GP+3y6Fzfsi3MWi7Cj6fOoWKVlK8HL8SGMBTWfoAIg== X-Received: by 10.237.57.233 with SMTP id m96mr14313647qte.192.1512958710068; Sun, 10 Dec 2017 18:18:30 -0800 (PST) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id z17sm3247490qti.59.2017.12.10.18.18.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 18:18:29 -0800 (PST) Date: Sun, 10 Dec 2017 21:18:27 -0500 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: IETF QUIC WG Subject: Re: APack async header compression Message-ID: <20171211021826.GB27940@ubuntu-dmitri> Mail-Followup-To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , IETF QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 11 Dec 2017 02:18:32 -0000 On Sun, Dec 10, 2017 at 09:24:19AM -0800, Mikkel Fahnøe Jørgensen wrote: > qmin is found at > > https://github.com/litespeedtech/qmin/blob/master/id-qmin.txt For the record: this is the work-in-progress version of QMIN. The first draft is here: https://tools.ietf.org/html/draft-tikhonov-quic-qmin-00 - Dmitri. From nobody Sun Dec 10 19:41: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 3E8E11270AE for ; Sun, 10 Dec 2017 19:41:08 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=S3J3AEU3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SqK1AjHk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-zOPY6KhNez for ; Sun, 10 Dec 2017 19:41:05 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7439126C26 for ; Sun, 10 Dec 2017 19:41:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 180CD20BB9; Sun, 10 Dec 2017 22:41:05 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 10 Dec 2017 22:41:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=TdqB8tzaZsI15YnOZPWJ2ccQFcaBC++HnmICcsOKR/I=; b=S3J3AEU3 dCZ1H36I0yhpAo20JiINWBAbUpvzJTSmXmD8d6IitDG2xwyjUcQ/fKvjnWdDQZqs skcH5svO+98mZSI5tOlHPcDa7oCGzXqDKPz5Tbpzu2RWGDVfZj7gQxOMOaLnYPky 4GanE1mBcbNi92KodctRGnTNCHxonZ5/cNDhVrSPc481lsRqc3vM2TgVbOTr2R4z 30JnpxTmiUAdnoyTXdOPMZJsDBNNDWXsVmlCB9gaGGwCpkOc+Oh8pkyS5xf+1JuK yrUENn/K5EfQbMYv9/SONXY50Laz92OgXUicJvctYq+4qydeoCxkzLg4H5ZkSmva OPDp7cGhajHdLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=TdqB8tzaZsI15YnOZPWJ2ccQFcaBC ++HnmICcsOKR/I=; b=SqK1AjHkHU9V2i3NOV/k7XPDw0LyMjrQWArSiR4VOPVRz cbSkGi8aK3mcjoM18fXfKTomCHoYoE4u/qnqQjGTPJyVmq9G1F8ReoPTiod4RQPW I4YG+ydH8DFKu9yWLRtXbcmf8So7wqkBD4wfrezgqbaQ38WZOcvUlibQd78GPGIG 81zVd9b+8T5y4qP5lBrHgYABibAPfdUZbtT2s9KN4RaDsC7tswoTsT9TW2xdBP9A NltfDHNd4X7yu0EO1l7EKLtROAwOyJegNEr3RgkwBuyntQq8PqO/IgkMhsVVcL4l 7xFC2xZeTKnSA3KXWO9qGOmwd5aS7NxhNWuKhxP4Q== X-ME-Sender: Received: from [192.168.1.18] (cpe-144-136-175-28.sa.bigpond.net.au [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E3DF240F8; Sun, 10 Dec 2017 22:41:03 -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 11.1 \(3445.4.7\)) Subject: DRAFT agenda for Melbourne Message-Id: <439D2CE2-CB1E-4DEC-93BD-1545F5E40479@mnot.net> Date: Mon, 11 Dec 2017 14:41:00 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.4.7) 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, 11 Dec 2017 03:41:08 -0000 We've started an agenda for the next interim: = https://datatracker.ietf.org/meeting/interim-2018-quic-01/materials/agenda= -interim-2018-quic-01-quic-01/ Suggestions welcome, either on-list or as pull requests: = https://github.com/quicwg/wg-materials/blob/master/interim-18-01/agenda.md= Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Dec 11 00:09: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 10E3C126BF0 for ; Mon, 11 Dec 2017 00:09:25 -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, 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 I8MzlyvwPvX8 for ; Mon, 11 Dec 2017 00:09:23 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B4F1205D3 for ; Mon, 11 Dec 2017 00:09:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,391,1508828400"; d="asc'?scan'208";a="231388753" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 11 Dec 2017 00:09:23 -0800 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Dec 2017 00:09:23 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 11 Dec 2017 00:09:23 -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=kF91Bgd+BMwk5/gLcRALJiINNVORQeUhYOPtnDwDDCg=; b=XA8OtPMNA4n7ACniGxOtaTnoqez7qeu65KpN5NyqECbM5gcnUTFHz/7jYSK/YQaHuODdOU1XBKGrptd/Q07iCsg7Gn+03Mp7FTH6ddhBWPuC1LAkmH06Qqu9FIdtXqoWc56tf7vynbWFt/Ft4WnEIKUwA2VfPS5IcXMOweo2U9o= Received: from BY2PR06MB1765.namprd06.prod.outlook.com (10.163.33.19) by BY2PR06MB1767.namprd06.prod.outlook.com (10.163.33.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Mon, 11 Dec 2017 08:09:21 +0000 Received: from BY2PR06MB1765.namprd06.prod.outlook.com ([10.163.33.19]) by BY2PR06MB1765.namprd06.prod.outlook.com ([10.163.33.19]) with mapi id 15.20.0302.013; Mon, 11 Dec 2017 08:09:21 +0000 From: "Eggert, Lars" To: QUIC WG Subject: QUIC paper at ACM IMC Thread-Topic: QUIC paper at ACM IMC Thread-Index: AQHTcldZGfgs1F+6/k+91UXog3NY7w== Date: Mon, 11 Dec 2017 08:09:20 +0000 Message-ID: <9F467123-CC23-4BB1-B784-0DB7B72ECBD7@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR06MB1767; 6:Y2b+D+N4WnstOqQ9cL00Qg0y+MVodFZQd5mrUFquFcTiR7xX4cmKdqPTTAAA7pocWugMtbkGc+MGHkgk6Jh1nMPcQK3Fr1fBwyTNxl57bYQuSN1LA/6cFZLP3RBjut6Db8v1ir3oTO+89ApksD4P/WR+io/3scemfrJJFmQXw32fmOb+b78UI5B2WSgoZdTP/viwu3Agf/SQzVb0RbUBQQWrqdMgqB0/gTnx23K+viHQUziZBd8uRiy1rbg8UVIS8Czo7un3fQvUNK+vOpFEoKaDA0klpJ1JKpYbEAFm5Hho3THt84i3jIrT9J7ft0jh7Yo7JTXBw8ZXod9foHIlKTKGv1zvTThdoBwPGM2ghUI=; 5:QLp4cHGh+kdR83Z5Hwf9fDWsXXJQ1BXbppbzOtwWl4+eiyOMeCzBLEDWqNEM2Q/4yRt/YESJTdJyslmBoC8ZXKZ56sYSXPYDBH8tEljX/vzEJEysjfe2NjYddAymyeDcsIfe5CpOTC9aOE47LA4KdkfHTju3xarncIODz/olLKA=; 24:OTmvcstdBbWpIW4HGjZpi7H0xkkCCil71lGeMn2oxiG7NfBqBpSbFuF84861/eiERkkfx+IuhI4fD0JiTHnC1XPLU5F4MTTs2jTus6ypsNE=; 7:0FupNK6LzYI6botczRYYeJwAY9rwQdqoNTB4cvWHZZMOhabcpzW0y+DBQE2vm23eQ6wvHJzdxD4D1D9RI5IuDVC/IwCahePPT6wrm8/KpXun8Hd8lUHcFbPbS53nqxhvgZ3tBd38SnZLC8Q+mRv0WhQUnemvoukXNtj43cu/Epi+srKfUzeuCE8/BUujc69x++5+rSRoRcsa7BZ/EBf61KNFPHikG4PUYwWDFlcuE+nHSbqqVulCtsP4RVwApWzM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5adf7669-5179-43e7-7021-08d5406e7bc7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(49563074); SRVR:BY2PR06MB1767; x-ms-traffictypediagnostic: BY2PR06MB1767: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:BY2PR06MB1767; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR06MB1767; x-forefront-prvs: 0518EEFB48 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(189003)(199004)(5660300001)(14454004)(8936002)(25786009)(99286004)(6916009)(2900100001)(966005)(68736007)(2906002)(99936001)(53936002)(3846002)(102836003)(6116002)(3660700001)(305945005)(478600001)(105586002)(83716003)(106356001)(82746002)(86362001)(7736002)(36756003)(6306002)(6436002)(3280700002)(33656002)(57306001)(6506006)(8676002)(316002)(81156014)(81166006)(97736004)(50226002)(77096006)(6486002)(6512007)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB1767; H:BY2PR06MB1765.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_6A992105-AB61-4B4A-8363-866E506051DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5adf7669-5179-43e7-7021-08d5406e7bc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2017 08:09:20.9572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB1767 X-OriginatorOrg: netapp.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: Mon, 11 Dec 2017 08:09:25 -0000 --Apple-Mail=_6A992105-AB61-4B4A-8363-866E506051DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, in case folks hadn't seen it, there was a QUIC paper presented at this = year's ACM IMC conference: Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of = Rapidly Evolving Transport Protocols. Arash Molavi Kakhki (Northeastern = University), Samuel Jero (Purdue University), David Choffnes, Alan = Mislove, and Cristina Nita-Rotaru (Northeastern University) Go to https://conferences.sigcomm.org/imc/2017/program/ and search for = "QUIC", paper and slides are online. Lars --Apple-Mail=_6A992105-AB61-4B4A-8363-866E506051DD 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlouPS8ACgkQVLXDCb9w wVcvOBAAmMH49d3SY4OAGOHv4N3+fdE53PcwaAs6NtskkancN8/NQwk4fYkgXXkh cj3ANmgROHrtndTYJokiLGSN9m70VowdYl5Vuwl33GEeMdH8ufNQgNd6fYJkARyp bGKd9lghj371K3RL89e3ksLfWeIOvmjUujKN6UuAYoB0WIsQKv9o5JrVTS8yfc6D E88fj11cERMWKFYTUm8fE7epbXxc1D2LubUHVYs9ixsoe/sinZ9FTjy0i1HnNlJi ZKnSucCLrzhjJKsdxBa7KHR81IawGEruhx/2FsCmy6mgc7Gz+XtVT9R62vanLofn 7LUd10GwdyUW6uE0fzFu0dP7fwYbyQg15dyTCzUKKjsddC2MS/3u4E/yqouY0VtD emR1ZGzjGcR4IvKVE2FJSqqKwG/Stvu3mmfiuEvFZvB8anwUsiNO6cH6n0qXxuUF fetoi2NwACx5pBEtuDpBS1LFG6GvE6ZctOHw9XNH5PEEoGEH21sQ2e2xsTCvvRF6 Xs1oFcvWADIKm93+Ma7L8DG8fWCV3WS7DcfyuEUSDTmeUXG8sVdBQqWZ+y2ZjVyh vVtpf9fT0yWGX12SfcCHC6rnlgxQXyS48Ab9MpAGF6NkfXuEmNcxwkbWfoL2tw64 W8HCHV8HlDQrTnFqjIQhPsBzd0pyM1nAdonAUsr+Z7NsGSIoYpU= =5LkO -----END PGP SIGNATURE----- --Apple-Mail=_6A992105-AB61-4B4A-8363-866E506051DD-- From nobody Mon Dec 11 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 9B191127369 for ; Mon, 11 Dec 2017 11:58:01 -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, 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 T02NTYvHXWhn for ; Mon, 11 Dec 2017 11:58:00 -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 D8DC6124D68 for ; Mon, 11 Dec 2017 11:57:59 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id z11so1745354ybm.1 for ; Mon, 11 Dec 2017 11:57:59 -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=gpiv4+C6PmhX7besRLkKFFjr5B2PKz8PHCugWO9MZtA=; b=CIL4akvudDBTn7fZps8GSR+VUqrdhJNuAofB1OGeawScXx2IR+xztVpVYMQ1adzgaE XvFMV5nZAjuAwob+2pd7H6xbRMiUtkUZWciMkZsqPS4l/RHspugn5EGS+N6G/eflL6tN tWANYcnCMb5uAOFKCS9Ky0mqUzfEEp9P5hEOZSAXQ3ml+9yopn+r+fEk04PgTPWndulW oDxApQFiIrS1mXUolyilZ3Ht/g9J1IvZWGu58nAoRnkXs3sgp+7K2CH0y8mLi5tkBYnq LxsWXFc8wC4YkGZwh58bZUMD3vIjTofNbJud2SBB7cxlD4HfvB2Jm0DNdXOtaTw25whX UPeA== 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=gpiv4+C6PmhX7besRLkKFFjr5B2PKz8PHCugWO9MZtA=; b=OWYF9/Gck4rBqjgKbdHsyep/+BeRzbNkr9TsQVt41lMY9+tFZodK+UXvq74Rgr6dxt 6OpS2MZWWezTGElqK8+Z4cDSQDiTTvTldXXNtaTuZCYxXxEnN02NSlF7K9p4PgifTU0P QVhzU81EAhHR3AMZI02GmpS8Isvw1MuV9Vvb85Xa/2lHw187DEckV9F3X9M2Hxtzmtfv CP3wMWspaBrT8U9s2QWW479TpnEphOcXTVyrissKrBRpap4ZvjNu7/FbR3eVZh92iA2B dD9X/OXE3SEYk3Ha5Ud01esMtVU1ZQCKU8TxQksFUXOrLPOhlH0pzqsy5uX7rOJn3exf GBHA== X-Gm-Message-State: AKGB3mItTUNkfRz45MrH2u2Eop09d6ac0BjDQjAKvrg7yoRNq+sk5bOA Lq8Z7B0Qve6X/vUO1OLs1nw3GmrgUlFy2+QawaHQ0Q== X-Google-Smtp-Source: ACJfBostxwybeKpiRi83KuxctXgdBY8DRrDE1QUU/Dm9NmQOhTV++MrDLsKplrPzvB4em166uE1cj38Hj57yYMF8IPY= X-Received: by 10.37.144.14 with SMTP id s14mr1172992ybl.323.1513022278549; Mon, 11 Dec 2017 11:57:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Mon, 11 Dec 2017 11:57:57 -0800 (PST) In-Reply-To: <9F467123-CC23-4BB1-B784-0DB7B72ECBD7@netapp.com> References: <9F467123-CC23-4BB1-B784-0DB7B72ECBD7@netapp.com> From: Jana Iyengar Date: Mon, 11 Dec 2017 11:57:57 -0800 Message-ID: Subject: Re: QUIC paper at ACM IMC To: "Eggert, Lars" Cc: QUIC WG Content-Type: multipart/alternative; boundary="089e082c7820742cdb056015f374" 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, 11 Dec 2017 19:58:02 -0000 --089e082c7820742cdb056015f374 Content-Type: text/plain; charset="UTF-8" Yup, thanks for sharing -- I've read earlier versions of this paper. The results mostly agree with what we've seen and published with GQUIC performance IIRC, but it's a good piece of reproducible work (as against our work which was basically numbers out of Google). It's a good read. On Mon, Dec 11, 2017 at 12:09 AM, Eggert, Lars wrote: > Hi, > > in case folks hadn't seen it, there was a QUIC paper presented at this > year's ACM IMC conference: > > Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of Rapidly > Evolving Transport Protocols. Arash Molavi Kakhki (Northeastern > University), Samuel Jero (Purdue University), David Choffnes, Alan Mislove, > and Cristina Nita-Rotaru (Northeastern University) > > Go to https://conferences.sigcomm.org/imc/2017/program/ and search for > "QUIC", paper and slides are online. > > Lars > --089e082c7820742cdb056015f374 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yup, thanks for sharing -- I've read earlier versions = of this paper. The results mostly agree with what we've seen and publis= hed with GQUIC performance IIRC, but it's a good piece of reproducible = work (as against our work which was basically numbers out of Google). It= 9;s a good read.


On Mon, Dec 11, 2017 at 12:09 AM, Eggert, Lars <lars@net= app.com> wrote:
Hi,

in case folks hadn't seen it, there was a QUIC paper presented at this = year's ACM IMC conference:

Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of Rapidly = Evolving Transport Protocols. Arash Molavi Kakhki (Northeastern University)= , Samuel Jero (Purdue University), David Choffnes, Alan Mislove, and Cristi= na Nita-Rotaru (Northeastern University)

Go to https://conferences.sigcomm.org/imc/2017= /program/ and search for "QUIC", paper and slides are online.=

Lars

--089e082c7820742cdb056015f374-- From nobody Mon Dec 11 11:59: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 53561128854 for ; Mon, 11 Dec 2017 11:59:00 -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, 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 R2CEr8XqlwRb for ; Mon, 11 Dec 2017 11:58:58 -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 617DE124D68 for ; Mon, 11 Dec 2017 11:58:58 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id 69so5003591ybc.6 for ; Mon, 11 Dec 2017 11:58:58 -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=XaZkKZH7R1o8UczrpYH6aqmDGla2frUlJPrZZF4j0v0=; b=ju+mSOeGf8uD7bt3BH/VsDbK+Cys6rF1+7bkGmiWtdWfZi+EOqE5VGPRc0Bc/XuiFi p0Qzf+blyBGNKlzArqlKbRglIt1ZfebvC96ukLtwEVU2VZGua6mTco5jeev7aT31+Fxr jcowt2t/aEkqk9ueQz2+dN/Pl57ycuJT9v8u8Sf78dzMS0TXM4LgBCZkfcIbAPYYztnW /n5CslFi8PV+GiIBv0zvhpwAXO9kCuow/gyTq0ugUsQKPzki7zpXilmuEKnOoeBCH2Np WbevrXxHVTeOCEAsPs07f3POvjrJwGzxSlJGLFq5nEN8qsW2H05jShbqWXwi4gL7ghqc ZPaA== 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=XaZkKZH7R1o8UczrpYH6aqmDGla2frUlJPrZZF4j0v0=; b=Bi7I2nxcEwSM4nVTcedgHNmzZMwp5N/99hVyoxxIj/WS1GKDYInQVC0EXAjQ7IXRlN wG+shq7HRseLdmplWh6vZG2Lww6syv6CfuQ370rnkIszwcaEDhgtH2zrAPE1EWuG8Gl6 hCkfYNYkFyxRc6C9y+3MR8qi5um9UziWII3vOSL60I8Fsi1pYX3d6gmhFflw0UA7wR1d FSl6ST8n8zREwuwSZw1kbCnw2XEu7ffRorRMJOQi51OtCe7JtvqDCzujOKKC9XfvCGhO bSrC4HdEAoaEyFTCbsvpJmLxxW4mRjhZ42clzVCFkLvWOr/SAcCW/u/DPWS7v7UwuWx3 0Vbw== X-Gm-Message-State: AKGB3mJaIb/RCc0BWblDhu/oeVVOSbi4fPHRXhiCNZJ0viuGQx7SW0u3 SPooAlmZZDyk5QiPN61Ln2aHEr+uOrD5vneKkda4Rw== X-Google-Smtp-Source: ACJfBotlmsVqjhjwrNMh0Cr8X9kJxxGri89izPRsSi9JrkzUdQu5L9FGNW6lvXydz3QaToD92P0ozgSr3dpDNCuwg/U= X-Received: by 10.129.82.79 with SMTP id g76mr1199951ywb.94.1513022337375; Mon, 11 Dec 2017 11:58:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Mon, 11 Dec 2017 11:58:56 -0800 (PST) In-Reply-To: References: <9F467123-CC23-4BB1-B784-0DB7B72ECBD7@netapp.com> From: Jana Iyengar Date: Mon, 11 Dec 2017 11:58:56 -0800 Message-ID: Subject: Re: QUIC paper at ACM IMC To: "Eggert, Lars" Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114dac02f5864c056015f691" 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, 11 Dec 2017 19:59:00 -0000 --001a114dac02f5864c056015f691 Content-Type: text/plain; charset="UTF-8" (Sorry -- didn't mean to spam everyone's inbox by sending that response out to the IETF list.) On Mon, Dec 11, 2017 at 11:57 AM, Jana Iyengar wrote: > Yup, thanks for sharing -- I've read earlier versions of this paper. The > results mostly agree with what we've seen and published with GQUIC > performance IIRC, but it's a good piece of reproducible work (as against > our work which was basically numbers out of Google). It's a good read. > > > On Mon, Dec 11, 2017 at 12:09 AM, Eggert, Lars wrote: > >> Hi, >> >> in case folks hadn't seen it, there was a QUIC paper presented at this >> year's ACM IMC conference: >> >> Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of >> Rapidly Evolving Transport Protocols. Arash Molavi Kakhki (Northeastern >> University), Samuel Jero (Purdue University), David Choffnes, Alan Mislove, >> and Cristina Nita-Rotaru (Northeastern University) >> >> Go to https://conferences.sigcomm.org/imc/2017/program/ and search for >> "QUIC", paper and slides are online. >> >> Lars >> > > --001a114dac02f5864c056015f691 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Sorry -- didn't mean to spam everyone's inbox by = sending that response out to the IETF list.)

On Mon, Dec 11, 2017 at 11:57 AM, Jana Iye= ngar <jri@google.com> wrote:
=
Yup, thanks for sharing -- I've read earlier versions = of this paper. The results mostly agree with what we've seen and publis= hed with GQUIC performance IIRC, but it's a good piece of reproducible = work (as against our work which was basically numbers out of Google). It= 9;s a good read.


On Mon, Dec 11,= 2017 at 12:09 AM, Eggert, Lars <lars@netapp.com> wrote:
Hi,

in case folks hadn't seen it, there was a QUIC paper presented at this = year's ACM IMC conference:

Taking a Long Look at QUIC: An Approach for Rigorous Evaluation of Rapidly = Evolving Transport Protocols. Arash Molavi Kakhki (Northeastern University)= , Samuel Jero (Purdue University), David Choffnes, Alan Mislove, and Cristi= na Nita-Rotaru (Northeastern University)

Go to https://conferences.sigcomm.org/imc/2017= /program/ and search for "QUIC", paper and slides are online.=

Lars


--001a114dac02f5864c056015f691-- From nobody Tue Dec 12 02:07: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 EB02D129410; Tue, 12 Dec 2017 02:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=ferlin.io Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo-Hx_h06u00; Tue, 12 Dec 2017 02:07:47 -0800 (PST) Received: from n1nlsmtp02.shr.prod.ams1.secureserver.net (n1nlsmtp02.prod.ams1.secureserver.net [188.121.43.194]) (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 984AB12940F; Tue, 12 Dec 2017 02:07:46 -0800 (PST) Received: from n1plcpnl0047.prod.ams1.secureserver.net ([46.252.205.173]) by : HOSTING RELAY : with SMTP id OhSWeusudjzE4OhSWeyqoU; Tue, 12 Dec 2017 03:06:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ferlin.io; s=default; h=Content-Type:To:Subject:Message-ID:Date:From:MIME-Version: Sender:Reply-To:Cc: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=B2hYbMlPqVeRQjXapCYh5WI99d+U1QD47BERhxLJrM4=; b=T0/C1MjaIQL4oYxJv9LgjOhvZZ EU0me1O8gmeTnrhW2JXcAcWF9DsqoBQYLNgnpIpMLjd9vfTvEfR5vRG2/nLE0KB8yeR/ZTDeQZV7c xJWXOv8Q9RN5qNtAWtcHhGsK4n0hpJsnY9XUYy2EBa+fmF8BWs/a95iPvupBhvOmH5zhUimboLmK1 LMXK6v+IAY5PjuDNFa5fBEV6pg5HnMoE9Ib4i/0wcfKvX6YozrlUEE56ZS4H9vETpk+OzndMR2jpJ WB/Kl2JSkxYtPERVRCRGbTpUH2RTyDDXHF03uVIlZiLWjzqmsTVtezdT/M+aujp4Ej6lxP7vrC/TU DOWTS7+Q==; Received: from mail-pg0-f50.google.com ([74.125.83.50]:43338) by n1plcpnl0047.prod.ams1.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eOhSW-0004fR-Gs; Tue, 12 Dec 2017 03:06:44 -0700 Received: by mail-pg0-f50.google.com with SMTP id b18so13083550pgv.10; Tue, 12 Dec 2017 02:06:44 -0800 (PST) X-Gm-Message-State: AKGB3mK9lrZrxwIpLOC9NBbHdK8IMhsRMcDsT2tfszGE7Ay1MG5gbjYR UUUpAN7Bd1wl1854l7muHbiS1K3zmf6rNpFbdtU= X-Google-Smtp-Source: ACJfBovrc2khvtD32J8OYzDz5MfbJxCtoQqe40icySNq+QxqvNe+txFLuR2tJAMXM1Uic6UmmArLthzO3f98ufo/HIw= X-Received: by 10.84.130.33 with SMTP id 30mr1757436plc.161.1513073203589; Tue, 12 Dec 2017 02:06:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.151.15 with HTTP; Tue, 12 Dec 2017 02:06:23 -0800 (PST) From: Simone Ferlin Date: Tue, 12 Dec 2017 11:06:23 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Background traffic traces To: rmcat@ietf.org, quic@ietf.org Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n1plcpnl0047.prod.ams1.secureserver.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ferlin.io X-Get-Message-Sender-Via: n1plcpnl0047.prod.ams1.secureserver.net: authenticated_id: simone@ferlin.io X-Authenticated-Sender: n1plcpnl0047.prod.ams1.secureserver.net: simone@ferlin.io X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfHgFBEBss8GS9ZeZOrVQVYdAhohsqBSRXuZbXjWNxfjsyi0w/Rk9VOWuMNQafkCfNPE1OwPTsO+ste8//jnKdu3BZxWDYHGIrO9oaNPvotrH2N/jD1fR PcgqF/RghF085cNiv2P8TTLuRWxkOEMN5vAv1wreDQrmC0Ae+SfguSSGlLMTY0WJeiM98OMJdQ9VGZDzkEH9zdZtqzBp02W//jllQf0GWlFytlglWnk8vO4m 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, 12 Dec 2017 10:07:53 -0000 Hello all, Sorry for the spam for those in both lists... Is there any remote chance that anybody in this group is working with some common traffic traces from a real capture to compare algorithms? I remember seeing this in RMCAT few months (if not years...) ago, but my search now ended in /dev/null. Any pointers to find something like that? I am trying to replace some components such as synthetic traffic traces for a (controlled) measurement setup, and this would be of great help. Thanks, Simone From nobody Tue Dec 12 04:37:37 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 B506A12943D for ; Tue, 12 Dec 2017 04:37:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for quic WG X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151308225673.20446.8468457020013556087.idtracker@ietfa.amsl.com> Date: Tue, 12 Dec 2017 04:37:36 -0800 From: IETF Secretariat Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-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, 12 Dec 2017 12:37:37 -0000 Changed milestone "Core Protocol document to IESG", set due date to November 2018 from March 2018. Changed milestone "Loss detection and Congestion Control document to IESG", set due date to November 2018 from March 2018. Changed milestone "TLS 1.3 Mapping document to IESG", set due date to November 2018 from March 2018. URL: https://datatracker.ietf.org/wg/quic/about/ From nobody Tue Dec 12 04:40: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 D8FB512943F for ; Tue, 12 Dec 2017 04:40:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 ZtMyRhXVJd-k for ; Tue, 12 Dec 2017 04:40:08 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6BE12943D for ; Tue, 12 Dec 2017 04:40:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,395,1508828400"; d="asc'?scan'208";a="232815785" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx143-out.netapp.com with ESMTP; 12 Dec 2017 04:40:07 -0800 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Dec 2017 04:40:07 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 12 Dec 2017 04:40:07 -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=rkO9Sm+cG1TmgpIJW06N2XGKV2g8YAl0csoyiv1vGxY=; b=TSnPPOzHi6Krn9G6FXnA9z562EfeN8APrl+zTaByeA7cpaa5FBgMfSjpuFoHdzQU4/r3rc/+jH8QHoDwSc0RW2jftGXg24rWSdnXYQ26ied6nBVc5fP6CgwHMVvqA3IVcPPVQ7ipaEaGo0h3XDloSq78SA+h+gkP94TD1ulLoZg= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Tue, 12 Dec 2017 12:40:05 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0302.014; Tue, 12 Dec 2017 12:40:05 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Re: Milestones changed for quic WG Thread-Topic: Milestones changed for quic WG Thread-Index: AQHTc0YN+X81jAzxjkuH0yooq8hTlKM/phwA Date: Tue, 12 Dec 2017 12:40:04 +0000 Message-ID: References: <151308225673.20446.8468457020013556087.idtracker@ietfa.amsl.com> In-Reply-To: <151308225673.20446.8468457020013556087.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [46.183.103.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 6:elGQN6wtImdd3Pg104hWhlwRlMIhbQOt4Bvo37O6nOFQin6YwnbAbO3dnj6nEmqKbq8J5b7+XUdjI48N9pa+UwOaV7oZaolGQ1SsnXquP1kTc701zfCew+FzCia0L7+dEoROKHte5eDC8/iOHEGcyK+/nZsJIZn7jjZxVu896gabtRKv4B4a+vkOSVYegAbagvgYgjlAVnkfnIpxzqTUydXRffX8KA7izk2v1gyfKMCBE3a2K9c/jjh+gicg+1lp1QYviKwU/LVZCLRipk3GipjeQe75ElZ6c5ZuH27VNXMxMfVBZ9Pb1h6hCMDY3SPqsCYxMZUnXEM8G5j9za9pLUcGotR7q9NMGh3MX0dP8zA=; 5:mYd2CrT9sRor4qktugxLgLN0Bm3uX35suEl7x2n24uSKhSMuo6zCKcaG8c8urwvLq8AsJvNmhOVq9TnZh11mZs4xKtgw2F0cOJBUD+CVpmlcFKJ+vzJV51vuatqvv3RN5ZgE1EemjLYpIpBXyguLrdFAAuUyjX1SPcx2wrzar+0=; 24:n9AEXUll9yps4jFNuhhM7pODYXHNGYeJrFFPL1xzjJrse6BZNfnYo9gYIAR9w3gBTEZ9BfAp75lsQCmsIKaTj5xaZilMmkQlboBi3HNoaLc=; 7:Wfnbmo7nrs1VSXMz2WmmkKoP+HpOVq8k8GOTZ37xAx7Yr6Z8j0RwvmYbBYgW5fLWS5Vx2kcDmpP7NHQ33z36CHlv2pJaWFyGJhRYfvVu0niMRzILEtw3MpR/WYSg3WXk06BA2lCWIKJJq2hy3ctiW8mZZPFdJCwZwWNWHYwULvdc4W2UDVzczfZqF73dE9/bef0RkRbsLGiWgUWbWWyiA1+jnD4iEG+72SbZILuJDoZL6olFbCkuA9/0OmtNrrz4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d6f04948-bb6b-4a33-073c-08d5415d7865 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(49563074); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1762; x-forefront-prvs: 051900244E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(189003)(24454002)(377424004)(199004)(2906002)(83716003)(966005)(305945005)(82746002)(4001150100001)(2950100002)(76176011)(7736002)(36756003)(6916009)(5660300001)(86362001)(2900100001)(6246003)(316002)(53546010)(99286004)(53936002)(68736007)(478600001)(97736004)(99936001)(77096006)(6486002)(6436002)(3280700002)(6506006)(6512007)(57306001)(3660700001)(25786009)(81156014)(81166006)(229853002)(8676002)(6116002)(3846002)(50226002)(8936002)(33656002)(102836003)(106356001)(105586002)(14454004)(66066001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_61F46656-B770-44E4-91BF-D962E3E97767"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d6f04948-bb6b-4a33-073c-08d5415d7865 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2017 12:40:04.8412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.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, 12 Dec 2017 12:40:13 -0000 --Apple-Mail=_61F46656-B770-44E4-91BF-D962E3E97767 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we discussed the need to push back the milestones for three of the four = base documents; I just made the change in the datatracker. Lars > On 2017-12-12, at 13:37, IETF Secretariat = wrote: >=20 > Changed milestone "Core Protocol document to IESG", set due date to = November > 2018 from March 2018. >=20 > Changed milestone "Loss detection and Congestion Control document to = IESG", > set due date to November 2018 from March 2018. >=20 > Changed milestone "TLS 1.3 Mapping document to IESG", set due date to > November 2018 from March 2018. >=20 > URL: https://datatracker.ietf.org/wg/quic/about/ >=20 --Apple-Mail=_61F46656-B770-44E4-91BF-D962E3E97767 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlovziIACgkQVLXDCb9w wVf/5w/+NTgJ91DzIXHlH3uD/5pk9VZJPQxvblr2ce2OVFIcgZVobnYPF/pmE4DJ Y7QE0224Tvp7O25LbGqumW6HtlSVsas/j5CPyjAJkUUOJAsZTDv/qjuDKUPVuqDU GXfVzC9DuREr7t+ES12yIu/WjuC7qkDWk8g8kCoodLZfUyQz1MAc4C0fpohHOFwe U5xIdwr81IwvzimyhlOilsAZBTn2RscIssyrPHwrkCUHdDUqStZGlkLAzNQgdRrW PlK0tM8uZYaCBqv+NlZJCgrK6kGj1PaIRrr9d7FSsKrUaiX0lr860DcCS+wUVBb9 x2XxTWmVOtAbKCbkuFi5/pxLSE1PfbWpT2RFZ289iwACk0ZybhFRRipY3acGsFh0 +cJfUPP0A/8soo3IYFDP1dVKwXxpR/FhOV0u1SPTt44ZplSFOOL8HeTrC9V/SnNn FFb+IwHCDMInjJ73nx4OG4KDTradK6h9qgVbGfqx6pkSN28Ip6IvaogHhAWaKfFm GlrQONBC2tlF0pOfHFmE1nHHDEQwq0GNOx8vKdhQkVFt0tRx9EjWGEShAYlnIh68 jgLNC73HXAV85uMikUMkE6pTluQflWVaMso9w4T5b/ZnnhurDOUHR07GZHcxFpDO hLlesqb0tv0V4QemL8cDkg3aQ+1peCeym83rfT0Yx4iQiyodaEA= =VcLr -----END PGP SIGNATURE----- --Apple-Mail=_61F46656-B770-44E4-91BF-D962E3E97767-- From nobody Tue Dec 12 16:22: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 567F3128656 for ; Tue, 12 Dec 2017 16:22:27 -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 (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 ujmdMp9gH9_2 for ; Tue, 12 Dec 2017 16:22:23 -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 83713126CBF for ; Tue, 12 Dec 2017 16:22:23 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id x199so238205ywg.5 for ; Tue, 12 Dec 2017 16:22:23 -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:cc; bh=91PF76TmK7dMgQi/KFgQWV2Kt0pmobXxCYL8mr3gK2U=; b=UBzecWh+Bdgm/aF+otowGb5G+kXWhE3hWlKTP5QRcGubJMLMR14bQRFXCsxJKwtBH8 AVmpzAr7mz2Eauj3SK+1Qr/6xrHEI7Nb29R7qBMBQHx/yIRnhUeO2KvvAbuHxJSs0GYi X+Mg7rtB2I1Nhro5/w0LlzL3PdWDk/c7yLYj+TzQ76CmB5jkmd4dpQ3O2q7NK9eva15m rAQyXcxgNHcq6EOo0l0xjJUiIDRNpOY7IsZppbp1kyTDpwZqUP5h9SEZX34+yOxNpKz/ /HxEdD4Y2638nj76LoxR4TqIJ7XzntY6oe+0oxvVGugwsYyv//C7m6yQZPIuAKm7oQGf XM6g== 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=91PF76TmK7dMgQi/KFgQWV2Kt0pmobXxCYL8mr3gK2U=; b=XZNJJvi81rUqKpUKNKbKu+amlgWF4B6ZeyRtjWoIHgy82RF7VHSD84wyv/ELp56saX 0U4Y+rbAfPDIcCH86z14etVc3PexjNQhU4z3EKz31NwgPkeLHzMMFrXZyvDshfhHTm3S peJWy6o410x+Z+uL/02njtiMgFfo8Oh7fPAiq+tv4HlAXU1DmkITcNU0tbDQxuU1PRWy Oxa7RinUqlWDGSB4gKqbFNAms5cebYf0HZkgWKVEcJp9xhNqRKuAaZhU6VaJoqRxsxu/ 7BzKT2Oh+gs2QpnanMGdZ1o0KMhgS0tIkQBNVlc/6iVnZdDd4RCRIsi8qN3dySGIMom6 iyDA== X-Gm-Message-State: AKGB3mISIn+yGnns1poyOx/9aXeXpex7YNoVodkpGTLnbZGuX3gXhTnU 51+15qjQJnuTANSGzLOLcMScsLP6WBtVLhtg0anQ3/X+qEo= X-Google-Smtp-Source: ACJfBos37lCCuYHLbgw2gL2jw/XP9Tx4Vdrqw1OIKneOESNHGds2N4sMD1XfsAq4dZAVyUBoj9xQBGvWzi6sXklwalU= X-Received: by 10.129.145.135 with SMTP id i129mr482841ywg.315.1513124542086; Tue, 12 Dec 2017 16:22:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.78 with HTTP; Tue, 12 Dec 2017 16:22:21 -0800 (PST) From: Jana Iyengar Date: Tue, 12 Dec 2017 16:22:21 -0800 Message-ID: Subject: A more complete connection migration To: IETF QUIC WG Cc: Eric Kinnear , Tommy Pauly Content-Type: multipart/alternative; boundary="94eb2c0941c8d5cf6205602dc27e" 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, 13 Dec 2017 00:22:27 -0000 --94eb2c0941c8d5cf6205602dc27e Content-Type: text/plain; charset="UTF-8" Hi all, Tommy Pauly, Eric Kinnear, and I worked through a design of connection migration that we have now written up in PR #1012 . This PR describes a more complete connection migration design. Among other small bits, this design includes the following: - Allow a client to probe alternate paths without having to use them for data. The PR introduces PATH_CHALLENGE and PATH_RESPONSE frames for this purpose. - Allow a client to do PMTU verification on a new path. - Ensure that a server validates client ownership of a new address. The server also uses the PATH_CHALLENGE and PATH_RESPONSE frames for this purpose. The new frames obviate the need for PING with data, so PING is now back to being what it used to be -- a frame with no data -- and PONG is gone as well. Note that this allows for a clean implementation and semantic separation. PING can be considered a "retransmittable" frame, with retransmission when not acknowledged, whereas PATH_CHALLENGE/RESPONSE are less onerous, since an implementation may choose to not retransmit (or limit retransmission attempts differently on) probing frames sent to alternate paths. Please keep discussion of the mechanism preferably on Issue #880 , and not on the PR. --94eb2c0941c8d5cf6205602dc27e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Tommy Pauly, Eric Ki= nnear, and I worked through a design of connection migration that we have n= ow written up in PR #1012. This PR describes a more complete connecti= on migration design. Among other small bits, this design includes the follo= wing:
- Allow a client to probe alternate paths without having to= use them for data. The PR introduces PATH_CHALLENGE and PATH_RESPONSE fram= es for this purpose.
- Allow a client to do PMTU verification on = a new path.
- Ensure that a server validates client ownership of = a new address. The server also uses the PATH_CHALLENGE and PATH_RESPONSE fr= ames for this purpose.

The new frames obviate the = need for PING with data, so PING is now back to being what it used to be --= a frame with no data -- and PONG is gone as well. Note that this allows fo= r a clean implementation and semantic separation. PING can be considered a = "retransmittable" frame, with retransmission when not acknowledge= d, whereas PATH_CHALLENGE/RESPONSE are less onerous, since an implementatio= n may choose to not retransmit (or limit retransmission attempts differentl= y on) probing frames sent to alternate paths.

Plea= se keep discussion of the mechanism preferably on Issue #880, and no= t on the PR.

--94eb2c0941c8d5cf6205602dc27e-- From nobody Tue Dec 12 23:44: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 A1430126C26; Tue, 12 Dec 2017 23:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 1l3JuD3Rz_0g; Tue, 12 Dec 2017 23:44:29 -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 EE74112700F; Tue, 12 Dec 2017 23:44:28 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-e7-5a30da5bb9ea Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DE.50.27591.B5AD03A5; Wed, 13 Dec 2017 08:44:27 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 13 Dec 2017 08:44:26 +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=RlSLPCiCzOaDDIfymXohr94yICIn7EHWPz7jYIjQ9xM=; b=c0PCAm0reOyQR7JAYIvLwOk5uQIoYjFYndDSn1awFCpG0peGIWgeMY8hgadRApnIEXAJZ5bzaR4fX5HyIgVB8ZtLU18NqaurSXo6vifUpBedqzDxkVWjF+xM84kKRyPa2kpqzlIDgIqD3FG6/9S9okTtWGIV0kgrn+lzD8bK0LM= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.4; Wed, 13 Dec 2017 07:44:25 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::cce3:1dd0:46c6:afb4]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::cce3:1dd0:46c6:afb4%17]) with mapi id 15.20.0323.011; Wed, 13 Dec 2017 07:44:25 +0000 From: Ingemar Johansson S To: Simone Ferlin , "rmcat@ietf.org" , "quic@ietf.org" Subject: RE: [rmcat] Background traffic traces Thread-Topic: [rmcat] Background traffic traces Thread-Index: AQHTc4Qb/XYH/AF6G02gVEYT81M86KNA3ncg Date: Wed, 13 Dec 2017 07:44:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:cMyMw/KWQWt2EGwTyHKnOAifJxBiMFj2xDMeLK03Uhp6PlmFxk2/xOpdQe+S0kkJ69AG3QO8bynh1D/TilRV7EdHrmH9qPrPGWMCHP3waLYbCfN9fTHhNz+jvrb46J3wSg5P9pNPGUjmYICpf1sP+i4xaO6JyNFxpeevZ1d6avkattEDpKdzjJiH6XfWEq3ukH7BXAm6Jdp03bmW3C9Z/kwLGneSTPhlKI1poW75NZ6H5SZZaX9+uFFnZxEfW7Q3PXwBSed9lbe5Ju08rn/4QiC7gMjYV3raOgOEqeNj0ewkpCUZuVaypsucVgDaz2BbbA6zhVlS6WSYQfF83biydYbGH7Gdd9oK9Y5TvzzCyqg=; 5:L+LGEydBfN2GckXJYH19CsJ8XtKmLJ2czRXiZ+ZtqjSPNoq02oC4+JxGy9SQ8bRp01ikPocnFo8uJmPYUC5LTwURK2feC6d81kwB+KkEl/L6Uo9em9Z+sVsEVDJj84aOojAGJkPCUn/E9FcwIV+N1zvfqbD/ZI3qIimCSo/3siA=; 24:3DFwGdA2AtpaL7pWZ07HQuFHjZShG2PoS7INPYZziIIRLIukTvqt09PUo6zQPKhbs6/4I8Xa2pEnyoRROmn8p/HaU1nYZsHYuQ6luvwBa84=; 7:S/EY3acVGhLTCLemwKm4fs1kux4HCdyXl2PHKpmpaSBsHiYb/YDSb0Zn4vZCXKEN4cSBt1zkJxUmalvRrHQTRL+A5volbZmcve7+XPEV4XLVtZf4WjNDWkcDouRYN8WdLygxSC90iuk52oYPqKmPur8pvagH2GbyGQd9shHZabHJmASWTmST06TO24f3UJX8U9GrYUtNxtHK0mT9NQxsh5hDk+WPextDIT4jO5HKKMXsMJecDPww/EcjH5yeb7Vj x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fd16c162-9c1a-4591-96e0-08d541fd5547 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:DB4PR07MB345; x-ms-traffictypediagnostic: DB4PR07MB345: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB4PR07MB345; x-forefront-prvs: 052017CAF1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(376002)(13464003)(53754006)(189003)(199004)(7736002)(86362001)(74316002)(316002)(66066001)(3846002)(33656002)(102836003)(478600001)(25786009)(8936002)(2950100002)(6116002)(68736007)(9686003)(97736004)(55016002)(7696005)(2501003)(5250100002)(6436002)(305945005)(3280700002)(81156014)(81166006)(6506007)(53546011)(8676002)(2906002)(53936002)(2201001)(76176011)(229853002)(2900100001)(106356001)(105586002)(110136005)(5660300001)(3660700001)(14454004)(6246003)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd16c162-9c1a-4591-96e0-08d541fd5547 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2017 07:44:25.5454 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42KZGbFdWjf6lkGUweFeIYueBdwWq29+YLM4 1jid2YHZY9aRm4weS5b8ZApgiuKySUnNySxLLdK3S+DKaDm7jblgHXdF06KzjA2MHdxdjJwc EgImEutPNLN1MXJxCAkcZpT4eu8dK4RzglFi3ZGnTCBVLAK9zBJvp6tAJKYxSUye8ZoRwnnI KPH3+UmwKjYBG4mVh74zgtgiAlkSKyccYQexhQX0JOYdXg8V15c407ebCcI2kni4/iAjxAZV iTmv57GA2LwCURJLbpwG6xUSCJBY+2ARK4jNKRAo8aXjI1g9o4CsxP3v98DqmQXEJW49mc8E 8Y+AxJI955khbFGJl4//sULYChJ/Lj1ig7BlJS7N7wZ7QELgILvE1PtP2SESehJbJ75lhLB9 JTZsfcMEUbSYUeLgw1VQUzUlHk34wQxxRbLEp5u9UBsyJXZMXw51hYXE+wf3mSGa5zFLNMzd A9UsI7Fo2VaoqStZJS5PPMs2gVF3FpI3ZjFyANmaEut36UOEFSWmdD9knwUOGUGJkzOfsCxg ZFnFKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZhCDm75bbCD8eVzx0OMAhyMSjy85mcNooRY E8uKK3MPMUpwMCuJ8PbEA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInznvTkjRISSE8sSc1OTS1I LYLJMnFwSjUwCly86+/wcPsawaMa6fs7Q7d5pIouPbr9xg/LG3KnH5woqX/nZnK/lOP3h7On /9hM3jA7WZLlYOKm09z5Gj/kL71yf1O4UPCgVKTEVuuLJ6aWcmubWqcI1JbtOVr+Zd7UdB/n eb/uVJ7rfmYmbX+bb/fVGQlX8t/YutsrPJXq9Vl9i7tSoXBrvxJLcUaioRZzUXEiAHjG/7gd AwAA 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, 13 Dec 2017 07:44:32 -0000 SGkgU2ltb25lIA0KDQpJIGFzc3VtZSB0aGF0IHlvdSB3aXRoIHRyYWZmaWMgdHJhY2VzLCByZWZl ciB0byBSVFAgcGFja2V0IHN0cmVhbXMgZnJvbSBhIHZpZGVvIGVuY29kZXIsIHJpZ2h0ID8uIA0K SWYgdGhhdCBpcyB0aGUgY2FzZSB0aGVuIEkgY2FuIHBvc3NpYmx5IGFycmFuZ2Ugd2l0aCBzb21l IHRyYWNlcyAodGNwZHVtcCkgZnJvbSBvdXIgbXVsdGljYW1lcmEgcGVybW9iaWxlIHBsYXRmb3Jt IGJhc2VkIG9uIFNDUmVBTSBDQywgZG8geW91IG5lZWQgYSBmaXhlZCB0YXJnZXQgYml0cmF0ZSA/ IA0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNp bW9uZSBGZXJsaW4gW21haWx0bzpzaW1vbmVAZmVybGluLmlvXQ0KPiBTZW50OiBkZW4gMTIgZGVj ZW1iZXIgMjAxNyAxMTowNg0KPiBUbzogcm1jYXRAaWV0Zi5vcmc7IHF1aWNAaWV0Zi5vcmcNCj4g U3ViamVjdDogW3JtY2F0XSBCYWNrZ3JvdW5kIHRyYWZmaWMgdHJhY2VzDQo+IA0KPiBIZWxsbyBh bGwsDQo+IA0KPiBTb3JyeSBmb3IgdGhlIHNwYW0gZm9yIHRob3NlIGluIGJvdGggbGlzdHMuLi4N Cj4gDQo+IElzIHRoZXJlIGFueSByZW1vdGUgY2hhbmNlIHRoYXQgYW55Ym9keSBpbiB0aGlzIGdy b3VwIGlzIHdvcmtpbmcgd2l0aCBzb21lDQo+IGNvbW1vbiB0cmFmZmljIHRyYWNlcyBmcm9tIGEg cmVhbCBjYXB0dXJlIHRvIGNvbXBhcmUgYWxnb3JpdGhtcz8NCj4gSSByZW1lbWJlciBzZWVpbmcg dGhpcyBpbiBSTUNBVCAgZmV3IG1vbnRocyAoaWYgbm90IHllYXJzLi4uKSBhZ28sIGJ1dCBteQ0K PiBzZWFyY2ggbm93IGVuZGVkIGluIC9kZXYvbnVsbC4NCj4gDQo+IEFueSBwb2ludGVycyB0byBm aW5kIHNvbWV0aGluZyBsaWtlIHRoYXQ/DQo+IEkgYW0gdHJ5aW5nIHRvIHJlcGxhY2Ugc29tZSBj b21wb25lbnRzIHN1Y2ggYXMgc3ludGhldGljIHRyYWZmaWMgdHJhY2VzIGZvciBhDQo+IChjb250 cm9sbGVkKSBtZWFzdXJlbWVudCBzZXR1cCwgYW5kIHRoaXMgd291bGQgYmUgb2YgZ3JlYXQgaGVs cC4NCj4gDQo+IFRoYW5rcywNCj4gU2ltb25lDQo+IA0KDQo= From nobody Wed Dec 13 00:24: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 5B1F81275C5; Wed, 13 Dec 2017 00:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 siG4i0qs7ccW; Wed, 13 Dec 2017 00:23:59 -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 EE043120726; Wed, 13 Dec 2017 00:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=936; q=dns/txt; s=iport; t=1513153439; x=1514363039; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=nl5pJqGoAq6uF3FJ/SucEobOCkJZXH7TL29j+VWVuvY=; b=VbfmcZhn9L+7Im5uzt5HIo/bC5JicbMcwtIGP/6Z49FHYx36iB7pRvgQ kOEIo0MVi9n0U+HiIIS2vSV27+VETsZWXAcxgCAy5JSeRjSCkwEJ7htpB sKkuhS0T96EjTOi8YHpB77V4Ifeh9AkQDhUVS5Jspsr81M+gx0bKpRiXe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDS4jBa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQkdIQpixWQEJkmCh+FHAKFUBQBAQEBAQEBAQFrKIUkAQUjFVE?= =?us-ascii?q?LGAICJgICVwYBDAgBAYokEKglgieKYwEBAQEBAQEBAQEBAQEBAQEBARsFgQ+CV?= =?us-ascii?q?INhghKDAoMuhQSCYwWjGYd7jSuMEodVjRCJVoE7NiKBTjIaCBsVgmSEVUCKegE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208";a="822707" 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; 13 Dec 2017 08:23:57 +0000 Received: from [10.61.162.156] ([10.61.162.156]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBD8Nubi014212; Wed, 13 Dec 2017 08:23:56 GMT Subject: Re: [rmcat] Background traffic traces To: Simone Ferlin , rmcat@ietf.org, quic@ietf.org References: From: Sergio Mena Message-ID: <06dcf045-bece-33b8-bbdd-c17b649e46eb@cisco.com> Date: Wed, 13 Dec 2017 09:23:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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, 13 Dec 2017 08:24:01 -0000 Hello Simone, You can try the following open source repo: https://github.com/cisco/syncodecs This is a reference implementation of draft-ietf-rmcat-video-traffic-model. Besides, it contains a set of traces we obtained with Mozilla's h264 earlier this year. Let me know if you have any question. Thanks, Sergio On 12/12/17 11:06, Simone Ferlin wrote: > Hello all, > > Sorry for the spam for those in both lists... > > Is there any remote chance that anybody in this group is working with > some common traffic traces from a real capture to compare algorithms? > I remember seeing this in RMCAT few months (if not years...) ago, but > my search now ended in /dev/null. > > Any pointers to find something like that? > I am trying to replace some components such as synthetic traffic > traces for a (controlled) measurement setup, and this would be of > great help. > > Thanks, > Simone > > From nobody Wed Dec 13 00:34: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 CB0D61270A7 for ; Wed, 13 Dec 2017 00:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyi7pHzCpO2T for ; Wed, 13 Dec 2017 00:34:29 -0800 (PST) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EC2120726 for ; Wed, 13 Dec 2017 00:34:28 -0800 (PST) Received: from [10.151.161.125] (unknown [210.94.141.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: qdeconinck@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DD18E67DA0B for ; Wed, 13 Dec 2017 09:34:18 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be DD18E67DA0B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1513154059; bh=DPMppSsMBC1vo3fqxg42etyjtoNb9YGNnZwNuGI8Zqs=; h=To:From:Subject:Date; b=RqwZOZETDeCGV9RajF8y/pG19Slt7J77l4A+6hz11qliO5atu2chVfjv+MytL9RVo oCzhhIAoZ3KFitZ/B1TE/CsfHeCRXMsL/5u26cJLUYADBFUOcmyO1WJImQIW0y09RA hpovqGolHXJuVsqMiAfuALjjt9E3eTADCyvTcF+I= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-1 To: IETF QUIC WG From: Quentin De Coninck Subject: Multipath QUIC: Design and Evaluation (CoNEXT'17 paper) Message-ID: Date: Wed, 13 Dec 2017 17:34:15 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------632CCE63C12AF3A793F22212" Content-Language: en-US X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: DD18E67DA0B.A479E X-SGSI-MailScanner: Found to be clean X-SGSI-From: quentin.deconinck@uclouvain.be X-SGSI-Spam-Status: No 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, 13 Dec 2017 08:34:32 -0000 This is a multi-part message in MIME format. --------------632CCE63C12AF3A793F22212 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, As announced previously, our paper describing the design and the evaluation of Multipath extensions for QUIC has been presented at the CoNEXT'17 conference today in South Korea. The paper and the slides are available from https://inl.info.ucl.ac.be/publications/multipath-quic-design-and-evaluation To ensure the reproducibility of our results, we have released several research artefacts on http://multipath-quic.org : - source code of the implementation of Multipath QUIC built on the quic-go implementation - mininet scripts to reproduce the hundreds of experiments that are analyzed in the paper (coming with a packed-ready VM for convenience) In addition, we ported our implementation of Multipath QUIC on iOS11 and released an application which allows to test how both QUIC and Multipath QUIC work on Apple smartphones. This application includes various tests with QUIC over IPv4 and IPv6 and also tests that evaluate the bonding capabilities of Multipath QUIC. Suggestions on additional tests are more than welcome. This application can be downloaded from https://itunes.apple.com/gy/app/quictester/id1322019644?mt=8 Quentin --------------632CCE63C12AF3A793F22212 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello,

As announced previously, our paper describing the design and the evaluation of Multipath extensions for QUIC has been presented at the CoNEXT'17 conference today in South Korea. The paper and the slides are available from

https://inl.info.ucl.ac.be/publications/multipath-quic-design-and-evaluation

To ensure the reproducibility of our results, we have released several research artefacts on http://multipath-quic.org :

- source code of the implementation of Multipath QUIC built on the quic-go implementation
- mininet scripts to reproduce the hundreds of experiments that are analyzed in the paper (coming with a packed-ready VM for convenience)

In addition, we ported our implementation of Multipath QUIC on iOS11 and released an application which allows to test how both QUIC and Multipath QUIC work on Apple smartphones. This application includes various tests with QUIC over IPv4 and IPv6 and also tests that evaluate the bonding capabilities of Multipath QUIC. Suggestions on additional tests are more than welcome. This application can be downloaded from

https://itunes.apple.com/gy/app/quictester/id1322019644?mt=8

Quentin

--------------632CCE63C12AF3A793F22212-- From nobody Wed Dec 13 08:09: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 9201412783A for ; Wed, 13 Dec 2017 08:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 L12uPZHIFAIS for ; Wed, 13 Dec 2017 08:09:07 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA671126C0F for ; Wed, 13 Dec 2017 08:09:06 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4AEC1205E4 for ; Wed, 13 Dec 2017 17:09:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 2EE371A007B for ; Wed, 13 Dec 2017 17:09:05 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 13 Dec 2017 17:09:04 +0100 Message-ID: <14936_1513181345_5A3150A1_14936_390_1_5A3150A4.7010700@orange.com> Date: Wed, 13 Dec 2017 17:09:08 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Subject: Re: Re: Greasing more of QUIC References: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> In-Reply-To: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.6] 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, 13 Dec 2017 16:09:09 -0000 Hello Brian, On -10/01/-28163 20:59, Brian Trammell (IETF) wrote: > > [...] what I was hoping I'd see here, and didn't, is an explicit statement of the threat model the greasing we apply > is meant to counter. Thanks for focusing on this. I'd like to take this opportunity to chime in with a network operator's perspective on these matters. As it turns out, the generic term "middlebox", which seems to be rather loaded in this context, somehow hides another important use case for us: a passive middle observer meant for troubleshooting. While I agree that all active middleboxes may somehow wreck things in creative though unwilling ways, a passive middle observer can do no harm. But the point is that this middle observer is not only harmless, but necessary for the smooth operation of the network, which benefits the whole chain: its purpose is simply to locate, as effectively as possible, the offending link or piece of equipment, once some problem has been detected end-to-end. To do so, the most efficient method is dichotomy, which allows to home in on the problem in logN steps for a path of N segments, where each steps means (1) installing the middle observer at a chosen point on the path and (2) deciding whether the problem happens upstream or downstream from that point. Clearly step (2) assumes that the measurements done by the middle observer give the upstream/downstream information. This means that the observable of interest (RTT, loss or reordering) should be available for both upstream and downstream segments. This somehow constrains the class of methods that can be designed to support the use case. In this respect, the spin bit is satisfactory (since it gives both upstream and downstream RTT estimates), while proposed alternatives like packet number echo aren't (since they only yield end-to-end RTTs). Now, while pondering options like a random key shared by the endpoints, please keep in mind the use case of dichotomic troubleshooting, where typically none of the endpoints is under control. You may still impose stateful operation on the middle observer though. But don't just kill it. -Alex _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Dec 13 08:24: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 B774212009C for ; Wed, 13 Dec 2017 08:23:59 -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 dDkZQYsjceiD for ; Wed, 13 Dec 2017 08:23:57 -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 CD4EB1275FD for ; Wed, 13 Dec 2017 08:23:55 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0FFA1340A45 for ; Wed, 13 Dec 2017 17:23:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.14850); Wed, 13 Dec 2017 17:23:54 +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 ; Wed, 13 Dec 2017 17:23:53 +0100 (CET) Received: from [195.176.111.26] (account ietf@trammell.ch HELO public-docking-cx-0880.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 39182749 for quic@ietf.org; Wed, 13 Dec 2017 17:23:51 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_20E8D23B-F1E3-42AC-85A2-5DF07B2363C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: New Version Notification for draft-trammell-quic-spin-01.txt Message-Id: References: <151318182856.30158.12067009513682167233.idtracker@ietfa.amsl.com> To: QUIC WG Date: Wed, 13 Dec 2017 17:23:50 +0100 X-Mailer: Apple Mail (2.3273) 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, 13 Dec 2017 16:24:00 -0000 --Apple-Mail=_20E8D23B-F1E3-42AC-85A2-5DF07B2363C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted an updated version of the spin bit draft. As you can see = from the diff, the changes are extensive, including a (hopefully) = clearer description of the mechanism, an illustration of how the = mechanism works, additional use cases, and a discussion of = considerations for greasing the spin bit. We believe this version of the = document to completely answer the questions raised by the chairs with = the introduction of the process for changes to the information content = of the wire image. Please have a look at the draft, and forward any additional questions to = the authors or to the list. Thanks, cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-trammell-quic-spin-01.txt > Date: 13 December 2017 at 17:17:08 GMT+1 > To: "Emile Stephan" , "Giuseppe Fioccola" = , "Piet De Vaere" , = "Thomas Fossati" , "Piet Vaere" = , "Al Morton" , "Brian Trammell" = , "Roni Even" , "Marcus Ihlar" = , "Stephan Emile" >=20 >=20 > A new version of I-D, draft-trammell-quic-spin-01.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-trammell-quic-spin > Revision: 01 > Title: The Addition of a Spin Bit to the QUIC Transport = Protocol > Document date: 2017-12-13 > Group: Individual Submission > Pages: 22 > URL: = https://www.ietf.org/internet-drafts/draft-trammell-quic-spin-01.txt > Status: = https://datatracker.ietf.org/doc/draft-trammell-quic-spin/ > Htmlized: = https://tools.ietf.org/html/draft-trammell-quic-spin-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-trammell-quic-spin-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-quic-spin-01 >=20 > Abstract: > This document summarizes work to date on the addition of a "spin > bit", intended for explicit measurability of end-to-end RTT on QUIC > flows. It proposes a detailed mechanism for the spin bit, describes > how to use it to measure end-to-end latency, discusses corner cases > and their workarounds in the measurement, describes experimental > evaluation of the mechanism done to date, and examines the utility > and privacy implications of the spin bit. As the overhead and risk > associated with the spin bit are negligible, and the utility of a > passive RTT measurement signal at higher resolution than once per > flow is clear, this document advocates for the addition of the spin > bit to the protocol. >=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 --Apple-Mail=_20E8D23B-F1E3-42AC-85A2-5DF07B2363C7 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloxVBYACgkQihK3vwvq RqNjPQ//VkNFo41vqI/tlz+OWzjzu5GCyASlGM11Ep/0icfXFTlp30B9vIHCoo5Z gEi4qHR2+sjWFDjv+TCf4DhfJk1dyuSgJCuIetFXKHm9cN4kQJlKuoxm5q5fzp3M 7uBWNYLbiKwqAuMc3ymhkfTwLcXkww1+al3+L2+Y++KLaGD9FNyVFyvjd59kagHZ KgvCjQufLifpAHDsXmfWW9KGXSh1byb7uTf8KUUbUvFSA3UPBTZcblqbW2feD1Lx xGeT/orMDHgf6kVRVtSNgwf7BaJNMi6yBra6/RSeUrFEaoBUPqB7jo8ecliQQ0ip RJhPz1xgcGxF/M6okeZI+bLx820MLZPL5onUxLUMCLvjkBluk03cCZH7OZ34v2Ug dd99vaxcAzj/Ql7NWJOdKajBthGBeFnkF8oiKZ0OdEn1Yx9ov27P2/x0v6CC5ilK KsoCd2VjL7ZV4/Y1FDPOTZuwAUX9d1MaAu4R+duQ1nSDgIRZa22VCw2JM52Lds9v bRHUN21VsminffqmVnMY9poVLmXK2X4V33QfOV6s4tExfNc3TmA9mpeJNp7hk4DF uAj4xw6BpczKfU0zShIm8N8XRIpX+mO+AdRHboU/a2nUw2ak7M0crw0E/ydwRcOC kcSBrHoezo7jj0s8lMVwPwvqVIhPNeQq7RtKe6jtZQMyx6iJMdI= =71NO -----END PGP SIGNATURE----- --Apple-Mail=_20E8D23B-F1E3-42AC-85A2-5DF07B2363C7-- From nobody Wed Dec 13 09:15: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 D09CD1270B4 for ; Wed, 13 Dec 2017 09:15:12 -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, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK6mt0MpvJcS for ; Wed, 13 Dec 2017 09:15:11 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DD1124BAC for ; Wed, 13 Dec 2017 09:15:11 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id m11so21433183iti.1 for ; Wed, 13 Dec 2017 09:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=wqzcYzy1dea9chmEcWsiFrknXOL5a8X0M3EZ4xlXGEU=; b=uCAGqymbz381+fbaPwOnb5PZcFEKxBwt7YU89gkCTW9Rja5ZDxvevEZnCXPVJ8StNx XtRghQl5L4s5bJ+DTkw8oaMnPGCbKkWQbJPO1HHaYwz5cjQpWrKNeDNr2zbQlMn9yiE6 gXwevwUJ0skIJe04yaP5PJO1WcFTYkcVBdNBDfladiY9D1++9JtoaOhuBgYlvl3CxAjx kB/wQS/JgyL4NKArXscfy5D/td8y6WM9CKYrWSWIVzLu15MFwivqxFt/DBi/G5zB71Zk LlKjH8QRgpumio0xKr1/dgEF4g/6s4H+7H7P7knpduvd730KVdzmXnTFX+zPa+V3x3RH ma4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=wqzcYzy1dea9chmEcWsiFrknXOL5a8X0M3EZ4xlXGEU=; b=DHd18D6+CdzaDuUjTjh65Yf8Yc1Ha7SBc9P8mOO47CmSDX2vQ6CsfN+APkbf64IHz8 xigZIdzo1YGEg1n6GmoFfGmDRLYPL8nXbXozqc0URlIJ/EbfhKnAUg61Jjd0+J3MNwOV Rx/8bzjZFl6u1kMsFZeFdsUlTXZYY7+rQDHxBDFPfZbZfz9kgcT8FWJZaZxYImGd5t9f Y9ju8uQyaTMs5IjzHEH81E8b1C8r8euo4AtMf/rrKq1QYvQGW4YxVtzKlAY/QB7cYWUT BrkN1gLb1hccAJUQijdR/EcTObvV7TFV1vvb4zcRdjpskxnkqUq0aWe9cvg5XEVIvudc 8Iow== X-Gm-Message-State: AKGB3mLSsBr490VWEoScdyYKUfct5JB1/OWk2r1EPTZuAELHK7XIXiTI U7y/+hpRMTKEnFKQQAtp1HTdEO2eH9gmZaq/EY0= X-Google-Smtp-Source: ACJfBotMsV8ocCLM/I83FcF1aThzeJ3fQGEICXBjOpedAoUeIBSS/m6zSz2PVcJoU7/s2XEim26ZEEqZ8zJ/ls8vSRU= X-Received: by 10.107.47.234 with SMTP id v103mr3587471iov.96.1513185310512; Wed, 13 Dec 2017 09:15:10 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Dec 2017 12:15:09 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <14936_1513181345_5A3150A1_14936_390_1_5A3150A4.7010700@orange.com> References: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> <14936_1513181345_5A3150A1_14936_390_1_5A3150A4.7010700@orange.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 13 Dec 2017 12:15:09 -0500 Message-ID: Subject: Re: Re: Greasing more of QUIC To: alexandre.ferrieux@orange.com, quic@ietf.org Content-Type: multipart/alternative; boundary="001a1135a438e99e8b05603be87e" 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, 13 Dec 2017 17:15:13 -0000 --001a1135a438e99e8b05603be87e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A passive middle box observer can do harm if the deployment is large scale and mission critical. If it mis-interprets new QUIC version it may report network damage which may cause operators to explicitly block new QUIC versions as opposed to deal with upgrading passive, but mission critical, middleware. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 13 December 2017 at 17.09.15, alexandre.ferrieux@orange.com ( alexandre.ferrieux@orange.com) wrote: Hello Brian, On -10/01/-28163 20:59, Brian Trammell (IETF) wrote: > > [...] what I was hoping I'd see here, and didn't, is an explicit statement of the threat model the greasing we apply > is meant to counter. Thanks for focusing on this. I'd like to take this opportunity to chime in with a network operator's perspective on these matters. As it turns out, the generic term "middlebox", which seems to be rather loaded in this context, somehow hides another important use case for us: a passive middle observer meant for troubleshooting. While I agree that all active middleboxes may somehow wreck things in creative though unwilling ways, a passive middle observer can do no harm. But the point is that this middle observer is not only harmless, but necessary for the smooth operation of the network, which benefits the whole chain: its purpose is simply to locate, as effectively as possible, the offending link or piece of equipment, once some problem has been detected end-to-end. To do so, the most efficient method is dichotomy, which allows to home in on the problem in logN steps for a path of N segments, where each steps means (1) installing the middle observer at a chosen point on the path and (2) deciding whether the problem happens upstream or downstream from that point. Clearly step (2) assumes that the measurements done by the middle observer give the upstream/downstream information. This means that the observable of interest (RTT, loss or reordering) should be available for both upstream and downstream segments. This somehow constrains the class of methods that can be designed to support the use case. In this respect, the spin bit is satisfactory (since it gives both upstream and downstream RTT estimates), while proposed alternatives like packet number echo aren't (since they only yield end-to-end RTTs). Now, while pondering options like a random key shared by the endpoints, please keep in mind the use case of dichotomic troubleshooting, where typically none of the endpoints is under control. You may still impose stateful operation on the middle observer though. But don't just kill it. -Alex ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --001a1135a438e99e8b05603be87e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = A passive middle box= observer can do harm if the deployment is large scale and mission critical= . If it mis-interprets new QUIC version it may report network damage which = may cause operators to explicitly block new QUIC versions as opposed to dea= l with upgrading passive, but mission critical, middleware.
Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgen= sen


On 13 December 2017 at = 17.09.15, alexandre.ferrie= ux@orange.com (alexand= re.ferrieux@orange.com) wrote:

Hello Brian,

On -10/01/-28163 20:59, Brian Trammell (IETF) wrote:
>
> [...] what I was hoping I'd see here, and didn't, is an ex= plicit statement of the threat model the greasing we apply
> is meant to counter.

Thanks for focusing on this. I'd like to take this opportunity to c= hime in with a network operator's perspective on =20
these matters.

As it turns out, the generic term "middlebox", which seems to= be rather loaded in this context, somehow hides another =20
important use case for us: a passive middle observer meant for troubles= hooting.

While I agree that all active middleboxes may somehow wreck things in c= reative though unwilling ways, a passive middle =20
observer can do no harm. But the point is that this middle observer is = not only harmless, but necessary for the smooth =20
operation of the network, which benefits the whole chain: its purpose i= s simply to locate, as effectively as possible, =20
the offending link or piece of equipment, once some problem has been de= tected end-to-end.

To do so, the most efficient method is dichotomy, which allows to home = in on the problem in logN steps for a path of N =20
segments, where each steps means (1) installing the middle observer at = a chosen point on the path and (2) deciding =20
whether the problem happens upstream or downstream from that point.

Clearly step (2) assumes that the measurements done by the middle obser= ver give the upstream/downstream information.
This means that the observable of interest (RTT, loss or reordering) sh= ould be available for both upstream and =20
downstream segments. This somehow constrains the class of methods that = can be designed to support the use case. In this =20
respect, the spin bit is satisfactory (since it gives both upstream and= downstream RTT estimates), while proposed =20
alternatives like packet number echo aren't (since they only yield = end-to-end RTTs).

Now, while pondering options like a random key shared by the endpoints,= please keep in mind the use case of dichotomic =20
troubleshooting, where typically none of the endpoints is under control= . You may still impose stateful operation on the =20
middle observer though. But don't just kill it.

-Alex

_______________________________________________________________________= __________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci.

This message and its attachments may contain confidential or privileged= information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and = delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified.
Thank you.

--001a1135a438e99e8b05603be87e-- From nobody Wed Dec 13 10:25: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 A6425127A91 for ; Wed, 13 Dec 2017 10:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 T6x_4wIcuiMq for ; Wed, 13 Dec 2017 10:25:29 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC0612714F for ; Wed, 13 Dec 2017 10:25:28 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 03C426090D; Wed, 13 Dec 2017 19:25:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id D7F5D180055; Wed, 13 Dec 2017 19:25:26 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 13 Dec 2017 19:25:26 +0100 Message-ID: <16891_1513189526_5A317096_16891_360_1_5A31709A.8090901@orange.com> Date: Wed, 13 Dec 2017 19:25:30 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= CC: Subject: Re: Greasing more of QUIC References: <68B6C3D7-243D-4E0A-B8D1-34AE5E08468A@trammell.ch> <14936_1513181345_5A3150A1_14936_390_1_5A3150A4.7010700@orange.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.168.234.6] 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, 13 Dec 2017 18:25:31 -0000 I'm talking about middle observers which we do use every day to maintain re= al-life networks. We deploy them=20 intentionally, after being notified of issues by other means, and make huma= n decisions on their observations. No "short=20 loop" with automated, too fast reactions. My point is that this use case is an important one to support. The theoreti= cal possibility of misuse of its enablers has=20 no bearing on the cost of *not* supporting it. Which is huge. -Alex On 13/12/2017 18:15, Mikkel Fahn=F8e J=F8rgensen wrote: > A passive middle box observer can do harm if the deployment is large scal= e and mission critical. If it mis-interprets > new QUIC version it may report network damage which may cause operators t= o explicitly block new QUIC versions as opposed > to deal with upgrading passive, but mission critical, middleware. > > Kind Regards, > Mikkel Fahn=F8e J=F8rgensen > > > On 13 December 2017 at 17.09.15, alexandre.ferrieux@orange.com > (alexandre.ferrieux@orange.com ) wr= ote: > >> Hello Brian, >> >> On -10/01/-28163 20:59, Brian Trammell (IETF) wrote: >> > >> > [...] what I was hoping I'd see here, and didn't, is an explicit state= ment of the threat model the greasing we apply >> > is meant to counter. >> >> Thanks for focusing on this. I'd like to take this opportunity to chime = in with a network operator's perspective on >> these matters. >> >> As it turns out, the generic term "middlebox", which seems to be rather = loaded in this context, somehow hides another >> important use case for us: a passive middle observer meant for troublesh= ooting. >> >> While I agree that all active middleboxes may somehow wreck things in cr= eative though unwilling ways, a passive middle >> observer can do no harm. But the point is that this middle observer is n= ot only harmless, but necessary for the smooth >> operation of the network, which benefits the whole chain: its purpose is= simply to locate, as effectively as possible, >> the offending link or piece of equipment, once some problem has been det= ected end-to-end. >> >> To do so, the most efficient method is dichotomy, which allows to home i= n on the problem in logN steps for a path of N >> segments, where each steps means (1) installing the middle observer at a= chosen point on the path and (2) deciding >> whether the problem happens upstream or downstream from that point. >> >> Clearly step (2) assumes that the measurements done by the middle observ= er give the upstream/downstream information. >> This means that the observable of interest (RTT, loss or reordering) sho= uld be available for both upstream and >> downstream segments. This somehow constrains the class of methods that c= an be designed to support the use case. In this >> respect, the spin bit is satisfactory (since it gives both upstream and = downstream RTT estimates), while proposed >> alternatives like packet number echo aren't (since they only yield end-t= o-end RTTs). >> >> Now, while pondering options like a random key shared by the endpoints, = please keep in mind the use case of dichotomic >> troubleshooting, where typically none of the endpoints is under control.= You may still impose stateful operation on the >> middle observer though. But don't just kill it. >> >> -Alex ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sun Dec 17 04:35: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 BBFC6128A32 for ; Sun, 17 Dec 2017 04:35:15 -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, 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 dBbeZeoWZbU4 for ; Sun, 17 Dec 2017 04:35:14 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE28C1205F1 for ; Sun, 17 Dec 2017 04:35:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,415,1508828400"; d="asc'?scan'208";a="233640937" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx143-out.netapp.com with ESMTP; 17 Dec 2017 04:35:12 -0800 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 17 Dec 2017 04:35:13 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Sun, 17 Dec 2017 04:35:12 -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=oTvsrK8YlvP7RxWVhk2sKwTqg9/+Dj/glMeMZflCiHQ=; b=GJSQvoYLAKHc6vNWgE12oBA1/NkcvsGApeiGkriPQBynINetsrRMjPsW/eLNX2zDKL1Fwnt58NzgLihPDzxO8+nBtyc04PrV+7bmyjZSlbIoMNTbLOCAERJ1VBserGzJ6vupPs8orPto0uBEiU2Ep3PPQGaeqPTbX0r/rNlV8ks= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Sun, 17 Dec 2017 12:35:10 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0323.018; Sun, 17 Dec 2017 12:35:10 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Dec 2017 interop day Thread-Topic: Dec 2017 interop day Thread-Index: AQHTdzN6W4hU3FHsWkiF356Nh+6YWA== Date: Sun, 17 Dec 2017 12:35:10 +0000 Message-ID: <86F7C21A-4EC9-4F06-9F47-D3F988F94945@netapp.com> References: <5F30810F-C268-483C-A6BA-02D4BC86C325@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3614:8001:2c4c:3830:c3a0:c8e2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:tbyhOxyF/aldA+qeWRTGqNsc+EZRkQsJs+H3GHGaBczqNg2MAILjQGGPZeecKTQ3dQ4LWHmC7QKMk+2fBUVLZMaQYvB+Bo38cv8PyEbjILbZGZBSZ1A08+KYP9xi12BuNR+kmkDiJm+sBC+HDFZytwcCTMvdSO/IxgFxm8pdcLah3Lb93Xu3OKQHX//81top0X0gHnYavzX/YZdY/YHLQsM8cmo6mwyt+TaeO5G5nD5EArtj4Vyo6IG/FA9PXDk+fJwOC6CkgbQNPkiiBuEbUIobisyNyVr7ispAjDsLzBEpf6XfDYpddxL9DcfeyNa6pVD08fPlyDPNJ3huqPF+4Zyx84Psd5LHFeKNcDwbIBw=; 5:vtZUAhC6N+HAc+wJ9MubcBZvX/itMRD+30pWhPG6zkE4jfh4RQu3XQafzLsYdS4CEPJJkWzBWm+Efm/hgbstTp/Gz67v+1/wZPVgLpStTEwTXgoed8BeFR/0Al9zeigUCb5pyIfwHwvN1qitZM/yQiuLDOdvs83BnAji7I4z2to=; 24:+ePG3tQjbxgiBGGBwr8doad38bPrOLFY4TeCUbTGRbAn1oZGJ18/dN3DQ4p1HGYuPhQeEqGdqt5GIzuUUxyq/FFbv8aTCJJKYv7wwSTHcLE=; 7:O0sYzyHeMxr9MBxdNA4J+1voR1vy8nJM+WoevuO3UETq0nTlMFw8FFoH1xh1goPXC84SZnRUqSbNpDwDPinqG/oM9xRwm1YVlC8B5BM/3vUFGd+XgBaxEzOSKZSgrwNyZH2PfjWwMFzhlvOWfLpAgaZdUSicu9rxLUfjhjWEyiuzPMxXYFR2tposKuEFX7NwamZVH1zFWmiRSWWOflYIHhcYaiLtl4fCyibgMRyF1hYW5uk1Bmvj4P80LQYmHflj x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d369f994-b807-492b-ebe1-08d5454a9ccf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(222300048226458)(231250463719595)(119230021023882); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(920507027)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1763; x-forefront-prvs: 05245CA661 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(376002)(39850400004)(199004)(189003)(52024003)(478600001)(53936002)(25786009)(99286004)(14454004)(8676002)(33656002)(3280700002)(102836003)(6116002)(81166006)(105586002)(3660700001)(97736004)(77096006)(6486002)(2900100001)(106356001)(305945005)(81156014)(68736007)(76176011)(966005)(99936001)(6436002)(6512007)(50226002)(6306002)(7736002)(8936002)(57306001)(2950100002)(34040400001)(82746002)(86362001)(6916009)(6506007)(83716003)(59450400001)(36756003)(7116003)(316002)(410100003)(575784001)(5660300001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_E71DDB35-5617-4BD6-B0C7-130829885294"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d369f994-b807-492b-ebe1-08d5454a9ccf X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2017 12:35:10.2780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.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: Sun, 17 Dec 2017 12:35:16 -0000 --Apple-Mail=_E71DDB35-5617-4BD6-B0C7-130829885294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, the remote interop day is tomorrow. The rough idea is that people will = use https://quicdev.slack.com/ to set up interop sessions between = implementations, using any other collaboration tools (e.g., Hangouts, = Skype) as needed. Use the #general channel to coordinate interops, and then use the = respective per-implementation channels for followup (or make new = temporary channels). Keep #social chatter on that channel. Please update the interop sheet at = https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk= 0l4JtvTVg/edit?usp=3Dsharing during the day; there is a new tab for the = 3rd interop. Feel free to more concretely define what H, D, and C should = mean this time. We'll try doing a "follow the sun" model. (Which may mean that our = Japanese friends will interop with US west coast people during their - = Japanese - morning hours on Tuesday.) See you tomorrow! Lars --Apple-Mail=_E71DDB35-5617-4BD6-B0C7-130829885294 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlo2ZH0ACgkQVLXDCb9w wVdDtRAAjsZqLUaBVZgO7hXySYwb2RM7BWviJI2FsanHJx54TvPHdbhp5FpK2ISC xjIEIPf8BTr42GX6/7Uuavj9bMxd2U6aVatEDQwsB8089ISgAr+iXYNcWynigVkJ ck5tVtqYMv5Z17YA0z8GA8+lHLnnxmQL7Gp0l0566+yul+OMsrLlfnGr1NnJb6T3 h3TQAtd7m4djz8pi0/A5Biu6ImXln0kJScLckGFYicLJge8/h7CcQgD5J8Y3gf25 0H+hwHOTWV9gS3bkN2ciB75FdZ38MWfW6hgh3L7Pxta9AZV5dA6kUpXXNiUFgzKh bHREZ+DKmOSsjEK/BGv9IbOUQzWKdNU7+fRK71SJVdfIu4AJbNOj9wuypCh4GX7n STHhY99VzV0EPZGuQtVqGHMD/m1fCUhjq98MITuhoyN5cJ9yZDOV7G2D/1N+6CvN aPMt2B0V2tz1S1mtiGF09eLURu23sSpHeeZUbSOylKXLLLRSwzyOz0t9DNT/ebGP igTCAC7N5cgIB0d+YPfULGoax6fY/YNwKYdqVE+kw7RvdRgT7/aI6I7PXMeZZa8I 1fkOOBHhfYQFo6HqLHB8K1h8NqJbMT76haDzqKss5nr+idXHHMoI+yojViaskrrY JKiRt+XBqryzshYu5H0IaZpipyAvD/Of3IkRpNthkU2bJIXMvjs= =xGO8 -----END PGP SIGNATURE----- --Apple-Mail=_E71DDB35-5617-4BD6-B0C7-130829885294-- From nobody Mon Dec 18 19:40: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 F3045127201 for ; Mon, 18 Dec 2017 19:40:04 -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 (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 UOwkfRlHe_El for ; Mon, 18 Dec 2017 19:40:03 -0800 (PST) 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 4B558124E15 for ; Mon, 18 Dec 2017 19:40:03 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJ3boOB019663 for ; Tue, 19 Dec 2017 03:40:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=bUrJ/G5GRSLahEX85Yk78oPLhFEY28Ga/pAWNGSxG9Q=; b=SJrgmdMA4uN8djE/zeKNSMDANG/9kFp34A2c21CbmW/0lnVfoOjc87xFTFYa8c2O46J6 UYOQV36YfAlMS4hyFyW76k8d1gwH2KOE7tSMp7eiai39g3546ePpI+IGfI3M7oQyM1x2 SjR+jQlJu5/JFPgDgblCWV/qmoUPDuJf5Qc0pKWJgOzFBoWV2Nvms8o0ida/XCpTDgyd 2tVZaJ0uYiW3K/UpbFcUgdkbtFwAHyfPnLTM4coOU68hAuBlPrHb0lJaQ4qAoAx8lFQS MJFXn2iv+TwEncAAR0sE1ZbgHpfCc1aTuUwCzmLirI4fkUxEAlcCO9N2oLt7yPs5YxYj Pw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2evum8ytjp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Dec 2017 03:40:01 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJ3aKhr013842 for ; Mon, 18 Dec 2017 22:40:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2evyq0x51r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 18 Dec 2017 22:39:59 -0500 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.1263.5; Mon, 18 Dec 2017 22:39:59 -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.1263.000; Mon, 18 Dec 2017 22:39:59 -0500 From: "Lubashev, Igor" To: QUIC WG Subject: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQ== Date: Tue, 19 Dec 2017 03:39:58 +0000 Message-ID: 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.41.116] Content-Type: multipart/alternative; boundary="_000_c1f5a6d8d21f423a93003f7b69dae882usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=477 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190049 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=419 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190049 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, 19 Dec 2017 03:40:05 -0000 --_000_c1f5a6d8d21f423a93003f7b69dae882usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've just posted a draft on adding partial reliability to QUIC streams. Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-r= eliability Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliab= ility This draft introduces a generic way to add partial reliability to QUIC stre= ams using a single new frame: MIN_STREAM_FRAME (and keeping one new per-str= eam variable: Min Stream Offset). The high-level idea is that the sender keeps track of messages within a str= eam and can "expire" old messages whenever it wants. The "expiration" is a= signal to the transport to not retransmit expired data (and a signal to th= e other endpoint that this data will not be retransmitted). All details ar= e in the draft. I am very interested in feedback on this proposal. * Igor --_000_c1f5a6d8d21f423a93003f7b69dae882usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve just posted a draft on adding partial rel= iability to QUIC streams.

 

Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability

Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliability

 

This draft introduces a generic way to add partial r= eliability to QUIC streams using a single new frame: MIN_STREAM_FRAME (and = keeping one new per-stream variable: Min Stream Offset).

 

The high-level idea is that the sender keeps track o= f messages within a stream and can “expire” old messages whenev= er it wants.  The “expiration” is a signal to the transpor= t to not retransmit expired data (and a signal to the other endpoint that this data will not be retransmitted).  All details are in the dr= aft.

 

I am very interested in feedback on this proposal.

 

  • Igor
--_000_c1f5a6d8d21f423a93003f7b69dae882usma1exdag1mb5msgcorpak_-- From nobody Mon Dec 18 19:56: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 F1C67127275 for ; Mon, 18 Dec 2017 19:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.929 X-Spam-Level: X-Spam-Status: No, score=-6.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SDhd1cLM7ZDM for ; Mon, 18 Dec 2017 19:56:09 -0800 (PST) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 23E78124E15 for ; Mon, 18 Dec 2017 19:56:09 -0800 (PST) Received: (qmail 83043 invoked by uid 99); 19 Dec 2017 03:56:08 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Dec 2017 03:56:08 +0000 Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 76F991A010E for ; Tue, 19 Dec 2017 03:56:05 +0000 (UTC) Received: by mail-it0-f41.google.com with SMTP id o130so7140423itg.0 for ; Mon, 18 Dec 2017 19:56:05 -0800 (PST) X-Gm-Message-State: AKGB3mKG58+kWX3ACCI++0X4bAX9c0Mhb4D7eGfJOWwoPWiW9LmafUzT /xfQhCbypmAbqpGbUlmSbgPnzmqKxcU7RpkV5w0= X-Google-Smtp-Source: ACJfBosjfLaKpZCh6d4g0+zdsGiA1cwI6XD80AC7hehJdIh3cO1r/aJKIUGeqCj5T1kMtDdeeC3Y0pvpTZvC5w0NFD0= X-Received: by 10.36.67.199 with SMTP id s190mr1676177itb.153.1513655763400; Mon, 18 Dec 2017 19:56:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Tue, 19 Dec 2017 03:55:52 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: draft-lubashev-quic-partial-reliability To: "Lubashev, Igor" Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a113faebc16fde40560a9720a" 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, 19 Dec 2017 03:56:11 -0000 --001a113faebc16fde40560a9720a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is interesting and addresses some things that I have had some conversations with others about as well. I'll try to read and give feedback in the next couple of weeks. Thanks. On Mon, Dec 18, 2017 at 8:40 PM Lubashev, Igor wrote: > I=E2=80=99ve just posted a draft on adding partial reliability to QUIC st= reams. > > > > Datatracker link: > https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability > > Github link: > https://github.com/igorlord/draft-lubashev-quic-partial-reliability > > > > This draft introduces a generic way to add partial reliability to QUIC > streams using a single new frame: MIN_STREAM_FRAME (and keeping one new > per-stream variable: Min Stream Offset). > > > > The high-level idea is that the sender keeps track of messages within a > stream and can =E2=80=9Cexpire=E2=80=9D old messages whenever it wants. = The =E2=80=9Cexpiration=E2=80=9D > is a signal to the transport to not retransmit expired data (and a signal > to the other endpoint that this data will not be retransmitted). All > details are in the draft. > > > > I am very interested in feedback on this proposal. > > > > - Igor > > --001a113faebc16fde40560a9720a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is interesting and addresses some things that I = have had some conversations with others about as well. I'll try to read= and give feedback in the next couple of weeks.

Thanks.

On Mon, Dec 18, 2017= at 8:40 PM Lubashev, Igor <iluba= she@akamai.com> wrote:

I=E2=80=99ve just posted a draft on adding partial r= eliability to QUIC streams.

=C2=A0

Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability<= /u>

Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliability<= /u>

=C2=A0

This draft introduces a generic way to add partial r= eliability to QUIC streams using a single new frame: MIN_STREAM_FRAME (and = keeping one new per-stream variable: Min Stream Offset).

=C2=A0

The high-level idea is that the sender keeps track o= f messages within a stream and can =E2=80=9Cexpire=E2=80=9D old messages wh= enever it wants.=C2=A0 The =E2=80=9Cexpiration=E2=80=9D is a signal to the = transport to not retransmit expired data (and a signal to the other endpoin= t that this data will not be retransmitted).=C2=A0 All details are in the dr= aft.

=C2=A0

I am very interested in feedback on this proposal.

=C2=A0

  • Igor
--001a113faebc16fde40560a9720a-- From nobody Tue Dec 19 00:38:02 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 0D79F124BE8; Tue, 19 Dec 2017 00:38:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Meeting Session Request for IETF 101 X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151367268100.7379.12316172886616803075.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 00:38:01 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-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, 19 Dec 2017 08:38:01 -0000 A new meeting session request has just been submitted by Lars Eggert, a Chair of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls dispatch Second Priority: mptcp saag Third Priority: irtfopen maprg People who must be present: Sean Turner Mark Nottingham Patrick R. McManus Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Mike Bishop Ian Swett Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days early in the week, if possible; 2 hour slot(s) fine too, if that makes it easier. --------------------------------------------------------- From nobody Tue Dec 19 01:38: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 9421512426E for ; Tue, 19 Dec 2017 01:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 6JLx4815RGzA for ; Tue, 19 Dec 2017 01:38:07 -0800 (PST) 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 B94611200F3 for ; Tue, 19 Dec 2017 01:38:06 -0800 (PST) Received: from BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vBJ9c3bu013469; Tue, 19 Dec 2017 09:38:03 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 09:38:03 +0000 From: Lucas Pardue To: "Lubashev, Igor" , QUIC WG Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZ Date: Tue, 19 Dec 2017 09:38:02 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> References: 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: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23538.006 x-tm-as-result: No--22.456200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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, 19 Dec 2017 09:38:08 -0000 Hi Igor, Thanks for wrting this up, it is an interesting proposal. It seems flexible= enough to apply to a few different use cases, although I do wonder how exp= ressive or accommodating APIs could be. Some basic questions: Is this proposal the "alternative single-stream method"? I think it is but = may be assuming incorrectly. With this proposal, partial reliability seems to unilaterally apply to all = streams, based on the potential reception of the MIN_STREAM_DATA frame at a= ny point during the connection lifetime. This seems a different approach th= an others where the reliability type is indicated on stream creation. Could= this feature be negotiated for the connection (or path ;) )? I can see a c= ase for simplistic client in constrained devices that may not want the over= head of supporting this feature. Similar to above, is this capability symmetric? Could it be restricted to o= ne direction of traffic? What stream are MIN_STREAM_DATA frames sent on? Could the stream ID field b= e omitted if the frame is only sent on the stream it affects? ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe@ak= amai.com] Sent: 19 December 2017 03:39 To: QUIC WG Subject: draft-lubashev-quic-partial-reliability I=92ve just posted a draft on adding partial reliability to QUIC streams. Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-r= eliability Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliab= ility This draft introduces a generic way to add partial reliability to QUIC stre= ams using a single new frame: MIN_STREAM_FRAME (and keeping one new per-str= eam variable: Min Stream Offset). The high-level idea is that the sender keeps track of messages within a str= eam and can =93expire=94 old messages whenever it wants. The =93expiration= =94 is a signal to the transport to not retransmit expired data (and a sign= al to the other endpoint that this data will not be retransmitted). All de= tails are in the draft. I am very interested in feedback on this proposal. * Igor ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Tue Dec 19 05:13: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 E0240129C6F for ; Tue, 19 Dec 2017 05:13:13 -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 (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 FlhQl6VAONfF for ; Tue, 19 Dec 2017 05:13:09 -0800 (PST) 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 EBCC4129C53 for ; Tue, 19 Dec 2017 05:13:09 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJDD7St013930; Tue, 19 Dec 2017 13:13:07 GMT 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=0UXGs/WvD0l9izpzkmiSIm5BqTTYqWGTF9yY3qg+Fcs=; b=lLiEOjuev5hd40zUReSXgsWPndL64IebkmIXwkyITgyrfgJhq+kt9U/+MQ42l8Ncntnf o5VRhLO/w/m2+fIBbWfKVxzFPTS4yEZ/iwuL7V8crVv6q3ogAwxmSzdxTrDwZsr5lhFH 3qyFcBYltgO2o8il4WfNy1XTy2pYyWqPPsAp+wsitzOMzee4zNKOfzWWsnhGynWfBDc1 aOEhjNJ/p1wn7SqP+QrRtAvFrrO+i9OS6nuunMIqXvsT/tp3ecfSknyLXt0MDyi6DcyJ K6Atk5ZIo8d9t0FLeimh/5Ux2Z3RBFv8Lb8YQaGEw6k8nkirg3J+SqMkDsZwkmE8GKGd hg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2evum91425-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 13:13:07 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJDBGam007076; Tue, 19 Dec 2017 08:13:05 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2evypxv3v2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 08:13:05 -0500 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.1263.5; Tue, 19 Dec 2017 08:13:04 -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.1263.000; Tue, 19 Dec 2017 08:13:04 -0500 From: "Lubashev, Igor" To: "quic@ietf.org" , "Lucas.Pardue@bbc.co.uk" Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPA= Date: Tue, 19 Dec 2017 13:13:04 +0000 Message-ID: <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> References: , <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> 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_85d7dc28d3bb40a38873f4d32a16fd71usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190190 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190191 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, 19 Dec 2017 13:13:14 -0000 --_000_85d7dc28d3bb40a38873f4d32a16fd71usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Lucas! Yes, I have seen other proposals, and this is my alternative. The idea is that all streams, other than stream 0, can be partially reliabl= e, in both directions, without a need to negotiate (other than version nego= tiation, in case the initial QUIC version does not support this). The bookkeeping is simple enough and the runtime resources required is just= one uint64_t per steam, so I do not see a problem for constrained devices. Ultimately, partial reliability is a feature that an application either nee= ds or does not. If an application needs it, it most likely requires it. In = any case, an application can do its own negotiation if it desires to do so.= For example, it can use stream 1 for that. I did not fully understand the last question. Are you asking whether it is = possible for the connection to negotiate just a single stream (in each dire= ction) that would be partially reliable and, therefore, not send a stream i= d with MIN_STREAM_DATA? I could actually think of a version of MIN_STREAM_D= ATA that has an implied stream id -- the stream id of a prior/following STR= EAM frame in the same packet. That would be an optimization that I am happy= to add, if there is enough support for it. - Igor -----Original Message----- From: Lucas Pardue [Lucas.Pardue@bbc.co.uk] Received: Tuesday, 19 Dec 2017, 4:38AM To: Lubashev, Igor [ilubashe@akamai.com]; QUIC WG [quic@ietf.org] Subject: RE: draft-lubashev-quic-partial-reliability Hi Igor, Thanks for wrting this up, it is an interesting proposal. It seems flexible= enough to apply to a few different use cases, although I do wonder how exp= ressive or accommodating APIs could be. Some basic questions: Is this proposal the "alternative single-stream method"? I think it is but = may be assuming incorrectly. With this proposal, partial reliability seems to unilaterally apply to all = streams, based on the potential reception of the MIN_STREAM_DATA frame at a= ny point during the connection lifetime. This seems a different approach th= an others where the reliability type is indicated on stream creation. Could= this feature be negotiated for the connection (or path ;) )? I can see a c= ase for simplistic client in constrained devices that may not want the over= head of supporting this feature. Similar to above, is this capability symmetric? Could it be restricted to o= ne direction of traffic? What stream are MIN_STREAM_DATA frames sent on? Could the stream ID field b= e omitted if the frame is only sent on the stream it affects? ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe@ak= amai.com] Sent: 19 December 2017 03:39 To: QUIC WG Subject: draft-lubashev-quic-partial-reliability I=92ve just posted a draft on adding partial reliability to QUIC streams. Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-r= eliability Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliab= ility This draft introduces a generic way to add partial reliability to QUIC stre= ams using a single new frame: MIN_STREAM_FRAME (and keeping one new per-str= eam variable: Min Stream Offset). The high-level idea is that the sender keeps track of messages within a str= eam and can =93expire=94 old messages whenever it wants. The =93expiration= =94 is a signal to the transport to not retransmit expired data (and a sign= al to the other endpoint that this data will not be retransmitted). All de= tails are in the draft. I am very interested in feedback on this proposal. * Igor ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- --_000_85d7dc28d3bb40a38873f4d32a16fd71usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks Lucas!

Yes, I have seen other proposals, and this is my alternative.

The idea is that all streams, other than stream 0, can be partially reliabl= e, in both directions, without a need to negotiate (other than version nego= tiation, in case the initial QUIC version does not support this).

The bookkeeping is simple enough and the runtime resources required is just= one uint64_t per steam, so I do not see a problem for constrained devices.=

Ultimately, partial reliability is a feature that an application either nee= ds or does not. If an application needs it, it most likely requires it. In = any case, an application can do its own negotiation if it desires to do so.= For example, it can use stream 1 for that.

I did not fully understand the last question. Are you asking whether it is = possible for the connection to negotiate just a single stream (in each dire= ction) that would be partially reliable and, therefore, not send a stream i= d with MIN_STREAM_DATA? I could actually think of a version of MIN_STREAM_DATA that has an implied stream = id -- the stream id of a prior/following STREAM frame in the same packet. T= hat would be an optimization that I am happy to add, if there is enough sup= port for it.

- Igor

-----Original Message-----
From: Lucas Pardue [Lucas.Pardue@bbc.co.uk]
Received: Tuesday, 19 Dec 2017, 4:38AM
To: Lubashev, Igor [ilubashe@akamai.com]; QUIC WG [quic@ietf.org] Subject: RE: draft-lubashev-quic-partial-reliability

Hi Igor,

Thanks for wrting this up, it is an interesting proposal. It seems flexible= enough to apply to a few different use cases, although I do wonder how exp= ressive or accommodating APIs could be.

Some basic questions:

Is this proposal the "alternative single-stream method"? I think = it is but may be assuming incorrectly.

With this proposal, partial reliability seems to unilaterally apply to all = streams, based on the potential reception of the MIN_STREAM_DATA frame at a= ny point during the connection lifetime. This seems a different approach th= an others where the reliability type is indicated on stream creation. Could this feature be negotiated for= the connection (or path ;) )? I can see a case for simplistic client in co= nstrained devices that may not want the overhead of supporting this feature= .

Similar to above, is this capability symmetric? Could it be restricted to o= ne direction of traffic?

What stream are MIN_STREAM_DATA frames sent on? Could the stream ID field b= e omitted if the frame is only sent on the stream it affects?
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe@ak= amai.com]
Sent: 19 December 2017 03:39
To: QUIC WG
Subject: draft-lubashev-quic-partial-reliability

I=92ve just posted a draft on adding partial reliability to QUIC streams.
Datatracker link: https://tools.ietf.org/html/draft-lubashev-quic-partial-reliability
Github link: https://github.com/igorlord/draft-lubashev-quic-partial-reliability

This draft introduces a generic way to add partial reliability to QUIC stre= ams using a single new frame: MIN_STREAM_FRAME (and keeping one new per-str= eam variable: Min Stream Offset).

The high-level idea is that the sender keeps track of messages within a str= eam and can =93expire=94 old messages whenever it wants.  The =93expir= ation=94 is a signal to the transport to not retransmit expired data (and a= signal to the other endpoint that this data will not be retransmitted).  All details are in the draft.

I am very interested in feedback on this proposal.


  *   Igor



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specif= ically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
 --_000_85d7dc28d3bb40a38873f4d32a16fd71usma1exdag1mb5msgcorpak_-- From nobody Tue Dec 19 07:47: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 3A2BC124BFA for ; Tue, 19 Dec 2017 07:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 K2UxgmZ_xIR1 for ; Tue, 19 Dec 2017 07:47:02 -0800 (PST) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.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 BFC59124B17 for ; Tue, 19 Dec 2017 07:47:01 -0800 (PST) Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vBJFkvVW010766; Tue, 19 Dec 2017 15:46:57 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.0361.001; Tue, 19 Dec 2017 15:46:56 +0000 From: Lucas Pardue To: "Lubashev, Igor" , "quic@ietf.org" Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEA== Date: Tue, 19 Dec 2017 15:46:56 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> References: , <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23540.000 x-tm-as-result: No--22.023900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01bgb01xud1012_" 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, 19 Dec 2017 15:47:03 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01bgb01xud1012_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Igor wrote: The bookkeeping is simple enough and the runtime resources required is just= one uint64_t per steam, so I do not see a problem for constrained devices. Ultimately, partial reliability is a feature that an application either nee= ds or does not. If an application needs it, it most likely requires it. In = any case, an application can do its own negotiation if it desires to do so.= For example, it can use stream 1 for that. Now I understand this is connection-wide, I generally agree. However, for s= omething like conventional HTTP/QUIC, the reliable guarantee assurances are= required by the mapping. If partial reliability is default enabled transpo= rt feature, applications like HTTP/QUIC must restrict or disable it - I'm n= ot sure if the editors/drafts have broached that subject yet (I've certainl= y had some feedback on my draft about such restrictions). I did not fully understand the last question. Are you asking whether it is = possible for the connection to negotiate just a single stream (in each dire= ction) that would be partially reliable and, therefore, not send a stream i= d with MIN_STREAM_DATA? I could actually think of a version of MIN_STREAM_D= ATA that has an implied stream id -- the stream id of a prior/following STR= EAM frame in the same packet. That would be an optimization that I am happy= to add, if there is enough support for it. Apologies, I hadn't drunk any coffee when first replying and got myself con= fused. All QUIC frames of this nature should normally include a Stream ID, = which identifies the stream it is sent on. I think your suggestion relies o= n serial ordering/processing (even inside a packet), which might be a hard = sell. Separately, in terms of asymmetry, I was thinking that you might always wan= t (as a policy) clients to transmit with full reliability but provide data = to them with partial reliability. I think this is again an application mapp= ing concern. Regards, Lucas --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01bgb01xud1012_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Igor wrote:

 

The bookkeeping is simple enough and the runtime resources required = is just one uint64_t per steam, so I do not see a problem for constrained d= evices.

Ultimately, partial reliability is a feature that an application eit= her needs or does not. If an application needs it, it most likely requires = it. In any case, an application can do its own negotiation if it desires to do so. For example, it can use stream= 1 for that.

Now I understand this is connection-wide, I generall= y agree. However, for something like conventional HTTP/QUIC, the reliable g= uarantee assurances are required by the mapping. If partial reliability is = default enabled transport feature, applications like HTTP/QUIC must restrict or disable it – I’m = not sure if the editors/drafts have broached that subject yet (I’ve c= ertainly had some feedback on my draft about such restrictions).=

 

I did not fully understand the last question. Are you asking whether= it is possible for the connection to negotiate just a single stream (in ea= ch direction) that would be partially reliable and, therefore, not send a stream id with MIN_STREAM_DATA? I coul= d actually think of a version of MIN_STREAM_DATA that has an implied stream= id -- the stream id of a prior/following STREAM frame in the same packet. = That would be an optimization that I am happy to add, if there is enough support for it.

 

Apologies, I hadn’t drunk any coffee when firs= t replying and got myself confused. All QUIC frames of this nature should n= ormally include a Stream ID, which identifies the stream it is sent on. I t= hink your suggestion relies on serial ordering/processing (even inside a packet), which might be a hard sell.

 

Separately, in terms of asymmetry, I was thinking th= at you might always want (as a policy) clients to transmit with full reliab= ility but provide data to them with partial reliability. I think this is ag= ain an application mapping concern.

 

Regards,

Lucas

 

--_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01bgb01xud1012_-- From nobody Tue Dec 19 09:15: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 9ACA212D838 for ; Tue, 19 Dec 2017 09:15:22 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5DCaIzFsjOX for ; Tue, 19 Dec 2017 09:15:20 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 B8AC612D94F for ; Tue, 19 Dec 2017 09:15:20 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id f190so3595167ita.5 for ; Tue, 19 Dec 2017 09:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=4XelZiDgLBB/8idyvW5rt2FVqmOUrWjkUpS0VplHZ3c=; b=Tp/vAty+2IrpNG1X81VsCWGXdPmAPxfuY5gj4Fp4QbQ9yBr7yVgoExtFHCHM05ekbF RDz/ybXI6D0+OXg50LsZs2pLvxKWm3lnJy1B/uCtGjnjbtX/zZdEwp8WUAPDMNLNN4Dz Dc35q5ZYAXrP7/zcMS627CBMF51jWWbdr8Fz48kzc+uzFncCkDe/zjPVSibWP7PYOjGm n2sSS77ul0UTFThvgWUCQqEqUGFSRB9dE+e3a8gUbJ1iUKQzueJhttCwiYt3c4mlBcsO EXFtN4/kHS8uYk96H6c1QY/JwM9ZnSdGxEMyGA9769Ldw2jLZhDAuPLsq8qt64mOda6+ g9xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=4XelZiDgLBB/8idyvW5rt2FVqmOUrWjkUpS0VplHZ3c=; b=A79ZIEx+g3VShgLKUlOEoT3YOqXqpuru6ScWq3rcutAUK/3e519WpGPmlXR/Wj2YcG BnzOn24hyFX92n5lm3Xthv2Bn74n1jOJ9MWVTo44MUNhKnR8GVEcNPVIZ5Wyc6oWORrc tDTqXhTVvJN4mIEsdk1XRpNXyytfJjpQw3rJQD4Vc2kuGYjf6kiu5FUTQJaz1DBG/G91 mMDd6+dbdnzUdGzjQDvrxTOtcmZyA7pTXFZUG28YIqXI0YbMQgowu7bZIqql2AFLBOW2 LWJ0pz+S/rsrHk9VbqR8jZNBMmAVLyaR+6+Vd+MqBACVkB+omJsuvyXEuZe9HjeIvZbk TbgQ== X-Gm-Message-State: AKGB3mJF9wosk+S1Z428Cx4U0UJRYprQf9mIckE7EQG6u6vq5VaiAKht gCLoyVk+wZ+/KVIREc7k58PviBvv1866g8EOc7oNDQ== X-Google-Smtp-Source: ACJfBot8Zcu/Wile72LGwuL8RtUo6lU7CPPZTQH819xr8mWdQktTmeh+aq95yY/al2XO4a8fFayS6MtC5B7m8yJa4Hk= X-Received: by 10.36.95.14 with SMTP id r14mr4034805itb.42.1513703720097; Tue, 19 Dec 2017 09:15:20 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Dec 2017 09:15:19 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Dec 2017 09:15:19 -0800 Message-ID: Subject: RE: draft-lubashev-quic-partial-reliability To: Lucas Pardue , "Lubashev, Igor" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b57a881ab60560b49c0a" 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, 19 Dec 2017 17:15:23 -0000 --001a1144b57a881ab60560b49c0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this proposal largely makes good sense. Be default no MIN_STREAM_DATA frame is sent which is then the current stream behaviour. Any application protocol can define its own rules about which streams can behave partially reliable. A counter argument is that QUIC explicitly distinguishes between uni- and bi-directional streams, so why not between partial- and fully reliable streams? The answer might be that uni- streams can close state early, while there is no similar concern for partial reliability. Another concern is time-based partial reliability. If data is old, don=E2= =80=99t retransmit regardless. But an application protocol can handle this. My main concern is that sending MIN_FRAME_DATA can generate A LOT of traffic with lots of tiny messages where you only care about, say, the last three 1 byte messages sent (hoping at least one gets through). The MIN_FRAME_DATA could be much larger than the messages forcing less frequent traffic. Of course, locally you can have you own rules, and just periodically update MIN_FRAME_DATA, but this is a bit odd. A variation of the concept could be sending MIN_FRAME_DATA as a delta to most recent: never expect more than X bytes older than most recently seen, but that also has it issues when messages are variable length. As to client vs server asymmetri: It strongly suggest not to make a distinction here because there are many symmetric peer to peer use cases and also opposite cases: server to client with partially reliable video, client to server with partially reliable game state, server to server with partially reliable gossip protocol to statistically advance a common state (e.g. "I have processed so many bytes now, how about you?=E2=80=9D). Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 December 2017 at 16.47.08, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Igor wrote: The bookkeeping is simple enough and the runtime resources required is just one uint64_t per steam, so I do not see a problem for constrained devices. Ultimately, partial reliability is a feature that an application either needs or does not. If an application needs it, it most likely requires it. In any case, an application can do its own negotiation if it desires to do so. For example, it can use stream 1 for that. Now I understand this is connection-wide, I generally agree. However, for something like conventional HTTP/QUIC, the reliable guarantee assurances are required by the mapping. If partial reliability is default enabled transport feature, applications like HTTP/QUIC must restrict or disable it =E2=80=93 I=E2=80=99m not sure if the editors/drafts have broached that sub= ject yet (I=E2=80=99ve certainly had some feedback on my draft about such restrictions). I did not fully understand the last question. Are you asking whether it is possible for the connection to negotiate just a single stream (in each direction) that would be partially reliable and, therefore, not send a stream id with MIN_STREAM_DATA? I could actually think of a version of MIN_STREAM_DATA that has an implied stream id -- the stream id of a prior/following STREAM frame in the same packet. That would be an optimization that I am happy to add, if there is enough support for it. Apologies, I hadn=E2=80=99t drunk any coffee when first replying and got my= self confused. All QUIC frames of this nature should normally include a Stream ID, which identifies the stream it is sent on. I think your suggestion relies on serial ordering/processing (even inside a packet), which might be a hard sell. Separately, in terms of asymmetry, I was thinking that you might always want (as a policy) clients to transmit with full reliability but provide data to them with partial reliability. I think this is again an application mapping concern. Regards, Lucas --001a1144b57a881ab60560b49c0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I think this proposa= l largely makes good sense.

Be default no MIN_STREAM_DATA frame is sent which is then the curren= t stream behaviour.
Any application protocol can define its own rules about which stream= s can behave partially reliable.

A counter argument is that QUIC explicitly distinguishes betwee= n uni- and bi-directional streams, so why not between partial- and fully re= liable streams? The answer might be that uni- streams can close state early= , while there is no similar concern for partial reliability.

Another concern is time-based par= tial reliability. If data is old, don=E2=80=99t retransmit regardless. But = an application protocol can handle this.

My main concern is that sending MIN_FRAME_DATA can gene= rate A LOT of traffic with lots of tiny messages where you only care about,= say, the last three 1 byte messages sent (hoping at least one gets through= ). The MIN_FRAME_DATA could be much larger than the messages forcing less f= requent traffic. Of course, locally you can have you own rules, and just pe= riodically update MIN_FRAME_DATA, but this is a bit odd.

A variation of the concept could be sen= ding MIN_FRAME_DATA as a delta to most recent: never expect more than X byt= es older than most recently seen, but that also has it issues when messages= are variable length.


As to c= lient vs server asymmetri: It strongly suggest not to make a distinction he= re because there are many symmetric peer to peer use cases and also opposit= e cases: server to client with partially reliable video, client to server w= ith partially reliable game state, server to server with partially reliable= gossip protocol to statistically advance a common state (e.g. "I have= processed so many bytes now, how about you?=E2=80=9D).


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

<= /div>

On 19 December 2017 at 16.47.08, Lu= cas Pardue (lucas.pardue@bbc.co.u= k) wrote:

Igor wrote:

=C2=A0

The bookkeeping is simple enough and the runtime resources required = is just one uint64_t per steam, so I do not see a problem for constrained d= evices.

Ultimately, partial reliability is a feature that an application eit= her needs or does not. If an application needs it, it most likely requires = it. In any case, an application can do its own negotiation if it desires to do so. For example, it can use stream= 1 for that.

Now I understand this is connection-wide, I generall= y agree. However, for something like conventional HTTP/QUIC, the reliable g= uarantee assurances are required by the mapping. If partial reliability is = default enabled transport feature, applications like HTTP/QUIC must restrict or disable it =E2=80=93 I=E2=80= =99m not sure if the editors/drafts have broached that subject yet (I=E2=80= =99ve certainly had some feedback on my draft about such restrictions).

=C2=A0

I did not fully understand the last question. Are you asking whether= it is possible for the connection to negotiate just a single stream (in ea= ch direction) that would be partially reliable and, therefore, not send a stream id with MIN_STREAM_DATA? I coul= d actually think of a version of MIN_STREAM_DATA that has an implied stream= id -- the stream id of a prior/following STREAM frame in the same packet. = That would be an optimization that I am happy to add, if there is enough support for it.

=C2=A0

Apologies, I hadn=E2=80=99t drunk any coffee when fi= rst replying and got myself confused. All QUIC frames of this nature should= normally include a Stream ID, which identifies the stream it is sent on. I= think your suggestion relies on serial ordering/processing (even inside a packet), which might be a hard sell.

=C2=A0

Separately, in terms of asymmetry, I was thinking th= at you might always want (as a policy) clients to transmit with full reliab= ility but provide data to them with partial reliability. I think this is ag= ain an application mapping concern.

=C2=A0

Regards,

Lucas

=C2=A0

--001a1144b57a881ab60560b49c0a-- From nobody Tue Dec 19 09:22: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 DC8D212D7F6 for ; Tue, 19 Dec 2017 09:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 F3LJKZP_mM-p for ; Tue, 19 Dec 2017 09:22:18 -0800 (PST) Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.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 3D227124C27 for ; Tue, 19 Dec 2017 09:22:18 -0800 (PST) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vBJHMDSQ020186; Tue, 19 Dec 2017 17:22:13 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.03.0361.001; Tue, 19 Dec 2017 17:22:13 +0000 From: Lucas Pardue To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Lubashev, Igor" , "quic@ietf.org" Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEAAGisaAAAATtMA= Date: Tue, 19 Dec 2017 17:22:12 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> 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.213] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23540.000 x-tm-as-result: No--22.016700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44bgb01xud1012_" 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, 19 Dec 2017 17:22:20 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44bgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWlra2VsIHdyb3RlOg0KDQo+IEFzIHRvIGNsaWVudCB2cyBzZXJ2ZXIgYXN5bW1ldHJpOiBJdCBz dHJvbmdseSBzdWdnZXN0IG5vdCB0byBtYWtlIGEgZGlzdGluY3Rpb24gaGVyZSBiZWNhdXNlIHRo ZXJlIGFyZSBtYW55IHN5bW1ldHJpYyBwZWVyIHRvIHBlZXIgdXNlIGNhc2VzIGFuZCBhbHNvIG9w cG9zaXRlIGNhc2VzOiBzZXJ2ZXIgdG8gY2xpZW50IHdpdGggcGFydGlhbGx5IHJlbGlhYmxlIHZp ZGVvLCBjbGllbnQgdG8gc2VydmVyIHdpdGggcGFydGlhbGx5IHJlbGlhYmxlIGdhbWUgc3RhdGUs IHNlcnZlciB0byBzZXJ2ZXIgd2l0aCBwYXJ0aWFsbHkgcmVsaWFibGUgZ29zc2lwIHByb3RvY29s IHRvIHN0YXRpc3RpY2FsbHkgYWR2YW5jZSBhIGNvbW1vbiBzdGF0ZSAoZS5nLiAiSSBoYXZlIHBy b2Nlc3NlZCBzbyBtYW55IGJ5dGVzIG5vdywgaG93IGFib3V0IHlvdT/igJ0pLg0KDQpZZXMsIGVh cmx5IHNwZWNpYWxpc2F0aW9uIGlzIGEgcm91dGUgdG8gZGlzYXBwb2ludG1lbnQuIFRoZXJlIGFy ZSBvdGhlciBkaXNjdXNzaW9ucyBhcm91bmQgdW5uZWNlc3NhcnkgYXN5bW1ldHJ5IGF0IHRoaXMg bGV2ZWwuDQoNClJlZ2FyZHMNCkx1Y2FzDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCmh0dHA6Ly93d3cuYmJjLmNvLnVrDQpUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2ht ZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGlj aCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUgQkJDIHVubGVzcyBzcGVjaWZpY2FsbHkgc3RhdGVk Lg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJv bSB5b3VyIHN5c3RlbS4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0 aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkuDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBCQkMgbW9uaXRvcnMgZS1t YWlscyBzZW50IG9yIHJlY2VpdmVkLg0KRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlm eSB5b3VyIGNvbnNlbnQgdG8gdGhpcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44bgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBNYWlsIERpc2NsYWltZXJzIG9uIDA1OjIyOjEzIFR1ZXNkYXksIDE5IERlY2VtYmVyIDIw MTcgLS0+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPlAuNWVlM2FhZjYtNjI2 NC00NDQxLWIxODgtNjE2MDIzOWY4NDMyIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpMSS41 ZWUzYWFmNi02MjY0LTQ0NDEtYjE4OC02MTYwMjM5Zjg0MzIgew0KCU1BUkdJTjogMGNtIDBjbSAw cHQNCn0NCkRJVi41ZWUzYWFmNi02MjY0LTQ0NDEtYjE4OC02MTYwMjM5Zjg0MzIgew0KCU1BUkdJ TjogMGNtIDBjbSAwcHQNCn0NClRBQkxFLjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4LTYxNjAyMzlm ODQzMlRhYmxlIHsNCglNQVJHSU46IDBjbSAwY20gMHB0DQp9DQpESVYuU2VjdGlvbjEgew0KCXBh Z2U6IFNlY3Rpb24xDQp9DQo8L3N0eWxlPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyog Rm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFy Z2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC5haXJtYWlsb24sIGxpLmFpcm1haWxvbiwgZGl2LmFpcm1haWxvbg0KCXttc28tc3R5 bGUtbmFtZTphaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPHAgY2xhc3M9IjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4 LTYxNjAyMzlmODQzMiI+PC9wPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWlr a2VsIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg QXMgdG8gY2xpZW50IHZzIHNlcnZlciBhc3ltbWV0cmk6IEl0IHN0cm9uZ2x5IHN1Z2dlc3Qgbm90 IHRvIG1ha2UgYSBkaXN0aW5jdGlvbiBoZXJlIGJlY2F1c2UgdGhlcmUgYXJlIG1hbnkgc3ltbWV0 cmljIHBlZXIgdG8gcGVlciB1c2UgY2FzZXMgYW5kIGFsc28gb3Bwb3NpdGUgY2FzZXM6IHNlcnZl cg0KIHRvIGNsaWVudCB3aXRoIHBhcnRpYWxseSByZWxpYWJsZSB2aWRlbywgY2xpZW50IHRvIHNl cnZlciB3aXRoIHBhcnRpYWxseSByZWxpYWJsZSBnYW1lIHN0YXRlLCBzZXJ2ZXIgdG8gc2VydmVy IHdpdGggcGFydGlhbGx5IHJlbGlhYmxlIGdvc3NpcCBwcm90b2NvbCB0byBzdGF0aXN0aWNhbGx5 IGFkdmFuY2UgYSBjb21tb24gc3RhdGUgKGUuZy4gJnF1b3Q7SSBoYXZlIHByb2Nlc3NlZCBzbyBt YW55IGJ5dGVzIG5vdywgaG93IGFib3V0IHlvdT/igJ0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WWVzLCBlYXJseSBzcGVjaWFsaXNhdGlvbiBpcyBhIHJvdXRlIHRvIGRpc2FwcG9p bnRtZW50LiBUaGVyZSBhcmUgb3RoZXIgZGlzY3Vzc2lvbnMgYXJvdW5kIHVubmVjZXNzYXJ5IGFz eW1tZXRyeSBhdCB0aGlzIGxldmVsLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkx1Y2FzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwPjwvcD4NCjxwIGNsYXNzPSI1ZWUzYWFmNi02MjY0LTQ0NDEtYjE4OC02MTYw MjM5Zjg0MzIiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSI1ZWUzYWFmNi02MjY0LTQ0NDEtYjE4OC02 MTYwMjM5Zjg0MzIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxhIGhyZWY9Imh0dHA6Ly93d3cuYmJj LmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy48c3BhbiBjbGFzcz0iaWwiPmJiYzwv c3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj5jbzwvc3Bhbj4uPHNwYW4gY2xhc3M9ImlsIj51azwvc3Bh bj48L2E+PGJyPg0KVGhpcyBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2ggYXJlIG5vdCB0aGUgdmll d3Mgb2YgdGhlDQo8c3BhbiBjbGFzcz0iaWwiPkJCQzwvc3Bhbj4gdW5sZXNzIHNwZWNpZmljYWxs eSBzdGF0ZWQuPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS48YnI+DQpEbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Ns b3NlIHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgd2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQg YW5kIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5Ljxicj4NClBsZWFzZSBub3RlIHRoYXQg dGhlIDxzcGFuIGNsYXNzPSJpbCI+QkJDPC9zcGFuPiBtb25pdG9ycyBlLW1haWxzIHNlbnQgb3Ig cmVjZWl2ZWQuPGJyPg0KRnVydGhlciBjb21tdW5pY2F0aW9uIHdpbGwgc2lnbmlmeSB5b3VyIGNv bnNlbnQgdG8gdGhpcy48L2ZvbnQ+PC9mb250PjwvZm9udD48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 IjVlZTNhYWY2LTYyNjQtNDQ0MS1iMTg4LTYxNjAyMzlmODQzMiI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44bgb01xud1012_-- From nobody Tue Dec 19 09:40: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 18E4112D7F5 for ; Tue, 19 Dec 2017 09:40:50 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXj9uZclmjNs for ; Tue, 19 Dec 2017 09:40:48 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F39E1241F5 for ; Tue, 19 Dec 2017 09:40:48 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id e204so14420349iof.12 for ; Tue, 19 Dec 2017 09:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=tB5Qsvm2dIP4heNA1xh9BUYETXmJiKerrpCCDpd8E/A=; b=CT5oJk6P/GtPpit8LbHWTSjNuLV7UhdGeskS6keXrPXCmoIOmuZRgbLbt4cNbpAV1B vQb1LpuDSW8jMnFmiTfvAQ7awtoDw0JchlapOT0bIdiK7znbI+YssGJwX9GifWKgLFZM Z+XE2Q2PQW/R0KIv90HB4+mPcUmIgFARFRD2rMRl+W0i6Odzw9tlt1XhcZlr1GeGiUeW 63gtBEpgxBKvTpYYa9OW2iKWIVyprFpKw7BIjtz4h2IeNQGlWmHqKuqwqsR8A17vmU2I z4/KiIS/A/Tyka2ZUftAEWTsIuujY8AvTN7c58n83uOzfe7Ixbj6TLBMEgn/TjXKZ5/F a2fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=tB5Qsvm2dIP4heNA1xh9BUYETXmJiKerrpCCDpd8E/A=; b=l7L2SRHtd9C10Ha+ZwFsutipo26++f9RTbuDQcWRFPnHzq+b64CLRT27XMOC+outH/ 7fK2tynLWZfY1ZFXy0Z0d04E9y/U/PKuB0LER0hhSnJEODpUND90NlfLFSrEuxWGFYB/ NplC3E6qDJAgaOF4KBuOZtefYQRdrNp8Qr6F0zChHDZblD8yLOHdMpuYSo0SUb3M1U3F O6WTWJDhBH2S3L/ZWQTHjwqhsEySiNCokAgT7CUX2C9M8yj3A4P8oeptdOkedPK0DlUx kQ0gfUUSeVikCf3b+BmHmL8sxF+0T1PUkf6iaKhbRbW7mZhwC1pqZ2mUiYLn03yXyaCn ob8w== X-Gm-Message-State: AKGB3mI0JjDqt/xJsdS2I3kjiIGnC4SxcgvNsc5EHrbb9q5q3YK+K/WF l4U6gjPE+qCiWCCu/l6REB8dHtNWS9dgSzjYsDw= X-Google-Smtp-Source: ACJfBovCCsIETdwz8sNKXSabL34BsBDOY2sT3QO7/w1J5Kn1j8kLSqDB+gtbF54sXiOd9eREMZI8Kd6yWxojn+Q63oE= X-Received: by 10.107.69.20 with SMTP id s20mr4895963ioa.239.1513705247637; Tue, 19 Dec 2017 09:40:47 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Dec 2017 09:40:46 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B44@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Dec 2017 09:40:46 -0800 Message-ID: Subject: RE: draft-lubashev-quic-partial-reliability To: Lucas Pardue , "Lubashev, Igor" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="089e082866a89486880560b4f769" 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, 19 Dec 2017 17:40:50 -0000 --089e082866a89486880560b4f769 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another thought: The partial reliability problem is really like a reverse ACK problem. You can send a frame similar to ACK, be referring to you own streams rather than the peers packets. For any stream where the conceptual MIN_STREAM_DATA is 0, not transmission is made. Otherwise all unclosed streams have an entry in a frame carrying many streams at once. This might be delivered unreliable similar to ACK, since old reverse ACK are not that interesting. You loose some details about sent vs unsent, but peer can deduce that because a stream does not have gaps. (A stream could pretend to have lost some data by never sending it if it gets behind, it it is the same thing). This would use much less space achieving largely the same concept as with MIN_STREAM_DATA frames for one stream at time. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 December 2017 at 18.22.16, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote: Mikkel wrote: > As to client vs server asymmetri: It strongly suggest not to make a distinction here because there are many symmetric peer to peer use cases and also opposite cases: server to client with partially reliable video, client to server with partially reliable game state, server to server with partially reliable gossip protocol to statistically advance a common state (e.g. "I have processed so many bytes now, how about you?=E2=80=9D). Yes, early specialisation is a route to disappointment. There are other discussions around unnecessary asymmetry at this level. Regards Lucas ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. --------------------- --089e082866a89486880560b4f769 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Another thought:

The partial reliability = problem is really like a reverse ACK problem.
You can send a frame similar to ACK, be re= ferring to you own streams rather than the peers packets. For any stream wh= ere the conceptual MIN_STREAM_DATA is 0, not transmission is made. Otherwis= e all unclosed streams have an entry in a frame carrying many streams at on= ce. This might be delivered unreliable similar to ACK, since old reverse AC= K are not that interesting.=C2=A0

You loose some details about sent vs unsent, but peer can de= duce that because a stream does not have gaps. (A stream could pretend to h= ave lost some data by never sending it if it gets behind, it it is the same= thing).

=
This would u= se much less space achieving largely the same concept as with MIN_STREAM_DA= TA frames for one stream at time.

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


On 19 December 2017 at 18.22.16, Lucas Pardue (lucas.pardue@bbc.co.uk) wrote:

Mikkel wr= ote:

=C2=A0

> As to client vs server asymmetri: It strongl= y suggest not to make a distinction here because there are many symmetric p= eer to peer use cases and also opposite cases: server to client with partially reliable video, client to server with partially r= eliable game state, server to server with partially reliable gossip protoco= l to statistically advance a common state (e.g. "I have processed so m= any bytes now, how about you?=E2=80=9D).

=C2=A0

Yes, early specialisation is a route to disappointme= nt. There are other discussions around unnecessary asymmetry at this level.

=C2=A0

Regards

Lucas

=C2=A0

-------------------------= ---

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal = views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance= on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or= received.
Further communication will signify your consent to this.

---------------------

 --089e082866a89486880560b4f769-- From nobody Tue Dec 19 11:02: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 1E3F51289B0 for ; Tue, 19 Dec 2017 11:02: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, 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=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 5zaDDVxTvyxw for ; Tue, 19 Dec 2017 11:02:45 -0800 (PST) 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 4DA151200F1 for ; Tue, 19 Dec 2017 11:02:45 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJJ2IDc008962; Tue, 19 Dec 2017 19:02:40 GMT 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=6EKcFamdOq6sLhzalhlZxTGscRiGaSwxebtwtX+08+o=; b=SoWyRXmCZREVgb6za2O3aGIatyWiSar8spN2N8Z2rFoIUd4LlvoRUtT+L0ADNf7lCNNK KYp1OEpF18yMCcc4Ai8hyE2319ZJcVaYnEWXQjZHSWd8RNnwRHS7ikWG0iK9ROwo95VF Ml8qjabejgFicFdC5pCfCi/1ktpXYThzheX+vwCon6PLOgoNE2j41dSF+bYOwIqH3kUO jmcSKNoU2x5MClu2uJpNvbE4NatRJdwC1IywcIU/2zqWrtn5k0ExK0FSl8Q9TdkMg3tL GsA2X7SGFcVEr2ntdU2KswM4scA4G4+81OuaQAEJhuke31l1o/ibmteB0u98Gp9MO6tE Jg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2evvdkt2mm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 19:02:39 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJJ0sV6025013; Tue, 19 Dec 2017 14:02:38 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2evyq10d7g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 14:02:38 -0500 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.1263.5; Tue, 19 Dec 2017 14:02:35 -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.1263.000; Tue, 19 Dec 2017 14:02:35 -0500 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Lucas Pardue , "quic@ietf.org" Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEAARBPyAAAhDLtA= Date: Tue, 19 Dec 2017 19:02:34 +0000 Message-ID: <49797640bd7444f39b51a7595ee53c72@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> 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.55] Content-Type: multipart/alternative; boundary="_000_49797640bd7444f39b51a7595ee53c72usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190272 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190272 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, 19 Dec 2017 19:02:48 -0000 --_000_49797640bd7444f39b51a7595ee53c72usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQW5vdGhlciBjb25jZXJuIGlzIHRpbWUtYmFzZWQgcGFydGlhbCByZWxpYWJpbGl0eS4g SWYgZGF0YSBpcyBvbGQsIGRvbuKAmXQgcmV0cmFuc21pdCByZWdhcmRsZXNzLiBCdXQgYW4gYXBw bGljYXRpb24gcHJvdG9jb2wgY2FuIGhhbmRsZSB0aGlzDQoNClllcywgdGhpcyBpcyBhbiBhcHBs aWNhdGlvbiBjb25jZXJuLCBzaW5jZSBvbmx5IHRoZSBhcHBsaWNhdGlvbiBjYW4ga25vdyB3aGF0 IOKAnG9sZOKAnSBtZWFucy4gIEFsc28sIHNpbmNlIE1JTl9GUkFNRV9EQVRBICBmcmFtZSBpcyBl bWl0dGVkIE9OTFkgaWYgc29tZSBleHBpcmVkIHN0cmVhbSBkYXRhIGlzIGxvc3QgKG5vdCBBQ0tl ZCksIHlvdSB3b3VsZCBub3QgZXhwZWN0IHRvIHNlZSBtYW55IHN1Y2ggZnJhbWVzIG9uIHRoZSB3 aXJlLCBldmVuIGlmIG1lc3NhZ2VzIGtlZXAgZXhwaXJpbmcgYWxsIHRoZSB0aW1lLg0KDQoNCg0K ICAqICAgTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgc2VuZGluZyBNSU5fRlJBTUVfREFUQSBbc2lj OiBNSU5fU1RSRUFNX0RBVEFdIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGggbG90 cyBvZiB0aW55IG1lc3NhZ2VzIHdoZXJlIHlvdSBvbmx5IGNhcmUgYWJvdXQsIHNheSwgdGhlIGxh c3QgdGhyZWUgMSBieXRlIG1lc3NhZ2VzIHNlbnQgKGhvcGluZyBhdCBsZWFzdCBvbmUgZ2V0cyB0 aHJvdWdoKS4gVGhlIE1JTl9GUkFNRV9EQVRBIGNvdWxkIGJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhl IG1lc3NhZ2VzDQoNClRoaXMgaXMgdGhlIG1vc3QgZXhwZW5zaXZlIGNhc2UgZm9yIE1JTl9TVFJF QU1fREFUQSDigJMgbWFueSBwYXJ0aWFsbHktcmVsaWFibGUgc3RyZWFtcywgZWFjaCBjYXJyeWlu ZyAxLWJ5dGUgbWVzc2FnZXMsIHdpdGggZWFjaCBuZXcgbWVzc2FnZSBleHBpcmluZyBhbGwgZWFy bGllciBtZXNzYWdlcywgb3ZlciBhIGhpZ2gtbG9zcyBjb25uZWN0aW9uLiAgSW4gdGhpcyBjYXNl LCB0aGUgY29zdCBvZiBNSU5fU1RSRUFNX0RBVEEgY291bGQgYXBwcm9hY2ggNTAlIG9mIHRoZSBj b3N0IG9mIHRoZSBvdGhlciBmcmFtZXMgKDkgYnl0ZXMgZm9yIFNUUkVBTSArIHNvbWUgQUNLcyB2 cyA1IGJ5dGVzIGZvciBNSU5fU1RSRUFNX0RBVEEgZnJhbWVzKS4NCg0KWW91IHJlbW92ZSBhbnkg b2YgdGhlIGNvbmRpdGlvbnMgYWJvdmUsIGFuZCBNSU5fU1RSRUFNX0RBVEEgY29zdCBkcm9wIG9m ZiByYXBpZGx5Og0KDQogICogICBGZXcgcGFydGlhbGx5LXJlbGlhYmxlIHN0cmVhbXM6IGVpdGhl ciBtdWx0aXBsZSBtZXNzYWdlcyBnZXQgY29uc29saWRhdGVkIGludG8gYSBzaW5nbGUgU1RSRUFN IGZyYW1lIChyZXF1aXJpbmcgYSBzaW5nbGUgTV9TX0QgZnJhbWUgdG8gZXhwaXJlKSBvciB0aGUg b3ZlcmhlYWQgb2YgdGhlIFFVSUMgcGFja2V0IGl0c2VsZiAoTUFDK0lQK1VEUCtRVUlDIGhlYWRl cnMpIHN0YXJ0cyB0byBkb21pbmF0ZSBkcmFtYXRpY2FsbHkuDQogICogICBNdWx0aS1ieXRlIG1l c3NhZ2VzOiBTVFJFQU0gZnJhbWVzIGFyZSBsYXJnZXIsIHNvIE1fU19EIGZyYW1l4oCZcyBwcm9w b3J0aW9uIGlzIHNtYWxsZXINCiAgKiAgIE5ldyBtZXNzYWdlcyBleHBpcmluZyBOT1QgYWxsIGVh cmxpZXIgbWVzc2FnZXM6IG1vcmUgY2hhbmNlIGZvciB0aGUgbmV0d29yayB0byByZXRyYW5zbWl0 IGxvc3QgbWVzc2FnZXMsIHJlZHVjaW5nIGhvdyBvZnRlbiBNX1NfRCBpcyBzZW50Lg0KICAqICAg TG93LWxvc3MgY29ubmVjdGlvbjogZmV3IHBhY2tldHMgYXJlIGxvc3QsIHNvIGZldyBNX1NfRCBm cmFtZXMgbmVlZCBzZW5kaW5nLg0KDQrigJxQYXJ0aWFsbHkgcmVsaWFibGXigJ0gaXMgbm90IOKA nHVucmVsaWFibGXigJ0uICBUaGUgdHJhbnNwb3J0IHN0aWxsIHByb3ZpZGVzIG1lc3NhZ2UgYXRv bWljaXR5IGFuZCBvcmRlcmluZyBndWFyYW50ZWVzLCBpbiBhZGRpdGlvbiB0byByZXRyYW5zbWlz c2lvbiBvZiDigJxzdGlsbCBjdXJyZW504oCdIGRhdGEuDQoNCklmIHlvdSB3YW50IGNvbXBsZXRl bHkgdW5yZWxpYWJsZSAobGlrZSBVRFApLCB5b3UgbWF5IHdhbnQgc29tZXRoaW5nIHNsaWdodGx5 IGRpZmZlcmVudC4gIEZvciBleGFtcGxlLCB3ZSBtYXkgZGVjaWRlIHRoYXQgaXMgdGhlIGZpcnN0 IFNUUkVBTSBoYXMgT0ZGPTEgYW5kIE9mZnNldD0wLCB0aGlzIGludHJvZHVjZXMgYSDigJxjb21w bGV0ZWx5IHVucmVsaWFibGXigJ0gc3RyZWFtLiAgTm8gcmV0cmFuc21pc3Npb25zIGFyZSBleHBl Y3RlZCBhdCBhbGwuICBIb3dldmVyLCB5b3Ugc3RpbGwgd2FudCB0byBkbyBzb21ldGhpbmcgZm9y IGZsb3cgY29udHJvbCAoeW91IG5lZWQgdG8gcGVyaW9kaWNhbGx5IHN5bmNocm9uaXplIHlvdXIg c3RyZWFtIGFuZCBjb25uZWN0aW9uIGZsb3cgY29udHJvbCkuICBNYXliZSwgaWYgeW91ciB1bnJl bGlhYmxlIHN0cmVhbSB3ZW50IGlkbGUgd2l0aCB0aGUgbGFzdCB0cmFuc21pc3Npb24gdW5hY2tu b3dsZWRnZWQsIHlvdSBjb3VsZCBzZW5kIGEgU1RSRUFNIGZyYW1lIHdpdGggTEVOPTEsIExlbmd0 aD0wLCBhbmQgT0ZGPTEsIE9mZnNldD1jdXJyZW50X3N0cmVhbV9vZmZzZXQuDQoNCklmIHlvdSBs aWtlIHRoaXMsIEkgY2FuIHdyaXRlIHRoaXMgaW4gYSBkcmFmdC4NCg0KDQogICogICBJZ29yDQoN Cg0KRnJvbTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWls LmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAyMDE3IDEyOjE1IFBNDQpUbzogTHVj YXMgUGFyZHVlIDxsdWNhcy5wYXJkdWVAYmJjLmNvLnVrPjsgTHViYXNoZXYsIElnb3IgPGlsdWJh c2hlQGFrYW1haS5jb20+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSRTogZHJhZnQtbHViYXNo ZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5DQoNCkkgdGhpbmsgdGhpcyBwcm9wb3NhbCBsYXJn ZWx5IG1ha2VzIGdvb2Qgc2Vuc2UuDQoNCkJlIGRlZmF1bHQgbm8gTUlOX1NUUkVBTV9EQVRBIGZy YW1lIGlzIHNlbnQgd2hpY2ggaXMgdGhlbiB0aGUgY3VycmVudCBzdHJlYW0gYmVoYXZpb3VyLg0K QW55IGFwcGxpY2F0aW9uIHByb3RvY29sIGNhbiBkZWZpbmUgaXRzIG93biBydWxlcyBhYm91dCB3 aGljaCBzdHJlYW1zIGNhbiBiZWhhdmUgcGFydGlhbGx5IHJlbGlhYmxlLg0KDQpBIGNvdW50ZXIg YXJndW1lbnQgaXMgdGhhdCBRVUlDIGV4cGxpY2l0bHkgZGlzdGluZ3Vpc2hlcyBiZXR3ZWVuIHVu aS0gYW5kIGJpLWRpcmVjdGlvbmFsIHN0cmVhbXMsIHNvIHdoeSBub3QgYmV0d2VlbiBwYXJ0aWFs LSBhbmQgZnVsbHkgcmVsaWFibGUgc3RyZWFtcz8gVGhlIGFuc3dlciBtaWdodCBiZSB0aGF0IHVu aS0gc3RyZWFtcyBjYW4gY2xvc2Ugc3RhdGUgZWFybHksIHdoaWxlIHRoZXJlIGlzIG5vIHNpbWls YXIgY29uY2VybiBmb3IgcGFydGlhbCByZWxpYWJpbGl0eS4NCg0KQW5vdGhlciBjb25jZXJuIGlz IHRpbWUtYmFzZWQgcGFydGlhbCByZWxpYWJpbGl0eS4gSWYgZGF0YSBpcyBvbGQsIGRvbuKAmXQg cmV0cmFuc21pdCByZWdhcmRsZXNzLiBCdXQgYW4gYXBwbGljYXRpb24gcHJvdG9jb2wgY2FuIGhh bmRsZSB0aGlzLg0KDQpNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBzZW5kaW5nIE1JTl9GUkFNRV9E QVRBIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGggbG90cyBvZiB0aW55IG1lc3Nh Z2VzIHdoZXJlIHlvdSBvbmx5IGNhcmUgYWJvdXQsIHNheSwgdGhlIGxhc3QgdGhyZWUgMSBieXRl IG1lc3NhZ2VzIHNlbnQgKGhvcGluZyBhdCBsZWFzdCBvbmUgZ2V0cyB0aHJvdWdoKS4gVGhlIE1J Tl9GUkFNRV9EQVRBIGNvdWxkIGJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIG1lc3NhZ2VzIGZvcmNp bmcgbGVzcyBmcmVxdWVudCB0cmFmZmljLiBPZiBjb3Vyc2UsIGxvY2FsbHkgeW91IGNhbiBoYXZl IHlvdSBvd24gcnVsZXMsIGFuZCBqdXN0IHBlcmlvZGljYWxseSB1cGRhdGUgTUlOX0ZSQU1FX0RB VEEsIGJ1dCB0aGlzIGlzIGEgYml0IG9kZC4NCg0KQSB2YXJpYXRpb24gb2YgdGhlIGNvbmNlcHQg Y291bGQgYmUgc2VuZGluZyBNSU5fRlJBTUVfREFUQSBhcyBhIGRlbHRhIHRvIG1vc3QgcmVjZW50 OiBuZXZlciBleHBlY3QgbW9yZSB0aGFuIFggYnl0ZXMgb2xkZXIgdGhhbiBtb3N0IHJlY2VudGx5 IHNlZW4sIGJ1dCB0aGF0IGFsc28gaGFzIGl0IGlzc3VlcyB3aGVuIG1lc3NhZ2VzIGFyZSB2YXJp YWJsZSBsZW5ndGguDQoNCg0KQXMgdG8gY2xpZW50IHZzIHNlcnZlciBhc3ltbWV0cmk6IEl0IHN0 cm9uZ2x5IHN1Z2dlc3Qgbm90IHRvIG1ha2UgYSBkaXN0aW5jdGlvbiBoZXJlIGJlY2F1c2UgdGhl cmUgYXJlIG1hbnkgc3ltbWV0cmljIHBlZXIgdG8gcGVlciB1c2UgY2FzZXMgYW5kIGFsc28gb3Bw b3NpdGUgY2FzZXM6IHNlcnZlciB0byBjbGllbnQgd2l0aCBwYXJ0aWFsbHkgcmVsaWFibGUgdmlk ZW8sIGNsaWVudCB0byBzZXJ2ZXIgd2l0aCBwYXJ0aWFsbHkgcmVsaWFibGUgZ2FtZSBzdGF0ZSwg c2VydmVyIHRvIHNlcnZlciB3aXRoIHBhcnRpYWxseSByZWxpYWJsZSBnb3NzaXAgcHJvdG9jb2wg dG8gc3RhdGlzdGljYWxseSBhZHZhbmNlIGEgY29tbW9uIHN0YXRlIChlLmcuICJJIGhhdmUgcHJv Y2Vzc2VkIHNvIG1hbnkgYnl0ZXMgbm93LCBob3cgYWJvdXQgeW91P+KAnSkuDQoNCg0KS2luZCBS ZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDE5IERlY2VtYmVyIDIw MTcgYXQgMTYuNDcuMDgsIEx1Y2FzIFBhcmR1ZSAobHVjYXMucGFyZHVlQGJiYy5jby51azxtYWls dG86bHVjYXMucGFyZHVlQGJiYy5jby51az4pIHdyb3RlOg0KSWdvciB3cm90ZToNCg0KVGhlIGJv b2trZWVwaW5nIGlzIHNpbXBsZSBlbm91Z2ggYW5kIHRoZSBydW50aW1lIHJlc291cmNlcyByZXF1 aXJlZCBpcyBqdXN0IG9uZSB1aW50NjRfdCBwZXIgc3RlYW0sIHNvIEkgZG8gbm90IHNlZSBhIHBy b2JsZW0gZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuDQpVbHRpbWF0ZWx5LCBwYXJ0aWFsIHJlbGlh YmlsaXR5IGlzIGEgZmVhdHVyZSB0aGF0IGFuIGFwcGxpY2F0aW9uIGVpdGhlciBuZWVkcyBvciBk b2VzIG5vdC4gSWYgYW4gYXBwbGljYXRpb24gbmVlZHMgaXQsIGl0IG1vc3QgbGlrZWx5IHJlcXVp cmVzIGl0LiBJbiBhbnkgY2FzZSwgYW4gYXBwbGljYXRpb24gY2FuIGRvIGl0cyBvd24gbmVnb3Rp YXRpb24gaWYgaXQgZGVzaXJlcyB0byBkbyBzby4gRm9yIGV4YW1wbGUsIGl0IGNhbiB1c2Ugc3Ry ZWFtIDEgZm9yIHRoYXQuDQpOb3cgSSB1bmRlcnN0YW5kIHRoaXMgaXMgY29ubmVjdGlvbi13aWRl LCBJIGdlbmVyYWxseSBhZ3JlZS4gSG93ZXZlciwgZm9yIHNvbWV0aGluZyBsaWtlIGNvbnZlbnRp b25hbCBIVFRQL1FVSUMsIHRoZSByZWxpYWJsZSBndWFyYW50ZWUgYXNzdXJhbmNlcyBhcmUgcmVx dWlyZWQgYnkgdGhlIG1hcHBpbmcuIElmIHBhcnRpYWwgcmVsaWFiaWxpdHkgaXMgZGVmYXVsdCBl bmFibGVkIHRyYW5zcG9ydCBmZWF0dXJlLCBhcHBsaWNhdGlvbnMgbGlrZSBIVFRQL1FVSUMgbXVz dCByZXN0cmljdCBvciBkaXNhYmxlIGl0IOKAkyBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgZWRpdG9y cy9kcmFmdHMgaGF2ZSBicm9hY2hlZCB0aGF0IHN1YmplY3QgeWV0IChJ4oCZdmUgY2VydGFpbmx5 IGhhZCBzb21lIGZlZWRiYWNrIG9uIG15IGRyYWZ0IGFib3V0IHN1Y2ggcmVzdHJpY3Rpb25zKS4N Cg0KSSBkaWQgbm90IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGxhc3QgcXVlc3Rpb24uIEFyZSB5b3Ug YXNraW5nIHdoZXRoZXIgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBjb25uZWN0aW9uIHRvIG5lZ290 aWF0ZSBqdXN0IGEgc2luZ2xlIHN0cmVhbSAoaW4gZWFjaCBkaXJlY3Rpb24pIHRoYXQgd291bGQg YmUgcGFydGlhbGx5IHJlbGlhYmxlIGFuZCwgdGhlcmVmb3JlLCBub3Qgc2VuZCBhIHN0cmVhbSBp ZCB3aXRoIE1JTl9TVFJFQU1fREFUQT8gSSBjb3VsZCBhY3R1YWxseSB0aGluayBvZiBhIHZlcnNp b24gb2YgTUlOX1NUUkVBTV9EQVRBIHRoYXQgaGFzIGFuIGltcGxpZWQgc3RyZWFtIGlkIC0tIHRo ZSBzdHJlYW0gaWQgb2YgYSBwcmlvci9mb2xsb3dpbmcgU1RSRUFNIGZyYW1lIGluIHRoZSBzYW1l IHBhY2tldC4gVGhhdCB3b3VsZCBiZSBhbiBvcHRpbWl6YXRpb24gdGhhdCBJIGFtIGhhcHB5IHRv IGFkZCwgaWYgdGhlcmUgaXMgZW5vdWdoIHN1cHBvcnQgZm9yIGl0Lg0KDQpBcG9sb2dpZXMsIEkg aGFkbuKAmXQgZHJ1bmsgYW55IGNvZmZlZSB3aGVuIGZpcnN0IHJlcGx5aW5nIGFuZCBnb3QgbXlz ZWxmIGNvbmZ1c2VkLiBBbGwgUVVJQyBmcmFtZXMgb2YgdGhpcyBuYXR1cmUgc2hvdWxkIG5vcm1h bGx5IGluY2x1ZGUgYSBTdHJlYW0gSUQsIHdoaWNoIGlkZW50aWZpZXMgdGhlIHN0cmVhbSBpdCBp cyBzZW50IG9uLiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiByZWxpZXMgb24gc2VyaWFsIG9yZGVy aW5nL3Byb2Nlc3NpbmcgKGV2ZW4gaW5zaWRlIGEgcGFja2V0KSwgd2hpY2ggbWlnaHQgYmUgYSBo YXJkIHNlbGwuDQoNClNlcGFyYXRlbHksIGluIHRlcm1zIG9mIGFzeW1tZXRyeSwgSSB3YXMgdGhp bmtpbmcgdGhhdCB5b3UgbWlnaHQgYWx3YXlzIHdhbnQgKGFzIGEgcG9saWN5KSBjbGllbnRzIHRv IHRyYW5zbWl0IHdpdGggZnVsbCByZWxpYWJpbGl0eSBidXQgcHJvdmlkZSBkYXRhIHRvIHRoZW0g d2l0aCBwYXJ0aWFsIHJlbGlhYmlsaXR5LiBJIHRoaW5rIHRoaXMgaXMgYWdhaW4gYW4gYXBwbGlj YXRpb24gbWFwcGluZyBjb25jZXJuLg0KDQpSZWdhcmRzLA0KTHVjYXMNCg0K --_000_49797640bd7444f39b51a7595ee53c72usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJIZWx2ZXRpY2EgTmV1ZSI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9u DQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjQ5OTAwMzE1MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6NTAyNzk0ODY0IDE5MDg2NzI1MzAgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo5Ow0KCW1zby1sZXZlbC1udW1i 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 CXttc28tbGlzdC1pZDoxMDQyNzA0Njg0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo4NDQyOTg1MjIgNTE2MzU0NjUyIDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6OTsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3Qt aWQ6MTk3ODQ5MjI1NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTIwNDExNzU3NTAgLTIxMjQyNzg0NjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo5Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZh bWlseTpIZWx2ZXRpY2E7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QW5vdGhl ciBjb25jZXJuIGlzIHRpbWUtYmFzZWQgcGFydGlhbCByZWxpYWJpbGl0eS4gSWYgZGF0YSBpcyBv bGQsIGRvbuKAmXQgcmV0cmFuc21pdCByZWdhcmRsZXNzLiBCdXQgYW4gYXBwbGljYXRpb24NCiBw cm90b2NvbCBjYW4gaGFuZGxlIHRoaXM8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlllcywgdGhpcyBpcyBhbiBhcHBsaWNhdGlvbiBjb25jZXJuLCBzaW5jZSBvbmx5IHRoZSBh cHBsaWNhdGlvbiBjYW4ga25vdyB3aGF0IOKAnG9sZOKAnSBtZWFucy4mbmJzcDsgQWxzbywgc2lu Y2UNCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5NSU5fRlJBTUVfREFUQTwvc3Bhbj4gJm5ic3A7ZnJhbWUg aXMgZW1pdHRlZCBPTkxZIGlmIHNvbWUgZXhwaXJlZCBzdHJlYW0gZGF0YSBpcyBsb3N0IChub3Qg QUNLZWQpLCB5b3Ugd291bGQgbm90IGV4cGVjdCB0byBzZWUgbWFueSBzdWNoIGZyYW1lcyBvbiB0 aGUgd2lyZSwgZXZlbiBpZiBtZXNzYWdlcyBrZWVwIGV4cGlyaW5nIGFsbCB0aGUNCiB0aW1lLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+TXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgc2VuZGluZyBNSU5fRlJBTUVfREFU QSBbc2ljOiBNSU5fU1RSRUFNX0RBVEFdIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdp dGggbG90cyBvZiB0aW55DQogbWVzc2FnZXMgd2hlcmUgeW91IG9ubHkgY2FyZSBhYm91dCwgc2F5 LCB0aGUgbGFzdCB0aHJlZSAxIGJ5dGUgbWVzc2FnZXMgc2VudCAoaG9waW5nIGF0IGxlYXN0IG9u ZSBnZXRzIHRocm91Z2gpLiBUaGUgTUlOX0ZSQU1FX0RBVEEgY291bGQgYmUgbXVjaCBsYXJnZXIg dGhhbiB0aGUgbWVzc2FnZXM8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgaXMgdGhlIG1vc3QgZXhwZW5zaXZlIGNhc2UgZm9yIDxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCk1J Tl9TVFJFQU1fREFUQSDigJMgbWFueSBwYXJ0aWFsbHktcmVsaWFibGUgc3RyZWFtcywgZWFjaCBj YXJyeWluZyAxLWJ5dGUgbWVzc2FnZXMsIHdpdGggZWFjaCBuZXcgbWVzc2FnZSBleHBpcmluZyBh bGwgZWFybGllciBtZXNzYWdlcywgb3ZlciBhIGhpZ2gtbG9zcyBjb25uZWN0aW9uLiZuYnNwOyBJ biB0aGlzIGNhc2UsIHRoZSBjb3N0IG9mIE1JTl9TVFJFQU1fREFUQSBjb3VsZCBhcHByb2FjaCA1 MCUgb2YgdGhlIGNvc3Qgb2YgdGhlIG90aGVyIGZyYW1lcw0KICg5IGJ5dGVzIGZvciBTVFJFQU0g JiM0Mzsgc29tZSBBQ0tzIHZzIDUgYnl0ZXMgZm9yIE1JTl9TVFJFQU1fREFUQSBmcmFtZXMpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+WW91IHJlbW92ZSBhbnkgb2YgdGhlIGNvbmRpdGlvbnMgYWJvdmUs IGFuZCBNSU5fU1RSRUFNX0RBVEEgY29zdCBkcm9wIG9mZiByYXBpZGx5OjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwy IGxldmVsMSBsZm8yIj5GZXcgcGFydGlhbGx5LXJlbGlhYmxlIHN0cmVhbXM6IGVpdGhlciBtdWx0 aXBsZSBtZXNzYWdlcyBnZXQgY29uc29saWRhdGVkIGludG8gYSBzaW5nbGUgU1RSRUFNIGZyYW1l IChyZXF1aXJpbmcgYSBzaW5nbGUNCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NX1NfRCBmcmFtZTwvc3Bh bj4gdG8gZXhwaXJlKSBvciB0aGUgb3ZlcmhlYWQgb2YgdGhlIFFVSUMgcGFja2V0IGl0c2VsZiAo TUFDJiM0MztJUCYjNDM7VURQJiM0MztRVUlDIGhlYWRlcnMpIHN0YXJ0cyB0byBkb21pbmF0ZSBk cmFtYXRpY2FsbHkuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPk11bHRpLWJ5dGUgbWVzc2FnZXM6IFNUUkVBTSBmcmFtZXMgYXJlIGxhcmdlciwg c28gTV9TX0QgZnJhbWXigJlzIHByb3BvcnRpb24gaXMgc21hbGxlcjwvc3Bhbj48bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwyIGxldmVsMSBsZm8yIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TmV3IG1lc3NhZ2Vz IGV4cGlyaW5nIE5PVCBhbGwgZWFybGllciBtZXNzYWdlczogbW9yZSBjaGFuY2UgZm9yIHRoZSBu ZXR3b3JrIHRvIHJldHJhbnNtaXQgbG9zdCBtZXNzYWdlcywgcmVkdWNpbmcNCiBob3cgb2Z0ZW4g TV9TX0QgaXMgc2VudC48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+ TG93LWxvc3MgY29ubmVjdGlvbjogZmV3IHBhY2tldHMgYXJlIGxvc3QsIHNvIGZldw0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPk1fU19EIGZyYW1lcyBuZWVkIHNlbmRpbmcuPC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxQYXJ0aWFsbHkgcmVsaWFibGXigJ0gaXMgbm90IOKAnHVu cmVsaWFibGXigJ0uJm5ic3A7IFRoZSB0cmFuc3BvcnQgc3RpbGwgcHJvdmlkZXMgbWVzc2FnZSBh dG9taWNpdHkgYW5kIG9yZGVyaW5nIGd1YXJhbnRlZXMsIGluIGFkZGl0aW9uIHRvIHJldHJhbnNt aXNzaW9uIG9mIOKAnHN0aWxsIGN1cnJlbnTigJ0gZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgeW91IHdhbnQgY29tcGxldGVseSB1bnJlbGlhYmxlIChsaWtlIFVEUCksIHlvdSBtYXkg d2FudCBzb21ldGhpbmcgc2xpZ2h0bHkgZGlmZmVyZW50LiZuYnNwOyBGb3IgZXhhbXBsZSwgd2Ug bWF5IGRlY2lkZSB0aGF0IGlzIHRoZSBmaXJzdCBTVFJFQU0gaGFzDQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjojMzMzMzMzIj5PRkY9MSBhbmQgT2Zmc2V0PTA8L3NwYW4+LCB0aGlzIGludHJvZHVjZXMgYSDi gJxjb21wbGV0ZWx5IHVucmVsaWFibGXigJ0gc3RyZWFtLiZuYnNwOyBObyByZXRyYW5zbWlzc2lv bnMgYXJlIGV4cGVjdGVkIGF0IGFsbC4mbmJzcDsgSG93ZXZlciwgeW91IHN0aWxsIHdhbnQgdG8g ZG8gc29tZXRoaW5nIGZvciBmbG93IGNvbnRyb2wgKHlvdSBuZWVkDQogdG8gcGVyaW9kaWNhbGx5 IHN5bmNocm9uaXplIHlvdXIgc3RyZWFtIGFuZCBjb25uZWN0aW9uIGZsb3cgY29udHJvbCkuJm5i c3A7IE1heWJlLCBpZiB5b3VyIHVucmVsaWFibGUgc3RyZWFtIHdlbnQgaWRsZSB3aXRoIHRoZSBs YXN0IHRyYW5zbWlzc2lvbiB1bmFja25vd2xlZGdlZCwgeW91IGNvdWxkIHNlbmQgYSBTVFJFQU0g ZnJhbWUgd2l0aCBMRU49MSwgTGVuZ3RoPTAsIGFuZCBPRkY9MSwgT2Zmc2V0PWN1cnJlbnRfc3Ry ZWFtX29mZnNldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGxpa2UgdGhpcywgSSBj YW4gd3JpdGUgdGhpcyBpbiBhIGRyYWZ0LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgMTI6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+ IEx1Y2FzIFBhcmR1ZSAmbHQ7bHVjYXMucGFyZHVlQGJiYy5jby51ayZndDs7IEx1YmFzaGV2LCBJ Z29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogZHJhZnQtbHViYXNoZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIHRoaXMgcHJvcG9zYWwgbGFyZ2Vs eSBtYWtlcyBnb29kIHNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5C ZSBkZWZhdWx0IG5vIE1JTl9TVFJFQU1fREFUQSBmcmFtZSBpcyBzZW50IHdoaWNoIGlzIHRoZW4g dGhlIGN1cnJlbnQgc3RyZWFtIGJlaGF2aW91ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkFueSBhcHBsaWNhdGlvbiBwcm90b2NvbCBjYW4gZGVmaW5lIGl0cyBv d24gcnVsZXMgYWJvdXQgd2hpY2ggc3RyZWFtcyBjYW4gYmVoYXZlIHBhcnRpYWxseSByZWxpYWJs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QSBjb3VudGVyIGFyZ3VtZW50 IGlzIHRoYXQgUVVJQyBleHBsaWNpdGx5IGRpc3Rpbmd1aXNoZXMgYmV0d2VlbiB1bmktIGFuZCBi aS1kaXJlY3Rpb25hbCBzdHJlYW1zLCBzbyB3aHkgbm90IGJldHdlZW4gcGFydGlhbC0gYW5kIGZ1 bGx5IHJlbGlhYmxlIHN0cmVhbXM/IFRoZSBhbnN3ZXIgbWlnaHQNCiBiZSB0aGF0IHVuaS0gc3Ry ZWFtcyBjYW4gY2xvc2Ugc3RhdGUgZWFybHksIHdoaWxlIHRoZXJlIGlzIG5vIHNpbWlsYXIgY29u Y2VybiBmb3IgcGFydGlhbCByZWxpYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QW5vdGhlciBjb25jZXJuIGlzIHRpbWUtYmFzZWQgcGFydGlhbCByZWxpYWJpbGl0 eS4gSWYgZGF0YSBpcyBvbGQsIGRvbuKAmXQgcmV0cmFuc21pdCByZWdhcmRsZXNzLiBCdXQgYW4g YXBwbGljYXRpb24gcHJvdG9jb2wgY2FuIGhhbmRsZSB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5NeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBzZW5kaW5nIE1JTl9GUkFN RV9EQVRBIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGggbG90cyBvZiB0aW55IG1l c3NhZ2VzIHdoZXJlIHlvdSBvbmx5IGNhcmUgYWJvdXQsIHNheSwgdGhlIGxhc3QgdGhyZWUgMSBi eXRlIG1lc3NhZ2VzIHNlbnQNCiAoaG9waW5nIGF0IGxlYXN0IG9uZSBnZXRzIHRocm91Z2gpLiBU aGUgTUlOX0ZSQU1FX0RBVEEgY291bGQgYmUgbXVjaCBsYXJnZXIgdGhhbiB0aGUgbWVzc2FnZXMg Zm9yY2luZyBsZXNzIGZyZXF1ZW50IHRyYWZmaWMuIE9mIGNvdXJzZSwgbG9jYWxseSB5b3UgY2Fu IGhhdmUgeW91IG93biBydWxlcywgYW5kIGp1c3QgcGVyaW9kaWNhbGx5IHVwZGF0ZSBNSU5fRlJB TUVfREFUQSwgYnV0IHRoaXMgaXMgYSBiaXQgb2RkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5BIHZhcmlhdGlvbiBvZiB0aGUgY29uY2VwdCBjb3VsZCBiZSBzZW5kaW5nIE1J Tl9GUkFNRV9EQVRBIGFzIGEgZGVsdGEgdG8gbW9zdCByZWNlbnQ6IG5ldmVyIGV4cGVjdCBtb3Jl IHRoYW4gWCBieXRlcyBvbGRlciB0aGFuIG1vc3QgcmVjZW50bHkgc2VlbiwgYnV0IHRoYXQgYWxz byBoYXMgaXQgaXNzdWVzDQogd2hlbiBtZXNzYWdlcyBhcmUgdmFyaWFibGUgbGVuZ3RoLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRvIGNsaWVudCB2cyBzZXJ2ZXIgYXN5bW1ldHJp OiBJdCBzdHJvbmdseSBzdWdnZXN0IG5vdCB0byBtYWtlIGEgZGlzdGluY3Rpb24gaGVyZSBiZWNh dXNlIHRoZXJlIGFyZSBtYW55IHN5bW1ldHJpYyBwZWVyIHRvIHBlZXIgdXNlIGNhc2VzIGFuZCBh bHNvIG9wcG9zaXRlIGNhc2VzOiBzZXJ2ZXINCiB0byBjbGllbnQgd2l0aCBwYXJ0aWFsbHkgcmVs aWFibGUgdmlkZW8sIGNsaWVudCB0byBzZXJ2ZXIgd2l0aCBwYXJ0aWFsbHkgcmVsaWFibGUgZ2Ft ZSBzdGF0ZSwgc2VydmVyIHRvIHNlcnZlciB3aXRoIHBhcnRpYWxseSByZWxpYWJsZSBnb3NzaXAg cHJvdG9jb2wgdG8gc3RhdGlzdGljYWxseSBhZHZhbmNlIGEgY29tbW9uIHN0YXRlIChlLmcuICZx dW90O0kgaGF2ZSBwcm9jZXNzZWQgc28gbWFueSBieXRlcyBub3csIGhvdyBhYm91dCB5b3U/4oCd KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3Np Z25fMTUxMzcwMzAxMTYzNjU4MTg4OCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWly bWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTkgRGVjZW1iZXIgMjAxNyBhdCAxNi40Ny4w OCwgTHVjYXMgUGFyZHVlICg8YSBocmVmPSJtYWlsdG86bHVjYXMucGFyZHVlQGJiYy5jby51ayI+ bHVjYXMucGFyZHVlQGJiYy5jby51azwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklnb3Igd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgYm9va2tlZXBpbmcgaXMgc2ltcGxl IGVub3VnaCBhbmQgdGhlIHJ1bnRpbWUgcmVzb3VyY2VzIHJlcXVpcmVkIGlzIGp1c3Qgb25lIHVp bnQ2NF90IHBlcg0KIHN0ZWFtLCBzbyBJIGRvIG5vdCBzZWUgYSBwcm9ibGVtIGZvciBjb25zdHJh aW5lZCBkZXZpY2VzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5VbHRpbWF0ZWx5LCBwYXJ0aWFsIHJlbGlhYmlsaXR5IGlz IGEgZmVhdHVyZSB0aGF0IGFuIGFwcGxpY2F0aW9uIGVpdGhlciBuZWVkcyBvciBkb2VzIG5vdC4g SWYNCiBhbiBhcHBsaWNhdGlvbiBuZWVkcyBpdCwgaXQgbW9zdCBsaWtlbHkgcmVxdWlyZXMgaXQu IEluIGFueSBjYXNlLCBhbiBhcHBsaWNhdGlvbiBjYW4gZG8gaXRzIG93biBuZWdvdGlhdGlvbiBp ZiBpdCBkZXNpcmVzIHRvIGRvIHNvLiBGb3IgZXhhbXBsZSwgaXQgY2FuIHVzZSBzdHJlYW0gMSBm b3IgdGhhdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Tm93IEkgdW5kZXJzdGFuZCB0aGlzIGlzIGNvbm5lY3Rpb24td2lkZSwgSSBn ZW5lcmFsbHkgYWdyZWUuIEhvd2V2ZXIsIGZvciBzb21ldGhpbmcgbGlrZSBjb252ZW50aW9uYWwN CiBIVFRQL1FVSUMsIHRoZSByZWxpYWJsZSBndWFyYW50ZWUgYXNzdXJhbmNlcyBhcmUgcmVxdWly ZWQgYnkgdGhlIG1hcHBpbmcuIElmIHBhcnRpYWwgcmVsaWFiaWxpdHkgaXMgZGVmYXVsdCBlbmFi bGVkIHRyYW5zcG9ydCBmZWF0dXJlLCBhcHBsaWNhdGlvbnMgbGlrZSBIVFRQL1FVSUMgbXVzdCBy ZXN0cmljdCBvciBkaXNhYmxlIGl0IOKAkyBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgZWRpdG9ycy9k cmFmdHMgaGF2ZSBicm9hY2hlZCB0aGF0IHN1YmplY3QgeWV0DQogKEnigJl2ZSBjZXJ0YWlubHkg aGFkIHNvbWUgZmVlZGJhY2sgb24gbXkgZHJhZnQgYWJvdXQgc3VjaCByZXN0cmljdGlvbnMpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBk aWQgbm90IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGxhc3QgcXVlc3Rpb24uIEFyZSB5b3UgYXNraW5n IHdoZXRoZXIgaXQgaXMgcG9zc2libGUgZm9yIHRoZQ0KIGNvbm5lY3Rpb24gdG8gbmVnb3RpYXRl IGp1c3QgYSBzaW5nbGUgc3RyZWFtIChpbiBlYWNoIGRpcmVjdGlvbikgdGhhdCB3b3VsZCBiZSBw YXJ0aWFsbHkgcmVsaWFibGUgYW5kLCB0aGVyZWZvcmUsIG5vdCBzZW5kIGEgc3RyZWFtIGlkIHdp dGggTUlOX1NUUkVBTV9EQVRBPyBJIGNvdWxkIGFjdHVhbGx5IHRoaW5rIG9mIGEgdmVyc2lvbiBv ZiBNSU5fU1RSRUFNX0RBVEEgdGhhdCBoYXMgYW4gaW1wbGllZCBzdHJlYW0gaWQgLS0gdGhlIHN0 cmVhbQ0KIGlkIG9mIGEgcHJpb3IvZm9sbG93aW5nIFNUUkVBTSBmcmFtZSBpbiB0aGUgc2FtZSBw YWNrZXQuIFRoYXQgd291bGQgYmUgYW4gb3B0aW1pemF0aW9uIHRoYXQgSSBhbSBoYXBweSB0byBh ZGQsIGlmIHRoZXJlIGlzIGVub3VnaCBzdXBwb3J0IGZvciBpdC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkFwb2xvZ2llcywgSSBoYWRu4oCZdCBkcnVuayBhbnkgY29mZmVlIHdoZW4g Zmlyc3QgcmVwbHlpbmcgYW5kIGdvdCBteXNlbGYgY29uZnVzZWQuIEFsbCBRVUlDIGZyYW1lcw0K IG9mIHRoaXMgbmF0dXJlIHNob3VsZCBub3JtYWxseSBpbmNsdWRlIGEgU3RyZWFtIElELCB3aGlj aCBpZGVudGlmaWVzIHRoZSBzdHJlYW0gaXQgaXMgc2VudCBvbi4gSSB0aGluayB5b3VyIHN1Z2dl c3Rpb24gcmVsaWVzIG9uIHNlcmlhbCBvcmRlcmluZy9wcm9jZXNzaW5nIChldmVuIGluc2lkZSBh IHBhY2tldCksIHdoaWNoIG1pZ2h0IGJlIGEgaGFyZCBzZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U2VwYXJhdGVseSwgaW4gdGVybXMgb2YgYXN5 bW1ldHJ5LCBJIHdhcyB0aGlua2luZyB0aGF0IHlvdSBtaWdodCBhbHdheXMgd2FudCAoYXMgYSBw b2xpY3kpIGNsaWVudHMNCiB0byB0cmFuc21pdCB3aXRoIGZ1bGwgcmVsaWFiaWxpdHkgYnV0IHBy b3ZpZGUgZGF0YSB0byB0aGVtIHdpdGggcGFydGlhbCByZWxpYWJpbGl0eS4gSSB0aGluayB0aGlz IGlzIGFnYWluIGFuIGFwcGxpY2F0aW9uIG1hcHBpbmcgY29uY2Vybi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkx1Y2FzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_49797640bd7444f39b51a7595ee53c72usma1exdag1mb5msgcorpak_-- From nobody Tue Dec 19 11:23: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 930891270AC for ; Tue, 19 Dec 2017 11:23:39 -0800 (PST) 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=gjvCEafu; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kvCladCp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IV_MZa-E40s for ; Tue, 19 Dec 2017 11:23:36 -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 5B16D1200F1 for ; Tue, 19 Dec 2017 11:23:36 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.21/8.16.0.21) with SMTP id vBJJInGm004085; Tue, 19 Dec 2017 11:23:29 -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=4gG7+ejKrjTU3j9KUioAhVJq9b+W4fLu5Vn/eLMGf2g=; b=gjvCEafuO97VymDMiCnrzvSzl/fX3B+RVJrr681en2JrItTN7Y52inwU33o4/UnwAVpi BMhRnQ3rD2KHSoEMke66RvwvGRJhunnBGlybJGhpjE3Pee1yHeYIEGS8qO0Y0JTVkOnI PFosGY4o+qenWQCuVaOf0/j4S5QRustsxMo= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2ey5yr8y96-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Dec 2017 11:23:29 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.20) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Dec 2017 11:23:27 -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=4gG7+ejKrjTU3j9KUioAhVJq9b+W4fLu5Vn/eLMGf2g=; b=kvCladCpmzeMjJZaLxc04+7VTSsak/6RkI66eRvon2O+2aVMWDxXqhQxOgmpt8h/qFx+JgX16jDECkbP/HK7ZQafol0okPd6BbaVetF5VDPCiEtc8IQovloPaD1okLhOecPfX+PTCenCrgZ73cjmihGrNJ+mnuRPD/SEPRBVKKQ= Received: from BN6PR15MB1876.namprd15.prod.outlook.com (10.174.239.136) by BN6PR15MB1874.namprd15.prod.outlook.com (10.174.239.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 19:23:25 +0000 Received: from BN6PR15MB1876.namprd15.prod.outlook.com ([10.174.239.136]) by BN6PR15MB1876.namprd15.prod.outlook.com ([10.174.239.136]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 19:23:25 +0000 From: Roberto Peon To: "Lubashev, Igor" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Lucas Pardue" , "quic@ietf.org" Subject: Re: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEAAGisaAAAO+5AD//3+1AA== Date: Tue, 19 Dec 2017 19:23:25 +0000 Message-ID: <47687CC1-2C78-451C-A9AD-3370FA4CA36B@fb.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> <49797640bd7444f39b51a7595ee53c72@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <49797640bd7444f39b51a7595ee53c72@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:c30f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR15MB1874; 20:UOZCKkEqfshLf6/nFDxoTQ6GZ+8Ek8J4j3l5gj8kii8fhuroAH1L9xtPMc8cNW5KbYTI54EAoD2rBRAshPAsQQbwjG/wUjxgYVTWcLcYz/K6iAa4uhiwlMkOMGQxeIRhE+emrOPyKenptpZLdL6lrOJ94Zxw2FgAdb/vi3EWmmk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 91958f5f-b4fb-469d-6bc9-08d54715f9b5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153057); SRVR:BN6PR15MB1874; x-ms-traffictypediagnostic: BN6PR15MB1874: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(127952516941037)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011); SRVR:BN6PR15MB1874; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR15MB1874; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(366004)(376002)(189003)(199004)(24454002)(8936002)(86362001)(230783001)(81166006)(6246003)(33656002)(97736004)(82746002)(7736002)(2950100002)(8676002)(105586002)(106356001)(316002)(68736007)(2900100001)(83716003)(81156014)(25786009)(110136005)(2501003)(6116002)(6486002)(5660300001)(102836003)(36756003)(6436002)(93886005)(2906002)(53946003)(3660700001)(53936002)(3280700002)(77096006)(229853002)(561944003)(39060400002)(478600001)(99286004)(76176011)(6506007)(14454004)(54896002)(53546011)(6306002)(59450400001)(236005)(6512007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1874; H:BN6PR15MB1876.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_47687CC12C78451CA9AD3370FA4CA36Bfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 91958f5f-b4fb-469d-6bc9-08d54715f9b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 19:23:25.0688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1874 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 19 Dec 2017 19:23:39 -0000 --_000_47687CC12C78451CA9AD3370FA4CA36Bfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgdGhlIEFQSSwgaW1wbGVtZW50YXRpb24sIGFuZCBwcm90b2NvbC4NCkFQSToNCkni gJlkIGJlIG5pY2UgdG8gaGF2ZSBhbiBBUEkgd2hpY2ggd291bGQgYWxsb3cgYXBwbGljYXRpb25z IHRvIGV4cHJlc3M6DQoNCjEpICAgICAgIERyb3AtZGVhZC10aW1lOiBUaGUgdGltZSBiZXlvbmQg d2hpY2ggdGhlIGRhdGEgaXMgbm90IHVzZWZ1bCB0byB0aGUgcmVjaXBpZW50DQoNCjIpICAgICAg IEV4cGFuc2lvbi1mYWN0b3I6IFRoZSBtYXhpbXVtIOKAmGV4cGFuc2lvbiBmYWN0b3LigJkgYWxs b3dlZCBmb3IgdGhlIGRhdGEgKGRvIEkgc2VuZCB0aGUgYnl0ZXMgMS4yICh+RkVDKSB0aW1lcywg MiB0aW1lcyAoZHVwbGljYXRlIHNlbmRzKT8pDQoNCjMpICAgICAgIFByaW9yaXR5OiBkdWgNCg0K SW1wbGVtZW50YXRpb246DQpJZiB0aGUgaW1wbGVtZW50YXRpb24gdG9vayBhbGwgb2YgdGhlIGFi b3ZlIGludG8gYWNjb3VudCwgaXQgbWlnaHQgZGVjaWRlIHRvIG5ldmVyIGF0dGVtcHQgdG8gc2Vu ZCBzb21lIGRhdGEsIGFzLCBnaXZlbiB0aGUgQlcgZXN0aW1hdGUgZmxvd2luZyBiYWNrIGZyb20g dGhlIGNvbmdlc3Rpb24tYXZvaWRhbmNlIGFsZ29yaXRobSwgaXQgd291bGQgbm90IGJlIHJlY2Vp dmVkIHdpdGhpbiB0aGUgZHJvcC1kZWFkLXRpbWUuIFRoaXMgd291bGQgYmV0dGVyIHVzZSB0aGUg YXZhaWxhYmxlIGJhbmR3aWR0aC4NCg0KUHJvdG9jb2w6DQpQcm90b2NvbC13aXNlLCB3ZSBjb3Vs ZCAgZGVsZWdhdGUgdGhlIHRyYW5zbWlzc2lvbiB0byBRVUlDIG9yIHNvbWUgb3RoZXIgaGlnaGVy LWxldmVsIGxheWVyLg0KSG93ZXZlciwgaWYgd2UgZGVsZWdhdGUgYXdheSBmcm9tIFFVSUMsIHRo ZSBwcm94aWVzIHdpbGwgYmUgcXVpdGUgdW5saWtlbHkgdG8gcGFydGljaXBhdGUgKG90aGVyIHRo YW4gcHJvY2Vzc2luZyBzdHJlYW0gY2FuY2VscykuIFRoaXMgd291bGQgYmUgc2FkIGdpdmVuIHRo ZSB3aWRlIGRlcGxveW1lbnQgb2YgcHJveGllcyAoaS5lLiByZXZlcnNlIHByb3hpZXMpIGluIENE TnMsIGV0Yy4NCg0KKysgb24gcGFydGlhbGx5IHJlbGlhYmxlICE9IHVucmVsaWFibGUuDQoNClRD UCwgYWZ0ZXIgYWxsLCBpcyDigJxqdXN04oCdIGEgcGFydGlhbGx5IHJlbGlhYmxlIHByb3RvY29s IHdpdGggbG9uZyBlbm91Z2ggdGltZW91dHMgdGhhdCB3ZSBkZWlnbiB0byBjYWxsIGl0IHJlbGlh YmxlIOKYug0KDQotPVINCg0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZUBha2FtYWkuY29tPg0KRGF0ZTog VHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgYXQgMTE6MDMgQU0NClRvOiBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+LCBMdWNhcyBQYXJkdWUgPGx1Y2FzLnBh cmR1ZUBiYmMuY28udWs+LCAicXVpY0BpZXRmLm9yZyIgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSRTogZHJhZnQtbHViYXNoZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5DQoNCg0KICAqICAg QW5vdGhlciBjb25jZXJuIGlzIHRpbWUtYmFzZWQgcGFydGlhbCByZWxpYWJpbGl0eS4gSWYgZGF0 YSBpcyBvbGQsIGRvbuKAmXQgcmV0cmFuc21pdCByZWdhcmRsZXNzLiBCdXQgYW4gYXBwbGljYXRp b24gcHJvdG9jb2wgY2FuIGhhbmRsZSB0aGlzDQoNClllcywgdGhpcyBpcyBhbiBhcHBsaWNhdGlv biBjb25jZXJuLCBzaW5jZSBvbmx5IHRoZSBhcHBsaWNhdGlvbiBjYW4ga25vdyB3aGF0IOKAnG9s ZOKAnSBtZWFucy4gIEFsc28sIHNpbmNlIE1JTl9GUkFNRV9EQVRBICBmcmFtZSBpcyBlbWl0dGVk IE9OTFkgaWYgc29tZSBleHBpcmVkIHN0cmVhbSBkYXRhIGlzIGxvc3QgKG5vdCBBQ0tlZCksIHlv dSB3b3VsZCBub3QgZXhwZWN0IHRvIHNlZSBtYW55IHN1Y2ggZnJhbWVzIG9uIHRoZSB3aXJlLCBl dmVuIGlmIG1lc3NhZ2VzIGtlZXAgZXhwaXJpbmcgYWxsIHRoZSB0aW1lLg0KDQoNCg0KICAqICAg TXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgc2VuZGluZyBNSU5fRlJBTUVfREFUQSBbc2ljOiBNSU5f U1RSRUFNX0RBVEFdIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGggbG90cyBvZiB0 aW55IG1lc3NhZ2VzIHdoZXJlIHlvdSBvbmx5IGNhcmUgYWJvdXQsIHNheSwgdGhlIGxhc3QgdGhy ZWUgMSBieXRlIG1lc3NhZ2VzIHNlbnQgKGhvcGluZyBhdCBsZWFzdCBvbmUgZ2V0cyB0aHJvdWdo KS4gVGhlIE1JTl9GUkFNRV9EQVRBIGNvdWxkIGJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIG1lc3Nh Z2VzDQoNClRoaXMgaXMgdGhlIG1vc3QgZXhwZW5zaXZlIGNhc2UgZm9yIE1JTl9TVFJFQU1fREFU QSDigJMgbWFueSBwYXJ0aWFsbHktcmVsaWFibGUgc3RyZWFtcywgZWFjaCBjYXJyeWluZyAxLWJ5 dGUgbWVzc2FnZXMsIHdpdGggZWFjaCBuZXcgbWVzc2FnZSBleHBpcmluZyBhbGwgZWFybGllciBt ZXNzYWdlcywgb3ZlciBhIGhpZ2gtbG9zcyBjb25uZWN0aW9uLiAgSW4gdGhpcyBjYXNlLCB0aGUg Y29zdCBvZiBNSU5fU1RSRUFNX0RBVEEgY291bGQgYXBwcm9hY2ggNTAlIG9mIHRoZSBjb3N0IG9m IHRoZSBvdGhlciBmcmFtZXMgKDkgYnl0ZXMgZm9yIFNUUkVBTSArIHNvbWUgQUNLcyB2cyA1IGJ5 dGVzIGZvciBNSU5fU1RSRUFNX0RBVEEgZnJhbWVzKS4NCg0KWW91IHJlbW92ZSBhbnkgb2YgdGhl IGNvbmRpdGlvbnMgYWJvdmUsIGFuZCBNSU5fU1RSRUFNX0RBVEEgY29zdCBkcm9wIG9mZiByYXBp ZGx5Og0KDQogICogICBGZXcgcGFydGlhbGx5LXJlbGlhYmxlIHN0cmVhbXM6IGVpdGhlciBtdWx0 aXBsZSBtZXNzYWdlcyBnZXQgY29uc29saWRhdGVkIGludG8gYSBzaW5nbGUgU1RSRUFNIGZyYW1l IChyZXF1aXJpbmcgYSBzaW5nbGUgTV9TX0QgZnJhbWUgdG8gZXhwaXJlKSBvciB0aGUgb3Zlcmhl YWQgb2YgdGhlIFFVSUMgcGFja2V0IGl0c2VsZiAoTUFDK0lQK1VEUCtRVUlDIGhlYWRlcnMpIHN0 YXJ0cyB0byBkb21pbmF0ZSBkcmFtYXRpY2FsbHkuDQogICogICBNdWx0aS1ieXRlIG1lc3NhZ2Vz OiBTVFJFQU0gZnJhbWVzIGFyZSBsYXJnZXIsIHNvIE1fU19EIGZyYW1l4oCZcyBwcm9wb3J0aW9u IGlzIHNtYWxsZXINCiAgKiAgIE5ldyBtZXNzYWdlcyBleHBpcmluZyBOT1QgYWxsIGVhcmxpZXIg bWVzc2FnZXM6IG1vcmUgY2hhbmNlIGZvciB0aGUgbmV0d29yayB0byByZXRyYW5zbWl0IGxvc3Qg bWVzc2FnZXMsIHJlZHVjaW5nIGhvdyBvZnRlbiBNX1NfRCBpcyBzZW50Lg0KICAqICAgTG93LWxv c3MgY29ubmVjdGlvbjogZmV3IHBhY2tldHMgYXJlIGxvc3QsIHNvIGZldyBNX1NfRCBmcmFtZXMg bmVlZCBzZW5kaW5nLg0KDQrigJxQYXJ0aWFsbHkgcmVsaWFibGXigJ0gaXMgbm90IOKAnHVucmVs aWFibGXigJ0uICBUaGUgdHJhbnNwb3J0IHN0aWxsIHByb3ZpZGVzIG1lc3NhZ2UgYXRvbWljaXR5 IGFuZCBvcmRlcmluZyBndWFyYW50ZWVzLCBpbiBhZGRpdGlvbiB0byByZXRyYW5zbWlzc2lvbiBv ZiDigJxzdGlsbCBjdXJyZW504oCdIGRhdGEuDQoNCklmIHlvdSB3YW50IGNvbXBsZXRlbHkgdW5y ZWxpYWJsZSAobGlrZSBVRFApLCB5b3UgbWF5IHdhbnQgc29tZXRoaW5nIHNsaWdodGx5IGRpZmZl cmVudC4gIEZvciBleGFtcGxlLCB3ZSBtYXkgZGVjaWRlIHRoYXQgaXMgdGhlIGZpcnN0IFNUUkVB TSBoYXMgT0ZGPTEgYW5kIE9mZnNldD0wLCB0aGlzIGludHJvZHVjZXMgYSDigJxjb21wbGV0ZWx5 IHVucmVsaWFibGXigJ0gc3RyZWFtLiAgTm8gcmV0cmFuc21pc3Npb25zIGFyZSBleHBlY3RlZCBh dCBhbGwuICBIb3dldmVyLCB5b3Ugc3RpbGwgd2FudCB0byBkbyBzb21ldGhpbmcgZm9yIGZsb3cg Y29udHJvbCAoeW91IG5lZWQgdG8gcGVyaW9kaWNhbGx5IHN5bmNocm9uaXplIHlvdXIgc3RyZWFt IGFuZCBjb25uZWN0aW9uIGZsb3cgY29udHJvbCkuICBNYXliZSwgaWYgeW91ciB1bnJlbGlhYmxl IHN0cmVhbSB3ZW50IGlkbGUgd2l0aCB0aGUgbGFzdCB0cmFuc21pc3Npb24gdW5hY2tub3dsZWRn ZWQsIHlvdSBjb3VsZCBzZW5kIGEgU1RSRUFNIGZyYW1lIHdpdGggTEVOPTEsIExlbmd0aD0wLCBh bmQgT0ZGPTEsIE9mZnNldD1jdXJyZW50X3N0cmVhbV9vZmZzZXQuDQoNCklmIHlvdSBsaWtlIHRo aXMsIEkgY2FuIHdyaXRlIHRoaXMgaW4gYSBkcmFmdC4NCg0KDQogICogICBJZ29yDQoNCg0KRnJv bTogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAyMDE3IDEyOjE1IFBNDQpUbzogTHVjYXMgUGFy ZHVlIDxsdWNhcy5wYXJkdWVAYmJjLmNvLnVrPjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFr YW1haS5jb20+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSRTogZHJhZnQtbHViYXNoZXYtcXVp Yy1wYXJ0aWFsLXJlbGlhYmlsaXR5DQoNCkkgdGhpbmsgdGhpcyBwcm9wb3NhbCBsYXJnZWx5IG1h a2VzIGdvb2Qgc2Vuc2UuDQoNCkJlIGRlZmF1bHQgbm8gTUlOX1NUUkVBTV9EQVRBIGZyYW1lIGlz IHNlbnQgd2hpY2ggaXMgdGhlbiB0aGUgY3VycmVudCBzdHJlYW0gYmVoYXZpb3VyLg0KQW55IGFw cGxpY2F0aW9uIHByb3RvY29sIGNhbiBkZWZpbmUgaXRzIG93biBydWxlcyBhYm91dCB3aGljaCBz dHJlYW1zIGNhbiBiZWhhdmUgcGFydGlhbGx5IHJlbGlhYmxlLg0KDQpBIGNvdW50ZXIgYXJndW1l bnQgaXMgdGhhdCBRVUlDIGV4cGxpY2l0bHkgZGlzdGluZ3Vpc2hlcyBiZXR3ZWVuIHVuaS0gYW5k IGJpLWRpcmVjdGlvbmFsIHN0cmVhbXMsIHNvIHdoeSBub3QgYmV0d2VlbiBwYXJ0aWFsLSBhbmQg ZnVsbHkgcmVsaWFibGUgc3RyZWFtcz8gVGhlIGFuc3dlciBtaWdodCBiZSB0aGF0IHVuaS0gc3Ry ZWFtcyBjYW4gY2xvc2Ugc3RhdGUgZWFybHksIHdoaWxlIHRoZXJlIGlzIG5vIHNpbWlsYXIgY29u Y2VybiBmb3IgcGFydGlhbCByZWxpYWJpbGl0eS4NCg0KQW5vdGhlciBjb25jZXJuIGlzIHRpbWUt YmFzZWQgcGFydGlhbCByZWxpYWJpbGl0eS4gSWYgZGF0YSBpcyBvbGQsIGRvbuKAmXQgcmV0cmFu c21pdCByZWdhcmRsZXNzLiBCdXQgYW4gYXBwbGljYXRpb24gcHJvdG9jb2wgY2FuIGhhbmRsZSB0 aGlzLg0KDQpNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBzZW5kaW5nIE1JTl9GUkFNRV9EQVRBIGNh biBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGggbG90cyBvZiB0aW55IG1lc3NhZ2VzIHdo ZXJlIHlvdSBvbmx5IGNhcmUgYWJvdXQsIHNheSwgdGhlIGxhc3QgdGhyZWUgMSBieXRlIG1lc3Nh Z2VzIHNlbnQgKGhvcGluZyBhdCBsZWFzdCBvbmUgZ2V0cyB0aHJvdWdoKS4gVGhlIE1JTl9GUkFN RV9EQVRBIGNvdWxkIGJlIG11Y2ggbGFyZ2VyIHRoYW4gdGhlIG1lc3NhZ2VzIGZvcmNpbmcgbGVz cyBmcmVxdWVudCB0cmFmZmljLiBPZiBjb3Vyc2UsIGxvY2FsbHkgeW91IGNhbiBoYXZlIHlvdSBv d24gcnVsZXMsIGFuZCBqdXN0IHBlcmlvZGljYWxseSB1cGRhdGUgTUlOX0ZSQU1FX0RBVEEsIGJ1 dCB0aGlzIGlzIGEgYml0IG9kZC4NCg0KQSB2YXJpYXRpb24gb2YgdGhlIGNvbmNlcHQgY291bGQg YmUgc2VuZGluZyBNSU5fRlJBTUVfREFUQSBhcyBhIGRlbHRhIHRvIG1vc3QgcmVjZW50OiBuZXZl ciBleHBlY3QgbW9yZSB0aGFuIFggYnl0ZXMgb2xkZXIgdGhhbiBtb3N0IHJlY2VudGx5IHNlZW4s IGJ1dCB0aGF0IGFsc28gaGFzIGl0IGlzc3VlcyB3aGVuIG1lc3NhZ2VzIGFyZSB2YXJpYWJsZSBs ZW5ndGguDQoNCg0KQXMgdG8gY2xpZW50IHZzIHNlcnZlciBhc3ltbWV0cmk6IEl0IHN0cm9uZ2x5 IHN1Z2dlc3Qgbm90IHRvIG1ha2UgYSBkaXN0aW5jdGlvbiBoZXJlIGJlY2F1c2UgdGhlcmUgYXJl IG1hbnkgc3ltbWV0cmljIHBlZXIgdG8gcGVlciB1c2UgY2FzZXMgYW5kIGFsc28gb3Bwb3NpdGUg Y2FzZXM6IHNlcnZlciB0byBjbGllbnQgd2l0aCBwYXJ0aWFsbHkgcmVsaWFibGUgdmlkZW8sIGNs aWVudCB0byBzZXJ2ZXIgd2l0aCBwYXJ0aWFsbHkgcmVsaWFibGUgZ2FtZSBzdGF0ZSwgc2VydmVy IHRvIHNlcnZlciB3aXRoIHBhcnRpYWxseSByZWxpYWJsZSBnb3NzaXAgcHJvdG9jb2wgdG8gc3Rh dGlzdGljYWxseSBhZHZhbmNlIGEgY29tbW9uIHN0YXRlIChlLmcuICJJIGhhdmUgcHJvY2Vzc2Vk IHNvIG1hbnkgYnl0ZXMgbm93LCBob3cgYWJvdXQgeW91P+KAnSkuDQoNCg0KS2luZCBSZWdhcmRz LA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDE5IERlY2VtYmVyIDIwMTcgYXQg MTYuNDcuMDgsIEx1Y2FzIFBhcmR1ZSAobHVjYXMucGFyZHVlQGJiYy5jby51azxtYWlsdG86bHVj YXMucGFyZHVlQGJiYy5jby51az4pIHdyb3RlOg0KSWdvciB3cm90ZToNCg0KVGhlIGJvb2trZWVw aW5nIGlzIHNpbXBsZSBlbm91Z2ggYW5kIHRoZSBydW50aW1lIHJlc291cmNlcyByZXF1aXJlZCBp cyBqdXN0IG9uZSB1aW50NjRfdCBwZXIgc3RlYW0sIHNvIEkgZG8gbm90IHNlZSBhIHByb2JsZW0g Zm9yIGNvbnN0cmFpbmVkIGRldmljZXMuDQpVbHRpbWF0ZWx5LCBwYXJ0aWFsIHJlbGlhYmlsaXR5 IGlzIGEgZmVhdHVyZSB0aGF0IGFuIGFwcGxpY2F0aW9uIGVpdGhlciBuZWVkcyBvciBkb2VzIG5v dC4gSWYgYW4gYXBwbGljYXRpb24gbmVlZHMgaXQsIGl0IG1vc3QgbGlrZWx5IHJlcXVpcmVzIGl0 LiBJbiBhbnkgY2FzZSwgYW4gYXBwbGljYXRpb24gY2FuIGRvIGl0cyBvd24gbmVnb3RpYXRpb24g aWYgaXQgZGVzaXJlcyB0byBkbyBzby4gRm9yIGV4YW1wbGUsIGl0IGNhbiB1c2Ugc3RyZWFtIDEg Zm9yIHRoYXQuDQpOb3cgSSB1bmRlcnN0YW5kIHRoaXMgaXMgY29ubmVjdGlvbi13aWRlLCBJIGdl bmVyYWxseSBhZ3JlZS4gSG93ZXZlciwgZm9yIHNvbWV0aGluZyBsaWtlIGNvbnZlbnRpb25hbCBI VFRQL1FVSUMsIHRoZSByZWxpYWJsZSBndWFyYW50ZWUgYXNzdXJhbmNlcyBhcmUgcmVxdWlyZWQg YnkgdGhlIG1hcHBpbmcuIElmIHBhcnRpYWwgcmVsaWFiaWxpdHkgaXMgZGVmYXVsdCBlbmFibGVk IHRyYW5zcG9ydCBmZWF0dXJlLCBhcHBsaWNhdGlvbnMgbGlrZSBIVFRQL1FVSUMgbXVzdCByZXN0 cmljdCBvciBkaXNhYmxlIGl0IOKAkyBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgZWRpdG9ycy9kcmFm dHMgaGF2ZSBicm9hY2hlZCB0aGF0IHN1YmplY3QgeWV0IChJ4oCZdmUgY2VydGFpbmx5IGhhZCBz b21lIGZlZWRiYWNrIG9uIG15IGRyYWZ0IGFib3V0IHN1Y2ggcmVzdHJpY3Rpb25zKS4NCg0KSSBk aWQgbm90IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGxhc3QgcXVlc3Rpb24uIEFyZSB5b3UgYXNraW5n IHdoZXRoZXIgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBjb25uZWN0aW9uIHRvIG5lZ290aWF0ZSBq dXN0IGEgc2luZ2xlIHN0cmVhbSAoaW4gZWFjaCBkaXJlY3Rpb24pIHRoYXQgd291bGQgYmUgcGFy dGlhbGx5IHJlbGlhYmxlIGFuZCwgdGhlcmVmb3JlLCBub3Qgc2VuZCBhIHN0cmVhbSBpZCB3aXRo IE1JTl9TVFJFQU1fREFUQT8gSSBjb3VsZCBhY3R1YWxseSB0aGluayBvZiBhIHZlcnNpb24gb2Yg TUlOX1NUUkVBTV9EQVRBIHRoYXQgaGFzIGFuIGltcGxpZWQgc3RyZWFtIGlkIC0tIHRoZSBzdHJl YW0gaWQgb2YgYSBwcmlvci9mb2xsb3dpbmcgU1RSRUFNIGZyYW1lIGluIHRoZSBzYW1lIHBhY2tl dC4gVGhhdCB3b3VsZCBiZSBhbiBvcHRpbWl6YXRpb24gdGhhdCBJIGFtIGhhcHB5IHRvIGFkZCwg aWYgdGhlcmUgaXMgZW5vdWdoIHN1cHBvcnQgZm9yIGl0Lg0KDQpBcG9sb2dpZXMsIEkgaGFkbuKA mXQgZHJ1bmsgYW55IGNvZmZlZSB3aGVuIGZpcnN0IHJlcGx5aW5nIGFuZCBnb3QgbXlzZWxmIGNv bmZ1c2VkLiBBbGwgUVVJQyBmcmFtZXMgb2YgdGhpcyBuYXR1cmUgc2hvdWxkIG5vcm1hbGx5IGlu Y2x1ZGUgYSBTdHJlYW0gSUQsIHdoaWNoIGlkZW50aWZpZXMgdGhlIHN0cmVhbSBpdCBpcyBzZW50 IG9uLiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiByZWxpZXMgb24gc2VyaWFsIG9yZGVyaW5nL3By b2Nlc3NpbmcgKGV2ZW4gaW5zaWRlIGEgcGFja2V0KSwgd2hpY2ggbWlnaHQgYmUgYSBoYXJkIHNl bGwuDQoNClNlcGFyYXRlbHksIGluIHRlcm1zIG9mIGFzeW1tZXRyeSwgSSB3YXMgdGhpbmtpbmcg dGhhdCB5b3UgbWlnaHQgYWx3YXlzIHdhbnQgKGFzIGEgcG9saWN5KSBjbGllbnRzIHRvIHRyYW5z bWl0IHdpdGggZnVsbCByZWxpYWJpbGl0eSBidXQgcHJvdmlkZSBkYXRhIHRvIHRoZW0gd2l0aCBw YXJ0aWFsIHJlbGlhYmlsaXR5LiBJIHRoaW5rIHRoaXMgaXMgYWdhaW4gYW4gYXBwbGljYXRpb24g bWFwcGluZyBjb25jZXJuLg0KDQpSZWdhcmRzLA0KTHVjYXMNCg0K --_000_47687CC12C78451CA9AD3370FA4CA36Bfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <6D9CE1EA9435EB46BF13DA63A1E4EE53@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJ cGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9u LCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9v bjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDk5MDAzMTUxOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MDI3OTQ4NjQgMTkwODY3MjUzMCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0Ojk7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LHNlcmlmO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjU4ODIwMDY4OTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNjc0NDY5NDY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0K CXttc28tbGlzdC1pZDo3MjA2NjYzNjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xMjc4MTY4NzA4IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlz dC1pZDoxMDQyNzA0Njg0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczo4NDQyOTg1MjIgNTE2MzU0NjUyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwzOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6OTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iixz ZXJpZjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwz OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7 bXNvLWxpc3QtaWQ6MTM5ODkzOTc0MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyOTQ3MjQx OTg7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDoxNTY5OTE3Nzg5Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxMjg3Nzk4NDE0O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDYNCgl7bXNvLWxp c3QtaWQ6MTg1ODEwODEyNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI0MDIxNTkzNjt9DQpA bGlzdCBsNjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw2OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjE5Nzg0OTIyNTc7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDQxMTc1NzUwIC0yMTI0Mjc4NDY0 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGw3OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 OTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6SGVsdmV0aWNhO30NCkBsaXN0IGw3Omxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIs c2VyaWY7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBs NzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGw3OmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZXJlIGlzIHRoZSBBUEksIGltcGxlbWVudGF0aW9uLCBhbmQgcHJvdG9jb2wuPGJy Pg0KQVBJOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi4yNWluIj5J4oCZZCBiZSBuaWNlIHRvIGhhdmUgYW4gQVBJIHdoaWNoIHdvdWxkIGFs bG93IGFwcGxpY2F0aW9ucyB0byBleHByZXNzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzExIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkRyb3AtZGVhZC10aW1lOiBUaGUgdGltZSBiZXlv bmQgd2hpY2ggdGhlIGRhdGEgaXMgbm90IHVzZWZ1bCB0byB0aGUgcmVjaXBpZW50PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43 NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mik8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RXhwYW5zaW9u LWZhY3RvcjogVGhlIG1heGltdW0g4oCYZXhwYW5zaW9uIGZhY3RvcuKAmSBhbGxvd2VkIGZvciB0 aGUgZGF0YSAoZG8gSSBzZW5kIHRoZSBieXRlcyAxLjIgKH5GRUMpIHRpbWVzLCAyIHRpbWVzIChk dXBsaWNhdGUgc2VuZHMpPyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwyIGxldmVsMSBsZm8xMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5Qcmlvcml0eTogZHVoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklt cGxlbWVudGF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPklmIHRoZSBpbXBsZW1lbnRhdGlvbiB0b29rIGFsbCBvZiB0aGUg YWJvdmUgaW50byBhY2NvdW50LCBpdCBtaWdodCBkZWNpZGUgdG8gbmV2ZXIgYXR0ZW1wdCB0byBz ZW5kIHNvbWUgZGF0YSwgYXMsIGdpdmVuIHRoZSBCVyBlc3RpbWF0ZSBmbG93aW5nIGJhY2sgZnJv bSB0aGUgY29uZ2VzdGlvbi1hdm9pZGFuY2UgYWxnb3JpdGhtLCBpdCB3b3VsZCBub3QgYmUgcmVj ZWl2ZWQNCiB3aXRoaW4gdGhlIGRyb3AtZGVhZC10aW1lLiBUaGlzIHdvdWxkIGJldHRlciB1c2Ug dGhlIGF2YWlsYWJsZSBiYW5kd2lkdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb3RvY29s OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPlByb3RvY29sLXdpc2UsIHdlIGNvdWxkICZuYnNwO2RlbGVnYXRlIHRoZSB0cmFuc21p c3Npb24gdG8gUVVJQyBvciBzb21lIG90aGVyIGhpZ2hlci1sZXZlbCBsYXllci48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Ib3dl dmVyLCBpZiB3ZSBkZWxlZ2F0ZSBhd2F5IGZyb20gUVVJQywgdGhlIHByb3hpZXMgd2lsbCBiZSBx dWl0ZSB1bmxpa2VseSB0byBwYXJ0aWNpcGF0ZSAob3RoZXIgdGhhbiBwcm9jZXNzaW5nIHN0cmVh bSBjYW5jZWxzKS4gVGhpcyB3b3VsZCBiZSBzYWQgZ2l2ZW4gdGhlIHdpZGUgZGVwbG95bWVudCBv ZiBwcm94aWVzIChpLmUuIHJldmVyc2UgcHJveGllcykgaW4NCiBDRE5zLCBldGMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomIzQzOyYjNDM7IG9uIHBhcnRpYWxs eSByZWxpYWJsZSAhPSB1bnJlbGlhYmxlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NClRDUCwgYWZ0ZXIgYWxsLCBpcyDigJxqdXN04oCdIGEgcGFydGlhbGx5IHJl bGlhYmxlIHByb3RvY29sIHdpdGggbG9uZyBlbm91Z2ggdGltZW91dHMgdGhhdCB3ZSBkZWlnbiB0 byBjYWxsIGl0IHJlbGlhYmxlDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUg Q29sb3IgRW1vamkmcXVvdDsiPuKYujwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LT1S PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5R VUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtMdWJh c2hldiwgSWdvciZxdW90OyAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgYXQgMTE6MDMgQU08YnI+DQo8Yj5Ubzog PC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDss IEx1Y2FzIFBhcmR1ZSAmbHQ7bHVjYXMucGFyZHVlQGJiYy5jby51ayZndDssICZxdW90O3F1aWNA aWV0Zi5vcmcmcXVvdDsgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJFOiBkcmFmdC1sdWJhc2hldi1xdWljLXBhcnRpYWwtcmVsaWFiaWxpdHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMyBsZXZlbDEgbGZvMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFub3RoZXIgY29uY2VybiBpcyB0 aW1lLWJhc2VkIHBhcnRpYWwgcmVsaWFiaWxpdHkuIElmIGRhdGEgaXMgb2xkLCBkb27igJl0IHJl dHJhbnNtaXQgcmVnYXJkbGVzcy4gQnV0IGFuIGFwcGxpY2F0aW9uIHByb3RvY29sDQogY2FuIGhh bmRsZSB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoaXMg aXMgYW4gYXBwbGljYXRpb24gY29uY2Vybiwgc2luY2Ugb25seSB0aGUgYXBwbGljYXRpb24gY2Fu IGtub3cgd2hhdCDigJxvbGTigJ0gbWVhbnMuJm5ic3A7IEFsc28sIHNpbmNlDQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+TUlOX0ZSQU1FX0RBVEE8L3NwYW4+ICZuYnNwO2ZyYW1lIGlzIGVtaXR0ZWQgT05M WSBpZiBzb21lIGV4cGlyZWQgc3RyZWFtIGRhdGEgaXMgbG9zdCAobm90IEFDS2VkKSwgeW91IHdv dWxkIG5vdCBleHBlY3QgdG8gc2VlIG1hbnkgc3VjaCBmcmFtZXMgb24gdGhlIHdpcmUsIGV2ZW4g aWYgbWVzc2FnZXMga2VlcCBleHBpcmluZyBhbGwgdGhlDQogdGltZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TXkgbWFpbiBj b25jZXJuIGlzIHRoYXQgc2VuZGluZyBNSU5fRlJBTUVfREFUQSBbc2ljOiBNSU5fU1RSRUFNX0RB VEFdIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGggbG90cyBvZiB0aW55IG1lc3Nh Z2VzDQogd2hlcmUgeW91IG9ubHkgY2FyZSBhYm91dCwgc2F5LCB0aGUgbGFzdCB0aHJlZSAxIGJ5 dGUgbWVzc2FnZXMgc2VudCAoaG9waW5nIGF0IGxlYXN0IG9uZSBnZXRzIHRocm91Z2gpLiBUaGUg TUlOX0ZSQU1FX0RBVEEgY291bGQgYmUgbXVjaCBsYXJnZXIgdGhhbiB0aGUgbWVzc2FnZXM8L3Nw YW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgdGhlIG1vc3QgZXhwZW5z aXZlIGNhc2UgZm9yIDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4NCk1JTl9TVFJFQU1fREFUQSDigJMgbWFu eSBwYXJ0aWFsbHktcmVsaWFibGUgc3RyZWFtcywgZWFjaCBjYXJyeWluZyAxLWJ5dGUgbWVzc2Fn ZXMsIHdpdGggZWFjaCBuZXcgbWVzc2FnZSBleHBpcmluZyBhbGwgZWFybGllciBtZXNzYWdlcywg b3ZlciBhIGhpZ2gtbG9zcyBjb25uZWN0aW9uLiZuYnNwOyBJbiB0aGlzIGNhc2UsIHRoZSBjb3N0 IG9mIE1JTl9TVFJFQU1fREFUQSBjb3VsZCBhcHByb2FjaCA1MCUgb2YgdGhlIGNvc3Qgb2YgdGhl IG90aGVyIGZyYW1lcw0KICg5IGJ5dGVzIGZvciBTVFJFQU0gJiM0Mzsgc29tZSBBQ0tzIHZzIDUg Ynl0ZXMgZm9yIE1JTl9TVFJFQU1fREFUQSBmcmFtZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WW91 IHJlbW92ZSBhbnkgb2YgdGhlIGNvbmRpdGlvbnMgYWJvdmUsIGFuZCBNSU5fU1RSRUFNX0RBVEEg Y29zdCBkcm9wIG9mZiByYXBpZGx5Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzciPkZldyBwYXJ0aWFsbHkt cmVsaWFibGUgc3RyZWFtczogZWl0aGVyIG11bHRpcGxlIG1lc3NhZ2VzIGdldCBjb25zb2xpZGF0 ZWQgaW50byBhIHNpbmdsZSBTVFJFQU0gZnJhbWUgKHJlcXVpcmluZyBhIHNpbmdsZQ0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPk1fU19EIGZyYW1lPC9zcGFuPiB0byBleHBpcmUpIG9yIHRoZSBvdmVyaGVh ZCBvZiB0aGUgUVVJQyBwYWNrZXQgaXRzZWxmIChNQUMmIzQzO0lQJiM0MztVRFAmIzQzO1FVSUMg aGVhZGVycykgc3RhcnRzIHRvIGRvbWluYXRlIGRyYW1hdGljYWxseS48bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDcg bGV2ZWwxIGxmbzciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NdWx0aS1ieXRlIG1lc3NhZ2VzOiBTVFJF QU0gZnJhbWVzIGFyZSBsYXJnZXIsIHNvIE1fU19EIGZyYW1l4oCZcyBwcm9wb3J0aW9uIGlzIHNt YWxsZXI8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw3IGxldmVsMSBsZm83Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+TmV3IG1lc3NhZ2VzIGV4cGlyaW5nIE5PVCBhbGwgZWFybGllciBtZXNzYWdlczogbW9yZSBj aGFuY2UgZm9yIHRoZSBuZXR3b3JrIHRvIHJldHJhbnNtaXQgbG9zdCBtZXNzYWdlcywgcmVkdWNp bmcgaG93IG9mdGVuDQogTV9TX0QgaXMgc2VudC48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw3IGxldmVs MSBsZm83Ij5Mb3ctbG9zcyBjb25uZWN0aW9uOiBmZXcgcGFja2V0cyBhcmUgbG9zdCwgc28gZmV3 DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+TV9TX0QgZnJhbWVzIG5lZWQgc2VuZGluZy48L3NwYW4+PG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFBhcnRpYWxseSByZWxpYWJsZeKAnSBpcyBu b3Qg4oCcdW5yZWxpYWJsZeKAnS4mbmJzcDsgVGhlIHRyYW5zcG9ydCBzdGlsbCBwcm92aWRlcyBt ZXNzYWdlIGF0b21pY2l0eSBhbmQgb3JkZXJpbmcgZ3VhcmFudGVlcywgaW4gYWRkaXRpb24gdG8g cmV0cmFuc21pc3Npb24gb2Yg4oCcc3RpbGwgY3VycmVudOKAnSBkYXRhLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiB5b3Ugd2FudCBjb21wbGV0ZWx5IHVucmVsaWFibGUgKGxpa2UgVURQKSwg eW91IG1heSB3YW50IHNvbWV0aGluZyBzbGlnaHRseSBkaWZmZXJlbnQuJm5ic3A7IEZvciBleGFt cGxlLCB3ZSBtYXkgZGVjaWRlIHRoYXQgaXMgdGhlIGZpcnN0IFNUUkVBTSBoYXMNCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+DQpPRkY9MSBhbmQgT2Zmc2V0PTA8L3NwYW4+ LCB0aGlzIGludHJvZHVjZXMgYSDigJxjb21wbGV0ZWx5IHVucmVsaWFibGXigJ0gc3RyZWFtLiZu YnNwOyBObyByZXRyYW5zbWlzc2lvbnMgYXJlIGV4cGVjdGVkIGF0IGFsbC4mbmJzcDsgSG93ZXZl ciwgeW91IHN0aWxsIHdhbnQgdG8gZG8gc29tZXRoaW5nIGZvciBmbG93IGNvbnRyb2wgKHlvdSBu ZWVkIHRvIHBlcmlvZGljYWxseSBzeW5jaHJvbml6ZSB5b3VyIHN0cmVhbSBhbmQgY29ubmVjdGlv biBmbG93IGNvbnRyb2wpLiZuYnNwOw0KIE1heWJlLCBpZiB5b3VyIHVucmVsaWFibGUgc3RyZWFt IHdlbnQgaWRsZSB3aXRoIHRoZSBsYXN0IHRyYW5zbWlzc2lvbiB1bmFja25vd2xlZGdlZCwgeW91 IGNvdWxkIHNlbmQgYSBTVFJFQU0gZnJhbWUgd2l0aCBMRU49MSwgTGVuZ3RoPTAsIGFuZCBPRkY9 MSwgT2Zmc2V0PWN1cnJlbnRfc3RyZWFtX29mZnNldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgeW91IGxpa2UgdGhpcywgSSBjYW4gd3JpdGUgdGhpcyBpbiBhIGRyYWZ0LiA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTAiPklnb3I8bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgMTI6MTUgUE08 YnI+DQo8Yj5Ubzo8L2I+IEx1Y2FzIFBhcmR1ZSAmbHQ7bHVjYXMucGFyZHVlQGJiYy5jby51ayZn dDs7IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgcXVpY0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtbHViYXNoZXYtcXVpYy1wYXJ0aWFs LXJlbGlhYmlsaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIHRoaXMg cHJvcG9zYWwgbGFyZ2VseSBtYWtlcyBnb29kIHNlbnNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5CZSBkZWZhdWx0IG5vIE1JTl9TVFJFQU1fREFUQSBmcmFtZSBpcyBzZW50 IHdoaWNoIGlzIHRoZW4gdGhlIGN1cnJlbnQgc3RyZWFtIGJlaGF2aW91ci48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFueSBhcHBsaWNhdGlvbiBwcm90b2NvbCBj YW4gZGVmaW5lIGl0cyBvd24gcnVsZXMgYWJvdXQgd2hpY2ggc3RyZWFtcyBjYW4gYmVoYXZlIHBh cnRpYWxseSByZWxpYWJsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QSBj b3VudGVyIGFyZ3VtZW50IGlzIHRoYXQgUVVJQyBleHBsaWNpdGx5IGRpc3Rpbmd1aXNoZXMgYmV0 d2VlbiB1bmktIGFuZCBiaS1kaXJlY3Rpb25hbCBzdHJlYW1zLCBzbyB3aHkgbm90IGJldHdlZW4g cGFydGlhbC0gYW5kIGZ1bGx5IHJlbGlhYmxlIHN0cmVhbXM/IFRoZSBhbnN3ZXIgbWlnaHQNCiBi ZSB0aGF0IHVuaS0gc3RyZWFtcyBjYW4gY2xvc2Ugc3RhdGUgZWFybHksIHdoaWxlIHRoZXJlIGlz IG5vIHNpbWlsYXIgY29uY2VybiBmb3IgcGFydGlhbCByZWxpYWJpbGl0eS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QW5vdGhlciBjb25jZXJuIGlzIHRpbWUtYmFzZWQgcGFy dGlhbCByZWxpYWJpbGl0eS4gSWYgZGF0YSBpcyBvbGQsIGRvbuKAmXQgcmV0cmFuc21pdCByZWdh cmRsZXNzLiBCdXQgYW4gYXBwbGljYXRpb24gcHJvdG9jb2wgY2FuIGhhbmRsZSB0aGlzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NeSBtYWluIGNvbmNlcm4gaXMgdGhhdCBz ZW5kaW5nIE1JTl9GUkFNRV9EQVRBIGNhbiBnZW5lcmF0ZSBBIExPVCBvZiB0cmFmZmljIHdpdGgg bG90cyBvZiB0aW55IG1lc3NhZ2VzIHdoZXJlIHlvdSBvbmx5IGNhcmUgYWJvdXQsIHNheSwgdGhl IGxhc3QgdGhyZWUgMSBieXRlIG1lc3NhZ2VzIHNlbnQNCiAoaG9waW5nIGF0IGxlYXN0IG9uZSBn ZXRzIHRocm91Z2gpLiBUaGUgTUlOX0ZSQU1FX0RBVEEgY291bGQgYmUgbXVjaCBsYXJnZXIgdGhh biB0aGUgbWVzc2FnZXMgZm9yY2luZyBsZXNzIGZyZXF1ZW50IHRyYWZmaWMuIE9mIGNvdXJzZSwg bG9jYWxseSB5b3UgY2FuIGhhdmUgeW91IG93biBydWxlcywgYW5kIGp1c3QgcGVyaW9kaWNhbGx5 IHVwZGF0ZSBNSU5fRlJBTUVfREFUQSwgYnV0IHRoaXMgaXMgYSBiaXQgb2RkLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BIHZhcmlhdGlvbiBvZiB0aGUgY29uY2VwdCBjb3Vs ZCBiZSBzZW5kaW5nIE1JTl9GUkFNRV9EQVRBIGFzIGEgZGVsdGEgdG8gbW9zdCByZWNlbnQ6IG5l dmVyIGV4cGVjdCBtb3JlIHRoYW4gWCBieXRlcyBvbGRlciB0aGFuIG1vc3QgcmVjZW50bHkgc2Vl biwgYnV0IHRoYXQgYWxzbyBoYXMgaXQgaXNzdWVzDQogd2hlbiBtZXNzYWdlcyBhcmUgdmFyaWFi bGUgbGVuZ3RoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRvIGNsaWVudCB2cyBz ZXJ2ZXIgYXN5bW1ldHJpOiBJdCBzdHJvbmdseSBzdWdnZXN0IG5vdCB0byBtYWtlIGEgZGlzdGlu Y3Rpb24gaGVyZSBiZWNhdXNlIHRoZXJlIGFyZSBtYW55IHN5bW1ldHJpYyBwZWVyIHRvIHBlZXIg dXNlIGNhc2VzIGFuZCBhbHNvIG9wcG9zaXRlIGNhc2VzOiBzZXJ2ZXINCiB0byBjbGllbnQgd2l0 aCBwYXJ0aWFsbHkgcmVsaWFibGUgdmlkZW8sIGNsaWVudCB0byBzZXJ2ZXIgd2l0aCBwYXJ0aWFs bHkgcmVsaWFibGUgZ2FtZSBzdGF0ZSwgc2VydmVyIHRvIHNlcnZlciB3aXRoIHBhcnRpYWxseSBy ZWxpYWJsZSBnb3NzaXAgcHJvdG9jb2wgdG8gc3RhdGlzdGljYWxseSBhZHZhbmNlIGEgY29tbW9u IHN0YXRlIChlLmcuICZxdW90O0kgaGF2ZSBwcm9jZXNzZWQgc28gbWFueSBieXRlcyBub3csIGhv dyBhYm91dCB5b3U/4oCdKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgaWQ9ImJsb29wX3NpZ25fMTUxMzcwMzAxMTYzNjU4MTg4OCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTkgRGVjZW1iZXIg MjAxNyBhdCAxNi40Ny4wOCwgTHVjYXMgUGFyZHVlICg8YSBocmVmPSJtYWlsdG86bHVjYXMucGFy ZHVlQGJiYy5jby51ayI+bHVjYXMucGFyZHVlQGJiYy5jby51azwvYT4pIHdyb3RlOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklnb3Igd3JvdGU6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgYm9va2tl ZXBpbmcgaXMgc2ltcGxlIGVub3VnaCBhbmQgdGhlIHJ1bnRpbWUgcmVzb3VyY2VzIHJlcXVpcmVk IGlzIGp1c3Qgb25lIHVpbnQ2NF90IHBlcg0KIHN0ZWFtLCBzbyBJIGRvIG5vdCBzZWUgYSBwcm9i bGVtIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5V bHRpbWF0ZWx5LCBwYXJ0aWFsIHJlbGlhYmlsaXR5IGlzIGEgZmVhdHVyZSB0aGF0IGFuIGFwcGxp Y2F0aW9uIGVpdGhlciBuZWVkcyBvciBkb2VzIG5vdC4gSWYNCiBhbiBhcHBsaWNhdGlvbiBuZWVk cyBpdCwgaXQgbW9zdCBsaWtlbHkgcmVxdWlyZXMgaXQuIEluIGFueSBjYXNlLCBhbiBhcHBsaWNh dGlvbiBjYW4gZG8gaXRzIG93biBuZWdvdGlhdGlvbiBpZiBpdCBkZXNpcmVzIHRvIGRvIHNvLiBG b3IgZXhhbXBsZSwgaXQgY2FuIHVzZSBzdHJlYW0gMSBmb3IgdGhhdC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Tm93IEkgdW5kZXJzdGFuZCB0aGlzIGlzIGNvbm5lY3Rpb24td2lkZSwgSSBnZW5lcmFs bHkgYWdyZWUuIEhvd2V2ZXIsIGZvciBzb21ldGhpbmcgbGlrZSBjb252ZW50aW9uYWwNCiBIVFRQ L1FVSUMsIHRoZSByZWxpYWJsZSBndWFyYW50ZWUgYXNzdXJhbmNlcyBhcmUgcmVxdWlyZWQgYnkg dGhlIG1hcHBpbmcuIElmIHBhcnRpYWwgcmVsaWFiaWxpdHkgaXMgZGVmYXVsdCBlbmFibGVkIHRy YW5zcG9ydCBmZWF0dXJlLCBhcHBsaWNhdGlvbnMgbGlrZSBIVFRQL1FVSUMgbXVzdCByZXN0cmlj dCBvciBkaXNhYmxlIGl0IOKAkyBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgZWRpdG9ycy9kcmFmdHMg aGF2ZSBicm9hY2hlZCB0aGF0IHN1YmplY3QgeWV0DQogKEnigJl2ZSBjZXJ0YWlubHkgaGFkIHNv bWUgZmVlZGJhY2sgb24gbXkgZHJhZnQgYWJvdXQgc3VjaCByZXN0cmljdGlvbnMpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBkaWQgbm90 IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGxhc3QgcXVlc3Rpb24uIEFyZSB5b3UgYXNraW5nIHdoZXRo ZXIgaXQgaXMgcG9zc2libGUgZm9yIHRoZQ0KIGNvbm5lY3Rpb24gdG8gbmVnb3RpYXRlIGp1c3Qg YSBzaW5nbGUgc3RyZWFtIChpbiBlYWNoIGRpcmVjdGlvbikgdGhhdCB3b3VsZCBiZSBwYXJ0aWFs bHkgcmVsaWFibGUgYW5kLCB0aGVyZWZvcmUsIG5vdCBzZW5kIGEgc3RyZWFtIGlkIHdpdGggTUlO X1NUUkVBTV9EQVRBPyBJIGNvdWxkIGFjdHVhbGx5IHRoaW5rIG9mIGEgdmVyc2lvbiBvZiBNSU5f U1RSRUFNX0RBVEEgdGhhdCBoYXMgYW4gaW1wbGllZCBzdHJlYW0gaWQgLS0gdGhlIHN0cmVhbQ0K IGlkIG9mIGEgcHJpb3IvZm9sbG93aW5nIFNUUkVBTSBmcmFtZSBpbiB0aGUgc2FtZSBwYWNrZXQu IFRoYXQgd291bGQgYmUgYW4gb3B0aW1pemF0aW9uIHRoYXQgSSBhbSBoYXBweSB0byBhZGQsIGlm IHRoZXJlIGlzIGVub3VnaCBzdXBwb3J0IGZvciBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFwb2xvZ2llcywgSSBoYWRu4oCZdCBkcnVuayBhbnkg Y29mZmVlIHdoZW4gZmlyc3QgcmVwbHlpbmcgYW5kIGdvdCBteXNlbGYgY29uZnVzZWQuIEFsbCBR VUlDIGZyYW1lcw0KIG9mIHRoaXMgbmF0dXJlIHNob3VsZCBub3JtYWxseSBpbmNsdWRlIGEgU3Ry ZWFtIElELCB3aGljaCBpZGVudGlmaWVzIHRoZSBzdHJlYW0gaXQgaXMgc2VudCBvbi4gSSB0aGlu ayB5b3VyIHN1Z2dlc3Rpb24gcmVsaWVzIG9uIHNlcmlhbCBvcmRlcmluZy9wcm9jZXNzaW5nIChl dmVuIGluc2lkZSBhIHBhY2tldCksIHdoaWNoIG1pZ2h0IGJlIGEgaGFyZCBzZWxsLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U2VwYXJhdGVseSwgaW4g dGVybXMgb2YgYXN5bW1ldHJ5LCBJIHdhcyB0aGlua2luZyB0aGF0IHlvdSBtaWdodCBhbHdheXMg d2FudCAoYXMgYSBwb2xpY3kpIGNsaWVudHMNCiB0byB0cmFuc21pdCB3aXRoIGZ1bGwgcmVsaWFi aWxpdHkgYnV0IHByb3ZpZGUgZGF0YSB0byB0aGVtIHdpdGggcGFydGlhbCByZWxpYWJpbGl0eS4g SSB0aGluayB0aGlzIGlzIGFnYWluIGFuIGFwcGxpY2F0aW9uIG1hcHBpbmcgY29uY2Vybi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkx1Y2FzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_47687CC12C78451CA9AD3370FA4CA36Bfbcom_-- From nobody Tue Dec 19 11:26: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 3538212D7E9 for ; Tue, 19 Dec 2017 11:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7noHVb2NIPV1 for ; Tue, 19 Dec 2017 11:26:00 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001: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 F3BAA1200F1 for ; Tue, 19 Dec 2017 11:25:59 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id w127so14743710iow.11 for ; Tue, 19 Dec 2017 11:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=I/NkfeNiswywhCGXb0geU0Ux/K3FJlHLwD7MV+SxnzY=; b=R1rblXQGXS/UjBUZfZqXOTy1p0o27SEsWMRvui469ez46+Atlr59zWaFMphliUir49 dfxSJu05hYHVsuwlExx2q1Sb9pToksexTaDs75iONB5t7ZH7HXBEy+F1JS8qVTLCnk53 i2sdgh+jPEUSeKVUAAdz98eh1X6iXv4OQ8FYRqlH5zn/nmD7ol+uFziirDNeU95Tsq19 iC0yejZv7VmDkh+Vb2BjBugK4ou8MTtWf/VmquqL5Ir9gZTCvL29dLqiebcrXYH2iBzl f50qHyLGSJisJc2bilS/4lvqhWrhPXoiiVxMe4IrS2u/cd8rgX/6Y9n0noO372SyCe9c +VQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=I/NkfeNiswywhCGXb0geU0Ux/K3FJlHLwD7MV+SxnzY=; b=oWcadMsxANsV1A9JEKySbWPwxLxQ/daeAf0LlCasr60uwrnRIt0w0xURgpCaPSB+Pu YrqLBV7kZalTTdWm44s1EjJGcCZjZSAitRBQM29d2lmYlkQ4x66QUz36GosNEcsFjoxU euGTP5nrvFnx9EWBOocBDqyOJpr0UiWGcsjvsR/OP5UvFAOitxdPOPU97JstU8zF8v8w PlCjFjpVsH7FtUTYua6Mx10TTUdxf76sLk8Qm92ORMQ2IQV6K5bNhUHD1cTQevwqwdal 3KlNROQsMPTGAFLmN5FAwv2thWsDoUNacQpFo/IPE63og+z81xE/oixiZEb4o4zEq+Fo iaYQ== X-Gm-Message-State: AKGB3mKfBvbqnqQc4OzNYVvIXFG8ETzmhNABIeLDO/YASM6xj7K9hvAB /SOnCRQ2HFxQoiFT5Y0Ft5UIqJsYS6424lY2MuQ= X-Google-Smtp-Source: ACJfBouBYy2Q+g/D6GgwG+9OFcwJ3S4g92uNh/JUSPzX5EfYZtRSRCJQGPS/+m6RW2/WHkra7+Bh6FSsT2YUvjeRpbw= X-Received: by 10.107.170.194 with SMTP id g63mr2938847ioj.175.1513711558338; Tue, 19 Dec 2017 11:25:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Dec 2017 11:25:57 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <49797640bd7444f39b51a7595ee53c72@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> <49797640bd7444f39b51a7595ee53c72@usma1ex-dag1mb5.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Dec 2017 11:25:57 -0800 Message-ID: Subject: RE: draft-lubashev-quic-partial-reliability To: "Lubashev, Igor" , Lucas Pardue , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1141d432ba2e650560b66f34" 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, 19 Dec 2017 19:26:01 -0000 --001a1141d432ba2e650560b66f34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, this is an application concern, since only the application can know what =E2=80=9Cold=E2=80=9D means. Also, since MIN_FRAME_DATA frame is emi= tted ONLY if some expired stream data is lost (not ACKed), you would not expect to see many such frames on the wire, even if messages keep expiring all the time. I could be that the approach is not aggressive enough. If the connection has low loss-rate, it might start retransmitting a lot of data that the application already knows is no longer relevant, before the NACK (ACK gap) arrives cost excessive bandwidth. In a recent TCP vs QUIC paper posted here, that was an unanswered question about why QUIC took double the bandwidth of TCP when both were competing using CUBIC. This might be related to QUIC being able to make faster retransmission decisions on more packets which do not count against its flow control window (right?). --001a1141d432ba2e650560b66f34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Yes, this is an application concern, since only the application can = know what =E2=80=9Cold=E2=80=9D means.=C2=A0 Also, since=C2=A0MIN_FRAME_DATA=C2=A0=C2=A0frame is emitted ONLY if some expired stream data i= s lost (not ACKed), you would not expect to see many such frames on the wir= e, even if messages keep expiring all the time.

I could be that the approach is not aggressive enough. If = the connection has low loss-rate, it might start retransmitting a lot of da= ta that the application already knows is no longer relevant, before the NAC= K (ACK gap) arrives cost excessive bandwidth.

In a recent TCP vs QUIC= paper posted here, that was an unanswered question about why QUIC took dou= ble the bandwidth of TCP when both were competing using CUBIC. This might b= e related to QUIC being able to make faster retransmission decisions on mor= e packets which do not count against its flow control window (right?).

<= div>
--001a1141d432ba2e650560b66f34-- From nobody Tue Dec 19 11:31: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 D151D12D830 for ; Tue, 19 Dec 2017 11:31:13 -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_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 52c3o27q9FY8 for ; Tue, 19 Dec 2017 11:31:12 -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 16A6112D82D for ; Tue, 19 Dec 2017 11:31:12 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRNbY-0007Eu-8x for quic@ietf.org; Tue, 19 Dec 2017 20:31:09 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eRNbW-00052F-7B for quic@ietf.org; Tue, 19 Dec 2017 14:31:07 -0500 Received: (qmail 21831 invoked from network); 19 Dec 2017 19:31:04 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Dec 2017 19:31:04 -0000 To: "Lubashev, Igor" , QUIC WG References: From: Christian Huitema Message-ID: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> Date: Tue, 19 Dec 2017 11:31:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: draft-lubashev-quic-partial-reliability X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.59) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mejodwnrW+nNt0lzyyKp64Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu7Ve+IJooKvShhDVWyxDygB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CgKaGzfcJ00EPsiVhfSKl3mx+PIL1ombXfQrNjRfO/VOx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5mTFkJCfQx95lvhVaK1R9QMX /Lgz0mucCFazxyRnx4XXBGWb7fPzS53ef0WN2OlcClz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiB8jSoYz6mw6iMTDK1bQzS5x3h1vgDbEdmhrg3iVBpdRZRb8Vdsy5LZaUHXrX9gYVqGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj 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, 19 Dec 2017 19:31:14 -0000 On 12/18/2017 7:39 PM, Lubashev, Igor wrote: > The high-level idea is that the sender keeps track of messages within > a stream and can =93expire=94 old messages whenever it wants.=A0 The > =93expiration=94 is a signal to the transport to not retransmit expired= > data (and a signal to the other endpoint that this data will not be > retransmitted).=A0 All details are in the draft. I read your draft, and it does indeed provide "partial reliability." My problem is that for RTP style applications, you don't want just partial reliability. You also want application frame delimitation, such as delivering isolated VOIP frames, doing=A0 loss compensation, or implementing application level FEC for large video frames. The streams in QUIC don't provide that. They implement a "byte stream" abstraction, not a "packet stream". So I really wonder whether FTP style applications are better served by adding partial reliability to the current concept of streams, or whether we should just add a different service, maybe creating "RTP_STREAM" frames. -- Christian Huitema From nobody Tue Dec 19 11:40: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 33BDF129C6B for ; Tue, 19 Dec 2017 11:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnNKBEwpKOrD for ; Tue, 19 Dec 2017 11:40:21 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA61128954 for ; Tue, 19 Dec 2017 11:40:21 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id l10so14786123ioc.3 for ; Tue, 19 Dec 2017 11:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=uC4uofQWvtU/Da8o8PnY+Y9sYCftCHXp/aHHXxPiqeM=; b=NnWKnZMmKn3FtjuoHmsVAM+XCCFxgogK6MdB7x49FK6o/zby/EyixV70gCZvUmb9Yv mdpeJ02tX89VNzt1V8Fpn8H0sPFbzN11PqkctdOD8foLtwZ3pH26eluCVjhbLsrlgPRD N9AscduIRVP7bTEM4NGJAExDVGW6D6I6lTcMN3TEgXBrSvRbzOPDAZKqFdoqYnV4VAQJ mC8OkHMokoqUMvCv+kQvhrV0YUdBtGHTRkFuI7KAi412PXYVIXmeh2yIx57qU38rJe4O wO8ElaSdPt5nPEq9GXCYU7ltw6B4mEVNyryyUK65qXBwBRYz5aqKbW7641wranS8qU1U XiPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=uC4uofQWvtU/Da8o8PnY+Y9sYCftCHXp/aHHXxPiqeM=; b=G5B9U+hSy9s2vvJiccEjXkIZ8X3YiPLYUIIGnjJWUTdmb9iBxI8EVZGkrZsr28XD14 hqiglmBT0Cii5ywjmWe3HT0I3tqoX1iRctLJuY/PA6pzGrFxVz4hkSggV/KJH9efE4dB JQGlUW1CoS0vfYPFgRk66UsPU++gnu0cDbFE7LIEiIwLgrNmzXg0UOTkALvWWztxzSEy 4bYgRY43GJ9HN6EdpDHIUzNNrhYC9XoPDJdnIBE9iXe33yl8jnHPni54udru/9bC594L seKauv7BhFK6SZ9F0RaxxGtaK3Dxp74Fekhc1zrdYJHHr6nQ7HgM1FvOvd9It6PDz/8c pOEw== X-Gm-Message-State: AKGB3mJMsOyjuRiRenLxW50M7NPlJ/qHyacNQmb377yl61gC0IEGakO/ BbZBEF78FgFWKsIQIAyJvD+xto35I4ykdpg0ci73ow== X-Google-Smtp-Source: ACJfBotQDvEXInk8J8WpF6cMzAPPg154GznIsVizwROisfZLUTvRpVSlZEV9hzZewu4WR1W+pMnVdhgFWkxbnIF8faM= X-Received: by 10.107.47.234 with SMTP id v103mr4917138iov.96.1513712421118; Tue, 19 Dec 2017 11:40:21 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Dec 2017 11:40:20 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 19 Dec 2017 11:40:20 -0800 Message-ID: Subject: Re: draft-lubashev-quic-partial-reliability To: "Lubashev, Igor" , Christian Huitema , QUIC WG Content-Type: multipart/alternative; boundary="001a1135a438272be00560b6a3ca" 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, 19 Dec 2017 19:40:23 -0000 --001a1135a438272be00560b6a3ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did come up with a proposal with segmented stream data for partial reliability. It=E2=80=99s not too coherent as it evolved, but here it is: https://github.com/quicwg/base-drafts/issues/433 Applications could also do their internal framing and forward the min for each internal frame and let transport decide if retransmission is worthwhile. If the application needs to make business decisions it might be out of the loop for too long. QUIC might be scheduled a lot more often than applications talking to QUIC. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 December 2017 at 20.31.17, Christian Huitema (huitema@huitema.net) wrote: On 12/18/2017 7:39 PM, Lubashev, Igor wrote: > The high-level idea is that the sender keeps track of messages within > a stream and can =E2=80=9Cexpire=E2=80=9D old messages whenever it wants.= The > =E2=80=9Cexpiration=E2=80=9D is a signal to the transport to not retransm= it expired > data (and a signal to the other endpoint that this data will not be > retransmitted). All details are in the draft. I read your draft, and it does indeed provide "partial reliability." My problem is that for RTP style applications, you don't want just partial reliability. You also want application frame delimitation, such as delivering isolated VOIP frames, doing loss compensation, or implementing application level FEC for large video frames. The streams in QUIC don't provide that. They implement a "byte stream" abstraction, not a "packet stream". So I really wonder whether FTP style applications are better served by adding partial reliability to the current concept of streams, or whether we should just add a different service, maybe creating "RTP_STREAM" frames. -- Christian Huitema --001a1135a438272be00560b6a3ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I did come up with a= proposal with segmented stream data for partial reliability.
It=E2=80=99s not too cohe= rent as it evolved, but here it is:


Applications could also do their internal = framing and forward the min for each internal frame and let transport decid= e if retransmission is worthwhile.

If the application needs to make business decisions it might= be out of the loop for too long. QUIC might be scheduled a lot more often = than applications talking to QUIC.

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

<= br>

On 19 December 2017 at 20.31.17, Christian Huite= ma (huitema@huitema.net) wrote:<= /p>

On 12/18/2017 7:39 PM, Lubashev, Igor wrote:

> The high-level idea is that the sender keeps track of messages wit= hin
> a stream and can =E2=80=9Cexpire=E2=80=9D old messages whenever it= wants.=C2=A0 The
> =E2=80=9Cexpiration=E2=80=9D is a signal to the transport to not r= etransmit expired
> data (and a signal to the other endpoint that this data will not b= e
> retransmitted).=C2=A0 All details are in the draft.

I read your draft, and it does indeed provide "partial reliability= ." My
problem is that for RTP style applications, you don't want just par= tial
reliability. You also want application frame delimitation, such as
delivering isolated VOIP frames, doing=C2=A0 loss compensation, or
implementing application level FEC for large video frames. The streams
in QUIC don't provide that. They implement a "byte stream"= ; abstraction,
not a "packet stream". So I really wonder whether FTP style a= pplications
are better served by adding partial reliability to the current concept
of streams, or whether we should just add a different service, maybe
creating "RTP_STREAM" frames.

-- Christian Huitema


--001a1135a438272be00560b6a3ca-- From nobody Tue Dec 19 12:20: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 66AF11270A0 for ; Tue, 19 Dec 2017 12:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.29 X-Spam-Level: ** X-Spam-Status: No, score=2.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gbGVe11UakPE for ; Tue, 19 Dec 2017 12:20:09 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 0C8311201F2 for ; Tue, 19 Dec 2017 12:20:09 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id o2so14894495ioe.8 for ; Tue, 19 Dec 2017 12:20:09 -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=nzl1ponJoEyMVRZ1SG3OADyDZEe5u0iw67uRz9K1uwk=; b=TGHDjvEwYM00nKpzP5jMeBcvT0lYD/1k1W0Jf7d3oUWKJmwPQ3yzFqVGGIE33W5uVV u6zaL/C+6Q1HUJf1FMsZuBYpIzpFfhJq3NnYXm3BxFlJcbZ559Izy2OAfTEH0dE8JLFn DM4IAXOJ5RzLiYOc+Dw1DST9dbO7GBl9OBuqbB9aGkqpukd/P4OfzHV9XcYgyNpVoMbZ Kuo8g/YX6Ti17PY9HTmCKMK54g79cgTbWZ4LtIRFjp6R5x2qudm52DFNmur+sWtX+kec croBXkQ8+LVGQA/ML+5p+di+4gPYnQBCRNqhQLt0TaqlJIBN1spvJWEm89sA88S3k1RC lIiw== 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=nzl1ponJoEyMVRZ1SG3OADyDZEe5u0iw67uRz9K1uwk=; b=DAaj1MT4xS2IQPQTzos4LVrBF+4g4sNWp6lGkM1plEF4n2WHSQtBVr6U+mB5KAiSyf T6VOjouPQvceki1p9vdssZf/6AvrAPFBZ+JW9kbuJpAZn6xiW7OmrJO1KvFec923ilYT n/5Q2qQWqFkAhWL4Hm94ogGLIYrwWYCA4DwMWLuaMenNeAZdugxZSRhaHmzCQh7aClqi dRZtQYr3bZuvVh5CbQfAa1+tDBo9ccdGlrgmwZzVhHdqt64FoVoT+hIzhBrLCdl6xaA9 S1jLk55bBttGrDGhMqlLCdbljpuEdEFNJ0dBjGiD112jlsISGfYCclru9hRpPEho6RjZ BeEA== X-Gm-Message-State: AKGB3mIPwN6dnOuOvaTOqNLfLkWkfpC65755Onh18JSZTbuRsDSGi7Nn zOHDBs8lp+SkSNJ42HJvv5Pk4y+DRgBrFGFnVz4qCg== X-Google-Smtp-Source: ACJfBou3Iwbe4xHHgj4CciQPG3iSJye/HhCGm4Vg2GifumTo0zlZW9Ku18JeemADd6c7jEyT5OSmXHzZma7jfQMCFgo= X-Received: by 10.107.107.23 with SMTP id g23mr5483062ioc.283.1513714807934; Tue, 19 Dec 2017 12:20:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.3 with HTTP; Tue, 19 Dec 2017 12:19:47 -0800 (PST) In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> From: Ian Swett Date: Tue, 19 Dec 2017 15:19:47 -0500 Message-ID: Subject: Re: draft-lubashev-quic-partial-reliability To: Lucas Pardue Cc: "Lubashev, Igor" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="089e0825fbc46b9f300560b7319f" 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, 19 Dec 2017 20:20:10 -0000 --089e0825fbc46b9f300560b7319f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for writing this up Igor, it's an interesting idea, and I like how it allows any stream besides 0 to be partially reliable. I'm a bit concerned(or possibly confused) about the effort to change how flow control works, see comments below. I believe this proposal implicitly assumes that it's easier and more efficient to use streams for ordering and make the application deal with interpreting out of order data than the current model of making applications reorder a large number of small streams? That may or may not be true in a given application, but I can imagine cases when it is true. At the beginning you say: "The key to partial reliablity is notifying the transport and the peer when data previously enqueued for transmission no longer needs to be transmitted." I believe there is another challenge, which is indicating to the receiver when they should stop expecting to receive data. Conveniently, this is exactly what MIN_STREAM_DATA does, but I think it's worth noting in the introduction. In terms of the downsides of using streams as is, you say: "Hence, a message-per-stream approach requires each message to contain an extra header portion to associate the message with a logical application stream. In case of short messages, this approach introduces a significant overhead due to STREAM frames and message headers. It also places the burden on the application to reorder data arriving on multiple QUIC streams." In practice, I believe a lot of applications using partial reliability today have such headers, since they're commonly designed with UDP in mind. In section 4, you discuss the separation of Unsent bytes from Sent data, but I'm still confused on the motivation there, since separating them seems to make flow control more complex. Currently the connection flow control used is the sum of the largest byte offsets of all streams on a connection, and now that would be dramatically different, correct? Can you add more background on why these are separated and how they are applied to various limits? If I read correctly, MIN_STREAM_DATA frame is effectively able to increase a peer's flow control limits by declaring previously used credits up for grabs? This proposal requires out of order delivery be supported by QUIC streams, which is worth explicitly noting, maybe in section 5, since it's currently not required. Also, the receiver needs to be able to determine what the message boundaries are if there are gaps in the stream. How easy that is would depend upon what is being sent on the stream. It might deserve some discussion about how one might do this and what restrictions should be imposed on how the sender bundles data, if that ends up being necessary? ie: Can a STREAM frame contain the end of one message and the beginning of another in a single frame? On Tue, Dec 19, 2017 at 10:46 AM, Lucas Pardue wrote: > Igor wrote: > > > > The bookkeeping is simple enough and the runtime resources required is > just one uint64_t per steam, so I do not see a problem for constrained > devices. > > Ultimately, partial reliability is a feature that an application either > needs or does not. If an application needs it, it most likely requires it= . > In any case, an application can do its own negotiation if it desires to d= o > so. For example, it can use stream 1 for that. > > Now I understand this is connection-wide, I generally agree. However, for > something like conventional HTTP/QUIC, the reliable guarantee assurances > are required by the mapping. If partial reliability is default enabled > transport feature, applications like HTTP/QUIC must restrict or disable i= t > =E2=80=93 I=E2=80=99m not sure if the editors/drafts have broached that s= ubject yet (I=E2=80=99ve > certainly had some feedback on my draft about such restrictions). > > > > I did not fully understand the last question. Are you asking whether it i= s > possible for the connection to negotiate just a single stream (in each > direction) that would be partially reliable and, therefore, not send a > stream id with MIN_STREAM_DATA? I could actually think of a version of > MIN_STREAM_DATA that has an implied stream id -- the stream id of a > prior/following STREAM frame in the same packet. That would be an > optimization that I am happy to add, if there is enough support for it. > > > > Apologies, I hadn=E2=80=99t drunk any coffee when first replying and got = myself > confused. All QUIC frames of this nature should normally include a Stream > ID, which identifies the stream it is sent on. I think your suggestion > relies on serial ordering/processing (even inside a packet), which might = be > a hard sell. > > > > Separately, in terms of asymmetry, I was thinking that you might always > want (as a policy) clients to transmit with full reliability but provide > data to them with partial reliability. I think this is again an applicati= on > mapping concern. > > > > Regards, > > Lucas > > > --089e0825fbc46b9f300560b7319f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing this up Igor, it's an interest= ing idea, and I like how it allows any stream besides 0 to be partially rel= iable.=C2=A0 I'm a bit concerned(or possibly confused) about the effort= to change how flow control works, see comments below.=C2=A0 I believe this= proposal implicitly assumes that it's easier and more efficient to use= streams for ordering and make the application deal with interpreting out o= f order data than the current model of making applications reorder a large = number of small streams?=C2=A0 That may or may not be true in a given appli= cation, but I can imagine cases when it is true.

A= t the beginning you say:
"The key to partial reliablity is n= otifying the transport and the peer
=C2=A0when data previously en= queued for transmission no longer needs to be
=C2=A0transmitted.&= quot;

I believe there is another challenge, which = is indicating to the receiver when they should stop expecting to receive da= ta.=C2=A0 Conveniently, this is exactly what MIN_STREAM_DATA does, but I th= ink it's worth noting in the introduction.

In = terms of the downsides of using streams as is, you say:
"Hen= ce, a message-per-stream
=C2=A0approach requires each message to = contain an extra header portion to
=C2=A0associate the message wi= th a logical application stream.=C2=A0 In case of
=C2=A0short mes= sages, this approach introduces a significant overhead due
=C2=A0= to STREAM frames and message headers.=C2=A0 It also places the burden on
=C2=A0the application to reorder data arriving on multiple QUIC str= eams."

In practice, I believe a lot of applic= ations using partial reliability today have such headers, since they're= commonly designed with UDP in mind.

In section 4,= you discuss the separation of Unsent bytes from Sent data, but I'm sti= ll confused on the motivation there, since separating them seems to make fl= ow control more complex.=C2=A0 Currently the connection flow control used i= s the sum of the largest byte offsets of all streams on a connection, and n= ow that would be dramatically different, correct?=C2=A0 Can you add more ba= ckground on why these are separated and how they are applied to various lim= its?=C2=A0 If I read correctly, MIN_STREAM_DATA frame is effectively able t= o increase a peer's flow control limits by declaring previously used cr= edits up for grabs?

This proposal requires out of = order delivery be supported by QUIC streams, which is worth explicitly noti= ng, maybe in section 5, since it's currently not required.=C2=A0 Also, = the receiver needs to be able to determine what the message boundaries are = if there are gaps in the stream.=C2=A0 How easy that is would depend upon w= hat is being sent on the stream.=C2=A0 It might deserve some discussion abo= ut how one might do this and what restrictions should be imposed on how the= sender bundles data, if that ends up being necessary?=C2=A0 ie: Can a STRE= AM frame contain the end of one message and the beginning of another in a s= ingle frame?


On Tue, Dec 19, 2017 at 10:46 AM, Lucas Pardue <Lu= cas.Pardue@bbc.co.uk> wrote:

Igor wrote:

=C2=A0

The bookkeeping is simple enough and the runtime resources required = is just one uint64_t per steam, so I do not see a problem for constrained d= evices.

Ultimately, partial reliability is a feature that an application eit= her needs or does not. If an application needs it, it most likely requires = it. In any case, an application can do its own negotiation if it desires to do so. For example, it can use stream= 1 for that.

Now I understand this is connection-wide, I g= enerally agree. However, for something like conventional HTTP/QUIC, the rel= iable guarantee assurances are required by the mapping. If partial reliabil= ity is default enabled transport feature, applications like HTTP/QUIC must restrict or disable it =E2=80=93 I=E2=80= =99m not sure if the editors/drafts have broached that subject yet (I=E2=80= =99ve certainly had some feedback on my draft about such restrictions).<= /u>

=C2=A0

I did not fully understand the last question. Are you asking whether= it is possible for the connection to negotiate just a single stream (in ea= ch direction) that would be partially reliable and, therefore, not send a stream id with MIN_STREAM_DATA? I coul= d actually think of a version of MIN_STREAM_DATA that has an implied stream= id -- the stream id of a prior/following STREAM frame in the same packet. = That would be an optimization that I am happy to add, if there is enough support for it.=

=C2=A0

Apologies, I hadn=E2=80=99t drunk any coffee = when first replying and got myself confused. All QUIC frames of this nature= should normally include a Stream ID, which identifies the stream it is sen= t on. I think your suggestion relies on serial ordering/processing (even inside a packet), which might be a hard sell.

=C2=A0

Separately, in terms of asymmetry, I was thinking th= at you might always want (as a policy) clients to transmit with full reliab= ility but provide data to them with partial reliability. I think this is ag= ain an application mapping concern.

=C2=A0

Regards,

Lucas

=C2=A0


--089e0825fbc46b9f300560b7319f-- From nobody Tue Dec 19 12:31: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 7DB2C12D84C for ; Tue, 19 Dec 2017 12:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Hi4opXKEXI4f for ; Tue, 19 Dec 2017 12:31:28 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074051201F2 for ; Tue, 19 Dec 2017 12:31:27 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-68-5a39771d44c7 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.50.14322.D17793A5; Tue, 19 Dec 2017 21:31:26 +0100 (CET) Received: from EUR03-AM5-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.352.0; Tue, 19 Dec 2017 21:31:25 +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=NdHLO/Ix+L0uHkAQg+Ny3HspISvbvMPlYWmgIdB6E/s=; b=boedz8a/nXqQXgfsB1Sit4IocciQm5W3IXuzyUZxVPyYV24k5DVgnIvjEy1JXIeNkhRZQYca8Eqyp/SKM5ZMm4Lwh3vr8N7xa8+7adsFWxYmWZJCUWMDwAKpwJlIIssGtWlTLB8CNZfuTzk3FPC9HIU9EdiXdgJNLJhOty5uqUI= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB350.eurprd07.prod.outlook.com (10.141.12.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Tue, 19 Dec 2017 20:31:24 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::2c98:5b96:c4b1:c9c5]) by DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::2c98:5b96:c4b1:c9c5%13]) with mapi id 15.20.0345.013; Tue, 19 Dec 2017 20:31:24 +0000 From: Ingemar Johansson S To: Christian Huitema , "Lubashev, Igor" , QUIC WG Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AQHTeQQGB+JEQ3qvq0uxD/I0bJKSsaNLFpjg Date: Tue, 19 Dec 2017 20:31:24 +0000 Message-ID: References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> In-Reply-To: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.226.2.151] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB350; 6:jwdwLzUN7xP/3FZ9mWUaVttyGGPpX2pHp0Ti1U56WC4qAAB4EB+j0hR+Uql7+FWQ9HYFCOI63RWMCySUYPHSINmMeHXLCbNxApQN37BOHBBK1m7uDG39v+6mWFmGdx+Va6bUjFbP9FY7bKAQvfQtPduHBZwJtrs++Y6H89FHxzwxpt+/apAYP2XuMBbB7Njfd6ZpTpZhvz6BPsRuCLzjmQLhavisJcm/nXCl2+J+BUi9KMR3cs790Pu8MOG/x3uBTh/4esagVelV1tU6xqbpoTcAQzmsAGJJ49ClOcOIZGg0qVIqh/fPMaPHvLbdazIbUt/hYL12qA/DjjScADP9EpFq51GHQFwSzoJKCpBUKEQ=; 5:4yut8jIu2IOyLWR39F3Qj07WIv99mc7roHEONFwQJAIP2zeeE3TLiKRGMkrFSgcr+OQ7z/n1aD1gTv4rpc5ATgGGrRDCw7pVV9MzeFdgGI3dnRRdBMmDj8JKkTyCc2g88qDQfL107TOba0620E0CMUXs5/pOQYGowhIj9qsZd+g=; 24:R4rwL4zMwRau6kQ29AOF3+5sL2mwwLRvovJM2MZOgVP9mI360kkiyXwEtkUiUEnPBtK/XAH8rQcjbL3TveMr8uKy4A/8eXHN8oCID8PoUQc=; 7:KbRHtiBICD3sq/bNw7jaF91neAkgeJMueLmbjK5ZB/HNrAilIKFo4JtvYlz5jWzwfo2r2ilPG+O+XxkJUQ6svGB2U7Fwnm9lLMDMORRyB/6/SBcV57y94xlqOtA2aHHD2s+reqXQtOhPThTOO4x7b8CbaNPXwFLZ8BX4mYCwNT3vZSX2WfJNLUH4gg1DujL7iIZPfDAlObrgca1cNexIui4ydtUQKL/13r/DEJzqLnagNjXHNop0Th4svOYs3etT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 87323607-2fdc-4e3c-3bcc-08d5471f78f9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:DBXPR07MB350; x-ms-traffictypediagnostic: DBXPR07MB350: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:DBXPR07MB350; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DBXPR07MB350; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(366004)(39860400002)(24454002)(189003)(199004)(13464003)(55016002)(9686003)(478600001)(97736004)(53546011)(59450400001)(6506007)(316002)(6436002)(105586002)(229853002)(106356001)(2950100002)(5660300001)(6116002)(102836003)(8936002)(3846002)(81156014)(3280700002)(66066001)(99286004)(2900100001)(74316002)(7736002)(110136005)(3660700001)(86362001)(230783001)(81166006)(6246003)(7696005)(68736007)(5250100002)(14454004)(305945005)(33656002)(2906002)(25786009)(53936002)(8676002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB350; H:DBXPR07MB351.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 87323607-2fdc-4e3c-3bcc-08d5471f78f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 20:31:24.0544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB350 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbFdS1eu3DLKYNlhRovJjbPZLZoaVjBb 9CzgdmD2mHxkAbPHrRmnWDyWLPnJFMAcxWWTkpqTWZZapG+XwJVxYn8He8Ej/oprd5waGF/y dDFycEgImEhM6U7tYuTiEBI4zChxurWPGcI5wSjx8uNZFhCHRaCXWeLWgvssEJmpTBJ39jdD lT1klFh8dBtTFyMnB5uAjcTKQ98ZQWwRgTyJQ186WEFsYZAdBx+ygOwTETCV+LSFCaLESOLI 97XsIDaLgKrE4qv/mEFsXoEoiXdnHrFCzG9nlLjzZQZYEaeAvcTO6YvAihgFZCXuf7/HAmIz C4hL3HoyH2yohICAxJI955khbFGJl4//sULYChJ3Jy2AsmUlLs3vZgRZICFwkF1i3ZRlUAk9 ia0T3zJC2L4S538dgCpawyhxdGIDEyTENCVuHjGEqMmUaGq/CNVrLbH86FSo+nnMEj+O7WGH qJeRuD/XBCK+nVXi+NEpbCANQgKpEsvXtjJOYNSdheQJCFtP4sbUKWwQtrbEsoWvmWeBQ0ZQ 4uTMJywLGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgQmkoNbflvtYDz43PEQowAHoxIP 7+Yyyygh1sSy4srcQ4wSHMxKIrwLd1pECfGmJFZWpRblxxeV5qQWH2KU5mBREud1SgNKCaQn lqRmp6YWpBbBZJk4OKUaGE3OxGzsidpu5j+BxbHkEp/YfdmbnCXWW7U0rs8o3WVvuE7k/bRX W5u1zQ7bpCyYXBsktMPKt2iVanH1HY561ZtP79fcPqz18F3bP87P/+5sPnBrXXZAmBLztOvP rHP778/pTqmat0bD3Fvh0DSd/OZFvlapc8/MfvNVUD5GWmmt7UYlLzOjFiWW4oxEQy3mouJE AOgyA24gAwAA 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, 19 Dec 2017 20:31:34 -0000 > -----Original Message----- > From: Christian Huitema [mailto:huitema@huitema.net] > Sent: den 19 december 2017 20:31 > To: Lubashev, Igor ; QUIC WG > Subject: Re: draft-lubashev-quic-partial-reliability >=20 > On 12/18/2017 7:39 PM, Lubashev, Igor wrote: >=20 > > The high-level idea is that the sender keeps track of messages within > > a stream and can "expire" old messages whenever it wants.=A0 The > > "expiration" is a signal to the transport to not retransmit expired > > data (and a signal to the other endpoint that this data will not be > > retransmitted).=A0 All details are in the draft. >=20 > I read your draft, and it does indeed provide "partial reliability." My p= roblem > is that for RTP style applications, you don't want just partial reliabili= ty. You > also want application frame delimitation, such as delivering isolated VOI= P > frames, doing=A0 loss compensation, or implementing application level FEC= for > large video frames. The streams in QUIC don't provide that. They implemen= t > a "byte stream" abstraction, not a "packet stream". So I really wonder > whether FTP style applications are better served by adding partial reliab= ility > to the current concept of streams, or whether we should just add a differ= ent > service, maybe creating "RTP_STREAM" frames. Thanks Christian, I now understand what I did not understand with the parti= al-reliability draft. The reason is that I look at this from an RTP point o= f view. To make QUIC {partial,un}reliable streams useful for real time medi= a then I agree that one need something like RTP_STREAM. With that said I am= not sure that RTP is the best common denominator around, perhaps MEDIA_STR= EAM is a better alternative?, where one use the abstraction media frames (v= ideo frames, audio frames...) instead ?, that would allow support for other= not RTP type packetization like for instance MPEG-TS . >=20 > -- Christian Huitema >=20 >=20 From nobody Tue Dec 19 12:48: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 E54F4128D2E for ; Tue, 19 Dec 2017 12:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4fwon1Y8sn7f for ; Tue, 19 Dec 2017 12:48:47 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894531201F2 for ; Tue, 19 Dec 2017 12:48:47 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id e204so14983303iof.12 for ; Tue, 19 Dec 2017 12:48: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=zC4rI+nNArsumSKfVm/48ZcaLNHZ9x9AiXo0cgApFBg=; b=nJvNRo/uUrSreAX/A5lsNT/dYL5Jy96uB+rCnXR8gOcAEZQSMJmi/hb3LJGrchFh4b JziWuRGqPZlKzHZR1qewpRvuhg3b3A9XVGZTKy6Ku06yKgtkSkDOz5yfEtrr8bzqK0CN GRzPqh0NU47nFmz+Snhp8WoQ5ncAJFoaAyBbUr6OgdLq/AUAzOn0togaQ4jFsHDvwn+n QRhfkIPcTHNmiDCN1lF2kzIQJKm2L5j8k8YPYVcGbYc1NXu7q4+NvuAnGVke8+xwtk2Q iMBZi6l9MO5J6of6FL4wTc9Y64JaVhrrQbGYsv01cJL+H9ucYXV/RMsy4B10gcrDGu1C WgQg== 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=zC4rI+nNArsumSKfVm/48ZcaLNHZ9x9AiXo0cgApFBg=; b=Kfg7bVYtg210wioAiLFfdIg8CPqmlX4Xjl0ojftcphlsX8Lp+UdvFlo5ZODe1JS7st Tyu8uLO7oYA7kz9uCtUkUg0cj+NcJFK8tbjWSf1ozEKuHmIZ7H+FNgzQQifDWZVkIU3f FlGayBPW+y8XeNShN0UZUqzkf0VN0uusIWDR2wJ/CEtdOpc41NJu/Zewdi80fa019W9/ Z7qeoNdeSIHq8JxO0cmMVerN3pChBD/SJcWVIE1wT09NM6McrzAsqhkdCR1AulQkiVpV hq2Lk8Md/lC01+umB5QTw7gDKvlZv95KaB7Pk0OVcA+6rYWu0gZPNdiXOXwoXgxjn8N8 5F6A== X-Gm-Message-State: AKGB3mKUzhsR5Skx13Cv7xxf+HQWcIrZn8eLXsz7q7ebXGlpm6EMtqNO CF3TDXNOvd+ZrGKmCPRbJ6d3cn2V8Tz0iZCraFlwNg== X-Google-Smtp-Source: ACJfBosLPxdUq4LJBKSpKcRyDuDOJEgpUMhPbR+nwR9dQMvrehD7o4Py44gfjTPaUmwAQ9Vhe9zhpgTTJ3GY9V/ikk0= X-Received: by 10.107.107.23 with SMTP id g23mr5592689ioc.283.1513716526671; Tue, 19 Dec 2017 12:48:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.3 with HTTP; Tue, 19 Dec 2017 12:48:25 -0800 (PST) In-Reply-To: References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> From: Ian Swett Date: Tue, 19 Dec 2017 15:48:25 -0500 Message-ID: Subject: Re: draft-lubashev-quic-partial-reliability To: Ingemar Johansson S Cc: Christian Huitema , "Lubashev, Igor" , QUIC WG Content-Type: multipart/alternative; boundary="089e0825fbc4dd674d0560b797a5" 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, 19 Dec 2017 20:48:50 -0000 --089e0825fbc4dd674d0560b797a5 Content-Type: text/plain; charset="UTF-8" For message style payloads commonly carried over UDP, like RTP, I added an issue to create a MESSAGE frame for QUIC. Does that fit what you have in mind? https://github.com/quicwg/base-drafts/issues/814 On Tue, Dec 19, 2017 at 3:31 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@huitema.net] > > Sent: den 19 december 2017 20:31 > > To: Lubashev, Igor ; QUIC WG > > Subject: Re: draft-lubashev-quic-partial-reliability > > > > On 12/18/2017 7:39 PM, Lubashev, Igor wrote: > > > > > The high-level idea is that the sender keeps track of messages within > > > a stream and can "expire" old messages whenever it wants. The > > > "expiration" is a signal to the transport to not retransmit expired > > > data (and a signal to the other endpoint that this data will not be > > > retransmitted). All details are in the draft. > > > > I read your draft, and it does indeed provide "partial reliability." My > problem > > is that for RTP style applications, you don't want just partial > reliability. You > > also want application frame delimitation, such as delivering isolated > VOIP > > frames, doing loss compensation, or implementing application level FEC > for > > large video frames. The streams in QUIC don't provide that. They > implement > > a "byte stream" abstraction, not a "packet stream". So I really wonder > > whether FTP style applications are better served by adding partial > reliability > > to the current concept of streams, or whether we should just add a > different > > service, maybe creating "RTP_STREAM" frames. > > Thanks Christian, I now understand what I did not understand with the > partial-reliability draft. The reason is that I look at this from an RTP > point of view. To make QUIC {partial,un}reliable streams useful for real > time media then I agree that one need something like RTP_STREAM. With that > said I am not sure that RTP is the best common denominator around, perhaps > MEDIA_STREAM is a better alternative?, where one use the abstraction media > frames (video frames, audio frames...) instead ?, that would allow support > for other not RTP type packetization like for instance MPEG-TS . > > > > > -- Christian Huitema > > > > > > --089e0825fbc4dd674d0560b797a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For message style payloads commonly carried over UDP, like= RTP, I added an issue to create a MESSAGE frame for QUIC.=C2=A0 Does that = fit what you have in mind?

On Tue,= Dec 19, 2017 at 3:31 PM, Ingemar Johansson S <ingemar.s.jo= hansson@ericsson.com> wrote:
> -----Original Message-----
> From: Christian Huitema [mailto:huitema@huitema.net]
> Sent: den 19 december 2017 20:31
> To: Lubashev, Igor <ilubashe= @akamai.com>; QUIC WG <quic@ietf= .org>
> Subject: Re: draft-lubashev-quic-partial-= reliability
>
> On 12/18/2017 7:39 PM, Lubashev, Igor wrote:
>
> > The high-level idea is that the sender keeps track of messages wi= thin
> > a stream and can "expire" old messages whenever it want= s.=C2=A0 The
> > "expiration" is a signal to the transport to not retran= smit expired
> > data (and a signal to the other endpoint that this data will not = be
> > retransmitted).=C2=A0 All details are in the draft.
>
> I read your draft, and it does indeed provide "partial reliabilit= y." My problem
> is that for RTP style applications, you don't want just partial re= liability. You
> also want application frame delimitation, such as delivering isolated = VOIP
> frames, doing=C2=A0 loss compensation, or implementing application lev= el FEC for
> large video frames. The streams in QUIC don't provide that. They i= mplement
> a "byte stream" abstraction, not a "packet stream"= . So I really wonder
> whether FTP style applications are better served by adding partial rel= iability
> to the current concept of streams, or whether we should just add a dif= ferent
> service, maybe creating "RTP_STREAM" frames.

Thanks Christian, I now understand what I did not understand with th= e partial-reliability draft. The reason is that I look at this from an RTP = point of view. To make QUIC {partial,un}reliable streams useful for real ti= me media then I agree that one need something like RTP_STREAM. With that sa= id I am not sure that RTP is the best common denominator around, perhaps ME= DIA_STREAM is a better alternative?, where one use the abstraction media fr= ames (video frames, audio frames...) instead ?, that would allow support fo= r other not RTP type packetization like for instance MPEG-TS .

>
> -- Christian Huitema
>
>


--089e0825fbc4dd674d0560b797a5-- From nobody Tue Dec 19 12: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 98C9D1270A0 for ; Tue, 19 Dec 2017 12:56:38 -0800 (PST) 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=bhsBcfmj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZxFIs/oh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEVAlhQPqboV for ; Tue, 19 Dec 2017 12:56:36 -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 20FF61205D3 for ; Tue, 19 Dec 2017 12:56:36 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJKrHNt018471; Tue, 19 Dec 2017 12:56:23 -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=nHuKFJb6PgwfaVd0P0dvWCoaJLgVZzv4CMwd6/6tewE=; b=bhsBcfmjvqeB2bre5ComasR0gudUOgtvpPZG8edj2bCKzWv4OigB+NRpxxUyYRBAqGUU B3YocMKIW1GHPcfoT4Lq5s6cTKx+VLAmjlZ0k4tuRGbk2BqBiEdcj7940dj+4Qfilbry rLoQfEhBZx9IpBPitUpwtruzzCo07atT6co= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2eya01g29g-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Dec 2017 12:56:23 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.29) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 19 Dec 2017 15:56:21 -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=nHuKFJb6PgwfaVd0P0dvWCoaJLgVZzv4CMwd6/6tewE=; b=ZxFIs/ohEIGm3S376uZ4nr7Y8tI5gIAzGacXCoEFUxdSMAELLYu9I2NJnk8UvNN7h1tet/6E88WwLmuDITCNvP+q16pjHfdfLNJ7JOc0chf1K327zeGj1GsJM8SW0OKgrsq7RDH5Hf1lplKKQLRlCzO+UVetGcO7GiWaQl+/tNY= Received: from BN6PR15MB1876.namprd15.prod.outlook.com (10.174.239.136) by BN6PR15MB1874.namprd15.prod.outlook.com (10.174.239.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 20:56:20 +0000 Received: from BN6PR15MB1876.namprd15.prod.outlook.com ([10.174.239.136]) by BN6PR15MB1876.namprd15.prod.outlook.com ([10.174.239.136]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 20:56:20 +0000 From: Roberto Peon To: Ian Swett , Ingemar Johansson S CC: "Lubashev, Igor" , Christian Huitema , QUIC WG Subject: Re: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAhf3aAAAIb3wAAAJgkgP//fBiA Date: Tue, 19 Dec 2017 20:56:20 +0000 Message-ID: References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:5c29] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR15MB1874; 20:7H1uz5k3+dqJk2UGdae0y/m0j06/xCICjZNDU2L/8RaDqYWuDIsLHemnJC2nUVVsaXDblQIjgowfaZ60vhW48yfYdnhWxzXcyGr5K3X90gg6Ynq6eKKe7DcLdmeG+Su3zJnuDrLEE0CljTZLdcWKSd8xfWcqLWytAf8zOYPW7+o= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 75999f70-f891-4c5b-fa63-08d54722f4b5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:BN6PR15MB1874; x-ms-traffictypediagnostic: BN6PR15MB1874: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(166708455590820)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(11241501184)(920507027)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011); SRVR:BN6PR15MB1874; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR15MB1874; x-forefront-prvs: 052670E5A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(346002)(396003)(24454002)(13464003)(199004)(189003)(53936002)(3660700001)(229853002)(77096006)(3280700002)(6486002)(6116002)(93886005)(2906002)(102836003)(5660300001)(36756003)(6436002)(14454004)(6506007)(236005)(6512007)(59450400001)(53546011)(54896002)(6306002)(76176011)(99286004)(478600001)(966005)(6246003)(33656002)(97736004)(82746002)(34040400001)(7736002)(81166006)(2950100002)(4326008)(86362001)(8936002)(230783001)(2900100001)(68736007)(25786009)(110136005)(81156014)(83716003)(54906003)(8676002)(105586002)(606006)(316002)(106356001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1874; H:BN6PR15MB1876.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D329F6FCBBBF491A930D69D8917F364Efbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 75999f70-f891-4c5b-fa63-08d54722f4b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 20:56:20.1257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1874 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 19 Dec 2017 20:56:38 -0000 --_000_D329F6FCBBBF491A930D69D8917F364Efbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd291bGQgYmUgYmVzdCB0byBoYXZlIGEgZ3JvdXBpbmcgb2YgaW5kaXZpZHVhbGx5IG5hbWVk IGF0b21zICh3aGV0aGVyIHN0cmVhbXMgb3IgbWVzc2FnZXMsIGRvZXNu4oCZdCBtYXR0ZXIpIHNv IHRoYXQgd2UgZG9u4oCZdCBqZXR0aXNvbiB0aGUgYWJpbGl0eSB0byBjYWNoZS4NCi09Ug0KDQpG cm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBJYW4gU3dldHQg PGlhbnN3ZXR0QGdvb2dsZS5jb20+DQpEYXRlOiBUdWVzZGF5LCBEZWNlbWJlciAxOSwgMjAxNyBh dCAxMjo0OSBQTQ0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25A ZXJpY3Nzb24uY29tPg0KQ2M6ICJMdWJhc2hldiwgSWdvciIgPGlsdWJhc2hlQGFrYW1haS5jb20+ LCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4sIFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogZHJhZnQtbHViYXNoZXYtcXVpYy1wYXJ0aWFsLXJlbGlh YmlsaXR5DQoNCkZvciBtZXNzYWdlIHN0eWxlIHBheWxvYWRzIGNvbW1vbmx5IGNhcnJpZWQgb3Zl ciBVRFAsIGxpa2UgUlRQLCBJIGFkZGVkIGFuIGlzc3VlIHRvIGNyZWF0ZSBhIE1FU1NBR0UgZnJh bWUgZm9yIFFVSUMuICBEb2VzIHRoYXQgZml0IHdoYXQgeW91IGhhdmUgaW4gbWluZD8NCmh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzgxNA0KDQpPbiBUdWUsIERl YyAxOSwgMjAxNyBhdCAzOjMxIFBNLCBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b20+PiB3cm90ZToNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2hyaXN0 aWFuIEh1aXRlbWEgW21haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0Pl0NCj4gU2VudDogZGVuIDE5IGRlY2VtYmVyIDIwMTcgMjA6MzENCj4gVG86IEx1 YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWku Y29tPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KPiBT dWJqZWN0OiBSZTogZHJhZnQtbHViYXNoZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5DQo+DQo+ IE9uIDEyLzE4LzIwMTcgNzozOSBQTSwgTHViYXNoZXYsIElnb3Igd3JvdGU6DQo+DQo+ID4gVGhl IGhpZ2gtbGV2ZWwgaWRlYSBpcyB0aGF0IHRoZSBzZW5kZXIga2VlcHMgdHJhY2sgb2YgbWVzc2Fn ZXMgd2l0aGluDQo+ID4gYSBzdHJlYW0gYW5kIGNhbiAiZXhwaXJlIiBvbGQgbWVzc2FnZXMgd2hl bmV2ZXIgaXQgd2FudHMuICBUaGUNCj4gPiAiZXhwaXJhdGlvbiIgaXMgYSBzaWduYWwgdG8gdGhl IHRyYW5zcG9ydCB0byBub3QgcmV0cmFuc21pdCBleHBpcmVkDQo+ID4gZGF0YSAoYW5kIGEgc2ln bmFsIHRvIHRoZSBvdGhlciBlbmRwb2ludCB0aGF0IHRoaXMgZGF0YSB3aWxsIG5vdCBiZQ0KPiA+ IHJldHJhbnNtaXR0ZWQpLiAgQWxsIGRldGFpbHMgYXJlIGluIHRoZSBkcmFmdC4NCj4NCj4gSSBy ZWFkIHlvdXIgZHJhZnQsIGFuZCBpdCBkb2VzIGluZGVlZCBwcm92aWRlICJwYXJ0aWFsIHJlbGlh YmlsaXR5LiIgTXkgcHJvYmxlbQ0KPiBpcyB0aGF0IGZvciBSVFAgc3R5bGUgYXBwbGljYXRpb25z LCB5b3UgZG9uJ3Qgd2FudCBqdXN0IHBhcnRpYWwgcmVsaWFiaWxpdHkuIFlvdQ0KPiBhbHNvIHdh bnQgYXBwbGljYXRpb24gZnJhbWUgZGVsaW1pdGF0aW9uLCBzdWNoIGFzIGRlbGl2ZXJpbmcgaXNv bGF0ZWQgVk9JUA0KPiBmcmFtZXMsIGRvaW5nICBsb3NzIGNvbXBlbnNhdGlvbiwgb3IgaW1wbGVt ZW50aW5nIGFwcGxpY2F0aW9uIGxldmVsIEZFQyBmb3INCj4gbGFyZ2UgdmlkZW8gZnJhbWVzLiBU aGUgc3RyZWFtcyBpbiBRVUlDIGRvbid0IHByb3ZpZGUgdGhhdC4gVGhleSBpbXBsZW1lbnQNCj4g YSAiYnl0ZSBzdHJlYW0iIGFic3RyYWN0aW9uLCBub3QgYSAicGFja2V0IHN0cmVhbSIuIFNvIEkg cmVhbGx5IHdvbmRlcg0KPiB3aGV0aGVyIEZUUCBzdHlsZSBhcHBsaWNhdGlvbnMgYXJlIGJldHRl ciBzZXJ2ZWQgYnkgYWRkaW5nIHBhcnRpYWwgcmVsaWFiaWxpdHkNCj4gdG8gdGhlIGN1cnJlbnQg Y29uY2VwdCBvZiBzdHJlYW1zLCBvciB3aGV0aGVyIHdlIHNob3VsZCBqdXN0IGFkZCBhIGRpZmZl cmVudA0KPiBzZXJ2aWNlLCBtYXliZSBjcmVhdGluZyAiUlRQX1NUUkVBTSIgZnJhbWVzLg0KDQpU aGFua3MgQ2hyaXN0aWFuLCBJIG5vdyB1bmRlcnN0YW5kIHdoYXQgSSBkaWQgbm90IHVuZGVyc3Rh bmQgd2l0aCB0aGUgcGFydGlhbC1yZWxpYWJpbGl0eSBkcmFmdC4gVGhlIHJlYXNvbiBpcyB0aGF0 IEkgbG9vayBhdCB0aGlzIGZyb20gYW4gUlRQIHBvaW50IG9mIHZpZXcuIFRvIG1ha2UgUVVJQyB7 cGFydGlhbCx1bn1yZWxpYWJsZSBzdHJlYW1zIHVzZWZ1bCBmb3IgcmVhbCB0aW1lIG1lZGlhIHRo ZW4gSSBhZ3JlZSB0aGF0IG9uZSBuZWVkIHNvbWV0aGluZyBsaWtlIFJUUF9TVFJFQU0uIFdpdGgg dGhhdCBzYWlkIEkgYW0gbm90IHN1cmUgdGhhdCBSVFAgaXMgdGhlIGJlc3QgY29tbW9uIGRlbm9t aW5hdG9yIGFyb3VuZCwgcGVyaGFwcyBNRURJQV9TVFJFQU0gaXMgYSBiZXR0ZXIgYWx0ZXJuYXRp dmU/LCB3aGVyZSBvbmUgdXNlIHRoZSBhYnN0cmFjdGlvbiBtZWRpYSBmcmFtZXMgKHZpZGVvIGZy YW1lcywgYXVkaW8gZnJhbWVzLi4uKSBpbnN0ZWFkID8sIHRoYXQgd291bGQgYWxsb3cgc3VwcG9y dCBmb3Igb3RoZXIgbm90IFJUUCB0eXBlIHBhY2tldGl6YXRpb24gbGlrZSBmb3IgaW5zdGFuY2Ug TVBFRy1UUyAuDQoNCj4NCj4gLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4NCj4NCg0K --_000_D329F6FCBBBF491A930D69D8917F364Efbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSBiZXN0IHRvIGhhdmUg YSBncm91cGluZyBvZiBpbmRpdmlkdWFsbHkgbmFtZWQgYXRvbXMgKHdoZXRoZXIgc3RyZWFtcyBv ciBtZXNzYWdlcywgZG9lc27igJl0IG1hdHRlcikgc28gdGhhdCB3ZSBkb27igJl0IGpldHRpc29u IHRoZSBhYmlsaXR5IHRvIGNhY2hlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RVUlDICZs dDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBJYW4gU3dldHQgJmx0O2lh bnN3ZXR0QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIERlY2VtYmVy IDE5LCAyMDE3IGF0IDEyOjQ5IFBNPGJyPg0KPGI+VG86IDwvYj5JbmdlbWFyIEpvaGFuc3NvbiBT ICZsdDtpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9i PiZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Oywg Q2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7LCBRVUlDIFdHICZs dDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogZHJhZnQtbHViYXNo ZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgbWVzc2FnZSBzdHlsZSBwYXlsb2Fk cyBjb21tb25seSBjYXJyaWVkIG92ZXIgVURQLCBsaWtlIFJUUCwgSSBhZGRlZCBhbiBpc3N1ZSB0 byBjcmVhdGUgYSBNRVNTQUdFIGZyYW1lIGZvciBRVUlDLiZuYnNwOyBEb2VzIHRoYXQgZml0IHdo YXQgeW91IGhhdmUgaW4gbWluZD8NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv aXNzdWVzLzgxNCI+aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMv ODE0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIERlYyAxOSwgMjAxNyBhdCAzOjMxIFBNLCBJbmdlbWFyIEpvaGFuc3NvbiBT ICZsdDs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iIHRh cmdldD0iX2JsYW5rIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsgRnJvbTogQ2hyaXN0aWFuIEh1aXRlbWEgW21haWx0bzo8YSBocmVmPSJtYWls dG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT5dPGJyPg0KJmd0 OyBTZW50OiBkZW4gMTkgZGVjZW1iZXIgMjAxNyAyMDozMTxicj4NCiZndDsgVG86IEx1YmFzaGV2 LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVA YWthbWFpLmNvbTwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRm Lm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogZHJhZnQt bHViYXNoZXYtcXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5PGJyPg0KJmd0Ozxicj4NCiZndDsgT24g MTIvMTgvMjAxNyA3OjM5IFBNLCBMdWJhc2hldiwgSWdvciB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFRoZSBoaWdoLWxldmVsIGlkZWEgaXMgdGhhdCB0aGUgc2VuZGVyIGtlZXBzIHRy YWNrIG9mIG1lc3NhZ2VzIHdpdGhpbjxicj4NCiZndDsgJmd0OyBhIHN0cmVhbSBhbmQgY2FuICZx dW90O2V4cGlyZSZxdW90OyBvbGQgbWVzc2FnZXMgd2hlbmV2ZXIgaXQgd2FudHMuJm5ic3A7IFRo ZTxicj4NCiZndDsgJmd0OyAmcXVvdDtleHBpcmF0aW9uJnF1b3Q7IGlzIGEgc2lnbmFsIHRvIHRo ZSB0cmFuc3BvcnQgdG8gbm90IHJldHJhbnNtaXQgZXhwaXJlZDxicj4NCiZndDsgJmd0OyBkYXRh IChhbmQgYSBzaWduYWwgdG8gdGhlIG90aGVyIGVuZHBvaW50IHRoYXQgdGhpcyBkYXRhIHdpbGwg bm90IGJlPGJyPg0KJmd0OyAmZ3Q7IHJldHJhbnNtaXR0ZWQpLiZuYnNwOyBBbGwgZGV0YWlscyBh cmUgaW4gdGhlIGRyYWZ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgcmVhZCB5b3VyIGRyYWZ0LCBh bmQgaXQgZG9lcyBpbmRlZWQgcHJvdmlkZSAmcXVvdDtwYXJ0aWFsIHJlbGlhYmlsaXR5LiZxdW90 OyBNeSBwcm9ibGVtPGJyPg0KJmd0OyBpcyB0aGF0IGZvciBSVFAgc3R5bGUgYXBwbGljYXRpb25z LCB5b3UgZG9uJ3Qgd2FudCBqdXN0IHBhcnRpYWwgcmVsaWFiaWxpdHkuIFlvdTxicj4NCiZndDsg YWxzbyB3YW50IGFwcGxpY2F0aW9uIGZyYW1lIGRlbGltaXRhdGlvbiwgc3VjaCBhcyBkZWxpdmVy aW5nIGlzb2xhdGVkIFZPSVA8YnI+DQomZ3Q7IGZyYW1lcywgZG9pbmcmbmJzcDsgbG9zcyBjb21w ZW5zYXRpb24sIG9yIGltcGxlbWVudGluZyBhcHBsaWNhdGlvbiBsZXZlbCBGRUMgZm9yPGJyPg0K Jmd0OyBsYXJnZSB2aWRlbyBmcmFtZXMuIFRoZSBzdHJlYW1zIGluIFFVSUMgZG9uJ3QgcHJvdmlk ZSB0aGF0LiBUaGV5IGltcGxlbWVudDxicj4NCiZndDsgYSAmcXVvdDtieXRlIHN0cmVhbSZxdW90 OyBhYnN0cmFjdGlvbiwgbm90IGEgJnF1b3Q7cGFja2V0IHN0cmVhbSZxdW90Oy4gU28gSSByZWFs bHkgd29uZGVyPGJyPg0KJmd0OyB3aGV0aGVyIEZUUCBzdHlsZSBhcHBsaWNhdGlvbnMgYXJlIGJl dHRlciBzZXJ2ZWQgYnkgYWRkaW5nIHBhcnRpYWwgcmVsaWFiaWxpdHk8YnI+DQomZ3Q7IHRvIHRo ZSBjdXJyZW50IGNvbmNlcHQgb2Ygc3RyZWFtcywgb3Igd2hldGhlciB3ZSBzaG91bGQganVzdCBh ZGQgYSBkaWZmZXJlbnQ8YnI+DQomZ3Q7IHNlcnZpY2UsIG1heWJlIGNyZWF0aW5nICZxdW90O1JU UF9TVFJFQU0mcXVvdDsgZnJhbWVzLjxicj4NCjxicj4NClRoYW5rcyBDaHJpc3RpYW4sIEkgbm93 IHVuZGVyc3RhbmQgd2hhdCBJIGRpZCBub3QgdW5kZXJzdGFuZCB3aXRoIHRoZSBwYXJ0aWFsLXJl bGlhYmlsaXR5IGRyYWZ0LiBUaGUgcmVhc29uIGlzIHRoYXQgSSBsb29rIGF0IHRoaXMgZnJvbSBh biBSVFAgcG9pbnQgb2Ygdmlldy4gVG8gbWFrZSBRVUlDIHtwYXJ0aWFsLHVufXJlbGlhYmxlIHN0 cmVhbXMgdXNlZnVsIGZvciByZWFsIHRpbWUgbWVkaWEgdGhlbiBJIGFncmVlIHRoYXQgb25lIG5l ZWQgc29tZXRoaW5nDQogbGlrZSBSVFBfU1RSRUFNLiBXaXRoIHRoYXQgc2FpZCBJIGFtIG5vdCBz dXJlIHRoYXQgUlRQIGlzIHRoZSBiZXN0IGNvbW1vbiBkZW5vbWluYXRvciBhcm91bmQsIHBlcmhh cHMgTUVESUFfU1RSRUFNIGlzIGEgYmV0dGVyIGFsdGVybmF0aXZlPywgd2hlcmUgb25lIHVzZSB0 aGUgYWJzdHJhY3Rpb24gbWVkaWEgZnJhbWVzICh2aWRlbyBmcmFtZXMsIGF1ZGlvIGZyYW1lcy4u LikgaW5zdGVhZCA/LCB0aGF0IHdvdWxkIGFsbG93IHN1cHBvcnQgZm9yDQogb3RoZXIgbm90IFJU UCB0eXBlIHBhY2tldGl6YXRpb24gbGlrZSBmb3IgaW5zdGFuY2UgTVBFRy1UUyAuPGJyPg0KPGJy Pg0KJmd0Ozxicj4NCiZndDsgLS0gQ2hyaXN0aWFuIEh1aXRlbWE8YnI+DQomZ3Q7PGJyPg0KJmd0 OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D329F6FCBBBF491A930D69D8917F364Efbcom_-- From nobody Tue Dec 19 13:45: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 F309212D856 for ; Tue, 19 Dec 2017 13:45: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, 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=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 Y7uo4hH4W9hp for ; Tue, 19 Dec 2017 13:45:52 -0800 (PST) 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 480FA1200FC for ; Tue, 19 Dec 2017 13:45:52 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBJLgL1j030492; Tue, 19 Dec 2017 21:45:45 GMT 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 : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4tkWRTVo0uxCut8uFDT3Ci79foKhZqwd69MU7D0BN/o=; b=BxIe13nk86aWtJrTpMaICD8S0EC/M9YiLLl/tt4BEMW10dh/05tu305wCzCp4g9JCNsK Q7AfOGPJryWm31KDEUflwvNKySMZ3jByegx18S4HHAgfOU1pMwV6PdLnjM9vIcTSviyG w561crG72bDkfZXHNtJ2qXoCXtwn4l0uHX4y77TACzTFp7vWBE4jLZTAnDZNgQrkoxTM mjtKIet07IxiJlLP9jbyZIpm0hb6l7RbLsibKfb90b0virPfo01GoMaKi8X/kyY3XgZr YNYZmZZHUb3dEu+i4F4fj4kJXd2o/dbhzNn1POq5uaX6WRe0SPJdoHq3gfAJlJICg3s5 OQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2evuw6b9m8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 21:45:45 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBJLetuc018467; Tue, 19 Dec 2017 16:45:43 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2evyqdwvnq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 16:45:43 -0500 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.1263.5; Tue, 19 Dec 2017 16:45:42 -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.1263.000; Tue, 19 Dec 2017 16:45:42 -0500 From: "Lubashev, Igor" To: Christian Huitema , QUIC WG Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAr+ayAAAX9L9A= Date: Tue, 19 Dec 2017 21:45:42 +0000 Message-ID: References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> In-Reply-To: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> 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.55] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190307 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190307 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, 19 Dec 2017 21:45:54 -0000 > My problem is that for RTP style applications, you don't want just partia= l reliability. You also want application frame delimitation [...] This is what this draft is trying to give you. >From Section 5 "Sender Interface and Behavior" "A typical sender would call an API function providing this functionality whenever any data previously enqueued for transmission expires, per application semantics. The sender would keep track of the message boundaries of such data." Hence, since the sender knows message boundaries (you call them "applicatio= n frame delimitation") within the data stream, the sender can choose the of= fset to expire data. The one thing this draft will NOT let you do is expir= e selective ranges of data within a data stream -- it only supports expirin= g "all data up to offset X". - Igor -----Original Message----- From: Christian Huitema [mailto:huitema@huitema.net]=20 Sent: Tuesday, December 19, 2017 2:31 PM To: Lubashev, Igor ; QUIC WG Subject: Re: draft-lubashev-quic-partial-reliability On 12/18/2017 7:39 PM, Lubashev, Igor wrote: > The high-level idea is that the sender keeps track of messages within=20 > a stream and can "expire" old messages whenever it wants.=A0 The=20 > "expiration" is a signal to the transport to not retransmit expired=20 > data (and a signal to the other endpoint that this data will not be=20 > retransmitted).=A0 All details are in the draft. I read your draft, and it does indeed provide "partial reliability." My pro= blem is that for RTP style applications, you don't want just partial reliab= ility. You also want application frame delimitation, such as delivering iso= lated VOIP frames, doing=A0 loss compensation, or implementing application = level FEC for large video frames. The streams in QUIC don't provide that. T= hey implement a "byte stream" abstraction, not a "packet stream". So I real= ly wonder whether FTP style applications are better served by adding partia= l reliability to the current concept of streams, or whether we should just = add a different service, maybe creating "RTP_STREAM" frames. -- Christian Huitema From nobody Tue Dec 19 13:48: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 3DEE212D85F for ; Tue, 19 Dec 2017 13:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHaV1QzN9kpz for ; Tue, 19 Dec 2017 13:48:11 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFDF1200FC for ; Tue, 19 Dec 2017 13:48:11 -0800 (PST) Received: from [81.187.2.149] (port=44197 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eRPk5-0001G1-2k; Tue, 19 Dec 2017 21:48:06 +0000 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8BE2E5E2-8A46-4E44-AF5E-4C636E035AE7" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: draft-lubashev-quic-partial-reliability Date: Tue, 19 Dec 2017 21:47:58 +0000 In-Reply-To: Cc: Christian Huitema , "Lubashev, Igor" , QUIC WG To: Ingemar Johansson S References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 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, 19 Dec 2017 21:48:14 -0000 --Apple-Mail=_8BE2E5E2-8A46-4E44-AF5E-4C636E035AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Dec 2017, at 20:31, Ingemar Johansson S = wrote: >=20 >> -----Original Message----- >> From: Christian Huitema [mailto:huitema@huitema.net] >> Sent: den 19 december 2017 20:31 >> To: Lubashev, Igor ; QUIC WG >> Subject: Re: draft-lubashev-quic-partial-reliability >>=20 >> On 12/18/2017 7:39 PM, Lubashev, Igor wrote: >>=20 >>> The high-level idea is that the sender keeps track of messages = within >>> a stream and can "expire" old messages whenever it wants. The >>> "expiration" is a signal to the transport to not retransmit expired >>> data (and a signal to the other endpoint that this data will not be >>> retransmitted). All details are in the draft. >>=20 >> I read your draft, and it does indeed provide "partial reliability." = My problem >> is that for RTP style applications, you don't want just partial = reliability. You >> also want application frame delimitation, such as delivering isolated = VOIP >> frames, doing loss compensation, or implementing application level = FEC for >> large video frames. The streams in QUIC don't provide that. They = implement >> a "byte stream" abstraction, not a "packet stream". So I really = wonder >> whether FTP style applications are better served by adding partial = reliability >> to the current concept of streams, or whether we should just add a = different >> service, maybe creating "RTP_STREAM" frames. >=20 > Thanks Christian, I now understand what I did not understand with the = partial-reliability draft. The reason is that I look at this from an RTP = point of view. To make QUIC {partial,un}reliable streams useful for real = time media then I agree that one need something like RTP_STREAM. With = that said I am not sure that RTP is the best common denominator around, = perhaps MEDIA_STREAM is a better alternative?, where one use the = abstraction media frames (video frames, audio frames...) instead ?, that = would allow support for other not RTP type packetization like for = instance MPEG-TS . RTP has many other features that will confuse if we=E2=80=99re not = careful=E2=80=A6 Framed messages, rather than unframed byte streams, = might be the key abstraction? Once we have that, partial reliability, = dependancies, deadlines, and unordered delivery become natural to add. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_8BE2E5E2-8A46-4E44-AF5E-4C636E035AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 19 Dec 2017, at 20:31, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

-----Original = Message-----
From: Christian Huitema [mailto:huitema@huitema.net]
Sent: den 19 = december 2017 20:31
To: Lubashev, Igor <ilubashe@akamai.com>; QUIC WG <quic@ietf.org>
Subject: Re: draft-lubashev-quic-partial-reliability

On 12/18/2017 7:39 PM, Lubashev, Igor = wrote:

The high-level idea is that the sender keeps track of = messages within
a stream and can "expire" old messages = whenever it wants.  The
"expiration" is a signal to = the transport to not retransmit expired
data (and a signal = to the other endpoint that this data will not be
retransmitted).  All details are in the draft.

I read your draft, and it does = indeed provide "partial reliability." My problem
is that = for RTP style applications, you don't want just partial reliability. = You
also want application frame delimitation, such as = delivering isolated VOIP
frames, doing  loss = compensation, or implementing application level FEC for
large video frames. The streams in QUIC don't provide that. = They implement
a "byte stream" abstraction, not a "packet = stream". So I really wonder
whether FTP style applications = are better served by adding partial reliability
to the = current concept of streams, or whether we should just add a different
service, maybe creating "RTP_STREAM" frames.

Thanks Christian, I now = understand what I did not understand with the partial-reliability draft. = The reason is that I look at this from an RTP point of view. To make = QUIC {partial,un}reliable streams useful for real time media then I = agree that one need something like RTP_STREAM. With that said I am not = sure that RTP is the best common denominator around, perhaps = MEDIA_STREAM is a better alternative?, where one use the abstraction = media frames (video frames, audio frames...) instead ?, that would allow = support for other not RTP type packetization like for instance MPEG-TS = .

RTP has many = other features that will confuse if we=E2=80=99re not careful=E2=80=A6 = Framed messages, rather than unframed byte streams, might be the key = abstraction? Once we have that, partial reliability, dependancies, = deadlines, and unordered delivery become natural to add.

-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_8BE2E5E2-8A46-4E44-AF5E-4C636E035AE7-- From nobody Tue Dec 19 13:58: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 B0B2D124BAC for ; Tue, 19 Dec 2017 13:58:54 -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, 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 5k1w1cUZfhIy for ; Tue, 19 Dec 2017 13:58:53 -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 EBA7A1200FC for ; Tue, 19 Dec 2017 13:58:52 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx19.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eRPuT-00063Z-7F for quic@ietf.org; Tue, 19 Dec 2017 22:58:50 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eRPuO-0005V5-CQ for quic@ietf.org; Tue, 19 Dec 2017 16:58:48 -0500 Received: (qmail 13729 invoked from network); 19 Dec 2017 21:58:43 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Dec 2017 21:58:43 -0000 To: Ian Swett , Ingemar Johansson S References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> Cc: "Lubashev, Igor" , QUIC WG From: Christian Huitema Message-ID: <496d69f0-8c88-134a-d80d-a4fcb07249f9@huitema.net> Date: Tue, 19 Dec 2017 13:58:52 -0800 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: draft-lubashev-quic-partial-reliability X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hQfmGMyLVXJokjUP4fI3lMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKNPILOWNIp50KNu32/z0EB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYfVCZ1my7qTGj+pYSPpnV3tZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xe5FFYx70dwpnXuYL0mrvA8FWxgXlWmTYKYIcQI2OJ epHQ4lRr5p6yleZoFrtpXFkHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFCFnwGKkv+DIQGXVP+Qhqh8ibYT4C2qF2lnc18bVJn66g m3XMthnh0ALITSE6NJwtyvmR2nbAco/KthuxWjUkZDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTcmOtKpb1oAulsHm1CrhdOljI1dRH6f16eQCtvwPkeoyl2uO1aNahU3xgdP6yeyunl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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, 19 Dec 2017 21:58:55 -0000 On 12/19/2017 12:48 PM, Ian Swett wrote: > For message style payloads commonly carried over UDP, like RTP, I > added an issue to create a MESSAGE frame for QUIC. Does that fit what > you have in mind? > https://github.com/quicwg/base-drafts/issues/814 Not quite. RTP has the concept of streams, with applications negotiating what stream carries what kind of media payload. They also have a concept of "sequence of messages", so they can determine which packets in a stream are missing and apply whatever corrective process is appropriate. And then there time stamps, and source identifiers... Applications could indeed use a MESSAGE frame and put their own RTP style headers inside it. But that feels like punting to the app. I am kind of hoping that we can do a bit better. -- Christian Huitema From nobody Tue Dec 19 17:21: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 0A88E128961 for ; Tue, 19 Dec 2017 17:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=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=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 4OZcFMMH4fv8 for ; Tue, 19 Dec 2017 17:21:38 -0800 (PST) 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 C252212AF77 for ; Tue, 19 Dec 2017 17:21:37 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBK1Gpnq022347; Wed, 20 Dec 2017 01:21:34 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=UcezZAw/sjXGGJS0ViFdnjVmwsXSiEFNVcKCFMJoqc4=; b=HY478c9z3pc/Rjdf0IAyJQzMMRwSoFx27Bu9hXwMd9EgF6RarkldouzFnh1JuzhCY/4m M7CznbBi38UWzt6E76G0CxbqlRiGf+Kmh14Xs5IAKj1GhQ8remtT2OxdYJMYT2m/a8uD AXmjVGwByDxbtWUjXr1KgaEVZpFCBU3uWENfv3dzINUiuphXNjINwpuW/1PzdCYgE/+V 9ONgCXIRIcd9s6T5HQQrFGBWPzqLwleholW3nUdL4VfG3QBoDCC1cdBZT4FUr6xqp29M V3bWcMqyomhpASpvmiqiN6UpNBSTgzrFOF/u1cdY7JOTdFT04DAElxUyzWv+/1bIgMVZ kA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2evs7v30xr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2017 01:21:33 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBK1LI5s018163; Tue, 19 Dec 2017 20:21:33 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2evypxxhj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 20:21:32 -0500 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.1263.5; Tue, 19 Dec 2017 20:21:32 -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.1263.000; Tue, 19 Dec 2017 20:21:32 -0500 From: "Lubashev, Igor" To: Ian Swett , Lucas Pardue CC: "quic@ietf.org" Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEAAXdj+AAANLonA= Date: Wed, 20 Dec 2017 01:21:31 +0000 Message-ID: <672822da83a74bd2b69634c881283331@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> 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.55] Content-Type: multipart/alternative; boundary="_000_672822da83a74bd2b69634c881283331usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200017 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200016 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, 20 Dec 2017 01:21:41 -0000 --_000_672822da83a74bd2b69634c881283331usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVGhpcyBwcm9wb3NhbCByZXF1aXJlcyBvdXQgb2Ygb3JkZXIgZGVsaXZlcnkgYmUgc3Vw cG9ydGVkIGJ5IFFVSUMgc3RyZWFtcw0KDQpJdCBkb2VzIG5vdC4gIEFsbCBkZWxpdmVyeSwgd2hl dGhlciBvZiBkYXRhIG9yIGdhcHMtaW4tZGF0YSwgaXMgc3RyaWN0bHkgaW4tb3JkZXIuICBJIGNh biBzZWUgYSByZWNlaXZlciBBUEkgbG9vayBzb21ldGhpbmcgbGlrZToNCg0KY2xhc3MgU3RyZWFt IHsNCiAgICAgIOKApg0Kc2l6ZV90IHJlY2VpdmUodm9pZCAqYnVmLCBzaXplX3QgYnVmX3NpemUp IHRocm93IFF1aWNrRXhjZXB0aW9uOw0Kc2l6ZV90IHJlY2VpdmUoc2l6ZV90ICZleHBpcmVkX2J5 dGVzLCB2b2lkICpidWYsIHNpemVfdCBidWZfc2l6ZSkgdGhyb3cgUXVpY2tFeGNlcHRpb247DQri gKYNCn07DQoNClRoZSB2ZXJzaW9uIG9mIHJlY2VpdmUgd2l0aCBleHBpcmVkX2J5dGVzIHdpbGwg cmV0dXJuIGhvdyBtYW55IGJ5dGVzIGhhdmUgZXhwaXJlZCBmb2xsb3dlZCBieSB0aGUgZGF0YSBy ZWNlaXZlZCBpbiBidWYuICBDbGllbnRzIHRoYXQgZG8gbm90IGV4cGVjdCBtaXNzaW5nIG1lc3Nh Z2VzIHdpbGwganVzdCBjYWxsIHRoZSB2ZXJzaW9uIG9mIHJlY2VpdmUoKSB3L28gZXhwaXJlZF9i eXRlcyBhbmQgd2lsbCBnZXQgYW4gZXhjZXB0aW9uIGlmIGFueSBkYXRhIGlzIGV4cGlyZWQuICAg KEFQSXMgdGhhdCBhcmUgZXZlbnQgY2FsbGJhY2sgYmFzZWQgd2lsbCBqdXN0IGRlY2xhcmUgYSBu ZXcgc3RyZWFtIGV2ZW50IHR5cGUg4oCcU3RyZWFtRXhwaXJlZERhdGHigJ0uKQ0KDQoNCg0KDQog ICogICBBbHNvLCB0aGUgcmVjZWl2ZXIgbmVlZHMgdG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hh dCB0aGUgbWVzc2FnZSBib3VuZGFyaWVzIGFyZSBpZiB0aGVyZSBhcmUgZ2FwcyBpbiB0aGUgc3Ry ZWFtLg0KDQpJdCB3aWxsIG5vdC4gIFNpbmNlIHNlbmRlciBrZWVwcyB0cmFjayBvZiB3aGVyZSBt ZXNzYWdlIGJvdW5kYXJpZXMgYXJlIGFuZCBjb250cm9scyBtaW5pbXVtIHJldHJhbnNtaXR0YWJs ZSBvZmZzZXQsIHRoZSByZWNlaXZlciBpcyBndWFyYW50ZWVkIHRoYXQgYW55IGRhdGEgYWZ0ZXIg YSBnYXAgY29ycmVzcG9uZHMgdG8gdGhlIHN0YXJ0IG9mIGEgbmV3IG1lc3NhZ2UuDQooTUFZIGlu IFNlY3Rpb24gNiDigJxSZWNlaXZlciBJbnRlcmZhY2UgYW5kIEJlaGF2aW9y4oCdIGlzIG5vdCBh IE1VU1QgdG8gYWxsb3cgZm9yIGFuIG9wdGltaXphdGlvbiBvZiBrZWVwaW5nIGRhdGEgdGhhdCBo YXMgYXJyaXZlZCBhZnRlciBNSU5fU1RSRUFNX0RBVEEgZHVlIHRvIHJlb3JkZXJpbmcsIGlmIHRo ZSBhcHBsaWNhdGlvbiBoYXMgbm90IHlldCBiZWVuIG5vdGlmaWVkIGFib3V0IHRoZSBkYXRhIGdh cC4pDQoNCg0KDQogICogICBDYW4gYSBTVFJFQU0gZnJhbWUgY29udGFpbiB0aGUgZW5kIG9mIG9u ZSBtZXNzYWdlIGFuZCB0aGUgYmVnaW5uaW5nIG9mIGFub3RoZXIgaW4gYSBzaW5nbGUgZnJhbWU/ DQoNClllcywgaXQgY2FuLCBzaW5jZSBub3RoaW5nIGlzIGNoYW5nZWQgaW4gdGhlIGJlaGF2aW9y IG9mIFNUUkVBTSBmcmFtZXMuICBUaGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBhcHBsaWNhdGlv biBjYW4gZmlndXJlIG91dCBpdHNlbGYgaG93IGxvbmcgZWFjaCBmdWxseS1kZWxpdmVyZWQgbWVz c2FnZSBpcy4NCg0KDQoNCiAgKiAgIEluIHNlY3Rpb24gNCwgeW91IGRpc2N1c3MgdGhlIHNlcGFy YXRpb24gb2YgVW5zZW50IGJ5dGVzIGZyb20gU2VudCBkYXRhLCBidXQgSSdtIHN0aWxsIGNvbmZ1 c2VkIG9uIHRoZSBtb3RpdmF0aW9uIHRoZXJlLCBzaW5jZSBzZXBhcmF0aW5nIHRoZW0gc2VlbXMg dG8gbWFrZSBmbG93IGNvbnRyb2wgbW9yZSBjb21wbGV4Lg0KDQpJIGd1ZXNzIEkgZmFpbGVkIHRv IGJlIGNsZWFyIGhlcmUsIGFzIFVuc2VudCBCeXRlcyB3YXMgZGVzaWduZWQgdG8gTk9UIGNvbXBs aWNhdGUgZmxvdyBjb250cm9sIGFjY291bnRpbmcgKGluIGZhY3QsIGl0IGhhcyBubyBlZmZlY3Qg b24gZmxvdyBjb250cm9sIGFjY291bnRpbmcgYXQgYWxsKS4NCg0KSW1hZ2luZSBhbiBIRCB2aWRl byBjb25mZXJlbmNpbmcgYXBwIGhhcyBzZW50IDEwTUIgb2YgZGF0YSB0byBhIHN0cmVhbSAobWF5 YmUgaW4gbXVsdGlwbGUgbWVzc2FnZXMpLiAgTm93LCBzYXksIGl0IHdhcyBvbmx5IGFibGUgdG8g dHJhbnNtaXQgMU1CIG91dCBvZiB0aG9zZSAxME1CIHdoZW4gYSBuZXcga2V5IGZyYW1lIGlzIHJl Y2VpdmVkLg0KDQpJZiBpdCBoYXMgdG8gdXNlIG5vcm1hbCBzdHJlYW0gYW5kIGNvbm5lY3Rpb24g ZmxvdyBjb250cm9sIGNyZWRpdHMgdG8gYWR2YW5jZSB0aGlzIHN0cmVhbSBieSB0aGUgYWRkaXRp b25hbCA5TUIsIGl0IG1heSBtaWdodCBub3QgYmUgYWJsZSB0byBkbyBzbyB3L28gdmlvbGF0aW5n IE1BWF9TVFJFQU1fREFUQSBvciBNQVhfREFUQS4gIFRoZSBzZW5kZXIgd291bGQgbmVlZCB0byDi gJxza2lw4oCdIHRob3NlIDlNQiBvdmVyIHNldmVyYWwgUlRUcywgaWYgdGhlIHJlY2VpdmVyIGlz IG9ubHkgd2lsbGluZyB0byBjb21taXQsIHNheSwgMk1CIG9mIGJ1ZmZlcnMgdG8gdGhpcyBzdHJl YW0vY29ubmVjdGlvbiAoaXQgaXMgbm90IGF3YXJlIHRoYXQgdGhlIHNlbmRlciBoYXMgOU1CIG9m IG9jdGV0cyB0byBza2lwKS4gIE1vcmVvdmVyLCB0aGlzIHdvdWxkIGJlIGJsb2NraW5nIGFsbCBv dGhlciBzdHJlYW1zIGZyb20gbWFraW5nIHByb2dyZXNzIGJ5IGNsb3NpbmcgZG93biB0aGUgY29u bmVjdGlvbiB3aW5kb3cuDQoNClVuc2VudCBCeXRlcyB3YXMgZGVzaWduZWQgdG8gc29sdmUgdGhp cyBwcm9ncmFtLCBhcyBpdCAqZG9lcyBub3QgY291bnQgdG93YXJkIHN0cmVhbSBvciBjb25uZWN0 aW9uIGZsb3cgY29udHJvbCogKHNvIGl0IGRvZXMgbm90IHZpb2xhdGUgdGhlbSBhbmQgZG9lcyBu b3QgcmVkdWNlIGNvbm5lY3Rpb24gd2luZG93KSwgYnV0IGl0IGlzIGEgaGludCB0byBvcGVuIHRo ZSBzdHJlYW0gYW5kIGNvbm5lY3Rpb24gd2luZG93cyB0byBhY2NvbW1vZGF0ZSBza2lwcGluZyBi eXRlIG9jdGV0cyAoc2luY2UgdGhleSBkbyBub3QgcmVxdWlyZSBhbnkgYnVmZmVyIHNwYWNlKS4g IFRoZSBzdHJlYW0gd291bGQgYmUgYWJsZSB0byByZXN1bWUgaW4gYXQgbW9zdCAxIHJ0dCwgYW5k IGl0IHdvdWxkIG5vdCBibG9jayBvdGhlciBzdHJlYW1zIG1lYW53aGlsZS4NCg0KSG93ZXZlciwg SSBub3cgc2VlIGEgcHJvYmxlbSDigJMgd2hpbGUgb3BlbmluZyB0aGUgc3RyZWFtIHdpbmRvdyBi eSA5TUIrIGlzIG9rIChzaW5jZSBhbnkgb2N0ZXRzIGF0IG9mZnNldCBsb3dlciB0aGFuIE1pbiBT dHJlYW0gT2Zmc2V0IGFyZSB0byBiZSBkaXNjYXJkZWQpLCB0aGVyZSBpcyBubyByZXF1aXJlbWVu dCB0aGF0IHRoZSBleHRyYSBjb25uZWN0aW9uIHdpbmRvdyBpcyB1c2VkIGZvciB0aGF0IHN0cmVh bSBvbmx5LiAgQSBtYWxpY2lvdXMgY2xpZW50IGNhbiByZW5kZXIgY29ubmVjdGlvbiB3aW5kb3cg bWVhbmluZ2xlc3MgYnkgc2VuZGluZyBNSU5fU1RSRUFNX0RBVEEgd2l0aCBhIGh1Z2UgVW5zZW50 IEJ5dGVzIGFuZCB0aGVuIG5ldmVyIHNlbmRpbmcgb24gdGhhdCBzdHJlYW0gYWdhaW4uICBPb3Bz ISAgSSB3aWxsIGZpeCB0aGlzIQ0KDQoNCg0KDQogICogICBJIGJlbGlldmUgdGhlcmUgaXMgYW5v dGhlciBjaGFsbGVuZ2UsIHdoaWNoIGlzIGluZGljYXRpbmcgdG8gdGhlIHJlY2VpdmVyIHdoZW4g dGhleSBzaG91bGQgc3RvcCBleHBlY3RpbmcgdG8gcmVjZWl2ZSBkYXRhLiAgQ29udmVuaWVudGx5 LCB0aGlzIGlzIGV4YWN0bHkgd2hhdCBNSU5fU1RSRUFNX0RBVEEgZG9lcywgYnV0IEkgdGhpbmsg aXQncyB3b3J0aCBub3RpbmcgaW4gdGhlIGludHJvZHVjdGlvbi4NCg0KSSBtZWFudCBleGFjdGx5 IHRoaXMgYnkg4oCcbm90aWZ5aW5nIHRoZSB0cmFuc3BvcnQgYW5kIHRoZSBwZWVyIHdoZW4gZGF0 YSBwcmV2aW91c2x5IGVucXVldWVkIGZvciB0cmFuc21pc3Npb24gbm8gbG9uZ2VyIG5lZWRzIHRv IGJlIHRyYW5zbWl0dGVk4oCcICh0aGF04oCZcyB3aGF0IOKAnGFuZCB0aGUgcGVlcuKAnSB3YXMg Zm9yKSBidXQgc2FpZCBpdCB2ZXJ5IGF3a3dhcmRseS4gIFdpbGwgZml4IGJ5IGZvY3VzaW5nIG9u bHkgb24gdGhlIHBlZXIgKGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGFwcCBhbmQgbG9jYWwgdHJh bnNwb3J0IGRvZXMgbm90IGNvbmNlcm4gd2lyZSBwcm90b2NvbCkuDQoNCg0KDQogICogICBJZ29y DQoNCg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2Vu dDogVHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgMzoyMCBQTQ0KVG86IEx1Y2FzIFBhcmR1ZSA8 THVjYXMuUGFyZHVlQGJiYy5jby51az4NCkNjOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWth bWFpLmNvbT47IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBkcmFmdC1sdWJhc2hldi1xdWlj LXBhcnRpYWwtcmVsaWFiaWxpdHkNCg0KVGhhbmtzIGZvciB3cml0aW5nIHRoaXMgdXAgSWdvciwg aXQncyBhbiBpbnRlcmVzdGluZyBpZGVhLCBhbmQgSSBsaWtlIGhvdyBpdCBhbGxvd3MgYW55IHN0 cmVhbSBiZXNpZGVzIDAgdG8gYmUgcGFydGlhbGx5IHJlbGlhYmxlLiAgSSdtIGEgYml0IGNvbmNl cm5lZChvciBwb3NzaWJseSBjb25mdXNlZCkgYWJvdXQgdGhlIGVmZm9ydCB0byBjaGFuZ2UgaG93 IGZsb3cgY29udHJvbCB3b3Jrcywgc2VlIGNvbW1lbnRzIGJlbG93LiAgSSBiZWxpZXZlIHRoaXMg cHJvcG9zYWwgaW1wbGljaXRseSBhc3N1bWVzIHRoYXQgaXQncyBlYXNpZXIgYW5kIG1vcmUgZWZm aWNpZW50IHRvIHVzZSBzdHJlYW1zIGZvciBvcmRlcmluZyBhbmQgbWFrZSB0aGUgYXBwbGljYXRp b24gZGVhbCB3aXRoIGludGVycHJldGluZyBvdXQgb2Ygb3JkZXIgZGF0YSB0aGFuIHRoZSBjdXJy ZW50IG1vZGVsIG9mIG1ha2luZyBhcHBsaWNhdGlvbnMgcmVvcmRlciBhIGxhcmdlIG51bWJlciBv ZiBzbWFsbCBzdHJlYW1zPyAgVGhhdCBtYXkgb3IgbWF5IG5vdCBiZSB0cnVlIGluIGEgZ2l2ZW4g YXBwbGljYXRpb24sIGJ1dCBJIGNhbiBpbWFnaW5lIGNhc2VzIHdoZW4gaXQgaXMgdHJ1ZS4NCg0K QXQgdGhlIGJlZ2lubmluZyB5b3Ugc2F5Og0KIlRoZSBrZXkgdG8gcGFydGlhbCByZWxpYWJsaXR5 IGlzIG5vdGlmeWluZyB0aGUgdHJhbnNwb3J0IGFuZCB0aGUgcGVlcg0KIHdoZW4gZGF0YSBwcmV2 aW91c2x5IGVucXVldWVkIGZvciB0cmFuc21pc3Npb24gbm8gbG9uZ2VyIG5lZWRzIHRvIGJlDQog dHJhbnNtaXR0ZWQuIg0KDQpJIGJlbGlldmUgdGhlcmUgaXMgYW5vdGhlciBjaGFsbGVuZ2UsIHdo aWNoIGlzIGluZGljYXRpbmcgdG8gdGhlIHJlY2VpdmVyIHdoZW4gdGhleSBzaG91bGQgc3RvcCBl eHBlY3RpbmcgdG8gcmVjZWl2ZSBkYXRhLiAgQ29udmVuaWVudGx5LCB0aGlzIGlzIGV4YWN0bHkg d2hhdCBNSU5fU1RSRUFNX0RBVEEgZG9lcywgYnV0IEkgdGhpbmsgaXQncyB3b3J0aCBub3Rpbmcg aW4gdGhlIGludHJvZHVjdGlvbi4NCg0KSW4gdGVybXMgb2YgdGhlIGRvd25zaWRlcyBvZiB1c2lu ZyBzdHJlYW1zIGFzIGlzLCB5b3Ugc2F5Og0KIkhlbmNlLCBhIG1lc3NhZ2UtcGVyLXN0cmVhbQ0K IGFwcHJvYWNoIHJlcXVpcmVzIGVhY2ggbWVzc2FnZSB0byBjb250YWluIGFuIGV4dHJhIGhlYWRl ciBwb3J0aW9uIHRvDQogYXNzb2NpYXRlIHRoZSBtZXNzYWdlIHdpdGggYSBsb2dpY2FsIGFwcGxp Y2F0aW9uIHN0cmVhbS4gIEluIGNhc2Ugb2YNCiBzaG9ydCBtZXNzYWdlcywgdGhpcyBhcHByb2Fj aCBpbnRyb2R1Y2VzIGEgc2lnbmlmaWNhbnQgb3ZlcmhlYWQgZHVlDQogdG8gU1RSRUFNIGZyYW1l cyBhbmQgbWVzc2FnZSBoZWFkZXJzLiAgSXQgYWxzbyBwbGFjZXMgdGhlIGJ1cmRlbiBvbg0KIHRo ZSBhcHBsaWNhdGlvbiB0byByZW9yZGVyIGRhdGEgYXJyaXZpbmcgb24gbXVsdGlwbGUgUVVJQyBz dHJlYW1zLiINCg0KSW4gcHJhY3RpY2UsIEkgYmVsaWV2ZSBhIGxvdCBvZiBhcHBsaWNhdGlvbnMg dXNpbmcgcGFydGlhbCByZWxpYWJpbGl0eSB0b2RheSBoYXZlIHN1Y2ggaGVhZGVycywgc2luY2Ug dGhleSdyZSBjb21tb25seSBkZXNpZ25lZCB3aXRoIFVEUCBpbiBtaW5kLg0KDQpJbiBzZWN0aW9u IDQsIHlvdSBkaXNjdXNzIHRoZSBzZXBhcmF0aW9uIG9mIFVuc2VudCBieXRlcyBmcm9tIFNlbnQg ZGF0YSwgYnV0IEknbSBzdGlsbCBjb25mdXNlZCBvbiB0aGUgbW90aXZhdGlvbiB0aGVyZSwgc2lu Y2Ugc2VwYXJhdGluZyB0aGVtIHNlZW1zIHRvIG1ha2UgZmxvdyBjb250cm9sIG1vcmUgY29tcGxl eC4gIEN1cnJlbnRseSB0aGUgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgdXNlZCBpcyB0aGUgc3Vt IG9mIHRoZSBsYXJnZXN0IGJ5dGUgb2Zmc2V0cyBvZiBhbGwgc3RyZWFtcyBvbiBhIGNvbm5lY3Rp b24sIGFuZCBub3cgdGhhdCB3b3VsZCBiZSBkcmFtYXRpY2FsbHkgZGlmZmVyZW50LCBjb3JyZWN0 PyAgQ2FuIHlvdSBhZGQgbW9yZSBiYWNrZ3JvdW5kIG9uIHdoeSB0aGVzZSBhcmUgc2VwYXJhdGVk IGFuZCBob3cgdGhleSBhcmUgYXBwbGllZCB0byB2YXJpb3VzIGxpbWl0cz8gIElmIEkgcmVhZCBj b3JyZWN0bHksIE1JTl9TVFJFQU1fREFUQSBmcmFtZSBpcyBlZmZlY3RpdmVseSBhYmxlIHRvIGlu Y3JlYXNlIGEgcGVlcidzIGZsb3cgY29udHJvbCBsaW1pdHMgYnkgZGVjbGFyaW5nIHByZXZpb3Vz bHkgdXNlZCBjcmVkaXRzIHVwIGZvciBncmFicz8NCg0KVGhpcyBwcm9wb3NhbCByZXF1aXJlcyBv dXQgb2Ygb3JkZXIgZGVsaXZlcnkgYmUgc3VwcG9ydGVkIGJ5IFFVSUMgc3RyZWFtcywgd2hpY2gg aXMgd29ydGggZXhwbGljaXRseSBub3RpbmcsIG1heWJlIGluIHNlY3Rpb24gNSwgc2luY2UgaXQn cyBjdXJyZW50bHkgbm90IHJlcXVpcmVkLiAgQWxzbywgdGhlIHJlY2VpdmVyIG5lZWRzIHRvIGJl IGFibGUgdG8gZGV0ZXJtaW5lIHdoYXQgdGhlIG1lc3NhZ2UgYm91bmRhcmllcyBhcmUgaWYgdGhl cmUgYXJlIGdhcHMgaW4gdGhlIHN0cmVhbS4gIEhvdyBlYXN5IHRoYXQgaXMgd291bGQgZGVwZW5k IHVwb24gd2hhdCBpcyBiZWluZyBzZW50IG9uIHRoZSBzdHJlYW0uICBJdCBtaWdodCBkZXNlcnZl IHNvbWUgZGlzY3Vzc2lvbiBhYm91dCBob3cgb25lIG1pZ2h0IGRvIHRoaXMgYW5kIHdoYXQgcmVz dHJpY3Rpb25zIHNob3VsZCBiZSBpbXBvc2VkIG9uIGhvdyB0aGUgc2VuZGVyIGJ1bmRsZXMgZGF0 YSwgaWYgdGhhdCBlbmRzIHVwIGJlaW5nIG5lY2Vzc2FyeT8gIGllOiBDYW4gYSBTVFJFQU0gZnJh bWUgY29udGFpbiB0aGUgZW5kIG9mIG9uZSBtZXNzYWdlIGFuZCB0aGUgYmVnaW5uaW5nIG9mIGFu b3RoZXIgaW4gYSBzaW5nbGUgZnJhbWU/DQoNCg0KT24gVHVlLCBEZWMgMTksIDIwMTcgYXQgMTA6 NDYgQU0sIEx1Y2FzIFBhcmR1ZSA8THVjYXMuUGFyZHVlQGJiYy5jby51azxtYWlsdG86THVjYXMu UGFyZHVlQGJiYy5jby51az4+IHdyb3RlOg0KSWdvciB3cm90ZToNCg0KVGhlIGJvb2trZWVwaW5n IGlzIHNpbXBsZSBlbm91Z2ggYW5kIHRoZSBydW50aW1lIHJlc291cmNlcyByZXF1aXJlZCBpcyBq dXN0IG9uZSB1aW50NjRfdCBwZXIgc3RlYW0sIHNvIEkgZG8gbm90IHNlZSBhIHByb2JsZW0gZm9y IGNvbnN0cmFpbmVkIGRldmljZXMuDQpVbHRpbWF0ZWx5LCBwYXJ0aWFsIHJlbGlhYmlsaXR5IGlz IGEgZmVhdHVyZSB0aGF0IGFuIGFwcGxpY2F0aW9uIGVpdGhlciBuZWVkcyBvciBkb2VzIG5vdC4g SWYgYW4gYXBwbGljYXRpb24gbmVlZHMgaXQsIGl0IG1vc3QgbGlrZWx5IHJlcXVpcmVzIGl0LiBJ biBhbnkgY2FzZSwgYW4gYXBwbGljYXRpb24gY2FuIGRvIGl0cyBvd24gbmVnb3RpYXRpb24gaWYg aXQgZGVzaXJlcyB0byBkbyBzby4gRm9yIGV4YW1wbGUsIGl0IGNhbiB1c2Ugc3RyZWFtIDEgZm9y IHRoYXQuDQpOb3cgSSB1bmRlcnN0YW5kIHRoaXMgaXMgY29ubmVjdGlvbi13aWRlLCBJIGdlbmVy YWxseSBhZ3JlZS4gSG93ZXZlciwgZm9yIHNvbWV0aGluZyBsaWtlIGNvbnZlbnRpb25hbCBIVFRQ L1FVSUMsIHRoZSByZWxpYWJsZSBndWFyYW50ZWUgYXNzdXJhbmNlcyBhcmUgcmVxdWlyZWQgYnkg dGhlIG1hcHBpbmcuIElmIHBhcnRpYWwgcmVsaWFiaWxpdHkgaXMgZGVmYXVsdCBlbmFibGVkIHRy YW5zcG9ydCBmZWF0dXJlLCBhcHBsaWNhdGlvbnMgbGlrZSBIVFRQL1FVSUMgbXVzdCByZXN0cmlj dCBvciBkaXNhYmxlIGl0IOKAkyBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgZWRpdG9ycy9kcmFmdHMg aGF2ZSBicm9hY2hlZCB0aGF0IHN1YmplY3QgeWV0IChJ4oCZdmUgY2VydGFpbmx5IGhhZCBzb21l IGZlZWRiYWNrIG9uIG15IGRyYWZ0IGFib3V0IHN1Y2ggcmVzdHJpY3Rpb25zKS4NCg0KSSBkaWQg bm90IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGxhc3QgcXVlc3Rpb24uIEFyZSB5b3UgYXNraW5nIHdo ZXRoZXIgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBjb25uZWN0aW9uIHRvIG5lZ290aWF0ZSBqdXN0 IGEgc2luZ2xlIHN0cmVhbSAoaW4gZWFjaCBkaXJlY3Rpb24pIHRoYXQgd291bGQgYmUgcGFydGlh bGx5IHJlbGlhYmxlIGFuZCwgdGhlcmVmb3JlLCBub3Qgc2VuZCBhIHN0cmVhbSBpZCB3aXRoIE1J Tl9TVFJFQU1fREFUQT8gSSBjb3VsZCBhY3R1YWxseSB0aGluayBvZiBhIHZlcnNpb24gb2YgTUlO X1NUUkVBTV9EQVRBIHRoYXQgaGFzIGFuIGltcGxpZWQgc3RyZWFtIGlkIC0tIHRoZSBzdHJlYW0g aWQgb2YgYSBwcmlvci9mb2xsb3dpbmcgU1RSRUFNIGZyYW1lIGluIHRoZSBzYW1lIHBhY2tldC4g VGhhdCB3b3VsZCBiZSBhbiBvcHRpbWl6YXRpb24gdGhhdCBJIGFtIGhhcHB5IHRvIGFkZCwgaWYg dGhlcmUgaXMgZW5vdWdoIHN1cHBvcnQgZm9yIGl0Lg0KDQpBcG9sb2dpZXMsIEkgaGFkbuKAmXQg ZHJ1bmsgYW55IGNvZmZlZSB3aGVuIGZpcnN0IHJlcGx5aW5nIGFuZCBnb3QgbXlzZWxmIGNvbmZ1 c2VkLiBBbGwgUVVJQyBmcmFtZXMgb2YgdGhpcyBuYXR1cmUgc2hvdWxkIG5vcm1hbGx5IGluY2x1 ZGUgYSBTdHJlYW0gSUQsIHdoaWNoIGlkZW50aWZpZXMgdGhlIHN0cmVhbSBpdCBpcyBzZW50IG9u LiBJIHRoaW5rIHlvdXIgc3VnZ2VzdGlvbiByZWxpZXMgb24gc2VyaWFsIG9yZGVyaW5nL3Byb2Nl c3NpbmcgKGV2ZW4gaW5zaWRlIGEgcGFja2V0KSwgd2hpY2ggbWlnaHQgYmUgYSBoYXJkIHNlbGwu DQoNClNlcGFyYXRlbHksIGluIHRlcm1zIG9mIGFzeW1tZXRyeSwgSSB3YXMgdGhpbmtpbmcgdGhh dCB5b3UgbWlnaHQgYWx3YXlzIHdhbnQgKGFzIGEgcG9saWN5KSBjbGllbnRzIHRvIHRyYW5zbWl0 IHdpdGggZnVsbCByZWxpYWJpbGl0eSBidXQgcHJvdmlkZSBkYXRhIHRvIHRoZW0gd2l0aCBwYXJ0 aWFsIHJlbGlhYmlsaXR5LiBJIHRoaW5rIHRoaXMgaXMgYWdhaW4gYW4gYXBwbGljYXRpb24gbWFw cGluZyBjb25jZXJuLg0KDQpSZWdhcmRzLA0KTHVjYXMNCg0KDQo= --_000_672822da83a74bd2b69634c881283331usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjYzMTMyNjIyMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTIwNzMwMTYyMTIgLTEzNTk5NTgzMzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 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 Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTI4Nzc0 MDMyODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Nzkw NDE3NTAgLTIwNzY0MTgyMTggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlRoaXMgcHJv cG9zYWwgcmVxdWlyZXMgb3V0IG9mIG9yZGVyIGRlbGl2ZXJ5IGJlIHN1cHBvcnRlZCBieSBRVUlD IHN0cmVhbXM8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgZG9lcyBub3QuJm5ic3A7 IEFsbCBkZWxpdmVyeSwgd2hldGhlciBvZiBkYXRhIG9yIGdhcHMtaW4tZGF0YSwgaXMgc3RyaWN0 bHkgaW4tb3JkZXIuJm5ic3A7IEkgY2FuIHNlZSBhIHJlY2VpdmVyIEFQSSBsb29rIHNvbWV0aGlu ZyBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj5jbGFzcyBTdHJlYW0gezxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXMiPnNpemVfdCByZWNlaXZlKHZvaWQgKmJ1 Ziwgc2l6ZV90IGJ1Zl9zaXplKSB0aHJvdyBRdWlja0V4Y2VwdGlvbjs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj5zaXplX3QgcmVjZWl2ZShzaXplX3QgJmFt cDtleHBpcmVkX2J5dGVzLCB2b2lkICpidWYsIHNpemVfdCBidWZfc2l6ZSkgdGhyb3cgUXVpY2tF eGNlcHRpb247PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcyI+ 4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzIj59OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHZlcnNpb24gb2YgcmVjZWl2ZSB3aXRoIGV4cGlyZWRfYnl0ZXMgd2lsbCByZXR1cm4g aG93IG1hbnkgYnl0ZXMgaGF2ZSBleHBpcmVkIGZvbGxvd2VkIGJ5IHRoZSBkYXRhIHJlY2VpdmVk IGluIGJ1Zi4mbmJzcDsgQ2xpZW50cyB0aGF0IGRvIG5vdCBleHBlY3QgbWlzc2luZyBtZXNzYWdl cyB3aWxsIGp1c3QgY2FsbCB0aGUgdmVyc2lvbiBvZiByZWNlaXZlKCkgdy9vIGV4cGlyZWRfYnl0 ZXMgYW5kIHdpbGwgZ2V0DQogYW4gZXhjZXB0aW9uIGlmIGFueSBkYXRhIGlzIGV4cGlyZWQuJm5i c3A7Jm5ic3A7IChBUElzIHRoYXQgYXJlIGV2ZW50IGNhbGxiYWNrIGJhc2VkIHdpbGwganVzdCBk ZWNsYXJlIGEgbmV3IHN0cmVhbSBldmVudCB0eXBlIOKAnFN0cmVhbUV4cGlyZWREYXRh4oCdLik8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5BbHNvLCB0aGUgcmVjZWl2ZXIg bmVlZHMgdG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hhdCB0aGUgbWVzc2FnZSBib3VuZGFyaWVz IGFyZSBpZiB0aGVyZSBhcmUgZ2FwcyBpbiB0aGUgc3RyZWFtLjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JdCB3aWxsIG5vdC4mbmJzcDsgU2luY2Ugc2VuZGVyIGtlZXBzIHRyYWNrIG9m IHdoZXJlIG1lc3NhZ2UgYm91bmRhcmllcyBhcmUgYW5kIGNvbnRyb2xzIG1pbmltdW0gcmV0cmFu c21pdHRhYmxlIG9mZnNldCwgdGhlIHJlY2VpdmVyIGlzIGd1YXJhbnRlZWQgdGhhdCBhbnkgZGF0 YSBhZnRlciBhIGdhcCBjb3JyZXNwb25kcyB0byB0aGUgc3RhcnQgb2YgYSBuZXcgbWVzc2FnZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihNQVkgaW4gU2VjdGlvbiA2IOKA nFJlY2VpdmVyIEludGVyZmFjZSBhbmQgQmVoYXZpb3LigJ0gaXMgbm90IGEgTVVTVCB0byBhbGxv dyBmb3IgYW4gb3B0aW1pemF0aW9uIG9mIGtlZXBpbmcgZGF0YSB0aGF0IGhhcyBhcnJpdmVkIGFm dGVyIE1JTl9TVFJFQU1fREFUQSBkdWUgdG8gcmVvcmRlcmluZywgaWYgdGhlIGFwcGxpY2F0aW9u IGhhcyBub3QgeWV0IGJlZW4gbm90aWZpZWQgYWJvdXQgdGhlIGRhdGEgZ2FwLik8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+Q2FuIGEgU1RSRUFNIGZy YW1lIGNvbnRhaW4gdGhlIGVuZCBvZiBvbmUgbWVzc2FnZSBhbmQgdGhlIGJlZ2lubmluZyBvZiBh bm90aGVyIGluIGEgc2luZ2xlIGZyYW1lPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z ZXMsIGl0IGNhbiwgc2luY2Ugbm90aGluZyBpcyBjaGFuZ2VkIGluIHRoZSBiZWhhdmlvciBvZiBT VFJFQU0gZnJhbWVzLiZuYnNwOyBUaGUgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBhcHBsaWNhdGlv biBjYW4gZmlndXJlIG91dCBpdHNlbGYgaG93IGxvbmcgZWFjaCBmdWxseS1kZWxpdmVyZWQgbWVz c2FnZSBpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+SW4gc2VjdGlvbiA0LCB5b3UgZGlzY3VzcyB0aGUgc2VwYXJhdGlvbiBvZiBVbnNlbnQgYnl0 ZXMgZnJvbSBTZW50IGRhdGEsIGJ1dCBJJ20gc3RpbGwgY29uZnVzZWQgb24gdGhlIG1vdGl2YXRp b24gdGhlcmUsIHNpbmNlIHNlcGFyYXRpbmcgdGhlbSBzZWVtcyB0byBtYWtlIGZsb3cgY29udHJv bCBtb3JlIGNvbXBsZXguPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgSSBm YWlsZWQgdG8gYmUgY2xlYXIgaGVyZSwgYXMgVW5zZW50IEJ5dGVzIHdhcyBkZXNpZ25lZCB0byBO T1QgY29tcGxpY2F0ZSBmbG93IGNvbnRyb2wgYWNjb3VudGluZyAoaW4gZmFjdCwgaXQgaGFzIG5v IGVmZmVjdCBvbiBmbG93IGNvbnRyb2wgYWNjb3VudGluZyBhdCBhbGwpLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbWFnaW5lIGFuIEhEIHZpZGVvIGNvbmZlcmVuY2luZyBhcHAgaGFzIHNlbnQg MTBNQiBvZiBkYXRhIHRvIGEgc3RyZWFtIChtYXliZSBpbiBtdWx0aXBsZSBtZXNzYWdlcykuJm5i c3A7IE5vdywgc2F5LCBpdCB3YXMgb25seSBhYmxlIHRvIHRyYW5zbWl0IDFNQiBvdXQgb2YgdGhv c2UgMTBNQiB3aGVuIGEgbmV3IGtleSBmcmFtZSBpcyByZWNlaXZlZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SWYgaXQgaGFzIHRvIHVzZSBub3JtYWwgc3RyZWFtIGFuZCBjb25uZWN0aW9uIGZs b3cgY29udHJvbCBjcmVkaXRzIHRvIGFkdmFuY2UgdGhpcyBzdHJlYW0gYnkgdGhlIGFkZGl0aW9u YWwgOU1CLCBpdCBtYXkgbWlnaHQgbm90IGJlIGFibGUgdG8gZG8gc28gdy9vIHZpb2xhdGluZyBN QVhfU1RSRUFNX0RBVEEgb3IgTUFYX0RBVEEuJm5ic3A7IFRoZSBzZW5kZXIgd291bGQgbmVlZCB0 byDigJxza2lw4oCdIHRob3NlIDlNQiBvdmVyDQogc2V2ZXJhbCBSVFRzLCBpZiB0aGUgcmVjZWl2 ZXIgaXMgb25seSB3aWxsaW5nIHRvIGNvbW1pdCwgc2F5LCAyTUIgb2YgYnVmZmVycyB0byB0aGlz IHN0cmVhbS9jb25uZWN0aW9uIChpdCBpcyBub3QgYXdhcmUgdGhhdCB0aGUgc2VuZGVyIGhhcyA5 TUIgb2Ygb2N0ZXRzIHRvIHNraXApLiZuYnNwOyBNb3Jlb3ZlciwgdGhpcyB3b3VsZCBiZSBibG9j a2luZyBhbGwgb3RoZXIgc3RyZWFtcyBmcm9tIG1ha2luZyBwcm9ncmVzcyBieSBjbG9zaW5nIGRv d24gdGhlDQogY29ubmVjdGlvbiB3aW5kb3cuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuc2Vu dCBCeXRlcyB3YXMgZGVzaWduZWQgdG8gc29sdmUgdGhpcyBwcm9ncmFtLCBhcyBpdCAqZG9lcyBu b3QgY291bnQgdG93YXJkIHN0cmVhbSBvciBjb25uZWN0aW9uIGZsb3cgY29udHJvbCogKHNvIGl0 IGRvZXMgbm90IHZpb2xhdGUgdGhlbSBhbmQgZG9lcyBub3QgcmVkdWNlIGNvbm5lY3Rpb24gd2lu ZG93KSwgYnV0IGl0IGlzIGEgaGludCB0byBvcGVuIHRoZSBzdHJlYW0gYW5kIGNvbm5lY3Rpb24g d2luZG93cw0KIHRvIGFjY29tbW9kYXRlIHNraXBwaW5nIGJ5dGUgb2N0ZXRzIChzaW5jZSB0aGV5 IGRvIG5vdCByZXF1aXJlIGFueSBidWZmZXIgc3BhY2UpLiZuYnNwOyBUaGUgc3RyZWFtIHdvdWxk IGJlIGFibGUgdG8gcmVzdW1lIGluIGF0IG1vc3QgMSBydHQsIGFuZCBpdCB3b3VsZCBub3QgYmxv Y2sgb3RoZXIgc3RyZWFtcyBtZWFud2hpbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2 ZXIsIEkgbm93IHNlZSBhIHByb2JsZW0g4oCTIHdoaWxlIG9wZW5pbmcgdGhlIHN0cmVhbSB3aW5k b3cgYnkgOU1CJiM0MzsgaXMgb2sgKHNpbmNlIGFueSBvY3RldHMgYXQgb2Zmc2V0IGxvd2VyIHRo YW4gTWluIFN0cmVhbSBPZmZzZXQgYXJlIHRvIGJlIGRpc2NhcmRlZCksIHRoZXJlIGlzIG5vIHJl cXVpcmVtZW50IHRoYXQgdGhlIGV4dHJhIGNvbm5lY3Rpb24gd2luZG93IGlzIHVzZWQgZm9yIHRo YXQgc3RyZWFtDQogb25seS4mbmJzcDsgQSBtYWxpY2lvdXMgY2xpZW50IGNhbiByZW5kZXIgY29u bmVjdGlvbiB3aW5kb3cgbWVhbmluZ2xlc3MgYnkgc2VuZGluZyBNSU5fU1RSRUFNX0RBVEEgd2l0 aCBhIGh1Z2UgVW5zZW50IEJ5dGVzIGFuZCB0aGVuIG5ldmVyIHNlbmRpbmcgb24gdGhhdCBzdHJl YW0gYWdhaW4uJm5ic3A7IE9vcHMhJm5ic3A7IEkgd2lsbCBmaXggdGhpcyE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JIGJlbGlldmUgdGhlcmUgaXMgYW5vdGhlciBjaGFs bGVuZ2UsIHdoaWNoIGlzIGluZGljYXRpbmcgdG8gdGhlIHJlY2VpdmVyIHdoZW4gdGhleSBzaG91 bGQgc3RvcCBleHBlY3RpbmcgdG8gcmVjZWl2ZSBkYXRhLiZuYnNwOyBDb252ZW5pZW50bHksIHRo aXMgaXMgZXhhY3RseSB3aGF0IE1JTl9TVFJFQU1fREFUQSBkb2VzLA0KIGJ1dCBJIHRoaW5rIGl0 J3Mgd29ydGggbm90aW5nIGluIHRoZSBpbnRyb2R1Y3Rpb24uPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgbWVhbnQgZXhhY3RseSB0aGlzIGJ5IOKAnG5vdGlmeWluZyB0aGUgdHJhbnNw b3J0IGFuZCB0aGUgcGVlciZuYnNwO3doZW4gZGF0YSBwcmV2aW91c2x5IGVucXVldWVkIGZvciB0 cmFuc21pc3Npb24gbm8gbG9uZ2VyIG5lZWRzIHRvIGJlJm5ic3A7dHJhbnNtaXR0ZWTigJwgKHRo YXTigJlzIHdoYXQg4oCcYW5kIHRoZSBwZWVy4oCdIHdhcyBmb3IpIGJ1dCBzYWlkIGl0IHZlcnkg YXdrd2FyZGx5LiZuYnNwOyBXaWxsIGZpeCBieSBmb2N1c2luZyBvbmx5DQogb24gdGhlIHBlZXIg KGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGFwcCBhbmQgbG9jYWwgdHJhbnNwb3J0IGRvZXMgbm90 IGNvbmNlcm4gd2lyZSBwcm90b2NvbCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBJYW4gU3dldHQgW21haWx0 bzppYW5zd2V0dEBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1i ZXIgMTksIDIwMTcgMzoyMCBQTTxicj4NCjxiPlRvOjwvYj4gTHVjYXMgUGFyZHVlICZsdDtMdWNh cy5QYXJkdWVAYmJjLmNvLnVrJmd0Ozxicj4NCjxiPkNjOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0 O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBkcmFmdC1sdWJhc2hldi1xdWljLXBhcnRpYWwtcmVsaWFiaWxpdHk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHdyaXRpbmcgdGhpcyB1cCBJ Z29yLCBpdCdzIGFuIGludGVyZXN0aW5nIGlkZWEsIGFuZCBJIGxpa2UgaG93IGl0IGFsbG93cyBh bnkgc3RyZWFtIGJlc2lkZXMgMCB0byBiZSBwYXJ0aWFsbHkgcmVsaWFibGUuJm5ic3A7IEknbSBh IGJpdCBjb25jZXJuZWQob3IgcG9zc2libHkgY29uZnVzZWQpIGFib3V0IHRoZSBlZmZvcnQgdG8g Y2hhbmdlIGhvdyBmbG93IGNvbnRyb2wgd29ya3MsIHNlZSBjb21tZW50cw0KIGJlbG93LiZuYnNw OyBJIGJlbGlldmUgdGhpcyBwcm9wb3NhbCBpbXBsaWNpdGx5IGFzc3VtZXMgdGhhdCBpdCdzIGVh c2llciBhbmQgbW9yZSBlZmZpY2llbnQgdG8gdXNlIHN0cmVhbXMgZm9yIG9yZGVyaW5nIGFuZCBt YWtlIHRoZSBhcHBsaWNhdGlvbiBkZWFsIHdpdGggaW50ZXJwcmV0aW5nIG91dCBvZiBvcmRlciBk YXRhIHRoYW4gdGhlIGN1cnJlbnQgbW9kZWwgb2YgbWFraW5nIGFwcGxpY2F0aW9ucyByZW9yZGVy IGEgbGFyZ2UgbnVtYmVyIG9mIHNtYWxsDQogc3RyZWFtcz8mbmJzcDsgVGhhdCBtYXkgb3IgbWF5 IG5vdCBiZSB0cnVlIGluIGEgZ2l2ZW4gYXBwbGljYXRpb24sIGJ1dCBJIGNhbiBpbWFnaW5lIGNh c2VzIHdoZW4gaXQgaXMgdHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhlIGJlZ2lubmluZyB5b3Ugc2F5OjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7VGhlIGtleSB0byBw YXJ0aWFsIHJlbGlhYmxpdHkgaXMgbm90aWZ5aW5nIHRoZSB0cmFuc3BvcnQgYW5kIHRoZSBwZWVy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDt3aGVuIGRhdGEgcHJldmlvdXNseSBlbnF1ZXVlZCBmb3IgdHJhbnNtaXNzaW9uIG5vIGxvbmdl ciBuZWVkcyB0byBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7dHJhbnNtaXR0ZWQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGVyZSBpcyBhbm90aGVy IGNoYWxsZW5nZSwgd2hpY2ggaXMgaW5kaWNhdGluZyB0byB0aGUgcmVjZWl2ZXIgd2hlbiB0aGV5 IHNob3VsZCBzdG9wIGV4cGVjdGluZyB0byByZWNlaXZlIGRhdGEuJm5ic3A7IENvbnZlbmllbnRs eSwgdGhpcyBpcyBleGFjdGx5IHdoYXQgTUlOX1NUUkVBTV9EQVRBIGRvZXMsIGJ1dCBJIHRoaW5r IGl0J3Mgd29ydGggbm90aW5nIGluIHRoZSBpbnRyb2R1Y3Rpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRlcm1zIG9mIHRoZSBkb3du c2lkZXMgb2YgdXNpbmcgc3RyZWFtcyBhcyBpcywgeW91IHNheTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0hlbmNlLCBhIG1lc3NhZ2Ut cGVyLXN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7YXBwcm9hY2ggcmVxdWlyZXMgZWFjaCBtZXNzYWdlIHRvIGNvbnRhaW4gYW4g ZXh0cmEgaGVhZGVyIHBvcnRpb24gdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO2Fzc29jaWF0ZSB0aGUgbWVzc2FnZSB3aXRoIGEgbG9n aWNhbCBhcHBsaWNhdGlvbiBzdHJlYW0uJm5ic3A7IEluIGNhc2Ugb2Y8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO3Nob3J0IG1lc3NhZ2Vz LCB0aGlzIGFwcHJvYWNoIGludHJvZHVjZXMgYSBzaWduaWZpY2FudCBvdmVyaGVhZCBkdWU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO3Rv IFNUUkVBTSBmcmFtZXMgYW5kIG1lc3NhZ2UgaGVhZGVycy4mbmJzcDsgSXQgYWxzbyBwbGFjZXMg dGhlIGJ1cmRlbiBvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7dGhlIGFwcGxpY2F0aW9uIHRvIHJlb3JkZXIgZGF0YSBhcnJpdmluZyBv biBtdWx0aXBsZSBRVUlDIHN0cmVhbXMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHByYWN0aWNlLCBJIGJlbGlldmUgYSBsb3Qg b2YgYXBwbGljYXRpb25zIHVzaW5nIHBhcnRpYWwgcmVsaWFiaWxpdHkgdG9kYXkgaGF2ZSBzdWNo IGhlYWRlcnMsIHNpbmNlIHRoZXkncmUgY29tbW9ubHkgZGVzaWduZWQgd2l0aCBVRFAgaW4gbWlu ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gc2VjdGlvbiA0LCB5b3UgZGlzY3VzcyB0aGUgc2VwYXJhdGlvbiBvZiBVbnNlbnQgYnl0ZXMg ZnJvbSBTZW50IGRhdGEsIGJ1dCBJJ20gc3RpbGwgY29uZnVzZWQgb24gdGhlIG1vdGl2YXRpb24g dGhlcmUsIHNpbmNlIHNlcGFyYXRpbmcgdGhlbSBzZWVtcyB0byBtYWtlIGZsb3cgY29udHJvbCBt b3JlIGNvbXBsZXguJm5ic3A7IEN1cnJlbnRseSB0aGUgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wg dXNlZCBpcyB0aGUgc3VtDQogb2YgdGhlIGxhcmdlc3QgYnl0ZSBvZmZzZXRzIG9mIGFsbCBzdHJl YW1zIG9uIGEgY29ubmVjdGlvbiwgYW5kIG5vdyB0aGF0IHdvdWxkIGJlIGRyYW1hdGljYWxseSBk aWZmZXJlbnQsIGNvcnJlY3Q/Jm5ic3A7IENhbiB5b3UgYWRkIG1vcmUgYmFja2dyb3VuZCBvbiB3 aHkgdGhlc2UgYXJlIHNlcGFyYXRlZCBhbmQgaG93IHRoZXkgYXJlIGFwcGxpZWQgdG8gdmFyaW91 cyBsaW1pdHM/Jm5ic3A7IElmIEkgcmVhZCBjb3JyZWN0bHksIE1JTl9TVFJFQU1fREFUQSBmcmFt ZQ0KIGlzIGVmZmVjdGl2ZWx5IGFibGUgdG8gaW5jcmVhc2UgYSBwZWVyJ3MgZmxvdyBjb250cm9s IGxpbWl0cyBieSBkZWNsYXJpbmcgcHJldmlvdXNseSB1c2VkIGNyZWRpdHMgdXAgZm9yIGdyYWJz PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIHByb3Bvc2FsIHJlcXVpcmVzIG91dCBvZiBvcmRlciBkZWxpdmVyeSBiZSBzdXBwb3J0ZWQg YnkgUVVJQyBzdHJlYW1zLCB3aGljaCBpcyB3b3J0aCBleHBsaWNpdGx5IG5vdGluZywgbWF5YmUg aW4gc2VjdGlvbiA1LCBzaW5jZSBpdCdzIGN1cnJlbnRseSBub3QgcmVxdWlyZWQuJm5ic3A7IEFs c28sIHRoZSByZWNlaXZlciBuZWVkcyB0byBiZSBhYmxlIHRvIGRldGVybWluZSB3aGF0IHRoZSBt ZXNzYWdlIGJvdW5kYXJpZXMNCiBhcmUgaWYgdGhlcmUgYXJlIGdhcHMgaW4gdGhlIHN0cmVhbS4m bmJzcDsgSG93IGVhc3kgdGhhdCBpcyB3b3VsZCBkZXBlbmQgdXBvbiB3aGF0IGlzIGJlaW5nIHNl bnQgb24gdGhlIHN0cmVhbS4mbmJzcDsgSXQgbWlnaHQgZGVzZXJ2ZSBzb21lIGRpc2N1c3Npb24g YWJvdXQgaG93IG9uZSBtaWdodCBkbyB0aGlzIGFuZCB3aGF0IHJlc3RyaWN0aW9ucyBzaG91bGQg YmUgaW1wb3NlZCBvbiBob3cgdGhlIHNlbmRlciBidW5kbGVzIGRhdGEsIGlmIHRoYXQgZW5kcyB1 cA0KIGJlaW5nIG5lY2Vzc2FyeT8mbmJzcDsgaWU6IENhbiBhIFNUUkVBTSBmcmFtZSBjb250YWlu IHRoZSBlbmQgb2Ygb25lIG1lc3NhZ2UgYW5kIHRoZSBiZWdpbm5pbmcgb2YgYW5vdGhlciBpbiBh IHNpbmdsZSBmcmFtZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBEZWMgMTksIDIwMTcgYXQgMTA6NDYgQU0sIEx1Y2FzIFBhcmR1ZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkx1Y2FzLlBhcmR1ZUBiYmMuY28udWsiIHRhcmdldD0iX2JsYW5rIj5M dWNhcy5QYXJkdWVAYmJjLmNvLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj5JZ29yIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhlIGJvb2trZWVwaW5nIGlzIHNpbXBsZSBlbm91Z2ggYW5kIHRoZSBydW50aW1lIHJlc291cmNl cyByZXF1aXJlZCBpcyBqdXN0IG9uZSB1aW50NjRfdCBwZXIgc3RlYW0sIHNvIEkgZG8gbm90IHNl ZSBhIHByb2JsZW0gZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6YmxhY2siPlVsdGltYXRlbHksIHBhcnRpYWwgcmVsaWFiaWxp dHkgaXMgYSBmZWF0dXJlIHRoYXQgYW4gYXBwbGljYXRpb24gZWl0aGVyIG5lZWRzIG9yIGRvZXMg bm90LiBJZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyBpdCwgaXQgbW9zdCBsaWtlbHkgcmVxdWlyZXMg aXQuDQogSW4gYW55IGNhc2UsIGFuIGFwcGxpY2F0aW9uIGNhbiBkbyBpdHMgb3duIG5lZ290aWF0 aW9uIGlmIGl0IGRlc2lyZXMgdG8gZG8gc28uIEZvciBleGFtcGxlLCBpdCBjYW4gdXNlIHN0cmVh bSAxIGZvciB0aGF0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Tm93IEkgdW5k ZXJzdGFuZCB0aGlzIGlzIGNvbm5lY3Rpb24td2lkZSwgSSBnZW5lcmFsbHkgYWdyZWUuIEhvd2V2 ZXIsIGZvciBzb21ldGhpbmcgbGlrZSBjb252ZW50aW9uYWwgSFRUUC9RVUlDLCB0aGUgcmVsaWFi bGUgZ3VhcmFudGVlIGFzc3VyYW5jZXMgYXJlIHJlcXVpcmVkDQogYnkgdGhlIG1hcHBpbmcuIElm IHBhcnRpYWwgcmVsaWFiaWxpdHkgaXMgZGVmYXVsdCBlbmFibGVkIHRyYW5zcG9ydCBmZWF0dXJl LCBhcHBsaWNhdGlvbnMgbGlrZSBIVFRQL1FVSUMgbXVzdCByZXN0cmljdCBvciBkaXNhYmxlIGl0 IOKAkyBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgZWRpdG9ycy9kcmFmdHMgaGF2ZSBicm9hY2hlZCB0 aGF0IHN1YmplY3QgeWV0IChJ4oCZdmUgY2VydGFpbmx5IGhhZCBzb21lIGZlZWRiYWNrIG9uIG15 IGRyYWZ0IGFib3V0IHN1Y2gNCiByZXN0cmljdGlvbnMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJjb2xvcjpibGFjayI+SSBkaWQgbm90IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGxhc3QgcXVlc3Rp b24uIEFyZSB5b3UgYXNraW5nIHdoZXRoZXIgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBjb25uZWN0 aW9uIHRvIG5lZ290aWF0ZSBqdXN0IGEgc2luZ2xlIHN0cmVhbSAoaW4gZWFjaA0KIGRpcmVjdGlv bikgdGhhdCB3b3VsZCBiZSBwYXJ0aWFsbHkgcmVsaWFibGUgYW5kLCB0aGVyZWZvcmUsIG5vdCBz ZW5kIGEgc3RyZWFtIGlkIHdpdGggTUlOX1NUUkVBTV9EQVRBPyBJIGNvdWxkIGFjdHVhbGx5IHRo aW5rIG9mIGEgdmVyc2lvbiBvZiBNSU5fU1RSRUFNX0RBVEEgdGhhdCBoYXMgYW4gaW1wbGllZCBz dHJlYW0gaWQgLS0gdGhlIHN0cmVhbSBpZCBvZiBhIHByaW9yL2ZvbGxvd2luZyBTVFJFQU0gZnJh bWUgaW4gdGhlIHNhbWUgcGFja2V0Lg0KIFRoYXQgd291bGQgYmUgYW4gb3B0aW1pemF0aW9uIHRo YXQgSSBhbSBoYXBweSB0byBhZGQsIGlmIHRoZXJlIGlzIGVub3VnaCBzdXBwb3J0IGZvciBpdC48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkFwb2xvZ2ll cywgSSBoYWRu4oCZdCBkcnVuayBhbnkgY29mZmVlIHdoZW4gZmlyc3QgcmVwbHlpbmcgYW5kIGdv dCBteXNlbGYgY29uZnVzZWQuIEFsbCBRVUlDIGZyYW1lcyBvZiB0aGlzIG5hdHVyZSBzaG91bGQg bm9ybWFsbHkgaW5jbHVkZSBhIFN0cmVhbSBJRCwgd2hpY2ggaWRlbnRpZmllcw0KIHRoZSBzdHJl YW0gaXQgaXMgc2VudCBvbi4gSSB0aGluayB5b3VyIHN1Z2dlc3Rpb24gcmVsaWVzIG9uIHNlcmlh bCBvcmRlcmluZy9wcm9jZXNzaW5nIChldmVuIGluc2lkZSBhIHBhY2tldCksIHdoaWNoIG1pZ2h0 IGJlIGEgaGFyZCBzZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlNlcGFyYXRlbHksIGluIHRl cm1zIG9mIGFzeW1tZXRyeSwgSSB3YXMgdGhpbmtpbmcgdGhhdCB5b3UgbWlnaHQgYWx3YXlzIHdh bnQgKGFzIGEgcG9saWN5KSBjbGllbnRzIHRvIHRyYW5zbWl0IHdpdGggZnVsbCByZWxpYWJpbGl0 eSBidXQgcHJvdmlkZSBkYXRhIHRvIHRoZW0NCiB3aXRoIHBhcnRpYWwgcmVsaWFiaWxpdHkuIEkg dGhpbmsgdGhpcyBpcyBhZ2FpbiBhbiBhcHBsaWNhdGlvbiBtYXBwaW5nIGNvbmNlcm4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5MdWNhczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_672822da83a74bd2b69634c881283331usma1exdag1mb5msgcorpak_-- From nobody Tue Dec 19 17:34: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 F07C2128961 for ; Tue, 19 Dec 2017 17:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 RQE2EkUgaadz for ; Tue, 19 Dec 2017 17:34:20 -0800 (PST) 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 9D773124D85 for ; Tue, 19 Dec 2017 17:34:20 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBK1WCv9032613; Wed, 20 Dec 2017 01:34:13 GMT 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=y5JF1MvcsN0PZ+53pYfng7le2blXCr/49wqOfzjAd+I=; b=j4IxAC7jLB/zzGb9uEHPQophskIdbxMmnrGIWk5UyI6eAy7N1COwvjY+9AQ2tOoszSP/ DCBph0oMFYOejsIzTIT21hI18WsvwCN5XkHGl5IzsLRvFZc5vim5w76sT1pZ5Q3ZDlMQ 5fBB/3d1vXttnqLOPfRfP6aFXVzI584ggzFv5u6MIIt5iNanoiglqn81uxWM1/mZ464s Lbpk7YY5tV4GhcLOkfpA6uHPUo0X3V4lDLKEL6qQ1NlIGqlqn3+HQIgVA65giGFQMJ57 +49cHIodQQbE9aVdq8LmcyNyCUEwcJS5tPNJM7aGdr50d46TS93LP70c4yrjV0I/hzX3 lw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2evs7v31r1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2017 01:34:13 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBK1V113005192; Tue, 19 Dec 2017 20:34:12 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2evyqdxgj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 20:34:12 -0500 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.1263.5; Tue, 19 Dec 2017 20:34: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.1263.000; Tue, 19 Dec 2017 20:34:12 -0500 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Christian Huitema , QUIC WG Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAr+ayAAABTTAAAAZKAAA== Date: Wed, 20 Dec 2017 01:34:11 +0000 Message-ID: References: <8c35500c-0011-3a9c-6c01-b3440e112532@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.55] Content-Type: multipart/alternative; boundary="_000_b4b0135a9761410f9df864c2ceebc477usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200019 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200019 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, 20 Dec 2017 01:34:23 -0000 --_000_b4b0135a9761410f9df864c2ceebc477usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHR3byBwcm9wb3NhbHMgYXJlIHNpbWlsYXIgaW4gYSB3YXkgdGhhdCBib3RoIGVmZmVjdGl2 ZWx5IGNvbnRhaW4gYSDigJx6ZXJvLWZpbGzigJ0gZnJhbWUsIHRob3VnaCBNSU5fU1RSRUFNX0RB VEEgcHJvcG9zYWwgaXMgZXhwbGljaXQgYWJvdXQgbm90aWZ5aW5nIHRoZSByZWNlaXZlciBhYm91 dCBhIGdhcCBpbiBkYXRhIGFuZCBkb2VzIG5vdCBqdXN0IGZpbGwgd2l0aCAweDAwLg0KDQpTaW5j ZSBRVUlDIGlzIGxpa2VseSB0byBiZSBhIGxpYnJhcnkgbGlua2VkIGludG8gYW4gYXBwbGljYXRp b24sIHRoZXkgYXJlIHNjaGVkdWxlZCB0b2dldGhlci4gIEJ1dCBpbiBhbnkgY2FzZSwgSSBmaW5k IGl0IGltcG9ydGFudCB0byBhbGxvdyBhcHBsaWNhdGlvbnMgZnVsbCBjb250cm9sIG92ZXIgd2hl biB0byBleHBpcmUgZGF0YSwgYWx0aG91Z2ggc29tZSBRVUlDIGltcGxlbWVudGF0aW9ucyBjb3Vs ZCBwcm92aWRlIGhpZ2hlci1sZXZlbCBhYnN0cmFjdGlvbnMgZm9yIG1lc3NhZ2UgZXhwaXJhdGlv bi4NCg0KDQpGcm9tOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpA Z21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgMjo0MCBQTQ0KVG86 IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWEg PGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDog UmU6IGRyYWZ0LWx1YmFzaGV2LXF1aWMtcGFydGlhbC1yZWxpYWJpbGl0eQ0KDQpJIGRpZCBjb21l IHVwIHdpdGggYSBwcm9wb3NhbCB3aXRoIHNlZ21lbnRlZCBzdHJlYW0gZGF0YSBmb3IgcGFydGlh bCByZWxpYWJpbGl0eS4NCkl04oCZcyBub3QgdG9vIGNvaGVyZW50IGFzIGl0IGV2b2x2ZWQsIGJ1 dCBoZXJlIGl0IGlzOg0KDQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lz c3Vlcy80MzM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vlc180MzMmZD1Ed01GYVEm Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlq VVpkbl9tNTVLUG1sbyZtPTRPS2U4ZVpScmhUWDF3cWwzWDJoRDliTjN0MDU2LWRMbXA1cnRlN2hz ck0mcz1oSnVvcG94RHpJeUZiaElZUjNiWmRIQ1NvdGtxVlRzR0NTalVjcHdPZlJnJmU9Pg0KDQpB cHBsaWNhdGlvbnMgY291bGQgYWxzbyBkbyB0aGVpciBpbnRlcm5hbCBmcmFtaW5nIGFuZCBmb3J3 YXJkIHRoZSBtaW4gZm9yIGVhY2ggaW50ZXJuYWwgZnJhbWUgYW5kIGxldCB0cmFuc3BvcnQgZGVj aWRlIGlmIHJldHJhbnNtaXNzaW9uIGlzIHdvcnRod2hpbGUuDQoNCklmIHRoZSBhcHBsaWNhdGlv biBuZWVkcyB0byBtYWtlIGJ1c2luZXNzIGRlY2lzaW9ucyBpdCBtaWdodCBiZSBvdXQgb2YgdGhl IGxvb3AgZm9yIHRvbyBsb25nLiBRVUlDIG1pZ2h0IGJlIHNjaGVkdWxlZCBhIGxvdCBtb3JlIG9m dGVuIHRoYW4gYXBwbGljYXRpb25zIHRhbGtpbmcgdG8gUVVJQy4NCg0KS2luZCBSZWdhcmRzLA0K TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDE5IERlY2VtYmVyIDIwMTcgYXQgMjAu MzEuMTcsIENocmlzdGlhbiBIdWl0ZW1hIChodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0 ZW1hQGh1aXRlbWEubmV0Pikgd3JvdGU6DQpPbiAxMi8xOC8yMDE3IDc6MzkgUE0sIEx1YmFzaGV2 LCBJZ29yIHdyb3RlOg0KDQo+IFRoZSBoaWdoLWxldmVsIGlkZWEgaXMgdGhhdCB0aGUgc2VuZGVy IGtlZXBzIHRyYWNrIG9mIG1lc3NhZ2VzIHdpdGhpbg0KPiBhIHN0cmVhbSBhbmQgY2FuIOKAnGV4 cGlyZeKAnSBvbGQgbWVzc2FnZXMgd2hlbmV2ZXIgaXQgd2FudHMuICBUaGUNCj4g4oCcZXhwaXJh dGlvbuKAnSBpcyBhIHNpZ25hbCB0byB0aGUgdHJhbnNwb3J0IHRvIG5vdCByZXRyYW5zbWl0IGV4 cGlyZWQNCj4gZGF0YSAoYW5kIGEgc2lnbmFsIHRvIHRoZSBvdGhlciBlbmRwb2ludCB0aGF0IHRo aXMgZGF0YSB3aWxsIG5vdCBiZQ0KPiByZXRyYW5zbWl0dGVkKS4gIEFsbCBkZXRhaWxzIGFyZSBp biB0aGUgZHJhZnQuDQoNCkkgcmVhZCB5b3VyIGRyYWZ0LCBhbmQgaXQgZG9lcyBpbmRlZWQgcHJv dmlkZSAicGFydGlhbCByZWxpYWJpbGl0eS4iIE15DQpwcm9ibGVtIGlzIHRoYXQgZm9yIFJUUCBz dHlsZSBhcHBsaWNhdGlvbnMsIHlvdSBkb24ndCB3YW50IGp1c3QgcGFydGlhbA0KcmVsaWFiaWxp dHkuIFlvdSBhbHNvIHdhbnQgYXBwbGljYXRpb24gZnJhbWUgZGVsaW1pdGF0aW9uLCBzdWNoIGFz DQpkZWxpdmVyaW5nIGlzb2xhdGVkIFZPSVAgZnJhbWVzLCBkb2luZyAgbG9zcyBjb21wZW5zYXRp b24sIG9yDQppbXBsZW1lbnRpbmcgYXBwbGljYXRpb24gbGV2ZWwgRkVDIGZvciBsYXJnZSB2aWRl byBmcmFtZXMuIFRoZSBzdHJlYW1zDQppbiBRVUlDIGRvbid0IHByb3ZpZGUgdGhhdC4gVGhleSBp bXBsZW1lbnQgYSAiYnl0ZSBzdHJlYW0iIGFic3RyYWN0aW9uLA0Kbm90IGEgInBhY2tldCBzdHJl YW0iLiBTbyBJIHJlYWxseSB3b25kZXIgd2hldGhlciBGVFAgc3R5bGUgYXBwbGljYXRpb25zDQph cmUgYmV0dGVyIHNlcnZlZCBieSBhZGRpbmcgcGFydGlhbCByZWxpYWJpbGl0eSB0byB0aGUgY3Vy cmVudCBjb25jZXB0DQpvZiBzdHJlYW1zLCBvciB3aGV0aGVyIHdlIHNob3VsZCBqdXN0IGFkZCBh IGRpZmZlcmVudCBzZXJ2aWNlLCBtYXliZQ0KY3JlYXRpbmcgIlJUUF9TVFJFQU0iIGZyYW1lcy4N Cg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0K --_000_b4b0135a9761410f9df864c2ceebc477usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0 d28gcHJvcG9zYWxzIGFyZSBzaW1pbGFyIGluIGEgd2F5IHRoYXQgYm90aCBlZmZlY3RpdmVseSBj b250YWluIGEg4oCcemVyby1maWxs4oCdIGZyYW1lLCB0aG91Z2ggTUlOX1NUUkVBTV9EQVRBIHBy b3Bvc2FsIGlzIGV4cGxpY2l0IGFib3V0IG5vdGlmeWluZyB0aGUgcmVjZWl2ZXIgYWJvdXQgYSBn YXAgaW4gZGF0YSBhbmQgZG9lcyBub3QganVzdCBmaWxsIHdpdGggMHgwMC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2luY2UgUVVJQyBpcyBsaWtlbHkgdG8gYmUgYSBsaWJyYXJ5IGxpbmtlZCBp bnRvIGFuIGFwcGxpY2F0aW9uLCB0aGV5IGFyZSBzY2hlZHVsZWQgdG9nZXRoZXIuJm5ic3A7IEJ1 dCBpbiBhbnkgY2FzZSwgSSBmaW5kIGl0IGltcG9ydGFudCB0byBhbGxvdyBhcHBsaWNhdGlvbnMg ZnVsbCBjb250cm9sIG92ZXIgd2hlbiB0byBleHBpcmUgZGF0YSwgYWx0aG91Z2ggc29tZSBRVUlD IGltcGxlbWVudGF0aW9ucyBjb3VsZCBwcm92aWRlDQogaGlnaGVyLWxldmVsIGFic3RyYWN0aW9u cyBmb3IgbWVzc2FnZSBleHBpcmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFp bHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNl bWJlciAxOSwgMjAxNyAyOjQwIFBNPGJyPg0KPGI+VG86PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7 aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1 aXRlbWEubmV0Jmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IGRyYWZ0LWx1YmFzaGV2LXF1aWMtcGFydGlhbC1yZWxpYWJpbGl0eTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBkaWQgY29tZSB1cCB3aXRoIGEgcHJvcG9zYWwg d2l0aCBzZWdtZW50ZWQgc3RyZWFtIGRhdGEgZm9yIHBhcnRpYWwgcmVsaWFiaWxpdHkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdOKAmXMgbm90IHRvbyBjb2hl cmVudCBhcyBpdCBldm9sdmVkLCBidXQgaGVyZSBpdCBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vl c180MzMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpu M2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT00T0tlOGVaUnJo VFgxd3FsM1gyaEQ5Yk4zdDA1Ni1kTG1wNXJ0ZTdoc3JNJmFtcDtzPWhKdW9wb3hEekl5RmJoSVlS M2JaZEhDU290a3FWVHNHQ1NqVWNwd09mUmcmYW1wO2U9Ij5odHRwczovL2dpdGh1Yi5jb20vcXVp Y3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy80MzM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkFwcGxpY2F0aW9ucyBjb3VsZCBhbHNvIGRvIHRoZWlyIGludGVybmFsIGZyYW1p bmcgYW5kIGZvcndhcmQgdGhlIG1pbiBmb3IgZWFjaCBpbnRlcm5hbCBmcmFtZSBhbmQgbGV0IHRy YW5zcG9ydCBkZWNpZGUgaWYgcmV0cmFuc21pc3Npb24gaXMgd29ydGh3aGlsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIG1h a2UgYnVzaW5lc3MgZGVjaXNpb25zIGl0IG1pZ2h0IGJlIG91dCBvZiB0aGUgbG9vcCBmb3IgdG9v IGxvbmcuIFFVSUMgbWlnaHQgYmUgc2NoZWR1bGVkIGEgbG90IG1vcmUgb2Z0ZW4gdGhhbiBhcHBs aWNhdGlvbnMgdGFsa2luZyB0byBRVUlDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUxMzcxMjI2MTQ4NjE0NTAyNCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ T24gMTkgRGVjZW1iZXIgMjAxNyBhdCAyMC4zMS4xNywgQ2hyaXN0aWFuIEh1aXRlbWEgKDxhIGhy ZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPikg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pk9uIDEyLzE4LzIwMTcgNzozOSBQTSwgTHViYXNoZXYsIElnb3Igd3JvdGU6DQo8YnI+DQo8YnI+ DQomZ3Q7IFRoZSBoaWdoLWxldmVsIGlkZWEgaXMgdGhhdCB0aGUgc2VuZGVyIGtlZXBzIHRyYWNr IG9mIG1lc3NhZ2VzIHdpdGhpbiA8YnI+DQomZ3Q7IGEgc3RyZWFtIGFuZCBjYW4g4oCcZXhwaXJl 4oCdIG9sZCBtZXNzYWdlcyB3aGVuZXZlciBpdCB3YW50cy4mbmJzcDsgVGhlIDxicj4NCiZndDsg 4oCcZXhwaXJhdGlvbuKAnSBpcyBhIHNpZ25hbCB0byB0aGUgdHJhbnNwb3J0IHRvIG5vdCByZXRy YW5zbWl0IGV4cGlyZWQgPGJyPg0KJmd0OyBkYXRhIChhbmQgYSBzaWduYWwgdG8gdGhlIG90aGVy IGVuZHBvaW50IHRoYXQgdGhpcyBkYXRhIHdpbGwgbm90IGJlIDxicj4NCiZndDsgcmV0cmFuc21p dHRlZCkuJm5ic3A7IEFsbCBkZXRhaWxzIGFyZSBpbiB0aGUgZHJhZnQuIDxicj4NCjxicj4NCkkg cmVhZCB5b3VyIGRyYWZ0LCBhbmQgaXQgZG9lcyBpbmRlZWQgcHJvdmlkZSAmcXVvdDtwYXJ0aWFs IHJlbGlhYmlsaXR5LiZxdW90OyBNeSA8YnI+DQpwcm9ibGVtIGlzIHRoYXQgZm9yIFJUUCBzdHls ZSBhcHBsaWNhdGlvbnMsIHlvdSBkb24ndCB3YW50IGp1c3QgcGFydGlhbCA8YnI+DQpyZWxpYWJp bGl0eS4gWW91IGFsc28gd2FudCBhcHBsaWNhdGlvbiBmcmFtZSBkZWxpbWl0YXRpb24sIHN1Y2gg YXMgPGJyPg0KZGVsaXZlcmluZyBpc29sYXRlZCBWT0lQIGZyYW1lcywgZG9pbmcmbmJzcDsgbG9z cyBjb21wZW5zYXRpb24sIG9yIDxicj4NCmltcGxlbWVudGluZyBhcHBsaWNhdGlvbiBsZXZlbCBG RUMgZm9yIGxhcmdlIHZpZGVvIGZyYW1lcy4gVGhlIHN0cmVhbXMgPGJyPg0KaW4gUVVJQyBkb24n dCBwcm92aWRlIHRoYXQuIFRoZXkgaW1wbGVtZW50IGEgJnF1b3Q7Ynl0ZSBzdHJlYW0mcXVvdDsg YWJzdHJhY3Rpb24sIDxicj4NCm5vdCBhICZxdW90O3BhY2tldCBzdHJlYW0mcXVvdDsuIFNvIEkg cmVhbGx5IHdvbmRlciB3aGV0aGVyIEZUUCBzdHlsZSBhcHBsaWNhdGlvbnMgPGJyPg0KYXJlIGJl dHRlciBzZXJ2ZWQgYnkgYWRkaW5nIHBhcnRpYWwgcmVsaWFiaWxpdHkgdG8gdGhlIGN1cnJlbnQg Y29uY2VwdCA8YnI+DQpvZiBzdHJlYW1zLCBvciB3aGV0aGVyIHdlIHNob3VsZCBqdXN0IGFkZCBh IGRpZmZlcmVudCBzZXJ2aWNlLCBtYXliZSA8YnI+DQpjcmVhdGluZyAmcXVvdDtSVFBfU1RSRUFN JnF1b3Q7IGZyYW1lcy4gPGJyPg0KPGJyPg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWEgPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b4b0135a9761410f9df864c2ceebc477usma1exdag1mb5msgcorpak_-- From nobody Tue Dec 19 19:03: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 B2FD812D948 for ; Tue, 19 Dec 2017 19:03:29 -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 (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 MvQDJUTVxTJd for ; Tue, 19 Dec 2017 19:03:28 -0800 (PST) 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 34F12124D85 for ; Tue, 19 Dec 2017 19:03:27 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBK32o1c027813; Wed, 20 Dec 2017 03:03:22 GMT 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=nB5h7Nt6PJYGpAPlmRZ98VzAi6WynwnhAXSAdfiAeJ8=; b=CuOpohpZthuwHJBKknmwffTQaZ6MxY5H/MlyUuCZsZ7AepKwZKCNf6E1sv17bTdDpztL tRs5qwgvh11epvLnwMLEvG8lV6DwCgf+lPxJ2d1VX8/Za7ebkNTzmIVeBOdx26Y0Qkbe Ssva3TstRilApUP9rGFf2ji1KQ95nebD9B9vLClwULySgKB5HkKKCFle7Byp6ntkyzO0 cypGKNLBBJQi9Zn2AgxkC+jKuBpJlWysJMaDeJbo5WeNr+uFN11OPdHHrzgNyIlcaSSt WbK58VGuvJNiamRww2XWF5OCeoUr9uC/8Z4isrzEytrpSCQYenc6ldcWvHJXH8TFhjE5 TQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2evuw6c1g2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2017 03:03:22 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vBK30lis030661; Tue, 19 Dec 2017 22:03:21 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2evypxxt8r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Dec 2017 22:03:21 -0500 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.1263.5; Tue, 19 Dec 2017 22:03: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.1263.000; Tue, 19 Dec 2017 22:03:20 -0500 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Lucas Pardue , "quic@ietf.org" Subject: RE: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQAMOJHZAAgTzPAAAesSEAARBPyAAAhDLtD//+JmgP//26VA Date: Wed, 20 Dec 2017 03:03:19 +0000 Message-ID: <5a3b3547c4f24b55aaf949c967e44e1c@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAB1A4A@bgb01xud1012> <85d7dc28d3bb40a38873f4d32a16fd71@usma1ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BAB1B01@bgb01xud1012> <49797640bd7444f39b51a7595ee53c72@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.55] Content-Type: multipart/alternative; boundary="_000_5a3b3547c4f24b55aaf949c967e44e1cusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200041 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712200042 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, 20 Dec 2017 03:03:30 -0000 --_000_5a3b3547c4f24b55aaf949c967e44e1cusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSWYgdGhlIGNvbm5lY3Rpb24gaGFzIGxvdyBsb3NzLXJhdGUsIGl0IG1pZ2h0IHN0YXJ0 IHJldHJhbnNtaXR0aW5nIGEgbG90IG9mIGRhdGEgdGhhdCB0aGUgYXBwbGljYXRpb24gYWxyZWFk eSBrbm93cyBpcyBubyBsb25nZXIgcmVsZXZhbnQgW+KApl0NCg0KQXJlIHlvdSB3b3JyaWVkIGFi b3V0IGEgY2FzZSBvZiBtZXNzYWdlIGV4cGlyYXRpb24gYmVpbmcgc2hvcnRlciB0aGFuIGFuIHJ0 dCwgYW5kIGhlbmNlIHRoZSBhcHBsaWNhdGlvbiB3b3VsZCBleHBpcmUgbWVzc2FnZXMgYXQgYSBy YXRlIGZhc3RlciB0aGFuIHRoZSBBQ0tzIGNhbiBiZSByZWNlaXZlZD8gICBUaGF0IHdvdWxkIG5v dCBjYXVzZSBhbnkgZXh0cmEgcmV0cmFuc21pc3Npb25zLCBidXQgaXQgd291bGQgY2F1c2UgdW5u ZWNlc3NhcnkgTUlOX1NUUkVBTV9EQVRBIGZyYW1lcywgaW5kZWVkLg0KDQoNCg0KDQogICogICBR VUlDIGJ5dGVzIOKAnGV4ZW1wdOKAnSBmcm9tIEZsb3cgQ29udHJvbA0KDQpJIHRoaW5rLCB5ZXMs IFFVSUMgcGFja2V0cyBoYXZlIG1hbnkgYnl0ZXMgZXhlbXB0IGZyb20gZmxvdyBjb250cm9sIChT VFJFQU0gZnJhbWUgaGVhZGVycyBhbmQgYWxsIG5vbi1TVFJFQU0gZnJhbWVzKS4gIE9uZS1zdHJl YW0tcGVyLW1lc3NhZ2UgaXMgZ29pbmcgdG8gaGF2ZSB0aGUgc2FtZSBvdmVyaGVhZCBpbiDigJxl eGVtcHQgYnl0ZXPigJ0gYXMgZW1pdHRpbmcgb25lIE1JTl9TVFJFQU1fREFUQSBwZXIgbWVzc2Fn ZS4NCg0KDQpGcm9tOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpA Z21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTksIDIwMTcgMjoyNiBQTQ0KVG86 IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgTHVjYXMgUGFyZHVlIDxsdWNh cy5wYXJkdWVAYmJjLmNvLnVrPjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IGRyYWZ0LWx1 YmFzaGV2LXF1aWMtcGFydGlhbC1yZWxpYWJpbGl0eQ0KDQpZZXMsIHRoaXMgaXMgYW4gYXBwbGlj YXRpb24gY29uY2Vybiwgc2luY2Ugb25seSB0aGUgYXBwbGljYXRpb24gY2FuIGtub3cgd2hhdCDi gJxvbGTigJ0gbWVhbnMuICBBbHNvLCBzaW5jZSBNSU5fRlJBTUVfREFUQSAgZnJhbWUgaXMgZW1p dHRlZCBPTkxZIGlmIHNvbWUgZXhwaXJlZCBzdHJlYW0gZGF0YSBpcyBsb3N0IChub3QgQUNLZWQp LCB5b3Ugd291bGQgbm90IGV4cGVjdCB0byBzZWUgbWFueSBzdWNoIGZyYW1lcyBvbiB0aGUgd2ly ZSwgZXZlbiBpZiBtZXNzYWdlcyBrZWVwIGV4cGlyaW5nIGFsbCB0aGUgdGltZS4NCg0KSSBjb3Vs ZCBiZSB0aGF0IHRoZSBhcHByb2FjaCBpcyBub3QgYWdncmVzc2l2ZSBlbm91Z2guIElmIHRoZSBj b25uZWN0aW9uIGhhcyBsb3cgbG9zcy1yYXRlLCBpdCBtaWdodCBzdGFydCByZXRyYW5zbWl0dGlu ZyBhIGxvdCBvZiBkYXRhIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGFscmVhZHkga25vd3MgaXMgbm8g bG9uZ2VyIHJlbGV2YW50LCBiZWZvcmUgdGhlIE5BQ0sgKEFDSyBnYXApIGFycml2ZXMgY29zdCBl eGNlc3NpdmUgYmFuZHdpZHRoLg0KDQpJbiBhIHJlY2VudCBUQ1AgdnMgUVVJQyBwYXBlciBwb3N0 ZWQgaGVyZSwgdGhhdCB3YXMgYW4gdW5hbnN3ZXJlZCBxdWVzdGlvbiBhYm91dCB3aHkgUVVJQyB0 b29rIGRvdWJsZSB0aGUgYmFuZHdpZHRoIG9mIFRDUCB3aGVuIGJvdGggd2VyZSBjb21wZXRpbmcg dXNpbmcgQ1VCSUMuIFRoaXMgbWlnaHQgYmUgcmVsYXRlZCB0byBRVUlDIGJlaW5nIGFibGUgdG8g bWFrZSBmYXN0ZXIgcmV0cmFuc21pc3Npb24gZGVjaXNpb25zIG9uIG1vcmUgcGFja2V0cyB3aGlj aCBkbyBub3QgY291bnQgYWdhaW5zdCBpdHMgZmxvdyBjb250cm9sIHdpbmRvdyAocmlnaHQ/KS4N Cg== --_000_5a3b3547c4f24b55aaf949c967e44e1cusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBp bjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0 Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkxMjA4MDIzNDsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5NDE4MTM0NzggODM1 MTE4MzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6SGVsdmV0aWNhO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h 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 aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZiB0 aGUgY29ubmVjdGlvbiBoYXMgbG93IGxvc3MtcmF0ZSwgaXQgbWlnaHQgc3RhcnQgcmV0cmFuc21p dHRpbmcgYSBsb3Qgb2YgZGF0YSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBhbHJlYWR5IGtub3dzDQog aXMgbm8gbG9uZ2VyIHJlbGV2YW50IFvigKZdPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcmUg eW91IHdvcnJpZWQgYWJvdXQgYSBjYXNlIG9mIG1lc3NhZ2UgZXhwaXJhdGlvbiBiZWluZyBzaG9y dGVyIHRoYW4gYW4gcnR0LCBhbmQgaGVuY2UgdGhlIGFwcGxpY2F0aW9uIHdvdWxkIGV4cGlyZSBt ZXNzYWdlcyBhdCBhIHJhdGUgZmFzdGVyIHRoYW4gdGhlIEFDS3MgY2FuIGJlIHJlY2VpdmVkPyZu YnNwOyZuYnNwOw0KIFRoYXQgd291bGQgbm90IGNhdXNlIGFueSBleHRyYSByZXRyYW5zbWlzc2lv bnMsIGJ1dCBpdCB3b3VsZCBjYXVzZSB1bm5lY2Vzc2FyeSBNSU5fU1RSRUFNX0RBVEEgZnJhbWVz LCBpbmRlZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5RVUlDIGJ5dGVzIOKAnGV4ZW1w dOKAnSBmcm9tIEZsb3cgQ29udHJvbDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluaywg eWVzLCBRVUlDIHBhY2tldHMgaGF2ZSBtYW55IGJ5dGVzIGV4ZW1wdCBmcm9tIGZsb3cgY29udHJv bCAoU1RSRUFNIGZyYW1lIGhlYWRlcnMgYW5kIGFsbCBub24tU1RSRUFNIGZyYW1lcykuJm5ic3A7 IE9uZS1zdHJlYW0tcGVyLW1lc3NhZ2UgaXMgZ29pbmcgdG8gaGF2ZSB0aGUgc2FtZSBvdmVyaGVh ZA0KIGluIOKAnGV4ZW1wdCBieXRlc+KAnSBhcyBlbWl0dGluZyBvbmUgTUlOX1NUUkVBTV9EQVRB IHBlciBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2Vs ZmpAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDE5LCAy MDE3IDI6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBh a2FtYWkuY29tJmd0OzsgTHVjYXMgUGFyZHVlICZsdDtsdWNhcy5wYXJkdWVAYmJjLmNvLnVrJmd0 OzsgcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtbHViYXNoZXYt cXVpYy1wYXJ0aWFsLXJlbGlhYmlsaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywg dGhpcyBpcyBhbiBhcHBsaWNhdGlvbiBjb25jZXJuLCBzaW5jZSBvbmx5IHRoZSBhcHBsaWNhdGlv biBjYW4ga25vdyB3aGF0IOKAnG9sZOKAnSBtZWFucy4mbmJzcDsgQWxzbywgc2luY2U8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TUlOX0ZSQU1FX0RBVEE8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jm5ic3A7ZnJh bWUNCiBpcyBlbWl0dGVkIE9OTFkgaWYgc29tZSBleHBpcmVkIHN0cmVhbSBkYXRhIGlzIGxvc3Qg KG5vdCBBQ0tlZCksIHlvdSB3b3VsZCBub3QgZXhwZWN0IHRvIHNlZSBtYW55IHN1Y2ggZnJhbWVz IG9uIHRoZSB3aXJlLCBldmVuIGlmIG1lc3NhZ2VzIGtlZXAgZXhwaXJpbmcgYWxsIHRoZSB0aW1l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGNvdWxkIGJlIHRoYXQgdGhlIGFwcHJvYWNo IGlzIG5vdCBhZ2dyZXNzaXZlIGVub3VnaC4gSWYgdGhlIGNvbm5lY3Rpb24gaGFzIGxvdyBsb3Nz LXJhdGUsIGl0IG1pZ2h0IHN0YXJ0IHJldHJhbnNtaXR0aW5nIGEgbG90IG9mIGRhdGEgdGhhdCB0 aGUgYXBwbGljYXRpb24gYWxyZWFkeSBrbm93cyBpcyBubyBsb25nZXIgcmVsZXZhbnQsDQogYmVm b3JlIHRoZSBOQUNLIChBQ0sgZ2FwKSBhcnJpdmVzIGNvc3QgZXhjZXNzaXZlIGJhbmR3aWR0aC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gYSByZWNlbnQg VENQIHZzIFFVSUMgcGFwZXIgcG9zdGVkIGhlcmUsIHRoYXQgd2FzIGFuIHVuYW5zd2VyZWQgcXVl c3Rpb24gYWJvdXQgd2h5IFFVSUMgdG9vayBkb3VibGUgdGhlIGJhbmR3aWR0aCBvZiBUQ1Agd2hl biBib3RoIHdlcmUgY29tcGV0aW5nIHVzaW5nIENVQklDLiBUaGlzIG1pZ2h0IGJlIHJlbGF0ZWQg dG8gUVVJQw0KIGJlaW5nIGFibGUgdG8gbWFrZSBmYXN0ZXIgcmV0cmFuc21pc3Npb24gZGVjaXNp b25zIG9uIG1vcmUgcGFja2V0cyB3aGljaCBkbyBub3QgY291bnQgYWdhaW5zdCBpdHMgZmxvdyBj b250cm9sIHdpbmRvdyAocmlnaHQ/KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_5a3b3547c4f24b55aaf949c967e44e1cusma1exdag1mb5msgcorpak_-- From nobody Wed Dec 20 00:40: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 22DCE127241 for ; Wed, 20 Dec 2017 00:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iVx1grHkGVGD for ; Wed, 20 Dec 2017 00:40:18 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD52126CF9 for ; Wed, 20 Dec 2017 00:40:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,431,1508828400"; d="asc'?scan'208";a="232863493" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx144-out.netapp.com with ESMTP; 20 Dec 2017 00:40:17 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 20 Dec 2017 00:40:17 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 20 Dec 2017 00:40:17 -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=PbqqBdaLBIr/5dVpokSgGyC/yYNvCwq9LcpO/bAfNG0=; b=PeHDM/MyDpRLj8tQPWFX4jjppXdqbIxr505fTwbL4tmjPAHnbArA8g/WitKFO4d835uArxIlRcmtxBn+jKWHqsjXrKJ11TAAHB8uG8w/8Ub7ymlLxSnzmeLy0WkuVKCW7PQCPUy7q2JRWFN36cX0CXtH8Z/8x56lQvcJap2s5QE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Wed, 20 Dec 2017 08:40:15 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0323.018; Wed, 20 Dec 2017 08:40:15 +0000 From: "Eggert, Lars" To: "Lubashev, Igor" CC: QUIC WG Subject: Re: draft-lubashev-quic-partial-reliability Thread-Topic: draft-lubashev-quic-partial-reliability Thread-Index: AdN4eekQTxka84DaTqiLnO0Um5bpqQA9D5wA Date: Wed, 20 Dec 2017 08:40:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:233nHGPFdYK4GtHToB0sC+PpTpXlbzUWe87X/fT61VLfGhQkkFZ2HlMm6bsDPVKOy8TUf9VI0kS1yRgo0Wyf7SPsB9ZH8ozc7umHsHIUfVLLa+8akpvHgfCeZ92e9xN7OPDcrSJ+7yPlyf8Lh9Vj1bNmDZoRI4/S1UcC108tHEQoJ3BQ6sBPuL3bHEdteyReIEmeLwsajRxNNtPU0WjrTybHL7MpAaRqduVKsRdZQrwOxJydfYPae9nREboIJkYKF/VT5cb/OIvWf2ZchKK9RsEW4FsChV1YbJtXoCW8DfiDtSkGZ6z4wkZkMb7Tnc8cqu9ZgbdOh/ZI1A50HS/sGQB2TKLumB6rYdl5XfM1rgA=; 5:Uu6pnUR7dVV1OshxCVYNaBMA844LT7oxGYXMJrkFsrwU0/5hIew+7WLDJx7rbCvEB1Gj4ywFsxsJnm9492Tlp/7BPUIvpNOuOa2WLeOdTbPElUy5ICMiGh6ncFbSrZUep0VBSwJgFDnvyMKd69KehO7UNbL5ksl/3SwSTKymUpA=; 24:kfIEZs7CQo1n/nxao4y0yTQmuF2GmFdunhA1p2Hk60ZyaQltBZ+4YGodBjQPotFW5sxJ6qC0AOjKr3AtSNg21itypBLDyNThXc83XwfJClU=; 7:Jt45qQoKK5ohoXxHf6tYZqSn/KNawZgToNNyTeWcDpKraVok0hFp6lUHPRxuSkORWJUaom+SpaLIsHNI0R301GdnqlgsEYT5I+sx9aMU9z1azbIond8aQZYYjS3a8z79e5fEMf7VIq+HE2uSRCEVfPmCZ3GoWnLi0Tl9Ln4t10keLHH0jolEv0aElHftkcVST4iX7Z1hdDGkN8Xp1sMsfML+J756zAHLhP21XowBDcVvhPop44Xi9ZTv8JnSjq09 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 20620dbe-c40e-4f49-38f7-08d547854adc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(376002)(39380400002)(366004)(377424004)(189003)(199004)(24454002)(2900100001)(99936001)(6512007)(86362001)(316002)(76176011)(99286004)(6436002)(77096006)(229853002)(478600001)(57306001)(561944003)(14454004)(6486002)(33656002)(66066001)(83716003)(3280700002)(3660700001)(305945005)(2906002)(81166006)(8676002)(6506007)(8936002)(6246003)(59450400001)(7736002)(105586002)(106356001)(81156014)(25786009)(53546011)(4326008)(5660300001)(4001150100001)(2950100002)(82746002)(230783001)(6916009)(102836003)(68736007)(50226002)(3846002)(6116002)(97736004)(36756003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_73478A77-82D5-4FC5-831A-55DE24B57A57"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 20620dbe-c40e-4f49-38f7-08d547854adc X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 08:40:15.2774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.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: Wed, 20 Dec 2017 08:40:19 -0000 --Apple-Mail=_73478A77-82D5-4FC5-831A-55DE24B57A57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2017-12-19, at 4:39, Lubashev, Igor wrote: > I=E2=80=99ve just posted a draft on adding partial reliability to QUIC = streams. with my chair hat on - and without having discussed this with Mark - I = would like to remind people that partial reliability is called out in = the charter as something that is explicitly *not* currently in scope. Give that we're further trying to limit QUICv1 by reducing the scope = even compared to what is in the charter, I think we should really put = this proposal on the back burner for a while. This is not a comment about the quality of the proposal itself - I = haven't read it. It's a reminder that we already had to push our = milestones back, and starting to discuss things that are not QUICv1 = doesn't seem like the most effective use of our cycles. Lars --Apple-Mail=_73478A77-82D5-4FC5-831A-55DE24B57A57 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlo6Ie4ACgkQVLXDCb9w wVdXjhAAg0iqutZPW7nFaSMk+PGh+Wipo8CUQ3lSeThT1pauXtsvtkfKf2m7oVfx jYwoiTY1dxk3/ZKjAPYYHNOmBnjRibH4iwXSG7Wy8dBASefHVA3fXFyNwirs8xYz kWjABYYp9WHhsoD3pZ+w0+nTWjmmZG7wkYYRhU4RfQUmIXx0Cgd8McGuPknUh0HP i4/7knxNgUHGkx/ntERAOnpKu6n+Z2lXSpC2XZ8LFz5Lpy5XX1kcfxkbcpcuqBNs QpY7kP02FBpuXTrDdd5UZFNITp9n4iR+amS4vChYBz9MeO/+ULP28gMJ0luTbAJj gtdbRrxWeBc60vuDfh7Hq3GzPv0zNZYcLFiEFnUWgf+B0XIl58Yo4Z+v0SbwotV/ 0sVcXord+gSiY0rZbFgkjAZh+/Iar1XL2xiosLvhUqETIt2qTIoofrRPhGg+PfHW 0wRRgrPfuZ3kPGKMl2SH3Mgivu9mLD96Ek4Q5VtYay9XyGmM+DbFIzvO1lhgJmMu /cew/ZvAOAzedkAmPV/lNJhlzmt1jWy8aXuHjVSWTmXea1XiyQm9EEnmEa+zMoOx qbwvxA/dB+nm53RaIiPHIdbvXkpXbdPl99Duadt1a15oeRcODbjXXJWr1ogIOBiJ awSP0AvRIBIZZh/NuB0+vm2dyxv/N9xHKGL6R3n1nqfZidAI6AA= =wh7e -----END PGP SIGNATURE----- --Apple-Mail=_73478A77-82D5-4FC5-831A-55DE24B57A57-- From nobody Wed Dec 27 13:12: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 AF758127275 for ; Wed, 27 Dec 2017 13:12:15 -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 s5A23pLbLx-X for ; Wed, 27 Dec 2017 13:12:13 -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 C0CE6124D85 for ; Wed, 27 Dec 2017 13:12:13 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eUIzj-00064N-3W for quic@ietf.org; Wed, 27 Dec 2017 22:12:12 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eUIz0-0007Y8-7o for quic@ietf.org; Wed, 27 Dec 2017 16:12:09 -0500 Received: (qmail 32322 invoked from network); 27 Dec 2017 21:11:25 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Dec 2017 21:11:24 -0000 References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> To: "quic@ietf.org" From: Christian Huitema X-Forwarded-Message-Id: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> Message-ID: <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> Date: Wed, 27 Dec 2017 13:11:21 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------8D1DDA196DE6251D8E7F11C9" Content-Language: en-US Subject: Fwd: New Version Notification for draft-huitema-quic-mpath-req-00.txt X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qg+GF2bCfSghNAmzRBNy2wXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fufgBMZZOEPX8NSAU7MCaXHB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPTmWL20QDaTB8w3xrEB2b tyq4BukT3QBnVdlneavYsvMHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFGJcKcttgBZ1L66iO4uqDysibYT4C2qF2lnc18bVJn65P vZj1p1FvH+oEP9E8GWGSvRi0E9myGDb2WiKGw4mfozwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTgV2UgQ4fjGXvUpBoNqBFuFjI1dRH6f16eQCtvwPkeoznDkScy96NTyJk9BjUcSB1l1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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: Wed, 27 Dec 2017 21:12:15 -0000 This is a multi-part message in MIME format. --------------8D1DDA196DE6251D8E7F11C9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Yes, I know full well that multipath is not in scope for V1. But since we are dabbling in connection migration anyhow, I thought we could just as well have a document listing multipath requirements and issues... -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt Date: Wed, 27 Dec 2017 13:07:17 -0800 From: internet-drafts@ietf.org To: Christian Huitema A new version of I-D, draft-huitema-quic-mpath-req-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-quic-mpath-req Revision: 00 Title: QUIC Multipath Requirements Document date: 2017-12-27 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-mpath-req-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/ Htmlized: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-req-00 Abstract: This document describes the requirement and plausible architecture of QUIC multipath extensions. While the first version of QUIC is not scheduled to include multipath extensions, there are risks that decisions made in this first version might preclude some options that we may later find attractive. An early review of multipath extension requirements and issues should minimize that risk. 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 --------------8D1DDA196DE6251D8E7F11C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Yes, I know full well that multipath is not in scope for V1. But since we are dabbling in connection migration anyhow, I thought we could just as well have a document listing multipath requirements and issues...

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt
Date: Wed, 27 Dec 2017 13:07:17 -0800
From: internet-drafts@ietf.org
To: Christian Huitema <huitema@huitema.net> 


A new version of I-D, draft-huitema-quic-mpath-req-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-quic-mpath-req
Revision:	00
Title:		QUIC Multipath Requirements
Document date:	2017-12-27
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-huitema-quic-mpath-req-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/
Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-mpath-req-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-req-00


Abstract:
   This document describes the requirement and plausible architecture of
   QUIC multipath extensions.  While the first version of QUIC is not
   scheduled to include multipath extensions, there are risks that
   decisions made in this first version might preclude some options that
   we may later find attractive.  An early review of multipath extension
   requirements and issues should minimize that risk.

                                                                                  


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
--------------8D1DDA196DE6251D8E7F11C9-- From nobody Thu Dec 28 02:04: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 68B2412D86C for ; Thu, 28 Dec 2017 02:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 wDpAIiASVn0L for ; Thu, 28 Dec 2017 02:04:35 -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 41328126B6D for ; Thu, 28 Dec 2017 02:04:34 -0800 (PST) Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D3CB3278263 for ; Thu, 28 Dec 2017 19:04:31 +0900 (JST) Received: by mail-wm0-f49.google.com with SMTP id r78so43338463wme.5 for ; Thu, 28 Dec 2017 02:04:31 -0800 (PST) X-Gm-Message-State: AKGB3mKZRtcgq/VeUnnJX+V6JabtZr8SIZpuAxhG1vX8HQyn0FOFVro7 +rZgINhS0QqEKnmAB3/2BVCVD46DrlsgPCFcQRQ= X-Google-Smtp-Source: ACJfBotqMdY4vLU33mG3l+TZNI9M4RtQKUy7Uk8evHsQDYCu9aw0schKdTlqx2YdgG4A+CSjQYvDDSj9WdtoL/QKvkU= X-Received: by 10.28.149.203 with SMTP id x194mr25815507wmd.145.1514455469830; Thu, 28 Dec 2017 02:04:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.147.199 with HTTP; Thu, 28 Dec 2017 02:04:28 -0800 (PST) In-Reply-To: <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> From: Yoshifumi Nishida Date: Thu, 28 Dec 2017 02:04:28 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt To: Christian Huitema Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1148eb984eb9b1056163a4c3" 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, 28 Dec 2017 10:04:38 -0000 --001a1148eb984eb9b1056163a4c3 Content-Type: text/plain; charset="UTF-8" Hi Chritian, I think this is a useful doc, but I might want to clarify one thing in the following text. Since different paths experience different network conditions, it follows that congestion control should be executed separately for each path, just like it is executed separately for each subflow in MPTCP [RFC6824]. MPTCP measures ACKs, losses and delays on each path, however, adjusting transfer rate in MPTCP is governed by coupled congestion control. So, it seems to me that this is not very precise expression for MPTCP. I think the draft needs to clarify this point. Also, I believe QUIC should follow the same principle. Thanks, -- Yoshi On Wed, Dec 27, 2017 at 1:11 PM, Christian Huitema wrote: > Yes, I know full well that multipath is not in scope for V1. But since we > are dabbling in connection migration anyhow, I thought we could just as > well have a document listing multipath requirements and issues... > > -- Christian Huitema > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt > Date: Wed, 27 Dec 2017 13:07:17 -0800 > From: internet-drafts@ietf.org > To: Christian Huitema > > A new version of I-D, draft-huitema-quic-mpath-req-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-quic-mpath-req > Revision: 00 > Title: QUIC Multipath Requirements > Document date: 2017-12-27 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-mpath-req-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/ > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-req-00 > > > Abstract: > This document describes the requirement and plausible architecture of > QUIC multipath extensions. While the first version of QUIC is not > scheduled to include multipath extensions, there are risks that > decisions made in this first version might preclude some options that > we may later find attractive. An early review of multipath extension > requirements and issues should minimize that risk. > > > > > 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 > > > --001a1148eb984eb9b1056163a4c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chritian,

I think this is a useful d= oc, but I might want to clarify one thing in the following text.=C2=A0
   Since different paths experience different network conditions, it
   follows that congestion control should be executed separately for
   each path, just like it is executed separately for each subflow in
   MPTCP [RFC6824].
MPTCP measures ACKs, lo= sses and delays on each path, however, adjusting transfer rate in MPTCP is = governed by coupled congestion control. So, it seems to me that this is not= very precise expression for MPTCP.
I think= the draft needs to clarify this point.=C2=A0
Also, I believe QUIC should follow the same principle.

Thanks,
--
Yoshi


=C2=A0

=C2=A0

On Wed, Dec 27, 2017 at 1:11 PM, Christian Huitema <huite= ma@huitema.net> wrote:
=20 =20 =20

Yes, I know full well that multipath is not in scope for V1. But since we are dabbling in connection migration anyhow, I thought we could just as well have a document listing multipath requirements and issues...

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt
Date: Wed, 27 Dec 2017 13:07:17 -0800
From: internet-drafts@ietf.org
To: Christian Huitema <huitema@huitema.net> 


A new version of I-D, draft-huitema-quic-mpath-req-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-quic-mpath-req
Revision:	00
Title:		QUIC Multipath Requirements
Document date:	2017-12-27
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/inter=
net-drafts/draft-huitema-quic-mpath-req-00.txt
Status:         https://datatracker.ietf.org/do=
c/draft-huitema-quic-mpath-req/
Htmlized:       https://tools.ietf.org/html/draft-=
huitema-quic-mpath-req-00
Htmlized:       https://datatracker.ietf.org/=
doc/html/draft-huitema-quic-mpath-req-00


Abstract:
   This document describes the requirement and plausible architecture of
   QUIC multipath extensions.  While the first version of QUIC is not
   scheduled to include multipath extensions, there are risks that
   decisions made in this first version might preclude some options that
   we may later find attractive.  An early review of multipath extension
   requirements and issues should minimize that risk.

                                                                           =
      =20


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

--001a1148eb984eb9b1056163a4c3--